[ 고지 사항 (Disclaimer) ]
이 문서에서는 클라우드 기반 아키텍처를 검토 및 개선하고 설계 결정의 비즈니스 영향을 보다 잘 이해할 수 있는 AWS Well-Architected Framework에 대해 설명합니다. Well-Architected Framework의 기반으로 정의하는 다섯 가지 개념적 영역에서 일반적인 디자인 원칙뿐만 아니라 구체적인 모범 사례와 지침을 다룹니다.
이 문서는 AWS Well-Architected Framework (July 2019, 영문) 내용에 기반하여 작성 되었습니다.
고객은 문서의 정보를 독립적으로 평가할 책임이 있습니다. 이 문서 : (a) 정보 제공의 목적으로 만, (b) 현재 AWS 제품 운영 및 관행을 나타내며, 예고없이 변경 될 수 있으며 © AWS 및 그 계열사, 공급 업체 또는 라이선서로부터 어떤 약속이나 보증도 작성하지 않습니다. AWS 제품이나 서비스는 명시적이든 묵시적이든 어떤 종류의 보증, 표현 또는 조건 없이 “있는 그대로” 제공됩니다. AWS의 고객에 대한 책임은 AWS 계약에 의해 통제되며, 이 문서는 AWS와 고객 간의 계약의 일부가 아니며 수정 하지도 않습니다.
Copyright © 2019 Amazon Web Services, Inc. or its affiliates
일반적인 설계 원칙
Well-Architected Framework는 클라우드에서 우수한 디자인을 용이하게 하는 일반적인 디자인 원칙을 확인합니다:
- 용량 요구 추측 중지: 인프라 용량 요구에 대한 추측을 그만둡니다. 시스템을 배포하기 전에 용량을 결정하는 경우 값비싼 유휴 리소스를 사용하거나 제한된 용량의 성능에 영향을 미칠 수 있습니다. 클라우드 컴퓨팅을 사용하면 이러한 문제가 사라질 수 있습니다. 필요한 만큼 또는 적은 용량을 사용하고 자동으로 스케일업 및 스케일다운 할 수 있습니다.
- 프로덕션에 맞는 시스템 테스트: 클라우드에서 주문형 프로덕션 규모 테스트 환경을 생성하고 테스트를 완료 한 다음 리소스를 해제 할 수 있습니다. 테스트 환경은 실행 중일 때만 비용을 지불하기 때문에 온프레미스 테스트 비용의 일부만으로 실제 환경을 시뮬레이션 할 수 있습니다.
- 아키텍처 실험을 보다 쉽게하기 위한 자동화: 자동화를 사용하면 저렴한 비용으로 시스템을 생성하고 복제 할 수 있으며 수작업에 드는 비용을 피할 수 있습니다. 자동화 변경 사항을 추적하고 영향을 감사하며 필요한 경우 이전 매개 변수로 되돌릴 수 있습니다.
- 진화적인 아키텍처 허용: 진화적인 아키텍처를 허용합니다. 기존 환경에서 아키텍처 결정은 종종 정적인 일회성 이벤트로 구현됩니다. 비즈니스와 그 맥락이 계속 변화함에 따라 이러한 초기 결정으로 인해 시스템의 변화하는 비즈니스 요구 사항을 제공 할 수 없습니다. 클라우드에서는 온디맨드 방식으로 자동화하고 테스트할 수 있으므로 설계 변경으로 인한 영향의 위험이 줄어듭니다. 이를 통해 시스템이 시간이 지남에 따라 발전하여 기업이 혁신을 표준 사례로 활용할 수 있습니다.
- 데이터를 사용한 아키텍처 구동: 클라우드에서는 아키텍처 선택이 워크로드의 동작에 어떤 영향을 미치는지에 대한 데이터를 수집할 수 있습니다. 이를 통해 작업 부하를 개선하는 방법에 대해 사실에 기반하여 결정할 수 있습니다. 클라우드 인프라는 코드이기 때문에 이 데이터를 사용하여 시간이 지남에 따라 아키텍처 선택 사항과 개선 사항을 알릴 수 있습니다.
- 게임 데이(Game Day)를 통한 개선: 프로덕션에서 이벤트를 시뮬레이션하기 위해 게임 데이를 정기적으로 예약하여 아키텍처와 프로세스의 성능을 테스트합니다. 이를 통해 어디에서 개선이 이루어질 수 있는지 이해하고 이벤트를 처리하는 데 있어 조직 경험을 개발할 수 있습니다.
프레임워크의 다섯개의 기반
소프트웨어 시스템을 만드는 것은 건물을 만드는 것과 비슷합니다. 기초가 확실하지 않으면 구조적 문제가 건물의 무결성과 기능을 손상시킬 수 있습니다. 기술 솔루션을 설계 할 때 운영 우수성, 보안, 안정성, 성능 효율성 및 비용 최적화의 다섯 가지 요소를 무시하면 기대와 요구 사항을 충족하는 시스템을 구축하기가 어려워 질 수 있습니다. 이러한 기반을 아키텍처에 통합하면 안정적이고 효율적인 시스템을 생성하는 데 도움이됩니다. 이를 통해 기능 요구 사항과 같은 디자인의 다른 측면에 집중할 수 있습니다.
운영 우수성
운영 우수성 기반에는 비즈니스 가치를 제공하고 지원 프로세스 및 절차를 지속적으로 개선하기 위해 시스템을 실행 및 모니터링하는 기능이 포함되어 있습니다.
운영 우수성 기반은 설계 원칙, 모범 사례 및 질문에 대한 개요를 제공합니다. 운영 우수성 기반 백서에서 구현에 대한 규범적 지침을 찾을 수 있습니다.
디자인 원칙
클라우드의 운영 우수성을 위한 6가지 설계 원칙:
- 코드로 작업 수행: 클라우드에서는 애플리케이션 코드에 사용하는 것과 동일한 엔지니어링 원칙을 전체 환경에 적용 할 수 있습니다. 전체 워크로드 (애플리케이션, 인프라)를 코드로 정의하고 코드로 업데이트 할 수 있습니다. 운영 절차를 코드로 구현하고 이벤트에 대한 응답으로 트리거하여 실행을 자동화할 수 있습니다. 코드로 작업을 수행하면 사람으로 인한 오류를 제한하고 이벤트에 일관된 응답을 수행 할 수 있습니다.
- 문서에 주석 달기: 온프레미스 환경에서 문서는 수동으로 작성되어 사람들이 사용하며 변경 속도에 맞추기 어렵습니다. 클라우드에서는 모든 빌드 후 주석이 달린 문서 작성을 자동화 할 수 있습니다 (또는 수작업으로 작성된 문서에 자동으로 주석을 달 수 있습니다). 사람과 시스템은 주석이 달린 문서를 사용할 수 있습니다. 작업 코드에 대한 입력으로 주석을 사용하십시오.
- 자주, 작게, 되돌릴 수 있는 변경: 컴포넌트를 정기적으로 업데이트 할 수 있도록 워크로드를 설계하십시오. 실패할 경우 되돌릴 수 있는 작은 단위로 변경하십시오 (가능한 경우 고객에게 영향을 주지 않음).
- 운영 절차를 자주 수정: 운영 절차를 사용할 때 개선 할 기회를 찾으십시오. 워크로드가 진화함에 따라 절차를 적절하게 개선해야 합니다. 정기적인 게임 데이를 설정하여 모든 절차가 효과적이며 팀이 해당 절차에 익숙한지 확인합니다.
- 예상 실패: “사전 사전”연습을 실시하여 잠재적인 실패 원인을 파악하여 제거하거나 완화 할 수 있습니다. 실패 시나리오를 테스트하고 그 영향에 대한 이해를 검증하십시오. 대응 절차를 테스트하여 효과적이고 팀이 실행에 익숙한지 확인하십시오. 시뮬레이션 된 이벤트에 대한 워크로드 및 팀 응답을 테스트하기 위해 정기적인 게임 데이를 설정하십시오.
- 모든 운영상의 실패로부터의 학습: 모든 운영 이벤트 및 장애로부터 얻은 교훈을 통해 개선을 유도하십시오. 팀과 조직 전체에서 배운 내용을 공유하십시오.
정의
클라우드에서 운영의 우수성을 위한 3가지 모범 사례 영역이 있습니다:
- 준비
- 운영
- 개선
운영 팀은 비즈니스 성과와 고객의 요구를 이해해야 비즈니스 성과를 효과적이고 효율적으로 지원할 수 있습니다. 운영은 운영 이벤트에 대응하기 위한 절차를 작성하고 사용하며 비즈니스 요구를 지원하기 위해 그 효과를 검증합니다. 운영은 원하는 비즈니스 성과 달성을 측정하는 데 사용되는 메트릭을 수집합니다. 비즈니스 상황, 비즈니스 우선 순위, 고객 요구 사항 등 모든 것이 계속 변화하고 있습니다. 변화에 대응하여 시간이 지남에 따라 진화를 지원하고 성과를 통해 얻은 교훈을 통합하도록 운영을 설계하는 것이 중요합니다.
모범사례
준비
운영의 우수성을 높이기 위해서는 효과적인 준비가 필요합니다. 비즈니스 성공 여부는 비즈니스, 개발 및 운영 전반에 걸쳐 공유된 목표와 이해를 통해 가능합니다. 공통 표준은 워크로드 설계 및 관리를 단순화하여 운영상의 성공을 지원합니다. 애플리케이션, 플랫폼 및 인프라 구성 요소, 고객 환경 및 행동을 모니터링하고 통찰력을 얻을 수 있는 메커니즘을 통해 워크로드를 설계 하십시오.
워크로드 또는 변경 사항이 프로덕션으로 이동되고 운영에서 지원될 준비가 되었는지 확인하는 메커니즘을 만듭니다. 워크로드가 정의된 표준을 충족하고 필요한 절차가 런북 및 플레이북에 적절하게 캡처되도록 하기 위해 체크리스트를 통해 운영 준비 상태를 검증합니다. 워크로드를 효과적으로 지원할 수 있는 충분한 교육을 받은 직원이 있는지 확인합니다. 전환 전에 작동 이벤트 및 고장에 대한 응답을 테스트합니다. 실패 주입와 게임 데이 이벤트를 통해 지원되는 환경에서 응답을 연습합니다.
AWS는 클라우드에서 코드로 작동하고 안전한 테스트, 운영 절차 개발 및 장애 연습 기능을 지원합니다. AWS CloudFormation을 사용하면 운영 제어 수준이 증가하면서 일관되고 템플릿화 된 샌드 박스 개발, 테스트 및 프로덕션 환경을 구축할 수 있습니다. AWS를 사용하면 다양한 로그 수집 및 모니터링 기능을 통해 모든 계층에서 워크로드를 볼 수 있습니다. 리소스, API(응용 프로그램 프로그래밍 인터페이스) 및 네트워크 흐름 로그의 사용 데이터는 Amazon CloudWatch, AWS CloudTrail 및 VPC Flow Log를 사용하여 수집할 수 있습니다. 수집된 플러그인 또는 CloudWatch Logs 에이전트를 사용하여 운영 체제에 대한 정보를 CloudWatch로 집계할 수 있습니다.
다음 질문은 운영 우수성에 대한 이러한 고려사항에 초점을 맞춥니다. (운영 우수성 질문, 답변 및 모범 사례 목록은 부록 참조)
워크로드에 대한 최소한의 아키텍처 표준을 구현합니다. 표준 구현 비용을 워크로드의 편익 및 운영 부담과 비교하여 조정합니다. 지원되는 표준 수를 줄여서 허용 가능한 수준 이하의 표준이 오류로 적용될 가능성을 줄입니다. 운영 담당자는 종종 제한된 리소스입니다.
운영 인력의 생산성을 극대화하고, 오류율을 최소화하고, 자동화 된 기능을 지원하기 위해 운영 활동을 코드로 구현하십시오. 클라우드의 탄력성을 이용하여 보다 빠른 구현을 위해 시스템의 사전 배치를 용이하게 하는 배포 방식을 채택합니다.
운영
워크로드의 성공적인 운영은 비즈니스 및 고객 성과 달성으로 측정됩니다. 예상 결과를 정의하고 성공을 측정하는 방법을 결정하고 해당 계산에 사용될 작업량 및 작업 메트릭을 식별하여 작업의 성공 여부를 결정합니다. 운영 상태에는 작업 부하의 상태와 작업 부하에 작용하는 작업의 상태 및 성공 (예 : 배포 및 사고 대응)이 모두 포함됩니다. 운영 개선 또는 저하를 식별 할 기준을 설정하고, 메트릭을 수집 및 분석 한 다음, 운영 성공에 대한 이해와 시간 경과에 따른 변화에 대한 이해를 검증하십시오. 수집 된 메트릭을 사용하여 고객 및 비즈니스 요구를 만족하는지 확인하고 개선 영역을 식별하십시오.
운영 우수성을 달성하기 위해서는 운영 이벤트의 효율적이고 효과적인 관리가 필요합니다. 이것은 계획된 운영 이벤트와 계획되지 않은 운영 이벤트 모두에 적용됩니다. 잘 이해된 이벤트에 대해 확립된 실행북을 사용하고 다른 이벤트의 해결을 돕기 위해 플레이북을 사용합니다. 비즈니스 및 고객의 영향을 기반으로 이벤트에 대한 응답을 우선시합니다. 이벤트에 대한 응답으로 경고가 제기되면 특정 식별 소유자와 함께 실행할 관련 프로세스가 있는지 확인합니다.
이벤트를 해결하는 데 필요한 인력을 미리 정의하고 임팩트 (즉, 지속 시간, 규모 및 범위)에 따라 필요에 따라 추가 인력을 참여시키기 위한 에스컬레이션 트리거를 포함합니다. 이전에 언급되지 않은 이벤트 응답으로 인해 비즈니스 영향이 있을 때 행동 과정을 결정할 권한이 있는 인력을 식별하고 참여시킵니다.
대상 사용자 (예를 들어 고객, 비즈니스, 개발자, 운영)에게 맞춤형 대시보드와 통지를 통해 워크로드의 운영 상태를 전달해 적절한 조치를 취할 수 있도록 해 기대치를 관리하고 정상 운영이 재개되면 통지합니다.
계획되지 않은 이벤트의 근본 원인과 계획된 이벤트로 인한 예기치 않은 영향을 판별하십시오. 이 정보는 향후 발생하는 사건을 완화하기 위해 절차를 업데이트하는 데 사용됩니다. 영향을 받는 커뮤니티와 적절한 근본 원인을 소통합니다.
AWS에서는 작업 및 기본적으로 AWS에서 수집 한 지표의 대시 보드 보기를 생성 할 수 있습니다. CloudWatch 또는 타사 애플리케이션을 활용하여 비즈니스, 워크로드 및 운영 수준의 운영 활동보기를 집계하고 제시 할 수 있습니다. AWS는 근본 원인 분석 및 치료를 지원하는 워크로드 문제를 식별 할 수있는 AWS X-Ray, CloudWatch, CloudTrail 및 VPC 흐름 로그를 포함한 로깅 기능을 통해 워크로드 통찰력을 제공합니다.
다음 질문은 운영 우수상에 대한 이러한 고려 사항에 중점을 둡니다.
계획되지 않은 이벤트에 대한 응답뿐만 아니라 일상적인 작업도 자동화해야 합니다. 배포, 릴리스 관리, 변경 및 롤백에 대한 수동 프로세스는 피해야합니다. 릴리스는 드물게 수행되는 큰 배치가 아니어야 합니다.
롤백은 큰 변화에서 더 어렵습니다. 롤백 계획을 만들지 않거나 실패의 영향을 완화할 수 있는 기능을 갖추지 못하면 작업의 연속성이 방지됩니다. 비즈니스 요구에 따라 메트릭을 조정하면 비즈니스 연속성을 유지하는 데 효과적입니다. 수동 응답을 갖는 일회성 분산 메트릭은 계획되지 않은 이벤트 동안 작업에 더 큰 혼란을 초래합니다.
개선
운영의 우수성을 유지하려면 운영의 개선이 필요합니다. 주기를 지속적으로 점진적으로 개선하기 위해 노력하십시오. 워크로드 및 운영 절차를 포함하여 개선 기회 (예 : 기능 요청, 문제 수정 및 준수 요구 사항)를 정기적으로 평가하고 우선 순위를 지정합니다. 작업할 때 개선 영역을 신속하게 식별하고 학습을 캡처하기 위해 절차에 피드백 루프를 포함합니다.
팀간에 배운 교훈을 공유하여 교훈의 이점을 공유합니다. 학습된 수업 내 추세를 분석하고 운영 메트릭에 대한 교차 팀 소급 분석을 수행하여 개선 기회와 방법을 확인합니다. 개선을 가져오고 결과를 평가하여 성공을 결정하기 위한 변경 사항을 구현합니다.
AWS 개발자 도구를 사용하면 AWS 및 제 3 자의 다양한 소스 코드, 빌드, 테스트 및 배포 도구로 작동하는 지속적인 배달 빌드, 테스트 및 배포 활동을 구현할 수 있습니다. 배포 활동의 결과는 배포 및 개발의 개선 기회를 식별하는 데 사용될 수 있습니다. 운영 및 배포 활동의 데이터를 통합한 메트릭 데이터에 대한 분석을 수행하여 활동이 비즈니스 및 고객 성과에 미치는 영향을 분석할 수 있습니다. 이 데이터는 크로스 팀 회고 분석에서 활용되어 개선 기회와 방법을 식별할 수 있습니다.
다음 질문은 운영 우수성에 대한 이러한 고려 사항에 중점을 둡니다.
성공적인 운영 개선은 다음과 같이 수행됩니다: 빈번한 작은 개선; 실험, 개발 및 테스트 개선을 위한 안전한 환경과 시간을 제공하는 것; 실패로부터의 학습이 장려되는 환경. 운영 제어 수준이 증가함에 따라 샌드 박스, 개발, 테스트 및 생산 환경에 대한 운영 지원은 개발을 용이하게하고 운영에 배포된 변경으로 성공적인 결과의 예측 가능성을 증가시킵니다.
주요 AWS 서비스
운영 우수성에 필수적인 AWS 서비스는 AWS CloudFormation이며, 모범 사례를 기반으로 템플릿을 생성하는 데 사용할 수 있습니다. 이를 통해 개발 환경에서 프로덕션 환경에 이르기까지 자원을 규칙적이고 일관된 방식으로 프로비저닝 할 수 있습니다. 다음 서비스 및 기능은 운영 우수성의 세 가지 영역을 지원합니다:
- 준비: AWS Config 및 AWS Config 규칙을 사용하여 워크로드에 대한 표준을 생성하고 프로덕션 환경에 들어가기 전에 환경이 해당 표준을 준수하는지 확인할 수 있습니다.
- 운영: Amazon CloudWatch를 사용하면 워크로드의 운영 상태를 모니터링 할 수 있습니다.
- 개선: Amazon Elasticsearch Service (Amazon ES)를 사용하면 로그 데이터를 분석하여 실행 가능한 통찰력을 빠르고 안전하게 얻을 수 있습니다.
리소스
운영 우수성에 대한 모범 사례에 대한 자세한 내용은 다음 리소스를 참조 하십시오.
문서
백서
동영상
보안
보안 기반에는 정보, 시스템 및 자산을 보호하는 동시에 위험 평가 및 완화 전략을 통해 비즈니스 가치를 제공하는 기능이 포함됩니다.
보안 기반은 설계 원칙, 모범 사례 및 질문에 대한 개요를 제공합니다. 보안 기반 백서에서 구현에 대한 규범적 지침을 찾을 수 있습니다.
디자인 원칙
클라우드 보안에는 7 가지 설계 원칙이 있습니다.
- 강력한 개별 기반 구현: AWS 리소스와 상호 작용할 때마다 적절한 권한을 부여하여 최소 권한의 원칙을 구현하고 업무 분리를 시행하십시오. 권한 관리를 중앙 집중화하고 장기 자격 증명에 대한 의존도를 줄이거나 없앱니다.
- 추적 기능 활성화: 작업 환경 및 변경 사항을 실시간으로 모니터링, 경고 및 감사합니다. 로그와 메트릭을 시스템과 통합하여 자동 응답 및 조치를 수행합니다.
- 모든 계층에 보안 적용: 단일 외부 레이어의 보호에 초점을 맞추기보다는 다른 보안 제어 및 심층 방어 접근법을 적용합니다. 모든 레이어 (예 : 엣지 네트워크, VPC, 서브넷, 로드 밸런서, 모든 인스턴스, 운영 체제 및 응용 프로그램)에 적용합니다.
- 보안 모범 사례 자동화: 자동화된 소프트웨어 기반 보안 메커니즘은 보다 신속하고 비용 효율적으로 안전하게 확장 할 수 있는 능력을 향상시킵니다. 버전 제어 템플릿에서 코드로 정의되고 관리되는 컨트롤 구현을 포함하여 안전한 아키텍처를 만듭니다.
- 전송 중 및 미사용 데이터 보호: 데이터를 민감도 수준으로 분류하고 적절한 경우 암호화, 토큰화 및 액세스 제어와 같은 메커니즘을 사용합니다.
- 데이터와 사람의 분리: 데이터에 대한 직접 액세스 또는 데이터 수동 처리의 필요성을 줄이거나 없애기 위한 메커니즘과 도구를 만듭니다. 이것은 민감한 데이터를 처리할 때 손실, 수정 및 사람으로 인한 오류의 위험을 감소시킵니다.
- 보안 이벤트 준비: 조직의 요구사항에 맞는 사고관리 프로세스를 통해 사고에 대비합니다. 사고 대응 시뮬레이션을 실행하고 자동화된 도구를 사용하여 탐지, 조사 및 복구 속도를 향상시킵니다.
정의
클라우드 보안에는 5 가지 모범 사례 영역이 있습니다.
- 자격증명 및 액세스 관리
- 감사 컨트롤
- 인프라 보호
- 데이터 보호
- 사고 대응
시스템을 설계하기 전에 보안에 영향을 미치는 place practices를 적용해야 합니다. 누가 무엇을 할 수 있는지 통제하고 싶을 것입니다. 또한 보안 사고를 식별하고 시스템 및 서비스를 보호하며 데이터 보호를 통해 데이터의 기밀성과 무결성을 유지할 수 있습니다. 보안 사고에 대응하기 위해 잘 정의되고 실행된 프로세스를 가져야 합니다. 이러한 도구와 기술은 재정적 손실을 방지하거나 규제 의무를 준수하는 것과 같은 목표를 지원하기 때문에 중요합니다.
AWS 공유 책임 모델을 통해 클라우드를 채택한 조직은 보안 및 규정 준수 목표를 달성 할 수 있습니다. AWS는 클라우드 서비스를 지원하는 인프라를 물리적으로 보호하므로 AWS 고객은 서비스를 사용하여 목표를 달성하는 데 집중할 수 있습니다. 또한 AWS 클라우드는 보안 데이터에 대한 액세스 권한을 높이고 보안 이벤트에 자동으로 대응합니다.
모범 사례
자격 증명 및 액세스 관리
자격 증명 및 액세스 관리는 정보 보안 프로그램의 핵심 부분이며, 인증된 사용자만 리소스에 액세스할 수 있으며, 의도하는 방식으로만 액세스할 수 있도록 보장합니다. 예를 들어, 당신은 주체(즉, 당신의 계정에서 행동을 취하는 사용자, 그룹, 서비스, 역할)를 정의하고, 이들 주체와 일치하는 정책을 구축하고, 강력한 자격 관리를 구현해야 합니다. 이러한 권한 관리 요소는 인증과 권한 부여의 핵심을 형성합니다.
AWS에서 권한 관리는 주로 AWS Identity and Access Management (IAM) 서비스에 의해 지원되며, 이 서비스는 AWS 서비스 및 리소스에 대한 사용자 및 프로그램 액세스를 제어 할 수 있습니다. 사용자, 그룹, 역할 또는 리소스에 권한을 할당하는 세분화 된 정책을 적용해야 합니다. 또한 복잡성 수준, 재사용 방지 및 다중 요인 인증 (MFA) 시행과 같은 강력한 암호 방법을 요구할 수 있습니다. 기존 디렉토리 서비스와 결합을 하여 사용할 수 있습니다. 시스템에 AWS에 대한 액세스 권한이 필요한 워크로드의 경우 IAM을 통해 역할, 인스턴스 프로필, 자격 증명 연동 및 임시 자격 증명을 통해 안전하게 액세스 할 수 있습니다.
다음 질문은 이러한 보안 고려 사항에 중점을 둡니다. 보안 질문, 답변 및 모범 사례 목록은 부록을 참조하십시오.
사용자 또는 시스템간에 자격 증명을 공유해서는 안됩니다. 사용자 액세스는 암호 요구 사항 및 MFA를 시행하는 모범 사례를 사용하여 최소 권한 접근법을 사용하여 부여되어야 합니다. AWS 서비스에 대한 API 호출을 포함한 프로그래밍 방식 액세스는 AWS Security Token Service에서 발급한 것과 같은 임시적이고 제한된 권한 자격 증명을 사용하여 수행해야 합니다.
AWS는 자격 증명 및 액세스 관리에 도움이되는 리소스를 제공합니다. 모범 사례를 배우려면 자격 증명 및 인증 관리, 인적 액세스 제어 및 프로그래밍 방식 액세스 제어에 대한 실습 랩을 살펴보십시오.
감사 컨트롤
감사 컨트롤는 잠재적인 보안 위협이나 사건을 식별할 수 있습니다. 이들은 거버넌스 프레임 워크의 필수적인 부분이며 품질 프로세스, 법적 또는 준수 의무, 위협 식별 및 대응 노력을 지원하는 데 사용할 수 있습니다. 감사 컨트롤에는 여러 가지 유형이 있습니다. 예를 들어, 자산의 재고 및 세부 속성을 수행하면 운영 기준선을 수립하는 데 도움이 되는 보다 효과적인 의사 결정 (및 라이프 사이클 컨트롤)이 촉진됩니다. 또한 내부 감사, 정보 시스템과 관련된 제어에 대한 검사 등을 사용하여 관행이 정책과 요구 사항을 충족시키고 정의된 조건을 기반으로 올바른 자동 경고 경고를 설정할 수 있습니다. 이러한 컨트롤은 조직이 비정상적인 활동의 범위를 확인하고 이해하는 데 도움이 되는 중요한 반응 요소입니다.
AWS에서는 감사, 자동화 된 분석 및 경보를 허용하는 로그, 이벤트 및 모니터링을 처리하여 감사 컨트롤을 구현할 수 있습니다. CloudTrail 로그, AWS API 호출 및 CloudWatch는 경보를 통해 지표 모니터링을 제공하고 AWS 구성은 구성 기록을 제공합니다. Amazon GuardDuty는 악의적이거나 무단 행동을 지속적으로 모니터링하여 AWS 계정 및 워크로드를 보호하는 관리형 위협 탐지 서비스입니다. 서비스 수준 로그도 사용할 수 있습니다. 예를 들어 Amazon Simple Storage Service (Amazon S3)를 사용하여 액세스 요청을 기록할 수 있습니다.
다음 질문은 이러한 보안 고려 사항에 중점을 둡니다.
로그 관리는 보안 또는 포렌식에서 규제 또는 법적 요구 사항에 이르기까지 잘 관리된 설계에 중요합니다. 로그를 분석하고 이에 대응하여 잠재적인 보안 사고를 식별하는 것이 중요합니다. AWS는 데이터 보존 수명주기를 정의하거나 데이터가 보존, 보관 또는 결국 삭제될 위치를 정의할 수 있는 기능을 제공함으로써 로그 관리를 구현하기 쉽습니다. 이것은 예측 가능하고 신뢰할 수 있는 데이터 처리를 단순화하고 비용을 효율화합니다.
인프라 보호
인프라 보호는 모범 사례 및 조직 또는 규제 의무를 충족하기 위해 필요한 심층 방어와 같은 제어 방법론을 포함합니다. 이러한 방법론은 클라우드 또는 온프레미스에서 성공적이고 지속적인 운영을 위해 매우 중요합니다.
AWS에서는 AWS 네이티브 기술을 사용하거나 AWS 마켓플레이스를 통해 제공되는 파트너 제품 및 서비스를 사용하여 상태 저장 및 상태 비저장 패킷 검사를 구현할 수 있습니다. Amazon VPC(Amazon Virtual Private Cloud)를 사용하여 게이트웨이, 라우팅 테이블, 퍼블릭 및 프라이빗 서브넷 등 토폴로지를 정의할 수 있는 확장 가능한 보안이 적용된 프라이빗 환경을 만들어야 합니다.
다음 질문은 이러한 보안 고려 사항에 중점을 둡니다.
어떤 종류의 환경에서도 여러 계층의 방어가 바람직합니다. 인프라 보호의 경우 클라우드 및 온프레미스 모델에서 많은 개념과 방법이 유효합니다. 경계 보호, 진입 지점 및 발신 지점 모니터링, 포괄적인 로깅, 모니터링 및 경고를 시행하는 것은 효과적인 정보 보안 계획에 필수적입니다.
AWS 고객은 Amazon EC2 (Amazon Elastic Compute Cloud), Amazon ECS (Amazon EC2 Container Service) 컨테이너 또는 AWS Elastic Beanstalk 인스턴스의 구성을 조정하거나 강화할 수 있으며, 이 구성을 고정의 Amazon 머신 이미지(AMI)로 유지할 수 있습니다. 그런 다음 Auto Scaling에 의해 트리거 되었든 수동으로 시작 되었든, 이 AMI로 시작된 모든 새로운 가상 서버 (인스턴스)는 강화된 구성을 받습니다.
데이터 보호
시스템을 설계하기 전에 보안에 영향을 미치는 기본 실례를 갖추어야 합니다. 예를 들어 데이터 분류는 민감도 수준을 기준으로 조직 데이터를 분류하는 방법을 제공하며 암호화는 데이터를 무단 액세스에 이해할 수 없도록 렌더링하여 데이터를 보호합니다. 이러한 도구와 기법은 재무 손실 방지 또는 규제 의무를 준수하는 것과 같은 목적을 지원하기 때문에 중요합니다.
AWS에서 다음 실례는 데이터 보호를 용이하게 합니다:
- AWS 고객은 데이터를 완전히 제어 할 수 있습니다.
- AWS를 사용하면 AWS에서 쉽게 자동화하거나 유지 관리 할 수있는 정규 키 순환을 비롯하여 데이터를 암호화하고 키를 쉽게 관리 할 수 있습니다.
- 파일 액세스 및 변경과 같은 중요한 내용이 포함된 상세 로깅을 사용할 수 있습니다.
- AWS는 뛰어난 복원력을 위해 스토리지 시스템을 설계했습니다. 예를 들어 Amazon S3 Standard, S3 Standard–IA, S3 One Zone-IA 및 Amazon Glacier는 모두 1년 동안 객체의 99.999999999% 내구성을 제공하도록 설계 되었습니다. 이 내구성 수준은 물체의 평균 연간 예상 손실 0.000000001 %에 해당합니다.
- 더 큰 데이터 수명주기 관리 프로세스의 일부일 수 있는 버전 관리는 우발적인 덮어 쓰기, 삭제 및 유사한 피해를 방지 할 수 있습니다.
- AWS는 리전 간 데이터 이동을 초기 설정으로 지원하지 않습니다. 해당 기능을 명시적으로 활성화하거나 해당 기능을 제공하는 서비스를 활용하지 않는 한 지역에 배치된 컨텐츠는 해당 지역에 남아 있습니다.
다음 질문은 이러한 보안 고려 사항에 중점을 둡니다.
AWS는 저장 및 전송중인 데이터를 암호화하기 위한 여러 가지 수단을 제공합니다. 데이터를 보다 쉽게 암호화 할 수 있는 기능을 서비스에 제공합니다. 예를 들어, Amazon S3에 서버 측 암호화 (SSE)를 구현하여 데이터를 암호화 된 형태로 보다 쉽게 저장할 수 있습니다. ELB (Elastic Load Balancing)에서 처리 할 전체 HTTPS 암호화 및 암호화 프로세스(일반적으로 SSL termination)를 정렬할 수도 있습니다.
사고 대응
극도로 성숙한 예방 및 감사 통제를 가지고 있음에도 불구하고 조직은 보안 사고의 잠재적 영향에 대응하고 완화하기 위한 프로세스를 제자리에 두어야 합니다. 워크로드의 아키텍처는 팀이 사고 발생시 효과적으로 작동하고 시스템을 분리하거나 포함하고 작동을 알려진 좋은 상태로 복원할 수 있는 능력에 강한 영향을 미칩니다. 보안 사고 전에 도구를 배치하고 보안 사고보다 앞서 액세스 한 다음 일상적으로 게임 데이를 통해 사고 대응을 연습하면 아키텍처가 적시에 조사 및 복구를 실행할 수 있도록 보장할 수 있습니다.
AWS에서 다음 방법은 효과적인 사고 대응을 향상 시킵니다:
- 파일 액세스 및 변경과 같은 중요한 내용이 포함 된 상세 로깅을 사용할 수 있습니다.
- AWS API를 통해 이벤트를 자동으로 처리하고 응답을 자동화하는 도구를 트리거 할 수 있습니다.
- AWS CloudFormation을 사용하여 툴링 및 “클린 룸”을 사전 프로비저닝 할 수 있습니다. 이를 통해 안전하고 격리된 환경에서 포렌직을 수행할 수 있습니다.
다음 질문은 이러한 보안 고려 사항에 중점을 둡니다.
InfoSec팀에 대한 액세스 권한을 신속하게 부여 할 수 있는 방법을 확보하고, 인스턴스 격리 및 포렌직을 위한 데이터 및 상태 캡처를 자동화 할 수 있습니다.
주요 AWS 서비스
보안에 필수적인 AWS 서비스는 AWS Identity and Access Management (IAM)이며, 이를 통해 사용자의 AWS 서비스 및 리소스에 대한 액세스를 안전하게 제어 할 수 있습니다. 다음 서비스 및 기능은 5가지 보안 영역을 지원합니다.:
- 자격증명 및 액세스 관리: IAM을 사용하면 AWS 서비스 및 리소스에 대한 액세스를 안전하게 제어 할 수 있습니다. MFA는 사용자 액세스에 추가적인 보호 계층을 추가합니다. AWS Organizations를 사용하면 여러 AWS 계정에 대한 정책을 중앙에서 관리하고 시행 할 수 있습니다.
- 감사 컨트롤: AWS CloudTrail은 AWS API 호출을 기록하고 AWS 구성은 AWS 리소스 및 구성에 대한 자세한 인벤토리를 제공합니다. Amazon GuardDuty는 악의적이거나 승인되지 않은 동작을 지속적으로 모니터링하는 관리 형 위협 탐지 서비스입니다. Amazon CloudWatch는 AWS 리소스에 대한 모니터링 서비스로, CloudWatch Events를 트리거하여 보안 대응을 자동화 할 수 있습니다.
- 인프라 보호: Amazon Virtual Private Cloud (Amazon VPC)를 사용하면 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. Amazon CloudFront는 AWS Shield for DDoS 완화 기능과 통합 된 뷰어에게 데이터, 비디오, 애플리케이션 및 API를 안전하게 제공하는 글로벌 컨텐츠 전송 네트워크입니다. AWS WAF는 Amazon CloudFront 또는 Application Load Balancer에 배포되는 웹 애플리케이션 방화벽으로서 일반적인 웹 익스플로잇으로부터 웹 애플리케이션을 보호합니다.
- 데이터 보호: ELB, Amazon EBS (Amazon Elastic Block Store), Amazon S3 및 Amazon RDS (Amazon Relational Database Service)와 같은 서비스에는 전송중인 데이터와 휴지중인 데이터를 보호하는 암호화 기능이 포함되어 있습니다. Amazon Macie는 민감한 데이터를 자동으로 검색, 분류 및 보호하는 반면 AWS KMS (AWS Key Management Service)를 사용하면 암호화에 사용되는 키를 쉽게 생성하고 제어 할 수 있습니다.
- 사고 대응: IAM을 사용하여 사고 대응 팀 및 대응 도구에 적절한 권한을 부여해야 합니다. AWS CloudFormation을 사용하여 조사를 수행 할 수 있는 신뢰할 수 있는 환경 또는 클린 룸을 만들 수 있습니다. Amazon CloudWatch Events를 사용하면 AWS Lambda를 포함한 자동 응답을 트리거하는 규칙을 생성 할 수 있습니다.
리소스
보안 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하십시오.
문서
백서
동영상
안정성
안정성 기반에는 시스템이 인프라 또는 서비스 중단을 복구하고, 컴퓨팅 리소스를 동적으로 획득하여 요구를 충족 시키며, 잘못 구성되거나 일시적인 네트워크 문제와 같은 중단을 완화하는 기능이 포함됩니다.
안정성 기반은 설계 원칙, 모범 사례 및 질문에 대한 개요를 제공합니다. 안정성 기반 백서에서 구현에 대한 규범적 지침을 찾을 수 있습니다.
디자인 원칙
클라우드의 안정성을 위한 5 가지 설계 원칙이 있습니다:
- 테스트 복구 절차: 온프레미스 환경에서 테스트는 종종 특정 시나리오에서 시스템이 작동하는지 입증하기 위해 수행됩니다. 일반적으로 테스트는 복구 전략을 검증하는 데 사용되지 않습니다. 클라우드에서 시스템 장애를 테스트하고 복구 절차를 검증 할 수 있습니다. 자동화를 사용하여 다양한 장애를 시뮬레이션하거나 이전에 장애를 유발 한 시나리오를 재현 할 수 있습니다. 이는 실제 장애 시나리오 이전에 테스트하고 수정할 수있는 장애 경로를 노출시켜 이전에 테스트하지 않은 구성 요소의 고장 위험을 줄입니다.
- 자동 장애 복구: 핵심 성과 지표 (KPI)에 대한 시스템을 모니터링 하여 임계 값이 초과 될 때 자동화를 트리거 할 수 있습니다. 이를 통해 자동 통지 및 장애 추적, 장애를 해결하거나 복구하는 자동 복구 프로세스가 가능합니다. 보다 정교한 자동화를 통해 장애가 발생하기 전에 예측하고 개선 할 수 있습니다.
- 시스템 가용성을 높이기 위해 수평으로 확장: 하나의 큰 리소스를 여러 개의 작은 리소스로 대체하여 전체 시스템에 대한 단일 오류의 영향을 줄입니다. 여러 개의 작은 리소스에 요청을 분산하여 일반적인 장애 지점을 공유하지 않도록 합니다.
- 용량 추측 중지: 온프레미스 시스템에서 장애가 발생하는 일반적인 원인은 시스템에 대한 요구가 해당 시스템의 용량을 초과 할 때의 리소스 포화입니다 (이는 종종 서비스 거부 공격의 목적임). 클라우드에서는 수요 및 시스템 활용도를 모니터링하고 리소스 추가 또는 제거를 자동화하여 초과 또는 미달 프로비저닝 없이 요구를 충족하는 최적의 수준을 유지할 수 있습니다.
- 자동화 변경 관리: 인프라 변경은 자동화를 사용하여 수행해야 합니다. 관리해야 할 변경 사항은 자동화 변경 사항입니다.
정의
클라우드 안정성을 위한 세 가지 모범 사례 영역이 있습니다:
- 기초
- 변경 관리
- 장애 관리
신뢰성을 달성하기 위해, 시스템은 수요 또는 요구 사항의 변화를 처리하기 위한 메커니즘과 함께 잘 계획된 기초 및 모니터링을 갖추어야합니다. 시스템은 고장을 감지하고 자동으로 자체 치유되도록 설계되어야 합니다.
모범 사례
기초
시스템을 설계하기 전에 안정성에 영향을 미치는 기본 요구 사항이 있어야 합니다. 예를 들어, 데이터 센터에 충분한 네트워크 대역폭이 있어야 합니다. 이러한 요구 사항은 때로는 단일 프로젝트 범위를 벗어나기 때문에 무시됩니다. 이러한 무시는 신뢰할 수 있는 시스템을 제공하는 능력에 중대한 영향을 미칠 수 있습니다. 온프레미스 환경에서 이러한 요구 사항은 종속성으로 인해 리드 타임이 길어질 수 있으므로 초기 계획 중에 통합해야 합니다.
AWS에서 이러한 기본 요구 사항의 대부분은 이미 통합되었거나 필요에 따라 해결 될 수 있습니다. 클라우드는 본질적으로 무제한으로 설계되었으므로 충분한 네트워킹 및 컴퓨팅 용량에 대한 요구 사항을 충족시키는 것은 AWS의 책임이며, 필요에 따라 스토리지 장치의 크기와 같은 리소스 크기 및 할당을 자유롭게 변경할 수 있습니다.
다음 질문은 안정성 고려 사항에 중점을 둡니다. 신뢰성 질문, 답변 및 모범 사례 목록은 부록을 참조하십시오.
AWS는 실수로 리소스를 과도하게 프로비저닝하지 않도록 서비스 제한(팀에서 요청할 수 있는 각 리소스 수에 대한 상한)을 설정합니다. 비즈니스 요구 사항을 충족하기 위해 이러한 제한을 모니터링하고 변경할 수 있는 거버넌스 및 프로세스가 마련되어야 합니다. 클라우드를 채택할 때 기존 사내 리소스(하이브리드 방식)와의 통합을 계획해야 할 수도 있습니다. 하이브리드 모델을 사용하면 시간이 지남에 따라 점차적으로 All-In 클라우드 접근 방식으로 전환할 수 있습니다. 따라서 AWS와 사내 리소스가 네트워크 토폴로지로 어떻게 상호 작용하는지 설계하는 것이 중요합니다.
변경 관리
변경이 시스템에 어떤 영향을 미치는지 알고 있으면 사전에 계획을 세울 수 있으며 모니터링을 통해 용량 문제나 SLA 위반으로 이어질 수 있는 추세를 신속하게 파악할 수 있습니다. 기존 환경에서는 변경-제어 프로세스가 수동인 경우가 많으므로 감사와 세심하게 조정하여 누가 언제 변경되는지 효과적으로 제어해야 합니다.
AWS를 사용하면 시스템의 동작을 모니터링하고 KPI에 대한 응답을 자동화할 수 있습니다. 예를 들어 시스템이 더 많은 사용자를 얻을 때 서버를 추가하면 됩니다. 시스템 변경 권한을 가진 사용자를 제어하고 이러한 변경 내역을 감사할 수 있습니다.
다음 질문은 신뢰성에 대한 이러한 고려사항에 초점을 맞춥니다.
수요 변화에 대응하여 리소스를 자동으로 추가 및 제거하도록 시스템을 설계하면 안정성이 향상될 뿐만 아니라 비즈니스 성공에 부담이 되지 않습니다. 모니터링을 시행하면 KPI가 예상된 규범에서 벗어날 때 팀원들에게 자동으로 경고가 전달됩니다. 환경에 대한 변경 내용을 자동으로 기록하면 신뢰성에 영향을 줄 수 있는 작업을 감사하고 신속하게 식별할 수 있습니다. 변경 관리에 대한 제어를 통해 필요한 신뢰성을 제공하는 규칙을 적용할 수 있습니다.
장애 관리
합리적으로 복잡한 시스템에서는 장애가 발생할 것으로 예상됩니다. 이러한 장애에 대해 어떻게 인지하고, 이에 대응하고, 재발 방지를 할 수 있을지가 일반적으로 관심사입니다.
AWS를 사용하면 자동화를 활용하여 모니터링 데이터에 대응할 수 있습니다. 예를 들어 특정 메트릭이 임계값을 초과할 경우 자동 작업을 트리거하여 문제를 해결할 수 있습니다. 또한 운영 환경의 일부인 장애가 발생한 리소스를 진단하고 수정하는 대신 새 리소스로 교체하고 장애가 발생한 리소스에 대한 분석을 수행할 수 있습니다. 클라우드를 사용하면 전체 시스템의 임시 버전을 저렴한 비용으로 지원할 수 있으므로 자동 테스트를 사용하여 전체 복구 프로세스를 확인할 수 있습니다.
다음 질문은 안정성에 대한 고려 사항에 중점을 둡니다.
정기적으로 데이터를 백업하고 백업 파일을 테스트하여 논리적 오류와 물리적 오류를 모두 복구할 수 있도록 합니다. 고장 관리의 핵심은 시스템의 빈번하고 자동화된 테스트로 고장을 일으킨 다음 복구 방법을 관찰하는 것입니다. 정기적으로 이 작업을 수행하고 중요한 시스템 변경 후 이러한 테스트도 트리거되도록 합니다. RTO(복구 시간 목표) 및 RPO(복구 시점 목표)와 같은 KPI를 능동적으로 추적하여 시스템의 복원력(특히 고장 테스트 시나리오에서)을 평가합니다. KPI를 추적하면 단일 장애 지점을 식별하고 완화하는 데 도움이 됩니다. 목표는 시스템 복구 프로세스를 철저히 테스트하여 지속적인 문제 발생 시에도 모든 데이터를 복구하고 고객에게 계속 서비스를 제공할 수 있음을 확신하는 것입니다. 복구 프로세스는 일반적인 프로덕션 프로세스와 마찬가지로 잘 수행되어야 합니다.
주요 AWS 서비스
안정성에 필수적인 AWS 서비스는 런타임 지표를 모니터링하는 Amazon CloudWatch입니다. 다음 서비스 및 기능은 세 가지 영역의 안정성을 지원합니다:
- 기초: AWS IAM을 사용하면 AWS 서비스 및 리소스에 대한 액세스를 안전하게 제어할 수 있습니다. Amazon VPC를 사용하면 가상 네트워크에서 AWS 리소스를 시작할 수 있는 AWS Cloud의 분리된 전용 섹션을 프로비저닝할 수 있습니다. AWS Trusted Advisor는 서비스 제한에 대한 가시성을 제공합니다. AWS Shield는 AWS에서 실행되는 웹 응용 프로그램을 보호하는 관리 DoS(Distributed Distributed DoS) 보호 서비스입니다.
- 변경 관리: AWS CloudTrail은 계정에 대한 AWS API 호출을 기록하고 감사를 위해 로그 파일을 제공합니다. AWS Config는 AWS 리소스 및 구성에 대한 상세 인벤토리를 제공하고 구성 변경 사항을 지속적으로 기록합니다. Amazon Auto Scaling은 구축된 워크로드에 대해 자동화된 수요 관리를 제공하는 서비스입니다. Amazon CloudWatch는 사용자 지정 메트릭을 포함하여 메트릭에 대해 경고하는 기능을 제공합니다. Amazon CloudWatch에는 리소스에서 로그 파일을 집계하는 데 사용할 수 있는 로깅 기능도 있습니다.
- 장애 관리: AWS CloudFormation은 AWS 리소스 생성을 위한 템플릿을 제공하고 이를 순서대로 예측 가능한 방식으로 프로비저닝합니다. Amazon S3는 백업을 보관할 수 있는 내구성이 뛰어난 서비스를 제공합니다. Amazon Glacier는 내구성이 뛰어난 아카이브를 제공합니다. AWS KMS는 많은 AWS 서비스와 통합되는 신뢰할 수 있는 키 관리 시스템을 제공합니다.
리소스
안정성에 대한 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하십시오.
문서
- Service Limits
- Service Limits Reports Blog
- Amazon Virtual Private Cloud
- AWS Shield
- Amazon CloudWatch
- Amazon S3
- AWS KMS
백서
- Reliability Pillar
- Backup Archive and Restore Approach Using AWS
- Managing your AWS Infrastructure at Scale
- AWS Disaster Recovery
- AWS Amazon VPC Connectivity Options
동영상
제품
성능 효율성
성능 효율성 요소에는 시스템 요구 사항을 충족하기 위해 컴퓨팅 리소스를 효율적으로 사용하고 수요의 변화와 기술이 발전함에 따라 효율성을 유지할 수 있는 기능이 포함됩니다.
성능 효율성 기반은 설계 원리, 모범 사례 및 질문에 대한 개요를 제공합니다. 성능 효율성 기반 백서에서 구현에 대한 규범적 지침을 확인할 수 있습니다.
디자인 원칙
클라우드에는 성능 효율성을 위한 5가지 설계 원칙이 있습니다:
- 첨단 기술의 대중화: 구현하기 어려운 기술은 그 지식과 복잡성을 클라우드 공급 업체의 영역으로 밀어 냄으로써 사용하기 쉬워 질 수 있습니다. IT 팀에게 새로운 기술을 호스팅하고 실행하는 방법을 배우게 하는 대신 단순히 서비스로 사용할 수 있습니다. 예를 들어 NoSQL 데이터베이스, 미디어 변환 및 기계 학습은 모두 기술 커뮤니티에 고르게 분산되지 않는 전문 지식이 필요한 기술입니다. 클라우드에서는 이러한 기술이 리소스 프로비저닝 및 관리보다는 제품 개발에 집중하면서 팀이 사용할 수 있는 서비스가 됩니다.
- 몇 분 안에 전 세계로 배포: 클릭 몇 번만으로 전 세계 여러 지역에 손쉽게 시스템을 구축할 수 있습니다. 따라서 최소한의 비용으로 대기 시간을 단축하고 고객에게 더 나은 환경을 제공할 수 있습니다.
- 서버리스 아키텍처 사용: 클라우드에서 서버리스 아키텍처는 기존 컴퓨팅 작업을 수행하기 위해 서버를 실행하고 유지 관리할 필요성을 제거합니다. 예를 들어 스토리지 서비스는 정적 웹 사이트 역할을 수행하여 웹 서버의 필요성을 제거하며 이벤트 서비스는 사용자의 코드를 호스팅할 수 있습니다. 이렇게 하면 이러한 서버를 관리해야 하는 운영 부담을 줄일 수 있을 뿐만 아니라 이러한 관리형 서비스가 클라우드 규모로 운영되기 때문에 트랜잭션 비용을 절감할 수 있습니다.
- 손 쉬운 테스트: 가상 리소스와 자동화할 수 있는 리소스를 사용하여 다양한 유형의 인스턴스, 스토리지 또는 구성을 사용하여 비교 테스트를 신속하게 수행할 수 있습니다.
- 기계적인 공감: 달성하려는 목표에 가장 적합한 기술 방식을 사용합니다. 예를 들어 데이터베이스 또는 스토리지 접근 방식을 선택할 때 데이터 액세스 패턴을 고려해야 합니다.
정의
클라우드에는 성능 효율성을 위한 4가지 모범 사례 영역이 있습니다.:
- 선택
- 검토
- 모니터링
- 트레이드오프
고성능 아키텍처를 선택하는 데이터 중심 접근 방식을 취합니다. 고급 설계에서 리소스 유형의 선택 및 구성에 이르기까지 아키텍처의 모든 측면에 대한 데이터를 수집합니다. 주기적인 방식으로 선택 사항을 검토하면 지속적으로 발전하는 AWS 클라우드를 활용할 수 있습니다. 모니터링을 수행하면 예상 성능에서 벗어나는 것을 인지하고 조치를 취할 수 있습니다. 마지막으로, 아키텍처는 압축 또는 캐싱을 사용하거나 일관성 요구 사항을 완화하는 등 성능을 향상시키기 위한 트레이드오프를 수행할 수 있습니다.
모범 사례
선택
특정 시스템을 위한 최적의 솔루션은 여러 가지 접근 방식이 결합된 워크로드의 종류에 따라 달라집니다. 잘 설계된 시스템은 여러 솔루션을 사용하며 다양한 기능을 지원하여 성능을 향상시킵니다.
AWS에서는 리소스가 가상화되어 다양한 유형과 구성으로 제공됩니다. 따라서 사용자의 요구 사항에 가깝게 일치하는 접근 방식을 더 쉽게 찾을 수 있으며 사내 인프라로는 쉽게 달성할 수 없는 옵션도 찾을 수 있습니다. 예를 들어 Amazon DynamoDB와 같은 관리형 서비스는 모든 규모에서 한 자릿수의 지연 시간을 갖는 완전히 관리되는 NoSQL 데이터베이스를 제공합니다.
다음 질문은 성능 효율성에 대한 이러한 고려 사항에 중점을 둡니다. 성능 효율성 질문, 답변 및 모범 사례 목록은 부록을 참조하십시오.
아키텍처의 패턴과 구현을 선택할 때는 최적의 솔루션을 위해 데이터 기반 접근 방식을 사용합니다. AWS Solutions Architects, AWS Reference Architectures 및 AWS Partner Network(APN) 파트너는 지금까지 배운 내용을 기반으로 아키텍처를 선택할 수 있도록 지원할 수 있지만, 벤치마킹 또는 로드 테스트를 통해 얻은 데이터는 아키텍처를 최적화하기 위해 필요합니다.
아키텍처는 다양한 아키텍처 접근 방식(예: 이벤트 중심, ETL 또는 파이프라인)을 결합할 수 있습니다. 아키텍처를 구현하면 아키텍처의 성능 최적화와 관련된 AWS 서비스를 사용할 수 있습니다. 다음 섹션에서는 고려해야 할 네 가지 주요 리소스 유형(컴퓨팅, 스토리지, 데이터베이스 및 네트워크)을 살펴봅니다.
컴퓨팅
특정 시스템의 최적 컴퓨팅 솔루션은 애플리케이션 설계, 사용 패턴 및 구성 설정에 따라 달라질 수 있습니다. 아키텍처는 다양한 구성 요소에 대해 서로 다른 컴퓨팅 솔루션을 사용할 수 있으며 성능을 향상시키기 위해 다양한 기능을 사용할 수 있습니다. 아키텍처에 대해 잘못된 컴퓨팅 솔루션을 선택하면 성능 효율성이 떨어질 수 있습니다.
AWS에서 컴퓨팅은 인스턴스, 컨테이너 및 함수의 세 가지 형태로 제공됩니다.:
- 인스턴스는 가상화된 서버이므로 버튼이나 API 호출을 클릭하여 기능을 변경할 수 있습니다. 클라우드 리소스 결정은 더 이상 고정되지 않으므로 여러 서버 유형을 사용하여 테스트할 수 있습니다. AWS에서 이러한 가상 서버 인스턴스는 다양한 제품군과 크기로 제공되며 SSD(Solid State Drive) 및 GPU(그래픽 처리 장치)를 비롯한 다양한 기능을 제공합니다.
- 컨테이너는 운영 체제 가상화 방법으로, 애플리케이션과 애플리케이션 종속성을 리소스 분리 프로세스에서 실행할 수 있습니다.
- 함수는 실행하려는 코드에서 실행 환경을 추상화합니다. 예를 들어 AWS Lambda를 사용하면 인스턴스를 실행하지 않고도 코드를 실행할 수 있습니다.
다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.
컴퓨팅 사용을 설계할 때 사용 가능한 탄력성 메커니즘을 활용하여 수요 변화에 따라 성능을 유지할 수 있는 충분한 용량을 확보해야 합니다.
스토리지
특정 시스템을 위한 최적의 스토리지 솔루션은 액세스 방법(블록, 파일 또는 객체), 액세스 패턴(임의 또는 순차), 필요한 처리량, 액세스 빈도(온라인, 오프라인, 아카이브), 업데이트 빈도(WORM, 다이내믹), 가용성 및 내구성 제약에 따라 달라집니다. 잘 설계된 시스템은 여러 스토리지 솔루션을 사용하며 다양한 기능을 지원하여 성능을 향상시킵니다.
AWS에서 스토리지는 가상화되며 다양한 유형으로 제공됩니다. 따라서 스토리지 방법을 요구 사항에 더 쉽게 맞출 수 있으며, 온프레미스는 쉽게 달성할 수 없는 스토리지 옵션을 제공합니다. 예를 들어 Amazon S3는 11나인(99.999999999%)의 내구성을 위해 설계되었습니다. 또한 자기 하드 디스크 드라이브(HDD)를 사용하는 것에서 SSD로 변경하고 가상 드라이브를 한 인스턴스에서 다른 인스턴스로 몇 초 만에 쉽게 이동할 수 있습니다.
다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.
스토리지 솔루션을 선택할 때는 원하는 성능을 달성하기 위해 액세스 패턴에 맞는 솔루션을 사용해야 합니다.
데이터베이스
특정 시스템에 적합한 최적의 데이터베이스 솔루션은 가용성, 일관성, 파티션 내구성, 지연 시간, 내구성, 확장성 및 쿼리 기능에 대한 요구 사항에 따라 달라질 수 있습니다. 많은 시스템이 다양한 서브시스템에 대해 서로 다른 데이터베이스 솔루션을 사용하고, 성능을 향상시키기 위해 다양한 기능을 사용할 수 있습니다. 시스템에 맞는 잘못된 데이터베이스 솔루션과 기능을 선택하면 성능 효율이 저하될 수 있습니다.
Amazon RDS는 완전히 관리되는 관계 데이터베이스를 제공합니다. Amazon RDS를 사용하면 다운타임 없이 데이터베이스의 컴퓨팅 및 스토리지 리소스를 확장할 수 있습니다. Amazon DynamoDB는 전체 관리형 NoSQL 데이터베이스로, 모든 규모에서 한 자릿수의 지연 시간을 제공합니다. Amazon Redshift는 성능 또는 용량이 변경될 때 노드 수나 유형을 변경할 수 있는 관리형 페타바이트 규모의 데이터 웨어하우스입니다.
다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.
워크로드의 데이터베이스 접근 방식(RDBMS, NoSQL)은 성능 효율성에 큰 영향을 미치지만 데이터 기반 접근 방식이 아니라 조직 기본 설정에 따라 선택하는 영역인 경우가 많습니다. 스토리지와 마찬가지로 워크로드의 액세스 패턴을 고려하고, 데이터베이스가 아닌 다른 솔루션이 문제를 보다 효율적으로 해결할 수 있는지 여부도 고려해야 합니다(예: 검색 엔진 또는 데이터 웨어하우스 사용).
네트워크
특정 시스템에 적합한 최적의 네트워크 솔루션은 대기 시간, 처리량 요구 사항 등에 따라 달라집니다. 사용자 또는 온프레미스 리소스와 같은 물리적 제약으로 인해 위치 옵션이 실행되며, 이 옵션은 에지 기법이나 리소스 배치를 사용하여 오프셋할 수 있습니다.
AWS에서 네트워킹은 가상화되며 다양한 유형과 구성으로 제공됩니다. 따라서 필요에 따라 네트워킹 방법을 보다 쉽게 일치시킬 수 있습니다. AWS는 네트워크 트래픽을 최적화하기 위한 제품 기능(예: 향상된 네트워킹, Amazon EBS 최적화 인스턴스, Amazon S3 전송 가속, 동적 Amazon CloudFront)을 제공합니다. AWS는 네트워크 거리나 지터를 줄이기 위해 네트워킹 기능(예: Amazon Route 53 대기 시간 라우팅, AmazonVPC 엔드 포인트 및 AWS Direct Connect)도 제공합니다.
다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.
네트워크 솔루션을 선택할 때는 위치를 고려해야 합니다. AWS를 사용하면 거리를 줄이기 위해 사용할 위치에 리소스를 배치하도록 선택할 수 있습니다. 리전, 배치 그룹 및 엣지 로케이션을 활용하여 성능을 크게 향상시킬 수 있습니다.
검토
솔루션을 설계할 때 선택할 수 있는 옵션이 한정되어 있습니다. 그러나 시간이 지남에 따라 아키텍처의 성능을 향상시킬 수 있는 새로운 기술과 접근 방식을 사용할 수 있게 됩니다.
AWS를 사용하면 고객의 요구에 따라 지속적인 혁신을 활용할 수 있습니다. 새로운 지역, 에지 위치, 서비스 및 기능을 정기적으로 출시합니다. 이 중 어느 것이든 아키텍처의 성능 효율성을 긍정적으로 개선할 수 있습니다.
다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.
아키텍처의 성능이 제한된 위치를 이해하면 이러한 제약 조건을 완화할 수 있는 릴리스를 확인할 수 있습니다.
모니터링
아키텍처를 구현한 후에는 성능을 모니터링하여 고객이 인식하기 전에 문제를 해결할 수 있도록 해야 합니다. 임계값 위반 시 모니터링 메트릭을 사용하여 경보를 발생시켜야 합니다. 알람은 성능이 저하 된 구성 요소를 해결하기 위해 자동 작업을 트리거 할 수 있습니다.
Amazon CloudWatch는 알림 경보를 모니터링하고 전송할 수 있는 기능을 제공합니다. 자동화를 사용하여 Amazon Kinesis, Amazon SQS(Amazon Simple Queue Service) 및 AWS Lamba를 통해 작업을 트리거하여 성능 문제를 해결할 수 있습니다.
다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.
잘못된 탐지가 너무 많거나 데이터에 압도되지 않도록 하는 것이 효과적인 모니터링 솔루션을 갖추는 데 중요합니다. 자동 트리거는 인적 오류를 방지하고 문제 해결 시간을 단축할 수 있습니다. 운영 환경에서 시뮬레이션을 수행하여 경보 솔루션을 테스트하고 문제가 올바르게 인식되는지 확인할 수 있는 게임 데이를 계획합니다.
트레이드오프
솔루션을 설계할 때는 최적의 접근 방식을 선택할 수 있도록 트레이드오프를 고려해야 합니다. 상황에 따라 일관성, 내구성 및 공간을 시간 또는 지연 시간과 비교하여 더 높은 성능을 제공할 수 있습니다.
AWS를 사용하면 몇 분 만에 전 세계에 진출하고 리소스를 전 세계 여러 위치에 배포하여 최종 사용자에게 보다 가까이 다가갈 수 있습니다. 또한 읽기 전용 복제본을 데이터베이스 시스템과 같은 정보 저장소에 동적으로 추가하여 주 데이터베이스의 부하를 줄일 수 있습니다. AWS는 또한 메모리 내 데이터 저장소 또는 캐시를 제공하는 Amazon ElastiCache 및 최종 사용자에게 더 가까운 정적 컨텐츠의 복사본을 캐슁하는 Amazon CloudFront와 같은 캐싱 솔루션도 제공합니다. Amazon DynamoDB Accelerator(DAX)는 Amazon DynamoDB 앞에 읽기, 쓰기 캐싱 계층을 제공하여 동일한 API를 지원하지만 캐시에 있는 엔티티에 대해 밀리 초 미만의 대기 시간을 제공합니다.
다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.
트레이드오프는 아키텍처의 복잡성을 증가시킬 수 있으며 측정 가능한 이점을 얻을 수 있도록 부하 테스트를 필요로 합니다.
주요 AWS 서비스
성능 효율성에 필수적인 AWS 서비스는 Amazon CloudWatch로 리소스 및 시스템을 모니터링하여 전반적인 성능과 운영 상태를 파악할 수 있도록 지원합니다. 다음 서비스 및 기능은 성능 효율성의 네 가지 영역을 지원합니다.:
- 선택
- 컴퓨팅: Auto Scaling은 수요를 충족하고 응답 성을 유지하기에 충분한 인스턴스를 확보하는 데 중요합니다.
- 스토리지: Amazon EBS는 사용 사례에 맞게 최적화 할 수 있는 다양한 스토리지 옵션 (예 : SSD 및 PIOPS (Provisioned Input / Output Operations Per Second, 프로비저닝된 초당 입출력 작업))을 제공합니다. Amazon S3는 서버리스 컨텐츠 전송을 제공하며 Amazon S3 전송 가속화를 통해 장거리에서 파일을 빠르고 쉽고 안전하게 전송할 수 있습니다.
- 데이터베이스: Amazon RDS는 사용 사례에 맞게 최적화할 수 있는 다양한 데이터베이스 기능(예: PIOPS 및 읽기 복제본)을 제공합니다. Amazon DynamoDB는 어떤 규모에서도 한 자릿수의 지연 시간을 제공합니다.
- 네트워크: Amazon Route 53은 지연 시간 기반 라우팅을 제공합니다. Amazon VPC 끝점 및 AWS Direct Connect를 사용하면 네트워크 거리 또는 지터를 줄일 수 있습니다.
- 검토: AWS 블로그 및 AWS 웹 사이트의 What’s New 섹션은 새로 시작한 기능 및 서비스에 대해 알아보기 위한 리소스입니다.
- 모니터링: Amazon CloudWatch는 기존 모니터링 솔루션과 통합하고 AWS Lambda와 함께 사용하여 작업을 트리거할 수 있는 메트릭, 경보 및 알림을 제공합니다.
- 트레이드오프: Amazon ElastiCache, Amazon CloudFront 및 AWS Snowball은 성능을 향상시킬 수 있는 서비스입니다. Amazon RDS의 읽기 복제본을 사용하면 읽기 집약적인 워크로드를 확장할 수 있습니다.
리소스
성능 효율성을 위한 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하십시오.
문서
백서
동영상
- AWS re:Invent 2016: Scaling Up to Your First 10 Million Users (ARC201)
- AWS re:Invent 2017: Deep Dive on Amazon EC2 Instances
비용 최적화
비용 최적화 기반에는 시스템을 실행하여 가장 낮은 가격으로 비즈니스 가치를 제공할 수 있는 기능이 포함됩니다.
비용 최적화 기반은 설계 원리, 모범 사례 및 질문에 대한 개요를 제공합니다. 비용 최적화 기반 백서에서 구현에 대한 규범적 지침을 확인할 수 있습니다.
디자인 원칙
클라우드에는 비용 최적화를 위한 5 가지 설계 원칙이 있습니다:
- 소비 모델 채택: 정교한 예측을 사용하지 않고 비즈니스 요구 사항에 따라 필요한 컴퓨팅 리소스만 지불하고 사용량을 늘리거나 줄입니다. 예를 들어 개발과 테스트 환경은 보통 일주일 동안 하루에 8시간만 사용됩니다. 잠재적인 비용 절감에 75 % (40 시간 대 168 시간)를 사용하지 않을 때 이러한 리소스를 중단 할 수 있습니다.
- 전체적인 효율성 측정: 워크로드의 비즈니스 출력 및 워크로드 제공과 관련된 비용을 측정합니다. 이 방법을 사용하면 생산량 증가와 비용 절감을 통해 얻을 수 있는 이점을 파악할 수 있습니다.
- 데이터 센터 운영에 대한 비용 지출 중단: AWS는 랙 설치, 스택 설치 및 서버 전원 공급에 큰 부담을 주므로 IT 인프라보다는 고객 및 조직 프로젝트에 집중할 수 있습니다.
- 지출 분석 및 속성: 클라우드를 사용하면 시스템 사용량과 비용을 정확하게 파악할 수 있으므로 IT 비용을 개별 워크로드 소유자에게 투명하게 할당할 수 있습니다. 이를 통해 투자 수익률(ROI)을 측정하고 워크로드 소유자에게 리소스를 최적화하고 비용을 절감할 수 있습니다.
- 관리 및 애플리케이션 수준 서비스를 사용하여 소유 비용 절감: 클라우드에서 관리형 및 애플리케이션 수준 서비스는 이메일 전송이나 데이터베이스 관리와 같은 작업을 위해 서버를 유지 관리해야 하는 운영 부담을 제거합니다. 관리형 서비스는 클라우드 규모로 운영되므로 트랜잭션 또는 서비스당 비용을 절감할 수 있습니다.
정의
클라우드에는 비용 최적화를 위한 4가지 모범 사례 영역이 있습니다:
- 지출의 인식
- 비용 효율적인 리소스
- 수요와 공급
- 시간 경과에 따른 최적화
다른 기반과 마찬가지로 고려해야 할 트레이드오프가 있습니다. 예를 들어, 시장 출시 속도나 비용에 대해 우선 순위를 매기겠습니까? 경우에 따라 초기 비용 최적화에 투자하지 않고 신속하게 시장에 진출하거나, 새로운 기능을 제공하거나, 단순히 마감일을 맞추는 등 속도에 우선 순위를 두는 것이 가장 좋습니다. 설계 결정은 때때로 경험적 데이터가 아닌 성급함으로 유도됩니다. 시간이 지남에 따라 가장 비용 효율적인 워크로드를 벤치마킹하는 데 시간을 소비하기 보다는 “만일 대비”를 과다하게 보상하려는 유혹이 항상 존재하기 때문입니다. 이로 인해 과도하게 프로비저닝되고 최적화되지 않은 구현이 이루어지며, 이는 수명 주기 내내 정적 상태를 유지합니다.
다음 섹션에서는 구현의 초기 및 지속적인 비용 최적화를 위한 기술과 전략적 지침을 제공합니다.
모범 사례
지출의 인식
클라우드를 통해 유연성과 민첩성이 향상됨에 따라 혁신과 빠른 개발 및 구현이 촉진됩니다. 이를 통해 하드웨어 사양 식별, 가격 견적 협상, 구매 주문 관리, 발송 스케줄링, 리소스 배포 등 사내 인프라 프로비저닝과 관련된 수동 프로세스와 시간이 제거됩니다. 그러나 사용 편의성과 사실상 무제한의 온디맨드 용량으로 인해 지출에 대한 새로운 사고방식이 필요합니다.
많은 기업이 다양한 팀에서 운영하는 여러 시스템으로 구성되어 있습니다. 리소스 비용을 개별 조직 또는 제품 소유자에게 귀속시키는 기능은 효율적인 사용 행동을 촉진하고 낭비를 줄이는 데 도움이 됩니다. 정확한 비용 귀속 기능을 사용하면 어떤 제품이 진정으로 수익성이 있는지 알 수 있으며, 예산을 어디에 할당할지 보다 정확한 결정을 내릴 수 있습니다.
AWS에서는 비용 탐색기를 사용하여 지출을 추적하고 정확한 지출처에 대한 통찰력을 얻을 수 있습니다. AWS 예산을 사용하면 사용량 또는 비용이 예측과 일치하지 않을 경우 알림을 보낼 수 있습니다. 리소스 태깅을 사용하여 사용량 및 비용에 비즈니스 및 조직 정보를 적용할 수 있습니다. 이를 통해 조직의 관점에서 최적화에 대한 추가적인 통찰력을 얻을 수 있습니다.
다음 질문은 비용 최적화를 위한 이러한 고려사항에 초점을 맞춥니다. (비용 최적화 질문, 답변 및 모범 사례 목록은 부록 참조)
비용 할당 태그를 사용하여 AWS 사용량 및 비용을 분류하고 추적할 수 있습니다. EC2 인스턴스 또는 S3 버킷과 같은 AWS 리소스에 태그를 적용하면 AWS는 사용량 및 태그가 포함된 비용 및 사용량 보고서를 생성합니다. 조직 범주(예: 비용 센터, 워크로드 이름 또는 소유자)를 나타내는 태그를 적용하여 여러 서비스에 걸쳐 비용을 구성할 수 있습니다.
태그가 지정된 리소스를 엔티티 라이프사이클 추적(직원, 프로젝트)과 결합하면 더 이상 조직에 가치를 창출하지 못하고 폐기해야 하는 고립된 리소스 또는 프로젝트를 식별할 수 있습니다. 과금 경고를 설정하여 예상 초과 지출을 통지할 수 있으며, AWS Simple Monthly Calculator를 사용하면 데이터 전송 비용을 계산할 수 있습니다.
비용 효율적인 리소스
워크로드에 적합한 인스턴스와 리소스를 사용하는 것이 비용 절감의 핵심입니다. 예를 들어, 보고 프로세스는 작은 서버에서 실행하는 데 5시간이 걸리지만 두 배나 비싼 큰 서버에서 실행하는 데는 1시간이 걸릴 수 있습니다. 두 서버 모두 동일한 결과를 제공하지만, 소규모 서버는 시간이 지날수록 더 많은 비용을 발생시킵니다.
잘 설계된 워크로드는 가장 비용 효율적인 리소스를 사용하므로 상당한 긍정적인 경제적 영향을 미칠 수 있습니다. 또한 관리 서비스를 사용하여 비용을 절감할 수도 있습니다. 예를 들어, 이메일을 전송하기 위해 서버를 유지하는 대신 메시지당 요금을 청구하는 서비스를 사용할 수 있습니다.
AWS는 EC2 및 기타 서비스에서 사용자의 요구에 가장 적합한 방식으로 인스턴스를 획득할 수 있는 다양한 유연하고 비용 효율적인 가격 옵션을 제공합니다. 온디맨드 인스턴스를 사용하면 최소한의 약속 없이도 시간당 컴퓨팅 용량에 대한 비용을 지불할 수 있습니다. 예약된 인스턴스를 통해 용량을 예약하고 주문 시 가격을 최대 75% 할인된 가격으로 제공할 수 있습니다. 스폿 인스턴스를 사용하면 사용하지 않는 Amazon EC2 용량을 활용하고 주문형 가격을 최대 90%까지 할인된 가격으로 제공할 수 있습니다. 스폿 인스턴스는 시스템이 상태 비저장 웹 서버, 배치 프로세싱 또는 HPC 및 빅데이터 사용 시 개별 서버가 동적으로 오고갈 수 있는 일련의 서버를 사용하는 것을 허용할 수 있는 경우에 적합합니다.
적절한 서비스를 선택하면 CloudFront와 같은 사용량 및 비용이 절감됩니다. CloudFront는 데이터 전송을 최소화하거나 RDS의 Amazon Ourora를 활용하여 값비싼 데이터베이스 라이센스 비용을 제거하는 등 비용을 완전히 제거할 수 있습니다.
다음 질문은 비용 최적화를 위한 이러한 고려 사항에 초점을 맞춥니다.
서비스 선택 중에 비용을 계산하고, Cost Explorer 및 AWS Trusted Advisor와 같은 도구를 사용하여 AWS 사용량을 정기적으로 검토함으로써 적극적으로 활용률을 모니터링하고 그에 따라 배포를 조정할 수 있습니다.
수요와 공급의 일치
수요에 최적화된 공급은 워크로드에 가장 낮은 비용을 제공하지만 프로비저닝 시간 및 개별 리소스 장애를 허용하려면 충분한 추가 공급도 필요합니다. 수요는 수정되거나 변동될 수 있으므로 관리 비용이 크게 들지 않도록 메트릭과 자동화가 필요합니다.
AWS에서는 수요에 맞게 리소스를 자동으로 프로비저닝할 수 있습니다. Auto Scaling 및 수요, 버퍼 및 시간 기반 접근 방식을 사용하면 필요에 따라 리소스를 추가하고 제거할 수 있습니다. 수요의 변화를 예측할 수 있다면 더 많은 비용을 절약하고 워크로드 요구에 맞는 리소스를 확보할 수 있습니다.
다음 질문은 비용 최적화를 위한 이러한 고려 사항에 초점을 맞춥니다.
수요 대비 공급에 맞게 설계할 때는 사용 패턴과 새로운 리소스를 프로비저닝하는 데 걸리는 시간을 적극적으로 고려합니다.
시간 경과에 따른 최적화
AWS는 새로운 서비스와 기능을 출시할 때 기존 아키텍처 결정을 검토하여 가장 비용 효율적인 결정을 유지하는 것이 좋습니다. 요구사항이 변경되면 더 이상 필요하지 않은 리소스, 전체 서비스 및 시스템을 폐기하는 데 적극적이어야 합니다.
AWS의 관리형 서비스는 워크로드를 크게 최적화할 수 있으므로 새로운 관리형 서비스와 기능을 사용할 수 있을 때 이를 알아야 합니다. 예를 들어 Amazon RDS 데이터베이스를 실행하는 것이 Amazon EC2에서 자체 데이터베이스를 실행하는 것보다 저렴할 수 있습니다.
다음 질문은 비용 최적화를 위한 이러한 고려 사항에 초점을 맞춥니다.
정기적으로 배포를 검토할 때 새로운 서비스를 통해 비용을 절감할 수 있는 방법을 평가합니다. 예를 들어 Amazon Aurora on RDS 사용하면 관계형 데이터베이스의 비용을 절감할 수 있습니다.
주요 AWS 서비스
비용 최적화에 필수적인 툴은 비용 탐색기입니다. 비용 탐색기는 워크로드와 조직 전반에서 사용량에 대한 가시성과 통찰력을 확보할 수 있도록 도와줍니다. 다음 서비스 및 기능은 비용 최적화의 네 가지 영역을 지원합니다.:
- 지출의 인식: AWS Cost Explorer를 사용하면 사용량을 자세히 보고 추적할 수 있습니다. AWS 예산은 사용량 또는 지출이 실제 또는 예상 예산 금액을 초과하면 이를 알려줍니다.
- 비용 효율적인 리소스: 비용 탐색기를 사용하여 예약된 인스턴스 권장 사항을 확인하고 시간이 지남에 따라 AWS 리소스에 지출하는 비용의 패턴을 볼 수 있습니다. Amazon CloudWatch 및 Trusted Advisor를 사용하여 리소스 크기를 적절하게 조정할 수 있습니다. RDS에서 Amazon Aurora를 사용하여 데이터베이스 라이센스 비용을 제거할 수 있습니다. AWS Direct Connect 및 Amazon CloudFront를 사용하여 데이터 전송을 최적화할 수 있습니다.
- 수요와 공급: Auto Scaling능을 사용하면 과도한 지출 없이 수요에 맞게 리소스를 추가하거나 제거할 수 있습니다.
- 시간 경과에 따른 최적화: AWS 뉴스 블로그 및 AWS 웹 사이트의 새로운 기능 섹션은 새로 출시된 기능과 서비스에 대한 정보를 얻기 위한 자료입니다. AWS Trusted Advisor는 AWS 환경을 검사하고 사용되지 않거나 유휴 리소스를 제거하거나 예약된 인스턴스 용량을 할당하여 비용을 절감할 수 있는 기회를 찾습니다.
리소스
비용 최적화를 위한 모범 사례에 대해 자세히 알아보려면 다음 리소스를 참조합니다.
문서
백서
동영상
Tool
검토 프로세스
아키텍처에 대한 검토는 지속적으로 이루어져야 하며, 깊이 잠수하도록 유도하는 흠결이 없는 접근 방식을 사용해야 합니다. 감사가 아닌 대화이자 대화인 경량화 프로세스(일수가 아닌 시간)이어야 합니다. 아키텍처를 검토하는 목적은 해결해야 할 중요한 문제 또는 개선해야 할 영역을 식별하는 것입니다. 검토 결과는 작업 부하를 사용하는 고객의 경험을 개선해야 하는 일련의 조치입니다.
“아키텍처” 섹션에서 논의한 바와 같이, 각 팀 구성원이 건축의 품질에 대해 책임을 지도록 할 것입니다. 아키텍처를 구축하는 팀원들은 공식적인 검토 회의를 개최하는 대신 잘 설계된 프레임워크를 사용하여 아키텍처를 지속적으로 검토할 것을 권장합니다. 지속적인 접근 방식을 통해 팀원들은 아키텍처가 발전함에 따라 답변을 업데이트하고, 기능을 제공할 때 아키텍처를 개선할 수 있습니다.
AWS 우수 관리 기능은 AWS가 시스템 및 서비스를 내부적으로 검토하는 방식에 따라 조정됩니다. 이 솔루션은 아키텍처 접근 방식에 영향을 미치는 설계 원칙과 사람들이 종종 RSA(근본 원인 분석)에 등장하는 영역을 소홀히 하지 않도록 보장하는 질문을 기반으로 작성되었습니다. 내부 시스템, AWS 서비스 또는 고객에게 중대한 문제가 발생할 때마다 RCA를 검토하여 사용하는 검토 프로세스를 개선할 수 있는지 확인합니다.
변경하기 어려운 일방 도어를 방지하기 위해 설계 단계 초기에 제품 라이프사이클의 주요 이정표에 검토를 적용해야 합니다. 그런 다음 라이브 날짜 전에 검토해야 합니다. 가동 후 워크로드는 새로운 기능을 추가하고 기술 구현을 변경하면서 계속 발전할 것입니다. 워크로드 아키텍처는 시간이 지남에 따라 변경됩니다. 여러분은 Well- Architected을 따라야 합니다. 이를 발전시킬 때 아키텍처 특성이 저하되는 것을 막을 수 있습니다. 중요한 아키텍처를 변경할 때는 잘 설계된 검토를 포함한 일련의 Well- Architected 프로세스를 따라야 합니다.
검토를 일회성 스냅샷 또는 독립적 측정으로 사용하려면 대화에서 모든 적합한 사용자를 확보해야 합니다. 종종 우리는 팀이 실제로 구현한 것을 이해하는 것이 검토가 처음이라는 것을 알게 됩니다. 다른 팀의 워크로드를 검토할 때 잘 작동하는 접근 방식은 대부분의 질문에 대한 답을 얻을 수 있는 아키텍처에 대한 일련의 비공식적인 대화를 나누는 것입니다. 그런 다음 한두 번의 미팅을 통해 명확성을 확보하거나 모호하거나 위험을 인지하는 영역을 자세히 살펴볼 수 있습니다.
다음은 미팅을 용이하게 하기 위한 몇 가지 제안 항목입니다.:
- 화이트 보드가있는 회의실
- 다이어그램이나 디자인 노트에서 인쇄
- Out-of-Band 외 조사에 답해야하는 질문 목록 (예 : “암호화를 활성화 했습니까?”)
검토를 완료한 후에는 비즈니스 상황에 따라 우선 순위를 지정할 수 있는 문제 목록을 작성해야 합니다. 또한 이러한 문제가 팀의 일상적인 업무에 미치는 영향도 고려해야 합니다. 이러한 문제를 조기에 해결할 경우 반복적인 문제를 해결하는 대신 비즈니스 가치 창출에 집중할 수 있습니다. 문제를 해결하면서 검토 내용을 업데이트하여 아키텍처가 어떻게 개선되고 있는지 확인할 수 있습니다.
검토를 완료한 후 검토의 가치는 분명하지만, 처음에는 새로운 팀이 저항할 수 있습니다. 다음은 검토의 이점에 대해 팀 교육을 통해 해결할 수 있는 몇 가지 이의 제기입니다.:
- “우리는 너무 바쁘다!”(종종 팀이 큰 런칭을 준비 할 때)
- 만약 여러분이 큰 런칭을 준비하고 있다면, 여러분은 그것이 순조롭게 진행되기를 원할 것입니다. 검토를 통해 놓쳤을 수 있는 문제를 이해할 수 있습니다.
- 제품 수명 주기 초기에 검토를 수행하여 위험을 파악하고 기능 제공 로드맵에 맞는 완화된 계획을 개발할 것을 권장합니다.
- “우리는 결과를 위해 다른걸 할 시간이 없습니다!” (오펜은 슈퍼볼과 같은 고정된 행사가 있을 때 그들이 목표로 하고 있다고 말했습니다.)
- 이 이벤트는 이동할 수 없습니다. 아키텍처의 위험 요소를 모른 채 이 문제를 해결하려고 합니까? 이러한 모든 문제를 해결하지 않더라도, 실현될 경우 문제를 처리하는 플레이북을 계속 보유할 수 있습니다.
- “우리는 다른 사람들이 솔루션 구현의 비밀을 알기를 원하지 않습니다!”
- Well-Architected Framework의 질문을 팀에게 제시하면 어떠한 질문도 상업적 또는 기술적 적합성 정보를 제공하지 않습니다.
조직의 팀과 여러 검토를 수행함에 따라 주제별 문제를 식별할 수 있습니다. 예를 들어 팀 그룹이 특정 기둥 또는 항목에 여러 가지 문제가 있는 것을 볼 수 있습니다. 모든 리뷰를 총체적으로 살펴보고, 이러한 주제적 문제를 해결하는 데 도움이 될 수 있는 메커니즘, 교육 또는 주요 엔지니어링 대화를 파악해야 합니다.
결론
AWS Well-Architected Framework는 클라우드에서 안정적이고, 안전하고, 효율적이며, 비용 효율적인 시스템을 설계하고 운영할 수 있는 5가지 기반에 걸친 아키텍처 모범 사례를 제공합니다. Framework에서는 기존 아키텍처 또는 제안된 아키텍처를 검토할 수 있는 일련의 질문을 제공합니다. 또한 각 기반에 대한 일련의 AWS 모범 사례도 제공합니다. 아키텍처의 프레임워크를 사용하면 안정적이고 효율적인 시스템을 생산하여 기능 요구사항에 집중할 수 있습니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
