과정명 : AWS Solutions Architect - Designing a Three-Tier Web Architecture
개념 증명(POC, Proof of Concept)
- 실제 제품 출시 전에 정상 작동 여부를 작은 규모로 테스트해보는 것.
- 위를 확장하여 AS + LB 서비스를 추가하면 실제 배포 가능한 아키텍처가 되는 거임
고객 요구 사항 수집
- 아키텍처 설계는 기술이나 솔루션 소개로 시작하는 것이 아니라, 고객의 요구사항 파악이 먼저임!
1. 궁극적인 사업 목표 파악 (ex: 출시 일정, 예산 등)
2. 운영,기술,보안 요구사항 (ex: 예상 동시 사용자, 개발/테스트 환경 분리, 자격 증명 관리방식 등)
3. 향후 확장성에 대한 논의 (ex: 추가 기능, 신규 리전 진출 여부 등)
(1) 네트워크 요구사항
VPC 및 서브넷
- IPv4 와 IPv6 트래픽은 각각의 전용 IGW를 통해 라우팅되어 별도로 취급됨
- 이때 IPv4의 경우 서브넷 내 5개 IP는 예약 되어있으므로, 사용가능한 IP 수에서 제외해야 함.
- 인터넷에 대한 인바운드 또는 아웃바운드 액세스가 필요한 워크로드의 경우 -> 퍼블릭 서브넷을 활용
💡 Q. 이미 할당한 기존 VPC CIDR 블록을 수정하려면 어떻게 해야하나요?
과거에 다른 강의에서 수정이 불가능하다고 설계 시 신중해야한다 했었는데,
아예 방법이 없는게 아님. Skill Builder에서는 2가지 옵션을 제시해줌
1. VPC에 세컨더리 CIDR 블록을 추가하여 연결 (5개까지 추가가능함)
2. 더 큰 CIDR 블록을 새로 만들고 -> 기존 VPC를 마이그레이션 후 제거하는 방법
💡 Q. /16과 같은 큰 CIDR 블록 할당하지 않는 이유는 뭔가요?
-> 많은 IP 주소를 낭비하게 돼서 그럼. 이후 관리도 어렵다!
-> 요구사항에 따라 적절하게가 중요!
-> 그렇다고 너무 작은 크기보다 큰 크기의 서브넷(/24 이상) 사용 추천
🤔 "서브넷은 VPC CIDR 블록의 하위 집합" -> 뭔가 이해가 어려움..
그냥 서브넷 = IP주소의 범위라고만 이해하고 있어서 위의 말이 와닿지 않았음.
쉽게 이해하자면,
VPC CIDR 블록 = 큰 상자
서브넷 = 그 상자 안에 나눈 작은 칸
"하위 집합"이란, VPC의 전체 IP 범위 안에서
서브넷이 그 일부만 사용한다는 뜻
🍯 Tip) 서브넷을 바라보는 관점
- 서브넷은 애플리케이션 주변의 격리 경계로 바라보기 보다,
- 라우팅 정책을 위한 컨테이너로 바라보자.
NAT
VPC CIDR 블록은 그 자체만으로는 인터넷에 대한 직접 엑세스 지원 x
-> IGW, 가상 프라이빗 GW, AWS Site-to-Site VPN, AWS Direct Connect 등을 이용해야함
IGW
: 퍼블릭IP와 프리이빗IP를 매핑하는 NAT를 수행.
NAT
: Network Address Translation
처리량(Throughput)을 고려한 설계 시 NAT의 성능에도 집중할 필요가 있다.
-> NAT는 5Gbps 지원, 자동으로 최대 100Gbs까지 스케일업.
- 이때, 더 많은 대역폭 필요시 리소스를 여러 서브넷 분할 후 -> 각 서브넷에 NAT생성
보안그룹 및 네트워크 ACL
보안그룹
: 리소스에 대해 특정 인바운드 또는 아웃바운드 트래픽 허용/거부
: Stateful
- 인바운드로 허용된 요청의 응답은 아웃바운드 규칙 없이도 나갈 수 있음
네트워크 ACL
: Network Access Control List
: 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽 허용/거부
: StateLess
네트워크 ACL 및 SG 배치
- 네트워크ACL 및 보안그룹을 통한 다중 방어 계층으로 인프라를 보호하는 것
- 느낀점
- 사실 이제는 당연한 베스트 프랙티스지만 이 자체로 훌륭한 보안구성이구나를 새삼 깨달음.
(2) 컴퓨팅 요구사항
AWS 컴퓨팅의 진화
2006 - EC2를 이용한 가상화를 시작으로
2014 - ECS를 이용한 컨테이너화 (OS만 가상화해서 1앱 1OS로 가볍게)
2014 - Lambda로 서버리스
2017 - Fargate로 서버리스 + 컨테이너 결합
2020 - 이떄부터 꾸준히 AI를 위한 고성능 칩 출시
2023 - EKS Auto Mode로 컨테이너 오케스트레이션 관리 자체를 AWS가 맡음.
과거 "서버 사야 했던 시대" → "VM 빌리는 시대" → "컨테이너로 묶는 시대" 가 되었고,
클라우드를 통해 "코드만 올리는 시대" → "인프라 관리 자체를 AWS에 위임하는 시대"가 됨.
특히 2020년 이후는 컴퓨팅의 패러다임 자체가
범용 서버 → AI 특화 HW로 이동하는 게 핵심.
Graviton은 비용 효율, Trainium/Inferentia는 AI 학습/추론 전용으로 역할이 나뉨
"어떤 워크로드에 어떤 인스턴스를 쓸 것인가"가
현재 아키텍처 설계의 중요한 판단 포인트가 됨 !
컴퓨팅 옵션
3가지 기본 컴퓨팅 패러다임
(1) Amazon EC2
- 특정 OS를 사용해야하는 레거시 애플리케이션
- 일정하고 예측가능한 워크플로 애플리케이션에 적합
- 특수한 HW가 필요한 워크로드 (GPU가 필요하거나 등)
(2) 컨테이너
- 마이크로서비스 아키텍처를 구축하는 경우(다양한 구성요소 독립적으로 개발 및 배포, 규모조정)
- 기존 EC2 인스턴스보다 빠르게 규모 조정해야하는 애플리케이션 쓰는 경우
- 하이브리드 클라우드 배포 시 (워크로드 이식성 보장)
- 이식성 = 어디서든 똑같이 실행되는 능력
- 이때, ECR(Elastic Container Registry)에 올려두고 어디서든 pull해서 바로 실행으로 구현할 수 있다.
(3) 서버리스
- 코드만 업로드하면 배포 스케일링 및 관리는 AWS에서 자동으로 처리
- 관련 : AWS Lambda, Fargate, Step Functions 등
- 트래픽이 발생하지 않는 기간 동안 워크로드가 계속 바뀌거나 워크로드 예측 불가능 경우
- 파일 업로드, DB 변경, API 요청 같은 이벤트 기반 처리할때
- 예약된 작업 같은 단기 실행 프로세스 수행하는 경우
EC2 사용 시 고려사항
1. 태그 : 리소스 필터링을 통해 관리 및 비용 추적 자동화 가능
2. 애플리케이션 및 OS 이미지 : 기술 요구사항에 따라서
3. 인스턴스 유형 및 크기 : 기술 요구사항에따라서
4. 키 페어 : 다른 구성요소와 연결하는 방법과 액세스 인증 방식 어떻게 할지
5. 네트워크 및 보안 : 사용할 VPC, 서브넷, SG가 뭔지
6. 스토리지 구성 : 사용사례에 가장 적합한 블록스토리지는 뭔지
7. 배치 및 테넌시 : EC2를 어느범위로 어디서 어떻게 실행할지. (뒤에서 자세하게 다룸)
8. 스크립트 및 메타데이터 : 인스턴스 시작 시 자동화 어떻게 할지
인스턴스 유형 이름 이해
- 400가지가 넘음, 첫글자는 인스턴스 패밀리 : 뭔가 용도를 뜻함
- 그다음 세대, 추가속성, 크기 순
범용 : 컴퓨팅,메모리,네트워킹 리소스가 적절한 비율, 다양한 워크로드에 사용, 웹 애플리케이션
컴퓨팅 최적화 : 고성능, 프로세서, 과학 모델링 또는 기계 학습 등
메모리 최적화 : DB서버, 웹 캐시 등
가속 컴퓨팅 : GPU 기반, 대량의 그래픽 처리 및 기계학습 등
스토리지 최적화 : 대규모 데이터세트, NoSQL DB 등
AWS Compute Optimizer(← 이거 신기하다 🤩)
: CloudWatch에서 제공되는 사용 데이터와 리소스 현재 구성 분석 후
결과에 따라 권장 컴퓨팅 제공 -> 비용 및 성능 개선
이때 결과를 S3에 저장하고 Cost Explorer로 예상 비용을 볼 수 있음
이후 System Manager 연동을 통해 수동/자동으로 서버 스케일 업/다운가능.
근데 스케일 업/다운은 인스턴스를 멈추고 타입바꾸는 거라 중단 발생 -> 점검시간 같은거 필요
실무에서 오토스케일링이라 하면 스케일 업/다운이 아닌 스케일 인/아웃을 말하는 이유가 바로 이거구나 !!
-> 결국 오토스케일링의 핵심은 서비스 중단이 일어나느냐가 기준이구나 인사이트 얻음!
테넌시
: 물리 자원을 공유해서 사용하는 개념
: EC2 인스턴스는 기본적으로 테넌시를 공유함
(1) 공유 테넌시 : 같은 물리 서버 하나를 여러 AWS 계정에서 나눠씀 (default)
(2) 전용 인스턴스 : 서버 하나를 나 혼자 씀. (근데 어떤 서버인지는 AWS가 지정해줌)
(3) 전용 호스트 : 물리 서버 자체를 통째로 할당받음 (그 위에서 내가 직접 관리)
배치 그룹 및 사용 사례 ⭐️
AWS는 기본적으로 EC2 인스턴스들을 물리 서버 전체에 분산시킴 (방금 다룬 공유테넌시 느낌)
-> 한 서버 죽어도 다른 인스턴스 살게 하려고.
이때 배치그룹이 필요한 이유?
-> 위의 분산이 워크로드에 따라 오히려 문제 될 수도 있어서.
ex: 빅데이터 분석 작업
: 노드10대가 서로 물리적으로 떨어져있으면 Latency 발생, 성능저하
결국 인스턴스들을 어떻게 배치할지 결정하는게 -> 배치그룹
(1) 클러스터 배치 그룹(Cluster)
- 물리 서버 랙 1개안에 몰아넣기, 서로 물리적으로 가까움 -> 초저지연, 고대역폭 Network
- 사용사례 : HPC(고성능컴퓨팅), 머신러닝, 빅데이터
- 근데 단점도 있음 ! 랙 하나에 몰려있는 구조다보니, 성능을 취하고 가용성을 포기.
(2) 분산형 배치 그룹(Spread)
- 한 놈도 같이 안둠
- 물리 서버 각각에 하나씩 최대한 분리 -> 가용성
(3) 파티션 배치 그룹(Partition)
- 파티션(묶음)단위로 분리,
- 랙A에 EC2 10대, B에 10대, ...
- Hadoop, Kafka 같은 대규모 분산 시스템
EC2 요금 옵션
- (1) On-Demand : pay-as-you-go, 약정없이 사용한만큼 지불
- (2) Saving Plans : 1년, 3년 같은 약정을 통한 비용 절감
- (3) Spot Instanaces
- AWS DC의 남는 EC2 서버 용량을 사용, 온디맨드 대비 90퍼까지 절감가능
- 여뷰분이 없어진다면 2분 전에 알림을 주고 워크로드 실행 중단됨, 언제 꺼질지 모름.
스팟 인스턴스 사용 예시- 중단되어도 괜찮은 것들
(1) 이미지 및 미디어 렌더링
- Spot 100대로 병렬 처리 → 중간에 몇 대 꺼져도 ㄱㅊ
(2) 빅데이터/ML
- Haddop, Spark 분석 작업은 체크포인트 기능이 있음
- Spot 꺼져도 마지막 체크포인트부터 다시 시작.
(3) 일부 웹 서비스
- 여러 스팟 인스턴스를 로드밸런서를 통해 배포, 대규모 트래픽을 저비용으로.
- 그래도 spot만 쓰면 위험함. 온디맨드 + 스팟 구조로 써야 안전
(3) 스토리지 요구사항
스토리지 유형
(1) 객체 스토리지
- 고유한 식별자 및 메타데이터 사용하여 데이터를 객체로 관리 - AWS S3
(2) 블록 스토리지
- 데이터를 고정된 크기의 블록으로 분할 - AWS EBS
- 짧은 시간 내 엑세스 해야하는 부팅볼륨, OS, DB 등
(3) 파일 스토리지
- 여러 시스템 간 공유 액세스 - AWS EFS, FSx
(4) 데이터베이스 스토리지
- 특정 데이터 모델 및 액세스 패턴용으로 최적화됨 - AWS RDS, DynamoDB, DocumentDB 등
- 복잡한 관계가 적용되는 정형 데이터, ACID 트랙잭션 수행시 적합.
EC2 인스턴스 스토어 ⭐️
- EC2 == 호스트 PC 한대가 아님.
- 호스트 PC하나에 여러 EC2 인스턴스가 연결되는 구조
- 인스턴스 스토어는 이 호스트 PC에 "물리적"으로 연결된 디스크
- 인스턴스 스토어는 임시 스토리지를 제공, 연결된 인스턴스의 수명 기간동안에만 유지되고,
- 해당 인스턴스를 중지하거나 절전모드로 전환하거나 종료시 인스턴스 스토어 볼륨의 모든 데이터 손실됨
EBS
- EC2를 위해 안정적이고 분리 가능한 블록 스토리지
- 쉽게 말하면 EC2에 붙이는 외장 HDD, SSD 느낌
- 인스턴스에 탑대되므로 매우 짧은 레이턴시
- 스냅샷을 생성하여 S3에보관가능, 추후 새 EC2 인스턴스 생성 시 재사용 가능.
💡 EC2와 스토리지를 활용 예시들 3가지
(1) EC2 안에 MySQL 직접 설치 (AWS 처음쓸때 이랬었음ㅋㅋ)
- EC2에 Spring Boot 앱
- EC2에 MySQL (직접 설치)
*데이터 저장은? → EC2 로컬 디스크 (인스턴스 스토어)
(2) EC2 + EBS
- EC2에 Spring Boot 앱
- EC2에 MySQL (직접 설치)
*데이터 저장은? → EBS 볼륨 (외장 디스크)
(3) RDS
- EC2에 Spring Boot 앱
- RDS로 MySQL (AWS가 관리)
*데이터 저장은? → AWS가 알아서
💭 AWS 처음 쓸때 EC2에 MySQL을 올려서 썼던 경험이 떠오른다
안그래도 성능 낮은 프리티어 EC2 안에서
DB마저 CPU 및 메모리를 할당받으니 부하가 심했던 기억이있음.
(EC2 파워를 올리려다가 가격보고 돌아섰었던..)
그때 이렇게 할걸...
RDS 프리티어는 또 별개니까 그거 쓸걸.
이제야 보이는 RDS의 장점들:
- 패치, 백업을 자동, Multi-AZ도 직접 복잡하게x -> 쉽게가능,
- 클릭 한 번으로 Read Replica 생성, 쉬운 모니터링 연동(CloudWatch)
관계형 및 비관계형
- 관계형은 데이터 항목 간 사전 정의된 관계가 있을때 그 데이터의 모음.
- 비관계형(NoSQL) DB는 현대적 애플리케이션에 적합한 스키마.
- 가용성과 확장성이 뛰어남
💡 NoSQL 잘몰라서공부해봄
{
"user": "대형",
"orders": [
{"item": "노트북", "price": 100},
{"item": "마우스", "price": 20}
]
}- JSON 덩어리들 그냥 쌓아둔 느낌, 구조가일정하지않고, 한 데이터안에 구조가 중첩됨
- 근데 JSON 형태만있는거 아니고 graph형, key-value형 등 총4개가 있음.
- 관계형DB에서 관계를 JOIN으로 표현한다면, 비관계형DB는 중첩으로 표현함
- ex: MongoDB, Redis, DynamoDB
RDS
- 관계형 DB를 손쉽게 설정 및 작동하고, 규모 조정할 수 있는 관리형 서비스
- DB를 관리할때는 열/행 및 쿼리도 고려해야하지만, 운영이나 규모 조정 등 기타측면도 고려해야함
- RDS는 DB 규모를 조정할 수 있음.
- 자동으로 DB SW를 패치하고, DB를 백업도 가능.
다중 AZ 배포
읽기 전용 복제본 (Read Replica) ⭐️
- 읽기 복제본 생성 -> 프라이머리 DB 인스턴스와 동기화.
- 추가 읽기 용량으로 프라이머리 노드에 대한 부하 해소
- 여러 AWS 리전에서 데이터를 애플리케이션에 더 가까이 배치 가능
- 프라이머리 DB 인스턴스 장애 발생 시 DR 솔루션으로 이 read replica를 프라이머리 인스턴스로 승격
저장 시 데이터 암호화
- AWS KMS를 통해 저장 데이터 암호화를 제공함.
- 암호화 키를 생성 및 관리하여 데이터를 암호화 및 복호화
- 기본 스토리지에 대한 액세스 보호하는 계층 제공
Amazon RDS 설계 고려사항
(1) 엔진 선택
- 상업용 (MS, Oracle) or 오픈소스(PostgreSQL, MySQL, MariaDB)
- 상업용은 라이선스 포함형과 기존 보유 라이선스 사용하는 2가지가 잇음.
- EC2는 셀프 매니지드 인스턴스임. 직접 서비스 가동 중단하고 패치해야함.
- 반면 RDS는 관리형 데이터베이스 인스턴스
- 롤백이나 애플리케이션 환경 수정시 가동 중단 필요없는게 AWS RDS의 장점
(2) DB 인스턴스 클래스 선택
- 범용(Standard)
- 메모리 최적화(Memory Optimized) : 메모리 집약적
- 순간 확장 가능(Burstable) : CPU 사용량을 순간적으로 확장가능
(3) DB 인스턴스 스토리지 선택
- 범용 : 광범위한 워크로드
- 프로비저닝된 IOPS : I/O 집약적 네트워크
- 마그네틱 : 하위호환(HDD)를 위함
확인문제 : 요구사항에 맞는 DB 인스턴스 클래스 및 스토리지 선택
- 컴퓨팅 메모리와 네트워킹 리소스의 균형을 유지해야하며, IOPS 요구사항은 3000정도
- 범용인스턴스로 균형있는, 메모리나 CPU 성능은 크게 중요하지않음.
- 3000 IOPS 정도는 범용 스토리지로 충분
- 메모리 집약적 애플리케이션이며, 해당 워크로드의 I/O 성능이 일정하게 유지되어야 함.
- 메모리 최적화 인스턴스 및 프로비저닝된 IOPS 스토리지를 사용 !