AWS Well-Architected ドキュメントが読みやすくなりました！！（AWS Well-Architected ドキュメントの歩き方2022）
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS認定トレーニング講師の平野@おんせん県おおいたです。
さて、2021年に下記のような Well-Architected フレームワークのブログを書きました。
最近AWS Well-Architectedのドキュメントがアップデートされましたので、それに伴いブログも新しくリリースしました。
おもな変更点
ドキュメント構成の改善に対応
ドキュメント自体が読みやすくなりました（詳細は後述）。それに対応して、内容を変更しました。
新しい柱への対応
2021年12月に「持続可能性の柱」が追加されましたので、この新しい柱についての記事を追記しています。 尚、2022.1.9時点で日本語化されておりませんので
- ブログ内の見出しは、私の方で日本語訳したもの
- 各リンク先は英語ページ
となっておりますので、ご了承ください。
はじめに
AWS Well-Architected フレームワークとは
AWSとAWSユーザの10年以上の経験からまとめられたベストプラクティス集です。 いいかえれば、多くの失敗反省を元に作られています。 これからAWSを活用する際に、皆さんが同じ失敗をしないためのガイドラインとも言えます。 AWSを始めたら、まずは目を通してもらいたいドキュメントです。
こんな人にオススメ
AWSの勉強を始めた人
これからAWSを始める方には、どのようなベストプラクティスがあるのか全体に目を通して、頭の片隅に置いていてもらいたいです。 ベストプラクティスには、AWSが解決しようとしている顧客の課題が反映されています。 解決したい課題が頭に入っていると、AWSのサービスを学ぶ際、理解の助けになります。
様々なプロジェクトに携わっている人
業務でAWSを利用する際は、AWSへの投資対効果を最大限に発揮するために、Well-Architectedレビューが推奨されています。 レビューにWell-Architected Toolを活用することも多いと思います。 その際、ドキュメントを調べるための索引集/ハンドブックとしてこのブログを活用いただけると嬉しいです。
Well-Architected ドキュメントの歩き方 -読み方ガイド-
ますは、ドキュメントの読み方として、ドキュメントの構成（読むポイント）を紹介します。 そして、このブログが取り上げる索引集について説明します。
ドキュメントの全体構成
今回のアップデートの目玉の一つは、ドキュメントの構成がわかりやすくなったことです。
例えば、以前の構成はこのような形でした。
階層構造が深くて、無意識に先頭から読み進んでいると今どこにいるか迷宮に入ってしまうという課題がありました。これが今回のアップデートで、次のようになりました。
かなり読みやすくなりましたね。
これに合わせて、索引集もシンプルに再構成しました。 詳細は以下をごらんください。
AWS Well-Architected ドキュメント索引集
各柱の領域/トピックを見出しに索引集をまとめてます。
一般的な設計原則
設計原則
- キャパシティーニーズの推測が不要
- 本稼働スケールでシステムをテストする
- ⾃動化によってアーキテクチャでの実験が容易に
- 発展するアーキテクチャが可能に
- データに基づいてアーキテクチャを駆動
- ゲームデーを利用して改善する
運用上の優秀性の柱
設計原則
- 運用をコードとして実行する
- 小規模かつ可逆的な変更を頻繁に行う
- 運用手順を定期的に改善する
- 障害を予想する
- 運用上のすべての障害から学ぶ
内容
| 領域 | トピック |
|---|---|
| 組織 | 組織の優先順位 |
| 運用モデル | |
| 組織カルチャー | |
| 準備 | テレメトリを設計する |
| 運用のための設計 | |
| デプロイのリスクを緩和する | |
| 運用準備状況 | |
| 運用する | ワークロードの状態の把握 |
| 運用状態の把握 | |
| イベントへの対応 | |
| 進歩する | 学習、共有、改善 |
セキュリティの柱
設計原則
- 強力なアイデンティティ基盤の実装
- トレーサビリティの実現
- 全レイヤーでセキュリティを適用する
- セキュリティのベストプラクティスを自動化する
- 伝送中および保管中のデータの保護
- データに人の手を入れない
- セキュリティイベントに備える
内容
| 領域 | トピック |
|---|---|
| セキュリティの基礎 | ワークロードを安全に運用する |
| AWS アカウントの管理と分離 | |
| アイデンティティとアクセス管理 | アイデンティティ管理 |
| アクセス権管理 | |
| 検出 | 設定 |
| 調査 | |
| インフラストラクチャ保護 | ネットワークの保護 |
| コンピューティングの保護 | |
| データ保護 | データ分類 |
| 保管中のデータの保護 | |
| 転送中のデータの保護 | |
| インシデント対応 | クラウドレスポンスの設計目標 |
| 教育 ※ | |
| 準備 | |
| シミュレーション | |
| イテレーション |
※ 2022.1.9の段階で日本語ページに間違いがあります。AWSにFeedbackしていますので、修正されるまでは英語版に切り替えてご確認ください。
信頼性の柱
設計原則
- 障害から自動的に復旧する
- 復旧手順をテストする
- 水平方向にスケールしてワークロード全体の可用性を高める
- キャパシティーを推測することをやめる
- オートメーションで変更を管理する
内容
パフォーマンス効率の柱
設計原則
- 最新テクノロジーの標準化
- わずか数分でグローバル展開する
- サーバーレスアーキテクチャを使用する
- より頻繁に実験する
- システムに対する精通の程度を考慮する
内容
コスト最適化の柱
設計原則
- クラウド財務管理の実装
- 消費モデルを導入
- 全体的な効率を測定する
- 差別化につながらない高負荷の作業に費用をかけるのをやめる
- 費用を分析および属性化する
内容
| 領域 | トピック |
|---|---|
| クラウド財務管理を実践する | 機能オーナーシップ |
| 財務とテクノロジーのパートナーシップ | |
| クラウドの予算と予測 | |
| コスト意識の高いプロセス | |
| コスト意識を持つ文化 | |
| コスト最適化によるビジネス価値の数値化 | |
| 経費支出と使用量の認識 | ガバナンス |
| コストと使用量のモニタリング | |
| リソースを削除する | |
| 費用対効果の高いリソース | サービスを選択する際にコストを評価する |
| 正しいリソースタイプ、リソースサイズ、リソース数を選択する | |
| 最適な料金モデルを選択する | |
| データ転送を計画する | |
| 需要を管理し リソースを供給する |
需要の管理 |
| 動的供給 | |
| 継続的最適化 | 継続的最適化 |
持続可能性の柱（英語）
設計原則
- 影響を把握する
- サステナビリティの目標を設定する
- 利用率の最大化
- より効率的な新しいハードウェアおよびソフトウェア製品を予測し採用する
- マネージドサービスを利用する
- クラウドワークロードの下流への影響を低減する
内容
| 領域 | トピック |
|---|---|
| 改善プロセス | 改善目標の設定 |
| 具体的な改善点の評価 | |
| 優先順位付けと改善計画 | |
| 改善点のテストと検証 | |
| 変更を本番にデプロイする | |
| 結果の測定と成功の再現 | |
| 非機能要件としての持続可能性 | 非機能要件としての持続可能性 |
| クラウドにおける 持続可能性のための ベストプラクティス |
リージョン選択 |
| ユーザーの行動パターン | |
| ソフトウェアとアーキテクチャのパターン | |
| データパターン | |
| ハードウェアのパターン | |
| 開発・デプロイプロセス |
まとめ
AWSを理解する上でWell-Architectedは大切なものです。今回のアップデートで読みやすくなりましたので、ぜひ多くの方に学んでいただきたいです。
