운영환경, 개발환경 분리하기

배경

1월 7일 최종 테스트를 앞두고, 개발 환경과 운영 환경을 분리할 필요성이 생겼다. 기존의 개발 환경을 운영 환경으로 전환하고, 비용 효율적인 새로운 개발 환경을 구성하기로 했다.

요구사항 분석

팀에서 마주한 과제는 다음과 같았다:

1. 기존 개발 환경을 운영 환경으로 전환
2. 비용 효율적인 새로운 개발 환경 구성
3. 운영/개발 환경의 데이터 분리
4. 배포 자동화 구성

현재 시스템은 EC2에서 애플리케이션이 실행되고 있었으며, 별도의 EC2에서 Nginx가 리버스 프록시 역할을 수행하고 있었다.

운영 환경 구성

기존 개발 환경을 운영 환경으로 전환하면서 다음과 같이 설정했다:

spring:
  jpa:
    hibernate:
      ddl-auto: validate
    properties:
      hibernate:
        format_sql: false
        show_sql: false

주요 변경사항

• 데이터베이스 스키마 자동 생성 비활성화
• SQL 로깅 비활성화

개발 환경 재구성

비용 절감을 위해 Docker Compose를 활용한 로컬 데이터베이스 구성을 선택했다:

services:
  mysql:
    image: mysql:8.0
    environment:
      - MYSQL_DATABASE=${MYSQL_DATABASE}
      - MYSQL_USER=${MYSQL_USER}
    volumes:
      - mysql_data_dev:/var/lib/mysql

  redis:
    image: redis:latest
    volumes:
      - redis_data_dev:/data
    command: redis-server --appendonly yes

선택 이유

• RDS 사용 시 발생하는 불필요한 비용 절감
• Docker Compose를 통한 간편한 환경 구성

GitHub Actions 최적화

브랜치 기반의 배포 전략을 구성했다:

# 개발 환경 배포
on:
  push:
    branches: [ "dev" ]

# 운영 환경 배포
on:
  push:
    branches: [ "main" ]

개선된 점

• 브랜치별 자동 배포
• 환경별 독립적인 설정 관리

결과

이러한 설계를 통해 다음과 같은 이점을 얻었다:

1. 환경별 독립적인 데이터베이스 운영
2. 간소화된 개발 프로세스

향후 계획

현재의 운영 환경에서 단일 EC2안에 WAS와 Redis Server가 Docker Compose로 운영되고 있으나, 실제 서비스 운영 시 트래픽이 증가하면 다음과 같은 개선을 계획하고 있다:

1. Nginx를 사용한 로드 밸런싱
   • 여러 EC2 인스턴스에 트래픽을 분산하여 시스템 안정성 확보
   • 무중단 배포 지원으로 서비스 연속성 보장
2. AWS ElastiCache 도입
   • 단일 Redis 서버 장애 시 모든 EC2 인스턴스가 영향을 받는 Single Point of Failure 문제 해결
   • Redis 클러스터를 통한 고가용성 확보