[AWS] 운영 서버

운영서버란?

운영 서버는 개발이나 테스트 목적이 아닌, 실제 사용자들을 대상으로 서비스하는 서버입니다.

운영 서버는 테스트 서버와는 다르게 트래픽 대응도 해야하고, 빠른 응답 속도와 높은 가용성을 보장해야 합니다.

 

운영 서버 관리의 세 가지 단계

운영 서버 관리는 크게 '환경 구성', '코드 배포', '모니터링' 세 가지 단계로 나뉩니다.

 

환경 구성은 서비스 하게 될 코드를 구동시킬 수 있는 인프라를 구축하는 것입니다.

코드 배포는 구성한 환경에 최신 버전의 코드를 빠르고 안전하게 배포하는 것입니다.

모니터링은 안정적인 서비스 운영을 위해 서버와 코드에 이상이 없는지 바로 파악하고 대응할 수 있게 도와주는 것입니다.

 

운영 서버의 아키텍쳐

1. 단일 서버

이는 가장 기본 적인 아키텍쳐입니다.

클라이언트(웹 브라우저 등)와 요청을 처리하는 서버 한 대로 구성이 되고, 서버 내에는 어플리케이션 코드와 데이터베이스가 실행됩니다.

이는 어플리케이션과 데이터베이스가 한 서버 내에 있기 때문에 매우 구성하기가 매우 편리하지만,

다음과 같은 단점들이 있습니다.

 

우선, 서비스 장애가 생길 확률이 다른 아키텍쳐에 비해 높습니다.

어플리케이션이나 데이터베이스, 아니면 서버 하드웨어에 장애가 발생하면 해당 부분만 문제가 생기는 것이 아니라

서비스 전체가 구동이 불가능한 상태가 됩니다.

 

다음으로 서버 자원을 비효율적으로 사용하게 됩니다.

어플리케이션과 데이터베이스는 각자 중요한 자원의 종류가 다르고, 최적화를 위해 필요한 OS 설정이 다릅니다.

이를 모두 만족시키기 위해 필요 이상의 설정을 해야할 수 있습니다.

 

다음으로 보안성이 떨어지게 됩니다.

데이터베이스는 보안상 포트나 IP 등의 접속 지점이 최소한으로 되어야 하지만,

어플리케이션은 특성상 다양한 IP 주소와 포트 번호에 대해 요청을 받을 수 있어야 하므로 데이터베이스가 공격당할 가능성이 생깁니다.

 

2. 어플리케이션/데이터베이스 서버 분리

이는 단일 서버 구성에서 데이터베이스 따로 빼서 구성한 아키텍쳐입니다.

이는 어플리케이션과 데이터베이스가 다른 자원을 자원하기 때문에

단일 서버의 단점의 많은 부분(장애 확률, 자원의 비효율성, 보안성 등)들이 해결됩니다.

 

다만 서버를 두 대를 관리해야 하기 때문에 단일 서버에 비해 구성의 복잡성이 증가하게 되고,

서버 사이의 지연과 네트워크 보안을 고려해야 합니다.

 

3. 서버 단위의 로드 밸런서

위의 1, 2번과 달리 클라이언트가 어플리케이션 서버와 직접 통신하지 않고, 로드 밸런서라는 서버와 통신을 하게 됩니다.

로드 밸런서가 여러 개의 어플리케이션 서버와 통신을 하게 됩니다.

클라이언트는 로드 밸런서와 통신을 하고, 로드 밸런서가 클라이언트에게 받은 요청을 어플리케이션 서버들에게 분산키겨 주고,

어플리케이션 서버들이 요청을 처리하고 응답은 로드 밸런서를 통해 클라이언트에게 전달이 됩니다.

 

이는 서버의 수를 여러 대로 늘려서 자원을 확장하는 스케일 아웃이 가능해집니다.

그리고 어플리케이션 서버 중 일부가 장애가 발생하여도, 로드 밸런서가 부하를 분산시켜주므로

정상 서버가 하나라도 있으면 구동이 가능해지며 장애를 최소화 할 수 있습니다.

하지만 로드 밸런서가 장애가 생긴다면 나머지 서버들이 정상이어도 장애가 발생하게 됩니다.

(OSI 7 Layer에서 L4 스위치라고 이야기하는 것이 로드 밸런서의 역할을 하는 장비입니다.)

- 이 아키텍쳐는 실제로 구성을 해본 적이 있는데.. 구성하기가 복잡해서 매우 고생했던 기억이 있습니다.

 

 4. 서버 내 어플리케이션 단위의 로드 밸런서

이는 여러 서베에게 요청을 보내는 로드 밸런서 이외에도 서버 내에서 어플리케이션에게

요청을 분산시키는 어플리케이션 단위의 로드 밸런서가 추가된 아키텍쳐입니다.

어플리케이션 서버 안에서 같은 어플리케이션을 여러개 만들고, 서버로 들어온 요청을 내부의 여러 어플리케이션 중 하나로 보내줍니다.