Azure でのミッション クリティカルなワークロードの操作
他のアプリケーションと同様に、ミッション クリティカルなワークロードでも変更が発生します。 アプリケーションは時間の経過と同時に進化し、キーの有効期限が切れ、パッチがリリースされます。 すべての変更とメンテナンスは、デプロイ パイプラインを使用して適用する必要があります。 この記事では、一般的な変更と更新を行う操作に関するガイダンスを提供します。
組織の配置は、操作手順でも同様に重要です。 ミッション クリティカルなワークロードの運用が成功するためには、エンド ツー エンドの責任が 1 つのチームである DevOps チーム内に収まるようにすることが重要です。
技術的な実行では、Azure ネイティブ プラットフォームの機能と、自動化された Azure Pipelines を使用して、アプリケーション、インフラストラクチャ、および構成に変更をデプロイする必要があります。 ここでも、メンテナンス タスクを自動化し、手動タスクを回避する必要があります。
次のセクションでは、さまざまな種類の変更を処理する方法について説明します。
アプリケーションの自動化
継続的インテグレーションと継続的デプロイ (CI/CD) により、ミッション クリティカルなワークロードの適切なデプロイと検証が可能になります。 CI/CD は、環境、開発/テスト、運用環境などに変更をデプロイする場合に推奨されるアプローチです。 ミッション クリティカルなワークロードの場合、次のセクションに示す変更により、まったく新しいスタンプがデプロイされます。 新しいスタンプは、青/緑のデプロイ戦略を使用してスタンプにトラフィックがルーティングされる前に、リリース プロセスの一環として徹底的にテストする必要があります。
以下のセクションでは、CI/CD を使用して、可能な場合に実装する必要がある変更について説明します。
アプリケーションの変更
アプリケーション コードに対するすべての変更は、CI/CD を使用してデプロイする必要があります。 コードはビルドされ、リンティングされ、回帰テストを行う必要があります。 ランタイム環境やパッケージなどのアプリケーションの依存関係を監視し、CI/CD 経由で更新プログラムをデプロイする必要があります。
インフラストラクチャの変更
インフラストラクチャをモデル化し、コードとしてプロビジョニングする必要があります。 この方法は、一般に、コードとしてのインフラストラクチャ (IaC) と呼ばれます。 IaC に対するすべての変更は、CI/CD パイプラインを通じてデプロイする必要があります。 OS の修正プログラムの適用など、インフラストラクチャの更新も CI/CD パイプライン経由で管理する必要があります。
構成の変更
構成の変更は、アプリケーションの停止の一般的な原因です。 このような障害に対処するには、アプリケーションまたはインフラストラクチャの構成をコードとしてキャプチャする必要があります。 この方法は、コードとしての構成 (CaC) と呼ばれます。 CaC への変更は、CI/CD パイプラインを使用してデプロイする必要があります。
ライブラリ/SDK の更新
ミッション クリティカルなアプリケーションでは、新しいバージョンが利用可能になったときにソース コードと依存関係を更新することが重要です。 推奨される方法は、ソース コード リポジトリの構成管理変更プロセスを利用することです。 次のようなさまざまな依存関係の更新に対して Pull Request を自動的に作成するように構成する必要があります。
- .NET NuGet パッケージ
- JavaScript ノード パッケージ マネージャー パッケージ
- Terraform プロバイダー
次のシナリオは、GitHub リポジトリ dependabot を使用してライブラリの更新を自動化する例です。
Dependabot は、アプリケーション コードで使用されるライブラリと SDK の更新を検出します
Dependabot は、ブランチ内のアプリケーション コードを更新し、メイン ブランチに対してこれらの変更を含むプル要求 (PR) を作成します。 PR にはすべての関連情報が含まれており、最終レビューの準備ができています。
コード レビューとテストが完了すると、PR をメイン ブランチにマージできます。
依存関係の dependabot が監視できない場合は、新しいリリースを検出するプロセスがあることを確認してください。
キー/シークレット/証明書のローテーション
キーとシークレットのローテーション (更新) は、どのワークロードでも標準的な手順である必要があります。 シークレットは、公開された後、または適切なセキュリティプラクティスとして定期的に変更する必要がある場合があります。
期限切れまたは無効なシークレットは、アプリケーションの (エラー分析を参照)の停止を引き起こす可能性があるため、明確に定義された実証済みのプロセスを実施することが重要です。 Azure Mission-Critical の場合、スタンプの有効期間は数週間のみです。 そのため、スタンプ リソースのシークレットをローテーションすることは問題ではありません。 1 つのスタンプ内のシークレットの有効期限が切れると、アプリケーション全体が引き続き機能します。
ただし、有効期間の長いグローバル リソースにアクセスするためのシークレットの管理は重要です。 注目すべき例は、Azure Cosmos DB API キーです。 Azure Cosmos DB API キーの有効期限が切れると、すべてのスタンプが同時に影響を受け、アプリケーションが完全に停止します。
次のアプローチは、Azure Kubernetes Service で実行されているサービスにダウンタイムを発生させずに Azure Cosmos DB キーをローテーションするための、Azure ミッション クリティカルなテスト済みおよび文書化されたアプローチです。
セカンダリ キーを使用してスタンプを更新します。 既定では、Azure Cosmos DB のプライマリ API キーは、各スタンプの Azure Key Vault にシークレットとして格納されます。 セカンダリ Azure Cosmos DB API キーを使用する IaC テンプレート コードを更新する PR を作成します。 この変更は、通常の PR レビューと更新の手順で実行し、新しいリリースまたは修正プログラムとして展開します。
(省略可能)更新プログラムが既存のリリースの修正プログラムとしてデプロイされた場合、ポッドは数分後に Azure Key Vault から新しいシークレットを自動的に取得します。 ただし、Azure Cosmos DB クライアント コードは現在、変更されたキーで再初期化されません。 この問題を解決するには、クラスターで次のコマンドを使用して、すべてのポッドを手動で再起動します。
kubectl rollout restart deployment/CatalogService-deploy -n workload kubectl rollout restart deployment/BackgroundProcessor-deploy -n workload kubectl rollout restart deployment/healthservice-deploy -n workload新しくデプロイまたは再起動されたポッドでは、Azure Cosmos DB への接続にセカンダリ API キーが使用されるようになりました。
すべてのスタンプのすべてのポッドが再起動されるか、新しいスタンプがデプロイされたら、Azure Cosmos DB のプライマリ API キーを再生成します。 コマンドの例を次に示します。
az cosmosdb keys regenerate --key-kind primary --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup今後のデプロイにプライマリ API キーを使用するように IaC テンプレートを変更します。 または、セカンダリ キーを引き続き使用し、セカンダリを更新するときにプライマリ API キーに切り替えることもできます。
アラート
アラートは、環境に問題があるかどうかを理解するための鍵となります。 アラートやアクション グループに対する変更は、CI/CD パイプラインを使用して実装する必要があります。 アラートの詳細については、Azureでのミッション・クリティカル ワークロードの正常性モデリングと可観測性に関する
オートメーション
Azure で実行されている多くのプラットフォームとサービスは、一般的な運用アクティビティに自動化を提供します。 この自動化には、自動スケーリングと、キーと証明書の自動処理が含まれます。
Scaling
アプリケーション設計の一環として、スタンプ全体のスケール ユニットを定義するスケール要件を決定する必要があります。 スタンプ内の個々のサービスは、ピーク時の需要を満たすためにスケールアウトしたり、スケールインしてコストやリソースを節約したりできる必要があります。
十分なリソースがないサービスでは、次の一覧を含め、さまざまな副作用が生じます。
- キュー/アーティクル/パーティションからのメッセージを処理するポッドの数が不足すると、未処理のメッセージが増えます。 この結果は、キューの深さの増加と呼ばれることもあります。
- Azure Kubernetes Service ノードのリソースが不足すると、ポッドを実行できなくなる可能性があります。
- 以下の結果により、要求が調整されます。
- Azure Cosmos DB の要求ユニット (RU) が不十分
- Event Hubs Premium の処理ユニット (PU) または Standard のスループットユニット (TU) が不十分です。
- Service Bus Premium レベルのメッセージング ユニット (RU) が不十分
可能であれば、サービスの自動スケール機能を利用して、需要を満たすのに十分なリソースを確保します。 利用できる自動スケーリング機能を次に示します。
- ポッドの水平自動スケール を使用すると、需要に応じて、ワークロードを実行しているポッドの数を増減できます。
- AKS クラスター オートスケーラー を使用すると、需要に応じてクラスター内のノード数を増減できます。
- Azure Event Hubs のスループットユニット（標準レベル）を自動的にスケールアップできます
- Azure Service Bus 名前空間のメッセージングユニットを自動的に更新することができます
キー、シークレット、証明書の管理
API キーやパスワードなどのシークレットを管理する必要がないように、可能な場合はマネージド ID を使用します。
キー、シークレット、または証明書を使用している場合は、可能な限り Azure ネイティブ プラットフォーム機能を使用します。 これらのプラットフォーム レベルの機能の例を次に示します。
- Azure Front Door には、TLS 証明書の管理と更新のための組み込みの機能があります。
- Azure Key Vault では、キーの自動ローテーションがサポートされています。
手動操作
手動による介入を必要とする運用アクティビティがあります。 これらのプロセスをテストする必要があります。
配信不能メッセージ
処理できないメッセージは、予めアラートが設定されたデッドレターキューにルーティングする必要があります。 通常、これらのメッセージには、問題を理解して軽減するために手動による介入が必要です。 配信不能メッセージを表示、更新、再生できる機能を作る必要があります。
Azure Cosmos DB の復元
Azure Cosmos DB データが意図せずに削除、更新、または破損した場合は、定期的なバックアップから復元を実行する必要があります。 定期的なバックアップからの復元は、サポート ケースでのみ実行できます。 このプロセスは文書化し、定期的にテストする必要があります。
クォータの増加
Azure サブスクリプションにはクォータ制限があります。 これらの制限に達すると、デプロイが失敗する可能性があります。 一部のクォータは調整可能です。 調整可能なクォータについては、Azure portal の [マイ クォータ] ページ
重要
運用設計に関する考慮事項と推奨事項については、Azure でのミッション クリティカルなワークロードに関する
貢献者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主な作成者:
- ロブ・バビー |プリンシパル コンテンツ開発者
- アレン スッドブリング |シニア コンテンツ 開発者
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次の手順
参照実装をデプロイして、このアーキテクチャで使用されるリソースとその構成を完全に理解します。