interplanetary detour

Module 3 : 리소스 배포 및 업데이트

시스템 관리자는 다음과 같은 배포 환경을 보장해야 한다.

- 회사 정책 준수

    - 표준화, 규정 준수 요구 사항

- 반복 가능

    - 템플릿, AMI, 코드형 인프라

- 추적 가능

    - 태그, 소유권, 비용, 조직

- 모니터링 가능

    - 성능, 감사, 규정 준수, 로그, 지표

태그

- Key-Value 형태

- 리소스에 대해 메타데이터를 할당

- 관리, 검색, 필터링에 이용

- 많이 붙일수록 좋다.

- 어떤 태그에 어떤 정보를 담을지 태깅 전략을 세워 일관성 있게 한다.

- 대소문자를 구분한다.

AMI (Amazon Machine Image)

- 운영체제의 템플릿

- AWS에서 미리 구성해서 제공하는 AMI와 사용자 생성 AMI 두 가지가 있다.

- 리전 범위의 서비스 (서울 리전 안에서만 사용 가능) → 다른 리전으로 복사하여 사용 가능

- Image Builder를 사용해 쉽게 AMI 생성 가능

AMI를 다른 리전에 복사

aws ec2 copy-image --source-image-id ami-1234567890bdadf --source-region ap-northeast-2 --region ap-northeast-1 --name "My server"

AWS Control Tower

다중 계정 AWS 환경을 쉽고 빠르게 설정 및 관리한다.

- 랜딩 존 설정 - 기본 뼈대

    - SSO (Single Sign On) and OU (Organization Unit)

        - SSO를 통해 한 번의 인증(로그 아카이브)으로 여러 계정들을 관리 가능

        - 멀티 Account 환경에서 많은 계정들을 중앙 집중식 관리 가능

        - 비용 결제 통합

        - SCPs(Service Control Policies)를 통해 계정에 대한 권한 제어

- 가드레일 적용 - 보안과 규정 준수, 운영

    - 예방 : SCP를 통해 작업 비허용 (default disabled)

    - 탐지 : AWS Config를 통해 규정 미준수 탐지

- 계정 프로비저닝 자동화

- 대시보드 가시성 확보

로그와 문제 사항 확인 경로

- https://169.254.169.254/latest/user-data

- /var/log/cloud-init-output.log

Module 4 : 리소스 배포 자동화

AWS에서의 배포 자동화

- 프로비저닝

    - 라이브 서버 업데이트

    - 다중 리전 롤아웃 배포

    - 시스템 종속성 관리

    - 반복 가능하며 동일한 환경 배포

- 문제 해결

    - 롤백 관리

    - 배포 디버깅

    - 모든 변경 사항 문서화

AWS OpsWorks

- DSL(Domain-Specific Language)을 사용

- Chef, Puppet, Ansible, Terraform 등을 AWS 환경 내에서 사용할 수 있게 함.

AWS CloudFormation

- 구축 프로세스

    1. 템플릿 작성

        - JSON 또는 YAML 문서 작성 

        - Designer를 통해 GUI로 템플릿 생성

    2. CloudFormation 엔진이 해석 및 리소스 생성

    3. 각 리소스를 단일 스택으로 모아 관리

- 리소스 집합을 단일 단위(스택)로 생성, 업데이트 및 삭제 가능

- 스택 및 개별 리소스에서 드리프트(수동 변경) 감지

CloudFormation 템플릿 구조와 속성들

- Resources

    - 생성할 AWS 리소스 기술 : EC2, EBS, RDS...

    - 필수 필드 : 논리적 ID(ImageID), 리소스 유형(Type), 리소스 속성(Properties)

    - !Ref 함수로 다른 구성 요소에 대한 참조 가능

    - DependsOn : 웹 서버의 속성으로 DependsOn: MyDB 을 기술하여 종속성을 정의해 DB 서버의 생성 이후에 웹 서버가 생성되도록 한다.

- Parameters

    - 템플릿에 값을 전달하는 데에 사용

    - Pseudo 파라미터를 통해 스택이 시작될 때 자동으로 값을 참조할 수 있다.

- Outputs

    - 템플릿에서 값을 불러오는 데에 사용

- Mappings

    - Key-Value 페어를 저장

    - 내장 함수인 !FindInMap을 사용해 저장된 값을 반환

CloudFormation Sample Templates

• AWS Quick Start 이용
• https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/sample-templates-services-ap-northeast-2.html

Console Recoder for AWS (Chrome)

이 확장 프로그램을 실행하고 AWS Management Console 상에서 설정하면 그에 따른 CloudFormation 템플릿을 자동으로 생성해준다.

드리프트 감지

AWS CloudFormation에서 드리프트 감지를 활성화한다.

AWS Config에서 cloudfomation-stack-drift-detection-check 룰을 설정하는 방법도 있다.

Cloud Formation Helper Script

애플리케이션을 배포할 때 도움이 되는 기능을 사용할 수 있다.

- cfn-init

    - 블록의 형태로 리소스 메타데이터를 호출, 해석하고 패키지를 설치하며 파일을 생성하고 서비스를 시작하는 데에          사용

- cfn-signal

    - WaitCondition과 함께 순차적으로 동작

    - cfn-signal 명령을 통해 성공/실패 신호를 전송

    - WaitCondition은 WaitConditionHandle이 호출될 때까지 스택의 완료 상태를 차단

CloudFormation 오류 로그

• cloud-init,log
• cfn-init.log
• cfn-wire.log

스택 시작 추가 옵션

--on-failure : 스택 생성 실패

• DO_NOTHING
• ROLLBACK
• DELETE

롤백 실패 시 문제 해결

• 롤백 실패의 일반적인 원인
  • AWS CloudFormation 외부에서 스택의 리소스 변경
  • 권한 부족
  • 제한 오류
  • 리소스가 안정화되지 않음
• continue-update-rollback : 스택이 UPDATE_ROLLBACK_FAILED 상태에 있을 때 롤백하기 위해 사용

템플릿 모범 사례

• 템플릿에 자격 증명을 내장하지 않는다.
  • STS와 Role을 통해 임시 자격 증명을 부여한다.
• AWS 고유 파라미터 유형을 사용한다.
• 파라미터 제약 조건을 사용한다.
  • 데이터 타입, 문자열 길이 등을 지정한다.
• AWS::CloudFormation::Init을 사용하여 EC2 인스턴스에 소프트웨어 애플리케이션을 배포한다.
• 템플릿을 사용하기 전에 먼저 확인한다.

스택 관리 모범 사례

• 코드 검토 및 버전 관리를 사용한다.
• 스택을 업데이트하기 전에 change set을 생성한다.
• AWS CloudTrail을 사용하여 AWS CloudFormation API 호출을 로깅한다.
• 스택 정책을 사용한다.
  • 변경 불가, 삭제 불가 등의 제한을 건다.

AWS Service Catalog

서비스 카탈로그에 템플릿을 등록하고 그 템플릿만 사용할 수 있게 하면 다른 팀에서 리소스를 생성할 때도 리소스에 대한 옵션들이 강제되기에 변수없이 표준 규정을 준수할 수 있다.

예를 들어 보안팀에서 EBS 볼륨을 암호화해서 생성하는 옵션을 지정하여 템플릿을 생성하면 개발팀에서 EBS 볼륨을 생성할 때도 반드시 암호화 옵션과 함께 생성한다.

Service Catalog 구조 예시

• AWS Service Catalog
  • 웹 서비스 포트폴리오
    • EBS 제품(=CloudFormation의 템플릿 등록)
    • EC2 제품
  • 모바일 앱 포트폴리오
  • OOO 포트폴리오

사용자 WorkFlow

1. 제품 탐색
2. 버전 선택
3. 파라미터 채우기
4. 필수 태그 추가
5. 제품 시작
6. 결과 검토

AWS CloudFormation 문제 해결

Amazon S3 버킷에 템플릿을 올려 놓고 재사용하려는데 오류가 발생한다.

• 버킷이 존재하는가?
• S3 접근 권한이 있는가?

CloudFormation 스택 리소스가 만들어지지 않는다.

• 해당 AWS 리소스에 대한 권한이 있는가?
• 리소스 유형에 필요한 파라미터가 있는가?
  • 코드를 작업 템플릿과 비교

Module 5 : 리소스 관리

위에선 배포에 대한 자동화를 알아봤고, 운영과 관리에 대한 프로세스 또한 간소화와 효율적인 방안이 존재한다. 스냅샷, 패치 등을 인스턴스 하나하나 접속해서 할 수 없기 때문이다.

AWS Systems Manager

온프레미스 서버 또한 Systems Manager Agent 설치 구성을 통해 관리할 수 있다.

• 운영 관리
• 애플리케이션 관리
• 변경/패치 관리
• 인스턴스 관리
• 자동화 관리

Systems Manager 사전 조건

• IAM 사용자에게 서비스 권한이 있음
• Systems Manager 에이전트 설치
• EC2 인스턴스의 인스턴스 프로파일 역할(Roles) 및 외부 시스템의 서비스 역할(Roles)
• NACL, SG에서 HTTPS 아웃바운드 트래픽 허용
• (Optional) VPC Endpoint

Systems Manager - Explorer

간단한 대시보드 형태로 현재 운영중인 리소스들을 확인할 수 있다.

• EC2 인스턴스 메타데이터
  • 전체 인스턴스 수
  • 인스턴스별 AMI
• 패치 규정 준수
  • 규칙 미준수 인스턴스 수
• 기타 OpsData
  • AWS Trusted Advisor 데이터
  • AWS Compute Optimizer 데이터
    • EC2 유형 조언
    • EBS 크기/유형 조언
    • Lambda 메모리 조정
• OpsCenter 세부 정보
  • OpsItems (관리 대상)
    • OpsItem 세부 정보
      • 보안 문제
      • 성능 문제
      • 장애
      • 상태 알림(AWS SNS)
      • 상태 변경
    • 생성, 편집
    • 유사 OpsItem 검색, 필터링, 검사
  • 리소스 설명 : 구성 데이터 확인
  • 실행서
    • 실행서를 사용하여 문제 해결
    • 문제 해결 자동화
  • 관련 리소스 세부 정보
    • CloudWatch 경보
    • AWS Config 세부 정보
    • AWS CloudTrail 로그

Systems Manager - AppConfig

애플리케이션 구성을 생성 및 관리하고 신속하게 배포한다.

AppConfig는 아래의 워크플로우를 따른다.

1. 애플리케이션을 만든다.
2. 환경을 생성한다.
   • 개발, 프로덕션 환경
3. AWS CodePipeline 구성 프로파일을 만든다.
   • 구성 단계 설정
   • 구성 항목의 소스(하기 Parameter Store)
4. 배포 전략을 선택한다.
   • 카나리, 롤링, AB, 블루/그린 등

Systems Manager - Parameter Store

• Before
  • 코드 내 자격 증명
  • 암호화 불가
  • 버전 추적
  • 다양한 위치에서 변경된 사항
• After
  • 코드와 데이터 분리
  • 암호화 가능
  • 버전 관리
  • 중앙 집중식

Systems Manager - Automation

1. 자동화 문서 생성
2. 자동화 문서 실행
3. 자동화 모니터링 및 테스트

System Manager - State Manager

EC2 인스턴스 또는 온프레미스 서버의 일관된 구성을 유지관리한다.

1. 자동화 문서 선택 또는 생성
2. 인스턴스 - 문서 연결
3. 상태의 일정 지정
4. (선택)데이터를 S3로 출력할 수 있다.

그 밖에 Patch Manager, Maintenance Windows, Automation 등의 기능을 통해 AWS Systems Manager 안에서 운영, 애플리케이션, 변경, 인스턴스, 자동화에 대한 관리 작업을 수행할 수 있다.

문제 해결

인스턴스가 Session Manager에 표시되지 않는다.

• 인스턴스에 에이전트가 설치되어 있는가?
• 양 측 네트워크가 연결되어 있는가?
• 사용자에게 사용 권한 또는 Role이 부여되어 있는가?

티스토리의 UX상 문제로 항목별 정리와 넘버링 등의 부분에서 멋대로 상위 항목에 탭이 들어가고 있다.

결국 YAML파일 작성하듯이 수동으로 들여쓰기로 했다.

이 밖에도 여러가지 이유로 가능한 한 빨리 다른 플랫폼으로 이전할 예정이다.

ELB, CloudWatch, Auto Scaling

이 삼총사는 같이 움직인다.

하나의 예로

ELB

는 연결된 4개의 인스턴스들을 로드 밸런싱 및 모니터링(Health Check)하며 관리하고,

CloudWatch

는 ELB로부터 노티피케이션 받은 인스턴스 정보를 Auto Scaling에게 트리거링 해준다.

또한 전반적인 AWS 컴포넌트들에 대한 모니터링을 수행하며, Amazon S3 등 저장 공간에 연결하여 각종 모니터링에 대한 데이터를(주로 감사 용도로) 저장한다.

Auto Scaling

은 CPU 사용률(지표=Metric)이 5분(지정기간) 동안 50%(임계치)를 초과하는 경우 인스턴스를 하나 추가하는(Scale Out) 등의 정책에 따라 인스턴스 집합(Fleet)을 스케일링한다. 그러면 다시 ELB는 추가된 인스턴스까지 포함해 5개의 인스턴스를 로드 밸런싱하며 관리한다.

3가지 유형의 탄력성

시간 기반(예약) : 특정 시간대에 고정적으로 스케일링

볼륨 기반(동적) : CPU, I/O 등의 모니터링을 통한 스케일링

예측 기반 : ML을 통해 일일 및 주간 추세를 기반으로 향후 트래픽 예측을 통한 스케일링

Auto Scaling - 구매 옵션

오토 스케일링이 인스턴스를 생성할 때 그 인스턴스의 사양과 최소, 최대값을 지정해야 한다.

인스턴스의 사양은 Launch Configuration에서 지정한다.

Min, Max, Desired 값은 Auto Scaling Group에서 지정한다.

RDS Read Replica

관계형 데이터베이스의 읽기 전용 복제본이다.

읽기 작업이 매우 자주 일어나는 상황에서 트래픽의 경합을 막기 위해 여러 복제본으로 트래픽을 분산시킨다.

Amazon Aurora의 경우 최대 15개,

Oracle DB, MS-SQL Server, MySQL, MariaDB, PostgreSQL은 최대 5개까지 생성할 수 있다.

Scale Up/Down

RDS 인스턴스의 리소스 성능을 변경하는 작업이다.

micro부터 24xlarge에 이르는 모든 크기의 인스턴스 타입을 지원한다.

스토리지(EBS) 추가를 제외하면 변경 시에 발생하는 다운 타임은 감안해야 한다.

Amazon Aurora Serverless

Amazon Aurora 위에 MySQL이나 PostgreSQL을 얹어서 사용할 수 있다.

다운 타임 없이 RDS에 대한 수직적 확장 및 축소가 가능하며, 서버 인프라를 관리할 필요없이 애플리케이션의 필요에 따라 자동으로 시작 및 종료하고 용량을 축소 또는 확장하는 DB 클러스터이다.

Infra Automation with CloudFormation (인프라 자동화)

수동 프로세스는 확장, 버전 제어, 감사 내역, 일관성이 없기에 인프라 자동화가 필요하다. 

JSON/YAML로 작성한 템플릿을 CloudFormation 엔진에서 돌려 아키텍처 스택을 만든다.

IaC (Infra as a Code)

반복성, 재사용성 등의 장점이 있고, 템플릿의 내용만 고쳐 쉽게 인프라를 수정할 수 있다. 원래 스택에 대한 변경 집합을 검사한 후 CloudFormation으로 실행한다.

스택은 주로 위와 같이 계층별로 구분지어 따로 만든다. 각 스택을 알아보기 편하고 관리하기 쉽기 때문이다.

AWS Quick Start

AWS Solutions Architect가 구축한 모범 표준 AWS CloudFormation 템플릿.

보안 및 고가용성 모범 사례에 기초하여 만들어졌으며, 클릭 한 번으로 1시간 이내에 전체 아키텍처 생성이 가능하다.

템플릿이 적용할 환경에 정확히 부합하진 않을 것이기 때문에 스크립트로 커스터마이징하여 부트스트랩으로 배포해 사용할 수 있다.

Deployment Automation (배포 자동화)

보안 패치 등을 수많은 인스턴스(Fleet)에 적용하기 위해 Systems Manager를 이용한다.

일괄적으로 명령 실행, 패치 관리, 상태 관리, 세션 관리, 인벤토리 관리가 가능하다.

S/W Inventory : 설치될 제품 목록

AWS OpsWorks

개별 인스턴스 내부의 S/W 설정에 특화되어 있다. 스택에서 인스턴스 외부의 부분은 CloudFormation으로 구축하고, 인스턴스 내부의 상세한 설정은 OpsWorks로 구축하면 된다.

온프레미스에서 사용하던 Chef, Puppet를 사용하여 애플리케이션을 구성 관리할 수 있다.

AWS Elastic Beanstalk

AWS Elastic Beanstalk의 목표는 개발자가 기본 인프라에 대해 걱정할 필요없이 클라우드에 확장 가능한 웹 애플리케이션 및 서비스를 배포하고 유지 관리하도록 돕는 것이다. Elastic Beanstalk은 선택된 플랫폼에서 애플리케이션을 실행하는데 필요한 요소로 구성한다. 애플리케이션 스택을 설치 및 구성하기 위해 인스턴스에 로깅하는 것에 대해 걱정할 필요가 없다.

상황에 맞는 알맞은 솔루션을 선택하여 시스템을 구축한다.

AWS CloudFront

CDN(Contents Delivery Network)서비스란 말 그대로 콘텐츠 전송 네트워크로, 기본적인 멀티 티어 캐시와 광범위한 유연성으로 모든 전송 사례에 최적화되어 있다. 이 세션에선 AWS Edge Location의 CloudFront를 살펴본다.

무엇을 캐싱해야 하는가?

• 수집하려면 느리고 비싼 쿼리가 필요한 데이터
• 비교적 정적이고 자주 액세스하는 데이터(WORM : Amazon S3)
• 공개 거래되는 주식 가격처럼 일정 기간 동안 변화가 없을 수 있는 정보

캐싱 유형

• 클라이언트 - 웹 브라우저
• 서버 - 웹 서버
• 서버 - 역방향 프록시 캐시

원래 동적인 데이터는 캐싱의 대상이 아니지만 AWS CloudFront는 매우 빠른 속도의 AWS Backbone Network를 사용하기 때문에 동적인 부분도 캐싱이 가능은 하다.

콘텐츠 만료 방법

• TTL(Time To Live)
• 객체 이름 변경
• 객체 무효화

Amazon DynamoDB Acclerator (DAX)

DynamoDB와 마찬가지로 완전관리형 서비스이다. DynamoDB는 10밀리초 미만의 일관된 지연 시간을 제공하지만 DAX는 읽기 중심의 워크로드에 대한 초당 수백만 건의 요청에 대해서 마이크로초 단위의 응답 시간을 제공한다.

또한 DynamoDB와 API 호환이 되기 때문에 작동 중인 애플리케이션 코드를 변경할 필요가 없다. DAX 클러스터를 프로비저닝하고 DAX 클라이언트 SDK를 사용하여 DAX 클러스터에서 기존 DynamoDB API 호출을 가리키면, DAX가 나머지 모든 작업을 처리한다.

위와 같이 응답 시간이 중요한 게임 서버 등의 캐시로써 잘 사용된다.

Amazon ElastiCache

Amazon ElastiCache는 클라우드에서 인 메모리 캐시를 배포, 운영, 조정하는 데 사용되는 완전관리형 웹 서비스이다.

여러 개의 캐시 노드(EC2 Instance)들을 묶어 하나의 ElastiCache 클러스터로 관리한다.

ElastiCache는 Memcached와 Redis 두 가지의 유형이 있다.

아래의 다이어그램은 애플리케이션 서버, 캐시, 데이터베이스의 흐름도를 나타낸다.

Write Through (연속 쓰기)

애플리케이션으로부터 쓰기 작업을 요청받으면 Cache와 오리진 DB에 모두 데이터를 입력한다. 

Lazy Loading

애플리케이션으로부터 읽기 작업을 요청받았을 때 캐시에서 요청한 데이터가 Hit되면 그대로 받아오기만 하고, 만약 Miss되어 데이터베이스로부터 읽어왔다면 캐시에 그 값을 저장한다.

CloudFront, 캐시, ELB를 포함한 3-Tier 웹 애플리케이션 아키텍처 예시