# 프레임워크의 원칙
소프트웨어 시스템을 제작하는 것은 건물을 짓는 것과 매우 비슷합니다. 토대가 단단하지 않으면 구조적 문제가 발생하여 건물의 기능이 약해지는 것은 물론 건물 자체가 무너질 수 있습니다. 기술 솔루션을 설계할 때 운영 우수성, 보안, 신뢰성, 성능 효율성, 비용 최적화 및 지속 가능성이라는 여섯 가지 기반 원칙을 간과하면 기대 및 요구에 충실한 시스템을 구축하기가 어려울 수 있습니다. 이러한 기반 원칙을 아키텍처에 통합하면 안정적이고 효율적인 시스템을 구축하는 데 도움이 됩니다. 또한 이를 바탕으로 기능적 요구 사항 등 설계의 다른 측면에 집중할 수 있게 됩니다.
**Topics**
+ [운영 우수성](operational-excellence.md)
+ [보안](security.md)
+ [신뢰성](reliability.md)
+ [성능 효율성](performance-efficiency.md)
+ [비용 최적화](cost-optimization.md)
+ [지속 가능성](sustainability.md)
# 운영 우수성
운영 우수성(OE)은 소프트웨어를 올바르게 구축하는 동시에 지속적으로 우수한 고객 경험을 제공하기 위한 노력입니다. 운영 우수성 원칙에는 팀 구성, 워크로드 설계, 규모에 따른 운영, 장기적 발전에 관한 모범 사례가 포함되어 있습니다.
운영 우수성 원칙에서는 설계 원리 개요, 모범 사례, 질문 사항을 제공합니다. 구현에 대한 권장 가이드는 [운영 우수성 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)에서 확인할 수 있습니다.
**Topics**
+ [설계 원칙](oe-design-principles.md)
+ [정의](oe-definition.md)
+ [모범 사례](oe-bp.md)
+ [리소스](oe-resources.md)
# 설계 원칙
클라우드에서 운영 우수성을 달성하기 위한 설계 원칙은 다음과 같습니다.
+ **비즈니스 성과를 중심으로 팀 구성:** 비즈니스 성과를 달성하는 팀의 역량은 리더십 비전, 효과적인 운영, 비즈니스에 맞는 운영 모델에서 비롯됩니다. 경영진은 팀이 가장 효율적인 방식으로 운영하고 비즈니스 성과를 달성하도록 장려하는 적절한 클라우드 운영 모델을 활용하여 CloudOps 혁신에 전적으로 투자하고 전념해야 합니다. 적절한 운영 모델은 규모 조정 및 최적화로 생산성을 높이고 민첩성, 대응성, 적응을 통한 차별화를 위해 인력, 프로세스 및 기술 역량을 사용합니다. 조직의 장기적 비전은 목표에 반영되고 목표는 기업 전반의 이해관계자 및 클라우드 서비스 소비자에게 전달됩니다. 목표와 운영 KPI는 모든 수준에서 연계됩니다. 이러한 관행은 다음과 같은 설계 원칙을 구현함으로써 얻을 수 있는 장기적 가치를 뒷받침합니다.
+ **실행 가능한 인사이트를 위한 관찰성 구현:** 워크로드 동작, 성능, 신뢰성, 비용 및 상태를 포괄적으로 이해할 수 있습니다. 핵심 성과 지표(KPI)를 설정하고 관찰성 원격 측정을 활용하여 정보에 입각한 결정을 내리고 비즈니스 성과가 위험에 처했을 때 즉각적인 조치를 취합니다. 실행 가능한 관찰성 데이터를 기반으로 성능, 신뢰성, 비용을 선제적으로 개선합니다.
+ **가능한 경우 안전하게 자동화:** 애플리케이션 코드를 위해 사용하였던 엔지니어링 원칙을 클라우드에서 인프라를 포함한 환경에 적용할 수 있습니다. 전체 워크로드와 해당 작업(애플리케이션, 인프라, 구성, 프로시저)을 코드로 정의하고 업데이트할 수 있습니다. 그런 다음 이벤트에 대한 응답으로 워크로드 작업을 시작하여 워크로드 작업을 자동화할 수 있습니다. 클라우드에서는 속도 제어, 오류 임곗값, 승인을 비롯한 가드레일을 구성하여 자동화 안전을 실현할 수 있습니다. 효과적인 자동화를 통해 이벤트에 일관되게 대응하고, 인적 오류를 제한하며, 작업자 수고를 줄일 수 있습니다.
+ **되돌릴 수 있는 소규모 변경 자주 적용:** 구성 요소를 정기적으로 업데이트할 수 있도록 확장 가능하고 느슨하게 결합된 워크로드를 설계합니다. 자동화된 배포 기법과 소규모의 점진적인 변경을 함께 사용하면 영향 반경을 줄이고 장애 발생 시 더 빠르게 되돌릴 수 있습니다. 이를 통해 품질을 유지하고 시장 상황의 변화에 신속하게 적응하면서 워크로드에 유익한 변화를 가져올 수 있다는 자신감이 높아집니다.
+ **수시로 운영 절차 개선:** 워크로드가 발전함에 따라 운영도 적절하게 개선합니다. 운영 절차를 사용할 때 개선할 여지가 있는지 확인합니다. 정기적으로 검토하여 모든 절차가 효과적이며 팀이 이러한 절차에 익숙한지 확인하고 검증합니다. 격차가 확인되면 그에 따라 절차를 업데이트합니다. 절차 업데이트를 모든 이해관계자와 팀에 전달합니다. 운영을 게임화하여 모범 사례를 공유하고 팀을 교육합니다.
+ **장애 예측:** 워크로드의 위험 프로필 및 비즈니스 성과에 미치는 영향을 이해하기 위해 실패 시나리오를 유도하여 운영 성공을 극대화합니다. 시뮬레이션에서 확인한 장애에 대한 절차의 효과와 팀의 대응을 테스트합니다. 테스트를 통해 확인된 미해결 위험을 관리하기 위해 정보에 입각한 결정을 내립니다.
+ **모든 운영 이벤트 및 지표에서 학습:** 모든 운영상 이벤트 및 실패로부터 파악한 내용을 통해 개선합니다. 파악한 내용을 팀 전반과 조직 전체에 공유합니다. 파악한 내용에서 운영이 비즈니스 성과에 어떻게 기여하는지에 대한 데이터와 일화를 강조해야 합니다.
+ **관리형 서비스 사용:** 가능한 경우 AWS 관리형 서비스를 사용하여 운영 부담을 줄입니다. 해당 서비스와의 상호 작용을 중심으로 운영 절차를 구축합니다.
# 정의
클라우드의 운영 우수성에는 4가지 모범 사례 영역이 있습니다.
+ **Organization**
+ **준비**
+ **운영**
+ **개선**
조직의 리더십이 비즈니스 목표를 정합니다. 조직은 요구 사항과 우선순위를 파악하고, 이를 통해 비즈니스 성과를 실현할 수 있도록 업무를 구성하고 수행해야 합니다. 또한 워크로드에서 이를 지원하는 데 필요한 정보를 생성해야 합니다. 워크로드를 통합, 배포, 제공하는 서비스를 구현하면 반복적인 프로세스를 자동화하여 프로덕션 환경에 유익한 변경 사항을 지속적으로 더 많이 적용할 수 있습니다.
워크로드 운영에 내재된 위험이 있을 수 있습니다. 이러한 위험을 파악하고 정보에 근거하여 프로덕션 환경에 적용할지 여부를 결정해야 합니다. 그리고 팀에서 워크로드를 지원할 수 있어야 합니다. 원하는 비즈니스 성과에서 도출된 비즈니스와 운영 지표를 통해 워크로드 상태, 운영 활동, 인시던트에 대한 대응 능력을 파악할 수 있습니다. 우선순위는 비즈니스 요구 사항과 비즈니스 환경 변화에 따라 달라집니다. 이를 피드백 루프로 활용하여 조직과 워크로드 운영을 지속적으로 개선합니다.
# 모범 사례
**참고**
운영 우수성과 관련된 모든 질문에는 이 원칙의 약어인 OPS가 맨 앞에 표시됩니다.
**Topics**
+ [Organization](oe-organization.md)
+ [Prepare](oe-prepare.md)
+ [운영](oe-operate.md)
+ [개선](oe-evolve.md)
# Organization
적절한 업무 수행의 기준이 되는 우선순위를 설정하려면 팀이 전체 워크로드, 워크로드 내 각 팀원의 역할 그리고 공동의 업무 목표를 파악해야 합니다. 우선순위를 잘 정하면 운영을 개선하는 과정에서 최대한의 이점을 얻을 수 있습니다. 실무 팀, 개발 팀, 운영 팀 등의 주요 이해관계자와 함께 내외부 고객 요구 사항을 평가하여 주력할 영역을 결정합니다. 고객 요구 사항을 평가하면 비즈니스 성과를 달성하는데 어떤 지원이 필요한지 철저하게 파악할 수 있습니다. 특정 초점을 의무화하거나 강조할 수 있는 규제 준수 요구 사항과 업계 표준과 같은 외부 요인과 조직의 거버넌스로 정해진 지침 또는 의무를 알고 있는지 확인합니다. 내부 거버넌스와 외부 규정 준수 요구 사항의 변경 사항을 식별할 수 있는 메커니즘이 있는지 확인합니다. 요구 사항이 식별되지 않았다는 결론을 내릴 때는 신중하게 판단하여 내린 결론인지 재차 확인해야 합니다. 정기적으로 우선순위를 검토하여 요구 사항의 변화에 따라 순위를 변경합니다.
비즈니스에 대한 위협 요소(예: 비즈니스상의 위험 및 법적 책임, 정보 보안 위협)를 평가하고 위험 목록에서 이 정보를 관리합니다. 위험의 영향과 상충하는 이해관계나 대안 사이의 장단점을 평가합니다. 예를 들어, 비용 최적화보다 새로운 기능의 시장 출시를 앞당기는 데 더 역점을 둘 수 있습니다. 아니면 리팩터링 없이 시스템 마이그레이션 작업을 간소화하기 위해 비관계형 데이터용 솔루션으로 관계형 데이터베이스를 선택할 수도 있습니다. 주력할 영역을 결정할 때 정보를 토대로 적절한 결정을 내릴 수 있도록 이점과 위험을 관리합니다. 일부 위험이나 선택은 한동안 감수할 수 있거나, 관련 위험을 완화할 수도 있습니다. 하지만 감수할 수 없는 경우에는 이를 해결하기 위한 조치를 취해야 합니다.
팀은 비즈니스 성과를 달성하기 위해 맡은 역할을 파악해야 합니다. 그리고 다른 팀의 성공을 위해 자신의 팀이 해야 할 역할과 해당 팀이 해야 할 역할을 파악하고, 목표를 공유해야 합니다. 맡은 책임, 소유권, 의사 결정 방식, 의사 결정권자를 파악하면 역량을 집중하고 팀의 이점을 극대화할 수 있습니다. 팀의 요구 사항은 팀에서 지원하는 고객, 소속된 조직, 팀 구성 및 워크로드의 특성에 따라 결정됩니다. 당연히 단일 운영 모델로는 모든 팀과 조직 내에서 그들이 맡은 워크로드를 지원할 수 없습니다.
애플리케이션, 워크로드, 플랫폼, 인프라 구성 요소마다 소유자가 명시되어 있고, 각 프로세스와 절차를 정의하고 실행하는 소유자가 각각 명시되어 있는지 확인합니다.
각 구성 요소, 프로세스, 절차의 비즈니스 가치, 이러한 리소스가 배치되거나 활동이 수행되는 이유, 그러한 소유권이 존재하는 이유를 파악하면 팀원의 작업을 알 수 있습니다. 팀원이 적절하게 행동하고 책임과 소유권을 식별하는 메커니즘이 마련되도록 팀원의 책임을 명확하게 정의합니다. 혁신에 제약이 없도록 추가, 변경 및 예외를 요청하는 메커니즘을 마련합니다. 팀 간의 협력을 통해 서로를 지원하는 방법과 비즈니스 성과를 설명하는 계약을 정의합니다.
팀원이 효과적으로 조치를 취하고 비즈니스 성과를 지원할 수 있도록 팀원에 대한 지원을 제공합니다. 참여하는 고위 리더십이 기대치를 설정하고 성공 여부를 측정해야 합니다. 고위 리더십은 조직이 발전하고 모범 사례를 도입하도록 하는 감독이자 후원자이며 지지자입니다. 성과를 달성할 수 없는 위험한 상태일 때 팀원이 그 영향을 최소화할 수 있도록 조치를 취하게 하고 위험하다고 판단될 때는 문제를 해결하고 사고를 방지할 수 있도록 의사 결정권자와 이해관계자에게 에스컬레이션하도록 합니다. 팀원이 적시에 적절한 조치를 취할 수 있도록 알려진 위험과 계획된 이벤트와 관련하여 시기 적절하고 명확하게 대화하며 실행 가능한 부분을 알려줍니다.
실험을 권장하여 학습을 가속화하고 팀원의 관심과 참여를 유지합니다. 팀은 새로운 기술을 도입하고 요구 사항과 책임이 변했을 때 이를 지원할 수 있도록 기술을 발전시켜야 합니다. 학습을 위한 시간을 따로 지정하여 이를 지원하고 장려합니다. 팀원이 성공과 비즈니스 성과 지원을 위한 확장에 필요한 리소스 즉, 도구와 팀원을 모두 확보하고 있는지 확인합니다. 조직 간의 다양성을 활용하여 여러 가지 고유한 관점을 모색합니다. 이러한 관점을 통해 혁신을 증진하고, 기존의 추정 사항에 의문을 제기하며, 확증 편향의 위험을 줄일 수 있습니다. 팀 내에서 포용성, 다양성, 접근성을 높여 유익한 관점을 확보합니다.
조직에 적용되는 외부 규제 또는 규정 준수 요구 사항이 있다면 팀원이 우선순위에 대한 영향을 확인할 수 있도록 [AWS 클라우드 규정 준수](https://aws.amazon.com/compliance/?ref=wellarchitected-wp)에서 제공하는 리소스를 사용하여 관련 정보를 제공해야 합니다. Well-Architected Framework에서는 학습, 평가, 개선을 강조합니다. 아키텍처를 평가하고 시간에 따라 규모를 조정 가능한 설계를 구현하는 일관된 접근 방식을 제공합니다. AWS에서 선보이는 AWS Well-Architected Tool은 개발 전의 접근 방식, 프로덕션 환경에 적용하기 전의 워크로드 상태, 프로덕션 환경에서의 워크로드 상태를 검토합니다. 워크로드를 최신 AWS 아키텍처 모범 사례와 비교하고, 워크로드의 전반적인 상태를 모니터링하며, 잠재적 위험에 대한 인사이트를 얻을 수 있습니다. AWS Trusted Advisor은 우선순위 결정에 도움이 될 수 있는 최적화 방안을 알려 주는 핵심 검사 세트를 이용할 수 있는 도구입니다. Business 및 Enterprise Support 고객에게는 우선순위를 더욱 세세히 결정하는 데 사용할 수 있는 검사 기능이 추가로 제공됩니다. 이러한 기능을 사용하면 보안, 신뢰성, 성능, 비용 최적화, 지속 가능성 영역을 중점적으로 확인할 수 있습니다.
AWS를 활용하면 선택한 방식이 워크로드에 미치는 영향을 효과적으로 파악하도록 팀에 AWS와 해당 서비스 관련 정보를 제공할 수 있습니다. AWS Support(AWS 지식 센터, AWS 토론 포럼, AWS Support 센터) 및 AWS 설명서에 나와 있는 리소스를 사용해서 팀을 교육해야 합니다. AWS Support 센터를 통해 AWS Support 팀에 문의하여 AWS 관련 질문의 답을 찾을 수도 있습니다. AWS는 AWS 운영을 통해 학습한 모범 사례와 패턴을 Amazon Builders' Library에서 공유합니다. AWS 블로그 및 공식 AWS 팟캐스트에서도 기타 여러 가지 유용한 정보를 확인할 수 있습니다. AWS 교육 및 자격증에서는 AWS 기초에 관한 자습형 디지털 과정을 통해 일부 교육을 제공합니다. 강사 주도형 교육에 등록하여 팀이 AWS 기술을 연마하도록 추가로 지원할 수도 있습니다.
운영 모델 관리를 위해 AWS Organizations와 같이 여러 계정에 걸쳐 환경을 중앙 집중식으로 관리할 수 있는 도구나 서비스를 사용해야 합니다. AWS Control Tower와 같은 서비스는 계정 설정을 위한 블루프린트(운영 모델 지원)를 정의하고, AWS Organizations를 통해 지속적으로 거버넌스를 적용하며, 새로운 계정의 프로비저닝을 자동화할 수 있도록 함으로써 이 관리 기능을 확장합니다. 관리형 서비스 제공업체(예: AWS Managed Services, AWS Managed Services 파트너 또는 AWS 파트너 네트워크의 관리형 서비스 제공업체)를 통해 클라우드 환경을 전문적으로 구현할 수 있으며, 보안 및 규정 준수 요구 사항과 비즈니스 목표를 지원받을 수 있습니다. 관리형 서비스를 운영 모델에 추가하면 시간과 리소스를 절약할 수 있으며, 새로운 기술과 기능을 개발하는 대신 내부 팀이 비즈니스를 차별화하는 전략적 결과에 집중할 수 있습니다.
다음은 운영 우수성 고려 사항에 중점을 둔 질문입니다. (운영 우수성 질문 및 모범 사례 목록은 [부록](a-organization.md)을 참조하세요.)
| OPS 1: 회사에서 우선순위를 어떻게 결정하나요? |
| --- |
| 모든 사람이 비즈니스 성공을 달성하는 데 있어 자신의 역할을 이해해야 합니다. 리소스 우선순위 설정을 위한 공동의 목표가 있어야 합니다. 그러면 운영을 개선하려는 노력의 이점을 극대화할 수 있습니다. |
| OPS 2: 비즈니스 성과를 지원하기 위해 조직을 어떻게 구성하나요? |
| --- |
| 팀은 비즈니스 성과를 달성하기 위해 맡은 역할을 파악해야 합니다. 그리고 다른 팀의 성공을 위해 자신의 팀이 해야 할 역할과 해당 팀이 해야 할 역할을 파악하고, 목표를 공유해야 합니다. 맡은 책임, 소유권, 의사 결정 방식, 의사 결정권자를 파악하면 역량을 집중하고 팀의 이점을 극대화할 수 있습니다. |
| OPS 3: 조직 문화는 비즈니스 성과를 어떻게 지원하나요? |
| --- |
| 팀원이 효과적으로 조치를 취하고 비즈니스 성과를 지원할 수 있도록 팀원에 대한 지원을 제공합니다. |
특정 시점에 우선순위 중 일부를 중점적으로 처리해야 할 수도 있습니다. 필요한 기능을 개발하고 위험을 관리하려면 워크로드 우선순위를 장기적으로 적절하게 절충해야 합니다. 우선순위를 정기적으로 검토하고 요구 사항이 바뀌면 그에 따라 변경합니다. 책임과 소유권을 정의하지 않았거나 알지 못하는 경우 필요한 활동을 적시에 처리하지 못하고 해당 요구 사항을 해결하기 위한 작업이 중복되고 잠재적으로 상충될 위험이 있습니다. 조직 문화는 팀원의 업무 만족도와 팀원 이직률에 직접적인 영향을 미칩니다. 팀원의 참여와 역량을 통해 비즈니스의 성공을 뒷받침할 수 있습니다. 혁신과 아이디어를 실현하려면 실험이 필요합니다. 원치 않는 결과가 나와도 성공하지 못하는 경로를 알게 되었으므로 실험에 성공한 것으로 인정합니다.
# Prepare
운영 우수성 달성을 준비하려면 워크로드 및 예상되는 워크로드 동작을 파악해야 합니다. 그러면 워크로드가 상태 관련 인사이트를 제공하도록 설계할 수 있으며, 워크로드를 지원하는 절차를 작성할 수 있습니다.
문제를 관찰하고 조사할 수 있도록 모든 구성 요소에서 지표, 로그, 이벤트, 추적 등 내부 상태를 파악하는 데 필요한 정보를 얻을 수 있도록 워크로드를 설계합니다. 관찰성은 단순한 모니터링을 넘어서서 외부 출력을 기반으로 시스템의 내부 작동을 포괄적으로 이해할 수 있게 합니다. 지표, 로그, 추적에 기반을 둔 관찰성을 통해 시스템 동작과 역학에 대한 심층적인 인사이트를 얻을 수 있습니다. 효과적인 관찰성을 통해 팀은 패턴, 이상 및 추세를 식별하여 잠재적 문제를 사전에 해결하고 최적의 시스템 상태를 유지할 수 있습니다. 모니터링 활동과 비즈니스 목표를 일치시키기 위해서는 핵심 성과 지표(KPI)를 식별하는 것이 매우 중요합니다. 이러한 조정을 통해 팀은 진정으로 중요한 지표를 사용하여 데이터를 기반으로 결정을 내리고 시스템 성능과 비즈니스 결과를 모두 최적화할 수 있습니다. 또한 관찰성을 통해 기업은 사후 대응이 아닌 사전 대응이 가능합니다. 팀은 단순히 대응하는 데 그치지 않고 시스템 내의 인과 관계를 이해하여 문제를 예측하고 예방할 수 있습니다. 워크로드가 진화함에 따라 관찰성 전략을 재검토하고 개선하여 관련성과 효율성을 유지하는 것이 중요합니다.
프로덕션 환경으로 변경 사항을 전달하는 흐름을 개선할 수 있는 방식을 도입합니다. 이 방식은 리팩터링, 품질에 대한 빠른 피드백, 버그 수정을 지원해야 합니다. 이러한 방식을 도입하면 유용한 변경 사항을 프로덕션 환경으로 빠르게 전달할 수 있고 문제가 퍼질 가능성을 제한할 수 있으며 배포 활동을 통해 발생하거나 환경에서 발생된 문제를 빠르게 파악하고 해결할 수 있습니다.
품질과 관련한 피드백을 빠르게 제공하며 적절한 성과를 달성하는 데 도움이 되지 않는 변경 사항을 적용한 경우 신속하게 복구할 수 있는 방식을 도입합니다. 이러한 사례를 사용하면 변경 사항 배포로 인해 발생하는 문제의 영향을 완화할 수 있습니다. 필요한 경우 더 빠르게 대응하고 변경 사항을 테스트하고 확인할 수 있도록 부적절한 변경 사항을 처리할 계획을 세웁니다. 계획된 활동에 변경 사항이 미치는 위험을 제어할 수 있도록 환경 내에서 일어날 활동을 알고 있어야 합니다. 되돌릴 수 있도록 조금씩 자주 변경 사항을 적용하도록 변경 범위를 제한합니다. 그러면 문제를 더 쉽게 해결할 수 있으며 변경 사항 롤백 옵션을 사용해 문제 해결 시간을 단축할 수 있습니다. 또한 중요한 변경 사항의 이점을 더 자주 누릴 수 있기도 합니다.
워크로드, 프로세스, 절차, 직원의 운영 준비 상태를 평가하여 워크로드와 관련된 운영 위험을 파악합니다. 수동 또는 자동화된 체크리스트 등 일관된 프로세스를 사용하여 워크로드 또는 변경에 대응할 수 있는 준비가 되었는지 확인해야 합니다. 이렇게 하면 문제 해결 계획을 세워야 하는 영역도 파악할 수 있습니다. 일상 활동을 문서화한 런북과 문제 해결 프로세스를 안내하는 플레이북을 준비합니다. 이점과 위험을 파악하여 프로덕션에 변경 사항 적용에 대해 정보에 입각한 결정을 내립니다.
AWS에서 전체 워크로드(애플리케이션, 인프라, 정책, 거버넌스, 운영)를 코드로 확인할 수 있습니다. 즉, 애플리케이션 코드에 사용하는 것과 동일한 엔지니어링 분야를 스택의 모든 요소에 적용하고 이를 팀 또는 조직 간에 공유하여 개발 작업의 이점을 확대할 수 있습니다. 클라우드에서 코드를 통해 운영하면 안전하게 실험하여 워크로드와 운영 절차를 개발하고 실패를 연습할 수 있습니다. CloudFormation을 사용하면 운영 제어 수준을 점점 향상할 수 있는 일관된 템플릿 형식의 샌드박스 개발, 테스트, 생산 환경을 갖출 수 있습니다.
다음은 운영 우수성 고려 사항에 중점을 둔 질문입니다.
| OPS 4: 워크로드에 어떻게 관찰성을 구현하나요? |
| --- |
| 워크로드에 관찰성을 구현하여 상태를 파악하고 비즈니스 요구 사항에 따라 데이터 기반 결정을 내릴 수 있습니다. |
| OPS 5: 어떻게 결함을 줄이고 수정 작업을 쉽게 수행하고 프로덕션으로 이어지는 흐름을 개선하나요? |
| --- |
| 프로덕션 환경으로 변경 사항을 전달하는 흐름을 개선할 수 있는 방식을 도입합니다. 이 방식으로 리팩터링, 품질과 관련된 빠른 피드백 및 버그 수정이 가능합니다. 이렇게 하면 유용한 변경 사항을 프로덕션 환경으로 빠르게 전달할 수 있고, 문제 배포 가능성을 제한할 수 있으며, 배포 활동을 통해 발생하는 문제를 빠르게 파악하고 해결할 수 있습니다. |
| OPS 6: 배포 위험을 어떻게 최소화하나요? |
| --- |
| 품질과 관련한 피드백을 빠르게 제공하며, 적절한 성과를 달성하는 데 도움이 되지 않는 변경을 수행한 경우 신속하게 복구할 수 있는 방식을 도입합니다. 이러한 사례를 사용하면 변경 사항 배포로 인해 발생하는 문제의 영향을 완화할 수 있습니다. |
| OPS 7: 귀사가 워크로드를 지원할 준비가 되어있는지 어떻게 알 수 있나요? |
| --- |
| 워크로드, 프로세스, 절차 및 직원의 운영 준비 상태를 평가하여 워크로드와 관련된 운영 위험을 파악합니다. |
코드를 통해 운영 활동을 구현하여 운영 인력의 생산성을 최대화하고 오류율을 최소화하며 대응을 자동화할 수 있습니다. 해당하는 경우에는 '사전 분석' 기능을 사용하여 장애를 예측하고 절차를 생성합니다. 리소스 태그와 AWS Resource Groups를 사용하여 메타데이터를 적용하고 일관된 태그 지정 전략을 시행하면 리소스를 식별할 수 있습니다. 조직, 비용 회계, 액세스 제어의 리소스에 태그를 지정하여 자동화된 운영 활동을 실행할 대상을 설정합니다. 클라우드의 탄력성을 활용하는 배포 실습을 도입하여 개발 활동을 용이하게 하고 시스템을 사전 배포할 수 있도록 함으로써 보다 빠르게 구현합니다. 워크로드를 평가하는 데 사용하는 체크리스트를 변경할 때는 해당 변경으로 인해 더 이상 규정을 준수하지 못하게 되는 사용 중인 시스템은 어떻게 할 것인지 계획합니다.
# 운영
관찰성을 통해 의미 있는 데이터에 집중하고 워크로드의 상호 작용과 결과를 이해할 수 있습니다. 필수 인사이트에 집중하고 불필요한 데이터를 제거함으로써 워크로드 성능을 이해할 수 있는 간단한 접근 방식을 유지할 수 있습니다. 데이터를 수집하는 것뿐만 아니라 데이터를 올바르게 해석하는 것도 중요합니다. 명확한 기준을 정의하고, 적절한 경고 임곗값을 설정하며, 편차를 적극적으로 모니터링합니다. 특히 다른 데이터와 관계가 있는 경우 주요 지표의 변화로 특정 문제 영역을 정확히 찾아낼 수 있습니다. 관찰성을 사용하면 잠재적 문제를 더 잘 예측하고 해결하여 워크로드를 원활하게 운영하고 비즈니스 요구 사항을 충족할 수 있습니다.
워크로드 운영의 성공은 비즈니스 및 고객 성과 달성에 따라 측정됩니다. 예상 결과를 정의하고 성공을 측정하는 방법을 결정하며 이러한 계산에 사용될 지표를 식별하여 워크로드와 운영이 성공적인지 여부를 결정합니다. 운영 상태에는 워크로드 상태, 워크로드 지원 시 수행되는 운영 활동의 상태와 성공이 모두 포함됩니다(예: 배포 및 인시던트 응답). 개선, 조사 및 개입에 대한 지표 기준선을 설정하고 지표를 수집 및 분석한 후 운영 성공에 대한 이해 및 시간에 따라 어떻게 변하는지를 확인합니다. 수집된 지표를 사용하여 고객과 비즈니스 요구 사항을 충족하는지 여부를 확인하고 개선 영역을 식별합니다.
운영 우수성을 달성하려면 효과적이고 효율적인 운영 이벤트 관리가 필요합니다. 이는 계획된 운영 이벤트 및 계획되지 않은 운영 이벤트 모두에 적용됩니다. 사전에 파악된 이벤트에 대해 런북을 작성하여 사용하고, 문제 조사 및 해결에 도움이 되는 해결책을 지원하는 데는 플레이북을 사용합니다. 비즈니스와 고객에게 미치는 영향을 기반으로 이벤트 대응의 우선순위를 지정합니다. 이벤트 대응에 경고가 발생하는지 연결된 실행 프로세스가 있는지를 담당자와 함께 확인합니다. 이벤트를 해결하는 데 필요한 인력을 미리 정하고 에스컬레이션 프로세스를 포함하여 필요할 경우 긴급성과 영향을 기반으로 추가 인력을 배치합니다. 권한이 있는 개인을 식별하고 참여시켜 이전에 해결되지 않은 이벤트 대응에 대해 대응 과정이 비즈니스에 영향을 미쳤는지 확인합니다.
대상(예: 고객, 비즈니스, 개발자, 운영)에 맞는 알림과 대시보드를 통해 워크로드 운영 상태를 전달하여 적절한 조치를 취하고 기대 사항을 관리하며 정상 운영이 다시 시작될 때 알림을 받을 수 있도록 합니다.
AWS에서는 AWS의 기본 지표와 워크로드에서 수집된 지표가 나와 있는 대시보드 보기를 생성할 수 있습니다. CloudWatch 또는 서드파티 애플리케이션을 활용하여 운영 활동의 비즈니스, 워크로드, 운영 수준 보기를 표시하고 집계할 수 있습니다. AWS에서는 AWS X-Ray, CloudWatch, CloudTrail, VPC 흐름 로그 등 로깅 기능을 통해 워크로드 인사이트를 제공하여 워크로드 문제를 파악하고 근본 원인 분석 및 수정을 지원합니다.
다음은 운영 우수성 고려 사항에 중점을 둔 질문입니다.
| OPS 8: 워크로드 관찰성을 어떻게 활용하나요? |
| --- |
| 관찰성을 활용하여 워크로드 상태를 최적화합니다. 관련 지표, 로그, 추적을 활용하여 워크로드 성능을 종합적으로 파악하고 문제를 효율적으로 해결합니다. |
| OPS 9 운영 상태를 어떻게 파악하나요? |
| --- |
| 운영 지표를 정의, 캡처 및 분석하면 운영 이벤트에 대한 가시성을 확보하여 적절한 조치를 취할 수 있습니다. |
| OPS 10: 워크로드 및 운영 이벤트를 어떻게 관리하나요? |
| --- |
| 이벤트로 인해 워크로드가 중단될 가능성을 최소화할 수 있도록 이벤트 대응을 위한 절차를 준비하고 검증합니다. |
수집하는 모든 지표는 비즈니스 요구 사항과 지원되는 성과에 부합해야 합니다. 잘 알려진 이벤트에 대한 스크립팅된 응답을 개발하고 이벤트 인식에 대한 응답으로 성능을 자동화합니다.
# 개선
운영 우수성을 유지하려면 학습하고 공유하며 지속적으로 개선해야 합니다. 거의 연속적이고 서서히 개선을 이뤄내는 데에 주력하여 작업 주기를 조절합니다. 고객에게 영향을 미치는 모든 이벤트의 사후 분석을 수행합니다. 재발 제한 또는 방지를 위한 기여 요인과 예방 조치를 파악합니다. 영향을 받는 커뮤니티와 함께 기여 요소를 적절히 알립니다. 워크로드와 운영 절차 모두를 포함하여 개선할 부분(예: 기능 요청, 문제 해결, 규정 준수 요구 사항)을 정기적으로 평가하고 우선순위를 조정합니다.
절차 내에 피드백 루프를 포함시켜 개선할 영역을 빠르게 식별하고 실행을 통해 학습한 교훈을 파악합니다.
팀 전반에 걸쳐 파악한 내용을 공유하여 이러한 내용의 이점도 함께 공유합니다. 파악한 내용 내의 추세를 분석하고 운영 지표에 대해 팀 교차 후행 분석을 수행하여 개선할 여지 및 방법을 식별합니다. 개선하려는 변경 사항을 적용하고 결과를 평가하여 성공 여부를 확정합니다.
AWS에서 Amazon S3로 로그 데이터를 내보내거나 장기 보관을 위해 Amazon S3로 로그를 직접 전송할 수 있습니다. AWS Glue를 사용하면 분석을 위해 Amazon S3의 로그 데이터를 검색 및 준비하여 AWS Glue Data Catalog에 관련된 메타데이터를 저장할 수 있습니다. 그리고 Amazon Athena에서 AWS Glue와의 기본 통합을 통해 로그 데이터를 분석하고 표준 SQL을 사용해 쿼리할 수 있습니다. Amazon Quick과 같은 비즈니스 인텔리전스 도구를 사용하면 데이터를 시각화하고 탐색하며 분석할 수 있습니다. 개선을 이끌 추세와 관심 이벤트를 찾습니다.
다음은 운영 우수성 고려 사항에 중점을 둔 질문입니다.
| OPS 11: 운영을 어떻게 지속적으로 개선하나요? |
| --- |
| 시간과 리소스를 할애하여 점진적 개선을 거의 지속적으로 수행하면 운영의 효과와 효율성을 높일 수 있습니다. |
성공적인 운영 개선은 잦은 소규모 개선, 안전한 환경 제공, 실험과 개발, 테스트 개선을 위한 시간 제공 그리고 실패로부터 학습을 독려하는 환경을 통해 이루어집니다. 샌드박스, 개발, 테스트, 생산 환경에 대한 운영 지원을 통해 운영 제어 수준을 점점 높아지도록 하고 개발을 촉진하며 생산 단계에 배포된 변경에서 성공적인 결과를 예측할 수 있도록 합니다.
# 리소스
운영 우수성 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하세요.
## 설명서
+ [DevOps 및 AWS](https://aws.amazon.com/devops/?ref=wellarchitected-wp)
## 백서
+ [운영 우수성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html?ref=wellarchitected-wp)
## 비디오
+ [Amazon의 DevOps](https://www.youtube.com/watch?v=esEFaY0FDKc&ref=wellarchitected-wp)
# 보안
보안 원칙에는 클라우드 기술을 활용하여 보안을 강화하고 데이터, 시스템 및 자산을 보호하는 능력이 포함됩니다.
보안 원칙에서는 설계 원칙 개요, 모범 사례 및 질문 사항을 제공합니다. 구현에 대한 권장 가이드는 [보안 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html?ref=wellarchitected-wp)에서 확인할 수 있습니다.
**Topics**
+ [설계 원칙](sec-design.md)
+ [정의](sec-def.md)
+ [모범 사례](sec-bp.md)
+ [리소스](sec-resources.md)
# 설계 원칙
클라우드에는 워크로드 보안을 강화할 수 있는 여러 가지 원칙이 존재합니다.
+ **강력한 자격 증명 기반 구현:** 최소 권한 원칙을 구현하고 AWS 리소스와의 각 상호 작용에 대한 적절한 권한을 부여하여 업무를 분리합니다. 자격 증명 관리를 중앙 집중화하고 장기적인 정적 자격 증명에 대한 의존도를 해소하는 것을 목표로 합니다.
+ **추적 기능 유지 관리:** 실시간으로 환경에 대한 작업 및 변경 사항을 모니터링하고 알림을 전송하며 감사합니다. 로그 및 지표 수집을 시스템과 통합하여 자동으로 조사하고 조치를 취합니다.
+ **모든 계층에 보안 적용:** 여러 보안 제어와 함께 심층 방어 접근 방식을 적용합니다. 모든 계층(예: 네트워크 엣지, VPC, 로드 밸런싱, 모든 인스턴스 및 컴퓨팅 서비스, 운영 체제, 애플리케이션, 코드)에 적용됩니다.
+ **보안 모범 사례의 자동 적용:** 자동화된 소프트웨어 기반의 보안 메커니즘은 안전한 규모 조정 능력을 빠르고 비용 효율적으로 향상시킵니다. 버전 제어가 가능한 템플릿에서 코드로 정의되고 관리되는 제어 기능의 구현을 비롯한 보안 아키텍처를 생성합니다.
+ **전송 중 데이터 및 보관 중인 데이터 보호:** 데이터를 민감도 수준에 따라 분류하고 적절한 경우 암호화, 토큰화 및 액세스 제어와 같은 메커니즘을 사용합니다.
+ **사람들이 데이터에 쉽게 접근할 수 없도록 유지:** 데이터에 대한 직접 액세스 또는 수동 처리의 필요성을 줄이거나 없애기 위한 메커니즘 및 도구를 사용합니다. 이를 통해 민감한 데이터를 처리할 때 잘못된 취급이나 수정 및 수작업으로 인한 오류의 위험을 줄일 수 있습니다.
+ **보안 이벤트에 대비:** 조직의 요구 사항에 부합하는 인시던트 관리 및 조사 정책과 프로세스를 통해 사고에 대비합니다. 인시던트 대응 시뮬레이션을 실행하고 자동화된 도구를 사용하여 감지, 조사 및 복구 속도를 높입니다.
# 정의
클라우드의 보안에는 7가지 모범 사례 영역이 있습니다.
+ 보안 기초
+ ID 및 액세스 관리
+ 감지
+ 인프라 보호
+ 데이터 보호
+ 인시던트 대응
+ 애플리케이션 보안
워크로드를 설계하기 전에 보안에 영향을 미치는 업무의 수행 방식을 마련해야 합니다. 작업을 수행할 수 있는 대상 및 작업 내용을 제어할 수 있어야 합니다. 또한 보안 사고를 식별하고 시스템과 서비스를 보호하며 데이터 보호를 통해 데이터의 기밀성과 무결성을 유지할 수 있기를 원합니다. 보안 사고에 대응하기 위한 잘 정의된 프로세스를 마련하고 숙련해야 합니다. 이는 금전적 손해 방지 또는 규제 의무 준수 등 목표 달성을 뒷받침하는 중요한 도구이자 기법입니다.
AWS 공동 책임 모델은 클라우드를 채택한 고객의 보안 및 규정 준수 목표를 이루는데 도움을 줍니다. 클라우드 서비스를 뒷받침하는 인프라를 AWS가 물리적으로 보호해 주기 때문에 AWS 고객들은 서비스를 이용하여 목표를 달성하는 데 집중할 수 있습니다. 또한 AWS 클라우드에서는 보안 데이터에 더 폭넓게 액세스할 수 있으며 보안 이벤트에 대한 응답도 자동화되어 있습니다.
# 모범 사례
**Topics**
+ [보안 기초](sec-security.md)
+ [ID 및 액세스 관리](sec-iam.md)
+ [감지](sec-detection.md)
+ [인프라 보호](sec-infrastructure.md)
+ [데이터 보호](sec-dataprot.md)
+ [사고 대응](sec-incresp.md)
+ [애플리케이션 보안](sec-appsec.md)
# 보안 기초
다음은 보안 고려 사항에 중점을 둔 질문입니다. (보안 질문 및 모범 사례 목록은 [부록](a-security.md)을 참조하세요.)
| SEC 1: 워크로드를 안전하게 운영하려면 어떻게 해야 하나요? |
| --- |
| 워크로드를 안전하게 운영하려면 모든 보안 영역에 중요한 모범 사례를 적용해야 합니다. 운영 우수성에 대해 조직 및 워크로드 수준에서 정의한 요구 사항 및 프로세스를 모든 영역에 적용하세요. AWS의 권장 사항, 업계 리소스 및 위협 인텔리전스를 최신 상태로 유지하면 위협 모델 및 제어 목표를 발전시키는 데 도움이 됩니다. 보안 프로세스, 테스트 및 검증을 자동화하면 보안 운영을 확장할 수 있습니다. |
AWS에서는 다양한 워크로드를 기능 및 규정 준수 또는 데이터 민감도 요구 사항에 따라 계정별로 분리하는 것이 좋습니다.
# ID 및 액세스 관리
자격 증명 및 액세스 관리는 정보 보안 프로그램의 핵심 요소로, 허가되고 인증된 사용자 및 구성 요소에 한해 허용되는 방식으로만 리소스에 액세스할 수 있도록 하는 것을 말합니다. 예를 들어 보안 주체(계정에서 작업을 수행할 수 있는 계정, 사용자, 역할 및 서비스)를 정의하고, 이러한 보안 주체에 맞게 정의된 정책을 구축하고, 강력한 자격 증명 관리를 구현합니다. 이러한 권한 관리 요소가 인증 및 권한 부여의 핵심 개념을 이룹니다.
AWS에서는 기본적으로 AWS 서비스 및 리소스에 대한 사용자 액세스를 고객이 직접 제어할 수 있도록 하는 AWS Identity and Access Management(IAM) 서비스로 권한 관리를 지원합니다. 사용자, 그룹, 역할 또는 리소스에 대한 권한을 세부 정책으로 지정할 수 있습니다. 또한 복잡성, 재사용, 다중 인증(MFA) 등 강력한 암호를 요구할 수 있는 기능도 있습니다. 기존의 디렉터리 서비스와 연동되도록 할 수도 있습니다. 시스템이 AWS에 액세스해야 하는 워크로드의 경우 IAM이 인스턴스 프로필, 자격 증명 연동, 임시 자격 증명을 통해 보안 액세스를 보장합니다.
다음은 보안 고려 사항에 중점을 둔 질문입니다.
| SEC 2: 사람과 시스템에 대한 자격 증명은 어떻게 관리하나요? |
| --- |
| 보안 AWS 워크로드를 운영할 때는 두 가지 유형의 ID를 관리해야 합니다. 액세스 권한을 관리하고 부여하는 데 필요한 자격 증명의 유형을 이해하면 적절한 자격 증명이 적절한 조건에서 적절한 리소스에 액세스할 수 있도록 보장할 수 있습니다. 사람 ID: 관리자, 개발자, 운영자 및 최종 사용자가 AWS 환경 및 애플리케이션에 액세스하려면 ID가 필요합니다. 조직의 구성원 또는 웹 브라우저, 클라이언트 애플리케이션 또는 대화형 명령줄 도구를 통해 AWS 리소스와 상호 작용하는 외부 사용자입니다. 시스템 자격 증명: 서비스 애플리케이션, 운영 도구 및 워크로드에서 AWS 서비스에 요청하려면(예: 데이터 읽기) 자격 증명이 필요합니다. 이러한 ID에는 AWS 환경에서 실행되는 시스템이 포함됩니다(예: Amazon EC2 인스턴스 또는 AWS Lambda 함수). 또한 액세스 권한이 필요한 외부 당사자를 위해 시스템 ID를 관리할 수도 있습니다. 또한 AWS 외부에 AWS 환경에 대한 액세스 권한이 필요한 시스템이 있을 수도 있습니다. |
| SEC 3: 사람과 시스템에 대한 권한은 어떻게 관리하나요? |
| --- |
| AWS 및 워크로드에 액세스해야 하는 사람 및 시스템 자격 증명에 대한 액세스를 제어하는 권한을 관리합니다. 권한은 누가 어떤 조건에서 무엇에 액세스할 수 있는지를 제어합니다. |
자격 증명은 어떠한 사용자 또는 시스템과도 공유할 수 없습니다. 사용자 액세스 권한은 암호 요구 사항 및 MFA 적용을 포함하는 모범 사례와 함께 최소한의 권한 접근 방식을 사용하여 부여해야 합니다. AWS 서비스에 대한 API 직접 호출을 포함한 프로그래밍 방식의 액세스는 AWS Security Token Service에서 발행한 것과 같은 임시 및 제한된 권한 자격 증명을 사용하여 수행해야 합니다.
사용자가 AWS Management Console 외부에서 AWS와 상호 작용하려면 프로그래밍 방식의 액세스 권한이 필요합니다. 프로그래밍 방식의 액세스 권한을 부여하는 방법은 AWS에 액세스하는 사용자 유형에 따라 다릅니다.
사용자에게 프로그래밍 방식의 액세스 권한을 부여하려면 다음 옵션 중 하나를 선택합니다.
****
| 프로그래밍 방식 액세스가 필요한 사용자 | 목적 | 방법 |
| --- | --- | --- |
| IAM | (권장됨) 콘솔 자격 증명을 임시 자격 증명으로 사용하여 AWS CLI, AWS SDK 또는 AWS API에 대한 프로그래밍 요청에 서명합니다. | 사용하고자 하는 인터페이스에 대한 지침을 따릅니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/sec-iam.html) |
| 작업 인력 ID (IAM Identity Center에서 관리되는 사용자) | 임시 자격 증명을 사용하여 AWS CLI, AWS SDK 또는 AWS API에 대한 프로그래밍 요청에 서명합니다. | 사용하고자 하는 인터페이스에 대한 지침을 따릅니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/sec-iam.html) |
| IAM | 임시 자격 증명을 사용하여 AWS CLI, AWS SDK 또는 AWS API에 대한 프로그래밍 요청에 서명합니다. | IAM 사용자 설명서의 [AWS 리소스와 함께 임시 자격 증명 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)에 나와 있는 지침을 따르세요. |
| IAM | (권장되지 않음)장기 자격 증명을 사용하여 AWS CLI, AWS SDK 또는 AWS API에 대한 프로그래밍 요청에 서명합니다. | 사용하고자 하는 인터페이스에 대한 지침을 따릅니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/sec-iam.html) |
AWS는 Identity and Access Management를 사용하여 도울 수 있는 리소스를 제공합니다. 모범 사례를 배우려면 [자격 증명 및 인증 관리](https://wellarchitectedlabs.com/Security/Quest_Managing_Credentials_and_Authentication/README.html?ref=wellarchitected-wp), [사용자 액세스 제어](https://wellarchitectedlabs.com/Security/Quest_Control_Human_Access/README.html?ref=wellarchitected-wp), [프로그래밍 방식 액세스 제어](https://wellarchitectedlabs.com/Security/Quest_Control_Programmatic_Access/README.html?ref=wellarchitected-wp)에 대한 실습을 살펴보세요.
# 감지
탐지 제어를 사용하여 잠재적 보안 위협 또는 인시던트를 식별할 수 있습니다. 이러한 제어는 일반적인 거버넌스 프레임워크의 핵심 부분으로, 품질 프로세스, 법률 또는 규정 준수 의무, 위협 식별 및 대응 과정을 지원하는 데 사용됩니다. 탐지 제어의 종류는 여러 가지입니다. 예를 들어, 자산 및 해당 세부 속성의 인벤토리를 만들어 두면 보다 효과적인 의사 결정(및 수명 주기 전반의 제어)이 이루어지고, 이를 운영의 기준으로 삼을 수 있습니다. 또한 내부 감사를 통해 정보 시스템과 관련된 제어 기능을 검사하여 실제 사례가 정책 및 요건에 맞는지, 정의된 조건에 따라 올바른 자동 알림이 설정되어 있는지 확인할 수 있습니다. 이러한 제어 기능은 조직 내에서 변칙적 활동 범위를 식별하고 파악하는 데 도움이 되는 중요한 대응 요소입니다.
AWS에서는 로그, 이벤트 및 모니터링(감사, 자동 분석 및 경보)을 처리하여 탐지 제어를 구현할 수 있습니다. CloudTrail 로그, AWS API 직접 호출 및 CloudWatch는 경보와 함께 측정치 모니터링을 제공하며 AWS Config는 구성 내역을 제공합니다. Amazon GuardDuty는 악성 또는 인증되지 않은 동작을 지속적으로 모니터링하여 AWS 계정 및 워크로드를 보호하도록 지원하는 관리형 위협 탐지 서비스입니다. 또한 서비스 수준 로그도 사용 가능한데, 예를 들어 Amazon Simple Storage Service(S3)를 사용하여 액세스 요청을 기록할 수 있습니다.
다음은 보안 고려 사항에 중점을 둔 질문입니다.
| SEC 4: 보안 관련 이벤트를 어떻게 감지하고 조사하나요? |
| --- |
| 로그와 지표에서 이벤트를 캡처하고 분석하여 가시성을 확보합니다. 보안 이벤트 및 잠재적 위협에 대해 조치를 취해 워크로드를 보호할 수 있습니다. |
Well-Architected 워크로드에서 로그 관리가 중요한 이유는 보안 또는 포렌식부터 규제 또는 법적 요구 사항에 이르기까지 다양합니다. 잠재적 보안 인시던트를 식별하려면 로그를 분석하고 이에 대응하는 것이 매우 중요합니다. AWS는 데이터 보존 기간 또는 데이터 보존, 아카이브 또는 삭제 위치를 정의하는 기능을 고객에게 부여함으로써 로그 관리를 보다 쉽게 구현할 수 있도록 합니다. 이렇게 하면 더 단순하고 경제적인 방식으로, 예측 가능하고 신뢰할 수 있도록 데이터를 처리할 수 있습니다.
# 인프라 보호
모범 사례와 업계 규정 또는 규제 의무를 준수하기 위해서는 인프라 보호가 필요하며, 여기에는 심층 방어와 같은 제어 방법이 포함됩니다. 지속적으로 클라우드 또는 온프레미스에서 작업을 성공적으로 수행하려면 반드시 이러한 방법을 사용해야 합니다.
AWS에서는 AWS 기본 기술을 사용하거나 AWS Marketplace에서 제공되는 파트너 제품 및 서비스를 사용하여 상태 저장(Stateful) 및 상태 비저장(Stateless) 방식의 패킷 검사를 구현할 수 있습니다. Amazon Virtual Private Cloud(VPC)를 사용하여 안전하고 확장 가능한 프라이빗 환경을 만들고, 여기에서 게이트웨이, 라우팅 테이블, 퍼블릭 및 프라이빗 서브넷 같은 토폴로지를 정의해야 합니다.
다음은 보안 고려 사항에 중점을 둔 질문입니다.
| SEC 5: 네트워크 리소스는 어떻게 보호하나요? |
| --- |
| 인터넷이든 프라이빗 네트워크이든 상관없이 어떤 형태든 네트워크 연결이 있는 워크로드에는 외부 및 내부 네트워크 기반 위협으로부터 보호하기 위한 다중 방어 계층이 필요합니다. |
| SEC 6: 컴퓨팅 리소스는 어떻게 보호하나요? |
| --- |
| 워크로드의 컴퓨팅 리소스를 외부 및 내부 위협으로부터 보호할 수 있는 다중 방어 계층이 필요합니다. 컴퓨팅 리소스에는 EC2 인스턴스, 컨테이너, AWS Lambda 함수, 데이터베이스 서비스, IoT 디바이스 등이 포함됩니다. |
어떤 환경이든 다중 방어 계층을 두는 것이 좋습니다. 인프라 보호의 경우 클라우드 및 온프레미스 모델을 망라하여 효과를 발휘하는 다양한 인프라 보호 개념과 방법이 있습니다. 경계 보호를 적용하고, 수신 및 송신 지점을 모니터링하고, 종합적인 로깅과 모니터링, 알림을 이용하는 것은 모두 효과적인 정보 보안 계획의 핵심 요소입니다.
AWS 고객은 Amazon Elastic Compute Cloud(Amazon EC2), Amazon Elastic Container Service(Amazon ECS) 컨테이너 또는 AWS Elastic Beanstalk 인스턴스의 구성을 맞춤 조정하거나 강화할 수 있고 변경 불가능한 Amazon Machine Image(AMI)로 이러한 구성을 유지할 수 있습니다. 이렇게 하면 Auto Scaling에 의한 시작되거나 수동으로 시작된 모든 경우에 이 AMI로 시작되는 모든 새 가상 서버(인스턴스)가 이 강화된 구성을 얻게 됩니다.
# 데이터 보호
시스템을 설계하려면 먼저 보안과 관련된 기본적인 관행부터 마련해야 합니다. 예를 들어 데이터 분류는 민감도에 따라 조직의 데이터를 구분하는 하나의 방법이고 암호화는 무단 액세스 사용자가 데이터를 해석하지 못하게 만들어 데이터를 보호하는 방법입니다. 이는 금전적 손해 방지 또는 규제 의무 준수 등 목표 달성을 뒷받침하는 중요한 도구이자 기법입니다.
AWS에서는 다음과 같은 관행으로 데이터 보호를 실현합니다.
+ AWS 고객은 데이터에 대한 완전한 통제력을 유지합니다.
+ AWS는 정기적인 키 교체 등 키 관리 및 데이터 암호화를 더 간편하게 처리하도록 만듭니다. AWS 서비스를 이용하거나 사용자가 직접 관리하여 손쉽게 자동화할 수 있습니다.
+ 파일 액세스, 변경 사항 등 중요한 콘텐츠가 수록된 상세 로그를 확인할 수 있습니다.
+ AWS는 탁월한 복원성을 목표로 스토리지 시스템을 설계했습니다. 예를 들어 Amazon S3 Standard, S3 Standard–IA, S3 One Zone-IA 및 Amazon Glacier는 지정된 기간에 객체에 대해 99.999999999%의 내구성을 제공할 수 있도록 설계되었습니다. 이 내구성은 연평균 0.000000001%의 객체 손실 수준으로 예측됩니다.
+ 광범위한 데이터 수명 주기 관리 프로세스에 포함될 수 있는 버전 관리는 우발적인 덮어쓰기나 삭제 및 그와 유사한 손해를 방지할 수 있습니다.
+ AWS는 절대로 지역 간 데이터 이동을 하지 않습니다. 특정 리전에 저장된 콘텐츠는 사용자가 명시적으로 기능을 활성화하거나 그 기능을 제공하는 서비스를 이용하지 않는 한 해당 리전을 벗어나지 않습니다.
다음은 보안 고려 사항에 중점을 둔 질문입니다.
| SEC 7: 데이터는 어떻게 분류하나요? |
| --- |
| 분류는 적절한 보호 및 보존 제어 수준을 결정하는 데 도움이 되도록 중요도와 민감도를 기준으로 데이터를 분류하는 방법을 제공합니다. |
| SEC 8: 저장 데이터는 어떻게 보호하나요? |
| --- |
| 여러 제어를 구현하여 무단 액세스 또는 처리 오류의 위험을 줄여 저장 데이터를 보호합니다. |
| SEC 9: 전송 중 데이터는 어떻게 보호하나요? |
| --- |
| 여러 제어를 구현하여 무단 액세스 또는 손실의 위험을 줄여 전송 중인 데이터를 보호합니다. |
AWS는 저장된 데이터 및 전송 중인 데이터를 암호화할 수 있는 여러 가지 수단을 제공합니다. 데이터를 암호화하기 쉽도록 서비스에 각종 기능을 내장했습니다. 예를 들어, Amazon S3에 대해 서버 측 암호화(SSE)를 구현하여 데이터를 암호화된 형태로 저장하기 쉽게 만들었습니다. 또한 흔히 SSL 종료라고 부르는 전체 HTTPS 암호화 및 복호화 프로세스를 Elastic Load Balancing(ELB)을 통해 처리하도록 설정할 수도 있습니다.
# 사고 대응
고도의 예방 및 탐지 제어를 사용하더라도 조직은 잠재적 보안 인시던트에 대응하고 그 영향을 완화하기 위한 프로세스를 마련해야 합니다. 워크로드의 아키텍처가 인시던트 발생 시 보안 팀이 효과적으로 시스템을 격리 또는 억제하고 운영을 알려진 정상 상태로 복구하는 능력에 지대한 영향을 미칩니다. 보안 인시던트보다 앞서 도구 및 액세스를 마련하고 게임 데이를 통해 인시던트 대응을 정기적으로 연습한다면 아키텍처가 적기에 조사 및 복구를 수용할 수 있게 할 수 있습니다.
AWS에서는 다음과 같은 관행으로 효과적인 인시던트 대응을 지원합니다.
+ 파일 액세스, 변경 사항 등 중요한 콘텐츠가 수록된 상세 로그를 확인할 수 있습니다.
+ 이벤트는 자동으로 처리될 수 있으며 AWS API를 사용하여 대응을 자동화하는 도구를 시작합니다.
+ AWS CloudFormation을 사용하여 도구 및 '클린 룸'을 사전 프로비저닝할 수 있습니다. 이를 통해 안전하고 격리된 환경에서 과학 수사를 진행할 수 있습니다.
다음은 보안 고려 사항에 중점을 둔 질문입니다.
| SEC 10: 인시던트를 어떻게 예상하고 대응하며 어떻게 사후 복구하나요? |
| --- |
| 조직의 업무 중단을 최소화할 수 있도록 보안 인시던트를 제때 효고적으로 조사 및 대응하고 사후 복구하려면 철저한 준비가 필요합니다. |
보안 팀에게 신속하게 액세스를 부여할 수 있는 절차를 마련하고 인스턴스 격리와 포렌식을 위해 데이터 및 상태 캡처를 자동화합니다.
# 애플리케이션 보안
애플리케이션 보안(AppSec)은 개발하는 워크로드의 보안 속성을 설계, 구축 및 테스트하는 전반적인 프로세스를 설명합니다. 조직에 적절한 교육을 받은 직원이 있어야 하며, 빌드 및 릴리스 인프라의 보안 속성을 이해하고, 자동화를 사용하여 보안 문제를 식별해야 합니다.
소프트웨어 개발 수명 주기(SDLC) 및 릴리스 후 프로세스에 정기적으로 애플리케이션 보안 테스트를 수행하면 프로덕션 환경에 유입되는 애플리케이션 보안 문제를 식별, 수정 및 방지할 수 있는 구조화된 메커니즘을 갖출 수 있습니다.
애플리케이션 개발 방법에는 워크로드를 설계, 구축, 배포 및 운영할 때의 보안 제어 기능이 포함되어야 합니다. 이와 동시에 지속적으로 결함을 줄이고 기술 부채를 최소화하도록 프로세스를 조정하세요. 예를 들어 설계 단계에서 위협 모델링을 사용하면 설계 결함을 조기에 발견할 수 있으므로 기다렸다가 나중에 문제를 완화하는 것보다 수정이 더 쉽고 비용이 적게 듭니다.
SDLC에서 결함은 보통 일찍 해결해야 비용과 복잡성이 줄어듭니다. 문제를 해결하는 가장 쉬운 방법은 애초에 문제가 발생하지 않게 하는 것입니다. 따라서 위협 모델로 시작하면 설계 단계부터 올바른 결과에 집중하는 데 도움이 됩니다. AppSec 프로그램이 발전을 거듭하면서 자동화를 사용하여 수행되는 테스트의 양을 늘리고, 빌더에 대한 피드백의 충실도를 개선하며, 보안 검토에 필요한 시간을 줄일 수 있습니다. 이러한 모든 작업은 구축하는 소프트웨어의 품질을 개선하고, 프로덕션에 기능을 도입하는 속도를 높입니다.
이 구현 지침은 조직 및 문화, 파이프라인 *자체* 보안, 파이프라인 *내부* 보안, 종속성 관리라는 네 가지 영역에 중점을 둡니다. 각 영역은 구현할 수 있는 일련의 원칙을 제공하며, 워크로드를 설계, 개발, 구축, 배포 및 운영하는 방법을 아우르는 전체적인 관점을 제공합니다.
AWS에는 애플리케이션 보안 프로그램을 다룰 때 사용할 수 있는 여러 방법이 있습니다. 이러한 접근 방식 중 일부는 기술에 의존하며, 일부는 애플리케이션 보안 프로그램의 인력 및 조직 측면에 중점을 두고 있습니다.
다음은 애플리케이션 보안 고려 사항에 중점을 둔 질문입니다.
| SEC 11: 설계, 개발 및 배포 수명 주기 전반에 걸쳐 애플리케이션의 보안 속성을 어떻게 통합하고 검증하나요? |
| --- |
| 인력 교육, 자동화를 사용한 테스트, 종속성 이해, 도구 및 애플리케이션의 보안 속성 검증은 프로덕션 워크로드에서 발생할 수 있는 보안 문제를 줄이는 데 도움이 됩니다. |
# 리소스
보안 관련 모범 사례에 대해 자세히 알아보려면 다음 리소스를 참조하세요.
## 설명서
+ [AWS 클라우드 보안](https://aws.amazon.com/security/?ref=wellarchitected-wp)
+ [AWS 규정 준수](https://aws.amazon.com/compliance/?ref=wellarchitected-wp)
+ [AWS 보안 블로그](http://blogs.aws.amazon.com/security/?ref=wellarchitected-wp)
+ [AWS Security Maturity Model](https://maturitymodel.security.aws.dev/en/0.-introduction/)
## 백서
+ [보안 요소](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html?ref=wellarchitected-wp)
+ [AWS Security Overview](https://d1.awsstatic.com/whitepapers/Security/AWS%20Security%20Whitepaper.pdf?ref=wellarchitected-wp)
+ [AWS Risk and Compliance](https://d1.awsstatic.com/whitepapers/compliance/AWS_Risk_and_Compliance_Whitepaper.pdf?ref=wellarchitected-wp)
## 비디오
+ [AWS 보안: 연방 정부](https://youtu.be/Wvyc-VEUOns?ref=wellarchitected-wp)
+ [Shared Responsibility Overview](https://www.youtube.com/watch?v=U632-ND7dKQ&ref=wellarchitected-wp)
# 신뢰성
신뢰성 원칙에서는 워크로드의 기능이 필요한 때에 기능을 정확하고 일관되게 수행하는 역량에 대해 다룹니다. 여기에는 전체 수명 주기에 걸쳐 워크로드를 운영 및 테스트할 수 있는 기능이 포함됩니다. 이 백서는 AWS에서 안정적인 워크로드를 구현하기 위한 세부적인 모범 사례 지침을 제공합니다.
신뢰성 원칙에서는 설계 원칙 개요, 모범 사례 및 질문 사항을 제공합니다. 구현에 대한 권장 가이드는 [신뢰성 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp)에서 확인할 수 있습니다.
**Topics**
+ [설계 원칙](rel-dp.md)
+ [정의](rel-def.md)
+ [모범 사례](rel-bp.md)
+ [리소스](rel-resources.md)
# 설계 원칙
클라우드에는 5가지 신뢰성 설계 원칙이 있습니다.
+ **장애 자동 복구:** 워크로드의 핵심 성과 지표(KPI) 모니터링을 통해 임곗값을 위반하면 자동화를 시작할 수 있습니다. 이러한 KPI는 서비스의 기술적 측면이 아닌 비즈니스 가치에 기반한 측정한 값이어야 합니다. KPI를 모니터링하면 장애 추적 및 자동 알림을 지원하고, 자동화된 복구 프로세스에 따라 장애 지점을 우회하거나 복구할 수 있습니다. 보다 정교한 자동화를 구현할 경우 장애가 발생하기 전에 예측하여 해결하는 것도 가능합니다.
+ **복구 절차 테스트:** 온프레미스 환경에서 테스트는 워크로드가 특정 시나리오에서 작동하는 것을 증명하기 위해 시행됩니다. 일반적으로 복구 전략을 검증하기 위해 테스트하지는 않습니다. 클라우드에서는 워크로드의 장애 과정을 테스트하고 복구 절차를 검증할 수 있습니다. 자동화를 사용하여 다양한 장애를 시뮬레이션하거나 이전에 장애로 이어졌던 시나리오를 재현할 수 있습니다. 이 접근 방식은 실제 장애 시나리오가 발생하기 전에 테스트하고 수정할 수 있는 장애 경로를 노출하여 위험을 줄여 줍니다.
+ **수평적 스케일링을 통해 전체 워크로드 가용성 증대:** 단일의 큰 리소스를 다수의 작은 리소스로 대체하여 단일 장애가 전체 워크로드에 미치는 영향을 축소합니다. 요청을 더 작은 리소스 여러 개로 분산시키면 공통의 장애 지점이 공유되지 않습니다.
+ **용량 추정 중지:** 워크로드에 대한 수요가 해당 워크로드의 용량을 넘어서는 리소스 부족 상태는 온프레미스 워크로드에서 흔히 발생하는 장애의 원인입니다(서비스 거부 공격의 대상). 클라우드에서는 수요 및 워크로드 사용량을 모니터링하고 리소스 추가 또는 제거를 자동화함으로써 프로비저닝 과다 또는 부족 현상 없이 보다 효율적인 수준으로 수요를 충족할 수 있습니다. 클라우드에도 제한은 있지만 할당량을 어느 정도 제어하고 관리하는 것이 가능합니다(Service Quotas 및 제약 조건 관리 참조).
+ **자동화를 통한 변경 관리**: 인프라 변경은 자동화를 통해 수행되어야 합니다. 관리가 필요한 변경에는 자동화 변경이 포함되며, 이후에 이러한 변경을 추적하고 검토할 수 있습니다.
# 정의
클라우드의 신뢰성에는 4가지 모범 사례 영역이 있습니다.
+ 기본
+ 워크로드 아키텍처
+ 변경 관리
+ 장애 관리
신뢰성을 달성하려면 기반부터 시작해야 합니다. 이러한 기반은 서비스 할당량과 네트워크 토폴로지로 워크로드를 수용하는 환경을 의미합니다. 분산 시스템의 워크로드 아키텍처는 장애를 예방하고 완화하도록 설계되어야 합니다. 워크로드는 수요 또는 요구 사항의 변경을 처리해야 하며, 장애를 감지하고 자동으로 복구되도록 설계되어야 합니다.
# 모범 사례
**Topics**
+ [기본](rel-found.md)
+ [워크로드 아키텍처](rel-workload-arch.md)
+ [변경 관리](rel-chg-mgmt.md)
+ [장애 관리](rel-failmgmt.md)
# 기본
기반에 관한 요구 사항은 그 범위가 단일 워크로드 또는 프로젝트 이상으로 확장됩니다. 시스템을 설계할 때는 먼저 신뢰성을 좌우하는 기반에 관한 요구 사항부터 갖춰야 합니다. 예를 들어, 데이터 센터의 네트워크 대역폭을 충분히 확보해야 합니다.
AWS에서는 이러한 기반에 관련된 요구 사항이 대부분 이미 통합되어 있거나 필요에 따라 적용할 수 있습니다. 클라우드는 거의 한계가 없도록 설계되었기 때문에 충분한 네트워킹 및 컴퓨팅 용량에 대한 요구 사항을 충족할 책임은 AWS에 있습니다. 따라서 고객은 리소스 크기와 할당을 필요에 따라 변경할 수 있습니다.
다음은 신뢰성 고려 사항에 중점을 둔 질문입니다. (신뢰성 질문 및 모범 사례 목록은 [부록](a-reliability.md)을 참조하세요.)
| REL 1: 서비스 할당량과 제약 조건은 어떻게 관리하나요? |
| --- |
| 클라우드 기반 워크로드 아키텍처에는 서비스 할당량(서비스 한도라고도 함)이 있습니다. 이러한 할당량은 실수로 필요한 것보다 많은 리소스를 프로비저닝하는 것을 방지하고 API 작업에 대한 요청 비율을 제한하여 서비스가 남용되지 않도록 하기 위해 존재합니다. 또한 리소스에도 제약이 따릅니다. 예를 들면, 광섬유 케이블을 통해 비트를 전송할 수 있는 속도나 물리적 디스크의 스토리지 용량 등이 있습니다. |
| REL 2: 네트워크 토폴로지는 어떻게 계획하나요? |
| --- |
| 워크로드는 여러 환경에 존재하는 경우가 많습니다. 여기에는 여러 클라우드 환경(퍼블릭 액세스 가능 및 프라이빗)과 기존 데이터 센터 인프라가 포함됩니다. 계획에는 시스템 내부 및 시스템 간 연결, 퍼블릭 IP 주소 관리, 프라이빗 IP 주소 관리 및 도메인 이름 확인과 같은 네트워크 고려 사항이 포함되어야 합니다. |
# 워크로드 아키텍처
신뢰할 수 있는 워크로드는 소프트웨어와 인프라에 대한 사전 설계 결정에서 시작됩니다. 아키텍처 선택은 모든 Well-Architected 원칙에서 워크로드 동작에 영향을 미칩니다. 신뢰성을 달성하려면 특정 패턴을 따라야 합니다.
AWS에서는 워크로드 개발자가 사용할 언어와 기술을 선택할 수 있습니다. AWS SDK는 AWS 서비스를 위한 언어별 API를 제공하여 코드 작성의 복잡성을 제거합니다. 이러한 SDK와 언어 선택을 통해 개발자는 여기에 나열된 신뢰성 모범 사례를 구현할 수 있습니다. 또한 개발자는 [Amazon Builders' Library](https://aws.amazon.com/builders-library/?ref=wellarchitected-wp)에서 Amazon의 소프트웨어 구축 및 운영 방법에 대해 자세히 알아볼 수 있습니다.
다음은 신뢰성 고려 사항에 중점을 둔 질문입니다.
| REL 3: 워크로드 서비스 아키텍처는 어떻게 설계하나요? |
| --- |
| 서비스 지향 아키텍처(SOA) 또는 마이크로서비스 아키텍처를 사용하여 확장성과 신뢰성이 뛰어난 워크로드를 구축합니다. 서비스 지향 아키텍처(SOA)는 서비스 인터페이스를 통해 소프트웨어 구성 요소를 재사용 가능하게 만드는 방식입니다. 마이크로서비스 아키텍처는 구성 요소를 더 작고 간단하게 만듭니다. |
| REL 4: 분산 시스템에서 장애 방지를 위한 상호 작용은 어떻게 설계하나요? |
| --- |
| 분산 시스템은 통신 네트워크를 사용하여 서버 또는 서비스와 같은 구성 요소를 상호 연결합니다. 이러한 네트워크에서 데이터 손실이나 지연 시간이 발생하더라도 워크로드는 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 이러한 모범 사례는 장애를 예방하고 평균 고장 간격(MTBF)을 개선합니다. |
| REL 5: 분산 시스템에서 장애 완화 또는 극복을 위한 상호 작용은 어떻게 설계하나요? |
| --- |
| 분산 시스템에서 구성 요소(예: 서버 또는 서비스)는 통신 네트워크를 사용하여 상호 연결됩니다. 워크로드는 이러한 네트워크에서 데이터 손실 또는 지연 시간이 발생하더라도 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 이러한 모범 사례를 준수하면 워크로드가 스트레스 또는 장애를 견디고, 더 빠르게 이를 복구하며, 이러한 장애의 영향을 완화할 수 있습니다. 그러면 결과적으로 평균 복구 시간(MTTR)이 개선됩니다. |
# 변경 관리
워크로드의 안정적인 운영을 위해서는 워크로드 또는 환경에 대한 변경을 예상하고 수용해야 합니다. 변경에는 수요 급증과 같이 워크로드에 적용되는 변경은 물론 기능 배포 및 보안 패치와 같은 워크로드 내부의 변경이 포함됩니다.
AWS를 사용하면 워크로드 동작을 모니터링하고 KPI에 대한 대응을 자동화할 수 있습니다. 예를 들어 워크로드의 사용자가 증가하면 워크로드 서버를 추가할 수 있습니다. 워크로드 변경 권한을 가진 사용자를 관리하고 이러한 변경 기록을 감사할 수 있습니다.
다음은 신뢰성 고려 사항에 중점을 둔 질문입니다.
| REL 6: 워크로드 리소스는 어떻게 모니터링하나요? |
| --- |
| 로그와 지표는 워크로드 상태를 파악할 수 있는 강력한 도구입니다. 로그와 지표를 모니터링하고 임계값을 초과하거나 중요한 이벤트가 발생할 경우 알림을 보내도록 워크로드를 구성할 수 있습니다. 모니터링을 수행하면 워크로드가 저성능 임곗값을 초과하거나 장애가 발생할 때를 인식하고 이에 대응하여 자동으로 복구할 수 있습니다. |
| REL 7: 수요 변경에 따라 조정되도록 워크로드를 설계하려면 어떻게 해야 하나요? |
| --- |
| 확장 가능한 워크로드는 리소스를 자동으로 추가 또는 제거할 수 있는 탄력성을 제공하여 리소스 공급이 특정 시점의 수요와 거의 일치하도록 합니다. |
| REL 8: 변경 사항은 어떻게 적용하나요? |
| --- |
| 새로운 기능을 배포하고 워크로드와 운영 환경에서 알려진 소프트웨어를 실행하고 예측 가능한 방식으로 패치 또는 교체할 수 있도록 하려면 변경 사항을 제어해야 합니다. 이러한 변경이 제어되지 않으면 변경의 영향을 예측하거나 변경으로 인해 발생하는 문제를 해결하는 것이 어려워집니다. |
수요 변화에 따라 리소스를 자동으로 추가하거나 제거하도록 워크로드를 설계하면 신뢰성이 향상될 뿐 아니라 비즈니스 성공의 가능성도 높아집니다. 모니터링을 통해 KPI가 통상적인 수준을 벗어나면 담당 팀에 자동으로 알려 줍니다. 환경에 대한 변경 사항이 자동으로 로깅되므로 신뢰성에 영향을 미칠 가능성이 있는 작업을 감사하여 신속하게 파악할 수 있습니다. 변경 관리 제어를 통해 규칙을 적용함으로써 필요한 수준의 신뢰성을 확보할 수 있습니다.
# 장애 관리
통상적인 수준의 복잡한 시스템에는 장애가 발생하기 마련입니다. 신뢰성을 유지하려면 워크로드에서 장애가 발생할 때 이를 인식하고 가용성에 미치는 영향을 방지하는 조치를 취해야 합니다. 워크로드는 장애를 견디는 동시에 문제를 자동으로 복구할 수 있어야 합니다.
AWS에서는 자동화를 활용하여 모니터링 데이터에 대응합니다. 예를 들어, 특정 지표가 임곗값을 넘어서면 자동화된 작업을 시작하여 문제를 해결할 수 있습니다. 또한 운영 환경에서 장애가 발생한 리소스를 진단하여 수정하는 대신, 일단 새 리소스로 대체한 다음 운영 환경이 아닌 외부에서 장애 리소스를 분석해 볼 수도 있습니다. 클라우드에서는 저렴한 비용으로 전체 시스템의 임시 버전을 설정할 수 있기 때문에 전체 복구 프로세스를 자동으로 테스트하는 것이 가능합니다.
다음은 신뢰성 고려 사항에 중점을 둔 질문입니다.
| REL 9: 데이터는 어떻게 백업하나요? |
| --- |
| 복구 시간 목표(RTO) 및 복구 지점 목표(RPO)에 대한 요구 사항을 충족하도록 데이터, 애플리케이션 및 구성을 백업합니다. |
| REL 10: 장애 격리를 사용하여 워크로드를 보호하려면 어떻게 해야 하나요? |
| --- |
| 장애 격리는 구성 요소 또는 시스템 장애의 영향을 정의된 경계로 제한합니다. 올바르게 격리하면 경계 외부의 구성 요소는 장애의 영향을 받지 않습니다. 여러 장애 격리 경계에서 워크로드를 실행하면 장애에 대한 복원력이 향상될 수 있습니다. |
| REL 11: 구성 요소 장애를 견디도록 워크로드를 설계하려면 어떻게 해야 하나요? |
| --- |
| 고가용성 및 낮은 평균 복구 시간(MTTR)이 요구되는 워크로드는 복원력을 고려하여 설계해야 합니다. |
| REL 12: 신뢰성은 어떻게 테스트하나요? |
| --- |
| 프로덕션 환경의 스트레스에 대한 복원력을 가지도록 워크로드를 설계한 후 설계대로 작동하고 예상한 복원력을 제공하는지 확인할 수 있는 유일한 방법은 테스트입니다. |
| REL 13: 재해 복구(DR)는 어떻게 계획하나요? |
| --- |
| DR 전략의 시작은 백업 및 이중화 워크로드 구성 요소를 갖추는 것입니다. [RTO 및 RPO](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)는 워크로드 복원을 위한 목표입니다. 비즈니스 요구 사항에 따라 이러한 목표를 설정합니다. 워크로드 리소스 및 데이터의 위치와 기능을 고려하여 이러한 목표를 충족하는 전략을 구현합니다. 중단 가능성과 복구 비용도 워크로드에 대한 재해 복구 옵션을 갖추는 것이 지니는 비즈니스 가치를 파악하는 데 도움이 되는 주요 요소입니다. |
정기적으로 데이터를 백업하고 백업 파일을 테스트하여 논리적 오류와 물리적 오류를 모두 복구할 수 있는지 확인합니다. 빈번한 워크로드 자동 테스트를 통해 장애 원인을 파악하고 복구 방식을 살펴보는 것이 장애 관리의 핵심입니다. 정기 일정에 따라 이 테스트를 수행하고, 중요한 워크로드 변경 이후에도 이 테스트가 시작되는지 확인해야 합니다. Recovery Time Objective(RTO), Recovery Point Objective(RPO) 및 KPI를 적극적으로 추적하여 특히 장애 테스트 시나리오 등에서 워크로드의 복원력을 평가합니다. KPI를 추적하면 단일 장애 지점을 파악 및 완화하는 데 도움이 됩니다. 목표는 워크로드 복구 프로세스를 철저히 테스트함으로써 모든 데이터를 복구할 수 있으며 문제가 지속되더라도 고객에게 계속 서비스를 제공할 수 있다는 확신을 얻는 것입니다. 통상적인 프로덕션 프로세스와 마찬가지로 복구 프로세스도 제대로 실행해야 합니다.
# 리소스
신뢰성 관련 모범 사례에 대해 자세히 알아보려면 다음 리소스를 참조하세요.
## 설명서
+ [AWS 설명서](https://docs.aws.amazon.com/index.html?ref=wellarchitected-wp)
+ [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure?ref=wellarchitected-wp)
+ [AWS Auto Scaling: How Scaling Plans Work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html?ref=wellarchitected-wp)
+ [AWS Backup란 무엇입니까?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html?ref=wellarchitected-wp)
## 백서
+ [신뢰성 원칙: AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp)
+ [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html?ref=wellarchitected-wp)
# 성능 효율성
성능 효율성 원칙에는 클라우드 리소스를 성능 요구 사항에 맞게 효율적으로 사용하고, 수요 변화 및 기술 진화에 발맞춰 그러한 효율성을 유지하는 능력이 포함됩니다.
성능 효율성 원칙에서 설계 원칙 개요, 모범 사례, 질문 사항을 제공합니다. 구현에 대한 권장 가이드는 [성능 효율성 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp)에서 확인할 수 있습니다.
**Topics**
+ [설계 원칙](perf-dp.md)
+ [정의](perf-def.md)
+ [모범 사례](perf-bp.md)
+ [리소스](perf-resources.md)
# 설계 원칙
클라우드에는 5가지 성능 효율성 설계 원칙이 있습니다.
+ **고급 기술의 대중화**: 팀에서 고급 기술을 원활하게 구현할 수 있도록 복잡한 작업을 클라우드 공급업체에 위임합니다. IT 팀에 새로운 기술의 호스팅 및 실행에 대해 알아볼 것을 요청하는 대신 기술을 서비스 형태로 사용하는 것을 고려하세요. 예를 들어 NoSQL 데이터베이스, 미디어 트랜스코딩 및 기계 학습은 모두 전문 지식이 요구되는 기술입니다. 클라우드에서는 이러한 기술이 팀에서 사용할 수 있는 서비스 형식으로 제공되므로 팀은 리소스 프로비저닝과 관리가 아닌 제품 개발에 집중할 수 있습니다.
+ **몇 분 안에 전 세계에 배포**: 전 세계의 여러 AWS 리전에 워크로드를 배포하면 최소한의 비용으로 지연 시간을 줄이고 고객 경험을 개선할 수 있습니다.
+ **서버리스 아키텍처 사용**: 서버리스 아키텍처에서는 물리적 서버를 실행하고 유지 관리하지 않고도 기존의 컴퓨팅 활동을 수행할 수 있습니다. 예를 들어 서버리스 스토리지 서비스를 정적 웹 사이트로 사용하고(웹 서버 불필요) 이벤트 서비스를 통해 코드를 호스팅할 수 있습니다. 이렇게 하면 물리적 서버 관리로 인한 운영 부담이 없어집니다. 또한 이러한 관리형 서비스는 클라우드 규모에서 운영되므로 트랜잭션 비용을 절감할 수 있습니다.
+ **테스트 횟수 증가**: 자동화할 수 있는 가상 리소스를 활용하며 여러 가지 인스턴스, 스토리지 또는 구성에 대한 비교 테스트를 신속하게 수행할 수 있습니다.
+ **기계에 대한 공감 고려**: 클라우드 서비스가 어떻게 사용되는지 파악하고 항상 워크로드 목표에 부합하는 기술 접근 방식을 사용합니다. 예를 들어 데이터베이스 또는 스토리지 접근 방식을 선택할 때는 데이터 접근 패턴을 고려합니다.
# 정의
클라우드의 성능 효율성에는 5가지 모범 사례 영역이 있습니다.
+ **아키텍처 선택**
+ **컴퓨팅 및 하드웨어**
+ **데이터 관리**
+ **네트워킹 및 콘텐츠 전송**
+ **프로세스 및 문화**
고성능 아키텍처를 구축할 때는 데이터 기반 접근 방식을 취합니다. 개괄적 설계부터 리소스 유형 선택과 구성에 이르는 아키텍처의 모든 측면에 대한 데이터를 수집합니다.
정기적으로 선택 사항을 검토하면서 진화를 거듭하는 AWS 클라우드를 최대한 활용할 수 있습니다. 모니터링을 수행하면 예상 성능과의 차이를 확인할 수 있습니다. 압축 또는 캐싱을 사용하거나 일관성 요구 사항을 완화하는 등의 성능 개선을 위해 아키텍처에서 절충안을 구성합니다.
# 모범 사례
**Topics**
+ [아키텍처 선택](perf-arch.md)
+ [컴퓨팅 및 하드웨어](perf-compute.md)
+ [데이터 관리](perf-data.md)
+ [네트워킹 및 콘텐츠 전송](perf-networking.md)
+ [프로세스 및 문화](perf-process.md)
# 아키텍처 선택
특정 워크로드에 대한 최적의 솔루션은 다양하며, 종종 여러 접근 방식이 결합된 솔루션을 사용합니다. Well-Architected 워크로드의 경우 다수의 솔루션이 사용되며 다양한 특성을 사용하여 성능을 높일 수 있습니다.
AWS 리소스는 다양한 유형과 구성으로 제공되므로, 요구 사항에 가장 근접한 접근 방식을 쉽게 찾을 수 있습니다. 또한 온프레미스 인프라에서는 쉽게 사용할 수 없는 옵션도 제공됩니다. 예를 들어 Amazon DynamoDB와 같은 관리형 서비스는 완전관리형 NoSQL 데이터베이스로, 어떤 규모에서도 지연 시간이 한 자릿수 밀리초 단위로 매우 짧습니다.
다음은 성능 효율성 고려 사항에 중점을 둔 질문입니다. (성능 효율성 질문 및 모범 사례 목록은 [부록](a-performance-efficiency.md)을 참조하세요.)
| PERF 1: 워크로드에 적합한 클라우드 리소스 및 아키텍처를 어떻게 선택하나요? |
| --- |
| 워크로드에서 보다 효과적인 성능을 얻으려면 종종 여러 접근 방식을 취해야 합니다. Well-Architected 시스템은 다수의 솔루션 및 기능을 사용하여 성능을 개선합니다. |
# 컴퓨팅 및 하드웨어
특정 워크로드에 대한 최적의 컴퓨팅 선택은 애플리케이션 설계, 사용량 패턴 및 구성 설정에 따라 다를 수 있습니다. 아키텍처는 다양한 컴포넌트에 대해 서로 다른 컴퓨팅 옵션을 사용하고 다양한 기능을 활성화하여 성능을 개선할 수 있습니다. 아키텍처에 대해 잘못된 컴퓨팅 옵션을 선택하면 성능 효율성 저하로 이어질 수 있습니다.
AWS에서는 3가지 형식의 컴퓨팅 기능(인스턴스, 컨테이너, 함수)이 제공됩니다.
+ **인스턴스**는 가상화된 서버이기 때문에 버튼을 누르거나 API를 호출하는 방법으로 기능을 변경할 수 있습니다. 클라우드에서는 리소스를 한번 결정하면 그대로 고정되는 것이 아니므로 다양한 서버 유형을 시험해 볼 수 있습니다. AWS에서는 이러한 가상 서버 인스턴스를 다양한 제품군과 규모로 제공하며, 솔리드 스테이트 드라이브(SSD)와 그래픽 처리 장치(GPU)를 비롯한 폭넓은 기능을 제공합니다.
+ **컨테이너**는 애플리케이션 및 종속성을 리소스가 격리된 프로세스에서 실행할 수 있는 운영 체제 가상화 방식입니다. AWS Fargate는 컨테이너용 서버리스 컴퓨팅입니다. 컴퓨팅 환경의 설치, 구성 및 관리를 제어해야 한다면 Amazon EC2를 사용할 수 있습니다. Amazon Elastic Container Service(ECS) 또는 Amazon Elastic Kubernetes Service(EKS)와 같은 다수의 컨테이너 오케스트레이션 플랫폼 중에서 선택할 수도 있습니다.
+ **함수**는 실행하려는 코드에서 실행 환경을 추상화합니다. 예를 들어, AWS Lambda에서는 인스턴스를 실행하지 않고 코드를 실행할 수 있습니다.
다음은 성능 효율성 고려 사항에 중점을 둔 질문입니다.
| PERF 2: 워크로드에서 컴퓨팅 리소스를 선택하고 사용하는 방법은 무엇인가요? |
| --- |
| 워크로드에 보다 효율적인 컴퓨팅 솔루션은 애플리케이션 설계, 사용량 패턴 및 구성 설정에 따라 다릅니다. 아키텍처는 다양한 구성 요소에 대해 서로 다른 컴퓨팅 솔루션을 사용하고 다양한 기능을 설정하여 성능을 개선할 수 있습니다. 아키텍처에 대해 잘못된 컴퓨팅 솔루션을 선택하면 성능 효율성 저하로 이어질 수 있습니다. |
# 데이터 관리
특정 시스템에 대한 최적의 스토리지 솔루션은 데이터 유형의 종류(블록, 파일, 객체), 액세스 패턴(랜덤 또는 순차), 필요한 처리량, 액세스 빈도(온라인, 오프라인, 아카이브), 업데이트 빈도(WORM, 동적) 및 가용성과 내구성 제약 사항에 따라 다릅니다. Well-Architected 워크로드는 용도에 맞게 구축된 데이터 저장소를 사용하므로 다양한 기능을 통해 성능을 개선할 수 있습니다.
AWS에서 스토리지는 객체, 블록, 파일이라는 3가지 형태로 제공됩니다.
+ **객체 스토리지**는 모든 인터넷 위치에서 사용자가 생성한 콘텐츠, 활성 아카이브, 서버리스 컴퓨팅, 빅 데이터 스토리지 또는 백업 및 복구를 위한 데이터에 액세스할 수 있게 하는 확장 가능하고 내구성이 뛰어난 플랫폼을 제공합니다. Amazon Simple Storage Service(Amazon S3)는 업계 최고의 확장성, 데이터 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스입니다. Amazon S3는 99.999999999%의 내구성을 제공하도록 설계되었으며 전 세계 회사를 위한 수백만 개의 애플리케이션에 대한 데이터를 저장합니다.
+ **블록 스토리지**는 일관되고 지연 시간이 짧은 고가용성 블록 스토리지를 각 가상 호스트에 제공하며, Direct-Attached Storage(DAS) 또는 Storage Area Network(SAN)와 유사합니다. Amazon Elastic Block Store(Amazon EBS)는 EC2 인스턴스에서 영구 스토리지에 액세스할 수 있어야 하는 워크로드를 위해 설계되었으며, 적절한 스토리지 용량, 성능 및 비용으로 애플리케이션을 튜닝하는 데 도움이 됩니다.
+ **파일 스토리지**를 사용하면 여러 시스템에서 공유 파일 시스템에 액세스할 수 있습니다. Amazon Elastic File System(Amazon EFS)과 같은 파일 스토리지 솔루션은 대용량 콘텐츠 리포지토리, 개발 환경, 미디어 스토어 또는 사용자 홈 디렉터리와 같은 사용 사례에 적합합니다. Amazon FSx를 사용하면 주요 파일 시스템을 비용 효율적으로, 능률적으로 시작하고 실행할 수 있으므로 널리 사용되는 오픈 소스 및 상용 라이선스 파일 시스템의 풍부한 기능 세트와 빠른 성능을 활용할 수 있습니다.
다음은 성능 효율성 고려 사항에 중점을 둔 질문입니다.
| PERF 3: 워크로드의 데이터를 어떻게 저장, 관리, 액세스하나요? |
| --- |
| 시스템에 대한 보다 효율적인 스토리지 솔루션은 액세스 작업 종류(블록, 파일, 객체), 액세스 패턴(랜덤 또는 순차), 필요한 처리량, 액세스 빈도(온라인, 오프라인, 보관), 업데이트 빈도(WORM, 동적), 가용성과 내구성 제약 사항에 따라 다릅니다. Well-Architected 시스템은 여러 스토리지 솔루션을 사용하며 다양한 기능을 설정하여 성능을 개선하고 리소스를 효율적으로 사용합니다. |
# 네트워킹 및 콘텐츠 전송
워크로드에 대한 최적의 네트워킹 솔루션은 지연 시간, 처리량 요구 사항, 지터, 대역폭에 따라 다릅니다. 위치 옵션은 사용자 또는 온프레미스 리소스와 같은 물리적 제약에 따라 결정됩니다. 엣지 로케이션 또는 리소스 배치를 통해 이러한 제약을 상쇄할 수 있습니다.
AWS에서 네트워킹은 가상화되고 다양한 유형 및 구성으로 제공됩니다. 따라서 네트워킹 요구 사항에 보다 쉽게 부합할 수 있습니다. AWS에서는 제품 기능(예: 강화된 네트워킹, Amazon EC2 네트워킹 최적화 인스턴스, Amazon S3 Transfer Acceleration, 동적 Amazon CloudFront)을 제공하여 네트워크 트래픽을 최적화합니다. 또한 AWS Global Accelerator에서는 네트워킹 기능(예: Amazon Route 53 지연 속도 기반 라우팅, Amazon VPC 엔드포인트, AWS, AWS Direct Connect)도 제공하여 네트워크 거리 또는 지터를 줄입니다.
다음은 성능 효율성 고려 사항에 중점을 둔 질문입니다.
| PERF 4: 워크로드에서 네트워킹 리소스를 어떻게 선택하고 구성하나요? |
| --- |
| 이 질문에는 클라우드에서 효율적인 네트워킹 및 콘텐츠 전송 솔루션을 설계, 구성 및 운영하기 위한 지침과 모범 사례가 포함됩니다. |
# 프로세스 및 문화
워크로드를 설계할 때는 효율적인 고성능 클라우드 워크로드를 더 잘 실행하는 데 도움이 되도록 채택할 수 있는 원칙과 관행이 있습니다. 클라우드 워크로드의 성능 효율성을 촉진하는 문화를 도입하려면 다음과 같은 주요 원칙과 관행을 고려하세요.
이러한 문화를 구축하기 위해 다음과 같은 핵심 원칙을 고려하세요.
+ **코드형 인프라:** AWS CloudFormation 템플릿 등의 접근 방식을 사용하여 코드형 인프라를 정의합니다. 템플릿을 사용하면 애플리케이션 코드와 구성과 함께 인프라를 소스 제어에 포함할 수 있습니다. 이렇게 하면 소프트웨어를 개발하는 데 사용하는 것과 동일한 사례를 인프라에 적용할 수 있으므로 검토를 빠르게 반복할 수 있습니다.
+ **배포 파이프라인:** 소스 코드 리포지토리, 빌드 시스템, 배포, 테스트 자동화 등의 지속적 통합 및 지속적 전달(CI/CD) 파이프라인을 사용하여 인프라를 배포합니다. 이렇게 하면 반복 가능하며 일관성 있는 저렴한 방식으로 배포를 반복해서 진행할 수 있습니다.
+ **잘 정의된 지표:** 핵심 성과 지표(KPI)를 캡처하기 위해 지표를 설정하고 모니터링합니다. 기술과 비즈니스 지표를 모두 사용하는 것이 좋습니다. 웹 사이트 또는 모바일 앱의 경우 주요 지표는 첫 번째 바이트가 수신되거나 첫 번째 렌더링이 완료될 때까지의 시간을 측정합니다. 그 외에 일반적으로 적용되는 지표에는 스레드 수, 가비지 수집 속도, 대기 상태 등이 있습니다. 요청당 누적 비용 집계액 등의 비즈니스 지표에서는 비용 절감 방법을 파악할 수 있습니다. 지표를 해석할 방법을 신중하게 고려합니다. 예를 들어 평균이 아닌 최대값이나 99번째 백분위수를 선택할 수 있습니다.
+ **자동 성능 테스트:** 배포 프로세스의 일환으로 더 빠르게 실행되는 테스트가 정상적으로 완료되고 나면 성능 테스트를 자동으로 시작합니다. 이 자동 테스트에서는 새 환경을 설정하고, 테스트 데이터 등의 초기 조건을 설정한 다음 일련의 벤치마크와 로드 테스트를 실행해야 합니다. 시간별 성능 변화를 추적할 수 있도록 이러한 테스트의 결과를 빌드에 다시 연결해야 합니다. 오래 실행되는 테스트의 경우에는 테스트를 빌드의 다른 부분과 비동기식으로 파이프라인에 포함할 수 있습니다. Amazon EC2 스팟 인스턴스를 사용하여 야간에 성능을 테스트할 수도 있습니다.
+ **로드 생성:** 가상 또는 사전 녹화 방식의 사용자 여정을 복제하는 일련의 테스트 스크립트를 생성해야 합니다. 이러한 스크립트는 항상 동일한 결과를 반환하고 결합되지 않아야 합니다. 유효한 결과를 얻기 위해 *사전 준비* 스크립트를 포함해야 할 수도 있습니다. 따라서 스크립트를 최대한 많이 테스트하여 프로덕션 환경의 사용 동작을 복제하는 것이 좋습니다. 소프트웨어 또는 서비스형 소프트웨어(SaaS) 솔루션을 사용하여 로드를 생성할 수 있습니다. 비용 효율적인 방식으로 로드를 생성할 수 있도록 [AWS Marketplace](https://aws.amazon.com/marketplace/) 솔루션 및 [스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)를 사용하는 방법을 고려하세요.
+ **성능 확인:** 팀이 주요 지표(특히 각 빌드 버전 관련 지표)를 확인할 수 있도록 제공해야 합니다. 이렇게 하면 시간 경과에 따른 긍정적이거나 부정적인 주요 추세를 확인할 수 있습니다. 또한 오류나 예외 수 관련 지표도 표시하여 작동 중인 시스템을 테스트하고 있는지를 확인해야 합니다.
+ **시각화:** 성능 문제, 핫스팟, 대기 상태, 낮은 사용률 등이 확인되는 위치를 명확하게 표시하는 시각화 기술을 사용합니다. 아키텍처 다이어그램 위에 성과 지표를 겹쳐서 표시합니다. 콜 그래프나 코드는 문제를 빠르게 확인하는 데 도움을 줍니다.
+ **정기적인 검토 프로세스:** 아키텍처의 성능 저하는 성능 검토 프로세스가 없거나 효과적이지 않은 경우 주로 발생합니다. 아키텍처의 성능이 좋지 않은 경우 성능 검토 프로세스를 구현하면 반복적으로 개선을 주도할 수 있습니다.
+ **지속적 최적화:** 클라우드 워크로드의 성능 효율성을 지속적으로 최적화할 수 있는 문화를 채택합니다.
다음은 성능 효율성 고려 사항에 중점을 둔 질문입니다.
| PERF 5: 워크로드의 성능 효율성을 높이기 위해 어떤 프로세스를 사용하나요? |
| --- |
| 워크로드를 설계할 때는 효율적인 고성능 클라우드 워크로드를 더 잘 실행하는 데 도움이 되도록 채택할 수 있는 원칙과 관행이 있습니다. 클라우드 워크로드의 성능 효율성을 촉진하는 문화를 도입하려면 다음과 같은 주요 원칙과 관행을 고려하세요. |
# 리소스
성능 효율성 관련 모범 사례에 대해 자세히 알아보려면 다음 리소스를 참조하세요.
## 설명서
+ [Amazon S3 성능 최적화](https://docs.aws.amazon.com/AmazonS3/latest/dev/PerformanceOptimization.html?ref=wellarchitected-wp)
+ [Amazon EBS 볼륨 성능](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html?ref=wellarchitected-wp)
## 백서
+ [성능 효율성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp)
## 비디오
+ [AWS re:Invent 2019: Amazon EC2 foundations (CMP211-R2)](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Leadership session: Storage state of the union (STG201-L)](https://www.youtube.com/watch?v=39vAsGi6eEI&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Leadership session: AWS purpose-built databases (DAT209-L)](https://www.youtube.com/watch?v=q81TVuV5u28&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Connectivity to AWS and hybrid AWS network architectures (NET317-R1)](https://www.youtube.com/watch?v=eqW6CPb58gs&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Powering next-gen Amazon EC2: Deep dive into the Nitro system (CMP303-R2)](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Scaling up to your first 10 million users (ARC211-R)](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected-wp)
# 비용 최적화
비용 최적화 원칙은 시스템을 실행하여 최저 가격으로 비즈니스 가치를 제공할 수 있는 역량을 포함합니다.
비용 최적화 원칙에서는 설계 원칙 개요, 모범 사례 및 질문 사항을 제공합니다. 구현에 대한 권장 가이드는 [비용 최적화 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html?ref=wellarchitected-wp)에서 확인할 수 있습니다.
**Topics**
+ [설계 원칙](cost-dp.md)
+ [정의](cost-def.md)
+ [모범 사례](cost-bp.md)
+ [리소스](cost-resources.md)
# 설계 원칙
클라우드에는 5가지 비용 최적화 설계 원칙이 있습니다.
+ **클라우드 재무 관리 구현:** 클라우드에서 재무적 성공을 달성하고 비즈니스 가치 실현을 앞당기려면 클라우드 재무 관리 및 비용 최적화에 투자합니다. 조직이 이 새로운 기술 및 사용 관리 영역에서 역량을 쌓기 위해서는 시간과 리소스를 할애해야 합니다. 보안 또는 운영 우수성 역량과 마찬가지로 지식 강화, 프로그램, 리소스 및 프로세스를 통해 역량을 쌓아 비용 효율적인 조직이 되어야 합니다.
+ **소비 모델 도입**: 정교한 예측 기능을 사용할 필요 없이, 필요한 컴퓨팅 리소스에만 비용을 지불하고 비즈니스 요구 사항에 따라 사용량을 늘리거나 줄입니다. 예를 들어 개발 및 테스트 환경은 주로 주중 근무일에 하루 8시간 동안만 사용됩니다. 사용되지 않는 동안 이러한 리소스를 중단하여 잠재적으로 75%의 비용을 절감할 수 있습니다(40시간과 168시간의 차이).
+ **전반적인 효율성 측정**: 워크로드의 비즈니스 결과와 워크로드 제공과 관련된 비용을 측정합니다. 이렇게 측정하여 성과 개선과 비용 절감으로 얻을 수 있는 이익을 확인하시기 바랍니다.
+ **획일적인 업무 부담에 대한 비용 지출 중단**: 랙 및 스택 설치와 서버 전원 공급 등 데이터 센터 운영의 힘든 작업을 AWS가 처리합니다. 또한 관리형 서비스를 통해 운영 체제 및 애플리케이션을 관리하는 운영 부담을 덜어줍니다. 따라서 IT 인프라가 아니라 고객과 비즈니스 프로젝트에 집중할 수 있습니다.
+ **지출 분석 및 기여도 확인**: 클라우드를 사용하면 손쉽게 시스템의 사용량과 비용을 정확하게 식별할 수 있어 개별 워크로드 소유자의 IT 비용 기여도를 투명하게 확인할 수 있습니다. 그 결과 투자 대비 수익률(ROI)을 측정할 수 있어 워크로드 소유자에게는 리소스를 최적화하고 비용을 절감하는 기회가 됩니다.
# 정의
클라우드의 비용 최적화에는 5가지 모범 사례 영역이 있습니다.
+ **클라우드 재무 관리 시행**
+ **지출 및 사용량 인식**
+ **비용 효율적인 리소스**
+ **수요 관리 및 리소스 공급**
+ **시간 경과에 따른 최적화**
Well-Architected 프레임워크의 다른 원칙과 마찬가지로 비교 분석을 통해 하나를 선택해야 합니다. 예를 들어 출시 시간에 최적화할지 아니면 비용에 최적화할지 선택합니다. 경우에 따라서는 선결제 비용 최적화에 투자하는 것보다 출시 시간을 단축하거나, 새로운 기능을 배포하거나, 단순히 납기를 준수하는 등 속도를 기준으로 최적화하는 것이 가장 좋습니다. 데이터를 고려하지 않고 급하게 설계 결정이 내려지는 경우도 있으며, 가장 비용 최적화된 구축 벤치마킹에 시간을 쓰기보다 '만약을 대비해' 과잉 지출을 하려는 유혹은 항상 존재합니다. 이러한 경우에는 배포가 과다하게 프로비저닝되고 제대로 최적화되지 않을 수 있습니다. 그러나 온프레미스 환경의 리소스를 클라우드로 '리프트 앤 시프트'한 후 최적화해야 하는 경우에는 이 선택이 적합합니다. 사전에 비용 최적화 전략에 적당한 노력을 들여 모범 사례를 일관적으로 준수하고 불필요한 오버프로비저닝을 방지하면 클라우드의 경제적 이점을 더 빨리 실현할 수 있습니다. 다음 섹션에서는 클라우드 재무 관리의 초기 및 지속적인 구현과 워크로드의 비용 최적화를 위한 기술과 모범 사례를 제공합니다.
# 모범 사례
**Topics**
+ [클라우드 재무 관리 시행](cost-cfm.md)
+ [지출 및 사용량 인식](cost-aware.md)
+ [비용 효율적인 리소스](cost-cereso.md)
+ [수요 관리 및 리소스 공급](cost-mandem.md)
+ [시간 경과에 따른 최적화](cost-opti.md)
# 클라우드 재무 관리 시행
클라우드가 도입됨에 따라 기술 팀은 승인, 조달 및 인프라 배포 주기 단축으로 더 빠르게 혁신합니다. 비즈니스 가치를 실현하고 재정적 성공을 거두려면 클라우드에서의 재무 관리에 대한 새로운 접근 방식이 필요합니다. 이 접근 방식은 클라우드 재무 관리이며 조직 전반에 걸친 지식 구축, 프로그램, 리소스 및 프로세스를 구현하여 조직 전체의 역량을 강화합니다.
많은 조직은 서로 다른 우선순위가 지정된 여러 단위로 구성됩니다. 합의를 통해 정한 일련의 재무 목표에 따라 조직을 조정하고 목표 달성을 위한 메커니즘을 조직에 제공할 수 있으면 조직의 효율성이 향상됩니다. 역량 있는 조직은 더 빠르게 구축하고 혁신하며, 더 민첩하게 대응하고, 내부 또는 외부 요인에 적응합니다.
AWS에서 비용 및 사용 보고서(CUR)와 함께 Cost Explorer와 Amazon Athena 및 Amazon QuickSight(선택 사항)를 사용하여 비용과 사용량에 대한 조직 전체의 인식을 높일 수 있습니다. AWS 예산에서는 비용과 사용량에 대한 사전 알림을 제공합니다. AWS 블로그는 새로운 서비스 릴리스를 숙지할 수 있도록 신규 서비스와 기능에 대한 정보를 제공합니다.
다음은 비용 최적화 고려 사항에 중점을 둔 질문입니다. (비용 최적화 질문 및 모범 사례 목록은 [부록](a-cost-optimization.md)을 참조하세요.)
| COST 1: 클라우드 재무 관리를 어떻게 구현하나요? |
| --- |
| 조직은 클라우드 재무 관리를 시행하여 비용과 사용량을 최적화하고 AWS에서 규모를 확대하면서 비즈니스 가치를 실현하고 재정적 성공을 거둘 수 있습니다. |
비용 최적화 역할을 구성할 때는 팀원을 활용하고 CFM 및 비용 최적화의 전문가로 팀을 보완합니다. 기존 팀원들은 조직이 현재 어떻게 작용하며 어떻게 개선 사항을 신속하게 실행하는지 알게 됩니다. 또한 분석 및 프로젝트 관리와 같은 보조 또는 전문 기술을 보유한 인력 투입도 고려합니다.
조직에서 비용에 대한 인식을 이행할 때는 기존 프로그램과 프로세스를 바탕으로 개선하거나 구축합니다. 새로 구축하는 것보다 기존 프로세스와 프로그램에 추가하는 것이 훨씬 더 빠릅니다. 이를 통해 훨씬 더 빠르게 성과를 올릴 수 있습니다.
# 지출 및 사용량 인식
클라우드에서는 향상된 유연성과 민첩성을 바탕으로 혁신을 촉진하고 개발 및 배포를 가속화할 수 있습니다. 이는 하드웨어 사양을 식별하고, 가격 견적을 협상하며, 주문 번호를 관리하고, 배송을 예약한 후 리소스를 배포하는 등의 온프레미스 인프라 프로비저닝과 연관된 시간 및 수동 프로세스를 줄입니다. 하지만 사용이 편리하고 온디맨드 용량이 사실상 무제한으로 제공되면 지출을 새로운 방식으로 고려해야 합니다.
많은 비즈니스는 다양한 팀에서 운영하는 여러 시스템으로 구성되어 있습니다. 개별 조직 또는 제품 소유자에게 리소스 비용을 부여하는 기능은 효율적인 사용 행동 양식으로 이어지고 낭비되는 요소를 줄여줍니다. 또한 정확한 비용 기여도를 통해 수익성 높은 제품을 파악하고 예산을 어디에 할당할지에 대해 더 근거 있는 결정을 내릴 수 있습니다.
AWS에서는 AWS Organizations 또는 AWS Control Tower를 사용하여 계정 구조를 만듭니다. 이를 통해 비용과 사용량의 분리와 할당이 가능합니다. 리소스 태그 지정을 사용하여 사용량과 비용에 비즈니스 및 조직 정보를 적용할 수도 있습니다. AWS Cost Explorer를 사용하여 비용과 사용량을 파악하거나 Amazon Athena와 Amazon QuickSight로 사용자 지정 대시보드 및 분석을 만들 수 있습니다. 비용 및 사용량 제어는 AWS Budgets를 통한 알림과 AWS Identity and Access Management(IAM) 및 Service Quotas를 사용한 제어 기능을 통해 이루어집니다.
다음은 비용 최적화 고려 사항에 중점을 둔 질문입니다.
| COST 2: 사용량을 어떻게 관리하나요? |
| --- |
| 목표 달성 과정에서 발생하는 비용을 적정 수준으로 유지하는 정책과 메커니즘을 설정합니다. 견제와 균형 방식을 도입하면 비용을 과도하게 지출하지 않고 혁신을 이룰 수 있습니다. |
| COST 3: 비용과 사용량을 어떻게 모니터링하나요? |
| --- |
| 비용을 모니터링하고 적절하게 할당하기 위한 정책 및 절차를 구성합니다. 이렇게 하면 이 워크로드의 비용 효율성을 측정하고 개선할 수 있습니다. |
| COST 4: 리소스를 어떻게 폐기하나요? |
| --- |
| 프로젝트 시작부터 마지막까지의 전체 과정에서 변경 제어 및 리소스 관리를 구현합니다. 이를 통해 미사용 리소스를 차단하여 낭비를 줄일 수 있습니다. |
비용 할당 태그를 사용하여 AWS 사용량과 비용을 분류하고 추적할 수 있습니다. AWS 리소스(예: EC2 인스턴스 또는 S3 버킷)에 태그를 적용할 경우 AWS는 사용량과 태그가 포함된 비용 및 사용량 보고서를 생성합니다. 조직 카테고리(예: 비용 센터, 워크로드 이름 또는 소유자)를 나타내는 태그를 적용하여 여러 서비스 전반에서 비용을 조직화할 수 있습니다.
비용과 사용량 보고 및 모니터링에서 적절한 수준의 세부 정보와 세분화를 사용해야 합니다. 개략적인 인사이트와 추세를 위해서는 AWS Cost Explorer에서 일 단위의 세부 수준을 사용합니다. 심층적인 분석과 검사를 위해서는 시간 단위의 CUR(비용 및 사용 보고서)과 함께 AWS Cost Explorer 또는 Amazon Athena와 Amazon Quick에서 시간 단위의 세부 수준을 사용합니다.
태그가 지정된 리소스와 엔터티 수명 주기 추적(직원, 프로젝트)을 결합하면 조직에 더 이상 가치를 제공하지 않아 폐기해야 할 고립된 리소스나 프로젝트를 식별할 수 있습니다. 예상되는 초과 지출에 대한 통지를 받도록 결제 알림을 설정할 수 있습니다.
# 비용 효율적인 리소스
워크로드에 적합한 인스턴스와 리소스 사용은 비용 절감의 핵심입니다. 예를 들어 보고 프로세스에서 보다 작은 서버를 운영하는 데는 5시간이 걸리지만 2배로 비싼 더 큰 서버를 운영하는 데는 1시간이 걸릴 수 있습니다. 두 서버가 모두 동일한 결과를 내지만 보다 작은 서버는 시간에 따라 더 높은 비용이 발생합니다.
잘 설계된 워크로드는 상당히 긍정적인 비용적 영향을 미칠 수 있는 가장 비용 효율적인 리소스를 사용합니다. 또한 관리형 서비스를 사용하여 비용을 절감할 기회도 얻게 됩니다. 예를 들어 이메일을 전송하는 서버를 유지 관리하는 것 외에 메시지당을 기준으로 부과되는 서비스를 사용할 수 있습니다.
AWS는 요구 사항을 가장 효과적으로 충족하는 Amazon EC2 및 다른 서비스의 인스턴스를 획득하도록 유연하고 비용 효율적인 요금 옵션을 매우 다양하게 제공합니다. *온디맨드* *인스턴스*의 경우 최소 약정이 없으며 시간 단위로 컴퓨팅 파워 비용을 지불합니다. *절감형 플랜 및 예약형 인스턴스*는 온디맨드 요금에 비해 최대 75% 할인된 요금을 제공합니다. 스팟 인스턴스를 사용하면 미사용 Amazon EC2 용량을 활용할 수 있으며 온디맨드 요금보다 최대 90% 할인된 요금을 제공합니다. *스팟 인스턴스*는 시스템이 상태 비저장 웹 서버, 일괄 처리 또는 HPC 및 빅 데이터를 사용하는 경우 등 개별 서버가 동적으로 오고갈 수 있는 서버 플릿 사용을 용인할 수 있는 데에 적합합니다.
적합한 서비스 선택으로 사용량 및 비용도 절감할 수 있습니다. 예를 들어, CloudFront를 사용하면 데이터 전송을 최소화하거나 소모 비용을 줄일 수 있으며, Amazon Aurora on Amazon RDS를 활용하면 값비싼 데이터베이스 라이선싱 비용을 해소할 수 있습니다.
다음은 비용 최적화 고려 사항에 중점을 둔 질문입니다.
| COST 5: 서비스를 선택할 때 비용을 어떻게 평가하나요? |
| --- |
| Amazon EC2, Amazon EBS 및 Amazon S3는 기본 구성 AWS 서비스입니다. Amazon RDS 및 Amazon DynamoDB와 같은 관리형 서비스는 더 높은 수준이거나 애플리케이션 수준의 AWS 서비스입니다. 기본 구성 서비스와 관리형 서비스를 적절히 선택하여 이 워크로드의 비용을 최적화할 수 있습니다. 예를 들어 관리형 서비스를 사용하면 관리 및 운영 고정 비용을 상당 부분 줄이고, 애플리케이션 및 비즈니스 관련 활동에 집중할 수 있습니다. |
| COST 6: 리소스 유형, 크기 및 수 선택을 통해 비용 목표를 어떻게 달성하나요? |
| --- |
| 진행 중인 작업에 대해 적절한 리소스 크기와 리소스 수를 선택해야 합니다. 가장 비용 효율적인 유형, 크기 및 수를 선택하여 리소스 낭비를 최소화할 수 있습니다. |
| COST 7: 비용 절감을 위해 요금 모델을 어떻게 사용하나요? |
| --- |
| 해당 리소스에 대해 비용을 최소화하는 데 가장 적합한 요금 모델을 사용합니다. |
| COST 8: 데이터 전송 요금을 위한 계획은 어떻게 되나요? |
| --- |
| 비용 최소화를 위한 아키텍처 관련 사항을 결정할 수 있도록 데이터 전송 요금을 계획하고 모니터링해야 합니다. 아키텍처를 약간이라도 효율적으로 변경하면 장기적으로 운영 비용을 크게 줄일 수 있습니다. |
서비스 선택 시 비용을 고려하고 Cost Explorer 및 AWS Trusted Advisor와 같은 도구를 사용하여 AWS 사용량을 정기적으로 검토함으로써 사용률을 적극적으로 모니터링하고 그에 따라 배포를 조절할 수 있습니다.
# 수요 관리 및 리소스 공급
클라우드로 이전하면 필요한 용량에 대한 비용만 지불하면 됩니다. 필요할 때 워크로드 수요에 맞춰 리소스를 공급할 수 있으므로 비용이 많이 들고 비경제적인 오버프로비저닝이 줄어듭니다. 또한 조절, 버퍼 또는 대기열을 통해 수요를 수정하여 수요를 원활하게 하고 더 적은 리소스로 수요를 처리함으로써 비용을 낮추거나 나중에 배치 서비스로 수요를 처리할 수 있습니다.
AWS에서는 워크로드 수요에 맞춰 리소스를 자동으로 프로비저닝할 수 있습니다. 수요 또는 시간 기반 접근 방식을 사용하는 Auto Scaling을 활용하면 필요한 만큼 리소스를 추가하고 제거할 수 있습니다. 수요의 변화를 예측할 수 있으면 비용을 더 많이 절약하고 워크로드 수요에 리소스를 맞출 수 있습니다. Amazon API Gateway를 사용하여 조절을 실행하거나 Amazon SQS를 사용하여 워크로드에서 대기열을 구현할 수 있습니다. 둘 다 워크로드 구성 요소에 대한 수요를 수정할 수 있습니다.
다음은 비용 최적화 고려 사항에 중점을 둔 질문입니다.
| COST 9: 수요와 리소스 공급은 어떻게 관리하나요? |
| --- |
| 비용과 성능을 적절하게 절충한 워크로드에서는 비용을 결제한 모든 리소스가 사용되는지 확인하고, 사용률이 매우 낮은 인스턴스가 없도록 해야 합니다. 사용률 지표가 매우 높거나 낮으면 조직의 운영 비용(사용률이 너무 높아 성능이 저하됨)이 늘어나거나 과도한 프로비저닝으로 AWS 지출 금액이 낭비되는 등 조직에 악영향을 미칩니다. |
수요 및 공급 리소스를 수정하도록 설계할 때는 사용 패턴, 새 리소스를 프로비저닝하는 데 걸리는 시간 및 수요 패턴의 예측 가능성을 적극적으로 고려하세요. 수요를 관리할 때 대기열 또는 버퍼의 크기가 적절한지 그리고 필요한 시간 내에 워크로드 수요에 응답하고 있는지 확인해야 합니다.
# 시간 경과에 따른 최적화
AWS에서 신규 서비스와 기능이 출시되면 기존에 결정한 아키텍처 관련 사항을 검토하여 비용 측면에서 여전히 가장 효율적인 결정인지 확인하는 것이 좋습니다. 요구 사항이 변경되면 더 이상 필요하지 않은 리소스, 전체 서비스 및 시스템을 과감하게 폐기하세요.
새로운 기능 또는 리소스 유형을 구현하면 변경 사항을 구현하는 데 필요한 노력을 최소화하면서 워크로드를 점진적으로 최적화할 수 있습니다. 이를 통해 장기적 효율성이 지속적으로 향상되고 최첨단 기술을 계속 활용하여 운영 비용을 절감할 수 있습니다. 구성 요소를 교체하거나 새 구성 요소를 워크로드에 신규 서비스와 함께 추가할 수도 있습니다. 이렇게 하면 효율성이 크게 향상될 수 있으므로 정기적으로 워크로드를 검토하고 신규 서비스와 기능을 구현하는 것이 반드시 필요합니다.
다음은 비용 최적화 고려 사항에 중점을 둔 질문입니다.
| COST 10: 새로운 서비스를 어떻게 평가하나요? |
| --- |
| AWS에서 신규 서비스와 기능이 출시되면 기존에 결정한 아키텍처 관련 사항을 검토하여 비용 측면에서 여전히 가장 효율적인 결정인지 확인하는 것이 좋습니다. |
정기적으로 배포를 검토할 때 최신 서비스가 비용을 절약하는 데 어떻게 도움이 될 수 있는지 평가합니다. 예를 들어 Amazon Aurora on Amazon RDS를 사용하면 관계형 데이터베이스의 비용을 줄일 수 있습니다. Lambda와 같은 서버리스를 사용하면 코드를 실행하기 위해 인스턴스를 운영하고 관리할 필요가 없습니다.
| COST 11: 작업 비용을 어떻게 평가하나요? |
| --- |
| 클라우드에서의 운영 비용을 평가하고, 시간이 많이 걸리는 클라우드 운영을 검토하며, 관련 AWS 서비스, 서드파티 제품 또는 사용자 지정 도구를 채택하여 인적 노력과 비용을 줄이도록 이를 자동화하합니다. |
# 리소스
비용 최적화 관련 모범 사례에 대해 자세히 알아보려면 다음 리소스를 참조하세요.
## 설명서
+ [AWS 설명서](https://docs.aws.amazon.com/index.html?ref=wellarchitected-wp)
## 백서
+ [비용 최적화 요소](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html?ref=wellarchitected-wp)
# 지속 가능성
지속 가능성 원칙은 환경 영향, 특히 에너지 소비 및 효율성에 중점을 두고 있는데, 이는 건축가가 자원 사용을 줄이기 위한 직접적인 조치를 알아낼 수 있는 중요한 수단이기 때문입니다. 구현에 대한 권장 가이드는 [지속 가능성 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp)에서 확인할 수 있습니다.
**Topics**
+ [설계 원칙](sus-design-principles.md)
+ [정의](sus-def.md)
+ [모범 사례](sus-bp.md)
+ [리소스](sus-resources.md)
# 설계 원칙
클라우드에는 6가지 지속 가능성 설계 원칙이 있습니다.
+ **영향 파악:** 클라우드 워크로드의 영향을 측정하고 워크로드의 향후 영향을 모델링합니다. 고객의 제품 사용으로 인한 영향과 최종 폐기 및 사용 중지로 인한 영향을 포함하여 영향의 모든 원인을 포함합니다. 작업 단위당 필요한 리소스 및 배출량을 검토하여 생산량을 클라우드 워크로드의 총 영향과 비교합니다. 이 데이터를 사용하여 핵심 성과 지표(KPI)를 설정하고, 영향을 줄이면서 생산성을 개선하는 방법을 평가하며, 시간 경과에 따른 제안된 변경의 영향을 예측할 수 있습니다.
+ **지속 가능성 목표 설정:** 각 클라우드 워크로드에 대해 트랜잭션당 필요한 컴퓨팅 및 스토리지 리소스의 절감과 같은 장기적인 지속 가능성 목표를 설정합니다. 기존 워크로드에 대한 지속 가능성 개선의 투자 수익률을 모델링하고 소유자에게 지속 가능성 목표에 투자하는 데 필요한 리소스를 제공합니다. 성장을 계획하고 워크로드를 설계하여 성장으로 인해 사용자당 또는 트랜잭션당 등 적절한 단위에 대해 측정된 영향 강도를 줄입니다. 목표를 통해 비즈니스 또는 조직의 보다 광범위한 지속 가능성 목표를 지원하고, 회귀를 식별하며, 잠재적 개선 영역의 우선순위를 지정할 수 있습니다.
+ **활용률 극대화:** 워크로드 크기를 적절하게 조정하고 효율적인 설계를 구현하여 높은 활용률을 보장하고 기본 하드웨어의 에너지 효율성을 극대화합니다. 호스트당 기준 전력 소비로 인해 30% 활용률로 실행되는 호스트 두 개는 60%로 실행되는 호스트 하나보다 효율성이 떨어집니다. 동시에 유휴 리소스, 처리 및 스토리지를 줄이거나 최소화하여 워크로드에 전력을 공급하는 데 필요한 총 에너지를 줄입니다.
+ **보다 효율적인 최신 하드웨어와 소프트웨어 제품 및 서비스 예측 및 도입:** 파트너와 공급업체가 업스트림 개선을 통해 클라우드 워크로드의 영향을 줄일 수 있도록 지원합니다. 새롭고 더 효율적인 하드웨어와 소프트웨어 제품 및 서비스를 지속적으로 모니터링하고 평가합니다. 새롭고 효율적인 기술을 신속하게 도입할 수 있도록 유연성을 고려하여 설계합니다.
+ **관리형 서비스 사용:** 광범위한 고객 기반에서 서비스를 공유하면 리소스 활용률을 극대화하여 클라우드 워크로드를 지원하는 데 필요한 인프라의 양을 줄일 수 있습니다. 예를 들어, 고객은 워크로드를 AWS 클라우드로 마이그레이션하고 AWS가 대규모로 운영하고 효율적인 운영을 책임지는 서버리스 컨테이너용 AWS Fargate와 같은 관리형 서비스를 도입함으로써 전력 및 네트워킹과 같은 일반적인 데이터 센터 구성 요소의 영향을 공유할 수 있습니다. Amazon S3 수명 주기 구성 또는 Amazon EC2 Auto Scaling을 사용하여 자주 액세스하지 않는 데이터를 콜드 스토리지로 자동 이동함으로써 수요에 맞게 용량을 조정하는 등 영향을 최소화할 수 있는 관리형 서비스를 사용합니다.
+ **클라우드 워크로드의 다운스트림 영향 감소:** 서비스를 사용하는 데 필요한 에너지 또는 리소스의 양을 줄입니다. 고객이 서비스를 사용하기 위해 디바이스를 업그레이드할 필요성을 줄입니다. Device Farm을 사용하여 테스트함으로써 예상되는 영향을 파악하고 고객과의 테스트를 통해 서비스 사용으로 인한 실제 영향을 이해합니다.
# 정의
클라우드의 지속 가능성에는 6가지 모범 사례 영역이 있습니다.
+ 리전 선택
+ 수요에 맞춘 조정
+ 소프트웨어 및 아키텍처
+ 데이터
+ 하드웨어 및 서비스
+ 프로세스 및 문화
클라우드에서의 지속 가능성이란 주로 프로비저닝된 리소스의 이점을 극대화하고 필요한 총 리소스를 최소화하면서 워크로드의 모든 구성 요소에서 에너지 절감과 효율성에 초점을 맞춘 지속적인 노력을 말합니다. 이러한 노력은 초기에 효율적인 프로그래밍 언어를 선택하고, 현대적인 알고리즘을 채택하며, 능률적인 데이터 스토리지 기술을 사용하여 적절한 크기의 효과적인 컴퓨팅 인프라를 배포하고 고성능 최종 사용자 하드웨어 요구 사항을 최소화하는 등 다양하게 나타날 수 있습니다.
# 모범 사례
**Topics**
+ [리전 선택](sus-region-selection.md)
+ [수요에 맞춘 조정](sus-user-behavior-patterns.md)
+ [소프트웨어 및 아키텍처](sus-software-architecture-patterns.md)
+ [데이터 관리](sus-data-patterns.md)
+ [하드웨어 및 서비스](sus-hardware-patterns.md)
+ [프로세스 및 문화](sus-development-deployment-patterns.md)
# 리전 선택
워크로드 리전의 선택은 성능, 비용 및 탄소 배출량을 포함한 KPI에 큰 영향을 미칩니다. 이러한 KPI를 개선하려면 비즈니스 요구 사항과 지속 가능성 목표를 기준으로 워크로드의 리전을 선택해야 합니다.
다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다. (지속 가능성 질문 및 모범 사례 목록은 [부록](a-sustainability.md)을 참조하세요.)
| SUS 1: 워크로드에 적합한 리전을 선택하려면 어떻게 해야 하나요? |
| --- |
| 워크로드 리전의 선택은 성능, 비용 및 탄소 배출량을 포함한 KPI에 큰 영향을 미칩니다. 이러한 KPI를 개선하려면 비즈니스 요구 사항과 지속 가능성 목표를 기준으로 워크로드의 리전을 선택해야 합니다. |
# 수요에 맞춘 조정
사용자 및 애플리케이션이 워크로드 및 기타 리소스를 사용하는 방식을 통해 지속 가능성 목표를 달성하기 위한 개선 사항을 식별할 수 있습니다. 인프라를 지속적으로 확장하여 수요를 충족하고 사용자를 지원하는 데 필요한 최소 리소스만 활용하는지 확인합니다. 고객 요구 사항에 맞게 서비스 수준을 조정합니다. 사용자가 리소스를 소비하는 데 필요한 네트워크를 제한하도록 리소스를 배치합니다. 사용되지 않는 자산을 제거합니다. 팀원에게 지속 가능성에 미치는 영향을 최소화하면서 요구 사항을 지원하는 디바이스를 제공합니다.
다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다.
| SUS 2: 클라우드 리소스를 비즈니스 요구에 어떻게 맞추나요? |
| --- |
| 사용자 및 애플리케이션이 워크로드 및 기타 리소스를 사용하는 방식을 통해 지속 가능성 목표를 달성하기 위한 개선 사항을 식별할 수 있습니다. 인프라를 지속적으로 확장하여 수요를 충족하고 사용자를 지원하는 데 필요한 최소 리소스만 활용하는지 확인합니다. 고객 요구 사항에 맞게 서비스 수준을 조정합니다. 사용자가 리소스를 소비하는 데 필요한 네트워크를 제한하도록 리소스를 배치합니다. 사용되지 않는 자산을 제거합니다. 팀원에게 지속 가능성에 미치는 영향을 최소화하면서 요구 사항을 지원하는 디바이스를 제공합니다. |
사용자 로드에 맞게 인프라 규모 조정: 활용률이 낮거나 없는 기간을 식별하고 리소스의 크기를 조정하여 초과 용량을 줄이고 효율성을 개선합니다.
SLA를 지속 가능성 목표에 맞게 조정: 가용성 또는 데이터 보존 기간과 같은 서비스 수준에 관한 계약(SLA)을 정의 및 업데이트하여 워크로드를 지원하는 동시에 비즈니스 요구 사항을 지속적으로 충족하는 데 필요한 리소스 수를 최소화합니다.
사용되지 않는 자산 생성 및 유지 관리 감소: 애플리케이션 자산(예: 사전 컴파일된 보고서, 데이터 집합, 정적 이미지 등)과 자산 액세스 패턴을 분석하여 중복성, 활용률 저하 및 잠재적 폐기 대상을 식별합니다. 생성된 자산을 중복 콘텐츠(예: 중복되거나 공통된 데이터 집합 및 출력이 포함된 월간 보고서)로 통합하여 출력을 복제할 때 소비되는 리소스를 줄입니다. 사용되지 않는 자산(예: 더 이상 판매되지 않는 제품 이미지)을 폐기하여 사용된 리소스를 해제하고 워크로드를 지원하는 데 사용되는 리소스 수를 줄입니다.
사용자 위치에 대한 워크로드의 지리적 배치 최적화: 네트워크 액세스 패턴을 분석하여 고객이 접속하는 지리적 위치를 식별합니다. 워크로드를 지원하는 데 필요한 총 네트워크 리소스를 줄이기 위해 네트워크 트래픽이 이동해야 하는 거리가 적은 리전 및 서비스를 선택합니다.
수행된 활동에 대한 팀원 리소스 최적화: 팀원에게 제공되는 리소스를 최적화하여 팀원에게 필요한 지원을 충분히 제공하면서도 지속 가능성에 미치는 영향을 최소화합니다. 예를 들어, 활용률이 낮은 고성능 단일 사용자 시스템 대신 활용률이 높은 공유 클라우드 데스크톱에서 렌더링 및 컴파일과 같은 복잡한 작업을 수행합니다.
# 소프트웨어 및 아키텍처
로드 평준화를 수행하고 배포된 리소스의 높은 활용률을 일관되게 유지하여 소비되는 리소스를 최소화하기 위한 패턴을 구현합니다. 구성 요소는 시간 경과에 따른 사용자 행동의 변화로 인해 사용 부족으로 인해 유휴 상태가 될 수 있습니다. 패턴과 아키텍처를 수정하여 활용률이 낮은 구성 요소를 통합함으로써 전체 활용률을 높입니다. 더 이상 필요하지 않은 구성 요소를 폐기합니다. 워크로드 구성 요소의 성능을 이해하고 리소스를 가장 많이 사용하는 구성 요소를 최적화합니다. 고객이 서비스에 액세스하고 패턴을 구현하는 데 사용하는 디바이스를 숙지하여 디바이스 업그레이드 필요성을 최소화합니다.
다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다.
| SUS 3: 소프트웨어 및 아키텍처 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 하나요? |
| --- |
| 로드 평준화를 수행하고 배포된 리소스의 높은 활용률을 일관되게 유지하여 소비되는 리소스를 최소화하기 위한 패턴을 구현합니다. 구성 요소는 시간 경과에 따른 사용자 행동의 변화로 인해 사용 부족으로 인해 유휴 상태가 될 수 있습니다. 패턴과 아키텍처를 수정하여 활용률이 낮은 구성 요소를 통합함으로써 전체 활용률을 높입니다. 더 이상 필요하지 않은 구성 요소를 폐기합니다. 워크로드 구성 요소의 성능을 이해하고 리소스를 가장 많이 사용하는 구성 요소를 최적화합니다. 고객이 서비스에 액세스하고 패턴을 구현하는 데 사용하는 디바이스를 숙지하여 디바이스 업그레이드 필요성을 최소화합니다. |
비동기식 및 예약된 작업을 위한 소프트웨어 및 아키텍처 최적화: 효율적인 소프트웨어 설계 및 아키텍처를 사용하여 작업 단위당 필요한 평균 리소스를 최소화합니다. 구성 요소를 균일하게 활용하여 작업 간에 유휴 상태인 리소스를 줄이고 로드 급증의 영향을 최소화하는 메커니즘을 구현합니다.
사용 빈도가 낮거나 전혀 없는 워크로드 구성 요소 제거 또는 리팩터링: 워크로드 활동을 모니터링하여 시간에 따른 개별 구성 요소의 사용률 변화를 파악합니다. 사용되지 않아 더 이상 필요하지 않은 구성 요소와 활용률이 낮은 구성 요소를 리팩터링하여 낭비되는 리소스를 제한합니다.
가장 많은 시간 또는 리소스를 소모하는 코드 영역 최적화: 워크로드 활동을 모니터링하여 가장 많은 리소스를 소비한 애플리케이션 구성 요소를 식별합니다. 이러한 구성 요소 내에서 실행되는 코드를 최적화하여 성능을 극대화하면서 리소스 사용을 최소화합니다.
고객 디바이스 및 장비에 대한 영향 최소화: 고객이 서비스를 사용하기 위해 사용하는 디바이스와 장비, 예상 수명 주기, 이러한 구성 요소 교체가 재정 및 지속 가능성에 미치는 영향을 이해합니다. 소프트웨어 패턴 및 아키텍처를 구현하여 고객이 디바이스를 교체하고 장비를 업그레이드해야 하는 필요성을 최소화합니다. 예를 들어, 이전 하드웨어 및 운영 체제 버전과 역호환되는 코드를 사용하여 새로운 기능을 구현하거나 대상 디바이스의 저장 용량을 초과하지 않도록 페이로드 크기를 관리합니다.
데이터 액세스 및 저장 패턴을 가장 잘 지원하는 소프트웨어 패턴 및 아키텍처 사용: 데이터가 워크로드 내에서 사용되고, 사용자가 소비하며, 전송 및 저장되는 방식을 이해합니다. 데이터 처리 및 스토리지 요구 사항을 최소화하는 기술을 선택합니다.
# 데이터 관리
다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다.
| SUS 4: 데이터 관리 정책 및 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 하나요? |
| --- |
| 데이터 관리 원칙을 구현하여 워크로드를 지원하는 데 필요한 프로비저닝된 스토리지와 이를 사용하는 데 필요한 리소스를 줄입니다. 데이터를 이해하고 데이터의 비즈니스 가치와 데이터 사용 방식을 가장 효과적으로 지원하는 스토리지 기술과 구성을 사용합니다. 요구 사항이 감소하면 데이터를 더 효율적이고 성능이 낮은 스토리지로 수명 주기를 변경하고 더 이상 필요하지 않은 데이터는 삭제합니다. |
데이터 분류 정책 구현: 데이터를 분류하여 비즈니스 성과에 미치는 분류의 영향을 파악합니다. 이 정보를 사용하여 데이터를 보다 에너지 효율적인 스토리지로 이동하거나 안전하게 삭제할 수 있는 시기를 결정합니다.
데이터 액세스 및 스토리지 패턴을 지원하는 기술 사용: 데이터 액세스 및 저장 방법을 가장 잘 지원하는 스토리지를 사용하여 워크로드를 지원하면서 프로비저닝된 리소스를 최소화합니다. 예를 들어, SSD(Solid State Device)는 자기 드라이브보다 에너지 집약적이므로 활성 데이터 사용 사례에만 사용해야 합니다. 자주 액세스하지 않는 데이터에는 에너지 효율적인 아카이빙 클래스 스토리지를 사용합니다.
수명 주기 정책을 사용하여 불필요한 데이터 삭제: 모든 데이터의 수명 주기를 관리하고 삭제 일정을 자동으로 적용하여 워크로드의 총 스토리지 요구 사항을 최소화합니다.
블록 스토리지에서 과다 프로비저닝 최소화: 프로비저닝된 스토리지의 총량을 최소화하려면 워크로드에 적합한 크기가 할당된 블록 스토리지를 생성합니다. 탄력적 볼륨을 사용하면 컴퓨팅 리소스에 연결된 스토리지의 크기를 조정할 필요 없이 데이터가 증가함에 따라 스토리지를 확장할 수 있습니다. 탄력적 볼륨을 정기적으로 검토하고 과다 프로비저닝된 볼륨을 현재 데이터 크기에 맞게 축소합니다.
필요하지 않은 데이터 또는 중복 데이터 제거: 필요한 경우에만 데이터를 복제하여 총 스토리지 사용을 최소화합니다. 파일 및 블록 수준에서 데이터를 중복 제거하는 백업 기술을 사용합니다. SLA를 충족하는 데 필요한 경우를 제외하고 RAID(Redundant Array of Independent Drives) 구성의 사용을 제한합니다.
공유 파일 시스템 또는 객체 스토리지를 사용하여 공용 데이터에 액세스: 공유 스토리지와 단일 정보 소스를 도입하여 데이터 중복을 방지하고 워크로드의 총 스토리지 요구 사항을 줄입니다. 필요한 경우에만 공유 스토리지에서 데이터를 가져옵니다. 미사용 볼륨을 분리하여 리소스를 확보합니다. 네트워크 간 데이터 이동을 최소화합니다. 공유 스토리지를 사용하고 리전 데이터 스토어의 데이터에 액세스하여 워크로드의 데이터 이동을 지원하는 데 필요한 총 네트워킹 리소스를 최소화할 수 있습니다.
다시 생성하기 어려운 경우에만 데이터 백업: 스토리지 소비를 최소화하려면 비즈니스 가치가 있거나 규정 준수 요구 사항을 충족하는 데 필요한 데이터만 백업합니다. 백업 정책을 검토하고 복구 시나리오에서 가치를 제공하지 않는 임시 스토리지는 제외합니다.
# 하드웨어 및 서비스
하드웨어 관리 방식을 변경하여 지속 가능성에 미치는 워크로드의 영향을 줄일 수 있는 기회를 모색합니다. 프로비저닝 및 배포에 필요한 하드웨어의 양을 최소화하고 개별 워크로드에 가장 효율적인 하드웨어 및 서비스를 선택합니다.
다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다.
| SUS 5: 지속 가능성 목표를 지원하기 위해 아키텍처에서 클라우드 하드웨어 및 서비스를 어떻게 선택하고 사용하나요? |
| --- |
| 하드웨어 관리 방식을 변경하여 지속 가능성에 미치는 워크로드의 영향을 줄일 수 있는 기회를 모색합니다. 프로비저닝 및 배포에 필요한 하드웨어의 양을 최소화하고 개별 워크로드에 가장 효율적인 하드웨어 및 서비스를 선택합니다. |
요구 사항을 충족하는 데 필요한 최소한의 하드웨어 사용: 클라우드의 기능을 사용하여 워크로드 구현을 자주 변경할 수 있습니다. 변화하는 요구 사항에 따라 배포된 구성 요소를 업데이트합니다.
영향이 가장 적은 인스턴스 유형 사용: 새로운 인스턴스 유형의 릴리스를 지속적으로 모니터링하고 기계 학습 훈련 및 추론, 동영상 트랜스코딩과 같은 특정 워크로드를 지원하도록 설계된 인스턴스 유형을 포함하여 에너지 효율성 개선의 이점을 활용합니다.
관리형 서비스 사용: 관리형 서비스는 배포된 하드웨어의 높은 평균 활용률과 지속 가능성 최적화를 유지하는 책임을 AWS로 이전합니다. 관리형 서비스를 사용하여 지속 가능성에 미치는 서비스의 영향을 서비스의 모든 테넌트에 분산하여 개인의 기여도를 낮춥니다.
GPU 사용 최적화: 그래픽 처리 디바이스(GPU)는 높은 전력 소비의 원인이 될 수 있으며 렌더링, 트랜스코딩, 기계 학습 훈련 및 모델링과 같은 많은 GPU 워크로드는 매우 가변적입니다. 필요한 시간 동안만 GPU 인스턴스를 실행하고 필요하지 않은 경우 자동화를 통해 GPU 인스턴스를 폐기하여 리소스 사용을 최소화합니다.
# 프로세스 및 문화
개발, 테스트 및 배포 방식을 변경하여 지속 가능성에 미치는 영향을 줄일 수 있는 기회를 모색합니다.
다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다.
| SUS 6: 조직의 프로세스가 지속 가능성 목표를 어떻게 지원하고 있나요? |
| --- |
| 개발, 테스트 및 배포 방식을 변경하여 지속 가능성에 미치는 영향을 줄일 수 있는 기회를 모색합니다. |
지속 가능성 개선을 신속하게 도입할 수 있는 방법 채택: 잠재적인 개선 사항을 프로덕션에 배포하기 전에 테스트하고 검증합니다. 개선 사항으로 실현될 미래의 잠재적 이익을 계산할 때 테스트 비용을 고려합니다. 소규모 개선 사항을 제공할 수 있도록 저비용 테스트 작업을 개발합니다.
워크로드를 최신 상태로 유지: 최신 운영 체제, 라이브러리 및 애플리케이션을 통해 워크로드 효율성을 개선하고 보다 효율적인 기술을 더 쉽게 채택할 수 있습니다. 공급업체가 자체적인 지속 가능성 목표를 충족할 수 있는 기능을 제공함에 따라, 최신 소프트웨어에는 워크로드의 지속 가능성에 미치는 영향을 보다 정확하게 측정하는 기능이 포함될 수도 있습니다.
빌드 환경의 사용률 증가: 자동화와 코드형 인프라를 사용하여 필요 시 프로덕션 전 환경을 가동하고 사용하지 않을 때는 해당 환경을 종료합니다. 일반적인 패턴은 개발 담당 팀원의 근무 시간과 일치하는 가용 기간을 예약하는 것입니다. 최대 절전 모드는 상태를 유지하고 필요할 때만 인스턴스를 빠르게 온라인으로 전환할 수 있는 유용한 도구입니다. 버스트 용량이 포함된 인스턴스 유형, 스팟 인스턴스, 탄력적 데이터베이스 서비스, 컨테이너 및 기타 기술을 사용하여 사용량에 따라 개발 및 테스트 용량을 조정합니다.
테스트를 위해 관리형 Device Farm 사용: 관리형 Device Farm은 하드웨어 제조 및 리소스 사용이 지속 가능성에 미치는 영향을 여러 테넌트에 분산시킵니다. 관리형 Device Farm은 다양한 디바이스 유형을 제공하며, 사용 빈도가 낮은 오래된 하드웨어를 지원하고 불필요한 디바이스 업그레이드로 인한 고객의 지속 가능성에 미치는 영향을 방지할 수 있습니다.
# 리소스
지속 가능성 관련 모범 사례에 대해 자세히 알아보려면 다음 리소스를 참조하세요.
## 백서
+ [지속 가능성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp)
## 비디오
+ [The Climate Pledge](https://www.youtube.com/watch?v=oz9iO0EOpI0&ref=wellarchitected-wp)