1장 사용자 수에 따른 규모의 확장성

[HaeUlNam]

Template

느낀점

정리

몰랐던 내용

더 알아본 내용

질문

[fuzzysound]

정리

• 더 많은 사용자를 지원하기 위해 다음과 같은 확장이 필요하다.
  • 데이터 계층의 분리 (DB 서버)
  • 로드밸런서 도입 및 수평적 확장
  • 데이터베이스 다중화 (master & slave)
  • 캐시와 CDN 도입 (성능 향상)
  • 무상태 아키텍처 구현 (세션이 필요없도록)
  • 데이터센터 도입 (성능 및 가용성 향상)
  • 메시지 큐
  • 로그, 메트릭, CI/CD
  • DB 샤딩

몰랐던 내용

• 전체적으로는 일반적인 내용이어서 새로운 건 없었다.
• 다만 각각의 확장에서 고민해봐야 할 포인트들은 생각해본 적이 많이 없는데, 이런 질문들에 대한 답을 생각해보면 도움이 많이 될 것 같다. (ex. 다중 지역 데이터센터 구축 시 동기화를 어떻게 할 것인가)

더 알아본 내용

• 넷플릭스의 데이터센터 다중화 전략: Active-Active (https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
• 중요 내용만 요약하자면
  • Active-Active란 여러 AWS 리전에 걸쳐 데이터를 다중화하여 가용성을 높이는 솔루션으로, 가령 재난이 일어나 단 한 개의 AWS 리전만 살아남았더라도 그 리전에서 모든 사용자 요청을 처리할 수 있도록 하는 것이다.
  • Active-Active를 달성하기 위해서는 3가지 요건이 충족되어야 한다.
  • 모든 서비스가 stateless해야 한다.
  • 모든 리소스는 국지적으로 (locally) 접근 가능해야 한다.
  • 유저 요청 경로 (call path)는 지역을 가로지르면 안 된다. Consistency를 달성하기 위한 데이터 복제는 비동기적으로 이루어져야 한다.

질문

• 우리 회사에서는 무상태성을 어떻게 달성하고 있는가?
  • 내가 알아본 바로는 유저 정보를 (...)에 저장하고, (...)를 통해 각 서비스에서 유저 정보를 불러온다.
• 우리 회사에서는 multi-region availability를 어떻게 달성하고 있는가?
• 무상태성을 달성하기 위해 모든 세션 데이터를 데이터 계층으로 옮길 수 있는가? (ex. 장바구니)

[briggirl2]

느낀점

규모 확장이라는 주제로 아래 내용들을 묶어서 설명하니까 더 잘 읽어진 것 같다. 우리 회사 정도 규모의 서비스는 아래 내용을 고려한 설계인 것 같다.

정리

• 데이터베이스 선택
  • 비관계가 바람직할 경우? 낮은 latency, 비정형 데이터, 직렬화/역직렬화만 가능하면됨, 아주 많은 양의 데이터.
• 수직적 규모 확장(scale up)
• 수평적 규모 확장(scale out) -> load balancing, auto scaling
• 데이터베이스 다중화
  • master/slave, source/replica
• 캐시: expire, consistency, eviction, memory 고려.
• CDN
• Stateless 무상태 웹 계층
• 여러 개의 데이터 센터
• 메세지 큐
  • lag에 따라서 process 수 조절.
  • 서버간 결합이 느슨해짐 -> 안정적.
• Log, Metric, Automation.
• 데이터베이스의 수평적 확장 (Sharding) : partition key 고려.

몰랐던 내용

다른 내용들은 회사에 들어와서도 보게되는 내용인데 Stateless에 대해서는 생각해본적이 없었다. 무상태 웹계층을 어떻게 설계하는지..?

더 알아본 내용

• 카카오 장애
• https://if.kakao.com/session?f.2gB2OPT7YO.GgWcMRm0cNSS=re1015

[xodhx4]

느낀점

항상 말은 쉬워 보인다. 만약 내가 회사의 CTO가 되어 이것을 실제 코드로 만들어야 한다면 막막하다. 카카오가 개발자 도구가 다중화 되지 않아 복구 문제가 늦어졌던 것처럼 문제는 어디서 터질지 모르고, 그렇기 때문에 항상 질문을 던질 준비를 해야한다

정리

• 시스템 확장하기
  • 웹 계층
    • 로드밸런서

      • question 로드밸런서가 SPOF가 될 일은 없나?

      • question 로드밸런서 알고리즘

    • CDN
      • 고려사항
        • 비용
        • 만료 시한
        • 장애 대처 방안
        • 콘텐츠 무효화 방법
    • Stateless 웹 계층
      • 정의: 상태 정보를 보관하지 않는 서버
      • 공유 저장소
        • 세션 정보를 저장

      • question JWT

  • 데이터 계층
    • RDBMS
    • NoSQL
      • 분류
        • key-value store
        • graph store
        • column store
        • document store
      • NoSQL 유용할 수 있는 요구 사항
        • low latency
        • unstructured data
        • 데이터의 직렬화, 역직렬화만 필요
        • 많은 양의 데이터 저장
    • DB 다중화
      • DB Replication
      • DB Shariding
        • 고려사항
          • 샤딩 키 디자인
          • 데이터 재 샤딩
          • 핫스팟 문제
          • 조인과 비정규화

      • question DB Clustering

    • 캐시
      • 캐시 전략
      • 유의 사항
        • 갱신보다 참조가 자주 일어날 때
        • 어떤 데이터를 넣을 것인가
        • 어떻게 만료되는가
        • 원본 디비와 일관성을 어떻게 유지하는가
        • 캐시서버가 SPOF가 될 수 있는가
  • 데이터 센터
    • 라우팅 방법
      • 로드 밸런서에서 geo-routing
    • 다중 데이터 센터 기술적 난제
      • 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법
      • 데이터 동기화
      • 테스트와 배포

      • question 그림에서도 보이듯이 session 공유 저장소는 다중 데이터 센터와 상관없이 저장하는 것일까

  • 추가적인 도구
    • 메시지 큐
      • 서비스와 서버 간 결합을 느슨하게 함
    • 로그
      • 로그를 단일 서비스로 모오는 도구 활용 시 디버깅에 용이
    • 메트릭
      • 호스트 단위 메트릭: CPU, 메모리, 디스크 I/O
      • 종합 메트릭: 데이터베이스 성능, 캐시 성능
      • 핵심 비즈니스 메트릭: DAU, Revenue, Retention
    • 자동화
      • 빌드, 테스트, 통합, 배포 등에 자동화를 해 생산성 향상

몰랐던 내용

다중 데이터 센터 난제.

더 알아본 내용

• 로드 밸런싱의 종류와 알고리즘
• JWT를 이용한 세션 유지 방법

질문

qeustion으로 표시해 두었습니다.

[HaeUlNam]

느낀점

• Cache 전략에 대해서 예전에 프로젝트를 하면서 본적은 있는데, 다시 찾아보면서 정리하게 되서 좋았다.
• Eviction policy는 Redis/Guava cache가 모두 LRU 알고리즘을 쓰는 걸 처음 알게 됨.
• Json 외에 데이터 포맷을 잘 써본 적이 없어서 궁금하긴 함. Protocol buffer나 Thirft를 직접 써볼 기회가 있으면 좋겠음.

정리

• 단일 서버: DNS, 데이터 포맷으로 Json을 널리 사용
  • Json 외에 사용하는 데이터 포맷은 뭐가 있을까?
    • Protocol Buffers, Apahe Thirft, Apache Avro
    • https://www.bizety.com/2019/04/02/data-serialization-protocol-buffers-vs-thrift-vs-avro/
• 데이터 계층(DB)
  • RDBMS vs NoSQL
  • 수직적 규모 확장 vs 수평적 규모 확장: Failover, Re-dundancy.
    • 수평적 확장 Sharding: sharding 전략을 구현할 때 가장 중요한 것은 샤딩 키
  • master vs slave
    • write operation은 마스터에서만 지원: insert/delete/update
    • slave는 master로부터 사본을 전달받으며, read operation만을 지원: Redis는 Slave node가 처음으로 startup할 때 SYNC command를 통해서 master 노드 snapshot를 받아서 sync하고, 이후에는 replication command들을 이용해서 sync.
• Load Balancer
  • 우리는 Load Balancer 주소를 그대로 사용하지 않고 Route 53을 이용해서 domain name을 제공하는 듯. 이를 통해, Client 변경없이 Load Balancer 변경 가능
• Cache
  • Read-through caching strategy: 저장되어있다면 해당 데이터를 클라이언트에 반환, 없는 경우 데이터베이스 질의를 통해 데이터를 찾아 캐시에 저장한 후 클라이언트에 반환
  • Refresh-ahead caching strategy: 캐시가 만료되기 전에 미리 refresh를 해서 read 성능을 높인다.
  • https://docs.oracle.com/cd/E15357_01/coh.360/e15723/cache_rtwtwbra.htm#COHDG5180
  • Expired policy: 캐시의 시간을 지정하지 않는 것은 안티 패턴
  • Eviction policy: 메모리가 부족하거나 Size limit이 있을 때는 만료 정책에 따라 삭제하게 되는데, 보통 Redis와 Guava cache는 LRU 알고리즘을 사용하는 것 같음.
• Stateless
  • 상태 정보 의존적인 아키텍처: Sticky session.
    • https://smjeon.dev/web/sticky-session/
  • 무상태 아키텍처
• Message Queue: 서버 간 결합이 느슨해져서 규모 확장성이 보장되어야 하는 안정적 Application을 구성하기 좋다. 시간이 오래 걸리지만 바로바로 처리하지 않아도 되는 작업들?

질문

• RDBMS와 NoSQL을 선택하는 기준이 어떻게 될까?
• 결과적으로 Stateless를 달성하려면, Cache 시스템이나 DataBase등의 autoscaling이 가능해야 할 것 같은데, 가능할까?

더 알아본 내용

• 정리 중간중간 추가해두었음