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