본문 바로가기

전체 글

(387)
[프로젝트 이슈] 무중단 배포 자동화 들어가기 전지난번 배포 과정에서는 GitHub Actions와 CodeDeploy를 활용해 빌드와 서버 배포를 대부분 자동화했기 때문에, 사람이 직접 파일을 복사하고 서버를 재시작하며 발생할 수 있는 오류는 크게 줄일 수 있었습니다. 또한 배포 실패 시 CodeDeploy의 롤백 기능을 통해 이전 버전으로 빠르게 되돌릴 수 있어, 서비스가 완전히 중단되는 상황은 최소화할 수 있었습니다. 하지만 단일 EC2 인스턴스 환경에서는 배포 중 잠시 서비스가 끊길 가능성을 완전히 제거할 수 없었고, 진정한 의미의 무중단 배포까지 구현한 것은 아니었습니다. 이 한계를 보완하고자, 배포 과정에서 서비스 중단을 최소화할 수 있는 전략을 찾아보았습니다.롤링(Rolling) 배포 방식카나리 (Canary) 배포 방식블루/그..
[프로젝트 이슈] CI/CD 구축기 들어가기 전코드를 완성하고 나면, 그다음 단계는 바로 배포입니다. 처음에는 단순하다고 생각했습니다. 로컬에서 빌드한 JAR 파일을 서버에 올리고, SSH로 접속해서 실행하면 끝났죠. 한두 번 정도는 금방 끝나는 일이었고, 이 정도면 충분하다라고 생각하기도 했습니다. 제가 처음 배포를 시작했을 때는, 로컬에서 서버로 JAR 파일을 옮기는 과정도 직접 실행하여야 했습니다. 일반적으로는 SCP나 SFTP를 이용해서 파일을 서버에 업로드했습니다. 예를 들어, 터미널에서 다음과 같이 명령어를 입력하면 됩니다.scp build/libs/app.jar ubuntu@서버IP:/home/ubuntu/app/ 이 한 줄로 로컬에서 빌드한 JAR 파일이 원격 서버의 지정 디렉토리로 복사됩니다. 처음에는 단순히 파일을 복사하..
[프로젝트 이슈] 사용자 로그인 처리(인증, 인가) 0. 들어가며API 서버를 설계하면서 가장 먼저 고민한 부분 중 하나는 사용자의 로그인 상태를 어떻게 관리할 것인가? 였습니다. 대표적인 방식으로는 세션 방식과 토큰방식이 있으며 관련 레퍼런스를 살펴보니 각각의 방식은 장단점이 존재했습니다. 세션 방식은 서버가 로그인한 사용자 정보를 서버 측 세션 저장소에 유지하고, 클라이언트는 세션 ID를 쿠키에 담아 요청마다 전달하는 구조입니다. 이 방식은 비교적 구현이 간단하지만, 서버가 상태를 유지(stateful)해야 하므로 확장성과 유연성에 제약이 있었습니다. 특히 서버가 여러 대로 구성되는 분산 환경에서는 세션 동기화 또는 공유 저장소를 구성해야 하므로 복잡도가 증가하는 문제점이 있었습니다. 반면, 토큰 기반 인증은 서버가 사용자 정보를 상태로 관리하지 않고..