自動化を有効にするための推奨事項
Azure Well-Architected フレームワークのオペレーション エクセレンスに関するチェックリストの次の推奨事項を対象とします。
| OE:10 | ライフサイクルの問題、ブートストラップ、ガバナンスとコンプライアンスのガードレールの適用などの操作に対し、あらかじめ自動化を設計して実装します。 自動化を後から改良しようとしないでください。 プラットフォームで提供される自動化機能を選択します。 |
|---|
このガイドでは、自動化を有効にするためにワークロードを設計および実装するための推奨事項について説明します。 リソースのプロビジョニング、スケーリング、デプロイなどの日常的なタスクが迅速かつ確実に実行されるように、自動化を念頭に置いてワークロードを設計します。 自動化により、メンテナンス タスクが簡素化され、システムの更新、修正プログラムの適用、アップグレードをより効率的に行うことができます。
主要な設計戦略
自動化をサポートするようにワークロード コンポーネントを設計する
構想のフェーズから進行中の改善フェーズまでの自動化をサポートするようにワークロードを設計できます。 まず、必要な要素を確実に配置するために、ワークロードに自動化を適用する方法を検討します。 Well-Architected フレームワークの柱という観点からワークロードについて考えて、使用する自動化の種類の計画に役立てます。 セキュリティ、信頼性、パフォーマンス、運用、コスト管理の多くの機能を自動化できます。
ワークロードの実行後のリファクタリングを最小限に抑えるために、自動化を念頭に置いて設計します。 使用する自動化ツールを決定するときは、ワークロードの要件を考慮してください。 チームが既に使い慣れている既製の自動化ツールが存在する可能性があります。 このようなツールを採用すると、ワークロードの自動化への道が簡単になる可能性がありますが、クラウド プラットフォームでの制限や互換性に注意してください。 たとえば、一部の自動化ツールは Azure CLI ツールと適切に統合される場合もありますが、その他のツールでは REST インターフェイスが必要な場合もあります。 使用するクラウド プラットフォームが提供するツールを常に調査して、それらに互換性があり、必要な機能が提供されることを確認します。 自動化を事前に計画する方法の例を次に示します。
デプロイ: アプリケーションとインフラストラクチャのデプロイを自動化して、予測可能な標準を確保します。 デプロイ標準を開発し、使用するツールについてチームをトレーニングし、必要なインフラストラクチャを実装することで、自動デプロイを計画します。
検証: オーケストレーション ツールまたはポリシー ツールを使用して、ワークロードに対するコンプライアンス要件を自動的に検証します。 ワークロードに適した検証ツールを特定し、オーケストレーション サーバーなどの必要なシステムを実装することを計画します。
自動スケーリング: インフラストラクチャ全体で自動スケーリングを使用して、信頼性とパフォーマンスの要件を満たすことができます。 冗長性と自然な増加の計画に加えて、スケーリング操作を考慮するために、事前にワークロードに IP アドレス空間とサブネットを割り当てる必要があります。
トレードオフ: 自動化を有効にするようにワークロードを設計するときは、維持する制御の程度と、自動化によって得られる効率のバランスを考慮してください。 場合によっては、ワークロードが一部の機能を自動化するのに十分に成熟していない場合や、自動化で提供されないレベルの柔軟性が必要な場合があります。
また、ワークロードを設計する際には、チームのスキル セットも考慮してください。 高度な自動化を行うのに、チームでサポートされないツールが必要な場合は、中間ステップとしてより包括性の低い設計の使用が必要になる場合があります。
ライフサイクル中に自動化設計を見直す
ワークロードがクラウドで実行されるようになったら、継続的な改善を優先して行うことが重要です。 ワークロードの動作を観察し、使用パターンを分析し、ワークロードに関連する顧客の行動を確認して、自動化を改善できる領域を特定します。 既存の自動化を強化したり、新しい自動化を導入したりしてカスタマー エクスペリエンスを向上させる方法を探します。 たとえば、自動スケーリングを有効にしても、ワークロードの増加の期間が短い場合があります。 スケールイン自動化を統合して、負荷がしきい値を下回ったときに CPU 使用率を減らすことができます。
このガイドの次のセクションでは、ワークロードの設計と実装に役立つ自動化の特定の領域に関する推奨事項を示します。
ブートストラップを自動化する
ブートストラップとは、リソースがプロビジョニングされた後、ワークロード プールの一部として使用できるようになる前に行う必要がある、リソースに対する構成の更新を指します。 ブートストラップは、多くの場合仮想マシン (VM) に関連付けられますが、サービスとしてのプラットフォーム (PaaS) テクノロジや Azure Kubernetes Service (AKS) などのコンテナー ホスティング テクノロジなど、他の多くのリソースをデプロイ プロセスの一部として設定する必要があります。
クラウド プラットフォームにはブートストラップ ソリューションが用意されている場合があり、可能な限り使用する必要があります。 たとえば、Azure の VM 拡張機能を使用して、デプロイ プロセス中に事前定義済みの構成変更を行い、PowerShell スクリプトを挿入して構成の変更をカスタマイズできます。
アクセス管理に自動化を組み込む
認証と承認の戦略を設計するときに、自動化を考慮します。 運用ワークロードで最高レベルのセキュリティを維持することは重要ですが、これは自動化に影響する可能性があります。 たとえば、生体認証または多要素認証を使用すると、自動化設計で考慮が必要な複雑さが増します。 マネージド ID、ワークロード ID、証明書など、自動化された認証には、人間以外のセキュリティで保護されたアカウントを使用します。 認証セキュリティを強化するために、自動化にシークレットとキーの管理が含まれていることを確認します。
ワークロードの変動性を設計する
アーティファクトに柔軟性を組み込むことで、細かい変更が加えられた場合に新しいインフラストラクチャを不必要にデプロイしないようにします。 たとえば、機能フラグが変更されたときにインフラストラクチャを再デプロイするのではなく、アプリ構成などのコンポーネントを更新するために設定されたパラメーターを使用できます。 過度の使用と構成の誤差を回避するために、変動制がどのように使用されるかを明確に定義し、文書化してください。
コントロール プレーンを構築する
コントロール プレーンは、統合インターフェイスを介してアプリケーションとその依存関係を管理するために使用するバックエンド システムまたはツール スイートです。 REST インターフェイス、CLI、Webhook などのコントロール プレーンを構築して、外部ツールによる自動化をサポートします。
コントロール プレーンを介してメンテナンス操作を公開します。これにより、整合性が保たれたバックアップと復元、ブートストラップ、構成、インポート/エクスポート、バッチ処理などのワークロード コンポーネントを調整できます。 コントロール プレーンを介して公開する操作を決定するときは、適切なレベルの細分性を選択するように注意してください。
データドリブン アプローチを採用して自動化を開発する
必要な自動化の種類を推進するメトリックをキャプチャする監視戦略を開発します。 構造化ログとカスタム メトリックを使用して、自動化ツールで簡単に認識できる形式で、自動化に必要な情報を提供します。 キャプチャするメトリックは、アラートをトリガーする監視システムで定義されたしきい値と、必要に応じて通知や self-healing メカニズムなどの自動化されたアクションとペアにする必要があります。 詳細については、「self-healing と自己保存に関する推奨事項」を参照してください。
ユーザー ライフサイクル イベントを自動化する
個人またはマルチテナントの顧客向けに、自動化されたユーザーのオンボードとオフボードを可能にするアプリケーションとインフラストラクチャを設計します。 スクリプト、インフラストラクチャのプロビジョニングとプロビジョニング解除、資格情報とシークレットの管理を使用して、データベースの自動更新を計画します。
Desired State Configuration を自動化する
継続的なワークロード管理の一環として、リソースの Desired State Configuration (DSC) を自動化して、コンプライアンスとビジネス要件を確実に満たすことができます。 DSC オートメーションは、構成の誤差を確実にキャッチし、迅速に修復するのに役立ちます。 オーケストレーション ツールまたはポリシー管理ツールを使用して DSC を自動化できます。 Azure DevOps サービスや Jenkins などのオーケストレーション ツールは、プッシュベースのメカニズムと考えてください。 オーケストレーション ツールを使用すると、手動デプロイや自動デプロイなど、ワークフロー イベントを通じて構成の更新をプッシュアウトできます。 これらの更新は、デプロイ スクリプトで定義されているタスク シーケンスの一部として実行されます。 ポリシー管理ツールはプルベースのメカニズムを使用します。つまり、システムはワークロードの基本レベルで実行され、ワークロードを定期的にポーリングして、定義された DSC に対してその状態を確認します。 ポーリングで不整合または構成の誤差が特定された場合、ツールは是正措置を取ります。 オーケストレーション ツールとポリシー管理ツールを決定するときは、次の要因を考慮してください。
オーケストレーション ツールには、構成の誤差についてワークロードを事前にポーリングするための機能は組み込まれていません。 オーケストレーション ツールは、コードとしてのインフラストラクチャ (IaC) のデプロイと管理の標準を維持するために、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに統合する必要があります。 オーケストレーション ツールを使用する利点は、デプロイ時にリソースが常に完全に構成される点です。
ポリシー管理ツールを使用すると、1 つ以上のリソース グループに影響するポリシーを定義できます。 これらのポリシーは、リソースがポリシー管理システムにチェックインするときに適用されます。 ポリシー管理を使用する利点は、これらのシステムがコード駆動型でないため、チームのオペレーターが導入しやすくなる場合があります。
オーケストレーション ツールとポリシー ツールのどちらを使用するかを決定するときは、新しいリソースに対して行う予定の構成更新をデプロイ時に行う必要があるかどうかを検討します。 また、コードで更新を定義することが、運用プラクティスに適合するかどうかと、デプロイする予定のリソースの種類の数も検討してください。 各種類のリソースに異なる構成が多数ある場合は、ポリシー ツールを使用すると、更新を簡単に管理できる場合があります。
Azure ファシリテーション
ポリシー管理
Azure Policy: Azure Policy を使用すると、標準の適用とコンプライアンス評価を大規模に行えます。 Azure Policy には、コンプライアンス ダッシュボードでワークロード環境の全体的な状態を評価するための集計ビューが用意されています。 または、Azure Policy を使用して、各リソースとポリシーを詳細なレベルで評価できます。 Azure Policy を使用して、新しいリソースを自動的に修復したり、既存のリソースを一括で修復したりすることもできます。
ブートストラップの自動化
Azure Virtual Machines 機能拡張: Virtual Machines の拡張機能は、VM でデプロイ後の構成と自動化を実行する小さなパッケージです。 スクリプトの実行、マルウェア対策ソリューションの構成、ログ記録ソリューションの構成など、さまざまな構成タスクで使用できる拡張機能がいくつかあります。 Azure Resource Manager テンプレート、Azure CLI、Azure PowerShell モジュール、または Azure portal を使用して、VM にこれらの拡張機能をインストールして実行します。 各 VM には、拡張機能のライフサイクルを管理する VM エージェントがインストールされています。
通常、VM 拡張機能はカスタム スクリプト拡張機能を使用して、VM または Azure Virtual Machine Scale Sets でのソフトウェアのインストール、コマンドの実行、構成を行います。 これらの拡張機能は、Azure VM エージェントを使用して新しい VM で実行されるように、IaC デプロイの一部として実行されるように設定できます。 拡張機能は、Azure CLI、PowerShell モジュール、または Azure portal を使用して、Azure デプロイの外部で実行することもできます。
cloud-init: cloud-init は、最初の起動時に Linux VM を構成するための業界ツールです。 Azure カスタム スクリプト拡張機能と同様に、cloud-init を使用すると、Linux VM にパッケージをインストールしてコマンドを実行できます。 cloud-init は、ソフトウェアのインストール、システム構成、コンテンツのステージングに使用できます。 Azure には、既知の Linux ディストリビューションにわたって多数の cloud-init 対応 VM イメージが含まれています。 完全な一覧については、Azure での VM に対する cloud-init のサポートの説明を参照してください。
Azure デプロイ スクリプト リソース: Azure を使用してデプロイする場合、ユーザー アカウント、Kubernetes ポッドの管理をブートストラップしたり、Azure 以外のシステムからデータを照会したりするために、任意のコードを実行することが必要になる場合があります。 これらの操作はいずれも Azure コントロール プレーンを介してアクセスできないため、別のメカニズムが必要です。 詳細については、「Microsoft.Resources deploymentScripts」を参照してください。 他の Azure リソースと同様に、デプロイ スクリプト リソースには次の特徴があります。
Azure Resource Manager テンプレートで使用できます。
他のリソースの Azure Resource Manager テンプレートの依存関係が含まれています。
入力を使用し、出力を生成します。
認証にユーザー割り当てマネージド ID を使用します。
デプロイするとき、デプロイ スクリプトは、PowerShell または Azure CLI のコマンドとスクリプトを実行します。 スクリプトの実行とログ記録は、Azure portal または Azure CLI と PowerShell モジュールで確認できます。 スクリプトの失敗後に、実行環境、タイムアウト オプション、リソース管理の変数をカスタマイズできます。
GitOps を使用した AKS クラスターのブートストラップ: GitHub リポジトリで構成設定を宣言することで、GitOps と Flux v2 クラスター拡張機能を使用して、新しくプロビジョニングされた AKS クラスターをブートストラップできます。 AKS クラスター ファイルは GitHub リポジトリに格納されるため、バージョン管理され、バージョン間の変更を簡単に追跡できます。 Kubernetes コントローラーはクラスターで実行され、Git リポジトリからファイルをプルすることで、リポジトリで宣言されている必要な状態でクラスターの状態を継続的に調整します。 詳細については、AKS ベースライン リファレンス アーキテクチャに関するページを参照してください。
構成管理
Azure Automation State Configuration は、Azure Policy ゲスト構成機能によって管理される DSC 管理ツールです。これは、任意のクラウドまたはオンプレミスのデータセンター内のノードに対する PowerShell DSC 構成の作成、管理、コンパイルに使用できます。 このツールを使用して、DSC リソースをインポートし、ターゲット ノードに構成を割り当てることもできます。
Azure App Configuration は、アプリケーション設定と機能フラグを一元的に管理するために使用できるサービスです。 Azure Key Vault で動作するため、環境全体でさまざまなアプリケーション構成を安全に管理できます。
変更履歴とインベントリ
Azure Monitoring Agent を使用した変更履歴とインベントリでは、Azure VM と Arc 対応 VM の両方で OS 構成の誤差を追跡します。 ワークロード内の誤差、インベントリの実行中のサービス、仮想マシンにインストールされているパッケージの検出を自動化します。 変更履歴とインベントリによって追跡される項目には次のものがあります。
- インストールされている Windows および Linux ソフトウェア
- 主要な Windows ファイルと Linux ファイル
- Windows レジストリ キー
- Windows サービスと Linux デーモン
関連リンク
- AKS ベースライン リファレンス アーキテクチャ
- Azure App Configuration
- Azure Automation State Configuration
- Azure Policy
- Azure での VM の cloud-init のサポート
- AKS および Azure Arc 対応 Kubernetes を使用した GitOps Flux v2 構成
- Microsoft.Resources deploymentScripts
- self-healing と自己保存に関する推奨事項
オペレーショナル エクセレンス チェックリスト
レコメンデーションの完全なセットを参照してください。