こんにちは。クルーズ株式会社CTOの鈴木です。
今回はこの一連のOS/ミドルウェアバージョンアップの中の残タスクとなっているWebおよびバッチ用のインスタンスの対応の話をしたいと思います。
以前の投稿「脱レガシーシステム⑥（DBインスタンスのOS/MariaDBバージョンを最新安定版にあげた話)」で記載のとおり、2020年の10月にDBまではOS/ミドルウェアバージョンアップが完了して残るはPHP7.4周りのみとなっています。
前提
2020年の10月末からの約1週間がメガセールで、その期間はエンジニアもメガセールに関連する対応、運用監視などで手が空けれないため、メガセール完了後からの作業再開となりました。
とはいっても、「脱レガシーシステム③（OS/ミドルウェアのバージョンアップを計画した話）」のバージョンアップの進め方で記載のとおり、PHP7動作確認用のブランチへのコミットと動作確認はすでに進めていて、メインの作業は機能デバッグがメインでした。デバッグについては進捗が悪く計画より2週間遅れている状況でした。
デバッグの遅れの要因として大きかったのは、すべての画面やバッチについて存在しておらず、稀にしか使わない画面やバッチ、使われ方が多彩すぎる（機能が多すぎる）画面などがあって、デバッグを行った際に想定するシナリオがよくわからないことでした。
これは仕様書が管理されていないという別の問題で、まさに仕様書をかき集めて、不足しているものをリバース作成するプロジェクトを開発部門で実施しています。
ただ、現時点で現在進行中のプロジェクトの成果物を当てにしても意味がないので、ログインや決済、商品選択、検索などエンドユーザが使う主要機の未過去のデバッグ項目書に従ってデバッグ、それ以外はフリーデバッグを依頼し、表示崩れやデータがおかしい箇所を見つけたら開発者に報告してもらう。開発者はデバッグ報告及びログ上に出るFatalエラーをマストでつぶすという形で進めました。
バッチについてはテスト実行してある程度不具合が出ないことさえ確認していれば、万一PHP7移行後に仮に処理が失敗してもそこでログ採取して修正してもリトライできるので楽観的といえば楽観的ですがある程度まで事前に潰せたら、PHP7移行後に修正という方針としました。
メンテナンス中に発生した問題
デバッグ、切り替えの当日スケジュール、作業手順のレビューが終了したタイミングで2020年の11月の4週に4回目のメンテナンスを実施しました。
今回は作業手順としては簡単で、あらかじめ構築しておいた新環境用のEC2インスタンス(AmazonLinux2/PHP7.4)を新環境用に用意したALBに紐づけて準備しておき、DNSの設定として紐づけるALBを変更する、バッチサーバについても旧インスタンスのcronを無効化して新インスタンスのcronをゆうこうにするのみだったため、メンテナンスに入ってから切り替えて、メンテナンスを開ける前の最終動作確認までは極めて順調でした。
問題が発生したのは最終動作確認時で、以下の不具合が出ていました。
１．アプリでログインできない端末がある
原因が分からず3時間ほど様々な仮説を立てては切り分けを行うことを繰り返したのですが結局原因が分からず、ただなぜか時間がたつにつれて次第にこの問題は解消され、最終的には特定の従業員の端末1台でしか発生しない状況になっていました。
挙動から見て、なにかしらのキャッシュ影響のようだと考えられるのですが特定従業員の端末以外でこの問題が発生しておらず、明らかに一般ユーザとは異なる使い方をしている端末、会員アカウントなので、今回のメンテナンスとは別に端末やユーザアカウントの問題の可能性もあるため、今回のメンテナンスに起因した不具合ではないと結論付けてこの問題についてはCloseという判断を行いました。
実際にメンテナンスが明けてから同じ事象が一般ユーザで発生していないためおそらくデバッグで使っていた端末、会員アカウントに起因する問題だったようです。これはこれで問題で、デバッグ端末やデバッグアカウントは一定期間過ぎたらリセットして通常のユーザに近い状態を作成しておかないと正しくデバッグできなくなるので次回バージョンアップメンテナンスを行う前までには準備作業としてやることします。
２．決済が行えない決済手段が２つあった
結論、両方とも今回のバージョンアップ起因ではなかったです。
片方の決済手段については決済システムの仕様としてIPアドレス制限が実際には存在したが、そのことが社内資料に記載がなかったため、決済システムの管理画面上でIPアドレスを変更するというタスクが計画時点で漏れていたことが原因。
もう一方の決済手段については、これも決済システムの仕様で、つなぎ先サイト画面手ナンス中は決済が行えないような仕様となっていることが原因。
原因が判明したのは計画上でメンテナンスを開けなければならない時間だったため、この２つの決済手段のみ選択不可の状態でメンテナンスを開け、開けた後に動作確認が行えた決済手段ごとに決済を選択可能とし、最終的にはメンテナンス明けから1時間後にはすべての決済手段が利用可能な状態となり、一連の作業は終了しました。
メンテナンス終了後に発覚した問題
懸念していたとおり、バッチ処理周りで問題が発生しました。
具体的にはCRMツールでデータ連携できない問題が発生していました。
原因としては２点で、１つ目はリポジトリで管理されていない野生のコードと設定ファイルが存在していて、それらのファイルが移行対象から漏れたこと、２つ目はバッチが生成する一時ファイルを格納するフォルダが移行後のインスタンスに存在していなかったことがそれぞれ原因でした。
前者は該当する旧インスタンスから新たにリポジトリ内に格納したうえで、移行後のインスタンスに移し、後者については作業ディレクトリとパーミッションを設定し正常動作するようになりました。
上記以外で厄介な問題として、PHP7.4にバージョンアップ後にSQLを発行した際に意図したインデックスが使われない問題というのが発生していた増したが、これはPHP7.2以降でPDOでINT型をバインドする際の内部動作が変更になったことが原因と後日分かり修正を実施し解消しました。
また今回のバージョンアップは社内でもそれなりに大ごとだったため、各営業部門の従業員がメンテナンスが明けてから本番環境で変なところがないかを本当に細かく見てくれたおかげで、PHP7.4へのバージョンアップとは無関係で元々の環境から不具合を起こしていた個所を2か所ほど見つけてくれ、そこも併せて修正対応を実施しました。
まとめ
今回のWeb/バッチインスタンスのバージョンアップについては、バージョンアップに伴う技術的な話よりも、仕様の文書化。ナレッジ化ができていないことによる問題のほうが多かったと感じています。
リポジトリ管理外のコードやPDOの内部動作の仕様変更に関わる部分は今回のタイミングを機に直しましたでよいと思うのですが、仕様が把握できていなかった問題、特に決済システムやCRMツールなどの外部システム連携周りの仕様が把握できていないことは致命的で、今回のメンテナンス中に発覚した仕様漏れについては社内の文書に更新し、今後の再発防止につなげていきたいと考えています。
ただ、全体通してはユーザ影響を最小限に抑えた形でOS/ミドルウェアのバージョンアップができたのではないかと思っています。
PHP7.4へのバージョンアップ対応については本格的に動き出したのが9月下旬で、対応完了が11月下旬なので約2カ月間でPHPのメジャーバージョンを跨ぐバージョンアップを行ったことになります。
正直今回かなり強引な進め方をしましたが、この規模のサイトでこの期間で無事にバージョンアップ対応を行えたのは以前のDBのバージョンアップ対応の際にも触れたとおり当社のエンジニアの技術的なスキルの高さと圧倒的な問題解決能力に本当に助けられてのことだと思っています。
今回のこのWebインスタンス及びバッチインスタンスのOS/ミドルウェアのバージョンアップ完了をもって、今回のスコープで行おうとしていたインフラ的なレガシーシステム脱却はほぼ完了しました。
まだ投稿記事としては作成していないのですが、「インフラ的な話としてAWS Auto Scalingを利用したインスタンス管理に切り替えた話」があり、次回投稿したいと思います。
