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