AWS Builders 100 Hands On Lab
업데이트:
https://aws-builders-kr.workshop.aws/ko/
지난 여름 참가했던 AWS Builders 100 Hands On Lab 내용을 나름대로 정리해서 복습의 기회로 삼고자 한다.
(정리하면서 기초 용어들도 한 번씩 나만의 말로 설명을 적어보는 기회…)
구성
교육을 들으며 구성했던 환경은 아래 그림과 같다.
(그림 그려서 추가)
IAM 유저 생성
- AWS 계정 생성 → 루트 계정 로그인하여 IAM 유저 생성
- IAM 유저에 admin 권한 부여 : Attach existing policies directly (기존 정책 직접 연결) → AdministratorAccess 선택
- 유저 추가된 후 로그인 URL 을 복사, 해당 URL 로 로그인하여 사용
- https://
.signin.aws.amazon.com/console
네트워크 구성
VPC & 서브넷 구성
- Virtural Private Cloud 의 약자로, 물리 서버 환경으로 비교하면 DC 에서 운영하는 네트워크 환경에 해당
- 사용자가 직접 정의한 가상의 네트워크 환경에서 다양한 AWS 리소스를 생성 및 운영할 수 있음
- 기존에 생성된 VPC 에 추가 서브넷 추가 역시 가능하다
VPC 를 신규로 생성할 때의 설정 대상은 아래와 같다.
CIDR 블록 | 해당 VPC 에서 사용할 네트워크 범위(IP 주소/서브넷 마스크) |
---|---|
퍼블릭/프라이빗 서브넷의 CIDR | 생성할 VPC 를 분할하여 사용할 서브넷 네트워크 범위(IP 주소/서브넷 마스크) |
가용 영역 | 모든 리전은 최소 2개의 격리된, 그리고 연결된 가용 영역으로 구성되어 있다 → 백업을 위해 서브넷은 최소 2개의 가용 영역에 생성하는 것이 좋음 |
서브넷 이름 | 생성할 서브넷 이름 설정 |
※ 서브넷(부분망) : 하나의 네트워크를 분할하여 사용하는 작은 네트워크
- 퍼블릭 서브넷 : 외부 인터넷과 Ingress/Egress 가 가능한 서브넷 범위
- 프라이빗 서브넷 : 외부 인터넷과 Ingress/Egress 가 불가능한 서브넷 범위. 이 경우 퍼블릭 서브넷에 NAT Gateway 를 두고 프라이빗 서브넷이 이 NAT Gateway 를 바라보게 설정하면 프라이빗 서브넷 내에서도 외부 인터넷과 통신할 수 있다.
※ CIDR(Classless Inter-Domain Routing) : 네트워크의 주소와 크기를 표현하는 방식
예를 들어 10.0.0.0/24 CIDR 중 아래 5 IP 는 예약된 것이므로 사용할 수 없다
10.0.0.0 | 네트워크 주소(물리 환경의 IP 와 동일) |
---|---|
10.0.0.1 | AWS 의 VPC 라우터용 예약 주소 |
10.0.0.2 | DNS 서버 주소 |
10.0.0.3 | AWS 예약 주소 |
10.0.0.255 | 브로드캐스트 주소(물리 환경의 IP 와 동일) |
라우팅 테이블 생성
- 라우터 : 출발지에서 목적지까지 데이터(패킷)을 어떤 경로로 전송할 것인지 경로를 결정
- 해당 VPC 의 서브넷이나 게이트웨이에 대해 네트워크 트래픽이 전송되는 위치를 설정하는 규칙의 집합인 라우팅이 포함된 테이블
- 기본 라우팅 테이블 : VPC 가 생성되면 자동으로 함께 생성되는 라우팅 테이블로, 해당 VPC 내에 있는 모든 서브넷의 라우팅을 제어할 수 있다
- 사용자 지정 라우팅 테이블 : 유저가 직접 생성한 라우팅 테이블
- 라우팅 테이블 ID 에서 기본 라우팅 테이블이 아닌 쪽의 라우팅 테이블을 선택(해당 라우팅 테이블이 인터넷으로 향하는 경로가 있는지 확인)하여 설정
보안 그룹 설정
- 보안 그룹 : 인스턴스에 대한 인바운드/아웃바운드 트래픽을 제어하는 가상 방화벽 역할
- 인바운드 규칙 / 아웃바운드 규칙
- 유형 : 프로토콜 선택
- 소스 : Anywhere-IPv4 + 네트워크 범위
웹 서버 생성
EC2 생성
- 원하는 만큼 가상 서버를 구축하고, 보안 및 네트워크 구성과 스토리지 관리가 가능
- 예상 외의 트래픽 변동에 신속하게 규모의 확장 및 축소(autoscaling)가 가능 → 서버의 트래픽 예측 필요성 감소 효과
- 고급 세부 정보 → 사용자 데이터(텍스트로) : EC2 생성 직후 실행시킬 Shell Script 를 미리 작성 가능
- 키 페어 : SSH 클라이언트를 통해 해당 EC2 에 접속할 경우 필요
- 웹 브라우저에서 퍼블릭 IP 로 접속할 때 http 로 접근해야 함(https 는 불가)
AMI 로 EC2 이미지 복제
- Amazon Machine Image : 인스턴스의 정보를 담고 있는 이미지
- AMI 를 만들고자 하는 인스턴스의 [작업] → [이미지 및 템플릿] → [이미지 생성]
ELB 구성
- Elastic Load Balancing 의 약자로, AWS 의 로드밸런서 서비스
- 애플리케이션 트래픽이 들어오면 구성되어 있는 AWS 서비스에 그 트래픽을 자동으로 분산시킴
- 단일 혹은 복수의 가용 영역에서 다양한 애플리케이션 부하를 처리할 수 있음
- Application Load Balancer : HTTP, HTTPS
- Network Load Balancer : TCP, UDP, TLS
- Gateway Load Balancer : IP
- Classic Load Balancer
※ 리스너 : 연결 요청을 확인하는 프로세스. 로드밸런서의 앞단과 뒷단을 연결하는 역할
모니터링 기능 추가
SNS(Simple Notification Service)
- 애플리케이션-애플리케이션 , 애플리케이션-사용자 간 통신 모두를 위한 완전관리형 메시징 서비스
- 주제 생성 : 통신 채널 역할을 하는 논리적인 액세스 포인트
- 구독자 생성 : 해당하는 주체에 알람이 발생할 때, 그 내용을 받는 주체
CloudWatch
- AWS 의 모니터링 및 관창 기능 서비스
- 로그/지표/이벤트 형태로 데이터를 수집하여 모니터링 및 시각화, 알람 설정까지 가능
- 경보 생성 기준, 알람 전송받을 대상 생성
Auto Scaling
- Amazon EC2 Auto Scaling : 애플리케이션의 로드를 문제 없이 처리할 수 있는 정확한 인스턴스를 보유할 수 있도록 자동 조정해 주는 서비스
- 내결함성 향상 : 인스턴스에 장애 발생시 대체 인스턴스를 시작할 수 있다(여러 가용 영역을 사용하도록 구성 또한 가능)
- 가용성 향상 : 실시간 트래픽 상황에 알맞은 용량을 보장해준다
- 비용 관리 개선 : 필요에 따라 용량을 자동으로 증가/감소할 수 있어 비용 절감에도 효과적이다
시작 템플릿 생성
- 오토스케일링 그룹 생성 전 필요한 템플릿 생성
- 오토스케일링 대상이 될 AMI, 인스턴스 유형, 보안 그룹 설정
오토스케일링 그룹 생성
- 오토스케일링을 실행할 대상 그룹(로드밸런서 생성), 시작 템플릿, VPC 및 서브넷 설정
- 오토스케일링 그룹과 로드밸런서를 연결할 수 있음 → 인스턴스가 시작될 때 자동으로 오토스케일링 그룹에 등록됨
- CloudWatch 활성화 → 오토스케일링 그룹에서 추적 가능한 지표를 전송받을 수 있음
- 최소/최대 용량 한도 설정 : 인스턴스를 몇 대까지 증가/감소시킬 것인가
- 조정 정책 설정 : 조정 정책에서 정한 내용(예를 들어 CPU 사용률 30)을 기준으로 증가/감소
- SNS 활성화 → 오토스케일링 이벤트가 발생할 때마다 알림을 받을 수 있음
S3 활용
- Simple Storage Service : AWS 전용 객체 스토리지 서비스
- 전용 버킷 생성 후, 버킷의 객체 URL 에 데이터 보관 가능