Scalability
1 Scalability
- 한 명의 사용자를 지원하는 시스템에서 시작해서 몇백만 사용자를 지원하는 시스템을 설계해보자
1.1 시스템 규모 확장 기법
- 시스템 규모 확장 기법을 요약하면 아래와 같다
- 웹 계층은 무상태 계층으로
- 모든 계층에 다중화를 도입
- 가능한 많은 데이터를 캐시할 것
- 여러 데이터 센터를 지원할 것
- 정적 콘텐츠를 CDN을 통해 서비스 할 것
- 데이터 계층은 샤딩을 통해 규모를 확장할 것
- 각 계층은 독립적 서비스로 분할할 것
- 시스템을 지속적으로 모니터링하고 자동화 도구들을 활용할 것
2 Scale up
- 특정 노드의 고사양 자원의 양을 늘리는 방법을 말한다
- 예를 들어 서버에 메모리를 추가해서 서버의 처리 능력을 향상시킬 수 있다
- 대규모 서비스에서는 Scale up의 단점으로 인해 사용하지 않는다
2.1 장점
- 서버로 유입되는 트래픽의 양이 적을 때 좋은 선택이 된다
- Scale up 일반적으로 Scale out 보다 구현하기 쉽다
2.2 단점
- 수직적 규모 확장에는 한계가 있다
- 한 대의 서버에 CPU와 메모리를 무한대로 증설할 방법은 없다
- 자동복구 방안이나 다중화 방안을 제시하지 않는다
- 서버에 장애가 발생하면 모든 서비스가 완전히 중단된다
- SPOF로 인한 위험성이 크다
- 비용이 많이 든다
- 고성능 서버로 갈수록 가격이 올라가기 마련이다.
3 Scale out
- 노드의 개수를 늘리는 방법을 말한다
- 서버를 추가하므로써 서버 한 대가 다뤄야 하는 부하를 줄일 수 있다
3.1 장점
- 여러개의 서버를 두어 한 서버에 장애가 발생해도 모든 서비스가 중단되지 않는다
- SPOF로 인한 위험성이 낮다
3.2 단점
- Scale out 일반적으로 Scale up 보다 구현하기 어렵다.
4 웹 계층 다중화
- 웹 계층의 수평적 규모 확장을 위해 로드밸런서를 사용한다
4.1 로드밸런서
- 로드밸런서는 부하 분산 집합에 속한 웹 서버들에게 트래픽을 고르게 분산하는 역할을 한다.
- 웹 서버는 클라이언트의 접속을 집적 처리하지 않는다.
- 더 나은 보안을 위해 서버 간 통신(로드밸런서와 웹 서버)에는 사설 IP 주소를 이용한다.
가용성
- 부하 분산 집합에 웹 서버를 추가하면 가용성이 향상된다
- 서버 하나가 다운되면 모든 트랙픽은 다른 서버로 전송되므로 웹 사이트 전체가 다운되는 일이 방지된다
부하 분산
- 부하를 나누기 위해 새로운 서버를 부하 분산 집합에 추가할 수 있다
- 트래픽이 가파르게 증가할 때 서버를 증설하면 로드밸런서가 자동으로 트래픽을 분산한다
4.2 Stateless 웹 계층
- 웹 계층을 수평적으로 확장하기 위해서는 상태 정보(사용자 세션 데이터 등)를 웹 계층에서 제거해야 한다
- 바람직한 전략은 상태 정보를 관계형 데이터베이스나 NoSQL 같은 지속성 저장소에 보관하고 필요할 때 가져오는 것이다
- 이렇게 구성된 웹 계층을
무상태 웹 계층이라고 한다
장점
- 웹 서버에는 상태가 없기 때문에 사용자 A의 요청을 어떤 웹 서버로도 전달할 수 있다
- 상태 정보가 필요한 경우 공유 저장소로 부터 데이터를 가져올 수 있다
4.3 Stateful 웹 계층
- 상태 정보를 보관하는 서버는 클라이언트의 정보(상태)를 유지하여 요청들 사이에 공유되도록 한다
단점
- 사용자 A의 세션 정보가 서버1에 저장되어 있을 때 이후 요청은 반드시 서버1로 전송되어야 한다
- 즉 같은 클라이언트의 요청은 항상 같은 서버로 전송되어야 한다
- 대부분의 로드밸런서가 이를 지원하기 위해 고정 세션(sticky session)이라는 기능을 제공하지만 이는 로드밸런서에 큰 부담을 준다
- 로드밸런서에 서버를 추가하거나 제거하기 까다로워진다
5 데이터베이스 다중화
- 웹 계층의 다중화는 로드밸런서를 통해 얻을 수 있다. 그렇다면 데이터베이스의 다중화는 어떻게 얻을 수 있을까?
- 많은 DBMS는 다중화를 지원한다
- 보통은 서버 사이에 master와 slave 관계를 설정하고 데이터 원본은 master에 사본은 slave에 저장하는 방식이다
- 대부분의 애플리케이션은 읽기 연산의 비중이 쓰기 연산의 비중보다 훨씬 높다
- 따라서 slave 데이터베이스의 수가 master 데이터베이스의 수보다 많다
5.1 master
- 쓰기 연산은 마스터에서만 지원한다
- 데이터베이스를 변경하는 insert, delete, update 명령어들은 마스터 데이터베이스로만 전달되어야 한다
5.2 slave
- 읽기 연산을 지원한다
- 마스터로 부터 사본을 전달 받는다
5.3 장점
- 모든 데이터 변경은 마스터 서버로만 전달되며 읽기 연산은 slave 데이터베이스로 전달되므로 병렬로 처리될 수 있는 쿼리의 수가 늘어나므로 성능이 좋아진다
- 자연 재해 등의 이유로 데이터베이스 서버 가운데 일부가 파괴되어도 데이터가 보존된다
- 하나의 서버에 장애가 발생하도 다른 서버의 데이터를 가져올 수 있으므로 가용성이 확보된다
5.4 가용성
- 부 서버가 한 대 뿐인데 다운된 경우 읽기 연산은 한시적으로 모두 주 데이터베이스로 전달된다
- 여러 부 서버 중 하나다 다운된 경우 다른 부 서버로 읽기 연산이 분산된다
- 마스터 서버가 다운되고 한 대의 부 서버가 존재하는 경우 해당 부 서버가 새로운 마스터 서버가 되며 모든 데이터베이스 연산이 일시적으로 새로운 마스터 서버에서 수행될 것이다.
- 그리고 새로운 부 서버가 추가될 것이다.
6 캐시
- 웹 계층과 데이터 계층에 대한 다중화에대해서 알아보았다. 이제 응답시간을 개선해보자.
- 응답 시간은 캐시를 붙이고 정적 콘텐츠를 CNS으로 옮기면 개선할 수 있다.
- [[System-Design/Cache/Cache]] 참고
7 메시지 큐
- 메시지 큐는 메시지의 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트다
- 메시지의 버퍼 역할을 하며 비동기적으로 전송한다
- 생산자 또는 발행자라고 불리는 입력 서비스가 메시지를 만들어 메시지 큐에 발행한다
- 큐에는 보통 소비자 혹은 구독자라 불리는 서비스 혹은 서버가 연결되어 있는데 메시지를 받아 그에 맞는 동작을 수행한다
- 메시지 큐를 사용하면 서비스 또는 서버 간 결합이 느슨해져 규모 확장성면에서 좋다
- 생산자는 소비자 프로세스가 다운되어도 메시지를 발행할 수 있고 반대도 마찬가지다
8 로그, 메트릭 그리고 자동화
- 소규모 프로젝트에는 로그나 메트릭 자동화 같은 것은 하면 좋지만 필수는 아니다
- 하지만 규모가 커지면 이런 도구가 필수적으로 필요하다
8.1 로그
- 에러 로그를 모니터링 하는 것은 중요하다
- 에러 러그는 서버 단위로 모니터링 할 수 있지만 로그를 단일 서버스로 모아주는 도구를 활용하면 편리하게 검색하고 조회할 수 있다
8.2 메트릭
- 메트릭을 잘 수집하면 유용한 정보를 얻을 수 있다.
- 호스트 단위 메트릭
- CPU, 메모리, 디스크 I/O
- 종합 메트릭
- 데이터베이스의 계층의 성능, 캐시 계층의 성능
- 핵심 비즈니스 메트릭
- 일별 능동 사용자, 수익, 재방문 등
8.3 자동화
- 지속적 통합을 도와주는 도구를 활용하면 개발자가 만드는 코드가 어떤 검증 절차를 자동으로 거치도록 할 수 있다
- 이 외에도 빌드, 테스트, 배포 등의 절차를 자동화할 수 있어서 개발 생산성을 크게 향샹시킬 수 있다
9 데이터베이스의 규모 확장
- 데이터베이스의 규모를 확장하는 데는 두 가지 접근법이 있다
- Scale Up(수직적 확장)
- Scale Out(수평적 확장)
9.1 Scale Up
- Sacle Up은 기존 서버에 더 많은 고성능 자원을 증설하는 방법이다
- 가령 아마존에는 24TB 램을 가진 서버도 상품으로 제공한다
- 스택오버플로는 한 해 동안 천만 명의 사용자 전부를 단 한대의 마스터 데이터베이스로 처리했다
9.2 Scale Out
- 데이터베이스의 수평적 확장은 샤딩이라고 부른다
- 샤딩은 대규모 데이터베이스를 샤드라는 작은 단위로 분할하는 기술을 일컫는다
- 모든 샤드는 같은 스키마를 쓰지만 샤드에 보관된 데이터 사이에는 중복이 없다
참고