デプロイパス

OpenLM Platform のデプロイ先を選ぶには、4 つのデプロイパスを比較します。各パスによって、Kubernetes をどこで動かすか、インフラサービスをどう用意するか、そして何を自社で管理するかが決まります。背景については、アーキテクチャ、システム要件、ネットワークを参照してください。

デプロイパスの比較

次の表に、4 つのパスとそれぞれが使うものを示します。

パス	Kubernetes	インフラサービス	向いているケース
Platform as VM	K3s（自動構成）	単一 VM 上ですべて自動構成	小規模顧客、デモ、概念実証（PoC）、評価環境
オンプレミスマシン	自社サーバー上の任意の Cloud Native Computing Foundation（CNCF）準拠ディストリビューション	すべてクラスタ内で self-hosted	既存データセンターと Kubernetes 運用経験を持つ組織
プライベートクラウド (AWS)	Amazon EKS（マネージド）	AWS マネージドサービス、クラスタ内チャート、またはその組み合わせ	AWS を利用している組織、または既存データセンターを持たない組織
プライベートクラウド (Azure)	Azure AKS（マネージド）	Azure マネージドとクラスタ内構成の混在	Azure を利用している組織

:::tip 推奨 既存のデータセンターや専任のインフラチームがない場合は、クラウドプロバイダー上へのデプロイを推奨します。クラウド管理型の Kubernetes とデータサービスにより、運用負荷を大きく下げられます。

AWS は、もっともサポートが厚いクラウドパスです。RDS、MSK、ElastiCache といったマネージドサービスの対応範囲が広く、Terraform の参照構成もあり、OpenLM 内の導入実績も最も多い構成です。 :::

Platform as VM

小規模顧客、デモ、評価環境には、Platform as VM パスを使用します。単一のデプロイスクリプトで、クリーンな AlmaLinux 9、RHEL 9、または Rocky Linux 9 環境を、完全に動作する OpenLM Platform に変換します。Kubernetes やインフラの専門知識は不要です。

このスクリプトは、K3s のインストール、データベース（MariaDB、PostgreSQL、MongoDB）、Kafka、Redis、スキーマ初期化、OpenLM Platform サービスのデプロイまで自動化します。結果として、単一マシン上でそのまま利用できる環境が構築されます。

スクリプトがすべてを管理します。Kubernetes、すべてのデータベース、Kafka、Redis、MongoDB、スキーマ作成、Kafka トピック、OpenLM Platform サービスが対象です。

お客様は、AlmaLinux 9、RHEL 9、または Rocky Linux 9 を実行する VM またはベアメタルサーバー、ドメイン名、TLS 証明書を用意します。AlmaLinux 9 が実際に検証されている構成です。RHEL 系の 8 および 10、ならびに Ubuntu、Debian、SUSE はサポートされません。

次の表に、最小リソースと推奨リソースを示します。

リソース	最小（評価用）	推奨
CPU	4 コア	8 コア以上
RAM	32 GB	64 GB
ストレージ	空き容量 200 GB の SSD	500 GB 以上の SSD

注意

このパスは、スケーラビリティよりもシンプルさを優先します。すべてのサービスが単一マシンを共有するため、処理できる負荷には現実的な上限があります。単一 VM の容量を超える場合は、下記のマルチノード構成への移行を検討してください。

詳細な要件は Platform as VM requirements を参照してください。

導入手順は Platform as VM deployment を参照してください。

オンプレミスマシン

オンプレミスパスでは、すべてをお客様が管理するベアメタルサーバーまたは仮想マシン上で動かします。Kubernetes とすべてのインフラサービスは自社ハードウェア上にインストールされます。

お客様がすべてを管理します。サーバー、OS、Kubernetes、データベース、Kafka、Redis、MongoDB、ネットワーク、証明書が対象です。

このパスでは、Kubernetes と Linux 運用の経験を持つチームが必要です。すべてのインフラサービスは、専用の infrastructure ノード上でクラスタ内実行されます。

次の表に、サービスごとの構成を示します。

サービス	構成
SQL データベース	SQL Server、または MariaDB または MySQL と PostgreSQL（クラスタ内）
Kafka	クラスタ内
Redis	クラスタ内
MongoDB	クラスタ内

Red Hat OpenShift では、Kubernetes を自分でインストールする必要はありません。このパスと異なる設定については Red Hat OpenShift を参照してください。

詳細なハードウェア要件は On-premises machines requirements を参照してください。

導入手順は On-premises machines environment setup を参照してください。

プライベートクラウド (AWS)

AWS パスでは、Kubernetes に Amazon EKS を利用し、必要に応じてインフラコンポーネントを AWS のマネージドサービスで構成します。自社の AWS アカウント内で完結させつつ、運用の負担を減らせます。OpenLM Platform が必要とするのは SQL Server、Kafka、Redis、MongoDB のエンドポイントだけなので、いずれもデプロイパッケージのチャートを使ってクラスタ内で実行できます。Kafka には Amazon MSK を使用してください。Amazon MSK を利用できない組織では、オンプレミスパスと同じクラスタ内 Kafka を実行してください。

AWS は、Kubernetes control plane、SQL Server（RDS）、Kafka（MSK）、Valkey（ElastiCache）を管理できます。

引き続きお客様が管理するのは、AWS アカウント、ネットワークと仮想プライベートクラウド（VPC）、EKS node groups、MongoDB（Atlas またはクラスタ内）、およびマネージドサービスの代わりにクラスタ内で実行するすべてのサービスです。

次の表に、サービスごとの構成と状態を示します。

サービス	構成	状態
SQL データベース	Amazon RDS for SQL Server	サポート済み
Kafka	Amazon MSK（推奨）、またはデプロイパッケージによるクラスタ内 Kafka	サポート済み。MSK の場合は、インストールガイドで扱っていない SASL/SCRAM の接続設定を OpenLM へお問い合わせください。
Redis	Amazon ElastiCache for Valkey	サポート済み
MongoDB	MongoDB Atlas またはクラスタ内	サポート済み（DocumentDB は未サポート）

AWS 環境全体（VPC、EKS、RDS、MSK、ElastiCache、KMS、IAM）を infrastructure-as-code で構築するための Terraform 参照構成が用意されています。この構成は常に MSK を作成するため、Kafka をクラスタ内で実行する場合はその部分を除外してください。

詳細なサイジングとコストは AWS infrastructure requirements を参照してください。

導入手順は AWS environment setup を参照してください。

プライベートクラウド (Azure)

Azure パスでは、Kubernetes に AKS を利用し、SQL とキャッシュにはマネージドサービスを利用します。Kafka と MongoDB はクラスタ内、またはサードパーティのマネージドサービスとして実行します。

Azure は、Kubernetes control plane、SQL データベース（SQL Managed Instance）、Redis（Azure Cache）を管理できます。

引き続きお客様が管理するのは、Azure subscription、ネットワークと仮想ネットワーク（VNet）、AKS node pools、Kafka、MongoDB です。

次の表に、サービスごとの構成と状態を示します。

サービス	構成	状態
SQL データベース	Azure SQL Managed Instance	サポート済み
Redis	Azure Cache for Redis	サポート済み
Kafka	Confluent Cloud またはクラスタ内	Event Hubs の Kafka レイヤーは未サポート
MongoDB	MongoDB Atlas またはクラスタ内	Cosmos DB は未サポート

Kafka と MongoDB は、Azure subscription 経由で課金される marketplace 提供サービス（Confluent Cloud、MongoDB Atlas）として用意することも、付属の Helm チャートで Kubernetes クラスタ内にデプロイすることもできます。

詳細なサイジングは Azure infrastructure requirements を参照してください。

導入手順は Azure environment setup を参照してください。

SQL データベースの選択肢

デプロイパスにかかわらず、SQL レイヤーは 2 つの方法で構成できます。

• Option A、単一の SQL Server インスタンス: 運用、identity、reporting のすべてを 1 つの SQL Server で構成します。
• Option B、MariaDB または MySQL と PostgreSQL: 運用・identity に MariaDB または MySQL を使い、reporting に PostgreSQL を使います。

Option B があるのは、次のエンジンの制限によるものです。

• 運用系サービスは MariaDB、MySQL、SQL Server をサポートしている。
• reporting engine（Spark ETL）は SQL Server または PostgreSQL のみをサポートしている。

既存のデータベース運用経験やライセンス条件に応じて選択してください。