以前から気になっていた英語技術書の「Release It! 2nd Edition」を重い腰を上げてGoogle翻訳を活用しながら細々と読む話の第一弾。なお今回5章まで読んでいるが、キモとなる安全性のパターンについてはkawasimaさんの以下のQiita記事のほうがだいぶ詳しいのでオススメ。英語技術書をGoogle翻訳で読む方法は以前に書いたこちらの記事を参照。
Release It!: Design and Deploy Production-Ready Software (English Edition)
- 作者: Michael T. Nygard
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2018/02/21
- メディア: Kindle版
- この商品を含むブログを見る
Release It!は、パターンが分かりやすく書いてあるだけでなく、現実世界でおきた事例に照らし合わせて、パターン・アンチパターンが出てくるので、読み物としても非常に面白いのでオススメです。
ちなみに 1st Editionは訳書が入手可能である。こちらはだいぶ前に読んではいるが、今回大幅に内容は書き直されているように見えている。だいぶん記憶が曖昧だけれども。
Release It！ 本番用ソフトウェア製品の設計とデプロイのために
- 作者: でびあんぐる,ＭｉｃｈａｅｌＴ．Ｎｙｇａｒｄ
- 出版社/メーカー: オーム社
- 発売日: 2018/03/23
- メディア: Kindle版
- この商品を含むブログを見る
というわけで、ここからは本書を読みながらの読書メモ。
序文
ワクワクが止まらない。
この本では、現実世界の悪臭と悩みのために、ソフトウェア、特に分散システムを設計、設計、構築する方法を検討します。あなたはクレイジーで予測不可能なことをする非論理的なユーザの軍隊に備えるでしょう。あなたがリリースした瞬間からあなたのソフトウェアは攻撃を受けるでしょう。それは、フラッシュモブの台風や、しっかりと固定されていないIoTトースターオーブンによるDDoS攻撃の圧迫圧力に耐える必要があります。テストに失敗したソフトウェアを詳しく調べて、ソフトウェアが現実の世界との接触に耐えられるようにする方法を見つけます。
世の中には本当にイマジネーションの限界を超えたトラブルが存在するんですよ、ホント。
Chapter 1 Living in Production
本番にイキロ。
あまりにも多くの場合、プロジェクトチームは、本番環境での生活を目指すのではなく、品質保証（QA）部門のテストに合格することを目指しています。つまり、あなたの仕事の大部分はおそらくテストに合格することに集中しています。しかし、テスト - アジャイル、実用的、自動テストでさえ - 、ソフトウェアが現実の世界に向けて準備ができていることを証明するには十分ではありません。狂った実ユーザ、世界中に広がるトラフィック、そして今までに聞いたことがない国からのウイルスを作成する暴徒など、現実世界のストレスや緊張は、これまでテストしたいものをはるかに超えています。
狂った実ユーザ、かどうかはわからないけれども、パワーユーザーは常に侮れない！
Part I. Create Stability
2. Case Study: The Exception That Grounded an AirlineCase Study: The Exception That Grounded an Airline
お腹の痛くなるケーススタディ。
計画的なOracleデータベースのフェイルオーバーをトリガーとして、特殊な状況のみに発生するOracle JDBCドライバの例外を考慮していないコードが起因で関連するシステムが処理不能に。数時間の業務停止が発生。このバグは実質的に防御困難であり、バグが存在する前提で相互接続された関連システムに影響を伝播させない設計を行う必要があったというポストモーテム。痺れる。
3. Stabilize Your System
システムを安定化する基本戦略について。
- システムはインパルス（局所的な負荷の増大）とストレス（緩やかな負荷やデータの増加）にされされる。
- 処理の失敗がシステムに亀裂を生じさせ、これが大規模に伝播していく。
- クラックストッパーとショックアブソーバーを準備し、自己防衛によって、安全な障害モードを構成する必要がある。
まず、悪い知らせです。私たちは悟りの高原にたどり着く前に影の谷を通って移動しなければなりません。言い換えれば、それはあなたのシステムを殺すアンチパターンを見る時が来たということです。
殺さないで。
4. Stability Antipatterns
安定性を損なうアンチパターン集。おなじみのものも多い。
- 統合ポイント(Integration point)
- すべての統合ポイントは最終的に何らかの方法で失敗する。その失敗に備えて準備する必要がある
- 連鎖反応 (Chain reaction)
- 1台のサーバーがダウンすると残りのサーバーが危険にさらされる
- カスケード障害(Cascading Failures)
- 統合ポイントを基点として、カスケード障害によってクラックアクセラレートが起こる
- ユーザー (Users)
- 人間ユーザーは創造的破壊のコツを持っているw
- ブロックされたスレッド(Blocked Threads)
- リソースプールのデッドロック
- 自己拒否攻撃(Self-Denial Attacks)
- スケーリング効果(Scaling Effects)
- 1対1の通信環境(テスト環境等)では正常に稼動しても、1対多の本番環境スケールで稼動した場合に問題が引き起こされるパターン。ポイントツーポイント通信(接続の数が参加者の二乗に比例して増加)や共有リソースに留意した設計が必要
- 不均衡な容量 (Unbalanced Capacities)
- フロントエンドとバックエンド等が同等のキャパシティを持たない場合に、過負荷によって問題が発生する
- ドッグパイル(Dogpile)
- 何かしらの要因により瞬間的にシステムに対する負荷が高まる（たとえば停電後の一斉再起動）。
- フォース マルチプライアー(Force Multiplier)
- 運用自動化と手動運用の組み合わせや矛盾によって予期せぬトラブルが引き起こされる
- 遅延応答 (Slow response)
- 遅延応答によってカスケード障害がトリガーされる
- 無制限のデータ応答 (Unbounded Result Sets)
- 応答結果数を制限していない場合、予期せぬ大量データを返すクエリによって障害が発生する
5. Stability Patterns
安定性を確保するためのパターン集。
- タイムアウト (Timeouts)
- サーキットブレーカー (Circuit Breaker)
- 発生障害数や頻度に応じて遮断する
- リーキーバケット - Wikipedia
- タイムアウトと一緒に使う
- 遮断壁(Bulkheads)
- 予め影響を限定するためにリソースを分離しておく(粒度はスレッドからサーバ単位まである)
- 定常状態(Steady State)
- データやログファイルは自動的に削除し、人間の介入を不要にする
- できる限り本番環境から人間を遠ざる
- すばやく失敗する(Fail Fast)
- システムが操作失敗を予期できる場合、迅速に失敗させ処理自体を回避する
- クラッシュさせて(Let It Crash)
- 可能であれば、問題が発生した該当箇所を迅速にクラッシュさせ、再起動によって状態をクリーンに保つ
- ハンドシェイク(Handshaking)
- 有用な手法だが現在主流のアプリケーションプロトコル(HTTP)がサポートしていない
- テストハーネス(Test Harnesses)
- テストハーネスで障害を注入して安定性に関わるテストを行う
- ミドルウェアによる分離(Decoupling Middleware)
- 適切な分散ミドルウェアを選択して耐障害性を上げる
- 負荷制限(Shed Load)
- 想定外の負荷にさられれたときにガードできるようにしておく
- 流量制御(Create Back Pressure)
- 負荷増大を呼び出し側に伝達し、流量をコントロールする（遅くする）
- ガバナー(Govenor)
- 自動化機構が暴走しないように人が介入できるような意図的なスローダウン機構を用意する
パラノイアは優れたエンジニアリングです。
同意。
ここまで読んだのだけれども、非常に実用的（Pragmatic）な匂いに溢れる良書という印象。実践に裏打ちされたリアルな一言が多い（とにかく、Hellとかそういう表現を良くみる技術書だ）。
さて、次章からは「Part 2 Design for Production」に突入である。先は長いが、楽しめそう。
