メインコンテンツまでスキップ

日々の停止や起動を行う

この章では、アプリケーションやサーバのメンテナンスなどで、ユーザからのシステムへのアクセスを一時的に制限する場合について説明します。
intra-martの環境を安全に停止・起動する際、「いつ」「どの順で」「どの方法で」行うか などを、理由と注意点を含めて整理していきましょう。

停止や再起動が必要なケース​

設定を変更した​

各種設定の変更に伴い設定ファイルを編集・更新した場合は、基本的に再起動が必要となります。
主なケースは以下のものが挙げられます。これら設定ファイルの多くは起動時に読み込まれるため、再起動（または再デプロイ/サービスリロード）が必要となります。

  • アプリケーション（イントラマート本体/Resin/Servlet コンテナ など）の設定変更
  • JVMオプション/Javaランタイムの変更
  • Webサーバ/プロキシ（Apache、IISなど）の設定変更
  • SSL/TLS 証明書更新（サーバ証明書や鍵の入替）
  • クラスタ/分散関連の設定変更
  • データソース/接続設定の変更
  • Resin/resin-dataや展開情報に関わる操作（resin-data を削除・操作する場合）
  • アプリケーション（WAR）に含まれる設定ファイルやライブラリの変更
各種設定の更新など​
  • OS・ミドルウェアのセキュリティパッチ適用やカーネル更新（Windows/Linux再起動）
  • データベースのメンテナンス（パッチ、バックアップ/リストア など）
  • JVMオプションやJavaバージョンの変更（ヒープサイズや GC設定を含む）
  • WAR配備/更新、ライブラリ差し替え、WEB-INF内設定変更
  • クラスタ設定変更（ノード追加/削除、セッション共有方式変更）
  • SSL/TLS証明書更新やポート設定変更
  • ログローテーションやディスク肥大対応（巨大ログやtempファイル削除のための停止）

バージョンアップを行った​

バージョンアップをした際には、WARファイルの切替が必要になります。

カスタマイズを追加した​

カスタマイズを追加した場合も、設定を変更したときと同様に再起動が必要となります。

トラブルが起こった​

何らかのトラブルが起こった際にも、障害対応として停止と再起動は重要です。
考えられる主なトラブルのケースを見ていきましょう。

  • OutOfMemoryError（JVMヒープ不足）でプロセスが停止・ハングした場合

    • なぜ：JVM自体が不安定/停止しているためプロセス再起動が必要
    • 注意：原因調査（ヒープ設定、メモリリーク、実行中ジョブ）を行う。再起動のみで根本対処にならないことが多い
    • 優先度：高（即時対応）

  • Resin/アプリケーションが応答しない（ハング、スレッドデッドロック など）

    • なぜ：プロセス再起動でリソース解放・正常状態へ戻す必要がある
    • 注意：ログ（system.log、jvm-app-*.log、stdout）先に確認。クラスタでは単一ノード切り離し→順次再起動を検討
    • 優先度：高

  • セッション/内部DB（work/httpd/session、resin-data）の破損・不整合（ファイルが壊れる など）

    • なぜ：破損した内部ファイルが原因で起動やデプロイに失敗するため、停止して該当ファイル削除や修復後に再起動が必要
    • 注意：分散クラスタではresin-dataなどは全ノードで整合性を取る必要がある（共有の場合は全ノードで操作）。resin-data破損は停止手順が不適切なことが多いので、推奨手順で停止しているか見直す
    • 優先度：高〜中（影響範囲に依存）

  • クラスタ通信エラー（Read timed outなど）でノード間接続が破綻している場合

    • なぜ：ノードの再接続・再同期のために該当ノードの停止/再起動が必要な場合がある
    • 注意：ネットワークやファイアウォール、ポート（例：クラスタポート）を確認。全ノード同時起動は避ける
    • 優先度：高〜中

  • Apache側でResinConfigServerに関連する設定不整合により503が発生（設定先サーバが参照不能 など）

    • なぜ：Apache設定やキャッシュのクリア、または対象サーバの再起動で回復することがある
    • 注意：Apacheの再起動/設定変更は影響が大きいのでメンテ実施を周知。ResinConfigServerを複数指定するか事前検証を
    • 優先度：中〜高

推奨する手順​

一般的な推奨の停止/起動順序を見ていきましょう。環境要件により前後する場合がありますが、「データベースは必ず起動済みであること」が重要です。

停止順（安全に停止するための一例）​

  1. Application Platform（AP1～APnのサービス）を順次停止
  2. Server Manager（ある場合）を停止
  3. APサーバ群、Server ManagerのOSを停止（必要に応じて）
  4. データベースを停止（DBは最後に停止）

再起動順（DBを先に起動することが前提）​

  1. データベースを起動（DBが先に利用可能であることが必須）
  2. APサーバ群、Server ManagerのOSを起動
  3. Server Managerを起動（ある場合）
  4. Application Platform（AP）サービスを順次起動（ノードは間隔を置いて）

スケジュール系ジョブの停止について​

ジョブやジョブネット、タスクを利用してアプリケーションを停止します。ジョブネットとは、複数ジョブの組合せで定義される実行単位です。 これらの停止・再開を行う主な2つの方法を確認しましょう。

  • 「システム管理画面（サービス設定）」でJob Scheduler Service/Task Serviceを停止する
    全テナント・全サーバで一斉にジョブ発火を抑止したい/メンテナンスで全体停止する場合はこちらです。この画面からの停止操作はクラスタ全体（全APノード）に対して作用する仕様です。特定のAPサーバだけを指定して停止する機能はありません。「全テナント」「全ノード」に影響します。
  • 「テナント管理（ジョブ管理）」でジョブネットの停止/トリガ無効化を行う
    特定テナントだけ停止したい/テナント単位で制御したい場合はこちらで行います。テナント単位で切り分けられますが、テナント毎に手動で行う手間があるので、テナント数が多い場合は運用負荷が高くなります。

Resinの停止について​

Resin（Webアプリケーションサーバ）を停止する場合、標準の停止処理は処理中のリクエストを停止要求後から120秒待ち、それでも処理が終了しなければ、プロセスを中断・停止する動作があります（環境設定によりタイムアウト値は変わる場合があります）。
データ不整合や途中処理の問題を避けるためには以下の安全な停止手順を参照してください。

推奨の安全な停止手順例​

  1. ジョブネットのトリガを無効化して今後の新しい起動を抑止する（disableTriggers）
  2. ジョブネットモニタで「実行中のジョブがない」ことを確認する。実行中があれば完了を待つ
  3. 外部リクエストが無いことを確認（一定期間のアクセスログ、セッション状況などで確認）
  4. 非同期タスクキューに実行中のタスクがないことを確認
  5. Resin（intra-mart）を停止（resinctl stop など）。停止処理がタイムアウトでプロセス中断になる点に注意する
  6. メンテナンス作業実施
  7. Resin起動後、無効化したトリガを有効化（enableTriggers）してジョブを再開する
  • 補足：トリガの無効化/有効化はスクリプト（JobSchedulerManager API）でまとめて実行できるため、運用自動化に向く
参考

Webアプリケーションサーバについての詳細は、以下のガイドを参照してください。
セットアップガイド - 4.3. Web Application Server

Apacheの再起動について​

Apache（Webサーバ）を再起動する必要があるケースを確認していきましょう。
設定テストのみの場合や、接続を極力切りたくないときには、設定ファイルをチェックして再読み込み（graceful reload など）を行います。
モジュール追加や、深刻な不具合対応などの場合は、確実にプロセスを再生成する必要がありますので、完全な再起動（stop → start または restart）を行ってください。

  • httpd.confやVirtualHost、mod_proxy/mod_rewrite などの設定を変更したとき

    • Apache は設定ファイルの読み込みは起動時/リロード時のみ行うため

  • 新しいApacheモジュール（DSO）を追加・更新したとき（例：mod_proxy、mod_ssl など）

    • モジュールはロード時に初期化されるため再起動が必要

  • SSL証明書の更新・差替えを行ったとき

    • 証明書は起動済みプロセスに読み込まれないため再読み込みが必要

  • Apache のプロセスが高負荷/ハング/メモリリークなどで不安定なとき

    • プロセスを再生成することで状態をリセットして復旧するため

  • ログローテーションでファイルハンドルを切り替える必要があるとき（環境による）

    • 古いログが閉じられない場合があるため（多くはgracefulやreopenシグナルで対応）

  • Webサーバ側のキャッシュやプロキシ設定をクリアしたいとき（例：Proxyキャッシュ）

    • 既存接続やキャッシュの影響を排除するため

  • Apache側の設定で Resin（AP）への振り分け先を変更したとき

    • 振り分け設定は Apache 側が持つため、Apache の再読み込みが必要

  • Apacheを含むソフトウェア更新（パッケージ更新、OSカーネル更新後に再起動が必要な場合）

    • バイナリ差替え後はプロセスの再起動が必要
メモ

補足事項
Resin（AP）側のみの設定変更であれば、通常はResinの再起動のみで、Apacheの再起動は不要です。
Apache設定変更時はApacheの再起動およびリロードが必要となります。

参考

イントラマートにおけるApacheサーバについては、「セットアップガイド - 4.4.1. Apache HTTP Server」を参照してください。

前提と注意点​

intra-martは、起動時にデータベースが稼働している前提で動作します。DBを止める場合は必ず先にアプリケーションを停止してください。逆順（AP稼働中にDB停止）で行うとデータ破損や不整合、予期せぬエラーの原因になります。

いつ行うか​

上記で述べた通り、システムの停止や再起動は、トラブル時を除くと主に「環境を入れ替えたとき」「設定ファイルを変更したとき」、または「定期メンテナンス時」に行うことがほとんどです。
「いつ行うか」のタイミングについては、下記を念頭に置いて計画してください。

  • 事前通知済みのメンテナンスウィンドウ内で実施する（影響範囲を関係者へ通知）
  • 長時間のバッチが実行中にならない時間帯を選ぶ（可能ならバッチの最終実行をメンテ前に完了させる）
  • ジョブ停止はメンテナンス開始の少し前に実施して、実行中ジョブの終了を待ってから次工程へ進める。遅延発生を避けるためジョブの最終稼働状態を確認しておく
  • DBメンテが必要な場合は、必ず全AP停止 → DB停止の時間帯を確保する

再起動の必要が無い変更について​

画面操作で行うマスタ情報などの設定変更や、用意されたキャッシュクリア機能で済む変更は、再起動不要です。

起動しない場合のチェックポイント​

  • まずはログ（APの stdout.log、system.log、Apacheのエラーログ）で原因特定
  • ネットワーク上の疎通不良（ポートブロック・遅延）を疑う（特にクラスタポート）
  • 一斉起動が原因ならノードを個別に再起動して、スタートを間隔をあけて実行
  • どうしても停止できない場合は、Service ManagerやOSのプロセス強制終了（最終手段）を検討。ただしデータ整合性やセッションの状態に注意
  • 再発時は設定やハードウェア・ネットワーク構成の見直し（スイッチ/ファイアウォールのログ確認含む）を行う