本記事では、Azure CTO Mark Russinovich 氏による人気セッション 「Cloud Native Innovations with Mark Russinovich（BRK431）」 を聴講した内容をまとめています。
本セッションの聴講はこちらから
Microsoft Igniteとは？
Microsoft Igniteは、Microsoftが毎年開催しているクラウド・AIに関する開発者向けの技術カンファレンスです。
2025年度は11/18~11/21の4日間にわたり、サンフランシスコで開催されました。
Mark Russinovich氏について
Microsoft Azure Blog によると、Mark Russinovich 氏は Microsoft Azure の
- CTO（Chief Technology Officer）：最高技術責任者
- Deputy CISO（Chief Information Security Officer）：副最高情報セキュリティ責任者
- Technical Fellow：高度な専門知識を持つ技術者
を務めています。
コンピュータ工学の博士号を取得しており、Microsoft Ignite、Microsoft Build、RSA Conference などのイベントで大人気のスピーカーです！
また、Windows Internals シリーズや Sysinternals Tools のトラブルシューティング本などの技術書に加え、『Zero Day』『Trojan Horse』『Rogue Code』といった サイバーセキュリティを題材にしたフィクション小説の著者としても知られています。
Mark Russinovich 氏のポストはこちらからご覧いただけます。
本セッションのまとめ（結論）
大きく以下の3つのテーマで構成
- サーバーレスコンテナ：ACI（Azure Container Instances）の進化
- コンテナセキュリティ：OS Guard / 機密コンテナ / 高速パッチの適用
- インキュベーションOSS：発展途上のOSSとして Radiusや Drasi の紹介
また、講演の最後には、
「本セッションで紹介された技術はすべてオープンソースであり、クラウドネイティブ発展のために是非使ってコントリビュートしてほしい」
と、強いメッセージが添えられました。
サーバーレスコンテナ：ACIの進化
1つ目の大きなテーマとして、サーバーレスコンテナに関する話題が取り上げられました。Azureが重視してきたサーバーレス化の取り組みと、その中心となるサービスであるACIの進化した点、そして今後提供予定の機能について紹介されました。
コンテナ化からサーバーレスへ
Azureはこれまで一貫してサーバーレスを重視してきたと強調します。
アプリケーションの現代化（モダナイゼーション）が3段階で示されました。
- コンテナ化 - Refactor：大規模な修正は不要
- マイクロサービス化 - Rearchitect：全体のアーキテクチャの再設計が必要
- サーバーレス化 - Rebuild / New：再構築や新しく構築する必要
Azureは、このステップを前提にサービス設計をしています。
引用元：Cloud Native Innovations with Mark Russinovich（BRK431） スライドより
サーバーレスコンテナの元祖はAzure
サーバーレスでコンテナを動かせるサービスとしてACIがあります。
ACIが世界初のサーバーレスコンテナサービスであることを強調していました。
従来、コンテナ実行のためにはクラスタの構築やノード管理が必要ですが、
ACIではコンテナイメージだけを用意すればすぐに動きます。
このコンセプトはAzureが最初に打ち出したものです。
その後に AWS Fargate や Google Cloud Run が登場しました。
Direct Virtualization による高速化と効率化
従来のACIは、VMの中にハイパーバイザーを立てて、その上でコンテナを隔離する構成でした。この構成は、安全性が確保できる一方で、二重の仮想化によりオーバーヘッドが発生するという問題があります。
Direct Virtualizationの導入により、Azureのハイパーバイザー上に直接分離コンテナを作れるようになり、「起動時間の短縮」「CPU・メモリ・デバイスへのアクセス効率が向上」「セキュリティ境界のシンプル化」などが実現しました。
ACI従来の仮想化とDirect virtualizationの比較の図
引用元：Cloud Native Innovations with Mark Russinovich（BRK431） スライドより
Ngroupsの導入：複数コンテナを"群"として扱う
ACIはもともと1つのコンテナを1つのコンテナインスタンスとして扱うのが基本でしたが、
Ngroupsの導入でコンテナ群の一括管理が可能になりました。
- 同じイメージで複数インスタンスをまとめて作成
- スケールアウト/スケールインの管理（コンテナ数の管理）
- ローリングアップデート（コンテナをまとめて更新する）
などがNgroupsの導入で可能になりました。
Virtual Node：AKSとACIの連携（サーバーフル × サーバーレス）
Azureには、AKS（Azure Kubernetes Service）とACIを連携させる仕組みとして、Virtual Node / Virtual Node 2が提供されています。
Virtual Nodeを利用すると、ACIをKubernetesのノードとして扱うことができます。つまり、AKSのクラスタ内にサーバーレスで動くノードを追加するイメージです。
さらに、Virtual Node 2 では Kubernetes との統合度が向上し、ほぼネイティブノード（通常のノード）と同等の扱いができるまでに進化しています。
ACI上で動作するAKSのVirtual Nodeのイメージ図
引用元：Cloud Native Innovations with Mark Russinovich（BRK431） スライドより
Standby Pools / オーバーサブスクリプション / Stretchable Containers
さらに、ACIを大きく進化させる３つの要素として、今後提供予定の新サービスも含めた以下の３点が紹介されました。
① Standby Pools：あらかじめ起動済みのコンテナを待機
Standby Poolsは、あらかじめコンテナを起動して待機させておき、必要になった瞬間に割り当てるための仕組みです。
スケールアウト時にコンテナの起動を待つ必要がなく、待ち時間がほぼゼロで即時に増やすことができます。
過去のセッションでは「100コンテナを数秒で起動」するデモも実演済みだそうで、爆発的なトラフィックに即応できるため、キャンペーン開始直後やゲームの突発的アクセス、ライブ配信などに有効と考えられます。
② リソース・オーバー・サブスクリプション：CPU / メモリの共有（今後提供予定）
従来のサーバーレスコンテナでは、各コンテナに割り当てたCPUやメモリが固定ですが、リソース・オーバー・サブスクリプションを導入することで、複数のコンテナでCPU / メモリを共有プールとして扱うことが出来ます。
③ Stretchable ACI：動的な垂直スケーリング（今後提供予定）
今後提供予定のサービスとして、Stretchable ACIが紹介されました。
実行中のコンテナに対して、vCPUやメモリの割り当てを増減できる機能です。
引用元：Cloud Native Innovations with Mark Russinovich（BRK431） スライドより
通常、コンテナは起動時にスペックを決めたら途中で変更が出来ませんが、
デモでは実行中にスケールを動的に変更する様子が披露されました。
デモの内容：
- コンテナごとに vCPUとメモリの最小値/最大値を設定
- 稼働中にCPUとメモリを増加
- 処理性能が 2.6k TPS → 7.7k TPS に向上する様子を披露
垂直スケーリングがリアルタイムで実現されており、
クラウド上のサーバーレスコンテナとしては初めてのことだそうです！
コンテナセキュリティ
2つ目のテーマとして、コンテナセキュリティの強化が取り上げられました。具体的には、次の3つの仕組みが紹介されました。
| 仕組み | 目的 |
|---|---|
| OS Guard | ホストOSの改ざんを防ぐ |
| Confidential Containers | コンテナの中身をハードウェアで保護する |
| Project Copacetic | コンテナイメージを超高速でパッチするOSS |
OS Guard
Microsoftで行っていることの１つにLinuxのセキュリティ強化があります。
現在よくあるアプローチとしては、SELinuxなどのセキュリティポリシーを重ねることがありますが、これはあくまでOSの上に制御ルールを追加していくだけなので、ホストOS（Linux）は書き換え可能なままです。
そこで、OS Guardは、DM-Verityによる検証とIPEによる実行制御を組み合わせることで、ホストOSを書き換えられないようにし、改ざんを防ぎます。
引用元：Cloud Native Innovations with Mark Russinovich（BRK431） スライドより
- Device-Mapper-Verity（DM-Verity）
- すべてのブロックをハッシュ化して、ツリー構造にする。
- ブロックチェーンのイメージ。
- Integrity Policy Enforcement（IPE）
- 実行可能なイメージを制御する。
- それ以外をPermission deniedでブロックする。
Confidential Containers（機密コンテナ）
機密コンテナは、ハードウェアによる構成証明が行われた高信頼実行環境（TEE: Trusted Execution Environment）上でコンテナを実行する仕組みです。
デモでは、
- WindowsのConfidential Containerに対してポリシーを設定
- 許可されるコマンド（
cmd /c dir） - 許可されないコマンド（
cmd）
- 許可されるコマンド（
- 許可されたコマンドのみ実行できる
という様子を披露していました。
Project Copacetic（Copa）
Project Copaceticは通称をCopaといい、CNCFのSandbox OSSです。
（OSSについては次の章で記載します。）
コンテナイメージは複数のレイヤー（層）で構成されていますが、通常、1つのレイヤーで脆弱性が発見された場合、そのレイヤーに依存する全てのイメージを再構築する必要があります。
大規模環境では、数日～数週間かかることも。
そこでホットパッチのようにパッチ層を追加するというCopaのアプローチが生まれました。
引用元：Cloud Native Innovations with Mark Russinovich（BRK431） スライドより
ホットパッチとは？
ソフトウェアを停止せずに不具合や脆弱性を修正する仕組みのこと。
コンテナイメージを全て再構築するのではなく、必要な修正部分だけを追加レイヤー（パッチ層）として上に重ねるということです。
これにより、数時間で修正を適用できるようになりました。
インキュベーションOSS
3つ目のテーマとして、社内のインキュベーションチームが育てているプロジェクトについて紹介がありました。特に、CNCF（Cloud Native Computing Foundation）に登録されているオープンソースプロジェクトのうち、Sandbox OSSから代表して Radius と Drasi の2つがピックアップされました。
Sandbox OSSとは？
CNCFが定めている成熟度のうち、最も初期段階で発展途上のプロジェクトのこと。
成熟度には、Sandbox → Incubation → Graduated の3段階がある。
Radius：アプリとインフラを分離する OSS コントロールプレーン
本OSSは認証プロトコルのRADIUSとは無関係です。
Radius は、アプリケーションの定義と、それをどのクラウドや基盤にどのようにデプロイするかというインフラ定義を分離して管理できる OSS のユニバーサルコントロールプレーンです。
ユニバーサルコントロールプレーンとは？
クラウドや基盤（Azure / AWS / Kubernetes / オンプレミス）に依存せず、アプリを一元的に管理・デプロイできる制御層のこと。
公式ページはこちら
アプリ側は Radiusタイプ として、データベースなどのアプリを構成する要素を宣言します。
インフラ側は レシピ として、
- どの基盤に配置するか（Azure / AWS / Kubernetes / オンプレミス など）
- どの設定で配置するか
を記述します。
これにより、アプリの定義を変えずにレシピを切り替えるだけで異なる環境でも同じアプリのデプロイが可能になります。
デモの内容：チャットボットアプリを、
- Kubernetes版とACI版へ切り替えてデプロイする様子
- 開発環境（Dev）と本番環境（Prod）でセキュリティ設定などを自動反映する様子
が披露されました。
Drasi（ドラシ）：リアルタイム監視＋イベント駆動の基盤
Drasiは、データの変化をリアルタイムで監視し、条件に一致したときに任意の処理（Reaction）を自動実行できるOSSです。
ここでいうデータの変化とは、データベースの追加・更新・削除などの状態変化を指します。
例えば、後述する「製品の評価システム」のデモにおいては、
- 新しいレビューが登録される
- 評価スコアの平均値が変わる
- 一定時間イベントが起こらない
などが、データの変化にあたります。
このような動的なデータを前提としたシステム向けにDrasiは設計されています。
公式ページはこちら
Drasi はアプローチを以下の3つのみに単純化
引用元：Cloud Native Innovations with Mark Russinovich（BRK431） スライドより
- Source：データの変更を取り込む
- Continuous Query：継続クエリ（常にデータを監視）
- Reaction：イベント駆動の動作
Continuous Query（継続クエリ）とは？
通常のクエリは1度だけ実行されるのに対し、継続クエリはデータの変化を監視し続けながら条件成立を検知するために継続的に実行されます。
デモの内容：製品（ノートパソコン）に対する評価システム
常に最新状態のレビューが反映され続け、
「どのノートパソコンが一番評価が高い？」
「最新化されたデータに基づいた回答が返ってくる」
という様子が披露されました。
もう少しデモの詳細をお話しすると、
- Sourceとして、2つのデータベースを取り込みます。
- PostgreSQL：ノートパソコン一覧
- MySQL：ユーザーの評価、コメント
- 継続クエリとして、2つのデータベースから各ノートパソコンとその最新レビュー群をグラフとして継続的に集約します。
- Reactionとして、条件に一致したレビュー情報をEmbeddingし、Qdrantに自動反映します。（AIが読みやすい形に変換し、ベクターストアに格納します。）
以上の3つのアプローチにより、新しいレビューが入った瞬間から質問への回答内容が自動的に最新化されていました。
まとめ
今回紹介されたのは、以下の3点でした。
- サーバーレスコンテナ（ACI）の進化
- コンテナセキュリティの強化
- インキュベーションOSSとして Radius と Drasi の紹介
そして、全体を通じて改めて強調されたのは、本セッションで紹介された技術はすべてオープンソースであるという点です。
And so that's kind of in a nutshell what we're doing with cloud-native incubation is open.
So with that, I want to thank you very much, hope you've had a great session, saw some stuff, and encourage you to come and contribute to these projects.
オープンであることこそがクラウドネイティブを発展させる
ぜひこれらのプロジェクトに参加し、コントリビュートしてほしい
と強いメッセージで締めくくられました。