コンサルタントの織です。OpenShift Advent Calendar 2025の1日目、外部のBGPルーターから受け取った経路をMetalLBのBGPスピーカーにインポートする話を書きました。これまでMetalLBのBGPモードでは、 type: LoadBalancer なServiceのExternal IPをBGPで /32 の経路として広告するだけで、外部のルータから受け取った経路をインポートすることはできませんでした。しかし、最近登場したfrr-k8sバックエンドを使うことで、外部からの経路をインポートすることができるようになります。詳しくは以下をご覧ください。 zenn.dev OpenShiftを対象に書いていますが、他のKubernetesディストリビューションでも同じことができると思います。 その他、MetalLB + FRR-k8sを使ったBGP周りの機能についてスライドにまとめたので、もしよかったらこちらも見てください。 speakerdeck.com

※本記事は OpenShift Virtualization アドベントカレンダーの 1日目の記事です。 qiita.com 目次 目次 はじめに 【積極採用中！】Red Hat 採用に関するお知らせ この記事のゴール Q. Red Hat OpenShift Virtualizationとは？ 余談: 意外と知られていないRed Hat OpenShiftのユニークな特徴 Q. どれくらいの価格なのか？ Q. Red Hat OpenShiftとは？ Q. Kubernetesとは？ Q. つまり、コンテナのために用意された商用クラスター環境上で、仮想マシンも実行できるのがOpenShift Virtualizationと言えるか？ Q. OpenShift Virtualizationに登場するサーバ仮想化関連の技術スタックは？ KubeVirtとOpenShift Virtualizationの関係 Q. サーバ仮想化はなぜ必要とされるのか？ Q. コンテナはなぜ必要とされるのか？ Q. 結局コンテナとKubernetesはどう繋がるんだっけ？ Q. OpenShift Virtualizationはどのようなユーザーに向いているのか？ あとがき はじめに 皆さんこんにちわ、Red Hat Global Learning ServicesでLearning Solution Architectを担当している坂井 大和( @lab8010 )です。 普段はよく https://x.com/lab8010 というアカウントでRed Hatの製品やサービスを中心にIT関連の情報(たまにプライベートな投稿)を配信しています。 Red Hat Summit Connect 2025にて登壇させて頂いた際の一枚 これからよろしくお願いいたします 本記事が私にとって、赤帽ブログの初投稿記事となります。 これまでは本ブログには読者としてアクセスをしていましたが、まさか自分が赤帽ブログを書く側になるとは夢にも思っていませんでした。 素晴らしい著者による記事が多いブログですので、私もブログの価値をより一層高められるように頑張りたいと思います。 【積極採用中！】Red Hat 採用に関するお知らせ Red Hatでは事業拡大に伴い人材を募集しています。 本記事でご紹介している『OpenShift Virtualization』に関するコンサルタントを募集しています。もし少しでも興味がある方は、ご応募または本記事を執筆している私坂井までお気軽にDMをください。( X / Linkedin ) redhat.wd5.myworkdayjobs.com この記事のゴール この記事を読み終わった頃には、読者様が次のことが出来る状態になって頂きたいと考えています。 Red Hat OpenShift Virtualizatioの特徴を1つ以上理解し、説明できる Red Hat OpenShift Virtualizationと他の仮想化プラットフォームとの違いを理解し説明できる すでに赤帽ブログを始め、多くのブログ記事でOpenShift Virtualizationについては記事化されています。本当にありがたいことです。 私の記事では 特定機能の具体的な紹介や設定、操作などではなく、 『そもそもOpenShift Virtualizationって何？その価値は？特徴は？製品の位置付けは？』 というメジャーな疑問に対し、 私の言葉で解説 していきます。 上記の次第のため、 OpenShift Virtualizationを使用して仮想化を始める方や検討している方が最初に読むべき記事になればいいな とも思います。 それでは、早速本編に入っていきましょう。 本編ではQA形式を用いて、製品への理解度を深めていきます。 Q. Red Hat OpenShift Virtualizationとは？ A. Red Hat OpenShift上で仮想マシンを実行するための機能 です。 オンプレミス環境で使用可能なOpenShiftは4種類のエディションが存在します。 これら全てのエディションで、本機能(OpenShift Virtualization)は使用可能です。 本ブログのバナーに使用している画像には『 OpenShift Virtualization Engine 』という記述がありますが、これは下図内の一番左にある最もリーズナブルなエディションを示します。 画像引用元: Red Hat OpenShift Container Platform 余談: 意外と知られていないRed Hat OpenShiftのユニークな特徴 また、 意外と知られていない のはOpenShift Virtualization上でRHELの仮想マシンを構成する場合、 仮想マシンとしてのRHELに対するサブスクリプションもOpenShiftのサブスクリプションに含まれている *1 ことです。 分かりやすくいえば、 サブスクリプション込みのRHEL仮想マシンをOpenShift Virtualization上で無制限に実行可能 ということです。 もし読者の方で『本番環境はRHELを使用しているけど、テストや開発環境にはRHELのサブスクリプションは用意できないからRHEL互換OSを使わないといけない』というシーンに当たったことがある場合は、OpenShiftが持つ仮想化機能を活用することは1つのソリューションとなり得るわけです。 世の中には様々なサーバ仮想化ソリューションが存在しますが、このユニークな特徴はRed Hatのソリューションで仮想化をする大きな理由になると言えます。 本内容については以下のページ内にその記述があります。 www.redhat.com 項目タイトル: Red Hat Enterprise Linux エンタイトルメント OpenShift Kubernetes Engine、OpenShift Container Platform、OpenShift Platform Plus には、コンピュートノードとインフラストラクチャ・ノード用の Red Hat Enterprise Linux エンタイトルメントが含まれています。これには、アプリケーション向け Pod のエンタイトルメントと、VM 向けのゲスト OS のエンタイトルメントも含まれます。 この表現は、数多くの記事でも使われる極めてよく見かけるメッセージです。 それで終わってしまっては、この記事のユニークさが出ませんので、この記事では順を追って上から下に読んでいくにつれ、機能への理解が深まる流れを大切にしていこうと思います。 www.redhat.com Q. どれくらいの価格なのか？ 上述の通り、OpenShift Virtualizationには多段階的なエディション設定があります。 今回は私の直近のX.com上での投稿をご紹介致します。こちらは4つあるエディションのうち、最もリーズナブルなRed Hat OpenShift Virtualization Engineの1ノード辺りの価格です。 ※以下の内容は、SNS上での投稿時点のものです。 これがOpenShift Virtualization Engineの価格です (1ノード当たり30万円から) ※OpenShiftというRed Hat式Kubernetesの入門エディション ※4つあるオンプレミス向けエディションの中で、仮想マシン実行に振り切ったエディション (次ポストに続く) https://t.co/lNFmXo9UI1 pic.twitter.com/QudFNvPl1N — Yamato@Red Hat/Learning Solution Architect (@lab8010) November 29, 2025 また、上記と併せてお読み頂きたいのが次のガイドです。 このガイドでは各種OpenShiftのエディションの概説と必要なサブスクリプション数の計算のための例などが掲載されています。 www.redhat.com 製品の価格やサブスクリプションの内容は、時期によってはマーケットのニーズを見て改定される場合もあるため、実際の価格は弊社営業担当より取得をした見積もりにてご確認ください。 Q. Red Hat OpenShiftとは？ A. Red Hatが提供するKubernetesディストリビューション です。 Linuxカーネルを使用するオペレーティングシステムにもFedoraやCentOS、RHELのように利用シーンや搭載機能の違いごとにディストリビューションという区分けがあるように、Kubernetesにもディストリビューションがあり、OpenShiftはRed Hatが提供、サポートをしているものです。 www.redhat.com 世の中に存在する他のKubernetesディストリビューションとしては次のようなものが挙げられます。 マネージド Kubernetes サービス – Amazon EKS – AWS Azure Kubernetes Service (AKS) | Microsoft Azure Google Kubernetes Engine（GKE） | Google Cloud 同じKubernetesのはずなのに、なぜこうも似たようなものがあるかと言うと、上述の通りコアであるKubernetesは共通ではあるが、それを取り巻く追加の要素で各提供元がユニークな機能を持って差別化をしているようなイメージです。 身近なものに例えて言えば、日本食としての寿司は、海外ではその国の食文化やニーズに応じて変化して提供されます。 ある意味これは、その国のニーズを取り入れて誕生したディストリビューションと考えられるかもしれません。 こんな風に、Kubernetesに対しRed Hatの思想やサービスを加えて提供しているものがOpenShiftなんだな、と解釈をして頂けると嬉しいです。 Q. Kubernetesとは？ A. Pod *2 などに対して耐障害性や拡張性などの商用基盤で求められる高度な機能を提供するクラスタリングソフトウェア です。  このPodと呼ばれる単位の中に、アプリケーションを持つコンテナを実行することで、商用アプリケーションに対しKubernetesが持つ機能を提供することができるため、コンテナとKubernetesは多くのコンテンツでよく一緒に登場することが多いのです。 kubernetes.io Q. つまり、コンテナのために用意された商用クラスター環境上で、仮想マシン も 実行できるのがOpenShift Virtualizationと言えるか？ A. はい、その通りです。 より正確にいえば、 『Kubernetesの仕組みを使用し、サーバ仮想化環境の運用管理監視』が出来るようにしたもの が、Red Hat OpenShift Virtualizationです。 質問提起文で、 仮想マシン も と記述しているのは1つのOpenShiftクラスター上でコンテナワークロードも仮想マシンも同時に実行可能 *3 だからです。 Q. OpenShift Virtualizationに登場するサーバ仮想化関連の技術スタックは？ A. 次のようになっています。 仮想マシンを作成/実行/管理する仕組みとして、KVM、QEMU *4 Kubernetesを通じて仮想マシンを管理する仕組みとして、KubeVirt 上記のKubernetesの解説の項目では以下の表現を使用しました。 Podと呼ばれる単位の中に、アプリケーションを持つコンテナを実行することで Kubernetes環境では、管理される側はPodと呼ばれる外装を纏っていると考えてみましょう。 これまではアプリケーションを持つコンテナをPodとして活用してきましたが、 KubeVirtやOpenShift Virtualizationでは、仮想マシンをPodの中に入れて管理します。   つまり、ざっくり解説で図解してみると次のようなイメージです。 コンテナはコンテナエンジン/コンテナランタイム(CRI-Oとcrunまたはrunc)により制御されている OpenShift 4.18からは デフォルトのコンテナランタイムはcrun となっています。従来のバージョンではruncが採用されていました。詳細は次のURLをご確認ください。 docs.redhat.com 仮想マシンはQEMU *5 とKVMによって制御されている 異なるワークロードではあるが、Podとして取り扱う事でKubernetesベースの命令を持って管理対象とすることが可能 2つの異なるワークロードをどちらともPodとして取り扱う事で、 Kubernetesの管理対象として実行可能としている。 上記のように、QEMU/KVMを用いて仮想マシンをPodとして管理することを可能としたのがKubeVirtプロジェクトです。 kubevirt.io www.redhat.com KubeVirtとOpenShift Virtualizationの関係 アップストリーム　KubeVirt ダウンストリーム　OpenShift Virtualization KubeVirtプロジェクトをベースとして、それをRed Hat OpenShiftに対して最適化した形でサポートも込みで提供しているものがOpenShift Virtualizationです。 Q. サーバ仮想化はなぜ必要とされるのか？ A. リソースの共有によるリソース効率向上を始めとするいくつかの利点を得るため 市場では、VMware by Broadcomを筆頭にデータセンターインフラにおけるサーバの仮想化は2025年後半でも今もなお根強い人気のあるテクノロジーであることに変わりありません。 コンテナやKubernetesと比べると、サーバ仮想化は枯れた技術だったり、レガシーという表現をされる場合もある中、Red Hatはそうした仮想化技術にどうして投資をするのか？そのように考える方も一定数おられるでしょう。 私は前職において、サーバ仮想化に関する業務を担当していましたが、その経験を持って思うことは サーバ仮想化とコンテナはそれぞれが異なる課題を解決するもの であるということです。 サーバの仮想化が登場した背景は、『 1台のサーバには1つの役割 』という常識から『 1台のサーバに複数の役割(仮想マシンを用いて) 』に変化させたことで、 CPUやメモリリソースの利用効率を高め 、その結果 物理サーバの設置台数削減 、仮想化による レガシーOSの実行環境の確保 、 仮想マシンのホスト間移行(ライブマイグレーション) など次々と仮想化記述を応用することで多角的な利便性を得るにまで至りました。 サーバ仮想化を使用する前と後の比較 物理サーバの価格はそれなりにするため、たった1つの処理だけに使うのは勿体無い さて、ここでこの問の中で触れた様々な課題を見返して欲しいのですが、これらは誰にとっての課題か？というと 『ITインフラの運用や管理に関わる方』の課題 という見方ができます。 時代はAIやコンテナ、Kubernetesなどモダンで次世代なテクノロジーが生まれてきている一方で、いつの時代もそれらを実行する環境としてはインフラストラクチャは欠かせません。 現在においても インフラ機能を司る仮想マシン(例えばActive Directoryドメインコントローラー、DNS、NTPなど) や、 VDIとして利用される仮想マシン など、コンテナ化に向いていないワークロードは散見されます。 そのため、 サーバの仮想化は今もなお必要な技術であることに違いありません。 Q. コンテナはなぜ必要とされるのか？ A. アプリケーションの開発、テスト、本番実装のサイクルをより高速で信頼性を高めてくれるから さて、 サーバ仮想化＝インフラに関わる課題を解決してくれるもの という解説をしましたが、ここでは コンテナ＝アプリケーション開発における課題を解決してくれるもの という流れで進めていきます。 アプリケーション開発を行うデベロッパーは、自身が開発したアプリケーションが動くかどうかをテストしたいと考えることでしょう。 その場合、 テスト環境を誰かが用意する必要 が出てきます。つまり、次のようなコストが発生します。 テスト環境のためのハードウェアやOS、ソフトウェアの調達 テスト環境構築のための知識取得 テスト環境構築にかかる時間 テスト環境として専用に物理マシンを用意するのは、コスト面、設置スペース、保守面など多くの課題が出てきます。サーバ仮想化環境を使うのも良いですが、ゲストOSのインストール、セットアップ、アップデートなどアプリケーションのテストに至る前の準備が多くなりがちです。 アプリケーションを中心としたビジネスでは、いかにアプリケーションのユーザーに対して素早く新機能やバグ修正を提供していくかが非常に重要視されます。 そのため、上記のようなボトルネックは極力避けるべきであり、次のような思考が生まれてくるはずです。 なるべく速くアプリのテスト環境が欲しいし、テストも速やかに終えたい できれば既存の資産上でテストが出来るとなお助かる テスト環境では動いたけど、本番環境では動かないという事態は避けたい これらのアプリケーション開発者が持つであろう課題を解消するにはまさに コンテナは打ってつけの存在 だと言えます。 開発したアプリケーションを、コンテナインスタンス内で実行するまでの一例 仮想マシンと比較した場合、 単一のコンテナはCPU/メモリ/ディスクなどのリソース消費量が小さい ため、特別巨大なハードウェアリソースを積んだマシンでなくとも手軽に起動ができます。そのため、テストをしたいアプリケーションをコンテナに搭載し、すぐ起動をしてテストを開始することができます。 物理または仮想マシン上でテスト環境を構築する場合、少なくとも次のような作業が想定 されます。 OSのインストールイメージの準備 デバイスドライバーの準備 インストール時の設定入力 OSインストールの待ち時間 OSインストール完了後のパッチ適用 要は、多段階的に時間がかかる準備が存在しうるという事です。 これに対してコンテナをテスト環境として利用する場合、コンテナ上で実行されるアプリケーションに対してどのOS相当として実行されるコンテナとするかを指定する必要があります。これを コンテナイメージ と呼びます。 なお本記事の性質上、コンテナについてフォーカスをしすぎると主題から外れてしまうため、コンテナについての概念や基礎を理解したい方は私の個人ブログを参考にしてみてください。 qiita.com この際、コンテナイメージとしてRed Hat Enterprise Linuxを指定すること *6 もできます。 Red Hat OpenShift上で実行されるRHEL UBIを使用したコンテナ環境(正確にはUBIを使用したコンテナを実行するPod)もまた、上記でご説明をした仮想マシンと同様に起動数に制限はなく、必要なだけ起動ができます。 *7 rheb.hatenablog.com rheb.hatenablog.com www.redhat.com Q. 結局コンテナとKubernetesはどう繋がるんだっけ？ コンテナを実行するだけならノートPCなどにコンテナエンジンをインストールして実行するだけでも実行は可能です。 しかし、商用アプリケーションを実行する場合は耐障害性や拡張性を備えたクラスタリング環境が必要です。一般的なPC環境ではこれらの準備は難しいでしょう。 そこで、Kubernetesがその役割となることで、コンテナに対してエンタープライズクラスのクラスター環境を提供可能となるという流れとなり両者が繋がっていきます。 Q. OpenShift Virtualizationはどのようなユーザーに向いているのか？ A. Kubernetesを活用しながら、コンテナと仮想マシンの共存を目指したいユーザー 現在のITインフラ市場においてサーバ仮想化は成熟したテクノロジーとなりました。 その結果、殆どのサーバ仮想化製品は運用管理で必要される主要な機能を一通り備え、どれも似たように見えるという感想もあるかもしれません。 ここで、 Red Hat OpenShift Virtualizationにはどのような差別化要素があるか を列挙します。 仮想マシンおよびコンテナに対して、RHELを無制限に使用できる 多くのハイパーバイザーと違い、仮想マシンをPodとして取り扱い、Kubernetesの仕組みを通じて管理運用できる 多くの他社ハイパーバイザーでは新機能実装のために仮想マシンベースのアプライアンスを構築するが、Red Hat OpenShift環境では仮想マシンではなくコンテナベースで機能追加が可能である 将来的に仮想マシンをコンテナ化する場合に、そのために必要な仕組みや機能、サービスが揃っている オープンソースベースの先進的な仕組みやソリューションを、Red Hatのサポートを受けながら安心して使用できる 上記の要素があることで、 次のような様々な利点をOpenShiftユーザーは得やすくなる と言えるでしょう。 CentOS StreamをはじめとするRHEL互換OSの採用をする場面が減らせる。 つまり、RHELとRHEL互換OSの2種を持つケースが減る つまり、それらを管理にかかるオーバーヘッドが減る つまり、RHELを使用すればRed Hatサポートを活用できるシーンが増える アプリケーションの実行環境にはコンテナ、インフラ機能の実行環境には仮想マシンという2つの仕組みを、OpenShiftという1つのプラットフォーム上で実行することができる。 新機能実装時に使用されるリソースオーバーヘッドは仮想マシンと比べると少量で済むことが多い(アプライアンスレベルでの比較) 仮想マシンを将来的にコンテナ化出来れば、物理リソース *8 の利用量が削減できる つまり、物理ホストのダウンサイジングも狙える可能性がある つまり、データのバックアップ量が減ることで、ジョブの実行速度が上がる つまり、バックアップストレージのサイズもダウンサイジングが狙える つまり、リストア時間も短くなり、ダウンタイム短縮も狙える OpenShiftでは、Kubernetes由来の様々な便利な機能が使用できる ラベルを使用したワークロードの実行箇所の指定 ネットワークポリシーを活用した通信制御 ワークロードの負荷状況に応じた自動的なスケールアウト、スケールイン 他社ではこれらの機能は上位ライセンスや別製品で提供される場合があるが、これらは全てKubernetesが持つ極めて標準的な機能である 競合他社よりも先んじてオープンソース主導のテクノロジーをRed Hatのサービスを活用しながら現場への実装が狙える つまり、企業としていち早くお客様に価値を提供できるチャンスが増える つまり、オープンソース主導のテクノロジーを採用する事で、ベンダーに依存しないテクノロジー、技術を活用できるため、企業のインフラストラクチャーの拡張性と柔軟性を維持できる あとがき いかがでしたでしょうか。 主題は Red Hat OpenShift Virtualizationとは？ とし、 OpenShiftにおける仮想化アーキテクチャの紹介 からはじめ、 後半ではコンテナの有用性 についても紹介しました。 仮想マシンもコンテナも、どちらも戦略的に使ってこそ最大の価値を発揮します。 もし、現在使用している仮想マシンが少しでもコンテナ化出来るのであれば、ITインフラの側面では消費物理リソース軽量化、迅速なバックアップやリストアなど大きな利点があります。 アプリケーションの視点においてもアプリケーションの提供サイクルが早まり、最終的にエンドユーザーに対する価値提供がよりスピーディーになります。 OpenShift Virtualizationを使用して仮想化環境を持つということは、ただのサーバ仮想化インフラの移行ではなく、将来的に既存の仮想マシンをコンテナ化することも見据えた方に向けた最適な選択肢だと言えます。 Red Hatでは、そうしたハイブリッドなワークロードに対応した製品、それらをサポートするプロフェッショナルなメンバーと彼らが提供するサービスという準備があります。 ぜひ、Red Hat OpenShift Virtualizationを活用する新しいITインフラストラクチャの実装を一緒に始めませんか？ *1 : 全4種のOpenShiftエディションのうち、上位3種類のエディションに付与されている。 *2 : PodとはKubernetesにおけるワークロードの実行単位の1つである。 *3 : 4つあるOpenShiftのエディションのうち、OpenShift Virtualizationだけはワークロードとして実行可能なものは仮想マシンに限定されます *4 : KVMとQEMUはどちらもOSSであり、現在では多くの企業やハイパーバイザーでも使用されており、高い実績があります。 *5 : 仮想ハードウェアのエミュレーション *6 : Universal Base Image、通称UBIイメージと呼ぶ *7 : 全4種のOpenShiftエディションのうち、上位3種類のエディションに付与されている。 *8 : CPU/メモリ/ディスクなど

Apache Camel Advent Calendar 1日目の記事は、サポート担当古市が担当します。 テーマは、「Camel Advent Calendar 始まります」 「オープンソースプロジェクトでシステム間連携用 Javaライブラリーは何？」と聞かれたら、ほぼ「Apache Camel」と答えが返ってくると思います。老舗のオープンソースプロジェクトではありますが、現在もなお利用者数は増加傾向にあります。2025年10月は、月間5000万以上の JARダウンロード数を記録したとのことです。これは、Camel 4.x をリリースしてから数年分の総ダウンロード数の約２倍に相当するそうです。 長い間、ユーザーの皆様から広く利用されている反面、古いものから新しいものまで様々な情報が世の中に溢れており、現時点でどの情報が最適か判断することが難しいのではと危惧していました。 Red Hat は、Red Hat Build of Apache Camel という商用製品を提供していますので、サポートサービスを適時ご利用いただくことで問題解決はできますが、クリスマスプレゼントの意味も込めて、今回は Camel Advent Calendar として 25本の記事をご用意しました。 2025年のクリスマスを迎える頃には、Apache Camel を今まで以上に理解し、使ってみようとモチベーションが上がることを願っています。 25本の記事は、以下のように分類されています。 General Camel の歴史と今 Camel 4 を学ぶ環境整備 Camel Component との付き合い方 Camel の最前線を追いかける Camelの商用サポート有効活用 Editor kaoto を使った開発 kaoto のお気に入り機能ベスト３ Examples Camel File コンポーネント Camel Kafka コンポーネント Camel による Exception/Error Handling Basic Tech Camel route から Hello World Testing Camel Debugging Camel Camel SEDA エンドポイント Camel Split/Aggregate Deploy Camel to k8s/OCP Advanced Tech Camel routeTemplate Camel Kamelet Camel で header/variable を使い分ける Camel アンチパターン Camel ベストプラックティス Monitoring hawtio を使ったモニタリング Camel trace AI Camel x AI, Project Wanaku これから Apache Camel をご利用いいただく方も、記事を読み進め実際に体験していただく事でよりスムーズに導入できる構成になっています。 内容については、Camel 4.x ならではの機能であったり、Camel 2.x から変わらないトピックなどが散りばめられていますので、昔 Apache Camel を使われた経験のある方々も、知識のアップデートにご活用ください。 今すぐ Apache Camel について知りたいという方は、Japan Camel User Group(JCUG)の記事をご覧ください。 jcug-oss.github.io 明日の advent calendar 2日目では、「Camel の歴史と今」についてご紹介します。 アドベントカレンダーの一覧はこちらです。 qiita.com

Red Hat コンサルタントの金子です。「アプリケーションモダナイゼーション」に関連する連載の第7回です。 はじめに：高速なデリバリーの「その先」にある運用者の責任 VM時代とReplatform後の決定的な違い 従来のVM（仮想マシン）時代における運用現場は、多くの「負債」を抱えていました 。 システムの内部状態を理解する「可観測性（Observability）」の徹底活用 統合されたモニタリング（OpenShift Monitoring/Prometheus） ログの一元管理（OpenShift Logging/Loki Stack） 分散システム診断の切り札（OpenShift Distributed Tracing） 運用リスクを劇的に低減する DevSecOps の仕組み プラットフォームによるセキュリティの底上げ 継続的な脆弱性管理と防御 イメージスキャン：継続的なリスク監視の実現 デプロイ時の制御：本番環境への安全なゲートウェイ 実行時の防御：ビジネスのレジリエンス強化 まとめ：Replatformは「安定した運用」というビジネス価値を生む Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  はじめに：高速なデリバリーの「その先」にある運用者の責任 前回はReplatformがCI/CD、脆弱性診断、分散トレーシングによって「高速かつ安全な開発サイクル」を実現し、開発者の体験を向上させることを解説しました。しかし、いくら開発者が早くコードをリリースできても、それを安定して動かせなければビジネス価値は生まれません。運用者は、システムの安定稼働、障害の迅速な復旧、そしてセキュリティの維持という重要な責任を負っています。 特にReplatformによりコンテナのベストプラクティスに則った構成、1 プロセス 1 コンテナにすることにより、複数プロセスが同居していたサーバーは分散システム化が進みます。これにより「障害発生時の原因特定が困難になる」という新たな課題が発生します。また、レガシー環境ではOSパッチ管理や個別対策に依存していたセキュリティ対策も、コンテナ環境でどう担保するかが焦点となります。 本記事では、コンテナプラットフォーム（Red Hat OpenShift）がいかにして、従来の 「運用負債」（属人化や非効率な手作業、形骸化した監視）を解消し、統合された仕組みによってシステムの信頼性（Reliability）と回復性（Resiliency） を高めるのかを、具体的なツール（ログ、監視、セキュリティ）を通じて深堀りします。 VM時代とReplatform後の決定的な違い 従来のVM（仮想マシン）時代における運用現場は、多くの「負債」を抱えていました 。 例えば、監視一つとっても、アプリケーション担当チームとインフラ担当チームで使うツールがバラバラでした。このように担当領域やツールが分断（＝サイロ化）されていると、デプロイ作業全体を一気通貫で自動化することが難しくなります。その結果、結局は「サーバー一台ごと」に手作業で監視や運用の設定をしなければならない非効率さが温存されてしまいました。 そして、こうした手作業こそが、「設定漏れ」や「変更忘れ」といったヒューマンエラーの温床となります。さらに、障害対応のノウハウも、ツールと同様にチーム内に閉じこもって共有されなかったため、いざ問題が起きても原因特定や復旧が後手に回りがちでした。 Replatform、すなわちOpenShiftがもたらす変化は劇的です 。従来はアプリケーション開発者が VM 上にアプリケーションをデプロイしており、そのVM のOSのメンテナンスもアプリケーション開発者が担うケースが有りました。OpenShift ではOSのメンテナンスに関してはアプリケーション開発者の責務ではなく、インフラチームの責務となります。これはOSとアプリが分離され、アプリケーション開発者のプラットフォームの運用負荷が軽減されます 。 そして最も重要な点は、デプロイ、スケーリング、監視、ログ収集のすべてが、Kubernetesの標準リソースによって一元化・自動化されることです 。 これにより、運用者の目線は「サーバー単位の個別管理」から、「Pod/Namespace（プロジェクト）単位の可視化・自動化」へとシフトし、IT運用コストの低減が実現します 。 システムの内部状態を理解する「可観測性（Observability）」の徹底活用 高速な開発サイクルにおいては、万が一問題が発生した場合に「誰が、いつ、どこで、何を」追跡するかが鍵となります。Replatform後の分散環境において、この課題を解決するのが統合された可観測性（Observability）の仕組みです。 統合されたモニタリング（OpenShift Monitoring/Prometheus） メトリクスの一元収集 : OpenShiftは、プラットフォームの機能としてPrometheusベースのOpenShift Monitoringを提供し、CPU使用率やメモリ使用量などの各種メトリクスを統合ダッシュボードで一元的に監視できます。 障害対応の迅速化 : 障害発生時も、アラートをもとに迅速に原因を特定しやすくなります。 ログの一元管理（OpenShift Logging/Loki Stack） ログの一元管理 : 従来のサーバーごとに散在していたログを、 OpenShift Logging（Lokiスタックベース） によってシステム全体で一元的に集約し、検索可能にします。 開発と運用の連携 :開発者がコンテナの標準的な作法（ログをstdout/stderrに出力する）に従うだけで、OpenShift/Kubernetesの統一されたログ収集の仕組みに自動的に連携されます。これにより、運用側は最適化された一元的なログ管理方式を自動的に踏襲でき、開発と運用の分断が解消されます。 分散システム診断の切り札（OpenShift Distributed Tracing） 課題 : 分散システムでは、リクエストが複数のサービスをまたがるため、ボトルネックの特定が困難です。 解決策 : OpenShift Distributed Tracing（Grafana Tempo） は、サービスをまたぐ一連のリクエストにユニークなIDを付与し、その経路を可視化します。 具体的な効果 : これにより、「決済処理の遅延が、実は在庫確認サービスの一時的な応答遅延だった」など、データに基づいて迅速に根本原因を特定し、障害復旧時間の短縮（例: 1日→数時間へ短縮）に貢献します。 運用リスクを劇的に低減する DevSecOps の仕組み Replatformによって基盤がコンテナ化されることは、セキュリティ対策が個別対策から「プラットフォームによる一括管理」へとシフトすることを意味し、運用側の負担を大きく軽減します。 プラットフォームによるセキュリティの底上げ セキュアな基盤 : OpenShiftはRHEL CoreOSやRed Hat Universal Base Image (UBI)を土台とし、厳格なセキュリティポリシーをデフォルトで適用することで、安全なコンテナ運用を容易に実現します。 よりセキュアなデフォルト : OpenShiftは、コンテナの実行をデフォルトで非rootユーザーとし、最小権限の原則に基づいて稼働させるため、開発者が特別なセキュリティ設定をしなくても、基盤側が自動的にセキュリティの「守り」を強化します。 継続的な脆弱性管理と防御 従来の開発プロセスでは、セキュリティ診断はリリースの最終段階で行われることが多く、この段階で重大な脆弱性が発見されると、リリースが延期され、開発チームは大きな手戻りを強いられていました。これは、アプリケーションの継続的な進化を阻む技術的負債の一つです。 OpenShiftで実現されるDevSecOpsは、セキュリティ対策を開発プロセスの早い段階（シフトレフト）に組み込むことで、この課題を解決します。OpenShiftは、土台となるOSやコンテナのベースイメージがセキュアに保たれている上で、アプリケーションのサプライチェーン全体に多層的なセキュリティを組み込みます。 イメージスキャン：継続的なリスク監視の実現 イメージスキャン : 開発フェーズでビルドされたコンテナイメージは、Red Hat Quayによって継続的にスキャンされ、既知の脆弱性（CVE）がないかチェックされます。 Quay 脆弱性スキャン 継続的なリスクの可視化: このスキャンは、一度きりのチェックではなく、イメージが レジストリに保存されている間も継続的 に実行されます。これにより、デプロイ後に新しい脆弱性が発見された場合でも、 運用側が迅速にリスクを把握 し、対処することが可能となります。レガシー環境で発生しがちな「サポート切れのソフトウェアを使い続けることによる既知の脆弱性の放置」というセキュリティ上の負債 を、プラットフォーム側が継続的に監視・通知することで防ぎます。 デプロイ時の制御：本番環境への安全なゲートウェイ デプロイ時の制御 : Red Hat Advanced Cluster Security for Kubernetes (ACS) を活用することで、「脆弱性レベル"Critical"のイメージはデプロイさせない」といったポリシーを適用し、安全でないアプリケーションが本番環境に到達するのを防ぎます。 自動化されたリスク阻止 : ACSは、CI/CDパイプラインと連携してデプロイの最終的なゲートウェイとしての役割を果たします。これにより、開発段階で万が一見落とされた安全でないアプリケーションが、誤って本番環境に到達するのを未然に防ぎます。これは、Kubernetesクラスター全体のセキュリティを監視・制御する中核的な役割を担い、デプロイにおける手動チェックや属人化のリスク（運用負債）を排除します 実行時の防御：ビジネスのレジリエンス強化 実行時の防御 : ACSは、実行中のコンテナの異常な振る舞いを検知し、実行時（Runtime）の脅威にも迅速に対応します。 ゼロデイ脅威への対応: ACSは、設定されたセキュリティポリシーと異なる異常な振る舞いを検知した際には、即座にアラートを発し、実行時（Runtime）の脅威にも迅速に対応することが可能です。これは、静的なスキャンやポリシーチェックでは防げない、ゼロデイ攻撃や予期せぬ内部侵入に対する最後の砦となります。このような多層防御の仕組みにより、障害やセキュリティ事故に強い、可用性の高いシステム、すなわちビジネスのレジリエンスが強化されます。 まとめ：Replatformは「安定した運用」というビジネス価値を生む Replatformは、単なるインフラのお引っ越しではなく、 CI/CDによる高速化（開発） と、 統合された可観測性・多層セキュリティ（運用） という両輪を揃えることで、ビジネスの変化に素早く、そして安全に対応できる「開発・運用文化」そのものを変革する取り組みです。 統合されたロギング、監視、分散トレーシングによってシステムの健全性が高まり、障害発生時の迅速な対応が可能となることで、 ビジネスのレジリエンス が強化されます。 この変革の鍵を握るのは、 CI/CD、セキュリティ、可観測性といった要素を統合して提供するプラットフォーム であるOpenShiftの存在です。 安定した運用基盤を手に入れることで、運用部門はインフラの保守や障害対応といった 「守りの工数」 を削減し、ビジネス価値創造といった 「攻めのIT」 に集中できるようになります。 次回からはリファクタリングです。 数回に分けてマイクロサービスアーキテクチャや分散システムが進んだ世界だとどうなるかをお伝えする予定です。 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？  Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」  ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。  www.redhat.com

RHELのスペシャリストソリューションアーキテクトの田中司恩( @tnk4on )です。 先日、Red Hat Enterprise Linux (RHEL) の最新マイナーリリースである RHEL 10.1 および RHEL 9.7 の一般提供（GA）が発表されました！ Red Hatのテクニカルマーケティングマネージャー、Nate Lager氏が自ら新機能や改善点を解説するライブストリーム（ Red Hat Enterprise Linux 10.1 and 9.7 release live stream! ）が公開されています。 www.youtube.com この記事では、約38分間の動画の内容をトピックごとにタイムスタンプ付きで詳細にまとめました。忙しくて動画を見る時間がない方も、この記事で最新情報をキャッチアップしてください！ 🚀 イントロダクションと注目の新機能 (00:00 - 03:41) まず、Nate Lager氏からRHEL 10.1と9.7のリリースが発表され、今回のリリースの「目玉機能（Marquee Features）」が紹介されました。 AI アクセラレーター: NVIDIA, AMD, Intel の最新AIハードウェア（GPUなど）に対応した検証済みドライバーへのアクセスが、RHELのリポジトリを通じて格段に容易になりました。 オフライン RHEL コマンドラインアシスタント (開発者プレビュー): これまでクラウド接続が必須だったAI搭載のコマンドラインアシスタント（CLA）が、オンプレミス環境でも実行可能になります。 ソフトリブート: OS全体を再起動せず、ユーザー空間（サービスやアプリケーション）のみを数秒で再起動できる機能が導入され、アップデート適用時のダウンタイムを大幅に短縮します。 耐量子暗号 (PQC) の進展: 将来の量子コンピュータによる脅威に対応するため、RHEL 9および10で耐量子暗号（PQC）への対応がさらに進みました。 New Marquee Features 💡 イノベーション（Innovation） (03:42 - 10:19) AI機能の強化と、管理者の運用を助けるアシスタント機能のアップデートです。 (03:46) AI アクセラレーターの詳細（RHEL 10.1）: RHEL 10.1では、各ベンダー（NVIDIA, AMD, Intel）のドライバーが公式リポジトリから提供されます。これにより、コンプライアンスを維持しつつ、AI/MLワークロードに必要なハードウェアを信頼性の高い方法でセットアップできます。 AI Accelerators for Red Hat Enterprise Linux (05:35) コマンドラインアシスタント (CLA) の改善（RHEL 10.1/9.7）: リクエストサイズの増加: アシスタントに分析させるログやコマンド出力の最大サイズが、従来の2KBから 32KB へと大幅に増加しました。 オフライン CLA (開発者プレビュー): Satellite サブスクリプションを利用することで、セキュアな（閉域網の）環境でもAIアシスタントを利用できるようになります。 Red Hat Enterprise Linux Command-Line Assistant 開発者エクスペリエンスも大きく向上しています。 (07:58) 最新ツールチェーンのサポート（RHEL 10.1/9.7）: Go 1.24 LLVM 20 Rust 1.88 GCC 15 .NET 10 WSL (Windows Subsystem for Linux): RHEL Image Builderを使用してWSL2イメージをを作成できるようになりました。 New developer features and enhancements (08:50) RHEL for Business Developers: 組織内の開発およびテスト用途のみ、1ユーザーあたり最大25のRHELサブスクリプションがセルフサービスで無償利用可能になりました。 Red Hat Enterprise Linux for Business Developers RHEL for Business Developersの詳細については以前の記事を参照ください rheb.hatenablog.com 🛠️ 運用性のシンプル化 (Simplify) (10:20 - 17:30) システム管理をより簡単かつ効率的にする機能が追加されました。 (10:22) ソフトリブート (Soft-Reboots)（RHEL 10.1）: カーネルを再起動しないため、ファームウェアの初期化などをスキップできます。 イメージモード（ bootc update ）でのOSアップデート適用や、パッケージモード（ systemctl soft-reboot ）での迅速なサービス再起動に絶大な効果を発揮します。 Soft-Reboots for Red Hat Enterprise Linux (12:24) コンテナツールの再現可能なビルド（RHEL 10.1/9.7）: Podman や Buildah でコンテナイメージをビルドする際、タイムスタンプなどの変動要素が排除され、同じ内容なら必ず同じハッシュ値のイメージが生成されるようになりました。CI/CDパイプラインやコンプライアンス監査に非常に有効です。 Reproducible Builds for RHEL Container Tools (13:44) 新しい Image Builder CLI (Tech Preview)（RHEL 10.1）: 従来必要だったバックグラウンドサービスなしで、RHELイメージをビルドできる新しいCLIツールです。CI/CDへの統合がより容易になります。 New Image Builder Command Line Interface (15:00) RHEL システムロールのアップデート（RHEL 10.1/9.7）: HA (High Availability): クラスター設定の迅速な再作成が可能に。 Time: NTPクライアント（chronydなど）やIPv4/v6の指定に対応。 Metrics: Apache Spark メトリクスのサポートを追加。 Podman: Podman設定ファイル（TOML形式）の管理に対応（RHEL 10.1のみ）。 Red Hat Enterprise Linux System Roles 🛡️ セキュリティの強化 (Protect) (17:31 - 22:54) セキュリティはRHELの中核です。今回も大幅に強化されています。 (17:32) 耐量子暗号 (PQC) for RHEL 9.7: RHEL 9.7がPQCに対応し、OpenSSLを通じて標準アルゴリズム（ML-KEM, ML-DSA）をサポートします。 Post Quantum Crypto for RHEL 9.7 (18:48) 強化された PQC TLS サポート (RHEL 10.1): RHEL 10.1では、将来の「盗聴しておき、後で解読する（Collect Now, Decrypt Later）」攻撃に備え、PQC-TLSをデフォルトでサポートします。 Enhanced PQC TLS Support (19:57) ACME サポート: RHEL IdM (Identity Management) がACMEサーバーとして機能し、環境内のWebサーバーなどのTLS証明書を自動発行・更新できるようになります。 Automatic Certificate Management Environment (21:15) OpenTelemetry と TPM サポート: クラウド環境で仮想TPM (vTPM) をサポート。暗号鍵をvTPM内のセキュアな領域に保存し、より強固な認証や署名操作が可能になります。 OpenTelemetry Trusted Platform Module support 🤝 信頼と管理 (Trust) (22:55 - 24:50) エコシステムとアップグレードパスの整備も進んでいます。 (22:58) Red Hat Satellite 6.18 ハイライト: Red Hat Lightspeed（脆弱性・アドバイザーサービス）との連携、オフラインCLAのサポート、FlatpakのWebUIサポートなど、管理機能が強化されました。 Red Hat Satellite 6.18 highlights (24:32) LEAPP アップグレード: RHEL 9.7 から RHEL 10.1 へのインプレースアップグレード が正式にサポートされました。 LEAPP upgrades from RHEL 9.7 to 10.1 🔄 ライフサイクル (Lifecycle) (24:51 - 28:31) 最後に、RHEL 7, 8, 9, 10 のサポートライフサイクルと、各マイナーリリースのサポート期間についてのおさらいがありました。 (24:56) RHEL 7 の状況: RHEL 7 は現在、 「Extended Life Cycle Support（ELS）」フェーズ にあります。これは標準の10年間のライフサイクルが終了した後の有償アドオンサポートです。もしELSアドオンを契約していない場合、セキュリティアップデートやバグフィックスは提供されていません。動画でも、まだRHEL 7を利用している場合は 新しいRHELへの移行を強く推奨 しています。 Red Hat Enterprise Linux 7 (25:36) RHEL 8, 9, 10 の標準ライフサイクル: RHEL 8以降のメジャーリリースは、一貫して 10年間のサポートライフサイクル が提供されます。この10年間は、以下のように分かれています。 フルサポート (5年間): 新機能の追加、ハードウェアサポートの追加、バグフィックス、セキュリティ修正が提供されます。 メンテナンスサポート (5年間): 主に重大なセキュリティ修正とバグフィックスが中心となり、新機能の追加は行われません。 Red Hat Enterprise Linux 8, 9, and 10 （注意）10年間のサポートが提供されるのは 各メジャーリリース に対してのみです。マイナーリリースごとについてのサポート期間は次のトピックを参照ください。 (26:33) マイナーリリースのタイムラインと EUS: 動画では、RHEL 10, 9, 8 の各マイナーリリース（例: 9.0, 9.1, 9.2...）ごとのサポート期間を示すタイムライン（ガントチャート）が提示されました。 特に重要なのが「 Extended Update Support（EUS） 」です。 通常、セキュリティ修正は最新のマイナーリリース（例: 9.7）に対してのみ提供されますが、特定のアプリケーションの互換性維持や検証サイクルのために、特定のマイナーリリースバージョン（例: 9.6）に固定（バージョンロック）したいというニーズがあります。 EUSは、そのような企業向けのアドオンで、 特定の偶数番号のマイナーリリース （例: 9.4, 9.6, 10.0, 10.2）に対して、標準より長く（約2年間）セキュリティ修正やバグフィックスを受け取れるようにするものです。 動画のタイムラインでは、RHEL 10.1 は EUS の対象外であり、次の EUS は RHEL 10.2 となる予定であることが示されています。 Red Hat Enterprise Linux 10 Red Hat Enterprise Linux 9 Red Hat Enterprise Linux 8 （注意）EUSは定められた期間内においてのみ、通常よりも長くサポートが提供されるものです。定められた期間を超えて、 同じマイナーリリースバージョンを使い続けることを推奨するものではありません 。 📚 まとめと追加リソース (28:32 - 38:32) 今回のリリースでは、AIハードウェアへの対応強化、AIアシスタントのオンプレミス対応、ソフトリブートによる運用効率化、そしてPQC対応による将来のセキュリティ脅威への備えなど、多岐にわたるアップデートが行われました。 動画内では、Red HatのYouTubeチャンネルや、無料で試せるハンズオンラボ（ lab.redhat.com ）なども紹介されています。 ぜひ動画本編もチェックして、新しいRHELのパワーを体感してみてください！ 参考リンク 動画内で紹介された各機能の詳細は、ブログ記事やリリースノートを参照ください。 Red Hat Delivers Evolving Foundation for Modern IT with Latest Version of Red Hat Enterprise Linux Red Hat Delivers Enhanced Experience for AI Accelerators on Red Hat Enterprise Linux What's new in Red Hat Enterprise Linux 10.1 Introducing Red Hat Enterprise Linux 9.7 Install AI accelarator drivers with a single command on Red Hat Enterprise Linux 10.1 リリースノート | Red Hat Enterprise Linux | 10 | Red Hat Documentation 9.7 リリースノート | Red Hat Enterprise Linux | 9 | Red Hat Documentation

RHELのスペシャリストソリューションアーキテクトの田中司恩( @tnk4on )です。 2025年7月、Red Hatは、企業・組織内の開発者向けに、Red Hat Developer Programを介して「Red Hat Enterprise Linux for Business Developers」という新たな無料サブスクリプションを発表しました。 developers.redhat.com Red Hat Enterprise Linux (RHEL) は、安定性、信頼性、セキュリティを提供するエンタープライズLinuxプラットフォームとして世界をリードしています。開発者がこの強力なプラットフォームを無料で利用できるように、Red Hatは複数の無料サブスクリプションを提供していますが、特に個人の開発者か、組織内の開発者かによって選ぶべきものが異なります。 開発者向けのRHELサブスクリプションの紹介ページはこちら。 www.redhat.com 本記事では、既存の Red Hat Developer Subscription for Individuals を基準に、新しいRHEL for Business Developersがどのような開発者に最適か、その違いを解説します。 1. Red Hat Developer Subscription for Individuals Red Hatは、開発者向けのRHELの無償サブスクリプションとして Red Hat Developer Subscription for Individuals を提供しています。これは、 個人の利用 を主な目的として設計されています。 Red Hat Developer Subscription for Individualsの特徴 特徴 Red Hat Developer Subscription for Individuals 主な対象者 個人 開発者 主な利用目的 個人的な プロジェクトや実験を目的とした開発、テスト、 またはプロダクション（本番）利用 提供範囲 RHEL (x86_64, ARM64) (Satelliteなし)、その他のRed Hatソフトウェア エンタイトルメント数 1ユーザーあたり 16ノード（インスタンス） まで 取得・管理方法 セルフサービスモデルで、個人が管理する Red Hat Developer Subscription for Individualsの最大の特徴は、 個人利用に限り、開発だけでなくプロダクション用途にも利用できる 点です。また、「 Red Hat Developer Subscription」という名前が示す通り、RHEL以外のソフトウェアも含まれています。 ただし、個人の利用を前提をしており、組織内での利用用途には使えない点に注意が必要です。 2. 新しい選択肢：RHEL for Business Developers 2025年7月に発表された RHEL for Business Developers は、 組織内でRHELを開発・テストに使用したい企業開発者 のニーズをカバーします。 Red Hat Developer Subscription for Individualsとの比較 比較項目 Red Hat Developer Subscription for Individuals RHEL for Business Developers 利用目的 個人利用（開発、テスト、 プロダクション 利用可能） 組織内の 開発およびテスト用途 のみ エンタイトルメント数 1ユーザーあたり 16インスタンス まで 1ユーザーあたり 25インスタンス まで 対象者 個人開発者 企業や組織内の開発者 提供ソフトウェア RHEL (x86_64, ARM64) (Satellite除く)、その他のRed Hatソフトウェア RHEL（全アーキテクチャ対応）（Satellite除く） サポート セルフサポート セルフサポート 重要なポイント: 利用目的の明確化: RHEL for Business Developersは、企業や部門レベルのプロジェクトの開発・テスト用に 費用ゼロ（no-cost） で利用できます。これにより、開発者はIT部門が本番環境向けに承認したのと同じOS上で開発を開始できます。 エンタイトルメントの増加: RHEL for Business DevelopersはRed Hat Developer Subscription for Individualsよりも多い 25エンタイトルメント を提供します。これは、開発者が物理、仮想、またはクラウドベースのインスタンスを25個まで利用できることを意味します。 統合ツールの強化: RHEL for Business Developersには、プロアクティブな問題特定、脆弱性アラート、稼働時間最適化のためのガイダンスを提供する統合分析および修復ツールである Red Hat Insights が含まれています。また、コンテナ開発ツールである Podman Desktop との連携や、Windows Subsystem for Linux (WSL)との統合機能も含まれます。 RHEL for Business Developersの始め方 個人向けのRed Hat Developer Subscription for Individualsと同様に、Red Hat Developerのサイトから簡単に登録できます。 developers.redhat.com Red Hat アカウントを取得し、ログインしたた状態で下記の「Access now」ボタンを選択するだけで、自動で登録が完了します。 RHEL for Business Developersの入手 RHEL for Business Developersへの登録完了 登録されたRHEL for Business Developersのサブスクリプション サブスクリプションの更新は、Red Hat Developer Subscription for Individualsと同様に 年次更新 です。 サポートの利用について RHEL for Business Developersは基本的にセルフサポートですが、追加のサポートが必要な場合、 Red Hat Developer Subscription for TeamsサポートSKU を購入することで、サポートをオプションで追加できます。例えば、25人の開発者向けの「Professional (RH02253)」サポートSKUは、開発に関する質問に限定されますが、2営業日以内のSLAを提供しています。詳細はRed Hatの担当営業までご確認ください。 3. 大規模環境の選択肢：Red Hat Developer Subscription for Teams Red Hat Developer Subscription for IndividualsやRHEL for Business Developersがセルフサービスや個人/小規模チーム向けであるのに対し、 Red Hat Developer Subscription for Teams は、より 大規模で集中管理が必要な組織 に適したサブスクリプションです。 Red Hat Developer Subscription for Teamsは、 ハイタッチな営業主導型のオファリング であり、個人での申し込みはできません。 大規模環境の管理: Red Hat Developer Subscription for Teamsは 無制限のエンタイトルメント を提供し、 Satellite管理にも対応 しています。 集中管理: RHEL for Business Developersでは開発者自身が年次更新を管理する必要がありますが、Red Hat Developer Subscription for Teamsでは企業が集中管理します。 対象: 大量の組織内開発ユーザーを抱える企業は、IT部門がサブスクリプションを中央で管理しやすくなるRed Hat Developer Subscription for Teamsプログラムへの移行を推奨します。 まとめ：あなたの開発環境に最適なのは？ 選択肢 最適な利用シーン Red Hat Developer Subscription for Individuals 個人 が趣味やスキルアップ目的で利用し、小規模な 本番環境 でも使いたい場合。 RHEL for Business Developers 組織内の 開発者 が、本番環境と同じRHEL環境を 無料・セルフサービスで 、導入の障壁なしに開発・テストに利用したい場合。 Red Hat Developer Subscription for Teams 大規模なIT部門 が、集中管理ツール（Satellite）や無制限のノード数を用いて、全社の開発環境を管理・標準化したい場合。 RHEL for Business Developers は、あらゆる企業の開発者が コスト障壁なし に、安定したエンタープライズプラットフォーム上でアプリケーションを迅速に構築・デプロイするための理想的な手段を提供します。今すぐ developers.redhat.com からRHEL for Business Developersを始め、RHELを使って開発を加速させましょう！

Red Hat コンサルタントの中川です。「アプリケーションモダナイゼーション」に関連する連載の第6回目です。 本連載では「アプリケーションモダナイゼーション」をテーマに、現場で役立つ実践的な知見をお届けしています。 モダナイゼーションに関連する連載記事はこちらを参照ください。 第1回 【Application Modernization | 第1回】アプリケーションモダナイゼーションとは何か？ - 赤帽エンジニアブログ 第2回 【Application Modernization | 第2回】なぜ今、モダナイゼーションなのか？～エンジニアを悩ませる「技術的負債」からの脱却 - 赤帽エンジニアブログ 第3回 【Application Modernization | 第3回】最初の一歩：現状分析（アセスメント）の進め方 - 赤帽エンジニアブログ 第4回 【Application Modernization | 第4回】目標設定とロードマップ策定 - ゴールの明確化と現実的な計画 - 赤帽エンジニアブログ 第5回 【Application Modernization | 第5回】Replatformで変わる開発と運用体験 - 赤帽エンジニアブログ はじめに：「ただのインフラ刷新」で終わらせないために 1. CI/CDによる高速化 2. 継続的な脆弱性診断による安全性 3. 分散トレーシングによる信頼性 まとめ Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  はじめに：「ただのインフラ刷新」で終わらせないために 今回は、前回に引き続きReplatformにフォーカスしていきます。アプリケーションモダナイゼーションの手法として「Replatform」を検討する際、多くの方がサーバーを「オンプレミスからクラウドへの移行」や、「VM環境からコンテナ環境への移行」といったインフラの刷新をイメージされるかもしれません。 しかし、その取り組みを単なる "お引っ越し" で終わらせてしまうのは、非常にもったいないです。 Replatformの真の価値は、本タイトルにもあるように、アプリケーション開発のライフサイクル全体を 「高速」かつ「安全」 なものへと変革することにあります。この変革を実現する上で、成功の鍵を握るのが、アプリケーションを動かすだけでなく、開発から運用までのプロセス全体を支えるエンタープライズ向けコンテナプラットフォームの存在です。 本記事では、Red Hat OpenShiftを具体的なプラットフォームとして念頭に置きながら、Replatformがもたらす 「1. CI/CDによる高速化」「2. 継続的な脆弱性診断による安全性」「3. 分散トレーシングによる信頼性」 という3つの具体的なメリットを深掘りしていきます。 1. CI/CDによる高速化 【Before】かつての開発風景 かつての開発現場を思い出してみてください。ソースコードの変更を本番環境に反映するには、開発者による手作業でのビルド、テスト担当者へのリリース依頼、そしてインフラ担当者による深夜や早朝のデプロイ作業…といった、多くの手作業と伝言ゲームが発生していました。「自分のローカルPCでは動いたのに…」という問題も日常茶飯事だったかもしれません。 【After】OpenShiftがもたらす変化 Red Hat OpenShiftのようなコンテナプラットフォームは、このような状況を改善します。Kubernetesを核とした統合プラットフォームであるOpenShiftは、開発者がインフラを意識することなく、必要な環境をセルフサービスで利用できる世界を提供します。 その中で、クラウドネイティブなCI/CDを実現する中核ツールが OpenShift Pipelines (Tektonベース) です。Tektonは、パイプラインそのものをコンテナとして定義・実行するため、特定のCI/CDサーバーに依存せず、スケーラブルで再利用性の高いパイプラインを構築できます。 開発者が行う作業は、ソースコードをGitにプッシュするだけ。それをトリガーに、以下のようなプロセスが自動的に実行されます。 ソースコードの取得: Gitなどのソースコードリポジトリから最新のコードをチェックアウトします。 テストの自動実行: ソースコードに対して単体テストを実行し、品質を担保します。 コンテナイメージのビルド: テストをパスしたソースコードから、DockerfileやSource-to-Image (S2I) といった機能でコンテナイメージを自動でビルドします。 デプロイと結合テスト: ビルドしたイメージを開発環境やステージング環境へ自動でデプロイし、必要に応じて結合テストを実行します。 この自動化されたサイクルによって、開発者は煩雑な作業から解放され、ビジネス価値の創造という本来の業務に集中できるようになります。アイデアが生まれてからユーザーに価値を届けるまでのリードタイムが短縮されます。 さらに、Gitを信頼できる唯一の情報源として、アプリケーションのデプロイや運用状態を宣言的に管理・自動化するGitOpsのアプローチも、開発体験を向上させる上で重要です。 OpenShiftでは 「OpenShift GitOps」 という機能を提供しており、これに含まれるArgo CDを利用することで、Gitリポジトリへの変更をトリガーに、アプリケーションのデプロイや更新を自動で反映させることができます。これにより、CI/CDパイプラインと連携して、一貫性のあるデプロイメントを実現します。 Red Hat OpenShift Pipelines： www.redhat.com Red Hat OpenShift GitOps： www.redhat.com 2. 継続的な脆弱性診断による安全性 【Before】リリース直前の"関所" 従来の開発プロセスでは、セキュリティ診断は開発サイクルの最終盤、リリース直前に行われることが多くありました。 この段階で重大な脆弱性が発見されると、リリースは延期され、開発チームは大きな手戻りを強いられます。 これでは、高速な開発サイクルは実現できません。 【After】OpenShiftで実現するDevSecOps この課題を解決するのが、セキュリティ対策を開発プロセスの早い段階（左側）へ移行させる「シフトレフト」という考え方、すなわちDevSecOpsです。OpenShiftは、プラットフォーム全体でこのDevSecOpsの実現を強力に支援します。 まず、土台となるOS（RHEL CoreOS）やコンテナのベースイメージ（Red Hat Universal Base Image - UBI）が、エンタープライズレベルでセキュアに保たれています。その上で、アプリケーションのサプライチェーン全体に多層的なセキュリティを組み込むことができます。 コーディング・ビルド時: OpenShift PipelinesにSonarQubeといったSAST (静的アプリケーションセキュリティテスト) ツールを組み込むことで、ソースコード自体に潜むSQLインジェクションやクロスサイトスクリプティングといった脆弱性をコーディング段階で検出します。さらに、ビルドされたコンテナイメージは Red Hat Quay によって継続的にスキャンされ、ベースイメージやライブラリに含まれる既知の脆弱性（CVE）がないかチェックされます。 デプロイ時: Red Hat Advanced Cluster Security for Kubernetes (ACS) は、「脆弱性レベル"Critical"のイメージはデプロイさせない」といったポリシーを適用し、安全でないアプリケーションが本番環境に到達するのを防ぎます。 実行時: ACSは、実行中のコンテナの異常な振る舞いを検知し、万が一の脅威にも迅速に対応します。 これらのセキュリティチェックを前述のOpenShift Pipelinesに組み込むことで、「安全でないものは、そもそも作らない、デプロイさせない」という文化を開発プロセスに根付かせることができます。 Red Hat Quay： www.redhat.com ACS： www.redhat.com 3. 分散トレーシングによる信頼性 Replatform後の新たな課題 Replatform後、特に分散システムの場合、システムは機能ごとに分割された多数のサービス群で構成されるようになります。 これにより、開発の俊敏性は向上しますが、一方で「あるリクエストが、どのサービスを、どのような順番で経由したのか」を追跡するのが非常に困難になるという新たな課題が生まれます。 OpenShiftにおけるObservability（可観測性） この複雑化したシステムの"道しるべ"となるのが、Observability (可観測性) の考え方です。 OpenShiftは、システムの内部状態を理解するための機能をプラットフォームに統合されているか、または容易に導入できるようになっています。 モニタリング: OpenShift Monitoring (Prometheusベース) が、CPU使用率やメモリ使用量といった各種メトリクスを収集・可視化します。 ロギング: OpenShift Logging (Lokiスタックベース) が、システム全体のログを一元的に集約・検索可能にします。 分散トレーシング: 分散システムでの課題を解決する切り札が OpenShift Distributed Tracing (Grafana Tempo) です。 分散トレーシングは、サービスをまたがる一連のリクエストにユニークなIDを付与し、その経路を可視化する仕組みです。 これにより、「決済処理が遅いのは、在庫確認サービスのAPI応答がボトルネックになっているからだ」といった原因究明を、データに基づいて迅速に行うことができます。 これらの機能がプラットフォームに統合されていることで、運用者は複数のツールを使い分けることなく、効率的にシステムの健全性を保ち、問題の根本原因を素早く特定することができるようになります。 OpenShiftでのロギングや監視／モニタリングについては、次回のアプリケーションモダナイゼーションブログで詳しく掘り下げていきます。 Red Hat OpenShift Observability： www.redhat.com まとめ Replatformは、単なるインフラの移行にとどまりません。 ビジネスの変化に素早く、そして安全に対応できる「開発・運用文化」そのものを変革する大きな一歩です。 この変革を成功させるには、CI/CD、セキュリティ、可観測性といった個別の要素だけでなく、これらすべてが連携する「統合プラットフォーム」が不可欠です。 Red Hat OpenShiftは、Kubernetes、Tekton、Grafana Tempoなどの技術をベースに、エンタープライズに求められる安定性とセキュリティ、長期サポートを提供します。 高速な開発、強固なセキュリティ、そして安定した運用。これらを手に入れることで、組織は本来のビジネス価値創造に集中できます。 Replatformを検討する際は、ぜひこの「基盤」となるプラットフォーム選びに注力してください。 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？  Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」  ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。  www.redhat.com

Red Hat のソリューションアーキテクトの瀬戸です。 今回はお客様から表題のような質問を受けたので簡単にまとめます。 記事の3行サマリー StandaloneモードとDomainモードはサーバー(群)をどのように管理するかの差だけ StandaloneモードとDomainモードのどちらでもセッションレプリケーションなどの高可用性機能を使用できる 台数が多い場合はStandaloneモードでAnsible/OpenShiftなどの自動化ツールを併用することがおすすめ JBoss EAPの2つの管理モード Red Hat JBoss Enterprise Application Platform (JBoss EAP) は、エンタープライズJavaアプリケーションの基盤として、2つの運用モードを提供しています。StandaloneモードとDomainモードです。 Standaloneモード：独立したサーバー運用 Standaloneモードは単体でサーバーを運用することができるJBoss EAPの運用モードです。 多くのサンプルではこちらが採用されており、何も考えずに使っているとこのモードになっています。サーバーの設定は各インスタンスが持つ独自の管理インターフェースを通じて個別に管理されます。管理者は、管理用のCLIやWebベースの管理コンソールといったツールを使用して、特定のインスタンスに直接接続し、設定変更やアプリケーションの管理を行います。 勘違いされているお客様も多いですが、Standaloneモードでもセッションレプリケーションなどの高可用性のための機能は使用することができます。デフォルトでもstandalone-ha.xmlという高可用性の機能が設定されたプロファイルが提供されていますので、Standaloneモードで高可用性のための機能を使用したい場合はそちらをベースとし、適切な設定をするようにしてください。 Domainモード：集中型のサーバー管理 Domainモードは一つ制御用のJBoss EAPサーバーを立ち上げて、そこから複数のJBoss EAPをまとめて管理することができるモードです。制御用のJBoss EAPサーバーには既存のEAPサーバーを使用することもできます。 ドメインモードの論理図(マニュアルより) 制御用のJBoss EAPサーバーからは、管理されているサーバーに対する処理を一括して行うことができます。サーバーの起動、停止、再起動やアプリケーションの更新など、Standaloneモードではそれぞれのサーバーに対して直接CLIを使うか、管理コンソール経由で設定を行わなければいけませんでしたが、それらの処理をまとめて制御用のJBoss EAPサーバーから行えるようになります。 Domainモードの詳細については 第7章 JBoss EAP のマネージドドメインの設定 | 設定ガイド | Red Hat JBoss Enterprise Application Platform | 8.1 | Red Hat Documentation を参照してください。 Domainモードの本質的な問題 DomainモードではJBoss EAPをまとめて管理する事ができます。とても便利です。しかしながら、JBoss EAPしか管理ができないという致命的な弱点があります。一つのウェブシステムには多くの要素が含まれています。JBoss EAPが必要とされるようなシステムの場合、少なくとも、JBoss EAPの他にデータベースが稼働しているはずです。また、JBoss EAPやデータベースを稼働させているOSについても管理できなくていいのでしょうか？他にバッチとかが動いている場合、そちらも同時に管理する必要はありませんか？Domainモードは便利な機能ですが、JBoss EAPしか管理ができません。JBoss EAPはシステムの一部にしか過ぎず、JBoss EAPだけをまとめて管理ができても、システム運用上、必要十分ではないと言えます。 10年以上前、JavaはJavaVMという名前の通り、Javaという世界の中ですべてを完結できるような世界を構築しようとしていました。しかし、その後に出てきたDockerやコンテナオーケストレーションなどの技術により、すべてをJavaVMで行うよりも、その外側で制御をしたほうが良くなっています。そのため、JavaVMの思想の中で生まれ、作られてきたDomainモードについても現時点ではレガシーなものと言っていいでしょう。いまだに要件としてはDomainモードが必要とされる場合もありますが、多くの場合では技術的にというよりは政治的に必要とされるものになっています。これはJBoss EAPだけではなく、その他の一般的なJavaアプリケーションサーバーすべてについても言えることです。 Ansible/OpenShiftなどの外部自動化ツールを使った運用自動化 Red Hatでは自動化の製品として、AnsibleやOpenShiftを提供しています。これらはJBoss EAPのDomainモードより後に出てきた技術で、OSレイヤーから含めて、JBoss EAPだけではなくサーバー自体をまとめて管理することができます。 JBoss EAPのDomainモードと外部ツール(Ansible/OpenShift)での管理対象の差 JBoss EAPに限らずJavaアプリケーションサーバーを使ったシステムを運用していると、WARファイルの中身は更新されますが、アプリケーションサーバーから下のレイヤーについてはきちんと更新されていない場合があります。OSを含めてセキュリティパッチがきちんと当てられない理由の一つとして、アプリケーションサーバーより下のレイヤーについては集中的な管理ができていないことが挙げられます。最近はJakarta EE問題に対する知見もたまり、多くのお客様がJBoss EAP 7.XからJBoss EAP8.Xに移行しようとしています。これを機会にDomainモードへの依存を止めて、AnsibleやOpenShiftを利用した更に広い範囲での集中管理を行ってみてはどうでしょうか。 AnsibleでのJBoss EAPの運用自動化について興味がある人は Red Hat Developerの方に記事があります ので、そちらを参照してみてください。 まとめ まとめると次のようなフローでモードを選定するとよいでしょう。 サーバーの台数は1台もしくは少数のみか？ はい → Standaloneモードを選択 いいえ → 次のステップへ アプリケーションサーバーネイティブの集中管理機能が必須要件か？ はい → Domainモードを選択 いいえ → 次のステップへ 強力な外部自動化ツール（Ansible/OpenShift等）が使用できるか？ はい → 自動化を前提としたStandaloneモードを選択 いいえ → 次のステップへ サーバー数が5台以上、かつ設定変更が頻繁に発生するか？ はい → Domainモードを強く推奨 いいえ → Standaloneモードの方がシンプルである可能性が高い 当然、Domainモードと外部自動化ツールを併用することもできます。 JBoss EAPでは最近は起動可能なJARや自動プロビジョニングの仕組みもサポートされており、外部自動化ツールとの親和性が向上しております。それらの機能に興味がある人は前回の記事: JBoss EAP 8.1 で新しくサポートされた起動可能なJAR(Bootable jar)とGalleonによるサーバーの軽量化を試す - 赤帽エンジニアブログ を参照してください。 ぜひ運用を簡単にしていきましょう。

Red Hat のソリューションアーキテクトの瀬戸です。 JBoss EAP 8.1: エンタープライズ Java アプリケーションのモダナイゼーション - 赤帽エンジニアブログ で紹介した 起動可能なJAR(Bootable jar)を試したいと思います。 起動可能なJARではJBoss EAPをアプリケーションにまとめてパッケージングすることができ、JBoss EAPのプリインストールが不要になります。 JBoss EAPをRPMでインストールしたため、バージョン管理がOS管理者側の管理になり、本来はアプリケーション管理者が一緒に管理するべきなのが分断される～～～みたいな状況を防ぐことができます。 Spring-BootやQuarkusなどではすでに一般的な方式となっており、UpstreamのWildflyでもかなり前から使えましたが、それが今回、JBoss EAP本体でもサポートされた形となります。 *1 JBoss EAPではMavenを利用したアプリケーションサーバーの自動プロビジョニングの仕組みもあるので、そちらも合わせて試したいと思います。 リポジトリは こちら 。Maven(pom.xml)についてすべてを説明できないので、必要に応じてこちらを参照してください。 github.com また、OpenJDK 21やMavenについては適切にインストールされている状態とします。 アプリケーションの自動プロビジョニング pom.xmlに次のprofileを追加します。 <profile> <id> provisioned-server </id> <build> <plugins> <plugin> <groupId> org.jboss.eap.plugins </groupId> <artifactId> eap-maven-plugin </artifactId> <configuration> <channels> <channel> <manifest> <groupId> org.jboss.eap.channels </groupId> <artifactId> eap-8.1 </artifactId> <version> ${version.eap.channel} </version> </manifest> </channel> </channels> <feature-packs> <feature-pack> <location> org.jboss.eap:wildfly-ee-galleon-pack </location> </feature-pack> </feature-packs> <layers> <layer> datasources-web-server </layer> </layers> </configuration> <executions> <execution> <goals> <goal> package </goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile> mavenを使ってビルドをします。プロファイルとしてprovisioned-serverを指定することでJBoss EAPの構築が行われます。 mvn clean package -Pprovisioned-server ビルドが終了するとtargetの下にserverというフォルダができています。 ビルドされたフォルダ その下にJBoss EAPがインストールされています。 インストールされたJBoss EAP bin\standalone.bat を実行することで起動することができます。 実行結果 実行可能なJar(Bootable jar) pom.xmlに次のプロファイルを追加します。アプリケーションの自動プロビジョニングとの差分は <bootable-jar>true</bootable-jar> だけです。 <profile> <id> bootable-jar </id> <build> <plugins> <plugin> <groupId> org.jboss.eap.plugins </groupId> <artifactId> eap-maven-plugin </artifactId> <configuration> <channels> <channel> <manifest> <groupId> org.jboss.eap.channels </groupId> <artifactId> eap-8.1 </artifactId> <version> ${version.eap.channel} </version> </manifest> </channel> </channels> <feature-packs> <feature-pack> <location> org.jboss.eap:wildfly-ee-galleon-pack </location> </feature-pack> </feature-packs> <layers> <layer> datasources-web-server </layer> </layers> <bootable-jar> true </bootable-jar> </configuration> <executions> <execution> <goals> <goal> package </goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile> ビルドするにはプロファイルとしてbootable-jarを指定します。 mvn clean package -Pbootable-jar 起動するためには java -jar コマンドに出来上がったjarファイルを渡してあげます。 example-bootable.jar java -jar .\target\example-bootable.jar 起動可能なJar(スクショ取り直してます) サーバーフットプリントの削減 起動可能なJAR(Bootable jar)のファイルサイズが小さいことに気がついたでしょうか？ファイルサイズが小さいだけではなく、起動時間も早くなっています。通常、JBoss EAPを起動させるには4秒～程度かかりますが、このjarファイルは私の環境では2秒程度で起動します。 *2 Galleonという仕組みでサーバーをトリミングし、不要なサービスを含めないようにしたためです。この仕組みは起動可能なJARだけではなく、アプリケーションの自動プロビジョニングでも同じように動作します。 先程のbootable-jarは83Mぐらいの大きさでした。 Galleonによるトリミングを無効化してみます。 pom.xmlから次の記述を探して削除をします。2箇所あるので注意してください。 <layers> <layer> datasources-web-server </layer> </layers> 次のコマンドでビルドし直します。 mvn clean package -Pbootable-jar これはフルサイズでのJBoss EAPを構築しているため、出来上がったbootable-jarのファイルサイズが増えていることを確認できます。 起動すると先ほどよりも起動に時間がかかっていることも確認できるはずです。 まとめ この記事では JBoss EAP 8.1: エンタープライズ Java アプリケーションのモダナイゼーション - 赤帽エンジニアブログ で紹介した内容を実際に試しました。 JBoss EAPを始めとしたJavaアプリケーションサーバーはプリインストールすることで安定した環境として動作してきましたが、最近はプリインストールをしない方法も提供されており、また、そちらのほうが管理面ですぐれているケースも発生しています。Galleonによるサーバーのトリミングを行うことでJBoss EAPは更に軽量に動作することができますので、ぜひお試しください。 参考: JBoss EAP のプロビジョニング | Red Hat JBoss Enterprise Application Platform | 8.1 | Red Hat Documentation A.2. さまざまなデプロイメントコンテキストでサポートされている Galleon レイヤー | JBoss EAP のプロビジョニング | Red Hat JBoss Enterprise Application Platform | 8.1 | Red Hat Documentation JBoss EAP 8 Maintenance Schedule - Red Hat Customer Portal eap-maven-pluginでJBoss EAPのバージョンを指定する方法は独特なので注意してください *1 : EAP XPでもかなり前からサポートされていました。 *2 : この起動時間は参考時間です。実際の起動時間はお客様の環境で計測してください。

Red Hat のソリューションアーキテクトの瀬戸です。 サマリー Jakarta EE 11はJBoss EAP 8.2.zで対応の検討がされています。ただし、JBoss EAPのライフサイクルポリシーに照らし合わせるといくつかの制限事項が発生するため、対応するべきか不透明な状態です。Jakarta EE 11の採用を期待しているお客様は サポートチャンネル か最寄りの営業担当までご連絡ください。 今までのJBoss EAP 8.X JBoss EAP 8.0はJakarta EE 10に準拠をし、 2024年2月にリリースされました。 Red Hat Application Services 製品のアップデートとサポートポリシー に定義されているように、バグ修正とセキュリティパッチは、ライフサイクルのフルサポートフェーズ、メンテナンスサポートフェーズ、およびELS-1フェーズの期間に提供されます。JBoss EAP 8.0 がリリースされた後、MicroProfile 6.1の機能と連携した互換性のある拡張パックとして、EAP XP 5.0がリリースされました。 JBoss EAP 8.1は、引き続きJakarta EE 10に準拠をしながら、2025年9月にリリースされました。ubar-jarのサポートも開始し、より使いやすくなっています。詳細については JBoss EAP 8.1: エンタープライズ Java アプリケーションのモダナイゼーション - 赤帽エンジニアブログ を参照してください。継続的なサポートをご利用いただくため、はやめのアップグレードをお勧めします。EAP XP 6.0は、EAP 8.1の互換拡張パックとして、2025年第4四半期にリリース予定です。お客様からご要望いただいた機能に加え、MicroProfile 7.0の機能を実装しています。 JBoss EAP 8.2 JBoss EAP 8.2は、Jakarta EE 10との互換性を維持しながら、2027年前半にリリースされる予定になっています。EAP XP 7.0 は、MicroProfile 7.1との互換性を持つ拡張パックとなり、EAP 8.2のリリース後3か月以内にリリースされる予定です。EAP 8.2を早めに試したいユーザー向けにベータ版が2026年後半にリリースされる予定です。 Jakarta EE 11 Jakarta EE 11仕様は2025年6月にリリースされたJakarta EE仕様の最新版です。 Jakarta EE 11では互換性を破る変更が導入 されており、Jakarta EE 10との完全な互換性はありません。これはJakarta EE 10仕様で作成されたアプリケーションがJakarta EE 11仕様の環境の下では同じ動作をしない可能性があることを意味します。 Jakarta EE 11にてどのような変更があったのかの詳細については2025年7月に行われた JakartaOne 2025 Japanで公開された資料 を参照してください。 JBoss EAP 8.2.zでのJakarta EE 11 Jakarta EE 11はJakarta EE 10と互換性が低いため、実装された場合は JBoss EAP互換性ポリシー が適用されない可能性があります。また、その場合、JBoss EAP 8.2 はJakarta EE10 モード (互換性のため) と Jakarta EE11モード (非互換性の可能性のため) という 2 つの EE モード メカニズムをサポートすることになります。 お客様の考慮事項とお願い Jakarta EE(Java EE)アプリケーションサーバーの価値は安定した長期サポートです。そのため、Jakarta EE 11については実装しても使われない可能性があるのではないかと考えています。 そのため、Jakarta EE 11を使用したいお客様については、サポートチャネルを通じて Red Hat サポートにお問い合わせの上、関心があることをお伝え下さい。もしくは最寄りの営業担当までお伝え下さい。これによりRed Hat側でJakarta EE 11のニーズがあるかどうかを判断できるようになります。十分な要望があれば、JBoss EAP 8.2.z の今後のアップデート (パッチ) のリリースで機能パックとしてサポートを提供する予定です。 参考: Runtimes Release Plans

Red Hatの小島です。 Red Hatは生成AIモデルや予測AIモデルの学習や推論を可能にするための、統合AIプラットフォーム(Red Hat AI)を提供しています。 www.redhat.com Red Hat AIはAWS Marketplaceで購入して利用できるようになっています。この場合、 Red Hat AIのサポートはRed Hatが、EC2インスタンスを含むAWSインフラのサポートはAWSが提供 します。本記事ではAWS Marketplaceから購入できるRed Hat AIのサブスクリプションについて、2025年10月時点の情報をご紹介します。 AWS Marketplaceで購入できるRed Hat Entetprise Linux AIサブスクリプション (RHEL AI) 利用料金 利用方法 事前準備 RHEL AIカタログの購入 PAYG RHEL AIの起動方法 AWS Marketplaceで購入できるRed Hat OpenShift AIサブスクリプション まとめ Red Hat AIだけでなく他のサービスも利用可能になっているので、ぜひこちらもご確認ください。 rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com AWS Marketplaceで購入できるRed Hat Entetprise Linux AIサブスクリプション (RHEL AI) RHEL AIは大規模言語モデル(LLM)をシームレスに開発/テスト/実行するための機能が統合されたRHELです。RHEL AIにはオープンソースのLLMである Granite も最初から含まれており、Graniteの操作やカスタマイズが簡単に実行できるようにするツールも提供しています。また、2025年10月時点ではRed Hatがサポートする構成ではありませんが、RHEL AIではGranite以外のLLMも実行できます。 RHEL AIの概要やAWS上でのRHEL AI実行についての詳細は、次のブログにまとまっています。 qiita.com 上記のブログでは、Red Hatから直接購入したRHEL AIのサブスクリプションをAWS上に持ち込んで利用する(Bring Your Own Subscription. BYOS)シナリオを想定していますが、本記事ではAWS Marketplaceから購入して利用する従量課金制(Pay as you go. PAYG)のRHEL AIの利用方法をご紹介します。 利用料金 AWS MarketplaceのカタログからRHEL AIを購入して利用できます。 aws.amazon.com RHEL AIの利用料金は、EC2インスタンスの利用料金とは別にAWSから請求されます。つまり、 RHEL AIの利用料金 ($0.40/時間. どのインスタンスタイプでも同じです) EC2インスタンス(OSタイプはLinux)を含むAWSインフラの利用料金 の合計金額がAWSから請求されることになります。料金情報は、EC2インスタンス起動画面などから確認できます。AWS Marketplaceでの従量課金制のRHEL AIを利用する場合、2025年10月時点では、次の画像に記載されている3つのインスタンスタイプのいずれかのみを選択できます。 利用方法 事前準備 AWS Marketplaceのカタログから購入手続きを実施するための事前準備をします。 こちらのブログの「事前準備」 と全く同じです。 RHEL AIカタログの購入 AWS MarketplaceのRHEL AIカタログから購入手続きを実施します。最初に「購入オプションを表示」をクリックします。 続いて表示されるページの下部にある「サブスクライブ」をクリックします。 ここまでの手続きが正常に完了すると、オンデマンド専用のRHEL AIサブスクリプション(SKU: MCT4738MO)が Red Hatアカウントの「Subscription Inventory」 のページに表示されます。これでRHEL AIカタログの購入手続きは完了です。購入手続きが完了しても、実際にRHEL AIのAMIを利用してEC2インスタンスを起動しない限り、RHEL AIの利用料金は発生しません。 AWS Marketplaceから購入したRed Hatサブスクリプションは「Contract Number」が「Not Available」となっていますが、Red Hatからのサポートを問題なく受けることができます。 RHEL AIサブスクリプション(SKU: MCT4738MO)は自動更新される設定になっています。RHEL AIサブスクリプションが不要になった場合は、PAYG RHEL AIのEC2インスタンスを全て削除したあとに、 AWS Marketplaceのサブスクリプション管理画面からAMIサブスクリプションをキャンセル します。これによって、Red Hat Subscriptions InventoryのWebページからも、RHEL AIサブスクリプションが自動削除されます。 RHEL AIサブスクリプション(SKU: MCT4738MO)がRed Hatアカウントに割り当てられていない場合、これまでの手順を正しく実施していたかどうかを見直してみてください。不明点がある場合は、Red Hatのカスタマーサービスまでお問い合わせ下さい。 www.redhat.com PAYG RHEL AIの起動方法 RHEL AIはEC2コンソールのAMI選択画面から選択して起動できるようになっています。次の画面からRHEL AIを選択すると、自動的にRHEL AIの最新バージョン(2025年10月時点では 1.5)が選択されます。 RHEL AIのライフサイクル は短いため、2025年10月時点では最新バージョンしかサポートされていません。そのため、RHEL AIは常に最新バージョンを利用することを推奨しています。 RHEL AIサブスクリプションにはRed Hat AI Inference Serverサブスクリプションが含まれているため、PAYG RHEL AIのユーザーはRHEL AIのEC2インスタンス上で、Red Hat AI Inference Serverも実行できるようになっています。 www.redhat.com AWS Marketplaceで購入できるRed Hat OpenShift AIサブスクリプション Red Hat OpenShift AIはRed Hat OpenShiftの機能を基盤として、生成AIモデルと予測AIモデルの学習・推論環境を展開するためのプラットフォームを提供します。MLOps機能が統合されており、ハイブリッドクラウド環境全体における AIアプリケーションのトレーニング、チューニング、推論、モニタリングを含む包括的なライフサイクル管理を実現します。 AWS Marketplaceに 従量課金制のOpenShift AIカタログ はありますが、2025年10月時点ではこのカタログは Red Hat OpenShift Service on AWS (classic architecture) のアドオン製品( Red Hat OpenShift AI Cloud Service )として提供されるものとなっています。 2026年4月1日以降にRed Hat OpenShift Service on AWS (classic architecture)の新規クラスター作成機能が終了 することもあり、AWS MarketplaceでOpenShift AIサブスクリプションを購入して利用したい場合は、プライベートオファー経由での購入を推奨しています。「 購買専用のお問い合わせ 」のWebページからAWS MarketplaceのOpenShift AI購入希望をお問い合わせください。その際に、プライベートオファー発行に必要な情報をご案内します。ここで発行されるプライベートオファーは、年間契約式のSelf-Managed OpenShift AIサブスクリプションとなります。 OpenShift AIを無料で試してみたい場合は、60日間のSelf-support 評価版OpenShift AIサブスクリプションを次のWebページから自動発行できます。[Start your trial]ボタンをクリックして「Your product trial has started」といったメッセージが表示されれば、自動発行の手続きは完了です。 www.redhat.com 発行が完了すると、評価版のOpenShift AIサブスクリプション(SKU: SER0788)が Red Hatアカウントの「Subscription Inventory」 のページに表示されます。 この評価版サブスクリプションでOpenShift AIをお試しいただいた後に、プライベートオファーでOpenShift AIサブスクリプションをご購入いただけます。この場合、評価版サブスクリプションで構築したOpenShift AI環境をそのままご利用いただけます。OpenShift AI on ROSA with Hosted Control Planeで、OpenAI社が2025年8月にリリースしたgpt-ossというオープンモデルの実行を紹介するブログがありますので、こちらを参考にしてみてください。 rheb.hatenablog.com OpenShift AIサブスクリプションにはRed Hat AI Inference ServerサブスクリプションとRHEL AIサブスクリプションが含まれているため、OpenShift AIのユーザーは BYOSでRHEL AIをAWS上で実行 したり、 Red Hat AI Inference ServerをOpenShift上で実行 できるようになっています。 まとめ Red Hat AIをAWS Marketplaceで購入して利用する方法をご紹介しました。オンプレミスとAWSのハイブリッドクラウド環境でオープンソースのAIインフラストラクチャーを効率的に導入できるようになっています。ぜひご活用ください。

こんにちは。RHELのスペシャリストソリューションアーキテクトの田中司恩( @tnk4on )です。 今回は、Red HatのYouTubeチャンネルで公開された短い動画「 The modern Linux platform in 60 seconds 」の内容を分かりやすくご紹介します。この動画は、Red Hat Senior Principal Product Manager for RHELであるScott McCarty氏が解説していますが、彼が 文字通り「60秒でまとめきる」というミッションを達成しようと必死に早口で語り切る様子 は、思わず笑ってしまうほどユーモラスです！この短い動画に、現代のLinux運用の抱える課題と、Red Hat Enterprise Linux (RHEL) の目指す方向性が凝縮されています。 www.youtube.com 昔の「イケてる」エンジニアは今では通用しない？ 動画は、過去と現在のLinux環境を対比するところから始まります。 1990年代の中頃から後半にかけてLinuxに携わっていた頃、あなたがもし sed や awk のコマンドを暗記していて、自由自在に使いこなせたり、 grep のスキル *1 が非常に優れていたりすれば、「すごくクールなエンジニア」でした。 しかし、残念ながらそのスキルだけでは 今日では通用しません 。 なぜなら、この20年間で環境が劇的に変化したからです。 ワークロードの爆発的な増加とシステム管理者の限界 現代では、Linuxサーバーはクラウドにデプロイされるのが当たり前になり、管理しなければならないソフトウェアの規模は 信じられないほど拡大 しました。 その結果、 すべてのソフトウェアの専門家であることは不可能 になっています。 さらに大きな問題は、スケーリングです。 かつては10程度のワークロードを運用していればよかったかもしれません。しかし、今や私たちは同じ環境で 何千ものワークロード を実行しています。にもかかわらず、システム管理者をそれに応じて増員（スケール）することはできていません。 この「複雑化する世界で、いかに効率的にスケールさせるか」が、現代のLinuxプラットフォームが直面している根本的な課題です。 RHEL 10が目指す、知識と自動化によるスケーリング支援 Red Hatは、 RHEL 10 を通して、この課題を解決しようと取り組んでいます。 専門家がすべてのソフトウェアに精通していなくても問題なく運用できるよう設計されています。RHELは 「知識」そのものをシステムへ組み込む アプローチを採用しています。 具体的にRHELは以下の機能を通じて、スケールアップを支援します。 コマンドラインアシスタント Red Hat Insights for RHEL planning Image mode for RHEL これらの目標は、運用に必要な すべての知識をパッケージ化 し、それをイメージとして構築して、環境内で 非常に効率的な方法で移動 できるようにすることです。 これにより、ユーザーはますます複雑化する環境下で、効率的なスケーリングが可能になります。 まとめ 「60秒でわかるモダンなLinuxプラットフォーム」という短い動画でしたが、90年代のシンプルなLinux運用を知る方から、現代の複雑なクラウド環境を管理する方まで、共感できる内容だったのではないでしょうか。 ぜひ、現代のLinuxプラットフォームが目指す方向性として、RHELの進化にご注目ください！ 【宣伝】 イベント Red Hat Summit: Connect 2025 Tokyo RHEL 10の進化にご興味をお持ちいただけたなら、Red Hatの最新動向をまとめてチェックできるこちらのイベントをぜひご検討ください。 Red Hat Summit: Connect 2025 | Tokyo が、「 AIの未来をオープンソースが創り出す 」をテーマに今年も開催されます。 開催日時： 2025年10月8日（水） 会場： 赤坂インターシティコンファレンス（ライブ配信あり） 参加費： 無料（要事前登録） 登録URL： https://www.redhat.com/ja/summit/connect/apac/tokyo-2025 本カンファレンスでは、AI、ハイブリッドクラウド、そしてオープンソース技術の未来に触れることができ、各業界のテクノロジーリーダーやRed Hatが誇るエキスパート陣による最新の知見が提供されます。 とくに、本記事のテーマである Red Hat Enterprise Linux (RHEL) 10の新機能とその活用ポイント について深く掘り下げるセッションも予定されていますので、お客様のビジネス課題に直結する気づきを得る機会として、ぜひご参加ください！ *1 : 動画内では「grep-fu」と発音。grepを使いこなす能力（grepスキル）というジョーク的な表現。

Red Hat のソリューションアーキテクトの瀬戸です。 この記事はRed Hat Developerのブログ記事　 JBoss EAP 8.1: Modernizing enterprise Java applications | Red Hat Developer を許可をうけて翻訳したものです。 Red Hat JBoss Enterprise Application Platform 8.1 リリースが利用可能になりました。これにより、幅広いデプロイメント環境にわたるエンタープライズ Java アプリケーションのサポートと最新化への取り組みが継続されます。 このリリースでは、ベアメタルや仮想マシンなどの従来のインフラストラクチャで実行する場合でも、クラウドネイティブ アーキテクチャを採用する場合でも、組織が自信を持って Java アプリケーションを構築、実行、拡張できるようにするための機能が強化されています。 この記事では、JBoss EAP 8.1リリースの新機能について解説します。これらの新機能は、Javaアプリケーションのデプロイメントを効率化し、起動時間の短縮、デプロイメントの一貫性の向上、そして移植性の向上を実現します。機能一覧については、JBoss EAP 8.1 リリースノート をご確認ください。 起動可能なJAR(ubar-jar) 起動可能なJARは、エンタープライズJavaに最新のマイクロサービスパッケージングの利便性と、JBoss EAPプラットフォームの堅牢性を与えます。起動可能なJARは、アプリケーションとJBoss EAPランタイムの両方を単一のJARファイルにパッケージ化した、自己完結型の実行可能なアーティファクトです。これにより、Spring Bootに似た簡素化されたデプロイメントモデルを実現しながら、エンタープライズグレードの機能とコンプライアンスを維持できます。 起動可能なJARを使用することで、Java EEアプリケーションのビルド、テスト、デプロイを、開発者はより容易に行えるようになります。使い慣れたMavenワークフローを使用してJARを生成できるため、CI/CDパイプラインが効率化され、開発環境と本番環境間の環境のズレが軽減されます。 アーキテクチャの観点から見ると、起動可能なJARは起動時間の短縮、より一貫性のあるデプロイメント、そしてクラウド、コンテナ、オンプレミス環境間の移植性の向上を実現します。これにより、開発者の生産性が向上し、エンドユーザーにとってより回復力と応答性に優れたエクスペリエンスが実現します。 詳細: 起動可能な JAR について (JBoss EAP ドキュメント) ※訳者注: 現時点では起動可能なJARはベアメタル上のみサポートされています。OpenShift上で使用したい場合は次のGalleonを使用してください。 サーバーフットプリントの削減 Galleon はベアメタルと仮想マシンの両方における従来の Java アプリケーションのデプロイメントにきめ細かな制御と最新化をもたらします。 JBoss EAPのGalleonレイヤーは、アプリケーションのニーズに合わせてカスタマイズされた軽量サーバーランタイムを柔軟にプロビジョニングする方法を提供します。JBoss EAPの完全なディストリビューションをデプロイする代わりに、Galleonを使用して必要なサブシステムと機能のみを含めることができます。これにより、フットプリント、起動時間、脆弱性が見つかった場合の影響範囲が削減されます。 このアプローチは、リソースの最適化、起動時間、そして環境間の一貫性が重要となるベアメタルマシンや仮想マシンへのデプロイにおいて特に有効です。Galleonを使用すると、ランタイムをコードとして定義できるため、不要な肥大化を招くことなく、繰り返し可能なビルドと合理化されたDevOpsワークフローを実現できます。 詳細: Build & deploy JBoss EAP 8 images in OpenShift with Galleon & Helm charts | Red Hat Developer ビデオによるデモ: JBoss EAP プロビジョニングによる Jakarta EE のモダナイゼーション 次のビデオでは、JBoss EAP でのGalleonを使用したトリミングと起動可能な JAR について説明しています。 www.youtube.com JBoss EAP 8への移行 今すぐJBoss EAP 8.1をダウンロードしてください 。 移行ガイド には、シームレスな移行に必要な情報が記載されています。 より大規模な移行を計画している場合は、より構造化されたアプローチについて、 JBoss EAP 7 から 8 へのチェックリスト を確認してください 。 Migration Toolkit Red Hat Migration Toolkit for Applications は、問題を特定し、実用的なガイダンスを提供することで、Java アプリケーションの移行を簡素化および加速し、JBoss EAP 8 などのプラットフォームへの移行をより効率的かつ低リスクにします。 JBoss EAP 8 サポートライフサイクル 現在サポートされているすべてのRed Hat Application Services製品のライフサイクルの日付については、次のページを参照してください。 access.redhat.com

Red Hatの森若です。 2026年1月14日にRed HatがCDN（コンテンツ配信ネットワーク）およびエンタイトルメントネットワークの近代化を予定しています。この変更により、一部のシステムではRed Hatのネットワークへのアクセスができなくなる可能性があります。 この記事では、お使いのシステムが影響を受ける可能性があるかどうかのチェックポイントをまとめました。詳細は必ず公式のアナウンスをご確認ください。 なぜ対応が必要か？ もし、影響をうけるシステムやネットワークが古い設定のままであると、2026年1月14日以降、 yum や dnf を使ったソフトウェアのアップデートやパッケージの取得、 subscription-manager でのシステム登録ができなくなる場合があります。 何が起きるの？ 以下の変更が行われます。 yum 、 dnf や subscription-manager が通信するホスト cdn.redhat.com , subscription.rhsm.redhat.com がTLSv1.2以上などの仕組みで新設されます。IPアドレスが今までと変わります。 (1)へ対応できない古いバージョン(RHEL 5, 6, 7.0-7.3)のために、今とおなじ仕組みが cdn-legacy.redhat.com 、 subscription-legacy.rhsm.redhat.com に改名して提供されます。こちらもIPアドレスは今までと変わります。 主な影響対象 お使いの環境が以下のいずれかに該当する場合、 対応が必要 な場合があります。 Red Hat Enterprise Linux (RHEL) 5, 6, および 7.3 以前のバージョン をご利用の場合 ファイアウォールでRed Hatネットワークに接続するために、 特定のIPアドレスを許可リストに登録 している場合 おおまかな対策 許可するべきIPアドレスが変わるので、ファイアウォールなどでIPアドレスを設定している人は利用バージョンによらず修正が必要です。 RHEL 5, 6, 7.0-7.3を使う人は各ホストで接続先ホストの変更が必要です。 Red Hat Satellite Serverや Red Hat Satellite Serverへ登録しているシステムには影響ありません。(ファイアウォールなどの設定変更は同様に必要です。) 詳細情報の確認と対策 詳細な情報および対策については、必ず以下のRed Hat公式記事をご確認ください。 Red Hat Content Delivery Network (CDN) & Entitlement Network Modernization Public CIDR Lists for Red Hat (IP Addresses for cdn.redhat.com) 早めに情報をご確認いただき、計画的なご対応をおすすめします。

こんにちは。Red Hat コンサルタントの志田です。 「アプリケーションモダナイゼーション（以下、モダナイゼーション）」について解説する連載の第5回目となります。これまでの記事では、モダナイゼーションの全体像や基本的な進め方、 6つのアプローチ（6R） を紹介してきました。 今回は一歩踏み込んで、その中でも特に現実的な選択肢となりやすい Replatform にフォーカスします。Replatformは、 既存アプリケーションを大きく作り変えることなく、実行基盤を変更するアプローチ です。たとえば、オンプレミスの物理/仮想サーバーからクラウド上のIaaSへ移行したり、モノリシックなアプリケーションをWebサーバーとDBサーバーに分離したりすることも含まれます。この記事では、特にニーズの高い 「VMからコンテナ基盤への移行」 に焦点を当てて、開発と運用の両面で体験がどう変わり、それがビジネスにどのような価値をもたらすのかを具体的に見ていきましょう。 なぜ Replatform が選ばれるのか？ 開発体験の変化：VMからコンテナへ 1. 開発環境が軽量化・標準化される 2. 開発と運用の分断が解消される 運用体験の変化：コンテナからコンテナオーケストレーションへ Replatform成功の鍵：よくある課題と対策 Replatform 前後での変化（まとめ） 経営層にとっての価値 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  なぜ Replatform が選ばれるのか？ モダナイゼーションの最もシンプルなアプローチに Rehost（単純移行） があります。これは既存のVMをそのままクラウドや仮想基盤に載せ替える手法です。迅速な移行は可能ですが、OSのパッチ管理やミドルウェアの更新といった運用負荷はそのまま残り、開発やデプロイは依然として手作業になりがちです。 一方で Replatform は、 アプリケーション自体を大きく作り変えることなく、実行基盤をコンテナへ移行します。 これにより、開発と運用の両面でフットワークが一段と軽くなります。 さらに重要なのは、 将来的な変革への布石 です。先にReplatformで基盤の標準化・自動化を進めておくことで、将来的に Refactor（マイクロサービス化など） へ進む際のリスクや工数を抑えることができます。つまり、Replatformは 短期的な効率化と、中長期的な変革の土台を同時に手に入れるアプローチ と言えます。 開発体験の変化：VMからコンテナへ VMで動かしていたアプリケーションをコンテナイメージ化すると、開発者の体験は劇的に変わります。 1. 開発環境が軽量化・標準化される かつては、同僚の環境を再現するためにOSの設定からミドルウェアのインストールまで手動で行い、数時間から数週間かけてVM環境を構築していました。しかし、コンテナ化によってこのプロセスは一変します。 環境構築が数分で完了 ：数分かけてVMを起動していたのが、コンテナなら数秒で起動できます。 Docker や Podman といったコンテナツールを使えば、 Dockerfile に書かれた手順通りに環境が自動で構築されます。テストサイクルが大幅に加速し、素早いフィードバックが可能になります。 「動かない」が激減 ： Dockerfile やコンテナイメージに依存関係を閉じ込められるため、「私の環境では動くのに…」といった問題が減少します。ローカルでの動作と本番環境での動作が一致するため、デプロイ後の不具合が少なくなります。 再現性の向上 ： Docker Hub や Quay.io といったコンテナレジストリを介して、開発者チーム間で常に同じ環境を共有できます。これにより、チーム全体の開発効率が向上します。 2. 開発と運用の分断が解消される VM時代は、開発環境と本番環境の間に大きな乖離があり、本番特有の問題がリリース直前に顕在化するケースが多くありました。コンテナ化によって、開発段階で定義した ヘルスチェック、リソース制御、ログ出力方式 が、運用環境でもそのまま適用されます。 これにより、開発と運用の分断が小さくなり、DevOps的なコラボレーションが自然に進むようになります。 運用体験の変化：コンテナからコンテナオーケストレーションへ 次に、コンテナ化したアプリケーションを本番環境で効率的に運用するために不可欠なのが、 コンテナオーケストレーションツール です。これらのツールは、多数のコンテナを自動で管理し、デプロイやスケーリング、監視などを容易にします。ここでは、その代表的なプラットフォームである OpenShift （Kubernetesをベースとする）に載せることで、運用側にもたらされる大きな変化を解説します。 デプロイが標準化・自動化 ：これまで手動や属人化したスクリプトに頼っていたデプロイが、Kubernetesの標準リソース（ Deployment など）によって誰でも同じ手順で実行できるようになります。 GitOps のアプローチを導入すれば、Gitリポジトリへのコミットをトリガーに自動デプロイを行うなど、CI/CDパイプライン全体を自動化できます。 スケーリングが容易に ：トラフィックの増加に応じて、アプリケーションのコンテナ数（Pod数）をコマンド一つで調整したり、 Horizontal Pod Autoscaler (HPA) のようなオートスケール機能で自動的に増減させたりできます。 監視の統合 ： OpenShift Console や Prometheus によって、アプリケーションのメトリクスから基盤のリソース状況まで、統合されたダッシュボードで一元的に監視できます。障害発生時も、アラートをもとに迅速に原因を特定しやすくなります。 セキュリティの底上げ ：開発者が特別な知識を持たなくても、プラットフォームの機能（セキュリティコンテキスト制約やイメージ署名など）によって、アプリケーションのセキュリティ水準を一定以上に保てます。 OpenShift はデフォルトで厳格なセキュリティポリシーを適用するため、安全なコンテナ運用を容易に実現できます。 特に注目すべきは、 「開発段階で用意した仕組みが、運用でもそのまま活きる」という点です。たとえば、コンテナイメージを構築する際に設定する非rootユーザー実行 などのセキュリティ設定や、Kubernetesのマニフェストで定義する ヘルスチェック は、OpenShift上でも機能します。これにより、開発・運用の両者にとって 手戻り が減り、シンプルで一貫した運用が可能になります。 Replatform成功の鍵：よくある課題と対策 Replatformは多くのメリットをもたらしますが、無計画に進めると失敗するリスクもあります。ここでは、よくある課題とその対策について解説します。 課題1：技術的負債の可視化が困難 長年運用されてきたレガシーアプリケーションは、コードベースが複雑で、どこから手を付けていいかわからないことが多いです。 対策： 既存システムのアーキテクチャや依存関係を可視化するツール（ Migration Toolkit for Applications など）を活用し、モダナイゼーションの対象範囲と優先順位を明確にします。 課題2：組織や文化の壁 開発部門と運用部門の連携が不足している場合、せっかくのモダナイゼーションの効果が半減してしまいます。 対策： Replatformを機に、開発と運用が協力してCI/CDパイプラインを構築するなど、 DevOps の文化を導入します。定期的な勉強会やワークショップを通じて、部門間のコミュニケーションを促進することも有効です。 課題3：移行に伴うサービスダウンタイム 本番環境の移行中にサービスが停止するリスクを恐れて、モダナイゼーションに踏み切れないケースがあります。 対策： ストラングラーフィグ・パターン 1 や ブルーグリーンデプロイメント といった移行戦略を採用します。これにより、既存システムと新システムを並行稼働させ、段階的にトラフィックを切り替えることで、ダウンタイムを最小限に抑えられます。 Replatform 前後での変化（まとめ） 観点 Before (VM + 仮想化基盤) After (コンテナ + OpenShift) 環境構築 手順書ベース、時間がかかる イメージ化 + マニフェストで即再現 テストサイクル VM 起動で数分 コンテナ起動で数秒 デプロイ OS やミドルを個別に管理 Kubernetes 標準リソースで一元化 運用 サーバ単位で監視・運用 Pod/Namespace 単位で可視化・自動化 セキュリティ 個別対策・属人化 プラットフォーム標準機能で一括管理 「Replatform = 単なる移行」ではなく、 開発と運用の両面で体験を刷新するアプローチ だということを実感できました。 経営層にとっての価値 Replatformの価値は、単なる技術的な改善に留まりません。これは、事業の競争力と俊敏性を強化する 戦略的な投資 と言えます。 開発スピードの向上 = 市場投入の加速 ：環境構築の時間を大幅に短縮し、開発サイクルを高速化することで、新サービスを競合より早く市場に投入できます。 運用効率化 = コスト削減とリスク低減 ：手作業に依存していた運用を自動化することで、運用コストを削減し、人的ミスによる障害リスクも低減できます。 ビジネスのレジリエンス強化 ：OpenShiftのセキュリティ機能や自己回復機能により、障害やセキュリティ事故に強い、可用性の高いシステムを構築できます。 将来の布石 ：Replatformは、将来のRefactorへのスムーズな橋渡しとなります。短期的な効率化のメリットを享受しながら、中長期的にはクラウドネイティブな変革への道を開きます。 Replatformは「単なる技術的な移行」ではなく、ビジネスの成長を支える基盤を再構築する取り組みです。この投資を成功させるには、経営層がReplatformの価値を正しく理解し、全社的な取り組みとして推進することが不可欠です。 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？  Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」  ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。  www.redhat.com 「ストラングラーフィグ（Strangler Fig）」とは、オーストラリアに自生するイチジクの一種で、既存の樹木に巻き付き、徐々にその樹を覆い尽くしていく性質を持ちます。この自然現象になぞらえたストラングラーフィグ・パターンは、既存の巨大なアプリケーション（モノリス）を一度に置き換えるのではなく、新しいサービスを徐々に追加していく移行手法です。古いシステムから新しいシステムへと機能を段階的に切り替えることで、サービス全体を一度に停止することなく、安全にモダナイゼーションを進めることができます。ストラングラーフィグ・パターンを用いた段階的移行のロードマップについては、 第4回目の記事 をご参照ください。 ↩

Konveyor AIとはなにか Konveyor AI（通称：Kai）は、レガシーソフトウェアをKubernetesのようなクラウドネイティブ環境向け、もしくは古いライブラリやミドルウェアに依存しているシステムを最新版にモダナイズするという複雑なプロセスに生成AIを統合する、先進的なオープンソースツールです。どのようにアプリケーションを変更したいのかを認識したコード提案を生成することで開発者を支援し、それによってコード修正を加速し、手作業による労力を削減することができます。 このツールは、Cloud Native Computing Foundation (CNCF) のサンドボックスプロジェクトであるKonveyorの一部として開発されています。静的コード解析によって得られる修正箇所の指摘と大規模言語モデル（LLM）の生成能力を組み合わせることで、アプリケーションモダナイゼーションの経済性を根本的に変えることを目指しています。特定のLLMに依存せず、組織独自の開発パターンを学習する能力を持つ、大規模なエンタープライズアプリケーションの修正のための強力なツールであるとともに、AIの使い方の良いサンプルでもあります。 企業が抱える古いアプリケーション 多くの企業では古いアプリケーションを多数抱えています。例えばJava SE 8はリリースされてから10年以上経っていますが、いまだに多くの企業では使用されています。それ以前のJavaが使われている場合もあります。多くのシステムではサポートが行われないまま使用されており、多くの脆弱性が見逃されています。安全に使い続けるためにはライブラリの最新化が必要になります。今動いているシステムでどれくらいの脆弱性が含まれているかを調べる方法については次の記事を参照してください。 rheb.hatenablog.com ただ、脆弱性が含まれていることがわかったとしても、実際にアプリケーションのライブラリの最新化を行うためには多大な労力がかかります。なので、行いたいとは思っても、実際には行われてきませんでした。しかし、それを手助けすることができるプロジェクトが存在します。それがKonveyorです。 Konveyor Konveyorプロジェクトは、組織がオープンハイブリッドクラウド向けにアプリケーションをモダナイズするのを支援することを目的として、Red HatとIBM Researchによって立ち上げられました 。安全かつ予測可能な方法で大規模なモダナイゼーションを実現するためのツールを提供することにより、Kubernetesの採用を加速することを目標としています。 2022年7月26日にCNCFのサンドボックスプロジェクトとして承認されました。ここで開発されたアプリケーションは多くの組織で使われているのとともに、Red HatでもMigration Toolkit for Applicationsという名前で製品化されています。 Migration Toolkit for Applications が何かを知りたい人は次の記事を参照してください。 rheb.hatenablog.com Konveyorの課題とKonveyor AI Konveyorで組織のアプリケーションの移行を促進するための情報の整理や、実際に移行を行うときにどのような修正を行う必要があるかの検出を行うことができました。その中で、実際に移行を行うときにどのような修正を行う必要があるのか、修正箇所の指摘はしてくれるものの、実際にどのような修正を行うべきかについてはわかりにくい場合がありました。 それに対して、AIを使って解決しようという取り組みがKonveyor AIです。 GitHubにあるKonveyor AIのリポジトリ で公開されている動画を見てみましょう。 ここではJakarta EEで使用されているEJBをMigration Toolkit for Applicationsで指摘されたメッセージを元に自動的にREST APIに変更しています。 *1 EJBからREST APIへの変更 必要に応じて動画を止めてもらいながら、自分だとどうやって修正するかを考えてみてください。これらの修正提案をAIを活用して自動的に行なってくれるというのがKonveyor AIの機能です。 Konveyor AIとRAG Konveyor AIではRAGという手法が使用されています。RAGはAI(LLM)に外部データからの検索機能を組み合わせることで信頼性の高い、最新の情報に基づいた回答を生成する技術です。 Konveyor AIはRAGの考え方を採用し、今までに行われた修正内容をDBとして構築し、そこに問い合わせを行うことで高品質な修正案を生成してくれます。AIを使ったコード修正は今までも行うことができましたが、どうしてもJavaに存在しないAPIをいつの間にか呼び出してしまうとか、コンパイルが通らない、もしくは全くでたらめな修正案が出てくることがありました。それらの精度を高めるために採用された手法となります。 Konveyor AIの利点・差別化要素 Konveyor AIの素晴らしいところは修正内容をDBとして保持することにあります。通常、組織内では多くのシステムが構築されています。その中には社外には公開されていない社内向けライブラリが含まれており、それらの移行方法はオープンなAIの多くは知っていません。そのため修正案を提供する事はできません。できたとしてもでたらめな場合が多数となります。 Konveyor AIではDBを持っているため、一度修正方法が決まったものについてはDBから過去の修正方法を元に修正案を提供することができます。最初に修正方法を人間が決める必要はありますが。既存のAIに比べての差別化要素となります。また、組織内でのRAGを使用したナレッジ収集の方法としての一つのサンプルともなるでしょう。 また、RAGを使用することで、AI部分はなんでもいいということも挙げられます。将来的により良い性能のAIが出てきた場合にはすぐに新しいAIに乗り換えることもできます。毎月のようにAIの性能が向上している現状では、特に優れた点となるでしょう。 Konveyor AIの課題 Konveyor AIではいまだ進行中の課題もあります。大きなものとしては複数のファイルにまたがって伝搬する変更(例えば、メソッド名の変更)を行うことができないことです。現時点ではファイル単位の変更に焦点が当てられていますが、今後はリポジトリ単位での整合性を保った修正が行えるように研究がされています。 さて、試そう！ 10月8日に行われるRed Hat Summit: Connect 2025 Tokyo ではKonveyor AIを使ったワークショップを行う予定です。 この先進的なツールを体験してみたい方はぜひご参加ください。 生成AIでアプリケーションのコンテナ移行を加速Konveyor AI体験型Workshop *1 : Jakarta EEからQuarkusへの移行を行っています。

こんにちは。Red Hatコンサルティングチームの木嶋です。 生成AIの活用が広がっていますね。 私たちも日々「どこまで効率化や高度化に役立てられるのか」検証を進めています。 私自身はエンタープライズアーキテクチャ (EA) やマイクロサービスアーキテクチャといった全体設計レビューを担当することが多いのですが、この領域を担える人材が不足している組織も少なくありません。 弊社が持っているツールの一つにMigration Toolkit for Applications (MTA) があります。 これは例えばJBoss EAPからSpring Bootなど、異なるミドルウェアやランタイムに移行するときに実行するコードアセスメントツールです。 ただし実はこのツールのアウトプットには、リポジトリ全体に対して実行した場合、システム全体の構造を把握するのに役立つ情報が多く含まれています。 そこで今回は、このMTAのアウトプットを活用してどこまで理想に迫れるのか、試してみました。 まずは結果から 結論から言うと、さすがにシステムを長年お守りしている熟練アーキテクトほどではないかもしれませんが、そこそこのレビュー結果を出すことができます。 今回お見せしてもいいように、トレーニングに利用している環境の結果をサンプルとして利用しています。 C4アーキテクチャ図 案外これ更新できていないシステムが多いですよね。 サンプルはL2のコンテナ図ですが、L1のシステム図も生成できます。 コンテナ図 拡大してご覧になりたい場合は、GitHubに格納してあります。 技術スタックの一覧 トレーニングの環境なので塩漬けにしているのがバレバレですね。 Service Spring Boot Parent Version Bill 2.6.4 Employee 2.6.7 Menu 2.6.4 Payment 2.6.4 Private 2.6.7 Transaction 2.6.4 UserProfile 2.6.7 AIによるレビューコメント 現在の構成のメリットとリスクを聞いてみました。 もちろん見えている範囲ではありますが、内容は悪くないです。 AIによるレビュー 実行手順 (MTA CLI) これを実際に実行する手順をご紹介します。 なおMTA部分を避けて生成AI部分だけ試したい方に向けて、GitHubにサンプルに使ったMTAの実行結果ファイル (output.yaml) を格納しております。 ご利用ください。 ここから先は自分のリポジトリに対して実行してみたい方向けです。 1. リポジトリをローカルにクローン 参照してみたいリポジトリをローカルにクローンします。 2. MTA CLIを入手 これだけのために入手する方にはCLIがおすすめです。 以下からダウンロードできます。 developers.redhat.com 3. MTAを実行 MTA CLI を実行します。 例として私の環境はmacOS、MTAは7.3.2を使用しています。 ./darwin-mta-cli analyze \ --input <ローカルリポジトリのパス> \ --output <アウトプットファイルの出力先> \ --overwrite 今回はtarget オプションなしとしましたが、実行に数分かかります。 気になる方は何らかの移行先を指定してください。 なおバージョンにより引数が変わることがあります。詳しくはヘルプをご参照いただくか、ヘルプの内容を生成AIに渡してコマンドを解説、生成してもらってください。 4. 生成AIに分析依頼 output.yaml を生成AIに渡してください。 今回の検証レベルでよければ、プロンプトは以下のようなもので十分です。 ローカルリポジトリに対してMigration Toolkit for Applications (MTA) を実行した結果を共有します。 この環境のC4アーキテクチャ図のコンテナ図を生成してください。 エンタープライズアーキテクトとして、この環境に対する洞察を教えてください。特に以下の点が気になります。 - 開発生産性に対するメリット - 長期的なリスク まとめ MTAの実行結果に含まれる情報は限定的ですが、生成AIに短いプロンプトを与えることでここまで可視化できます。 CIに組み込むことで、開発のたびに差分をレビューし、実装のアーキテクチャ適合性や潜在的リスクを継続的に計測することも視野に入ります。 もちろん品質を上げるためにはコンテキスト情報は必要ですし、他のツールと組み合わせたり、自作する部分もあるでしょう。例えば: アーキテクチャビジョンやアーキテクチャ原則 別ツールのアウトプット コード解析を補助するAIエージェント この実験で分かったのは、現在アーキテクチャレビューの生成AIとの協業が夢ではなく現実になったことと、それからもうすでに「できるかどうか」ではなく「どう作るか」の時代だということです。 よくある質問 MTA CLI の詳しい情報 以下の製品マニュアルをご参照ください。 docs.redhat.com リポジトリを丸ごと生成AIに読ませては？ 当然そのほうが品質が上がります。 Cursorで試した結果、もっと深い洞察を得られました。 しかし残念ながら現実的ではありません。 なぜならトークン上限にすぐに引っかかるからです。 この記事の段階ではMTAを活用した定型レビューで課題箇所をあぶり出し、必要に応じて個別に深掘りするのが現実的と思われます。 これで人間のアーキテクトは必要なくなるのか？ 生成AIは強力ですが、万能ではありません。 特に人間のアーキテクト不在のレビューは危険です。理由は以下の通りです。 生成AIのハルシネーション対策は不可欠 生成AIの出力を検証し、品質を高めるにはアーキテクトの判断が必要 ビジネスドメインの知識や組織固有の制約を踏まえた判断は代替できない 生成AIは“相棒”にはなれても、アーキテクトの代わりにはなりません。 生成AIの進化は、アーキテクトを不要にするのではなく、アーキテクトの本質的な役割をより鮮明にするものだと考えています。

はじめに Red Hat コンサルタントのフェンです。「アプリケーションモダナイゼーション」に関連する連載の第4回目となります。 本連載では「アプリケーションモダナイゼーション（アプモダ）」をテーマに、現場で役立つ実践的な知見をお届けしています。 これまでの話を振り返ってみましょう。 第1回:  rheb.hatenablog.com アプリケーションモダナイゼーションとは、単なる技術の刷新ではなく、アプリケーションの価値を現在のビジネスニーズに適合させる営みであると定義し、その戦略的選択肢として「6R」を紹介しました。 第2回:  rheb.hatenablog.com なぜモダナイゼーションが必要なのか、その根源にある「技術的負債」という深刻な問題に焦点を当てました。システムの脆弱性や非効率な運用が、いかにビジネスの俊敏性を奪っているかを見てきました。 第3回:  rheb.hatenablog.com どこから手をつけるべきか？という問いに対し、その「羅針盤」となる現状分析(アセスメント)の実施方法を解説しました。アセスメントによって、ITポートフォリオの健康状態を客観的に診断し、勘や声の大きさではなく、データに基づいた意思決定の土台を築くことができます。 しかし、羅針盤が指し示す方向が分かっても、それだけでは航海には出られません。診断結果を手に、「何が問題かは分かったが、具体的にどう治せばいいのか分からない」という「迷い」に陥ってしまうケースは後を絶ちません。 本記事は、アセスメントという羅針盤で得たデータを、実行可能な「海図」、すなわち戦略的なロードマップへと落とし込むためのナビゲーターズガイドです。このロードマップ策定の核心は、ポートフォリオ内の各アプリケーションに対し、Red Hatが提唱する6つの戦略的選択肢 （ Retire, Retain, Rehost, Replatform, Refactor, Repurchase ） のいずれかを合理的に割り当てるプロセスです。この海図は、単に進むべき航路を示すだけでなく、目的地（目標）を定義し、航海の各段階を詳述し、そして船員とその支援者（ステークホルダー）全員に、この旅の価値を納得してもらうための強力なコミュニケーションツールとなります。 そして、今回はモダナイゼーションの「目標設定とロードマップ策定 - ゴールの明確化と現実的な計画」を紹介したいと思います。 はじめに 1. 目標設定：モダナイゼーションの「北極星」を定義する 明確な目標設定のためのSMART原則 2. ロードマップの策定：目的地までの現実的な航路を描く 例1: 段階的移行のロードマップ 例2: アジャイル・ロードマップ 3. 合意形成：プロジェクトを推進する「追い風」を得る ポイント1: 対象者に合わせて伝えるメッセージを仕立てる ポイント2: トレードオフに備える まとめ：実行可能な計画こそが、変革の第一歩   1. 目標設定：モダナイゼーションの「北極星」を定義する あらゆる計画の第一歩は、「成功とは何か」を定義することです。「システムを改善する」「技術的負債を解消する」「コストを削減する」といった曖昧な目標は、プロジェクトの漂流、予算超過、そして価値欠如を招く恐れがあります。前回のステップで得たアセスメント結果こそが、具体的で意味のある目標を練り上げるための材料となります。 明確な目標設定のためのSMART原則 ここで役立つのが、効果的な目標設定のフレームワークとして広く知られる「SMART」原則です。各目標は、特定の6R戦略と密接に関連しているべきです。以下に、SMART原則の各要素と、6R戦略を意識した具体例を示します。 SMART要素 説明 具体例 S pecific (具体的) 誰が読んでも同じように理解できるほど、具体的に設定します。「5W1H」を意識することで、目標はより明確になります。 オンプレミスで稼働するJavaベースのモノリシックな「顧客管理システム」の「顧客情報参照API」を、コンテナ基盤上で稼働するマイクロサービスとしてリファクタリング( Refactor )する。 M easurable (測定可能) 成果を客観的に評価できる、定量的な指標を定義します。これにより、成功が主観的な「感想」ではなく、客観的な「事実」として測定可能になります。 「在庫管理システム」のデータベースをオンプレミスからクラウドのマネージドDBサービスにリプラットフォーム( Replatform )することで、インフラ運用コストを月額50万円から30万円以下に、40%削減する。 A chievable (達成可能) 現在のリソース（人材、スキル、予算、時間など）の制約を考慮し、現実的に達成できる目標を設定します。主要なステークホルダーからの合意も不可欠です。 「蓄積用レポートサーバー」はOSサポート切れのリスクを抱えている。アプリケーション改修は不要なため、今四半期末までにOpenShift Virtualization上のRHEL仮想マシンへリホスト( Rehost )し、セキュリティリスクを即時解消する。 R elevant (関連性) モダナイゼーションを単なる技術刷新で終わらせず、組織全体のビジネス戦略と連携させます。なぜその取り組みがビジネスにとって重要なのかを明確にします。 中期経営計画にある「ECサイトにおけるパーソナライズ機能の強化」を達成するため、機能追加を迅速に行えるアーキテクチャが必要である。その実現手段として、商品レコメンド機能をマイクロサービスとして切り出す( Refactor )。 T ime-bound (期限) すべての目標には期限が必要です。「いつまでに」を明確にすることで、プロジェクトに計画性が生まれます。長期目標の場合は、中間マイルストーンを設定することが重要です。 現行の人事管理システムを、本会計年度末（3月31日）までにSaaSソリューションへ移行（ Repurchase ）を完了させる。これにより、次年度からの保守費用を90%削減する。   2. ロードマップの策定：目的地までの現実的な航路を描く ロードマップは、単なるプロジェクトのスケジュール表やガントチャートではありません。それは、「いつ、何を、どのように」を可視化し、価値が段階的に提供される物語を伝える、戦略的なコミュニケーションツールとして捉える必要があります。 ロードマップ策定するには、様々なアプローチが存在しますが、以下では2つの例を説明します。 例1: 段階的移行のロードマップ 段階的なモダナイゼーション戦略の代表例が「ストラングラーフィグ・パターン」です。ストラングラーフィグ・パターンは、既存の古いシステム（レガシーシステム）を一度に全て作り替えるのではなく、新しい機能を段階的に追加・移行し、最終的に古いシステムを「絞め殺す（strangle）」ように置き換えていく手法です。 仕組みは以下の通りです: 継ぎ目（Seam）の特定: モノリスの中から、明確に分離可能な機能（例：商品検索機能）を見つけます。 新サービスの構築: その機能を再現する、モダンな新しいマイクロサービスを構築します。 ファサード（Proxy）の導入: モノリスの前に、リクエストを振り分ける層を設置します。最初はすべてのトラフィックを古いシステムに流します。 リダイレクト（strangle）: ファサードの設定を変更し、特定の機能（例：検索クエリ）へのトラフィックだけを新しいマイクロサービスに振り向けます。残りのトラフィックは依然としてモノリスに向かいます。 繰り返し: このプロセスを機能ごとに繰り返し、古いモノリスが担う役割がなくなるまで徐々に「絞め殺し」、安全に停止・廃止します。 このアプローチのメリット・デメリットは以下の通りです: メリット 👍 デメリット 👎 リスクを大幅に低減できる 移行期間中、新旧システムが共存し構成が複雑になる ダウンタイムを最小限に抑えられる ストラングラー・ファサードの設計・実装に手間がかかる 新しい価値を継続的に提供できる 新旧システム間でデータの一貫性を保つのが難しい場合がある 途中で計画の修正や技術の見直しが容易 モダナイゼーションが長期にわたる可能性ある   例2: アジャイル・ロードマップ 未来は不確実性があり、ビジネスの優先順位も変化します。そのため、厳格な日付ベースのタイムラインよりも、「Now-Next-Later」のような柔軟なアジャイル・ロードマップ形式を推奨します。 Now (現在): チームが今四半期に具体的に取り組んでいること。確度が高く、詳細なユーザーストーリーが存在します。 Next (次): 次の1〜2四半期で計画していること。確度は中程度で、主要な機能やエピックが定義されています。 Later (将来): 長期的に視野に入れていること。確度は低く、広範な戦略的なテーマやアイデアのレベルです。 以下のサンプルは、時間軸、戦略テーマ、6Rの選択、そしてKPIを一つの分かりやすい成果物に統合したもので、皆さんの計画策定の出発点として活用できます。 時間軸 戦略テーマ 取り組み（アプリケーション/モジュール） 6R戦略 追跡すべき主要KPI Now (Q1-Q2) インフラリスクの低減とコスト最適化 顧客管理システム (CRM) Rehost インフラTCOを20%削減 OSサポート切れリスクの解消   開発者体験の向上 請求処理バッチ (Billing Batch) Replatform バッチ処理時間を50%短縮 手動デプロイ作業の撤廃 Next (Q3-Q4) 市場投入までの時間短縮 商品検索機能 (Product Search) Refactor 新検索機能のリリースサイクルを4週→1週に短縮 検索応答速度を30%改善   不要資産の整理 旧営業支援ツール (Old Sales Tool) Retire 年間ライセンス費用1,000万円を削減 Later (3年後) 新規ビジネスモデルの実現 課金・決済モジュール (Payment Module) Refactor 新規サブスクリプションサービスの立ち上げ 決済APIの外部提供   コモディティ機能のSaaS化 人事管理システム (HR System) Repurchase 保守運用工数を90%削減 3. 合意形成：プロジェクトを推進する「追い風」を得る どんなに完璧な計画も、組織の支持を得られなければ絵に描いた餅です。合意形成は、一度きりの「承認」プロセスではなく、継続的なコミュニケーション、交渉、そして調整のプロセスです。 以下は合意を得るためのポイントを2つ紹介します。 ポイント1: 対象者に合わせて伝えるメッセージを仕立てる ここで重要なのは、コミュニケーションを一種の製品開発サイクルのように捉えることです。モダナイゼーション計画が「製品」であり、各ステークホルダーは異なる「顧客ペルソナ」です。画一的なプレゼンテーションは失敗します。それぞれのペルソナのニーズ、懸念、動機に響くように「マーケティングメッセージ」を仕立てる必要があります。 合意の対象者 彼らの言語 あなたのメッセージ 経営層・事業部門リーダー ROI, TCO, リスク削減, 競争優位性, 収益成長。 「これはITプロジェクトではなく、ビジネス投資です。X円を投資することで、運用リスクをY%削減し、Z円の新規収益を生むと予測される新サービスの立ち上げを可能にします。3年間で150%のROIを見込んでいます。こちらが、その価値を段階的に提供していくためのロードマップです。」セクション2で解説した「価値の連鎖」を用いて、この物語を構築します。 関連業務部門 (営業、マーケティング、運用など) 「私の仕事はどう楽になるのか？」「チームの業務は混乱しないか？」「ずっと要望していたあの機能はいつ入るのか？」 「遅くて使いにくいCRMへのご不満は理解しています。計画のフェーズ1では、皆さんが求めていた新しいレポート機能を搭載した、より高速で信頼性の高いシステムを第3四半期までに提供します。移行がスムーズに進むよう、皆さんのチームと緊密に連携します。」計画を彼らの日々のペインポイントや業務目標に直接結びつけます。 IT部門・開発/運用エンジニア 技術的負債, 運用負荷, 自動化, モダンなツール, CI/CD, 燃え尽き症候群。 「この計画は、深夜の障害対応や苦痛なデプロイ作業の原因となっている技術的負債に直接取り組みます。ロードマップにある請求バッチのReplatformにより、手動のデプロイプロセスを自動化します。検索機能のRefactorにより、スパゲッティコードを解消し、モダンなCI/CDパイプラインを導入することで、安全かつ迅速に機能を出荷できるようになります。」   ポイント2: トレードオフに備える 異なる部門は、しばしば相反する優先順位を持っています。営業は機能Aを、マーケティングは機能Bを、そしてIT部門は基盤が崩壊寸前だと訴えます。ここでプロジェクトリーダーが陥りがちな過ちは、全員を喜ばせようとして優先順位のない計画を作ること、あるいは「声の大きい部門」に屈することです。 そのため、あなたの役割は、優先順位を決定することではなく、データに基づいた論理的なトレードオフを促進することです。 共通のゴールを再確認する: 会議の冒頭で、合意済みの最上位ビジネス目標（例：「今年の最優先目標は顧客維持率を10%向上させることです」）を改めて共有します。 選択肢を可視化する: 競合する要望（機能A, 機能B, 基盤改修）をホワイトボードに書き出します。 客観的なデータを用いる: 各選択肢について、現状分析(アセスメント)で得たデータを提示します。「機能Aはユーザーの5%が抱える課題に対応します。機能Bはマーケティングの新規キャンペーンに必要です。一方、基盤改修はアセスメントで特定された最重要セキュリティリスクに対応するものであり、そもそも新しい機能を安定して開発するための前提条件です。」 トレードオフを提案: 「顧客維持率の向上という最優先目標と、我々の限られたリソースを考えた場合、これらのうちどれが 今 、その目標に最も大きなインパクトを与えますか？」と問いかけます。これにより、会話の焦点が「私が欲しいもの」から「ビジネスが必要とするもの」へとシフトします。ロードマップとKPIが、交渉のための中立的な土俵となるのです。   まとめ：実行可能な計画こそが、変革の第一歩 実行可能な計画は、以下の3つの柱の上に成り立っています。 目標設定: 何を達成しようとしているのか、そしてそれをビジネスが理解できる言葉でどう測定するのかを知る必要があります。 ロードマップ: リスクを管理しながら段階的に価値を提供する、現実的なアプローチに基づく計画が必要です。 合意形成: それぞれに最適化されたコミュニケーションと、説得力のある客観的なデータを通じて、幅広い組織の支持を得る必要があります。 このロードマップは、一度作って終わりではありません。 (1)ビジネス環境の変化 、 (2)新しいテクノロジー の登場、そして (3)アプリケーション自体のライフサイクル に応じて、最適な戦略は常に変化します。また、 (4)チームの成長 につれて、四半期ごとに見直され、調整されるべき「生きた計画書」です。(特にアジャイル・ロードマップの形式は、まさにこの適応性のために設計されています。) 次回は、6Rの実践に移るため、 Replatform にフォーカスし、「 Replatformで変わる開発と運用体験 」について、さらに深く掘り下げていく予定です。   Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？  Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」  ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。  www.redhat.com  

こんにちは。OpenShift SSAの瀬戸です。 現在JBoss EAP 7.Xをご利用の皆様に、サポートフェーズの変更に関わる重要なお知らせです。 2025年6月をもって、JBoss EAP 7.Xはサポートの「メンテナンスフェーズ」を終了し、 「ELS-1（Extended Life Cycle Support-1）」 という新しいフェーズに移行しました。 「このまま使い続けられるの？」「何をすればいいの？」といった疑問にお答えし、皆様が安心してJBoss EAPを使い続けるための選択肢をご紹介します。 今回の記事の詳細については: access.redhat.com 使い続けられるの？ 使い続けられます。ただし、ELSのサブスクリプションを追加購入しない限りはサポートをうけられなくなります。その中にはセキュリティパッチの提供が含まれており、新たな脆弱性が発見されても、修正されなくなります。 ELS（延長ライフサイクルサポート）で何が変わるのか？ ELSはExtended Life Cycle Supportの略です。 次のバージョンのJBoss EAPへの移行期間として提供されています。 また、サポート対象はJBoss EAP 7.4に限定され、EAP 7.0～7.3についてはサポートを受けられなくなります。 なお、ELSにはELS-1とELS-2の二段階があります。 現在は、ELS-1です。 ELS-1では提供されるセキュリティパッチが限定されます。ELSにおいては影響度が「重大」および「重要」の一部のセキュリティー修正と、優先度が「緊急」の一部 (判断は Red Hat による) のバグ修正のためのソフトウェアメンテナンスに限定されます。 ELS-2ではセキュリティパッチの提供もされなくなります。 ELS-1、ELS-2でもテクニカルサポート、ナレッジベースの利用等は引き続き行うことができます。 ただし、これらのサポートを受けるためにはELSアドオンの購入が必要になります。 セキュリティの観点から、できるだけ早くJBoss EAP 8への移行をご検討いただき、移行期間中のリスクを低減するためにELSのご利用を強くお勧めします。 推奨される次のステップ：JBoss EAP 8への移行 JBoss EAP 8.XはJakarta EE 10に準拠したJavaアプリケーションサーバーです。JBoss EAP 7.XはJava EE 8/Jakarta EE 8に準拠しています。JBoss EAP 7.Xではすでに新規の機能開発は凍結されており、現在はJBoss EAP 8に対して新機能の追加やセキュリティパッチの提供等が提供されています。 今までJavaアプリケーションサーバーは互換性が高く、ほとんどのシステムではアプリケーションの修正なしでもアップデートができていました。しかし、今回は大きく変更され、それなりのマイグレーションコストが必要になります。詳細については次の記事を参照してください。 rheb.hatenablog.com また、このツールは他のサーバー(例:weblogic)からの移行にも対応しています。Jakarta EEへの移行ついでにJBoss EAPに移行したいという場合にも使用する事ができます。 この移行を機会としてJBoss EAP製品の運用自動化をしませんか？ JBoss EAPのバージョンアップを行うついでに運用自動化について検討してみてはいかがでしょうか？JBoss EAPではDomainモードがあり、複数のサーバーのメンテナンスを自動で行うことができますが、JBoss EAP上の操作に限定されてしまいます。本番システムはJBoss EAPだけで構成されているわけではなく、基盤となるOSや、他の多くのソフトウェアで構成されています。OpenShiftをお使いいただけると、OpenShiftは自動化前提の基盤であるため、基板からすべて自動化することができます。OpenShiftは大きすぎてちょっと・・・・という場合はAnsibleをお使いいただくことでOSレイヤーからの自動化が可能になります。OSのパッチあてやJBossから上のミドルウェアのパッチあてなど、すべてを同時に行うことができるようになりますので、運用負荷が軽減できるようになるでしょう。 Jakarta EEへの移行のついでにJBoss EAPへの基盤の統一 Java EEからJakarta EEに対する移行はそれなりの工数がかかります。どうせ工数がかかるならもうなぜJavaアプリケーションサーバーを使うのかに検討を戻して少し手間をかけてみてはいかがでしょうか。 なぜJavaアプリケーションサーバーを使用するのでしょうか？ベンダーロックインが怖いからと答える人が一定数いるかと思います。Java EE/Jakarta EEはオープンな仕様で、多くのベンダーがこれらの仕様に則ってアプリケーションサーバーを開発しています。 そのため、アプリケーションサーバー間の互換性が高く、ベンダーロックインされにくい事が特徴です。 しかしながら、実装差異があり、実際には移行が難しくなる場合もあります。 JBoss EAPは 多くのシステムインテグレーターにて構築実績があります。 一覧にはないですが、親会社のIBMもJBoss EAPの構築ができます。 そのため、JBoss EAPで構築してもらうことで、システムインテグレーターのベンダーロックインを避けながら、移行が難しいという問題も解決することができます。 Red Hat自体が、という場合はRed Hatの製品はすべてOSSなので、OSSの互換品に移行する事が可能です。 そのため、ユーザーはJBoss EAPに統一していただくことで、ベンダーロックインを気にすることなく、システム構築を行うことができるようになります。 また、その場合、システム規模を合計するとそれなりになると思いますが、ベアメタル上でOpenShiftと同時にご購入していただくことで大幅にディスカウントできるプランを準備しています。以前はすべてコンテナ化しなければいけないという制約があり、クラスタリング機能を単体で持っているJBoss EAPと組み合わせるメリットは使い始める敷居に比べて微妙なラインだったのですが、最近はOpenShift Virtualizationもあり、使い始めるための敷居は大幅に下がっています。制約はありますが、 詳細については最寄りの営業担当までご連絡ください。

　こんにちは、レッドハットでソリューションアーキテクトをしている石川です。米国時間の8月5日にOpenAI社がgpt-ossという オープンモデルをリリース しました。OpenAIにとってChatGPTが公開されて以降では初めてとなるオープンモデルの発表となり、大きな反響を呼んでいます。これらのモデルは自身のローカルPCや、サーバー環境にダウンロードし、実行可能であることから、これまでクラウド上で提供されるAIの利用が難しかった環境でも利用が可能です。 本ブログ記事ではgpt-ossをOpenShift AI上で実行し、その実態を確認してみたいと思います。 公開されたモデルについて 　モデルの詳細についてはOpenAIが ブログを公開 しているため、ここではいくつか気になった部分を取り上げます。 今回公開されたのはgpt-oss-120bとgpt-oss-20bという二つのモデルです。パラメーターサイズはそれぞれ約1170億と210億となっており、用途や利用するGPUのスペックに合わせてモデルを選択することができます。モデルのアーキテクチャとしてはDeepSeekやQwen3などと同様にMixture of Experts（MoE）が採用されており、推論時にアクティブとなるパラメーターは全体の一部のみとなるため、推論を高速に実行できます。 　興味深いのが公開されたモデルがMXFP4という形式で既に量子化済みのモデルであるということです。MXFP4は Open Compute Projectの中で定義されている4bitのデータ形式 です。4bitで表現される数値ブロック32個ごとに、8bitのスケーリングファクターが存在することで、量子化前の数値との誤差を低減しています。これによりGPUにモデルをロードする際に必要なVRAM容量を抑えつつ、モデルのデグレードを防いでいます。 　今回公開されたモデルにはApache 2.0ライセンスが適用されています。モデルのトレーニング時のコードや、学習の段階で利用したデータについての情報は公開されていないことから、open source initiatveが公開する Open Source AIの定義 には合致していませんが、オープンウェイトモデルとして利用の自由度は高く、 ファインチューニングを行う方法 なども公開されています。 実行環境の準備 OpenShiftクラスタの準備 　gpt-ossを実行する環境として、AWS上にROSA HCPクラスタを構築し、必要なOperatorのインストールを行います。クラスタの構築方法に関しては本記事の中では紹介しないため、 公式ドキュメント や、 こちらのブログ記事 などを参照ください。 　ROSAクラスタが構築できたら、MachinePoolとしてg6e.12xlargeインスタンスを追加します。このインスタンスタイプにはNVIDIA L40S GPUが4枚搭載されており、今回ホストするgpt-oss-120bに対して十分なVRAM容量を確保できます。 # MachinePoolの追加 $ rosa create machinepool --cluster={クラスタ名} --name=gpu --replicas=1 --instance-type=g6e.12xlarge 　なお東京リージョンにおいて、このインスタンスのオンデマンド料金は$15.21742/hourとなるため、利用時のコストには注意してください。 Operatorのインストール 　OpenShiftクラスタでLLMを実行するために必要な以下のOperatorをインストールします。 　(1) Node Feature Discovery Operator 　(2) NVIDIA GPU Operator 　(3) OpenShift AI Operator 　(1)(2)をOpenShiftコンソールのOperatorHubからインストールし、設定します。これらのOperatorの設定方法について、 以前のブログに記載 しているためこちらを参照してください。 　(3)のOpenShift AI Operatorについて、以前は推論時のためのコンポーネントであるKServeを利用するため、Service Mesh Operatorや、Serverless Operatorのインストールが必須となっていました。しかし、現行のOpenShift AI v2.22では、これらを利用しないKServeのStandardモードがサポートされ、追加のOperatorをインストールすることなく、LLMの推論が実行できるようになっています。（Service Mesh、Serverlessを利用するデプロイパターンは、Advancedモードとして継続してサポート。） docs.redhat.com 　本記事ではStandardモードでのデプロイを行うよう、Operatorを設定します。 　OperatorHubで「OpenShift AI」を検索し、インストールします。stableチャネルから、現行の最新バージョンである2.22.1を選択します。その他の設定は全てデフォルトのままとします。 　OpenShift AIではOperatorのインストール時に行う初期設定をDSCInitializationというカスタムリソースで管理しています。デフォルトではServiceMeshを利用するよう設定されるため、以下のコマンドを実行し、ServiceMeshを利用しない設定に変更します。 # DSCInitializationの変更 $ oc patch dscinitialization default-dsci --type='json' --patch '[{"op": "replace", "path": "/spec/serviceMesh/managementState", "value": "Removed"}]' 　続いてOpenShift AIのDataSciencrClusterカスタムリソースを作成します。以下の通り設定を行います。 apiVersion: datasciencecluster.opendatahub.io/v1 kind: DataScienceCluster metadata: name: default-dsc labels: app.kubernetes.io/created-by: rhods-operator app.kubernetes.io/instance: default-dsc app.kubernetes.io/managed-by: kustomize app.kubernetes.io/name: datasciencecluster app.kubernetes.io/part-of: rhods-operator spec: components: codeflare: managementState: Managed kserve: nim: managementState: Managed rawDeploymentServiceConfig: Headed #① serving: ingressGateway: certificate: type: OpenshiftDefaultIngress managementState: Removed #② name: knative-serving managementState: Managed modelregistry: registriesNamespace: rhoai-model-registries managementState: Removed feastoperator: managementState: Removed trustyai: managementState: Managed ray: managementState: Managed kueue: managementState: Managed workbenches: workbenchNamespace: rhods-notebooks managementState: Managed dashboard: managementState: Managed modelmeshserving: managementState: Managed llamastackoperator: managementState: Removed datasciencepipelines: managementState: Managed trainingoperator: managementState: Managed ①: .spec.kserve.rawDeploymentServiceConfigをHeadedに変更。 ②: .spec.kserve.serving.managementStateをRemovedに変更 　これらの設定を行うことで、KServe利用時にServiceMeshやServerlessのカスタムリソースを使わずに、OpenShiftのデフォルトリソースであるRouteとServiceを介して推論エンドポイントを公開できます。 AcceleratorProfileの作成 　OpenShift AIコンソールからGPUを利用するためのリソースとして、AcceleratorProfileを作成します。 $ cat << EOF | oc apply -f - apiVersion: dashboard.opendatahub.io/v1 kind: AcceleratorProfile metadata: name: nvidia-gpu namespace: redhat-ods-applications spec: description: '' displayName: NVIDIA GPU enabled: true identifier: nvidia.com/gpu tolerations: [] EOF モデルの準備とカスタムランタイムの登録 モデルファイルのダウンロード 　OpenShift AIでgpt-ossをデプロイするため、Hugging Faceからモデルファイルをダウンロードします。OpenShift AIの標準的なモデルデプロイでは、オブジェクトストレージにモデルファイルを配置しておき、デプロイするタイミングでファイルを取得するという方法を取ります。 以前のブログ ではこの方法でモデルをデプロイしました。 今回はあらかじめPVにモデルファイルをダウロードし、それをアタッチすることでモデルをデプロイします。こちらの方法ではオブジェクトストレージを使わずにモデルをデプロイできます。 以下のコマンドで利用するプロジェクト、PVCを作成します。 # プロジェクトの作成 $ oc new-project llm-serving --display-name='LLM Serving' $ oc label namespace llm-serving opendatahub.io/dashboard=true # PVCの作成 $ cat << EOF | oc apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: model-store namespace: llm-serving spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 200Gi EOF 　Hugging Faceの OpenAIのリポジトリ からモデルをダウンロードするためのPodを作成し、PVCをアタッチします。ここで利用するコンテナイメージには、huggingface_hubライブラリをあらかじめインストールしており、そちらを使ってモデルファイルをPVにダウンロードします。環境変数として設定しているHF_REPO_IDの値を変えることで、別のリポジトリからモデルをダウンロードすることも可能です。 # リポジトリの指定 $ export HF_REPO_ID=openai/gpt-oss-120b # モデルファイルのダウンロード $ cat << EOF | oc create -f - apiVersion: v1 kind: Pod metadata: generateName: hf-download-model- labels: name: hf-download-model spec: volumes: - name: model-store persistentVolumeClaim: claimName: model-store restartPolicy: Never initContainers: - name: fix-volume-permissions image: quay.io/quay/busybox:latest command: ["sh", "-c"] args: ["mkdir -p /mnt/models/$HF_REPO_ID && chmod -R 777 /mnt/models"] volumeMounts: - mountPath: "/mnt/models/" name: model-store containers: - name: download-model imagePullPolicy: IfNotPresent image: quay.io/jishikaw/huggingface-hub:latest command: ["sh", "-c"] args: ["hf download --local-dir=/mnt/models/$HF_REPO_ID --exclude=/original/ $HF_REPO_ID"] volumeMounts: - mountPath: "/mnt/models/" name: model-store EOF カスタムランタイムの登録 　この記事を書いている2025年8月13日時点では、OpenShift AIにデフォルトで包含されているvLLMのバージョンがgpt-ossに対応していません。そのためDockerHubで提供されるOSS版の最新イメージをカスタムランタイムとして登録します。この手順は今後のOpenShift AIのアップデートでvLLMのバージョンが上がり、gpt-ossに正式に対応すれば不要となります。 　OpenShift AIコンソールを開き、Settings -> Serving runtimesから、新しいカスタムランタイムを登録します。 　以下の通り設定してください。 ・Select the model serving platforms this runtime supports: Single-model serving platform ・Select API protocol this runtime supports: REST 　 apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: annotations: opendatahub.io/recommended-accelerators: '["nvidia.com/gpu"]' opendatahub.io/runtime-version: v0.10.2.dev2 openshift.io/display-name: Latest OSS vLLM opendatahub.io/apiProtocol: REST labels: opendatahub.io/dashboard: "true" name: vllm-cuda-runtime-copy spec: annotations: prometheus.io/path: /metrics prometheus.io/port: "8080" containers: - args: - --port=8080 - --model=/mnt/models - --served-model-name={{.Name}} command: - vllm - serve env: - name: VLLM_ATTENTION_BACKEND value: TRITON_ATTN_VLLM_V1 - name: HOME value: /tmp/vllm - name: HF_HOME value: /tmp/hf_home image: vllm/vllm-openai:gptoss name: kserve-container ports: - containerPort: 8080 protocol: TCP multiModel: false supportedModelFormats: - autoSelect: true name: vLLM モデルのデプロイ 　OpenShift AIコンソールのData science projectsから、先ほど作成したLLM Servingプロジェクトを開きます。Modelsタブを開き、Single model servingを選択してください。Deploy modelから以下の通り設定を行います。 ・Model deployment name: gpt-oss-120b ・Serving runtime: Latest OSS vLLM ・Number of model server replicas to deploy: 1 ・Model server size: CUSTOM 　・CPUs requested: 1 　・CPU limit: 6 　・Memory requested: 1 　・Memory limit: 30 ・Accelerator: NVIDIA GPU 　・Number of accelerators: 4 ・Model route: チェック入れる ・Token authentication: チェック不要 ・Connection type: URI -v1 ・Connection name: gpt-oss-120b ・URI: pvc://model-store/openai/gpt-oss-120b ・Additional serving runtime arguments: 　・--tensor-parallel-size=4 　デプロイ状況については以下のコマンドでログを確認できます。 # デプロイログ確認 $ oc logs -f deployment/gpt-oss-120b-predictor 　 INFO: Application startup complete. というログが確認できれば、起動は完了です。OpenShift AIコンソールからAPIアクセスのためのエンドポイントを確認できます。 モデルの実行とベンチマーキング 　デプロイしたモデルを Open WebUI を使って呼び出します。OpenShiftへのOpen WebUIのデプロイ方法、設定方法については 以前のブログ の"モデルの実行"セクションを参照してください。 　チャットを実施してみたところ、日本語でのやり取りに関しても問題なく実行できます。 　デプロイしたモデルに対し、 GuideLLM を利用してパフォーマンスのベンチマークを実行します。GuideLLMはvLLMプロジェクトの中で開発されている、モデルのベンチマークツールです。OpenAI互換のAPIを提供する推論エンジンであればvLLM以外でも利用することができます。 　Pythonの実行環境に以下のコマンドでツールをインストールし、実行します。 # ツールのインストール $ pip install guidellm # ベンチマークの実行 $ guidellm benchmark \ --target "https://gpt-oss-120b-llm-serving.apps.rosa.mycluster3.uwl9.p3.openshiftapps.com" \ --processor openai/gpt-oss-120b \ --rate-type concurrent \ --rate 200 \ --max-seconds 60 \ --data "prompt_tokens=512,output_tokens=256" 　 --target で指定するAPIのエンドポイントは、自身の環境に合わせ設定してください。この設定では同時接続数を200とし、入力トークンが512、出力トークンが256となるリクエストを60秒間でどれだけ処理できるか計測します。結果は以下の通りです。 　Out Tok/secは一秒間あたりの平均出力トークン数、Tot Tok/secは一秒間あたりの平均入出力トークン数を表します。それぞれ1820.0、9094.1という結果となりました。 　TTFT(ms)は最初のトークン出力までの時間、ITL(ms)は最初のトークンを除いた平均トークン出力時間を表します。TTFTやITLが遅延すると、チャットなどのアプリを利用する際にユーザー体験が低下します。今回の結果では、TTFT、ITL共に99パーセンタイルでの結果が1秒未満であるため、大きな遅延は発生していないと見ることができます。 　トークン入出力のベンチマーク結果と、利用しているAWSのGPUインスタンス料金から1Mトークンあたりの費用を計算することができます。 出力トークン: (1000000 / (1820 x 3600) ) * 15.21742 ≒ 2.32 入力トークン: (1000000 / ( (9094.1 - 1820) * 3600) ) * 15.21742 ≒ 0.58 　計算の結果、1Mあたりの出力コストは$2.32、入力コストが$0.58となりました。この値は常に十分なトークン入出力が発生することを前提としているため、単純な比較はできませんが、gpt-oss-120bと同等のモデルであるgpt4o-miniをクラウドで利用する際の1Mトークンあたりのコストが、出力$4.40、入力$1.10であることを考えると、悪くない結果だと言えるのではないでしょうか。 まとめ 　本記事ではgpt-ossをOpenShift AI上でホストし、モデルのベンチマークを実行しました。これだけの性能のモデルが公開され、誰でも自由に使うことができるということに対して改めて大きな驚きを覚えます。今後も引き続きLLMの動向や、関連するオープンソースの動向をウォッチし、情報発信をしていきたいと思います。