第4部 揺り戻しと計測 2015-2020
前の部で払った授業料の、領収書を整理する時代。3つの動きが並行する。型と一貫性の取り戻し、分散の精緻化、そして最も重要な、勘だった領域の科学化。
言語 — 静的型の逆襲
Section titled “言語 — 静的型の逆襲”TypeScript(2012年登場、採用の爆発は2015年以降、Angular 2 と VS Code が押した)が「動的言語の資産を捨てずに型を足す」道を示し、JavaScript 圏を10年かけて静的化した。鍵は**漸進的型付け(gradual typing)**である。全部を一度に型付けしなくてよい。any から始めて、境界から内側へ型を入れていく。この経路があったから、既存のコードベースが移住できた。
Rust 1.0(2015)は所有権システムでメモリ安全とデータ競合の検査をコンパイル時に移した。Java が GC で「解放忘れ」を構造に変えたのに対し、Rust は実行時コストなしで同じことをし、さらに「2つのスレッドが同じデータを同時に書く」をコンパイルエラーにした。第3部のマルチコア危機への、型システム側からの回答である。「人間が気をつける」領域をまた1つ構造に変換した。
静的化は宗派対立ではなく、実務の収束だった。これを示すのは、動的言語の側からの歩み寄りである。
| 言語 | 型への歩み寄り | 年 |
|---|---|---|
| Python | 型ヒント(PEP 484)、mypy | 2015 |
| PHP | スカラー型宣言と戻り値型(PHP 7)、後にプロパティ型(7.4)、union 型(8.0) | 2015- |
| Ruby | RBS と TypeProf(Ruby 3) | 2020 |
| JavaScript | TypeScript の事実上の標準化 | 2015- |
| Java/Android | Kotlin の公式化(null 安全) | 2017 |
| Objective-C | Swift(Optional) | 2014 |
null 安全が Kotlin/Swift/TypeScript で常識化したのも象徴的だ。Tony Hoare は null 参照を「10億ドルの過ち」と自省した(2009)。警告ではなく型システムで塞ぐ。「null チェックを忘れない」という規約を、「null かもしれない値はチェックしないと使えない」という構造に。
データ — 「一貫性は諦めなくてよかった」
Section titled “データ — 「一貫性は諦めなくてよかった」”2012年、Google の Spanner 論文が転回点になる。地球規模で分散し、それでも外部一貫性のあるトランザクションを提供する。仕掛けは TrueTime である。各データセンターに GPS と原子時計を置き、「今の時刻はこの区間のどこか」という不確実性付きの時計を API にする。区間が重ならないようにコミットを待てば、全世界で順序が決まる。NoSQL 時代の「規模のためには一貫性を諦める」という前提が、ハードウェアとアルゴリズムで覆された。CAP は間違っていない。ただし、分断の確率を工学で下げられるなら、一貫性を選んでも可用性は実用上十分になる。
CockroachDB(2015)、TiDB(2016)が思想をオープン実装に移した。Aurora(2014)は別の方向からクラウドネイティブな RDB の形を示した。計算と格納の分離。ストレージ層が6重に複製され、コンピュート層は redo ログだけを送る。レプリカの追加が分単位になり、後の fast clone や Blue/Green の基盤になる。
スキーマは復権した。MongoDB 自身がスキーマ検証(3.2、2015)とトランザクション(4.0、2018)を足したことが、第二次授業料の領収書である。オンラインスキーマ変更は外部ツールとして職人芸から道具になっていく。Percona の pt-online-schema-change(2011)はトリガーで新旧テーブルを同期しながらコピーし、GitHub の gh-ost(2016)はトリガーをやめて binlog を読む。どちらも「ロックしない ALTER」を、深夜の祈りから平日昼の操作に変えた。「リレーショナルは古い」という10年前の空気は、「リレーショナルこそ分散の最前線」に反転した。
アーキテクチャ — 分散の精緻化
Section titled “アーキテクチャ — 分散の精緻化”マイクロサービスは反省とともに精緻化される。分散モノリスの教訓から、同期呼び出しの鎖をイベントで置き換えるイベント駆動が普及し、Kafka(2011、LinkedIn)がその土管になった。サービスメッシュ(Istio、2017)が通信の横断的関心事 — 再試行、タイムアウト、mTLS、観測 — をサイドカーに吸収した。Netflix が Hystrix としてライブラリで書いたものを、基盤に沈めた。これも規約から構造への移動である。各サービスがサーキットブレーカーを入れ忘れない、ではなく、入れ忘れられない。
Ford と Parsons の『Building Evolutionary Architectures』(2017)が2つの重要な概念を与えた。適応度関数(fitness function): アーキテクチャ特性の維持を自動検証する。「UI 層は DB 層を直接呼ばない」という規約を、アーキテクチャテスト(ArchUnit など)として CI に置く。境界は文書でなく CI が守る。第1部で「定義だけで測る道具がなかった」結合と凝集が、40年後に測られ、強制されるようになった。もう1つはアーキテクチャ量子(architectural quantum): 独立してデプロイ可能な最小単位。「何を分けたことになっているか」の測定単位である。DB を共有する10サービスの量子は1つだ。分散モノリスを、感覚ではなく定義で見分けられるようになった。
デリバリー — デプロイとリリースの分離
Section titled “デリバリー — デプロイとリリースの分離”フィーチャーフラグは産業になった(LaunchDarkly、2014)。2018年に RedMonk の James Governor がプログレッシブデリバリーと命名する。デプロイ(コードを本番に置く)とリリース(利用者に見せる)を分離し、段階的に露出し、計測しながら進める一群の実践の総称である。カナリア、Blue/Green、フラグ、リングデプロイ。「デプロイ=リリース=賭け」だった時代の終わりが宣言された。
この分離の意味は操作の数で考えると分かりやすい。第2部のリリーストレインには操作が1つしかなかった。実行すれば全部が出て、戻せば全部が戻る。プログレッシブデリバリーは操作を2つにする。コードは毎日出す(デプロイ)。機能は準備ができたときに、少しずつ見せる(リリース)。戻すときはフラグを倒すだけで、デプロイは戻さない。列車を逃すという概念自体が消える。
操作が2つあれば、「列車を逃す」という概念は消える。コードはいつでも出せ、機能は準備ができたときに見せる。
組織 — 勘の科学化
Section titled “組織 — 勘の科学化”この部の主役はここだ。3冊の本が、組織運営を勘から科学へ動かした。
SRE 本(2016) は「エラーバジェット」を与えた。「信頼性と開発速度のどちらを優先するか」という永遠の口論を、SLO からの逆算による 数値契約 に変換する。SLO が 99.9% なら、月に約43分の障害が許される。それが予算だ。予算が残っていればリリースし、尽きたら信頼性に投資する。判断は毎回の会議から、1回の契約設計へ移った。重要なのは、100% を目標にしないと明言したことだ。100% を目指す組織は変更を恐れ、変更を恐れる組織は変更を溜め、溜めた変更は大きくなって危険になる。CAB の悪循環を、予算という数字で断つ。
予算が残っている間はリリースに許可が要らない。尽きたら新機能を止めて直す。どちらも予め決まっているので、その場の交渉が消える。
Accelerate(2018) と DORA の研究は、さらに根本的な前提を覆した。2014年から毎年、数千組織に調査を行い、統計的に分析した。示されたのは、デプロイ頻度と安定性はトレードオフではない ということ。高頻度でデプロイする組織ほど障害も少なく、復旧も速い。CAB 以来の「変更を減らすほど安全」という40年の前提が、Four Keys(デプロイ頻度・変更のリードタイム・変更障害率・復旧時間)という測定可能な形で反証された。2つは速度の指標、2つは安定の指標で、4つは同じ方向に動く。理由は単純で、小さい変更は壊れにくく、壊れても原因が分かりやすく、戻しやすい。デリバリーは信念の問題から計測の問題になった。同時に DORA は、CAB のような外部審査がデリバリー性能と 負の相関 を持ち、安定性とは 無相関 であることも示した。申請書は遅くするだけで、安全にはしない。
破線が40年間信じられていた前提、実線が数千組織のデータが示したもの。傾きが逆である。
Team Topologies(2019) は Conway の法則(1968)を51年越しに運用可能にした。組織構造がアーキテクチャを決めるなら、望むアーキテクチャから逆算して組織を設計せよ(逆コンウェイ戦略)。認知負荷をチーム設計の単位とし、1チームが持てるシステムの大きさには上限があるとした。4類型のチームと3つの相互作用モードで、「誰が何を持つべきか」に語彙を与えた。
| チームの類型 | 持つもの | 例 |
|---|---|---|
| Stream-aligned | 価値の流れ1本を端から端まで | 注文チーム、決済チーム |
| Platform | 他チームの認知負荷を下げる内部製品 | CI/CD 基盤、VPC vending |
| Enabling | 他チームの能力獲得を一時的に助ける | テスト自動化のコーチ |
| Complicated-subsystem | 専門知識が要る部分系 | 動画コーデック、検索エンジン |
重要なのは Platform の定義だ。プラットフォームは統制の道具ではなく、他チームが選んで使う製品である。使われないプラットフォームは失敗している。この定義が、第5部のプラットフォームエンジニアリングへ直結する。
greenfield の現在形: 29チェックリスト=適応度関数の束。サービスモジュール(migrations・cmd・client 込み)=量子。デプロイ(stopDeployment 32秒)とリリース(フラグ)の2つの操作=プログレッシブデリバリーの実装。昇格シグナル3種=エラーバジェット的な数値契約。VPC vending の責任分担=Team Topologies の platform/stream-aligned 分割。