Well-Architected Framework

Well-Architected Framework는 워크로드를 여러 관점에서 점검하고 개선할 질문을 제공한다. 여섯 필러는 체크리스트로 끝나는 별도 영역이 아니라, 같은 설계 결정을 운영·보안·복원력·성능·비용·지속가능성 측면에서 다시 살펴보게 한다. 이 글에서는 각 필러가 어떤 문제를 드러내는지와 리뷰 후 실제 개선으로 옮기는 방법을 정리한다.

1. Well-Architected Framework 개요

6가지 필러

1. 운영 우수성 (Operational Excellence)
2. 보안 (Security)
3. 안정성 (Reliability)
4. 성능 효율성 (Performance Efficiency)
5. 비용 최적화 (Cost Optimization)
6. 지속 가능성 (Sustainability)

Well-Architected Tool

AWS 콘솔 → Well-Architected Tool
  → 워크로드 등록
  → 필러별 질문에 답변
  → 위험 항목 식별 (High Risk, Medium Risk)
  → 개선 계획 수립
  → 마일스톤 저장 (시간에 따른 개선 추적)

일반 설계 원칙

필요한 만큼만 프로비저닝      — 실제 사용량 기반, 낭비 제거
프로덕션 규모 테스트          — 작은 환경 테스트는 함정
자동화로 실험 용이화          — 인프라를 코드로, 반복 가능하게
아키텍처 발전 허용            — 빅뱅 설계 대신 지속 개선
데이터 기반 결정              — 추측이 아닌 지표·로그로 판단
게임 데이로 개선              — 장애 시뮬레이션으로 약점 발견

2. 운영 우수성 (Operational Excellence)

목표: 비즈니스 가치를 제공하고 운영 프로세스를 지속적으로 개선한다.

설계 원칙

코드로 운영 수행 (Operations as Code)
  → CloudFormation, CDK로 인프라 정의
  → 수동 작업 최소화, 재현 가능성 확보

빈번하고 작은 변경
  → 작은 단위 배포 → 문제 발생 시 빠른 원인 파악
  → 카나리 배포, Blue/Green으로 위험 최소화

실패 예상 및 대비
  → Chaos Engineering (카오스 엔지니어링)
  → GameDay: 의도적 장애 시뮬레이션
  → Runbook: 장애 대응 절차 문서화

운영 절차의 지속적 개선
  → 장애 후 무결점 포스트모템(Blameless Post-Mortem)
  → 재발 방지 자동화

핵심 서비스

안티패턴

피할 패턴: 콘솔에서 수동으로 리소스 변경 (드리프트 발생)
피할 패턴: 대규모 일괄 배포 (문제 발생 시 롤백 어려움)
피할 패턴: 장애 대응 절차 문서화 안 함
피할 패턴: 알람은 있지만 대응 자동화 없음

주요 패턴

[배포 안전성]
CodePipeline → CodeBuild (테스트)
  → CodeDeploy (카나리 배포)
    → CloudWatch 알람 (오류율 급증 탐지)
      → 자동 롤백

[운영 자동화]
CloudWatch 알람 → SNS → Lambda
  → Systems Manager Automation
    → 자동 수정 (재시작, 스케일링, 격리)

3. 보안 (Security)

목표: 데이터, 시스템, 자산을 보호하면서 비즈니스 가치를 제공한다.

설계 원칙

강력한 자격 증명 기반 구현
  → 최소 권한 원칙 (Least Privilege)
  → MFA 강제, 루트 계정 미사용
  → 임시 자격 증명 (IAM 역할)

추적 가능성 활성화
  → CloudTrail, Config, CloudWatch Logs
  → 모든 API 호출 기록

모든 계층에서 보안 적용 (Defense in Depth)
  → 엣지: CloudFront + WAF
  → 네트워크: VPC, 보안 그룹, NACLs
  → 컴퓨팅: IAM 역할, Systems Manager
  → 데이터: 암호화 (저장·전송)

보안 이벤트 대비
  → GuardDuty, Security Hub
  → 자동 격리·대응 플레이북
  → 보안 계정 격리 (폭발 반경 제한)

데이터 보호
  → 저장 데이터: KMS 암호화
  → 전송 데이터: TLS
  → 중요 데이터: Secrets Manager

핵심 서비스

안티패턴

피할 패턴: 장기 액세스 키 사용 (대신 IAM 역할)
피할 패턴: 과도한 권한 부여 (AdministratorAccess 남용)
피할 패턴: 암호화 없는 S3 버킷, EBS 볼륨
피할 패턴: 공개 S3 버킷으로 데이터 배포
피할 패턴: 보안 그룹 0.0.0.0/0 인바운드 허용
피할 패턴: 루트 계정으로 일상 작업

공유 책임 모델

AWS 책임 (Security OF the Cloud)
  → 물리적 데이터센터, 하드웨어
  → 하이퍼바이저, 네트워크 인프라
  → 관리형 서비스 (S3, DynamoDB 등)의 기반 인프라

고객 책임 (Security IN the Cloud)
  → 운영 체제, 네트워크 설정 (EC2)
  → 애플리케이션 코드
  → 데이터 암호화·분류
  → IAM 계정·권한 관리

4. 안정성 (Reliability)

목표: 워크로드가 의도한 기능을 올바르게, 기대한 시점에 수행하는 능력.

설계 원칙

복구 절차 테스트
  → DR 훈련을 정기적으로 실행
  → 실제로 복원해보지 않은 백업은 백업이 아님

복구 자동화
  → 사람 개입 없이 자동 감지·복구
  → Auto Scaling, Multi-AZ 자동 페일오버

수평 확장 (Horizontal Scaling)
  → 단일 대형 서버 대신 여러 소형 서버
  → 단일 장애점(SPOF) 제거

용량 추측 제거
  → Auto Scaling으로 수요에 자동 대응
  → 과도 프로비저닝·부족 프로비저닝 모두 제거

변경 사항 자동화 관리
  → IaC로 인프라 변경 추적
  → 수동 변경으로 인한 드리프트 방지

핵심 서비스

안정성 설계 패턴

단일 장애점 제거

피할 패턴: 단일 EC2 인스턴스
권장 패턴: Auto Scaling + Multi-AZ + ALB

피할 패턴: 단일 AZ RDS
권장 패턴: RDS Multi-AZ (자동 페일오버)

피할 패턴: 단일 리전
권장 패턴: 멀티 리전 + Route 53 장애 조치

서킷 브레이커 패턴

의존 서비스 장애 시 요청 차단
  → 장애 전파 방지
  → 일정 시간 후 재시도 (Half-Open 상태)

벌크헤드 패턴

서비스를 격리된 파티션으로 분리
  → 한 파티션 장애가 다른 파티션에 영향 없음
  → SQS 큐 분리, Lambda Reserved Concurrency

안티패턴

피할 패턴: 단일 AZ 배포
피할 패턴: 고정 용량 (Auto Scaling 미사용)
피할 패턴: 동기 강결합 (서비스 간 직접 HTTP 호출)
피할 패턴: 백업 없는 상태저장 서비스
피할 패턴: 테스트하지 않은 DR 계획

5. 성능 효율성 (Performance Efficiency)

목표: 요구사항을 충족하기 위해 컴퓨팅 리소스를 효율적으로 사용하고 수요 변화에 맞게 효율성을 유지한다.

설계 원칙

최신 기술의 민주화
  → 관리형 서비스 활용 (RDS, ElastiCache 등)
  → 복잡한 기술을 직접 구현 대신 서비스로 소비

글로벌 배포 (몇 분 내)
  → CloudFormation으로 전 세계 동일 환경 복제
  → CloudFront로 엣지 캐싱

서버리스 아키텍처 사용
  → Lambda, Fargate로 서버 관리 부담 제거

더 자주 실험
  → 다양한 인스턴스 유형 비교 테스트
  → 새 기능을 빠르게 시도하고 최적 선택

기계적 공감 (Mechanical Sympathy)
  → 사용 패턴에 맞는 서비스 선택
  → 읽기 많음 → ElastiCache / 쓰기 많음 → DynamoDB

핵심 서비스

성능 선택 기준

컴퓨팅

범용: m 계열 (m7g, m6i)
CPU 집약: c 계열 (c7g, c6i)
메모리 집약: r 계열 (r7g, r6i)
GPU: p 계열 (p4d), g 계열 (g5)
고성능 네트워킹: 향상된 네트워킹 (ENA)
고성능 스토리지: 로컬 NVMe SSD (i3, i4i)

DB 캐싱

자주 읽는 데이터:
  ElastiCache (Redis/Memcached) 앞단 배치
  → DB 부하 90% 감소, 응답 ms 단위

세션 저장:
  ElastiCache Redis → stateless 앱 구현

읽기 복제본:
  RDS 읽기 복제본 → 읽기 쿼리 분산

안티패턴

피할 패턴: 과도 프로비저닝 (m5.4xlarge가 CPU 5% 사용)
피할 패턴: DB 직접 전체 스캔 (인덱스 미사용)
피할 패턴: 캐싱 없이 동일 쿼리 반복
피할 패턴: 단일 리전에서 글로벌 사용자 서비스

6. 비용 최적화 (Cost Optimization)

목표: 불필요한 비용을 피하면서 비즈니스 가치를 달성한다.

설계 원칙

클라우드 재무 관리 구현
  → 비용 책임자 지정, 팀별 예산 배분
  → 태그로 비용 배분

소비 모델 채택
  → 사용한 만큼만 지불
  → 예측 가능한 워크로드 → RI/Savings Plans

전체 효율성 측정
  → 단순 비용이 아닌 비용/산출 비율
  → 수익당 인프라 비용 추적

차별화되지 않는 무거운 짐 제거
  → 관리형 서비스로 운영 부담 제거
  → 핵심 비즈니스 로직에 집중

비용 분석
  → Cost Explorer로 지속적 모니터링
  → 미사용 리소스 정기 정리

(16편에서 상세 다룸 — 여기서는 원칙 중심)

7. 지속 가능성 (Sustainability)

목표: 클라우드 워크로드의 환경 영향을 최소화한다. (2021년 6번째 필러로 추가)

설계 원칙

영향 이해
  → 워크로드의 탄소 발자국 측정
  → AWS Customer Carbon Footprint Tool 활용

지속 가능성 목표 수립
  → 에너지 효율 KPI 정의
  → 단위 작업당 에너지 사용량 추적

활용률 최대화
  → 유휴 리소스 제거 (과도 프로비저닝 줄이기)
  → Auto Scaling, Savings Plans으로 효율 최적화

더 효율적인 하드웨어 사용
  → Graviton 프로세서 (ARM 기반, 에너지 효율 높음)
  → 최신 인스턴스 세대 사용

관리형 서비스 사용
  → AWS가 공유 인프라를 최적 효율로 운영
  → 사용자가 직접 운영하는 것보다 탄소 효율 높음

클라우드 스토리지 최적화
  → 필요 없는 데이터 삭제
  → 콜드 데이터 Glacier로 이동
  → 중복 데이터 제거

핵심 서비스

Graviton 프로세서

AWS 자체 설계 ARM 기반 칩
  → 동급 x86 대비 성능 40% 향상
  → 에너지 소비 60% 감소
  → 비용 20% 절감
지원: EC2, Lambda, RDS, ElastiCache, ECS/EKS 등

8. 필러 간 트레이드오프

Well-Architected의 핵심은 필러 간 균형이다. 하나의 필러를 최적화하면 다른 필러에 영향이 생긴다.

SAP 시험 접근법:
  문제에서 제시된 우선순위를 파악
  → "비용 효율적인" → 비용 최적화 우선
  → "다운타임 불가" → 안정성 우선
  → "보안 규정 준수" → 보안 우선
  → 이 조건에서 다른 필러도 최대한 충족하는 답 선택

9. Well-Architected 리뷰 프로세스

1. 워크로드 정의
   → 경계 명확히 (마이크로서비스별, 시스템별)

2. WAF Tool에서 질문 답변
   → 필러별 수십 개 질문
   → 현재 상태 정직하게 답변

3. 위험 항목 우선순위 결정
   → High Risk (빨강): 즉시 개선 필요
   → Medium Risk (노랑): 계획적 개선

4. 개선 계획 수립·실행
   → 각 위험별 개선 조치 정의
   → 담당자·기한 지정

5. 마일스톤 저장 → 재검토
   → 개선 후 재평가로 진행 추적
   → 분기·반기 주기 권고

10. 핵심 암기 포인트

핵심 내용을 다시 정리하면

• 운영 우수성: 코드로 운영, 작은 변경, 장애 대비·자동화
• 보안: 최소 권한, 다층 방어, 암호화, 공유 책임 모델
• 안정성: 자동 복구, 수평 확장, SPOF 제거, DR 테스트
• 성능: 관리형 서비스, 캐싱, 글로벌 배포, 올바른 서비스 선택
• 비용: 소비 모델, RI/SP, 지속적 분석·최적화
• 지속 가능성: Graviton, 서버리스, 활용률 최대화, 탄소 발자국 추적
• 트레이드오프: 필러 간 균형, 시험에서 우선순위 파악이 핵심

이어 읽기: 20. AWS SAP 시나리오 빠른 복습