AWSのWell-Architected Frameworkを5本の柱ごとに自分なりの解釈を書いていきたいと思います。
※誤りがあればコメント頂けると嬉しいです。
今回はパフォーマンス効率についてです。
パフォーマンス効率とは
システムの要件を満たすためにコンピューティングリソースを効率的に使⽤し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能⼒
パフォーマンス効率の柱ではどのアーキテクチャを採用するかという設計が重要になります。
「効率」が含まれていることからシステムの要件を満たすのみでなく、リソースを有効活用することも考慮しなければならないことが分かります。
システムのアクセス傾向（読み込みが多いか、書き込みが多いかや多重度など）によって、
どのアーキテクチャが適しているか選択します。
設計の原則
パフォーマンス効率には、5 つの設計の原則があります。
| No | 設計の原則 | 概要 |
|---|---|---|
| 1 | 最新テクノロジーの標準化 | NoSQL、機械学習などの専門領域でも利用することは難しくない |
| 2 | 数分でグローバルに展開 | 数クリックで世界中にデプロイ。世界中にデプロイすることでレイテンシを短縮 |
| 3 | サーバーレスアーキテクチャを使⽤ | サーバ運用コストの削減。スケールの考慮が不要になる |
| 4 | より頻繁に実験可能 | リソースを柔軟に変更可能。 |
| 5 | システムを深く理解 | 実現しようとすることに最も適した技術アプローチ（データベース、ストレージなど）を使⽤ |
ベストプラクティス
⾼性能なアーキテクチャを選択する際は、データ駆動型のアプローチを選択します。
※データ駆動：データを収集してその結果からアーキテクチャを選択する。
| No | ベストプラクティス | 概要 |
|---|---|---|
| 1 | 選択 | データ駆動型のアプローチを選択（性能試験の結果を判断基準にする） |
| 2 | レビュー | 定期的に構成確認し、AWSの新サービスの利用を検討 |
| 3 | モニタリング | メトリクスが閾値を超えた際にアラーム＆自動アクション |
| 4 | トレードオフ | 耐久性重視かパフォーマンス重視かで適切なリソースを選択 |
選択
システムにとって最適なソリューションは、お客様のワークロードの種類に応じて異なります。
選択では下記４つのリソース別にどのような選択肢があるか紹介されています。
| No | リソース | 選択、基準 |
|---|---|---|
| 1 | コンピューティング | インスタンス or コンテナ or ファンクション |
| 2 | ストレージ | オブジェクトストレージ(S3) or ファイルストレージ(EFS) or ブロックストレージ（EBS） |
| 3 | データベース | RDB or NoSQL or DWH |
| 4 | ネットワーク | 拡張ネットワーク、動的（？）CloudFront、EBS最適化インスタンス |
インスタンス（サーバ）、コンテナ、ファンクション、メリデメ・選択基準
| No | リソース | 運用コスト | 拡張性 | 性能設計 | 利用効率 | AWS サービス |
|---|---|---|---|---|---|---|
| 1 | インスタンス | 大（ペットになってしまう） | 一般的に低め | 必要 | システム特性による | EC2 |
| 2 | コンテナ | 中（家畜として扱う） | インスタンスと比較すると高め | 必要 | システム特性による | ECS、Fargate |
| 3 | ファンクション（サーバレス） | 無し | 考慮不要 | 考慮不要 | システム特性による | Lambda、Step Functions |
上記の３つ選択肢がありますが、サーバレスアーキテクチャ利用の原則から
採用の優先順位はNo３⇒２⇒１の順だと思います。
（まずファンクションを検討し、難しそうならコンテナで検討する。）
※コスト比較が重要な気がしますが、それはコストの柱で検討するためここでは割愛します
コンテナについては以下の説明が分かりやすいと思います。
https://geekly.co.jp/column/cat-technology/1902_047/
まだまだファンクション（サーバレス）だけでシステムを構成できないことは多々あると思います。
コンテナとインスタンスの運用コストの差を理解するにあたり、
ペットと家畜という考え方が分かりやすいと思います。
https://blogs.itmedia.co.jp/narisako/2014/07/post-047f.html
クラウドでは家畜として扱えとありますが、
インスタンスを利用した場合、まだまだペットで扱う場面が多いように感じます。
コンテナでは家畜として扱わざるを得ない機能（設定変更は永続しない）などが備わっています。
ストレージ選択基準
システムにとって最適なストレージソリューションは、アクセス⽅法 (ブロック、ファイル、オブジェクト)、アクセスパターン (ランダムまたはシーケンシャル)、必要なスループット、アクセス頻度 (オンライン、オフライン、アーカイブ)、更新頻度(WORM、動的)、および可⽤性と耐久性に関する制約に応じて異なります。
| No | リソース | 概要 | 用途 | 速度 | 利用効率 | AWSサービス |
|---|---|---|---|---|---|---|
| 1 | ファイルストレージ | フォルダ、ファイルで構成される | NAS（ファイルサーバ）として利用 | 中速 | 中 | EFS |
| 2 | オブジェクトストレージ | 格納数には制限なく、スケールアウトが簡単 | 主にアーカイブ、バックアップとして利用 | 低速 | 高 | S3 |
| 3 | ブロックストレージ | 高性能を必要とするアプリケーションに適する | 主にSAN（Storage Area Network）ストレージで利用 | 高速 | 低 | EBS |
ファイルストレージ、ブロックストレージ、オブジェクトストレージの比較
https://www.redhat.com/ja/topics/data-storage/file-block-object-storage
データベース選択基準
システムにとって最適なデータベースソリューションは、可⽤性、整合性、パーティ
ション対応性、レイテンシー、耐久性、スケーラビリティ、クエリ機能などの要件に
応じて異なります。
| No | リソース | 概要 | 用途 | AWS サービス |
|---|---|---|---|---|
| 1 | RDB | リレーショナルDB | 一般的なデータベース | RDS |
| 2 | No SQL | 可用性が高く、スケーラブルで、高パフォーマンス用 | RDBでは対処しづらいようなビッグデータに対応すべく生み出された技術 | DynamoDB |
| 3 | DWH | 過去データを整理して保管しておく「倉庫」的な役割を果たすデータベースのこと。 | 分析用途として利用されることが多い | RedShift |
・【超入門】RDBとNoSQLの違いに着目！NoSQLに求めるものとは？
http://tech-blog.rakus.co.jp/entry/20180919/nosql/bigdata
・DWHとは（AWS再入門 Amazon Redshift編）
https://dev.classmethod.jp/cloud/aws/cm-advent-calendar-2015-getting-started-again-aws-redshift/
・Amazon DynamoDB がニーズに合うかどうかを判断し、移行を計画する方法
https://aws.amazon.com/jp/blogs/news/how-to-determine-if-amazon-dynamodb-is-appropriate-for-your-needs-and-then-plan-your-migration/
ネットワーク選択基準
システムにとって最適なネットワークソリューションは、レイテンシーやスループット
などの要件によって異なります。
ネットワークパフォーマンス向上に利用できるAWSサービス
-
拡張ネットワーク
高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/enable-configure-enhanced-networking/ -
EBS 最適化インスタンス
EBS ボリュームの高パフォーマンスを提供
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-optimized.html -
Amazon S3 Transfer Acceleration
クライアントと S3 バケットの間で、長距離にわたるファイル転送を高速、簡単、安全に行える
中央のバケットに対して世界中のお客様からアップロードが行われる場合などに利用
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/transfer-acceleration.html -
CloudFront
AWSのCDNサービス
CDN（コンテンツ・デリバリ・ネットワーク）とは／What is CDN
https://www.cdnetworks.co.jp/about/
-
Amazon Route 53 のレイテンシールーティング
複数の AWS リージョンにリソースがあり、レイテンシーの最も小さいリージョンにトラフィックをルーティングする場合に使用
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/routing-policy.html -
Amazon VPC エンドポイント
サポートされている AWS サービスや VPC エンドポイントサービスに VPC をプライベートに接続できる
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-endpoints.html -
AWS Direct Connect
拠点間の専用線接続
AWS Direct Connectの「3つのメリット」と「導入方法」を理解する
https://businessnetwork.jp/Detail/tabid/65/artid/3836/Default.aspx
レビュー
ソリューションを設計するときは、選択できるオプションが限られていても、時間が経つにつれ、アーキテクチャのパフォーマンスを向上させることができる新しいテクノロジーやアプローチが利⽤できるようになります。
執筆中
モニタリング
アーキテクチャの実装後は、お客様が発⾒する前に問題を修正できるよう、アーキテク
チャのパフォーマンスをモニタリングする必要があります。
執筆中
トレードオフ
整合性、耐久性、容量を重視するのか、時間またはレイテンシーを重視するのかを、お客様の状況に応じてトレードオフしてください。
執筆中
主要なAWSのサービス
パフォーマンス効率に不可⽋なAWS のサービスは Amazon CloudWatch であり、リソースとシステムをモニタリングし、全体的なパフォーマンスと動作状況を可視化します。
| No | 分野 | AWSサービス |
|---|---|---|
| 1-1 | 選択－コンピューティング | AutoScaling |
| 1-2 | 選択－ストレージ | Amazon EBS（SSD、PIOPS）、Amazon S3 |
| 1-3 | 選択－データベース | Amazon RDS、Amazon DynamoDB |
| 1-4 | 選択－ネットワーク | Amazon Route 53、Amazon VPC(エンドポイント)、AWS Direct Connect |
| 2 | レビュー | AWS ブログ、 AWS ウェブサイトの「最新情報」セクション |
| 3 | モニタリング | Amazon CloudWatch、AWS Lambda |
| 4 | トレードオフ | Amazon ElastiCache、Amazon CloudFront、AWS Snowball、Amazon RDS（リードレプリカ） |
レビューシート実践
-
パフォーマンス 項番2 コンピューティングソリューションをどのように選択していますか？
□ 最適なパフォーマンスを得るためにEC2, Container, Lambdaなどの選択肢を考慮している
□ コンピューティングサービスの様々なオプションを考慮している(GPU, I/O, サイズ, コンテナなど)を考慮している
□ コンピュートリソースに関するメトリクスを収集している
□ 収集してメトリクスを分析して、最適なアーキテクチャを決定している
□ 要求の変化に対応できるよう弾力性のある機能を利用している(Auto Scaling, ECS, Lambdaなど)
□ 定期的に、メトリクスに基づき、コンピューティングサービス選択やインスタンスファミリーやタイプ、サイズの再評価を実施している -
パフォーマンス 項番3 ストレージソリューションをどのように選択していますか？
□ 特性(共有, キャッシュ, アクセスパターン, レイテンシ, スループット, 永続性など)を考慮して、
適したストレージサービスを選択している(S3, EBS, EFS, EC2インスタンスストアなど)
□ ストレージの設定オプションを考慮している(PIOPS, SSD, S3 Transfer Accelerationなど)
□ データのアクセスパターンを考慮している (ストライピング, 分散キー, パーティショニング等) -
パフォーマンス 項番4 データベースソリューションをどのように選択していますか？
□ 特性(可用性, 一貫性, パーティション許容値, レイテンシ, 耐久性, スケーラビリティ, クエリ性能等)を考慮して、
適切なデータベースを選択している(RDB, NoSQL, DWH, インメモリキャッシュなど)
□ DBの設定オプションを考慮している(ストレージ最適化, DBレベルの構成, メモリ, キャッシュなど)
□ データベースソリューションに関するメトリクスを収集している
□ データのアクセスパターンを考慮している(Index, 分散キー, パーティショニング, 水平スケーリング等)
□ アクセスパターンとメトリクスに基づいて、データベースソリューションや戦略(インデックス作成、キーの設定、キャッシング戦略など)を決定している
参考ドキュメント
〇AWS Well-Architected
(日本語 201907)
https://d1.awsstatic.com/whitepapers/ja_JP/architecture/AWS_Well-Architected_Framework.pdf?sc_icampaign=aware_well_architected_jp_wa_framework&sc_ichannel=ha&sc_icontent=awssm-3366&sc_iplace=content&trk=awssm-3366_aware_well_architected_jp_wa_framework
〇Well-Architected_review_sheet
https://d1.awsstatic.com/webinars/jp/pdf/services/Well-Architected%E3%83%92%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%82%B7%E3%83%BC%E3%83%88%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88.77c25d2afd0a69894be16b95aae6a423011f5a1f.xlsx