[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는Architecting for the Cloud(AWS Best Practices)(October 2018, 영문) 내용에 기반하여 작성 되었습니다.
본 문서는 정보 제공 목적으로만 제공됩니다. 이 문서는 이 문서의 발행일 현재 AWS의 현재 제품 및 관행을 나타내며 예고 없이 변경될 수 있습니다. 고객은 본 문서의 정보 및 AWS의 제품 또는 서비스의 사용에 대한 자체적인 독립적 평가를 수행할 책임이 있으며, 각 정보는 명시적이든 묵시적이든 어떠한 종류의 보증도 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 계열사, 공급업체 또는 면허소지자의 보증, 진술, 계약, 조건 또는 보증서를 작성하지 않습니다. 고객에 대한 AWS의 책임과 책임은 AWS 협약에 의해 관리되며, 이 문서는 AWS와 고객 간의 어떠한 합의에도 속하지 않으며 수정하지도 않습니다.
© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
개요
이 백서는 AWS(Amazon Web Services)에 배포할 솔루션을 구축하고 있는 솔루션 설계자 및 개발자를 대상으로 작성되었습니다. 이 솔루션은 기술 설계 패턴 및 클라우드 컴퓨팅 환경에서 어떻게 적용되는지에 대한 아키텍처 지침과 조언을 제공합니다. 이 소개는 AWS에서 솔루션을 설계할 때 주요 개념과 차이점을 제공합니다. 여기에는 탄력성 및 인프라 자동화 등 클라우드 컴퓨팅의 동적 특성과 관련된 특성을 활용하는 방법에 대한 토론이 포함되어 있습니다. 이러한 패턴은 AWS Well-Architected Framework 에 자세히 설명된 대로 선택 사항, 운영 상태 및 구현 상태를 보다 자세히 검토할 수 있는 컨텍스트를 제공할 수 있습니다.
소개
애플리케이션을 AWS로 마이그레이션하는 것은 상당한 변경 사항(Lift and Shift라고 하는 접근 방식)이 없어도 안전하고 비용 효율적인 인프라의 이점을 조직에 제공합니다. 그러나 클라우드 컴퓨팅에서 가능한 유연성과 민첩성을 최대한 활용하려면 엔지니어가 AWS 기능을 활용하도록 아키텍처를 발전 시켜야 합니다.
새로운 애플리케이션의 경우 클라우드별 IT 아키텍처 패턴이 효율성과 확장성을 높이는 데 도움이 될 수 있습니다. 이러한 새로운 아키텍처는 인터넷 규모 데이터의 실시간 분석에서 수천 개의 IoT(Internet of Things) 또는 모바일 장치에서 발생하는 예측 불가능한 트래픽이 있는 애플리케이션에 이르기까지 모든 것을 지원할 수 있습니다.
현재 사내 환경에서 실행되는 애플리케이션을 AWS에서 실행할 수 있도록 재설계하거나 클라우드 네이티브 애플리케이션을 설계하는 경우 기존 환경과 클라우드 컴퓨팅 환경의 차이를 고려해야 합니다. 여기에는 아키텍처 선택, 확장성, 리소스 유형, 자동화 및 유연한 구성 요소, 서비스 및 데이터베이스가 포함됩니다. AWS를 처음 접하는 경우 AWS 정보 페이지에서 정보를 검토하여 AWS 서비스에 대한 기본 지식을 얻는 것이 좋습니다.
기존 컴퓨팅 환경과 클라우드 컴퓨팅 환경의 차이점
클라우드 컴퓨팅은 유연하고 글로벌하며 확장 가능한 용량, 관리 서비스, 기본 제공 보안, 비용 최적화 옵션 및 다양한 운영 모델을 포함하여 여러 가지면에서 전통적인 온-프레미스 환경과 다릅니다.
프로비저닝 된 리소스인 IT 자산
기존 컴퓨팅 환경에서는 이론상 최대 피크의 추정치를 기반으로 용량을 프로비저닝 합니다. 이로 인해 값 비싼 리소스가 유휴 상태이거나 용량이 부족한 경우가 발생할 수 있습니다. 클라우드 컴퓨팅을 사용하면 필요한만큼만 용량에 액세스 할 수 있고 실제 수요에 맞게 동적으로 확장 할 수 있으며 사용하는 비용만 지불하면 됩니다.
AWS에서는 서버, 데이터베이스, 스토리지 및 상위 수준의 애플리케이션 구성 요소를 몇 초 내에 인스턴스화 할 수 있습니다. 고정 및 유한 IT 인프라의 유연성과 제약 없는 이러한 리소스를 임시 리소스로 취급 할 수 있습니다. 변경 관리, 테스트, 안정성 및 용량 계획에 접근하는 방식이 재설정됩니다. 이러한 접근 방식의 변화는 프로세스가 빠르게 실패하고 빠르게 반복되는 기능을 도입함으로써 테스트를 촉진합니다.
글로벌, 가용 및 확장 가능한 용량
AWS의 글로벌 인프라를 사용하여 요구 사항을 가장 잘 충족하는 AWS 리전 (예 : 최종 사용자와의 근접성, 규정 준수, 데이터 상주 제약 조건 및 비용)에 애플리케이션을 배포 할 수 있습니다. 글로벌 애플리케이션의 경우 Amazon CloudFront CDN (Content Delivery Network)을 사용하여 전 세계 최종 사용자의 대기 시간을 줄일 수 있습니다. 또한 여러 데이터 센터에서 프로덕션 응용 프로그램 및 데이터베이스를 훨씬 쉽게 운영하여 고 가용성 및 내결함성을 달성 할 수 있습니다. AWS의 글로벌 인프라와 필요에 따라 용량을 프로비저닝하는 기능을 통해 애플리케이션과 서비스의 폭이 넓어짐에 따라 인프라에 대해 다르게 생각할 수 있습니다.
고급 관리 서비스
Amazon Elastic Compute Cloud (Amazon EC2)의 컴퓨팅 리소스 외에도 광범위한 스토리지, 데이터베이스, 분석, 애플리케이션 및 배포 서비스에 액세스 할 수 있습니다. 이러한 서비스는 개발자가 즉시 사용할 수 있기 때문에 사내 전문 기술에 대한 의존도를 줄이고 조직이 새로운 솔루션을 더 빨리 제공 할 수 있습니다. 관리되는 AWS 서비스는 운영 복잡성과 비용을 낮출 수 있습니다. 또한 확장성과 고가용성을 위해 설계 되었으므로 구현의 위험을 줄일 수 있습니다.
Built-in 보안
기존 IT 환경에서 인프라 보안 감사는 정기적이고 수동적 인 프로세스 일 수 있습니다. 반대로 AWS 클라우드는 IT 리소스의 구성 변경 사항을 지속적으로 모니터링 할 수있는 거버넌스 기능을 제공합니다. AWS의 보안이 최우선 순위이므로 가장 보안에 민감한 조직의 요구 사항을 충족하도록 구축 된 데이터 센터 및 네트워크 아키텍처의 혜택을 누릴 수 있습니다.
AWS 리소스는 도구 및 API를 사용하여 프로그래밍할 수 있으므로 인프라 설계 내에서 보안 정책을 공식화하고 포함할 수 있습니다. 임시 환경을 가동하는 기능을 통해 보안 테스트는 이제 지속적인 제공 파이프라인의 일부가 될 수 있습니다. 마지막으로, 보다 높은 수준의 데이터 보호 및 컴플라이언스를 달성하는 데 도움이 되는 다양한 기본 AWS 보안 및 암호화 기능을 활용할 수 있습니다.
비용 설계
온-프레미스 솔루션의 기존 비용 관리는 일반적으로 서비스 제공과 밀접한 관련이 없습니다. 클라우드 컴퓨팅 환경을 프로비저닝 할 때 비용 최적화는 아키텍트의 기본 디자인 테넌트입니다. 솔루션을 선택할 때는 기능적 아키텍처 및 기능 세트뿐만 아니라 선택한 솔루션의 비용 프로필에 중점을 두어야합니다.
AWS는 세분화 된 청구를 제공하므로 솔루션의 모든 측면과 관련된 비용을 추적 할 수 있습니다. 예산 관리, 발생 비용 알림, 리소스 사용량 및 비용 최적화에 도움이 되는 다양한 서비스가 있습니다.
AWS에서의 운영
AWS에서 서비스를 운영 할 때 몇 가지 일반적인 운영 모델 범주가 있습니다.
- 마이그레이션 된 애플리케이션은 기존의 전통적인 운영 모델을 유지하고 API를 통해 Infrastructure as Code를 관리하는 기능을 활용하여 강력하고 반복 가능한 빌드 프로세스를 가능하게하여 안정성을 향상시킵니다.
- 리팩토링 된 솔루션은 운영 프로세스의 자동화를 지원 서비스로 활용합니다 예 : AWS Auto Scaling 및 자체 복구 아키텍처.
- 클라우드 운영을 위해 재구성되고 설계된 솔루션은 일반적으로 제공 파이프 라인 및 관리를위한 DevOps 프로세스를 통해 완전히 자동화됩니다.
이러한 전환을 지원하는 것은 사용 된 기술뿐만 아니라 개발 및 운영 팀 관리 방식의 문화적 변화도 변화시킵니다.
AWS는 툴링, 프로세스 및 모범 사례를 제공하여 운영 관행의 전환을 지원하여 클라우드 컴퓨팅에서 활용할 수있는 이점을 극대화합니다.
디자인 원칙
AWS 클라우드에는 다양한 사용 사례에 적용 할 수있는 많은 디자인 패턴과 아키텍처 옵션이 포함되어 있습니다. AWS 클라우드의 일부 주요 설계 원칙에는 확장성, 일회용 리소스, 자동화, 서버 대신 느슨한 커플링 관리 서비스 및 유연한 데이터 스토리지 옵션이 포함됩니다.
확장성
시간이 지남에 따라 확장 될 것으로 예상되는 시스템은 확장 가능한 아키텍처 위에 구축해야 합니다. 이러한 아키텍처는 성능 저하없이 사용자, 트래픽 또는 데이터 크기의 증가를 지원할 수 있습니다. 추가 자원을 추가하면 추가 로드를 제공하는 능력이 최소한 비례 적으로 증가하는 선형적인 방식으로 해당 스케일을 제공해야합니다. 성장은 규모의 경제를 가져오고 비용은 해당 시스템에서 비즈니스 가치를 창출하는 동일한 차원을 따라야합니다. 클라우드 컴퓨팅은 사실상 무제한의 주문형 용량을 제공하지만 디자인에서는 이러한 리소스를 완벽하게 활용할 수 있어야 합니다.
일반적으로 IT 아키텍처를 확장하는 방법에는 수직 및 수평의 두 가지가 있습니다.
수직 확장
수직 확장은 더 큰 하드 드라이브 또는 더 빠른 CPU로 서버를 업그레이드하는 것과 같이 개별 리소스의 사양이 증가함에 따라 발생합니다. Amazon EC2를 사용하면 인스턴스를 중지하고 RAM, CPU, I / O 또는 네트워킹 기능이 더 많은 인스턴스 유형으로 크기를 조정할 수 있습니다. 이러한 확장 방식은 결국 한계에 도달 할 수 있으며 항상 비용 효율적이거나 고 가용성 접근 방식은 아닙니다. 그러나 구현하기가 매우 쉽고 특히 단기적으로 많은 사용 사례에 충분할 수 있습니다.
수평 확장
스토리지 확장에 더 많은 하드 드라이브를 추가하거나 응용 프로그램을 지원하기 위해 서버를 추가하는 등 리소스 수의 증가를 통해 수평 확장이 이루어집니다. 이는 클라우드 컴퓨팅의 탄력성을 활용하는 인터넷 규모의 애플리케이션을 구축 할 수 있는 좋은 방법입니다. 모든 아키텍처가 워크로드를 여러 리소스로 분산하도록 설계된 것은 아니므로 가능한 시나리오를 살펴 보겠습니다.
상태 비 저장 애플리케이션
사용자 또는 서비스가 응용 프로그램과 상호 작용할 때 종종 세션을 형성하는 일련의 상호 작용을 수행합니다. 세션은 사용자가 응용 프로그램을 사용하는 동안 요청간에 유지되는 고유 한 데이터입니다. 상태 비 저장 응용 프로그램은 이전 상호 작용에 대한 지식이 필요하지 않으며 세션 정보를 저장하지 않는 응용 프로그램입니다. 예를 들어, 동일한 입력이 주어지면 모든 최종 사용자에게 동일한 응답을 제공하는 응용 프로그램은 상태 비 저장 응용 프로그램입니다. 사용 가능한 컴퓨팅 리소스 (예 : EC2 인스턴스 및 AWS Lambda 함수)가 모든 요청을 처리 할 수 있으므로 상태 비 저장 애플리케이션은 수평으로 확장 할 수 있습니다. 저장된 세션 데이터가 없으면 필요에 따라 더 많은 컴퓨팅 리소스를 추가 할 수 있습니다. 해당 용량이 더 이상 필요하지 않으면 실행 작업이 끝난 후 해당 개별 리소스를 안전하게 종료 할 수 있습니다. 이러한 리소스는 동료의 존재를 인식 할 필요가 없습니다. 워크로드를 분산시키는 방법 만 있으면됩니다.
여러 노드에 로드 분산
워크로드를 사용자 환경의 여러 노드에 분산하려면 푸시 또는 풀 모델을 선택할 수 있습니다.
푸시 모델을 사용하면 ELB (Elastic Load Balancing)를 사용하여 작업 부하를 분산시킬 수 있습니다. ELB는 들어오는 응용 프로그램 요청을 여러 EC2 인스턴스로 라우팅합니다. 트래픽을 라우팅 할 때 Network Load Balancer는 OSI (Open Systems Interconnection) 모델의 계층 4에서 작동하여 초당 수백만 건의 요청을 처리합니다. 컨테이너 기반 서비스를 채택하면 Application Load Balancer를 사용할 수도 있습니다. Application Load Balancer는 OSI 모델의 계층 7을 제공하고 애플리케이션 트래픽을 기반으로 컨텐츠 기반 요청의 라우팅을 지원합니다. 또는 Amazon Route 53을 사용하여 DNS 라운드 로빈을 구현할 수 있습니다. 이 경우 DNS 응답은 유효한 호스트 목록에서 라운드 로빈 방식으로 IP 주소를 반환합니다. 구현하기 쉽지만이 접근 방식이 항상 클라우드 컴퓨팅의 탄력성과 잘 작동하는 것은 아닙니다. DNS 레코드에 TTL (Low Time to Live) 값을 설정할 수 있더라도 캐싱 DNS 확인 프로그램은 Amazon Route 53의 제어 범위를 벗어나며 설정을 항상 준수하지 않을 수 있기 때문입니다.
로드 밸런싱 솔루션 대신 비동기 이벤트 중심 워크로드를 위한 풀 모델을 구현할 수 있습니다. 풀 모델에서 수행해야하는 작업 또는 처리해야 하는 데이터는 Amazon Simple Queue Service (Amazon SQS)를 사용하여 대기열에 메시지로 저장하거나 Amazon Kinesis와 같은 스트리밍 데이터 솔루션으로 저장할 수 있습니다. 그런 다음 여러 컴퓨팅 리소스가 해당 메시지를 가져 와서 소비하여 분산 방식으로 처리 할 수 있습니다.
상태 비 저장 컨포넌트
실제로 대부분의 응용 프로그램은 일종의 상태 정보를 유지 관리합니다. 예를 들어, 웹 애플리케이션은 사용자가 로그인했는지 여부를 추적하여 이전 조치를 기반으로 개인화 된 컨텐츠를 표시 할 수 있어야합니다. 자동화 된 다단계 프로세스는 이전 활동을 추적하여 다음 조치를 결정해야합니다. 로컬 파일 시스템에서 하나 이상의 요청에 대해 유지해야하는 항목을 저장하지 않아도 이러한 아키텍처의 일부를 상태 비 저장 상태로 만들 수 있습니다.
예를 들어, 웹 응용 프로그램은 HTTP 쿠키를 사용하여 웹 클라이언트 캐시에 세션 정보 (예 : 장바구니 항목)를 저장할 수 있습니다. 브라우저는 각 후속 요청에서 해당 정보를 서버로 다시 전달하므로 응용 프로그램에서 정보를 저장할 필요가 없습니다. 그러나이 방법에는 두 가지 단점이 있습니다. 첫째, 클라이언트 측에서 HTTP 쿠키의 내용이 변조 될 수 있으므로 항상 검증해야하는 신뢰할 수 없는 데이터로 취급해야 합니다. 둘째, HTTP 쿠키는 모든 요청과 함께 전송되므로 불필요한 대기 시간을 피하기 위해 크기를 최소로 유지해야합니다.
HTTP 쿠키에 고유 세션 식별자만 저장하고 서버 측에서 보다 자세한 사용자 세션 정보를 저장하십시오. 대부분의 프로그래밍 플랫폼은 이러한 방식으로 작동하는 기본 세션 관리 메커니즘을 제공합니다. 그러나 사용자 세션 정보는 종종 기본적으로 로컬 파일 시스템에 저장되어 상태 저장 아키텍처가 됩니다. 이 문제에 대한 일반적인 해결책은 이 정보를 데이터베이스에 저장하는 것입니다. Amazon DynamoDB는 확장 성, 고 가용성 및 내구성 특성으로 인해 탁월한 선택입니다. 많은 플랫폼에는 Amazon DynamoDB에 기본 세션을 저장할 수 있는 오픈 소스 드롭 인 교체 라이브러리가 있습니다.
다른 시나리오에서는 더 큰 파일을 저장해야합니다 (예 : 사용자 업로드 및 배치 프로세스의 중간 결과). 이러한 파일을 Amazon Simple Storage Service (Amazon S3) 또는 Amazon Elastic File System (Amazon EFS)과 같은 공유 스토리지 계층에 배치하면 상태 저장 구성 요소가 도입되는 것을 피할 수 있습니다.
마지막으로 복잡한 다단계 워크 플로는 각 실행의 현재 상태를 추적해야하는 또 다른 예입니다. AWS Step Functions를 사용하여 실행 기록을 중앙 집중식으로 저장하고 이러한 워크로드를 상태 비 저장으로 만들 수 있습니다.
상태 저장 컨포넌트
필연적으로 상태 비 저장 구성 요소로 변하지 않는 아키텍처 계층이 있을 것입니다. 데이터베이스는 상태 저장입니다. 자세한 내용은 데이터베이스 섹션을 참조하십시오. 또한 많은 레거시 응용 프로그램은 로컬 컴퓨팅 리소스를 사용하여 단일 서버에서 실행되도록 설계되었습니다. 다른 사용 사례에서는 클라이언트 장치가 특정 서버에 대한 연결을 장기간 유지해야 할 수도 있습니다. 예를 들어, 실시간 멀티 플레이어 게임은 지연 시간이 매우 짧은 여러 플레이어에게 게임 세계에 대한 일관되게 제공해야 합니다. 참가자가 동일한 서버에 연결되어 있는 비 분산 구현에서는 이 방법이 훨씬 간단합니다.
세션 선호도를 가진 여러 노드에 로드를 분산하여 이러한 구성요소를 수평으로 확장할 수 있습니다. 이 모델에서는 세션의 모든 트랜잭션을 특정 계산 리소스에 바인딩합니다. 하지만 이 모델에는 몇 가지 제한이 있습니다.
기존 세션은 새로 시작한 컴퓨팅 노드의 도입으로 직접적인 이점을 얻을 수 없습니다. 더 중요한 것은 세션 선호도를 보장할 수 없다는 것입니다. 예를 들어 노드가 종료되거나 사용할 수 없게 되면 노드에 바인딩 된 사용자의 연결이 끊기고 세션별 데이터가 손실됩니다. 이는 Amazon S3, Amazon EFS 또는 데이터베이스와 같은 공유 리소스에 저장되지 않은 데이터입니다.
Implement Session Affinity
HTTP 및 HTTPS 트래픽의 경우 Application Load Balancer의 고정 세션 기능을 사용하여 사용자 세션을 특정 인스턴스에 바인딩 할 수 있습니다. 이 기능을 사용하면 Application Load Balancer가 세션 기간 동안 해당 사용자에 대해 동일한 서버를 사용하려고 합니다.
클라이언트에서 실행되는 코드를 제어하는 경우 또 다른 옵션은 클라이언트 측로드 밸런싱을 사용하는 것입니다. 이는 추가 복잡성을 추가하지만로드 밸런서가 요구 사항을 충족하지 않는 시나리오에서 유용 할 수 있습니다. 예를 들어 ELB에서 지원하지 않는 프로토콜을 사용하거나 사용자가 서버에 할당되는 방법을 완전히 제어해야 할 수 있습니다 (예 : 게임 시나리오에서 게임 참가자가 일치하고 연결되어 있는지 확인해야 할 수 있음) 같은 서버). 이 모델에서 클라이언트는 직접 연결할 유효한 서버 엔드 포인트를 감지하는 방법이 필요합니다. 이를 위해 DNS를 사용하거나 클라이언트에서 실행중인 소프트웨어에 해당 정보를 제공하는 간단한 감지 API를 구축 할 수 있습니다. 로드 밸런서가 없으면 상태 확인 메커니즘도 클라이언트 쪽에서 구현해야 합니다. 서버를 사용할 수 없음이 감지 될 때 장치가 응용 프로그램을 거의 중단하지 않고 다른 서버에 다시 연결하도록 클라이언트 논리를 설계해야 합니다.
분산 처리
단일 컴퓨팅 리소스가 적시에 처리 할 수 없는 대량의 데이터를 처리하는 사용 사례에는 분산 처리 방식이 필요합니다. 작업과 해당 데이터를 여러 개의 작은 작업 조각으로 나눔으로써 일련의 컴퓨팅 리소스에서 병렬로 실행할 수 있습니다.
분산 처리 구현
AWS Batch, AWS Glue 및 Apache Hadoop과 같은 분산 데이터 처리 엔진을 사용하여 오프라인 배치 작업을 수평으로 확장 할 수 있습니다. AWS에서는 Amazon EMR을 사용하여 운영의 복잡성 없이 여러 EC2 인스턴스 위에서 Hadoop 워크로드를 실행할 수 있습니다. 스트리밍 데이터의 실시간 처리를 위해 Amazon Kinesis는 데이터를 여러 샤드로 분할 한 다음 여러 Amazon EC2 또는 AWS Lambda 리소스에서 소비하여 확장 성을 달성 할 수 있습니다.
이러한 유형의 워크로드에 대한 자세한 내용은 AWS의 핵심 데이터 분석 옵션 및 IoT 핵심 백서를 참조하십시오.
고정 서버 대신 일회용 리소스
기존 인프라 환경에서는 새로운 하드웨어 도입에 소요되는 초기 비용과 리드 타임으로 인해 고정 리소스로 작업해야 합니다. 이를 통해 수동으로 서버에 로그인하여 소프트웨어를 구성하거나 문제를 해결하고, IP 주소를 하드 코딩하고, 테스트를 실행하거나 작업을 순차적으로 처리하는 등의 방법을 수행합니다.
AWS를 설계 할 때 동적으로 프로비저닝 된 클라우드 컴퓨팅 특성을 활용할 수 있습니다. 서버 및 기타 구성 요소를 임시 자원으로 생각할 수 있습니다. 필요한만큼 시작할 수 있으며 필요한 기간 동안 만 사용할 수 있습니다.
오래 실행되는 고정 서버의 또 다른 문제는 구성 드리프트입니다. 시간이 지남에 따라 변경 사항 및 소프트웨어 패치가 적용되면 여러 환경에서 테스트되지 않은 이기종 구성이 발생할 수 있습니다. 불변의 인프라 패턴으로이 문제를 해결할 수 있습니다. 이 방법을 사용하면 서버가 한 번 시작되면 업데이트되지 않습니다. 대신, 문제가 있거나 업데이트가 필요한 경우 문제 서버는 최신 구성의 새 서버로 교체됩니다. 이를 통해 리소스는 항상 일관되고 테스트 된 상태를 유지하고 롤백을보다 쉽게 수행 할 수 있습니다. 이것은 상태 비 저장 아키텍처에서보다 쉽게 지원됩니다.
컴퓨팅 리소스 인스턴스화
새로운 테스트 환경을 구축하든, 추가 부하에 대처하기 위해 기존 시스템의 용량을 늘리든, 구성 및 코드로 새 리소스를 수동으로 설정하지 않아도 됩니다. 리드 타임이 길지 않고 사람이 실수하지 않도록 자동화되고 반복 가능한 프로세스를 만드는 것이 중요합니다. 이를 달성하기 위한 몇 가지 방법이 있습니다.
부트 스트랩
EC2 인스턴스 또는 Amazon RDS (Amazon Relational Database Service) DB 인스턴스와 같은 AWS 리소스를 시작하면 기본 구성으로 시작됩니다. 그런 다음 소프트웨어를 설치하거나 데이터를 복사하여 해당 리소스를 특정 상태로 만드는 스크립트인 자동화 된 부트스트랩 작업을 실행할 수 있습니다. 다른 환경 (예 : 프로덕션 또는 테스트)마다 다른 구성 세부 사항을 매개 변수화 하여 수정없이 동일한 스크립트를 재사용 할 수 있습니다.
사용자 데이터 스크립트 및 cloud-init 지시문을 사용하여 새 EC2 인스턴스를 설정할 수 있습니다. Chef 또는 Puppet과 같은 간단한 스크립트 및 구성 관리 도구를 사용할 수 있습니다. 또한 사용자 지정 스크립트 및 AWS API 또는 AWS Lambda 지원 사용자 지정 리소스에 대한 AWS CloudFormation 지원을 통해 거의 모든 AWS 리소스에서 작동하는 프로비저닝 로직을 작성할 수 있습니다.
골든 이미지
EC2 인스턴스, Amazon RDS DB 인스턴스 및 Amazon Elastic Block Store (Amazon EBS) 볼륨과 같은 특정 AWS 리소스 유형은 골든 이미지에서 시작할 수 있으며 이는 해당 리소스의 특정 상태에 대한 스냅 샷입니다. 부트 스트랩 방식과 비교할 때 골든 이미지는 시작 시간이 더 빨라지고 구성 서비스 또는 타사 저장소에 대한 종속성을 제거합니다. 이는 수요 변화에 대한 응답으로 추가 리소스를 빠르고 안정적으로 시작할 수있는 자동 확장 환경에서 중요합니다.
EC2 인스턴스를 사용자 정의한 다음 Amazon 머신 이미지 (AMI)를 생성하여 구성을 저장할 수 있습니다. AMI에서 필요한만큼 인스턴스를 시작할 수 있으며 이러한 모든 사용자 지정이 포함됩니다. 구성을 변경할 때마다 새 골든 이미지를 만들어야하므로 시간이 지남에 따라 골든 이미지를 관리하는 버전 관리 규칙이 있어야합니다. 스크립트를 사용하여 AMI 생성에 사용하는 EC2 인스턴스의 부트 스트랩을 생성하는 것이 좋습니다. 이를 통해 시간에 따라 이미지를 테스트하고 수정할 수 있는 유연한 방법을 제공합니다.
또는 기존 온 프레미스 가상화 환경이있는 경우 AWS에서 VM Import / Export를 사용하여 다양한 가상화 형식을 AMI로 변환 할 수 있습니다. AWS Marketplace에서 AWS 또는 타사에서 제공하는 사전 준비 된 공유 AMI를 찾아서 사용할 수도 있습니다.
골든 이미지는 새 EC2 인스턴스를 시작할 때 가장 일반적으로 사용되지만 Amazon RDS DB 인스턴스 또는 Amazon EBS 볼륨과 같은 리소스에도 적용 할 수 있습니다. 예를 들어 새 테스트 환경을 시작할 때 긴 SQL 스크립트에서 데이터를 가져 오는 대신 특정 Amazon RDS 스냅 샷에서 데이터베이스를 인스턴스화하여 데이터베이스를 미리 채울 수 있습니다.
컨테이너
개발자에게 인기있는 또 다른 옵션은 소프트웨어 컨테이너 내에 분산 응용 프로그램을 빌드하고 배포 할 수 있는 오픈 소스 기술인 Docker입니다. Docker를 사용하면 소프트웨어 개발을 위한 표준화 된 단위 인 Docker 이미지로 소프트웨어를 패키지화 할 수 있습니다. 이 소프트웨어는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 소프트웨어 실행에 필요한 모든 것을 포함합니다. AWS Elastic Beanstalk, Amazon Elastic Container 서비스 (Amazon ECS) 및 AWS Fargate를 사용하면 EC2 인스턴스 클러스터에 여러 컨테이너를 배포하고 관리 할 수 있습니다. 골든 도커 이미지를 빌드하고 ECS 컨테이너 레지스트리를 사용하여 이미지를 관리 할 수 있습니다.
다른 컨테이너 환경은 Kubernetes 및 Kubernetes 용 Amazon Elastic Container Service (Amazon EKS)입니다. Kubernetes와 Amazon EKS를 사용하면 컨테이너화 된 애플리케이션을 쉽게 배포, 관리 및 확장 할 수 있습니다.
하이브리드
두 가지 접근 방식의 조합을 사용할 수도 있습니다. 구성의 일부는 골든 이미지로 캡처 되고 다른 일부는 부트 스트랩 작업을 통해 동적으로 구성됩니다.
자주 변경되지 않거나 외부 종속성을 유발하는 항목은 일반적으로 골든 이미지의 일부입니다. 적합한 후보의 예로는 인스턴스를 시작할 때마다 타사 저장소에서 다운로드 해야 하는 웹 서버 소프트웨어가 있습니다.
다양한 환경에서 자주 변경되거나 다른 항목은 부트 스트랩 작업을 통해 동적으로 설정할 수 있습니다. 예를 들어, 새 버전의 애플리케이션을 자주 배포하는 경우 각 애플리케이션 버전마다 새 AMI를 생성하는 것이 실용적이지 않을 수 있습니다. 또한 테스트 환경과 프로덕션 환경이 다르기 때문에 데이터베이스 호스트 이름 구성을 AMI에 하드 코딩하고 싶지 않습니다. 사용자 데이터 또는 태그를 사용하면 시작 시 수정할 수 있는 보다 일반적인 AMI를 사용할 수 있습니다. 예를 들어 다양한 소규모 비즈니스를 위해 웹 서버를 실행하는 경우 모두 동일한 AMI를 사용하고 시작 시 사용자 데이터에 지정한 S3 버킷 위치에서 컨텐츠를 검색 할 수 있습니다.
AWS Elastic Beanstalk는 하이브리드 모델을 따릅니다. 미리 구성된 런타임 환경 (각각 자체 AMI에서 시작됨)을 제공하지만 .ebextensions 구성 파일을 통해 부트 스트랩 작업을 실행하고 환경 변수를 구성하여 환경 차이를 매개 변수화 할 수 있습니다.
새로운 리소스의 배포를 관리 할 수있는 다양한 방법에 대한 자세한 내용은 AWS의 배포 옵션 개요 및 AWS 인프라 관리 백서를 참조하십시오.
코드로서의 인프라
우리가 논의한 원칙의 적용이 개별 자원 수준으로 제한 될 필요는 없습니다. AWS 자산은 프로그래밍 가능하므로 소프트웨어 개발의 기술, 사례 및 도구를 적용하여 전체 인프라를 재사용, 유지 관리, 확장 및 테스트 할 수 있습니다. 자세한 내용은 Infrastructure as Code 백서를 참조하십시오.
AWS CloudFormation 템플릿을 사용하면 관련 AWS 리소스 모음을 손쉽게 생성 및 관리하고 순서에 따라 예측 가능한 방식으로 프로비저닝 및 업데이트 할 수 있습니다. 애플리케이션을 실행하는 데 필요한 AWS 리소스 및 관련 종속성 또는 런타임 파라미터를 설명 할 수 있습니다. CloudFormation 템플릿은 버전 관리 리포지토리에서 애플리케이션과 함께 사용할 수 있으므로 테스트를 위해 아키텍처를 재사용하고 프로덕션 환경을 안정적으로 복제 할 수 있습니다.
자동화
전통적인 IT 인프라에서는 종종 다양한 이벤트에 수동으로 대응해야합니다. AWS에 배포 할 때는 시스템의 안정성과 조직의 효율성을 모두 향상시킬 수있는 자동화 기회가 있습니다. 복원력, 확장 성 및 성능을 높이려면 이러한 유형의 자동화 중 하나 이상을 애플리케이션 아키텍처에 도입하십시오.
서버리스 관리 및 배포
서버리스 패턴을 채택하면 운영 파이프 라인의 자동화에 초점이 맞춰집니다. AWS는 기본 서비스, 규모 및 가용성을 관리합니다.
AWS CodePipeline, AWS CodeBuild 및 AWS CodeDeploy는 이러한 프로세스 배포 자동화를 지원합니다.
인프라 관리 및 배포
AWS Elastic Beanstalk: 이 서비스를 사용하여 Apache, Nginx, Passenger 및 IIS와 같은 익숙한 서버에서 Java, .NET, PHP, Node.js, Python, Ruby, Go 및 Docker로 개발 된 웹 애플리케이션 및 서비스를 배치하고 확장 할 수 있습니다. 애플리케이션 코드를 간단히 업로드 할 수 있으며 서비스는 리소스 프로비저닝,로드 밸런싱, 자동 확장 및 모니터링과 같은 모든 세부 정보를 자동으로 처리합니다.
Amazon EC2 auto recovery: EC2 인스턴스를 모니터링하고 장애가 발생하면 자동으로 복구하는 Amazon CloudWatch 경보를 생성 할 수 있습니다 . 복구 된 인스턴스는 인스턴스 ID, 프라이빗 IP 주소, 탄력적 IP 주소 및 모든 인스턴스 메타 데이터를 포함하여 원래 인스턴스와 동일합니다. 그러나 이 기능은 적용 가능한 인스턴스 구성에만 사용할 수 있습니다. 이러한 사전 조건에 대한 최신 설명은 Amazon EC2 설명서를 참조하십시오. 또한 인스턴스 복구 중에는 인스턴스 재부팅을 통해 인스턴스가 마이그레이션되고 메모리에 있는 모든 데이터가 손실됩니다.
AWS Systems Manager: 소프트웨어 인벤토리를 자동으로 수집하고 OS 패치를 적용하며 시스템 이미지를 만들어 Windows 및 Linux 운영 체제를 구성하고 임의의 명령을 실행할 수 있습니다. 이러한 서비스를 제공하면 운영 모델이 간소화되고 최적의 환경 구성이 보장됩니다.
Auto Scaling: 정의한 조건에 따라 애플리케이션 가용성을 유지하고 Amazon EC2, Amazon DynamoDB, Amazon ECS, Kubernetes 용 Amazon Elastic Container Service (Amazon EKS) 용량을 자동으로 늘리거나 줄일 수 있습니다. Auto Scaling을 사용하면 여러 가용 영역에서 원하는 수의 정상 EC2 인스턴스를 실행하고 있는지 확인할 수 있습니다. Auto Scaling은 수요 급증시 EC2 인스턴스 수를 자동으로 늘려 사용량이 적은 기간 동안 성능을 유지하고 용량을 줄여 비용을 최적화 할 수 있습니다.
알람 및 이벤트
Amazon CloudWatch alarms: 특정 지표가 지정된 기간 동안 지정된 임계 값을 초과 할 때 Amazon Simple Notification Service (Amazon SNS) 메시지를 전송하는 CloudWatch 경보를 생성 할 수 있습니다. 이러한 Amazon SNS 메시지는 구독 된 Lambda 함수의 실행을 자동으로 시작하거나 Amazon SQS 대기열에 알림 메시지를 대기열에 넣거나 HTTP 또는 HTTPS 엔드 포인트에 POST 요청을 수행 할 수 있습니다.
Amazon CloudWatch Events: AWS 리소스의 변경 사항을 설명하는 실시간 시스템 이벤트 스트림을 제공합니다. 간단한 규칙을 사용하면 각 유형의 이벤트를 Lambda 함수, Kinesis 스트림 및 SNS 주제와 같은 하나 이상의 대상으로 라우팅 할 수 있습니다.
AWS Lambda scheduled events: Lambda 함수를 생성하고 정기적으로 실행하도록 AWS Lambda를 구성 할 수 있습니다.
AWS WAF security automations: AWS WAF는 웹 애플리케이션 방화벽으로, 애플리케이션 가용성에 영향을 미치거나 보안을 손상 시키거나 과도한 리소스를 소비 할 수있는 일반적인 공격 패턴을 차단하는 맞춤형 애플리케이션 별 규칙을 생성 할 수 있습니다. API를 통해 AWS WAF를 완벽하게 관리 할 수 있어 보안 자동화가 쉬워져 빠른 규칙 전파와 빠른 사고 대응이 가능합니다.
느슨한 결합
응용 프로그램의 복잡성이 증가함에 따라 IT 시스템의 바람직한 특성은 더 작고 느슨하게 결합 된 구성 요소로 나눌 수 있다는 것입니다. 즉, IT 시스템은 상호 종속성을 줄이는 방식으로 설계 되어야 합니다. 한 구성 요소의 변경 또는 오류가 다른 구성 요소에 종속되지 않아야 합니다.
잘 정의 된 인터페이스
시스템에서 상호 종속성을 줄이는 방법은 RESTful API와 같은 특정 기술에 구애받지 않는 인터페이스를 통해서만 다양한 구성 요소가 서로 상호 작용할 수 있도록하는 것입니다. 이러한 방식으로 기술 구현 세부 사항이 숨겨져 팀이 다른 구성 요소에 영향을 주지 않고 기본 구현을 수정할 수 있습니다. 이러한 인터페이스가 이전 버전과의 호환성을 유지하는 한 차이 구성 요소의 배포는 분리됩니다. 이 세부적인 디자인 패턴을 일반적으로 마이크로 서비스 아키텍처라고합니다.
Amazon API Gateway는 개발자가 모든 규모의 API를 쉽게 생성, 게시, 유지 관리, 모니터링 및 보안 할 수 있도록하는 완전 관리 형 서비스입니다. 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링 및 API 버전 관리를 포함하여 최대 수십만 개의 동시 API 호출 수락 및 처리와 관련된 모든 작업을 처리합니다.
Service Discovery
더 작은 서비스 집합으로 배포되는 응용 프로그램은 해당 서비스가 서로 상호 작용할 수 있는 기능에 따라 다릅니다. 이러한 각 서비스는 여러 컴퓨팅 리소스에서 실행될 수 있으므로 각 서비스를 처리 할 수있는 방법이 필요합니다. 예를 들어, 기존 인프라에서 프론트 엔드 웹 서비스가 백엔드 웹 서비스와 연결해야 하는 경우이 서비스가 실행중인 컴퓨팅 리소스의 IP 주소를 하드 코딩 할 수 있습니다. 이 접근 방식은 여전히 클라우드 컴퓨팅에서 작동 할 수 있지만 이러한 서비스가 느슨하게 연결되어 있으면 네트워크 토폴로지 세부 정보에 대한 사전 지식 없이도 서비스를 이용할 수 있어야 합니다. 복잡성을 숨기는 것 외에도 인프라 세부 사항을 언제든지 변경할 수 있습니다. 느슨한 결합은 언제든지 새로운 리소스를 시작하거나 종료 할 수 있는 클라우드 컴퓨팅의 탄력성을 활용하려는 경우 중요한 요소입니다. 이를 위해서는 서비스 검색을 구현할 수 있는 방법이 필요합니다.
서비스 검색 구현
Amazon EC2 호스팅 서비스의 경우 서비스 검색을 수행하는 간단한 방법은 ELB (Elastic Load Balancing)를 사용하는 것입니다. 각로드 밸런서는 자체 호스트 이름을 가져 오므로 안정적인 엔드 포인트를 통해 서비스를 사용할 수 있습니다. 이를 DNS 및 프라이빗 Amazon Route 53 영역과 결합하여 언제든지 특정로드 밸런서의 엔드 포인트를 추상화하고 수정할 수 있습니다.
다른 옵션은 서비스 등록 및 발견 방법을 사용하여 엔드 포인트 IP 주소 및 서비스의 포트 번호를 검색 할 수 있습니다. 서비스 검색은 구성 요소 사이의 접착제가 되기 때문에 가용성과 안정성이 중요합니다. 로드 밸런서를 사용하지 않는 경우 서비스 검색은 상태 확인과 같은 옵션도 허용해야 합니다. Amazon Route 53은 자동 이름 지정을 지원하여 마이크로 서비스 용 인스턴스를 보다 쉽게 프로비저닝 할 수 있습니다. 자동 이름 지정을 사용하면 정의한 구성에 따라 DNS 레코드를 자동으로 만들 수 있습니다. 다른 구현 예에는 태그 조합, 고 가용성 데이터베이스, AWS API를 호출하는 사용자 지정 스크립트 또는 Netflix Eureka, Airbnb Synapse 또는 HashiCorp Consul과 같은 오픈 소스 도구를 사용하는 사용자 지정 솔루션이 포함됩니다.
비동기 통합
비동기 통합은 서비스 간 느슨한 결합의 또 다른 형태입니다. 이 모델은 즉각적인 응답이 필요하지 않으며 요청이 등록되었다는 확인이 필요한 모든 상호 작용에 적합합니다. 이벤트를 생성하는 하나의 구성 요소와 이를 소비하는 다른 구성 요소가 관련됩니다. 두 구성 요소는 직접적인 지점 간 상호 작용을 통해 통합되지 않지만 일반적으로 SQS 대기열과 같은 중간 내구성 저장소 계층 또는 Amazon Kinesis, 계단식 Lambda 이벤트, AWS Step Functions 또는 Amazon Simple Workflow와 같은 스트리밍 데이터 플랫폼을 통해 통합됩니다.
이 접근 방식은 두 구성 요소를 분리하고 추가적인 복원력을 제공합니다. 예를 들어 대기열에서 메시지를 읽는 프로세스가 실패하더라도 메시지를 대기열에 추가하고 시스템이 복구될 때 처리할 수 있습니다. 또한 확장성이 떨어지는 백엔드 서비스를 프런트 엔드 급증으로부터 보호하고 비용과 처리 지연 간에 적절한 절충점을 찾을 수 있습니다. 예를 들어, 일부 지연과 함께 비동기식으로 쿼리를 처리하기만 하면 가끔 최대 쓰기 쿼리를 수용할 수 있도록 데이터베이스를 확장할 필요가 없다고 결정할 수 있습니다. 마지막으로, 대화형 요청 경로에서 느린 작업을 제거함으로써 최종 사용자 환경도 개선할 수 있습니다.
비동기식 통합의 예는 다음과 같습니다.
- 프론트 엔드 애플리케이션은 Amazon SQS와 같은 대기열 시스템에 작업을 삽입합니다. 백엔드 시스템은 해당 작업을 검색하여 자체 속도로 처리합니다.
- API는 이벤트를 생성하여 Kinesis 스트림으로 푸시합니다. 백엔드 응용 프로그램은 이러한 이벤트를 일괄 처리하여 데이터베이스에 저장된 집계 된 시계열 데이터를 만듭니다.
- 여러 이기종 시스템은 AWS Step Functions를 사용하여 서로 직접 상호 작용하지 않고 시스템 간의 작업 흐름을 전달합니다.
- Lambda 함수는 Amazon DynamoDB 업데이트 스트림 및 Amazon S3 이벤트 알림과 같은 다양한 AWS 소스의 이벤트를 사용할 수 있습니다. Lambda가 이를 처리하기 때문에 큐잉 또는 기타 비동기 통합 방법 구현에 대해 걱정할 필요가 없습니다.
분산 시스템 모범 사례
느슨한 결합을 증가시키는 또 다른 방법은 구성 요소 장애를 정상적으로 처리하는 응용 프로그램을 구축하는 것입니다. 일부 구성 요소 오류가 발생하더라도 최종 사용자에게 미치는 영향을 줄이고 오프라인 절차에 대한 진행 능력을 높일 수있는 방법을 식별 할 수 있습니다.
Graceful Failure in Practice
실패한 요청은 지수 백 오프 및 지터 전략으로 재 시도하거나 나중에 처리하기 위해 큐에 저장할 수 있습니다. 프론트 엔드 인터페이스의 경우 데이터베이스 서버를 사용할 수 없게 될 때 완전히 실패하지 않고 대체 또는 캐시 된 컨텐츠를 제공 할 수 있습니다. Amazon Route 53 DNS 장애 조치 기능을 통해 기본 사이트를 사용할 수없는 경우 웹 사이트를 모니터링하고 백업 사이트로 방문자를 자동으로 라우팅 할 수 있습니다. 백업 사이트를 Amazon S3의 정적 웹 사이트 또는 별도의 동적 환경으로 호스팅 할 수 있습니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
