Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

yumechi
September 24, 2022

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

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

yumechi

September 24, 2022
Tweet

More Decks by yumechi

Other Decks in Programming

Transcript

  1. https://www.dip-net.co.jp/
    PHPカンファレンス2022
    2022/09/24
    Motoki Hirao
    2年かけました!大規模サービスを
    Java製CMSからPHP+Laravelの構成
    にリプレイスし、運用している話

    View Slide

  2. https://www.dip-net.co.jp/
    自己紹介 平尾 元紀(ひらお もとき)
    2021年7月dipジョイン
    エンジニア→スクラムマスター(仮)
    PHPカンファレンスやPyCon JPの当日ス
    タッフなどで過去参加してまして、今回現
    地開催なのが久々で新鮮です!

    View Slide

  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サービス

    View Slide

  4. https://www.dip-net.co.jp/
    はたらこねっと
    について
    引用:
    https://www.hatarako.net/kanto/
    https://www.dip-net.co.jp/service

    View Slide

  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

    View Slide

  6. https://www.dip-net.co.jp/
    アーキテクチャ全体像
    6

    View Slide

  7. https://www.dip-net.co.jp/
    今回の発表範囲
    7

    View Slide

  8. https://www.dip-net.co.jp/
    アジェンダ
    8
    • 旧アーキテクチャの課題
    • 新アーキテクチャの構成
    • 人、タスク、スケジュール
    • リリース後の対応
    • 体制変更、そしてアジャイル開発へ
    • 今後にむけて

    View Slide

  9. https://www.dip-net.co.jp/
    9
    旧アーキテクチャの課題

    View Slide

  10. https://www.dip-net.co.jp/
    構成技術
    10
    • 言語はJava、有償ライセンスのCMSを利用
    • EC2上で動作している
    • 元々オンプレミス環境で動いていたものをクラウドリフトした
    • デプロイはJenkinsを利用

    View Slide

  11. https://www.dip-net.co.jp/
    • アプリケーションフロー
    • EC2上に構成したCMSに
    アクセスし、そこから
    Memcached、DB、NFSに
    アクセスしてサイト表示
    を行う
    旧アーキテクチャの構成

    View Slide

  12. https://www.dip-net.co.jp/
    • デプロイフロー
    • Jenkinsを用いて
    手動ローリングデプロイ
    旧アーキテクチャの構成

    View Slide

  13. https://www.dip-net.co.jp/
    言語はJava、
    有償ライセンスのCMSを利用
    13
    • 有償ライセンスなのでローカル環境の構築が困難
    • 開発サーバーでやらざるを得ない
    • コンフリクトを気にする必要があり、開発効率が低下
    • CMSにある独自のDBでもバージョン管理されている
    • gitリポジトリにないビジネスロジックが存在する
    • 見るべきコードが増え運用保守がしずらい

    View Slide

  14. https://www.dip-net.co.jp/
    EC2上で動作している
    14
    • 日時のアクセス頻度に合わせて適切なマシン数でスケー
    ルイン・スケールアウトさせるのが難しい
    • CMSに密結合した構成であったことも影響している
    • ansibleを使った半手動の環境構築であるため、ローカル
    環境の構築を困難にしている
    • 開発効率の低下

    View Slide

  15. https://www.dip-net.co.jp/
    手動デプロイ
    15
    • Jenkinsによる手動ローリングデプロイ
    • 手動で手順が複雑になりがちで、ノウハウに強依存
    • 熟練の技によるデプロイ

    View Slide

  16. https://www.dip-net.co.jp/
    トラブルシューティング
    16
    • 問題があればログの調査が必要
    • ログの調査はサーバーに入ってgrepする形
    • アクセス権限があるメンバーに依頼が必要
    • 熟練の技での想像が必要

    View Slide

  17. https://www.dip-net.co.jp/
    17
    新アーキテクチャの構成

    View Slide

  18. https://www.dip-net.co.jp/
    • アプリケーションフローの改善
    • ECS、Fargateを利用し、
    コンテナ技術を活用
    • サイドカーコンテナで
    ログを各種分析用SaaSへ
    • マネージドサービスも活用
    新アーキテクチャ
    の構成

    View Slide

  19. https://www.dip-net.co.jp/
    • デプロイフローの改善
    • Codeシリーズを利用し、
    コンテナを用いた
    自動デプロイを実現
    新アーキテクチャ
    の構成

    View Slide

  20. https://www.dip-net.co.jp/
    「言語はJava、有償ライセンスの
    CMSを利用」問題について
    20
    • OSSで公開されているフレームワークを活用する
    • 社内でも採用例のあったPHP + Laravel の構成にする
    • メンバー的にもJavaよりPHPの方が馴染みがあった
    • DBに依存しない形でコードを管理し、ビジネスロジック
    に関わるものは全てgit管理する

    View Slide

  21. https://www.dip-net.co.jp/
    「EC2上で動作している」
    問題について
    21
    • Dockerを活用してコンテナ化する
    • 社内で PHP + Laravel の構成でコンテナ化されている事例あり
    • ローカルでの開発も可能になった
    • ECS + Fargate を用いてスケーリングに対応する
    • コンテナ化されているので、マシンの構成がシンプルになった

    View Slide

  22. https://www.dip-net.co.jp/
    「手動デプロイ」問題について
    22
    • AWSのCodeシリーズにより、ほぼ自動デプロイされる
    • GitHub Enterpriseへ特定ブランチをpushした際に、Webhookを用
    いてCodeBuildが動き、自動的にビルドされる
    • ルーティングの切り替えのみを手動で実施し、事前にユーザー
    に提供される機能を確認した上でリリースできる構成

    View Slide

  23. https://www.dip-net.co.jp/
    • 開発者はSaaSからメトリク
    スやログを観測できる
    • これらのサービスにアクセ
    スできれば調査可能
    • 開発者なら誰でも調査をで
    きる状態になった
    「トラブルシューティング」
    問題について

    View Slide

  24. https://www.dip-net.co.jp/
    各種ログ・モニタリングツール
    について
    24
    • DataDog
    • ログの調査、アラートの発行
    • NewRelic
    • 各種画面のメトリクスの計測、生産性の可視化
    • Kibana
    • マーケティングチームでの分析

    View Slide

  25. https://www.dip-net.co.jp/
    ついでに
    25
    • Linterの導入と自動実行
    • PHP Insights を選定 https://phpinsights.com/
    • チームの中でチェックされるルールを明示的にしたいというニーズ
    • Laravelとの相性を考えつつ、既存ビジネスロジックに影響しないような
    ゆるいルールで導入
    • CodeBuildの中で実行される

    View Slide

  26. https://www.dip-net.co.jp/
    ついでに②
    26
    • テストの自動実行
    • Feature Test を導入した
    • 画面ごとの表示(結合テストレベル)を簡易的にテスト
    • 代表的なケースのみ表示ができるかどうかを判定している
    • 全網羅ではない
    • CodeBuildの中で実行される

    View Slide

  27. https://www.dip-net.co.jp/
    人、タスク、スケジュール
    27

    View Slide

  28. https://www.dip-net.co.jp/
    スケジュール
    28
    • 最初のコミットが2020年4月、リリースが2022年4月
    • 2年かかりました
    • ベースとなる処理や代表的な画面を開発し、2021年3月時点のプ
    ロダクトのコードを凍結し、それを参考に実装
    自分の入社↓

    View Slide

  29. https://www.dip-net.co.jp/
    スケジュール続き
    29
    • 2021年3月時点から追加された機能を追いつき実装
    • 12月から4月にかけて移行テストやリハーサルを行い、入念に
    • セキュリティテスト: VAddy
    • 負荷テスト: jmeter

    View Slide

  30. https://www.dip-net.co.jp/
    移植したものの規模など
    30
    • 数百画面単位(PC、スマホそれぞれあるので全画面×2のイメージ)
    • PHPのファイル数
    • 数千単位
    • 元々動いていたコードをベースに移植しつつ、共通処理を整理した
    • テスト数
    • 手動で数万件単位
    • デザイン崩れや通信系のトラッキングなど項目的に人手でなければ難しい問題が
    あり、手動で見る必要があった

    View Slide

  31. https://www.dip-net.co.jp/
    人の変化
    31

    View Slide

  32. https://www.dip-net.co.jp/
    コミュニケーションの変化
    32
    • 20名もいると全員で集まって状況や進捗が共有できない
    • 開発チーム・テストチームに作業分担
    • 報告内容フローを整理
    • リーダーポジションの人がまとめる
    • 朝会の実施

    View Slide

  33. https://www.dip-net.co.jp/
    人の比率の変化
    33

    View Slide

  34. https://www.dip-net.co.jp/
    34
    2022年4月、
    大きな不具合もなく
    無事にリリース
    🎉 🎉 🎉 🎉 🎉

    View Slide

  35. https://www.dip-net.co.jp/
    35
    リリース後の対応

    View Slide

  36. https://www.dip-net.co.jp/
    とにかくシステム安定化優先!
    36
    • 全員体制でエラーアラートや問い合わせ対応する
    • 1〜2週間ほどの期間で対応し切ると決めた
    • 予測しきれない不具合を心配していた

    View Slide

  37. https://www.dip-net.co.jp/
    大きめのトラブル:ログ出力停止
    37
    • DataDogのログ保管制限に引っ掛かっていた
    • https://docs.datadoghq.com/ja/logs/indexes/#日別の割り当てを
    設定する
    • 原因は通信系のInfoログを含めてログを転送していたこと
    • 一旦Infoログ出力を全て中止し、その後見直し

    View Slide

  38. https://www.dip-net.co.jp/
    DataDogでアラート、エラーログ監視
    38
    • エラー数が多いものを優先的に対応
    • 調査への影響が大きい
    • 出力数が多すぎてノイズになる
    • DataDogは検索結果が5000件までしか出力できない
    https://docs.datadoghq.com/ja/logs/explorer/list/
    • すぐ直せるものは直し、Warningに落としても問題ないものはWarningに
    • その後、プロダクトとして問題があるアラートを優先して対応

    View Slide

  39. https://www.dip-net.co.jp/
    39
    エラーログが
    1日数千件→1日百数件程度
    に現在は減りました!
    ※一時期、1日数件まで減ったが、最近通信周りのエラーログ出力を
    厳格にしたところ、少し増えてしまった

    View Slide

  40. https://www.dip-net.co.jp/
    40
    大規模に影響のある不具合も
    出ず、リリース成功した!
    と胸を張って言える状況に
    💪💪💪💪💪

    View Slide

  41. https://www.dip-net.co.jp/
    うまく行った要因
    41
    • 仕様的にノウハウのあるメンバーの活躍
    • 人数増加に伴うコミュニケーションフローの改善
    • 入念で多様なテスト実施、リハーサル
    • ログ、パフォーマンスの可視化

    View Slide

  42. https://www.dip-net.co.jp/
    42
    体制変更、そして
    アジャイル開発へ

    View Slide

  43. https://www.dip-net.co.jp/
    3チーム制に変更する
    43
    • 役割別に分割
    • 中大規模プロジェクトの担当チーム
    • SEO、小規模プロジェクトの担当チーム
    • リファクタリング、アーキテクチャの担当チーム
    • どのチームも社員、パートナー混成チームで4〜8名
    • 内部的にはそれぞれのチームに愛称をつけている

    View Slide

  44. https://www.dip-net.co.jp/
    チームを分断することの影響
    44
    組織図を可視化したり、各チームのメンバー1名以上を選んでPRを出す
    などの工夫をしています

    View Slide

  45. https://www.dip-net.co.jp/
    アジャイル開発への切り替え
    45
    スクラム スクラム ウォーター
    フォール
    引用: いらすとや https://www.irasutoya.com/2020/04/blog-post_53.html

    View Slide

  46. https://www.dip-net.co.jp/
    なぜアジャイル
    46
    • より早い開発の実現のため
    • スクラムガイドの読み合わせや、プロダクト内での役割の認識
    合わせを行う
    • 企画チームとの関係性も築きたい
    • 徐々にプロダクトオーナーからプロダクト方向性や価値を聞き
    ながら、実装方針の相談できる関係に変化しつつある

    View Slide

  47. https://www.dip-net.co.jp/
    大規模スクラム開発フレームワークは
    採用していない
    47
    • LeSS, SAFeなどが複数チーム体制だと上がると思われるが、
    現在は採用していない
    • LeSS: https://less.works/
    • SAFe: https://www.scaledagileframework.com/
    • まずは各チームで自立してスクラムができるようになる

    View Slide

  48. https://www.dip-net.co.jp/
    • 色々な指標をNewRelicの
    EventTypeとして送信して
    お試し中
    • DocBaseの投稿量
    • チームのベロシティ
    • などなど…
    生産性の可視化 with NewRelic

    View Slide

  49. https://www.dip-net.co.jp/
    Unit Testの実装
    49
    • リリース前はFeature Testで進めていた
    • 実行時間が長すぎる
    • 実行時にメモリ消費が大きく、比較的スペックが低いマシンを
    使っているメンバーの手元で実行できなかった
    • 少しずつUnit Testに置き換えていき、実行時間の短縮や関
    数単位での動作保証に切り替えて開発しやすく

    View Slide

  50. https://www.dip-net.co.jp/
    リファクタリングの実施
    50
    • 既存のロジックを参考に実装したため、色々な人が書い
    た色々な書き方が混ざってしまっている
    • 後からLinterを導入したこともあり、甘めの検出になっている
    • PHPやPSRに沿った実装でないことや、ユニットテストが書きづ
    らい問題
    • ユニットテストと並行してリファクタリングを実施中

    View Slide

  51. https://www.dip-net.co.jp/
    51
    今後にむけて

    View Slide

  52. https://www.dip-net.co.jp/
    大きくなっていくチーム体制で、
    うまく開発する
    52
    • 開発者はこれからも増えていく見込みなので、今後もチーム
    体制を見直していきたい
    • スクラムを始めたばかり、ノウハウもこれから
    • なんらかのフレームワーク導入も考えてみる
    • 他システムと合わせてリリースするなど規模が大きくなる対
    応と、SEOなどの早めの対応が混ざる問題
    • コンフリクトが起きやすく、結合テストでの問題の切り分けが難しい

    View Slide

  53. https://www.dip-net.co.jp/
    継続的な環境のアップデート
    53
    • 言語周り
    • PHP、Laravelのアップデートが急務
    • PHPはまだ7.4系なので8系にあげたい
    • リリース時、Laravel6系だったがLaravel8系にあげた。9系にあげたい
    • アーキテクチャ
    • パフォーマンスの可視化促進
    • プロダクトを構成する他システムのコンテナ化

    View Slide

  54. https://www.dip-net.co.jp/
    • プロダクト知識定着
    • 自立に時間がかかっている
    • 属人性も排除したい
    • 他システムとの関係の整理
    • テストコード、カバレッジ、
    Linterルールの厳格化
    などなど…
    その他
    引用: いらすとや https://www.irasutoya.com/2015/03/blog-post_528.html

    View Slide

  55. https://www.dip-net.co.jp/
    まとめ
    55
    • コンテナネイティブなアーキテクチャに変更した
    • 熟練の技に依存していた箇所を置換し、ローカルで開発
    も実現。開発者フレンドリーな環境になった
    • 開発体制と併せてチームメンバーの構成も変更していき、
    動きやすい体制も整えることが大事
    • リプレイスしてからが本当の始まり

    View Slide

  56. https://www.dip-net.co.jp/
    カジュアル面談やってますの
    でお気軽に…
    会場のジョブボードにもあり
    ます!
    もし気になった方は…

    View Slide

  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/

    View Slide