📡 사용자 수에 따른 점진적 개선 방안

1만명

동기화, OAuth

세션 스토리지 및 pub-sub 구조

• 다중 인스턴스 환경에서 인스턴스가 재시작 되거나 로드 밸런싱을 통해 세션이 다른 인스턴스로 이동할 경우 타이머 남은 시간 정보가 유실되는 상황이 발생했다.
• 세션 스토리지에서 발행되는 타이머 정보는 실시간으로 여러 인스턴스에서 정보가 공유되어야한다. 따라서 사용자가 타이머를 트리깅하면, 각 인스턴스별로 발행되고, 소모 되어야한다. 이 과정에서 느슨한 연결을 통해 병목 지점을 최소화한다.
• 이 상황을 방지하기 위해 Redis를 도입한다.
• 타이머 정보 관리 및 OAuth 과정 state값 관리는 세션 단위로 저장이 필요하다. 따라서 인스턴스 외부에 세션 스토리지를 사용한다.

DB

샤딩 & writer DB 증설

• 코딩해듀오 서비스는 쓰기 작업보다 읽기 작업이 더 많이 발생한다.
• 삭제된 페어룸, 회고 작성까지 완료된 종료된 페어룸은 읽기 전용 데이터베이스로 분리하고, writer DB를 증설하여 성능을 개선한다.
• 현재 페어룸은 물리적 삭제가 아닌 논리적 삭제만 가능하다.
• 페어룸 생성 개수가 수천만건으로 늘어난다면, 데이터베이스가 모든 데이터를 감당할 수 없다.
• 또한 생성 시기가 오래된 페어룸을 조회해야 하는 상황이 적기 때문에 기간을 기준으로 데이터베이스를 분산하는 것이 효율적이라고 생각했다.
• 도메인 특성상, 오랜전에 생성된 방일수록 조회/ 수정 요청이 줄어들 것으로 예상되어 시간 단위로 데이터베이스를 분리하여 관리한다.

10만명

오픈그래프

S3, 비동기(RabbitMQ, Kafka), 캐싱

• 링크 저장하는 순간 해당 링크에 메타 데이터(썸네일, 제목, 페이지 설명)인 오픈 그래프를 크롤링한다.
• 크롤링 작업이 링크 저장과 같은 트랜잭션안에 포함되어 있어 크롤링이 오래 걸리는 경우 링크 저장도 오래 걸리게 된다.
• 사용자가 링크를 저장하는 것은 이미 해당 링크에 방문을 마친 다음 아카이빙 목적으로 저장하는 것이기 때문에 저장하자마자 바로 메타 데이터를 제공할 필요성이 크지 않다.
• 크롤링 작업을 비동기 작업으로 처리한다면 사용자 수가 증가하여도 대기 시간이 크게 증가하지 않을 것으로 예상한다.
• 그리고 이 메타 데이터 정보는 변경될 가능성이 굉장히 낮은 정보이다.
• 또한 현재 url 형식으로 이미지를 DB에 저장하고 있기 때문에 이미지를 조회할 때마다 크롤링을 하게 된다.
• 오픈 그래프 정보를 S3로 관리하거나 아니면 로컬 캐시에 저장한다면 조회시 빠른 응답률을 가져올 것으로 예상한다.

마이페이지

페이징

• 사용자의 페어룸과 회고 리스트를 보여줄 때, 한 번에 모든 정보를 보여줄 필요가 없다.
• 페이징을 적용해서 사용자에게 보여줄 정보를 작은 단위로 나뉘어 표시한다.
• 페이징 쿼리에서 OFFSET과 LIMIT을 사용하되, 큰 데이터셋에 대해 쿼리 성능이 저하될 수 있는 상황을 고려하여 인덱스를 최적화하거나, Keyset Pagination과 같은 방법을 활용하여 쿼리 성능을 높인다.

1000만명

오토 스케일링

• 수천만명의 사용자를 감당하려면 결국 시스템의 부하에 따라 리소스를 확장할 필요가 있다..
• CPU 사용률, 메모리 사용량, 네트워크 트래픽, TPS 등의 모니터링 지표를 기준으로 서버 인스턴스를 스케일-아웃 하거나, 스케일-인한다.

마이크로 서비스 아키텍쳐

• 사용자 수가 1000만명을 넘게 되면 새로운 기능을 추가할 때마다 시스템이 더 복잡해지고, 의존성이 높아져 빠른 배포가 어려워지게 된다.
• 따라서 기능단위로 서비스들을 분리하여 독립적으로 확장 가능하도록 한다.
• 특정 마이크로 서비스에 문제가 발생한 경우 해당 서비스만 재배포하거나 복구할 수 있기 때문에 빠르게 문제를 해결할 수 있다.
• 사용자 수가 1,000만 명을 넘으면, 기존의 모놀리식 아키텍처는 유지보수 역시 어려워진다. 새로운 기능을 추가할 때마다 시스템이 더 복잡해지고, 기능 간 의존성이 높아져 빠른 배포와 확장에 제한을 해결한다.