そもそもなぜ双方向データ連携をすることになったのか
株式会社うるるはCGS（Crowd Generated Service）事業、クラウドソーシング事業、BPO事業でシナジーを生み出し、労働力不足の解決に挑戦している。今回は同社 NJSS事業本部 事業開発部 開発課 チームリーダーの河本周時氏が、システムリプレイスに伴う新旧システムの並行稼働と切り戻しの経緯をリーダーの目線で紹介する。
まずはそもそも新旧システムの並行稼働するに至った背景について。今回のシステムリプレイスではバックエンド、フロントエンド、インフラ、データベース、ほぼまるごと刷新することになっていた。ただしビッグバンリリースは避け、段階リリースを選択することにした。その過程でデータベースを役割で分割することになり、新旧データベースでデータ連携する必要が出てきた。河本氏は「双方向データ連携は一般的にアンチパターンと言われていますが、それを踏み抜きにいきました」と言う。
新旧システムでは構成が異なる。旧システムではWebアプリケーション1台とデータベース1台にしていたところ、新システムではWebアプリケーション2台とデータベース2台にした。旧システムではデータ入力も閲覧も1台でこなしていたところ、新システムではデータ入力と閲覧で分けるため2台とした。ただしリリース当初は、データ閲覧は旧システムが担い、データ入力は新システムから行うため（新システムのデータ閲覧は後からリリースする）、データを新旧で連携する必要があった。
リプレイスで生じた課題と、克服のために工夫したこと
このようなリプレイスではどのような困難が生じ、河本氏はどのように乗り越えたのか。順に見ていこう。河本氏は4つの課題を挙げた。
課題1：双方向連携に利用したツールの理解が困難
データの双方向連携には、SymmetricDSというオープンソースのRDB同期ツールを採用した。ただし日本では利用者が少なく、日本語のドキュメントもなく、ツールの理解に言語の壁が立ちはだかった。そのためデータ連携をどう実現するか、エラーが起きた時にどう対処すればいいのかでも苦労した。有償サポートを契約したものの英語のみだったので、問い合わせのコミュニケーションも苦労したという。
そこで河本氏は変換方法調査チーム、連携実装チーム、課題解決チームと役割分担して、それぞれが割り当てられた課題に専念できるようにした。3チームに分けたことにより、効率的に課題解決が進んだ。
課題2：新旧それぞれのシステム設計とデータベース設計に対しての深い知識が必要
データを新旧の双方向で連携するため、新旧のデータベースと新旧のアプリケーション、どちらも理解しておく必要がある。新旧データベースでテーブルやカラムが異なるため、どうマッピングするかなどが不明瞭だった。旧から新へのデータ移行も危うくなる。
そこで河本氏はビジネスドメインのエキスパートに協力を依頼した。また設計書やER図を入手し、テーブルカラム単位のマッピングや変換表を作成した。
課題3：データの整合性を守りながら数千万行の移行処理が必要
新システム稼働にあたり、数千万行分のデータを旧から新データベースに移行する作業が生じる。旧システムでは外部キーの制約があまりなく、不整合があるデータも散見されていた。新システムでは外部キーの制約が異なることから移行処理が中断してしまうこともあった。クラウドのリソースにも制約があり、処理が中断することや、データ移行にかかる時間が想定以上になることも判明した。
そこで河本氏はデータを年単位で分割し、移行処理を並列化した。またクラウドのマシンスペックも可能な限り大きなものにすることで「爆速で」移行作業を終えることができた。
課題4：限られた停止時間の中で複雑なリリース完遂が必要
システム移行ではよくあるケースで、週末中にリリースを完遂する必要があった。本番のリリース作業手順は複雑になっていた。またデータ移行が正しくできたか確認するところでも時間を要した。本番のリリースを無事に終えられるように、何度もリリースのリハーサルを行った。
河本氏はリリース作業未経験者でも迷わず作業できるように、細かい手順書を用意した（手順は1200ほどあった）。データ確認を効率よく進めるためのチェック用スクリプトも用意した。万が一の事態に備えて、主担当以外のメンバーもリリースリハーサルを実施することで、リリース手順の理解を広めた。
リリース後に切り戻しを選択せざるを得なかった理由は？
もともと達成しようとしたことが新旧データベースでデータ連携するというアンチパターンで（さらに新旧データベースでテーブルやカラムの構造が異なるなど）、困難が多いにもかかわらずいろいろと手を尽くし、まずは最初のリリースへとこぎつけた。
……はずだった。
河本氏は「非常に残念ですが、ここで切り戻しましょう」と宣言せざるをえない事態に陥った。
理由は大きく2つある。最初のリリースは無事にできたものの、実際に稼働開始した後に解消が困難なエラーが生じたことと、データ連携で許容できない遅延が発生してしまったためだ。
前者のエラーについては、かなりの頻度で生じていた。開発環境で再現できず、原因究明に苦労した。エラーを解消するための処理（データパッチ）が必要となった。エラーが発生すると後続処理にも影響が生じるため、解消まで時間をかけることはできなかった。
エラーについてはすぐに対応する必要があったため、エラーのアラートが発報されたら誰でも対応できるように対応方法をまとめた。同時に原因調査も進めていった。
（余談だが双方向連携プロジェクトは「WAKKA」と呼ばれており、エラーの原因究明していたメンバーの口からは思わず「WAKKA、わっかんない……」とダジャレがでてしまうほどのつらい状況だったようだ）
後者の遅延は「速報性」を売りとするサービスとしては許容できないものだった。先述した通り、入力は新システムで行われ、閲覧は旧システムで行うようになっていた。新システムから旧システムへとデータを移す時に予想以上の時間がかかっていた。
データ連携で遅延が生じてしまう理由に、新旧データベース構造の違いがある。新データベースから旧データベースへとデータを移す時、新データベースの複数のテーブルにあるデータをまとめて旧システムへと送るなど、複雑な処理を行う必要があったため遅延が生じてしまっていた。
そこで河本氏は、マシンスペックを上げ、データ連携の順序を変更し、SQLをチューニングするなどの工夫を重ねて処理速度改善を試みた。しかし手を尽くしてみたものの、解決と判断できる状況にならず、先述したように切り戻しと仕切り直しを決断した。その後に細かな調整を重ねて遅延は改善し、なんとかリリースを完了できたという。
もし同じ取り組みをするなら知っておいてもらいたいこと
最後のまとめとして河本氏は「あまりないかもしれませんが、同じ取り組みをするなら」と教訓をまとめた。
- 双方向連携するツールの事前検証は入念に行う
- ステークホルダーを巻き込んで進める
- データ移行する際、並列処理が可能な設計をする
- データ移行に耐えうるマシンスペックを事前に検証しておく
- リリース手順書は誰が行っても迷わないようにする
- リリースリハーサルは複数回行う
加えて河本氏は「ビッグバンリリースのリスクと、新旧並行稼働に伴う双方向データ連携のリスクを並べ、よく検討した上で方針決定できると幸せになれます。双方向連携を伴う並行稼働は本当にめちゃめちゃつらかったです」と本音を語る。
あらためてビッグバンリリースと双方向データ連携のリスクを比較してみよう。前者のビッグバンリリースでは、動作確認に時間がかかる、切り戻しが困難になる、不具合の切り分けが大変になるなどのリスクが想定されていた。
一方、後者の双方向データ連携では、過去データの移行が大変、データに不整合が生じる可能性があるというリスクは想定していた。しかし、利用ツールの検証に時間がかかる、データ連携で遅延が生じると業務に与える影響が大きい、不具合調査に時間がかかるなどは「見えていなかった」と河本氏は言う。
最後に河本氏は「もし双方向データ連携を伴う並行稼働をする場合は、我々と同じ失敗をしないようにしていただければ幸いです！」と繰り返した。ぜひ教訓にしよう。
