2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
Startup Architecture Of The Year 2019 #3-7 株式会社スタメン(全1記事)
提供:アマゾン ウェブ サービス ジャパン株式会社
リンクをコピー
記事をブックマーク
松谷勇史朗氏(以下、松谷):こんにちは。スタメンの松谷です。今日は「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つあります。
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点で、ビジネスへの貢献のポイントを終わらせていただきたいと思います。ありがとうございました。
司会者:松谷さん、ありがとうございました。
(会場拍手)
じゃあ松谷さんにご質問のあるCTOの方、もしいらっしゃればお願いしたいですが、いかがでしょうか。
名村卓氏(以下、名村):基本的には、Amazon AthenaとAmazon S3でパイプライン処理しているということですかね。
松谷:はい、そのとおりです。
名村:今後リアルタイムなデータを扱うとか、そんなときどうしようとかって、なにかあったりしますか?
松谷:今の設計ですと、アクセスログを準リアルタイムでAmazon Kinesis Firehoseへ送っているので、準リアルタイムなかたちでは今できるんですけれども、今の段階だとリアルタイム性のデータ分析は求められないので、日ごとの集計処理で間に合っています。
司会者:ありがとうございます。じゃあ、あと10秒ぐらいでなにかありますか?
名村:具体的には、どれぐらいの規模のデータを扱っているんですか?
松谷:Dailyですと数10ギガバイトのデータが流れていますので、だいたい月ごとに20パーセントの上昇で増えてきています。
名村:ありがとうございます。
司会者:それでは、松谷さん、以上となります。ありがとうございました。
(会場拍手)
アマゾン ウェブ サービス ジャパン株式会社
関連タグ:
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略