인프라 구축기 (1) - 개요, IAM 설정, 아키텍처 소개

인프라 구축기

인프라 구축기 개요

인프라 구축 개요

데이터 엔지니어링 데브코스 3기를 진행하면서 데이터 파이프라인을 위한 AWS 인프라를 구축했었지만, 네트워크나 보안, 비용 등 관리 측면의 고려 사항은 모두 배제하고 진행하였다. 이번 프로젝트 진행에서 인프라 및 데이터 엔지니어링 역할을 맡게 되었고, 이전에 신경 쓰지 못했던 세부사항과 서비스 사용 이유 등을 고려하여 인프라 구축을 진행해보려 한다. 추가로 인프라 구축을 진행하며, 고민했던 과정을 작성할 것이다.

프로젝트 목표 및 규모

• 자동화된 데이터 수집 (크롤링) 및 대시보드 제작
• 데이터 엔지니어링 관점에서 최적화 및 모니터링을 고려하며 진행
• 모든 데이터를 한 달간 수집해도 10GB를 넘지 않을 것이라 추측
• 대규모 데이터 처리 방법보다는 자동화 과정을 모니터링하고, 관리 측면에서 최적화하는 것이 목표

주요 사항

기술적인 지식 습득을 위해 어느 정도의 오버 엔지니어링을 감수하고 진행하려 한다. 데이터 엔지니어링에서의 필수 지식인 자동화 프레임워크와 데이터 웨어하우스를 사용하기 위해 Airflow와 Redshift를 사용할 것이다.

• Airflow
  • EC2 내에서 docker를 활용해 aifrlow를 사용하므로 다소 높은 사양의 인스턴스 필요
  • 간단한 자동화이므로 Crontab 혹은 Lambda로도 충분히 구현 가능
• Redshift
  • AWS의 데이터 웨어하우스 서비스로 대규모 데이터 처리에 사용
  • Redshift Serverless의 경우 쿼리 실행 시간에 따라 비용 부과
  • 프로젝트에서 대규모 데이터를 다루지 못하기 때문에 더 저렴한 RDS로도 충분히 구현 가능

IAM 설정

IAM 사용자 그룹 및 사용자

• 루트 계정을 그대로 사용하면 보안 이슈가 생길 수 있기에 IAM 활용
  • "AdministratorAccess" 정책이 부여된 사용자 그룹 생성
  • 인프라 구성을 진행하는 인원 (3명) 수 만큼 사용자를 생성해 사용자 그룹에 추가
  • 각 사용자는 MFA를 사용하여 계정 보안 강화

아키텍처 소개

draw.io 사이트를 활용해 해당 아키텍처를 작성하였다. 아키텍처는 프로젝트를 진행하는 과정에서 변경될 수 있다.

인프라 아키텍처

인프라 구성

• Region : ap-northeast-2 (서울, 10.0.0.0/16)
• Available Zone (AZ) & Subnet
  • ap-northeast-2a
    • Public Subnet (10.0.0.0/20) : EC2 (Bastion Host)
    • Private Subnet (10.0.16.0/20) : Redshift Serverless
    • Private Subnet(10.0.32.0/20) : Postgres RDS
  • ap-northeast-2b
    
    • Private Subnet (10.0.48.0/20) : Redshift Serverless
    • Private Subnet (10.0.64.0/20) : Postgres RDS
  • ap-northeast-2c
    • Public Subnet (10.0.80.0/20) : NAT Gateway
    • Private Subnet (10.0.112.0/20) : Redshift Serverless
    • Private Subnet (10.0.128.0/20) : Postgres RDS
    • Private Subnet (10.0.144.0/20) : EC2 (Airflow (Web Server, Scheduler, Worker))

요소 소개 및 리소스 설정

• Redshift Serverless
  • 기본 용량 (RPU)은 32로 설정, 데이터 크기가 크지 않기 때문에 가장 작은 리소스 할당
  • 세 개 이상의 서로 다른 AZ의 Subnet이 필요하므로 각 AZ의 Private Subnet에 할당
• EC2
  • Bastion Host
    • Private Subnet에 있는 리소스에 접근하기 위한 서버
    • 단순 통로 역할이기에 프리 티어인 t2.micro 사용
    • OS : Ubuntu Server 24.04 LTS (HVM), SSD Volume Type
  • Airflow (Web Server, Scheduler, Worker)
    
    • ETL과 ELT 과정을 자동화 및 스케줄링하기 위한 프레임워크
    • Airflow를 유지하기 위해 다소 높은 사양인 t3.large 사용
    • OS : Ubuntu Server 24.04 LTS (HVM), SSD Volume Type
• PostgreSQL RDS
  • Airflow의 메타 데이터를 저장할 DB
  • 스토리지는 범용 SSD (gp3) 50GB로 설정
  • 가용성보다는 비용 절감을 목표로 하기에 프리 티어 사용 (단일 AZ)
  • 엔진 버전 : PostgreSQL 16.3-R2

• S3
  • AWS의 오브젝트 스토리지 서비스
  • 데이터 크롤링 후 파일 형태로 저장될 데이터 레이크

• NAT Gateway
  • Private Subnet의 리소스가 외부 인터넷에 접근할 수 있도록 해주는 네트워크 장치
  • 반대로 외부에서는 Private 리소스에 접근할 수 없음
  • CI/CD를 통해 Github의 코드를 가져오기 위해 사용
• Internet Gateway
  • VPC 내의 Public Subnet 리소스가 인터넷과 통신할 수 있도록 하는 게이트웨이
  • Public IP가 할당된 인스턴스는 Internet Gateway를 통해 인터넷 접근 가능
  • Internet Gateway -> Bastion Host -> Private 리소스 접근 가능
• S3 Endpoint
  • VPC 내에서 S3에 직접 연결할 수 있는 경로로 Private 리소스 - S3 간 안전하게 통신 가능
  • 인터넷을 통하지 않고 S3에 접근 가능하며, 보안성과 네트워크 효율성 향상

네트워크 구성

1. Redshift Serverless는 서로 다른 3개의 AZ Private Subnet에 존재
2. EC2 (Airflow)와 PostgreSQL RDS는 같은 AZ에 존재
   • 같은 AZ에 존재해 통신 비용 최소화
   • 다른 AZ에 놓더라도 하나의 AZ에 문제가 생기면 Airflow는 사용 불가
   • 가용성을 유지하려면 추가 리소스와 ELB를 사용해야 하지만, 비용 절감을 위해 사용 X
3. NAT Gateway는 EC2 (Airflow)가 존재하는 AZ에만 존재
   
   • Airflow의 경우 Github의 DAG 파일을 CI/CD를 통해 가져올 것이므로 NAT Gateway 필요
4. EC2 (Airflow)의 Web Server에 쉬운 접근을 위해 ALB 사용
   • ALB에 부여된 DNS로 허용된 IP 주소만 Airflow Web Server에 직접 접속 가능
   • 원래 ALB를 사용해 웹 접속을 하려고 했지만, nginx를 활용한 방법도 생각중

고민 과정

• 단일 AZ에서 다중 AZ로 아키텍처 변경
  • 높은 가용성을 위한 다중 AZ보다 단일 AZ로 간단하고 적은 비용으로 프로젝트를 진행하기로 결정
  • 처음 아키텍처에서 단일 AZ를 사용하여 Subnet을 구성하였지만 Redshift Serverless 생성 불가 
  • Redshift Serverless를 사용하려면 세 개 이상의 서로 다른 AZ의 Subnet에 존재해야 함
  • 3개의 AZ로 구성하고 각 Private Subnet의 IP를 Redshift Serverless에게 할당하는 것으로 결정
• Redshift vs Redshift Serverless
  • Redshift
    • 클러스터 크기, 노드 수, 유형 등을 직접 설정하고 관리해야 함
    • 선택한 노드의 크기와 수에 따라 시간당 비용 지불 (고정 비용)
    • 특정한 컴퓨팅 및 스토리지 자원을 미리 설정해 운영
  • Redshift Serverless
    • 특별한 설정 없이 자동으로 리소스를 할당하고 확장
    • 필요할 때만 자원이 할당되므로 예측할 수 없는 워크로드에 적합 (가변 비용)
    • 클러스터 프로비저닝 없이 SQL 실행이 가능하며, 서버 관리에 대한 부담이 없음
    • 단점 : 프로비저닝이 필요 없으므로 이미 정해진 규격과 형태를 따라야 함 (커스텀 불가)
  • 프로젝트에서는 프리 티어 ($300)가 제공되며, 서버 관리가 필요 없는 Redshift Serverless 사용
• 외부에서 EC2 (Airflow)의 Web Server에 접속하기 위한 방법
  1. SSH 포트 포워딩 & 프록시 설정
     • Bastion Host를 중개로 Local (Bastion Host)에서 Private Subnet에 접속하는 방법
     • 외부에서 직접적인 도메인 접속은 지원하지 않고, 로컬 머신에서만 가능하다는 한계
     • 참고 : Private Subnet EC2는 Public IP가 존재하지 않고, Internet Gateway 연결 X
  2. ALB & NLB 사용
     • ALB는 Public Subnet에 위치하며, 외부의 트래픽을 Private Subnet에 전달하는 역할
     • ALB에 부여된 DNS를 통해 인터넷에서 Airflow Web Server에 접근 가능
     • EC2 (Airflow)의 보안 그룹 (인바운드 그룹)에 ALB 트래픽 허용을 추가해야 함
  3. EC2 + nginx 사용
     • EC2 서버에 Elastic IP를 부여하고, nginx를 활용해 트래픽 전송을 받아 웹 접속
     • Bastion Host에서 활용한다면 Elastic IP 비 발생

용어 정리

• 가용성 (Availability)
  • 서버와 네트워크, 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도
  • 즉, 가용성 높은 인프라는 하나의 AZ에서 문제가 생기더라도 다른 AZ를 통해 정상 작동 가능
• 프로비저닝 (Provisioning)
  • 필요한 자원 (컴퓨팅, 네트워크, 스토리지 등)을 미리 설정하고 준비하는 과정
  • Redshift : 노드 수, 노드 크기 등을 미리 결정하는 과정

Reference

https://ko.wikipedia.org/wiki/%EA%B0%80%EC%9A%A9%EC%84%B1

https://www.redhat.com/ko/topics/automation/what-is-provisioning