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

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

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

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

Ryo Tomidokoro

March 15, 2022
Tweet

More Decks by Ryo Tomidokoro

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  5. 5

    View Slide

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

    View Slide

  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で初期設置してみた

    View Slide

  8. 現状の問題点 3つ
    8

    View Slide

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

    View Slide

  10. - 機能追加による暗黙知の増大
    - ファイル数・ディレクトリ数の増加
    - Package by Layer の限界
    - 機能ごとに微妙にアーキテクチャーが異なる
    10

    View Slide

  11. 結果として、Dev/Ops 共に認知負荷が増大
    → 一人あたりのコミット数は低下傾向
    11

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  18. ここまでのまとめ
    18

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  23. @hanhan1978
    ● 富所 亮
    ● 所属
    ○ 株式会社カオナビ
    ● 肩書
    ○ エキスパート (??)
    ● 役割
    ○ マイクロサービス化担当
    ○ リアーキテクチャリング担当
    23

    View Slide

  24. 24
    弊社における取り組み

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  39. 39
    基本の考え方

    View Slide

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

    View Slide

  41. 41
    水平の例

    View Slide

  42. - 認証
    - 通知
    - メール送信
    - バッチ
    フレームワークにおいて、ミドルウェアで切り出されるような機能群
    コアドメインから疎結合にしやすい
    AWSのマネージドサービス利用、マイクロサービスとしての分割が現実的
    42

    View Slide

  43. 43
    垂直の例

    View Slide

  44. - カオナビの各機能単位のソースコード群
    - 各機能から使われる共通モジュール
    - フレームワーク
    機能単位では Package By Feature で名前空間・ディレクトリで分割
    Composer Package として責務分離することで、全体の認知負荷を軽減
    44

    View Slide

  45. 45
    大切にしていること

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  50. - プロトタイピングによる実験
    - Composer Package を使ったモジュールの分割
    - AST に影響を与えにくいリファクタリング
    - コメント追加
    - メソッド移動、名称変更
    - 未使用クラス・メソッドの削除
    50

    View Slide

  51. - 考古学調査
    - Unknown unknown の掘り出しと文書化
    - 曖昧な仕様の調査と文書化
    - 複雑な仕様の調査と文書化
    - とにかく調べて調べて調べて調べて......
    51

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide