<div id="readability-page-1" class="page"><article><div><div><div><h2 id="8b5d" data-testid="storyTitle">멀티 클라우드 환경에서의 데이터 마이그레이션 시스템 구축</h2><div><a rel="noopener follow" href="/@daram7522?source=post_page-----420394a212d2--------------------------------"><div aria-hidden="false"><p><img alt="Daram7" src="https://miro.medium.com/v2/da:true/resize:fill:88:88/0*dYN2xnLkFmH61ND3" width="44" height="44" loading="lazy" data-testid="authorPhoto"></p></div></a><a href="https://medium.com/watcha?source=post_page-----420394a212d2--------------------------------" rel="noopener follow"><div aria-hidden="false"><p><img alt="WATCHA" src="https://miro.medium.com/v2/resize:fill:48:48/1*3YwZ4pRivcBi8nWl7u98gA.png" width="24" height="24" loading="lazy" data-testid="publicationPhoto"></p></div></a></div></div><p id="0505">WATCHA에서 서로 다른 클라우드 저장소 간의 데이터 마이그레이션 시스템을 구축한 경험을 소개합니다. #Kubernetes #ArgoWorkflows</p></div><div><p id="7517">안녕하세요, WATCHA Server Platform 팀에서 플랫폼 엔지니어로 일하고 있는 루카입니다.</p><p id="76cc">WATCHA에서 모은 데이터를 효율적으로 분석하고 활용하기 위해 기존 데이터 마이그레이션 프로세스를 개선해 새로 구축한 경험, 그중에서도 AWS DynamoDB의 데이터 마이그레이션 사례를 중심으로 소개해 보려 합니다.</p><p id="6ee2">WATCHA에서는 다양한 데이터가 매일 생성되고 업데이트됩니다. 이들은 용도에 따라 RDB나 NoSQL 등, 데이터 성질에 맞는 데이터베이스에 저장되지만, 다양한 의사결정을 지원하기 위해서는 서로 다른 성질의 데이터들을 통합하여 분석할 필요가 있습니다. WATCHA는 Google Cloud의 강력한 데이터 분석 도구인 BigQuery를 데이터 웨어하우스로 활용하고 있습니다.</p><figure></figure><p id="f030">데이터 통합을 위해서는 매일 업데이트되는 데이터를 BigQuery에 동기화하는 과정이 필요합니다. 이 과정은 <strong>자동화</strong>되고 <strong>안정적</strong>이어야 하며, 새로운 데이터 형태가 추가될 때 <strong>쉽게 통합</strong>할 수 있어야 합니다. 또, WATCHA의 경우 대부분의 데이터가 Google Cloud 대신 AWS에 저장되고 있기 때문에, <strong>멀티 클라우드 환경에 대한 고려</strong>도 필요합니다. 마지막으로, 위 조건들이 충족되는 한에서 <strong>비용 효율성</strong>을 최적화해야 합니다. 기존의 데이터 마이그레이션 프로세스는 이러한 요구사항들을 온전히 충족하지 못하고 있었습니다.</p></div><div><p id="91aa">데이터 마이그레이션 작업은 여러 팀의 리소스가 연계되는 작업입니다. 크게 보면 각 데이터를 소유한 담당 서버 팀, 데이터를 전달하는 인프라 팀, 그리고 데이터를 사용하는 분석 팀이 있겠습니다. 기존 파이프라인은 각 팀이 오너십을 가진 영역에서 각자 작업을 수행하는 협업의 형태로 설계되어 있었습니다. 이러한 오너십의 분산은 언뜻 보기엔 크게 문제가 없게 느껴졌지만, 운영 시스템의 미성숙과 겹치자 몇 가지 문제를 야기했습니다.</p><figure><figcaption>기존 파이프라인. 각 팀마다 작업이 할당되어 각자 순차적으로 처리합니다.</figcaption></figure><p id="89da">대표적인 문제는 <strong>Cascading failure</strong>였습니다. 기존 프로세스에서는 팀 간 작업 완료 이벤트를 제대로 체크하지 않고 있어, 한 작업이 실패할 경우 이후 단계 작업이 모두 실패하는 상황이 발생했습니다. 이로 인해 각 팀이 운영하는 모니터링 시스템에서 중복된 실패 알림이 발생해 혼란이 생겼고, 알림이 왔는데 막상 다른 팀의 실패에서 비롯된 경우가 발생하면서 알림의 신뢰도 역시 감소하였습니다.</p><p id="3569">또 다른 문제는 지속적인 <strong>운영 부하</strong>였습니다. 데이터 마이그레이션 작업은 새로운 데이터가 통합에 추가되거나, 데이터의 스키마가 변할 때 지속적으로 관리가 필요한데요, 각 팀에서 각자 관리하는 데이터가 생기면서, 작은 스키마 변경에도 여러 팀에서 각자 설정 파일을 수정하고, 다른 팀 간에 타이밍을 맞춰 변경 사항을 적용하는 등의 번거로운 처리가 필요했습니다.</p><h2 id="1510">문제점 2. 비용 비효율성</h2><p id="bcbe">마이그레이션에 활용되는 데이터 형태에도 문제가 있었습니다. 기존 데이터 마이그레이션은 테이블 전체를 export하여 BigQuery로 전송했는데, 이는 스키마 변경 시 기존 데이터와의 호환을 걱정하지 않아도 되고, 마이그레이션 과정에 오류가 발생해도 재시도가 용이하다는 장점이 있었습니다. 그러나 데이터 양이 많아질수록 비용 이슈가 부각되고, 특히 DynamoDB의 경우 Full Export 비용이 GB당 0.1$ 수준으로 높아 문제가 더 심각했습니다.</p></div><div><div><figure><figcaption>신규 마이그레이션 파이프라인. 전체 프로세스가 플랫폼 팀 관리 하의 Workflow에서 step 기반으로 실행됩니다.</figcaption></figure><p id="3649">이러한 문제점을 해결하고자 운영이 용이하면서도 비용 효율적인 새로운 시스템을 설계하였습니다. 새 시스템은 <a href="https://argoproj.github.io/workflows/" rel="noopener ugc nofollow" target="_blank"><strong>Argo Workflows</strong></a>¹를 활용해 전체 프로세스를 관리하도록 구성되었습니다. Argo Workflows는 Kubernetes 친화적인 오픈소스 Workflow 엔진으로, CNCF의 Graduated 오픈소스 프로젝트인 Argo 프로젝트의 일부입니다. 높은 자유도를 제공하면서도 자체 UI를 통한 컨트롤과 모니터링이 가능하며, 기존에 CI/CD에 활용하고 있던 ArgoCD와의 연계도 가능했습니다.</p><h2 id="55f0">변경점 1. 전체 프로세스의 통합</h2></div><div><figure><figcaption>작업의 성질에 따라 Template를 생성하고, 각 Template을 메인 cron workflow가 관리합니다.</figcaption></figure></div><div><p id="4d35">Argo Workflow는 특정한 작업 플로우를 Workflow Template로 지정하여, 새로운 Workflow를 생성할 때 미리 만들어둔 템플릿을 조합할 수 있습니다. 이를 활용해 기존에 각 팀에서 맡고 있던 작업들을 기반으로 크게 세 개의 템플릿을 만들었고, 메인 Cron Workflow가 이 템플릿들을 관리하도록 했습니다. 메인 Workflow는 매일 정해진 시간에 Config 파일을 기반으로 각 템플릿을 트리거하고, 에러 발생 시 사내 메신저를 통한 에러 전파를 수행합니다.</p><p id="9dc8">이렇게 템플릿 단위로 구분하고 하나의 Workflow로 통합하면서, 코드 가시성을 유지하면서도 문제 발생 시 원인 분석이 용이해졌습니다. 에러가 Workflow 외적인 이슈(네트워크, 클라우드 장애 등)였다면 곧바로 에러 지점에서 재시도할 수 있고, Workflow 코드에 문제가 발생했더라도 문제가 있었던 템플릿을 수정하여 해당 템플릿만 다시 실행하는 등의 처리도 가능했습니다.</p></div><div><figure><figcaption>제공되는 UI를 통해 각 템플릿의 step 단위로 성공/실패 여부를 확인할 수 있습니다.</figcaption></figure></div><div><h2 id="d9b7">변경점 2. 멀티 클라우드 권한 관리 방식 변경</h2><p id="a549">멀티 클라우드 환경에서 일어나는 작업을 단일 Workflow로 통합하면서, 각 클라우드의 리소스에 대한 액세스 권한을 효과적으로 관리할 필요성이 생겼습니다. 특히 AWS S3으로 export된 데이터를 Google Cloud Bucket으로 전송하는 작업인 <strong>Storage transfer</strong> 작업의 경우, AWS와 GCP 모두에 대한 접근 권한이 필요합니다. 기존에는 해당 작업을 위해 전용 IAM User를 생성하고, Access Key를 통해 영구적인 접근을 제공했으나, 이 방식은 Access Key가 유출될 경우 심각한 보안 문제가 발생할 수 있었습니다. AWS에서도 가능한 한 Access Key 대신 다른 인증 방식을 활용할 것을 권장하고 있습니다².</p><p id="a6ca">새로운 시스템에서는 Role 기반 페더레이션을 도입했습니다. Google Cloud에서 storage transfer 작업을 수행하는 주체를 AWS IAM Role에 Trusted Relationship으로 등록하여, 필요할 때마다 동적으로 단기 인증을 허가해 주는 방식입니다. 이 방식은 지정된 워크로드에서만 인증이 허가되며 자격 증명을 위한 키를 따로 남기지 않아, 보안성을 크게 개선할 수 있었습니다.</p><figure><figcaption>accounts.google.com의 특정 account에서 AWS role을 사용할 수 있도록 허용했습니다.</figcaption></figure><h2 id="dd27">변경점 2. 수동 관리 작업의 간소화</h2><p id="ea0d">설계와 함께 중요했던 부분은 수동으로 관리할 데이터를 줄이는 것이었습니다. 기존 프로세스의 구조를 그대로 가져갈 경우, 기존에 세 팀에서 처리되던 운영 부하가 프로세스를 관리하는 한 팀으로 모여 과중될 것이기 때문입니다. 대표적으로 기존 프로세스에서 데이터 소유 팀이 DB export에 활용되는 DB 스키마 파일을, 데이터 분석 팀이 마이그레이션 결과인 빅쿼리 테이블 스키마 파일을 별도로 관리하고 있어, 스키마 변경시마다 각 파일을 직접 수정해 주고 정합성을 검증해야 하는 번거로움이 있었습니다.</p><p id="f156">변경된 프로세스에서는 분석 팀에서 필요로 하는 빅쿼리 테이블 스키마 파일만을 인풋으로 받고, 이를 기반으로 DB 스키마 파일과 마이그레이션 쿼리 등을 동적으로 생성하도록 Workflow를 구성했습니다. 이를 통해 최소한의 수정으로 마이그레이션을 수행할 수 있게 되었습니다.</p><h2 id="aa4a">변경점 3. 증분 마이그레이션 적용</h2><p id="bae2">비용 효율성에 대한 개선도 이루어졌습니다. 최초 시스템 구상 당시에는 DynamoDB Stream을 활용한 CDC(Change Data Capture) 파이프라인을 구성하려 하였으나, 구상 도중 AWS에서 DynamoDB <a href="https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/S3DataExport.HowItWorks.html" rel="noopener ugc nofollow" target="_blank"><strong>Incremental Export</strong></a>³ 를 신규 기능으로 출시하였습니다. 기준 시간과 목표 시간을 입력하여 두 시간 사이에 변경된 데이터만을 export 하는 기능인데요, CDC와 Incremental Export를 비교한 결과 최종적으로 Incremental Export를 적용하게 되었습니다.</p><p id="5e7a">Incremental Export는 export 기준 시점을 명확히 명시해두기에 에러 발생 시 복구 시점을 정확히 판별할 수 있고, 적절한 쿼리 세팅을 통해 멱등성을 보장할 수 있습니다. 또한, 기존에 사용하던 Full Export와 유사하게 이용할 수 있도록 설계되어, 마이그레이션에 문제가 생기거나 스키마가 변경되는 등의 상황에, Full Export를 통해 한번 덮어씌우는 것만으로 간단히 동기화할 수 있었습니다. Full Export와 Incremental Export 간의 상호 전환을 비교적 적은 공수로 구현할 수 있었던 것은 큰 이점이었습니다.</p><figure><figcaption>Full Export와 연계하여 continuous data retention을 구현할 수 있습니다. 이미지 출처: <a href="https://aws.amazon.com/blogs/database/use-amazon-dynamodb-incremental-exports-to-drive-continuous-data-retention/" rel="noopener ugc nofollow" target="_blank">AWS 공식 블로그</a>⁴</figcaption></figure><p id="339c">비용적 측면에서도 Incremental Export는 오직 변경이 일어난 데이터의 최종 스냅샷만을 export에 활용하여, 변경이 없는 데이터도 전부 내보내는 full export나 변경이 일어날 때마다 업데이트가 필요한 CDC보다 이점이 있었습니다. 적용을 통해 마이그레이션 비용의 대부분을 차지하던 export 비용이 95% 이상 절감되었습니다.</p></div></div><div><p id="5308">이렇게 WATCHA가 멀티 클라우드 환경에서 데이터 마이그레이션 시스템을 개선한 과정을 공유해 보았습니다. 새로운 프로세스는 Argo Workflows를 통해 기존 시스템의 오너십 분산과 비용 비효율성 문제를 성공적으로 해결했습니다. 마이그레이션 프로세스에 대한 보다 효율적인 모니터링을 할 수 있었고, 수동 작업을 간소화하여 운영 부담을 줄였으며, Incremental Export 기능을 활용해 비용을 크게 절감할 수 있었습니다.</p><p id="c1fa">하지만 아직 해결해야 할 과제도 남아있습니다. 오너십을 통합하고 수동 관리 데이터를 간소화했지만, 아직 완전한 자동화가 이루어지고 있다고는 볼 수 없습니다. 요구사항이 생길 때마다 누군가가 직접 인풋 데이터를 세팅해 주어야 하기 때문입니다. 장기적으로는 분석팀이 어딘가에 요청하지 않고, 직접 마이그레이션 주기와 데이터 스키마를 조정하고 컨트롤할 수 있도록 완전한 <strong>플랫폼화</strong>를 목표로 하고 있습니다.</p><p id="3ec7">이 글이 멀티 클라우드 환경을 고려 중인 분들, 데이터 마이그레이션 파이프라인을 설계하시는 분께 도움이 되길 바랍니다.</p><p id="4819">읽어주셔서 감사합니다.</p></div></div></article></div>

WATCHA - Medium

WATCHA에서 서로 다른 클라우드 저장소 간의 데이터 마이그레이션 시스템을 구축한 경험을 소개합니다. #Kubernetes #ArgoWorkflows
안녕하세요, WATCHA Server Platform 팀에서 플랫폼 엔지니어로 일하고 있는 루카입니다.
WATCHA에서 모은 데이터를 효율적으로 분석하고 활용하기 위해 기존 데이터 마이그레이션 프로세스를 개선해 새로 구축한 경험, 그중에서도 AWS DynamoDB의 데이터 마이그레이션 사례를 중심으로 소개해 보려 합니다.
WATCHA에서는 다양한 데이터가 매일 생성되고 업데이트됩니다. 이들은 용도에 따라 RDB나 NoSQL 등, 데이터 성질에 맞는 데이터베이스에 저장되지만, 다양한 의사결정을 지원하기 위해서는 서로 다른 성질의 데이터들을 통합하여 분석할 필요가 있습니다. WATCHA는 Google Cloud의 강력한 데이터 분석 도구인 BigQuery를 데이터 웨어하우스로 활용하고 있습니다.
데이터 통합을 위해서는 매일 업데이트되는 데이터를 BigQuery에 동기화하는 과정이 필요합니다. 이 과정은 자동화되고 안정적이어야 하며, 새로운 데이터 형태가 추가될 때 쉽게 통합할 수 있어야 합니다. 또, WATCHA의 경우 대부분의 데이터가 Google Cloud 대신 AWS에 저장되고 있기 때문에, 멀티 클라우드 환경에 대한 고려도 필요합니다. 마지막으로, 위 조건들이 충족되는 한에서 비용 효율성을 최적화해야 합니다. 기존의 데이터 마이그레이션 프로세스는 이러한 요구사항들을 온전히 충족하지 못하고 있었습니다.
데이터 마이그레이션 작업은 여러 팀의 리소스가 연계되는 작업입니다. 크게 보면 각 데이터를 소유한 담당 서버 팀, 데이터를 전달하는 인프라 팀, 그리고 데이터를 사용하는 분석 팀이 있겠습니다. 기존 파이프라인은 각 팀이 오너십을 가진 영역에서 각자 작업을 수행하는 협업의 형태로 설계되어 있었습니다. 이러한 오너십의 분산은 언뜻 보기엔 크게 문제가 없게 느껴졌지만, 운영 시스템의 미성숙과 겹치자 몇 가지 문제를 야기했습니다.
대표적인 문제는 Cascading failure였습니다. 기존 프로세스에서는 팀 간 작업 완료 이벤트를 제대로 체크하지 않고 있어, 한 작업이 실패할 경우 이후 단계 작업이 모두 실패하는 상황이 발생했습니다. 이로 인해 각 팀이 운영하는 모니터링 시스템에서 중복된 실패 알림이 발생해 혼란이 생겼고, 알림이 왔는데 막상 다른 팀의 실패에서 비롯된 경우가 발생하면서 알림의 신뢰도 역시 감소하였습니다.
또 다른 문제는 지속적인 운영 부하였습니다. 데이터 마이그레이션 작업은 새로운 데이터가 통합에 추가되거나, 데이터의 스키마가 변할 때 지속적으로 관리가 필요한데요, 각 팀에서 각자 관리하는 데이터가 생기면서, 작은 스키마 변경에도 여러 팀에서 각자 설정 파일을 수정하고, 다른 팀 간에 타이밍을 맞춰 변경 사항을 적용하는 등의 번거로운 처리가 필요했습니다.
문제점 2. 비용 비효율성
마이그레이션에 활용되는 데이터 형태에도 문제가 있었습니다. 기존 데이터 마이그레이션은 테이블 전체를 export하여 BigQuery로 전송했는데, 이는 스키마 변경 시 기존 데이터와의 호환을 걱정하지 않아도 되고, 마이그레이션 과정에 오류가 발생해도 재시도가 용이하다는 장점이 있었습니다. 그러나 데이터 양이 많아질수록 비용 이슈가 부각되고, 특히 DynamoDB의 경우 Full Export 비용이 GB당 0.1$ 수준으로 높아 문제가 더 심각했습니다.
이러한 문제점을 해결하고자 운영이 용이하면서도 비용 효율적인 새로운 시스템을 설계하였습니다. 새 시스템은 Argo Workflows¹를 활용해 전체 프로세스를 관리하도록 구성되었습니다. Argo Workflows는 Kubernetes 친화적인 오픈소스 Workflow 엔진으로, CNCF의 Graduated 오픈소스 프로젝트인 Argo 프로젝트의 일부입니다. 높은 자유도를 제공하면서도 자체 UI를 통한 컨트롤과 모니터링이 가능하며, 기존에 CI/CD에 활용하고 있던 ArgoCD와의 연계도 가능했습니다.
변경점 1. 전체 프로세스의 통합
Argo Workflow는 특정한 작업 플로우를 Workflow Template로 지정하여, 새로운 Workflow를 생성할 때 미리 만들어둔 템플릿을 조합할 수 있습니다. 이를 활용해 기존에 각 팀에서 맡고 있던 작업들을 기반으로 크게 세 개의 템플릿을 만들었고, 메인 Cron Workflow가 이 템플릿들을 관리하도록 했습니다. 메인 Workflow는 매일 정해진 시간에 Config 파일을 기반으로 각 템플릿을 트리거하고, 에러 발생 시 사내 메신저를 통한 에러 전파를 수행합니다.
이렇게 템플릿 단위로 구분하고 하나의 Workflow로 통합하면서, 코드 가시성을 유지하면서도 문제 발생 시 원인 분석이 용이해졌습니다. 에러가 Workflow 외적인 이슈(네트워크, 클라우드 장애 등)였다면 곧바로 에러 지점에서 재시도할 수 있고, Workflow 코드에 문제가 발생했더라도 문제가 있었던 템플릿을 수정하여 해당 템플릿만 다시 실행하는 등의 처리도 가능했습니다.
변경점 2. 멀티 클라우드 권한 관리 방식 변경
멀티 클라우드 환경에서 일어나는 작업을 단일 Workflow로 통합하면서, 각 클라우드의 리소스에 대한 액세스 권한을 효과적으로 관리할 필요성이 생겼습니다. 특히 AWS S3으로 export된 데이터를 Google Cloud Bucket으로 전송하는 작업인 Storage transfer 작업의 경우, AWS와 GCP 모두에 대한 접근 권한이 필요합니다. 기존에는 해당 작업을 위해 전용 IAM User를 생성하고, Access Key를 통해 영구적인 접근을 제공했으나, 이 방식은 Access Key가 유출될 경우 심각한 보안 문제가 발생할 수 있었습니다. AWS에서도 가능한 한 Access Key 대신 다른 인증 방식을 활용할 것을 권장하고 있습니다².
새로운 시스템에서는 Role 기반 페더레이션을 도입했습니다. Google Cloud에서 storage transfer 작업을 수행하는 주체를 AWS IAM Role에 Trusted Relationship으로 등록하여, 필요할 때마다 동적으로 단기 인증을 허가해 주는 방식입니다. 이 방식은 지정된 워크로드에서만 인증이 허가되며 자격 증명을 위한 키를 따로 남기지 않아, 보안성을 크게 개선할 수 있었습니다.
변경점 2. 수동 관리 작업의 간소화
설계와 함께 중요했던 부분은 수동으로 관리할 데이터를 줄이는 것이었습니다. 기존 프로세스의 구조를 그대로 가져갈 경우, 기존에 세 팀에서 처리되던 운영 부하가 프로세스를 관리하는 한 팀으로 모여 과중될 것이기 때문입니다. 대표적으로 기존 프로세스에서 데이터 소유 팀이 DB export에 활용되는 DB 스키마 파일을, 데이터 분석 팀이 마이그레이션 결과인 빅쿼리 테이블 스키마 파일을 별도로 관리하고 있어, 스키마 변경시마다 각 파일을 직접 수정해 주고 정합성을 검증해야 하는 번거로움이 있었습니다.
변경된 프로세스에서는 분석 팀에서 필요로 하는 빅쿼리 테이블 스키마 파일만을 인풋으로 받고, 이를 기반으로 DB 스키마 파일과 마이그레이션 쿼리 등을 동적으로 생성하도록 Workflow를 구성했습니다. 이를 통해 최소한의 수정으로 마이그레이션을 수행할 수 있게 되었습니다.
변경점 3. 증분 마이그레이션 적용
비용 효율성에 대한 개선도 이루어졌습니다. 최초 시스템 구상 당시에는 DynamoDB Stream을 활용한 CDC(Change Data Capture) 파이프라인을 구성하려 하였으나, 구상 도중 AWS에서 DynamoDB Incremental Export³ 를 신규 기능으로 출시하였습니다. 기준 시간과 목표 시간을 입력하여 두 시간 사이에 변경된 데이터만을 export 하는 기능인데요, CDC와 Incremental Export를 비교한 결과 최종적으로 Incremental Export를 적용하게 되었습니다.
Incremental Export는 export 기준 시점을 명확히 명시해두기에 에러 발생 시 복구 시점을 정확히 판별할 수 있고, 적절한 쿼리 세팅을 통해 멱등성을 보장할 수 있습니다. 또한, 기존에 사용하던 Full Export와 유사하게 이용할 수 있도록 설계되어, 마이그레이션에 문제가 생기거나 스키마가 변경되는 등의 상황에, Full Export를 통해 한번 덮어씌우는 것만으로 간단히 동기화할 수 있었습니다. Full Export와 Incremental Export 간의 상호 전환을 비교적 적은 공수로 구현할 수 있었던 것은 큰 이점이었습니다.
비용적 측면에서도 Incremental Export는 오직 변경이 일어난 데이터의 최종 스냅샷만을 export에 활용하여, 변경이 없는 데이터도 전부 내보내는 full export나 변경이 일어날 때마다 업데이트가 필요한 CDC보다 이점이 있었습니다. 적용을 통해 마이그레이션 비용의 대부분을 차지하던 export 비용이 95% 이상 절감되었습니다.
이렇게 WATCHA가 멀티 클라우드 환경에서 데이터 마이그레이션 시스템을 개선한 과정을 공유해 보았습니다. 새로운 프로세스는 Argo Workflows를 통해 기존 시스템의 오너십 분산과 비용 비효율성 문제를 성공적으로 해결했습니다. 마이그레이션 프로세스에 대한 보다 효율적인 모니터링을 할 수 있었고, 수동 작업을 간소화하여 운영 부담을 줄였으며, Incremental Export 기능을 활용해 비용을 크게 절감할 수 있었습니다.
하지만 아직 해결해야 할 과제도 남아있습니다. 오너십을 통합하고 수동 관리 데이터를 간소화했지만, 아직 완전한 자동화가 이루어지고 있다고는 볼 수 없습니다. 요구사항이 생길 때마다 누군가가 직접 인풋 데이터를 세팅해 주어야 하기 때문입니다. 장기적으로는 분석팀이 어딘가에 요청하지 않고, 직접 마이그레이션 주기와 데이터 스키마를 조정하고 컨트롤할 수 있도록 완전한 플랫폼화를 목표로 하고 있습니다.
이 글이 멀티 클라우드 환경을 고려 중인 분들, 데이터 마이그레이션 파이프라인을 설계하시는 분께 도움이 되길 바랍니다.
읽어주셔서 감사합니다.
Reference
[1] https://argoproj.github.io/workflows/
[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds.html#sec-alternatives-to-long-term-access-keys
[3] https://aws.amazon.com/blogs/database/introducing-incremental-export-from-amazon-dynamodb-to-amazon-s3/
[4] https://aws.amazon.com/blogs/database/use-amazon-dynamodb-incremental-exports-to-drive-continuous-data-retention/
멀티 클라우드 환경에서의 데이터 마이그레이션 시스템 구축 was originally published in WATCHA on Medium, where people are continuing the conversation by highlighting and responding to this story.

멀티 클라우드 환경에서의 데이터 마이그레이션 시스템 구축

댓글