수직적 규모 확장(scale up) vs 수평적 규모 확장(scale out)
수직적 규모 확장의 단점은 아래와 같다.
- 수직적 규모 확장의 한계: CPU나 메모리 무한대 증설 물가
- 장애에 대한 자동복구, 다중화 방안 X
👉 대규모 애플리케이션에선, 수평적 규모 확장법이 적절!
수평적 규모 확장: 로드밸런서, DB 클러스터링
너무 많은 사용자가 접속하여 웹 서버가 한계 상황에 도달하게 되면, 응답 속도가 느려지거나 접속이 불가능해질 수도 있다.
👉 부하 분산기 or 로드밸런서를 도입하여 해결한다.
로드밸런서
로드밸런서는 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할
- 사용자는 로드밸런서의 공개 IP 주소로 접속하고, 내부에는 사설 IP 주소들이 사용된다.
- 사설 IP 주소: 같은 네트워크에 속한 서버 사이의 통신에만 사용하며 인터넷을 통해서는 접속할 수 없다.
- Failover: 서버 1이 다운되면 모든 트래픽은 서버 2로 전송됨으로써, 웹 사이트 전체가 다운되는 일을 방지한다.
- 가용성 향상: 로드밸런서가 자동적으로 트래픽을 분산하여, 서버 다운을 예방할 수 있다.
데이터베이스 다중화: 클러스터링
- 쓰기 연산은 master에서만 지원, 해당 사본을 slave에 전달
- 읽기 연산은 slave에서 지원 👉 통상적으로 읽기 연산이 비중이 크기 때문에, slave DB 수가 master DB 수 보다 많다.
- 성능 향상: master와 slave의 역할이 분리되어 요청이 분산된다. → 병렬로 처리될 수 있는 질의 수 증가
- 안정성: 데이터 파괴 시 다른 DB에서 복구 가능
- 가용성: 장애 발생 시 다른 DB를 활용해 복구 가능
- master 장애 → slave를 master로 승격
- 🤔 근데, slave 서버에 보관된 데이터가 최신 상태가 아니라면?!
- 없는 데이터는 복구 스크립트를 돌려 추가
- 다중 마스터, 원명 다중화 도입. But, 훨씬 복잡…
응답시간 개선: 캐시, CDN
캐시
💡 애플리케이션의 성능은 데이터베이스 호출 빈도수에 많은 영향을 받는다.
웹 페이지를 새로고침 할 때마다 데이터베이스를 호출하여 데이터를 가져온다. 따라서 자주 사용되는 데이터를 캐시에 보관하여 데이터베이스 호출 수를 줄인다.
- 성능 개선
- 데이터베이스 부하 감소
- 캐시 사용 시 유의할 점
- 캐시는 어떤 상황에 바람직한가?
- 어떤 데이터를 캐시에 두어야 하는가?
- 캐시에 보관된 데이터는 어떻게 만료되는가?
- 일관성은 어떻게 유지되는가?
- 장애에는 어떻게 대처할 것인가?
- 캐시 메모리는 얼마나 크게 잡을 것인가?
- 데이터 방출 정책은 무엇인가?
콘텐츠 전송 네트워크(CDN)
- 전 세계에 분산된 서버 네트워크를 통해 웹 콘텐츠를 빠르게 제공하는 시스템
- 사용자와 지리적으로 가까운 서버에서 콘텐츠를 제공함으로써 웹사이트의 로딩 속도를 개선하고 서버의 부하를 줄인다.
- request path, query string, cookie, request header 등의 정보에 기반하여 HTML 페이지 캐시
- 이미지, 비디오, CSS, JavaScript 파일 등을 캐시
- CDN 사용 시 고려해야 할 사항
- 비용
- 적절한 만료 시한 설정
- CDN 장애에 대한 대처 방안
- 콘텐츠 무효화 방법
웹 계층의 수평적 확장: 무상태(stateless) 웹 계층
💡 웹 계층을 수평적으로 확장하기 위해서는, 상태 정보(e.g. 사용자 세션 데이터)를 웹 계층에서 제거해야 한다.
👉 상태 정보를 데이터베이스와 같은 지속성 저장소에 보관하고, 필요할 때 가져오도록 하여 무상태 웹 계층을 만든다.
상태 정보 의존적인 아키텍처가 왜 문제인가? 🤔
서버가 여러 대 있는 경우,
유저 A에 대한 세션 데이터는 서버 A, 유저 B에 대한 세션 데이터는 서버 B에 존재할 때 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야 한다. 로드밸런서가 이러한 기능을 제공하고 있긴 복잡하고 부담이 심하다.
무상태 아키텍처
- 상태 정보를 웹 서버로부터 물리적으로 분리
- 이런 구조는 단순하고, 안정적이며, 규모 확장이 쉽다.
세계적인 시스템으로🌎: 데이터 센터
가용성을 높이고 전 세계 어디서도 쾌적하게 사용하기 위해서는 데이터 센터를 지원해야 한다.
데이터 센터
- 장애가 없는 상황이라면, 사용자로부터 가장 가까운 데이터 센터로 라우팅 → 지리적 라우팅(geoDNS-routing)
- 사용자는 도메인 이름만 입력하면, 사용자의 위치에 따라 알아서 IP 주소 변환
- 데이터 센터에 장애 발생 시, 다른 데이터 센터로 트래픽 전송
- 데이터 센터 아키텍처 설계의 기술적 난제
- 트래픽 우회: 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법
- 데이터 동기화
- 테스트와 배포: 여러 위치에서 테스트 본다
시스템 컴포넌트 분리를 통한 독립적 확장: 메세지 큐
메세지 큐
- 메세지의 무손실을 보장하는 비동기 통신 지원 컴포넌트
- 메세지의 버퍼 역할을 하며, 비동기적으로 메세지를 전달한다.
- publisher 입력 서비스가 메세지를 만들어 메세지 큐에 publish한다. 큐에 연결되어 있는 consumer가 메세지를 받아 그에 맞는 동작을 수행한다.
- 메시지 큐를 이용하면 서비스 또는 서버 간 결합이 느슨해져, 규모 확장이 편리하다.
- publisher는 consumer가 다운되어 있어도 메세지를 발생할 수 있고, consumer는 publisher가 가용한 상태가 아니더라도 메세지를 수신할 수 있다.
로그, 메트릭, 자동화
로그
- 에러 로그를 모니터링하여, 시스템의 오류와 문제들을 파악한다.
메트릭
- 메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수도 있고, 시스템의 현재 상태를 손쉽게 파악할 수도 있다.
- 호스트 단위 메트릭, 종합 메트릭, 핵심 비즈니스 메트릭
자동화
- 생산성을 향상시키기 위해 자동화를 도입하자!
- CI/CD, ..
데이터베이스 규모 확장
수직적 확장 vs 수평적 확장
- 수직적 확장(scale up)
- 기존 서버에 고성능 자원 증설
- 단점: 한계 존재, SPOF 위험, 비용 문제
- 수평적 확장(scale out)
- 샤딩
샤딩(sharding)
- 샤딩은 대규모 데이터베이스를 샤드라는 작은 단위로 분할하는 기술
- 더 많은 서버 추가
- 모든 샤드는 같은 스키마를 쓰지만 샤드에 보관되는 데이터 사이에는 중복 X
- 샤드 분할 방법, 즉 샤딩 키를 어떻게 정하느냐 중요!
- 고려해야 할 문제
- 데이터의 재 샤딩
- 핫스팟 키 문제
- 조인과 비정규화
