[75일 차] 21.11.09 : AWS 공인 교육 1

AWS 이론 기초

AWS VPC, Subnet, EC2 등 기초 인프라 실습 - 웹 서버 + DB 서버 구축

---

1교시

 

 

이제는 강의 녹화 영상이 없으니 집중!

 

과목은 2가지 - AWS Technical Essential + Architect on AWS

교재 배포 : VitalSource 사이트 들어가서 코드 입력(2개). 교재를 볼 수 있는 기간은 2년

-> 프린트하고 싶다면 PC에 앱을 다운로드하고 로그인 후 PDF 프린트

 

Lab guide : 실습 매뉴얼 - 개인 계정으로 하는 실습 + 퀵랩 환경 실습(교육 중에만 사용 가능)

-> 퀵랩 실습은 내일부터

Student guide : 수업용 자료

 

오늘내일은 AWS 기술 에센셜, 그 다음은 아키텍트 온 AWS 수업

두 과목 간에 겹치는 부분이 꽤 있다.

 

 

• AWS Technical Essential

AWS에 대한 기본적인 소개 + 많이 사용하는 기술에 대한 소개

 

클라우드?

-> 대충 뭔가 복잡한 것이 내부에 있다는 의미

-> 인터넷/네트워크의 의미

 

클라우드 컴퓨팅이란?

-> 컴퓨팅에 필요한 자원들을 제공하는 서비스

인터넷을 통해 컴퓨팅 자원을 제공하는 서비스

-> 규격화된 수많은 리소스 중 고객이 요청한 만큼 쪼개서 제공

-> 리소스가 필요할 때 빠르게 만들어진다

 

대충 비용과 속도에서 큰 이점이 있다는 것.

-> 대기업은 보안, 규정, 요구 사항 등을 쉽게 충족할 수 있다 + 새로운 시도를 적은 비용으로 할 수 있다

-> 스타트업은 비용을 절감할 수 있다

 

On-premise와 달리 초기 투자 비용이 대폭 줄어든다 + 용량을 정밀하게 추정할 필요 없다

---

2교시

 

 

• 리전

지리적 위치. 관리의 수준으로는 막을 수 없는 재해가 일어날 수 있으니 최소한 2개 이상의 가용 영역으로 구성된다.

대충 대표적인 도시의 이름으로 명명된다. 서울 리전이라고 서울 지역에 있다는 것이 아니다.

※ 미국에 있는 GovCloud 리전은 일반 사용자가 선택 불가능. 정부 전용 클라우드

• 가용 영역

데이터 센터의 클러스터. 다른 가용 영역의 장애로부터 격리된다.

각 가용 영역의 실제 위치는 모르겠지만 아무튼 다른 가용 영역과 충분히 떨어져 있다는 것.

 

가용 영역 2개에 부하 분산으로 인스턴스 2개를 만들었다고 가정해 보자.

-> 비용이 2배인가요?

-> 아니다. 100의 성능을 사용하던 50의 성능 2개를 사용하던 비용은 똑같다.

(ALB 비용은 제외하고 생각)

클라우드니까 원할 때 성능을 높일 수 있으니 100의 성능으로 미리 만들어놓을 필요 없다.

 

• 엣지 로케이션

특정 서비스(Route 53, CloudFront, WAF, Shield)를 사용하는 고객과 가장 가까이 있는 네트워크

(AWS Shield : 디도스 방지 서비스)

리전/가용 영역과 독립적으로 운영된다.

제공할 콘텐츠를 멀리 있는 고객에게 제공하기 위해 가까이 있는 엣지 로케이션에 캐싱

 

 

기초 서비스 시작 전에 IAM 먼저 : AWS 보안, 자격 증명 및 액세스 관리

 

AWS 책임 공유 모델 - 고객은 클라우드에서의 보안을 책임지고, AWS는 클라우드의 책임이 있다.

무슨 소리냐? 책임 회피 아닌가?

인프라는 AWS가 소유 중이니 모든 내용물에 대한 접근 권한이 있겠지만, 도의상 AWS가 접근할 수 없는 영역이 있다.

-> 고객이 만든 부분은 고객이 알아서 책임져야 한다. AWS는 서비스/기능의 사용에 문제가 없도록 관리할 뿐이다.

 

물리적으로는 데이터센터의 보안에 신경쓰고, HW/SW 측면으로는 액세스 시도 기록, 방화벽, 모니터링 도구 등을 제공

그리고

SSL 엔드포인트 : 전송 암호화, 보안 통신

보안 그룹 : 보안 그룹을 사용하여 인스턴스에 대한 방화벽 규칙을 구성

VPC : 퍼블릭/프라이빗 서브넷, NAT/VPN 지원으로 리소스 액세스에 대한 제약 조건 생성

등의 기능을 제공

 

사용자가 요청한 모든 내용은 네트워크를 타고 AWS 서버로 API 호출 형태로 나간다.

요청 때마다 아이덴티티 정보가 첨부되어 전송된다. 이 정보를 IAM에서 제공하는 것이다.

 

지금까지는 루트 사용자로 콘솔에 로그인했는데, 절대 이러면 안 된다!

-> 루트 계정이 탈취당하면 큰일 난다. 루트 계정은 권한 제어가 안되기 때문.

그러니까

루트 계정의 액세스 키 삭제

그룹을 사용, IAM 사용자에게 권한 지정 + 최소한의 권한 지정

강력한 암호 정책 구성

권한 있는 사용자에 대해 MFA 활성화

---

3교시

 

 

• EC2(Elastic Compute Cloud)

똑같이 가상 서버인데 왜 VM이 아니라 인스턴스라고 부를까?

-> 온 프레미스 환경에서의 서버는 소중한 자원이다. 신경 쓸 요소도 많고, 귀한 몸이다.

-> AWS에서의 서버는 그럴 필요가 없다. VM처럼 관리할 필요가 없다(= 원하는 대로 만들고 없애라는 것)

-> 다시 세팅해야 하잖아요? : 그래서 AMI를 사용한다. 서버의 상태를 그대로 백업한 것.

 

요구 사항에 따라 컴퓨팅 성능 조정

사용한 만큼만 비용 지불

여러 리전과 가용 영역에 걸쳐 배포

 

* 인스턴스 유형

사용 목적에 따라 유형 선택

범용 : 균형 있는 워크로드

컴퓨팅 최적화 : 고성능 컴퓨팅

메모리 최적화 : 고성능 DB

가속화된 컴퓨팅 : GPU 집약적 워크로드

스토리지 최적화 : 저렴한 비용으로 높은 IOPS

 

최신 세대 인스턴스 유형은 가격 대비 성능이 더 높다

 

인스턴스 생성 시 고려 사항

-> 리전, VPC, 서브넷(가용 영역) = 네트워크

-> 인스턴스 유형, 스토리지 볼륨

-> IP 주소, 보안 그룹, 태그, 키 페어

 

인스턴스 생성 요청을 받으면 AWS는 사용 가능한 리소스를 찾는다 : Pending

찾았으면 그 자리에 인스턴스 생성 : Running. 이제부터 비용이 나온다.

인스턴스 중지를 누르면 "중단 중"으로 바뀌는데, 이때부터 요금이 나오지 않는다.

중단이 완료되면 Pending 상태로 돌아간다. 내려간 상태니까 비용이 나오지 않는 것.

-> 재시작하면 그 자리에 다시 만드는 것이 아니라 다시 사용할 수 있는 자리를 찾는다. 

재부팅은 Pending으로 넘어가지 않는다(= 동일한 자리에 남아있다)

 

• 인스턴스 메타데이터

인스턴스에 대한 데이터. 실행 중인 인스턴스를 구성/관리하는 데 사용할 수 있다.

실행 중인 인스턴스에 접속 후 http://169.254.169.254/latest/meta-data에서 볼 수 있다.

curl이나 GET 명령어로 가져오면 된다.

 

• 인스턴스 사용자 데이터

시작 시에 인스턴스에 전달될 수 있다.

인스턴스 시작 후에 스크립트 실행

#!/bin/sh 로 시작해서 명령어 스크립트 실행

---

4교시

 

 

• VPC

AWS 클라우드에서 격리된 프라이빗 가상 네트워크를 프로비저닝

가상 네트워크 환경을 제어 가능

 

기본 VPC는 간단한 테스트 용도로나 쓸만하지, 그냥 쓰기엔 좋지 않다.

한 번 만들면 수정이 어렵거나 불가능하기 때문.

 

VPC는 네트워크라기보단 네트워크를 만들 수 있는 공간이라고 생각하는 것이 좋다.

이 안에 서브넷을 만들어야 실제 네트워크가 생기는 것.

 

• 서브넷

서브넷은 VPC 내 IP 주소 범위를 정의

프라이빗 서브넷은 인터넷에서 액세스 할 수 없는 리소스에 사용

퍼블릭 서브넷은 인터넷에서 액세스할 수 있는 리소스에 사용

-> 퍼블릭/프라이빗 서브넷을 결정하는 것은 라우팅 테이블 : IGW로의 경로가 있는가?

 

온 프레미스에서는 라우터로 NAT 기능 대체

AWS에서는 클릭 몇 번으로 NAT 게이트웨이를 생성 가능하지만, 비용이 좀 나온다.

-> NAT 인스턴스

 

• VPC의 보안

인터넷에서 들어간다고 치면

인터넷 -> 인터넷 게이트웨이(or VPN) -> VPC 라우터 -> 네트워크 ACL -> 서브넷 -> 보안 그룹 -> 인스턴스 방화벽

+ 키 페어

 

• AWS EBS

내구성이 높다 : 특정 가용 영역에 만들어지면 복사본이 많이 만들어진다.

스냅샷은 S3에 저장된다.

 

EBS는 연결되어 있지 않더라도 요금이 발생한다.

 

볼륨 유형

-> SSD 지원 볼륨 : I/O 크기가 작고 읽기/쓰기 작업 빈도가 높은 워크로드에 적합. IOPS 성능이 뛰어남

-> HDD 지원 볼륨 : 대규모 스트리밍 워크로드에 적합. 처리량이 뛰어남

 

• AWS EC2 인스턴스 스토리지

인스턴스 스토리지가 EBS보다 성능이 월등히 좋다.

하지만 지속성이 없음(인스턴스가 중지되면 데이터가 사라짐) = 휘발성

데이터 분석 같이 빠른 처리가 필요한 작업에 좋다(어차피 대상 데이터를 복사해온 후 처리하고 결과를 내보내면 끝)

---

5교시

 

 

EC2 실습을 위한 사용자 생성

IAM > 사용자 > 사용자 추가 > 사용자 이름 작성, 액세스 유형 선택(암호 방식으로 했다) - 콘솔 접속 시 사용할 비밀번호 작성 > 다음 > 기존 정책 연결 > AdministratorAccess 선택 > 태그 작성 > 생성

 

생성 후 요약에서 보면 사용자 ARN에 12자리 숫자가 있다. 이게 접속할 때 사용하는 ID.

어쨌건 이렇게 생성한 계정은 Billing 콘솔에 대한 접근 권한이 없다.

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/tutorial_billing.html

IAM 자습서: 결제 콘솔에 대한 액세스 권한 위임 - AWS Identity and Access Management

문서를 따라 결제 콘솔 접근 권한 부여

 

 

이제 실습하자. VPC로 이동. 대시보드 언어는 영어로 진행

VPC는 만들었다고 비용이 발생하지는 않는다.

 

기본 VPC가 있고, 가용 영역마다 기본 서브넷이 1개씩 있다. 라우팅 테이블을 확인해 보니 퍼블릭 서브넷이다.

 

VPC를 하나 만들어 보자.

이름 작성하고 IPv4 CIDR 작성 후 생성

-> CIDR은? : 서브넷마스크로 네트워크 영역과 호스트 영역을 구분

 

IGW 하나 생성, 만든 VPC에 부착

VPC를 생성하면 라우팅 테이블이 자동으로 생성된다.

같은 VPC 내에 만들어진 인스턴스들은 통신이 가능하다.

-> 라우팅 테이블에 VPC CIDR에 대한 라우팅이 기본으로 지정되어 있기 때문이다.

 

네트워크 ACL도 VPC를 생성하면 기본으로 생성된다(모든 트래픽 허용)

 

 

만든 VPC 체크 > actions > Edit NS hostname > Enable 체크 > 저장

주소가 아닌 DNS로 접근할 수 있도록 한다.

---

6교시

 

 

이번에는 서브넷 생성

같은 가용 영역에 프라이빗, 퍼블릭 서브넷 하나씩 생성

일단 생성 직후에는 기본 라우팅 테이블이 적용되는데, 기본 라우팅 테이블은 인터넷 게이트웨이 정보가 없어서 IGW로의 라우팅 경로가 없다.

 

어쨌건 퍼블릭 서브넷으로 만드는 방법은 2가지 - 기본 라우팅 테이블에 IGW로의 경로를 추가하거나, 새로운 라우팅 테이블을 만들어 경로를 추가하거나.

-> 전자는 프라이빗 서브넷도 할당이 되므로 권장되지 않음.

 

작업할 때 다른 VPC의 리소스가 섞여 있어서 헷갈릴 수 있다. 좌측 목록 상단의 필터로 특정 VPC를 선택해서 필터링

 

퍼블릭으로 사용할 라우팅 테이블 생성 후 IGW로의 라우팅 경로 등록 > 라우팅 테이블과 서브넷 연동

이제 퍼블릭 서브넷의 라우팅 테이블을 보면 적용되어 있다.

 

퍼블릭 서브넷에 필요한 설정이 더 있다. 이 안에 생성되는 인스턴스들에게 공인 IP 주소를 기본으로 할당하는 설정.

서브넷 체크 > Actions > Modify auto-assign IP settings > Auto-assign IPv4 체크 후 저장

 

인스턴스를 생성해 보자.

AMI는 우분투 18.04 > 인스턴스 설정에서 퍼블릭 서브넷을 선택해 보면 Auto-assign Public IP가 Use subnet setting(Enable)로 되어 있다. 위에서 공인 주소 기본 할당을 활성화했으니까.

User data 내용

보안 그룹도 만지고 어찌어찌 생성하고 접속해 보면 User data에 작성했던 내용대로 웹 사이트가 만들어져 있다.

다음은 프라이빗 서브넷의 인터넷 통신과 DB 연결

---

7교시

 

 

위에서는 User data로 아파치 다운로드, PHP 설치, 소스 코드를 다운로드했다.

다음엔 프라이빗 인스턴스로 뭘 할 건데, 외부와의 통신이 되어야 뭘 할 수 있다.

NAT 인스턴스를 생성하자. 아마존 리눅스 AMI로 생성, 퍼블릭 서브넷에 생성

User data

보안 그룹은 SSH 외에도 모든 TCP와 UDP에 대해 well-known port 허용, source는 이 VPC(10.0.0.0/16). ICMP도 이 VPC에 대해 허용(10.0.0.0/16)

 생성 후에 NAT 인스턴스 체크 > Actions > Networking > Change source/destination check > Source/destination checking의 Stop 체크

-> 이게 Stop이 아니라면 IP 주소 변환이 안 된다. NAT 기능을 위해서는 Stop해야 한다.

 

다음은 프라이빗 라우팅 테이블에 NAT 인스턴스로의 경로를 추가해줘야 한다.

-> 목적지는 모든 주소(0.0.0.0/0), 대상은 NAT 인스턴스

-> NAT 인스턴스로 지정하면 NAT 인스턴스의 네트워크 카드(Elastic Network Interface)로 알아서 바뀐다.

 

 

이번에는 DB 인스턴스를 만들자. 우분투 18.04 AMI 선택, 프라이빗 서브넷 선택, 공인 주소는 주지 않는다.

USer data

패스워드 인증으로 하긴 했는데 실제로는 이러면 안된다. 보안상 좋지 않다.

bind-address 부분은 원격 접속이 가능하도록 하는 것

 

보안 그룹은 SSH/MySQL 허용. MySQL 규칙은 지금은 Anywhere로 해도 괜찮지만, 같은 서브넷에 다른 기능의 인스턴스가 생긴다면 더 타이트하게 조여야 한다.

 

웹 서버 인스턴스로 원격 접속 - 우분투 AMI를 사용했으니 사용자 명이 ubuntu임에 주의

/var/www/html/basic/login/dbconn.php 파일을 열어서 DB 정보 수정

-> hostname 부분을 DB의 실제 주소(사설 IP 주소)로 수정

 

이제 웹 사이트에서 Customer Center로 들어가진 다면 잘 연결된 것이다.

---

8교시

 

 

마지막 시간은 복습.

---

수업 시간이나 쉬는 시간이 들쭉날쭉하다.

아직까진 기초적인 내용이라 괜찮다.

대답 좀 열심히 하겠다고 막 질렀는데 틀릴 때마다 부끄럽다 흑흑