運用タスクを最適化するためのアーキテクチャ戦略

この Azure Well-Architected Framework のパフォーマンス効率チェックリストの推奨事項に適用されます。

このガイドでは、運用タスクを最適化するための推奨事項について説明します。 運用タスクの最適化は、日常的なワークロード操作の一部として実行するタスクの影響を最小限に抑えるプロセスです。 運用アクティビティでは、ワークロード自体と同じコンピューティング リソースが使用されます。 運用タスクの影響を考慮しないと、ワークロードのパフォーマンス目標が見逃される可能性があります。 また、顧客のワークロードのパフォーマンスに悪影響を及ぼす可能性もあります。

定義

ソフトウェア開発ライフサイクルやその他の日常的な操作がワークロードのパフォーマンスに及ぼす影響を軽減するための対策を講じる必要があります。 目標は、ウイルス スキャン、シークレット ローテーション、バックアップ、インデックスの最適化 (再編成または再構築)、デプロイなどの日常的な操作によって、ワークロードのパフォーマンスが大幅に低下しないようにすることです。

運用タスクへの対応

パフォーマンス目標を設定するときは、運用タスクを検討することが重要です。 定期的なタスク、定期的なタスク、およびアドホック タスクをパフォーマンス ターゲットに組み込むことで、ワークロードが効率的に動作することを確認できます。 パフォーマンス 目標の運用タスクを考慮するために、考慮すべきいくつかの重要なポイントを次に示します。

• 運用タスクを特定します。 パフォーマンス 目標に関連する運用タスクを特定して含めます。 日常的なタスクの例としては、ウイルス スキャン、データベース インデックスの再編成、データベース インデックスの再構築、ディスクまたはデータベースのバックアップ、証明書のローテーション、オペレーティング システムの修正プログラムの適用、パスワードのローテーション、API キーのローテーション、侵入テスト、運用環境での監査レビューなどがあります。

• パフォーマンス目標を評価します。 現在のパフォーマンス目標を評価し、ワークロードに固有の運用タスクを考慮するように調整します。 これにより、パフォーマンスターゲットがワークロードの運用要件に合うようにします。

デプロイを最適化する

デプロイの最適化とは、シームレスなパフォーマンスと最小限の中断を保証するために、リソースとコードを解放するプロセスを調整することです。 ライブ環境に導入される前に、コードとしてのインフラストラクチャ (IaC) とアプリケーション コードの両方の計画、効果的なリソース分散、および徹底的なテストが含まれます。 デプロイの不備により、ワークロードの速度と効率が低下し、リソースの制約が発生する可能性があり、運用設定でのユーザー エクスペリエンスが損なわれる可能性があります。 デプロイを最適化するには、次の戦略を検討してください。

許容されるダウンタイムを評価します。 ダウンタイムが許容される場合は、速度と効率に優先順位を付けるデプロイ戦略を実装できます。 ただし、その決定を行う前に、ダウンタイムがビジネス要件に与える影響を慎重に評価することが重要です。 一方、ダウンタイムが許容できない場合は、ワークロードの継続的な可用性を確保するデプロイ戦略を実装する必要があります。 ブルーグリーンデプロイやカナリアデプロイなどの手法を使用することを検討してください。ここで、問題を監視しながら、ワークロードの新しいバージョンを段階的にロールアウトします。 これらの戦略は、ダウンタイムの影響を最小限に抑え、シームレスなユーザー エクスペリエンスを確保するのに役立ちます。

現在のインスタンス数でデプロイします。 また、すぐにスケール操作が発生するデプロイは避ける必要があります。 インスタンス数が非常に少ないライブ システムにリソースをデプロイしないでください。そのため、システムはスケール操作をすぐに実行するように強制されます。 たとえば、コードとしてのインフラストラクチャ (IaC) テンプレートが、デプロイ時に必要なインスタンスの数と一致しない場合があります。 現在デプロイされている環境で 8 つのインスタンスが実行されている場合でも、インスタンス数が 2 である可能性があります。 デプロイによって 6 つのインスタンスが削除され、パフォーマンスに悪影響が及びます。

青緑色のデプロイ戦略を使用します。 デプロイにより、サービスの中断とダウンタイムが発生する可能性があります。 これらの問題を軽減するには、ブルーグリーンデプロイなどのパフォーマンスへの影響を最小限に抑えるデプロイ戦略を選択します。 これらのアプローチにより、環境間のシームレスな移行が可能になり、サービスの中断のリスクが軽減されます。 ブルーグリーンデプロイアプローチを使用する場合、青と緑の環境という 2 つの異なる環境があります。 緑の環境で問題やパフォーマンスの低下が検出された場合は、安定した青色の環境に簡単にロールバックできます。 この戦略は、ダウンタイムを最小限に抑え、ワークロードの高レベルのパフォーマンスを維持するのに役立ちます。 ブルーグリーン アプローチを使用してデプロイするには、次の一般的な手順に従います。

• 新しい環境をデプロイします。 アプリケーションの更新バージョンを使用して、既存の環境 (青) と共に新しい環境 (緑) を設定します。

• 新しい環境を検証します。 デプロイでは、待機時間が発生し、応答時間が長くなる可能性があります。 一括移行の前に、インスタンスの事前ウォーミングを検討してください。 事前ウォーミングでは、運用環境に似たトラフィックとワークロードをシミュレートして新しい環境を準備し、環境が予想される負荷を処理する準備ができていることを確認します。 待機時間と応答時間への影響を最小限に抑えるのに役立ちます。 新しい環境を十分にテストして検証し、正しく機能し、パフォーマンスの期待を満たしていることを確認します。 テストは、キャッシュをウォームアップし、データベース接続を確立し、環境が予想される負荷を処理する準備ができていることを確認するのに役立ちます。

• トラフィックを徐々にシフトします。 新しい環境が事前に警告および検証されたら、生産トラフィックを古い環境 (青) から新しい環境 (緑) に徐々にシフトします。 最初は、トラフィックのごく一部を緑の環境に向け、その安定性と予想されるアプリケーションの正常性を確認した後、徐々に増やします。 グローバル ロード バランサーまたはトラフィック管理メカニズムを使用できます。 制御されたトラフィックシフトを使用すると、ワークロードを新しい環境に完全に移行する前に、パフォーマンスの問題を早期に特定し、是正措置を講じることができます。

• 監視と最適化。 デプロイでは、共有コンピューティング リソースが使用される場合があります。 トラフィックをシフトした後、新しい環境のパフォーマンスと正常性を継続的に監視します。 必要な最適化や調整を行って、必要なパフォーマンスとユーザー エクスペリエンスを確保します。

• 古い環境を削除します。 すべてのトラフィックを緑色の環境に正常に移行したら、既存の接続から青い環境を削除します。 この手順は、古い環境を維持するコストを最適化し、新しい環境に構成の誤差がないことを保証するのに役立ちます。

• プロセスを繰り返します。 今後のデプロイでは、青と緑の環境の役割を逆にします。 新しい青い環境に変更をデプロイし、検証し、トラフィックの移行を調整し、古い緑の環境を使用停止します。

複数のビルドを使用します。 ビルドの種類が異なれば、ビルド時間を最適化し、デプロイの品質を確保できます。 たとえば、すべてのコード コミットでトリガーされる継続的インテグレーション (CI) ビルドを作成できます。 自動テストを定期的に実行する夜間ビルドと、運用環境へのデプロイに使用されるリリース ビルドを用意できます。 ビルドの種類ごとに、継続的インテグレーション、自動テスト、運用デプロイなどの特定の目的が必要です。 デプロイ前のワークロードのテストと検証は、開発プロセスの早い段階で問題やバグを特定して対処するのに役立ちます。

機能フラグを検討してください。 機能フラグは、アプリケーション内の特定の機能の可視性と動作を制御するために、ソフトウェア開発で使用されます。 機能フラグを使用すると、開発者はアプリケーションを再デプロイしなくても、特定の機能を有効または無効にすることができます。 機能フラグは、機能を有効にするか無効にするかを決定する条件付きロジックをコードに導入することによって機能します。 このロジックは、ユーザー ロール、ユーザー設定、開発チームによって定義された特定の条件など、さまざまな要因に基づくことができます。 機能フラグを使用することで、開発者は新しい機能をユーザーのサブセットに徐々にロールアウトしたり、テスト (カナリア テスト) のために特定のグループの機能を有効にしたりできます。

アップグレードを最適化する

インプレース アップグレードは、既存のリソースまたはアプリケーションへのアップグレードです。 インプレース アップグレードでは、一時的に速度が低下したり、ワークロードが中断されたりする可能性があります。 アップグレードがワークロードと互換性があることを確認することが重要です。 アップグレードを適用する前に、別の環境でテストして潜在的な問題を特定することをお勧めします。 アップグレード プロセス中に問題が発生した場合に備えて、ロールバック計画を提供します。 アップグレードを適用する前に、重要なデータと構成の完全バックアップを作成することが重要です。 アップグレード後にアップグレードされたシステムを注意深く監視して、すべてが期待どおりに機能することを確認します。 バックアップを使用すると、必要に応じて適切な状態に復元できます。 ユーザーとワークロードのパフォーマンスへの影響を最小限に抑えるために、ピーク時以外の時間帯にアップグレードのスケジュールを設定する必要があります。 予想されるダウンタイムや必要なアクションなど、計画されたアップグレードについて事前にユーザーに通知します。

トレードオフ: ピーク外の時間帯に操作アクティビティを実行するのを待機すると、運用効率に影響を与える可能性があります。 ピーク外の時間帯に適切なスキル セットを持つ担当者の作業を行う方が便利ではない場合があります。

ツールの最適化

ファイル整合性の監視、ウイルス スキャン、侵入検出、その他の運用タスクに不可欠なツールは、ワークロードのパフォーマンスに影響を与える可能性があります。 コンピューティング リソースを消費し、待機時間とパフォーマンスのオーバーヘッドを増やすことができます。 ツールがワークロードのパフォーマンスに与える影響をテストして理解する必要があります。 テスト結果に基づいて、ツールの構成を微調整し、スキャン頻度を調整し、コンピューティング リソースを再割り当てする必要があります。 ウイルス スキャンの場合は、関連する除外リストを作成して、スキャンの期間を最小限に抑えることができます。

データベース操作を最適化する

データベース操作の最適化とは、最大限の効率と最小限のリソース使用率を確保するために、データベース タスクを調整および微調整するプロセスを指します。 これらの操作には、バックアップ、スキーマの変更、パフォーマンスチューニング、監視などのタスクが含まれます。 効率的なデータベース操作により、クエリ応答の高速化、システムオーバーヘッドの削減、全体的なスムーズなユーザー エクスペリエンスが実現します。

スキーマの変更には、テーブル、列、インデックスの追加や変更など、データベースの構造の変更が含まれます。 これらの変更により、デプロイ プロセス中に追加の処理とリソース使用率が必要になり、ワークロードの全体的なパフォーマンスに影響する可能性があります。 スキーマの変更により、アクティブなクエリ、インデックス、またはトランザクションのパフォーマンスが低下したり、データが使用できなくなる可能性があります。

これらの影響を最小限に抑えるには、非運用環境でのスキーマ変更を計画してテストする必要があります。 スキーマの更新を実装するには、さまざまなデプロイ手法を使用できます。 また、プロセスを最適化するために、使用可能なスキーマ変更ツールを使用する必要があります。 データのアーカイブとパーティション分割は、スキーマ変更の影響を軽減するのに役立ちます。

バックアップを最適化する

バックアップでは、処理能力、ネットワーク帯域幅、ディスク I/O などのワークロード リソースが消費されます。 これらの影響を最小限に抑えるバックアップ戦略をテストして選択する必要があります。 可能な場合は、ピーク時以外の時間帯にバックアップを実行する必要があります。 戦略には、毎回完全バックアップではなく増分バックアップを含める必要があります。 スナップショットは、バックアップよりもリソースを消費する量が少なくなる可能性があります。 カスタム ソリューションを構築するのではなく、組み込みのプラットフォームのバックアップと復元機能を検討する必要があります。 これらのオプションをテストし、ワークロードに最適なパフォーマンスを提供する組み合わせを使用する必要があります。

監視とデバッグを最適化する

過剰または実装が不十分なログ記録、テレメトリ、インストルメンテーション、分散トレースのキャプチャと収集は、パフォーマンスに影響を与える可能性があります。 同様に、リモート デバッグなどの便利な機能もパフォーマンスに影響する可能性があります。 環境に対するパフォーマンスの影響を測定して把握する必要があります。 これらのプロセスでパフォーマンスを低下させたくない。 パフォーマンス効果が利点を上回るプロセスを構成または無効にする必要があります。

Azure ファシリテーション

運用タスクの説明: Azure DevOps は、チームがソフトウェアを効率的に計画、開発、テスト、および提供できるようにする一連の開発ツールとサービスです。 これには、バージョン管理、継続的インテグレーションと配信、プロジェクト管理などの機能が含まれます。

Azure には、多くの運用タスクの影響を最小限に抑えるサービス間統合が用意されています。 たとえば、Azure Key Vault と統合されるサービスでは、パフォーマンスへの影響を最小限に抑えるシームレスな証明書ローテーションまたはシークレット ローテーションがサポートされることがよくあります。

デプロイの最適化: App Service には デプロイ スロットが用意されています。 デプロイ スロットを使用して、非運用環境にコードをデプロイできます。 アプリのコンテンツと構成要素は、2 つのデプロイ スロット間でスワップできます。 たとえば、非運用スロットから運用スロットにアプリコンテンツを切り替えることができます。

Azure Front Door と Azure Traffic Manager を使用すると、 ブルーグリーンデプロイ戦略を実装できます。 一部の Azure コンピューティング サービスでは、ブルーグリーン デプロイなどの高度なデプロイ戦略もサポートされています。 これらのサービスをトラフィックシフトまたはインスタンスウォーミング戦略と組み合わせて、デプロイのパフォーマンスの影響を軽減できます。

データベース操作の最適化: Azure SQL Database では、完全バックアップ、差分バックアップ、トランザクション ログ バックアップが自動的に作成されます。 Azure Cosmos DB では、データのバックアップが定期的に自動的に作成されます。 自動バックアップは、データベース操作のパフォーマンスや可用性に影響を与えずに作成されます。 Azure Cosmos DB は、バックアップを別のストレージ サービスに格納します。

バックアップの最適化: 一部の Azure データ サービスでは、特定の時点の復旧とインデックス作成に対して低to-no のパフォーマンスへの影響がサポートされています。 Azure Backup は、データとアプリケーションを保護できる信頼性の高いスケーラブルなクラウドベースのバックアップ ソリューションです。 増分バックアップ、圧縮、暗号化などの機能を提供し、バックアップ操作中のパフォーマンスへの影響を最小限に抑えます。 Azure Site Recovery は、アプリケーションをセカンダリの場所にレプリケートすることで、アプリケーションを保護するのに役立ちます。 バックアップ操作とディザスター リカバリー操作中のダウンタイムとパフォーマンスへの影響を最小限に抑えるために、継続的レプリケーションと自動フェールオーバー機能が提供されます。

ビジネス継続性とディザスター リカバリーの管理: Azure Business Continuity Center を使用して、バックアップの構成、保護ポリシーの設定、運用の監視、さまざまな環境にわたる構成の確認を行う統合 Web インターフェイスを使用して、バックアップとディザスター リカバリーの管理を効率化することもできます。

関連リンク

• デプロイ スロット
• ブルーグリーンデプロイ戦略
• Azure SQL データベース
• Azure Cosmos DB

パフォーマンス効率チェックリスト

完全なレコメンデーションのセットを参照してください。