自動化を有効にするための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework Operation Excellence チェックリストの推奨事項に適用されます。

OE:10 ライフサイクルの問題、ブートストラップ、ガバナンスとコンプライアンスガードレールの適用などの運用のための自動化を事前に設計して実装します。 後で自動化をレトロフィットしようとしないでください。 プラットフォームで提供される自動化機能を選択します。

このガイドでは、自動化を有効にするためにワークロードを設計および実装するための推奨事項について説明します。 リソースのプロビジョニング、スケーリング、デプロイなどの日常的なタスクが迅速かつ確実に実行されるように、自動化を念頭に置いてワークロードを設計します。 自動化により、メンテナンス タスクが簡素化され、システムの更新、修正プログラムの適用、アップグレードをより効率的に行うことができます。

主要な設計戦略

ワークロード設計

アイデアフェーズから進行中の改善フェーズまでの自動化をサポートするようにワークロードを設計できます。 まず、ワークロードに自動化を適用して、必要な部分を確実に配置する方法を検討します。 使用する自動化の種類の計画に役立つ、Well-Architected Framework の柱の観点からワークロードについて考えます。 セキュリティ、信頼性、パフォーマンス、運用、コスト管理の多くの機能を自動化できます。

ワークロードの実行後にリファクタリングを最小限に抑えるために、自動化を念頭に置いて設計します。 使用する自動化ツールを決定するときは、ワークロードの要件を考慮してください。 チームが既に使い慣れている既製の自動化ツールが存在する可能性があります。 これらのツールを採用すると、ワークロードの自動化への道が簡単になりますが、クラウド プラットフォームとの制限と互換性に注意してください。 たとえば、一部の自動化ツールは Azure CLI ツールとうまく統合される場合もあれば、REST インターフェイスを必要とするものもあります。 クラウド プラットフォームが提供するツールを常に調査して、互換性があることを確認し、必要な機能を提供します。 自動化を事前に計画する方法の例を次に示します。

  • デプロイ: アプリケーションとインフラストラクチャのデプロイを自動化して、予測可能な標準を確保します。 デプロイ標準を開発し、使用するツールでチームをトレーニングし、必要なインフラストラクチャを実装することで、自動デプロイを計画します。

  • 検証: オーケストレーションまたはポリシー ツールを使用して、ワークロードに対するコンプライアンス要件を自動的に検証します。 ワークロードに適した検証ツールを特定し、オーケストレーション サーバーなどの必要なシステムを実装することを計画します。

  • 自動スケーリング: インフラストラクチャ全体で自動スケーリングを使用して、信頼性とパフォーマンスの要件を達成します。 冗長性と自然な成長の計画に加えて、スケーリング操作を考慮するために、事前にワークロードに IP アドレス空間とサブネットを割り当てる必要があります。

トレードオフ: 自動化を可能にするようにワークロードを設計する場合は、維持する制御の程度と、自動化によって得られる効率を考慮してください。 場合によっては、ワークロードが一部の機能を自動化するのに十分に成熟していない場合や、自動化で提供されないレベルの柔軟性が必要になる場合があります。

また、ワークロードを設計する際には、チームのスキル セットも考慮してください。 高度な自動化でチームがサポートするツールが必要な場合は、より包括的でない設計を中間ステップとして使用する必要がある場合があります。

継続的なワークロードの改善

ワークロードがクラウドで実行されたら、継続的な改善に優先順位を付ける必要があります。 実際のワークロードを観察し、使用パターンを分析し、ワークロードに関連する顧客の行動を確認して、自動化を改善できる領域を特定します。 既存の自動化を強化したり、新しい自動化を導入してカスタマー エクスペリエンスを向上させる方法を探します。 たとえば、自動スケーリングが有効になっている場合でも、ワークロードの増加は短期間です。 スケールイン自動化を統合して、負荷がしきい値を下回ったときに CPU 使用率を減らすことができます。

このガイドの次のセクションでは、ワークロードの設計と実装に役立つ自動化の特定の領域に関する推奨事項を示します。

ブートストラップ

ブートストラップとは、プロビジョニング後にワークロード プールの一部として使用できるようになる前に行う必要があるリソースの構成更新を指します。 ブートストラップは多くの場合、仮想マシン (VM) に関連付けられますが、サービスとしてのプラットフォーム (PaaS) テクノロジや、Azure Kubernetes Service (AKS) などのコンテナー ホスティング テクノロジなど、他の多くのリソースをデプロイ プロセスの一部として設定する必要があります。

クラウド プラットフォームにはブートストラップ ソリューションが用意されている場合があり、可能な限り使用する必要があります。 たとえば、Azure の VM 拡張機能を使用して、デプロイ プロセス中に定義済みの構成変更を行い、PowerShell スクリプトを挿入して構成の変更をカスタマイズできます。

認証と承認

認証と承認の戦略を設計するときに、自動化を考慮します。 運用環境のワークロードで最高レベルのセキュリティを維持することが重要ですが、これは自動化に影響を与える可能性があります。 たとえば、生体認証や多要素認証を使用すると、自動化設計で考慮する必要がある複雑さが増します。 マネージド ID、ワークロード ID、証明書などの自動認証には、非人間的で安全なアカウントを使用します。 認証セキュリティを強化するために、自動化にシークレットとキーの管理が含まれていることを確認します。

ワークロードの変動性を設計する

成果物に柔軟性を組み込むことで小さな変更が加えられた場合は、新しいインフラストラクチャを不必要にデプロイしないようにします。 たとえば、機能フラグが変更されたときにインフラストラクチャを再デプロイするのではなく、アプリ構成などのコンポーネントを更新するために設定されているパラメーターを使用できます。 過度の使用や構成のずれを避けるために、可変性がどのように使用されるかを明確に定義し、文書化してください。

コントロール プレーンを作成する

コントロール プレーンは、統合インターフェイスを介してアプリケーションとその依存関係を管理するために使用するバックエンド システムまたはツール スイートです。 REST インターフェイス、CLI、Webhook などのコントロール プレーンを構築して、外部ツールによる自動化をサポートします。

メンテナンス操作をコントロール プレーンを介して公開します。これにより、ワークロード コンポーネントを調整できます 。たとえば、順序付けされたバックアップと復元、ブートストラップ、構成、インポート/エクスポート、バッチ処理の操作などです。 コントロール プレーンを介して公開する操作を決定するときは、適切なレベルの粒度を選択するように注意してください。

監視とログ記録

必要な自動化の種類を推進するメトリックをキャプチャするための監視戦略を開発します。 構造化ログとカスタム メトリックを使用して、自動化ツールで認識しやすい形式でオートメーションに必要な情報を提供します。 キャプチャするメトリックは、アラートや自動アクション (通知や自己復旧メカニズムなど) をトリガーする監視システムで定義されているしきい値と、必要に応じてペアにする必要があります。 詳細については、「 自己復旧と自己保存に関する推奨事項」を参照してください。

ユーザー のライフサイクル

アプリケーションとインフラストラクチャを設計して、ユーザーのオンボードとオフボーディングを自動化し、個人またはマルチテナントの顧客に対応できるようにします。 スクリプト、インフラストラクチャのプロビジョニングとプロビジョニング解除、資格情報とシークレットの管理を使用して、自動データベース更新を計画します。

オーケストレーションとポリシーの使用

継続的なワークロード管理の一環として、リソースの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を使用して、新しいリソースを自動的に修復したり、既存のリソースを一括で修復したりすることもできます。

トレードオフ: CI/CD パイプラインからプラットフォーム ツールやサービス (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 ディストリビューション全体で多数のクラウド 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 クラスターをブートストラップする: GitOps と Flux v2 クラスター拡張機能を使用して、新しくプロビジョニングされた AKS クラスターをブートストラップするには、GitHub リポジトリで構成設定を宣言します。 AKS クラスター ファイルは GitHub リポジトリに格納されるため、バージョン管理され、バージョン間の変更を簡単に追跡できます。 Kubernetes コントローラーはクラスターで実行され、リポジトリからファイルをプルすることで、Git リポジトリで宣言された目的の状態でクラスターの状態を継続的に調整します。 詳細については、「 AKS ベースラインリファレンスアーキテクチャ」を参照してください。

構成管理

Azure Automation State Configurationは、Azure Policy ゲスト構成機能によって管理される DSC 管理ツールであり、任意のクラウドまたはオンプレミス のデータセンター内のノードの PowerShell DSC 構成の作成、管理、コンパイルに使用できます。 このツールを使用して DSC リソースをインポートし、ターゲット ノードに構成を割り当てることもできます。

Azure App Configurationは、アプリケーション設定と機能フラグを一元的に管理するために使用できるサービスです。 Azure Key Vaultで動作するため、環境全体でさまざまなアプリケーション構成を安全に管理できます。

変更履歴とインベントリ

Azure Monitoring Agent を使用した変更の追跡とインベントリ は、仮想マシンの OS 構成ドリフトを追跡します。 これにより、ワークロード内の仮想マシン上のドリフト、実行中のサービスのインベントリ、インストールされたパッケージの検出が自動化されます。 変更の追跡とインベントリによって追跡される項目は次のとおりです。

  • インストールされている Windows および Linux ソフトウェア
  • Windows および Linux の主要なファイル
  • Windows レジストリ キー
  • Windows サービスと Linux デーモン

オペレーショナル エクセレンス チェックリスト

推奨事項の完全なセットを参照してください。

オペレーショナル エクセレンス チェックリスト