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

시작하기 전에

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

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

오늘의 주제

오늘은  지난 포스팅에 이어 AWS를 이용한 운영 서버 관리 2편 입니다. (짝짝짝)

이번 시간에는 ASG( Auto Scaling Group) 와 ELB( Elastic Load Balancer )에 대해서 알아 보도록 하겠습니다.

우선, ASG와 ELB가 무엇인지 알아야 할테니 시작하겠습니다.

ASG( Auto Scaling Group) 란?

Auto Scaling 이란, 자동으로 서버 인스턴스에 대해 크기(Scale)을 관리해주는 기능입니다. 과거에는 실제 서버 증설을 위해서 하드웨어를 보강해주거나, 트레픽의 피크(고점)에 대해서 예상을 하여 미리 서버를 증설해 두었기 때문에 낭비되는 자원이 굉장히 많았습니다. 현재에는 물리적인 서버대신 Cloud 서비스를 이용한 가상화 기술이 늘어나고, 상황에 따라 자동으로 같은 환경을 가지고 있는 서버를 자동으로 늘리거나 줄여주는 방법인 "Auto Scaling"을 사용합니다. 사용자는 특정상황(서버리소스, 응답속도, 처리량, 시간)에 대해 서버 증설에 대한 옵션을 설정할 수 있고, 최대 /최소 몇대의 EC2 Insatance를 사용할 지 설정할 수 있습니다. 특히, Amazon에서는 ASG라는 기능을 통해 Auto Scaling을 관리합니다.

현재 ASG를 설정할 때, 인스턴스 조정 정책 조건입니다.

1. 대상당 어플리케이션 로드 밸런서 요청수

2. 평균 CPU 사용률

3. 평균 네트워크 입력량

4. 평균 네트워크 출력량

총 4가지의 조건에 따라 인스턴스의 개수를 AUTO SCALING 가능 한 것 같습니다.

전체적인 구성을 살펴보면 다음과 같습니다.

ASG의 응용

1. CPU, 메모리, 네트워크 응답 속도 등의 지표를 통하여 갑자기 몰려드는 요청이나 , 특정 인스턴스에 장애가 나더라도 사람이 직접 나서기 전에 시스템이 자동으로 대처하게 할 수 있습니다.

2. Auto Scaling Group에서 어떤 경위로 인스턴스 수가 자동으로 변경됐는지 아메일로 알림을 받아 서비스가 이상이 생겼는지 파악할 수 있습니다.

3. 서비스 특성 상 사용자가 몰리는 시간, 몰리지 않는 시간에 최소/최대 값을 지정하여 서버 비용을 효율적으로 관리가 가능합니다.

ELB (Elastic Load Balancer) 란?

 Elastic Load Balancer란, AWS에서 제공하는 Load Balancer 입니다. 일반적으로 Load Balancer를 구현하기 위해서는(L4 level) 직접 서버를 구축하여 관리를 해야 하지만, AWS는 자체적으로 Load Balancer 기능만 하는 서버기능을 제공하여 줍니다. 우리는 ELB를 통해 어떤 Target 그룹을 대상으로 Load Balancer를 실행할 지 정해줄 수 있습니다. 여기서 타겟은 위에서 말한 ASG가 될 수도 있고, 그냥 단일 인스턴스가 될 수도 있습니다.

ELB 생성 과정

- ELB를 생성해 줍니다. ( 요청을 보낼 포트, 가용영역, ELB의 이름 등을 설정합니다.)

- 보안그룹을 생성해 줍니다. (인바운드, 아웃바운드를 설정해 줍니다)

- 대상 그룹에 관한 설정을 진행합니다. ( 관리할 그룹의 이름, 헬스체크를 위한 경로&포트 설정)

- 대상 그룹에 포함 시킬 인스턴스 or ASG를 선택하여 줍니다

위의 과정을 완료하게 되면, ELB는 설정한 대상그룹을 향하여 헬스체크를 위해 주기적인 요청을 보내며, 적절한 상태를 갖고 있는 인스턴스에 대해서만(status : 200) 가용할 수 있는 서버로 분류하여 요청을 분산 시킵니다.

ELB에서 각 인스턴스 혹은 ASG로 상태검사를 하는 과정 입니다.

FailOver (장애극복)

시스템의 특정 서버에 장애가 발생했을 때 전체 시스템이 다운되는 것이 아니라 예비 시스템이 즉시 요청을 대신 처리하여 최소한의 에러만 발생하고 문제 없이 서비스가 돌아가게 하는 과정을 말한다.

서버에 발생할 수 있는 장애의 종류는 무한하고 무조건 발생하게 되어있다.

따라서 운영 서버라면 꼭 서버를 2대 이상 띄워서 failover가 가능하도록 설계해야 한다.

Monolithic Architecture

제품 전체를 하나로 합쳐서 관리하는 구조,  기존의 전통적인 웹 시스템 개발 스타일이다. 

여기서 "기존의 전통적인" 이라는 말을 생각해보면 요즘은 잘 사용하지 않는 구조라는 느낌이 강하다.(물론 나만 그럴 수도 있다) 잘 사용하지 않는대에는 분명 이유가 있을 것이다. 장점과 단점에 대해서 알아보자.

Monolithic 구조의 장점 & 단점

장점

- 서버를 구성하는데 간단하다.

- 기술 스택이 통일되어 있기 때문에 개발하기도 쉽다.

- 하나의 어플리케이션만 배포하면 된다.(시스템의 규모가 작은경우에 유리)

- 스케일 아웃에 유리하다

단점

- 하나의 코드 뭉텅이로 되어있기 때문에 수정하는 비용이 크다.

- 한번 정해진 기술과 버전을 오래써야 한다.

MicroService architecture

마이크로 서비스 아키텍쳐는 대용량 웹서비스가 많아짐에 따라 정의된 아키텍쳐이며,  근간은 SOA (Service Oriented Architecture)에 두고 있다. SOA는 엔터프라이즈 시스템을 중심으로 고안된 아키텍쳐이고, 마이크로 서비스 아키텍쳐는 대용량 웹서비스 개발에 맞는 구조로 사상이 경량화 되고, 대규모 개발팀의 조직 구조에 맞도록 변형된 아키텍쳐이다. 

( 우리가 1차포스트와 위에서 알아본 구조들은 마이크로 서비스 아키텍쳐에 관한 서버 구성들이었습니다. )

MicroService 장점& 단점

장점

1. 제품이 하나의 기술, 버전에 묶여있지 않아도 된다.

2. 도메인별 어플리케이션들이 느슨하게 연결되어있기 때문에 추후 아키텍처 변화에 유연하게 대처할 수 있다.

3. 여러 사람들이 큰 규모의 제품을 개바할때 각 서비스간의 스펙만 맞추고 개발을 진행하면 되기 때문에 편하다

4. 전체 배포를 하지 않아도 되기 때문에 배포하기가 더 쉬워진다.

단점

1. 복잡도가 올라간다.

2. 규칙 없이 막 사용했다간, 사람보다 더 많은 기술 스택이 쌓일 수 있다.

3. 문서화가 잘 안되어있다면 누구도 손대지 못하는 서비스가 될 수 있다.

4. 서비스들간 연동 테스트 하기 힘들다.

5. 테스트, 배포 모니터링 자동화가 잘 되어있어야만 가능하다.

가상 네트워크 - VPC (Virtual Private Cloud)

- AWS에서는 시스템 자체적인 논리적 가상 네트워크를 제공한다.

- 필요에 따라 네트워크를 만들어 Private subnet, Public subnet을 운용할 수 있다.

- Public Subnet 내부의 인스턴스들은 외부 네트워크와 연결 가능한 public IP와 VPC 안에서만 사용 가능한 private IP를 할당 받는다.

- Private subnet 내 인스턴스는 private IP만 할당받는다.

- 외부와 연결할 필요가 없는 인스턴스 들은 private subnet에 두고, 외부와 연결해야 하는 인스턴스들은 public subnet에 둘 수있다.

Amazon VPC 구조

사실 ELB와 ASG를 AWS에서 직접 생성하고 설정하는 과정에 대해서 자세하게 포스팅하고 싶었으나...

밀린 업무에 대해서 퍼포먼스가 나지 않아서 매일매일 피곤에 찌들어 있어 작성하지 못하였습니다. ( _ _ )

여유 시간이 생기게 된다면 각 기능에 대해 구성하는 방법을 자세히 포스팅 하도록 하겠습니다.