본문 바로가기

전체 글

 (389)
[DB] 인덱스 느린 검색의 원인 - 풀 테이블 스캔 (Full Table Scan)인덱스가 없는 테이블에서 특정 데이터를 찾는 과정은, 비유하자면 100만 페이지짜리 거대한 책에서 특정 단어 하나를 찾기 위해, 책의 첫 페이지부터 마지막 페이지까지 한 장 한 장 넘겨보는 것과 같습니다. 예를 들어, 인프런의 데이터베이스에는 '강의 목록 ' 컬럼이 존재하고 이 컬럼에 '김영한의 실전 데이터베이스 강의 ' 이라는 값이 어디에 있는지 알 수 있는 아무런 힌트가 없습니다. 그래서 데이터베이스는 가장 무식하고 정직한 방법을 선택한다고 합니다. 그것은 바로 테이블 전체를 디스크에서 메모리로 읽어들인 후, 첫 번째 행부터 마지막 100만 번째 행까지 하나씩 차례대로 '강의 목록 ' 컬럼의 값을 비교하는 것 입니다. 이러한 작업..
[프로젝트 이슈] API 호출량 제한 들어가기 전이번 프로젝트에서는 사용자의 위치를 기반으로 주변 스터디룸을 탐색하는 기능을 제공했습니다. 처음에는 사용자가 조회할 때마다 외부 API를 호출하여 실시간 데이터를 가져오는 방식으로 구현했지만, 곧 예상되는 문제가 존재했습니다. 사용자가 늘어날수록 API 호출 횟수가 기하급수적으로 증가하면서 비용이 커질 것이고, 특히 카카오 API의 호출 제한 때문에 안정적으로 데이터를 가져오기 어려운 상황도 발생할 수 있다고 생각했습니다. 이를 해결하기 위해 지난 번 지오해시(GeoHash)를 활용한 캐싱 전략을 도입했었습니다. 각 스터디룸 데이터에 지오해시 값을 포함해 저장하고, 사용자가 특정 위치를 조회할 때는 해당 지점이 속한 격자와 인근 8개 격자를 함께 조회하도록 설계했습니다. 이후, 매번 외부 AP..
[프로젝트 이슈] 무중단 배포 자동화 들어가기 전지난번 배포 과정에서는 GitHub Actions와 CodeDeploy를 활용해 빌드와 서버 배포를 대부분 자동화했기 때문에, 사람이 직접 파일을 복사하고 서버를 재시작하며 발생할 수 있는 오류는 크게 줄일 수 있었습니다. 또한 배포 실패 시 CodeDeploy의 롤백 기능을 통해 이전 버전으로 빠르게 되돌릴 수 있어, 서비스가 완전히 중단되는 상황은 최소화할 수 있었습니다. 하지만 단일 EC2 인스턴스 환경에서는 배포 중 잠시 서비스가 끊길 가능성을 완전히 제거할 수 없었고, 진정한 의미의 무중단 배포까지 구현한 것은 아니었습니다. 이 한계를 보완하고자, 배포 과정에서 서비스 중단을 최소화할 수 있는 전략을 찾아보았습니다.롤링(Rolling) 배포 방식카나리 (Canary) 배포 방식블루/그..

티스토리툴바