FinOpsの始め方とクラウドコスト可視化の重要性
tecchan
デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
Well-Architected Frameworkで改善施策を立案する手順を徹底解説
tecchan
当社デロイト トーマツ ウェブサービスはAWSより「Well-Architected パートナー」の認定を得ており、多くのお客様のワークロードのレビュー及び改善を行ってきました。また、同様に当社は「内製化支援推進 AWS パートナー」の認定も得ており、お客様の内製化を推進しています。
お客様がWAFR（Well-Architected Framework Review）を内製化して行うことで、外注することと比較しよりスピード感を持ったクラウド環境の最適化を行う事ができ、また長期的なコスト削減にも繋がります。
そこで本ブログではWAFRおよび改善施策の立案を内製で実施する方法について、AWSのドキュメントおよび当社の支援事例を交えながら徹底解説いたします。
AWS Well-Architected Frameworkの進化
まずはWell-Architected Frameworkの歴史についてです。2022年のre:Inventの以下のセッションで、AWS Well-Architected Frameworkの歴史が紹介されています。
（出所）ARC210_The-well-architected-way
AWS Well-Architected Frameworkは、元々AWSのソリューションアーキテクト（SA）が行っていたレビュー手法を体系化したものです。2018年にお客様自身でレビューをできるツールとしてAWS Well-Architected Toolのサービスがリリースされ、セルフサービス型のレビューが可能になりました。
以下の記載がある通り、AWS Well-Architected ToolはAWSのSAの参加を必要とせず、お客様のレビュー依頼のニーズに応えるためにセルフサービス化したものです。
AWSのソリューションアーキテクト(SA)はお客様と共に、毎年、数千ものWell-Architectedレビューを実施しており、レビューを実施したお客様からは「レビューが大変価値のあるものだった」「レビュー結果をシステム改善に活用している」とのお声をいただいています。一方で、今まではすべてのお客様からのレビュー依頼にはお応え出来ていませんでした。
そこで、すべてのお客様にWell-Architectedレビューを実施いただけるように、私たちはAWS Well-Architected Toolを開発しました。このセルフサービス形式のツールは、お客様が自身でワークロードのレビューを実施出来るようにデザインされています。レビューへのAWSのSAの参加は必要ではなく、お客様は任意のタイミングでワークロードのレビューが出来ます。
WAFRのレビュープロセスのガイダンス
続いてWell-Architected Frameworkの活用について、AWSが提示しているレビュープロセスを確認し、それをお客様の環境に適用する方法を解説します。
「AWS Well-Architected – 安全で効率的なクラウドアプリケーション」のページで、フレームワークの概要や6つの柱等の説明が記載してあります。また、そこからホワイトペーパーへのリンクを飛ぶことで、レビュープロセスのページを見つけることができます。
WAFRは原則として、こちらの概要ページやホワイトペーパーを参考にしながら進めていくことになります。
ホワイトペーパーとしてはこれより詳細化されているものはありません。これは先述の概要ページにも記載がある通り、Well-Architected Frameworkの各設問の項目はあくまで設計するための核となる戦略とベストプラクティスを経験から作成したものであるためです。
この経験を元に作られたこのフレームワークを活用しながら、実際にワークロードへ適用させるフェーズはお客様にて実施する必要があります。また、上記のWebページにも記載されている通り、AWS Well-Architected パートナー企業やAWSから支援を受けることも可能です。
AWS Well-Architected パートナープログラムのメンバーは、AWS Well-Architected Framework についての徹底したトレーニングを受講し、ベストプラクティスの実装、ワークロード状態の測定、サポートが必要な分野の改善を行うことができます。
WAFRの内製化に向けた課題とその解決策
ここまで見てきた通り、WAFRを実際のワークロードに適用させるにはW-A Toolの活用に加え、お客様によりそれをワークロードに適用させるためのWAFRの知見が必要になります。内製化を実現するためには、ここをAWSのSAやWell-Architected パートナーに依頼するのではなく、お客様自身で実施する必要があります。
今回、当社のお客様において、
- ホワイトペーパーの情報だけでは具体性が足りずWAFRの進め方が確立できない。
- レビューのツールとしてWell-Architected Toolがあるが、改善実施のためのツールが提供されていない。
という二点の課題がありました。
上記のニーズについて、当社がご提供したソリューションをご紹介します。
ホワイトペーパーの情報だけでは具体性が足りずWAFRの進め方が確立できない。
こちらについてはこれまで見てきたように、WAFRのホワイトペーパーはAWSのペストプラクティスを経験から作成したものであり、「こう進めていけばOK」という具体的な手法を示すものではありません。
これはお客様のニーズに柔軟に適合するためという観点だと汎用的といえますが、一方で事業会社のお客様はAWSの専門家ではないため、柔軟に適合させることは難しいという課題があります。そこでより詳細化するための参考資料として、以下のブログが公開されています。
- Well-Architected Framework Review の実施方法 – パート 1 | Amazon Web Services ブログ
- Well-Architected Framework Review の実施方法 – パート 2 | Amazon Web Services ブログ
- Well-Architected Framework Review の実施方法 – パート 3 | Amazon Web Services ブログ
これはAWS がお客様と多数の WAFR を実施した際に学んだ教訓のいくつかを共有するもので、各ステップの詳細を説明しています。具体的には、WAFRを下図のPREPARE, REVIEW, IMPROVEの３つのフェーズに分解し、そのポイントを詳細に見ていくというものです。
（出所）Well-Architected Framework Review の実施方法 – パート 1 | Amazon Web Services ブログ
これにより、ホワイトペーパーよりも具体的な進め方のノウハウを得ることができます。
レビューのツールとしてWell-Architected Toolがあるが、改善実施のためのツールが提供されていない。
AWSはWAFRのレビュー観点をホワイトペーパーとして公開し、そのツールとしてWell-Architected toolを提供しています。
一方で、改善実施についてはホワイトペーパーが公開されているものの、Well-Architected toolのような改善を行うためのツールは提供していません。
上記ブログ記事だと、パート3の「1- リスクの特定」を行うツールとしてWell-Architected Toolが提供されていますが、「2」から「4」に相当するツールは提供されていません。（以降、簡略化のため下記をStep1, 2, 3, 4と表記します。）
- 1- リスクの特定 （別名：改善機会）
- 2- リスクの理解
- 3- 規範的なソリューションの決定
- 4- 実装と追跡
ここについて本記事では、お客様のご了承を得た上で実際に当社が行った事例を公開します。
万能のアプローチではありませんが、WAFRを内製化するための一例としてご活用ください。
WAFRを活用した改善施策立案の内製化の方法
Step1 リスクの特定 （別名：改善機会）
このフェーズについてはWell-Architected Toolが提供されているため、詳細の紹介は割愛します。
お客様のご要望および工数の都合により、レポートの発行および、この段階でピラーを絞り後続のステップへと進むことにしました。
Step2 リスクの理解
ブログ記事を参考すると、以下の6つの設問を念頭に、Step1で特定したリスクの理解を深めるフェーズが必要となります。
- リスクが影響を及ぼす可能性はどの程度か？
- お客様への影響は何か？
- 結果としてのビジネスへの影響は何か？
- リスクを完全に排除できるか、それとも軽減するのみか？
- 誰がリスクを負っているか？
- 誰がリスクの排除や軽減のための改善作業を担うか?
ブログ記事で以下の記載があるように、このフェーズでは運用担当者や部門責任者を交えながら、これらのリスクについてディスカッションするフェーズとなります。
主要なステークホルダーやビジネスオーナーにこれらの質問に答えてもらうことで、焦点を当てるべき最も重要なリスクのリストの作成と、それらに対処するための時間を予測するのに役立ちます。
今回の当社の事例では、検出されたHRIについてホワイトペーパーおよび上記の設問を参考にしながら、ワークロードの実態についてディスカッションを行い、想定されるリスクや実際に顕在化しているリスク等を表計算ソフトに入力していきました。なお、ここで記載しているホワイトペーパーとは、例えばOPS01-BP01の項目であれば以下のドキュメントのことを指します。
一つの設問につき15分の時間枠でディスカッションを行い、これを設問数だけ繰り返しました。
Step3 規範的なソリューションの決定
ブログ記事では方法として
このステップでは、追加の調査、ディスカッション、概念実証の構築が必要になる場合があります。
と紹介されており、これ以上の情報は載っていません。一般に当社がWell-Architected パートナーとしてソリューションをご提案する場合、ソリューションはホワイトペーパーを参照しながらご提案します。
一例として「OPS01-BP01 外部顧客のニーズを評価する - オペレーショナルエクセレンスの柱」の場合、お客様が抱えられているリスクと、ホワイトペーパーに記載されている以下のような情報を参考にしながらソリューションを検討します。
ビジネスニーズの理解: ビジネスの成功は、ビジネス、開発、運用の各チームを含むステークホルダー全体で目標を共有し、理解を深めることで実現できます。
例として上記の場合、「開発チームと運用チームがビジネス目標を共有できるように、定期的に意見交換できる場を設ける」というようなソリューションの例が考えられます。
今回の事例でも、上記のようにホワイトペーパーの記載およびStep2でのディスカッション内容を参考にしながら、Step3も15分の時間枠でディスカッションを行いました。
実際には、Step2, 3で各設問合計30分ずつの枠を確保し、これを設問ごとにディスカッションを行いました。表計算ソフトを利用し、以下のようにディスカッション結果を整理して記入しました。行ごとに各30分ディスカッションをするイメージです。
ここまでのディスカッションが完了すると、表計算ソフトにStep2とStep3のディスカッション結果が記入されている状態になります。これを生成AIに読み込ませてソリューションのサマリを作成したり、人の目でソリューションとして整理することでStep3を完了としました。
Step4 実装と追跡
実装と追跡というタイトルではありますが、ブログ記事内ではStep1-4のサイクルが回っている様子を表す図として以下が紹介されています。
（出所）Well-Architected Framework Review の実施方法 – パート 3 | Amazon Web Services ブログ
この図では「Step4 実装と追跡」は以下の2要素に分類されます。
- Prioritize improvements（優先順位付け）
- Implement & track improvements（実装と追跡）
Prioritize improvements（優先順位付け）
このうち優先順位付けについては、ブログ記事の中でアイゼンハワースタイルのプロットが紹介されています。
（出所）Well-Architected Framework Review の実施方法 – パート 3 | Amazon Web Services ブログ
今回のお客様事例では重要性（Impact）と労力（Ease）の他にも考慮する観点が多々あったため、アイゼンハワースタイルのプロットでは要件を満たすことができませんでした。そのためStep2, 3のディスカッション結果を元にお客様と合計5時間のディスカッション枠を確保し、個別に優先順位付けを行いました。
Implement & track improvements（実装と追跡）
実装については、優先順位付けしたものをBacklog等で管理をしながら一つずつ行っていくこととなります。追跡については定期的にWAFRを行うことで行う事が可能です。これはWell-Architected Toolでマイルストーンという機能が提供されています。この機能では、各WAFRの実施結果を保存することができるので、ディスカッション結果を追跡することに役立ちます。
本来はアプリケーションのマイルストンに合わせてWAFRを行うべきですが、今回の事例では半年または一年のサイクルで繰り返すような枠組みを確立させました。これにより、常にワークロードを変化に対応させることが可能となりました。
改善施策の効果測定（KPI設定）
最後にKPIについて、お客様からご相談があったので記載します。
「Step1 リスクの特定」を行うことでレポートが発行され、高リスクの問題 (High Risk Issues, HRI) と中リスクの問題 (Medium Risk Issues, MRI) という形で可視化されます。
一見これをそのままKPIとして数を減らして行くのが簡単そうですが、それは推奨されていません。
クラウド環境のKPI設定のガイダンスとしては、以下のブログが参考になります。
KPI を定めるうえで重要なことは、達成したいビジネスの成果や顧客が得られる価値を起点にして検討を始めることです。これは、ゴールに向けて正しく進んでいるかを測定するために必要な KPI を特定、決定するということです。また、ファイナンス部門とテクノロジー部門を跨ぐ共通言語で KPI を作成し、その効用と価値を社内で公開することでより効果を高めることができます。
Well-Architected FrameworkのHRI, MRIはワークロード上のリスクを可視化するための数値であり、上記に記載のあるような達成したいビジネスの成果や顧客が得られる価値を起点に考えられたものではありません。
Well-Architected Frameworkはあくまで改善のためのツールとして利用し、KPIは別途定める必要があります。
具体的なKPIには本記事では触れませんが、以下のブログ記事ではAWSの事例を通して得られた共通のテーマに関するKPIの例が記載されています。
ビジネス価値を測定するためのKPI の選定は、顧客満足度、業務効率、収益成長などへの影響を直接測定する分野に焦点を当てるべきです。万能のアプローチは存在しませんが、事例をとおしていくつかの共通テーマが見いだせてきています。以下は、ビジネス価値の柱ごとにみるKPI の例になります。
これらの情報を参考にKPIを設定し、Well-Architected Frameworkを通じてワークロードの評価および改善を行うことでより効果的なクラウド活用を実現する事が可能です。
まとめ
ここまで、WAFRから改善施策の実行までの流れをより詳細に紹介しました。
WAFRを行う場合は、まずはAWSが提供しているホワイトペーパーを参照することが重要です。そこでより具体的な方法が知りたい場合はAWSが公開しているブログを参照し、その上で具体例が知りたいという場合は本ブログをご活用ください。
WAFRの内製化は、社内のクラウド環境改善に向けた強力なツールになります。本ブログ記事がAWS Well-Architected Framework活用およびその内製化の一助となれば幸いです。
AUTHOR
金融業界のSIerにて5年間勤務。大小様々な規模の案件にてプロジェクトマネジメントを経験後2022年5月にDWSへ入社。最先端の技術を用いる開発業務を担当。最近では先端技術への理解とマネジメントの経験を活かし、スクラムマスターとして案件を推進。2023, 2024 Japan AWS All Certifications Engineer。認定スクラムマスターPSMⅡ取得。
