인프라 아키텍처 개선

동기화, OAuth

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

• 세션 스토리지
  • 타이머 정보 관리 및 OAuth 과정 state값 관리는 세션 단위로 저장이 필요하다. 따라서 인스턴스 외부에 세션 스토리지로 레디스를 사용한다.
• pub-sub
  • 타이머 정보는 각 인스턴스별로 발행되고, 소모 되어야한다. 이 과정에서 느슨한 연결을 통해 병목 지점을 최소화한다.

DB

샤딩

• 현재 페어룸은 물리적 삭제가 아닌 논리적 삭제만 가능하다.
• 페어룸 생성 개수가 수천만건으로 늘어난다면, 데이터베이스가 모든 데이터를 감당할 수 없다.
• 삭제된 페어룸, 회고 작성까지 완료된 종료된 페어룸 들은 읽기전용 데이터베이스로 분리한다.
• 또한 생성 시기가 오래된 페어룸을 조회해야 하는 상황이 적기 때문에 기간을 기준으로 데이터베이스를 분산하는 것이 효율적이라고 생각했다.

오픈그래프

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

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

마이페이지

페이징

• 사용자의 페어룸과 회고 리스트를 보여줄 때, 한 번에 모든 정보를 보여줄 필요가 없다.
• 페이징을 적용해서 사용자에게 보여줄 정보를 작은 단위로 나뉘어 표시한다.

오토 스케일링

• 수천만명의 사용자를 감당하려면 시스템의 부하에 따라 리소스를 확장할 필요가 있다.
• 어떤 시간대에 사용자가 가장 많이 몰리는지 분석하고, 피크 타임에 오토 스케일링을 적용한다.