Well-Architectedレビューの啓蒙活動

社内LTで使用した資料の社内情報削除版

Transcript

1. Well-Architected レビューのススメ 山本 直弥 2024年9月27日 社内LT会
2. 自己紹介 名前：山本 直弥 Well-Architected Program リード 2023-2024 Japan AWS All Certifications Engineer 好きなAWSサービス： AWS Lambda AWS Step Functions Amazon Redshift 1
3. ＜今日のLTの目的＞ Well-Architected レビューの社内向け啓蒙活動 2
4. ＜今日のLTで伝えたいこと＞ ・Well-Architected レビューは有意義なもの ・ Well-Architected レビューは時間をかけなくてもできる ・ まずは、チェック項目を知ることから始めてほしい 3
5. Well-Architected (W-A) レビューとは？ 4
6. Well-Architectedレビューとは？ • クラウド設計のベストプラクティス集で作られたチェックリスト (Well-Architected Framework)を元にチェックするレビュー • ６つの柱(観点)毎に質問形式のチェック項目がある(合計60問弱) • 実施するとベストプラクティスとの差(リスク)が出ている内容が把握できる →もれなく検討できているか？次の改善は何をすればよいか整理できる 5 2021年追加
7. どんなチェック項目がある？ 6
8. 実際の質問例 • 運用上の優秀性 1問目 7 ◼ 信頼性 9問目 AWSリソースの設定をどうす るか等の専門的な記載はない マネジメント目線のチェックもエンジニア目線のチェックも両方ある チェック項目を知るだけでも勉強になる(AWS以外のチェックとしても有用) 経験や勘に頼らないレビューができる 難しい横文字が多い １つの「質問」に５つくらい の「チェック項目」がある
9. どうやって進めればよい？ 8
10. Well-Architectedレビューの進め方 • お客様のビジネス/技術リーダーを中心に各質問の内容を認識合わせしながら進める (AWSのBoot Campだとこの方法なので推奨はこの方法？) • PJの状況や企業の制約が様々あるため、 実際の進め方はレビューを実施する企業(あるいはチーム)が決定する 9 設計資料や要件定義の資料などからわか る範囲でレビューする (下流工程でもリスクを洗い出すために有効) Well-Architected チェックリスト お客様と認識合わせしな がら進める (上流工程だと手戻り少ない)
11. W-Aレビューを進める上での課題は？ 10
12. W-Aレビューの課題 • レビューに時間がかかる • 仮に1つの質問10分でできても約600分 (約60問分） • 打合せ有なら時間×人数の工数がかかる • チェック項目内の一部の単語を理解するのにも時間がかかる 11 そんな時間は工数は見積に含んでない ただのレビューにそんな時間かけられない 顧客の理解が得られない エグゼクティブスポンサー? テレメトリー？ バルクヘッドアーキテクチャ？ 難しい単語を調べるのも大変
13. W-Aレビューの時間を節約するには？ 12
14. W-Aレビューの前提の理解 • 全ての質問に答える必要はない • PJと関係がある項目、時間的制約、顧客と合意した範囲の中でできる範囲でOK • まずはリスクは把握することが大切(顕在化) • 修正する必要があるかどうかはそのPJ次第 →顧客の意向等を考慮してビジネス的な判断をすることが重要 • ベストプラクティスはあくまで一般的な原則、必ずしも合わせる必要はない • 大体のPJは何かしらのリスクが複数発見されるのが普通 13 チェックに時間はかかりそうだけど、ある程度はコントロールできそう リスクは普通にあるものとして把握する事が大切 リスクがあることは設計スキル不足や恥ずかしいことではない
15. 個人的理想案： W-Aの観点を事前に学んでいる状態でPJを進める • PJを進める中で自然にW-Aの観点の検討が取り入れられる形を目指したい • W-Aレビューは早い段階で行うほど手戻りが少ない • 必要なチェック項目の選定がPJ進捗に合わせてできる • PJ担当者がW-Aを知っていると各工程で適切なレビューが実施できる 14 PJ担当者 (W-A項目把握) PJ担当者 (設計、運用資料作成） PJ担当者、外部アーキテクト (W-Aに沿った認識合わせ、設計) セキュリティ系の案件だから セキュリティ観点のW-Aレ ビューを取り入れよう リスクになりそうなところは お客さんと認識合わせして、 リスク対策を合意した 解決が必要な問題は必要に応 じて外部アーキテクト交えて 対策検討した チェック済みのW-A観点がわ かるように設計、運用資料を 作成した
16. 個人的おすすめミニマム案： 「運用上の優秀性」の優先８問のできるところだけやってみる • 「運用上の優秀性」の特徴 • 全観点の中でもわかりやすい • 運用を考えずに進めるPJはほとんどないはずなので、W-Aに関わらずどのPJでも 関連した内容を検討しているはず • PM、PL、SE、PG、その他どの担当者でも検討しやすい • 要件検討、設計、開発、保守運用などどの工程でも検討/改善しやすい 15 どうやって対応の優先順位決めるか どうやってリスクの少ないリリースするかなど 運用を考えていないPJはないのでは？
17. 個人的おすすめミニマム案： 「運用上の優秀性」の優先８問のわかるところだけやってみる • 質問内容 • OPS 1. 優先順位はどのように決定すればよいでしょうか? • 顧客ニーズやコンプライアンスを元に優先順位考えている？ • OPS 4. オブザーバビリティをワークロードに実装するにはどうすればよいでしょうか? • KPIなど定量的に運用できているか測れている？ • OPS 5. どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか? • バージョン管理や複数環境で運用している？ • OPS 6. どのようにデプロイのリスクを軽減しますか? • デプロイする前にテストしてる？ • OPS 7. ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか? • デプロイするときに手順決めたり作業者が練習したりしてる？ • OPS 8. 組織でワークロードのオブザーバビリティを活用するにはどうすればよいでしょうか? • ログ出力したり、分析したりしている？ • OPS 9. オペレーションの正常性をどのように把握しますか? • ログ(メトリクス)を取得して改善しようとしてる？ • OPS 10. ワークロードと運用イベントはどのように管理しますか? • 問題が起こった時にアラート出したり、担当者にエスカレーションする手順ある？ 16 どのPJでもどれかはやっているはず。まずはその内容をチェックすればOK。 余力があれば他の項目をチェックできれば検討漏れに気が付きやすい
18. まとめ • W-Aレビューはあくまで設計原則 • 全て合わせられれば理想、チェック観点を知るだけでも有意義 • PJ特性により合わせられないものもある、無理に合わせなくてOK • W-Aレビューの時間は調整できる • できる範囲から始めればOK • 経験や勘だけに頼ったレビューにならないためにも徐々に取り入れたい 17 まずはどんなチェック観点があるかを知る所から始めてほしい W-Aについてもっと知りたい方はTeamsやSlack等でお気軽にご連絡ください。
19. 参考情報 • AWS Well-Architected フレームワーク付録: 質問とベストプラクティス https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/ap pendix.html 18
20. ご清聴ありがとうございました 19