4
ASTERIAアーキテクチャ
|
この章では、ASTERIAの動作をより詳しく理解するために、システム構成、データモデル、プロセスモデル、イベントモデルなどについて解説します。
|
4.1 システム構成
|
ASTERIAは、インストーラによって自前のJavaランタイムをインストールディレクトリ配下に置き、それを使って動作するようになっています。このためインストーラのサイズが大きくなっていますが、その代わり安定した動作が期待できます。ASTERIAサーバを構成するサービスはすべてこのJavaランタイムのインスタンス（OSレベルのプロセス）です。
|
4.1.1 フローサービスの物理モデル
|
ASTERIAサーバの実体は1.3.4節で述べたように複数のJavaの常駐プロセスから構成されていますが、中でもフローサービスがその中核となります。フローサービスは、HTTP / HTTPS / AJPの各プロトコルによるリクエストを受け入れるリスナーと、フロー処理の核となるフローエンジンといった複数のコアから構成されている物理プロセスです。
フローエンジンでは、各リスナーから送られてくるフロー開始リクエストをAccepterスレッドが受理し、即座にQueueに登録します。そこから、プールされているWorkerスレッドのうち、空き状態になっているものがQueueの先頭エントリを取り出して処理を開始します。Workerスレッドはリクエストされたフロー（サブフローやを含むメインフロー全体）の開始から終了までの処理を一貫して行い、処理が終わると（必要に応じて）レスポンスをリスナーに返して空き状態に戻ります。 Workerスレッドは、開始コンポーネントから終了コンポーネントに至るまで、フロー変数やストリームなどのデータを保持しつつ、フロー内にある各コンポーネントを順番に呼び出していきます。 この際に、外部のデータベースなどに接続するコネクションをプールして使い回すことで、頻繁にアクセスするデータに対する性能向上を行っています。 ASTERIAで開発されたフローはこうした一貫性のあるフレームワーク上で動作するため、特に何も意識しなくても基本的にはマルチスレッドで動作し、同じ内容の処理をJavaプログラムで書いた場合と比べても1.5〜2倍程度のオーバーヘッドで軽快に動作します。（慣れないプログラマーが既存の言語で書くより高速かつ安全であることもよくあります。） また、フローサービスの各構成要素についての設定はASMCから変更が行えるため、柔軟なチューニングが可能となっています。ちなみに、標準状態ではフローエンジンのWorkerスレッドの最大数は32ですので、計32個のフローを同時並行的に走らせることができ、それを超えた部分についてはキューに積まれていきます。 ここに記載されている以上の内容については、ASTERIA Users Guideの付録「ASTERIAアーキテクチャ詳細」をご覧ください。
|
4.1.2 主なリスナーのポート番号
|
ASTERIAサーバで使用されるリスナーのうち、代表的なポート番号のデフォルトは以下の通りです。
|