予期せぬ障害の連続に試行錯誤を重ねながらもついにゴールへ
いよいよ本番環境の構築に入っても、使用する GCP サービスに、フルマネージドのインメモリ データストア サービスである Cloud Memorystore が加わったくらいで、基本的には開発環境と変わらなかった。
「他にもモニタリング環境を、独自のツールと時系列データベースであるInfluxDB、イベント監視ツールPrometheus、そしてグラフ表示ツールのGrafanaと組み合わせて構築しました。とはいえ、基本的にマネージドサービスなので、こちらも特に難しい構成にはならず、問題なく無事にリリースできました」（泉水氏）
だが、初めてのKubernetes案件を終えて一安心の泉水氏を、突然のアクシデントが襲った。そのインフラを利用するゲームのタイトルがリリースされた途端、予想を上回るアクセスが殺到し、アプリケーションが「502エラー」を返すようになったのだ。すぐに確認すると、KubernetesのPod機能が停止していることがわかった。このPodは主にNginxとPHPで構成されている。
「何が悪いのかと調べると、Nginxのコンテナが動かなくなっていました。さらに原因を追っていった結果、ヘルスチェックが通っていないことが判明しました。ロードバランサーからのヘルスチェックは通っているが、コンテナ間が通っていませんでした」（泉水氏）
ここで、Nginxの後のPHPでの処理が詰まってレスポンスが返ってこないことがわかった。この結果、Nginxコンテナが止まってしまい、処理が行われなくなっていたのである。そこでPodを増やして分散しようとかなりの台数を追加したが、アクセスが上回り処理が追いつかなかった。最終的に、プログラムを修正して再度デプロイを行うことになった。
だが、ここでもう1つの問題が起こった。このアプリケーションの性質上、ローリングアップデートを実施していたのが、どういうわけか開始されないのだ。再び泉水氏の原因究明が始まり、そもそもPodが正常な状態でないとアップデートが実行されないことが判明した。
「複数あるPodのうちどれかが正常でないと、処理が詰まってアップデートがそれ以上進まなくなってしまうのです。これではいつまでたっても終わらないので、ローリングアップデートを諦めてブルー／グリーン デプロイメントで事態を回避しようと決めました」（泉水氏）
これは、本番環境（ブルー）と別の本番環境（グリーン）を用意して、ロードバランサーで新旧を切り替える手法だが、泉水氏も実際に行うのは初めてだった。だが、失敗は許されない。開発環境で試験を行った上で本番の切り替えを実行し、「どうにか障害を乗り切ることができました。とはいえ、初めての経験だったのでドキドキしながらコマンドをたたいていました」と泉水氏はその当時の緊張を振り返る。
リリースから8カ月。泉水氏の奮闘の甲斐あって、その後大きな障害も起きることなく安定して稼働中だ。今後の新規要件としては、対抗システムのホワイトリストにIPを登録する課題がある。最初は Google Cloud のマネージド ネットワーク アドレス変換サービスである Cloud NAT が利用できると見ていたが、そのために必要な、既存のクラスタの変更が不可であることがわかり、現在別の方法を検討しているところだそうだ。
最後に泉水氏は、「これは当たり前のことですが、上のホワイトリストの件でもわかるように、GKE クラスタ作成時はリリース後の変更に細かな制約があります。それだけに、将来の運用をじっくりと見据えた上で構築することが大切だと悟りました。同様の案件にこれから取り組む人は、十分に注意して取りかかることをお勧めします」とアドバイスを贈り、セッションを締めくくった。
お問い合わせ
株式会社grasys
