X-Tech JAWSで聞いたコネクテッドカーサービスのAWS活用術

「Cariot」のリアルタイム性を強化するKinesis、Lambda、DynamoDBの整え方

2020年05月12日 07時00分更新

文● 大谷イビサ　編集●ASCII

　第9回のX-Tech JAWSで3番目に登壇したのは登壇はフレクトの二人。MobiTechコネクテッドカーサービスである「Cariot」でのAWS基盤について、プロダクトマネージャーの篠原翔さん、製品開発部部長の遠藤匠さんが説明した。

フレクトプロダクトマネージャー篠原翔さん

「さして」「走って」「見る」コネクテッドカーサービス「Cariot」とは？

　2005年創業のフレクトは、セールスフォースやAWSのクラウドインテグレーションのほか、今回紹介するCariotを手がけている。移動体＋ITであるMobiTech分野は、MaaS（Mobility as a Service）やCASE（Connected、Autonomous、Shared、Electric）などのキーワードで言い表され、配車サービス、バイク・カー・パーキングなどのシェアリング、自動運転、物流の最適化、あおり運転の防止まで幅広い。

　Cariotは「さして」「走って」「見る」というコンセプトのコネクテッドカーサービスで、シガーソケットタイプやドライブレコーダータイプの対応デバイスやスマホアプリの「Cariot Mobile」を車に取り付けると、リアルタイムの運行状態や過去の運行履歴を把握できる。また、Drivecastという機能を使えば、車両の位置情報をアドレス（URL）として配信できるので、公共移動機関の位置情報を利用者に知らせることが可能だ。篠原さんはCariotを採用している兵庫県豊岡市の事例を元に、市営バスのリアルタイムな位置情報がなめらかに表示されている点をアピールした。

「さして」「走って」「見る」コネクテッドカーサービス「Cariot」

　Cariotの対象ユーザーはフィールドサービスやメンテナンス、建機・工事車両、工場や社内物流、営業車両、医薬品、産業廃棄物回収、リサイクル物流など幅広い。「医薬品の物流では製造してからお客様に届くまでの時間が短いので、こうしたリアルタイム物流のサービスが求められています」（篠原さん）。

　前述したとおり、Cariotの特徴は3秒に1回に位置情報を送信していくことから実現されるなめらかで、高いリアルタイム性。開発の経緯がシャトルバスの運行状況の可視化という案件だったこともあり、一定時間内に処理を完了するために、データの詰まりがないこと、つねに流入量をさばける処理能力を目指している。「サービスのしきい値として遅延が30秒を超えた場合は要注意インシデントとみなしており、10分を超えたらお客様に報告するような重要なインシデントになってしまう」と遠藤さんは語る。

サービスの成長とともにAWSでのデータハンドリングをどのように変えたのか？

　こうしたリアルタイム性を満たすため、Cariotはデータの収集、処理・分析、保存、活用を行なうIoTプラットフォームをAWSでバックエンドを構築している。なお、ユーザーが利用するアプリケーションはSalesforceを採用している。

　2015年のサービス開始当初はKinesis、Lambda、DynamoDBという構成でうまくいっていたが、サービスの成長とともに、リアルタイム性を補う必要が出てきた。たとえば、急ブレーキ、方向判定、到着・出発・通過などのいわゆるジオフェンス、到着時間の経過予測など、モビリティサービスにはやはりリアルタイム性を実現しようと思うと、Kinesis、Lambda、DynamoDBの使い方を工夫しなければならなくなったという。

フレクト製品開発部部長遠藤匠さん

　まずはKinesisだが、3秒に1回のデータを数多くのデバイスから受けることを考えると、1シャードあたりの1000レコード／秒という上限はかなり厳しい。そのため、シャード数を増やすのが基本だが、当然コストにも跳ね返るし、シャード単位の順番を保証する必要がある。そのため、Kinesisのライブラリを用いて、1レコードに数多くのデータを詰め込むようにした。これによりコスト面でのメリットのほか、TCPのオーバーヘッドも減るという。

KinesisとLambda

　Lambdaに関しては、1回の呼び出しで渡されるレコードの最大値をバッチサイズに設定した。「サポートの人にも聞いたのですが、タイムアウトしないで処理可能であれば、バッチサイズを大きくとってもかまわない」（遠藤さん）とのこと。同時実行数もシャードごとにつねに1つにし、1秒に1回ずつのポーリングを行なっている。

　また、Lambdaはメモリサイズに比例してCPUパワーが決まるという特性があり、Cariotではコストと処理性能のバランスをとって512MBを選択している。Lambdaの処理が正常終了しない限り、リトライが繰り返されるので、無駄なデータが入らないようにケアする必要がある。また、課金対象の実行時間は100ミリ秒単位で切り上げられるが、実際の呼び出しはそれより短い頻度で行なわれている点にも注意すべきだという。LambdaがRDSの相性があまりよくないこともあり、Lambdaは基本データを流すことに専念させ、リアルタイムなデータ処理はバックエンドのEC2にオフロードする構成をとっている。

リアルタイムなデータ処理はEC2にオフロード

　DynamoDBに関しては、あとからできること、あとからできないこと、できるけど大変なことをきちんと認識した上で、最初にしっかりテーブル設計しておくことが重要だという。DynamoDBの場合、容量は無制限だが、ストレージ単価がS3の標準ストレージの10倍以上するため、データのメンテナンスが重要になる。しかし、テーブル内の既存レコード全体をあとから更新・削除するのは大変なので、古いデータをパージする前提でテーブル設計をしておくべきだという。特にCariotのようなリアルタイム性重視のシステムの場合、キャパシティをオンデマンドに強化するのは難しいという。

　最後、遠藤さんは個人的な教訓として「トラブルが発生したときに、札束で原状回復できるなら、それは強いアーキテクチャ」「処理するデータの数が一桁変わったら、アーキテクチャの再検討時期」の2つを披露した。とはいえ、4年間の運用を通して、制限や性能がAWSのアップデートで解消されたことも多かったとのこと。遠藤さんは「神様、クラウドをありがとう！」と語って、発表を締めた。

■関連サイト