[IT 도서 리뷰] 가상 면접 사례로 배우는 대규모 시스템 설계 기초(5장 ~ 8장)

책 정보

---

 

https://www.yes24.com/Product/Goods/102819435

가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 예스24

5장 안정 해시 설계

---

• 수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요
  • 안정 해시는 이 목표를 달성하기 위해 보편적으로 사용하는 기술
• 해시 키 재배치(rehash) 문제
  • N개의 캐시 서버가 있을 때 이 서버들에 부하를 균등하게 나누는 보편적인 방법은 해시 함수를 사용
    • serverIndex = hash(key) % N
  • 이 방법은 서버 풀의 크기가 고정되어 있을 때, 데이터 분포가 균등할 때는 잘 동작 
  • But, 서버가 추가되거나 기존 서버가 삭제되면 문제 발생
• 안정 해시
  • 해시 테이블 크기가 조정될 때 평균적으로 오직 k/n개의 키만 재배치하는 해시 기술
  • 히시 공간과 해시링
  • 기본 구현법의 두 가지 문제
    • 기본 구현법
      • 서버와 키를 균등 분포 해시 함수를 사용해 해시 링에 배치한다.
      • 키의 위치에서 링을 시계 방향으로 탐색하다 만나는 최초의 서버가 키가 저장될 서버다.
    • 두 가지 문제
      • 서버가 추가되거나 삭제되는 상황을 감안하면 파티션의 크기를 균등하게 유지하는 것이 불가능
      • 키의 균등 분포를 달성하기가 어려움
  • 가상 노드
    • 가상 노드는 실제 노드 또는 서버를 가리키는 노드
    • 가상 노드의 개수를 늘리면 표준 편차가  작아져서 데이터가 고르게 분포됨
  • 재배치할 키 결정
• 마치며
  • 안정 해시의 이점
    • 서버가 추가되거나 삭제될 때 재배치되는 키의 수가 최소화
    • 데이터가 보다 균등하게 분포하게 되므로 수평적 규모 확장성을 달성하기 쉽다.
    • 핫스팟 키 문제를 줄인다.

6장 키-값 저장소 설계

---

• 키-값 저장소는 비 관계형 데이터베이스
  • 이 저장소에 저장되는 값은 고유 식별자를 키로 가져야 함
  • 키-값 쌍에서 키는 유일해야 하며 해당 키에 매달린 값은 키를 통해서만 접근할 수 있다.
  • 값은 문자열일 수도 리스트일 수도 객체일 수도 있음
  • put(key, value): 키-값 쌍을 저장소에 저장한다.
  • get(key): 인자로 주어진 키에 매달린 값을 꺼낸다.
• 문제 이해 및 설계 범위 확정
  • 키-값 쌍의 크기는 10KB 이하
  • 큰 데이터 저장
  • 높은 가용성
  • 높은 규모 확장성
  • 데이터 일관성 수준은 조정 가능
  • 응답 지연시간이 짧아야 함
• 단일 서버 키-값 저장소
  • 가장 직관적인 방법은 키-값 전부를 해시 테이블로 저장
  • 빠른 속도를 보장하지만 모든 데이터를 메모리 안에 두는 것이 불가능할 수도 있다는 약점
  • 개선책
    • 데이터 압축
    • 자주 쓰이는 데이터만 메모리에 두고 나머지는 디스크에 저장
• 분산 키-값 저장소
  • 분산 시스템을 설계할 때는 CAP 정리를 이해하고 있어야 함
  • CAP 정리 : Consistency(일관성), Availability(가용성), Partition tolerance(파티션 감내)라는 세 가지 요구사항을 동시에 만족하는 분산 시스템을 설계하는 것은 불가능
  • 데이터 일관성: 분산 시스템에 접속하는 모든 클라이언트는 어떤 노드에 접속했느냐에 관계없이 언제나 같은 데이터를 보게 되어야 한다.
  • 가용성: 분산 시스템에 접속하는 클라이언트는 일부 노드에 장애가 발생하더라도 항상 응답을 받을 수 있어야 한다.
  • 파티션 감내: 파티션은 두 노드 사이에 통신 장애가 발생하였음을 의미한다. 파티션 감내는 네트워크에 파티션이 생기더라도 시스템을 계속 동작하여야 한다는 것을 뜻한다.
• 시스템 컴포넌트
  • 데이터 파티션: 데이터를 작은 파티션들로 분할한 다음 여러 대 서버에 저장하는 것
    • 중요한 문제 2가지
      • 데이터를 여러 서버에 고르게 분산할 수 있는가
      • 노드가 추가되거나 삭제될 때 데이터의 이동을 최소화할 수 있는가
    • 안정해시 활용
      • 좋은점 2가지
        • 규모 확장 자동화: 시스템 부하에 따라 서버가 자동으로 추가되거나 삭제되도록 만들 수 있음
        • 다양성: 각 서버의 용량에 맞게 가상 노드의 수를 조정할 수 있다.
  • 데이터 다중화
    • 높은 가용성과 안정성을 확보하기 위해서는 데이터를 N개 서버에 비동기적으로 다중화할 필요가 있음
    • 시계방향으로 만나는 첫 N개 서버에 데이터 사본 보관
  • 데이터 일관성
    • 다중화된 데이터는 적절히 동기화가 되어야 함
  • 시스템 아키텍처 다이어그램

7장 분산 시스템을 위한 유일 ID 생성기 설계

---

• 1단계 문제 이해 및 설계 범위 확정
  • ID는 유일해야 한다.
  • ID는 숫자로만 구성되어야 한다.
  • ID는 64비트로 표현될 수 있는 값이어야 한다.
  • ID는 발급 날짜에 따라 정렬 가능해야 한다.
  • 초당 10,000개의 ID를 만들 수 있어야 한다.
• 2단계 개략적 설계안 제시 및 동의 구하기
  • 다중 마스터 복제
  • UUID
  • 티켓 서버
  • 트위터 스노우플레이크 접근법
    • 생성해야 하는 ID의 구조를 여러 절로 분할
    • 사인 비트, 타임스탬프, 데이터센터 ID, 서버 ID, 일련번호
• 3단계 상세 설계
  • 타임스탬프: 최대값은 69년
  • 일련번호 : 4096개
• 4단계 마무리
  • 시계 동기화
  • 각 절의 길이 최적화
  • 고가용성

8장 URL 단축기 설계

---

• 1단계 문제 이해 및 설계 범위 확정
  
  • 주어진 긴 URL을 훨씬 짧게 줄인다.
  • URL 리디렉션: 축약된 URL로 HTTP 요청이 오면 원래 URL로 안내
  • 높은 가용성과 규모 확장성, 그리고 장애 감내가 요구됨
  • 개략적 추정
    • 쓰기 연산: 매일 1억 개의 단축 URL 생성
    • 초당 쓰기 연산: 1억(100milion)/24/3600=1160
    • 읽기 연산: 읽기 연산과 쓰기 연산 비율이 10:1이면 초당 11,600회
    • URL 단축 서비스를 10년간 운영한다고 가정하면 1억 X 365 X 10 = 3650억
    • 축약 전 URL의 평균 길이는 100
    • 10년동안 필요한 저장 용량은 36.5TB
• 2단계 개략적 설계안 제시 및 동의 구하기
  • API 엔드포인트
    • URL 단축용 엔드포인트: 새 단축 URL을 생성하고자 하는 클라이언트는 이 엔드포인트에 단축할 URL을 인자로 실어서 POST 요청을 보내야 함.
    • URL 리디렉션용 엔드포인트: 단축 URL에 대해서 HTTP 요청이 오면 원래 URL로 보내주기 위한 용도의 엔드포인트.
  • URL 리디렉션
    • 단축 URL을 받은 서버는 그 URL을 원래 URL로 바꾸어서 301 응답의 Location 헤더에 넣어 반환
    • 301 Permanently Moved
      • 해당 URL에 대한 HTTP 요청의 처리 책임이 영구적으로 Location 헤더에 반환된 URL로 이전되었다는 응답
    • 302 Found
      • 주어진 URL로의 요청이 '일시적으로' Location 헤더가 지정하는 URL에 의해 처리되어야 한다는 응답
  • URL 단축
    • 중요한 것은 긴 URL을 해시 값으로 대응시킬 해시 함수 fx를 찾는 일
    • 요구사항
      • 입력으로 주어지는 긴 URL이 다른 값이면 해시 값도 달라야 한다.
      • 계산된 해시 값은 원래 입력으로 주어졌던 긴 URL로 복원될 수 있어야 한다.
• 3단계 상세 설계
  • 데이터 모델
    • 메모리는 유한하며 비싸서 모든 것을 해시 테이블에 두기는 힘듦
    • 더 나은 방법은 관계형 데이터베이스에 저장
  • 해시 함수
    • n=7이면 3.5조 개의 URL을 만들 수 있음
    • 해시 후 충돌 해소
      • 손쉬운 방법은 CRC32, MD5, SHA-1같이 잘 알려진 해시 함수를 이용
    • base-62 변환
      • 62진법을 쓰는 이유는 hashValue에 사용할 수 있는 문자 개수가 62개이기 때문.
  • URL 단축기 상세 설계
  • URL 리디렉션 상세 설계
• 4단계 마무리
  • 처리율 제한 장치
  • 웹 서버의 규모 확장
  • 데이터베이스의 규모 확장
  • 데이터 분석 솔루션