Are you Well-Architected ?
こんにちは（もしくはこんばんは？）AWS Well-Architected Framework の普及に貢献したいマン 大竹 です。
本記事はJapan AWS Ambassador Advent Calendar 2022の23日目の記事となります。
2020年のネタ、2021年のネタに引き続き今回もWell-Architectedなネタでいってみたいと思います。
はじめに
AWS Well-Architected Frameworkの項目の中で個人的にしっくりこないものがいくつかあります。今回も前回に引き続き『う～ん』ってなったネタをピックアップしてみました。『動作を継続的に行う』と『静的安定性を使用してバイモーダル動作を防止する』についてオレオレ解釈を行いアーキテクチャレビューなでいい感じに活用できるようにオレオレ解釈をやってきたいと思います。
読者としては
AWS Well-Architected Frameworkを愛する方を対象にしています。前回と同じくだいぶ独りよがり(？)なブログになっていますが、なにとぞご容赦を m(_ _)m
動作を継続的に行うとは？
文言の意味から『Multi-AZ構成なんで大丈夫！』と判断してしまう人が多い印象ですが、フレームワークを読み込むと少し意味が違うことがわかります。
読んでもしっくりこないので超訳すると『負荷が急激に変化しようとも影響を受けないような仕組みを実装しましょう』と書かれています。『監視対象が増えたのでレスポンスが悪くなりました』とか『アクセス急増による処理落ちでエラー率が上昇しました』などはよく聞く話ですが、こういった事象がそもそも発生しないような（＝外的要因に影響されないような）構造にしておきましょうというプラクティスになります。
各ベストプラクティスはそのベストプラクティスにつながる質問がセットになっており、『動作を継続的に行う』は『障害を防ぐために、分散システムの操作をどのように設計しますか？』という質問に対するベストプラクティスです。ベストプラクティスの解釈に困ったら必ず元の質問を確認するのがフレームワークを読み込むポイントです。で、質問がしっくり来なければシンプル化するのもオススメです。例えば『障害を防ぐために、分散システムの操作をどのように設計しますか？』は『障害を防ぐためにどのような設計にしますか？』と読み替えても支障はないと思います。
話を雑にまとめると『障害を防ぐために、外的要因に影響されないような構造や仕組みを設計しましょう』と言っているだけです。で、具体的にどう設計すべきか？については後半で扱いますので話を次に進めます。
静的安定性を使用してバイモーダル動作を防止するとは？
バイモーダル動作についてはフレームワーク解説があります。
こちらも読んでもしっくりこないので超訳すると『状況に応じて複数の動作モードを使い分けるような実装はやめましょう』と書かれています。ワークロードの状況に応じて最適な動作モードに切り替える方がインテリジェントな感じがしますが、逆に複数の動作モードを実装することで設計が複雑になり安定性や品質が低下するものと考えられます。少々雑な解釈ですが『状況に左右されないシンプルな構造がいいよね』って話です。
このベストプラクティスに対する質問は『コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか？』ですがもう少し言い回しをシンプルにすると『（コンポーネントの）障害に耐えるためにどのような設計にしますか？』となります。
またもや話を雑にまとめると『障害に耐えるために、シンプルな構造を設計しましょう』となります。
『動作を継続的に行う』と目指す方向はほぼ一緒なので具体的にどう設計すべきか？についてはまとめて考察してきましょう。
結局、どんな設計にすべき？
まずは外的要因に影響されないようスケーラビリティや耐障害性が求められるようなところは基本的にAWSのマネージドサービスにお任せしましょう。セキュリティの柱に『マネージドサービスを活用する』というプラクティスがありますが、同じ話かなと思います。（責任はどんどんAWS側に寄せましょう）
次はコンポーネントの障害などを考慮したシンプルな構造をどう実現するかになりますが、AWSではそれを簡単に実現できるサービスがあります。そう『AWS Lambda』です！（AWS Lambdaの解説は割愛します）
AWS Lambdaを使わなくても次のような条件でアプリケーションの設計を行えば構造はシンプルになると思います。
- 障害のあるコンポーネントはすぐに切り捨てることができる
- 処理単位が小さくリトライが容易
- 並列処理が可能
書いてあることがほぼ負荷分散クラスタになってしまいましたが、そういうことです。
個人的にはマネージドサービスを活用しつつ（スケーラビリティなどの責任はAWS側に押し付けつつ）、各コンポーネントがステートレスな設計になっていればいいんじゃないかなと思っています。ぶっちゃけ類似したベストプラクティスが他にいくつかあるので『動作を継続的に行う』と『静的安定性を使用してバイモーダル動作を防止する』に関してはシビアに捉えなくてもいいんじゃないか派です！
おまけ
なんかアーキテクチャ設計のレビューをやりたくなってきたぞ！ってこちらをどうぞ！（宣伝）
お次は？
明日(12/24)は柴田パイセンのターンです！
乞うご期待！