勘と経験と読経

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

「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にする 電力使用量の増加

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

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

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

Effective DevOps 第Ⅴ章~第Ⅵ章を読んだ #デッドライン読書会

未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画(ざっくり)の第2回。
前回記事はこちら

ルールはこのあたり

というわけで、Effective DevOps ―4本柱による持続可能な組織文化の育て方の後半戦を読みきった感想也。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DevOpsは日本に定着するのか?

感想なのにのっけからこのような書出しになってしまうのだけれども、本書の後半の主要なメッセージは「DevOpsは文化である」だと理解している。そして文化である以上、この文化を広げていくためには知識やツールなどのノウハウだけでなく、

  • ストーリーの共有
  • カンファレンスやコミュニティ、ミートアップを通じた情報共有

などが重要である、とある。

これを読んで、ううむ、と唸ってしまった。
これは日本国内で定着するのに、時間がかかりそうだ。

思い返してみると、現在主流化しつつあるアジャイル開発も、最初は文化運動(しかも、ある種のカウンターカルチャー的なもの)だった。「アジャイルソフトウェア開発宣言」が発表されたのが2001年で、そこから実に18年が経過しているのである。しかも、アジャイルソフトウェア開発宣言そのものが広く行き渡った事によってアジャイル開発が拡散したのではなく、様々なツールと開発方法論が整備されて、やっと広がったのではなかったか。

DevOpsの考え方やアプローチは正しいと思うし、好みでもあるのだけれども、改めて「DevOpsは文化だ」と言い切ってしまうのは、理解は出来るが残念でもある。もしくはまだ黎明期であると考えるべきなのだろうか。

というのが、本書の後半を読んだ率直な感想である。少なくとも本書は気軽に初学者には進めにくいし、上司に提言する際に活用する本でも無い(スタートアップや小規模組織では別かもしれない)という印象である。

落ち穂拾い

後半(第Ⅴ章以降)で興味深かった話について

第V部 スケーリング

DevOps組織の構築と成長に関する論点が整理されている。
特に興味深いのは、英国のGovernment Digital Service(GDS)という組織および小売大手のTargetの事例である。
GDSの事例は首相官邸にいい感じのサマリー資料があったのであわせて紹介しておく。

TargetについてはRedHatでも記事が出ているようだ。

内容とは直接的に関係しないが、比喩表現として以下が面白かった。

  • ゾンビプロジェクトと、ヴァンパイアプロジェクト
    • 改善を阻害するプロジェクトの例。
  • たわごとの傘(shit umbrella)と、たわごとファネル(shit funnel)

第Ⅵ部 devops文化への架け橋

18章 devops文化への架け橋:人と人のつながりを育てる、で触れられている「文化的負債」の話が興味深かった。
採用や解雇、不適切なルールや組織階層の問題などに関してである。このワードはDevOps界隈では昔からある議論のようだ。

さて、84zumeさんはどんな感想だったのだろうか。意見交換が楽しみだ。