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