AWS Startup ブログ
「あらゆるテックスタートアップはこのコンテストを目指すべき！」スタメン松谷氏が振り返るグランプリまでの道のり 【Startup Architecture Of The Year 2019 ファイナリストによる寄稿シリーズ】
皆さんこんにちは、スタートアップマーケティングの石渡です。
先日開催した Startup Architecture Of The Year 2019 では、7社のファイナリストによる熱いピッチコンテストが繰り広げられました。
このイベントは時間の関係もあり、各社5分という限られた時間でのピッチをお願いしました。当日は私も舞台袖から皆さんのピッチを聞いていましたが、ご登壇頂いた皆様の内容は、知恵と経験の詰まったもので、当日イベントに参加されなかった方にも是非お伝えしたいと思いました。そこで、ファイナリストの皆様に寄稿をお願いして、ここ AWS Startup Blog で、各社のアーキテクチャを熱く語って頂くことにいたしました。
今回は、グランプリである Startup Architecture Of The Year 2019 に輝いた、株式会社スタメンのテックリード、松谷さんにご登場頂きます。この賞は、日本におけるテックスタートアップをリードする著名 CTO 6名の投票により決定したものです。
先日、受賞のトロフィーをお渡しするために、スタメン様のオフィスにお邪魔してきました。寄稿の前に、写真とショートインタビューをご覧下さい。インタビューには、松谷さんとともに、取締役 CTO の小林さんにも同席頂きました。
株式会社スタメン テックリード 松谷 勇史朗 氏
あらためてグランプリである「Startup Architecture Of The Year」の受賞、おめでとうございます。まずは今回の応募のきっかけなどを教えてください。
有り難うございます。
このコンテストの存在を知ったのは、応募〆切の3日前でした。ちょうど今回エントリーした、TUNAG上に蓄積した各種データを分析・活用するためのETL基盤のカットオーバーが終わった直後でした。3日前ということもあり、もう誰にも相談することなく、一人で急遽エントリーすることに決めて申し込みました（笑）。
グランプリということで反響や効果などはありましたか？
ビジネス的なところですと、大手の新聞などにも取り上げられましたし、弊社の営業がお客様先に伺った際に、「あのグランプリの会社ですね！」と言ってくださるお客様もいました。企業の認知度や弊社の技術的な信頼感の向上という点でも大いに役立ちました。あとは、プライベートでは、祖母が喜んでくれました！（笑）。エンジニアリングという仕事を理解して貰うのは大変でしたが、グランプリということで、「大したことをやったね！」と喜んでくれました。
(小林氏) 我々は技術の観点でビジネスに貢献していきたいという思いを強く持っていましたので、今回の受賞を契機にした一連の効果というのは大きかったなと思っています。また、今回の経験を通じて、松谷さんの視座が高まり、より大きなところを目指してくれそうだという点も効果として大きかったなと思いました。
株式会社スタメン 取締役 CTO 小林 一樹 氏
今回のETL基盤のシステムの変遷を教えてください。
スタメンの創業後1年くらいのタイミングで、第一世代の ETL 基盤を構築しました。その当時は、メインのプロダクトの開発と強化が優先課題でしたので、ETL の基盤としては、まずは動けば良いという程度の割り切りの元で開発されたものです。よって、EC2 と RDS などの基本的なプロダクトに、外部の BI ツールを組み合わせたというような、ミニマムな構成でした。当初はそれで良かったのですが、TUNAG がビジネスとしてスケールしていく過程で、スケーラビリティや信頼性、さらには耐障害性の観点での課題が顕在化してきたのです。こうした背景が、今回エントリーした、第2世代のETL基盤に向けての背景にあります。今回のリプレースに当たっては、AWS のマネージドサービスをうまく活用して、AWS に任せられるところはどんどん外に出してしまおうという発想でデザインを進めました。
このプロジェクトの苦労話などを教えてください。
大変すぎてどこから喋ればいいかな（苦笑）
私は基盤チームのテックリードということで、データ分析系のソリューションの経験は今回が初めてでした。そのため、AWS Glue, Amazon Kinesis Data Firehose などのデータ分析系の AWS サービスを知るところから始め、具体的な比較検討などを行っていきました。そうした中でも、AWS のソリューションアーキテクト (SA) には大変お世話になりました。AWS Activate 参加スタートアップ向けの個別技術相談会 (Office Hour) などを活用して、具体的な質問をさせてもらい、一人で悩んで時間を浪費することなくアーキテクチャの設計ができたのは、時間価値の観点でも大きかったと思いますね。
今回のコンテストのベースとなっている AWS Well-Architected Framework についてはご存じでしたか？
実は、今回エントリーしたことで知りました。AWS W-A を活用することで、今の我々がどこまでやるべきなのか、何をリスクとして認識した上で、それを許容するか対処するべきなどかの指針を持てたことが大きかったと思いますね。
（小林氏）スタートアップの初期には、まずは MVP 目指してプロダクト開発を優先してしまい、本来あるべきアーキテクチャや考慮するべきとこを先送りして、結果、半年後や1年後のレビューのタイミングで、いわゆるベストプラクティス構成に戻すということが、ありがちだと思います。W-A を活用することで、最初の段階でそれを意識した設計をしておくことができるし、仮に初期の忙しいタイミングでもそうするべきだと改めて感じましたね。
今後、このコンテストを目指そうという方へのアドバイスをお願いします。
あらゆるスタートアップに、創業したタイミングで、「3年以内にこのコンテストに出るんだ！」ということを中間ゴールとして設定してみることをお勧めしたいです。実際にやってみて思ったのは、これはただのピッチコンテスト、つまり、アウトプットしておしまい、というものではなく、W-Aのレビューを通じての指摘事項、同じスタートアップの方々とのネットワーキング、そして、審査員の方々との交流などを通じて、膨大なインプットと学びを得られる場なのです。それはきっと、テックスタートアップの成長の過程で意味のある経験だと思いました。
インタビューは以上です。続けて、松谷さんによるアーキテクチャ解説をお届けします。
株式会社スタメン エンジニアの松谷 (Twitter: @uuushiro) と申します。当日のピッチではお伝えしきれなかった情報も含めて紹介させていただきたいと思います。
発表時のスライドはこちらを参照ください。
会社及びサービスについて
株式会社スタメンは現在 HR-Tech サービスを展開しているベンチャー企業です。2016 年 8 月より事業を開始し、翌年4月に正式リリース。「TUNAG（ツナグ）」という、会社と社員の間、社員同士などの組織エンゲージメントの向上、つまり、信頼関係の構築を目的とした企業向けの SNS を企画・開発・運営をしています。
TUNAG で発生したコミュニケーションデータや行動ログは、会社への関心や社員同士の関係性が反映されています。そのデータを分析することで、社内のエンゲージメント状況を定量的に測定することができます。
このようにデータという根拠に基づいた社内活性化施策の PDCA を回すことができるというところが TUNAG の強みです。今回構築したデータを扱う ETL 基盤はこれからの TUNAG のビジネス上重要なデータを支える鍵となっています。
システムアーキテクチャ
今回コンテストに応募したアーキテクチャは、TUNAG の ETL 基盤ですが、もともと2年前に作成した旧 ETL 基盤 (下図) がありました。
旧ETL基盤アーキテクチャ
日次でAmazon RDSインスタンスからdumpデータを取り出し、データベースのコピーを作成し、一つのRDSインスタンス内に追加していました。この形式では、全てを使い慣れたデータベース上で完結できるため、機能の構築は素早く行えたのですが、データ量が増えるにつれて以下3点の課題が顕在化してしまいました。
- データ増大によるストレージの枯渇
- データ増大による処理時間の増大
- 無視できないEC2の運用コスト
これらの課題を解決するべく、今回応募した新ETL基盤にリプレイスを行いました。
新ETL基盤のアーキテクチャ
全体像は以下の図のようになります。データの流れの順に説明します。
まず、Amazon S3 にすべてのデータを集め、S3 を ETL 基盤のデータの中心、つまりデータレイクとすることからはじめました。
データレイクとは、多様なデータを貯めておく広大な領域で、データの保存時に慎重に設計する必要がなく必要に応じてデータを抜き出せればよいという特徴があります。つまりアジャイルな検証を可能するための大事なポイントとなっており、組織エンゲージメントという KPI が不確実な領域においては、特にビジネス運営を効率化することができます。Amazon S3 という高い耐久性・可用性・スケーラビリティがあり、データの形式を問わず保存可能できるストレージサービスはデータレイクに適していました。
この ETL 基盤では、WEB サーバーで生成されるアクセスログを、Amazon Kinesis Data Firehose に送信し、次々と送られるデータを S3 に流し込みます。そして、Amazon RDS に保存されているマスターデータについては、AWS Glue ジョブでデータを抽出し、parquet 形式に変換した上で S3 に保存しています。この詳細については以下の記事に書いてあるので参照ください。
Amazon S3 に保存したデータ対して AWS Glue でクローリングをし、データのカタログを同期することで、後述する Amazon Athena から、テーブルとしてクエリができる状態にすることができます。
そして、そのクローラーの成功のイベントをフックして、CloudWatch Eventで集計処理のワークフローを実行します。
ここまですべてイベントドリブンな設計になっているため、サービス間が疎結合に保たれます。そして機能拡張が必要になっても、既存のイベントにサブスクライブするだけで対応が可能となり高い拡張性を獲得することができました。
集計は、Amazon Athena を利用しています。AWS Lambda が Amazon Athena に対して「CREATE TABLE AS」というクエリを実行して、Amazon S3 に集計データを再配置しています。
AWS には ETL に関連するサービスが複数存在しますが、今回の ETL 処理に、Amazon Athena を選択した主な理由は以下の4つです。
- 日々のデータ増加量が数 10GB 程度の ETL 処理であり、それほど大規模でない
- 例えば Amazon Redshift の場合、DB インスタンスを立ち上げておく必要があり、今回の ETL 基盤のような定時のバッチ処理などにはコスト効率が悪いが、Amazon Athena はデータをスキャンした分なのでコスト効率が良い
- Athena はフルマネージドサービスなので、インフラ管理が不要である
- 旧 ETL 基盤では SQL で変換処理を行っており、その SQL の資産を活かしたい
また、Amazon Athena を利用する ETL 基盤として考慮したポイントはエラー処理とリソース制限です。Amazon Athena そのものにはエラーのリトライ機構がないため、自前で実装する必要がありました。AWS Lambda で実行中のクエリのステータスをチェックし、失敗すれば AWS Step Function のエラー処理の仕組みを利用して、再試行やアラート通知を実行しています。
また、Amazon Athena の同時実行数には制限があるので、最大同時実行数以内で集計処理を並列化させる必要があります。現在の同時実行数を Amazon DynamoDB に記録し、その実行数を元に並列数を調整しています。
そして、Amazon Athena における集計処理や、その結果を分析用データベースにロードするなどの後続の処理は AWS Lambda において Ruby で実装しています。ちょうど去年の11月に AWS Lambda が Ruby に対応したという発表があり、TUNAG 本体のアプリケーションにおいて Ruby を利用している弊社にとって、サーバーレス開発のハードルがぐっと下がりました。AWS Lambda と Ruby の組み合わせに関しては、こちらのスライドにまとめてあるので是非ご覧ください。
Ruby × AWS Lambdaで サーバーレスの導入~TUNAG分析基盤の事例をもとに~
最終的には、集計データを Amazon Aurora にロードし、エンドユーザーに利用していただいています。
また別の集計のケースとして、新しくKPIの指標を追加する時など、過去分のすべて日付の集計をやり直すことがあります。その場合には、Amazon SQS に日ごとのジョブをキューイングし、それを AWS Lambda が順次受け取り、日別に AWS Step Function の集計ワークフローを並列処理しています。
集計処理のワークフローに AWS Step Function を利用することで、各集計ステップ同士の依存関係やエラー処理を簡単に管理することができます。
旧 ETL 基盤では、この集計処理に8時間ほど時間が掛かっていましたが、新基盤では、AWS Lambda のオートスケールを利用することで、なんと20分に縮めることができました。
このアーキテクチャを採用した3つの理由
このアーキテクチャを採用している理由は3つあります。
1つ目は、先ほども述べたように、AWS Lambda のようなスケールアウトや、Amazon S3 のスケーラビリティを確保したかったからです。これはTUNAGが順調に伸びていて、データが増加してきたからという理由です。
2つ目は、今後TUNAGはデータを活用した事業の展開をしていきたいと思っています。なので、まずAmazon S3に置くことで、ほかのAWSのMLOps系のサービスとの親和性も高くなり、事業の拡張がしやすくなると考えました。
3つ目は、私は、ある程度の規模のETL基盤の構築をしたことがなかったのですが、今回、ETL基盤のベストプラクティスを詰め込んだようなマネージドサービスを使うことで、短期間で構築できるのではないかということでこのアーキテクチャを採用しました。
Well Architectedな2つのポイント
「コストの最適化」と「運用上の優秀性」の2つです。
コスト最適化
まず、このシステムは、AWS Glue・Amazon Athena・AWS Lambda・Amazon Kinesis Data Firehose・Amazon SQSなどの、マネージドサービスとサーバレスを組み合わせています。そのため、サーバー管理など運用上の人的コストは限りなくゼロに近づきました。限られた開発リソースで、サービス本体ではないETL基盤へ掛ける人的コストは少しでも抑えたかったのでとても助かっています。
また、これらのサービスは従量課金なので、事前に予算を掛けすぎたり、リソースが枯渇するといった心配から解放されました。
運用上の優秀性
ETL基盤をただ構築するだけでなく、その後の運用を見越したアーキテクチャを実現しています。例えば、AWS SAMを使ってこのワークロード全体をコード化しています。そうすることで、デプロイの自動化に組み込みやすくなり、またプロダクションにデプロイする前に他のメンバーにコードレビューをしてもらえるなど、人的ミスを制限することができます。
また、集計処理の複雑なワークフロー管理には、AWS Step Functionを使っているので、以下の図のように、ビジュアルワークフローを用いて分散アプリケーションのコンポーネントを容易に管理することができます。
どこで集計の処理に失敗したかという情報は一目瞭然です。また、AWS Step Functionはエラー処理やリトライ処理の実装がとても柔軟にできるので、あらかじめシステムの障害を見越した上での設計を容易に組み込むことができました。
エラーハンドリングや再実行を細かく制御できるので、障害を予測した上でのシステム構築が非常にしやすいです。
また、AWS LambdaからAmazon Athenaを実行するなど、様々なサービスと相互作用するアプリケーションのパフォーマンスのボトルネックを特定するのは難しいです。
このアーキテクチャではAWS X-Rayを利用することで、リソースの関係やサービスのレイテンシを視覚的に把握することができ、様々な問題の診断が容易になっています。
アーキテクチャによるビジネスへの貢献
アーキテクチャによるビジネスへの貢献については3つあります。
1つ目は、クラウドの高いスケーラビリティがもたらしたメリットです。Amazon S3 を活用することでストレージのスケーラビリティが確保され、データレイクとしてのメリットを享受することができました。また、 AWS Lambda のオートスケールを活用し集計処理の並列化を実現することで処理時間が大幅に短縮されました。この集計処理の時間短縮はデータ分析の試行錯誤の回数を増やすことになり、運用上の効率を上げることができました。
2つ目は、マネージドサービスがもたらしたメリットです。私は ETL 基盤リプレイスプロジェクトの担当になったのですが、ETL 基盤を構築した経験は無く、しかも短期間で構築することが求められていました。そんな中、マネージドサービスという基盤を構築する上でのベストプラクティスを盛り込んだシステムを組み合わせることで、限られた開発リソースで、そして ETL 基盤に関して詳しかったわけでもない私でも短期間で構築することができました。
3つ目は、他 AWS サービスとの親和性の高さです。S3 にデータを集約したことで、データ活用系の AWS サービスとの親和性が高まり、TUNAG の今後に向けたデータを活用した事業の展開の可能性を広げることができました。旧 ETL 基盤における課題を解決しただけでなく、未来を見据えた基盤に生まれ変わりました。
まとめ
今回発表させていただいた ETL 基盤は、AWS のマネージドサービスを組み合わせただけのシンプルな構成で特に複雑なことはしていません。その分クラウドの強みをちゃんと活かし、かつ今後のデータ分析における試行錯誤がしやすい柔軟な基盤にしました。
データはすべてデータレイクで一元管理することで、必要なときに必要なデータを取り出せるようになりました。そして AWS Lambda の並列処理によって集計をやり直す場合でも時間を大幅に短縮することができました。つまりこの ETL 基盤はアジャイルなデータ分析を可能にする環境を提供し、不確実な領域に立ち向かうとても心強い武器になりました。この武器をフル活用し、データに基づいた組織のエンゲージメント分析をより一層進めていきたいと思います。
最後に
TUNAG は、多くの企業に導入いただき、今後さらなる規模拡大に向けて、インフラのリアーキテクトだけでなく、アプリケーションの機能拡張、ネイティブ・フロントエンドでの UI/UX 改善、機械学習でのデータ活用など、各分野で積極的な開発が必要となっており、エンジニアを積極的に採用しています。今回グランプリを受賞した ETL 基盤だけでなく、TUNAG 本体、そして新規プロダクトを一緒に作ってくれるエンジニア募集しています！興味を持ってくれた方は是非、下記のエンジニア採用サイトを見てください！
スタメンでは、様々な社員がご自身の目標達成をみんなで祝う文化があるそうです。松谷さんが指を指しているのは、Architecture Of The Year 受賞をみんなでお祝いした時の写真です。