Well Architected Framework実践②レビューと運用
投稿日: 2023/3/1
はじめに
こんにちは。山下です。
前回はAWSのWell Architected Frameworkの概要について触れました。
システムに必要な非機能要件を満たすための6つの観点(＝柱)がありました。前回は概要について触れましたが、今回は実際に柱の適用を試みてみます。
前回は柱の概要について触れてきましたが各柱にはさらに細かくベストプラクティスの項目が設けられています。こちらの数は非常に膨大で、これをきっちり形式立てて進める、関係者を巻き込んでやるのは骨が折れます。これを補助、運用するためにAWSではレビュー体制について方針と推奨案を提示しています。
[レビュープロセス]
https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.thereviewprocess.wa-review.ja.html
レビューの方針
①何日もかけてレビューは行わず数時間で終わる内容にする
会議の日程やその都度議題を分けるなどせず、メンバーを揃えたらその場で一気に実施する。
日にちを置いてしまうと思い出すのに時間がかかり、単純に拘束時間が長く業務に支障が出ます。一気にやってしまう方が時間的にメリットがあります。
②非難せずに内容を掘り下げる
監査するためではなく、問題と改善策の洗い出しをブレスト形式で行う。
レビュー自体が苦痛となったり、会議準備の負担が重くなってしまうので、ワークショップやセミナー感覚で少しオープンな雰囲気でやることが挙げられます。
③アーキテクチャを継続してレビューする
一度のレビューに全ての内容を網羅させる、完璧にしようとは考えず徐々に改善に向かわせる。
もっとコストを下げられないか、運用負荷を下げられないか、性能を改善できないかなど継続して検討します。
④設計の初期段階/本番運用前におけるレビュー
一度決定したアーキテクチャに対して変更を加えると手戻りが発生するだけでなく関連箇所への見直しも発生するため、可能なら初期からレビューを実施する。
初期の概要設計、全体構成の時点でレビューしないで途中から実施する場合、全体構成の見直しや途中まで進めていた設計や実装を手直す必要があるので初期段階で実施できるのが望ましいです。
⑤レビュー完了後の課題一覧に優先順位を立て早く対処する
問題/課題の一覧が洗い出されることにより、重要度と緊急性、業務への影響を可視化・検討できる。漠然とした状態で課題を話し合うよりもフレームワークの柱に合わせて観点を整理する事で課題と対策を具体的かつ優先度を決めて話すことができます。
レビュー実践
次に私なりに自分の組織やお客様の状況を踏まえて実際にやってみた内容をあげてみます。改善の余地はまだまだあると思いますが、これは顧客向けでも社内向けでも適用可能で有用と感じております。
初回レビュー前にもっとベストプラクティスのチェックを行っても良いのですが、そもそもの全体像や機能要件、非機能要件が定まりきっていない中で進めると手戻りが多くなる経験をしております。そのため、まずは構成や全体像が把握できた後にWell Architectedレビューを当てはめるようにしています。
実践内容
初回レビュー前
- ベストプラクティス一覧をまず見ずに柱ごとに要件を洗い出し一覧化する
- 柱ごとの要件一覧をスプレッドシートまたはスライドにまとめる
- 要件を満たすAWSサービス一覧と構成図を数案PowerPoint,Keynote,DrawIOなどで作成する
- 要件一覧と構成図案をレビュー参加者に事前共有する
初回レビュー
- 要件一覧について概要を説明し質問や異論を求め認識を合わせる
- 複数の構成案に対して5つの柱の観点でメリットデメリットを説明し異論を求める
- 可能なら構成図やオンラインホワイトボードをメンバーで共有し書き込みを行う
- 質問や異論、新しく出た案をリストアップする
2回目レビュー
- 初回レビューで出た課題に対して優先度を決め、実施時期と対策案を提示する
- レビューを受けて再考したAWSサービス一覧と構成図を再作成or修正する
3回目以降レビュー
- 構成図と要件を元に作成した設計に対して各柱のベストプラクティスをWA Toolを利用してチェック・適用していく
- 各柱について継続して改善案を考える(もっとセキュリティを強化できないか、安くできないか、運用負荷を下げられないかなど)
まとめ
AWSとしてもホワイトボードの利用や構成図、チェックリストを準備することを推奨しています。 フレームワークを有効活用し、会議時間や開催負荷を下げるためにもたたき台となる内容は必要です。システムに必要な５つの柱に合わせた要件整理＞全体構成イメージ＞認識合わせ＞修正＞ベストプラクティスの適用と進め、それを設計フェーズ、実装フェーズ、運用フェーズで見直すことで有用なものになると考えています。
何日もかけずに会議時間を減らし一気に実施する、関係者/ステークホルダーを全て巻き込むというのがチームの規模、会社の組織体制や担当者のスキル(AWSにどれだけ精通しているか)に依るため、実践する中で一番難しいと感じている点です。
しかし、レビュー方針にもある通り、監査のように形式立てて実施せずレビューを継続的に実施することが求められています。このレビュー自体も実施する中でやり方や内容を日々改善する事が一番重要と解釈しています。大変ではありますが非常に有用です。
完璧を求めず行動しながら改善し、関与するお客様やメンバーとともに責め合わず意見を交わし成長していくのがレビューのあるべき姿だと考えています。一見理想論に見えますが、メンバー間でよりビジネスを良くしたい、運用負荷を下げたいor下げてあげたいなどビジョンや思い、目標が一致し共有された時、生産的なレビューが自ずと行えるようになると思います。まずは実践して楽しみましょう！
CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。
