サーバーレス テクノロジを使用して、クラウド上でワークフローや繰り返し実行されるタスクを自動化することで、組織の DevOps チームの生産性を大幅に向上させることができます。 サーバーレス モデルは、イベント ドリブン アプローチに適したオートメーション シナリオに最適です。
アーキテクチャ
シナリオ
この記事では、次の 2 つの主要なクラウド自動化シナリオについて説明します。
コスト センターのタグ付け - この実装では、各 Azure リソースのコスト センターを追跡します。 Azure Policy サービスは、既定のコスト センター ID を持つグループのすべての新しいリソースにタグを付けます。 Azure Event Grid は、リソース作成イベントを監視し、Azure 関数を呼び出します。 この関数は Microsoft Entra ID と対話し、新しいリソースのコスト センター ID を検証します。 異なる場合は、タグを更新し、リソース所有者に電子メールを送信します。 Microsoft Entra ID の REST クエリは、わかりやすくするためにモック アウトされています。 Microsoft Entra ID は、Microsoft Graph PowerShell モジュールまたは Python 用 Microsoft Authentication ライブラリ (MSAL) を使用して統合することもできます。
スロットリングへの応答: この例では、スロットリングがないか Azure Cosmos DB データベースを監視します。 Azure Cosmos DB へのデータ アクセス要求が、要求ユニット (RU) の容量を超えると、Azure Monitor アラートがトリガーされます。 Azure Monitor アクション グループは、これらのアラートに応答してオートメーション関数を呼び出すように構成されています。 この関数は、RU をより高い値にスケーリングし、容量を増やすことにより、アラートを停止します。
注意
これらのソリューションは、これらのタスクを実行する唯一の方法ではなく、サーバーレス テクノロジが環境シグナル (イベント) に反応し、環境への変化に影響を与えるしくみを示す実例として示されています。 実用的な場合は、カスタム ソリューションよりもプラットフォーム ネイティブなソリューションを使用してください。 たとえば、Azure Cosmos DB では、スロットリングへの応答シナリオのネイティブ代替手段として自動スケーリングのスループットがネイティブにサポートされます。
シナリオ 1 の参照実装は、GitHub で入手できます。
これらのサーバーレス クラウド オートメーション シナリオの関数は、システムのオートメーションで使用される最も一般的な 2 つのスクリプト言語である PowerShell と Python で記述されています。 これらは、Azure CLI で Azure Functions Core Tools を使用してデプロイされます。 または、Az.Functions PowerShell コマンドレットを使用して Azure Functions をデプロイおよび管理することもできます。
ワークフロー
イベントベースのオートメーションのシナリオは、Azure Functions を使用して実装することをお勧めします。 これらは次の一般的なパターンに従います。
リソースのイベントに応答します。 これらは、Azure リソースやリソース グループの作成、削除、変更などのイベントに対する応答です。 このパターンでは、Event Grid を使用して、そのようなイベントに対して関数をトリガーします。 このパターンの例は、コスト センターのタグ付けシナリオです。 他には次のようなシナリオが考えられます。
- DevOps チームに、新しく作成されたリソース グループへのアクセス権を付与する
- リソースが削除されたときに DevOps に通知を送信する
- Azure Virtual Machines (VM) などのリソースのメンテナンス イベントに応答する。
スケジュールされたタスク。 これらは通常、タイマーによってトリガーされる関数を使用して実行されるメンテナンス タスクです。 このパターンの例を次に示します。
- 夜間にリソースを停止し、朝に開始する
- 定期的な間隔での Blob Storage コンテンツの読み取りと、Azure Cosmos DB ドキュメントへの変換を行う
- 使用されなくなったリソースを定期的にスキャンし、削除する
- 自動的にバックアップする
Azure アラートを処理します。 このパターンでは、Azure Monitor アラートとアクション グループを Azure Functions と統合することの容易さが活用されています。 通常、この関数は、アプリケーションとインフラストラクチャで発生したメトリック、ログ分析、アラートに応じて修復アクションを実行します。 このパターンの例は、スロットリングへの応答シナリオです。 よく使用されるシナリオは以下のとおりです。
- SQL Database が最大サイズに達したときにテーブルを切り捨てる
- 誤って停止された場合の VM でのサービスを再起動する
- 関数が失敗した場合に通知を送信する。
外部システムと調整します。 このパターンは、Logic Apps を使用してワークフローを調整することにより、外部システムとの統合を可能にします。 Logic Apps コネクタは、いくつかのサードパーティ サービスや、Microsoft 365 などの Microsoft サービスと簡単に統合できます。 実際のオートメーションには Azure Functions を使用できます。 このパターンの実例は、コスト センターのタグ付けシナリオです。 他には次のようなシナリオが考えられます。
- 変更要求や承認などの IT プロセスを監視する
- オートメーション タスクが完了したときに電子メール通知を送信する。
web hook または API として公開します。 Azure Functions を使用したオートメーション タスクは、HTTP トリガー使用して web hook/API として公開することにより、サードパーティ製アプリケーションやコマンドライン ツールに統合できます。 PowerShell と Python の両方で、関数への外部アクセスをセキュリティで保護するために、複数の認証方法を使用できます。 オートメーションは、アプリ固有の外部イベント (たとえば、Power Apps や GitHub との統合) に応答して行われます。 一般的なシナリオは、次のとおりです。
- 失敗したサービスのオートメーションをトリガーする
- 組織のリソースにユーザーをオンボードする。
ChatOps インターフェイスを作成します。 このパターンによって、お客様がチャットベースの操作インターフェイスを作成し、開発および操作の関数とコマンドを人間のコラボレーションに従って実行できます。 これは Azure Bot Framework に統合でき、デプロイ、監視、一般的な質問などに対して Microsoft Teams または Slack のコマンドを使用できます。 ChatOps インターフェイスにより、運用インシデントを管理するためのリアルタイム システムが作成され、そのチャットでは各ステップが自動的に文書化されます。 詳細については、「ChatOps で DevOps を改善する方法」を参照してください。
ハイブリッド自動化。 このパターンでは、Azure App Service ハイブリッド接続を使用して、ローカル コンピューターにソフトウェア コンポーネントがインストールされます。 このコンポーネントにより、そのコンピューターのリソースへのアクセスを保護できます。 現在、ハイブリッド環境を管理する機能は、PowerShell 関数を使用して Windows ベースのシステムで使用可能です。 一般的なシナリオは、次のとおりです。
- オンプレミスのマシンを管理する。
- ジャンプ サーバーを介して、ファイアウォールの背後にある他のシステム (オンプレミスの SQL Server など) を管理する。
Components
アーキテクチャは、次のコンポーネントで構成されています。
Azure Functions。 Azure Functions は、このアーキテクチャでイベント ドリブンのサーバーレス コンピューティング機能を提供します。 関数は、イベントまたは警告によってトリガーされたときに、オートメーション タスクを実行します。 2 つのシナリオで、関数は HTTP 要求を使用して呼び出されます。 ステートレスおよびべき等の関数を開発することで、コードの複雑さを最小限に抑えられます。
べき等関数を複数回実行すると、同じ結果になります。 べき等を維持するために、スロットリング シナリオでの関数のスケーリングは単純に保持されています。 実際のオートメーションでは、適切にスケール アップまたはスケール ダウンするようにしてください。 関数を記述する際のベストプラクティスについては、「Azure Functions のパフォーマンスと信頼性を最適化する」を参照してください。
Azure Logic Apps。 Logic Apps を使用すると、組み込みのコネクタを使用して簡単に実装でき、簡単なタスクを実行するために使用できます。 これらのタスクは、電子メール通知から外部管理アプリケーションとの統合までさまざまです。 サードパーティのアプリケーションで Logic Apps を使用する方法については、「Azure での基本的なエンタープライズ統合」を参照してください。
Logic Apps には、ノー コードまたはロー コード ビジュアル デザイナーが用意されており、一部のオートメーション シナリオで単独で使用できます。 シナリオに適したサービスを確認するには、Azure Functions と Logic Apps の比較 を参照してください。
Event Grid。 Event Grid には、他の Azure サービスからのイベントやカスタム イベント (カスタム トピック) の組み込みのサポートがあります。 リソース作成などの操作イベントは、Event Grid の組み込みメカニズムを使用して、オートメーション関数に簡単に反映できます。
Event Grid では、パブリッシュ/サブスクライブ モデルを使用してイベントベースのオートメーションを簡素化し、HTTPS 経由で配信されるイベントに対して信頼性の高いオートメーションを実現します。
Azure Monitor。 Azure Monitor アラートは、重大状態を監視し、Azure Monitor アクション グループを使用して是正措置を実行できます。 これらのアクション グループは、Azure Functions と簡単に統合できます。 これは、データベースのスロットリングなど、インフラストラクチャのエラー状態を監視および修正するのに役立ちます。
オートメーション アクション。 この広範なブロックは、関数がやり取りできる他のサービスを表し、オートメーション機能を提供します。 たとえば、最初のシナリオでタグを検証するための Microsoft Entra ID、2 つ目のシナリオでプロビジョニングするデータベースです。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
回復性
Azure Functions
HTTP タイムアウトを処理する
より長いオートメーション タスクで HTTP タイムアウトを回避するには、このイベントを Service Bus でキューに置いて、実際のオートメーションを別の関数で処理します。 スロットリングへの応答のオートメーション シナリオは、実際の Azure Cosmos DB RU プロビジョニングが高速であっても、このパターンを示しています。
Durable Functions は、呼び出しの間の状態を維持し、上記の方法の代わりに使用できます。 Durable Functions では特定の言語のみがサポートされます。
エラーのログ
ベストプラクティスとして、関数は、オートメーション タスクの実行中に発生したエラーをログに記録する必要があります。 これにより、エラー状態のトラブルシューティングを適切に行うことができます。 Azure Functions では、テレメトリ システムとしての Application Insights との統合がネイティブにサポートされます。
コンカレンシー
オートメーション関数の同時実行要件を確認します。 host.json ファイルの変数 maxConcurrentRequests を設定することで、コンカレンシーが制限されます。 この設定により、お使いの関数アプリで実行されている同時実行関数インスタンスの数が制限されます。 すべてのインスタンスで CPU とメモリが消費されるため、CPU を集中的に使用する操作の場合は、この値を調整する必要があります。 関数呼び出しの速度が遅すぎるようである場合、または完了できない場合は、maxConcurrentRequests を下げます。 詳細については、「コンカレンシーを適切に処理するようにホストの動作を構成する」を参照してください。
べき等性
オートメーション関数がべき等であることを確認します。 Azure Monitor と Event Grid の両方で、サブスクライブしたイベントが解決された、発生した、進行中などの進行状況、またはリソースがプロビジョニングされている、正常に作成されたなどを示すアラートまたはイベントを生成する、さらには構成が間違っているために誤ったアラートを送信する場合があります。 関数が関連するアラートおよびイベントに対してのみ動作し、それ以外は無視することを確認し、誤ったまたは正しく構成されていないイベントによって望ましくない結果が発生しないようにします。 詳細については、「同一入力のための Azure Functions の設計」を参照してください。
Event Grid
ワークフローで Event Grid を使用する場合は、シナリオでグリッドを渋滞させるのに十分な大量のイベントが生成される可能性があるかどうかを確認します。 配信が確認されない場合にイベントがどのように処理されるかを理解し、それに応じてロジックを変更するには、「Event Grid によるメッセージの配信と再試行」をご覧ください。 コスト センター ワークフローでは、リソース グループ内のリソース作成イベントのみを監視するため、このような追加のチェックは実装されません。 サブスクリプション全体で作成されたリソースの監視では、より多くのイベントが生成され、回復性の高い処理が必要になります。
Azure Monitor
十分な大量のアラートが生成され、オートメーションによって Azure リソースが更新される場合は、Azure Resource Manager のスロットリング制限に達する可能性があります。 これは、そのサブスクリプションのインフラストラクチャの残りの部分に悪影響を及ぼす可能性があります。 Azure Monitor によって生成されるアラートの頻度を制限することで、この状況を回避します。 また、特定のエラーに対して生成されるアラートの数を制限することもできます。 詳細については、Azure Monitor アラートのドキュメントを参照してください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
関数へのアクセスの制御
承認レベルを設定して、HTTP によってトリガーされる関数へのアクセスを制限します。 匿名認証を使用すると、http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME> などの URL を使用して関数に簡単にアクセスできます。 関数レベル認証では、URL に関数キーを要求することにより、http エンドポイントを難読化できます。 このレベルは、ファイル function.json で設定されます。
{
"bindings": [
{
"authLevel": "function",
"type": "httpTrigger",
"direction": "in",
"name": "Request",
"methods": [
"get",
"post"
]
},
{
"type": "http",
"direction": "out",
"name": "Response"
}
]
}
運用環境では、関数をセキュリティで保護するために追加の戦略が必要になる場合があります。 これらのシナリオでは、関数は他の Azure サービスによって Azure プラットフォーム内で実行され、インターネットには公開されません。 Web hook としてアクセスされる関数には、Function の承認で十分なことがあります。
関数の認証の上にセキュリティ層を追加することを検討してください。たとえば、
- クライアント証明書を使用した認証
- App Service 認証を有効にして、呼び出し元が関数をホストするディレクトリの一部であるか、それに対するアクセス権を持っていることを確認します。
Azure Functions を使用して Azure Monitor アクション グループで使用できる唯一のオプションは、Function レベルの認証です。
関数をサードパーティのアプリケーションまたはサービスから呼び出す必要がある場合は、API Management レイヤーを使用してアクセスを提供することをお勧めします。 このレイヤーでは、認証を強制します。 API Management には、Azure Functions と統合された従量課金レベルがあります。これにより、API が実行された場合にのみ支払いを行うことができます。 詳細については、「OpenAPI を使用して関数を作成して公開する」をご覧ください。
呼び出し元のサービスでサービス エンドポイントまたはプライベート リンクがサポートされている場合は、次に示すコストの高いオプションを検討できます。
- 専用の App Service プランを使用します。これにより、仮想ネットワーク内の関数をロック ダウンして、アクセスを制限できます。 これは、使用量ベースのサーバーレス モデルでは実現できません。
- Azure Functions Premium プランを使用します。これには、関数アプリで使用される専用の仮想ネットワークが含まれます。
これらのオプション間の価格と機能を比較するには、「Azure Functions のスケールとホスティング」をご覧ください。
関数がアクセスできる内容を制御する
Azure リソースのマネージド IDは、Microsoft Entra の機能であり、関数が他の Azure リソースやサービスに対して認証を行い、アクセスする方法を簡略化します。 認証資格情報は、Microsoft Entra ID によって管理されているため、コードが管理する必要はありません。
マネージド ID には、次の 2 種類があります。
システム割り当てマネージド ID:これらは Azure リソースの一部として作成され、複数のリソース間で共有することはできません。 これらは、リソースが削除されると削除されます。 これらは、単一の Azure リソースを含むか、独立した ID を必要とするシナリオに使用します。 どちらのシナリオでも、1 つのリソースのみが更新されるため、システム割り当て ID が使用されます。 マネージド ID は、別のリソースを更新する場合にのみ必要です。 たとえば、関数は、マネージ ID を使用せずにリソースタグを読み取ることができます。 システムによって割り当てられた ID を関数に追加するには、次の手順を参照してください。
ユーザー割り当て済みマネージド ID:これらはスタンドアロンの Azure リソースとして作成されます。 これらは複数のリソース間で共有でき、必要なくなったときには明示的に削除する必要があります。 ユーザー割り当て ID を関数に追加する方法については、これらの手順を参照してください。 次のようなシナリオで使用します。
- 1 つの ID を共有できる複数のリソースへのアクセスが必要な場合
- プロビジョニング中にリソースをセキュリティで保護するための事前承認が必要な場合
- リソースが頻繁にリサイクルされるものの、アクセス許可は一貫性を保つ必要がある場合
Azure 関数に ID が割り当てられたら、Azure ロールベースのアクセス制御 (Azure RBAC) を使用してリソースにアクセスするロールを割り当てます。 たとえば、リソースを更新するには、"共同作成者" ロールを関数の ID に割り当てる必要があります。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
コストの見積もりには、Azure 料金計算ツールをご利用ください。 コスト削減のためのいくつかの考慮事項を次に示します。
Azure Logic Apps
Logic Apps には従量課金制の価格モデルがあります。 トリガー、アクション、およびコネクタの実行は、ロジック アプリを実行するたびに課金されます。 トリガーを含め、成功したアクションと失敗したアクションすべてが実行と見なされます。
Logic Apps には、固定価格モデルもあります。 Azure 仮想ネットワークで、セキュリティで保護されたリソースと通信するロジック アプリを実行する必要がある場合は、それを統合サービス環境 (ISE) で作成できます。
詳細については、「Azure Logic Apps の価格モデル」を参照してください。
このアーキテクチャでは、ロジック アプリが、コスト センターのタグ付けシナリオでワークフローの調整に使用されます。
組み込みコネクタを使用して Azure Functions に接続され、オートメーション タスクが完了した時点で電子メール通知が送信されます。 関数は、HTTP/API トリガーを使用して、Web hook/API として公開されます。 Logic Apps は、HTTPS 要求が発生した場合にのみトリガーされます。 関数によってポーリングが継続的に行われ、特定の条件が確認される設計と比較すると、この方法はコスト効率に優れています。 すべてのポーリング要求が、アクションとして課金されます。
詳細については、「Logic Apps の価格」をご覧ください。
Azure Functions
Azure Functions は、次の 3 つの価格プランでご利用いただけます。
従量課金プラン。 これは最もコスト効率の高いサーバーレス プランで、お客様の関数が実行されていた時間に対してのみ課金されます。 このプランでは、一度に最大 10 分間関数を実行できます。
Premium プラン。 自動化シナリオに、実行時間が長い、専用仮想ネットワークなどの追加要件がある場合は、Azure Functions Premium プランを使用することを検討してください。 これらの関数は、最大 1 時間実行できます。バックアップ実行、データベースのインデックス作成、レポート生成など、自動化タスクに時間がかかる場合は、このプランを選択する必要があります。
App Service プラン。 Azure App Service ハイブリッド接続を使用するハイブリッド自動化のシナリオでは、App Service プランを使用する必要があります。 このプランで作成された関数は、Web アプリと同様、実行時間に制限はありません。
これらのオートメーション シナリオでは、Azure Functions は、Microsoft Entra ID でタグを更新したり、RU をより高い値にスケールアップして Azure Cosmos DB の構成を変更したりするなどのタスクに使用されます。 これらのタスクは対話型であり、長時間実行されるものではないため、このユース ケースには従量課金プランが適しています。
Azure Cosmos DB
Azure Cosmos DB では、プロビジョニングされたスループットと消費されたストレージに対して時間単位で課金されます。 プロビジョニングされたスループットは要求ユニット/秒 (RU/秒) で表され、挿入、読み取りなどの一般的なデータベース操作に使用できます。 ストレージへの課金は、格納データとインデックスに使用される GB ごとに行われます。 詳細については、「Azure Cosmos DB の価格」を参照してください。
このアーキテクチャでは、Azure Cosmos DB へのデータ アクセス要求が、要求ユニット (RU) の容量を超えると、Azure Monitor によってアラートがトリガーされます。 このアラートに応答してオートメーション関数を呼び出すように、Azure Monitor アクション グループが構成されています。 関数は、RU を高い値にスケーリングします。 ワークロードで必要とされるリソースに対してのみ、時間単位で課金されるため、これはコストを抑え続けるうえで役に立ちます。
ワークロードのコストをすばやく見積もるには、Azure Cosmos DB 容量計算ツールを使用します。
詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。
デプロイに関する考慮事項
アプリケーションの動作を管理する重要なオートメーション ワークフローでは、効率的な DevOps パイプラインを使用してダウンタイムなしのデプロイを達成する必要があります。 詳細については、「サーバーレス バックエンドのデプロイ」をご覧ください。
オートメーションが複数のアプリケーションを対象としている場合は、オートメーションに必要なリソースを別のリソース グループに保持します。 オートメーションが単一のアプリケーションを対象とする場合、1 つのリソース グループをオートメーションとアプリケーション リソース間で共有できます。
ワークフローに多数のオートメーション関数が含まれている場合は、関数をグループ化して 1 つの関数アプリで 1 つのシナリオに対応します。 詳細については、「Function App を管理する」をご覧ください。
アプリケーションをデプロイしたら、それを監視する必要があります。 Application Insights を使用して、開発者がパフォーマンスを監視し、問題を検出できるようにすることを検討してください。
詳細については、「Microsoft Azure Well-Architected Framework」の DevOps のセクションを参照してください。
Azure リソースに対する命令型アクション
上記のいずれのシナリオでも、最終的に、Azure Resource Manager の直接の対話によって Azure リソースの状態が変更されました。 これは意図された結果でしたが、変更されたリソースが Bicep や Terraform テンプレートにより、もともと宣言によってデプロイされていた場合、それを実行した場合の環境への影響を考慮してください。 これらの変更がソース テンプレートに再びレプリケートされない限り、これらのテンプレートを次回使用すると、このオートメーションによって行われた変更が元に戻る可能性があります。 通常はテンプレートを使用してデプロイされている Azure リソースに、命令型の変更を混在させた場合の影響について検討してください。
このシナリオのデプロイ
コスト センターのシナリオをデプロイするには、GitHub 上のデプロイの手順を参照してください。