Share via

運用タスクを最適化するための推奨事項

  • [アーティクル]

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

PE:10 運用タスクを最適化する。 ソフトウェア開発ライフサイクルやその他の日常的な操作がワークロードのパフォーマンスに及ぼす影響を監視し、最小限に抑えます。 これらの操作には、ウイルス スキャン、シークレットローテーション、バックアップ、データベースのインデックス再作成、デプロイが含まれます。

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

定義

期間 定義
ブルーグリーン デプロイ 2 つの同じ環境を使用し、新しいデプロイ (グリーン デプロイ) へのトラフィックの方向を制御するデプロイ戦略。
データベース インデックスの再構築 インデックスを削除して再作成するメンテナンス アクティビティ。
データベース インデックスの再編成 現在のデータベース インデックスを最適化するメンテナンス アクティビティ。
データベース スキーマ データベースの一般的な構造とその他のデータとの関係。
デプロイ スロット 独自のホスト名を使用してライブ アプリを展開できるようにするAzure App Serviceの機能。
一括アップグレード コンポーネントまたはアプリケーションを置き換えたり、新しい環境に移行したりせずにアップグレードするプロセス。
コードとしてのインフラストラクチャ (IaC) ネットワーク、仮想マシン、ロード バランサー、接続トポロジなど、インフラストラクチャを定義およびデプロイするための説明モデル。

主要な設計戦略

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

運用タスクのアカウント

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

  • 運用タスクを特定します。 パフォーマンス目標に関連する運用タスクを特定して含めます。 日常的なタスクの例としては、ウイルス スキャン、データベース インデックスの再編成、データベース インデックスの再構築、ディスクまたはデータベースのバックアップ、証明書のローテーション、オペレーティング システムの修正プログラムの適用、パスワードのローテーション、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 データ サービスでは、ポイントインタイムの復旧とインデックス作成に対する低対無パフォーマンスの影響がサポートされています。 Azure Backupは、データとアプリケーションを保護できる信頼性が高くスケーラブルなクラウドベースのバックアップ ソリューションです。 バックアップ操作中のパフォーマンスへの影響を最小限に抑えるために、増分バックアップ、圧縮、暗号化などの機能が提供されます。 Azure Site Recoveryは、アプリケーションをセカンダリの場所にレプリケートすることでアプリケーションを保護するのに役立ちます。 継続的レプリケーションと自動フェールオーバー機能を提供し、バックアップおよびディザスター リカバリー操作中のダウンタイムとパフォーマンスへの影響を最小限に抑えます。

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

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

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