SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2022 レポート(AD)

膨大なログをサービス改善につなげるには? タクシーアプリ「GO」を支えるElasticsearchとBigQuery【デブサミ2022】

【17-E-5】24時間走り続けるタクシー車載器の安定稼働を目指したログ基盤の開発

  • X ポスト
  • このエントリーをはてなブックマークに追加

株式会社Mobility Technologies IoT統括部 IoT開発部 部長
株式会社Mobility Technologies IoT統括部 IoT開発部 部長 松島由紘氏

ElasticsearchとBigQueryで実現する膨大なログの解析とその活用

 「ログを分析することで改善につなげる」というと簡単そうに聞こえるが、ログの分析や管理はそう簡単ではない。なにせ量が多い。最近ではログデータは1日あたり数億ものレコード、数百GBものサイズに膨れ上がっている。必要な情報を適切に抽出し、またインサイトをもたらすように可視化していかなくてはならない。

 ログの集積と分析に使うツールはMoTのなかで試行錯誤を続けてきたものの、現時点では短期データはElasticsearch、長期データはGCPのBigQueryに落ち着いている。

 Elasticsearchは分散型でRESTfulな全文検索エンジン。MoTが採用した理由は、NoSQLなのでそのままデータを放り込めて、検索が簡単であるからだ。単語から全文検索も可能で、SQL的なもので詳細な条件指定も可能だ。加えてElasticsearchとセットで使えるデータ可視化ツールKibanaの存在も大きい。Kibanaのダッシュボードからは簡単にデータの集計や可視化ができて、ログの有効活用につながっている。

 BigQueryはSQLが使えるDBMSでデータウェアハウスとしてよく使われている。もともとMoTのデータ分析基盤として使われていたため、それに相乗りするような形で使っている。分析の専門チームが長期間のデータを集計している。

ログ分析基盤の構成
ログ分析基盤の構成

 ログ分析基盤はマルチクラウドで構成されている。基本的にはAWSで、BigQueryはGCPを使う。車載器からのログデータはALB(Application Load Balancer)を通じて、EKS(Amazon Elastic Kubernetes Service)のアプリケーションサーバーで処理され、Elasticsearchで分析し、Kibanaのダッシュボードで可視化される。

 データを活用するユーザーが直接目にしているのはKibanaとなる。主に開発エンジニアと顧客からの問い合わせ対応を行うヘルプデスクがKibanaを参照している。BigQueryは分析エンジニアがデータの抽出や集計を行い、日々の利用実績などKPIを出している。

 Kibanaは難しい構文を使わなくても検索しやすいのが特徴だ。下図はBluetoothで接続された機器の稼働状況。棒グラフの水色が正常で、赤が失敗を表す。ほとんど正常ではあるものの「100%を実現するために、まだやらなくてはならないことがあるのが現状です」と話す。画面下半分には失敗部分のエラーログが表示されていて、どのような状況で失敗したのかを把握できるようになっている。

Bluetooth機器の稼働や接続状況を可視化
Bluetooth機器の稼働や接続状況を可視化

 ヘルプデスクもKibanaを参照することで、問い合わせに対応している。その90%はヘルプデスクで解決され、残り10%が開発への調査依頼となる。

 先に少し触れた、独特な操作や運用についてもログから実態を把握することができる。標準的なタクシーのステータスでは、誰も賃走していない時は「空車」、アプリから注文を受け付けると「迎車」、顧客を乗せると「賃走」、夜間なら「割増」、目的地に到着すると「支払」となる。しかしまれに「迎車」にする操作をせず「空車」のステータスのまま顧客のところに向かうために、二重に注文を受けてしまう場合がある。こうした不具合はログから確認できるので、ここから多様な運用や操作に対応できるようにUI改善を進めることができる。

 ログ解析について佐々木氏は「まだ課題はあります。何か起きた後の詳細調査はできるのですが、検知のアラートが課題となっています。サーバー監視だと、しきい値でアラートを設定することができるのですが、車載器の不具合はログに出ないものが多く、検知しにくいのです」と説明する。

ログ解析は「移動の未来」に何をもたらしたのか

 MoTがログ解析の基盤を構築し、改善を繰り返しつつ運用を続けて4年になる。会社が統合したのが2年前なので、ログ解析開始前を知る社員は意外と少ない。松島氏は2016年に当時のJapanTaxiに入社したため、ログ解析がなかった時代を知っている貴重な一人だ。

 松島氏によると、車載器の不具合は高温や通信状態が悪いなど特定の条件下でのみ発生するものが多いという。電話などのやりとりでどうしても解決できないと、現地に赴いて解析することもあった。

 例えば「ちゃんと動かない」と苦情が来て、松島氏がオフィスで検証しても不具合が再現できなかった。結局現地に赴いて確認すると、ケーブルは挿さっていたものの運転の振動でケーブルが劣化し、断線と再接続が繰り返されていたことが原因と判明した。このインシデントは後にハードウェアの接続部分を強化するという改善につなかったものの、不具合が起きた場所が遠方だと移動だけでも大変だった。

 こういうことは振動や過酷な気温などがないオフィスではなかなか気づけない。長時間ログを取れるようになり、素早く気づくことができた。遠方で起きた問題でも素早く対応することが可能になった意義は大きい。

 松島氏は次のようなメッセージでセッションを締めくくった。「今日はログ収集の重要性とログ基盤を中心に紹介させていただきました。参考になれば幸いです。これをきっかけに『移動の未来を一緒に作って行きたい』、『その課題を一緒に解決したい』と思っていただけたら、ぜひお声かけください。興味があれば、いつでも遊びに来てください。雑談でも大歓迎です」

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Developers Summit 2022 レポート連載記事一覧

もっと読む

この記事の著者

加山 恵美(カヤマ エミ)

フリーランスライター。茨城大学理学部卒。金融機関のシステム子会社でシステムエンジニアを経験した後にIT系のライターとして独立。エンジニア視点で記事を提供していきたい。EnterpriseZine/DB Onlineの取材・記事や、EnterpriseZine/Security Onlineキュレーターも担当しています。Webサイト:http://emiekayama.net

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/15712 2022/04/27 17:20

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング