2019-10-22

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)

作者: Michael T. Nygard
出版社/メーカー: Pragmatic Bookshelf
発売日: 2018/02/21
メディア: Kindle版
この商品を含むブログを見る

前回記事はこちら。

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章以降

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

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

2019-09-18

気になる洋書技術書をとりあえず斜め読み 2019/9

Professional Engineer safaribooksonline book

読んでみたい本が多すぎる。が、よく考えてみたら米oreillyのサービスに加入しているので何冊読んでも追加でお金はかからない（定額読み放題）。というわけで、目ぼしい未読の洋書技術書について、まず冒頭だけざっと読んでみた。
今回目をつけているのは以下。

More Fearless Change: Strategies for Making Your Ideas Happen

More Fearless Change: Strategies for Making Your Ideas Happen (English Edition)

作者: Mary Lynn Manns,Linda Rising
出版社/メーカー: Addison-Wesley Professional
発売日: 2015/02/20
メディア: Kindle版
この商品を含むブログを見る

訳書が出ている前作「Fearless Change」が非常に良かったので興味を持ったもの。
以下のページでは増補改訂版と紹介されていたのだけれども、SNSでつぶやいたら翻訳者の川口さんから「別本の扱いです」とのコメントが。

今回の特別ワークショップでは、今月末に出版される『More Fearless Change』のパターンを用いたワークショップを行います。この本は、とても有名な『Fearless Change』の改訂増補版です。

井庭崇のConcept Walk | Mary Lynn Mannsさんと「Fearless Change Workshop」を開催します

というわけで、ざっくり目次比較もしてみたのだけれども、確かに別本のようだ。ストーリーというか、パターンの使い方の解説部分は減って、追加のパターン＋既存のパターンに関する説明が主となっている。

Fearless Change 比較 - Google スプレッドシート

冒頭を斜め読みしてみたけれども、前作出版後の10年の議論などから発見されたパターンについて書かれているっぽい。
ただ、この本はGoogle翻訳だと非常に読み難い（おそらく相性の問題）ので、これ以上読み込むのは見送り。組織変革などの悩みに直面したら、トライしてみるかもしれない。

個人的な期待度：★（悩んだ時に手にとるかも）

The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done

The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done (English Edition)

作者: Stephen Denning
出版社/メーカー: AMACOM
発売日: 2018/02/08
メディア: Kindle版
この商品を含むブログを見る

この記事を書いた人が書いた本。

The Five Biggest Challenges Facing Agile

この本の中心テーマは、企業が組織や組織化の方法を根本的に改革し、新しい管理パラダイムを取り入れなければならないというものです。

新しい管理パラダイムは、目的地ではなく旅です。それは、技術革新を決して終わることのない関係の両方の組織が顧客のために生成し、特定の技術革新の面でと経営そのものの実施に着実に改善。企業は、「私たちは今アジャイル」であるため、リラックスできる安定した状態に「到達」することはありません。新しいパラダイムを採用するには、継続的なコミットメントと経営陣のリーダーシップが必要です。
この本は、それぞれの旅のさまざまな段階にある企業のスナップショットを提供します。それらが現在の場所に到達したことは、将来の成功を保証するものではありません。これらの企業は、新しい目標、原則、価値観を受け入れ、継続的なイノベーションで顧客を喜ばせ続けた場合にのみ繁栄し続けます。

というわけで、本書は経営パラダイムとしてアジャイルを取り組む方法に関する話のようだ。目次を見ていると様々な企業の事例分析も含まれている模様。技術書というよりビジネス書だけど、けっこう面白そう。

個人的な期待度：★★★（ぜひ通読したい！）

Clean Agile: Back to Basics (Robert C. Martin Series)

作者: Robert C. Martin
出版社/メーカー: Prentice Hall
発売日: 2019/10/24
メディア: ペーパーバック
この商品を含むブログを見る

最近読んだ「Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)」の著者の続刊。

この本は研究成果ではありません。私は熱心な文献レビューを行っていません。あなたが読んでいるのは、アジャイルとの20年にわたる関わりについての私の個人的な記憶、観察、意見です。これ以上でもそれ以下でもありません。

この本は、プログラマーと非プログラマーを対象としています。技術的ではありません。コードはありません。プログラミング、テスト、および管理の深い技術的な詳細に触れることなく、アジャイルソフトウェア開発の本来の意図の概要を提供することを目的としています。

技術エッセイ好きとしては、かなり興味をそそられる内容である。

私はこの序文を2019年の最初の日に書いています。そのリブートからほぼ20年が経ちました。どうして？なぜなら、アジャイルのシンプルで小さなメッセージは、この数年間で混乱してきたからです。リーン、カンバン、LeSS、SAFe、モダン、スキルド、その他多くの概念が混在しています。これらの他のアイデアは悪くありませんが、元のアジャイルメッセージではありません。

ここでいうリブートとは、90年代のソフトウェア開発の混乱の後の業界の再起動とアジャイルソフトウェア開発宣言のことである。そして、もしかすると大規模アジャイルに関する警鐘も書かれているような気がする。非常に気になる。

個人的な期待度：★★★（ぜひ通読したい！）

The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition (2nd Edition)

作者: David Thomas,Andrew Hunt
出版社/メーカー: Addison-Wesley Professional
発売日: 2019/09/23
メディア: ハードカバー
この商品を含むブログを見る

名著の誉れが高い「新装版達人プログラマー職人から名匠への道」の二版。昔読んだけど記憶の彼方なので、ちゃんと読み直したい。

20年前、新しいクライアントとの議論を短縮するために書いたメモを発展させることにより「達人プログラマ」は生まれた
20年が経過して、多くのソフトウェアは寿命が来て世代交代した。しかし、ソフトウェア開発の常識、実践とアプローチは変化していない
20周年版を出すにあたって、テクノロジー面の更新に加えて、20年の経験を踏まえた見直しを行った

その結果、この本はテセウスの船のようなものです。本のトピックのおよそ3分の1は真新しいものです。残りの大部分は、部分的または全体的に書き換えられています。私たちの意図は、物事をより明確にし、より関連性のあるものにし、できれば時代を超越したものにすることでした。

うーん、つまり全部読み直さないといけないということか。
興味深いけれども、自分の興味としては後回しかなぁ。若手エンジニアの皆さん、もしくは未読の方は読んだほうがよさそうだけれども。

個人的な期待度：★（きっと良い本だけれども、読み直す時間が無いので後回し）

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software (English Edition)

作者: David Scott Bernstein
出版社/メーカー: Pragmatic Bookshelf
発売日: 2016/03/08
メディア: Kindle版
この商品を含むブログを見る

訳書も出た。

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

作者: David Scott Bernstein,吉羽龍太郎,永瀬美穂,原田騎郎,有野雅士
出版社/メーカー: オライリージャパン
発売日: 2019/09/19
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

が、とりあえず定額読み放題の原著で内容をチェック。

ソフトウェア開発者と協力するマネージャーのために、この本は、9つの重要なプラクティスに投資することで、チームがより効率的に作業してレガシーコードに陥らないソフトウェアを提供する方法を示します。そして、それを行うには、単なる技術的なTo Doリスト以上のものが必要です。その理由を方法に追加する原則をしっかりと理解する必要があります。

というわけで、後半は具体的なプラクティスの説明になっている。9つのプラクティスは以下の通り。

プラクティス1　やり方より先に目的、理由、誰のためかを伝える
プラクティス2　小さなバッチで作る
プラクティス3　継続的に統合する
プラクティス4　協力しあう
プラクティス5　「CLEAN」コードを作る
プラクティス6　まずテストを書く
プラクティス7　テストでふるまいを明示する
プラクティス8　設計は最後に行う
プラクティス9　レガシーコードをリファクタリングする

一方で注目したいのは前半の総論的なレガシーコード論である。これは面白そうなのだけれども、原著で読むのは骨が折れるので訳書を買うべきな印象。SNSのタイムラインをみていても賞賛の声がよく見えるし、有用度が高そうなので訳書を買ってしまおうかなぁ。Kindleでセールになっていたら間違いなく購入するのだけれども、日本オライリーだとセールになることは無いのが残念。

個人的な期待度：★★★（有用度高そう。訳書購入を検討！）

ところで、前回チェックした本とその後の状況

前回も何冊かチェックしているのだけれども、

気になる洋書技術書をとりあえず斜め読み 2019/5 - 勘と経験と読経

現在はその中から１冊「Release It!: Design and Deploy Production-Ready Software (English Edition)」について、少しずつ読み進めている状況。途中経過は以前に書いた。Part.2は現在下書き中。

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

現在オンラインで本書を扱った読書会が進行中なので、参加しはじめている(#3のみだけど)。遅い時間スタートかつ自宅から参加できるので（社畜派でも）お勧め。

アーキ部 - connpass

時間が足りないのだよ。そして月末からはDQ11(Switch版)に着手する予定なので重ねてマズイ状況。

2019-09-16

Google Colaboratory で AtCorder生活

Professional Engineer

以前にScratchでAtCorderする方法を記事に書いた。

Scratch3.0でAtCorderに参加できるようになったのでいろいろやってみた - 勘と経験と読経

その後AtCorderの過去問をScratchで解きまくってみたのだけれども、実行時間制限が厳しい問題をクリアできなくなってきた。Scratchでは例えばソート関数などが提供されていないのでアルゴリズムを手組みせざるをえないのだけれども、高速なアルゴリズムを組むのはしんどい。
というわけでPythonに浮気した。しかし、ローカル開発環境を構築するのは面倒だ。そこで、まるっと使いやすいサービスを探していたところ、Google Colaboratoryがよかったというのが本記事の内容。

Google Colaboratoryとは

このあたりからどうぞ。GoogleがホストしているJupyterですね。

環境構築不要でPython入門！Google Colaboratoryの使い方を分かりやすく説明｜はやぶさの技術ノート

類似のオンライン実行環境としては、国内では某転職斡旋業者のサービスもあるようだが、私はなんとなく避けている。なんとなく。

Google ColaboratoryでAtCorder

基本的にはGoogle Colab上でコーディングとテストを実施して、完成したらAtCorderのフォームから提出するという流れ。
特に工夫をしないでも

Google Colab上で、テストデータをインプットとするコードを書く
サンプルデータで正解になるか確認する
問題が無さそうであれば、AtCorderに提出する用のI/Oを追加する
提出する

という流れでAtCorderに参加できるが、最後のI/Oの追加あたりが面倒だ。

そこで、以下のようなテンプレートコードを考えた。これであればColab上で開発完了したら、そのままAtCorderへも提出できる。

def main():
  if 'get_ipython' not in globals():  
    # 以下のコードはAtCorder提出時のみに実行される。問題の種類に応じてinputメソッドを準備する
    N = int(input())
    # AtCorderでよくある入力形式
    # A, B, C = input().split()
    # b = [int(i) for i in input().split()]  横持ち
    # S = [input() for _ in range(N)]  縦持ち／行数N
    # t = [0] * N  　　ti xi yi 縦持ち/行数N
    # x = [0] * N
    # y = [0] * N
    # for i in range(N):
    #   t[i], x[i], y[i] = map(int, input().split())
  else:
　# 以下のコードはColab上でのみ実行される。テスト用の入力データを書いておく
    N = 1

  # 以下にコード本体を書く
  print(N)

main()

例えば、AtCorderサンプル問題「practice_1」の回答は以下になる。

def main():
  if 'get_ipython' not in globals():  
    #以下のコードはAtCorder提出時のみに実行される。問題の種類に応じてinputメソッドを準備する
    a = int(input())
    b,c = map(int,input().split())
    s = input()
  else:
    #以下のコードはColab上でのみ実行される。テスト用の入力データを書いておく
    a,b,c = 1,2,3
    s = "test"
 
  # 以下にコード本体を書く
  print("{} {}".format(a+b+c, s))
  
main()

参考リンク

AtCoder Beginners Selection をPythonで解く - Szarny.io

プログラミングコンテストチャレンジブック [第2版]　?問題解決のアルゴリズム活用力とコーディングテクニックを鍛える?

作者: 秋葉拓哉,岩田陽一,北川宜稔
出版社/メーカー: マイナビ出版
発売日: 2012/01/28
メディア: Kindle版
この商品を含むブログを見る

プログラミングコンテスト攻略のためのアルゴリズムとデータ構造

作者: 渡部有隆
出版社/メーカー: マイナビ出版
発売日: 2015/01/30
メディア: Kindle版
この商品を含むブログを見る

2019-09-03

2012年のKnight Capitalのシステムトラブルについて調べた

Project Management Professional Engineer Postmortem

名前だけは知っていた有名なソフトウェアトラブルの事例。「巨大システム　失敗の本質―「組織の壊滅的失敗」を防ぐたった一つの方法」という本で詳しく語られていたのを見て興味が沸いて、いろいろ調べてみた。今は調べたことを、少し後悔している。

米ナイト・キャピタル・グループ、自動取引システムの障害で4億4千万ドルの損失 (2012年8月5日) - エキサイトニュース

巨大システム　失敗の本質―「組織の壊滅的失敗」を防ぐたった一つの方法

作者: クリス・クリアフィールド,アンドラーシュ・ティルシック
出版社/メーカー: 東洋経済新報社
発売日: 2018/11/30
メディア: Kindle版
この商品を含むブログを見る

トラブルの概要

2012年8月1日ニューヨークの証券会社であるKnight Capitalにおいて、コンピュータを使った自動売買トレーディングソフトウェアのインストールに絡む問題により「大量の誤注文」が発生。
損失額は4億4000万ドル

何が起こったのか

既存システムにはもともと「パワーペグ」と呼ばれる試験的な取引機能があった。この機能は結局本番稼動しなかったが、コードは削除されなかった。いわゆるデッドコード。
パワーペグ機能の廃止に伴い、取引モニタリング機能も廃止された（これによりトラブル後の原因調査が難しくなったようだ）。
取引所で新たな制度「個人投資家流動性プログラム（RLP）」が開始されることとなり、システムに対応機能を追加したが、その際の処理フラグは「パワーペグ」で過去に利用していたものと同一で設計された（合掌）

これらの一見無害な一つひとつのステップ――RLPの導入、パワーペグ機能の保持、パワーペグ取引の追跡不能、パワーペグフラグの再利用――が、金融メルトダウンのお膳立てをした。RLPプログラム開始の数日前、ナイトのIT社員が更新プログラムのインストールに取りかかった。問題がないことを確認するために、まず一部のサーバで試し、正しく作動するのを見届けてから、8台のサーバのすべてにRLP機能を組み込んだ。いや、そうしたつもりだったが、実際には1台だけ追加し忘れた。7台のサーバは修正ずみのソフトウェアを実行したが、8台目のサーバは、パワーペグコードが残る、古いバージョンのままだった。

巨大システム　失敗の本質―「組織の壊滅的失敗」を防ぐたった一つの方法

読むだけで寿命が縮むレベルだが、いろいろ調べてみるとさらにお腹の痛い事実が次々と・・・

The Rise and Fall of Knight Capital — Buy High, Sell Low. Rinse and Repeat.
コードのデプロイは手動であり、ダブルチェックはなかった。各サーバのコード不一致を警告するようなチェック機能も導入されていなかった
取引初日の稼動直前に「Power Peg disabled」というエラーがメッセージ通知されていたが、内容もあいまいであり、リアルタイムで対応する体制もなかった為に見過ごされていた
同社はインシデント対応フローが確立されておらず、問題発生時に大きな混乱に陥った
2010年のフラッシュクラッシュで追加されたサーキットブレーカー（価格変動を基準とした自動停止機構）条件には該当しなかったため、自動遮断はされなかった
トラブル発生直後、直近で修正されたコード（RLP対応）が原因であるという誤った（最悪の）判断があり、全サーバが1世代前の状態に切り戻された。これは、8台全台のサーバがパワーペグコードが残る、古いバージョンに戻されたということである（黙祷）
当然のことながら、全台でパワーペグ機能が稼動し、さらに大量の取引が実行された
その後エンジニアが原因を特定しシステムをシャットダウンした。ここまで（なんと）業務開始から28分である

いやぁ、勉強になるなぁ～

2019-08-20

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

Professional Engineer Software Architect book

以前から気になっていた英語技術書の「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!は、パターンが分かりやすく書いてあるだけでなく、現実世界でおきた事例に照らし合わせて、パターン・アンチパターンが出てくるので、読み物としても非常に面白いのでオススメです。

安定性のパターン大全 (とその実装) - Qiita

ちなみに 1st Editionは訳書が入手可能である。こちらはだいぶ前に読んではいるが、今回大幅に内容は書き直されているように見えている。だいぶん記憶が曖昧だけれども。

Release It！本番用ソフトウェア製品の設計とデプロイのために

作者: でびあんぐる,ＭｉｃｈａｅｌＴ．Ｎｙｇａｒｄ
出版社/メーカー: オーム社
発売日: 2018/03/23
メディア: Kindle版
この商品を含むブログを見る

Release It! 本番用ソフトウェア製品の設計とデプロイのために | Ohmsha

というわけで、ここからは本書を読みながらの読書メモ。

序文

ワクワクが止まらない。

この本では、現実世界の悪臭と悩みのために、ソフトウェア、特に分散システムを設計、設計、構築する方法を検討します。あなたはクレイジーで予測不可能なことをする非論理的なユーザの軍隊に備えるでしょう。あなたがリリースした瞬間からあなたのソフトウェアは攻撃を受けるでしょう。それは、フラッシュモブの台風や、しっかりと固定されていない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」に突入である。先は長いが、楽しめそう。

2019-07-03

「Building Microservices」7章以降も読んだ #デッドライン読書会

book Professional Engineer

未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画（ざっくり）の第5回。今回は少し前に発売されたオライリーの「マイクロサービスアーキテクチャ」を2回に分けて読むことにしている。というわけで第7章以降を読んだ感想。結論から言うと10章以降がすばらしい。

マイクロサービスアーキテクチャ

作者: Sam Newman,佐藤直生,木下哲也
出版社/メーカー: オライリージャパン
発売日: 2016/02/26
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

デッドライン読書会のルールは、以下参照

読書×締切ではじめる「デッドライン読書会」を始めました | 84zume Works

前編はこちら

「Building Microservices」6章までを読んだ #デッドライン読書会 - 勘と経験と読経

Building Microservices 7章以降の感想

10章まではマイクロサービス構築時の様々なテーマの課題（7章テスト、8章監視、9章セキュリティ)の話なのだけれども、当然のことながらマイクロサービス固有の話ばかりではなく、なかなか興味深かったけれども知っている話も多かった。まぁ本書(原著)は2015年の本なので、あたりまえなのかもしれないけれど。
10章以降はかなり興味深く、いろいろと関連資料も見ながら、なかなか楽しく読むことができた。

10章コンウェイの法則とシステム設計

コンウェイの法則、およびWindowsVistaの失敗については以前に本ブログで取り上げたこともある。

WBS類とコンウェイの法則、組織の枝振りは変化する - 勘と経験と読経

本書ではWindows Vistaの件に加えて、NetflixとAmazonの取組みについて触れられている。個別に事例を読んだことはある気がするが、改めて並べてみるとかなり興味深い。
また、コンウェイの法則の対策の一つとして提言されている「社内オープンソース」という考え方は、なかなか良い考え方のように見える。取込みを検討したい。
そして、逆コンウェイの法則。これは以前に平鍋さんのブログでも紹介されていたな・・・

逆コーンウェイ戦略とDevOps, Microservices, Agile | an Agile Way

11章大規模なマイクロサービス

本章は文字通り、大規模なマイクロサービス（というか、マイクロサービスを用いた大規模システム）の課題をまとめている。現在具体的に似たような悩みを抱えているからかもしれないが、すごく「あるある感」を感じながら読んでしまった。

冒頭で紹介されている「分散コンピューティングの誤謬」というのは有名な話のようだが、知らなかった。笑える。

Fallacies of distributed computing - Wikipedia

類似のもので

「分散システムとは、あなたが知らなかったコンピュータの障害が原因で、自分のコンピュータを使用できなくすることができるシステムです」レスリー・ランポート（コンピュータ科学者）

というのもあったが、類似の匂いを感じる。

また、偶然最近読み終わったタレブの「反脆弱性」の話も出てくる。アンチフラジャイルな組織については、2013年にACMで論文が公開されているようだ。NetflixのChaos Engineering関連。後でよむ。

The Antifragile Organization - ACM Queue

その後は各種の対応パターンがいろいろ掲載されているのだけれども、どうやらいくつかの対応はRelease It!: Design and Deploy Production-Ready Software (English Edition)に詳しく書かれているようだ。これも読まねば。

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

作者: Michael T. Nygard
出版社/メーカー: Pragmatic Bookshelf
発売日: 2018/02/21
メディア: Kindle版
この商品を含むブログを見る

設計アプローチとしては、マイクロサービスはまだかなり若いので、注目すべき経験がいくつかありますが、今後数年間でそれらを大規模に扱う際により有用なパターンが得られると確信しています。それにもかかわらず、この章では、マイクロサービスへの道のりを拡大できるようにするためのいくつかの手順を概説しました。
私がここで扱ったことに加えて、私はMichael Nygardの素晴らしい本、Release It！をお勧めします。。その中で彼はシステム障害とそれにうまく対処するのを助けるためのいくつかのパターンについての物語のコレクションを共有しています。この本は読む価値があります（実際、大規模にシステムを構築している人にとっては必須の読み物と見なすべきだと私は言えるでしょう）。