コンテンツにスキップ

第4部 揺り戻しと計測 2015-2020

前の部で払った授業料の、領収書を整理する時代。3つの動きが並行する。型と一貫性の取り戻し、分散の精緻化、そして最も重要な、勘だった領域の科学化。

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)、mypy2015
PHPスカラー型宣言と戻り値型(PHP 7)、後にプロパティ型(7.4)、union 型(8.0)2015-
RubyRBS と TypeProf(Ruby 3)2020
JavaScriptTypeScript の事実上の標準化2015-
Java/AndroidKotlin の公式化(null 安全)2017
Objective-CSwift(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つにする。コードは毎日出す(デプロイ)。機能は準備ができたときに、少しずつ見せる(リリース)。戻すときはフラグを倒すだけで、デプロイは戻さない。列車を逃すという概念自体が消える。

デプロイとリリースを分けると、レバーが1本から2本になるリリーストレイン(第2部)デプロイ = リリース = 賭け2週間ぶんの変更を全部束ねる未完成の機能も「とりあえず乗せる」レバー1本本番: 全部出る、失敗すれば全部戻る次の列車は2週間後プログレッシブデリバリー(第4部)コードを出すことと、見せることを分けるデプロイ毎日、小さくリリースフラグで 1% → 100%レバー2本、別々に引く本番: コードは入っているが、見せるのは少しずつ戻すのはフラグだけ。デプロイは戻さない

操作が2つあれば、「列車を逃す」という概念は消える。コードはいつでも出せ、機能は準備ができたときに見せる。

この部の主役はここだ。3冊の本が、組織運営を勘から科学へ動かした。

SRE 本(2016) は「エラーバジェット」を与えた。「信頼性と開発速度のどちらを優先するか」という永遠の口論を、SLO からの逆算による 数値契約 に変換する。SLO が 99.9% なら、月に約43分の障害が許される。それが予算だ。予算が残っていればリリースし、尽きたら信頼性に投資する。判断は毎回の会議から、1回の契約設計へ移った。重要なのは、100% を目標にしないと明言したことだ。100% を目指す組織は変更を恐れ、変更を恐れる組織は変更を溜め、溜めた変更は大きくなって危険になる。CAB の悪循環を、予算という数字で断つ。

エラーバジェット: 「速度か信頼性か」の口論を1回の契約に変えるSLO を決める例: 月の可用性 99.9%予算 = 許される障害99.9% なら月に約43分予算は残っているかリリースする会議は要らない信頼性に投資する新機能を止めて直すSLI を計測する使った分を予算から引く残っている尽きた

予算が残っている間はリリースに許可が要らない。尽きたら新機能を止めて直す。どちらも予め決まっているので、その場の交渉が消える。

Accelerate(2018) と DORA の研究は、さらに根本的な前提を覆した。2014年から毎年、数千組織に調査を行い、統計的に分析した。示されたのは、デプロイ頻度と安定性はトレードオフではない ということ。高頻度でデプロイする組織ほど障害も少なく、復旧も速い。CAB 以来の「変更を減らすほど安全」という40年の前提が、Four Keys(デプロイ頻度・変更のリードタイム・変更障害率・復旧時間)という測定可能な形で反証された。2つは速度の指標、2つは安定の指標で、4つは同じ方向に動く。理由は単純で、小さい変更は壊れにくく、壊れても原因が分かりやすく、戻しやすい。デリバリーは信念の問題から計測の問題になった。同時に DORA は、CAB のような外部審査がデリバリー性能と 負の相関 を持ち、安定性とは 無相関 であることも示した。申請書は遅くするだけで、安全にはしない。

デプロイ頻度と安定性はトレードオフではない(DORA、2018)速度 → デプロイ頻度、変更のリードタイム安定性 ↑変更障害率、復旧時間CAB の前提: 速いほど壊れるDORA の発見: 速い組織ほど安定Low: 月に数回、復旧に数日Elite: 日に何度も、復旧は1時間未満小さい変更は壊れにくく、壊れても戻しやすい

破線が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 分割。