Azure でのイベントベースのクラウド オートメーションEvent-based cloud automation on Azure

サーバーレス テクノロジを使用して、クラウド上でワークフローや繰り返し実行されるタスクを自動化することで、組織の DevOps チームの生産性を大幅に向上させることができます。Automating workflows and repetitive tasks on the cloud using serverless technologies, can dramatically improve productivity of an organization's DevOps team. サーバーレス モデルは、イベント ドリブン アプローチに適したオートメーション シナリオに最適です。A serverless model is best suited for automation scenarios that fit an event driven approach. この参照アーキテクチャは、次の 2 つのクラウド オートメーション シナリオを示しています。This reference architecture illustrates two such cloud automation scenarios:

  1. コスト センターのタグ付け:この実装では、各 Azure リソースのコスト センターを追跡します。Cost center tagging: This implementation tracks the cost centers of each Azure resource. Azure Policy サービスは、既定のコスト センター ID を持つグループのすべての新しいリソースにタグを付けますThe Azure Policy service tags all new resources in a group with a default cost center ID. Event Grid は、リソース作成イベントを監視し、Azure 関数を呼び出します。The Event Grid monitors resource creation events, and then calls an Azure function. 関数は Azure Active Directory と対話し、新しいリソースのコスト センター ID を検証します。The function interacts with Azure Active Directory, and validates the cost center ID for the new resource. 異なる場合は、タグを更新し、リソース所有者に電子メールを送信します。If different, it updates the tag and sends out an email to the resource owner. Azure Active Directory の REST クエリは、わかりやすくするためにモック アウトされています。The REST queries for Azure Active Directory are mocked out for simplicity. Azure AD は、Azure AD PowerShell モジュールまたは ADAL for Python ライブラリを使用して統合することもできます。Azure AD can also be integrated using the Azure AD PowerShell module or the ADAL for Python library.

  2. スロットリングへの応答:この実装では、スロットリングがないか Cosmos DB データベースを監視します。Throttling response: This implementation monitors a Cosmos DB database for throttling. [CosmosDB へのデータ アクセス要求が、要求ユニット (または RU) の容量を超えると、Azure Monitor アラート](https://docs.microsoft.com/azure/azure-monitor/overview#alerts)がトリガーされます。Azure Monitor alerts are triggered when data access requests to CosmosDB exceed the capacity in Request Units (or RUs). Azure Monitor アクション グループは、これらのアラートに応答してオートメーション関数を呼び出すように構成されています。An Azure Monitor action group is configured to call the automation function in response to these alerts. この関数は、RU をより高い値にスケーリングし、容量を増やすことにより、アラートを停止します。The function scales the RUs to a higher value, increasing the capacity and in turn stopping the alerts. CosmosDB オートパイロット モード (プレビュー) は、この実装の代替手段であることに注意してください。Note that the CosmosDB autopilot mode (Preview) is an alternative to this implementation.

サーバーレス クラウド自動化

GitHub ロゴこのアーキテクチャのリファレンス実装は、GitHub で入手できます。GitHub logo The reference implementations for this architecture are available on GitHub.

これらの実装の関数は、オートメーションで使用される最も一般的なスクリプト言語の 2 つである PowerShell と Python で記述されています。The functions in these implementations are written in PowerShell and Python, two of the most common scripting languages used in automation. これらは、Azure CLI で Azure Functions Core Tools を使用してデプロイされます。They are deployed using Azure Functions Core Tools in Azure CLI. または、PowerShell コマンドレットのプレビュー バージョンを試して、Azure Functions をデプロイおよび管理することもできます。Alternatively, you can try a preview version of PowerShell cmdlet to deploy and manage Azure Functions.

イベントベースのオートメーションのパターンPatterns in event-based automation

イベントベースのオートメーションのシナリオは、Azure Functions を使用して実装することをお勧めします。Event-based automation scenarios are best implemented using Azure Functions. これらは次の一般的なパターンに従います。They follow these common patterns:

  • リソースのイベントに応答しますRespond to events on resources. これらは、Azure リソースやリソース グループの作成、削除、変更などのイベントに対する応答です。These are responses to events such as an Azure resource or resource group getting created, deleted, changed, and so on. このパターンでは、Event Grid を使用して、そのようなイベントに対して関数をトリガーします。This pattern uses Event Grid to trigger the function for such events. このパターンの例として、コスト センターのタグ付け実装が挙げられます。The cost center tagging implementation is an example of this pattern. 他には次のようなシナリオが考えられます。Other common scenarios include:

    • DevOps チームに、新しく作成されたリソース グループへのアクセス権を付与するgranting the DevOps teams access to newly created resource groups,
    • リソースが削除されたときに DevOps に通知を送信するsending notification to the DevOps when a resource is deleted, and
    • Azure Virtual Machines (VM) などのリソースのメンテナンス イベントに応答する。responding to maintenance events for resources such as Azure Virtual Machines (VMs).
  • スケジュールされたタスクScheduled tasks. これらは通常、タイマーによってトリガーされる関数を使用して実行されるメンテナンス タスクです。These are typically maintenance tasks executed using timer-triggered functions. このパターンの例を次に示します。Examples of this pattern are:

    • 夜間に VM を停止し、翌朝に開始するstopping a VM at night, and starting in the morning,
    • 定期的な間隔での Blob Storage コンテンツの読み取りと、Cosmos DB ドキュメントへの変換を行うreading Blob Storage content at regular intervals, and converting to a Cosmos DB document,
    • 使用されなくなったリソースを定期的にスキャンし、削除するperiodically scanning for resources no longer in use, and removing them, and
    • 自動的にバックアップするautomated backups.
  • Azure アラートを処理しますProcess Azure alerts. このパターンでは、Azure Monitor アラートとアクション グループの Azure Functions との統合が容易であることを活用しています。This pattern leverages the ease of integrating Azure Monitor alerts and action groups with Azure Functions. 通常、この関数は、アプリケーションとインフラストラクチャの両方で発生したメトリック、ログ分析、アラートに応じて修復アクションを実行します。The function typically takes remedial actions in response to metrics, log analytics, and alerts originating in the applications as well as the infrastructure. このパターンの例として、スロットリングへの応答の実装が挙げられます。The throttling response implementation is an example of this pattern. よく使用されるシナリオは以下のとおりです。Other common scenarios are:

    • SQL Database が最大サイズに達したときにテーブルを切り捨てるtruncating the table when SQL Database reaches maximum size,
    • 誤って停止された場合の VM でのサービスを再起動するrestarting a service in a VM when it is erroneously stopped, and
    • 関数が失敗した場合に通知を送信する。sending notifications if a function is failing.
  • 外部システムと調整しますOrchestrate with external systems. このパターンは、Logic Apps を使用してワークフローを調整することにより、外部システムとの統合を可能にします。This pattern enables integration with external systems, using Logic Apps to orchestrate the workflow. Logic Apps コネクタは、いくつかのサードパーティ サービスや、Office 365 などの Microsoft サービスと簡単に統合できます。Logic Apps connectors can easily integrate with several third-party services as well as Microsoft services such as Office 365. 実際のオートメーションには Azure Functions を使用できます。Azure Functions can be used for the actual automation. コスト センターのタグ付け実装がこのパターンの実例です。The cost center tagging implementation demonstrates this pattern. 他には次のようなシナリオが考えられます。Other common scenarios include:

    • 変更要求や承認などの IT プロセスを監視するmonitoring IT processes such as change requests or approvals, and
    • オートメーション タスクが完了したときに電子メール通知を送信する。sending email notification when automation task is completed.
  • web hook または API として公開しますExpose as a web hook or API. Azure Functions を使用したオートメーション タスクは、HTTP トリガー使用して web hook/API として公開することにより、サードパーティ製アプリケーションやコマンドライン ツールに統合できます。Automation tasks using Azure Functions can be integrated into third-party applications or even command-line tools, by exposing the function as a web hook/API using an HTTP trigger. PowerShell と Python の両方で、関数への外部アクセスをセキュリティで保護するために、複数の認証方法を使用できます。Multiple authentication methods are available in both PowerShell and Python to secure external access to the function. オートメーションは、アプリ固有の外部イベント (たとえば、Power Apps や GitHub との統合) に応答して行われます。The automation happens in response to the app-specific external events, for example, integration with power apps or GitHub. 一般的なシナリオは、次のとおりです。Common scenarios include:

    • 失敗したサービスのオートメーションをトリガーするtriggering automation for a failing service, and
    • 組織のリソースにユーザーをオンボードする。onboarding users to the organization's resources.
  • ChatOps インターフェイスを作成しますCreate ChatOps interface. このパターンによって、お客様がチャットベースの操作インターフェイスを作成し、開発および操作の関数とコマンドを人間のコラボレーションに従って実行できます。This pattern enables customers to create a chat-based operational interface, and run development and operations functions and commands in-line with human collaboration. これは Azure Bot Framework に統合でき、デプロイ、監視、一般的な質問などに対して Microsoft Teams または Slack のコマンドを使用できます。This can integrate with the Azure Bot Framework and use Microsoft Teams or Slack commands for deployment, monitoring, common questions, and so on. ChatOps インターフェイスにより、運用インシデントを管理するためのリアルタイム システムが作成され、そのチャットでは各ステップが自動的に文書化されます。A ChatOps interface creates a real-time system for managing production incidents, with each step documented automatically on the chat. 詳細については、「ChatOps で DevOps を改善する方法」を参照してください。Read How ChatOps can help you DevOps better for more information.

  • ハイブリッド自動化Hybrid automation. このパターンでは、Azure App Service ハイブリッド接続を使用して、ローカル コンピューターにソフトウェア コンポーネントがインストールされます。This pattern uses the Azure App Service Hybrid Connections to install a software component on your local machine. このコンポーネントにより、そのコンピューターのリソースへのアクセスを保護できます。This component allows secure access to resources on that machine. 現在、ハイブリッド環境を管理する機能は、PowerShell 関数を使用して Windows ベースのシステムで使用可能です。The ability to manage hybrid environments is currently available on Windows-based systems using PowerShell functions. 一般的なシナリオは、次のとおりです。Common scenarios include:

    • オンプレミスのマシンを管理する。managing your on-premises machines, and
    • ジャンプ サーバーを介して、ファイアウォールの背後にある他のシステム (オンプレミスの SQL Server など) を管理する。managing other systems behind the firewall (for example, an on-premises SQL Server) through a jump server.

ArchitectureArchitecture

アーキテクチャは、次のブロックで構成されています。The architecture consists of the following blocks:

Azure FunctionsAzure Functions. Azure Functions は、このアーキテクチャでイベント ドリブンのサーバーレス コンピューティング機能を提供します。Azure Functions provide the event-driven, serverless compute capabilities in this architecture. 関数は、イベントまたは警告によってトリガーされたときに、オートメーション タスクを実行します。A function performs automation tasks, when triggered by events or alerts. リファレンス実装では、HTTP 要求を使用して関数が呼び出されます。In the reference implementations, a function is invoked with an HTTP request. ステートレス、およびべき等である関数を開発することで、コードの複雑さを最小限に抑える必要があります。Code complexity should be minimized, by developing the function that is stateless, and idempotent.

べき等関数を複数回実行すると、同じ結果になります。Multiple executions of an idempotent function create the same results. べき等を維持するために、スロットリング シナリオでの関数のスケーリングは単純に保持されています。To maintain idempotency, the function scaling in the throttling scenario is kept simplistic. 実際のオートメーションでは、適切にスケール アップまたはスケール ダウンするようにしてください。In real world automation, make sure to scale up or down appropriately.

関数を記述する際のベストプラクティスについては、「Azure Functions のパフォーマンスと信頼性を最適化する」を参照してください。Read the Optimize the performance and reliability of Azure Functions for best practices when writing your functions.

Logic AppsLogic Apps. Logic Apps を使用すると、組み込みのコネクタを使用して簡単に実装でき、簡単なタスクを実行するために使用できます。Logic Apps can be used to perform simpler tasks, easily implemented using the built-in connectors. これらのタスクは、電子メール通知から外部管理アプリケーションとの統合までさまざまです。These tasks can range from email notifications, to integrating with external management applications. サードパーティのアプリケーションで Logic Apps を使用する方法については、「Azure での基本的なエンタープライズ統合」を参照してください。To learn how to use Logic Apps with third-party applications, read basic enterprise integration in Azure.

Logic Apps には、ノー コードまたはロー コード ビジュアル デザイナーが用意されており、一部のオートメーション シナリオで単独で使用できます。Logic Apps provides a no code or low code visual designer, and may be used alone in some automation scenarios. シナリオに適したサービスを確認するには、Azure Functions と Logic Apps の比較 を参照してください。Read this comparison between Azure Functions and Logic Apps to see which service can fit your scenario.

Event GridEvent Grid. Event Grid には、他の Azure サービスからのイベントやカスタム イベント (カスタム トピック) の組み込みのサポートがあります。Event Grid has built-in support for events from other Azure services, as well as custom events (also called custom topics). リソース作成などの操作イベントは、Event Grid の組み込みメカニズムを使用して、オートメーション関数に簡単に反映できます。Operational events such as resource creation can be easily propagated to the automation function, using the Event Grid's built-in mechanism.

Event Grid は、パブリッシュ/サブスクライブ モデルを使用してイベント ベースのオートメーションを簡素化し、HTTP 経由で配信されるイベントの信頼性の高いオートメーションを可能にします。Event Grid simplifies the event-based automation with a publish-subscribe model, allowing reliable automation for events delivered over HTTP.

Azure MonitorAzure Monitor. Azure Monitor アラートは、重大状態を監視し、Azure Monitor アクション グループを使用して是正措置を実行できます。Azure Monitor alerts can monitor for critical conditions, and take corrective action using Azure Monitor action groups. これらのアクション グループは、Azure Functions と簡単に統合できます。These action groups are easily integrated with Azure Functions. これは、データベースのスロットリングなど、インフラストラクチャのエラー状態を監視および修正するのに役立ちます。This is useful to watch for and fix any error conditions in your infrastructure, such as database throttling.

オートメーション アクションAutomation action. この広範なブロックは、関数がやり取りできる他のサービスを表し、オートメーション機能を提供します。This broad block represents other services that your function can interact with, to provide the automation functionality. たとえば、最初のシナリオでタグを検証するための Azure Active Directory、2 つ目のシナリオでプロビジョニングするデータベースです。For example, Azure Active Directory for tag validation as in the first scenario, or a database to provision as in the second scenario.

回復性に関する考慮事項Resiliency considerations

Azure FunctionsAzure Functions

HTTP タイムアウトを処理するHandle HTTP timeouts

より長いオートメーション タスクで HTTP タイムアウトを回避するには、このイベントを Service Bus でキューに置いて、実際のオートメーションを別の関数で処理します。To avoid HTTP timeouts for a longer automation task, queue this event in a Service Bus, and handle the actual automation in another function. スロットリングへの応答のオートメーション シナリオは、実際の Cosmos DB RU プロビジョニングが高速であっても、このパターンを示しています。The throttling response automation scenario illustrates this pattern, even though the actual Cosmos DB RU provisioning is fast.

オートメーション関数の信頼性

Durable Functions は、呼び出しの間の状態を維持し、上記の方法の代わりに使用できます。Durable functions, which maintain state between invocations, provide an alternative to the above approach. これらは現在、JavaScript および C# でのみサポートされています。These are currently supported only in JavaScript and C#.

エラーのログLog failures

ベストプラクティスとして、関数は、オートメーション タスクの実行中に発生したエラーをログに記録する必要があります。As a best practice, the function should log any failures in carrying out automation tasks. これにより、エラー状態のトラブルシューティングを適切に行うことができます。This allows for proper troubleshooting of the error conditions. リファレンス実装では、テレメトリ システムとして Application Insights を使用します。The reference implementations use the Application Insights as the telemetry system.

コンカレンシーConcurrency

オートメーション関数の同時実行要件を確認します。Verify the concurrency requirement for your automation function. host.json ファイルの変数 maxConcurrentRequests を設定することで、コンカレンシーが制限されます。Concurrency is limited by setting the variable maxConcurrentRequests in the file host.json. この設定により、お使いの関数アプリで実行されている同時実行関数インスタンスの数が制限されます。This setting limits the number of concurrent function instances running in your function app. すべてのインスタンスで CPU とメモリが消費されるため、CPU を集中的に使用する操作の場合は、この値を調整する必要があります。Since every instance consumes CPU and memory, this value needs to be adjusted for CPU-intensive operations. 関数呼び出しの速度が遅すぎるようである場合、または完了できない場合は、maxConcurrentRequests を下げます。Lower the maxConcurrentRequests if your function calls appear to be too slow or aren't able to complete. 詳細については、「コンカレンシーを適切に処理するようにホストの動作を構成する」を参照してください。See the section Configure host behaviors to better handle concurrency for more details.

べき等性Idempotency

オートメーション関数がべき等であることを確認します。Make sure your automation function is idempotent. Azure Monitor と Event Grid の両方で、サブスクライブしたイベントが解決された発生した進行中などの進行状況、またはリソースがプロビジョニングされている正常に作成されたなどを示すアラートまたはイベントを生成する、さらには構成が間違っているために誤ったアラートを送信する場合があります。Both Azure Monitor and Event Grid may emit alerts or events that indicate progression such as your subscribed event is resolved, fired, in progress, etc., your resource is being provisioned, created successfully, etc., or even send false alerts due to a misconfiguration. 関数が関連するアラートおよびイベントに対してのみ動作し、それ以外は無視することを確認し、誤ったまたは正しく構成されていないイベントによって望ましくない結果が発生しないようにします。Make sure your function acts only on the relevant alerts and events, and ignores all others, so that false or misconfigured events do not cause unwanted results. 詳細については、べき等パターンに関するブログ記事を参照してください。For more information, read this blog post on idempotency patterns.

Event GridEvent Grid

ワークフローで Event Grid を使用する場合は、シナリオでグリッドを渋滞させるのに十分な大量のイベントが生成される可能性があるかどうかを確認します。If your workflow uses Event Grid, check if your scenario could generate a high volume of events, enough to clog the grid. 配信が確認されない場合にイベントがどのように処理されるかを理解し、それに応じてロジックを変更するには、「Event Grid によるメッセージの配信と再試行」をご覧ください。See Event Grid message delivery and retry to understand how it handles events when delivery isn't acknowledged, and modify your logic accordingly. コスト センター ワークフローでは、リソース グループ内のリソース作成イベントのみを監視するため、このような追加のチェックは実装されません。The cost center workflow does not implement additional checks for this, since it only watches for resource creation events in a resource group. サブスクリプション全体で作成されたリソースの監視では、より多くのイベントが生成され、回復性の高い処理が必要になります。Monitoring resources created in an entire subscription, can generate larger number of events, requiring a more resilient handling.

Azure MonitorAzure Monitor

十分な大量のアラートが生成され、オートメーションによって Azure リソースが更新される場合は、Azure Resource Manager のスロットリング制限に達する可能性があります。If a sufficiently large number of alerts are generated, and the automation updates Azure resources, throttling limits of the Azure Resource Manager might be reached. これは、そのサブスクリプションのインフラストラクチャの残りの部分に悪影響を及ぼす可能性があります。This can negatively affect the rest of the infrastructure in that subscription. Azure Monitor によって生成されるアラートの頻度を制限することで、この状況を回避します。Avoid this situation by limiting the frequency of alerts getting generated by the Azure Monitor. また、特定のエラーに対して生成されるアラートの数を制限することもできます。You may also limit the alerts getting generated for a particular error. 詳細については、Azure Monitor アラートのドキュメントを参照してください。Refer to the documentation on Azure Monitor alerts for more information.

セキュリティに関する考慮事項Security considerations

関数へのアクセスの制御Control access to the function

承認レベルを設定して、HTTP によってトリガーされる関数へのアクセスを制限します。Restrict access to an HTTP-triggered function by setting the authorization level. 匿名認証を使用すると、http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME> などの URL を使用して関数に簡単にアクセスできます。With anonymous authentication, the function is easily accessible with a URL such as http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. 関数レベル認証では、URL に関数キーを要求することにより、http エンドポイントを難読化できます。Function level authentication can obfuscate the http endpoint, by requiring function keys in the URL. このレベルは、ファイル function.json で設定されます。This level is set in the file function.json:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

運用環境では、関数をセキュリティで保護するために追加の戦略が必要になる場合があります。For production environment, additional strategies might be required to secure the function. リファレンス実装では、関数は他の Azure サービスによって Azure プラットフォーム内で実行され、インターネットには公開されません。In the reference implementations, the functions are executed within the Azure platform by other Azure services, and will not be exposed to the internet. web hook としてアクセスされる関数には関数の認証で十分です。Function authorization is sufficient for functions accessed as web hooks.

関数の認証の上にセキュリティ層を追加することを検討してください。たとえば、Consider adding security layers on top of function authentication, such as,

  • クライアント証明書を使用した認証authenticating with client certificates, or
  • Easy Auth の統合を使用して、呼び出し元が関数をホストするディレクトリの一部であるか、アクセス権を持っていることを確認します。making sure the caller is part of or has access to the directory that hosts the function, by using Easy Auth integration.

Azure Monitor アクション グループで使用できる唯一のオプションは、関数レベル認証です。Note that function-level authentication is the only option available to Azure Monitor action groups.

関数をサードパーティのアプリケーションまたはサービスから呼び出す必要がある場合は、API Management レイヤーを使用してアクセスを提供することをお勧めします。If the function needs to be called from a third-party application or service, it is recommended to provide access to it with an API Management layer. このレイヤーでは、認証を強制します。This layer should enforce authentication. API Management には、Azure Functions と統合された 従量課金レベルがあります。これにより、API が実行された場合にのみ支払いをします。API Management now has a consumption tier integrated with Azure Functions, which allows you to pay only if the API gets executed. 詳細については、「OpenAPI を使用して関数を作成して公開する」をご覧ください。For more information, read Create and expose your functions with OpenAPI.

呼び出し元のサービスがサービス エンドポイントをサポートしている場合は、次のよりコストの高いオプションを考慮することができます。If the calling service supports service endpoints, the following costlier options could be considered:

  • 専用の App Service プランを使用します。これにより、仮想ネットワーク内の関数をロック ダウンして、アクセスを制限できます。Use a dedicated App Service plan, where you can lock down the functions in a virtual network to limit access to it. これは、使用量ベースのサーバーレス モデルでは実現できません。This is not possible in a consumption-based serverless model.
  • Azure Functions Premium プランを使用します。これには、関数アプリで使用される専用の仮想ネットワークが含まれます。Use the Azure Functions Premium plan, which includes a dedicated virtual network to be used by your function apps.

これらのオプション間の価格と機能を比較するには、「Azure Functions のスケールとホスティング」をご覧ください。To compare pricing and features between these options, read Azure Functions scale and hosting.

関数がアクセスできる内容を制御するControl what the function can access

Azure リソースのマネージド IDは、Azure Active Directory 機能であり、関数が他の Azure リソースやサービスに対して認証を行い、アクセスする方法を簡略化します。Managed identities for Azure resources, an Azure Active Directory feature, simplifies how the function authenticates and accesses other Azure resources and services. 認証資格情報は、Azure AD によって管理されているため、コードが管理する必要はありません。The code does not need to manage the authentication credentials, since it is managed by Azure AD.

マネージド ID には、次の 2 種類があります。There are two types of managed identities:

  • システム割り当てマネージド ID:これらは Azure リソースの一部として作成され、複数のリソース間で共有することはできません。System-assigned managed identities: These are created as part of the Azure resource, and cannot be shared among multiple resources. これらは、リソースが削除されると削除されます。These get deleted when the resource is deleted. これらは、単一の Azure リソースを含むか、独立した ID を必要とするシナリオに使用します。Use these for scenarios, which involve single Azure resource or which need independent identities. 両方のリファレンス実装は、1 つのリソースのみを更新するため、システムによって割り当てられた ID を使用します。Both the reference implementations use system-assigned identities since they update only a single resource. マネージド ID は、別のリソースを更新する場合にのみ必要です。Managed identities are only required to update another resource. たとえば、関数は、マネージ ID を使用せずにリソースタグを読み取ることができます。For example, a function can read the resource tags without a managed identity. システムによって割り当てられた ID を関数に追加するには、次の手順を参照してください。See these instructions to add a system-assigned identity to your function.

  • ユーザー割り当て済みマネージド ID:これらはスタンドアロンの Azure リソースとして作成されます。User-assigned managed identities: These are created as stand-alone Azure resources. これらは複数のリソース間で共有できるため、明示的に削除する必要があります。These can be shared across multiple resources, and need to be explicitly deleted. ユーザー割り当て ID を関数に追加する方法については、これらの手順を参照してください。Read these instructions on how to add user-assigned identity to your function. 次のようなシナリオで使用します。Use these for scenarios that:

    • 1 つの ID を共有できる複数のリソースへのアクセスが必要な場合Require access to multiple resources that can share a single identity, or
    • プロビジョニング中にリソースをセキュリティで保護するための事前承認が必要な場合Need pre-authorization to secure resources during provisioning, or
    • リソースが頻繁にリサイクルされるものの、アクセス許可は一貫性を保つ必要がある場合Have resources that are recycled frequently, while permissions need to be consistent.

Azure 関数に ID が割り当てられたら、ロールベースのアクセス制御 (RBAC) を使用してリソースにアクセスするロールを割り当てます。Once the identity is assigned to the Azure function, assign it a role using role-based access control (RBAC) to access the resources. たとえば、リソースを更新するには、共同作成者ロールを関数 ID に割り当てる必要があります。For example, to update a resource, the Contributor role will need to be assigned to the function identity.

コストに関する考慮事項Cost considerations

コストの見積もりには、Azure 料金計算ツールをご利用ください。Use the Azure pricing calculator to estimate costs. 次にコスト削減のためのいくつかの考慮事項を示します。Here are some considerations for lowering cost.

Azure Logic AppsAzure Logic Apps

Logic Apps には従量課金制の価格モデルがあります。Logic apps have a pay-as-you-go pricing model. トリガー、アクション、およびコネクタの実行は、ロジック アプリを実行するたびに課金されます。Triggers, actions, and connector executions are metered each time a logic app runs. トリガーを含め、成功したアクションと失敗したアクションすべてが実行と見なされます。All successful and unsuccessful actions, including triggers, are considered as executions.

Logic Apps には、固定価格モデルもあります。Logic apps have also a fixed pricing model. Azure 仮想ネットワークで、セキュリティで保護されたリソースと通信するロジック アプリを実行する必要がある場合は、それを統合サービス環境 (ISE) で作成できます。If you need to run logic apps that communicate with secured resources in an Azure virtual network, you can create them in an Integration Service Environment (ISE).

詳細については、「Azure Logic Apps の価格モデル」を参照してください。For details, see Pricing model for Azure Logic Apps.

このアーキテクチャでは、ロジック アプリが、コスト センターのタグ付けシナリオでワークフローの調整に使用されます。In this architecture, logic apps are used in the cost center tagging scenario to orchestrate the workflow.

組み込みコネクタを使用して Azure Functions に接続され、オートメーション タスクが完了した時点で電子メール通知が送信されます。Built-in connectors are used to connect to Azure Functions and send email notification an when an automation task is completed. 関数は、HTTP/API トリガーを使用して、Web hook/API として公開されます。The functions are exposed as a web hook/API using an HTTP trigger. Logic Apps は、HTTPS 要求が発生した場合にのみトリガーされます。Logic apps are triggered only when an HTTPS request occurs. 関数によってポーリングが継続的に行われ、特定の条件が確認される設計と比較すると、この方法はコスト効率に優れています。This is a cost effective way when compared to a design where functions continuously poll and check for certain criteria. すべてのポーリング要求が、アクションとして課金されます。Every polling request is metered as an action.

詳細については、「Logic Apps の価格」をご覧ください。For more information, see Logic Apps pricing.

Azure FunctionsAzure Functions

Azure Functions は、次の 3 つの価格プランでご利用いただけます。Azure Functions are available with the following three pricing plans.

  • 従量課金プランConsumption plan. これは最もコスト効率の高いサーバーレス プランで、お客様の関数が実行されていた時間に対してのみ課金されます。This is the most cost-effective, serverless plan available, where you only pay for the time your function runs. このプランでは、一度に最大 10 分間関数を実行できます。Under this plan, functions can run for up to 10 minutes at a time.

  • Premium プランPremium plan. 自動化シナリオに、実行時間が長い、専用仮想ネットワークなどの追加要件がある場合は、Azure Functions Premium プランを使用することを検討してください。Consider using Azure Functions Premium plan for automation scenarios with additional requirements, such as a dedicated virtual network, a longer execution duration, and so on. これらの関数は、最大 1 時間実行できます。バックアップ実行、データベースのインデックス作成、レポート生成など、自動化タスクに時間がかかる場合は、このプランを選択する必要があります。These functions can run for up to an hour, and should be chosen for longer automation tasks such as running backups, database indexing, or generating reports.

  • App Service プランApp Service plan. Azure App Service ハイブリッド接続を使用するハイブリッド自動化のシナリオでは、App Service プランを使用する必要があります。Hybrid automation scenarios that use the Azure App Service Hybrid Connections, will need to use the App Service plan. このプランで作成された関数は、Web アプリと同様、実行時間に制限はありません。The functions created under this plan can run for unlimited duration, similar to a web app.

このアーキテクチャでは、RU を高い値にスケールアップして Cosmos DB 構成を変更する、Azure Active Directory のタグを更新する、といったタスクに Azure Functions が使用されます。In this architecture Azure Functions are used for tasks such as updating tags in Azure Active Directory, or changing cosmos DB configuration by scaling up the RUs to a higher value. これらのタスクは対話型で実行中でないため、このユース ケースには従量課金プランが適しています。The Consumption plan is the appropriate for this use case because those tasks are interactive and not on going.

Azure Cosmos DBAzure Cosmos DB

Azure Cosmos DB では、プロビジョニングされたスループットと消費されたストレージに対して時間単位で課金されます。Azure Cosmos DB bills for provisioned throughput and consumed storage by hour. プロビジョニングされたスループットは要求ユニット/秒 (RU/秒) で表され、挿入、読み取りなどの一般的なデータベース操作に使用できます。Provisioned throughput is expressed in Request Units per second (RU/s), which can be used for typical database operations, such as inserts, reads. ストレージへの課金は、格納データとインデックスに使用される GB ごとに行われます。Storage is billed for each GB used for your stored data and index. 詳細については、「Azure Cosmos DB の価格」を参照してください。See Cosmos DB pricing model for more information.

このアーキテクチャでは、Cosmos DB へのデータ アクセス要求が、要求ユニット (RU) の容量を超えると、Azure Monitor によってアラートがトリガーされます。In this architecture, when data access requests to Cosmos DB exceed the capacity in Request Units (or RUs), Azure Monitor triggers alerts. このアラートに応答してオートメーション関数を呼び出すように、Azure Monitor アクション グループが構成されています。In response to those alerts, an Azure Monitor action group is configured to call the automation function. 関数は、RU を高い値にスケーリングします。The function scales the RUs to a higher value. ワークロードで必要とされるリソースに対してのみ、時間単位で課金されるため、これはコストを抑え続けるうえで役に立ちます。This helps to keep the cost down because you only pay for the resources that your workloads need on a per-hour basis.

ワークロードのコストをすばやく見積もるには、Cosmos DB 容量計算ツールを使用します。To get a quick cost estimate of your workload, use the Cosmos DB capacity calculator.

詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。For more information, see the Cost section in Microsoft Azure Well-Architected Framework.

デプロイに関する考慮事項Deployment considerations

アプリケーションの動作を管理する重要なオートメーション ワークフローでは、効率的な DevOps パイプラインを使用してダウンタイムなしのデプロイを達成する必要があります。For critical automation workflows that manage behavior of your application, zero downtime deployment must be achieved using an efficient DevOps pipeline. 詳細については、「サーバーレス バックエンドのデプロイ」をご覧ください。For more information, read serverless backend deployment.

オートメーションが複数のアプリケーションを対象としている場合は、オートメーションに必要なリソースを別のリソース グループに保持します。If the automation covers multiple applications, keep the resources required by the automation in a separate resource group. オートメーションが単一のアプリケーションを対象とする場合、1 つのリソース グループをオートメーションとアプリケーション リソース間で共有できます。A single resource group can be shared between automation and application resources, if the automation covers a single application.

ワークフローに多数のオートメーション関数が含まれている場合は、関数をグループ化して 1 つの関数アプリで 1 つのシナリオに対応します。If the workflow involves a number of automation functions, group the functions catering to one scenario in a single function app. 詳細については、「Function App を管理する」をご覧ください。Read Manage function app for more information.

ソリューションのデプロイ方法Deploy the solution

このアーキテクチャのリファレンス実装をデプロイするには、必要なワークフローについて GitHub のデプロイの手順を参照してください。To deploy the reference implementations for this architecture, see the deployment steps on GitHub for the desired workflow.

次のステップNext steps

サーバーレス実装の詳細をご確認ください。Learn more about the serverless implementations.