AWS SAA(ElastiCache, Route53)

ElastiCache

ElastiCache란?

Redis 또는 Memcached의 관리형 서비스
Cache는 in-memory Database, 낮은 지연율과 높은 성능을 가지고 있음
DB 읽기 부하를 줄일 때 많이 사용함
운영되고 있는 어플리케이션이 무상 태성을 가지도록 도와줌
OS와 관련된 모든 운영 요소를 AWS에서 관리함
Cache가 적용되지 않았던 서비스에 적용할 때 코드 변경이 많이 필요함
애플리케이션 → ElastiCache(이미 있으면 Retrun) → 캐시에 없다면 RDS 쿼리 실행 → 실행 쿼리 ElastiCache에 저장
애플리케이션 로그인 → ElastiCache에 로그인 세션 저장 → 사용자가 타 인스턴스에 접근시 ElastiCache의 세션 데이터로 로그인 상태 유

ElastiCache - 레디스와 Memcached 차이

레디스

멀티 AZ와 자동화된 복구를 지원
읽기 복제본 사용 가능
AOF 영속성을 통해 데이터를 관리할 수 있음( 읽기 이벤트 저장)
백업과 복구 기능이 있음
Sorted Set / Set 기능을 지원함

Memcached

여러 개 노드 간 데이터 샤딩이 가능함
읽기 복제본 사용이 불가능함
영속성을 관리할 수 없음
복구 또는 백업이 불가능함
멀티 쓰레드 아키텍처를 지원함

ElastiCache - 캐시 보안

IAM 기반 인증을 제공함
IAM 정책을 통한 보안은 AWS API 레벨 보안에서만 동작함
Redis AUTH
- 비밀번호 / 토큰을 생성 시에 설정할 수 있음
- 필요한 경우 설정함
- SSL 암호화 통신을 지원해줌
Memcached
- SASL 기반 인증을 지원함

ElastiCache - 활용

Lazy Loading 패턴을 사용할 수 있음
- 업데이트 시 캐시에 저장해 주어야 함
Session 관리 용도로 사용함
캐시 사용 시 네이밍과 캐시 정합성 검사를 제외하면 어려울 점이 없음
- 중요하고 불변성이 유지되어야 한다면, 사용하지 않는 게 좋음
Redis - Sorted Set
- 순서를 보장함
- 유니크를 보장함
- 순위를 측정하는 용도의 읽기 / 쓰기가 많은 경우 유용하게 사용할 수 있음

ElastiCache 활용 - DB 캐시

어플리케이션에서캐시를 가져오려고 시도함
없다면 RDS를 통해 데이터를 읽어옴
읽어온 데이터를 캐시에 저장하고 반환함

ElastiCache 활용 - 사용자 세션으로 활용하기

사용자가 로그인하면 세션 정보를 캐시에 저장함
저장된 캐시를 기반으로 다른 서버에서도 로그인 확인이 가능하도록 함
여러 개 인스턴스에서 다 같이 세션을 관리할 수 있음
로컬 캐시 대신 사용함
여러 인스턴스가 있는 상황에서는 필수

Route53

DNS란?

Route53 은 AWS에서 제공하는 DNS 서비스임
DNS(Domain Name System) 은 IP 대신 사람이 이해할 수 있는 형태로 작성된 호스트 명
예를 들면 http://www.google.com -> 172.217.18.36으로 해석됨
DNS는 인터넷을 유지해 주는 backbone
DNS는 계층화된 구조를 사용함
- .com
- example.com
- http://www.example.com
- api.example.com
- api-test.example.com

DNS란? - 용어

Domain 등록 대행자(registrar):
- Amazon Route53 / GoDaddy / 가비아... etc
DNS 레코드
- A / TXT / CNAME / NS / AAAA ... etc
Zone File: DNS 레코드를 담은 파일
네임서버: DNS 쿼리를 처리하는 서버
TLD 최상위 레벨 도메인: .com .org .kr .dev 등
SLD 차상위 레벨 도메인: naver.com / amazon.com / gmail.com
- http://test.api.example.com
- 프로토콜 - 서브네임 - SLD - TLD 순으로 구성됨

DNS란? - 동작

브라우저가 example.com에 접속할 때?
Root -> TLD -> SLD 순으로 ip 조회
ip 가 조회되면 Web 서버로 요청을 진행함

Route53란?

고가용성과 확장성을 가지고 있음
AWS에서 매니징 하는 완전 관리형 서비스임
사용자가 DNS 레코드를 업데이트할 수 있음
도메인 등록 대행업체기도 함
리소스에 대한 헬스 체크를 진행해줌
유일하게 100% 가용성을 보장하는 서비스임
53은 DNS 포트로 사용되던 숫자

Route53 - 레코드

도메인에 접근하는 트래픽을 어떻게 라우팅할지 결정할 수 있음
각 레코드의 구성요소
- 도메인 또는 서브 도메인명
- 레코드 타입
- 값 - IP 또는 다른 도메인명 등
- Routing 정책
- TTL(Time to live) - DNS Resolver 가 레코드를 보존하는 시간
Route 53에서 지원하는 레코드 타입
- A /AAAA / CNAME / NS
- CAA /DS / MX / NARTR / PTR / SOA / TXT / SPF / SRV

Route53 - 필수 레코드 type

A 레코드
- ipv4 와 호스트명을 연결함
AAAA 레코드
- ipv6 와 호스트명을 연결함
CNAME
- 호스트 네임 간 연결을 지원함
- 대상 호스트는 반드시 A 또는 AAAA 레코드여야 함
- CNAME은 최상위로 설정할 수 없음
- 서브 도메인으로만 생성할 수 있음
NS 레코드
- 호스트 존 네임서버를 위한 타입
- 도메인 내부 트래픽 라우팅을 관리함

Route53 - Hosted Zone

도메인과 서브 도메인에 대한 트래픽 라우팅을 관장함
Public Hosted zone
- 인터넷상에서 들어오는 트래픽에 대한 라우팅 레코드 정의를 담고 있음
Private Hosted zone
- 한 개 또는 여러 개의 VPC 내부망에서 트래픽 라우팅 레코드 정의를 담고 있음
각 hosted zone 은 0.50 달러의 비용이 나옴

Record TTL이란

TTL 은 DNS 정보에 대한 캐싱 시간을 나타냄
높은 TTL
- 24시간 이상의 TTL
- Route 53 트래픽이 감소함(비용도 감소)
- 레코드 변경에 대한 반영이 늦게됨
낮은 TTL
- Route 53에 요청이 더 많아짐
- 레코드 변경을 자주 해야 하거나 변경이 필요한 경우 사용이 용이함
- 하지만 비용이 더 나올 수 있음
Alias 레코드는 적용되지 않음
TTL 은 각 레코드별로 필수적으로 적용됨

CNAME과 ALIAS 구분하기

AWS 리소스들은 자체적인 AWS 호스트명을 가진 경우가 있음
CNAME
- 다른 호스트네임을 바라보는 레코드
- 서브도메인에만 적용할 수 있음 → www.google.co.kr, map.google.co.kr
- 루트도메인에는 불가함(하나의 TLD + 하나의 . 조합) → google.co.kr
Alaias
- AWS 리소스에 대한 별칭 생성을 목적으로 함(AWS리소스)
- 루트 도메인과 서브도메인 모두 적용할 수 있음
- 자체적인 헬스 체크가 있음
- route53 비용이 별도로 발생하지 않음

ALIAS

호스트 명과 AWS 리소스를 연결해줌
DNS 기능의 확장판
리소스의 IP 변경을 자동으로 인지함
CNAME 과 다르게 루트 도메인에 적용이 가능함
alias 레코드는 항상 A / AAAA 레코드
TTL 을 별도로 지정할 수 없음

ALIAS 타겟은 어떤게 가능할까?

ELB
Cloudfront Distribution
API 게이트웨이
Elastic Beanstalk 환경
S3 웹사이트
VPC 엔트 포인트
글로벌 엑셀러레이터
같은 hosted zone 내부의 record
EC2 DNS에는 적용할 수 없음

라우팅 정책

DNS 쿼리에 대해 Route 53이 응답하는 방식을 정함
라우팅이란?
- 로드 밸런서의 트래픽 라우팅과는 다름
- DNS 요청에 대한 응답을 하고 목적지를 알려줌
Route 53 지원 정책
- Simple
- Weighted
- Failover
- Latency 기반
- 위치 기반
- Multi-value 응답
- Geoproximity

라우팅 정책 - Simple

단일 리소스에 대한 라우팅
동일 레코드에 여러 개를 설정할 수 있음
여러 값이 있다면, 클라이언트가 랜덤하게 하나를 정함
Alias 가 설정된 경우 하나의 AWS 리소스 만을 지정함
헬스 체크와 연동이 불가능함

라우팅 정책 - Weighted

요청에 대한 %로 특정 리소스에 대해 요청함
각 레코드에 상대 비중을 두어요
- 비중의 합이 꼭 100이 될 필요는 없음
각 레코드는 모두 같은 이름과 타입이어야 함
헬스 체크를 적용할 수 있음

라우팅 정책 - Weighted

리전간 로드밸런싱을 하거나 신규 어플리케이션을 테스트할 때 사용함
0으로 설정하면 해당 레코드로는 요청을 라우팅하지 않음
모든 레코드를 0으로 설정하면 모든 레코드에 동일한 비율로 요청함

※ 단일 AZ 또는 ALB로 보낼경우 의미 없고, 다른 리건 간 또는 ALB별로 가중치를 나눌때 사용

라우팅 정책 - Latency 기반

사용자에게 가장 적은 지연시간이 있는 리소스로 리다이렉트함
지연시간이 가장 중요한 서비스에 적절함
사용자와 리전간의 트래픽에 기반함
한국과 미국 리전에 서비스가 올라가있다면 남미 사용자는 미국 리전으로 일본 사용자는 한국 리전으로 라우팅 됨
헬스 체크를 적용할 수 있음

Route 53 - 헬스 체크

HTTP 헬스 체크는 Public 리소스에서만 사용 가능함
헬스 체크는 자동화된 DNS Failover를 지원함
- 엔드 포인트에 대한 헬스 체크를 진행함
- 다른 헬스 체크를 모니터링함
- Cloud watch 알람을 모니터링할 수 있음
헬스 체크는 Cloud watch 메트릭으로 확인할 수 있음

Route 53 - 헬스 체크의 엔드포인트 모니터링

전 세계 15개의 헬스 체커가 엔드 포인트 헬스 체크를 진행함
- 기본으로 3번 시도함
- 30초 단위로 체크함
- HTTP / HTTPS / TCP 기반으로 헬스 체크를 진행함
- 18% 이상의 헬스 체크가 통과하면 Route 53은 healthy로 판단함
- 위치를 설정할 수 있음
헬스 체크는 2xx 또는 3xx 상태 코드만 pass 할 수 있음
첫 5120 바이트 이내의 텍스트를 기반으로 pass/fail 을 설정할 수 있음
Route53을 통해 들어오는 헬스 체크를 받을 수 있도록 router 또는 방화벽을 설정해야 함

Route 53 - 계산된 헬스 체크

여러 개 헬스 체크의 결과를 묶어서 하나로 관리함
OR | AND | NOT 구문을 사용할 수 있음
256 개 하위 헬스 체크를 모니터링할 수 있음
pass / fail 을 몇 개 이상 통과했을 때 healthy로 판단할 수 있는지 셋팅할 수 있음
전체 헬스 체크가 실패하기 전에 사이트를 관리하는 데 사용함

Private Hosted Zone 에서 헬스체크

Route 53 health check는 vpc 밖에서 동작함
private resource 헬스 체크는 직접적으로 진행할 수 없음
Cloud watch 메트릭과 cloud watch 알람을 기반으로 헬스 체크를 설정함

Routing 정책 - Failover

하나의 메인 엔드 포인트를 가지고 있음
메인 엔드 포인트가 실패하는 경우 서브로 라우팅을 전환함
장애 대응을 위해 구성함

Routing 정책 - Geolocation

지연 기반 정책과는 다른 기능
사용자의 지역에 따라 라우팅을 함
대륙, 국가 또는 미국의 경우 주에 따라 위치를 지정함
기본 레코드를 따로 생성해야 함 (매칭되는 지역이 없으면 기본레코드로 라우팅 됨)

Routing 정책 - Geo Proximity

사용자와 리소스의 지리적인 위치를 기반으로 트래픽을 라우팅함
지정된 편향을 기반으로 더 많은 트래픽을 리소스로 전달할 수 있음
지리적인 리젼의 사이즈를 조정하려면 bias 값을 지정함
- 1 ~ 99 - 더 많은 트래픽을 리소스로 보냄
- -1 ~ -99 - 더 적은 트래픽을 리소스로 보냄
AWS 리소스 / AWS 리소스가 아닌 것 모두 해당됨
- AWS 리소스의 거리는 리젼을 기반으로
- AWS 리소스가 아닌 경우 위경도 좌표를 입력해야 함
Route 53 Traffic Flow 기능을 반드시 사용해야 함

Routing 정책 - IP 기반 라우팅

사용자 IP 주소를 기반으로 Routing 함
사용자 IP CIDR를 입력해야 함
- CIDR에 해당하는 엔드 포인트를 입력해 주어야 함
성능 향상 또는 네트워크 비용 감소를 위해 설정함
특정 인터넷 공급 업자를 통해 들어오는 요청을 특정 리소스로 라우팅하기 위해서 사용하기도 함

Routing 정책 - 여러개 값

트래픽을 여러 리소스로 라우팅하기 위해 사용함
Route 53 은 여러 개 값과 리소스를 반환함
헬스 체크와 함께 사용할 수 있음
최대 8개의 healthy 상태 리소스를 반환할 수 있음(unhealthy인 리소스는 반환되지 않음)
ELB를 대체하는 목적으로 사용하면 안 됨!

도메인 등록 업체와 DNS

기간 단위 금액을 지불하고 구매하는 곳 → 도메인 등록 대행업체
일반적으로 도메인 등록 업체는 DNS 서비스를 제공함
다른 도메인 등록업체에서 구매했더라도, 다른 DNS에서 등록할 수 있음
Godaddy에서 구매했어도 Route53에서 관리할 수 있음

※ 외부 도메인 업체에서 도메인 등록하고, NS 또는 네임서버의 값을 AWS Route53 공용 호스트 존 네임서버란에 넣어주어야 함

현재까지 전체적인 아키텍처의 흐름을 정리

사용자가 늘어남에 따라 수직적 확장 단, 확장하는 시간동안 서비스가 중단됨

단일 서비스 중단으로 인한 장애를 방지하고자 수평적 확장 단, 사용자들이 알아야하는 IP들이 늘어남

Route53을 이용해 사용자들은 하나의 도메인으로 접근이 가능 단, 하나의 인스턴스가 중단되면 해당 인스턴스로 접근한 사용자들은 서비스 이용에 여전히 장애가 발생

로드밸런서 헬스체크를 통해 인스턴스 하나에 장애가 생겨도 다른 인스턴스로 로드밸런싱 됨 단, 수동으로 인스턴스를 확장·축소 해주어야 함

오토스케일링 그룹이 기본적으로 수요에 따라 확장·축소 관리하며 멀티 AZ로 구성되어 하나의 AZ가 장애가 생겨도 대응 가능

사용자의 세션 정보를 다른 인스턴스로 로드밸런싱 되어도 유지될 수 있게 ElastiCache를 사용. 사용자가 필요한 정보를 Read 할때에도 이미 조회 했던 정보라면 ElastiCache에서 바로 전달하여 RDS에 가지 않음

그 외의 방법

ELB Stickiness를 이용해 첫 번째 요청 이후의 요청도 동일한 인스턴스로 보냄(해당 인스턴스 중단되면 문제 발생)
Cookie를 이용해 클라이언트가 해당 정보를 가지고 있음(HTTP요청이 무거워 지고, 보안 위험 등)
DynamoDB도 있는데 아직 학습되지 않음

Beanstalk(실무에서 많이 사용 안하는 듯)

기존 AWS 서비스 조합

EC2 (컴퓨팅)
ASG (자동 확장)
ELB (로드밸런싱)
RDS (데이터베이스)

AWS가 자동 관리하는 항목

용량 프로비저닝
로드밸런싱
스케일링
애플리케이션 헬스 모니터링
인스턴스 구성

개발자 책임 - 오직 애플리케이션 코드만 작성, 인프라 설정 불필요

비용

Beanstalk 자체: 무료
실제 비용: 생성된 EC2, RDS 등 리소스만 과금

Beanstalk 구성 요소
Application - Beanstalk 컴포넌트들의 집합체 (환경, 버전, 설정 등)

환경 특징

한 번에 하나의 버전만 실행
Web Server Tier / Worker Tier 구분
여러 환경 생성 가능 (dev, test, prod 등)

Tier 종류

Web Server Tier: 사용자 요청 처리 (ELB + EC2)
Worker Tier: 백그라운드 작업 처리 (SQS + EC2)

배포 프로세스
1. Create Application (애플리케이션 생성)
         ↓
2. Upload Version (코드 업로드)
         ↓
3. Launch Environment (환경 실행)
         ↓
4. Manage Environment (환경 관리)

'IT > AWS' 카테고리의 다른 글

AWS SAA(SQS, SNS, Kinesis, Amazon MQ) (0)	2025.10.12
AWS SAA(CloudFront, Global Accelerator, Storage Extras) (0)	2025.10.12
AWS SAA(S3) (1)	2025.10.02
AWS SAA(Load Balancer, Auto Scaling, RDS, Aurora) (2)	2025.09.27
AWS SAA(IAM, EC2) (1)	2025.09.23

IT-centralpark