1억건의 데이터를 안정적으로 마이그레이션하기 With Firestore

Firestore 마이그레이션을 시작하며

현재 Fromm 채팅 서비스는 내부적으로 리뉴얼 작업이 진행중입니다.

사용자 증가로 인해 기존 구조에서 대용량 트래픽을 처리하는 데 한계가 발생할 가능성이 있어, 이를 해결하기 위해 확장 가능한 아키텍처로 개편하고 있습니다.

또한 향후 채팅 기능 확장을 고려한 설계와 개발이 진행되고 있습니다.

이 과정에서 기존 Firebase db에 저장된 채팅 데이터를 새로운 Firebase 로 마이그레이션해야 하는 상황이 발생했습니다.

이번 글에서는 1억 건 이상의 데이터를 효율적으로 마이그레이션했던 방법에 대해 다룹니다.

마이그레이션 요구사항

마이그레이션 작업에는 다음과 같은 요구사항이 있었습니다.

1. 기존 인터페이스를 변경해야 한다.
2. 여러 개의 Firestore db를 생성하고, 각 팬에게 할당된 db id에 따라 데이터를 올바르게 분배해야 한다.
3. 마이그레이션 코드를 올릴 인프라가 필요하다.
4. 마이그레이션 도중 실패하더라도 안정적으로 재처리할 수 있어야 한다.

아래에서 하나씩 자세히 살펴보겠습니다.

마이그레이션 작업

기존 인터페이스를 변경해야 한다.

채팅 리뉴얼 과정에서 Firestore에 저장되는 데이터의 인터페이스가 변경되었습니다.

그대로 다른 db로 옮기는 요구사항이었다면 Firestore Export/Import 방식을 사용했을 것 같습니다. 이는 데이터 양이 많은 경우 유용한 방법입니다.

하지만 기존 것을 그대로 사용할 수 없었기 때문에 새로운 인터페이스로 변환하는 작업이 필요했는데, 마이그레이션 과정에서 인터페이스를 변환하는 로직을 추가하여 처리했습니다.

async #convertNewFanChatType({ message, databaseIds, data }: ConvertFunParamType) {
      // 기존 인터페이스에서 제외할 필드
      const deleteFields = this.#DELETE_FIELDS_BASE_ARRAY.concat(['delete1, delete2', ...]);

      // baseData에서 기존 필드를 제거하고 새로운 필드를 추가
      const newData: newChatType = {
         ...this.#convertBaseData(this.#deleteV1Field(data, deleteFields)),
         userType: data.userType,
         newField: data.new,
         ...
      };

      // 마이그레이션
      await this.#setFirestoreData(message.id, databaseIds, newData);

n개의 db를 생성하고 각 팬에게 할당된 db id에 해당하는 db로 데이터를 올바르게 마이그레이션한다.

부하를 분산하기 위해 Firestore db를 여러 개 생성하고 각 팬에게 고유한 db id를 할당했습니다.

db id는 팬 테이블에 추가된 별도 컬럼으로 저장되었고, 팬별로 할당된 db id를 기준으로 각 팬의 데이터를 해당 db로 마이그레이션했습니다.

팬 메시지 1개를 마이그레이션 할 때마다 해당 팬이 어떤 db_id를 가지고 있는지 rdb를 계속 조회해야 해서, 해당 데이터를 미리 Elasticache로 마이그레이션하고 이를 활용했습니다.

마이그레이션 코드를 올릴 인프라가 필요하고 실패 시의 처리를 고려해야 한다.

3번(자동화 인프라)과 4번(안정적인 실패 처리)은 서로 밀접하게 연결되어 있어 함께 설명합니다.

1억 건 이상의 데이터를 수동으로 처리할 수 없었기 때문에, Lambda 배치 작업과 SQS를 활용하여 자동화했습니다.

이 시스템은 실패 시에도 데이터 유실 없이 안전하게 재처리할 수 있도록 설계되었습니다.

1. 15분 간격 배치 실행
   마이그레이션이 완료되지 않은 아티스트를 Elasticache에서 조회합니다. 이미 완료된 경우 조회되지 않습니다.
   
   
2. SQS로 작업 전달
   병렬 처리를 하기 위해 n명의 아티스트를 SQS로 전달합니다.
   
   
3. Lambda로 마이그레이션 실행
   SQS에서 전달받은 메시지를 기반으로 Lambda 함수가 실행됩니다. 이 과정에서 너무 많은 아티스트를 병렬 처리하면 네트워크 대역폭 제한에 걸리거나, Firestore write 제한에 걸릴 수 있습니다. Lambda 메모리를 올려서 대역폭을 증가시키는 방법을 사용할 수 있습니다. Firestore의 경우 마이그레이션이 완료되면 완료 여부를 Elasticache에 저장하고 슬랙으로 알림을 보냅니다.
   
   
4. 실패 시 안전한 재시작
   배치 실행 시 새 저장소(new db)의 마지막 created_at 이후의 데이터를 기존 저장소(old db)에서 조회합니다. 따라서 도중에 실패하더라도 다음 배치에서 데이터의 유실 없이 재처리할 수 있습니다. 너무 많은 양의 데이터를 조회 시 Lambda의 메모리가 부족할 수 있어, 메모리 사용량을 체크하며 조회 수를 조절했습니다.

마치며

위 방식을 통해 채팅 데이터를 안정적이고 효율적으로 마이그레이션할 수 있었습니다.

글을 관심있게 읽어주신 모든분께 감사드립니다.