# 理解容易性のための設計 ## 定義 理解容易性(understandability)とは、妥当な技術的背景を持つ人物が、システムの運用上の挙動とその不変条件(セキュリティ・可用性を含む)の双方について、正確かつ自信を持って推論できる度合いである。*Building Secure and Reliable Systems* 第6章はこれを本書全体で採用する定義として提示し、理解容易性は特性ごとに大きく変動しうるとする(高負荷時の挙動は理解しやすくても、悪意ある入力に対する挙動は理解しにくい、など)。目標は複雑性そのものの排除ではなく、人間が高い確度で推論すべき特定の性質・挙動に対してだけ複雑性を封じ込め・区画化することにある。 第6章は理解容易性を成立させる設計上のてこを5つ挙げる。(1) システムをコンポーネントに分解し、各コンポーネントを単独で推論できるようにすること。(2) セキュリティ・信頼性の横断的要件を、個々のアプリケーションコードではなく中央のフレームワーク(RPCフレームワーク・アプリケーションフレームワークなど)へ集中させること。(3) アイデンティティ・認証・アクセス制御を標準化されたフレームワークで層状に扱い、能動的実体すべてに理解可能で一貫した識別子を与えること。(4) 信頼計算基盤(TCB)を最小限に保ち、想定する脅威モデルに応じてセキュリティ境界を明確に引くこと。(5) 値の性質を型(URL・SafeSql・SafeHtml等)で保証し、下流コードの正しさを検証する範囲を型の実装だけに限定すること。これら5つのてこは独立ではなく、ウィジェット販売アプリのモノリスからマイクロサービス、複数Webオリジンへの分解という一つの事例のなかで組み合わさって働く。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 6 Design for Understandability]]) ## 横断的知見 - **BSRS第6章と *A Philosophy of Software Design*(既存 [[ソフトウェア複雑性]] concept)は、「複雑性・理解容易性は書き手ではなく読み手が判定する」という認識論的な立場を共有しつつ、対処するスケールが異なる**: Ousterhoutは主にモジュール・関数・コード片という粒度で不明瞭さ(obscurity)と明白さ(obviousness)を論じ、レビュアーが「明白でない」と言えば不明瞭だと判定する。BSRS第6章はサービス・マイクロサービス・セキュリティ境界という分散システムのアーキテクチャ粒度で理解容易性を論じ、「妥当な技術的背景を持つ人物が正確かつ自信を持って推論できるか」を判定基準に据える。両者を突き合わせると、「複雑性を読み手・推論者の視点で管理する」という設計思想は、単一プロセス内のコード設計から分散システムのアーキテクチャ設計まで、スケールを問わず一貫して有効であることがわかる。ただしBSRS第6章はコードレベルの明白さの技法(命名・一貫性など)には立ち入らず、Ousterhoutはセキュリティ境界やTCBのようなアーキテクチャレベルの概念には立ち入らないため、両者は同じ思想の異なる縮尺への適用として補完関係にある。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 6 Design for Understandability]], [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 18 Code Should be Obvious]]) - **BSRS第6章は、既存 [[信頼計算基盤（TCB）]] concept が集約するTCB分割の弊害論(*Principles of Computer System Design* 第11章)に、「なぜTCBを小さく保つべきか」という理解容易性の観点からの理由づけを付け加える**: 既存ページは、TCBの分割を誤ると(1)セキュリティ検証が困難になる、(2)ユーザー体験が悪化する、(3)システムの進化速度が落ちる、という3つの弊害を論じる(Saltzer & Kaashoek)。BSRS第6章はこれとは独立に、TCBに数えられる資格として「明確なインターフェースを持ち、その正しさを他のコンポーネントへの仮定に依存せず単独で推論できること」を挙げ、TCBはしばしばそれ自体が独自の障害ドメイン(failure domain)になるため、バグ・DoS攻撃・運用上の影響に対するシステムの振る舞いを理解しやすくする副次的効果を持つと述べる。両ソースを突き合わせると、TCBを小さく保つ動機は「セキュリティ検証の困難さを避ける」ことだけでなく「TCBという単位そのものが理解容易性の基本的な構成要素になる」ことにもあり、TCB最小化は純粋なセキュリティ上の要請であると同時に理解容易性の要請でもあるという二重の動機づけを持つことがわかる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 6 Design for Understandability]], [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]]) ## 未解決の問い - 理解容易性を定量的に測定する方法は本章に示されていない。[[ソフトウェア複雑性]] concept が集約する静的メトリクス(McCabe循環的複雑度・Halsteadソフトウェアサイエンス)は、分散システムのアーキテクチャレベルの理解容易性(コンポーネント分解・セキュリティ境界の引き方)にも同様の形で適用可能か、コードメトリクスとは別の指標体系が必要か、両ソースを突き合わせただけでは判断できない。 - TCBを小さく保つことと、セキュリティ・信頼性要件をアプリケーションフレームワークへ集中させることは、時に緊張関係を持ちうる(フレームワーク自体が肥大化し、TCBに含まれる範囲を広げる可能性がある)。本章はこの緊張関係を明示的には論じていない。 - 組織横断で単一のアイデンティティ体系・メンタルモデルの一貫性を保つことは理解容易性の要件として述べられるが、複数チームが独立に開発する大規模組織で、この一貫性をどう組織的に担保するか(ガバナンス・レビュープロセスなど)は本章の範囲外であり、第20章・第21章のingestで扱われる可能性がある。 ## 関連 - source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 6 Design for Understandability]] - 概念: [[信頼計算基盤（TCB）]](TCBを小さく保つ理由としての理解容易性) / [[ソフトウェア複雑性]](コード粒度の複雑性論との対比) / [[セキュリティ設計原則]] / [[認可モデル]] - 実体: [[ALTS]] / [[Tink]] / [[Borg]] / [[Kubernetes]] ## 出典 - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 6.