Chatworkのシステムから学ぶレガシーなPHPの限界とレガシーからの脱却
2019/12/1 10:59
https://youtu.be/M04-F3e3u6I
画面が切れるトラブル
自己紹介
ISUCON2019 PHPで4位
Agenda
レガシーの説明
バックエンド構成
レガシーなPHPの限界
レガシーからの脱却
この発表でのレガシーとは
色んな本でちょっとづつ違う
修正・拡張・作業・が難しいコード
Chatworkのシステム
PHPがmicroserviceにアクセスしてる
4桁rps
レスポンスは30-200ms
サーバサイド
PHP
よくあるレガシー
10年前に作られたオレオレFW
いろんな思想が地層になっている
Scala
Microservicesチック
会社としてマイサーにしているわけではない
分散システム思考
リアクティブにしている
CQRS
EventSoursing
どうして2つある？
CTOが2年前に書いた記事
PHP -> Scala移行してる
まだまだぜんぜんPHP
PHPアプリのツラミ
１万行のUtilクラス
オレオレFW
静的解析ツールの適用がむずい
責務が入り混じっている
テストが責務を満たしてるか
テストがあってもリファクタはむずい
2年前にこの発表があったのできになったらみてね
静的解析ツールためしてみた
PHPStan
Phan
php5のコードがあって終了した
PHPMetrics
動いた
依存関係を表す図を作ってみた
「人が触るもんじゃない」
どうしてこうなった？
曖昧な仕様 on 曖昧な仕様
Scala化にパフォーマンス上の都合で失敗した
書き直しのScalaのコードがPHPの現役コードに引きづられる
困難な変更
大規模変更が困難
同期処理を非同期処理をいれるのは
デカルト「困難を分割せよ」
でも分割自体もむずい
DBの分割
WebサーバとDBサーバのスケール戦略(一般的な話)
ユーザが増えるとアプリが詰まる
PHPはスケールアウトが簡単。横に並べればよい
DBはスケールアウトできないのでスケールアップする。スケールアップは高いのでお金がなくなる
問題点は？
サービス規模にPHPがあってない
DBのコネクションプールがほしい
nK/rpsを同期処理の言語で処理するのが厳しい
JVM, Go, ErlangVMが適切
PHPは遅くもないし悪くもない
自社製FWも遅くはない（DIとか欲しい機能はないが）
Laravel(重厚なフレームワーク)にしてもrps捌けない
レガシーからの脱却
この辺りから組織論とか開発体制の話になるkadoyau.icon 開発者を増やしても生産性が上がらない
コンフリクトする
暗黙知
システムとして求められているもの
メッセージシステムを使ってそれぞれを担保する
katojunさん発表
スケールアウト
システムだけしてもだめ
例：マイクロサービスにしたらシステムが増えて1人が何個も見ないといけなくなった
micrsoservicesもつらいときく。そっちをやるのか検討している
組織構造
ヒエラルキー型になっている
発表者はこの構造が嫌いなので離れたい
問題点
チーム間の話がマネージャー経由で話をしないといけない
横のチームと会話ができない
role baseの自立したチーム
ねらい：横のチームで会話が必要なのを同じチームにすれば会話できて解決
いきなりこれにはできないので検討中
10ヶ月ぐらいやってきた
移行計画、PoC
現状
ドメインモデリングのクラス図
前：依存関係が不明
あと：上から見れば良くなった
これから
まとめ
PHPはプロセス単位で動いて簡単にスケールアウトする
周辺ツールの限界値がPHPの限界
メンテできないんだけど？のほうが早い
要求性能がめっちゃ高まってる大規模サービス
刷新が厳しい。要件定義だけで10ヶ月とかかかる
ビジネス規模に合わせて適切なタイミングでリライトしたりして