Tweet
Tweet

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/