도입 배경안녕하세요. 중고나라 DevOps 엔지니어 조상현, 김지헌입니다.복잡한 아키텍처를 개선하며, 자원 효율화를 위해 새롭게 도입한 Istio Ambient Mode에 대해 공유하려 합니다.중고나라는 회사의 성장과 함께 서비스 트래픽이 증가하면서 네트워크 관리의 중요성이 더욱 커졌습니다. 이를 해결하기 위해 Istio를 도입하여 서비스 메쉬를 구축했지만, 기존 Istio Sidecar Mode 기반 아키텍처는 몇 가지 한계를 보였습니다.Why Ambient Mode?간단하게 기존의 Sidecar Mode 형태의 아키텍처를 간단하게 소개하면 아래와 같습니다.큰 특징으로는 각 Pod마다 Envoy proxy를 Sidecar로 주입하여 트래픽을 전달하는 방식입니다.하지만 Sidecar Mode는 리소스 사용량 증가와 운영 복잡도 같은 문제를 야기했습니다.리소스 증가각 Pod마다 Envoy Proxy를 Sidecar로 주입하므로, 각 Pod의 컨테이너 개수는 (애플리케이션 컨테이너 1개 + Sidecar Proxy 컨테이너 1개)로 총 2개가 됩니다.따라서 Pod 수가 증가할수록 CPU와 Memory 사용량(요청량)이 크게 증가했고, 이는 전체적인 인프라 비용 증가로 이어졌습니다.2. 운영 복잡도Pod에 문제가 발생했을 때, 애플리케이션 컨테이너의 문제인지 Envoy Proxy의 문제인지 즉시 구분하기 어려웠습니다.Envoy Proxy와 애플리케이션이 강하게 결합(Coupling)된 형태여서, 하나의 문제로 인해 전체 Pod의 장애로 확대되는 경우가 많았습니다.저희는 이러한 문제를 해결하기 위해 새롭게 출시한 Ambient Mode로 전환하는 결정을 내렸습니다.새롭게 도입한 Ambient Mode 아키텍처를 간단하게 소개하면 아래와 같습니다.Ambient Mode는 기존의 Sidecar Mode와 달리, Envoy Proxy Sidecar의 역할을 Layer 4(ztunnel)와 Layer 7(waypoint)로 분리하여 네트워크 트래픽을 처리하는 방식으로 모든 pod 간 통신은 ztunnel 을 통하고, L7 기반 로직 처리 필요 시 waypoint 를 경유합니다. 이러한 구조적 변화로 인해 인프라 운영이 더욱 가볍고 효율적으로 설계되었습니다.key point는 아래와 같습니다.리소스 절감Pod마다 Envoy Proxy Sidecar가 존재하지 않으므로 CPU와 Memory 사용량(요청량)이 감소하였고, 더 적은 Worker Node로 동일한 트래픽을 처리할 수 있게 되었습니다.2. 운영 단순화Istio의 정책을 별도의 Proxy(ztunnel, waypoint)로 관리하여, 네트워크 정책 적용과 디버깅이 더욱 간편해졌습니다.애플리케이션을 Service Mesh에 포함하거나 제외할 때, 애플리케이션 Pod 재시작할 필요가 없습니다.Istio 버전을 업그레이드 할 때, 애플리케이션 Pod를 재시작할 필요가 없습니다.물론 Ambient Mode 전환 과정에서 기존 Sidecar Mode와의 호환성을 고려해야 했으며, 트래픽 라우팅 및 보안 정책이 기대한 대로 동작하는지 충분한 테스트가 필요했습니다.다음으로, Ambient Mode 전환 과정에서 맞닥뜨린 문제와 이를 어떻게 해결했는지, 그리고 현재 운영 방식에 대해 더 자세히 풀어보겠습니다!도입 과정Helm + Argo를 통한 Istio Ambient Mode 설치초기에 Istio를 도입할 당시, 중고나라는 Istio Operator를 활용하여 배포 및 운영을 진행하였습니다.그러나 Istio 1.18 버전 이후 Operator 기반의 방식이 Deprecated됨에 따라, 기존 방식으로는 더 이상 업그레이드가 불가능한 상황이 되었습니다.이에 따라 다양한 배포 방법을 검토하였으며, 잦은 업그레이드, 커스텀 설정, GitOps 등 유연한 운영이 가능한 방법을 찾고자 하였습니다.그 결과, Helm을 활용하여 환경별 세부 설정을 커스텀하고, Argo CD 기반의 GitOps 배포 방식을 도입하여 지속적인 운영 및 유지보수를 최적화하기로 결정하였습니다Kubernetes Gateway API 도입기존에는 Istio Gateway를 사용하여 트래픽을 관리하였지만, Gateway API를 도입한 이유는 다음과 같습니다.Istio 측에서 Gateway API를 향후 표준으로 자리 잡을 것이라고 언급했습니다.(참고 문서)Waypoint 트래픽을 세밀하게 제어하기 위해 Gateway API의 HTTPRoute 리소스를 활용할 필요가 있었습니다.이에 따라 기존의 VirtualService 및 DestinationRule 설정을 HTTPRoute 기반으로 재구성하였습니다.또한, Argo Rollout Controller 설치 시 gatewayAPI plugin을 같이 생성하고 Argo Rollout 의 트래픽 라우팅 방식도 기존 trafficRouting.istio에서 trafficRouting.plugins을 활용하는 방식으로 변경하여, Gateway API를 통해 트래픽을 분배할 수 있도록 수정하였습니다. (참고 문서1, 참고 문서2) trafficRouting: plugins: argoproj-labs/gatewayAPI: namespace: {{ .Release.Namespace }} httpRoute: {{ .Release.Name }}-httproute하지만 아직 HTTPRoute에서는 VirtualService, DestinationRule에서 제공하는 트래픽 관리 설정을 완벽하게 지원하지 않습니다.!! 예를 들어 Fault Injection 등은 아직 제공하지 않아 꼭 해당 기능이 필요한 상황이라면 Gateway API의 도입을 신중하게 검토해야합니다!!Ztunnel ProxyConfigAmbient Mode를 도입하면서 가장 큰 변화 중 하나는 L4 트래픽을 처리하는 ztunnel이 등장했다는 점입니다.그렇다면, 기존에 Istiod가 관리하던 ProxyConfig 설정이 ztunnel에도 그대로 적용될까요? 정답은 아니오 입니다.ztunnel은 Envoy 기반이 아니라 독립적인 L4 터널링 컴포넌트입니다.즉, 기존 ProxyConfi

SSO 연동 테스트: Keycloak과 애플리케이션의 완벽한 통합이번 글에서는 이전에 구성한 샘플 애플리케이션에 Single Sign Out을 구성해보고, 사전에 구축한 Keycloak을 활용하여 ArgoCD와 연동하는 방법을 안내드리겠습니다.• None 완벽한 HTTPS 보안: Ingress 컨트롤러와 Let's Encrypt으로 무료 인증서 설정하기• None Keycloak 설치부터 설정까지: SSO를 위한 첫걸음• None SSO 연동 샘플 애플리케이션 구성하기: 실전 가이드• None SSO 연동 테스트: Keycloak과 애플리케이션의 완벽한 통합ArgoCD는 Kubernetes 환경에서 애플리케이션을 지속적으로 배포(CD, Continuous Delivery)하기 위한 GitOps 기반의 오픈 소스 도구입니다.Git 리포지토리를 단일 소스로 삼아 Kubernetes 클러스터의 상태를 선언적 방식으로 관리하며, 안정적이고 일관된 배포 환경을 제공합니다.이번 가이드에서는 ArgoCD를 설치하고 Keycloak과 연동하여 SSO(Single Sign-On) 테스트를 수행해보겠습니다.이를 통해 안전하고 효율적인 접근 관리 및 인증 환경을 구축할 수 있습니다.ingress.yaml 파일을 하나 생성합니다.Ingress를 클러스터에 배포합니다.브라우저로 접속되는지 확인합니다. 인증서가 Stage용으로 배포되었기 때문에 경고 메시지를 확인할 수 있습니다.일단 접속이 되면 인증서를 Production용으로 변경합니다.yq 유틸리티가 설치되어 있지 않다면, 파일에서 부분을 로 직접 변경하시면 됩니다.ArgoCD의 배포와 접속이 성공적으로 완료되었다면, 이제 Keycloak에서 ArgoCD와의 원활한 인증 및 권한 관리를 위해 클라이언트를 생성하고 세부 설정을 진행해야 합니다.이 단계에서는 Keycloak이 ArgoCD의 인증 서버 역할을 수행할 수 있도록 클라이언트 ID, 인증 방식, 리디렉션 URI 등의 필수 설정을 꼼꼼하게 구성해야 합니다.이를 통해 사용자 접근 제어 및 보안 정책이 체계적으로 적용될 수 있습니다.로그인 설정과 관련된 URL을 그림을 참고하여 입력합니다.을 복사하여 ArgoCD 설정시에 사용합니다.Client Scope 설정시에 이름을 로 입력합니다.새로운 맵펑를 생성합니다. 타입은 을 선택합니다.이름과 토큰 클레임명을 로 지정합니다.이제 클라이언트를 구성하여 그룹 범위를 설정할 수 있습니다.신규로 그룹을 생성합니다.멤버에 alice를 추가합니다.이상으로 Keycloak에서 설정하는 부분은 모두 완료하였습니다.Keycloak에서 설정한 클라이언트 정보를 ArgoCD에서 설정하는 작업을 진행합니다. 먼저 argocd 값을 base64로 인코딩해야 합니다.인코딩한 값을 키로 추가합니다.이제 config 맵을 구성하고 OIDC 구성을 추가하여 Keycloak 인증을 활성화 할 수 있습니다.• None Keycloak 서버 및 realm 정보를 입력합니다. Keycloak 버전이 17보다 이전인 경우 Keycloak 릴리스의 발

WATCHA에서 서로 다른 클라우드 저장소 간의 데이터 마이그레이션 시스템을 구축한 경험을 소개합니다. #Kubernetes #ArgoWorkflows안녕하세요, WATCHA Server Platform 팀에서 플랫폼 엔지니어로 일하고 있는 루카입니다.WATCHA에서 모은 데이터를 효율적으로 분석하고 활용하기 위해 기존 데이터 마이그레이션 프로세스를 개선해 새로 구축한 경험, 그중에서도 AWS DynamoDB의 데이터 마이그레이션 사례를 중심으로 소개해 보려 합니다.WATCHA에서는 다양한 데이터가 매일 생성되고 업데이트됩니다. 이들은 용도에 따라 RDB나 NoSQL 등, 데이터 성질에 맞는 데이터베이스에 저장되지만, 다양한 의사결정을 지원하기 위해서는 서로 다른 성질의 데이터들을 통합하여 분석할 필요가 있습니다. WATCHA는 Google Cloud의 강력한 데이터 분석 도구인 BigQuery를 데이터 웨어하우스로 활용하고 있습니다.데이터 통합을 위해서는 매일 업데이트되는 데이터를 BigQuery에 동기화하는 과정이 필요합니다. 이 과정은 자동화되고 안정적이어야 하며, 새로운 데이터 형태가 추가될 때 쉽게 통합할 수 있어야 합니다. 또, WATCHA의 경우 대부분의 데이터가 Google Cloud 대신 AWS에 저장되고 있기 때문에, 멀티 클라우드 환경에 대한 고려도 필요합니다. 마지막으로, 위 조건들이 충족되는 한에서 비용 효율성을 최적화해야 합니다. 기존의 데이터 마이그레이션 프로세스는 이러한 요구사항들을 온전히 충족하지 못하고 있었습니다.데이터 마이그레이션 작업은 여러 팀의 리소스가 연계되는 작업입니다. 크게 보면 각 데이터를 소유한 담당 서버 팀, 데이터를 전달하는 인프라 팀, 그리고 데이터를 사용하는 분석 팀이 있겠습니다. 기존 파이프라인은 각 팀이 오너십을 가진 영역에서 각자 작업을 수행하는 협업의 형태로 설계되어 있었습니다. 이러한 오너십의 분산은 언뜻 보기엔 크게 문제가 없게 느껴졌지만, 운영 시스템의 미성숙과 겹치자 몇 가지 문제를 야기했습니다.기존 파이프라인. 각 팀마다 작업이 할당되어 각자 순차적으로 처리합니다.대표적인 문제는 Cascading failure였습니다. 기존 프로세스에서는 팀 간 작업 완료 이벤트를 제대로 체크하지 않고 있어, 한 작업이 실패할 경우 이후 단계 작업이 모두 실패하는 상황이 발생했습니다. 이로 인해 각 팀이 운영하는 모니터링 시스템에서 중복된 실패 알림이 발생해 혼란이 생겼고, 알림이 왔는데 막상 다른 팀의 실패에서 비롯된 경우가 발생하면서 알림의 신뢰도 역시 감소하였습니다.또 다른 문제는 지속적인 운영 부하였습니다. 데이터 마이그레이션 작업은 새로운 데이터가 통합에 추가되거나, 데이터의 스키마가 변할 때 지속적으로 관리가 필요한데요, 각 팀에서 각자 관리하는 데이터가 생기면서, 작은 스키마 변경에도 여러 팀에서 각자 설정 파일을 수정하고, 다른 팀 간에 타이밍을 맞춰 변경 사항을 적용하는 등의 번거로운 처리가 필요했습니다.문제점 2. 비용 비효율성마이그레이션에 활용되는 데이터 형태에도

이 번에는 지난 포스트에 이어 AKS(Azure Kubernetes Service) 상용 서비스에 적용한 후기 두 번째 내용으로,ArgoCD를 활용한 CD(Continueous Deployment) 방법에 대해 소개드리려고 합니다.ArgoCD는 이미 너무 유명해서 잘 알고 계실거라고 생각하는데요.구글이나 여러 기술 사이트에 조금만 검색해도 상세한 설명이 쉽게 찾아 볼 수 있어서 따로 설명드리지는 않고 기본 정의만 아래에 추가 하였습니다.ArgoCD는 Kubernetes 환경에서의 애플리케이션 배포와 관리를 지원하는 도구로, GitOps 원칙에 기반하여 설계되었습니다. 기본적으로 Git 저장소에 기록된 애플리케이션의 상태를 Kubernetes 클러스터와 동기화하는 역할을 수행합니다. 이를 통해 배포의 전체 상태와 변화 과정을 Git을 통해 효과적으로 추적하고 관리할 수 있습니다.저는 아래와 같은 전략으로 CD를 구성해보았습니다.• None argoCD를 통해 ACR에 저장되어 있는 어플리케이션 도커이미지를 k8s에 배포• None manifest yaml 파일을 하나의 git repo에서 모두 관리하고 프로젝트는 디렉토리로 구분하여 저장• None ArgoCD 등 k8s 관리에 필요한 것들을 서비스하기 위한 클러스터를 별도로 구성 (mgmt cluster). 단, 개발환경(dev/stg/live) 마다 하나씩 존재어떻게 CD를 구성하였는지 좀 더 자세히 알아보도록 하겠습니다.우선 manifest 파일 저장을 위해 git repository를 하나 생성하였습니다.ArgoCD는 위 용어 정의를 보셨다시피 Git 저장소에 기록된 애플리케이션의 상태를 동기화 하도록 되어 있는데요.따라서 애플리케이션에 대한 상태 정의 파일(manifest)을 저장할 수 있는 repository가 하나 필요합니다.ArgoCD에서 app을 만들 때마다 git project를 만들면 너무 저장소가 많아 지겠죠..?그래서 하나의 git repository에 여러개 애플리케이션의 manifest 파일들을 같이 관리하려고 합니다.이 때 ArgoCD에 app을 정의할 때 이 app이 어떤 애플리케이션인지 또 어떤 환경계(dev/stg/live)인지 알아야 합니다.이를 위해 아래와 같이 으로 네이밍룰을 정해 디렉토리를 생성하였습니다.• None 어떤 app인지 구분하기 위해 root directory 이름을 app명으로 작성• None env(환경계)를 구분하기 위해서 하위 directory 이름을 (dev/stg/live)로 작성 물론 git branch(develop/staging/main)로 구별할 수도 있지만, 다른 환경 파일을 수정할 때마다 브랜치를 스위칭 해주어야 하고 develop, staging, main 브랜치의 파일 내용을 다르게 관리해야 하기 때문에 (merge 하면 안됨) 좋지 않은 방법이라고 생각하여 main 브랜치에 모두 올려놓고 디렉토리 이름(dev/stg/live)으로 구분하도록 하였습니다.3. Deployment 생성 : 애플리케이션의 업데이트와