Radius概要 真壁 徹 シニアクラウドソリューションアーキテクト 日本マイクロソフト株式会社

Agenda  生まれた背景  コンセプト  実装

Radiusの生まれた背景

On-premises オープンソースコミュニティによる クラウドネイティブアプリケーション向け プラットフォームの標準化 many others

… のはずだった

よくあるお悩み • Kubernetesそのものが難しい • 新しいコンセプトで生まれたプラットフォームを使いこなすには、相応の学習コストがかかる • 向き合っていれば、おそらく時間が解決する (ノウハウの蓄積や流通、サービスや製品の拡充、改善など) • Kubernetesだけでは完結しない • ネットワークや認証など、各クラウドやオンプレ固有の制約がある • データストアやメッセージングは、Kubernetes外で各クラウドやオンプレの特徴を活かしたものを使いたい • 複数の環境を使う場合、各クラウドやオンプレの違いを吸収する必要がある • マルチクラウドでなくても、開発/本番環境の違いは課題 • アプリケーション開発者とプラットフォーム技術者の役割分担が難しい • アプリケーションとプラットフォームの境界が曖昧 • 「Kubernetesのマニフェストや周辺リソースのIaCコードは誰が書く?」 • 「誰がデプロイする?」 • 一般的なアプリケーション開発者には負担が大きい印象

PowerShell Bash GitHub Actions Pods Secrets Volumes Services Dockerfile Base image Code Ports Entrypoint Registries Charts Releases Parameters ... ... ... On-premises Bicep Terraform AKS Blob storage Event Hubs CosmosDB EKS S3 SQS DynamoDB Machines Disk Kafka MongoDB ... ... ... だけでは、クラウドネイ ティブアプリケーションは 完結しない ここは標準化できた

誰が書くか? 誰がデプロイするか? apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" volumeMounts: - name: ephemeral mountPath: "/tmp" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: requests: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" volumeMounts: - name: ephemeral mountPath: "/tmp" volumes: - name: ephemeral emptyDir: sizeLimit: 500Mi resource "azurerm_virtual_network" "example" { name = "example" location = azurerm_resource_group.example.location resource_group_name = azurerm_resource_group.example.name address_space = ["10.0.0.0/16"] } resource "azurerm_subnet" "example" { name = "example" resource_group_name = azurerm_resource_group.example.name virtual_network_name = azurerm_virtual_network.example.name address_prefixes = ["10.0.2.0/24"] } resource "azurerm_mssql_managed_instance" "example" { name = "managedsqlinstance" resource_group_name = azurerm_resource_group.example.name location = azurerm_resource_group.example.location license_type = "BasePrice" sku_name = "GP_Gen5" storage_size_in_gb = 32 subnet_id = azurerm_subnet.example.id vcores = 4 administrator_login = "msadministrator" administrator_login_password = "thisIsDog11" } Kubernetes Manifest Terraform HCL

それぞれの悩みとすれ違い アプリケーション開発者 プラットフォーム技術者 プラットフォーム関連の設定やコードを理解 するのが難しく、専門家にお任せしたい パラメータシートの標準化、受け渡し、Q&A、 コードへの変換に忙殺される デプロイ権限がもらえないので作業を依頼 するが、時間がかかる デプロイ依頼がたまっているので待ってほし い ルールやポリシーを周知してほしい(エラーが 出てはじめて気づくのは勘弁してほしい) 事故や浪費がないよう、ルールやポリシーに したがってもらいたい デプロイや運用に必要な最小権限を付与 するので教えてほしい まず触らせてもらえないので最小権限なん てわからない 開発と本番が違いすぎるので、本番同様 の開発環境が欲しい。できれば1人に1つ ちょっと難しいですね

クラウドネイティブアプリケーションに関わる技術者の 悩みを解決する 新たなプロジェクト

MI SSI ON 業界共通、インパクトある課題をオープンソース コミュニティに提起し、ともに解決する Azure CTO Officeを中心とする活動 GRADUATED SANDBOX INCUBATING Azure Incubations Aug 2023 Nov 2023 Sep 2023 SANDBOX (SUBMITTED) Oct 2023

Cloud-native applications containing Any cloud or edge infrastructure Application Graph Infrastructure Recipes Cloud Neutral Team Collaboration アプリケーションを構成するリソース のプロビジョニング、構成管理

Radiusのコンセプト

Frontend Container Internet Gateway Application Redis Cache SQL Database Backend Container • アプリケーションレイヤで、構成 要素(リソース)と、要素間の 依存関係、接続を定義する • 要素の実体を定義する必要 はない • 要素の実体から受け取りたい 情報は、接続を定義すると取 得可能 • 例: データベースの接続文 字列

Frontend Container Internet Gateway Application Redis Cache SQL Database Backend Container Redis Container SQL Container Environment RECIPES COMPUTE CNCF-certified Kubernetes Local development RECIPES

Azure Cache for Redis Azure SQL DB Environment RECIPES COMPUTE Azure Kubernetes Service Frontend Container Internet Gateway Application Redis Cache SQL Database Backend Container RECIPES

AWS MemoryDB AWS RDS Environment RECIPES COMPUTE Elastic Kubernetes Service Frontend Container Internet Gateway Application Redis Cache SQL Database Backend Container RECIPES

Environment On-premises RECIPES Application Redis Dapr Mongo SQL Gateway Connection Container Azure AWS Kubernetes Extensible Secret Store RabbitMQ Any platform Core resources Standard resources Any cloud or on- premises resource 多くの環境で動くソフトウェアを採用す ることで、Radiusの価値を引き出せる (例: マネージドサービスとして提供されて いるOSS、コンテナでの動作がサポート されているソフトウェアなど)

On-premises Radiusを活用した プラットフォームエンジニアリング Applications Environments Recipes アプリケーション開発者はアプリケーショ ンの開発とその定義にフォーカス プラットフォーム技術者はアプリケーション開 発者が求める環境とレシピを提供

Container Azure SQL DB SQL DB AWS RDS SQL Edge Container Services access consistent connection strings and values Infrastructure automatically deployed and configured Recipes Leverage your existing IaC templates Bicep Extensible… • アプリケーションの構成要素を 標準化/抽象化し、その実体 を別に定義 • 実体は環境に応じて選択、 切り替え可能 • 実体(リソース/インフラ)のプロ ビジョニング/構成管理は実 績あるツールを活用

Radiusの実装

Radiusの実体 • Radiusコントロールプレーン(UCP: Universal Control Plane)をKubernetes内に配置 • つまり、Kubernetes環境がすでにあることが前提 • コントロールプレーン操作するrad CLI • アプリケーション定義やレシピのコーディングを支援するVSCode拡張 Overview: Radius installation | Radius Docs (radapp.io) 環境やレシピのメタデータ管 理、リソースの操作を行う

ワークスペースによる環境の切り替え • rad CLIは構成ファイル(config.yaml)にワークスペース情報を保存 • ワークスペースに接続先Kubernetesのコンテキスト、環境を紐づけ • 端末やCI/CDパイプラインから、複数の環境を切り替えて操作可能 Overview: Radius workspaces | Radius Docs (radapp.io) 例: AKSやEKS 例: 端末内のk3d

対応するクラウドプロバイダ Overview: Cloud providers | Radius Docs (radapp.io) • Radius UCPがクラウド固有のリソースを操作 • 現時点ではAzureとAWSに対応 • 他クラウドプロバイダではKubernetes上のコンテナに限って利用可能

サンプルアプリケーション • フロントエンドWebアプリコンテナが、RedisをDBとして使う • Redisの実体は、環境によって異なる • それぞれの環境ごとに、レシピを提供する Tutorial: Deploy Recipes in your Radius Application | Radius Docs (radapp.io)

レシピのコンセプト • 環境に合わせたリソース/インフラのテンプレート(Bicep/Terraform) • アプリケーション開発者が詳細を知らずに済むよう、標準化/抽象化 • アプリケーション開発者はたとえばRedisを「使う」ことに集中できる Overview: Radius Recipes | Radius Docs (radapp.io)

プラットフォーム技術者視点

利用の流れ(プラットフォーム技術者) • レシピのテンプレートを書く • Bicep/Terraform(HCL)形式 • コミュニティレシピを参考に • テンプレートをレジストリに格納する • OCI(Open Container Initiative)準拠レジストリ/Terraformレジストリ • 環境を準備する • Kubernetesクラスタの作成 • 開発環境など、開発者の端末で実行できる環境を選ぶ場合は準備は不要 • Azure/AWSの前提リソース(ネットワークなど)、権限やガードレール • アプリケーション開発者へ利用に必要な情報を伝える • レシピテンプレートや環境、利用方法 • デプロイはアプリケーション開発者にお任せ(もちろん支援はする) • 本番まで任せるのが理想的だが、組織のルールや規制、成熟度によってプラットフォーム技術者が代行する

現在サポートされるリソースタイプ Applications.Datastores/redisCaches Applications.Datastores/mongoDatabases Applications.Datastores/sqlDatabases Applications.Messaging/rabbitmqQueues Applications.Dapr/stateStores Applications.Dapr/pubSubBrokers Applications.Dapr/secretStores Applications.Core/extenders Overview: Radius Recipes | Radius Docs (radapp.io) • アプリケーション開発者は、アプリケーション定義でこのリソースタイプを指定する(標準化/抽象化) • このリソースタイプに、テンプレート、レシピを紐づける • 使いたいリソースが現在サポートされるリソースタイプにない場合、”extenders”に紐づける

組み込みリソース(レシピ作成/登録不要) • Container • Applications.Core/containers • 実体: Kubernetes Deployment/ReplicaSets/Service • Gateway • Applications.Core/gateways • 実体: Kubernetes上のRadius Managed Contour HTTPProxy • Kubernetes Serviceをクラスタ外部に公開する • Radius Secret Store • Applications.Core/secretStores • 実体: Kubernetes Secrets

テンプレート例 – local-dev Redis (1/2) import kubernetes as kubernetes { kubeConfig: '' namespace: context.runtime.kubernetes.namespace } resource redis 'apps/Deployment@v1' = { metadata: { name: 'redis-${uniqueString(context.resource.id)}' } spec: { selector: { matchLabels: { app: 'redis' resource: context.resource.name } } [snip] bicepでKubernetes DeploymentとしてRedisを作成

テンプレート例 – local-dev Redis (2/2) output result object = { resources: [ '/planes/kubernetes/local/namespaces/${svc.metadata.namespace}/providers/core/Service/${svc.metadat a.name}' '/planes/kubernetes/local/namespaces/${redis.metadata.namespace}/providers/apps/Deployment/${redis. metadata.name}' ] values: { host: '${svc.metadata.name}.${svc.metadata.namespace}.svc.cluster.local' port: 6379 } } outputブロックで接続元が必要 とする接続情報などを返す

テンプレート例 – Azure Redis Cache resource azureCache 'Microsoft.Cache/redis@2022-06-01' = { name: 'cache-${uniqueString(context.resource.id, resourceGroup().id)}' location: location properties: { sku: { capacity: skuCapacity family: skuFamily name: skuName } } } [snip] bicepでAzure Redis Cacheを作成

テンプレート例 – Amazon MemoryDB for Redis resource memoryDBCluster 'AWS.MemoryDB/Cluster@default' = { alias: memoryDBClusterName properties: { ClusterName: memoryDBClusterName NodeType: nodeType ACLName: aclName SecurityGroupIds: [eksCluster.properties.ClusterSecurityGroupId] SubnetGroupName: subnetGroup.name NumReplicasPerShard: numReplicasPerShard [snip] bicepでAmazon MemoryDB for Redisを作成

テンプレート、レシピ、リソースタイプ、環境の紐づけ $ rad bicep publish --file azureredis.bicep --target br:ghcr.io/USERNAME/recipes/azureredis:1.1.0 $ rad recipe register myrecipe --environment myenv --resource-type Applications.Datastores/redisCaches --template-kind bicep --template-path ghcr.io/USERNAME/recipes/azureredis:1.1.0 レジストリにテンプレートをpublish リソースタイプを指定し、テンプレートをレシ ピに登録 レシピは複数のリソースタイプの集合体 レシピは環境別に作れる

アプリケーション開発者視点

利用の流れ(アプリケーション開発者) • アプリケーションを書く • アプリケーションのコンテナイメージを作成し、レジストリに格納する • アプリケーション定義を書く • Bicep形式(将来Terraformもサポート予定) • 環境に合わせたレシピを指定し、デプロイする • たとえば • 開発環境では、コンテナ(local-dev)のRedisを • 本番環境では、Azure Redis Cacheを • 各環境の’default’レシピを使う場合、明示は不要 • 使いたいレシピ/テンプレートが無い場合、プラットフォーム技術者にリクエストす る

アプリケーション定義例 (1/2) import radius as radius param environment string param application string resource frontend 'Applications.Core/containers@2023-10-01-preview' = { name: 'frontend' properties: { application: application container: { image: 'ghcr.io/radius-project/samples/demo:latest' } connections: { redis: { source: db.id } } } } フロントエンドアプリはコンテナリ ソースタイプで動かすと宣言 コンテナイメージ 接続先のRedis

アプリケーション定義 (2/2) resource db 'Applications.Datastores/redisCaches@2023-10-01-preview' = { name: 'db' properties: { environment: environment application: application // recipe is not specified, so it uses 'default' if present } } 利用するレシピを明示できるが、設定しない場合に は環境内の’default’レシピが選択される つまり、アプリケーション定義を書き換えることなく、 コンテナ Redis、Azure Redis Cache、 AWS MemoryDBが環境に合わせて自動選択される DBはRedisリソースタイプで 動かすと宣言

接続に必要な情報を自動で取得 $ kubectl get po demo-aaabbbccc -o yaml [snip] spec: containers: - env: - name: CONNECTION_REDIS_CONNECTIONSTRING valueFrom: secretKeyRef: key: CONNECTION_REDIS_CONNECTIONSTRING name: demo - name: CONNECTION_REDIS_HOST valueFrom: secretKeyRef: key: CONNECTION_REDIS_HOST name: demo [snip] フロントエンドアプリへ、Redisの接続 情報が環境変数として渡される(レシ ピテンプレートのoutputブロックで定 義した値) Redis cache | Radius Docs (radapp.io)

アプリケーションの構成要素や接続(依存関係)を表示 $ rad application connections Displaying application: radius-eval Name: demo (Applications.Core/containers) Connections: demo -> db (Applications.Datastores/redisCaches) Resources: demo (kubernetes: apps/Deployment) demo (kubernetes: core/Secret) demo (kubernetes: core/Service) demo (kubernetes: core/ServiceAccount) demo (kubernetes: rbac.authorization.k8s.io/Role) demo (kubernetes: rbac.authorization.k8s.io/RoleBinding) Name: db (Applications.Datastores/redisCaches) Connections: demo (Applications.Core/containers) -> db [snip]

Radiusで標準化/抽象化された世界でのデプロイ $ rad workspace switch dev Default environment is already set to dev $ rad deploy app.bicep $ rad workspace switch prod Switching default workspace from dev to prod $ rad deploy app.bicep 開発時は端末のdev環境で 本番prod環境へのデプロイは (注)これは容易さを表現するための例。実際には、本番環境へのデプロイはアプリケーション開発者の端末から行わ ず、アプリケーション定義をソースコードリポジトリで管理し、厳密に管理された環境、パイプラインから行うことを推奨

より複雑なサンプル Tutorial: eShop on containers | Radius Docs (radapp.io)

FAQ、事例、考慮点

FAQ Q: アプリケーションは、どのようなプログラミング言語をサポートしますか? A: 特に限定しません。Kubernetesで動くコンテナアプリケーションを作ってください。 ただし、アプリケーションが透過にリソースに接続できるよう、環境の違いを吸収す る仕組みは必要です。(例: 環境変数から動的に接続先を設定)

FAQ Q: 同様の目的を実現可能なツールがほかにもある気がします。違いは? A: いくつかのツールとの比較を公開しています。 Frequently asked questions | Radius Docs (radapp.io) 「アプリケーション開発者とプラットフォーム技術者の役割、関心事の分離」 「分離を前提としたコラボレーション」 「実績あるツールの活用」 「要素間の依存管理と接続の自動化」 「環境の違いを吸収」 これらの両立がRadiusのユニークさと考えます。

事例: Millennium bcp (ポルトガルの大手銀行) Case Study: How Millennium bcp leverages Radius | Radius Blog (radapp.io) • セルフサービスの実現、デプロイの準備にかかる時間の短縮など成果を得た。しかし課題が残る • Backstageで環境構築と設定ファイル群を生成するプラグイン作ったが、その開発維持の負担が大きい • KubeVelaはアプリケーションライフサイクル全体を対象にするため、インフラ部分の役割分担が難しい • 認知負荷を下げるためにツールを導入したが、ツールが多すぎてかえって認知負荷が高まった Before Radius

事例: Millennium bcp (ポルトガルの大手銀行) Case Study: How Millennium bcp leverages Radius | Radius Blog (radapp.io) With Radius (now) • ツールを減らし、よりシンプルに • アプリケーション開発者とプラットフォーム技術者が、それぞれの役割により集中できるように • 既存Terraform、Crossplane資産の活用 • 現在サポートされていないリソースはextenderで対応している。メンテナ/コミュニティとGitOpsに挑戦中

考慮点 • 今後、仕様や挙動が大きく変わる可能性がある • まだ’early release’段階 • コミュニティプロジェクトの成熟は時間がかかる • 多様なフィードバックで揉まれる • 目的がシンプルで効果が明確なKEDAでも、Graduatedまでに3年を要した • データストアのリソースタイプにアレがない • 本格化に向けて大きなテーマ • 現時点では将来に向けての試用、コンセプトの学習用途として推奨 • Radiusのコンセプト、特にアプリケーション開発者とプラットフォーム技術者の役割分担、コラボレーションに ついて、試すことで学びがあるはず • もちろん商用採用を目指したご利用も歓迎

まとめ

まとめ • Radiusは、クラウドネイティブアプリケーションに関わる技術者の悩みを解決す るべく生まれたオープンソースソフトウェア • アプリケーションを構成するリソースのプロビジョニング、構成管理が主な機能 • アプリケーション開発者とプラットフォーム技術者の役割と関心事の分離、コラ ボレーションを特に意識 • 実績あるツールを活用し、車輪を再発明しない • 環境の違いを吸収する、標準化/抽象化のしくみを持つ • まだ公開直後です フィードバックを楽しみにしております！

github.com/radius-project radapp.io

Thank you