OpenShift上でのLLMのアーキテクチャ設計：SCCとハイブリッドIDの解決

エンタープライズアーキテクトは、 Red Hat OpenShiftにデプロイする際の現実を知っています。標準的なマニフェストをkubectl applyするだけでは済まないことを知っています。オンプレミスで実行する場合でも、 IBM Cloud Satellite、Azure Red Hat OpenShift (ARO)経由で実行する場合でも、セキュリティプリミティブ、特にセキュリティコンテキスト制約（SCC）は、標準的なアップストリームKubernetesデプロイメントを即座に中断させます。

TrueFoundryはオーケストレーションオーバーレイとして機能します。私たちは開発者エクスペリエンスをインフラストラクチャの複雑さから切り離し、Red Hatエコシステムの厳格な境界を遵守しながらLLMをデプロイできるようにします。この記事では、OpenShiftのネットワーキング、 IBM Cloud IAM、および watsonx.aiとの統合方法を詳しく説明します。

デプロイメントモデル：スプリットプレーンアーキテクチャ

データレジデンシー要件を満たすために、スプリットプレーンアーキテクチャを使用しています。お客様は厳密に コンピュートプレーンを制御し、私たちはメタデータを コントロールプレーンで管理します。

1. コントロールプレーン（SaaSまたはVPC）： ID管理、モデルカタログ、ジョブスケジューリングを処理します。
2. 演算プレーン（お客様のクラスター）： TrueFoundryエージェントは、お客様の Red Hat OpenShift Container Platform上で直接動作します。

エージェントは、コントロールプレーンへのアウトバウンド専用WebSocket接続を開始します。インバウンドのファイアウォールポートを開く必要はありません。これにより、金融およびヘルスケア分野で一般的なエアギャップ環境や高セキュリティ要件を満たします。

図1：TrueFoundryは、ローカルの演算プレーン内で動作し、セキュアな境界を尊重します。

セキュリティ：SCCとRBACの自動化

OpenShiftにおける課題は、 セキュリティコンテキスト制約（SCC）の適用です。アップストリームのKubernetesとは異なり、OpenShiftは、デフォルトでPodがrootとして実行されたり、ホストパスにアクセスしたりすることを防ぎます。

Restricted-v2への対応

TrueFoundryエージェントは、restricted-v2 SCC内で動作するように設計されています。

• UIDの注入： ユーザーIDをハードコードすることはありません。エージェントは、名前空間に注釈付けされたUID範囲を検出し、実行時に正しいrunAsUser IDを推論Podのスペックに動的に注入します。
• ボリュームの抽象化： ホストパスの要件を回避するため、永続ボリューム要求（PVC）を、 IBM Cloud Block Storage または vSphere CSI でバックアップして、オンプレミス環境向けに利用します。

IDフェデレーション: IBM Cloud IAM

シークレットにハードコードされた認証情報はセキュリティリスクです。IBM Cloudへのデプロイメントでは、IDフェデレーションを使用して IBM Cloud Trusted Profilesを実装しています。

これにより、OpenShiftワークロードは動的なIDを仮定できます。ポッドはローカライズされたサービスアカウントトークンをIBM Cloud IAMトークンと交換し、一時的に IBM Cloud Object Storage (COS) または IBM Key Protectへのアクセスを許可します。

図2: Trusted Profilesを利用して静的な長期認証情報を排除する認証フロー。

ネットワーク: OpenShift Routesとの統合

標準的なKubernetes Ingressリソースは、Red Hat環境では変換が必要となることがよくあります。TrueFoundryは、 OpenShift Ingress Controller (HAProxy)と直接統合します。

• Ingress: モデルをデプロイすると、OpenShift Routeを自動的にプロビジョニングし、エッジでのSSL終端を処理します。
• エアギャップ環境でのエグレス: 切断された環境では、内部の Red Hat Quay レジストリからのイメージプルをサポートしています。内部のS3互換ストレージにモデルの重みを事前にキャッシュすることで、ランタイムのインターネット依存関係を排除できます。

コンピューティング：GPUスケジューリングとWatsonx.ai

当社は以下と連携します NVIDIA GPU Operator ハードウェアアクセラレーションを処理するために。

MIGパーティショニング

A100またはH100クラスターの場合、当社は以下をサポートしています NVIDIA Multi-Instance GPU (MIG)。TrueFoundryスケジューラは、利用可能なMIGプロファイルを識別し、手動のアフィニティ設定なしでポッドを適切な論理パーティションに割り当てることで、ハードウェア利用密度を高めます。

統合ゲートウェイ

を使用しているチーム向けに IBM watsonx.ai、統合AIゲートウェイを提供します。

• プロトコル変換： 開発者は標準のOpenAI互換スキーマを使用します。ゲートウェイがwatsonx.ai APIへの変換を処理します。
• 統合テレメトリー： 当社は、セルフホスト型モデル（Llama 3、Mistral）とSaaSモデル（Granite、Watsonx）の両方へのリクエストを単一のペインにログ記録し、コストと監査の可観測性を確保します。

図3：ゲートウェイは、セルフホスト型ポッドとマネージドIBMサービス間のトラフィックを統合します。

運用上の比較

下の表は、ネイティブOpenShiftにTrueFoundryをオーバーレイした場合の具体的な運用上の変化の概要を示しています。

アーキテクチャの継続性

TrueFoundryをIBM CloudおよびRed Hat OpenShiftと統合することで、Red Hatエコシステムの厳格なコンプライアンス体制を維持しつつ、モデルのデプロイを加速させることができます。オンプレミスであろうとIBM Cloud上であろうと、OpenShift上でデータレジデンシーを維持し、エンジニアリングチームには基盤となるインフラストラクチャの制約を抽象化する統合インターフェースを提供します。

‍