[AWS] Hybrid Cloud - AWS EC2 ↔ 온프레미스 DB 하이브리드 연결하기 (PoC) - 1. 이론/설계

 

본 포스팅에서는 대규모 엔터프라이즈 환경에서 표준으로 채택하는 '하이브리드 클라우드(Hybrid Cloud)' 아키텍처를 로컬 환경에서 재현해보고 기술적 타당성을 검증(PoC)한 과정을 담았다.

(실무에서는 보안과 성능 이슈로 AWS 환경으로 서비스를 이전하더라도 DB는 온프레미스에 두는 경우가 많다.)

---

[하이브리드 클라우드(Hybrid Cloud)' 아키텍처 구현 방식]

** 현업에 따라 다를 수 있음. 참고만!

 

1. AWS Site-to-Site VPN (가성비 & 중소규모 표준)

• 인터넷 망을 사용하지만, 암호화 기술(IPSec)을 이용해 전용 통로를 만드는 방식 (물리적 연결 없음)
• 구축 방법:
  ** 서비스/메뉴명: [VPC] -> [Virtual Private Network (VPN)]
  1. [AWS Console] 클라우드 엔지니어가 Customer Gateway(CGW)를 생성하여 온프레미스 방화벽의 IP를 등록함.
  2. [AWS Console] Virtual Private Gateway(VGW) 생성 후 연결할 VPC에 부착(Attach)함.
  3. [AWS Console] 위 두 지점을 잇는 VPN Connection(Site-to-Site VPN Connections)을 생성하고 설정 파일(구성값)을 다운로드함.
  4. [인프라 작업] 네트워크 엔지니어가 실물 방화벽 장비(L4/L7)에 접속하여 다운로드한 설정값(IPSec 키 등)을 입력하여 터널을 개통함.
  5. [AWS Console] VPC 라우팅 테이블에서 온프레미스 대역으로 가는 경로를 VGW로 지정함.
• 장점: 구축 비용이 저렴하고, 설정이 상대적으로 빠름.
• 단점: 인터넷 품질에 따라 속도가 불안정할 수 있으며, 암호화 연산으로 인한 CPU 부하 발생.
• 용도: 보조 백업 회선, 또는 트래픽이 크지 않은 서비스 연동.

2. AWS Direct Connect (대기업/엔터프라이즈 표준)

• 인터넷을 거치지 않고 데이터 센터와 AWS 사이를 물리적인 광케이블로 직접 연결하는 방식
• 구축 방법:
  ** 서비스/메뉴명: [Direct Connect]
  1. [AWS Console] 클라우드 엔지니어가 Direct Connect 연결을 신청(Connections)하고 LOA-CFA(권한 증서)를 발급받음.
  2. [인프라 작업] 통신사(KT/LG 등) 직원이 전산실까지 실물 광케이블을 인입하고 패치 패널에 연결함.
  3. [AWS Console] 연결이 활성화되면, 그 선 위에 가상 인터페이스(Private VIF)를 생성함.
  4. [인프라 작업] 네트워크 엔지니어가 전산실 라우터 장비에서 BGP 피어링(경로 공유) 설정을 완료하여 사설 IP 통신을 시작함.
  5. [AWS Console] VPC 라우팅 테이블에 전용선 경로를 추가함.
• 장점: 일관된 네트워크 성능(저지연), 최고 수준의 보안, 대량 데이터 전송 시 비용 절감.
• 단점: 초기 구축 비용이 매우 높고, 설치까지 2~4주 이상의 시간이 소요됨.
• 용도: 금융권 결제 시스템, 대규모 ERP 연동, 실시간 데이터 동기화.

 

3. AWS Transit Gateway (중앙 집중형 허브)

• 최근 대기업들이 가장 선호하는 아키텍처로, 수많은 VPC와 여러 온프레미스 지점을 중앙에서 하나로 관리 (가상 라우터 설정)
• 구축 방법:
  ** 서비스/메뉴명: [VPC] -> [Transit Gateways]
  1. [AWS Console] 클라우드 엔지니어가 중앙 허브 역할인 Transit Gateway(TGW)를 생성함.
  2. [AWS Console] 각 서비스 VPC들과 VPN/Direct Connect를 TGW에 Attachment(부착)함.
  3. [AWS Console] TGW 라우팅 테이블에서 "어느 VPC가 온프레미스 DB로 갈 수 있는지" 정책을 일괄 설정함.
  4. [AWS Console] 공유 서비스 VPC(보안/로깅용)를 별도로 두어 모든 트래픽을 검사하도록 설계함.
• 장점: 확장성이 매우 뛰어남(수백 개의 VPC 연결 가능), 복잡한 네트워크 구조를 단순화.
• 단점: 데이터 처리량에 따라 TGW 비용이 추가로 발생.
• 용도: 계열사가 많거나 서비스 규모가 큰 대기업의 전사적 클라우드 표준 아키텍처.

---

[실무에서 발생할 수 있는 이슈들 정리]

 

1. IP 대역 충돌 이슈 (IP Address Overlap)

• 실무에서 가장 빈번하고 치명적인 문제
• 실무 이슈: AWS VPC 대역(예: 10.0.0.0/16)과 온프레미스 사무실 대역(예: 10.0.0.0/16)이 똑같으면, 서버는 패킷을 어디로 보낼지 몰라 통신이 불가능해짐
• PoC에서 겪어보기: 내 로컬 사설 IP 대역과 EC2 VPC 대역을 일부러 겹치지 않게 설정해 보고, 라우팅 테이블이 어떻게 변하는지 관찰
• 해결 방안: 설계 단계에서 서로 겹치지 않는 사설 IP 대역(CIDR) 할당

2. 레이턴시와 타임아웃 (Latency & Timeout)

• 로컬 테스트는 네트워크가 아주 빠르지만, 하이브리드는 물리적 거리가 있음
• 실무 이슈: DB 쿼리 하나에 평소보다 10~50ms가 더 걸림. 트래픽이 몰리면 Connection Pool(HikariCP)이 고갈되거나 Read Timeout이 발생
• PoC에서 겪어보기: DB connection설정에서 connectionTimeout을 극단적으로 짧게(예: 500ms) 잡아보고 어떤 에러가 나는지 확인
• 해결 방안: 하이브리드 환경에선 일반적인 내부 통신보다 Timeout 값을 여유 있게 설정하고, Connection Pool 크기를 최적화 함

3. MTU 및 패킷 유실 이슈 (Path MTU Discovery)

• 실무 이슈: VPN 터널을 타면 암호화 헤더 때문에 한 번에 보낼 수 있는 데이터 크기(MTU)가 줄어듦. 큰 데이터를 조회할 때 패킷이 쪼개지다가 유실되어 연결이 뚝 끊기는 현상이 발생
• PoC에서 겪어보기: DB에서 아주 큰 이미지 데이터나 긴 텍스트(LongText)를 한 번에 조회해보기
• 해결 방안: 네트워크 장비에서 MSS Clamping 설정을 하거나, 애플리케이션에서 패치 사이즈(Fetch Size)를 조절해야 함

4. 보안 그룹 및 DB 권한 유지 (Hardening)

• 실무 이슈: PoC 때는 편의상 모든 포트를 열지만(0.0.0.0/0), 실무에선 최소 권한 원칙을 지켜야 함
• PoC에서 겪어보기: Tailscale IP 중에서도 딱 EC2의 사설 IP 1개만 DB 접속이 가능하도록 제한 (ACL 설정)
• 해결 방안: IP Whitelist 관리 프로세스를 미리 수립해야 함

---

 

이어서 2편에서는 로컬에서 하이브리드 설계를 구축해보자