# パフォーマンス効率
パフォーマンス効率の柱には、クラウドリソースを効率的に使用してパフォーマンス要件を満たし、需要の変化や技術の進歩に合わせてこの効率性を維持する能力が含まれます。
このパフォーマンス効率の柱では、設計原則、ベストプラクティス、質問の概要を説明します。実装に関する規範的なガイダンスについては、[パフォーマンス効率の柱のホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp)を参照してください。
**Topics**
+ [
# 設計原則
](perf-dp.md)
+ [
# 定義
](perf-def.md)
+ [
# ベストプラクティス
](perf-bp.md)
+ [
# リソース
](perf-resources.md)
# 設計原則
クラウドにはパフォーマンス効率のための設計原則が 5 つあります。
+ **高度なテクノロジーを誰でも使えるようにする**: 複雑なタスクをクラウドベンダーに委託することによって、チームがより円滑に高度なテクノロジーを実装できるようにします。IT チームに新しいテクノロジーのホストと実行について学んでもらうのではなく、テクノロジーをサービスとして消費することを検討します。例えば、NoSQL データベース、メディアトランスコーディング、および機械学習などは、いずれも特化された専門知識を必要とするテクノロジーです。クラウドでは、これらのテクノロジーがチームが消費できるサービスとなり、チームはリソースのプロビジョニングと管理ではなく、製品の開発に集中できるようになります。
+ **わずか数分でグローバル展開する**: 世界各地にある複数の AWS リージョンでのワークロードのデプロイメントは、最小限のコストで、お客様により低いレイテンシーとより良いエクスペリエンスを提供することを可能にします。
+ **サーバーレスアーキテクチャを使用する**: サーバーレスアーキテクチャにより、従来のコンピューティングアクティビティのために物理的なサーバーを実行および維持する必要がなくなります。例えば、サーバーレスストレージサービスは静的ウェブサイトとして機能させることができ (ウェブサイトサーバーが不要になる)、イベントサービスはコードをホストできます。これによって物理サーバーを管理する運用上の負担が取り除かれます。また、マネージドサービスはクラウド規模で運用されることから、トランザクションコストも削減することができます。
+ **より頻繁に実験する: **仮想および自動化可能なリソースを使用して、異なるタイプのインスタンス、ストレージ、および設定による比較テストを迅速に実行できます。
+ **メカニカルシンパシーを重視する**: クラウドサービスの使用方法を理解し、常にワークロードの目標に最適なテクノロジーアプローチを使用します。例えば、データベースやストレージのアプローチを選択するときには、データアクセスパターンを考慮します。
# 定義
クラウドのパフォーマンス効率を向上させるには、次の 5 つのベストプラクティス領域があります。
+ **アーキテクチャの選択**
+ **コンピューティングとハードウェア**
+ **データ管理**
+ **ネットワークとコンテンツ配信**
+ **プロセスと文化**
データ駆動型アプローチを採⽤して、⾼パフォーマンスのアーキテクチャを選択します。高レベルの設計からリソースタイプの選択と設定まで、アーキテクチャのすべての側面におけるデータを収集します。
選択した内容を定期的に見直して、進化し続ける AWS クラウドの機能を十分に活かしていることを検証します。モニタリングすることで、期待されるパフォーマンスからの逸脱を把握していることを検証します。圧縮やキャッシュを使用したり、整合性に関する要件を緩和したりするなど、アーキテクチャにおけるトレードオフを行ってパフォーマンスを向上させます。
# ベストプラクティス
**Topics**
+ [
# アーキテクチャの選択
](perf-arch.md)
+ [
# コンピューティングとハードウェア
](perf-compute.md)
+ [
# データ管理
](perf-data.md)
+ [
# ネットワークとコンテンツ配信
](perf-networking.md)
+ [
# プロセスと文化
](perf-process.md)
# アーキテクチャの選択
特定のワークロードに適したソリューションはさまざまで、大抵の場合、ソリューションには複数のアプローチが組み合わされています。優れた設計のワークロードは、複数のソリューションを使用し、異なる機能を有効化して、パフォーマンスを向上させます。
AWS のリソースはあらゆるタイプと設定で利用できるため、お客様のニーズを満たす、最も近いアプローチを簡単に見つけることができます。また、オンプレミスのインフラストラクチャでは実現が難しいオプションも見つけることができます。例えば、Amazon DynamoDB のようなマネージドサービスでは、あらゆるスケールにおいてレイテンシーが 10 ミリ秒未満であるフルマネージド型の NoSQL データベースを提供します。
以下の質問は、パフォーマンス効率に関する考慮事項に焦点を当てています。(パフォーマンス効率に関する質問、回答、ベストプラクティスの一覧については、[付録](a-performance-efficiency.md)を参照してください。)
| PERF 1: ワークロードに適切なクラウドリソースとアーキテクチャを選択するにはどうすればよいでしょうか? |
| --- |
| 多くの場合、ワークロード全体でのより効果的なパフォーマンスのためには、複数のアプローチが必要になります。Well-Architected なシステムでは、パフォーマンスを向上させるために複数のソリューションと機能が使用されています。 |
# コンピューティングとハードウェア
特定のワークロードに対する最適なコンピューティングの選択は、アプリケーションの設計、利用パターン、および構成設定に応じて異なります。アーキテクチャでは、各種コンポーネントに異なるコンピューティングを使用し、異なる機能を有効化してパフォーマンスを向上させることができます。アーキテクチャに誤ったコンピューティングを選択することは、パフォーマンス効率の低下につながる可能性があります。
AWS では、インスタンス、コンテナ、関数という 3 つの形式でコンピューティングを利用できます。
+ **インスタンス**は仮想化されたサーバーで、ボタンまたは API コールを使用して機能を変更できます。クラウドではリソースを柔軟に選択できることから、異なるサーバータイプで実験することができます。AWS では、これらの仮想サーバーインスタンスには、さまざまなファミリーおよびサイズがあり、ソリッドステートドライブ (SSD) やグラフィック処理ユニット (GPU) など、多種多様な機能を提供します。
+ **コンテナ**は、オペレーティングシステムを仮想化する手段です。コンテナを使用すると、リソースが分離されたプロセス内でアプリケーションとその依存関係を実行できます。AWS Fargate は、コンテナ用のサーバーレスコンピューティングです。コンピューティング環境のインストール、設定、管理を制御する必要がある場合は、Amazon EC2 を使用できます。Amazon Elastic Container Service (ECS) または Amazon Elastic Kubernetes Service (EKS) といった複数のコンテナオーケストレーションプラットフォームから選択することもできます。
+ **関数**は、適用するコードに基づいて、実行環境が抽象化されます。例えば、AWS Lambda ではインスタンスを実行せずにコードを実行できます。
以下の質問は、パフォーマンス効率に関する考慮事項に焦点を当てています。
| PERF 2: コンピューティングリソースを選択し、ワークロードで使用するにはどうすればよいでしょうか? |
| --- |
| ワークロードにとってより効率的なコンピューティングソリューションは、アプリケーションの設計、使用パターン、設定に応じて異なります。各アーキテクチャでは、コンポーネントごとに異なるコンピューティングソリューションが使用される可能性があるため、パフォーマンスを向上させるために有効にする機能も異なります。アーキテクチャに不適切なコンピューティングソリューションを選択すると、パフォーマンス効率が低下する可能性があります。 |
# データ管理
特定のシステムに最適なデータ管理ソリューションは、データの種類 (ブロック、ファイル、またはオブジェクト)、アクセスパターン (ランダムまたはシーケンシャル)、必要なスループット、アクセス頻度 (オンライン、オフライン、アーカイブ)、更新頻度 (WORM、動的)、および可用性と耐久性に関する制約に応じて異なります。優れた設計のワークロードは、さまざまな機能によってパフォーマンスを向上させることができる専用のデータストアを使用します。
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 (Amazon EFS) などのファイルストレージソリューションは、大規模なコンテンツリポジトリ、開発環境、メディアストア、ユーザーのホームディレクトリなどのユースケースに最適です。Amazon FSx を使用すると、一般的なファイルシステムを効率的かつコスト効率よく起動して実行できるため、広く使用されていて、オープンソースであり、商用ライセンスで利用できるファイルシステムの豊富な機能セットと高速なパフォーマンスを活用できます。
以下の質問は、パフォーマンス効率に関する考慮事項に焦点を当てています。
| PERF 3: ワークロード内のデータはどのように保存、管理、アクセスすればよいでしょうか? |
| --- |
| システムにとってより効率的なストレージソリューションは、アクセス操作 (ブロック、ファイル、オブジェクト)、アクセスパターン (ランダム、シーケンシャル)、必要なスループットやアクセス頻度 (オンライン、オフライン、アーカイブ)、更新頻度 (WORM、動的)、可用性と耐久性に関する制約によって異なります。Well–Architected システムは、複数のストレージソリューションを使用し、さまざまな機能を有効にして、パフォーマンスとリソースの使用効率を高めます。 |
# ネットワークとコンテンツ配信
ワークロードに最適なネットワークソリューションは、レイテンシー、スループット要件、ジッター、および帯域幅に応じて異なります。ロケーションのオプションは、ユーザーまたはオンプレミスのリソースなどの物理的な制約に左右されます。これらの制約は、エッジロケーションまたはリソースの配置で相殺することができます。
AWS ではネットワーキングが仮想化されており、数多くの異なるタイプと設定で利用することができます。これにより、ネットワークのニーズへの適合が容易になります。AWS は、ネットワークトラフィックを最適化する製品機能を提供します (拡張ネットワーキング、Amazon EC2 ネットワーク最適化インスタンス、Amazon S3 Transfer Acceleration、動的 Amazon CloudFront など)。また、AWS は、ネットワーク距離またはジッターを軽減するネットワーク機能も提供します (Amazon Route 53 レイテンシールーティング、Amazon VPC エンドポイント、AWS Direct Connect、AWS Global Accelerator など)。
以下の質問は、パフォーマンス効率に関する考慮事項に焦点を当てています。
| PERF 4: ワークロード内のネットワークリソースはどのように選択して構成すればよいでしょうか? |
| --- |
| この質問には、クラウドで効率的なネットワークおよびコンテンツ配信ソリューションを設計、構成、運用するためのガイダンスとベストプラクティスが含まれています。 |
# プロセスと文化
ワークロードを設計する際には、効率的で高性能なクラウドワークロードをより良く実行するために採用できる原則と慣行があります。クラウドワークロードのパフォーマンス効率を高める文化を採用するには、以下の重要な原則と慣行を検討してください。
この文化を築くために、以下の基本方針を考慮してください。
+ **コードとしてのインフラストラクチャ:** AWS CloudFormation テンプレートなどのアプローチを使用してインフラストラクチャをコードとして定義します。テンプレートを使用すると、アプリケーションコードと設定のほか、インフラストラクチャをソースコントロールに配置できます。これは、ソフトウェアの開発に使用するものと同じ慣行をインフラストラクチャに適用することを可能にし、イテレーションを迅速に行えるようになります。
+ **デプロイメントパイプライン:** 継続的インテグレーション/継続的デプロイメント (CI/CD) パイプライン (ソースコードリポジトリ、ビルドシステム、デプロイメント、およびテストのオートメーションなど) を使用してインフラストラクチャをデプロイします。これにより、イテレーションのたびに、反復可能で、一貫性があり、低コストな方法でデプロイできるようになります。
+ **明確に定義されたメトリクス:** メトリクスをセットアップおよびモニタリングして主要業績評価指標 (KPI) をキャプチャします。メトリクスについては、技術とビジネス両方のメトリクスの使用をお勧めします。ウェブサイトまたはモバイルアプリの主なメトリクスは、最初の 1 バイトを受信するまでの時間、または最初のレンダリングまでの時間のキャプチャです。一般的に適用されるその他のメトリクスには、スレッド数、ガベージコレクション率、および待機状態などがあります。リクエストあたりの総累積コストなどのビジネスメトリクスでは、コストを削減する方法をアラートできます。メトリクスを解釈する方法を十分に検討してください。例えば、平均値ではなく、最大値または 99 パーセンタイル値を選択できます。
+ **パフォーマンステストのオートメーション:** デプロイメントプロセスの一環として、より簡単に実行できるテストが正常に終了した後で、パフォーマンステストを自動的に開始します。自動化により新しい環境が作成され、テストデータなどの初期条件が設定された後に、一連のベンチマークとロードテストが実行されます。これらのテストの結果は、時間の経過に伴うパフォーマンスの変化を追跡できるようにビルドに関連付けてください。テストが長時間実行される場合、パイプラインのこの部分を、他のビルドと同期しないようにできます。または、Amazon EC2 スポットインスタンスを使用して夜間にパフォーマンステストを実行できます。
+ **ロードの生成:** 合成ユーザージャーニーや事前に記録されたユーザージャーニーをレプリケートする一連のテストスクリプトを作成します。これらは結合スクリプトではなく、べき等性スクリプトにしてください。有効な結果を得るために、「プレウォーミング」スクリプトを含める必要がある場合もあります。テストスクリプトは、可能な限り本番での使用状況を再現する必要があります。負荷の生成には、ソフトウェアまたは Software as a Service (SaaS) ソリューションを使用できます。[AWS Marketplace](https://aws.amazon.com/marketplace/) ソリューションおよび[スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)の使用を検討してください。これらを利用することで、コスト効率に優れた方法で負荷を生成できます。
+ **パフォーマンスの可視性:** 主要なメトリクス、特に各ビルドバージョンに対するメトリクスはチームが確認できるようにする必要があります。これにより、時間の経過に伴う大量の肯定的または否定的な傾向の評価を参照できるようになります。また、エラーや例外の数に関するメトリクスも表示して、動作中のシステムをテストしていることを確認するようにしてください。
+ **可視化:** パフォーマンス問題、ホットスポット、待機状態、または低使用率が発生している箇所を明らかにする可視化手法を使用します。アーキテクチャ図にパフォーマンスメトリクスを重ね合わせます。コールグラフ、またはコードも問題をすばやく特定するために役立ちます。
+ **定期的なレビュープロセス:** 低パフォーマンスのアーキテクチャは通常、パフォーマンスレビュープロセスが存在しないか、または破綻していることに起因します。アーキテクチャのパフォーマンスレベルが低い場合は、パフォーマンスレビュープロセスを導入することで、反復的な改善を促すことができます。
+ **継続的な最適化:** クラウドワークロードのパフォーマンス効率を継続的に最適化する文化を取り入れましょう。
以下の質問は、パフォーマンス効率に関する考慮事項に焦点を当てています。
| PERF 5: ワークロードのパフォーマンス効率を高めるためにどのようなプロセスを使用しますか? |
| --- |
| ワークロードを設計する際には、効率的で高性能なクラウドワークロードをより良く実行するために採用できる原則と慣行があります。クラウドワークロードのパフォーマンス効率を高める文化を採用するには、以下の重要な原則と慣行を検討してください。 |
# リソース
パフォーマンス効率に関するベストプラクティスの詳細については、以下のリソースを参照してください。
## ドキュメント
+ [Amazon S3 パフォーマンスの最適化](https://docs.aws.amazon.com/AmazonS3/latest/dev/PerformanceOptimization.html?ref=wellarchitected-wp)
+ [Amazon EBS ボリュームパフォーマンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html?ref=wellarchitected-wp)
## ホワイトペーパー
+ [パフォーマンス効率の柱](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp)
## 動画
+ [AWS re:Invent 2019: Amazon EC2 foundations (CMP211-R2)](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Leadership session: Storage state of the union (STG201-L)](https://www.youtube.com/watch?v=39vAsGi6eEI&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Leadership session: AWS purpose-built databases (DAT209-L)](https://www.youtube.com/watch?v=q81TVuV5u28&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Connectivity to AWS and hybrid AWS network architectures (NET317-R1)](https://www.youtube.com/watch?v=eqW6CPb58gs&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Powering next-gen Amazon EC2: Deep dive into the Nitro system (CMP303-R2)](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Scaling up to your first 10 million users (ARC211-R)](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected-wp)