ナビタイムが全サービスをAWS移行　アンチパターンてんこ盛りでGPUは生かせるか（1/2 ページ）

AWS採用に早くから取り組んできたナビタイムジャパンが、全サービスをAWSへ移行。同プロジェクトで得た効果と、同社サービスには不向きだと考えられる「GPUインスタンス」の活用で目指す効果について詳しく語った。

公開 2018年07月31日 05時01分

更新 2018年07月31日 10時19分

著者

重森大

[著]

印刷する

　地図ポータルサイト／ナビゲーションサービス「NAVITIME」を運営するナビタイムジャパンは2018年6月、Amazon Web Servicesの年次カンファレンス「AWS Summit Tokyo 2018」に登壇。「AWS Summit Tokyo 2017」に続き、2018年も示唆に富んだ発表をした。全サービスを「Amazon Web Services」（AWS）へ移行するプロジェクトで得たノウハウや効果に加え、今回はGPU（画像処理プロセッサ）を利用したインスタンス（仮想マシン）であるGPUインスタンスを使った経路探索の実証実験についても発表した。

併せて読みたいお薦めの記事

位置情報に基づく行動分析の事例

ゼンリンデータコムのビッグデータチームが指南、AWSマネージドHadoopの勘所とは？

AWS Summit Tokyo 2018レポート

NAVITIME本番サービスをAWSに次々と移行

　ナビタイムジャパンのAWS採用は2013年に始まった。「AWS Summit Tokyo」の初開催が2012年であることを考えると、かなり早い段階からクラウド化を視野に入れて動き始めていたといえる。最初はデータ分析基盤の一部をAWSで稼働させるべく、システムを構築しながらAWS利用のノウハウを探った。本番サービスでAWS利用が本格化したのは、2年後の2015年。交通コンサルティング事業のデータ分析システムと、それに続いて海外旅行者向けサービス「NAVITIME Transit」がAWSで稼働を開始した。これらを皮切りに、ナビタイムジャパンは全サービスをAWSに移行するプロジェクトを本格化させた。

　こうしたナビタイムジャパンのサービスの多くは、外的要因によって大きく負荷が変わる。電車の遅延や天候不良、連休などの際にアクセスが急増する。ナビタイムジャパンのインフラエンジニア田中一樹氏（クラウド担当）は「外的要因を見越したサーバ増強は都度工数がかかる上に、サイジングを見誤るとユーザーが必要なときに輻輳（ふくそう）を起こしてサービスが提供できなくなる恐れがあります」と話す。NAVITIME Transitの稼働実績もあったことから、各サービスを順次AWSへ移行することにした。

ナビタイムジャパン　田中一樹氏

　移行の基本方針は3つ。アクセス増加時に自動でスケールアウトできるようにすること、インフラを全てコード化すること、アプリケーションはコンテナ化すること。それぞれ「AWS Auto Scaling」「AWS CloudFormation」「Amazon EC2 Container Service」（ECS）で実現できる内容だ。最初に移行した「乗換NAVITIME」では輻輳が減少し、それに伴い障害も大幅に減少した。アクセス推移に応じて自動で拡張／縮小するので、サーバ増強などの工数も不要になった。

Auto Scalingによりアクセス推移に合わせたサーバ増減に自動対応

　「移行当初は予想に反してオンデマンドよりも高コストになるという課題がありましたが、約1年かけてチューニングした結果、コスト問題も解決しました」（田中氏）

　移行直後はオンプレミス環境との並行運用期間もあり、一時的に高コストになることはある程度予想していた。しかしAWSにかかるコストが予想以上に高かったのだという。特に仮想マシンサービス「Amazon Elastic Compute Cloud」（EC2）やデータベースサービス「Amazon Relational Database Service」（RDS）のオンデマンドインスタンス（従量課金で利用するインスタンス）にコストがかかっていた。そこでEC2をスポットインスタンス（入札額に応じて利用料金が決まるインスタンス）とリザーブドインスタンス（長期利用を前提に利用料金を割り引くインスタンス）にし、RDSもリザーブドインスタンスに変更。スポットインスタンスについては、その集合体であるスポットフリート化し、フリート全体で自動的にスケールアウト（オートスケーリング）するようにした。これによりオンデマンドインスタンスと比べて最大90％のコスト削減を実現。アプリケーションはコンテナ化されているので、不意のシャットダウン時にも自動的に再起動できる。

　こうしたノウハウを身に付け、2017年には歩数計アプリケーションの「ウォーキングNAVITIME」と、メインサービスであるNAVITIMEをAWSへ移行した。

AWSならではの工夫をこらし、効果を上げたナビタイムジャパン

　NAVITIMEは、公共交通機関、自動車、徒歩のナビゲーションを組み合わせたナビタイムジャパンのメインサービスだ。AWS移行第3弾でメインサービスに手を付けたのは、やはりAWS移行の効果が大きかったからだろう。経路探索という点で似ている乗換NAVITIMEの移行実績もあったので、スムーズに進むだろうという期待もあった。しかしデータサイズの違いがボトルネックとなった。

　NAVITIMEは公共交通機関だけではなく自動車、徒歩を含めている上に、屋根の多いルートなど検索項目も多く、経路探索エンジンに必要なデータは数十から数百GBもあった。「1つのインスタンスに数日に1回、100GB程度のデータをデプロイ（配備）するため、デプロイに要する時間が問題になりました」（田中氏）

　オブジェクトストレージサービス「Amazon Simple Storage Service」（S3）からのダウンロード、ブロックストレージサービス「Amazon Elastic Block Store」（EBS）のボリュームから取得したスナップショットからのコピー、ファイルストレージサービス「Amazon Elastic File System」（EFS）でのファイル共有など幾つもの手段を検討したが、いずれも初回アクセス時のデータ読み込みが遅く、検索に時間がかかり過ぎた。さまざまな手段を模索した結果、ナビタイムジャパンがたどり着いた手段は、デプロイ時に複数のEBSボリュームにデータをコピーしてプールしておくという方法だった。オートスケーリング時には、既に最新のデータが格納されているEBSボリュームを適宜アタッチするようにした。こうすることでオートスケーリング時の初回検索時間の問題が解決した。

デプロイされたEBSボリュームをプールしておき、オートスケーリング時にインスタンスにアタッチすることで課題を解決

　「メインサービスであるNAVITIMEをAWSに移行して3カ月、大きな障害もなく安定稼働しています。運用コストも削減できました。特にアクセスが増加する大型連休前のコスト増も、低く抑えられています」（田中氏）

　ナビタイムジャパンには数多くのサービスがあり、今後も各サービスでのAWS移行を計画している。サーバの輻輳が大幅に減少すること、Infrastructure as Code（コードによるインフラの構成管理）を実現できること、コンテナ化でアプリケーション管理を効率化できることなど、AWS移行が確実な効果をもたらすと分かっているので、ためらいはない。

　機能的な効果以外に、副次的な効果もあった。サービスごとのコストが可視化されるので、社内でコスト意識が高まったという。AWS採用を掲げてクラウド化を前面に打ち出したことでエンジニアの関心を集め、インフラ部門への配属希望者が増えて「人材確保の悩みも解消しました」と田中氏は説明する。

　他にも発表では、S3を使ったセキュアで効率的なログ管理の手法などを紹介し、実際に使って分かった工夫すべきポイントなどを語った。

次ページへアンチパターンてんこ盛りの案件でGPUは生かせるのか