パフォーマンス効率
パフォーマンス効率の柱には、 システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力。 が含まれます。
このパフォーマンス効率の柱では、設計原則、ベストプラクティス、質問の概要を説明します。実装に関する規範的なガイダンスについては、「パフォーマンス効率の柱」のホワイトペーパーを参照してください。
設計原則
クラウドでのパフォーマンス効率には、5 つの設計原則があります。
-
最新テクノロジーの標準化: 複雑なタスクをクラウドベンダーに委託することによって、チームがより簡単に高度なテクノロジーを実装できるようにします。IT チームに新しいテクノロジーのホストと実行について学んでもらうのではなく、テクノロジーをサービスとして消費することを検討します。たとえば、NoSQL データベース、メディアトランスコーディング、および機械学習は、すべて特化された専門知識を必要とするテクノロジーです。クラウドでは、これらのテクノロジーがチームによる消費が可能なサービスとなり、チームはリソースのプロビジョニングと管理ではなく、製品の開発に集中できるようになります。
-
わずか数分でグローバル展開する: 世界各地にある複数の AWS リージョンでのワークロードのデプロイメントは、最小限のコストで、お客様により低いレイテンシーとより良いエクスペリエンスを提供することを可能にします。
-
サーバーレスアーキテクチャを使用する: サーバーレスアーキテクチャは、従来のコンピューティングアクティビティのために物理的なサーバーを実行して維持する必要性を取り除きます。たとえば、サーバーレスストレージサービスは静的ウェブサイトとして機能させることができ (ウェブサイトサーバーが不要になる)、イベントサービスはコードをホストできます。これによって物理サーバーを管理する運用上の負担が取り除かれます。また、マネージドサービスはクラウド規模で運用されることから、トランザクションコストも削減することができます。
-
より頻繁に実験する: 仮想的で自動化できるリソースを使うことで、異なるタイプのインスタンス、ストレージ、設定を使用した比較テストを簡単に実施できます。
-
システムに対する精通の程度を考慮する: クラウドサービスの使用方法を理解し、常にワークロードの目標に最適なテクノロジーアプローチを使用します。たとえば、データベース、またはストレージのアプローチを選択するときは、データアクセスパターンを考慮します。
定義
クラウドでのパフォーマンス効率には、4 つのベストプラクティスの分野があります。
データ駆動型アプローチを採⽤して、⾼パフォーマンスのアーキテクチャを選択します。高レベルの設計からリソースタイプの選択と設定まで、アーキテクチャのすべての側面におけるデータを収集します。
選択した内容を定期的に見直して、進化し続ける AWS クラウドを十分に活かしていることを確認します。モニタリングは、期待されるパフォーマンスからの逸脱を確実に把握できるようにします。パフォーマンスを向上させるために、圧縮やキャッシングの使用、または整合性要件の緩和などのアーキテクチャ面でのトレードオフを実施します。
ベストプラクティス
選択
特定のワークロードに最適なソリューションはさまざまで、大抵の場合、ソリューションには複数のアプローチが組み合わされています。優れた設計のワークロードは、パフォーマンスを向上させるために複数のソリューションを使用し、異なる機能を有効化します。
AWS のリソースはあらゆるタイプと設定で利用できるため、ニーズにしっかりと適合するアプローチを見つけることが容易になります。また、オンプレミスのインフラストラクチャでは実現が難しいオプションも見つけることができます。たとえば、Amazon DynamoDB などのマネージドサービスは、どのような規模でもレイテンシーが 10 ミリ秒未満の完全マネージド型 NoSQL データベースサービスを提供します。
以下の質問は、パフォーマンス効率に関するこれらの考慮事項に焦点を当てています。
PERF 1: どのように最良パフォーマンスのアーキテクチャを選択するのですか? |
データ主導のアプローチを用いて、アーキテクチャのパターンと実装を選択し、コスト効率性に優れたソリューションを実現します。AWS ソリューションアーキテクト、AWS リファレンスアーキテクチャ、および AWS パートナーネットワーク (APN) のパートナーは、業界知識に基づいたアーキテクチャを選択する支援を行うことができますが、アーキテクチャを最適化するには、ベンチマークまたは負荷テストを通じて得られたデータが必要になります。
アーキテクチャでは通常、アーキテクチャに関するさまざまなアプローチが組み合わされて使用されます (イベント駆動型、ETL、パイプラインなど)。アーキテクチャの実装には、アーキテクチャのパフォーマンスの最適化に固有の AWS のサービスが使用されます。以下のセクションでは、考慮すべき 4 つの主なリソースタイプ、つまりコンピューティング、ストレージ、データベース、およびネットワークについて説明します。
コンピューティング
要件やパフォーマンスのニーズを満たし、コストや労力を大幅に効率化するコンピューティングリソースを選択することで、同じ数のリソースでより多くを達成できます。コンピューティングオプションを評価するときは、ワークロードのパフォーマンスの要件とコスト要件に留意し、これを使用して十分な情報に基づいて意思決定を行います。
AWS では、インスタンス、コンテナ、関数の形式でコンピューティングが利用できます。
-
インスタンスは仮想化されたサーバーであり、ボタンをクリックしたり、API コールしたりすることで機能を変更できます。クラウドではリソースを自由に決定できることから、異なるサーバータイプで実験できます。AWS では、これらの仮想サーバーにさまざまなファミリーおよびサイズがあり、ソリッドステートドライブ (SSD) およびグラフィック処理ユニット (GPU) などの多種多様な機能を提供します。
-
コンテナはオペレーティングシステムを仮想化する手法であり、リソースが分離されているプロセスでアプリケーションとその依存関係を実行することが可能です。AWS Fargate はコンテナ用のサーバーレスコンピューティングです。または、コンピューティング環境のインストール、設定、および管理を制御する必要がある場合は、Amazon EC2 を使用できます。Amazon Elastic Container Service (ECS) または Amazon Elastic Kubernetes Service (EKS) といった複数のコンテナオーケストレーションプラットフォームから選択することもできます。
-
関数では、実行するコードに基づいて実行環境が抽象化されます。例えば、AWS Lambda を使用すれば、インスタンスを実行することなくコードを実行できます。
以下の質問は、パフォーマンス効率に関するこれらの考慮事項に焦点を当てています。
PERF 2: コンピューティングソリューションはどのように選択するのですか? |
コンピューティングを使用するアーキテクチャを設計する場合、需要が変化してもパフォーマンスを維持できるだけの十分な容量を確保できるように、伸縮性のメカニズムを導入する必要があります。
ストレージ
クラウドストレージはクラウドコンピューティングに不可欠のコンポーネントで、ワークロードが使用する情報を保持します。クラウドストレージは、通常、従来のオンプレミスストレージシステムよりも信頼性、拡張性、安全性に優れています。ワークロードに適したクラウドデータ移行オプションに加えて、オブジェクト、ブロック、ファイルストレージサービスから選択します。
AWS では、ストレージは、オブジェクト、ブロック、ファイルという 3 つの形式で利用できます。
-
オブジェクトストレージは、ユーザーが生成したコンテンツ、アクティブなアーカイブ、サーバーレスコンピューティング、ビッグデータストレージ、またはバックアップと復旧のために、任意のインターネットの場所からデータへのアクセスを可能にする、スケーラブルで耐久性のあるプラットフォームを提供します。Amazon Simple Storage Service (Amazon S3) は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを備えたオブジェクトストレージサービスです。Amazon S3 は 99.999999999% (9 が 11 個) の耐久性を実現するように設計されており、世界中の企業向けに数百万ものアプリケーションのデータを保存しています。
-
ブロックストレージは、仮想ホストごとに、高可用性かつ一貫性のある低レイテンシーのブロックストレージを提供します。これは、ダイレクトアタッチトストレージ (DAS) またはストレージエリアネットワーク (SAN) に類似しています。Amazon Elastic Block Store (Amazon EBS) は、EC2 インスタンスからアクセスできる永続的なストレージを必要とするワークロード向けに設計されており、適切なストレージ容量、パフォーマンス、コストでアプリケーションを調整するのに役立ちます。
-
ファイルストレージは、複数のシステムにまたがる共有ファイルシステムへのアクセスを提供します。Amazon Elastic File System (EFS) などのファイルストレージソリューションは、大規模なコンテンツリポジトリ、開発環境、メディアストア、ユーザーのホームディレクトリなどのユースケースに最適です。Amazon FSx を使用すると、一般的なファイルシステムを簡単かつコスト効率よく起動して実行できるため、広く使用されていて、オープンソースであり、商用ライセンスで利用できるファイルシステムの豊富な機能セットと高速なパフォーマンスを活用できます。
以下の質問は、パフォーマンス効率に関するこれらの考慮事項に焦点を当てています。
PERF 3: ストレージソリューションをどのように選択していますか? |
ストレージソリューションを選択する際は、必要なパフォーマンスを実現できるように、お客様のアクセスパターンに合ったソリューションを選択することが重要です。
データベース
クラウドは、ワークロードで発生するさまざまな問題に対処する、専用のデータベースサービスを提供します。これは、リレーショナル、key-value、ドキュメント、インメモリ、グラフ、時系列、および台帳データベースを含めた多数の専用データベースエンジンから選択できます。特定の問題 (または一連の問題) を解決するために最適なデータベースを選択することによって、制約の多い汎用的なモノリシックデータベースから脱却し、顧客のパフォーマンスニーズを満たすアプリケーションの構築に専念することができます。
AWS では、リレーショナル、key-value、ドキュメント、インメモリ、グラフ、時系列、および台帳データベースを含めた複数の専用データベースエンジンから選択できます。AWS のデータベースを使えば、サーバーのプロビジョニング、パッチ適用、セットアップ、設定、モニタリング、バックアップ、復旧などのデータベース管理タスクについて頭を悩ます必要はありません。AWS はクラスターを継続的に監視して、自己修復ストレージと自動スケーリングを使用してワークロードを稼働させ、より高価値なアプリケーション開発に集中できるようにします。
以下の質問は、パフォーマンス効率に関するこれらの考慮事項に焦点を当てています。
PERF 4: データベースソリューションをどのように選択していますか。 |
ワークロードのデータベースアプローチは、パフォーマンス効率に大きな影響を与えます。この領域では、多くの場合、データ駆動型のアプローチではなく、組織の標準に従って選択がなされます。ストレージと同様、ワークロードのアクセスパターンを検討することが重要です。また、データベースではないソリューション (グラフ、時系列、インメモリストレージデータベースなど) を使用してより効率的に問題を解決できないか検討することも重要です。
ネットワーク
ネットワークはすべてのワークロードコンポーネント間に存在するため、ワークロードのパフォーマンスと動作に対して好影響と悪影響を大きく及ぼす可能性があります。また、ハイパフォーマンスコンピューティング (HPC) などのネットワークパフォーマンスに大きく依存するワークロードもあり、この場合はネットワークを深く理解することがクラスターのパフォーマンスを向上させるうえで重要になります。帯域幅、レイテンシー、ジッター、およびスループットに関するワークロードの要件を判断する必要があります。
AWS ではネットワーキングが仮想化されており、数多くの異なるタイプと設定で利用することができます。ネットワーキング手法とニーズの適合が容易になります。AWS では、拡張ネットワーク、Amazon EBS 最適化インスタンス、Amazon S3 Transfer Acceleration、動的 Amazon CloudFront など、ネットワークトラフィックを最適化するための製品機能を提供しています。Amazon Route 53 のレイテンシールーティング、Amazon VPC エンドポイント、AWS Direct Connect、および AWS Global Accelerator などの、ネットワーク距離を縮め、ジッターを削減するネットワーキング機能も提供しています。
以下の質問は、パフォーマンス効率に関するこれらの考慮事項に焦点を当てています。
PERF 5: どのようにネットワーキングソリューションを選択するのですか? |
ネットワークをデプロイするときは場所を考慮する必要があります。使用される場所に近い所にリソースを配置できるため、ネットワークの距離を縮めることができます。ネットワーキングメトリクスを使用して、ワークロードの進化に合わせてネットワーキング設定を変更します。リージョンや、プレイスメントグループ、エッジサービスを活用すれば、パフォーマンスを大幅に向上させることができます。クラウドベースのネットワークは素早い再構築または変更が可能なことから、パフォーマンス効率を維持するためにもネットワークアーキテクチャを徐々に進化させることが必要です。
レビュー
クラウドテクノロジーは急速に進化しているため、ワークロードコンポーネントが新しいテクノロジーとアプローチを使用してパフォーマンスを継続的に改善できるようにする必要があります。ワークロードコンポーネントに対する変更を継続的に評価して検討し、パフォーマンスとコストの目標を確実に満たすようにする必要があります。機械学習や人工知能 (AI) などの新しいテクノロジーにより、カスタマーエクスペリエンスを再考し、ビジネスワークロード全体にわたってイノベーションを起こすことができます。
お客様のニーズによって推進される AWS の継続的なイノベーションを活用してください。AWS では、新しいリージョン、エッジロケーション、サービス、および機能を定期的にリリースしています。これらのリリースはいずれも、アーキテクチャのパフォーマンス効率を向上させることができます。
以下の質問は、パフォーマンス効率に関するこれらの考慮事項に焦点を当てています。
PERF 6: ワークロードを進化させるためにどのように新機能を取り込んでいますか? |
低パフォーマンスのアーキテクチャは通常、パフォーマンスレビュープロセスが存在しないか、または破損していることに起因します。アーキテクチャのパフォーマンスレベルが低い場合は、パフォーマンスレビュープロセスを導入することで、デミングの PDCA (計画 – 実施 – 評価 – 改善) サイクルを適用して反復的な改善を促すことができます。
モニタリング
ワークロードを実装した後は、そのパフォーマンスをモニタリングして、問題が顧客に影響を及ぼす前に修正できるようにする必要があります。モニタリングメトリクスは、しきい値を超えたときにアラームを発行するために使用するようにしてください。
Amazon CloudWatch は、モニタリングおよび可観測性のサービスで、ワークロードをモニタリングし、システム全体のパフォーマンスの変化に対応し、リソースの使用率を最適化し、運用状態の統合ビューを取得するためのデータと実用的な洞察を提供します。CloudWatch は、AWS およびオンプレミスのサーバーで実行されるワークロードから、ログ、メトリクス、イベントの形式でモニタリングおよび運用データを収集します。AWS X-Ray は、開発者が本稼働の分散アプリケーションを分析およびデバッグするのに役立ちます。AWS X-Ray を使用すると、アプリケーションの動作に関する洞察を得て、根本原因を検出し、パフォーマンスのボトルネックを特定できます。これらのインサイトを使用することで、速やかに対応し、ワークロードのスムーズな動作を維持できます。
以下の質問は、パフォーマンス効率に関するこれらの考慮事項に焦点を当てています。
PERF 7: リソースが稼働していることを確実にするためのリソースのモニタリングはどのように行いますか? |
誤判定がないことを確実にすることは、効果的なモニタリングソリューションの鍵です。自動化されたトリガーは、人為的なミスを防ぎ、問題の修正にかかる時間を短縮できます。解決までの時間を短縮できます。本番環境でシミュレーションを実施するゲームデーを計画して、アラームソリューションをテストし、それが問題を正しく認識することを確認します。
トレードオフ
ソリューションを設計するときは、最適なアプローチを確保するためにトレードオフを考慮します。状況に応じて、整合性、耐久性、および時間とレイテンシーの余裕と引き換えに、より優れたパフォーマンスを実現することができます。
AWS を使用すれば、数分で世界各地にリソースを展開して、エンドユーザーに近い場所にリソースをデプロイできます。また、プライマリデータベースの負荷を減らすため、情報ストア (データベースシステムなど) に読み取り専用のレプリカを動的に追加することもできます。
以下の質問は、パフォーマンス効率に関するこれらの考慮事項に焦点を当てています。
PERF 8: トレードオフをどのように使用するとパフォーマンスが向上するのですか? |
ワークロードに変更を加えた後、メトリクスを収集して評価し、それらの変更の影響を判断します。システムおよびエンドユーザーに対する影響を測定して、トレードオフがワークロードにどのような影響を与えるかを理解します。負荷テストなどの体系的なアプローチを使用して、トレードオフによってパフォーマンスが向上するかどうかを調べます。
リソース
パフォーマンス効率に関する AWS のベストプラクティスの詳細については、以下のリソースを参照してください。
Performance Efficiency PillarAmazon S3 Performance Optimization
Amazon EBS Volume Performance
AWS re:Invent 2019: Amazon EC2 foundations (CMP211-R2)
AWS re:Invent 2019: Leadership session: Storage state of the union (STG201-L)
AWS re:Invent 2019: Leadership session: AWS purpose-built databases (DAT209-L)
AWS re:Invent 2019: Connectivity to AWS and hybrid AWS network architectures (NET317-R1)
AWS re:Invent 2019: Powering next-gen Amazon EC2: Deep dive into the Nitro system (CMP303-R2)
AWS re:Invent 2019: Scaling up to your first 10 million users (ARC211-R)