[인프라] 시스템 구성 기본 패턴

풀스택을 1대의 시스템으로 구성하기

---

일반적인 웹 서비스를 1대의 서버로 구축한다고 가정하면 역할의 전형적인 구분 방법은 다음과 같습니다.

[Web]

- 클라이언트의 접속

- 데이터 전송

- 정적 데이터 전달

- 동적 데이터 중계

- 동적 데이터 생성

- 애플리케이션 로직

[DB]

- 데이터베이스의 가동 및 데이터베이스의 데이터 보관

[File]

- 파일 형식의 데이터 보관

- 화상 및 프로그램 파일 등을 보관

각각의 역할마다 대표적인 제품은 아래와 같습니다.

Web	Web 서버나 애플리케이션 서버  nginx, Apache(cgi/mod_php/mod_perl), php-fpm, plack, Unicorn, gunicorn, Tomcat, Glassfish, WebLogic, JBoss 등
DB	RDBMS나 NoSQLDB   PostgreSQL, MySQL, Oracle, DB2, memcached, Redis, MongoDB 등
File	디스크 스토리지, 오브젝트 스토리지   하드디스크, Amazon EBS, Amazon S3 등

역할을 명확히 구분함으로써 역할마다 새로운 버전으로 적용하거나 다른 소프트웨어로 바꾸거나 교환이 가능하게 하려는 의도가 숨어 있습니다. 다만 수직적인 스택에 비하여 결합도가 강하기 때문에 역할을 독립적으로 운용하는 것이 수직적인 스택의 경우보다 어려울 수도 있습니다. 그렇지만 이렇게 세분화함으로써 성능과 다중성 및 가용성 등의 대책이 조금 더 용이해질 수 있습니다.

아래는 1대의 시스템에서 역할을 나누는 경우의 구성도입니다.

시스템 구성 변경의 기초

---

1대의 시스템에서 구성을 변경하는 경우, 구성 변경에는 전형적인 패턴이 몇가지 있습니다.

방법	목적	내용
다중화	다중성 향상, 가용성 향상	같은 기능과 역할의 기기를 여러 대 준비하여 단일 기기의 고장에 따른 영향이 시스템 전체에 미치지 않도록 함으로써 시스템 전체의 가용성을 높입니다.
기능 분할	처리 능력 향상	1대로 여러 기능을 제공하고 있는 경우, 서버를 기능별로 준비하여 1대당 처리 부하를 감소시켜 시스템 전체의 성능을 향상시킵니다.
스케일 업	처리 능력 향상	구성은 변경하지 않고 서버 자체의 성능을 향상시킴으로써 시스템 전체의 성능을 향상시킵니다.
스케일 아웃	처리 능력 향상	같은 기능과 역할의 기기를 여러 대 준비하여 처리를 분담시킴으로써 시스템 전체의 성능을 향상시킵니다.

스케일 아웃은 서버를 추가로 준비하는 등 특정 조건에서는 다중화를 겸할 수 있지만, 근본적으로는 다른 개념이므로 혼동하지 않도록 주의해야 합니다.

패턴1. 웹서버x1, 데이터베이스 서버x1 구성 (기능 분할)

1대로는 서버의 스펙이 부족할 때, 이를 해결하기 위해 적용하는 경우가 많습니다. 이때는 [DB]만 분할하는 경우와 [DB] 및 [File]을 함께 분할하는 경우가 있습니다.

[DB]만 별도의 서버로 분할하는 경우 / [DB]와 [File]을 별도의 서버로 분할하는 경우

패턴2. 웹서버x2 구성 (다중화)

대기용 서버에 [Web], [DB], [File]을 준비한다

이 구성은 다중성을 높이기 위해 적용하는 경우가 많습니다. 서버1(운용 서버)에 어떤 문제가 생긴 경우, 서버 1 대신 서버 2(대기용 서버)를 이용하는 방법입니다.

이때 현재 운용 중인 서버와 대기용 서버 간의 전환 방법은 다음과 같이 다양합니다.

- 물리적인 서버의 경우, LAN 케이블을 바꿔 끼운다(수 시간).

- DNS를 갱신한다(수 분 ~ 수 시간).

- 대기용 서버의 IP 주소를 수동으로 갱신한다(수 분 ~ 수 시간).

- 대기용 서버의 IP 주소를 자동으로 갱신하는 제품을 도입한다(수 초 ~ 수 분).

- 그 밖에도 로드밸런서를 별도로 준비하는 방법이 있다.

전제 조건으로 [DB]와 [File]은 어떤 방법으로든 데이터를 동기화해야 하며, 그 방법은 다양합니다.

DBMS의 기능을 이용하거나 공유 스토리지(하드웨어 및 소프트웨어)를 이용하는 방법이 있습니다.

또한, 동기 방식으로는 완전 동기, 비동기 등이 있기 때문에 설계할 때 특히 주의해야 합니다. 완전 동기는 성능을 높이기 어렵고, 비동기는 성능을 높이기 용이하지만 비동기 특유의 동기 방법에 주의할 필요가 있습니다.

참고로, 데이터 동기의 방법으로서 하드디스크 자체를 공유하는 방법도 있지만 전용 디스크 장치 및 케이블 등이 필요하게 되므로 가격이 매우 비싸집니다. 따라서 웹계열의 시스템에서는 잘 사용하지 않습니다.

패턴3. 웹 서버x2, 데이터베이스 서버x1 구성 (다중화, 기능 분할, 스케일 아웃)

이 구성은 패턴1에서 [Web] 측의 성능 문제가 해결되지 않을 때 적용하는 경우가 많습니다.

[Web]은 시스템의 동작을 일일이 계산해서 처리하게 되며, 사용자 수에 따라 처리량이 증가되기 쉽습니다. 따라서, [Web]과 [DB]를 별도의 서버로 나누어 분업시킴으로써 서버의 리소스 편중에 따른 성능 저하를 피하고, [Web] 서버도 2대로 나누어 사용함으로써 시스템 전체의 성능을 향상시킵니다.

이를 위하여 앞에서 소개한 대로 [DB]와 [File]을 분할하고 [Web]을 병렬화합니다.

또한, 1대의 서버로는 감당할 수 없을 만큼 액세스 수가 많은 경우, 2대의 구성에서는 1대가 고장 나면 또다시 처리 능력이 부족하게 되므로 가용성 관점에서는 여전히 문제가 됩니다.

패턴4. 웹서버x2, 데이터베이스 서버x2 구성 (다중화, 기능 분할, 스케일 아웃)

[Web]을 2대의 서버로 구성하고 [DB] 및 [File] 서버에 연결, [DB]와 [File]의 대기용 서버도 준비

이 구성으로는 [Web]의 다중화와 부하 분산 그리고 [DB]의 다중화를 할 수 있습니다.

참고로, 대기용 서버의 [DB]에 대해 참조 SQL을 발행하여 데이터를 취득하는 것은 가능하지만, 부하의 관점에서는 의미가 없으며 가용성이 떨어지기 때문에 사용하지 않는 것이 좋습니다.

현재 운용 중인 서버만으로 처리하기 어렵다면, [File]을 별도의 서버로 분할하여 대기용 [DB
(slave)]를 3대 이상 준비하는 등의 대책을 수립하는 것이 좋습니다.