9月上旬に行ったAWS移行・・・前編につづいて、後編では移行の直前から移行後までの詳しい流れと、そこで得た学びについてお伝えできればと思います。
移行時の準備
システムの移行は常に「何か問題が起きる」もの・・・事前に用意できるものは、なるべく事前に用意しておきたいものです。
今回準備したものの一例としては、移行当日までに「いつまでに」「誰が」「何を」やっておくべきかをリストにした事前作業チェックシート。これに沿って当日本当に移行できる状態にあるかを確認します。
もう一点は、当日の作業手順を細かく記載したタイムテーブルです。当日は22:00からの深夜作業というのもあり、手を動かしながら考える、という状況はなるべく避けたいので、手順によっては実際打つコマンドや、設定の値、叩くべきURL等を細かく記載しておきます。
事前作業チェックシートも、タイムテーブルも直前に作るわけではなく、３〜４週前から準備しておき、何度か関係者とレビューを重ねてインクリメンタルに確認事項や、作業内容を肉付けしていきます。
その他準備したものとしては、緊急連絡網。各機能群に担当者をアサインして、その機能群に障害が出た場合は、担当者にすぐ繋がるように携帯の番号を控えております。「実際使ったか？」といわれれば実際使いました！・・・準備してよかったものの一つです！
また、全社へのアナウンスも段階的にしておきます。このプロジェクトに関しては、数ヶ月前から少しずつ全社会議等でも共有し情報を透明化してあり、そうすることで実行するメンバーも、直接関わらないメンバーも安心して進めるようにケアしました。テストにも関わっているメンバーが全社員数の1/3くらい居たので、唐突なサプライズ無しに進めることが出来ました。
移行当日
さて、9月3日 土曜日 22:00。
移行作業は、インフラエンジニアの渡邉と加辺、アプリエンジニアの泉、あとビジネスオーナーとして甲木の４名が集まり作業を開始。（この後、移行後の対応でテンパり、急遽山本にジョインしてもらい、結果５名体制で行いました）
今回の移行では、事前に新クラウドにスレーブDBを準備しておいて、旧クラウドのマスターデータベースからレプリケーションを仕込んでいたので、移行当日はマスターをロックし、レプリケーションを切り、新DBをマスターに昇格するだけで楽勝！
・・・の予定だったのですが直前にトラブル発生！
確認のつもりでCTO泉が新システムでテスト注文をしてしまい、旧クラウドのマスターDBと新クラウドのスレーブDBで、データの不整合が起きてしまいました。結局差異が出ているレコードを一つづつ潰して不整合を解消して、40分程のロスタイムで移行作業に。まったくウチのCTOは…
事前に準備した手順書に沿って、旧システムをメンテ画面に切り替え、NFSの同期や、DBの作業を終わらせ、hostsファイルを書き換えて新システムのテストを開始！
全ての機能をチェックすることは不可能なので、ビジネスオーナーの甲木と一緒に新規登録や購入導線、気になっていた印刷データの入稿等、４時間程書けてチェック開始。一定度超えた時点で「後はなんとかなるだろう！」という実感を得たので、DNSの切り替えを行いサービス再開。
朝から渋谷のIT関連のイベントで登壇していた泉は、この時点でダウン。二時間程仮眠に入ります。
移行後おきたこと
落ち着かない雰囲気の中仮眠をとっておりましたが、結局２時間程で目がさめると早速コンビニ決済の支払い完了通知が届かないとのことで障害対応モードに。調べると、支払い完了時に受け取るエンドポイントの一部が叩かれずにいたので、決済サービスの設定を変更して問題を解決。
その後、委託先の印刷会社の一社から連絡があり管理画面の一部に不具合が！この問題は数時間格闘したのですが、原因がなかなか解らず手元では再現も出来ないので、一時は「現地まで行くか」くらいの話をしていたのですが、なんとF5 を押してページをリロードしたら問題解消。
そんな感じで、この後も延々と大小様々な課題が出てきて、予定では日曜日の朝の5時くらいに帰宅するはずでしたが、最終的には夕方の5時の帰宅となってしまいました。時間には余裕を…
学び
すでに前々回のブログで渡邉も記述している通りですが、本当に今回痛感したのはこの一言に尽きます。
「本番でしかテストができない部分は移行後に確実に問題が起きる」
詳細は割愛しますが、移行後起きたことを振り返るとやはり「本番でしかテスト出来ない部分」が主な問題の発生ポイントになります。QAでも検証は行いましたが、そもそも外部連携先が本番向けしかなかったり、と移行後でしか最終的な検証が出来ない部分は多数あります。
- 外部APIを叩く処理
- 外部のウェブサイトに行きデータをスクレーピングする処理
- メールの受取で起動する処理
- 決済処理で決済会社からコールバックリクエストを受ける処理
- 外部ベンダーのCRMツールからコールバックリクエストを受ける処理
それでも、QA環境でテストをした際、最低一度は通った道なので、まだ解決は早くできたほうかと思います。全く知らないコンポーネントに火を吹かれた時にはパニックに陥りそうです…幸いありませんでしたが。
もし何らかのレガシーシステムのサーバー移管を検討されている方へ、あえて３つTIPSをお伝えするとしたら、月並みではありますが以下の３つを選びます。
テスト、テスト、テスト！
もうとにかく、頼れるものはテストしかありません！
E2Eテストを書く時もそうですが、テストを効率良く行うにはテストを簡単にするための様々な工夫が必要だと感じました。効率よくできないと「やらなくなってしまう」という事態にも陥ります。
例えば上記の「外部ベンダーのCRMツールからコールバックリクエストを受ける処理」は、CRMツールのQA環境がないためテストすることは困難です。ここでは、シンプルな shell script を組んで数パラメータ入力することで、簡単にエンドポイントが叩けるような工夫をしています。
なるべく多くのメンバーを巻き込む
この規模のシステムになると「一人の人間で全ての責任を負う」ということは、精神的にもつらいし、所詮無理な話です。
なるべく色々なメンバーを巻き込んでおきましょう。今回はテストを分担して進め、「この機能が動かなかったらあなたの責任です！」と・・・もちろん明確には言いませんが、みんながそれぞれ責任を持つ、という形で進めることで随分とエンジニアの気持ちにも余裕が出来ます。
あと経営陣にもしっかり告知しておきましょう。今回は移行の数時間くらい前に「最後はなんとかなると思いますが、無事故で終わることはないので覚悟を！」と告知してあります。プロジェクトの実行者はエンジニアであるが、全社的な応援が必要なのです…
「何が起こってもおかしくない」と慎重に進める一方で「最後はチームでなんとかできる」という心構え
最後のTIPSは完全に精神論ですが、何が起こってもおかしくない、だから周到に準備をしておこう・・・でも、心配ばかりしていると胃が痛むので、「チームで頑張れば最後は絶対なんとかなるだろう」という希望をもって挑みましょう！
最後に
今回の移行プロジェクトの最大の目的は可用性、完全性、秘匿性の強化・・・つまりセキュリティーの強化でしたが、移行を通じて副次的なプラスが出ています。
アプリケーションのモニタリングは大幅に楽になりましたし、「全面SSL化」というレガシーシステムではなかなか踏み切れない変更も果たせ、設定周りもかなりきれいになりました。新入社員の開発環境の設定も楽になりましたし、いままでミドルウェアと同化していた部分を切り離すことができ、ローカル開発のきっかけも作れました。
今回システムのサーバー移行をやっているときは、観葉植物の「鉢替え」をしているような気分になりました。今後サービスをより成長するために、より適した鉢に入れ替えることで拡張や運用が楽になります。
「もう二度とやりたくない！」と言いたくなるほど移行時に必要なエネルギーは膨大である一方で、長期的なリターンは確実にあると思うので、サーバーインフラの運用に限界が来ているレガシーのシステムをお持ちの方は、是非ご検討あれ！この記事が何かの参考になれば幸いです！
