スタートアップのプロダクト成長の舞台裏とコンテナ化までの道のり

AWS Startup Tech Meetup Online #10 登壇資料

Transcript

1. スタートアップのプロダクト成長の 舞台裏とコンテナ化までの道のり
2. 自己紹介 2 松谷 勇史朗 株式会社スタメン CTO 愛知県出身 創業直後の株式会社スタメンへ新卒入社 当時3人目のエンジニアとして参加 2020年にCTO就任
3. 3 社名 株式会社スタメン 設立 2016年1月29日 所在地 名古屋本社 愛知県名古屋市中村区井深町1-1 拠点 鎌倉支社 / 大阪支社 代表者 加藤 厚史 従業員数 68名（2021年6月末時点の正社員数） 資本金 6億730万円 事業内容 エンゲージメント経営プラットフォーム 「TUNAG」の企画・開発・運営 オンラインサロンプラットフォーム 「FANTS」の企画・開発・運営 会社概要- 会社について
4. 4 これまでの歩み これまでスタートアップとしてビジネスや技術の課題にどのように向き合ってきたのか？をお伝えしま す。 2016 1月 設立 8月 創業 2017 1月 東京支社設立 3月 総額2.8億円を 資金調達 4月 TUNAGをリリース 2018 5月 大阪支社設立 7月 『週刊東洋経済』の すごいベンチャー100に選出 HR Tech GP 2018にて オーディエンス賞を受賞 2019 6月 Startup Architecture Of The Year 2019にて グランプリ受賞 11月 TUNAGグローバル版を リリース 2020 2月 働きがいのある会社 ランキングにて第1位 5月 新規事業 FANTSリリース 12月 マザーズ市場に上場 日本テクノロジーFast50 に て第1位受賞 2021 4月 デロイトトーマツG アジア太平洋地域 テクノロジー Fast500 にて第6位受賞 関東拠点を 鎌倉支社に拡大移転 2019.6 2020.2 2020.12 2020.12
5. 5 事業紹介 Our Business ２つのエンゲージメント事業 スタメンでは「ITとリアルの融合」をテーマに事業を展開しており、 現在、エンゲージメント領域において、２つのSaaS型サービスを提供しています。 また、2021年度より新規事業立上げを一層強化すべく、 役員主導の新規事業立案コンテスト「STAR PROJECT」を年に2回行っています。 SaaSモデルの "社内制度運用クラウド" と "組織コンサルティング" をワンストップサービスで提 供し、顧客企業の組織課題に貢献するプラットフォーム事業です。 エンゲージメント経営プラットフォーム TUNAG コミュニティ運営に必要な機能をワンストップで提供し、コミュニティのエンゲージメント向上 と収益化を支援するプラットフォーム事業です。 オンラインサロンプラットフォーム FANTS
6. TUNAG - エンゲージメント経営プラットフォーム 企業でのエンゲージメント(信頼関係)の構築を目的とした社内SNS。 お互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションが目的。
7. TUNAG - 実際にスタメンで使っている画面
8. FANTS - オンラインサロンプラットフォーム オンラインサロンを開設・運営するためのプラットフォーム。SNS + サブスク をアプリで。 ２つ目の事業として2020年5月にリリース。コロナ禍でのコミュニティ運営や収益化を支援。
9. FANTS - 主なオンラインサロン プロスポーツチーム、アイドルユニット、タレントや著名人、レジャー施設、YouTuber、 協同組合、スクールや習い事など、幅広いカテゴリーでオンライサロン展開が拡大中。
11. スタートアップのプロダクト成長の 舞台裏とコンテナ化までの道のり
12. • コンテナ化するまでの経緯 ◦ 2017年 (立ち上げ期) ◦ 2018年 (立ち上げ期) ◦ 2019年 〜 2020年 (成長期) ◦ 2020年 〜 2021年 (新規事業) • 移行作業について ◦ Chef Solo の内容を Dockerfile へ移行 ◦ アプリケーションのコンテナ移行 ◦ デプロイ方式の移行 ◦ cronサーバーをECS Scheduled Taskへ移行 ◦ ログ管理を AWS Firelens へ移行 アジェンダ 最近、弊社が提供している 「エンゲージメント経営プラットフォーム TUNAG」 と 「オンラインサロン プラットフォーム FANTS」 のアプリケーション環境をECS上のDockerコンテナへ移行しました。 約5年間、EC2で本番運用してきたRailsアプリケーションをコンテナ化することはとても困難でリスクの 高い大変な作業でしたが、今後、開発組織としてプロダクトのスケーラビリティに向き合うために必要だ と判断し実行しました。
13. コンテナ化するまでの経緯
14. 14 2017年 (立ち上げ期) 2016 8月 創業 2017 4月 TUNAGをリリース 2018 2019 導入企業数増加 エンタープライズ企業の増加 障害件数増加 2020 新規事業 FANTSリリース 12月 マザーズ市場に上場 2021 • プロダクト立ち上げ時には、アプリケーションの実行環境と して最も慣れていた EC2 を選択 • ECS という選択肢もあったが、当時は他社の採用事例が少な く、社内にコンテナや ECS のノウハウが無かった • また、サーバー構成管理ツールとして Chef Solo を導入 創業事業である TUNAG は、2017年にサービス提供を開始した、もうすぐ6年目のBtoBサービス Railsエンジニア1~3名で開発。 エンゲージメント経営プラットフォーム TUNAG
15. 15 2018年 (立ち上げ期) 2016 8月 創業 2017 4月 TUNAGをリリース 2018 2019 導入企業数増加 エンタープライズ企業の増加 障害件数増加 2020 新規事業 FANTSリリース 12月 マザーズ市場に上場 2021 • サーバー増設の必要があれば、都度手動でEC2インスタンス を立ち上げ、Chef Solo でサーバーをプロビジョニングして いた • 導入企業数も少なかったため、増設の頻度は少なく運用コス トはほぼなかった • プロダクト開発に集中できていた 導入企業数は増えつつも、スケーラビリティの問題は特に発生していなかった。 WEBエンジニアが10人ほどに増加。 エンゲージメント経営プラットフォーム TUNAG
16. 16 2019年 〜 2020年 (成長期) 2016 8月 創業 2017 4月 TUNAGをリリース 2018 2019 導入企業数増加 エンタープライズ企業の増加 障害件数増加 2020 新規事業 FANTSリリース 12月 マザーズ市場に上場 2021 • スケーラビリティの課題が大きくなってきたこの時期に、シス テムの信頼性向上に取り組むチームとしてSREチームが発足 • スケーラビリティにおける課題を発見すれば、SREチームがア プリケーションのパフォーマンスチューニングをしたり、手動 でサーバーを構築し本番環境に投入していた • ただ、SREチームとはいえインフラ専任ではなく、アプリケー ション開発も並行していたため、手動でのインフラ運用コスト は無視できなかった 導入企業数が増え、ニーズの多様化に対応するためにプロダクトが大規模になってきました。 エンタープライズ企業様の導入が進むにつれて、サーバーの負荷が一気に高まるシーンが増えていました。 エンゲージメント経営プラットフォーム TUNAG
17. 2020年には、新規事業 FANTS のサービス提供が始まりました 17 2020年 〜 2021年 (新規事業) 2016 8月 創業 2017 4月 TUNAGをリリース 2018 2019 導入企業数増加 エンタープライズ企業の増加 障害件数増加 2020 新規事業 FANTSリリース 12月 マザーズ市場に上場 2021 • 少人数で、TUNAGのスケーラビリティを確保しつつ、一方 で FANTSのインフラを支える • FANTSのアプリケーションがTUNAGのコードを再利用して いたことから、TUNAGと同じくEC2 を選択 オンラインサロンプラットフォーム FANTS
18. 直近1年で運用サロン数が10倍以上に急成長 18 2020年 〜 2021年 (成長期) 2016 8月 創業 2017 4月 TUNAGをリリース 2018 2019 導入企業数増加 エンタープライズ企業の増加 障害件数増加 2020 新規事業 FANTSリリース 12月 マザーズ市場に上場 2021 • 少人数で２つのビジネスの急成長を支える必要があった • このペースでサービス成長が続けば、今後負荷対策が後手に 回ってしまうのは明らかだった • さらに毎年、新規事業を生み出していく方針 • 少人数で複数ビジネスのインフラを横串で管理できるベスト プラクティス導入の必要性が高まっていた
19. 当時のインフラ管理の課題は？
20. 冪等性を考慮する難しさと本番稼働中のサーバーを変更する不安 • この冪等性を考慮してコードを管理することが難しく、様々な状況を考えないと一発でサー バー設定を完了させることができませんでした。 • 当然、ツール自体の問題ではなく使い方の問題ですが、今後、複数人でサーバーの設定管理 していくことの難しさを感じていました。 • サーバーを増設するたびに、Chef Solo の実行エラーに悩まされたり、他のサーバーと本当に 同じ設定になっているかどうかの確認作業によって、少なくない時間を使っていました。 • 本番サーバーの設定を変更する際には、オンラインで Chef Solo を適用していました。 • オンラインで適用しても問題ないことを確認しているとはいえ、本番環境で稼働しているサ ーバーを変更することの安全性に不安を感じていました サーバー管理に利用していた、Chef Solo の特性として冪等性というものがあります
21. 一部メンバーへの負担の偏り • 負荷対策は緊急度が高く、他のメンバーに経験してもらう機会を作りにくいこと • 作業そのものが危険なため、慣れている人が毎回実施してしまうこと • 今後 Chef Solo が更新されないことが分かっており、今から学ぶモチベーションが生まれづ らいこと 以下の3点の理由から、サーバー管理スキルの冗長化が遅れ、一部メンバーの負担が高い状況が 長いこと続いてしまっていました。
22. 2021年、ついにコンテナ移行プロジェクトが始まる • コンテナのように、変更の度にアプリケーションを使い捨てにできるのであれば、冪等性の 考慮も不要になり、本番で稼働中のサーバーを変更する必要がありません。 • また、Docker、 ECS、Kubernetesなどコンテナ関連の技術は大きなトレンドにもなっており 、エンジニアが学ぶモチベーションにも繋がります。 • これらのコンテナの特性こそがチームが必要としていたものであったことは理解しており、 過去にコンテナ化を検討したことは何度かありましたが、プロダクト開発を優先し見送って きました。 • しかし、既存の運用方式は限界だったこと、複数のビジネスの急成長を少人数で支えるため にはインフラ運用コストを圧縮する必要があることから、コンテナ移行プロジェクトが始ま りました。 これまで述べたように、各種インフラ作業の心理的ハードルが高く、プロダクトのスケーラビリ ティを支える上で、健全な状態ではなかったと言えます。
23. コンテナ移行作業について
24. アプリケーションのコンテナ化 • Chef Solo を読み解き、Dockerfileへ移植 • アプリケーションで稼働していたRailsのプロセス4種類をコンテナに最適化 ◦ Webアプリケーション本体のPuma ◦ 非同期処理の Sidekiq、delayed_job ◦ cron • プロセスごとに起動するタスク数やスケーリングの設定は異なるため、 プロセスごとに ECS Service を分けて管理 • 各種ECS Serviceにオートスケーリングを設定することで、今後サービスの負荷が増える につれてアプリケーションを自動的にスケーリングしてくれる状態を実現 コンテナ(ECS)移行における主要な変更点について簡単に共有します。アプリケーションのコン テナ化だけでなく、周辺のシステムアーキテクチャレベルでの変更もいくつかありました。 ECSに移行することでインフラ運用工数の削減🎉
25. デプロイ方式の移行 • もともとデプロイには Capistrano を利用して、SSHでリモートサーバーにアク セスし、各種プロセスを再起動してアプリケーションを更新していた • このため、sidekiq や delayed_job の更新時にはプロセスが完全に停止し、一時 的にキューが詰まるという問題が発生していた • ECS環境では、デプロイメント方式として「ローリングアップデート」と「 BlueGreenデプロイメント」の2つを提供しているのでこちらの方式へ移行した 移行前
26. デプロイ方式の移行 • 非同期処理(Sidekiq と delayed_job)はローリングアップデート方式を採用することで、 稼働中のプロセスを完全に停止させずに徐々に新しいものに入れ替えていくことができ るようになったため、キューが詰まる問題が解消🎉 • Webアプリケーションプロセス(Puma)をローリングアップデート方式でデプロイする場 合、デプロイ途中に一定時間、新旧のコンテナが混在し、新しいコンテナへのリクエス トで表示されたページから、古いコンテナへリクエストが飛ぶケースが存在するため、 一度に新旧コンテナへのトラフィックを切り替えるBlueGreen方式を採用 • BlueGreenデプロイメント方式は切り戻しが一瞬なので、今後リリース直後の不具合の影 響を極小化できるように🎉 インフラ運用負荷の圧縮以外にも、ユースケースごとにデプロイメント方式を柔軟に変更できる ことはECSに移行した大きなメリットだった🎉 移行後
27. cronサーバーをECS Scheduled Taskへ移行 • 移行前のcrontabの運用では、システムの冗長化が難しく単一障害点となってい た • 単一のcronサーバーで運用していたため、負荷分散も難しくサーバーのスペッ クを上げるしか負荷対策の方法がなかった 移行前
28. cronサーバーをECS Scheduled Taskへ移行 • 移行後は、ECS Scheduled Task というAmazon EventBridge ルールを使用したECSタス ク実行の仕組みを利用 • 単一障害点であったcronサーバーから、Amazon EventBridge というマネージドサービス に乗り換えることができ可用性が向上 • ECS Scheduled Task を利用することで各定期処理ごとにコンテナが立ち上がるため、負 荷分散が自動で行われるようになり、負荷対策のために定期処理の時間帯をずらすよう な運用も撤廃 可用性が向上し、運用ルールもシンプルに🎉 移行後
29. ログ管理を AWS Firelens へ移行 • もともとはEC2上で、kinesisエージェント を起動し、一部アプリケーションの ログをKinesis Firehoseへ転送し、S3で保存する仕組みが存在していた。 • kinesisエージェントが意図せず停止してしまった場合に、その期間のログが欠 損してしまうという問題があった。 • また、一部のログ以外のほとんどのシステムログを転送する仕組みが無く、 EC2インスタンス上に保存されていた 移行前
30. ログ管理を AWS Firelens へ移行 • コンテナに適したステートレスなアプリケーションにするために、全てのログ をAWS Firelens というログルーター経由で外部へ転送する方式に変更 ◦ Firelens: コンテナのサイドカーとして配置し、他のコンテナからはログドラ イバーとして使用できる仕組み • ECSのタスク定義で、ログルータコンテナとアプリケーションコンテナの依存 関係を定義できるので、確実にログルーターコンテナがヘルシーな状態でアプ リケーションコンテナを起動することを保証することができるように ログの正確性が向上🎉 移行後
31. 勝ち取ったコンテナ環境 • 多くの課題を乗り越えてようやく勝ち取ったコ ンテナ環境のおかげで、これまで多くの時間を 割いてきたサーバー構成管理やインフラ増強な どのSRE業務は圧縮され、プロダクト開発に集 中できる状態になってきています。 • SRE作業の安全性が高まったことから、SRE経 験のないメンバーも積極的に巻き込むことがで きるようになり、徐々に一部メンバーへの負担 の偏りも減ってきています • コンテナ移行をきっかけに、開発組織として大 きく前進していきたいと考えています • 今回の話はブログにも書いています。 https://tech.stmn.co.jp/entry/2021/1 1/11/130328
32. 少しずつプロダクト開発に集中する上で、在るべき姿に近づいてきた👍 32 そして今後 2016 8月 創業 2017 4月 TUNAGをリリース 2018 2019 導入企業数増加 エンタープライズ企業の増加 障害件数増加 2020 新規事業 FANTSリリース 12月 マザーズ市場に上場 2021 • スタメンは TUNAG と FANTS だけでなく、世の中にいくつもの事業を生み出していく会社 • 複数事業を運営する組織において、パターン化しやすい領域、つまり事業固有の事情が小さく専門性が高 い領域は横断的な価値が活きてくる • 今回獲得したコンテナの知識を組織のベストプラクティスとして横展開しインフラ運用効率を上げ、プロ ダクト開発に集中できるような体制を目指していきたい 2022 コンテナ化
33. AWSエンジニア絶賛採用中です！ AWS, Rails, React/Next.js, マネージャーを採用中 エンジニア採用サイトにて、メンバーインタビュー、 カルチャーや技術について、エンジニアブログなどを紹介しています。
34. Meety絶賛開放中です！