3. 컴퓨팅 서비스

컴퓨팅 서비스는 애플리케이션을 기동 시키는 인프라 스트럭처 서비스로 시스템 아키텍처의 핵심을 담당한다. 시험에도 많은 문제에서 제대로 이해하고 있나 지식을 확인하기 때문에 각 서비스의 특징이나 기능, 설계 시의 주의해야 할 점이나 코스트에 관해 이해해둘 필요가 있다.

여기선 아래 3가지의 서비스에 대해 상세히 알아보자

• EC2 ( Amazon Elastic Compute CLoud )
• ECS ( Amazon Elastic Container Service )
• Lambda ( AWS Lambda )

EC2

가상 서버를 제공하는 컴퓨팅 서비스이다. 필요한 수 만큼 빠르게 서버를 만드는 것이 가능하며, 말하자면 IaaS 형 서비스이다. Elastic Load Balancing (ELB)나 Autu Scaling이라고 하는 서비스와 조합하는 것으로 부하가 발생할 시 동적으로 서버의 대수를 변경하는 등 의 클라우드 다운 방법으로 사용이 가능하다.

ECS

Docker 컨테이너의 실행 환경을 제공하는 서비스이다. 이 서비스가 등장하기 이전까지 AWS 에서 Docker를 이용하기 위해서는 EC2 위에 컨테이너 관리용 소프트웨어를 설치할 필요가 있었다. ECS는 서비스로서 Docker 환경을 제공하고 있기 때문에 이용자가 설정, 구축한 항목을 그대로 AWS 상에서 설정할 수 있다.

Lambda

서버를 준비하지 않더라도 프로그램을 실행시킬 수 있는 환경을 제공하는 서비스이다. 서버를 준비하지 않는 아키텍처 즉 서버리스 아키텍처의 중심이라고 할 수 있는 서비스로서, 확장성이나 코스트 효율의 면에서 메리트가 강하다. 서버의 셋업이나 메인테넌스가 필요 없기 때문에, 애플리케이션 개발에 집중할 수 있다.

 

이러한 서비스들은 어떤 것이 좋다. 어떤 것이 우수하다 등과 같은 것이 아니라, 기능 요소나, 비기능 요소에 대하여 적절한 것을 선택하여 또는 조합하여 이응하는 것들이다. 각 서비스의 특징을 기억해두고, 각 서비스의 유스케이스를 이해하여, 과거에 담당했던 안건을 다시 한번 대응한다면 어떤 식으로 설계할까 와 같은 긋들을 생각해봄으로써 시험에 나오는 질문에 좀 더 쉽게 대응할 수 있을 것이다.

EC2

온프레미스의 환경에 서버를 준비할 경우 OS 의 인스톨은 물론, 서버의 조정, 렉 설비, 네트워크나 전류 관리 등 다양한 작업이 필요하다. 서버 구성에는 리드 타임이 필요하기 때문에 새로운 서비스를 구축할 때에는 시간을 들여 견적을 내고, 필요에 따라 여유분을 추가한 스펙을 상정하여 구성을 준비했다. 하지만 이러한 견적에는 중요한 것이 배제되어 있는데, 처음 예상을 넘어선 리퀘스트를 처리하지 못하여 비즈니스적인 찬스를 놓치거나, 역으로 서비스가 생각보다 인기를 끌지 못해 인프라 리소스가 남아 도는 상황이 발생하는 등 결과적으론 적자가 이어지는 상황을 많이 경험했을 것이다.

EC2는 가상 서버를 제공하는 컴퓨팅 서비스이다. 인스턴스라고 하는 단위로 서버를 관리하고 있으며, 버튼을 몇 번 누르는 것 또는 CLI 를 이용할 경우 커맨드 몇 번 입력하는 것으로 새로운 인스턴스를 작성할 수 있다.

리퀘스트 수의 증감에 따른 인스턴스 수의 증감으로 대응

그 때문에 온 프레미스 환경과 비교하여 서버의 조정과 리드 타임이 획기적으로 줄어든다. 서비스를 론칭 하기전에는 최소한의 스펙이 필요하지만, 론칭 후에 예상 이상의 페이스로 서비스가 급성장하여 인스턴스의 수를 늘리거나 또는 인스턴스의 성능을 올려야 하는 등의 대응이 가능해진다.

또한 아쉽게도 금방 거품이 꺼져 인스턴스의 수를 줄이거나, 스펙을 내려 불필요한 인프라 비용이 발생하지 않도록 방지할 수 있다.

 

이렇듯 EC2를 이용하는 것으로 인프라 리소스를 유연하게 최적화시키는 것이 가능하다. 그렇기에 사전에 견적을 내는데 시간을 들이는 것이 아닌, 론칭할 때까지 시간을 얼마나 단축시키는가, 론칭 후의 트라이 엔드 에러나 개선 활동을 좀 더 활발하게 회전시킬 수 있기에 비즈니스적 가치를 낳는 행위에 주력하는 것이 가능하다.

또한 고객을 위한 사이트뿐만 아니라 사내의 기반 시스템에도 AWS를 이용하는 경우가 늘어나고 있다. 성수기와 비수기별 인스턴스 리소스를 동적으로 변경, 새로운 앱을 검증하기 위한 환경을 3개월만 준비해두는 것과 같이 유연하게 인프라 리소스를 이용할 수 있기 때문에, 사내를 대상으로 하는 시스템에도 EC2의 메리트는 매우 크다고 할 수 있다.

 

EC2를 기동 할 때에는 기반이 되는 이미지를 선택하여 인스턴스를 작성한다. 이 이미지를 Amazon Machine Image라고 부르며 줄여서 AMI라고 표기한다.

AMI에는 Amazon Linux AMI나 Redhant Enterprise Linux, Microsoft WIndows Server 등과 같은 AWS가 준비해둔 것들과, 각 벤더가 서비스를 독자적으로 설치한 AMI가 있다. 또한 각 이용자가 인스턴스의 일부를 AMI로서 백업하는 것도 가능하다. AMI를 제대로 활용하는 것으로 구축 시간을 단축시키거나, 같은 인스턴스를 간단하게 늘이는 것도 가능하다.

EC2의 성능에 대한 접근 방법

EC2에는 인스턴스 타입이라고 하는 형태로 인스턴스의 스펙을 선택할 수 있다. 인스턴스 타입에는 m5.large나 p3.xlarge라고 하는 형태로 표기되고 있다.

선두의 m이나 p는 인스턴스 패밀리를 나타내며, 어떤 서비스에  최적화되어 있는 인스턴스 타입인지를 의미한다. 예를 들어 컴퓨팅에 최적화된 인스턴스 타입은 c로 시작하며 c5나 c4와 같은 타입이다.

또한 메모리를 중시한 인스턴스의 타입은 r로 시작흔 r5나 r4와 같은 것들이 있다.

인스턴스 패밀리 뒤에 오는 숫자는 세대를 나타낸다. 큰 숫자일수록 최신 세대이다. 일반적으로 세대가 최신일수록 스펙이 좋거나 가격이 비싸다. xlarge나 8 xlarge의 경우 인스턴스 사이즈를 나타내며, 클수록 스펙이 높은 인스턴스 타입이 된다. 예를 들어 범용적인 인스턴스 패밀리인 m5 게열의 인스턴스 타입은 아래와 같은 종류가 있다.

구분	vCPU	Memory(GB)
m5.large	2	8
m5.xlarge	4	16
m5.2xlarge	8	32
m5.4xlarge	16	64
m5.8xlarge	32	128
m5.12xlarge	64	192

인스턴스 사이즈가 배가 되면 스펙도 배가 되는 것을 알 수 있다. 이것들의 정보는 상황에 따라 변경될 수 있기 때문에 AWS의 공식 문서를 확인 하는 것이 가장 바람직하다.

 

또한 인스턴스의 성능을 정하는 다른 중요한 요소로서 디스크 기능이 EBS( Elastic Block Store)가 있다. 

EC2에선 일반적으론 통신으로 사용하는 네트워크 영역과, EBS와 주고받는데 이용하는 영역을 공유하고 있다. 그렇기 때문에 디스크 I/O, 외부와의 리퀘스트와 함께 발생할 경우, 영역이 부족해질 경우가 발생한다. 이런 경우 이용할 수 있는 옵션이 EBS 최적화 인스턴스이다. 이 옵션을 유효화 하면 보통의 네트워크 영역과 별도로 EBS용 영역이 확보된다. 그렇기에 디스크 I/O가 높아져도 외부로의 통신에는 영향이 없다. EBS 최적화 인스턴스는 어느 정도 큰 인스턴스 타입에서만 이용할 수 있기 때문에 공식 도큐먼트에서 이 옵션을 활용할 수 있는지를 확인해 보는 것이 좋다.

EC2의 비용에 대한 생각 방법

EC2는 인스턴스를 사용한 만큼 과금되는 종량 과금 형 서비스이다. EC2의 서비스의 가격은 아래의 요소에 의해 이루어진다.

• 인스턴스가 Running 상태로 지속 된 시간
• Running 상태 인스턴스의 타입, AMI, 인스턴스가 존재하는 리전

인스턴스에는 기동 중 (Running), 정지 중 (Stopped), 삭제 완료 (Terminated)의 3가지 상태가 존재한다.  EC2에는 기동 중인 인스턴스만 과금의 대상이 되므로, 일시적으로 중지 상태로 둔 인스턴스나, 삭제된 인스턴스는 과금의 대상이 아니다. 하지만 중지 중의 인스턴스도 EBS의 비용은 과금되므로 이를 주의해야 한다.

인스턴스 타입	시간 단가 (USD/시간)
m5.large	0.124
m5.xlarge	0.248
m5.2xlarge	0.496
m5.4xlarge	0.992
m5.8xlarge	1.984
m5.12xlarge	2.976

기동 하고 있는 인스턴스는 인스턴스의 타입에 의해 과금이 정해진다. 인스턴스의 AMI에 의해 결정되기 때문에 이 또한 공식 도큐먼트를 잘 살펴봐야 한다.

예를 덜어 m5.large의 인스턴스를 2대 3시간 기동시 키는 경우 0.124 * 3 * 2 = -. 744 USD의 요금이 발생하게 된다. ( EBS의 요금은 미포함 ) 시간 단가는 유동적으로 변하기 때문에 시험을 치르는 식의 접근 방식으로선 상세한 숫자를 전부 기억할 필요는 없지만, 요금의 견적을 내는 방법에 대해선 알아둘 필요가 있다.

스팟 인스턴스와 리저브드 인스턴스

위에서 설명한 EC2 인스턴스의 가격은 온디맨드 인스턴스라고 하는 가장 일반적으로 사용하는 패턴이라 할 수 있다. EC2에는 이 외에도 스팟 인스턴스와 리저브드 인스턴스라고 하는 구매 옵션이 존재한다.

스팟 인스턴스

AWS의 여유분의 EC2 리소스를 입찰 형식으로 저렴하게 이용할 수 있는 방식이다. 예를 들어 m4.large는 온디맨드로 이용할 경우 시간당 0.129 USD의 이용료가 발생하지만, 만약 m4.large용 리소스에 여유가 있을 경우 0.095 USD 가격으로 스팟 입찰에 성공할 경우  해당 가격으로 인스턴스를 이용할 수 있다. 하지만 다른 이용자로부터 m4.large의 이용 리퀘스트가 늘어나 여유분의 리소스가 없어질 경우 인스턴스가 자동으로 중단된다. 이런 사용이 허용될 경우 예를 들어 개발용 환경이나 기계학습의 데이터 학습을 위한 일시적인 스펙이 높은 인스턴스를 사용하고 싶을 경우 주로 사용하는 옵션이기도 하다.

리저브드 인스턴스 (Reserved Instance)

장기간의 이용을 계약하는 것으로 할인을 받을 수 있는 옵션이다. 예를 들어 m4.large 타입을 1년간 스탠다드 RI로 구매할 경우 약 37%의 비용을 삭감할 수 있다. 서비스를 론칭하고부터 늦어도 시간이 흘러가면 인스턴스 타입을 고정해도 된다는 판단이 들었을 경우 RI를 구매하는 것을 검토하길 바란다.

인스턴스의 분류와 용도

솔루션 아키텍처가 시행하는 설계 업무에는 애플리케이션의 용도에 따라 적절한 인스턴스 타입을 결정하는 일도 포함된다. 그렇기 위해선 분류 방법과, 인스턴스 패밀리 별 주요한 용도를 파악해둘 필요가 있다. 우선 현재 사용 중인 5가지 분류를 알아보자.

• 범용
• 컴퓨팅 최적화
• 메모리 최적화
• 고속 컴퓨팅
• 스토리지 최적화

범용

가장 이용범위가 넓으며 CPU와 메모리의 밸런스가 잘 잡혀 있다 ( m5. t3 등 )

컴퓨팅 최적화

CPU의 성능이 높다. 현재 (c5와 같은 c 계열)

메모리 최적화

메모리 용량이 큰 것들이다. r5나 x1과 같은 여려 계열이 있지만, 일반적으로 사용하는 것은 r 계열이다.

고속 컴퓨팅

GPU 등 CPU 이외의 계산 리소스가 강화되어 있다. 굉장히 세분화가 되어 있지만, 이미지 처리 용의 p계열과, 기계학습을 담당하는 g 계열이 가장 많이 사용된다.

스토리지 최적화

이쪽 또한 굉장히 세분화되어 있지만 HDD를 사용하는 d2와 SSD를 사용하는 l3를 기억해두는 것이 좋다.

Saving Plans 과 스케줄링된 리저브드 인스턴스

리저브드 인스턴스와 비교하여 보다 유연한 형식으로 할인을 받을 수 있는 플랜으로서 2019년 11월 부터 Saving Plans 이라는 서비스가 제공되었다. 리저브드 인스턴스와의 차이는 인스턴스의 이용수가 아니라 EC2 인스턴스의 이용수에 대한 접근 방법이다.

Saving Plan에는 Compute Saving Plans 와 EC2 Instance Savings Plans 2종류가 있다.

EC2 Instance Saving Plan는 기존의 리저브드 인스턴스와 같은 리전이나 인스턴스 패밀리를 지정하여 구입한다.

Compute Saving Plan은 리전이나 인스턴스 패밀리와 관계없이 모든 EC2 인스턴스에 대상으로 단위 시간에 따른 이용료를 책정하고 구입한다. 또한 EC2 뿐만 아니라 Lmabda, Fargate도 대상이 된다. 꽤 유연성이 높고 잘 사용하면 보다 유리한 조건으로 컴퓨팅 리소스를 이용할 수 있다.

Savings Plans의 요소

또한 리저브드 인스턴스의 구입 방법의 패턴으로 스케줄링 된 리저브드 인스턴스라고 하는 것이 있다. 이것은 1년 안에 매울, 매주, 매월 같은 일정 기간만 사용하는 패턴으로 평일의 일하는 시간만 사용하는 등의 방법으로 이용료를 삭감할 수 있는 기능이 있다. 대상 인스턴스가 c3, c4, m4, r3로 몇 개 없으며, 최신 인스턴스만 대상이 되지만 이러한 삭감 방법도 있다는 것을 알아두는 것이 좋다.

ELB

지금까지 하나의 EC2 인스턴스에 대해 알아보았다. 론칭 이후에 서비스의 인기가 올라가기 시작하여 부하가 발생한다 해도, AWS에는 수많은 타입의 인스턴스가 준비되어 있어, 어느 정도까지는 인스턴스의 타입을 올리는 것으로 대응 가능할 수 있을지도 모른다. 이렇듯 직접적인 서버의 스펙 상승으로 대응하는 방법을 스케일 업이라고 한다.

하지만 스케일 업에는 한계가 있으며, 언젠가는 인스턴스 타입의 상한선에 부딪힐 수도 있다. 또한 단일 인스턴스의 운용을 계속하면 해당 인스턴스의 정지 = 해당 서비스의 정지라는 상태가 되어 버린다. 이렇듯 어떤 한 부분이 멈추면 전체가 멈춘다 라는 것을 단일 장애점 (Single Point Of Failure, SPOF)라고 하며, 단일 장애점 문제가 있는 설계는 결코 추천할 수 없다. 시험상에도 어떤 식으로 단일 장애점을 만들지 않는가와 같은 시점은 중요하기 판단하기 때문에 기억해 두는 것이 좋다.

 

그렇다면 고부하에 대응하는 설계는 어떤 식으로 설계하는 것이 좋을까? 대상의 레이어에 따라 답이 다르겠지만 웹 서버의 레이어에서 베스트 프랙티스라고 하는 것은 EC2 인스턴스를 수평으로 세우는 스케일 아웃이다. EC2 인스턴스를 복수로 나란히 새워 그 앞에 로드 밸런서를 두어 리퀘스트를 각 인스턴스로 분산시키는 것이다.

 

로드 밸런서 로서는 EC2 상에 BIG-IP라고 하는 제품을 도입하는 것도 가능하지만, 로드 밸런서 매니지드 서비스인 Elastic Load Balacing (ELB)를 이용하는 것을 추천한다.

ELB의 종류

ELB에는 아래 3가지의 로드 밸런서가 있다.

• Classic Load Balancer (CLB) : L4, L7 레이어의 부하 분산을 행한다.
• Application Load Balancer (ALB) : L7 레이어의 부하 분산을 행한다. CLB 보다 이후에 등장하였으며, 기능 또한 풍부하다
• Network Load Balancer (NLB) : L4 레이어의 부하분산을 행한다. HTTP(S) 이외의 프로토콜 통신의 부하 분산을 하고 싶을 경우 사용한다.

CLB와 ALB는 같은 애플리케이션 레이어의 부하 분산을 행하고 있지만, 뒤에 나온 ALB의 쪽이 보다 저렴한 가격에 기능 또한 풍부하다. 구체적인 기능으로는 WebSocket이나 HTTP/2에 대응하는 것, URL 패턴에 의한 분산 방법을 바뀐 패스 베이스 라우팅 기능이 제공되는 것을 들 수 있다.

NLB는 HTTP(S) 이외의 TCP 프로토콜 부하 분산을 행하기 위한 것이다. 로드 밸런서 자체가 고정 IP 주소를 가지는 특징이 있다.

ELB의 특징

매니지드 서비스인 ELB를 사용하는 메리트로서 ELB 자체의 스케일링을 들 수 있다. EC2 인스턴스상 로드 밸런서를 도입하는 경우에는 해당 인스턴스가 보틀넥이 안되게 하기 위한 설계가 필요하다. 그것에 대하여 ELB를 사용할 경우, 부하에 대하여 자동적인 스케일링 설계가 되어 있다.

주의점으로 알고 있어야 하는 부분으론 해당 스케일링이 순식간에 완료되는 것이 아니라는 것이다. 그렇기 위해선 몇 분 만에 빠르게 부하가 걸리는 경우, 예를 들어 티비에 서비스 광고가 나오거나, 론칭 직전에 성능 시험을 행하는 경우, 단계적인 스케일링 스피드에는 못 따라갈 수도 있다.

혹시 이렇게 급격하게 늘어나는 부하량(스파이크) 을 예상할 수 있을 경우 사전에 ELB 프리 워밍을 신청해 두는 것이 좋다. 해당 시간에 맞춰 ELB가 스케일링 상태로 진입하게 할 수 있다.

또한 ELB의 커다란 이점으로서 헬스 체크(Health Check) 기능이 있다. 헬스 체크는 설정된 순간에 휘하에 있는 EC2에 리퀘스트를 날려 각 인스턴스가 정상적으로 동작하고 있는지를 확인하는 기능이다. 혹시 문제가 생긴 인스턴스가 있을 경우 자동적으로 잘라내고, 이후 정상으로 돌아온 타이밍에 새롭게 인스턴스를 ELB에 물리게 된다. 헬스 체크에는 아래와 같은 설정 값이 존재한다.

• 대상 파일 (index.php)
• 헬스 체크 빈도 (30초 단위)
• 몇 번 연속으로 리퀘스트에 실패할 경우 문제가 있다 판단할 것인가 (*회)
• 몇번 연속으로 리퀘스트가 성공할 경우 문제가 해결되었다고 판단할 것인가 (*회)

혹시 웹 서버뿐만 아니라 DB 서버까지 정상적으로 답하는 것을 확인하고 싶을 경우 DB에 리퀘스트를 날려 파일을 헬스 체크의 대상으로 한다. 또한 위의 설정이라면 OK 설정을 받을 때까지 5분의 시간이 걸린다. 좀 더 짧은 시작으로 OK 판정을 받고 싶다면 헬스 체크 빈도를 짧게 하며 OK를 판단하는 횟수를 좀 더 줄이는 것이 좋다.

Auto Scaling

시스템의 이용 상태에 대하여 자동적으로 ELB에 물려있는 인스턴스의 수를 늘리거나, 줄이거나 하는 기능이다. 인프라 리소스를 간단히 조달 가능하며, 쓸모없어지게 되면 버리는 것도 가능한 클라우드 이기 때문에 손쉽게 사용할 수 있는 기능이다.  Auto Scaling에는 다음과 같은 항목을 설정할 수 있으며, 자동적인 스케일 아웃, 스케일 인을 실현할 수 있다.

• 최소 인스턴스 수 유지
• 최대 인스턴스 수 유지
• 인스턴스의 수를 늘리는 조건을 늘린다.
• 인스턴스의 수를 줄이는 조건을 늘릴 수 있다.

또한 인스턴스의 수를 줄일 때에 어떤 인스턴스를 삭제할지 예를 들어 기동 시간이 가장 오래된 인스턴스부터 삭제와 같은 설정이 가능하다.

Auto Scaling을 이용하는 것으로 성수기 피크 기간은 인스턴스의 수를 늘렸다가, 비수기나 심야 시간과 같은 리퀘스트 수가 줄어들 때에는 그것에 맞춰 인스턴스를 운용하는 것이 가능해진다. 항상 리소스 수를 최적화시킬 수 있으며, 예상을 넘어선 리퀘스트를 처리하지 못하고 비즈니스 찬스를 놓쳐 서비스가 성장하는 시기를 놓치는 실수를 반복하지 않을 수 있다.

또한 Auto Scaling의 메리트로는 장애에 대한 면역을 높일 수 있다는 점이다. 예를 들어 인스턴스의 수를 최소, 최대 2배로 설정할 경우 한쪽 인스턴스에 문제가 생길 경우에는 헬스 체크에 의해 하나는 버려지고, Auto Scaling의 기능으로 새로운 정상적인 인스턴스가 1대 작성된다. 항상 최소, 최대 수를 유지하기 때문에, 모르는 사이에 정상적인 인스턴스가 없어져 장애가 발생하는 위험을 미연에 방지할 수 있다.

문제가 발생했을떼 새롭게 인스턴스가 추가된다.

스케일링 폴리시

Auto Scaling의 스케일링 방법은 크게 3가지로 분류 가능하다.

• 동적 스케일링
• 예측 스케일링
• 스케줄 스케일링

빈번히 이용되는 동적인 스케일링에는 또다시 3가지 스케일링 폴리시가 존재한다.

• 간이 스케일링
• 스탭 스케일링
• 타깃 추적 스케일링

간이 스케일링

CPU의 사용률이 70%를 넘길 때와 같은 하나의 메트릭스에 대하여 하나의 수치를 설정한다. 초창기부터 존재했던 스케일링 방법으로 지금은 추천하지 않는다. 간이 스케일링은 다음 소개할 스텝 스케일링으로 대응되기 때문에 그것을 이용하도록 하자.

스텝 스케일링

하나의 메트릭스에 대하여 복수의 조건을 설정한다. 예를 들어 CPU 사용률이 50% 이상일 경우, 60% 이상일 경우처럼 계단처럼 설정할 수 있다. 이렇듯 복수의 수치를 설정할 순 있지만, 하나의 수치만 설정하는 것 또한 가능하다. 즉 간이 스케일링의 상위 호환이라 할 수 있다. 그 때문에 AWS로서는 간이 스케일링 보단 스텝 스케일링을 추천한다.

타깃 추적 스케일링

하나의 매트릭스에 대하여 목표치를 설정한다. 예를 들어 CPU의 이용률이 50%와 같은 목표치를 설정하면 Autu Scaling 그룹 전체에 CPU 이용률이  50%를 유지할 수 있도록 자동적으로 조정한다. 스텝 스케일링과 같이 상세하게 설정할 순 없지만, AWS 측이 컨트롤해주고 있다. 향후에는 이 방법이 주류가 될 것으로 보인다. 

스케일링의 설정을 할 때에는 기동 설정이나. 기동 템플릿을 설정할 필요가 있다.

스케일 아웃의 유예기간, 웜업, 쿨 다운

시스템의 퍼포먼스나 신뢰성을 높이기 위해선 Auto Scaling을 사용하여 수요에 응하여 인스턴스 수를 증감시킬 필요가 있다. 이럴 때 인스턴스의 기동 중에 새로운 인스턴스가 기동 되는 등과 같은 것을 방지할 필요가 있다. 그렇지 않으면 예상 이상의 인스턴스 수가 기동 될 가능성이 있다.  AWS에는 이를 대비한 회피책으로 몇 가지를 제공하고 있다.

유예기간

헬스 체크(Health Check)는 Auto Scaling의 관리 대상 하에 있는 인스턴스의 동작을 체크하여 문제가 발견되었을 때 새로운 인스턴스로 교체한다.

인스턴스의 기동 시간이나 인스턴스 내의 프로세스를 기동 시킬 시간이 있기 때문에 즉각적으로 해당 인스턴스가 이용 가능한 상태가 될 순 없다. 이때 헬스 체크에서 에러가 계속 발생하는 현상이 일어나면 스케일링 동작이 제대로 기능하지 않기 때문에, 일정 기간 헬스 체크를 하지 않는 유예 기간이 있다. 화면 콘솔로부터 만든 경우, 유예 기간은 기본 300초 (5분)이다. 하지만 CLI나 SDK로부터 작성할 경우 기본 0초이기 때문에 주의할 필요가 있다.

웜 업, 쿨 다운

유예기간 이외에도 웜업과 쿨 다운이라는 파라미터가 있다. 쿨다운의 정식 명칭은 스케일링 쿨다운이라고 한다. 이것은 Auto Scaling이 발동한 직후에, 추가적인 인스턴스의 증감이 발생하는 것을 막아주는 설정이다. 유예 기간과 혼동하기 쉽겠지만, 유예기간은 헬스 체크에 유예를 두는 것이라면, 쿨 다운은 인스턴스의 증감 액션의 기능에 대한 파라미터라고 할 수 있다.

또한 현재는 쿨다운은 주로 간인 스케일링을 위하여 설정되고 있으며, 이외의 스케일링 폴리시의 경우에는 기본적으로 설정을 손보지 않아도 되도록 세팅되어 있다. 예를 들어 스텝 스케일링의 경우 메트릭스에 대하여 복수의 수치가 설정되어 있다. 그렇기 때문에 스케일링 동작중에 다음 수치에 도달해 버릴 경우에는 쿨다운과는 관계없이 반응하도록 하기 위함이다.

 

웜업은 앞서 말한 대로 대체로 스텝업 스케일링에 대하여 차이가 나는 인스턴스를 추가하기 위해 추가된 기능이다.

예를 들어 CPU 사용률이 50% 이상일 경우 1대 추가, 70% 이상일 경우 2대 추가 조건이 걸려있다 할 시에, 50% -> 70%로 증가할 경우 50%의 조건에 만족하는 1대를 추가한 뒤 70%에 만족하는 2대를 바로 추가하는 것이 아닌 50%에서 이미 1대를 추가했기 때문에 비교하여 차이가 나는 1대를 추가하는 것이다.

웜업 동작의 포인트는 2가지이다. 첫 번째 포인트는 웜업 기간 중에는 해당 알람의 인스턴스 추가는 이뤄지지 않는다는 점이다. 두번째 웜업 기간중에는 다음 알람(70%)이 발동된 경우 차이가 나는 만큼 대수를 추가하는 점이다. 웜업은 스텝 스케일링과 타깃 추적 스케일링 폴리시에 대응한다.

웜업과 쿨다운

기타 Auto Scaling 옵션

라이프 사이클 훅

Auto Scaling 그룹에 의한 인스턴스의 기동시나, 삭제 시에 인스턴스를 일시 정지하여 커스텀 액션을 실행하는 기능이다. 예를 들어 기동시에 데이터를 취득해 두거나, 삭제 시에는 로그나 데이터의 삭제처리가 이뤄지기 전에 어딘가에 백업해두는 등과 같은 목적으로 이용되고 있다. 대기 시간은 기본적으로 1시간 최대 48시간까지 설정 가능하다.

종료 폴리시

부하에 대하여 인스턴스를 늘리는 것을 스케일 아웃이라고 한다. 이것에 대비하여 부하가 줄어들었을 때 인스턴스를 줄이는 경우를 스케일 인이라고 한다. Auto Scaling에서 스케일 인의 경우 어떤 인스턴스를 삭제하는 가 등을 정하는 행위를 종료 폴리시라고 한다. 기본적으로 종료 폴리시에는 인스턴스가 가용 영역에 평등하게 배분되도록 삭제한다. 두 개의 가용 영역에서 2대 3대의 인스턴스가 있을 경우 3대가 있는 가용 영역의 인스턴스를 하나 삭제하여 가용 영역 간의 인스턴스 수를 평등하게 유지하는 동작이 된다.

스케일인 폴리시나, 스케일 아웃의 유예기간, 웜업, 쿨다운, 종료 폴리시는 ELB의 기능이 아닌  Auto Scaling의 기능이다.  ELB와 Auto Scaling의 기능은 혼동하는 케이스가 종종 있는데, 각각의 기능을 확실히 알아 둘 필요가 있다.

종료 폴리시	동작
OldestInstance	가장 오래된 인스턴스를 삭제
NewestInstance	가장 새로운 인스턴스를 삭제
OldestLaunchConfiguration	가장 오래된 기동 설정의 인스턴스를 삭제
ClosestToNextInstanceHour	다음 과금시에 가장 가까운 인스턴스를 삭제
Default	AZ 간의 대수의 평등을 가지도록 인스턴스를 삭제
OldestLaunchTemplate	가장 오래된 기동 템플릿을 사용하는 인스턴스를 삭제
AllocationStrategy	스팟 또는 온디맨드 등의 인스턴스 타입의 배분전력에 따라 삭제

ELB와 Auto Scaling을 이용할 시의 설계 포인트

마지막으로 ELB와 Auto Scaling을 도입할 때에 중요시 여길 포인트 2가지를 안내할까 한다. 이것들의 생각 방법에도 중요하기 때문에 확실히 이해해둘 필요가 있다.

서버를 스테이트레스로 즉 상태를 보유하지 않도록 설계하는 것이다.

예를 들어 파일을 업로드하는 기능을 가지고 있는 경우, 업로드된 파일을 인스턴스 상에 보관한다고 할 경우, 다음 리퀘스트가 다른 인스턴스에 분산되어 버릴 경우, 업로드되었을 파일을 참조할 수 없게 된다. 또한  Auto Scaling을 유효화 했을 경우 스케일링의 타이밍에 해당 인스턴스가 삭제되는 상황도 발생할 수 있다. 데이터는 데이터베이스에 저장하고, 파일의 경우 S3에 보관하도록 설계를 변경하여 이러한 상황이 벌어지지 않도록 주의할 필요가 있다. 스테이트레스 하게 설계하기 위해서는 인프라 설계뿐만 아니라 애플리케이션 설계에도 신경을 써야 한다. 프로젝트 전체적으로 팀원들이 모두 스테이트레스에 대한 인식을 가질 수 있도록 하는 것 또한 아키텍트의 역할 중 하나이다.

 

또 하나는 AZ를 나누어 인스턴스를 배치하는 설계를 할 필요가 있다는 것이다. AWS에는 정말 가끔 AZ전체에 대하여 장애가 발생할 수 있는 경우가 있다. 이런 경우에는 인스턴스가 하나의 AZ에 배치되어 있을 경우 모든 인스턴스를 이용할 수 없게 되며, 결과적으로 서비스 전체가 정지되는 것과 같다. 혹시 4대의 웹 서버를 준비한다고 한다면 예를 들어 2대는 ap-northeast-1a의 AZ에 다른 2대는 ap-northeast-1c에 위치시키는 것이다. 이렇게 비치 해 둠으로써 AZ 장애가 발생할 경우에도 견딜 수 있는 설계가 된다.

 

이렇듯 AWS에는 어떻게 단일 장애점을 없애는가, 부분 장애를 이겨낼 수 있는 가를 전제로 설계하는가를 매우 중요시 여긴다. 장애에 대한 내구성에 대한 문제가 나올 경우 이러한 시점에서 접근하는 것이 해답에 가까워지는 방법이라고 생각하기 때문에, EC2 이외의 설계에도 웅분히 인식하는 것이 중요하다.

ECS

Amazon Elastic Container Service는 Docker 컨테이너 환경을 제공하는 서비스이다.  ECS가 등장하기 전에는 AWS 상에 Docker르 ㄹ도입하기 위해선 EC2위에 소프트웨어를 인스톨하여 접근할 필요가 있었다. 이러한 도입 작업이나 계속된 메인테넌스 작업은 사람을 번거롭게 하고 있었으며, 특히 많은 컨테이너를 운영하고 있는 경우에는 엄청난 코스트가 들어가는 작업이었다.  ECS는 Docker 환경에 필요한 설정을 포함하고 있는 EC2 인스턴스를 기동시 켜 해당 관리를 서포트하고 있다. 많은 코스트가 필요했던 작업을 AWS 측에 맡겨 버리고, 개발자는 애플리케이션의 개발에 집중할 수 있게 되었다.

ECS의 특징

ECS에 등장하는 개념에 대해서 설명하겠다. 간단히 그림을 확인해보자..

ECS의 요소

우선 EC2 인스턴스 상에서 실행되는 컨테이너를 Task라고 부르며, EC2 인스턴스에 해당하는 것을 cluster라고 부른다. 하나의 Cluster 상에는 복수의 task를 실행하는 것이 가능하다.

Cluster 상에서 동작하는 task를 정의하는 것을 task-definition에서 행하고 있다. Task의 역할에 따라 Task-Definition을 준비하여 그것들을 Cluster 상에서 기동 시킨다.

{
	"ContainerDefinitions" : [
    	{
        	"name": "wordpress",
            "links": [
            	"mysql"
            ],
            "images": "wordpress",
            "essential": true,
            "portMappings": [
            	{
                	"containerPort": 80,
                    "hostPort": 80
                }
            ],
            "memory": 50o,
            "cpu": 10
        },
        {
        	"enviroment: [
            	{
                	"name": "MYSQL_ROOT_PASSWORD",
                    "value": "password",
                }
            ],
            "name": "mysql",
            "image": "mysql",
            "cpu" : 10,
            "memory" : 500,
            "essential": true
        }
	],
    "family": "hello_word"
}

 

같은 Task를 복수 준비하고 싶을 경우도 있다. 예를 들어 웹 서버 task를 복수 준비하여 ELB에 연결하는 것과 같은 이런 경우 이용할 수 있는 것이 Service이다. Service에선 웹 서버용 task-definition에서 task를 4개 기동 하라 등과 같은 지정이 가능하다. 물론 Auto Scaling을 이용하여 동적인 스케일링을 설정하는 것도 가능하다. 또한 Service를 이용하는 것으로 Task의 갱신을 블루 그린 데프로이먼트로 실행하는 것도 가능하다.

세큐리티면의 특징으로는 task 별로 IAM (Identity and Access Management) 역할을 할당하는 것을 들 수 있다. EC2의 경우에는 IAM 역할을 인스턴스 단위로 밖에 할당할 수 없었으나, ECS에서는 같은 클러스터 상에서 기동하고 있는 Task라고 할 지라도 별도의 IAM을 설정할 수 있다. 그렇기 때문에 다음과 같은 권한 관리도 가능하게 된 것이다.

• 웹 서버용 Task에는 SQS ( Simple Queue Service )로의 Send Message 권한만 부여
• 같은 Cluster 상에 동작하는 배치용 Task에는 SQS에로부터 Receive Message 권한과 S3로부터의 Get Object 권한만 부여

AWS 상의 또 다른 컨테이너 서비스

ECS 외에도 AWS에는 다음과 같은 컨테이너 관련 서비스들이 있다.

• AWS Fargate
• Amazon Elastic Container Service for Kubenetes (EKS)
• Amazon Elastic Container Registry (ECR)

ECS에는 Cluster용의 EC2 인스턴스가 필요하다. 그렇기 때문에 해당 EC2 인스턴스의 관리, 예를 들어 Auto Scaling의 설정 등은 사용자 측에서 인식하고 있어야 한다. AWS  Fargate는 EC2를 사용하지 않고, 컨테이너를 움직일 수 있는 서비스이다. 현재 ECS의 Task 정의를 작성할 때에 기동 타입으로서 EC2 (본래의 ECS)와 Fargate를 선택할 수 있다. Fargate를 선택하면 Cluster의 관리가 필요 없기 때문에  ECS보다 더 애플리케이션 개발에 집중할 수 있다. Fargate는 각 클러스터에 분배되어 있는 CPU와 메모리에 관하여 이용료가 부과되는 특징이 있다.

 

Kubenetes는 컨테이너 관리의 자동화를 위한 오픈소스 플랫폼이다. 본래 Kubenetes를 이용하기 위해서는 마스터용 EC2 인스턴스를 여려대 준비하여 관리할 필요가 있었다. Amazon Elastic Container Service for Kubenetes(EKS)는 해당 마스터를 서비스로서 제공하는 서비스이다. 마스터 용의 EC2 인스턴스를 관리할 필요가 없게 되어, 차별화를 두는 기능의 개발에 보다 집중할 수 있게 되었다.

 

Docker를 이용할 경우 해당 컨테이너 이미지를 레지스트리 ( 스토레지와 컨테이너 배송 서비스 )로 관리할 필요가 있다. 스스로 운용할 경우 레지스트리 자체의 가용성을 높이기 위한 설계가 필요하게 된다. 이런 레지스트리를 서비스로 제공하고 있는 것이 Amazon Elastic Container Registry (ECR)이다. 레지스트리의 관리를 ECR에 맡길 수 있으며, 레지스트리의 push/pull 권한을 IAM에서 관리하는 것도 가능하다.

Lambda

서버를  프로비저닝 하지 않아도 프로그램을 실행시킬 수 있는 컴퓨팅 서비스이다. 흔히 말하는 서버리스 아키텍처의 중축을 담당하고 있는 존재이다. EC2를 온프레미스 환경과 비교할 때에, 리드 타임이 짧아지는 것을 메리트중 하나로 언급했을 것이다. 그렇다곤 해도 EC2 상에서 소스 코드를 움직이게 하기 위해선 인스턴스를 작성하고, 각종 미들웨어를 인스톨 하는 등과 같은 순서가 필요하다. 또한 ELB나 Auto Scaling의 기능을 사용하여 리퀘스트의 부하 분산을 설정하거나, 운용 페이즈에 EC2에 배치를 할당하는 등의 작업은 이용자 측에서 해야만 하는 설정이기도 하다

 

Lambda를 이용한다면 소스코드의 실행 환경 자체를 제공하고 있기 때문에, 이용하는 소스 코드만 준비하면 곧바로 프로그램일 실행 시킬 수 있다. 또한 라퀘스트의 수에 응하여 자동적으로 스케일링하기 때문에, 처리에 필요한 서버의 대수를 고려할 필요도 없다. ( 동시 실행 수에 제한은 있지만, 필요에 따라 신청을 통해 제한을 해제할 수 있다 ) 따로 서버를 두고 있는 것이 아니기 때문에 소프트웨어를 업데이트하는 등 보수 작업을 행할 필요가 없으며, 이용자는 인프라 관리의 대부분을 클라우드 측에 맡기는 것이 가능하다. 

 

결과론 적으론 비즈니스적인 가치가 있는 기능을 실행하는 데에 있어, 개발 리소스를 가져다 쓰는 것도 가능하다. 이렇듯 서버를 가지지 않는 구성을 가져가는 것으로 다양한 메리트를 얻을 수 있다.

Lmabda가 서포트하고 있는 이벤트와 자주 사용되는 아키텍처 패턴

Lambda는 소스코드를 제 프로가 하는 것만으로 프로그램일 실행할 수 있는 환경을 제공하는 서비스이다. Lambda를 이용하기 위해서는 Lambda 함수라고 하는 단위로 실행할 프로그램을 해당 실행 트리거가 되는 이벤트를 전제하여 정의한다. 그리고 해당 이벤트가 발생한 타이밍에 프로그램이 실행되도록 한다. 지정 가능한 이벤트의 예시로는 아래와 같은 것들이 있다.

• S3 버킷에 오브젝트가 추가된 경우, S3 버킷으로부터 오브젝트가 삭제되는 경우,
• DynamoDB 테이블이 갱신되는 경우
• SNS 통지가 발행되었을 경우
• SES가 메일을 수신했을 경우
• API Gateway로의 HTTPS 리퀘스트가 발생한 경우
• Cloudwatch Events에 의하여 정의된 스케줄링이 시작되었을 경우

이러한 것들과 연계할 수 있는데 여기 작성한 것들은 극히 일부분이다. 공식 도큐먼트를 읽어 보면 더 많은 것들을 확인할 수 있을 것이다.

개중 자주 이용되는 패턴을 소개해 볼까 한다,

우선 S3 트리거를 이용하는 예이다.

S3에 이미지가 업로드 되면 람타가 섬네일을 작성한다.

1. S3에 이미지가 업로드되고, 그것을 트리거로 Lambda함수가 기동 한다.
2. Lambda함수는 대상이 되는 이미지를 추출하여, 섬네일용 이미지를 작성한 뒤 다른 S3 버킷에 업로드한다.

원래라면 배치 서버를 이용하여 해야 할 적업을 Lambda를 이용하여 손쉽게 이용할 수 있는 아주 좋은 예 중 하나이다.

API의 제공을 Lambda를 이용하는 패던도 있다.

API Gateway와의 조합하여 API의 로직을 람다가 실행

1. API Gateway는 리퀘스트가 있는 URI와 HTTP 메서드를 조합하여 호출시킬 Lambda함수를 지정할 수 있다.
2. 불려진 Lambda 함수는 비즈니스 로직을 실행하여 필요한 DynamoDB와 데이터를 주고받은 뒤에 API Gateway를 경유하여 결괏값을 반환한다.
3. API 리퀘스트의 피크시에는 자동적으로 스케일링을 구성하는 것도 가능하다

마지막으로 정기적으로 실행하는 패턴이다. CloudWatch Evnet와 조합하는 것으로 시간마다, 매주 화요일 18시와 같은 형식으로 Lambda의 실행 타이밍을 지정할 수 있다. 예를 들어 1시간에 1번 외부 API로부터 정보를 취득하는 크롤러로 이용하거나 정기적으로 slack에 무언가 정보를 보낼 때에 이용할 수 있다.

 CloudWatch Events에서 Lambda를 정기 실행하여 외부 API를 호출, 정보를 취득한다.

Lambda가 지원하는 프로그래밍 언어

지금까지 소개했듯, 다양한 아키텍처의 중심으로 Lambda를 이용할 수 있다. 이어 Lambda 함수의 실행 예를 살펴보자. 아래의 예는 AWS가 사전에 준비해둔 블루 프린트를 호출하는 실행 중 일부분이다. boto3이라고 하는 python용 AWS SDK를 이용하여 s3로부터 오브젝트 정보를 취득하고 있다. 이러한 소스 코드를 준비하여 압축하는 메모리나, 타임아웃 값 만 설정하는 것으로 lambda 상에서 프로그램을 움직일 수 있다.

Lambda에는 2020년 12월 기준 아래의 언어를 지원하고 있다.

• Node.js
• Ruby
• PowerShell
• Python
• C#
• Java
• Go

명확히 어느 언어가 좋다. 어느 언어가 구리다 등과 같은 것은 없지만 Pyhton에는 초회 Lambda의 기동이 빠르다는 장점이 있으며, 반대로 Java는 초회 기동에 시간이 걸린다는 단점이 있다. 때문에 기능 요건이 아닌 비 기능 요건, 개발 멤버의 언어에 대한 이용 경험에 따라 다양한 언어를 선택할 수 있다.

Lambda에는 이용하는 언어 이외에 아래의 항목을 설정할 필요가 있다.

• 설정된 메모리 값
• 타임 아웃 시간
• Lambda에 설정할 IAM 롤
• VPC내에서 실행할 것인가, VPC 밖에서 실행할 것인가.

또한 Lambda의 CPU 파워는 설정된 메모리량에 따라 결정된다.

Lambda의 과금 체계

또 하나 Lambda의 커다란 특징이라면 과금 체계라 할 수 있다.

2020년 12월 현재 Lambda의 이용금은 아래와 같다.

• Lambda 함수의 실행수 : 100만 건 의 리퀘스트 당 0.20 USD
• Lmabda 함수의 실행 시간 : Lambda함수 별 설정된 메모리 량에 따라 과금 금액 정해짐

이렇듯 Lambda의 과금 체계는 리퀘스트의 수와 처리 시간에 따라 결정되는 리퀘스트 과금 모들을 적용하고 있다. 그렇기 때문에 1시간에 몇 번씩 기동 할 필요가 있는 배치나 어느 정도 리퀘스트가 도달할지 에상할 수 없는 API를 구축하는 등 코스트에 최적화된 구성을 만들어 낼 수 있다.