HAROiDプラットフォームのリアルタイムログサービス

はじめに

はじめまして。
サーバサイドエンジニアの稲垣と申します。好きなエディタはVimです。
業務ではプラットフォームの開発/運用などを担当しております。

今回は私が主に開発を担当しているリアルタイムログサービスについてお話をさせて頂きます。

HAROiDではHAROiD Realtime Analytics(以下、HRA)と呼ばれるサービスを提供しています。
これは、HAROiDプラットフォームを利用して作られた企画の参加者情報を、リアルタイムに集計・可視化するサービスです。
視聴者数推移のような使い方から、利用者の傾向や分布を見ることも可能なものとなっています。
サービスの性質上、じっくり分析するということよりも、状況がひと目でわかるようなビュー構成を意識して作っています。

ビュー ※数値などについてはイメージです


システム構成

HRAのシステム構成においては以下のようなことが重要な課題となっていました。

  • 高負荷時でもリアルタイム性を損なわない(遅延は限りなく少なく)
  • 正確にログを取り込む
  • システムのダウンタイムが発生しにくい

このような課題を解決するために、AWSのフルマネージドサービスを多く使った構成となっています。

システム構成

処理の大枠は以下のシステムで構成されています

  • AWS Kinesis
  • AWS Lambda
  • AWS S3
  • Elasticsearch
  • Kibana

各アプリケーションサーバから送信されたログは、まずKinesisストリームが受け取ります。KinesisストリームをLambdaがポーリングしており、ログの検出をトリガーにLambda関数が実行されます。
Lambda関数では受け取ったログを分析に必要な形にフォーマットし、Elasticsearchに保存します。
このElasticsearchに保存されたデータをKibanaがビジュアライズします。
バックアップ用にログをS3にも保存しますが、S3への保存はリアルタイム性を確保するには時間がかかりすぎるため、別のKinesisとLambda関数が非同期に処理するようにしています。

Kinesisは事前にアクセス数が想定できればスケールすることが容易ですし、Lambdaはそのときの流量に応じてオートスケールされるため、先述の課題を解決しながらも運用負荷を大幅に下げることができる優れたサービスです。
特にLambdaに関してはコストにおけるインパクトも大きく非常に重宝しています。

このシステム構成で、これまでの実績値として10000レコード/秒程度を問題なく処理することができています。

おわりに

今回はHAROiDのリアルタイムログサービスであるHRAのシステムの概要について簡単に紹介させていただきましたm(_ _)m
次回以降ではこのシステムを構成している個別のサービスについて、さらに掘り下げてお話できればと思っています!

今後共よろしくお願いいたします。