1. 웹의 기본 아키텍처

1-1. 3 tier 아키텍처

기본이었던 3tier 아키텍처 이다. 먼저 클리이언트가 서버로 요청을 보낸다. 서버는 비즈니스 로직을 수행하고 데이터베이스로에게 요청을 보내 응답을 받는다. 서버가 받은 데이터를 클라이언트에게 보낸다.

그런데 웹의 복잡도가 증가함에 따라 웹의 아키텍처가 발전하게 됐다

1-2. n tier 아키텍처

웹서버
JavaScript, CSS, HTML 같은 정적인 데이터를 서빙하는데에 주로 사용됨.

웹 어플리케이션 서버
동적으로 변하는 데이터를 처리함.

1-2-1. 왜? 웹서버와 웹어플리케이션이 나뉘었는가?

핵심

• 관심사의 분리 / 관측가능한 시스템 / 효율적인 리소스 사용

  • 웹 어플리케이션 서버는 DB 조회, 비즈니스 로직을 수행하기 바쁘기 때문에 단순한 정적 컨텐츠는 웹 서버에서 빠르게 클라이언트한테 제공하는 것이 좋다.
  • 정적 컨텐츠 요청까지 웹 어플리케이션 서버에서 수행하게 되면 부하가 커지게 되고, 동적 컨텐츠 처리가 지연됨에 따라 수행속도가 느려진다.
  • 컴포넌트를 각각의 역할에 맡게 잘게 분리하게 되면 역할에 맡게 자유롭게 최적화 기법을 사용할 수 있다.
  • 문제의 범위를 굉장히 좁힐 수 있다.

• 단점

  • 시스템의 복잡도가 매우 증가한다.

장점과 단점의 균형을 잘 잡아가야 한다.

Note :
관심사의 분리의 경우 비단 아키텍처 뿐만 아니라
웹 어플리케이션 서버를 구축할 때 레이어계층의 역할을 분리한 코드는 유지보수하기에도 좋다.

1-3. 클라이언트는 무한정 늘어날 수 있는 구조

서비스의 흥행에 따라 클라이언트는 무한정 늘어날 수 있다. (이용자 급증)
그러나 서버와 데이터베이스는 무한정 늘릴 수 없다.

2. 데이터베이스

2-1. 왜 데이터베이스가 병목일까

2-1-1. 스케일 업 & 스케일 아웃

스케일 업

• 컴퓨터의 성능을 업그레이드 한다.

스케일 아웃

• 컴퓨터를 여러대로 늘린다.

간단한 비교

• 유지보수 및 관리 : 스케일 업 > 스케일 아웃
  (스케일 업한 서버는 하나의 서버만을 관리하기 때문에 비교적 쉬움)
• 확장성 : 스케일 업 < 스케일 아웃
  (하나의 서버를 무한정으로 스케일 업 할 수 없음)
• 장애복구 : 스케일 업 < 스케일 아웃
  (N대의 서버 중 하나의 서버에서 장애 발생 시 다른 서버가 서빙 할 수 있음)

여러 관점에서 대규모시스템을 만들기 위해서는 스케일 업보다 스케일 아웃이 조금더 유리해보인다.

Note :

• N대의 서버로 확장되더라도 하나의 서버가 동작하는 것처럼 보여야 한다.
• 스케일 아웃의 중요한 점은 무상태를 유지하는 것. 그러나 DB는 데이터 상태를 유지한다. 따라서 DB를 스케일 아웃하는 기술은 있지만, 서버의 스케일 아웃보다 훨씬 많은 비용이 필요함
• 현대 서버 아키텍처는 상태관리를 DB에 위임하고 서버는 상태관리를 하지 않는 방향으로 발전

스케일 아웃 외에도 데이터베이스는 디스크의 데이터를 접근해서 가져오기 때문에 서버보다 비교적 처리속도가 늦어질 수 밖에 없다.

3. 대용량 트래픽 / 데이터 처리는 왜 어려울까

핵심

• 하나의 서버 또는 데이터베이스로 감당하기 힘든 부하
  이와 같은 이유로 여러대의 서버와 데이터베이스를 사용하게 되고
  다수의 서버와 데이터베이스가 마치 하나인 것처럼 작동해야 하기 때문

• 웹 서비스는 24시간 무중단
  잘못된 코드 한줄의 영향이 매우 크다.

• 굉장히 복잡한 시스템, 여러 마이크로 서비스가 복잡한 의존 관계를 가진다.

3-1. 조건

고가용성

• 언제든 서비스를 이용할 수 있어야 한다.

확장성

• 시스템이 비대해짐에 따라 증가하는 데이터와 트래픽에 대응할 수 있어야한다.

관측가능성

• 문제가 생기면 빠르게 알 수 있어야하고 문제의 범위를 최소화 할 수 있어야한다.

3-2. 시스템 발전 과정 맛보기

1.
사용자가 적을때 적절한 응답속도를 가진다. 그러나 사용자가 증가함에 따라 고려해볼 기술로 우선 스케일 아웃이 있다.

2.
N대의 서버로 확장하고 앞단에 로드밸런서를 두어 트래픽을 분산 시켰다.
그러나 데이터베이스의 응답속도가 느려지면 결국 전체 서비스의 응답속도가 느려진다.
고려해볼 기술로 캐시가 있다.
(먼저 쿼리 최적화 등을 고려해볼 수 있지만 현재 가정에는 캐시를 사용한다고 가정한다.)

Note :

• 글로벌 캐시 : Redis Server와 같이 여러대의 서버가 하나의 캐시를 바라보는 기술
• 로컬 캐시 : 각각의 서버의 메모리에 저장하는 캐시
• 고려해야할 점 : 캐시 주기 설정, 만료 정책

3.
시스템이 발전함에 따라 이메이, 푸시 알림 등 점점 대외기관과의 연동이 필요한 요구사항들이 생겨났다. 따라서 대외기관을 연동하는 부분에서 응답속도가 늦어지는 문제가 발생했다고 가정해보자. 고려해볼 수 있는 기술로 비동기큐가 있다.

4.

이렇게 클라이언트의 요청 중 대외기관의 연동을 이용하는 트랜잭션을 제외할 수 있다.

위와 같은 모듈이 여러개 모여 하나의 대규모시스템을 이루게 된다.
5.

결론

이 위의 예시는 단편적인 예이고, 실무에서는 어떻게 대용량아키텍처를 구축하는지 아직 알 수 없기 때문에 중요한 것은 각 기술들의 사용법이 아니라 대용량아키텍처 아래서 이러한 기술이 나타난 배경, 목적, 용도를 이해하고 각 기술들이 상호보완적으로 어떻게 작동하는지 이해하는 것을 목표로 한다.