Spring Boot WARデプロイの基本と実践：Tomcat、Nginx、そしてパフォーマンス向上

Spring Bootアプリケーションのデプロイ戦略は多岐にわたりますが、特にエンタープライズ環境や既存のインフラストラクチャとの統合を考慮する際、WAR（Web Application Archive）形式でのデプロイは依然として重要な選択肢です。
本記事では、Spring BootアプリケーションをWAR形式でデプロイする基本的な考え方から、Tomcatへの具体的なデプロイ方法、Nginxを組み合わせたリバースプロキシ設定、さらにはパフォーマンス最適化のヒントまでを網羅的に解説します。
モダンな開発プラクティスと伝統的な運用環境の橋渡しを理解し、より堅牢で高性能なアプリケーション運用を目指しましょう。

Spring BootアプリケーションをWAR形式でデプロイする理由

Spring Bootはデフォルトで自己完結型のJARファイルとしてアプリケーションをパッケージングし、内蔵のTomcatやJettyなどのWebサーバーで起動できます。
しかし、この便利な機能があるにもかかわらず、なぜあえてWAR形式を選択し、外部のServletコンテナにデプロイするのでしょうか。
そこには、プロジェクトの特性、既存のインフラ、運用ポリシーなど、さまざまな要因が絡んでいます。

WARデプロイの基本とメリット

WARファイルは、Servlets、JSP、HTML、CSS、JavaScriptなどのWebアプリケーションに必要なコンポーネントをまとめた、Java EE（現Jakarta EE）の標準的なアーカイブ形式です。
これを外部のServletコンテナ（例: Apache Tomcat）にデプロイすることで、多くのメリットが享受できます。
主なメリットとしては、まず既存のアプリケーションサーバー資産を有効活用できる点が挙げられます。
既にTomcatなどのServletコンテナが稼働している環境では、新しいアプリケーションのために別途Webサーバーを起動する手間がなく、リソースを共有できます。

また、複数のWARファイルを一つのTomcatインスタンス上で動かすことで、リソースの効率的な利用や、集中管理による運用負荷の軽減が期待できます。
セキュリティや監視、ロギングなど、インフラレベルでの共通設定やポリシーを適用しやすくなるため、エンタープライズ環境でのガバナンス強化にも繋がります。
さらに、デプロイメントの標準化により、開発者と運用者の間で共通の理解を促進し、スムーズな連携を可能にします。
特に、モノリシックなアプリケーションや既存システムとの連携が必要な場合には、WARデプロイが非常に有効な選択肢となり得ます。（参考情報より）

WARファイルの構造とその役割

WARファイルは、実際には標準的なZIPベースのアーカイブファイルであり、特定のディレクトリ構造を持っています。
この構造を理解することは、トラブルシューティングやアプリケーションのリソース配置を最適化する上で不可欠です。
主要なディレクトリは以下の通りです。

• WEB-INF/: アプリケーションのデプロイメントに必要な機密情報や設定が含まれます。
  • classes/: コンパイル済みのJavaクラスファイルやプロパティファイルなどが配置されます。
  • lib/: アプリケーションが依存するJARライブラリが格納されます。
  • web.xml: (オプション) デプロイメントディスクリプタ。Servlet 3.0以降ではアノテーションによる設定が主流ですが、ServletやFilter、Listenerなどの設定をXML形式で定義することも可能です。（参考情報より）
• ルートディレクトリ: HTML、JSP、静的リソース（画像、CSS、JavaScriptファイルなど）が配置されます。これらはWebブラウザから直接アクセス可能な公開コンテンツです。

この構造により、Webサーバーはどのリソースを外部に公開し、どのリソースを内部処理に利用するかを明確に区別し、セキュアかつ効率的なWebアプリケーションの運用を実現します。
特にWEB-INF以下の内容はWebブラウザから直接アクセスできないため、アプリケーションの重要な設定ファイルやビジネスロジックを安全に保つことができます。

デプロイメント戦略としてのWARの選択

Spring Bootアプリケーションのデプロイメント戦略を決定する際には、プロジェクトの規模、開発チームのスキルセット、運用環境、そして将来のスケーラビリティなどを総合的に考慮する必要があります。
WARデプロイは、以下のようなシナリオで特に強みを発揮します。

1. 既存のTomcat/Servletコンテナ環境の活用: 既にApache TomcatなどのServletコンテナがインフラストラクチャとして確立されている場合、WARデプロイは新規サーバー導入の手間を省き、既存の監視・管理ツールとの連携が容易です。
2. モノリシックアプリケーションの一元管理: 複数のWebアプリケーションを一つのTomcatインスタンス上で管理したい場合、WAR形式でデプロイすることで、リソースの共有と運用の一元化が図れます。
   これにより、サーバーリソースの最適化やメンテナンスの効率化に繋がります。
3. エンタープライズ標準への準拠: 組織によっては、セキュリティやコンプライアンスの観点から、特定の標準的なデプロイ形式（例: WAR）や、集中管理されたアプリケーションサーバーの利用が求められることがあります。
   WARデプロイは、こうした要件を満たす上で有効な手段となります。

しかし、WARデプロイはコンテナへの依存性が発生し、Spring Bootの「Just run」という手軽さとは異なる運用フェーズが必要となる点も考慮すべきです。
マイクロサービスアーキテクチャではJAR形式が主流であるのに対し、モノリシックなサービスや既存資産との統合ではWARが有利となる場合が多いでしょう。

MavenとGradleでSpring Boot WARを作成する方法

Spring BootアプリケーションをWAR形式でパッケージングするには、プロジェクトのビルドツール（MavenまたはGradle）で適切な設定を行う必要があります。
これらの設定は、アプリケーションが実行時に外部のServletコンテナによって提供されるAPIを利用するように構成し、内蔵Servletコンテナをパッケージングしないように指示することが重要です。
ここでは、それぞれのビルドツールでの具体的な設定方法を解説します。

MavenでのWARビルド設定

Mavenを使用してSpring BootアプリケーションをWAR形式でビルドするには、pom.xmlファイルにいくつかの変更を加えます。
最も重要なのは、プロジェクトのパッケージングタイプをjarからwarに変更し、内蔵Tomcatの依存関係をprovidedスコープに設定することです。

具体的には、まず<project>タグの直下にある<packaging>要素を以下のように変更します。

<packaging>war</packaging>

次に、spring-boot-starter-tomcatの依存関係について、<scope>をprovidedに設定します。
これにより、WARファイルにはTomcatのライブラリが含まれなくなり、デプロイ先の外部Tomcatが提供するライブラリを使用するようになります。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-tomcat</artifactId>
    <scope>provided</scope>
</dependency>

最後に、メインアプリケーションクラスをSpringBootServletInitializerを継承するように変更します。
これは、外部Servletコンテナがアプリケーションを起動するためのエントリポイントを提供するために必要です。
通常、@SpringBootApplicationアノテーションが付いたクラスに以下のように追加します。

import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

public class YourApplication extends SpringBootServletInitializer {

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(YourApplication.class);
    }
    // ... mainメソッドなど他のコード
}

これらの設定により、mvn packageコマンドを実行すると、最終的に.warファイルがtarget/ディレクトリに生成されます。

GradleでのWARビルド設定

Gradleを使用している場合も、Mavenと同様にビルドスクリプト（build.gradle）を修正することでWARファイルを生成できます。
まず、warプラグインを適用します。これにより、WARファイル作成に必要なタスクが利用可能になります。

plugins {
    id 'java'
    id 'war' // WARプラグインを適用
    id 'org.springframework.boot' version '3.x.x' // Spring Bootプラグインのバージョンを指定
    id 'io.spring.dependency-management' version '1.x.x'
}

次に、spring-boot-starter-tomcatの依存関係をprovidedRuntimeスコープに設定します。
これはMavenのprovidedスコープに相当し、外部のServletコンテナがTomcatの機能を提供することを想定しています。

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat' // providedRuntimeで外部Tomcatを利用
    // 他の依存関係
}

Mavenと同様に、メインアプリケーションクラスはSpringBootServletInitializerを継承する必要があります。
Gradleでも、このクラスが外部Tomcatからの起動エントリポイントとなります。

import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

public class YourApplication extends SpringBootServletInitializer {

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(YourApplication.class);
    }
    // ... mainメソッドなど他のコード
}

これらの変更を加えてgradle buildコマンドを実行すると、build/libs/ディレクトリに.warファイルが生成されます。
Gradleの柔軟なビルドシステムにより、プロジェクトの要件に合わせてさらに詳細な設定を行うことも可能です。

WARファイル作成後の確認と注意点

WARファイルの作成が完了したら、デプロイ前にいくつかの確認を行うことが重要です。
まず、生成されたWARファイルが意図したディレクトリ（Mavenならtarget/、Gradleならbuild/libs/）に存在するかを確認します。
ファイル名も重要で、例えばmy-app.warというファイル名でデプロイすると、Tomcat上では通常http://localhost:8080/my-app/というコンテキストパスでアクセス可能になります。
もしルートコンテキスト（http://localhost:8080/）でアプリケーションを動かしたい場合は、WARファイル名をROOT.warに変更してデプロイします。

次に、WARファイルの内部構造を簡単に確認することも有効です。
WARファイルは実質的にはZIPファイルなので、解凍ツールで開いてWEB-INF/libディレクトリに必要なライブラリが適切に含まれているか、またWEB-INF/classesに必要なクラスファイルが存在するかなどをチェックできます。
特に、spring-boot-starter-tomcatがprovidedスコープになっていることを確認し、重複するTomcatライブラリが含まれていないかを注意深く見ます。

また、アプリケーションが依存する外部リソース（データベース接続情報など）が、WARファイル内部ではなく、外部のTomcat設定や環境変数から読み込まれるように設定されているかも確認が必要です。
これにより、WARファイルの再ビルドなしに環境ごとの設定を柔軟に変更できるようになります。
ビルド後のWARファイルをTomcatにデプロイする前に、これらの注意点を押さえておくことで、デプロイ時のエラーを未然に防ぎ、スムーズな運用へと繋がります。

TomcatへのWARデプロイとよくある404エラーの対処法

Spring BootアプリケーションのWARファイルが準備できたら、いよいよApache Tomcatへのデプロイです。
TomcatはWARファイルを簡単にデプロイできる様々な方法を提供していますが、時には予期せぬエラー、特に「404 Not Found」エラーに遭遇することがあります。
ここでは、Tomcatへの具体的なデプロイ手順と、遭遇しやすい404エラーの原因と対処法について詳しく見ていきましょう。

Tomcatへのデプロイ手順詳解

Apache TomcatへWARファイルをデプロイする方法は複数ありますが、ここでは最も一般的な方法をいくつか紹介します。

1. webappsディレクトリへの配置:
   最もシンプルで手軽な方法です。Tomcatのインストールディレクトリ内にあるwebapps/ディレクトリに、作成したWARファイルをコピーするだけです。
   Tomcatが起動中であれば、自動的にWARファイルが展開され、アプリケーションがデプロイされます。
   停止中に配置した場合は、Tomcat起動時にデプロイされます。（参考情報より）
2. Tomcat Manager UIの利用:
   Tomcatには、Webブラウザ経由でアプリケーションのデプロイや管理を行うための管理ツール（Tomcat Manager）が付属しています。
   Manager UIにアクセスし、「WAR file to deploy」セクションからWARファイルをアップロードすることでデプロイが可能です。
   これを利用するには、conf/tomcat-users.xmlファイルにmanager-guiロールを持つユーザーを設定する必要があります。（参考情報より）
3. CI/CDツールとの連携:
   JenkinsやAnsible、GitLab CI/CDなどの継続的インテグレーション/デリバリー（CI/CD）ツールと連携することで、デプロイプロセスを完全に自動化できます。
   これにより、開発者はコードの変更に集中し、デプロイは自動で行われるため、リリースサイクルを高速化し、ヒューマンエラーを削減できます。（参考情報より）

本番環境でのデプロイでは、ゼロダウンタイムデプロイメントを実現するために、Tomcatのバージョン番号付きWARファイル名機能（例: my-app##1.0.war）などを活用し、古いバージョンと新しいバージョンを同時に稼働させ、トラフィックを切り替える戦略も検討されることがあります。（参考情報より）

WARデプロイにおける404エラーの主要原因

WARファイルをTomcatにデプロイした後、アプリケーションにアクセスしようとすると「404 Not Found」エラーが発生することは珍しくありません。
これは通常、Tomcatがアプリケーションを正しく見つけられないか、アプリケーションが正しく起動していないことを意味します。
主要な原因と対処法は以下の通りです。

1. コンテキストパスの不一致:
   WARファイル名がそのままアプリケーションのコンテキストパスになります。
   例えば、my-app.warをデプロイした場合、アクセスURLはhttp://localhost:8080/my-app/となります。
   もしROOT.warとしてデプロイすれば、ルートコンテキストhttp://localhost:8080/でアクセス可能です。
   ファイル名とアクセスURLが一致しているかを確認してください。
2. デプロイ失敗またはアプリケーションの起動エラー:
   WARファイルがwebappsにコピーされたとしても、Tomcatがそのファイルを展開し、Spring Bootアプリケーションを起動する際にエラーが発生している可能性があります。
   この場合、Tomcatのログファイル（CATALINA_HOME/logs/catalina.outやlocalhost.<日付>.logなど）を詳細に確認することが最も重要です。
   ログには、ClassNotFoundException、BeanCreationExceptionなどの具体的なエラーメッセージが記録されているはずです。
3. SpringBootServletInitializerの未実装:
   外部Tomcatにデプロイする場合、Spring BootアプリケーションのエントリポイントとしてSpringBootServletInitializerを継承したクラスが必要です。
   この実装が漏れていると、Tomcatはアプリケーションを認識できません。前述のMaven/Gradle設定で示したように、このクラスが適切に設定されているかを確認してください。
4. Tomcatのバージョン互換性:
   使用しているTomcatのバージョンと、Spring Bootアプリケーションが要求するServlet APIのバージョンが合致しているかを確認します。
   例えば、Spring Boot 3.xはJakarta Servlet 6.0をベースとしているため、Tomcat 10.x以降が必要です。
   古いTomcatバージョンにデプロイしようとすると、互換性エラーが発生し、アプリケーションが起動しないことがあります。

これらのチェック項目を順に確認することで、404エラーの原因を特定し、適切な対処を行うことができます。

404エラー以外のトラブルシューティング

404エラーだけでなく、TomcatへのWARデプロイ時には様々な問題が発生する可能性があります。
問題解決のためには、Tomcatのログファイルを徹底的に調査することが基本となります。

これらの問題は、Tomcatのlogsディレクトリにあるログファイル（特にcatalina.out、localhost.<日付>.log、manager.<日付>.logなど）に詳細な情報が出力されます。
ログレベルを調整して、より詳細な情報を取得することも有効です。
また、Tomcatはバージョンごとに様々な改善や変更が加えられているため、公式ドキュメントで推奨されるJVMバージョンや設定を確認することも重要です。（参考情報より）

Nginxを活用したリバースプロキシとCORS設定

Spring BootアプリケーションをTomcatにWARデプロイした後、本番環境ではその前にWebサーバーを配置することが一般的です。
特にNginxは、その高性能と豊富な機能から、リバースプロキシとして広く利用されています。
Nginxを導入することで、セキュリティの向上、負荷分散、SSL終端処理、静的コンテンツの高速配信など、多くの恩恵が得られます。

Nginxをリバースプロキシとして設定する基本

Nginxをリバースプロキシとして設定することで、クライアントからのリクエストをNginxが受け取り、そのリクエストを内部ネットワークに配置されたTomcat（Spring Bootアプリケーション）に転送します。
これにより、Tomcatサーバーを直接インターネットに公開する必要がなくなり、セキュリティが大幅に向上します。
基本的なNginxの設定は、nginx.confファイルまたは/etc/nginx/conf.d/内の設定ファイルで行います。

以下は、Nginxでリバースプロキシを設定する際の基本的な例です。

server {
    listen 80;
    server_name example.com; # 実際のドメイン名に変更

    location / {
        proxy_pass http://localhost:8080/my-app/; # TomcatのURLとコンテキストパス
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # 静的コンテンツの例
    location /static/ {
        alias /path/to/your/static/files/; # 静的ファイルが置かれている実際のパス
        expires 30d;
        add_header Cache-Control "public, no-transform";
    }
}

この設定では、Nginxはポート80でリクエストを受け付け、http://localhost:8080/my-app/に転送します。
proxy_set_headerディレクティブは、クライアントのオリジナルIPアドレスなどの情報をTomcatに正しく伝えるために重要です。
また、Nginxは静的コンテンツの配信に優れており、Tomcatへの負荷を軽減しながら高速に静的ファイルを配信できます。（参考情報より）

CORS（オリジン間リソース共有）のNginxでの設定

現代のWebアプリケーションでは、フロントエンドとバックエンドが異なるドメインで動作する「SPA (Single Page Application)」が一般的です。
この場合、ブラウザのセキュリティ制約により、異なるオリジン（ドメイン、プロトコル、ポート）間でリソースを共有しようとするとCORS (Cross-Origin Resource Sharing) エラーが発生します。
Nginxをリバースプロキシとして利用する場合、CORSヘッダーをNginx側で設定することで、アプリケーションサーバー側の設定を簡素化できます。

NginxでのCORS設定は、通常add_headerディレクティブを使用して行います。

server {
    # ... 他の設定 ...

    location / {
        # ... proxy_pass の設定 ...

        # 特定のオリジンのみ許可する場合
        # if ($http_origin ~* "^(http://localhost:3000|https://your-frontend.com)$") {
        #     add_header 'Access-Control-Allow-Origin' "$http_origin";
        # }

        # すべてのオリジンを許可する場合（開発環境など）
        add_header 'Access-Control-Allow-Origin' '*';

        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
        add_header 'Access-Control-Allow-Credentials' 'true';

        # OPTIONSリクエストのプリフライト処理
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain; charset=utf-8';
            add_header 'Content-Length' 0;
            return 204;
        }
    }
}

Access-Control-Allow-Originはセキュリティ上非常に重要です。
本番環境では、'*'（すべて許可）ではなく、実際に許可するオリジンを明示的に指定することを強く推奨します。
複数のオリジンを許可する場合は、ifディレクティブと正規表現を組み合わせるのが一般的です。
OPTIONSリクエストは、実際のデータリクエストの前にブラウザが行う「プリフライト」リクエストであり、これにも適切に応答する必要があります。

Nginxのその他活用法とパフォーマンス向上

NginxはリバースプロキシやCORS設定以外にも、Spring Bootアプリケーションのパフォーマンスと信頼性を向上させるための強力な機能を提供します。

1. ロードバランシング:
   複数のTomcatインスタンスをNginxの背後に配置し、トラフィックを分散させることで、可用性とスケーラビリティを向上させます。
   Nginxはラウンドロビン、IPハッシュ、最小接続数など、様々なロードバランシングアルゴリズムをサポートしています。（参考情報より）

   upstream backend {
               server 127.0.0.1:8080;
               server 127.0.0.1:8081; # 別のTomcatインスタンス
           }
           server {
               listen 80;
               location / {
                   proxy_pass http://backend/my-app/;
               }
           }

2. SSL/TLS終端:
   HTTPS通信のSSL/TLS暗号化・復号化をNginxで行い、Tomcatの負荷を軽減します。
   NginxはSSLハンドシェイクの処理に優れており、証明書の管理も一元化できます。
   これにより、Spring BootアプリケーションはHTTPで動作させつつ、セキュアな通信を実現できます。（参考情報より）
3. キャッシュ機能:
   Nginxは特定のレスポンスをキャッシュし、同じリクエストが来た際にバックエンドサーバーに問い合わせることなく、Nginxから直接レスポンスを返すことができます。
   これにより、アプリケーションサーバーの負荷を劇的に軽減し、レスポンスタイムを短縮できます。
4. Gzip圧縮:
   HTML、CSS、JavaScriptなどのテキストベースのコンテンツを送信する前にGzip圧縮をかけることで、データ転送量を削減し、ページロード時間を短縮できます。
   Nginxのgzip on;設定で簡単に有効化できます。

Nginxを適切に設定することで、SSL処理のオフロードや静的コンテンツ配信の効率化により、Spring Bootアプリケーション全体のパフォーマンス向上に大きく貢献します。
ただし、HTTPS設定の不備などがパフォーマンス低下の原因となる場合もあるため、適切な設定と継続的な監視が重要です。（参考情報より）

Spring Bootのパフォーマンス最適化：ウォームアップとグレースフルシャットダウン

Spring Bootアプリケーションのパフォーマンスは、起動時間の短縮、効率的なリソース利用、そして安定した停止処理によって大きく左右されます。
特にWARデプロイ環境では、JVMやTomcatのチューニングも相まって、これらの要素が重要になります。
ここでは、アプリケーションのウォームアップ戦略とグレースフルシャットダウンの実装に焦点を当て、パフォーマンス向上のための実践的なアプローチを解説します。

アプリケーションのウォームアップ戦略

Spring Bootアプリケーションは、起動時に多くのBeanを初期化し、データベース接続を確立し、キャッシュをロードするなどの処理を行います。
この起動処理が完了するまでの時間（ウォームアップ時間）は、アプリケーションの初回応答速度に直結します。
特にデプロイや再起動の頻度が高い環境では、この時間の短縮が重要です。

ウォームアップ時間を短縮し、デプロイ直後から高いパフォーマンスを発揮させるための戦略は以下の通りです。

1. 起動時間の短縮:
   不要な自動設定の除外や、Beanの遅延初期化（@Lazyアノテーション）を活用することで、起動時にロードされるリソースを最小限に抑えます。
   これにより、JVMがアプリケーションコードを最適化するための時間も短縮されます。（参考情報より）
2. プロアクティブなキャッシュロード:
   アプリケーション起動後、すぐにアクセスされる可能性のある重要なデータを事前にキャッシュにロードしておく「プリローディング」戦略を導入します。
   これにより、初回リクエスト時にデータベースアクセスなどの遅延が発生するのを防ぎます。

   @Service
   public class CacheWarmupService {
       @Autowired
       private MyDataRepository myDataRepository;
   
       @EventListener(ApplicationReadyEvent.class)
       public void warmUpCache() {
           // アプリケーション起動後にキャッシュをロードする処理
           myDataRepository.findAll().forEach(data -> cache.put(data.getId(), data));
           System.out.println("Cache warmed up successfully.");
       }
   }

3. データベースコネクションプールの初期化:
   HikariCPなどのコネクションプールは、アプリケーション起動時に一定数のコネクションを事前に確立するように設定できます。
   これにより、初回のリクエストでデータベース接続の確立によるオーバーヘッドを回避できます。

これらの戦略を組み合わせることで、アプリケーションはデプロイ後すぐに「ホット」な状態になり、ユーザーエクスペリエンスの向上に貢献します。

グレースフルシャットダウンの実装と重要性

アプリケーションのシャットダウンは、単にプロセスを停止させるだけでなく、現在処理中のリクエストを安全に完了させ、リソースを適切にクリーンアップする「グレースフルシャットダウン」が非常に重要です。
これにより、データの不整合を防ぎ、クライアントにエラーを返すことなくスムーズなサービス停止・再起動が可能になります。

Spring Bootでは、グレースフルシャットダウンをサポートするための機能が提供されています。

• 組み込みTomcatの場合:
  application.propertiesまたはapplication.ymlに以下の設定を追加することで、組み込みServletコンテナのグレースフルシャットダウンを有効にできます。

  server.shutdown=graceful
  spring.lifecycle.timeout-per-shutdown-phase=30s # シャットダウンのタイムアウト時間

  この設定により、シャットダウンシグナルを受信した後、新しいリクエストの受け入れを停止し、既存のリクエストがtimeout-per-shutdown-phaseで指定された時間内に完了するのを待ちます。

• 外部Tomcatの場合:
  外部TomcatにWARデプロイしている場合、グレースフルシャットダウンはTomcat自体の設定と連携して行う必要があります。
  Tomcatはデフォルトでグレースフルシャットダウンをサポートしていますが、その挙動はTomcatのバージョンや設定に依存します。
  通常、Tomcatの停止スクリプト（shutdown.sh / shutdown.bat）はグレースフルシャットダウンをトリガーしますが、ロードバランサー（Nginxなど）との連携も重要です。
  ロードバランサーは、Tomcatインスタンスがシャットダウン準備中であることを検知し、新しいリクエストをそのインスタンスに転送しないように設定する必要があります。

グレースフルシャットダウンは、特にCI/CDパイプラインやコンテナオーケストレーション環境（Kubernetesなど）での自動デプロイにおいて、サービスの安定性を保つために不可欠な要素です。

JVMとデータベースのパフォーマンス最適化

Spring Bootアプリケーション全体のパフォーマンスを最大化するには、JVM（Java Virtual Machine）とデータベースの最適化が不可欠です。
これらはアプリケーションの基盤であり、適切なチューニングにより目覚ましい改善が見込めます。

これらの最適化は継続的なプロセスであり、Spring Boot Actuator、VisualVM、JProfilerなどのツールを用いたモニタリングとプロファイリングを通じて、常にアプリケーションのパフォーマンスを監視・分析することが重要です。（参考情報より）

“`