Liferay Cloud Nativeとは？ 従来のSelf-HostedやPaaSとの違い、導入・移行時の注意点を解説

Liferay Cloud Nativeってなに？

Liferay Cloud Native Experienceとは

Liferay DXPを導入する場合、これまでは自分たちでサーバーを用意してLiferayをインストールする「Self-Hosted」や、Liferay社が提供するクラウドサービス「Liferay PaaS」を利用する方法が一般的でした。

そこに新たな選択肢として登場したのが、Liferay Cloud Native Experience（以下、CNE） です。

「Cloud Native」と聞いてなんとなくイメージしたかも知れませんが、Kubernetes上で動作するものになります。

ただ、CNEのポイントは、ただ単にLiferayをコンテナ上で動かすことじゃありません。

これまでは個別に設計・構築していたLiferayの実行環境を、標準化されたツールを使って、より効率的に構築・運用できるようにする仕組みです。

今回は、CNEの基本的な仕組みから、従来のSelf-HostedやPaaSとの違い、提供されているメニュー、既存環境から移行する際の注意点までをご紹介します。

CNEの基本的な仕組み

一言で言うと、CNEはAWSやGoogle Cloudなどのクラウド環境、あるいは自社で管理するKubernetes環境に、Liferay DXPを構築・運用するためのツールキットです。

Liferayが提供するHelmチャートやインフラ構築用のツールを利用することで、Liferayの実行環境を標準化し、構築やデプロイ、スケーリングなどを効率化できます。

主に次のような技術が利用されています。

技術	役割
コンテナ	Liferayをコンテナイメージとしてパッケージ化し、環境ごとの差異を吸収
Kubernetes	コンテナの起動・停止、障害時の再起動、スケーリングなどを管理
Helm	Kubernetes上にLiferayをデプロイするための設定をテンプレート化
GitOps	Gitで管理する設定情報をもとに、環境の変更やデプロイを実施
IaC	Terraformなどを利用してクラウドインフラの構築をコードで管理

例えばAWS Readyの場合、Liferay本体はAmazon EKS（Kubernetes）上で動作し、データベースや検索エンジン、ファイルストレージなどにはAWSのマネージドサービスを利用する構成が基本になってます。

これによって、Liferay本体とインフラを分離しながら、クラウドの機能を活用した可用性や拡張性の高い構成を実現できます。

なお、CNEはLiferay DXP 2024.Q1以降を対象としています。利用する際には、対象バージョンとの互換性を確認しておきましょう。

これまでのSelf-Hostedとは何が違うの？

従来のSelf-Hostedで必要だった作業

これまでLiferayをSelf-Hostedで導入する場合、一般的には次のような作業が必要でした。

まずサーバーを用意し、JavaやLiferay DXPをインストールします。さらにデータベースや検索エンジンを構築し、必要に応じてロードバランサーやクラスタリングの設定も行います。

運用が始まってからも、サーバーの増減やパッチ適用、障害対応、バックアップなど、いろいろと考えることがありました。

もちろん、これらの作業は従来のSelf-Hostedでも自動化できます。ただ、そのための仕組みは自分たちで設計・構築する必要がありました。

CNEとの違い

CNEでは、こうした作業の一部をLiferayが提供する標準ツールを使って効率化できます。

比較項目	Self-Hosted	CNE
Liferayの導入	手動インストールや独自スクリプト	Helmなどで標準化
インフラ構築	個別に設計・構築	Ready方式に応じて自動化
スケーリング	サーバー追加や個別設定	Kubernetesで自動化可能
障害復旧	監視・復旧手順を個別に構築	Podの自動再起動などを活用
アップデート	独自のリリース手順	GitOpsなどで管理
運用管理	OS・ミドルウェア中心	Kubernetes・クラウドサービス中心
カスタマイズ	OSGiモジュールなど	同様に利用可能

CNEにすれば運用が楽になる？

ここは少し注意したいところです。

CNEを導入したからといって、インフラの運用がすべて不要になるわけではありません。

クラウドアカウントの管理やネットワーク・セキュリティの設計、監視、バックアップ、障害対応などは引き続き必要です。

また、Kubernetesを利用するため、従来のOSやTomcatを中心とした運用とは違った知識も求められます。

つまり、運用がなくなるというよりも、個別のサーバーを管理する方法から、標準化されたクラウド基盤を管理する方法に変わるというイメージです。

じゃあ、Liferay PaaSとは何が違うの？

Liferay PaaSとの基本的な違い

Liferayには、クラウド上でLiferay DXPを利用できる「Liferay PaaS Experience」も用意されています。

PaaSのメリットは、インフラの構築や運用の多くをLiferay側に任せられることです。

利用者はインフラの細かな管理を意識せずに、Liferayを使ったアプリケーション開発や運用に集中できます。

一方で、インフラがLiferay側の管理下にあるため、利用者から見えない部分が多く、自由にコントロールできないという側面もあります。

例えば、基盤となるKubernetesやミドルウェアの構成を詳細に確認したり、必要に応じて設定を変更したりすることには制約があります。

また、基盤側のメンテナンスやアップデートについても、Liferayが提供する運用ルールやメンテナンススケジュールに従う必要があります。

自社の業務スケジュールに合わせてメンテナンスを実施したい場合でも、必ずしも希望どおりに調整できるとは限りません。

これに対してCNEでは、自社で管理するAWSなどのクラウド環境にLiferayを構築します。

そのため、インフラの構成を把握し、必要に応じて変更したり、メンテナンスのタイミングを自社の都合に合わせて計画したりできます。

PaaSが「インフラ運用をLiferayに任せるサービス」だとすると、CNEは「Liferayの標準ツールを活用しながら、自分たちでインフラをコントロールできる仕組み」といえます。

PaaSとCNEの比較

比較項目	Liferay PaaS	CNE
クラウド環境	Liferay側が管理	利用者側が管理
インフラ構成の可視性	利用者が確認できる範囲に制約あり	自社で構成や設定を把握・管理可能
インフラ構築	Liferayが提供	CNEを使って構築
Kubernetes管理	主にLiferay側	利用者側
インフラ設定の自由度	PaaSの提供範囲内	要件に合わせて柔軟に設定可能
メンテナンス時期	Liferayの運用ルールや調整に依存	自社のスケジュールに合わせて計画可能
障害時の調査	Liferay側の調査・対応が必要な領域あり	自社でインフラのログや設定を確認可能
クラウドサービスの選択	PaaSの制約に依存	要件に応じて選択可能
運用負荷	比較的小さい	自社での運用体制が必要
インフラ費用	PaaS契約に含まれる範囲に依存	クラウド利用料を別途負担

CNEなら自社の運用に合わせられる

CNEのメリットとして特に注目したいのが、インフラを自社でコントロールできる点です。

例えば、次のようなケースでは、この違いが大きく影響します。

• メンテナンスのスケジュール： 業務への影響が少ない日時を選び、インフラのアップデートやメンテナンスを計画できます。
• 障害時の原因調査： Kubernetesやクラウドサービスのログ、設定情報などを自社で確認できるため、問題の切り分けを進めやすくなります。
• セキュリティ要件への対応： 自社のセキュリティポリシーに合わせて、ネットワークやアクセス制御、監視などを設計できます。
• 既存システムとの連携： 社内ネットワークや既存のクラウドサービスとの接続を、要件に合わせて柔軟に構成できます。
• インフラの最適化： 利用状況に合わせてリソース構成を見直し、性能やコストの最適化を進められます。

もちろん、CNEでもクラウドプロバイダー側のメンテナンスやサービス仕様による制約はありますし、インフラの管理・運用は自社で行う必要があります。

ただ、これまでPaaSではLiferay側に依頼したり、回答や対応を待ったりする必要があった作業の一部を、自社の判断で進められるようになるのは大きなメリットです。

特に、業務システムとして長期間運用する場合、メンテナンスのスケジュールや障害対応を自社でコントロールできることは、運用面での安心感にもつながります。

インフラの運用体制を確保できるのであれば、構成の透明性や運用の自由度という点で、CNEはPaaSよりも魅力的な選択肢になるのではないでしょうか。

CNEにはどんなメニューがあるの？

Cloud Provider Ready

CNEには、大きく分けて「Cloud Provider Ready」と「Kubernetes Ready」の2つの導入方式があります。

Cloud Provider Readyは、特定のクラウドサービス向けに最適化された構築ツールを利用する方式です。

AWS ReadyやGCP Readyがこれに該当します。

Terraformなどを利用して、Liferayを動かすために必要なクラウド基盤を構築できるため、ゼロからインフラを設計・構築する手間を減らせます。

Kubernetes Ready

こちらは、すでに用意されているKubernetes環境を利用する方式です。

Liferayが提供するHelmチャートを使ってLiferay DXPをデプロイしますが、Kubernetesクラスタやデータベース、検索エンジンなどは自分たちで用意します。

その分、既存のインフラを活用したり、独自の構成を採用したりしやすいのが特徴です。

オンプレミス環境やプライベートクラウドでの構築の際はこちらになりますし、AWSやGCPでも標準の構成と異なる構成をとりたい場合などに向いています。

提供メニューの比較

主なメニューを整理すると、次のようになります。

メニュー	主な対象環境	特徴
AWS Ready	Amazon AWS	EKS、RDS、S3、OpenSearchなどを利用した構築を自動化
GCP Ready	Google Cloud	GCP向けの標準構成を提供
Kubernetes Ready	EKS、GKE、AKS、OpenShift、オンプレミスなど	既存のKubernetes環境を活用可能
Azure Ready	Microsoft Azure	提供状況・時期は公式情報の確認が必要

また、各メニューの標準構成は以下の通りです。

コンポーネント	AWS Ready	GCP Ready	Kubernetes Ready
LB	AWS Load Balancer	Cloud Load Balancing	任意のLB
Web / Gateway	Kubernetes Gateway	Kubernetes Gateway	任意のIngress / Gateway
AP	Liferay DXP + Tomcat	Liferay DXP + Tomcat	Liferay DXP + Tomcat
Kubernetes	Amazon EKS	Google Kubernetes Engine	EKS / GKE / AKS / OpenShift等
Search	Amazon OpenSearch Service	Elasticsearch（ECK）	任意の対応検索エンジン
DB	Amazon RDS for PostgreSQL	Cloud SQL for PostgreSQL	任意の対応RDB
Storage	Amazon S3	Google Cloud Storage	任意の対応ストレージ
デプロイ管理	Argo CD / Helm	Argo CD / Helm	Helm / GitOps等
インフラ構築	Terraform等で自動化	Terraform等で自動化	利用者側で構築
監視・ログ	AWS / Kubernetesの監視基盤	Google Cloud / Kubernetesの監視基盤	任意の監視基盤

※ AWS Ready・GCP Readyは標準的な構成を示しています。

AWS ReadyとKubernetes Ready、どちらを選べばいい？

例えばAWSでLiferayを動かす場合、AWS ReadyとKubernetes Readyのどちらも候補になります。

AWS Readyは、Liferayが用意した標準構成をできるだけ活用して、構築や運用の手間を減らしたい場合に向いています。

一方、すでに社内でEKSを運用している場合や、既存のデータベース・検索エンジン・ネットワーク構成などを活用したい場合には、Kubernetes Readyも検討したいところです。

ただし、AWS Readyでも設定変更や外部サービスとの連携は可能です。

そのため、標準構成と少し違うからといって、必ずしもKubernetes Readyを選ぶ必要はありません。

既存のインフラをどこまで活用したいのか、標準構成からどれくらい変更が必要なのかが選定のポイントになりそうです。

マイグレーションする場合に注意することは？

Liferay DXPのバージョン

CNEはLiferayの実行環境を標準化する仕組みですが、既存環境からの移行がすべて自動化されるわけではないです。

特に、長期間運用してきたLiferayや、カスタマイズが多い環境では、事前に確認しておきたいポイントがあります。

まず、CNEが対象としているのはLiferay DXP 2024.Q1以降です。

古いバージョンを利用している場合は、CNEへの移行と併せてLiferay本体のアップグレードも検討する必要があります。

この場合、単なるインフラ移行ではなく、アプリケーションの互換性確認やデータベースのアップグレードなども必要になるため、作業範囲が大きくなります。

データベースの互換性

AWS Ready、GCP Readyでは、標準のデータベースとしてPostgreSQLが採用されています。

そのため、既存環境でMySQLやOracle、SQL Serverなどを利用している場合は、移行先のデータベースをどうするか検討する必要があります。

PostgreSQLへ変更する場合は、データ移行だけでなく、データ型やSQLの互換性、独自カスタマイズへの影響なども確認が必要です。

一方、既存のデータベースを継続利用したい場合は、AWS Readyの標準構成を変更する方法や、Kubernetes Readyを利用する方法も検討できます。

ただし、Liferay DXPがサポートしているデータベースであっても、AWS Readyの標準構築ツールがそのまま対応しているとは限りません。

特に、データベースの種類を変更する場合は移行作業が大きくなる可能性があるため、既存のデータベースを継続利用できるか、事前に確認しておくことをおすすめします。

検索エンジンの互換性

AWS Readyでは、標準の検索エンジンとしてAmazon OpenSearch Serviceが採用されています。

一方、従来のSelf-HostedやPaaSではElasticsearchを利用しているケースも多いため、移行時には検索エンジンの互換性を確認する必要があります。

OpenSearchへ変更する場合は、Liferay DXPのバージョンとの互換性に加え、検索コネクタの変更や独自の検索カスタマイズへの影響などを確認しておきましょう。

なお、AWS ReadyではOpenSearchだけでなく、Elasticsearchを利用する構成もサポートされています。

公式ドキュメントには、Elastic Cloud on Kubernetes（ECK）を利用してElasticsearchを構築する方法が用意されています。

そのため、既存環境でElasticsearchを利用している場合でも、必ずしもOpenSearchへ変更する必要はありません。

ただし、Elasticsearchを利用する場合は、コンテナイメージへの検索コネクタの組み込みや接続設定の変更などが必要になります。

また、検索エンジンの種類を変更しない場合でも、バージョン変更や環境移行に伴うインデックスの再構築が必要になることがあります。

検索エンジンはLiferay DXPのバージョンによってサポート対象バージョンが異なるため、移行先のバージョンとの互換性を事前に確認しておくことが大切です。

ファイルストレージの移行

Liferayのドキュメントとメディアでファイルシステムを利用している場合は、CNE環境での保存方式を検討する必要があります。

例えばAWSではAmazon S3を利用する構成が一般的ですが、既存のファイルシステムからS3へ移行する場合、ファイルデータの移行だけでなく、Liferay側のストア設定も考慮する必要があります。

ファイルの整合性やアクセス権限、移行期間中の更新データの扱いなども確認しておきたいところです。

カスタマイズモジュールの移行

既存環境でOSGiモジュールや独自テーマ、Client Extensionなどを利用している場合は、CNE環境へのデプロイ方法を整理する必要があります。

CNEでもこれまでと同様にカスタマイズを利用できますが、従来のように稼働中のサーバーへ直接ファイルを配置する運用から、コンテナイメージやデプロイ設定を通じて反映する運用へ変更する場合があります。

また、サーバー内のローカルファイルや固定IPアドレス、特定のディレクトリ構成に依存する実装がある場合は注意が必要です。

ネットワーク・外部システムとの接続

既存システムと連携している場合は、ネットワーク構成の変更にも気をつけたいところです。

例えば、社内システムとの閉域接続、外部APIへのアクセス、送信元IPアドレスの固定、独自証明書の利用などが挙げられます。

CNEではKubernetesやクラウドのネットワーク機能を利用するため、従来のサーバー構成をそのまま再現できるとは限りません。

運用体制とコスト

CNEへ移行すると、OSやミドルウェアの管理負荷を減らせる可能性がありますが、代わりにKubernetesやクラウドサービスの運用が必要になります。

また、AWS Readyなどを利用する場合も、EKS、RDS、検索サービス、ストレージ、ネットワークなどの利用料金が発生します。

そのため、LiferayのライセンスやCNEの契約条件だけでなく、クラウド利用料や運用費用を含めたトータルコストで比較することが大切です。

移行前のチェックポイント

確認項目	主な確認愛用
Liferayバージョン	CNE対象バージョンか
DB・検索エンジン	移行先との互換性、変更の必要性
ファイルストレージ	保存方式、データ移行方法
カスタマイズ	コンテナ環境への対応
外部システム連携	ネットワーク、認証、接続先
運用	監視、バックアップ、障害対応
コスト	クラウド利用料、ライセンス、運用費

特にPaaSからCNEへ移行する場合は、これまでLiferay側が管理していたインフラの運用を自分たちで行うことになります。

そのため、技術面だけでなく、移行後の運用体制も含めて計画しておくことをおすすめします。

まとめ

CNEのメリットと注意点

Liferay Cloud Native Experience（CNE）は、Liferay DXPの構築・運用を標準化しながら、自社でインフラを管理できる新しい選択肢です。

従来のSelf-Hostedと比べると、KubernetesやHelm、Terraformなどを活用することで、インフラの構築やデプロイ、スケーリングなどを効率化できることが大きなメリットです。

また、Liferay PaaSと比べると、インフラ構成の透明性が高く、メンテナンスのスケジュールや障害対応を自社の判断で進められる点が魅力です。

こんにちは、admin さん

PaaSでは基盤の運用をLiferay側に任せられる反面、インフラの詳細を把握しにくかったり、メンテナンスのタイミングを自由に調整できなかったりすることがあります。

CNEであれば、こうした制約を減らし、自社のセキュリティポリシーや運用方針に合わせて環境を構築・管理できます。

CNEを導入する際のポイント

CNEにはAWS Ready、GCP Ready、Kubernetes Readyなどの導入方式が用意されており、利用するクラウド環境や既存インフラの構成に合わせて選択できます。

ただし、各Readyでは標準構成が異なるため、既存環境から移行する場合には注意が必要です。

もちろん、CNEではインフラの管理責任が自社に移るため、Kubernetesやクラウドサービスの運用体制も必要になります。

それでも、Liferayが提供する標準ツールを活用することで、従来のSelf-Hostedのようにすべてを個別に構築することなく、自社でコントロールできる環境を整えられるのは大きなメリットだと思います。

特に、長期的な運用や既存システムとの連携、セキュリティ要件への対応などを重視する企業にとって、CNEは有力な選択肢になるのではないでしょうか。

OxygenDesignでは日本ライフレイのオフィシャル コンサルティング ファームとして、Liferay DXPの導入・構築からカスタマイズ、アップグレード、運用まで幅広く支援しています。

CNEへの移行についても、既存環境の調査、移行方式の検討、インフラ構成の設計、データやカスタマイズの移行など、お客様の環境やご要件に合わせた支援が可能です。

現在Self-HostedやLiferay PaaSをご利用中で、CNEへの移行をご検討されている場合は、ぜひお気軽にご相談ください。

まつもとでした！