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