"요즘 주식 자동 매매 시스템으로 야수의 심장을 가질 수 있다는데?"

개발자 => 파이썬으로 개발하고 개발자 ec2 인스턴스 하나 파면 될듯?

그래서 그냥 시작해봤다. AWS 프리티어의 제약된 리소스 안에서 비트코인, 이더리움, 리플 거래 봇과 대시보드를 띄우는게 목표다. 단순히 "돌아가는" 시스템이 아닌 확장 가능하고 운영 가능한 프로덕션 레벨의 아키텍처를 목표로 했다.

그냥 돌아가게 했다면 python3 app.py 하면 끝났을 일을 온종일 매달렸다. 처음이기에 여러 트러블 슈팅이 있었는데 이를 짚어가며 회고하고 나아가겠다.

인프라 as 코드: docker-compose.yml과 Dockerfile을 통해 전체 인프라를 코드로 관리하여 재현 가능한 배포 환경을 구축했다.

기술 스택 선정 클라우드: AWS EC2 t2.micro (프리티어)

컨테이너: Docker + Docker Compose

백엔드: Python 3.12 + pyupbit API

대시보드: Streamlit

데이터베이스: SQLite (경량화)

CI/CD: GitHub + SSH 기반 배포

AWS ec2 프리티어 클라우드 서버

AWS 프리티어는 월 750시간의 t2.micro 사용량만을 무료로 제공한다. 5개의 독립적인 ec2 인스턴스를 운영하면 월 20-50달러의 비용이 발생하지만, 단일 인스턴스 활용 시 무료 운영이 가능했다.

하지만 여기서 아키텍처를 결정해야 했다. 5개의 서비스를 어떻게 격리하면서도 효율적으로 관리할 것인가? 역시 답은 컨테이너 기반 마이크로서비스 아키텍쳐였다.

Docker compose : 오케스트레이션의 예술

docker compose를 선택한 이유는 단순히 컨테이너를 관리하는 도구 이상의 의미가 있다. 5개의 거래 시스템을 독립적으로 개발, 배포, 확장 할 수 있는 기반을 제공한다.

핵심 이점 서비스 격리: 각 거래 봇은 독립적인 컨테이너에서 실행되어, 한 서비스의 장애가 다른 서비스에 영향을 주지 않습니다 리소스 제어: 메모리와 CPU 사용량을 서비스별로 제한하여 t2.micro의 1GB RAM을 효율적으로 분배할 수 있습니다 환경 일관성: 개발 환경과 운영 환경의 차이로 인한 "내 컴퓨터에서는 되는데" 문제를 원천 차단합니다 확장성: 향후 트래픽 증가 시 특정 서비스만 스케일 아웃하거나 별도 인스턴스로 분리할 수 있습니다

# 5개 서비스의 독립적 관리
services:
  bitcoin-service:
    mem_limit: 180m
    cpu_limit: 0.15
  ethereum-service:
    mem_limit: 200m
    cpu_limit: 0.2
  # ... 각 서비스별 리소스 할당

Nginx Reverse Proxy : 하이패스 진입점입니다.

5개의 서비스가 각각 8080-8084 포트에서 실행된다면, 사용자는 서비스별로 다른 포트를 기억해야한다. 더 심각한 문제는 보안 그룹에서 5개 포트를 모두 열어줘야 한다는 점인데, Nginx Reverse Proxy는 이 모든 복잡성을 해결해준다.

1. 보안 강화: 백엔드 서비스들을 외부에 직접 노출시키지 않고 Nginx 뒤에 숨김으로써 공격 표면을 최소화합니다
2. SSL 터미네이션: HTTPS 암호화/복호화를 Nginx에서 처리하여 백엔드 서비스의 부하를 줄입니다
3. 로드 밸런싱: 향후 같은 서비스의 여러 인스턴스 간 트래픽 분산이 가능합니다
4. 캐싱: 정적 콘텐츠와 API 응답을 캐싱하여 응답 속도를 향상시킵니다
5. 모니터링: 모든 요청이 Nginx를 거치므로 중앙집중식 로그 관리와 메트릭 수집이 용이합니다

# 단일 포트(80)로 모든 서비스 접근
server {
    listen 80;
    
    location /bitcoin/ {
        proxy_pass http://bitcoin-service:8080/;
    }
    
    location /ethereum/ {
        proxy_pass http://ethereum-service:8081/;
    }
    
    location /dashboard/ {
        proxy_pass http://dashboard:8082/;
    }
}

메모리 최적화 :Swap

t2.micro 의 1GB RAM으로 5개의 pythone 애플리케이션을 구동하는 것은 이론적으로 불가능해보였다. 하지만 2GB Swap 메모리 설정과 컨에티너 별 메모리 제한을 통해 총 3GB의 가용 메모리를 확보했다.

# Swap 메모리 설정으로 메모리 한계 극복
sudo fallocate -l 2G /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

결론

그냥 실행해서 돌리긴 쉽다. 근데 앞으로 확장성을 고려하는데 문제가 생긴다.

효과적으로 파이썬 서버를 운영하기 위한 고민을 시작해본다.