시스템 설계 면접에서 시스템 용량이나 성능 요구사항을 개략적인 수치로 나타낼 수 있어야한다.

구글의 시니어 제프 딘은 다음과 같이 말했다.

개략적인 규모 추정은 보편적으로 통용되는 성능 수치상에서 사고실험을 행하여 추정치를 계산하는 행위로서, 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것이다.

즉 개략적인 수치 계산을 통해 어떤 설계가 어울릴지 찾아내는 것이다. 수치 계산을 위해 규모 확장성을 표현하는 기본기에 대해 알려주는게 이번 챕터2다.

• 2의 제곱수
• 응답지연 값
• 가용성에 관계된 수치들

2의 제곱수

• 1천바이트 ≒ 1KB
• 1백만(million) 바이트 ≒ 1MB
• 10억(billion) 바이트 ≒ 1GB
• 1조(trillion) 바이트 ≒ 1TB
• 1000조(quadrillion) 바이트 ≒ 1PTB

모든 프로그래머가 알아야 하는 응답 지연 값

• L1 캐시 참조 : 0.5ns
• 분기 예측 오류(branch mipredict) : 5ns
• L2 캐시 참조 : 7ns
• 뮤텍스(mutex) 락/언락 : 100ns
• 주 메모리 참조 : 100ns
• Zippy로 1KB 압축 : 10,000ns : 10μS
• 1 Gbps 네트워크로 2kb 전송 : 20,000ns = 20μS
• 메모리에서 1MB 순차적으로 read : 250,000ns = 250μS
• 같은 데이터 센터 내에서의 메시지 왕복 지연시간: 500,000ns = 500μS
• 디스크 탐색(seek) : 10,000,000ns = 10ms
• 네트워크에서 1MB 순차적으로 read : 10,000,000ns = 10ms
• 디스크에서 1MB 순차적으로 read : 30,000,000ns = 30ms
• 한 패킷의 CA(캘리포니아)로부터 네덜란드까지의 왕복 지연시간 : 150,000,000ns = 150ms

메모리는 빠르지만 디스크는 아직도 느리다.

디스크 탐색(seek)은 가능한 피하라.

단순한 압축 알고리즘은 빠르다.

데이터를 인터넷으로 전송하기 전에 가능하면 압축하라.

데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간의 데이터를 주고받는 데는 시간이 걸린다.

가용성에 관한 수치들

고가용성(high availability)

• 시스템이 오랜 시간동안 중단 없이 운영이 지속되는것.
• 퍼센트로 표기. 대부분의 서비스는 99% ~ 100%사이의 값을 가진다.

• 가용률	하루당 장애시간	주당 장애시간	개월당 장애시간	연간 장애시간
  99%	14.40분	1.68시간	7.31시간	3.65일
  99.9%	1.44분	10.08분	43.83분	8.77
  99.99%	8.64초	1.01분	4.38분	52.60분
  99.999%	864.000밀리초	6.05초	26.30초	5.26분
  99.9999%	86.40밀리초	604.80밀리초	2.63초	31.56초

예제: 트위터 QPS와 저장소 요구량 추정

가정

• MAU : 3억(300million)명이다.
• 50%의 사용자가 트위터를 매일 사용한다.
• 평균적으로 각 사용자는 매일 2건의 트윗을 올린다.
• 미디어를 포함하는 트윗을 10%정도다.
• 데이터는 5년간 보관된다.

QPS(Query per Second) 추정치는? DAU = 3억 * 50% = 1.5억명 1.5억 * 2 / 86400 = 3472.2 == 3500 최대 qps는 2*QPS = 7000

미디어 저장을 위한 저장소 요구량은? 평균 트윗 크기

• id : 64바이트
• text : 140바이트
• 미디어어: 1MB 3억건 * 0.9200바이트 + 3억건0.1*1mb(30TB/일) 5년간 미디어를 보관하기 위한 저장소 요구량 = 30TB * 365 * 5 = 약 55PB

팁

• 근사치를 활용해라
• 단위를 붙여라
• QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수등을 추정

단일 서버

모바일 앱에서 api.mysite.com에 접속했을때 일어어나는 flow는?

1. DNS에 요청 api.mysite.com의 IP주소를 얻어온다.
2. 해당 IP주소로 HTTP 요청을 전달
3. 요청을 받은 웹서버는 응답값을 HTML페이지나 JSON으로 응답
4. 응답값을 받은 클라이언트는 화면을 렌더링

데이터베이스

• Realational database(SQL)
  • MySQL, Oracle, PostgreSQL
  • 데이터를 열과 컬럼으로 표시, 조인으로 여러 데이터를 합칠 수 있다.
• Non realational database(NoSQL)
  • CouchDB, Cassandra, HBase, Amazon DynamoDB, MongoDB
  • 4가지 종류로 나뉜다. Key-value store, graph store, column store, document store

어떤 데이터베이스를 사용할 것인가?

특별한 요구사항이 없다면, RDB로. 이미 40년 이상 시장에서 검증 받아온 시스템. 하지만 다음과 같은 경우라면 비관계형 데이터베이스를 선택해야 한다.

• 아주 낮은 응답 지연시간이 요구됨
• 다루는 데이터가 형식이 정해져있지 않음.
• 데이터(JSON, XML, YAML 등)을 직렬화 하거나 역직렬화 할 수 있기만 하면 됨.
• 아주 많은 양의 데이터를 저장할 필요가 있음.

Scale up vs Scale out

• Scale up
  • 서버로 유입되는 트래픽이 적을때
  • 단순함 but 자동복구(Failover), 다중화(Redundancy)에 대한 해결책이 없다.

대규모 트래픽을 지원하는 애플리케이션에서는 Scale out이 적절한 방법이다. Scale out을 해가는 방법에 대해 살펴보겠다.

1. 로드밸런서 로드밸런싱 셋에 속한 서버들에게 트래픽 부하를 고르게 분산시켜주는 역할을 한다. 클라이언트는 서버에 직접 접속하는 게 아닌, 로드밸런서와 연결한다.

   • 웹서버 장애로 인한 fail over문제는 해결
   • 웹 계층의 가용성은 향상

2. 데이터베이스 다중화

   • 마스터, 슬레이브(Read only) 모델을 사용
   • 안정성(Realiabiliy), 가용성(Availabiliy) 향상

3. 캐시

   • 데이터베이스 부하를 줄인다. 캐시 사용시 유의해야할점

     캐시는 어떤 상황에 바람직한가? 갱신보다 참조가 빈번하게 일어날때 ㅡㅡㅡ 어떤 데이터를 캐시에 두어야 하는가? 영구저장할 필요가 없는 데이터 ㅡㅡㅡ expire 정책은? 너무 짧으면 db access가 늘어나므로 좋지 않다. ㅡㅡㅡ 일관성 있는 데이터 유지법 페이스북의 논문 Scaling Memcache at Facebook참고 ㅡㅡㅡ 캐시서버 장애시 대처방법은? SOF를 피해야한다. ㅡㅡㅡ 캐시 메모리는 얼마나 크게 잡을 것인가? 적게 잡는것보다 과할당을 하는것이 더 낫다. ㅡㅡㅡ 데이터 방출 정책은? 가장 많이 쓰이는 방식은 LRU(Least Recently Used)

   4. CDN 정적 콘텐츠를 전송하는데 쓰이는, 지리적으로 분산된 서버의 네트워크
      • 요청경로, 질의 문자열, 쿠키, 헤더값 정보에 기반하여 HTML페이지 캐싱

   CDN의 동작 순서

   1. 사용자 A가 CDN 서버로 image.png 요청
   2. CDN서버에 image.png가 없다면 원본 서버로 요청
   3. 원본서버는 http response에 TTL(얼마나 오래 캐시될수 있는지)값을 포함해서 반환
   4. CDN서버는 imgae.png를 캐시하고 사용자에게 반환
   5. 사용자 B가 CDN 서버로 image.png 요청
   6. CDN서버가 image.png 반환

CDN 사용시 고려해야할 점은?

 - 적절한 만료 시한 설정
     - 너무 길면 콘텐츠의 신선도는 떨어지고, 짧으면 원본 서버에 빈번하게 접속
 - 비용
      - CDN은 요금을 내고 제공하는 서비스를 이용하는 식. 전송 양에 따라 요금을 내게 되므로, 필요한 콘텐츠만 캐싱
 - 장애에 대한 대처 방안
      - CDN이 죽었을때 원본서버로 직접 요청할 수 있도록 고려
 - 콘텐츠 무효화 방법
   - CDN에서 제공해주는 API 사용
   - 오브젝트 버저닝 이용. ex) image.png

5. Stateless 웹 계층 이용

   • 사용자의 상태정보를 저장하는 서버는 따로 분리

6. 여러 지역의 데이터 센터 운영 기술적 난제 존재

   1. 트래픽 우회: 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야한다.

   2. 데이터 동기화: 장애가 났을시 특정 데이터 센터에는 찾는 데이터가 없을 수 있다.

      • 여러 데이터 센터에 걸쳐 다중화 하는것이 보편적인 전략

   3. 테스트와 배포

   4. 메시지 큐

• 비동기 통신을 지원하는 컴포넌트

• 시스템의 컴포넌트를 분리하여, 독립적으로 확장할 수 있도록 하기 위해 사용되는 핵심적 전략중 하나

• 서비스, 컴포터넌트간 결합이 느슨해져 규모 확장성을 보장되어야 하는 안정적 애플리케이션을 구성하기 좋다.

  8. 로그, 메트릭 그리고 자동화 로그: 여러 서버의 로그를 모아 모니터링은 필수 메트릭: 시스템 현재 상태 파악및 사업 현황에 관한 유용한 정보를 얻을 수 있다. 자동화: 생산성을 높이기 위해 자동화 도구는 필수

  9. 데이터베이스의 규모 확장 샤딩을 통한 scale out 활용

  • 샤딩은 대규모 데이터 베이스를 샤드라고 부르는 작은 단위로 분할하는 기술
  • 모든 샤드는 같은 스키마를 사용하지만, 데이터는 중복되지 않는다.
  • 가장 중요한건 샤딩 전략 즉 샤딩 키를 어떻게 설정할것인가이다.

  샤딩을 도입하면 생기는 복잡한 문제는?

  • 데이터의 재샤딩
    • 데이터가 너무 많아져서 하나의 샤드로 더이상 감당이 어려울때
    • 샤드간 데이터 분포가 균등하지 못할때 (샤드 소진 발생)
    • 샤드키를 계산하는 함수 변경 및 데이터 재배치 필요, 안정해시 기법 활용
  • 유명 인사 문제(hotspot key)
    • 특정 샤드에 질의가 집중되어 서버가 과부하가 걸리는 문제
  • 조인과 비정규화
    • 여러 샤드로 쪼개면 조인하기가 힘들어진다.
    • 데이터베이스를 비정규화 하는게 필요하다.

페이스북의 Ryan Mack이 타임라인 구현 스토리대해 말한 기고문이 있다. 해당 기고문에서 크게 5가지만 뽑자면 다음과 같다.

1. 새로운 것을 구축하는 대신 기존 인프라를 활용해라 당신은 페이스북이 타임라인을 위해 새로운 구조를 구축했을거라고 생각할 수 있지만, 그들은 이미 구축 되 있는 인프라를 사용했다.

• MySQL
• Multifeed(가까운 친구들의 업데이트 상황을 받아 볼 수 있는 시스템)
• Thrift
• Memcached
• Operations

기존 인프라위에서 그들은 오직 비즈니스 로직만 집중했고, 결국 6개월만에 완성 될 수 있었던 것이다.

2. 비정규화. 필요한 형태로 데이터를 포맷팅 해라

• 비정규화, 즉 필요해 맞는 테이블 생성(중복이 될지라도)으로 조인 쿼리의 감소와 데이터베이스 I/O를 최소화 시킬 수 있다. 비정규화 대신 캐싱을 사용할 수 도 있지만, 타임라인의 데이터는 방대하고 해당 데이터의 라이프 사이클을 측정할 수 없는 상황에서는 바람직하지 않다.

• 타임라인은 데이터를 메타데이터 토대로 랭킹을 매겨 순서에 따라 보여줘야 한다. 비정규화 프로세스는 모든 메타 데이터를 하나의 형태로 모아, 적은 I/O로 랭킹을 계산하고 PK range 쿼리로 데이터를 효율적으로 스트리밍 할 수 있다.

• 타임라인은 데이터웨어 하우스에 데이터마트와 같다. 수십 개의 서로 다른 시스템에서 데이터를 슬러핑 하여 정리하고 합쳐 새로운 표준 형식으로 다시 포맷해야 한다. 페이스북은 페이스북 방식으로 이것을 해냈다. 사용자 정의 데이터 변환 언어를 만들고, 기존 시스템에서 빠르게 데이터를 가져오기 위해 수백 대의 MySQL 서버를 배치하고 조인 속도를 높이기 위해 플래시 스토리지를 배치하고, 쿼리 프록시를 병렬화 시키고 향후 유연성을 위해 표준 Multifeed 데이터 포맷을 만들었다.

3. 다른 종류의 캐시를 이용해라

• Short term cache. 타임라인의 최근 활동은 계속해서 바뀐다. 이 캐시는 플래시 캐시 커널 드라이버를 사용하여 OS캐시를 플래시 장치로 확장하는 InnoDB내의 RAM row 캐시이다.

• Long term cache. 쿼리 캐시는 맴캐시에 저장된다. 2010년 활동의 랭킹을 보여달라는 빅 쿼리 같은 케이스는 결과가 거의 바뀔리가 없기 때문에 캐싱하면 효율적이다.

4. 지역적으로 운영해라 타임라인 집계기는 각각의 데이터베이스에서 돌아가기 때문에 디스크를 최대화 할 수 있다. 표시할 데이터만 네트워크를 통해 전송해라

5. 병렬적으로 개발해라 개발팀은 디자인, 프론트 앤드, 인프라, 데이터 마이그레이션으로 나누어 작업을 진행했다. 이와 동시에 테스트 백엔드의 UI 프로토타입, 시뮬레이션 백엔드의 프로덕션 UI, 확장 가능한 백엔드, 탈규격화 프레임워크, 데이터 웨어하우스 및 시뮬레이션 로드 테스트와 같이 구축되었다.

원문: 링크