デプロイとメンテナンス / アーキテクチャ、スケーリング、リソース制限

本記事では、DataFlux Func の全体アーキテクチャと、処理能力を向上させるためのスケーリング方法について説明します。

1. アーキテクチャ

システム内部は、典型的な「プロデューサー -> コンシューマー」モデルです。Python 関数の実行はすべて、「タスク生成 -> エンキュー -> デキュー -> 実行 -> 結果返却」というフローを経ます。

すべての Python 関数は、実際にはまず「タスク」にラップされ、所属する「ワークキュー」（番号は #0 から始まる）に入ります。その後、対応する「ワーカー」（番号は worker-0 から始まる）がキューから取り出して実行します。

flowchart TB
    USER[ユーザー]
    FUNC_SERVER[Func Server サービス]
    REDIS_QUEUE_N[Redis キュー #N]
    FUNC_WORKER_N[Func Worker-N サービス]
    FUNC_BEAT[Func Beat サービス]

    USER --HTTP リクエスト--> FUNC_SERVER

    FUNC_SERVER --関数実行タスクをエンキュー--> REDIS_QUEUE_N

    REDIS_QUEUE_N --関数実行タスクをデキュー--> FUNC_WORKER_N

    FUNC_BEAT --"関数実行タスクをエンキュー
    （定期実行タスク）"--> REDIS_QUEUE_N

1.1 サービスとその用途

DataFlux Func には複数のサービスが含まれており、各サービスにはそれぞれ異なる役割があります。具体的なサービスは次のとおりです。

サービス	用途
server	Web サービス。以下の機能を提供します： 1. Web UI 2. API インターフェース 3. サブスクライバーの保守
worker-{キュー番号}	ワーカーは、ユーザースクリプトの実行に使用され、以下を含みます： 1. 関数 API 2. 関数 API 3. 定期実行タスクまた、システムレベルのバックグラウンドタスクも一部処理します詳細はキューの説明を参照してください
beat	定期実行タスクのトリガー
mysql	データベース
redis	キャッシュ / 関数実行タスクキュー

1.2 ワーカーとキューのリッスン関係

サービス worker-{キュー番号}（ワーカー）について、各 Worker サービスは、特定のいくつかのキューのみをリッスンします：

キューとワーカーは必ずしも 1 対 1 に対応する必要はありません

キューとワーカーは必ずしも 1 対 1 に対応する必要はありません。たとえば、ワーカー worker-0 はキュー #0 のタスクだけをリッスンするわけではなく、各ワーカーは任意の 1 つまたは複数のキューをリッスンできます。

また、同じキューを複数のワーカーが同時にリッスンすることもできますし、リッスンしないこともできます（推奨されません）。

独立デプロイ Func とデータプラットフォーム付属 Func ではキューが異なります

独立デプロイ Func は、その大部分が比較的軽度な使用であるため、不要なリソース消費を減らすために、独立デプロイ Func のワーカー数はキュー数よりも少なくなっています。

一方、データプラットフォーム付属 Func はモニター、メッセージ送信モジュール（Message Desk）などの高負荷な業務を担うため、ワーカーとキューが 1 対 1 に対応し、独立デプロイ Func よりも多くの番号のワーカーとキューが存在します。

6.0.4 以降のバージョン3.2.0（1.77.145）以降のバージョン3.1.0（1.79.155）以前のバージョン

ワーカー	キュー独立デプロイ	キューデータプラットフォーム付属
worker-0	#0, #4, #7, #8, #9	#0
worker-1	#1	#1
worker-2	#2	#2
worker-3	#3	#3
worker-4	-	#4
worker-5	#5	#5
worker-6	#6	#6
worker-7	-	#7
worker-8	-	#8
worker-9	-	#9
worker-10	-	#10
worker-11	-	#11
worker-12	-	#12
worker-13	-	#13
worker-14	-	#14
worker-15	-	#15

ワーカー	キュー独立デプロイ	キューデータプラットフォーム付属
worker-0	#0, #4, #7, #8, #9	#0
worker-1	#1	#1
worker-2	#2	#2
worker-3	#3	#3
worker-4	-	#4
worker-5	#5	#5
worker-6	#6	#6
worker-7	-	#7
worker-8	-	#8
worker-9	-	#9

ワーカー	キュー
worker-0	#0
worker-1-6	#1, #2, #3, #4, #5, #6
worker-7	#7
worker-8-9	#8, #9

2. サービス / キューとその役割・スケーリングの推奨事項

スケーリングには、より多くのハードウェア投資が必要です

スケーリングには、対象サーバーにより高いパフォーマンスが求められます。これには、サーバー自体、データベースサービス、Redis などが含まれますが、これらに限定されません。

一般に、DataFlux Func のスケーリングは、対応するサービスのレプリカ数を増やすだけで済みます。そのため、ユーザーはまず自分の実際の業務状況を把握し、的を絞ってスケーリングを行う必要があります。

サービス、キューとその役割、およびスケーリングの推奨事項は以下のとおりです。

6.0.4 以降のバージョン3.2.0（1.77.145）以降のバージョン3.1.0（1.79.155）以前のバージョン

サービス / キュー	役割独立デプロイ	役割データプラットフォーム付属	デフォルトの Pod 数データプラットフォーム付属	スケーリングの推奨事項
server	Web サービス。以下の機能を提供します。 1. Web インターフェース 2. API インターフェース 3. サブスクライバーの保守	← 左と同じ	1	通常はスケーリング不要
server-inner	（このサービスなし）	クラスター内で API を呼び出すための Web サービス	1	通常はスケーリング不要
worker-0 キュー #0	システムワーカーであり、ユーザーコードの処理には直接関与しません	← 左と同じ	2	通常はスケーリング不要
worker-1 キュー #1	同期実行される関数 API からの関数タスクを実行します	← 左と同じ	1	同期実行される関数 API の同時実行数を増やす必要がある場合はスケーリングできます
worker-2 キュー #2	定期実行タスクからの関数タスクを実行します	← 左と同じ	1	定期実行タスクの同時実行数を増やす必要がある場合はスケーリングできます
worker-3 キュー #3	非同期実行される関数 API からの関数タスクを実行します	← 左と同じ	1	非同期実行される関数 API の同時実行数を増やす必要がある場合はスケーリングできます
worker-4 キュー #4	（予約済み）	（予約済み）	0	スケーリング不要
worker-5 キュー #5	デバッグコードの実行つまり Web インターフェースで関数を直接実行します	← 左と同じ	1	より多くのユーザーが同時にスクリプトを開発できるようサポートする必要がある場合はスケーリングできます
worker-6 キュー #6	コネクターのサブスクリプションメッセージ処理からの関数タスクを実行します	← 左と同じ	1	コネクターのサブスクリプションメッセージ処理の同時実行数を増やす必要がある場合はスケーリングできます
worker-7 キュー #7	（予約済み）	データプラットフォームのシステム業務を実行する関数タスク例：データプラットフォームのバックエンド管理者としてのログイン、各種キャッシュの更新、メッセージ集約プールの解放など	2	モニターの総数が多い場合はスケーリングできます
worker-8 キュー #8	（予約済み）	データプラットフォームの閾値検出などの通常モニター、指標生成などに関する関数タスクを実行します	5	通常モニターの数が多い場合はスケーリングできます
worker-9 キュー #9	（予約済み）	データプラットフォームの高度な検出、スマートモニタリングを実行する関数タスク	3	通常の高度な検出・スマートモニターの数が多い場合はスケーリングできます
worker-10 キュー #10	（該当サービスなし）	データプラットフォームがユーザー報告イベントを受信する関数タスクを実行します	1	ユーザー報告イベントの量が多い場合はスケーリングできます
worker-11 キュー #11	（該当サービスなし）	Message Desk のメッセージ送信タスクを実行します	3	メッセージ送信量が多い場合はスケーリングできます
worker-12 キュー #12	（該当サービスなし）	（予約済み）	0	スケーリング不要
worker-13 キュー #13	（該当サービスなし）	（予約済み）	0	スケーリング不要
worker-14 キュー #14	（該当サービスなし）	ユーザー操作に即時応答する必要がある AI 関連処理を実行します例：「Pipeline の自動作成」の呼び出しなど	2	同時に Pipeline を作成するユーザーが多い場合はスケーリングできます
worker-15 キュー #15	（該当サービスなし）	ユーザー操作への即時応答が不要な AI 関連処理を実行します例：「アラート圧縮統合」の呼び出し処理など	2	AI でアラートを集約するモニターが多い場合はスケーリングできます
beat	定期実行タスクのトリガー	← 同左	1	スケーリング不可。グローバルで単一レプリカを保証
mysql	データベース	（該当サービスなし）	-	スケーリング不要。より高いニーズがある場合は、自前構築またはクラウドサービスを選択できます
redis	キャッシュ / 関数実行タスクキュー	（該当サービスなし）	-	スケーリング不要。より高いニーズがある場合は、自前構築またはクラウドサービスを選択できます

サービス / キュー	役割独立デプロイ	役割データプラットフォーム付属	スケーリングの推奨事項
server	Web サービス。以下の機能を提供します： 1. Web インターフェース 2. API インターフェース 3. サブスクライバーのメンテナンス	← 同左	通常はスケーリング不要
server-inner	（該当サービスなし）	Web サービス。クラスター内部での API 呼び出し専用	通常はスケーリング不要
worker-0 キュー #0	システム作業ユニット。ユーザーコードの処理には直接関与しません	← 同左	通常はスケーリング不要
worker-1 キュー #1	同期実行の関数 API からの関数タスクを実行します	← 同左	同期実行の関数 API の並行処理量を増やす必要がある場合にスケーリングできます
worker-2 キュー #2	定期実行タスクからの関数タスクを実行します	← 同左	定期実行タスクの並行処理量を増やす必要がある場合にスケーリングできます
worker-3 キュー #3	非同期実行の関数 API からの関数タスクを実行します	← 同左	非同期実行の関数 API の並行処理量を増やす必要がある場合にスケーリングできます
worker-4 キュー #4	（予約）	（予約）	スケーリング不要
worker-5 キュー #5	デバッグコードの実行つまり Web インターフェースで関数を直接実行	← 同左	より多くのユーザーが同時にスクリプトを開発できるようにする必要がある場合にスケーリング
worker-6 キュー #6	コネクターのサブスクリプションメッセージ処理からの関数タスクを実行します	← 同左	コネクターのサブスクリプションメッセージ処理の並行処理量を増やす必要がある場合にスケーリングできます
worker-7 キュー #7	（予約）	データプラットフォームのシステム業務・メッセージ送信の関数タスクを実行します例：データプラットフォームのバックエンドでの管理者ログイン、各種キャッシュの更新、メッセージ集約プールの解放、Message Desk メッセージ送信	メッセージ送信量が多い場合にスケーリングできます
worker-8 キュー #8	（予約）	データプラットフォームの閾値検出などの通常モニター関連の関数タスクを実行します	通常モニターの数が多い場合にスケーリングできます
worker-9 キュー #9	（予約）	データプラットフォームの高度な検出・スマートモニタリングの関数タスクを実行します	通常の高度な検出・スマートモニターの数が多い場合にスケーリングできます
beat	定期実行タスクのトリガー	← 同左	スケーリング不可。グローバルで単一レプリカを保証
mysql	データベース	（該当サービスなし）	スケーリング不要。より高いニーズがある場合は、自前で構築するかクラウドサービスを選択できます
redis	キャッシュ / 関数実行タスクキュー	（該当サービスなし）	スケーリング不要。より高いニーズがある場合は、自前で構築するかクラウドサービスを選択できます

サービス	役割	スケーリングの推奨事項
server	Web サービス。以下の機能を提供します： 1. Web インターフェース 2. API インターフェース 3. 保守サブスクライバー	通常はスケーリング不要
worker-0 キュー #0	システムワーカー。ユーザーコードの処理には直接関与しません	通常はスケーリング不要
worker-1-6 キュー #1、#2、#3、#4、#5、#6	デフォルトでは、関数の同期呼び出し処理を担当します。例： 1. 同期実行の関数 API 2. サブスクリプションメッセージ処理	同期実行の関数 API、サブスクリプションメッセージ処理の並行処理量を増やす必要がある場合にスケーリングできます
worker-7 キュー #7	デフォルトでは、デバッグコードの処理を担当します（つまり Web インターフェースで関数を直接実行）	より多くのユーザーが同時にスクリプトを開発できるようにする必要がある場合にスケーリング
worker-8-9 キュー #8、#9	デフォルトでは、関数の非同期呼び出し処理を担当します。例： 1. 非同期実行の関数 API 2. 定期実行タスク	定期実行タスク、非同期実行の関数 API の並行処理量を増やす必要がある場合にスケーリングできます
beat	定期実行タスクのトリガー	スケーリング不可。グローバルで単一レプリカを保証
mysql	データベース	スケーリング不要。より高いニーズがある場合は、自前で構築するかクラウドサービスを選択できます
redis	キャッシュ / 関数実行タスクキュー	スケーリング不要。より高いニーズがある場合は、自前で構築するかクラウドサービスを選択できます

例：定期実行タスクの処理能力を強化する必要がある場合...

上記のとおり、定期実行タスクは「キュー #8」にあり、「キュー #8」は「サービス worker-8」に対応するため、「サービス worker-8」をスケーリングすればよい

スケーリング量の見積もり

一般的な worker-8 を例にすると：

worker-8 はデータプラットフォーム付属版において、主にモニタータスクの実行を担当します。1回の検出タスクに T ミリ秒かかるとすると、1分間に 60 × 1,000 ÷ T 回の検出を実行できます。デフォルトでは、worker-8 の各 Pod は5プロセスを起動します。

つまり、単一の worker-8 Pod の検出能力は 5 × (60 × 1,000 ÷ T) 個のモニターです。

計算式

Text Only
A = 5 × (60 × 1,000 ÷ T)
  = 300,000 ÷ T

A：検出能力

T：検出タスクの実行時間（ミリ秒）

モニターの1回の実行時間ごとに、以下の表のようになります。

1回の検出時間	単一 Pod の検出能力	基準との比較
300	1,000	167%
500	600	基準
800	375	63%
1,000	300	50%
2,000	150	25%
3,000	100	17%

逆に、モニターの総数を M とすると、必要な Pod 数は M ÷ (5 × (60 × 1,000 ÷ T)) で求めることができます。

計算式

Text Only
P = M ÷ (300,000 ÷ T)
  = M × T ÷ 300,000

P：必要な Pod 数

M: モニター数

T：検出タスクの実行時間（ミリ秒）

モニターの数と1回の実行時間によって、以下の表のようになります。

1000 個のモニター5000 個のモニター10,000 個のモニター

モニター数	1回の検出時間	必要な Pod 数	基準との比較
1,000	300	1	50%
1,000	500	2	基準
1,000	800	3	150%
1,000	1,000	4	200%
1,000	2,000	7	350%
1,000	3,000	10	500%

モニター数	1回の検出時間	必要な Pod 数	基準との比較
5,000	300	5	56%
5,000	500	9	基準
5,000	800	14	156%
5,000	1,000	17	189%
5,000	2,000	34	378%
5,000	3,000	50	556%

モニター数	1回の検出時間	必要な Pod 数	基準との比較
10,000	300	10	59%
10,000	500	17	基準
10,000	800	27	159%
10,000	1,000	34	200%
10,000	2,000	67	394%
10,000	3,000	100	588%

操作方法

スタンドアロン展開の DataFlux Func は、設定（{インストールディレクトリ}/docker-stack.yaml）を変更し、対象サービスの deploy.replicas を増やすことでスケーリングを実現できます。

公式ドキュメントを参照してください

deploy.replicas オプションの詳細については、Docker 公式ドキュメントを参照してください：Docker Documentation / Compose file deploy reference / replicas

worker-8 の処理能力を向上させる場合を例に、具体的な変更箇所は以下のとおりです。

例は抜粋のみ

例は主要な変更箇所のみを示しています。実際の操作時には、設定を完全に行うように注意してください。

docker-stack.yaml の主要な変更箇所
services:
  worker-8:
    deploy:
      # キュー 8 を処理するワーカーを同時に 2 つ起動する
      replicas: 2

3. リソースの制限

リソース制限は実際の業務に応じて適切に調整する必要があります

実際の業務に応じて、リソース制限を適切に調整してください。

むやみにリソースを制限すると、タスクの実行時間が長くなったり、メモリ不足によりコードの実行が完了できなくなったりする可能性があります。

操作方法

スタンドアロン展開の DataFlux Func は、設定（{インストールディレクトリ}/docker-stack.yaml）を変更し、対象サービスの deploy.resources を設定することで、リソースを制限できます。

公式ドキュメントを参照してください

deploy.resources オプションの詳細については、Docker 公式ドキュメントを参照してください：Docker Documentation / Compose file deploy reference / resources

デフォルトでは、各 worker-N レプリカは最大 5 つの CPU コアを占有します（つまり、各ワーカーには 5 つのワーカープロセスがあります）。

worker-8 のリソース使用量を制限する場合を例に、具体的な変更箇所は以下のとおりです。

例は抜粋のみ

例は主要な変更箇所のみを示しています。実際の操作時には、設定を完全に行うように注意してください。

docker-stack.yaml の主要な変更箇所
services:
  worker-8:
    deploy:
      resources:
        limits:
          cpus  : '2.50' # CPU は最大 2.5 コアまでに制限
          memory: 4G     # メモリは最大 4 GB までに制限

4. ワーカーの分割

新しいバージョンではすべてのワーカーが分割されています

スタンドアロン展開の Func 3.2.0 以降では、デフォルトですべての予約されていないワーカーが分割されています。ユーザーは必要に応じて予約済みのキューを有効にできます。

データプラットフォーム付属版 Func 1.77.145 以降では、デフォルトですべてのワーカーが分割されており、ユーザーが自分で分割する必要はありません。

特殊な場合には、デフォルトで結合されているワーカー（例：worker-1-6）を分割することで、より細かい粒度のタスクスケジューリングを実現し、特定のキューを担当するワーカーのスケーリングとリソース制限を実現できます。

仮に業務要件により、DataFlux Func のサブスクリプション処理に対する性能要件が高く、サブスクリプションメッセージ処理が同期実行される関数 API 処理と干渉しないようにしたい場合は、worker-1-6 を worker-1-5 と worker-6 に分割できます。

操作方法

スタンドアロン展開の DataFlux Func は、設定（{インストールディレクトリ}/docker-stack.yaml）を変更し、対応するサービスを追加・変更して、command で指定されているキューの番号を変更することで、ワーカーの分割を実現できます。

ワーカーがリッスンするキューは、./run-worker-by-queue.sh の後ろの引数で指定します。サービス名自体は主にラベルとして使用されるため、混乱を避けるため、実際にリッスンするキューと一致させることをお勧めします。

例は抜粋のみ

例は主要な変更箇所のみを示しています。実際の操作時には、設定を完全に行うように注意してください。

docker-stack.yaml の主要な変更箇所
services:
  # 元の「worker-1-6」を削除し、以下の内容に変更する

  worker-1-5:
    # ワーカーが 1〜5 番のキューを処理するように指定する
    command: ./run-worker-by-queue.sh 1 2 3 4 5

  worker-6:
    # ワーカーが 6 番のキューを処理するように指定する
    command: ./run-worker-by-queue.sh 6