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