株式会社スタメン――松谷勇史朗氏
スタメンの提供する「TUNAG」は、会社でのコミュニケーションに特化した企業向けSNS。そのデータの処理基盤（ETL基盤）のアーキテクチャについて語った。
「TUNAG」で蓄積したコミュニケーションのデータには、会社と社員との距離感などが反映されている。「このデータを活用することで、エンゲージメントを定量的に分析できる」と松谷氏。そのため今回構築したETL基盤も、ビジネス上重要な鍵となっているという。
採用しているアーキテクチャは以下の通りだ。
まず、サーバから流れてくるアプリケーションログや、Amazon Auroraに保存されているマスターデータなどを含めたすべてのデータをAmazon S3に保存。そのデータをAWS Glueでクローリングし、AWS Glue Data Catalogを同期、クローラーの成功のイベントをフックして、Amazon CloudWatch Eventsで集計処理のワークフローを実行する。ここまでの処理は、イベントドリブンで進んでいる。
その後AWS LambdaからAmazon AthenaにCTAS（create table as）という処理を実行して、Amazon S3に再配置した集計データをエンドユーザーに使ってもらっているという。
過去の集計をやり直す場合には、SQSに集計ジョブをキューイング。それをAWS Lambdaが受け取り、日別に集計を並列処理する形だ。以前のETL基盤では8時間かかっていたこの処理だが、AWS Lambdaのオートスケールを利用することによって、20分にまで短縮できた。
このアーキテクチャの採用理由を、松谷氏は、以下のように語った。
- 「TUNAG」のサービスが順調に伸びデータが増えているので、集計処理のスケーラビリティを確保したい：AWS LambdaやAmazon S3のスケーラビリティの高さで実現
- 今後間違いなくデータを活用した事業をしていくので、拡張性を獲得したい：Amazon S3を置くことでほかのMLOps系サービスとの親和性アップ、機能拡張しやすい
- ELT基盤の構築経験がなかった：ベストプラクティスの詰まったマネージドサービスを使うことで、短期間で構築
Well-Architectedである理由としては、「コスト最適化」と「運用上の優秀性」の2点を挙げた松谷氏。コスト最適化については、「Amazon AthenaやAWS Glueなど、マネージドサービスの活用とサーバレスなアーキテクチャによって、運用上の人的コストがほぼかからない。またデータ量に応じた従量課金のおかげで、データ量が枯渇するのではと言った不安からも解放された」と話す。
また、運用上の優秀性については、「SAMでワークロード全体をコード化」しているという。これによってデプロイ自動化に組み込みやすくなる。またAWS Step Functionsを採用しており、どこで集計処理に失敗したのか一目瞭然。エラー処理やトライアル処理の設定が柔軟で、あらかじめ障害を見越した設計が可能。さらに、X-Rayでいつでも診断ができ、パフォーマンスの問題が可視化されるのもポイントだ。
最後に、アーキテクチャによるビジネスへの貢献を、以下のように話した。
「Amazon SQSによって並列処理することで、再集計の処理時間が大幅に短縮。これによって私たちのようなエンゲージメントが不確実な領域でも、トライ＆エラーで運用の効率が上がった。また、基盤系の経験の少ないエンジニアチームでも、マネージドサービスによって短期間で構築できた。さらに、今後のデータを活用した事業の可能性を広げることができた」
ストックマーク株式会社――谷本龍一氏
ストックマークは、AIベンチャーとしてテキスト解析、テキストマイニングをベースとしたクラウドソリューションを提供している。
これは、世の中にあふれる膨大なニュースを、AIを用いて企業・個人にパーソナライズし配信。企業の競合やマーケットの情報を分析することもでき、ビジネスの現場における情報収集や整理・分析を効率化、最適化するものだ。
アーキテクチャは以下の通り。
メディアサイトから、AWS LambdaとAmazon SQSでクローリングとニュース記事を分析、保存。そうして収集された記事に対して、AWS Batch上で管理されたCPUコンテナ（一部EC2上で管理されたGPUコンテナ）で機械学習を行い、記事のデータはAmazon Elasticsearch Serviceに、その他のデータはAmazon DynamoDBに保存される。
このデータに対して、オンラインアプリケーションでユーザーが興味のある業界や企業を検索した結果を、個人にパーソナライズしてレコメンデーションを返すといった仕組みになっている。
このアーキテクチャの採用理由を谷本氏は、まず「情報収集の網羅性を担保する」ためと話す。記事の収集・分析の仕組みは、AWS LambdaやAmazon SQSを用いていているので、スケーラブルな構成になっているうえ、今後も高速な追加開発ができる。
また、収集した膨大なデータを、使えるものとしてユーザーに提供するために、CPU／GPUコンテナを用いて、累計数千万におよぶ記事を独自のAIエンジンで分析。CPUコンテナでは要約の生成など、GPUコンテナでは類似事例・企業の抽出などを行っている。
さらに、オンラインアプリケーションの部分では、Amazon DynamoDBとAmazon Elasticsearch Serviceを併用することで、リアルタイムなレコメンデーションを可能にしている。
Well-Architectedである理由としては、まず「信頼性」を挙げた。ニュース記事のようなオープンデータの収集・分析は、「増え続けるデータとそれに伴って現れる特殊ケースとの格闘の連続」だと谷本氏は語る。メディアサイトからの情報収集の仕組みも、最初期は1台のEC2インスタンスだったものを、プロダクトの成長に合わせて段階的にマイクロサービス化することで対応してきた。
また、「パフォーマンス」の高さもWell-Architectedである理由の1つだ。AWS Elastic Beanstalk下のAmazon EC2と、Amazon Elasticsearch Serviceのインスタンスをそれぞれ最適化することで、数十万記事の分析結果を、1秒でユーザーに提供する高速なレコメンデーションを実現したという。
2017年4月にリリースしたこのサービスは、すでに1000社以上の企業で利用されている。広くビジネスへ貢献できているとして、谷本氏は発表を締めくくった。
株式会社スナックミー――三好隼人氏
お菓子のサブスクリプションサービスを提供するスナックミー。サブスクのKPIで大事なのは、「チャンレートを下げること」だとの三好氏は語る。データ分析の結果、「リクエストしてもらう」状況になると解約率が下がる（満足している）と分かった。リクエスト率を上げ、MAU（月間アクティブユーザー数）を向上させることが、同社のビジネス課題というわけだ。
そこで同社では、リクエストに基づいて届けるお菓子を決定し、ユーザーに届けるまでの仕組み、つまりアサインシステムの強化と効率化を目指したという。アーキテクチャは以下の通り。
AWS Step Functions上にAWS LambdaやAWS Batchのフローを載せている。三好氏は「ユーザーをクラスタリングさせたアサイン方法や、配送パターンの増加など、アサインパターンが複雑化している」ため、このAWS Step Functionsを採用したと話す。「昨年のre:InventでAWS Step FunctionsとAWS Batch、その他7つのマネージドサービスと連携可能になったと発表された。これによってAWS Step Functionsの利便性は上がった」と三好氏は話し、連携後のワークフローの例としてAWS Batchを用いた場合を挙げた。
これによって、Well Architectedを実現できている。三好氏は、ポイントとして以下の5つを挙げた。
- コストの最適化： AWS BatchとAWS Lambdaを実行時間によって使い分ける
- 運用上の優秀性：AWS Step Functionsにまとめることで一元管理
- セキュリティ：AWS Step Functions IAM / Amazon GuardDutyによる、AWSの他のサービスとリソースへのアクセスを制御 / 不正トラフィックのモニタリング
- 信頼性：job間を疎結合にすることで、障害を極小化
- パフォーマンスの効率：Amazon CloudWatchでワークフローのモニタリング
ビジネスの貢献としては、アサイン業務の手動時間を1週間あたり5時間削減、チャーンレート率は最大値から4％減、リクエスト率は昨年度から10％向上など、数字的にも効果が明らかになっている。また、「新しいアルゴリズムを容易に試すことができるので、さらなる解析も可能」と三好氏は今後にも期待する。今一度AWS Step Functionsの有用性を強調して、発表を終えた。
