[SK shieldus Rookies 29기] 31일차

7. 데이터베이스 서비스

7.1 데이터베이스 서비스 개요

AWS의 데이터베이스 선택지

AWS는 다양한 데이터 모델에 맞춘 여러 종류의 데이터베이스 서비스를 제공합니다.

데이터 저장 방식에 따른 분류:

1. 관계형 (RDB)

• Amazon RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB)
  • Amazon Aurora (AWS 자체 개발, RDS의 상위)

2. 키-값 (NoSQL)

• Amazon DynamoDB (완전 관리형 NoSQL)

3. 기타 특수 DB

• Amazon DocumentDB (MongoDB 호환)
• Amazon Neptune (그래프 DB)
• Amazon Timestream (시계열 DB)
• Amazon QLDB (원장 DB)

관리형 서비스 (Managed Service)

온프레미스 데이터베이스:

• 하드웨어 구매, 설정
• OS 설치, 패치
• DB 소프트웨어 설치, 버전 업그레이드
• 백업 자동화
• 모니터링, 성능 튜닝
• 고가용성 구성 (Replication, Failover)
  = 관리 및 사고 부담 매우 큼

AWS RDS / DynamoDB:

• AWS가 인프라 관리
• AWS가 OS 패치
• AWS가 DB 소프트웨어 관리
• 자동 백업
• 모니터링 + 경보
• Multi-AZ 고가용성 기본 제공
  = 데이터와 쿼리에만 신경쓰면 됨

---

7.2 Amazon RDS (관계형 데이터베이스)

RDS란?

Relational Database Service = AWS가 관리해주는 관계형 데이터베이스

전통적인 SQL 기반 데이터베이스를 AWS 클라우드에서 사용할 수 있게 제공
마치 EC2를 사용하듯이, RDS를 "빌려서" 사용한다.
옛날에 DVD방에서 빌려보는 거 생각하면 쉽다.

지원하는 DB 엔진

DB 엔진	설명	특징
MySQL	오픈소스 관계형 DB	가장 인기, 저렴
PostgreSQL	고급 기능 지원	복잡한 쿼리, JSON 지원
MariaDB	MySQL 호환	MySQL 대체재
Oracle	엔터프라이즈용	비싼 라이선스
SQL Server	Microsoft 엔진	Windows 통합
Aurora	AWS 자체 개발	성능 굿

RDS 기능

1. 자동 백업 (Automatic Backup)

RDS가 매일 자동으로:

• 매일 전체 백업 (Daily full backup)
• 매시간 증분 백업 (Transaction logs)
• 백업 보관 기간: 0~35일 설정 가능

사용자는 신경 쓸 필요 없음
"우리 국정자원 DB가 불이 났다?" → RDS에서 복구해줌!

2. 스냅샷 (Snapshot)

특정 시점의 DB 상태를 "사진처럼" 저장

언제 사용?

• 본격적인 작업 전 보험
• 개발/테스트용 복제 DB 만들 때
• 다른 리전으로 복제할 때
• 비용 절감을 위해 아카이빙할 때

스냅샷 → 새 RDS 생성 = DB 복제

3. Multi-AZ 배포 (고가용성)

하나의 RDS를 여러 가용영역(AZ)에 배치

구조:
Primary DB (AZ-a)
↕ (자동 동기화)
Standby DB (AZ-c)

장애 발생 시:

1. Primary가 다운됨
2. AWS가 자동으로 Standby로 전환
3. 데이터 손실 없음 (RPO = 0)
4. 다운타임 최소 (일반적으로 수십 초)

주의: Multi-AZ는 비용 발생하니깐 프리티어는 못해ㅠ

4. Read Replica (읽기 확장)

원본 RDS에서 "읽기 전용" 복제본을 만듦

목적:

• SELECT 쿼리를 복제본으로 분산
• 원본 DB 부하 감소
• 다른 리전으로도 복제 가능 (글로벌 읽기)

특징:

• 약간의 지연 가능 (동기화 딜레이)
• 쓰기는 원본에만
• 읽기 트래픽이 많을 때 효과적

구조:
Primary DB (쓰기)
↓ (레플리케이션)
Read Replica 1 (읽기 전용) - 쿼리 1000개/초
Read Replica 2 (읽기 전용) - 쿼리 1000개/초
Read Replica 3 (읽기 전용) - 쿼리 1000개/초
↓
총 쿼리 처리량 3배 증가됨

---

7.3 RDS 인스턴스 생성 & 관리

RDS 인스턴스 생성 절차

1. 엔진 선택

   • MySQL / PostgreSQL / MariaDB / Oracle / SQL Server / Aurora

2. 인스턴스 클래스 선택

• db.t3.micro (개발/테스트용, 저렴)
• db.t3.small (소규모 애플리케이션)

3. 스토리지 설정

• 스토리지 타입: gp2 / gp3
• 초기 할당 크기: 예) 20
• 오토스케일링: No(연습용으로 쓸거면 no로 하면 됨)

4. 네트워크 설정

• VPC 선택
• 서브넷 그룹
• 보안 그룹 (포트 3306/5432 등 허용)

5. 데이터베이스 설정

• DB 인스턴스 이름
• 마스터 사용자명
• 마스터 암호
• 초기 데이터베이스 이름

6. 백업 & 고가용성

• 백업 보관 기간: 7일 (권장)
• Multi-AZ 활성화: Yes (프로덕션)
• 자동 패치: Yes

7. 생성

• 약 5~10분 후 접속 가능

RDS 접속 방법

RDS 엔드포인트 (예):
mydb.c9akciq32.us-east-1.rds.amazonaws.com

MySQL Workbench (GUI 도구):

• 호스트: mydb.c9akciq32.us-east-1.rds.amazonaws.com
• 사용자: admin
• 암호: (설정한 암호)
• 포트: 3306

---

복습용으로 실습 한 번 해보자!

---

1. 개요

본 실습은 AWS Well-Architected Framework의 가용성, 확장성, 보안 향상을 기반을 갖춘 웹 애플리케이션 아키텍처를 설계합니다. 특히 가용성, 확장성, 보안 향상의 세 가지 핵심 요구사항에 집중하여 권장 모범 사례에 맞으며 요구사항을 수용하는 클라우드 아키텍처와 서비스 설계를 제시합니다.

---

2. 설계 구현 그림

---

3. 가용성 (Availability)

3.1 구현 이유

AWS Well-Architected Framework - Reliability Pillar에 따르면, 신뢰성 있는 아키텍처는 다중 가용 영역(Multi-AZ) 배포를 통해 단일 장애점(SPOF: Single Point of Failure)을 제거해야 합니다.[각주_1] [각주_3]

현재 단일 AZ 환경에서는 해당 AZ의 장애 발생 시 전체 서비스가 중단되므로, 비용 효율적이면서도 고가용성을 제공하는 다중 AZ 아키텍처가 필수입니다.

AWS ELB 모범 사례에 따르면, "Application Load Balancer는 최소 2개 이상의 Availability Zone으로 구성해야 하며, 각 AZ에 등록된 타겟이 있어야 효과적인 로드 밸런싱이 이루어집니다."[각주_9][각주_11]

3.2 리소스 및 구성

3.2.1 Application Load Balancer (ALB)

항목	설정값	설명
배포 위치	Public Subnet (Multi-AZ)	인터넷 사용자의 직접 접근 허용
Availability Zone	2개 이상	다중 AZ 고가용성 확보
리스닝 포트	80 (HTTP), 443 (HTTPS)	표준 웹 트래픽 포트
타겟 그룹	Private Subnet의 EC2 인스턴스들	보안성 강화
라우팅 알고리즘	RR + 상태 기반 라우팅	효율적인 트래픽 분산

ALB의 역할:

• 클라이언트로부터의 모든 웹 요청을 수신
• 헬스 체크를 통해 건강한 인스턴스로만 트래픽 라우팅
• 특정 AZ에 장애 발생 시 다른 AZ의 인스턴스로 자동 전환
• 결과: 다운타임 없는 서비스 연속성 제공

3.2.2 Multi-AZ VPC 구성

컴포넌트	AZ A	AZ B	목적
Public Subnet	10.0.1.0/24	10.0.3.0/24	ALB 배치 및 IGW 직접 접근
Private Subnet	10.0.2.0/24	10.0.4.0/24	EC2 인스턴스 격리 배치
NAT Gateway	AZ A의 Public	AZ B의 Public	Private Subnet의 외부 통신
Route Table	Public용, Private용	각각 별도 구성	트래픽 라우팅 관리

작동 원리:

1. 유저 요청
2. IGW(ALB_Public Subnet)
3. AZ A의 healthy 인스턴스 or AZ B의 healthy 인스턴스로 라우팅
4. 응답을 동일 경로로 반환

가용성 효과:

• AZ A 장애 시: ALB가 AZ B의 인스턴스로만 라우팅 → 서비스 계속 운영
• AZ B 장애 시: ALB가 AZ A의 인스턴스로만 라우팅 → 서비스 계속 운영
• 목표 가용성: 99.99% 달성

---

4. 확장성 (Scalability)

4.1 구현 이유

AWS EC2 Auto Scaling 모범 사례에 따르면, "EC2 Auto Scaling을 사용하여 수요 요청에 맞게 인스턴스 수를 자동으로 증감함으로써, 비용 최적화와 성능 유지를 동시에 달성할 수 있습니다."[각주_2][각주_5][각주_7] 트래픽이 예측 불가능한 환경에서 수동 확장은 느린 대응 시간(수십 분)으로 인해 사용자 경험 저하를 초래하므로, 자동 확장 메커니즘이 필수입니다.

4.2 리소스 및 구성

4.2.1 Auto Scaling Group (ASG) - EC2만 적용

파라미터	값	설명
최소 인스턴스 수	2개	항상 기본 부하 처리 가능
최대 인스턴스 수	10개	비용 관리 및 리소스 제약
원하는 용량	4개	평상시 운영 목표
인스턴스 타입	t3.micro (2vCPU, 4GB)	비용 효율적인 일반용 인스턴스
가용 영역	2개 이상 (Multi-AZ)	고가용성 확보

4.2.2 스케일 정책 (CPU 기반)

스케일 아웃 (Scale Out):

조건: 평균 CPU 사용률 > 70%(5분 이상 지속할 시)

1. 스케일링 정책 트리거
2. 새로운 인스턴스 시작 신호 전송
3. 시작 템플릿에 따라 인스턴스를 생성
4. 보안 그룹 적용
5. ALB 타겟 그룹에 등록
6. Health Check 시작
7. 정상 동작 확인 후 트래픽을 분산

스케일 인 (Scale In):

조건: 평균 CPU 사용률 < 30% (10분 이상 지속 시)

1. 스케일링 정책 트리거
2. Oldest 인스턴스 선택
3. Deregistration Delay(일정 시간동안 유저 요청에 대한 응답을 보장)
4. 인스턴스 종료
5. ALB 타겟 그룹에서 제거

4.2.3 트래픽 예상별 동작 예시

시간대	사용자 수	CPU 사용률	ASG 대응	인스턴스 수
00:00-06:00	낮음	~15%	정상	2개 (최소)
06:00-09:00	중간	~45%	정상	4개
09:00-17:00	높음	~75%	스케일 아웃	6-8개
17:00-20:00	매우 높음	~85%	스케일 아웃	8-10개 (최대)
20:00-00:00	중간	~50%	정상	4개

확장성의 이점:

• 트래픽 급증 시 자동 응답 → 사용자 경험 향상
• 저부하 시간 자동 축소 → 비용 절감 (30-40% 비용 감소)
• 수동 개입 불필요 → 운영 자동화

4.2.4 시작 템플릿 구성

)

---

5. 보안 향상 (Security)

5.1 구현 이유

AWS VPC 보안 모범 사례에 따르면, "ELB 뒷단의 웹/애플리케이션 인스턴스는 반드시 프라이빗 네트워크 환경으로 구성하여 인터넷 직접 노출을 방지해야 한다."[각주_4][각주_6][각주_8] 또한 계층별 보안 그룹을 구현하여 "최소 권한의 원칙(Principle of Least Privilege)"을 준수해야 한다.[각주_10]

단일 보안 그룹으로 모든 트래픽을 허용하는 구성은:

• 웹 인스턴스에 직접 SSH 접근 가능 → 무단 접근 위험
• 모든 포트 개방 → 공격 면적 확대
• 보안 감시 불가능 → 침입 탐지 어려움

5.2 리소스 및 구성

5.2.1 Multi-Tier 보안 그룹 (Security Groups)

1단계: ALB 보안 그룹 (ALB-SG)

방향	프로토콜	포트	소스/대상	용도
인바운드	TCP	80	0.0.0.0/0	HTTP 웹 트래픽
인바운드	TCP	443	0.0.0.0/0	HTTPS 암호화 트래픽
아웃바운드	TCP	80, 443	EC2-SG	EC2 인스턴스로의 트래픽

2단계: EC2 보안 그룹 (EC2-SG)

방향	프로토콜	포트	소스/대상	용도
인바운드	TCP	80	ALB-SG (보안그룹 ID)	ALB에서만의 HTTP 접근
인바운드	TCP	443	ALB-SG (보안그룹 ID)	ALB에서만의 HTTPS 접근
아웃바운드	TCP	443	0.0.0.0/0	외부 API 통신 (HTTPS)
아웃바운드	TCP	3306	RDS-SG	데이터베이스 접근

3단계: 보안 그룹 계층 다이어그램

단계	구성 요소	서브넷 유형	보안 그룹 / 접근 규칙	통신 포트
1	인터넷 사용자	Internet	모든 사용자	80, 443
2	ALB	Public Subnet	ALB-SG: 0.0.0.0/0 허용	80, 443
3	EC2 인스턴스	Private Subnet	EC2-SG: ALB-SG로부터만 허용	80, 443
4	RDS (Database)	Private Subnet	RDS-SG: EC2-SG로부터만 허용	3306
5	외부 API	Internet	EC2 → 외부 서비스 (NAT Gateway 경유)	443

5.2.2 Private Subnet 아키텍처

목표: EC2 인스턴스가 인터넷으로 직접 노출되지 않도록 격리

구성 요소	배치 위치	접근 방식
ALB	Public Subnet	IGW를 통해 인터넷 접근
EC2 인스턴스	Private Subnet	ALB를 통해서만 접근
NAT Gateway	Public Subnet	Private Subnet의 아웃바운드 제공
RDS Database	Private Subnet	EC2를 통해서만 접근

Private Subnet 사용 이유:

이점	설명
공격 면적 축소	직접 인터넷 노출 불가 → 스캔 및 무단 접근 차단
무단 접근 방지	특정 포트(22, 3389)에 직접 접근 불가
내부 통신만 가능	ALB를 거쳐서만 외부 요청 수신
감시 용이	모든 인바운드 트래픽이 ALB를 거치므로 로깅 가능

5.2.3 보안 모범 사례 체크리스트

1. 최소 권한 원칙

• 필요한 포트만 개방 (80, 443)
• 불필요한 포트 폐쇄 (22, 3306, 3389)
• Source CIDR을 최대한 좁게 설정

1. 계층별 격리

• ALB는 Public Subnet
• EC2는 Private Subnet
• 데이터베이스는 Private Subnet

1. 보안 그룹 연결

• EC2-SG: ALB-SG의 소스만 허용
• RDS-SG: EC2-SG의 소스만 허용

1. 아웃바운드 제한

• 필요한 외부 서비스만 허용 (예: HTTPS 443)
• 무제한 아웃바운드 정책 회피

---

6. 성능 지표 및 예상 효과

항목	기존 아키텍처	개선 후	예상 개선율
가용성	99.0%	99.99%	+0.99%
응답 시간	300-500ms	100-200ms	50-70% 단축
트래픽 급증 대응	수동 (30분~)	자동 (2-3분)	10배 빠름
비용 효율성	고정 비용	수요 기반	30-40% 절감
보안 위험	높음	낮음	공격 면적 90% 축소

---

7. 결론

AWS 모범 사례를 참고하여 제시한 아키텍처는 신뢰성, 보안, 성능 효율성 모두 충족함을 검증하였습니다.

핵심 개선 사항:

1. 가용성 - 다중 AZ ALB 배포로 99.99% 가용성 달성
2. 확장성 - EC2 Auto Scaling으로 자동 확장/축소 구현
3. 보안 - Private Subnet과 다계층 보안 그룹으로 무단 접근 차단

이 아키텍처를 통해 고가용성, 비용 효율성, 보안 향상을 동시에 확보할 수 있다.

---

참고 문헌

[각주_1] AWS Well-Architected Framework - Reliability Pillar, AWS Documentation

[각주_2] 10 AWS Auto Scaling Best Practices 2024, Coherence

[각주_3] AWS Well-Architected Framework: Reliability, Stream.Security

[각주_4] AWS VPC Subnet Design: Public & Private Configuration Guide, rajatim.com

[각주_5] Best Practices for AWS EC2 Auto Scaling Configuration, SitePoint

[각주_6] Security best practices for your VPC, Amazon Virtual Private Cloud Documentation

[각주_7] 10 Best Practices for Effective Auto-Scaling on AWS, Coherence

[각주_8] How to secure your AWS Application Load Balancer (ALB), learnaws.org

[각주_9] Infrastructure Protection - ELB Best Practices Checklist, AWS GitHub

[각주_10] Top 27 AWS Security Groups Best Practices, securekloud.com

[각주_11] How ELB works, Elastic Load Balancing Documentation

---

와.. 보고서 쓰는데 한 3일 걸린 듯....