yuntae-log
🌙
archived-project

(Project) Petraschu 서비스 비용 줄이기

date
Feb 2, 2024
slug
petraschu-aws-architecture
author
status
Public
tags
Archived
summary
Petraschu 서비스를 AWS 이관하는데서 제안하는 아키텍처 및 비용 분석, 중앙 로그 메트릭 수집 대시보드 등
type
Post
thumbnail
dmp-network-architecture-dmp-aws-architecture-eks.drawio.png
category
archived-project
updatedAt
Oct 1, 2025 06:23 AM

Index

  1. Introduction
  1. 기존 아키텍처 및 AWS 이관 시 비용 예측
  1. Problem
  1. New Architecture
  1. New Architecture 비용 예측
  1. Review AI 로직 변경
  1. 통합 로그 메트릭 수집 및 대시보드
  1. Projects 진행 계획
    1. 1단계
      1. AWS 이관
      2. Review AI 로직 변경
    2. 2단계
      1. 새 아키텍처 도입
    3. 3단계
      1. 통합 로그 메트릭 수집 및 대시보드
  1. Conclusion
  1. Reference

Introduction

안녕하세요 Yureutae 입니다. 해당 포스트에서는 AWS 이관 과정에서 제가 직접 구성한 아키텍처 및 비용 최적화에 대해서 설명합니다.
 
저는 서울과학기술대학교 빅데이터 관리 및 응용 연구실에서, 2023년부터 해당 Petraschu 서비스 전체 개발 및 아키텍처 구성에 기여했으며, Kakao i Cloud의 지원을 받아 현재 안정적이게 운영되는 서비스를 개발했습니다.
DMP Networks에서는 반려동물 및 관련 데이터를 이용해 Petraschu 서비스를 운영하고 있습니다.
아래의 웹사이트 뿐만 아니라 관련 데이터를 활용한 API, 딥러닝 추론이 있으며 로그 데이터 등을 모니터링하는 서버를 구성해서 운영 중입니다.
펫트라슈 - 동물병원 진료비
24시간동물병원 | 반려동물 병원 진료비 실시간 조회와 증상별 질병, 동물병원, 약국, 미용, 호텔 추천 서비스를 제공합니다.
펫트라슈 - 동물병원 진료비
https://petraschu.com/
펫트라슈 - 동물병원 진료비
하지만 1년 동안의 지원에 기대어, 해당 아키텍처를 비용적으로 분석하여 최적화하지 않았습니다. 아래부터 AWS 이관 과정에서 아키텍처 변경 이유 및 신규 아키텍처 도입, 비용 분석 등을 설명합니다. 아키텍처 내부의 각 서비스에 대한 소개는 추가적으로 업로드 하도록 하겠습니다.

기존 아키텍처 및 AWS 이관 시 비용 예측

현재 Kakao i Cloud에서 Petraschu 통합 서비스 운영에 핵심이 되는 것들만 남겨 아키텍처를 그렸습니다.

아키텍처 구성도

현재의 아키텍처 구성도입니다. 아래 간단하게 구성요소에 관해 요약했습니다.
  • Petraschu 웹사이트
    • Vue js 및 typescript express js로 구성된 웹사이트입니다.
    • PWA로 구성하여 모바일 환경에도 쉽게 대응가능하도록 구성했습니다.
    • 현재 정적 파일(이미지, 프론트 빌드 파일 등)및 프록싱이 NGINX를 통해 처리되고 있으며, 정적파일은 모두 해당 서버의 스토리지에 저장됩니다.
  • Review AI 분석 서비스
    • Petraschu 웹사이트에서 고객이 남긴 리뷰에 대해서 Pytorch 딥러닝 모델로 추론합니다.
    • 병원, 약국 등에 대해 리뷰 분석기반 긍정 부정의 비율을 표시하여 고객에게 제공합니다.
  • Petraschu Dataset 제공 API
    • Petraschu에서는 동물병원 영수증, 이미지, 리뷰에 관해 많은 데이터를 보유 중입니다.
    • 해당 데이터를 타 사에 제공하는 API 서비스를 운영 중입니다.
    • FastAPI를 백엔드로 운영 중이며, replicate 된 백엔드에 대해서 로그를 수집하여 전송하기 위해 Filebeat를 사용 중입니다.
  • DB
    • 현재 이미지와 로그를 제외한 모든 데이터는 PostgresSQL에 적재되며 중앙관리되고 있습니다.
  • Monitoring
    • 로그 데이터 등을 수집하고 분석하여, 관리자 및 비즈니스 파트에서 편리한 UI를 제공합니다.
    • Logstash로 각 Filebeat agent로부터 데이터를 전달받아 Parsing 처리합니다. (Preprocessing)
    • Logstash는 Elastic Search에 데이터를 적재하며, Elastic Search에서 해당 데이터를 관리합니다.
    • Kibana에서 범용성이 높은 Grafana로 전환하고 대시보드를 만들어 제공하고 있습니다.
notion image
 

현재 아키텍처에서 사용 중인 Cloud Service

현재 사용 중인 Cloud Service는 다음과 같습니다. 용어는 AWS가 업계 기준이므로, AWS 서울 region 내 Cloud Service로 통일하겠습니다. 기존에는 Kakao i Cloud에서 지원이 있어 resource를 넉넉히 할당하고 사용하여 정확한 비용 추산이 되지 않습니다. 따라서 현재 사용량 등을 고려하여 해당 서비스 운영에 필요한 만큼의 AWS 내 resource 및 금액을 표기했습니다. (Over-provisioned Resource Scale Down)
 
총, 최소 월 819 $ ⇒ 약 108만원 (네트워크 사용 비용 등에 의해 증가될 수 있습니다.) ec2: computing instance, EBS: Block Storage(SSD)
  • Petraschu 2.0
    • ec2 (On-demand)
      • t4g.xlarge (vCPU 4, Ram 16)
      • 월 121.47 $
    • EBS
      • gp3 (60GB)
      • 월 5.47 $
    • public ip
      • 월 3.65 $
  • Dataset API
    • ec2 (On-demand)
      • t4g.small (vCPU 2, Ram 2)
      • 월 15.18 $
    • EBS
      • gp3 (15GB)
      • 월 1.37 $
    • public ip
      • 월 3.65 $
  • Review AI
    • ec2 (On-demand) + gpu
      • g4dn.xlarge (vCPU 4, Ram 16, NVIDIA T4)
      • 월 472.31 $
    • EBS
      • gp3 (25GB)
      • 월 2.28 $
    • public ip
      • 월 3.65 $
  • Monitoring
    • ec2 (On-demand)
      • t4g.xlarge (vCPU 4, Ram 16)
      • 월 121.47 $
    • EBS
      • gp3 (15GB)
      • 월 1.47 $
    • public ip
      • 월 3.65 $
  • Petraschu DB
    • ec2 (On-demand)
      • t4g.medium (vCPU 2, Ram 4)
      • active-standby ⇒ 30.37 * 2 ⇒ 월 60.74 $
    • EBS
      • gp3 (15GB)
      • 1.37 * 2 ⇒ 월 2.64 $
 

Problem

현재 Kakao i Cloud에서 운영되고 있는 해당 아키텍처의 문제점을 분석하여 정리해보았습니다.

낭비되는 resource

  • Review AI의 경우, 비교적 넓은 batch 간격(주기적)으로 동작하고 있습니다. 고가의 GPU를 24/7 운영하는 데 있어, 학습이 아닌 batch 단위의 추론용으론 비효율적입니다. 또한 별도의 백엔드를 프로덕션 용이 아닌 개발용으로 임시 운영하고 있고, DB 내 발생한 후기 전체를 매번 조회해야하는 구조로 인해 리소스 낭비를 일으킵니다.
  • 기존 petraschu 웹서비스 backend의 경우, 현재 고가의 인스턴스 1개를 사용하는 것을 기준으로 개발되었습니다. 이는 트래픽 변동에 적절히 대응되지 않으며 비효율적입니다.
  • petraschu 웹서비스 frontend의 경우, 정적인 build 파일을 인스턴스의 웹서버를 통해서 제공하고 있습니다. 이는 상대적으로 비용이 높은 네트워크를 사용하게 됩니다.
  • 모니터링 서버는 고가의 인스턴스 및 스토리지를 필요로 합니다. 모니터링의 편의성은 증진되었지만 비용이 크게 증가하게 됩니다.

시스템 장애, 애플리케이션 로그, 메트릭 추적의 어려움

  • 모든 요소에 대한 인스턴스 및 스토리지, 로그 등이 중앙 관리가 되지 않습니다.
  • 로그 및 메트릭 관찰을 위해서 agent를 모든 인스턴스 별, 모든 애플리케이션 단계별로 비교적 까다롭게 설정됩니다.

서비스 확장 시 발생되는 어려움

  • 아키텍처의 각 요소는 letsencrypt 를 이용해 무료 SSL/TLS 인증서를 주기적으로 받아 HTTPS를 적용 중입니다. 데이터 송수신에 안정적이지만, 도메인에 대한 SSL/TLS 갱신 및 웹서버 설정과정을 모든 서비스에 일일히 작업해주는 과정이 필요하며 오류가 잦은 편입니다.
  • 서비스 배포 시, docker 등의 도구 없이는 환경에 대한 문제가 발생할 수 있습니다.

증가하는 데이터

  • 영수증 이미지와 애완동물 이미지가 현재 매우 많고, 계속 추가되기 때문에 스토리지에 대해서 적절한 scale up이 필요합니다.
  • 영수증 이미지와 애완동물 이미지는 단순 데이터가 아니라, 클라이언트에게 제공되기 때문에 CRUD 처리가 잘 이루어져야합니다.
  • 다량의 이미지 데이터에 대한 명령 수행이 빠르게 이루어져야합니다.

온디맨드 요금 방식

  • 단순 온디맨드 요금을 현재는 사용 중인데, 이와 같은 방식을 유지할 경우 시스템 유지 비용이 매우 커지게 됩니다.
 
 
 

New Architecture

아키텍처 구성도

AWS Cloud Service에 맞춰 새로 구성한 아키텍처입니다. 데이터 증가 및 서비스 확장 등에 맞춰 작성했습니다.아키텍처를 구성하는 요소에 대해서는 아래에서 설명하겠습니다.
해당 구조로, 기존대비 비용 절감이 크게 가능해지고 전체 애플리케이션에 대해 확장 및 고가용성을 만족할 수 있으며 성능 향상을 꾀할 수 있습니다.
또한 CloudWatch 등의 통합 시각화 대시보드 도입으로, 애플리케이션 뿐만 아니라 인프라 구성요소 모두에 대해 실시간 관리 감독, 알람화 등이 가능하며 사용자 편의에 맞게 대시보드 구성을 할 수 있습니다. 또한 중앙화된 로그/메트릭 데이터 수집으로 추후 이상행위 탐지, 사용자 애플리케이션 사용 패턴 분석, 장애 발생 예측, 비용 누수 탐지 등의 유의미한 데이터 분석 수행을 꾀할 수 있습니다.
 

아키텍처 내부 요소

notion image
아키텍처 구성도 기준 왼쪽부터 설명하겠습니다.
 

AWS Route 53

DNS 서비스. 가비아 DNS 매핑가능
💡
Amazon Route 53은 확장 가능하고 안정적인 Domain Name System (DNS) 웹 서비스입니다. 도메인 이름을 IP 주소로 변환하여 인터넷 트래픽을 웹 사이트, 애플리케이션 및 기타 리소스로 라우팅하는 데 사용됩니다.
 

AWS S3 (Simple Storage Service)

증가하는 데이터에 적절하게 대응이 가능하며, 정적 웹 호스팅 기능으로 petraschu frontend를 따로 처리하여 성능 및 비용에 개선가능
💡
  • 무한한 스토리지: Amazon S3는 무제한의 스토리지 공간을 제공하며, 사용자는 필요한 만큼 데이터를 저장할 수 있습니다.
  • 데이터 내구성: Amazon S3는 데이터를 여러 가용 영역에 복제하여 고가용성과 내구성을 보장하며, 데이터의 손실을 방지합니다.
  • 객체 스토리지: S3는 파일, 이미지, 비디오, 문서 등 다양한 형식의 객체를 저장하고 관리할 수 있습니다.
  • 데이터 버전 관리: Amazon S3는 데이터의 버전을 관리하고, 이전 버전으로 롤백할 수 있으며, 데이터 복원을 지원합니다.
  • 데이터 보안: S3는 데이터 암호화, 액세스 제어, 버킷 정책 및 IAM(Identity and Access Management)과 통합되어 데이터의 보안을 강화합니다.
  • 데이터 검색 및 분류: S3는 객체에 메타데이터를 추가하고, 태그를 사용하여 데이터를 쉽게 검색하고 분류할 수 있습니다.
  • 정적 웹 호스팅: Amazon S3를 사용하여 정적 웹 사이트를 호스팅할 수 있으며, 정적 웹 페이지를 배포하고 전세계 사용자에게 액세스할 수 있습니다.
  • 데이터 전송 및 이동: 데이터를 Amazon S3로 쉽게 업로드 및 다운로드하거나, AWS DataSync, AWS Transfer for SFTP 등을 사용하여 데이터 이동 및 동기화를 수행할 수 있습니다.
  • 비용 효율성: Amazon S3는 사용한 스토리지 양에 따라 과금되므로 필요한 만큼만 비용을 지불하게 됩니다.
 

ELB (Elastic Load Balancer)

웹서버의 역할을 하나로 대체, 트래픽 분산 처리 가능.
💡
  • AWS에서 제공하는 관리형 로드 밸런서 서비스입니다.
  • 로드 밸런싱: ELB는 트래픽을 여러 EC2 인스턴스 또는 컨테이너로 분산하여 애플리케이션의 부하를 고르게 분산합니다.
  • 자동 확장: ELB는 트래픽이 증가하면 자동으로 더 많은 인스턴스를 생성하고 연결하여 애플리케이션의 성능을 유지합니다.
  • 고가용성: ELB는 여러 가용 영역에 분산되어 장애에 대비하고 애플리케이션의 가용성을 보장합니다
  • SSL/TLS 종단점 관리: ELB는 SSL/TLS 인증서를 관리하고, 애플리케이션에 대한 암호화 연결을 처리하여 보안을 강화합니다.
  • 관리형 서비스: ELB는 관리 및 유지보수가 AWS에서 자동으로 처리되므로 운영자가 로드 밸런서 인프라를 관리할 필요가 없습니다.
 

Container Orchestration Management Service (EKS, ECS 중 선택)

  • 두 서비스 모두 Container Orchestration Management Service입니다
  • 두 서비스 모두 EC2 단위의 노드 내 배포가 아닌 Fargate(Serverless)를 통해서도 Container 스펙에 맞춰 애플리케이션 배포가 가능하여 비용절감을 크게 이룰 수 있습니다.
  • 두 서비스 모두 Container 단위로 Auto Scaling이 가능합니다. 트래픽 증감에 따라 비용 최적화가 가능합니다.
  • 두 서비스 모두 AWS Batch를 프로비저닝 가능하며, 현재 존재하는 Review AI 등의 작업을 Job, CronJob 등으로 트리거 하여 비용 절감이 가능합니다.
EKS의 경우, K8s 클러스터를 모두 세세히 관리할 수 있고 K8s의 모든 기능을 쓸 수 있지만 K8s를 충분히 관리할 수 있는 인력이 필요하다는 단점이 있습니다.
ECS의 경우, 간편히 클러스터 관리가 가능하지만 AWS에 종속된다는 단점이 있습니다.
 
AWS EKS (Elastic Kubernetes Service)
💡
  • Kubernetes 기반: Kubernetes의 모든 기능을 활용하여 컨테이너를 오케스트레이션할 수 있습니다.
  • 클러스터 관리: 클러스터를 직접 관리하거나 Amazon EKS Anywhere를 사용하여 온-프레미스 또는 다른 클라우드에서 클러스터를 실행할 수 있습니다.
  • 유연성: 다양한 배포 옵션과 맞춤화 가능성을 제공하여 다양한 요구 사항에 맞게 컨테이너를 실행할 수 있습니다.
  • 통합: 다양한 AWS 서비스와 쉽게 통합됩니다.
EKS 사용의 장점:
  • Kubernetes 전문성 활용: Kubernetes에 대한 전문 지식을 활용하여 컨테이너를 배포하고 관리할 수 있습니다.
  • 높은 유연성: 다양한 배포 옵션과 맞춤화 가능성을 통해 다양한 요구 사항에 맞게 컨테이너를 실행할 수 있습니다.
  • 클러스터 제어: 클러스터 환경을 직접 제어하고 설정할 수 있습니다.
  • 온-프레미스 또는 다른 클라우드: Amazon EKS Anywhere를 사용하여 온-프레미스 또는 다른 클라우드에서 컨테이너를 실행할 수 있습니다.
AWS ECS (Elastic Container Service)
💡
  • 서버리스 컴퓨팅 지원: Fargate를 사용하여 서버 관리 없이 컨테이너를 실행할 수 있습니다.
  • 간편한 배포: ECS 작업을 사용하여 컨테이너를 쉽게 배포하고 관리할 수 있습니다.
  • 확장성: 트래픽 증가에 따라 자동으로 확장하여 글로벌 사용자에게 서비스를 제공합니다.
  • 통합: 다양한 AWS 서비스와 쉽게 통합됩니다.
ECS 사용의 장점:
  • 서버 관리 부담 감소: Fargate를 사용하면 서버 프로비저닝, 관리, 확장 등을 걱정할 필요 없이 컨테이너에 집중할 수 있습니다.
  • 비용 절감: 사용한 컴퓨팅 리소스에 대해서만 비용을 지불합니다.
  • 빠른 배포: 코드를 배포하기 위해 서버를 프로비저닝할 필요 없이 ECS 작업을 사용하여 컨테이너를 빠르게 배포할 수 있습니다.
  • 높은 가용성: ECS는 애플리케이션 가용성을 높이도록 설계되었습니다.
 

RDS (AWS Relational Database)

Database 맞춤 서비스로 관리가 훨씬 용이\
💡
  • 데이터베이스 인스턴스 생성 및 관리: RDS는 데이터베이스 인스턴스 프로비저닝, 패치 적용, 백업 및 복원 등을 자동으로 처리합니다.
  • 확장성: 트래픽 증가에 따라 데이터베이스를 쉽게 확장할 수 있습니다.
  • 고가용성: RDS는 여러 가용성 영역에 데이터베이스를 복제하여 높은 가용성을 제공합니다.
  • 보안: RDS는 데이터베이스를 암호화하고 네트워크 트래픽을 제한하여 보안을 강화합니다.
  • 비용 효율성: 사용한 만큼만 비용을 지불합니다.
 

ACM (AWS Certificate Manager)

SSL/TLS 인증서 발급/갱신 과정 중앙관리 및 편의성 향상
💡
  • AWS에서 제공하는 관리형 SSL/TLS 인증서 관리 서비스입니다. ACM을 사용하면 웹 애플리케이션 및 웹 서비스를 안전하게 암호화하고 HTTPS를 사용할 수 있습니다.
  • 기존 letsencrypt 기반 SSL/TLS 발급 및 재갱신 과정이 제거됩니다. 한번 등록하면 AWS ACM에서 자동으로 처리해주게 됩니다.
 

AWS CloudWatch

기존 모니터링 서버를 대체 가능하며, 애플리케이션 로그 뿐만 아니라 운영중인 인프라 전체를 모니터링 가능
💡
  • 리소스 모니터링: CloudWatch는 EC2 인스턴스, RDS 데이터베이스, ELB 로드 밸런서 등 AWS 리소스의 성능 지표를 모니터링하며, CPU 사용률, 네트워크 트래픽, 디스크 I/O 등의 데이터를 수집합니다.
  • 사용자 지정 지표: 사용자는 자신의 애플리케이션 및 리소스에서 사용자 지정 지표를 생성하고 모니터링할 수 있습니다.
  • 경보 및 알림: CloudWatch는 지표에 기반하여 경보를 설정하고, 특정 조건이 충족될 때 알림을 발송합니다. 이를 통해 문제가 발생했을 때 신속하게 대응할 수 있습니다.
  • 대시보드: 사용자는 대시보드를 만들어 다양한 지표와 경보를 한눈에 확인할 수 있으며, 비즈니스 및 기술적 결정에 도움이 됩니다.
  • 로그 및 이벤트 모니터링: CloudWatch Logs 및 CloudWatch Events를 사용하여 로그 데이터와 이벤트를 수집하고 검색할 수 있습니다.
  • 미리 설정된 지표 및 리포트: CloudWatch는 사용자에게 미리 설정된 AWS 서비스별 지표 및 리포트를 제공하여 리소스의 상태를 간편하게 파악할 수 있습니다.
  • 통합 및 확장성: CloudWatch는 다른 AWS 서비스와 쉽게 통합되며, 서비스의 확장과 함께 스케일링이 가능합니다.
 
 
 
 

New Architecture 비용 예측

  • On-demand : 일반적인 인스턴스 서비스 사용 방식입니다. 사용한 시간만큼 월말에 지불하게 됩니다. 원할 때 원하는 만큼 생성하면 되기 때문에 유연합니다.
  • Reserved Instance: 1년/3년 단위로 인스턴스 서비스를 계약합니다. On-demand 대비 상당히 저렴합니다.
  • Spot Instance: 실시간으로 여유 있는 인스턴스를 경매방식으로 가져옵니다. 이 부분은 서비스 중단 위험이 있어 고려하지 않았습니다.
  • Fargate: 서버리스 (인스턴스 단위가 아닌 애플리케이션 단위로 최적화) 사용방식입니다. 인스턴스 단위로 고정된 형태의 리소스가 아닌 더 세밀한 단위로 리소스 사용에 대해 프로비저닝이 가능합니다. 애플리케이션 단위가 되기 때문에 비용을 유연하게 조절할 수 있습니다.
 
비용 예측 2안으로 할 경우, 최소 68% 비용 감축이 가능합니다

비용 예측 1안 (On-demand + Fargate + 필요한 경우 On-demand 추가)

EKS를 사용한다면 ⇒ 월별 최소 450$까지 절감 (약 60만원)
ECS를 사용한다면 ⇒ 월별 최소 377$까지 절감 (약 50만원)
네트워크 트래픽 증감 + 서버 증설에 따라 비용이 달라질 수 있습니다.
Fargate 사용 시 더 절감될 수 있습니다.
notion image
 
  • EKS / ECS
    • EKS 사용 시 월 72$
    • ECS 사용 시 추가 비용 x
  • ec2 (vcpu 4 ram 8 EBS 50GB * 2을 최소로 클러스터 구성)
  • fargate (비용 계산 제외)
    • 시간당 vCPU 1개 0.014 $ + RAM 1GB 0.0015 $
  • Batch
  • S3
  • CloudFront
  • ELB
  • RDS
  • ECR
  • ACM
  • Cloud Watch

비용 예측 2안 (RI 1년 선결제 + Fargate + 필요한 경우 On-demand 추가)

1년 선결제 시에, EKS를 사용한다면 ⇒ 월별 최소 337$까지 절감 (약 45만원)
ECS를 사용한다면 ⇒ 월별 최소 264$까지 절감 (약 35만원)
네트워크 트래픽 증감 + 서버 증설에 따라 비용이 달라질 수 있습니다. Fargate 사용 시 더 절감될 수 있습니다.
notion image
  • EKS / ECS
    • EKS 사용 시 월 72$
    • ECS 사용 시 추가 비용 x
  • ec2 (vcpu 4 ram 8 EBS 50GB * 2을 최소로 클러스터 구성)
  • fargate (비용계산 제외)
    • 시간당 vCPU 1개 0.014 $ + RAM 1GB 0.0015 $
  • Batch
  • S3
  • CloudFront
  • ELB
  • RDS
  • ECR
  • ACM
  • Cloud Watch
 
 
 
 
 

Review AI 로직 변경

아래는 앞서 제시했던 기존 Petraschu 시스템 내 Review AI 분석 아키텍처입니다.
Review AI는 다음과 같은 과정으로 동작합니다.
  1. Pytorch 기반의 모델을 서빙한 백엔드가 Petraschu DB로부터 모든 업체에 대하여 모든 후기를 가져오게됩니다.
  1. Pytorch 모델이 각 업체에 대해 Score를 계산합니다.
    1. 각 업체의 후기 전체에 대해서 추론
    2. 각 업체의 후기 각각에 대해서 추론
    3. 위 두 추론 결과를 합산하여 업체 별 Score를 계산
  1. 모든 Score, 추론 결과를 Redis 인메모리 DB에 저장합니다.
  1. Petraschu.com에서 각 업체를 조회하면 별도의 javascript 파일이 업체 id를 감지하고, 해당 업체에 대해서 Review AI 백엔드 서버에 Score를 요청합니다.
notion image
 
해당 로직은 아래와 같은 단점이 있습니다.
  • 매 주기별 모든 업체의 모든 후기를 조회하고 계산해야하는 과정으로 인한 불필요한 Overhead 발생
  • DB로부터 데이터를 조회하고 별도로 저장하는 과정으로 인한 리소스 낭비
  • 모델을 백그라운드로 서빙위한 백엔드 운영으로 인해 리소스 낭비
  • Petraschu.com에 분석 결과를 제공하기 위해 별도의 agent 서버 운영으로 인한 리소스 낭비
  • 후기 분석 주기의 최적화 불가
  • GPU 리소스 유지를 위해 매우 큰 비용 지출.
  • 서비스 장애 발생 확률 감소
따라서 다음과 같은 구조로 변경합니다.
  1. AWS Batch를 주기 등을 조건으로 Trigger
  1. AWS Batch가 Trigger되면 ECS 또는 EKS 클러스터에 해당 작업(병원 Score 추론)을 수행하는 컨테이너를 프로비저닝
  1. Batch성 작업은 새로 발생한 후기가 있는 업체에 대해서만 Petraschu DB에서 데이터를 읽어들여 수행.
  1. Score 추론 후 해당 결과를 Petraschu DB 업체 테이블에 저장.
 
⇒ 불필요한 백엔드 로직과 API 서버를 없앰으로써 시스템 복잡도를 낮추고, GPU 리소스 사용을 24/7 동안 유지할 필요가 없어 비용이 상당히 감소하게 됩니다.
notion image
 
 
 
 
 

통합 로그 메트릭 수집 및 대시보드

현재 시스템에서 발생하는 로그와 메트릭의 종류와 추후 사용가능한 부분은 다음과 같습니다.
  • Petraschu 웹서비스에서 발생하는 로그
    • 사용자의 Petraschu 웹사이트 내 활동을 데이터화하여 분석하는 행위가 가능
  • Review AI에서 발생하는 로그
    • 서비스 장애 추적
    • 분석 주기 최적화
  • Dataset API에서 발생하는 로그
    • 기존 API 사용 과금 모델
    • API 사용 이상행위 탐지
  • 시스템 내 애플리케이션 및 구성요소들에서 발생하는 실시간 메트릭
    • 시스템 내 장애 원인을 명확히 파악가능
    • 네트워크 공격 등을 실시간으로 파악 가능
    • 장애 발생 또는 트래픽 증가 시, 이메일/슬랙 등 알람화 가능
 
해당 데이터들을 AWS CloudWatch라는 하나의 중앙화된 클라우드 서비스를 통해 수집하고 대시보드화합니다.
앞서 아키텍처 요소 설명에 언급한 것처럼, 기존 모니터링 서버를 대체 가능하며, 애플리케이션 로그 뿐만 아니라 운영중인 인프라 전체를 중앙화 모니터링 가능합니다. 특히 서버 할당없이 적은 비용으로 데이터 중앙 수집, 모니터링, 시각화 대시보드, 알람 설정 등 많은 기능을 수행할 수 있습니다.
notion image
 
 

Projects 진행 계획

  1. 1단계
    1. AWS 이관
    2. Review AI 로직 변경
  1. 2단계
    1. 새 아키텍처 도입
  1. 3단계
    1. 통합 시각화 대시보드

AWS 이관

서비스 중단으로 인해 이관이 어려운 요소인 Petraschu 웹서비스를 제외하고 대부분 이관을 진행합니다.
  1. AWS 내 애플리케이션에 의존하지 않는 구성요소에 대해 먼저 구축을 시작합니다.
    1. VPC, Subnet, IAM 등 구축
    2. 테스트
    3. Terraform 모듈화
    4. 비용 예측 2안을 선택할 경우, 선 결제 등을 같이 진행합니다.
  1. 복제 가능한 요소들을 이관합니다.
    1. DB, Image 등 이관
    2. RDS, S3, CloudWatch 테스트
    3. Terraform 모듈화
  1. 별개 구동이 가능한 애플리케이션들을 온디맨드 ec2로 이관합니다. (아키텍처 도입 완료전까지 온디맨드로 별개 구동)
    1. DatasetAPI, Canari Petraschu Webservice, Monitoring
    2. letsencrypt 인증서 → ACM 이관
    3. 테스트
 

Review AI 로직 변경

현재 Review AI의 낭비되는 리소스를 막고 AWS Lambda/Batch로 수행하기 위해 로직 및 구조를 변경합니다.
  1. 백엔드 로직 제거
  1. 환경별 inference 테스트 (CPU/GPU)
  1. DB 내 신규 테이블/필드 작업
  1. AWS Lambda 또는 Batch 테스트
 

새 아키텍처 도입

  1. AWS 이관 시 구축했던 네트워크에 EKS 또는 ECS를 구축합니다.
    1. EKS 또는 ECS 구축
    2. Terraform 모듈화
    3. 애플리케이션 Container 화 및 Pod화
    4. ECR에 Container 업로드
    5. Pod 배포 및 테스트
    6. RDS 이중화 연결 테스트
  1. 로드밸런싱을 구축 및 연결합니다.
    1. ALB 연결
    2. Terraform 모듈화
    3. 네트워크 로드밸런싱 테스트
  1. Route53, CloudFront, S3를 연결합니다.
    1. EKS/ECS와 연결
    2. Terraform 모듈화
    3. Canari Petraschu로 CloudFront, S3 테스트
  1. Petraschu 웹서비스 이관
    1. 기존 코드 내에 이미지 전송관련 코드 재작성
    2. Petraschu 도메인 letsencrypt 이관
    3. CloudFront, S3 정상 CRUD 가능한 지 테스트
 

통합 로그 메트릭 수집 및 대시보드

  1. 전체 아키텍처 내 인스턴스, 클러스터, 클라우드 서비스 메트릭 수집 가능하도록 agent 설치
  1. 애플리케이션 Pod 내 data collector agent 추가 및 테스트 (fluentd 또는 beats)
  1. CloudWatch와 모든 agent 연결
  1. 데이터 별로 도메인화하여 대시보드 구성
 

Conclusion

해당 아키텍처를 AWS에 도입함으로써 얻게되는 이익은 다음과 같습니다.
  • 월 비용 약 108만원 → 35만원으로, 약 68% 비용 절감
  • aws cloud service를 통한 중앙화된 관리
  • 고가용성, 오토스케일링이 보장되어 안정된 운영 가능
  • 추후 서비스 확장이 매우 손쉽게 이루어짐
  • 로그/메트릭 데이터 중앙 수집 가능해졌으며 추후 유의미한 데이터 분석이 가능.
 
아키텍처를 비용에 맞춰 설계하는 과정을 진행해보면서, DevOps나 Cloud Solution Architect 등의 직무, task의 중요도를 잘 알게되었던 것 같습니다.
1000만 사용자를 위한 AWS 클라우드 아키텍처등을 컨퍼런스나 아티클을 감상만 했을 뿐, 실제 고려하여 적용하던 적은 적었던 것 같습니다. AWS Freetier, GCP Credit, KiC 지원, 연구실 서버 무제한 사용 등으로 비용관리적인 측면에 상당히 무뎌졌는데, 이번 기회에 암묵화해서 언제든 잊지않고 잘 적용할 수 있을 것 같습니다.
 

Reference

  • 비용축소 관련해서 인프랩 포스팅을 많이 참고하였습니다.
스타트업 엔지니어의 AWS 비용 최적화 경험기
인프랩이 어떻게 월 $25,000 넘게 AWS 비용을 절약할 수 있었는지 경험과 노하우를 소개합니다.
스타트업 엔지니어의 AWS 비용 최적화 경험기
https://tech.inflab.com/20240227-finops-for-startup/
스타트업 엔지니어의 AWS 비용 최적화 경험기
  • 웹서비스를 기초로 하고 있기 때문에 천만 아키텍처 시리즈의 기본 구조를 참고했습니다.
천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기 - 이일구, AWS | AWS Builders 온라인 시리즈
AWS 클라우드는 단순하고 작은 규모의 서비스 초기에서부터 사용자가 점차 증가되는 과정에 따라 다양하게 선택할 수 있는 서비스 아키텍처를 제공해 드리고 있습니다. 고유의 서비스 규모에 따라 아키텍처에 대해 어떠한 고민이 필요하고, 또 AWS의 어떤 솔루션을 이용해서 트래픽의 증가에 대응할 수 있는지에 대해 본 강연을 통해 학습할 수 있습니다. 서비스 확장에 필요한 오토스케일링이나 네트워크 서비스, 데이터 캐시 등과 같은 다양한 분야의 고려사항을 함께 알아보고 고유 환경에 맞는 서비스를 고민하고 선택하는 것에 필요한 지식을 함께 알아볼 수 있습니다.
천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기 - 이일구, AWS | AWS Builders 온라인 시리즈
https://www.youtube.com/watch?v=fhNpjPr-f54
천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기 - 이일구, AWS | AWS Builders 온라인 시리즈