Well-Architected Frameworkの柱「パフォーマンス効率」を読み解いてみた

豊崎隆

2019.05.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ご機嫌いかがでしょうか、豊崎です。

最近Well-Architectedにご縁があり、連続して記事を書いています。今回はWell-Architectedのパフォーマンス効率の柱についてご紹介をしたいと思います。

何度か書いていますが、Well-Architectedとは何か？どういうシステムに使ってもらいたいか？については以下をご覧いただければと思います。

無料のAWS Well-Architected Toolでクラウド最適化への一歩を踏み出そう

さて、改めての記載となるのですが、Well-Architected Framework には５つの観点があります。

5 つの柱などと表現されたりします。

それぞれの柱に対話形式の質問が用意されています。

ここでは実際にどのような質問があるのか、またそれに対してどのような観点を持ってアプローチを行うことが望ましいかを確認していきたいと思います。

そのために各柱の設計原則、定義、ベストプラクティス、キーとなるAWSサービスについて確認していきたいと思います。内容がたっぷりあるので、柱ごとに確認をしていきます。

今回はパフォーマンス効率の柱について確認していきたいと思います。

パフォーマンス効率の柱

パフォーマンス効率の柱にはコンピューティングリソースを効率的に利用してシステムの要件を満たし、需要の変化やテクノロジーの進化に応じてその効率を維持する機能が含まれています。

先進的なテクノロジーをAWSのサービスとして利用することでチームはプロビジョニングや管理を気にすることなく製品開発に集中することができます。

わずか数回のクリックで世界中の地域にシステムを展開することができます。最小限のコストで遅延なく素晴らしい体験をユーザに提供することが可能

サーバレスアーキテクチャの採用により従来のサーバの実行および保守が必要なくなります。サーバレス側のコード管理、保守は必要ですがサーバに対する保守、運用の負荷が軽減されます。

様々なインスタンスやストレージ、設定を利用して比較テストをすぐに行うことができます。

サービスの特性を理解し、実施したいことに対して最もマッチするサービスを利用しましょう。

パフォーマンス効率の柱には以下の4つのベストプラクティス分野があります。これらは以下にあるBest Practicesの項目にある質問およびKey AWS Services とマッピングされた形で確認されます。

ベストプラクティスを確認するために以下のような質問が用意されています。

パフォーマンス効率に不可欠なサービスはAmazon CloudWatchです。リソースとシステムを監視し、全体的なパフォーマンスと運用上の健全性に対する可視性を提供するからです。それ以外にも重要なサービスをみていきましょう。

選択
- コンピューティング
  - AutoScaling
- ストレージ
  - EBS（SSDやPIOPSなど）
  - Amazon S3
- データベース
  - Amazon RDS
  - Amazon DynamoDB
- ネットワーク
  - Amazon Route 53（ルーティング）
  - Amazon VPC
  - AWS Direct Connect
レビュー
- AWS Blog
- AWS website
- etc
モニタリング
- Amazon CloudWatch
  - AWS Lambda(トリガーのアクションとして)
トレードオフ
- Amazon ElastiCache
- Amazon CloudFront
- AWS Snowball
- Read replicas in Amazon RDS

パフォーマンス効率の柱では特性を理解しシステムにマッチしたサービスを利用しパフォーマンスについて監視を行い、新しいテクノロジーに対しては必要に応じてテスト比較を行う旨が記載されています。

選択
- AWS上の複数サービスに対して適切なサービスの選択を行う
レビュー
- 日々アップデートされたテクノロジーについてシステムのパフォーマンス効率を改善できないかの検討
モニタリング
- パフォーマンスについて監視しアラーム通知を行い、必要に応じて自動的なアクションを実行する
トレードオフ
- より高いパフォーマンスを実現するために整合性、耐久性、容量に対する時間と遅延（レイテンシー）のトレードオフを検討する
- 例：DBの負荷を軽減させるためキャッシュを利用するなど