クラウドプリセールス事例紹介シリーズ（第二回目）／AWS Well-Architectedフレームワークの適切な対応を考える

こんにちは、ENKです。

クラウドプリセールス事例紹介シリーズとして、当社のクラウドに関する取り組みの一端を紹介させていただければと思います。ある程度クラウドの知識を持っている方に向けた内容になりますので、予めご了承ください。

第二回目は、昨今ではクラウドサービス利用時に必須要件とされることを多く見かける「AWS Well-Architectedフレームワーク（以降「W-A」と略す）」をテーマにした記事になります。ちなみに私は「Well-Architected Lead」の認定を受けていますので、ある程度の価値は皆さまに提供できるかと思います。

W-Aレビューは様々なタイミングでの実施などが多いと思いますが、ご自身で実施する場合は、主にアーキテクチャ設計工程などで、ある程度のシステム構成が見えてきた段階で非機能要求事項とW-Aの設計原則および6本の柱の質問/ベストプラクティスと突き合わせしつつ、考慮漏れ等が無いように細かくチェックすることは実際の現場で行うことと思います。本記事では、各柱に記載されるベストプラクティスに準拠したクラウドを利用する際の基本的な設計方針を提示し、実際に非機能検討していく際のポイントをお伝えしたいと思います。W-Aのそれぞれの項目には色々難しいことが書いてありますが、主に対応すべきことは何かを中心に整理しましたので、W-Aレビュー実施前の設計方針策定や、レビュー後の指摘対応などに役立てていただければと考えています。

1. AWS Well-Architected フレームワークとは
2. W-Aの対応項目を考える
3. 対応結果をお客様に共有しよう
4. 改善サイクルで良くしよう
5. まとめ
6. Appendix

AWS曰く、W-Aは以下のように語られています。

「クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。W-A では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチ」とされています。

 

この内容の本質はAWSを用いた際の非機能要求対応に重きを置いたベストプラクティス集であり、このツールを使うことで、AWSのクラウドを賢く使うためのノウハウをITシステムに組み込むことが効率的にできるので、システム価値向上に直結させることができます。また、ベストプラクティスを知ることで、リスクや改善点を顕在化させることにも利用することができます。

尚、本記事で語る非機能要求とは、皆さんお馴染み？のIPA（独立法人 情報処理推進機構）から提供されている「非機能要求グレード」です。これを参考に対応関係を整理すると完全一致ではありませんが下表のようになります。W-Aは従来の非機能検討手法の延長で参考に出来る部分が多くあり、このように整理すると初見の方でも利用イメージが湧き、具体的な利用シーンになるのか分かり易くなるのではないでしょうか。
尚、フレームワークの柱の一つであるコスト最適化に関するものは非機能要求グレードで定義されていませんが、システム価値を費用対効果で考えるには全項目共通して意識する内容になります。

※本書では他のServerless Lens等に関しては割愛しています。

私がシステム要件定義工程に参画し、システムインフラ（いわゆる基盤系）の検討タスクに着手する場合、前述のIPAの非機能要件グレードを用いて、お客様の非機能要求のヒアリングおよび実装方式の検討を進めていくことが多く、その進め方に準じた検討方法を一例としてご紹介します。ここでは非機能要件グレード表とW-Aとの対応項目（質問事項を含め）を1:1で比較して大公開したほうが、みんな幸せになるのでは？と思うものの、非常に膨大なものになりますので中項目レベルの内容に留めさせていただきました。
まず、話を進める前に前提となる知識はW-Aで謳われる設計原則です。この原則から各定義およびベストプラクティスに繋がっていく話になりますので、ご留意ください。
 

クラウドの一般的な設計原則
クラウド上における設計の共通的な考え方になります。どのフレームワークの柱も、この考え方が中心になっているので、ここから派生した作りになっています。

また、次節より非機能要件グレードの中項目に関して、「必須」もしくは「お勧め」として対応要否のレベルを記載しております。読み方はW-Aの質問に対して何らかの対応を1つ以上は必ず実装していただきたいのが「必須」、内容が組織論などが含まれ対応が直ぐには出来ないと思わるものは「お勧め」として内容を記載しています。

非機能要件グレードの「可用性」は、W-Aでは「信頼性の柱（13の質問）」に、概ね該当します。質問に回答していく前に以下の信頼性の設計原則を考慮し、非機能要求事項に対する対応方針を検討します。

信頼性の設計原則

• 障害から自動的に復旧する
• 復旧手順をテストする
• 水平方向にスケールしてワークロード全体の可用性を高める
• キャパシティーを推測することをやめる
• オートメーションで変更を管理する
   

非機能要件グレードの「性能・拡張性」は、W-Aでは「パフォーマンス効率の柱（8の質問）」に概ね該当します。こちらの設計原則は以下のとおりです。サーバーキャパシティ単位での従来の性能確保ではなく、クラウドの柔軟な拡張性を活用する性能確保の視点で見ていく内容になります。
 

パフォーマンス効率の設計原則

• 最新テクノロジーを誰もが利用できるようにする
• わずか数分でグローバル展開する
• サーバーレスアーキテクチャを使用する
• より頻繁に実験する
• メカニカルシンパシー（システムやサービスを利用する際に、最も効率的に利用可能な状態のこと）を重視する
   

非機能要件グレードの「運用・保守性」は、W-Aでは「運用上の優位性の柱（11の質問）」に概ね該当します。こちらの設計原則は以下のとおりです。システム運用はシステム自体の価値を向上させていくための重要なプロセスになるので、W-Aのベストプラクティスに積極的に寄せていくことが重要です。ただW-Aに記載される内容は、かなり理想的な状態であるため、既に多くのシステム運用を行っているお客様に対しては直ぐに適用できないケースあるので、システム運用の改善プロセスの中で徐々に適用していくといった手法が現実的な対応になるかと思います。

運用上の優位性の設計原則

• 運用をコードとして実行する
• 小規模かつ可逆的な変更を頻繁に行う
• 運用手順を頻繁に改善する
• 障害を予想する
• 運用上の障害すべてから学ぶ

　非機能要件グレードの「移行性」は、W-Aでは特に語られていません。移行に関しては、お客様保有のシステム構成やデータ特性など、非常に様々なパターンがあるのでベストプラクティスを参考にするものはあるものの、うまく適合させることはケーズバイケースであるので難しいことが殆どだと思います。そのため、移行に関しては別テーマとさせていただきます。AWSからはガイドが多く提供されておりますので、その一部分を紹介します。これらの参考にしながら移行要件を満たすための個別設計にて、最適な移行方式を検討いただければと思います。

• AWSへの移行：ベストプラクティスと戦略
• 移行向けのアーキテクチャのベストプラクティス
   

非機能要件グレードの「セキュリティ」は、W-Aでは「セキュリティの柱（11の質問）」に概ね該当します。こちらの設計原則は以下のとおりです。昨今ではゼロトラストという考えをよく耳にすることが多いと思いますが、適切な認証/認可（人や各システム間などすべて）、通信やデータの暗号化など、この設計原則では対応のためのベストプラクティスが語られています。このことを念頭に利用者が安全に利用できる仕組み作りを考えていく必要があります。
 

セキュリティの設計原則

• 強力なアイデンティティ基盤を実装する
• トレーサビリティの実現
• 全レイヤーでセキュリティを適用する
• 伝送中および保管中のデータを保護する
• データに人の手を入れない
• セキュリティイベントに備える
   

非機能要件グレードの「システム環境・エコロジー」は、W-Aでは「持続可能性の柱（6の質問）」に概ね該当します。こちらの設計原則は以下のとおりです。非機能要件グレードで語られる内容と、W-Aと比べると意味合い異なるので、ここで整理して良いかは微妙なところではありますが、中項目の環境マネージメントのエネルギー消費効率の部分で、率用最小限のエネルギーで済む仕組みが該当します。ここでは、システムを稼働させる際に、無駄なエネルギー（リソース）消費がない仕組みになっているかの観点で見ていく部分になります。
 

持続可能性の設計原則

• 影響を理解する
• 持続可能性の目標を設定する
• 使用率を最大化する
• より効率的なハードウェアやソフトウェアの新製品を予測して採用する
• マネージドサービスを使用する
• クラウドワークロードのダウンストリームの影響を軽減する
   

非機能要件グレードでは定義されていませんが、W-Aの「コスト最適化の柱（7質問）」はアーキテクチャ検討では常に意識し、その構成に効率性を求めた設計が必要になります。こちらの設計原則は以下のとおりです。例えば、可用性が求められるからと言って複数台構成の重厚してしまうとコスト増（複数台構成化など）に直結するのですが、実は停止時間を多少は許容するシステムならオートヒーリング/リカバリ等の機能で十分であるケースがあります。このようにシステム化をする際は、用途に応じた構成とコストのバランスを考えていくことが必要であり、常日頃から必要最小限の構成や仕組みなど松竹梅を把握して実装していけるようにする必要があります。
 

コスト最適化の設計原則

• クラウド財務管理を実装する
• 消費モデルを導入する
• 全体的な効率を測定する
• 差別化につながらない高負荷の作業に費用をかけるのをやめる
• 費用を分析し帰属関係を明らかにする
   

W-Aの質問の選択項目で、これは必至対応だとAWSから推奨されているものがあります。この辺りを合わせて対応していくのが良いかと思います。
　AWSの利用時におさえておきたい10のこと

W-Aに可能な限り準拠させて設計を進めたら、なるべく早い段階で「Well-Architected Lead」に相談しW-Aレビューを実施してもらい、その結果をお客様に共有しましょう。W-Aの目的はレビュー結果から、潜在的なリスクや影響を理解し、それらの情報に基づいてアーキテクチャを見直すなど、ビジネス成功の可能性を高めるための活動に繋げることになるので、この共有は必須になります。
　またW-Aを活用するシーンは、以下のタイミングなどありますので、一回の実施だけでは無く継続的に実施することで、ベストプラクティスに則ったシステムとして構築された状態を維持することが可能になります。より良いシステム作りは、お客様と共に成長していくことが不可欠になります。
 

主なW-A活用シーン

• 要件検討
• 設計
• 構築
• 運用

※W-Aレビューは、どのシーンからでも実施可能です。
 

 　改善サイクルではベストプラクティスに則ったシステムの状態を維持できているか、日々の運用のなかで改善されているかを見ていく活動になります。これは前述の繰り返しW-Aレビューを実施していくことにも繋がります。
　改善サイクルを回すには、まずW-Aレビューを実施し、その結果の状態をベースラインとして改善基準として用い、この基準から繰り返しレビューを実施＆改善活動をすることでシステムを良くしていきます。この活動を効率良く実施していくには、「AWS Well-Architected Tool」を使っていきましょう。このツールの利用方法は本記事では割愛しますが、推奨される改善点が提示されているため、該当システムにとって必要な改善点が一目瞭然であり対応の優先順位も付け易いです。W-Aでは、改善点の気付きを得るためのツールですので、改善可能なものがあれば対応していくことをお勧めします。やっていくと全て対応していきたくなりますが、無理せず費用対効果を念頭に進めていくのが大事です。また継続して改善サイクルを回すことで改善点が無くなって何もする必要がなくなってしまう場合がありますが、その際は、システムのアプリケーション改修などでシステムの状態が変わることもあるかと思いますので、そのタイミングでベストプラクティスに則ったシステムの状態を維持出来ているかのチェックにも役立てることができます。
 

改善サイクルを回すポイント

• まずW-Aレビューを実施しよう
• 現在の状態を把握し、改善点に対して優先順位を付けよう
• 改善はシステム価値向上に直結する内容を優先的に対応しよう
• 改善点が無くなるまで、一定の周期で実施しよう（四半期単位など）
• 改善点がなくなれば、システム改修イベントや時期システムでの課題抽出のための材料として実施しよう
• W-A全てを対応する必要はない。システムにとって費用対効果が高いものを中心に実施していくことが大事
   

　W-Aの各柱の対応の結果として殆どは実装していく必要が結果的にはあります。実態としてベストプラクティスですので、システム利用環境固有の事情が無ければ合わせていくという営みになるためです。
　私も振返ってみて「必須」とした内容が多いなと正直思います。ただAWSの基本的なデザインパターンに準じて構成していれば自然と対応ができているのが殆どですので、個人差があるものの日々の技術研鑽を積んでいれば実装に問題は無います。それでもお困りの場合は、お近くの「Well-Architected Lead」の方にお声がけいただくのが良いかと思います。
 

最後に、W-Aは様々なフェーズで活用できますので、以下にW-Aレビューのタイミングを整理させていただきますので、こちらも、お客様のビジネス成功のためにお役立ていただければと思います。
 

• AWS Well-Architected
• システム構築の上流工程強化（非機能要求グレード）紹介ページ
• 移行向けのアーキテクチャのベストプラクティス
• AWSへの移行：ベストプラクティスと戦略
• AWSの利用時におさえておきたい10のこと