Well-Architectedの勉強会でやったことをまとめてみる
昨年会社の有志で、Well-Architected framework(以下W/A)の勉強会を開きました。
そして勉強のやり方自体を試行錯誤するうちに、テーマを決めて実際の設計をレビューするという形式に辿り着きました。
単にペーパーを読んでディスカッションしているうちは気づかなかった観点や、実践的な設計指針が見える様になりとてもためになったので共有します。
対象読者
AWSには馴染んできたけど、まだW/Aを読んだことない、読んだけど設計に活かしきれないという方が対象です。私自身まだ道半ばです。
私がこの記事を書いたのは、お馴染みAWS最強メディアのDevelopersIOさんで『【初心者向け】AWS Well-Architected ドキュメントの歩き方』という記事が公開されたことで、ふと勉強会のことを思い出したのがきっかけです。
AWSが公開しているW/Aの資料は読んでみると、初心者でも「ふーんなるほどね」と納得はできるのですが、腹落ちして設計に活かすのはちょっと難しいです。私も初心者のときに読みましたが、理解したようで頭の中を横滑りする感覚でした。
DevelopersIOさんの記事もよくまとまっていて感動しますが、初心者が読むと同じような気持ちになるのではないかと思います。
この記事では具体的な勉強法を紹介することで、理解を深めていただければ嬉しいです。
AWSの公式ドキュメントが教科書、DevelopersIOさんの記事が副読本という位置づけで勉強していくのが今のおすすめです。
勉強会の進め方 ： 実際の設計をレビューしてディスカッションする
我々は毎週1回輪読で1人が発表して、内容について参加者でディスカッションする形式で進めました。
題材はAWS Well-Architected フレームワークの概要の資料です。
各回の内容は以下の通りです。
- W/Aの5本の柱のうち1つを選んで、考え方を要約して発表する。
- 参加者はその章を読んでくる。
- 発表者は簡単に重要だと思うポイントを要約する。
-
実際の設計を、選んだ柱の観点からレビューする。
- 「付録：質問とベストプラクティス」と比較しながらレビューして、3つのポイントを抽出する。
- W/Aのベストプラクティス通りに設計できている点
- W/Aのベストプラクティスの観点から改善できる点
- 判断できない設計、ベストプラクティス自体の意味わからない点
- 設計書全体を余すことなくやる必要はなく、それぞれ２〜３箇所ぐらいを指摘する。
- 「付録：質問とベストプラクティス」と比較しながらレビューして、3つのポイントを抽出する。
- 発表者が選んだ点について、参加者全員でディスカッションする。
- 設計の改善方法を出し合う。
- W/Aに近づくためのサービスを紹介しあう。
- ドキュメントの意図や、実装方法をディスカッションする、など。
それぞれ詳細を書いていきます。
具体的な3Step
Step1 5本の柱のうち1つを選んで、考え方を要約して発表する。
ここはごく簡単で良いと思います。
参加者は毎回読んでくるのが前提となるため、特にフォーカスしたいポイントがなければドキュメント等も作成しなくて良いと思います。
Step2 実際に過去作成した設計書を、選んだ柱の観点からレビューする。
勉強会で最も理解が深まるのがこの活動です。
ここでは実際の設計をW/Aの観点からレビューしていきます。ベストプラクティスと比較したときにどのような設計になっているかがポイントです。
AWS Well-Architected フレームワークの資料には、付録として質問とベストプラクティスがありますのでこれを活用しました。
この項目ではW/Aの各観点について、質問＋回答＋ベストプラクティスがセットになっています。参考にリンクを貼っておきます。
付録:質問とベストプラクティス > パフォーマンス効率 > 選択
リンク先の引用
一つ引用してみます。
質問
PERF 1 どのように最良パフォーマンスのアーキテクチャを選択するのですか?
回答
多くの場合、ワークロード全体での最適なパフォーマンスのためには、複数のアプローチが必要になります。Well-Architected なシステムでは、パフォーマンスを向上させるために複数のソリューションと機能が使用されています。
ベストプラクティス
利用可能なサービスやリソースを理解する: クラウドで利用できる幅広いサービスやリソースに関する情報を取得し、その内容を理解します。お客様のワークロードに関連するサービスや設定の選択肢を認識した上で、最適なパフォーマンスを実現する方法を理解してください。
これらを読み込んで下記の観点でレビューしていきます。レビュー対象の設計書と見比べながら進めます。
- W/Aのベストプラクティス通りに設計できている点
- W/Aのベストプラクティスの観点から改善できる点
- 判断できない設計、ベストプラクティス自体の意味わからない点
発表資料のサンプルも載せておきます。大体マークダウンかスライド形式で書くことが多かったです。（好みの世界だと思います。）
「パフォーマンス効率」の発表資料のサンプル
###ベストプラクティス通りにできてている点
選択
利用可能な設定オプションを評価する: さまざまな特性や設定オプションと、それらがストレージにどのように関連するかを評価します。ワークロードのためのストレージ容量とパフォーマンスを最適化するために、プロビジョンド IOPS、SSD、磁気ストレージ、オブジェクトストレージ、アーカイブストレージ、またはエフェメラルストレージをどこでどのように使用するかを理解してください。
設計書のXXの箇所で、サーバーの選定において必要な条件が整理されている。
YYという観点からt3のサーバーが選ばれているため、W/Aに設計できていると言える。
改善できる点
ワークロードのパフォーマンスを測定するための主要業績評価指標 (KPI) を確立する: ワークロードが意図したとおりに動作しているかどうかを示す KPI を特定します。たとえば、API ベースのワークロードでは、全体的なレスポンスレイテンシーを全体的なパフォーマンスの指標として使用でき、e コマースサイトでは、購入数を KPI として使用できます。
この設計書の中ではKPIが明確に定義されておらず、モニタリング対象のパフォーマンス指標がなぜXXになったのかがよくわからない。
システムの性質を考えると、YYの指標の方が望ましいのではないか？
よく分からなかった点
トレードオフが顧客と効率性にどのように影響するかを明らかにする: パフォーマンス関連の向上を評価する場合、どの選択肢が顧客とワークロードの効率性に影響するかを特定します。たとえば、key-value データストアの使用がシステムパフォーマンスを向上させる場合、その結果整合性の性質がお客様に与える影響を評価することが大切です。
パフォーマンスとトレードオフの関係となる具体的な要素がよく分からなかった。結果整合性以外の例を知りたい。
Step3 ディスカッションする
発表資料を題材にディスカッションをすることが大事です。
他のプロジェクトでも応用できなそう点を探す、改善方法を具体的に議論する、よく分からなかった点を補い合う、等のディスカッションができれば、勉強会が有意義になります。
大体各テーマごとに２回発表を回して、5本の柱×2回＝10回勉強会を開きました。
その他のTips
勉強会の人数とメンバー
- 人数：５人前後
- 心理的安全性を確保する。
Step2/3が知見を貯めて成長する良い機会となるため、ディスカッションできるようにメンバーを決めるのが良いです。
大体５人ぐらいが限度かと思うのと、お互いディスカッションができるぐらいの心理的安全性を確保するのもポイントになると思います。
発言をまんべんなく促す、スキルが低いものに対して理解度を尋ねて質問の機会を作る、といった工夫があると良いかもしれないです。
開催頻度とテーマ選び
- 毎週１回開催
- 各テーマごとに２名で担当する
各テーマ（柱）を深堀りして理解度を深めようと思うと、それなりに各テーマを２回は扱った方が良いです。
１回につき１テーマととなると、隔週で開催すると２０週＝５ヶ月かかってだれてしまいます。なので毎週１回ぐらいをおすすめします。
また１テーマ1人にすると、何らかの理由で発表ができずに会自体がスキップされたりします。
ディスカッションの種があれば結構持つので、各会２人をアサインして最低１人は発表できるようにすると良いでしょう。（発表回数増えるの大変ですが…）
参考
AWS公式ドキュメント
AWS Well-Architected
Well-Architected 概要(html)
Developers IO(いつもお世話になってます）
『【初心者向け】AWS Well-Architected ドキュメントの歩き方』