フローサービスの実行モデル

サービスでは、「ASFramework」という共通のスレッド実行モデルが使用されます。ASFrameworkにおいては、複数のスレッドがプールされており、FIFO(先入れ先出し)型のキューを用いることで同時に発生するリクエストの多重処理を実現しています。

ASFrameworkでは、以下のスレッドが存在します。

Main ASFramework自身のスレッドで、キューサイズの変化に応じてWorkerスレッドのプール数を増減したり、Workerスレッドの処理時間などを一定の間隔で監視します。
Control ASTERIA Warp Monitorからの稼動確認要求や停止要求に対する応答を返すためのスレッドです。
Accepter リクエストの到着を待ち、受信したリクエストをキューに入れるためのスレッドです。
Worker キューからリクエストを取り出し、処理を実行するためのスレッドです。

実行モデルの図

実行モデルの図

またASFrameworkは、ひとつの物理的なプロセス内部に複数のプロセスコアを持つことができます。

複数の実行モデルの図

複数の実行モデルの図

FlowServiceのアーキテクチャ

FlowServiceは、HTTP / HTTPSの各プロトコルによるリクエストを受け入れるリスナーと、フロー処理の核となるフローエンジンなどの複数のASFrameworkプロセスコアから構成されています。

FlowSeriveの概念図

FlowSeriveの概念図

「サーバー」で実行される各サービスは特定のTCPポート番号を占有しており、このポート番号に対する外部からのアクセスを監視するリスナーを持ちます。すべてのプロセスはASTERIA Warp Monitorからの稼動監視シグナルを受け付ける制御用リスナーを持ち、いくつかのサービスは自身のサービス提供に必要なHTTPなどによるアクセスを受け付ける固有のリスナーを持っています。「サーバー」の各種リスナーが利用するポート番号に関しては、フローサービス運用ガイドの「リスナー一覧」を参照してください。

フローエンジンでは、各リスナーから送られてくるフロー開始リクエストをAccepterが受理し、即座にQueueに登録します。そこから、プールされているWorkerのうち空き状態になっているものがQueueの先頭エントリを取り出して処理を開始します。Workerはリクエストされたフロー(サブフローやExceptionを含むメインフロー全体)の開始から終了までの処理を一貫して行い、処理が終わると空き状態に戻ります。

Workerは、開始コンポーネントから終了コンポーネントに至るまで、フロー変数やストリームなどのデータを保持しつつ、フロー内にある各コンポーネントを順番に呼び出していきます。

上図ではフローエンジンが1つだけ存在するように描かれていますが、実際にはフローエンジンは次の3つの実行エンジンを持っています。

これらの実行エンジンは、フロー開始リクエストがAccepterへ入ってくる経路が違うだけで、それぞれの処理内容はほとんど同じものです。次項で優先実行とパラレルサブフローについて説明します。

優先実行とパラレルサブフロー

トリガー(実行設定)などでフローの実行モードを「優先」に設定すると、優先モードのリクエストを処理するための実行エンジンにリクエストが振り分けられます。また、ParallelSubFlowコンポーネントを使用すると、ループ処理でParallelSubFlowコンポーネントに処理が到達した段階で、並列処理を行うための実行エンジンにサブフローの処理が振り分けられます。

フローエンジンの実行エンジンの図

フローエンジンの概念図

上図のように優先実行は通常実行の実行エンジンとは別の実行エンジンとなっていますので、通常実行の実行エンジンに負荷がかかってフロー開始リクエストがQueueに溜まってしまっているような状態でも、優先モードのリクエストはそれとは別に実行することができます。つまり、優先実行は必ず実行したい定時バッチ処理や緊急回避的なフローを実行するために使用するのに向いています。ただし、あくまでもフローが優先実行の実行エンジンで行われるということだけですので、CPUを優先的に振り分けるということではない、つまり、優先実行のフローが他のフローよりも優先的に実行されるということではないことに注意してください。

ParallelSubFlowコンポーネントを使用すると、サブフローの処理が並列実行用の実行エンジンに振り分けられます。これにより、マルチCPU、マルチコアのサーバーではサブフロー実行の並列度が高まり、処理の高速化が期待できます。

メモ

どちらの場合でもWorkerの数には上限がありますので、フローの実行数はその上限を超えないようにしてください。上限を超えると優先実行・並列実行の効果が薄くなります。Workerの上限数は管理コンソールの「設定」-「サービス」-「フロー」の「フローエンジン」画面で変更することができます。

ポーリングサービス

メール監視トリガーとメッセージキュー監視トリガーによるフローの実行では、実行設定で指定したフローを実行する以外に、メールやメッセージを受信するといった前処理や、フローの実行終了後にメールやメッセージを削除するといった後処理が必要になります。これらの前処理や後処理を実行したり、指定されたフローをフローエンジンに実行するように要求するサービスがポーリングサービスです。

メール監視トリガーの場合は、ポーリングサービス内で新しく仮想的な親フローが作成されます。メール監視実行設定で指定した本文処理フローや添付ファイル処理フローは、作成された親フローからサブフローとして呼び出されます。

リスナーを介した場合のスレッドチューニングについて

FlowServiceにおけるHTTPなどのリスナーもそれぞれがASFramework実装となっているため、各リスナーもAccepterやWorkerといったスレッドおよびQueueを持ちます。さらに、リスナーのWorkerはFlowEngineからのレスポンス(すなわちフローの終了)を待つため、アクティブだがアイドリング(レスポンスを待っているだけの状態)しているスレッドがいるという状態になります。従って、例えばHTTP経由でフローを呼び出す場合、リクエストの多重度が1増えるごとに、少なくともHTTPリスナーのWorkerスレッドとFlowEngineのWorkerスレッドを1つずつ増やすというのが基本的なチューニングの考え方になります。

さらに、一般にHTTPリスナーはアクティブな場合でもアイドリング(CPU消費が少ない)している時間が相対的に長いため、通常時のプール数とMAX時のプール数の差を縮めておくことが有効です。逆に、FlowEngineはアクティブな期間はCPU稼働率が高いことが多いため、通常時のプール数を増やしすぎず、MAX時のプール数のみHTTPリスナーと合わせておくことがメモリの節約およびアクティブでないスレッドによるCPU消費の節約(他のサービスへの割り当て向上)につながります。

 

▲ このページのトップへ