[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Architecting for the Cloud — AWS Best Practices(2018, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
본 문서는 총 2부로 구성되어 있으며 이 글은 1부입니다.
소개
애플리케이션을 AWS로 마이그레이션하는 것은 중요한 변경 사항(리프트 및 시프트 방식) 없이 조직에게 안전하고 비용 효율적인 인프라의 이점을 제공합니다. 그러나 클라우드 컴퓨팅을 통해 가능한 탄력성과 민첩성을 최대한 활용하려면 엔지니어가 아키텍처를 발전시켜 AWS 기능을 활용해야 합니다.
새로운 애플리케이션의 경우 클라우드별 IT 아키텍처 패턴을 통해 효율성과 확장성을 높일 수 있습니다. 이러한 새로운 아키텍처는 인터넷 규모 데이터의 실시간 분석에서 수천 개의 연결된 사물 인터넷(IoT) 또는 모바일 장치에서 예측 불가능한 트래픽이 있는 애플리케이션에 이르기까지 모든 것을 지원할 수 있습니다.
현재 사내 환경에서 실행되는 애플리케이션을 AWS에서 실행하도록 다시 설계하거나 클라우드 네이티브 애플리케이션을 설계하는 경우라면 기존 환경과 클라우드 컴퓨팅 환경의 차이를 고려해야 합니다. 여기에는 아키텍처 선택, 확장성, 리소스 유형, 자동화, 유연한 구성 요소, 서비스 및 데이터베이스가 포함됩니다. AWS를 처음 접하는 경우 AWS 서비스에 대한 기본적인 이해를 얻으려면 AWS 정보 페이지의 정보를 검토하는 것이 좋습니다.
기존 컴퓨팅 환경과 클라우드 컴퓨팅 환경의 차이점
클라우드 컴퓨팅은 유연하고 글로벌하며 확장 가능한 용량, 관리형 서비스, 내장 보안, 비용 최적화 옵션, 다양한 운영 모델 등 다양한 측면에서 기존의 사내 환경과 다릅니다.
프로비저닝 된 리소스인 IT 자산
기존 컴퓨팅 환경에서는 이론적으로 최대 피크의 추정치를 기반으로 용량을 프로비저닝합니다. 이로 인해 비용이 많이 드는 리소스가 유휴 상태이거나 용량이 부족한 경우가 발생할 수 있습니다. 클라우드 컴퓨팅을 사용하면 필요한 용량만큼 또는 적은 용량에 액세스할 수 있으며, 실제 수요를 충족하기 위해 동적으로 확장할 수 있으며, 사용량에 대해서만 비용을 지불할 수 있습니다.
AWS에서는 서버, 데이터베이스, 스토리지 및 상위 수준의 애플리케이션 구성 요소를 몇 초 내에 인스턴스화할 수 있습니다. 이러한 리소스를 고정되고 유한한 IT 인프라의 유연성과 제약 없이 임시 리소스로 처리할 수 있습니다. 이렇게 하면 변경 관리, 테스트, 안정성 및 용량 계획에 대한 접근 방식이 재설정됩니다. 이러한 접근 방식의 변화는 프로세스에 빠르게 실패하고 빠르게 반복되는 기능을 도입하여 실험을 장려합니다.
글로벌, 가용 및 확장 가능한 용량
AWS의 글로벌 인프라를 사용하여 요구 사항을 가장 잘 충족하는 AWS 영역(예: 최종 사용자와의 근접성, 컴플라이언스, 데이터 상주 제약 및 비용)에 애플리케이션을 배포할 수 있습니다. 글로벌 애플리케이션의 경우 Amazon CloudFront 콘텐츠 전송 네트워크(CDN)를 사용하여 전 세계 최종 사용자의 대기 시간을 줄일 수 있습니다. 또한 여러 데이터 센터에서 프로덕션 애플리케이션과 데이터베이스를 훨씬 쉽게 운영하여 고가용성 및 내결함성을 달성할 수 있습니다. AWS의 글로벌 인프라와 필요에 따라 용량을 프로비저닝할 수 있는 기능을 통해 애플리케이션에 대한 수요와 서비스 범위가 확장될 때 인프라에 대해 다르게 생각할 수 있습니다.
고급 관리 서비스
Amazon Elastic Compute Cloud(Amazon EC2)의 컴퓨팅 리소스 외에도 다양한 스토리지, 데이터베이스, 분석, 애플리케이션 및 구축 서비스셋에 액세스할 수 있습니다. 이러한 서비스는 개발자가 즉시 사용할 수 있기 때문에 사내 전문 기술에 대한 의존도를 줄이고 조직에서 새로운 솔루션을 더 빠르게 제공할 수 있습니다. 관리되는 AWS 서비스는 운영 복잡성과 비용을 낮출 수 있습니다. 또한 확장성과 고가용성(HA)을 위해 설계되어 구현 위험을 줄일 수 있습니다.
보안 기능의 내장
기존 IT 환경에서는 인프라 보안 감사가 주기적이고 수동적인 프로세스가 될 수 있습니다. 반면 AWS Cloud는 IT 리소스에 대한 구성 변경 사항을 지속적으로 모니터링할 수 있는 거버넌스 기능을 제공합니다. AWS의 보안은 가장 높은 우선 순위입니다. 즉, 가장 보안에 민감한 조직의 요구 사항을 충족하도록 구축된 데이터 센터 및 네트워크 아키텍처의 이점을 누릴 수 있습니다.
AWS 리소스는 도구와 API를 사용하여 프로그래밍할 수 있으므로 인프라 설계 내에서 보안 정책을 공식화하고 포함할 수 있습니다. 임시 환경을 가동하는 기능을 통해 보안 테스트는 이제 지속적인 제공 파이프라인의 일부가 될 수 있습니다. 마지막으로, 보다 높은 수준의 데이터 보호 및 컴플라이언스를 달성할 수 있도록 지원하는 다양한 기본 AWS 보안 및 암호화 기능을 활용할 수 있습니다.
비용을 위한 설계
사내 솔루션의 기존 비용 관리는 일반적으로 서비스 제공과 밀접하게 연관되어 있지 않습니다. 클라우드 컴퓨팅 환경을 프로비저닝할 때 비용에 맞게 최적화하는 것은 설계자를 위한 기본 설계 테넌트입니다. 솔루션을 선택할 때는 기능 아키텍처 및 기능 세트뿐만 아니라 선택한 솔루션의 비용 프로필에 집중해야 합니다.
AWS는 솔루션의 모든 측면과 관련된 비용을 추적할 수 있는 세밀한 청구서를 제공합니다. 예산 관리, 발생 비용 알림, 리소스 사용 및 비용 최적화를 지원하는 다양한 서비스가 있습니다.
AWS에서의 작업
AWS에서 서비스를 운영할 때 다음과 같은 몇 가지 일반적인 범주가 있습니다.
- 마이그레이션되고 기존 운영 모델을 유지하며, 강력하고 반복 가능한 빌드 프로세스를 지원하고 안정성을 향상시키는 API를 통해 인프라(Code)를 코드화하는 기능을 활용합니다.
- 리팩터링된 솔루션은 AWS 자동 확장 및 자가 복구 아키텍처와 같은 지원 서비스로서 운영 프로세스의 높은 자동화 수준을 활용합니다.
- 클라우드 운영을 위해 다시 설계되고 설계된 솔루션은 일반적으로 제공 파이프라인 및 관리를 위한 DevOps 프로세스를 통해 완전히 자동화됩니다.
이러한 전환을 지원하는 것은 단순히 사용된 기술을 바꾸는 것이 아니라 개발 및 운영 팀의 관리 방식에 따른 문화적 변화도 가져옵니다.
AWS는 클라우드 컴퓨팅에서 활용할 수 있는 이점을 극대화하기 위해 운영 사례의 전환을 지원하는 툴링, 프로세스 및 모범 사례를 제공합니다.
설계 원칙
AWS 클라우드에는 다양한 사용 사례에 적용 할 수있는 많은 디자인 패턴과 아키텍처 옵션이 포함되어 있습니다. AWS 클라우드의 일부 주요 설계 원칙에는 확장 성, 일회용 리소스, 자동화, 서버 대신 느슨한 결합 관리 서비스 및 유연한 데이터 스토리지 옵션이 포함됩니다.
확장성
시간이 지남에 따라 증가할 것으로 예상되는 시스템은 확장 가능한 아키텍처를 기반으로 구축되어야 합니다. 이러한 아키텍처는 드롭인 성능 없이 사용자, 트래픽 또는 데이터 크기의 증가를 지원할 수 있습니다. 추가 리소스를 추가하면 추가 부하를 처리할 수 있는 능력이 최소한 비례적으로 증가하는 선형 방식으로 확장해야 합니다. 성장은 규모의 경제를 도입해야 하며 비용은 시스템에서 비즈니스 가치를 창출하는 것과 동일한 차원을 따라야 합니다. 클라우드 컴퓨팅은 사실상 무제한의 온디맨드 용량을 제공하지만 설계 시 이러한 리소스를 원활하게 활용할 수 있어야 합니다.
IT 아키텍처를 확장하는 방법에는 일반적으로 수직 및 수평 두 가지가 있습니다.
수직 확장
수직 확장은 더 큰 하드 드라이브나 더 빠른 CPU로 서버를 업그레이드하는 것과 같은 개별 리소스의 사양이 증가함에 따라 수행됩니다. Amazon EC2를 사용하면 인스턴스를 중지하고 더 많은 RAM, CPU, I/O 또는 네트워킹 기능을 가진 인스턴스 유형으로 크기를 조정할 수 있습니다. 이러한 확장 방식은 결국 한계에 이를 수 있으며, 항상 비용 효율적이거나 가용성이 높은 방식은 아닙니다. 그러나 구현이 매우 쉽고 특히 단기적으로 많은 사용 사례에 충분할 수 있습니다.
수평 확장
수평적 확장은 스토리지 어레이에 하드 드라이브를 추가하거나 애플리케이션을 지원하기 위해 서버를 추가하는 등 리소스 수의 증가를 통해 이루어집니다. 이는 클라우드 컴퓨팅의 유연성을 활용하는 인터넷 규모의 애플리케이션을 구축하는 좋은 방법입니다. 모든 아키텍처가 워크로드를 여러 리소스에 분산하도록 설계된 것은 아닙니다. 몇 가지 가능한 시나리오를 살펴보겠습니다.
상태 비 저장 애플리케이션
사용자 또는 서비스가 애플리케이션과 상호 작용할 때 세션이 형성되는 일련의 상호 작용을 수행하는 경우가 많습니다. 세션은 애플리케이션을 사용하는 동안 요청 간에 지속되는 사용자에게 고유한 데이터입니다. 상태 비저장 응용 프로그램은 이전 상호 작용에 대한 지식이 필요 없고 세션 정보를 저장하지 않는 응용 프로그램입니다. 예를 들어, 동일한 입력을 통해 최종 사용자에게 동일한 응답을 제공하는 애플리케이션은 상태 비저장 애플리케이션입니다. 상태 비저장 응용 프로그램은 사용 가능한 계산 리소스(EC2 인스턴스 및 AWS Lambda 기능 등)가 모든 요청을 처리할 수 있기 때문에 수평으로 확장할 수 있습니다. 저장된 세션 데이터가 없으면 필요에 따라 계산 리소스를 더 추가할 수 있습니다. 이 용량이 더 이상 필요하지 않은 경우 실행 중인 태스크가 손실된 후 개별 리소스를 안전하게 종료할 수 있습니다. 이러한 리소스는 동료의 존재를 인식할 필요가 없습니다. 필요한 모든 것은 워크로드에 대한 분산입니다.
여러 노드에 로드 분배
작업량을 환경의 여러 노드에 분산하려면 푸시 또는 풀 모델을 선택할 수 있습니다.
푸시 모델을 사용하면 ELB(Elastic Load Balancing)를 사용하여 워크로드를 분산할 수 있습니다. ELB는 들어오는 애플리케이션 요청을 여러 EC2 인스턴스로 라우팅합니다. 트래픽을 라우팅할 때 네트워크 로드 밸런서는 OSI(Open Systems Interconnection) 모델의 4계층에서 작동하여 초당 수백만 개의 요청을 처리합니다. 컨테이너 기반 서비스를 채택하면 애플리케이션 로드 밸런서도 사용할 수 있습니다. 애플리케이션 로드 밸런서는 OSI 모델의 계층 7을 제공하고 애플리케이션 트래픽에 기반한 요청의 컨텐츠 기반 라우팅을 지원합니다. 또는 Amazon Route 53을 사용하여 DNS 라운드 로빈을 구현할 수 있습니다. 이 경우 DNS 응답은 유효한 호스트 목록에서 IP 주소를 라운드 로빈 방식으로 반환합니다. 이러한 접근 방식은 구현이 쉽지만 클라우드 컴퓨팅의 탄력성과는 항상 잘 작동하지 않습니다. 이는 DNS 레코드의 TTL(사용 시간) 값을 낮게 설정할 수 있더라도 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 단계 기능을 사용하여 실행 기록을 중앙에서 저장하고 이러한 워크로드를 상태 비저장 상태로 만들 수 있습니다.
상태 저장 구성 요소
불가피하게, 상태 비저장 구성요소로 전환되지 않는 아키텍처 계층이 존재하게 됩니다. 정의상 데이터베이스는 상태 저장입니다. 자세한 내용은 데이터베이스 섹션을 참조합니다. 또한 많은 레거시 애플리케이션은 로컬 컴퓨팅 리소스에 의존하여 단일 서버에서 실행되도록 설계되었습니다. 다른 사용 사례에서는 클라이언트 디바이스가 특정 서버에 대한 연결을 장기간 유지해야 할 수 있습니다. 예를 들어, 실시간 멀티플레이어 게임은 지연 시간이 매우 짧은 일관된 게임 세계관을 여러 플레이어에 제공해야 합니다. 이는 참가자가 동일한 서버에 연결되어 있는 분산되지 않은 구현에서 훨씬 간단하게 달성할 수 있습니다.
세션 선호도를 사용하여 로드를 여러 노드에 분산하여 이러한 구성 요소를 수평으로 확장할 수 있습니다. 이 모델에서는 세션의 모든 트랜잭션을 특정 계산 리소스에 바인딩합니다. 하지만 이 모델에는 몇 가지 제한이 있습니다.
기존 세션은 새로 실행된 컴퓨팅 노드의 도입으로 직접적인 혜택을 받지 못합니다. 더 중요한 것은 세션 선호도를 보장할 수 없다는 것입니다. 예를 들어 노드가 종료되거나 사용할 수 없게 되면 노드에 바인딩된 사용자가 연결이 끊기고 세션별 데이터가 손실됩니다. 이는 Amazon S3, Amazon EFS 또는 데이터베이스와 같은 공유 리소스에 저장되지 않은 데이터입니다.
세션 친화성 구현
HTTP 및 HTTPS 트래픽의 경우 애플리케이션 로드 밸런서의 고정 세션 기능을 사용하여 사용자의 세션을 특정 인스턴스에 바인딩할 수 있습니다. 이 기능을 사용하면 애플리케이션 로드 밸런서가 세션 동안 해당 사용자에 대해 동일한 서버를 사용하려고 시도합니다.
클라이언트에서 실행되는 코드를 제어하는 다른 옵션은 클라이언트 측 로드 밸런싱을 사용하는 것입니다. 따라서 복잡성이 가중되지만 로드 밸런서가 요구 사항을 충족하지 못하는 시나리오에서 유용할 수 있습니다. 예를 들어 ELB에서 지원하지 않는 프로토콜을 사용하거나 사용자가 서버에 할당되는 방식을 완전히 제어해야 할 수 있습니다(예: 게임 시나리오에서는 게임 참가자가 일치하고 동일한 서버에 연결되었는지 확인해야 할 수 있습니다). 이 모델에서는 클라이언트가 직접 연결할 올바른 서버 끝점을 검색하는 방법이 필요합니다. DNS를 사용하여 해당 정보를 클라이언트에서 실행 중인 소프트웨어에 제공할 수 있습니다. 로드 밸런서가 없는 경우 상태 점검 메커니즘도 클라이언트 측에서 구현해야 합니다. 서버 가용성이 감지되면 애플리케이션 중단 없이 장치를 다른 서버에 다시 연결하도록 클라이언트 논리를 설계해야 합니다.
분산 처리
단일 컴퓨팅 리소스가 적시에 처리할 수 없는 모든 데이터를 매우 많은 양의 데이터 처리와 관련된 사례를 사용합니다. 분산 처리 접근 방식이 필요합니다. 태스크와 해당 데이터를 여러 개의 작은 작업 조각으로 나누어 계산 리소스 집합에서 병렬로 실행할 수 있습니다.
분산 처리 구현
오프라인 배치 작업은 AWS Batch, AWS Glue 및 Apache Hadoop과 같은 분산 데이터 처리 엔진을 사용하여 수평적으로 확장할 수 있습니다. AWS에서는 Amazon EMR을 사용하여 운영상의 복잡성 없이 EC2 인스턴스(instance)를 기반으로 Hadoop 워크로드를 실행할 수 있습니다. 스트리밍 데이터의 실시간 처리를 위해 Amazon Kinesis는 여러 개의 파드로 데이터를 분할하여 여러 Amazon EC2 또는 AWS Lambda 리소스가 데이터를 사용하여 확장성을 달성합니다.
이러한 워크로드 유형에 대한 자세한 내용은 AWS의 빅 데이터 분석 옵션 및 IoT 백서의 핵심 테넌트를 참조하시기 바랍니다.
고정 서버 대신 일회용 자원
기존 인프라 환경에서는 새로운 하드웨어를 도입하는 데 드는 초기 비용과 소요 시간 때문에 고정된 리소스로 작업해야 합니다. 이 드라이브는 수동으로 서버에 로그인하여 소프트웨어를 구성하거나 문제를 해결하고, IP 주소를 하드코딩하며, 테스트 또는 처리 작업을 순차적으로 실행하는 등의 작업을 수행합니다.
AWS를 위해 설계할 때 클라우드 컴퓨팅의 동적으로 프로비저닝된 특성을 활용할 수 있습니다. 서버 및 기타 구성 요소를 임시 리소스로 생각할 수 있습니다. 필요한 만큼만 실행할 수 있으며, 필요한 만큼만 사용할 수 있습니다.
고정 서버 및 장기 실행 서버의 또 다른 문제는 구성 드리프트입니다. 시간이 지남에 따라 변경 사항과 소프트웨어 패치가 적용되면 다양한 환경에서 테스트되지 않은 이기종 구성이 발생할 수 있습니다. 이 문제는 불변의 인프라 패턴으로 해결할 수 있습니다. 이 접근 방식을 사용하면 한 번 실행된 서버가 업데이트되지 않습니다. 대신 문제가 있거나 업데이트가 필요한 경우 문제 서버는 최신 구성을 가진 새 서버로 교체됩니다. 이를 통해 리소스는 항상 일관된(테스트 및 테스트) 상태를 유지할 수 있으며 롤백을 더 쉽게 수행할 수 있습니다. 이는 상태 비저장 아키텍처에서 더 쉽게 지원됩니다.
컴퓨팅 리소스 인스턴스화
새로운 환경을 테스트하기 위해 구축하거나, 추가 부하에 대처하기 위해 기존 시스템의 용량을 늘리더라도 구성 및 코드로 새 리소스를 수동으로 설정하지는 않을 것입니다. 긴 리드 타임을 방지하고 사람의 실수를 피하기 쉬운 자동화되고 반복 가능한 프로세스를 만드는 것이 중요합니다. 이를 달성하기 위한 몇 가지 방법이 있습니다.
부트스트래핑
EC2 인스턴스 또는 Amazon RDS(Amazon Relational Database Service) DB 인스턴스와 같은 AWS 리소스를 시작하면 기본 구성으로 시작합니다. 그런 다음 자동 부트스트래핑 작업을 실행할 수 있습니다. 이 스크립트는 소프트웨어를 설치하거나 데이터를 복사하여 해당 리소스를 특정 상태로 전환하는 스크립트입니다. 여러 환경(예: 프로덕션 또는 테스트)에 따라 다른 구성 세부 정보를 매개 변수로 지정하여 수정 없이 동일한 스크립트를 재사용할 수 있습니다.
사용자 데이터 스크립트 및 클라우드 시작 명령을 사용하여 새 EC2 인스턴스를 설정할 수 있습니다. 간단한 스크립트 및 Chef 또는 Puppet과 같은 구성 관리 도구를 사용할 수 있습니다. 또한 사용자 지정 스크립트 및 AWS API 또는 AWS Lambda 지원 사용자 지정 리소스에 대한 AWS CloudFormation 지원을 사용하여 거의 모든 AWS 리소스에 작동하는 프로비저닝 논리를 작성할 수 있습니다.
골든 이미지
EC2 인스턴스, Amazon RDS DB 인스턴스, Amazon EBS(Amazon Elastic Block Store) 볼륨과 같은 특정 AWS 리소스 유형은 해당 리소스의 특정 상태의 스냅샷인 골든 이미지에서 시작할 수 있습니다. 부트스트래핑 방식과 비교할 때 골든 이미지는 시작 시간을 단축하고 구성 서비스 또는 타사 리포지토리에 대한 종속성을 제거합니다. 이는 수요 변화에 대응하여 추가 리소스를 신속하고 안정적으로 실행할 수 있는 자동 확장 환경에서 중요합니다.
EC2 인스턴스를 사용자 정의한 다음 AMI(Amazon Machine Image)를 생성하여 구성을 저장할 수 있습니다. AMI에서 원하는 만큼 인스턴스를 시작할 수 있으며 이러한 인스턴스에는 모두 사용자 지정이 포함됩니다. 구성을 변경할 때마다 새 골든 이미지를 생성해야 하므로 시간이 지남에 따라 골든 이미지를 관리하기 위한 버전 지정 규칙이 있어야 합니다. 스크립트를 사용하여 AMI를 생성하는 데 사용하는 EC2 인스턴스에 대한 부트스트랩을 생성하는 것이 좋습니다. 이렇게 하면 시간을 통해 영상을 테스트하고 수정할 수 있는 유연한 방법이 제공됩니다.
또는 기존 사내 가상화 환경이 있는 경우 AWS에서 VM 가져오기/내보내기 기능을 사용하여 다양한 가상화 형식을 AMI로 변환할 수 있습니다. 또한 AWS 또는 AWS Marketplace에서 제공하는 미리 작성된 공유 AMI를 찾아 사용할 수도 있습니다.
골든 이미지는 새로운 EC2 인스턴스를 시작할 때 가장 일반적으로 사용되지만 Amazon RDS DB 인스턴스나 Amazon EBS 볼륨과 같은 리소스에도 적용할 수 있습니다. 예를 들어 새 테스트 환경을 시작할 때 긴 SQL 스크립트에서 데이터를 가져오는 대신 특정 Amazon RDS 스냅샷에서 데이터베이스를 인스턴스화하여 데이터베이스를 미리 채울 수 있습니다.
컨테이너
개발자들에게 인기 있는 또 다른 옵션은 소프트웨어 컨테이너 안에 분산된 애플리케이션을 구축하고 배포할 수 있는 오픈 소스 기술인 Docker입니다. Docker를 사용하면 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 소프트웨어 개발에 필요한 모든 것을 포함하는 표준화된 장치인 Docker 이미지로 소프트웨어 조각을 패키징할 수 있습니다. AWS Elastic Beanstalk, Amazon ECS(Amazon Elastic Container Service) 및 AWS Fargate를 사용하면 EC2 인스턴스 클러스터 전체에 여러 컨테이너를 배포하고 관리할 수 있습니다. Golden Docker 영상을 빌드하고 ECS Container Registry를 사용하여 관리할 수 있습니다.
대안적인 컨테이너 환경은 쿠버넷(Amazon EKS)을 위한 쿠버넷과 Amazon Elastic Container Service입니다. 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: 이 서비스를 사용하여 Java에서 개발한 웹 애플리케이션 및 서비스를 배포하고 확장할 수 있습니다. Apache, Nginx, Passer 및 IIS. 개발자는 애플리케이션 코드를 업로드하기만 하면 되며, 이 서비스는 리소스 프로비저닝, 로드 밸런싱, 자동 확장 및 모니터링과 같은 모든 세부 정보를 자동으로 처리합니다.
Amazon EC2 auto recovery: EC2 인스턴스를 모니터링하고 손상된 경우 자동으로 복구하는 Amazon CloudWatch 경보를 생성할 수 있습니다. 복구된 인스턴스는 인스턴스 ID, 개인 IP 주소, Elastic IP 주소 및 모든 인스턴스 메타데이터를 포함하여 원래 인스턴스와 동일합니다. 그러나 이 기능은 적용 가능한 인스턴스 구성에만 사용할 수 있습니다. 이러한 전제 조건에 대한 최신 설명은 Amazon EC2 설명서를 참조합니다. 또한 인스턴스 복구 중에 인스턴스가 인스턴스 재부팅을 통해 마이그레이션되고 메모리에 있는 모든 데이터가 손실됩니다.
AWS Systems Manager: 소프트웨어 인벤토리를 자동으로 수집하고, OS 패치를 적용하고, 윈도우즈 및 리눅스 운영 체제를 구성할 시스템 이미지를 생성하고, 임의 명령을 실행할 수 있습니다. 이러한 서비스를 프로비저닝하면 운영 모델이 단순화되고 최적의 환경 구성이 보장됩니다.
Auto Scaling: 정의한 조건에 따라 자동으로 Amazon EC2, Amazon DynamoDB, Amazon ECS, Cubernetes용 Amazon Elastic Container Service(Amazon EKS) 용량을 위 또는 아래로 확장할 수 있습니다. 자동 확장을 사용하여 여러 가용성 영역에서 원하는 수의 정상 EC2 인스턴스를 실행하고 있는지 확인할 수 있습니다. 또한 자동 확장은 수요 급증 시 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 시스템이 더 작고 느슨하게 결합된 구성 요소로 분리될 수 있다는 것입니다. 즉, IT 시스템은 상호의존성을 줄이는 방식으로 설계되어야 합니다. 즉, 한 구성 요소의 변경 또는 장애는 다른 구성 요소에 영향을 미치지 않아야 합니다.
잘 정의 된 인터페이스
시스템에서 상호의존성을 줄이는 방법은 RESTful API와 같은 특정 기술 관련 인터페이스를 통해서만 다양한 구성 요소가 상호 작용할 수 있도록 하는 것입니다. 이렇게 하면 팀이 다른 구성 요소에 영향을 주지 않고 기본 구현을 수정할 수 있도록 기술 구현 세부 정보가 숨겨집니다. 이러한 인터페이스가 이전 버전과의 호환성을 유지하는 한 서로 다른 구성 요소의 배포는 분리됩니다. 이러한 세분화된 설계 패턴을 일반적으로 마이크로 서비스 아키텍처라고 합니다.
Amazon API Gateway는 개발자가 어떤 규모로든 API를 생성, 게시, 유지, 모니터링 및 보안할 수 있도록 하는 완전 관리 서비스입니다. 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링 및 API 버전 관리를 포함하여 최대 수십만 개의 동시 API 호출을 수신 및 처리하는 데 관련된 모든 작업을 처리합니다.
서비스 검색
소규모 서비스 집합으로 배포되는 애플리케이션은 이러한 서비스의 상호 작용 능력에 따라 달라집니다. 이러한 각 서비스는 여러 컴퓨팅 리소스에서 실행될 수 있으므로 각 서비스를 해결할 수 있는 방법이 필요합니다. 예를 들어 기존 인프라에서 프런트 엔드 웹 서비스를 백엔드 웹 서비스와 연결해야 하는 경우 이 서비스가 실행 중인 계산 리소스의 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 Service와 같은 중간 내구 스토리지 계층을 통해 통합됩니다.
이 접근 방식은 두 구성 요소를 분리하고 추가적인 복원력을 제공합니다. 예를 들어, 대기열에서 메시지를 읽는 프로세스가 실패하더라도, 메시지는 여전히 대기열에 추가되고 시스템이 복구될 때 처리될 수 있습니다. 또한 프런트 엔드 급증으로부터 확장성이 떨어지는 백엔드 서비스를 보호하고 비용과 처리 지연 간의 적절한 균형을 찾을 수 있습니다. 예를 들어, 약간의 지연과 함께 비동기식으로 쿼리를 처리하는 한, 때때로 최대 쓰기 쿼리를 수용하기 위해 데이터베이스를 확장할 필요가 없다고 결정할 수 있습니다. 마지막으로 대화형 요청 경로에서 느린 작업을 제거하여 최종 사용자 환경을 개선할 수도 있습니다.
비동기 통합의 예는 다음과 같습니다.
- 프런트 엔드 응용 프로그램은 Amazon SQS와 같은 대기열 시스템에 작업을 삽입합니다. 백엔드 시스템은 이러한 작업을 검색하여 자신의 속도로 처리합니다.
- API는 이벤트를 생성하여 Kinesis 스트림에 푸시합니다. 백엔드 애플리케이션은 이러한 이벤트를 일괄 처리하여 데이터베이스에 저장된 집계된 시계열 데이터를 생성합니다.
- 여러 이기종 시스템이 AWS Step Functions를 사용하여 서로 직접 상호 작용하지 않고 AWS Step Function을 통해 작업 흐름을 전달합니다.
- Lambda 기능은 Amazon DynamoDB 업데이트 스트림 및 Amazon S3 이벤트 알림과 같은 다양한 AWS 소스의 이벤트를 사용할 수 있습니다. Lambda가 처리하므로 대기열 또는 기타 비동기 통합 방법을 구현하는 것에 대해 걱정할 필요가 없습니다.
분산 시스템 모범 사례
느슨한 커플링을 증가시키는 또 다른 방법은 구성 요소 고장을 우아하게 처리하는 애플리케이션을 구축하는 것입니다. 일부 구성 요소에 장애가 발생한 경우에도 최종 사용자에게 미치는 영향을 줄이고 오프라인 절차의 진행률을 높일 수 있는 방법을 식별할 수 있습니다.
연습에서의 실패
실패한 요청은 지수 백오프 및 지터 전략으로 다시 시도하거나 나중에 처리하기 위해 대기열에 저장할 수 있습니다. 프런트 엔드 인터페이스의 경우 데이터베이스 서버를 사용할 수 없게 되면 완전히 실패하는 대신 대체 콘텐츠 또는 캐시된 콘텐츠를 제공할 수 있습니다. 또한 Amazon Route 53 DNS 페일오버 기능을 통해 웹 사이트를 모니터링하고 주 사이트를 사용할 수 없는 경우 자동으로 방문자를 백업 사이트로 라우팅할 수 있습니다. 백업 사이트를 Amazon S3에서 정적 웹 사이트 또는 별도의 동적 환경으로 호스트할 수 있습니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
