システムの停止・再起動
アプリケーションやサーバのメンテナンス、設定変更、トラブル対応などに伴い、ユーザからのアクセスを一時的に制限する必要が生じる場合があります。intra-martの環境を安全に停止・起動するために、「いつ」「どの順で」「どの方法で」実施するかについて、理由や注意点とあわせて説明します。
停止・再起動が必要なケース
システムの停止や再起動は、すべての変更や作業で必要になるわけではありません。ここでは、停止・再起動の実施が必要となる主なケースを示します。
設定を変更した場合
各種設定の変更に伴い、設定ファイルを編集・更新した場合は、基本的に再起動が必要となります。多くの設定は起動時に読み込まれるため、変更内容を反映するには再起動、または再デプロイ／サービスリロードが必要です。
再起動が必要となる主な変更は、以下のとおりです。
- アプリケーション／実行環境の変更
- アプリケーションおよびミドルウェアの設定変更（intra-mart本体、Resin、Servletコンテナなど）
- アプリケーション資産の変更（WARファイルの配備・更新、ライブラリ差し替え、
WEB-INF配下の設定変更）- Resin関連データや展開情報の操作（
resin-dataの削除・変更など）- Webサーバ／外部公開設定の変更
- Webサーバ／プロキシの設定変更（Apache、IISなど）
- SSL/TLS証明書の更新（証明書・鍵の入れ替え、ポート設定変更）
- 接続・構成に関する変更
- データソースや接続設定の変更
- クラスタ構成や分散設定の変更（ノード追加・削除、セッション共有方式など）
- 基盤（OS・ミドルウェア・データベース）の変更
- OSやミドルウェアの更新（セキュリティパッチ適用、カーネル更新など）
- データベースのメンテナンス（パッチ適用、バックアップ／リストアなど）
- 運用・リソース管理に関する対応
- ログローテーションやディスク容量対応（ログや一時ファイルの整理を伴う場合）
バージョンアップを行った場合
アプリケーションのバージョンアップを実施した場合は、WARファイルの更新や再配備、ライブラリの差し替えなどが発生します。これらの変更は稼働中には反映されないため、再起動（または再デプロイ）が必要です。
カスタマイズを追加した場合
カスタマイズを追加した場合は、アプリケーションのコードや設定ファイル、ライブラリなどが変更されます。これらの変更は稼働中には反映されないため、再起動（または再デプロイ）が必要です。
トラブルが発生した場合
何らかのトラブルが発生した場合、障害の解消やサービス復旧のために、システムの停止や再起動が必要となることがあります。ここでは、主なトラブルのケースと対応の考え方を示します。
OutOfMemoryError（JVMヒープ不足）でプロセスが停止・ハングした場合【理由】 JVMが不安定または停止しているため、プロセスの再起動が必要となる。
【注意】 ヒープ設定やメモリリーク、実行中ジョブなどの原因調査を行う。再起動のみでは根本対処にならない場合が多い。
【優先度】 高（即時対応）
Resin／アプリケーションが応答しない場合（ハング、スレッドデッドロックなど）【理由】 プロセスを再起動し、リソースを解放して正常状態に戻す必要がある。
【注意】 事前にログ（
system.log、jvm-app-*.log、stdoutなど）を確認する。クラスタ構成の場合は、単一ノードを切り離してから、順次再起動を検討する。【優先度】 高
セッション／内部データ（work/httpd/sessionやresin-dataなど）の破損・不整合が発生した場合【理由】 破損したデータにより起動やデプロイが失敗するため、停止して修復後に再起動が必要となる。
【注意】 分散クラスタ環境では、
resin-dataなどの内部データはノード間で整合性を取る必要がある。共有構成の場合は、全ノードに対して同一の操作を行う。なお、resin-dataの破損は不適切な停止手順が原因となることが多いため、推奨手順で停止しているかを見直す。【優先度】 高〜中（影響範囲に依存）
クラスタ通信エラー（Read timed outなど）によりノード間接続が不安定な場合【理由】 ノードの再接続・再同期のため、対象ノードの停止・再起動が必要となる場合がある。
【注意】 ネットワークやファイアウォール、ポート設定（クラスタポートなど）を確認する。ノード間の不整合を防ぐため、全ノードの同時起動は避ける。
【優先度】 高〜中
Apache設定の不整合により503エラーが発生した場合（ResinConfigServer関連）【理由】 設定の不整合やキャッシュの影響によりバックエンドサーバへ接続できず、設定の再読込や対象サーバの再起動で回復する場合がある。
【注意】 Apacheの再起動や設定変更は影響範囲が大きいため、事前にメンテナンス実施を周知する。あわせて、
ResinConfigServerの冗長化（複数指定）や事前検証を行う。【優先度】 高〜中
停止・再起動の事前確認
システムの停止・再起動にあたり、事前に確認しておくべき注意事項や実施タイミングについて説明します。
実施前の注意事項
intra-martは、起動時にデータベースが稼働している前提で動作します。データベースを停止する場合は、必ず先にアプリケーションを停止してください。逆の手順（アプリケーションを稼働中に、データベースを停止する）で実施した場合、データの破損や不整合、および予期せぬエラーの原因となります。
実施タイミング
システムの停止や再起動は、トラブル時を除き、主に以下のタイミングで実施します。
- ✓環境の入れ替えや変更時
- ✓設定ファイルの変更時
- ✓定期メンテナンス時
実施にあたっては、以下の点を考慮してください。
計画・周知
(1) メンテナンスウィンドウ内で実施し、事前に影響範囲を関係者へ通知する
(2) 長時間バッチが実行されていない時間帯を選ぶ（可能であれば、バッチの最終実行をメンテナンスの前に完了させる）
ジョブの停止と確認
(1) ジョブの停止は、メンテナンスを開始する前に実施する
(2) ジョブ停止後、実行中ジョブの終了を確認してから次工程へ進む
(3) 遅延発生を避けるため、ジョブの最終稼働状態を確認しておく
データベースに関する制約
(1) データベースのメンテナンスが必要な場合は、必ずすべてのアプリケーションを停止してから、データベースを停止するまでの時間を確保する
停止・再起動の手順
システムの停止および再起動は、コンポーネント間の依存関係を考慮して実施する必要があります。ここでは、一般的な停止・再起動手順を示します。環境により手順が前後する場合がありますが、データベースは必ず先に起動することが重要です。
停止前の準備
システムを停止する前に、以下の対応を行います。
- ✓スケジュール系ジョブを停止する
- ✓実行中ジョブがないことを確認する
- ✓外部リクエストがないことを確認する
スケジュール系ジョブは、「ジョブ／ジョブネット」機能を利用して停止します。詳細は、下記「スケジュール系ジョブの停止」を参照してください。
停止手順
システムを安全に停止するための基本的な手順を以下に示します。
1. Application Platform（AP1～APn）のサービスを順次停止する
2. Server Managerを停止する（存在する場合）
3. アプリケーションサーバ群およびServer ManagerのOSを停止する（必要に応じて）
4. データベースを停止する
環境構成や運用要件により順序が前後する場合がありますが、データベースは必ず最後に停止することに注意してください。
アプリケーションサーバ（Resin）の停止手順は、下記「アプリケーションサーバ（Resin）停止」を参照してください。
起動手順
システムを安全に起動するための基本的な手順を以下に示します。データベースは事前に起動し、利用可能な状態であることを前提とします。
1. データベースを起動する
2. アプリケーションサーバ群およびServer ManagerのOSを起動する
3. Server Managerを起動する（存在する場合）
4. Application Platform（AP1～APn）のサービスを順次起動する
負荷の集中や起動時の競合を避けるため、ノード間は間隔を空けて起動してください。
設定変更の内容によっては、再起動を行わなくても反映される場合があります。 一般的に、画面操作によるマスタ情報の変更や、キャッシュクリア機能で対応できる変更については、再起動は不要です。
Webサーバ（Apache）の再起動手順は、下記「Webサーバ（Apache）再起動」を参照してください。
起動しない場合のチェックポイント
システムが正常に起動しない場合は、以下の観点から原因を切り分けてください。
(1) ログ（アプリケーションのstdout.log、system.log、Apacheのエラーログなど）で原因を特定する
(2) ネットワーク疎通（ポートブロックや遅延）を確認する（特にクラスタポート）
(3) 一斉起動が原因の場合は、ノードを個別に起動し、間隔を空けて実行する
(4) 停止できない場合は、Service ManagerやOSのプロセス強制終了を検討する（最終手段）
※ データの整合性やセッションの状態に注意する
(5) 再発する場合は、設定やハードウェア、ネットワーク構成を見直す（スイッチ／ファイアウォールのログ確認を含む）
補足（コンポーネント別）
スケジュール系ジョブの停止
ジョブ／ジョブネットやタスクを利用して、アプリケーションを停止します。ジョブネットとは、複数ジョブの組合せで定義される実行単位です。停止方法は、対象範囲に応じて使い分けます。
全体停止（全テナント・全サーバ）
- 全テナント・全サーバでジョブ発火を一括停止する場合
- メンテナンスなどでシステム全体を停止する場合
システム管理者により、「システム管理画面（サービス設定）」から
Job Scheduler Service/Task Serviceを停止します。この操作はクラスタ全体（全アプリケーションノード）に対して作用します。特定のアプリケーションサーバのみを指定して停止することはできません。参考
Job Scheduler Serviceはジョブを管理するサービスで、スケジューラに登録されたジョブの実行・監視を行います。Task Serviceは非同期タスクを実行するサービスで、タスクキューに登録されたタスクを実行します。これらのサービスを停止することで、ジョブやタスクの新規実行を抑止できます。詳細は「サービス仕様書 - intra-mart 各種サービスの概要」を参照してください。
テナント単位の停止
- 特定テナントのみ停止したい場合
- テナント単位で制御したい場合
テナント管理者により、「テナント管理画面（ジョブ管理）」からジョブネットの停止、またはトリガの無効化を行います。テナントごとに操作が必要なため、テナント数が多い場合は運用負荷に注意してください。
参考プログラムを実行するにはジョブネットを設定します。ジョブネットに対して、トリガ（実行する日時や、繰り返し実行の間隔など）を指定できます。詳細は「テナント管理者操作ガイド - ジョブを設定する」を参照してください。
アプリケーションサーバ（Resin）停止
アプリケーションサーバ（Resin）は、停止時に最大120秒待機し、それでも処理が終了しない場合はプロセスを中断する動作があります。このタイムアウト値は環境設定により変更される場合があります。そのため、データ不整合や途中処理の問題を避けるため、以下の手順で安全に停止します。
ジョブ運用の停止
(1) ジョブネットのトリガを無効化し、新規ジョブの起動を抑止する（disableTriggers）
(2) ジョブネットモニタで実行中のジョブがないことを確認する。実行中のジョブがある場合は、完了するまで待つ
(3) 一定期間のアクセスログやセッション状況など、外部リクエストがないことを確認する
(4) 非同期タスクキューに実行中タスクがないことを確認する
アプリケーションサーバの停止
(1) Resinを停止する（resinctl stopなど）
(2) intra-martが停止したことを確認する
タイムアウトによりプロセスが強制終了される場合があります。停止前に処理状況を確認してください。
アプリケーションサーバ（Resin）の停止は、コンソールまたはWindowsサービスのいずれかの方法で実施します。詳細は「セットアップガイド - 6. Web Application Server の起動・停止」を参照してください。
メンテナンス作業
(1) 必要なメンテナンス作業を実施する
ジョブ運用の再開
(1) Resinの起動後、無効化したトリガを有効化する（enableTriggers）
(2) ジョブを再度実行する
トリガの無効化／有効化は、スクリプト（JobSchedulerManager API）で一括実行できるため、手動操作を削減し、運用の自動化に活用できます。詳細は「intra-mart Accel Platform API Specifications - インタフェース JobSchedulerManager」を参照してください。
Webサーバ（Apache）再起動
Webサーバ（Apache）の再起動は、変更内容や障害対応の内容により、「再読み込み（リロード）で対応可能なケース」と「完全再起動が必要なケース」に分かれます。
設定テストのみで接続影響を最小限にしたい場合は、設定ファイルの再読み込み（graceful reloadなど）を行います。一方で、モジュール追加や不具合対応など、プロセスの再生成が必要な場合は、完全再起動（stop → start/restart）を実施します。
再読み込みで対応可能なケース
Webサーバ（Apache）の設定を反映するために、プロセスを停止せず設定を再読み込みします。
httpd.conf、VirtualHost、mod_proxy、mod_rewriteなどの設定変更
└ 設定ファイルは起動時またはリロード時に読み込まれるため、再読み込みが必要- SSL証明書の更新・差し替え
└ 証明書は起動済みプロセスに読み込まれないため、再読み込みが必要- Apache側のキャッシュやプロキシ設定の変更（例：Proxyキャッシュ）
└ 既存接続やキャッシュの影響を排除するため、再読み込みが必要- Apacheの振り分け先変更（Resinの設定変更）
└ 振り分け設定はApache側で行うため、再読み込みが必要- ログローテーションに伴うファイルハンドル切り替え（環境による）
└ 古いログが閉じない場合があるため、再読み込みが必要（graceful reloadやreopenシグナルで対応可能）
完全再起動が必要なケース
プロセスを再生成しないと設定が反映されない、または状態が復旧できないため、完全再起動を行います。
- Apacheモジュール（Dynamic Shared Object：DSO）の追加・更新（例：
mod_proxy、mod_ssl）
└ モジュールは起動時にロード・初期化されるため、完全再起動が必要- Apacheプロセスの高負荷・ハング・メモリリークなどの不安定な状態
└ プロセスを再生成することで状態をリセットして復旧するため、完全再起動が必要- Apacheを含むソフトウェア更新（パッケージ更新・OSカーネル更新など）
└ バイナリを差し替え後は、変更内容を反映するため、完全再起動が必要
Resin側のみの設定変更の場合は、通常はResinの再起動のみで対応可能であり、Apacheの再起動は不要です。一方で、Apache側の設定を変更した場合は、設定を反映するため、Apacheの再起動または再読み込み（リロード）が必要となります。
Apacheを使用する場合の前提条件や制限事項の詳細については、「セットアップガイド - 4.4.1. Apache HTTP Server」を参照してください。