🐢 12. System design & Scalability

규모 확장성 (scalability) 은 가장 쉬운 종류의 문제

⭐ 문제를 다루는 방법

• 소통하라 의사소통 능력을 평가하기 위함
• 처음에는 포괄적으로 접근하라 특정 부분을 과도하게 파고들지 말라
• 화이트보드를 사용하라 화이트보드에 제안하는 그림을 그리면서 설명해라
• 면접관이 우려하는 부분을 인정하라 면접관이 짚은 문제점을 인정하고 적절하게 수정해라
• 가정을 할 때 주의하라 잘못된 가정은 문제를 완전히 다르게 바꿔 버릴 수 있다
• 여러분이 생각하는 가정을 명확히 언급하라 면접관한테 가정할 것을 알리라
• 필요하다면 어림잡아 보라 필요한 공간이 얼마나 되는지 어림잡아 봐라
• 뛰어들라 장단점을 열린 마음으로 받아들라

최고의 설계를 해내는 것보다 대게 그 과정을 중요하게 본다

⭐ 시스템 설계: 단계적 접근법

1단계: 문제의 범위를 설정하라

만들고자 하는 시스템과 면접관이 원하는 것이 같은지 확실히 하기 위해 문제의 범위를 한정해라

• URL을 TinyURL로 축약
• URL을 분석
• TinyURL과 연결된 URL을 검색
• 사용자 계정 및 링크 관리

2단계: 합리적인 가정을 만들어라

가정을 세우는 것도 괜찮지만, 합당해야 한다

어떤 가정을 세우려면 “제품에 대한 감”이 있어야 할 수도 있다

3단계: 중요한 부분을 먼저 그려라

시스템의 주요한 부분을 다이어그램으로 그려라

시스템의 처음부터 마지막까지 어떻게 동작하는지 그 흐름을 보이아라

현재 단계에선 규모 확장성 문제를 무시해도 된다

4단계: 핵심 문제점을 찾으라

마음속에서 기본적인 설계를 마친 뒤에는 발생할 수 있는 핵심 문제에 집중해야 한다

어느 부분이 병목지점일까? 이 시스템이 풀어야 할 주된 문제는 무엇인가?

5단계: 핵심 문제점을 해결할 수 있도록 다시 설계하라

핵심 문제가 무엇인지 알아냈다면 이제는 그에 맞게 여러분의 설계를 수정해야 한다

다이어그램을 바뀐 설계에 맞게 수정하라

본인의 시스템에 존재하는 어떤 제약사항도 열린 마음으로 받아들일 수 있어야 한다

⭐ 규모 확장을 위한 알고리즘: 단계별 접근법

단순히 시스템 전체가 아닌 시스템의 한 부분 혹은 알고리즘을 설계해 보라는 요청을 받을 수도 있는데, 반드시 규모 확장성을 신경써라

1단계: 질문하라

초반에는 문제를 제대로 이해했는지 확인하기 위한 질문 시간이 필요하다

2단계: 현실적 제약을 무시하라

메모리 제약이 없고, 컴퓨터 한 대에서 모든 데이터를 다 처리할 수 있다고 가정해보라

3단계: 현실로 돌아오라

어떤 논리로 데이터를 나눌 것인가, 특정 컴퓨터가 어느 데이터 조각을 사용했는지 등 생각해봐라

4단계: 문제를 풀어라

상황에 따라 문제점 자체를 완전히 해결할 수도 있고, 그 수준을 완화시키는 데 그칠 수도 있다

순환적 접근법이 일반적으로 유용하다! 어떤 문제를 해결하면, 또 다른 문제가 발생하고, 그 문제를 다시 해결해 나가고를 반복하는 작업이다

문제를 분석하고 풀 수 있는 능력을 입증하라

⭐ 시스템 설계의 핵심 개념

시스템 설계 문제가 무엇을 알고 있는지 확인하는 문제는 아니지만, 특정 개념을 알고 있으면 문제를 더 쉽게 풀 수 있다

수평적(horizontal) vs. 수직적(vertical) 규모 확장

• 수직적 규모 확장: 특정 노드의 자원의 양을 늘리는 방법
• 수평적 규모 확장: 노드의 개수를 늘리는 방법

서버 부하 분산 장치(load balancer)

• 서버에 걸리는 부하를 여러 대의 서버에 균일하게 분산시킬 수 있고 서버 한 대 때문에 전체 시스템이 죽거나 다운되는 상황을 방지할 수 있다
• 서버 여러 대가 근본적으로 똑같은 코드와 데이터를 사용하도록 하는 네트워크를 구현해놔야 한다

데이터베이스 역정규화(denormalization)와 NoSQL

• SQL 같은 관계형 데이터베이스의 조인 연산은 시스템이 커질수록 굉장히 느려진다
• 역정규화가 이런것들 중 하나다
• 역정규화란 데이터베이스에 여분의 정보를 추가해서 읽기 연산 속도를 향상시킨 것을 의미한다
• 두 테이블을 조인하기보단 정보를 추가로 저장해 더 빠르게 작업을 수행할 수 있다
• NoSQL은 join 연산 자체가 없어 규모 확장성이 좋도록 설계되어 있다

⭐ 데이터베이스 분할(샤딩)

샤딩(sharding)은 데이터를 여러 컴퓨터에 나눠서 저장하는 동시에 어떤 데이터가 어떤 컴퓨터에 저장되어 있는지 알 수 있는 방식

• 수직적 분할(vertical partitioning)
  • 자료의 특성별로 분할하는 방식
  • 한 가지 단점은 특정 테이블의 크기가 일정 수준 이상이 되면 데이터베이스를 다른 방식으로 재분할해야 할 수도 있다
• 키 & 해시 기반 분할
  • mod(key, n) 의 값을 N개의 서버에 분할 저장하면 된다
  • 한 가지 문제점은 서버의 개수가 사실상 고정되어 있어야 한다
  • 서버를 새로 추가할 때 마다 모든 데이터를 다시 재분배해야 한다
• 디렉터리 기반 분할
  • 데이터를 찾을 때 사용되는 조회 테이블(lookup table)을 유지하는 방법
  • 상대적으로 서버를 추가하기 쉽지만, 두가지 심각한 단점이 있따
    • 조회 테이블이 단일 장애 지점이 될 수 있다
    • 지속적으로 테이블을 읽는 행위가 전체 성능에 영향을 미칠 수 있다

⭐ 캐싱(caching)

• 인메모리 캐시를 이용해 결과를 빠르게 가져올 수 있다
  • 메모리 캐시는 key-value 쌍으로 갖는 간단한 구조이다
• 일반적으로 애플리케이션, 데이터 저장소 사이에 자리잡고 있다
• 애플리케이션이 어떤 자료를 요청하면 캐시를 먼저 확인한다
  • 캐시가 해당 키값을 갖고 있지 않으면 그때 데이터 저장소를 확인한다

⭐ 비동기식 처리 & 큐

• 이상적이라면, 속도가 느린 연산은 비동기식(asynchronous)으로 처리해야 한다
• 그렇지 않으면 해당 연산이 끝나기까지 하염없이 기다려야 한다
• 어떤 경우는 이 연산을 미리 해 놓을 수도 있다
• 작업이 끝나면 사용자에게 작업이 끝났다고 직접 알려 주기도 한다

⭐ 네트워크 성능 척도

• 대역폭(handwidth)
  • 단위 시간에 전송할 수 있는 데이터의 최대치
• 처리량(throughput)
  • 단위 시간에 실제로 전송된 데이터의 양
• 지연 속도(latency)
  • 데이터를 전송하는 데 걸리는 시간

⭐ MapReduce

• 굉장히 커다란 데이터를 처리하는데 사용된다
  • Map은 데이터를 입력으로 받은 뒤 <key, value> 쌍을 반환한다
  • Reduce 는 key와 관련 value 를 입력으로 받아 처리 과정을 거쳐 새로운 키값을 반환한다
  • 규모 확장이 수워진다

⭐ 시스템 설계 시 고려할 점

• 실패: 실패에 대한 대비책이 필요하다
• 가용성: 사용 가능한 시스템의 시간을 백분율로 나타낸 것
• 신뢰성: 특정 단위 시간에 시스템이 사용 가능할 확률로 나타낸 것
• 읽기 중심 vs 쓰기 중심: 쓰는 연산이 많다면 큐, 읽는 연산이 많다면 캐시
• 보안: 보안 위협은 시스템에 엄청난 해를 가한다 (설계해라)

⭐ 완벽한 시스템은 없다

• 완벽하게 동작하는 시스템 설계란 존재하지 않는다
• 끔찍한 시스템은 매우 많다
• 사례를 잘 이해하고, 문제의 범위를 설정하고, 합리적인 가정을 세운 뒤, 명확하게 설계한 시스템을 만들라