기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 의 간단한 마이크로서비스 아키텍처 AWS
일반적인 모놀리식 애플리케이션은 프레젠테이션 계층, 애플리케이션 계층, 데이터 계층 등 다양한 계층으로 구성됩니다. 반면 마이크로서비스 아키텍처는 기술 계층이 아닌 특정 도메인에 따라 기능을 응집력 있는 *수직*으로 구분합니다. 그림 1은 일반적인 마이크로서비스 애플리케이션의 참조 아키텍처를 보여줍니다 AWS.
![\[의 일반적인 마이크로서비스 애플리케이션을 보여주는 다이어그램 AWS\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/microservices-on-aws/images/typical-microservices-application.png)
# 사용자 인터페이스
최신 웹 애플리케이션은 JavaScript 프레임워크를 사용하여 백엔드 APIs. 이러한 APIs는 일반적으로 REST(Representational State Transfer) 또는 RESTful APIs 또는 GraphQL APIs. 정적 웹 콘텐츠는 Amazon Simple Storage Service([Amazon S3](https://aws.amazon.com/s3/)) 및 [Amazon CloudFront](https://aws.amazon.com/cloudfront/)를 사용하여 제공할 수 있습니다.
# 마이크로서비스
APIs는 애플리케이션 로직의 진입점이므로 마이크로서비스의 *정문*으로 간주됩니다. 일반적으로 RESTful 웹 서비스 API 또는 GraphQL APIs 사용됩니다. 이러한 APIs 클라이언트 호출을 관리하고 처리하여 트래픽 관리, 요청 필터링, 라우팅, 캐싱, 인증 및 권한 부여와 같은 기능을 처리합니다.
## 마이크로서비스 구현
AWS 는 컨테이너 오케스트레이션 엔진의 선택 항목으로 Amazon ECS 및 Amazon EKS와 호스팅 옵션으로 AWS Fargate EC2를 포함한 마이크로서비스를 개발하기 위한 구성 요소를 제공합니다. AWS Lambda 는 마이크로서비스를 구축하는 또 다른 서버리스 방법입니다 AWS. 이러한 호스팅 옵션 중에서 선택하는 것은 기본 인프라를 관리하기 위한 고객의 요구 사항에 따라 달라집니다.
AWS Lambda 를 사용하면 코드를 업로드하여 고가용성으로 실행을 자동으로 조정하고 관리할 수 있습니다. 따라서 인프라 관리가 필요하지 않으므로 빠르게 이동하고 비즈니스 로직에 집중할 수 있습니다. Lambda는 [여러 프로그래밍 언어를](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html) 지원하며 다른 AWS 서비스에서 트리거하거나 웹 또는 모바일 애플리케이션에서 직접 호출할 수 있습니다.
컨테이너 기반 애플리케이션은 이식성, 생산성 및 효율성으로 인해 인기를 얻었습니다. AWS 는 컨테이너를 빌드, 배포 및 관리하기 위한 여러 서비스를 제공합니다.
+ [App2Container](https://aws.amazon.com/app2container/)는 Java 및 .NET 웹 애플리케이션을 컨테이너 형식으로 마이그레이션하고 현대화하기 위한 명령줄 도구입니다. AWS A2C는 베어 메탈, 가상 머신, Amazon Elastic Compute Cloud(EC2) 인스턴스 또는 클라우드에서 실행되는 애플리케이션의 인벤토리를 분석하고 빌드합니다.
+ Amazon Elastic Container Service([Amazon ECS](https://aws.amazon.com/ecs/)) 및 Amazon Elastic Kubernetes Service([Amazon EKS](https://aws.amazon.com/eks/))는 컨테이너 인프라를 관리하므로 컨테이너화된 애플리케이션을 더 쉽게 시작하고 유지 관리할 수 있습니다.
+ Amazon EKS는 AWS 클라우드 및 온프레미스 데이터 센터([Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/))에서 Kubernetes를 실행하는 관리형 Kubernetes 서비스입니다. 이렇게 하면 지연 시간이 짧은 로컬 데이터 처리, 높은 데이터 전송 비용 또는 데이터 레지던시 요구 사항을 위해 클라우드 서비스가 온프레미스 환경으로 확장됩니다("[Amazon EKS Anywhere를 사용하여 하이브리드 컨테이너 워크로드 실행](https://d1.awsstatic.com/kubernetes-pmm/eks-a/getting-started/AWS_Whitepaper_Running_Hybrid_Container_Workloads_with_Amazon_EKS_Anywhere.pdf)" 백서 참조). Kubernetes 커뮤니티의 모든 기존 플러그인 및 도구를 EKS와 함께 사용할 수 있습니다.
+ Amazon Elastic Container Service(Amazon ECS)는 컨테이너화된 애플리케이션의 배포, 관리 및 규모 조정을 간소화하는 완전 관리형 컨테이너 오케스트레이션 서비스입니다. 고객은 간소화 및 AWS 서비스와의 심층 통합을 위해 ECS를 선택합니다.
자세한 내용은 Amazon [ECS vs Amazon EKS: AWS 컨테이너 서비스 이해 블로그를 참조하세요](https://aws.amazon.com/blogs/containers/amazon-ecs-vs-amazon-eks-making-sense-of-aws-container-services/).
+ [AWS App Runner](https://aws.amazon.com/apprunner/)는 사전 인프라 또는 컨테이너 경험 없이 컨테이너화된 웹 애플리케이션 및 API 서비스를 빌드, 배포 및 실행할 수 있는 완전 관리형 컨테이너 애플리케이션 서비스입니다.
+ [AWS Fargate](https://aws.amazon.com/fargate/)서버리스 컴퓨팅 엔진인는 Amazon ECS 및 Amazon EKS와 함께 작동하여 컨테이너 애플리케이션의 컴퓨팅 리소스를 자동으로 관리합니다.
+ [Amazon ECR](https://aws.amazon.com/ecr/)은 고성능 호스팅을 제공하는 완전 관리형 컨테이너 레지스트리이므로 애플리케이션 이미지와 아티팩트를 어디서나 안정적으로 배포할 수 있습니다.
# 지속적 통합 및 지속적 배포(CI/CD)
지속적 통합 및 지속적 전달(CI/CD)은 신속한 소프트웨어 변경을 위한 DevOps 이니셔티브의 중요한 부분입니다.는 마이크로서비스용 CI/CD를 구현하기 위한 서비스를 AWS 제공하지만 자세한 설명은이 문서의 범위를 벗어납니다. 자세한 내용은 지속적인 [통합 및 지속적 전달 연습 AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html) 백서를 참조하세요.
# 프라이빗 네트워킹
AWS PrivateLink 는 Virtual Private Cloud(VPC)와 지원되는 AWS 서비스 간의 프라이빗 연결을 허용하여 마이크로서비스의 보안을 강화하는 기술입니다. 마이크로서비스 트래픽을 격리하고 보호하여 퍼블릭 인터넷을 통과하지 않도록 합니다. 이는 PCI 또는 HIPAA와 같은 규정을 준수하는 데 특히 유용합니다.
# 데이터 스토어
데이터 스토어는 마이크로서비스에 필요한 데이터를 유지하는 데 사용됩니다. 세션 데이터의 인기 저장소는 Memcached 또는 Redis와 같은 인 메모리 캐시입니다.는 관리형 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) 서비스의 일부로 두 기술을 모두 AWS 제공합니다.
애플리케이션 서버와 데이터베이스 사이에 캐시를 넣는 것은 데이터베이스의 읽기 부하를 줄이는 일반적인 메커니즘으로, 더 많은 쓰기를 지원하는 데 리소스를 사용할 수 있습니다. 캐시는 지연 시간도 개선할 수 있습니다.
관계형 데이터베이스는 여전히 구조화된 데이터 및 비즈니스 객체를 저장하는 데 매우 인기가 있습니다.는 Amazon [Amazon Relational Database Service](https://aws.amazon.com/rds/) (Microsoft SQL Server, Oracle, MySQL, MariaDB, PostgreSQL 및 [Amazon Aurora](https://aws.amazon.com/rds/aurora/))을 관리형 서비스로 AWS 제공합니다.
그러나 관계형 데이터베이스는 무한 규모로 설계되지 않았으므로 많은 수의 쿼리를 지원하는 기술을 적용하는 것이 어렵고 시간이 많이 걸릴 수 있습니다.
NoSQL 데이터베이스는 관계형 데이터베이스의 일관성보다 확장성, 성능 및 가용성을 높이도록 설계되었습니다. NoSQL 데이터베이스의 중요한 요소 중 하나는 일반적으로 엄격한 스키마를 적용하지 않는다는 것입니다. 데이터는 수평적으로 확장할 수 있는 파티션에 분산되며 파티션 키를 사용하여 검색됩니다.
개별 마이크로서비스는 한 가지를 잘 수행하도록 설계되었으므로 일반적으로 NoSQL 지속성에 적합할 수 있는 간소화된 데이터 모델을 갖추고 있습니다. NoSQL 데이터베이스의 액세스 패턴은 관계형 데이터베이스와 다르다는 점을 이해하는 것이 중요합니다. 예를 들어 테이블을 조인할 수 없습니다. 필요한 경우 애플리케이션에서 로직을 구현해야 합니다. [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)를 사용하여 원하는 양의 데이터를 저장 및 검색하고 모든 수준의 요청 트래픽을 처리할 수 있는 데이터베이스 테이블을 생성할 수 있습니다. DynamoDB는 한 자릿수 밀리초의 성능을 제공하지만 응답 시간이 마이크로초 단위로 필요한 특정 사용 사례가 있습니다. [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/) (DAX)는 데이터 액세스를 위한 캐싱 기능을 제공합니다.
또한 DynamoDB는 실제 트래픽에 따라 처리량 용량을 동적으로 조정하는 자동 조정 기능을 제공합니다. 그러나 애플리케이션에서 짧은 기간의 대규모 활동 급증으로 인해 용량 계획이 어렵거나 불가능한 경우가 있습니다. 이러한 상황에서 DynamoDB는 pay-per-request 요금을 제공하는 온디맨드 옵션을 제공합니다. DynamoDB 온디맨드는 용량 계획 없이 초당 수천 개의 요청을 즉시 처리할 수 있습니다.
자세한 내용은 [분산 데이터 관리](distributed-data-management.md) 및 [데이터베이스를 선택하는 방법을 참조하세요](https://aws.amazon.com/startups/learn/maximizing-performance-with-aws-databases).
# 작업 간소화
마이크로서비스를 실행, 유지 관리 및 모니터링하는 데 필요한 운영 노력을 더욱 간소화하기 위해 완전한 서버리스 아키텍처를 사용할 수 있습니다.
## Lambda 기반 애플리케이션 배포
`zip` 파일 아카이브를 업로드하거나 유효한 Amazon ECR 이미지 URI를 사용하여 콘솔 UI를 통해 컨테이너 이미지를 생성하고 업로드하여 Lambda 코드를 배포할 수 있습니다. 그러나 Lambda 함수가 복잡해져 계층, 종속성 및 권한이 있는 경우 코드 변경 시 UI를 통한 업로드가 불안정해질 수 있습니다.
AWS CloudFormation 및 AWS Serverless Application Model ([AWS SAM](https://github.com/awslabs/serverless-application-model)) AWS Cloud Development Kit (AWS CDK)또는 Terraform을 사용하면 서버리스 애플리케이션을 정의하는 프로세스가 간소화됩니다. CloudFormation에서 기본적으로 지원하는 AWS SAM은 서버리스 리소스를 지정하기 위한 간소화된 구문을 제공합니다. AWS Lambda 계층은 여러 Lambda 함수에서 공유 라이브러리를 관리하고, 함수 공간을 최소화하고, 테넌트 인식 라이브러리를 중앙 집중화하고, 개발자 경험을 개선하는 데 도움이 됩니다. Java용 Lambda SnapStart는 지연 시간에 민감한 애플리케이션의 시작 성능을 향상시킵니다.
배포하려면 CloudFormation 템플릿에서 리소스 및 권한 정책을 지정하고, 배포 아티팩트를 패키징하고, 템플릿을 배포합니다. AWS CLI 도구인 SAM Local은 Lambda에 업로드하기 전에 서버리스 애플리케이션의 로컬 개발, 테스트 및 분석을 허용합니다.
AWS Cloud9 IDE AWS CodeBuild, AWS CodeDeploy등의 AWS CodePipeline 도구와 통합하면 SAM 기반 애플리케이션의 작성, 테스트, 디버깅 및 배포가 간소화됩니다.
다음 다이어그램은 CloudFormation 및 AWS CI/CD 도구를 사용하여 AWS Serverless Application Model 리소스를 배포하는 방법을 보여줍니다.
![\[AWS Serverless Application Model (AWS SAM)를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/microservices-on-aws/images/aws-sam.png)
## 다중 테넌시 복잡성 추상화
SaaS 플랫폼과 같은 다중 테넌트 환경에서는 개발자가 기능 개발에 집중할 수 있도록 다중 테넌시와 관련된 복잡성을 간소화하는 것이 중요합니다. 이는 교차 커팅 문제를 해결하기 위한 공유 라이브러리를 제공하는 [AWS Lambda Layers](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)와 같은 도구를 사용하여 달성할 수 있습니다.이 접근 방식의 근거는 공유 라이브러리와 도구를 올바르게 사용하면 테넌트 컨텍스트를 효율적으로 관리하는 것입니다.
그러나 이로 인해 발생할 수 있는 복잡성과 위험으로 인해 비즈니스 로직을 캡슐화하는 것으로 확장해서는 안 됩니다. 공유 라이브러리의 근본적인 문제는 업데이트를 둘러싼 복잡성이 증가하여 표준 코드 복제에 비해 관리하기가 더 어려워진다는 것입니다. 따라서 가장 효과적인 추상화를 위해 공유 라이브러리 사용과 중복 간의 균형을 맞추는 것이 중요합니다.
## API 관리
APIs 관리는 특히 여러 버전, 개발 주기의 단계, 권한 부여 및 제한 및 캐싱과 같은 기타 기능을 고려할 때 시간이 많이 걸릴 수 있습니다. [API Gateway](https://aws.amazon.com/api-gateway/) 외에도 일부 고객은 API 관리를 위해 ALB(Application Load Balancer) 또는 NLB(Network Load Balancer)를 사용합니다. Amazon API Gateway는 RESTful APIs. 이를 통해 프로그래밍 방식으로 APIs를 생성할 수 있고, 백엔드 서비스의 데이터, 비즈니스 로직 또는 기능, 권한 부여 및 액세스 제어, 속도 제한, 캐싱, 모니터링 및 트래픽 관리에 액세스할 수 있는 “정문” 역할을 하며, 서버를 관리하지 않고도 APIs.
그림 3은 API Gateway가 API 호출을 처리하고 다른 구성 요소와 상호 작용하는 방법을 보여줍니다. 모바일 디바이스, 웹 사이트 또는 기타 백엔드 서비스의 요청은 지연 시간을 줄이고 최적의 사용자 경험을 제공하기 위해 가장 가까운 CloudFront PoP(Point of Presence) 로 라우팅됩니다.
![\[API Gateway 호출 흐름을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/microservices-on-aws/images/api-gateway-call-flow.png)