AWS를 이용한 운영 서버 관리(1편) - 서버 아키텍처에 대하여

시작하기 전에!

해당 블로그에 작성되는 글은 주인장의 지극히 주관적인 생각이 다수이며, 대부분의 지식은 구글링을 통해 얻고 있기 때문에 옳지않은 정보가 있습니다. 

잘못된 부분이나 수정해야 하는 부분이 있다면 과감히 덧글을 남겨주세요! 모르는게 많은 새싹입니다

오늘 포스팅의 주제는 제목에서도 볼 수 있지만,  "AWS를 이용한 서버 운영 관리"를 주제로 제가 들은 강의를 기반으로 작성 할 예정입니다. 이게 어떻게 보면.. 강의 정보 유출(?) 같은게 되는건지.... 저는 그냥 복습을 위해 작성하는 거긴한데 기분이가 조금 찝찝하기도 하네요. 시작! 해보겠습니다.

자주 사용되는 서버 아키텍처

1. 단일 서버 구조

가장 단순하고 구성하기 쉬운 구조입니다.

하나의 서버안에 서비스에 필요한 모든것이 올라가 있습니다. 그렇기 때문에 어떤 기능에 얼마만큼의 리소스가 소비되는지 파악하기 힘든 단점이 있습니다. 또한 Scale up, Scale out에 굉장히 제한 적입니다.

여기서 잠깐! Scale up, Scale out 약간은 생소할 수 있는 단어라 알아보도록 하겠습니다.

Scale Up, Scale Out 이란?

각각의 주제는 서버의 처리 능력을 향상시키는 방법이며, 두 방법은 서로 상호 보완적입니다.

우선, Scale Up이란 서버 능력자체를 향상시키는 방법입니다.  이해를 위해 시각자료를 이용해 봅시다!

위의 사진을 보면 아마존 EC2 프리티어를 만들때 CPU개수와 RAM을 선택하게 됩니다. 현재 CPU는 1개, RAM은 1GiB 입니다. 차후에 트래픽이 감당이 되지않아. 서버의 성능을 향상시키고자 CPU의 개수는 100개 RAM용량은 100GiB로 늘려 버렸습니다.

바로  위의 과정이 Server를 "Scale Up" 하는 과정입니다. Scale Up를 "수직 스케일" 이라고 부르기도 합니다.

그러면 Scale Out은 뭘까요? 대충 느낌이 오실꺼라 생각합니다. "Scale Out"은 "수평 스케일"이라고도 불리우며 물리적인 서버의 개수를 증가시켜주는 과정을 통해 서버의 처리능력을 향상시키는 것을 말합니다.

2. Application/ DB 분리 구조

말그대로 단일서버(Application과 DB가 한 서버에 올라가 있는 구조)에서 Application과 DataBase를 분리시킨 구조 입니다. 서버의 리소스가 어디에 분배되는지 파악이 가능해지므로 부족한 리소스에 대해 Scale Up/Out이 자유로워 집니다. 단일 서버 보다는 좀 더 복잡한 구조를 가지게 됩니다.

Application과 DataBase, 두 개의 서버로 분리되기 때문에 두 서버간에 latency가 발생하게 됩니다.

또 나왔습니다. latency가 뭘까요? 그래서 한번 찾아 보았습니다.

Latency란?

Latency란, 지연 혹은 대기시간(delay)입니다. "송신자가 발송한 패킷이 서버에 도달하는 시간" , "송신자가로 발송한 패킷이 다시 송신자에게 되돌아오기까지의 시간" 등 관점에 따라 다르게 바라볼 수 있습니다. Application/DB 분리형 구조와 연관 시켜 생각해볼 때 , "서버가 분리됨에 따라 두 서버 사이의 지연시간(Latency)가 발생할 수 있다" 는걸 생각하셨으면 좋겠습니다.

3. 서버단위 Load Balancer

Load Balancer를 통해 서버를 분기시켜주는 구조 입니다. Load Balancer는 하나 혹은 다량의 서버를 바라보고 있기때문에, 하나의 서버에 오류가 발생하더라도 패킷을 수신하기에 알맞은 서버로 요청을 보내주는 구조입니다. Load Balancer 덕분에 서버단위 Load Balancer에서는 Scale out이 자유롭습니다. 하지만 Load Balancer에 문제가 생기게 되면 전체적인 시스템 장애를 발생 시킵니다.

4. 앱 단위 Load Balancer(Reverse Proxy)

하나의 서버에서 여러개의 Application을 구동할 수 있게되는 구조 입니다.