Release It! 2nd Editionを読んでいる(Part.2)

近著の技術書では名著と名高い(個人的な観測範囲)Release It! 2nd Editionであるが、残念ながら翻訳はされていない。Google翻訳を活用しながら、えっちらおっちら原著を読むブログ記事のPart.2。今回は6章〜11章を読んでいる（全部で17章ある）。

Release It!: Design and Deploy Production-Ready Software (English Edition)

前回記事はこちら。

• Release It! 2nd Editionを読んでいる(Part.1) - 勘と経験と読経

6章〜11章は「Part II. Design for Production」つまり本番運用のための設計に関する指針といった内容。6章がケーススタディで、これを踏まえて7章以降で設計要素について語られている。

6. Case Study: Phenomenal Cosmic Powers, Itty-Bitty Living Space

というわけで、またもや空恐ろしいケーススタディである。このケーススタディでは主人公の休暇中に破滅的なシナリオが時系列で進行するというもので、読んでいて心臓が止まるか毛が生える勢い。ECサイトがブラックフライデーに原因不明でダウンする事例である。

障害は避けられるものではないため、障害を前提とした設計をする必要があるという話で紹介されている「ROCプロジェクト」が興味深い。

Recovery-Oriented Computing（ROC）プロジェクトは、バークレーとスタンフォードの共同研究プロジェクトでした。プロジェクトの設立原則は次のとおりです。

• ハードウェアとソフトウェアの両方で、障害は避けられません。
• モデリングと分析が十分に完了することはありません。すべての故障モードの事前予測は不可能です。
• 人間の行動は、システム障害の主要な原因です。

彼らの研究は、システムの信頼性に関するこれまでの研究の多くに反しています。ほとんどの作業は障害の原因の除去に焦点を当てていますが、ROCは障害が必然的に発生することを受け入れています。これはこの本の主要なテーマです。彼らの調査の目的は、障害が発生した場合の生存性を改善することです。 ROCの概念は、2005年の時代を先取りしました。今では、マイクロサービス、コンテナー、および弾性スケーリングの世界では自然に見えます。

• The UC Berkeley/Stanford Recovery-Oriented Computing (ROC) Project

7章以降

（私の知る限り）本書独自の観点スタックで本番環境向けの構成設計に関して議論されている。

• Foundation
  • いわゆるインフラストラクチャー
• Instances
  • サービスの最小単位（呼び名はまちまち。ただし名称を統一しないと死ぬ）の管理について
    • Loose Lips Sink Ships: Precision in Language | the agile admin
• Interconnect
  • サービス間の相互接続に関する観点。DNSラウンドロビンから始まってサービスディスカバリーまで。
• Control Plane
  • コントロールプレーンって日本語だとどうなるんですかね。運用制御と監視など。コントロールプレーンが高度になるほど、実装と運用にかかるコストが増加する。バランスを取る必要がある。また、新しいオープンソースの運用ツールが次々と登場しており、慎重に選択しなければならないとか。
• Operations
  • システムの運用そのものについて。なお本書ではSecurityのみをトピックとして扱っているようだ。

次は「Part III. Deliver Your System」（12章〜15章）。これはさくっと読めそう。

なお本書には興味があるけど、ハードルが高いと感じられている人はアーキ部のオンライン読書会に参加すると良いだろう。

• アーキ部 - connpass