[BE] 괜찮을지도 아키텍처 개선 방안

현재 팀의 아키텍처에서 사용자가 늘어났을 때 문제가 될 수 있는 부분을 설명하고, 이를 개선할 수 있는 방법에 대해 작성한다.

• 만명, 10만명, 1,000만명이 사용해도 서비스할 수 있도록 팀의 인프라 아키텍처 개선 방향

서비스 특징

• 사회적 이슈 발생에 따라, 조회수가 급증하는 컨텐츠가 있다.
  • ex) 코로나 시기 마스크 판매처 지도
  • ex) 지하철 살인 예고 등의 사건 사고 발생지 지도
• 하나의 DB에서 읽기 - 쓰기 작업이 모두 이루어진다.
• 컨텐츠가 공개 / 비공개로 나눠져있고, 즐겨찾기 등의 기능이 있다.

문제 사항 - 개선 방안

하나의 DB에 읽기 및 쓰기 부하 집중되어 있고, DB 장애 시 서비스의 가용성을 보장할 수 없다.

• DB Replication을 통해, 쓰기용 DB와 읽기용 DB를 분리하여 서버의 성능 저하를 방지한다.

특정 컨텐츠에 대해 반복적인 데이터베이스 조회로 인해 성능이 저하될 수 있다.

• 캐싱 서버를 도입하여, 조회수 및 즐겨찾기 수등을 통해 지도와 핀의 인기도를 측정하여 이를 기반으로 캐싱하는 Popularity-based 캐싱 전략을 사용한다.

트래픽이 몰리는 시기를 예측할 수 없다.

• 쿠버네티스를 도입하여, 사용자가 늘어날 시 자동적으로 scale out을 할 수 있는 환경을 세팅한다.

분산 환경 도입 시, 외부 트래픽을 적절히 분산할 수 없다.

• 분산 환경에서 외부 트래픽을 적절하게 분산하기 위해 로드밸런스를 도입한다.
• 장애 발생 시에도 트래픽을 안전하게 처리할 수 있고, 고가용성 제공할 수 있다.

분산 환경 도입 시, RefreshToken을 발급 받은 서버가 아닌 경우, AccessToken을 재발급 받을 수 없다.

• RefreshToken을 서버 외부의 중앙 데이터 저장소에 저장하여, 각 서버에서 해당 저장소를 호출하여 액세스 토큰을 발급할 수 있도록 Redis 서버를 도입한다.

분산 환경 도입 시, 각 서버나 인스턴스에서 생성되는 로그를 관리할 수 없다.

• 중앙집중식 로깅 플랫폼을 도입하여, 로그 데이터를 단일 위치에서 집중 관리하고, 검색, 분석 및 보존을 용이하게 만든다.

  • 메시지 큐 도입
    • 로그 전송의 안정성을 향상
    • 네트워크 지연이나 중앙 로그 저장소의 일시적인 오류 등의 문제가 발생해도 로그 메시지를 안전하게 보관
    • 로그 메시지의 폭발적인 증가나 스파이크 처리
  • 대규모 로깅 메시지의 검색, 분석 및 보존을 용이하게 위해 ELK 스택 도입
    • Elasticsearch: 로그 메시지를 저장하고, 검색하고, 분석하는 분산형 검색 및 분석 엔진
    • Logstash: 다양한 소스에서 로그를 수집하여 변환 및 가공한 다음 다른 저장소로 전송하는 데이터 처리 파이프라인 도구
    • Kibana: Elasticsearch에 저장된 데이터를 시각화하고 대시보드를 생성하여 로그 분석을 도와주는 웹 인터페이스