Cloud Native MSA 플랫폼 구축

Project Overview

개요

VM 기반 모놀리스 환경을 Kubernetes 기반 Cloud Native MSA로 전환하며 Terraform 기반 IaC, Istio Service Mesh, Observability 환경과 Account Service를 구현한 프로젝트입니다.

Event-Driven Microservices

NATS JetStream을 메시지 브로커로 활용하여 서비스 간 느슨한 결합도를 확보했습니다. 메시지 보존 기능을 통해 비동기 통신의 신뢰성을 보장하고 장애 전이를 차단했습니다.

Istio Service Mesh & Observability

Istio를 도입하여 서비스 간 트래픽 제어 및 보안을 강화했습니다. Kiali로 실시간 트래픽 가시성을 확보하고, Zipkin을 통해 분산 환경에서의 E2E 추적을 구현했습니다.

비동기 트랜잭션 처리

NATS 기반의 이벤트 발행/구독 모델을 활용하여 트랜잭션 결과를 비동기로 전달하고, 성공/실패 상태를 독립적으로 업데이트하는 이벤트 처리 흐름을 구현했습니다.

Terraform Cloud Infrastructure

Terraform을 사용하여 VPC, GKE 클러스터 등 클라우드 인프라를 코드로 관리합니다. 재사용 가능한 모듈 구조로 인프라 프로비저닝 시간을 단축했습니다.

Architecture

시스템 아키텍처

GCP GKE 기반 위에 Istio와 NATS가 통합된 이벤트 주도 마이크로서비스 아키텍처

이미지를 클릭하면 확대됩니다

트래픽 및 데이터 흐름

GKE 클러스터 위에서 Ingress Gateway를 거쳐 외부 트래픽이 인입되며, Auth Service에서 인증 후 Account Service와 Transaction Service로 요청이 전달됩니다. 이후 NATS를 통해 비동기 이벤트가 발행됩니다. 이 모든 과정에서 발생하는 메트릭은 Prometheus로 수집되고, 분산 트랜잭션 추적은 Zipkin이 담당하며, 서비스 간 트래픽 흐름은 Kiali를 통해 실시간으로 시각화됩니다.

Database-per-service

각 서비스는 독립적인 논리 DB를 가지며, 서비스 간 강결합을 피하도록 설계되었습니다.

Istio Ingress Gateway & Sidecar Proxy

외부 트래픽을 안전하게 제어하고 내부 서비스 간 통신은 mTLS와 Sidecar Proxy를 통해 보안 및 관측성을 확보합니다.

Tech Stack

사용 기술

Backend

Spring Boot PostgreSQL

Infrastructure

Terraform GKE Kubernetes Istio NATS JetStream

Observability

Prometheus Kiali Zipkin

CI/CD

GitHub Actions

My Contributions

기여

Infrastructure & Observability

① Terraform 기반 GKE 인프라 구축

Terraform으로 GKE Cluster 및 Node Pool을 IaC 방식으로 구성했습니다.

코드 기반 인프라 관리로 동일한 Cloud Native 환경을 언제든 재현 가능하도록 구현했습니다.

② Istio Service Mesh 구축

Istio Ingress Gateway와 VirtualService를 구성하여 서비스 간 트래픽 라우팅을 구현했습니다.

Envoy Sidecar 기반 Service Mesh를 적용하여 애플리케이션 수준의 수정 없이 네트워크 보안과 정책을 제어했습니다.

③ Observability 환경 구축

Prometheus로 전체 시스템의 메트릭을 수집하고, Kiali에서 Service Mesh 간의 통신 트래픽을 시각화했으며, Zipkin으로 분산된 마이크로서비스 간의 트랜잭션을 추적할 수 있는 가시성 환경을 구축했습니다.

파편화된 분산 환경에서 장애 지점을 한눈에 파악하고 신속한 트러블슈팅이 가능하도록 시스템 운영 환경을 구성했습니다.

Backend Application

④ Account Service 개발

계좌 생성 및 입·출금 요청 API를 구현했습니다.

Transaction Service와 NATS 기반 비동기 메시징을 연계하여 거래 요청을 처리하고, Circuit Breaker를 통해 Fallback을 제공하는 회복 탄력성을 확보했습니다.

Problem Solving

문제 해결

Istio Protocol Detection - NATS 메시징 장애

Problem

Istio 적용 이후 NATS 브로커와 서비스 간 연결은 수립되었지만 Publish/Subscribe 통신이 정상적으로 동작하지 않는 현상이 발생했습니다.

Cause

Istio가 Service Port의 이름 client을 HTTP 프로토콜로 잘못 인식하여 L7 Protocol Sniffing을 수행하려 했고, HTTP가 아닌 바이너리 기반의 단방향 NATS 통신에서 프로토콜 미스매치로 인해 데이터 전송이 차단된 것이 원인이었습니다.

Implementation & Result

Kubernetes Service의 Port 이름을 client에서 tcp-client로 변경하여 해당 통신이 TCP 프로토콜임을 Istio 쪽에 명시적으로 알려주었습니다.
결과적으로 Envoy 프록시가 L7 스니핑 없이 L4 수준에서 패킷을 올바르게 라우팅하게 되어 NATS 메시징이 정상적으로 복구되었습니다.

Circuit Breaker 도입 - 장애 전파 방지

Problem

MSA 환경에서 하위 서비스에 장애가 발생하거나 응답 지연이 생기면, 이를 호출하는 상위 서비스의 스레드까지 고갈되어 전체 시스템으로 장애가 전파될 위험이 있었습니다.

Cause

서비스 간 동기 호출 구조에서 타임아웃 처리가 미흡할 경우, 한 서비스의 성능 저하가 의존성을 가진 다른 모든 서비스의 가용성을 떨어뜨리는 병목으로 작용하기 때문입니다.

Implementation & Result

서비스 간 통신 구간에 Circuit Breaker를 도입하여, 특정 호출의 에러율이나 지연 시간이 임계치를 초과하면 회로를 차단하고 Fallback 응답을 반환하도록 구현했습니다.
결과적으로 하위 서비스 장애가 상위 서비스로 확산되는 것을 방지하고, 사용자에게는 일관된 서비스 경험을 제공하는 회복 탄력성을 확보했습니다.

제로 트러스트아키텍처 달성을 위한 Istio 도입

Problem

기존 쿠버네티스 환경에서는 클러스터 내부의 파드 간 통신이 기본적으로 평문으로 이루어져 내부망에 침투할 경우 모든 서비스에 무방비로 접근할 수 있는 보안 취약점이 있었습니다.

Cause

Kubernetes의 기본 네트워킹 구조는 통신 연결 자체만 지원할 뿐, L7 수준의 세밀한 접근 제어나 서비스 간 암호화, 강력한 상호 인증 체계를 기본적으로 제공하지 않기 때문입니다.

Alternatives Considered

애플리케이션 레벨에서 직접 Spring Security를 통해 각 서비스 간 통신 시 JWT 토큰을 검증하거나, 내부 HTTPS 설정을 위해 TLS 인증서를 수동으로 관리하는 방안을 고려했습니다. 하지만 이는 애플리케이션 코드의 복잡성을 크게 높이고 인증서 갱신 등의 운영 부담을 가중시켰습니다.

Why This Solution

따라서 비즈니스 로직의 수정 없이 인프라 계층에서 네트워크 통제권을 확보하고 "아무도 신뢰하지 않는" 제로 트러스트보안 모델을 달성하기 위해 Istio Service Mesh를 도입하기로 결정했습니다.

Implementation

클러스터의 모든 서비스 파드에 Envoy Sidecar Proxy를 주입하여 트래픽을 가로채도록 구성했습니다. 이후 Istio의 PeerAuthentication 정책을 통해 서비스 간 통신을 상호 TLS로 강제 암호화하고, AuthorizationPolicy를 정의하여 인가되지 않은 트래픽 접근을 원천 차단했습니다.

Result

애플리케이션 코드 변경 없이 서비스 간 모든 통신 구간을 100% 암호화하여 제로 트러스트 기반의 사내 보안을 완벽히 달성했습니다. 또한 Kiali 연동을 통해 통신 상태와 에러를 한눈에 파악할 수 있는 트래픽 가시성까지 추가로 확보했습니다.

Lessons Learned

클라우드 네이티브 환경에서 보안과 네트워크 제어를 '애플리케이션'이 아닌 'Service Mesh 인프라 계층'으로 분리하고 위임하는 것이 시스템의 확장성과 유지보수성에 얼마나 큰 장점을 주는지 체감할 수 있었습니다.

Retrospective

회고

좋은 점

Cloud Native 인프라 운영 경험:
단순히 Kubernetes를 사용하는 것을 넘어, Terraform 기반의 인프라 프로비저닝, Istio Service Mesh 구축, Prometheus·Kiali·Zipkin 관측성 환경을 직접 구축하며 완전한 Cloud Native 생태계를 경험했습니다.
운영 관점의 중요성 이해:
개발에 그치지 않고 배포와 트래픽 제어, 시스템 내부 상태를 투명하게 모니터링하는 과정을 통해 플랫폼 엔지니어링 역량을 크게 향상시켰습니다.

아쉬운 점

데이터 정합성 보장의 한계:
NATS JetStream을 이용해 비동기 메시징을 구현했으나, 분산 환경에서 필수적인 완전한 형태의 SAGA 패턴까지는 적용하지 못했습니다.
에러 발생 시 전체 비즈니스 흐름을 안전하게 롤백하는 구조가 미흡했던 것이 아쉬움으로 남습니다.

추후 개선

SAGA 패턴을 통한 분산 트랜잭션 고도화:
보상 트랜잭션 로직을 도입하여, 장애 발생 시 원상 복구를 통해 시스템 간 최종 데이터 정합성을 보장하는 구조로 개선하고자 합니다.