W-A パフォーマンス効率の柱

Kom i gang. Det er Gratis
eller tilmeld med din email adresse
W-A パフォーマンス効率の柱 af Mind Map: W-A パフォーマンス効率の柱

1. 選択

1.1. PERF 1. パフォーマンスアーキテクチャの選択

1.1.1. 利用可能なサービスやリソースを理解する

1.1.1.1. ワークロードを満たすテクノロジの理解

1.1.2. アーキテクチャに関わる選択プロセスを決める

1.1.2.1. リソースの選定プロセスを決定する

1.1.2.2. 重要なストーリーにはパフォーマンス要件を含める

1.1.3. 意思決定においてコスト要件を考慮する

1.1.3.1. 運用コストの削減

1.1.3.2. コスト最適化の柱

1.1.4. ポリシーやリファレンスアーキテクチャを使用する

1.1.4.1. 組織の内部ポリシーと既存のリファレンスアーキテクチャを評価

1.1.5. クラウドプロバイダー、または適切なパートナーからのガイダンスを利用する

1.1.5.1. AWS プロフェッショナルサービス (AWS クラウドのコンサルティングサービス) | AWS

1.1.5.2. AWS パートナーネットワーク | AWS

1.1.6. 既存のワークロードのベンチマークを実施する

1.1.6.1. TPC-DS Homepage

1.1.7. ワークロードの負荷テストを実施する

1.1.7.1. 本番データから生成しサニタイズしたバージョン

1.1.7.2. CloudWatch

1.1.7.3. スポットインスタンス

1.1.7.4. クライアントの地理的分散

1.2. PERF 2. コンピューティングアーキテクチャの選択

1.2.1. 使用可能なコンピューティングオプションを評価する

1.2.1.1. インスタンス

1.2.1.1.1. EC2

1.2.1.2. コンテナ

1.2.1.2.1. Fargete、ECS、EKS

1.2.1.2.2. AWS App Mesh(マイクロサービスをモニタリングおよびコントロールする)| AWS

1.2.1.3. Functions

1.2.1.3.1. Lambda、API Gateway

1.2.2. 利用可能なコンピューティング設定オプションについて理解する

1.2.2.1. GPU

1.2.2.2. FPGA

1.2.2.3. AWS Inferenitia

1.2.2.3.1. AWS Neuron

1.2.2.4. バースト可能なインスタンスファミリー

1.2.2.5. 高度なコンピューティング機能

1.2.2.6. AWS Nitoro System

1.2.3. コンピューティング関連のメトリクスを収集する

1.2.3.1. CloudWatch

1.2.4. 適切なサイジングによって必要な設定を決定する

1.2.4.1. インスタンスファミリー

1.2.5. 利用可能な伸縮性のあるリソースを使用する

1.2.5.1. 需要ベースのアプローチ

1.2.5.2. バッファーベースのアプローチ

1.2.5.3. 時間ベースのアプローチ

1.2.6. メトリクスに基づいてコンピューティングニーズを再評価する

1.2.6.1. メモリ集約型のシステムであることが判明すればばインスタンスファミリーを変更する、など

1.3. PERF 3. ストレージアーキテクチャの選択

1.3.1. ストレージ特性と要件を理解する

1.3.1.1. オブジェクトストレージ

1.3.1.2. ブロックストレージ

1.3.1.3. ファイルストレージ

1.3.1.4. インスタンスストレージ

1.3.2. 利用可能な設定オプションを評価する

1.3.2.1. EBS

1.3.2.2. S3転送アクセラレーション

1.3.2.3. EFS

1.3.2.4. Amazon FSx

1.3.3. アクセスパターンとメトリクスに基づいて意思決定を行う

1.3.3.1. ブロックストレージかオブジェクトストレージか

1.3.3.2. アクセスパターンに基づいたストレージソリューション

1.3.3.3. RAID0アレイ

1.3.3.4. バースト、固定容量

1.4. PERF 4. データベースアーキテクチャの選択

1.4.1. データベースの特性を理解する

1.4.1.1. リレーショナルデータベース

1.4.1.1.1. EC2、RDS、Aurora、Redshift

1.4.1.2. Key-Valueデータベース

1.4.1.2.1. DynamoDB

1.4.1.3. インメモリデータベース

1.4.1.3.1. ElastiCache

1.4.1.4. ドキュメントデータベース

1.4.1.4.1. DocumentDB

1.4.1.5. ワイドカラムストア

1.4.1.5.1. Amazon Keyspaces

1.4.1.6. グラフデータベース

1.4.1.6.1. Amazon Neptune

1.4.1.7. 時系列データベース

1.4.1.7.1. Amazon TImestream

1.4.1.8. 台帳データベース

1.4.1.8.1. Amazon QLDB

1.4.2. 使用可能なオプションを評価する

1.4.2.1. データベース統合キャッシュ

1.4.2.2. ローカルキャッシュ

1.4.2.3. リモートキャッシュ

1.4.2.4. DynamoDB アクセラレーター

1.4.3. データベースのパフォーマンスメトリクスを収集して記録する

1.4.3.1. AWS X-Ray

1.4.4. アクセスパターンに基づいてデータストレージを選択する

1.4.4.1. トランザクション、スループット、結果整合性

1.4.5. アクセスパターンとメトリクスに基づいてデータストレージを最適化する

1.4.5.1. インデックス作成、キー配布、データウェアハウス設計、キャッシュ戦略

1.5. PERF 5. ネットワークアーキテクチャの選択

1.5.1. ネットワーキングがパフォーマンスに与える影響を理解する

1.5.1.1. すべてのアプリケーションコンポーネント間

1.5.2. 使用可能なネットワーク機能を評価する

1.5.2.1. Global Accelerator、S3コンテンツアクセラレーション

1.5.2.2. 新しいEC2インスタンス、ENA

1.5.2.3. Route 53レイテンシーベースルーティング、VPCエンドポイント

1.5.3. ハイブリッドワークロード用に適切なサイズの専用接続またはVPNを選択する

1.5.3.1. Direct Connect

1.5.3.2. サイト間VPN、Transit Gateway

1.5.4. ロードバランシングと暗号化のオフロードを活用する

1.5.4.1. ELBでSSL終端

1.5.5. ネットワークトラフィックを最適化するネットワークプロトコルを選択する

1.5.5.1. TCPチューニング、最適化された転送プログラム、UDP

1.5.6. ネットワーク要件に基づいてロケーションを選択する

1.5.6.1. ユーザーの所在地

1.5.6.1.1. ユーザーの近くに配置

1.5.6.2. データの場所

1.5.6.2.1. アプリケーションコードの近くに配置しデータ転送を減らす

1.5.6.3. その他の制約

1.5.6.3.1. セキュリティ、コンプライアンス

1.5.6.4. プレースメントグループ、ENA

1.5.6.5. CloudFront、Lambda@Edge

1.5.6.6. Outposts、Local Zones、Wavelength

1.5.7. メトリクスに基づいてネットワーク設定を最適化する

1.5.7.1. VPCフローログ、ネットワークメトリクス

2. リンク

3. トレードオフ

3.1. PERF 8. トレードオフを使用してパフォーマンスを向上させる

3.1.1. パフォーマンスがもっとも重要な分野を理解する

3.1.2. デザインパターンとサービスについて理解する

3.1.2.1. The Amazon Builders' Library

3.1.3. トレードオフが顧客と効率性にどのように影響するかを明らかにする

3.1.4. パフォーマンス向上の影響を測定する

3.1.4.1. トレードオフの発生の理解

3.1.5. さまざまなパフォーマンス関連戦略を使用する

3.1.5.1. 変更時の影響の判断

4. モニタリング

4.1. モニタリングのフェーズ

4.1.1. 生成、集計、リアルタイの処理とアラームの発行、保存、分析

4.2. モニタリングのソリューション

4.2.1. アクティブモニタリング

4.2.2. パッシブモニタリング

4.2.2.1. ユーザーエクスペリエンスパフォーマンス

4.2.2.2. 地理的パフォーマンスの変動性

4.2.2.3. APIの使用による影響

4.3. PERF 7. リソースをモニタリングして、それらが期待通りに機能していることを確認する

4.3.1. パフォーマンスに関連するメトリクスを記録する

4.3.1.1. ワークロードにとって重要なパフォーマンスメトリックを特定

4.3.2. イベントやインシデントが発生したときにメトリクスを分析する

4.3.2.1. ダッシュボード、レポート

4.3.3. ワークロードのパフォーマンスを測定するための主要業績評価指標(KPI)を確立する

4.3.4. モニタリングを使用してアラームベースの通知を生成する

4.3.4.1. CloudWatch

4.3.5. メトリクスを定期的に見直す

4.3.6. モニタリングしてプロアクティブに警告する

5. 確認

5.1. パフォーマンスレビューアプローチ

5.1.1. Infrastructure as code

5.1.2. Deployment pipeline

5.1.3. 明確に定義されたメトリクス

5.1.4. パフォーマンステストの自動化

5.1.5. 負荷の生成

5.1.6. パフォーマンスの可視性

5.1.7. 可視化

5.2. PERF 6. ワークロードを進化させて新しいリソースを活用する

5.2.1. リソースとサービスに関する最新情報を常に入手する

5.2.1.1. AWSのアップデート、新機能の評価プロセス

5.2.2. ワークロードのパフォーマンス向上プロセスを定める

5.2.2.1. 評価プロセス、パフォーマンスの制約の文書化

5.2.3. ワークロードのパフォーマンスを時間の経過とともに進化させる

5.2.3.1. 変化の推進

6. 設計原則

6.1. 高度なテクノロジーの民主化: 複雑なタスクをクラウドベンダーに委託する

6.2. わずか数分でグローバルに展開する

6.3. サーバーレスアーキテクチャを使用する

6.4. より頻繁に実験する

6.5. メカニカルシンパシーを重視する