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

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의 인스턴스가 올라오고 서비스를 지속할 수 있게 된다. 

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

WAF (Well Architected Framework)

Web Application Firewall과 헷갈리지 말자.
설계를 검토해주는 역할을 한다.
보안, 안전성, 비용 최적화, 성능 효율성, 운영 우수성 5가지 항목을 확인.

대규모 아키텍처 다이어그램

S3 vs. EBS

S3 (Simple Storage Service)

Region Level로 만들 수 있는 Web 기반의 스토리지 서비스.
위 다이어그램에 있는 양동이 모양의 '정적 자산'이 바로 이 S3이다.
S3 안에 여러 개의 Bucket이 있고, Bucket 안에 Object 단위로 파일을 저장한다.

업로드한 파일의 일부만 변경되어도 전체 파일을 처음부터 다시 업로드해야 하므로 S3에는 정적인 파일을 저장하는 편이 좋다(WORM : Write Once Read Many).
주로 온프레미스, AMI, EBS의 백업 데이터를 저장하며, Data Lake로써 머신 러닝 등에 사용될 수도 있다.
병렬(Load Balancing)로 읽기/쓰기가 가능하다.

1. 파일 1개 당 5TB 이하
2. 업로드 파일 갯수 무제한
3. 스토리지 전체 사이즈 무제한
4. 업로드 횟수 무제한
이라는 특징을 가지고 있다. 업로드 관련 기능은 무료이지만 스토리지로부터 데이터를 GET할 때 비용이 발생한다.

S3 Bucket Policy
Permissions의 Bucket Policy에 JSON 형식으로 Bucket 별 액세스 제어 정책을 정의할 수 있다.
디폴트로는 비공개이며, 외부로부터의 모든 접근 허용 또는 일부 접근 허용 등의 설정이 가능하다.

Amazon S3 Transfer Acceleration
파일의 근원지로부터 S3에 업로드 되기까지 100% 인터넷 회선을 통하는 대신 이동 과정 중간부터는 Amazon CloudFront(One of Edge Location Features)를 이용해 Amazon Backbone Network를 통한 보다 안전하고 신속한 데이터 이동이 가능하다.

AWS Physical Data Transfer Solutions
10TB 초과의 대용량 데이터를 더 빨리 전송할 수 있는 물리적 솔루션이다.
AWS Snowball은 기내용 캐리어 정도 크기의 저장소이다. 약 80TB의 데이터를 물리적으로 운송할 수 있다.
AWS Snowmobile은 대형 트럭 크기의 데이터 트럭이다. 약 100PB의 데이터를 물리적으로 운송할 수 있다.

S3 4 Tiers
S3 Standard
S3 Standard IA (Infrequent Access)
S3 One Zone IA
S3 Glacier (Backup)

아래로 갈 수록 저장 비용↓ 검색 비용 및 속도↓
Glacier는 신속 검색 5분, 표준 검색 3~5시간, 대량 검색 5~12시간이 소요된다.
S3 Intelligent Tiering : AWS에서 자동으로 데이터들을 티어링한다.

ILM (Information Lifecycle Management)

Amazon S3 수명 주기 정책을 사용하면 생성 후 기간을 기준으로 객체를 삭제 또는 이동할 수 있다.

EBS (Elastic Block Store)

하나의 인스턴스에 Attach 되어 종속되어지는 스토리지이다. EBS 1개 당 최대 16TB까지 저장 가능하다.
외장 하드를 구매할 때와 같이 리소스를 Provisioning할 때 그만큼 지불한다.

인스턴스의 데이터 저장용으로 실제 물리적 호스트의 Local Storage 이용 시 인스턴스가 멈췄다가 다시 시작될 경우 다른 물리적 호스트에서 실행될 것이기 때문에(같은 AZ 내일 뿐) 휘발성인 Local Storage가 아닌 별도의 Storage Farm에 있는 EBS를 인스턴스에 매핑시켜 데이터를 저장하게 한다(네트워크를 통한 연결).

Database on AWS

DB 결정 시 고려할 사항으로는 확장성, 총 스토리지 요구 사항, 객체 크기 및 유형, 내구성이 있다.

DB - RDS (Relational Database Service)

AWS에서 관계형 데이터베이스는 Oracle DB, MS-SQL Server, MySQL, MariaDB, PostgreSQL, Aurora 총 6가지를 사용할 수 있다. 이 중 Aurora는 AWS에서 자체 개발한 DB로 완전관리형 데이터베이스이며, MySQL, PostgreSQL과 호환이 가능하다. Aurora를 플랫폼으로 MySQL 사용 시 기존의 최대 5배 처리량, PostgreSQL의 경우 최대 3배.
수직적으로 리소스 조절(Scale Up/Down).

RDS Security
I/O 경합을 막기 위해 Read Replica를 만들어 읽기 부하를 분산시킬 수 있다.
Amazon Aurora는 15개, 나머지 5가지 RDB는 5개까지 Read Replica를 만들 수 있다.
저장 시 KMS를 이용해서 암호화. 통신 시 SSL 암호화 사용.

DB - NoSQL

Document DB : MongoDB
GraphDB : Amazon Neptune, Cassandra
Key-Value DB : Amazon DynamoDB, Redis

DynamoDB는 완전관리형 비관계형 데이터베이스 서비스이다.
Amazon의 전자상거래 서비스에서 일어나는 많은 트랜잭션을 처리하기 위해 개발되었다.
이벤트 중심 프로그래밍(서버리스 컴퓨팅)이다.
수평적으로 리소스 조절(Scale In/Out).

Eventually Consistance Read(DynamoDB default) : 레이턴시 최소화. 게임 등에서 사용한다.
Strongly Consistance Read : 금융권 등에서 사용. 계좌의 잔고가 동기화되지 않으면 큰일이므로 강력하게 읽기 일관성을 정의한다.

DynamoDB Security
Row, Column 등 모든 것에 대해 액세스 권한 부여 가능.
저장 시 KMS를 이용해서 암호화. 통신 시 SSL 암호화 사용.

AWS DMS (Database Migration Service)

AWS는 대부분의 상용 및 오픈 소스 데이터베이스와의 마이그레이션을 지원.
데이터베이스가 너무 클 경우 AWS Snowball Edge(Snowball + Computing Resource)와 연동해 마이그레이션 할 수 있다.

AWS Schema Conversion Tool
이종 마이그레이션의 경우 AWS SCT를 통해 데이터베이스 엔진을 변환해 마이그레이션이 가능하다.

Cattles & Puppets

클라우드에선 트래픽이 급증하는 시기에 필요한 만큼 즉각적으로 인스턴스를 늘리고, 평상시엔 적은 인스턴스로 유지하며 On-demand(종량제)로 리소스를 관리할 수 있다. 반려동물처럼 애지중지하며 관리할 필요없이 가축처럼 다룬다.

AWS Global Infrastructure

Server → Data Center(1~6) → Availability Zone(2~) → Region

1. 수만 개의 서버가 하나의 데이터센터 안에 존재함.

2. 데이터센터 1~6개를 논리적으로 하나의 AZ로 묶음.

3. AZ 최소 2개 이상(Multi-AZ Mirroring for HA)을 하나의 Region으로 묶음.

한 Region의 AZ들은 기본적으로 서로 격리되어 있지만, 한 Region의 AZ들은 지연 시간이 짧은 링크를 통해 연결되어 있어 미러링 되어지고 있음.

또한 각 Region 간 연결이 가능한데, 일본같은 경우 지진 발생으로 도쿄 Region과 오사카 Region이 동시에 Failure될 수 있으므로 타국의 Region과 AWS Backbone Network를 통해 링크를 연결한다.

*2021.11.09 기준 전 세계 Region 25개, AZ 81개

PoP(Points of Presence)

Edge Location : 176개

Edge Cache : 11개

캐시 기능을 하며, 리전 주변에 있음.

PoP 주요 기능

Amazon Route 53 : DNS

Amazon CloudFront : CDN(Content Delivery Network) = Caching

AWS WAF(Web Application Firewall) : L7 Security

AWS Shield : DDoS 공격 완화

VPC (Virtual Private Cloud)

VPC는 퍼블릭 클라우드 환경에서 외부에 노출되면 안 되는 데이터를 인터넷으로부터 보호하기 위한 공간이다.

인터넷이라는 바다에서 가두리 양식을 쳐 놓은 것과 같다.

Soft Limit으로 하나의 계정 당 최대 VPC 5개까지 생성 가능하고, Hard Limit(AWS에 요청)으로는 최대 100개까지 생성 가능하다.

VPC로 인프라를 구성하는 기본 패턴은 다중 VPC와 복수 계정 두 가지이다.

다중 VPC는 하나의 계정에서 VPC를 여럿(주로 부서별로) 생성해 사용하는 것이고, 복수 계정은 계정 자체를 여러 개 만들어 계정 당 VPC 하나로 운용하는 것이다. 과금되는 주체가 'AWS 계정'이기 때문에 주로 다중 VPC 방식을 사용한다.

prefix 24 기준 IP를 251개밖에 못 쓰는 이유

10.0.0.1 : IGW

10.0.0.2 : DNS

10.0.0.3 : AWS 시스템에서 예비로 지정

10.0.0.255 : 브로드캐스트 주소

Public/Private Subnet

Seoul Region 기준 4개의 AZ가 있는데, 이 중 a와 b의 리소스를 받아 각각 2개의 서브넷을 만들었다.

각 Subnet마다 설정해 준 라우팅 테이블에 따라 Public Subnet은 인터넷에 직접 접속, Private Subnet은 NAT Gateway → Internet Gateway를 순서대로 통해 인터넷에 접속한다.

EC2 & SG

Amazon EC2(Elastic Compute Cloud) 서비스를 이용해 EC2 Instance를 생성하여 애플리케이션 등을 구동할 수 있다.

Public Subent엔 Application, Private Subnet엔 DB를 올려 서비스할 때 외부에서 DB로 접근하지 못하도록 가상의 방화벽을 설정해야 한다.

VPC 설정에서 SG(Security Group)를 잡아주는데(Instance Level = 각 인스턴스마다), App Instance에선 0.0.0.0/0:80, DB Instance에선 0.0.0.0/0:3306으로 설정하면 된다(WebApp, MySQL).

서브넷 레벨로 적용하는 NACL(Network Access Control List)도 존재하는데 아래의 글을 참고 바람.

https://blog.naver.com/adaylily/220953739322

Types of EC2 Instance (Not All)

범용 : T, M

고성능 컴퓨팅 최적화(CPU) : C

메모리 최적화(RAM) : R

가속화된 컴퓨팅(GPU - ML, 3D Rendering) : P

스토리지 최적화(비용↓ IOPS↑) : H

ex) t3.large

t = 범용

3 = 3세대

large = 리소스 성능

ROI(Return on Investment)

userdata, metadata 확인 방법

http://169.254.169.254/latest/userdata

http://169.254.169.254/latest/metadata