1. Compute
1-1. EC2 Overview
리눅스 윈도우 맥 등의 운영환경 설치 가능
여러 구매 옵션으로 비용 최적화 가능
Amazon Machine Image(AMI)
이미지 (아마존 리눅스, 우분투 등) 설치
사용자 지정 가능하여 OS 커널 파라미터 튜닝, 어플리케이션 실행환경 구축, 운영/배포를 위한 스크립트
Amazon EBS(Elastic Block Store)
블록 스토리지
API 연결하여 생성, 연결 수정
여러 형태, i/o 성능에 따라 다양한 서비스 제공
EC2 인스턴스 수명 주기
인스턴스가 정지된 상태에서는 과금이 발생하지 않으므로, 장비를 사용하지 않을 때 정지시켜 놓으면 비용을 절약할 수 있다.
EC2 기본 구성
1-2. EC2 인스턴스 타입
인스턴스 표기법
인스턴스 패밀리: 각각의 특화된 영역을 알려준다.
추가기능의 표기법은 다음과 같다.
인스턴스 분류
다음의 분류 기준을 통해 자신에게 필요한 타입의 인스턴스를 세부적으로 선택하여 사용할 수 있다.
Mac 인스턴스
인프라 대신 코드에 집중할 수 있도록 도와주며, DevOps 파이프라인을 통합하는 것이 가능해졌다.
1-3. EC2 인스턴스 선택
400개 이상의 인스턴스 중 어떤 것을 선택해야 할지 고민이 될 때는 다음과 같은 기준을 두고 생각하면 좋다.
-
최신 세대의 인스턴스
특별한 사정이 없는 한 최신 세대의 인스턴스를 선택하는 것이 좋다. -
인스턴스 크기
xlarge 8시간 8xlarge 1시간 운영하는 비용은 거의 같다.
워크로드 크기에 맞는 인스턴스 크기를 사용하면 비용을 절약할 수 있다. -
Cost explorer, AWS Compute Optimizer를 통해 최적의 인스턴스 및 크기를 결정할 수 있다.
비용 최적화
실제 상황에서는 어떤 식으로 인스턴스 타입을 선택해야 할지 고려해보자.
RESP API 서비스인데 트래픽 양이 많고 메시지 사이즈도 크다면 m타입을 설정하되, 프로세스가 많이 필요하다면 c타입을 선택하면 될 것이다.
DB에 적용할 인스턴스는 일반적인 경우 m타입이면 충분하지만 복잡한 쿼리가 많다면 R 타입을 고려해 볼 수 있다.
1-4. 컴퓨팅 관련 추가 서비스
Elastic Load Balancing(ELB)
트래픽을 여러 기준으로 나눠 자동으로 로드밸런싱을 해준다.
EC2 Auto Scaling
수요가 갑자기 늘어나거나 줄어드는 경우 이에 대응하기 어렵다. ec2를 사용하면 이러한 수요 변화에 동적으로 대응하고 비용을 최적화하는데 도움을 준다.
EC2 Auto Scaling 환경 구성
auto scaling 그룹을 생성하면 자동으로 EC2 인스턴스를 생성한다. 이 때 인스턴스의 정보가 필요하므로 Launch Template에 미리 정보를 작성해 놓아야 한다.
Scaling Policy
조건을 설정하여 그 조건에 맞을 때 스케일링을 할 수도 있고, 예상되는 사용량에 맞추어 스케일링을 할 수도 있다.
인스턴스 시작 시 사용자 데이터로 명령 실행
Amazon CloudWatch
1-5. 서버리스 컴퓨팅 Fargate, Lambda
직접 서버를 관리할 필요가 없고 필요할 때 원하는 만큼만 사용하여, 사용한 만큼만 비용을 지불하는 서비스이다.
fargate
완전한 격리 서비스를 제공한다.
Lambda
함수 단위의 실행 환경을 제공하여, 다양한 프로그래밍 언어 및 컨테이너를 지원한다.
또한 자동 스케일링, 로드밸런싱, 에러 핸들링을 제공하고, 호출 기반으로 비용이 과금되어 사용량에 맞추어 요금을 지불할 수 있다.
람다의 실행 모델은 동기, 비동기, 스트림의 방식을 모두 제공한다.
2. Network
2-1. Default VPC
2-2. 서브네팅과 보안그룹
2-3. VPC 엔드포인트
타입
엔드포인트는 vpc 밖의 다른 서비스가 접근할 때 IGW를 통해서 접근하게 되는데, 같은 AWS 서비스라면 내부 네트워크를 활용할 수 있다.
이 때 사용하는 것이 게이트웨이 VPC 엔드포인트이다.
- 게이트웨이 타입s3, dynamoDB만 지원 / 라우팅 방식 / 추가요금X / 접근제어 정책만
- 인터페이스=95가지 서비스 지원 / DNS 방식 / 데이터 처리 비용 발생 / 보안그룹, 알림 추가지원
VPC를 위한 최소한의 보안
보안그룹=인스턴스 레벨, prefix 지원, 상호참조
NACL=서브넷 레벨, deny 정책 지원,
CloudWatch 등을 활용해 비정상적인 상태를 인지하는 것이 필요
2-4.운영 환경을 위한 VPC 디자인
내 워크로드를 위한 VPC 설계
- 가용영역 레벨의 고가용성 구성: 최소 2개 이상의 가용 영역 사용 권장
- VPC 대역: RFC 1918에 정의된 사설 IP대역 사용 권장, 서브넷마다 예약된 IP에 대해 고려해야 함
IP 서브넷 개수를 위와 같이 잘 나눠야 하지만, 개수는 검색하면 계산기가 나오므로 걱정하지 말자.
가용영역을 나눌 때는 워크로드 분산을 위해 서브넷을 고르게 배치해야 한다.
보통 퍼블릭보다 프라이빗 서브넷에 많이 할당 되기 때문에 분배할 때 각 유형마다 필요한 만큼 분배해야 한다.
DB의 경우 프라이빗 서브넷에 할당해야 한다.
다만 프라이빗 서브넷도 인터넷 & 아웃바운드 통신이 필요하다면 NAT 게이트웨이 사용을 고려하도록 한다.
2-5. 멀티 VPC 패턴
용도에 따라 VPC를 여러개 구성하여 사용할 수 있다.
구성 기준은 다양한데 접근 모델에 따라, 소유권에 따라, 환경에 따라 구성할 수 있다.
VPC를 많이 쪼개다보면 모니터링, 개발 도구 비용이 많이 들게 되므로 공용 서비스용 VPC를 만들어 공동으로 사용하기도 한다. 또한 보안과 관련하여 격리된 VPC 구성하는 경우도 있다.
Peering: 전이적 라우팅 불가(A-B, B-C 연결되어 있어도 A-C 따로 연결돼있어야 통신 가능). 많아지면 구조가 복잡해지므로 사용할 때 고민이 필요.
2-6. VPC 모니터링
Flow logs
직접 데이터를 확인하지는 않지만 메타데이터를 확인하여 모니터링 가능.
트래픽 패턴 수집 가능
Reachibility analyzer
추후 내용 추가
3. Storage
3-1. AWS 스토리지 기본
일반적으로 스토리지는 다음과 같은 용도로 사용한다.
 스토리지의 옵션을 제공한다.
3-2. AWS 블록 스토리지
Amazon EBS
데이터를 일정 크기의 블록으로 나누어 저장한다.
이로 인해 고성능 대규모 데이터 처리와 트랜잭션 집약적인 워크로드에 사용.
99.999%의 가용성을 제공하도록 설계되어, 스냅샷 기능으로 추가 내구성 수준 다성을 지원한다.
비용적인 측면에서도, 생성한 용량만큼만 비용을 지불하면 되고 비용 절감을 위해 증분 기반의 스냅샷을 제공한다.
볼륨 타입에 대해서는 다음과 같은 옵션을 제공하여, 용도에 따라 선택할 수 있다.
EBS Multi-Attach
여러 서버에서 동일 공간에 있는 파일에 접근해야 하는 경우나, 장애 발생시에도 지속적인 서비스가 필요할 때, 성능과 고가용성이 필요할 때 Multi-attach 기능을 사용할 수 있다.
3-3. AWS 파일 스토리지
Amazon EFS
Amazon EFS는 완전 관리형 스토리지 서비스로, 별도의 파일시스템 구성이 필요 없다.
또한 기존 도구 및 어플리케이션과 유연하게 통합이 가능하여, 운영체제의 표준 파일시스템 API와도 호환이 가능하다.
AWS의 다양한 서비스와 호환이 가능하여 컴퓨팅, 자동화, 머신러닝 등에도 사용될 수 있다.
또한 자동적으로 확장/축소되어, 사용량에 따라 유연하게 비용을 지불할 수 있고, 확장 시 페타바이트 규모까지 확장이 가능하다.
가용성 측면에서는 다중의 가용영역에 분산 저장되어 가용영역 장애를 고려하였고, Production 및 Tier-0 어플리케이션에 적합하다.
FSx for Windows File Server
윈도우 기본 파일시스템인 NTFS를 지원하여, 윈도우 서버에 구축되는 확장 가능한 완전 관리형 파일 스토리지 서비스이다.
FSx for Lustre
오버헤드 없이 사용할 수 있는 고성능 스토리지를 제공하는 서비스이다.
성능적인 측면에서는, HPC, 머신러닝, 렌더링 등 공유 파일시스템을 통해 동일한 데이터에 엑세스하는 워크로드에 적합하다.
또한 S3와 연계되어 있어 데이터 엑세스가 쉽고 변경된 데이터만 추적이 가능하다.
3-4. AWS 오브젝트 스토리지
S3
스토리지 클래스
S3 운영
성능 및 용량
파티션 당 초당 5500회 읽기 또는 3500회 쓰기를 지원하고, 병렬 처리로 성능을 극대화했다.
가용성
데이터를 3곳 이상의 물리적으로 분리된 가용영역에 저장하여 고가용성을 자랑한다.
보안
S3 select
빅데이터를 처리할 때는 S3 select를 사용하여 처리 성능을 향상하고 비용을 절감할 수 있다.
4. Database
4-1. AWS 데이터베이스 서비스
데이터베이스는 예전부터 있었지만, 기술의 발전으로 폭발적인 성장을 이루었다.
또한 비용과 인력이 많이 드는 온프레미스 데이터베이스에서 완전 관리형인 AWS 데이터베이스로의 이동이 많아지는 추세이다.
AWS의 완전 관리형 데이터베이스의 특징은 다음과 같다.
??
또한 어플리케이션 아키텍처가 발전하여 마이크로서비스가 확산되면서 데이터베이스도 각 서비스별로 구성해야 할 필요성이 생겼다. 또한 기존의 관계형 데이터베이스 뿐만아니라 목적별로 다양한 데이터베이스의 수요도 증가하게 되었다.
-
관계형 데이터베이스
-
비관계형 데이터베이스
레거시
예상 밖으로 초기 스타트업에서도 레거시 시스템이 존재한다. 초기 단계에서는 개발자만으로 구성된 조직에서 빠르게 개발을 했지만, 데이터 개발자가 없어 이후에 레거시 시스템으로 인한 문제가 발생한다.
이러한 문제를 해결하기 위해 AWS에서 제공하는 데이터베이스를 선택함으로써 레거시 시스템을 안전하게 해결할 수 있다.
4-2. AWS 데이터베이스 서비스 모범 사례
스트리밍 서비스 기반의 새로운 서비스 구축 사례(Hulu)
Amazon Aurora, ElastiCache를 사용
자주 액세스하지만 수정은 많지 ㅇ낳은 비디오 컨텐츠의 메타데이터는 ElastiCache에, 미디어 세그먼트의 메타데이터는 Aurora MySQL을 사용.
- Aurora MySQL과 RDS MySQL차이
기존 MySQL보다 성능이 뛰어난 Aurora MySQL
운영 자동화를 통한 운영 리소스 감소, 쿼리 레벨 모니터링, 백업 및 복원 기능
- Provision
AWS 콘솔에서 클릭 몇 번으로 데이터베이스 구성이 가능 - 모니터링
CloudWatch와 통합되어 지표 모니터링 가능, 서드파티 유틸리티와도 호환. RDS에서 이벤트 발생시 경보 수신이 가능하며, 이벤트 범주도 선택이 가능하다. 또한 Performance insights가 있어 성능 문제를 분석해주고, 부하를 일으키는 악성 쿼리를 개선할 수 있도록 도움을 준다. - 자동백업 & 스냅샷
하루에 하나, 예약된 백업을 받을 수 있고 시점도 선택 가능. 또한 데이터베이스 스냅샷을 제공하여 다른 리전에도 옮길 수 있다.
이중화 기능, failover 기능
-
다중 AZ 배포
-
읽기 전용 복제본
-
다중 AZ 배포 vs 읽기 전용 복제본
데이터베이스 확장과 피크타임 시 대응(Grab)
- 확장성
다양한 옵션을 가진 데이터베이스 인스턴스를 제공하고, 워크로드에 연동하여 인스턴스 사이즈를 변경할 수 있다. 또한 auto scaling을 지원하여 부하를 줄일 수 있다. - 피크타임 시 대응
ElastiCache를 통해 피크타임 시 분 당 수 십만 개의 요청에 1밀리초 미만의 응답 속도를 제공한다.
Connection Pool 관리
데이터베이스의 앞단에 많은 애플리케이션이 존재할 경우 부하, 장애가 발생하는 경우가 많다.
RDS Proxy를 사용하면 많은 수의 연결을 지원하고, 여러 AZ에 배포되어 연결이 끊어지지 않고 장애가 발생할 경우 조치를 취한다.
데이터 보안
RDBMS에서 NoSQL로의 마이그레이션
단순히 현재 NoSQL이 유행해서 사용하는 것이 아니라, 현재 서비스가 NoSQL에 적합한지 그 사용 목적을 우선적으로 고려해야 한다.
-
DynamoDB
어떤 규모에도 일관된 성능을 보장하는 빠르고 유연한 키-밸류 데이터베이스. -
DocumentDB
빠른 속도, 확장성, 높은 가용성, 완전 관리형의 MongoDB 호환 데이터베이스.
온프레미스 데이터베이스에서 RDS로의 마이그레이션
DMS를 통해 서비스가 중단되지 않고 마이그레이션이 가능하다.
5. Security
5-1. AWS 보안
5-2. IAM 이해
사용자의 분류에 따라 적절한 권한을 가진 계정이 필요하다.
AWS 클라우드의 환경 관리를 위해서는 IAM(Identity and Access Management)이 필요하다.
인증
AWS 로그인 시 루트 사용자로 로그인하게 되면 지나치게 많은 권한을 갖기 때문에 관리 콘솔에 로그인할 때는 IAM사용자로 로그인 할 것을 권장한다.
그리고 IAM 사용자가 콘솔에 접근할 필요가 없다면 관리 콘솔로의 접근을 차단할 수 있다.
실사용자가 아닌 경우 임시적인 단기자격증명을 받아 IAM역할을 줄 수 있다.
또한 인스턴스에 IAM을 설정하여 자격 증명을 제출할 수 있다.
인가
API 호출 시 IAM 정책에 의해 요청이 인가되어야 하고, 정책은 다음과 같이 구성된다. 다만 정책에 모든 구성요소를 넣을 필요는 없다.
- Effect: 명시된 정책에 대한 허용/차단
- Principal: 접근을 허용/차단하고자 하는 대상
- Action: 허용/차단하고자 하는 접근 타입
- Resource: 요청의 목적지가 되는 서비스
- Condition: 명시된 조건
다만 모든 권한을 허용하게 되면 해킹을 당했을 때 대처하기 어려우므로 명시적 권한 설정으로 제한하는 것이 안전하게 관리하는데 도움이 된다.
정책은 권한을 제한할수도, 부여할수도 있는데 크게 Identity-based와 Resource-based 정책으로 나눌 수 있다.
또한 정책의 우선순위는 명시적 거부가 우선되므로, 허용과 거부가 동시에 있더라도 거부가 우선하게 된다.
IAM 설정 시 다음의 모범 사례를 참조하여 설정하는 것을 권장한다.
5-3. AWS 로깅 및 관리를 위한 CloudTrail & CloudWatch
CloudTrail
다양한 계층에서 각각의 서비스에 따라 다른 방식의 로그를 남길 수 있는데, AWS 서비스에서 API 호출 시 생성되는 로그를 관리하는 것이 CloudTrail이다.
CloudWatch
DevOps, 개발자를 위한 클라우드 리소스 통합 모니터링 도구가 CloudWatch이다.
5-4. 경보 체계 구성
CloudWatch Alarm을 설정하여 장애, 침해 상황에 대응하도록 할 수 있다.
