Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Radiusの生まれた背景

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

… のはずだった

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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 ... ... ... だけでは、クラウドネイ ティブアプリケーションは 完結しない ここは標準化できた

Slide 8

Slide 8 text

誰が書くか? 誰がデプロイするか? 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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Radiusのコンセプト

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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、コンテナでの動作がサポート されているソフトウェアなど)

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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… • アプリケーションの構成要素を 標準化/抽象化し、その実体 を別に定義 • 実体は環境に応じて選択、 切り替え可能 • 実体(リソース/インフラ)のプロ ビジョニング/構成管理は実 績あるツールを活用

Slide 21

Slide 21 text

Radiusの実装

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

現在サポートされるリソースタイプ 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”に紐づける

Slide 30

Slide 30 text

組み込みリソース(レシピ作成/登録不要) • 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

Slide 31

Slide 31 text

テンプレート例 – 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を作成

Slide 32

Slide 32 text

テンプレート例 – 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ブロックで接続元が必要 とする接続情報などを返す

Slide 33

Slide 33 text

テンプレート例 – 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を作成

Slide 34

Slide 34 text

テンプレート例 – 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を作成

Slide 35

Slide 35 text

テンプレート、レシピ、リソースタイプ、環境の紐づけ $ 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 リソースタイプを指定し、テンプレートをレシ ピに登録 レシピは複数のリソースタイプの集合体 レシピは環境別に作れる

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

アプリケーション定義例 (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

Slide 39

Slide 39 text

アプリケーション定義 (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リソースタイプで 動かすと宣言

Slide 40

Slide 40 text

接続に必要な情報を自動で取得 $ 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)

Slide 41

Slide 41 text

アプリケーションの構成要素や接続(依存関係)を表示 $ 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]

Slide 42

Slide 42 text

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環境へのデプロイは (注)これは容易さを表現するための例。実際には、本番環境へのデプロイはアプリケーション開発者の端末から行わ ず、アプリケーション定義をソースコードリポジトリで管理し、厳密に管理された環境、パイプラインから行うことを推奨

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

FAQ、事例、考慮点

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

まとめ

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

github.com/radius-project radapp.io

Slide 53

Slide 53 text

Thank you