무상태 웹 계층
웹 계층을 수평적으로 확장하기 위해선 상태 정보(사용자 세션 데이터 등)를 제거해야 합니다. 일반적으로 상태 정보를 RDB나 NoSQL 같은 영속성을 지닌 저장소에 보관하고, 필요할 때 가져오도록 하는 방법이 있습니다. 이렇게 구성된 웹 계층을 무상태 웹 계층이라고 합니다.
상태 정보 의존적인 아키텍처
상태 정보를 보관하는 서버와 그렇지 않은 서버 사이에는 몇 가지 중요한 차이가 있습니다. 상태 정보를 보관하는 서버는 클라이언트 정보를 유지하여 요청들 사이에 공유되도록 하지만, 무상태 서버는 이러한 장치가 없습니다.
위 그림은 상태 정보 의존적인 아키텍의 예입니다. 사용자 A에 대한 상태 정보는 서버1에 저장되어, 사용자 A를 인증하기 위해 HTTP 요청은 반드시 서버 1로 전송되어야 합니다. 만약, 요청이 2로 전송되면 인증은 실패할 것인데, 서버 2에는 사용자 A에 관한 상태 정보가 없기 떄문입니다.
이 구조의 한계는 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야 한다는 점입니다. 대부분의 로드밸런서가 이를 지원하기 위해 고정 세션이라는 기능을 제공하고 있는데, 이는 로르밸런서에 부담을 주는 방식입니다. 게다가 로드밸런서 뒷단에 서버를 추가하거나 제거하기도 까다로워지기 때문에, 서버 장애를 처리하기도 복잡합니다.
무상태 아키텍처
다음 사진은 상태 정보를 보관하지 않는 무상태 아키텍처입니다. 이 구조의 경우 사용자로부터의 HTTP 요청은 어떤 웹 서버로도 전달 가능합니다. 웹 서버는 상태 정보가 필요한 경우 공유 저장소로부터 데이터를 가져옵니다.
다음 구조는 무상태 웹 계층을 갖도록 기존 설계를 변경한 결과입니다. 단, 공유 저장소는 RDB일 수도, NoSQL일 수도, Memcached/Redis와 같은 캐시 시스템일 수도 있습니다.
이 과정을 통해, 상태 정보가 웹 서버들로부터 제거되었으므로, 트래픽 양에 따라 웹 서버를 추가하거나 삭제하기만 하면 자동으로 규모를 확장할 수 있습니다. 하지만, 웹 사이트가 전 세계로 진출하게 된 시점도 생각해야 합니다. 가용성을 높이고 어디서도 쾌적하게 사용할 수 있도록 하기 위해선 여러 데이터 센터를 지원하는 것은 필수입니다.
데이터 센터
다음 그림은 두 개의 데이터 센터를 이용하는 아키텍처입니다. 사용자는 우선 가장 가까운 데이터 센터로 이동하는데, 통상 이 절차를 지리적 라우팅이라고 합니다.
만약, 데이터 센터 중 하나에 심각한 장애가 발생하면 다음 그림과 같이 모든 트래픽은 장애가 없는 데이터 센터로 전송됩니다.
다중 데이터 센터에서 발생하는 기술적 난제
트래픽 우회
올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야 합니다. GeoDNS 서비스는 사용자에게서 가장 가까운 데이터 센터로 트래픽을 보낼 수 있도록 도와줍니다.
데이터 동기화
데이터 센터마다 별도의 데이터베이스를 사용하고 있는 상황이라면, 장애가 자동으로 복구되어 트래픽이 다른 데이터베이스로 우회된다 해도, 해당 데이터 센터에는 찾는 데이터가 없을 수 있습니다. 이런 상황을 막는 보편적 전략은 데이터를 여러 데이터 센터에 걸쳐 다중화하는 것입니다.
테스트와 배포
여러 데이터 센터를 사용하도록 시스템이 구성된 상황이라면 웹 사이트 또는 애플리케이션을 여러 위치에서 테스트해 보는 것이 중요합니다. 자동화된 배포 도구는 모든 데이터 센터에 동일한 서비스가 설치되도록 하는 데 중요한 역할을 합니다.
시스템을 더 큰 규모로 확장하기 위해서는 시스템의 컴포넌트를 분리하여, 각기 독립적으로 확장될 수 있도록 해야 합니다. 메시지 큐는 많은 실제 분산 시스템이 이 문제를 풀기 위해 채용하고 있는 핵심적 전략 가운데 하나입니다.
메시지 큐
메시지 큐는 메시지의 무손실과 비동기 통신을 지원하는 컴포넌트로 버퍼 역할을 수행합니다. 메세지 큐의 기본 아키텍처는 생산자와 소비자로 구분되어 있습니다. 생산자는 메시지를 만들어 큐에 발행하고, 소비자는 큐를 구독하여 발행된 메시지를 받아 동작을 수행합니다. 이를 그림으로 표현하면 다음과 같습니다.
메시지 큐를 사용하면 서비스 또는 서버 간 결합이 느슨해져서, 규모 확장성이 보장되어야 하는 안정적 애플리케이션을 구성하기 좋습니다. 생산자는 소비자 프로세스가 다운되어 있어도 메시지를 발행할 수 있고, 소비자는 생산자 서비스가 가용한 상태가 아니더라도 메시지를 수신할 수 있기 때문입니다.
로그, 메트릭 그리고 자동화
몇 개 서버에서 실행되는 소규모 웹 사이트를 만들 때는 로그나 메트릭, 자동화 같은 것들은 필수는 아닙니다. 하지만, 일단 웹 사이트와 함께 사업 규모가 커지고 나면, 그런 도구에 필수적으로 투자해야 합니다.
로그
에러 로그를 모니터링하는 것은 중요합니다. 시스템의 오류와 문제들을 보다 쉽게 찾아낼 수 있도록 하기 때문입니다. 에러 로그는 서버 단위로 모니터링 할 수도 있지만, 로그를 단일 서비스로 모아주는 도구를 활용하면 더 편리하게 검색하고 조회할 수 있습니다.
메트릭
메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수도 있고, 시스템의 현재 상태를 손쉽게 파악할 수 있습니다. 메트릭 가운데 특히 유용한 것을 몇 가지 살펴보면 다음과 같습니다.
- 호스트 단위 메트릭: CPU, Memory, 디스크 I/O
- 종합 메트릭: 데이터베이스 계층의 성능, 캐시 계층의 성능
- 핵심 비즈니스 메트릭: 일별 능동 사용자, 수익, 재방문
자동화
시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구를 활용해야 합니다. 가령 지속적 통합을 도와주는 도구를 활용하면 개발자가 만드는 코드가 어떤 검증 절차를 자동으로 거치도록 할 수 있어서 문제를 쉽게 감지할 수 있습니다. 이 외에도 빌드, 테스트, 배포 등의 절차를 자동화할 수 있어서 개발 생산성을 크게 향상시킬 수 있습니다.
메시지 큐, 로그, 메트릭, 자동화 등을 반영한 설계
메시지 큐, 로그, 메트릭, 자동화 등을 모두 반영할 설계는 다음 그림과 같습니다.
