コンテンツに移動
Google Cloud

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

2018年1月25日
Google Cloud Japan Team

https://storage.googleapis.com/gweb-cloudblog-publish/images/NTJ_BI010101_v100.max-300x300.png

注目のコンテナ技術の採用で、柔軟なスケールを実現した Google Kubernetes Engine を活用し効率的なデプロイ環境を整え、サーバー構築の自動化、短縮化に成功した事例を紹介します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/fep4uOt5BrphmB6ZoRmnrp1O0nGLHVL9_FFZXm68NAS.max-900x900.JPEG
エンジン開発部 萱島 克英氏

■ 利用している Google Cloud Platform サービス

Google Kubernetes Engine

https://cloud.google.com/kubernetes-engine/?hl=ja

, Stackdriver Logging など

■ 株式会社ナビタイムジャパン
1996 年から経路探索に取り組み、生活に欠かせない自動車道や各種交通機関のルート探索を、Web サイトやモバイルアプリで広範囲に対応し、多くのユーザーに愛用されています。公共交通機関から徒歩に至るまで、さまざまな移動手段を使って出発地から目的地までの最適な経路を探索・ナビゲーションできる独自の探索エンジンを使ったサービスが特徴で、性質の異なる移動手段を組み合わせたルート探索を実現しています。

プロビジョニング作業を効率化するためにコンテナを活用

ナビタイムジャパンでは、サービスの一環として Android / iOS 向けにさまざまなアプリを提供しています。そのアプリの 1 つに、バスの乗り換え案内や停車駅、運行情報など、バスに関するさまざまな情報を一元的に提供する「バスNAVITIME」があります。このアプリを提供するためのサーバー構成は一般的な三層構造で、インフラとしてオンプレミスで独自に構築したものが使われていました。
しかし 2016 年頃、オンプレミスで運用していたシステムをクラウドに移行します。その理由について、ナビタイムジャパン 萱島 克英さんは次のように説明します。
「2016 年以前はほとんどのサービスをオンプレミスで運用していたのですが、その頃からこれらのサービスをクラウドに移行しようという流れが出てきました。2016 年以前も、一部のサービスでスモールスタートの形でクラウドを利用し、どのような効果があるのかを検証してはいたのです。その結果が出始めたことで、各種サービスを本格的にクラウドに移行することになりました。」

https://storage.googleapis.com/gweb-cloudblog-publish/images/LemwD1gX4S9gMfT7YBac0MsSYqoHNzjE85vQG2TLmv5.max-700x700.JPEG

クラウド移行の目的として挙げられたのは、システムの構築およびプロビジョニングに要する時間の短縮です。
「以前のサーバー構築作業では、ハードウェアの調達、データセンターでのラッキング作業、OS などソフトウェアのインストールなど、いろいろ含めると約 2 週間のリードタイムが発生していました。そこでクラウドに移行し、システム構築やプロビジョニングのフローを自動化し、短縮しようという大きな目的を設定しました。」
この目的を達成するために、バスNAVITIME において積極的に利用されたのがコンテナ技術です。コンテナは仮想化技術の 1 つですが、ハードウェアを仮想化して利用するサーバー仮想化とは異なり、OS が持つコンテナ機能を使って個別の実行環境を作成し、その中でアプリケーションなどを実行します。こうした仕組みのためにオーバーヘッドが小さく、またコンテナの管理も容易に行えることから、新たな基盤技術として多くの技術者に注目されています。萱島さんもこのコンテナ技術に大きな可能性を感じたと言います。

「単純にシステムをクラウドに移行するだけでなく、アプリケーションをコンテナ化した上でクラウドに移行するという手法を採りました。実際に運用したところ、デプロイがすごく楽になったことが一番大きなメリットだと感じました。何か機能を追加した際、オンプレミスであれば実際に動かすまでにさまざまなステップが必要だったのですが、コンテナ技術を採用したことで、数クリックでデプロイできるようになった。これは大きな違いでした。」

このように考えた背景には、オンプレミスで運用していた時代にデプロイ作業の自動化があまりできていなかったという反省があったと言います。デプロイなどを行う際、「まずこのコマンドを入力して、次のこの作業を行って」など、作業の手順をドキュメント化しておき、その内容に従って作業するフローだったとのことで、これを改善するためにもコンテナ技術を用いて積極的に自動化に取り組みたいと考えたのです。

また、開発の場面においてもメリットがあると萱島さんは話します。「自分が作ったものを動作確認する際、オンプレミス時代は作成した成果物をサーバーに転送し、そこで実行しなければ動作確認ができなかったわけです。しかしコンテナであれば、そうした作業を自分のマシンの中で完結できることは大きな利点です。新しいオープンソースのツールを簡単に試せるといった部分もコンテナなら容易です。コンテナが持つ、さまざまなメリットは、開発でも本当にありがたいと思います。」

インスタンス起動の俊敏さと永続ディスクが Google Kubernetes Engine の魅力

リリース当初からオンプレミスで運用していたバスNAVITIME のバックエンドシステムを、Google Cloud Platform(GCP)上で提供されている、Google Kubernetes Engine(GKE)に移行しました。その決断の背景には、どのような理由があったのでしょうか。
「インスタンスの起動が極めて速いという特長があり、その部分にすごくメリットを感じたんです。また実際に GKE を使ってみて、単に起動が速いだけでなく、Google 永続ディスクをインスタンスにアタッチする操作が非常に速かったことも魅力に感じました。我々が使う経路探索のサーバーは、大容量のデータを使う上に、そのデータの更新も 1 日に数回行われます。そのため、迅速に大きいデータをインスタンスにアタッチする必要があるのです。ここで Google 永続ディスクを使うと、読み込み専用ではありますが、非常に高速に複数のインスタンスからデータを参照することが可能であり、しかも読み込みも高速ですごく助かりました。」

GKE に移行する前、すでにシステムのコンテナ化は行っており、GKE 導入に際しての追加開発はほとんどなかったようです。GKE で使われているコンテナ オーケストレーターである Kubernetes での運用実績が少なかったため、操作に必要なコマンド調査などは行いましたが、それらも Google のサポートの利用、ドキュメントの参照で解決できたと言います。

インフラを GKE に移行した後、管理業務上で便利だと感じたのが ログデータなどを格納し、リアルタイムで分析できる Stackdriver Logging だったと言います。
「GKE のログを自動的に Stackdriver Logging に集約していますが、それがすごく便利だなと思いました。また Web ブラウザでログをチェックし、条件を指定してフィルタリングできるのもありがたいと感じた部分です。」さらに「GKE は落ちることもなく稼働しており、安定したサービス提供につながっています」と、GKE の安定性についても萱島さんは評価しました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/_k8oYp94rxyifmlQVlLIrRxIrm5fWAshgW0PgwEDh3.max-1000x1000.PNG
バスNAVITIME システム構成図

また萱島さんは、高負荷時に自動でリソースを増強して対応する、GKE のオートスケーリング機能にも大いに期待しています。「現状ではスケーリングはまだ手動なんですね。オートスケーリングについてもすでに検証は行っていますが、まだ準備段階というところです。ただ環境が整ったらオートスケールをサービスに組み込んでみたいと思っています。」

「現時点で GCP 上にインフラを移行しているのは Android 版なのですが、2018 年には iOS 版のインフラも GCP に移行したいと考えています。そうするとアクセス数が今の数倍に増えるため、それに備える意味でもオートスケーリングの実現は欠かせないですね。」

ナビタイムジャパンではバスNAVITIME 以外でも積極的にクラウドが使われています。そこで使われるクラウドサービスの選定において、萱島さんはいくつかのポイントを挙げました。
「各リソースに対して細かく権限を設定できること、将来性が高いこと、俊敏なインスタンスの起動、そしてネットワークのレイテンシですね。ナビタイムジャパンではサービス開発において、1 つのサービスを細かく分割して実現するマイクロサービスの考え方を採り入れています。このため、サービスごとに多数のサーバーを使っていて、それが内部ネットワークを使って連携する形になっています。この内部ネットワークのレイテンシが大きければ、システム全体のレスポンスにも影響しかねません。こういった部分もチェックポイントになります。」

最後に萱島さんは「インターネット上でサービスを提供する際、迅速なデプロイを可能にする環境の構築は作業の効率化につながります。それを実現する上で、コンテナ技術と GKE は大いに役立ちました」と語りました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/ohFk-a1kad3ITDKA1LkuekU4rM82G_75OmBVbQK2sgcr.max-600x600.PNG
https://storage.googleapis.com/gweb-cloudblog-publish/images/6zGvOG4st5OFTFmt4TjmywHrjY-K5dNWEmabAizMV8FU.max-600x600.PNG
https://storage.googleapis.com/gweb-cloudblog-publish/images/Zvee-JuunTzSK0JpWxIZ24n16ZpU8zUpRXq5dugMPg0x.max-600x600.PNG

乗換、停留所、時刻表などさまざまな情報を一度に見られるバスNAVITIME

GCP のその他の導入事例はこちらをご覧ください。

投稿先