모놀리식 애플리케이션 및 마이크로서비스
모놀리식 애플리케이션
애플리케이션은 여러 구성 요소로 구성됩니다. 구성 요소는 서로 통신하여 데이터를 전송하고, 요청을 이행하고, 애플리케이션을 계속 실행합니다.
구성 요소가 밀결합된 애플리케이션이 있다고 가정해 보겠습니다. 이러한 구성 요소에는 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등이 포함될 수 있습니다.
이러한 유형의 아키텍처를 모놀리식 애플리케이션으로 볼 수 있습니다.
이 애플리케이션 아키텍처 접근 방식에서는 한 구성 요소에서 장애가 발생하면 다른 구성 요소에도 장애가 발생하고, 심지어 전체 애플리케이션에서 장애가 발생할 수도 있습니다.
단일 구성 요소에 장애가 발생했을 때 애플리케이션 가용성을 유지할 수 있도록 마이크로서비스 접근 방식을 통해 애플리케이션을 설계할 수 있습니다.
마이크로 서비스
마이크로서비스 접근 방식에서는 애플리케이션 구성 요소가 소결합됩니다. 이 경우 단일 구성 요소에 장애가 발생해도 다른 구성 요소들은 서로 통신하기 때문에 계속 작동합니다. 소결합 때문에 전체 애플리케이션에서 장애가 발생하는 것이 방지됩니다.
AWS에서 애플리케이션을 설계할 때 다양한 기능을 수행하는 서비스 및 구성 요소를 사용하여 마이크로서비스 접근 방식을 취할 수 있습니다. 애플리케이션 통합을 촉진하는 두 가지 서비스로 Amazon Simple Notification Service(Amazon SNS)와 Amazon Simple Queue Service(Amazon SQS)가 있습니다.
Amazon Simple Notification Service(Amazon SNS)
Amazon Simple Notification Service(Amazon SNS)는 게시 및 구독 서비스입니다. 게시자는 Amazon SNS 주제를 사용하여 구독자에게 메시지를 게시합니다. 이는 커피숍에서 계산원이 음료를 만드는 바리스타에게 주문 사항을 전달하는 것과 비슷합니다.
Amazon SNS에서 구독자는 웹 서버, 이메일 주소, AWS Lambda 함수 또는 그 밖의 여러 옵션이 될 수 있습니다.
예시
단일 주제에서 업데이트 게시
커피숍에 모든 비즈니스 영역의 업데이트를 포함하는 단일 뉴스레터가 있다고 가정해 보겠습니다. 여기에는 쿠폰, 커피 상식, 신제품과 같은 주제가 포함됩니다. 단일 뉴스레터이기 때문에 모든 주제가 그룹화됩니다. 뉴스레터를 구독하는 모든 고객은 쿠폰, 커피 상식, 신제품에 대한 업데이트를 받습니다.
얼마 후 일부 고객이 관심 있는 특정 주제에 대해서만 별도의 뉴스레터를 받으면 좋겠다는 의견을 표명합니다. 커피숍 점주는 이 접근 방식을 시험해 보기로 결정합니다.
여러 주제에서 업데이트 게시
이제 커피숍은 모든 주제를 다루는 단일 뉴스레터 대신 이를 3개의 뉴스레터로 나눴습니다. 각 뉴스레터는 쿠폰, 커피 상식, 신제품과 같은 특정 주제만을 다룹니다.
이제 구독자는 구독한 특정 주제에 대해서만 즉시 업데이트를 받게 됩니다.
구독자는 주제를 하나 또는 여러 개 구독할 수 있습니다. 예를 들어 첫 번째 고객은 쿠폰 주제만 구독하고 두 번째 구독자는 커피 상식 주제만 구독합니다. 세 번째 고객은 커피 상식 주제와 신제품 주제를 구독합니다.
이 커피숍 예에는 사람인 구독자가 포함되지만 Amazon SNS에서는 구독자가 웹 서버, 이메일 주소, AWS Lambda 함수 또는 기타 여러 옵션이 될 수 있습니다.
Amazon Simple Queue Service(Amazon SQS)
Amazon Simple Queue Service(Amazon SQS)는 메시지 대기열 서비스입니다.
Amazon SQS를 사용하면 메시지 손실이나 다른 서비스 사용 없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있습니다. Amazon SQS에서는 애플리케이션이 메시지를 대기열로 전송합니다. 사용자 또는 서비스는 대기열에서 메시지를 검색하여 처리한 후 대기열에서 삭제합니다.
예 1: 주문 이행
계산원이 주문을 받고 바리스타가 주문 음료를 만드는 주문 프로세스가 커피숍에 있다고 가정해 보겠습니다. 계산원과 바리스타가 애플리케이션의 두 가지 개별 구성 요소라고 생각하십시오.
먼저 계산원이 주문을 받아 주문지에 적습니다. 그런 다음 계산원이 바리스타에게 주문지를 전달합니다. 마지막으로 바리스타가 음료를 만들어 고객에게 제공합니다.
다음 주문을 받으면 프로세스가 반복됩니다. 이 프로세스는 계산원과 바리스타가 함께 조율되는 한 원활하게 진행됩니다.
만약 계산원이 주문을 받아 바리스타에게 전달하려는데 바리스타가 쉬는 시간이거나 다른 주문으로 바쁘다면 어떻게 될까요? 계산원은 바리스타가 주문을 받을 준비가 될 때까지 기다려야 합니다. 그러면 주문 프로세스가 지연되고 고객은 주문한 음료를 받을 때까지 더 오래 기다려야 합니다.
커피숍의 인기가 많아지고 주문하려는 고객의 줄이 줄어드는 속도가 더 느려지면 점주는 현재 주문 프로세스가 시간이 많이 걸리고 비효율적이라는 것을 알게 됩니다. 점주는 대기열을 사용하는 다른 접근 방식을 시도하기로 결정합니다.
예 2: 대기열에 있는 주문
계산원과 바리스타가 애플리케이션의 2가지 개별 구성 요소라는 점을 떠올리십시오. Amazon SQS와 같은 메시지 대기열 서비스를 사용하면 분리된 애플리케이션 구성 요소 간에 메시지를 사용할 수 있습니다.
이 예에서 프로세스의 첫 번째 단계는 이전과 동일합니다. 즉, 고객이 계산원에게 주문합니다.
계산원이 주문을 대기열에 넣습니다. 이를 계산원과 바리스타 사이의 버퍼 역할을 하는 주문판이라고 생각할 수 있습니다. 바리스타가 쉬는 시간이거나 다른 주문으로 바쁘더라도 계산원은 계속해서 새 주문을 대기열에 넣을 수 있습니다.
다음으로 바리스타가 대기열을 확인하고 주문을 검색합니다.
바리스타가 음료를 만들어 고객에게 제공합니다.
바리스타는 완료된 주문을 대기열에서 제거합니다.
바리스타가 음료를 만드는 동안 계산원은 계속 새로운 주문을 받아 대기열에 추가할 수 있습니다.
요약
분리된 애플리케이션과 마이크로서비스의 경우, Amazon SQS를 사용하면 구성 요소 간에 메시지를 전송, 저장, 검색할 수 있습니다.
개별 구성 요소는 이러한 분리된 접근 방식을 통해 보다 효율적이고 독립적으로 작동할 수 있습니다.
[출처]
AWS Cloud Practitioner Essentials