Building for Scale에 대해서 알아보자. 책 "가상 면접 사례로 배우는 대규모 시스템 설계 기초"를 참고하여 전반적인 내용을 작성해보려고한다. 모든 내용을 다루다기보단, 몰랐었던 부분 그리고 중요하다고 생각하는 부분을 간략하게 정리하고자한다. 공부한 내용을 간단히 정리하는 식으로 머리속에 저장하는 겸 작성할 예정이다.
사용자수에 따른 규모 확장성
: 사용자들에게 서비스를 제공하기 위한 시스템을 생각해보자. 일단, 가장 간단한 구성인 단일 서버라고 가정하면 DNS-클라이언트-웹서버-데이터베이스이 서버를 구성하는 가장 큰 요소들로 생각할 수 있다.
이러한, 서버를 하드웨어적으로 확장시키는 방법은 두가지가 있다. 첫번째는 서버를 구동하는 하드웨어를 업그레이드하는 Scale up 방법이다. 이는 다중화 및 서버에 장애가 발생할시에 서비스를 이용할 수 없다는 단점을 가지고 있다. 따라서, 트래픽이 적은 서비스를 이용할 때 적합한 확장 방법이다. 두번째로는 서버를 수평적으로 추가하는 Scale Out 방법이다. 이러한 Scale Out은 로드밸런서 또는 부하분산기를 활용하여 많은 사용자가 몰려와도 서비스가 중지되지 않도록 유지한다.
그럼, 데이터베이스를 다중화하는 방법을 이야기해보자. 데이터베이스를 다중화하는 가장 흔한 방법은 주(master)-부(slave) 데이터베이스로 나눠 확장한다. 이는 더 나은 성능, 안전성, 가용성을 보장한다. 그 이유는 주(master) 데이터베이스에서는 쓰기 연산만을 담당하고 부(slave) 데이터베이스에서는 읽기 연산만을 담당하기 때문에 가능하다. 이를 통해, 하나의 데이터베이스 서버에서 문제가 생겨도 다른 데이터베이스 서버에서 데이터를 가져와 요청을 해결 할 수 있다.
하지만, 데이터베이스가 아무리 잘 관리가 된다고 하여도 모든 요청에 따라 데이터베이스 서버를 접근하여 필요한 데이터를 가져오게 된다. 따라서, 우리는 캐시라는 것을 활용한다. 캐시는 빈번히 요청이 일어나는 데이터를 메모리에 저장하는 저장소라고 생각하면 된다. 즉, 웹서버-데이터베이스 관계가 캐시를 이용하면 웹서버-캐시서버-데이터베이스 관계로 더 빠르게 자주 일어나는 요청에 따른 데이터를 전달 할 수 있게 된다. 하지만 이러한 캐시서버도 고려를 해야될 사항들이 많다. 예를 들자면, 중요 데이터는 지속적 저장소에 두어야 된다는 점, 단일 캐시 서버를 두게된다면 SPOF가 될 수 있다는 점이 대표적 고려사항이 될 수 있다. 또한, 캐시 메모리의 과할당을 조심해야하고, 캐시 데이터 방출 정책을 잘 관리해야한다.
이러한 캐시 서버와 같은 느낌으로 콘텐츠를 저장하는 서버를 CDN이라고한다. 특정한 컨텐츠에 대해서 첫 요청을 했다고 생각해보자. 사용자가 요청한 데이터를 웹서버를 통해서 원본 서버로 콘텐츠를 요청하고 이를 CDN에 저장한다. 이후 같은 요청이 오게되면 원본 서버를 통하지 않고 CDN에 있는 콘텐츠를 전달한다. 이를 통해서 원본 서버에 같은 컨텐츠를 요구하는 요청에 대해서 효과적으로 관리할 수 있고, 또한 요청자와 가장 가까운 CDN에서 해당 컨텐츠를 전송함으로써 latency 문제도 해결 할 수 있는 장점이 있다. 하지만 이또한, CDN이 장애를 일으키는 경우의 웹 작동 여부, 컨텐츠의 적절한 만료 일시, 비용 등을 고려해야된다.
위의 내용을 제외하고도 Stateless 웹 계층, 데이터센터, 샤딩을 통한 데이터베이스 확장, 독립적 서비스로 각 계층을 분할할 것 등이 시스템 규모 확장을 위해서 사용된다.
개략적인 규모 추정
: 개략적인 규모 추정을 하기 위해서는 규모 확장성을 표현하는데 필요한 기본기를 익혀야한다. 2의 제곱수나 응답지연 값, 가용성과 관련된 수치를 잘 이해하고 있어야한다.
2의 제곱수는 간단히 이야기하자면 2^10: 킬로바이트(KB), 2^20: 메가바이트(MB), 2^30: 기가바이트(GB), 2^40: 테라바이트(TB), 2^50: 페타바이트(PB)가 있다는 정도로 숙지하면된다.
응답 지연값의 경우는 컴퓨터에서 실행되는 각 연산들에 대한 지연 시간에 대한 표를 참고하여 대략적인 지연 시간을 계산할 수 있다. 결론은 메모리는 빠르고 시스크는 느리기때문에 디스크 탐색은 피해야한다는 점이다.
가용성에 대한 수치는 시스템이 오랜시간동안 지속적으로 중단 없이 운영될 수 있는 능력을 지칭하는 용어다.
처리율 제한 장치
: 서비스 혹은 클라이언트의 트래픽의 처리율을 제어하기 위한 장치이다. 즉, 요청 횟수가 설정한 임계치를 넘어가게 되면 모든 호출 처리가 중단되는 것을 제한하는 장치를 의미한다. 처리율 제한 장치를 이용하게되면 Dos 자원 고갈을 방지가 가능한 점, 추가 요청에 대한 처리 제한을 통해 서버의 수를 효과적으로 관리가 가능하기 때문에 비용에서 이득을 본다는 점, 서버 과부화를 막을 수 있다는 점이 장점으로 작용된다.
이러한 처리율 제한 장치는 서버 쪽, 클라이언트 쪽, 서버와 클라이언트 사이의 미들웨어 쪽에 둘 수 있다. 클라이언트에 처리율 제한 장치를 설치하게 되면 위변조가 쉽기 때문에 권장되지 않는 방법이다. 서버에 처리율 제한 장치를 두는 방법은 API서버에 처리율 제한 장치를 두어 요청에 대한 트래픽을 제어하게된다. 미들웨어에 처리율 제한 장치를 설치하게 되는 경우, 처리율 제한 알고리즘을 이용하여 처리율 제한 장치를 관리하게 된다.
처리율 제한 알고리즘은 대표적으로 토큰 버킷, 누출 버킷, 고정 윈도 카운터, 인동 윈도 로그, 이동 윈도 카운터 방법이 있다.
- 토큰 버킷: 사전에 지정된 양의 버킷에 토큰이 공급되고, 오버플로 된 토큰은 버려진다. 버킷 크기와 토큰 공급률을 적당한 값으로 튜닝하기가 까다롭다는 점을 제외하면 구현이 쉽고 메모리 사용 측면에서도 효율적인 편이다.
- 누출 버킷: 토큰 버킷과 유사하지만 처리율(지정된 시간에 얼마나 많은 항목을 처리할지 지정하는 값)을 인자로 가진다. 요청이 오면, 버킷이 차있는지 확인하고 가득 차있으면 요청을 버리고 아니면 큐에 요청을 채운다. 이후, 처리율에 따라 큐에 있는 요청을 해결한다. 요청에 대한 안정적인 처리가 가능하지만 단시간에 트래픽이 몰리는 경우, 최신 요청을 잘 처리 못하게 되는 단점을 가지고 있다.
- 고정 윈도 카운터 알고리즘: 타임라인을 고정되어 있는 간격의 윈도우로 나누고 그것을 카운터를 붙여 요청을 관리하는 방법이다. 각 시간마다 카운터를 설정하고 요청이 올때마다 카운터가 1씩 증가하고 임계치를 넘고 들어오는 요청은 버리는 방식이다. 효과적으로 메모리 관리가 가능하지만 윈도우 경계 부근에서 트래픽이 몰리게 될 경우에는 처리 한도 보다 많은 양의 요청을 처리하게 된다는 단점을 가지고 있다.
- 이동 윈도 로깅 알고리즘: 고정 윈도 카운터 알고리즘이 가지는 문제점인 경계 부근에 트래픽이 쏠렸을 때의 문제점을 해결하는 방법 중 하나이다. 타임스탬프에 요청을 담는 것이 아닌 타임스탬프를 로그에 담아서 관리하는 방법이다. 거절된 요청에 대한 타임스탬프를 저장해야되기 때문에 다량의 메모리를 사용한다는 단점을 제외하면 아주 정교한 알고리즘이다.
- 이동 윈도 카운터 알고리즘: 고정 윈도 카운터 알고리즘과 이동 윈도 로깅 알고리즘을 합친 알고리즘이다. 이전 시간대의 평균 처리율에 따라 윈도의 상태를 계산하기 때문에 트래픽이 몰려와도 잘 대응하고 메모리 효율 또한 좋다.
이러한 알고리즘은 카운터를 사용하는데, 이러한 카운터는 하드디스크에 저장하면 느리기때문에 캐시 메모리에 저장하여 사용한다. 대표적으로 Redis가 있다.
