パフォーマンス効率のトレードオフ
オーバープロビジョニングなしでパフォーマンス目標を満たすワークロードは効率的です。 パフォーマンス効率の目標は、常に需要を処理するのに十分な供給を持つことです。 パフォーマンス効率の主な戦略には、コードの最適化、設計パターン、容量計画、スケーリングの適切な使用が含まれます。 明確なパフォーマンス 目標とテストがこの柱を支えています。
ワークロードのパフォーマンス目標をネゴシエートし、パフォーマンス効率のためにワークロードを設計するプロセスでは、 パフォーマンス効率の設計原則 と、 パフォーマンス効率の設計レビュー チェックリスト の推奨事項が他の柱の最適化目標にどのように影響するかに注意することが重要です。 特定のパフォーマンス効率の決定は、一部の柱に役立つ場合がありますが、他の要素のトレードオフを構成します。 この記事では、パフォーマンス効率のためにワークロード アーキテクチャと操作を設計するときにワークロード チームが遭遇する可能性があるトレードオフの例を示します。
信頼性を備えたパフォーマンス効率のトレードオフ
トレードオフ: レプリケーションの削減と密度の向上。 信頼性の基礎となるのは、レプリケーションを使用して回復性を確保し、誤動作の爆発半径を制限することにあります。
最後の責任ある瞬間までスケーリングを遅延させて効率を達成するワークロードは、需要を厳密に満たしますが、予期しないノード障害やスケーリングの遅延に対して脆弱です。
ワークロード リソースを統合すると、過剰な容量が使用され、効率が向上する可能性があります。 ただし、併配置されたコンポーネントまたはアプリケーション プラットフォームでの誤動作の爆発半径が増加します。
過剰な容量を最小限に抑えるためにスケールインまたはスケールダウンすると、使用量の急増中にワークロードのプロビジョニングが不足し、供給不足によるサービスの中断につながる可能性があります。
自動スケーリングを使用してワークロードの供給と需要のバランスを取る場合、ワークロードのトポロジにばらつきが生じ、システムの信頼性を高めるために正しく機能する必要があるコンポーネントが追加されます。 自動スケーリングにより、起動や停止など、より多くのアプリケーション ライフサイクル イベントがトリガーされます。
データのパーティション分割とシャーディングは、大規模または頻繁にアクセスされるデータセットのパフォーマンスの問題を回避するのに役立ちます。 ただし、これらのパターンの実装は、(最終的な) 一貫性を追加のリソース全体で維持する必要があるため、複雑さが増します。
最適化されたアクセス パターン用にデータを非正規化するとパフォーマンスが向上しますが、複数のデータ表現を同期する必要があるため、複雑さが生じる可能性があります。
パフォーマンス中心のクラウド設計パターンでは、追加のコンポーネントの導入が必要な場合があります。 これらのコンポーネントを使用すると、ワークロードの領域が増加します。 その後、コンポーネント自体を信頼性の高い状態にして、ワークロード全体の信頼性を維持する必要があります。 以下に例を示します。
- 重大でステートフルなコンポーネントを導入する、読み込み平準化用のメッセージ バス。
- 自動スケーリングされたレプリカのロード バランサー。信頼性の高い操作とレプリカの参加が必要です。
- キャッシュにデータをオフロードするには、信頼性の高いキャッシュ無効化アプローチが必要です。
代理トランザクションの使用など、アクティブな環境でのパフォーマンス テストでは、テスト アクションまたは構成によって誤動作が発生するリスクがあります。
ワークロードは、チームがアクティブな環境から学習できるようにするアプリケーション パフォーマンス監視 (APM) システムでインストルメント化する必要があります。 APM ツールは、アプリケーション コードまたはホスティング環境にインストールおよび構成されます。 ツールの不適切な使用、制限の超過、または構成の誤りにより、その機能とメンテナンスが損なわれ、信頼性が損なわれる可能性があります。
セキュリティを使用したパフォーマンス効率のトレードオフ
パフォーマンス最適化戦略の 1 つは、特に処理時間が正当化されない場合に、フローの遅延に寄与するコンポーネントまたはプロセスを削除またはバイパスすることです。 ただし、この戦略はセキュリティを侵害する可能性があり、徹底的なリスク分析を伴う必要があります。 次に例を示します。
転送中または保存中の暗号化を削除して転送速度を向上すると、データは潜在的な整合性または機密性の侵害にさらされます。
セキュリティ スキャンまたは検査ツールを削除または削減して処理時間を短縮すると、それらのツールが保護する機密性、整合性、または可用性が損なわれる可能性があります。
パフォーマンスへの影響を制限するためにセキュリティ パッチ適用の頻度を減らすと、ワークロードが新たな脅威に対してより脆弱になる可能性があります。
ネットワークの待機時間を短縮するためにネットワーク フローからファイアウォール規則を削除すると、望ましくない通信が可能になります。
データの検証を最小限にしてデータ処理を高速化すると、特に入力が悪意のある場合に、データの整合性が損なわれる可能性があります。
暗号化アルゴリズムやハッシュ アルゴリズム (初期化ベクトル (IV) など) ではエントロピを使用する方が効率的ですが、暗号化が容易になります。
パフォーマンス中心のクラウド設計パターンでは、追加のコンポーネントの導入が必要な場合があります。 これらのコンポーネントにより、ワークロードの領域が増加します。 新しいコンポーネントは、システムでまだ使用されていない方法でセキュリティ保護する必要があり、多くの場合、コンプライアンス スコープが広がります。 一般的に追加される次のコンポーネントを検討してください。
負荷平準化のためのメッセージ バス
自動スケーリングされたレプリカのロード バランサー
キャッシュ、アプリケーション配信ネットワーク、またはコンテンツ配信ネットワークへのデータのオフロード
バックグラウンド ジョブやクライアント コンピューティングへの処理のオフロード
リソースの共有は、効率を向上させるアプローチです。 容量の使用を最適化するために密度が向上します。 たとえば、マルチテナント シナリオや、一般的なアプリケーション プラットフォーム上のアーキテクチャで異なるアプリケーションを組み合わせたりします。 密度が高くなると、次のセキュリティ上の問題が発生する可能性があります。
1 つのテナントから別のテナントへの不正な横移動のリスクが増加しました。
最小限の特権の原則に違反し、アクセス ログ内の個々の監査証跡を隠す共有ワークロード ID。
境界セキュリティ制御 (ネットワーク 規則など) は、すべての併配置されたコンポーネントをカバーするように縮小され、個々のコンポーネントに必要以上のアクセス権を与えます。
より大きな爆発半径によるアプリケーション プラットフォーム ホストまたは個々のコンポーネントの侵害。 この増加は、併配置されたコンポーネントへのアクセスが容易な場合に発生します。
異なるコンポーネントを併置すると、共有ホストが原因で、コンプライアンスのスコープ内のコンポーネントが増えます。
コスト最適化によるパフォーマンス効率のトレードオフ
オーバープロビジョニングは、チームがワークロードのパフォーマンスの問題を軽減しようとする場合のリスクです。 オーバープロビジョニングの一般的な原因には、次のようなものがあります。
- 初期容量計画が誤って判断されました。これは、チームがピーク時の負荷の見積もりのみに重点を置き、ワークロード設計のピーク 平滑化に関する戦略を無視したためです。
- インシデント対応のトラブルシューティング 手順中にリソースをスケールアップまたはスケールアウトする。
自動スケーリングが正しく構成されていない可能性があります。 正しく構成されていない自動スケーリングの例を次に示します。
- 需要の変化を最小限に抑えるか、クールダウン期間を延長してスケールアップすると、需要が必要とするよりも多くのコストが発生する可能性があります。
- 上限を設定せずに自動スケーリングを使用すると、システムの誤動作や不正使用による制御不能な増加につながり、予想されるワークロード要件を超える可能性があります。
複数のリージョンに拡張すると、ワークロードをユーザーに近づけることでパフォーマンスを向上させ、一時的なリソース容量の制約を回避できます。 ただし、複雑さとリソースの重複も追加されます。
パフォーマンス中心のクラウド設計パターンでは、追加のコンポーネントの導入が必要な場合があります。 これらの追加コンポーネントは、通常、ワークロードの全体的なコスト増加につながります。 たとえば、負荷平準化のためのメッセージ バスを含めたり、アプリケーションまたはコンテンツ配信ネットワークにタスクをオフロードして応答時間を短縮したりできます。
リソースのセグメント化を使用すると、ワークロードのさまざまな部分で個別のパフォーマンス特性を持つことが可能になり、セグメントごとに独立したチューニングが可能になります。 ただし、1 つの一般化されたコンポーネントではなく、複数の最適化されたセグメントが必要になるため、総保有コストが増加する可能性があります。
Premium サービスと SKU は、ワークロードがパフォーマンス 目標を満たすのに役立ちます。 通常、これらのサービスはコストが高く、追加の機能を提供できます。 Premium 機能の多くが特にパフォーマンス目標を達成するために使用されていない場合は、使用率が低い可能性があります。
パフォーマンスの高いワークロードでは、転送および格納する必要がある可観測性のためにテレメトリ データが必要です。 収集されるパフォーマンス テレメトリの増加により、テレメトリ データ転送とストレージのコストが増加する可能性があります。
パフォーマンス テスト アクティビティでは、運用システムの値に関連付けられていないコストが追加されます。 パフォーマンス テストのコストの例を次に示します。
- パフォーマンス中心のテスト専用の環境をインスタンス化する。
- 特殊なパフォーマンス ツールを使用する。
- テストの実行に時間を費やす。
特殊なパフォーマンス最適化タスクのチーム メンバーをトレーニングしたり、パフォーマンス チューニング サービスの支払いを行ったりすると、ワークロードのコストが高くなります。
オペレーショナル エクセレンスによるパフォーマンス効率のトレードオフ
ログとメトリックの量を減らして、他のタスクではなくテレメトリの収集に費やす処理時間を短縮すると、システム全体の監視性が低下します。 結果として得られる観測性の低下の例を次に示します。
- 意味のあるアラートを作成するために使用されるデータ ポイントが制限されます。
- これは、インシデント対応アクティビティのカバレッジのギャップにつながります。
- セキュリティに依存する操作やコンプライアンスに依存する相互作用と境界での可観測性が制限されます。
パフォーマンス設計パターンを実装すると、多くの場合、ワークロードの複雑さが増します。 コンポーネントは重要なフローに追加されます。 ワークロード監視戦略とパフォーマンス監視には、これらのコンポーネントを含める必要があります。 フローが複数のコンポーネントまたはアプリケーションの境界にまたがる場合、そのフローのパフォーマンスを監視する複雑さが増します。 フローパフォーマンスは、相互接続されたすべてのコンポーネントに関連付ける必要があります。
密度を高めることでパフォーマンス効率を向上させると、運用タスクのリスクが高まります。 1 つのプロセスでエラーが発生すると、爆発半径が大きくなる可能性があります。
パフォーマンス設計パターンが実装されると、バックアップ、キーローテーション、復旧戦略などの運用手順に影響します。 たとえば、データのパーティション分割とシャーディングは、チームがそれらのタスクがデータの一貫性に影響しないようにしようとするときに、ルーチン タスクを複雑にする可能性があります。
パフォーマンスの問題の根本原因分析を行うと、修正が必要なプロセスまたは実装の欠陥が特定されます。 チームは、演習を学習機会と見なす必要があります。 チーム メンバーが問題の責任を負うと、士気が影響を受ける可能性があります。
ルーチンプロセスとアドホック プロセスは、ワークロードのパフォーマンスに影響を与える可能性があります。 多くの場合、オフピーク時にこれらのアクティビティを実行することをお勧めします。 ただし、ピーク外の時間は、これらのタスクを担当または熟練しているチーム メンバーにとって不便な場合や、通常の時間外である可能性があります。
関連リンク
他の柱のトレードオフを調べる: