AWS SAA - The Operational Excellence Pillar (운영 우수성 원칙)

The Operational Excellence Pillar (운영 우수성 원칙)

AWS Certified Solutions Architect Study Guide - Associate (SAA-C02) EXAM 요약

운영 우수성 원칙은 SAA C01 에 포함되어있는 영역이었으며, SAA-C02 에서는 포함되지 않을 수 있는 영역이다

 

개요

운영 우수성 원칙 (operational excellence pillar) 은 클라우드 인프라 위에서 자동화, 코드화를 통해 원활하고 안정적으로 유지하기 위한 활동에 관한 내용이다.

CloudFormation

CloudFormation은 템플릿을 이용해 코드로서의 인프라를 배포, 설정, 문서화하는 서비스이다.

하나의 템플릿을 이용해 다수의 동일한 실행환경을 구현 가능하다.

스택 생성하기

각 리소스는 논리적 ID (logical ID) 라는 식별자를 부여한다. 이는 하드코드된, 템플릿 내 유일한 값이어야 한다.

스택 이름과 논리적 ID는 대소문자를 구분하고, 이들은 생성 시 파라미터 값으로 사용되지 못하는 고유하고 고정된 값이다.

다수의 스택 활용하기

스택 간 값 전달을 위해서 두 가지 방법이 존재한다.

중첩 스택

nested stack을 사용하면 템플릿 선언 내에 Outputs 섹션에서 리턴값을 주는 함수같은 항목을 선언할 수 있다.

이는 Resources 섹션에서 Fn::GetATT 함수를 이용해 가져올 수 있다.

스택 Output 값 익스포트 하기

중첩 구조 외부에 스택 정보를 공유해야 할 경우 Output 섹션 Export 필드에서 익스포트가 가능하다.

이는 타 템플리셍서 Fn::ImportValue 함수를 통해 가져올 수 있다.

스택 업데이트

Direct Update

업데이트한 템플릿을 업로드하면, CloudFormation은 변경 내역을 즉각 반영하여, 변경된 리소스만 수정한다.

Change Set

체인지 세트를 이용하면, 업데이트 전에 변경 내역을 눈으로 확인 후 승인할 수 있다.

업데이트 속성

스택이 포함하는 리소스들의 업데이트 속성에 따라 다음 세 종류로 나뉜다.

• 중단 없는 업데이트 (update with no interruption)
  • EC2 인스턴스에 부착된 IAM 인스턴스 프로필 변경 등
  • 물리적 ID 가 변경되지 않는다 (기존 인스턴스에서 작업된다)
• 중단 혀용 업데이트 (update with some interruption)
  • EBS 기반 EC2 인스턴스의 타입 변경 등
  • 물리적 ID 가 변경되지 않는다
• 대체 (replacement)
  • EC2 인스턴스의 AZ 변경 등
  • 새 리소스를 생성하여 원본 리소스를 대체한다.

특정 리소스에 대한 업데이트 방지

스택 정책 (stack policy) 를 사용하면 각 리소스마다 업데이트 정책을 설정할 수 있다.

스택 정책 덮어쓰기

다이렉트 업데이트를 실행할 때 업데이트 도중에만 적용할 업데이트 정책을 설정할 수 있다.

 

CodeCommit

Amazon의 프라이빗 Git 서비스이다. 다른 AWS 서비스와의 연계를 강점으로 가진다.

• AWS KMS 를 이용해 저장 중 데이터 암호화
• HTTPS 및 SSH 를 이용해 이동 중 데이터 암호화
• 리포지토리 용량제한 없음, 개별 파일 최대 용량 2GB

리포지토리 접근 제어

IAM 정책을 통해 리포지토리에 대한 접근을 제어하므로, 정책을 적용함으로서 접근 권한을 부여할 수 있다.

• AWSCodeCommitFullAccess
  • 무제한의 접근 권한 : 어드민
• AWSCodeCommitPowerUser
  • 쓰기 및 읽기
• AWSCodeCommitReadOnly
  • 읽기 권한

특정 리포지토리에 대한 접근을 제한하고자 한다면 위 정책을 고객 정책에 복사한 뒤 해당 리포지토리의 ARN을 지정한다.

 

CodeDeploy

EC2 또는 온프레미스 인스턴스에 애플리케이션을 배포하기 위한 서비스

S3 이나 GitHub 리포지토리에 저장된 바이너리 실행파일, 스크립트, 웹 에셋, 이미지를 배포할 수 있다.

• 어플리케이션을 다수의 인스턴스 또는 서버에 동시에 배포
• 배포 오류 밥ㄹ생 시 자동 롤백 기능으로 복원
• 중앙집중식 모니터링 및 배포 제어
• 한 번에 여러 개의 어플리케이션 배포

배포 성공이나 실패에 따라서 트리거를 실행하여, SNS 노티피케이션이 가능하다.

모니터링을 위해 CloudWatch 알람 설정이 가능하다.

배포 실패 또는 CloudWatch 경보 시 마지막 성공적인 배포 시점의 파일로 새로 배포를 진행한다.

CodeDeploy 에이전트

Linux 또는 Windows 인스턴스에서 실행되는 서비스

인스턴스에 어플리케이션을 배포하는 과정을 제어할 수 있다.

배포 타입

인플레이스 배포

기존 인스턴스에 어플리케이션을 배포할 수 있다.

각 인스턴스에서 기존 어플리케이션은 중지 후 업그레이드가 진행되고, 재시작된다.

ELB 연계 인스턴스의 경우 ELB에서 업데이트 진행 동안에는 연결이 해제된다.

블루/그린 배포

blue/green deployment 는 기존의 어플리케이션을 업그레이드할 때 배포 과정의 중단 또는 간섭을 최소화한다.

기존의 인스턴스를 그대로 유지하고, 새 인스턴스들을 생성하여 어플리케이션을 배포한다.

이후 트래픽을 새 인스턴스로 라우트 한 뒤, 원본 인스턴스에 대한 처우를 결정한다.

배포 환경설정

• OneAtATime
  • 마지막 인스턴스를 제외한 모든 인스턴스에서의 배포가 성공해야 배포 성공으로 친다.
• HalfAtATime
  • 절반 이상이 배포에 성공해야 배포 성공으로 친다.
• AllAtOnce
  • 하나라도 배포에 성공하면 배포 성공으로 친다.
• 커스텀
  • 임의로 설정할 수 있다.

라이프사이클 이벤트

• ApplicationStop : 인플레이스 배포 전, 어플리케이션을 문제 없이 중지시키기 위한 이벤트
• BeforeInstall : 어플리케이션을 복사한 후, 최종 위치에 저장하기 전
• AfterInstall : 최종 위치에 저장한 후 실행, 퍼미션 등 작업에 사용
• ApplicationStart : 어플리케이션 시작을 위한 이벤트
• ValidateService : 어플리케이션의 성능을 검증하는 이벤트
• BeforeBlockTraffit, AfterBlockTraffic, BeforeAllowTraffic, AfterAllowTraffic : ELB 이벤트

AppSpec 파일

어플리케이션 명세서 파일 (application specification) 파일을 통해 배포가 진행되는 동안 어떻게 진행될 지 자세히 명시할 수 있다.

• OS 섹션 : Windows / Linux
• Files 섹션 : 파일 또는 디렉토리에 원본-대상 식별자 쌍을 부여하고, 복사 대상을 지정한다.
• Permissions 섹션 : 리눅스 계열에서 퍼미션을 설정한다.
• Hooks 섹션 : 각 라이프사이클 이벤트에서 에이전트가 실행해야 할 스크립트
  • 하나의 라이프사이클 이벤트에서 모든 작업의 총 대기시간은 1시간을 초과할 수 없다.

 

CodePipeline

여러 단계로 이뤄진 소프트웨어 개발 및 배포 절차를 자동화해준다.

CI/CD 워크플로우 또는 파이프라인 기법을 통해 개발 및 배포의 자동화를 구현한다.

지속적 통합 CI

Continuous Integration (CI) 의 첫 번째 단계인 소스 스테이지에서는 개발자가 Git 등을 통해 리포지토리에 코드를 제출한다.

다음 단계인 빌드 스테이지에서는 어플리케이션에 따라 빌드 시스템이 코드를 컴파일하거나 바이너리 파일 속에 빌드하기도 한다.

유닛 테스트 (unit test)를 통해 검증이 가능하며, 언어에 따라 빌드 스테이지를 진행하지 않기도 한다.

지속적 배포 CD

Continuous Delivery (CD) 의 목적은 실패의 위험을 줄이며 자주 어플리케이션을 업데이트하는 것이다.

이를 위해 테스트 스테이지 (test stage) 가 포함되며, 어플리케이션에 따라 이 내용은 달라진다.

마지막 단계는 배포 스테이지 (deployment stage) 이며, 상용 환경에 배포한다.

배포 과정까지 자동화도 가능하지만, 수동 승인 과정을 중간에 포함하는 것이 일반적이다.

파이프라인 생성하기

최소 2개에서 최대 10개의 스테이지를 포함한다.

스테이지마다 최대 20개의 액션을 순차적, 혹은 병렬적으로 수행한다.

파이프라인에서 스테이지가 진행되는 동안 사용된 파일은 아티팩트 (artifacts)로서 관리된다.

Source 액션

파이프라인의 첫 번째 스테이지에서는 하나 이상의 소스 액션만 포함된다.

CodeCommit, S3, GitHub 등이 소스 제공처로 설정이 가능하다.

Build 액션

컴파일이 필요 없는 언어도 이 액션을 통해 문법 오류나 규칙 준수 여부를 확인할 수 ㅣㅇㅆ다.

이 액션에는 AWS CodeBuild 나 서드파티 도구인 CloudBees, Jenkins 등을 사용할 수 있다.

Test 액션

테스트 액션에서도 AWS CodeBuild를 사용할 수 있다.

스마트폰 플랫폼 기반 테스트는 AWS DeviceFarm 사용또한 가능하다.

Approval 액션

manual approval 작업으로서, 사용자가 직접 7일 내에 수동 승인하는 작업이다.

Deploy 액션

배포 액션 수행을 위해 CodeDeploy, CloudFormation, ECS, Elastic Beanstalk 등과 통합할 수 있다.

Invoke 액션

커스텀 Lambda 함수 실행이 필요한 경우 해당 함수를 호출할 수 있다.

 

AWS Systems Manager

AWS 리소스 및 온프레미스 서버에 대한 각종 액션을 자동 및 수동으로 실행할 수 있도록 한다.

Actions

Automation Action

다수의 EC2 인스턴스 재시작, CloudFormation 스택 업데이트, AMI 패칭 등 AWS 리소스에 대한 다수의 작업의 처리이다.

Run Command Action

인스턴스에 대한 커스텀 스크립트이다.

AWS-InstallApplication, AWS-RunShellScript 등의 액션 문서가 이에 포함된다.

Session Manager

보안 그룹이나 NACL의 인바운드 포트 개방, 퍼블릿 서브넷 도움 없이 Bash 및 PowerShell을 통해 인스턴스에 접근할 수 있게해준다.

Patch Manager

인스턴스의 패치 작업을 자동화한다.

AWS-RunPatchBaseline 액션 문서 실행으로서 Linux와 Windows 인스턴스에 대한 패치 작업을 진행한다.

State Manager

인스턴스별로 원하는 소프트웨어 및 환경 설정을 돕는다.

AWS-GatherSoftwareInventory 정책 문서만 사용 가능하다.

Insights

AWS 리소스의 헬스 상태, 규정준수 여부, 운영 세부 정보를 한곳에 집약한 것이다.

Built-in insights

빌트인 인사이트는 사용자에게 기본적으로 제공하는 시스템 모니터링이다.

• AWS Config Compliance : AWS Config 룰, 리소스 그룹 내 총 리소스 수, 환경설정 변경이력 등을 제공
• CloudTrail Events : CloudTrail이 기록한 개별 리소스의 마지막 이벤트 정보 등
• Personal Health Dashboard : 리소스에 영향을 줄 수 있는 문제 상황 경고
• Trusted Advisor Recommendations : AWS 환경설정의 최적화 수준 검토, 리소스 비용, 보안 등에 대한 권장안 비교

Inventory Manager

OS나 어플리케이션 버전 등 인스턴스와 관련된 데이터를 수집한다.

계정 내 모든 인스턴스를 선택하여 AWS-GatherSoftwareInventory 정책 문서가 동작하게 되면, 이는 글로벌 인벤토리 어소시에이션 이라 한다.

Compliance Insights

사용자가 설정한 환경설정 룰과 실제 인스턴스 스택의 패치 및 연관 상태를 비교한다.

패치와 관련된 패치 컴플라이언스, 연관 액션 인사이트인 연관 컴플라이언스로 구성된다.

 

AWS Landing Zone

리소스를 보안성 및 확장성을 높이기 위해 다른 AWS 계정에 배포할 수 있다.

Landing Zone은 4개의 코어 계정으로 시작하며, 서로 다른 다음 롤을 가진다.

• AWS Organizations Account : 다른 멤버 계정을 생성 및 관리하기 위한 계정
• Shared Services Account : 다른 계정이 접근할 수 있는 호스팅 서비스인 공유 서비스 VPC가 포함된다.
• Log Archive Account : 로그 관리를 위한 계정, CloudTrail, AWS Config 로그 파일을 수집한다.
• Security Account : 보안 관리를 위한 계정, GuardDuty, 교차계정 롤 등이 포함된다.

 

코멘트

물론 SAA-C02 시험에는 명시되지 않은 출제범위긴 하지만.. (사실 알아두어야 AWS 아키텍팅에 도움이 될거다)

책에 있어서 한번 가벼운 마음으로 쭉 읽어보았는데 생각보다 CI/CD 관련 내용이라 재밌게 잘 읽었다.