「バスNAVITIME」Google Kubernetes Engine移行時の5つのチャレンジ――プロビジョニング期間を約60分の1に短縮：特集：百花繚乱。令和のクラウド移行（16）（2/2 ページ）
多数の事例取材から企業ごとのクラウド移行プロジェクトの特色、移行の普遍的なポイントを抽出する本特集「百花繚乱。令和のクラウド移行」。ナビタイムジャパンの事例では、Google Kubernetes Engine移行時のポイントを中心にお届けする。
クラウド移行時の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はデータベースの死活チェックとバランシングも担当しているという。
大容量データの高速デプロイについては、あるサービスでPodが起動するときに60GBのデータを参照する必要があり、それに対応することが課題になったという。
「『Google Cloud Storage』にデータを配置してコンテナ起動時にダウンロードすることが考えられますが、Podのスケールに時間がかかってしまいました。そこで、GCEの『Persistent Disk』に60GBのデータを保存し、複数のインスタンス（経路検索エンジン）から参照することで解決しました。attachが高速で助かりました」（萱島氏）
NATサービスについては、当時は「Google Cloud NAT」がなく、GCE上に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号への対応があります。日本に上陸した際にアクセス数が急増しましたが、オートスケールで乗り切ることができました」（萱島氏）
ただ、いいことばかりではなく、本番リリース後にも幾つかトラブルに見舞われたという。
「リリースした後、障害を何度も出してしまって、バスの利用者から何度もお叱りを受けました。振り返ってみると、原因のほとんどはKubernetesを使って運用するための知識が足りていなかったことです」（萱島氏）
その上で萱島氏は、本番リリース前に実施しておいた方がよかったこととして、4つを挙げた。1つ目は「kube-system」で動いているPodの死活監視、2つ目はクラスタ内で名前解決するコンテナが、名前解決に時間がかかるのに備えて、クライアント側でDNSをキャッシュすること、3つ目はKubernetesのHorizontal Pod Autoscalerだけではなく、スパイクアクセスに備えるためのスケールアウトスクリプトを用意すること、4つ目はデプロイ時のスクリプト作成の手間を削減するためのツールの利用だ。
現在はデプロイツールとして、NetflixとGoogleが主導するOSSの「Spinnaker」を試験導入している。萱島氏はSpinnakerの導入効果として、Kubernetesデプロイ用のテンプレートが用意されており、デプロイパイプラインが簡単に作成できること、マルチクラウド環境へのデプロイが1つのツールできること、G Suiteアカウントとの連携や権限設定を挙げていた。
本番リリース後も、さらなる改善に取り組んでいる。例えば、Podのリソース消費量に合わせてNodeをカスタマイズ。具体的には、「カスタム マシンタイプ」のVMインスタンスを使うことで、1割ほどのコストを削減した。また、KubernetesのManifestファイルの管理をOSSの「Kustomize」で行うことで効率化を図った。
さらに萱島氏は今後の取り組みとして、Spinnakerを全Kubernetesクラスタのデプロイに採用すること、Kubernetesバージョンアップ作業の平準化、Kubernetes管理者を増やすことなどを挙げていた。
ナビタイムジャパンでは、このように迅速なデプロイと管理の効率性を高めることで、環境変化に迅速に対応しさらなるビジネス拡大を目指す方針だ。
参考
この移行事例のポイント
- クラウド移行時に5つの挑戦があったが、安定性を重視するため当時β版だったサービスは使わなかったり、サービスに制限があってもOSSを活用して自前で構築、運用したりするなど、正社員の80％はエンジニアというテクノロジー企業としての強みを生かした。
- 会社の方針としてユーザー用データベースをオンプレミスに配置しておく必要があったが、クラウドで処理を行うAPIサーバを用意し、クラウドと連携させるハイブリッド構成をとった。リソースの比率はオンプレミスを1割、GKEを9割にすることで、「リードタイムの短縮」と「サーバリソースのオートスケール」を実現している。
- Nodeの数は40〜50といった規模感のKubernetesの本番運用は多くの知識が必要で、障害を起こしたりもしたが、問題点を整理し改善に取り組むことで、削減や効率化を進めている。さらなる活用を目指し、人材育成も怠らない。
特集：百花繚乱。令和のクラウド移行〜事例で分かる移行の神髄〜
時は令和。クラウド移行は企業の“花”。雲の上で咲き乱れる花は何色か？どんな実を結ぶのか？ 徒花としないためにすべきことは？ 多数の事例取材から企業ごとの移行プロジェクトの特色、移行の普遍的なポイントを抽出します。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
クラウド移行に「コスト削減」ばかりを求めてはいけない理由〜経営層に贈る言葉〜
ビジネスに一層のスピードと柔軟性が求められている今、それを支えるインフラとしてクラウドを検討することはもはや当たり前になっている。既存システムのクラウド移行を支援するベンダーも複数存在し、クラウド活用のハードルも下がってきた。だが使いやすくなったことと、クラウドの効果を獲得することは、また別の話だ。ではなぜクラウド移行でメリットを享受できない例が多いのか。その真因を探った。
既存システムのクラウド移行、考えるべき2つのポイント
コスト削減、運用負荷低減という「目前の課題」解消だけに、視野が閉じてしまいがちなクラウド移行。その現状に見る、日本企業とSIerの課題とは。
変わる「リフト＆シフト」の意味――既存システムのクラウド移行、成功のポイント
AI、IoT、データ分析など、ITを活用して新しいビジネスに取り組む企業が増えている。その実践基盤として不可欠となるクラウドだが、デジタル変革に真に生かすためにはどのようなポイントを押さえておけばよいのだろうか。クラウド移行やサービス選定の考え方をアクセンチュアに聞いた。