サーバーレスのパフォーマンスと信頼性のための分散システムの再考

Apache Spark のための真のサーバーレスコンピューティングの構築には、Spark の誕生以来存在する根本的なアーキテクチャ上の課題を解決する必要がありました。その複雑さは、単にウォームプールを用意したり、基本的な自動スケーリングを実装したりするだけでは済みません。分散コンピューティングシステムがどのように動作すべきかについてのコアな前提を再考する必要がありました。

従来の Spark デプロイメントでは、ユーザーにインフラストラクチャが直接公開され、アプリケーションとコンピューティングが密接に結合されていました。ワークロードは共有リソースを奪い合い、小さな非効率性が連鎖的な障害につながる可能性があり、ユーザーはパフォーマンス、コスト、信頼性のバランスを手動で取ることを余儀なくされていました。需要が変化すると、システムは高い利用率と予測可能なパフォーマンスの両方を維持するのに苦労します。

サーバーレスコンピューティングは、インフラストラクチャを完全に管理することで、ユーザーがデータとインサイトに集中できるようにする、異なるアプローチを採用しています。安定性は、ユーザーの責任ではなく、システムのプロパティになります。これは、ワークロードを分離し、インテリジェントに配置し、リソースを動的に適応させるアーキテクチャによって実現されます。

サーバーレスコンピューティングは、安定性、パフォーマンス、および運用の簡素化を向上させるように設計されています。これを可能にする 3 つのコアシステムがあります。

1. Spark Connect。ユーザーアプリケーションとコンピューティングインフラストラクチャを分離します。
2. コンピューティングリソース全体でワークロードをインテリジェントにルーティングするServerless Gateway。
3. パフォーマンスとコストのためにクラスターサイズを継続的に最適化するadaptive autoscaler。

これらのシステムは一体となって、システム全体の安定性を確保することによってパフォーマンスを実現するモデルを可能にします。

Spark Connect: 分離による安定性

Spark Connect は、Spark の歴史における最も重要なアーキテクチャ変革であり、10 年以上にわたって分散コンピューティングを定義してきたモノリシックな設計からの完全な脱却です。従来のアーキテクチャでは、ユーザーアプリケーションは Spark ドライバーと同じマシン上で直接実行され、重大な制限をもたらす密結合が導入されていました。複数のアプリケーションが同じクラスターのリソースを奪い合ったり、ユーザーコードが過剰なメモリや CPU を消費したりすると、システムは不安定になり、ワークロード全体に連鎖する障害につながる可能性があります。

Spark Connect は、クライアントサーバーアーキテクチャを導入しており、アプリケーションは gRPC を介して Spark ドライバーと通信し、ドライバーはユーザープロセスを直接実行するのではなく、クライアントに代わってクエリを実行します。これにより、実行単位がアプリケーションプロセスからクエリに移行し、ユーザーアプリケーションとインフラストラクチャのクリーンな分離が可能になります。

この疎結合により、信頼性が大幅に向上し、プラットフォームはユーザーワークロードとは独立してドライバーを管理できるようになります。Spark Connect は、アプリケーションをコンピューティングから分離することで、安定したマルチテナント実行に必要な基盤を構築し、システム全体でのより高度なリソース管理を可能にします。

このアーキテクチャにより、Databricks は、99.998% の成功率で、45 億以上のワークロードにわたって、年間 25 以上のメジャーな Spark ランタイムアップグレードを提供できます。ユーザーによる操作は不要です¹。

Gateway: 効率性と予測可能性のバランス

分散システムは、長い間、効率性と予測可能性の根本的な緊張関係に直面してきました。利用率を最大化すると、リソースの競合につながることが多く、ワークロードを分離すると、利用率の低い容量につながる可能性があります。従来のクラスターモデルでは、ユーザーは手動でこのトレードオフをナビゲートすることを余儀なくされ、ワークロードが変化すると、予測不可能なパフォーマンスや信頼性の低い実行につながることがよくあります。

数十のクエリが同時に着信した場合に何が起こるかを考えてみてください。一部はサンプルデータに対する小さな探索的スキャン、その他は数百ギガバイトを処理する大規模な本番 ETL ジョブです。単純なルーターはそれらを同じように扱い、大規模なジョブを小さなジョブの後ろで待機させたり、ワークロードが同じクラスターのリソースを奪い合ったりして、予測不可能なパフォーマンス低下につながります。このダイナミクスにより、共有環境で高い利用率と一貫したパフォーマンスの両方を提供することが困難になります。

Databricks Gateway は、3 つのリアルタイムシグナルを評価して各ワークロードをルーティングします。推定クエリサイズ（論理プランから導出）、クラスタープールの現在の利用率、およびレイテンシプロファイル（セッションがインタラクティブでレイテンシに敏感か、スループットに最適化されたバッチジョブか）。小さな探索的クエリは、応答に数秒かかる負荷の軽いクラスターにルーティングされます。重い ETL ジョブは、データ量に対応できる利用可能なヘッドルームがあるクラスターにルーティングされるか、プロビジョニングするように自動スケーラーにシグナルが送られます。条件が変化した場合（クラスターがいっぱいになる、長時間実行されるジョブが完了する、新しいクラスターがオンラインになる）、Gateway は配置を継続的に再評価し、ユーザーの介入なしにルーティングを修正します。結果として、ワークロードは互いに分離されます。あるクラスターでの暴走クエリは、別のクラスターでのクエリを遅延させず、システムは予測可能性を犠牲にすることなく高い利用率を維持します。

自動スケーリング: コストパフォーマンス曲線の最適化

動的なクラスターサイジングは、分散システムにおける価格パフォーマンスを最適化するための主要なメカニズムですが、最適なコンピューティング量を決定することは本質的に複雑です。最適な構成は、ワークロードの特性、データサイズ、およびレイテンシとコストの相対的な重要性に依存し、単一の構成がすべてのシナリオに適合するわけではありません。Databricks サーバーレスは、さまざまなニーズに合わせて2 つのモードを提供します。コストを削減するためにコンピューティングリソースを少なく使用するStandardモードと、時間的制約のあるワークロードに対してより高速な起動と実行を提供するPerformance-Optimizedモードです。

起動は私たちにとって優先事項であり、サーバーレスノートブックとワークフローは大きな違いをもたらしました。ノートブックのサーバーレスコンピューティングは、ワンクリックで簡単に利用できます。 — Chiranjeevi Katta, Data Engineer at Airbus

Databricks は、冗長なワークフローを排除しながら、サーバーレスコンピューティングへの移行を支援してくれました。これらの効率化により、運用コストを 25% 削減することができました。従来のインフラストラクチャでのパイプラインは、処理に数時間かかっていました。現在では、2〜5 倍高速に実行されます。 — Evan Cherney, Senior Data Science Manager at Unilever

従来の自動スケーリングアプローチは、静的なルールとリアクティブなしきい値に依存していますが、これらのニュアンスを捉えきれないことがよくあります。その結果、クラスターは頻繁に過小または過剰にプロビジョニングされ、非効率性、不安定性、またはその両方につながります。

サーバーレス自動スケーリングは、より適応的なアプローチを採用しています。ワークロードパターンとシステム全体のシグナルを継続的に分析することで、自動スケーラーは各ワークロードを最適なコストパフォーマンス曲線上に配置します。手動で構成されたほとんどのクラスターは、分散システムのサイジングの難しさにより、パフォーマンスが悪くコストが高くなるため、ここで不足しています。必要に応じてコンピューティング容量を水平および垂直にスケーリングすることで動的に調整し、メモリ不足の障害を防ぎ、ワークロードが増加しても安定性を維持します。タスクがメモリ不足のエラーに遭遇した場合、自動スケーラーはそれを自動的に検出し、より大きな VM でタスクを再起動し、手動の介入やジョブの失敗なしにジョブを続行します。

その影響は測定可能です。CKDelta は、以前は 4〜5 時間実行されていたジョブが20 分で完了したと報告しました。Unilever は、パイプラインが 2〜5 倍高速に実行され、運用コストが 25% 削減されたことを確認しました。HP は、クラウド費用を 32% 以上削減し、結合されたジョブ実行時間を 36% 短縮しました。

Spark Connect、Gateway、および自動スケーラーは一体となって、Spark の根本的に異なる運用モデルを可能にします。ワークロードは分離され、インテリジェントに配置され、ユーザーの介入なしに動的にリソースが割り当てられます。アーキテクチャレベルで安定性に対処することにより、サーバーレスコンピューティングは信頼性を維持しながら強力なパフォーマンスを提供し、ユーザーはインフラストラクチャの管理ではなく、データと AI ワークロードの構築に集中できるようになります。

¹ Justin Breese et al., "Blink Twice: Automatic Workload Pinning and Regression Detection for Versionless Apache Spark using Retries," SIGMOD/PODS '25, pp. 103–106. https://doi.org/10.1145/3722212.3725084

今すぐサーバーレスジャーニーを始めましょう

• サインアップ to a Serverless Databricks account
• Serverless Compute for Notebooks, Lakeflow Jobs, and Spark Declarative Pipelines
• Practitioner’s Guide to Serverless Compute

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事