참고
사용자 수에 따른 규모 확장성
NOTE
수백만 사용자를 지원하는 시스템을 설계하는 것은 도전적인 과제이며 지속적인 개선이 요구되는 여정이다..!
•
이번 장에서는 1명의 사용자 → 100,000,00명의 사용자를 지원하는 시스템 설계를 알아본다.
단일 서버
NOTE
웹, DB, 캐시 등이 모두 서버 1대에서 실행된다!
가장 단순한 구조이다,
데이터베이스 서버 분리
NOTE
사용자가 늘면서 웹 서버, 데이터베이스 서버를 분리한다!
웹/모바일 트래픽 처리 서버(웹 계층), 데이터베이스 서버(데이터 계층)
어떤 DB를 사용해야 하는가?
•
RDBMS
•
NoSQL
◦
아주 낮은 지연시간이 요구됨
◦
아주 많은 양의 데이터를 저장할 필요가 있음
로드 밸런서 도입
NOTE
서버의 확장을 위해 수평적 확장을 시도하려는데, 각 서버연결을 어떻게 관리하는가?
로드 밸런서가 각 서버의 부하를 분산시켜줌!
•
로드밸런서를 도입하면서 no failover(장애 자동복구)가 해소되며, 웹 계층의 availability(가용성)이 향상된다.
◦
서버 1이 다운되면, 서버 2로 트래픽이 전송된다.
◦
트래픽이 가파르게 증가하면 서버를 증설하고 로드밸런서가 부하를 분담시킴
•
수직적 확장 (scale up)
◦
서버에 고사양 자원을 추가하는 행위
◦
한계가 존재한다. (1대의 서버에 CPU, 메모리를 무한대로 증설할 수 없음)
◦
자동 복구, 다중화 방안을 제시하지 못한다.
•
수평적 확장 (scale out)
◦
서버의 수를 늘리는 행위
데이터베이스 다중화
NOTE
웹 계층처럼 데이터베이스 서버또한 여러개로 늘려보자!
DB의 다중화!
Master-Slave 구조!
•
많은 데이터베이스 관리 시스템이 다중화를 지원한다.
◦
Maset-Slave 관계를 설정, 원본은 Master에 저장, 사본은 Slave에 저장
◦
Master 에서 전체 연산, Slave에서 Read 연산만 수행
다중화의 장점
•
더 나은 성능
◦
모든 데이터 변경 연산은 Master로 전달된다.
◦
데이터 읽기 연산은 Slave로 분산된다.
◦
병렬처리 할 수 있는 질의 수가 늘어나고, 성능이 좋아진다.
•
안전성
◦
특정 DB가 파괴되어도 데이터가 보존될 수 있다.
•
가용성
◦
DB를 여러 지역에 복제해둠으로 써, 하나의 DB에 장애가 발생해도 다른 DB를 사용하면 된다.
캐시 - 응답시간 개선
NOTE
값 비싼 결과, 자주 참조되는 데이터를 메모리 안에 두고 요청을 빠르게 처리할 수 있도록 하는 저장소다!
캐시 계층과 CDN 적용한 아키텍쳐
캐시 계층
캐시를 읽으면 DB를 읽는거보다 훨씬 빠르다!
•
메모리 DB를 사용해 일반 DB보다 훨씬 빠르다!
사용 시 유의할 점
•
데이터 갱신이 자주 일어나지 않고, 참조가 자주 일어나는 경우 고려한다.
•
메모리에 저장하는 데이터는 결국 사라지므로 영속성 데이터를 저장하는건 적합하지 않다.
•
캐시에 저장되는 데이터의 만료시간을 적절하게 설정해야 한다.
•
DB와 캐시 DB의 일관성을 어떻게 유지할지 전략을 짜야한다.
•
캐시서버 또한 분리해서 설계해야 한다.
CDN
원본 서버보다 더 가까운 CDN에서 데이터를 전송해준다!
동작방식은 캐쉬와 동일하다.
•
정적,동적 콘텐츠를 전송하는데 쓰이는 지리적으로 분산된 서버 네트워크!
사용 시 유의할 점
•
CDN은 보통 제 3사업자에 의해 운영되며, 데이터 전송 양에 따라 비용을 내야하므로 캐싱전략을 잘 생각해야 한다.
•
CDN이 죽었을 경우 웹사이트가 어떻게 동작해야하는지 고려해야 한다.
무상태(Stateless) 웹 계층 - 확장성 개선
NOTE
웹 계층을 수평적으로 확장하기 위해선 상태 정보(사용자 정보, session)을 웹 계층에서 제거해야 한다!
상태 정보를 DB계층에서 따로 관리한다.
1의 자동규모 확장은 autoscaling을 의미한다.
•
이상적인 전략은 상태 정보를 RDBMS나 NoSQL 같은 지속성 저장소에 보관하고, 필요할때 가져오도록 하는 것이다.
상태 정보 의존적인 아키텍쳐
각 서버에 사용자의 데이터가 남아있다.
이 경우, 사용자 A를 인증하려면 서버 1로 전송되어야 한다.
•
항상 같은 클라이언트로부터의 요청이 항상 같은 서버로 전송되어야 한다
◦
로드밸런스에서 고정 세션(sticky session) 기능을 제공하지만 이는 로드밸런스에 부담을 준다.
◦
서버를 추가/제거 하기에도 까다로워진다.
무상태 아키텍쳐
사용자의 HTTP 요청은 어떠한 웹 서버로 가도된다!
•
공유 저장소로부터 상태 정보를 가져온다.
•
이러한 구조는 단순하고, 안정적이며 규모확장이 쉽다.
데이터 센터 - 전세계 확장
NOTE
데이터 센터를 사용해 지리적으로 가까운 데이터 센터에 연결시켜준다!
지리적 이점은 결국 최고인거같다.
•
geoDNS-routing
◦
2개의 데이터 센터를 이용하면, 사용자와 가까운 데이터 센터와 연결되는 방식
◦
위 그림의 경우 x%의 사용자는 US-East, 100-x%의 사용자는 US-West
•
데이터 센터 중 하나가 장애가 발생하면, 모든 트래픽은 장애가 없는 데이터 센터로 전송된다.
고려해야하는 점
•
트래픽 우회
◦
올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야 한다.
◦
GeoDNS는 사용자에게서 가까운 데이터 센터로 보낸다.
•
데이터 동기화
◦
데이터 센터마다 별도의 데이터베이스를 사용한다면, 데이터 정합성이 맞지 않을 수 있다.
◦
보편적 전략은 데이터를 여러 센터에 걸쳐 다중화 하는것이다.
메시지 큐 - 디커플링(확장성 개선)
NOTE
메시지 큐 ⇒ 메시지의 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트다!
Pub/Sub 구조로 연결된다.
•
메시지 큐를 사용하면 서비스 또는 서버간 결합이 느슨해져서, 규모 확장성이 보장되어야하는 안정적 애플리케이션을 구성하기 좋다.
◦
생산자 → 소비자 프로세스가 다운되어도 메시지 발행가능
◦
소비자 → 생산자가 가용상태가 아니더라도 메시지 수신가능
•
시간이 오래걸리는 프로세스를 비동기적으로 처리하면 편리하다.
◦
생산자 → 작업을 메시지 큐에 넣는다
◦
소비자 → 작업을 메시지 큐에서 꺼내서 비동기적으로 완료한다.
로그, 메트릭 그리고 자동화 - 유지보수 개선
NOTE
로그, 매트릭, 자동화를 통해 유지보수성을 증가시킬 수 있다!
로그,메트릭,자동화 + 메시지큐 적용 아키텍쳐
•
로그
◦
에러 로그를 모니터링 해서, 문제점을 쉽게 찾아낼 수 있다.
•
메트릭
◦
잘 수집하면 사업 현황에 관해 유용한 정보를 얻을 수도 있다.
◦
CPU, 메모리 이외에도 일별 사용자, 수익, 재방문 정보도 알 수 있다.
•
자동화
◦
시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구를 활용한다.
▪
CI(지속적 통합)을 도와주는 도구를 만들어 검증 절차를 자동으로 거치도록 한다.
▪
빌드, 테스트, 배포 등의 절차를 자동화 하는 작업
데이터베이스의 규모 확장 - 샤딩(확장성 개선)
NOTE
샤딩 ⇒ 데이터베이스를 단순 복제가 아니라 나누어서 서버로 분산하는 방법
ex) user_id % 4를 통해 DB를 4개로 나누었다.
데이터가 분산되서 저장된다!
샤딩 고려사항
•
샤딩 키를 통해 데이터를 고르게 분할 할 수 있도록 하는게 중요하다.
•
샤딩은 다음과 같은 경우에 필요하다
◦
데이터가 너무 많아져서 하나의 샤드로는 감당 못할 때
◦
샤드 간 데이터 분포가 균등하지 못하여 어떤 샤드에 할당된 공간 소모가 다른 샤드에 비해 빠르게 진행될 때
•
유명인사 문제(핫스팟 키)
◦
특정 샤드에 질의가 집중되어 과부하가 걸리는 문제
•
조인과 비정규화
◦
하나의 DB를 여러 서버로 쪼개고 나면, 여러 샤드에 걸친 데이터를 조인하기가 힘들어진다.
◦
이를 위해 DB를 비정규화하거나 하나의 테이블에서 질의를 수행하도록 한다.