AWS Well-Architectured

The Five Pillars of the Framework

Operational Excellence (운영 고도화):

운영중인 시스템을 모니터링 하고, 지원체계를 끊임없이 개선할 수 있습니까?

Security (보안)

AWS 클라우드 상의 데이터 및 자산을 안전하게 보호하기 위한 best practice 가 적용되어 있습니까?

Reliability (안정성)

시스템 아키텍쳐가 장애, 업무 증가 및 기타 이벤트에 능동적으로 대처할 수 있습니까?

Performance Efficiency (성능)

시스템 리소스들이 최적의 성능을 낼 수 있도록 설계되어 있습니까?

Cost Optimization (비용 효율)

비용을 줄일 수 있는 방법들을 고려하고 있습니까?

aws-5-pillars

Design Principles

필요한 용량을 '추측' 하지 말자

클라우드는 사용자가 원할 때 리소스를 가져다 쓸 수 있는 탄력적인 구성이 가능하다. 따라서 굳이 불필요한 추측을 하지 말고 현재 당장 필요한 리소스들을 가지고 아키텍쳐를 설계하는 것이 더 현명하다

운영환경의 규모에 맞게 테스트를 수행

프로덕션의 규모가 크기 때문에 비용을 줄이려고 종종 테스트 환경은 약식으로 하고 소규모하게 (integrations, functions and perf tests) 테스트한다. 그런데, 실제로 예상치 못한 문제들이 생긴다.

클라우드는 필요할 때 필요한 리소스들을 가지고 테스트하고, 테스트가 끝나면 그 리소스들을 과감하게 버릴 수 있기 때문에 많은 비용이 나가지 않으면서도 운영 환경 규모에 맞는 테스트를 할 수 있다.

아키텍쳐에 대한 변경/실험을 자동화

운영 중에도 끊임없이 변경과 실험을 하게 된다. 안정적인 앱을 운영하기 위해서 굉장히 작은 규모의 변경/실험들을 자주 테스트 하는 것이 좋다. 시간과 비용을 줄이기 위해 이런것들은 자동화를 하자.

Data-driven 아키텍쳐를 디자인

클라우드는 아키텍쳐 선택이 워크로드 거동에 미치는 영향에 대한 데이터를 수집할 수 있다. 그러므로 사실에 근거하여 어떻게 워크로드를 개선할지 결정할 수 있다. 클라우드 인프라는 코드이므로 이 데이터를 장기적으로 아키텍쳐 선택 및 개선을 위한 정보로 활용할 수 있다. 아키텍쳐 개선, 고도화, 비용 효율 등과 같은 과정은 endgame이 아니라 꾸준히 장기적으로 가져가야 할 여정이다.

Security (보안)

Design Principles

모든 영역에 보안을 적용

  • 인프라 전체에 적용되는 방화벽보다는, 각각의 리소스에 대한 방화벽 사용 및 보안 제어를 설정하자.
  • 추적 로그를 수집: 모든 활동과 변경 사항들에 대한 로그를 수집하여 감시하자.
  • 보안 이벤트에 대한 대처를 자동화: 지속적인 모니터링을 수행하고, 이벤트 혹은 조건에 따른 대처를 자동화하자.

애플리케이션, 데이터의 보호에 집중

AWS는 인프라 및 서비스에 대한 보안을 제공한다. 개발자는 운영되고 있는 앱, 데이터 및 운영 체제의 보안에 집중하면 된다.

보안에 대한 best practice를 자동화

최적화된 이미지들을 사용하고, 전체 인프라를 템플릿을 통하여 관리하자.

Definition:

Data protection (데이터 보호)

  • 전송 및 보관시 암호화: ELB (elastic load balancing), EBS, S3 및 RDS
  • 암호화 키 생성 및 관리: KMS (key management service), CloudHSM

Privilege management (권한 관리)

  • AWS는 root 계정은 사용하지 말라고 누누히 경고한다. 사용하지 말자. IAM을 셋업해서 사용하자.
  • 인증 강화 MFA (multi factor authentication) 를 사용해도 좋다. Token 사용 등, 은행 OTP와 흡사하다.

Infrastructure protection (인프라 보호)

네트워크는 논리적으로 격리된다: VPC, VPN

Detective controls (감시 제어)

  • CloudTrail 로 API 호출을 기록하고, CloudWatch로 자원 모니터링을 하자.
  • Config를 통해 인벤토리 변경 이력 관리를 할 수 있다.
  • VPC Flow Logs를 사용하면 네트워크 IP 트래픽 수집, 저장 및 분석을 할 수 있다.
  • 로그 데이터를 CloudWatch 및 S3로 게시할 수 있다.

Reliability (안정성)

Design Principles:

복구 절차를 테스트

다양한 형태의 장애상황을 만들고 복구하는 시나리오를 자동화하여 복구시 문제를 미리 파악하여 대처하자.

문제 발생시 자동으로 보구될 수 있도록 구성

중요 요소들에 대한 모니터링을 수행하여, 임계치에 도달했을 때 자동으로 필요한 절차를 수행하도록 시스템을 구성하자. 이를 통해 장애에 대한 감지, 추적, 조치 뿐만 아니라 더 나아가서 장애를 사전에 예방하자.

시스템의 가용성을 높이기 위해서 수평 확장이 가능하도록 구성

하나의 큰 자원을 사용하는 것보다, 여러 개의 작은 자원들을 사용하는 것이 장애 발생 시 피해를 최소화한다. 물론, 먼저 작은 자원들이 공통된 장애 요소를 가지고 있지 않도록 구성하자.

고정적이지 않고, Dynamic 한 아키텍처 구성

시스템의 용량을 초과하는 부하가 유입되는 경우 (이벤트, DDoS 등) 에도 자원의 고갈로 인해 문제가 발생하지 않도록 동적으로 구성하자. AWS는 auto scaling를 지원한다. 어카운트의 Service Limits에 대해 미리 잘 알고 있으면 좋다.

Definition:

Foundations (기본 요건)

  • IAM으로 AWS 서비스 및 자원들에 대한 접근을 제어하자.
  • VPC으로 AWS 서비스 및 자원들을 독립된 네트워크 공간에서 안전하게 운영하자.
  • Service limit를 관리하자.

Change Management (변경 관리)

  • CloudTrail으로 AWS의 API 호출에 대한 기록을 보관하자.
  • Config으로 AWS 자원 및 구성에 대한 인벤토리를 관리하자.
  • 지속적으로 구성 변경을 관리하자.

Failure Management (장애 관리)

  • CloudFormation으로 원하는 AWS 자원들을 자동 생성하는 템플릿을 구성하자.
  • Auto Recovery 기능을 활용하여 자동 복구를 설정하자.
  • Auto Scaling Group 기능을 활요하여 Self Healing 설정하자.

Performance Efficiency (성능):

Design Principles:

  • 최신 서비스와 기능 사용
  • Multi Region 또는 CDN 사용
  • 서버리스 아키텍쳐 사용
  • 더 자주 새로운 아이디어를 실험

Selection

Computing: Elasticity mechanism을 활용하여 수요 변화에 맞춰 성능을 유지할 수 있는 충분한 용량을 확보해야 한다.

  • Auto Scaling은 수요를 충족하고 응답 속도를 유지할 수 있는 충분한 인스턴스를 보장해 준다.

Storage: 액세스 방식 (블록, 파일 or 객체), 액세스 패턴 (무작위 or 순차적), 필요한 처리량, 액세스 빈도 (온라인, 오프라인 or 보관), 업데이트 빈도 (WORM, 동적), 가용성 및 내구성 제약을 생각해야 한다.

  • 액세스 패턴과 일치하도록 선택하는 것이 원하는 성능을 구현하는 데 매우 중요하다.
  • EBS: 사용 사례에 맞춰 최적화할 수 있는 광범위한 스토리지 옵션 제공 (SSD, 프로비저닝된 IOPS 초당 입 / 출력 작업 수).
  • S3: 서버리스 콘텐츠 전송 및 Transfer Acceleration으로 장거리에서 컨텐츠를 빠르고, 쉽고, 안전하게 전송한다.

Database: 가용성, 일관성, 파티션 허용치, 지연 시간, 내구성, 확장성 및 쿼리 용량에 대한 요구 사항을 생각해야 한다. 스토리지처럼 워크로드의 액세스 패턴을 고려하는 것이 중요하며, 다른 비 데이터베이스 솔루션 (검색 엔진 or data warehouse 사용) 보다 효율적으로 문제를 해결할 수 있는지 여부도 고려해야 한다.

  • RDS를 사용하면 거의 가동 중지 없이 DB의 컴퓨팅과 스토리지 리소스를 확장할 수 있다. 또한, 프로비저닝된 IOPS, 읽기 전용 복제본 등을 제공한다.
  • DynamoDB는 확장 시 지연 시간이 한 자릿수 밀리초 단위로 매우 짧다.
  • Redshift (페타바이트 규모의 관리형 데이터 웨어하우스)는 성능 또는 용량을 변경해야 할 경우 노드 수 또는 유형을 변경할 수 있다.

Network: 위치를 고려해야 한다. 리전, 배치 그룹 및 에지 위치를 활요하여 성능을 현저히 개선할 수 있다.

  • 네트워크 트래픽 최적화 (EBS-optimized instances, S3 transfer acceleration, dynamic CloudFront)
  • 네트워크 거리 또는 jitter을 줄임 (Route 53 latency routing, VPC endpoints, Direct Connect)

Review

AWS는 정기적으로 새로운 리전, 에지 위치, 서비스 및 기능을 출시한다. 이들 모두는 아키텍쳐의 성능 효율을 개선할 수 있다. 어떤 조건이 아키텍쳐 성능을 제약하는지 이해하면 해당 제약 조건을 완화할 수 있는 릴리스를 찾아볼 수 있다. AWS 블로그 및 웹 사이트의 새 소식 섹션을 참고하자.

Monitoring

고객이 인지하기 전에 모든 문제를 해결할 수 있도록 성능을 모니터링해야 한다. 너무 많은 false positives 또는 데이터가 과도하게 발생하지 않도록 하는 것이 효과적인 모니터링 솔루션의 관건이다. 자동 트리거는 운영자의 실수를 방지하고 문제 해결 시간을 단축시킬 수 있다.

  • CloudWatch는 모니터링 기능 및 알림 경보 전송 기능을 제공한다
  • Kinesis, SQS (simple queue service) 및 lambda를 통해 조치를 트리거하여 성능 문제를 해결하는 자동화를 이용할 수 있다.
  • 프로덕션 환경에서 시뮬레이션을 통해 경보 솔루션이 문제를 인지하는지 테스트하는 “실전 연습”을 계획하면 좋다.

Tradeoffs

최적의 접근 방식을 선택할 수 있도록 tradeoffs을 고려해야 한다. 상황에 따라서 일관성, 내구성 및 공간을 위해 시간 또는 지연 시간을 희생함으로써 보다 고성능을 제공할 수 있다. Tradeoffs는 아키텍쳐의 복잡성을 증가시킬 수 있으며 측정 가능한 혜택이 달성되는지 확인하기 위한 load testing이 필요하다.

  • CloudFront로 몇 분 내에 전 세계의 여러 곳에 리소스를 배포하여 최종 사용자에게 가깝게 다가갈 수 있다.
  • RDS의 읽기 전용 복제본을 동적으로 추가하여 기본 데이터베이스의 부하를 줄일 수 있다.
  • ElastiCache로 메모리 데이터를 저장하거나 캐시를 제공한다.

Reference

AWS Well-Architected Framework 백서

Cost Optimization (비용 효율):

Design Prinicples:

비용을 업무/부서별로 투명하게

클라우드를 통하여 IT 비용을 개별 업무/부서별로 쉽게 나눌 수 있다. 보다 정교하게 투자 회수율를 측정할 수 있고 결과적으로 비용을 최적화할 수 있다.

비용 절감을 위하여 관리 서비스를 이용

대용량 메일 발송이나 데이터베이스를 관리하는 등의 운영 부담을 줄여 클라우드 스케일로 최적화한다.

CAPEX를 OPEX로 전환

  • 데이터센터 및 서버들에 대한 불투명한 투자보다는, 사용할 때 사용한 만큼한 지불하는 방식으로 전환하여 위험 요소를 낮추고 비용을 효과적으로 관리할 수 있다.
  • 개발/테스트 환경일 경우 사용되지 않는 시간에 리소스를 중단하여 비용을 절감할 수 있다.
  • 규모의 경제를 통한 혜택
  • 백만 이상의 고객들의 사용을 통하여 얻어지는 규모의 경제를 통하여 비용이 절감된다.

Definition:

Expenditure awareness (비용 인지)

데이터 전송을 최적화하도록 설계하고 (앱 설계, WAN 가속화, 다중 AZ, 리전 선택 등) 해당하는 경우 CloudFront (CDN)와 Direct Connect를 활용한다. 사용 항목 및 해당 비용을 모니터링하고 관리하고 적절하게 할당한다.

  • 모든 리소스에 태그 지정: 모든 태그 지정 가능 리소스에 태그를 지정하여 청구서의 변경 내용과 인프라 및 사용량의 변경 내용을 연결지을 수 있다.
  • 결제 및 비용 관리 도구 활용: Cost Explorer와 CloudWatch를 사용하여 정기적으로 사용량 및 지출을 모니터링하자.
  • 알림: 지출이 정의된 한도를 초과하는지 알 수 있다.
  • 자금 중심 과금 (charge back) / 확인 (show back) 방식: 비용 센터에 인스턴스와 리소스를 할당한다.

Cost-effective resources (비용 효율적인 자원)

  • 먼저 비용 절감을 위해 사용할 수 있는 서비스를 분석하고 확인한다.
  • 라이선스 비용에 대해 최적화한다.
  • 서버리스 및 컨테이너 기반 접근 방식을 사용하여 최적화한다.
  • 적절한 스토리지와 데이터베이스를 사용하여 최적화한다.
  • 다른 애플리케이션 수즌 서비스 (Simple Queue Service, Simple Notification Service, Simple Email Service) 를 사용하여 최적화한다.

Matching supply and demand (필요한 만큼만 사용)

  • 수용 기반 접근: Auto Scaling을 사용함으로써 변화하는 수요에 대응한다.
  • 버퍼 기반 접근: 작업을 버퍼링하여 (Kinesis or SQS) 작업을 처리하는 데 충분한 용량이 확보될 때까지 작업을 연기한다.
  • 시간 기반 접근: 주말 동안 개발 및 테스트 인스턴스 끄기, 이벤트, 분기 또는 연간 일정 기준 등등.

Optimizing over time (지속적인 최적화)

  • 새로운 서비스, 리소스 유형 및 크기를 검토하는 프로세스를 마련한다.
  • 성능 테스트를 다시 실행하여 비용이 절감되는지 평가한다.

Operational Excellence (운영 고도화)

Design Principles:

코드로 운영작업 수행

  • 공통적인 반복 프로세스 또는 절차가 있을 경우 자동화를 고려한다. 휴먼 에러를 줄일 수 있다.
  • 구성 관리, 변경 및 이벤트에 대한 응답 등등.

운영 프로세스를 비즈니스 목표에 맞게 조정

  • 비즈니스 목표를 달성하기 위한 모니터링 매트릭 설정 및 수집.
  • 신호 대 잡음 비율을 줄이기 위한 반복적인 노력이 필요하다.

정기적으로, 작게, 점진적으로 변경

  • 변경 작업은 큰 배치가 아닌 작은 단위로 수행해야 하며, 작업에 영향을 주지 않고 롤백할 수 있어야 한다.
  • 유지 보수 또는 서비스 구성요소의 교체를 위해 중단없이 변경사항을 적용할 수 있도록 운영 절차를 마련해야 한다.

예기치 않은 이벤트에 대한 대응 테스트

이벤트에 대응하는 절차를 테스트하고 이해하며, 실제 이벤트 발생 시 이를 준수하는 것이 중요하다.

Definition:

Preparation (준비)

운영 및 보안 체크리스트를 작성한다. Config, Service Catalog 등을 통해 리소스와 설정에 대한 인벤토리를 관리한다. 리소스 추적 (metadata 사용 및 tag 지정)과 아키텍처를 문서화한다. Wiki, 기술자료, 티켓 등을 이용할 수 있다. Auto Scaling 및 SQS 등을 통해 워크로드를 자동화한다.

Operations (운영)

자동화, 잦은 소규모 변경, 정기적 품질 보증 테스트, 변경 사항을 추적, 감사, 롤백 및 검토하기 위해 정의된 메커니즘에 초점을 맞추자

  • CI/CD 파이프라인 구축: CodeCommit, CodeDeploy, CodePipeline 사용 환경에 가해진 변경들을 추적하고 감시: CloudTrail 사용
  • Release 관리 프로세스
  • 소규모 중분식 변경
  • 롤백 가능
  • 위험 완화 전략 (Blue/Green, Canary, A/B testing 등등)

시스템은 내부 및/또는 외부 요인으로 인해 시간이 지남에 따라 성능이 저하될 수 있다. 따라서, 시스템 동작 모니터링을 통해 이러한 성능 저하 요소를 식별하고 수정할 수 있도록 한다.

  • 모니터링: CloudWatch
  • 로그 집계: application logs, CloudTrail, VPC Flow Logs
  • 경보 기반 알림: 측정치 안전 범위 밖이면 모니터링 시스템에서 자동 알림 받기
  • 트리거 기반 작업: 경보를 통해 자동으로 문제에 대한 조치를 취하거나 에스컬레이션 할 수 있도록

Responses (대응)

얘기치 못한 운영 이벤트에 대한 대응을 자동화할 준비를 한다. 여기에는 경보뿐만 아니라 완화, 수정, 롤백 및 복구도 포함된다.

  • 준수할 지침서 (대기 프로세스, 워크플로 체인, 에스컬레이션 프로세스 등등) 를 작성하고 업데이트 한다.
  • RCA 프로세스를 마련한다.

에스컬레이션이 발생할 경우 경보를 수신해야 할 이해관계자 및 시스템을 설정한다.

  • 우선순위, 영향 및 시간을 정한다.
  • Personal Health Dashboard: 계정별 aws 자원에 대한 맞춤형 대쉬보드, 서비스 이벤트 및 영향도 파악
  • Shield Advanced: 특수하고 다양한 DDoS 공격에 대한 지원 서비스
GitHubGitHubLinkedin