목차
1장은 1명의 사용자를 지원하는 서버에서 몇백만 사용자가 지원하는 서버로 설계하는 방법을 간단하게 풀었다.
단일 서버
간단한 단일 서버에선,
웹서버와 dns 서버(외부 서비스) 를 통해 구성했다.
데이터베이스
그다음 데이터베이스를 추가했다.
데이터베이스는 2가지로 분류한다.
관계형 데이터 베이스
비 관계형 데이터 베이스( key-value, graph, column, document)
책에서 추천하는 비관계형 데이터베이스를 선택할만한 사유로는 아래와 같다.
- 아주 낮은 응답 지연시간 요구
- 비정형 데이터
- 데이터를 직렬화, 역직렬화 할 수 있기만 하면 됨
- 많은 양의 데이터를 저장할 필요가 있음
아주 낮은 응답 지연시간은 일반적으로 단순한 조회를 뜻하는 듯 싶다.
구조가 간단하고, 조인이나 트랜잭션을 일반적으로 사용안하기 때문으로 보인다.
수직적 규모 확장 vs 수평적 규모 확장
스케일 업이라고 표현하는 수직적 규모 확장은 더 좋은 자원(CPU, RAM 등)으로 변경하는 것을 뜻한다.
스케일 아웃이라고 표현하는 수평적 규모 확장은 더 여러개의 자원을 사용하는 것을 뜻한다.
스케일업은 간단하단 장점 외에는 여러 단점이 존재한다.
- 더 좋은 자원으로 변경할 수 있는 한계가 있음.
- 자동복구 방안이나 다중화 방안을 제시하지 않음.
로드밸런서
수평적 확장을 위해선 로드밸런서가 필요하다.
로드 밸런서란 부하 분산을 위해 앞단에서 요청을 받고 어떤 서버에게 요청을 맡길것인지 분산하는 역할을 한다.
대부분 구조는 public ip 기반의 로드밸런서에 요청하면,
로드밸런서가 private ip를 이용한 서버 계층에 전달한다. ( 보안을 위해 )
이렇게 되면 스케일업의 단점이였던 자동복구 못하던 문제가 해결되고 가용성이 향상된다.
예를 들어, 웹 서버 1이 문제가 생기면 로드 밸런서가 파악하고 웹 서버 2로 트래픽을 맡긴다.
기본적인 정책으론 round robin으로 순서대로 요청하게 된다.
[ Least Outstanding Requests (가장 적은 대기 요청) , Source IP Hash (고정 라우팅 / 세션 고정), route53의 Weighted Routing (가중치 기반 라우팅) 도 있음 ]
로드밸런서가 서버에 문제가 생겼는지 체크하는 일반적인 방법은 헬스체크다.
서버에 health 체크를 할만한 api를 구현해두고 해당 url이 어떻게 답변 오는지에 따라 상태를 체크한다.
( 정상응답, 응답시간 등등)
데이터베이스의 다중화
데이터 베이스도 다중화가 가능하다.
보통은 주(master)-부(slave)를 두고 데이터 원본을 master에, 사본을 slave에 저장하는 방식이다.
해당 다중화 방식에선 쓰기는 master에만 지원한다.
slave는 master로부터 사본을 전달받으며, 읽기 연산을 지원한다.
대체적으로 데이터베이스는 읽기 연산이 많아서 master보다 slave 수가 많다.
cqrs 패턴을 통해 쓰기는 master로 읽기는 slave로 처리하면,
구조적으로도 안정적이고 성능도 챙길 수 있다.
만약 master가 장애가 발생 시, slave가 master로 변경되는 장애복구 정책을 통해 해결이 가능하다.
aws의 db들의 경우, 관리형 db이기 때문에 동기화 정책은 수정이 불가능하다.
캐싱
캐시는 값비싼 연산 결과 또는 자주 참조되는 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소다.
사용할 때 유의할점으론,
- 영속적으로 보관할 데이터 x. 휘발성 데이터 o
- 만료 정책
- 원본과 캐시간의 일관성 유지
- 캐시 서버 장애 대응
- 캐시 메모리 설정 ( 작으면, 데이터가 캐시에서 밀려나게 되고 성능이 떨어짐 )
- 데이터 방출 정책 ( LRU, LFU, FIFO )
콘텐츠 전송 네트워크(CDN)
정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크다.
이미지, 비디오, css, javascript 파일 등을 캐시할 수 있다.
cdn 캐싱을 통해 응답 시간을 개선할 수 있다. (글로벌 기업이라면, 더더욱)
무상태 웹 계층
상태 정보 같은건 웹 계층에서 제거하고, 공유 저장소에 저장하여 사용자가 어떤 서버로 요청하더라도 처리할 수 있도록 한다.
데이터 센터
클라우드 서비스의 리소스나 데이터베이스를 사용할 때, 실제적인 물리적인 리소스를 지원하는 지역이 있을텐데
해당 물리적 리소스의 위치를 2개 이상으로 처리해야 특정 지역에 문제가 생겼을 때 장애 대응이 된다.
메세지 큐
메세지 큐는 비동기 통신을 사용할 때 자주 사용하는 컴포넌트이다.
메세지 큐를 이용하여 서버 간 결합도를 느슨하게 만들고, 규모 확장성이 보장되어야하는 안정적 어플리케이션을 구성하기 좋다.
msa 아키텍처같은곳에서 많이 사용한다.
로그, 메트릭 그리고 자동화
뭐.. 별 얘기 없다.
규모가 커질 수록 로그, 메트릭, 자동화는 중요하다는 이야기..
데이터베이스의 수평적 확장
수평적 확장으로는 샤딩에 대한 이야기가 나온다.
샤드 단위로 작은 단위로 분할하는 것과 샤딩 키 전략을 어떻게 할지에 대한 이야기.
샤딩 도입시 문제점들
- 데이터 재 샤딩
- 유명인사
- 조인과 반정규화
댓글