관리 및 거버넌스 Part

박기원·2022년 8월 1일

AWS Certified Solutions Architect - Associate

목록 보기

6/12

📒 AWS Well-Architected 및 6대 원칙

운영 우수성 원칙
보안 원칙
안정성 원칙
성능 효율적 원칙
비용 최적화 원칙
지속 가능성 원칙

📒 AWS Auto Scaling

ASG의 모든 인스턴스는 정상 상태에서 시작한다.
EC2 AS에서 해당 인스턴스가 비정상 상태라는 알림을 수신하지 않는 한 인스턴스는 정상 상태로 간주된다.
이 알림은 EC2, ELB 또는 사용자 지정 상태 확인 중 하나 이상에서 전송될 수 있다.

🔔 ASG 종료 정책

인스턴스가 가장 많으며 축소로부터 보호되지 않는 인스턴스가 최소 하나 있는 AZ를 확인한다.
종료할 인스턴스를 결정하고 종료 중인 온디맨드 또는 스팟 인스턴스의 할당 전략에 나머지 인스턴스를 맞춘다. (우선순위가 낮은 인스턴스 유형에서 점진적으로 이동하려고 시도한다.)
가장 오래된 시작 템플릿 또는 구성을 사용하는 인스턴스가 있는지 확인한다. (시작 템플릿을 사용하는 인스턴스 이전에 시작 구성을 사용하는 인스턴스를 먼저 종료 / 시작 템플릿 < 시작 구성)
다음 번 결제 시간에 가장 근접한 비보호 인스턴스를 임의로 종료한다.

AS에서 상태가 비정상인 것으로 표시한 인스턴스는 교체가 예정, 교체하지 않으려면 개별 ASG의 상태 확인 프로세스를 일시 중지한다.

ASG 인스턴스에는 다른 EC2 인스턴스와는 다른 경로, 즉 생명 주기가 있다.

Pending 상태에서 autoscaling:EC2_INSTANCE_LAUNCHING 수명 주기 후크 를 추가하면 Pending:Wait 상태에서 수명 주기 작업 완료 후 Pending:Proceed 상태가 된다.

Terminating 상태에서 autoscaling:EC2_INSTANCE_TERMINATING 수명 주기 후크[ ] 를 추가하면 Terminating:Wait 상태에서 수명 주기 작업 완료 후 Terminating:Proceed 상태가 된다.

🔔 대상 추적 조정 정책

대상 추적 조정 정책을 사용하는 경우 지표를 선택하고 목푯값을 설정한다.
AS는 조정 정책을 트리거하는 CloudWatch 경보를 생성 및 관리하고 지표와 대상 값을 기준으로 조정 조절을 계산한다.
ex :
ASG의 평균 총 CPU 사용량을 40%를 유지하는 경우
ALB 대상 그룹의 대상 1개 당 요청 수를 ASG에 필요한 1,000개로 유지하는 경우
대상 값과 실제 지표 데이터 포인트 사이에는 차이가 발생할 수 있다.
추가하거나 제거할 인스턴스 수를 결정할 때마다 항상 반올림 또는 내림을 통해 어림짐작으로 동작한다.

🔔 단계 조정 정책과 단순 조정 정책의 차이점

단계 조정 정책을 통해 얻을 수 있는 단계 조절이다.
단계 조절이 적용되고 AS 그룹의 현재 용량을 늘리거나 줄이는 경우 조절은 경보 위반의 크기에 따라 달라진다.
대부분의 경우에는 단계 조정 정책이 단순 조정 정책보다는 더 낫다고 한다.
단순 조정에서 주요 문제는 크기 조정 활동이 시작된 후 정책은 크기 조정 활동 또는 상태 확인 교체가 완료되고 휴지 기간이 끝날 때까지 기다린 후 추가 경보에 응답해야 한다는 것이다.
반면 단계 조정에서는 크기 조정 활동 또는 상태 확인 교체가 진행 중인 동안에도 정책이 추가 경보에 계속 응답할 수 있다.
@휴지기간 : 이전 조정 활동이 적용되기 전에 추가 및 종료하지 않도록 하는 설정

🔔 시작 템플릿 (시작 템플릿 > 시작 구성)

시작 구성은 온디맨드 & 스팟 인스턴스를 모두 사용할 수 없지만 시작 템플릿은 가능하다.
인스턴스 구성 정보를 지정한다는 점에서 시작 구성과 동일하다.
하지만 시작 구성 대신에 시작 템플릿을 정의하면 여러 템플릿 버전을 사용할 수 있다.
버전 관리를 사용하면 전체 파라미터 세트의 하위 세트를 만든 후 이를 재사용하여 여러 템플릿 또는 템플릿 버전을 만들 수 있다.
기본 모니터링은 시작 템플릿을 만들거나 AWS Management 콘솔을 사용하여 시작 구성을 생성할 때 활성화 된다.
AWS CLI or SDK를 사용하여 시작 구성을 생성하면 기본적으로 세부 모니터링이 활성화된다.

🔔 시작 구성을 사용하여 인스턴스 테넌시 구성

테넌시는 EC2 인스턴스가 물리적 하드웨어에 분산되는 방식을 정의하고 요금에 영향을 준다.
다음 3가지 테넌시 옵션을 사용할 수 있다.

공유(default) : 여러 AWS 계정이 동일한 물리적 하드웨어를 공유할 수 있다.
전용 인스턴스 (dedicated) : 인스턴스가 단일 테넌트 하드웨어에서 실행된다.
전용 호스트 (host) : 인스턴스가 완전히 전용으로 사용할 EC2 인스턴스 용량을 가진 물리적 서버(사용자가 제어할 수 있는 구성의 격리된 서버)에서 실행된다.

📒 CodeDeploy를 사용한 Blue/Green 배포

CodeDeploy로 제어되는 Blue/Green 배포 모델을 사용한다.
이 배포 유형을 사용하면 프로덕션 트래픽을 전송하기 전에 서비스의 새로운 배포를 확인할 수 있다.
Blue/Green 배포 중 트래픽을 이동할 수 있는 방법은 3가지가 있다.

Canary : 트래픽이 2증분씩 이동한다.
Linear : 트래픽이 동일한 증분으로 이동하며 각 증분 간에 시간(분)이 동일하다.
All-at-once : 모든 트래픽이 원래 작업 세트에서 업데이트된 작업 세트로 한 번에 이동한다.

Blue/Green 배포는 Blue와 Green 애플리케이션 환경 간에 격리를 제공한다.
병렬 Green 환경 회전은 Blue 환경을 뒷받침하는 리소스에 영향을 주지 않는다.
Green 환경이 예상대로 작동하지 않는 경우 Blue 환경에 영향을 주지 않는다.
트래픽을 다시 전송하여 작동 중단이나 다운타임을 최소화하고 충돌 반경을 제한할 수 있다.
트래픽을 계속 작동하는 Blue환경으로 간단하게 롤백할 수 있는 이 기능은 Blue/Green 배포의 주요 차이점이다.

📒 AWS Backup

데이터 보호를 쉽게 중앙 집중화하고 자동화할 수 있는 종합 관리형 서비스이다.
AWS 클라우드 및 온프레미스에서 서비스를 제공한다.
이 서비스를 사용하여 백업 정책을 구성하고 AWS 리소스에 대한 활동을 한 곳에서 모니터링할 수 있다.
이전에 수행했던 백업 작업을 자동화하고 통합할 수 있다.
service-by-service 사용자 지정 스크립트와 수동 프로세스를 만들 필요가 없다.
몇 번의 클릭만으로 AWS Backup 콘솔에서 데이터 보호 정책 및 일정을 자동화할 수 있다.
AWS Backup에서 수행하는 백업은 제어하지 않는다.

🔔 Pliot Light

개념은 가스 히터에서 비롯되어 항시 켜지는 작은 불꼿으로 전체 난로를 점화하여 필요할 때 집을 따듯하게 할 수 있다.
시스템의 가장 중요한 핵심 요소를 항상 실행하는 최소 버전의 환경을 DR(재해 복구)리전에 유지한다.
복구 시기가 되면 중요한 핵심 요소를 중심으로 전체 프로덕션 환경을 신속하게 프로비저닝할 수 있다.

📒 AWS Step Functions

시각적 워크플로를 사용하여 분산 애플리케이션과 마이크로 서비스의 구성요소를 손쉽게 조정할 수 있게 해주는 완전관리형 서비스
각각 기능을 수행하는 개별 구성 요소를 사용하여 애플리케이션을 구축하면 애플리케이션을 빠르고 쉽게 확장하거나 변경할 수 있다.
애플리케이션의 기능을 통해 구성 요소와 단계를 조정할 수 있는 안정적인 방법이다.
워크플로는 일련의 단계로 이루어져 있으며, 한 단계의 출력이 다음 단계의 입력이 된다.
워크플로가 이해하기 쉽고 다른 사람에게 설명하기 쉬우면서 변경하기 쉬운 상태 시스템 다이어그램으로 변환되므로 애플리케이션 개발을 훨씬 쉽고 직관적으로 수행할 수 있다.
자동으로 각 단계를 트리거 및 추적하고 오류가 발생할 경우 재시도하므로 애플리케이션이 의도한 대로 올바르게 실행된다.
기계 학습 모델 교육, 보고서 생성, IT 자동화와 같이 장기 실행되는 워크플로를 만들 수 있다.
IoT 데이터 수집, 스트리밍 데이터 처리와 같이 단기간에 대량을 처리하는 워크플로도 빌드 가능

📒 AWS CloudFormation

포맷 버전 : 템플릿이 따르는 AWS CloudFormation 템플릿 버전
Description : 템플릿을 설명하는 텍스트 문자열
Metadata : 템플릿에 대한 추가 정보를 제공하는 객체
Parameters : 실행 시간에 템플릿에 전달하는 값
Mappings : 조건부 파라미터 값을 지정하는 데 사용할 수 있는 키와 관련 값의 매핑
Conditions : 스택 생성 또는 업데이트 시 특정 리소스 속성에 값이 할당되는지 또는 특정 리소스가 생성되는지 여부를 제어하는 조건
Transform : 서버리스 애플리케이션의 경우, 사용할 AWS Serverless Application Model의 버전도 지정
Resources : EC2 인스턴스 또는 S3 버킷 같은 스택 리소스 및 해당 속성을 지정
Outputs : 스택의 속성을 볼 때마다 반환되는 값을 설명

AWSTemplateFormatVersion: "2010-09-09"
Description: A sample template
Resources:
  MyEC2Instance: #An inline comment
    Type: "AWS::EC2::Instance"
    Properties: 
      ImageId: "ami-0ff8a91507f77f867" #Another comment -- This is a Linux AMI
      InstanceType: t2.micro
      KeyName: testkey
      BlockDeviceMappings:
        -
          DeviceName: /dev/sdm
          Ebs:
            VolumeType: io1
            Iops: 200
            DeleteOnTermination: false
            VolumeSize: 20

🔔 CloudFormation StackSets

단일 작업으로 여러 계정 및 리전에 대해 스택을 생성, 업데이트 또는 삭제할 수 있도록 하여 스택의 기능을 확장한다.
관리자 계정을 통해 템플릿을 정의 및 관리한다.
스택 세트는 리전 리소스이다. 한 리전에서 스택 세트를 생성하면 다른 리전으로 해당 스택 세트를 보거나 변경 불가 하다.
스택 인스턴스는 리전 내 대상 계정에서 스택에 대한 참조로 스택 인스턴스는 스택 없이 존재할 수 있다.
스택 생성 실패에 대한 이유를 표시한다.
스택 인스턴스는 하나의 스택 세트에만 연결된다.

📒 AWS CloudTrail [ 감사 ]

CloudTrail의 이벤트는 AWS 계정의 활동을 기록한다.
이벤트 기록을 통해 AWS 계정에서 이루어진 지난 90일간의 활동을 확인, 검색 및 다운로드할 수 있다.
이벤트는 AWS Management Console, SDK, 명령줄 도구 및 기타 AWS 서비스를 통해 수행된 API 및 비API 계정 활동 기록을 모두 제공한다.
모든 리전 또는 단일 리전에 적용할 수 있다.
CloudTrail 모니터링은
Cloudwatch Logs, CloudWatch Events, CloudTrail
로 모니터링을 수행할 수 있다.
글로벌 서비스는 미국 동부 (N.Virginia)리전에서 발생한 것으로 기록한다.
다중 리전과 글로벌 서비스를 추가하려면
글로벌 : --include-global-service-events
다중 리전 : --is-multi-region-trail
을 추가 한다.
CloudTrail에 기록할 수 있는 이벤트에는 관리 이벤트와 데이터 이벤트 2 가지 유형이 있다.

🔔 CloudTrail 데이터 이벤트

데이터 영역 작업이라고도 한다.
AWS 계정의 리소스에서 또는 리소스 내에서 수행된 리소스 작업을 보여준다. 이러한 작업은 대개 대량 활동이다.

예제 데이터 이벤트

Amazon Simple Storage Service(Amazon S3) 객체 수준 API 활동
(예: GetObject, DeleteObject, PutObject API 작업)
AWS Lambda 함수 호출 활동
(예: InvokeFunction API 작업)
테이블에서의 Amazon DynamoDB 객체 수준 API 활동
(예: PutItem, DeleteItem, UpdateItem API 작업)

데이터 이벤트 보기

기본적으로 추적은 데이터 이벤트를 기록하지 않으며 데이터 이벤트는 CloudTrail 이벤트 기록에서 볼 수 없다.
데이터 이벤트 로깅을 활성화하려면 지원되는 리소스 또는 리소스 유형을 추적에 명시적으로 추가해야 한다.

🔔 CloudTrail 관리 이벤트

제어 영역 작업이라고도 한다.
AWS 계정의 리소스에서 수행되는 관리 작업을 보여준다.

예제 관리

Amazon S3(Simple Storage Service) 버킷 생성
AWS Identity and Access Management(IAM) 리소스 생성 및 관리
디바이스 등록
라우팅 테이블 규칙 구성
로깅 설정

관리 이벤트 보기

기본적으로 추적은 AWS 서비스 전체에서 관리 이벤트를 로그하며 무료로 사용할 수 있다.
CloudTrail 이벤트 기록 또는 LookupEvents API를 사용하여 계정의 관리 이벤트에 대한 가장 최근 90일 기록을 검톼고 다운로드할 수 있다.

📒 Amazon CloudWatch

AWS 클라우드 리소스와 AWS에서 실행되는 애플리케이션을 위한 모니터링 및 관찰 가능성 서비스이다.
지표를 수집 및 추적하고 로그 파일을 수집 및 모니터링하고 경보를 설정할 수 있다.
Amazon EC2 인스턴스, Amazon DynamoDB 테이블, Amazon RDS DB 인스턴스 같은 AWS 리소스뿐만 아니라 애플리케이션과 서비스에서 생성된 사용자 정의 지표 및 애플리케이션에서 생성된 모든 로그 파일을 모니터링할 수 있다.
시스템 전반의 리소스 사용률, 애플리케이션 성능, 운영 상태를 파악할 수 있다.
모니터링을 시작하려면, 내장된 AWS 모범 사례와 함께 자동 대시보드를 사용하여 지표 및 경보에 대한 계정 및 리소스 기반의 보기를 탐색하고, 쉽게 세부 정보를 드릴다운하여 성능 문제의 원인을 파악할 수 있다.
메모리 활용, 디스크 스왑 활용, 디스크 공간 활용도, 페이지 파일 활용, 로그 수집은 CloudWatch Agent를 통하거나 사용자 지정 지표로 수집 가능하다.

Amazon CloudWatch는 기본적으로 지표 리포지토리이다.
Amazon EC2와 같은 AWS 서비스는 지표를 리포지토리에 저장하므로 이러한 지표를 기반으로 통계를 검색할 수 있다.
사용자 지정 지표를 리포지토리에 저장하면 해당 지표에 대한 통계도 검색할 수 있습니다.

🔔 CloudWatch 에이전트를 사용하는 일반적인 시나리오

다른 사용자로 CloudWatch 에이전트 실행
CloudWatch 에이전트가 수집한 지표에 사용자 지정 측정기준 추가
여러 CloudWatch 에이전트 구성 파일
CloudWatch 에이전트가 수집한 지표 집계 또는 롤업
CloudWatch 에이전트로 고분해능 지표 수집
다른 계정에 지표 및 로그 전송
통합 CloudWatch 에이전트와 이전 CloudWatch Logs 에이전트 간의 타임스탬프 차이

EC2 인스턴스 지표

사용 중인 CPU 비율
Disk 읽기/쓰기 작업
읽고 쓴 바이트 수
메타데이터 서비스에 성공적으로 액세스한 횟수
네트워크 보내고 받은 바이트 수
받고 보낸 패킷 수

📒 AWS Config

AWS 리소스 구성 기록을 측정, 감사 및 평가할 수 있는 서비스
AWS 리소스 구성을 지속적으로 모니터링 및 기록하고, 원하는 구성을 기준으로 기록된 구성을 자동으로 평가
아키텍처 모범 사례에 대한 의견은 제공하지 않는다.
이에 따라 규정 준수 감사, 보안 분석, 변경 관리 및 운영 문제 해결 작업을 간소화할 수 있다.

📒 Amazon EventBridge(Amazon CloudWatch Events)

Amazon EventBridge는 코드 작성 없이 AWS 서비스, 자체 애플리케이션 및 서비스형 소프트웨어(SaaS) 애플리케이션 데이터의 변경 사항에 대한 실시간 액세스를 제공하는 서비스이다.
시작하려면 Amazon EventBridge 콘솔에서 이벤트 소스를 선택하고 AWS Lambda, Amazon Simple Notification Service(SNS), Amazon Kinesis Data Firehose를 포함한 여러 AWS 서비스에서 대상을 선택한다.
Amazon EventBridge는 거의 실시간으로 이벤트를 자동 전송한다.

📒 AWS Organizations

AWS의 워크로드가 증가하고 확장됨에 따라 환경을 중앙에서 관리하는데 도움된다.
스타트업이든, 대기업이든 관계없이 결제를 관리하고, 액세스, 규정 준수 및 보안을 제어하고, 계정에서 리소스를 공유하는 일을 모두 중앙에서 손쉽게 처리 가능하다.

🔔 기능

모든 계정의 중앙 집중식 관리 AWS 계정
모든 멤버 계정에 대한 통합 결제
예산, 보안, 규정 준수 필요 충족을 위한 계정의 계층적 그룹화
각 계정이 액세스할 수 있는 AWS 서비스 및 API 작업의 제어를 중앙화하는 정책
조직 계정의 리소스 전반에서 태그를 표준화하는 정책

🔔 장점

하나의 청구서
추적 용이
사용량 통합
추가 비용 없음

📒 AWS Resource Access Manager (RAM)

AWS 계정 또는 Organizations 내 에서 리소스를 공유할 수 있는 간단한 방법을 제공
중앙 집중식으로 리소스를 생성하고 RAM을 사용하여 여러 계정 간에 공유할 수 있으므로 다중 계정 전략의 이점을 유지하면서 고객의 운영 오버헤드는 줄일 수 있다.
RAM을 사용하여 리소스를 공유하면 고객이 각 계정에서 중복 리소스를 만들지 않아도되므로 비용을 절감할 수 있다.

📒 AWS Systems Manager

AWS 인프라에 대한 가시성과 제어를 제공
Systems Manager는 통합된 사용자 인터페이스를 제공하므로 여러 AWS 서비스의 운영 데이터를 보고 리소스 전체에서 운영 작업을 자동화할 수 있다.
리소스 및 애플리케이션 관리를 간소화하고, 운영 문제를 탐지 및 해결하는 시간을 단축하며, 인프라를 대규모로 안전하게 운영 및 관리할 수 있게 해준다.
Systems Manager는 관리형 노드를 스캔하고 탐지된 정책 위반을 보고하거나 시정 조치를 취해서 보안 및 규정 준수를 유지하는 데 도움이 된다.

📒 AWS Trusted Advisor

AWS 모범 사례에 따라 리소스를 프로비저닝하는 데 도움이 되도록 실시간 지침을 제공하는 온라인 도구
인프라를 최적화하고 보안과 성능을 향상시키고 전체 비용을 절감하며 서비스 한도를 모니터링할 수 있다.
비용 최적화, 성능, 보안, 내결함성, 서비스 한도 / 5가지 카테고리의 모범 사례 권장
리소스 및 애플리케이션 관리를 간소화하고, 운영 문제를 탐지 및 해결하는 시간을 단축하며, 인프라를 대규모로 안전하게 운영 및 관리할 수 있게 해준다.

박기원

이전 포스트

데이터베이스 Part

다음 포스트