[AWS] VPC구성에서 서버구축까지

Things I was curious about

[AWS] VPC구성에서 서버구축까지

갈릭 deep잉 소스좋아 2024. 3. 22. 22:51

내가 잠시 몸담았던 회사에서 프로젝트를 진행할 때, 아키텍처를 설계하는데에 있어서 AWS 인프라 기초 지식이 부족하여 벽을 느꼈던 적이 있다.
"반드시 AWS 인프라는 공부를 해야겠다"라는 결심 하나 가지고 AWS 공식 문서와 여러 블로그 글들, 그리고 어느 구인구직 플랫폼에서 진행했던 프리온보딩 챌린지 중에 'AWS 시스템 아키텍처 설계'를 들으면서 내 나름대로 정리한 내용을 포스팅하려고 한다.

1.Global Infrastructure & Networking

VPC : 사용자가 정의한, 논리적으로 격리된 가상의 프라이빗 네트워크 환경
- CIDR블록으로 VPC크기를 지정하여 생성(/16~/28)
- 각 리전별 default VPC가 제공
- VPC를 생성하면 default로 라우팅 테이블이 생성됨.
- 이 기본 라우팅 테이블은 VPC대역 내의 IP 주소끼리의 연결을 도와줌.
- VPC대역 외의 IP 주소와 연결을 원할 경우 서브넷 라우팅 테이블을 만들어 게이트웨이를 통해 외부와 연결을 하면 됨.
인스턴스 : CPU, 메모리, 디스크, 네트워크 등을 할당받은 가상화된 컴퓨터 환경.
- 사용자는 인스턴스 위에 프로그램을 올려놓고 실행시킨다.
서브넷 : 서비스 용도에 따라 분리해 놓은 공간(== 여러 개의 가용영역)
NAT 게이트웨이 : VPC 내부의 private 서브넷에서 인터넷을 통해 외부 리소스와 통신할 수 있도록 지원하는 서비스. private 서브넷의 인스턴스가 인터넷에 연결될 수 있도록 private IP를 public IP로 변경한다.
Network Access Control List(NACL) : 인바운드(Inbound) & 아웃바운드(Outbound) 트래픽을 제어하는 보안 규칙을 정의하는 데 사용되는 네트워크 수준의 방화벽입니다. 서브넷 단위 방화벽. stateless이므로 이전 패킷과의 연관성이 없음. 인바운드에서 허락된 트래픽의 응답도 아웃바운드 규칙 내 명시적으로 allow가 있어야만 리턴.
보안 그룹 : 보안 그룹은 인스턴스에 대한 인바운드(Inbound) 및 아웃바운드(Outbound) 트래픽을 제어하는 데 사용되는 인스턴스 단위의 방화벽. 상태 저장(stateful)이므로 이전에 세션을 허용한 트래픽에 대해서는 응답을 항상 허용함

NAT 게이트웨이를 통해 프라이빗 서브넷 IP를 퍼블릭 IP로 변경
→ 로드 밸런서를 거치고 인터넷 게이트웨이를 통해 VPC대역 외의 외부 인터넷과 연결을 시도함.

Load Balancer

: 인바운트 트래픽을 분산시켜서 인스턴스에 할당하는 역할을 함. 각 인스턴스에게 작업 부하를 덜어주며 가용성을 늘려줌. 또한, 외부 IP 주소로의 연결시에도 인터넷 게이트웨이를 거치기 전에 로드 밸런서를 거쳐야함.

2. Computing(EC2)

EC2(Elastic Compute Cloud) : 가상화된 컴퓨팅 리소스를 제공하여 사용자가 필요에 따라 가상 서버(인스턴스)를 프로비저닝하고 실행할 수 있게 해줌.
- 다양한 운영체제와 소프트웨어 실행 가능.
- EC2 인스턴스를 생성하여 필요한 용도에 맞게 설정하고, 인스턴스에 애플리케이션을 설치하여 사용할 수 있게함.
AMI(Amazon Machine Image) : EC2 인스턴스를 시작하기 위한 템플릿.
- 사전 구성된 운영 체제와 소프트웨어 설정, 애플리케이션 및 데이터까지 포함할 수 있음.

EC2 : 가상화된 컴퓨팅 리소스를 제공하는 서비스
EC2 인스턴스 : 가상 서버로서 실행되는 VM
AMI : EC2 인스턴스를 시작하기 위한 템플릿으로, 운영 체제, 소프트웨어 설정 및 애플리케이션을 포함한 이미지

EC2 인스턴스 스토어 : EC2 인스턴스에 직접 연결된 임시 블록 스토리지
- EC2 인스턴스를 만들면 자동으로 생성됨.
- AWS의 데이터 센터의 하드웨어로 제공되는 물리적인 데이터 저장공간으로 구성.
- 스냅샷을 지원하지 않으므로 데이터의 백업과 복제가 불가.
- 임시 스토리지이므로 EC2인스턴스가 실행중일 때만 사용가능하다.
  - 일시적인 데이터나 캐시 데이터에 적합.
- EC2 인스턴스를 중지하거나 종료하면 데이터는 손실됨.
EBS(Elastic Block Store) : 지속적으로 데이터를 저장할 수 있는 네트워크 기반의 블록 스토리지
- 데이터의 지속성
- EC2 인스턴스에 마운트되어 사용
- 인스턴스가 종료되어도 데이터는 영구적으로 보존
- EBS 스냅샷을 통해 데이터의 백업 및 복제, 볼륨의 확장 등 다양한 데이터 관리 기능을 제공
- 다른 인스턴스에 연결하여 데이터에 접근할 수 있음.
- 인스턴스와 직접적으로 연결되어 있지 않고 네트워크를 통해 연결되는 독립적인 데이터 저장 공간.

EC2 Auto Scaling : 서비스 오픈 후 트래픽이 몰리는 것을 동적으로 변화시켜 대응하는 것
- 비정상 인스턴스 교체(fleet management)
- 수요에 맞게 확장(dynamic scailing)

※ EC2 인스턴스 생성 → AMI생성 → 기존의 EC2 인스턴스 삭제 → 추후 커스텀 AMI를 이용하여 새 EC2인스턴스 생성(아래 사진)

※ 커스텀 AMI를 이용하여 새로운 EC2 인스턴스를 생성하고 auto scaling을 적용했을 때의 아키텍쳐

3. Storage

블록 스토리지 :
- 데이터를 일정한 크기의 블록으로 나누고, 이러한 블록 단위로 데이터를 읽고 쓸 수 있음.
- 가상메모리의 페이징 기법과 매우 유사.
- 데이터베이스, 파일 시스템, 애플리케이션의 데이터 저장 등에 사용
파일 스토리지 :
- 공유 파일 시스템을 제공하여 여러 인스턴스가 동시에 파일을 읽고 쓸 수 있게 함.
- 공유 파일 시스템이 필요한 애플리케이션, 대규모 데이터 공유, 데이터 백업 등에 사용.
- 블록 스토리지의 기능을 기반으로 하여 공유 파일 시스템을 구현하는 역할을 수행
- EFS가 이에 해당.

파일 스토리지는 블록 스토리지의 개념을 포함.
파일 스토리지는 블록 스토리지의 기능을 기반으로 하여 공유 파일 시스템을 구현하는 역할을 수행한다. 블록 스토리지는 주로 파일 시스템의 데이터 저장을 위해 사용되며, 파일 스토리지는 블록 스토리지에 저장된 파일 시스템의 데이터를 공유하고 관리하는 역할을 수행

오브젝트 스토리지 :
- RESTful API 호출을 통해 접근하는 데이터들의 저장공간
- 웹 애플리케이션의 정적 자원, 미디어 파일, 백업 데이터, 로그 파일 등을 저장하는 데 사용
- S3의 REST API를 통해 사용자는 버킷(Bucket)이라고 불리는 데이터 컨테이너에 객체(Object)를 업로드하고 다운로드함.
- 일반적인 HTTP 메소드 (GET, PUT, POST, DELETE 등)를 사용하여 데이터를 조작

EFS(Elastic File System) : 서버리스 방식의 완전 탄력적인 파일 스토리지

AWS Backup 동작 방식

4. Database

Amazon RDS : 6가지 DB엔진을 갖춘 관계형 데이터베이스
- Amazon RDS의 장점

Amazon Aurora : MySQL 및 PostgreSQL과 호환되는 클라우드용으로 구축된 관계형 DB
- 로그 기반의 분산형 스토리지
- Shared Storage Volume을 통해 3개의 가용영역에 수백 개 이상의 storage node로 스트라이핑
- 더보기
  Shared Storage Volume
  : Amazon Aurora 클러스터의 모든 인스턴스 간에 데이터를 공유하기 위해 사용되는 공유 스토리지
  1. 공유 스토리지 및 중앙 집중식 스토리지형태로 모든 인스턴스 간에 데이터의 일관성과 동기화를 보장하고 데이터베이스 파일이 Shared Storage Volume에 저장된다. 또한, 각 인스턴스는 이 스토리지를 통해 데이터에 접근한다.
  2. Shared Storage Volume은 다중 가용 영역(Multi-AZ)에 걸쳐 복제되어 높은 가용성과 내구성을 제공 → 장애가 발생해도 데이터의 손실이나 가용성 문제가 발생하지 않는다.
  3. 분산 스토리지 시스템을 사용하여 높은 처리량과 낮은 지연 시간을 제공
  4. Aurora 클러스터의 작업량이 증가할 때 자동으로 확장 → 읽기 및 쓰기 작업의 처리량을 향상시키고, 성능 요구 사항에 대응 가능.

AWS SCT(Schema Conversion Tool)
- 기존 데이터베이스의 스키마 및 코드를 다른 종류의 데이터베이스 스키마 및 코드로 변환
  - NoSQL 데이터베이스 변환
  - Application Code 내의 SQL을 변환

AWS DMS(Database Migration Service)
- 같은 종류, 다른 종류의 데이터베이스 migration을 지원
- 소스 DB의 변동 사항을 지속적으로 복제
- 여러 개의 소스 DB를 하나의 타겟 DB로 통합.

AWS SCT를 사용하여 schema를 변경 → AWS DMS를 사용하여 migration

AWS Database Service

5. Flow

1. VPC 생성

가용영역 설정.
인터넷과 직접적으로 통신할 퍼플릭 서브넷의 CIDR 설정.
외부 서비스에서 인스턴스와의 직접적인 연결을 시도할 수 없도록 NAT게이트웨이 설정.

2. AMI 생성을 위한 임시 인스턴스 생성

이름, 운영체제, 인스턴스 타입 등등 설정.
EC2가 위치할 공간을 설정.
이전에 생성한 VPC를 선택하고 서브넷은 퍼블릭 서브넷을 설정.
앞으로 생성될 EC2에 적용되는 보안 규칙을 설정.
이후 생성된 인스턴스를 통해 이미지 생성.
생성된 AMI가 사용가능한 상태가 되면 임시 인스턴스를 삭제

3. Application Load Balancer(ALB) 구성 및 Auto Scaling Group(ASG) 구성

이전에 생성한 VPC에서의 사용할 가용영역 선택 → 퍼블릭 서브넷으로 지정.
ALB의 보안그룹을 생성.
생성할 ALB의 보안그룹으로 이전 단계에서 생성한 ALB 보안그룹 선택.(디폴트 값은 삭제)
ALB가 타겟팅할 그룹을 선택 → 타겟 타입과 타겟 그룹의 이름, VPC를 설정해서 생성.
이전 단계에서 생성한 타겟 그룹을 ALB의 타겟팅 그룹으로 설정.
ALB를 만들었으니 로드밸런스 뒤에 인스턴스들을 배치해야함.
앞으로 생성될 인스턴스의 생성을 간편화 하기 위해 시작 템플릿 생성.
ALB뒷단에 배치될 EC2 인스턴스의 보안그룹을 생성.
이전 단계에서 생성된 VPC와 EC2 인스턴스의 보안그룹을 이용해서 시작템플릿 생성.
ASG를 구성하기 위해 VPC와 프라이빗 서브넷을 설정

4. S3스토리지 생성

버킷 생성.
버킷을 배치할 region 선택.
S3는 오브젝트 스토리지이니 호스팅을 위한 오브젝트를 추가해줘야함.

5. Auto Scaling 그룹 내의 인스턴스들만 RDS 서비스를 이용할 수 있도록 보안 그룹 생성

인바운드 규칙으로 Auto Scaling Group에 적용되어 있는 보안 그룹 선택.
RDS 보안 그룹이 생성되었으므로 RDS 인스턴스 생성.
RDS 인스턴스의 데이터베이스 엔진 선택.
RDS의 사용자 명, 패스워드를 설정.
RDS의 네트워크 및 보안을 설정. → RDS가 운영될 VPC, 서브넷, 외부의 접근 허용여부, 보안 그룹 지정.
프로젝트를 위해 작성될 코드에 어떤 데이터 베이스를 사용할 것인지, 어떻게 연결할 것인지 명시하는 작업을 수행하고 AWS Secrets Manager에 저장.
웹 서버가 Secrets Manager에 접근할 수 있도록 정책 설정.

저작자표시 비영리 변경금지