Download to read offline
![[Slide]闇アジャイラーvs光アジャイラーforDevLOVE(EnergizedWorkLT祭)](https://cdn.slidesharecdn.com/ss_thumbnails/slidevsfordevloveenergizedworklt-100930000024-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
MicroServiceArchitecture
- 1.
- 2.
- 3.
- 5.
- 6.
- 7.
- 8.
- 9. 突然ですが、DevOpsって知っていますか？ そうです。DevとOpsが組み合わさったものです。 バズってます これの実現を目標にする上司がいたら、黄色信号。 理由は、のちほど
- 10.
- 11.
- 12.
- 13.
- 14.
- 15. DevOpsって、なぜ生まれたのでしょう？ どの企業も、レッドオーシャンでビジネスなんかしたくないんです だから、 新しい分野への進出していく 何らかの付加価値をつけていく
- 16. DevOpsって、なぜ生まれたのでしょう？ どの企業も、レッドオーシャンでビジネスなんかしたくないんです だから、 新しい分野への進出していく 何らかの付加価値をつけていく そこは、トライ＆エラーの世界
- 17. DevOpsって、なぜ生まれたのでしょう？ どの企業も、レッドオーシャンでビジネスなんかしたくないんです だから、 新しい分野への進出していく 何らかの付加価値をつけていく そこは、トライ＆エラーの世界 何が成功するのか、答えは誰も知らない世界です
- 18. DevOpsって、なぜ生まれたのでしょう？ どの企業も、レッドオーシャンでビジネスなんかしたくないんです だから、 新しい分野への進出していく 何らかの付加価値をつけていく そこは、トライ＆エラーの世界 何が成功するのか、答えは誰も知らない世界です だから仮説をつくり、それを世の中に出して結果を検証していく
- 19. DevOpsって、なぜ生まれたのでしょう？ どの企業も、レッドオーシャンでビジネスなんかしたくないんです だから、 新しい分野への進出していく 何らかの付加価値をつけていく そこは、トライ＆エラーの世界 何が成功するのか、答えは誰も知らない世界です だから仮説をつくり、それを世の中に出して結果を検証していく そのとき、「早く失敗する」（検証した結果を知る）というのが必要なんです
- 20. DevOpsって、なぜ生まれたのでしょう？ どの企業も、レッドオーシャンでビジネスなんかしたくないんです だから、 新しい分野への進出していく 何らかの付加価値をつけていく そこは、トライ＆エラーの世界 何が成功するのか、答えは誰も知らない世界です だから仮説をつくり、それを世の中に出して結果を検証していく そのとき、「早く失敗する」（検証した結果を知る）というのが必要なんです 「早く失敗する」ことで、 早くビジネスの方向を変えたりすることができる
- 21. DevOpsって、なぜ生まれたのでしょう？ どの企業も、レッドオーシャンでビジネスなんかしたくないんです だから、 新しい分野への進出していく 何らかの付加価値をつけていく そこは、トライ＆エラーの世界 何が成功するのか、答えは誰も知らない世界です だから仮説をつくり、それを世の中に出して結果を検証していく そのとき、「早く失敗する」（検証した結果を知る）というのが必要なんです 「早く失敗する」ことで、 早くビジネスの方向を変えたりすることができる 致命傷になる前にやめられる
- 23. 大丈夫です。ひどいニオイかもしれないけど、 鍋は無事です（外から見る限り） 火事になっていないですよ。
- 24.
- 25. 「早く失敗する」にはどうしたらいい？ 「構築 –計測 – 学習」のサイクルをできる限り早く回すことです このあたりは、リーン開発とかが詳しいみたいです。 深追いはしませんよ。
- 26. 「早く失敗する」にはどうしたらいい？ 「構築 –計測 – 学習」のサイクルをできる限り早く回すことです このあたりは、リーン開発とかが詳しいみたいです。 深追いはしませんよ。 ものすご～く大雑把にいうと
- 27. 「早く失敗する」にはどうしたらいい？ 「構築 –計測 – 学習」のサイクルをできる限り早く回すことです このあたりは、リーン開発とかが詳しいみたいです。 深追いはしませんよ。 ものすご～く大雑把にいうと 構築： システムの構築や改修 計測： 運用と、そこで得られる様々なデータ 学習： 計測で得られたデータから得た知見
- 28. 「早く失敗する」にはどうしたらいい？ 「構築 –計測 – 学習」のサイクルをできる限り早く回すことです このあたりは、リーン開発とかが詳しいみたいです。 深追いはしませんよ。 ものすご～く大雑把にいうと 構築： システムの構築や改修 計測： 運用と、そこで得られる様々なデータ 学習： 計測で得られたデータから得た知見 ⇒このサイクルをできるだけ早くしていきたい
- 30. 「構築 – 計測– 学習」サイクルを早めるには
- 31. 「構築 – 計測– 学習」サイクルを早めるには いままで（いまも？）こういった組織構成となることが多かったのでは？ 構築：開発部門 計測：運用部門 学習：サービス事業部門
- 32. 「構築 – 計測– 学習」サイクルを早めるには いままで（いまも？）こういった組織構成となることが多かったのでは？ 構築：開発部門 計測：運用部門 学習：サービス事業部門 これでは、サイクルを回すのにオーバヘッドがかかってしまいます
- 33. 「構築 – 計測– 学習」サイクルを早めるには いままで（いまも？）こういった組織構成となることが多かったのでは？ 構築：開発部門 計測：運用部門 学習：サービス事業部門 これでは、サイクルを回すのにオーバヘッドがかかってしまいます こういった組織の垣根を取り払ってチーム一丸となる必要があります
- 34. 「構築 – 計測– 学習」サイクルを早めるには いままで（いまも？）こういった組織構成となることが多かったのでは？ 構築：開発部門 計測：運用部門 学習：サービス事業部門 これでは、サイクルを回すのにオーバヘッドがかかってしまいます こういった組織の垣根を取り払ってチーム一丸となる必要があります でもこれって、とても難しいことなんです。 たとえば
- 35. 「構築 – 計測– 学習」サイクルを早めるには いままで（いまも？）こういった組織構成となることが多かったのでは？ 構築：開発部門 計測：運用部門 学習：サービス事業部門 これでは、サイクルを回すのにオーバヘッドがかかってしまいます こういった組織の垣根を取り払ってチーム一丸となる必要があります でもこれって、とても難しいことなんです。 たとえば 開発部門 vs サービス just like: “あなた作る人、わたし食べる人”
- 36. 「構築 – 計測– 学習」サイクルを早めるには いままで（いまも？）こういった組織構成となることが多かったのでは？ 構築：開発部門 計測：運用部門 学習：サービス事業部門 これでは、サイクルを回すのにオーバヘッドがかかってしまいます こういった組織の垣根を取り払ってチーム一丸となる必要があります でもこれって、とても難しいことなんです。 たとえば 開発部門 vs サービス just like: “あなた作る人、わたし食べる人” 開発部門 vs 運用部門 just like: “変化”を好む vs “安定”を好む
- 37.
- 38. 「構築 – 計測– 学習」サイクルで 必要とされる「構築」とは？ 「構築 - 計測 - 学習」サイクルを回していくためには 「構築」にかかる時間を短くする必要があります。
- 39. 「構築 – 計測– 学習」サイクルで 必要とされる「構築」とは？ 「構築 - 計測 - 学習」サイクルを回していくためには 「構築」にかかる時間を短くする必要があります。 日本では、ここで「アジャイル開発が必要！」となります。
- 40. 「構築 – 計測– 学習」サイクルで 必要とされる「構築」とは？ 「構築 - 計測 - 学習」サイクルを回していくためには 「構築」にかかる時間を短くする必要があります。 日本では、ここで「アジャイル開発が必要！」となります。 でも海外では、そうはなりません。なぜならアジャイルが普通だからです。
- 41. 「構築 – 計測– 学習」サイクルで 必要とされる「構築」とは？ 「構築 - 計測 - 学習」サイクルを回していくためには 「構築」にかかる時間を短くする必要があります。 日本では、ここで「アジャイル開発が必要！」となります。 でも海外では、そうはなりません。なぜならアジャイルが普通だからです。 「私は間違っていた。ごめん。ウォーターフォールは何のメリットもない」 in メソッド屋のブログ http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
- 42. 「構築 – 計測– 学習」サイクルで 必要とされる「構築」とは？ 「構築 - 計測 - 学習」サイクルを回していくためには 「構築」にかかる時間を短くする必要があります。 アジャイル開発では、 変化を受容する
- 43. 「構築 – 計測– 学習」サイクルで 必要とされる「構築」とは？ 「構築 - 計測 - 学習」サイクルを回していくためには 「構築」にかかる時間を短くする必要があります。 アジャイル開発では、 変化を受容する そこには仮説に沿った「構築」を行う素地が既にある
- 45. 「構築 – 計測– 学習」サイクルに おける「学習」とは？ 仮説を立てる
- 46. 「構築 – 計測– 学習」サイクルに おける「学習」とは？ 仮説を立てる 仮説のもととなるデータは「計測」のなかで取得される
- 47. 「構築 – 計測– 学習」サイクルに おける「学習」とは？ 仮説を立てる 仮説のもととなるデータは「計測」のなかで取得される フィードバックから、仮説が正しかったのかを検証する
- 48. 「構築 – 計測– 学習」サイクルに おける「学習」とは？ 仮説を立てる 仮説のもととなるデータは「計測」のなかで取得される フィードバックから、仮説が正しかったのかを検証する フィードバックは「計測」からもたらされる
- 49. 「構築 – 計測– 学習」サイクルに おける「学習」とは？ 仮説を立てる 仮説のもととなるデータは「計測」のなかで取得される フィードバックから、仮説が正しかったのかを検証する フィードバックは「計測」からもたらされる 進む方向を決定する
- 51. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」のために
- 52. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」のために 「構築 - 計測 - 学習」サイクルを回していくためには 「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。
- 53. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」のために 「構築 - 計測 - 学習」サイクルを回していくためには 「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。 環境の作成の高速化
- 54. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」のために 「構築 - 計測 - 学習」サイクルを回していくためには 「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。 環境の作成を機械化 仮想化、コンテナ
- 55. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」のために 「構築 - 計測 - 学習」サイクルを回していくためには 「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。 環境の作成の高速化 仮想化、コンテナ Infrastructure As Code
- 56. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」のために 「構築 - 計測 - 学習」サイクルを回していくためには 「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。 環境の作成の高速化 仮想化、コンテナ Infrastructure As Code Blue Green Deployment
- 57. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」のために 「構築 - 計測 - 学習」サイクルを回していくためには 「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。 環境の作成の高速化 仮想化、コンテナ 直接、機械を触る必要がなくなる Infrastructure As Code Blue Green Deployment
- 58. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」のために 「構築 - 計測 - 学習」サイクルを回していくためには 「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。 環境の作成の高速化 仮想化、コンテナ 直接、機械を触る必要がなくなる Infrastructure As Code 人間が１台ずつ設定していく必要がなくなる Blue Green Deployment
- 59. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」のために 「構築 - 計測 - 学習」サイクルを回していくためには 「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。 環境の作成の高速化 仮想化、コンテナ 直接、機械を触る必要がなくなる Infrastructure As Code 人間が１台ずつ設定していく必要がなくなる Blue Green Deployment 設定は必要になったタイミングで都度、実施 いらなくなったら、全部リセット
- 60. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」とは？
- 61. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」とは？ 仮説を構築するためのデータを提供する
- 62. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」とは？ 仮説を構築するためのデータを提供する 仮説を検証するためのフィードバックを提供する
- 63. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」とは？ 仮説を構築するためのデータを提供する 仮説を検証するためのフィードバックを提供する 「学習」のプロセスでは上記が視覚化されることが必要
- 64. 「構築 – 計測– 学習」サイクルで 必要とされる「測定」とは？ 仮説を構築するためのデータを提供する 仮説を検証するためのフィードバックを提供する 「学習」のプロセスでは上記が視覚化されることが必要 視覚化を「計測」「学習」のどちらでやるかは、考えなくてもよいと思う。 チーム一丸なので、どちらでも。
- 65.
- 66. ひとつの巨大なシステムでは、 「構築 - 計測- 学習」サイクルを早く回せない
- 67. ひとつの巨大なシステムでは、 「構築 - 計測- 学習」サイクルを早く回せない リリースには時間がかかります
- 68. ひとつの巨大なシステムでは、 「構築 - 計測- 学習」サイクルを早く回せない リリースには時間がかかります 部署間の調整 システムの影響範囲の調査
- 69. ひとつの巨大なシステムでは、 「構築 - 計測- 学習」サイクルを早く回せない リリースには時間がかかります 部署間の調整 システムの影響範囲の調査 スケールアウトではなく、スケールアップが選択肢となることが多い
- 70. ひとつの巨大なシステムでは、 「構築 - 計測- 学習」サイクルを早く回せない リリースには時間がかかります 部署間の調整 システムの影響範囲の調査 スケールアウトではなく、スケールアップが選択肢となることが多い チームや組織、コンポーネントの関係が密になりすぎているわけです
- 71. ひとつの巨大なシステムでは、 「構築 - 計測- 学習」サイクルを早く回せない リリースには時間がかかります 部署間の調整 システムの影響範囲の調査 スケールアウトではなく、スケールアップが選択肢となることが多い チームや組織、コンポーネントの関係が密になりすぎているわけです この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず） APIを通じて、お互いがコミュニケーションすればよい
- 72. ひとつの巨大なシステムでは、 「構築 - 計測- 学習」サイクルを早く回せない リリースには時間がかかります 部署間の調整 システムの影響範囲の調査 スケールアウトではなく、スケールアップが選択肢となることが多い チームや組織、コンポーネントの関係が密になりすぎているわけです この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず） APIを通じて、お互いがコミュニケーションすればよい スケールアップではなく、スケールアウトが選択肢となる
- 73. ひとつの巨大なシステムでは、 「構築 - 計測- 学習」サイクルを早く回せない リリースには時間がかかります 部署間の調整 システムの影響範囲の調査 スケールアウトではなく、スケールアップが選択肢となることが多い チームや組織、コンポーネントの関係が密になりすぎているわけです この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず） APIを通じて、お互いがコミュニケーションすればよい スケールアップではなく、スケールアウトが選択肢となる ⇒これが、「マイクロサービス・アーキテクチャ」の原型です
- 74. ひとつの巨大なシステムでは、 「構築 - 計測- 学習」サイクルを早く回せない リリースには時間がかかります 部署間の調整 システムの影響範囲の調査 スケールアップ チームや組織、コンポーネントの関係が密になりすぎているわけです この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず） APIを通じて、お互いがコミュニケーションすればよい スケールアップではなく、スケールアウトが選択肢となる ⇒これが、「マイクロサービス・アーキテクチャ」の原型です 「マイクロサービス・アーキテクチャ」は、 現実世界の課題を解決しようと 試行錯誤したうえで出てきたもの
- 75. マイクロサービス・アーキテクチャの一般化 ２０１４年、マーティン・ファウラーとジェームス・ルイスにより 「マイクロサービスの前提条件」という記事を公開 ※http://martinfowler.com/articles/microservices.html 現在、マイクロサービスについて議論されるときは、この記事の内容が意識されている（はず）
- 76.
- 77.
- 78. 「マイクロサービス・アーキテクチャ」へ トップダウンで、こちらに舵を切ることが重要です ボトムアップではうまくいきません。 組織を変更する必要があります 「失敗」を糧とする文化が必要です
- 79.
- 80. おまけ（時間が余れば） 実際に構築するマイクロサービス（のようなもの）を構築するなら “TheTweleve-Factor App”(http://12factor.net/)を知っていたほうがいいです 日本語訳もあります（http://12factor.net/ja/）
- 81.
- 82.
Editor's Notes
- #33 それぞれの組織が、自己の「責任」を果たそうとする とても正しく、素晴らしいことで、それを否定するつもりはないのです （誤解されそうなので、ここ強調！）
- #37 一丸となるには、結集軸が必要となります。 ・自分の組織や仕事への影響は出るでしょうが、それを甘受できるようになるなにかが。
- #61 アジャイル開発が隆盛：２０００年前後。 ２００１年、「アジャイルソフトウェア開発宣言」 一方、MapReduceのGoogleの論文は、2004年
- #63 アジャイル開発が隆盛したときには、まだこの、計測は難しかった。 ２００１年、「アジャイルソフトウェア開発宣言」 一方、MapReduceのGoogleの論文は、2004年
- #64 アジャイル開発が隆盛したときには、まだこの、計測は難しかった。 ２００１年、「アジャイルソフトウェア開発宣言」 一方、MapReduceのGoogleの論文は、2004年
- #65 アジャイル開発が隆盛したときには、まだこの、計測は難しかった。 ２００１年、「アジャイルソフトウェア開発宣言」 一方、MapReduceのGoogleの論文は、2004年
- #76 「発見」っていうのは言い過ぎなので、訂正
- #78 http://readwrite.jp/startup/29950 に失敗を従容すること そして有名な６原則が書かれている。 英語だと、こちら？ http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/ 「Amazonは一つのことだけに携わる小さなチームの集まりで出来ており、そのために急速なイノベーションが可能になっている」とベゾス氏は述べている。 これらのチームは、以下にある「公開されたAPI」に（強制的に）沿って互いにコミュニケーションを取っている。 －全てのチームはサービスインターフェイスを通じてその機能やデータを公開しなければならない。 －チームのコミュニケーションはインターフェイスを通じて行われる。 －インターフェイスを通じたもの以外のあらゆるプロセス間通信は許可されない。 直接的にリンクすること、他のチームのデータを直接見ること、共有メモリモデルによる コミュニケーション、バックドアやその他の手段すべてに対してこれは適用される。 唯一許可されるコミュニケーションは、ネットワーク越しにインターフェイスを叩くことのみである。 －どのようなテクノロジーを使っていたとしてもこのルールは変わらない。 －どのようなサービスインターフェイスも例外なく公開されることを前提に、 根底からデザインされなければならない。つまり、チームはインターフェイスを 開発者に公開できるようにプラン設計を行わなければならない。例外は認められない。 そして、これらを選択肢の1つだと考えているAmazonの従業員たちに対し、ベゾス氏はこう締めくくっている。 「これを守れない社員はクビにする。では、今日もいい日を」