リリース後に切り戻しを選択せざるを得なかった理由は？
もともと達成しようとしたことが新旧データベースでデータ連携するというアンチパターンで（さらに新旧データベースでテーブルやカラムの構造が異なるなど）、困難が多いにもかかわらずいろいろと手を尽くし、まずは最初のリリースへとこぎつけた。
……はずだった。
河本氏は「非常に残念ですが、ここで切り戻しましょう」と宣言せざるをえない事態に陥った。
理由は大きく2つある。最初のリリースは無事にできたものの、実際に稼働開始した後に解消が困難なエラーが生じたことと、データ連携で許容できない遅延が発生してしまったためだ。
前者のエラーについては、かなりの頻度で生じていた。開発環境で再現できず、原因究明に苦労した。エラーを解消するための処理（データパッチ）が必要となった。エラーが発生すると後続処理にも影響が生じるため、解消まで時間をかけることはできなかった。
エラーについてはすぐに対応する必要があったため、エラーのアラートが発報されたら誰でも対応できるように対応方法をまとめた。同時に原因調査も進めていった。
（余談だが双方向連携プロジェクトは「WAKKA」と呼ばれており、エラーの原因究明していたメンバーの口からは思わず「WAKKA、わっかんない……」とダジャレがでてしまうほどのつらい状況だったようだ）
後者の遅延は「速報性」を売りとするサービスとしては許容できないものだった。先述した通り、入力は新システムで行われ、閲覧は旧システムで行うようになっていた。新システムから旧システムへとデータを移す時に予想以上の時間がかかっていた。
データ連携で遅延が生じてしまう理由に、新旧データベース構造の違いがある。新データベースから旧データベースへとデータを移す時、新データベースの複数のテーブルにあるデータをまとめて旧システムへと送るなど、複雑な処理を行う必要があったため遅延が生じてしまっていた。
そこで河本氏は、マシンスペックを上げ、データ連携の順序を変更し、SQLをチューニングするなどの工夫を重ねて処理速度改善を試みた。しかし手を尽くしてみたものの、解決と判断できる状況にならず、先述したように切り戻しと仕切り直しを決断した。その後に細かな調整を重ねて遅延は改善し、なんとかリリースを完了できたという。
もし同じ取り組みをするなら知っておいてもらいたいこと
最後のまとめとして河本氏は「あまりないかもしれませんが、同じ取り組みをするなら」と教訓をまとめた。
- 双方向連携するツールの事前検証は入念に行う
- ステークホルダーを巻き込んで進める
- データ移行する際、並列処理が可能な設計をする
- データ移行に耐えうるマシンスペックを事前に検証しておく
- リリース手順書は誰が行っても迷わないようにする
- リリースリハーサルは複数回行う
加えて河本氏は「ビッグバンリリースのリスクと、新旧並行稼働に伴う双方向データ連携のリスクを並べ、よく検討した上で方針決定できると幸せになれます。双方向連携を伴う並行稼働は本当にめちゃめちゃつらかったです」と本音を語る。
あらためてビッグバンリリースと双方向データ連携のリスクを比較してみよう。前者のビッグバンリリースでは、動作確認に時間がかかる、切り戻しが困難になる、不具合の切り分けが大変になるなどのリスクが想定されていた。
一方、後者の双方向データ連携では、過去データの移行が大変、データに不整合が生じる可能性があるというリスクは想定していた。しかし、利用ツールの検証に時間がかかる、データ連携で遅延が生じると業務に与える影響が大きい、不具合調査に時間がかかるなどは「見えていなかった」と河本氏は言う。
最後に河本氏は「もし双方向データ連携を伴う並行稼働をする場合は、我々と同じ失敗をしないようにしていただければ幸いです！」と繰り返した。ぜひ教訓にしよう。
