パフォーマンス効率とコスト最適化のプラクティスについて

パフォーマンス効率とは、ワークロードがユーザーのパフォーマンス要件を満たし、必要に応じてスケーリングできるように、クラウド・リソースを効率的に使用することを意味します。需要は時間の経過とともに変化する可能性があるため、アーキテクチャ上の設計上の決定により、パフォーマンス効率を向上させる新しいサービスを柔軟に組み込むことができます。

オンプレミス環境と比較して、クラウド環境は柔軟な方法で、人的介入が制限された状態で増加する需要に適応する必要がありますが、これにはソリューションがクラウド用に設計されている必要があります。この記事では、ワークロードをクラウドに移行する際に考慮する必要がある、パフォーマンス効率に関連するいくつかの領域および推奨事項について説明します。

効率的なワークロードは次のようにする必要があります。
  • アーキテクチャおよびビジネス要件に最適なサービスの実装
  • 必要に応じて新しいクラウド・サービスを利用
  • コスト効率に優れた方法-プラットフォーム・サービスを活用します。コストと支出を可視化する予算、コスト・トラッキング・タグ
  • 拡張性に優れた設計パターンを適用して、需要の増大やビジネス要件の拡大に伴うスケーラビリティの問題を回避します。
  • データ主導型の意思決定を実現-メトリックを収集および利用して拡張性と最適化を促進
パフォーマンスとコストの最適化に関して効率的なクラウド・アプリケーションを構築するには、次のステップに従って効率性を考慮して設計する必要があります。
  • ワークロードを把握します。ワークロードを十分に理解しているため、設計を決定する際には、新規またはオンプレミスが不可欠です。
  • 要件に応じてクラウド・サービスを評価します。アーキテクチャと現在のビジネス要件に最適なクラウド・サービスの理解
  • データ・ドリブンになる。 Todays Cloudプラットフォームでは、意思決定を推進し、ワークロード・パフォーマンスを詳細に把握するために使用できる大量のメトリックを提供できます。
  • 成長の予測。時間の経過とともに、ワークロードは追加の地理的領域に拡大または拡大する可能性があります。アーキテクチャと選択したサービスがビジネスの成長をサポートすることを確認する
  • 支出を理解し、最適化します。クラウドを使用すると、サービスを迅速にプロビジョニングし、関連するコストを把握できます。また、ワークロードが増加したときにサービスを最適化する方法が重要になります。

ワークロードの把握

現在実行中のワークロードまたは計画済ワークロードのビジネス要件を理解することは、クラウド・リソースを活用して効率的なパフォーマンスを達成し、コストを最適化するための最善の意思決定に役立ちます。

現在のワークロードがcommercial - off - the - helf (COTS)ソフトウェア・パッケージに基づいている場合、クラウドに移行すると、多数の制約が発生し、特定のOSバージョン要件、制限されたスケールアウト・オプション、共有ファイル・システム要件などのクラウド機能の取込みが制限されることがあります。パフォーマンス効率メジャーを組み込むことはできますが、特定の領域での侵害が必要になる場合があります。

ハイブリッド・デプロイメントの場合は、依存関係を考慮し、ワークロードの要求が増加したとき、または他のワークロードやプロセスが共有リソースを競合させる必要があるときにボトルネックが存在するかどうかを評価する必要があります。ネットワーク帯域幅および待機時間は、ワークロードのパフォーマンスに重大な影響を与える可能性があるため、多くの場合調査する必要があります。

また、既存のワークロードを理解することは、ソリューションの構成要素と各部分の動作についても理解することを意味します。この知識は、ワークロードの移行時に使用するクラウド・リソースを評価する際に必要です。既存の機能の一部は、管理対象サービスに置き換えることができ、自分で管理する必要がなくなります。

既存のパフォーマンス目標およびメトリックにアクセスし、現在のワークロードに対して一連のベンチマークを実行することで、アーキテクチャ上の意思決定を推進するために使用できる重要な情報およびメトリックが提供されます。

要件に応じたクラウド・サービスの評価

ワークロードと現在のビジネス要件に最適なクラウド・サービスを評価します。

クラウドで使用可能な幅広いサービスおよびリソースについて学習し、理解します。ワークロードに関連するサービスおよび構成オプションを識別し、要件をどのようにサポートできるかを理解します。

既存のワークロードを移行する場合、既存のリソースおよびコンポーネントをクラウド対応サービスにマップできます。ただし、パフォーマンス、コストまたは管理性の利点を提供する可能性のある他のクラウド・サービスを使用するようにアーキテクチャを更新できるかどうかを必ず評価してください。移行を計画する場合、現在のワークロードがクラウド用に設計されているかどうかを考慮する必要があります。

完全に管理されたクラウド・サービスの方がコストが高いように見える場合がありますが、操作のワークロードの削減を考慮すると、この計算が変更される可能性があります。これは、アーキテクチャを決定する際に考慮する必要があります。

データ・ドリブンになる

データおよびメトリックはすべてのクラウド・ワークロードの重要な部分であり、キー・パフォーマンス・インジケータの定義は設計プロセス全体の重要な部分です。

一定期間にわたってメトリックを収集すると、次のことに役立ちます。
  • 設計の意思決定の促進。
  • ワークロードを最適化します。
  • スケーラビリティの問題を強調表示します。
  • リリース関連の問題を特定します。
  • エンド・ユーザーとの対話に関する洞察を提供します。
  • ワークロードのコスト効率を表示します。
  • トレンド、季節性およびプロジェクト需要を明らかにします。
  • アラーム、スケーリング、是正アクションなどの自動タスクをトリガーします。
戦略レベルでは、メトリックを分析ソリューションにプッシュして、ビジネス要件に対してワークロードがどのように実行されているかを視覚化、共有および把握する必要があります。

成長の予測

クラウドでは、需要を満たす必要がある場合や新しいリージョンに拡張する必要がある場合に、小規模で開始して拡大できます。

ワークロードに応じて、スケーリング方法、およびスケーリングをサポートする適切なサービスとパターンを使用しているかどうかを検討する必要があります。アプリケーションの各レイヤーおよびコンポーネントを評価して、スケーリング特性を理解します。

管理対象PaaSサービスを利用すると、リソースの自動スケーリングなどの機能を提供し、スクリプト作成や管理者操作の必要性を最小限に抑えることができます。

負荷テストを使用して、アプリケーションのスケーリング方法、およびテスト中に特定のコンポーネントがホットスポットになるかどうかを判断します。

また、スケーリング・シナリオでテナンシ・サービス制限または割当て制限ポリシーが影響を与える可能性があるかどうかも考慮する必要があります。本番ワークロードとその他の非本番ワークロードの両方を含むテナンシでは、本番リソースのスケーリングを成功させるために、ポリシーおよび保護が適切に行われていることを確認する必要があります。

既存の履歴ワークロード・メトリックを使用して、ワークロード需要の性質および予測可能かどうかを把握します。

支出の理解と最適化

クラウドのコスト・モデルは、オンプレミスの実装とは大きく異なります。これにより、適切なサイズのアプローチをとることができ、アイドル状態のリソースに対して支払うことが多い長期的なリソース要件予測を処理する必要がなくなります。

調達サイクルが非常に短く、数分以内に環境をプロビジョニングおよびプロビジョニング解除できるため、チームはより高いレベルの生産性を実現し、設計上の意思決定を下す前に異なるソリューションまたはサービスを試すことができます。
  • クラウド・コスト・モデルについて学ぶ

    組織レベルで支出を最適化できるように、様々なリソースの請求特性および使用特性がどのように異なるかを理解します。

  • コスト・ガバナンスの導入

    異なるチームが同じアプローチに従うようにポリシーとプロセスを定義し、コストを評価する統一された方法を可能にします。

  • 効率の測定

    ワークロードをビジネス価値および使用されるリソースの関連コストの観点から測定できるように、データ駆動型のアプローチが用意されています。これにより、ビジネス目標を達成し、改善領域を特定しながら、どの程度効率的にリソースを使用しているかを把握できます。

  • クラウド・サービスと機能の活用

    自動化およびマネージド・サービスにより、環境の構築または維持、オペレーティング・システムの更新またはデータベースのチューニングに費やすスタッフの時間を削減し、ビジネス価値を追加しないため、ワークロードの実行にかかる全体的なコストを削減できます。

  • 要件により使用を促進する必要があります

    ビジネス要件に基づいて、リソースが必要な時期と方法、およびリソースを24時間365日利用可能にするかどうかを定義します。これはオンプレミスの世界とは異なります。クラウドでは、必要に応じてリソースをスケーリング、停止またはプロビジョニング解除できるため、結果のコストに大きく影響します。