DevelopersIO DayOne モノリスかマイクロサービスか、その選択に迷っている人へ届けたい話

2023年4月11日に開催されたクラスメソッド株式会社のイベント、DevelopersIO DayOne で発表したスライドです。
「モノリスかマイクロサービスか、その選択に迷っている人へ届けたい話」をマイクロサービス導入ステップやチーム作りの観点から解説しました。

Transcript

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

2. スライドは後で入手することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター音が出ないようにご配慮ください
3. 3 Please share our event #devio_day1 #main
4. 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 吉井 亮
5. 5 今日話すこと ★ モノリスとマイクロサービスの説明 ★ マイクロサービス導入のアプローチ ★ マイクロサービス化へ取り組む方々へ チーム作りが大切ですよ、という話
6. 6 今日話さないこと start Q Q Q Q Q Q Q Q Q Q Q Q Q Monolith Micro Service YES NO
7. 7 そういうこと言うと怒られそうなので マイクロサービスに向かないアプリケーション • リソースヘビー • グラフィック重視 • 依存関係が多い • 商用パッケージ (非対応のもの) • デプロイ頻度が低い
8. 8 そういうこと言うと怒られそうなので マイクロサービスに向いているアプリケーション • 大規模なアプリケーション • 多数の開発者、多数のチームによるアプリケーション • 異なる技術スタックを必要とする • リアルタイムが要求される • デプロイ頻度が高い
9. 9 モノリスとマイクロサービス
10. 10 本セッションにおける言葉の定義 (諸説あります) ・モノリス システム内のすべての機能を 同時にデプロイしなければならないサービス ・マイクロサービス ビジネスドメインに基づいてモデル化された 独立してデプロイ可能なサービス
11. 11 本セッションにおける言葉の定義 (諸説あります) モノリス マイクロサービス App Code Deploy App Sales App Payment App Order App User Deploy Deploy Deploy Deploy
12. 12 モノリス
13. 13 モノリスは悪くない ”モノリス” という言葉にネガティブな印象が 含まれていることが稀にある
14. 14 モノリスは悪くない モノリス ≠ レガシー
15. 15 モノリスは悪くない 大きな泥だんごであることが悪い • コード内の機能に境界線が無い • 場当たりな構造化が無秩序に広がる • 度重なる急場しのぎの修繕 • 冗長で無差別な共有 • アーキテクチャが明確ではない
16. 16 モノリスは悪くない ほとんどのシステムは、 モノリスが現実的なアーキテクチャの選択肢 かつ、モジュラーモノリスが最適解である可能性が高い
17. 17 モジュラーモノリス モノリス モジュラーモノリス App Code App Sales Payment Order User
18. 18 モノリスの欠点 あるコードの変更で、無関係の機能が失敗する デリバリー衝突が起きる 異なる開発者が偶然同じコードを変更した 異なる開発者が異なる時間帯にデプロイしたい コードの規模が大きくなるほどより問題になる
19. 19 マイクロサービス
20. 20 マイクロサービスの利点 デプロイが独立することにより、 多くの開発者がお互いを邪魔することなく取り組める ビジネスドメインごとに機能が分離することで、 異なるプログラミング言語、プラットフォームを選択可能 柔軟性と拡張性、選択肢を与えてくれる
21. 21 マイクロサービスの欠点 マイクロサービスは分散システムになる - どこで何が起こっているか、把握が難しい - 高度なアーキテクチャー設計を求められる - トランザクションの分断 新しい技術が豊富に存在する → エンジニアの確保
22. 22 視点を変えてみて VM vs Container VM でマイクロサービス (っぽい) を作ることは可能 (やるやらないは別として) Container であってもモノリスになってしまうことはある
23. 23 マイクロサービスの導入
24. 24 導入する前に 1. マイクロサービス化して達成したいことは何？ a. エンドユーザーへのメリットは？ 2. 別の方法はなかったのか？ a. モノリス、モジュラーモノリス b. リファクタしてまでやるか？ 3. KPI は？ a. 「やって良かった」と言いたい b. 定性的、定量的、定期的なレビュー
25. 25 分散システムの罠にハマらないように 1. ネットワークは信頼できる 2. レイテンシはゼロである 3. 帯域幅は無限である 4. ネットワークは安全である 5. トポロジは変化しない 6. 管理者は1人である 7. 転送コストはゼロである 8. ネットワークは均質である App Sales App Payment App Order App User
26. 26 マイクロサービス導入に向けて
27. 27 The Twelve-Factor App の理解 I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス https://12factor.net/ja/
28. 28 マイクロサービス導入へのステップ 1. おおきな泥だんごに含まれているビジネス機能を特定する 2. ビジネス機能をランク付けする 競争上優位になるコア機能 > 支援的機能 > 3rd Party に置き換え可能 3. 重要ではなくなっているビジネスルールと機能 4. どの機能を優先的に抽出するか 5. 最初の機能を抽出する方法を決定 6. 1～5を繰り返し、増分的に実現していく
29. 29 マイクロサービス導入へのステップ マイクロサービス App Sales App Payment App Order App User モジュラーモノリス App Sales Payment Order User ビジネス機能
30. 30 マイクロサービスへの移行パターン ストラングラーパターン Monolith Code MicroService Sales Payment Order User 機能を移行する 移行対象 を識別する ELBなど 呼び出しを リダイレクト /payment /*
31. 31 マイクロサービスへの移行パターン UI 合成 Monolith MicroService 記事 機能を移行する 検索 天気検索 東京は晴れです 6-12 12-18 18-24
32. 32 マイクロサービスへの移行パターン 前述した2つ以外にも色々なパターンがあります。 • 抽象化によるブランチ • 同時実行 • デコレーションコラボレーター • 変更データキャプチャ 天気検索 東京は晴れです
33. 33 導入しながら考えてほしい 1. マイクロサービス化して達成したいことは何？ 2. 別の方法はなかったのか？ 道は平坦ではない。 霧の中に入ったら 「達成したいこと」を思い出す。 サンクコストは捨てる。
34. 34 Tech な話をしましたが マイクロサービスの導入には それよりも大切なことがあります
35. 35 チーム作り
36. 36 コンウェイの法則 メルヴィン・コンウェイ（Melvin Conway）によって 提唱されたソフトウェア工学の原則 "組織が設計するシステムは、 その組織自体のコミュニケーション構造を反映する"
37. 37 コンウェイの法則 続き 大規模なシステムがなぜ崩壊するか3つのステップからなる 1. システムが大規模化することを最初の設計者が見越しており そこに組織の圧力が加わり、設計に関係する人が増える 2. 経営陣の型に嵌った考え方を設計組織に当てはめると コミュニケーション構造が崩壊する 3. 同型性により、設計組織の崩壊がシステムの構造に反映される
38. 38 ルース・マラン システムのアーキテクチャと組織のアーキテクチャが 対立する場合、組織のアーキテクチャが勝つ
39. 39 逆コンウェイ戦略 コンウェイの法則を受け入れたうえでの戦略 望ましいアーキテクチャを推進するために、 チームや組織構造を進化させることを推奨する。 理想的には、テクノロジー・アーキテクチャは、 ビジネス・アーキテクチャと同型性を示す。
40. 40 例 縦割りが強い組織でのコンウェイの法則 App A App B App C App D DB DB システム 組織 DBA App B 使いたい チーム App C 使いたい チーム App D 使いたい チーム App A 使いたい チーム 超えられない壁 超えられない壁 超えられない壁 超えられない壁 超えられないライセンス
41. 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
42. 42 マイクロサービスに合ったチーム
43. 43 マイクロサービスに合ったチーム • チームをまとめる 時間をかけてタックマンモデルの 形成期～混乱期～統一期を乗り越える
44. 44 マイクロサービスに合ったチーム • チームのサイズを制限する 5～10人。 コミュニケーションパスが多すぎるとうまくいかない。 n ( n - 1 ) / 2
45. 45 マイクロサービスに合ったチーム • 独立したチームを作る コードの依存関係、リリースの調整、 デプロイ衝突をできるだけ少なくし、 納期と品質を高めるために、チーム間の依存を減らす
46. 46 マイクロサービスに合ったチーム • ビジネス機能を中心にチーム編成 ビジネスエキスパート、アーキテクト、 開発者、QA、SRE など様々なスキルを持つ者で チームを編成する
47. 47 マイクロサービスに合ったチーム • コミュニケーションゲートウェイを定義 ゲートウェイを通じてチーム間のコミュニケーションを 形成する。 目標を阻害するもの、集中力を乱すものなどに 境界線を引く。
48. 48 マイクロサービスに合ったチーム • チームに割り当てる責任は1つ コミュニケーションの複雑や重複を避ける。 1つのチームを複数のプロジェクトに同時割り当てすると ろくなことにならない。
49. 49 マイクロサービスに合ったチーム • マルチタスクを取り除く 人間の脳はマルチタスクが得意ではない
50. 50 マイクロサービスに合った文化
51. 51 マイクロサービスに合った文化 • チームの自律性が高い チーム間の依存度が低く、チームの裁量が大きい。 チーム内に各分野の専門家が揃っている。 デプロイを単独で行える。
52. 52 マイクロサービスに合った文化 • 市場投入までの時間を減らす Better than Nothing. EC サイトを作るとしたらどの程度の完成度でリリースしますか・・・ 40％ : ログインオンライン決済のみ実装して1ヶ月でリリース 80％ : ショッピングカート・在庫管理を実装して2ヶ月でリリース 100％ : レコメンド機能・クーポン機能などオンラインショピングに必要な機能が揃えて4ヶ月でリリース https://dev.classmethod.jp/articles/knqyf263-oss-better-than-nothing-awsdevday/
53. 53 マイクロサービスに合った文化 • 新しい技術を受け入れる • トレードオフを受け入れる ネガティブよりポジティブを重視。 例) Kubernetes ネガ = 4ヶ月ごとのバージョンアップ ポジ = 豊富なエコシステムによる優れた機能
54. 54 マイクロサービスに合った文化 • みんなを連れていく • 組織を変革するためのビジョンを周知徹底 誰をバスに乗せるか 必要な人がバスに乗っているか
55. 55 マイクロサービスに合った文化 • 段階的に移行していく • 可逆的な判断と不可逆的な判断を使い分ける 可逆的 → 引き返せるのですぐに試して成果を得る 不可逆的 → 慎重に判断する
56. 56 マイクロサービスに合った文化 • ドメイン駆動設計を取り入れる ドメイン駆動設計とマイクロサービスの相性の良さ
57. 57 まとめ
58. 58 本セッションのタイトル ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ モノリスかマイクロサービスか、 その選択に迷っている人へ届けたい話
59. 59 3行まとめ 迷っている人へ届けたい話 • モノリスは悪くない (むしろ現実的) • マイクロサービスで達成したいことは何？ • チームと文化を作ることができるか、が分岐点
60. 60 参考にした書籍 ～Thanks～ ▪ モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド Sam Newman　著、島田 浩二　訳 ▪ 要件最適アーキテクチャ戦略 Vaughn Vernon 原著 Tomasz Jaskuła 原著 株式会社クイープ 翻訳 株式会社クイープ 監修
61. 61 参考にした書籍 ～Thanks～ ▪ チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 永瀬 美穂 (翻訳), 吉羽 龍太郎 (翻訳)