[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Implementing Microservices on AWS 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
개요
마이크로 서비스는 소프트웨어 개발에 대한 아키텍처 및 조직적 접근 방식으로, 배포 주기를 단축하고, 혁신 및 소유를 촉진하며, 소프트웨어 응용 프로그램의 유지 관리 및 확장 성을 향상 시키며, 팀이 서로 독립적으로 작업 할 수 있도록 하는 민첩한 접근 방식을 사용하여 소프트웨어 및 서비스를 제공하는 조직을 확장합니다. 소프트웨어는 마이크로 서비스 접근 방식을 사용하여 독립적으로 배포 할 수있는 잘 정의 된 API를 통해 통신하는 소규모 서비스로 구성됩니다. 이 서비스는 소규모 자율 팀이 소유합니다. 이 민첩한 접근 방식은 조직을 성공적으로 확장하는 데 중요합니다.
고객이 마이크로 서비스를 구축 할 때 관찰하는 일반적인 패턴은 API 기반, 이벤트 기반 및 데이터 스트리밍입니다. 이 백서에서는 세 가지 접근 방식을 모두 소개하고 마이크로 서비스의 공통 특성을 요약하고, 마이크로 서비스 구축의 주요 과제를 논의하며, 제품 팀이 Amazon Web Services (AWS)를 활용하여 이러한 과제를 극복 할 수 있는 방법을 설명합니다.
소개
마이크로 서비스 아키텍처는 소프트웨어 엔지니어링에 대한 완전히 새로운 접근 방식이 아니라 다음과 같은 성공적이고 입증 된 다양한 개념의 조합입니다.
- 민첩한 소프트웨어 개발
- 서비스 지향 아키텍처
- API 우선 설계
- 지속적인 통합 / 연속 전달 (CI / CD)
대부분의 경우 Twelve-Factor App의 디자인 패턴은 마이크로 서비스에 활용됩니다.
먼저 확장성이 뛰어난 내결함성 마이크로 서비스 아키텍처 (사용자 인터페이스, 마이크로 서비스 구현 및 데이터 저장소)의 다양한 측면과 컨테이너 기술을 활용하여 AWS에서이를 구축하는 방법에 대해 설명합니다. 그런 다음 운영 복잡성을 줄이기 위해 일반적인 서버리스 마이크로 서비스 아키텍처를 구현하기 위해 AWS 서비스를 권장합니다.
서버리스는 다음 원칙에 따라 운영 모델로 정의됩니다.
- 프로비저닝 또는 관리할 인프라가 없음
- 소비 단위별 자동 스케일링
- “가치 지불” 청구 모델
- 내장된 가용성 및 내결함성
마지막으로 전체 시스템을 살펴보고 분산 모니터링 및 감사, 데이터 일관성 및 비동기 통신과 같은 마이크로 서비스 아키텍처의 교차 서비스 측면에 대해 논의합니다.
AWS의 간단한 마이크로서비스 아키텍처
일반적인 단일 응용 프로그램은 UI (사용자 인터페이스) 계층, 비즈니스 계층 및 지속성 계층과 같은 다른 계층을 사용하여 구축됩니다. 마이크로 서비스 아키텍처의 핵심 아이디어는 기능을 기술적인 계층이 아니라 특정 영역을 구현하여 응집성 있는 “수직”으로 분할하는 것입니다. 그림 1은 AWS의 일반적인 마이크로 서비스 애플리케이션에 대한 참조 아키텍처를 보여줍니다.
사용자 인터페이스
최신 웹 애플리케이션은 종종 JavaScript 프레임 워크를 사용하여 REST (Representational State Transfer) 또는 RESTful API와 통신하는 단일 페이지 애플리케이션을 구현합니다. 정적 웹 콘텐츠는 Amazon Simple Storage Service (Amazon S3) 및 Amazon CloudFront를 사용하여 제공 할 수 있습니다.
마이크로 서비스의 클라이언트는 가장 가까운 엣지 로케이션에서 서비스를 제공하고 캐시와 프록시 서버에서 오리진에 최적화 된 연결을 통해 응답을 받기 때문에 지연 시간을 크게 줄일 수 있습니다. 그러나 서로 가까이에서 실행되는 마이크로 서비스는 CDN의 이점을 얻지 못합니다. 경우에 따라 이 방법은 실제로 추가 대기 시간을 추가 할 수 있습니다. 최선의 방법은 다른 캐싱 메커니즘을 구현하여 대화를 줄이고 대기 시간을 최소화하는 것입니다.
마이크로 서비스
우리는 종종 API가 마이크로 서비스의 정문이라고 말합니다. 즉, API는 일반적으로 RESTful 웹 서비스 API 인 일련의 프로그래밍 인터페이스 뒤에 있는 애플리케이션 로직의 진입점 역할을 합니다. 이 API는 클라이언트의 호출을 수락하고 처리하며 트래픽 관리, 요청 필터링, 라우팅, 캐싱, 인증 및 권한 부여와 같은 기능을 구현할 수 있습니다.
마이크로 서비스 구현
AWS는 마이크로 서비스 개발을 지원하는 통합 빌딩 블록을 보유하고 있습니다. 널리 사용되는 두 가지 접근 방식은 AWS Fargate와 함께 AWS Lambda 및 Docker 컨테이너를 사용하는 것입니다.
AWS Lambda를 사용하면 코드를 업로드하기 만하면 Lambda가 실행을 실행하고 확장하는데 필요한 모든 것을 처리하여 고가용성을 통해 실제 수요 곡선을 충족시킬 수 있습니다. 즉, 인프라 관리가 필요하지 않습니다. Lambda는 여러 프로그래밍 언어를 지원하며 다른 AWS 서비스에서 트리거하거나 모든 웹 또는 모바일 애플리케이션에서 직접 호출 할 수 있습니다. AWS Lambda의 가장 큰 장점 중 하나는 빠르게 이동할 수 있다는 것입니다. 보안 및 확장이 AWS에 의해 관리되므로 비즈니스 로직에 집중할 수 있습니다. Lambda의 의미 있는 접근 방식은 확장 가능한 플랫폼을 주도합니다.
배포를 위한 운영 노력을 줄이는 일반적인 방법은 컨테이너 기반 배포입니다. Docker와 같은 컨테이너 기술은 이식성, 생산성 및 효율성과 같은 이점으로 인해 지난 몇 년 동안 인기가 높아졌습니다. 컨테이너가 있는 학습 곡선은 가파르고 Docker 이미지 및 모니터링의 보안 수정에 대해 생각해야 합니다. Amazon ECS (Amazon Elastic Container Service) 및 Amazon EKS (Amazon Elastic Kubernetes Service)는 자체 클러스터 관리 인프라를 설치, 운영 및 확장 할 필요가 없습니다. 간단한 API 호출을 통해 Docker 지원 애플리케이션을 시작 및 중지하고 클러스터의 전체 상태를 쿼리하며 보안 그룹,로드 밸런싱, Amazon Elastic Block Store (Amazon EBS), AWS Identity and Access(IAM)와 같은 많은 친숙한 기능에 액세스 할 수 있습니다.
AWS Fargate는 서버리스 컨테이너를 실행할 수있는 컨테이너 관리 서비스이므로 컨테이너를 실행하기 위해 가상 머신의 클러스터를 프로비저닝, 구성 및 확장 할 필요가 없습니다. Fargate를 사용하면 더 이상 컨테이너 응용 프로그램에 충분한 컴퓨팅 리소스를 프로비저닝 할 필요가 없습니다. Fargate는 수만 개의 컨테이너를 출시하고 가장 중요한 응용 프로그램을 실행하도록 쉽게 확장 할 수 있습니다.
Amazon ECS는 컨테이너 배치 전략 및 제약 조건을 지원하여 Amazon ECS가 작업을 배치하고 종료하는 방법을 사용자 정의합니다. 작업 배치 제약 조건은 작업 배치 중에 고려되는 규칙입니다. 기본적으로 키-값 쌍인 속성을 컨테이너 인스턴스에 연결 한 다음 제약 조건을 사용하여 이러한 속성을 기반으로 작업을 배치 할 수 있습니다. 예를 들어, 제약 조건을 사용하여 GPU 기반 인스턴스와 같은 인스턴스 유형 또는 인스턴스 기능을 기반으로 특정 마이크로 서비스를 배치 할 수 있습니다.
Amazon EKS는 최신 버전의 오픈 소스 Kubernetes 소프트웨어를 실행하므로 Kubernetes 커뮤니티의 모든 기존 플러그인 및 툴링을 사용할 수 있습니다. Amazon EKS에서 실행되는 애플리케이션은 온 프레미스 데이터 센터 또는 퍼블릭 클라우드에서 실행중인 모든 표준 Kubernetes 환경에서 실행되는 애플리케이션과 완전히 호환됩니다. Amazon EKS는 IAM과 Kubernetes를 통합하여 Kubernetes의 기본 인증 시스템에 IAM 엔터티를 등록 할 수 있습니다. Kubernetes 마스터로 인증하기 위해 자격 증명을 수동으로 설정할 필요가 없습니다. IAM 통합을 통해 IAM을 사용하여 Kubernetes 마스터의 퍼블릭 엔드 포인트에 대한 세분화 된 액세스를 제공함으로써 마스터 자체를 직접 인증 할 수 있습니다.
Amazon ECS 및 Amazon EKS에 사용 된 Docker 이미지는 Amazon Elastic Container Registry (Amazon ECR)에 저장할 수 있습니다. Amazon ECR은 컨테이너 레지스트리에 필요한 인프라를 운영하고 확장 할 필요가 없습니다.
CI / CD (Continuous Integration and Continuous Delivery)는 시스템 안정성과 보안을 유지하면서 소프트웨어를 빠르게 변경할 수있는 DevOps 이니셔티브의 모범 사례이자 필수적인 부분입니다. 그러나이 백서의 범위를 벗어나는 자세한 내용은“AWS에서 지속적인 통합 및 지속적 전달 연습”백서에서 더 많은 정보를 찾을 수 있습니다.
Private Links
AWS PrivateLink는 지원되는 AWS 서비스, 다른 AWS 계정 (VPC 엔드 포인트 서비스)에서 호스팅하는 서비스 및 지원되는 AWS Marketplace 파트너 서비스에 VPC를 비공개로 연결할 수 있는 고 가용성의 확장 가능한 기술입니다. 서비스와 통신하기 위해 인터넷 게이트웨이, NAT 디바이스, 퍼블릭 IP 주소, AWS Direct Connect 연결 또는 VPN 연결이 필요하지 않습니다. VPC와 서비스 간의 트래픽은 Amazon 네트워크를 떠나지 않습니다.
프라이빗 링크는 마이크로 서비스 아키텍처의 격리를 향상시키는 좋은 방법입니다. 예를 들어, 각각 호스팅하고 단일 마이크로 서비스를 제공하는 수백 개의 VPC를 생성 할 수 있습니다. 회사는 이제 개인 연결을 통해 액세스 할 수 있도록 서비스를 생성하여 다른 AWS 고객에게 판매 할 수 있습니다. TCP 트래픽을 수락하고 Network Load Balancer 뒤에서 호스팅 한 다음 직접 또는 AWS Marketplace에서 서비스를 제공하는 서비스를 생성합니다. 새 구독 요청에 대한 알림을 받고 각 요청을 수락 또는 거부하도록 선택할 수 있습니다. AWS PrivateLink의 강력한 기능은 여러 시나리오에서 장점이 있지만 SaaS 조직에 특히 중요합니다. SaaS 제공 업체는 AWS PrivateLink를 통해 이 네트워킹 구성을 사용하여 솔루션의 아키텍처 및 비즈니스 모델을 향상시키고 확장 할 수 있는 새롭고 창의적인 기회를 보게 됩니다.
Data Store
데이터 저장소는 마이크로 서비스에 필요한 데이터를 유지하는 데 사용됩니다. 세션 데이터의 인기 저장소는 Memcached 또는 Redis와 같은 메모리 내 캐시입니다. AWS는 관리형 Amazon ElastiCache 서비스의 일부로 두 기술을 모두 제공합니다.
애플리케이션 서버와 데이터베이스 사이에 캐시를 두는 것은 데이터베이스의 읽기로드를 줄이는 일반적인 메커니즘으로, 더 많은 쓰기를 지원하기 위해 자원을 사용할 수 있습니다. 캐시는 또한 대기 시간을 향상시킬 수 있습니다.
관계형 데이터베이스는 구조화 된 데이터 및 비즈니스 개체를 저장하는 데 여전히 널리 사용됩니다. AWS는 Amazon Relational Database Service (Amazon RDS)를 통해 6 개의 데이터베이스 엔진 (Microsoft SQL Server, Oracle, MySQL, MariaDB, PostgreSQL 및 Amazon Aurora)을 관리 서비스로 제공합니다.
그러나 관계형 데이터베이스는 끝없는 확장을 위해 설계되지 않았으므로 많은 수의 쿼리를 지원하는 기술을 적용하기가 어렵고 시간이 많이 걸립니다.
NoSQL 데이터베이스는 관계형 데이터베이스의 일관성보다 확장성, 성능 및 가용성을 높이도록 설계 되었습니다. NoSQL 데이터베이스의 중요한 요소 중 하나는 일반적으로 엄격한 스키마를 적용하지 않는다는 것입니다. 데이터는 수평으로 확장 할 수 있는 파티션에 분산되며 파티션키를 사용하여 검색됩니다.
개별 마이크로 서비스는 한 가지 일을 잘 수행하도록 설계 되었기 때문에 일반적으로 NoSQL 지속성에 적합 할 수 있는 단순화 된 데이터 모델이 있습니다. NoSQL 데이터베이스는 관계형 데이터베이스와는 다른 액세스 패턴을 가지고 있음을 이해해야 합니다. 예를 들어, 테이블을 조인 할 수 없습니다. 이것이 필요한 경우 응용 프로그램에서 논리를 구현해야 합니다. Amazon DynamoDB를 사용하여 많은 양의 데이터를 저장 및 검색하고 모든 수준의 요청 트래픽을 처리 할 수 있는 데이터베이스 테이블을 생성 할 수 있습니다. DynamoDB는 한 자리 밀리 초 성능을 제공하지만 마이크로 초 단위의 응답 시간이 필요한 특정 사용 사례가 있습니다. DynamoDB Accelerator (DAX)는 데이터 액세스를 위한 캐싱 기능을 제공합니다.
또한 DynamoDB는 실제 트래픽에 따라 처리량 용량을 동적으로 조정할 수있는 자동 조정 기능을 제공합니다. 그러나 애플리케이션에서 짧은 기간 동안 활동이 크게 증가하여 용량 계획이 어렵거나 불가능한 경우가 있습니다. 이러한 상황에서 DynamoDB는 온 디맨드 옵션을 제공하며 간단한 요청 당 지불 요금을 제공합니다. DynamoDB 온 디맨드는 용량 계획없이 초당 수천 건의 요청을 즉시 처리 할 수 있습니다.
운영 복잡성 감소
지금까지 설명한 아키텍처는 이미 관리 서비스를 사용하고 있지만 Amazon EC2 (Amazon Elastic Compute Cloud) 인스턴스를 계속 관리해야 합니다. 완전히 서버리스 아키텍처를 사용하여 마이크로 서비스를 운영, 유지 보수 및 모니터링하는 데 필요한 운영 노력을 더욱 줄일 수 있습니다.
API 구현
API를 설계, 배포, 모니터링, 지속적으로 개선 및 유지 관리하는데 시간이 오래 걸릴 수 있습니다. 모든 클라이언트의 이전 버전과의 호환성을 보장하기 위해 다른 버전의 API를 실행해야하는 경우가 있습니다. 개발 주기의 다른 단계 (즉, 개발, 테스트 및 생산)는 운영 노력을 더욱 배가시킵니다.
권한 부여는 모든 API에 중요한 기능이지만 일반적으로 반복 작업을 작성하고 복잡하게 만듭니다. API가 게시되고 성공하면 API를 사용하는 타사 개발자의 에코 시스템을 관리, 모니터링 및 수익을 창출해야 합니다.
다른 중요한 기능과 과제로는 백엔드 서비스 보호 요청 제한, API 응답 캐싱, 요청 및 응답 변환 처리, Swagger와 같은 도구를 사용하여 API 정의 및 문서 생성이 있습니다.
Amazon API Gateway는 이러한 문제를 해결하고 RESTful API 생성 및 유지 관리의 운영 복잡성을 줄입니다.
API Gateway를 사용하면 AWS API 또는 AWS Management Console을 사용하여 Swagger 정의를 가져와 프로그래밍 방식으로 API를 생성 할 수 있습니다. API Gateway는 Amazon EC2, Amazon ECS, AWS Lambda 또는 온 프레미스 환경에서 실행되는 모든 웹 애플리케이션의 정문 역할을합니다. 기본적으로 API Gateway를 사용하면 서버를 관리하지 않고도 API를 실행할 수 있습니다.
그림 2는 API Gateway가 API 호출을 처리하고 다른 구성 요소와 상호 작용하는 방법을 보여줍니다. 모바일 디바이스, 웹 사이트 또는 기타 백엔드 서비스의 요청은 대기 시간을 최소화하고 최적의 사용자 경험을 제공하기 위해 가장 가까운 CloudFront Presence (PoP)로 라우팅됩니다.
서버리스 마이크로 서비스
“서버가 없는 것보다 관리하기 쉬운 서버가 없습니다”. 서버를 제거하는 것은 운영상의 복잡성을 제거하는 좋은 방법입니다.
Lambda는 API Gateway와 긴밀하게 통합되어 있습니다. API Gateway에서 Lambda로 동기식 호출 기능을 사용하면 완전한 서버리스 애플리케이션을 작성할 수 있으며 설명서에 자세히 설명되어 있습니다.
그림 3은 전체 서비스가 관리형 서비스로 구축 된 AWS Lambda를 사용한 서버리스 마이크로 서비스의 아키텍처를 보여줍니다. 따라서 규모와 고 가용성을 위해 설계해야 할 아키텍처적 부담을 없애고 마이크로 서비스의 기본 인프라를 운영 및 모니터링하는 운영 노력이 필요 없습니다.
그림 4는 서버리스 서비스를 기반으로 하는 유사한 구현을 보여줍니다. 이 아키텍처에서 Docker 컨테이너는 AWS Fargate와 함께 사용되므로 기본 인프라에 신경 쓸 필요가 없습니다. Amazon DynamoDB 외에도 Amazon Aurora Serverless가 사용됩니다.
Amazon Aurora (MySQL 호환 에디션)를 위한 온 디맨드 자동 스케일링 구성. 데이터베이스는 애플리케이션의 요구에 따라 자동으로 시작, 종료 및 용량 확장 또는 축소됩니다.
Lambda 기반 응용 프로그램 배포
AWS CloudFormation을 사용하여 서버리스 애플리케이션을 정의, 배포 및 구성 할 수 있습니다.
AWS SAM (AWS Serverless Application Model)은 서버리스 애플리케이션을 정의하는 편리한 방법입니다. AWS SAM은 기본적으로 CloudFormation에서 지원되며 서버리스 리소스를 표현하기위한 간단한 구문을 정의합니다. 애플리케이션을 배포하려면 CloudFormation 템플릿에서 관련 권한 정책과 함께 애플리케이션의 일부로 필요한 리소스를 지정하고 배포 아티팩트를 패키지 한 다음 템플릿을 배포하십시오. AWS SAM을 기반으로 하는 SAM 로컬은 서버리스 애플리케이션을 Lambda 런타임에 업로드하기 전에 로컬로 서버리스 애플리케이션을 개발, 테스트 및 분석 할 수 있는 환경을 제공하는 AWS CLI 도구입니다. SAM 로컬을 사용하여 AWS 런타임 환경을 시뮬레이트하는 로컬 테스트 환경을 만들 수 있습니다.
분산 시스템 구성 요소
AWS가 개별 마이크로 서비스와 관련된 문제를 해결하는 방법을 살펴본 후 서비스 검색, 데이터 일관성, 비동기 통신 및 분산 모니터링 및 감사와 같은 서비스 간 문제에 중점을 두고 자합니다.
Service Discovery
마이크로 서비스 아키텍처의 주요 과제 중 하나는 서비스가 서로를 발견하고 상호 작용할 수 있도록 하는 것입니다. 마이크로 서비스 아키텍처의 분산 된 특성은 서비스의 통신을 어렵게 할뿐만 아니라 해당 시스템의 상태를 확인하고 새로운 응용 프로그램을 사용할 수 있게 되면 발표하는 등의 다른 과제를 제시합니다. 또한 응용 프로그램에서 사용할 수 있는 구성 데이터와 같은 메타 저장소 정보를 저장하는 방법과 위치를 결정해야합니다. 이 섹션에서는 마이크로 서비스 기반 아키텍처를 위해 AWS에서 서비스 검색을 수행하는 몇 가지 기술을 살펴 봅니다.
DNS 기반 서비스 검색
Amazon ECS에는 이제 컨테이너화 된 서비스가 서로 쉽게 검색하고 연결할 수 있는 통합 서비스 검색 기능이 포함되어 있습니다.
이전에는 서비스가 서로를 검색하고 연결할 수 있도록 하려면 Amazon Route 53, AWS Lambda 및 ECS Event Stream을 기반으로 고유 한 서비스 검색 시스템을 구성 및 실행하거나 모든 서비스를 로드밸런서에 연결해야 습니다.
Amazon ECS는 Route 53 자동 이름 지정 API를 사용하여 서비스 이름의 레지스트리를 생성하고 관리합니다. 이름은 DNS 레코드 세트에 자동으로 매핑되므로 코드에서 이름으로 서비스를 참조하고 DNS 쿼리를 작성하여 런타임시 서비스 엔드 포인트로 이름을 확인할 수 있습니다. 서비스 작업 정의에서 상태 확인 조건을 지정할 수 있으며 Amazon ECS는 서비스 조회에서 정상적인 서비스 엔드 포인트만 반환되도록 합니다.
또한 Kubernetes에서 관리하는 서비스에 대해 통합 서비스 검색을 활용할 수도 있습니다. 이러한 통합을 가능하게하기 위해 AWS는 Kubernetes 인큐베이터 프로젝트 인 외부 DNS 프로젝트에 기여했습니다.
다른 옵션은 AWS 클라우드 맵의 기능을 활용하는 것입니다. AWS Cloud Map은 IP, URL 및 ARN과 같은 리소스에 대한 서비스 레지스트리를 제공하고 변경 전파 속도가 더 빨라지고 속성을 사용하여 범위를 좁힐 수 있는 API 기반 서비스 검색 메커니즘을 제공함으로써 Auto Naming API의 기능을 확장합니다. 기존 Route 53 자동 이름 지정 리소스는 AWS 클라우드 맵으로 자동 업그레이드됩니다.
Third-party software
서비스 검색을 구현하는 다른 방법은 HashiCorp Consul, etcd 등과 같은 타사 소프트웨어 또는 Netflix Eureka를 사용하는 것입니다. 세 가지 예는 모두 분산 된 안정적인 키-값 저장소입니다. HashiCorp Consul에는 유연하고 확장 가능한 AWS 클라우드 환경을 설정하고 원하는 구성으로 HashiCorp Consul을 자동으로 시작하는 AWS Quick Start가 있습니다.
Service Meshes
고급 마이크로 서비스 아키텍처에서 실제 애플리케이션은 수백 또는 수천 개의 서비스로 구성 될 수 있습니다. 응용 프로그램의 가장 복잡한 부분은 실제 서비스 자체가 아니라 해당 서비스간의 통신입니다. 서비스 메시는 서비스 간 통신 처리를 위한 추가 계층으로, 마이크로 서비스 아키텍처에서 트래픽을 모니터링하고 제어합니다. 이를 통해 서비스 검색과 같은 작업을 이 계층에서 완전히 처리 할 수 있습니다.
일반적으로 서비스 메시는 데이터 평면과 제어 평면으로 분할됩니다. 데이터 플레인은 애플리케이션 코드와 함께 마이크로 서비스간의 모든 네트워크 통신을 가로채는 특수 사이드카 프록시로 배치 된 지능형 프록시 세트로 구성됩니다. 컨트롤 플레인은 프록시와의 통신을 담당합니다.
서비스 메시는 투명하므로 애플리케이션 개발자는이 추가 계층을 알 필요가 없으며 기존 애플리케이션 코드를 변경할 필요가 없습니다. AWS App Mesh는 애플리케이션 수준 네트워킹을 제공하여 서비스가 여러 유형의 컴퓨팅 인프라에서 서로 쉽게 통신 할 수 있도록 하는 서비스 메시입니다. App Mesh는 서비스 통신 방식을 표준화하여 엔드 투 엔드 가시성을 제공하고 애플리케이션의 고 가용성을 보장합니다.
AWS Fargate, Amazon ECS, Amazon EKS 및 자체 관리형 Kubernetes에서 실행되는 기존 또는 새로운 마이크로 서비스와 함께 AWS App Mesh를 사용할 수 있습니다. App Mesh는 코드 변경 없이 단일 응용 프로그램으로 클러스터, 오케스트레이션 시스템 또는 VPC에서 실행되는 마이크로 서비스에 대한 통신을 모니터링하고 제어 할 수 있습니다.
분산 데이터 관리
모놀리식 응용 프로그램은 일반적으로 모든 응용 프로그램 구성 요소에 공통적인 단일 데이터 모델을 정의하는 대형 관계형 데이터베이스로 지원됩니다. 마이크로 서비스 접근 방식에서 이러한 중앙 데이터베이스는 분산되고 독립적인 구성 요소를 구축하려는 목표를 막을 수 있습니다. 각 마이크로 서비스 구성 요소에는 자체 데이터 지속성 계층이 있어야합니다.
그러나 분산 데이터 관리는 새로운 과제를 제기합니다. CAP 정리의 결과로, 분산 마이크로 서비스 아키텍처는 본질적으로 성능의 일관성을 절충하며 최종 일관성을 수용해야 합니다.
분산 시스템에서 비즈니스 트랜잭션은 여러 마이크로 서비스에 걸쳐 있을 수 있습니다. 단일 ACID 트랜잭션을 활용할 수 없기 때문에 부분적으로 실행할 수 있습니다. 이 경우 이미 처리 된 트랜잭션을 다시 실행하려면 제어 로직이 필요합니다. 이를 위해 분산 Saga pattern이 일반적으로 사용됩니다. 비즈니스 트랜잭션이 실패한 경우 Saga는 이전 트랜잭션에서 작성된 변경 사항을 취소하는 일련의 보상 트랜잭션을 오케스트레이션 합니다. AWS Step Functions를 사용하면 다음 그림과 같이 Saga 실행 코디네이터를 쉽게 구현할 수 있습니다.
마스터 데이터 관리 도구 및 절차에 의해 선별 된 중요한 기준 데이터의 중앙 저장소를 구축하면 마이크로 서비스가 중요한 데이터를 동기화하고 가능하면 롤백 상태를 유지할 수 있습니다. 예약된 Amazon CloudWatch Events와 함께 Lambda를 사용하면 간단한 정리 및 중복 제거 메커니즘을 구축 할 수 있습니다.
상태 변경이 단일 마이크로 서비스 이상에 영향을 주는 것은 매우 일반적입니다. 이러한 경우 이벤트 소싱이 유용한 패턴으로 입증되었습니다. 이벤트 소싱의 핵심 아이디어는 모든 애플리케이션 변경 사항을 이벤트 레코드로 표현하고 유지하는 것입니다. 응용 프로그램 상태를 유지하는 대신 데이터는 이벤트 스트림으로 저장됩니다. 데이터베이스 트랜잭션 로깅 및 버전 제어 시스템은 이벤트 소싱의 잘 알려진 두 가지 예입니다. 이벤트 소싱에는 몇 가지 이점이 있습니다. 상태를 특정 시점에 따라 결정하고 재구성 할 수 있습니다. 당연히 지속적인 감사 추적을 생성하고 디버깅을 용이하게 합니다.
마이크로 서비스 아키텍처와 관련하여 이벤트 소싱을 사용하면 게시 / 구독 패턴을 사용하여 응용 프로그램의 다른 부분을 분리 할 수 있으며 별도의 마이크로 서비스를 위해 동일한 이벤트 데이터를 다른 데이터 모델로 공급합니다. 이벤트 소싱은 CQRS (Command Query Responsibility Segregation) 패턴과 함께 사용되어 쓰기 워크로드에서 읽기를 분리하고 성능, 확장 성 및 보안을 위해 최적화합니다. 기존의 데이터 관리 시스템에서 명령 및 쿼리는 동일한 데이터 저장소에 대해 실행됩니다.
그림 6은 AWS에서 이벤트 소싱 패턴을 구현하는 방법을 보여줍니다. Amazon Kinesis Data Streams는 중앙 이벤트 저장소의 주요 구성 요소로, 애플리케이션 변경 사항을 이벤트로 캡처하여 Amazon S3에 유지합니다.
그림 6은 Amazon API Gateway, AWS Lambda 및 Amazon DynamoDB로 구성된 세 가지 마이크로 서비스를 보여줍니다. 파란색 화살표는 이벤트 흐름을 나타냅니다. 마이크로 서비스 1이 이벤트 상태 변경을 경험하면 Kinesis Data Streams에 메시지를 작성하여 이벤트를 게시합니다. 모든 마이크로 서비스는 AWS Lambda에서 자체 Kinesis Data Streams 애플리케이션을 실행하여 메시지 사본을 읽고 마이크로 서비스의 관련성에 따라 필터링 한 후 추가 처리를 위해 전달합니다.
Amazon S3는 모든 마이크로 서비스 전반에 걸쳐 모든 이벤트를 지속적으로 저장하며 디버깅, 애플리케이션 상태 복구 또는 애플리케이션 변경 감사와 관련하여 단일 정보 소스입니다.
비동기식 통신 및 경량 메시징
전통적인 단일 응용 프로그램의 통신은 간단합니다. 응용 프로그램의 한 부분은 메서드 호출 또는 내부 이벤트 배포 메커니즘을 사용하여 다른 부분과 통신합니다. 분리 된 마이크로 서비스를 사용하여 동일한 응용 프로그램을 구현하는 경우 응용 프로그램의 다른 부분 간의 통신은 네트워크 통신을 사용하여 구현해야합니다.
REST 기반 통신
HTTP / S 프로토콜은 마이크로 서비스 간 동기 통신을 구현하는 가장 보편적 인 방법입니다. 대부분의 경우 RESTful API는 HTTP를 전송 계층으로 사용합니다. REST 아키텍처 스타일은 상태 비 저장 통신, 균일 한 인터페이스 및 표준 방법에 의존합니다.
API Gateway를 사용하면 애플리케이션이 Amazon EC2 및 Amazon ECS에서 실행되는 워크로드, Lambda에서 실행되는 코드 또는 웹 애플리케이션. API Gateway 서비스로 정의 된 API 객체는 리소스 및 메서드 그룹입니다.
리소스는 API 도메인 내의 유형이 지정된 개체이며 데이터 모델 또는 다른 리소스와의 관계를 연결할 수 있습니다. 각 자원은 하나 이상의 메소드, 즉 GET, POST 또는 PUT과 같은 표준 HTTP 동사에 응답하도록 구성 할 수 있습니다. REST API는 다른 단계에 배포하고 버전을 지정하고 새 버전으로 복제 할 수 있습니다.
API Gateway는 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링 및 API 버전 관리를 포함하여 최대 수십만 개의 동시 API 호출 수락 및 처리와 관련된 모든 작업을 처리합니다.
비동기 메시징 및 이벤트 전달
마이크로 서비스 간의 통신을 구현하기위한 추가 패턴은 메시지 전달입니다. 서비스는 큐를 통해 메시지를 교환하여 통신합니다. 이 커뮤니케이션 스타일의 주요 이점 중 하나는 서비스를 검색 할 필요가 없고 서비스가 느슨하다는 것입니다.
동기식 시스템은 밀접하게 결합되어 동기식 다운 스트림 종속성의 문제가 업스트림 발신자에게 즉각적인 영향을 미칩니다. 업스트림 발신자의 재시도는 신속하게 팬 아웃하여 문제를 증폭시킬 수 있습니다.
프로토콜과 같은 특정 요구 사항에 따라 AWS는이 패턴을 구현하는 데 도움이되는 다양한 서비스를 제공합니다. 하나의 가능한 구현은 Amazon SQS (Amazon Simple Queue Service)와 Amazon SNS (Amazon Simple Notification Service)의 조합을 사용합니다.
두 서비스 모두 밀접하게 작동합니다. Amazon SNS를 통해 애플리케이션은 푸시 메커니즘을 통해 여러 가입자에게 메시지를 보낼 수 있습니다. Amazon SNS와 Amazon SQS를 함께 사용하면 여러 소비자에게 하나의 메시지를 전달할 수 있습니다. 그림 7은 Amazon SNS와 Amazon SQS의 통합을 보여줍니다.
SQS 대기열을 SNS 주제에 가입하면 주제에 메시지를 게시 할 수 있으며 Amazon SNS는 가입 한 SQS 대기열에 메시지를 보냅니다. 메시지에는 JSON 형식의 메타 데이터 정보와 함께 주제에 게시 된 제목 및 메시지가 포함됩니다.
기존의 소프트웨어가 JMS, NMS, AMQP, STOMP, MQTT 및 WebSocket을 포함한 메시징을 위해 개방형 표준 API 및 프로토콜을 사용하는 경우 사용할 수 있는 다른 구현 전략은 Amazon MQ를 기반으로 합니다. Amazon SQS는 커스텀 API를 제공합니다. 즉, 기존 애플리케이션을 마이그레이션하려는 경우를 의미합니다. AWS에 대한 온 프레미스 환경에서는 코드를 변경해야 합니다. Amazon MQ에서는 많은 경우에 필요하지 않습니다.
Amazon MQ는 널리 사용되는 오픈 소스 메시지 브로커인 ActiveMQ의 관리 및 유지 관리를 관리합니다. 기본 인프라는 애플리케이션의 안정성을 지원하기 위해 고 가용성 및 메시지 내구성을 위해 자동으로 프로비저닝 됩니다.
오케스트레이션 및 상태 관리
마이크로 서비스의 분산 특성으로 인해 여러 마이크로 서비스가 포함 된 경우 워크 플로우를 조정하기가 어렵습니다. 개발자는 서비스에 오케스트레이션 코드를 직접 추가하려는 유혹을 받을 수 있습니다. 더 긴밀한 연결을 도입하고 개별 서비스를 빠르게 교체하기 어렵게 하므로 피해야합니다.
단계 함수를 사용하여 각각 개별 기능을 수행하는 개별 구성 요소에서 응용 프로그램을 빌드 할 수 있습니다. Step Functions는 오류 처리 및 직렬화 / 병렬화와 같은 복잡한 서비스 오케스트레이션을 숨기는 상태 머신을 제공합니다. 이를 통해 서비스 내부의 추가 조정 코드를 피하면서 애플리케이션을 신속하게 확장 및 변경할 수 있습니다.
Step Functions는 구성 요소를 조정하고 응용 프로그램의 기능을 단계별로 확인할 수 있는 안정적인 방법입니다. 단계 기능은 일련의 단계로 응용 프로그램의 구성 요소를 배열하고 시각화하는 그래픽 콘솔을 제공합니다. 따라서 분산 서비스를 간단하게 구축하고 실행할 수 있습니다.
단계 함수는 각 단계를 자동으로 트리거 및 추적하고 오류가 있을 때 재 시도하므로 애플리케이션이 순서대로 예상대로 실행됩니다. 단계 함수는 각 단계의 상태를 기록하므로 문제가 발생하면 문제를 신속하게 진단하고 디버그 할 수 있습니다. 코드를 작성하지 않고도 단계를 변경하고 추가하여 애플리케이션을 발전시키고 더 빠르게 혁신 할 수 있습니다.
Step Functions는 AWS 서버리스 플랫폼의 일부이며 Amazon EC2 및 Amazon ECS와 같은 컴퓨팅 리소스와 Amazon SageMaker 및 AWS Glue와 같은 추가 서비스를 기반으로 하는 애플리케이션뿐만 아니라 Lambda 함수의 오케스트레이션을 지원합니다. 그림 8은 Lambda 함수 호출이 Step Functions에서 Lambda로 직접 푸시되는 반면 Amazon EC2 또는 Amazon ECS의 작업자는 지속적으로 호출을 폴링하는 방법을 보여줍니다.
Step Functions는 애플리케이션을 모든 규모에서 사용할 수 있도록 운영 및 기본 인프라를 관리합니다.
워크 플로우를 구축하기 위해 Step Functions는 Amazon States Language를 사용합니다. 워크 플로우에는 분기 단계뿐만 아니라 순차적 또는 병렬 단계가 포함될 수 있습니다.
그림 9는 순차적 및 병렬 단계를 결합한 마이크로 서비스 아키텍처의 워크 플로우 예를 보여줍니다. 이러한 워크 플로우 호출은 Step Functions API 또는 API Gateway를 통해 수행 할 수 있습니다.
분산 모니터링
마이크로 서비스 아키텍처는 모니터링 해야 하는 여러 가지 분산 된 부분으로 구성됩니다.
Amazon CloudWatch를 사용하여 지표를 수집 및 추적하고, 로그 파일을 중앙 집중화 및 모니터링하며, 경보를 설정하고, AWS 환경의 변화에 자동으로 대응할 수 있습니다. CloudWatch는 EC2 인스턴스, DynamoDB 테이블 및 RDS DB 인스턴스와 같은 AWS 리소스는 물론 애플리케이션 및 서비스에서 생성 된 사용자 지정 지표와 애플리케이션이 생성하는 모든 로그 파일을 모니터링 할 수 있습니다.
모니터링
CloudWatch를 사용하여 시스템 전체에서 리소스 사용률, 애플리케이션 성능 및 운영 상태를 파악할 수 있습니다. CloudWatch는 몇 분 안에 사용할 수있는 안정적이고 확장 가능하며 유연한 모니터링 솔루션을 제공합니다. 더 이상 자체 모니터링 시스템 및 인프라를 설정, 관리 및 확장 할 필요가 없습니다. 마이크로 서비스 아키텍처에서 CloudWatch를 사용하여 사용자 지정 지표를 모니터링하는 기능은 개발자가 각 서비스에 대해 수집 할 지표를 결정할 수 있기 때문에 추가 이점이 있습니다. 또한 사용자 지정 메트릭을 기반으로 동적 스케일링을 구현할 수 있습니다.
특히 Amazon EKS에 널리 사용되는 또 다른 옵션은 Prometheus를 사용하는 것입니다. Prometheus는 오픈 소스 모니터링 및 경고 툴킷으로 Grafana와 함께 수집 된 메트릭을 시각화하는 데 자주 사용됩니다. 많은 Kubernetes 구성 요소는 / metrics에 메트릭을 저장하며 Prometheus는 이러한 메트릭을 정기적으로 긁을 수 있습니다.
중앙 집중식 로그
일관된 로깅은 문제를 해결하고 식별하는 데 중요합니다. 마이크로 서비스를 통해 팀은 이전보다 더 많은 릴리스를 제공하고 엔지니어링 팀이 프로덕션의 새로운 기능에 대한 실험을 수행하도록 장려합니다. 고객 영향을 이해하는 것은 점차적으로 응용 프로그램을 개선하는 데 중요합니다.
대부분의 AWS 서비스는 기본적으로 로그 파일을 중앙 집중화 합니다. AWS에서 로그 파일의 기본 대상은 Amazon S3 및 Amazon CloudWatch Logs입니다. EC2 인스턴스에서 실행되는 애플리케이션의 경우 로그 파일을 CloudWatch Logs로 보내는 데몬을 사용할 수 있습니다. Lambda 함수는 기본적으로 로그 출력을 CloudWatch Logs로 전송하고 Amazon ECS에는 컨테이너 로그를 CloudWatch Logs로 중앙 집중화 할 수 있는 awslogs 로그 드라이버 지원이 포함되어 있습니다. Amazon EKS의 경우 개별 인스턴스의 로그를 전달하는 FluentD를 실행해야 합니다. Elasticsearch 및 Kibana를 사용하여 상위 레벨 보고를 위해 통합 된 중앙 로깅 CloudWatch Logs에 대한 클러스터.
그림 10은 일부 서비스의 로깅 기능을 보여줍니다. 그런 다음 팀은 Amazon Elasticsearch Service (Amazon ES) 및 Kibana와 같은 도구를 사용하여 이러한 로그를 검색하고 분석 할 수 있습니다. Amazon Athena는 Amazon S3의 중앙 집중식 로그 파일에 대해 임시 쿼리를 실행하는 데 사용할 수 있습니다.
분산 추적
대부분의 경우 마이크로 서비스 세트가 함께 작동하여 요청을 처리합니다. 콜 체인의 서비스 중 하나에서 오류가 발생하는 수십 개의 마이크로 서비스로 구성된 복잡한 시스템을 상상해보십시오. 모든 마이크로 서비스가 올바르게 로깅되고 로그가 중앙 시스템에 통합되어 있어도 모든 관련 로그 메시지를 찾기가 어려울 수 있습니다.
AWS X-Ray의 기본 개념은 특정 이벤트 체인과 관련된 모든 요청 및 메시지에 첨부 된 고유 식별자인 상관 관계 ID를 사용하는 것입니다. 추적 ID는 요청이 첫 번째 X-Ray 통합 서비스 (예 : Application Load Balancer 또는 API Gateway)에 도달하고 응답에 포함될 때 X-Amzn-Trace-Id라는 특정 추적 헤더의 HTTP 요청에 추가됩니다. X-Ray SDK를 통해 모든 마이크로 서비스는 이 헤더를 읽거나 추가하거나 업데이트 할 수 있습니다.
AWS X-Ray는 Amazon EC2, Amazon ECS, Lambda 및 AWS Elastic Beanstalk와 함께 작동합니다. 이러한 서비스에 배포 된 Java, Node.js 및 .NET으로 작성된 응용 프로그램과 함께 X-Ray를 사용할 수 있습니다.
AWS의 로그 분석 옵션
로그 데이터를 검색, 분석 및 시각화하는 것은 분산 시스템을 이해하는 데 중요한 측면입니다. Amazon CloudWatch Logs Insights는 즉시 로그를 탐색, 분석 및 시각화 할 수있는 훌륭한 서비스입니다. 이를 통해 운영 문제를 해결할 수 있습니다. 로그 파일을 분석하는 또 다른 옵션은 Kibana와 함께 Amazon ES를 사용하는 것입니다.
Amazon ES는 전체 텍스트 검색, 구조적 검색, 분석 및이 세 가지를 모두 조합하여 사용할 수 있습니다. Kibana는 Amazon ES용 오픈 소스 데이터 시각화 플러그인으로 완벽하게 통합됩니다.
그림 12는 Amazon ES 및 Kibana를 사용한 로그 분석을 보여줍니다. CloudWatch Logs 구독을 통해 거의 실시간으로 로그 항목을 Amazon ES로 스트리밍하도록 CloudWatch Logs를 구성 할 수 있습니다. Kibana는 데이터를 시각화하고 편리한 검색 인터페이스를 Amazon ES의 데이터 저장소에 노출합니다. 이 솔루션은 ElastAlert와 같은 소프트웨어와 함께 사용하여 데이터에서 이상, 스파이크 또는 기타 관심 패턴이 감지되는 경우 SNS 알림, 이메일, JIRA 티켓 생성 등을 보내기 위해 경고 시스템을 구현할 수 있습니다.
로그 파일을 분석하는 또 다른 옵션은 Amazon RedSight를 Amazon QuickSight와 함께 사용하는 것입니다.
Amazon QuickSight는 Amazon Redshift, Amazon RDS, Amazon Aurora, Amazon EMR, Amazon DynamoDB, Amazon S3 및 Amazon Kinesis를 포함한 AWS 데이터 서비스에 쉽게 연결할 수 있습니다.
Amazon CloudWatch Logs는 로그 데이터의 중앙 집중식 저장소 역할을 할 수 있으며 데이터 저장뿐 아니라 Amazon Kinesis Data Firehose에 로그 항목을 스트리밍 할 수 있습니다.
그림 13은 CloudWatch Logs 및 Kinesis Data Firehose를 사용하여 로그 항목이 다른 소스에서 Amazon Redshift로 스트리밍되는 시나리오를 보여줍니다. Amazon QuickSight는 분석,보고 및 시각화를 위해 Amazon Redshift에 저장된 데이터를 사용합니다.
그림 14는 Amazon S3의 로그 분석 시나리오를 보여줍니다. 로그가 S3 버킷에 저장되면 Amazon Redshift 또는 Amazon EMR과 같은 다른 AWS 데이터 서비스에 로그 데이터를로드하여 로그 스트림에 저장된 데이터를 분석하고 이상을 찾을 수 있습니다.
대화
대화성 단일 응용 프로그램을 작은 마이크로 서비스로 나누면 마이크로 서비스가 서로 통신해야하기 때문에 통신 오버 헤드가 증가합니다. 많은 구현에서 HTTP를 통한 REST는 가벼운 통신 프로토콜이지만 메시지 양이 많으면 문제가 발생할 수 있으므로 HTTP를 통한 REST가 사용됩니다. 경우에 따라 많은 메시지를 주고 받는 서비스 통합을 고려할 수 있습니다. 통신를 줄이기 위해 점점 더 많은 서비스를 통합하는 상황에 처한 경우 문제 도메인과 도메인 모델을 검토해야합니다.
프로토콜
이 백서의 앞부분 인 비동기 통신 및 경량 메시징 섹션에서 다른 가능한 프로토콜에 대해 설명합니다. 마이크로 서비스의 경우 HTTP와 같은 간단한 프로토콜을 사용하는 것이 일반적입니다. 서비스가 교환하는 메시지는 JSON 또는 YAML과 같은 사람이 읽을 수 있는 형식 또는 Avro 또는 프로토콜 버퍼와 같은 효율적인 이진 형식과 같은 다양한 방식으로 인코딩 될 수 있습니다.
캐싱
캐시는 마이크로 서비스 아키텍처의 대기 시간과 통신을 줄일 수 있는 좋은 방법입니다. 실제 사용 사례와 병목 현상에 따라 여러 캐싱 계층이 가능합니다. AWS에서 실행되는 많은 마이크로 서비스 애플리케이션은 Amazon ElastiCache를 사용하여 결과를 로컬로 캐싱하여 다른 마이크로 서비스에 대한 호출 량을 줄입니다. API Gateway는 내장 된 캐싱 계층을 제공하여 백엔드 서버의 로드를 줄입니다. 또한 캐싱은 데이터 지속성 계층의 로드를 줄이는 데 유용합니다. 모든 캐싱 메커니즘의 과제는 적절한 캐시 적중률과 데이터의 적시성 / 일관성간에 적절한 균형을 찾는 것입니다.
감사
잠재적으로 수백 개의 분산 서비스를 보유 할 수 있는 마이크로 서비스 아키텍처에서 해결해야 할 또 다른 과제는 각 서비스에 대한 사용자 작업의 가시성을 확보하고 조직 수준에서 모든 서비스에 대해 전체적으로 잘 볼 수 있는 것입니다. 보안 정책을 시행하려면 시스템 변경을 초래하는 활동뿐만 아니라 자원 액세스도 감사해야 합니다.
변경 사항은 개별 서비스 수준과 더 넓은 시스템에서 실행되는 서비스 전체에서 추적해야 합니다. 일반적으로 변경은 마이크로 서비스 아키텍처에서 자주 발생하므로 감사 변경이 더욱 중요합니다. 이 섹션에서는 마이크로 서비스 아키텍처를 감사하는 데 도움이 되는 AWS의 주요 서비스 및 기능을 살펴 봅니다.
Audit Trail
AWS CloudTrail은 AWS 클라우드에서 이루어진 모든 API 호출을 실시간으로 CloudWatch Logs 또는 몇 분 내에 Amazon S3에 기록 및 전송할 수 있으므로 마이크로 서비스의 변경 사항을 추적하는 데 유용한 도구입니다.
모든 사용자 및 자동화 된 시스템 작업을 검색 할 수 있으며 예기치 않은 동작, 회사 정책 위반 또는 디버깅에 대해 분석 할 수 있습니다. 기록 된 정보에는 타임 스탬프, 사용자 / 계정 정보, 호출 된 서비스, 요청 된 서비스 작업, 호출자의 IP 주소 및 요청 매개 변수 및 응답 요소가 포함됩니다.
CloudTrail을 사용하면 동일한 계정에 대해 여러 트레일을 정의 할 수 있으므로 보안 관리자, 소프트웨어 개발자 또는 IT 감사 자와 같은 다양한 이해 관계자가 자신의 트레일을 생성하고 관리 할 수 있습니다. 마이크로 서비스 팀에 다른 AWS 계정이있는 경우 추적을 단일 S3 버킷으로 집계 할 수 있습니다.
CloudWatch에 감사 추적을 저장하면 감사 추적 데이터가 실시간으로 캡처되고 검색 및 시각화를 위해 Amazon ES로 정보를 쉽게 라우팅 할 수 있다는 이점이 있습니다. Amazon S3 및 CloudWatch Logs에 모두 로그인하도록 CloudTrail을 구성 할 수 있습니다.
이벤트 및 실시간 액션
시스템 아키텍처의 특정 변경 사항은 신속하게 대응해야 하며 상황을 개선하기 위해 취한 조치 또는 변경을 승인하기 위한 특정 거버넌스 절차를 시작해야합니다.
CloudTrail과 CloudWatch Events를 통합하면 모든 AWS 서비스에서 모든 변경 API 호출에 대한 이벤트를 생성 할 수 있습니다. 고정된 일정에 따라 사용자 정의 이벤트를 정의하거나 이벤트를 생성 할 수도 있습니다.
이벤트가 시작되고 정의된 규칙과 일치하면 조직의 올바른 담당자에게 즉시 알림을 보내 적절한 조치를 취할 수 있습니다. 필요한 작업을 자동화 할 수 있으면 규칙이 자동으로 기본 제공 워크 플로를 트리거하거나 Lambda 함수를 호출하여 문제를 해결할 수 있습니다.
그림 15는 CloudTrail과 CloudWatch Events가 함께 작동하여 마이크로 서비스 아키텍처 내에서 감사 및 치료 요구 사항을 해결하는 환경을 보여줍니다. CloudTrail이 모든 마이크로 서비스를 추적하고 있으며 감사 내역은 S3 버킷에 저장됩니다. CloudWatch 이벤트는 CloudTrail 위에 있으며 아키텍처가 변경되면 경고를 트리거합니다.
자원 인벤토리 및 변경 관리
민첩한 개발 환경에서 빠르게 변화하는 인프라 구성에 대한 제어를 유지하려면 아키텍처를 감사하고 제어하기 위한 자동화 된 관리 방식이 필수적입니다.
CloudTrail 및 CloudWatch Events는 마이크로 서비스 전반의 인프라 변경 사항을 추적하고 이에 대응하기위한 중요한 구성 요소이지만, AWS Config 규칙을 통해 회사는 특정 규칙으로 보안 정책을 정의하여 정책 위반을 자동으로 감지, 추적 및 경고 할 수 있습니다.
다음 예는 마이크로 서비스 아키텍처 내에서 비준수 구성 변경을 감지하고 알리고 자동으로 대응하는 방법을 보여줍니다. 개발 팀의 구성원은 마이크로 서비스가 API 요청만 허용하는 대신 엔드 포인트가 인바운드 HTTP 트래픽을 허용하도록 API 게이트웨이를 변경했습니다.
이 상황은 이전에 조직에서 보안 규정 준수 문제로 확인 되었으므로 AWS Config 규칙은 이미 이 조건을 모니터링하고 있습니다.
규칙은 변경 사항을 보안 위반으로 식별하고 감사를 위해 S3 버킷에서 감지 된 변경 사항의 로그를 생성하고 SNS 알림을 생성하는 두 가지 작업을 수행합니다. Amazon SNS는 시나리오에서 두 가지 목적으로 사용됩니다. 보안 위반에 대해 알리고 SQS 대기열에 메시지를 추가하기 위해 지정된 그룹으로 이메일을 보내는 것입니다. 그런 다음 메시지가 수신되고 API 게이트웨이 구성을 변경하여 준수 상태가 복원됩니다.
결론
마이크로 서비스 아키텍처는 기존의 모 놀리 식 아키텍처의 한계를 극복하기 위한 분산 설계 방식입니다. 마이크로 서비스는 애플리케이션 및 조직을 확장하는 동시에 주기 시간을 향상시킵니다.
그러나 아키텍처 복잡성과 운영 부담이 추가 될 수 있는 몇 가지 문제가 있습니다.
AWS는 제품 팀이 마이크로 서비스 아키텍처를 구축하고 아키텍처 및 운영 복잡성을 최소화하는 데 도움이 되는 대규모 관리 서비스 포트폴리오를 제공합니다. 이 백서는 관련 AWS 서비스 및 AWS 서비스를 통해 서비스 검색 또는 이벤트 소싱과 같은 일반적인 패턴을 구현하는 방법을 안내합니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
