AWS 자격증을 준비하면서 마이크로 서비스 구현에 대한 백서를 읽게 되었다. 백서에 좋은 내용이 많은데 31page의, 그리고 영문으로 된... 백서를 나중에 다시 읽어보는 일이 아마 없지 않을까 싶어서 읽기 좋게 정리를 해놓아야겠다는 생각이 들었다.
포스팅의 주요 목적은 내년에 마이크로 서비스를 구축할 때 내가 다시 한 번 읽어보며 도움이 되기를 바라는 이유이다. 그렇지만 AWS를 이용하여 마이크로 서비스를 구현하려는 개발자나 아키텍처분들에게도 도움이 되었으면 좋겠다.(AWS 자격증을 취득하시는 분들은 이 문서만 보시면 안 되고 꼭 원본 백서를 참고해주세요ㅎㅎ!)
본 포스팅의 내용은 Implementing Microservices on AWS의 내용을 기반으로 보기 좋게 내 방식대로 정리하였고, 중요하다고 생각되는 내용만 정리하였다.
Intro
마이크로서비스 아키텍처란 ❔
마이크로서비스 아키텍처는 완전히 새로운 접근법이 아닌, 정확히 말하면 성공하고 입증된 컨셉의 조합이라고 말할 수 있다고 한다. 그 컨셉들은 아래와 같다.
마이크로 서비스의 컨셉(개념)
- 민첩한 소프트웨어 개발
- 서비스-지향 아키텍처
- API-우선 설계
- 지속적인 통합 / 지속적인 전달 (CI/CD)
서버리스란 ❔
AWS에서는 운영 복잡성을 줄여주는 서버리스를 이용한 마이크로 서비스 구현을 추천하고 있는데, 서버리스는 아래의 원칙을 따라야만 한다.
서버리스의 원칙
- 프로비저닝 하거나 관리할 인프라가 없다.
- 소비가 많아질 경우 자동으로 확장된다
- 사용한 만큼만 지불한다
- 가용성과 내결함성을 지닌다.
또한, 마이크로 서비스 구현 시 Twelve-Factor App의 디자인 패턴이 많이 활용되고 있다고 한다.
💡 (참고) Twelve-Factor app이란 ❔
최근 소프트웨어를 서비스 형태로 제공하는 게 일반화되면서, 웹앱 혹은 SaaS(Software As A Service)라고 부르게 되었다. Twelve-Factor app은 아래 특징을 가진 SaaS 앱을 만들기 위한 방법론이다.
- 설정 자동화를 위한 절차(declarative)를 체계화하여 새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용을 최소화한다.
- OS에 따라 달라지는 부분을 명확히 하고, 실행 환경 사이의 이식성을 극대화한다.
- 최근 등장한 클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리가 필요 없게 된다.
- 개발 환경과 운영 환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포가 가능하다.
툴, 아키텍처, 개발 방식을 크게 바꾸지 않고 확장(scale up) 할 수 있다.
AWS 서비스들을 이용한 마이크로 서비스 아키텍처 구현
기존 모놀리틱 애플리케이션과 다른 마이크로 서비스의 주요 개념은 기능 단위로, 그리고 수직으로 나누는 것이다.
이런 마이크로 서비스를 AWS의 서비스들을 이용하여 구현할 수 있는 방법을 소개한다.
✔ UI 구현
먼저, 프론트 쪽은 Amazon S3와, Amazon CloudFront로 구성된다(SPA 기준).
이렇게 구성될 경우 가장 가까운 엣지로케이션 또는 최적화된 연결을 가진 캐시 서버나 프록시 서버에서 클라이언트 소스를 받아올 수 있기 때문에 지연시간을 크게 줄일 수 있다.
✔ 비즈니스 로직 구현
API는 주로 마이크로 서비스의 현관문(?)이라고 불린다. 즉, API가 애플리케이션의 로직 뒤로 들어갈 수 있는 진입점이라는 것이다. 전형적으로 우리가 많이 아는 RESTful 웹서비스 API가 있다.
이런 백엔드의 API 역할을 구현할 수 있는 AWS의 서비스 중 마이크로 서비스에서 선호되는 방식은 두 가지가 있다.
- 서버리스 컴퓨팅을 제공하는 AWS Lambda 운영
- 컨테이너 관리 서비스인 AWS Fargate를 이용한 Amazon ECS(Docker), Amazon EKS(쿠버네티스) 운영. 도커 이미지는 Amazon ECR에 저장 가능하며 이 경우 별도의 레지스트리를 구성할 필요가 없다
그리고 이러한 마이크로 서비스 간의 연결은 AWS PrivateLink를 활용하여 연결할 수 있다.
✔ 데이터 저장소
데이터 저장소는 마이크로 서비스에 필요한 데이터를 유지하는 데 사용된다.
- 세션 데이터를 저장하는 저장하는 인메모리 캐시로는 Memcached or Redis가 유명한데, Amazon ElastiCache가 그 기술을 제공한다.
- 관계형 데이터베이스는 구조 데이터를 저장하는데 아직도 인기가 있다. AWS에서는 Amazon Aurora를 비롯해 여섯 개의 데이터베이스 엔진을 제공하며, Amazon RDS를 이용해 관리할 수 있다. 그러나 무한한 확장이 불가능하고 많은 쿼리를 지원하기 위한 기술을 적용하는 것이 어렵고 시간이 많이 걸릴 수 있다.
- NoSQL 데이터베이스는 관계형 데이터베이스보다 확장성, 성능, 가용성이 더 뛰어나다 가장 중요한 요소는 엄격한 스키마를 사용하지 않아도 된다는 것이다(데이터는 파티션으로 나누어져 있고 파티션 키를 통해 검색된다). 마이크로 서비스는 전형적으로 NoSQL에 더 적합한 단순한 데이터 모델을 가지고 있다. NoSQL 데이터베이스로는 Amazon DynamoDB를 이용할 수 있다. DynamoDB는 한 자리 밀리 초 성능을 제공하지만 마이크로 초 단위의 응답 시간이 필요한 특정 사용 사례가 있다. DynamoDB Accelerator(DAX)는 데이터 액세스를 위한 캐싱 기능을 제공한다.
운영 복잡성 줄이기
완전한 ⭐서버리스 아키텍처⭐를 사용함으로써 마이크로 서비스를 실행, 유지, 모니터링하는 데 필요한 운영 노력을 더욱 줄일 수 있다.
✔ API 구현
Amazon API Gateway를 사용하면 RESTful API를 생성하고 관리하는데 필요한 여러 과제들과 운영 복잡성을 줄여준다. API Gateway는 어떠한 웹 애플리케이션(Amazon EC, Amazon ECS, AWS Lambda, 온프레미스 환경)이든 현관문 역할을 제공한다.
✔ 서버리스 마이크로 서비스 구현
"서버가 없는 서버보다 관리하기 쉬운 서버가 없다"
서버를 제거하는 것은 운영상의 복잡성을 제거하는 좋은 방법이다.
서버리스 마이크로 서비스는 규모와 고가용성을 위해 설계해야 하는 아키텍처 부담을 없애고, 마이크로 서비스의 기반 인프라를 실행하고 모니터링해야 하는 운영 노력을 없앤다.
- 마이크로 서비스에 AWS Lambda 또는 AWS Fargate를 이용할 수 있다.
- 데이터 저장소로는 Amazon DynamoDB와 Amazon Aurora의 온디맨드, 오토 스케일링 구성인 Amazon Aurora Serverless를 사용할 수 있다.
✔ 람다 기반 애플리케이션 배포
AWS CloudFormation을 이용하여 서버리스 애플리케이션을 정의, 배포, 구성할 수 있다.
- AWS SAM(Severless Application Model)은 서버리스 애플리케이션을 정의하는 편리한 방법 중 하나이며, 간단한 Syntax를 정의함으로써 서버리스 리소스를 표현할 수 있다. AWS SAM은 CloudFormation에 의해 기본적으로 제공된다.
- SAM Local은 서버리스 애플리케이션을 람다 런타임에 올리기 전에 로컬에서 개발, 테스트 및 분석을 할 수 있게 해주는 AWS CLI 툴이다. AWS 런타임 환경을 시뮬레이션할 수 있는 로컬 테스트 환경을 제공한다.
분산 시스템 컴포넌트
✔ 서비스 검색
마이크로 서비스 아키텍처에서 각각의 서비스를 서로 발견하고 상호작용하는 것은 중요한 과제 중 하나다. 마이크로 서비스 아키텍처의 분산된 특성들은 서비스들 간의 커뮤니케이션을 힘들게 할 뿐만 아니라 그 시스템들의 건강 체크와 새로운 애플리케이션이 사용 가능하게 되었을 대 알리는 것 등 다른 과제들이 있다. 또한 애플리케이션에서 사용할 수 있는 구성 데이터와 같은 메타 저장소 정보를 저장하는 방법과 위치를 결정해야 한다.
DNS-기반 서비스 검색
Amazon ECS에는 컨테이너화 된 서비스가 서로 쉽게 검색하고 연결할 수 있는 통합 서비스 검색 기능이 포함되어 있다. 아마존 ECS는 Route 53 Auto Naming API를 사용하여 서비스 이름 레지스트리를 생성하고 관리한다. 이름은 자동으로 DNS 레코드 집합에 매핑되므로, 코드의 이름별로 서비스를 참조하고 DNS 쿼리를 작성하여 런타임에 서비스 끝점으로 이름이 확인되도록 할 수 있다.
Kubernetes에서 관리하는 서비스에 대해 통합 서비스 검색을 활용할 수도 있다. 이러한 통합을 가능하게 하기 위해 AWS는 외부 DNS 프로젝트인 Kubernetes 인큐베이터 프로젝트에 기여했다.
AWS Cloud Map은 IP, URL 및 ARN과 같은 리소스에 대한 서비스 레지스트리를 제공하고, API 기반 서비스 발견 메커니즘을 제공함으로써 Route 53 Auto Naming API의 기능을 확장한다.
타사 소프트웨어(Third-party software)
서비스 검색을 구현하기 위한 다른 접근방식은 HashiCorp Consumer, etcd 또는 Netflix Eureka와 같은 타사 소프트웨어를 사용하는 것이다. 세 가지 예 모두 분산되고 신뢰할 수 있는 키-밸류 스토어들이다. AWS Quick Start는 유연하고 확장 가능한 AWS Cloud 환경을 설정하고 HashiCorp Consumer를 자동으로 원하는 구성으로 시작한다.
서비스 메시
고급 마이크로 서비스 아키텍처에서 실제 응용 프로그램은 수백 또는 수천 개의 서비스로 구성될 수 있다. 애플리케이션의 가장 복잡한 부분은 실제 서비스 자체가 아니라 해당 서비스 간의 통신이다.
서비스 메쉬는 서비스 간 통신을 처리하기 위한 추가 계층으로, 마이크로 서비스 아키텍처에서 트래픽을 모니터링하고 제어하는 역할을 한다. 이를 통해 서비스 검색과 같은 작업을 이 계층에서 완전히 처리할 수 있다. 서비스 메쉬는 투명하다. 이는 애플리케이션 개발자가 이 추가 계층을 인식할 필요가 없으며 기존 애플리케이션 코드를 변경할 필요가 없다는 것을 의미한다.
AWS App Mesh는 여러 유형의 컴퓨팅 인프라에서 서비스가 서로 쉽게 통신할 수 있도록 네트워킹을 제공하는 서비스 메쉬이다. AWS Fargate, Amazon ECS, Amazon EKS, 자체 관리하는 Kubernetes 서비스와 함께 AWS 앱 메쉬를 사용할 수 있다. 앱 메쉬는 코드 변경 없이 단일 애플리케이션으로 클러스터, orchestration 시스템 또는 VPC를 통해 실행되는 마이크로 서비스에 대한 통신을 모니터링하고 제어할 수 있다.
✔ 분산 데이터 관리
분산 데이터 관리는 새로운 과제를 제기합니다. CAP 이론의 결론에 따르면, 36 개의 분산 마이크로 서비스 아키텍처는 본질적으로 성능의 일관성을 절충하며 최종 일관성을 수용해야 한다.
분산형 시스템에서 비즈니스 트랜잭션은 여러 마이크로 서비스에 걸쳐 있을 수 있다. 그들은 단일 ACID 트렌잭션을 활용할 수 없기 때문에, 당신은 부분적인 실행으로 끝날 수 있다. 이를 위해 분산된 Saga pattern이 보편적으로 사용된다. 사업 거래 실패의 경우, 사가는 일련의 보상 거래를 조정하여 선행 거래에 의해 이루어진 변경 사항을 되돌린다. AWS Step Functions은 Saga 실행 코디네이터를 쉽게 구현할 수 있도록 한다.
이벤트 소싱
이벤트 소싱은 유용한 패턴으로 입증되었다. 이벤트 소싱의 핵심 아이디어는 모든 애플리케이션 변경을 이벤트 기록으로 표시하고 유지하는 것이다. 애플리케이션 상태를 유지하는 대신 데이터가 이벤트 스트림으로 저장된다. 데이터베이스 트랜잭션 기록과 버전 제어 시스템은 이벤트 소싱의 잘 알려진 두 가지 예다. 이벤트 소싱에는 몇 가지 이점이 있다:
- 상태는 어떤 시점에서도 결정되고 재구성될 수 있다.
- 자연스럽게 지속적인 감사 추적을 만들어 내고 디버깅도 용이하게 한다.
Amazon Kinesis Data Streams는 중앙 이벤트 저장소의 주요 구성 요소로 사용되며, 애플리케이션 변경 사항을 이벤트로 캡처하여 Amazon S3에서 유지한다. Amazon S3는 모든 마이크로 서비스에 걸쳐 모든 이벤트를 지속해서 저장하며 디버깅, 애플리케이션 상태 복구 또는 애플리케이션 변경 감사와 관련하여 단일 진실의 원천이다.
✔ 비동기식 통신 및 경량 메시징
동일한 애플리케이션이 분리된 마이크로 서비스를 사용하여 구현되는 경우, 애플리케이션의 다른 부분들 간의 통신은 네트워크 통신을 사용하여 구현되어야 한다.
REST 기반 통신
- API Gateway를 사용하면 애플리케이션이 Amazon EC2 및 Amazon ECS에서 실행되는 워크로드, Lambda에서 실행되는 코드 또는 웹 애플리케이션과 같은 백엔드 서비스에서 데이터, 비즈니스 로직 또는 기능에 액세스 하는 "프론트 도어" 역할을 하는 API를 만들 수 있다.
비동기 메시징 및 이벤트 전달
마이크로 서비스 간 통신을 구현하기 위한 추가적인 패턴은 메시지 전달이다. 서비스는 대기열을 통해 메시지를 교환하여 통신한다. 이러한 통신 방식의 한 가지 큰 이점은 서비스 검색이 필요하지 않고 서비스가 느슨하게 결합되어 있다는 것이다.
- Amazon SNS는 푸시 메커니즘을 통해 여러 가입자에게 메시지를 보낼 수 있도록 한다. Amazon SNS와 Amazon SQS를 함께 사용하면 여러 소비자에게 하나의 메시지를 전달할 수 있다.
- 기존 구현 소프트웨어가 JMS, NMS, AMQP, STOMP, MQTT 및 WebSocket을 포함한 메시징을 위해 개방형 표준 API 및 프로토콜을 사용하는 경우 Amazon MQ를 사용할 수 있다.
오케스트레이션 및 상태 관리
마이크로 서비스의 분산된 특성은 여러 마이크로 서비스가 관련되었을 때 워크플로우를 조정하는 것을 어렵게 한다. 개발자는 자신의 서비스에 직접 조정 코드를 추가하려는 유혹을 받을 수 있다. 이것은 더 긴밀한 결합을 도입하고 개별 서비스를 신속하게 대체하는 것을 더 어렵게 만들기 때문에 피해야 한다.
- Step Functions를 사용하여 각 구성요소에서 개별 함수를 수행하는 응용프로그램을 작성할 수 있습니다.
- Step Functions는 AWS 서버리스 플랫폼의 일부로서 Amazon EC2, Amazon ECS와 같은 계산 리소스에 기반한 애플리케이션뿐만 아니라 Amazon SageMaker, AWS Glue과 같은 부가 서비스의 Lambda 함수의 오케스트레이션을 지원한다.
✔ 분산 모니터링
분산 모니터링 마이크로 서비스 아키텍처는 모니터링해야 하는 많은 분산 부품으로 구성됩니다. Amazon CloudWatch를 사용하여 메트릭을 수집하고 추적하고 로그 파일을 중앙 집중화 및 모니터링하고 알람을 설정하고 AWS 환경의 변화에 자동으로 반응할 수 있습니다.
모니터링
- CloudWatch를 사용하여 리소스 활용률, 애플리케이션 성능 및 운영 상태에 대한 시스템 전반의 가시성을 확보할 수 있다. 마이크로 서비스 아키텍처에서는 개발자가 각 서비스에 대해 수집해야 할 메트릭스를 결정할 수 있기 때문에 CloudWatch를 사용하여 사용자 지정 메트릭을 모니터링할 수 있는 기능이 추가 이점이다.
- Amazon EKS의 또 다른 인기 있는 옵션은 Prometeus를 사용하는 것이다. Prometeus는 수집된 메트릭스를 시각화하기 위해 Grafana와 함께 종종 사용되는 오픈 소스 모니터링 및 알림 툴킷이다.
로그 중앙 집중화
대부분의 AWS 서비스는 기본적으로 로그 파일을 중앙 집중화한다.
- AWS의 로그 파일의 주 목적지는 Amazon S3와 Amazon CloudWatch Logs이다.
- EC2 인스턴스에서 실행 중인 애플리케이션의 경우, 로그 파일을 CloudWatch Logs로 전송할 수 있는 데몬을 사용할 수 있다.
- Lambda 함수는 기본적으로 CloudWatch Logs로 로그 출력을 전송하고
- Amazon ECS는 CloudWatch Logs로 컨테이너 로그를 중앙 집중화할 수 있는 차폭 로그 드라이버를 지원하며,
- Amazon EKS의 경우 클러스터의 개별 인스턴스에서 중앙 집중식 Logging CloudWatch Logs로 로그를 전달하는 UlicD를 실행해야 한다.
- Amazon Elasticsearch Service (Amazon ES), Kibana 등의 도구를 이용해 이 로그들을 검색하고 분석할 수 있게 된다.
- Amazon Athena을 사용하여 Amazon S3의 중앙 집중식 로그 파일에 대해 임시 쿼리를 실행할 수 있다.
분산 추적
많은 경우, 일련의 마이크로 서비스가 요청을 처리하기 위해 함께 작동한다. 콜 체인의 서비스 중 하나에서 오류가 발생하는 수십 개의 마이크로 서비스로 구성된 복잡한 시스템을 상상해보십시오. 모든 마이크로 서비스가 제대로 로그를 작성하고 중앙 시스템에서 로그가 통합되어 있더라도 모든 관련 로그 메시지를 찾기가 어려울 수 있습니다.
- AWS X-Ray의 중심 개념은 상관관계 ID의 사용인데, 이것은 특정 이벤트 체인과 관련된 모든 요청과 메시지에 첨부된 고유한 식별자이다. AWS X-Ray는 Amazon EC2, Amazon ECS, Lambda, AWS Elastic Beanstalk과 함께 작동한다.
AWS의 로그 분석 옵션
로그 데이터를 검색, 분석 및 시각화하는 것은 분산 시스템을 이해하는 중요한 측면이다.
- Amazon CloudWatch Logs Insights는 로그를 즉시 탐색, 분석 및 시각화할 수 있는 훌륭한 서비스이다. 이를 통해 운영 문제를 해결할 수 있다.
- 로그 파일을 분석하는 또 다른 옵션은 Kibana와 함께 Amazon ES를 사용하는 것이다. Amazon ES는 전체 텍스트 검색, 구조적 검색, 분석 및이 세 가지를 모두 조합하여 사용할 수 있고, Kibana는 Amazon ES 용 오픈 소스 데이터 시각화 플러그인으로 완벽하게 통합된다.
- 로그 파일을 분석하는 또 다른 옵션은 Amazon RedShift를 Amazon QuickSight와 함께 사용하는 것이다. 로그 항목은 CloudWatch Logs 및 Kinesis Data Firehose를 사용하여 다른 소스에서 Amazon Redshift로 스트리밍 된다. Amazon QuickSight는 분석, 보고 및 시각화를 위해 Amazon Redshift에 저장된 데이터를 사용한다.
✔ 대화
모놀리틱 애플리케이션을 작은 마이크로 서비스로 세분화함으로써, 마이크로 서비스는 서로 대화해야 하기 때문에 통신 오버헤드가 증가한다.
프로토콜
마이크로 서비스의 경우 HTTP와 같은 간단한 프로토콜을 사용하는 것이 일반적이다. 서비스로 교환되는 메시지는 JSON 또는 YAML과 같은 인간이 읽을 수 있는 형식이나 Avro 또는 Protocol Buffers와 같은 효율적인 이진 형식과 같은 다양한 방식으로 인코딩 될 수 있다.
캐싱
캐시는 마이크로 서비스 아키텍처의 지연 시간과 잡담을 줄이는 좋은 방법이다. AWS에서 실행되는 많은 마이크로 서비스 애플리케이션은 Amazon ElastiCache를 사용하여 로컬로 결과를 캐싱함으로써 다른 마이크로 서비스에 대한 통화량을 줄인다. API Gateway는 백엔드 서버의 로드를 줄이기 위해 내장된 캐싱 레이어를 제공한다.
✔ 감사
수백 개의 분산된 서비스를 잠재적으로 가질 수 있는 마이크로 서비스 아키텍처에서 다루어야 할 또 다른 과제는 각 서비스에 대한 사용자 조치의 가시성을 보장하고 조직 수준에서 모든 서비스에 대한 전체적인 시야를 잘 확보할 수 있는 것이다.
감사 추적
AWS CloudTrail는 AWS 클라우드에서 이루어진 모든 API 호출을 실시간으로 CloudWatch Logs 또는 몇 분 내에 Amazon S3에 기록 및 전송할 수 있으므로 마이크로 서비스의 변경 사항을 추적하는 데 유용하다.
이벤트 및 실시간 액션
CloudTrail과 CloudWatch Events를 통합하면 모든 AWS 서비스에서 모든 변경 API 호출에 대한 이벤트를 생성할 수 있습니다.
자원 인벤토리 및 변경 관리
AWS Config 규칙은 회사가 정책 위반을 자동으로 감지, 추적 및 경고하기 위해 특정 규칙을 사용하여 보안 정책을 정의할 수 있도록 허용한다.
