Carbon Black Cloud データ フォワーダは、大量の可変ストリーミング データを動的に処理するための、水平方向に拡張可能な分散サービスです。
データ フォワーダは、パフォーマンスとコスト管理の両方をアーキテクチャの主要な目標として構築されています。これらの目標は、商業環境における大規模分散データ処理エンジンに共通です。
大規模なストリーミング データを妥当なコストで処理するための主な課題の 1 つは、根本的なトレードオフがあることです。
- データが失われないようにする
- すべてのデータが確実に処理されるようにする
- すべてのデータが適切な時間内に処理されるようにする
- レコードの重複を最小限に抑える
マルチテナント データ処理では通常、水平スケール（パラレル データ処理ノードとも呼ばれる）を使用する必要があります。データ処理システム内の 2 つ以上のノードが同じキューから読み取りを行っている場合、そのキュー内の 1 つ以上のレコードを処理する責任者を調整するロジックが必要です。
さらに、大量のデータを処理する場合は、一度に 1 つのレコードを割り当てて処理するよりも、データ レコードをバッチで割り当てる方が一般に効率的でコスト効率が高くなります。担当者は、バッチの作業が完了した後にチェックポイントをコミットし、そのバッチ内のレコードが正常に処理されたことをシステム全体に示します。
障害モードの処理
すべてのコンピューティングで障害が発生した場合、その障害から回復するための対策が講じられます。特に関連する障害モードの 1 つは、「1 つのノードがバッチデータを割り当てて処理しているが、そのバッチのチェックポイントをまだコミットしておらず、終了してチェックポイントを設定する前に停止した場合にどうなるか?」です
積極的に確認するためのチェックポイントがないと、完了の正確な状態を知ることができないため、このようなシステムでは、そのバッチのデータの少なくとも一部が処理されていないと想定する必要があります。つまり、処理するためにバッチ全体を別のノードに割り当てる以外に選択の余地はありません。
Carbon Black Cloud データ フォワーダの場合、これは、バッチ内の一部のイベントまたはアラートが、システムがそのレコードのバッチを別のノードに再割り当てする前に正常に転送された可能性があることを意味します。この場合、転送済みのイベントは、以前に転送されなかったイベントと一緒に再度送信されます。
まれに、これが複数回発生することがあります。このような場合、複数のデータ処理ノードが特定のバッチイベントの転送タスクの完了とチェックポイントに失敗し、データが複数回再処理される可能性があります。
通常、Carbon Black Cloud データ フォワーダでは、すべてのイベントの 1% 以下、すべてのアラートの 0.1% 以下しか重複しません。この頻度は、お客様、時間帯、および個々のお客様のエンドポイントのアクティビティ レベルによって変動（増加または減少）する可能性があります。
