Build Blog

Saambaa事例:Buildで1日5,000万リクエストをスケール

SaambaaがBuildへの移行によって、1日5,000万リクエストへのスケールとプロダクト開発の加速をどのように実現したか。

SaambaaがBuildで1日5,000万リクエストをスケールし、プロダクト開発を加速させた方法


Saambaaの概要

  • プロダクト: 大手パブリッシャー向けのハイパーローカルコンテンツプラットフォーム
  • トラフィック: 1日5,000万リクエスト
  • ピーク負荷: 毎秒約1,000リクエスト

主な成果

  • カスタムVMベースのデプロイプロセスを置き換える、モダンなCI/CDワークフローを導入
  • 1日数百万のリクエストと毎秒約1,000リクエストをサポートする自己修復型インフラ
  • エンジニアリングの時間がプロダクト開発に集中できるようになり、成長を加速させるプロダクトを迅速に構築・リリース
  • Buildエンジニアへの直接アクセスにより、より良いデプロイ慣行と運用改善が可能に

会社概要

Saambaaは、大手パブリッシャーが利用するハイパーローカルなイベント、ニュース、広告プラットフォームを支えています。彼らのシステムは、メディアパートナーのネットワーク全体にリアルタイムのコンテンツとターゲットされた体験を配信します。

このプラットフォームは毎日数千万のリクエストを処理し、ピーク時には毎秒約1,000リクエストを超えることもよくあります。

プラットフォームが成長するにつれて、それを支えるインフラはペースに追いつくのに苦労しました。エンジニアリング時間のますます大きな部分が、プロダクト自体に新しい機能を構築する代わりに、環境の維持と安定化に費やされるようになりました。

チームは限界点に達しました。プロダクトのリリースに集中できるよう、インフラが邪魔にならなくなる必要があったのです。


機会

Saambaaは、デプロイワークフローをモダン化し、以前のインフラに伴ったDevOpsの抵抗を取り除く方法を探し始めました。

彼らの環境は、仮想マシン、ロードバランサー、そしてカスタムデプロイプロセスに依存していました。機能はしていたものの、脆弱で、エンジニアリングチームからの絶え間ない注意を必要としていました。

Saambaaに必要だったのは、単に新しいインフラプロバイダーではありませんでした。チームがソフトウェアをリリースする方法を変革するプラットフォームが必要だったのです。


ソリューション

Buildは、彼らの規模を処理するキャパシティを備えた、モダンな開発ワークフローをSaambaaに提供しました。

Buildは、マシン中心のインフラを、自動的にスケールし、自己監視し、自己修復するdynoフリートに置き換えます。個々のサーバーが重大な障害点になる代わりに、アプリケーションは可用性を自動的に維持するように設計された協調システム全体で実行されます。

稼働後、SaambaaはモダンなGitベースのデプロイパイプラインに移行しました:

  1. 開発者がGitHubにコードをプッシュ
  2. 継続的インテグレーションが自動テストを実行
  3. 成功したビルドが自動的にステージングにデプロイ
  4. 検証後、リリースが本番にプロモート

その結果、シンプルで予測可能、劇的に運用が容易なワークフローが生まれ、チームはインフラの心配から解放され、顧客への価値提供に集中できるようになりました。


インパクト

最大のインパクトは、単なる安定性の向上ではありませんでした。Saambaaチームが取り戻した時間で何ができるようになったかでした。

インフラがバックグラウンドで静かに動作することで、エンジニアはプラットフォーム自体の改善に集中できるようになりました。

Buildへの移行以来、Saambaaはビジネスの成長を加速させるいくつかの取り組みを立ち上げており、それには以下が含まれます:

  • 新しい地域プロダクト
  • AI駆動のプラットフォーム機能
  • パブリッシャーパートナー向けの追加ツール

インフラの保守のために以前は優先度を下げられていたプロジェクトが、迅速に開発され、顧客にリリースされました。

以前のインフラから移行して以来、Saambaaはダウンタイムゼロを経験しており、チームに大きな安心感を与えています。Buildチームはまた、Saambaaと緊密に協力してアーキテクチャの改善や運用のベストプラクティスを推奨し、プラットフォームが会社の成長するプロダクトの野心とともに進化し続けることを保証しています。

そのシフトはシンプルでありながら強力なものでした。保守する代わりに、チームは構築できるようになったのです。


サポートキューではなく、エンジニアからのサポート

もう一つの意味のある違いは、Buildチームによって提供されるサポートのレベルです。

従来のサポートキューとやり取りする代わりに、Saambaaはプラットフォームを深く理解するBuildエンジニアと直接連携しています。

チームは定期的に連絡を取り合い、デプロイ戦略、インフラの変更、運用改善をレビューします。これらの会話は、Saambaaチームがプロセスを洗練させ、運用の負担を増やすことなくモダンなベストプラクティスを採用するのに役立ってきました。

高トラフィックのプラットフォームを運用するチームにとって、エンジニアへの直接アクセスは大きな利点であることが証明されています。


スケールするために構築された

今日、Saambaaのプラットフォームは、成長とともにスケールするように設計されたインフラ上で動作しています。

アプリケーションは、負荷を分散し、障害から回復し、トラフィックの増加に応じてキャパシティをスケールするdynoのフリート全体で実行されます。需要が増えると、チームは新しいサーバーをプロビジョニングする代わりに、Buildインターフェースを通じて直接キャパシティを増やすことができます。

1日数百万のリクエストを処理するプラットフォームにとって、そのレベルの運用のシンプルさは大きな利点となっています。


今後の展望

Buildは今、Saambaaのプラットフォームのコア部分を支えています。

かつては絶え間ない運用上の注意を必要としていたものが、今ではバックグラウンドで静かに動作し、エンジニアリングチームがパブリッシャー向けのプロダクトの構築とプラットフォームの拡大に集中できるようにしています。

インフラがもはや彼らを遅らせることがなくなった今、Saambaaチームはこれまで以上に速く動けるようになっています。


Buildがあなたのチームをどのようにサポートできるか、ご覧ください - デモを予約する →