데이터 플랫폼 마이그레이션 전략

데이터 플랫폼 아키텍처는 지난 몇 년간 많은 변화를 마주해왔습니다.
시대에 따라 실시간, AI 등 새로운 요구사항이 등장했고 데이터와 활용 시스템이 증가함에 따라 확장성, 안정성, 비용 절감 등 다양한 문제를 해결해야만 했습니다. 그 결과 온프레미스와 클라우드 네이티브 환경, 데이터 웨어하우스부터 데이터 레이크 그리고 레이크 하우스까지 아키텍처의 변화에 따라 대규모 마이그레이션 프로젝트가 이루어졌습니다. 이번 글에서는 여러 번의 데이터 플랫폼 마이그레이션을 경험하며 배운 전략을 소개해드리려고 합니다.

준비 단계

성공적인 전환을 위해서는 현재 환경을 정확히 파악하고, 새로운 목표와 요구사항을 명확히 설정한 다음, 잠재적 위험 요소를 사전에 식별해 대비해야 합니다. 그리고 가장 적합한 마이그레이션 전략과 패턴을 선택해 조직의 상황에 맞게 적절한 로드맵을 그리는 것이 중요합니다.

1. 현재 환경 분석
우선적으로 수행해야 할 일은 기존 환경을 분석하는 것 입니다.
클러스터가 어떻게 구성되어 있는지, 실행 중인 워크로드의 특성과 스케줄 주기, 의존 관계 등 현황을 파악해야 합니다. 그리고 원활한 마이그레이션을 위해 모니터링, 로깅, 알람 시스템이 체계적으로 구성되어 있는지 진단이 필요합니다. 분석을 통해 마이그레이션 과정에서 예상되는 문제와 개선 포인트를 파악할 수 있습니다.

2. 목표 설정
기존 환경 분석을 마쳤다면, 마이그레이션을 통해 달성하고자 하는 구체적인 목표를 설정해야 합니다.
예를 들어 실시간 BI 대시보드 제공, 데이터 처리 성능 개선 등 목표를 나누어 우선순위를 정의하면 이를 통해 로드맵을 작성할 수 있습니다.

목표를 측정하고 검증할 수 있는 키 메트릭(Key Metrics) 을 정의하는 것이 좋습니다.
수치와 데이터로 마이그레이션 성과를 확인할 수 있고 새로운 기술 도입 등 마이그레이션 과정에서 발생할 수 있는 다양한 의사 결정 상황의 근거가 됩니다. 예를 들면 다음과 같습니다.

• 처리 성능: 배치 작업 처리 시간, 쿼리 수행 시간, DAG 완료까지 걸리는 시간 등
• 비용: 클라우드 사용량(컴퓨팅, 스토리지), 메모리 사용량, 비용 대비 성능 향상 효과(ROI)
• 안정성: SLA 준수율, 장애 발생 빈도 및 평균 복구 시간(MTTR), 재시도 비율 등

3. 서비스 영향도 파악
목표 설정이 끝났다면, 이를 달성하는 과정에서 발생할 수 있는 리스크를 살펴봐야 합니다.
대표적으로는 데이터 유실이나 장애로 인한 서비스 다운타임, 예상치 못한 성능 저하, 하위 호환성 문제 등이 있습니다. 마이그레이션 진행 과정에서 문제가 발생했을 때 빠르게 대응할 수 있도록, 백업 및 롤백 플랜과 다운타임 최소화 방안을 마련하는 것도 중요합니다.

마지막으로 상황을 고려하여 가장 적합한 마이그레이션 전략을 선택하고 계획을 세워야 합니다.
이제 대표적인 마이그레이션 전략에 대해 알아보겠습니다.

Lift & Shift

Lift & Shift는 기존의 어플리케이션이나 인프라를 최소한의 수정을 통해 새로운 환경으로 옮기는 접근 방식입니다.
예를 들어 YARN 기반 Spark 클러스터를 AWS 클라우드로 이전하는 경우, HDFS 데이터를 S3로 복사하고 EC2에 Spark을 설치 후 실행하는 방식입니다.

이 전략은 빠르고 간편한 이전을 통해 마이그레이션 기간을 최소화할 수 있으며 기존 작업 코드와 아키텍처를 그대로 이전하기 때문에 문제가 발생할 가능성이 낮습니다. 이러한 이유로 처음으로 온프레미스에서 클라우드로 마이레이션 하는 상황 또는 일정이 짧은 경우에 사용합니다.

하지만 클라우드와 같은 새로운 환경의 장점을 최대로 활용하지 못하는 단점이 있습니다. 결국 비용, 최적화 문제로 추가적인 개선을 진행하는 경우가 많았습니다.

Replatforming

Replatforming은 핵심 비즈니스 로직은 유지하되, 인프라 구성이나 일부 서비스(데이터베이스, 메세징, 스토리지 등)를 클라우드 친화적으로 변경하여 새로운 환경에 이전하는 방식입니다. 예를 들어 YARN 기반 Spark 클러스터를 AWS 클라우드로 이전하는 경우, AWS EMR, Glue 등의 매니지드 서비스를 활용하고 로컬 HDFS 대신 S3와 같은 오브젝트 스토리지를 활용하는 방식입니다.

이 방식은 스토리지와 컴퓨팅 자원을 분리하여 확장성 있는 클라우드의 장점을 얻을 수 있습니다. 또한 매니지드 서비스를 사용한다면 운영 부담을 줄일 수 있습니다. Replatforming은 장기적으로 팀 전체가 새로운 환경에 익숙해지는 계기가 되기도 합니다.

하지만 일부 코드와 아키텍처 수정이 필요하고 변경되는 요소들에 대한 성능 검증, 호환성 테스트가 필요합니다. Lift & Shift 방식에 비해 마이그레이션 시간이 소요되므로 레거시 시스템과 공존하는 기간이 생길 수 있습니다.

Refactoring

Refactoring은 기존 아키텍처를 근본적으로 재설계하고, 필요하다면 코드를 크게 수정해 클라우드 네이티브 환경에 맞게 최적화하는 접근 방식입니다. 예를 들어 기존 온프레미스 VM 기반의 데이터 플랫폼의 모든 컴포넌트를 Data on EKS 아키텍처로 재설계하는 방식입니다. 이를 위해 데이터 인프라 전반의 변화와 데이터 처리 파이프라인 전체에 대한 수정이 필요합니다.

이 방식은 장기적인 관점에서 성능, 비용, 운영 효율성 등을 크게 개선할 수 있습니다. 또한 유연하고 확장 가능한 구조로 전환하여 데이터 기반 의사결정과 비즈니스 요구사항 대응을 극대화할 수 있습니다.

하지만 코드와 아키텍처를 전면 재설계해야 하므로, 많은 시간과 인력이 필요합니다. 또한 새로 도입하는 기술과 구조가 안정화되는데 시간이 걸리고, 스케일링 이슈 등 예상치 못한 문제가 발생할 수 있습니다.

따라서 적용 시 PoC를 통해 성능, 호환성 등을 검증하고 리스크를 최소화하는 것이 중요합니다.
그리고 한 번에 전체를 전환하기보다 점진적인 전환 방식이 필요합니다. 큰 변화를 동시에 적용하는 경우, 인프라/플랫폼/어플리케이션 등 다양한 문제가 공존할 수 있어 문제의 범위를 좁히기 어렵습니다.

Refactoring은 장기간의 로드맵을 통해 달성할 수 있습니다. 도입하려는 새로운 기술에 대한 경험을 가진 사람이 팀에 존재한다면 마이그레이션 과정에서 마주하는 문제를 쉽게 해결할 수 있습니다.

Strangler Fig 패턴

앞서 살펴본 전략 중 Replatforming과 Refactoring은 코드와 아키텍처 수정이 필요합니다. 이 때 Strangler Fig 패턴을 사용한다면 한 번에 바꾸지 않고, 특정 기능이나 서비스 단위로 신규 시스템을 도입하면서, 기존 기능을 점차 축소해 나가는 단계적 접근이 가능합니다.

이 방식을 통해 장기간 다운타임 없이 안정적인 이관이 가능하며, 나누어 진행하기 때문에 실패 시 빠르게 롤백이 가능합니다. 또한 기존 시스템과 공존하기 때문에 비즈니스 운영의 연속성을 유지할 수 있습니다. 레거시 시스템의 규모가 크거나 복잡할 때 많이 사용하는 전략입니다. 다음으로 몇 가지 메이저 버전 업데이트 적용 사례를 소개해드리겠습니다.

Spark 클러스터 버전 업데이트

• 신규 버전 클러스터 생성, 성능 검증, 호환성 테스트 진행
• 기존 버전과 신규 버전 클러스터 동시 운영
• 가장 영향도가 낮은 작업부터 점진적으로 이관, 모니터링
• 신규 클러스터에서 실행하는 작업이 안정화되면 남은 작업 전체 이관
• 기존 클러스터 종료 후 제거, 키 메트릭을 통해 성과 확인

Airflow 클러스터 버전 업데이트

• 신규 버전 클러스터 생성, 성능 검증, 호환성 테스트 진행
• DAG 코드 자동 변환 스크립트, 신규 버전 스위칭 시스템 개발
• 가장 영향도가 낮은 DAG 부터 점진적으로 이관, 모니터링
• 문제 발생 시 신규 버전 DAG 비활성화, 기존 버전 DAG 활성화로 롤백
• 신규 클러스터에서 실행하는 작업이 안정화되면 남은 작업 전체 이관
• 기존 클러스터 종료 후 제거, 키 메트릭을 통해 성과 확인

Trino 클러스터 버전 업데이트

• Trino Gateway 도입을 통해 트래픽 라우팅 설정
• 신규 버전 클러스터 생성, 성능 검증, 호환성 테스트 진행
• 가장 영향도가 낮은 시스템부터 신규 버전으로 트래픽 라우팅, 모니터링
• 점진적으로 라우팅 비율을 높여 더 많은 쿼리 요청이 신규 버전으로 전환
• 신규 클러스터 전환 후 안정적으로 처리되는 것을 확인
• 기존 클러스터 점진적으로 종료 후 제거, 키 메트릭을 통해 성과 확인

점진적인 마이그레이션은 시간이 오래 걸릴 수 있습니다. 이 때 도움이 될 수 있는 몇 가지 방법을 소개합니다.

업데이트가 진행되는 동안에는 실행 중인 사용자의 작업에 영향이 없어야 합니다.
실행 중인 작업 또는 쿼리가 완료될 때까지 대기 후 안정적으로 종료되는 decommision과 graceful shutdown이 필요합니다.

롤백을 위해 코드의 하위 호환성을 유지해야 합니다.
의존성을 가진 시스템을 모두 기억하고 테스트하기 어렵기 때문에 통합 테스트 환경을 준비해두면 좋습니다.

업데이트에 따른 코드 수정을 전부 사용자에게 위임하면 후순위로 밀려 진행 속도가 느려질 수 있습니다. 자동화된 마이그레이션을 위해 스크립트나 도구를 제공하고 테스트 가이드가 필요합니다.

그럼에도 후순위로 밀려 진행되지 못한 작업은 CI를 통해 강제 전환을 유도할 수 있습니다.
예를 들면 새로 올라오는 PR에 대해 구 버전을 사용하는 경우, 단위 테스트가 실패하도록 설정합니다.

마치며

그 동안 여러 회사와 환경을 경험하며 Lift & Shift → Replatforming → Refactoring으로 변화하는 모습을 보았습니다. 대규모 마이그레이션일 수록 준비 단계와 점진적인 전환 방식이 중요했습니다. 한 가지 전략만 계획하기보다 컴포넌트 별 다양한 전략을 유연하게 선택하는 방법도 가능합니다. 실제 마이그레이션 과정에서는 보안, 네트워크, 조직 간 협업, 러닝 커브 등 더 많은 요소들을 마주할 수 있습니다.

데이터 플랫폼 마이그레이션은 단일 이벤트가 아니라 지속적인 개선 과정입니다. 앞으로도 새로운 문제가 나타나며 기술은 계속 발전합니다. 데이터 플랫폼 아키텍처도 이에 따라 진화해야 합니다. 변화를 두려워하지 않고 꾸준히 개선해 나가다보면 조직 전체에 긍정적인 영향을 줄 수 있을 것이라 생각합니다.