본문 바로가기

전체 글

 (388)
[프로젝트 이슈] API 호출량 제한 들어가기 전이번 프로젝트에서는 사용자의 위치를 기반으로 주변 스터디룸을 탐색하는 기능을 제공했습니다. 처음에는 사용자가 조회할 때마다 외부 API를 호출하여 실시간 데이터를 가져오는 방식으로 구현했지만, 곧 예상되는 문제가 존재했습니다. 사용자가 늘어날수록 API 호출 횟수가 기하급수적으로 증가하면서 비용이 커질 것이고, 특히 카카오 API의 호출 제한 때문에 안정적으로 데이터를 가져오기 어려운 상황도 발생할 수 있다고 생각했습니다. 이를 해결하기 위해 지난 번 지오해시(GeoHash)를 활용한 캐싱 전략을 도입했었습니다. 각 스터디룸 데이터에 지오해시 값을 포함해 저장하고, 사용자가 특정 위치를 조회할 때는 해당 지점이 속한 격자와 인근 8개 격자를 함께 조회하도록 설계했습니다. 이후, 매번 외부 AP..
[프로젝트 이슈] 무중단 배포 자동화 들어가기 전지난번 배포 과정에서는 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 파일이 원격 서버의 지정 디렉토리로 복사됩니다. 처음에는 단순히 파일을 복사하..

티스토리툴바