ナビタイムが全サービスをAWS移行　アンチパターンてんこ盛りでGPUは生かせるか：汎用的処理にAWSのGPUを採用、コストと性能のバランスは（1/2 ページ）

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

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

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ならではの工夫をこらし、効果を上げたナビタイムジャパン