[ 고지 사항 (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.
Services, Not Servers
특히 대규모로 응용 프로그램을 개발, 관리 및 운영하려면 다양한 기본 기술 구성 요소가 필요합니다. 전통적인 IT 인프라를 통해 기업은 이러한 모든 구성 요소를 구축하고 운영해야 했습니다.
AWS는 조직이 더 빠르고 IT 비용을 절감 할 수 있도록 광범위한 컴퓨팅, 스토리지, 데이터베이스, 분석, 애플리케이션 및 배포 서비스를 제공합니다.
이러한 폭을 활용하지 않는 아키텍처 (예 : Amazon EC2 만 사용하는 경우)는 클라우드 컴퓨팅을 최대한 활용하지 못하고 개발자 생산성 및 운영 효율성을 높일 수있는 기회가 없을 수 있습니다.
Managed Services
AWS 관리 형 서비스는 개발자가 애플리케이션을 구동하기 위해 사용할 수있는 빌딩 블록을 제공합니다. 이러한 관리 서비스에는 데이터베이스, 기계 학습, 분석, 대기열, 검색, 전자 메일, 알림 등이 포함됩니다. 예를 들어 Amazon SQS를 사용하면 고 가용성 메시징 클러스터의 운영 및 확장에 따른 관리 부담을 덜고 사용하는 것만 저렴한 가격으로 지불 할 수 있습니다. Amazon SQS는 본질적으로 확장 가능하고 안정적입니다. 용량, 하드 디스크 구성, 복제 및 기타 관련 문제를 고려할 필요없이 원하는만큼 데이터를 저장하고 필요할 때 액세스 할 수있는 Amazon S3에도 동일하게 적용됩니다.
응용 프로그램을 강화하는 관리 서비스의 다른 예는 다음과 같습니다.
· Amazon CloudFront for content delivery
· ELB for load balancing
· Amazon DynamoDB for NoSQL databases
· Amazon CloudSearch for search workloads
· Amazon Elastic Transcoder for video encoding
· Amazon Simple Email Service (Amazon SES) for sending and receiving email
Serverless Architectures
서버리스 아키텍처는 애플리케이션 실행의 운영 복잡성을 줄일 수 있습니다. 서버 인프라를 관리하지 않고도 모바일, 웹, 분석, CDN 비즈니스 로직 및 IoT를위한 이벤트 중심 및 동기식 서비스를 모두 구축 할 수 있습니다.
이러한 아키텍처는 활용률이 낮은 서버를 관리하거나 비용을 지불하거나 고 가용성을 구현하기 위해 중복 인프라를 프로비저닝 할 필요가 없으므로 비용을 절감 할 수 있습니다.
예를 들어, 코드를 AWS Lambda 컴퓨팅 서비스에 업로드 할 수 있으며 서비스는 AWS 인프라를 대신하여 코드를 실행할 수 있습니다. AWS Lambda를 사용하면 코드가 100ms 실행되고 코드가 트리거 된 횟수마다 요금이 부과됩니다. Amazon API Gateway를 사용하면 AWS Lambda에서 제공하는 거의 무한대로 확장 가능한 동기 API를 개발할 수 있습니다. 정적 컨텐츠 자산을 제공하기 위해 Amazon S3와 결합하면이 패턴이 완전한 웹 애플리케이션을 제공 할 수 있습니다. 이 유형의 아키텍처에 대한 자세한 내용은 AWS Serverless Multi-Tier Architectures 백서를 참조하십시오.
모바일 및 웹 앱과 관련하여 Amazon Cognito를 사용하면 사용자 인증, 네트워크 상태, 스토리지 및 동기화를 처리하기 위해 백엔드 솔루션을 관리 할 필요가 없습니다. Amazon Cognito는 사용자의 고유 식별자를 생성합니다.
이러한 식별자는 액세스 정책에서 참조하여 사용자별로 다른 AWS 리소스에 대한 액세스를 활성화하거나 제한 할 수 있습니다. Amazon Cognito는 사용자에게 임시 AWS 자격 증명을 제공하여 디바이스에서 실행되는 모바일 애플리케이션이 AWS Identity and Access Management (IAM) 보호 AWS 서비스와 직접 상호 작용할 수 있도록 합니다. 예를 들어 IAM을 사용하면 S3 버킷의 폴더에 대한 액세스를 특정 최종 사용자로 제한 할 수 있습니다.
IoT 응용 프로그램의 경우 조직에서는 전통적으로 연결된 장치와 서비스 간의 통신을 처리하기 위해 자체 서버를 장치 게이트웨이로 제공, 운영, 확장 및 유지 관리해야 했습니다. AWS IoT는 운영 오버 헤드 없이 사용량에 따라 자동으로 확장되는 완전히 관리되는 디바이스 게이트웨이를 제공합니다.
서버리스 아키텍처는 또한 엣지 로케이션에서 반응 형 서비스를 실행할 수있게 해줍니다. AWS Lambda @ Edge를 사용하면 CloudFront 이벤트에 대한 응답으로 Amazon CloudFront 엣지 로케이션에서 Lambda 함수를 실행할 수 있습니다. 이를 통해 지연 시간이 짧은 솔루션의 패턴과 기본 애플리케이션을 변경하지 않고도 기능을 도입 할 수 있습니다.
데이터 분석의 경우 대량의 데이터에서 쿼리를 관리하려면 일반적으로 복잡한 인프라를 관리해야합니다. Amazon Athena는 표준 SQL을 사용하여 Amazon S3의 데이터를 쉽게 분석 할 수있는 대화식 쿼리 서비스입니다. Athena는 서버리스이므로 관리 할 인프라가 없으며 실행 한 쿼리에 대해서만 비용을 지불합니다.
데이터베이스
기존 IT 인프라에서는 조직에서 사용할 수 있는 데이터베이스 및 스토리지 기술에 국한되는 경우가 많습니다. 라이센스 비용과 다양한 데이터베이스 엔진을 지원하는 능력에 따라 제약이 있을 수 있습니다. AWS에서 이러한 제약 조건은 오픈 소스 비용으로 엔터프라이즈 성능을 제공하는 관리되는 데이터베이스 서비스에 의해 제거됩니다. 따라서 각 워크로드에 적합한 기술을 선택하는 polyglot 데이터 계층 위에서 애플리케이션을 실행하는 경우가 흔치 않습니다.
각 워크로드에 적합한 데이터베이스 기술 선택
다음 질문은 아키텍처에 포함 할 솔루션을 결정하는 데 도움이 될 수 있습니다.
· 읽기, 쓰기 또는 균형 잡힌 작업입니까? 초당 몇 번의 읽기 및 쓰기가 필요합니까? 사용자 수가 증가하면 이러한 값은 어떻게 변경됩니까?
· 얼마나 많은 데이터를 저장해야합니까? 얼마나 빨리 자 랄까요? 가까운 시일 내에 상한이 있습니까? 각 개체의 크기는 얼마입니까 (평균, 최소, 최대)? 이러한 개체에 어떻게 액세스합니까?
· 데이터 내구성 측면에서 요구 사항은 무엇입니까?
· 대기 시간 요구 사항은 무엇입니까? 몇 명의 동시 사용자를 지원해야합니까?
· 데이터 모델은 무엇이며 어떻게 데이터를 쿼리합니까? 쿼리가 본질적으로 관계가 있습니까 (예 : 여러 테이블 간의 JOIN)? 확장하기 쉬운 더 평평한 데이터 구조를 만들기 위해 스키마를 비정규화할 수 있습니까?
· 어떤 종류의 기능이 필요합니까? 강력한 무결성 제어가 필요합니까 아니면 더 많은 유연성 (예 : 스키마가없는 데이터 저장소)을 찾고 있습니까? 정교한 보고 또는 검색 기능이 필요하십니까? 개발자는 NoSQL보다 관계형 데이터베이스에 더 익숙합니까?
· 관련 데이터베이스 기술 라이센스 비용은 얼마입니까? 이러한 비용이 시간이 지남에 따라 애플리케이션 개발 투자, 스토리지 및 사용 비용을 고려합니까? 라이센스 모델이 예상되는 성장을 지원합니까? 오픈 소스 데이터베이스의 단순성과 비용 효율성을 얻기 위해 Amazon Aurora와 같은 클라우드 네이티브 데이터베이스 엔진을 사용할 수 있습니까?
관계형 데이터베이스
관계형 데이터베이스 (RDBS 또는 SQL 데이터베이스라고도 함)는 데이터를 테이블로 알려진 잘 정의 된 테이블 구조로 정규화 합니다. 이 구조는 행과 열로 구성됩니다. 강력한 쿼리 언어, 유연한 인덱싱 기능, 강력한 무결성 제어 및 여러 테이블의 데이터를 빠르고 효율적으로 결합 할 수 있는 기능을 제공합니다. Amazon RDS를 사용하면 친숙한 많은 데이터베이스 엔진을 지원하여 클라우드에서 관계형 데이터베이스를 쉽게 설정, 운영 및 확장 할 수 있습니다.
확장성
관계형 데이터베이스는 더 큰 Amazon RDS DB 인스턴스로 업그레이드하거나 더 빠른 스토리지를 추가하여 수직으로 확장 할 수 있습니다. 또한 동일한 하드웨어에서 실행되는 표준 MySQL에 비해 훨씬 높은 처리량을 제공하도록 설계된 데이터베이스 엔진인 Amazon Aurora를 사용해 보십시오. 읽기가 많은 애플리케이션의 경우 하나 이상의 읽기 전용 복제본을 생성하여 단일 DB 인스턴스의 용량 제약을 넘어 수평 적으로 확장 할 수도 있습니다.
읽기 전용 복제본은 비동기 적으로 복제되는 별도의 데이터베이스 인스턴스입니다. 결과적으로 복제 지연이 발생하고 일부 최신 트랜잭션이 누락 될 수 있습니다. 응용 프로그램 설계자는 약간 오래된 데이터에 대한 허용 오차가 있는 쿼리를 고려해야 합니다. 이러한 쿼리는 읽기 전용 복제본에서 실행될 수 있으며 나머지는 기본 노드에서 실행해야 합니다. 읽기 전용 복제본도 쓰기 쿼리를 수락 할 수 없습니다.
단일 DB 인스턴스의 제약 조건을 넘어서 쓰기 용량을 확장해야하는 관계형 데이터베이스 워크로드에는 데이터 파티셔닝 또는 샤딩이라는 다른 접근 방식이 필요합니다. 이 모델을 사용하면 데이터가 각각 자율적인 기본 DB 인스턴스에서 실행되는 여러 데이터베이스 스키마로 분할됩니다. Amazon RDS는 해당 인스턴스를 실행하는 데 따른 운영 오버 헤드를 제거하지만 샤딩은 애플리케이션에 약간의 복잡성을 초래합니다. 응용 프로그램의 데이터 액세스 계층은 올바른 인스턴스로 쿼리를 전달할 수 있도록 데이터가 분할되는 방식을 인식하도록 수정해야합니다. 또한 여러 데이터베이스 스키마에서 스키마 변경을 수행해야 하므로 이 프로세스를 자동화하기 위한 노력이 필요합니다.
고가용성
프로덕션 관계형 데이터베이스의 경우 다른 가용 영역에서 동기식으로 복제 된 대기 인스턴스를 생성하는 Amazon RDS 다중 AZ 배포 기능을 사용하는 것이 좋습니다. 기본 노드에 장애가 발생한 경우 Amazon RDS는 수동 관리 작업 없이 대기 모드로 자동 장애 조치를 수행합니다. 장애 조치가 수행되면 기본 노드에 액세스 할 수 없는 짧은 기간이 있습니다. 읽기 전용 복제본을 사용하여 읽기 전용 모드와 같은 기능이 줄어든 상태에서 복원 가능한 응용 프로그램을 정상 장애에 맞게 설계 할 수 있습니다. Amazon Aurora는 다중 마스터 기능을 제공하여 가용 영역에서 읽기 및 쓰기를 확장 할 수 있으며 리전 간 복제도 지원합니다.
Anti-Patterns
애플리케이션이 주로 조인이나 복잡한 트랜잭션없이 데이터를 인덱싱하고 쿼리하는 경우 (특히 단일 인스턴스의 제약 조건을 넘어서 쓰기 처리량이 필요한 경우) NoSQL 데이터베이스를 대신 고려하십시오. 큰 이진 파일 (오디오, 비디오 및 이미지)이 있는 경우 실제 파일을 Amazon S3에 저장하고 파일의 메타 데이터 만 데이터베이스에 보관하는 것이 더 효율적입니다.
관계형 데이터베이스 모범 사례에 대한 자세한 내용은 Amazon RDS 설명서를 참조하십시오.
NoSQL 데이테베이스
NoSQL 데이터베이스는 관계형 데이터베이스의 일부 쿼리 및 트랜잭션 기능을 가로로 확장하는 보다 유연한 데이터 모델로 교환합니다. NoSQL 데이터베이스는 그래프, 키-값 쌍 및 JSON 문서를 포함한 다양한 데이터 모델을 사용하며 개발 용이성, 확장 가능한 성능, 고 가용성 및 복원력으로 널리 인식됩니다. Amazon DynamoDB는 모든 규모에서 일관된 단일 자릿수 밀리 초 대기 시간이 필요한 애플리케이션을위한 빠르고 유연한 NoSQL 데이터베이스 서비스입니다. 완전히 관리되는 클라우드 데이터베이스이며 문서 및 키-값 저장소 모델을 모두 지원합니다.
확장성
NoSQL 데이터베이스 엔진은 일반적으로 데이터 분할 및 복제를 수행하여 읽기 및 쓰기를 수평으로 확장합니다. 이들은 투명하게 수행하며 애플리케이션의 데이터 액세스 계층에 구현 된 데이터 파티셔닝 로직이 필요하지 않습니다. 특히 Amazon DynamoDB는 테이블 크기가 커지거나 읽기 프로비저닝 및 쓰기 프로비저닝 용량 변경에 따라 새 파티션을 추가하여 테이블 파티셔닝을 자동으로 관리합니다. DAX (Amazon DynamoDB Accelerator)는 DynamoDB가 성능을 크게 향상시키기 위해 관리되는 고가용성 인 메모리 캐시입니다.
애플리케이션을 설계 할 때 Amazon DynamoDB 확장 성을 최대한 활용하는 방법에 대한 자세한 내용은 DynamoDB 모범 사례를 참조하십시오.
고가용성
Amazon DynamoDB는 AWS 리전의 3개 시설에서 데이터를 동기식으로 복제하여 서버 장애 또는 가용 영역 중단 시 내결함성을 제공합니다. Amazon DynamoDB는 또한 글로벌 테이블을 지원하여 대규모로 확장 된 글로벌 애플리케이션을 위한 빠른 로컬, 읽기 및 쓰기 성능을 제공하는 완전히 관리되는 다중 리전, 다중 마스터 데이터베이스를 제공합니다. 글로벌 테이블은 선택한 AWS 리전간에 복제됩니다.
Anti-Patterns
스키마를 비정규화 할 수 없고 응용 프로그램에 조인 또는 복잡한 트랜잭션이 필요한 경우 관계형 데이터베이스를 대신 고려하십시오. 이진 파일 (오디오, 비디오 및 이미지)이 큰 경우 파일을 Amazon S3에 저장하고 파일의 메타 데이터를 데이터베이스에 저장하십시오.
관계형 데이터베이스에서 DynamoDB로 마이그레이션하거나 마이그레이션 할 워크로드를 평가하는 방법에 대한 지침은 RDBMS에서 DynamoDB로 마이그레이션하는 모범 사례 백서를 참조하십시오.
데이터 웨어하우스
데이터 웨어하우스는 많은 양의 데이터를 분석하고 보고하는 데 최적화 된 특수한 유형의 관계형 데이터베이스입니다. 웹 애플리케이션의 사용자 행동, 재무 및 청구 시스템의 데이터 또는 고객 관계 관리 또는 CRM과 같은 이종 소스의 트랜잭션 데이터를 결합하여 분석 및 의사 결정에 사용할 수 있습니다.
전통적으로 데이터웨어 하우스의 설정, 실행 및 확장은 복잡하고 비용이 많이 듭니다. AWS에서는 기존 솔루션 비용의 10 분의 1 이하로 운영되도록 설계된 관리형 데이터 웨어하우스 서비스 인 Amazon Redshift를 활용할 수 있습니다.
확장성
Amazon Redshift는 MPP (대규모 병렬 처리), 열 데이터 저장소 및 대상 데이터 압축 인코딩 체계를 결합하여 효율적인 스토리지와 최적의 쿼리 성능을 달성합니다. 매우 큰 데이터 세트에 대한 분석 및 고 워크로드에 특히 적합합니다. Amazon Redshift MPP 아키텍처를 사용하면 데이터 웨어하우스 클러스터의 노드 수를 늘려 성능을 향상시킬 수 있습니다. Amazon Redshift Spectrum을 사용하면 Amazon S3의 엑사 바이트 데이터에 대한 Amazon Redshift SQL 쿼리가 가능해 지므로 데이터를 로드 하거나 변환 할 필요 없이 데이터 웨어하우스의 로컬 디스크에 저장된 데이터를 넘어 비정형 데이터로 Amazon Redshift의 분석 기능을 확장 할 수 있습니다.
고 가용성
Amazon Redshift에는 데이터 웨어하우스 클러스터의 안정성을 향상시키는 여러 기능이 있습니다. 다중 노드 클러스터에 프로덕션 워크로드를 배포하여 노드에 기록 된 데이터가 클러스터 내의 다른 노드로 자동 복제되도록 하는 것이 좋습니다. 데이터는 Amazon S3에 지속적으로 백업됩니다. Amazon Redshift는 지속적으로 클러스터 상태를 모니터링하고 실패한 드라이브에서 데이터를 자동으로 복제하고 필요에 따라 노드를 교체합니다. 자세한 내용은 Amazon Redshift FAQ를 참조하십시오.
Anti-Patterns
Amazon Redshift는 SQL 기반 관계형 데이터베이스 관리 시스템 (RDBMS)이므로 다른 RDBMS 애플리케이션 및 비즈니스 인텔리전스 도구와 호환됩니다. Amazon Redshift는 OLTP (Online Transaction Processing) 기능을 포함하여 일반적인 RDBMS의 기능을 제공하지만 이러한 워크로드를 위해 설계된 것은 아닙니다. 일반적으로 한 번에 적은 수의 레코드에 대한 모든 열을 읽고 쓰는 것과 관련된 높은 동시성 워크로드를 예상하는 경우 대신 Amazon RDS 또는 Amazon DynamoDB 사용을 고려해야합니다.
검색
검색은 종종 쿼리와 혼동됩니다. 쿼리는 공식 데이터베이스 쿼리이며 특정 용어로 특정 데이터 세트를 처리합니다. 검색을 통해 정확하게 구조화되지 않은 데이터 세트를 쿼리 할 수 있습니다. 이러한 이유로 정교한 검색 기능이 필요한 응용 프로그램은 일반적으로 관계형 또는 NoSQL 데이터베이스의 기능을 능가합니다. 검색 서비스는 구조화 된 텍스트 형식과 자유 텍스트 형식을 모두 색인화하고 검색하는 데 사용할 수 있으며 사용자 정의 가능한 결과 순위 지정, 필터링, 동의어 및 형태소 분석과 같은 다른 데이터베이스에서는 사용할 수 없는 기능을 지원할 수 있습니다.
AWS에서는 Amazon CloudSearch와 Amazon Elasticsearch Service (Amazon ES) 중에서 선택할 수 있습니다. Amazon CloudSearch는 구성이 거의 필요 없고 자동으로 확장되는 관리형 서비스입니다. Amazon ES는 오픈 소스 API를 제공하며 구성 세부 정보를 보다 강력하게 제어 할 수 있습니다. Amazon ES는 단순한 검색 솔루션 그 이상으로 발전했습니다. 로그 분석, 실시간 애플리케이션 모니터링 및 클릭 스트림 분석과 같은 사용 사례를 위한 분석 엔진으로 자주 사용됩니다.
확장성
Amazon CloudSearch와 Amazon ES는 모두 데이터 분할 및 복제를 사용하여 수평으로 확장합니다. 차이점은 Amazon CloudSearch를 사용하면 서비스가 자동으로 처리하므로 필요한 파티션 및 복제본 수에 대해 걱정할 필요가 없다는 것입니다.
고 가용성
Amazon CloudSearch와 Amazon ES에는 가용 영역에 걸쳐 데이터를 중복 저장하는 기능이 포함되어 있습니다. 자세한 내용은 Amazon CloudSearch 및 Amazon ES 설명서를 참조하십시오.
그래프 데이터베이스
그래프 데이터베이스는 쿼리에 그래프 구조를 사용합니다. 그래프는 스토어의 노드 (데이터 엔티티)와 직접 관련된 에지 (관계)로 구성됩니다. 관계를 통해 스토어의 데이터를 직접 서로 연결할 수 있으므로 관계형 시스템에서 복잡한 계층 구조를 신속하게 검색 할 수 있습니다. 이러한 이유로, 그래프 데이터베이스는 관계를 저장하고 탐색하기 위해 의도적으로 구축되며 일반적으로 소셜 네트워킹, 추천 엔진 및 사기 탐지와 같은 사용 사례에 사용되며 데이터 간의 관계를 만들고 이러한 관계를 신속하게 쿼리 할 수 있어야합니다.
Amazon Neptune은 완전 관리형 그래프 데이터베이스 서비스입니다. 자세한 내용은 Amazon Neptune FAQ를 참조하십시오.
확장성
Amazon Neptune은 그래프 쿼리 처리에 최적화 된 특수 목적의 고성능 그래프 데이터베이스입니다.
고 가용성
Amazon Neptune은 읽기 전용 복제본, 특정 시점 복구, Amazon S3 로의 지속적인 백업 및 가용 영역 전체의 복제 기능을 통해 고 가용성을 제공합니다. Neptune은 저장 및 전송시 암호화를 지원하여 안전합니다.
증가하는 데이터 양 관리
기존의 데이터 스토리지 및 분석 도구는 더 이상 관련 비즈니스 통찰력을 제공하는 데 필요한 민첩성과 유연성을 제공 할 수 없습니다. 그렇기 때문에 많은 조직에서 데이터 레이크 아키텍처로 전환하고 있습니다. 데이터 레이크는 대량의 데이터를 중앙 위치에 저장하여 조직 내 다양한 그룹에서 분류, 처리, 분석 및 소비 할 수 있도록하 는 아키텍처 접근 방식입니다. 데이터는 있는 그대로 저장 될 수 있으므로 미리 정의 된 스키마로 변환 할 필요가 없으며 더 이상 데이터에 대해 어떤 질문을 해야하는지 알 필요가 없습니다. 이를 통해 특정 분석 요구 사항에 맞는 올바른 기술을 선택할 수 있습니다. 자세한 내용은 Amazon Web Services로 데이터 레이크 구축 백서를 참조하십시오.
단일 실패 지점 제거
생산 시스템에는 일반적으로 가동 시간에 대한 정의되거나 암시적인 목표가 있습니다. 시스템은 개별 구성 요소 또는 하드 디스크, 서버 및 네트워크 링크와 같은 여러 구성 요소의 장애를 견딜 수 있을 때 가용성이 높습니다. 고 가용성 시스템을 작성하는 데 도움을 주기 위해 아키텍처의 모든 계층에서 복구를 자동화하고 중단을 줄이는 방법에 대해 생각할 수 있습니다. 고 가용성 디자인 패턴에 대한 자세한 내용은 결함 허용 애플리케이션 구축 백서를 참조하십시오.
이중화 소개
이중화을 도입하여 단일 실패 지점을 제거 할 수 있습니다. 이는 동일한 작업에 여러 리소스가 있음을 의미합니다. 이중화는 대기 또는 활성 모드로 구현 될 수 있습니다.
대기 이중화에서 리소스에 장애가 발생하면 장애 조치 프로세스를 통해 보조 리소스에서 기능이 복구됩니다. 장애 조치는 일반적으로 완료되기까지 약간의 시간이 필요하며 이 기간 동안 리소스를 사용할 수 없습니다. 보조 리소스는 필요할 때만 자동으로 시작되거나 (비용 절감) 이미 유휴 상태 (장애 조치를 가속화하고 중단을 최소화하기 위해)로 실행 중일 수 있습니다. 대기 이중화는 종종 관계형 데이터베이스와 같은 상태 저장 구성 요소에 사용됩니다.
활성 이중화에서는 요청이 여러 중복 컴퓨팅 리소스에 분산됩니다. 그중 하나가 실패하면 나머지는 단순히 많은 양의 작업 부하를 흡수 할 수 있습니다. 대기 이중화와 비교하여 활성 이중화는 더 나은 사용을 달성 할 수 있고 장애가 있을 때 더 적은 수의 사용자에게 영향을 줄 수 있습니다.
실패 감지
장애 감지 및 대응에 최대한 많은 자동화를 구축해야 합니다. ELB 및 Amazon Route 53과 같은 서비스를 사용하여 트래픽을 정상 엔드 포인트로 라우팅하여 상태 확인을 구성하고 장애를 마스크 할 수 있습니다. 또한 Auto Scaling을 사용하거나 AWS Elastic Beanstalk와 같은 Amazon EC2 자동 복구 기능 또는 서비스를 사용하여 비정상 노드를 자동으로 교체 할 수 있습니다 . 첫 번째 날에 가능한 모든 장애 시나리오를 예측할 수는 없습니다. 정상적인 시스템 동작을 이해하기에 충분한 로그와 메트릭을 수집하십시오. 이를 이해하면 수동 개입 또는 자동 응답에 대한 경보를 설정할 수 있습니다.
헬스체크 점검 디자인
애플리케이션에 대한 올바른 상태 점검을 구성하면 다양한 장애 시나리오에 정확하고 신속하게 대응할 수있는 능력을 결정하는 데 도움이됩니다. 잘못된 상태 확인을 지정하면 실제로 응용 프로그램의 가용성이 떨어질 수 있습니다.
일반적인 3 계층 응용 프로그램에서는 ELB에서 상태 확인을 구성합니다. 백엔드 노드의 상태를 안정적으로 평가하기 위해 상태 점검을 설계하십시오. 간단한 TCP 상태 확인은 인스턴스 자체는 정상이지만 웹 서버 프로세스가 충돌했는지 감지하지 않습니다. 대신 웹 서버가 간단한 요청에 대해 HTTP 200 응답을 반환 할 수 있는지 평가해야 합니다.
이 계층에서는 잘못된 상태 확인이 발생할 수 있으므로 응용 프로그램의 다른 계층에 따라 테스트하는 심층 상태 점검을 구성하는 것이 좋지 않을 수 있습니다. 예를 들어, 상태 확인에서 인스턴스가 백엔드 데이터베이스에 연결할 수 있는지 여부를 평가하는 경우 해당 데이터베이스 노드를 곧 사용할 수 없게 되면 모든 웹 서버를 비정상으로 표시 할 위험이 있습니다. 계층적 접근 방식이 가장 좋습니다. Amazon Route 53 수준에서 구현하기 위해서는 심층 상태 점검이 적절할 수 있습니다. 해당 환경에서 실제로 필요한 기능을 제공 할 수 있는지 확인하는 보다 전체적인 검사를 실행하면 데이터베이스가 다시 시작될 때까지 웹 사이트의 정적 버전으로 장애 조치되도록 Amazon Route 53을 구성 할 수 있습니다.
내구성 있는 데이터 저장
응용 프로그램과 사용자는 다양한 데이터를 만들고 유지 관리합니다. 아키텍처가 데이터 가용성과 무결성을 모두 보호하는 것이 중요합니다. 데이터 복제는 중복 데이터 사본을 도입하는 기술입니다. 읽기 용량을 수평으로 확장 할 수 있지만 데이터 내구성과 가용성이 향상됩니다. 복제는 몇 가지 다른 모드에서 발생할 수 있습니다.
동기식 복제는 트랜잭션이 기본 위치와 복제본 모두에 지속적으로 저장된 후에 만 승인합니다. 기본 노드 장애 시 데이터 무결성을 보호하는 데 이상적입니다. 동기식 복제는 최신 데이터가 필요한 쿼리에 대한 읽기 용량을 확장 할 수도 있습니다 (강한 일관성). 동기식 복제의 단점은 기본 노드가 복제본에 연결되어 있다는 것입니다. 모든 복제본이 쓰기를 수행하기 전에 트랜잭션을 승인 할 수 없습니다. 이는 특히 불안정하거나 대기 시간이 긴 네트워크 연결에서 실행되는 토폴로지에서 성능과 가용성을 떨어뜨릴 수 있습니다. 같은 이유로 많은 동기 복제본을 유지 관리하지 않는 것이 좋습니다.
솔루션의 내구성에 관계없이 백업을 대체하지 않습니다. 동기식 복제는 소프트웨어 버그나 사람의 실수로 인한 업데이트 일지라도 데이터에 대한 모든 업데이트를 중복 저장합니다. 그러나 특히 Amazon S3에 저장된 객체의 경우 버전 관리를 사용하여 해당 버전을 유지, 검색 및 복원 할 수 있습니다. 버전 관리를 사용하면 의도하지 않은 사용자 작업과 응용 프로그램 오류를 모두 복구 할 수 있습니다.
비동기식 복제는 복제 지연을 유발하여 기본 노드를 복제본에서 분리합니다. 이는 기본 노드의 변경 사항이 해당 복제본에 즉시 반영되지 않음을 의미합니다. 비동기 복제본은 해당 복제 지연을 허용 할 수 있는 쿼리에 대한 시스템의 읽기 용량을 수평으로 확장하는 데 사용됩니다. 또한 페일 오버 중에 최근 트랜잭션 손실이 허용 될 때 데이터 내구성을 높이는 데 사용될 수 있습니다. 예를 들어 재해 복구 솔루션으로 별도의 AWS 리전에서 데이터베이스의 비동기 복제본을 유지할 수 있습니다.
쿼럼 기반 복제는 동기식 및 비동기식 복제를 결합하여 대규모 분산 데이터베이스 시스템의 과제를 극복합니다.
성공적인 쓰기 작업에 참여해야하는 최소 수의 노드를 정의하여 여러 노드에 대한 복제를 관리 할 수 있습니다. 분산 데이터 저장소에 대한 자세한 설명은 이 문서의 범위를 벗어납니다. 분산 형 데이터 저장소 및 확장 성과 안정성이 뛰어난 데이터베이스 시스템의 핵심 원칙에 대한 자세한 내용은 Amazon Dynamo 백서를 참조하십시오.
사용중인 각 기술이 이러한 데이터 스토리지 모델에서 어디에 적합한 지 이해하는 것이 중요합니다. 다양한 장애 조치 또는 백업 / 복원 시나리오에서의 동작은 RPO (복구 지점 목표) 및 RTO (복구 시간 목표)와 일치해야 합니다. 손실 될 데이터의 양과 작업을 재개해야 하는 속도를 확인해야 합니다. 예를 들어 Amazon ElastiCache 용 Redis 엔진은 자동 장애 조치를 통한 복제를 지원하지만 Redis 엔진의 복제는 비동기식입니다. 장애 조치 (failover) 중에 일부 최근 트랜잭션이 손실 될 가능성이 높습니다. 그러나 다중 AZ 기능이 있는 Amazon RDS는 기본 노드와 함께 대기 노드의 데이터를 최신 상태로 유지하기 위해 동기식 복제를 제공하도록 설계되었습니다.
자동화 된 다중 데이터 센터 탄력성
업무상 중요한 응용 프로그램은 단일 디스크, 서버 또는 랙 이상에 영향을 미치는 중단 시나리오로부터 보호해야합니다. 기존 인프라에서는 일반적으로 주요 데이터 센터에 큰 장애가 발생하는 경우 원격 데이터 센터로 장애 조치를 수행 할 수있는 재해 복구 계획이 있습니다. 두 데이터 센터 사이의 거리가 멀기 때문에 대기 시간으로 인해 데이터의 데이터 간 동기 복제본을 유지하는 것이 비현실적입니다. 결과적으로 페일 오버는 데이터 손실 또는 비용이 많이 드는 데이터 복구 프로세스로 이어질 것입니다. 따라서 장애 조치가 위험하고 항상 충분히 테스트 된 절차는 아닙니다. 그럼에도 불구하고, 이것은 전체 인프라를 오랜 시간 동안 중단시키는 자연 재해와 같이 낮은 확률이지만 큰 충격 위험으로부터 탁월한 보호 기능을 제공하는 모델입니다. AWS에서이 접근 방식을 구현하는 방법에 대한 지침은 AWS Disaster Recovery 백서를 참조하십시오.
데이터 센터에서 중단이 짧을수록 시나리오가 더 쉽습니다. 장애 기간이 길지 않을 것으로 예상되는 짧은 중단의 경우 장애 조치를 수행하기 위한 선택이 어렵고 일반적으로 피해야합니다. AWS에서는 이러한 유형의 장애로부터보다 간단하고 효율적으로 보호 할 수 있습니다. 각 AWS 리 전에는 여러 개의 고유 한 위치 또는 가용 영역이 있습니다. 각 가용 영역은 다른 가용 영역의 장애와 독립적으로 설계되었습니다. 가용 영역은 데이터 센터이며, 경우에 따라 가용 영역은 여러 데이터 센터로 구성됩니다.
리전 내의 가용 영역은 동일한 리전의 다른 영역에 대한 저렴한 대기 시간이 짧은 네트워크 연결을 제공합니다. 이를 통해 데이터 센터간에 데이터를 동기 방식으로 복제 할 수 있으므로 장애 조치를 자동화하고 사용자에게 투명하게 할 수 있습니다.
활성 이중화를 구현할 수도 있습니다. 예를 들어, 여러 응용 프로그램 서버를 여러 가용 영역에 분산하여 ELB에 연결할 수 있습니다. 특정 가용 영역의 EC2 인스턴스가 상태 확인에 실패하면 ELB는 해당 노드로 트래픽 전송을 중지합니다. 또한 AWS Auto Scaling은 애플리케이션을 실행하고 수요에 따라 인스턴스를 시작 및 종료하고 스케일링 정책에 의해 정의 된 올바른 수의 EC2 인스턴스를 사용할 수 있도록 합니다. 가용 영역 장애로 인해 응용 프로그램에 단기 성능 저하가 필요하지 않은 경우 아키텍처는 정적으로 안정적이어야 합니다. 즉, 장애를 허용하기 위해 작업 부하 동작을 변경할 필요가 없습니다. 이 시나리오에서는 아키텍처가 가용 영역 하나의 손실을 견딜 수 있도록 초과 용량을 프로비저닝해야 합니다.
AWS의 많은 고급 서비스는 본질적으로 다중 가용 영역 (Multi-AZ) 원칙에 따라 설계되었습니다. 예를 들어 Amazon RDS는 다중 AZ 배포를 사용하여 DB 인스턴스에 대한 고 가용성 및 자동 장애 조치 지원을 제공하는 반면, Amazon S3 및 Amazon DynamoDB의 경우 데이터가 여러 시설에 중복 저장됩니다.
결함 분리 및 기존 수평 스케일링
활성 중복 패턴은 트래픽 균형 조정 및 인스턴스 또는 가용 영역 중단 처리에 적합하지만 요청 자체에 유해한 것이 있으면 충분하지 않습니다. 예를 들어 모든 인스턴스가 영향을 받는 시나리오가 있을 수 있습니다. 특정 요청으로 인해 시스템 장애 조치를 유발하는 버그가 발생하면 호출자는 모든 인스턴스에 대해 동일한 요청을 반복적으로 시도하여 계단식 오류를 트리거 할 수 있습니다.
셔플 샤딩
기존 수평 스케일링에 대해 하나의 결함 분리 개선을 샤딩이라고 합니다. 기술과 유사 전통적으로 당신은, 대신 모든 노드에 걸쳐 모든 고객의 트래픽을 확산의 데이터 스토리지 시스템 그룹 파편에 인스턴스 수 사용. 예를 들어 서비스에 대해 8 개의 인스턴스가 있는 경우 각각 2 개의 인스턴스로 4 개의 샤드 (각 샤드 내에서 중복성을 위한 2 개의 인스턴스)를 생성하고 각 고객을 특정 샤드에 배포 할 수 있습니다. 이러한 방법으로, 당신은 당신이 가진 파편의 수에 비례 고객에 미치는 영향을 줄일 수 있습니다. 그러나 일부 고객은 여전히 영향을 받으므로 클라이언트 내결함성을 만드는 것이 중요합니다. 하나가 성공할 때까지 클라이언트가 분산됩니다 자원 세트에 있는 모든 엔드 포인트를 시도 할 경우, 당신은 극적인 향상을 얻을. 이 기법에 대한 자세한 내용은 Shuffle Sharding: Massive and Magical Fault Isolation 블로그 게시물을 참조하시기 바랍니다.
비용 최적화
기존 아키텍처를 클라우드로 이동하면 AWS 규모의 경제로 인해 자본 비용을 절감하고 비용을 절감 할 수 있습니다. 더 많은 AWS 기능을 반복 사용하여 비용 최적화 된 클라우드 아키텍처를 생성 할 수있는 추가 기회를 실현할 수 있습니다. AWS 클라우드 컴퓨팅으로 비용을 최적화하는 방법에 대한 자세한 내용은 AWS를 통한 비용 최적화 백서를 참조하십시오.
Right Sizing
AWS는 많은 사용 사례를 위한 광범위한 리소스 유형 및 구성을 제공합니다. 예를 들어 Amazon EC2, Amazon RDS, Amazon Redshift 및 Amazon ES와 같은 서비스는 많은 인스턴스 유형을 제공합니다. 경우에 따라 워크로드 요구 사항에 맞는 가장 저렴한 유형을 선택해야 합니다. 다른 경우에는 더 큰 인스턴스 유형의 인스턴스를 적게 사용하면 총 비용이 줄어들거나 성능이 향상 될 수 있습니다. 워크로드가 CPU, RAM, 네트워크, 스토리지 크기 및 I / O를 사용하는 방식에 따라 애플리케이션 환경을 벤치마킹하고 올바른 인스턴스 유형을 선택해야합니다.
마찬가지로 필요에 맞는 스토리지 솔루션을 선택하여 비용을 절감 할 수 있습니다. 예를 들어 Amazon S3는 Standard, Reduced Redundancy 및 Standard-Infrequent Access를 포함한 다양한 스토리지 클래스를 제공합니다. Amazon EC2, Amazon RDS 및 Amazon ES와 같은 다른 서비스는 평가해야 할 다양한 EBS 볼륨 유형 (자기, 범용 SSD, 프로비저닝 된 IOPS SSD)을 지원합니다.
시간이 지남에 따라 지속적인 모니터링 및 태깅을 통해 비용을 계속 절감 할 수 있습니다. 응용 프로그램 개발과 마찬가지로 비용 최적화는 반복적인 프로세스입니다. 애플리케이션과 그 사용량은 시간이 지남에 따라 발전하고 AWS는 반복적으로 정기적으로 새로운 옵션을 출시하므로 솔루션을 지속적으로 평가하는 것이 중요합니다.
AWS는 비용 절감 기회를 파악하고 리소스의 규모를 적절하게 유지하는 데 도움이되는 도구를 제공합니다. 이러한 도구의 결과를 쉽게 해석하려면 AWS 리소스에 대한 태깅 정책을 정의하고 구현해야합니다. AWS Elastic Beanstalk 및 AWS OpsWorks와 같은 AWS 관리 도구를 사용하여 빌드 프로세스의 일부에 태그를 지정하고 자동화 할 수 있습니다. AWS Config에서 제공하는 관리 규칙을 사용하여 특정 태그가 리소스에 적용되는지 여부를 평가할 수 있습니다.
탄력성
AWS로 비용을 절감 할 수있는 또 다른 방법은 플랫폼의 탄력성을 활용하는 것입니다. 가능한 한 많은 Amazon EC2 워크로드에 대해 Auto Scaling을 구현하여 필요할 때 수평으로 확장하고 더 이상 용량이 필요하지 않을 때 지출을 자동으로 줄 이도록 계획하십시오. 또한 사용하지 않을 때 비 프로덕션 워크로드를 자동화 할 수 있습니다 . 궁극적으로 유휴 또는 중복 리소스에 대한 비용을 지불하지 않도록 AWS Lambda에서 구현할 수 있는 컴퓨팅 워크로드를 고려하십시오.
가능한 경우 Amazon EC2 워크로드를 용량 결정을 요구하지 않는 AWS 관리 서비스 (예 : ELB, Amazon CloudFront, Amazon SQS, Amazon Kinesis Firehose, AWS Lambda, Amazon SES, Amazon CloudSearch 또는 Amazon EFS)로 교체 하십시오. ) 또는 필요 할 때 (예 : Amazon DynamoDB, Amazon RDS 또는 Amazon ES) 용량을 쉽게 수정할 수 있습니다.
다양한 구매 옵션 활용
Amazon EC2 온 디맨드 인스턴스 요금은 장기 약정 없이 최대한의 유연성을 제공합니다. 지출을 줄이는 데 도움이 되는 다른 두 EC2 인스턴스는 예약 인스턴스와 스팟 인스턴스입니다.
예약 인스턴스
Amazon EC2 예약 인스턴스를 사용하면 온 디맨드 인스턴스 요금에 비해 시간당 요금이 크게 할인되는 대가로 Amazon EC2 컴퓨팅 용량을 예약 할 수 있습니다. 이는 최소 용량 요구 사항이 예측 가능한 응용 분야에 이상적입니다. AWS Trusted Advisor 또는 Amazon EC2 사용 보고서와 같은 도구를 활용하여 가장 자주 사용하고 예약을 고려해야하는 컴퓨팅 리소스를 식별 할 수 있습니다. 예약 인스턴스 구매에 따라 할인이 월별 청구서에 반영됩니다. 온 디맨드 EC2 인스턴스와 예약 인스턴스 간에는 기술적으로 차이가 없습니다. 차이점은 예약 한 인스턴스에 대해 지불하는 방식에 있습니다.
다른 서비스 (예 : Amazon Redshift, Amazon RDS, Amazon DynamoDB 및 Amazon CloudFront)에도 예약 된 용량 옵션이 있습니다.
Tip: 프로덕션 환경에서 애플리케이션을 충분히 벤치마킹하기 전에 예약 인스턴스 구매에 집중해서는 안됩니다. 예약 용량을 구매 한 후 예약 인스턴스 사용률 보고서를 사용하여 예약 용량을 최대한 활용하고 있는지 확인할 수 있습니다.
스팟 인스턴스
보다 안정적인 워크로드를 위해서는 스팟 인스턴스 사용을 고려하십시오. Amazon EC2 스팟 인스턴스를 사용하면 여분의 Amazon EC2 컴퓨팅 용량을 사용할 수 있습니다. 스팟 인스턴스는 온 디맨드 요금에 비해 할인 된 가격으로 제공되는 경우가 많으므로 애플리케이션 실행 비용을 크게 줄일 수 있습니다.
스팟 인스턴스를 사용하면 사용하지 않는 EC2 인스턴스를 요청할 수 있으므로 Amazon EC2 비용을 크게 줄일 수 있습니다. 스팟 인스턴스 (각 가용 영역의 각 인스턴스 유형)에 대한 시간당 요금은 Amazon EC2에 의해 설정되며 스팟 인스턴스의 장기 공급 및 수요에 따라 점진적으로 조정됩니다. 스팟 인스턴스는 용량이 사용 가능하고 요청에 대한 시간당 최대 가격이 스팟 가격을 초과 할 때마다 실행됩니다.
결과적으로 스팟 인스턴스는 중단을 허용 할 수 있는 워크로드에 적합합니다. 그러나 더 예측 가능한 가용성이 필요한 경우 스팟 인스턴스를 사용할 수도 있습니다. 예를 들어, 예약, 주문형 및 스팟 인스턴스를 결합하여 스팟 시장 가격에 따라 예측 가능한 최소 용량과 추가 컴퓨팅 리소스에 대한 기회 적 액세스를 결합 할 수 있습니다. 이는 처리량 또는 응용 프로그램 성능을 향상시키는 훌륭하고 비용 효율적인 방법입니다.
캐싱
캐싱은 나중에 사용하기 위해 이전에 계산 된 데이터를 저장하는 기술입니다. 이 기술은 응용 프로그램 성능을 향상시키고 구현의 비용 효율성을 높이는 데 사용됩니다. IT 아키텍처의 여러 계층에 적용 할 수 있습니다.
응용 프로그램 데이터 캐싱
애플리케이션은 빠르고 관리되는 인 메모리 캐시에서 정보를 저장하고 검색하도록 설계 할 수 있습니다. 캐시 된 정보에는 I/O 집약적인 데이터베이스 쿼리 결과 또는 계산 집약적인 처리 결과가 포함될 수 있습니다. 캐시에서 결과 집합을 찾을 수 없는 경우 응용 프로그램은 결과 집합을 계산하거나 데이터베이스에서 값이 비싸거나 고가의 타사 콘텐츠를 느리게 변경하여 후속 요청을 위해 캐시에 저장할 수 있습니다. 그러나 캐시에서 결과 세트가 발견되면 애플리케이션이 해당 결과를 직접 사용할 수 있으므로 최종 사용자의 대기 시간이 개선되고 백엔드 시스템의 로드가 줄어 듭니다. 애플리케이션은 각 캐시 된 항목이 유효한 시간을 제어 할 수 있습니다. 경우에 따라 매우 인기있는 개체에 대해 몇 초간 캐싱을 해도 데이터베이스로드가 크게 감소 할 수 있습니다.
Amazon ElastiCache는 클라우드에서 메모리 내 캐시를 쉽게 배포, 운영 및 확장 할 수있는 웹 서비스입니다. Memcached와 Redis의 두 가지 오픈 소스 인 메모리 캐싱 엔진을 지원합니다. 일반적인 ElastiCache 디자인 패턴에 대한 설명뿐만 아니라 워크로드에 적합한 엔진을 선택하는 방법에 대한 자세한 내용은 Amazon ElastiCache를 사용한 대규모 성능 백서를 참조하십시오.
Amazon DynamoDB Accelerator (DAX)는 DynamoDB를위한 완전 관리형 고 가용성 인 메모리 캐시로 높은 처리량을 위해 밀리 초에서 마이크로 초까지의 성능 향상을 제공합니다. DAX는 캐시 무효화, 데이터 수집 또는 클러스터 관리를 관리하지 않고도 DynamoDB 테이블에 인 메모리 가속화를 추가합니다.
엣지 캐싱
정적 콘텐츠 (이미지, CSS 파일 또는 스트리밍 사전 녹화 비디오)와 동적 콘텐츠 (응답 HTML, 라이브 비디오)의 사본은 Amazon CloudFront 엣지 로케이션에 캐시 할 수 있습니다. 이 위치는 전 세계에 여러 지점이 있는 CDN입니다. 엣지 캐싱을 사용하면 시청자에게 더 가까운 인프라에서 컨텐츠를 제공 할 수 있으므로 대기 시간이 줄어들고 최종 사용자에게 대규모의 인기있는 객체를 대규모로 제공하는 데 필요한 높은 지속 데이터 전송 속도가 제공됩니다.
콘텐츠 요청은 지능적으로 Amazon S3 또는 오리진 서버로 라우팅됩니다. 오리진이 AWS에서 실행중인 경우 요청은보다 안정적이고 일관된 환경을 위해 최적화 된 네트워크 경로를 통해 전송됩니다. Amazon CloudFront를 사용하여 캐시 할 수 없는 콘텐츠를 포함한 전체 웹 사이트를 제공 할 수 있습니다. 이 경우 이점은 Amazon CloudFront가 Amazon CloudFront 엣지와 오리진 서버 간의 기존 연결을 재사용하여 각 오리진 요청에 대한 연결 설정 대기 시간을 단축한다는 것입니다. 인터넷 병목 현상을 피하고 가장자리 위치와 뷰어 사이의 가용 대역폭을 완전히 사용하기 위해 다른 연결 최적화도 적용됩니다. 즉, Amazon CloudFront는 동적 콘텐츠를 신속하게 제공하고 웹 애플리케이션을 탐색 할 때 시청자에게 일관되고 안정적이지만 개인화 된 경험을 제공 할 수 있습니다. Amazon CloudFront는 또한 동적 콘텐츠 다운로드 요청에 적용된 것과 동일한 성능 이점을 요청을 업로드합니다.
보안
기존 IT 인프라에서 이미 잘 알고있는 대부분의 보안 도구와 기술을 클라우드에서 사용할 수 있습니다. 동시에 AWS를 사용하면 다양한 방식으로 보안을 향상시킬 수 있습니다. AWS는 플랫폼 자체의 보안 제어 설계를 공식화 할 수있는 플랫폼입니다. 관리자 및 IT 부서의 시스템 사용을 단순화하고 지속적으로 환경을 훨씬 쉽게 감사 할 수 있습니다. AWS에서와 AWS 보안 모범 사례 백서 : 보안 거버넌스의 높은 수준을 달성 할 수 있는 방법에 대하여 스케일의 보안을 참조하십시오.
심층 방어를 위한 AWS 기능 사용
AWS는 심층 방어 방법을 갖춘 아키텍처를 구축하는 데 도움이 되는 많은 기능을 제공합니다. 네트워크 수준에서 시작하여 서브넷, 보안 그룹 및 라우팅 제어를 통해 인프라의 일부를 격리하는 VPC 토폴로지를 구축 할 수 있습니다. 웹 애플리케이션 방화벽 인 AWS WAF와 같은 서비스는 SQL 주입 및 애플리케이션 코드의 기타 취약점으로부터 웹 애플리케이션을 보호 할 수 있습니다. 액세스 제어를 위해 IAM을 사용하여 세부적인 정책 세트를 정의하고이를 사용자, 그룹 및 AWS 리소스에 할당 할 수 있습니다. 마지막으로 AWS 클라우드는 전송 중이 든 암호화를 사용하여 데이터를 보호하는지에 대한 많은 옵션을 제공합니다. 사용 가능한 모든 AWS 보안 기능에 대한 자세한 내용은 AWS 웹 사이트의 AWS Cloud Security 페이지를 참조하십시오.
AWS와 보안 책임 공유
AWS는 공유 보안 책임 모델에 따라 운영됩니다. AWS는 기본 클라우드 인프라의 보안을 책임지고 귀하는 AWS에 배포 한 워크로드를 보호 할 책임이 있습니다. 이를 통해 AWS 관리 서비스를 통해 책임 범위를 줄이고 핵심 역량에 집중할 수 있습니다. 예를 들어 Amazon RDS 및 Amazon ElastiCache와 같은 서비스를 사용하면 보안 패치가 구성 설정에 자동으로 적용됩니다. 이렇게 하면 팀의 운영 오버 헤드가 줄어들뿐만 아니라 취약점에 대한 노출도 줄일 수 있습니다.
권한있는 액세스 감소
서버가 프로그래밍 가능한 리소스인 경우 많은 보안 이점이 있습니다. 필요할 때마다 서버를 변경하는 기능을 통해 게스트 운영 체제가 프로덕션 환경에 액세스 할 필요가 없습니다. 인스턴스에 문제가 발생하면 자동 또는 수동으로 종료하고 교체 할 수 있습니다.
그러나 인스턴스를 교체하기 전에 개발 환경에서 문제를 다시 생성하고 지속적인 배포 프로세스를 통해 수정 사항으로 배포하는 데 도움이 되는 로그 데이터를 수집하고 중앙에 저장해야 합니다. 이 방법을 사용하면 로그 데이터가 문제 해결을 지원하고 보안 이벤트에 대한 인식을 높일 수 있습니다. 이는 서버가 임시적인 탄력적 컴퓨팅 환경에서 특히 중요합니다. Amazon CloudWatch Logs를 사용하여 이 정보를 수집 할 수 있습니다. 직접 액세스 할 수 없는 경우 AWS Systems Manager와 같은 서비스를 구현하여 통합 된 보기를 수행하고 리소스 그룹에 대한 작업을 자동화 할 수 있습니다. 이러한 요청을 시스템과 통합하여 승인 후에만 액세스 요청을 추적하고 동적으로 처리 할 수 있습니다.
또 다른 일반적인 보안 위험은 저장된 장기 자격 증명 또는 서비스 계정을 사용하는 것입니다. 기존 환경에서 서비스 계정에는 종종 구성 파일에 저장된 장기 자격 증명이 할당됩니다. AWS에서는 대신 IAM 역할을 사용하여 자동으로 배포 및 순환되는 단기 자격 증명을 사용하여 EC2 인스턴스에서 실행되는 애플리케이션에 권한을 부여 할 수 있습니다. 모바일 애플리케이션의 경우 Amazon Cognito를 사용하여 클라이언트 디바이스가 세분화 된 권한으로 임시 토큰을 통해 AWS 리소스에 액세스 할 수 있습니다. AWS Management Console 사용자는 AWS 계정에서 IAM 사용자를 생성하는 대신 임시 토큰을 통해 페더레이션 액세스를 제공 할 수 있습니다. 그런 다음 직원이 조직을 떠나 조직의 자격 증명 디렉토리에서 제거되면 해당 직원도 자동으로 AWS 계정에 액세스 할 수 없게 됩니다.
코드 보안
기존의 보안 프레임 워크, 규정 및 조직 정책은 방화벽 규칙, 네트워크 액세스 제어, 내부 / 외부 서브넷 및 운영 체제 강화와 같은 항목과 관련된 보안 요구 사항을 정의합니다. AWS 환경에서도 이러한 기능을 구현할 수 있지만 이제는 골든 환경을 정의하는 템플릿에서 이를 모두 캡처 할 수 있습니다. 이 템플릿은 AWS CloudFormation에서 사용되며 보안 정책에 따라 리소스를 배포합니다.
지속적인 통합 파이프 라인의 일부로 여러 프로젝트에서 보안 모범 사례를 재사용 할 수 있습니다. 릴리스 주기의 일부로 보안 테스트를 수행하고 응용 프로그램의 차이를 자동으로 발견하고 보안 정책에서 벗어날 수 있습니다.
또한 제어 및 보안을 강화하기 위해 AWS CloudFormation 템플릿을 제품으로 AWS 서비스 카탈로그로 가져올 수 있습니다. 이를 통해 리소스를 중앙에서 관리하여 일관된 거버넌스, 보안 및 규정 준수 요구 사항을 지원하는 동시에 사용자는 필요한 승인 된 IT 서비스 만 신속하게 배포 할 수 있습니다. 제품을 보고 수정할 수 있는 사람을 제어하기 위해 IAM 권한을 적용하고 제품에 특정 AWS 리소스를 배포 할 수 있는 방법을 제한하는 제약 조건을 정의합니다.
실시간 감사
안전을 유지하면서 빠르게 이동하려면 환경 테스트 및 감사가 중요합니다. 정기적 인 (종종 수동 또는 샘플 기반) 점검을 포함하는 기존의 접근 방식으로는 특히 변화가 일정한 민첩한 환경에서는 충분하지 않습니다. AWS에서는 제어의 지속적인 모니터링 및 자동화를 구현하여 보안 위험에 대한 노출을 최소화 할 수 있습니다. AWS Config, Amazon Inspector 및 AWS Trusted Advisor와 같은 서비스는 규정 준수 또는 취약성을 지속적으로 모니터링하여 규정에 부합하는 IT 리소스와 그렇지 않은 IT 리소스에 대한 명확한 개요를 제공합니다. AWS Config 규칙을 사용하면 짧은 시간 동안이라도 리소스가 규정을 준수하지 않았는지 확인하여 특정 시점 및 특정 시점 감사를 매우 효과적으로 수행 할 수 있습니다. AWS CloudTrail을 활성화하여 애플리케이션 (Amazon CloudWatch Logs 사용) 및 실제 AWS API 호출에 대한 광범위한 로깅을 구현할 수 있습니다.
AWS CloudTrail은 AWS 계정에서 지원되는 AWS 서비스에 대한 API 호출을 기록하고 S3 버킷에 로그 파일을 제공하는 웹 서비스입니다. 그런 다음 로그 데이터를 변경 불가능한 방식으로 저장하고 자동으로 처리하여 알림을 보내거나 사용자를 대신하여 조치를 취하여 조직의 비준수를 방지합니다. AWS Marketplace의 AWS Lambda, Amazon EMR, Amazon ES, Amazon Athena 또는 타사 도구를 사용하여 로그 데이터를 스캔하여 사용되지 않은 권한, 권한있는 계정 과다 사용, 키 사용, 비정상적인 로그인, 정책 위반 및 시스템과 같은 이벤트를 감지 할 수 있습니다.
결론
AWS 클라우드에서 아키텍처를 설계 할 때는 애플리케이션에 적합한 데이터베이스를 선택하는 방법, 수평 및 고 가용성으로 수평 확장 가능한 애플리케이션을 설계하는 방법을 비롯하여 AWS에서 제공되는 중요한 원칙과 디자인 패턴을 고려해야합니다. 각 구현은 고유하기 때문에 이 지침을 구현에 적용하는 방법을 평가해야 합니다. 클라우드 컴퓨팅 아키텍처의 주제는 광범위하고 지속적으로 발전하고 있습니다. AWS 웹 사이트 및 AWS 교육 및 인증 에서 제공하는 자료를 통해 AWS 클라우드 제품에 대한 최신 변경 사항 및 추가 사항을 최신 상태로 유지할 수 있습니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
