# 변경 사항 관리
**Topics**
+ [REL 6 워크로드 리소스는 어떻게 모니터링합니까?](w2aac19b9b9b5.md)
+ [REL 7 수요 변경에 따라 조정되도록 워크로드를 설계하려면 어떻게 해야 합니까?](w2aac19b9b9b7.md)
+ [REL 8 변경 사항은 어떻게 적용합니까?](w2aac19b9b9b9.md)
# REL 6 워크로드 리소스는 어떻게 모니터링합니까?
로그와 지표는 워크로드의 상태를 파악할 수 있는 유용한 도구입니다. 로그 및 지표를 모니터링하여 임계값을 초과하거나 중요한 이벤트가 발생하면 알림을 보내도록 워크로드를 구성할 수 있습니다. 모니터링을 수행하면 워크로드가 저성능 임계값을 초과하거나 장애가 발생할 때를 인식하고 이에 대응하여 자동으로 복구할 수 있습니다.
**Topics**
+ [REL06-BP01 워크로드의 모든 구성 요소 모니터링(생성)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 지표 정의 및 계산(집계)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 알림 전송(실시간 처리 및 경보)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 응답 자동화(실시간 처리 및 경보)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 분석](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 정기적인 검토 시행](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 시스템을 통한 요청의 종단 간 추적 모니터링](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 워크로드의 모든 구성 요소 모니터링(생성)
Amazon CloudWatch 또는 서드파티 도구를 사용하여 워크로드의 구성 요소를 모니터링합니다. AWS Health 대시보드를 사용하여 AWS 서비스를 모니터링합니다.
프런트엔드, 비즈니스 로직 및 스토리지 계층을 포함하여 워크로드의 모든 구성 요소를 모니터링해야 합니다. 필요한 경우 주요 지표를 정의하고 로그에서 지표를 추출하는 방법을 설명하고 해당 경보 이벤트를 트리거하는 임계값을 설정합니다. 지표가 워크로드의 핵심 성과 지표(KPI)와 연관이 있도록 해야 하며 지표와 로그를 사용하여 서비스 성능 저하의 조기 지표를 파악합니다. 예를 들어, 분당 성공적으로 처리된 주문 수와 같은 비즈니스 성과와 관련된 지표는 CPU 사용량과 같은 기술적 지표보다 워크로드 문제를 더 빠르게 알려줍니다. AWS Health 대시보드를 사용하여 AWS 리소스의 기반이 되는 AWS 서비스의 성능 및 가용성에 대한 맞춤형 보기를 제공합니다.
클라우드에서 모니터링은 새로운 기회를 제공합니다. 대부분의 클라우드 공급업체는 사용자 지정 가능한 후크를 개발했으며 여러 계층의 워크로드를 모니터링하는 데 도움이 되는 인사이트를 제공할 수 있습니다. Amazon CloudWatch 등의 AWS 서비스는 통계 및 기계 학습 알고리즘을 적용하여 시스템 및 애플리케이션의 지표를 지속적으로 분석하고, 일반적인 기준을 결정하며, 사용자의 개입을 최소화하면서 이상 현상을 알립니다. 이상 탐지 알고리즘은 지표의 계절성과 추세 변화를 설명합니다.
AWS는 사용할 수 있는 모니터링 및 로그 정보를 풍부하게 제공하며 사용자는 워크로드별 지표를 정의하고, 수요가 있는 프로세스를 변경하고, ML 전문성과 상관없이 기계 학습 기법을 도입하는 데 이 정보를 사용할 수 있습니다.
또한 모든 외부 엔드포인트를 모니터링하여 기본 구현과 독립되어 있는지 확인합니다. 이 능동 모니터링은 *사용자 Canary라고도 하는*가상 트랜잭션에도 수행할 수 있지만 카나리 배포와 혼동해서는 안 됩니다. 가상 트랜잭션은 워크로드의 클라이언트가 수행하는 일반적인 다수의 태스크 매칭 작업을 주기적으로 실행합니다. 이 태스크의 기간은 짧아야 하며 테스트 중에 워크로드에 과부하가 발생하지 않아야 합니다. Amazon CloudWatch Synthetics를 사용하면 엔드포인트 및 API 모니터링을 위한 [가상 Canary를 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 할 수 있습니다. 가상 Canary 클라이언트 노드를 AWS X-Ray 콘솔과 함께 사용하여 선택한 기간에 오류, 장애 또는 조절 속도 문제를 경험하는 가상 Canary를 식별할 수도 있습니다.
**원하는 결과:**
워크로드의 모든 구성 요소로부터 핵심적인 지표를 수집하고 사용하여 워크로드 안정성과 최적의 사용자 경험을 보장합니다. 워크로드가 비즈니스 성과를 달성하지 못하고 있음을 탐지하면 재해 상황임을 빠르게 선언하고 인시던트에서 복구할 수 있습니다.
**일반적인 안티 패턴:**
+ 워크로드에 대한 외부 인터페이스만 모니터링
+ 워크로드별 지표를 생성하지 않으며 워크로드에서 사용하는 AWS 서비스에서 제공되는 지표에만 의존함
+ 워크로드에서 기술적인 지표만 사용하며 워크로드가 기여하는 비기술적 KPI와 관련한 지표는 모니터링하지 않음
+ 프로덕션 트래픽 및 단순한 상태 확인에 의존하여 워크로드 상태를 모니터링하고 평가함
**이 모범 사례 정립의 이점:** 워크로드의 모든 티어에서 모니터링할 경우 워크로드를 구성하는 구성 요소의 문제를 보다 신속하게 예측하고 해결할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
1. **가능한 경우 로깅을 활성화합니다.** 모니터링 데이터는 워크로드의 모든 구성 요소로부터 수집해야 합니다. S3 Access Logs 등의 추가 로깅을 활성화하고 워크로드가 워크로드별 데이터를 로깅하도록 합니다. Amazon ECS, Amazon EKS, Amazon EC2, Elastic Load Balancing, AWS Auto Scaling, Amazon EMR 등의 서비스로부터 CPU, 네트워크 I/O, 디스크 I/O 평균 지표를 수집합니다. 참조 [CloudWatch 지표를 게시하는 AWS 서비스](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 에서 CloudWatch에 지표를 게시하는 AWS 서비스의 목록을 참조합니다.
1. **모든 기본 지표를 검토하고 데이터 수집에 간극이 있는지 확인합니다.** 모든 서비스에서는 기본 지표를 생성합니다. 기본 지표를 수집하면 워크로드 구성 요소 간의 종속성을 이해하고 구성 요소 안정성과 성능이 워크로드에 어떤 영향을 미치는지 파악할 수 있습니다. 직접 지표를 생성하고 [지표를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) CloudWatch에 게시할 수 있습니다. AWS CLI 또는 API를 사용하면 됩니다. 이
1. **모든 지표를 평가하여 워크로드의 각 AWS 서비스에 어떤 지표를 알릴지 결정합니다.** 워크로드 안정성에 큰 영향을 미치는 지표의 하위 집합을 선택할 수도 있습니다. 핵심 지표와 임계값에 집중하면 [알림](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 의 수를 정리하고 허위 양성을 최소화할 수 있습니다.
1. **알림과 알림이 트리거된 후 워크로드의 복구 프로세스를 정의합니다.** 알림을 정의하면 인시던트로부터 복구하는 데 필요한 단계를 빠르게 알리고, 에스컬레이션하고, 단계를 따라 사전에 정해진 Recovery Time Objective(RTO)를 달성할 수 있습니다. 전용 인프라에서 [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) 를 사용하여 자동화된 워크플로를 호출하고 정의된 임계값에 따라 복구 절차를 시작할 수 있습니다.
1. **워크로드 상태에 대한 관련 데이터를 수집하기 위해 가상 트랜잭션을 사용하는 방법을 알아보세요.** 가상 모니터링은 고객과 같은 경로를 따르고 같은 작업을 수행하므로 워크로드에 고객 트래픽이 없더라도 고객 경험을 지속적으로 확인할 수 있습니다. 이렇게 [가상 트랜잭션을](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)사용함으로써 고객보다 먼저 문제를 발견할 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md)
**관련 문서:**
+ [AWS Health 대시보드 시작하기 - 계정 상태](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [CloudWatch 지표를 게시하는 AWS 서비스](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Network Load Balancer에 대한 액세스 로그](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Application Load Balancer에 대한 액세스 로그](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [AWS Lambda의 Amazon CloudWatch Logs 액세스](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Amazon S3 서버 액세스 로깅](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Classic Load Balancer에 대한 액세스 로그 활성화(Classic Load Balancer에 대한 액세스 로그 활성화)](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Amazon S3로 로그 데이터 내보내기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Amazon EC2 인스턴스에 CloudWatch 에이전트 설치](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon CloudWatch Logs란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**사용 설명서:**
+ [추적 생성](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Amazon EC2 Linux 인스턴스의 메모리 및 디스크 지표 모니터링](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [컨테이너 인스턴스와 CloudWatch Logs 사용](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [VPC 흐름 로그](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [Amazon DevOps Guru란 무엇입니까?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [AWS X-Ray란 무엇입니까?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**관련 블로그:**
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**관련 예시 및 워크숍:**
+ [AWS Well-Architected 실습: 운영 우수성 - 종속성 모니터링](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [관찰 가능성 워크숍](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 지표 정의 및 계산(집계)
로그 데이터를 저장하고 필요한 경우 필터를 적용하여 특정 로그 이벤트 수 또는 로그 이벤트 타임스탬프에서 계산된 지연 시간과 같은 지표를 계산합니다.
Amazon CloudWatch 및 Amazon S3는 기본 집계 및 스토리지 계층으로 사용됩니다. AWS Auto Scaling 및 Elastic Load Balancing와 같은 일부 서비스에서는 클러스터나 인스턴스 전반에 걸쳐 CPU 로드 또는 평균 요청 지연 시간 관련 기본 지표가 기본적으로 제공됩니다. VPC Flow Logs 및 AWS CloudTrail과 같은 스트리밍 서비스의 경우에는 이벤트 데이터가 CloudWatch Logs로 전달되며, 이벤트 데이터에서 지표를 추출하려면 지표 필터를 정의하고 적용해야 합니다. 이렇게 하면 시계열 데이터가 나오며 알림을 트리거하도록 정의한 CloudWatch 경보에 대한 입력으로 이 데이터를 사용할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 지표를 정의 및 계산(집계)합니다. 로그 데이터를 저장하고 필요한 경우 필터를 적용하여 특정 로그 이벤트 수 또는 로그 이벤트 타임스탬프에서 계산된 지연 시간과 같은 지표를 계산합니다.
+ 지표 필터는 로그 데이터가 CloudWatch Logs에 전송될 때 찾아야 하는 용어와 패턴을 정의합니다. CloudWatch Logs는 이 지표 필터를 사용하여 로그 데이터를 숫자 형식의 CloudWatch 지표로 변환하여 사용자가 그래프를 작성하거나 경보를 설정할 수 있도록 합니다.
+ [로그 데이터 검색 및 필터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ 신뢰할 수 있는 서드 파티 도구를 사용하여 로그를 집계합니다.
+ 해당 서드 파티의 지침을 따릅니다. 대부분의 서드 파티 제품은 CloudWatch 및 Amazon S3와 통합됩니다.
+ 일부 AWS 서비스는 로그를 Amazon S3에 직접 게시할 수 있습니다. Amazon S3에 저장하는 것이 로그의 주요 요구 사항인 경우, 추가 인프라를 설정하지 않고도 로그를 생성하는 서비스가 로그를 Amazon S3로 직접 전송하도록 할 수 있습니다.
+ [Amazon S3로 로그를 직접 전송](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch Logs Insights 샘플 쿼리](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [로그 데이터 검색 및 필터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon S3로 로그를 직접 전송](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP03 알림 전송(실시간 처리 및 경보)
중요한 이벤트가 발생할 때 알아야 하는 조직에 알림이 전송됩니다.
Amazon Simple Notification Service(Amazon SNS) 주제로 알림을 전송한 다음 원하는 수의 구독자에게 푸시할 수 있습니다. 예를 들어 Amazon SNS는 기술 직원이 응답할 수 있도록 특정 이메일 별칭으로 알림을 전달할 수 있습니다.
**일반적인 안티 패턴:**
+ 임계값을 너무 낮게 구성하여 알림이 너무 많이 전송되도록 함
+ 향후 조사할 수 있도록 경보를 보관하지 않음
**이 모범 사례 정립의 이점:** 이벤트에 대한 알림(응답할 수 있고 자동으로 해결할 수 있는 알림 포함)을 통해 이벤트 기록을 확보할 수 있으며 향후에 다른 방식으로 이벤트를 처리할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 실시간 처리 및 경보 설정을 수행합니다. 중요한 이벤트가 발생할 때 알아야 하는 조직에 알림이 전송됩니다.
+ Amazon CloudWatch 대시보드는 CloudWatch 콘솔의 맞춤형 홈페이지로, 다른 리전에 분산되어 있는 리소스까지 포함하여 모든 리소스를 단일 보기에서 모니터링하는 데 이용할 수 있습니다.
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ 지표가 한도를 초과하는 경우 경보를 생성합니다.
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## 리소스
**관련 문서:**
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# REL06-BP04 응답 자동화(실시간 처리 및 경보)
: 이벤트가 감지되면 자동화를 사용하여 실패한 구성 요소를 대체하는 등의 조치를 취합니다.
알림을 통해 AWS Auto Scaling 이벤트를 트리거할 수 있으며, 그러면 클러스터가 수요 변경에 대응할 수 있습니다. 서드 파티 티켓 시스템용 통합 지점으로 사용 가능한 Amazon Simple Queue Service(Amazon SQS)로 알림을 전송할 수도 있습니다. AWS Lambda에서도 알림을 구독하여 변경에 동적으로 대응하는 비동기 서버리스 모델을 사용자에게 제공할 수 있습니다. AWS Config는 AWS 리소스 구성을 지속적으로 모니터링하고 기록하며 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 을 트리거하여 문제를 해결할 수 있습니다.
Amazon DevOps Guru는 애플리케이션 리소스가 비정상적으로 작동하는지를 자동으로 모니터링하고 표적화된 권장 사항을 제공하여 문제 파악 및 해결 시간을 단축합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ Amazon DevOps Guru를 사용하여 자동화된 작업을 수행합니다. Amazon DevOps Guru는 애플리케이션 리소스가 비정상적으로 작동하는지를 자동으로 모니터링하고 표적화된 권장 사항을 제공하여 문제 파악 및 해결 시간을 단축합니다.
+ [Amazon DevOps Guru란 무엇입니까?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ AWS Systems Manager를 사용하여 자동화된 작업을 수행합니다. AWS Config는 AWS 리소스 구성을 지속적으로 모니터링하고 기록하며 AWS Systems Manager Automation을 트리거하여 문제를 해결할 수 있습니다.
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Systems Manager Automation 문서를 생성하고 사용합니다. 이는 자동화 프로세스를 실행할 때 Systems Manager가 관리형 인스턴스 및 기타 AWS 리소스에서 수행하는 작업을 정의합니다.
+ [자동화 문서 작업(플레이북)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ Amazon CloudWatch가 경보 상태 변화 이벤트를 Amazon EventBridge에 전송합니다. 응답을 자동화하는 EventBridge 규칙을 생성합니다.
+ [AWS 리소스의 이벤트에서 트리거되는 EventBridge 규칙 생성](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ 응답 자동화를 위한 계획을 수립하고 실행합니다.
+ 모든 알림 응답 절차의 인벤토리를 작성합니다. 작업 순위를 정하기 전에 알림 응답을 계획해야 합니다.
+ 수행해야 할 특정 작업이 있는 모든 작업의 인벤토리를 작성합니다. 이러한 작업은 대부분 런북에 문서화됩니다. 예기치 않은 이벤트의 알림에 대한 플레이북도 있어야 합니다.
+ 런북 및 플레이북을 조사하여 자동화 가능한 작업을 모두 파악합니다. 일반적으로, 정의할 수 있는 작업은 대부분 자동화할 수 있습니다.
+ 오류가 발생하기 쉽거나 시간이 많이 걸리는 활동을 최우선으로 합니다. 오류의 원인을 제거하고 해결 시간을 단축하는 데 따른 효과가 가장 크기 때문입니다.
+ 자동화를 수행하기 위한 계획을 수립합니다. 자동화 및 업데이트를 위한 계획을 활성 상태로 유지합니다.
+ 수작업 요구 사항을 검토하여 자동화할 여지가 없는지 확인합니다. 수작업 프로세스를 검토하여 자동화 기회를 확인합니다.
## 리소스
**관련 문서:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS 리소스의 이벤트에서 트리거되는 EventBridge 규칙 생성](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Amazon DevOps Guru란 무엇입니까?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [자동화 문서 작업(플레이북)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
# REL06-BP05 분석
로그 파일 및 지표 기록을 수집하고 이를 분석하여 더 광범위한 추세 및 워크로드 인사이트를 확보합니다.
Amazon CloudWatch Logs Insights는 로그 데이터를 분석하는 데 사용할 수 있는 [단순하지만 강력한 쿼리 언어](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) 를 지원합니다. Amazon CloudWatch Logs 또한 구독을 지원하므로 데이터를 Amazon S3로 원활하게 보내 여기서 데이터를 사용하거나 Amazon Athena로 보내 데이터를 쿼리할 수 있습니다. 다양한 형식의 쿼리도 지원됩니다. 참조 [지원되는 SerDes 및 데이터 형식](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) (Amazon Athena 사용 설명서에 있음)에서 자세한 내용을 참조하세요. 방대한 로그 파일 세트를 분석하려면 Amazon EMR 클러스터를 실행하여 페타바이트 규모의 분석을 실행할 수 있습니다.
AWS 파트너와 서드파티에서 제공하는 다양한 도구를 집계, 처리, 저장 및 분석에 사용할 수 있습니다. 이러한 도구에는 New Relic, Splunk, Loggly, Logstash, CloudHealth 및 Nagios가 포함됩니다. 그러나 시스템과 애플리케이션 외부에서 생성되는 로그는 각 클라우드 공급자별로 다르며 각 서비스별로 다른 경우도 많습니다.
모니터링 프로세스에서 간과되는 경우가 많은 작업 중 하나로 데이터 관리를 들 수 있습니다. 데이터 모니터링을 위한 보존 요구 사항을 확인한 후 그에 따라 수명 주기 정책을 적용해야 합니다. Amazon S3는 S3 버킷 수준에서 수명 주기 관리를 지원합니다. 버킷의 각 경로에 이 수명 주기 관리 기능을 각기 다르게 적용할 수 있습니다. 수명 주기 종료가 가까워지면 장기 저장을 위해 데이터를 Amazon Glacier로 전환한 다음 보존 기간이 종료되면 데이터를 만료 처리할 수 있습니다. S3 Intelligent-Tiering 스토리지 클래스는 성능 영향이나 운영 오버헤드 없이 데이터를 가장 비용 효율적인 티어로 자동으로 이동하여 비용을 최적화하도록 설계되었습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ CloudWatch Logs Insights를 사용하면 Amazon CloudWatch Logs의 로그 데이터를 대화식으로 검색하고 분석할 수 있습니다.
+ [CloudWatch Logs Insights를 사용한 로그 데이터 분석](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Logs Insights 샘플 쿼리](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ Amazon CloudWatch Logs를 사용하여 사용할 수 있는 Amazon S3에 로그를 전송하거나 Amazon Athena에 전송하여 데이터를 쿼리합니다.
+ [Athena를 사용하여 Amazon S3 서버 액세스 로그를 분석하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ 서버 액세스 로그 버킷에 대한 S3 수명 주기 정책을 생성합니다. 로그 파일을 주기적으로 제거하도록 수명 주기 정책을 구성합니다. 이러한 정책을 구성하면 Athena에서 각 쿼리에 대해 분석되는 데이터의 양이 줄어듭니다.
+ [S3 버킷에 대한 수명 주기 정책을 생성하려면 어떻게 해야 하나요?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch Logs Insights 샘플 쿼리](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [CloudWatch Logs Insights를 사용한 로그 데이터 분석](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [S3 버킷에 대한 수명 주기 정책을 생성하려면 어떻게 해야 하나요?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [Athena를 사용하여 Amazon S3 서버 액세스 로그를 분석하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 정기적인 검토 시행
워크로드 모니터링이 구현되는 방식을 자주 검토하고 중요한 이벤트 및 변경 사항에 따라 업데이트합니다.
효과적인 모니터링의 기반은 주요 비즈니스 지표입니다. 비즈니스 우선 순위가 변경됨에 따라 이러한 지표가 워크로드에 반영되는지 확인하십시오.
모니터링을 감사하면 애플리케이션이 가용성 목표를 달성하는 시기를 확인하는 데 도움이 됩니다. 근본 원인 분석을 수행하려면 장애 발생 시에 수행된 작업을 검색하는 기능이 필요합니다. AWS는 인시던트 중에 서비스의 상태를 추적할 수 있는 서비스를 제공합니다.
+ **Amazon CloudWatch Logs:** 로그를 저장하고 해당 내용을 검사할 수 있는 서비스입니다.
+ **Amazon CloudWatch Logs Insights**: 대량 로그를 몇 초 만에 분석할 수 있는 완전관리형 서비스입니다. 이 서비스는 빠른 대화형 쿼리 및 시각화를 제공합니다.
+ **AWS Config:** 다양한 시점에서 사용된 AWS 인프라를 확인할 수 있습니다.
+ **AWS CloudTrail:** 특정 시간에 호출된 AWS API 및 기준으로 사용된 원칙을 확인할 수 있는 서비스입니다.
AWS에서는 주간 회의를 개최하여 [운영 성과를 검토하고](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 알게 된 내용을 팀 간에 공유합니다. AWS에는 많은 팀이 있기 때문에 검토할 워크로드를 무작위로 선택하는 [The Wheel](https://aws.amazon.com/blogs/opensource/the-wheel/) 을 만들었습니다. 운영 성능 검토 및 지식 공유를 위한 정기 케이던스를 설정하면 운영 팀의 성과를 개선하는 역량을 발전시킬 수 있습니다.
**일반적인 안티 패턴:**
+ 기본 지표만 수집
+ 모니터링 전략을 설정한 후 다시 검토하지 않음
+ 주요 변경 사항이 배포될 때 모니터링에 대해 논의하지 않음
**이 모범 사례 수립의 이점:** 모니터링을 정기적으로 검토하면 예상된 문제가 실제로 발생할 때 알림에 대응하는 것이 아니라 잠재적인 문제를 미리 예측할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 워크로드에 대해 여러 대시보드를 생성합니다. 주요 비즈니스 지표는 물론, 다양한 사용량에서 예상되는 워크로드의 상태와 가장 관련성이 높은 것으로 확인된 기술 지표도 포함된 최상위 대시보드가 있어야 합니다. 또한 검사할 수 있는 다양한 애플리케이션 티어와 종속성에 대한 대시보드도 필요합니다.
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ 워크로드 대시보드에 대한 정기적인 검토 일정을 예약하고 검토를 수행합니다. 대시보드를 정기적으로 검사합니다. 검사하는 세부 수준을 나타내는 다양한 케이던스를 구성할 수 있습니다.
+ 지표에서 추세를 검사합니다. 지표 값을 과거 값과 비교하여 조사해야 할 문제가 있음을 시사하는 추세가 나타나는지 확인합니다. 이러한 예로는 지연 시간 증가, 주요 비즈니스 기능 감소, 장애 응답 증가 등이 있습니다.
+ 지표에서 특이값/이상 항목을 검사합니다. 평균 또는 중간값은 특이값 및 이상 항목을 감출 수 있습니다. 해당 기간 동안의 가장 높은 값과 가장 낮은 값을 살펴보고 극단적인 값의 원인을 조사합니다. 이러한 원인을 계속 제거하면서 극단성을 낮추면 워크로드 성능의 일관성을 지속적으로 개선할 수 있습니다.
+ 동작의 급격한 변화를 찾습니다. 지표의 수량 또는 방향이 갑자기 바뀔 경우, 애플리케이션이 변경되었거나 외부 요인이 발생한 것일 수 있습니다. 이 같은 외부 요인으로 인해 추적할 지표를 추가해야 할 수 있습니다.
## 리소스
**관련 문서:**
+ [Amazon CloudWatch Logs Insights 샘플 쿼리](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
# REL06-BP07 시스템을 통한 요청의 종단 간 추적 모니터링
개발자는 AWS X-Ray 또는 서드파티 도구를 사용하여 분산 시스템을 보다 쉽게 분석하고 디버깅하여 애플리케이션과 기반 서비스의 성능을 파악할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 시스템을 통한 요청의 엔드 투 엔드 추적을 모니터링합니다. AWS X-Ray는 애플리케이션이 처리하는 요청에 대한 데이터를 수집하고, 최적화 문제와 기회를 식별하기 위해 데이터를 보고, 필터링하고, 인사이트를 얻는 데 사용할 수 있는 도구를 제공하는 웹 서비스입니다. 애플리케이션에 대한 요청이 추적되면, 해당 요청 및 응답뿐 아니라 애플리케이션이 다운스트림 AWS 리소스, 마이크로서비스, 데이터베이스 및 웹 API에 대해 수행한 호출과 관련하여 자세한 정보를 확인할 수 있습니다.
+ [AWS X-Ray란 무엇입니까?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [AWS X-Ray란 무엇입니까?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# REL 7 수요 변경에 따라 조정되도록 워크로드를 설계하려면 어떻게 해야 합니까?
확장 가능한 워크로드는 리소스를 자동으로 추가하거나 제거하여 특정 시기의 수요에 리소스 공급을 맞출 수 있는 탄력성을 제공합니다.
**Topics**
+ [REL07-BP01 리소스를 확보하거나 조정할 때 자동화 사용](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 워크로드 장애 감지 시 리소스 확보](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스 확보](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 워크로드 로드 테스트](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 리소스를 확보하거나 조정할 때 자동화 사용
손상된 리소스를 교체하거나 워크로드 크기를 조정할 때 Amazon S3 및 AWS Auto Scaling과 같은 관리형 AWS 서비스를 사용하여 프로세스를 자동화합니다. 서드 파티 도구 및 AWS SDK를 사용하여 크기를 자동 조정할 수도 있습니다.
관리형 AWS 서비스에는 Amazon S3, Amazon CloudFront, AWS Auto Scaling, AWS Lambda, Amazon DynamoDB, AWS Fargate, Amazon Route 53가 있습니다.
AWS Auto Scaling을 사용하면 손상된 인스턴스를 감지하고 교체할 수 있습니다. 또한 [Amazon EC2](https://aws.amazon.com/ec2/) 인스턴스 및 스팟 플릿, [Amazon ECS](https://aws.amazon.com/ecs/) 태스크, [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 테이블 및 인덱스와 [Amazon Aurora](https://aws.amazon.com/aurora/) 복제본에 대한 조정 계획을 수립할 수도 있습니다.
EC2 인스턴스의 크기를 조정할 때는 여러 가용 영역(3개 이상 권장)을 사용하고 용량을 추가하거나 제거하여 이러한 가용 영역 간의 균형을 유지해야 합니다. ECS 태스크 또는 Kubernetes 포드(Amazon Elastic Kubernetes Service를 사용하는 경우) 역시 여러 개의 가용 영역에 분산되어야 합니다.
AWS Lambda를 사용하는 경우에는 인스턴스가 자동으로 조정됩니다. 함수에 대한 이벤트 알림이 수신될 때마다 AWS Lambda가 컴퓨팅 플릿 내에서 여유 용량을 신속하게 찾고 할당된 동시성까지 코드를 실행합니다. 사용자는 필요한 동시성이 특정 Lambda와 Service Quotas에 구성되어 있는지 확인해야 합니다.
Amazon S3는 높은 요청 속도를 처리하도록 자동으로 확장됩니다. 예를 들어 애플리케이션은 버킷에서 접두사마다 초당 3,500개 이상의 PUT/COPY/POST/DELETE 및 5,500개의 GET/HEAD 요청을 전송할 수 있습니다. 버킷의 접두사 수에는 제한이 없습니다. 읽기를 병렬화하여 읽기 또는 쓰기 성능을 높일 수 있습니다. 예를 들어 Amazon S3 버킷에서 10개의 접두사를 생성하여 읽기를 병렬화하는 경우 읽기 성능을 초당 55,000개의 읽기 요청으로 확장할 수 있습니다.
Amazon CloudFront 또는 신뢰할 수 있는 콘텐츠 전송 네트워크(CDN)를 구성하고 사용합니다. CDN은 더 빠른 최종 사용자 응답 시간을 제공할 수 있으며 콘텐츠 요청을 캐시에서 처리하므로 워크로드의 크기를 확대할 필요가 줄어듭니다.
**일반적인 안티 패턴:**
+ 자동 복구를 위해 Auto Scaling 그룹을 구현하지만 탄력성은 구현하지 않음
+ Auto Scaling을 사용하여 트래픽의 대규모 증가에 대응
+ 고도의 상태 저장 애플리케이션을 배포하여 탄력성 옵션을 없앰
**이 모범 사례 수립의 이점:** 자동화는 리소스를 배포하고 폐기할 때 수작업으로 인한 오류가 발생할 가능성을 없앱니다. 자동화는 배포 또는 폐기 요구 사항에 대한 느린 대응으로 인해 비용이 초과하거나 서비스가 거부될 위험성을 없앱니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ AWS Auto Scaling을 구성하고 사용합니다. 애플리케이션을 모니터링하고 용량을 자동으로 조정하여 최저 비용으로 안정적이고 예측 가능한 성능을 유지할 수 있습니다. AWS Auto Scaling을 사용하면 여러 서비스에 걸쳐 여러 리소스에 대한 애플리케이션 크기 조정을 설정할 수 있습니다.
+ [AWS Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ Amazon EC2 인스턴스, 스팟 플릿, Amazon ECS 태스크, Amazon DynamoDB 테이블 및 인덱스, Amazon Aurora 복제본, AWS Marketplace 어플라이언스에 적절하게 Auto Scaling을 구성합니다.
+ [DynamoDB Auto Scaling을 통한 처리량 용량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ 서비스 API 작업을 사용하여 경보, 확장 정책, 가동 준비 시간 및 중단 시간을 지정합니다.
+ Elastic Load Balancing을 사용합니다. 로드 밸런서는 경로별 또는 네트워크 연결별로 로드를 분산할 수 있습니다.
+ [Elastic Load Balancing이란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Application Load Balancers는 경로별로 로드를 배포할 수 있습니다.
+ [Application Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ 도메인 이름의 하위 경로를 기준으로 다른 워크로드에 트래픽을 분산하도록 Application Load Balancer를 구성합니다.
+ Application Load Balancers를 사용해 AWS Auto Scaling과 통합하는 방식으로 수요를 관리해 로드를 분산할 수 있습니다.
+ [오토 스케일링 그룹과 함께 로드 밸런서 사용](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ Network Load Balancer는 연결별로 로드를 분산합니다.
+ [Network Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ TCP를 사용하여 다른 워크로드로 트래픽을 분산하도록 Network Load Balancer를 구성하거나 워크로드가 일정한 IP 주소 집합을 갖도록 합니다.
+ Network Load Balancer를 사용해 AWS Auto Scaling과 통합하는 방식으로 수요를 관리해 로드를 분산할 수 있습니다.
+ 가용성 높은 DNS 공급자를 사용합니다. DNS 이름을 사용하면 사용자가 IP 주소 대신 이름을 입력하여 워크로드에 액세스하고 이 정보를 정의된 범위, 즉 일반적으로 워크로드 사용자의 경우 전역적으로 배포할 수 있습니다.
+ Amazon Route 53 또는 신뢰할 수 있는 DNS 제공업체를 사용합니다.
+ [Amazon Route 53란 무엇입니까?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Route 53를 사용하여 CloudFront 배포 및 로드 밸런서를 관리합니다.
+ 관리할 도메인 및 하위 도메인을 결정하십시오.
+ ALIAS 또는 CNAME 레코드를 사용하여 적절한 레코드 세트를 생성합니다.
+ [레코드 작업](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
+ AWS 글로벌 네트워크를 사용하여 사용자로부터 애플리케이션으로의 경로를 최적화합니다. AWS Global Accelerator는 30초 이내에 애플리케이션 엔드포인트의 상태를 지속적으로 모니터링하고 트래픽을 정상 엔드포인트로 리디렉션합니다.
+ AWSGlobal Accelerator는 로컬 또는 글로벌 사용자에 대해 애플리케이션의 가용성과 성능을 개선하는 서비스입니다. Application Load Balancers, Network Load Balancer 또는 Amazon EC2 인스턴스 등, 하나 또는 여러 AWS 리전에서 애플리케이션 엔드포인트에 고정된 진입점 역할을 하는 고정 IP 주소를 제공합니다.
+ [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ Amazon CloudFront 또는 신뢰할 수 있는 콘텐츠 전송 네트워크(CDN)를 구성하고 사용합니다. 콘텐츠 전송 네트워크를 사용하면 최종 사용자 입장에서는 응답 시간을 단축할 수 있으며 워크로드를 불필요하게 확장할 수 있는 콘텐츠 요청을 처리할 수 있습니다.
+ [Amazon CloudFront란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ 워크로드에 Amazon CloudFront 배포를 구성하거나 서드 파티 CDN을 사용합니다.
+ CloudFront의 IP 범위를 엔드포인트 보안 그룹 또는 액세스 정책에 사용함으로써 워크로드에 대한 액세스를 제한하여 CloudFront에서만 액세스할 수 있도록 할 수 있습니다.
## 리소스
**관련 문서:**
+ [APN 파트너: 자동화된 컴퓨팅 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: 오토 스케일링과 함께 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [오토 스케일링 그룹과 함께 로드 밸런서 사용](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Amazon EC2 Auto Scaling란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [Amazon CloudFront란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [Amazon Route 53란 무엇입니까?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Elastic Load Balancing이란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Network Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [Application Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [레코드 작업](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
# REL07-BP02 워크로드 장애 감지 시 리소스 확보
가용성이 영향을 받는 경우 필요에 따라 리소스를 사후에 확장하여 워크로드 가용성을 복원합니다.
먼저 상태 확인과 이러한 확인에 대한 기준을 구성하여 리소스 부족으로 인해 가용성이 영향을 받는 시기를 나타내야 합니다. 그런 다음 적절한 담당자에게 수동으로 리소스를 조정하도록 알리거나 자동화를 트리거하여 자동으로 리소스를 조정합니다.
워크로드에 맞게 적절하게 수동으로 규모를 조정할 수 있습니다. 예를 들어 AWS Management Console 또는 AWS CLI를 통해 Auto Scaling 그룹의 EC2 인스턴스 수를 변경하거나 DynamoDB 테이블의 처리량을 수정할 수 있습니다. 하지만 가능한 경우에는 항상 자동화를 사용해야 합니다( **리소스를 확보하거나 조정할 때 자동화 사용**)는 SAP NetWeaver Guide Finder 및 SAP NetWeaver Security Guide를 참조하세요.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 워크로드 장애 감지 시 리소스를 확보합니다. 가용성이 영향을 받는 경우 필요에 따라 리소스를 사후에 확장하여 워크로드 가용성을 복원합니다.
+ AWS Auto Scaling의 핵심 구성 요소인 크기 조정 계획을 사용하여 리소스 크기 조정을 위한 지침 집합을 구성합니다. AWS CloudFormation을 사용하거나 AWS 리소스에 태그를 추가하는 경우 애플리케이션마다 서로 다른 리소스 집합에 대해 크기 조정 계획을 설정할 수 있습니다. AWS Auto Scaling은 각 리소스에 맞춤화된 크기 조정 전략에 대한 권장 사항을 제공합니다. 크기 조정 계획을 생성하면 AWS Auto Scaling이 동적 조정과 예측 조정 방식을 결합하여 조정 전략을 지원합니다.
+ [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Amazon EC2 Auto Scaling을 사용하면 애플리케이션의 로드를 처리하는 데 사용할 수 있는 적절한 수의 Amazon EC2 인스턴스를 확보할 수 있습니다. Auto Scaling 그룹이라는 EC2 인스턴스 모음을 생성합니다. 각 Auto Scaling 그룹의 최소 인스턴스 수를 지정할 수 있으며, Amazon EC2 Auto Scaling은 사용하면 그룹의 크기가 이 값 아래로 내려가지 않게 합니다. 각 오토 스케일링 그룹의 최대 인스턴스 수를 지정할 수 있으며, Amazon EC2 Auto Scaling은 그룹의 크기가 이 값을 초과하지 않게 합니다.
+ [Amazon EC2 Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ Amazon DynamoDB Auto Scaling은 AWS Application Auto Scaling 서비스를 사용하여 사용자를 대신해 실제 트래픽 패턴에 따라 프로비저닝된 처리량 용량을 동적으로 조정합니다. 따라서 테이블 또는 글로벌 보조 인덱스를 통해 프로비저닝된 읽기 및 쓰기 용량을 늘려 조절 없이 급증하는 트래픽을 처리할 수 있습니다.
+ [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 자동화된 컴퓨팅 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: 오토 스케일링과 함께 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Amazon EC2 Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스 확보
수요를 충족하고 가용성에 영향을 미치지 않도록 리소스를 사전에 확장합니다.
많은 AWS 서비스가 수요에 맞춰 자동으로 확장됩니다. Amazon EC2 인스턴스 또는 Amazon ECS 클러스터를 사용하는 경우 워크로드 수요에 해당하는 사용량 지표에 따라 이러한 자동 조정이 수행되도록 구성할 수 있습니다. Amazon EC2의 경우 평균 CPU 사용률, 로드 밸런서 요청 수 또는 네트워크 대역폭을 사용하여 EC2 인스턴스를 스케일아웃(또는 스케일인)할 수 있습니다. Amazon ECS의 경우 평균 CPU 사용률, 로드 밸런서 요청 수 및 메모리 사용률을 사용하여 ECS 작업을 스케일 아웃(또는 스케일 인)할 수 있습니다. AWS에서 Target Auto Scaling을 사용하면 Autoscaler가 가정용 온도 조절기처럼 작동하여 리소스를 추가하거나 제거함으로써 지정한 목표 값(예: 70%의 CPU 사용률)을 유지합니다.
또한 AWS Auto Scaling은 기계 학습을 사용하여 각 리소스의 기간별 워크로드를 분석하고 향후 2일간의 로드를 주기적으로 예측하는 [Predictive Auto Scaling](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)을 수행할 수도 있습니다.
리틀의 법칙은 필요한 컴퓨팅 인스턴스(EC2 인스턴스, 동시 Lambda 함수 등) 수를 계산하는 데 도움이 됩니다.
*L* = *λW*
L = 인스턴스 수(또는 시스템의 평균 동시성)
λ = 요청이 도착하는 평균 속도(요청/초)
W = 시스템이 각 요청에 소비하는 평균 시간(초)
예를 들어 100rps에서 각 요청을 처리하는 데 0.5초가 걸리는 경우 수요를 따라가려면 50개의 인스턴스가 필요합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스를 확보합니다. 수요를 충족하고 가용성에 영향을 미치지 않도록 리소스를 사전에 확장합니다.
+ 지정된 요청 속도를 처리하는 데 필요한 컴퓨팅 리소스(컴퓨팅 동시성)를 계산합니다.
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ 사용량에 대한 과거 패턴이 있는 경우 Amazon EC2 Auto Scaling에 대한 예약된 조정을 설정합니다.
+ [Amazon EC2 Auto Scaling의 예약된 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ AWS 예측 크기 조정을 사용합니다.
+ [Predictive Scaling for EC2, Powered by Machine Learning(기계 학습 기반 EC2용 예측 확장)](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
## 리소스
**관련 문서:**
+ [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: 오토 스케일링과 함께 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Predictive Scaling for EC2, Powered by Machine Learning(기계 학습 기반 EC2용 예측 확장)](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Amazon EC2 Auto Scaling의 예약된 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ [Amazon EC2 Auto Scaling란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP04 워크로드 로드 테스트
확장 작업이 워크로드의 필요 사항을 충족하는지 측정하기 위한 로드 테스트 방식을 채택하십시오.
지속적인 로드 테스트를 수행하는 것이 중요합니다. 로드 테스트를 통해 한계점을 찾고 워크로드의 성능을 테스트할 수 있습니다. AWS를 사용하면 프로덕션 워크로드의 규모를 모델링하는 임시 테스트 환경을 쉽게 설정할 수 있습니다. 클라우드에서는 온디맨드 방식으로 프로덕션 규모의 테스트 환경을 만들고, 테스트를 완료한 다음 해당 리소스를 폐기할 수 있습니다. 테스트 환경을 실행하는 동안에만 비용을 지불하면 되기 때문에 온프레미스 테스트 비용의 몇 분의 일에 불과한 가격으로 실제 환경을 시뮬레이션할 수 있습니다.
또한 프로덕션에서의 로드 테스트는 프로덕션 시스템에 스트레스가 가해지는 실전 연습의 일부로 간주되어야 하며 고객 사용량이 적은 시간에는 모든 직원이 결과를 해석하고 발생하는 문제를 해결해야 합니다.
**일반적인 안티 패턴:**
+ 구성이 프로덕션 환경과 동일하지 않은 배포에 대해 로드 테스트 수행
+ 전체 워크로드가 아니라 워크로드의 개별 부분에 대해서만 로드 테스트 수행
+ 대표적인 실제 요청 세트가 아니라 요청의 하위 집합을 사용하여 로드 테스트 수행
+ 예상 부하보다 작은 안전 계수로 부하 테스트 수행
**이 모범 사례 수립의 이점:** 로드 시 장애가 발생하는 아키텍처의 구성 요소를 알고 있으며, 해당 로드에 곧 도달할 것임을 나타내는 지표를 식별하고 조사하여 문제를 해결할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 로드 테스트를 수행하여 워크로드의 어느 측면에 용량을 추가 또는 제거해야 하는지 파악합니다. 로드 테스트에는 프로덕션 환경에서 수신하는 것과 유사한 대표 트래픽이 있어야 합니다. 계측한 지표를 모니터링하면서 로드를 늘려 리소스를 추가 또는 제거해야 하는 시점을 나타내는 지표를 결정합니다.
+ [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ 요청의 조합을 식별합니다. 다양한 요청 조합이 있을 수 있으므로 트래픽 조합을 식별할 때 다양한 시간 프레임을 살펴봐야 합니다.
+ 로드 드라이버를 구현합니다. 사용자 지정 코드, 오픈 소스 또는 상용 소프트웨어를 사용하여 로드 드라이버를 구현할 수 있습니다.
+ 처음에는 작은 용량을 사용하여 로드 테스트를 수행합니다. 인스턴스 또는 컨테이너 하나 정도의 작은 용량으로 로드를 유도하면 즉각적인 효과가 나타납니다.
+ 더 큰 용량에 대해 로드 테스트를 수행합니다. 분산된 부하에서는 효과가 다르게 나타나므로 가능한 한 제품 환경에 가깝게 테스트해야 합니다.
## 리소스
**관련 문서:**
+ [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
# REL 8 변경 사항은 어떻게 적용합니까?
새로운 기능을 배포하고 워크로드와 운영 환경에서 알려진 소프트웨어를 실행하고 예측 가능한 방식으로 패치 또는 교체할 수 있도록 하려면 변경 사항을 제어해야 합니다. 이러한 변경이 제어되지 않으면 변경의 영향을 예측하거나 변경으로 인해 발생하는 문제를 해결하기가 어려워집니다.
**Topics**
+ [REL08-BP01 배포와 같은 표준 활동에 런북 사용](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 배포의 일부로 기능 테스트 통합](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 배포의 일부로 복원력 테스트 통합](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 변경 불가능한 인프라를 사용하여 배포](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 자동화를 통한 변경 사항 배포](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 배포와 같은 표준 활동에 런북 사용
런북은 특정 결과를 달성하기 위한 미리 정의된 절차입니다. 수동 또는 자동으로 표준 활동을 수행할 때 런북을 사용합니다. 워크로드 배포, 워크로드 패치 적용 또는 DNS 수정과 같은 활동이 여기에 포함됩니다.
예를 들어 [배포 중에 롤백이 안전한지 확인하는 프로세스를 준비합니다.](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). 서비스를 안정적으로 유지하려면 고객 중단 없이 배포를 롤백할 수 있는지 확인하는 것이 중요합니다.
런북 절차를 수행할 때는 유효하고 효과적인 수동 프로세스에서 시작하고, 이를 코드에 구현한 다음, 필요한 경우 자동으로 실행되도록 트리거합니다.
고도로 자동화된 정교한 워크로드의 경우에도 [게임 데이를 실행하거나](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) 엄격한 보고 및 감사 요구 사항을 충족할 때 런북을 유용하게 사용할 수 있습니다.
플레이북은 특정 인시던트에 대응하여 사용되며 런북은 특정 결과를 달성하기 위해 사용됩니다. 런북은 일상적인 활동에 대한 것이고, 플레이북은 일상적이지 않은 이벤트에 대응하는 데 사용되는 경우가 많습니다.
**일반적인 안티 패턴:**
+ 프로덕션 환경에서 계획되지 않은 구성 변경 수행
+ 더 빠르게 배포하기 위해 계획의 단계를 건너뛰고, 그 결과 배포에 실패
+ 변경 사항 되돌리기를 테스트하지 않고 변경 수행
**이 모범 사례 수립의 이점:** 변경 계획을 효과적으로 수립하면 영향을 받는 모든 시스템을 파악할 수 있으므로 변경 사항을 성공적으로 실행할 수 있습니다. 테스트 환경에서 변경 사항을 검증하면 신뢰성을 높일 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 런북에 절차를 문서화하면 잘 알려진 이벤트에 일관된 방식으로 신속하게 대응할 수 있습니다.
+ [AWS Well-Architected Framework: 개념: 런북](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ 코드형 인프라의 원칙을 사용해 인프라를 정의합니다. AWS CloudFormation 또는 신뢰할 수 있는 서드 파티 제품을 사용하여 인프라를 정의하면 버전 제어 소프트웨어를 통한 변경 사항의 각 버전을 차례대로 확인할 수 있습니다.
+ AWS CloudFormation 또는 신뢰할 수 있는 서드 파티 제품을 사용하여 인프라를 정의합니다.
+ [AWS CloudFormation이란 무엇인가요?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ 우수한 소프트웨어 설계 원칙으로 분리된 단일 템플릿을 생성합니다.
+ 구현 권한, 템플릿 및 책임자를 결정합니다.
+ [AWS Identity and Access Management로 액세스 제어 ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ 버전을 제어하려면 AWS CodeCommit 또는 신뢰할 수 있는 서드 파티 도구와 같은 소스 제어를 사용합니다.
+ [AWS CodeCommit이란 무엇입니까?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 자동화된 배포 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: 배포 자동화에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [AWS Well-Architected Framework: 개념: 런북](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [AWS CloudFormation이란 무엇인가요?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS CodeCommit이란 무엇입니까?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**관련 예시:**
+ [플레이북 및 런북으로 운영 자동화](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 배포의 일부로 기능 테스트 통합
기능 테스트는 자동화된 배포의 일부로 실행됩니다. 성공 기준이 충족되지 않으면 파이프라인이 중지되거나 롤백됩니다.
이러한 테스트는 파이프라인에서 프로덕션 전에 준비되는 사전 프로덕션 환경에서 실행됩니다. 이 작업을 배포 파이프라인의 일부로 수행하는 것이 가장 좋습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 배포의 일부로 기능 테스트를 통합합니다. 기능 테스트는 자동화된 배포의 일부로 실행됩니다. 성공 기준이 충족되지 않으면 파이프라인이 중지되거나 롤백됩니다.
+ AWS CodePipeline에 모델링된 소프트웨어 릴리스 파이프라인의 '테스트 작업'을 실행하는 중에 AWS CodeBuild를 호출합니다. 이 기능을 사용하면 단위 테스트, 정적 코드 분석, 통합 테스트 등 코드에 대해 다양한 테스트를 손쉽게 실행할 수 있습니다.
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ AWS Marketplace 솔루션을 사용하여 소프트웨어 제공 파이프라인의 일부로 자동화된 테스트를 실행합니다.
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## 리소스
**관련 문서:**
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [AWS CodePipeline란 무엇입니까?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 배포의 일부로 복원력 테스트 통합
복원력 테스트( [카오스 엔지니어링의 원칙 사용)](https://principlesofchaos.org/)는 사전 프로덕션 환경에서 자동화된 배포 파이프라인에 포함되어 실행됩니다.
이러한 테스트는 프로덕션 전 환경에서 파이프라인에서 준비되고 실행됩니다. 또한 프로덕션 환경에서도 다음의 일부로 실행되어야 합니다. [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays).
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 배포의 일부로 복원력 테스트를 통합합니다. 프로덕션 환경에서 격변의 조건을 견딜 수 있는 워크로드의 기능에 대한 신뢰성을 확보하기 위해 시스템을 실험하는 분야인 카오스 엔지니어링을 사용합니다.
+ 복원력 테스트는 결함 또는 리소스 저하를 발생시켜 워크로드가 설계된 복원력으로 대응하는지 평가합니다.
+ [Well-Architected lab: Level 300: Testing for Resiliency of EC2 RDS and S3(Well-Architected 실습: 레벨 300: EC2 RDS 및 S3의 복원력 테스트)](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ 이러한 테스트는 자동화된 배포 파이프라인의 사전 프로덕션 환경에서 정기적으로 실행할 수 있습니다.
+ 또한 예약된 게임 데이의 일부로 프로덕션에서 실행해야 합니다.
+ 카오스 엔지니어링 원칙을 사용하여 다양한 장애 하에서 워크로드의 성능이 어떻게 나타날지에 대한 가설을 제안한 다음 복원력 테스트를 사용하여 가설을 테스트합니다.
+ [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
## 리소스
**관련 문서:**
+ [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
+ [AWS Fault Injection Simulator란 무엇입니까?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**관련 예시:**
+ [Well-Architected lab: Level 300: Testing for Resiliency of EC2 RDS and S3(Well-Architected 실습: 레벨 300: EC2 RDS 및 S3의 복원력 테스트)](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 변경 불가능한 인프라를 사용하여 배포
변경 불가능한 인프라는 프로덕션 워크로드의 현재 위치에서 업데이트, 보안 패치 또는 구성 변경이 발생하지 않도록 규정하는 모델입니다. 변경이 필요한 경우 아키텍처가 새 인프라에 구축되고 프로덕션 환경에 배포됩니다.
변경 불가능한 인프라 패러다임의 가장 일반적인 구현 형태는 ***변경 불가능한 서버입니다.***. 즉, 서버에 업데이트 또는 수정이 필요한 경우 이미 사용 중인 서버를 업데이트하는 대신 새 서버가 배포됩니다. 따라서 SSH를 통해 서버에 로그인하고 소프트웨어 버전을 업데이트하는 대신 애플리케이션의 모든 변경은 코드 리포지토리에 소프트웨어를 푸시(예: git push)하는 것으로 시작됩니다. 변경이 불가능한 인프라에서는 변경이 허용되지 않으므로 배포된 시스템의 상태를 확신할 수 있습니다. 변경이 불가능한 인프라는 본질적으로 더 일관되고 안정적이며 예측 가능하며 소프트웨어 개발 및 운영의 여러 측면을 간소화합니다.
변경이 불가능한 인프라에서 애플리케이션을 배포할 때는 Canary 또는 블루/그린 배포를 사용합니다.
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) 는 일반적으로 단일 서비스 인스턴스에서 실행되는 새 버전(Canary)으로 소수의 사용자를 연결하는 방식입니다. 그런 다음 생성되는 동작 변경 또는 오류를 면밀히 조사합니다. 중대한 문제가 발생하여 사용자에게 이전 버전을 다시 제공해야 하는 경우에는 Canary에서 트래픽을 제거할 수 있습니다. 배포가 정상적으로 진행되면 배포가 완료될 때까지 변경 사항에서 오류를 모니터링하면서 원하는 속도로 배포를 계속 진행할 수 있습니다. Canary 배포를 지원하는 배포 구성을 사용하여 AWS CodeDeploy를 구성할 수 있습니다.
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) 는 Canary 배포와 비슷합니다. 단, 전체 애플리케이션 플릿이 병렬로 배포됩니다. 이 패턴에서는 블루와 그린의 두 스택에서 번갈아 가며 배포를 수행합니다. 이 패턴에서도 새 버전으로 트래픽을 전송한 다음 배포에 문제가 발생하면 이전 버전으로 장애 복구할 수 있습니다. 일반적으로 모든 트래픽은 한 번에 전환되지만, Amazon Route 53의 가중치 기반 DNS 라우팅 기능을 사용하면 각 버전에 대한 트래픽의 일부를 사용하여 새 버전의 채택을 유도할 수도 있습니다. 블루/그린 배포를 지원하는 배포 구성을 사용하여 AWS CodeDeploy와 AWS Elastic Beanstalk를 구성할 수 있습니다.
![\[AWS Elastic Beanstalk 및 Amazon Route 53를 사용한 블루/그린 배포를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
변경 불가능한 인프라의 이점:
+ **구성 드리프트 감소:** 알려진 기본 버전 제어 구성에서 서버를 자주 교체하면 인프라가 알려진 상태로 **재설정되므로** 구성 드리프트가 방지됩니다.
+ **간소화된 배포**: 업그레이드를 지원할 필요가 없으므로 배포가 간소화됩니다. 업그레이드는 단지 새로운 배포일 뿐입니다.
+ **안정성 있는 원자 단위 배포:** 배포가 성공적으로 완료되거나 아무 것도 변경되지 않습니다. 따라서 배포 프로세스의 신뢰도가 개선됩니다.
+ **빠른 롤백 및 복구 프로세스를 통해 배포 안전성 개선:** 이전 작업 버전이 변경되지 않으므로 배포가 더 안전합니다. 오류가 감지되면 롤백할 수 있습니다.
+ **일관된 테스트 및 디버깅 환경:** 모든 서버에 동일한 이미지가 사용되므로 환경 간에 차이가 없습니다. 하나의 빌드가 여러 환경에 배포됩니다. 또한 일관되지 않은 환경이 방지되고 테스트 및 디버깅이 간소화됩니다.
+ **확장성 개선:** 서버가 기본 이미지를 사용하고 일관적이며 반복 가능하므로 자동 조정이 간단합니다.
+ **간소화된 도구 체인**: 프로덕션 소프트웨어 업그레이드를 관리하는 구성 관리 도구를 제거할 수 있으므로 도구 체인이 간소화됩니다. 서버에 추가 도구 또는 에이전트가 설치되지 않습니다. 변경은 기본 이미지에 수행되고 테스트된 후 롤아웃됩니다.
+ **보안 강화:** 서버에 대한 모든 변경을 거부하면 인스턴스에서 SSH를 비활성화하고 키를 제거할 수 있습니다. 이렇게 하면 공격 벡터가 줄어들어 조직의 보안 태세를 개선할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 변경 불가능한 인프라를 사용하여 배포합니다. 변경 불가능한 인프라는 프로덕션 시스템의 *현재 위치에서* 업데이트, 보안 패치 또는 구성 변경이 발생하지 않도록 규정하는 모델입니다. 변경이 필요한 경우 새 버전의 아키텍처가 구축되고 프로덕션 환경에 배포됩니다.
+ [블루/그린 배포 개요](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Deploying Serverless Applications Gradually(점진적으로 서버리스 애플리케이션 배포)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [변경 불가능한 인프라: 불변성을 통한 안정성, 일관성 및 신뢰성](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
## 리소스
**관련 문서:**
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
+ [Deploying Serverless Applications Gradually(점진적으로 서버리스 애플리케이션 배포)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [변경 불가능한 인프라: 불변성을 통한 안정성, 일관성 및 신뢰성](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [블루/그린 배포 개요](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Amazon Builders' Library: 배포 중 롤백 안전 보장](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# REL08-BP05 자동화를 통한 변경 사항 배포
배포 및 패치 적용이 자동화되므로 부정적인 영향이 제거됩니다.
프로덕션 시스템을 변경하는 것은 조직에서 가장 위험 부담이 큰 영역에 속합니다. 배포는 소프트웨어를 통해 해결할 수 있는 업무상의 문제와 더불어 해결해야 하는 가장 중요한 문제로 간주됩니다. 오늘날에는 배포 관련 문제를 해결하려면 운영 과정에서 해당하는 모든 영역(변경 사항 테스트/배포, 용량 추가/제거, 데이터 마이그레이션 포함)에 자동화를 사용해야 합니다. AWS CodePipeline을 사용하면 워크로드를 해제하는 데 필요한 단계를 관리할 수 있습니다. 여기에는 AWS CodeDeploy를 사용하여 Amazon EC2 인스턴스, 온프레미스 인스턴스, 서버리스 Lambda 함수 또는 Amazon ECS 서비스에 대한 애플리케이션 코드 배포를 자동화하는 배포 상태가 포함됩니다.
**권장 사항**
일반적인 통념으로는 가장 어려운 작업 절차에 사람을 투입하는 것이 좋다고 하지만 AWS에서는 바로 그런 이유로 가장 어려운 절차를 자동화할 것을 권장합니다.
**일반적인 안티 패턴:**
+ 수동으로 변경 수행
+ 비상 워크플로를 통해 자동화 단계를 건너뜀
+ 계획을 따르지 않음
**이 모범 사례 수립의 이점:** 자동화를 사용하여 모든 변경 사항을 배포하면 인적 오류가 발생할 가능성이 사라지고 프로덕션을 변경하기 전에 테스트하여 계획이 완료되었는지 확인할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 배포 파이프라인을 자동화합니다. 배포 파이프라인을 사용하면 이상 징후의 자동 테스트 및 탐지를 실행하여 프로덕션 배포 전 특정 단계에서 파이프라인을 중지하거나 변경 사항을 자동으로 롤백할 수 있습니다.
+ [Amazon Builders' Library: 배포 중 롤백 안전 보장](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library: 지속적 전달을 통한 신속한 배포](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ AWS CodePipeline 또는 신뢰할 수 있는 서드 파티 제품을 사용하여 파이프라인을 정의하고 실행합니다.
+ 코드 저장소에 변경 사항이 전달되고 나서 실행되도록 파이프라인을 구성합니다.
+ [AWS CodePipeline이란 무엇입니까?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ Amazon Simple Notification Service(Amazon SNS) 및 Amazon Simple Email Service(Amazon SES)를 사용하여 파이프라인의 문제에 대한 알림을 전송하거나 Amazon Chime과 같은 팀 채팅 도구에 통합합니다.
+ [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Amazon SES란 무엇입니까?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Amazon Chime이란 무엇일까요?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [Automate chat messages with webhooks(Webhook으로 채팅 메시지 기능 자동화)](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 자동화된 배포 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: 배포 자동화에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Automate chat messages with webhooks(Webhook으로 채팅 메시지 기능 자동화)](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [Amazon Builders' Library: 배포 중 롤백 안전 보장](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library: 지속적 전달을 통한 신속한 배포](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [AWS CodePipeline란 무엇입니까?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [CodeDeploy란 무엇입니까?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [Amazon SES란 무엇입니까?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**관련 동영상:**
+ [AWS Summit 2019: CI/CD on AWS(AWS 기반 CI/CD)](https://youtu.be/tQcF6SqWCoY)