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 생성 : 애플리케이션의 업데이트와

함께 구매하면 좋은 상품이에요! - 장바구니 추천 개발기 2부안녕하세요. 컬리 데이터서비스개발팀에서 일하고 있는 백엔드 개발자 최재형, 김수지, 데이터 엔지니어 이상협, ML 엔지니어 구국원입니다. 이전 글에서는 장바구니 추천 모델을 개발하는 과정에서 고민한 내용을 설명드렸습니다. 그리고 이러한 고민 끝에 만들어진 모델의 부가가치를 실제 컬리의 엔드 유저에게 전달하기 위해서 실시간 서빙 아키텍처를 구축할 필요가 있있었습니다. 그 과정에서 역시나 많은 고민과 시행착오가 있었고, 현재 구축한 아키텍처에 기반하여 성공적으로 실시간 서빙을 수행하고 있습니다. 따라서 본 글에서는 컬리가 어떻게 실시간 서빙 아키텍처를 구축하고 운영하고 있는지를 공유 드리고자합니다. 추천 모델을 실시간으로 서빙하기 위한 아키텍처를 나타내 보았습니다. 이 아키텍쳐에 대해서 간단하게 말씀드리면, 추천 모델 API는 AWS와 GCP의 시스템을 활용하였고 그 중 AWS의 EKS 클러스터에서 대부분의 추천 모델 관련 작업이 이루어졌습니다. 학습과 분석에 필요한 데이터는 BigQuery에 적재되어 있고, 운영시 중요하게 모니터링 해야할 부분들은 Datadog과 Slack을 활용해 감지하고 알럿을 보냅니다. 이 아키텍쳐를 서비스 API, 모델 API, MLOps, 모니터링, 배포 과정 파트로 나눠서 각각의 구성 요소들의 세부사항들을 설명드리겠습니다. 서비스 API는 모델 API 앞단에서 컬리 백엔드의 트래픽을 받아 냅니다. 서비스 API는 유저에게 더 좋은 추천 서비스를 제공하고, 추후 서비스의 확장성을 확보하기 위해 구축하였으며 다음과 같은 기능을 수행합니다.특히 모든 분석과 모니터링은 정확한 로깅에서 시작하기 때문에 로깅은 서비스 API의 가장 중요한 요소라고 할 수 있습니다. 서비스 API에는 팀내에서 자체 구축한 로깅 모듈을 활용하고 있는데, 이 모듈을 통해서 API에서 발생한 로그들을 파일 형태로 내립니다. 그 후 생성된 로그 파일을 기 구축된 로깅시스템을 통해 Kafka 토픽으로 전송하고 카프카 토픽에 쌓인 메시지는 Nifi를 활용해 실시간으로 빅쿼리로 적재됩니다. 위 과정을 수행하기 위해 필요한 Kafka나 Nifi와 같은 데이터 연동 인프라는 기존에 저희 팀에서 구축해서 운영 중인 상황이었기 때문에 이를 그대로 활용할 수 있었습니다. 그 결과, 현재 빅쿼리에서 거의 실시간에 가까운 로그를 확인할 수 있습니다.모델 API를 구축하기 위해서는 먼저 서빙 프레임워크를 선정해야 했습니다. 서빙에 사용되는 오픈 소스들은 각자의 장단점이 명확하기 때문에 결국 저희 상황에 맞는 프레임워크를 선정하는 것이 중요했습니다. 여러 후보들을 비교 했는데, 최종적으로는 BentoML과 TorchServe를 후보로 두고 의사결정 하였습니다. 먼저, BentoML은 사용 편의성이 높아서 컬리의 다른 ML API를 서빙하는데 활용하고 있었고 운영 하면서 축적된 노하우가 있었기 때문에 후보로 선정하였습니다. 그리고 Torchserve는 Pytorch 모델을 서빙할 수 있는 프레임워크인데, 마침 개발된 모델이 Pytorch 기반이기도 하고 준수한 성능 보일 것으로 예상해서 후보로 선정하였습니다.그리고 최종 선택을 위해 각 서빙 프레임워크로 랩핑한 API를 띄워보고 성능 테스트를 진행하였습니다. 성능 테스트는 Locust를 활용하였고, 아래와 같은 그래프를 확인 할 수 있었습니다.대략적인 비교를 해보고자 세부적인 튜닝 없이 진행하였는데, 응답 시간 측면에서 torchserve가 더 좋은 지표를 보여주었습니다. 따라서 최종적으로 서빙 프레임워크로 Torchserve를 활용하기로 했고, 성능 최적화를 위한 세부적인 튜닝을 진행하였습니다.Torchserve를 튜닝하는 최종 목표는 낮은 응답시간(지연시간)을 달성하는 것이었습니다. 이를 위해 Torchserve 공식 문서나 관련 아티클을 참고하여 몇 가지의 속성들과 인프라적 튜닝 포인트를 확인 했습니다. 그 내용들은 다음과 같습니다.정리하면, 낮은 지연시간을 달성하기 위해선 부차적인 옵션 설정보다는 CPU Clock Speed가 중요한 특성이라는 것을 경험적으로 확인했습니다. 그 이유는 TorchServe는 요청을 들어온 순서대로 Queue에 넣고 FIFO 방식으로 처리하는 방식으로 구현되어 있으므로 선행하는 요청을 빠르게 처리하는 것이 전체 성능 향상에 가장 큰 영향을 미치기 때문입니다. 다시 말해, 높은 CPU Clock Speed를 확보하는 것이 결국 낮은 응답시간을 달성하는 핵심 요인이라는 것이므로 최종적으로는 CPU �Clock에 특화된 인스턴스 중에서 더 우수한 성능을 보이는 인스턴스를 선정하여 API를 배포하였습니다.ML 모델 API는 일반적인 애플리케이션과는 다르게 배포가 자주 일어날 수 있습니다. 왜냐하면 API가 운영되고 있는 중에 모델은 빈번하게 업데이트가 발생하기 마련이고, 이를 반영하여 새 모델로 API를 변경해줘야 하기 때문입니다. 이렇게 새 버전으로 배포하는 중에 다운타임이 발생하게 된다면 서비스 품질에 큰 영향을 줄 수 있기 때문에 무중단 배포가 필요합니다. 일반적으로 Kubernetes가 제공하는 Rolling Update, Blue/Green, Canary 등의 배포 전략을 활용하면 이론적으로는 무중단 배포가 되는게 맞지만, 실제로 배포 테스트를 해보았을 때 다운타임이 일부 발생하는 것을 확인되었습니다.이런 중단이 발생하는 주된 이유는 EKS외에 AWS의 다른 서비스들을 활용하는 것, 그리고 Gracefulshutdown이 적용되지 않았기 때문입니다. AWS EKS에서 애플리케이션이 트래픽을 받기 위해서는 Ingress를 생성하면서 AWS의 Application Load Balancer(이하 ALB)를 활용하게 되는데 이 때 ALB Ingress의 TargetGroup의 연결이 끊어지고 새로 연결되는 과정에서 다운타임이 발생할 수 있습니다.ALB가 생성된 후에 TargetGroup이 정상적으로 연결이 되면 그 시점부터 트래픽은 정상적으로 들어오게 됩니다. 하지만 모델의 업데이트로 새 버전의 pod가 생성되었고 이 pod로 트래픽을 보내려고 한다면, 기존의

이번 글은 쿠버네티스 네이티브 워크플로를 이용한 대용량 스트리밍 파이프라인 검증 자동화 시리즈의 마지막 글입니다. 지난 1편과 2편은 아래 링크에서 확인하실 수 있습니다.• 쿠버네티스 네이티브 워크플로를 이용한 대용량 스트리밍 파이프라인 검증 자동화 - 1편• 쿠버네티스 네이티브 워크플로를 이용한 대용량 스트리밍 파이프라인 검증 자동화 - 2편지난 2편에서는 Tekton 기반으로 성능 테스트 시스템을 구축한 사례를 소개했는데요. 이번 글에서는 LitmusChaos를 이용해 카오스 테스트를 진행한 사례를 소개하겠습니다.카오스 테스트 대상 애플리케이션 소개 및 카오스 테스트가 필요한 이유카오스 테스트의 대상 애플리케이션은 Apache Flink 프레임워크 기반의 전처리기입니다. LINE 광고 데이터 파이프라인에서는 앞서 2편에서 말씀드렸던 Heron 프레임워크 기반의 전처리기를 대체할 다음 버전의 전처리기로 Flink 프레임워크 기반의 전처리기를 준비하고 있으며, 이를 도입하기 준비하는 과정에서 LitmusChaos 기반의 카오스 엔지니어링을 진행했습니다.Apache Flink(이하 Flink)는 데이터 스트리밍을 지원하는 분산 처리 엔진으로, 자체 상태 저장소를 갖추고 있기 때문에 스테이트풀(stateful)한 연산이 가능하다는 특징이 있습니다. 아래는 쿠버네티스 환경에서 실행되는 Flink 애플리케이션의 구조를 간략히 나타낸 그림입니다.Flink 프레임워크에서는 하나의 Flink 애플리케이션을 '잡(job)'이라고 표현합니다. 하나의 잡은 Flink의 기초 실행 단위인 '태스크(task)'로 구성되는데요. Flink는 이 태스크라는 실행 단위를 통해 데이터를 분산 처리합니다.위 구조에서 'Flink 시스템 네임스페이스(Flink-system namespace)'의 'Flink 쿠버네티스 오퍼레이터(Flink Kubernetes operator)'는 쿠버네티스 커스텀 리소스(이하 커스텀 리소스)와 오퍼레이터 패턴을 기반으로 Flink 애플리케이션의 배포와 업그레이드 등의 작업을 담당합니다.오퍼레이터가 배포한 Flink 애플리케이션은 크게 '잡 매니저(job manager)'와 '태스크 매니저(task manager)'로 나뉜 파드들을 갖고 있습니다. 잡 매니저는 잡의 태스크를 어떤 태스크 매니저에서 실행할지 결정하고 태스크 매니저의 상태를 관리하는 등 잡을 관리하는 역할을 담당하며, 태스크 매니저는 태스크를 직접 실행하는 역할을 담당합니다. 이 두 매니저를 묶어서 'Flink 클러스터'라고 칭합니다.Flink 쿠버네티스 오퍼레이터가 관리하는 Flink 애플리케이션에는 크게 두 가지 모드가 있습니다. 각 애플리케이션이 독립적으로 Flink 클러스터를 각각 하나씩 갖는 애플리케이션 모드가 있고, 하나의 Flink 클러스터를 여러 애플리케이션이 공유하며 각 애플리케이션이 해당 Flink 클러스터에 세션 잡(session job) 형태로 제출되는 방식으로 작동하는 세션 모드가 있습니다.애플리케이션 모드는 잡 매니저 및 태스크 매니저를 하나의 애플