Apache Spark によるストリーム処理

第26章 パフォーマンス・チューニング パフォーマンス・チューニング

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

分散ストリーミング・アプリケーションのパフォーマンス特性（ ）は、その運用に関わる内部および外部要因の複雑な関係によって決定されることが多い。

外部要因とは、クラスタを構成するホストやそれらを接続するネットワークなど、アプリケーションが実行される環境に縛られるものである。 各ホストは、CPU、メモリ、ストレージなどのリソースを特定の性能特性で提供する。 例えば、一般的に低速だが低コストのストレージを提供する磁気ディスクや、ストレージユニットあたりのコストは高いが非常に高速なアクセスを提供する高速ソリッドステートドライブ（SSD）アレイがあるかもしれない。 あるいは、ネットワークの容量と利用可能なインターネット接続に制約されるクラウドストレージを使用しているかもしれない。 同様に、データプロデューサはストリーミングアプリケーションの制御外にあることが多い。

内部要因では、実装されたアルゴリズムの複雑さ、アプリケーションに代入されたリソース、アプリケーションがどのように振る舞うべきかを規定する特定のコンフィギュレーションを考慮する。

この章では、まずSpark Streamingのパフォーマンス要因について理解を深める。 そして、既存のジョブのパフォーマンスを調整するために適用できるいくつかの戦略について調査する。

Sparkストリーミングのパフォーマンスバランス

パフォーマンス Spark Streamingのチューニングは時に複雑になりがちだが、それは常にバッチ間隔とバッチ処理時間の間の単純な均衡から始まる。 バッチ処理時間は、受信した全てのデータの処理とその他関連する簿記を完了するために必要な時間コストとみなすことができ、バッチ間隔は割り当てられた予算である。 金融のアナロジーと同じように、健全なアプリケーションは、割り当てられた予算内に処理コストを収める。 プレッシャーが高まる特定の瞬間には、予算を超えてしまうかもしれないが、長期的にはバランスが保たれていることを確認しなければならない。 長期間に渡ってこの時間-予算バランスを超えるアプリケーションは、システム障害を引き起こし、通常はリソースの枯渇によるアプリケーションのクラッシュをもたらす。

バッチ間隔と処理遅延の関係

一般化ストリーミングアプリケーションの強い制約は、データの取り込みが止まらないことである。 Spark Streamingでは、データの取り込みは一定間隔で行われ、それを任意にオフにする機能はない。 したがって、新しいバッチ間隔が始まり、新しいデータがシステムに挿入されるまでにジョブキューが空でない場合、Spark Streamingは、キューに入ったばかりの新しいデータに取り掛かる前に、前のジョブの処理を終了する必要がある。

一度に1つのジョブしか実行しない場合、次のようになる：

• バッチ処理時間がバッチ間隔より一時的に大きいだけで、一般化ではSparkがバッチ間隔より短い時間でバッチを処理できる場合、Spark Streamingは最終的に追いついてジョブ（RDD）キューを空にする。

• 一方、遅延がシステム的で、クラスタが平均してマイクロバッチの処理にバッチ間隔以上かかる場合、Spark Streamingは、平均して、バッチ間隔ごとにストレージ管理から削除できる以上のデータを受け入れ続けることになる。最終的にクラスタはリソースを使い果たしてクラッシュする。 ...