Liferay運用ガイド:パッチ・クラスタ・性能・バックアップ・勧告の追い方

Liferay DXPを本番で動かし続けるには、パッチ適用、クラスタ構成、性能の調整、バックアップ、脆弱性情報の確認を継続的に行う必要があります。このページは、公式ドキュメントで確認できた範囲を「出発点」としてまとめた図鑑です。公式で確認できなかった項目は、そのまま「未確認」と書いています。

ここがポイント: 運用の責任範囲は提供形態で変わります。PaaSではインフラ(Webサーバー、DB、検索、バックアップ、CI/CDなど)をLiferayが用意しますが、DXPのアップグレードとパッチは利用者の責任とされています。SaaSでは全スタックとアップグレード・パッチをLiferayが運用します。自社で触れる範囲を最初に確認しましょう。

運用の責任範囲を整理する

提供形態	インフラ	アップグレード・パッチ
SaaS	Liferayが運用	Liferayが運用
PaaS	Liferayが用意(Web、DB、検索、バックアップ、CI/CD)	利用者の責任
Self-Hosted	利用者が用意	利用者の責任(PaaSと同様と考えられますが、契約や構成は公式で要確認)

SaaSはClient Extensions前提で、OSGiカスタマイズやGroovyスクリプト、サーバー管理はできません。この記事の以降の話題は、主にPaaSとSelf-Hostedを想定しています。

パッチ・Fix Pack方針

リリースの数え方

バージョンは「年.四半期」(例: 2025.Q1)で表し、四半期内のパッチは 2024.Q1.1 のように番号が付きます。毎年Q1がLTSです。

パッチの種類

Hotfix
Fix Pack
Security Fix Pack

公式の方針として、最新の四半期リリースの最新パッチが最も多くの修正を含み、最新のQ1 LTSが最長のサポートを受けられる、とされています。ただし参照したパッチ解説ページには古い記述が含まれる可能性があるため、適用前に最新の内容を確認してください。

注意: LTSのサポート内訳(プレミアム期間と限定期間の区切り)は資料によって食い違いがあり、このガイドでは断定しません。また2026.Q2・Q3のサポート終了日も未確認です。契約と公式のサポート方針で確認してください。

Dockerでのパッチ

Dockerイメージを使う場合の手順は、公式の「Patching DXP in Docker」に別ページがあります。なお「Starting with a Docker Image」では、コンテナ内の変更は再起動で失われるとされ、/mnt/liferay 配下に files、scripts、deploy があると説明されています。

クラスタ要件

アプリケーションサーバー(APノード)を複数用意する
全ノードが共有するデータベースを使う(HSQLは不可)
全ノードからアクセスできるファイルストアを用意する
Cluster Linkを有効にする(cluster.link.enabled=true)

DXP Free Tierのクラスタは最大3ノードです。本番規模のクラスタはEnterprise Subscriptionの機能とされています。

2026.Q3の新プロパティ: cluster.link.jmx.enabled(既定値false)が追加されています。クラスタ監視でJMXを使っている場合は、アップグレード時に挙動を確認してください。

性能チューニングの出発点

公式のチューニングガイドで挙げられている出発点は次のとおりです。

スレッドプールは50から調整を始める
データベース接続プールは、それよりやや大きめにする
read-writerデータソースの利用を検討する
Ehcacheは既定値を引き継ぎ、そこから調整する

具体的な推奨値や環境ごとの最適値は、この調査では確認できていません。負荷試験で測りながら変えるのが一般的な進め方です。

動作要件の確認(2026.Q3)

項目	記載内容(公式の互換性マトリクス)
JDK	JDK 21。JDK 17はdeprecated
アプリケーションサーバー	Tomcat 10.1、JBoss EAP 8.x、WebLogic 15c、WildFly 30
DB	MySQL 8.0/8.4、MariaDB 10.6/11.8、PostgreSQL 14〜17、SQL Server 2019/2022、Oracle 19c、DB2 11.5、Aurora
検索	Elasticsearch 8.19.x、OpenSearch 2.19(Marketplaceコネクタ)

バックアップ

未確認: Liferay公式のバックアップ手順ページは、今回の調査では特定できていません。製品固有の手順や推奨コマンドは書きません。公式で要確認です。

一般論としての考え方(製品固有の主張ではありません)

一般に、バックアップ対象は「データベース」「ファイルストア」「検索インデックス(再構築で代替できるか)」「設定ファイルや配備物」に分けて考えます。DBとファイルストアは整合性が必要なため、取得の時点を揃える運用が通常求められます。復元テストを定期的に行い、実際に戻せることを確認してください。上の構成要素がLiferayでどう扱われるかは、公式の情報で確かめましょう。

PaaSの場合はLiferay側がバックアップを用意するとされていますが、範囲や保持期間は契約・公式資料で確認が必要です。

セキュリティ勧告の追い方

公式の脆弱性一覧(liferay.dev/vulnerabilities)を定期的に見る。調査時点では2025.Q3までの499件が掲載されていました。
2026年分の個別勧告は、公式では確認できていません。「載っていない=脆弱性がない」とは言えません。
脆弱性一覧のRSSは、更新が止まり気味でした。GitHubのリリースフィード(releases.atom)とあわせて監視するのが現実的です。
Security Fix Packの存在はパッチ方針に書かれています。サポート窓口(support.liferay.com)の通知も確認してください。

運用チェックリスト

[ ] 自社の提供形態(SaaS / PaaS / Self-Hosted)での責任範囲を文書化した
[ ] 使っているバージョンの互換性マトリクスと、JDK・DB・検索エンジンの組み合わせを突き合わせた
[ ] パッチの適用方針(いつ、誰が、どの種別を)を決めた
[ ] クラスタ要件(共有DB、共有ファイルストア、Cluster Link)を満たしている
[ ] スレッドプール、DB接続プール、キャッシュを負荷試験で確認した
[ ] バックアップ対象を洗い出し、復元手順を試した(公式手順は要確認)
[ ] 脆弱性情報の確認先と担当者を決めた
[ ] 新しい四半期リリースが出たときのアップグレード判断フローがある(アップグレードガイド参照)

出典

最終確認日: 2026年10月15日(内容は変わる可能性があります。必ず公式情報も確認してください)