2年かけました！大規模サービスをJava製CMSからPHP+Laravelの構成にリプレイスし、運用している話 / Replaced service from Java CMS to PHP and Laravel architecture

2022/09/24 PHPカンファレンス2022の1日目で発表した資料になります。
（サブタイトル分ですが、SpeakerDeckのURLが非常に長くなってしまうので付与しています。公式に提出させていただいているタイトルとは異なります）

Transcript

1. https://www.dip-net.co.jp/ PHPカンファレンス2022 2022/09/24 Motoki Hirao 2年かけました！大規模サービスを Java製CMSからPHP+Laravelの構成 にリプレイスし、運用している話
2. https://www.dip-net.co.jp/ 自己紹介 平尾 元紀（ひらお もとき） 2021年7月dipジョイン エンジニア→スクラムマスター（仮） PHPカンファレンスやPyCon JPの当日ス タッフなどで過去参加してまして、今回現 地開催なのが久々で新鮮です！
3. https://www.dip-net.co.jp/ ディップ株式会社について 3 ビジョン：Labor force solution company 人材サービスとDXサービスの提供を通して、労働市場における諸課題を解決し、誰もが働く 喜びと幸せを感じられる社会の実現を目指します。 引用： https://www.dip-net.co.jp/company/philosophy https://www.dip-net.co.jp/service 人材サービス DXサービス
4. https://www.dip-net.co.jp/ はたらこねっと について 引用： https://www.hatarako.net/kanto/ https://www.dip-net.co.jp/service
5. https://www.dip-net.co.jp/ サービス概要 5 • 社員・派遣・パートを探す求職者と求人企業を繋ぐ求人 サイト、「自分らしくはたらく」ことを実現する • プロダクトイン：2000/10/01〜 • 旧アーキテクチャ：2013/10〜2022/04、10年弱稼働 • 新アーキテクチャ：2022/04〜 引用： https://www.dip-net.co.jp/news/?category=all&year=2000&month=all
6. https://www.dip-net.co.jp/ アーキテクチャ全体像 6
7. https://www.dip-net.co.jp/ 今回の発表範囲 7
8. https://www.dip-net.co.jp/ アジェンダ 8 • 旧アーキテクチャの課題 • 新アーキテクチャの構成 • 人、タスク、スケジュール • リリース後の対応 • 体制変更、そしてアジャイル開発へ • 今後にむけて
9. https://www.dip-net.co.jp/ 9 旧アーキテクチャの課題
10. https://www.dip-net.co.jp/ 構成技術 10 • 言語はJava、有償ライセンスのCMSを利用 • EC2上で動作している • 元々オンプレミス環境で動いていたものをクラウドリフトした • デプロイはJenkinsを利用
11. https://www.dip-net.co.jp/ • アプリケーションフロー • EC2上に構成したCMSに アクセスし、そこから Memcached、DB、NFSに アクセスしてサイト表示 を行う 旧アーキテクチャの構成
12. https://www.dip-net.co.jp/ • デプロイフロー • Jenkinsを用いて 手動ローリングデプロイ 旧アーキテクチャの構成
13. https://www.dip-net.co.jp/ 言語はJava、 有償ライセンスのCMSを利用 13 • 有償ライセンスなのでローカル環境の構築が困難 • 開発サーバーでやらざるを得ない • コンフリクトを気にする必要があり、開発効率が低下 • CMSにある独自のDBでもバージョン管理されている • gitリポジトリにないビジネスロジックが存在する • 見るべきコードが増え運用保守がしずらい
14. https://www.dip-net.co.jp/ EC2上で動作している 14 • 日時のアクセス頻度に合わせて適切なマシン数でスケー ルイン・スケールアウトさせるのが難しい • CMSに密結合した構成であったことも影響している • ansibleを使った半手動の環境構築であるため、ローカル 環境の構築を困難にしている • 開発効率の低下
15. https://www.dip-net.co.jp/ 手動デプロイ 15 • Jenkinsによる手動ローリングデプロイ • 手動で手順が複雑になりがちで、ノウハウに強依存 • 熟練の技によるデプロイ
16. https://www.dip-net.co.jp/ トラブルシューティング 16 • 問題があればログの調査が必要 • ログの調査はサーバーに入ってgrepする形 • アクセス権限があるメンバーに依頼が必要 • 熟練の技での想像が必要
17. https://www.dip-net.co.jp/ 17 新アーキテクチャの構成
18. https://www.dip-net.co.jp/ • アプリケーションフローの改善 • ECS、Fargateを利用し、 コンテナ技術を活用 • サイドカーコンテナで ログを各種分析用SaaSへ • マネージドサービスも活用 新アーキテクチャ の構成
19. https://www.dip-net.co.jp/ • デプロイフローの改善 • Codeシリーズを利用し、 コンテナを用いた 自動デプロイを実現 新アーキテクチャ の構成
20. https://www.dip-net.co.jp/ 「言語はJava、有償ライセンスの CMSを利用」問題について 20 • OSSで公開されているフレームワークを活用する • 社内でも採用例のあったPHP + Laravel の構成にする • メンバー的にもJavaよりPHPの方が馴染みがあった • DBに依存しない形でコードを管理し、ビジネスロジック に関わるものは全てgit管理する
21. https://www.dip-net.co.jp/ 「EC2上で動作している」 問題について 21 • Dockerを活用してコンテナ化する • 社内で PHP + Laravel の構成でコンテナ化されている事例あり • ローカルでの開発も可能になった • ECS + Fargate を用いてスケーリングに対応する • コンテナ化されているので、マシンの構成がシンプルになった
22. https://www.dip-net.co.jp/ 「手動デプロイ」問題について 22 • AWSのCodeシリーズにより、ほぼ自動デプロイされる • GitHub Enterpriseへ特定ブランチをpushした際に、Webhookを用 いてCodeBuildが動き、自動的にビルドされる • ルーティングの切り替えのみを手動で実施し、事前にユーザー に提供される機能を確認した上でリリースできる構成
23. https://www.dip-net.co.jp/ • 開発者はSaaSからメトリク スやログを観測できる • これらのサービスにアクセ スできれば調査可能 • 開発者なら誰でも調査をで きる状態になった 「トラブルシューティング」 問題について
24. https://www.dip-net.co.jp/ 各種ログ・モニタリングツール について 24 • DataDog • ログの調査、アラートの発行 • NewRelic • 各種画面のメトリクスの計測、生産性の可視化 • Kibana • マーケティングチームでの分析
25. https://www.dip-net.co.jp/ ついでに 25 • Linterの導入と自動実行 • PHP Insights を選定 https://phpinsights.com/ • チームの中でチェックされるルールを明示的にしたいというニーズ • Laravelとの相性を考えつつ、既存ビジネスロジックに影響しないような ゆるいルールで導入 • CodeBuildの中で実行される
26. https://www.dip-net.co.jp/ ついでに② 26 • テストの自動実行 • Feature Test を導入した • 画面ごとの表示（結合テストレベル）を簡易的にテスト • 代表的なケースのみ表示ができるかどうかを判定している • 全網羅ではない • CodeBuildの中で実行される
27. https://www.dip-net.co.jp/ 人、タスク、スケジュール 27
28. https://www.dip-net.co.jp/ スケジュール 28 • 最初のコミットが2020年4月、リリースが2022年4月 • 2年かかりました • ベースとなる処理や代表的な画面を開発し、2021年3月時点のプ ロダクトのコードを凍結し、それを参考に実装 自分の入社↓
29. https://www.dip-net.co.jp/ スケジュール続き 29 • 2021年3月時点から追加された機能を追いつき実装 • 12月から4月にかけて移行テストやリハーサルを行い、入念に • セキュリティテスト: VAddy • 負荷テスト: jmeter
30. https://www.dip-net.co.jp/ 移植したものの規模など 30 • 数百画面単位（PC、スマホそれぞれあるので全画面×2のイメージ） • PHPのファイル数 • 数千単位 • 元々動いていたコードをベースに移植しつつ、共通処理を整理した • テスト数 • 手動で数万件単位 • デザイン崩れや通信系のトラッキングなど項目的に人手でなければ難しい問題が あり、手動で見る必要があった
31. https://www.dip-net.co.jp/ 人の変化 31
32. https://www.dip-net.co.jp/ コミュニケーションの変化 32 • 20名もいると全員で集まって状況や進捗が共有できない • 開発チーム・テストチームに作業分担 • 報告内容フローを整理 • リーダーポジションの人がまとめる • 朝会の実施
33. https://www.dip-net.co.jp/ 人の比率の変化 33
34. https://www.dip-net.co.jp/ 34 2022年4月、 大きな不具合もなく 無事にリリース 🎉 🎉 🎉 🎉 🎉
35. https://www.dip-net.co.jp/ 35 リリース後の対応
36. https://www.dip-net.co.jp/ とにかくシステム安定化優先！ 36 • 全員体制でエラーアラートや問い合わせ対応する • １〜２週間ほどの期間で対応し切ると決めた • 予測しきれない不具合を心配していた
37. https://www.dip-net.co.jp/ 大きめのトラブル：ログ出力停止 37 • DataDogのログ保管制限に引っ掛かっていた • https://docs.datadoghq.com/ja/logs/indexes/#日別の割り当てを 設定する • 原因は通信系のInfoログを含めてログを転送していたこと • 一旦Infoログ出力を全て中止し、その後見直し
38. https://www.dip-net.co.jp/ DataDogでアラート、エラーログ監視 38 • エラー数が多いものを優先的に対応 • 調査への影響が大きい • 出力数が多すぎてノイズになる • DataDogは検索結果が5000件までしか出力できない https://docs.datadoghq.com/ja/logs/explorer/list/ • すぐ直せるものは直し、Warningに落としても問題ないものはWarningに • その後、プロダクトとして問題があるアラートを優先して対応
39. https://www.dip-net.co.jp/ 39 エラーログが 1日数千件→1日百数件程度 に現在は減りました！ ※一時期、1日数件まで減ったが、最近通信周りのエラーログ出力を 厳格にしたところ、少し増えてしまった
40. https://www.dip-net.co.jp/ 40 大規模に影響のある不具合も 出ず、リリース成功した！ と胸を張って言える状況に 💪💪💪💪💪
41. https://www.dip-net.co.jp/ うまく行った要因 41 • 仕様的にノウハウのあるメンバーの活躍 • 人数増加に伴うコミュニケーションフローの改善 • 入念で多様なテスト実施、リハーサル • ログ、パフォーマンスの可視化
42. https://www.dip-net.co.jp/ 42 体制変更、そして アジャイル開発へ
43. https://www.dip-net.co.jp/ 3チーム制に変更する 43 • 役割別に分割 • 中大規模プロジェクトの担当チーム • SEO、小規模プロジェクトの担当チーム • リファクタリング、アーキテクチャの担当チーム • どのチームも社員、パートナー混成チームで４〜８名 • 内部的にはそれぞれのチームに愛称をつけている
44. https://www.dip-net.co.jp/ チームを分断することの影響 44 組織図を可視化したり、各チームのメンバー1名以上を選んでPRを出す などの工夫をしています
45. https://www.dip-net.co.jp/ アジャイル開発への切り替え 45 スクラム スクラム ウォーター フォール 引用： いらすとや https://www.irasutoya.com/2020/04/blog-post_53.html
46. https://www.dip-net.co.jp/ なぜアジャイル 46 • より早い開発の実現のため • スクラムガイドの読み合わせや、プロダクト内での役割の認識 合わせを行う • 企画チームとの関係性も築きたい • 徐々にプロダクトオーナーからプロダクト方向性や価値を聞き ながら、実装方針の相談できる関係に変化しつつある
47. https://www.dip-net.co.jp/ 大規模スクラム開発フレームワークは 採用していない 47 • LeSS, SAFeなどが複数チーム体制だと上がると思われるが、 現在は採用していない • LeSS: https://less.works/ • SAFe: https://www.scaledagileframework.com/ • まずは各チームで自立してスクラムができるようになる
48. https://www.dip-net.co.jp/ • 色々な指標をNewRelicの EventTypeとして送信して お試し中 • DocBaseの投稿量 • チームのベロシティ • などなど… 生産性の可視化 with NewRelic
49. https://www.dip-net.co.jp/ Unit Testの実装 49 • リリース前はFeature Testで進めていた • 実行時間が長すぎる • 実行時にメモリ消費が大きく、比較的スペックが低いマシンを 使っているメンバーの手元で実行できなかった • 少しずつUnit Testに置き換えていき、実行時間の短縮や関 数単位での動作保証に切り替えて開発しやすく
50. https://www.dip-net.co.jp/ リファクタリングの実施 50 • 既存のロジックを参考に実装したため、色々な人が書い た色々な書き方が混ざってしまっている • 後からLinterを導入したこともあり、甘めの検出になっている • PHPやPSRに沿った実装でないことや、ユニットテストが書きづ らい問題 • ユニットテストと並行してリファクタリングを実施中
51. https://www.dip-net.co.jp/ 51 今後にむけて
52. https://www.dip-net.co.jp/ 大きくなっていくチーム体制で、 うまく開発する 52 • 開発者はこれからも増えていく見込みなので、今後もチーム 体制を見直していきたい • スクラムを始めたばかり、ノウハウもこれから • なんらかのフレームワーク導入も考えてみる • 他システムと合わせてリリースするなど規模が大きくなる対 応と、SEOなどの早めの対応が混ざる問題 • コンフリクトが起きやすく、結合テストでの問題の切り分けが難しい
53. https://www.dip-net.co.jp/ 継続的な環境のアップデート 53 • 言語周り • PHP、Laravelのアップデートが急務 • PHPはまだ7.4系なので8系にあげたい • リリース時、Laravel6系だったがLaravel8系にあげた。9系にあげたい • アーキテクチャ • パフォーマンスの可視化促進 • プロダクトを構成する他システムのコンテナ化
54. https://www.dip-net.co.jp/ • プロダクト知識定着 • 自立に時間がかかっている • 属人性も排除したい • 他システムとの関係の整理 • テストコード、カバレッジ、 Linterルールの厳格化 などなど… その他 引用： いらすとや https://www.irasutoya.com/2015/03/blog-post_528.html
55. https://www.dip-net.co.jp/ まとめ 55 • コンテナネイティブなアーキテクチャに変更した • 熟練の技に依存していた箇所を置換し、ローカルで開発 も実現。開発者フレンドリーな環境になった • 開発体制と併せてチームメンバーの構成も変更していき、 動きやすい体制も整えることが大事 • リプレイスしてからが本当の始まり
56. https://www.dip-net.co.jp/ カジュアル面談やってますの でお気軽に… 会場のジョブボードにもあり ます！ もし気になった方は…
57. https://www.dip-net.co.jp/ ロゴの使用情報 57 • drawio https://app.diagrams.net/ • Kibana https://www.elastic.co/jp/kibana/ • Jenkins https://jenkins.io/ • New Relic https://newrelic.com • AWS https://aws.amazon.com/jp/architecture/icons/