エンジニアリング哲学：ワーナー・ヴォゲルス

要点

• 彼を定義づける原理は「あらゆるものは常に壊れる」というもので、だからこそ故障に抗うのではなく故障を前提に設計するのです。 2005年から Amazon の CTO を務めるワーナー・ヴォゲルスは、ある身も蓋もない観察――十分な規模になればコンポーネントの故障は絶え間なく起こり、統計的に避けられない――を設計の教義へと変えました。すなわち、すべてのディスク、サーバー、ネットワーク回線、依存先は必ず壊れると想定し、故障を防げるふりをするのではなく、故障を貫いて可用性を保ち続けるシステムを築くのです。¹⁶
• 彼は Dynamo 論文の共著者であり、現代の NoSQL を支える発想を切り拓きました。 「Dynamo: Amazon’s Highly Available Key-value Store」（SOSP 2007）は、コンシステントハッシュ法、ベクタークロック、緩やかなクォーラム、ゴシップベースのメンバーシップ管理、結果整合性を、常に書き込み可能な単一のストアにまとめ上げ、Cassandra、Riak、Voldemort、そして Amazon 自身の DynamoDB に直接の影響を与えました。²³
• 彼は結果整合性の最も中心的な伝道者です。 エッセイ「Eventually Consistent」では、可用性と整合性のトレードオフを率直に示しました。ネットワークが分断されたとき――そして規模が大きくなれば必ず分断は起こります――どちらかを選ばねばならず、Dynamo はすべてのレプリカの合意を待ってブロックするのではなく、可用性を保ったうえで早期に収束する道を選んだのです。⁴⁷
• 彼はエンジニアリング文化に「作った者が運用する（you build it, you run it）」という一節を与えました。 2006年の対談で彼は、開発者が本番環境で自らのサービスを所有する――スコープを定め、構築し、そのうえで運用する――という Amazon のモデルを語り、作り手をポケベルの前に、そして顧客の前に立たせることこそが品質を駆動するのだと論じました。⁵

原理

「あらゆるものは、常に壊れる。」 ―― ワーナー・ヴォゲルス、Amazon CTO、信頼性の高い分散システムの設計について⁶

ほとんどのエンジニアリングは、すべてがうまくいく場合に向けて最適化されています。ハッピーパスを書き、想像できるわずかなエラーを処理し、そして出荷する。その直感は、規模を相手に運用し始めるまさにその瞬間まで生き延び――そしてそこで裏切ります。数十万台のマシンを動かしているとき、「めったにない」はもはや「めったにない」ではなくなるのです。1台あたり3年に1度のディスク故障は、あなたの群れのどこかで数分おきに起こります。100万パケットに1つを落とすネットワーク回線は、1日に数百万パケットを落とすのです。ヴォゲルスの最も有名な一節は、これをわずか数語に圧縮しています。あらゆるものは常に壊れる。⁶ 故障は設計で回避すべき例外ではありません。規模においては、それは設計が向き合うべき定常状態なのです。

そこから導かれる原理は、通常のものを反転させたものです。故障を防げないのなら――そして規模においては証明可能に防げないのなら――防ぐことは誤った目標なのです。正しい目標は、ものごとが壊れている最中も可用性を保ち続けることです。だからこそ、あらゆるコンポーネントは死ぬと想定し、どの一つの死も乗り越えられるように設計します。データを複数のマシンに複製して1台の喪失が見えないようにし、サービスを API の背後で疎結合にして故障した依存先がシステム全体を倒すのではなく一機能を劣化させるにとどめ、そしてどの一つの障害の影響範囲を最小化して、それが全体を巻き込めないようにするのです。システムは故障の場合を避けるために作られるのではありません。故障の場合が退屈であるように作られるのです。¹⁶

この原理には後半があり、それこそが前半を現実のものにします。ネットワークが分断されうる以上、完璧な整合性と完璧な可用性を同時に持つことはできず、だからこそ選ばねばならない――そしてヴォゲルスは可用性を選んだのです。 ネットワークの分裂がレプリカ同士を切り離したとき、システムは全員が合意するまで応答を拒む（整合的だが利用不能）か、手元にあるもので応答を続けて後で調停する（利用可能だが一時的に不整合）かのどちらかをとれます。Amazon のショッピングカートにとって、応答を拒むことは受け入れられませんでした――分断の最中に「カートに追加」を拒むカートとは、売上を失うカートなのです。⁴ そこで Dynamo は常に書き込みを受け入れ、レプリカは後から収束させます。代償は、異なるレプリカが異なる答えを返しうるわずかな時間の窓です。見返りは、顧客に決して「ノー」と言わないシステムです。そのトレードオフ――全員の合意までブロックするのではなく、可用性を保ちつつ早期に収束する――こそが結果整合性であり、ヴォゲルスはこれこそ規模における正しい選択だとキャリアを通じて論じ続けたのです。⁴⁷

背景

ワーナー・ヴォゲルスは1958年10月3日、オランダのエルメロに生まれました。¹ コンピューティングへの道は、一流大学を一直線に進む型どおりのものではありませんでした。彼はハーグ応用科学大学でコンピューターサイエンスを学んで1989年に修了し、ずっと後になってようやくアムステルダム自由大学でコンピューターサイエンスの博士号を取得します――2003年の博士論文「Scalable Cluster Technologies for Mission Critical Enterprise Computing」は、ヘンリ・バルとアンドリュー・タネンバウムの指導を受けたもので、後者は分散システムとオペレーティングシステムの分野における礎を築いた人物の一人です。¹ 心に留めておくべき細部は、この博士号が実際のシステム開発の年月に先んじたのではなく、それに続いたという点です。理論が実践に追いついたのです。

最も形成的な章はコーネル大学で訪れました。彼は1994年から2004年まで、スケーラブルで信頼性の高いエンタープライズシステムに取り組む研究員でした。¹ コーネルではケン・バーマンの分散システム研究グループに身を置きます――Isis と信頼性の高いグループ通信の系譜、すなわち一群のマシンがいかに合意し、整合性を保ち、メンバーが故障し復旧する間も動き続けられるかを問うた研究の蓄積です。彼はバーマンおよびロベルト・ファン・レネッセとともに Reliable Network Solutions 社を共同創業し、その VP 兼 CTO を務めました。¹ これがヴォゲルスが育った知的土壌です。「どうすればマシンを故障させずに済むか」ではなく、「マシンの一群が、そのメンバーが故障する間もいかに正しく利用可能であり続けるか」。後に彼が「あらゆるものは常に壊れる」と語ったとき、それは即興ではありませんでした――彼が10年を過ごした信頼性ある分散システムの伝統の、その根本前提を述べていたのです。

彼は2004年9月に Amazon に入社してシステム研究のディレクターとなり、2005年1月に CTO に任命され、2005年3月には VP の肩書きも加えました――以来ずっと担い続け、全社の技術の方向性を牽引している役職です。¹ 彼の着任は、Amazon が現代のクラウドを発明していた年月と重なります。Dynamo ストレージシステムがこの時期に構築され論文化され、Amazon Web Services が基盤的サービスを立ち上げ、そしてヴォゲルスはそのすべての下にあるアーキテクチャ原理――故障を前提に設計する、サービスを介して疎結合にする、結果整合性を受け入れる、そしてサービスを作った人間にその運用を任せる――の公の代弁者となったのです。²⁴⁵

仕事

「あらゆるものは常に壊れる」――故障を前提とした設計と結果整合性

ここから始めましょう。これは原理がエンジニアリングへと姿を変えたものだからです。この教義には二つの動きがあります。一つ目は故障を前提とした設計です。あらゆるコンポーネントを、いずれ必ず壊れるものとして扱い、その喪失をシステムが生き延びられるようにします。それは冗長化（どの1つのコピーが消えてもよいように複製する）、疎結合（サービスは API を介して対話し、不調な依存先がカスケードせずに優雅に劣化する）、そして影響範囲の封じ込め（システムを分割し、障害が広がるのではなく小さなセルに閉じ込められる）を意味します。¹⁶ 設計の試金石は「すべてが健全なときに動くか」ではなく、「この部品が最悪のタイミングで死んだとき何が起こるか」であり――その答えは「システムは奉仕を続ける」でなければなりません。

二つ目の動きこそ、規模において高可用性を可能にするものです。結果整合性です。エリック・ブリュワーの CAP の観察によれば、ネットワークが分断されたとき、分散システムは完璧な整合性と完全な可用性の両方を備えることはできず――どちらかを手放さねばなりません。⁷ ヴォゲルスの「Eventually Consistent」はその選択を明示し、代替案を正確に定義します。結果整合性のもとでは、「ストレージシステムは、そのオブジェクトに新たな更新が加えられなければ、最終的にすべてのアクセスが最後に更新された値を返すことを保証する」のです。⁴ 最終的にという語が、トレードオフのすべてです。可用性を重んじるシステムは「常に書き込みを受け入れるかもしれないが、ある条件下では読み取りが直近に完了した書き込みの結果を反映しない」のです。⁴ 短く区切られた時間の窓のあいだ、二つのレプリカは食い違いうる――けれども、どちらも応答を拒むことはありません。収束は背後で起こり、ユーザーが待たされることはないのです。

なぜこれがエンジニアリングとして重要なのか。ほとんどの開発者がデータベースについて抱く心的モデルは、単一マシンのものです。そこでは書き込みは、コピーが一つしかないために、後続のあらゆる読み取りに即座に見えます。そのモデルは規模を生き延びません。コピーが一つということは単一障害点であり、マシンが一台ということはスループットの天井だからです。複製した瞬間――可用性のために複製は避けられません――コピーが追いつくあいだ読み手が何を見るのか、という問いを引き受けることになります。ヴォゲルスの貢献は、これを隠すべきバグではなく、意図して選ぶべき設計の次元だと主張したことであり、そしてエンジニアに語彙――read-your-writes、単調読み取り、セッション整合性――を与えて、あらゆる場所で最強の保証の対価を払うのではなく、ある作業負荷が実際にどれだけの整合性を必要とするかを正確に選べるようにしたことです。⁴

Dynamo 論文と NoSQL ムーブメント

この原理には正典となる成果物があります。「Dynamo: Amazon’s Highly Available Key-value Store」で、ヴォゲルスが共著し、この分野最高峰のオペレーティングシステムの会場である SOSP 2007 で発表されました。² Dynamo は、ある具体的で過酷な要件への Amazon の答えでした――ショッピングカートは、データセンターの分断やディスク故障の最中でさえ、書き込みを常に受け入れねばなりません。利用不能なカートは収益を直接失うからです。²³ 強整合性に最適化された従来のリレーショナルデータベースは、分断下でそれを約束できませんでした。そこで Amazon は、整合性と引き換えに可用性をとるストアを構築し、その仕組みを正確に書き残したのです。

Dynamo は、常に書き込み可能で分散的な一つのシステムへと組み上げられた分散システム技法のカタログであり、論文の影響力はそれらをいかに明快に並べてみせたかに由来します。²³ コンシステントハッシュ法はデータをノード間に分割し、リングがすべてを再シャッフルすることなく拡大・縮小できるようにします――「漸進的で、おそらく線形のスケーラビリティ」です。³ ベクタークロックは各値の因果の履歴を追い、並行する書き込みを黙って失うのではなく検出できるようにします。緩やかなクォーラムとヒンテッドハンドオフは、一部のレプリカに到達できないときでもシステムを書き込み可能に保ち、本来のノードが戻るまで書き込みを一時的な代役に預けます。Merkle 木によるアンチエントロピーは、レプリカが互いの差分を効率よく見つけて修復できるようにします。ゴシップベースのメンバーシップ管理は、中央の調停者なしにノードが互いを知り故障を検出できるようにします――この設計は意図的に対称かつ分散的で、「Dynamo のすべてのノードは、その同輩と同じ責任の集合を持つべき」であり、つまりその死が破滅的となるような特別なノードは存在しません。³ これらの選択の一つひとつが、同じ主人に仕えています。ものごとが壊れたときに可用性を保つこと、です。

Amazon は Dynamo のコードを公開しませんでしたが、論文がその役目を果たしました――それはその10年で最も影響力のあるシステム論文の一つとなり、NoSQL ムーブメントの知的な種子となったのです。³ Apache Cassandra、Riak、Project Voldemort はいずれも、そのリーダーレスで結果整合的な設計を Dynamo に直接たどることができます。³ そして名前は Amazon DynamoDB として商業的に生き続けました。これは内部では異なるエンジニアリングの選択をしている（Dynamo の純粋なリーダーレスモデルではなく単一リーダー複製）とはいえ、Dynamo の原理の上に築かれています。³ Dynamo の影響が教える教訓そのものも、留めておく価値があります。Amazon の競争上の堀はコードではなく、明快さでした。どの保証をなぜ手放したのかを正確に説明することで、彼らは一世代のエンジニアに、そのトレードオフをいかに推論するかを教えたのです。

AWS、サービス指向、そして「作った者が運用する」

Dynamo はストレージシステムです。ヴォゲルスのより深い貢献は、アーキテクチャ的かつ文化的なものです。Amazon のプラットフォームは、API を介してのみ対話する独立したサービスのメッシュとして築かれています――幕の裏で手を伸ばす共有データベースもなければ、隠れた結合もありません。⁵ この規律は故障にとって重要です。サービスが硬い界面の背後で疎結合になっているとき、故障した一つは、それが触れたすべてのデータを破壊したりスレッドを停滞させたりするのではなく、それが支える特定の機能を劣化させるにとどまります。サービス指向とは、アーキテクチャとして表現された影響範囲の封じ込めなのです。それはまた AWS を可能にしたものでもあります――いったん内部システムが綺麗な、API でアドレス可能なサービスになれば、それらを製品として外の世界にさらすのは自然な次の一歩です。

文化的な半分は、「あらゆるものは常に壊れる」と同じくらい頻繁に彼の言葉として引かれる一節です。「作った者が運用する（you build it, you run it）」。2006年のジム・グレイとの対談で、彼は各サービスがそれを作るチームによって端から端まで所有される Amazon のモデルを語りました。「各サービスにはチームが紐づいており、そのチームがそのサービスに完全な責任を負う――機能のスコープを定めることから、それを設計し、構築し、運用することまで。」⁵ そしてその根拠は、明確に所有を通じた品質についてのものでした。「作った者が運用する。これによって開発者は自らのソフトウェアの日々の運用と接点を持つ。それはまた、彼らを顧客との日々の接点へと連れて行く。」⁵ コードを投げ越す壁はありません。サービスを書いたエンジニアが、そのポケベルを携えるのです。その効果は密なフィードバックループです――脆さを最も直せる人物が、午前3時にその痛みを感じる人物であり、機能を設計した人物が、顧客の不満を直接耳にするのです。ここでの所有とは人事のスローガンではありません。信頼性の仕組みです。自分が作ったものを運用するチームは、故障を前提に設計します。故障が自分たちを叩き起こすからです。

クラウドの伝道：影響範囲、セル、そしてよく設計されたシステム

ヴォゲルスの四つ目の仕事の本体は、単一の成果物というより、持続する役割です。20年にわたり彼は、クラウドを作る方法だけでなく、クラウドの上で構築する方法を体系化した、アーキテクト兼伝道者であり続けてきました。¹⁶ 繰り返されるテーマは、ますます大きな範囲に適用された原理です。影響範囲を最小化せよ――システムを独立したセルへと分割し、障害や不良なデプロイ、毒入りのリクエストが、全員ではなく顧客の一部に封じ込められるようにする。徹底的に疎結合にせよ――一つの遅い依存先が呼び出し経路全体を停滞させる密な同期的連鎖よりも、明示的な契約を持つ非同期で疎結合なサービスを好む。復旧を文書化するのではなく自動化せよ――人手を要するランブックは、その人が眠っているとき実行されない。故障をテスト入力として受け入れよ――システムが故障を生き延びることを期待するのではなく、意図的に障害を注入して生き延びることを証明する。これらの一つひとつが、「あらゆるものは常に壊れる」を運用の実践へと変えたものです――数々の講演や著述、そして数年後の二度目の ACM 対談を通じて繰り返された一貫したメッセージ、すなわち回復力とはデモが動いた後に付け足す層ではなく、最初の一行から設計に組み込む性質だ、というものです。⁶

方法

Dynamo、結果整合性、サービス指向、そして「作った者が運用する」を横断して読むと、同じ約束が繰り返し現れます。ヴォゲルスの方法は、スローガンというより、常に保たれた一連の習慣です。

まず故障の場合を設計せよ。 規模においては、故障は例外ではなく定常状態であり、だから問いは決して「これは動くか」ではなく「この各部品が死んだとき何が起こるか」です。⁶ その教訓は Amazon の規模をはるかに超えて転用できます――ハッピーパスを書いてエラー処理を継ぎ当てるのではなく、まず故障モードを列挙し、それらをすでに生き延びるシステムから働く経路を導き出すのです。それは信頼性に適用された証拠の関門です――「デモでは動く」は証拠ではありません。「リクエストの最中にノードを殺しても可用性を保つ」が証拠であり、それはラディア・パールマンが、人手を介さず再収束するネットワークに組み込んだ自己修復と同じ基準なのです。

整合性を継承するのではなく選べ。 Dynamo における最も深い動きは、すべての読み取りが先行するすべての書き込みを見なければならないというデフォルトを拒んだことです。ヴォゲルスは整合性を作業負荷ごとに設定するダイヤルにし――正しさが求めるところでは強く、可用性のほうが重要なところでは結果整合的に――そしてシステムが実際にどの保証を提供するかについて正確です。⁴⁷ その規律は、自分の整合性の主張が正確に何の上に成り立っているかを知り、作業負荷が必要としない保証の対価を決して払わないことです。これはレスリー・ランポートが分散的な時間にもたらした、正しさについての同じ精密さです――性質を仮定するのではなく、正確に定義し、それがいつ成り立つかを知るのです。

影響範囲を封じ込めるために疎結合にせよ。 硬い API の背後にある独立したサービスは、故障がカスケードするのではなく、起こった場所に閉じ込められることを意味します。⁵ 常に保つべき習慣は、最悪の場合が劣化した機能であって決して停止したシステムではないように境界を引くこと――あらゆる依存先について「これが壊れたとき、穴はどれくらい大きいか」を問い、その穴を小さくすることです。それは最小限の価値ある製品のアーキテクチャ上の形です。最も綺麗な境界とは、自分の仕事をちょうど果たし、単独で壊れる境界なのです。

作り手に運用を所有させよ。 「作った者が運用する」は、サービスを設計した人間をそのポケベルの前に立たせ、脆さとそれを直せる人物のあいだのループを閉じます。⁵ その教訓は、運用上の痛みこそ存在しうる最も正直な品質の信号だということです――本番から隔離されたチームは回復力への投資を怠ります。脆さの代償が他の誰かに降りかかるからです。所有とは信頼性の仕組みであり、それは品質こそが唯一の変数であるを組織図へと変えたものです。品質を保証する唯一の方法は、作り手にその欠如の結果を感じさせることなのです。

トレードオフを公然と説明せよ。 Dynamo の影響は、そのコード――決して公開されませんでした――からではなく、どの保証をなぜ手放したかを率直に述べた論文から来ました。²³ その習慣は、推論を読み取れるものにすることです――トレードオフに名前を与え、選んだ側を正当化し、結果をカーゴカルト的に真似るのではなく、それについて推論する術を次のエンジニアに教えるのです。なぜについての明快さこそ、設計がその作者を超えて生き延びることを可能にするもの――パールマンやランポートの論文を数十年後も教えられるものにしたのと同じ、説明の規律なのです。

影響の連鎖

彼を形づくった人々

ケン・バーマンとコーネルの信頼性ある分散システムの伝統。 バーマンのグループと Isis／信頼性あるグループ通信の系譜の内側で過ごしたヴォゲルスのコーネルでの10年が、彼の根本前提の源です。¹ その伝統の中心的な問い――マシンの一群が、そのメンバーが故障し復旧する間もいかに正しく利用可能であり続けるか――こそ、まさに「あらゆるものは常に壊れる」が答える問いなのです。彼はスローガンを生み出したのではありません。自分の分野の第一原理を、地球規模の聴衆に向けて言い直したのです。（形成的な影響）

アンドリュー・タネンバウムと分散システムの学究。 彼のアムステルダム自由大学の博士号は、オペレーティングシステムと分散システムの分野の礎を築いた教師の一人、タネンバウムの指導を一部受けたものでした。¹ その土台は表れています――Dynamo は、文献を知り尽くした者が組み上げた、分散システムの正典の働く統合のように読めます。コンシステントハッシュ法、ベクタークロック、クォーラム、ゴシップ。（形成的な影響）

エリック・ブリュワーと CAP のトレードオフ。 ヴォゲルスの結果整合性への論拠は、分断耐性のあるシステムは整合性と可用性をトレードオフせねばならないという CAP の観察の上に明示的に立っています。⁴⁷ ブリュワーが不可能性を枠づけ、ヴォゲルスがその選択を Amazon の規模で実運用に落とし込み、「可用性を選んで収束させる」を立派なデフォルトにしたのです。（直接的な影響）

彼が形づくった人々

NoSQL ムーブメント全体。 Dynamo 論文は Cassandra、Riak、Voldemort の直接の祖先であり、DynamoDB の名の由来です――リーダーレスで結果整合的な設計パターンが、2007年の一本の論文から一世代のシステムのデータ層へと伝播したのです。³

クラウドネイティブなアーキテクチャと DevOps 文化。 「作った者が運用する」は現代の DevOps の創設的発想の一つとなりました――フルサービスの所有、オンコールの開発者、そして開発／運用の壁の解消は、ヴォゲルスが2006年に語ったモデルに直接たどれます。⁵

一世代のクラウドアーキテクトたち。 AWS の設計原理と彼の持続的な伝道を通じて、「故障を前提に設計する」「影響範囲を最小化する」「サービスを介して疎結合にする」は、エンジニアがクラウド上で信頼性あるシステムを構築することを推論するのに用いるデフォルトの語彙となりました。⁶

貫く一本の線

ヴォゲルスはこのシリーズの運用規模の要石です――分散システムの理論をとり、それを地球一つ分のマシンの上で走らせた人物です。レスリー・ランポートは分散システムにその基礎を与えました。時間、順序、合意をいかに正確に定義するか、そして参加者が故障したり恣意的にふるまったりするときシステムをいかに正しく保つか。ヴォゲルスは、その基礎がブラックフライデーのショッピングカートに奉仕せねばならなくなったとき、どう見えるかです――整合性と故障についての同じ問いを、ホワイトボードの上ではなく、実際の負荷のもと、可用性を保つことに本物の収益がかかった状況で答えたのです。⁴ そしてラディア・パールマンは、故障の場合を設計の中心として扱い、人手を介さず自らを治すネットワークを築きました。ヴォゲルスはまさにその直感の上にサービスを築きました。スタックを一段上がったところで――複製し、疎結合にし、影響範囲を封じ込め、そしてシステムが自ら収束するのに任せる。ランポートが正しさを定義し、それが故障を生き延びることを証明せよと言い、パールマンが自らを治すように作れと言うところで、ヴォゲルスはこう言います。あらゆるものは常に壊れる、だから防ごうとするのをやめよ――故障を真っ直ぐ貫いてシステムが可用性を保つように設計し、それを運用する作り手にあらゆる亀裂を感じさせよ。（シリーズの架け橋）

ここから受け取るもの

ヴォゲルスから私が手放さずにいる教訓は、故障を例外ではなく通常の場合として扱うことです。私の直感は、多くの作り手と同じく、呼び出しが成功し、依存先が応答し、ディスクがそこにある経路を書き――そして動いたら try/catch を後付けする、というものです。「あらゆるものは常に壊れる」はそれへの叱責です。実際のどんな規模でも、故障は私のシステムに起こる稀な出来事ではなく、私のシステムがその中で生きている恒常的な条件なのです。だから今、何かを作るとき――同期ジョブ、API クライアント、キューの消費者――私は「何が死に、それが死んだとき残りは奉仕を続けるか」から始めようとします。最後にそこへたどり着くのではなく。「動く」の正直な版とは、緑のデモではありません。リクエストの最中に依存先を殺し、システムが倒れるのではなく優雅に劣化するのを見ることです。ハッピーパスしか生き延びないシステムとは、私がまだ設計し終えていないシステムなのです。

二つ目の教訓は、可用性と整合性は私が意図して行うトレードオフだということです。両方が欲しくなるのは誘惑です――すべての読み取りがすべての書き込みを見て、かつシステムが決してノーと言わない――そして単一マシンならそれを持てます。何かを複製した瞬間、その快適さは消え、ヴォゲルスの規律は、習慣からあらゆる場所で最強の保証をデフォルトにするのではなく、作業負荷ごとに意図して側を選ぶことです。私が作るものの大半は、読み取りが最新の書き込みを即座に反映する必要はありません――顧客を決して拒まないことが必要なのです。結果整合性は、私にとってそれを恐ろしい妥協から精密な道具へと組み替えました。読み手がどれだけ古さに耐えられるかを正確に名指し、その余裕で可用性を買い、機能が決して必要としなかった保証の対価を払うのをやめる。技能とは、常に最強の約束に手を伸ばすことではありません――仕事が実際にどの約束を必要とするかを知ることなのです。

FAQ

「あらゆるものは常に壊れる」とはどういう意味ですか？

それは規模についての苦労して得た教訓を、ワーナー・ヴォゲルスが圧縮したものです。十分な数のマシンを運用すると、コンポーネントの故障は稀な例外であることをやめ、恒常的で統計的に避けられない条件となります。⁶ 1台のサーバーでは無視できるほど稀な故障モードが、大きな群れのどこかで絶え間なく起こるのです。実践的な帰結は、通常のエンジニアリングを反転させたものです。故障を防ごうとするのではなく、すべてのディスク、サーバー、回線、依存先は必ず壊れると想定し、故障を貫いて可用性を保ち続けるシステムを設計します――冗長化、疎結合、そして封じ込められた影響範囲を介して――どの一つの障害も乗り越えられ、理想的には見えないものになるように。¹⁶

Dynamo 論文とは何ですか？

「Dynamo: Amazon’s Highly Available Key-value Store」は2007年の SOSP 論文で、ヴォゲルスが共著し、ショッピングカートのようなサービスを故障やネットワーク分断の最中でも書き込み可能に保つために Amazon が構築したストレージシステムを記述しています。²³ それは、分割のためのコンシステントハッシュ法、並行する書き込みを追うためのベクタークロック、故障下で可用性を保つための緩やかなクォーラムとヒンテッドハンドオフ、修復のための Merkle 木によるアンチエントロピー、そして分散的なメンバーシップ管理のためのゴシップを組み合わせました――そのすべてが、常に書き込みを受け入れ後で調停するために奉仕します。Amazon はコードを公開しませんでしたが、論文は NoSQL ムーブメントの基礎となり、Cassandra、Riak、Voldemort、そして Amazon DynamoDB に直接の影響を与えました。³

結果整合性とは何ですか？

結果整合性は、ヴォゲルスが提唱しエッセイ「Eventually Consistent」で定義した、緩和された整合性モデルです。「そのオブジェクトに新たな更新が加えられなければ、最終的にすべてのアクセスが最後に更新された値を返す」というものです。⁴ 複製されたシステムでは、書き込みは一部のレプリカに他より先に到達しうるので、短い窓のあいだ異なるレプリカが異なる答えを返しうる――けれども、どれ一つとして要求を拒みません。システムは可用性を保ち、すべてのレプリカが合意するまでブロックするのではなく、背後で収束します。それは CAP のトレードオフの可用性側です。ネットワークが分断されたとき、システムは整合的（全員が合意するまで応答を拒む）か可用的（手元にあるもので応答し後で調停する）でありえ、結果整合性は可用的を選ぶのです。⁴⁷

「作った者が運用する」とはどういう意味ですか？

「作った者が運用する（you build it, you run it）」は、2006年の ACM Queue の対談でヴォゲルスが語った、Amazon のフルサービス所有のモデルの描写です。サービスを構築するチームが「そのサービスに完全な責任を負う――機能のスコープを定めることから、それを設計し、構築し、運用することまで。」⁵ 開発と運用のあいだに壁はありません――コードを書いたエンジニアが、そのポケベルを携えるのです。ヴォゲルスはこれが「開発者を自らのソフトウェアの日々の運用との接点へと連れて行き」「顧客との日々の接点へと連れて行く」と論じ、そこから生まれるフィードバックループこそが品質を駆動するのだとしました。⁵ この発想は、現代の DevOps 文化の創設原理の一つとなりました。

出典