[レポート] IOT204-S – 路上のゴム以上の存在へ: IoTの世界とタイヤ #reinvent

[レポート] IOT204-S – 路上のゴム以上の存在へ: IoTの世界とタイヤ #reinvent

Clock Icon2019.12.12

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

はじめに

あのピレリの話です!その昔の中嶋悟の時代から現在も、F1マシンの足元にピレリ、またRX-7∞の標準タイヤになってたピレリP-ZERO、スポーツカーのタイヤ中でも低扁平率で高性能なタイヤを出してる憧れのメーカーといえばピレリでした。 本記事はre:Invent 2019のセッション「IOT204-S - More than rubber on the road: Tires in an IoT world」のレポートです。

概要

ピレリは、ハイエンドの一般ドライバーとプロのドライバーの両方のパフォーマンスのニーズに焦点を当てた最先端の高品質タイヤを提供することで知られています。しかし、今日、ピレリタイヤは、道路上のゴム以上のものです。このテレメトリデータから、ドライバーが安全性とパフォーマンスの目標を達成できるようにします。このテレメトリ機能とピレリの他のアプリケーションの間では、大量のデータがシステムに流れ込みます。これらのシステムがAWSを使用してどのように構築され、最新の可観測性ツールによって可能になるかを共有します。このプレゼンテーションは、APNパートナーであるDatadogによって提供されます。

登壇者

登壇者はPirelliとパートナーであるDatadogの方のお二人で行われました。

AWS re:Invent 2019: More than rubber on the road: Tires in an IoT world (IOT204-S) - YouTube

セッション内容

  • ピレリは146年の歴史がある企業
  • タイヤメーカーとして知られている
  • ゴムとゴム製品の発明、特許、テクノロジーを持ってる
  • ゴムの歴史は産業から自動化へ、自動車から製品へ、1800年代からの続く技術革新の歴史でもある

  • 現代のテクノロジーはと言えばコンピュータ
  • 2013年に作られた言葉「すべての企業はTech企業である」と言われた
  • ピレリは自動運転とコネクテッドビークルに取り組んでる
  • Datadogは監視と分析のプラットフォーム、最近はログやセキュリティ製品も
  • ピレリとDatadogは過去数年で良い関係を築いてきた

  • ピレリは車、バイク、F1、自転車のタイヤを供給している

  • それだけではなくデジタル広告、カレンダー、高級なデザインされた製品、文化的・社会的コミットメントなど様々な活動にも関わっている

  • 特別なブランドのスーパースポーツ向けに最高品質のタイヤを作ることに責任を持っていた

  • AWSが登場する以前の他の企業と同様に、データセンターを持っていて自社運用していて、インフラの大部分はそこで動いていたが、クラウドの採用には積極的だった
  • 140年以上の歴史を持つ古いゴムの会社から新しいTechな会社になるには課題があった

  • 全てのシステムをクラウド移行するのが正しい選択かを理解するため、リソース全てを評価することを考えた

  • ソフトウェアだけではなく、製造工程やビジネスユニットにも影響するなど、歴史が長く規模が大きい会社にとっては乗り越える事が沢山ある
  • また、歴史的に一部の国ではB2Bの仕事が依然として多いが、今はコンシューマ向けの製品やサービスが多くなっているため、顧客のことをもっと知る必要がある

  • 過去に導入したものも、ニーズを満たすためにその時代に最適なものを選択している
  • 進化する事に誇りをもっているため、新しいトレンドを理解して、新しいビジネスを採用しづつける責任がある
  • 企業秘密を保護し、セキュリティの基準と要件を確実に遵守することは、非常に重要
  • そのため、タイヤのレシピのような機密情報やHRなどの重要なものは、現時点ではオンプレミスで管理するのが最適と判断した、しかし、将来的にはそれもクラウドに移行する

  • クラウドに移行するということはIoTなど新しいタイプの沢山のイノベーションの機会を得るということ
  • クラウドはリソースを割り当てるのに1週間待つ必要はなく、本当に重要なことに集中できる

  • B2Cとクラウドアーキテクチャ両方の分野の関係者でチームを編成した
  • このチームは”デジタルイノベーションと進化するクラウド”と呼ばれ、現実世界のシナリオを元に、新しいソリューションとサービスを探求し、新しいテクノロジーをテストして、新しい製品をより良くする方法を助けることを使命としている
  • これは非常に重要で、現代のスタートアップと違って、大きくて動きの遅い組織にいる場合、かなり冒険的な響きのする名前で推し進めるなら、受け入れられる
  • 現実世界のデータ、問題と製品チームは一緒に働く必要がある。イノベーションチームが密室で働いていても時間の無駄になる

  • 第1フェーズ
  • 最初のアプローチは近代的かつ保守的なリフト&シフトだった
  • EC2に配置できるかオンプレミスにDB配置する必要があるのか、全てのシステムを評価した。そして、ふさわしいものはクラウドに移行した。その過程でシステムの深い理解が得られ、クラウドの力を味わった
  • 重要なのは一晩でオンプレミスからサーバーレスに移行する必要は無いということ
  • 全てのプロダクトが独自のライフサイクルや構造があるため、個別に評価する必要がある
  • オブザーバビリティ(可観測性)が不足していた

  • オブザーバビリティはメトリクス、ログ、トレースの3本柱
  • しかし、複雑さを増してる現在ではそれだけでは足りない
  • イベント処理/モバイル/IoT などUXに関する判断も必要
  • CPU使用率のようなものだけではなく、ビジネスを理解するための仕組みも必要

  • Datadogとオブザーバビリティの話
  • タイヤがどの車に最適なのかが分かるWebサービスがある、これは顧客との主要な接点になってる
  • しかし、サービスを使い始めた50%の顧客が最後まで行かずに離脱していたのが分かった
  • 1週間掛けて調査したが、何も悪いところは見つからなかった、それは分析プロバイダが欠陥のあるデータを提供してたのが原因だった

  • 今はDatadogを利用して、協力なオブザーバビリティを持ち、原因の特定から解決まで、1日でできるようになった
  • 複雑なシステムをデバッグするのは難しい、信頼できるパートナーを持つのも同様
  • DatadogとAWSとのパートナーシップによって、クラウドを活用する中で、私達が学習プロセスにいる事に気づいた
  • AWSはサービスの管理と金銭的コストの最適化を支援している
  • Datadogは顧客にどう使われてるかの認識と理解を与えてくれる

  • 第2フェーズ
  • より早く、安全にマーケットに投入することが目標
  • 早く動く時は小さな変更をデプロイする、するとシステム全体が誤った動作をする可能性が低くなる

  • 第1フェーズではコンテナもサーバーレスもなかったが、第2フェーズではコンテナが機能するところを見つけた
  • システムのデータを分離するところからはじめ、自由に使えるようになったデータを利用し、素早くアプリを構築することができた
  • Dockerはラピッドプロトタイピングには最適だが、私達の会社では本番に行く前に、信頼できることを保証する必要があった
  • 信頼できるソースからベースとなるDockerイメージを取得し、JDKは公式のもの、Node.jsはライブラリを利用した
  • 最初は独自のDockerレジストリを立ち上げたが、後にAWSのECRに移行した

  • Lambda は Super cool!
  • しかし、システムのアーキテクチャ設計は全然違う
  • 最小のリソース、コード、タスクを設計する
  • モノリシックなアプリはLambdaに適用できない
  • 最初に少々の失敗するのは大丈夫、例えばコールドスタートの問題があったが、Lambda warmerでパフォーマンスを向上させた
  • Lambdaの適切な実装例としては、Webサービスで複雑なクエリからデータをユーザーに返すAPIがある
  • APIはサーバーレスを始めるのに良いところ、最小の手間で移行できる可能性がある

  • 世界はもっとデジタル機器を求めてる
  • タイヤを中心にしたIoTの事例がある

  • Track Adrenaline: your personal driving assistantはタイヤに取り付けられたセンサーとコントロールユニットからなるアプリ
  • サーキットでレースするのにクールな機能がある
  • タイヤの空気圧や温度を測定して最高のパフォーマンスを出すことができる

  • Dockerコンテナ、Lambda、SES、SNS、ECR、Aurora、API Gateway.. などのサービス、そして一部はコンテナを利用したマイクロサービスになっていて、スタック全体に自動的にデプロイされる
  • このような疎結合で復元力があり、安定してスケーラブルなアーキテクチャのパターンは全ての開発チームの標準になりつつある
  • センサーは工場でペアリングされる
  • Track Adrenaline はセンサーとコントロールユニットとモバイルアプリから構成される
  • コントロールユニットはEdison / Linux、Intelのプロセッサ、Wi-Fi Bluetooth、GPSモジュール、SSD、RAMからなる
  • コントロールユニットはWi-Fiでモバイルアプリと通信し、センサーをセットアップして、レース時にセンサーからブロドキャストされたデータをデコードしてアプリに送信して、リアルタイムにタイヤの情報を返してドライバーにレースに役立つヒントを与える
  • 昔はF1の領域の話だったが、今はコンシューマレベルに展開されてる
  • Need for Speedのようなレースゲームのようにゴーストとプレイするとこもできる
  • AWSにマイクロサービスで構成されたバックエンドシステムは、セッション情報やレースのヒントを計算するためのアルゴリズムをもってる
  • モバイルアプリはiOS/Androidのネイティブアプリ、Bluetoothでセンサーと通信し、Wi-Fiでコントロールユニットと通信し、セッションなどの情報をAPI通信してる、ポータルも同様

  • Cyber Fleet はトラックやバスの空気圧と温度を管理できる
  • 異常をドライバー通知したり、燃費を改善することで、ビジネス効率を高める
  • 先ほどのシステムとテクノロジーは似ているが、目的は異なる、これは重要な学び

  • Track AdrenalineにあってCyber Fleetに無いのはコントロールユニット
  • センサー自体は似ているが、目的が違うのでセンサーとアプリは直接通信する
  • Enterprise Kubernetes Management | Rancherは使いやすいUIを持つコンテナ管理ツール、近日Kubernetesに移行する予定
  • このアーキテクチャは最終的なものではなく、常に改善し続けている
  • 重要なことは、アーキテクチャ設計に関して独断的ではないこと
  • ある専門家だけで完璧なアーキテクチャを設計すると、触れられなくなってしまう罠がある、そうなると革新できなくなる

  • 例えば、 安全なソースからDockerイメージを生成し、デプロイメントパイプラインを使い、静的解析を行うように、ガードレールは減速させるためのものではなく、早く安全に行うためのもの
  • Wordドキュメントだけではなく、エンジニアリング的なソリューションによって行われる

  • 来年取り組むのはセキュリティとコストの最適化
  • AWSと連携して、ベストプラクティスに従い、現在は単一のAWSアカウントだが、少なくとも20アカウント以上を管理することで、将来に備える
  • また、人為的なミスを減らすことを目的としてセキュリティコンプライアンスに準拠した構築の自動化に取り組む
  • リソースへはロールベースのアクセスとし、パスワードがどこにも保存されないようにする

感想

昔から低い扁平率とハイグリップな高性能のタイヤを作れるピレリは、当時から世界最高峰のテクノロジー企業だったはずです。そんな彼らも他の企業と同じように現代のテクノロジーに合わせて変革していく必要がありました。
Datadogというパートナーと共に、しっかり既存の現場の状況やシステムを見て一体となって、地に足のついた変革を少しずつ進めているのが印象的でした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.