🦊 12. System design & Scalability

12. System design & Scalability

문제를 다루는 방법

• 소통하라
• 처음에는 포괄적으로 접근하라
• 화이트보드를 사용하라
• 면접관이 우려하는 부분을 인정하라
• 가정을 할 때 주의하라
• 여러분이 생각하는 가정을 명확히 언급하라
• 필요하다면 어림잡아 보라
• 뛰어들라

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

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

TinyURL 과 같은 시스템 설계에서, 실제 설계에 들어가기전 하고 싶은 질문이 많을 것이다.

면접에서도 이런 방식으로 문제에 접근해야 한다.

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

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

예를 들어 TinyURL 은 아마도 다음과 같은 특징이 있다.

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

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

필요하다면 가정을 세우는 것도 괜찮지만, 합당해야 한다.

이런 가정을 통해 얼마나 많은 데이터를 저장해야 하는지 계산해 볼 수 있다.

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

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

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

그 시스템이 어떻게 생겼는지 그림으로 그려라.

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

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

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

어떤 URL은 드물게 사용되는 반면 특정한 URL의 사용량이 갑자기 치솟는 경우가 있을 수도 있다.

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

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

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

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

시스템 전체가 아닌 시스템의 한 부분 혹은 알고리즘을 설계해 보라는 요청을 받을 수도 있다.

이때도 반드시 규모 확장성을 신경 써야 한다.

1단계: 질문하라

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

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

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

3단계: 현실로 돌아오라

다시 원래 문제로 돌아와서 컴퓨터 한 대에 저장할 수 있는 데이터의 크기는 얼마나 되고, 데이터를 여러 조각으로 쪼갰을 때 어떤 문제가 발생할지 생각해 보라.

4단계: 문제를 풀어라

발견한 문제점들을 어떻게 해결할지 생각해 보야 한다.

순환적 접근법이 일반적으로 유용하다.

어떤 문제를 해결하면, 또 다른 문제가 발생하고, 그 문제를 다시 해결해 나가고를 반복하는 작업이다.

시스템 설계의 핵심 개념

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

• 수직적 규모 확장: 특정 노드의 자원의 양을 늘리는 방법 (서버의 메모리 추가)
• 수평적 규모 확장: 노드의 개수를 늘리는 방법 (서버를 추가 → 부하를 줄임)

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

서버에 걸리는 부하를 여러 대의 서버에 균일하게 분산시킬 수 있고 서버 한 대 때문에 전체 시스템이 죽거나 다운되는 상황을 방지할 수 있다

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

RDB의 join 연산은 시스템이 커질수록 굉장히 느려진다.

역정규화는 데이터베이스에 여분의 정보를 추가해서 읽기 연산 속도를 향상시킨다.

두 테이블을 조인하기보단 정보를 추가로 저장해 더 빠르게 작업을 수행할 수 있다.

NoSQL은 join 연산 자체가 없어 규모 확장성이 좋도록 설계되어 있다

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

샤딩(sharding)은 데이터를 여러 컴퓨터에 나눠서 저장하는 동시에

어떤 데이터가 어떤 컴퓨터에 저장되어 있는지 알 수 있는 방식이다.

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

캐싱(caching)

인메모리 캐시를 이용해 결과를 빠르게 가져올 수 있다.

메모리 캐시는 key-value 쌍으로 갖는 간단한 구조이다.

비동기식 처리 & 큐

속도가 느린 연산은 비동기식(asynchronous)으로 처리해야 한다.

또는 이 연산을 미리 해 놓을 수도 있다.

이런 웹사이트는 어떤 부분을 사용 가능으로 바꿔 놓고, 데이터를 가져오는데 얼마나 소요되는지 알려주며 작업이 끝나면 알림을 보내 준다.

네트워크 성능 척도

• 대역폭
• 처리량
• 지연 속도

지연 시간은 무시되기 쉽지만 온라인 게임에선 지연 시간이 아주 중요하다.

MapReduce

굉장히 커다란 데이터를 처리하는데 사용된다.

• Map은 데이터를 입력으로 받은 뒤 <key, value> 쌍을 반환한다.
• Reduce 는 key와 관련 value 를 입력으로 받아 처리 과정을 거쳐 새로운 키값을 반환한다

시스템 설계 시 고려할 점

• 실패: 실패에 대한 대비책이 필요
• 가용성: 사용 가능한 시스템의 시간
• 신뢰성: 특정 단위 시간에 시스템이 사용 가능할 확률
• 읽기 중심 vs. 쓰기 중심: 쓰는 연산이 많다면 큐, 읽는 연산이 많다면 캐시가 좋을 수 있다
• 보안

완벽한 시스템은 없다

완벽하게 동작하는 시스템 설계란 존재하지 않는다.

모든 시스템에는 장단점이 존재한다.