Oracle Cloud로 구축한 Spring Boot 서비스 인프라 아키텍처 — Active-Standby, VCN Peering, CI/CD 자동화

---

🙋 들어가며

안녕하세요! 이번 글에서는 아이돌 굿즈 중고거래 서비스를 개발하면서 구축한 Oracle Cloud Infrastructure(OCI) 기반의 전체 서버 인프라를 소개해드리려 합니다.

처음에는 AWS를 고려했지만, 프리 티어 제한과 비용 문제로 Oracle Cloud의 Always Free 인스턴스를 선택했습니다. 4 OCPU + 24GB 메모리까지 무료로 사용할 수 있다는 점이 가장 큰 이유였습니다.

이 글에서 다룰 내용은 아래와 같습니다.

• 전체 인프라 구조 (VCN, 서브넷, Active-Standby 운영 서버)
• 네트워크 보안 설계 (Security List, NSG, Bastion)
• CI/CD 파이프라인 (Jenkins 자동화)
• 모니터링 스택 구성

---

🏗️ 1. 전체 인프라 구조 한눈에 보기

전체 인프라는 Oracle Cloud 기반으로 설계했으며, 역할에 따라 서버를 명확히 분리했습니다.

서버	역할	구동 서비스
goody-dev-server	개발 서버	Spring Boot, Redis
goody-prod-server-main	운영 서버 (Active)	Spring Boot, Redis
goody-prod-server-sub	운영 서버 (Standby)	Spring Boot, Redis
goody-monitoring-server	모니터링 / CI-CD 서버	Jenkins, Prometheus, Grafana, Loki, Tempo

 

운영 서버는 Active-Standby 구조로 구성했습니다. 평소에는 Active 서버만 트래픽을 처리하고, 장애 발생 시 OCI 로드밸런서의 Backup 기능에 의해 자동으로 Standby 서버로 트래픽이 전환됩니다.

Redis는 각 서버에 개별로 설치했습니다. 공유 Redis를 두면 그 자체가 단일 장애점(SPOF)이 되어 Active-Standby 이중화의 목적에 반하기 때문입니다. Redis에 저장하는 데이터가 캐싱 정보뿐이라 장애 시 DB 재조회로 충분히 복구 가능하므로, 별도 Redis를 운용해도 서비스 안정성에 영향이 없을거라 판단하여 그렇게 구성했습니다.

추가로 개발/모니터링 서버와 운영 서버는 서로 다른 VCN에 위치하기 때문에, 기본적으로는 내부 통신이 불가능합니다. Jenkins(모니터링 서버)에서 운영 서버로 배포를 수행하려면 두 VCN 간 연결이 필요하며, 이를 OCI Local Peering Gateway로 해결했습니다.
참고로 Local Peering 연결을 위해서는 두 VCN의 CIDR 대역이 겹치지 않아야 하며, 이 프로젝트에서는 개발/모니터링 VCN을 10.0.0.0/16, 운영 VCN을 10.2.0.0/16으로 설정해 중복 없이 구성했습니다.

---

Cross-Tenancy Local Peering 설정 순서 (Local VCN Peering using Local Peering Gateways)

OCI의 VCN Peering은 구성에 따라 방식이 다릅니다.

구분	방법
같은 region, 같은 tenancy	LPG만으로 연결
같은 region, 다른 tenancy	LPG + IAM 정책문 (Acceptor/Requestor)
다른 region	DRG (Dynamic Routing Gateway) 사용

이 프로젝트는 같은 region이지만 서로 다른 tenancy에 VCN이 존재하는 경우로, LPG와 IAM 정책문을 함께 설정해야 합니다.

1. 각 tenancy의 VCN에 LPG 생성

2. 각 tenancy에 IAM 정책문 추가

Requestor 측: 상대 tenancy의 LPG에 연결 요청을 허용하는 정책 (내 그룹이 상대 테넌시에 접근하도록 허용)

 

Acceptor 측: 요청 tenancy의 LPG 연결을 수락 허용하는 정책 (상대 테넌시의 그룹이 내 쪽에 접근하도록 허용)

3. Requestor가 Acceptor의 LPG OCID를 입력해 연결 요청 → 정책문이 올바르면 자동 수락

4. 각 VCN 라우트 테이블에 경로 추가

• 개발 VCN 라우트 테이블: 10.2.0.0/16 → 개발 VCN의 LPG
• 운영 VCN 라우트 테이블: 10.0.0.0/16 → 운영 VCN의 LPG

5. NSG에 양방향 보안 규칙 추가

• 모니터링 서버(Jenkins) NSG — 송신 (Egress): TCP 22 → <운영 서버 private IP>/32 허용
• 운영 서버 NSG — 수신 (Ingress): TCP 22 ← <모니터링 서버 private IP>/32 허용

이 설정으로 Jenkins(모니터링 서버)가 SSH를 통해 운영 서버에 직접 배포 명령을 실행할 수 있습니다.

---

🔐 2. 네트워크 보안 설계

VCN 및 서브넷 구성

VCN은 CIDR 10.0.0.0/16으로 설정했고, 퍼블릭 서브넷과 프라이빗 서브넷으로 분리했습니다.

서브넷	CIDR	역할
퍼블릭 서브넷	10.0.0.0/24	로드밸런서, Bastion 서버
프라이빗 서브넷	10.0.1.0/24	API 서버, 모니터링 서버

주요 서버들은 모두 프라이빗 서브넷에 배치해 외부에서 직접 접근이 불가능하도록 했습니다. 외부 트래픽은 반드시 로드밸런서를 통해서만 들어올 수 있어요.

Security List vs NSG

OCI에는 보안 규칙을 설정하는 방법이 두 가지 있습니다.

• Security List: 서브넷 단위로 적용되는 레거시 방식
• NSG (Network Security Group): 인스턴스 단위로 세분화된 보안 제어

두 가지를 함께 사용해 이중 계층 보안 구조를 구성했습니다. 트래픽은 두 계층을 모두 통과해야 인스턴스에 도달합니다.

• Security List(서브넷 단위): 허용할 포트 범위를 1차로 필터링
  프라이빗과 퍼블릭 서브넷을 나누어 서로 다른 보안목록(Security List) 적용

• NSG(인스턴스 단위): 특정 IP로 접근을 추가 제한하는 2차 세밀 제어
  각 인스턴스 별로 서로 다른 보안그룹(NSG) 적용

Bastion 서버를 통한 SSH 접근

프라이빗 서브넷의 서버들은 외부에서 직접 SSH 접속이 불가능합니다. 대신 퍼블릭 서브넷의 Bastion 서버를 경유해서만 접속할 수 있도록 설계했습니다.

또한 SSH 접속 시 ProxyJump를 사용해 한번에 접속하기 위해 ~/.ssh/config 파일을 아래와 같이 설정해두었습니다.

# Bastion 서버
Host bastion
  HostName <Bastion 공인 IP>
  User ubuntu
  IdentityFile ~/.ssh/goody_server_key
  ForwardAgent yes

# 개발 서버 (ProxyJump via Bastion)
Host private-server1
  HostName <개발 서버 private IP>
  User ubuntu
  IdentityFile ~/.ssh/goody_server_key
  ProxyJump bastion

# 모니터링 서버
Host private-server2
  HostName <모니터링 서버 private IP>
  User ubuntu
  IdentityFile ~/.ssh/goody_server_key
  ProxyJump bastion

이 설정으로 ssh private-server1 명령만으로 Bastion을 자동 경유해 프라이빗 서버에 접속할 수 있습니다.

로드밸런서 포트 구성

OCI 로드밸런서는 리스너(Listener)와 백엔드 집합(Backend Set)을 1:1로 매핑하는 구조입니다. 리스너는 외부에서 트래픽을 수신하는 포트를 정의하고, 백엔드 집합은 트래픽을 전달할 내부 서버와 포트를 정의합니다.

리스너 포트	대상 서버 : 포트	용도
8080	goody-server-001 : 80 (Nginx)	API 서버
8888	goody-server-002 : 8080	Jenkins
3000	goody-server-002 : 3000	Grafana
5601	goody-server-002 : 5601	Kibana
9200	goody-server-002 : 9200	Elasticsearch

외부에서는 로드밸런서의 공인 IP + 포트로 접근하고, 로드밸런서가 내부 서버로 트래픽을 전달하는 구조입니다.

---

🚀 3. CI/CD 파이프라인

GitHub에 코드를 Push하면 GitHub Webhook을 통해 Jenkins Pipeline이 자동으로 실행됩니다.

GitHub Push → GitHub Webhook → Jenkins Pipeline 자동 실행 → JAR 빌드 → Docker Image 빌드 → 서버 배포

main브랜치와 dev브랜치에 머지가 되면 각각 prod서버와 dev서버로 배포가 되도록 설정했으며, 빌드부터 배포까지 전 과정을 Jenkins로 자동화했습니다.

---

📊 4. 모니터링 스택

모니터링은 시스템 모니터링과 사용자 로그 분석 두 가지 목적으로 구분하여 구성했습니다.

• 시스템 모니터링: 각 서버의 애플리케이션이 OpenTelemetry Protocol로 메트릭/로그/트레이스를 전송하면, 모니터링 서버의 Prometheus + Grafana Loki + Grafana Tempo + Grafana 스택에서 수집·시각화합니다. 이상 감지 시 Slack 알림이 자동으로 발송됩니다.
• 사용자 로그 분석: 애플리케이션 로그를 Filebeat로 수집해 Elasticsearch에 저장하고, Kibana로 시각화하여 분석합니다.

---

🔎 5. 마무리 — 회고 & 개선점

이번 인프라를 구축하면서 가장 어려웠던 부분은 OCI의 보안 정책 설정이었습니다. AWS와 달리 Security List와 NSG가 따로 존재하고, 둘 다 통과해야 트래픽이 들어올 수 있어서 초반에 포트가 안 열리는 문제로 한참 헤맸어요.

특히 Security List와 NSG 규칙을 모두 올바르게 추가했는데도 접근이 안 되는 경우가 있었는데, 원인은 인스턴스 OS 레벨의 iptables 규칙이었습니다. OCI 네트워크 규칙을 모두 통과하더라도 OS 방화벽에서 한 번 더 차단될 수 있다는 점을 처음에는 몰랐서 원인 파악에 시간이 꽤 걸렸습니다.

현재 한계 및 개선 예정 사항

• NSG 일부 포트 (Jenkins, Grafana, Kibana 접근 포트)를 현재 0.0.0.0/0으로 열어둔 상태 → IP 제한으로 수정 예정