Ⅰ. 메시지 대기열
1. 모놀리딕 애플리케이션과 마이크로 서비스
아키텍처를 구성하는 방식에는 밀결합과 소결합이 있다. 밀결합된 아키텍처는 애플리케이션 A가 애플리케이션 B에 메시지를 직접 보내는 시스템이다. 따라서 구성 요소 하나가 고장이 나거나 변경이 되면 다른 구성요소 또는 시스템 전체에 문제가 발생할 수 있다.
따라서 소결합된 아키텍처가 더 안정적이라 할 수 있다. 소결합된 아키텍처는 특정 구성 요소에 장애가 발생하더라도 장애가 구성 요소 안에 격리되기 때문에 전체 시스템 장애로 확장되지 않는다. 즉, 애플리케이션 B에 장애가 발생하더라도 애플리케이션 A에는 중단이 발생하지 않는다. A는 B의 상태에 상관 없이 메시지를 대기열로 전송하며, 메시지는 B에서 처리될 때까지 안전하게 대기열에 보관된다.
애플리케이션은 여러 구성 요소로 구성된다. 구성 요소는 서로 통신하여 데이터를 전송하고, 요청을 이행하고, 애플리케이션을 실행한다. 구성요소에는 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등이 포함될 수 있다. 만약 구성 요소가 밀겹합된 애플리케이션이 있다면, 이것을 모놀리딕 애플리케이션이라 부른다. 위에서 설명한 바 있듯, 단일 구성요소에 대한 장애가 다른 구성요소의 장애를 유발할 수 있기 때문에 가용성이 매우 낮은 설계 방식이다.
단일 구성 요소에 장애가 발생하더라도 애플리케이션이 가용성을 유지할 수 있도록 마이크로서비스 접근 방식을 통해 애플리케이션을 설계해야 한다.
마이크로서비스 접근 방식에서는 애플리케이션 구성 요소가 소결합된다. 이 경우 단일 구성 요소에 장애가 발생해도 다른 구성 요소들은 서로 통신하기 때문에 계속 작동할 수 있다. 이러한 소결합 덕분에 전체 애플리케이션에서 장애가 발생하는 것을 방지할 수 있다.
AWS에서 애플리케이션을 설계할 때 다양한 기능을 수행하는 서비스 및 구성 요소를 사용하여 마이크로서비스 접근 방식으로 만들 수 있다. Amazon Simple Notification Service(Amazon SNS) 및 Amazon Simple Queue Service(Amazon SQS)는 애플리케이션을 통합해주는 서비스이다.
2. Amazon Simple Notification Service(Amazon SNS)
Amazon Simple Notification Service(Amazon SNS)는 게시/구독 서비스이다. 게시자는 Amazon SNS 주제를 사용하여 구독자에게 메시지를 게시한다. 여기서 말하는 구독자는 웹 서버, 이메일 주소, AWS Lambda 함수 또는 그 밖의 여러 옵션이 될 수 있다.
1) 단일 주제에서 업데이트 게시
커피숍에 모든 비즈니스 영역의 업데이트를 포함하는 단일 뉴스레터가 있다고 가정해보자. 여기에는 쿠폰, 커피 상식, 신제품과 같은 주제가 포함된다. 단일 뉴스레터이기 때문에 모든 주제가 그룹화된다. 뉴스레터를 구독하는 모든 고객은 쿠폰, 커피 상식, 신제품에 대한 업데이트를 받게 된다.
2) 여러 주제에서 업데이트 게시
이제 커피숍은 모든 주제를 다루는 단일 뉴스레터 대신 이를 3개의 뉴스레터로 나눴다. 각 뉴스레터는 쿠폰, 커피 상식, 신제품과 같은 특정 주제만을 다룬다. 이제 구독자는 구독한 특정 주제에 대해서만 즉시 업데이트를 받게 된다.
구독자는 주제를 하나 또는 여러 개 구독할 수 있다. 예를 들어 첫 번째 고객은 쿠폰 주제만 구독하고 두 번째 구독자는 커피 상식 주제만 구독한다. 세 번째 고객은 커피 상식 주제와 신제품 주제를 구독한다.
3. Amazon Simple Queue Service(Amazon SQS)
Amazon Simple Queue Service(Amazon SQS)는 메시지 대기열 서비스이다. Amazon SQS를 사용하면 메시지 손실이나 다른 서비스 사용 없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있다. Amazon SQS에서는 애플리케이션이 메시지를 대기열로 전송한다. 사용자 또는 서비스는 대기열에서 메시지를 검색하여 처리한 후 대기열에서 삭제한다.
1) 대기열이 없는 상태
계산원이 주문을 받고 바리스타가 음료를 만드는 주문 프로세스가 커피숍에 있다고 가정해 보자. (계산원과 바리스타가 애플리케이션의 두 가지 개별 구성 요소이다.)
먼저 계산원이 주문을 받아 주문지에 적는다. 그런 다음 계산원이 바리스타에게 주문지를 전달하면 마지막으로 바리스타가 음료를 만들어 고객에게 제공한다. 다음 주문을 받으면 프로세스가 반복된다. 이 프로세스는 계산원과 바리스타가 함께 조율되는 한 원활하게 진행된다.
만약 계산원이 주문을 받아 바리스타에게 전달하려는데 바리스타가 쉬는 시간이거나 다른 주문으로 바쁘다면 어떻게 될까? 계산원은 바리스타가 주문을 받을 준비가 될 때까지 기다려야 한다. 그러면 주문 프로세스가 지연되고 고객은 주문한 음료를 받을 때까지 더 오래 기다려야 한다.
커피숍의 인기가 많아지고 주문하려는 고객의 줄이 줄어드는 속도가 더 느려지면 점주는 현재 주문 프로세스가 시간이 많이 걸리고 비효율적이라는 것을 알게 된다. 점주는 대기열을 사용하는 다른 접근 방식을 시도하기로 결정한다.
2) 대기열 사용
고객이 계산원에게 주문을 요청하면 계산원이 주문을 대기열에 넣는다. 이를 계산원과 바리스타 사이의 버퍼 역할을 하는 주문판이라고 생각할 수 있다. 바리스타가 쉬는 시간이거나 다른 주문으로 바쁘더라도 계산원은 계속해서 새 주문을 대기열에 넣으면 된다.
바리스타는 대기열을 통해 주문을 확인한다. 주문에 맞게 음료를 고객에게 제공한 후 바리스타는 완료된 주문을 대기열에서 제거한다. 바리스타가 음료를 만드는 동안 계산원은 계속 새로운 주문을 받아 대기열에 추가할 수 있다.
Amazon SQS와 같은 메시지 대기열 서비스를 사용하면 분리된 애플리케이션 구성 요소 간에 메시지를 사용할 수 있게 된다.
Ⅱ. 추가 컴퓨팅 서비스
1. 서버리스 컴퓨팅
Amazon EC2에서 실행하려는 애플리케이션이 있는 경우 인스턴스(가상 서버)를 프로비저닝해야 하고, 사용자 코드를 업로드해야 하며, 애플리케이션이 실행되는 동안 계속해서 인스턴스를 관리해야 한다.
‘서버리스’라는 용어는 코드가 서버에서 실행되지만 이러한 서버를 프로비저닝하거나 관리할 필요가 없다는 뜻이다. 서버리스 컴퓨팅을 사용하면 서버를 유지 관리하는 대신 새로운 제품과 기능을 개발하는 데에 온전히 집중할 수 있다.
서버리스 컴퓨팅의 또 다른 이점은 서버리스 애플리케이션을 자동으로 확장할 수 있는 유연성이다. 서버리스 컴퓨팅은 처리량 및 메모리와 같은 소비 단위를 수정하여 애플리케이션의 용량을 조정할 수 있다. 서버리스 컴퓨팅용 서비스로 AWS에서는 Lambda를 지원하고 있다.
2. AWS Lambda
AWS Lambda는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서비스이다. AWS Lambda를 사용하는 경우 사용한 컴퓨팅 시간에 대해서만 비용을 지불하고 코드를 실행하는 동안에만 요금이 부과된다. 사실상 모든 유형의 애플리케이션 또는 백엔드 서비스 코드를 실행할 수 있으며 이를 관리할 필요가 전혀 없다.
예를 들어 간단한 Lambda 함수로 업로드되는 이미지의 크기를 AWS 클라우드에 맞춰 자동으로 조정하는 함수가 있을 수 있다. 이 경우 새 이미지를 업로드할 때 함수가 트리거된다.
※ 트리거
특정한 조건이나 이벤트가 발생하여 함수가 실행되는 것을 의미한다. 이벤트가 발생하면, 해당 이벤트에 연결된 함수가 자동으로 호출되어 작업을 수행한다.
3. 컨테이너식 애플리케이션 서비스
1) 컨테이너
컨테이너는 애플리케이션의 코드와 종속성을 하나의 객체로 패키징하는 표준 방식을 제공힌다. 보안성, 안정성, 확장성 요구 사항이 매우 중요한 프로세스 및 워크플로(여러 작업이 연결되어 있는 것으로 특정 목표를 달성하기 위해 정의한 일련의 단계)에도 컨테이너를 사용한다. 컨테이너에는 애플리케이션 실행에 필요한 바이너리가 적재된다.
컨테이너는 애플리케이션의 독립된 실행환경을 제공함으로써, 다양한 환경에서도 일관되게 실행되게 만들어준다(이식성을 향상시킨다). 근데 만약 수백 개의 컨테이너가 있는 수십개의 호스트를 관리해야한다면 어떨까? 메모리 사용량, 보안, 로깅 등을 모니터링하는 데에 많은 시간이 소요될 것이다.
AWS에서 제공하는 컨테이너 오케스트레이션 서비스를 사용하면, 컨테이너식 애플리케이션을 배포, 관리, 확장하는데 도움을 받을 수 있다.
2) Amazon Elastic Container Service(Amazon ECS)
Amazon Elastic Container Service(ECS)는 AWS에서 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 확장성이 뛰어난 고성능 컨테이너 관리 시스템이다.
Amazon ECS는 Docker 컨테이너를 지원한다. Docker는 애플리케이션을 신속하게 구축, 테스트, 배포할 수 있는 소프트웨어 플랫폼이다. AWS는 오픈 소스 Docker Community Edition 및 구독 기반 Docker Enterprise Edition의 사용을 지원한다. Amazon ECS에서는 API 호출을 사용하여 Docker 지원 애플리케이션을 시작 및 중지할 수 있다.
3) Amazon Elastic Kubernetes Service(Amazon EKS)
Amazon Elastic Kubernetes Service(Amazon EKS)는 AWS에서 Kubernetes를 실행하는 데 사용할 수 있는 완전 관리형 서비스이다.
Kubernetes는 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어이다. 대규모 커뮤니티에서 Kubernetes를 유지 관리하며, AWS는 Kubernetes 커뮤니티와 적극적으로 협력한다. Kubernetes 애플리케이션의 새로운 기능이 릴리스되면 Amazon EKS로 관리되는 애플리케이션에 이러한 업데이트를 간편하게 적용할 수 있다.
4) AWS Fargate
AWS Fargate는 컨테이너용 서버리스 컴퓨팅 엔진으로, Amazon ECS와 Amazon EKS에서 작동한다.
AWS Fargate를 사용하는 경우 서버를 프로비저닝하거나 관리할 필요가 없다. AWS Fargate는 자동으로 서버 인프라를 관리한다. 애플리케이션 혁신과 개발에 더 집중할 수 있으며, 컨테이너를 실행하는 데 필요한 리소스에 대해서만 비용을 지불하면 된다.
서버리스 컴퓨팅이라는 점에서 Lambda와 유사하지만, Lambda는 애플리케이션 코드를 실행할 수 있는 환경을 제공하는 반면, Fargate는 컨테이너 오케스트레이션 서비스로, 사용자가 컨테이너화된 애플리케이션을 실행하고 관리할 수 있는 환경을 제공한다.
이 시리즈의 글들은 AWS Skill Builder의 교육 내용을 모방하고 있으며, 이미지는 AWS Skill Builder에서 가져온 것입니다. 넷제로 해커톤을 준비하는 과정에서 수료해야 하는 교육 내용이기에 블로그에 정리해 둔 것입니다. 문제 시 삭제하겠습니다.
>> AWS Skill Builder
