차량관제, 홈플러스 배차지원 시스템 Migration

차량관제시스템과 홈플러스 배차지원 시스템을 IDC에서 AWS로 Migration 하는 것은 앞서 서술한 Renewal 작업에 버금가는 복잡한 작업입니다.

특히 차량관제시스템은 단말기와 관련한 복잡함이 있어서 전체 시스템을 한꺼번에 이전할 수 없고, 한번에 하나의 고객을 이전하며, 단말기의 위치보고를 위한 전송목적지(IP Address, Port) 전환을 다시 하나씩 진행하고 점검하는 복잡한 업무 프로세스를 수립하여 진행했습니다.

홈플러스 배차지원 시스템의 경우는, 산하의 여러 운송사들의 차량관제시스템 이전을 모두 진행하고, 그 후 배차지원 시스템을 전환하는 방식을 사용했습니다.

이러한 작업은 단지 개발 및 운영의 문제가 아닌, 업무 프로세스 수립과 감독, 절차에 있어서의 정당성 확보 등의 거버넌스 이슈까지 다루어야 하는 일입니다.

참고로, 모든 고객들 중 절반 넘는 고객들의 이관을 완료한 후 인수자에게 프로젝트를 인계했습니다.

차량관제시스템의 Migration

목적: 24/7 가동 중인 차량관제(CVO) 서비스의 고객 및 단말 데이터를 온프레미스(IDC)에서 AWS 클라우드로 서비스 중단 없이(Zero-Downtime) 단계별/고객별 이전.
핵심 과제:

Oracle의 고객별 데이터를 필요에 따라 변환하면서 AWS MariaDB로 실시간 복제
단말기가 AWS를 직접 바라보도록 설정(Cutover)되기 전까지, IDC로 인입되는 실시간 위치데이터의 누락 없는 실시간 복제(Replication)
디스크에 저장된 아카이브 데이터를 AWS S3로 저장.

이관작업의 장애와 해결방안

차량관제서비스의 이관작업에는 몇가지 중요한 어려운 점이 있었으며, 그에 대한 해결 방안이 필요했습니다.

장애	해결방안
이종 데이터베이스 간의 데이터 복제, 일부 변경 또는 개선된 스키마로 인해 단순한 Dump & Restore로 데이터 복제 불가	별도의 스크립트를 작성하여 테이블마다 Oracle 데이터를 읽은 후 MariaDB로 저장. 필요에 따라 데이터 변환.
고객사의 데이터를 복제해도 위치보고전용 단말기는 여전히 기존 IDC의 위치보고수신 TCP 서버로 데이터를 전송. 이 전송방향을 IDC에서 AWS로 돌려놓는 시간이 적어도 수십분에서, 길게는 몇 일까지도 소요됨.	모든 단말기의 방향 전환이 완료되기 전까지는, IDC로 들어오는 위치보고 데이터를 AWS로 실시간 전달하는 시스템을 구축.
고객별로 개별적인 계약이 맺어져 있으므로, 고객마다 이관작업의 절차, 기술지원, 등에 대한 합의 필요	한번에 한 고객만을 이전하며 고객의 최종 확인을 받음. 또한, 단말기 방향전환에 걸리는 시간도 필요함.

이에 따라, 다음과 같은 업무적, 기술적 절차를 확립하여 이관작업을 진행했습니다.

Migration을 위한 업무적 절차

실제는 이 보다 더 복잡하지만, 간단하게 표현하면 아래와 같은 절차로 한 고객의 AWS 이전이 진행됩니다.

이와 같이, 고객의 확인을 받은 후 이관작업이 개별적으로 진행되면서 추가적으로 발견되는 세부적인 문제점을 점진적으로 해결해 나갈 수 있었습니다.

고객 단위 무중단 이관을 위한 기술적 절차

고객사 단위로 무중단으로 안전하게 데이터를 넘기는 4단계 프로세스입니다.

준비단계: Target 지정 & 셋업
1단계: 고객 데이터 복제
2단계: 실시간 위치 데이터 복제
3단계: 대용량 데이터 이관
4단계: 완료 및 리소스 정리 & Cutover

이와 같은 절차를 위해 다양한 스크립트와 시스템 셋업이 필요했으며, 그 구조는 다음의 다이어그램과 같습니다.

다이어그램에 표현된 스크립트 및 시스템은 실제보다 더 단순화되어 있습니다.

[준비단계] 이관 대상 확정 및 셋업

이관이 진행되는 고객을 테이블에 표시하여 실수로 엉뚱한 고객의 데이터를 처리하지 않도록 함.

1단계: 고객 데이터 복제

데이터 복제를 위해 별도의 Perl 스크립트, Stored Procedure 등을 작성하여 사용했습니다. Perl 스크립트는 IDC의 Oracle과 AWS의 MariaDB를 동시에 연결하여 읽고, 필요에 따라 변환하고, INSERT 또는 프로시저를 호출하여 처리하도록 했습니다.

대상 고객의 기초데이터를 Oracle에서 MariaDB로 복제, 필요한 경우 데이터 변환 처리.
대상 고객 및 단말기 목록을 추출하여 위치정보 복제 Agent에 전달.
로그 성향의 데이터를 추출하여 AWS의 테이블로 복제.

2단계: 실시간 위치 데이터 복제 Agent와 AWS에서의 처리

IDC로 들어오는 위치데이터를 AWS로 실시간 복제하기 위해 데이터베이스에서 읽는 방식은 기존 IDC의 데이터베이스에 큰 부하를 줄 수 있으므로 데이터베이스가 아닌 위치데이터가 최초로 기록되는 지점에서 데이터를 읽기로 결정했습니다.

Fluent Bit를 사용하여 IDC의 위치보고수신 TCP 서버의 로그에서 이벤트를 감지하고 위치데이터 패킷만 추출하여 파일로 쪼개어 저장.
inotifywait를 사용하여 Fluent Bit가 저장한 위치데이터 파일의 생성을 감지한 후 스크립트를 호출하여 AWS로 rsync 전송. 이 때, 앞선 1단계에서 생성된 고객의 단말기 목록을 사용하여 위치데이터 필터링.
AWS에서도 inotifywait를 사용하여 rsync로 전송된 위치데이터 파일을 감지하고 단말기 Emulation 스크립트를 호출하여 AWS의 위치보고수신 TCP 서버로 데이터 입력하면 데이터베이스에 위치데이터가 저장됨.
AWS의 위치보고수신 TCP 서버를 일반 단말기가 연동하는 서버와 별개로 설치하여 혹시 발생가능한 장애에 분리대응할 수 있게 함.

이 단계는 사실상 개발자가 최초로 셋업한 상태에서 자동으로 진행되므로 실제로 위치데이터가 AWS에 잘 기록되는지 확인만 하면 되게 했습니다.

3단계: 대용량 데이터 이관

일부 과거 경로/로그 대용량 데이터는 별도의 스크립트를 작성하여 수동으로 이관합니다. 수동이라 함은, 모든 것을 직접 실행한다는 의미가 아니라, 모든 세부적인 작업을 수행하는 스크립트를 정해진 절차에 따라 실행한다는 의미입니다. 위 다이어그램 참조.

4단계: 완료 및 리소스 정리 & Cutover

운영담당자가 각 단말기들의 위치보고서버 IP address와 Port 변경을 완료하면 위치데이터는 더 이상 IDC에 저장되지 않게 됩니다.

이를 확인한 후 별도의 스크립트를 실행하여 최초 이관 준비단계에서 표시했던 내용을 삭제하고, 1단계에서 저장했던 단말기 목록을 삭제함으로써 동기화 파이프라인에서 해당 고객이 제외되고 이관이 완료됩니다.

이관작업 지원을 위한 별도의 사이트 개발

전체 이관작업은 수개월이 소요되며, 이관 도중에 인수인계가 계획되어 있었으므로, 본인 뿐만 아니라 인수자, 운영담당자가 현재 상황을 함께 지켜보며 업무 진행을 용이하게 할 수 있는 시스템이 필요하다고 판단했습니다.

이에 별도의 상황판 사이트를 작성했습니다.

이관 작업 지원 관리자 사이트 — 상황판. 고객정보 노출 우려로 윗부분만 캡처

상황판은 Node.js, React를 사용하여 작성했으며, IDC와 AWS의 각 데이터베이스를 동시 연결하여 정보를 읽도록 했습니다.

구분	내용
상황판 Backend	Node.js 사용하여 작성. Oracle과 MariaDB 동시 연결
상황판 Frontend	React, MUI.

상황판 사이트는 각 고객별로 실행할 스크립트를 순서대로 간편하게 Copy & Paste로 실행할 수 있게 만들었습니다.

엔지니어링 핵심 성과 (Engineering Value)

서비스 중단 시간 Zero (Zero-Downtime): DB 복제 방식이 아닌 미들웨어 로그 레벨 CDC(Change Data Capture) 방식을 설계하여, 기존 운영 서비스 영향을 최소화하면서 실시간 2중 데이터 동기화.
이종 간 데이터베이스(Heterogeneous DB) 완벽 이전: Oracle 구조의 데이터를 MariaDB 환경에 맞추어 스키마/TSV 파싱 및 트랜잭션 오류 정제 절차를 자동화.
Archive 처리 분리. 대용량의 Archive는 긴급하게 요구되는 데이터가 아니므로 별도로 처리하게하여 고객의 기초데이터만 전송하면 즉시 새로운 AWS의 사이트를 이용할 수 있게 함. 즉, 고객의 사용자 경험 공백을 최소화 시킴.
상황판 제공으로 이전작업을 진행하는 개발자와 운영자의 소통 강화 및 원활한 업무 지원

홈플러스 배차지원 시스템 Migration

홈플러스는 자신이 직접 차량을 보유하고 있지 않습니다. 다수 운송사들의 차량을 사용(3자물류)합니다.

이 운송사들의 차량들은 홈플러스 배차지원 시스템에 위치데이터를 제공해야 하므로, 이 운송사들은 개별적으로 차량관제서비스의 고객이어야 합니다.

따라서, 홈플러스 배차지원 시스템 Migration은 개별 운송사들의 차량관제시스템 이관을 포함하게 되며, 기술적으로는 차량관제시스템 이관보다 어렵지는 않지만, 절차적으로는 더 복잡한 과정을 거치게 됩니다. 단순화 시키면 다음과 같이 그릴 수 있습니다.

모든 운송사의 차량관제 이전과 단말기 위치보고 방향전환 작업은 앞에 서술한 차량관제시스템의 Migration에 설명되어 있습니다.

홈플러스 배차지원 시스템의 (1차 또는 최종) 이전은 다시 다음과 같은 과정을 거칩니다.

차량관제와 마찬가지로 이종 데이터베이스 간의 데이터 복제, 일부 변경 또는 개선된 스키마로 인해 단순한 Dump & Restore로 데이터 복제가 불가하므로 각 단계마다 별도의 Perl 스크립트를 작성하여 테이블마다 Oracle 데이터를 읽은 후 MariaDB로 저장하고, 필요에 따라 데이터를 변환했습니다.

참고로, 홈플러스는 회생절차와 관련된 문제 등으로 이전작업 중에 2종의 센터에서 테스트를 완료하지 못한 상태로 인수하는 개발자에게 7월말에 인계하였습니다. 단, "하림"으로 매각된 Express 센터들은 테스트를 완료하여 AWS에서 운영되는 새로운 시스템을 사용하고 있는 상황입니다

← 이전: 홈플러스 배차지원 시스템 Renewal 다음: 언어학습 앱 링고붐붐 →