interplanetary detour

Module 9 : 안전하고 복원력 있는 네트워크 운영

인터넷 통신을 위한 3단계

1. IGW 구성

2. 라우팅 테이블 경로 설정

3. 퍼블릭 서브넷의 EC2 인스턴스에 퍼블릭 IP 부여

NAT Gateway

아웃바운드 트래픽에게 힌시적(일회성)으로 퍼블릭 IP를 부여해 줌

NACL

- Default all permit

- 규칙 우선도 지정

- Stateless

Security Group

- Default deny all inbound

- Default permit all outbound

- Stateful

VPC Peering

- 인터넷을 통하지 않고 격리를 유지한 채로 VPC 간 통신

- AWS 네트워크를 통해 통신

- 서로의 라우팅 테이블에서 대역을 잡아준다.

데이터 센터에 대한 VPN 연결

가상 프라이빗 게이트웨이(VGW)를 통해 VPN을 맺는다.

Transit Gateway

- VPC Peering은 전이적 Trusting 지원이 안 되기 때문에 다중 VPC Peering 시에 TGW를 통해 허브같은 역할을 처리

- 최대 5000개 VPC 연결 가능

- 데이터 센터와 VPN 연결도 가능

VPC Endpoint

- Interface Endpoint

    - EC2 인스턴스와 AWS 서비스를 연결

    - AWS 네트워크를 통함

    - ENI에 연결

- Gateway Endpoint

    - DynamoDB와 S3만 지원

    - AWS 네트워크를 통함

    - VPC에 연결

Route 53 Resolver (Hybrid)

Route 53에 DNS 쿼리를 했을 때 AWS VPC 뿐만 아니라 온프레미스 환경에 대한 도메인도 함께 얻을 수 있는 서비스

Amazon VPC Flow Logs

게시 대상: Amazon CloudWatch Logs, Amazon S3

캡처 수준: VPC, Subnet, ENI

지원: 보안 그룹 제한성 진단, 인스턴스에 도달하는 트래픽 모니터링

Amazon CloudFront

- 캐싱으로 레이턴시 감소

- DDoS 완화

- SSL 인증서 지원

- HTTP/2 지원

- S3 Bucket Logs 지원

AWS WAF

SQL Injection, XSS, HTTP Flood 등 위협을 맨 앞단에서 차단

- 구성 순서

    1. 웹 ACL 생성

    2. 리소스 유형 정의

    3. 규칙 추가(관리형 규칙, 사용자 지정 규칙)

    4. 동작(허용/차단) 설정

    5. 규칙 우선 순위 설정

    6. 지표 구성(CloudWatch)

AWS Shield

관리형 DDoS 보호 서비스

- AWS Shield Standard

    - 무료

    - 3, 4계층 검증

- AWS Shield Advanced

    - 유료

    - 7계층까지 검증

    - WAF와의 통합, CloudFront 배포 기능 제공

AWS Certificate Manager (ACM)

- 인증서에 대한 프로비저닝, 배포 및 중앙 집중 관리

- SSL, TLS 통신에 사용

문제 해결

서브넷의 인스턴스가 서로 통신하지 못한다.

- NACL, SG 확인

- VPC Flow Logs 확인

NAT 구성이 작동하지 않는다.

- 라우팅 테이블 구성을 확인

- NAT Gateway가 Public Subnet에 위치하는지 확인

피어링된 네트워크의 리소스에 연결할 수 없다.

- 피어링 요청/승인 확인

- 라우팅 테이블 확인

- NACL, SG 확인

Module 10a : Mount 가능한 스토리지

Instance Storage

- 짧은 대기시간

- 높은 IOPS 및 처리량

- 인스턴스 중지 또는 종료 시 반환됨(휘발성)

- 사용 사례 : 버퍼, 캐시, 스왑 파일, 페이지 파일

Amazon EBS (Elastic Block Storage)

- 네트워크 연결

- 영구 블록 스토리지

- 부팅 및 데이터 볼륨이 지원됨

- USB 구매하는 것과 같이 사용량과 관계없이 최초 지정 용량만큼 과금 (온디맨드가 아님)

- 독립적 사용 불가. EC2 인스턴스에 연결해서 사용해야 함

    - EC2에 붙기 때문에 EBS도 AZ 레벨 서비스이다(다른 AZ의 EC2에 Attach 불가).

- Detach, Attach를 통해 데이터 이동의 용도로 사용 가능

- USB와 다른 점

    - 동시에 여러 EC2 인스턴스에 연결 가능(같은 AZ에서 최대 16개 인스턴스에 Attach 가능)

    - 크기와 유형 수정 가능 (6시간 쿨타임)

- RAID 0, 1 지원

- SSD 지원 볼륨

    - 범용(gp2) : 1GiB 당 3IOPS, 최대 16000IOPS

    - 프로비저닝된 IOPS : 볼륨 사이즈와 IOPS 수치를 정해 딱 맞게 프로비저닝시킨다.

- HDD 지원 볼륨

    - 처리량 최적화 : 처리량이 많다.

    - 콜드 : 자주 액세스하지 않는 워크로드를 위한 가장 저렴한 볼륨

- Auto-Enabled IO : 데이터 불일치를 탐지한 볼륨에 IO 작업을 계속 할 것인지(Fsck 명령어 참조).

EBS 스냅샷

- 증분 스냅샷

    - 불필요한 중복 정보가 스냅샷에 포함되지 않게 하여 효율적이다.

- 리전 간 스냅샷 복제 및 공유 가능

- 일관성 있는 스냅샷 생성

    - 애플리케이션 중지 또는 정지

    - Linux : fs_freeze

    - Windows : AWS Systems Manager Run Command 사용 

- 스냅샷 복원

- 스냅샷 수명 주기 관리

    - 정책에 따라 스냅샷 백업, 리전 간 복제, 복원 등 자동화

AWS Backup

백업 계획 생성 : 빈도, 수명 주기 설정

리소스 할당 : EBS, RDS 등...

백업 저장소 관리 : S3에 저장

Amazon EFS (Elastic File System)

- 서브넷 단위로 탑재대상을 구성해 해당 서브넷의 인스턴스들이 접근할 수 있게 한다.

- ENI에 탑재된다.

- FSx : for Windows

- FSx for Lustre

Module 10b : 객체 스토리지

Amazon S3 (Simple Storage Service)

- 인터넷용 오브젝트 스토리지

- 리전 레벨

Amazon S3 복제

CRR(Cross Region Replication), SRR(Same Region Replication) 활성화

CRR 장점 : 내결함성, 접근성이 높다

Public Access 차단

Account Setting에서 설정하면 계정 내 모든 버킷에 대해 퍼블릭 접근을 차단한다.

개별 버킷에 대해 설정 가능하다.

- Access Analyzer 지원

- Access Logs 저장 가능 (또 다른 버킷에 저장)

Amazon S3 이벤트 알림

- SQS 대기열

- SNS 알림

- Lambda 함수

Amazon S3 버전 관리

버전 관리 기능을 활성화해 버전별로 관리해서 복구가 가능하게 한다.

Amazon S3 객체 잠금 모드

- governance mode

    - 변경 X

    - 삭제 X

- compliance mode

    - 변경 X

    - 삭제 X (Account 포함)

S3 Intelligent-Tiering

Standard, Standard IA(Infrequent Access), One Zone IA, Glacier, Glacier Deep Archive 등 여러가지 티어로 AWS에서 지능적으로 데이터를 옮기고 관리해준다.

S3 수명 주기 작업

- 수동적으로 정의해서 자동화시킬 수도 있음

- 대상 지정 후 동작 선택

S3 Glacier

- 데이터 하나하나가 아카이브

- 아카이브들이 있는 곳이 저장소

- 호출 옵션

    - 신속 : 1~5분

    - 스탠다드 : 3~5시간

    - 대량 : 5~12시간

    - SNS를 통해 완료 알림 수신 가능

Module 11 : 비용 보고서, 알림, 최적화

과거, 현재, 미래 비용 인식

지출 변화 파악 요구

AWS 계정 기록

- 결제 대시보드

- pdf 포맷 청구서

AWS Cost Explorer

- 가계부같은 개념

- 최대 13개월치 기록을 볼 수 있음

- 데이터 그룹화 및 필터링

- 바, 스택, 라인 3가지 시각화 타입 지원

- 일별, 월별 Forecast 제공

AWS CUR (Cost and Usage Report)

- 보고서 생성 요청 시 지정한 S3 버킷에 보고서를 저장한다.

- 버킷 처리 지원

    - Amazon Athena

    - Amazon QuickSight

    - Amazon RedShift

    - text/csv

AWS CUR 쿼리 자동화

1. CloudWatch Events(시간 기반)

2. AWS Lambda

3. Amazon S3

4. Amazon SNS

AWS Budgets

- 비용 또는 사용량이 임계값을 초과할 경우 알림을 생성하거나 조치를 트리거링한다.

- 고정 지출 및 유동적인 지출에 대해 예산 설정

- Amazon Chime 또는 Slack으로 AWS Chatbot을 통해 알림 가능

AWS Cost Management

- 사용률이 높지 않은 비용이 발생하는 제품 확인

- Savings Plan 및 현재 비용과의 차이 확인

AWS Trusted Advisor

AWS Support Plan이 비즈니스 레벨 이상일 때 비용 최적화에 대한 안내까지 제공

- Amazon EC2 예약 인스턴스

- 사용률이 낮은 리소스 확인

- 기타 14가지 점검

AWS Compute Optimizer

AWS 인프라 및 CloudWatch 지표 기반으로 머신 러닝을 통해 워크로드에 더 나은 AWS 리소스 추천

새로운 인스턴스 타입

새 인스턴스 타입은 보다 효율적으로 하드웨어 리소스를 사용하기 때문에 새 인스턴스 타입 출시 시 사용하는 것이 비용 효율적일 수 있다.

AWS 한국 블로그

https://aws.amazon.com/ko/blogs/korea/

AWS 새로운 소식

https://aws.amazon.com/ko/new/

AWS 공식 강좌 (한국어/무료)

https://explore.skillbuilder.aws/learn/external-ecommerce;view=none?ctldoc-catalog-0=l-_ko

Module 7 : 시스템 상태 모니터링 및 유지 관리

AWS CloudWatch

- Metric(지표)

    - key:value(cpu:80)

    - 표준 지표 : AWS에서 수집하여 자동적으로 제공

    - 사용자 지표 : App 성능 지표에 따라 사용자 설정

    - 디폴트 수집 간격 : 5분

        - Detail Monitoring 선택 시 1분 간격 수집 + 추가 비용

        - 사용자 지표 사용 한정 초 단위 주기 설정 가능

- logs

    - App, DB 서버 등의 로그를 텍스트 형태로 적재

    - Filter 기능을 통해 Key:Value 형태로 변환 가능

        - 설정한 Agent가 CloudWatch로 보내 Metric으로 사용 가능

    - 텍스트 형태 데이터이기에 저장 비용이 비싸다.

        - 그래서 S3에 보관하는 것을 권장

- Alarm(경보)

    - 설정한 Metric 임계값에 따라 Event Driven으로 Auto Scaling, SNS 이벤트 알림 또는 Lambda 로직 수행 가능

    - 상태

        - Alarm : 지표가 임계값에 도달

        - OK : 지표가 임계값 미만

        - Insufficient : 지표에 대한 데이터가 불충분

- Event

    - Rule Event (Event 대처 자동화)

        - 대상 지정 → 상태 지정 → 처리

            - ex) EC2 인스턴스 1번 → stop 상태 → 관리자에게 SNS

    - Schedule Event

        - 지정 시간에 Lambda 함수 등을 실행할 수 있다.

            - ex) 오전 8:50 개발용 인스턴스 start, 오후 6:00 개발용 인스턴스 stop

Auto Scaling (Advanced)

기존 EC2 인스턴스에 대해서만 적용되는 Auto Scaling이었지만 점점 그 가용 범위를 넓혀가고 있다.

Auto Scaling 효율성

인스턴스가 뜨는 시간으로 인해 스케일링 시 즉각적인 반영이 어렵다. 때문에 AMI와 user-data 스크립트 등을 조정해 효율성을 높여야 한다.

- AMI Baking 전략

    - Raw Bake : 환경이 바뀔 것을 고려해 최소한의 구성만 이미지로 만든다. 가볍기 때문에 인스턴스가 빨리 뜬다.

    - Half Bake : Raw와 Full 사이

    - Full Bake : 모든 구성을 포함한 무거운 AMI를 만든다.

        - Netflix는 Full Bake 사용

Auto Scaling on RDS

DBA가 조정하던 데이터베이스의 스토리지를 Auto Scaling을 통해 자동화 할 수 있다.

- RDS 설정

    1. DB 엔진 선택

    2. EC2 타입 선택 (ex: db.t3.small)

    3. Storage 지정 - Auto Scaling 적용 가능

Aurora Read Replica(RR)

Master DB에는 쓰기 작업만 하여 I/O Limit을 줄이고 Aurora 기준 최대 15개 복제본들을 통해 읽기 작업을 한다.

이 때 이 Read Replicas를 Auto Scaling을 통해 관리할 수 있다.

Module 8 : 데이터 보안 및 시스템 감사

IAM Access Analyzer

액세스 권한이 있는 외부 엔티티가 내부 AWS 리소스에 접근을 시도한다면 Access Analyzer가 확인하고 관리자의 정책 설정 실수인지 외부의 악의적인 침입 시도인지 파악해준다.

- 리전 레벨 서비스 : 서울 리전, 도쿄 리전 두 군데에 인프라가 있다면 따로 만들어 사용해야 한다.

- 관리자가 상세 분석된 액세스 정보를 보고 Intended Access 또는 Not Intended의 선택으로 처리할 수 있다.

Permission Boundary

Condition - stringEqual 에서 바운더리를 주어 위임된 관리자가 Full 권한의 새로운 Role을 생성할 경우 보안적 위험 요소를 제거한다. Permission Boundary와 해당 사용자의 권한의 교집합으로 실 권한이 결정된다.

AWS CloudTrail

- Amazon S3에 계정의 모든 AWS 서비스에 대한 API 호출 상호 작용을 기록

- 접근 성공 뿐만 아니라 권한 부족 등으로 인한 실패까지 기록한다.

- 주요 정보

    - userIdentity

    - eventTime

    - eventName

Amazon Athena

SQL을 사용하여 Amazon S3에서 로그 데이터를 분석하는 대화형 쿼리 서비스를 제공한다.

- 서버리스

- S3 버킷 위치만 알려주면 알아서 쿼리해온다.

- 교차 리전 쿼리가 지원됨 (타 리전의 S3).

- Presto 및 Apache Hive 사용 가능

- 데이터를 로드하거나 집계할 필요 없음.

AWS Config

- 인벤토리에 포함된 리소스와 연결된 모든 구성 변경 사항에 대한 세부 정보를 지속적으로 캡처

- 규정 준수 모니터링

- 변경 사항 발생 시 SNS 또는 Lambda 로직 연계 수행 가능

Amazon GuardDuty

- Multi Account 환경에서 지능형 위협 탐지 가능

- CloudTrail 이벤트, VPC 흐름 로그, DNS 로그에 대해 Machine Learning을 통한 분석

- 세부적인 탐지 결과를 활용하여 블랙리스트/화이트리스트 등 조치를 취한다.

- GuardDuty → CloudTrail Logs → Filtering → CloudTrail Event Rule → AWS Lambda → NACL 조정

    - Lambda 함수에 대해 미리 작업에 필요한 IAM Role을 부여해야 한다.

Amazon Inspector

AWS의 보안 전문가가 모범 사례를 지속적으로 올린다.

사례에 따라 탐지하고, 탐지 결과 보고서를 생성한다.

인시던트 자동화

AWS Config 및 AWS Systems Manager Automation, AWS CloudTrail, AWS Lambda를 연계해 인시던트 자동화가 가능하다.

AWS Certification Guide

https://github.com/serithemage/AWSCertifiedSolutionsArchitectUnofficialStudyGuide

Module 6a : 고가용성 시스템 구성

Elastic Load Balancing

- 사용자 트래픽의 부하분산

- 타겟 인스턴스의 헬스체크

- 리전 레벨 서비스

    - 인스턴스에 대한 관리

- CLB, NLB, ALB, GLB

- 인스턴스에 대한 SG 설정 가능

- Web - WAS - DB 3Tier 구조의 사이에 ELB 배치 가능

- Auto Scaling 및 CloudWatch를 통한 모니터링 가능

ELB Access Logs

- Access logs 옵션을 활성화하고 S3 버킷을 잡아주어 사용할 수 있다.

- gzip으로 압축하여 저장된다.

- 포함되는 정보

    - 요청 타임스탬프

    - 클라이언트 IP 주소

    - 대기 시간

    - 요청 경로

    - 서버 응답

ELB HTTP Error Codes

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#load-balancer-http-error-codes

Amazon Route 53

- 리전에 대한 상태 확인 및 장애 조치 수행

- 100% 사용 가능한 서비스 수준 계약(SLA)

- 타 도메인 서비스로부터 도메인 네임을 이전 가능

- Record Set에 Primary, Secondary... 리전 설정

- Health Checker 생성 및 주기 설정

    - 응답이 오지 않을 시 해당 리전에 대해 Record Set 업데이트

- 글로벌 레벨 서비스

    - 리전에 대한 관리

Alias 기능

아래와 같이 도메인에 대한 앨리어스가 가능하다.

app.examplecorp.com ↔ web-app.us-west-2.elb.amazonaws.com

Route 53 라우팅 정책

- 단순 라우팅 정책

    - 인스턴스를 1개만 사용할 때

- 가중치 기반 라우팅 정책

    - 블루/그린 배포에서 점진적으로 트래픽 비율을 바꿀 때 사용

- 지연 시간 라우팅 정책

- 장애 조치 라우팅 정책

- 지리 위치 라우팅 정책

    - 사용자의 위치에 따라 해당 지역의 언어로 서비스를 제공하거나 특정 지역을 차단해야 할 때 사용

- 지리 근접 라우팅 정책

    - 최소한의 네트워킹 거리를 위해 가장 가까운 엣지 로케이션에 연결

- 다중 응답 라우팅 정책

Module 6b : 크기 조정 자동화

EC2 Auto Scaling 구성 단계

1. Launch Configuration(Legacy)/Template 생성

    - 인스턴스 구성

        - 인스턴스 유형

        - 보안 그룹(SG)

        - 인스턴스 키 페어

        - AMI

        - 스토리지

        - IAM 역할

        - 사용자 데이터

2. ASG(Auto Scaling Group) 생성

    - 조정 범위 설정

        - Min

        - Max

        - Desired

    - ELB와 통합 가능

    - 인스턴스를 여러 가용 영역에 분산 및 밸런싱 가능

3. Auto Scaling 정책 선택 및 구성

    - 정책 트리거 방법

        - 예약됨

            - 배치성 업무

        - 수동

        - Amazon CloudWatch 제어

            - 실시간 이벤트(Event Driven?) 모니터링을 통한 동적 제어

            - ex) CPU 사용량 50% 이상 시 인스턴스 1개 추가

    - 확장 또는 축소의 정도

        - ChangeInCapacity

        - ExactCapacity

        - ChangeInPercent

Launch Template

- 기능

    - 버전 관리

    - 재사용

    - 업데이트

- 고급 세부 정보 설정

    - IAM 인스턴스 프로파일(Role)

    - 종료 방지(Terminate)

    - 세부적인 CloudWatch 모니터링

    - 라이선스 구성

    - 사용자 데이터 스크립트(=NCP의 Init Script)

Auto Scaling Status Checks

- System Status Checks (1/2)

    - EC2 인스턴스가 실제 돌고 있는 물리적인 서버에 대한 상태 점검

- Instance Status Checks (2/2)

    - EC2 인스턴스 자체에 대한 상태 점검

- ELB에서의 상태 체크 옵션도 같이 선택하여 빠른 주기의 검사를 수행할 수 있다.

안정된 상태의 Auto Scaling Group 생성

핵심 서비스가 아닌 간단한 서비스를 하나의 ASG로 묶은 후 Min, Max, Desired 값을 모두 같은 값(인스턴스 수)으로 주어 인스턴스 실패 시 새로운 인스턴스를 재시작하게 함으로 부가 서비스들을 안정적으로 운영할 수 있다.

Auto Scaling 정책

- 예약된 조정

    - 특정 날짜 또는 시간을 지정한다.

- 동적 조정: 단순 조정 정책

    - 대상 리소스 사용량이 특정 임계값을 초과하면 스케일링 한다.

- 동적 조정: 단계 조정 정책

    - 단순 조정과 유사하나 사용량에 대해 세부적인 단계를 구분하여 보다 효율적인 스케일링을 수행한다.

- 동적 조정: 대상 추적 정책

    - 마치 에어컨 온도 설정과 같이 지표에 대한 지정 값을 설정하면(예: CPU 사용량 50%) 트래픽이 급증하여 CPU 사용량이 50%가 넘어가면 50% 이하로 떨어질 때까지 EC2 인스턴스를 계속 추가하는 방식이다.

- 예측 정책

    - AWS에서 과거의 리소스 증감량 등의 데이터를 기반으로 머신러닝을 통해 예측하여 스케일링 해주는 방식이다.

축소 종료 정책 (Termination Policies)

- Default

    - 각 가용영역에 인스턴스가 고르게 분포되도록 Scale In 한다.

- Allocation Strategy

    - ASG에서 인스턴스를 종료하여 나머지 인스턴스를 정의된 allocation strategy에 맞게 정렬해 온디맨드 용량 또는 스팟 용량을 충족한다. 이 정책은 선호하는 인스턴스 유형이 변경된 경우 유용하다.

- Newest Instance

    - 최신 인스턴스를 종료한다. 새로운 시작 구성을 테스트하지만 프로덕션 상태로 유지하고 싶지 않은 경우 유용하다.

- Oldest Instance

    - 가장 오래된 인스턴스를 종료한다. ASG의 인스턴스들의 타입을 변경할 때 점진적인 교체가 가능하다.

- Oldest Launch Template

    - 가장 오래된 런치 템플릿을 가진 인스턴스를 종료한다. 그룹을 업데이트하고 이전 구성에서 인스턴스를 단계적으로 종료할 때 유용하다.

- Oldest Launch Configuration

    - Oldest Launch Template과 같다.

- Closet To Next Instance Hour

    - 다음 번 결제 시간에 가장 근접한 인스턴스를 종료한다. 시간제로 요금이 청구되는 인스턴스의 사용을 극대화할 수 있게 한다.

스래싱 방지

스래싱이란 Scale Out/In이 짧은 간격으로 발생해 인스턴스의 생성과 삭제를 지속하는 현상이다(Ping Pong).

- 경보 지속 기간

    - 10분 동안 CPU 사용량이 50% 초과한다면 Scale Out

- 휴지 기간

    - 5분 동안 조정을 일시 중지

- 인스턴스 워밍업 기간

    - 인스턴스가 올라온 후 5분 간 사용하지 않는다.

오픈소스 로드 테스트 도구

- The Grinder

- JMeter

EC2 요금 옵션

- On-demand 요금제 (default)

    - 상대비용: 100

    - 원할 때 사용 및 중지 가능

    - 사용한 만큼 시간(Hour) 단위로 지불

    - 새로운 사업 또는 프로젝트 진행 시 사용해보고, 길게 운영할 것 같다면 RI로 전환하는 것도 좋다.

- 예약(RI=Reserved Instance) 요금제

    - 상대비용: 35 (온디맨드 대비 최대 65% 저렴)

    - 1년, 3년, 선불, 부분, 후불 등의 옵션이 있는 약정 형태.

    - 사전 신청 필요

    - 약정 중도 해지 불가

    - 긴 기간 동안 리소스의 유휴 시간 없이 쭉 사용한다면 유리하다.

- Spot Instance 요금

    - 상대비용: 10 (온디맨드 대비 최대 90% 저렴)

    - 시장 가격에 따라 결정

        - 여분 리소스가 많으면 AWS에서 가격을 낮춰 Spot Instance 사용 유도

        - Spot Instance 사용자가 많아 여분 Pool이 줄어들면 가격 상승

        - 사용하고 있는데 시장가가 오르면 2분 전에 알리고 회수해간다.

    - AWS의 여분의 하드웨어 리소스를 제공

    - 시간에 여유가 있고 컴퓨팅 리소스가 중지되어도 괜찮은 경우 사용한다.

    - Spot Instance를 얼마나 많은 비율로 사용하는가에 따라 지불 비용이 크게 달라진다.

비용 효율적 Auto Scaling

ASG에서 Scale Out 시 1차 시도로 설정한 가격에 따라 Spot Instance를 생성함으로 하고, 지정 가격보다 시장가가 높다면 2차로 On-demand로 인스턴스를 생성하는 방식 등으로 비용 효율적인 운영이 가능하다.

AWS License Manager

타사 제품의 유료 라이센스를 관리해주는 도구이다. 하드웨어 제한을 통해 초과요금이 발생하지 않게 한다.

1. 라이센스 구성 만들기

2. AMI에 라이센스 구성 연결

3. 인벤토리 검색 및 라이센스 추적

4. 알림을 사용하여 라이센스 제어 및 관리

문제 해결

오류 메시지: AMI<AMI ID>(은)는 대기 중이며 실행할 수 없습니다.

→ 새로 생성되어 준비 중인 AMI일 수 있다. 조금 기다린 후 재시도해본다.

오류 메시지: 요청된 구성이 현재 지원되지 않습니다.

→ 경우에 따라 Launch Template에 구성한 인스턴스 타입(ex: t2.small)의 하드웨어 장비가 해당 AZ에 존재하지 않을 수 있다. 인스턴스 타입을 변경한다.

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파일 작성하듯이 수동으로 들여쓰기로 했다.

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

Sysops 과정은 총 12개 모듈로 구성되어 있으며, 개중에 한 단계 더 분리된 모듈도 존재한다.

Tess와 Arch에서 배운 기초적인 내용이 포함되어 있어 복습 목적의 정리 또한 병행한다.

Module 1 : Systems Operations on AWS 소개

Region

• AWS 서비스가 제공되기 위한 인프라의 논리적인 위치
• 지리적 대표 도시명으로 나타낸다.
• 멀티 AZ로 DR(Disaster Recovery) 구성을 위해 반드시 2개 이상의 AZ가 포함되어야 한다.
• 현재 25개 리전 존재

Availability Zone

• 하나 이상의 데이터센터를 클러스터로 묶은 논리적 단위
• 현재 81개 AZ 존재

Edge Location

• AWS Route53, AWS CloudFront, AWS WAF 등 글로벌 서비스를 위한 인프라
• Region, AZ와 다르게 사용자가 지정할 수 없음

AWS Well-Architected Framework

• AWS 아키텍처 모범 사례를 포함한 백서
• 5가지 핵심 요소
  • 보안
  • 안정성
  • 성능 효율성
  • 비용 최적화
  • 운영 우수성

AWS Well-Architected Tool

• WAF와 다르게 Management Console의 툴로써 제공되며, 일련의 질문에 대답하며 더 간편하게 인프라 구조를 검토할 수 있다.

시스템 운영의 요소

• 배포
  • 인프라 환경의 구성

• 모니터링
  • 모니터링을 통해 개선점 등을 발견
• 고도화
  
  • 구조의 효율성을 위한 변경
• 보안
  • 권한의 핸들링 등 보안 솔루션 관리
• 최적화
  • 고도화와 유사하게 시스템 최적화

운영 우수성 원칙

• 설계 원칙
  • 코드형 작업 수행
  • 작은 규모로 손쉽게 롤백이 가능한 변경 수행
  • 운영 절차의 지속적 개선
  • 장애 예측
  • 모든 운영 실패에서 교훈 습득

단계별 운영 우수성 핵심 서비스

• 준비
  • AWS Trusted Advisor
  • AWS CloudFormation
  • AWS 개발자 도구
  • AWS X-Ray
  • AWS Config
  • AWS Systems Manager
• 실행
  • Amazon CloudWatch
  • Personal/Service Dashboard
  • Amazon CloudWatch
  • Amazon ElasticSearch
  • Amazon SNS
  • Auto Scaling
  • AWS Systems Manager
• 개선
  • Amazon QuickSight
  • Amazon Athena
  • Amazon S3
  • Amazon CloudWatch
  • Amazon Machine Image
  • Amazon SNS
  • AWS Lambda
  • AWS CloudFormation

AWS Trusted Advisor

• 비즈니스 레벨 이상의 AWS Support Plan을 이용할 때 제공받을 수 있는 유지 보수에 대해 도움을 주는 서비스이다.
• https://aws.amazon.com/ko/premiumsupport/plans/

AWS Simple Monthly Calculator

• 리소스에 대한 월별 지불할 비용을 계산해주는 서비스
• 예산 산출에 이용된다.
• 현재 콘솔 상에서 이용하는 AWS Pricing Calculator 개발로 인해 Deprecate 예정이다.
• https://calculator.s3.amazonaws.com/index.html?lng=ko_KR

AWS Cost Explorer

• 비용 및 사용량에 대한 데이터를 분석하여 시각적으로 확인할 수 있게 해주는 서비스
• 가계부와 비슷하다고 볼 수 있음
• https://aws.amazon.com/ko/aws-cost-management/aws-cost-explorer/

Module 2a - 액세스 관리

IAM (Identity and Access Management)

• 인증
  • 맞는 사용자(관리자)인지 확인
  • Management Console 접근은 사용자 ID와 PW, CLI와 SDK 접근은 액세스 키와 시크릿 액세스 키로 인증
• 인가
  • 관리자에 대해 권한을 제어
  • JSON 파일로 Policy를 지정
  • 권한을 할당할 때 최소 권한의 원칙 준수

IAM 권한 유형

• 자격 증명 기반 정책
  • IAM 사용자 종속 
  • 리소스에 관계없이 IAM 사용자에게 권한을 지정한다.
• 리소스 기반 정책
  • 리소스 종속 
  • 리소스에 대한 특정 IAM 사용자의 권한을 지정한다. 
  • 자격 증명 기반과 달리 JSON 파일에 Principal 속성이 포함되어 있다. IAM 사용자를 나타낸다.

STS & Role

• 임시 자격 증명
• 강사가 사옥에 들어갈 때 방문증을 받듯이 임시로 역할을 부여
• STS와 Role은 같이 동작한다.
  • STS가 임시 자격 증명을 발행한다.
  • Role이 권한을 위임한다.

연동 사용자

• SAML 2.0 또는 OpenID Connect를 통해 외부 사용자와 신뢰 관계를 맺는다.
• 이후 STS와 Role을 통해 임시 접근 자격을 부여한다.

IAM 그룹

• IAM 사용자의 모음
• 한 IAM 사용자는 여러 그룹에 속할 수 있음
• 권한은 IAM 정책을 통해 부여됨
• 그룹을 중첩할 수 없음
• 그룹은 보안 주체가 아님

Role on Resource

EC2 인스턴스의 어떤 애플리케이션이 S3 또는 DynamoDB와 상호 작용을 해야한다고 가정했을 때, 애플리케이션에 Role을 부여해서 접근 권한을 지정해 상호 작용을 할 수 있게 한다.

PassRole

Role을 부여할 수 있는 관리 권한

정책 평가 우선순위

• 명시적 Deny : Deny
• 명시적 Allow : Allow
• 명시적 Allow + 명시적 Deny : Deny
• 명시되어 있지 않음 : Deny

Policy 항목 5가지 : 예시 

1. (Required) Resource : EC2
2. (Required) Action : stop / start
3. (Required) Effect : allow / deny
4. (Optional) Condition : 특정 IP 지정 등 조건 지정
5. (리소스 기반 정책) Principal : IAM 사용자 아이덴티티 기술

Policy 생성 방법

• 편집기로 JSON 문서 작성
• AWS 관리형 정책 사용
  • 수정, 편집 불가
• IAM Policy Generator/Simulator 등의 GUI 기반 툴을 통해 생성

자격 증명 관리

• 환경 간 권한은 일관되어야 한다.
• IAM 자격 증명 보고서 검토
  • 주기적 액세스 키 교체
  • 불필요한 자격 증명 삭제

ARN (Amazon Resource Name)

Policy에 리소스 아이덴티티를 기술할 때 사용된다.

AWS Organizations

개발 계정, 테스트 계정, 프로덕션 계정, 공유 서비스 계정 등 여러 계정을 하나의 엔터프라이즈 기업에서 부서별로 관리할 수 있게 해주는 서비스이다.

• 중앙 집중식 계정 관리 및 감사
• 자동화된 계정 생성 및 관리
• 그룹 기반 계정 관리
• 서비스 비용 통합 결제
• SCP(Service Control Policy) : OU(Organization Unit), 루트 계정에도 액세스 제어가 가능
• 트리 구조로 조직도와 같이 구성된다.

Module 2b : 시스템 검색

AWS 리소스와의 상호 작용

• AWS Management Console
  • GUI 관리 툴을 사용해 AWS 서비스에 접속
• AWS CLI
  • 명령어를 통해 AWS 서비스에 접속
• SDK
  • 대부분의 주요 프로그래밍 언어에서 AWS 서비스 API 호출

AWS CLI

• 명령어 구조 : Service - Operation - Parameter - Options
• 단계마다 help 명령어가 전부 제공된다.

Commands & Options

• aws configure 명령어를 통해 액세스 키, 시크릿 액세스 키, 리전 이름, 출력 형식 등을 설정할 수 있다.
• --dry-run
  • 명령어를 실행하지 않고 권한만 확인한다.

AWS Session Manager

• IAM 정책으로 중앙 집중식 액세스 제어
  • 이 때문에 SSH 등 보안성 통신이 아니어도 보안적 이슈가 생기지 않는다.
• Windows, Linux 크로스 플랫폼 지원
• VPC Endpoint를 통해 EC2 인스턴스에 리모트로 연결
  • Jumping Host 없음
  • 인바운드 포트 불필요 (내부적으로 포트포워딩)
  • SSH 키 없음
  • ssm-user에 대한 관리 권한
• 세션 활동 및 로깅 감사
  • AWS CloudTrail (API 호출 로그)
  • Amazon S3
  • Amazon CloudWatch

AWS Systems Manager

리소스를 규모에 따라 안전하게 관리하고 운영할 수 있도록 지원한다.

• 그룹 리소스 (업무 단위로 그룹핑)
• 데이터 시각화
• 작업 수행
• 에이전트 기반

AWS Config

변경 사항을 일관된 형식으로 기록하고 정규화한다. 사내 인프라에 대한 규정을 준수하게 하는 목적.

• 리소스 검색
• 레코드 구성
• 변경 사항 캡처
• 변경 사항 분석 및 문제 해결
• Organizations 환경에서 복수 계정 인벤토리 데이터가 하나의 대시보드에 표시될 수 있다.
• 설정 프로세스
  1. 설정 지정
  2. 규칙 선택
  3. AWS Config에서 리소스 기록 시작
  4. 데이터 보기

AWS Config 규칙

• 관리형 규칙
  • AWS에서 정의하고 관리
  • 구성이 거의 또는 전혀 필요없음
• 사용자 지정 규칙
  • 고객이 정의 및 유지
  • AWS Lambda 사용

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 웹 애플리케이션 아키텍처 예시

Amazon SNS vs. Amazon SQS

Amazon SQS (Simple Queue Service)

아마존의 완전관리형 메시지 서비스이다. 마이크로 서비스 아키텍처를 위한 발신자와 수신자 간 버퍼의 역할을 담당한다. 하루에 수십억 건의 메시지를 처리할 수 있으며, Multi-AZ로 고가용성을 확보해 단일 리전 내에 모든 메시지 대기열과 메시지를 저장한다. 

SSE(Server Side Encryption)는 AWS KMS(Key Management Service)에서 관리하는 키를 사용하여 Amazon SQS 대기열의 메시지 콘텐츠를 보호한다. SSE는 Amazon SQS가 메시지를 수신하는 즉시 이를 암호화해 저장하며, 권한이 있는 사용자에게 전송할 메시지만 복호화한다.

메시지 하나 당 최대 256KB의 용량을 가지며, Producer - Consumer의 관계로 데이터를 처리할 인스턴스(소비자)가 큐(생산자)에 접근하여 능동적으로 메시지를 가져간다(Polling).

여러 애플리케이션에서 동시에 하나의 메시지를 처리하면 경합이 발생할 것이므로 가시성 제한 시간을 두어 하나의 애플리케이션에서만 처리할 수 있게 한다. 일반적으로 이 시간동안 메시지를 처리한 후 처리 완료한 메시지를 대기열에서 삭제한다. default는 30초이며, 0초~12시간 범위에서 설정 가능하다.

애플리케이션 예외 또는 트랜잭션 장애가 발생하면 Amazon SQS DLQ (Dead Letter Queue)로 리디렉션하여 나중에 다시 처리하게 할 수 있다.

Amazon SNS (Simple Notification Service)

Publisher - Topic - Subscriber의 구조로 퍼블리셔가 하나의 토픽으로 게시물을 게시하고(Pushing), 구독자는 게시물에 대한 알림을 받는 구조라고 볼 수 있다. 주로 애플리케이션에 대한 변경점에 이벤트를 걸어 특정 조건에서 트리거링 되게끔 설정한다. 예를 들어 Amazon S3에 새로운 데이터가 업로드 되었는데, 그 중 특정 컬럼값이 0이라면 푸시한다.

또한 당연히 Amazon SNS에 게시된 모든 메시지는 여러 서버와 데이터 센터에 걸쳐 저장된다.

Pushing : 흔히 푸시 알림이라고 하는 것이 이것이다. 

Amazon SNS의 구독 유형은 아래와 같다.

• Email/Email-JSON : 등록된 이메일 주소로 텍스트/JSON객체가 전송된다. 
• HTTP/HTTPS : 등록된 URL로 HTTP POST를 통해 알림이 전송된다.
• SMS 클라이언트 : 등록된 전화번호로 SMS 문자 메시지가 전송된다.
• Amazon SQS Queue : SQS 대기열에 알림 메시지가 추가된다(FIFO 대기열은 불가).
• AWS Lambda 함수 : 람다 함수에 메시지를 전송하여 후속적인 처리를 할 수 있다.

Amazon SQS에는 리콜 옵션이 없다. 메시지가 성공적으로 전송되면 이를 회수할 수 없다. 또한 주문 및 전달을 보장할 수 없다.

Amazon MQ (Message Queue)

Amazon MQ를 이용해 On-premise에서 사용하고 있는 Apache Active MQ와 연결된 하이브리드 시스템을 만들 수 있다.

또한 각 Amazon MQ를 서로 다른 AZ에 Primary와 Standby로 이중화하여 사용한다.

Micro Service (Container)

각 서비스들이 Tightly Coupled 되어 있는 Monolithic 방식은 한 애플리케이션이 Failure되면 전체 구조에 문제가 생기기 때문에 Loosely Coupled하게 구조화함으로써 독립적으로 만든다. 기본적으로 서비스들을 격리해놓고 서비스 간 통신은 REST API로 한다.

한 애플리케이션의 Code, Library, Dependency, Configuration 등을 패키지화 해서 하나의 컨테이너 이미지로 만들 수 있다. 컨테이너는 Hardware Level의 VM과는 달리 OS Level에서 만들고 운용되기 때문에 처리 속도가 더 빠르다(Docker Engine의 사용으로 GuestOS가 없음).

종속성, 라이브러리 등이 컨테이너 이미지 안에 전부 포함되어 있기 때문에 환경에 구애받지 않고 컨테이너를 돌릴 수 있다는 장점도 있다.

Amazon ECS(Elastic Container Service) / EKS(Elastic K8S Service)

Containers on EC2 Instances

위의 사진과 같은 구조로 볼 수 있다. 여러 개의 EC2 인스턴스들을 묶은 Amazon ECS Cluster 위에서 컨테이너가 실행되는 것이다.

ECS는 실행하는 노드 플릿을 유지 관리하고 확장한다. 또한 컨테이너의 배포를 모니터링하며, 클러스터의 전체 상태를 관리한다(인스턴스의 Auto Scaling 포함). Fargate 또는 EC2 두 가지 유형으로 시작 가능하다.

컨테이너 관리를 Docker가 하면 ECS, k8s가 하면 EKS이다. 

전체적인 ECS의 구조는 위와 같다. 마이크로 서비스로써 분리한 3가지의 서비스를 ALB를 통해 접근할 수 있다.

ECR(Registry)

컨테이너 이미지를 보관하는 레지스트리이다. ECS에서 컨테이너를 생성할 때 이곳을 참조해 이미지를 가져온다. 도커 허브와 비슷한 공간이라고 보면 된다.

Serverless

서버리스라고 해서 실제로 서버가 없는 것은 아니고 본인이 관리할 서버가 없다는 것이다.

서버리스는 개발자 등 인프라에 대한 지식이 충분하지 않은 사람이 앱과 서비스를 서버 위에서 실행할 수 있도록 AWS에서 서버를 자동적으로 관리해주는 서비스이다.

AWS Fargate - 완전 관리형 컨테이너 서비스

AWS Fargate는 완전관리형 컨테이너 서비스로써 모든 런타임 환경과 규모를 자동적으로 조정한다.

• 클러스터 프로비저닝 및 관리
• 런타임 환경 관리
• 규모 조정
• ECS 및 EKS 실행 가능

AWS Lambda

• 완전 관리형 컴퓨팅 서비스
• 상태 비저장 코드 실행
• Node.js, Java, Python, C#, Go, Ruby 지원
• 일정 또는 이벤트에 대한 응답으로 코드 실행=Kicking (ex: Amazon S3 버킷 또는 Amazon DynamoDB 테이블의 데이터 변경)
• 엣지에서 실행 가능(Node.js only)
• 구성이 아닌 애플리케이션에 집중
• 요청 시에만 컴퓨팅 리소스 사용
• 마이크로 서비스 아키텍처 구축
• 월별 100만 건 호출까지 무료
• 메모리 사이즈 범위 128MB~3GB를 64MB씩 46단계로 분류(CPU는 메모리에 맞춰 변경됨)되어 비용 발생
• 최대 15분 동안만 명령을 실행할 수 있기 때문에 하루종일 운용해야 하는 서비스의 경우엔 서버리스가 아닌 수동으로 EC2 인스턴스를 만들어 실행하는 편이 낫다.

AWS Lambda가 처리하는 작업

• 서버
• 용량 요구
• 배포
• 조정 및 내결함성
• OS 또는 언어 업데이트
• 지표 및 로깅

AWS Lambda 응용 아키텍처 시나리오

API Gateway

애플리케이션의 현관 역할을 하는 API를 생성할 수 있다.

최대 수십만 건의 동시 API 호출을 처리한다. Amazon EC2, AWS Lambda, 모든 웹 애플리케이션에서 실행되는 워크로드를 처리할 수 있다.

API Gateway를 사용함으로써 엔드포인트 노출 방지, DDoS 및 스크립트 주입 공격으로부터 보호된다.

API Gateway는 API 키를 생성하여 개발자에게 배포하고, 서명 버전 4를 이용해 API에 대한 액세스를 승인한다. 또한 AWS Lambda와 긴밀하게 통합된다.

API Gateway를 활용해 위와 같은 아키텍처를 가져갈 수 있다.

RTO/RPO - Backup

RTO (Recovery Time Objective)

장애가 발생했을 경우의 목표 복구 시간이다. 실제로 애플리케이션을 사용할 수 없는 시간을 의미한다.

RPO (Recovery Point Objective)

장애가 발생했을 경우 그 이전의 알려진 상태로의 롤백할 포인트를 의미한다. 쉽게 말해 백업 주기라고 할 수 있다.

AWS Backup

• 중앙 집중식 백업 관리
• 정책 기반 백업 솔루션
• 태그 기반 백업 정책
• 자동화된 백업 일정 관리

Recovery

위의 다이어그램은 인프라 복구 방법 중 파일럿 라이트 방식이다. 온프레미스에서 기본적으로 서버를 구동하고 있으며, AWS 측엔 실행 중이 아닌 준비된 인스턴스(Seed Light=불씨)들이 있고 Standby DB가 미러링 되어지고 있다.

온프레미스 측에서 Failure가 나면 몇 분 안으로 AWS의 인스턴스가 올라오고 서비스를 지속할 수 있게 된다. 

파일럿 라이트 밖에도 비용과 가용성이 높은 솔루션들이 존재한다.

ENI (Elastic Network Interface)

탄력적 네트워크 인터페이스는 가상 네트워크 인터페이스이다.

동일한 가용역역 안에서 EC2 인스턴스 간에 이동할 수 있다.

새 인스턴스로 이동할 때 ENI는 다음을 유지한다.

• Private IP Address
• Elastic IP Address
• MAC Address

VGW(Virtual GW) & CGW(Customer GW)

VGW란 VPC마다 하나씩 존재할 수 있는 가상 프라이빗 게이트웨이이다.

VGW를 통해 다른 VPC와 통신하거나 고객의 On-premise 네트워크에 연결할 수 있다.

이 때 고객 쪽의 게이트웨이는 CGW라고 한다.

하나인 VGW에 여러 회선을 연결하여 사용할 수도 있으며, 연결 방식은 AWS Direct Connect와 VPN으로 나뉜다.

AWS Direct Connect (DX) vs. VPN

DX - 중요

DX는 AWS와 협약을 맺은 회사들로부터 제공되는 전용선을 통해 통신을 하는 것이다.

VPN 방식에 비해 Network Bandwidth가 확보되고, 보안적 측면에서의 이점도 확실히 가져갈 수 있다는 장점이 있다.

현재 DX Location을 제공하는 파트너는 LG U+, 세종텔레콤, Kinix, Dream Line, Console Connect 이렇게 5개가 있다.

가격대는 DX Partner, Network Bandwidth 등에 따라 천차만별이다.

VPN

통상적으로 쓰이는 방식이다.

인터넷 회선을 통해 통신한다. DX 대비 속도가 떨어지고 보안이 완전하지 않을 수 있다.

보안과 속도가 중요한 케이스에선 DX를 메인, VPN을 보조회선으로 사용하기도 한다.

VPC Peering

2개의 VPC를 직접적으로 연결해 IGW 또는 VGW를 통하지 않고도 서로 간에 통신할 수 있게하는 기능이다.

고가용성 연결로 단일 장애 지점이 없고 대역폭 병목 현상 또한 일어나지 않으며, 트래픽은 항상 글로벌 AWS 백본에서 유지된다. 추가로 서로 다른 리전 간의 연결 또한 가능하다.

2개의 VPC를 각각 Requester와 Accepter로 잡아 Peering Connection을 생성하고, 아래와 같이 각 VPC의 라우팅 테이블에서 서로를 알도록 라우팅해주면 된다.

이를 통해 아래와 같은 인프라를 가져가는 것이 가능하다.

다만 전이적인 Peering은 불가하기에 너무 많은 Peering Connection이 필요할 경우엔 사용하기 힘들다.

n/2 * n-1

연결할 VPC 수를 위 식에 대입하면 만들어야 하는 라우팅 테이블의 수가 나오는데 이 규모가 방대해지면 효율이 크게 떨어지기 때문에 Transit Gateway를 사용해야 한다.

Transit Gateway - 중요

이 방식은 피어링과 달리 VPC 또는 온프레미스 네트워크 간 직접 연결하지 않고 트랜짓 게이트웨이를 통해 연결한다.

하나의 트랜짓 게이트웨이로 최대 5000개의 연결을 관리할 수 있으며, 이 트랜짓 게이트웨이의 라우팅 테이블은 연결된 모든 네트워크를 알고 있다. 

트랜짓 게이트웨이를 통해 아래와 같은 시나리오를 만족할 수 있다.

VPC Endpoint

VPC의 엔드포인트는 다른 AWS 엔드포인트 서비스에 Private하게 연결할 수 있다.

VPC Peering과 비슷하지만, 엔드포인트는 애플리케이션/서비스에 적용한다는 점이 다르다.

엔드포인트에는 두 가지 유형이 있는데, 인터페이스 엔드포인트와 게이트웨이 엔드포인트이다.

Interface Endpoint

ENI와 연결된다. Amazon EC2 API, Amazon SNS, AWS Systems Manager 그리고 다른 AWS 계정에서 호스팅하는 엔드포인트 서비스 등이 여기 포함된다. 

ENI는 EC2 Instance에 달려있는 것이기 때문에 많은 엔드포인트 연결을 필요로 한다면 EC2 Instance 생성 시에 미리 많은 ENI를 생성해 두어야 할 것이다.

Gateway Endpoint

라우팅 테이블과 연결된다. Amazon S3, Amazon DynamoDB가 여기 포함된다.

ELB (Elastic Load Balancing)

연결된 인스턴스들에 대해 주기적으로 Health Check를 하며, 200번 코드를 반환하는 정상 작동 중인 인스턴스에만 요청을 전송한다. 

ELB의 종류

• ALB (Application) : 7계층에서 동작. HTTP 및 HTTPS 트래픽의 고급 로드 밸런싱. RR(Round Robin) 알고리즘을 통한 LB.
• NLB (Network) : 4계층에서 동작. TCP, UDP, TLS 트래픽의 로드 밸런싱. Hashing 알고리즘을 통한 LB.
• CLB (Classic) : 구세대 통합형 LB. EC2 Instance 신규 등록 작업 불가. 예전부터 쓰고 있는 고객들이 있기에 Deprecated 되지 않고 있음.

ELB 동작 원리

위 사진과 같이 2개의 ELB가 배치되며, Internet Facing ELB와 Internal ELB로 나뉜다.

1. Internet Facing에서 Public Subnet의 Instance들에게 Load Balancing을 해주면
2. 그 Instance들로부터 Internal ELB로 전달.
3. 이후 Private Subnet으로 다시 LB된다.

IAM (Identity and Access Management)

말 그대로 인증과 권한에 대한 관리.

IAM의 4개의 주요 Entity는 다음과 같다.

User : 단일 IAM 사용자이다.

User Group : 보통 사내 부서 별로 나뉘어진 개별 그룹이다.

Role(역할) : (모자처럼 생겼으니)모자를 쓰고 있는 Duration만큼 임시 자격 증명.

Policy : AWS Service에 대한 액세스만 제어. User, User Group, Role에 권한 부여. JSON 파일 형식이다.

Federation User

연동 자격 증명 관리. On-premise에서 관리하다가 AWS를 잠깐 관리하기 위해 On-premise의 자격 증명을 받고 AWS에서 권한을 연동해 간단하게 관리할 수 있음.

Root User

결제의 주체. 모든 AWS 서비스와 리소스에 대한 전체 액세스 권한을 갖는다.

Admin 생성 및 사용, Root 접근에 대한 자격 증명 잠금을 하는 것이 안전하다.

IAM 사용자 생성

기본적으로는 묵시적 Access Deny이다. 가장 강하게, 최우선으로 권한을 제한하려면 명시적으로 Deny한다.

AWS Management Console 또는 CLI에 대한 액세스는 명시적으로 부여되어야 한다.

리소스 기반 - 연결된 AWS 리소스 : Amazon S3, Amazon S3 Glacier 등

자격 증명 기반 - 연결된 IAM 보안 주체 : User, User Group, Role