[レポート] 【ナビタイムジャパン様ご登壇事例】ナビタイムが導く AWS 活用への最適経路 #AWSSummit

2018年05月30日(水)〜2018年06月01日(金)の計3日間に渡り、グランドプリンスホテル新高輪（国際館パミール、飛天）で開催されています。

当エントリでは2018年06月01日に行われた『【ナビタイムジャパン様ご登壇事例】ナビタイムが導く AWS 活用への最適経路』に関するレポートをしたいと思います。

-- AWS Summit Tokyo 2018（2018年5月30日～6月1日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通りです。

セッションレポート

以下、セッションのレポートです。

はじめに

田中さんより

• アジェンダ
  • ナビタイムジャパンの紹介
  • ナビタイムジャパンでのAWS活用
  • データ分析基盤
  • ナビタイムサービス
  • GPUでの超並列経路検索の仕組み

ナビタイムジャパンについて

• 440名ほどいるがエンジニアが８０％
• 様々なアプリケーションサービスを提供している

Athenaを採用したデータ分析基盤

• Athenaを採用しデータ分析基盤を構築した事例（AWS導入事例として公開されている）
• ログ分析のポイント
  • 集計に時間がかからないこと : 数秒から数分
  • 集計にコストをかけない
  • とにかく安く
  • 詳細なアクセス権限の管理ができること : 閲覧権限は厳しく設定（位置情報を含む個人情報の保護に配慮）
• ログは適切な管理が必要
  • IAMポリシーを利用
  • 社内からのアクセスも適切に監視できる必要がある : Athenaのクエリ履歴とCloudTrailから追跡可能としている
  • 社外からのアクセスは不可 : IAMポリシーとスイッチロールの組み合わせで対応
• Atehenaを採用したことでセキュリティ的な課題を解決できた
  • Glueと連携させることでパフォーマンス向上に期待

AWS活用

• サービスの性質上、アクセス推移は外的要因大きく変わる
  • 柔軟なスケールが可能なAWSへの移行を決意した
• 移行方針
  • アクセス増加時に自動でスケールさせる
  • 構築はすべてCode化する
  • アプリケーションはコンテナ化する
• 費用面は、EC2でスポットフリーととRIを利用、RDSはRIの利用でコスト削減
• 大容量データのデプロイは、EBSをプールしておくことで対応

AWSへ移行して得られた効果

• サーバの輻輳が大幅に減った
• インフラの構成をコード化
• コストの可視化によるコスト意識の増大
• インフラエンジニアの採用が加速した

GPUについて

吉濱さんより

• 超並列経路探索についてのおはなし

最初に結論

• GPUでは不向きと言われている処理でもGPUを活用できた
• GPUの進化により、かなり汎用的な処理でも手軽に高速化できる
• GPUインスタンスは低コストで利用できるので、機械学習以外でも活用してほしい！

GPUを利用した経路探索

• 品質、処理速度を向上させるために力技を使った
• GPUが得意な計算
  • 要素数が多い
  • 処理の粒度が小さい
  • コアレスアクセスしやすい
• 条件分岐は避ける
• なるべく連続メモリにアクセス

経路探索処理の特徴

• 要素数が多い
• 処理の粒度は大きい
• ネットワークデータへランダムアクセス

  ＿人人人人人人人人人人人人人人人＿
  ＞　アンチパターンがてんこ盛り　＜
  ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

CPU vs GPU のお話

• 距離50kmの同一条件探索ではGPUが60倍速かった
• p3インスタンス voltaすごい
• 1000km以上の探索はp3にまかせる
• p2インスタンスでもCPU同等の速度が出せた（力技を使った成果）
• P2インスタンスで12GBのデバイスメモリ
  • まずp2で構築、テストをしたうえでp3に変えれば２−３倍の速度が期待できる

まとめ

• マネージドサービスを使うことで大事なことに集中できる
  • インフラエンジニア : アーキテクト
  • アプリケーションエンジニア : アプリケーション開発
  • などなど

感想

経路探索、ナビゲーションシステムを中心としたサービスを展開されている企業だけあって、筆者が普段扱わないGPUや経路探索処理のお話をテンポよく紹介いただけました。ナビゲーションアプリは旅のお供に重要な存在ですが、その裏にある経路探索の仕組みはなかなか意識したことがなく、このセッションを通じて興味が湧いてきました。