[TIL] 7주차_Day27: AWS 클라우드 실습 (2)

💡Today I Learned

• AWS 클라우드 실습에 대한 두 번째 수업을 진행했습니다.
• Route53, DB, ACM(인증서), CloudFront(CDN), ELB(로드밸런서), VPC 실습

 

---

 

1. Route53

: 가용성, 확장성이 뛰어난 DNS(도메인 네임 서비스) 웹 서비스

: 1) 도메인 등록  2) DNS 라우팅  3) 상태 확인(모니터링)  주요 기능이 있음

: public/private host zone 존재

: Route53 = DNS(네임서버) + 모니터링 + L4 + GSLB

 

- DNS 찾아가는 과정

1) end user가 특정 도메인 요청

2) 글로벌하게 등록된 네임 서버에 찾아감

3) 지역적으로 등록된 네임 서버에 찾아감

4) 로컬에 등록된 네임 서버에 찾아감

5) DNS서버를 활용해 원하는 도메인을 찾을 수 있도록 선택함

 

- 도메인 구매

: 내(AWS)/외부에서 도메인 구매 가능

 

- 서브 도메인

ex) 관리자용, 개발용, 프론트→백엔드 도메인

: 도메인 이름을 계층적으로 구성해 관리, 효과적으로 리소스를 구분하기 위함

 

: 서브 도메인 사용하는 이유

1) 조직 구조화: 서브 도메인 사용 시 조직의 구조를 반영해 도메인을 관리할 수 있음 (ex: 부서별, 서비스별 서브 도메인 할당)

2) 리소스 분리: 특정 서비스, app, 환경에 대한 리소스를 분리해 관리할 수 있음 → 다른 서브 도메인 간의 충돌을 방지, 관련 리소스를 더 효율적으로 관리할 수 있게 해줌

3) 보안/권한 관리: 서브 도메인을 사용해 보안 정책을 구성, 특정 서브 도메인에 대한 권한을 각각 관리할 수 있음 → 접근 제어를 세밀하게 설정(서브 도메인 별로), 보안을 강화

4) 서비스 구분: 서비스나 제품 간에 구분을 할 수 있음 ex: API 서비스, 메일 서비스, 웹 앱 등.. → 서브 도메인으로 분리해 각각을 식별

 

2. RDS

- DB

: 정형 데이터 RDBMS 사용하는 SQL ex) mySQL → AWS에서 SQL 지원하는 게 RDS

: 비정형 데이터 다루는 NoSQL, 스키마 형식이 일관적이지 않더라도 대용량으로 쌓을 수 있는 데이터베이스  ex) MongoDB

 

- RDS

: DB 인스턴스는 클라우드에서 실행하는 격리된 db환경

: DB 인스턴스에는 여러 사용자가 만든 db가 포함될 수 있음

: 직접 시스템 로그인 불가능 (서버 내에 들어가는 건 제공하지 x), 쿼리 이용은 커넥트해서 사용 가능

: RDS 자체는 serverless가 아님

 

- AWS RDS 생성하기 (실습)

: 자동으로 스냅샷 생성해줌 / 수동으로도 스냅샷 생성 가능 (백업) → 장애 발생 시에도 특정 시점의 버전으로 복원, 서비스 제공 가능하도록

: VPC 보안그룹 > 인바운드 규칙 > 선택한 db(mySQL)이 추가 돼있는지 확인

: 보안그룹 내 인바운드 규칙에 'MySQL/Aurora'추가 > 일단 모든 IP 접속 가능하도록 (0.0.0.0/0)로 설정 

: DB 클라이언트 툴 이용해 엔드포인트로 접속 (mySQL은 Workbench ..) / 엔드포인트(server host) + 설정한 username + 설정한 password

*) 내가 있는 공간(사무실), 내 IP만 접속 가능하게 하고싶다면 그 IP를 추가하면 됨 (보안그룹 내 인바운드 규칙)

 

- 보안 그룹

: EC2 인스턴스, 다른 AWS 리소스 .. 에 대한 네트워크 트래픽을 제어하는 데 사용되는 방화벽 규칙 → 인바운드/아웃바운드 규칙으로 구성됨

 

- 인바운드 규칙

: 특정 보안 그룹에 속한 리소스로 들어오는 트래픽을 제어, 특정 포트/프로토콜/소스 IP 주소를 기반으로 허용/차단 가능

: 인스턴스로 들어오는 트래픽을 관리

: ex) 웹 서버에 HTTP 트래픽을 허용

: ex) SSH로 인스턴스에 접근 설정

 

- 아웃바운드 규칙

: 리소스에서 나가는 트래픽을 제어하는 데 사용됨

: 특정 포트/프로토콜/대상 IP 주소또는 범위를 기반으로 트래픽을 허용, 차단

: 내부 리소스의 보안 강화, 필요한 트래픽만을 허용

 

 

3. Document DB

*) NoSQL의 종류 (4가지)

: Document, Key-Value, Graph, Column store

 

- Document DB

: MongoDB API와 연계되는 NoSQL

: 문서 전용 (document) 데이터베이스

: 복제본을 최대 15개까지 추가해 읽기 용량을 초당 수백만 개의 요청으로 늘릴 수 있음 (데이터 크기에 상관없이 지연시간 짧은 읽기 전용 복제본) 

: Amazon Document DB는 6개의 데이터 복사본을 3개의 AWS 가용 영역(AZ)에 복제

: 기본적으로 JSON 데이터 제공

: 유연한 인덱싱을 제공

 

- MongoDB

: Document 지향 DB (오픈소스)

: 데이터 중복이 발생할 수도 o, 접근성과 가시성이 좋음

: 스키마 설계 어렵, 스키마 유연

: 분산에 대한 솔루션을 자체적으로 지원, Scale-out이 쉬움

: 확장 시 Application을 변경하지 않아도 됨

: RDBMS → MongoDB = cluster → cluster / database → database / table → collection / row(레코드) → document / column → field

 

- Amazon Document DB 생성하기 (실습)

: 복제된 인스턴스 3개가 cluster로 묶여서 생성됨

: 연결 > key를 받아 접속하는 방법

 

4. Dynamo DB

: Key-Value 기반의 NoSQL 데이터베이스 서비스

: 오토스케일링 (데이터 쌓일 때마다 내부적으로 자동으로 용량 커지도록 / 워크로드의 데이터 볼륨,읽기/쓰기 증가할 때 DynamoDB의 리소스도 스토리지,읽기/쓰기 용량 증가)

: 암호화 제공

: 원하는 양의 데이터를 저장/검색/요청 트래픽 처리할 수 있는 db 테이블 생성해줌

: 리소스 사용률, 성능 지표를 모니터링

: DynamoDB는 온디맨드 백업 기능 제공

: 테이블 생성 시 스키마 생성 필요 없음

: RDBMS → DynamoDB = row → items

: 각 items는 Partition Key + SortKey 가 존재

AWS DB	DocumentDB	DynamoDB
Region	모든 리전에서 사용 가능	제한 o
자격증명	IAM(Identity and  Access Management)을 통해 DB에 대한 엑세스 제어	- DB에서 user을 생성하고 관리함 - 자격 증명이 DB에 직접 저장 → AWS는 이 영역에 대해 관여하지 않음
백업	- 매일 백업을 사용할 수는 없어 사용자가 백업 진행 - 데이터에서 지원하는 대로 필요할 때 데이터 복구 가는ㅇ	- db 자체에서 일일 백업을 관리, 필요할 때마다 복구 가능 - 모든 유형의 백업이 지원됨
NoSQL 타입	document	key-value
확장	쉬운 확장(최대 64TB)	하이퍼 스케일  (용량에 상관 없이 서비스 이용 가능)
최대 데이터 크기	document = 최대 16mb	item = 최대 400kb
특징	- MongoDB API 호환 - 손쉬운 마이그레이션	글로벌 테이블과 같은 차별화된 기능
관리/가격 책정	- 인스턴스 기반 - 스토리지 자동 확장 - 가격(인스턴스, IO, 스토리지, 백업 스토리지)	- 서버리스 - 자동 샤드(Shard) 및 오토스케일 - 가격 책정(온디맨드 vs 프로비전) - 프리티어(무료구간) 사용 가능

 

 

- Amazon Document DB 생성하기 (실습)

: 테이블 생성

: Partition Key, Sort Key 지정

: 테이블에 새로운 데이터 넣고싶을 때 '항목 생성'

: 항목 생성 > 속성 추가

: 조회 시 스캔(partition key 이용) & 쿼리(더 추가적인 정보 이용)

: lambda 서비스 → 원천 데이터(source data, raw data = 대용량임)를 프로그래밍해서 DynamoDB에 입력될 수 있도록 구성함

 

5. Certification Manager

: for 웹사이트 보안

: AWS Cetification Manage(ACM)

: AWS 서비스 및 연결된 내부 리소스에 사용할 공인/사설 SSL/TLS 보안 인증서를 프로비저닝/관리/배포

: SSL/TLS 인증서 구매/업로드/갱신에 드는 프로세스 단축

: AWS 내에서 직접 구매 or 외부에서 구매한 인증서의 키를 AWS에 등록하고 관리 가능

 

- SSL 인증서

: 공개 키 & 개인 키 키 쌍

: 함께 작용해 암호화된 연결을 수립

: 인증서를 얻으려면 서버에서 인증서 서명 요청(CSR)을 생성해야 함 → 여기서 공개키, 개인키가 생성됨

 

- ACM

1) 사용할 인증서를 AWS 계정으로 요청하거나 가져옴

2) DNS또는 이메일 검증을 통해 요청된 인증서의 도메인 소유권을 검증, 인증서 발급 완료

3) 등록된 SSL 인증서의 세팅: ELB(Elastic Load Balancing_EC2의 로드밸런서 메뉴), Amazon CloudFront 등의 AWS에서 새로 발급되거나 가져온 인증서 사용

 

- ACM 인증서 요청 (실습)

: 퍼블릭

: 내가 산 도메인 이름 입력

: DNS 검증 or 이메일 인증

 

6. CloudFront

: 콘텐츠 전송 네트워크(CDN) 서비스 (성능, 보안, 개발자 편의를 위해 구축됨)

: 컨텐츠, 영상, 이미지를 빨리 로딩해서 웹 앱의 뷰, 처리속도를 빠르게 해주는 서비스

: 먼 거리의 서버까지 가지 않고 근거리의 캐싱, 빠르게 서비스 처리

: 데이터 사용량이 많은 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크

: 정적 콘텐츠 & 동적 콘텐츠

: 캐싱 / 동적 가속 / 엣지 로직 계산 등의 기능

: 1) DNS서버에 도메인 요청 2) CDN에서 콘텐츠 로드 (이전에 original server에서 미리 받아둔 컨텐츠) 3) CDN에서 사용자에 게 빠르게 콘텐츠 내려줌

 

- 특징

1) 대기 시간 감소

2) 보안 향상

3) 비용 절감

4) 사용자 정의 전송

 

- Amazon CloudFront 배포 생성 (실습)

: CDN 서비스를 받기 위한 서비스(원본 도메인, 다이렉트로 가지 않고 CDN을 거칠 원본 S3) 선택

: HTTP 프로토콜 관련 옵션 설정

: AWS WAF → 특정 IP를 접속 못하게 막을 수 있음 (WAF & SHEILD)

: SSL 인증서 (CloudFront는 글로벌 서비스, 서울에서 인증서 발급받은 경우 인증서 목록에 뜨지x, 리전에서 인증서 새로 발급 '인증서는 반드시 미국 동부(버지니아 북부) 리전(us-east-1)에 있어야 합니다.')

: 프론트로 구성한 S3에 대해서 CloudFront가 작동, CDN 서비스 이용 가능

 

1) front, 도메인, SSL인증서, 백엔드, S3 구성

2) 최종적으로 CDN 서비스를 중간에 넣어서 구성하는 것이 일반적

 

 

7. Elastic Load Balancing (ELB)

: AWS의 로드밸런서 = ELB

: 네트워크 앞단에 로드밸런서를 둠

: 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법

: 서버에 가해지는 부하(=로드)를 분산(=밸런싱)해주는 장치 or 기술

: 타겟(=대상)을 여러 군데로 나눠서 갈 수 있도록 앞단에서 트래픽이 가는 방향을 세팅하는 역할

: (클라우드가 아니더라도,) 인프라 내에서도 로드밸런서라는 스위치를 두고, 앞단에서 장애 대응하며 가용성을 높임

 

- L4 로드밸런서

: 전송계층 (layer 4)에서 작동

: TCP/UDP(4) 로드 정보를 바탕으로 함

 

- L7 로드밸런서

: 응용계층 (layer 7)에서 작동

: TCP/UDP(4) 뿐만 아니라 HTTP의 URI, FTP(7)의 파일명, 쿠키정보 등을 바탕으로 함

 

- ELB 대상그룹

: 어디에 연결되는 ELB인지 대상을 등록해야 함

: 기본적으로 로드밸런서는 대상 그룹에 대해 지정한 프로토콜, 포트 번호 사용해 등록된 대상으로 요청 전송함

 

- EC2의 로드밸런서 구성하기 (실습)

: 대상 그룹 생성

: 대상 그룹에 대상 추가 → 대상으로 지정한 서비스의 앞단에 ELB가 생성됨 (ELB가 생성될 타깃=대상을 지정하는 과정)

: 로드 밸런서 생성해서 위의 대상 그룹을 가져옴

: Application Load Balancer 생성

: HTTPS 선택 시 인증서 구성해야 함

: ELB의 보안 그룹 설정

: 대상 그룹 설정

 

8. Amazon Virtual Private Cloud(Amazon VPC)

: 사용자가 정의한 가상 네트워크로 AWS 리소스 시작할 수 있음 (스위치, 장비로 구성된 데이터 센터 네트워크와 유사 → 클라우드 안에서 VPC 가상 네트워크 망으로 구성해서 app, 서버 관리)

: AWS의 확장 가능한 인프라를 사용 + 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사함

: 여러 VPC 간을 연결하는 VPC peering connection

: VPC 내에 여러 subnet을 둬서 운영 → 가상의 네트워크를 관리

 

- 서브넷

: VPC의 IP 주소 범위 (private or public)

: 단일 가용 영역에 상주해야 함

: 서브넷을 추가한 후 VPC에 AWS 리소스 배포/관리 가능

 

- IP 주소 지정

: VPC와 서브넷에 IPv4, IPv6 주소 할당 가능

 

- 라우팅

: 라우팅 테이블을 이용해 서브넷 or 게이트웨이의 네트워크 트래픽이 전달되는 위치를 결정

 

- (VPC에서의) 게이트웨이

: VPC를 다른 네트워크에 연결함

: VPC 엔드포인트 서비스를 사용해 인터넷 게이트웨이 or NAT 장치를 사용하지 않고 각종 AWS 서비스에 비공개로 연결

 

- 피어링 연결

: VPC 피어링 연결을 사용해 두 VPC간의 리소스 간 트래픽을 라우팅

 

- 트래픽 미러링

: 네트워크 인터페이스에서 네트워크 트래픽을 복사, 들어오는 트래픽에 대해 심층 패킷 검사를 위해 보안/모니터링 appliance로 전송

 

- Transit Gateway

: 중앙 허브 역할을 하는 전송 게이트웨이 사용

: VPC, VPN 연결 및 AWS Direct Connect 연결 간의 트래픽을 라우팅

 

- VPC 흐름 로그

: VPC의 네트워크 인터페이스로 들어오고 나가는 IP 트래픽에 대한 정보 캡쳐

 

- VPC 연결

: AWS VPN(Virtual Private Network)를 사용해 온프레미스 네트워크에 VPC 연결

 

- CIDR(Classless Inter-Domain Routing, 사이더)

: 클래스 없는 도메인 간 라우팅 기법

: IP 대역을 나누는 A~E class 없이 CIDR를 통해 도메인 간 라우팅

ex) IP주소: 174.16.0(네트워크 영역).0(호스트 영역) → 8비트씩 4부분 = 32비트로 구성 (비트 카운팅 시스템)

 

: CIDR 표기 = 어디까지 네트워크/호스트 영역으로 구분할지에 대해 나타냄

ex) 172.16.0.0/24 → 앞에서부터 24비트까지가 네트워크, 나머지 8비트가 호스팅 영역

ex) 152.2.136.0/26 → 앞에서부터 26비트까지가 네트워크, 나머지 6비트가 호스팅 영역

→ 어느 대역까지 IP를 쓸 수 있는지를 표현함

→ IP 대역을 많이 쓰고싶은 경우 = 호스트 영역에서 많은 비트를 가지도록 = 네트워크 영역의 비트는 적게

 

- NAT gateway

: public subnet = 외부와 인터넷을 할 수 있는 서브넷 (자동으로 인터넷 게이트웨이가 연결됨, 외부와 자유롭게 통신)

: private subnet = NAT gateway를 설정해서 외부와 통신할 수 있도록 해야함 (다이렉트로 외부와 연결은 불가)

 

- NAT 장치

: 사설 네트워크 내의 여러 장치가 인터넷에 연결될 수 있도록 공용 IP 주소를 공유하게 해줌 → IP 주소 부족 문제 해결, 보안 강화, 네트워크 트래픽 관리 목적

1) IP 주소 변환: 사설 IP ↔ 공인 IP 간의 주소 변환, 사설 네트워크에 있는 장치들은 NAT 장치를 통해 외부로 나가는 트래픽 시 공인 IP 주소로 변환돼 인터넷에 연결

2) 포트 포워딩: 특정 포트로 들어오는 외부 요청을 사설 네트워크 내 특정 장치로 전달

3) 보안 강화: 내부 네트워크(private)를 외부에서 숨김, 외부에서 내부 장치에 직접적으로 접근하는 것을 막아 보안을 강화함

4) 트래픽 관리: 트래픽 관리, 필요에 따라 허용되는 트래픽을 제어, 네트워크 리소스를 효율적으로 관리

 

 

- VPC 생성 (실습)

: IP 주소 범위 선택 (CIDR)

: 각 가용 영역(AZ, 리전 안에 여러 AZ 둘 수 있음)별 서브넷 설정, AZ 하나에 서브넷들이 들어갈 수 있음

: 인터넷으로 향하는 경로(route) 만들기

: VPC로부터의 트래픽 설정

 

: VPC 생성 > VPC 등 > 가용영역, 서브넷 등.. 자동으로 편리하게 구성해줌

: public 서브넷은 인터넷 게이트웨이가 자동으로 설정 ('igw~'로 시작함)

: private 서브넷은 NAT 게이트웨이 설정해주기 (2개 중 1개의 AZ에서, 혹은 2개의 AZ당 1개씩)

: AZ = (기본 설정, 리전은 서울일 경우) ap-northeast-2a, ap-northeast-2b

 

- VPC 엔드포인트

: AWS의 서비스에 VPC 내부에서 안전하게 엑세스할 수 있도록 하는 서비스

: AWS 서비스에 대한 연결 허용, 안전하게 접근

: 일반적으로, AWS 서비스는 퍼블릭 인터넷을 통해 엑세스 됨 → VPC 엔드포인트 사용시 VPC 내부의 인스턴스가 인터넷을 통하지 않고도 AWS 서비스에 연결 가능

: 두 가지 주요 유형

1) Gateway 형 VPC 엔드포인트: S3와 DynamoDB와 같은 AWS 서비스에 대한 액세스를 제공, 퍼블릭 인터넷을 통하지 않고 VPC 내부에서 해당 서비스에 직접 연결

2) Interface 형 VPC 엔드포인트: 다른 AWS 서비스와의 통신을 위한 프라이빗한 인터페이스를 제공, 이 엔드포인트는 VPC 내부의 인스턴스가 인터넷을 통하지 않고 AWS PrivateLink를 통해 다른 서비스에 연결할 수 있게 함

 

 

*) 클라우드 컴퓨팅에서의 엔드포인트

- 일반적으로 '두 지점이나 시스템 간에 데이터 Or 통신이 이뤄지는 위치나 인터페이스', '데이터가 출발 or 도착하는 곳'

- in 네트워크: 통신이 시작되거나 끝나는 지점 / 서비스 간 통신에서 API → 특정 서비스의 특정 기능에 접근하기 위한 URL or 엔드포인트로 사용됨

- in 클라우드 컴퓨팅: 클라우드 서비스의 특정 지점을 가리키는 경우가 대부분 (ex: AWS의 엔드포인트 = 특정 서비스나 리소스에 연결할 때 사용되는 URL or interface → 데이터가 AWS의 특정 서비스로 흐르는 지점)

 

---

 

💡Furthermore

• 설명 부족한 부분 따로 개념 이해
  • Route53
  • DNS 찾아가는 과정
  • 서브 도메인 설정
  • 인바운드 규칙 (VPC 보안그룹)
  • 게이트웨이, NAT장치, VPC 엔드포인트