Upgrade to Pro — share decks privately, control downloads, hide ads and more …

カオナビにおける マイクロサービスの取組と今後の展開 / kaonavi rearchitecturing

カオナビにおける マイクロサービスの取組と今後の展開 / kaonavi rearchitecturing

カオナビにおける Re Architecturing の現状、今後の方向性について

F04982ad61107b5408ad139966596316?s=128

Ryo Tomidokoro

March 15, 2022
Tweet

More Decks by Ryo Tomidokoro

Other Decks in Technology

Transcript

  1. @hanhan1978 カオナビにおける マイクロサービスの取組と今後の展開 SaaS.tech #1 LT

  2. @hanhan1978 カオナビにおける マイクロサービスの取組と今後の展開 SaaS.tech #1 LT

  3. @hanhan1978 カオナビにおける リーアキテクチャリングの取組と今後の展開 SaaS.tech #1 LT

  4. 弊社におけるモノリシックサービス改善の取組や経緯です。 少しでも参考になると幸いです。 4 本日のお話

  5. 5

  6. 現状のソフトウェアアーキテクチャー 6

  7. - PHP (Laravel) - AWS (EC2) - モノリシック いわゆる LAMP

    スタック 2012年4月の事業開始から、2回ほどのリアーキテクチャリング 7 https://dev.classmethod.jp/articles/ec2-lamp-al2-userdata/ ※Amazon Linux2 のLAMP環境、PHP7.2と MariaDB10.2.10をUserDataで初期設置してみた
  8. 現状の問題点 3つ 8

  9. 1. ソースコードの問題点 9

  10. - 機能追加による暗黙知の増大 - ファイル数・ディレクトリ数の増加 - Package by Layer の限界 -

    機能ごとに微妙にアーキテクチャーが異なる 10
  11. 結果として、Dev/Ops 共に認知負荷が増大 → 一人あたりのコミット数は低下傾向 11

  12. 2. インフラの問題点 12

  13. - EC2 (これ自体は問題じゃない) - 開発環境はコンテナ - ECS 等に乗り換えられないと旨味が少ない 13

  14. CodePipeline 利用や、 Blue/Green デプロイなど 改善は進んでいる ソフトウェアエンジニア側がインフラレイヤーに もう少し踏み込める形が望ましい PHPのバージョンアップとか、PHPのバージョンアップとか 14

  15. 3. チーム開発の問題点 15

  16. - 開発チーム (Dev) -> 機能開発後は解散 - Dev の開発物は Ops の範疇として積まれる

    16
  17. 仲が悪いわけではない。 暗黙知の継承など、スムーズに行えているとは言い難い Ops は日に日につらくなる どこかで見たコンウェイの法則 17

  18. ここまでのまとめ 18

  19. - いわゆる事業会社あるある - ゆでガエル状態 19

  20. 状況は日に日に悪くなっている気配を感じる 問題の大きさが、各チームが保持するゆとりでは 解決できない大きさになっている Big Ball of Mud 化しつつある 20

  21. 21 このへんで、銀の弾丸が求められる

  22. 最近のイキのいい銀の弾丸 - マイクロサービス - モジュラーモノリス というあたりで私は入社しました。(2020年11月) 22

  23. @hanhan1978 • 富所 亮 • 所属 ◦ 株式会社カオナビ • 肩書

    ◦ エキスパート (??) • 役割 ◦ マイクロサービス化担当 ◦ リアーキテクチャリング担当 23
  24. 24 弊社における取り組み

  25. 25 高度な情報戦 https://codezine.jp/article/detail/15176?p=2

  26. バズワードは使ってますが、私達は正気です。 手段を目的にしない! 26

  27. 最近のマイクロサービスについての情報 27

  28. - Mercari - Retty - 本イベント 皆様アウトプットしてくれてありがとう... 28

  29. コアドメインを含めたマイクロサービス化は、相当の困難が ありそう 集約として切り離しやすそうな機能は事例がチラホラ BFFとかもよく聞く 29

  30. マイクロサービス化の結果として縦割り組織ができないか? Customer Success の阻害要因にならないか? 慎重な組織設計も求められる 30

  31. マイクロサービス化は、その後の運用 チーム体制、その他考慮することがたくさんある ログどうする?デバッグどうする?結果整合性?とりあえずツラい 31

  32. 最近のモジュラモノリスについての情報 32

  33. 33 原点確認 http://www.codingthearchitecture.com/presentations/sa2015-modular-monoliths

  34. 34 http://www.codingthearchitecture.com/presentations/sa2015-modular-monoliths 分散デカ泥団子

  35. モノリスを適切なモジュラー分割できないのは マイクロサービス以前 モジュラーモノリスの実例は、少しずつ出てきている 最近は弊社と同じ境遇の会社がモジューラモノリスに舵を切っている雰囲気を感じ ている 35

  36. 36 神発表の予感 https://fortee.jp/phperkaigi-2022/proposal/95bc3631-7683-4201-9f82-d7e7feeb7bab PHPerKaigi 2022, 4/9〜11 チケット発売中

  37. Reアーキが現在考えていること 37

  38. モノリスの複雑化の増大に対して どうやって軽減、改善していくかという構想・妄想 38

  39. 39 基本の考え方

  40. 40 モノリスを水平・垂直で考える

  41. 41 水平の例

  42. - 認証 - 通知 - メール送信 - バッチ フレームワークにおいて、ミドルウェアで切り出されるような機能群 コアドメインから疎結合にしやすい

    AWSのマネージドサービス利用、マイクロサービスとしての分割が現実的 42
  43. 43 垂直の例

  44. - カオナビの各機能単位のソースコード群 - 各機能から使われる共通モジュール - フレームワーク 機能単位では Package By Feature

    で名前空間・ディレクトリで分割 Composer Package として責務分離することで、全体の認知負荷を軽減 44
  45. 45 大切にしていること

  46. - 既存の価値提供が毀損されないこと - セキュリティ的に脆弱な構成にならないこと - ビッグリライトを避けること できれば、後戻りができる算段をした上で段階的にやりたい 46

  47. 47 アーキテクトが価値を提供する相手

  48. - 顧客・一般ユーザー - 開発者 顧客はもちろん、開発者の開発体験にも寄与したい。 秩序を保ちつつ、チャレンジの余地を残すアーキテクチャーの模索 48

  49. 49 実際に取り組んでいること

  50. - プロトタイピングによる実験 - Composer Package を使ったモジュールの分割 - AST に影響を与えにくいリファクタリング -

    コメント追加 - メソッド移動、名称変更 - 未使用クラス・メソッドの削除 50
  51. - 考古学調査 - Unknown unknown の掘り出しと文書化 - 曖昧な仕様の調査と文書化 - 複雑な仕様の調査と文書化

    - とにかく調べて調べて調べて調べて...... 51
  52. 問題から目をそらさない! 52 地味でも、大切な改善を繰り返す。栄光のゴールはその先に見えてくる!

  53. 53 https://kaonavi.connpass.com/event/240653/ 来週木曜開催!!

  54. 54 私と一緒に考古学調査しませんか? https://corp.kaonavi.jp/recruit/list

  55. 55 ご清聴ありがとうございました。