AWS Well-Architected Framework 大幅アップデート!気になった更新をみてみた
朗報!
なにやらAWS Well-Architected Framework に大幅アップデートがあったようです。
改訂履歴から内容を見てみると…
大幅な パフォーマンスの柱 の再編を行い、ベストプラクティス領域を 5 つにしました。セキュリティの柱の インシデント対応 (SEC 10) における、ベストプラクティスとガイダンスの大幅な更新。運用上の優秀性の領域 OPS 04、05、06、08、09 における大幅なコンテンツの変更と統合。コスト最適化と 信頼性の柱の 全体にわたる ガイダンスの 更新。リスクレベルに関し、 持続可能性の柱 にマイナーな更新。
おお、パフォーマンス効率の柱が大幅に変わったらしい。どこが変わったか見てみよう!
柱を 5 つのベストプラクティス領域に再構成 (8 分野から減少)。コンテンツを 5 つの領域に統合し、更新。
以前は8個の設問だったのに5個の設問に再構成されています。
# | 旧版 | 新版 |
---|---|---|
PERF 1 | どのように最良パフォーマンスのアーキテクチャを選択するのですか? | ワークロードに適したクラウドリソースとアーキテクチャパターンを選択する方法を教えてください。 |
PERF 2 | コンピューティングソリューションはどのように選択するのですか? | ワークロードでコンピューティングリソースをどのように選択して使用しますか? |
PERF 3 | ストレージソリューションをどのように選択していますか? | ワークロード内のデータを保存、管理、アクセスする方法を教えてください。 |
PERF 4 | データベースソリューションをどのように選択していますか。 | ワークロードでネットワーキングリソースを選択して設定する方法を教えてください。 |
PERF 5 | どのようにネットワーキングソリューションを選択するのですか? | ワークロードのパフォーマンス効率を高めるために、どのようなプロセスを使用していますか? |
PERF 6 | ワークロードを進化させるためにどのように新機能を取り込んでいますか? | - |
PERF 7 | リソースが稼働していることを確実にするためのリソースのモニタリングはどのように行いますか? | - |
PERF 8 | トレードオフをどのように使用するとパフォーマンスが向上するのですか? | - |
まとめるとこのようになっていました。
- ストレージソリューションとデータベースソリューションがマージされた
- ワークロードの進化とリソースのモニタリングの話がマージされた
- トレードオフの話が消えた
良い感じに整理整頓されたみたいですね!トレードオフの話は正直僕も、お客さんに喋るときになかなか腹落ちしない分野だったので助かりました…
ちなみに当たり前かもですが、パフォーマンス効率の柱の設計原則に変わりはないので、本質的な見直しが入ったわけではないです。あくまで評価する角度とベストプラクティスにアップデートが入ったということですね!
パフォーマンス効率の柱 設計原則
ベストプラクティスについてみてみる
ベストプラクティスはどんなアップデートがあったのか、気になったものを何個かピックアップしてみていきます。
PERF01 アーキテクチャの選択
BP01 利用可能なクラウドサービスと機能について学び、理解する
01なので一番重要なことです。以前は「利用可能なサービスやリソースを理解する」という表記でした。ニュアンスとして視野が広がったことと 「学んで」 理解することが協調された形でしょうか。AWSというクラウドサービスについて学ばないままではパフォーマンス効率は語れないということですね。
BP02 クラウドプロバイダーまたは適切なパートナーからのガイダンスを使用して、アーキテクチャパターンとベストプラクティスについて学ぶ
以前は「クラウドプロバイダー、または適切なパートナーからのガイダンスを利用する」という表記でした。何に対してガイダンスを受けて、何を学ぶべきなのかより明確に表現されるようになりました。これも01とつながる話ですね。
PERF02 コンピューティングとハードウェア
BP04 コンピューティングリソースの設定とライトサイジングを行う
以前は恐らく「適切なサイジングによって必要な設定を決定する」という表記でした。ふわふわっとした言い方から「ライトサイジング」と言い切ることでより明確になりましたね。「ライトサイジングにより、組織はビジネスニーズに対応しながら、効率的かつ費用対効果の高い方法でクラウドインフラストラクチャを運用できます。」とも言い切られてます。やりましょう、ライトサイジング。
BP06 最適化されたハードウェアベースのコンピューティングアクセラレーターを使用する
以前はアクセラレーションについて言及したベストプラクティスはありませんでした。機械学習や生成系AIが伸びている時代の流れでしょうか。
PERF03 データ管理
BP01 データアクセスとストレージ要件に最適な専用データストアを使用する
以前は「特性(と要件)を理解する」というあいまいな表記でしたが、最適なデータストアを利用せよと明確に表記されるようになりました。
ドキュメントにもかなり詳しくデータベースとストレージタイプの使い分けが書かれています。これ頭に入れれば完璧になれます。
BP05 キャッシュを利用するデータアクセスパターンを実装する
こちらもキャッシュ利用について具体的に名言されるのは初めてでした。「~最適化する」のような利用者に委ねたものはありましたが、AWSとして必要だ、大事だと思ったゆえの判断ですね。
それを裏付ける、Amazon ElastiCache Well-Architected レンズ という新概念が登場してました。
PERF04 ネットワークとコンテンツ配信
あんまり変わってませんでした。
PERF05 プロセスと文化
BP04 ワークロードの負荷テストを実施する
信頼性の柱では障害テストについて以前から触れられていましたが、パフォーマンス効率の柱で具体的に言及されたのは初めてかもしれません。
パフォーマンスが重要な分野を特定し、KPIを達成するためにはどれくらいの負荷に耐えられないといけないのか?を知ることは重要です。とりあえずやってみようぜ!という心も大事ですが…。
BP05 自動化でパフォーマンス関連の問題をプロアクティブに修正する
これも、自動化について言及されたのはこの柱では初めてだと思います。以前の「プロアクティブに警告する」が「プロアクティブに修正する」に昇格されました。インシデントをリアルタイムで受け取るだけでなく、リアルタイムに修正することが求められる時代になったんですね。もちろん、それを可能とする技術の進歩があったからです。(僕の大好きなサービス SystemsManager がそれです!)
まとめ
今回のアップデートで、よりやるべきことが分かりやすくなったと思います。読みものとしても非常に優秀なのでぜひホワイトペーパー読んでください!
Discussion