はじめに レッドハットのソリューションアーキテクトの森です。 マルチクラウドやハイブリッドクラウド環境において、API管理やトラフィック制御は複雑化の一途を辿っています。Red Hat Connectivity Linkは、これらの課題を解決するための統合的なソリューションです。 本シリーズでは、Red Hat Connectivity Linkの基礎から実践的な使い方まで解説していきます。第1回となる今回は、Connectivity Linkの概要と、OpenShift Container Platform (OCP) へのインストール方法について説明します。 Red Hat Connectivity Linkとは Red Hat Connectivity Link は、マルチクラウドおよびハイブリッドクラウド環境における アプリケーション接続、ポリシー管理、API管理 のためのモジュール式で柔軟なソリューションです。 www.redhat.com 主な特徴 API、アプリケーション、インフラストラクチャの保護と接続 : セキュアな通信と柔軟な接続性を提供 標準ベースのアーキテクチャ : Kubernetes Gateway API標準に準拠 オープンソース基盤 : Kuadrantコミュニティプロジェクトをベースに開発 Service Mesh統合 : OpenShift Service Mesh 3 (Istioベース) をサポート 図1: Red Hat Connectivity Link アーキテクチャとPolicy APIs コアコンポーネント Connectivity Linkは、以下の主要コンポーネントで構成されています: Connectivity Link Operator（中央）: Kuadrant CRD、Certificate CRD、Limitador CRD、Authorino CRD、DNSRecord CRDを管理 Dependencies（依存関係）: Cert Manager : TLS証明書の自動管理 Limitador Operator : レート制限の実現 Authorino Operator : 認証・認可の実現 DNS Operator : DNSレコードとロードバランシングの管理 Policy APIs（右側）: AuthPolicy : Keycloakなどとの統合による認証・認可 DNSPolicy : クラウドDNSプロバイダー (AWS Route 53、Google Cloud DNS、Azure DNS) との統合 RateLimitPolicy : Redis互換データストア（またはインメモリ）を使用したレート制限。マルチクラスター環境での正確な分散レート制限にはRedis互換ストアが必須 TLSPolicy : cert-managerを使用した自動TLS証明書管理 前提条件 OpenShiftにConnectivity Linkをインストールする前に、以下の要件を満たしていることを確認してください。 必須コンポーネント / RHCL 1.3 コンポーネント バージョン / 要件 OpenShift Container Platform 4.19以降 OpenShift Service Mesh 3.2以降 cert-manager Operator for Red Hat OpenShift 1.18以降 access.redhat.com 注 : Red Hat Connectivity Link を利用するには、別途Subscriptionが必要です。詳細は弊社営業までお問い合わせください。 オプショナルコンポーネント 用途に応じて、以下のコンポーネントも準備してください: DNSPolicy用 : AWS Route 53、Google Cloud DNS、またはAzure DNSアカウントとホストゾーン RateLimitPolicy用 : Redis互換データストア (Redis、AWS ElastiCache、Dragonfly、Valkeyなど)。単一クラスター環境ではインメモリモードも利用可能ですが、マルチクラスター環境での正確な分散レート制限には必須 AuthPolicy用 : Red Hat build of Keycloak (オプション) 観測性用 : ユーザーワークロード監視とリモートストレージシステム OpenShiftへのインストール Connectivity Linkは、OpenShift Web ConsoleまたはCLIを使用してインストールできます。ここでは両方の方法を紹介します。 方法1: Web Consoleを使用したインストール Web Consoleを使用すると、GUIから直感的にインストールできます。 図2: OpenShift Web Console - Operator Catalog画面 手順 1. OpenShift Web Consoleにログイン クラスター管理者権限でログインします 2. Operatorの検索 左側のナビゲーションメニューから Ecosystem > Software Catalog を選択 検索ボックスに「 Connectivity 」と入力 3. Operatorのインストール Red Hat Connectivity Link Operator を選択 情報を確認し、 Install をクリック 4. インストール設定 以下のように設定します: 設定項目 値 Update Channel stable Version 1.3.2 Installation mode All namespaces on the cluster (デフォルト) Installed namespace kuadrant-system Approval Strategy Automatic または Manual ※ 1.3.2 = 2026年4月時点の最新バージョン 注 : Installed namespaceは kuadrant-system を推奨します。存在しない場合は自動的に作成されます。 図3: Operatorインストール設定画面 5. インストールの実行 Install をクリック Operatorがインストールされるまで待機 6. Kuadrantカスタムリソースの作成 Ecosystem > Installed Operators を選択 Projectドロップダウンから kuadrant-system を選択 Red Hat Connectivity Link を選択 Kuadrant タブをクリック Create Kuadrant をクリック YAML定義を必要に応じて編集 (デフォルトのまま使用可能) Create をクリック 7. インストールの確認 Ecosystem > Installed Operators から、以下のOperatorがインストールされていることを確認: Red Hat Connectivity Link Operator Authorino Operator DNS Operator Limitador Operator 図4: インストール完了後のOperator一覧 8. Web Console Pluginの有効化 Connectivity LinkはOpenShift Web ConsoleにカスタムUIを提供するConsole Pluginを含んでいます。このPluginを有効化すると、Web ConsoleからGateway、HTTPRoute、各種Policyを視覚的に管理できるようになります。 手順: 左側のナビゲーションメニューから Home > Overview を選択 Status セクションの Dynamic Plugin status で、プラグインの状態を確認 View alerts または Dynamic Plugins リンクをクリック 図5: Dynamic Plugin Statusの確認 Console plugins ページで、 kuadrant-console-plugin を探す Enabled 列が Disabled になっている場合、 Disabled リンクをクリック 図6: Console Pluginsの一覧 Console plugin enablement ダイアログが表示されます Enable を選択 警告メッセージを確認（Pluginはログインユーザーとして任意のKubernetesコマンドを実行できる権限を持ちます） Save をクリック 図7: Console Pluginの有効化 重要 : Console Pluginを有効化した後、ブラウザのページをリフレッシュしてください。 Console Plugin有効化後の機能: ページをリフレッシュすると、左側のナビゲーションメニューに Connectivity Link セクションが追加されます。 図8: Console Plugin有効化後のConnectivity Link Overview 追加される機能: Connectivity Link Overview : Gatewayの統計情報やリソースリンク Policies : 各種Policyの一覧と管理 Policy Topology : ポリシー関係の視覚化 Networking メニューに Gateways 、 HTTPRoutes などの項目が追加 Gateway、HTTPRoute、各種PolicyをGUIから作成・編集・削除可能 リソースの状態を視覚的に確認 YAMLエディタでの直接編集も可能 方法2: CLIを使用したインストール コマンドラインからインストールする場合は、以下の手順に従います。 前提条件 OpenShift CLI ( oc ) がインストール済み クラスター管理者権限でログイン済み 手順 1. ネームスペースの作成 oc create ns kuadrant-system 注 : kuadrant-system は任意のネームスペース名に変更可能です。 2. Connectivity Linkのインストール 以下のコマンドを実行して、OperatorとOperatorGroupを作成します: oc apply -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: rhcl-operator namespace: kuadrant-system spec: channel: stable installPlanApproval: Automatic name: rhcl-operator source: redhat-operators sourceNamespace: openshift-marketplace --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: kuadrant namespace: kuadrant-system spec: {} EOF 注 : この設定では、Operatorはクラスター内のすべてのネームスペースを監視します（ All namespaces on the cluster モード）。特定のネームスペースのみを監視する必要がある場合は、 spec.targetNamespaces フィールドを使用してください。 3. Kuadrantカスタムリソースの作成 oc apply -f - <<EOF apiVersion: kuadrant.io/v1beta1 kind: Kuadrant metadata: name: kuadrant namespace: kuadrant-system EOF インストール後の確認 インストールが正常に完了したことを確認するために、以下のコマンドでPodの状態をチェックします: oc get pods -n kuadrant-system 以下のようなPodが実行されていることを確認してください: NAME READY STATUS authorino-operator-xxxxx 1/1 Running dns-operator-xxxxx 1/1 Running limitador-operator-xxxxx 1/1 Running kuadrant-operator-xxxxx 1/1 Running 図9: Pod確認コマンドの出力例 次のステップ Connectivity Linkのインストールが完了しました。次回の記事では、以下のトピックを扱う予定です: Gatewayの作成と設定 : Kubernetes Gateway APIを使用したゲートウェイの基本設定 HTTPRouteの定義 : アプリケーションへのルーティング設定 DNSPolicyの適用 : クラウドDNSプロバイダーとの統合 TLSPolicyの設定 : 自動TLS証明書管理の実現 まとめ 本記事では、Red Hat Connectivity Linkの概要と、OpenShift Container Platformへのインストール方法を解説しました。 本記事のポイント Connectivity Linkは、マルチクラウド/ハイブリッドクラウド環境でのAPI管理とポリシー制御を統合的に実現 Kubernetes Gateway API標準に準拠し、OpenShift Service Meshと統合 Web ConsoleまたはCLIから簡単にインストール可能 Authorino、DNS、Limitadorの3つの主要Operatorで構成 Connectivity Linkを使用することで、複雑なマルチクラウド環境においても、一貫性のあるAPI管理とトラフィック制御が可能になります。 次回は、実際にゲートウェイを作成し、ポリシーを適用する手順を詳しく見ていきます。 参考情報 OpenShift ServiceMesh 3、および Red Hat Connectivity Link のインストールについては、 下記リンクの場所にスクリプトがありますので、こちらも参考にしてください。 connectivity-link-blog/01-introduction_and_install at main · kamorisan/connectivity-link-blog · GitHub

こんにちは。レッドハットコンサルティングチームの木嶋です。 「アプリケーションモダナイゼーション(以下、モダナイゼーション)」について解説する連載は、とうとう最後の3つの “R” であるRepurchase, Retain, Retire を扱います。 なお、本連載における「6R」の全体像については、第1回の記事でご紹介しています。必要に応じてあわせてご参照ください。 rheb.hatenablog.com アプリケーションモダナイゼーションというと、システムを作り替える、クラウドへ移す、マイクロサービス化するといった「変える」話に注目が集まりがちです。 しかし、現実のITポートフォリオでは、すべてを同時に変えることはできません。重要なのは、何を変えるかだけでなく、何を標準に寄せ、何を今は維持し、何を止めるかを、ライフサイクルの中で継続的に見直すことです。 本記事では、6Rの中でも見過ごされがちな Repurchase / Retain / Retire を、「変えない」選択肢としてではなく、モダナイズの起点として捉え直します。 6Rの罠 Retain: あえて変えない理由を明確にする Repurchase: ランニングコストを低減する Retire: 止めるために棚卸しする まとめ Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  6Rの罠 このシリーズで今までご紹介してきた “6R” は、 アプリケーションモダナイゼーションの議論で広く使われる整理軸です。 ただし実務で扱う際にはひとつ注意があります。 6Rを、今あるモノリス全体や分散システム全体に対して一括で当てはめると、判断が粗くなりやすいのです。 実際のシステムには、変更頻度が高く開発スピードを求められる領域、慎重な運用が必要な領域、すでにほとんど手を入れない領域が混在しています。 さらに、「アプリケーション共通機能」という名前の下に、現在ならインフラレイヤーや基盤側で担うべき機能まで抱え込んでいることも少なくありません。こうした異なる性質の要素をまとめて評価すると、結論は往々にして Retain に寄ってしまいます。 こうした粗い判断のしわ寄せが、ビジネス部門側が施策を諦めることで吸収することも珍しくありません。 古いシステムであればあるほど、IT側が遅いから諦めた施策がたくさんあるのです。 このような問題を避けるため、6R の判断は、システム全体ではなく、サブドメイン単位あるいはコンポーネント単位で行うべきです。 「サブドメイン」でピンとこない方は、「業務的な意味づけを持つ機能のかたまり」と捉えていただければ、本稿では十分です。 このように評価粒度を下げて考えると、これまで脇役に見えがちだった Repurchase / Retain / Retire は消極策ではなく、モダナイズを進めるための重要な戦略的起点になります。 Retain: あえて変えない理由を明確にする 本連載1回目で、Retainは以下の通りご紹介しました。 現時点では十分に機能しており、他システムと密に連携しているなどの理由から、あえて変更せずに現状維持する選択です。将来的な移行対象として棚上げする場合も含まれます。 Retain は、単に「今は変えない」という結論ではありません。 Retainと判断したものについて重要なのは、定期的に見直すことと、なぜ変えないかを都度確認することです。 6R の判断は、ビジネス状況やシステムを取り巻く制約の変化によって、最適な選択肢が変わり得ます。つまり、一度決めた Retain は永続的な判断ではありません。 実際にお客様のお話を伺うと、Retain が選ばれている理由は大きく2つあります。 スパゲッティ化して複雑であり、変更リスクが高いため、投資対効果を説明しにくい 利用者が少ない、あるいは業務変化が乏しく、投資するメリットが小さい 前者はいわば消極的なRetainです。 本来は変えたい、あるいは変える価値があるかもしれないものの、安全に変える方法が見つかっておらず、結果として Retain になっている状態です。 こうした Retain から脱出するヒントは、この連載の中でも共有してきましたので、ぜひ活用してください。 一方、後者は 積極的な Retain です。 現時点の利用実態や変化の少なさを踏まえたうえで、あえて投資しないと判断しているのであれば、それは十分に戦略的な選択だといえます。 重要なのは、Retain というラベルそのものではなく、なぜそう判断したのかを説明できること、そしてそれが組織のビジネス状況と合致していることです。 Repurchase: ランニングコストを低減する 最近は、AIによるコード生成の登場を受けて、「SaaSの時代は終わるのではないか」といった議論も見かけます。 たしかに「なんでも SaaS にすればいい」という時代は終わったのかもしれませんが、だからといって「なんでも自前で開発すればいい」という話でもないのです。 長年の作り込みによって複雑化した領域ほど、業務上の固有性と、単なる過去の都合による作り込みが混在しています。 例えば実際のシステム調査の現場では、Excel で管理していた時代の業務運用が、そのままシステムのデータモデルに焼き付いているケースをよく目にします。 こうした「Excel 由来データモデル」は、現在の業務要件やシステム実装に必ずしも適しているとは限りません。もともとは、表計算ソフトの表現力や機能制約の中で業務を成立させるための形だったはずだからです。 それにもかかわらず、その構造を前提にビジネスロジックが積み上がり、さらにその非効率を補うための機能が追加されることで、元の業務表現はプラットフォームを変えても踏襲され、結果としてスパゲッティ状態が形成されていきます。 こうした構造に対して有効なのが、Repurchase を通じた Fit to Standard です。 標準機能に寄せていく過程で、本当に必要な業務要件と、過去の運用都合を引きずっただけの作り込みを切り分けやすくなるからです。 ただし、そこには落とし穴があります。 Fit to Standard は、決して平坦な道ではない ということです。 複雑化した業務を標準 に乗せるということは、現在の運用や実装の中に埋もれてしまった業務の存在意義や意図をいったん取り出し、蒸留し、それを標準の中に再構成することを意味します。 ここで安易に機能追加へ逃げると、Repurchase のはずが、結局は新しい土台の上に古い複雑さを載せ替えるだけになってしまいます。 その先にあるのは、アップグレードコストの増加です。 最近のパッケージやSaaSはアップグレード頻度も高く、作り込み部分に対してテストを実施し、壊れた箇所を修正するための時間を毎回十分に確保することは容易ではありません。 その結果、作り込みが多いほどアップグレードコストは積み上がりやすくなります。 Repurchase の成否は、導入時の機能充足率ではなく、将来のアップグレード容易性をどこまで守れるかで決まると言ってもよいでしょう。 もちろん、どれだけ丁寧に見直しを重ねても、パッケージや SaaS だけで必要な機能がすべて充足することは、実際にはほとんどありません。 その場合に重要なのは、不足分を安易に本体へ作り込まないことです。必要な固有機能は、可能な限りパッケージや SaaS の外側に切り出して実装する。その方が、本体の標準性を守りながら、将来の変更自由度も確保できます。 難しそうに見えるマイクロサービス化も、必ずしも最初から大がかりに進める必要はありません。こうした小さな切り出しが、その第一歩になることもあります。 Retire: 止めるために棚卸しする IT効率化の最前線がITILだった時代に、講演会でこんなエピソードを聞いた記憶があります。 データセンターを使い始めてから数年後、初めてサーバーの棚卸しをしたところ、3分の1 がすでに使われていないサーバーだったというのです。 サーバーは、使っているかどうかにかかわらず、データセンター費用や電気代がかかります。 こうした問題は、物理サーバーに限りません。 仮想化基盤上のシステムやクラウド上のアプリケーションであっても、似たようなことが起こります。 例えば運用や保守にかかる人件費は、ユーザーが使っているかどうかに関わらず発生します。こういったコストは見えにくいまま大きなコストとして積み上がっていきます。 最後にアプリケーション全体の棚卸しをしたのはいつでしょうか。また、その時には必要と言い切れるシステムばかりでしたか？ もちろん、その判断には利用実態や依存関係の確認が欠かせません。 実際には、リタイアを検討すべきほど利用者が少ないにもかかわらず、説明責任や移行先の検討が面倒で、結果として Retain が選ばれてきたシステムもあるはずです。 しかし、確認しないまま残し続けることもまた、ひとつの高コストな意思決定です。 Retire の価値は、単に古いものを減らすことではありません。価値を生んでいない資産に払い続けているコストを止め、その分を本当に必要なモダナイズ投資へ振り向ける、いわば軍資金を確保することにあります。 Retire は、止める判断そのものよりも、「本当に残す理由があるのか」を問い直す行為だと言ってもよいでしょう。 まとめ Repurchase / Retain / Retire は、それ自体が独立した戦略判断であると同時に、Replatform / Refactor を含むモダナイズ投資にどれだけ健全に資源を振り向けられるかを左右する前提条件でもあります。 残すべきもの、標準に寄せるべきもの、止めるべきものが整理されていなければ、本当に変えるべき領域への予算配分はどうしても偏りやすいのです。 こうした投資配分の健全性は、Repurchase / Retain / Retire の判断を一度行っただけでは担保できません。ビジネス状況や利用実態、依存関係は変化し続けるからです。こうした棚卸しと再評価を継続的に行う仕組みは、すでに「アプリケーションポートフォリオ管理」という名前で体系化されています。どのようにサイクルとして回していくか、といった実践のヒントに関心がある方は、この領域もあわせて参照するとよいでしょう。 一方で、そのサイクルの中でどのような判断を行うべきかは、全体最適を見据えたアーキテクチャ上の意思決定と深く結びついています。どこを標準化し、どこに固有性を残し、将来の変更に耐えられる構造をどう維持するか。これはまさに設計の問題であり、われわれエンジニアにとっても避けて通れないテーマです。 変えることだけでなく、残す、買う、止めるを見直し続けることもまた、アプリケーションモダナイゼーション の重要な実践なのです。 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？  Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」  ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。  www.redhat.com

RHELのスペシャリストソリューションアーキテクトの田中司恩( @tnk4on )です。 この記事は Red Hat Blog の Navigating the Mythos-haunted world of platform security を、許可を受けて翻訳したものです。 2026年4月28日追記: MythosおよびProject Glasswingによって発見された脆弱性に対するRed Hatの分析・対応状況は、 Navigating Mythos and Project Glasswing Findings のナレッジにまとめられています。 Claude Mythosのプレビュー版の登場は、ITセキュリティの専門家にとって大きな課題であると同時に、（それを導入できる組織にとっては）一つの好機でもあります。Mythosは、レガシーコードに潜む複雑なメモリ安全性や論理的な欠陥を特定できるだけでなく、それらをますます巧妙な手法で悪用することさえ可能な、新しいカテゴリーのフロンティアモデルです。 これにより、企業内のITセキュリティチームやオープンソースコミュニティにおいてAI駆動の脆弱性スキャンが担っている突出した役割が、劇的に強化・拡大されることになります。しかし、Mythosがもたらすのは単なるAIによる脆弱性レポートの洪水ではありません。それはサイバー攻撃を工業化する可能性を秘めた道筋であり、高度なバグ調査や関連する脆弱性の連鎖攻撃への参入障壁を下げる存在です。我々業界は、この変化に対してパニックで反応すべきではありません。むしろ、コンテキスト（文脈）とスキル、そして最終的には我々自身がAIを活用することを通じて、システムの回復力を強化する必要があるのです。 マシンの中のゴースト 悪意のある攻撃者がどのようにMythosを悪用する可能性があるか議論する前に、この新時代の最初の課題はS/N比（シグナル対ノイズ比）の急激な変化です。Mythos以前のAIエージェントであっても、コード内の膨大な潜在的問題を特定することは可能でしたが、発見は戦いの半分に過ぎません。残りの半分は、これらのバグを大規模に検証し、緩和し、最終的に修正するプロセスです。 これらは実際の脅威か？ どうやって優先順位（トリアージ）をつけるか？ どうやって修正するか？ 例えば、2025年後半から2026年前半にかけて、AISLEの自律型AIシステムが OpenSSLとcurlの内部で複数のセキュリティ脆弱性を発見 しました。さらに最近では、2026年4月3日にAnthropicの研究者がClaude Code（Opus）を使用して、 Linuxカーネルに23年間潜んでいた脆弱性（合計5つの潜在的なCVE）を発見 しました。これは「脆弱性発見のためのAI時代」の到来を告げる出来事です。 額面通りに受け取れば、これは恐ろしいバグの山のように聞こえます。しかし、この脆弱性発見モードにはS/N比という課題が存在します。我々の見解では、実際に悪用可能で本番環境に影響を与える真の脆弱性を発見する唯一の方法は、継続的な監視と実際のコード精査しかありません。 コンテキスト（文脈）こそがすべて Red Hat Product Security は、Claude Codeのスキャンによって提示された5つの潜在的問題を評価しました。これは単なる証明のためではなく、我々のチームが常に脆弱性を監視、分析、追跡、トリアージしているという業務の一環であり、Red Hatサブスクリプションの価値を如実に示す例です。 以下は、これらのLinuxカーネルの脆弱性がもたらすリスクについての初期評価です： NFSDのヒープオーバーフロー修正 : これはNFSプロトコルの実装問題であり、根本的な問題は、確保された小さなスペースにそれより大きなバッファを書き込もうとすることです。この脆弱性はカーネルのNFSデーモン内にあり、ユーザー空間のセキュリティアーキテクチャとは異なるため、SELinuxのような制御は適用されません。このサービスはデフォルトでは内部ネットワークの外側に公開されていないため、悪用の実際のリスクは大幅に低くなります。最悪のシナリオではnfsdがクラッシュし、サービス拒否（DoS）につながります。Red Hatの製品エコシステム内では、このバグは現状「Low（低）」リスクと見なされますが、さらなる攻撃ベクトルが発見されれば「Moderate（中）」に評価される可能性があります。 IO_URING SQE_MIXEDのラップチェック : このカーネルバグから、重大な悪用につながる可能性はありません。根本的な欠陥は、破損したSQE（送信クエリエントリー）の判定が誤っていることであり、悪用された場合の最悪のシナリオは、下流のSQEエラーによるシステム不安定化です。これはセキュリティ問題というよりも、機能または安定性のバグです。さらに、このバグを悪用するために必要な混在型64b/128b SQEリングのサポートをRed Hat製品では提供していないため、Red Hat製品においてはCVEや機能バグとして扱われません。 Futex Requeueの問題 : このバグには間違いなくローカルアカウントが必要であり、特権アカウントが必要かどうかを判断するにはさらなる調査が必要です。元の報告ではuse-after-free（解放済みメモリの使用）のバグとされていますが、文脈から判断すると、その「use-after-free」のシナリオをどのように引き起こすのかは不明確です。Red Hat製品において、私たちはこの問題をModerate（中）のバグと評価します。主な理由は、悪用に成功するための前提条件が複雑であるためです。最悪の場合、悪用によってカーネルパニックを引き起こす可能性がありますが、現時点で判明している情報に基づくと、リモートコード実行は不可能です。 KSMBD Share_Confのuse-after-freeの問題 : この問題をネットワーク経由で悪用することに成功すればカーネルパニックを引き起こせますが、デフォルトではこのカーネルデーモンへのアクセスは内部ネットワークに限定されています。さらに、解放後にアクセスされるデータは、ユーザーが意味のある形で制御できるものではないため、システムが不安定になる以上の悪用価値や影響は低下します。この状況を考慮し、Red Hat製品ではこれをModerate（中）のCVEとして分類します。 KSMBDのsmb_direct_prepare_negotiationにおける符号の問題 : これはNFSのヒープオーバーフロー修正バグと同様で、攻撃者は悪意のあるデータかどうかにかかわらず、データを送信する前に認証を完了させる必要があります。潜在的な悪用につながる可能性のある事態を防ぐため、私たちは、ユーザーが信頼できるエンティティと見なされる場合を除き、カーネル内でのネットワークファイル共有を使用しないことを強く推奨します。Red Hat製品において、デフォルトの設定ではKASLRなどの保護機能が有効となっており、脆弱なコードが存在する場合でもこのバグの影響は低減されます。前提条件や基本構成を考慮し、私たちはこのバグを当社の製品エコシステムにおいてLow（低）の重大度と分類しています。 これらは明らかに5つの脆弱性に過ぎませんが、私たちはAIがソフトウェアサプライチェーンの根幹において、このような欠陥の発見を飛躍的に加速させることを予想しています。特にMythosのような強力なフロンティアモデルを含むAIモデルの悪用と組み合わさることで、悪意のある攻撃者は未知の欠陥を発見し、さらには同じワークフローの中でそれを悪用することさえ可能になるでしょう。これらすべては壊滅的な事態のように思えますが、それは私たちが業界としてそれらから目を背けたり、その能力を過小評価したりした場合に限った話です。 Red Hatは、このようなAI駆動のコード監査の到来を見据えて備えていました。私たちはすでに、Red Hat Enterprise Linux（RHEL）の構築・保守方法の検証として、またプラットフォームを保護する方法を拡張する手段として、AIを用いた脆弱性発見を積極的に取り入れています。 AIの対抗策としてのAI 理想的な世界であれば、AIが数億行のコードをスキャンして複雑なバグを特定できる能力は、オープンソースコミュニティへの贈り物と見なされるはずです。なぜなら、それはオープンなコードをより多くの人の目でチェックできることを意味するからです。しかし、現実はそれほど単純ではありません。 発見は戦いの半分に過ぎません。AIスキャナーによって特定された膨大な数の潜在的なセキュリティバグのうち、ごく一部でも検証されれば、セキュリティの世界は激震に見舞われるでしょう。今や課題は「脆弱性の発見」から「それらを大規模に吸収し、修復すること」へと移行しています。AIが多くの潜在的な脆弱性を発見するのと同様に、Red HatはAIツールを活用してそれらの脆弱性を迅速かつ正確にトリアージし、この急激な変化によって生じるS/N比の問題を改善しようと努めています。 AIエージェントがアップストリームのLinuxカーネルで問題を発見すると、すべてのディストリビューションが何らかの形で影響を受けます。その違いは、オペレーティングシステムを支えるインフラストラクチャにあります。つまり、専門家、プロセス、そして脆弱性が発見された際に対処する姿勢です。Red Hatは何十年にもわたってこれを行ってきており、AI主導による発見の波に対しても本質的な優位性を持っています。 制限のない反応ではなく、コンテキストこそが、Red HatがAIによる脆弱性スキャンやMythosのような最も高度なAIモデルによってもたらされるリスクに対処する際の方針を定義しています： コンテキストがバグを無力化する：RHELの標準構成に含まれるASLRやSELinuxのような機能は、脆弱なコードであっても、本番環境において意味のある攻撃を成功させることを困難にします。 機能性とセキュリティ：AIが特定した脆弱性の中には、実際には攻撃経路が存在せず、単なる機能上の不具合に過ぎないものも含まれています。 運用の現実：NFSプロトコルに見られるような多くの問題は、Red Hatの製品エコシステム内ではLow（低）リスクと見なされます。なぜなら、適切なセキュリティアーキテクチャが構築されていれば、影響を受けるデーモンがインターネットにさらされることはほとんどないからです。 攻撃が横行する闇を照らす光 AIが加速する世界において、堅牢なプラットフォームと脆弱なプラットフォームを分かつものは、OSの背後にあるインフラストラクチャです。ここに、Red Hat Enterprise Linux（RHEL）サブスクリプションの真価があります。 Claude Mythosが脆弱性を連鎖させて攻撃コードを作成できる一方で、RHELは以下を通じて進化し続ける防波堤を提供します： 先を見越したキュレーション：当社のProduct Securityチームは、単にコードをパッケージ化するだけではありません。アップストリームの研究開発に深く関与し、トリアージ、検証、そして修正パッチのバックポートを行っています。 インテリジェントなツール群：私たちは安全なソフトウェアサプライチェーンの原則に基づいた自動化ワークフローを用い、AIにはAIで対抗しています。また、Red Hat Lightspeedのようなツールを通じて、新たな脆弱性が発見された際にハイブリッドクラウド全体で修復の優先順位付けができるよう、社内の専門知識を顧客に提供しています。 時代を越えた専門性：Red HatはすでにAIツールを導入し、独自の知見をエージェントに統合することで、Mythosのような次世代モデルがもたらす潜在的な問題に対して一歩先んじています。RHELのクローン版を含む他のディストリビューションとは異なり、当社は独立したセキュリティ研究能力と、アップストリームプロジェクトに対する深い専門性を維持しており、膨大な量の課題に対応可能です。AI主導の現代において、アップストリームからの修正が下流で再パッケージされるのを待つことは、ビジネスにとって明確なリスクの空白期間を生み出します。 AIの嵐に対するレジリエンス Mythosの登場は、オープンソースの基盤が崩壊しつつあることを意味するのではなく、プラットフォーム保守の基準が引き上げられたことを意味します。Red Hatはこの変化を見据えて備えており、セキュリティ修復にAIを活用する以上の対策を講じています。 RHELのサブスクリプション は、単なるソフトウェアの提供にとどまりません。それは現代の脅威のスピードに対するダイナミックな対応です。社内の専門知識を通じたコンテキストは、実際の リスク 評価と密接に関係しています。AIスキャンによって発見された問題を、それがあなたの環境にとってほとんど懸念がないものであっても、すべて修正すべきでしょうか？何千ものバグが見つかったとしても、実際に悪用可能な脆弱性がごくわずかであれば、優先順位付けとトリアージこそが重要になります。 Red Hatの製品エコシステムにおいて、今回新たに発見されたバグのほとんどは、サービスに影響を与えるような問題を引き起こすことはありません。厄介ではありますが、ビジネスを破壊するようなものではありません。 私たちは、Linuxコミュニティにおける新たな規範と標準にコミットしています。自動化ツールとAIを活用した独自のスキルを駆使し、オープンソース全体およびLinuxの強力なセキュリティ体制を維持する道をリードしていきます。オープンソースはイノベーションの出発点であり、私たちはこの強固な基盤を守り続ける決意です。

Red Hat Learning Subscriptionが変える、組織のスキル戦略 〜 1回の研修で終わらせない、1年間のオールインワン成長プラットフォームとは 〜 皆さんこんにちは Red Hat Global Learning ServicesでLearning Solution Architectを担当している坂井 大和( @lab8010 )です。 今回は、私が日々お客様とお話する中でよく聞かれる「どうすればエンジニアのスキルが現場で定着するのか？」という問いに対して、一つの答えを提示できればと思い、筆を執りました。 まず最初にお伝えしたいことは「 Red Hatの教育サービスは、他社とは大きく考え方が違う 」ということです。 多くの企業が提供する 一般的な技術トレーニングは受講して終わりといういわゆる一期一会のようなサービス だと言えます。 しかし、 Red Hatの教育サービスは「お客様の組織、人をモダナイズするサービス」 であり、その中の1つの提供内容として講師によるトレーニングが存在しています。 AIの活用が当たり前となってきた現代においても、またどれだけ優れたITインフラを揃えたとしても、それらを活用して価値を生み出すのは私たち人間です。 本記事では、これ以降Red Hatが考える教育サービスの形や特徴などについてお話をしていきたいと思います。 ※なお、昨今のトレンドに乗じて一部の画像についてはAIを活用して作成してみました。 はじめに：「システムのモダナイズ」だけでは足りない 課題：「数日間の研修」が抱える本質的な問題 「トレーニングに参加させること」がゴールになっていませんか？ 解決策：Red Hat Learning Subscription とは？ プラン比較 これが他とは一線を画す：5つの差別化ポイント 1. 「いつでも学べる」継続的な学習環境 2. 「試験に強い」圧倒的な受験サポート 3. 「書店では買えない」Red Hat公式学習教材をPDF・EPUBで入手できる 4. 「実機で磨く」1年間アクセス可能なハンズオンラボ 5. RHLS CourseとPremiumにはインストラクター主導のバーチャルライブクラスも含まれる コスト試算：3コース以上で元が取れる 「1人で受けて終わり」ではなく「組織の投資」として まとめ：People Modernization の時代へ はじめに：「システムのモダナイズ」だけでは足りない RHEL、Ansible、OpenShiftなどはじめとし、近年ではRed Hatのポートフォリオはますます進化し、お客様の環境もどんどんモダナイズされています。 しかし、ここで一つ重要な問いかけをしたいと思います。 「システムはモダナイズされたけれど、それを動かす人のスキルはどうですか？」 コンテナ、Kubernetes、Infrastructure as Code、GitOps——これらを本当の意味で使いこなせるエンジニアが社内にいなければ、どんな最新インフラも宝の持ち腐れです。 私たちはこの問題に対し、人もまたモダンなインフラに対応できるようにモダン化(People Modernization)する必要があると考えます。 ビジネスの成功は、テクノロジーとそれを扱う 人の技術力 の両方が近代化されてはじめて実現するものであり、Red Hatでは製品に対してはコンサルティングサービス(GPS)、人に対してはラーニングサービス(GLS)という2つのサービスによってお客様の成功を支えます。 今回の記事では、GLSが提供する主力サービスであるRed Hat Learning Subscriptionについて解説していきます。 課題：「数日間の研修」が抱える本質的な問題 多くの企業で採用されてきた従来型のトレーニングといえば、こういう形です。 ある技術テーマに関する 1〜5日間の集中研修 を受講 研修期間中は意欲も高く、演習もこなせる 研修終了後、日常業務に戻ると…… 1〜2ヶ月で内容が薄れていく これはエンジニア個人の問題ではなく、学習の仕組みの問題です。 知識を 業務で使えるレベルまで定着させる には、繰り返しのアウトプットと、必要なときに立ち返れる環境が必要です。「研修で教えたのに使えていない」という声が出るのは、多くの場合この構造的な問題が背景にあります。 「1つのクラスを受けて、終わり」——他社の多くのトレーニングはこの形です。 受講者はその日・その週は理解できたように感じます。しかし1ヶ月後に現場で手を動かそうとしたとき、「あの設定ってどうやるんだっけ」と立ち往生してしまう。それでも学習環境にはもうアクセスできない、演習ラボも使えない。こういった場面に、私は何度も立ち会ってきました。 トレーニングを受けた直後から、すぐに現場で活躍できるでしょうか？ Red Hatが考えるトレーニングサービスのあり方は、ここが根本的に異なります。 1年間という長いスパンで、教育コンテンツ・演習ラボ・試験サポートを組み合わせながら、多角的にエンジニアの成長を支援し続ける ——これがRed Hatの答えです。受けて終わりにしない、それがRed Hat Learning Subscriptionの設計思想です。 また、資格試験についても同様の課題があります。「受験バウチャーを1枚だけ購入して不合格だった。追加バウチャーを買うか悩んでいる」という相談は、珍しくありません。受験が1回限りになっているため、心理的プレッシャーが高くなり、十分な準備ができないまま受験してしまうケースもあります。 「トレーニングに参加させること」がゴールになっていませんか？ 人材育成担当者やエンジニアを管理するマネージャーの中には、 本来の目的である「エンジニアが技術を身につけ、現場で活かすこと」 がいつの間にか薄れ、 「とにかくトレーニングに参加させること」自体がゴールになってしまっているケース を見受けます。 研修の予算を消化した、受講者数の目標を達成した——それ自体は悪いことではありませんが、その先にあるはずの「エンジニアが自信を持ってその技術領域に責任を持てるようになっているか」が問われなければ、投資の本来の意味が失われてしまいます。 Red Hatがラーニングサブスクリプションという形式にこだわるのは、まさにこの問題を解消するためです。 1年間というサイクルを通じて、エンジニアがその技術領域に対して責任を持てるよう、多角的な学習環境を継続的に提供する —— それがRed Hatの考える、あるべき人材育成の姿 です。 解決策：Red Hat Learning Subscription とは？ Red Hat Learning Subscription（RHLS） は、これらの課題を一挙に解決するために設計された、 1年間のサブスクリプション型学習プラットフォーム です。 「研修を受ける」のではなく、 「1年間、Red Hatのトレーニング環境を使い倒す」 というコンセプトです。 📎 参考： Red Hat ラーニングサブスクリプション プランは現在 Course・Standard・Premium の3種類が提供されており、それぞれの特長は以下の通りです。 プラン比較 RHLSのプラン比較、公式サイトからの引用 これが他とは一線を画す：5つの差別化ポイント 1. 「いつでも学べる」継続的な学習環境 Red Hatの学習サブスクリプションには、1年間のオンデマンドトレーニングと演習ラボ利用権 RHEL、OpenShift、Ansible、OpenStack……。特定のコースだけでなく、Red Hatのポートフォリオ全体をカバーするコンテンツを、自分のペースで、必要なタイミングで何度でも受講できます。「あのコマンドなんだったっけ」と思ったとき、すぐに手を動かしながら確認できる環境が1年間手元にあること——これは従来の研修にはない強みです。 2. 「試験に強い」圧倒的な受験サポート RHLS StandardとPremiumなら、5回分の各バウチャーが付与されます！ StandardおよびPremiumでは、 受験5回＋再受験5回 、合計最大10回の受験機会と試験準備ツールが含まれています。 一般的な受験バウチャーが1枚単位で有償購入となるのに比べると、この違いは歴然です。「1回で合格しなければ」というプレッシャーから解放されることで、十分に準備を重ねたうえで受験に臨めます。また、試験準備ツールが付属しているため、「自分がどこまで準備できているか」を事前に確認しながら学習を進められます。 なお、Red Hat認定資格の詳細については以下の記事でも紹介をしていますので、合わせてお読みいただけると幸いです。 rheb.hatenablog.com 3. 「書店では買えない」Red Hat公式学習教材をPDF・EPUBで入手できる タブレットの電子書籍アプリでEPUBを起動している様子 EPUBであれば、線を引いたり、直接キーワードの検索なども可能 ここで、意外と知られていない重要な事実をお伝えします。 Red Hatは、認定資格試験の対策書籍を市販していません。 他のIT資格では、書店やAmazonで試験対策本を購入することができますが、Red Hat認定資格に関しては、そのような市販の公式教材は存在しません。Red Hatが提供するトレーニングの電子書籍（PDF・EPUB形式）は、 Red Hat Learning Subscriptionを通じてのみ入手できる唯一の公式学習教材 です。 つまり、RHLSを契約することは、トレーニング環境へのアクセスだけでなく、 他では手に入らない公式コンテンツそのものを手に入れる ということを意味します。電子書籍は手元にダウンロードしておくことができるため、通勤中やオフライン環境でも学習を続けられます。「ちゃんとした教材で勉強したい」というニーズにも、RHLSはそのまま応えられる設計になっています。 4. 「実機で磨く」1年間アクセス可能なハンズオンラボ インターネット環境があれば、いつでもどこでもハンズオン！ RHLSをご利用のユーザーは、Red Hatが提供するハンズオン環境に1年間アクセスが可能です。 Courseでは年間100時間 、 StandardおよびPremiumでは400時間 の演習環境の利用権が提供されます。 「講義は分かったけど、実際に手を動かしてみないとイメージが湧かない」——これはインフラエンジニアなら誰でも経験する感覚です。RHLSのハンズオンラボは、自分のPC環境に依存することなく、ブラウザから実機相当の環境にアクセスして演習できます。400時間というのは、単純計算でも約16日分。これだけの実習時間が1年間のサブスクリプションに含まれているのは、他のトレーニングサービスではほとんど見られない水準です。 また、この演習環境のありがたいポイントの1つはRed Hatが用意したシナリオベースで特定の機能を実装したり、トラブルを解決するという演習が含まれている点です。 エンジニアの方の中には「用意された演習環境ではなく、自分で演習環境を作ってことエンジニアだ！」という方もいるでしょう。 しかし、初学者にとって自分で0から検証環境を用意したり、構築しないといけないとなってしまうと、それ自身が学習のボトルネックになってしまったり、 モチベーションの低下に繋がる可能性もあります。 Red Hatが提供する操作演習環境は、こうした問題の解決にも繋がります。 5. RHLS CourseとPremiumにはインストラクター主導のバーチャルライブクラスも含まれる RHLS CourseとPremiumでは、自習型コンテンツに加えて、 インストラクター主導のバーチャルライブクラス も含まれます。 ※ Courseでは1年間に1種類のコースのみ、Premiumは無制限に受講可能 「動画を見るだけでは理解が難しい」「インストラクターに直接質問したい」というニーズに応える形で、ライブクラスが組み込まれているのがCourseとPremiumの最大の特徴です。自習の柔軟性と、ライブ指導の深さを両立できる点で、本格的なスキルアップを目指す方には特に強くお勧めできます。 コスト試算：3コース以上で元が取れる 「RHLS StandardやPremiumは、単体の価格だけを見ると高く感じる」——これはよくいただく率直な感想です。 ただ、ここで少し立ち止まって計算してみてください。 Red Hatのコースは種類によって価格が異なりますが、一般的なコースを個別に受講した場合のコストと比べると、 StandardまたはPremiumのサブスクリプションは、3コース以上を受講するだけで費用的に逆転します。 さらに、個別購入では別途費用がかかる以下がすべて込みである点を忘れてはいけません。 試験バウチャー 試験準備ツール 1年間アクセスが可能なハンズオンラボ環境 1年間で複数のスキルを伸ばしたい、複数の認定資格を取得したいというエンジニアにとっては、 実質的に最もコストパフォーマンスが高い選択肢 と言えます。組織として複数のエンジニアのスキルアップを計画している場合はなおさらです。 「1人で受けて終わり」ではなく「組織の投資」として RHLSのユニークな点は、個人の学習手段としてだけでなく、 組織のスキル戦略の核 として使えることです。 ITマネージャーや人事担当者の視点で整理すると、従来型のトレーニング予算の使い方と比べた場合にこんな違いがあります。 従来型 ：年に1〜2回の集合研修 → 受講後に内容が定着しにくく、資格取得率も伸び悩む RHLS ：1年間の継続学習環境 → 受験サポートが手厚いため資格取得が促進され、スキルの定着度も高まる なお、Enterprise Strategy Groupによる経済効果の分析（2024年1月）においても、Red Hat Learning Subscriptionの組織レベルでの投資対効果が示されています。 https://www.redhat.com/en/engage/the-economic-impact-of-training-analyst-material 上記リンクより本誌をダウンロードできます。 まとめ：People Modernization の時代へ 「システムをモダナイズする」というプロジェクトは、多くの組織が取り組んでいます。しかし、 そのシステムを動かし続けるエンジニアのスキルが追いついていなければ、投資は十分に回収できません。 Red Hat Learning Subscriptionは、単なる「研修パッケージ」ではなく、 組織の技術変革を人材面から支える、1年間のオールインワン成長プラットフォーム です。 1年間のいつでも学べる環境 (再受験を含む)最大10回の認定資格試験受験機会と試験準備ツール 1年間アクセス可能なハンズオンラボ CourseとPremiumならバーチャルライブクラスも込み 3コース以上の受講で、個別購入より費用対効果が逆転 システムだけではなく、 人もモダナイズする時代 。 そのための第一歩として、ぜひRed Hat Learning Subscriptionの検討をお勧めします。 まずは無料トライアルから試してみてください。 https://www.redhat.com/ja/services/training/learning-subscription/trial Red Hatの教育サービスは、時代の変化に対応する人のモダナイズを支援します

サポート担当の古市です。今回は Red Hat Build of Apache Camel(RHBAC) のアップストリームとなる Apache Camel コミュニティーの活動に関する記事です。 将来、製品版に落ちてくるかもしれないので、ぜひ少し先の未来を覗く感覚でお楽しみください。 Apache Camel x AI の取り組みについて昨年(2025年) Apache Camel Advent Calendar の記事 でご紹介しましたが、今度は Apache Camel を使ったインテグレーション開発支援用バイブコーディングツール です。 その名も camel-kit 。 camel-kit AI agent と "Camel MCP Server"を使ったバイブコーディングツールとお伝えすればイメージし易いでしょうか。 執筆時点では、以下の AI Agent に対応しています。 Claude Code IBM Bob Gemini CLI came-kit は、各コマンドを通して 設計 コード実装 評価 テストコード生成 テストコード実行 までサポートできるので、インテグレーション開発の心強いパートナーとなり得ます。 設計段階では２つの粒度でドキュメントを作成します。ドキュメント自体はシンプルなテキストファイルとなり、これらをコードリポジトリで管理していただくことも、もちろん可能です。 Business Requirement Document Technical Design Document ざっくり、コマンドを紹介していきます。基本的に各コマンドでは、ユーザーが AIとの対話を通して成果物を作成する流れとなります。 camel kit init xxx --ai xxx camel-kit の初期化を実施します。 "ai"オプションで指定した AI Agent用の設定などを ".camel-kit" ディレクトリー配下に保存します。 /camel-project "Business Requirement Document" を生成し、".camel-kit" ディレクトリー配下に保存します。 /camel-flow "Business Requirement Document" を元に、"Technical Design Document"を生成し、".camel-kit"ディレクトリー配下に保存します。 /camel-implement "Technical Design Document" を元に、コード実装を実施。コマンド実行ディレクトリーに、インテグレーション ファイル(yaml)を保存します。 /camel-validate 実装コードの評価をおこないます。 /camel-test インテグレーション用テストコードを実装/実行します。生成テストコードは test ディレクトリー配下に保存されます。実行用に run-testes.sh も生成されます。テストコードは、 citrus ベース。 AI agent は "camel mcp server" へ問い合わせることで、常に最新の camel catalog 情報を利用可能です。 また、"docs/constitution.md" ファイルの "Project Customizations" セクションを使い、AI agent のふるまいをチューニングすることも可能です。(例: camel-xxx はなるべく使わず、camel-xxx を使う) その他、マイグレーション支援コマンドも用意しています。 /camel-migrate 現時点では、MuleSoft Mule プロジェクトを解析し Apache Camel 4.x ベースへの移行支援を実施します。 各AI agent は VSCode extension を提供しているようですので、VSCode上で camel-kit を使いつつ、kaoto で生成されたインテグレーションをチェックしたり手直しするといった運用ができます。 camel-kit をパートナーに、インテグレーション開発スピードをあげる未来がやってきそうです。 camle-kit のユーザーガイドはこちらです。camel-kit は、camel-jbang のプラグインとしてインストールできますので、AI agent環境があればすぐにお試しいただけます。 luigidemasi.github.io github.com 執筆時点ではバージョン 0.3.1 と若いですが、気になる方はぜひお試しいただき、フィードバックを アップストリーム へ届けてみてはいかがでしょうか。 製品版としての提供はまだですが、営業担当やサポートへ camel-kit に対する期待をお伝え頂いても、もちろんかまいません。 ぜひ、それぞれができる範囲でコミュニティー活動を盛り上げていければと願っております。 みなさんの声が、未来を創る。素敵じゃないですか。

Red Hat認定資格の歴史を振り返る 〜いつ始まり、何が変わり、今どうなっているのか〜 皆さんこんにちは、Red Hat Global Learning ServicesでLearning Solution Architectを担当している坂井 大和( @lab8010 )です。 この記事では、Red Hatのトレーニングと認定資格に興味をお持ちの皆さま向けに、Red Hat認定資格の歴史について整理してみたいと思います。 「Red Hatの資格っていつからあるの？」「昔はどんな試験だったの？」「今の資格は何が違うの？」という疑問に、できるだけ分かりやすくお答えしていきます。 はじめに Red Hatの認定資格は、単なる知識確認のための試験ではなく、実際に手を動かして業務を遂行できるかを問う実技中心の資格体系として発展してきました。 この "performance-based" という考え方は、Red Hat認定の大きな特徴であり、初期から現在までずっと一貫しています。 なお、2026年現在では自宅での受験も可能となっており、以下の動画では具体的な受験の流れを紹介しています。 Q. Red Hat認定資格はいつから始まったのか？ A. 1999年1月にRHCEが始まったのが、Red Hat認定資格の出発点です。 参考： RED HAT EXPANDS INDUSTRY-LEADING RHCE PROGRAMME（Red Hat公式） Red Hatの公式発表では、最初のRHCE取得者が1999年1月に誕生したことが示されています。 つまり、Red Hat認定資格の歴史は、少なくとも1999年初頭から継続していると言えます。 Q. 初期の資格形態はどのようなものだったのか？ A. 初期はRHCEのみでした。 RHCE この時代のRHCEは、Linuxシステム管理やネットワーク管理のスキルを、実際の環境を使ったライブ試験で確認する形式でした。 選択問題を解くだけではなく、実際にコマンドを打ち、設定し、動作させることが求められるのが大きな特徴です。 Red Hatはこの認定を、OS資格としては珍しいperformance-based certificationとして打ち出していました。 要するに、「知っているか」だけではなく、 「現場でできるか」 を問う資格だったわけです。 RHCTの登場（2002年） その後、 2002年11月 にRHCTが導入されました。RHCTは、現在のRHCSAの前身にあたる資格です。 参考： Red Hat Broadens Skill Certifications Program with New RHCT Certification（Red Hat公式） RHCTの登場によって、Red Hat認定はより段階的な体系になりました。 上位のRHCEに加えて、基礎的なシステム管理スキルを評価する資格が整備されたことで、学習者にとってもキャリアの入り口が明確になっていきました。 日本では2004年3月より、それまでRHCE受験の副産物として運用されていたRHCTが、独立した単独試験として正式スタートしています。あわせてこのタイミングで、トレーニングの実施プラットフォームがRed Hat LinuxからRed Hat Enterprise Linux 3へと移行しました。 参考： RHCE取得を目指すRHCE系トレーニングコース／認定試験を刷新（レッドハット株式会社 日本語プレスリリース） 当時のRHCT試験の対象範囲については、RHEL 5時代のデプロイメントガイドにその内容が記録されています。 参考（日本語）： Red Hat Enterprise Linux 5 デプロイメントガイド - RHCT試験について 参考（英語）： Red Hat Enterprise Linux 5 Deployment Guide - RHCT Exam RHCAの登場（2004年発表 → 2006年日本提供開始） 2004年6月、資格体系の頂点に位置する RHCA（Red Hat Certified Architect） が発表されます。 参考： New Red Hat Training and Certification Ensure Architect Level Competencies for Open Source（Red Hat公式プレスリリース） RHCAはRHCEの上位に位置する Capstone Certification（最上位認定） として設計されており、複数のサーバーやSANを用いたデータセンター規模の実機演習が中心です。対象は、組織のインフラを多種多様なシステムにわたって設計・管理するシニアエンジニアです。 なお、2004年6月の発表時点では「今年後半に提供開始予定」という案内にとどまっており、 日本での提供開始は2006年3月 となっています。レッドハット株式会社は2006年2月14日にその旨を発表しており、ITmediaもこれを報じています。 参考： レッドハット、最上位の認定資格RHCAのトレーニングを開始（ITmedia Enterprise） 取得には以下の5つのコースと対応する認定試験の合格が求められていました（提供開始当初）。 トレーニングコース 内容 認定試験 RHS333 エンタープライズ セキュリティ ネットワークサービスコース EX333 RH401 エンタープライズシステムの導入・運用コース EX401 RH423 エンタープライズディレクトリサービスおよび認証コース EX423 RH436 エンタープライズストレージ管理コース EX436 RH442 エンタープライズシステムの監視・パフォーマンスチューニングコース EX442 Red Hat Vice President of Learning Services であるPeter Childers氏は2004年の発表プレスリリースの中で、RHCAについて「オープンソースアーキテクチャの設計・管理に関心を持つ企業にとって魅力的な資格になる」と述べています。 Q. 現在の資格形態はどうなっているのか？ A. 現在はRHCSA・RHCE・RHCAの3段階のレベルを採用しています。 2010年のRHEL 6リリースを境に、資格体系が現在の形に整理されました。初級となるRHCSA、中級のRHCE、そして最上位のRHCAという3段階の構成で、いずれも実技試験による認定という方針は変わっていません。 📎 参考： Red Hat認定資格を持っていると「できるエンジニア」と言われるのはなぜなのか（赤帽エンジニアブログ） RHCSAはRed Hat Certified System Administratorの略で、現在のRed Hat認定資格体系における入口の資格として位置づけられています。 試験はEX200で、RHEL環境に対して実際の管理タスクをこなす実技試験です。 📎 参考： Red Hat Certified System Administrator (RHCSA) exam｜Red Hat公式 なお、RHCSAはRHCTの後継として 2010年のRHEL 6リリースに合わせて導入 されました。過去にRHCTを取得済みの方にはRHCSAが遡及発行されるという、ユーザーへの配慮もなされています。 📎 参考： Red Hat Introduces New Certification and Role-Based Training Paths（Red Hat公式） 歴史の流れを整理すると 時期 主な資格 位置づけ 試験の特徴 1999年1月 RHCE 認定資格の出発点 ライブ環境での実技試験。Linux管理とネットワーク管理を評価 2002年11月 RHCT 基礎資格の追加 初級のシステム管理スキルを実技で確認（RHCSAの前身） 2004年6月 RHCA 最上位資格の追加 複数サーバー・SAN環境を使った実機演習。アーキテクト向け 2010年〜現在 RHCSA / RHCE / RHCA 段階的な資格体系 RHCSAはEX200の実技試験。RHCEは中上級、RHCAは最上位 まとめに代えて Red Hat認定資格の歴史を振り返ると、最初から最後まで一貫しているのは、 実務に強いエンジニアを育てるという思想 です。 試験の形式や資格名は時代とともに変わってきましたが、 "手を動かせること"を重視する方針は変わっていません。 1999年のRHCE誕生から、2002年のRHCT、2004年のRHCA、そして2010年のRHCSAへの改名にいたるまで、常に「現場で通用するか」が問われ続けてきました。 そのため、Red Hat認定資格を学ぶことは、単に資格を取るためだけではなく、Linux/Red Hat環境での実践力を体系的に身につけることにもつながります。

RHELのスペシャリストソリューションアーキテクトの田中司恩( @tnk4on )です。 この記事は Red Hat Blog の Introducing the Red Hat Universal Base Image を、許可を受けて翻訳したものです。 コンテナーベースイメージの選択肢は数多くありますが、なぜRed Hat Universal Base Image (UBI) を選ぶべきなのでしょうか？まず第一に、Red Hat Universal Base Imageのコードは Red Hat Enterprise Linux (RHEL) から派生しており、RHELの使命は、安全で信頼性の高いLinuxを通じてワークロードの成功を支えることです。すべてのコンテナーはLinuxであり、UBIはRHELから派生しているため、同じ価値がUBIにも当てはまります： イノベーション： 組織は常に、摩擦なく迅速にイノベーションを起こし、運用を合理化し開発と管理を一元化することで、データセンターからエッジまでの一貫性を提供することを目指しています。 最適化： インフラストラクチャーの複雑さは、コストの増加と効率の低下を容易に引き起こします。 保護： ハイブリッドクラウド全体でリスクを継続的に軽減することは、ワークロードの構築、スケーリング、管理を含め、ほとんどの組織にとって課題です。 信頼： アプリケーションライフサイクルの複雑さ、ワークロードの互換性、セキュリティパッチ適用、コンプライアンスレポートを管理することは、組織にとって終わりのない課題です。 Red HatはRHEL 7以来ベースイメージを提供してきました（RHEL 6イメージも含まれていました）。RHELの コンテナーホスト 上でRHELの コンテナーイメージ を実行することで、環境間の互換性とポータビリティが得られます（馴染みやすさは言うまでもありません）。 お客様はUBI上で構築したコンテナーイメージを、組織の内外を問わず誰とでも共有できます お客様以外の方も、Red Hat Universal Base Imageでリリースされたすべてのコンテンツを活用できます 誰もが公式のRed Hatコンテナーイメージの優れた信頼性、セキュリティ、パフォーマンスを活用できるようになりました。つまり、UBI上でコンテナー化されたアプリケーションを構築し、任意のコンテナー レジストリサーバー にプッシュして、世界中と共有できます。UBIを使えば、どこでも好きな方法で、コンテナー化されたアプリケーションを構築、共有、コラボレーションできます。 図1: Red Hatプラットフォーム vs. 任意のOCI準拠コンテナープラットフォーム UBI上でアプリケーションを構築すれば、どこでも自由に共有し、どこでも自由に実行できますが、RHELまたは Red Hat OpenShift 上で実行すると追加の価値が得られます。その仕組みは次のとおりです： Run anywhere： 同じ品質のソフトウェアが得られますが、コミュニティサポートとセルフサポートのみです Run on RHEL or OpenShift： 同じ品質のソフトウェアが得られ、Red Hatによるフルサポートが受けられます。助けが必要な場合はサポートチケットを提出するだけです UBIを使用する理由 UBIは次のような場合にコンテナーに最適な選択です： 開発者 が公開配布できる高品質なコンテナーイメージを求めている場合 運用チーム がエンタープライズライフサイクルを持つサポート可能なベースイメージを求めている場合 プロダクトチーム がRed Hatと共同サポートされる Red Hat認定コンテナー を提供したい場合 お客様 がRed Hat環境でエンタープライズサポートを求めている場合 コミュニティ がコンテナー化されたアプリケーションをより自由に共有したいが、高品質なコンテナーイメージも求めている場合 これらのいずれか、またはすべてがあなたの組織に当てはまるなら、ぜひ読み進めてください！ UBIは単なるベースイメージではない コンテナーは、Linuxオペレーティングシステムのユーザーランド（オペレーティングシステムに付属するすべてのプログラム、ライブラリ、依存関係）の軽量バージョンを提供します。アプリケーションをコンテナーに入れることで依存関係を必要最小限に削減できますが、コンテナーの中身は依然としてOSのユーザーランドであるため、コンテナーベースイメージの品質はホストオペレーティングシステムと同じくらい重要です。組織にとって適切なコンテナーベースイメージを選択することは、 標準運用環境 (SOE) を構築するのと同様に、セキュリティとライフサイクルに影響を与える重要な選択です。 つまり、完全なOSを必要とせずに、UBIは3つのものを提供します： 4つのベースイメージのセット（ubi-micro、ubi-minimal、ubi standard、ubi-init） 言語ランタイムイメージのセット（Node.js、Ruby、Python、PHP、Perlなど） 一般的なアプリケーション依存関係を満たすソフトウェアリポジトリ内のパッケージセット 図2: ベースイメージ、ビルド済み言語イメージ、パッケージサブセット すべてのUBIコンテンツはRHELのサブセットです。UBIのすべてのパッケージはRHELチャネルから提供され、RHELまたはOpenShift上で実行される場合はRHELと同様にサポートされます： 図3: RHEL 7およびRHEL 8 vs 他のコンテナープラットフォーム コンテナーイメージの品質サポートを提供するには、多くのエンジニアリング、セキュリティ分析、リソースが必要です。ベースイメージだけでなく、特定のコンテナーホスト上での動作もテストする必要があります。アップグレードの課題を軽減するため、Red Hatはエンジニアリングとサポートに重点を置いており、古いバージョンのUBIを新しいRHELホスト上で実行でき、新しいUBIを古いRHELホスト上で実行できます。これにより、コンテナーイメージ内のアプリケーションや基盤となるコンテナーホストのプラットフォームアップグレード時に、ユーザーはより大きな柔軟性と安心感を得られます。サポート対象の完全なリストについては、Red Hatポータルの コンテナー互換性マトリックス を参照してください。 4つのUBIベースイメージの比較 図4: 4つのベースイメージの比較 Micro: 独自の依存関係を含むアプリケーション向け（Python、Node.js、.NETなど） 構築可能な最小のイメージ パッケージマネージャーがないため、より小さい Dockerfileの代わりにBuildahの使用を推奨 Minimal: 独自の依存関係を含むアプリケーション向け（Python、Node.js、.NET） 最小限のプリインストールコンテンツセット SUIDバイナリなし 最小限のパッケージマネージャー（インストール、更新、削除） Standard: RHEL上で動作するあらゆるアプリケーション向け 統一されたOpenSSL暗号スタック フルの dnf スタック 便利な基本OSツール（tar、gzip、viなど）を含む Multi-service: 単一コンテナーで複数のサービスの実行を簡素化 起動時にsystemdを実行するよう構成 ビルド時にサービスを有効化可能 開発者向けのビルド済み言語ランタイムコンテナーイメージ 言語をインストールできるベースイメージに加えて、UBIは開発者向けに、さまざまな言語ランタイムのビルド済みイメージを提供しています。多くの場合、開発者はイメージを取得して、構築しているアプリケーションの作業をすぐに開始できます。ビルド済みランタイムコンテナーイメージの完全なリストについては、 Red Hat Ecosystem Catalog を確認してください。 Red Hatは、新しいバージョンのRHELがリリースされたときや、重大なCommon Vulnerabilities and Exposures (CVE) にパッチが適用されたときに 新しいイメージをリリース し、RHELの更新ポリシーを反映しています。イメージを取得してすぐにアプリケーションの構築を開始できるように設計されています。 図5: UBIで利用可能なdnfリポジトリと関連パッケージ アプリケーションを構築する際に、追加のパッケージが必要になったり、アプリケーションを動作させるためにパッケージの更新が必要になることがあります。そのため、UBIには dnf を通じて利用可能なRPMのセットが付属しており、高可用性のコンテンツデリバリーネットワーク上で配布されています。CI/CDパイプラインで本番リリース前に dnf を更新する際も、お客様が使用しているのと同じインフラストラクチャーを利用できます。 すべての土台はRHEL 2014年にコンテナー化されたアプリケーションが登場したとき、それはエンタープライズITにおけるイノベーションの波を表していました。開発とメンテナンスを改善する点で今でも変革をもたらしていますが、コンテナーは万能薬ではありません。エンタープライズの世界では、オペレーティングシステムには安定性、信頼性、セキュリティツール、ガイダンス、タイムリーな修正が必要です。これらはRHELが満たすよう設計されたニーズです。ベースイメージに取り組んでいるRed Hatチームのほんの一部を紹介します： パフォーマンスエンジニアリングチーム：glibcやOpenSSLなどの基本的なライブラリ、PythonやRubyなどの言語ランタイムの更新と保守を担当し、堅牢なパフォーマンスを提供し、コンテナー化するワークロードで確実に動作するよう設計されています プロダクトセキュリティチーム：同じライブラリと言語がタイムリーなセキュリティ修正を受けることを確実にし、 Container Health Indexグレード で測定されます プロダクトマネジメントおよびエンジニアリングチーム：新機能の追加と長いライフサイクルの推進に専念し、その上に構築する投資に信頼を持てるよう設計されています RHELはサブスクリプションベースであるため、リリースごとのライセンス料やそれに加えたサポート料を別途支払う必要はありません。RHELをサブスクライブすると、現在のすべてのバージョンのRHELを実行する権利が得られます。これには、Red Hatサポートへのアクセスと、より安全で堅牢で信頼できるLinuxオペレーティングシステムの利点が含まれます。RHELはコンテナーの優れたホストおよびイメージとして機能しますが、多くの開発者はサポートされるシナリオの外にある可能性のある、より幅広いユースケースをサポートする必要があります。そこでUBIの出番です。 単純なコンテナー化アプリケーションの構築を始めるためのベースイメージを探しているだけかもしれません。あるいは、コンテナーエンジン上で実行されるスタンドアロンのコンテナーから、OpenShift上で動作するよう設計されたOperatorを構築・認定するクラウドネイティブの世界に移行しているかもしれません。いずれにしても、UBIは優れた基盤を提供します。 図6: RHEL認定アプリケーション > 認定コンテナー > 認定Operator コンテナーは軽量なオペレーティングシステムのユーザー空間を新しいパッケージング形式でカプセル化するものであり、Red HatはエンタープライズグレードのLinuxオペレーティングシステムのリーダーです。UBIは、独立系ソフトウェアベンダー（ISV）、お客様、オープンソースコミュニティにエンタープライズグレードのコンテナーを提供することで、コンテナー開発の新しい業界標準を設定するよう設計されています。 特に、ISVは Kubernetes Operator を含むコンテナー化されたアプリケーションの単一の信頼できる基盤に標準化できます。UBIを使用するISVは、OpenShiftのようなRed Hatプラットフォームにデプロイされたソフトウェアの継続的な検証のために、 Red Hatコンテナー認定 を活用できます。 サードパーティOCI準拠プラットフォーム上のUBI +Red Hatプラットフォーム +認定 信頼性のあるロードマップ ✓ ✓ ✓ 実証された基盤 ✓ ✓ ✓ 最小イメージ ✓ ✓ ✓ パッケージ更新 UBIコンテンツのみ すべてのRHELコンテンツ すべてのRHELコンテンツ クラウドネイティブ言語ランタイム ✓ ✓ ✓ 配布/再配布 ✓ ✓ ✓ Red Hatプラットフォームテスト - ✓ ✓ Red Hatカスタマーサポート - Red Hatコンポーネント 全コンポーネントの共同サポート セキュリティスキャン - - ✓ Red Hatとの共同プロモーション - - ✓ コンテナービルドサービス - - ✓ UBIを使い始める 使い始めるのは簡単です。お好きなコンテナーエンジンでこれらのイメージをプルしてください（Red Hatは Podman Desktop を推奨しています。コマンドラインがお好みなら Podman をどうぞ）。 例えば、UBI 9をプルするには： podman pull registry.access.redhat.com/ubi9/ubi podman pull registry.access.redhat.com/ubi9/ubi-minimal podman pull registry.access.redhat.com/ubi9/ubi-init さらに詳しい情報については、 Red Hat Universal Base Image eBook または Red Hat Universal Base Image FAQ をご覧ください。

こんにちは。レッドハットコンサルティングチームの中川です。 「アプリケーションモダナイゼーション(以下、モダナイゼーション)」について解説する連載は、8回目からリファクタリング (Refactor) をテーマにしています。 はじめに Red Hat Connectivity Link：セキュリティとポリシーを「外」に出す Red Hat Connectivity Linkとは？ なぜ、いま専用の管理人が必要なのか？ 「接続管理の外部化」がもたらすメリット Apache Camel：データ変換とプロトコル差分を「外」に出す なぜ、いま翻訳機が必要なのか？ 「変換の外部化」がもたらすメリット まとめ おわりに Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  はじめに これまでモダナイゼーションをテーマに、ここ数回は6Rのうちの「Refactor（リファクタリング）」に着目して、開発スピードの向上や運用の構造化、そしてサービスメッシュによるマイクロサービス間の通信制御についてお伝えしてきました。 Application, Modernization の検索結果 - 赤帽エンジニアブログ アプリケーション内部が綺麗になり、サービス間の通信も整理されたあと、その次に直面するのが、「外部システムとの連携」という壁です。既存のレガシーシステム、他部署のサブシステム、あるいは外部のSaaS。モダンになったはずのシステムですが、これら外の世界と繋がろうとした途端、再び複雑なコードに飲み込まれてしまうことがあります。 今回はRefactorシリーズの締めくくりとして、このインテグレーションの複雑さを解消する2つの強力な武器、Red Hat Connectivity Link と Apache Camel をご紹介します。 Red Hat Connectivity Link：セキュリティとポリシーを「外」に出す Red Hat Connectivity Linkとは？ リファクタリングによってアプリケーション内部が綺麗になった後、次に考えるべきは「外部との安全な接続」です。ここで登場するのが Red Hat Connectivity Link です。 「Connectivity Link」という名前に馴染みがない方も多いかもしれませんが、これは長年 Red Hat の API 管理を支えてきた Red Hat 3scale API Management の技術を継承し、さらに現代のクラウドネイティブな環境（Kubernetes/OpenShift）に最適化させた次世代の API ゲートウェイ・ソリューションです。 一言で表現するなら、アプリケーションの「玄関口」に立ち、外からの訪問者をチェックして整理する専用の管理人のような存在です。 www.redhat.com なぜ、いま専用の管理人が必要なのか？ マイクロサービス化やシステムのオープン化が進むと、一つのアプリが公開する API の数は膨大になります。その際、全てのアプリに対して以下のような機能を個別に実装しようとすると、大きな問題に直面します。 認証・認可：誰がアクセスして良いかを確認する 流量制限（レートリミット）：1秒間に100回以上のアクセスは遮断する アクセスログの記録：いつ、誰が、どのデータに触れたかを記録する これらをアプリケーションの機能としてコードの中に直接書き込んでしまうとどうなるでしょうか。せっかくビジネスロジックを整理してリファクタリングしたはずのコードが、再びこうした「接続を管理するための複雑なロジック」で埋め尽くされてしまいます。 「誰を通すか（認証）」や「どのくらいの頻度で通すか（流量制限）」といった接続管理の作法を、各アプリケーションの開発者が自分たちで実装し、メンテナンスし続けるのは非効率です。これこそが、リファクタリングの成果を損なう隠れた複雑性の正体です。 「接続管理の外部化」がもたらすメリット Connectivity Link を導入し、これらの機能をアプリの外に切り出すことで、以下のようなメリットが生まれます。 開発者は「本業」に専念できる 開発者は「セキュリティをどう実装するか」に頭を悩ませる時間を大きく減らせます。Connectivity Link という「構造」にガードレールを任せることで、純粋にビジネス価値を生むためのコード、つまり本業のロジック開発に 100% 集中できるようになります。 ガバナンスと統制の一元化 例えば、セキュリティポリシーを強化する必要が出た際、100 個のマイクロサービスを一つずつ修正して回るのは現実的ではありません。Connectivity Link があれば、管理画面から設定を一つ変えるだけで、全ての API に対して一括で新しいポリシーを適用できます。 運用の標準化 「どの API が、いつ、どれくらい使われているか」という可視化も、Connectivity Link で一括で行えます。これにより、Ops（運用）チームは個別のアプリの中身を知らなくても、システム全体の健康状態を構造として把握できるようになります。 Apache Camel：データ変換とプロトコル差分を「外」に出す Connectivity Link が玄関の管理人として入口を整えてくれたら、次に課題となるのは、中に入ってきたリクエストをどうやって相手に届けるかです。ここで活躍するのが Apache Camel です。 docs.redhat.com Apache Camel は、異なるシステム同士を連携させるための「インテグレーション・フレームワーク」です。世の中には、最新の REST/JSON で動くシステムもあれば、数十年前から動いている固定長データのメインフレーム、あるいは独自のプロトコルを持つ SaaS など、多種多様な言語を話すシステムが存在します。 Camel は、それら異なる言語を話すシステムの間に入り、リアルタイムで翻訳して橋渡しをしてくれる超高性能な翻訳機の役割を果たします。 なぜ、いま翻訳機が必要なのか？ リファクタリングが進み、アプリケーションが洗練されても、連携先のシステムが必ずしもモダンな状況で動いているとは限りません。 プロトコルの壁：こちらはHTTPで送りたいが、相手はFTPしか受け付けない データ形式の壁：JSONで処理したいが、相手はXMLや固定長データでしかやり取りできない 手順の壁：Aというデータが来たら、BとCの両方にコピーして送り、エラーがあればDに通知する これらをすべてアプリケーションのコードの中に書き込んでしまうと、コードはあっという間に「変換処理」や「リトライ処理」のスパゲッティ状態に逆戻りしてしまいます。これもリファクタリングの成果を台無しにする複雑性の一因です。 「変換の外部化」がもたらすメリット Camel を活用して、こうした連携ロジックをアプリケーションの外やライブラリに切り出すことで、以下のメリットが得られます。 データ変換という汚れ仕事をコードから追放できる Camel には数百種類もの接続コネクタ（Component）が用意されています。AWS、Salesforce、データベース、SAP……。これらへの接続やデータ変換を Camel に任せることで、アプリケーションのコードは驚くほど短く、読みやすくなります。 「定石（EIP）」による品質の安定化 「データを分割して送る」、「特定の条件で振り分ける」といった連携のパターンは、業界標準の EIP（Enterprise Integration Patterns） として Camel 内に型化されています。ゼロからロジックを組む必要がないため、バグが混入しにくく、誰が書いても高品質な連携が実現できます。 www.enterpriseintegrationpatterns.com 既存資産（レガシー）との共存 数十年にわたって安定稼働してきた複雑なレガシーシステムを無理に壊すのではなく、その前面に Camel を配して「モダンなAPI基盤」へと昇華させる。これにより、既存の堅牢な資産を活かしつつ、最新のクラウドネイティブなサービスとスムーズに連携させることが可能になります。新旧のシステムを「構造」として繋ぎ合わせるこの手法は、いまやエンタープライズ領域におけるモダン化の「定石」と言えます。 まとめ 本シリーズでは、モダナイゼーションにおけるRefactor（リファクタリング）を多角的な視点で掘り下げてきました。 Dev視点：リファクタリングが開発スピードの源泉であること Ops視点：SLAを「人の頑張り」から「システムの構造」へ移し替えること 通信の制御：サービスメッシュでマイクロサービス間のカオスを制御すること インテグレーション：Connectivity LinkやCamelで、サービス間の接続やデータ変換という外部連携の複雑さを「外」へ追い出すこと これらに共通するキーワードは、「構造化」です。 スパゲッティなコードや、特定の担当者にしか分からない運用を廃し、誰が見ても明快で、変化に強い「構造」を作り上げること。これこそがモダンなシステムにおけるリファクタリングの真のゴールです。 おわりに なぜ、いまここまでして構造化を急ぐ必要があるのか？ その答えは、私たちのビジネス環境が、かつてないスピードで変化し続けているからです。 新しいサービスを立ち上げたい、他社のSaaSと連携したい、急な法改正に対応したい…。こうした変化が起きたとき、複雑に絡まったコードの修正に追われていては、ビジネスのチャンスを逃してしまいます。 本シリーズで紹介してきたリファクタリングやインテグレーションの標準化は、単なる「古いシステムの掃除」ではありません。それは、変化が起きたときに即座に動ける「真の強さ」をシステムに持たせるための準備です。 いま取り組んでいるこの一歩は、数年後の自分たちを助け、会社が次の一歩を力強く踏み出すための価値ある「投資」となるはずです。 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？  Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」  ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。  www.redhat.com

Red Hat のソリューションアーキテクトの瀬戸です。 この記事はRed Hat Developerのブログ記事、 Temurin JDK 25 now available in Red Hat Customer Portal | Red Hat Developer を、許可をうけて翻訳したものです。 Java 開発者にとって朗報です。Temurin JDK 25 for x64 Windows が Red Hat カスタマーポータル で利用できるようになりました。これにより、Windows上でJavaを実行するためのサポート対象かつ本番環境対応の選択肢がさらに増えました。 知っておくべきこと Red Hatは長年にわたりTemurinビルドの商用サポートを提供しており、今回のリリースにより、TemurinはRed Hatカスタマーポータルから直接アクセスできるようになりました。64ビットWindows向けのJDK 25ではRed Hat build of OpenJDK が提供されないため、このプラットフォームではTemurinが第一の選択肢となります。 開発者にとって何が重要なのか 構築するコードを変更することなく、サポートニーズに最適なエンタープライズディストリビューションを選択できます。この柔軟性は、サポート、サービスレベル契約（SLA）、AIに特化したサービスといった選択肢を維持しながら、ツールを標準化したいチームにとって役立ちます。 Red Hatのエンジニアリングチームは、コンパイラのバージョンとオプションを調整し、TemurinがOpenJDKのRed Hatビルドと同様に動作するようにしました。Red Hatはビルドの再現性を検証しました。TemurinとRHBO *1 のバイナリは、ベンダーメタデータを除き、バイト単位で同一であるため、両者を切り替えても予期せぬ動作は少ないです。 Red Hat 製品セキュリティチームは、信頼できるインフラ上で Temurin ビルドを独自に再現し、検証しています。Temurin は AQAvit 検証および TCK 認証を取得しており、Red Hat は再現性を独自に保証しています。この検証により、本番環境での使用における信頼性がさらに高まります。 今後の見通し Red HatはEclipse AdoptiumプロジェクトにおいてTemurinへの貢献と検証を継続し、正式なReproducible Attestationプログラム *2 が展開される際には詳細を共有いたします。その間、開発者の皆様はRed Hatカスタマーポータルでサポートおよび検証済みのJDKオプションをご利用いただけます。これにより、チームが本番環境で必要とする保証を得ながら、モダンなJavaアプリケーションをより柔軟に開発できるようになります。 Temurin JDK 25 の詳細については、 Red Hat build of OpenJDK - Red Hat Customer Portal をお読みください。 *1 : 訳注: Red Hat build ofの略 *2 : 訳注:信頼できる実行環境内で動作するソフトウェアの整合性を、同一のソースコードから再構築されたバイナリと突き合わせて検証するセキュリティプロセスの事。これにより、実行中のコードが意図した通りであり、改ざんされていないことを保証する。

こんにちは。レッドハットコンサルティングチームの中川です。 「アプリケーションモダナイゼーション(以下、モダナイゼーション)」について解説する連載は、8回目からリファクタリング (Refactor) をテーマにしています。 はじめに OpenShift Service Meshを支える「三種の神器」 1． Istio：通信の「交通整理」 2． Kiali：暗闇を照らす「リアルタイム・マップ」 3．Grafana Tempo(Distributed Tracing)：リクエストの「足跡」を追う シナリオ：障害発生！そのときサービスメッシュはどう動く？ まとめ おわりに Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  はじめに 前回の記事 では、SLAを個人の努力ではなく「構造」で担保するという考え方を紹介しました。しかし、アプリケーションをリファクタリングしてマイクロサービス化すると、新たな課題に直面します。 rheb.hatenablog.com どこで不具合が出ているか」がわからない： 1つのリクエストが複数のサービスをまたぐため、エラーの特定が困難に。 「通信の不安定さ」が牙を向く： ネットワーク越しに対話が増えるため、わずかな遅延がシステム全体を麻痺させる。 「共通処理」がコードを汚染する： リトライやタイムアウトのロジックを全サービスに書くのは、「負債」の再生産である。また言語やフレームワークが混在するマイクロサービス環境では、この共通処理の実装漏れや差異が新たなバグの温床になり得ます。 これらを「アプリのコード（人の頑張り）」ではなく、「プラットフォーム（構造）」で解決するのが、今回紹介する サービスメッシュです。 OpenShift Service Meshを支える「三種の神器」 Red Hat OpenShift Service Meshは、IstioというOSSをベースに、運用を助けるツール群を複数含んでいます。 1． Istio：通信の「交通整理」 アプリケーションコンテナの隣に「サイドカー（Envoy）」コンテナを配置し、通信をすべて横取りし、必要な処理を注入します。 サービスメッシュの有無 コード改修は不要： アプリ本体にリトライ処理やサービス切り離し処理などを書く必要はありません。Istioの設定（YAML）一つで、「3回リトライしてダメなら切り離す」といった制御が可能です。 メリット： 開発者はビジネスロジックに集中でき、運用者はインフラ側の設定で一元的にポリシーを適用できます。 https://istio.io/ 2． Kiali：暗闇を照らす「リアルタイム・マップ」 「サービスがどう繋がっているか」を可視化します。 サービス間のマップ： 正常な通信とエラーが出ている通信はグラフの色で表示されます。「Aサービスは正常だが、そこから先のBサービスとの通信が赤い=エラー」といった状況がひと目でわかります。 設計と実態の同期: マイクロサービス化で複雑化した依存関係を俯瞰できるようになります。そのため、設計書にはない「意図しない通信」の発見や、カナリアリリースでのトラフィック分散状況の確認にも威力を発揮します。運用者は「勘」ではなく、可視化された「事実」に基づいて迅速な意思決定ができるようになります。 リアルタイムマップイメージ https://kiali.io/ 3．Grafana Tempo(Distributed Tracing)：リクエストの「足跡」を追う 役割： ユーザーの1クリックが、サービスA、B、Cを経由する際、それぞれで何ミリ秒で通過したかをタイムライン形式で示します。 実践的な価値: 「システム全体がなんとなく重い」という抽象的な問題を、「サービスCのDBアクセスが2秒かかっている」という具体的な事実まで掘り下げることができます。 こうしたアプリケーションパフォーマンス追跡ツールは開発時のデバッグ用と思われがちですが、その真価は本番環境での『原因究明の迅速化』にあります。OpenTelemetryによるサンプリング技術や、Tempoのような低コストな蓄積基盤の登場により、今や本番環境でサービス間の対話を可視化し続けることは、モダンな運用のスタンダードとなっています。 Traceイメージ https://grafana.com/ja/oss/tempo/ https://opentelemetry.io/ja/ シナリオ：障害発生！そのときサービスメッシュはどう動く？ サービスメッシュを導入したあとの具体的なトラブルシューティングの流れを、運用者の目線で追ってみます。 【異常の検知】 監視アラートが鳴る 「システム全体が重い」という抽象的なアラートからすべてが始まります。これまでは、ここから全サービスのログを1つずつ確認する、果てしない作業が必要でした。 【場所の特定】 Kialiで「犯人」を見つける まずKialiのサービスマップを開きます。正常な線が緑色で流れる中、特定のサービスに向かう線だけが「オレンジ色」に変わっている箇所を見つけます。これで、数あるマイクロサービスの中から「どこに問題があるか」が数秒で特定できます。 【原因の深掘り】 Grafana Tempoで「証拠」を掴む 次に、そのオレンジ色の通信を詳しく調査します。リクエストの足跡（トレース）を辿ると、たとえば「サービスAからDBへの問い合わせに5秒かかっている」という事実がタイムライン形式で表示されます。これで、調査の焦点は「DB接続に関する不具合」に絞られます。 【被害の封じ込め】 Istioで「二次災害」を防ぐ 原因究明を進める一方、あらかじめ設定しておいた「サーキットブレーカー」が、異常を検知した瞬間に自律的に作動し、不調なサービスへのリクエストを即座に遮断します。他の正常な機能まで連鎖的に停止（なだれ式なシステム崩壊）することを未然に防いでくれます。運用担当者が状況を確認したときにはすでに被害の波及は止まっており、最小限の影響でサービスが維持されている。という状態が担保されます。 もし、サービスメッシュがない世界でこれらを行うとしたらどうなるでしょうか？ まず関係しそうな各サービスのログを一つずつ収集するところから始まります。マイクロサービス環境ではログの量も膨大です。時には「ログの参照権限」や「該当時間帯のログ抽出依頼」を運用チームに申請し、許可を待つだけで半日過ぎてしまうということもあると思います。 やっと入手したログを時刻を頼りにパズルのように突き合わせて、数日かけてようやく「どうやら原因はサービスCにあるようだ」と突き詰めた頃にはアプリケーション開発者、運用者ともに疲弊しきっています。ビジネスにも大きな影響が出ているかもしれません。 今回ご紹介したツール群は、こうした「人が時間を溶かして解決していた作業」を構造的に肩代わりし、本来の開発業務に時間を費やせるようになります。 まとめ アプリケーションを細かく分ける（Refactor）だけでは、モダナイゼーションは完成したとは言えません。分けたことによって生じる「散らばった通信」は、サービスメッシュという構造で制御できてはじめて、第9回で掲げた「持続可能なSLAの担保」が実現します。 おわりに リファクタリングが進み、モダンになったシステムが次に直面するのは「外の世界との繋がり」です。 クラウドネイティブな環境と既存のレガシーシステム、あるいは異なるクラウドサービス間をどうスマートに繋ぎ、連携させていくか。次回のブログでは、このシステム間連携をテーマにRed Hat Connectivity LinkとApache Camelを活用したモダンなインテグレーションの世界を紹介します。 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？  Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」  ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。  www.redhat.com

こんにちは。レッドハットコンサルティングチームの木嶋です。 「アプリケーションモダナイゼーション(以下、モダナイゼーション)」について解説する連載は、前回である8回目からリファクタリング (Refactor) をテーマにしています。 リファクターは『既存の振る舞いを保ちながら、内部構造を改善する』行為です。これ自体はユーザーに目新しいものはなにも生み出さないので、一見ただの「作り直し」に見えてしまいます。 しかし、内部構造の改善は最終的に、開発者や運用者の時間の使われ方と、組織全体のコスト構造を大きく変えます。見た目以上に「経済の話」なのです。 前回はリファクタリングを開発者 (Dev) 視点 から捉え直し、「本当に欲しい機能の開発に使えている時間は限定されている」ことのデメリットを経済適合性の観点で整理しました。 本記事では、このリファクタリングを 運用 (Ops) 視点 から見直し、一見オーバースペックに見える「マイクロサービスアーキテクチャ」がなぜ採用されるのかを見直していきます。 はじめに マイクロサービス化適合性アセスメントから見える現実 Opsの現実 運用回避依存の罠 Ops視点でマイクロサービスアーキテクチャを選ぶ3つの理由 人的コストを削減し、自動化しやすい構造を作る キャパシティ計画の戦術の骨格を作る SLAを「偶然ではなく戦略的に」担保する でも、マイクロサービスアーキテクチャって運用が大変なんでしょう？ まとめ おまけ Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  はじめに 前回のDev編ではあえてマイクロサービスアーキテクチャを大きく取り上げませんでした。 開発 (Dev) 視点だけで見ると、実はマイクロサービスを選ばなければならない決定的な理由はあまり大きくありません。開発のスピードが経営課題になりうる組織、および対象システムが日本の組織にどれだけあるでしょうか。 一方で、運用 (Ops) の視点に立つと、マイクロサービスがもたらす価値は一気に明確になります。 障害の局所化 キャパシティ課題への対応 デプロイ、リリースのための準備と変更管理の最小化 属人化と運用品質リスクの低減 ただし残念ながら日本の大きな組織では、開発 (Dev)、運用 (Ops)、システムオーナーがそれぞれ別会社という構造の組織が多く、Opsが気がついている運用的課題、解消するための工夫や効果のでにくさが、Devやシステムオーナーのところに届きにくく、結果として全体最適を目的とした効率化が進みにくいという課題が生じがちです。 ではOpsでは日々何が起きており、どんなことに現在最も高価な人的リソースを割いているのでしょうか。 そしてそれはなぜうまく効率化されないのでしょうか。 ここからはこの観点に着目して掘り下げます。 マイクロサービス化適合性アセスメントから見える現実 私は、リファクタリングをしたいものの「マイクロサービスアーキテクチャが妥当かどうかわからない」というお客様のためにシステムの総合的なアセスメントをご提供しています。 この時、OSやミドルウェアやサポート期限、開発現場の悩み、いわゆる「2025年の崖」への懸念や対応の遅れといった論点は、最初のミーティングから必ずといってよいほど挙がってきます。 いずれも重要な観点ですが、一方で意外なほど話題に上がらず、こちらからお願いをしても最後まで出てこないものがあります。 このシステムは現在のトラフィック傾向に対して、どの程度のキャパシティの余力を持っているのか 例えば以下のような問いです。 ピーク時の CPU、メモリ、DB I/O が、どの程度のマージンで推移しているのか トランザクション数やデータ量の増加に、あと何年・何倍耐えられるのか 新しいチャネルやサービスを追加したとき、どこが先に限界を迎えそうか こうした問いに対して、きちんと数値と構造で答えられるケースは、驚くほど多くありません。 代わりに次のような回答が返ってくることがほとんどです。 SLAはクリアできています 大きな問題は起きていません そこで私は、少し問いの角度を変えて以下のように投げかけるようにしています。 「夜間バッチはありますか。夜間バッチは予定通りの時間枠の中で終了していますか」 「夜間バッチのエラーはどの程度発生しますか」 「システム的な繁忙日はいつ、どの時間帯ですか。その時はアクセス集中によるレイテンシー問題や障害は発生していませんか」 「それ以外の期間や時間帯は、繁忙日と比較してどの程度少ないですか。数分の1とか、数百分の1とか、大まかな感覚で構いません」 この4点をお聞きすると、多くの場合「実は...」とキャパシティに対する問題が出てきます。 つまり問題がないのではなく、「リファクタリング検討チームの関心事に含まれていない」ことがわかります。 このように、案外Opsの現実はしばしば、 「関心を向けるべきなのに、誰もはっきりと持ち場になっていない領域」として盲点になってしまっています。 そして皮肉なことに、この領域が日本の大きな組織において「マイクロサービス化を検討すべき、もっとも強い理由」を内在していることが少なくありません。 では、Ops の現場では日々どのようなことが起きており、 その中でキャパシティや安定運用に関する“見えないコスト”がどこに潜んでいるのでしょうか。 次に、もう少し具体的な日常の風景を見ていきます。 Opsの現実 では、Ops側の人手と時間は実際の現場でどこに費やされているのでしょうか。 Opsチームの方にお話をお伺いすると、以下のような現実が浮かび上がってきます。 サーバーごとに運用手順が異なる 「アラートが上がったサーバーはどのマニュアルを参照するか」のマッチングに時間がかかる サーバー一覧の更新は手動だが、たまに最新情報が反映されていない アラートが上がって初めて「このサーバー構成、資料と違うのでは」と気づき、有識者を探しにいくこともある また以下のように高度に属人化された様子も伺うことができます。 配属1-2年目はひよっこ、5年目くらいでやっと独り立ち、ベテランは20年選手 同じアラートが上がっても、対応手順の特定までに、新人とベテランで15分以上の差が出る Opsのリーダー層の方々も別にこの状況を放置しているわけではありません。むしろ逆で この高度に属人化した中でもサービス品質を安定させるための、パッチ的な仕組みづくりで手一杯 運用自動化のミッションは与えられているものの、サーバーごとに運用手順が異なり、自動化しようとしても例外処理だらけになってしまい、なかなかメリットが出ない といったジレンマを抱えているケースが多くみられます。 結果として、最も高価な人的リソースであるOpsの時間は、 アラート対応と一次切り分け サーバー／マニュアル／台帳の「すり合わせ」 サービスを止めないための場当たり的な工夫 新人 (?) 教育 にほとんど使い切られてしまい、本来取り組みたい構造的な改善や提案、現状維持をした場合のシステムリスク分析に回す余力が残りません。 その一方で、月次報告ミーティングは「今月も SLA は達成しました」という一言で締めくくられがちで、そこに至るまでにどれだけの人手と時間を燃やしたのかは、数字にはほとんど現れません。 運用回避依存の罠 ここで思い出していただきたいのは、前回の記事で取り上げた、価格構造の変化による「良い設計」の変遷です。 かつてCPUやメモリ、ディスクなどのコンピューティングリソースは非常に高価でした。 そのため、何か問題が起きた時、あるいは将来的な問題を見越して ハードウェアを増強する システム構成を大きく変える といった手段は、そう簡単には選べませんでした。 代わりに選ばれてきたのが、次のような「運用でなんとかする」アプローチでした。 夜間バッチの監視を人手で行う エラーが出た時の「再実行手順」や「再起動ナレッジ」を運用でカバーする 繁忙期だけ一時的に増強する いわゆる「運用回避」と呼ばれるパターンで、当時はコンピューティングリソースが高価だったからこそ、これがもっとも現実的で、費用対効果の良い選択肢でした。 リファクタリング検討チームの関心事からこういった論点が抜け落ちてしまうのは、当時の前提に立てば、合理的な判断だといえます。 しかし現在は状況がすっかり逆転しています。 コンピューティングリソースは劇的に安価になり、必要に応じて余裕を持って積んでおくことが現実解になった 自動化技術が高度になり、「必要な時に短時間だけ一時的に」増強する、あるいは調子が悪くなったコンポーネントを瞬時に立ち上げ直すことが、現実的な選択肢になった 一方で、熟練したOps人材の時間と採用・育成コストは、相対的に非常に高くなった にもかかわらず、かつてと同じ感覚で 「まずは運用でカバーする」 「構造を変えるのは最後の手段にしよう」 という意思決定を続けてしまうと、そのツケは人的コストと運用品質リスクのかたちで静かに積み上がっていきます。 かつては正しかったこうした「運用回避」の発想が、今やOpsの時間をじわじわと食い潰す構造的な罠になっている。ここが、現在のモダナイゼーションやリファクタリングを考える上での重要なポイントです。 Ops視点でマイクロサービスアーキテクチャを選ぶ3つの理由 これまでみてきたような「運用回避依存の罠」から抜け出すために、マイクロサービスアーキテクチャはどのような役割を果たせるでしょうか。 Ops視点で整理すると、マイクロサービスを選ぶ理由は大きく次の3つに分けられます。 人的コストを削減し、自動化しやすい構造を作る いわゆる「SRE (Site Reliability Engineering)」に繋がる領域です。 例えばあるお客様の事例では、「運用業務の95％は自動化されており、残りの5％だけは、手動で実施した方が効率が良いのであえて人がやっている」というお話を伺ったことがあります。 ここまで自動化できる組織のSREは、従来のOpsとは役割の重心が異なります。 イメージとしては、運用手順をドキュメント化するだけでなく、その手順自体をコードとして実装し、継続的に改善していく姿に近いでしょう。 ただし、このような自動化を進めるためには、前提として アーキテクチャレベルで運用パターンをそろえておくこと 自動化しやすい単位でシステムを分割しておくこと 自動化に適した技術スタックと、コンポーネント内部の作り (12-Factor等) を採用すること が必要になります。 マイクロサービスアーキテクチャやIaC (Infrastructure as Code)、OpenShift等のコンテナ管理基盤は、まさにこの条件を満たすための選択肢として採用されます。 つまり、「人が頑張って守る運用」から「構造とコードで守る運用」へとシフトするための土台として、マイクロサービス化が位置づけられるわけです。 こうして自動化の土台が整うと、Ops や SRE の役割も「障害対応の最前線」から、「システム全体の安定性と改善をデザインする仕事」へとシフトしていきます。 キャパシティ計画の戦術の骨格を作る キャパシティ計画を健全に行うには、「戦略的にどこにどれだけのキャパシティを割り当てるか」を考え、それを実現できる構造が必要です。 お客様環境のアセスメントをさせていただくと、キャパシティのボトルネックは、ほとんどの場合で DB に集中しています。 しかも、DB に含まれる多くのテーブルのうち、本当に問題になるのはごく一部の「非常によく使われるテーブル」だけ、というケースがほとんどです。 ところが単一モノリス構成で、DB がいわゆる「統合 DB」になっている場合、この一部のホットなテーブルのために、システム全体の DB キャパシティや並列度を大きく引き上げざるを得ません。 いくらコンピューティングリソースが安価になったとはいえ、このやり方では「使われていない部分」にもリソースを盛ることになり、どうしても無駄が目立ってしまいます。 リソース効率を上げ、無駄を減らすには、 よく使われるテーブルだけを対象に、データ利用目的ごとに最適な形にして分割する その利用目的ごとに必要なキャパシティに応じてスケールアウトできるようにしておく という戦術が取れるようにしておくことが有効です。 この文脈でのマイクロサービスアーキテクチャの採用は、同時接続数やCPU、メモリ等を利用目的ごとにアプリケーションレベル、およびデータストアレベルで観測し、よりピンポイントで効果の高い戦術の実行を可能にします。 SLAを「偶然ではなく戦略的に」担保する 「運用回避の罠」を繰り返すと、そのツケは人的コストと運用品質リスクのかたちで静かに積み上がっていきます。 積み上がったシステムのお守りをしている Ops は疲弊しており、 夜間・繁忙期の人的オペレーションでなんとか止めずに回し 月次のレポートでは「SLA 達成」とだけ報告し その裏で起きている“綱渡り状態”について、改善提案を出す余力が残っていない といった状況に陥りがちです。 ここで本来問うべきなのは、次の 2 点です。 SLA を守るために、どれだけの人手と時間を燃やしているのか その人手と時間に、経済的合理性はあるのか モノリス構造のままでは、障害や変更の影響範囲が広く、 結果として「とにかく慎重に扱う」以外の選択肢を取りづらくなります。 つまり、SLA を守るためのコストとリスクを、人の努力以外でコントロールする手段が乏しいのです。 この文脈でマイクロサービスアーキテクチャを採用すると、 SLA を守るための“前提条件そのもの”を、アーキテクチャ側でデザインし直すことができます。 例えば： 障害箇所をサービス単位に分割し、「どこまで止まるか」をコントロールできる 重要度の高いサービスと、そうでないサービスで、優先順位や復旧目標(SLO)を分けやすくする 変更・リリースの影響範囲やロールバック単位を、サービスごとに小さく保ちやすくする Observability (可観測性) を活用し、SLA の遵守状況をリアルタイムなデータとして把握・判断しやすくする 外向きの SLA の数値が同じであっても、 「SLA は守れているが、そのために毎月誰かが燃え尽きている」状態 と 「SLA は守れているし、Ops メンバーもきちんと夜安心して眠ることができる」状態 では、 ビジネスとしての健全性も、広い意味での事業継続性も、まったく異なります。 マイクロサービスを Ops 視点で選ぶ 3 つ目の理由は、SLA 達成を現場の頑張りと偶然に任せるのではなく、人手だけに依存せず、アーキテクチャ設計・自動化・基盤の仕組みを組み合わせて戦略的に担保できる状態に変えるためと言えるでしょう。 でも、マイクロサービスアーキテクチャって運用が大変なんでしょう？ ここまでOps視点でのメリットをお話ししてきましたが、ここまで読んでくださった方の頭にはある「大きな疑問」が浮かんでいるのではないでしょうか。 「言いたいことはわかる。でも、サービスが細かく分かれれば、その分だけ管理対象が増えて、結局運用は大変になるんじゃないの？」 おっしゃる通りです。確かにシステム構成図上の「見た目の複雑さ」は増します。 しかし、ここで重要なのは、「どのような種類の複雑さを選ぶか」という選択です。 モノリスなシステムは、構成図はシンプルですが、一度トラブルが起きると「どこで何が起きているか」が外からは見えにくく、原因究明にはログの山と格闘し、ベテランの勘と記憶を頼りに推理するしかありません。 これは、「人手と脳内で管理しなければならない複雑さ」が高い状態です。 一方でマイクロサービスアーキテクチャは、ドメイン駆動設計 (DDD) 等で適切に境界が定義されている前提であれば、構成要素は多いものの、通信や依存関係が明確です。 ここに「Observability (可観測性)」の技術を組み合わせることで、これまでブラックボックスだった内部の動きやボトルネックを徹底的に可視化することができます。 「どこで詰まっているか」「どのサービスがエラーを吐いているか」が、人の勘ではなく、ダッシュボード上の事実として即座に特定できる状態を作れるのです。 つまり、マイクロサービス化とは、運用の複雑さを「人の頭の中(暗黙知)」から「仕組みと構造(形式知)」へと引っ張り出す転換なのです。 運用の安定を「ベテランの勘と偶然」に頼る世界から脱却し、「可視化された根拠と仕組み」へと昇華させる。 一見大変そうに見える道のりの先に、Opsが本来手に入れたかった「枕を高くして眠れる夜」が待っています。 まとめ 前回と今回の記事をお読みくださったみなさま、本当にお疲れさまでした。 「思ったより技術の話が出てこないんですけど！」と思った方もいるかもしれません。 リファクタリングは一見すると「利用者から見える新しい機能は増えないのに、お金と時間だけかかる取り組み」に見えます。 しかしその本質は Dev 側では「新しい価値を生むコーディング時間を取り戻す」ための投資 Ops 側では「人が燃え尽きないかたちでサービスを守り続ける」ための投資 と捉えるのが自然です。 RehostやReplatformだけでは、これらの構造は本質的には変わらず、システムにかかるコスト構造や、人的リソースへの依存度に与えられる影響はどうしても限定的です。 どこまで構造を変えるべきか、どこまでを既存のまま許容するか、その判断は個々の技術要素の優劣ではなく、 どれだけの人的コストと運用品質リスクを、今後も背負い続けるのか どこまでを人の頑張りからアーキテクチャと自動化に置き換えるのか という観点から決めるべきテーマです。 リファクタリング案件では、よく「どの技術を採用すべきか」「どのアーキテクチャパターンが正解か」といったご相談をいただきます。 また、リファクタリングの予算を獲得するための説明や、一つ一つの意思決定に悩まれるケースも少なくありません。 その理由はシンプルで、「正解」が技術領域の中だけには存在しないからです。 これらは本来、「事業継続マネジメント (BCM)」の一環として考えるべきテーマであり、経営に近いレイヤーの判断が必要な領域です。 前回・今回の記事では、その点を意識して書いてみました。今後、リファクタリングプロジェクトの方針や予算訴求で迷うことがあれば、ここで挙げた観点を「ネタ帳」として参照していただければ幸いです。 本シリーズ次回の記事は、前回と今回の記事で触れた技術を深掘りしてみたいと思います。 おまけ 最後に、少し個人的な「未来予測」を添えさせてください。 ここ最近、「マイクロサービスは複雑すぎる」という揺り戻しもあり、トレンドとしては少し落ち着きを見せている (あるいは幻滅期にある) と言われています。 しかし私は、今後マイクロサービスアーキテクチャは、生成AI (GenAI) の活用と共に、再び脚光を浴びることになると予測しています。 理由はシンプルです。 今回お話しした「明確な境界」と「構造化された仕組み」を持つマイクロサービスの世界は、GenAI と極めて相性が良いからです。コンテキストが明確に分割され、インターフェースが定義されている環境は、AI がコードを理解し、自律的に支援を行うための理想的な遊び場 (Playground) でもあります。 逆に言えば、長年の歴史的経緯やさまざまな事情が地層のように折り重なってできあがった巨大なモノリスを、魔法のように読み解いてくれる AI は、少なくとも近い将来には現れないだろうと考えています。 人間にとって歯ごたえがありすぎる対象は、GenAI にとっても同様に負荷が高く、期待できるアウトプット品質にもおのずと限界があります。 今の苦しみを解消するための構造化投資は、来たる AI 共存時代への「入場チケット」でもあります。来年の今頃、あるいは再来年の今頃、この予測の答え合わせができるはずです。そういう意味でも、このアーキテクチャスタイルは、今こそ再注目に値すると考えています。 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？  Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」  ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。  www.redhat.com

こんにちは、Technical Account Manager (TAM) の鈴村圭史です。 はじめに Red Hat Developer Hub (RHDH) は、Backstage をベースとした開発者ポータルプラットフォームとして注目を集めています。しかし、「実際に触ってみたいけれど、検証用の OpenShift クラスタを準備するのは少しハードルが高い…」と感じている方も多いのではないでしょうか。 そんな方に朗報です。GitHub の redhat-developer/rhdh-local を使えば、お手元のノート PC（Podman / Docker）だけで、数コマンドで RHDH を立ち上げることができます。 今回は、この RHDH Local を使って、ローカル環境で開発者ポータルを立ち上げる方法をご紹介します。 OpenShift 上での RHDH については、既にブログにありますのでご参考ください。 rheb.hatenablog.com RHDH Local とは？ RHDH Local は、プラットフォームエンジニアが RHDH の機能をローカルでテストするための「最速かつシンプル」な手段です。 通常、RHDH は OpenShift 上での動作を前提としていますが、このプロジェクトを利用することで、以下のような検証をクラスタなしで実行できます。 ソフトウェアカタログの表示・構成テスト TechDocs のレンダリング確認 動的プラグイン (Dynamic Plugins) のインストールと設定 ソフトウェアテンプレートの動作確認 UI のカスタマイズ（ホームページや外観） 注意点: RHDH Local は開発・テスト用であり、製品環境での使用は想定されていません。また、公式の商用サポート対象外（Community Support）である点にご留意ください。 クイックスタート：3分で立ち上げ 前提条件として、Podman (v5.4.1+) または Docker (v28.1.0+) がインストールされている必要があります。 以下のコマンドをターミナルで実行するだけで準備完了です。 # リポジトリのクローン git clone https://github.com/redhat-developer/rhdh-local.git cd rhdh-local # Podman Compose で起動 podman compose up -d 起動後、ブラウザで http://localhost:7007 にアクセスしてください。「Guest」としてログインすれば、すぐに RHDH の管理画面を確認できます。 便利な活用ポイント RHDH Local には、単に立ち上がるだけでなく、検証をスムーズにするための工夫が凝らされています。 充実した内蔵ドキュメント 起動後のポータル内にある TechDocs には、RHDH Local 専用のガイドが組み込まれています。GitHub 連携の設定方法や、プラグインの開発手順などが網羅されているため、ドキュメントを読みながらその場で設定を試せます。 動的プラグインの反映も簡単 RHDH の強力な機能の一つである「動的プラグイン」の設定変更も、次のコマンドで反映可能です。 # プラグイン設定変更後の再インストールと再起動 podman compose run install-dynamic-plugins podman compose restart rhdh 多彩な拡張シナリオ README には、以下のような検証用ガイドも用意されています。 PostgreSQL 連携: インメモリ DB ではなく永続化 DB を使用する構成 プロキシ環境下のテスト: 企業内ネットワークを想定したシミュレーション Orchestrator 連携: ワークフロー開発のテスト Developer Lightspeed: AI 支援機能の試用 GitHub連携を支える便利なTips も RHDHを本格的に試す際、避けて通れないのがGitHub Appの設定です。RHDH Localには、この煩雑な作業を楽にする仕組みが備わっています。 1.認証情報を別ファイルで管理 RHDH Localでは、configs/extra-files/ 配下に認証情報を切り出し、インクルードする構成が推奨されています。 リポジトリ内の github-app-credentials.example.yaml を github-app-credentials.yaml にリネームして使用することで、本体の設定ファイルとは別に管理できます。 2.npx コマンドで認証情報の設定ファイルを作成 また、github-app-credentials.example.yaml をコピーやリネームして使わずとも、認証ファイルを半自動で作成することができます 認証情報のコピーアンドペーストや yaml ファイルでのインデントをミスなく設定することは大変です。そこで活用したいのが、次のCLIツールです。 # 予めご自身のデフォルトブラウザで、GitHub にログインした状態で、GitHubの組織名を指定して実行 npx @backstage/cli create-github-app <github-org-name> ? Select permissions [required] (these can be changed later but then require approvals in all installations) Read access to content (required by Software Catalog to ingest data from repositories), Read access to members (required by Software Catalog to ingest GitHub teams) GitHub App configuration written to github-app-backstage-test-local-ksuzumur-4-credentials.yaml This file contains sensitive credentials, it should not be committed to version control and handled with care! Here's an example on how to update the integrations section in app-config.yaml integrations: github: - host: github.com apps: - $include: github-app-backstage-test-local-ksuzumur-4-credentials.yaml このコマンドを実行するだけで： 必要な権限が正しく設定された GitHub App が自動的に作成されます。各権限などは実際の GitHub で確認し、適宜変更することをおすすめします。 作成後、設定に必要な認証 yaml ファイルが作成されます。この認証ファイルを、app-config.local.yaml などから参照するように記述を追加します。 integrations: github: - host: github.com apps: - $include: github-app-backstage-test-local-ksuzumur-4-credentials.yaml まとめ RHDH Local を使えば、リソースを気にせず自分の手元で RHDH のお手軽にお試しできます。 「Backstage や RHDH で何ができるのか？」「カタログをどう定義すべきか？」を検討する際の第一歩として、ぜひ活用してみてください。 詳細な構成や最新のアップデートについては、 公式リポジトリ をチェック！ 参考リンク: GitHub - redhat-developer/rhdh-local99 Red Hat Developer Hub 製品ページ

こんにちは。レッドハットコンサルティングチームの木嶋です。 AI やデータ連携が進み、システム同士が API を介して連携することが当たり前になった今、API は「個別の技術要素」ではなく、「アプリケーションアーキテクチャに組み込まれるべき前提条件」になりつつあります。 一方で API の実装のご相談というと、API セキュリティのご相談が大きな割合を占めることも少なくありません。 何をどこまで実装したらいいのかは引き続き手探りの状態が続いているように思われます。 こうした背景の中、NIST は Guidelines for API Protection for Cloud-Native Systems (SP 800-228) の正式版を2025/6に公開しました。 Draft 版の段階でも実践的で優れた内容でしたが、Published 版ではさらに整理され、より幅広い層が活用しやすいドキュメントへと成熟した印象を受けました。 このドキュメントはぜひともAPIセキュリティの教科書として直接読んでいただきたい。 なぜなら、プロジェクトの現場で受けるよくある質問がほとんどカバーされているからです。 タイトルには「Cloud-Native」と書かれていますが、内容的にはオンプレであってもモノリスであってもそのまま適用できるものとなっています。 Cloud-Native では内部構造も API 化されるため、API セキュリティの重要度がより高まる、という意味でのタイトルだと理解すると読みやすいと思います。 ですが英語ですし、やはりなかなか敷居の高さを感じる方も多いはずです。 ここではこのガイドラインをどう読み解けば良いか、「読み方」をご紹介します。 想定読者 メインターゲットは、Cloud-Native かどうかに関わらず、APIを扱っているバックエンド開発者やアーキテクトです。 また次のような方々も読んでいただくと、自分たちの関心事と API セキュリティ/ガバナンスの世界がうまく接続されるようになっています。 インフラ／ネットワーク担当者: ゼロトラスト前提でネットワークやセグメンテーションをどう設計すべきか、API Gateway・Service Mesh・WAAP それぞれの役割分担を整理する材料になります。 プラットフォームエンジニアリングチーム: OpenShift などのコンテナ基盤の上に、どのような API セキュリティ機能を「プラットフォームとして」載せていくべきかを検討する際のベースラインになります。 情報セキュリティ／CSIRT 担当者: API に起因するインシデントのパターンやビジネス影響の整理、既存ポリシーの棚卸し・強化の観点で参照できます。 プロダクトオーナー／プロジェクトマネージャー: 「どこまでやれば最低限で、どこから先が高度な取り組みか」を理解し、投資や優先順位付けを検討するための材料になります。 ガイドラインの位置付け NIST というと難しい標準文書を想像される方も多いかもしれませんが、本ドキュメントは API セキュリティの “教科書” として読める内容です。 特に優れているのは、 なぜその設計が必要なのか それを怠るとどんな事故につながるのか まで丁寧に言語化されていること。 プロジェクトの現場で API セキュリティを説明していると、 「そこまで必要でしょうか？」 という質問は避けられません。 そのとき、このドキュメントは “現場の暗黙知に対して、NIST が体系的にお墨付きを与えた” と言える非常に心強い存在になるでしょう。 構成と読み方のヒント 第1章：APIセキュリティの前提と世界観 第2章：脆弱性とビジネス影響 OWASP API Security Top 10 と強く連動 第3章：推奨コントロール（実装ガイド） Pre-Runtime（設計〜デプロイ） Runtime（運用） 各項目が Basic / Advanced に整理 第4章：アーキテクチャパターン API Gateway / WAAP / Service Mesh 等 私のような原理原則が大好きな人は1章から読むのが良いですが、プロジェクトの現場ですぐに使える知見が欲しい方には3章を軸に、時々1章や2章に遡って読むのがお勧めです。 つまりコントロール（対策）<--> 失敗パターン（事故の原因）を行き来しながら読む、というスタイルです。 英語ですし、わからないキーワードもあるかと思います。 お手持ちの生成AIにぜひ (3章の) REC-API-Xがなぜ必要か理解したいので、2章やOWASP API Security Top 10の解説などを参考に、もしこの対策を実施しなかった場合にどんな事故が起きるか (ホラーストーリー) を教えて と聞いてみてください。単なる仕様書の項目解説ではなく、設計判断の根拠がわかるように解説してくれるはずです。 実践にあたっての検討事項 ガイドラインそのものは私よりも生成AIの方がよっぽど上手く解説してくれます。 ですのでここでは、ドキュメントを把握した上で実践する際の検討事項をまとめておきたいと思います。 (APIだけでも) ゼロトラストの採用 このドキュメントは、いわゆる「境界防御モデル」を前提にしたものではなく、ネットワークの内側であっても、API間の通信はゼロトラスト前提で設計すべきという立場をとっています。 昨今のランサムウェア被害を見てもわかるように、一度境界が破られてしまうと、内部の横方向の移動 (ラテラルムーブメント) が容易になってしまいます。 特にAPIは機能の入り口です。APIを使って機能を実装しようということは、なんらかの処理の間にネットワークが必ず入るポイントを作るということでもあります。攻撃者から見ると、ここは非常に魅力的な侵入経路になります。 したがって、「境界の内側は無条件で信用する」のではなく、 すべてのリクエストごとに 「誰から」「どのサービスから」「何をしようとしているか」 を毎回検証するという考え方が基本になっています。 コンテナ管理基盤の活用 前項で整理した通り、API セキュリティにおいてゼロトラストを実現するためのキモは大きく以下の 3 点です。 不要な通信経路を作らない（＝侵入経路を極力減らす） 通してよい通信であっても、すべて検査する この 2 つを、すべての API に漏れなく適用する 理屈としてはシンプルですが、これを現実のシステム全体に適用しようとすると、 通信経路の設計 認証・認可の実装 ログ・監査・可視化 設定の一貫性とメンテナンス といった観点で、かなりの運用コストがかかります。 NIST SP 800-228 の第4章では、API Gatewayの実装パターンとしてCentralized / Hybrid / Distributed の3 つのモデルが紹介されています。 特にゼロトラスト原則に最も適合する Distributed パターン（サービスメッシュ等）を実装する場合、コンテナ基盤は非常にフィットしやすい選択肢のひとつです。 この前提があると、mTLS や SPIFFE ベースのサービスアイデンティティ、粒度の細かい流量制御やアクセスコントロールといった仕組みも、「都度アプリごとに実装する特別な仕掛け」ではなく、 プラットフォーム側で共通機能として用意し、 開発者が必要な項目を設定するだけで利用できる機能 として提供できるようになります。 ここまで読んで「導入や学習、移行のコストが高くつきそうだ」とお感じになった場合、おそらくそれは正しいはずです。 ただし、API の本数や関わるチームの数が増えれば増えるほど、1 本の API を安全に保つための平均コストは、むしろこうしたプラットフォーム機能をうまく活用するアプローチの方が下がっていきます。 各チームが個別にライブラリを組み込んで、都度レビューとテストを行う世界と比べると、 セキュリティポリシーの設計・更新は中央（プラットフォームチーム）に集約し、 開発チームは最小限の情報を提供するだけで済むようにし、 配布と適用はコンテナ基盤とサービスメッシュが自動で行う という役割分担にすることで、「人手で追いかけ続けるコスト」や「レビュー待ちのボトルネック」を大きく減らし、ガバナンスを確実に実行するためのランニングコストを抑えることができます。 アプリケーションプラットフォームの整備 もちろん、「設定するだけで安全な API が手に入る世界」を実現するためには、その裏側でかなりの設計と運用の工夫が必要です。 ここで重要になるのが、近年注目されている Platform Engineering の考え方です。 NIST SP 800-228 でも、API セキュリティを組織横断で支えるための「API プラットフォームチーム」や「セルフサービス型の基盤」が明確に言及されています。 日本でもすでに多くの組織で、インフラ/プラットフォームチームが インフラ基盤を整備し、開発チームがセルフサービスで使える形にする Platform Engineering 活動が進んでいます。 NIST SP 800-228 が求めているのは、そこから一歩踏み込んで、 ネットワークやコンピュートといった基盤だけでなく API セキュリティに必要な機能一式（認証・認可、流量制御、監査・可視化など）を まとめてプラットフォーム側で提供する、いわば 「アプリケーションプラットフォーム」として成熟した姿だと捉えることができます。 なお、このガイドラインを読んで、 「ではセキュリティレビューを強化するために、API プラットフォームチームで全件レビューをしよう！」 という方向に振り切るのは、あまりおすすめしません。 API の歴史の中で、「人手を増やしてレビューを頑張る」アプローチは、すでに多くの組織が試してきました。 しかし API の数と変更頻度の増大、そしてセキュリティ人材の確保難易度の高さから、いずれもどこかで限界を迎え、方向転換を余儀なくされています。 だからこそ本ガイドラインでも、人手による個別対応ではなく、「セルフサービス型の基盤」としてセキュリティを組み込む方向性も同時に打ち出されているのだと考えられます。 アイデンティティ管理基盤の整備 そこで忘れてはならないのが、アイデンティティ管理基盤そのものもアプリケーションプラットフォームの一部として整備されていることです。 認証・認可に必要な情報（ユーザー/サービスの属性やロール、グループ、組織情報など）が、この基盤に適切に集約されていることが前提になります。 NIST SP 800-228 では、API 側から見ると 「どのユーザーか」 「どのサービスか」 「どのような属性を持っているか」 といった情報が、あたかも当然のように利用できる前提で議論が進みます。 しかし現実のプロジェクトでは、この前提が満たされていないケースも少なくありません。 人事システム、ディレクトリサービス（Entra ID / AD）、各業務システムがそれぞれバラバラに属性を持っており、 どこを「認可判断のための信頼できる情報源（Source of Truth）」とするかが曖昧なままになっていることも多いのではないでしょうか。 API セキュリティの観点から見ると、 どの属性をどこで管理し どの範囲までをアイデンティティ基盤でカバーし どこから先を各アプリケーションに委ねるか という設計が非常に重要です。 その意味で、アイデンティティ管理基盤は単なる「認証のための仕組み」ではなく、 アプリケーションプラットフォームの中核コンポーネント として設計・運用していく必要があります。 適切な流量制御の実装 いわゆる情報セキュリティの「CIA」のうち、A = Availability (可用性) も忘れてはいけません。 NIST SP 800-228 では、レートリミットやタイムアウト、サーキットブレーカーといった仕組みが、 性能チューニングではなく セキュリティコントロール として扱われています。 よく流量制御のご相談で、 「API Gateway とサービスメッシュ、どちらで制御すべきでしょうか？」 というご質問を頂戴しますが、NIST SP 800-228 はこの問いにも明確に答えています。 両方です。 日本語ではどちらも「流量制御」という表現になってしまいますが、もともと API Gateway が持つ Quota のコントロール と、 サービスメッシュが持つ Rate Limit のコントロール は、「守る場所」と「目的」が異なります。 昨今のシステムでは、Gateway とバックエンドの間に Camel 等による API 連携処理や、複数の処理を集約する「アグリゲーション層」 が介在することが一般的です。クライアントからの 1 つのリクエストが、アグリゲーションを経由することで複数のマイクロサービスへのリクエストに「増幅 (ファンアウト)」されたり、複雑に変換されたりします。 つまり、入り口 (Gateway) でどれだけ綺麗に整流しても、その先でアプリケーション (アグリゲーション等) がリクエストを増幅した結果、バックエンドの各サービスが過負荷に陥る、という状況は現実的に起こり得ます。 予期せぬリクエストの増幅から個々のサービスを守る「最後の防波堤」として、サービス直近 (サービスメッシュ) での制御が不可欠になるわけです。 また、API Gatewayによく実装されているQuota はどちらかというと ビジネス観点の流量制御 であり、 課金プラン フェアユースポリシー 顧客やパートナーごとの利用上限 といった契約条件を表現するための機能です。 対象期間も 1 日や 1 か月など、比較的長い期間を扱うのが特徴です。 一方で、API セキュリティの観点から重要なのは、 Rate Limiting やバックプレッシャー、リトライ制御 の方です。これは、 誤実装やバグによる内部からの DoS 善意の業務ユーザーによる「連打」や大量実行 外部からの自動攻撃・クレデンシャルスタッフィング などから、システム全体を守るための 防波堤 として機能します。 コンテナ基盤と Service Mesh、API Gateway を組み合わせることで、 「どのクライアント（ユーザー／サービス）から」 「どの API に対して」 「どのくらいの頻度まで許容するか」 といったルールを、一貫したポリシーとしてプラットフォーム側に実装できます。 ここでもポイントは、 アプリごとに個別実装するのではなく 、 プラットフォームが共通の流量制御の “ガードレール” を提供することです。 その上で、各アプリケーションチームが自分たちの特性に応じた閾値を設定していく、という分担が現実的だと考えています。 まとめ ここで触れたのは、NIST SP 800-228 に含まれる内容のごく一部です。 境界防御ではなくゼロトラスト前提で API を設計すること コンテナ基盤と Service Mesh を活用して「設定すれば守れる」土台をつくること アプリケーションプラットフォームとして API セキュリティをまとめて提供すること それを支えるアイデンティティ管理基盤 そして、可用性を守るための流量制御をセキュリティ要件として扱うこと といった観点は、その中でも特に「アーキテクチャやプラットフォーム設計に効いてくる部分」です。 このほかにも、DevSecOps の確立と、それを可能にする Contract-Driven な開発（OpenAPI などの仕様を「プラットフォームへの入場チケット」とする考え方）など、内容は盛りだくさんです。 ぜひ一度、ご自身のプロジェクトの構成図や現状の課題を思い浮かべながら読んでみてください。 大事なのは、単一の API サーバーを守ることではなく、 組織横断で「すべての API」をどう守るか を考えることです。 セキュリティは、どれだけ一部を厚く守っても、「一番弱いポイント」から破綻するからです。 そのための一歩は自分たちのシステムから。 現在の自分たちのシステムでどう守れるかを考える一助になりましたら幸いです。 おまけ: 「この記事本当？」を検証するためのプロンプト Red Hat のブログなので、 これ、Red Hat に都合よく加工されてない？ と思われる方もいるかもしれません。 そのあたりは、ぜひみなさんの手元の GenAI と NIST SP 800-228 本文で好きなだけ検証していただきたいので、そのためのプロンプト例を置いておきます。 もしこの記事を読んで、 本当に NIST SP 800-228 はこんなことまで書いてあるの？ と思われた方は、お好みのモデルにガイドラインドキュメントを添付した上で、次のように投げてみてください。 あなたは NIST SP 800-228 「Guidelines for API Protection for Cloud-Native Systems」を読み込んだ API セキュリティの専門家です。 次の主張が、NIST SP 800-228 の内容とどの程度一致しているかを評価し、 根拠となる章番号・REC-API 番号とともに解説してください。 1. API セキュリティは、境界防御ではなくゼロトラスト前提で設計すべきである。 2. コンテナ基盤やサービスメッシュは、ゼロトラストな API セキュリティを 「プラットフォームとして」実現するための代表的な手段として示されている。 3. API セキュリティを組織横断で支えるために、API プラットフォームチームや セルフサービス型のアプリケーションプラットフォームのモデルが推奨されている。 4. アイデンティティ管理基盤は、認証・認可に必要な属性情報を集約し、 SSoT（Single Source of Truth）として扱える形にすることが望ましい。 5. レートリミットやタイムアウト、サーキットブレーカーなどの流量制御は、 可用性を守るためのセキュリティコントロールとして位置付けられている。 それぞれについて、 - 「おおむね正しい」「一部誤解を含む」「不正確」などの評価 - NIST SP 800-228 のどの記述が根拠になるか - 実務で適用する際の補足ポイント を日本語で教えてください。 このプロンプトをベースに、ご自身のプロジェクトで気になっている論点（例: 「Service Mesh にどこまで責務を持たせるべきか」など）を追加していくと、 「自分たちの前提や設計は、このガイドラインの観点から見てどうか？」 を中立な視点で確認する良いきっかけになると思います。

　こんにちは、レッドハットでソリューションアーキテクトをしている石川です。昨年11月にリリースされたOpenShift AI 3.0の中で llm-dがGA となりました。llm-dはRed Hat Summit 2025で発表された分散推論のためのオープンソースプロジェクトです。 　LLMの推論処理は、Kubernetes環境で取り扱うことが多いステートレスアプリケーションと異なり、KV Cacheに依存するステートフルなアプリケーションとして実行されます。Kubernetesのデフォルトの仕組みであるServiceではステートレスなアプリケーションへのトラフィックをクラスタ内部で効果的にロードバランシングできますが、LLMの推論を効率的に行うにはその処理特性を踏まえた別の仕組みが必要です。llm-dではこうした推論リクエストを適切に処理するための機能が実装され、推論環境を効率的にスケーリングすることを可能とします。 　今回のブログではllm-dを実際にデプロイして、アーキテクチャや動作について確認してみたいと思います。 llm-dのアーキテクチャ 　llm-dのGitHubリポジトリを確認すると以下のアーキテクチャ図を確認できます。 　llm-dにおいて、推論リクエストはまずInference Gatewayに対して行われます。このInference GatewayはKubernetesのGateway APIを通じてデプロイされるコンテナで、実態としてはenvoyが動作します。llm-dではKubernetes上でモデルの推論を効率的に行うプロジェクトである Gateway API Inference Extension（GIE） の仕組みをベースとしており、envoyの External Processing という機能を利用し、envoy外部のInference Schedulerにアクセスして、推論リクエストを送信するバックエンドのvLLM Podを決定します。このInference SchedulerはEndpoint Picker（EPP）とも呼ばれます。 　推論処理を行うvLLM PodのグループはInferencePoolというリソースで管理します。Gateway APIでは、HTTPRouteというリソースの中で、Gatewayからの通信のバックエンドを設定しており、ここにInferencePoolを設定することで、EPPにより選ばれたvLLM Podへ推論リクエストを送信します。 HTTPRouteの例 apiVersion : gateway.networking.k8s.io/v1 kind : HTTPRoute metadata : name : llm-d-kv-events spec : parentRefs : - group : gateway.networking.k8s.io kind : Gateway name : infra-kv-events-inference-gateway rules : - backendRefs : 　# InferencePoolをバックエンドに設定 - group : inference.networking.k8s.io kind : InferencePool name : gaie-kv-events port : 8000 weight : 1 timeouts : backendRequest : 0s request : 0s matches : - path : type : PathPrefix value : / Endpoint Picker 　llm-dではどのようなデプロイパターンにおいても、バックエンドのvLLMに対し推論リクエストをどのようにスケジューリングするかが重要となり、EPPがその中心的な役割を担います。EPPではどのようなルールでスケジューリングを実行するかを複数のプラグインの組み合わせで決めます。以下はllm-dにおけるEPPの設定例です。 apiVersion : inference.networking.x-k8s.io/v1alpha1 kind : EndpointPickerConfig plugins : - type : single-profile-handler - type : prefix-cache-scorer - type : load-aware-scorer - type : max-score-picker schedulingProfiles : - name : default plugins : - pluginRef : prefix-cache-scorer weight : 2.0 - pluginRef : load-aware-scorer weight : 1.0 - pluginRef : max-score-picker 　このEndpointPickerConfigは後述するLLMInferenceServiceや、ConfigMapの中に記載します。 .plugins 以下では、プラグインと各プラグインに設定するパラメーターを記載し、 .schedulingProfiles で実際に利用する際の組み合わせと、プラグインごとのスコアの重みづけを行います。これによりどのようなルールでスケジューリングを行うかを定義します。 　プラグインの中のScorerでは、推論を実行するvLLM Podの中でどれを優先するかのスコアを計算します。上記の例では以下の二つのScorerを利用しています。 prefix-cache-scorer : 過去リクエストのハッシュ値をメモリに保存し、新たなリクエストが来た際に一致する最も長いハッシュ値を持つvLLM Podを優先するようスコアリング。 load-aware-scorer : 各vLLM Podの処理キューの情報を元に、処理の空きがあるPodを優先してスコアリング。 　EPPで利用できるベースとなるプラグインは GIEのリポジトリ で開発されていますが、llm-dに特化したプラグインに関しては llm-d/llm-d-inference-scheduler で個別に開発されています。 llm-dのドキュメント でも触れられていますが、推論に関わる汎用的な機能に関してはGIEで実装し、llm-d側では分散推論に関わる独自機能を個別に実装する方針のようです。 llm-dのデプロイ 実行環境の準備 　本ブログではAWSのManaged OpenShiftであるROSAを利用し、その環境にOpenShift AIをインストールしたのち、llm-dをデプロイします。OpenShiftクラスタの構築方法やGPU Operatorの設定についての説明は割愛するため、これらの手順については 公式ドキュメント や 以前のブログ記事 などを参照して下さい。以降では以下の条件を満たしていることを前提に手順を記載します。 OpenShift Container Platformのバージョン4.19.9以降をインストール済みであること LLMを実行可能なGPU Nodeがクラスタに存在すること GPUデバイスが2台以上あること NVIDIA GPU Operator、NFD Operatorの設定を行い、GPUリソース（nvidia.co/gpu）を利用可能なこと OpenShift Service Meshのバージョン2をインストールしていないこと Serviceのtype: LoadBalancerを利用して外部からアクセス可能なこと（ベアメタルの場合、MetalLBをインストール） OpenShift AI 3のインストール 　OpenShiftコンソールから、エコシステム->ソフトウェアカタログを選択し、OpenShift AIのOperatorを検索します。2026年1月現在OpenShift AI 3はfast-3.xチャネルからのみインストールが可能です。ROSAの場合、インストール時にロールARNの設定を求められますが、"none"を設定し、その他の設定についてはデフォルトのままインストールします。 　Operatorをインストールしたら、OpenShift AIをデプロイするためのカスタムリソースであるDataScienceClusterについてもデフォルト設定で作成します。ステータスがReadyになれば準備完了です。 　OpenShift AIのバージョン3以降では、OpenShiftのデフォルトリソースであるRouteではなく、Gateway APIを利用してコンソール等へのアクセスを行います。OpenShift AIの設定を行うと、自動でGatewayClassリソースが作成され、 Istio実装のGateway を利用できるようになります。 # 作成されたGatewayClassの確認 $ oc get gatewayclass NAME CONTROLLER ACCEPTED AGE data-science-gateway-class openshift.io/gateway-controller/v1 True 21m このGatewayClassを利用してllm-dで利用するGatewayを作成します。 apiVersion : gateway.networking.k8s.io/v1 kind : Gateway metadata : labels : istio.io/rev : openshift-gateway name : openshift-ai-inference namespace : openshift-ingress spec : gatewayClassName : data-science-gateway-class listeners : - allowedRoutes : namespaces : from : All hostname : inference-gateway.apps.<cluster-domain> name : https port : 443 protocol : HTTPS tls : certificateRefs : - group : '' kind : Secret name : default-gateway-tls mode : Terminate 　<cluster-domain>の部分は自身が利用しているドメインに書き換えてください。 ここではallowedRoutesの設定より全てのNamespaceでこのGatewayの利用を許可していますが、Selectorを設定することでこのGatewayを利用可能なNamespaceを限定することもできます。OpenShift AIでllm-dをデプロイすると、この openshift-ai-inference というGatewayがデフォルトで利用されます。 Kuadrantのインストール 　OpenShift AIのllm-dでは Kuadrant を利用して推論時の認証を行っています。KuadrantとはGateway APIの Policy Attachment の仕組みを利用して、Gatewayに対して様々なポリシー設定を可能にするオープンソースプロジェクトです。OpenShift AI 3でDeveloper Previewとなった Model as a Service の機能でも利用され、そちらではLLMの推論リクエストに対するレートリミット設定などを行っています。Red HatではRed Hat Connectivity Linkという名前でKuadrantを製品として提供しているため、そちらを利用します。 　OpenShiftコンソールのソフトウェアカタログからRed Hat Connectivity Linkを検索しインストールします。この時インストール先のNamespaceとして kuadrant-system を新たに作成して指定します。 　Operatorをインストールしたら Kuadrant リソースを kuadrant-system に作成します。 # Kuadrantリソースの作成 $ oc apply -f - <<EOF apiVersion: kuadrant.io/v1beta1 kind: Kuadrant metadata: name: kuadrant namespace: kuadrant-system EOF $ oc wait Kuadrant -n kuadrant-system kuadrant --for = condition =Ready --timeout = 10m kuadrant.kuadrant.io/kuadrant condition met 　llm-dで認証を利用するために必要な設定を実施します。 $ oc annotate svc/authorino-authorino-authorization service.beta.openshift.io/serving-cert-secret-name = authorino-server-cert -n kuadrant-system $ sleep 2 $ oc apply -f - <<EOF apiVersion: operator.authorino.kuadrant.io/v1beta1 kind: Authorino metadata: name: authorino namespace: kuadrant-system spec: replicas: 1 clusterWide: true listener: tls: enabled: true certSecretRef: name: authorino-server-cert oidcServer: tls: enabled: false EOF $ oc wait --for = condition =ready pod -l authorino-resource = authorino -n kuadrant-system --timeout 150s $ oc delete pod -n redhat-ods-applications -l app =odh-model-controller $ oc delete pod -n redhat-ods-applications -l control-plane = kserve-controller-manager 　これで認証のための設定が完了しました。 LeaderWorkerSet Operatorのインストール (Option) 　llm-dでP/D DisaggregationやWideEPのデプロイを実施する場合、Kubernetesの LeaderWorkerSet(LWS) を利用します。OpenShiftではLeaderWorkerSet Operatorが利用できるため、ソフトウェアカタログから検索しインストールします。 　インストールしたら、以下のカスタムリソースを作成します。 $ oc apply -f - <<EOF apiVersion: operator.openshift.io/v1 kind: LeaderWorkerSetOperator metadata: name: cluster namespace: openshift-lws-operator spec: managementState: Managed logLevel: Normal operatorLogLevel: Normal EOF LLMInferenceService 　アップストリームのllm-dではhelmを使って各種コンポーネントをデプロイしていますが、OpenShift AIではKServeの LLMInferenceService というカスタムリソースを利用して、llm-dの実行に必要なコンポーネントを作成します。LLMInferenceServiceではGateway APIのHTTPRoute、EPP、vLLMなどを一つのカスタムリソースの中で設定しデプロイします。 　LLMInferenceServiceの設定例は以下のようになります。 apiVersion : serving.kserve.io/v1alpha1 kind : LLMInferenceService metadata : name : qwen3-06b-prefix-routing annotations : security.opendatahub.io/enable-auth : 'false' spec : model : uri : hf://Qwen/Qwen3-0.6B name : Qwen/Qwen3-0.6B replicas : 2 router : scheduler : template : volumes : - emptyDir : { } name : tokenizers containers : - name : main ports : - containerPort : 9002 name : grpc protocol : TCP - containerPort : 9003 name : grpc-health protocol : TCP - containerPort : 9090 name : metrics protocol : TCP - containerPort : 5557 name : zmq protocol : TCP volumeMounts : - mountPath : /mnt/tokenizers name : tokenizers readOnly : false args : - --pool-name - "{{ ChildName .ObjectMeta.Name `-inference-pool` }}" - --pool-namespace - "{{ .ObjectMeta.Namespace }}" - --pool-group - inference.networking.x-k8s.io - --zap-encoder - json - --grpc-port - "9002" - --grpc-health-port - "9003" - --secure-serving - --model-server-metrics-scheme - https - --model-server-metrics-https-insecure-skip-verify - --cert-path - /var/run/kserve/tls - '--v' - "4" - --config-text - |2 apiVersion : inference.networking.x-k8s.io/v1alpha1 kind : EndpointPickerConfig plugins : - type : single-profile-handler - type : prefix-cache-scorer - type : load-aware-scorer - type : max-score-picker schedulingProfiles : - name : default plugins : - pluginRef : prefix-cache-scorer weight : 2.0 - pluginRef : load-aware-scorer weight : 1.0 - pluginRef : max-score-picker route : { } gateway : { } template : containers : - name : main env : - name : VLLM_ADDITIONAL_ARGS value : "--disable-uvicorn-access-log --prefix-caching-hash-algo sha256_cbor --block-size 64 --kv-events-config '{ \" enable_kv_cache_events \" :true, \" publisher \" : \" zmq \" , \" endpoint \" : \" tcp://{{ ChildName .ObjectMeta.Name `-epp-service` }}:5557 \" , \" topic \" : \" kv@${POD_IP}@Qwen/Qwen3-0.6B \" }'" - name : POD_IP valueFrom : fieldRef : apiVersion : v1 fieldPath : status.podIP - name : PYTHONHASHSEED value : "42" resources : limits : cpu : '4' memory : 32Gi nvidia.com/gpu : "1" requests : cpu : '1' memory : 1Gi nvidia.com/gpu : "1" livenessProbe : httpGet : path : /health port : 8000 scheme : HTTPS initialDelaySeconds : 120 periodSeconds : 30 timeoutSeconds : 30 failureThreshold : 5 .spec.model : デプロイするモデルを指定します。上記ではHugging Faceから直接モデルをダウンロードするように設定していますが、それ以外に オブジェクトストレージや、PV、コンテナイメージを利用可能 です。 .spec.router : llm-dをデプロイする際のGatewayや、HTTPRoute、EPPの設定を行います。上記の例ではGateway、HTTPRouteについては空欄のためデフォルト設定を適用し、EPPに関しては .spec.router.scheduler で設定した内容に従ってデプロイします。先述のEndpointPickerConfigはこちらに設定します。 .spec.template.containers : vLLM Podの設定を行います。通常のvLLMの実行と異なる点として、実行時のオプションを VLLM_ADDITIONAL_ARGS という変数で渡す必要があるため注意してください。 　これ以外のデプロイパターン（P/D Diaggregation、各種のParallelism設定、等）に関しては以下のドキュメントを参照ください。 docs.redhat.com kserve.github.io llm-dの実行 　先ほどのLLMInferenceServiceをクラスタにデプロイし、llm-dを実行します。初回のみvLLMのコンテナイメージをPullしてくるため、少し時間がかかります。 # Namespace作成 $ oc new-project demo-llm # LLMInferenceServiceのデプロイ $ oc apply -f qwen3-06b-prefix-routing.yaml $ oc wait --for = condition =ready llmisvc qwen3-06b-prefix-routing -n demo-llm --timeout = 1200s $ oc get llmisvc qwen3-06b-prefix-routing 以下のコマンドで推論リクエストを実行します。 $ export LLM_URL = $( oc get llmisvc qwen3-06b-prefix-routing -o jsonpath = ' {.status.addresses[0].url} ' ) $ curl -X POST " $LLM_URL /v1/chat/completions " \ -H " Content-Type: application/json " \ -d ' { "model": "Qwen/Qwen3-0.6B", "messages": [ { "role": "system", "content": "You are a helpful assistant." }, { "role": "user", "content": "Hello" } ] } ' | jq . 正しく動作している場合、以下のように実行結果が返却されます。 実行結果 { " choices ": [ { " finish_reason ": " stop ", " index ": 0 , " logprobs ": null , " message ": { " annotations ": null , " audio ": null , " content ": " <think> \n Okay, the user just said \" Hello \" . I need to respond appropriately. Since they didn't ask a question, I should acknowledge their greeting. Maybe start with a friendly greeting, like \" Hello! \" to keep it simple. I should make sure my response is polite and open-ended so they feel comfortable. Let me check if there's anything else they might need, but since they just said \" Hello \" , a basic response should suffice. Alright, time to put it all together. \n </think> \n\n Hello! How can I assist you today? 😊 ", " function_call ": null , " reasoning_content ": null , " refusal ": null , " role ": " assistant ", " tool_calls ": [] } , " stop_reason ": null , " token_ids ": null } ] , " created ": 1767667429 , " id ": " chatcmpl-322fc85c-c2ac-4222-a4e0-8f3b1a6e591b ", " kv_transfer_params ": null , " model ": " Qwen/Qwen3-0.6B ", " object ": " chat.completion ", " prompt_logprobs ": null , " prompt_token_ids ": null , " service_tier ": null , " system_fingerprint ": null , " usage ": { " completion_tokens ": 112 , " prompt_tokens ": 20 , " prompt_tokens_details ": null , " total_tokens ": 132 } } ベンチマークの実行 　デプロイしたllm-dに対してパフォーマンスのベンチマークを実行してみましょう。以下の手順でPrometheus、Grafana等をインストールします。 # ベンチマーク用リポジトリのクローン $ git clone https://github.com/rh-aiservices-bu/rhaoi3-llm-d $ cd rhaoi3-llm-d # モニタリングアセットのデプロイ $ oc apply -k monitoring $ oc wait --for = condition =ready pod -l app =grafana -n llm-d-monitoring --timeout = 300s # Grafana URLの取得 $ export GRAFANA_URL = $( oc get route grafana-secure -n llm-d-monitoring -o jsonpath = ' {.spec.host} ' ) $ echo " Grafana URL: https:// $GRAFANA_URL " 　ベンチマークツールの推論エンドポイントを先ほどデプロイしたllm-dのエンドポイントに変更し実行します。 # エンドポイントの変更 $ # vi benchmark-job/overlays/llm-d/kustomization.yaml --- patch: |- - op: replace path: /spec/template/spec/containers/ 0 /args/ 0 # 以下を変更 value: " https://inference-gateway.apps.rosa.mycluster2.uwl9.p3.openshiftapps.com/demo-llm/qwen3-06b-prefix-routing/v1 " --- # ベンチマークの実行 $ oc apply -k benchmark-job/overlays/llm-d/ 　このベンチマークではチャットやコーディングのユースケースを想定し、マルチターンでの推論リクエストを実行します。llm-dではEPPが既存のKV Cacheを持つvLLM Podにリクエストをルーティングすることで、TTFT（Time to First Token）を早める効果を期待できます。 　ベンチマーク結果は以下のコマンドで確認します。 # 実行結果の確認 $ oc logs -f job/llm-d-multi-turn-benchmark -n demo-llm ---snip--- Time to First Token ( TTFT ) : Min: 50 . 99 ms Max: 254 . 22 ms Mean: 87 . 48 ms P50: 83 . 03 ms P95: 127 . 71 ms P99: 251 . 21 ms ---snip--- TTFT by Turn Number: Turn 1: 150 . 38 ms avg ( 11 requests ) Turn 2: 68 . 82 ms avg ( 11 requests ) Turn 3: 73 . 77 ms avg ( 11 requests ) Turn 4: 74 . 85 ms avg ( 11 requests ) Turn 5: 78 . 25 ms avg ( 11 requests ) Turn 6: 81 . 70 ms avg ( 11 requests ) Turn 7: 83 . 31 ms avg ( 11 requests ) Turn 8: 84 . 92 ms avg ( 11 requests ) Turn 9: 89 . 07 ms avg ( 11 requests ) Turn 10: 89 . 70 ms avg ( 11 requests ) TTFT by Document Type: CODE: 92 . 81 ms avg ( 50 requests ) TEXT: 83 . 03 ms avg ( 60 requests ) First Turn vs Subsequent Turns ( Prefix Caching Indicator ) : First turn avg: 150 . 38 ms Later turns avg: 80 . 49 ms Speedup ratio: 1 .87x 　Turn 1とTurn 2以降の結果を比較すると、Turn 2以降でのTTFTが低下していることを確認できました。また先ほどデプロイしたGrafanaのダッシュボードでKV Cache Hit Rateを確認できます。 　この結果と、llm-dを使わずにvLLMをそのままデプロイした場合の結果を比較してみましょう。LLMInferenceServiceを一度削除し、ServingRuntimeとInferenceServiceを利用してvLLMをデプロイします。 # LLMInferenceServiceの削除 $ oc delete llmisvc qwen3-06b-prefix-routing # vLLM Podのレプリカ数の変更 $ vi vllm/qwen/inference-service.yaml --- spec: predictor: automountServiceAccountToken: false # Replicasを2に変更 maxReplicas: 2 minReplicas: 2 --- # vLLMのデプロイ $ oc apply -k vllm/ $ oc wait --for = condition =ready pod -l serving.kserve.io/ inferenceservice =qwen-vllm -n demo-llm --timeout = 300s 　llm-dと同様にベンチマークを実行し、結果を確認します。 # ベンチマークの実行 $ oc apply -k benchmark-job/overlays/vllm/ # 実行結果の確認 $ oc logs -f job/vllm-multi-turn-benchmark -n demo-llm ---snip--- Time to First Token ( TTFT ) : Min: 40 . 02 ms Max: 368 . 80 ms Mean: 94 . 37 ms P50: 80 . 72 ms P95: 203 . 51 ms P99: 306 . 44 ms ---snip--- TTFT by Turn Number: Turn 1: 154 . 59 ms avg ( 11 requests ) Turn 2: 122 . 29 ms avg ( 11 requests ) Turn 3: 101 . 15 ms avg ( 11 requests ) Turn 4: 77 . 41 ms avg ( 11 requests ) Turn 5: 101 . 48 ms avg ( 11 requests ) Turn 6: 77 . 05 ms avg ( 11 requests ) Turn 7: 74 . 51 ms avg ( 10 requests ) Turn 8: 71 . 52 ms avg ( 9 requests ) Turn 9: 69 . 23 ms avg ( 9 requests ) Turn 10: 79 . 99 ms avg ( 8 requests ) TTFT by Document Type: CODE: 102 . 67 ms avg ( 46 requests ) TEXT: 87 . 54 ms avg ( 56 requests ) First Turn vs Subsequent Turns ( Prefix Caching Indicator ) : First turn avg: 154 . 59 ms Later turns avg: 87 . 09 ms Speedup ratio: 1 .78x 　二つの結果を比較すると、TTFTの平均値に関して、llm-dの方が若干改善しているのがわかります。またTTFTのパーセンタイルに関して、p95やp99のロングテールの結果がllm-dでは大きく改善されています。 p95: 203.51 ms(vLLM) -> p95: 127.71 ms(llm-d) p99: 306.44 ms(vLLM) -> p99: 251.21 ms(llm-d) KV CacheのHit Rateに関しては、llm-dと比較して約12%低下しており、この差がベンチマークの結果にも影響したと考えられます。今回の検証ではvLLM Podが二つだけでしたが、レプリカ数が増えるほど高い効果が期待できます。 まとめ 　本ブログではOpenShift AI 3.0でGAとなったllm-dについて紹介しました。今回はまず基本的なデプロイとしてPrefix Aware Routingを試しましたが、これだけでも複数PodでvLLMを実行するパターンでは非常に効果の高い方法だと感じます。今後もP/D Diaggregationなど、llm-dの別のパターンでのデプロイを試していければと思います。

※本記事は OpenShift Virtualization アドベントカレンダーの 25 日目の記事です。 qiita.com 皆さんこんにちは、OpenShift Virtualization とストレージを生業にしている Red Hat のうつぼ（宇都宮）です。 さあアドベントカレンダーも今日が最後です。まさか Virt で全部埋まるとは思っていなかったのですが、責任感の強い仲間達のおかげでなんとか完走できました。私は幸せもんです。 お付き合いくださった読者の皆様も、本当にありがとうございました。 最後はこれからの OpenShift Virtualization について、ロードマップ的なものを紹介したいと思います。 OpenShift Virtualization: What's Next Ease of Migration Networking Simplified & Scaled Administration Edge to Cloud Storage & Data Protection Security and Performance まとめ OpenShift Virtualization（以下 Virt）は結構にエンハンスされてきていて、割とリッチな feature を持っていると思います。 12/20 の記事で我らが坂井さんが、これまでの update について紹介してくださっています。 rheb.hatenablog.com しかし世界中でユーザーさんがガンガン増えており、たくさんの RFE（Request for Feature Enhancement）が届いております。 そのため Virt は止まることなく今後も開発が進みます。 OpenShift Virtualization: What's Next Red Hat 社内には、お客様やパートナー様との打ち合わせで使えるような Virt の Roadmap のスライドがあります。 公開可ではあるのですが、さすがにブログで直接スライドを出すのは違う気もするので、スライドの内容を文字で紹介していきます。スライドで見たいという方はお近くの Red Hat 担当者までお声がけ下さい。 それでは今後リリースされる予定となっている feature の 一部 （全部じゃない）をカテゴリごとに紹介しつつ、注目度の高いものをいくつかピックアップしてご紹介していきましょう。 Ease of Migration Live migration of VMs and Storage across clusters GA of Storage accelerated migration to OpenShift Migration from Hyper-V Self Guided Migration assistant ここで注目するのは何と言っても、 クラスタまたぎの VM / Storage Live migration 。 OpenShift クラスタを複数持つという選択肢は割と普通にありますが、その間で Live migration ができるようになります。 Blue/Green クラスタアップグレードをするために 2面クラスタを持つ場合、クラスタ間で VM を Live migration できれば、ダウンタイムを抑えられるのでいいですよね。 これは現在 Technology Preview として出ていますが、GA になる予定です。 docs.redhat.com なお、ここで開発の進捗が見られます。 https://issues.redhat.com/browse/VIRTSTRAT-96 Networking BGP and stretched L2 networks across clusters Single stack IPv6 ここでの注目は クラスタ間で L2 ブロードキャストドメインを共有し、VM が同一の L2 セグメント上に存在する構成 です。これを実現するのに BGP と EVPN (Ethernet VPN) を使います。 L2 を前提としたプロトコルを使うアプリが動く VM でもクラスタを自由に動けるようになったり、ハイブリッドクラウド構成を実現したり、様々なメリットがあると思います。クラスタまたぎの Live migration もこれを使うことでスムースにできるようになるでしょう。 マネージドサービス上の Virt にも L2 延伸的なアプローチができるかは、正直わかりません。GA になるまでのお楽しみとさせて下さい。 upstream の KubeVirt では次のように開発が進んでいます。 kubevirt.io Simplified & Scaled Administration Comprehensive multi-cluster virtualization and VM management VM Right Sizing actionable guidance Guided VM networking configuration Simplify troubleshooting with OpenShift AI ここでは マルチクラスタにおける包括的な VM 管理 について紹介します。 またまたマルチクラスタ関係ですが、複数クラスタにある VM を一元的に管理することができます。これを ACM（Red Hat Advanced Cluster Management）の機能として提供します。最新の ACM 2.15 では Technology Preview として出ています。 現在は上のような 非常に既視感の強い ツリービューがありましてこの中で各クラスタの VM が一元的に見ることができます。これが Redesign されて GA になる模様です。 https://issues.redhat.com/browse/CNV-69174 Edge to Cloud Two node HA Solution (no arbiter needed) for Edge deployments GA support for ARM platforms GA of GCP ここでは エッジコンピューティングユースケース向けの2ノード構成 に注目します。 TNA（Two Node with Arbiter）という構成が 4.20 でリリースされているのは、先の坂井さんの記事でも紹介されていますが、これは正真正銘の2ノード構成です。 split brain を回避するために Pacemaker を使って Fencing を織り込むため、TNF（Two Node with Fencing）とも呼ばれます。 TNF 構成自体は OpenShift 4.20 で Technology Preview になっていますが、Virt の文脈ではもっと先になることが予想されます。 Chapter 2. Two-node with Fencing | Installing a Two Node OpenShift Cluster | OpenShift Container Platform | 4.20 | Red Hat Documentation なお、TNA も TNF も基本的にエッジコンピューティングでの利用を想定しています。 Storage & Data Protection Change block tracking for Incremental backup 元のスライドにこれ1個しかないのでこれを紹介します。 CBT（Change Block Tracking）はストレージ上で write/rewrite されたブロックを記録するもので、差分（増分）バックアップや DR の差分レプリケーション、移行などで主に利用されます。 VMware では CBT が VMDK レイヤーの機能として実装されていますが、それに相当するものを QEMU レイヤーで実装しようというのがこれです。 これによってバックアップや DR を管理するソフトウェアが、独自で差分検知の実装をしなくて済むのでとっつきやすくなり、結果としてソフトウェアの選択肢が多くなります。 10月にあった KubeVirt Summit でこれについてのめっちゃ詳しく説明されているので、よかったらご覧ください。 www.youtube.com Security and Performance Optimized defaults for multiple live migrations and databases VM vulnerability reporting in RHACS Compliance Operator for Hardened OpenShift Virtualization ACS（Red Hat Advanced Cluster Security for Kubernetes） はコンテナセキュリティを監視するソフトウェアですが、コンテナだけでなく今後は VM の中までカバーするような書き方があります。 ぶっちゃけ実際どう実装するのかは不明ですが、やはり最近はシステムセキュリティは最重要の課題ですし、Virt ユーザも日に日に増えているので、責任持って対応するという姿勢であると思われます。 また、以下のような OpenShift Virtualization をよりセキュアにするためのプラクティスが集まっているドキュメントが公開されていますので、是非参考にして下さい。 Red Hat OpenShift Virtualization Hardening Guide - Red Hat Customer Portal まとめ 今回は6つのカテゴリで今後の Virt のロードマップについて紹介しました。 この他にも多くの取り組みが予定されていて、まだまだ Virt は留まるところを知りません。 Virt はどんどん機能が豊富になっていくのは間違いないですが、Virt で満足して終わって欲しくないというのが私の思いです。 OpenShift を飯の種にする者としてはやはり、お客様には現在の運用やアプリ開発を改善すべくコンテナや AI を使ったモダナイゼーションに取り組んでいただきたいですし、そこには OpenShift を使っていただきたいです。 OpenShift は、今は VMware からの置き換えに過ぎないとお考えかもしれませんが、間違いなくモダナイゼーションを実現できるプラットフォームとしての価値があります。 ですので、お客様が Virt を踏み台にしてさらに次のより良い世界へジャンプアップしてもらえると、私としてはこれ以上望むものはありません。 ということで、今年はここまで。お付き合いいただきましてありがとうございました。メリークリスマス & 良いお年を。

2026年こそPython2.7とお別れしたい みなさんメリークリスマス。さいとうです。今日はAnsibleコミュニティ方面からきました。 Ansible Advent Calendar 2025 の最終日の記事として、そろそろ真面目に考えはじめたPython2.7との別れについて、つらつらと書いてみたいと思います。今年もいい感じの図はありません文章だけですごめんなさい。 はじめに - Ansible CoreとAnsibleの関係 2025年12月25日現在、Ansible Coreの最新リリースは2.20.1、そして標準的なCollection(僕は選ばれし者たちと呼んでます)と合わせてAnsibleコミュニティーがパッケージングしてリリースしているAnsibleは13.1.0です。 Ansible Coreはいわゆるansibleコマンドやansible-playbookコマンドなどのコマンドラインインターフェイスと、templateモジュールやcopyモジュールといったbuiltin collectionを含んだエンジン部分です。 一般的にAnsibleと世の中で認識されているのは後者ですが、「バージョンは?」という質問に対する回答で帰ってくるのは前者のバージョンです。 この記事では、Ansibleとは後者のコミュニティーがパッケージングしてリリースしているバージョンを指すものとします。 Releases and maintenance Ansible community changelogs Ansible CoreのPython2サポートの現在地 AnsibleのPlaybookを実行するときに意識すべきPythonインタプリタは2種類あります。 Control Node Python : Playbookを実行する側（コントローラ）で必要なPythonインタプリタ。 Target Python : 操作される側（ターゲット）でモジュールを実行するために必要なPythonインタプリタ。 このControl Node PythonとTarget Pythonのサポートマトリクスは以下のリンクで確認できます。 ansible-core support matrix ご覧の通り、Ansibleコミュニティではコントローラ側のPythonインタプリタ(Control Node Python)はAnsible Core 2.11を最後にPython2.7は公式サポートされなくなりました。ターゲットノード側でのPython2サポートも実はAnsible Core 2.16で終了しています。 Control Node PythonとPython2.7 前述の通り、AnsibleはすでにPython2と決別しています。ですから、Python2.7とpipの組み合わてAnsible Coreをインストールしようとした場合、インストールの対象となるのは2.11.12までです。(ここでは利用可能なバージョンをリストアップさせるために、バージョンを無指定で実行しています) $ python --version Python 2.7.5 $ pip --version pip 20.3.4 from /usr/lib/python2.7/site-packages/pip (python 2.7) $ pip install ansible-core== DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality. Defaulting to user installation because normal site-packages is not writeable ERROR: Could not find a version that satisfies the requirement ansible-core== (from versions: 0.0.1a1, 2.11.0b1, 2.11.0b2, 2.11.0b3, 2.11.0b4, 2.11.0rc1, 2.11.0rc2, 2.11.0, 2.11.1rc1, 2.11.1, 2.11.2rc1, 2.11.2, 2.11.3rc1, 2.11.3, 2.11.4rc1, 2.11.4, 2.11.5rc1, 2.11.5, 2.11.6rc1, 2.11.6, 2.11.7rc1, 2.11.7, 2.11.8rc1, 2.11.8, 2.11.9rc1, 2.11.9, 2.11.10rc1, 2.11.10, 2.11.11rc1, 2.11.11, 2.11.12rc1, 2.11.12) ERROR: No matching distribution found for ansible-core== とはいえ、コントローラでサポートされなくなるというのは、利用者にとってそれほど大きな影響はないのではないかと思います。コントローラがPython2.7を標準Pythonインタプリタとしているような古いOSで動作していても、OSのディストリビュータからPython3インタプリタが提供されていることが多いので、Python2とPython3を共存させる形で運用できるかもしれません。 いざとなったらAnsible Coreの実行環境をコンテナ化してコントローラのOSから分離してしまって、コンテナ中でPythonインタプリタを含めてメンテナンスしていくという手もあります。Ansible Navigator、Ansible Runner、Execution Environment Containerの組み合わせであれば、このようなアイデアを比較的簡単(だと思う)に実現できます。 ちなみに、Ansible Coreの最新版を利用したいのであれば、Control Node PythonとしてPython3.12以降が必要です。 $ pip3.11 index versions ansible-core ansible-core (2.19.5) Available versions: 2.19.5, 2.19.4, ... , 2.11.0 $ pip3.12 index versions ansible-core ansible-core (2.20.1) Available versions: 2.20.1, 2.20.0, ... , 2.11.0 Target PythonとPython2.7 Ansible Core 2.16までは、Target Python(つまり自動化の対象となるターゲットノードのPythonインタプリタ)として公式にPython2.7をサポートしています。Ansibleのテクニカルサポートを提供している企業が、サポート対象のAnsible Coreの実行環境でいまだに2.16を標準的に提供している理由は恐らくこれです。 ターゲットノードでは、Ansible Coreのコマンド群やプラグインを実行するわけではありません。モジュールから生成されたプログラムさえSSH経由で実行できれば良いわけです。 そのためControl Node Pythonのように、Ansible Coreやそれが利用しているPythonライブラリ群の利用要件にしたがってPythonバージョンを上げていく必要性も「あまり」ありません。 そこで、可能な限り幅広いターゲットノードをカバーするというコンセプトで、Target PythonはControl Node Pythonよりも緩いバージョン縛りになっています。 Target Pythonで注意すべきこと Ansible Coreは、Playbookをタスク単位で実行します。一般的に、タスクにはモジュールとそのパラメータが指定され、Windows以外のターゲットを対象にしているタスクでは、指定したモジュールとパラメータをもとに、実行可能なPythonプログラムが生成されてターゲットノードにSSH経由で転送されます。 以下は、ansible.posix collectionのインテグレーションテストからの抜粋です。この場合はfirewalldモジュールをベースにPythonプログラムが生成されます。 - name: Firewalld port range test permanent enabled ansible.posix.firewalld: port: 5500-6850/tcp permanent: true state: enabled register: result タスクをもとに生成されたPythonプログラムは、Ansible Coreが提供するいくつかのPythonライブラリが含まれた形でZIP圧縮されて作られます。これらのライブラリは、モジュールから利用される基本的な機能を提供していて、実行時に解凍されてターゲットノード上の作業ディレクトリに展開されます。最終的に、モジュールはこれらのライブラリの助けを借りながらターゲットノード上で仕事をすることになるわけです。 このタスク(モジュール)実行の仕組みが今回のポイントで、モジュールから生成されたPythonプログラムはターゲットノード上のPythonインタプリタ(Target Python)を利用して実行されます。 Ansible 2.8(当時はAnsible CoreではなくAnsibleと呼ばれていました)からは、このターゲットノード上のPythonインタプリタをOSのディストリビューションとバージョンから自動判別するInterpreter Discoveryという機能が実装されています。最優先で選択されるのはPython3なので、Python2とPython3を含めた複数のバージョンのPythonインタプリタが動作しているシステムでは /usr/bin/Python3 が優先して選択されます。 このInterpreter Discoveryの恩恵で、利用者はターゲットノード上のPythonインタプリタをあまり意識しなくても済むようになったわけですが、困ったもので世の中には、Red Hat Enterprise Linux 7 のようにOS標準のPythonインタプリタが2.7であり、Python3がインストールされていない環境も存在しています。 現実には、このような環境んもカバーしなければなりませんから、簡単にはPython2を切り捨てることはできません。このために、モジュール側でPython2とPython3の両方をカバーするようなコードを書く必要性が生じます。 モジュールでPython2とPython3の差異を吸収する PythonコードをPython2でもPython3でも動作するようにする...というのは思いのほか面倒です。そこで世の中には six というPythonライブラリが提供されていて、コレを使えばPython2とPython3両方に対応したコードを比較的楽に書くことができます。 ゼロから書くのは大変なのでsixを使おう...あぁまじでよかったPythonコミュニティありがとう。なんて思うかもしれませんが、Ansibleが行う自動化の性質上そう簡単にはいかないのです。 $ pip install six Collecting six Downloading six-1.17.0-py2.py3-none-any.whl.metadata (1.7 kB) Downloading six-1.17.0-py2.py3-none-any.whl (11 kB) Installing collected packages: six Successfully installed six-1.17.0 $ Name: six Version: 1.17.0 Summary: Python 2 and 3 compatibility utilities Home-page: https://github.com/benjaminp/six Author: Benjamin Peterson Author-email: benjamin@python.org License: MIT Location: /home/azureuser/devel/venv/devel/lib64/python3.12/site-packages Requires: Required-by: なぜなら、 「モジュールはターゲットノードのPythonインタプリタで実行される」 からです。つまり、sixを使ったモジュールを実行することでターゲットノードに自動化を適用したいのであれば、モジュールが必要とするsixを含めたPythonライブラリ群もすべてターゲットノード上にあらかじめインストールされていなければならないからです。 検証用の数台ならいいけれど、数千台あるターゲットノードにsixをインストールします? 無理ですよねぇもう絶望しかないですよ...絶望には慣れてるけど... sixあります そんなかわいそうすぎる我々のために、Ansible Coreはヘルパーモジュールとして 自前のsix を提供してくれています。 $ python Python 3.13.9 (main, Oct 14 2025, 00:00:00) [GCC 14.3.1 20250617 (Red Hat 14.3.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ansible.module_utils import six >>> six.PY2 False >>> six.PY3 True >>> 以下はstable-11の community.general.decompress モジュールのsixを利用している箇所の抜粋です。Pythonインタプリタのバージョンによって呼び出すメソッドを変えていますが、その判定に自前のsixが使われています。 ... from ansible.module_utils import six ... def bz2_decompress(src): if six.PY3: return bz2.open(src, "rb") else: return bz2.BZ2File(src, "rb") ... ところで、このsixは前述したZIP圧縮されたPythonプログラムに含まれる形で配布されます。 $ tree $HOME/.ansible/ /home/foo/.ansible/ └── tmp └── ansible-tmp-1766630173.576013-11733-80347744334354 └── AnsiballZ_setup.py このAnsiballZ モジュール名.pyは、ansible.builtin.setupを実行したときに生成されるPythonプログラムで、自己解凍式になっています。そして、このAnsiballZ モジュール名.pyは、自前のsixを含む形で生成されるので、ターゲットノード上で実行時に解凍されれば、sixも同時に配置される仕組みになっています。 $ cd $HOME/.ansible/tmp/ansible-tmp-1766630173.576013-11733-80347744334354 $ python AnsiballZ_setup.py explode Module expanded into: /home/foo/.ansible/tmp/ansible-tmp-1766630173.576013-11733-80347744334354/debug_dir $ find . -type d -name "six" -exec find {} \; ./debug_dir/ansible/module_utils/six ./debug_dir/ansible/module_utils/six/__init__.py ここまで説明したように、 Python2をサポートし続けるということは、Pythonインタプリタのバージョンによる振る舞いの違いを、モジュールやプラグインでケアし続けるということを意味します 。そして、それはAnsible Coreが独自実装・提供しているsixに依存することで成立しているのです。 Target PythonもPython2とお別れしたいの Ansible Coreは自前のsixを提供することで、モジュールがPython2とPython3の両方をサポートしやすい仕組みを提供しています。しかし、Python2はすでにサポートされなくなっていますから、このsixもいつまで提供されるかわかりません。そこで、モジュールを提供するCollection側でもPython2を見切る動きが進んでいます。 たとえば、 先ほど例にあげた community.general.decompress は、stable-12ではすでにPython2を見切っています。 ... def bz2_decompress(src): return bz2.open(src, "rb") ... 上記のコードでは、Python2,3の判定箇所が削除され、残されているのはPython3向けのコードのみとなっていますから、Python2では動作しません。 $ python Python 2.7.5 (default, Aug 13 2020, 02:51:10) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bz2 >>> src = "/tmp/testfile.bz2" >>> bz2.open(src, "rb") Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'open' >>> bz2.BZ2File(src, "rb") <bz2.BZ2File object at 0x7f7712659168> つまり、 最新のcommunity.general collectionでは、Python2を利用した場合の動作は保証されない状況になっています(モジュールによっては動くかもしれないし、動かないかもしれない)。 Ansibe Coreがこの先も継続してsixを提供し続ける可能性はそれほど多くないでしょう。将来的にこのsixが廃止される可能性を考えると、遠からずCollecitonのメンテナたちはPython2を見切ってPython3だけを意識したコードにシフトすることになります。 2026年のAnsibleとわたし ターゲットノードの古いOSは、現在も延長サポートによって延命できているかもしれませんが、それにも限界があります。周囲のエコシステムの状況を考えると、2026年はAnsibleに関わる我々にとって 「Pythonの世代交代を真剣に見据える年」 になりそうです。 ほとんどのOSSプロダクトは、それ単体だけで構成されているわけではなく、さまざまなライブラリ群を利用しています。それらの動作要件で変えたくなくても変わらざるをえない場合もあるのです。 つらつらと書きましたが、個人的に、2026年は「この先のターゲットノードのPythonインタプリタをどう扱うべきか」を真剣に考える良いチャンスではないかと思っています。 それではみなさん素敵なクリスマスを!

ハッピークリスマス🎅🎉☃️ レッドハットで、OpenShift Solution Architectをしている 北山 です。 そしてクラウドネイティブな皆さん!!「安定したKubernetesクラスタ」をサンタさん🎅にお願いする時期がやってきましたね!! 私からは、 OpenShift Advent Calendar 最終日のクリスマスプレゼントとして、2026年のOpenShift運用を劇的に変える最新のロードマップアップデート「 What's Next: OpenShift Roadmap Update (December 2025) 」で紹介された内容から、注目機能をピックアップしてお届けしますっ☃️ ちなみにみなさんは、OpenShiftの最新バージョンをご存知でしょーか？ 早いもので、バージョン番号もついに 4.20 という節目を迎えました🎉🎂✨️ これまでのOpenShiftは、コンテナもVMも動く統合アプリケーションプラットフォームを目指してきましたが、2025年のロードマップを見ると、その方向性がさらにエンタープライズ需要に応える機能開発がなされていることを感じますね。 さて、今回動画のなかで紹介された大きなテーマは、以下の5点です。 1. OpenShift Virtualization: 仮想マシンの存在を忘れる魔法 1-1. Load Aware Descheduler 1-2. Storage Class Live Migration 2. Core Platform: 柔軟にクラスタを管理する魔法 2-1. RHEL CoreOSの進化 2-2. EUS Jumps Support 3. Networking: 意識せずとも繋がる魔法 3-1. Ethernet VPN(EVPN) 3-2. User Defined Networks(UDN) 4. Developer Experience: 開発に集中したいを叶える魔法 4-1. Default Dynamic Plug-ins 4-2. Red Hat Developer Lightspeed for RHDH 5. Security: すべての攻撃を守り抜く魔法 5-1. Zero Trust Workload Identity Manager - SPIFFE/SPIRE 5-2. Confidential Containers まとめ それでは早速、クリスマスの魔法をお届けしましょう。 1. OpenShift Virtualization: 仮想マシンの存在を忘れる魔法 BroadcomによるVMware社買収以降、レッドハット社にもOpenShift Virtualizationへの問い合わせが増えています。しかし、現場からは「VMwareで当たり前にできていたあの機能は使えるの？」という厳しいツッコミも頂いていました。 2025年のロードマップでは、そのラストワンマイルを埋めに行く機能紹介が盛りだくさんであり、その中から以下の2つを紹介します。 1-1. Load Aware Descheduler 1-2. Storage Class Live Migration 1-1. Load Aware Descheduler Load Aware Descheduler(負荷検知型リバランシング)とは、従来のPod数やRequest値に基づくスケジューリングではなく、実際のノード負荷(CPUプレッシャーやPSI)を監視し、高負荷時に自動的にVMをライブマイグレーションしてクラスタ全体のバランスを最適化する機能です。 この機能は、KubernetesのDeschedulerとの統合を行って実現されます。 具体的な仕組みとして、LinuxカーネルのPSI(Pressure Stall Information)メトリクスを活用します。 単なるCPU使用率(%)ではなく、「リソース待ちでどれだけ処理が詰まっているか」という実効的な負荷を見てバランシングを判断します。例えば、CPU使用率が低くても、I/O待ちやメモリ競合でプロセスが停滞している状態を検知するような仕組みですね。 そして、Deschedulerがこの情報を元に、VMをライブマイグレーションで空きのあるノードへ逃します。 気になる実際の効果は、以下のブログでも実証されているのでご参照をっ。 分かりづらい話をしましたが、サンタさんに、世界中の全ての家の位置を事前に網羅した地図（EVPN/BGP）を渡し、重いソリを引くトナカイの疲労度（PSI）を検知して自動で休憩やルート変更をさせる（Descheduler）仕組みです。 とても難しい話ですね。はい。次に行きましょう。 Release Target: OpenShift 4.20 1-2. Storage Class Live Migration Storage Class Live Migrationは、VMwareでもおなじみの「Storage vMotion」に相当する機能です。 この機能により、稼働中のVMを止めることなく仮想ディスク(PVC)を別のStorageClassやボリュームに移動できます。これによって、古いストレージの撤去や、HDDからNVMeへの階層移動が、無停止で可能です。 これでサンタさんも海外から荷物を運ばなくて移動できるわけです。 一つ注意としては、内部的にCSI(Container Storage Interface) Driverの機能をフル活用するため、ストレージバックエンド側の対応(スナップショットやクローン機能)が重要になってきます。 実務での利用を検討する場合は、OpenShift Virtualizationのストレージに関する考慮事項 1 を確認の上、適切なストレージの選択を行いましょう。 また、インストールに関しては、是非こちらの記事もお楽しみください!! Virt 屋のひとりごと : VM とストレージの Live migration - 赤帽エンジニアブログ 2. Core Platform: 柔軟にクラスタを管理する魔法 OpenShiftを普段から運用している方にとっては、しれっとインパクトの大きいことを言っていたのがこのセクション。 どのプラットフォーム上にOpenShiftを提供しているのかによって、インストールの細かな機能差異もアップデートされていましたねー。 Install Experiences このセクションで紹介するのは、これまで多くの管理者を悩ませてきたバージョンアップ作業を簡素化する機能についてです。 2-1. RHEL CoreOSの進化 2-2. EUS Jumps Support 2-1. RHEL CoreOSの進化 OpenShiftの専用OSであるRHCOSは、次世代のハードウェア対応やアップグレードリスクの極小化に向けて、次の一歩を踏み出しました。いくつかの機能が混在して話されていたので、3つをピックアップします。 Dual OS Streams これまでOpenShiftクラスタ内のノードOSはバージョンを統一するのが基本でしたが、RHCOS 9とRHCOS 10を同じクラスター内で実行することが可能になります。これによって、最新のRHEL 10で認定されたハードウェアを既存クラスタに順次導入したり、OSのメジャーバージョンアップに伴うリスクをノード単位で切り離して管理できるようになります。 コンフィデンシャル・コンピューティング対応 実行中のデータを保護するためのConfidential Nodesが計画されており、信頼実行環境(TEE:Trusted Execution Environment)上でのセキュアなOS実行をサポートします。これは後述のセキュリティのセクションで詳しく触れます。 Image Modeによるカスタマイズの効率化 RHCOSにImage Modeが導入されます。これによって、インストール時にCoreOSのカスタマイズ内容を直接インジェクトすることができ、デプロイ後の設定作業を大幅に削減できます。 Image Modeのキャッチアップについては、下記のWebセミナーがおすすめです!! Red Hat Enterprise Linux 10 /Image mode ご紹介ウェビナー 〜OS 構築・デプロイ・管理をコンテナネイティブなワークフローで実現〜 2-2. EUS Jumps Support クラスタ運用において、頻繁なアップデートは運用者の負担となります。 安定版(EUS: Extended Update Support) 間の移行を極限までスムーズにする戦略が示されました。それが EUS Jumps Support です。 これまでのアップグレードは1バージョンずつ段階を踏む必要がありましたが、新しいEUS戦略では、OCPバージョンNからN+3へのアップグレードを、ワーカーノードの再起動わずか1回で完了させることを目指しています。 これにより、大幅なメンテナンスウィンドウの短縮と運用コストの削減が期待できます。 また、頻繁なアップデートを推奨するため、APIサーバーのエミュレーション機能が導入される予定です。これによって、アップデートを最終確定する前にマイナーバージョンのロールバックが可能になったり、途中のバージョンをスキップしたアップデートがより安全に行えるようになります。 なお、サンタさんにはEUS Jumps(年飛ばし)することなく、毎年来てもらいたいものですね。 3. Networking: 意識せずとも繋がる魔法 ネットワークでは、OpenShift Virtualizationのマイグレーションとして活躍するEVPNやBGPの活用についての話がありました。ハイブリッドクラウドやマルチデータセンター間でのネットワーク接続は、まさにサンタさんの最適ルート選びと同じくらい複雑な問題ですね。 ここでは動画を観るうえで前提となっているUDNについても、少しおさらいしておきましょう。 3-1. Ethernet VPN(EVPN) 3-2. User Defined Networks(UDN) 3-1. Ethernet VPN(EVPN) これまでは、新しいデバイスを見つけるためにネットワーク全体に「誰かいますかー？」とパケットを投げまくる(フラッディング)必要がありました。 EVPNはBGPを使い、あらかじめ「どこに誰がいるか」という名簿(MAC/IP情報)を配布します。これによって、ARPなどの無駄な通信を劇的に減らし、ネットワークの帯域を有効活用できます。 しかし、これまでのEVPNの実現には、高価な物理スイッチ側で複雑な設定が必要でした。しかし、OpenShiftのOVN-Kubernetesを活用 2 することで、全てサーバー内部の仮想スイッチ(OVS)で完結できるようになりました。 - 物理スイッチの設定不要： 物理側はシンプルなIP転送さえできればOK。複雑な設定から解放されます。 - IPの重複も可能： テナントごとに全く同じIPアドレスを使っていても、ネットワークを完全に分離して管理できます。 EVPNがGAされることで、OpenShift Virtualizationで動く仮想マシンを別のクラスターへマイグレーションさせる際、 IPアドレスを変えずに 移動できます。また、vSphereなどの既存基盤とOpenShiftを、あたかも一つのネットワークのように透過的に接続できます。 さらに、 User Defined Networks(UDN) と組み合わせれば、OVN-KubernetesがBGPスピーカーとして機能し、UDN内のIPプレフィックスをデータセンターのToR（Top of Rack）スイッチ等の物理ファブリックに直接広報します。これで開発者が自分で専用のL2/L3セグメントを作成できるようになることも考えられます。 まさに、Private Cloud実現の夢が広がる機能ですね。 Release Target: Middle Term 3-2. User Defined Networks(UDN) Kubernetesの標準的なフラットなPodネットワークは、シンプルである反面、複雑なエンタープライズ要件や厳格なマルチテナンシーには不十分でした。OpenShift 4.18でGAとなったUDNは、クラスタ管理者がNamespace単位、あるいはPod単位で完全に分離されたネットワークトポロジーを定義できる機能です。 こちらの登壇資料がわかりやすいので、もうすこし詳しく知りたい場合はおすすめです。 UDNはOVN-Kubernetes CNIプラグインを拡張したもので、OpenShift 4.20でBGPとの統合やL2/L3セグメントの柔軟な作成が出来るようになりました。 Primary UDN: 従来のクラスタデフォルトネットワークを置き換えます。特定のNamespace内のPodは、作成された瞬間からカスタム定義されたネットワーク（例: 192.168.10.0/24）に接続され、デフォルトのPodネットワーク（10.128.0.0/14等）から隔離されます。 L2トポロジー: UDNはL2ネットワークを作成できます。これにより、同一UDN内のPodやVMは、あたかも同一のレイヤー2スイッチに接続されているかのように振る舞い、ブロードキャストやマルチキャスト通信が可能になります。 L3トポロジー: VRF(Virtual Routing and Forwarding)を用いたL3分離を提供し、テナント間のルーティング制御を柔軟に行います。 Release Target: OpenShift 4.18 4. Developer Experience: 開発に集中したいを叶える魔法 まだまだ続くよどこまでも。ということで次はOpenShift上での開発のお話です。 開発者の皆さんにとって、環境の準備やトラブルシューティングは、日々の開発工数を消費する手間のかかる作業ではないでしょうか。 開発者がKubernetesを意識しなくて済む領域へと踏み出すために、OpenShiftは Red Hat Developer Hub(RHDH) 3 を中心に開発者ポータルの機能を強化しています。RHDHはオープンソースのBackstage 4 をベースとした開発者ポータルであり、サンプルのGolden Pathや、他のRed Hat製品との連携を強化する製品です。 ここでは動画の中で触れられていた、Red Hat Developer Hubの機能から以下の2つをピックアップして紹介します。 4-1. Default Dynamic Plug-ins 4-2. Red Hat Developer Lightspeed for RHDH 4-1. Default Dynamic Plug-ins Backstageでは、Plug-ins 5 という機構を使って、開発ポータルを拡張します。Plug-insを使うことで、CI/CDの連携やOpenAPIカタログ連携、Gitへの接続ができ、組織独自の開発ポータルが簡単に作成できます。 しかし、RHDHのベースとなっているオープンソースのBackstageでは、これまで新しいPlug-insを追加するたびに、システムのソースコードを書き換え、コンテナイメージを再ビルドする必要がありました。それを解決する仕組みが、Dynamic Plug-insです。 Dynamic Plug-insは、ConfigMapの変更だけでコンパイルなしにPlug-insの追加や削除ができます。今後のロードマップでは、このDynamic Plug-insがRHDHの標準実装になります。 また、RHDHのサブスクリプションの一部として、Red Hatは厳選されたコミュニティPlug-insを提供しています。これらのコミュニティプラグインは、Red HatによってDynamic Plug-insに対応しており、テクニカルプレビュー規約に基づいてサポートが提供されます。 これを活用することで、ビジネスの要望に合わせて即座に機能拡張が可能になり、プラットフォームの鮮度を常に最新に保つことができます。 Release Target: OpenShift 4.18 4-2. Red Hat Developer Lightspeed for RHDH たとえRHDHを使い、開発ポータルが社内で利用できたとしても「このツールの使い方は？」「テストが失敗したけど原因がわからない…」と立ち止まる時間は意外と多いものです。その時間をもっと効率的な生産活動に変えるのが、生成AIを活用した仮想アシスタント Red Hat Developer Lightspeed for RHDH です。 簡単に言うと、RHDHの画面上に専用のAIコンシェルジュを呼べる製品です。よくある問い合わせ窓口ではあるのですが、開発時の手助けをしてくれます。 自然言語で相談：「RHDHで新しいPlug-insを設定するにはどうすればいい？」と問いかけるだけで、ドキュメントに基づいた正確な回答をくれます。 トラブルを即解決：例えばCI/CDパイプラインでテストが失敗したとき、そのエラー内容を渡すと、文脈を理解して修正案を提案してくれます。 テスト作成もお任せ：アプリケーションのユニットテストの計画策定や、実装のヒントもAIが教えてくれます。 これまでドキュメントを読み漁っていた時間をコーディング時間に変えることで、組織全体のイノベーションを加速させます。 Release Target: OpenShift 4.18 5. Security: すべての攻撃を守り抜く魔法 サプライチェーン攻撃が年間742%増加 6 している現代、セキュリティは「後付け」では間に合わなくなりました。 サンタさんからのプレゼントを横取りされたり、中身を変えられたなんて事件も増加しています。しらんけど。 OpenShiftのセキュリティは、プラットフォームのあらゆるレイヤーを要塞化し、 Zero Trust, Secure by Design を具現化することにあります。今回はその中でも、特にアプリケーションやワークロードの信頼のあり方を根本から変える2つの技術のアップデートを紹介します。 5-1. Zero Trust Workload Identity Manager - SPIFFE/SPIRE 5-2. Confidential Containers 5-1. Zero Trust Workload Identity Manager - SPIFFE/SPIRE Zero Trust Workload Identity Manager(ZTWIM)は、オープンソースのSPIFFE/SPIREプロジェクトをベースとした製品です。 従来の静的なシークレット(パスワードやAPIキー)に頼らず、全てのワークロードに対して実行時に暗号化し、暗号学的に検証可能な短寿命のアイデンティティを自動で付与してくる機能です。 SPIFFE (Secure Production Identity Framework for Everyone) SPIFFEはセキュアなワークロード識別のためのプロトコルと仕様を定義します。 SPIFFE ID: ワークロードに割り当てられる一意のURI形式の識別子。 SVID (SPIFFE Verifiable Identity Document): SPIFFE IDを保持する暗号学的に検証可能なドキュメント。通常はX.509証明書またはJWTトークンの形式で実装されます。 Workload API: ワークロードが自身のSVIDを取得し、他のワークロードのSVIDを検証するためのAPI仕様。 SPIRE (SPIFFE Runtime Environment) SPIREはSPIFFE標準の「本番環境向けリファレンス実装」であり、実際のIDの発行、管理、ローテーションを行います。SPIREは主に以下の2つのコンポーネントで構成されます。 SPIRE Server: トラストドメイン（信頼境界）内のIDの署名局（認証局）として機能します。またワークロードの登録情報と、IDを発行するための条件（セレクター）を管理します。 SPIRE Agent: 各ノード（ホストマシン、VM）上で実行されます。ノードおよびワークロードの「アテステーション（実証・認証）」を行い、サーバーと連携してSVIDを安全に発行します。そしてWorkload APIをローカルで公開し、ワークロードにSVIDを提供します。 これらの機能によって、たとえネットワーク内に侵入されたとしても、正当なアイデンティティを持たないワークロードは一切の通信ができない、真のゼロトラスト環境が実現します。 今後ZTWIMはService MeshやOpenShift Virtualizationと統合され、コンテナだけでなくVMに対しても一貫したID基盤を提供するようになることが紹介されていました。また将来的には、AIエージェント間のセキュアな通信やエッジ環境、サプライチェーン全体の信頼性を保証する仕組みへと拡張される予定です。 Release Target: OpenShift 4.20 5-2. Confidential Containers これまでのセキュリティ対策は「保存してあるデータ」と「転送中のデータ」の保護が中心でした。しかし、データがメモリ上で処理されている間は、特権ユーザーやホストOSから中身が見えてしまうという課題残っていました。まぁー。この世の中、サンタさん自身がプレゼントを変えちゃうってこともあるわけですよ。 この実行中のデータ保護を実現する技術の総称が、 コンフィデンシャル・コンピューティング であり、それをコンテナで実現する一要素が Confidential Containers です。 Confidential Containersは、ハードウェアベースのセキュリティ機能を利用して、実行中のワークロードを周囲から完全に隔離し、秘密を保護します。 アーキテクチャの概要は以下の通りです。 1. Podごとに専用の「安全な箱(VM)」を作る Confidential Containersは、Kata Containersという技術をベースにしています。通常のコンテナはホストOS上で直接動きますが、Condidential Containersでは Podごとに専用のConfidential VM（機密仮想マシン） を立ち上げ、その中でコンテナを実行します。 これの実装には、Intel TDXやAMD SEV-SNPといった特殊なCPUの機能を利用しながらメモリをハードウェアレベルで暗号化し、その中でコンテナを動かします。この技術によりクラウド事業者やKubernetesの管理者のような特権ユーザーであっても、この「安全な箱」の中身を覗いたり、書き換えたりすることはできません。 2. 正しさを確認する(リモートアテステーション) VMを起動しただけでは、その中身が本当に安全な設定で動いているか確信が持てません。そこで、 リモートアテステーション（構成証明） という確認プロセスが自動で行われます。 VM内の Attestation Agent (AA) が、ハードウェアの状態やOSの構成などのEvidenceを収集し、それを信頼できる場所に置かれた Trustee（トラスティ） と呼ばれる検証サービスへ送信します。 そして、検証が成功(環境が改ざんされていないと証明)された場合にのみ、暗号化されたコンテナイメージを解凍するための秘密情報がVMに送られます。 従来の仕組みでは、コンテナイメージを解凍するのはホストOS(クラウド側)の役割でしたが、Confidential Containerでは 「安全な箱（VM）」 の中でイメージの取得と解凍を行います。これによって、コンテナに含まれる独自のアルゴリズムや機密データが、実行前の段階で外部に漏れるのを防ぎます。 今回の動画では、このConfidential ContainersがARO (Azure Red Hat OpenShift) やベアメタル、さらにはNVIDIA GPU搭載環境においても、Confidential Containersの対応がGAおよびテックプレビューとして進められていることが紹介されました。この技術により、パブリッククラウドや共有インフラの上であっても、誰からも覗き見ることができない「安全な箱」の中で、機密性の高い処理を安心して実行できるようになります。 まとめ いかがだったでしょうか？相変わらず情報盛りだくさんのUpdateで、何がなんだか。。。と感じた方もいらっしゃるかもですが、ご安心を！ 全部詳細まで把握できている人などいませんw オープンソースが進化していくたびに、OpenShiftも成長を続け、新たな発見があります。 なにか1つでもみなさんの興味のある機能が見つかったのであれば、是非コメントを添えてシェアお待ちしていますー。 2026年は、OpenShiftにとっても新たな幕開けにしていくので是非お楽しみをっ！ オープンソースのチカラで世の中を少しでも変えてみたい。と思った方は、年末年始に是非レッドハットのポジションも検討してみてください~。 それでは良いお年を!! Bye for now. OpenShift Virtualization のストレージに関する考慮事項 - https://developers.redhat.com/articles/2025/07/10/storage-considerations-openshift-virtualization ↩ A native way of integrating OVN into the fabric through BGP EVPN - https://www.youtube.com/watch?v=KE-CF8bD1CU ↩ Getting started with the Red Hat Developer Hub - https://www.youtube.com/watch?v=tvVOC0mFR_4 ↩ Spotifyがオープンソース化した、開発ポータル - https://backstage.io/ ↩ Backstage Plugin directory - https://backstage.io/Plug-ins/ ↩ State of the Software Supply Chain - https://www.sonatype.com/state-of-the-software-supply-chain/introduction ↩

Apache Camel Advent Calendar 最終日となる 25日目の記事は、サポート担当古市が担当します。 テーマは、「Camelの商用サポートを有効活用」 Apache Camel ではなく Red Hat Build of Apache Camel をご利用いただく事で、商用サポートをご利用いただけます。 そもそもコミュニティーライブラリーではなく製品をご利用いただくメリットについて、いくつか記事が公開されています。 www.redhat.com www.redhat.com 話が長くなるのでここでは割愛しますが、ご興味がある方は Red Hat セールスチームへお声がけください。 今回は、サポート窓口での経験を通して、これは商用サポートならではと実感したエピソードをいくつかご紹介したいと思います。 新機能リクエスト 全てのリクエストが反映されるわけではありませんが、お客様の提案がきっかけで新機能が実装された際には喜びを感じます。 直近ですと、kaoto のドキュメント生成機能は日本の現場から生まれたリクエストでした。その他にも、camel-kafka コンポーネントのオプション追加など、お客様のプロジェクトを進める上で必要な機能をサポートケース経由で実現する事例が多いです。(既存のソリューションで解決できる場合、そちらをご提案することもあります。) 開発者の方々も、ユーザー様がどういった使い方をしているのか興味深くヒアリングしており、今後の製品開発の参考にされているそうです。 サポート追加リクエスト 製品サポートには含まれていない camel component のサポートリクエストが反映されることもあります。（現在のソリューションで解決できる場合、そちらをご提案することもあります。） 製品に含まれていないからと断念せず、まずはお気軽にサポートへお問い合わせいただければと思います。 トラブルシュート サポートで期待される本命はトラブルシュートかとは思いますが、複数製品をまたぐ問題に関するお問い合わせであった場合(例: Camel on Openshift の問題や、camel の kafka 連携に付随するパフォーマンス問題など)、他製品のサポートチームと連携して対応する事で、弊社の真価を発揮できていると実感することが多いです。 余談ですが、弊社で事象を再現できるプロジェクトをご提供いただけますと、調査がよりスムーズに進むことが多いです。解決を急がれている場合には、ぜひこちらもご検討いただけますと幸いです。 その他、Camel ならではと思うご質問として、使用すべき camel コンポーネントに関するご質問をいただきます。確かに物凄い数の camel コンポーネントが提供されていますので、Camel の使用方法に関するお問い合わせを頂くと、サポート窓口を有効活用されていらっしゃるなぁと嬉しくなります。 ご質問の中には、「仕様かどうか」をご確認されたいケースもございますが、ぜひ１度、こちらの記事をご覧いただけると助かります。 rheb.hatenablog.com これにて Camel Advent Calendar は終了となります。如何でしたでしょうか。 アドベントカレンダーの一覧はこちらです。 qiita.com 少しでも皆さんの興味あるトピックが含まれていればと思います。他にご興味のある内容やご感想などあれば、SNSアカウント(@hfuruichi)までお気軽にお知らせください。 それでは、メリークリスマス。

※本記事は OpenShift Virtualization アドベントカレンダーの 23 日目の記事です。 qiita.com こんにちは、OpenShift のプリセールスを担当している山川です。 OpenShift は、Installer-Provisioned Infrastructure (IPI) / User-Provisioned Infrastructure (UPI) / Assisted Installer / Agent-based Installer の 4 つのインストール方法を用意しています。 OpenShift Virtualization の構築の需要が多いオンプレミスのベアメタル環境だと、どの方法でもインストール可能となっています。 また、既存の 4 つのインストール方法に加え、最近発表された閉域環境向けの registry-less installer が利用可能となっておりますので、本記事ではこのインストール方法を試してみたいと思います。なお、本インストールは 2025年12月時点では Technical Preview となっているため、本番環境へは General Availability となってから適用ください。 従来の OpenShift では、閉域環境で構成する際、OpenShift の構築や更新に必要なソフトウェアを置いておくための Mirror Registry を設置し OpenShift が参照できる必要がありましたが、この方式では Mirror Registry が不要となっている点も特徴的です。 第2章 接続クラスターの非接続クラスターへの変換 | 非接続環境 | OpenShift Container Platform | 4.20 | Red Hat Documentation なお、インストール方法についての細かな違いは下記の記事をご参照ください。 www.redhat.com OpenShift をインストールしたい環境からインターネットへ出れる場合は、GUI ベースでインストール可能な Assisted Installer を利用いただくと、非常に簡易な手順でインストールが可能です。 Assisted Installer による OpenShift Virtualization のインストールを試してみたい方は、下記のブログシリーズをご参照ください。 rheb.hatenablog.com ISO ファイルのダウンロード まずは、Red Hat Hybrid Cloud Console から ISO ファイルをダウンロードします。 OpenShift > Cluster List > Cluster Type > Datacenter 画面より、Create cluster ボタンを押します。 I'm installing on a disconnected/air-gapped/secured environment の上に記載のボタンをオンにすると、ISO ファイルのダウンロード画面に移ることができます。 なお、私が ISO ファイルをダウンロードした時点では、ファイルの大きさが 43.5GB となっておりました。 ダウンロードに時間がかかるため、余裕をもってダウンロードを開始してください。 また、Red Hat Hybrid Cloud Console から インストール時に利用する Pull secret をダウンロードしておきます。 https://console.redhat.com/openshift/install/pull-secret DNS レコードの登録 DNS に関しては、下記の 2 つのレコードを登録しておく必要がございます。 事前に、<cluster_name>、<base_domain>、IP アドレスを決めた上で設定をお願いします。 項目 内容 本記事での設定値 Kubernetes API api.<cluster_name>. <base_domain> api.ocp.lab.local アプリケーションIngressトラフィック *.apps.<cluster_name>. <base_domain> *.apps.ocp.lab.local OpenShift Node の起動 ダウンロードした ISO からブートしNode を起動すると、Rendezvous IP の入力欄が出てきます。 Rendezvous IP で指定した Node が Bootstrap Node としての役割を持つこととなります。 Bootstrap Node にする予定の Node に関しては、This is the rendezvous node を選択します。 今回の環境では、DHCP により自動でアサインされた 172.16.11.157 が rendezvous node の IP アドレスとなりました。 その他の Node に関しては、選択した rendezvous node の IP アドレスを入力します。 続いて、rendezvous node 上に立ち上がったインストール用のコンソール http://172.16.11.157:3001 にアクセスします。 rendezvous node のコンソールには、下記のようにアクセス先が出力されています。 OpenShift インストールのための事前設定 http://172.16.11.157:3001 にアクセスすると、OpenShift の設定画面が表示されますので、画面に従って必要項目を入力していきます。 今回は、Control Plane と Worker Node を兼ねた 3 ノード構成を目指します。 環境に合わせて、OpenShift Virtualization の運用に必要な Operator を選択します。 現在は、下記の 7 つの Operator を選択可能です。 なお、初期インストールの後に Operator Hubから 7 つの Operator がインストール可能となっています。 OpenShift Virtualization Migration Toolkit for Virtualization NMState Node Health Check Node Maintenance Fence Agents Remediation Kube Descheduler 利用する Node を起動し、Rendezvous IP が適切に設定できていたら、自動的に Node が登録されてきます。 役割として Control Plane を指定した Node については、9 vCPU、17.15 GiB RAM 以上としなければ先に進むことはできませんので注意ください。 なお、NIC の Mac アドレスをベースとした Hostname が自動的に設定されています。 この画面の Hostname をクリックすると下記のようなポップアップが表示され、任意の Hostname をつけることが可能です。 全ての Node が Ready となっていたら、Storage と Network の設定画面に移ります。 特に重要な Network の設定項目である API IP と Ingress IP に関しては、DNS に登録したレコードと同様の IP アドレスの登録をお願いします。 続いて、チェックボックスにチェックを入れ、OpenShift と通信するために必要なクレデンシャル (kubeconfig、kubeadmin-password) を 2 つダウンロードします。 kubeconfig は、OpenShift に対してコマンドを実行可能とするために利用します。また、kubeadmin-password は、OpenShift コンソールにログインする際に利用するパスワードが記載されています。 最後に、全ての設定内容を確認し、完了したらインストールを開始します。 OpenShift インストール 設定が全て完了しましたら、自動でインストールが実行されていますのでしばらく待機となります。 インストールが完了に近づくと、下記のような画面が表示されます。 少し待つと、画面に記載されている URL から OpenShift コンソールに接続可能となります。 OpenShift コンソールへのログイン kubeadmin-password のパスワードをコピーし、コンソールにログインします。 ログイン後の画面で全てのステータスがグリーンになったら OpenShift のセットアップが全て完了となります。 まとめ 本手順を用いると、Mirror Registry がなく、インターネットへ接続できない環境内に ISO ファイルを持ち込むことで OpenShift の構成が可能となります。 簡単に試すことができるので、ぜひチャレンジしてみてください！

Apache Camel Advent Calendar 24日目の記事は、サポート担当古市が担当します。 テーマは、「Camel の最前線を追いかける」 今後は能動的に Apache Camel の情報をキャッチしたいという方へ、リファレンス的にリンクをまとめました。 ぜひ、ご活用ください。 ブログ camel.apache.org kaoto.io YOUTUBE www.youtube.com www.youtube.com Camel の話題が中心の回もあったので、Quarekusもチェックしておいた方が良いでしょう。 www.youtube.com www.youtube.com X(Twitter) Tweets by ApacheCamel x.com Tweets by KaotoIO x.com github.com ハッシュタグも抑えておいた方が良いです。 #ApacheCamel github github.com github.com github.com その他 商用製品の次期リリース予定と過去のリリース一覧はこちらでご確認いただけます。 access.redhat.com 明日の advent calendar 25日目では、「Camelの商用サポートを有効活用」 についてご紹介します。 アドベントカレンダーの一覧はこちらです。 qiita.com