「バスNAVITIME」Google Kubernetes Engine移行時の5つのチャレンジ――プロビジョニング期間を約60分の1に短縮：特集：百花繚乱。令和のクラウド移行（16）（2/2 ページ）

[齋藤公二，＠IT]

クラウド移行時の5つのチャレンジとGCPサービス、OSS活用のポイント

　クラウド移行でチャレンジとなった点として萱島氏は大きく5つを挙げた。「データベースの選択」「データベースのBlue／Green切り替え」「大容量データの高速デプロイ」「NAT（Network Address Translation）サービス」「モニタリング」だ。さまざまなGCPのサービスとオープンソースソフトウェア（OSS）を選定、活用している。

　データベースの選択としては、当時の「Google Cloud SQL」はパブリックIPでしかアクセスできないという制限があったため、「Google Compute Engine（GCE）」のVM（仮想マシン）上に「MySQL」環境を実装し、マネージドサービスに頼らず自前で運用する方針を採用した。

　また、Blue／Green切り替えについては、「Google Cloud DNS」が当時β版だったため、データベースの前段にOSSの「HAProxy」を配置し、Kubernetesのサービスのリソースを使って切り替えるようにした。HAProxyはデータベースの死活チェックとバランシングも担当しているという。

Blue／Green切り替え

　大容量データの高速デプロイについては、あるサービスでPodが起動するときに60GBのデータを参照する必要があり、それに対応することが課題になったという。

　「『Google Cloud Storage』にデータを配置してコンテナ起動時にダウンロードすることが考えられますが、Podのスケールに時間がかかってしまいました。そこで、GCEの『Persistent Disk』に60GBのデータを保存し、複数のインスタンス（経路検索エンジン）から参照することで解決しました。attachが高速で助かりました」（萱島氏）

Persistent Diskで解決

　NATサービスについては、当時は「Google Cloud NAT」がなく、GCE上にNATを構築し自前で運用するかたちにした。現在も外部サービス、オンプレミスとの通信処理で利用しているという。

NATインスタンス

　最後のモニタリングの課題は、「個人的にも大きなポイントだった」と萱島氏は振り返る。モニタリング項目としては「HTTPステータスコードごとのAPIリクエスト数」「Pod／コンテナごとのCPU使用率、メモリ使用率」「NodeのディスクI/O、ネットワークI/O、ディスク使用量」「DNS名前解決状況、Circuit Breaker実行状況」「アクセスログ可視化」などがあった。

　複数のツールを検討したが、NAVITIMEのサービス全体に展開するためコストなどが課題になり、最終的には、OSSの「Prometheus／Grafana」と「Google Stackdriver」を使い分けるかたちとした。

　「Prometheus／Grafanaでは、Kubernetesクラスタ内の各Pod、Nodeのリソース消費量のチェックや、PodのHttpStatusCodeごとのRequestCount、ResponseTimeを見ています。また、StackdriverではCloud Load Balancerのメトリクスの定期監視とアラーティング、コンテナログ参照に用いています」（萱島氏）

新規サービスのプロビジョニングは2カ月から1日に

　本番リリース後の効果として、環境構築のコード化によりリードタイムが短縮したこと、オートスケールにより事前に余剰リソースを確保することが不要になったことを挙げた。

　「これまで約2カ月かかっていたプロビジョニングは1日で終えることができるようになりました。またオートスケールの効果としては、2018年10月1日の台風24号への対応があります。日本に上陸した際にアクセス数が急増しましたが、オートスケールで乗り切ることができました」（萱島氏）

2018年10月1日の台風24号上陸時のアクセス推移

　ただ、いいことばかりではなく、本番リリース後にも幾つかトラブルに見舞われたという。

　「リリースした後、障害を何度も出してしまって、バスの利用者から何度もお叱りを受けました。振り返ってみると、原因のほとんどはKubernetesを使って運用するための知識が足りていなかったことです」（萱島氏）

　その上で萱島氏は、本番リリース前に実施しておいた方がよかったこととして、4つを挙げた。1つ目は「kube-system」で動いているPodの死活監視、2つ目はクラスタ内で名前解決するコンテナが、名前解決に時間がかかるのに備えて、クライアント側でDNSをキャッシュすること、3つ目はKubernetesのHorizontal Pod Autoscalerだけではなく、スパイクアクセスに備えるためのスケールアウトスクリプトを用意すること、4つ目はデプロイ時のスクリプト作成の手間を削減するためのツールの利用だ。

本番リリース前のデプロイフロー

　現在はデプロイツールとして、NetflixとGoogleが主導するOSSの「Spinnaker」を試験導入している。萱島氏はSpinnakerの導入効果として、Kubernetesデプロイ用のテンプレートが用意されており、デプロイパイプラインが簡単に作成できること、マルチクラウド環境へのデプロイが1つのツールできること、G Suiteアカウントとの連携や権限設定を挙げていた。

Spinnakerを利用したデプロイフロー

　本番リリース後も、さらなる改善に取り組んでいる。例えば、Podのリソース消費量に合わせてNodeをカスタマイズ。具体的には、「カスタム マシンタイプ」のVMインスタンスを使うことで、1割ほどのコストを削減した。また、KubernetesのManifestファイルの管理をOSSの「Kustomize」で行うことで効率化を図った。

　さらに萱島氏は今後の取り組みとして、Spinnakerを全Kubernetesクラスタのデプロイに採用すること、Kubernetesバージョンアップ作業の平準化、Kubernetes管理者を増やすことなどを挙げていた。

　ナビタイムジャパンでは、このように迅速なデプロイと管理の効率性を高めることで、環境変化に迅速に対応しさらなるビジネス拡大を目指す方針だ。

参考

• ナビタイムジャパンの導入事例：バスNAVITIMEにGoogle Kubernetes Engineを活用。サービスのコンテナ化を加速しマネージドで効率的なデプロイ環境を実現。 | Google Cloud Blog

この移行事例のポイント

• クラウド移行時に5つの挑戦があったが、安定性を重視するため当時β版だったサービスは使わなかったり、サービスに制限があってもOSSを活用して自前で構築、運用したりするなど、正社員の80％はエンジニアというテクノロジー企業としての強みを生かした。
• 会社の方針としてユーザー用データベースをオンプレミスに配置しておく必要があったが、クラウドで処理を行うAPIサーバを用意し、クラウドと連携させるハイブリッド構成をとった。リソースの比率はオンプレミスを1割、GKEを9割にすることで、「リードタイムの短縮」と「サーバリソースのオートスケール」を実現している。
• Nodeの数は40〜50といった規模感のKubernetesの本番運用は多くの知識が必要で、障害を起こしたりもしたが、問題点を整理し改善に取り組むことで、削減や効率化を進めている。さらなる活用を目指し、人材育成も怠らない。

特集：百花繚乱。令和のクラウド移行〜事例で分かる移行の神髄〜

時は令和。クラウド移行は企業の“花”。雲の上で咲き乱れる花は何色か？どんな実を結ぶのか？　徒花としないためにすべきことは？　多数の事例取材から企業ごとの移行プロジェクトの特色、移行の普遍的なポイントを抽出します。

特集：百花繚乱。令和のクラウド移行〜事例で分かる移行の神髄〜