AWS 비용 최적화 바이블.md

• 예전에는 주로 EC2 인스턴스의 CPU를 얼마나 사용했는지 자랑했다면 지금은 서버리스 아키텍처를 통해 얼마나 저렴하고 빠르게 동일한 처리를 해내고 있는지 이야기함
• AWS 비용 관리를 컴퓨팅, 스토리지, 네트워크, 애플리케이션, 운영 관점에서 다루고 있음
• 핀옵스가 무엇인지, 어떤 서비스를 어떻게 운영해야 하며 어떤 부분에서 비용을 좀 더 절감할 수 있는지 등 각 서비스를 비교하고, 그 비결을 간접적으로 독자에게 전달함
• 저자가 만든 KAOtm이라는 방법론을 바탕으로 지식, 구조, 운영 세 가지를 중점적으로 알아보며, AWS 구성 요소와 요금제를 이해함
• 비즈니스가 클라우드로 전환되면서 보안 위험에 노출되지 않도록 해야 했고 데이터 보호, 컴플라이언스(법, 명령 등의 준수), 규정 등과 관련된 과제를 해결해야 했음
• 클라우드 컴퓨팅의 비용은 새로운 사용량 기반의 요금제, 새로운 소비 모델, 새로운 운영 방법론, 새로운 추적 및 리포팅 시스템 등과 관련 있음

KAO_tm 방법론

• KAO_tm
  • 지식(Knowledge)
    • AWS 서비스 비용 최적화의 시작은 서비스의 구성 요소와 요금제를 이해하는 것
    • 활용 사례에 적용할 수 있는 대체 서비스를 이해하는 것도 중요
  • 구조(Architecture)
    • 결국에는 클라우드 아키텍트가 클라우드 환경을 구성하고 배포하는 방법을 안내함
    • AWS에서 어떤 서비스를 어느 리전에서 사용할 것인지, 보안 네트워크를 어떻게 구성하는지, 각 구성 요소가 다른 구성 요소와 상호 작용하는지 등을 의미함
  • 운영(Operation)
    • 지속적인 모니터링과 추적, 최적화가 필요함
    • 관련 지식과 구조적 이해가 뒷받침되는 지속적인 운영 작업 없이는 비용 최적화를 이룰 수 없음

컴퓨팅 서비스

• AWS EC2 : 종량제 방식으로 제공되는 아마존의 크기 조정과 확장 및 축소가 가능한 컴퓨팅 서비스
• AWS 람다 : AWS를 사용하면 기본 인프라를 프로비저닝하거나 운영할 필요 없이 서버리스 모드에서 코드를 실행할 수 있음. 애프릴케이션을 업로드하거나 미리 정의된 서버리스 애플리케이션 리포지토리에서 함수를 선택하고 실행을 트리거할 이벤트를 정의하면 됨. 트리거 이벤트가 발생하면 AWS가 함수 실행을 관리함
• AWS 배치 : 배치 작업을 실행하기 위한 관리형 서비스. 작업을 업로드하고 리소스 요구 사항을 정의하면 됨. AWS가 작업 예약과 실행은 물론 기본 인프라의 프로비저닝 및 운여을 처리함
• 아마존 EC2
  • EC2 특성
    • 인스턴스 제품군과 유형
      • 범용, 컴퓨팅 최적화, 메모리 최적화, 스토리지 최적화 및 가속 컴퓨팅
      • 일반적인 용도로 설계된 M형(범용 인스턴스 제품군), 컴퓨팅 집약적인 워크로드 용도로 설계된 C형(컴퓨팅 최적화 인스턴스 제품군), 고성능 그래픽 처리를 위해 GPU 카드로 구동되는 G형(가속 컴퓨팅 인스턴스 제품군) 등이 있음
  • 아마존 EC2 요금제
    • 사용 기간
      • EC2 온디맨드 인스턴스 요금이라 하며 계정 내에서 실행 중인 인스턴스에 대해서만 요금이 청구됨
    • 동일한 유형 내 인스턴스 크기별 가격
      • 일반적으로 인스턴스 크기가 커질 때마다 (예를 들면 large에서 xlarge로) 프로비저닝된 리소스양(예를 들면 vCPU 수, 메모리양, 스토리지양)이 두 배로 증가함
    • 동일 유형 내 인스턴스 세대별 가격
    • 인스턴스 유형별 가격
    • AWS 리전과 로컬 영역
      • 미국 동부 지역이 가장 저렴함. 가격은 유럽과 아시아 태평양, 또는 남아메리카 쪽으로 이동할수록 상승함
    • 테넌시: 공유 호스트와 전용 호스트 그리고 베어 메탈
      • 공유 테넌시에서는 여러 사용자가 동일한 물리 호스트에서 제공하는 컴퓨팅 리소스를 사용할 수 있음
      • 전용 호스트 및 베어 메탈 인스턴스는 호스트의 모든 리소스가 프로비저닝되며 한 번에 하나의 클라우드 계정에서만 사용됨
    • CPU 인스턴스 최적화
    • 일래스틱 그래픽
    • 일래스틱 추론
      • 일래스틱 추론을 사용하면 모든 EC2 및 세이지메이커 인스턴스 또는 아마존 ECS 작업에 GPU 기반 과속을 연결하여 딥러닝 추론을 실행할 수 있음
    • EC2 구매 옵션
      • 온디맨드 인스턴스 : 온디맨드는 EC2 인스턴스를 구매하는 기본 방법
      • 예약 인스턴스(RI) : 12개월 또는 36개월 동안 예약된 용량에 대한 비용을 지불하는 대신 EC2 온디맨드 가격에서 최대 72% 할인된 가격으로 제공되는 EC2 인스턴스
      • 세이빙 플랜 : 12개월 또는 36개월 동안 약정된 지출(시간당 달러)을 대가로 EC2 온디맨드 가격에서 최대 72% 할인을 제공함
      • 온디맨드 용량 예약 : EC2 인스턴스의 용량을 일정 기간 동안 특정 가용 영역에서 예약할 수 있음
      • 스팟 인스턴스 : 아마존 EC2 스팟 인스턴스를 사용하면 EC2 온디맨드 가격에 비해 최대 90% 할인된 가격으로 아마존의 여유 EC2 용량을 활용할 수 있음
• 아마존 EC2 구매 옵션
  • 예약 인스턴스
    • 예약 조건
      • 리전 또는 가용 영역
      • 인스턴스 유형
      • 인스턴스 플랫폼
      • 인스턴스 테넌시
      • 예약 기간
      • 적용 범위
      • 결제 옵션
    • 예약 인스턴스 마켓플레이스
      • 마켓플레이스를 활용하여 약정 기간이 12개월 미만인 예약을 구매할 수 있음. 경우에 따라 예약 인스턴스의 비용보다 훨씬 저렴한 가격으로 제공되는 예약도 찾을 수 있음
    • 장기 약정의 위험성을 완화할 수 있는 2가지 방법
      • 컨버터블 예약으로, 요구 사항이나 워크로드가 변경될 경우 약정을 수정할 수 있음
      • 예약 인스턴스 마켓 플레이스를 통해 불필요한 예약 인스턴스를 판매할 수 있음
  • 세이빙 플랜
    • 유형
      • EC2 인스턴스 세이빙 플랜
      • 컴퓨팅 세이빙 플랜
    • 다른 유형의 세이빙 플랜
      • 세이빙 플랜은 데이터 과학자와 개발자가 고품질 머신러닝 모델을 준비, 구축, 교육 및 배포하는 데 사용하는 서비스인 아마존 세이지메이커에도 사용할 수 있음
      • 세이지메이커 세이빙플랜은 12개월 또는 36개월의 지출 약정(시간당 달러 지출)을 대가로 세이지메이커 인스턴스 사용량을 최대 64%까지 할인해 줌
    • 세이빙 플랜은 EC2, 파게이트, 람다 비용을 최대 72%까지 절감할 수 있는 좋은 방법을 제공함
  • 스팟 인스턴스
    • EC2 플릿
      • AWS에서 제공하는 메커니즘으로, 리전 내에서 원하는 총 용량을 사용하여 온디맨드와 스팟 인스턴스 플릿을 시작하는 프로세스를 간소화함
    • 인스턴스 중단을 완하하기 위해 구축된 플랫폼 아키텍처, 오토 스케일링 그룹, EC2 플릿, AWS 스팟 인스턴스 어드바이저, 스팟 배치 점수 및 스팟 중단 주입을 조합하여 사용하면 거의 모든 워크로드에서 스팟 인스턴스를 사용할 수 있음
    • 개발 테스트, 프로덕션 환경까지 포함하고 스팟 인스턴스가 컨테이너 (EKS 및 ECS), EMR, 카산드라, 오픈서치, 하둡, 배치 및 CI/CD를 실행하는 워크로드를 지원함
    • 주요 예외는 데이터베이스와 스테이트풀 애플리케이션. 이러한 애플리케이션의 특성으로 중단 처리가 더 어려워짐
• EC2 오토 스케일링
  • 주어진 순간에 워크로드를 지원하는 데 필요한 컴퓨팅 파워를 프로비저닝하는 동시에 초과 프로비저닝된 인프라의 과도한 지출과 비효율성을 줄이거나 제거할 수 있음
  • 트래픽이 증가하면 더 많은 인스턴스가 프로비저닝되고 트래픽이 감소하면 인스턴스가 종료되어 사용량이 줄게 되며 사용하지 않는 인프라에 대한 요금이 부과되지 않음
  • 스케일링 정책
    • 정책은 동적 스케일링에 사용됨. CPU, 메모리, 네트워크 사용률, SQS 대기열 크기, 세션수와 같은 메트릭을 기반으로 스케일링을 트리거하도록 정책을 설정할 수 있음
  • 오토스케일링 그룹을 사용한 로드 밸런싱
    • 로드 밸런서는 오토 스케일링 그룹 내의 인스턴스 간의 트래픽 분산을 처리함.
    • 일래스틱 로드 밸런싱을 사용하여 오토 스케일링을 사용하도록 설정하면 오토 스케일링에 의해 시작된 인스턴스가 로드 밸런서에 자동으로 등록되고 트래픽이 해당 인스턴스로 라우팅됨
    • 오토 스케일링에 의해 종료된 인스턴스는 로드 밸런서에서 자동으로 등록이 취소되어 트래픽 분산이 중지됨
• 오토 스케일링 요금제
  • 오토 스케일링 그룹을 설정해도 비용이 들지 않음
  • 오토 스케일링 정의에 따라 구동되어 실행 중인 EC2 인스턴스에 대해서만 지불하면 됨. 오토 스케일링이 인스턴스 수를 줄이면 비용 지불이 중지됨
• 오토 스케일링은 주어진 순간에 부하를 지원하는 데 필요한 EC2 인스턴스 수와 컴퓨팅 리소스 용량을 확보하고 초과 프로비저닝된 용량의 낭비를 제거함
• 오토 스케일링은 워크로드 요구 사항에 맞게 인스턴스 용량을 유지 관리하고 가용 영역에 인스턴스를 배포하므로 애플리케이션 복원력과 성능이 향상됨
• 오토 스케일링을 활용하면 효율성, 비용 효율성, 애플리케이션 가용성이 향상됨
• EC2 스케줄링
  • 효율성과 종량제는 클라우드 인프라 채택의 주요 추진 요인 중 하나
  • 수요에 따라 리소스를 확장하거나 축소할 수 있으므로 기존 데이터 센터 운영에 비해 운영 효율성이 향상될 것
  • AWS 인스턴스 스케줄러
    • 스케줄 정의에 따라 EC2와 RDS 인스턴스를 자동으로 켜고 끄는 스케줄을 설정하여 수동 작업이나 중지/시작 스크립팅에 대한 많은 투자를 줄일 수 있음
    • 스케줄 : 리소스를 특정 스케줄과 연결하려면 태그 키 (스케줄)와 태그 값(스케줄 이름)을 적용해야 함
  • 인스턴스 스케줄러 요금제
    • 각 스케줄마다 AWS 람다 요금으로 매월 5달러가 청구됨
    • 실행 중인 EC2 인스턴스와 무관하며, EC2 인스턴스 비용에 추가로 청구됨
• 서버리스 컴퓨팅
  • EC2는 코드가 실행되는 인프라 계층을 담당하는 IaaS 모델을 기반으로 함
  • EC2 인스턴스의 프로비저닝, 구성, 운영, 모니터링, 최적화 및 유지 보수를 해야 할 책임이 있음
  • 서버리스 컴퓨팅은 사전 정의된 트리거(이벤트)에 대응하여 서버에서 코드(특정 함수)가 자동으로 실행되는 FaaS(Function as a Service) 모델로 운영됨
  • 서버리스 컴퓨팅의 장점
    • 애플리케이션 비즈니스 로직에 집중할 수 있게 함
    • 클라우드 인프라 관리에 드는 노력과 비용을 절감함
    • 애플리케이션 실행을 위한 최적의 인스턴스 유형 선택, 인스턴스 프로비저닝 자동화, 로드 밸런싱 설정, 오토 스케일링 구성, 운영 체제 패치, 코드 배포 등을 하지 않아도 됨
  • AWS 람다
    • AWS 람다를 도입하여 이벤트 트리거 함수 호출 문제를 해결하기 위해 서버리스 기능을 최초로 출시했음
    • 람다를 사용하면 사용자가 자체 애플리케이션 코드를 배포하거나 AWS 서버리스 애플리케이션 리포지토리에 저장된 미리 정의된 다양한 함수 중에서 선택할 수 있음
    • 함수 트리거
      • 다양한 이벤트를 기반으로 람다 함수 호출을 트리거할 수 있음
      • S3 : 객체 생성 및 삭제와 같은 S3 버킷 이벤트
      • 애프리케이션 로드 밸런서 : ALB에 도달하는 HTTP 및 HTTPS 요청은 요청 도메인, 요청 방법(GET, PUT, POST) 또는 URL에 따라 람다 함수로 라우팅될 수 있음
      • API 게이트웨이 : API 게이트웨이를 사용하여 서로 다른 API 호출, 원본 또는 엔드포인트에 따라 람다 함수를 호출함
      • 아마존 푸시 알림 서비스 : 아마존 SNS 토픽에 새 메시지가 게시되면 해당 메시지를 람다 함수의 매개변수로 사용함
      • 아마존 이메일 서비스
      • 다이나모 DB
      • 키네시스 데이터 스트림, 키네시스 데이터 파이어호스
      • 크라우드와치와 로그 또는 예약 이벤트 : 클라우드와치 로그 구독에 의해 로그에서 식별된 이벤트를 기반으로 또는 하루 중 특정 시간에 호출할 클라우드와치 스케줄러를 기반으로 람다 함수를 호출함
      • 기타 서비스 : 렉스, IoT 버튼, 코그니토, 클라우드프런트, 클라우드포메이션, 클라우드트레일, 코드커밋 등이 있음
      • 온디맨드
    • 프로비저닝된 동시성 : 100밀리초 내에 기능을 초기화하고 함수 트리거에 응답할 수 있도록 준비함.
    • 최대 이벤트 기간 : 60초에서 6시간 사이
    • 최대 재시도 횟수 : 0에서 2까지
    • AWS 스텝 펑션
      • 호출 순서와 미리 정의된 종속성이 포함됨
      • 스텝 펑션은 람다 함수 워크플로와 호출 프로세스의 단계별 종속성을 중앙에서 조정할 수 있는 장소를 제공하는 서비스
  • AWS 람다 요금제
    • 호출 요청 수와 처리 기간
    • 프로비저닝된 동시성 비요
      • 시작된 동시 함수의 수, 함수당 할당된 메모리 크기, 비활성화할 때까지의 시간에 따라 비용을 지불하게 됨
    • 간접 비용
      • API 게이트웨이 호출 : 아마존 API 게이트웨이는 API 호출(HTTP, REST 및 웹소켓)을 수락, 처리 및 대사응로 하는 작업을 관리하는 서비스
        • 람다 함수 트리거링은 API 게이트웨이에서 관리하는 API 호출을 통해 이뤄지기 때문에 API 게이트웨이 비용이 발생함
      • 실패한 실행 재시도
        • 시간 초과, 입력 데이터 구문 분석 실패, 할당된 메모리 리소스 과다 사용 등과 같은 다양한 이유로 인해 발생
          • 이벤트 기반 동기 호출 : 람다 함수를 동기 호출했을 때 실패한 경우 호출하는 애플리케이션은 오류 메시지를 수신하고 재시도 논리를 처리함
          • 이벤트 기반 비동기 호출
            • 람다 함수를 비동기 호출(호출 전에 큐에 있음)했을 때 실패한 경우 람다 서비스는 호출을 최대 2번까지 재시도함
            • 마지막 시도에서 호출에 실패하면 실패한 이벤트를 데드 레터 큐(DLQ)로 보냄
            • DLQ가 정의되지 않으면 이벤트가 삭제됨. 재시도 횟수를 효과적으로 제어하고 관련 비용을 최소화하기 위해 최대 이벤트 기간과 최대 재시도 횟수를 설정할 수 있음
          • 스트림 기반 호출
            • 런타임 실패 시 람다 서비스는 지속적으로 이벤트 처리를 시도함
            • 끝없는 재시도 호출로 인해 비용이 많이 나오는 상황을 방지하려면 오류 처리 로직을 함수 코드의 일부로 정의하는 것이 좋음
  • 이벤트를 수신하면 람다는 기본 컴퓨팅 인프라를 프로비저닝, 구성, 운영, 모니터링, 최적화 또는 유지 관리를 할 필요 없이 자동으로 코드를 실행함
  • 람다는 일반적인 컴퓨팅 집약적인 운영과 달리 경량, 무상태, 낮은 메모리, 시간이 제한된 워크로드를 위해 설계되었음
• 컨테이너
  • 코드를 실행하는 두 가지 방법
    • EC2 인스턴스에서 프로비저닝, 확장, 운영하기
    • 기본 인프라는 람다가 관리하기 때문에 코드만 작성하면 되는 람다 함수로 실행하기
  • 컨테이너는 애플리케이션 코드, 구성 파일, 종속성 및 OS 기본 이미지를 그룹화함
  • OS 기본 이미지는 메모리 관리, 파일 시스템, 네트워킹 및 프로세스 스케줄링과 같은 하위 수준의 기능을 위해 호스트 OS 커널을 사용할 수 있는 기능과 함께 컨테이너 내부에 있는 애플리케이션을 실행하기 위한 최소한의 필수 요소만 포함하는 경량 OS 이미지
  • 컨테이너에서 코드를 실행할 때는 도커와 같은 컨테이너 엔진에 의존하므로 호스트 OS나 기본 인프라에 대한 의존성이 제거됨
  • 컨테이너 배치 및 확장 관리는 도커 스웜, 쿠버네티스 등과 같은 컨테이너 오케스트레이션 도구를 사용하여 이루어짐
  • 컨테이너의 사용은 컨테이너 아키텍처와 클라우드 인프라의 적합성, 마이크로서비스 아키텍처의 채택, 환경(데스크톱, 개발, 테스트 및 프로덕션) 및 플랫폼 전반에서 애플리케이션 이식성을 보장하고자 하는 욕구로 인해 지속적으로 증가하고 있음
  • 컨테이너와 가상 머신
    • 컨테이너의 이점
      • 환경 일관성 : 코드가 안정적이고 일관되게 실행
      • 운영 간소화 : 모든 환경에서 설계된 대로 실행
      • 인프라 활용도
        • 컨테이너가 VM보다 가벼우므로 각 컨테이너는 실행 시 더 적은 컴퓨팅 리소스를 사용
        • 컨테이너를 설정할 때 실행에 할당할 정확한 CPU와 메모리를 지정함
  • 아마존 ECS와 아마존 EKS
    • ECS나 EKS를 사용하지 않을 경우 EC2 인스턴스를 통해 DIY로 쿠버네티스 클러스터를 독립적으로 관리할 수도 있음
    • 시작 유형
      • 컨테이너를 실행할 수 있는 유형
        • EC2 인스턴스에서 컨테이너를 실행
        • AWS 파게이트를 이용하여 서버리스 방식으로 컨테이너(ECS 및 EKS 모두)를 실행하는 것
    • 아마존 ECS와 EKS 요금제
      • EC2: 컨테이너가 실행되는 인스턴스에 대한 요금이 부과됨
      • ECS에서 제공하는 컨테이너 관리에 대한 추가 비용은 없음
      • EKS를 사용할 경우 실행하는 각 EKS 클러스터에 대해 시간당 0.10달러의 추가 요금이 부과됨
      • 파게이트 : 파게이트의 경우 vCPU 수, 메모리, 운영 체제, 프로세서 아키텍처(x86 또는 arm64) 및 스토리지와 같은 여러 요소에 요금이 부과됨
  • 애플리케이션을 컨테이너로 전환하면 조직에 상당한 이점을 제공할 수 있음 : 운영 효율성, 플랫폼 일관성, 인프라 설치 공간 감소, 비용 절감, 비용이 많이 드는 가상화 플랫폼이나 기본 인프라에 대한 의존성 제거 등이 있음
  • 파게이트는 컨테이너를 서버리스 방식으로 실행하기 위한 관리형 서비스이므로 컨테이너 운영을 크게 단순화하고 인프라 활용도를 높여줌. 파게이트를 사용하면 컨테이너 클러스터를 설정, 관리, 확장하는 것보다 비용이 적게 듬
• 컴퓨팅 비용 최적화를 위한 모범 사례
  • KAO_tm 방법론으로 서비스의 요금제에 대해 필요한 지식을 습득하고, 비용 효율적인 방식으로 환경을 설계할 때 고려해야 할 아키텍처 고려 사항과 대안을 이해하고 ,비용 효율성을 염두에 두고 환경을 운영할 수 있음
  • 지식
    • 컴퓨팅 비용을 최적화하기 위해 각 워크로드에 가장 적합한 사용 가능한 서비스(EC2 대 람다, EC2대 파게이트)를 숙지하는 것
    • 다양한 요금제와 컴퓨팅 서비스 비용에 영향을 미치는 요인을 숙지하는 것
    • 컨테이너의 비용의 주요 요인
      • CPU 및 메모리 할당
      • EC2 인스턴스 선택
      • 온디맨드와 스팟 인스턴스
      • 파게이드 구성
      • 가용 영역 선택(EC2, 파게이트)
  • 아키텍처
    • 모든 컴퓨팅 아키텍처의 주요 목표는 인프라가 성능, 복원력, 가용량 및 보안에 대한 애플리케이션 요구 사항을 항상 지원하는 것. 이 책의 목적은 비용 최적화를 위한 인프라 설계에 도움을 주는 것
    • 인프라 비용 최적화의 아키텍처 모범 사례
      • 리전 선택
      • 프로세서 선택
      • 소프트웨어 스택 선택
      • 용량과 수요 일치(오토 스케일링, 스케줄링, EC2 플릿)
      • 스팟 인스턴스용 아키텍처
      • EC2보다 람다 사용
      • 컨테이너
  • 운영
    • 컴퓨팅 리소스와 리소스 활용률을 모니터링하여 필요할 때만 실행되도록 하고, 최대한 활용하도록 하며, 유휴 리소스가 존재하지 않으며, 스케줄러와 오토 스케일링 그룹이 예상대로 작동하도록 하고, 과잉 프로비저닝 시나리오를 신속하게 파악하고 해결해야 하는 지속적인 작업
    • 모범 사례
      • EC2 사용량과 비용 모니터링
        • EC2 기타 비용은 AWS 비용 탐색기에서 제시하는 EBS 볼륨, EBS 스냅샷, 데이터 전송, NAT 게이트웨이, 유휴 EIP와 같은 간접 EC2 비용에 대해 제시한 비용 범주
      • 인스턴스 미세 조정
      • 인스턴스 중지(또는 종료)
        • 자동 스크립트나 AWS 인스턴스 스케줄러를 사용하여 중지하거나 종료하면 됨
        • EC2 인스턴스를 중지해도 인스턴스에 연결된 리소스에 대한 요금은 계속 부과된다는 점을 유의. EBS 볼륨과 EIP가 포함됨
      • EC2 플릿
      • 전용 호스트와 베어 메탈 인스턴스
      • 고비용 인스턴스
      • 서드파티 소프트웨어 라이선스
      • 온디맨드 용량 예약
      • 세이빙 플랜과 예약 인스턴스
      • 오토 스케일링 그룹
      • AWS 인스턴스 스케줄러
        • X-RAY는 요청에 대한 종단 간 보기를 제공하고, 요청이 애플리케이션을 통해 이동하는 방식, 애플레킹션의 기본 구성 요소 맵, 애플리케이션의 성능을 보여줌
        • 클라우드와치 서비스렌즈는 추적, 메트릭, 로그 및 알람과 함께 X-Ray 통찰력을 한 곳에 통합하여 서비스와 애플리케이션의 관찰 가능성을 향상 시킴
        • X-RAY와 클라우드와치 서비스렌즈를 사용하면 람다 함수가 필요 이상으로 오래 실행되게 하여 높은 비용으로 이어지는 성능 병목 현상을 식별할 수 있음

스토리지 서비스

• 아마존 심플 스토리지 서비스(S3)
  • 아마존 S3 서비스 기능
    • 객체 버전 관리
      • S3에서는 객체의 버전을 무제한으로 유지 관리하여 의도하지 않은 덮어쓰기나 삭제로 인한 데이터 손실을 방지할 수 있음
    • S3 셀렉트와 글래시어 셀렉트
    • 멀티파드 업로드
      • 객체를 S3에 업로드할 때 아마존에서는 멀티파드 업로드 API를 통해 객체를 부분적으로 업로드 또는 복사할 수 있음
    • S3 스토리지 관리
      • S3 액세스 지점
        • 액세스 지점은 버킷에 연결되어 S3 객체 작업(예: GET 및 PUT)을 수행하는 데 사용되는 네트워크 엔드포인트
      • S3 액세스 분석기
        • 액세스 정책을 모니터링
      • S3 인벤토리
        • 모든 객체와 관련 메타데이터 목록을 제공함
        • 비즈니스, 규정 준수 또는 규제 요구 사항에 대한 객체 상태를 감사하고 보고하는 데 사용
      • S3 애널리틱스 - 스토리지 클래스 분석
        • 액세스 빈도가 낮은 스탠더드 객체를 이동
      • S3 객체 태그 지정
        • S3는 분류 목적으로 객체에 태그를 지정하는 옵션을 제공함
    • S3 배치 작업
      • 버킷 간 객체 복사, 태그 세트 교체, 액세스 제어 수정, 이미지 트랜스코딩, 아마존 S3 글래시어 스토리지 클래스에서 아카이브된 객체 복원 등의 작업이 포함됨
    • S3 복제(CRR과 SRR)
      • 교차 리전 복제(CRR) : 서로 다른 AWS 리전에 있는 버킷 간에 객체를 복사하는 데 사용됨. CRR을 사용하면 컴퓨팅 클러스터 또는 사용자가 객체에 액세스하기 위한 지연 시간을 최소화할 수 있음
      • 동일 리전 복제(SRR) : 동일한 AWS 리전에 있는 버킷 간에 객체를 복사하는데 사용됨. SRR은 로그 집계(모든 로그를 단일 리전 내 버킷에 복사), 개발/테스트 환경 복제 등을 지원할 수 있음
      • 복제를 사용하는 경우 원본 및 대상 버킷의 스토리지 비용, COPY와 PUT 요청, 복제된 각 객체의 데이터 전송(CRR의 경우)에 대한 비용을 지불해야함
    • S3 수명 주기 관리 정책
      • 정책을 설정할 때는 S3 요금제(GB당 비용 및 요청당 운영 비용)를 숙지하고 객체의 다양한 수명 주기 단계(핫, 웜, 콜드, 필수 아님 등)를 명확하게 파악해야 함
    • S3 작업 및 객체 속성
      • 객체 만료
      • 이전 버전 전환
      • 이전 버전 만료
    • S3 애널리틱스 - 스토리지 클래스 분석
      • 수명 주기 의사 결정 프로세스를 지원하기 위해 S3 객체의 액세스 패턴을 분석함
  • 아마존 S3 요금제
    • S3 요금제는 S3 스토리지 클래스에 GB-월당 데이터 요금이 부과됨
    • 요청 유형 및 개수, 검색 크기 및 속도, 데이터 가속화, 복제(SRR 또는 CCR), 수명 주기 전환 요청, 데이터 업로드 등과 같은 운영 요소에 따라 달라짐
    • GB-월당 요금제
      • S3 스탠더드-IA와 S3 단일 영역-IA : 최소 30일 단위로 요금이 부과됨
      • 글래시어 즉시 회수 : 최소 90일 단위로 요금이 부과됨
      • 글래시어 유연 회수 : 최소 90일 단위로 요금이 부과됨
      • 글래시어 딥 아카이브 : 최소 180일 단위로 요금이 부과됨
  • 비용 최적화 모범 사례
    • 지식
      • S3 비용에 영향을 미치는 비용요소뿐만 아니라 최적화 프로세스 전반에 걸쳐 사용할 수 있는 모범 사례와 도구에 익숙해지는 것
      • S3 스탠더드-IA와 S3 단일 영역-IA
      • 글래시어 즉시 회수
      • 글래시어 유연 회수
      • 글래시어 딥 아카이브
      • 객체 크기 : 일부 요청(PUT,GET,COPY)은 객체 크기와 관계없이 객체별로 요금이 부과됨
      • S3 복제(CRR과 SRR)
      • S3와 글래시어 셀렉트의 장점 활용
      • 객체 버전 관리 : 객체 버전 관리 작업 시에는 현재 버전뿐만 아니라 저장된 모든 객체에 대해 요금이 부과됨
      • 멀티파드 업로드 : 업로드 요청의 수명 주기 동안 멀티파트 업로드 또는 파트의 일부 객체와 관련된 모든 스토리지, 대역폭, 요청에 대한 요금이 청구됨
      • S3 중복 감소 스토리지 클래스
    • 아키텍처
      • S3 비용 효율성을 위해 설계할 때는 객체 크기, 객체 수명 주기, 애플리케이션 요구 사항, 예상 요청 수 또는 요청 빈도, 데이터 검색 시간 요구 사항, 복제(SRR 및 CRR) 요구 사항, 데이터 전송 OUT 비용등을 고려해야 함
      • S3 리전 선택
      • 데이터 전송 비용 최소화
      • 객체 복제 제어
      • 객체 크기
      • 객체 압축
      • S3 셀렉트와 글래시어 셀렉트
      • S3 단일 영역-IA
      • 게이트웨이 VPC 엔드포인트 : EC2 인스턴스와 S3 객체 간의 통신이 필요한 경우 게이트웨이 VPC 엔드포인트를 통해 연결함
      • 객체 보안
      • 글래시어 스토리지 클래스의 설계
    • 운영
      • 운영은 S3 사용량과 비용을 모니터링하고 추가 최적화 기회를 파악하는 지속적인 일상 작업
      • S3 수명 주기 관리와 S3 지능형 티어
        • 객체 수명 주기의 여러 단계(핫,웜,콜드 및 사용되지 않음)를 고려하고 적절한 수명 주기 정책을 구현함
          • 액세스 관련 패턴의 변화에 따른 S3 스토리지 클래스 간 객체 전환
          • 특정 기간이 경과한 객체 삭제
          • 다시 생성할 수 있는 객체 삭제
          • 일정 시간이 지나면 버전 있는 객체 삭제
          • 업로드 완료되지 않은 멀티파트 업로드 객체 삭제
      • 객체 속성 : S3에 객체를 배치할 때는 새로운 객체를 생성하기 위해 애플리케이션을 작성할 때 객체 만료, 현재 버전 전환 및 현재 버전 만료와 같은 객체 속성을 활용해야 함
      • 필요하지 않은 경우 객체 삭제
      • S3 사용량과 비용 모니터링
        • 아마존 S3 콘솔
        • 아마존 S3 애널리틱스
        • 아마존 비용 탐색기
        • S3 액세스 지점
        • S3 액세스 분석기
        • AWS 컨피그
        • 아마존 클라우드와치
      • 실제 사례
        • 첫 번째 단계는 버전 객체, 멀티파트 업로드(부분 객체) 등이 포함된 불필요한 객체를 삭제하는 정리 프로세스
        • 질문
          • 이 객체는 무엇에 사용되는가?
          • 객체의 소유자는 누구인가?
          • 객체가 검색되는 시기와 시간 경과에 따른 검색 빈도는 어떻게 되는가?
          • 각 객체는 언제 버릴 수 있는가?
          • 버전 있는 객체를 얼마 동안 보관해야 할까?
          • 멀티파트 객체를 어떻게 처리해야 할까?
• 아마존 일래스틱 블록 스토리지(EBS)
  • EBS는 서버(EC2 인스턴스)에 연결하는 외부 드라이브로 간주할 수 있는 볼륨 형태의 스토리지를 제공함
  • EBS 볼륨 유형과 특징
    • 현세대 볼륨 범주
      • SSD 지원 볼륨
        • 지연 시간이 짧고 IOPS(읽기/쓰기)가 많은 작업을 수행하도록 설계되어 있으므로 집약적인 트랜잭션 워크로드에 적합함
        • SSD 지원 볼륨의 성능 속성은 IOPS로 측정됨
      • HDD 지원 볼륨
        • 성능의 주요 요소로 높은 처리량을 제공하도록 설계된 저렴한 마그네틱 스토리지
        • 높은 처리량이 필요한 대규모 순차 워크로드를 지원하는 데 이상적. HDD 지원 볼륨의 성능 속성은 처리량으로 측정됨
    • 구세대 볼륨 범주
      • 마그네틱 볼륨
  • 아마존 데이터 수명 주기 관리자(DLM)
    • 아마존 DLM은 EBS 볼륨 스냅샷의 생성, 보존, 삭제와 같은 데이터 수명주기 관리 작업을 지원함
    • 스냅샷을 수동으로 생성, 삭제하는 대신 스냅샷할 EBS 볼륨(태그당), 볼륨을 스냅샷할 시간, 스냅샷 간격 및 스냅샷 보존 기간을 정의하는 정책을 생성할 수 있음
  • EBS 비용 최적화를 위한 모범 사례
    • 지식
      • 사용 가능한 EBS 볼륨 유형과 각각의 가격에 영향을 미치는 비용 요소에 익숙해지는 것
      • EBS 요금제는 매우 간단하며 볼륨 크기와 경우에 따라 프로비저닝된 IOPS(gp3, io1, io2)나 프로비저닝된 처리량(gp3)에 따라 달라짐
      • 프로비저닝한 항목 비용 지불
      • 각 EBS 볼륨에 대한 비용 지불
      • 종료 시 삭제
      • 스냅샷
    • 아키텍처
      • 요구 사항에 적합한 볼륨 선택 : 데이터 크기, IOPS 및 대역폭 성능과 같은 애플리케이션의 요구 사항을 고려함
    • 운영
      • 운영은 프로비저닝된 사양에 대해 EBS 볼륨 사용량을 모니터링하고, 비용을 모니터링하며, 추가 최적화 기회를 식별하는 지속적인 일상 작업
      • EBS 볼륨 사용량과 성능 모니터링 : 아마존 클라우드와치, 성능 병목 현상을 확인하고 과잉 프로비저닝 사례를 발견할 수 있음
      • IO 작업
      • 버스트 밸런스
      • 볼륨 대기열 길이
      • AWS 컴퓨트 옵티마이저
      • 실제 스토리지 활용도
      • 미사용 볼륨 식별 및 삭제
      • 스냅샷 정리
      • 스냅샷 보관
      • 인스턴스 스토어
  • 애플리케이션을 지원하기 위한 최상의 EBS 볼륨 유형을 결정했으면 필요에 따라 볼륨 크기, IOPS와 처리량을 프로비저닝하고 필요한 모니터를 배치함. 이를 통해 각 볼륨이 효율적으로 활용되고(추가 GB, IOPS 또는 처리량으로 과도화게 프로비저닝되지 않음), 낭비(휴면 볼륨)가 발생하지 않도록 할 수 있음
  • 최소 볼륨 크기를 프로비저닝하는 것으로 시작하고 IOPS와 처리량 사용률을 지속적으로 모니터링하고 필요할 경우 볼륨을 확장 또는 축소하는것이 좋음
• 아마존 일래스틱 파일 시스템(EFS)
  • EFS는 리눅스 기반의 애플리케이션을 위한 고가용성, 내구성 및 확장성이 뛰어난 탄력적인 공유 파일 시스템을 제공하는 관리 서비스
  • EFS 서비스 기능
    • AWS 데이터 싱크
      • 온프레미스와 같은 소스에서 아마존 S3(모든 클래스)나 아마존 EFS로 파일을 복사하는 데 사용되는 안전한 고속 데이터 전송 서비스
    • EFS / EBS
      • 가용성과 내구성
        • 데이터는 여러 가용 영역에 걸쳐 중복 저장됨 / 데이터는 단일 가용 여역에 중복 저장됨
      • 동시 접속
        • 여러 가용 영역에서 최대 수천 개의 아마존 EC2 인스턴스가 파일 시스템에 동시 연결 가능 / 단일 가용 영역에서 단일 또는 여러 아마존 EC2 인스턴스가 파일 시스템에 연결 기능(io1, io2)
      • 크기
        • 무제한, 데이터양이 변함에 따라 스토리지 크기 확장 및 축소 가능 / 최대 64TB, 볼륨 크기는 프로비저닝 시점에 설정되며, 이후에 확장 가능
      • 사용 사례
        • 빅데이터 및 분석, 미디어 처리, 콘텐츠 관리, 웹 서비스, 홈 디렉터리 / 부팅 볼륨, 트랜잭션 및 NoSQL 데이터베이스, 데이터 웨어하우스, ETL
  • 아마존 EFS 요금제
    • 파일 시스템에 파일을 배치하는 것과 관련된 비용, IA 클래스에서 파일을 검색하는 데 필요한 요청별 비용, 추가 처리량을 프로비저닝하는 데 필요한 추가 비용이 있음
  • EFS 비용 최적화 모범 사례
    • 아키텍처
      • 리눅스 기반 애플리케이션을 지원하기 위해 공유 파일 시스템이 필요한 경우 EFS를 사용하고 필요에 가장 적합한 성능 모드와 처리량 모드를 선택해야함
    • 운영
      • 매월 사용되는 GB에 대해 요금이 청구되므로 불피요한 스토리지 비용을 지불하지 않도록 필요 없는 파일은 삭제해야 함
        • EFS 수명 주기 관리
        • 실제 스토리지 추적
        • 프로비저닝된 처리량 모니터링
        • 데이터싱크 추적
  • 스토리지의 GB당 가격은 S3나 EBS보다 비싸지만 액세스 빈도가 낮은 파일이나 단일 가용 영역에 저장된 파일 시스템에 대해 저렴한 스토리지 클래스를 제공함
  • EFS는 공유 파일 시스템이 필요한 사례에만 사용해야 함
• S3는 객체 스토리지, 글래시어와 글래시어 딥 아카이브는 데이터 아카이빙, EBS는 블록 스토리지 그리고 EFS는 관리형 공유 파일 시스템을 제공하기 위한 것
• AWS 퍼블릭 클라우드 인프라의 환상적인 측면 중 하나는 모든 서비스가 구성 가능하고 유연하며 통합 환경에서 운영된다는 것. 컴퓨팅 인프라뿐만 아니라 데이터 스토리지에서도 유용함
• AWS는 온프레미스 스토리지 장치보다 더 높은 유연성을 제공함. 예를 들어 단지 몇 번의 클릭만으로 선택적 복제나 S3 객체 수명 주기 설정이 가능하고, 스냅샷 프로세스와 스냅샷 수명 주기를 자동화하고, EBS 볼륨 크기를 동적으로 늘리고, 다중 가용 영역의 공유 EFS 파일 시스템 설정 등을 할 수 있음

네트워킹 서비스

• AWS 네트워킹 개념(서비스와 구성 요소)
  • 엣지 로케이션
    • POP(상호 접속 위치)
    • 아마존 클라우드프런트 서비스에서 콘텐츠 배포
    • POP(엣지 로케이션)를 전 세계에 배포하면 최종 사용자에게 콘텐츠를 빠르게 배포하고 AWS 네트워크에 빠르게 액세스할 수 있음
  • 아마존 VPC
    • AWS 리전, 가용 영역 및 로컬 영역 내에서 EC2 인스턴스, 데이터베이스, 컨테이너, 기타 리소스를 시작하게 됨
    • 이들을 서로 연결하기 위해서는 네트워크가 필요함. 아마존 VPC는 인스턴스를 연결하기 위한 가상 사설 네트워크
    • 네트워크를 구성하는 방법을 결정하고, VPC에 포함할 가용 영역을 선택하고, VPC에서 사용할 IP 주소 범위를 설정하고, 어떤 트래픽을 허용하고 제한해야 하는지, 어떤 리소스를 인터넷 또는 VPC 외부의 서비스와 통신하도록 허가해야 하는지 등을 정의함
  • IP 주소
    • IPv4 IP는 VPC 내에서 비공개이며 외부 리소스(예를 들면 인터넷 또는 다른 네트워크)로는 연결할 수 없음
  • AWS 트랜짓 게이트웨이
    • 트랜짓 게이트웨이는 이러한 모든 네트워크를 통해 연결 및 라우팅 정책을 중앙에서 관리하기 위해 허브 앤 스포크 모델로 작동함
    • 각 VPC 또는 온프레미스 데이터 센터에서 중앙 게이트웨이(허브)로의 단일 연결을 생성하고 관리하기만 하면 됨. 전송 게이트웨이는 스포크처럼 작동하는 연결된 모든 네트워크 간에 트래픽을 라우팅함
• 네트워킹 서비스 요금제
  • VPC 연결 옵션
    • 인터넷 통신
      • 인터넷 연결 서브넷에 상주하고 공인 IP 또는 EIP와 연결된 리소스는 인터넷 게이트웨이(IGW)를 ㅌ오해 인터넷에 액세스할 수 있음. 리소스를 공인 IP 또는 EIP와 직접 연결하거나 ENI를 통해 연결할 수 있음
      • 애플리케이션의 프런트엔드 인터페이스 역할을 하는 글로벌 액셀러레이터를 통해 인터넷에 액세스할 수 있음
      • 프라이빗 서브넷에 상주하는 리소스는 NAT 인스턴스나 NAT 게이트웨이를 통해 인터넷에 액세스할 수 있음
      • VPN 연결은 인터넷을 통해 외부 네트워크(회사 데이터 센터, 사무실 등)에 안전하게 연결하는 방법
      • 전용 연결은 전용 회선을 통해 외부 네트워크에 안전하게 연결하는 방법
      • Datapath,io 및 Cato Networks와 같은 서드파티 솔루션은 특정 연결 사용 사례를 지원함
    • 내부 통신(VPC 내, VPC 간 또는 다른 AWS 서비스와 통신)
      • 가능하다면 항상 사설 IP를 사용해야 함. 공인 IP를 통한 내부 통신이 가능하지만 데이터 전송 비용이 더 많이 들기 때문에 권장되는 모범 사례는 아님.
      • VPC 엔드포인트(인터페이스 및 게이트웨이)는 VPC 리소스를 S3, 다이나모DB, ELB, 키네시스, EC2 시스템 매니저(SSM), AWS 서비스 카탈로그 서비스와 같은 다른 AWS 서비스와 연결하는 것을 지원함. 엔드포인트를 사용하면 AWS 파트너가 제공하는 리소스와 통신할 수도 있음
      • VPC 피어링은 한 VPC의 리소스와 다른 VPC의 리소스(동일한 리전 또는 여러 리전 간 VPC 피어링)를 연결할 수 있도록 지원함
      • 트랜짓 게이트웨이는 모든 네트워크 연결되는 중앙 집중식 통신 허브를 통해 VPC 및 온프레미스 네트워크에서 리소스 통신을 지원함
  • 데이터 전송 비용
    • AWS 리소스, 네트워크, 계정, 인터넷을 통한 데이터 전송과 관련있음
      • 인터넷으로 데이터 전송(아웃바운드)
      • 리전과 로컬 영역 간 데이터 전송
      • 동일한 리전의 가용 영역 간 데이터 전송
      • 가용 영역 내 데이터 전송
• 네트워킹 서비스 비용 최적화를 위한 모범 사례
  • 지식
    • 네트워크에서 발생하는 데이터 전송 요금을 숙지
    • 네트워크 설정 방법, 리소스 간에 전송되는 데이터양과 외부 리소스로 전송되는 데이터양에 따라 달라짐
    • 데이터 전송 비용을 원자 데이터 전송 유형으로 분해. 인터넷, 여러 리전, 가용 영역, VPC, VPC 내의 여러 리소스에 대한 데이터 전송 비용을 파악
    • NAT 게이트웨이, 엔드포인트, IP, 트랜짓 게이트웨이, 글로벌 액셀러레이터 및 기타 구성 요소와 같은 다른 네트워크 구성 요소를 사용하여 발생하는 관련 비용을 이해하는 데 도움
    • 비용은 트래픽을 시작 및 수신하는 서비스, 통신 방법, 네트워크 아키텍처를 구성하는 네트워크 구성 요소의 영향을 받음
      • 인프라의 기반이 되는 AWS 리전
      • IP 선택
      • NAT 게이트웨이
      • VPC 피어링
      • VPC 엔드포인트
      • 트랜짓 게이트웨이
      • 글로벌 액셀러레이터
  • 아키텍처
    • 리전 선택
    • IP 선택
      • 공인 IP나 EIP를 통해 통신하는 것보다 사설 IP (해당하는 경우)를 통해 통신하는 것이 더 저렴함
      • 공인 IPv4 주소 대신 IPv6 주소를 사용하면 동일한 가용 영역 내의 리소스와 통신할 때 데이터 전송 비용을 피할 수 있음
    • 교차 가용 영역 데이터 전송 최소화
      • 리소스를 가용 영역 간이 아닌 가용 영역 내에서 통신하도록 구성하면 데이터 전송 비용을 줄일 수 있음
    • VPC 피어링
    • 엔드포인트
    • 트랜짓 게이트웨이
    • NAT 게이트웨이
    • 교차 리전 복제
    • 데이터 압축
    • 클라우드프런트
    • 지리 위치 라우팅
    • 전용 연결
  • 운영
    • 데이터 전송 사용량과 비용 모니터링
    • 더 이상 필요하지 않은 릴리스 리소스
      • EIP를 해제하면 매월 3.60 달러를 절약할 수 있음
      • VPN 연결을 종료하면 매월 36 달러를 절약할 수 있음
      • NAT 게이트웨이를 종료하면 매월 32.40 달러를 절약할 수 있음
      • 트랜짓 게이트웨이에 대한 VPC와 VPN 연결이 더 이상 필요하지 않을 경우 연결을 해제하면 매월 36달러를 절약할 수 있음

애플리케이션 계층

• 컨테이너, 스팟 인스턴스, 서버리스 람다 함수 실행, 오픈 소스 관리형 데이터베이스 등을 위한 애플리케이션을 설계
• 애플리케이션을 그대로 클라우드 인프라에 이식하는 리프트 앤 시프트 방식으로 마이그레이션을 먼저 수행하기로 함. 이 방식은 클라우드의 모든 잠재력을 활용할 가능성이 낮음
• 온프레미스 데이터 센터 설치 공간을 최소화하고, 데이터 센터 통합 프로젝트를 지원하며, 비즈니스 확장 시 발생하는 새로운 물리 인프라를 그매하고 운영할 필요가 없음
• 워크로드를 클라우드로 마이그레이션할 때 고려해야 할 몇 가지 애플리케이션 현대화 모범 사례
  • 초기 투자(분석, 개발, 평가, 테스트)가 더 많이 필요하지만 클라우드 마이그레이션으로 인한 비즈니스 이점을 더 크게 실현할 수 있음
  • 혁신적인 기능을 빠르게 도입, 고객의 채택률이 높아지고, 새로운 수익원의 창출로 이어짐
  • 자동화, 오토 스케일링 및 AWS 관리 서비스를 활용하여 운영 효율성과 비용을 절감할 수 있음
• 애플리케이션 현대화 방법
  • 마이크로서비스 : 서버리스로 실행해야할 서비스는 어던 것인가요? EC2 스팟 인스턴스에 적합한 서비스는 어떤 것인가요? 각 서비스를 실행하는 데 가장 적합한 EC2 인스턴스는 어떤 것인가요?
  • 확장성 : 오토스케일링의 이점을 얻을 수 있는 서비스를 식별하고 그에 따라 배포하는 것이 좋음
  • 배포 및 실행 방법 : 워크로드를 실행하는 데 EC2 인스턴스가 필요합니까 아니면 람다가 더 적합합니까? 스팟 인스턴스에서 실행하기에 적합한 워크로드는 무엇입니까? 컨테이너에서 실행해야 할 애플리케이션은 어떤 것인가요?
  • 서드파티 라이선스 폐기 : 라이선스 비용을 줄이는 것 외에도 관리형 데이터베이스 서비스로 마이그레이션 하면 성능 향상, 운영 간소화, 백업, 복제, 패치 처리의 번거로움 감소 등 다른 이점을 얻을 수 있음
  • 데이터베이스 현대화
  • 데이터 분석
    • 애플리케이션을 클라우드로 마이그레이션할 때 고려해야 할 사항
      • 수집하고 저장할 데이터 선택
      • 모든 데이터를 모든 애플리케이션이 액세스할 수 있는 중앙 집중식 데이터 레이크로 결합하는 방법
      • 이 데이터를 머신러닝 기술로 활용함으로써 도출할 수 있는 통찰력
      • 이러한 통찰력이 새로운 수익원을 창출하고 고객 경험을 개선하며 운영 효율성을 개선하는 방법
  • 혁신
• 현실 세계의 애플리케이션 현대화
  • 애플리케이션 관련 개선 작업을 통해 성능 향상과 상당한 비용 절감 효과
  • 운영 체제
  • 프로그래밍 언어
  • 데이터 압축
    • gzip은 응답으로 보내기 전에 HTML과 CSS를 압축하는 NGINX 아파치를 포함한 많은 선도적인 웹 서버에서 지원하고 있음
  • 기타 애플리케이션 관련 변경 사항
    • 서버리스로 전환
    • 상용 데이터베이스 폐기
    • 자바 가비지 컬렉터(GC) 최적화
    • 코드 최적화 : 리소스 누출, 스레드 경합, 잠재적인 동시성 경쟁 조건, 낭비된 CPU 주기가 포함

운영

• 운영 작업은 한 번에 끝나는 마법이 없는 지속적인 작업. 이를 위해서는 조직 내부의 변화, 새로운 유형의 협업 인터페이스, 새로운 사고방식, 새로운 기술, 모범 사례, 도구 등이 필요함
• 퍼블릭 클라우드 환경에 지출하는 각 비용 대비 최대의 가치를 창출할 수 있는 것이 운영 활동. 효과적인 거버넌스 정책을 구현하고, 비용을 보다 정확하게 파악할 수 있으며, 간결한 프로세스를 구현하여 클라우드 환경의 성장을 적절하게 관리하고, 비용 효율적인 방법으로 처리할 수 있음
• 보안, 사용자 관리, 액세스 관리, 환경 회복력, 애플리케이션 모니터링과 관련된 활동과 같은 클라우드 환경 내에서 처리해야 하는 많은 운영작업이 있음
• 거버넌스 유닛: 클라우드 혁신 센터(CCoE)
  • 퍼블릭 클라우드 인프라를 사용하려면 새로운 보안 구성, 거버넌스 정책, 클라우드 환경과 지출에 대한 지속적인 모니터링, 새로운 구매 옵션 도입, 개발자의 권한 변경 등이 필요함. 이러한 변경은 버튼 클릭 단 한번으로 무제한 리소스에 액세스할 수 있게 되어 종량제로 비용을 지불하게 된 것과 관련이 있음
  • 리소스의 가용성, 유연성, 민첩성, 획기적인 서비스의 이점을 누리고자 함. 동시에 프로비저닝된 모든 인프라가 타당한 목적을 가지고 잘 활용할 수 있도록 함으로써 낭비를 제거해야 함
  • 모범 사례
    • 클라우드 팀 간의 연결
    • 조력자 : 데이터 분석 플랫폼을 클라우드로 마이그레이션하기 위해 노력. 연결, 데이터 마이그레이션, 데이터 보호, 규정 준수, AWS 계정 권한, 인프라 프로비저닝 및 자동화와 관련된 모든 요구 사항을 논의하기 위해 CCoE 내에 연락해야 함
    • 지식 센터
    • 접근성
    • 팀 역량 강화
    • 호기심과 실험
    • 팀에 클라우드 네이티브 도구 제공
    • 클라우드 스튜어드
    • 핀옵스 : 기술 팀에 비용 효율적인 모범 사례 안내, 클라우드 환경의 비용 효율성 모니터링, 비용 센터 손해 배상에 대한 보고서 실행 등 경제적으로 최적화된 방식으로 클라우드를 운영하는 것
• 계정 관리
  • AWS 계정 용어
  • 다중 계정 작업
  • 계정 연결의 가치
  • 계정 구조 : 조직 단위(영업, R&D, 재무), 재품 수명 주기 단계(개발, 테스트, 샌드박스, 프로덕션) 프로젝트 또는 모든 구조의 조합을 반영하는 계정 구조를 고려해야 함
  • 이외 모범 사례
    • 계정 할당 : 계정에 대해 허용되는 서비스와 허용되지 않는 서비스를 정의하는 특정 권한 역할, 계정의 보안 설정 세부 정보(VPC, 라우팅 테이블, 암호화 키 등), 최종 사용자와 AWS 환경 간의 통신 방법 정의(VPN, 전용 연결 등을 통해)를 비롯하여 해당 서비스의 유효성을 검증하는 특정 권한 역할이 포함될 수 있음
    • 명명 규칙
    • 계정 소유권
    • 자동화
    • 보안
• 거버넌스
  • 식별 및 액세스 관리(IAM)
  • AWS 서비스 카탈로그 : 클라우드 사용자가 사용할 수 있는 IT 서비스의 카탈로그를 중아에서 관리할 수 있음
  • AWS 랜딩 존
  • AWS 컨트롤 타워
  • AWS 시작 템플릿
  • AWS 컨피그
  • AWs 버짓
  • 각 사용자와 프로세스의 권한 수준, 게정 및 리소스 제공 자동화, 각 리소스에 사전 정의된 구성 적용 등이 포함
  • 각 사용자가 권한을 부여받은 작업만 수행할 수 있으며, 리소스 구동과 관련된 수동 작업이 없으며, 모든 리소스가 사용자가 정의한 관리 정책을 준수하게 됨
• 태깅
  • 사용자나 AWS가 정의하는 키/값 태그와 리소스를 연결하는 옵션을 제공함
  • 태그는 인스턴스, 자동화, 스케줄 설정, 사용량 보고서 필터링, 예산 설정, 비용 분석, 보안 및 액세스 제어를 식별하고 관리하는 데 도움이 됨
• 모니터링과 리포팅
  • 리소스 활용률을 이해하고 최적화하며, 사용량 추이를 파악하고, 상계처리로 지출되는 비용을 추적하고, 데이터 중심으로 비용 절감 의사 결정을 할 수 있음
  • 리포팅
    • AWS 비용과 사용량 보고서
    • AWS 결제 대시보드
    • AWS 비용 탐색기
    • 세이빙 플랜 보고서
    • AWS 트러스트 어드바이저
    • 비용 범주
    • AWS 비용 이상 탐지
    • AWS 컴퓨트 옵티마이저
    • 서드파티 도구
• KPI
  • IT 단위당 비용
    • 시간 경과에 따른 인프라 단위의 평균 비요을 추적
  • 비즈니스 트랜잭션당 비용

요약: AWS 비용 최적화

• 이 책의 주제는 AWS 비용 최적화로 컴퓨팅, 스토리지, 네트워킹 비용 최적화에 중점을 둠. 애플리케이션 비용 절감과 비용 거버넌스를 염두에 두고 클라우드 환경을 운영하는 방법에 대한 내용을 다룸
• 조직의 모든 팀에 걸쳐 강력한 기반을 포함하는 전체 클라우드 채택 프로그램의 일부로 비용 최적화를 지속적으로 수행해야 함.
• 지식(아키텍처, 자동화, 거버넌스, 비용 제어 및 최적화), 팀 간 협업, 자동화된 프로세스, KPI 설정 및 추적 등이 포함되어 있어야 함
• 비용을 절감하고 지속적인 비용을 관리하는 데 도움이 될 뿐만 아니라 서드파티 소프트웨어 라이선스 비용을 절감하고 데이터 구조와 스토리지를 현대화하며 애플리케이션을 업데이트하여 최신 아키텍처 패러다임(예: 서버리스 컴퓨팅)을 활용할 수 있도록 지원함
• 비용 최적화의 단계의 일부로 수행해야 하는 몇 가지 예
  • 정리
    • 사용하지 않는 리소스에 대해서도 비용을 지불함. 연결되지 않은 EBS 볼륨, 이전 EBS 스냅샷, S3 객체, EC2 인스턴스, EIP 및 서비스의 리소스(아마존 워크스페이스나 암호화 키 등)가 포함
  • 컴퓨팅 비용 최적화
    • 실행 중인 모든 EC2 인스턴스의 활용률을 모니터링하고 유휴 리소스가 없도록 보장하고 활용률이 낮은 모든 인스턴스를 더 작은 인스턴스 유형으로 축소하는 지속적인 작업
    • 인스턴스 유형, 프로세서, 크기 및 인스턴스 세대 전반에 걸친 인스턴스 선택 미세 조정
    • EC2 프로비저닝 용량이 언제든지 수요를 충족하도록 오토 스케일링 그룹 설정