Tweet
Tweet

Slide 1

Slide 1 text

モノリスかマイクロサービスか、
 その選択に迷っている人へ届けたい話
 2023/04/11
 吉井 亮


Slide 2

Slide 2 text

スライドは後で入手することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター音が出ないようにご配慮ください

Slide 3

Slide 3 text

3 Please share our event #devio_day1 #main

Slide 4

Slide 4 text

4 自己紹介 経歴 HWエンジニア → 中小SIer → ERPコンサル → Jul 2018 クラスメソッド Jul 2020 ネクストモード Apr 2022 クラスメソッド Follow Me https://twitter.com/YoshiiRyo1 Community OpsJAWS JAWS-UG GameTech専門支部 好きな言葉 No human labor is no human error. Ryo Yoshii 吉井 亮

Slide 5

Slide 5 text

5 今日話すこと ★ モノリスとマイクロサービスの説明 ★ マイクロサービス導入のアプローチ ★ マイクロサービス化へ取り組む方々へ チーム作りが大切ですよ、という話

Slide 6

Slide 6 text

6 今日話さないこと start Q Q Q Q Q Q Q Q Q Q Q Q Q Monolith Micro Service YES NO

Slide 7

Slide 7 text

7 そういうこと言うと怒られそうなので マイクロサービスに向かないアプリケーション ● リソースヘビー ● グラフィック重視 ● 依存関係が多い ● 商用パッケージ (非対応のもの) ● デプロイ頻度が低い

Slide 8

Slide 8 text

8 そういうこと言うと怒られそうなので マイクロサービスに向いているアプリケーション ● 大規模なアプリケーション ● 多数の開発者、多数のチームによるアプリケーション ● 異なる技術スタックを必要とする ● リアルタイムが要求される ● デプロイ頻度が高い

Slide 9

Slide 9 text

9 モノリスとマイクロサービス

Slide 10

Slide 10 text

10 本セッションにおける言葉の定義 (諸説あります) ・モノリス システム内のすべての機能を 同時にデプロイしなければならないサービス ・マイクロサービス ビジネスドメインに基づいてモデル化された 独立してデプロイ可能なサービス

Slide 11

Slide 11 text

11 本セッションにおける言葉の定義 (諸説あります) モノリス マイクロサービス App Code Deploy App Sales App Payment App Order App User Deploy Deploy Deploy Deploy

Slide 12

Slide 12 text

12 モノリス

Slide 13

Slide 13 text

13 モノリスは悪くない ”モノリス” という言葉にネガティブな印象が 含まれていることが稀にある

Slide 14

Slide 14 text

14 モノリスは悪くない モノリス ≠ レガシー

Slide 15

Slide 15 text

15 モノリスは悪くない 大きな泥だんごであることが悪い ● コード内の機能に境界線が無い ● 場当たりな構造化が無秩序に広がる ● 度重なる急場しのぎの修繕 ● 冗長で無差別な共有 ● アーキテクチャが明確ではない

Slide 16

Slide 16 text

16 モノリスは悪くない ほとんどのシステムは、 モノリスが現実的なアーキテクチャの選択肢 かつ、モジュラーモノリスが最適解である可能性が高い

Slide 17

Slide 17 text

17 モジュラーモノリス モノリス モジュラーモノリス App Code App Sales Payment Order User

Slide 18

Slide 18 text

18 モノリスの欠点 あるコードの変更で、無関係の機能が失敗する デリバリー衝突が起きる 異なる開発者が偶然同じコードを変更した 異なる開発者が異なる時間帯にデプロイしたい コードの規模が大きくなるほどより問題になる

Slide 19

Slide 19 text

19 マイクロサービス

Slide 20

Slide 20 text

20 マイクロサービスの利点 デプロイが独立することにより、 多くの開発者がお互いを邪魔することなく取り組める ビジネスドメインごとに機能が分離することで、 異なるプログラミング言語、プラットフォームを選択可能 柔軟性と拡張性、選択肢を与えてくれる

Slide 21

Slide 21 text

21 マイクロサービスの欠点 マイクロサービスは分散システムになる - どこで何が起こっているか、把握が難しい - 高度なアーキテクチャー設計を求められる - トランザクションの分断 新しい技術が豊富に存在する → エンジニアの確保

Slide 22

Slide 22 text

22 視点を変えてみて VM vs Container VM でマイクロサービス (っぽい) を作ることは可能 (やるやらないは別として) Container であってもモノリスになってしまうことはある

Slide 23

Slide 23 text

23 マイクロサービスの導入

Slide 24

Slide 24 text

24 導入する前に 1. マイクロサービス化して達成したいことは何？ a. エンドユーザーへのメリットは？ 2. 別の方法はなかったのか？ a. モノリス、モジュラーモノリス b. リファクタしてまでやるか？ 3. KPI は？ a. 「やって良かった」と言いたい b. 定性的、定量的、定期的なレビュー

Slide 25

Slide 25 text

25 分散システムの罠にハマらないように 1. ネットワークは信頼できる 2. レイテンシはゼロである 3. 帯域幅は無限である 4. ネットワークは安全である 5. トポロジは変化しない 6. 管理者は1人である 7. 転送コストはゼロである 8. ネットワークは均質である App Sales App Payment App Order App User

Slide 26

Slide 26 text

26 マイクロサービス導入に向けて

Slide 27

Slide 27 text

27 The Twelve-Factor App の理解 I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス https://12factor.net/ja/

Slide 28

Slide 28 text

28 マイクロサービス導入へのステップ 1. おおきな泥だんごに含まれているビジネス機能を特定する 2. ビジネス機能をランク付けする 競争上優位になるコア機能 > 支援的機能 > 3rd Party に置き換え可能 3. 重要ではなくなっているビジネスルールと機能 4. どの機能を優先的に抽出するか 5. 最初の機能を抽出する方法を決定 6. 1～5を繰り返し、増分的に実現していく

Slide 29

Slide 29 text

29 マイクロサービス導入へのステップ マイクロサービス App Sales App Payment App Order App User モジュラーモノリス App Sales Payment Order User ビジネス機能

Slide 30

Slide 30 text

30 マイクロサービスへの移行パターン ストラングラーパターン Monolith Code MicroService Sales Payment Order User 機能を移行する 移行対象 を識別する ELBなど 呼び出しを リダイレクト /payment /*

Slide 31

Slide 31 text

31 マイクロサービスへの移行パターン UI 合成 Monolith MicroService 記事 機能を移行する 検索 天気検索 東京は晴れです 6-12 12-18 18-24

Slide 32

Slide 32 text

32 マイクロサービスへの移行パターン 前述した2つ以外にも色々なパターンがあります。 ● 抽象化によるブランチ ● 同時実行 ● デコレーションコラボレーター ● 変更データキャプチャ 天気検索 東京は晴れです

Slide 33

Slide 33 text

33 導入しながら考えてほしい 1. マイクロサービス化して達成したいことは何？ 2. 別の方法はなかったのか？ 道は平坦ではない。 霧の中に入ったら 「達成したいこと」を思い出す。 サンクコストは捨てる。

Slide 34

Slide 34 text

34 Tech な話をしましたが マイクロサービスの導入には それよりも大切なことがあります

Slide 35

Slide 35 text

35 チーム作り

Slide 36

Slide 36 text

36 コンウェイの法則 メルヴィン・コンウェイ（Melvin Conway）によって 提唱されたソフトウェア工学の原則 "組織が設計するシステムは、 その組織自体のコミュニケーション構造を反映する"

Slide 37

Slide 37 text

37 コンウェイの法則 続き 大規模なシステムがなぜ崩壊するか3つのステップからなる 1. システムが大規模化することを最初の設計者が見越しており そこに組織の圧力が加わり、設計に関係する人が増える 2. 経営陣の型に嵌った考え方を設計組織に当てはめると コミュニケーション構造が崩壊する 3. 同型性により、設計組織の崩壊がシステムの構造に反映される

Slide 38

Slide 38 text

38 ルース・マラン システムのアーキテクチャと組織のアーキテクチャが 対立する場合、組織のアーキテクチャが勝つ

Slide 39

Slide 39 text

39 逆コンウェイ戦略 コンウェイの法則を受け入れたうえでの戦略 望ましいアーキテクチャを推進するために、 チームや組織構造を進化させることを推奨する。 理想的には、テクノロジー・アーキテクチャは、 ビジネス・アーキテクチャと同型性を示す。

Slide 40

Slide 40 text

40 例 縦割りが強い組織でのコンウェイの法則 App A App B App C App D DB DB システム 組織 DBA App B 使いたい チーム App C 使いたい チーム App D 使いたい チーム App A 使いたい チーム 超えられない壁 超えられない壁 超えられない壁 超えられない壁 超えられないライセンス

Slide 41

Slide 41 text

41 組織を改善する例 コミュニケーション改善 Front Team Backend Team DBA Team スキルのサイロ化 スキルのサイロ化 スキルのサイロ化 スキルのサイロ化 機能横断的なスキルとビジネス機能 Backend Team が コミュニケーションハブ App A Front Eng. Backend Eng. DBA App B Front Eng. Backend Eng. DBA App C Front Eng. Backend Eng. DBA App D Front Eng. Backend Eng. DBA

Slide 42

Slide 42 text

42 マイクロサービスに合ったチーム

Slide 43

Slide 43 text

43 マイクロサービスに合ったチーム ● チームをまとめる 時間をかけてタックマンモデルの 形成期～混乱期～統一期を乗り越える

Slide 44

Slide 44 text

44 マイクロサービスに合ったチーム ● チームのサイズを制限する 5～10人。 コミュニケーションパスが多すぎるとうまくいかない。 n ( n - 1 ) / 2

Slide 45

Slide 45 text

45 マイクロサービスに合ったチーム ● 独立したチームを作る コードの依存関係、リリースの調整、 デプロイ衝突をできるだけ少なくし、 納期と品質を高めるために、チーム間の依存を減らす

Slide 46

Slide 46 text

46 マイクロサービスに合ったチーム ● ビジネス機能を中心にチーム編成 ビジネスエキスパート、アーキテクト、 開発者、QA、SRE など様々なスキルを持つ者で チームを編成する

Slide 47

Slide 47 text

47 マイクロサービスに合ったチーム ● コミュニケーションゲートウェイを定義 ゲートウェイを通じてチーム間のコミュニケーションを 形成する。 目標を阻害するもの、集中力を乱すものなどに 境界線を引く。

Slide 48

Slide 48 text

48 マイクロサービスに合ったチーム ● チームに割り当てる責任は1つ コミュニケーションの複雑や重複を避ける。 1つのチームを複数のプロジェクトに同時割り当てすると ろくなことにならない。

Slide 49

Slide 49 text

49 マイクロサービスに合ったチーム ● マルチタスクを取り除く 人間の脳はマルチタスクが得意ではない

Slide 50

Slide 50 text

50 マイクロサービスに合った文化

Slide 51

Slide 51 text

51 マイクロサービスに合った文化 ● チームの自律性が高い チーム間の依存度が低く、チームの裁量が大きい。 チーム内に各分野の専門家が揃っている。 デプロイを単独で行える。

Slide 52

Slide 52 text

52 マイクロサービスに合った文化 ● 市場投入までの時間を減らす Better than Nothing. EC サイトを作るとしたらどの程度の完成度でリリースしますか・・・ 40％ : ログインオンライン決済のみ実装して1ヶ月でリリース 80％ : ショッピングカート・在庫管理を実装して2ヶ月でリリース 100％ : レコメンド機能・クーポン機能などオンラインショピングに必要な機能が揃えて4ヶ月でリリース https://dev.classmethod.jp/articles/knqyf263-oss-better-than-nothing-awsdevday/

Slide 53

Slide 53 text

53 マイクロサービスに合った文化 ● 新しい技術を受け入れる ● トレードオフを受け入れる ネガティブよりポジティブを重視。 例) Kubernetes ネガ = 4ヶ月ごとのバージョンアップ ポジ = 豊富なエコシステムによる優れた機能

Slide 54

Slide 54 text

54 マイクロサービスに合った文化 ● みんなを連れていく ● 組織を変革するためのビジョンを周知徹底 誰をバスに乗せるか 必要な人がバスに乗っているか

Slide 55

Slide 55 text

55 マイクロサービスに合った文化 ● 段階的に移行していく ● 可逆的な判断と不可逆的な判断を使い分ける 可逆的 → 引き返せるのですぐに試して成果を得る 不可逆的 → 慎重に判断する

Slide 56

Slide 56 text

56 マイクロサービスに合った文化 ● ドメイン駆動設計を取り入れる ドメイン駆動設計とマイクロサービスの相性の良さ

Slide 57

Slide 57 text

57 まとめ

Slide 58

Slide 58 text

58 本セッションのタイトル ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ モノリスかマイクロサービスか、 その選択に迷っている人へ届けたい話

Slide 59

Slide 59 text

59 3行まとめ 迷っている人へ届けたい話 ● モノリスは悪くない (むしろ現実的) ● マイクロサービスで達成したいことは何？ ● チームと文化を作ることができるか、が分岐点

Slide 60

Slide 60 text

60 参考にした書籍 ～Thanks～ ■ モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド Sam Newman　著、島田 浩二　訳 ■ 要件最適アーキテクチャ戦略 Vaughn Vernon 原著 Tomasz Jaskuła 原著 株式会社クイープ 翻訳 株式会社クイープ 監修

Slide 61

Slide 61 text

61 参考にした書籍 ～Thanks～ ■ チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 永瀬 美穂 (翻訳), 吉羽 龍太郎 (翻訳)

Slide 62

Slide 62 text

62