GKE 인프라 학습 시리즈에서 GKE에 직접 서비스를 띄우고 비용을 줄이는 이야기까지 왔었다. 그 뒤 개인 앱은 비용 문제로 Cloud Run으로 한 번 옮겼는데, 이번엔 방향을 다시 틀어 Oracle Kubernetes(OKE)라는 상시 가동 환경으로 넘어간다. 이번 글은 그 전환의 배경과 전체 로드맵을 정리하는, 시리즈의 새 챕터 여는 편이다.
지금까지의 배포 여정
개인 앱은 아래 순서로 배포 환경을 옮겨 왔다. 1~3번은 완료했고, 지금부터 4번(OKE)을 직접 서비스 테스트를 목표로 진행한다.
| # | 단계 | 환경 | 상태 | 메모 |
|---|---|---|---|---|
| 1 | 내부 PC 테스트 | 로컬 docker-compose | ✅ 완료 | 기능 검증 |
| 2 | GKE 배포 | Google Kubernetes Engine | ✅ 완료 | 이 시리즈에서 다룸 |
| 3 | Cloud Run 배포 | Google Cloud Run | ✅ 완료 | 비용 때문에 GKE에서 이동 |
| 4 | OKE 배포 | Oracle Container Engine for K8s | ⏳ 진행 | 상시 가동 + 서비스 테스트 |
왜 Cloud Run을 떠나 다시 상시 가동 쿠버네티스로?
Cloud Run은 요청 기반 과금에 스케일 투 제로라, 트래픽이 없을 땐 아주 저렴하다. GKE의 상시 노드 비용이 부담될 때 옮겨간 이유도 그것이었다. 그런데 이 앱의 다음 목표가 바로 그 모델과 어긋난다.
| 이유 | 내용 |
|---|---|
| 채팅 = 상시 연결 | 채팅은 요청-응답이 아니라 연결을 계속 유지하는 stateful 기능이다. 스케일 투 제로·요청 수명 제한이 있는 환경에선 실제 서비스처럼 검증하기 번거롭다 → 상시 가동 노드 위에서 붙여 테스트 |
| 앱 런칭 경험 | 자체 개발 앱을 상시 가동 환경에 올려 런칭해 보는 경험 자체가 목표. 클러스터·인그레스·도메인·배포 파이프라인을 끝까지 한 번 통과시켜 본다 |
| 비용 통제 | OCI 서울 리전 유료 계정 한도(E4.Flex) 안에서 소규모 상시 클러스터를 운영해 상시 가동 비용을 관리 |
정리하면 — “요청이 있을 때만 뜨는” Cloud Run은 채팅처럼 계속 붙어 있어야 하는 기능엔 맞지 않는다. 그래서 다시 상시 가동되는 쿠버네티스로, 이번엔 비용을 감당할 수 있는 OCI(OKE)로 옮긴다. WebRTC(음성/영상)는 이번 범위에 넣지 않고, 먼저 텍스트 채팅을 상시 환경에서 검증한 뒤 별도로 진행한다.
전환 원칙 — 클라우드 provider 계층만 교체한다
이번 전환에서 가장 마음에 드는 부분. 인프라를 클라우드 provider 계층과 쿠버네티스 계층으로 분리해 두면, GCP→OCI 전환은 provider 계층만 갈아끼우면 된다. 그 위(ArgoCD·Traefik·서비스 배포)는 provider와 무관하게 그대로 재사용된다.
GCP: gke-init ─┐
├─→ k8s-init → argocd → traefik → service-deploy
OCI: oke-init ─┘ (이 계층은 provider 무관, 재사용)GKE ↔ OKE, 뭐가 다른가
| 개념 | GCP (GKE) | OCI (OKE) |
|---|---|---|
| CLI | gcloud |
oci |
| 프로젝트 경계 | Project | Compartment + Tenancy |
| 레지스트리 | Artifact Registry | OCIR |
| 네트워크 | 기본 VPC | VCN + public/private 서브넷 + IGW/NAT (클러스터보다 먼저 생성) |
| CI 자격증명 | Workload Identity Federation (GitHub OIDC) |
전용 배포 IAM 유저 + Auth Token → GitHub Secrets |
특히 두 가지가 GKE와 체감이 다르다. ① OCI는 클러스터 전에 네트워크(VCN)가 존재해야 한다(GCP는 기본 VPC로 대충 넘어갔다). ② OCI엔 GitHub OIDC(WIF) 같은 1급 연동이 없어서, 배포 전용 유저 + Auth Token을 만들어 GitHub Secrets에 넣는 방식으로 CI를 붙인다.
전체 로드맵
| Phase | 할 일 |
|---|---|
| 0. 사전 준비 | 유료 계정·서울 리전·E4.Flex 한도 확인, 컴파트먼트 생성 + OCID 복사 |
| 1. 인증 | oci-cli 설치, API 키 방식 인증(만료 없음), oci iam region list로 확인 |
| 2. 프로비저닝 | 스크립트로 OCIR → VCN → OKE 클러스터 → 노드풀 → IAM 한 번에 (dry-run 먼저) |
| 3. kubeconfig 연결 | oci ce cluster create-kubeconfig → kubectl get nodes |
| 4. 서비스 배포 | ArgoCD·Traefik, 앱 이미지 OCIR push, 배포 + 도메인 연결 |
| 5. 채팅 테스트 | 상시 가동 노드 위에서 채팅(상시 연결) 검증 — 재접속·다중 클라이언트 |
| 6. 앱 런칭 | 채팅 붙은 상태로 런칭 플로우 통과, 운영 관측(로그·리소스·비용) |
목표 클러스터는 app-staging(서울 리전, VM.Standard.E4.Flex 2 OCPU/16GB × 3노드)이다. Phase 0~1은 콘솔·로컬 준비, Phase 2부터가 실제 프로비저닝이다.
다음 편 예고
이번 편은 “왜, 어디로”를 정리했다. 다음 편부터는 실제로 손을 움직인다.
- OCI 인증 + 프로비저닝 스크립트로 OKE 클러스터 올리기 (Phase 2)
- GKE와 다른 지점 — VCN 네트워크·IAM·OCIR 뜯어보기
- kubeconfig 연결부터 앱 배포까지 (Phase 3~4)
- 상시 가동 환경에서 채팅 붙여 테스트하기 (Phase 5~6)
GKE에서 배운 쿠버네티스 개념이 provider만 바뀐 채 얼마나 그대로 재사용되는지, 그리고 OCI만의 결(네트워크 선행·Auth Token)이 어디서 튀어나오는지를 다음 편들에서 하나씩 짚어 보겠다.
— 정성원 · seongwon.net · OKE 인프라 학습 시리즈
답글 남기기