突然の指名を受け、初のKubernetes案件にチャレンジ
株式会社grasysは2014年11月にスタートし、創業5年目を迎えた若い会社だ。登壇時の社員数は25名で、うちエンジニアは代表を含め17名の「少数精鋭」の企業でもある。すでに現在、エンドユーザー数にして3億ユーザー以上（延べ）を擁し、コンシューマ、スマートフォン、PCゲームなど多彩なサービスのインフラを提供している。
「運用しているインフラの規模も、4500本を超えるVMインスタンスが稼働していて、1秒あたりのリクエスト数は約200万件。それぞれのサービス規模も、例えば1システムあたりのインスタンスが2200台と、かなり大きなインフラを管理しています。また GCP のプロジェクトもおよそ180プロジェクトが稼働しています」（泉水氏）
この他にも、Webシステムや分析基盤システムまで幅広く手がけており、今回の事例に登場する GCP の領域でも高い技術力を持ち、Google Cloud プレミアサービスパートナーの認定を受けている企業だ。
そうしたgrasysで入社以来、インフラエンジニアとして設計から構築、運用までを手がけてきた泉水氏だが、ある日突然、それまで経験したことのない分野の構築担当に指名され、大いに戸惑ったという。
「業務自体は、コンソールゲームの共通基盤プラットフォーム構築なのですが、これを GCP のマネージドサービスである GKE で構築せよ、との指示でした。ところが私は、それまでKubernetesを一度も手がけたことがなく、正直なところ、どうやったらいいのか見当がつきませんでした」と泉水氏は振り返る。
もともと他のKubernetesに慣れたエンジニアの担当だったが、そちらが手一杯で急遽、泉水氏に白羽の矢が立ったそうだ。だが、選ばれた以上は経験の有無にこだわっている場合ではない。早速、泉水氏は腹を決めてプロジェクトに取りかかった。
ここで泉水氏は改めて、簡単にKubernetesのおさらいをする。Kubernetesとは、コンテナ化されたアプリケーションのデプロイやスケーリングを自動化する、オープンソースシステムのコンテナオーケストレーションシステムだ。
一方 GKE は、Google Kubernetes Engine の名称の通り、GCP で提供されているKubernetesのマネージドサービス。これを利用するとKubernetesクラスタを自前で作成する必要がない。泉水氏も、「10分くらい、コンソールの画面からぽつぽつと設定するだけでできてしまう。こんなに簡単にできるのなら、本番環境で活用してもいいなと思いました」と初めて使った時の感想を語る。
開発するシステムは、「コンソールゲーム共通基盤プラットフォーム」と呼ばれ、各ゲームタイトルの共通および固有のKPIを収集／管理するものだ。また、この開発環境として使用する GCP サービスは、GKE に加えイメージのビルドには Cloud Build、データベースには Cloud Spanner、さらに Cloud Datastore も使われている。
「Kubernetesのmanifest管理には、Kustomize を使っています。このツールの利点は、開発環境や本番環境ごとに異なるパラメータを適用したり、必要なリソースを割り当てたりできることです。例えば、開発環境はストレージ10GBでいいけれど、本番環境ではやはり100GB欲しいといった場合も、設定値を環境ごとに変更できます」（泉水氏）
さらに、必要なリソースのmanifestを集約できる（サービスやconfigを1つのファイルにまとめて出力し、それをデプロイできる）といった利点もある。
細かな課題はいくつかあったものの、これらのツールを活用しながら開発は進み、順調に本番環境へのステップを上がっていくことができた。
予期せぬ障害の連続に試行錯誤を重ねながらもついにゴールへ
いよいよ本番環境の構築に入っても、使用する 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
