ForgeVision Engineer Blog

フォージビジョン エンジニア ブログ

ラスベガスで Well-Architected Framework を学んできました！

AWS re:Invent2023 Well-Architected

こんにちは、AWS チームの尾谷です。
おかげさまで今年も re:Invent に参加することができました。

今年は、AWS Community Builders だけでなく、2023 Japan AWS Ambassadors のイベントもゴールドジャケットを着て、世界のトップエンジニアや、HERO とコミュニケーションを取ることができたのが、大きな収穫でした。

Mandalay Bay 会場

僕は、今年はコミュニティイベントに参加したり、Orca Security の会食があったりと充実していた反面、例年と比較してセッションを受ける時間が取れなかったのですが、直近半年ほど内製化チームのマネージャーとして Well-Architected Framework (W-A) のレビュー (WAFR) を行うための検証やレビューを行ってきたので、W-A 関連のセッションを中心に選択しました。

W-A を学べた場所

関連するセッションは僕が調べた限り、メイン会場である Venetian では開催されず Wynn や MGM Grant、Mandalay Bay で開催されていました。

僕たちフォージビジョンのメンバーはコスモポリタンというカジノホテルの近くのコンドミニアムで合宿スタイルで生活していて、僕はそこからメインの Venetian ではなく、サブの会場にばかり行っていたので、日中は現地に来られている皆さんとお会いすることがありませんでした。
(決して昼までホテルのベッドでだらだら寝ていたとかではないですっ！！)

ということで、本ブログでは、僕が re:Invent 2023 で学んできた W-A 関連のセッションについてアウトプットしたいと思います。

主な W-A 関連のセッション

まずは、re:Invent のイベントサイトで Well というキーワードで検索してヒットしたものを列挙します。

※ 2023/12/03 に抽出したものです。
※ 単純検索ですので、W-A に関するセッションは他にもあったと思われます。
※ 自分が受講してきたセッションは★マークをつけてます。
※ リピートセッションという再演されたセッションは除外しています。
※ YouTube 公開でされていたものはリンクを添付しております。
※ Well は含んでおりませんが、ARC331 でオススメされた SUP310 と SUP304 も追加しました。

耳を慣らしておくと理解しやすい

W-A のセッションを視聴する上で、知っておいた方が良い用語がいくつかありました。
キーワードを知っていると英語も入ってきやすかったので、列挙しておきます。

WAFR

第一にお伝えしたいのは WAFR です。

聞き慣れない用語で、WAF (Web Application Firewall) 関係の略語かと勘違いをして視聴をしていたら、Well-Architected Frameworks Review のことでした。
今後、積極的に使っていきます！
ただ、セッションによっては Well-Architected Framework と正式名称を貫いているケースや、WAFRs と記述されたスライドもあり、あまり統一されていないようなので、使い方は気をつけた方が良いとも感じました。

Well-Architected ツールでは、WAFRs と略称されています

Pillar

柱のことです。W-A は、6 つの柱に区分けされるため、頻繁に耳にします。

Operational Excellence

オペレーショナル・エクセレンスは、W-A の柱の一つとして日本語では「運用上の優位性」と翻訳されています。
オペレーショナル・エクセレンスは、AWS 以外でも最近よく目にするようになったように感じます。

僕は、洗練された運用といった意味で理解しています。

Security Posture

Security Posture はさまざまなセッションで頻繁に耳にするキーワードです。その場しのぎの対応ではなく、根本から対応された動じない強固な環境を構築することが重要です。

Reliability

信頼性という意味で、W-A の柱の一つです。
これは、W-A のセッション以外でもよく耳にします。ただ、外人は「リライアリティ」と発音しているように僕には聞こえて今でも耳が反応しません。

Performance Efficiency

パフォーマンス効率も W-A の柱の一つです。

Sustainability

サステナビリティ (継続可能性) は、テレビでもよく出てくるようになりました。
W-A の柱のうちで最も歴史が浅く、Trusted Advisor との連携もなくて、扱いづらいところがありますが、今後重要な柱になっていくと感じています。

W-A の成り立ち

コストを意識する

金曜日の Werner Vogels の Keynote のテーマの一つに コスト がありました。

Architect with cost in mind

アーキテクトは常にコストを意識しないといけない。という 2012 年の re:Invent のテーマを引用して、オブザーバビリティ監視の重要性が語られました。

YouTube より引用

2012 年というとまだ、Lambda も誕生していませんでした。今ほどベストプラクティスも蓄積されていなかったはずです。

W-A の歴史

W-A の歴史を紹介していたセッション (ARC216) があり、当時の状況がよく理解できましたのでご紹介したいと思います。

ちょうど、Werner が 2012 年にコストの話をしていた頃、Well-Architected Framework は誕生したようです。
AWS の W-A チームに所属するプロダクトエンジニアリングチームの Samir Kopal さんは以下のように話されていました。

  • 人気のある AWS のサービスの 1 つで、大きな問題 (停電) が発生して、一部のお客様に影響が出てしまった。
  • AWS は、AWS をご利用いただいているお客様に対して、例えば、誰に影響が発生したか？どのような事象が発生したか？再発防止には何をすべきか？などを聞いて回った。
  • 一部のお客様では、問題が発生していないことが分かり、それらのお客様では、適切な冗長性をシステムに組み込んでいたことが分かった。
  • この情報を共有しないといけないと思い、ソリューション・アーキテクトが集結して、話し合いあった。
  • そして、2012 年、今日「Well-Architected Framework」と呼ばれるホワイトペーパーを完成させた。

当時は Multi-AZ だとか、DR といったアーキテクチャは AWS の中でもベストプラクティスとして浸透しておらず、オンプレミスからクラウドにリフトするには TCO (人件費や空調費などを含んだ総合的なコスト) を強調していたと思いますが、障害やお客様の構成からベストプラクティスを AWS の SA が学んだという点が非常に印象に残りました。

W-A のホワイトペーパーがローンチされた後は、お客様と継続的なレビューを重ねていき、毎年アップデートを重ねてきたということです。

Year Event
2012 Well-Architected のホワイトペーパーが誕生
2013 AWS SA レビュー
2014 コスト、信頼性、パフォーマンス、セキュリティの 4 つの柱を確立。
2015 Well-Architected Framework として公開
2016 オペレーショナル・エクセレンスの柱を追加
2018 AWS Well-Architected Tool をローンチ
2020 API などのレンズをリリース
2021 サステナビリティの柱を追加
2022 Service Catalog と Trusted Advisor の Well-Architected Framework Tool 統合をリリース
2023 連結したレポート機能をリリース
2023 プロファイル機能をリリース
2023 テンプレートをリリース
2023 レンズカタログをリリース

W-A は、2015 年に Werner Vogels のキーノートで発表され、メジャーになりました。
2016 年には「やっぱり、人が介在する必要があるよね。サイロでは機能しないよね。」という話になったようで、オペレーショナル・エクセレンスがリリースされました。
2021 年にはサステナビリティの柱が追加されて、現在の 6 つの柱になり、今年 (2023 年) は特に多くの機能がリリースされました。

AWS パートナーネットワーク界隈でも、W-A の話を聞く機会が増え、盛り上がっている印象があります。

印象に残った考え方

以下、セッションを受講して印象に残った考え方をまとめます。

コストは単に安く上げるだけではない

先ほど Werner が Keynote で「アーキテクトは、常にコストを意識しないといけない。」というテーマで話をしていたとご紹介しましたが、同時に「コストを節約するといろんなことができるようになる。」といったニュアンスを話していました。

W-A 関連のセッションで、お客様はついコストを重要視するケースが多いが、単にコストを下げて利益を増やすだけではなく、浮いたコストをアーキテクチャ投資に利用するといった広い視野で考えるべきだといった説明があり、Werner の考えと一貫していたので理解が深まりました。

広い視野を持つ

WAFR を行う場合は、視野が狭くならないように注意しようとの説明がありました。
顧客はレビュー時に、一つの柱に意見が集中してしまうケースがあるが、顧客との信頼関係を築けば別の柱に目を向けてもらえるといった説明があるとのこと。
これを実現するには、お客様のことを理解し把握することが必要だと感じました。

過去の慣習にとらわれない

日本の企業は物事を実行に移す前に、過去の事例から実施可否を決定づける傾向があるように感じます。

We’ve always done it this way (これまでも、そうやってきたから)

Werner も上記の表現で苦言を呈していましたが WAFR の実施可否は、成功体験を増やしてスタートしやすい環境を用意していくのが近道だといった解説がありました。 成功体験は、トレーニングツールや、専門家の意見を取り入れて効率的に進めていくのが良いという説明にも共感ができました。

早めに見つかった問題は悪いことではない

TNC216 のセッションで語られたエピソードです。

  • アプリケーションの構築やワークロードのデプロイの初期段階で、すごく基本的な見落としをしてしまった
  • 例えば、バックアップを取得する設定を忘れたと仮定する
  • バックアップは、おそらくほとんどの人にとって自動的に行うため、突然気づく
  • 場合によっては、周りから責められるかも知れない
  • でも、早期に気づけたことは良いことで、何か手を打つことはできるし、対処することもできる

若干、雑な理解で恐縮ですが、WAFR を行うときは非難するのではなく、前向きにアクションを起こすのが良いと理解しました。

Copilot

効率的に WAFR を行うには、一人でチェックするのではなく、誰かと一緒にレビューを進めるのが良いとのことで、Copilot というキーワードで解説されていました。

どのエンジニアも苦労している

ARC331 Deliver business outcomes from AWS Well-Architected Framework の Chalk Talk は満席でした。
W-A の人気の高さを感じるセッションで、登壇者と視聴者の間で活発に意見が交わされました。

ビジネス成果ということで、以下の例が挙げられていました。

  • 攻撃があっても動じない体制
  • ビジネスの成長
  • 顧客を維持する
  • 価値／コスト提案の改善
  • 持続可能性の目標とターゲット
  • 売り上げを上げる
  • 顧客満足度の向上
  • 市場シェアの向上
  • ブランドを構築する

上記以外にも「なぜ W-A レビューを行うのか？」という問いに対して参加者から以下のような意見が出ました。

  • リスクマネジメント
  • リスク軽減
  • コンプラアンス機関が関心を持っているため
  • 当局に従わなければならないから

一部、やらされている感を感じるコメントもあり、エンジニア同士で苦労を共有していて良いセッションでした。

レビューにおける 3 つのフェーズ

レビューにおける 3 つのフェーズということで、ARC331 で以下が紹介されていました。

Prepare (準備)

まず、Prepare (準備) に関しては、ステークホルダーを明確にすること、柱の優先順位を決める、オーナーシップを確定する、依存関係を把握する、コスト比較する、ワークロードのスコープを把握することなどが重要とのことでした。

Review

次に、Review に関しては、レビュー結果の記録が重要とのことでした。

また、「ああすればよかった。」といった後から批判するようなレビューは止めようといった指摘がありました。
改善する方向に前を向いたレビューが良いということだと理解しました。

Improve

最後の Improve (改善) に関しては、レビュー結果を持って改善のアクションを起こすことが重要とのことでした。

レビューフェーズの別の考え

TNC216 でも同じように 3 つのフェーズが提示されましたが、こちらは、学習、測定、改善の 3 つでした。

効率的にレビューするには

最後に、ARC216 セッションの中盤で、Ilana Morris さんが、Trusted Advisor を使った W-A Tools のデモをして下さいましたので、紹介しておきたいと思います。

レビューテンプレート

レビューテンプレートを使うと、予めチェックする項目を限定できます。
共有ができるので、管理者から各メンバーに依頼する際に便利です。

プロファイル

プロファイルを利用すると優先的にチェックする項目が別項目としてグルーピングされます。

これは、ワークロードにプロファイルを追加するだけで有効になりますし、

IAM ロールやユーザーに対して、共有をかけることができるので、チームで統一して効率よくレビューを進めることができます。

ただ、Ilana さんは、プロファイルによって優先順位付けがされるからといって、他のリスクを無視して良いということではないと、忠告されていました。

まとめ

Well-Architected Framework というカテゴリだけ限定しても、これほど盛り沢山なトピックがあり、改めて re:Invent のスケールの大きさを感じることができます。

繰り返しになりますが、昨年あたりから徐々に Well-Architected Framework が盛り上がっています。
ご興味を持たれた方は、無料ですので、Well-Architected Framework Tool でワークロードを作成するところから始めてみては如何でしょうか。