개인 프로젝트(Swimcolor)를 개발하면서 AWS 아키텍처들이 점차 변경되었는데, 그 과정을 정리해보려고 합니다.

📍 배경

https://d1iq2qlestvas6.cloudfront.net/

개인 프로젝트 Swimcolor를 개발하면서 처음으로 AWS 클라우드 환경을 직접 설계하고 운영해보게 되었습니다.

프로젝트는 12월 중순부터 시작했습니다.

가능한 빠르게 클라우드 환경에 올려 주변 친구들한테 서비스를 공유하고 피드백을 받고 싶었습니다.

(그리고 직접 서비스를 운영할 생각도 있었고요 ㅎㅎ)

 

현재는 어느 정도 AWS 아키텍처가 안정된 상태입니다.

그래서 이번 글에서는 Swimcolor 프로젝트에서 실제로 사용했던 AWS 아키텍처를 기준으로 다음 서비스들의 특징을 정리해보려고 합니다.

  • AWS App Runner
  • AWS EC2
  • AWS Lambda
  • AWS SQS

그리고 시간 순서대로 아키텍처가 어떻게 변화했는지 함께 정리해보겠습니다.

 

1️⃣ App Runner

처음에는 다음과 같은 구조로 서비스를 시작했습니다.

ECR → App Runner → FastApi API
                       ↑↓ HTTP 통신                        
ECR → App Runner → Spring Boot API
                        ↓
                       RDS

 

Github Actions를 사용해서 Docker 이미지를 ECR에 업로드하고 App Runner에서 바로 배포하는 방식이었습니다.

 

App Runner의 특징 및 장점

App Runner는 AWS에서 제공하는 완전관리형 웹 애플리케이션 서비스 (PaaS; Platform as a Service) 입니다.
컨테이너 이미지를 기반으로 애플리케이션을 실행하며 다음 기능을 자동으로 제공합니다.

  • Docker 이미지만 있으면 바로 배포 가능
  • 로드밸런싱 제공
  • 자동 HTTPS
  • 오토 스케일링
  • 서버 관리 (서버 설정 불 필요)

즉, 서버를 직접 관리하지 않아도 웹 서비스를 바로 실행할 수 있는 서비스입니다.

당시 목표는 가능한 빠르게 클라우드에 서비스를 올리는 것이었습니다

이러한 장점 때문에 저는 App Runner를 선택해서 웹 애플리케이션 서비스를 운영하게 되었습니다.

 

참고로 App Runner는 현재 서울 리전은 비활성화 되어 있어서 저는 도쿄 리전에서 실행했습니다.

 

App Runner의 단점

하지만 App Runner의 단점이 있었는데요 바로 비용 문제였습니다.

서비스를 운영한지 한 달 정도 되었을 때 AWS 비용을 확인해보니 

27.86 달러 = 약 4만원 정도의 비용이 발생했습니다 😱

App runner는 편리하지만 프리티어로 사용할 수 없는 서비스입니다.

(여담으로 IAM 설정을 잘못해서 조직에 들어가면서 프리티어를 사용할 수 없는 계정 상태가 되었더라고요... 😂)

 

개인 프로젝트 입장에서는 이 비용이 꽤나 부담되었기 때문에 프리티어로 사용할 수 있는 EC2 구조로 2월에 전환하게 되었습니다.

2️⃣ EC2

EC2의 특징

EC2는 AWS 에서 제공하는 가상 서버 서비스 (IaaS; Infrastructure as a Service ) 입니다

즉, 클라우드 상에서 직접 서버를 생성하고 운영할 수 있는 서비스 입니다.

EC2는 App Runner와 다르게 개발자가 서버 환경을 직접 관리해야 합니다

 

예를 들면 다음과 같은 것들을 직접 설정해야 합니다.

  • 운영체제
  • 보안 그룹
  • 네트워크
  • 서버 실행
  • Docker 설치

하지만 대신 서버 환경을 완전히 제어할 수 있는 자유도가 있습니다

 

EC2의 장점

  • 서버 환경 완전 제어 가능
  • 원하는 애플리케이션 실행 가능
  • 비용 절감 가능 (프리티어)

EC2의 단점

  • 서버 관리 필요
  • 운영 부담 존재 
  • 장애 대응 필요

 

EC2의 문제점

프리티어 환경에서 제공되는 EC2 사양은 이와 같습니다 

저는 t3.micro를 사용하고 있어 사양이 2vCPU (=1CPU) 1GB 환경에서 서비스를 운영하게 되었습니다

 

App Runner 환경에서는 다음과 같은 스펙으로 서비스를 운영했습니다.

  • Spring Boot → 1 CPU / 2GB RAM
  • FastAPI → 2 CPU / 4GB RAM

 

하지만 EC2 에서는 두 개의 Docker 컨테이너를 실행하자 서버가 거의 멈추는 수준이 되었습니다.

특히 FastAPI 컨테이너는 PyTorch 기반 이미지 분석 코드가 포함되어 있어 리소스를 많이 사용했습니다.

심지어 FastAPI 컨테이너만 실행해도 EC2 터미널에서 명령어를 입력하기 어려울 정도로 느려졌습니다.

Docker 이미지 크기도 약 4.8GB로 상당히 큰 상태였습니다.

결국 이 문제를 해결하기 위해 FastAPI 아키텍처를 분리하기로 결정했습니다.

 

3️⃣ Lambda

FastAPI 서비스에는 다음과 같은 주요 기능이 있었습니다.

  • 수영복 / 수모 크롤링
  • YOLO를 활용한 객체 탐지
  • 색상 분석

이 기능들을 AWS Lambda로 분리하기로 했습니다.

Lambda는 AWS에서 제공하는 Serverless 컴퓨팅 서비스입니다.

즉 서버를 직접 운영하지 않고 코드만 실행할 수 있는 환경입니다.

 

Lambda 특징

Lambda는 이벤트 기반으로 필요할 때만 실행되는 구조를 가지고 있습니다.

예를 들어 다음과 같은 이벤트로 실행될 수 있습니다.

  • API 요청
  • S3 업로드
  • 메시지 큐
  • 스케줄

Lambda 장점

  • 서버 관리 필요 없음
  • 자동 스케일링
  • 사용한 만큼만 과금

Lambda 역시 Github Actions를 통해 Docker 이미지를 빌드하고 ECR을 통해 Lambda에서 실행하도록 구성했습니다.

또한 기존 FastAPI 구조를 분리하여 다음과 같이 구성했습니다.

  • 크롤링 Lambda
  • YOLO 추론 및 색상 분석 Lambda

총 2개의 Lambda로 서비스를 분리했습니다.

 

 

4️⃣ SQS

두 개의 Lambda를 운영하면서 또 하나의 고민이 생겼습니다.

크롤링 Lambda와 색상 분석 Lambda를 연속 호출하게 되면,
크롤링 Lambda가 색상 분석 Lambda가 끝날 때까지 대기 상태(블로킹구조) 가 됩니다.

하지만 저는 크롤링이 끝나면 크롤링 Lambda는 바로 종료되는 구조(논블로킹구조) 가 더 적절하다고 생각했습니다.

이미 크롤링이 완료되었으나 색상분석을 위해 크롤링 람다가 돌아가므로 비용도 응답받는 시간만큼 과금되기 때문입니다.

 

그래서 크롤링 데이터를 임시로 저장할 공간이 필요했습니다.

즉 다음과 같은 구조입니다.

`크롤링 작업 → 데이터 저장 → 색상 분석`
 

이때 선택한 서비스가 SQS (Simple Queue Service) 입니다.

 

SQS 사용 방식

한 번 크롤링할 때 평균적으로 약 200개의 데이터가 수집되었습니다.

그래서 색상 분석 Lambda가 처리할 때 100개씩 나누어 처리하도록 구성했습니다.

색상 분석이 완료되면 Spring Boot가 실행 중인 EC2 서버로 HTTP 콜백을 보내도록 구성했습니다.

또한 SQS 트리거를 통해 색상 분석 Lambda가 자동으로 실행되도록 설정했습니다.

 

SQS 특징 

SQS는 AWS에서 제공하는 메시지 큐 서비스입니다.

쉽게 말하면 작업을 임시로 저장하는 대기열(queue) 입니다.

 

SQS 장점

  • 비동기 처리 가능
  • 서비스 간 결합도 감소
  • 트래픽 버퍼 역할

특히 크롤링과 같은 대량 데이터 처리 작업에서 매우 유용하게 사용할 수 있습니다.

📍 정리

Swimcolor 프로젝트의 아키텍처는 다음과 같이 변화했습니다.

App Runner + ECR
↓
비용 문제
↓
EC2
↓
리소스 문제
↓
Lambda
↓
비동기 처리
↓
SQS
 

처음에는 단순히 클라우드에 서비스를 올리는 것이 목표였습니다.

하지만 실제로 서비스를 운영하면서 비용, 서버 리소스, 비동기 처리 문제를 경험하게 되었고, 그때마다 아키텍처를 개선하게 되었습니다.

이번 프로젝트를 통해 다음과 같은 기준을 정리할 수 있었습니다.

  • 빠르게 서비스를 배포할 때 → App Runner
  • 비용을 줄이고 서버를 직접 관리할 때 → EC2
  • 리소스를 많이 사용하는 작업을 분리할 때 → Lambda
  • 비동기 처리와 시스템 결합도를 낮출 때 → SQS

결과적으로 단순히 AWS 서비스를 사용하는 것을 넘어 서비스 상황에 맞는 아키텍처를 선택하고 개선하는 경험을 할 수 있었습니다.

앞으로는 현재 구조를 기반으로 서비스를 운영하면서 비동기 처리 구조를 더욱 개선하고 시스템 안정성을 높이는 방향으로 아키텍처를 발전시켜볼 계획입니다.

'클라우드_인프라' 카테고리의 다른 글

AWS 핵심 서비스로 웹 어플리케이션 구축하기  (1) 2024.09.25
AWS 서버리스로 웹 어플리케이션 구축하기 이론  (1) 2024.09.11
MSA :: Micro Service Architecture 알아보기  (1) 2024.09.04

티스토리툴바