2022バージョンについて

新バージョンをリリースしています。 今後はこちらをご参照ください。

以下2021バージョン

AWS認定トレーニング講師の平野@おんせん県おおいたです。

今日はWell-Architectedがテーマです。

はじめに

AWS Well-Architected フレームワークとは

AWSとAWSユーザの10年以上の経験からまとめられたベストプラクティクス集です。 いいかえれば、多くの失敗反省を元に作られています。 これからAWSを活用する際に、皆さんが同じ失敗をしないためのガイドラインとも言えます。 AWSを始めたら、まずは目を通してもらいたいドキュメントです。

とはいえ...

とはいえ、このドキュメントなかなか読みづらいです。 私も正直最初は？？？という感じでした。 そこで、これからWell-Architected ドキュメントを読む方のサポートができないかと思い、このブログを描いてみました。 皆様のWell-Architectedライフをにお役立てください。

こんな人にオススメ

AWSの勉強を始めた人

これからAWSを始める方には、どのようなベストプラクティクスがあるのか全体に目を通して、頭の片隅に置いていてもらいたいです。 ベストプラクティクスには、AWSが解決しようとしている顧客の課題が反映されています。 解決したい課題が頭に入っていると、AWSのサービスを学ぶ際、理解の助けになります。

様々なプロジェクトに携わっている人

業務でAWSを利用する際は、AWSへの投資対効果を最大限に発揮するために、Well-Architectedレビューが推奨されています。 レビューにWell-Architected Toolを活用することも多いと思います。 その際、ドキュメントを調べるための索引集/ハンドブックとしてこのブログを活用いただけると嬉しいです。

Well-Architected ドキュメントの歩き方 -読み方ガイド-

ますは、ドキュメントの読み方として、ドキュメントの構成（読むポイント）を紹介します。 そして、このブログが取り上げる索引集について説明します。

ドキュメントの全体構成

Well-Architected ドキュメントの構成をまとめたものがこの図になります。

階層構造が深くて、無意識に先頭から読み進んでいると今どこにいるか迷宮に入ってしまいます。 一方で、この構造を理解しておくと、とても読みやすくなります。

とはいえ、最初からこの構造を全て見ていくのは大変です。

そこで、最初は「柱」と「質問」からおさえていくことをお勧めします。

「柱」はWell-Architectedのカテゴリを示していて、５つの柱から構成されています。まずは各柱の目的を考えてみてください。

「質問」はベストプラクティクスが解決すべきゴールです。言い換えれば、「AWSを活用して得られる効果」ということになります。どういうお困りごとを解決できるか想像しながら考えてみてください。

このブログに取り上げる範囲

このブログでは、１ページにおさまる範囲で「ドキュメント索引集」としてまとめました。 そして、まずおさえてもらいたい「柱」と「質問」にフォーカスが当たるように、全体構成の中の次の黄色部分をピックアップしてまとめています。

さらに詳細を調べたい場合は、各柱/質問ごとにAWSドキュメントの詳細ページへのリンクを貼っていますので、活用してください。

AWS Well-Architected ドキュメント索引集

ここからがこのブログの本題です。各柱/質問を中心にまとめています。 各質問ごとにぺストプラクティクスを箇条書きに記載しています。ぺストプラクティクスの詳細を調べる際は各質問に公式ページのリンクを貼ってますので、参考にしてください。

また、上から順に読む必要はありません。興味が持てる柱、ベストプラクティクスから始めてみましょう。挫折しないよう工夫してご利用ください。

一般的な設計原則

設計原則

• キャパシティーニーズの推測が不要
• 本稼働スケールでシステムをテストする
• ⾃動化によってアーキテクチャでの実験が容易に
• 発展するアーキテクチャが可能に
• データに基づいてアーキテクチャを駆動
• ゲームデーを利用して改善する

運用上の優秀性の柱

設計原則

• 運用をコードとして実行する
• 小規模かつ可逆的な変更を頻繁に行う
• 運用手順を定期的に改善する
• 障害を予想する
• 運用上のすべての障害から学ぶ

ベストプラクティス

セキュリティの柱

設計原則

• 強力なアイデンティティ基盤の実装
• トレーサビリティの実現
• 全レイヤーでセキュリティを適用する
• セキュリティのベストプラクティスを自動化する
• 伝送中および保管中のデータの保護
• データに人の手を入れない
• セキュリティイベントに備える

ベストプラクティス

信頼性の柱

設計原則

• 障害から自動的に復旧する
• 復旧手順をテストする
• 水平方向にスケールしてワークロード全体の可用性を高める
• キャパシティーを推測することをやめる
• オートメーションで変更を管理する

ベストプラクティス

パフォーマンス効率の柱

設計原則

• 最新テクノロジーの標準化
• わずか数分でグローバル展開する
• サーバーレスアーキテクチャを使用する
• より頻繁に実験する
• システムに対する精通の程度を考慮する

ベストプラクティス

コスト最適化の柱

設計原則

• クラウド財務管理の実装
• 消費モデルを導入
• 全体的な効率を測定する
• 差別化につながらない高負荷の作業に費用をかけるのをやめる
• 費用を分析および属性化する

ベストプラクティス

まとめ

AWSを理解する上でWell-Architectedは大切なものです。ただ、ドキュメントのボリュームの多さに二の足を踏む方もたくさんいると思います（私もそうでした）。このブログがそういう方の背中を押せれば幸いです。