Well-Architected Framework

목적

• 고 수준의 가이드

• 베스트 프랙티스

• Optimal

  고객의 요구사항을 극대화 할 수 있는 Architect

:star: Category

• 운영 우수성(운영 고도화)

  운영중인 시스템을 모니터링, 지원 체계를 끊임없이 개선

• 보안

  클라우드 상의 데이터 및 자산을 안전하게 보호

• 안정성

  장애, 업무 증가 및 기타 이벤트에 능동적으로 대처

• 성능 효율성

  시스템 리소스들이 최적의 성능을 냄

• 비용 최적화

  비용을 줄이는 방법

보안

디자인 원칙

• 강력한 신원 기반 구현

  콘솔에 접근하기 위한 보안 제어

  최소 권한 원칙

• 추적 로그 설정

  모든 변경 사항 로깅 및 감사

• 모든 계층에 보안 적용

• 보안 모범 사례 자동 적용

  최적화된 이미지 사용, 인프라 버전 관리 템플릿 정의

• 전송 중 및 유휴 시 데이터 보호

  민감도 수준 데이터 분류

• 사람의 실수 미연 방지

  데이터 직접 액세스 및 수동 처리 최소화

• 보안 이벤트 대비

책임 공유 모델

• IaaS 부분만 보안 책임

IAM

1. ID 및 액세스 관리

   • AWS Account Owner(루트 계정)
     • 모든 서비스 접근
     • 빌링 접근
   • AWS IAM Users, Groups, Role
     • 특정 서비스 접근
   • Temporary Security Credentials
     • 고객 지원 접근 :x:

2. 탐지 제어

   CloudTrail

   AWS 모든 흔적을 남김

   • 누가 언제 어떤 어떤 리소스가 어디서 API 호출이 이루어졌는지

   AWS Config

   AWS 리소스의 변경 사항 추적, 감사

   GuardDuty

   IDC

   특이한 API 호출 또는 계정 침해의 가능성을 나타내는 잠재적 모니터링

   • 람다로 detect

3. 인프라 보호

   :shield: 네트워크 및 호스트 보호 :arrow_right: 디도스 방어

   AWS Shield standard

   • Layer 3, 4 보호
   • 무료
   • 자동 탐지 및 대응
   • 가장 흔한 공귝 방어
   • AWS 서비스에 밀결합

   Layer 7은 커스터머가 직접 해야 함

   AWS Shield Advanced

   • L3, L4, L7 layer 디도스 방어

   • 리포팅 제공

   • DDosS 대응 팀 연계

   • AWS 청구 보호

     해킹당했을 때 가격 보호

   :shield: 네트워크 및 호스트 보호 :arrow_right: VPC

   • 다른 환경이나 프로젝트에서 각각 분리된 VPC 사용 권장
   • Stateful 방화벽 보안 그룹에서 역할 기반 보안 정의 권장
   • 어떤 구성 요소만 퍼블릭으로 설정할 것인지

   :shield: 보안 그룹

   • allow만 지원

   :shield: NACL

   • 인바운드, 아웃바운드 모두 설정 필수 (Stateless)
   • 특정 서브넷에서 접근 원천 봉쇄 가능

   :shield: VPC Flog logs

   • 별보 에이전트 없이 ENI, 서브넷, VPC 별로 로깅 가능
   • CloudWatch logs에 기록
   • 위에 보안그룹과 NACL이 복잡하기 때문

   :shield: Inspector

   • 앱의 취약점 점검 및 규정 준수를 자동화
   • CVE, CIS, …

   :shield: System manager(무료)

   • 소프트웨어 인벤토리 자동 수집, OS 패치 관리, 운영 체제 구성을 도와주는 System Manager를 통해 시스템 구성 정의, 추적, 유지 권장(SSM Agent 설치)
   • 특정 시스템이 어느 시점에 도달하면 실행
   • 형상 관리 솔루션
   • 배포, 구성 및 원격관리
     • 스테이트 매니저
   • 공유 기능
     • 유지 관리 기간
     • 파라미터 스토어

4. 데이터 보호

   • 전송 중, 유휴 데이터 암호화

   • KMS를 활용한 키 관리

     • EBS, S3등 암호화 관리

   • ACM을 통해 SSL/TSL 인증서 배포 및 관리

     AWS 내부 리소스에 사용할 공인 및 사설 SSL 인증서를 무료 배포, 자동된 관리 및 갱신 지원 ACM 활용 권장

     • AWS가 발행하는 인증서

       ACM이 있으면 LB -> EC2 인증서 발급

       CloudFront, API Gateway, S3, LB 등등 인증서 발급

       무료

     • 인증 서 만료 시 자동 리프레쉬

5. 사고 대응

   • 보안 사고의 잠재적 영향 대응 및 완화 위한 프로세스 마련 필수

   • 사고 발생 격리, 원인 분석 수행 :arrow_right: 운영 환경 영향 최소화 아키텍처

     • 도구, 액세스 권한 필요

     • 자동화

       이상 감지 시 자동으로 스냅샷

       IDC의 경우 네트워크 선을 뽑아야 함

   • CloudFormation 템플릿

     순간적으로 다시 만들 수 있음

안정성

• 복구 절차 반드시 테스트
• 자동 복구 구성
• 수평 확장 가능 구성
  • 수직 확장 시 시스템을 죽여야 함
• 시스템 용량 예측 :x:
• 변경 관리 자동화
• 9’s
  • 가용 의존성에 대한 가용성 계산
  • 중복된 구성요소에 대한 경성 계산

오토 스케이리링

• Route 53: 어떤 경우에도 죽지 않음
• CloudFront: 웹서버에 대한 Ddos를 막아줌

기본 요건

• AWS limit을 파악해야 함
  • Trusted Advisor, CloudWatch로 관리
• 네트워크 토폴로지 계획
  • 추가할 수 있지만, 변경할 수 없음
  • 안정성 확보

변경 관리

• 시스템 메니저 사용해서 변경 관리

  • Auto Scaling, cloud Watch, Load Balancing

• 모니터링 (Cloud Watch)

• 변경 관리 수행

  CloudFormation, CodePipeline, CodeDeploy

  소스 > 빌드 > 테스트 > 프로덕션

  CodeStar로 코드 시리즈를 제공

• 거버넌스 자동화

  DevOps -> S3 -> CodePipeline

장애 관리

• 죽을 것을 관리 하고 장애 조치
• SDKs, Load Balancing, SQS
  • 서버가 죽었을 때, SQS를 통해 Queue 저장
  • 그레이스풀 그레이드: 항상 서버가 돌아갈 수 있도록 조금 부족하더라도 자동으로 서버를 띄울 수 있도록

성능 효율성

• 최신 서비스 채택

• 즉시적 글로벌 서비스

  가까운 리전

• 서버리스 아키텍처 사용

  서버 운영 부담, 확장성, 가용성 걱정 없이 완전 관리형 서비스를 이용해 쉽게 웹 호스팅 또는 API 제작

• 더 자주 새로운 아이디어 실험

• 적절한 기술 접근법 사용

  종류에 맞는 것 사용

선택 - 컴퓨팅

• EC2
  • VM, H/W
• ECS
  • Task, OS
• Lambda
  • Run-time

핵심: Auto Scaling

선택 - 스토리지

• EBS
  • 마운트 해서 쓰는 것(block)
• EFS
  • Multiple, Many clients
• S3, Glacier
  • Web scale, Many clients

선택 - 데이터베이스

• RDS
  • 관계형 db
• DynamoDB
• ElasticCache
• Redshift

선택 - 네트워크

• 100 Gbps

검토 - 벤치마킹

검토 - 부하 테스트

모니터링 - 단계

성능 지표를 봐야 함 :exclamation: Cloudwatch

1. 생성
2. 집계
3. 실시간 처리 및 알람
4. 저장
5. 분석

트레이드오프 - 설명

어떤 하나가 좋아지면 다른 것은 나빠짐

비용 최적화

• 데이터 센터 운영에 필요한 비용 제거
• 소비 모델 채택
  • 다양한 소비 모델
• 전체 효율 측정
• 비용 분석 및 부과
  • 실제 쓸 사람이 맞는가
• 관리형 서비스를 사용하여 소유 비용 절감
  • 기존 보다 RDS가 1.5배 비쌈

전략

• Right Architecture
• Right Service
• Right Size
• Right Cost Model
• 장기 계약

Savings Plans(SP)

컴퓨팅 파워를 삼

• RI: Reserve Instance
  • 환불 불가
  • 인스턴스 단위
• 사용하지 않는 리스소스 제거
• 개발/테스트 환경의 인스턴스 끄기
• 작은 인스턴스로 구성

운영 우수성

• 코드를 통한 운영
• 문서 주석
• 변경을 작게, 자주, 원복 가능하도록
• 운영 절차를 수시로 개선
• 실패 예측
  • 프리모뎀 실행 -> 잠재 장애 요인 찾기
  • 게임데이 실행
• 모든 운영 실패를 통한 개선

준비, 운영, 진화

준비

• 운영 업무 설게 시 비즈니스 목표 반영
  • 비즈니스 목표 사업, 개발, 운영 팀 모두와 공유
  • 모니터링을 기반으로 하는 표준화된 운영 업무 설계
• 운영 평가 체계
  • 특정되지 않는 건 개선 :x:
  • 표준 준수 체크, 평가 체계 필요
  • Runbook 루틴하는 것에 대한 표시법(?), Playbook
• 운영업무를 코드화하고 모니터링하기
  • 코드 기반 템플릿

운영

• 측정 지표
  • 인프라 추상화
  • 배포, 인시던트 대응
• 운영 이벤트 관리
  • 한 눈에 확인할 수 있는 대시보드
• 문제에 대한 근본원인 확인
  • 근본원인 확인을 통해 이벤트 재발행 감소, 다른 팀들과 공유

진화

• 업무 사이클 준비
  • 피드백 루프
  • 정기적 개선 기회 평가, 우선 순위
• Lessone Learned, 다른 팀과 공유
• 배포 활동의 결과 활용한 개선 기회
  • 배포가 다른 활동에 영향을 줄 때

Cloud Adopted Application

• 자체 복구를 위한 디자인
• 모두 중복으로 구성
• 조정 최소화
• 규모 확장을 위한 디자인
• 한도에 맞춘 분할
• 운영을 위한 디자인
• 관리되는 서비스 사용
• 작업에 가장 적합한 데이터 저장소 사용
• 진화를 위한 디자인
• 비즈니스 요구 사항에 맞게 구축

• Web Server
  • Proxy
    • 나갈 때
  • reverse proxy
    • 들어 올 때