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

대규모 시스템 설계는 처음부터 몇백만 유저를 고려하여 설계하기보다 단일 시스템에서 발전시켜 나가는 방향으로 해야 한다. 첫 번째 장은 규모 확장성과 관계된 설계 문제를 푸는데 유용한 지식들에 대해 알아볼 것이다.

단일 서버

모든 컴포넌트, 캐시, 데이터베이스, was등이 전부 서버 한대에서 실행된다.

모바일 앱에서 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. 테스트와 배포

7. 메시지 큐

   • 비동기 통신을 지원하는 컴포넌트
   • 시스템의 컴포넌트를 분리하여, 독립적으로 확장할 수 있도록 하기 위해 사용되는 핵심적 전략중 하나
   • 서비스, 컴포터넌트간 결합이 느슨해져 규모 확장성을 보장되어야 하는 안정적 애플리케이션을 구성하기 좋다.

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

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

   • 샤딩은 대규모 데이터 베이스를 샤드라고 부르는 작은 단위로 분할하는 기술

   • 모든 샤드는 같은 스키마를 사용하지만, 데이터는 중복되지 않는다.

   • 가장 중요한건 샤딩 전략 즉 샤딩 키를 어떻게 설정할것인가이다.

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

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