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

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

2018年06月01日にAWS Summit TOKYOで行われた『【ナビタイムジャパン様ご登壇事例】ナビタイムが導く AWS 活用への最適経路』に関するレポートです #AWSSummit
Clock Icon2018.06.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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

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

-- AWS Summit Tokyo 2018(2018年5月30日~6月1日)|AWS

セッション概要

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

スピーカー: 田中 一樹 株式会社ナビタイムジャパン インフラエンジニア クラウド担当
吉濱 誠 株式会社ナビタイムジャパン 開発部 シニアエンジニア

概要: ナビタイムで利用している AWS サービスの活用事例についてお話します。前半は目的地までドア to ドアでナビゲーションをする「トータルナビ」のバックエンドで動く Amazon ECS、ログ分析基盤として利用している Amazon Athena などの本サービスで利用している AWS サービス全体的な活用事例について。また後半では、並列処理とは相性が悪いと言われている経路探索処理の GPU インスタンス活用事例をご紹介します。

セッションレポート

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

はじめに

田中さんより

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

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

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

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に変えれば2−3倍の速度が期待できる

まとめ

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

感想

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

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.