Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PHPアプリの品質を(ある程度)保つために出来る事 〜組織編〜

4,767 views

Published on

PHPカンファレンス2017の登壇資料です

Published in: Engineering
  • Be the first to comment

PHPアプリの品質を(ある程度)保つために出来る事 〜組織編〜

  1. 1. PHPアプリの品質を(ある程度)   保つために出来る事 〜~組織編〜~ PHP  カンファレンス  2017   2017/10/08   株式会社  サイバード   三浦  克浩
  2. 2. ⾃自⼰己紹介 • 名前:三浦  克浩   • Twitter  ID:@MiuraKatsu   • 仕事:恋愛ゲーム   • 好きなフレームワーク: Laravel、Sails.js   • 浦和レッズ:
  3. 3. ⼥女性向け恋愛ノベルゲーム
  4. 4. • シリーズ  通算14タイトル   • 海外展開  5カ国  6タイトル   • シリーズ以外  4タイトル   • 展開プラットフォーム  14プラットフォーム ⼥女性向け恋愛ノベルゲーム
  5. 5. 前提 • 新規開発じゃなくて、既存運⽤用の話   • ソシャゲ運⽤用=毎⽉月なんかしらイベントがある   • サーバサイド(PHP)の話中⼼心   • コードをどう変えるか?じゃなくて変えるため に何をしたのか?
  6. 6. • タイトル毎に運⽤用チー ム   • それぞれチームリーダ とメンバー   • 1チーム3〜~6⼈人   • 海外は別チームの場合 も 全体で50〜~80⼈人のエンジニア
  7. 7. 神クラス ハイクラス 新卒   PHP3ヶ⽉月⽬目 PHPerにも神はいる
  8. 8. 品質をよくするには? • 神がコードを書けば品質が良くなる • 神がコードレビューをすれば品質が良くなる • 神だけがコードを書けば品質が良くなる • 神がコードを書いた部分だけ品質が良くなる • 神がすべてのコードレビューをすれば品質が 良くなる
  9. 9. 「神頼み」 そ れ で も 神 な ら し て く れ る 神 な ら な ん と か
  10. 10. 突然の退職 新規⼤大型タイトル開発に引 き抜かれる 「神は死んだ!」
  11. 11. 「神頼み」からの脱却 仕組み化
  12. 12. 何をしたか? • 横断チームの新設   • 開発運⽤用サイクルの改善   • 品質評価軸の可視化   • 専⾨門チームの組成
  13. 13. • 特定タイトルにつかない 横断チーム
  14. 14. 横断チームの役割 • 共通系システムの維持メンテ   • 各チーム間の交流のHub   • ⽇日々のカイゼンだけではできないことをする
  15. 15. 何をしたか? • 横断チームの新設   • 開発運⽤用サイクルの改善   • 品質評価軸の可視化   • 専⾨門チームの組成
  16. 16. Development   -‐‑‒ VCS(Git)によるソース管理   Deploy   -‐‑‒  ⾃自動デプロイ Service  Monitoring   -‐‑‒ ステータス監視   開発運⽤用サイクルの改善 横断チームが仕組み導⼊入
  17. 17. Development   -‐‑‒ VCS(Git)によるソース管理   -‐‑‒ Pull  Request  運⽤用   Code  Check    -‐‑‒  コードレビュー    -‐‑‒  コーディング規約   Deploy   -‐‑‒  ⾃自動デプロイ Service  Monitoring   -‐‑‒ ステータス監視   -‐‑‒ パフォーマンス監視   開発運⽤用サイクルの改善
  18. 18. Development   -‐‑‒ VCS(Git)によるソース管理   -‐‑‒ Pull  Request  運⽤用   Code  Check    -‐‑‒  コードレビュー    -‐‑‒  コーディング規約   Test   -‐‑‒ Syntax  チェック   -‐‑‒ ユニットテスト   -‐‑‒ 継続的インテグレーション Deploy   -‐‑‒  ⾃自動デプロイ Service  Monitoring   -‐‑‒ ステータス監視   -‐‑‒ パフォーマンス監視   開発運⽤用サイクルの改善 ユニットテストよりCIが先
  19. 19. Development   -‐‑‒ VCS(Git)によるソース管理   -‐‑‒ Pull  Request  運⽤用   Code  Check    -‐‑‒  コードレビュー    -‐‑‒  コーディング規約    -‐‑‒  静的解析 Test   -‐‑‒ Syntax  チェック   -‐‑‒ ユニットテスト   -‐‑‒ 継続的インテグレーション Deploy   -‐‑‒  ⾃自動デプロイ Service  Monitoring   -‐‑‒ ステータス監視   -‐‑‒ パフォーマンス監視   -‐‑‒ プロファイリング 開発運⽤用サイクルの改善
  20. 20. •運⽤用チームで取り組みづらい事を横断チームが 仕組み化・⾃自動化   •⾃自動化できたところに乗っかってもらう     →導⼊入コストを下げる   •横断チームが作ることで標準化される   •あるんだから使ってよね、というプレッシャー   開発運⽤用サイクルの改善
  21. 21. GitHubでソース管理する   →PullReq運⽤用ができる   →→PullReqがくるからコードレビューする   ⾃自動デプロイする   →デプロイの前にCIが回せる   →→CIが回るからユニットテスト書く 開発運⽤用サイクルの改善 • 仕組みを⼊入れることで⾏行動が変わる
  22. 22. 巻き込み⽅方 ユニットテスト   回したいんです ⼯工数が余計 にかかるからダ メ
  23. 23. 巻き込み⽅方 振り返り/KPT バックログ/タスク化 バグチケットヒヤリ・ハット 何が防げるかを理解してもらう
  24. 24. 巻き込み⽅方 障害発⽣生! 再発防⽌止策 障害報告書 ここに盛り込む ピンチをチャンスに!
  25. 25. 何をしたか? • 横断チームの新設   • 開発運⽤用サイクルの改善   • 品質評価軸の可視化   • 専⾨門チームの組成
  26. 26. 品質を定義する • サービス的な品質:レスポンスが早い。サーバ 負荷が軽い。   • コード的な品質:静的解析のスコアが⾼高い。テ ストカバレッジが⾼高い。 数値化できるものを計測する
  27. 27. 品質評価軸の可視化 • 評価軸をチーム(タイトル)毎に可視化して公開   • 静的解析スコア/テストカバレッジ/スロークエリー 発⽣生数/レスポンスタイム/etc   • ⾃自チームの数字が⾒見えるようになる:     →⾃自分事になる   • 他チームの数字が⾒見えるようになる:     →勝⼿手に競い合う
  28. 28. サービス的な評価軸計測 • Zabbix  :統合監視ツール。計測値の可視化   • NewRelic:SaaS型パフォーマンス監視(有料)   • Monyog:MySQLモニタリングツール(有料) パフォーマンス監視&プロファイリング
  29. 29. コード的な評価軸計測 • Scrutinizer:静的解析SaaS(有料)   • SonarQube:静的解析ツール   • Coveralls:カバレッジレポート(有料) 単純に⾼高ければ⾼高評価でもない   古いタイトルには負の遺産も多い   変化を⾒見ている
  30. 30. 可視化 • Zabbix/NewRelic:時系列でグラフ表⽰示   • Chatwork:Alert/CI結果を通知   • Wiki:バッチリスト。こんなやつ→
  31. 31. 何をしたか? • 横断チームの新設   • 開発運⽤用サイクルの改善   • 品質評価軸の可視化   • 専⾨門チームの組成
  32. 32. 優先度 • レスポンスが早くなると、売上は上がる   • スコアが上がっても、売上は上がらない まずはサービス品質の改善から
  33. 33. サービス的な改善 とにかくボトルネックを潰す   DBボトルネックが6割強   スロークエリーの撲滅
  34. 34. • インフラチーム   • インフラチーム内にDBA
  35. 35. SQL道場 • 毎週DBAによるSQL指導   • 今週発⽣生したスロークエリー数の報告   • 今週発⽣生したイケてないクエリーについての 指導
  36. 36. ORMの功罪 • PHPerにはSQLが分からぬ   • かならずDB操作をしなければならぬ   • 功:PHPerでもDB操作ができる!   • 罪:どんなクエリが吐かれるか、吐いてみない と分からない
  37. 37. DBAとの対話 • DBAはクエリーしか⾒見ない   • プログラムの内容は知らない   • ゲーム仕様も知らない   • 開発者の⾔言い訳に同情しない
  38. 38. インフラ担当との対話 • インフラはサーバ負荷しか⾒見ない   • 負荷理由(exイベント開始)を知らない   • サーバ増はコスト増   • 開発者の⾔言い訳に同情しない
  39. 39. 道場開設当初 こんなクソクエリー書いたのは誰だ! インスタンスタイプ上げると   毎時xx円コストが上がるんだよ! なんで⽇日またぎのバッチと   イベントフィーバー被せるんだよ! オンプレだからサーバ増やせないっ て⾔言っただろ! スロークエリー数:閾値10s超で数百件 ボコボコにされるPHPer
  40. 40. 現在(開設から2年) スロークエリー数:閾値0.5sで数件まで削減 PKでしか検索かけてないのにスロークエリーにな るということはDiskアクセス発⽣生してませんか キャッシュ周りのパラメータを⾒見直して みましょう 現在のままのサーバスペックでは、次回イベント 時の負荷に耐えられないかもしれません。 新しいサーバで、負荷テストして⾒見ましょう
  41. 41. 改善⽅方法はひとつじゃない • クエリーを修正する   • プログラムを修正する   • サーバをスケールアウト/スケールアップする   • RDBからKVSに切替える   • ゲーム仕様を変更する
  42. 42. いろんな⼈人を巻き込む ステークホルダー/専⾨門家じゃないと   解決できない事もある
  43. 43. まとめ • 運⽤用だからカイゼンできる   • 仕組みを変えると⾏行動が変わる   • 「推測するな。計測せよ」   • ⾒見える化⼤大事   • 開発者以外を巻き込む
  44. 44. 新規開発も既存運⽤用も   エンジニア募集中
  45. 45. ご清聴ありがとうございました。

×