Upgrade to Pro — share decks privately, control downloads, hide ads and more …

IaC(Infrastructure as Code)をフル活用したアプリ開発の最前線

ks6088ts
February 02, 2025
2

IaC(Infrastructure as Code)をフル活用したアプリ開発の最前線

IaC(Infrastructure as Code)をフル活用したアプリ開発の最前線
https://aka.ms/sukiyanenazure202501

ks6088ts

February 02, 2025
Tweet

Transcript

  1. Shinji Takenaka Experience 2022 - Present: Cloud Solution Architect at

    Microsoft 2021 - 2022: Solutions Architect at SORACOM 2012 - 2021: Software Engineer at Nintendo Skills Cloud Computing : Azure/GitHub/Bicep/Python IoT : AWS/Terraform/Go/TypeScript Software Development : C++/C#/Python Social Website GitHub LinkedIn
  2. 進化する開発:生成AIとIaCが拓く未来!​ タイトル IaC をフル活用したアプリ開発の最前線 日時 2025年 1月31日(金) 14:30-17:00 形式 オフライン

    (日本マイクロソフト株式会社 関西支店) 対象 業務部門 / IT部門 / ノーコード開発・分析にご興味のある方 定員 24名 イベント申し込み締め切り 2025年 1月28日(火)
  3. Agenda 1. IaC とはなにか? 2. IaC が解決する課題 3. Azure での

    IaC の実践 4. Demo: AI Agent のデプロイ 5. 組織での IaC の導入
  4. クラウドインフラ管理手法の変遷 1. 手動操作 (Azure ポータル) 2. スクリプト (SDK, Azure CLI/Powershell)

    3. プロビジョニングツール (ARM Template) 4. プログラミング言語/DSL (Bicep, Terraform) ← IaC に分類されるものはこれ 管理手法の進化を辿りながら仕組みを理解する
  5. 手動操作 ツール Azure ポータル 利点 簡単に操作できる 欠点 繰り返し操作が面倒 人的ミスが発生しやすい 時間がかかる

    例: Azure ポータル 手動操作 > スクリプト > プロビジョニングツール > プログラミング言語/DSL
  6. スクリプト ツール SDK Azure CLI / Powershell 利点 繰り返し操作が可能 操作手順を自動化できる

    バージョン管理が可能 欠点 言語の学習コストがかかる テストが難しい ロールバック、アップデートが難しい 例: Azure CLI 手動操作 > スクリプト > プロビジョニングツール > プログラミング言語/DSL !#/bin/bash # リソースグループを作成する az group create \ --name demoResourceGroup \ --location japanwest
  7. プロビジョニングツール ツール ARM Template 利点 自動化が容易 テンプレートを使ってインフラストラクチャを 定義できる テンプレートを使って再利用が可能 テンプレートを使って環境を再現できる

    欠点 サービスの学習コストがかかる 抽象化がなく、実装詳細の認知コストが高い 例: ARM Template 手動操作 > スクリプト > プロビジョニングツール > プログラミング言語/DSL { "$schema": "https://schema.management.azure.com/schemas/ "contentVersion": "1.0.0.0", "resources": [ { "type": "Microsoft.Resources/deployments", "apiVersion": "2021-04-01", "name": "nestedDeployment", "resourceGroup": "demoResourceGroup", "properties": { "mode": "Incremental", "template": { resource-group-resources } } } ],
  8. プログラミング言語/DSL ツール Bicep Terraform 利点 プログラミング言語の恩恵を受けられる テストが容易 バージョン管理が容易 抽象化が可能 欠点

    記述言語の学習コストがかかる 例: Bicep 手動操作 > スクリプト > プロビジョニングツール > プログラミング言語/DSL targetScope='subscription' param resourceGroupName string param resourceGroupLocation string resource newRG 'Microsoft.Resources/resourceGroups@2024-03 name: resourceGroupName location: resourceGroupLocation }
  9. IaC の基本概念 コードのパラダイム 手続き型 手順をステップバイステップで実行 (手動操作、スクリプト) ロールバックをどう実装するか? 再試行をどう実装するか? 宣言型 望ましい最終状態を記述

    (プロビジョニングツール、プログラミング言語/DSL) 現在の状態との差分を計算して変更を適用 同じコードを何度実行しても同じ結果になる !#/bin/bash az group create \ --name myResourceGroup \ --location japaneast resource "azurerm_resource_group" "rg" { name = "myResourceGroup" location = "japaneast" }
  10. Azure でのリソース管理の全体像 Azure CLI New-AzResourceGroupDeployment PowerShell terraform apply Azure Resource

    Manager az deployment group create Deploy to Azure button Azure Portal ... ARM Template Compile Bicep Terraform (Provider) Authentication Microsoft Entra ID HCL SDK (Go) SDK (Python) SDK (.NET) Azure Resource Manager の呼び出し経路が違うだけでやってることはほどんど同じ
  11. インフラの再現が容易 aka.ms/awesome-azd: Azure Developer CLI で Azure リソースを作成するためのテンプレート 異なる環境に同じインフラストラクチャを容易に再現できる #

    --- # [構築手順の例] # --- REPOSITORY_URL=https://github.com/Azure-Samples/ # カレントディレクトリで azd プロジェクトを初期化 azd init --template $REPOSITORY_URL # リソースのプロビジョニングとアプリのデプロイ azd up # リソースの削除 azd down
  12. IaC を実現するテクノロジー IaC ツール 提供元 対象クラウド アプローチ 記述言語 Bicep Microsoft

    Azure 宣言型 Bicep ARM Template Microsoft Azure 宣言型 JSON Terraform HashiCorp Azure, AWS, GCP, etc 宣言型 HCL Pulumi Pulumi Azure, AWS, GCP, etc 宣言型 TypeScript, Python, Go, … Ansible Red Hat Azure, AWS, GCP, etc 手続き型 YAML
  13. Bicep について Azure リソースの IaC を実現するために Microsoft が開発したドメイン固有言語 (DSL) 簡潔で可読性の高い構文でインフラストラクチャを定義

    すべてのリソースの種類と API バージョンのサポート VS Code の Bicep 拡張機能などのツールサポートが充実 Bicep とは
  14. Bicep の記法 ~ 例: Storage Account の作成 ~ リソースの定義: main.bicep

    パラメーターファイル: main.bicepparam 1 param storageSKU string = 'Standard_LRS' 2 param location string = resourceGroup().location 3 4 @description('ストレージアカウント名に使用するプレフィックス') 5 @minLength(3) 6 @maxLength(11) 7 param storagePrefix string 8 9 var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGr 10 11 resource stg 'Microsoft.Storage/storageAccounts@2023-04-01' = { 12 name: uniqueStorageName 13 location: location 14 sku: { 15 name: storageSKU 16 } 17 kind: 'StorageV2' 18 properties: { 19 supportsHttpsTrafficOnly: true 1 using main.bicep' 2 3 // storageSKU, location は省略可能 4 5 var prefix = 'my' 6 param storagePrefix = '${prefix}storage'
  15. Bicep での開発環境 ツール名 概要 Bicep CLI commands Bicep ファイルをビルド、デプロイするための CLI

    コマンド Bicep language support for Visual Studio Code Visual Studio Code で Bicep ファイルを編集するための拡張機能 Bicep Bicep is a declarative language for describing and deploying Azure resources
  16. Azure CLI を使ったデプロイ 1. Azure アカウントにログイン 2. Bicep で定義されたリソースをデプロイ az

    login --use-device-code # 変数の設定 RESOURCE_GROUP_NAME=rg-sukiyanenazure-iac-20250131 # リソースグループを作成 az group create \ --name $RESOURCE_GROUP_NAME \ --location japaneast # Bicep テンプレートをデプロイ az deployment group create \ --resource-group $RESOURCE_GROUP_NAME \ --template-file main.bicep \ --parameters main.bicepparam
  17. Terraform について 出典: What is Terraform? HashiCorpによって開発されたオープンソースの IaC ツール AWS,

    Azure, GCP などのサービスに対応 ワークフローは、3 つのステージで構成される 1. Write: HCL でインフラストラクチャを記述 2. Plan: リソースの変更をレビュー 3. Apply: リソースの変更を適用
  18. Terraform(HCL) の記法 ~例:Storage Account の作成~ リソースの定義: main.tf パラメーターファイル: variables.tf 12

    name = "${var.name}sa" 13 location = var.location 14 tags = var.tags 15 resource_group_name = var.resource_group_name 1 terraform { 2 required_version = ">= 1.6.0" 3 required_providers { 4 azurerm = { 5 source = "hashicorp/azurerm" 6 version = "~> 4.5.0" 7 } 8 } 9 } 10 11 resource "azurerm_storage_account" "storage_account" { 16 account_tier = "Standard" 17 account_replication_type = "LRS" 18 allow_nested_items_to_be_public = false 19 } 1 variable "name" { 2 description = "リソース名" 3 type = string 4 } 5 6 variable "location" { 7 description = "リソースのリージョン" 8 type = string 9 } 10 11 variable "tags" { 12 description = "リソースのタグ" 13 type = map(any) 14 default = {} 15 } 16 17 variable "resource_group_name" { 18 description = "リソースグループ名" 19 type = string 20 }
  19. Terraform での開発環境 ツール名 概要 Terraform CLI Terraform ファイルをビルド、デプロイするための CLI コマンド

    Terraform Extension for Visual Studio Code Visual Studio Code で Terraform ファイルを編集するための拡 張機能 TFLint Terraform ファイルの静的解析ツール Trivy コンテナイメージの脆弱性スキャンツール
  20. Terraform を使ったデプロイ 1. Azure アカウントにログイン 2. Terraform で定義されたリソースをデプロイ az login

    --use-device-code export ARM_SUBSCRIPTION_ID=<your-subscription-id> # プロジェクトの初期化 terraform init # プランの作成 terraform plan -out=tfplan # リソースのデプロイ terraform apply tfplan
  21. Terraform 固有の特徴 カスタムプロバイダーを開発することで、任意の API に対して Terraform での管理が可能になる カスタムプロバイダーを開発する求人 さくらインターネット >

    ソフトウェア開発エンジニア(クラウドSDK) 実際に作ってみたブログ Terraform provider for SORACOM を作って Azure Functions と連携してみた 出典: Plugin Development
  22. Terraform 固有の特徴 出典: GitHub Actions から OpenID Connect で Azure

    に接続する設定作業を Terraform で自動化する クロスプラットフォーム対応の例: Azure だけでなく、AWS, GCP, GitHub などのサービスに対応
  23. Bicep と Terraform の比較 記法そのものはほとんど変わらず、モジュール化・パラメータ化もほぼ同じ 片方を習得すればもう片方の習得も容易 リソースグループを作成する例 Bicep Terraform resource

    rg 'Microsoft.Resources/resourceGroups@2021-04-01 name: 'myResourceGroup' location: 'japaneast' } resource "azurerm_resource_group" "rg" { name = "myResourceGroup" location = "japaneast" }
  24. Bicep と Terraform の比較 基本は Bicep、クロスプラットフォーム対応が必要な場合は Terraform 選定基準は MS Learn

    > Terraform と Bicep の比較 が参考になる ツール 個人的な選択理由 Bicep デフォルトの選択肢。機能への追従が早い。開発環境が整っている。 Terraform クロスプラットフォームで使いたい場合に選択。周辺ツールが充実している。 ARM Template 基本的には触らない (どうしても直接 ARM Template を触る必要がある場合のみ) 個人的な選択基準
  25. エコシステム タスクランナー アプリケーションのデプロイ、インフラのプロビジョニング、事前/事後処理などの自動化に利用 ツール: シェルスクリプト, Makefile, Azure Developer CLI など

    CI/CD プルリクエストの自動テスト、デプロイの自動化 ツール: GitHub Actions, Azure DevOps Azure Verified Modules (AVM) Azure のベストプラクティスに準拠したモジュール Bicep, Terraform で利用可能
  26. Azure Developer CLI Azure の使用を開始するのにかかる時間を短縮する Azure Developer CLI (azd) azure.yaml

    に定義された手順が実行される。暗黙的なデフォルトの挙動を理解する必要がある Azure/azure-dev でソースは公開されている 出典: Introducing the Azure Developer CLI (azd): A faster way to build apps for the cloud Azure Developer CLI テンプレートの概要
  27. Azure Developer CLI を使ったデプロイ 0. リポジトリのクローン 1. Azure アカウントにログイン 2.

    azd 環境の作成 3. リソースのプロビジョニングとアプリのデプロイ azure.yaml git clone $REPOSITORY_URL azd auth login --use-device-code azd env new azd up name: yourApp-terraform metadata: template: [email protected] services: web: project: ./src/web dist: build language: js host: appservice api: project: ./src/api language: js host: appservice
  28. タスクランナーの選定 サンプルが azd に準拠している場合は Azure Developer CLI を使うと無難 Microsoft が提供するサンプルコードは

    azd に準拠することが多い(例: awesome-azd) 開発チームが使い慣れているツールを使う 宗派が色々あるため、開発チームのスキルセットに合わせる CI のパイプラインなどでも必要になるため、依存関係少なくクイックに動かせるものが好ましい 手持ちのスキルセットとの整合性を考慮
  29. Demo: AI Agent アプリのデプロイ Azure Container Apps に AI Agent

    アプリを Terraform でデプロイする # リポジトリのクローン git clone https://github.com/ks6088ts-labs/basel cd infra/scenarios/workshop_azure_openai # 環境変数の設定 export ARM_SUBSCRIPTION_ID=$(az account show -- # 変数ファイルの作成 cat <<EOF > terraform.tfvars create_container_app = "true" container_app_image = "ks6088ts/workshop-llm-ag container_app_ingress_target_port = "8501" ... EOF # Terraform でデプロイ terraform init terraform apply -auto-approve
  30. 新技術の導入プロセス 導入に必要なタスクを要素分解して小さなステップの連なりに分ける 後ろのステップが実現されなかったとしてもそれぞれ価値を持つように並べる 組織の現在地に合わせてステップを選択する 出典: 詳解 Terraform 第3版 //////////////////////////////////////////////////////////////////////////////////////////////////////////// 例:

    新たに IaC ツールを導入する場合 1. IaC ツールを導入するためのワークショップ・勉強会を実施する (ここで終わってもノウハウは残る) 2. 新規プロジェクトなどで小規模に IaC ツールを活用してみる (ここで終わっても実践した経験が残る) 3. IaC ツールを活用した CI/CD の導入 (ここからは文化として根付かせて維持していく) 新たに導入する場合は 漸進主義 で少しづつ進めることを意識する
  31. 組織での IaC の導入 開発に求められる技術領域が広く、複雑化してきた (CI/CD, IaC, MLOps, DevSecOps, Observability, …)

    開発者の認知負荷を下げつつ幅広い技術を使いこなして生産性を向上させる芸の価値が高まる プラットフォームエンジニアリングという言葉が流行する背景
  32. やることは"関心の分離" 例: Android Platform アプリ開発者は Linux Kernel のことを意識しながらアプリケー ションを書くことはほぼ無いし意識したくもない ひとつ下のレイヤーだけを意識して開発するのがあるべき姿

    隠蔽することで開発者は自分の関心事に集中できるし、プラッ トフォームのメンテナンスは容易になる 関心事を分離して"知らなくていいこと"を隠蔽する
  33. 利用者観点で「知らなくていいこと」を増やす ベストプラクティスを知る Bicep に関するベスト プラクティス に準拠する 利用者が変更しないパラメータを隠蔽する 変数として露出はさせず、モジュール内部で固定する 利用者が変更するパラメータ 「変更したい変数だけ認知して変更できる」、「変更したくない変数は知らなくて良い」状態を作る

    尤もらしい default 値を備えたモジュールを作り溜める 要求に合わない default だけ変更すれば良い モジュール分割単位のちょうど良さは組織やプロジェクトのフェーズによって異なる 定期的な振り返り、ディスカッションが必要 GitHub Discussions などで DR (Decision Record) を残す IaC のモジュール化の判断軸
  34. プラットフォームを維持するための設計 いきなり共通基盤化は難しい 情報が少ない中で必要十分な外部仕様を定義することが難しい どう始めるか? まずは成功した事例(AVM や世間のベストプラクティスなど)をベースラインにする いくつか成功した具体的な事例を積み上げて、共通項を見つけて抽象化すると尚良し プラットフォームの寿命は外部仕様で決まる ユーザーストーリーに基づいて外部仕様を定義する 闇雲に内部仕様(変数、利用リソース、etc)をさらさない

    Assert, Validation はまずは厳しくする (緩めるのは簡単だが、厳しくするのは後方互換性を損なう) 自社にあった外部仕様を漸進的に定義していく モジュール分割の指針、デプロイ対象の環境、デプロイの頻度、などは組織によって異なる 利用者のフィードバックとプラットフォーム開発者の改善のループを高速に回す
  35. プラットフォームを維持するための自動化 Fail Fast するための自動化 Bicep では What-If 操作、Terraform は terraform

    plan を CI に組み込む 特に AI model は更新頻度が高く、プラットフォーマ側の変更により IaC コードが陳腐化しやすい 引数の Validation、静的解析、コードフォーマット、テストを徹底する ヒューマンエラーを排除するための自動化 デプロイが常に一貫性のある環境から行われることを保証する インフラコードをデプロイする権限を CI サーバーに集約する 雑多な作業を排除するための自動化 Dependabot などを使って、依存関係の更新を自動化する 自動化!自動化!自動化!
  36. 参考資料 スライド 俺とAzureとTerraform ~2024新春バージョン~ Azure Developer CLI Deep Dive MicrosoftのPlatform

    Engineeringガイドを読んで実際になにかやってみた コード awesome-azd AI app templates github.com/Azure-Samples github.com/Azure github.com/Microsoft baseline-environment-on-azure-terraform baseline-environment-on-azure-bicep