カオナビにおける マイクロサービスの取組と今後の展開 / kaonavi rearchitecturing
by
Ryo Tomidokoro
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
@hanhan1978 カオナビにおける マイクロサービスの取組と今後の展開 SaaS.tech #1 LT
Slide 2
Slide 2 text
@hanhan1978 カオナビにおける マイクロサービスの取組と今後の展開 SaaS.tech #1 LT
Slide 3
Slide 3 text
@hanhan1978 カオナビにおける リーアキテクチャリングの取組と今後の展開 SaaS.tech #1 LT
Slide 4
Slide 4 text
弊社におけるモノリシックサービス改善の取組や経緯です。 少しでも参考になると幸いです。 4 本日のお話
Slide 5
Slide 5 text
5
Slide 6
Slide 6 text
現状のソフトウェアアーキテクチャー 6
Slide 7
Slide 7 text
- 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で初期設置してみた
Slide 8
Slide 8 text
現状の問題点 3つ 8
Slide 9
Slide 9 text
1. ソースコードの問題点 9
Slide 10
Slide 10 text
- 機能追加による暗黙知の増大 - ファイル数・ディレクトリ数の増加 - Package by Layer の限界 - 機能ごとに微妙にアーキテクチャーが異なる 10
Slide 11
Slide 11 text
結果として、Dev/Ops 共に認知負荷が増大 → 一人あたりのコミット数は低下傾向 11
Slide 12
Slide 12 text
2. インフラの問題点 12
Slide 13
Slide 13 text
- EC2 (これ自体は問題じゃない) - 開発環境はコンテナ - ECS 等に乗り換えられないと旨味が少ない 13
Slide 14
Slide 14 text
CodePipeline 利用や、 Blue/Green デプロイなど 改善は進んでいる ソフトウェアエンジニア側がインフラレイヤーに もう少し踏み込める形が望ましい PHPのバージョンアップとか、PHPのバージョンアップとか 14
Slide 15
Slide 15 text
3. チーム開発の問題点 15
Slide 16
Slide 16 text
- 開発チーム (Dev) -> 機能開発後は解散 - Dev の開発物は Ops の範疇として積まれる 16
Slide 17
Slide 17 text
仲が悪いわけではない。 暗黙知の継承など、スムーズに行えているとは言い難い Ops は日に日につらくなる どこかで見たコンウェイの法則 17
Slide 18
Slide 18 text
ここまでのまとめ 18
Slide 19
Slide 19 text
- いわゆる事業会社あるある - ゆでガエル状態 19
Slide 20
Slide 20 text
状況は日に日に悪くなっている気配を感じる 問題の大きさが、各チームが保持するゆとりでは 解決できない大きさになっている Big Ball of Mud 化しつつある 20
Slide 21
Slide 21 text
21 このへんで、銀の弾丸が求められる
Slide 22
Slide 22 text
最近のイキのいい銀の弾丸 - マイクロサービス - モジュラーモノリス というあたりで私は入社しました。(2020年11月) 22
Slide 23
Slide 23 text
@hanhan1978 ● 富所 亮 ● 所属 ○ 株式会社カオナビ ● 肩書 ○ エキスパート (??) ● 役割 ○ マイクロサービス化担当 ○ リアーキテクチャリング担当 23
Slide 24
Slide 24 text
24 弊社における取り組み
Slide 25
Slide 25 text
25 高度な情報戦 https://codezine.jp/article/detail/15176?p=2
Slide 26
Slide 26 text
バズワードは使ってますが、私達は正気です。 手段を目的にしない! 26
Slide 27
Slide 27 text
最近のマイクロサービスについての情報 27
Slide 28
Slide 28 text
- Mercari - Retty - 本イベント 皆様アウトプットしてくれてありがとう... 28
Slide 29
Slide 29 text
コアドメインを含めたマイクロサービス化は、相当の困難が ありそう 集約として切り離しやすそうな機能は事例がチラホラ BFFとかもよく聞く 29
Slide 30
Slide 30 text
マイクロサービス化の結果として縦割り組織ができないか? Customer Success の阻害要因にならないか? 慎重な組織設計も求められる 30
Slide 31
Slide 31 text
マイクロサービス化は、その後の運用 チーム体制、その他考慮することがたくさんある ログどうする?デバッグどうする?結果整合性?とりあえずツラい 31
Slide 32
Slide 32 text
最近のモジュラモノリスについての情報 32
Slide 33
Slide 33 text
33 原点確認 http://www.codingthearchitecture.com/presentations/sa2015-modular-monoliths
Slide 34
Slide 34 text
34 http://www.codingthearchitecture.com/presentations/sa2015-modular-monoliths 分散デカ泥団子
Slide 35
Slide 35 text
モノリスを適切なモジュラー分割できないのは マイクロサービス以前 モジュラーモノリスの実例は、少しずつ出てきている 最近は弊社と同じ境遇の会社がモジューラモノリスに舵を切っている雰囲気を感じ ている 35
Slide 36
Slide 36 text
36 神発表の予感 https://fortee.jp/phperkaigi-2022/proposal/95bc3631-7683-4201-9f82-d7e7feeb7bab PHPerKaigi 2022, 4/9〜11 チケット発売中
Slide 37
Slide 37 text
Reアーキが現在考えていること 37
Slide 38
Slide 38 text
モノリスの複雑化の増大に対して どうやって軽減、改善していくかという構想・妄想 38
Slide 39
Slide 39 text
39 基本の考え方
Slide 40
Slide 40 text
40 モノリスを水平・垂直で考える
Slide 41
Slide 41 text
41 水平の例
Slide 42
Slide 42 text
- 認証 - 通知 - メール送信 - バッチ フレームワークにおいて、ミドルウェアで切り出されるような機能群 コアドメインから疎結合にしやすい AWSのマネージドサービス利用、マイクロサービスとしての分割が現実的 42
Slide 43
Slide 43 text
43 垂直の例
Slide 44
Slide 44 text
- カオナビの各機能単位のソースコード群 - 各機能から使われる共通モジュール - フレームワーク 機能単位では Package By Feature で名前空間・ディレクトリで分割 Composer Package として責務分離することで、全体の認知負荷を軽減 44
Slide 45
Slide 45 text
45 大切にしていること
Slide 46
Slide 46 text
- 既存の価値提供が毀損されないこと - セキュリティ的に脆弱な構成にならないこと - ビッグリライトを避けること できれば、後戻りができる算段をした上で段階的にやりたい 46
Slide 47
Slide 47 text
47 アーキテクトが価値を提供する相手
Slide 48
Slide 48 text
- 顧客・一般ユーザー - 開発者 顧客はもちろん、開発者の開発体験にも寄与したい。 秩序を保ちつつ、チャレンジの余地を残すアーキテクチャーの模索 48
Slide 49
Slide 49 text
49 実際に取り組んでいること
Slide 50
Slide 50 text
- プロトタイピングによる実験 - Composer Package を使ったモジュールの分割 - AST に影響を与えにくいリファクタリング - コメント追加 - メソッド移動、名称変更 - 未使用クラス・メソッドの削除 50
Slide 51
Slide 51 text
- 考古学調査 - Unknown unknown の掘り出しと文書化 - 曖昧な仕様の調査と文書化 - 複雑な仕様の調査と文書化 - とにかく調べて調べて調べて調べて...... 51
Slide 52
Slide 52 text
問題から目をそらさない! 52 地味でも、大切な改善を繰り返す。栄光のゴールはその先に見えてくる!
Slide 53
Slide 53 text
53 https://kaonavi.connpass.com/event/240653/ 来週木曜開催!!
Slide 54
Slide 54 text
54 私と一緒に考古学調査しませんか? https://corp.kaonavi.jp/recruit/list
Slide 55
Slide 55 text
55 ご清聴ありがとうございました。