目次
こちらの記事では、Well-Architected フレームワークの全体像を解説していきました。ただ、「それじゃあ実際にやってみよう」となると、意外と色々なところで手間取るものです。
この記事では、筆者がこれまで実施してきたレビューの取り組みの中での失敗談も交えつつ、気をつけておくと良い点を整理していきます。理想論を並べるというより、「こういう始め方もアリですよ」という現実寄りの話が中心です。
大前提:チェックリストではなく、建設的な話し合い
まず最初に、レビューに臨むときのマインドセットの話をさせてください。ここがズレていると、この後の話がぜんぶ空回りしてしまうので。
Well-Architected フレームワークの各質問項目を見ていくと分かるのですが、「xxxしなくてはならない」「xxxであるべきである」といった、いわゆるチェックリストやNGリストの形にはなっていません。ですから、システム・サービス設計のポイントとなる項目について、考慮すべき視点や対応方針を得るための、実践的なベストプラクティスとして使うのが望ましいです。
この点はドキュメントの冒頭でも、以下のように書かれています。
AWS Well-Architected フレームワークは、AWS でシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。このフレームワークを利用すると、安全で信頼性および有効性が高く、コスト効率に優れた持続可能なワークロードを AWS クラウドで設計し、運用するためのアーキテクチャに関するベストプラクティスを学ぶことができます。また、このフレームワークは、ベストプラクティスに照らしてアーキテクチャを評価し、改善すべき分野を特定する一貫した方法を提供します。アーキテクチャをレビューするプロセスは、アーキテクチャの決定に関する建設的な話し合いであり、監査メカニズムではありません。当社は、Well-Architected システムによってビジネスの成功の可能性が大いに高まると確信しています。
ポイントは、最後のほうにある「建設的な話し合いであり、監査メカニズムではありません」という一文です。粗探しをして点数をつける場ではない、ということですね。ここを押さえておくだけで、レビューの空気はだいぶ変わります。
なので、このレビューに臨むときは、次の様な視点を持っておきたいところです。
- 体系だったベストプラクティスで提示されている論点が、対象システムではどのように考慮されているか？
- ビジネス要件 / 非機能要件を踏まえた上で、ベストプラクティスを採用すべきか、採用するならどのように実装するか？
誰がレビューに参加するべきか？
次に、「誰を呼ぶか」の話です。
内製化がかなり進んでいるお客様なら、プロジェクトメンバー内だけで Well-Architected フレームワークレビューを実施可能です。ただ、よくあるシステム開発プロジェクトだと、SI パートナーさんと協業して進める体制になっていることが多いと思います。
例えば社内システムの場合、理想を言えば、次の様にそれぞれの立場から人を集めたいところです。
- システムを実際に利用するユーザ部門の責任者(いわゆるシステムオーナー)
- システム開発プロジェクトの PM / PL / アーキテクト
- SI パートナー
何故複数の立場が必要かというと、Well-Architected の論点って、突き詰めると「何を採用して、何を採用しないか」というトレードオフの話になるんですよね。なので、1つの視点だけだと、なかなか判断しきれないんです。
それぞれが持ち寄るものを整理すると、こんな感じです。
ユーザ部門の責任者には、ビジネス要件・非機能要件の優先順位や、予算、どこまでのリスクを許容できるか、といった「決められる」材料を持ってきてもらいます。たとえば「可用性を99.9%から99.99%に上げる」という選択肢が出たときに、そのための追加コストを払う価値があるかどうかは、最終的にビジネス側でしか判断できません。
PM / PL / アーキテクトには、システム全体像と設計意図、そして「これまでなぜその設計を選んだのか」という判断の経緯を共有してもらいます。レビューは過去の決定を蒸し返す場ではなく、その判断が今のビジネス要件に照らして妥当かを確かめる場なので、背景が分かっていないと議論が空回りしてしまいます。
SI パートナーには、実装の実態や技術的な制約、運用してみて分かった知見を持ち寄ってもらいます。ドキュメント上の設計と、実際に動いているシステムとの間にギャップがあることは珍しくなく、ここを埋められるのは現場を一番知っている人たちです。
——ここは筆者の失敗談なのですが—— 以前、指摘は山ほど出たのに、その場に「やる / やらない」「いつまでにやる」を決められる人がいなくて、結局ぜんぶ「持ち帰り検討」で終わってしまったことがありました。論点は洗い出せたのに、誰も決められないので何も進まない。これはもったいない時間の使い方でした。
Well-Architected の論点はコスト・信頼性・性能などのトレードオフに行き着くので、その場でトレードオフを決断できる人がいるかどうかは、地味ですがかなり効いてきます。
参加者を集めるときは、肩書きや人数よりも、「この決断のラインがその場に揃っているか」を意識すると良いと思います。
とはいえ、全員集めるのは大変なので
——と、ここまではあくまで理想形の話です。
現実には、そんなに時間も取れないし、工数かかって大変だよね、というのが正直なところだと思います。また、AWS 上でのシステム開発にあまり慣れていない場合、漠然とした不安を解消したいというニーズの方が大きい事もあるでしょう。
- 何か致命的な考慮漏れがないか？
- 改善点のアイディア・ネタ出しをしたい
そういうときは、もっと小さく始めてしまって良いと思います。システム開発プロジェクトの PL / アーキテクト + (場合によっては)SI パートナーの少人数で実施するのも全然アリです。
最初から完璧な座組を揃えようとして「結局できなかった」となるより、小さくても一度回してみる方が、得られるものは多いです。エンタープライズ企業のお客様の場合、SI パートナーから提示された各種設計ドキュメント・運用ドキュメントをレビューする立場になることが多くなります。Well-Architected レビューを通すことで、追加でお願いしたい要素や、次工程で決断しなくてはならないことが見通しやすくなりますよ。
いつレビューをやるのか？
ここまで「誰と」やるかを見てきましたが、もう1つ大事なのが「いつ」やるかです。
結論から言うと、1回限りのレビューにするよりも、継続的にやる方が望ましいです。AWSは進化を続けていますし、Well-Architected の定義自体も磨き上げられ続けています。なので、一度きりの健康診断というより、継続的なレビューによって継続的なシステム改善を支えるもの、として位置付けたいんですよね。
運用フェーズに入ってからは定期的にレビューするというやり方がイメージしやすいでしょう。実際には開発フェーズでも Well-Architected レビューを活用できますよ。開発フェーズはざっくりと要件定義・設計・実装・テストといった構成に分かれます。各工程の区切りで実施するのがおすすめです。
当然、工程によって議論すべきことや決定すべき事項は変わるので、レビューの内容も変わります。ベストプラクティスの各項目を「この項目はこの工程で議論した方が良いか?」という観点で眺めると、議論の抜け漏れチェックにも使えます。
運用の優秀性の柱における質問例として以下の内容があります。
OPS 11: 運用を進化させるにはどうすればよいか?
この項目に対して、各種ログを取得・可視化・分析する、といった対応は比較的考慮されやすいのですが、あわせて考えるべき「継続的で漸進的な改善に時間とリソースを費やす必要がある」という点は検討が漏れやすいポイントです。以下の様な運用プロセスが考慮されているか、これを要件定義・設計のタイミングで認識できていれば、後の運用設計での検討漏れを防げます。
- 月次の振り返りで改善点をディスカッションする
- 四半期単位で、新しく出た AWS サービスの採用可否を考える
- マネージドサービスのバージョンアップタイミング頻度
システム・業務特性上、頻繁にメンテナンス作業が行えない場合もあるでしょうし、比較的手軽にシステム変更が行える様な場合もあるでしょう。コストがかかる運用プロセスなので、思いつきで「毎週やります」と決められるものでもありません。かといって、まったく考慮できていないと、運用開始後、急に計画外のマネージドサービスのバージョンアップを急遽実施しなくてはならない、といったリスクを抱えることになります。
工程の区切りで Well-Architected レビューを挟んでおけば、少なくとも「考慮すべき論点」として認識した状態にしておけます。
高リスク判定とどう向き合うか
レビューを実施すると、高リスク (High risk) と評価される項目が出てきます。筆者の経験上、各設問に真剣に回答していれば、結構な割合で高リスク判定が出ます。画像は運用の優秀性に関するある設問です。
この設問に対しては、全ての選択肢にチェックがついていなければ、高リスクと判定されるでしょう。ここで目的を見失っていると、「なぜ対応していないのか。高リスク項目について全て対応していないのはおかしい。」という様な議論が行われる可能性すらあります。しかし、システム特性やプロジェクト体制等の制約を踏まえれば、全部に対応する事が必要ではありません。
レビューが建設的な話し合いの場であったならば、「コストの観点から分散トレーシングは過剰なので採用しない。」といった判断も行えるでしょう。あるいは「依存関係のある外部サービスやコンポーネントのヘルスチェックは追加した方がいい。」という判断に至る場合もあるでしょう。むしろこうした「合理的な優先順位付け」が行える場として活用するのが Well-Architected レビューの使い所の1つだと筆者は考えます。
Well-Architected フレームワークの目的を見失わない
最後に、一番大事なことを書いておきます。
ここまで「誰と」「いつ」やるかを色々書いてきましたが、レビューがうまくいかなくなるときって、だいたい原因は1つで、目的を見失っているときなんですよね。以下の見た目はバラバラですが、突き詰めるとすべて「目的を見失った結果」として説明できます。
- SIパートナーの不備を指摘し続けるだけになり、「より良いアーキテクチャにしていこう」という雰囲気がなくなってしまう
- チェックリスト化してしまい、ビジネス要件を脇に置いて全項目を満たそうとする(過剰設計)
- Well-Architected Tool を埋めること自体が目的になってしまう
- アクションアイテム・担当・期限が決まらず、次につながらない
冒頭の引用にもあったとおり、レビューの目的は「アーキテクチャの決定に関する建設的な話し合い」であって、監査や粗探しではありません。そして最終的なゴールは、より良いアーキテクチャを通じて、ビジネスの成功確率を上げることです。満点を取ることでも、誰かの落ち度を見つけることでもない、というのは折に触れて思い出したいところです。
もし「これは何のためにやってるんだっけ?」と感じたら、一度立ち止まって、この目的に立ち返ってみてください。
さいごに
Well-Architected フレームワークおよびレビューは、継続的なシステム改善に有用なツールです。完璧な座組や完璧なタイミングを待つより、目的を見失わずに小さく回し続ける方が、結果的にずっと良いアーキテクチャにつながっていくはずです。
最初から全てを完璧にこなす必要はありません。できる所から少しずつ、チームとシステムの成長に合わせて活用していきましょう。
