プラットフォームの制限
Liferay Cloud とそのサービスには、サブスクリプション レベルに応じていくつかの重要な制限があります。 Liferay Cloudのインフラストラクチャの制限は、時間の経過とともに変更される可能性があります。
概要
Liferay Cloudの利用を計画する際には、これらの一般的な制限を考慮してください。
-
各サービスの利用可能なvCPU、メモリ、スケーリング、ネットワーク設定 (ドメイン、SSL証明書、IPアドレス)、VPN帯域幅に制限があります。 例えば、各サービスは最大200GBのRAMに制限されています。 カスタム ドメインも、 Web サーバーの構成に応じて 50 または 1500 に制限されます。
-
同時操作(同時アップロードなど)、ビルドサイズ、同時ビルド、バックアップにも制限があります。
-
特にLiferayまたはSearchサービスの単一インスタンスを使用している環境では、計画的なメンテナンスのためにサービスのダウンタイムが発生することがあります。
-
より厳格なセキュリティ、コンプライアンス、またはVPNの要件を満たすためには、プライベートクラスターのサブスクリプションが必要になる場合があります。
詳細は以下の項目を参照してください。
- すべてのサービス
- Liferayサービス
- データベースサービス
- 検索サービス
- バックアップサービス
- Webサーバーサービス
- 継続的インテグレーションサービス
- カスタムサービス
- セキュリティ
- ファイル ストレージ
- ネットワーク設定
- VPN
すべてのサービス
これらの制限は、Liferay Cloud環境のすべてのサービスに適用されます。
古いログへのアクセス: デフォルトでは、各サービスの過去 30 日間のログがコンソール経由で利用できます。 この期間を過ぎると、1年間保管されます。
サポート リクエストを送信して 、30 日以上前のアプリケーション ログにアクセスします。 このプロセスには 5 日かかるため、360 日以上前のログは取得できません。 ステータス ログとビルド ログは 30 日後には取得できなくなります。
サービスごとの追加インスタンス: スケール 設定 では、最初にサブスクリプション プランに対して購入したインスタンス数を使用します。 デフォルトでは、検索を除いて、サービスは 1 つのインスタンスを追加できます。 検索サービスでは奇数個のインスタンスを使用する必要があります。
ダウンタイム: Liferay Cloudのインフラが定期メンテナンスのために更新された場合、単一インスタンスで動作しているサービスが再起動することがあります。 本番環境では、高可用性設定(WebサーバーとLiferayサービスは各2インスタンス、Searchサービスは3インスタンス)にして、混乱を回避してください。 計画メンテナンスのスケジュールは こちらで確認できます。
サービス インスタンスあたりのメモリ: サービスには最大 200 GB の RAM を使用できます。これは、サブスクリプション プランによって決まります。 デフォルトのプランでは、1サービスあたり16GBとなっています。
サービスインスタンスあたりの仮想 CPU 数: サービスには最大 32 個の vCPU を設定できます。これはサブスクリプション プランによって決まります。
Liferayサービス
これらの制限は、各 Liferay Cloud 環境の Liferay サービス に適用されます。
自動スケーリング: 有効にすると、自動スケーリングによって追加される新しいインスタンスの数は、デフォルトの最大値である 10 までになります。 最大100個のインスタンスまで、異なる最大数のインスタンスを構成できます。
ドキュメントライブラリストレージ: サブスクリプションプランによって、Liferay サービスの データ ボリュームのサイズが決まります。これには、Liferayのドキュメントライブラリに使用されるストレージも含まれます。 デフォルトのボリュームサイズは100GBですが、4TB以下であればサイズを増やすことができます。 プロジェクトに4TBを超えるストレージが必要な場合は、プライベートクラスターが必要です。
セッションレプリケーション: Liferay Cloud 内の複数の Liferay インスタンス間でセッションを複製すると、インスタンスのパフォーマンスに影響する可能性があり、 サポートされていません。 Liferay Cloud は、リソース管理と高可用性戦略の一環として、Kubernetes 上のポッドの削除を活用します。 システムの健全性を維持するために、ポッドの排除が必要です。 これらは、基盤となるインフラストラクチャの更新や、ノードがリソース制限に近づいた場合などのシナリオによってトリガーされます。 その結果、影響を受けるポッドからアクティブなユーザー セッションが削除されます。 セッションが失われるため、セッションのレプリケーションによってパフォーマンスの問題が発生し、ユーザーが予期せずログアウトされる可能性もあります。 代わりに、スティッキー セッションを使用するか、カスタム アプリケーションでセッション ストレージを完全に使用しないようにします。
Liferay は、Cookie やデータベースのやり取りなどのさまざまな戦略を通じて、セッション損失の影響を軽減します。 これにより、セッションが失われた場合でも、 コマース カート などのアイテムが保存されるようになります。
Dynatrace
Dynatrace は Liferay Cloud 環境の標準セットアップには含まれていませんが、別途購入して使用することができます。 Dynatraceは高可用性の設定に含まれていますが、本番環境またはUAT環境にのみ適用されます。
これらの制限は、Dynatraceに適用されます。
Dynatrace メトリックの不一致: Dynatrace メトリックが Liferay Cloud コンソールに表示されるメトリックと一致しません。 これは、Dynatrace がエージェントベースのモニタリングを使用してホストから直接プロセスレベルのメトリックを収集するのに対し、コンソール メトリックは Kubernetes 内のポッドレベルのリソース割り当てと制限を測定するためです。 したがって、両方とも同じリソース (CPU など) に対して異なるメトリックを持つグラフを持つ可能性があり、アプリケーション内の異なるコンテキストに対しては両方とも正しいことになります。
Liferay Logのストリーミング: Liferay LogをDynatraceログにストリーミングすることはできません。
Session Replay: Liferay CloudではDynatrace Session Replayの機能は使用できません。
データベースサービス
これらの制限は、各Liferay Cloud環境の データベースサービス に適用されます。
データベース サイズ: データベース コンテナーのサイズ制限は、CPU コア 4 個、メモリ 15 GB、ディスク ストレージ 100 GB です。 サブスクリプションのアドオンを使用すると、これらの制限を増やすことができます。
ダウンタイム:データベースのメンテナンスにより、数ヶ月に一度、ダウンタイムが発生することがあります。 このダウンタイムは通常2分程度です。 これは、事前に通知がない場合もあります。 ダウンタイムの影響を軽減するために、 優先メンテナンス ウィンドウ を設定できます。
Read/write splits:データベースサービスでのread/write splitの構成は、Liferay Cloudではサポートされていません。
検索サービス
これらの制限は、各Liferay Cloud環境の 検索サービス に適用されます。
設定: Elasticsearch は Liferay Cloud ワークスペースを通じて設定する必要があり、 Liferay UI を通じて設定する必要はありません 。 プロジェクト ワークスペース内の構成ファイルは各デプロイメントで使用され、以前のデプロイメントの構成を上書きします。
メモリ設定:Elasticsearchサーバーのデフォルト(および最大)のJVMヒープサイズは4GBです。 最大割り当て数は、お客様のサブスクリプションプランによって決まります。
OS Packages: 検索サービス用に追加のOSパッケージをインストールすることはサポートされていません。
ポッド管理ポリシー: クラスター内の Elasticsearch ノードは、正常に起動するために相互に接続する必要があります。 複数のインスタンスを持つ検索サービスの場合、サービスの起動に関する問題を回避するために、サービスの LCP.json ファイル内の podManagementPolicy 値を parallel に設定する必要があります。
バックアップサービス
これらの制限は、各 Liferay Cloud 環境の バックアップ サービス に適用されます。
Backup Consistency:データが変更されたデータベースからコピーする他のプロセスと同様に、更新の実行中にバックアップが作成された場合、データベース内のデータとドキュメントライブラリ間の整合性は保証されません。 完全に一貫性のあるバックアップを確保するには、データベース管理者と連携して、 手動バックアップを実行している間は更新を凍結します。
バックアップサイズ: Liferay Cloudバージョン4.2.0より前では、バックアップには 一時ストレージを使用していました。 これらのバージョンでは、バックアップのサイズは、共有のエフェメラルディスクの残りのスペースに制限されています。 新しいバージョンでは、バックアップ ファイルは 1 TB のデータに制限されます。
バックアップのアップロード: 1 分間にアップロードできるバックアップは 1 つだけです。
同時操作: 同時バックアップ作成、復元、またはアップロードはサポートされていません。 ただし、同時ダウンロードには対応しています。
リソースの割り当て: Backupサービスに割り当てられるRAMとvCPUの数は、サブスクリプションプランによって決定されます。 デフォルトでは、サービスに2つのvCPUと1GBのRAMが割り当てられています。
アップロード/ダウンロード速度: バックアップのアップロードまたはダウンロードの速度は、インターネットの接続速度とバックアップのサイズによって制限されます。 非常に遅い回線では、バックアップのダウンロードに数時間かかる場合があります。
Webサーバサービス
これらの制限は、各Liferay Cloud環境の Webサーバーサービス に適用されます。
プラグイン:Webサーバーの追加プラグインのインストールはサポートされていません。
リソースの割り当て: Webサーバーはデフォルトで2つのvCPUと512MBのメモリを搭載しています。 そのため、大容量のアップロードやダウンロードの際には、応答が遅くなることがあります。 お客様のサブスクリプションプランによって、サービスの具体的なリソース配分が決まります。
継続的インテグレーションサービス
これらの制限は、各Liferay Cloud環境の CIサービス に適用されます。
管理者アクセス: 管理者レベルのアクセスはJenkinsサーバでは許可されていません。 代わりに、 Jenkins パイプライン フック を使用して CI パイプラインを拡張します。 既存のDevOpsプロセスは、このパイプラインに合わせて調整する必要があるかもしれません。
APIの同時呼び出し:プロジェクトはLiferay Cloud APIへの同時呼び出しを行うことはできません。 これには、 CLI ツールを介してビルドを環境にデプロイするなどのタスクが含まれます。
リソースの割り当て:CIサービスに割り当てられるRAMとvCPUの数は、サブスクリプションプランによって決定されます。 デフォルトでは、サービスに4つのvCPUと8GBのRAMが割り当てられています。
サーバーの容量:サブスクリプション・プランによって、CIサーバーのデータ・ボリュームのサイズが決まります。 デフォルトのサイズは100GBです。
ビルド
これらの制限は、プロジェクト内で作成されたすべてのビルドに適用されます。
ビルド サイズ: 個々のビルドはそれぞれ 2 GB に制限されます。 リポジトリ内のプロジェクトの合計サイズがこの制限以下であることを確認する必要があります。
同時ビルド: Jenkinsでは2つのエクゼキュータ・スレッドが使用されるため、最大2つの同時ビルドが実行可能です。
1 日あたりの最大ビルド数: ビルドは 1 日あたり 300 までに制限されます。 この制限を増やすには、サポート リクエストを送信してください 。
プライベート GitHub サーバー:プライベート GitHub サーバーとの統合はサポートされていません。
カスタムサービス
これらの制限は、Liferay Cloud 環境内のすべての カスタム サービス に適用されます。
ホストOSアクセス:ホストOSカーネルへの特権的なアクセスは、プライベート・クラスターを含むサブスクリプションに限定されます。
セキュリティ
これらの制限は、Liferay Cloud内で利用可能なセキュリティ機能に適用されます。
アンチウイルス:ファイルアップロード時にウイルスをスキャンするためのデフォルトのLiferayDXP機能は使用できません。 代わりにLiferay Clouds ウイルス対策ソリューション が使用されます。 アップロードされたコンテンツはスケジュールに沿ってスキャンされるため、ファイルがアップロードされた時点ではリスクが検出されない場合があります。
1分あたりの認証:1分あたり最大8400の認証が許可されます。
ファイアウォールルール: プライベートクラスタ付きのサブスクリプションを購入し、Liferay Cloud Supportと調整してカスタムファイアウォールルールを設定する必要があります。 カスタムファイアウォールルールは、共有クラスタサブスクリプションでは使用できません。 プライベートクラスター用に作成されたカスタムファイアウォールルールは、プロジェクト内のすべての環境に適用されます。
IPアドレスフィルタリング:IPアドレスフィルタリングは、Webサーバーサービスにのみ適用できます。
ファイル ストレージ
これらの制限は、複数のサービスのファイル保存に適用されます。
Ephemeral Storage:ボリュームに保存されていないすべてのファイルに使用されます。 エフェメラル ストレージはホスト ノードの内部ストレージ上に存在し、そのノード上で実行されているすべてのコンテナー間で共有されます。 コンテナがホストノードの空き容量以上のスペースを要求した場合、そのコンテナは別のノードに移動されます。 ホストディスクの容量は250GBです。
サービス間でデータを共有する: StatefulSet デプロイメント タイプ を持つサービスは、他のサービスとデータを共有できません。
StatefulSet ストレージ サイズ: StatefulSet デプロイメント タイプを使用してサービスにストレージを追加するには、サポート チケットを作成する必要があります。 StatefulSetサービスの保存サイズは、一度大きくすると縮小できません。
ネットワーク設定
これらの制限は、Liferay Cloud環境におけるお客様のサービスのネットワーク構成に適用されます。
カスタムドメインへの変更:カスタムドメインへの変更や追加がプロパゲートされるまで、最大で60分程度の遅延が発生する場合があります。
カスタム ドメインの最大数: 環境外部に複数のサービスを公開している場合 (デフォルトの Web サーバーに加えて)、カスタム ドメインの数は 50 個までに制限されます 。 ただし、Webサーバーが唯一のエントリーポイントである場合には、1500個のカスタムドメインの制限を使用することができます。 この制限を超えて使用量を増やすために Web サーバー サービスを変更する場合は、 サポート チケットを開く 必要があります。
最大SSL証明書:最大14個のカスタムSSL証明書を許可します。 また、証明書を発行するプロバイダーは、これを少なくするために独自の制限を課すことがあります。
アウトバウンド接続:プロジェクト環境から外部エンドポイントへの接続は、1接続あたり120秒のタイムアウトを伴うNATソリューションを使用します。 短時間に次々と新しい接続が作成されると、ポートの枯渇や送信トラフィックのドロップにつながる可能性があります。 コネクションプーリングは、この問題を防ぐことができます。
パブリックIPアドレス:デフォルトでは、すべての環境は1つのパブリックIPアドレスを持ち、環境内のサービスは内部IPアドレスを持ちます。 ただし、サービスのポートを外部として構成し、サービスにパブリック IP アドレスを割り当てることができます。 サービスのエンドポイントをインターネットに公開することは、 推奨されません。これは、 HTTPS ロードバランサーからの DDoS 保護をバイパスするためです。
ワイルドカード SSL 証明書: ワイルドカード証明書は、Liferayの自動生成された SSL 証明書ではサポートされていません。 ただし、カスタムワイルドカードSSL証明書でインスタンスを設定 することができます。
TCPポートの状態: TCPポートの中には、そのポートを使用して外部からのトラフィックが顧客の環境に到達していなくても、オープンと表示されるものがあります。 これらのポートは、サーバーの同じディスクを共有している他のプロジェクトのために開かれており、ユーザーの環境のセキュリティ上のリスクはありません。
JMX エクスポータ ポート: ポート 15000 は JMX エクスポータによって使用され、他の目的には使用できません。
VPN
これらの制限は、環境内のサービスに VPN サーバー を接続している場合に適用されます。
Site-to-Site VPN:Site-to-Site VPN サーバーは、Google Cloud VPN でのみ設定 できます。 また、プライベートクラスターのサブスクリプションが必要です。
帯域幅:各VPNトンネルの総帯域幅は3Gbpsに制限されています。 この制限は、受信トラフィックと送信トラフィックの合計に適用されます。
オンプレミスのネットワークを拡張する:オンプレミス・ネットワークからのCloud InterconnectやExpress Routeの専用接続はサポートされていません。 これは、直接またはパートナープロバイダーを経由した接続、共有またはプライベートクラスターでの接続に適用されます。
2要素認証: Cloud VPN (OpenVPN または IPSec) 内での 2要素認証の使用はサポートされていません。