社内のコミュニケーションデータから、信頼関係を定量化　企業向けSNS「TUNAG」のシステムアーキテクチャ

社員同士のエンゲージメントを向上させるコミュニケーションデータ

松谷勇史朗氏（以下、松谷）：こんにちは。スタメンの松谷です。今日は「TUNAG」のETL基盤、データの処理基板の話をしていきます。

まずサービスについてです。

僕らが運営している「TUNAG」というサービスは、会社と社員の間だったり、社員同士のエンゲージメントの向上、つまり、信頼関係の構築を目的とした企業向けのSNSです。

そこのTUNAGの中で蓄積したコミュニケーションなどのデータには、社員と会社との距離感が反映されています。そのデータを分析することで、エンゲージメントを定量的に分析することができます。今回構築したこのETL基盤も、データを扱う上ですごく重要な、ビジネス上で重要な鍵となっていました。

それではシステムアーキテクチャの説明に入っていきます。

全体像はこんな感じです。データの流れの順に説明していきます。

まず、Amazon S3にすべてのデータを集めるところから始めました。Webのサーバから流れてくるアプリケーションログだったり、Amazon Auroraに保存されているマスターデータを日ごとに抽出して、それをすべてまずAmazon S3に保存しています。

そうして、そのAmazon S3に対してAWS Glueというサービスでクローリングしてあげて、データのカタログを同期してあげます。

そして、そのクローラーの成功のイベントをフックして、Cloud Eventで次のStep Functionsでの集計処理のワークフローを実行しています。ここまですべてイベントドリブンです。

その集計の処理の中身では、AWS LambdaがAmazon Athenaに対して「CREATE TABLE AS」というクエリを実行して、Amazon S3に集計データを再配置しています。

そして、最後の集計データをエンドユーザーの方に使っていただくかたちをとっています。

また別に、集計のケースとしては、新しくKPIの指標を追加したくなったときや、過去分のすべての集計をやり直す必要があります。

そういったときにはAmazon SQSに日ごとのジョブをキューイングしてあげて、それをAWS Lambdaが受け取り、日別に集計を並列処理すればいいということになっています。

以前のETL基盤では、もちろんベストな設計ではなかったのですが、8時間ほど集計に時間がかかっていたのが、LambdaのAuto Scaleを利用することで、なんと20分に縮めることができました。

このアーキテクチャを採用した3つの理由

松谷：続いて、このアーキテクチャを採用している理由です。3つあります。

1つ目、先ほども言ったように、AWS Lambdaのようなスケールアウトだったり、Amazon S3のストレージのスケーラビリティを確保したいところがありました。これはTUNAGが順調に伸びていて、データがどんどん増えてきたからという理由です。

2点目です。今後TUNAGはデータを活用した事業の展開をしていきたいと思っています。なので、まずAmazon S3に置くことで、ほかのAWSのMLOps系のサービスとの親和性も高くなり、事業の拡張がしやすくなると考えました。

そして3つ目。僕はETL基盤のある程度の規模の構築をしたことがなかったのですが、今回、基盤のベストプラクティスを詰め込んだようなマネージドサービスを使うことで、短期間で構築できるのではないかということで進めていきました。

Well Architectedな2つのポイントです。

1つ目は「コストの最適化」というところと、2つ目は「運用上の優秀性」、それぞれ説明していきます。

まず、このシステムは、AWS GlueやAmazon Athena、AWS Lambdaなどの、マネージドサービスとサーバレスで組み立てて作っています。なので、運用上の人的コストはほぼ限りなくなくなりました。

続いて、特徴として、データ量に応じて従量課金なので、事前に予算をかけすぎたり、リソースが枯渇するみたいな心配から解放されました。

ビジネスへの貢献ポイント

松谷：続いて、運用上の優秀性です。

僕らはこのシステムを作りっぱなしにはしていなくて、AWS SAMを使ってまずこのワークロード全体をコード化しています。そうすることで、デプロイの自動化に組み込みやすくなったり、プロダクションにデプロイする際に他のメンバーにレビューをしてもらえるなど、人的なリソースが確保できます。

そして次に、AWS Step Functionsを使っているので、どこでいったい集計の処理に失敗したかみたいなところも、一目瞭然でわかります。あとはStep Functionのエラー処理やTryの処理がすごい柔軟に設定できるので、あらかじめシステムの障害を見越した上での設計ができています。

最後、AWS X-Rayでパフォーマンスの問題を可視化できるので、いつでも診断ができて、どのクエリが遅いみたいなことが、今後データが増えたとしてもできるようになっています。

それではまとめます。ビジネスへの貢献についてです。

並列処理によって時間が短縮しました。これによって、何を意味するかというと、僕らみたいなエンゲージメントという不確実な領域の中で、トライ＆エラーの数を増やすことができたんですね。そうすることで、運用上の効率がすごく上がりました。

2つ目。僕を含めて、そんなまだ経験がなかなかない、基盤系の経験がないエンジニアの中でも、マネージドを組み合わせて短期間で構築できました。

3点目。今後の機械学習など、TUNAGの未来へ向けた事業の展開を、データを活用した事業の展開の可能性を広げることができました。

以上の3点で、ビジネスへの貢献のポイントを終わらせていただきたいと思います。ありがとうございました。

月に20パーセントの上昇を見込むデータの規模

司会者：松谷さん、ありがとうございました。

（会場拍手）

じゃあ松谷さんにご質問のあるCTOの方、もしいらっしゃればお願いしたいですが、いかがでしょうか。

名村卓氏（以下、名村）：基本的には、Amazon AthenaとAmazon S3でパイプライン処理しているということですかね。

松谷：はい、そのとおりです。

名村：今後リアルタイムなデータを扱うとか、そんなときどうしようとかって、なにかあったりしますか？

松谷：今の設計ですと、アクセスログを準リアルタイムでAmazon Kinesis Firehoseへ送っているので、準リアルタイムなかたちでは今できるんですけれども、今の段階だとリアルタイム性のデータ分析は求められないので、日ごとの集計処理で間に合っています。

司会者：ありがとうございます。じゃあ、あと10秒ぐらいでなにかありますか？

名村：具体的には、どれぐらいの規模のデータを扱っているんですか？

松谷：Dailyですと数10ギガバイトのデータが流れていますので、だいたい月ごとに20パーセントの上昇で増えてきています。

名村：ありがとうございます。

司会者：それでは、松谷さん、以上となります。ありがとうございました。

（会場拍手）