23.08.03
1. Elastic Load Balancer
1-1. Scalability (확장성) vs Availability (가용성)
가용성
ex. 어느 한 시스템에서 고장이 났을 때 서비스가 중단되지 않고 다른 데이터 서비스에서 이어서 끊김없이 서비스를 제공할 수 있게 하는 것을 고가용성이라고 함
=> 즉, 안정적인 서버를 계속 유지하기 위해서는 고가용성이 중요함
확장성
수평적 확장 : 인스턴스나 서버, DB 등을 여러개로 늘리는 것 => 즉, 인스턴스의 개수를 늘리는 것
수직적 확장 : 인스턴스는 하나인데 성능을 높이는 것
1-2. ELB
ELB (Elastic Load Balancer) : AWS에서 제공하는 로드 밸런싱 서비스로, 다수의 EC2 인스턴스를 사용하여 트래픽을 분산
로드밸런서를 쓰는 이유
- 요청 분산 (EC2와 연동)
- 단일 액세스 포인트 공개 (Route 53과 연동) => naver.com 이라면 naver.com이라는 하나의 액세스 포인트만 공개 (즉, 주소 DNS와 연관)
- 인스턴스에 대한 헬스 체크 => 어느 인스턴스가 살아있나
- HTTPS 제공 (ACM과 연동) => HTTP로 보안이 되어있지 않은 웹사이트에 HTTPS를 제공
- 고가용성 제공
- 공개 트래픽(ex. user)과 내부 트래픽(ex. EC2) 분리
ELB 종류
- Application Load Balancer : OSI 모델 7계층에서 동작하며, HTTP/HTTPS 트래픽을 처리. 또한, 컨테이너화된 애플리케이션과 연동하여 사용할 수 있음 (URL, Query String 이런 걸 기준으로 컨텐츠의 요청을 보냄)
- Network Load Balancer : OSI 모델 4계층에서 동작하며, TCP/UDP 트래픽을 처리. 높은 처리량을 필요로 하는 애플리케이션에 적합
- Classic Load Balancer : OSI 모델 4~7계층에서 동작하며, HTTP/HTTPS, TCP/UDP 트래픽을 처리. 가장 오래된 형태의 로드 밸런서이며 요즘에는 Application Load Balancer나 Network Load Balancer를 사용하는 것이 좋음
- Gateway Load Balancer : 다른 방화벽이나 써드 파티의 어플리케이션들을 갖다가 사용할 때 사용하면 적합
그렇다면 Application Load Balancer의 특징은 ?
- HTTP 요청을 여러 타깃 그룹에 나눠줄 수 있음
- 한 머신 안이라도 여러 어플리케이션(컨테이너)에 나눠 줄 수 있음
- HTTP/2와 웹소켓을 지원
- HTTPS로 리다이렉트 지원
- URL, hostname, query string, header에 기반해서 다른 타깃 그룹(ex. EC2)으로 보낼 수 있음
1-3. SSL과 HTTPS
SSL(Secure Sockets Layer) : 인터넷 상에서 정보를 안전하게 전송하기 위한 프로토콜 => 전송되는 데이터를 암호화하여 정보의 안전성을 보장.
TLS(Transport Layer Security) : SSL을 보완한 기술로 현재는 사실 SSL이 아니라 TLS 기술이다. => 그러나 모두가 아직까지 SSL이라고 부르고 있는 것
user들이 load balancer에 올 때는 https 통신으로 오고
load balancer에서 EC2 갈 때는 가상 사설망이기 때문에(= 외부 진입을 막아놓고 내부에서만 오고가기 때문에 = 도청당할 수 없기 때문에) http 통신도 괜찮음
2. Relational Database Service
2-1. RDS
RDS : SQL을 쿼리 언어로 사용하는 관계형 DB를 위한 서비스
ex. Postgres, MySQL, MariaDB, Oracle, Microsoft SQL service ...
EC2 상에 DB만들기보다 RDS가 나은점 (장점)
- RDS는 DB를 위한 인프라를 자동으로 구축(provisioning), 업데이트
- 지속적인 백업과 복구 기능 지원
- 모니터 대시보드 지원
- 성능향상을 위한 read replicas 지원
- Disaster Recovery를 위한 multi AZ 지원
- 수평/수직 확장성 지원
- EBS 백업 지원
(단점)
- 하지만 SSH로 접속 불가능 => 즉 터미널로 접근이 불가함
RDS가 지원해주는 기능
- Storage Auto Scaling : DB 용량의 한계치까지 왔을 때 자동으로 용량을 늘려줌
- 사용을 위해 Maximum Storage Threshold를 지정해줘야 함 (이거 이상을 넘어가지마라 !)
- 예측불가능한 트래픽이 있을때 유용 (ex. 이벤트가 있어 사람들이 글을 어마어마하게 쓸 것 같다 !)
- Read Replicas : 읽기 전용 복제품
- read replica는 오직 SELECT문만 가능 INSERT, UPDATE, DELETE는 불가능! => 즉, CRUD에서 R만 가능, CUD는 불가능
- Multi AZ : 서버(어플리케이션)가 RDS와 write와 read를 하다가 다른 AZ에 그대로 옮기는 것(= 백업) => 이렇게 되면 RDS에 만약 화재같은 사고가 나도 다른 Multi AZ에 백업되어있는 것이 있어서 계속 서버를 유지할 수 있음 ! (= 즉, 가용성이 높음 !!!)
- 가용성을 높여줌
- 확장성을 높여주지 않음 (확장성과는 관계 없음)
- 수동으로 설정할 필요가 없으
- read replica도 multi az로 쓰일 수 있음
3. Route 53
3-1. DNS
DNS(Domain Name System) : 인터넷에서 사용되는 컴퓨터나 기기들의 주소를 '도메인 네임'으로 변환하여 IP 주소를 가져오는 것 (일반 사용자들이 IP 주소를 외우고 기억하는 건 어렵기 때문에 ...)
Q. 그렇다면 여기서 도메인 네임이란 ?
A. URL (ex. naver.com ...)
DNS 계층 구조
만약 URL이 http://www.naver.com 라고 한다면 ?
- Root Level : ""
- Top Level Domain : .com
- Second Level Domain : naver
- Subdomain : www
- Protocol : http
=> 즉, DNS 서비스는 계층적으로 구성된 분산 시스템 => 이 계층 구조에서는 Root DNS Server, TLD DNS Server, SLD DNS Server가 각각의 역할을 수행
- Root DNS Server : DNS 계층 구조에서 가장 상위에 위치한 DNS 서버
- 모든 DNS 쿼리는 먼저 Root DNS Server에 도착하여 해당 도메인의 TLD(Top-Level Domain) DNS Server의 주소를 알아내야 함
- Root DNS Server는 인터넷 상에서 전 세계에 총 13개가 운영되고 있으며, 이들은 전 세계의 인터넷 서비스 제공 업체들에 의해 운영
- TLD DNS Server : 도메인 이름의 최상위 레벨에 해당하는 .com, .net, .org, .kr 등의 TLD를 관리하는 DNS 서버
- 모든 도메인 이름은 하나 이상의 TLD에 속하며, TLD DNS Server는 해당 도메인 이름이 속한 SLD(Secod-Level Domain) DNS Server의 주소를 알려줌
- SLD DNS Server : 도메인 이름의 중간 레벨에 해당하는 DNS 서버
- 도메인 이름의 중간 레벨에 해당하는 부분은 일반적으로 사용자가 만든 이름이며, SLD DNS Server는 해당 도메인 이름에 대한 IP 주소를 반환
=> 즉, 정리해보면 Root DNS Server는 인터넷에서 가장 상위에 위치, TLD DNS Server는 도메인 이름의 최상위 레벨을 관리, SLD DNS Server는 중간 레벨을 관리
=> 이들은 모두 인터넷 사용자가 도메인 이름을 입력하여 해당하는 웹 사이트나 이메일을 찾을 때 중요한 역할을 수행
=> 사용자가 브라우저를 통해 도메인 이름을 입력해서 웹 사이트를 찾을 때마다 Local DNS가 Root DNS나 TLD DNS나 SLD DNS를 다 거쳐서 IP 주소를 가져오는 것은 너무 비효율적이기 때문에 Local DNS와 브라우저에서도 캐싱이 일어나서 기억하고 있는 것은 저장하고 있다가 바로바로 알려줌 !
+) Route 53은 TLD DNS Server + SLD DNS Server
+) nslookup은 name server 관련한 조회를 할 수 있는 명령어
그래서 아래 223.130.200.107를 주소창에 입력하면 naver.com으로 이동하게 됨
nslookup naver.com
// 223.130.200.107
nslookup google.com
// 142.250.76.1423-2. 왜 53인가 ?
Q. Route 53에서 53은 무엇일까 ?
A. 53은 통신에 사용되는 프로토콜 중 하나인 DNS에서 사용하는 기본 포트 번호, 기본적으로 TCP와 UDP를 사용하며, TCP 53번 포트와 UDP 53번 포트를 사용
3-3. IPv4v6, 레코드타입, TTL
IPv4 vs IPv6
IPv4 : 인터넷 프로토콜(IP) 주소 체계, 32비트로 구성된 주소 체계로, 최대 약 43억개의 IP 주소를 사용 가능
ex. 192.168.0.1
하지만, 인터넷 사용자의 증가로 인해 IPv4 주소가 부족해지는 문제가 발생 => 이에 따라, IPv6가 등장 !
IPv6 : 새로 등장한 인터넷 프로토콜(IP) 주소 체계, 128비트로 구성된 주소 체계로, 약 340경개의 IP 주소를 사용 가능
ex. 2001:0db8:85a3:0000:0000:8a2e:0370:7334
쉽게 비유하자면 핸드폰 번호가 11자리에서 30자리로 늘어났다고 생각하면 됨
IPv6는 IPv4에 비해 주소 고갈 문제 해결과 보안성, 기능 면에서도 개선됨
레코드타입
- A 레코드: 호스트네임과 'IPv4 주소'를 연결
- AAAA 레코드: 호스트네임과 'IPv6 주소'를 연결
- CNAME 레코드: 호스트네임을 다른 호스트네임과 연결, 다른 호스트네임은 반드시 A 혹은 AAAA 레코드가 있어야 함
- NS 레코드: 호스트존의 네임서버를 지정
+) 호스트존은 주소록, public 호스트존은 도메인 네임의 IP 주소를 가리키며, private 호스트존은 사설망 내부에서 사용
+) 또한, SOA 레코드는 메타 데이터를, NS 레코드는 네임서버 정보를 담고 있음
CNAME vs Alias
CNAME과 Alias 모두 DNS 레코드의 유형으로 두 레코드는 호스트 이름을 다른 호스트 이름에 매핑하는 데 사용하나 용도는 다름
- CNAME 레코드 : 이전에 정의된 호스트 이름의 모든 레코드를 복사하여 새 호스트 이름에 할당.
이는 호스트 이름이 변경되었거나 호스트 이름이 서로 다른 IP 주소를 가리키도록 하려는 경우에 유용.
CNAME은 루트 도메인이 아닌경우에만 적가능
(ex app.mydomain.com - O, http://mydomain.com - X)
- Alias 레코드 : 호스트 이름을 AWS 리소스(ex. Amazon S3 버킷, Elastic Load Balancer, Amazon CloudFront ...)에 매핑.
이를 통해 AWS 리소스에 대한 DNS 레코드를 만들 수 있음. Alias 레코드는 Amazon Route 53에서만 지원
TTL
TTL(Time to Live) : DNS 레코드가 캐싱될 수 있는 최대 시간을 나타내는 값(= 캐싱을 얼만큼 오래 할 것인가) TTL이 높을수록 DNS 레코드가 캐싱될 수 있는 시간이 더 길어지므로, 캐시 효율성은 높아짐
