サービス・インスタンスに関連付けられたメトリックに基づいて、何をスケーリングする必要があるかを判別します。 たとえば、レスポンス時間が長い場合はクラスタのスケール・アウトを検討します。 または、ヒープ使用率が高い場合は、クラスタ内のノードの拡張を検討します。 「OPCMのOracle Java Cloud Serviceでのサービス・メトリックの表示」は、Oracle Java Cloud Serviceがサービス・インスタンスに提供するメトリックに関する情報を提供します。
パッチ適用やバックアップ中などサービス・インスタンスがメンテナンス中の場合は、サービス・インスタンスをスケーリングすることはできません。
Oracle Java Cloud Serviceクラスタに対するロードの変化に対応して、クラスタをスケーリングして、クラスタに対してノードの追加または削除を行います。 ノードとは、クラスタのメンバーである管理対象サーバーを実行している仮想マシン(VM)です。
注意:
クラスタのスケーリングは、Oracle Java Cloud Service-Virtual Imageインスタンスでサポートされていません。Oracle Java Cloud Serviceクラスタのスケール・アウトについて
Oracle Java Cloud Serviceクラスタのスケール・アウトでは、1つのノードがクラスタに追加されます。
Oracle Java Cloud Serviceクラスタをスケール・アウトする前に、次のすべての条件が満たされることを確認します。
サービス・インスタンスがメンテナンス中ではありません。
これらの条件のいずれかが満たされないと、スケーリング操作は失敗し、Oracle Java Cloud Serviceによってエラー・メッセージが記録されます。
Oracle Java Cloud Serviceでは、スケール・アウトの開始または完了時、あるいは失敗が検出されたときにメッセージが記録されます。 「OPCMでのスケーリング・リクエストの表示」を参照してください。
クラスタのスケール・アウトの試行が失敗すると、Oracle Java Cloud Serviceでは次の処理が実行されます。
診断情報を記録します。
他の操作が継続できるように、サービス・インスタンスのステータスをRUNNINGに設定します。
サービス・インスタンスを元のシェイプに戻します。
追加の管理対象サーバー・インスタンスを実行するために作成されたVMを削除します。
Oracle Java Cloud Serviceクラスタのスケール・インについて
Oracle Java Cloud Serviceクラスタのスケール・インでは、選択したノードがクラスタから削除されます。
Oracle Java Cloud Serviceクラスタをスケール・インする前に、管理サーバーと1番目の管理対象サーバー用のノードの他に、少なくとも1つの管理対象サーバー・ノードがクラスタに含まれることを確認します。 管理サーバーと1番目の管理対象サーバーのノードしか含まないクラスタをスケール・インすることはできません。 このノードが不要になった場合は、サービス・インスタンス全体を削除する必要があります。 Oracle Java Cloud Serviceインスタンスの削除を参照してください。
デフォルトでは、Oracle Java Cloud Serviceは、管理対象サーバー・インスタンスを正常にシャットダウンした後で、クラスタからの管理対象サーバー・インスタンスの削除およびVMの停止を行って、クラスタをスケール・インします。 管理対象サーバー・インスタンスが応答しない場合にノードを確実に削除するためには、クラスタの強制スケール・インを選択できます。
クラスタのスケール・インの試行が失敗すると、Oracle Java Cloud Serviceでは次の処理が実行されます。
診断情報を記録します。
他の操作が継続できるように、サービス・インスタンスのステータスをRUNNINGに設定します。
古いリソース(ある場合)をクリーンアップします。
新規クラスタの追加について
インスタンスのスケール・アウトが必要なときにクラスタが存在しない場合や、新しい管理対象サーバーを新しいクラスタに追加する場合があります。 REST APIを使用して管理対象サーバーを追加し、スケール・アウトRESTエンドポイントにcreateClusterIfMissing=true問合せパラメータを含むことにより、クラスタをインスタンスに追加できます。 クラスタを追加すると、トポロジタイルにそのクラスタが表示され、それが追加されたことを確認できます。 これは単にクラスタを追加するのみでなく、新しいノードを含むためにスケール・アウトも行います。
Oracle Java Cloud Serviceノードをスケーリングして、ワークロードの変化に対応するようにコンピューティング形態を変更したり、ストレージが不足しているノードにブロック・ストレージを追加したります。 ただし、ノードからブロック・ストレージを削除することはできません。
スケーリングできるのはWebLogic Serverクラスタ内の管理サーバー・ノードと管理対象サーバー・ノードのみです。 Oracle Java Cloud Serviceでは、サービス・インスタンス内の他のノード(Coherenceデータ層のロード・バランサ・ノードまたは容量単位ノードなど)についてはスケーリングをサポートしていません。
クラスタの各ノードを個別にスケーリングする必要があります。 1回の操作でクラスタ内のすべてのノードをスケーリングすることはできません。
ノードのコンピューティング形態の変化について
ノードのコンピューティング形態を変更し、ワークロードの変化に対応するように処理能力を調整できます。 コンピューティング形態によって、ノードに対して割り当てるOracle Compute Units (OCPU)の数およびメモリー量(RAM)が指定されます。
Oracle Java Cloud Serviceは様々な使用ケースに適した一連のコンピューティング形態を備えています。 全目的型およびメモリー集中型の一連の形態から選択します。 コンピューティング形態が大きくなるほど、処理能力は上昇します。 定義済みコンピューティング形態の詳細は、Oracle Cloud管理者に問い合わせてください。
高負荷のワークロードの要求を満たすには、より大きなコンピューティング形態を選択してコンピューティング形態を拡張します。
たとえば、コンピューティング形態をOC3からOC4に変更すると、ノードの処理能力が1 OCPUから2 OCPUに倍増し、ノードに割り当てられるRAM容量も倍増します。
ワークロードが軽減した場合にコストを節約するには、小さいコンピューティング形態を選択してノードのコンピューティング形態を縮小します。
たとえば、コンピューティング形態をOC4からOC3に変更すると、ノードの処理能力が2 OCPUから1 OCPUに半減し、ノードに割り当てられるRAM容量も半減します。
注意:
パフォーマンスを最適化して、管理対象サーバー・インスタンスでのロード・バランシングを適切に行うには、クラスタ内のすべてのノードのコンピューティング形態が同一になるようにします。 リクエストを管理対象サーバー・インスタンスにルーティングするとき、ロード・バランサはすべての管理対象サーバー・インスタンスを同等として扱います。ノードへのブロック・ストレージの追加について
ストレージが不足しているノードにブロック・ストレージを追加できます。 ストレージをノードに追加すると、Oracle Compute Cloud Serviceストレージ・ボリュームが作成され、ノードのVMにアタッチされます。
注意:
ノードからブロック・ストレージを削除することはできません。スケーリングで作成された新しいストレージ・ボリュームはアタッチされたままで、サービス・インスタンスを再起動したり、停止してから起動した場合でも、ノードのVMで使用できます。 また、このストレージ・ボリュームはサービス・インスタンスを削除するまで存在し、その時点でストレージ・ボリュームも削除されます。
ストレージを追加できるのは、新しいボリュームまたは次に示す既存のボリュームのいずれかです。
バックアップ・ストレージ・ボリューム(管理サーバー・ノードのみ)
ドメイン・ホーム・ストレージ・ボリューム
ミドルウェア・ホーム・ストレージ・ボリューム
これらのボリュームの詳細は、「ディスク・ボリュームについて」を参照してください。
ストレージ・ボリュームにストレージを追加できるのは最大で5回までます。
注意:
ストレージをドメイン・ホームまたはミドルウェア・ホーム・ストレージ・ボリュームに追加する前に、サービス・インスタンスをバックアップしてデータ損失のリスクを回避します。 手順については、「OPCMでのOracle Java Cloud Serviceインスタンスのオンデマンド・バックアップの開始」を参照してください。