이동형

전체 인프라를 AWS에서 운영하던 중 월 $60,000의 높은 클라우드 비용이 발생하여 비용 최적화가 필요했습니다.

워크로드별 비용 분석을 수행한 결과, 개발·테스트 환경은 트래픽 변동이 적어 클라우드의 자동 스케일링이 불필요했고, QA·Production 환경만 확장성과 안정성이 요구되는 상황이었습니다. 이에 개발·테스트 환경은 온프레미스로 전환하고, QA·Production 환경은 AWS에 유지하는 하이브리드 아키텍처를 설계했습니다.
양쪽 환경은 VPN 없이 역할을 분리해 독립 운영(앱 트래픽 분리)하며, 이미지 레지스트리도 환경별로 분리(개발=Harbor, QA·Production=ECR)해 아키텍처 차이에 맞춰 각 환경에서 독립적으로 빌드했습니다. 양쪽 환경 모두 Terraform과 Ansible을 활용한 IaC 통합으로 운영 표준을 일원화(신규 컴포넌트 IaC 100%, IAM 제외)하여, 운영 복잡도 증가 없이 일관된 인프라 관리를 실현했습니다.

개발자가 수동으로 빌드 후 서버에 배포하는 방식으로, 배포 시 평균 30분이 소요되었으며 휴먼 에러로 인한 장애가 빈번하게 발생했습니다.

GitLab CI와 ArgoCD를 조합한 GitOps 기반 자동 배포 환경을 구축했습니다. 개발자가 Git Push만 하면 자동으로 빌드→테스트→배포가 진행되며, ArgoCD가 Kubernetes 클러스터 상태를 모니터링하여 선언적 배포를 수행합니다.
Kaniko를 활용한 Docker 이미지 빌드로 Docker-in-Docker 의존성을 제거하고, 멀티 환경(alpha/review/dev/staging) 배포를 단일 파이프라인에서 관리하도록 구성했습니다.

온프레미스 환경에서 서버 및 컨테이너 로그가 분산되어 있어 장애 발생 시 원인 파악에 많은 시간이 소요되었으며, 통합 모니터링 체계도 없었습니다.

Phase 1 (ELK 구축): Elasticsearch, Logstash, Kibana, Filebeat를 활용한 중앙 집중식 로깅 시스템을 구축했습니다. 모든 서버와 컨테이너의 로그를 Filebeat로 수집하고, Logstash에서 JSON 파싱 및 필드 매핑을 처리한 뒤 Elasticsearch에 저장하여 Kibana 대시보드로 실시간 모니터링 및 검색이 가능하도록 했습니다.
Phase 2 (EFK 전환): Logstash JVM 메모리 부담(1GB+), Filebeat의 Helm 생태계 불일치, 로그 파이프라인 커스텀 확장성 한계를 해소하기 위해 Fluent Bit + Fluentd 기반 EFK Stack으로 전환했습니다. C 기반 경량 수집기인 Fluent Bit이 DaemonSet으로 각 노드에서 Kubernetes 메타데이터 자동 태깅과 함께 로그를 수집하고, Fluentd가 멀티 output을 지원하는 로그 가공/필터링을 처리한 뒤 Elasticsearch로 전달하는 구조로 리팩토링했습니다. 차트 업그레이드 자동화 스크립트를 개발하여 upstream Helm 차트 자동 업그레이드 시 커스텀 PVC 템플릿을 보존하도록 구성했습니다.
Phase 3 (ECK Operator 전환 + Stack 9.0 major upgrade): Elastic 공식 Helm Chart 업데이트가 2년 이상 중단되고 CRD 기반 선언형 관리(ECK)가 주류로 전환됨에 따라, Elastic Stack을 8.5.1에서 9.0.0으로 major upgrade하고 ECK Operator 3.3.2를 elastic-system 네임스페이스에 도입했습니다.
Elasticsearch/Kibana를 Custom Resource로 재정의하고 로컬 차트(CR wrapper) 형태로 관리하여 repo convention과 정렬했으며, 병렬 배포(monitoring → logging 네임스페이스) 후 cutover 전략을 채택하여 무중단 전환을 수행했습니다.
ECK 기반 체계에서는 TLS 인증서 자동 발급/회전(1년 / 30일), elastic 계정 패스워드 Helm template 관리, CR spec.version 한 줄 변경으로 완료되는 롤링 업그레이드 체계를 확립하여 수동 운영 부담을 제거했습니다.

개발팀의 반복적인 수동 작업을 자동화하고 생산성을 높이기 위해, 5가지 사내 도구를 설계·개발·운영했습니다.

클러스터 가시성, 운영 안정성, 네트워크 고도화, 스토리지 성능, 자동화 코드 품질을 목표로 모니터링 체계를 고도화하고 K8s 업그레이드·Helm 관리를 자동화했으며, 네트워크 컨트롤러를 Gateway API 기반으로 마이그레이션했습니다. NGF 마이그레이션과 ECK Operator 도입의 산출물을 OSS Helm 차트로 공개하고, control-plane / DB 노드의 SSD 마이그레이션 및 빌드 I/O 격리로 스토리지 성능 병목을 해소했으며, 인프라 배포/업그레이드 파이프라인을 단계별(wave) 순차 자동화 + Shell → Python 마이그레이션으로 정비했습니다.

인프라 운영에 필요한 민감 정보를 안전하게 관리하기 위한 보안 체계를 구축하고 있습니다.

GitLab CI 표준화 범위 안의 15개 repo(1개 template provider + 14개 consumer)에서 각 잡이 alpine 베이스에 helm·helmfile·kubectl·crane·aws-cli 등을 매번 설치하면서 첫 번째 잡 준비 시간이 평균 5분에 달했고, 도구 버전이 14개 consumer repo에 흩어져 있어 신버전 추가 시 일괄 갱신이 사실상 불가능했습니다. :latest 태그 의존으로 재현성이 떨어지고 취약점 추적도 어려웠습니다.

Layer 1 (Mirror): 외부 레지스트리(Docker Hub, GHCR)의 도구 이미지를 crane copy로 사내 Harbor에 multi-arch manifest 보존 미러링.
Layer 2 (Custom): Layer 1 위에 도구가 사전 설치된 fat image 7종(helmfile-tools, node-build, go-build, rclone-backup, aws-cli-tools, kaniko-build, terraform-tools)을 빌드해 consumer repo가 image pin만으로 도구를 즉시 사용할 수 있도록 표준화.
Tier 1~2 SSOT: gitlab-ci-templates에 .toolchain_build_custom 공용 template + TOOLCHAIN_*_TAG 중앙 변수를 도입해 consumer repo는 image tag를 직접 추적하지 않도록 간접화.
Phase 4 자동 사이클: cron 트리거로 다음 4단계가 자동 진행되어 사람의 수동 click 2회(pipeline trigger + Tier 2 MR merge)만으로 연쇄 전파 완성:
   · (1) upstream 신버전 감지
   · (2) Layer 1 mirror auto-MR
   · (3) Layer 2 rebuild + Tier 2 TOOLCHAIN_*_TAG 동기화 auto-MR
   · (4) 14개 consumer repo(template provider repo 제외)에 자동 전파

Phase 3 ECK 전환 후 운영 중 Fluent Bit Pod 재시작 시 tail input의 in-memory offset이 사라지면서 동일 로그 재색인 / 로그 누락 위험이 발견되었습니다. 또한 단일 replica + PDB·preStop hook 부재로 노드 drain 시 짧은 수집 공백이 발생했고, 수집기 자체를 모니터링하는 알림 규칙이 없어 장애가 감지되지 않을 가능성이 있었습니다.

Tier 1 (데이터 무결성): tail input plugin에 SQLite offset DB(db /var/log/flb-storage/tail.db)를 도입하고 전용 PVC(2Gi)를 마운트해 Pod 재시작 후에도 offset이 보존되도록 구성. helmfile revision 4에서 동일 로그 재색인 0, 중복 0 검증 완료.
Tier 2 (가용성): PodDisruptionBudget(minAvailable=1), preStop hook(sleep + flush), liveness/readiness probe(/api/v1/health) 추가로 노드 drain·롤링 업데이트 중 수집 공백 최소화.
Tier 3 (모니터링): PrometheusRule 7개 alert(input/output 실패율, retry 누적, fluentd queue 압력, fluent-bit Pod down, SQLite DB write fail 등) 추가로 감지되지 않던 장애를 사전 포착.
Tier 4 (HA 옵션 문서화): 향후 확장을 위한 3가지 옵션(입력 path 분할 / 사이드카 / Vector 멀티 수집기) 비교 문서화.

AWS 비용이 지속적으로 상승하고 있었으며(월 $10,000+), 특히 NAT Gateway와 데이터 전송 비용이 높았습니다. 마침 GCP Startup Program 참여 기회가 생겨, 비용 절감과 멀티 리전 게임 서비스를 위한 글로벌 로드밸런싱 확보를 목표로 GCP 마이그레이션을 추진했습니다.

3단계 마이그레이션 전략을 수립해 단계별로 실행했습니다. 1단계로 개발 환경을 GCP에 먼저 구축하여 검증하고, 2단계로 QA 환경을 이전한 뒤, 3단계로 프로덕션 환경을 이전했습니다.
네트워크 설계는 Shared VPC (Host Project / Service Project 분리) 기반으로 구성하고, GitHub Actions 의 GCP 인증은 Workload Identity Federation 으로 전환하여 서비스 계정 키 발급/순환 부담을 제거하고 OIDC 기반 단명 토큰으로 대체했습니다. DNS 는 서브도메인 위임 (Hosting.kr → AWS Route53 → GCP Cloud DNS) 으로 사전 검증 단계를 거친 뒤, 최종 NS 변경 시점에만 점검 공고 후 cutover 를 수행했습니다. Filestore 의 SSD 최소 2.5TB 비용 문제는 Compute Engine + pd-balanced 1TB 디스크 기반 NFS 서버 자체 구축으로 우회하여 운영 비용을 최소화했습니다. Cloud Armor 로 region 차단 + IP 화이트리스트 WAF 정책을 구성하고, Cloud CDN 의 URL Map 을 HTTP / HTTPS 두 개로 분리하여 HTTP → HTTPS 강제 리다이렉트와 정적 자산 캐싱을 함께 활성화했습니다.
Terraform 으로 GCP 인프라를 IaC 화 (IAM 제외 100%) 하고, 마이그레이션 완료 후 GitLab CI 와 ArgoCD 를 조합한 GitOps 기반 CI/CD 파이프라인을 구축했습니다. Helm Chart 로 환경별 설정을 표준화하고 Git 커밋 기반 배포 이력 관리 체계를 확립했습니다.

게임 및 블록체인 데이터를 수동으로 수집하고 있어 분석가가 매일 2~3시간을 데이터 수집에 소비했으며, 휴먼 에러로 인한 데이터 누락이 빈번하게 발생했습니다.

MongoDB · CloudSQL · Google Analytics · Dune 등 멀티 데이터 소스를 BigQuery 로 적재하고, 분석가용 Google Sheets 까지 자동 갱신되는 데이터 파이프라인을 GCP 서비스 조합으로 구축했습니다. MongoDB 는 Dataflow Flex Template 기반 ETL 로 BigQuery 에 적재하고, CloudSQL 은 BigQuery 의 직접 connection 기능을 활용하며, GA / Dune 은 각자의 API (Dune 은 별도 API Key) 로 호출하여 일관된 인덱스 스키마로 정규화했습니다.
Python Cloud Function 이 BigQuery 쿼리 결과를 Google Sheets API 로 적재하고, Cloud Scheduler 가 Daily (전일 데이터) / Monthly (전월 데이터) 두 가지 주기로 자동 트리거합니다. BigQuery 적재 후에는 별도 중복 제거 Cloud Function 이 정기 실행되어 데이터 정합성을 유지합니다. 전체 인프라 (BigQuery Dataset · Cloud Function · Scheduler · Cloud Storage · Artifact Registry · IAM 권한 · Service Account) 는 Terraform 으로 IaC 관리하여 환경 재구축과 변경 추적을 표준화했습니다.

Kubernetes 클러스터와 애플리케이션의 실시간 모니터링 체계가 없어 장애 발생 시 사후 대응만 가능했으며, 원인 파악에 과도한 시간이 소요되었습니다.

Prometheus로 메트릭을, Loki로 로그를 수집하여 Grafana 대시보드로 통합 시각화하는 PLG Stack을 구축했습니다. CPU·메모리·네트워크 사용률과 애플리케이션 로그를 실시간으로 모니터링하고, 임계치 초과 시 Slack 알림을 자동 발송하도록 구성했습니다.

고객사마다 요구하는 환경과 서버 스펙이 상이하여, 표준화된 솔루션으로는 대응이 어려웠습니다.

고객사 요구사항에 맞춰 Kubernetes 클러스터를 HA(High Availability) 구성으로 설계하고, OpenStack으로 가상머신 관리 환경을 구축했습니다. Ceph로 블록·파일·오브젝트 스토리지를 통합 제공하고, 고객사 운영팀에 인프라 운영 교육을 병행했습니다.

DP사 운영팀이 Kubernetes·컨테이너 기반 인프라 운영 경험이 부족하여, PaaS 솔루션 도입 후 자체 운영에 어려움이 예상되었습니다.

Kubernetes 기초부터 클러스터 운영·트러블슈팅까지 단계별 교육 커리큘럼을 설계하고, 실습 환경을 구성해 실무 중심으로 운영했습니다. OpenStack·Ceph 스토리지 운영 교육도 병행해 전체 PaaS 스택 운영 역량을 확보하도록 도왔습니다.

Kubernetes 클러스터 인증서가 1년마다 만료되어 고객사마다 연간 약 5시간의 갱신 작업이 필요했으며, 만료 시 서비스 장애가 발생할 위험이 있었습니다.

Kubernetes 인증서 관리 프로세스를 분석하고, kubeadm 설정을 수정하여 인증서 유효기간을 1년에서 10년으로 연장했습니다. 기존 운영 중인 클러스터에도 적용 가능한 자동화 스크립트를 개발하여 전체 고객사에 배포했습니다.