はじめに
SREワークブック第14章「Configuration Design and Best Practices（構成の設計とベストプラクティス）」を読んだ所、概念としてAWS CDKが近い事を実践しているように感じたので、
- SREワークブックの内容の紹介
- 個人的に感じたAWS CDKにおける適応の考察
についての記事です。
今回はSREワークブックの14章の中より、特に気になる項目の要点と所感を記載していきます。
https://sre.google/workbook/configuration-design/
AWS CDKについては詳しく解説はしませんが、一言で表すと「プログラム言語でインフラ定義が可能なIaCツール」です。以下、参考文献等まとめてあります。
https://qiita.com/yoyoyo_pg/items/e7e85839341d16006b87
構成とは？（What Is Configuretion?）
- システムは「ソフトウェア」「システムが処理するデータセット」「システム構成」の3つの主要コンポーネントがあると考えられる
- 優れた構成インターフェイスを使用すると、信頼性が高く、テスト可能な構成変更が可能になる
- 逆に不十分な構成インターフェイスの場合はミスが発生する可能性が高くなる
構成と信頼性（Configuration and Reliability）
- 人間が利用する構成インターフェイスの品質は、システムを実行する組織の能力に影響を与える
- これは、コードの品質がシステムの保守性に与える影響に似ている
- コードの変更と対照的なのは、1つのシステム構成の変更で劇的に機能が変化する可能性がある点
- インシデント発生時には、簡単かつ安全に調整できる構成システムが不可欠
哲学と力学の分離（Separating Philosophy and Mechanics）
- 新しいソフトウェアを設計したり、既存のソフトェアコンポーネントから新しいシステムを組み立てるとき、構成は「構成の哲学」と「構成の力学」の二つに分ける
- 構成の哲学は、他のメカニズムから完全に独立している
- 構成を構築する方法や、正しいレベルの抽象化を達成する方法等が含まれる
- 構成の力学は、言語設計や他のシステムとの相互作用のトピックを扱う
構成の哲学（Configuration Philosophy）
- 理想的な構成は、構成が全くない事
- 新しいシステムが展開された時に既に存在していた構成の一部に基づいて、正しい構成を自動的に認識する
- つまり、多数の調整可能変数から遠ざかり、単純化する方向
- システムに対し実行できる制御の量を減らし、エラーの表面積とオペレーターの認知的負荷の両方を減らす
所感
- よくあるパターンとして単純化出来るという点はCDKのL2、L3コンストラクトに考え方として近いのかもしれないなと感じました。（勿論、L1コンストラクトが必要な場面もあったりと、必ずしも単純化出来ない場合もありますが）
- また、新規のスタックやコンストラクトを作成した際に、既存パラメータをprops、クロススタック参照等で渡して動的に構築する事が文書中の「自動的に認識」に近い部分があるかもしれないと感じます。
構成がユーザーに質問する（Configuration Asks Users Questions）
- アプローチとしては、インフラストラクチャ中心（設定多い） or ユーザー中心（設定少ない）
- ユーザー入力を最小限に抑えるという哲学に基づいて、私たちはユーザー中心のビューを好む
- 構成オプションが限られてくると、非常に用途の広いソフトウェアよりも採用が進む可能性がある
- オンボーディングの労力は大幅に少なくなる
質問はユーザーの目標に近いものでなければなりません（Questions Should Be Close to User Goals）
- 分かりやすくお茶を淹れる例で例えると、以下の違いが存在
- 「温かい緑茶」を頼んで、大まかに欲しいものを手に入れる
- 「水の量」「沸騰温度」「お茶のブランドとフレーバー」等、プロセス全体を指定する
- 後者のプロセスを遵守するためにはコストがかかる
- 代わりに高レベルの目標を説明する事で、システムは時間の経過とともに、その目標の実装方法を改善できる
所感
- 少ない設定だと、ミドルウェアやインターフェースの実装等、ユーザから隠蔽されている部分の変更コストが低く済み、実装方法を改善させやすいのだと解釈しました。
- CDKを使う場合だと「AとBの要件を満たすもの」といったような大まかな方向性を決めて（細かなチューニングはAWSのデフォルトに任せて）構築をするといった使い方もすると思うので、考え方として近い物を感じました。
必須項目と選択項目（Mandatory and Optional Questions）
- ユーザー中心で導入しやすいシステムを維持するには、必須の構成に関する質問の数を最小限に抑える必要がある
- 簡単な方法としては、必須の質問を減らしてそれらをオプションの質問に変換すること（=つまり、デフォルトの回答を提供）
- デフォルト値は静的でハードコードされた値だが、システムの他のプロパティに基づいて動的に決定でき、構成をさらに簡素化できる
- デフォルトの値は構成ユーザーの要件に応じて改善も検討する
- デフォルトの値の選択を間違えると多くの害が生じるので、選択の影響を慎重に検討する
所感
- 必須パラメータは最小限かつ、オプション指定の箇所は指定しなければデフォルトの値になる点など、CDKにも当てはまる点だと思いました。
- CDKの実装例に適応してみると「デフォルト値が入力されるからパラメータを書かない」とするのも勿論手ですが「確実に設定したい箇所は明示的に指定」といった事も逆に必要なのかもしれないと感じました。（提供されているデフォルトが必ずしも正しい物とも限らないと感じた為）
構成の力学（Mechanics of Configuration）
- 先ほどまでは「構成の哲学」として紹介したが、ここからは構成を操作する方法の仕組みに焦点を当てる
構成と結果データを分離（Separate Configuration and Resulting Data）
- 私たちの経験からはコードとデータの両方を持つが、2つを分離することが最適と示されている
- ここでのデータはProtocol Buffers,YAML,JSON等の静的データ
- データを生成する上位のインターフェースと対話できる
- インターフェイスはほとんど何でもかまわなく、Python,Lua,Jsonnet等の高水準言語などにすることが出来る
- 構成がどのように取り込まれたかに関するメタデータも保存すると便利（作成者を追跡等）
所感
- CDKで各種コードを書きながら（インターフェース相当）、それが展開された形としてCloudFormationテンプレート（構成データ）が生成されるスタイルはこの章で書かれていることに近いと感じました。
ツーリングの重要性（Importance of Tooling）
- 構成システムを設計する際には見過ごされがち
- これらのツールにより、ユーザーは構文の正しさに確信を持ちながら構成を作成、編集できる
- セマンティック検証・・・構成が構文としてだけでなく、意味あるものであることを検証する
- 構成検証・・・エディターでの構文の強調表示やリンターの使用による矛盾の特定等
所感
- CDKをプログラム言語で記載できるからこそVSCodeのエディタやLinterを活用して
cdk deploy前に構築リソース検証できる点は概念として似ているなと感じます。
所有権と変更追跡（Ownership and Change Tracking）
- ユーザーを適切に分離し、システムで発生した変更を理解することが重要
- 構成への変更とその結果のアプリケーションの変更をシステムに記録すると便利
- これによりインシデントの原因となる構成編集を迅速に判別でき、確実なロールバックに役立ち、かつ関係者に通知できる
所感
- これは「アプリケーションコードとCDKコードを共通リポジトリで管理」の話に似ているなと感じます。
- 常に現状のリソースの視認性を高く持てる点は、インシデント対応する上でも役立ちそうだなと感じます。
安全な構成変更アプリケーション（Safe Configuration Change Application）
- 新しい構成をデプロイするときは、グローバルな一括プッシュを避けることが重要で、新しい構成を徐々にプッシュする
- そうする事で、問題のあるプッシュを中止できる
おわりに
- AWS CDKの利用という観点を用いつつ今回は読んでみましたが、ソフトウェア提供の観点として読み直してみても面白そうです。
- 「SRE本」の他二つや、ワークブックの他の章はまだじっくり読めていないので、また発見があれば追記します。
- 一部拡大解釈等もあるかもしれませんが、ご容赦下さい