Are you Well-Architected ?
こんにちは（もしくはこんばんは？）AWS Well-Architected Framework の普及に貢献したいマン 大竹 です。
本記事はJapan APN Ambassador Advent Calendar 2021の25日目の記事となります。
2020年のネタに引き続き今回もWell-Architectedなネタでいってみたいと思います。
はじめに
AWS Well-Architected Frameworkの項目の中で個人的にしっくりこないものがいくつかあります。今回はその中で最初に『う～ん』ってなった『バルクヘッドアーキテクチャを使用する』についてオレオレ解釈を行いアーキテクチャレビューなでいい感じに活用できるように改変したいと思います。
読者としては
AWS Well-Architected Frameworkを愛する方を対象にしています。前回のネタと比べ今回はだいぶ独りよがり(？)なブログになっていますが、なにとぞご容赦を m(_ _)m
バルクヘッドアーキテクチャって何だ？
バルクヘッドアーキテクチャは信頼性の柱で登場します。ここの『REL 10 ワークロードを保護するために、障害分離をどのように使用すればよいですか?』という質問に対するベストプラクティスとして紹介されています。
バルクヘッドアーキテクチャを使用する: 船の隔壁のように、このパターンは、障害がリクエストやユーザーの小さなサブセットに確実にとどまるようにすることで、障害のあるリクエストの数が制限され、ほとんどがエラーなしで続行できるようにします。データの隔壁は通常パーティションまたはシャードと呼ばれ、サービスの隔壁はセルと呼ばれます。
シンプルに表現されていますが、完全に初見殺しです。なんとなくわかったような気になることは可能ですが、これを人に説明できるか？と言われたらゴメンナサイと言わざるを得ません。
こっち方ではベストプラクティスの説明以外に改善計画として補足が加えられています。
・ワークロードのセルベースのアーキテクチャを評価する: セルベースのアーキテクチャでは、各セルは独立した完全なサービスのインスタンスで、最大サイズは固定されています。負荷が増加すると、セルが追加されることでワークロードが増大します。着信トラフィックでパーティションキーを使用して、リクエストを処理するセルを決定します。障害は発生した単一のセルに限定され、他のセルがエラーなしで継続するため、障害のあるリクエストの数が制限されます。セル間の相互作用を最小限に抑え、各リクエストに複雑なマッピングサービスを含める必要がないように、適切なパーティションキーを特定することが重要です。複雑なマッピングをするサービスでは、単に問題がマッピングサービスに移行するだけであり、セルが相互作用するサービスでは、セルの独立性が低下します (これにより可用性の改善が想定されます)。
ここで新たに『セルベースのアーキテクチャ』が登場するんですが、個人的にSuperdome 2の『セルブレード・アーキテクチャ』のイメージが強すぎて説明文の内容が全く頭に入ってきません。概念的には似たようなもんだと思うのですが、やはり人に説明できるか？と言われたらゴメンナサイと言わざるを得ません。
セルベースのアーキテクチャの理解にはこちらのブログが役に立つと思います。
（クラスメソッドさん、いつもありがとう）
信頼性の柱に特化したドキュメントでセルベースのアーキテクチャを理解する？
とりあえずドキュメントはこちら。
ドキュメントの方をセルベースのアーキテクチャについて図で補足が加えられています。
なるほど、なるほど。
ここでSuperdome 2のセルブレード・アーキテクチャとも類似点が見つかりしっくり来ました。めでたし、めでたし、、、？
ここまで説明だとあくまでセルベースのアーキテクチャに関する説明であり、それがバルクヘッドアーキテクチャそのものとも受け取れますが、そうであるなら最初から『セルベースのアーキテクチャを使用する』と書けばいいわけで、まだモヤッとしたものが残ります。
もう少し探索を続けましょう。
結局バルクヘッドアーキテクチャって何なのよ？
Azureアーキテクチャセンターのドキュメントにも『バルクヘッド』の項目があり、これが参考になりそうです。
図が2つ示してあり、前述のセルベースのアーキテクチャとは少し違った感じになっています。
MSさんの解説を読み込んでいくとバルクヘッドアーキテクチャとは下記2点がポイントになるのかなと思います。
- 障害の影響を抑え込む(限定的にする)ための分割(分離)の考え方
- セルベースのアーキテクチャはバルクヘッドアーキテクチャを実現するパターンの1つ
ここでスタートラインに戻ってみると『ワークロードを保護するために、障害分離をどのように使用すればよいですか?』との関連性に気付きます。結局のところ障害を波及させないためにどう分離するのか。そのための考え方としてバルクヘッドアーキテクチャがありますよ、ということを言っています。
いざオレオレ解釈
バルクヘッドアーキテクチャが何を意図しているのか理解できたので、今度はオレオレ解釈です。
意図がわかってしまえばあとは使いやすいように表現を改変すればいいわけで、アーキテクチャレビューを実施する際はこんな感じで改変しています。
- 特定の役割を持ったワークロード(サービス、システム、コンポーネントなどで置き換えたほうがしっくりきますね)をひとつの単位とする
- ワークロードが障害に陥った際、他のワークロードに影響を及ぼすことがあるか？
- 他のワークロードが障害になった際、影響を受けることがあるか？
結局のところ『ワークロードの独立性を担保して、耐障害性を高めよう』ってことなんですが、レビューの際には『自分が不幸になっても他者を巻き込まないようにするとか、他者の不幸に巻き込まれないようにするって考え方と同じですね（ニッコリ）』みたいに身近なもので説明するといい感じで説明が捗ります。
おまけ
まだしっくりこないよ！って人はこっちの方も読んでおくときっと理解できると思います（知らんけど）