온프레미스에서 클라우드로: 우당탕탕AWS 마이그레이션 실전기

온프레미스에서 AWS 클라우드로 이전하며 멀티 VPC·EKS·RDS·MSK를 적용한 올라핀테크 데이터엔지니어링팀의 클라우드 마이그레이션 사례입니다. 가용성 99.95% 달성, 배포 시간 1시간→10분 단축, 보안·운영 자동화·비용 최적화까지 정리했습니다.

“작은 불편에서 출발해, 모두가 편해지는 순간까지. 올라핀테크 팀의 이야기를 공유합니다.”

핀테크 기업의 온프레미스에서 AWS 클라우드로 전환 과정을 표현한 3D 일러스트. 서버에서 클라우드로 데이터가 이동하는 클라우드 마이그레이션 개념 이미지.

AWS클라우드 마이그레이션은 선택이 아닌 필수

클라우드 마이그레이션은 필수

디지털 전환의 시대에서 클라우드 마이그레이션은 더 이상 선택이 아닌 필수입니다. 특히 저희처럼 핀테크 서비스를 운영하고 있다면 안정성과 확장성, 그리고 보안성이 더더욱 중요한데요. 이는 클라우드 전환 자체가 곧 비즈니스 성장에 직결되는 핵심 동력이라는 말이기도 합니다.

저희가 운영하고 있는 당시 “올라 선정산” 서비스 또한 2025년 내 기존 선정산 서비스의 편의성 및 안정성 극대화부터 초간편 자금관리 서비스로의 확장까지 계획되어 있었는데요. 다양하고 빠른 변화가 필요한 환경에 맞춰 대응하기 위해 기존의 온프레미스 환경에서 AWS 클라우드로의 전환을 결정했습니다.

마이그레이션 전 온프레미스 아키텍처

저희가 운영하는 프로덕트의 온프레미스 인프라 구성은 아래와 같았어요.

웹 서버: Nginx 기반 Load Balancer
애플리케이션 서버: Spring Boot 기반 Java 애플리케이션 (다중 인스턴스)
데이터베이스: MariaDB
캐시: Redis

이 구성은 서비스의 초기 운영에는 적합했지만, 트래픽 증가와 함께 다음과 같은 한계가 드러나게 됩니다.

확장성 부족: 순간적인 자원 사용량 증가에 대응이 어려움
운영 복잡성: 배포 및 패치 시 수동 절차 다수
비용 비효율성: 유휴 자원에 대한 고정 비용 발생
보안 관리 부담: 주기적인 패치 및 보안 업데이트의 복잡성

AWS 클라우드 마이그레이션 계획을 시각화한 3D 일러스트. 개발자들이 가용성, 운영 효율화, 보안 강화, 비용 최적화를 목표로 회의 중인 장면.

AWS클라우드 마이그레이션 계획 과정

AWS 클라우드 마이그레이션 전환 계획

데이터 엔지니어링 팀은 정확한 목표를 가지고 계획을 수립해나갔습니다. 내용이 방대할 수 있습니다. 가독성이 좋게 정리했지만 참고 부탁드립니다!

#1 전환 목표

클라우드 마이그레이션을 통해 아래 네 가지 목표를 달성하고자 했어요.

고가용성 확보: 99.9% 이상의 서비스 가용성 달성
운영 효율화: DevOps 자동화를 통한 배포 및 운영 간소화
보안 강화: 관리형 인스턴스 활용으로 보안 패치 부담 완화
비용 최적화: 사용량 기반 과금으로 유휴 자원 최소화

#2 아키텍처 설계

보안 정책을 고려하여 다음과 같은 멀티 VPC 아키텍처를 설계했습니다.

VPC 구성

Security VPC: 사무실과 Site-to-Site VPN 연결, 보안 관리 중앙화
Production VPC: 운영 환경, Security VPC와 피어링 연결
Development VPC: 개발/테스트 환경, Security VPC와 피어링 연결

VPC별 구성사항

Security VPC

네트워크 프록시: 내부서비스 접속을 위한 단일 프록시 서버
내부 전용 DNS 서버: 내부서비스 도메인 질의를 위한 전용 DNS 서버

Production VPC

EKS 클러스터: Kubernetes 기반 컨테이너 오케스트레이션
RDS MariaDB: Multi-AZ 구성으로 고가용성 확보
ElastiCache Redis: 캐시 및 세션 관리
MSK (Managed Streaming for Kafka): 메시지 스트리밍
Application Load Balancer: L7 로드밸런싱 및 SSL 터미네이션

Development VPC

Production과 동일한 구성의 축소 버전
개발 및 스테이징 환경용

#3 마이그레이션 전략

마이그레이션 전략은 총 5단계, 준비기간까지 합하면 3개월 정도지만 계획은 약 1.5개월을 잡고 진행했어요.

Phase 1(2주): 인프라 구축 (VPC, EKS, RDS 등)
Phase 2(3주): 애플리케이션 컨테이너화 및 배포
Phase 3(1주): 데이터 마이그레이션
Phase 4(1일): DNS 전환 및 서비스 오픈
Phase 5(유지): 모니터링 및 최적화

#4 주요 고려사항

1. 리소스 확보

서비스 오픈 시 자원 부족으로 인한 장애 방지
기존 온프레미스 대비 120% 이상의 여유 자원 확보

2. 외부 연동 호환성

금융기관 API 등 핵심 외부 서비스와의 원활한 통신 보장
기존 IP 화이트리스트 기반 연동의 새로운 IP 대역 등록
SSL/TLS 인증서 갱신 및 도메인 설정

3. 보안 정책 준수

금융 서비스 특성상 엄격한 클라우드 보안 요구사항 충족
개인정보보호법, 전자금융거래법 등 관련 법규 준수
네트워크 분리 및 접근 제어 정책 적용

4. 서비스 중단 최소화

완전 무중단 마이그레이션보다는 계획된 다운타임 활용
주말 시간대 활용으로 사용자 영향 최소화
빠른 롤백 계획 수립

추가로 기술적인 고려 사항은 다음과 같았습니다.

컨테이너화 전략

Spring Boot 애플리케이션의 Docker 이미지 최적화
멀티 스테이지 빌드를 통한 이미지 크기 최소화

데이터 마이그레이션

서비스 규모 대비 데이터 크기가 적어 단순 백업/복원 방식 선택
마이그레이션 전 데이터 정합성 검증 절차 수립
테스트 환경에서의 사전 검증

AWS 클라우드 마이그레이션 전략

AWS 클라우드 마이그레이션 단계별 전환 과정

Phase 1: 인프라 구축 (2주)

AWS 기본 인프라 설정

- Security, Production, Development VPC 생성

- 각 VPC별 public, private 서브넷 설정

- VPC Peering 연결 설정

- Site-to-Site VPN 구성 및 연동

EKS 클러스터 구축

용도별 관리형 노드 그룹 구성
AWS Load Balancer Controller 설치

데이터베이스 및 캐시 구성

RDS MariaDB 구성
ElastiCache Redis 7 구성

Phase 2: 애플리케이션 컨테이너화 (3주)

Kubernetes 매니페스트 작성

Deployment, Service, Ingress 리소스 정의
ConfigMap 및 Secret을 통한 설정 관리

CI/CD 파이프라인 구축

각 서비스별 Dockerfile, Jib을 이용한 컨테이너화
GitHub Actions를 통한 자동 빌드/테스트
ECR (Elastic Container Registry)을 통한 이미지 관리
ArgoCD를 통한 GitOps 방식 배포

Phase 3: 데이터 마이그레이션 (1주)

데이터베이스 마이그레이션

온프레미스 MariaDB 백업 생성
AWS RDS로 데이터 복원
애플리케이션 설정 변경 (데이터베이스 연결 정보)
데이터 정합성 검증

캐시 및 설정 마이그레이션

Redis 데이터 동기화
환경별 일부 설정 값 ConfigMap으로 이관

Phase 4: DNS 전환 및 서비스 오픈 (1일)

전환 당일 프로세스

서비스 점검 공지 (토요일 오전 11시~자정까지)
최종 데이터 동기화
DNS 레코드 AWS ALB로 변경
서비스 정상 확인
모니터링 강화

Phase 5: 모니터링 및 최적화 (지속적)

모니터링 체계 구축

데이터독 오퍼레이터를 통한 연동
알람 및 대시보드 구성

성능 최적화

리소스 사용량 분석 및 인스턴스 타입 최적화

AWS 클라우드 전환 이후 성과를 시각화한 3D 일러스트. 서비스 가용성 향상, 배포 시간 단축, DevOps 자동화 등 마이그레이션 결과를 나타내는 개념 이미지.

AWS클라우드 마이그레이션의 성과

AWS 클라우드 마이그레이션의 성과

기존 온프레미스에서 클라우드 전환을 마치고 저희는 아래와 같은 성과를 얻을 수 있었어요.

가용성 향상: 99.9% → 99.95% 서비스 가용성 달성
배포 효율성: 배포 시간 1시간 → 10분으로 단축
개발 생산성: DevOps 자동화로 개발팀 효율성 향상
서비스 안정성: 장애 복구 시간 대폭 단축

마이그레이션 과정에서 겪은 문제와 해결책

단순히 성과만 얻을리가 만무하죠. AWS 클라우드로 마이그레이션하면서 겪은 문제 그리고 해결한 방법 두 가지를 소개하려고 합니다.

예상치 못한 프록시 서버 발견

문제 상황

오픈 전 테스트 과정에서 특정 외부 연동 서비스가 동작하지 않는 현상 발견
기존 온프레미스에서 특정 도메인의 특정 경로로 들어오는 연결을 내부 서버로 프록시하는 웹서버가 존재했음을 뒤늦게 발견

해결 방안

# ALB Ingress Rule 추가 설정
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: proxy-ingress
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/group.name: 'example-alb'
    alb.ingress.kubernetes.io/group.order: 1 # 다른 ingress보다 우선순위 높여주기
spec:
  rules:
  - host: external-service.domain.com
    http:
      paths:
      - path: /specific-path/*
        pathType: Prefix
        backend:
          service:
            name: forward-target
            port: 1234

서비스 오픈 후 예상보다 높은 트래픽으로 인한 병목 현상