IT

Kubernetes で Jakarta EE（Payara）業務システムを動かすときの考慮点と注意点

Y.Yoshi

• 3 min read
Kubernetes で Jakarta EE（Payara）業務システムを動かすときの考慮点と注意点
Photo by Growtika / Unsplash

近年、業務システムでも「コンテナ化して Kubernetes で可用性と運用性を上げたい」という要望が増えています。しかし、Jakarta EE（特に Payara Server）を単純にコンテナへ入れるだけでは、Kubernetes の恩恵を最大化できません。

この記事では、業務システムを Payara Server で構築している場合に Kubernetes 化する際、必ず押さえるべきポイントをまとめます。クラウド環境としては Oracle Cloud（OKE）を前提にしていますが、考え方自体はどのK8sにも共通します。

1. 「Payara Server をそのままクラスタリング」は原則しない

GlassFish 系の標準的なクラスタリング（DAS を中心としたドメイン管理）は、**「ノードが固定される前提」**の設計です。一方 Kubernetes では Pod は“消えるもの”であり、再スケジュールされ、IP も入れ替わります。

そのため、Kubernetes では以下の方式が定石です。

  • Payara Server の各Podを独立インスタンスとして動かす（non-DAS構成）
  • 設定は Docker イメージ内 or preboot/postboot スクリプトで再現可能にする
  • クラスタ管理は Kubernetes（Deployment/ReplicaSet）に任せる

DASごとコンテナ化してPod内で起動する構成は、Kubernetesとの相性が悪く非推奨です。

2. コンテナ化で重要なのは「ステートレス化」

Kubernetes での可用性向上の本質は、「アプリをいつでもどこにでも再配置できる状態にする」ことです。そのカギが ステートレス化 です。

ステートレス化の要件

  • セッションを外に出す / JWT化する
    • HttpSession を使うなら Sticky Session や外部ストア（Redis など）が必要
    • 最も可用性が高いのは JWT などの完全ステートレス方式
  • ファイルはローカルに置かない
    • “アップロードをローカルに保存”は Pod の再配置で必ず壊れる
    • Object Storage（クラウドストレージ）に保存するのがベスト
  • 設定ファイルを不変にする
    • ConfigMap/Secret で定義し、イメージ内の設定を最小化

Payara を複数 Pod として動かすためには、このあたりの調整が必須です。

3. ファイルアップロードは Object Storage または 共有ファイルシステム（FSS）に逃がす

業務システムでよくある“ファイルアップロード”は、Kubernetes では最大の落とし穴になります。

X アップロードをローカル（/tmp や /opt/payara/...）に保存
→ Pod が落ちた瞬間に消えるため、冗長化できない

  • Object Storage（OCI Object Storage など）へ直接保存
    • Podが消えても影響ゼロ
    • OKEとの相性が良い
    • 可用性を最も高くできる

さらに、100MiBを超えるファイルなら OCI はマルチパートアップロード推奨なので、大容量対応も容易です。

DBにはメタデータだけを保存する

例：

  • bucket
  • objectName
  • size
  • contentType
  • status（UPLOADING / AVAILABLE / FAILED）

この構造にしておけば、アップロード失敗時の再試行や整合性チェックも容易です。

4. Payara Server のヘルスチェックは必ず設計する

Payara Server は起動に時間がかかるため、Probe（ヘルスチェック）設計が非常に重要です。

特に重要な3つ

1. startupProbe

  • 「起動完了まで liveness を無効化」
  • これが無いと、Payara は起動途中で liveness に殺されて再起動ループになります

2. readinessProbe

  • アプリが「リクエストを受けられる状態」になってからONLY トラフィックを流す
  • DB疎通が完了してから 200 を返すのが理想

3. livenessProbe

  • ハングしたら再起動
  • ただし過敏にしない（false positive で再起動→SLA低下）

Payara では MicroProfile Health を使った
/health/ready /health/live
がベストです。

5. Kubernetes での可用化に必須の K8s リソース

Deployment（replicas 2+）

  • Kubernetes が自動復旧
  • RollingUpdateで無停止に近いデプロイ

Service（ClusterIP）

  • Ingress からアプリを安定して参照するための内部固定ポイント

Ingress（Nginx / OCI Native Ingress）

  • ロードバランシング
  • SSL終端
  • パス/ホスト単位のルーティング

PodDisruptionBudget（PDB）

  • ノードメンテ時に「全部のPodが同時に落ちる」事故を防ぐ

6. OCI環境なら Workload Identity は必ず検討

OCIでは、2024以降 Workload Identity が推奨です。

メリット

  • APIキーをPodに置かない（Secret不必要）
  • Kubernetesの serviceAccount を IAM とひも付け可能
  • Object Storage などを安全に叩ける

典型的な利用例

  • Payara アプリから OCI Object Storage へアップロード（PUT）
  • Pre-Authenticated Request（PAR）を発行
  • メタデータ更新

APIキー方式よりも安全で運用負荷が低いので 強く推奨 です。

7. DB は Kubernetes の外で管理するのが現実的

業務システムでは DB の可用性が重要ですが、KubernetesにDBを載せると「ストレージHA」「フェイルオーバー」「スナップショット」「チューニング」を自前でやる必要があります。

そのため、以下が実務では定石です：

  • DBはマネージド（または既存のHA構成）
  • アプリ層だけ Kubernetes 化して可用性を高める

Kubernetes の可用性は “アプリ層のセルフヒーリング＋スケールアウト” が中心です。

8. Payara ServerをDocker化するときの注意点

  • domain ディレクトリは不変に
  • postboot.asadmin / preboot.asadmin に設定反映を集約
  • JVM オプションも環境変数化（ConfigMap / Secret）
  • ログは 標準出力へ（K8sログ収集と相性が良い）
  • ローカルファイル保存は禁止（temporary用途なら emptyDir のみ）

まとめ：業務システムを Kubernetes 化するなら「ステートレス化」が成功の鍵

Payara Server の業務システムを OKE（Kubernetes）で可用化するとき、最も重要なのは アプリを“Kubernetesにお任せできる状態”にすることです。

ポイントを整理すると…

  • Payara Server は 独立Pod として動かす（DASは使わない）
  • セッションは外部化 or JWT化
  • ファイルアップロードは Object Storage または FSSを使用
  • Probe（startup / readiness / liveness）設計は必須
  • 設定値は ConfigMap/Secret に分離
  • DBは無理にK8sへ入れず、外部のHA構成を利用
  • OCIなら Workload Identity で Object Storage に安全アクセス

これらを押さえることで、高可用・低運用負荷の Jakarta EE（Payara）アプリケーション基盤が実現できます。