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