AWS Well-Architected Framework は6つの柱から成るベストプラクティス集ですが、独特な言い回しがあって理解するのが大変、という意見をよく耳にします。
この記事ではそういった言葉を自分なりに咀嚼して出来るだけわかりやすく解説したいと思います。
全体
ドキュメントはこちら
ドキュメントにもありますが、W-Aでよく出てくる特有の用語があります。
コンポーネント
EC2とかS3とかデータベースとかそういったリソースも含みますが、アプリケーションに欠かせないコードや運用ドキュメントなんかも「コンポーネント」と表現します。有形か無形かではなく、ワークロード（後述）に重要な"要素"かどうかがポイントです。
この用語は比較的 運用上の優秀性の柱 でよく出てきます。
ワークロード
AWSアカウントやVPC、ももちろんこれの一部ですがそれだけはありません。皆さん方開発チームや運用チーム、ステークホルダーといった「人」もワークロードの一部として表現することもあります。
こちらも「モノ」だけではないというところがポイントです。
この用語は 6つの柱全体 でよく登場します。
設計原則
「一般的な設計原則」というゼネラルなものと、柱ごとに存在する「設計原則」があります。
読んで字のごとくこちらの原則に則り設計を行うことで、Well-Architected なワークロードに近づきます。
なお各柱に存在するベストプラクティスは必ず、「一般的な設計原則」と各柱の「設計原則」を満たしているものです。
例）信頼性の柱 REL11-BP03 すべてのレイヤーの修復を自動化するというベストプラクティスは、一般的な設計原則 自動化でアーキテクチャ実験を容易にすると信頼性の設計原則 障害から自動的に復旧するから来ています。
セキュリティ
ドキュメントはこちら
フォレンジック機能
フォレンジックは「法医学の」「法的に有効な」という意味で、この場合重大なインシデントが発生した際に法的な証拠の確保や第三者専門機関の調査体制があるか、ということを指します。
ゲームデー
いわゆる障害対応訓練です。
ペネトレーションテスト
侵入テストのことです。ハッカーの侵入をシミュレーションし、想定通りに封じ込めが行えるか、想定外の侵入経路がないかなどをチェックします。
信頼性
ドキュメントはこちら
グレイスフルグラデーション
直訳すると「上品な劣化」ですが、この文脈では一つや二つのコンポーネントに障害があったとしても、何か（パフォーマンスとか）を犠牲にしながらシステムが停止しないようにするために実装するべきと説明されています。
がちがちの依存関係から疎結合を意識しつつ全体の停止が起きないように設計します。
緊急レバー
言葉からご想像の通りかと思います。
例えばYahoo!ニュースでは大きな地震が起こった際などアクセスが集中すると、簡易ページに切り替わる機能があります。あれも不可によってサービス全体を止めないための一種の緊急レバーかなと思います。
イミュータブルなインフラストラクチャ
イミュータブルは「変更不可能」という意味です。つまり一度デプロイしたらそのインフラは修正できません。
その代わり新しい代わりの環境を用意して、そちらに変更することが出来ます。そうすることで高い信頼性を確保しつつインフラの修正が可能です。
ブルーグリーンデプロイメントなどを使用して環境を管理します。
バルクヘッドアーキテクチャ
この記事を書こうと思った元凶です。最初何のことか全く分かりませんでしたが、お客さんに何回も説明しててやっと、なんとなく理解出来ました。
バルクヘッドとは隔壁のことです。特に船の隔壁をイメージして頂きたいのですが、それは浸水を一つの区画に止め、船全体が沈まないようにするための重要な役割を持っています。
信頼性が求められるアーキテクチャでも同じように、ある区画で障害が起こることで全体に影響を及ぼさないよう、隔壁（LBやドメイン、ネットワークなど）で分割する設計がバルクヘッドアーキテクチャです。
バイモーダル動作
バイモーダル動作とは、正常時と障害時にそれぞれ違う動作をすることを指します。
例えばフロントエンドで障害があった時に、普段5%とかのCPU使用率を100%近くまで上げて頑張っちゃうバックエンドサーバくんがいたとすると、それはバイモーダル動作です。
意見障害に対応しようとしてて偉い！って思いますが、普段と違うことをすることは更なるインシデントの温床です。
こういった対処ではなく、仮に障害が起こった場合でも通常時と同じような動作をするように、予めリスクヘッジを行って設計しましょう。
カオスエンジニアリング
これもよく聞く言葉かもしれません。意図的に障害を起こして自らの力を試します。
先ほどのゲームデーよりちゃんと障害を起こします。起こしたうえでしっかり対処が出来るかを確認するのが目的になります。
有名な話でネットフリックスのサーバーにはイタズラ好きのお猿さんが常駐しているらしいです。
エクスポネンシャルバックオフ・ジッター
エクスポネンシャルバックオフ（Exponential backoff・指数バックオフ）とは、アプリケーションやネットワークが過負荷とならないように、ある秒数待機させてから再試行する、かつその秒数を段々長くしていくアルゴリズムのことです。
1秒待ってダメだから、次は2秒待ってみるか…それでもダメなら8秒待って…的な感じです。
ただスパイクアクセス時などは、大量の人がほとんど同じタイミングでアクセスするので、同じ秒数待たせていたら埒が空きません。
そのためにジッターと呼ばれる「揺らぎ」を追加し、各アクセスの秒数にランダム性を持たせ、分散することが推奨されています。
分かりやすいのであえてGoogleのドキュメントを載せます。
https://cloud.google.com/iot/docs/how-tos/exponential-backoff?hl=ja
運用上の優秀性
テレメトリー
監視や分析のために収集した、アプリケーションのログやデータを指します。メトリックと似た意味ですが、両者の違いは観点の違いかと思います。（僕の理解）
メトリックは 定期的に収集された モニタリングデータやログで、テレメトリーは 遠隔で収集された パフォーマンスモニタリングデータを指す、と理解してます。（僕の理解）
ランブック
いわゆる手順書です。W-Aの文脈の場合は、オペレーターが使用するWordで作られた手順書ではないかもしれませんが…。
パフォーマンス効率
コンピューティングオプション
インスタンスタイプもそうですが、EC2かコンテナかLambdaか？もこれに当たります。とりあえずEC2でやろっか。ではなくて多角的に判断しましょう。
コスト最適化
クラウド財務管理（クラウドファイナンシャルマネジメント・CFM）
そのままの意味ですが、具体的に何？って感じですよね。
AWSが出しているこちらの動画が非常に参考になるので、全人類見てください。
https://www.youtube.com/watch?v=88MMYFdaxrg
また、こちらのガイドブックも非常に参考になります。
https://d1.awsstatic.com/executive-insights/ja_JP/ebook-aws-cloud-financial-management-guide.pdf
サステナビリティ
AWS Device Farm
マイナーサービスだと思います。違ったらすみません。
AWS Device Farm はクラウド上でスマートフォンOSを搭載した実機をエミュレートし、テストを行えるサービスです。シンプルにめっちゃ便利じゃないですか。
https://aws.amazon.com/jp/device-farm/
サステナビリティの柱で出てくる理由は、余計なハードウェアをセットアップしたり何百台も用意したりするのはSDGsじゃないので、こういったマネージドサービスを使いましょうという話のためです。
最後に
他に追加してほしい語録があればコメントにお願いします。