Well-Architected とは？

クラウドアーキテクチャの 「ベストプラクティス」 をAWSがまとめたもの

「優れた運用効率」「セキュリティ」「信頼性」「パフォーマンス効率」「コストの最適化」「持続可能性」の６つの柱で構成されています。

https://aws.amazon.com/jp/architecture/well-architected
階層構造のチェックリストになっていて、これに基づいてレビューすることで「ベストプラクティスがどの程度、適用できているか計測」「改善すべき点の可視化」ができます。

実際にレビューしてみると

レビュー実施してみるとベストプラクティスを満たすには
そのワークロード固有の設計や実装・運用だけでなく組織としての体制やルール、文化・教育にも及ぶことがわかります。

またベストプラクティスの記載は年々わかりやすくなっていますが、具体的な解釈やどこまでやればOKとするか？判断が難しい項目も。

ベストプラクティスに追従するには個々の担当者やグループだけでは難しいものもあり、事業部や会社単位で取り組むのがよいと考えています。

数年前から弊社では「Well-Architected活用ワーキンググループ」という部署横断的なチームを作って活動しているので、今回はざっくり図にまとめてみました。
詳細はまた機会あれば共有させてもらえればと思いますが、同じような取り組みをされている方の参考になれば幸いです。

活用状況

ワーキンググループ

対象とする各部署から１名以上のメンバーを選出してもらいワーキンググループを構成しています。
徐々に対象部署を拡大していっていますが、人数も増えてきたので役割毎にグループ細分化も検討中です。

さまざまな部署から集まってもらっているので事情や状況の違いがミーティングの場ですぐわかる点やりやすいです。
自分は社内サービスの開発エンジニアを主にやっていて、ネットワークやインフラ周り弱い部分があったり、普段使っているAWSサービスにも偏りがあるので議論や実例共有の中で勉強になることが多いです。

方針・計画の策定

ざっくり１年分のおおまかな方針と計画を立てガントチャートに落とし込み、あとはそれを隔週の定例を起点に活動しています。

2019年からAWS Well-Architected パートナープログラムの認定を取得しており、その継続要件のチェックや必要な提出物の対応なども計画に入れ込みます。

①レビュー推進

Well-Architectedのフルレビューは現在、必須ではなく推奨という形をとっています。

はじめてレビューを実施してみるとやはり疑問や迷うところなど出てくるので、これらを共有や相談する場としても定例を使っています。
効率的にレビューできるよう「社内W-Aレビューチートシート」というのを作っています。
チートシートには「社内のこのガイドラインに沿っていればこの項目はこういう理由でOKになるよ！」「こういうった見直しを継続的にしていればOK。初回だけ実施して継続見直しの機会がない場合はNG！」「ここは◯◯を入れる提案をして採用され改善でOKにしたことがある。費用面の説明はこうした」のような判断基準や知見を集約しています。

②ベストプラクティスの項目をひとつずつ議論

定例の中でベストプラクティスを１項目ずつ読み合わせ解釈や判断基準をあわせています。
隔週の定例の最後のアジェンダにもってきて20〜30分くらい、１〜数項目ずつ進めています。
ベストプラクティスには重要度が「高」「中」「低」と分かれており、とくに「高」の項目については時間をとって読み合わせしています。
2023年度は６つの柱のうち「セキュリティの柱」に絞って行い、一巡することができました。
ここで議論した内容はチートシートだけでなく、社内標準やエンプレート、社内教育、社内の仕組みなどへも必要に応じフィードバックや調整をします。

③ レビュー結果分析

溜まったレビューレポートの分析なども合間にちょいちょい進めています。
NG率が高い項目は社内でプラクティスが確立されていない？やリスク受容しているケースが多い？など確認していきます。

おわりに

レビューをすることが目的化すると何かおかしくなり形骸化しはじめるのでAWSがまとめてくれているベストプラクティスをうまく活用し、ポジティブな気持ちで品質担保や効率化に活かしていきたいですね！

ではまた！

AWS Well-Architected の活用状況を図にしてみた