대규모 서비스를 위한 고려 사항 (2)

6. 무상태(Stateless) 웹 계층

---

웹 계층을 수평적으로 확장하기 위해서는 사용자 세션 정보와 같은 상태 정보를 웹 계층에서 제거해야 한다.
바람직한 전략은 상태 정보를 관계형 데이터베이스나 NoSQL과 같은 지속성 저장소에 보관하고, 필요할 때 가져오도록 하는 것이다. 이렇게 구성된 웹 계층을 무상태 웹 계층이라고 한다.

상태 정보 의존적인 아키텍처

예를 들어서 사용자 A의 세션 정보나 프로파일 이미지와 같은 상태 정보는 서버 1에 저장된다.
이때의 문제는 사용자 A를 인증하기 위해서 HTTP 요청은 반드시 서버 1로 전송되어야 한다는 것이다.

만약 서버 2로 요청하면, 서버 2에는 사용자 A에 대한 상태 정보가 저장되어 있지 않아 인증이 실패할 것이다.

Sticky Session

Sticky Session

이러한 문제를 해결하기 위해 로드밸런서에는 sticky session이라는 기능을 제공한다.

• 고정 세션 기능으로, 같은 사용자는 항상 같은 서버로 요청 되도록 하는 기능
• 하지만 이는 로드밸런서에 부담을 주며, 로드밸런서 뒷단에 서버를 추가하거나 제거하기 까다롭다는 단점이 존재한다.

무상태 아키텍처

무상태 아키텍처에서 사용자로부터의 HTTP 요청은 어떤 웹 서버로도 전달될 수 있다. 웹 서버는 상태가 필요할 경우 공유 저장소로부터 데이터를 가져온다.

• 따라서 상태 정보는 웹 서버로부터 물리적으로 분리되어 있다.

이러한 구조는 단순하고, 안정적이며, 규모 확장이 쉽다.

7. 데이터 센터

---

지리적 라우팅

• 장애가 없는 상황에서 사용자는 가장 가까운 데이터 센터로 안내되는데, 이 절차를 지리적 라우팅이라고 한다.
• 지리적 라우팅에서의 geoDNS는 사용자의 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정할 수 있도록 해주는 DNS 서비스이다.

기술적 난제

다중 데이터센터 아키텍처를 구현하려면 몇 가지 기술적 난제를 해결해야 한다.

트래픽 우회

• 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야 한다.

데이터 동기화

• 데이터 센터마다 별도의 데이터베이스를 사용하는 경우, 장애가 자동으로 복귀되어 트래픽이 다른 데이터베이스로 우회된다 해도, 해당 데이터센터에는 찾는 데이터가 없을 수 있다.
• 이러한 상황을 막는 보편적 전략은 데이터를 여러 데이터센터에 걸쳐 다중화하는 것이다.

테스트와 배포

• 여러 데이터 센터를 사용하도록 시스템이 구성된 상황이라면 애플리케이션, 웹 사이트를 여러 위치에서 테스트해보는 것이 중요하다. 한편 자동화된 배포 도구는 모든 데이터센터에 동일한 서비스가 설치되도록 하는 데 중요한 역할을 한다.

8. 메시지 큐

---

시스템을 더 큰 규모로 확장하기 위해서는 시스템의 컴포넌트를 분리하여, 각기 독립적으로 확장될 수 있도록 하여야 한다.

메시지 큐란?

• 메시지 큐는 메시지의 무손실 (durability)를 보장하는 비동기 통신을 지원하는 컴포넌트.
• 메시지의 버퍼 역할을 하며, 비동기적으로 전송한다.

아키텍처

메시지 큐

• 발행자 (Producer or Publisher)라고 불리는 입력 서비스가 메시지를 만들어 메시지 큐에 발행한다.
• 큐에는 구독자 (Consumer or Subscriber)라 불리는 서비스 혹은 서버가 연결되어 있는데, 메시지를 받아 그에 맞는 동작을 수행하는 역할을 한다.

효과

• 메시지를 큐를 이용하면 서비스 또는 서버 간 결합이 느슨해져서, 규모 확장성이 보장되어야 하는 안정적 애플리케이션을 구성하기 좋다.
• 생산자는 소비자 프로세스가 다운되어 있어도 메시지를 발행할 수 있고, 소비자는 생산자 서비스가 가용한 상태가 아니더라도 메시지를 수신할 수 있다.
• 또한 생상자와 소비자의 서비스의 규모는 각기 독립적으로 확장될 수 있다.

9. 로그,  메트릭,  자동화

---

로그

• 에러 로그를 모니터링하는 것은 중요하다.
• 에러 로그는 서버 단위로 모니터링 할 수도 있지만, 로그를 단일 서비스로 모아주는 도구를 활용하면 더 편리하게 검색하고 조회할 수 있다.

메트릭

• 메트릭을 잘 수집하면, 시스템의 현재 상태를 손쉽게 파악할 수 있다.

호스트 단위 메트릭

• CPU, 메모리, 디스크 I/O에 관한 메트릭 등

종합 메트릭

• 데이터베이스 계층의 성능, 캐시 계층의 성능 등

핵심 비즈니스 메트릭

• 일별 능동 사용자 (DAU), 수익, 재방문 등

자동화

• 시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구를 활용해야 한다.
• 예를 들어 CI를 활용하면 개발자가 만드는 코드가 어떤 검증 절차를 자동으로 거치도록 할 수 있어서 문제를 쉽게 감지할 수 있다.
• 이외에도 빌드, 테스트, 배포 등의 절차를 자동화할 수 있어서 개발 생산성을 크게 향상할 수 있다.

10. 데이터베이스의 규모 확장

---

저장할 데이터가 많아지면 데이터베이스에 대한 부하도 증가한다.

이때 데이터베이스를 증설할 방법을 고려해야 하는데, 규모를 확장하는 방법은 마찬가지로 수직적 규모 확장법과 수평적 규모 확장법 두 가지 접근법이 존재한다.

수직적 확장

• Scale Up으로, 기존 서버에 고성능의 자원을 증설하는 방법.

수직적 확장의 단점

• 데이터베이스 서버 하드웨어에는 한계가 존재한다.
• SPOF로 인한 위험성이 크다.

수평적 확장

샤딩

• 샤딩이라고도 불리는 수평적 확장은, 더 많은 서버를 추가함으로써 성능을 향상시키는 접근법이다.
• 샤딩은 대규모 데이터베이스를 샤드라고 부르는 작은 단위로 분할하는 기술.
• 모든 샤드는 같은 스키마를 쓰지만 샤드에 보관되는 데이터 사이에는 중복이 없다.

샤딩 전략 고려 사항

샤딩 키(파티셔닝 키)를 어떻게 정하느냐가 포인트.

데이터의 재 샤딩

• 데이터가 너무 많아져서 하나의 샤드로는 감당하기 어렵거나, 샤드 간 데이터 분포가 균등하지 못하여 어떤 샤드에 할당된 공간 소모가 다른 샤드에 비해 빠르게 진행될 때, 샤드 소진이라고 부르는 이런 현상이 발생하면 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치하여야 한다.

유명인사 문제

• 핫스팟 키 문제라고도 부르는데, 특정 샤드에 쿼리가 집중되어 서버에 과부하가 걸리는 문제.

조인과 비정규화

• 일단 하나의 데이터베이스를 여러 샤드 서버로 쪼개고 나면, 여러 샤드에 걸친 데이터를 조인하기가 힘들어진다.
• 이를 해결하는 한 가지 방법은 데이터베이스를 비 정규화하여 하나의 테이블에서 질의가 수행될 수 있도록 하는 것.

정리

---

시스템의 규모를 확장하는 것은 지속적이고 반복적인 과정이다.

시스템 규모 확장을 위해 살펴본 기법들을 정리해보면..

• 웹 계층은 무상태 계층으로
• 모든 계층에 다중화 도입
• 가능한 한 많은 데이터를 캐시
• 여러 데이터 센터를 지원
• 정적 콘텐츠는 CDN을 통해 서비스
• 데이터 계층은 샤딩을 통해 그 규모를 확장
• 각 계층은 독립적 서비스로 분할
• 시스템을 지속적으로 모니터링하고, 자동화 도구를 활용.