@hiroeorz@github
Edited at

Serverless Days Tokyo 2019 トヨタ自動車・ダイキン工業 事例覚書

lambdaserverless

Serverless Days Tokyoに参加してきました。いずれも興味深い内容ばかりでしたが、ダイキン工業とトヨタのIoTシステムの中の話は、こういう機会でもなければ聞けない話でかなり貴重な話を聞けた感がありました。

その内容をメモったので残しておきます。

入り口の様子。

IMG_4993.JPG

会場の様子。休みの日の朝9時からというのに、ほぼ満席な感じでした。

IMG_4987.JPG


ダイキン工業：空調設備向けIoTシステムにおけるランニングコスト


  • ダイキン工業は、全世界の空調機（エアコン等）をインターネットに繋いで、販売、運用、保守、施工に対するサービスを提供する。

  • システム名は「Daikin Global Network（ダイキン・グローバルネットワーク）」

  • 想定接続台数は500万台。各空調機が1分ごとにデータをサーバーにあげる。

  • 想定ユーザー数は30万人。

  • 無限に発生するデータを格納できるストレージが必要。

  • 断固としてデータベースにRDBは使わず、全てNoSQLで扱う。

  • 初期投資を抑えるためにサーバーレスでスモールスタート。

  • サーバーレス開発はクラウドランニングコストとの戦い。

  • 一般にサーバーレスは低コストと言われるが、大規模なIoTシステムにおいては、サーバーレスアーキテクチャだとスケールしてコストがかさむ。

  • ユーザーが監視中は毎分データの取り出しを行う。

  • ユーザー監視中は建物内のデータを全て表示するので、複数機器のデータを一度に取り出す。

  • Lambdaの処理時間を抑えてコストを抑えるためには、DynamoDBのデータ構造が重要。

  • データ書き込み側は少しづつ書き込みたい、読み出し側は一度に読み込みたいという要求があった。

  • １機器中の１データにつきDynamoDBの１レコードとして保存すると、書き込みは速いが読み込み時に数千レコードを読み込むこともあり読み込みコストが高い。

  • 最終的にDynamoDBのパーティションキーに建物ID、ソートキーに機器IDを指定、データはJSONとして１レコードに格納することで書き込み、読み込みのコストを低減。

  • 失敗談として、ログレベルをDebugにしたままテストを実行して、CloudWatchLogに数百億のログを送信してしまい、アマゾンから数十万円を請求された。ログレベルには気をつけましょう。


トヨタ x サーバーレス

グローバル展開のコネクティッドカーを支える大規模サーバーレス事例


  • なぜトヨタがサーバーレスを選んだのか。


    • トヨタ車とドライバー、保険事業者、官公庁などをIoTで結ぶ。

    • セキュリティ会社とIoTでつないで盗難検知（遠隔からエンジン始動を禁止できる）



  • 圧倒的スピードでお客様へ価値を提供するには人的リソースが必要。でも人的リソースはトヨタといえども無限にあるわけではない。


    • 価値を生まない部分を徹底的に削減。



  • 車からのサーバーへのアクセスは日中は多く、夜は少ない。


    • サーバーレス化することで無駄をすべてマネージド化。




  • 法規上の問題で、コネクティッドカーのサーバーは各国ごとに作らなければならない。


    • 車の多い地域もあれば少ないあ地域もある。同じ規模のシステムを構築すると車の少ない地域ではコストが無駄になる。



  • トヨタのコネクティッドカーシステムは、地域ごとに分かれているシステムと、グローバルで共通のシステムとで連携する設計となっている。


  • 状態を特定のコンポーネントで集中管理し、プロセスをステートレスな設計にすることで、部分部分を再起動できる構成に。



  • アーキテクチャースタイル


    • アーキテクチャを決めるためのスタイル。




  • 設計の選択肢


    • Nティアー

    • ウェブキュー・ワーカー/イベントドリブン

    • マイクロサービス




  • 各コンポーネントの設計


    • リクエストの受信には２つの選択肢


      • Amazon API Gateway + Lambda

      • Application Loadbalancer + Fargate（スケールを柔軟にコントロールしやすい）



    • データの保存は全てDynamoDB（オンデマンドにすることでスケーリングを柔軟にコントロールできる）

    • インテグレーション


      • Amazon SQS（１つのメッセージに対して１つのパブリッシャー）

      • Amazon SNS

      • Amazon Kinesis Data Streams（キャパシティを拡張したり縮小したりできる）



    • ワーカープロセスは全てLambda




  • サーバーレスの課題


    • テストがしにくい


      • CI/CDパイプラインでテスト実行環境をつくる。


        • CodeCommit Codeepipeeline ...

        • LocalStackを利用してサービス単体でのテストをローカル/自動実行を可能にした





    • 各機能はシンプルになるが全体像が把握しにくい。


      • ロギング/分散トレーシング環境をしっかり作る。

      • ログはCloudWatch Logsに出すのが便利。

      • ログの出し過ぎは後から高コストに繋がる。

      • X-Rayを活用した分散トレーシング。



    • 自動スケールは便利だが、コントロールすべき項目が出てきた。




  • 自動スケールが逆に問題となるケース


    • 成功するまでリトライを行う必要のある仕様のLambdaがあった。

    • あっという間に数千処理が並行処理する状態になる。

    • Lambda同時実行数がアカウントの上限に達し、他のLambdaが起動できない状況に。



  • 運用コストの見積もりは50%ダウン。


  • 運用チームにかかっていたコストを開発チームに投与。開発サイクルを高速化。


  • １ヶ月あたり624回デプロイしている。


  • 今後は問題が生じた際の回復も自動化していきたい。


会場ではドーナツもいただきました。コーヒーもあって大変美味しかったです。

IMG_4992.JPG

Edit request
72