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

[minkukjo]

느낀 점

• 일반적인 웹/앱 서비스에 필요한 설계 기법을 다루는 책이었다.
• 아주 작은 서비스 ( 서버, DB )로 시작해서 cdn 이중화 무상태 등 점진적으로 내용을 전개해나가는 빌드업이 좋았다.
• RDBMS의 수평 확장은 어렵다고 알려져 있는데, 최근 Glace 밋업에서 https://vitess.io/를 써서 서비스를 운영하는 옆 팀의 발표를 들어서 안되는건 없구나.. 라고 느낌 ㅋㅋ
• 샤딩 시 유의해야할 문제로 유명인사 문제는 신박했음. 빈번한 질의가 오는 샤드가 위치한 장비에 트래픽이 몰릴 수 있으니. 이런 경우는 어떡하면 좋을까요? ( 급 질문 )
• 개인적으로 넷플릭스에서 어떤 식으로 다중화를 하고 데이터간의 싱크를 맞추는지가 궁금해서 해당 기술 블로그를 찾아봄
• https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b
• 따로 번역된 건 없어서 나중에 블로그에 번역해 볼 예정

[LOG-INFO]

느낀점

• 작동하는 것만 고려한 단일 서버 아키텍처부터 가용성을 고려한 복잡한(?) 아키텍처까지 가는 과정을 단계별로 그려서 학부생들도 잘 이해할 수 있을 것 같음
• 딱 3학년 때 궁금해했던 것들이 거의 다 들어있는 장이었음
  • RDB vs NoSQL, 웹 애플리케이션 서버 스케일업/아웃 (+ failover, redundancy, load balancer), DB 다중화(master-slave, replication, sharding), Cache, CDN, ...
  • 그 땐 이런거 검색해도 잘 나오지 않았던 거로 기억함
  • 주변에 서버개발자도 많지 않았음
• 여러 캐시 전략이 있다는 것을 알게 됨
  • 읽기 주도형 캐시 전략(read-through caching strategy)
  • 캐시를 먼저 읽어서 있으면 반환, 없으면 데이터 새로 조회해서 캐시에 저장 후 반환
  • 여러 캐시 eviction 정책
  • LRU, LFU, FIFO
• 두나무 면접에서 두나무 홈페이지에 접속하면 서버 레이어에서의 요청 전달 과정이 어떻게 될까요?를 질문했었는데 이런걸 물어본거였나 싶음
• 면접 때 샤드 관련 질문이 몇 번 나왔었는데 이게 꽤 어려웠던 것으로 기억함
  • 재샤딩
  • celebrity 문제

  • join & de-normalization

    이 외 키워드

• stateful vs stateless
  • sticky session
  • LB에 부담을 준다 -> LB에서는 sticky session을 어떻게 제공할까?
• 다중 데이터센터
  • 지리적 라우팅(geoDNS-routing)
  • 트래픽 우회
  • 데이터 동기화
  • 테스트와 배포 자동화

[2rohyun]

느낀점

---

• 전체적으로 아키텍처를 설계하기 위해 쭉 정리하고 훑은 느낌이다.
• 기억이 안나던 것, 잘 몰랐던 것에 대해 되새김질 할 수 있어서 좋았다!
• 아래는 읽으면서 추가적으로 조금 더 정리하기 위해 찾아본 내용을 조금 정리해보았다.
• 시간이 된다면 캐시 관련 러닝 드리겠습니다!

끄적 끄적

---

• LB 알고리즘
  • 라운드 로빈
    • 서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식
    • 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합함.
  • 가중 라운드 로빈
    • 각각의 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분하는 방식
    • 주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 부하 분산 방식이다. 예를 들어 A라는 서버가 5라는 가중치를 갖고 B라는 서버가 2라는 가중치를 갖는다면, 로드밸런서는 라운드로빈 방식으로 A 서버에 5개 B 서버에 2개의 요청을 전달함.
  • IP hash
    • 클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식
    • 사용자의 IP를 해싱해(Hashing, 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 매핑하는 것, 또는 그러한 함수) 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장함.
  • Least Connection
    • 요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 우선적으로 트래픽을 배분하는 방식
    • 자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합함.
  • Least Response time
    • 서버의 현재 연결 상태와 응답시간(Response Time, 서버에 요청을 보내고 최초 응답을 받을 때까지 소요되는 시간)을 모두 고려하여 트래픽을 배분하는 방식
    • 가장 적은 연결 상태와 가장 짧은 응답시간을 보이는 서버에 우선적으로 로드를 배분함.
• 데이터베이스 다중화
  • 부 서버에 보관된 데이터가 최신 상태가 아닐 때, recovery script
  • 다중 마스터 ( multi-masters )
  • 원형 다중화 ( circular replication )
• 캐시 전략
  • Read Through
  • Write Through
  • Write Back
• 데이터베이스 수평적 확장 ( 샤딩 ) - Range based, Modulus based
  • https://tech.kakao.com/2016/07/01/adt-mysql-shard-rebalancing/
  • https://techblog.woowahan.com/2687/
  • 샤딩 key ( partition key ) 전략 - 데이터가 어떻게 분산될지 정하는 하나 이상의 컬럼으로 구성
  • 문제
    • Data resharding
      • 데이터가 너무 많아져서 하나의 샤드로는 감당하기 힘들 때
      • 샤드 간 데이터 분포가 균등하지 못해 어떤 샤드에 할당된 공간 소모가 다른 샤드에 비해 빠르게 진행될 때
      • shard exhaustion 이라고 부르는 이런 현상이 발생하면 사드 키를 계산하는 함수를 변경하고 데이터를 재배치하여야 한다. ( 5장의 consistent hashing 기법 활용 )
    • Celebrity 문제
      • hotspot key 문제라고도 불림.
      • 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제
    • Join and De-normalization
      • 하나의 데이터베이스를 여러 샤드 서버로 쪼개고 나면, 여러 샤드에 걸친 데이터를 조인하기가 힘들어진다.
      • 해결 방법은 데이터베이스를 비정규화하여 하나의 테이블에서 질의가 수행될 수 있도록 한다.

[MinJunKweon]

확장을 위한 간단 정리

1. 웹 서버 다중화 (로드밸런서)
2. 데이터베이스 다중화 (Master - Slave 구조)
3. 캐시 사용 (빈번한 Read, 높은 Cost, 느린 변화)
4. CDN 사용
5. 공용 데이터 저장소 (세션 데이터 등)
6. 데이터 센터 이중화
7. 데이터베이스 확장 (샤딩)

느낀점

• 네이버도 IDC를 3개 사용하는데, 제가 속한 팀도 얼마전 두 군데로 이중화 작업을 했음.
• 데이터베이스도 이중화를 했는데, Active - StandBy로 나머지는 데이터 복제만 해두고 장애 발생 시 프라이머리를 바꾸는 방식인듯
• 몽고디비 쓰면서 데이터가 크면 샤딩을 하긴하는데 쿼리에 제약이 좀 걸려서 데이터 작은 컬렉션들은 샤딩 안하고 쓰는중 (그렇게 성능차이가 많이 나는것 같지는 않음)