module 9(클라우드 아키텍처)

 

Summry

본 문서에서는 AWS Academy Cloud Foundations module 9(클라우드 아키텍처)를 정리한다.
서비스 별 기능과 개요에 대해 정리된 문서이므로 해당 서비스를 사용하기 위해선 AWS 가이드를 참조할 것

send me email if you have any questions.


AWS Well-Architected Framework

  • 아키텍처는 큰 구조물을 설계하고 구축하는 예술이자 과학이다. 대규모 시스템의 아키텍트는 시스템의 규모와 복잡성을 관리해야 한다.
  • AWS는 수많은 고객의 AWS 기반 아키텍처를 검토한 끝에 Well-Architected Framework를 개발했다. 아래 다섯 가지 원칙으로 구성되며 각 원칙에는 일련의 설계 원칙과 모범 사례가 포함되어 있다. 또한 Well-Architected 를 위한 체크리스트를 제공한다.
    • 운영 우수성
    • 보안
    • 안정성
    • 성능 효율성
    • 비용 최적화

1. 운영 우수성 원칙

  • 비즈니스 가치를 실현하고 지원 프로세스 및 절차를 지속적으로 개선하기 위해 시스템을 실행 및 모니터링 한다.

    그림1

  • 운영 우수성 설계 원칙

    그림2

    1. 코드로 작업을 수행하면 인적 오류를 제한하고 이벤트에 일관되게 응답할 수 있다.
    2. 빌드가 나올 때마다 주석이 추가된 설명서를 생성하는 작업을 자동화하는 데 중점을 둔다.
    3. 구성 요소의 주기적 업데이트가 가능하도록 워크로드를 설계해야 한다. 실패할 경우 되돌릴 수 있는 작은 단위로 변경을 수행한다.
    4. 운영 절차를 변경하면서 이러한 절차를 개선하고 업데이트할 기회를 모색한다. 가능한 실패 원인을 탐색하여 사전에 제거하거나 완화한다. 정기적으로 장애 시나리오를 테스트하고 이러한 장애의 영향을 이해하고 있는지 검증한다.
    5. 습득한 내용을 팀과 조직 전체에 공유한다.
  • 운영 우수성 체크리스트

    그림3


2. 보안 원칙

  • 위험 평가 및 완화 전략을 통해 비즈니스 가치를 제공하면서 정보, 시스템 및 자산을 보호한다.

    그림4

  • 보안 설계 원칙

    그림5

    1. 최소 권한의 원칙을 구현하고 AWS 리소스와의 각 상호 작용에 적절한 권한을 부여함으로써 직무 분리를 시행한다.
    2. 환경에서 수행되는 작업과 변경 사항에 대한 실시간 모니터링 알림 및 감사 기능을 사용, 로그와 지표를 시스템에 통합하여 자동으로 대응하고 조치를 취한다.
    3. 심층 방어를 적용하고 아키텍처의 모든 계층, 예를 들어 엣지 네트워크, 가상 사설 클라우드, 서브넷 및 로드 밸런서, 모든 인스턴스 운영체제 및 애플리케이션에 보안 제어를 적용한다.
    4. 보안 메커니즘을 자동화하여 확장 및 축소를 신속하고 경제적이며 안전하게 수행하는 기능을 개선한다.
    5. 데이터를 민감도에 따라 분류하고 암호화, 토큰화 및 액세스 제어와 같은 메커니즘을 적절히 사용한다.
    6. 인적 오류로 인해 민감한 데이터가 손실되거나 수정되는 위험을 줄여야 함. 데이터에 직접 액세스하거나 데이터를 수동으로 처리해야 하는 필요성을 줄이거나 없애는 메커니즘과 도구를 만든다.
    7. 조직의 요구 사항에 적합한 Incident(사건, 사고) 관리 프로세스를 마련할 것. Incident 대응 시뮬레이션을 실행하고 자동화를 포함한 도구를 사용하여 탐지, 조사 및 복구 속도를 높인다.
  • 보안 원칙 체크리스트

    그림6


3. 안정성 원칙

  • 장애를 예방하고 신속하게 복구하여 비즈니스 및 고객의 요구를 충족

    그림7

  • 안정성 원칙

    그림8

    1. 시스템 장애를 테스트하고 복구 절차를 검증한다.
    2. 시스템의 주요 성능 지표를 모니터링하고 임계값 위반 시 자동 복구를 트리거하도록 시스템을 구성한다.
    3. 단일의 대규모 리소스를 다수의 소규모 리소스로 대체하고 이러한 소규모 리소스에 요청을 분산하여 단일 지점의 장애가 전체 시스템에 미치는 영향을 줄인다.
    4. 수요 및 시스템 사용량을 모니터링하고 리소스 추가 또는 제거를 자동화하여 수요를 충족하는 최적의 수준을 유지한다.
    5. 자동화를 사용하여 인프라 변경을 수행하고 자동화를 통해 변경을 관리한다.
  • 안정성 원칙 체크리스트

    그림9


4. 성능 효율성 원칙

  • 컴퓨팅 리소스를 효율적으로 사용하여 시스템 요구 사항을 충족하고, 수요가 변하고 기술이 진화함에 따라 이러한 효율성을 유지한다.

    그림10

  • 성능 효율성 설계 원칙

    그림11

    1. 기술을 서비스로 소비한다. 예를 들어 SQL Database, 미디어 트랜스코딩, 머신 러닝과 같은 기술은 기술 커뮤니티에서 쉽게 찾을 수 없는 전문성이 요구되는 기술이다. 클라우드에서는 이러한 기술을 서비스로 사용할 수 있다. 기술을 소비함으로써 팀은 리소스 프로비저닝 및 관리 대신 제품 개발에 집중할 수 있다.
    2. 여러 AWS 리전에 시스템을 배포하여 지연 시간을 줄이고 최소한의 비용으로 고객 경험을 선사한다.
    3. 서버 실행 및 유지 관리로 인한 운영 부담 없이 기존의 컴퓨팅 활동을 수행할 수 있다. 관리형 서비스는 대규모로 운영되기 때문에 서버리스 아키텍처에서는 트랜잭션 비용도 절감된다.
    4. 다양한 유형의 인스턴스, 스토리지 또는 구성을 비교하는 테스트를 수행한다.
    5. 달성하려는 목표에 가장 적합한 기술 접근 방식을 사용한다. 예를 들어 데이터베이스 또는 스토리지에 대한 접근 방식을 선택할 때는 데이터 액세스 패턴을 고려한다.
  • 성능 효율성 체크리스트

    그림12


5. 비용 최적화 원칙

  • 가장 낮은 가격으로 비즈니스 가치를 제공하도록 시스템을 실행한다.

    그림13

  • 비용 최적화 설계 원칙

    그림14

    1. 필요한 컴퓨팅 리소스에 대해서만 비용을 지불한다. 정교한 예측을 사용하는 대신 비즈니스 요구 사항에 따라 사용량을 늘리거나 줄인다.
    2. 워크로드의 비즈니스 결과를 측정하고 이 결과를 실현하는 것과 관련된 비용을 측정한다. 이 측정을 사용하여 결과를 늘리고 비용을 줄여 얻을 수 있는 이점을 파악한다.
    3. AWS는 서버를 랙에 설치하고, 스태킹하고 전원을 공급하는 등의 작업 부담을 덜어준다. 따라서 IT 인프라가 아니라 고객과 비즈니스 프로젝트에 집중할 수 있다.
    4. 클라우드에서는 시스템 사용량과 비용을 쉽고 정확하게 파악하고 IT 비용을 개별 워크로드 사용자에게 알릴 수 있다. 이 기능을 사용하면 투자 수익률을 측정하고 워크로드 소유자에게 리소스를 최적화하고 비용을 줄일 수 있는 기회를 제공할 수 있다.
    5. 클라우드에서 관리형 및 애플리케이션 수준 서비스는 이메일 전송이나 데이터베이스 관리 등의 작업을 위해 서버를 유지 관리해야하는 운영상의 부담을 해소해준다. 관리형 서비스는 클라우드 규모에서 운영되기 때문에 클라우드 서비스 공급자가 더 저렴한 트랜잭션 또는 서비스당 비용을 제공할 수 있다.
  • 비용 최적화 체크리스트

    그림15


안정성 및 가용성

  • AWS Well-Architected Framework에서 제시하는 모범 사례 중 하나는 장애 즉, 애플리케이션/워크로드 중지에 대비한 계획을 수립하는 것이다.
    • 클라우드 아키텍트가 장애를 견디도록 아키텍처를 설계할 때 고려하는 두 가지 중요한 요소는 안정성과 가용성이다.

안정성

그림16

  • 모든 것에서 항상 장애가 발생할 수 밖에 없으므로 통계적 방식으로 안정성을 생각해야 한다.
  • 안정성 지표 이해

    그림17

    • 월요일 정오에 온라인 상태로 전환되는 애플리케이션이 있고 정상 작동하다가 금요일 정오에 장애가 발생한다. 금요일 정오부터 월요일 정오까지 애플리케이션에서 장애가 발생한 이유를 진단하여 복구한다.
      • 평균 장애 시간(MTTF) 또는 애플리케이션을 사용할 수 있는 시간은 96시간
      • 평균 복구 시간(MTTR)은 72시간
      • 평균 장애 간격(MTBF)은 168시간 또는 1주일.

가용성

그림18

  • 시스템 구성 요소의 장애는 시스템 가용성에 영향을 미친다.
    • 예정된 중단과 예정되지 않은 중단을 포함하여 애플리케이션이 정상적으로 작동하지 않을 때마다 가용성이 저하된다.
  • 일반적으로 가용성을 개선하면 비용이 증가한다.
    • 환경의 가용성을 높일 방법을 고려할 때는 개선 비용과 사용자에게 돌아가는 혜택 간에 균형을 맞추는 것이 중요하다.
  • 가용성 계층

    그림19

  • 가용성에 영향을 미치는 요인

    그림20

고가용성

그림21

  • 고가용성 시스템이란 성능이 어느 정도 저하되더라도 시스템이 사용 가능한 상태로 유지되는 시스템을 말한다.
    • 고가용성 시스템에서는 가동 중지 시간이 최소화되고 사람의 개입이 거의 필요하지 않는다.
    • 고가용성 시스템은 서로 유기적으로 작동하면서 필수 서비스를 보장하는 시스템 전체의 공유 리소스 집합이라고 할 수 있다.

AWS Trust Advisor

  • AWS에서 아키텍처를 설계하고 검토하는 데 사용할 수 있는 도구

    그림22

    1. Cost Optimization - 리소스 사용량을 분석하고 사용하지 않는 유휴 리소스를 제거하거나 예약 용량을 약정하여 비용을 최적화할 수 있도록 권장 사항을 제시
    2. Performance - 서비스 제한을 점검하고 프로비저닝된 처리량을 확인하며 초과 사용되는 인스턴스를 모니터링하여 서비스 성능을 개선하는 권장 사항을 제시할 수 있다.
    3. Security - 기능 공백 및 활성화가 필요한 다양한 AWS 보안 기능을 식별하여 애플리케이션의 보안을 개선하는 데 도움이 되는 권장 사항을 제기한다. 사용자의 권한도 검사한다.
    4. Fault Tolerance(내결함성) - 자동 조정, 상태 확인, 다중 AZ 배포 및 백업 기능을 활용하여 AWS 애플리케이션의 가용성과 이중화를 개선할 수 있는 권장 사항을 제시한다.
    5. Service Limits - 서비스 제한의 80%가 넘는 서비스 사용량이 있는지 점검한다. 값은 스냅샷을 기반으로 하므로 현재 사용량과 다를 수 있다. 제한 및 사용량 데이터의 변경 사항이 반영되는 데 최대 24시간이 걸릴 수 있다.