勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

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

以前から気になっていた英語技術書の「Release It! 2nd Edition」を重い腰を上げてGoogle翻訳を活用しながら細々と読む話の第一弾。なお今回5章まで読んでいるが、キモとなる安全性のパターンについてはkawasimaさんの以下のQiita記事のほうがだいぶ詳しいのでオススメ。英語技術書をGoogle翻訳で読む方法は以前に書いたこちらの記事を参照。

Release It!は、パターンが分かりやすく書いてあるだけでなく、現実世界でおきた事例に照らし合わせて、パターン・アンチパターンが出てくるので、読み物としても非常に面白いのでオススメです。

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

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

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


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

序文

ワクワクが止まらない。

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

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

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

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

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

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

前編はこちら

Building Microservices 7章以降の感想

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

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

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

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

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

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

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

類似のもので

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

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

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

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

設計アプローチとしては、マイクロサービスはまだかなり若いので、注目すべき経験がいくつかありますが、今後数年間でそれらを大規模に扱う際により有用なパターンが得られると確信しています。それにもかかわらず、この章では、マイクロサービスへの道のりを拡大できるようにするためのいくつかの手順を概説しました。

私がここで扱ったことに加えて、私はMichael Nygardの素晴らしい本、Release It!をお勧めします。。その中で彼はシステム障害とそれにうまく対処するのを助けるためのいくつかのパターンについての物語のコレクションを共有しています。この本は読む価値があります(実際、大規模にシステムを構築している人にとっては必須の読み物と見なすべきだと私は言えるでしょう)。

探索は続く

そういえば、今日たまたま聞いていた、EM.FM ep23でちょうど、マイクロサービスとか犠牲的アーキテクチャの話が聞こえてきてびっくりした。

犠牲的アーキテクチャとマイクロサービスは相性がいい。このあたりも深堀していきたい今日この頃。

テーマ的には、次は プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

を読もうかと思っていたけど、を先に読んだほうがいいのかなぁ・・・

2019年上半期に読んだ本まとめ

2019年1月~6月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。

2019年上半期に読んだ本

2019年1月~6月に最後まで読み終わった本はこんな感じ。
https://www.instagram.com/p/BsDQJz7AUo3/https://www.instagram.com/p/BsP5P5uAK2f/https://www.instagram.com/p/Bsg01AKgxXn/https://www.instagram.com/p/Bsg_YnUgg6B/
https://www.instagram.com/p/Bsy_Z6NAtip/https://www.instagram.com/p/BszM4fTgh5R/https://www.instagram.com/p/BtFEYrEg0Ki/https://www.instagram.com/p/BtQpEowAhg8/
https://www.instagram.com/p/BtTChNpgr3k/https://www.instagram.com/p/BtihHa4gICa/https://www.instagram.com/p/Btii4T8g-VK/https://www.instagram.com/p/Bt5_6aZgWHG/
https://www.instagram.com/p/BuPVTfoA6ak/https://www.instagram.com/p/BuWOdV3AhZY/https://www.instagram.com/p/BuY9DFwgqdL/https://www.instagram.com/p/Buh4DrXAjz3/
https://www.instagram.com/p/Buz2mQuA7bM/https://www.instagram.com/p/Bu0lVZtgA-r/https://www.instagram.com/p/Bu6N3AAAvLE/https://www.instagram.com/p/BvP4z07gTs_/
https://www.instagram.com/p/BvQ01b4gkNn/https://www.instagram.com/p/Bvts5CaAteC/https://www.instagram.com/p/Bv9JOqtg_U9/https://www.instagram.com/p/BwMlVy2gCDw/
https://www.instagram.com/p/BwOo1OOgmna/https://www.instagram.com/p/BwdXoxWgXY7/https://www.instagram.com/p/BwiMrnLA6tm/https://www.instagram.com/p/BwzM4npgx7b/
https://www.instagram.com/p/Bw26sGCgN2j/https://www.instagram.com/p/Bw70lN4gg4y/https://www.instagram.com/p/Bw-bRtXgy5q/https://www.instagram.com/p/Bw-smOMgWnI/
https://www.instagram.com/p/BxCeNEagVp3/https://www.instagram.com/p/BxLZStwAZmU/https://www.instagram.com/p/Bxe2cMcnNpa/https://www.instagram.com/p/BxhYDu4nViH/
https://www.instagram.com/p/BxkWtCgnXpK/https://www.instagram.com/p/BxyJFgkgo1u/https://www.instagram.com/p/Bx2QErHgFpW/https://www.instagram.com/p/Bx3Px0Wnk2m/
https://www.instagram.com/p/ByQ7GlyAEDv/https://www.instagram.com/p/Byekt-YA-tJ/https://www.instagram.com/p/By7rcs4AAyd/https://www.instagram.com/p/By_9HyMgwXi/
https://www.instagram.com/p/BzIum8egIjc/https://www.instagram.com/p/BzJk2xyA1-s/https://www.instagram.com/p/BzSeNX7APyW/https://www.instagram.com/p/BzUArrEApgO/

  1. 女の子は本当にピンクが好きなのか (ele-king books)
  2. アンダー・ザ・ドーム 上
  3. アンダー・ザ・ドーム 下
  4. アジャイルエンタープライズ
  5. 知的生活の設計―――「10年後の自分」を支える83の戦略
  6. 理系あるある
  7. 森の探偵―無人カメラがとらえた日本の自然
  8. 物語論 (講談社現代新書)
  9. シルトの梯子 (ハヤカワ文庫SF)
  10. 自分の仕事をつくる (ちくま文庫)
  11. 興奮
  12. Hit Refresh(ヒット リフレッシュ)
  13. 代替医療解剖(新潮文庫)
  14. SOSの猿 (中公文庫)
  15. Complex Enterprise Architecture: A New Adaptive Systems Approach (English Edition)
  16. NO HARD WORK! 無駄ゼロで結果を出すぼくらの働き方 (早川書房)
  17. なるほどデザイン
  18. 残酷すぎる成功法則
  19. FACTFULNESS(ファクトフルネス)10の思い込みを乗り越え、データを基に世界を正しく見る習慣
  20. ヴィジョンズ
  21. NEXT GENERATION BANK 次世代銀行は世界をこう変える (blkswn paper vol. 1)
  22. 地下鉄道 (早川書房)
  23. ランドスケープと夏の定理 (創元日本SF叢書)
  24. バッタを倒しにアフリカへ (光文社新書)
  25. みみずくは黄昏に飛びたつ―川上未映子訊く/村上春樹語る―
  26. Effective DevOps ―4本柱による持続可能な組織文化の育て方
  27. 石の血脈 (祥伝社文庫)
  28. WIRED(ワイアード)VOL.32
  29. [映]アムリタ (メディアワークス文庫)
  30. 小説「映画 ドラえもん のび太の月面探査記」
  31. もうすぐ絶滅するという開かれたウェブについて 続・情報共有の未来 - 達人出版会
  32. トップアスリートが実践 人生が変わる最高の呼吸法
  33. 自然観察12カ月―昆虫・植物・鳥 (岩波ジュニア新書 71)
  34. サピエンス異変
  35. 小説禁止令に賛同する (集英社文芸単行本)
  36. 業務デザインの発想法?「仕組み」と「仕掛け」で最高のオペレーションを創る
  37. プラットフォームの経済学 機械は人と企業の未来をどう変える?
  38. 春にして君を離れ (クリスティー文庫)
  39. 竜のグリオールに絵を描いた男 (竹書房文庫)
  40. どこでも誰とでも働ける――12の会社で学んだ“これから”の仕事と転職のルール
  41. アルテミス 上 (ハヤカワ文庫SF)
  42. アルテミス 下 (ハヤカワ文庫SF)
  43. When 完璧なタイミングを科学する
  44. Learn Better ― 頭の使い方が変わり、学びが深まる6つのステップ
  45. 反脆弱性[上]――不確実な世界を生き延びる唯一の考え方
  46. 反脆弱性[下]――不確実な世界を生き延びる唯一の考え方
  47. レダ 1 (ハヤカワ文庫JA)
  48. レダ 2 (ハヤカワ文庫JA)
  49. レダ 3 (ハヤカワ文庫JA)
  50. ハロー・ワールド
  51. ゴーストマン 時限紙幣 (文春文庫)
  52. 教養は児童書で学べ (光文社新書)

オススメ文芸書編

最近、古典海外ミステリの未読をブックオフで安く買って読むのがブームだったりする。というわけで超古典だけれども以下は最高だった。読まずに死ねない感じ。「競馬シリーズ」とあるが、私のように競馬に興味が無くても問題ない。

興奮

興奮

また、古典ではないがハードボイルドサスペンス小説としては評価の高い以下も素晴らしかった。

ゴーストマン 時限紙幣 (文春文庫)

ゴーストマン 時限紙幣 (文春文庫)

オススメビジネス書編

FACTFULNESS(ファクトフルネス)10の思い込みを乗り越え、データを基に世界を正しく見る習慣

FACTFULNESS(ファクトフルネス)10の思い込みを乗り越え、データを基に世界を正しく見る習慣

言うまでも無く、圧倒的にオススメである。基本的には電子書籍を買う主義なのだけれども、家族で共有したかったので紙書籍を買うくらい、素晴らしかった。読むことで思考が変わるレベルのインパクトがある。

また、ここまでのインパクトは無かったけれども有用度が高いのは以下の2冊。どちらもオススメ。

残酷すぎる成功法則

残酷すぎる成功法則

Learn Better ― 頭の使い方が変わり、学びが深まる6つのステップ

Learn Better ― 頭の使い方が変わり、学びが深まる6つのステップ

オススメ技術書編

正確には技術書ではないのだけれども、マイクロソフトCEOが書いたこの本は技術者も読むべきだと感じている。

Hit Refresh(ヒット リフレッシュ)

Hit Refresh(ヒット リフレッシュ)

昨今のMicrosoftの戦略、思考、これからを考えるという意味でオススメしたい。

この半期の振り返り

最近の読書は割と惰性感があって、もうちょっと意識的に(もしくは自由に!)本を読みたい気がするのだけれども、この課題感をうまく消化できていない。一方でKindleセールだったり、酔っ払って勢い余って電子積読はどんどん増えるし、物理積読もたくさん溜まっていて困ったものである。

ところで最近ついに、老眼鏡というものにも手を出してしまった。

最近、夜の読書がツラくってな・・・超見えるようになって、びっくりした。

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

未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画(ざっくり)の第4回。今回は少し前に発売されたオライリーの「マイクロサービスアーキテクチャ」を2回に分けて読むことにしている。というわけで第6章まで読んだ感想など。

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

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

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

Building Microservices

さて、今回対象の書籍「マイクロサービスアーキテクチャ」だが、原題は「Building Microservices」である。著者のSam NewmanはThoughtWorksのエンジニアのようだ。
おそらく本書が初の著書で、続編としてEBookとして「What are microservices?」という短いテキストが公開されている。現在は続編として「Monolith to Microservices」という本を執筆しているようだ。

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

他に、著者は異なるが「プロダクションレディマイクロサービス」という本も良いという話を聞いたことがあり気になっている。これは翻訳書もある。

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

あとは最近パターン本もいろいろ出版されている模様。

いずれも未読だけれども、ちょっと眺めてみたいと思っている。
オライリーのSafariBooksOnlineに加入すればどれも定額サービス内で読めるので、いずれ読んでみたい。SafariBooksOnlineへの加入などについては以下の記事を参照。

なお、今回とりあげている「マイクロサービスアーキテクチャ」についても、原著の「Building Microservices」を英語と機械翻訳で読んでいる。

1章〜6章の感想

本書を読む以前の個人的な感覚として、『マイクロサービス「的」アーキテクチャ』は意図して作り出すというより、現代的な技術/プロダクトの活用や、様々な制約回避の結果生み出されるもの、という印象を持っていたのだけれども、ある部分ではその通りであるということが確認できた。
(実際、本書の3章、4章では一度モノシリックな設計をした上で段階的にマイクロサービス化していく方法が示されている。また設計手法はDDDの文脈で語られている)
一方でモノシリックなシステムのマイクロサービスへの移行は意外にも本書では多く語られていない印象がある(ストラングラーパターンの話とかは大変興味深いのだけれども)。このあたりは現在執筆中の続巻に期待ということだろうか。
ストラングラーパターンについて調べてみたら、以下の記事が興味深かった。

そして、構築した(もしくは構築する)マイクロサービスシステムの取り扱い方が5章〜9章のテーマのようだ。そして10章と11章が総論と今後に向けた問題提起だろうか。このあたりはまだ読んでいないので本記事としても後編で扱う予定。そして読み終わったら、前述の類書もいくつか読んでみたい。

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

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

Design It!

Design It! [Book]

  • 序文
    • この本にはアジャイルソフトウェア開発についての言及がない。それは本書がアジャイルアーキテクチャの優れた統合であるからだ(George Fairbanks/書籍「Just Enough Software Architecture」(2010)(邦訳なし)の著者)
  • 斜め読み
    • パート1とパート2はアーキテクチャ構築の方法論と著者のアイデアについて語られている。各章では仮想プロジェクト「Project Lionheart」ケーススタディが挿入されており理解を深めやすくなっている。
    • パート3はアーキテクトのツールボックスとして、様々なプラクティスに関する説明となっている。プラクティスは例えば「共感マップ」のような、アジャイル開発で用いられるようなものも多数含まれていて興味深い。

個人的な期待度:★★★(ぜひ通読したい!)

Software Architecture in Practice, Third Edition

Software Architecture in Practice, Third Edition [Book]

  • 第3版の序文
  • 斜め読み
    • パート1はアーキテクチャについての概要説明。パート2以降で、アーキテクチャと品質属性、開発ライフサイクル、ビジネスとの関係について論じている。最後のパート5では新興技術におけるアーキテクチャについて論じている。
    • 興味深いのは各章の最後に「ディスカッション」という項目があること。おそらく本書は教室で利用することを想定されており、各章について受講者が議論することを想定していると思われる(ディスカッションについては著者からの所見はなく、抽象的な問いが提示されている。例えば「ソフトウェアアーキテクチャーは、概念的なアナロジーとして建物のアーキテクチャーとよく比較されます。その類推の強みは何ですか?」のような感じ)。

個人的な期待度:★(うーん、この本はいったんパスかなぁ)

Software Architecture in Practice: Software Architect Practice_c3 (SEI Series in Software Engineering) (English Edition)

Software Architecture in Practice: Software Architect Practice_c3 (SEI Series in Software Engineering) (English Edition)

Software Architecture Patterns

Software Architecture Patterns [Book]

  • はじめに
    • アーキテクチャの決定なく実装を開始するのは一般的によくあることだが、これは往々にして「巨大な泥団子」のアンチパターンにはまる。
    • アーキテクトは、常にアーキテクチャについて判断決定し正当化する必要がある。本書は正当化するための情報を提供するものである。
  • 斜め読み
    • 本書は主に以下のアーキテクチャについて説明している。
      • 階層型
      • イベント駆動型
      • マイクロカーネル
      • マイクロサービス
      • Space-Based Architecture (日本語だと何ていうのがメジャーなんだろう)

個人的な期待度:★★(Building Microservice読み終わってから考える)

Designing Data-Intensive Applications

Designing Data-Intensive Applications [Book]

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

個人的な期待度:★★(訳書が出版されてから出てくるであろう書評を見てみたい)

Learning Chaos Engineering

Learning Chaos Engineering [Book]

  • 序文
    • 本書はカオスエンジニアリングの実践者向けの本である。Chaos Toolkitを使って Chaos Engineeringするための実用ガイドとなっている。
  • 斜め読み
    • 第1章はカオスエンジニアリングの概要、第2章からは具体的なChaos Toolkit、そして使い方の説明になっている。

Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation

Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation

個人的な期待度:★(ツール中心の説明なので、後回し)

Monolith to Microservices

Monolith to Microservices [Book]

  • 序文はまだない(これから追加されるかも)
  • 斜め読み
    • Building Microservicesの著者によるモノリスシステムのマイクロサービスへの移行、をテーマに書かれている本となっている。
    • 段階的な移行を前提として、移行するためのテクニックなどについて書かれている。

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

個人的な期待度:★(まだアーリーリリースなので、もう少し執筆が進んでから再確認したい)

Release It!, 2nd Edition

Release It!, 2nd Edition [Book]

  • 初版は邦訳されている。ずいぶん前の本だが非常に有用だった印象あり。
  • 序文
    • しびれる

この本では、現実世界の悪臭と悩みのために、ソフトウェア、特に分散システムを設計、設計、構築する方法を検討します。あなたはクレイジーで予測不可能なことをする非論理的なユーザの軍隊に備えるでしょう。あなたがリリースした瞬間からあなたのソフトウェアは攻撃を受けるでしょう。それは、フラッシュモブの台風や、しっかりと固定されていないIoTトースターオーブンによるDDoS攻撃の圧迫圧力に耐える必要があります。テストに失敗したソフトウェアを詳しく調べて、ソフトウェアが現実の世界との接触に耐えられるようにする方法を見つけます。

  • 斜め読み
    • 初版と二版の目次を並べてみてみると、「第1部 安定性」はだいたい同じ。アンチパターンとパターンは増えている感じ。
    • 第2部以降は全面改定といって良いくらい手が入っている。章構成が全然違う。単に順序が変わっただけではなさそうだ。

個人的な期待度:★★★(初版がとても良かったので、ぜひ読みたい)

Antifragile Systems and Teams

Antifragile Systems and Teams [Book]

  • 無料のEBookのようだ(Kindle版は無料になっている)
  • 薄い本のようなので、どこかで時間ができたらさっさと読むのがよさそう。

個人的な期待度:★★★(薄いので近日中に読み切る)

今回はここまで、来月またどこかで棚卸しをしよう

「業務デザインの発想法」を読んだ #デッドライン読書会

未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画(ざっくり)の第3回。今回は発売されたばかりの「業務デザインの発想法」を課題図書に選定。読んでみた。

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

わりと無かった業務デザインに関する本

業務デザインの発想法」はタイトル通り、業務デザイン(業務設計)に関する本である。思い返すと業務デザインに特化した良書というのはあまり心当たりがないので、そういう意味では貴重なノウハウが詰まった本という気がする。

業務デザイン関連というと、ビジネスプロセスモデリング関連の書籍をこれまでは割と参考にしていた。たとえば古典(かつ絶版本)だけれども

ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

上流工程UMLモデリング

上流工程UMLモデリング

あと
要求開発~価値ある要求を導き出すプロセスとモデリング

要求開発~価値ある要求を導き出すプロセスとモデリング

  • 作者: 山岸耕二,安井昌男,萩本順三,河野正幸,野田伊佐夫,平鍋健児,細川努,依田智夫,[要求開発アライアンス]
  • 出版社/メーカー: 日経BP
  • 発売日: 2006/03/02
  • メディア: 単行本
  • クリック: 19回
  • この商品を含むブログ (18件) を見る
あたりが良い本であった印象がある。ただ、これらの本はいずれもソフトウェア開発における開発対象の分析がメインの題材であり、いっぽうで業務デザインという意味では、

  • 新規業務をどのような組織で遂行するか(業務体制の検討)
  • 新規業務にどうやって移行するか(業務移行の検討)
  • 新規業務開始後の運営をどうするか(業務運営の検討)

あたりも必要になるが、いずれも割と王道的なやり方・正攻法はなく、毎回工夫しながら乗り越えてきた気がする。そもそもソフトウェア開発エンジニアとして「業務設計」そのものに関わる頻度というのも多くなかったので、なんとかなってきた。
いっぽうで、RPAのような新しい技術による業務見直しや改善、BPRの機会はどんどん増えていくと思われる。その際には、本書を教科書のように使って効率的に業務設計ができるようになるだろう。

本書のカバー範囲と感想など

開発系ITエンジニアの視点で読みながらいくつか感想などを列挙してみた。

  • 第1章 「何を」「どのように」提供するか決める ~業務設計/システム設計
    • ITシステム開発の文脈で言えば、業務要件定義に分類されるタスク。
    • ちょっと気になったのは、コンプライアンスやライセンス関連の記載がほとんどないところ。いつも重要になるわけではないのだけれども、設計した業務が法制度上問題ないかとか、商標や特許侵害していないかといった観点はあるような気がする。まあ、対象業務の規模や内容によるけれども。
    • 運用組織設計やリソース計画は(エンジニアとしては)割とお客様に担当いただく事が多いのだけれども、内容によっては(例えば新規業務部署を設立するとか)なかなか確定できないので、制約を整理して未決のまま設計をしたりすることもある。プロジェクトマネジメントの話だけれども、リスク管理が重要なエリアだと思う。
  • 第2章 業務のおはようからおやすみまでを想定する ~ライフサイクルマネジメント
    • ITシステム開発の文脈で言えば、保守運用設計などと呼んだりするタスク。
    • 割と検討を後回しにしがちで、あとで死ぬやつ。
  • 第4章 あたりまえの業務を,あたりまえに提供できるようにする ~オペレーションマネジメント
    • 戻って第2章と一緒に、保守運用設計に含めて考える事が多い気がする。もしくは、いったん実施した保守運用設計をベースに運用初年度の具体的な計画を立てる時に考えるようなイメージ。
  • 第5章 業務の価値を高める ~付加価値向上
  • 第6章 人と組織を継続的に成長させる ~環境セットアップ/ブランドマネジメント
    • 組織設計といったカテゴリの内容。残念ながら、SIerのエンジニア目線だとちょっと縁遠いというか、ここまで踏み込むことはあまり無い印象。

ちょっと残念だったところ

本書の一番良い点は、割と広範囲に業務デザイン周辺のテーマを総ざらいしている点なのだけれども、一方で個々の検討事項の分析の方法やアウトプットの定義までは踏み込んでいないところはちょっと残念。
例えば、業務設計の成果物やドキュメントはどのように定義すべきか(1-8章でラインナッップまでは提示されている)などである。
もしかすると、このあたりを補完する続編の構想があるのかもしれない(最近よくあるビジネス小説書形式とか)。

あと、私はKindle版で本書を読んだのだけれども巻末の索引が単なる用語の羅列になっており無リンクなのは、意図したものなのだろうか疑問である。可能であればアップデートで訂正いただきたいものだ。

Tail Latencyに関する論文読み

Misreading ChatのPodcastでTail Latencyに関する論文の紹介がされていて非常に興味深かったので、自分でも紹介されている論文を読んでみたという話。Misreading Chat Podcastのほうが的確な要約になっているので興味があればまず視聴するのがおすすめ。

Turtle

The Tail at Scale

米国計算機学会の機関紙Communications of the ACMの Feb/2013に掲載された記事。

要点

  • 大規模で複雑な分散システムでは、稀なパフォーマンスの低下が全体のパフォーマンス低下に繋がる事がある。
  • 大規模システムではレイテンシ低下の原因を完全に除去することは難しい。
  • 障害許容(フォールトトレラント)設計と同様に、テールレイテンシー許容設計をすることで、全体のパフォーマンス低下を対策することができる。

テールレイテンシーのよくある原因

  • マシン上の共有リソース(CPUコア、キャッシュ、メモリ、ネットワーク)
  • バックグラウンドデーモン
  • グローバルリソース(ネットワークスイッチや共有ファイルシステム)
  • メンテナンスのバックグラウンドアクティビティ(分散ファイルシステムでのデータ再構築、定期的なログ圧縮、ガベージコレクション)
  • 中間サーバやネットワークスイッチにおけるキューイング
  • ハードウェアによる制限(パワーリミット、電源管理、SSDガベージコレクション等)

並列処理によってテールレイテンシーの問題は増幅される

  • ユーザ要求を100台、1000台といった規模で分散処理する場合、1%, 0.1%の処理遅延が全体のパフォーマンスを悪化させる。

対策

  • Hedged requests。同じ要求を複数のレプリカに連携、最速の応答を採用する。その後未処理の要求は取消す。
  • Tied-Request。Hedged requestsで発生する無駄な処理を減らすためにキューに入れて処理をする。
  • Micro-partitions。細分化する。
  • Selective replication。 負荷の高い処理を優先的にレプリケーションする。
  • Latency-induced probation。遅いマシンを隔離する。
  • 最良の結果を返すのではなく、十分に良い結果で応答する。
  • カナリア要求。いくつかの要求の応答時間が短いことを確認してから、残処理を実施する。

Tales of the Tail: Hardware, OS, and Application-level Sources of Tail Latency

要点

  • マルチコアマシンで実行されているハイスループットサーバーで、ハードウェア、OS、およびアプリケーションレベルでテールレイテンシが悪化する原因を探る。
  • 予め作成した処理時間予想モデルに対して、Linuxサーバ(null RPCサービス、Memcached、およびNginx)で実測した上で検知されたテールレイテンシの原因を調査する。
  • テールレイテンシの主要な原因は以下の通り
    • バックグラウンドプロセスからの干渉
    • 不適切なスケジューリング
    • 割り込みルーティング
    • CPUの省電力機能
    • NUMAの影響
  • これらの要因を排除するとテールレイテンシの改善が図れる
  • スループット、エネルギー、テールレイテンシの間にトレードオフがある

テールレイテンシーの原因

原因 理想値との乖離の理由 対策例 関係するトレードオフ
バックグラウンドプロセス 干渉によるスケジュール遅延 優先順位をRTにするか、専用コアに割当 RT化は他タスクの割当を阻害する可能性。専用コアはタスクアイドル時にシステム利用率を下げる可能性がある
Non-FIFO Scheduling スレッドが順序どおりにスケジュールされていない RTなどのFIFOスケジューラを使う スケジューラの変更は全体の優先順位に影響する
並列アーキテクチャ TCP接続を静的に分解するとワーカー別にキューが生成される UDPイベント駆動型、またはスレッド毎のTCP接続アーキテクチャに変更する UDP化は信頼性低下、スレッド毎のTCP接続はスループット低下となる
割込処理 コンテキストスイッチと、FIFO順序喪失 割込処理専用のコアを持つ 割込用コアの稼働率が低いとスループットが低下する可能性がある
NUMA Effects NUMAノード間のメモリアクセスとキャッシュコヒーレンシプロトコルによる処理時間の増加 NUMAノードごとにプロセスを実行 複数キューによるレイテンシの発生、インスタンス間の負荷分散の問題が発生する可能性がある
Power Saving CPUアイドル状態からの復帰時間 CPUの低電力制御をOFFにする 電力使用量の増加

ここまで読んでちょっと調べていて気づいたんだけど、論文ではなくてプレゼンテーションスライドも公開されているようだ。

こっちを見たほうが断然わかりやすい印象。

もうちょっと関連論文を見てみようかと思い始めたところ。