[AWS][SAA] Classic Solutions Architecture

Ann Jongmin·2026년 5월 11일
Classic Solutions Architecture

AWS SAA

목록 보기
8/10

Udemy - Stephane Maarek AWS SAA 강의를 듣고 메모 목적으로 남김

1. 섹션 개요

지금까지 배운 AWS 핵심 서비스(EC2, ELB, ASG, RDS, ElastiCache, Route 53 등)들이 실제 환경에서 어떻게 결합하고 상호작용하는지 알아보는 종합 섹션입니다. 애플리케이션의 요구사항이 커짐에 따라 아키텍처를 점진적으로 발전시키는 과정을 다룹니다.

2. 상태 비저장 웹 앱 (Stateless Web App): WhatIsTheTime.com

  • 목표: 데이터베이스가 필요 없고, 단순히 현재 시간을 알려주는 서비스. 확장에 제약이 없어야 함.
  • 아키텍처 발전 과정:
    1. 단순 시작: 퍼블릭 EC2 인스턴스 1개에 탄력적 IP(Elastic IP)를 부여하여 서비스 시작.
    2. 수직 확장 (Scale Up): 트래픽 증가로 인스턴스 사양을 높임(예: t2.micro -> m5.large). 인스턴스 재시작이 필요해 다운타임(Downtime) 발생.
    3. 수평 확장 (Scale Out): 여러 대의 EC2를 두고 Route 53의 A 레코드(다중 IP)로 분산. (문제점: 특정 인스턴스 장애 시 DNS 캐시(TTL) 때문에 일부 사용자는 접속 실패).
    4. ELB 도입: 퍼블릭 IP를 없애고 프라이빗 EC2들 앞에 로드 밸런서(ELB) 배치. Route 53은 ELB의 Alias(별칭) 레코드를 가리킴. ELB 상태 확인(Health Check)으로 고가용성 확보.
    5. 오토 스케일링(ASG) 도입: 트래픽 증감에 따라 EC2가 자동 생성/삭제되도록 ASG를 ELB에 연결하여 진정한 수평 확장 구현.
    6. 다중 가용 영역 (Multi-AZ): 데이터 센터 재난에 대비해 ELB와 ASG를 최소 2개 이상의 AZ에 분산 배치.
    7. 비용 최적화: 항상 켜두어야 하는 최소한의 베이스라인 인스턴스는 예약 인스턴스(Reserved Instances)로 구매하여 비용 대폭 절감.

3. 상태 유지 웹 앱 (Stateful Web App): MyClothes.com

  • 목표: 사용자가 옷을 고르고 장바구니에 담는 쇼핑몰. 장바구니 내용(상태)이 유지되어야 함.
  • 아키텍처 발전 과정:
    1. 기본 Multi-AZ: ELB로 트래픽을 분산하면, 사용자가 매번 다른 EC2로 접속되어 로컬에 저장된 장바구니가 날아가는 문제 발생.
    2. 고정 세션 (Stickiness): ELB Sticky Session을 켜서 동일 사용자는 동일 EC2로 접속하게 함. (문제점: 해당 EC2가 죽으면 장바구니도 같이 날아감).
    3. 사용자 쿠키 (Web Cookies): 사용자 브라우저 쿠키에 장바구니 데이터를 저장해 서버를 무상태(Stateless)로 만듦. (문제점: 무거운 데이터 전송, 보안 위험, 4KB 용량 제한).
    4. 서버 세션 관리 (ElastiCache 도입): 브라우저 쿠키에는 가벼운 Session_ID만 담고, 실제 장바구니 데이터는 Amazon ElastiCache(또는 DynamoDB)에 저장. 빠르고 안전하며 완벽한 상태 유지 아키텍처 완성.
    5. 데이터 저장 (RDS): 회원가입, 결제 내역 등 영구적인 데이터는 RDS에 저장.
    6. 읽기 성능 확장: DB 읽기 트래픽 부하는 RDS 읽기 전용 복제본(Read Replicas)이나 ElastiCache를 활용한 지연 로딩(Lazy Loading)으로 해결.
    7. 재해 복구 (Multi-AZ): RDS와 ElastiCache 모두에 다중 AZ(Multi-AZ) 옵션을 켜서 고가용성 확보.
  • 보안 그룹 (Security Group) 설계 원칙:
    • ELB: 인터넷(0.0.0.0/0)의 HTTP/HTTPS 트래픽 허용.
    • EC2: 오직 ELB의 보안 그룹에서 오는 트래픽만 허용.
    • RDS/ElastiCache: 오직 EC2의 보안 그룹에서 오는 트래픽만 허용하여 백엔드 철벽 보안.

4. 복잡한 상태 유지 앱 (Stateful Web App): MyWordPress.com

  • 목표: 이미지 업로드가 가능한 확장형 워드프레스 블로그.
  • 아키텍처 발전 과정:
    1. DB 계층: 워드프레스 데이터를 저장할 RDS MySQL 구성. 대규모 확장을 위해 Aurora MySQL (Multi-AZ + Read Replicas) 로 업그레이드.
    2. 이미지 저장소 문제 (EBS): EC2에 연결된 EBS 볼륨에 이미지를 저장하면, 다른 AZ의 EC2 인스턴스들은 그 이미지를 볼 수 없음 (EBS는 단일 인스턴스에만 연결됨).
    3. 이미지 저장소 해결 (EFS 활용): 여러 AZ의 수많은 EC2가 동시에 마운트할 수 있는 공유 네트워크 파일 시스템인 Amazon EFS를 사용하여 분산 이미지 스토리지 문제를 완벽히 해결.

5. 애플리케이션 빠른 인스턴스화 (Instantiating Applications Quickly)

ASG 등으로 새 인스턴스가 켜질 때 애플리케이션 설치 및 로딩 시간을 획기적으로 줄이는 전략.

  • EC2 인스턴스:
    • Golden AMI: OS 세팅과 애플리케이션 설치가 완벽히 끝난 이미지를 미리 만들어 두고 부팅 (부팅 속도 가장 빠름).
    • User Data (부트스트랩): 기본 이미지로 시작하여 스크립트로 최신 코드를 다운받고 설정함.
    • 하이브리드 (권장): 변하지 않는 무거운 소프트웨어는 Golden AMI로, 자주 변하는 동적 설정/코드는 User Data로 처리.
  • RDS 데이터베이스:
    • 빈 DB를 띄우고 스크립트로 밀어 넣는 대신, 미리 찍어둔 RDS 스냅샷을 복원(Restore)하여 데이터가 완비된 상태로 투입.
  • EBS 볼륨:
    • 디스크 포맷 및 복사 과정을 생략하고, EBS 스냅샷을 복원하여 데이터가 들어있는 드라이브를 즉시 부착.

6. AWS Elastic Beanstalk 개요

  • 개념: 인프라(EC2, ASG, ELB, RDS 등)를 하나씩 구축할 필요 없이 코드만 업로드하면 자동으로 환경을 구성해 주는 완전 관리형 PaaS(Platform as a Service).
  • 특징:
    • 구축은 자동화되지만, 개발자가 인프라 제어 권한을 그대로 유지함.
    • 서비스 자체는 무료이며 프로비저닝된 AWS 리소스에 대해서만 비용 지불.
    • Java, .NET, Node.js, PHP, Python, Docker 등 다양한 언어와 플랫폼 지원.
  • 환경 티어 (Tiers):
    • Web Server Tier: ELB와 ASG를 통해 사용자의 웹(HTTP) 요청을 직접 처리.
    • Worker Tier: SQS(메시지 큐)에서 작업을 꺼내 백그라운드에서 비동기적으로 처리 (웹 서버 티어가 SQS로 작업을 보내는 패턴).
  • 배포 모드:
    • Single Instance: 개발/테스트용. 로드 밸런서 없이 1개의 EC2와 탄력적 IP로 구성.
    • High Availability with LB: 프로덕션(운영)용. ALB, ASG, Multi-AZ 등을 완벽히 갖춘 구성.
profile
Ann Jongmin
AI Study
이전 포스트

[AWS][SAA] Route 53

다음 포스트

[AWS][SAA] S3

0개의 댓글