高負荷システムのインフラストラクチャコストを削減する 5 つの方法: AdTech ケーススタディ

クラウドの誇大宣伝の波が沈静化するにつれて、通常は目立たないクラウド インフラストラクチャの副作用を発見する技術チームが増えています。 オンデマンドのスケーラビリティ、オンプレミス サービスの管理時間の短縮、その他の利点は有望に聞こえますが、多くの場合、高負荷システムにおけるインフラストラクチャ コストの高騰という重大な欠点によってバランスがとれています。 インフラストラクチャのコストについて議論するとき、高負荷システムに重点が置かれます。小規模企業にとって、クラウドよりも柔軟で安価な代替手段はほとんどありません。 しかし、QPS が数十万に達すると、少額に見えるベンダー手数料はもはや持続可能ではなくなります。 AdTech 向けの高負荷システムの構築と最適化を専門とするソフトウェア開発会社として、私たちはインフラストラクチャのコストの高騰を防ぐためにチームが使用する複数の実践方法を検討してきました。 15 年以上の経験を持つ Xenoss は、Activision Blizzard、Verve Group、Smartly、Voodoo、Inmar Intelligence などのプロジェクトのサポートを支援し、堅牢かつ機敏なインフラストラクチャを構築しました。 この投稿では、高負荷プラットフォームに関連するインフラストラクチャの課題に関する経験とノウハウを共有し、コストを合理化する方法を検討したいと思います。この投稿で示されている戦術を説明するために、速度と規模が交渉の余地のない業界であるアドテックを使用します。 また、インフラ について詳しく説明したブログ投稿もあり、ソフトウェア アーキテクトからの専門的なヒントとコメント、およびインフラストラクチャ コストを 20 倍削減したケース スタディが紹介されています。 ストラクチャ コストの最適化 AdTech プラットフォーム – 高負荷システムの代表例 高負荷プラットフォームにより、銀行、医療などの複数のセクターが可能になります。プログラマティック広告は、多くの場合、開発する技術的な偉業とは見なされませんが、その運用要件がインフラストラクチャ設計の限界を押し上げることが多いため、他の複雑なシステムに匹敵する可能性があります。 AdTech プラットフォーム (SSP、DSP など) が を検討するための優れたレンズである理由を簡単にまとめてみましょう。 インフラストラクチャ コストの最適化 大音量と低遅延に対するプレッシャー AdTech プラットフォームは、大量のトラフィック量と低遅延のニーズの間で絶えず綱引きに巻き込まれています。 一方で、オンライン広告によって生成される膨大な量のトラフィックを処理する必要があります (TPA Digital の CEO 、トラフィックは 1 日あたり 9,500 億インプレッションに相当します)。 である Wayne Bloodwell 氏によると 負荷に加えて、エコシステムのリアルタイム性により、新たな複雑さが加わります。 AdTech プラットフォームのレイテンシーが長いこと、つまり入札リクエストと応答の間の遅延により、広告主は入札が時間内に処理されず、高品質の広告枠を逃すことになります。 遅延が長いと、パブリッシャーは広告スロットを埋めるのに苦労し、長期的には収益の低下につながります。 入札処理の標準的な時間枠は、業界が運営する平均的な時間枠で、80 ～ 120 ミリ秒程度です。 リアルタイムの意思決定 リアルタイム データ処理は、次のような課題により、アドテック プロジェクトにとって繰り返し発生するもう 1 つの課題です。 入札価格モデリングなどのリアルタイムの意思決定を行うために、データを迅速 (100 ミリ秒未満) に取得する必要があります。 複数のソースから視聴者データを収集すると、パイプラインが複雑になり、さまざまな種類のデータを処理するために必要なツールセットが拡張されます。 データ品質に関する懸念: データが間違っていると、広告主が不適切な入札決定を下す可能性があります。すべてのパイプライン段階 (取り込み、処理、消費) のデータ品質チェックが不可欠です。 以下のクリップは、リアルタイム データ分析の複雑さと重要な操作を示しています。 https://www.youtube.com/watch?v=uaRzovqK3t0 スケーラビリティの要求 アドテック業界には周期性があり、経済の浮き沈みによって広告サービスの需要が変動します。市場の高騰により、AdTech プラットフォームは動的なスケーラビリティ機能の実装を迫られています。 SPO の増加に加え、アドテック ベンダーは需要の変化に応じてキャパシティを確実に増減させるプレッシャーを感じています。したがって、パフォーマンスや信頼性を犠牲にすることなくピーク トラフィックを処理する (そして市場の変動に合わせてスケールダウンする) 能力とリソースが必要です。 生データと集約データの収集 生データの使用は、AdTech プラットフォームの成功にとって極めて重要です。これらのシステムは、人口統計情報、閲覧履歴、ユーザー行動などの大量の集約データを収集します。これらの洞察はさまざまなソースから統合され、ターゲティングとパーソナライゼーションを促進するのに役立ちます。 生データを使用する準備が整う前に、抽出、変換、読み込みという ETL の手順を実行する必要があります。ただし、システムがスケールし、データ量が急激に増加するにつれて、複数のパイプラインを維持することはエンジニアリング上の課題になります。 Xenoss が高負荷システムのインフラストラクチャ コストを最適化するために使用するベスト プラクティス 技術チームがインフラストラクチャのコストに細心の注意を払わないと、すぐに制御不能になってしまいます。非効率的なデータ モデリングとストレージ、サービスへの依存の選択性の欠如、事前の脅威への計画と対抗の失敗により、インフラストラクチャは予測不可能で、遅く、高価で、維持が困難になります。 インフラストラクチャ コストの削減は 1 日でできる作業ではありませんが、エコシステムとプラットフォームの知識があれば、いくつかの調整で大幅な削減を達成できます。 ここでは、Xenoss 技術チームがクライアントの無駄のないインフラストラクチャの実現を支援するために使用しているインフラストラクチャ削減手法のリストをいくつか示します。 ハイブリッド クラウド インフラストラクチャのメリットを探る 初期段階のプロジェクトでは、最適なクラウド インフラストラクチャの設計についてはあまり考慮されていません。技術チームは通常、2 つの方法のいずれかを選択します。 (AWS、Google Cloud、Microsoft Azure など)。開発プロセスの初期段階でクラウド ベンダーに依存するのは理解できますが、厳密に必要でない場合はマネージド サービスを使用しないよう技術リーダーに警告したいと思います。これらのツールは時間の経過とともに、プロジェクトのインフラストラクチャの請求額を大幅に増加させる可能性があります。インフラストラクチャの請求額が 250 万ドルになったときに、当社のクライアントの 1 つから連絡がありました。 パブリック クラウド サービス プロバイダー 。最近では、初期投資と人材が必要となるため、オンプレミスのデータセンターを維持することは初期段階のプロジェクトではそれほど一般的ではありません。オンプレミスのインフラストラクチャには、制御の強化やセキュリティの強化などの利点があることは注目に値します。 社内チームによって維持されるオンプレミスのインフラストラクチャ アドテックでは、柔軟性と動的に拡張する能力が極めて重要です。インフラストラクチャのコストを完全に制御することと、セキュリティを強化する機能も同様に重要です。前者は通常クラウドに関連するものであり、後者はオンプレミスの利点としてよく挙げられます。 Xenoss では、両方のインフラストラクチャの利点を認識しているため、クライアント プロジェクトで両方を使用しています。クラウドとオンプレミスの組み合わせは「ハイブリッド クラウド」と呼ばれることがよくありますが、この用語に適した組み合わせはさらに多くあります。パブリック クラウドとプライベート クラウド、または 2 つのパブリック クラウド (別名マルチクラウド) を組み合わせることもコンセプトに適合します。 、調査対象の組織の 33% がクラウドとオンプレミスのインフラストラクチャを組み合わせて使用しています。企業組織 (従業員 1000 人以上) のみを考慮すると、この数字は 42% に達します。 DZone が発行した Data Pipelines レポートによると ハイブリッド モデルは、アドテック チームに高い財務上の柔軟性を提供し、アドテック プラットフォームがオンプレミス設定の制御とクラウド プラットフォームの動的なスケーラビリティを統合できるようにします。 セキュリティも大きな利点です。プロジェクトは、機密データをオンプレミスに保管し、重要性の低いタスクにはクラウドを使用することで、厳格なデータ保護基準を維持できます。 私たちがハイブリッド アプローチを好み、推奨するもう 1 つの理由は、ベンダー ロックインを防止できることです。重要なインフラストラクチャをオンプレミスに維持することで、企業は 1 つのクラウド プロバイダーに依存せずに技術スタックを多様化する余地が得られます。 さらに、ハイブリッド アプローチにより、製品チームはワークロード固有のインフラストラクチャをより意図的に構築できるようになります。 リアルタイムの広告入札や、厳格な地域コンプライアンスに拘束されるデータ操作など、アドテックの一部のタスクは、オンプレミスでの実行に適しています。 同時に、他のワークフロー (キャンペーン分析、分散広告コンテンツ ホスティング、または共同広告デザイン) をクラウドにシームレスに移行できます。 データストレージの最適化 私たちの経験では、ストレージを最適化するだけでインフラストラクチャのコストを大幅に削減できます。 AdTech では、構造化データと非構造化データの管理に SQL データベースと NoSQL データベースの両方が使用されます。 2 種類のデータベースの主な違いと、アドテックでの使用例をまとめてみましょう。 議論にさらに文脈を加えるために、この 2 つの違いを要約してみましょう。 リレーショナルデータベースの利点 NoSQL データベースの利点 高信頼性 ハイパフォーマンス 高いデータ一貫性 高い拡張性 標準化されたスキーマ 大量のデータに最適化されたストレージ ACID準拠 高い俊敏性とカスタマイズ性 ここで、トップの AdTech プラットフォームに選ばれるデータベースと、そのデータ ストレージへのアプローチを見てみましょう。 AdTech ベンダーが SQL データベースを使用して大量のデータを運用する方法 パブマティック Pubmatic SSP は、パブリッシャーが独自の需要パートナーシップ、高度な分析、クリエイティブ最適化ツールを使用して幅広い視聴者を獲得し、広告収入を最大化するのに役立ちます。 同社は大規模なデータセットを処理し、複雑な問題を解決するための堅牢なデータベースを必要としていました。同社は、何よりも信頼性が高く効果的な、実戦でテストされたツールを求めていました。 課題: MySQL 解決策: PubMatic の Ad Quality チームは、主要なデータ ソースとして MySQL を使用しています。プラットフォームのデータベースには最大 1 億件のレコードが保存されます。信頼性と堅牢性で知られる MySQL を使用すると、PubMatic は 1 日に何百万ものクリエイティブを処理し、2 倍から 10 倍のデータ負荷を維持できます。 影響: アドグリーツ AdGreetz は、ソーシャル メディア、CTV/OTT、アプリ内などの複数のチャネルにわたって、カスタマイズされた広告クリエイティブを配信するパーソナライゼーション プラットフォームです。 組織のワークフローはデータ集約型であり、数百万のユーザー レコードをサポートするデータベース管理ソリューションが必要です。 課題: ClickHouse 選択したデータベース: AdGreetz のエンジニアリング チームにとって、Clickhouse はコスト効率が高く、パフォーマンスの高いソリューションであることがわかりました。同社は、小規模なコンピューティングでクエリ時間を数秒から 1 秒未満に短縮することができました。 影響: AdTech プロジェクトでの NoSQL データベースの使用方法 蜜蝋 Beeswax は、広告主がプログラマティックな運用を合理化できるようにするマネージド RTB プラットフォームです。同社は、1 秒あたり数百万のクエリを処理し、1 分あたり 125 GB のデータを消費する Bidder-as-a-Service ソリューションを提供しています。 効率的な広告配信を保証する迅速なスケーリング、組織のマシン全体での均等な負荷分散の必要性。 課題: Amazon EC2 上で実行される Aerospike。 選択した NoSQL データベース: Beeswax は、2 ミリ秒の末尾読み取り遅延で 1 秒あたり数百万のクエリを処理できます。 影響: ガムガム GumGum は、独自の機械学習プラットフォームである Verity によって可能になるコンテキスト ターゲティングのプラットフォームを提供します。 同社は、大量の広告関連データ (インプレッション、ビュー、クリック、コンバージョン) を最小限の遅延で処理したいと考えていました。データはリアルタイムで処理されませんでしたが、目標はギャップを最小限に抑えることでした。 課題: ScyllaDB 選択した NoSQL データベース: インパクト： エンジニアリングリソースへの負担の軽減 75% の容積増加 オンデマンドのリソース プロビジョニングによりスケーラビリティが促進されます。 モロコ語 Moloco は、広告主がモバイル オーディエンスの獲得、エンゲージメント、小売を支援するモバイル オーディエンス プラットフォームです。このプラットフォームは、キャンペーンの最適化と予測分析のために機械学習モデルに大きく依存しています。 厳格な遅延制限 (100 ミリ秒未満) で 1 秒あたり数百万の入札クエストを処理するというプレッシャー。 課題: Google Cloud BigTable 選択された NoSQL データベース: インパクト： 処理されるリクエストの数を 1 秒あたり 50 万から 500 万にスケールしました 低遅延 管理されたインフラストラクチャにより、同社はソフトウェア エンジニアリング リソースを再割り当てして他のタスクに集中できるようになりました。 AdTech プラットフォーム開発における長年の経験から、AdTech データ ストレージ インフラストラクチャに適したデータベースを選択するための型にはまったアプローチは存在しないことがわかりました。データベースにはさまざまな種類のものがあります。適切なものを見つけるには、経験、製品知識、徹底的な調査が必要です。 場合によっては、2 つの NoSQL データベースを切り替えると大きな違いが生じることがあります。上で紹介した GumGum は、ScyllaDB に切り替える前は Cassandra に依存していました。 MongoDB から Aerospike に移行した後、クライアント (モバイル DSP) のケースで運用コストが大幅に削減されたことがわかりました。 データストレージを最適化するその他の方法 データ圧縮および重複排除技術の導入は、必要なストレージ容量を削減し、コスト削減につながるもう 1 つの方法です。 データ サイズの縮小を意味し、送信の高速化とストレージ コストの削減につながります。データ チームは GZIP などの手法を使用できます。 圧縮は 、その名前が示すように、データの冗長なコピーを排除します。これは、ユーザー プロファイルや同様のデータセットが繰り返されることが一般的である AdTech において役立ちます。 重複排除 は 、アクセス頻度の低いデータ (古いキャンペーン指標) をパフォーマンスに影響を与えることなく保存できる、コスト効率の高い方法です。 コールド ストレージは インフラベンダーが提供するプレミアムサービスを選択する クラウド サービスを利用するには、賢明な選択が必要です。注意しないと、インフラストラクチャのコストが追加されるサービス バンドルを簡単に使用してしまいますが、プラットフォームには何の価値もありません。 以下のクリップでは、Xenoss CTO の Vova Kyrychenko 氏が、AdTech プラットフォームが拡大するにつれて「フリーマネートラップ」がどのようにしてインフラストラクチャコストの高騰を招く可能性があるかを説明しています。 https://www.youtube.com/watch?v=q_57WdKDJI0 AdTech ベンダーに対する私たちの重要な推奨事項は、プレミアム サービスの価格設定を分析して、隠れたコストや節約を見つけることです。」 また、新しいツールはプラットフォームの速度を低下させる可能性があるため、新しいサービスを運用環境に導入する前に小規模でツールをテストするのが合理的です。 サードパーティまたはオープンソースのプロジェクトに常に注目することは、高価なマネージド製品に代わるもう 1 つの選択肢です。無料または低コストのプラットフォームは、主流のクラウド ベンダーよりも優れたパフォーマンスを提供できます。 Xenoss のエンジニアは、クライアントのプロジェクトにこのアプローチを採用することで、インフラストラクチャのコストを 20 分の 1 に削減することに貢献しました。 以下のインフォグラフィックでは、クライアントの古いインフラストラクチャと、当社のアーキテクトが設計した最新バージョンを示しています。 トラフィックと負荷のバランスをとる 少し前に述べたように、アドテック プラットフォームは安定した負荷の下では動作しません。ある瞬間、プラットフォームは突然のスパイクに見舞われ、次の瞬間には、どうすればよいかわからないほど多くのコンピューティング リソースを抱えている可能性があります。 Xenoss のエンジニアは、効率的なトラフィックと負荷分散が AdTech システムには必須であると信じているため、これらの概念をさらに詳しく見てみましょう。 負荷分散とは、受信リクエストを複数のサーバーに均等に分散し、単一のサーバーが過負荷にならないようにすることを意味します。このフレームワーク内で、Xenoss アーキテクトはミッションクリティカルなプロセス、つまり中断されるとシステムの中核機能 (リアルタイムの広告入札やユーザー データ処理) に支障をきたす重要なタスクを優先します。 これらのプロセスに優先順位を与えることで、潜在的な速度低下や障害から重要な操作を保護します。 脅威を早期に検出するメカニズムの設計 有名な格言に「失敗はあらゆる計画の一部だ」というものがありますが、これは AdTech 製品チームに脅威やダウンタイムに備えるよう簡潔に警告しています。 そのために、ベンダーや社内の技術チームに対し、システムの健全性を監視し、中断のない運用を確保する監視ツールを活用することを推奨します。異常に対するアラートを設定すると、チームは即座にアラートを受け取り、迅速に行動し、軽微な後退が大きなメルトダウンに発展しないようにすることができます。 AI を活用した洞察でこのアプローチを強化することで、さらに詳細な情報が提供されます。 Isolation Forest や One-Class SVM などの異常検出アルゴリズムは、脅威やシステムの脆弱性を示す可能性のある異常なデータ パターンの特定に適しています。 時系列データを分析するために長期短期記憶リカレント ニューラル ネットワークを展開することを再度お勧めします。 大規模言語モデルは、ログとシステム メッセージを分析して異常を検出し、見落とされる可能性のあるテキスト データを理解することで、脅威の検出にも貢献できます。 結論 インフラコストの最適化は、効率性と収益性を目指すあらゆる分野の企業にとっての要です。 AdTech は、ミリ秒単位で数千のクエリに対処する必要があるため、インフラストラクチャ開発の限界がエッジまで押し上げられるため、大量のデータ量とトラフィック負荷を処理する際の課題と回避策を探るのに最適な場です。 良いニュースとしては、経験豊富な技術チームが試行錯誤を繰り返しながら、たとえ高負荷のシステムであってもインフラストラクチャのコストを低く抑えるためのハンドブックを開発したことです。クラウド ソリューションとオンプレミス ソリューションのバランスをとり、脅威検出に AI を活用し、データ ストレージ戦略を継続的に改良することで、製品チームは予算を犠牲にすることなく堅牢な運用を確保できます。 この分野で機敏性を保ち、情報を得ることがコスト削減策であり、ダイナミックな AdTech 環境における競争上の優位性となります。