1.2　本製品の構成

ここでは，本製品でサポートしているアプリケーションの実行形式，および本製品が提供するコンポーネントについて説明します。

本製品でサポートしているアプリケーションの実行形式

本製品は，次の2つの実行形式をサポートします。

• 実行可能JAR/WAR形式

  Spring Bootで主に使用されている形式です。次を満たすアプリケーションの実行方法のことを指します。

  • ユーザアプリケーションとともに，必要なライブラリや組み込みサーブレットコンテナを1つのアーカイブファイルに格納した「実行可能JAR（Executable JAR）」または「実行可能WAR（Executable WAR）」をSpring Bootのビルドツールを用いて作成する

  • 作成した実行可能JAR/WARを-jar引数に渡してJavaVMを起動する

• WARデプロイ形式

  Spring Bootで旧来使用されてきた形式です。次を満たすアプリケーションの実行方法のことを指します。

  • ユーザアプリケーションとともに必要なライブラリを1つのWARファイルに格納した「デプロイ可能WAR（Deployable WAR）」をSpring Bootのビルドツールを用いて作成する

  • 作成したWARをTomcatなどのサーブレットコンテナにデプロイすることで，サーブレットコンテナ上でアプリケーションを実行する

  WARデプロイ形式のサポート対象を次に示します。

  • Spring Bootのビルドツールを用いて作成されたWAR

  • Java Servlet仕様を基に作成されたWebアプリケーションのWAR

    ただし，本製品の機能のうちSpring BootやSpring Frameworkの機能に依存している一部の機能は動作しません。

本製品が提供するコンポーネント

本製品では，アプリケーションが動作している監視対象プロセスのことをモニタ対象プロセスと呼びます。実行可能JAR/WAR形式の場合は，実行可能JAR/WARプロセス（実行可能JARまたは実行可能WARを起動させたJava VMプロセス）がモニタ対象プロセスとなります。WARデプロイ形式の場合は，デプロイ先のサーブレットコンテナのサーバプロセス（Tomcatサーバプロセス）がモニタ対象プロセスとなります。

このモニタ対象プロセスを監視するために，本製品は次の2つのコンポーネントを提供しています。

• プロセスモニタ

  プロセスモニタは，起動コマンドとモニタ対象プロセスの間に割り込み，モニタ対象プロセスの稼働状態監視や保守情報の収集を実行します。

• モニタ対象プロセス内のフィルタ

  モニタ対象プロセス内のフィルタは，TomcatのValveやSpring FrameworkのListenerなどの実装として提供されます。各フィルタは，モニタ対象プロセス内の各種処理やリクエスト処理の間に割り込み，トレース情報や稼働監視情報を出力します。

本製品は，これら2つのコンポーネントを図1-1，または図1-2のように連携することで，OSS単体では実現が困難な機能を提供します。これによって，OSSの保守性を向上できます。

図1‒1　本製品の機能構成全体図（実行可能JAR/WAR形式の場合）

図1‒2　本製品の機能構成全体図（WARデプロイ形式の場合）

本製品が提供する機能について説明します。各説明の番号は図中の番号と対応しています。

1. プロセスモニタ機能は，モニタ対象の起動処理を代行し，モニタ対象の起動と同時に稼働監視や運用管理用REST APIの受付を開始します。

   実行可能JAR/WAR形式の場合は，本製品が提供する起動スクリプトを使ってJava VMを起動することによって，実行可能JAR/WARを起動するタイミングでプロセスモニタを起動します。

   WARデプロイ方式の場合は，Tomcatが提供する設定変更の仕組みを利用して，Tomcatを起動するタイミングでプロセスモニタを起動します。プロセスモニタはTomcatの起動コマンドの延長で自動起動します。

   詳細は，「14.　プロセスモニタ機能」を参照してください。

2. トレース機能は，リクエスト処理の内部状態を把握できる独自のトレース情報を出力します。

   リクエストごとに一意のIDを採番し，リクエスト処理がどのような状態でどこまで到達していたかを把握できるトレース情報を常時出力します。uCosminexus Application Serverの「性能解析トレース機能」に相当する機能です。

   詳細は，「15.　トレース機能」を参照してください。

3. 稼働監視機能は，プロセス監視やヘルスチェックを代行し，異常検知時には指定したコマンド呼び出しや保守情報の収集を即座に実施します。

   クラウドのマネージドサービスやコンテナオーケストレーションツールが提供する既存のヘルスチェック機能に比べて，高度なプロセス監視・ヘルスチェックを提供します。異常発生からその検知と閉塞までのタイムラグ短縮に寄与します。

   詳細は，「16.　稼働監視機能」を参照してください。

   ヒント

   一般的なクラウドサービスも，オートスケーリング機能の自動スケールインを実現するために，ヘルスチェック機能を提供しています。ただし，それらの多くは，一定時間おきに投入するHTTPリクエストの応答によって正常/異常を判別しています。そのため，プロセスダウンのように，即座に業務が継続できなくなるような障害が発生しても，次のHTTPリクエストが投入されるまでの一定時間はプロセスダウンしているサーバを使い続けます。

   本製品の稼働監視機能では，異常発生からその検知と閉塞までのタイムラグが大幅に短縮できます。HTTPリクエストの応答だけでなく，プロセスダウンの即時検知や，高頻度なハートビートによるハングアップも検知するためです。また，本製品にはユーザが指定した任意のシェルスクリプトを呼び出す機能も備わっています。そのため，異常検知時には保守情報を自動収集するだけでなく，クラウドサービスに対して即座に閉塞を指示するコマンドを発行できます。

4. スナップショットログ収集機能は，異常検知直後に自動的に必要な保守資料を収集し，指定したディレクトリにアーカイブを出力します。

   異常が検知されたときだけ，その時点で出力されていた保守資料を自動的に収集・アーカイブし，指定した永続化領域に出力する機能を提供します。

   詳細は，「17.　スナップショットログ収集機能」を参照してください。

   ヒント

   次の環境では，障害発生時の原因解析に必要なログファイルを別のストレージ領域^※に永続化しておく必要があります。

   • オートスケーリング機能によって仮想マシンの自動増減が発生するクラウド環境

   • オーケストレーションツールによってコンテナの起動・停止が頻発するコンテナ仮想化環境

   注※

   ログファイルを格納するストレージ領域は，サーバがスケールインされてもログファイルが消失しない領域にする必要があります。

   しかし，起動から停止まで正常稼働していた場合を含め，すべてのログファイルを永続化すると，ストレージ領域の容量や書き込み転送量が増大し，従量課金額がかさむリスクが生じます。また，一定時間経過後のログファイルを削除するなど，単調増加を防ぐ仕組みをユーザ側で構築する必要があります。

   本製品のスナップショットログ収集機能では，障害発生時にサポートサービスに提供する保守資料（ログファイル）が，障害発生時にだけ自動で出力されます。そして，それを1つのアーカイブファイルとして永続化できます。保守資料がアーカイブされているため，個々の保守資料を永続化するための作業が削減できます。また，永続化先のストレージ容量と書き込み転送量を削減できます。

ページの先頭へ