[レポート] Well-Architected なアプローチ #ARC210 #reinvent

アノテーション テクニカルサポートの川崎です。

本記事は AWS re:Invent 2022 のセッションレポートとなります。

概要

AWS Well-Architected フレームワークの原則を既存の管理・ガバナンスプロセスへ実装する方法について学んでください。このセッションでは、AWS Well-Architected ツールと API の機能を活用し、AWS の推奨される実践方法をシームレスに統合することで、ワークロードの効率、耐性、およびセキュリティを向上させます。

セッション動画

セッション資料

The Well-Architected way

セッション情報

ARC210

イントロ

私は Ilana Greenberg といいます。 Well-Architected のシニアプロダクトマネージャーです。 Samir Kopal は Well-Architected の製品とエンジニアリングをリードしています。

Well-Architected に精通している方や、知っている方もいらっしゃることでしょう。 Well-Architected フレームワークとツールは、 クラウド上でシステムを構築する際、 ベストプラクティスに従っていることを確認するのに非常に役立ちます。

(Amazon.com の CTO である) Dr. Werner は

Everything fails all the time, so plan for failure and nothing fails
（すべては常に失敗する可能性がある。失敗する前提で備えれば、失敗を回避できる）

と言っています。 これがまさに Well-Architected の役割です。 つまり、クラウドでシステムやアプリケーションを構築および管理する方法を考える際に、 Well-Architected であるかどうかを問いかける必要があります。 このセッションでは、 Well-Architected を実装し、組織に拡張する方法について、ガイダンスを提供します。

AWS WA の簡単な歴史

2012年、人気のある AWS サービスの障害で一部のお客様に影響が出ましたが、 影響を受けなかったお客様が特定のベストプラクティスに従っていることが分かりました。 そこで、この知見を共有するために Well-Architected が生まれ、ソリューションアーキテクト（SA）がAWSのベストプラクティスを提供し始めました。 これによりホワイトペーパーが作成され、最終的にAWS Well-Architected フレームワークが誕生しました。SAはお客様がベストプラクティスを実装できるよう支援を続け、AWSパートナーと協力して実践的なガイダンスを提供しました。 2018年には、 Well-Architected ツールが作成され、ワークロードの学習、測定、改善ができるようになりました。その後も、フレームワークとツールの更新に重点を置き、2020年にはAPIのフルセットをリリースしました。 更にカスタマイズ機能が追加され、ベストプラクティスや質問を無効化できるようになりました。昨年、サステナビリティの柱やカスタムレンズが実装され、Trusted AdvisorやService Catalog App Registryとの統合が開始されました。 これらの進化により、リソースレベルでのコンテキストが提供され、ワークロードレビューの速度が向上しました。今後も Well-Architected フレームワークとツールが進化し続け、お客様のニーズに応えるよう努力していきます。

AWS WA フレームワークとは何ですか?

AWS Well-Architected フレームワークについて簡単に説明します。このフレームワークは、お客様のフィードバックや洞察をもとに開発されたもので、6つの柱にわたる一連の質問やベストプラクティスが含まれています。主な柱はオペレーショナルエクセレンス、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、そして持続可能性です。 これらの質問を通じて、ワークロードの健全性を評価し維持するためのベストプラクティスが特定されます。これは、クラウドでのアーキテクチャ構築を考慮する際に役立つ基本的なベストプラクティスのセットです。また、カスタムレンズを導入することで、組織独自のベストプラクティスを実現するための基盤を拡張できます。 カスタムレンズは、 Well-Architected フレームワークを強化し、組織がユニークで重要な要素に集中できることを目的としています。 Well-Architected ツールを使用することで、ガバナンス要件や運用上のニーズなど、すべてのアーキテクチャのベストプラクティスを1か所で追跡できるようになります。これにより、組織は効率的なアーキテクチャ構築と運用を行うことができます。

Well-Architected ツールの価値は何ですか?

Well-Architected ツールの価値は、 Well-Architected フレームワークとカスタムレンズを活用して、チームがアーキテクチャを継続的に改善することを目指し、リスクを早期に特定し、問題を解決するための段階的な改善計画を提供することです。また、ツールは組織全体で一貫した測定を行い、リソースの最適化や信頼性の向上などの要素を評価することができます。 Well-Architected は3つの要素、つまりコンテンツ、ツール、データから構成されており、それぞれが連携して機能します。コンテンツにはフレームワークやカスタムレンズが含まれ、ツールはフレームワークとカスタムレンズのレビューを実行するのに役立ちます。データは意思決定やリスク分析、コンテンツとツールの組織への統合が反映されます。 適切なメカニズムを構築することで、 Well-Architected が組織内で実装され、学習、測定、改善の側面で効果を発揮します。まず、 Well-Architected が何であるかをチームに教え、AWSやお客様の経験に基づくベストプラクティスを伝えます。次に、ワークロードの健全性を測定し、リスクを特定し、アーキテクチャの改善を目指します。最後に、改善計画を実行し、経過とともにワークロードがどのように改善されたかを評価します。 Well-Architected は一般的なフレームワークという基本層から始まり、その上に特定のワークロードに特化したレンズやカスタムレンズを使って、ワークロードの適切な設計方法やリスクを詳細に評価することができます。 様々なレンズを活用し、カスタムレンズを開発することで、組織全体で一貫したアプローチを確立し、問題解決やリソース最適化に効果的に取り組むことができるようになります。

AWS の Well-Architected なアプローチ

AWSの適切な設計について、これを Well-Architected なアプローチと呼びます。適切な設計にはまず入力が重要で、レビューを行う理由や優先順位を理解することが求められます。これはチェックリストや監査ではなく、チームが同じ間違いを繰り返さないよう、学習プロセスとして捉えるべきです。 理由の1つはセキュリティインシデントを防ぐことで、チームは自分たちが何をしているのか、なぜそうしているのかを理解することが大切です。もう1つの理由は顧客から逆算して作業し、顧客や社内チームのニーズに応えることです。例えば、ツールやサービスのパフォーマンスを向上させたい場合や、運用負荷を軽減したい場合に、 Well-Architected のレビューが役立ちます。 このためには、まずワークロードの健全性を維持するために Well-Architected がなぜ重要なのかをチームが理解することが必要です。そしてツールやその使用方法の採用、改善の追跡やツールの更新、サイクルを継続する方法を考慮する必要があります。 この設計方法は拡張性を重視し、複数のワークロードに適用できるよう構築されます。また、継続的に改善するプロセスであり、 Well-Architected のホワイトペーパーを参照して詳細な内容を理解することも推奨されています。 結局のところ、 Well-Architected な設計方法はチームが学習プロセスを通じて適切な設計を継続的に追求し、顧客や社内チームのニーズに応えることを目指すものです。この方法を取り入れることで、組織のAWSシステムはより強固で効率的になることでしょう。

ツールの概要

まず、AWSマネジメントコンソールを使って、中央アカウントの作成やワークロード管理が行えます。また、レポート生成機能を利用して運用状況の把握が可能です。 さらに、APIを用いて組織内の他のツールと連携でき、リスク管理やカスタマイズがより容易になります。その一例として、中リスクと判断された項目が実際には高リスクである場合、ツールを活用してリスクレベルを変更することができます。 ワークロードの定義や管理が重要である理由を説明します。それは、チーム全員が共通の理解を持ってワークロードに取り組むことができ、より効果的にリスク管理が行えるためです。また、過去の決定に関する文書化が整っていれば、今後の意思決定に役立てることができます。 最後に、ツールの導入方法として、段階的アプローチを提案します。これは、重要なワークロードから始めて徐々に導入範囲を広げる方法で、ツールがもたらす価値をチーム全員が実感し、自然に浸透していくことが期待されます。

導入概要：カスタムレンズ

レビューをスケールする段階的なアプローチについてお話します。カスタムレンズを使って、ガイダンスを調整することができます。例えば、60個の超高度な質問はあまり価値がないかもしれませんが、これらを使って新しいワークロードを開始することができます。複雑なレガシーワークロードには、調整が必要です。カスタムレンズを用いることで、より特化した質問を提案することができます。 カスタムレンズの構築において、チーム間で協力することが重要です。1人でレビュー全体を行うのは困難ですが、セキュリティや持続可能性、パフォーマンスに特化した小さなチームを編成し、共同作業を行うことで効果的なレビューが可能になります。ツールには多数の共同作業機能があります。これらを活用して、効率的にカスタムレンズを作成しましょう。

導入の概要: AWS Organizations

カスタムレンズについて説明し、次にAWS Organizationsに統合する方法を紹介します。AWS Organizationsを使用することで、レビューやレンズの共有が組織全体で可能になり、部門間の協力が促進されます。中央チームはダッシュボードのポートフォリオビューを確認でき、全体の状況を把握しやすくなります。 統合を利用して投資の優先順位を決めることもできます。ポートフォリオ全体を見ると、コストの問題が見えてくるかもしれません。その場合、チームにAWS全体の支出状況を確認してもらい、すぐに実施できる改善策や長期的な変化を検討できます。これにより、何を優先して取り組むべきかが明確になります。

導入の概要: AWS WA ラボ

AWS WA ラボの導入についてです。 多くの人は実運用環境で新しいことを試すことに抵抗があるが、それは理解できることです。そこで利用できるのが、 Well-Architected ラボというものです。これによって、どの程度の労力と価値が必要なのかを知ることができます。 多くの人が抱える疑問は「具体的に何をしなければならないかは分かっているが、そのためにどれくらいの時間や労力が必要なのかが分からない」ということです。価値は理解できていても、どのようにしてそれを知ることができるでしょうか。 ラボは、これらの疑問を解決するための最適な方法です。サンドボックスのような環境で構築してテストすることができます。その結果、労力に対する価値がどの程度なのかを判断できるようになります。

改善の概要

改善計画の立て方が非常に重要です。最初に何をする必要があるか学び、その問題を特定して改善します。改善は一度では実現できず、問題の優先順位を決めて段階的に解決することが大切です。また、ワークロードの健全性を継続的に改善するために、適切な優先順位を付けることが重要です。さらに、改善の進捗を追跡するために役立つレポートに注意を払い、信用スコアのように時間の経過とともに改善を行います。すべてが最高レベルのスコアにはならないことを理解し、リスクを認識し、追跡することが必要です。

出力の概要

ここでは、成果に関してデファクトスタンダードや一貫性が重要であることをお伝えしていきます。また、経済においてコストの最適化が不可欠であり、その方法を検討する必要があります。コストの最適化はAWSのリソース支出だけでなく、チーム管理方法も含まれます。リスクを考慮することで、組織内でリソースを適切に活用し、従業員の最適化を実現できます。

Trusted Advisor/サービスカタログのご紹介

今月初めに開始された統合について説明します。これには、Trusted AdvisorとService Catalogの2つのサービスが含まれています。Trusted Advisorは、リソースのベストプラクティスを確認できるサービスです。リソース全体のベストプラクティスを把握できます。これらのベストプラクティスを Well-Architected にマッピングしました。これでツールを使って、どのチェックが失敗したかがわかります。 Service CatalogはApp Registryと統合されます。App Registryは、ワークロードやアプリを一つの単位として見るのに適した方法です。私たちの目標は、ワークロードの観点から考え始めることです。たとえば、どのアプリケーションが影響を受けるのかを知ることです。この統合によって、 Well-Architected レビューがApp Registry内のアプリケーションにマッピングされます。それでいつでもレビューを参照できます。

エンタープライズ向けに優れた設計

それでは、Matthew と Allison に、Liberty Mutual Insurance での、Well-Architected の事例について紹介してもらいます。

私は Matthew Dorrian といいます。 Liberty Mutual Insurance のシニア ソリューション アーキテクトです。 Liberty Mutual について説明すると、 当社は自動車から住宅、企業に至るまであらゆるものを保護する世界的な損害保険会社です。 みなさんは、リバティエミューと非常に美しいジングルを使用した広告を見たことがあるかもしれません。 そして昨年の re:Invent 2021 では、進化するアーキテクチャ戦略をサポートすることを目的として、 イノベーションと実験の文化をどのように構築してきたかについて話しました。

Well-Architected アプローチで、ビジネス価値を迅速に提供するにはどうすればよいでしょうか? 当社には 4000人以上のテクノロジー関連の従業員がいます。 Well-Architected が組織全体で適切に導入される必要があります。

エンタープライズレベルとチームレベルでの Well-Architected に焦点を当てた話をします。 すべてのリーダーと従業員の協力が必要です。私たちは Well-Architected の実現に向けた全社規模の取り組みを行い、導入を重視しました。 脅威組織の代表者を配置し、リバティ相互保険の事業を検証しました。各分野の代表者に献身的な時間と労力を与え、従業員4000人が魅力的な方法で Well-Architected を理解するようにしました。 教育が鍵であることを認識し、一元的なガイダンスとサポートを提供することを目指しました。オンボーディングとリソース検索の容易さに重点を置きました。AWSのリソースを利用し、独自のエンタープライズLMコンテキストで補完することを考えました。 Well-Architected labや独自の補足教育コース、エコシステムを作成し、エンジニアリングの卓越性の定義を持ちました。 ドアメトリクスなどを検討し、 Well-Architected を中心的な柱の一つにしました。プロセスやベストプラクティスに向けた進捗状況を測定し、成熟度の指標を得ました。レンズ全体の使用状況やリスクを可視化し、保険会社で実際に使用されている価値を確認しました。学んだことを取り入れ、カスタマイズされた教育を作成し、エンタープライズリソーススイートや知識ベースの強化を図りました。 段階的に柱ごとにロールアウトし、フィードバックサイクルを短縮しました。BSガイダンスやレビューに関するガイダンスを検討し、オペレーショナルエクセレンスやセキュリティから柱ごとに調査しました。これにより、私たち自身の Well-Architected ロードマップに影響がありました。

これまでの洞察と指標

これまでの洞察と指標を見てみると、2020年から700件のレビューが行われ、2022年も毎月約10～20件のレビューが続いています。700件のうち、50%がサーバレスレンズに集中しており、私たちがサービスアーキテクチャを重視していることがわかります。現在、データプライバシーを徹底する設計を開始し、最初の顧客やカスタムレンズを検討しています。また、オペレーショナルエクセレンスが人気のある柱であり、セキュリティや信頼性が続いています。私たちはリスクを調査し、リスクカテゴリーを分析して、情報を活用してリソースを的確に維持する方法を考えています。

チーム向けの Well-Architected

私は Alison Bridger といいます。 Liberty Mutualのソリューションアーキテクトです。チーム向けの Well-Architected レビューについて話します。私たちがアーキテクチャチームと協力して、 Well-Architected レビューを展開する際、これがただの命令ではなく、エンジニアやチーム自体にとっても価値のあるものになることが重要でした。 私が展開に従事しているチームのほとんどは、 Well-Architected とクラウド開発の両方が初めてです。レビューの進行中に、いくつかの発見をしました。まず、事前にチームにAWSの柱となるガイダンスやホワイトペーパーを共有し、サンドボックスでワークロードを作成して試しに読むことを奨励しました。また、これは単なるチェックボックスにチェックを入れるだけではなく、アプリケーションのコードを改善する機会と捉えることが重要でした。 我々はエンジニアの参加と非エンジニアの参加に重点を置いており、このレビューでは全員がソフトウェアの改善に関与することが目的です。最後に、レビューで得た調査結果やメモを文書化し、バックログ項目や改善のためのストーリーを作成するために使用しました。 私が共有した4つのポイントは、文書化と準備、チェックボックスに関する会話、エンジニアの参加、そして包含性です。 私からは以上です。 Samir に代わります。

次に、マクドナルドの Vamshi Komuravalli (ヴァムシ・コムラヴァリ)さんが、 デジタルアーキテクチャチームにおける主任アーキテクトとして、 故障モード分析において Well-Architected 顧客レンズの使用について語ります。

故障モード解析とは何ですか?

マクドナルドは、100か国以上で4万軒のレストランを展開し、毎日約6500万人の顧客にサービスを提供している世界最大のレストラン会社です。この規模でこの種の複雑性をサポートする為に、マイクロサービス、サーバーレス機能、さまざまなバッチジョブに至るまで、さまざまなワークロードで構成される、拡張性の高いクラウドネイティブデジタルプラットフォームを用意しています。

故障モード解析とは、システムの回復力を向上させるために様々な障害点を特定し、回復メカニズムを組み込むプロセスです。分析では、マイクロサービス、ラムダ関数、バッチアプリケーションなどの異なるワークロードに焦点を当てます。障害が発生する原因として、内部コンポーネントの障害や外部の依存関係が挙げられます。 外部依存関係は、サードパーティのパートナーAPI、インフラサービス、他の内部ワークロードといった3つの異なる領域に分類できます。また、ワークロードの障害がビジネスにどのような影響を与えるかも重要な点です。 回復力を高めるには、耐障害性、サービス構成、信頼性のテスト、監視の4つの異なる領域に分類される様々なテクニックがあります。耐障害性では、フォールトトレランスやサーキットブレーカーなどの手法が使われます。サービス構成では、インフラストラクチャサービスを構成して高可用性を実現します。信頼性のテストと監視では、カオスエンジニアリングやバックアップ復元手順のテスト、SLAやリソースの監視などが行われます。 構造化されたアプローチを採用し、ワークロードごとに回復力のベストプラクティスを適用し、開発者コミュニティがそれらを認識できるようにすることが重要です。

分析と修復のための複数段階のアプローチ

このために、AWS Well-Architected Reviews (WAR) からの、カスタムレンズの活用が助けとなります。 まずはじめに、ベストプラクティスのリストを編集する準備段階について触れています。 さまざまなベストプラクティスがカスタムレンズに変換され、それに関連するPython関数が作成されています。 次に、いくつかのレンズが紹介されています。1つ目のレンズは故障の影響について、2つ目のレンズはAWSサービスに関するもの、3つ目のレンズはパートナーサービスに焦点を当てています。4つ目と5つ目のレンズは内部ワークロードに関連しています。 次のステップでは、データが収集され、企業全体の復元力を理解し、洞察とレポートを確認する必要があります。このために、すべてのデータをパイプし、S3 と Athena をQuickSight に接続しました。QuickSightでは、重要なワークロードや回復力のレベル、改善すべき分野を調べることができました。 改善領域のリストを取得した後、優先順位を付けるメカニズムが必要になります。このためにカスタムスコアリングメカニズムを作成しました。スコアリングメカニズムは、失敗の確率、失敗の影響、改善のカテゴリーに基づいています。 最後に、スコアを付け、リスクの高い改善点のリストを取得し、製品チームがそれらの問題を修正するよう依頼しました。このようにして、分析と修復のための複数段階のアプローチが実施されています。

カスタムレンズの例と結果

カスタムレンズの例を紹介します。例えば、KafkaのマネージドストリーミングであるMSKの回復力のあるレンズでは、トピックのレプリケーション係数が適切に構成されているか確認したいと考えました。また、Dynamoでは結果整合性のある読み取りが強整合性よりも優れた回復力を提供するため、ワークロードが結果整合性のある読み取りを使用できる場合、それを使用することをお勧めします。

お客様のメリット: AWS Well-Architected パートナー

次に、 Well-Architected を導入し、大きなメリットが得られることを実感している他の顧客の例として、Cox Automotive、1898、Mootsが挙げられます。これらの企業では、リスクを生み出すための安全な内部投資という観点から非機能要件を実装しており、Alison が言ったように、システムが適切に構築されていない場合、それらの機能は決して日の目を見ることはありません。組織全体で Well-Architected をどのように使用するかという点では、これらは非常に重要です。

ここでいくつかの点を強調したいと思います。 AWS Well-Architected パートナーには、 Well-Architected レビューの構築と実装を支援する者がいて、組織全体のメカニズム構築も支援します。これにより、お客様にはいくつかのメリットが得られます。例えば、視認性が向上し、コストのかかる建築上の神話を避けることができます。 しかし、実際には基本的なことをおろそかにしてしまうことが多々あります。例えば、ボリューム設定時と同じ AZ でバックアップを実装し、後で AZ が削除されるとバックアップも失われてしまいます。これらは避けるべき事象ですが、意外とよく起こることです。 また、単体テストや統合テストを行う際にはアーキテクチャのテストが欠けていることが多く、マルチ AZ からシングル AZ への移行が適切に注目されていない場合があります。さらに、ソフトウェアの展開方法についても、適切な検証が行われていないことが珍しくありません。 Well-Architected は、これらの課題を測定するのに適した方法です。いずれ、 Well-Architected テストが作成されるかもしれないですが、それをパスしないものはデプロイせずに、適切なアーキテクチャへの改善を実施することが重要です。

まとめ

私が伝えたいのは、皆さんが仕事を始めた際に、自分が適切に設計されているか否かをチームにどう伝えるかについてです。このセッションを通じて、「自分は適切に設計されているか？」という問いをチームと話し合う良い方法が見つかることを期待しています。この会話をすることが重要です。なぜなら、もしそういった会話をしていなければ、皆さんはコードや日常業務に多くの時間を費やし、アーキテクチャや構築方法に十分な注意を払わないからです。 善意だけでは機能しません。皆さんには、このセッションを通じて良いアイデアが得られることを願っています。

本セッションの内容に興味を持たれた方は、上部のリンクからセッション動画、セッション資料をご覧ください。