운영 서버의 이해

 운영서버는 실무에서 사용자들을 대상으로 운영하는 서버를 말합니다.

테스트나 학습용이 아닌 실 사용자를 위해 "운영"이 되기에 서비스의 퀄리티, 쾌적한 네트워크, 중단 없는 가용성이 제공되어야한다고 생각합니다.

 

책에서는 '환경 구성', '코드 배포', '모니터링' 3가지의 단계가 있다고 합니다.

1. 환경구성: 서비스가 작동하는 인프라 구성

2. 코드배포: 신속하고 안전한 서비스 배포

3. 모니터링: 안정적이고 쾌적한 서비스 감시

위 3가지 정도로 저는 이해했습니다.

 

 그래서 이를 위해 인프라 구축부터 모니터링까지 AWS를 통해 구성하는것이 목표입니다.

 

우선 운영 서버가 어떻게 구성되는지 알아봤습니다.

클라이언트는 운영 서버의 애플리케이션을 이용하는 손님이며 데이터 베이스는 애플리케이션의 정보를 모아놓습니다.

예를 들어 애플리케이션은 Apache 웹 서버가 되고, 데이터베이스는 MySQL이 된다고 하면 손님은 옷을 구매하기 위해 옷을 판매하는 사이트에 접근을 했고 회원가입을 통해 손님 정보를 데이터 베이스에 저장했습니다 !!

 

위와 같은 단일 서버는 웹 페이지, 데이터 베이스를 미리 준비한다면 OS 설치부터 웹, 데이터 베이스 연동까지 짧은 시간이 걸릴것입니다.  

 

하지만 장점보다는 단점이 많다고 할 수 있습니다

첫 째: 장애발생 및 대응, 하나의 물리 서버에서 공존하며 독립되어 있지 않기에 자원(CPU, 램, 스토리지 등)이 고갈되거나 접속량이 많아지거나 재해, 이상이 발생하면 장애는 한 곳에서만 발생하는것이 아니고 물리 서버 전체로 번 질 가능성이 있습니다. 그리고 이에 따른 대응 또한 어려울것입니다. 

 

두 번째: 자원 분배, 첫 번째처럼 하나의 물리서버에 애플리케이션, 데이터 베이스가 공존하면 자원 분배는 효율적이고 유동적이지 못 할 것이고, 기능에 맞는 최적화된 설정이 힘들것입니다. 운영하는 서비스는 웹과 데이터 베이스뿐인데 접속량이 많아지면 그저 자원을 확장하거나 업그레이드 하는 방법밖에 없을것입니다.... 소 잡는 칼로 닭 잡는 맥락인것이죠

 

세 번째: 취약한 보안, 데이터 베이스는 관리자, 엔지니어 정도의 접속만 필요할 정도로 유동 접속이 활발하면 안 됩니다 

이는 라우터, 보안 기능으로 포트, IP 접속 통제를 하거나 보안 솔루션을 사용해야하는 부분인데 이 기능을 하나의 독립되지 않은 물리 서버에서 운용하기란.... 쉽지 않을것 같습니다.

 

네 번째: 확장성 결여, 접속량이 증가하면 자원을 추가하면 되지만 물리 서버만 운용하는 방식으로는 한계가 있을것입니다. 자원을 계속 추가하다보면 랙 탑재 공간이 없어질것이고, 결국 물리 서버를 한 대 더 놓는 방법밖에는 없을것입니다.

 

결국에는 물리 서버만 고집하여 운영하면 발생하는 문제를 모아 놓은것 같습니다.

아직 AWS는 잘 모르기에 이를 어떻게 해결하면 되는지 잘 모르겠지만, 만약 온 프레미스 환경이라면 vSphere를 통해 가상머신을 추가하고... DRS... HA... FT 등등... 아직 배울것도 많고 갈 길도 먼 본인이지만 이 정도 문제는 이론적으로라도 해결 방안을 드릴 수 있을것 같습니다.

 그러기에 VMware의 vSphere으로 예를 들자면 물리 서버에 하이퍼바이저(사진에는 vSphere로 나와있지만 ESXi)OS를 탑재하고 그 위에 OS를 놓음으로서 마치 사진의 작은 블럭 하나가 하나의 컴퓨터로서 작동 하는 '가상화'로 해결 할 수 있을겁니다.

 

본론으로 위 문제를 임시방편으로 해결하는 다른 방법으로는

이런 방법으로 애플리케이션과 클라이언트를 분리하는 방법입니다.

우선적으로 데이터 베이스가 별도의 서버가 되었기에 자원을 확보하고 보안 등의 문제는 해결되었지만, 이는 임시방편 같은 느낌인거 같습니다. 서버가 한대 늘었기에 관리 서버가 증가했고 서버 간 지연시간이 발생하며 결국 확장성은 해결하지 못 했습니다.... 물론 이 또한 서버 가상화로 해결 할 수 있습니다 !

 

다음 방법으로는

애플리케이션 이 두 개가 되었고 두 개의 애플리케이션을 데이터 베이스가 바라보는 구성입니다.

클라우드 공부하는 입장에서는 보이는것만 3대의 물리 서버?가 있고 로드 밸런서가 탑재한 물리 서버가 존재한다고 하면 4대의 물리서버가..... 저도 이런 방식으로 구성해본 경험이 있습니다. HAproxy로 L4 계층 로드 밸런싱하여 접속량을 두 개의 웹 서버로 분리하며 데이터 베이스가 두 개의 웹 서버와 연동하여 게시판, 회원 정보를 저장하는 구성을 했습니다. 

그래도 위 방법중에서는 괜찮은 방법입니다. 하지만 책에서는 로드 밸런서에 장애가 발생한다면 그 이후로 부터는 위 구성들과 비슷해진다는 주의가 있습니다. 이럴 경우에는 로드 밸런서를 2 개를 두면 될 것 같습니다 ! Active/Stand by 구성을 하여 상시에는 Active 로드 밸런서가 작동하지만 장애가 발생하면 즉시 Stand by 로드 밸런서가 작동이 되도록 구성하면 될 것 같습니다. vSphere에는 FT나 비슷하게 HA로 가용성을 높이는 방법이 있지만... AWS도 자체 로드 밸런서도 있고 비슷한 기능이 있을것 같습니다. !