長期運用を支える Platform Engineering

＼積極的に技術発信を行なっております／

▽ Twitter/COLOPL_Tech
https://twitter.com/colopl_tech

▽ connpassページ
http://colopl.connpass.com

▽ COLOPL Tech Blog
http://blog.colopl.dev

Transcript

1. 長期運用を支える Platform Engineering 工藤 剛
2. 2 2017 年新卒として入社、運用タイトルのサーバーエンジニアを経て SRE チームを経て PE (Platform Engineering) チームへ 主にミドルウェアの更新対応やアプリケーションの保守性向上などに 取り組んでいる PHP が結構好き 氏名　 ： 部署名 ： 自己紹介 工藤 剛 技術基盤本部 第 3 バックエンドエンジニア部 サーバー基盤グループ SREチーム PE チーム
3. 3 今日話す内容
4. Platform Engineering とは 4
5. わからん 5
6. 6 ChatGPT に聞いてみた
7. 7 長いので要約してもらった > 開発者が効率的に働ける環境を提供するエンジニアリング これだ！
8. 抱えている 課題の整理 8
9. • 速度と質のバランスがとても難しい ◦ 理想はもちろんテストコードがしっかりと書かれていること ◦ 猛烈な PDCA サイクルが求められる ▪ "試してみないとわからない" ことがとにかく多い！ • 度重なるスクラップアンドビルド... ◦ テストを書いてもいつの間にか負債になる悪循環... • 速度を優先したばかりに保守性が低下していく悪循環 ◦ 新機能の開発にかかる工数が膨大化 ◦ 修正が意図しない箇所に影響 ◦ 後に保守する人がつらい思いをすることに 9 課題1: ゲームアプリケーションであるということ
10. • サポート対象バージョンに追従する難しさ ◦ 特に PHP は破壊的変更が多い ◦ 前述の通り、テストも完全にカバーできているとは言い切れない ◦ "次の次" に非推奨になるコードが新たに書かれることもある... • "お行儀の悪いコード" への対応がままならない ◦ "今は動くが、将来的に非推奨になるようなコード" がレビューをすり抜けてしまう ▪ "${variableName}" 等 • 荒ぶる E_DEPRECATED ◦ 一人ですべてのコードをレビューするわけにもいかない 10 課題2: ミドルウェア更新への追従
11. • "暗黙の約束" がどんどん増えていく ◦ 例: 引数に string 以外を渡しちゃダメだから "(string) 123" でキャストしてね ◦ 気付きようもないので新規にアサインされた人が罠を踏んでしまう • プロジェクトによって異なるお作法が生まれてしまう ◦ プロジェクト間のコンテキストスイッチが大変 ▪ array vs Collection ▪ JSON vs YAML ▪ Tab vs Space ▪ CSV vs TSV 11 課題3: 運用でカバーしてほしくない
12. 昨今の PHP には強力な静的解析ツールが揃っている • PHPStan https://phpstan.org/ • Psalm https://psalm.dev/ また、静的解析結果を元にコードを自動修正 (リファクタ) するツールもある • Rector https://getrector.org/ • PHP-CS-Fixer https://cs.symfony.com/ これらの活用を自ら推進・普及していく でも、そもそも静的解析って何？ 12 静的解析
13. 13 ChatGPT (GPT-4) くんが説く静的解析の魅力
14. "社内のサーバーエンジニアの共通認識" をPHPStan のルールにして共有 例: • mt_srand / mt_rand 関数の使用を検出 ◦ なぜダメなのか: https://zenn.dev/zeriyoshi/articles/abd808d1c6d31b • 浮動小数点数丸め誤差の起きる数値演算を検出 • etc... 14 PHPStan の活用
15. 警告だけじゃなくて 修正も自動で やりたい 15
16. Rector の活用 方法がわかってるなら修正まで自動でやっちゃえば良い https://github.com/colopl/php-colopl_bc/blob/main/tests/Rector/Equal/EqualToBCMigrateRector/Fixture/basic_replace_op erator.php.inc 16
17. 新たな問題 17
18. 18 静的解析が 重すぎる
19. レベル (スペック) を上げて物理で殴る 19
20. • 消費リソース的にローカルで実行しておくのは困難 ◦ GitLab CI を用いて実行することに ▪ キャッシュが適切に利用できないので強いインスタンスで対応 ▪ インスタンススペックでゴリ押し 20 CI パイプラインの整備
21. それでも無理な 非互換が... 21
22. colopl_bc Extension https://github.com/colopl/php-colopl_bc どうしても対応できない PHP の非互換に対応するための PHP Extension 詳細は COLOPL Tech Blog にて近日中に書きます 22
23. • 保守性向上には静的解析が有用 ◦ 必要であればルールを自作しイレギュラーの発生を抑制 • 継続的インテグレーションは大切 ◦ 性善説に基づく "ローカルで実行" は現実的ではない • いざとなったら低レイヤーで対応 ◦ 自分たちの使っている技術スタックを深く理解しておく 23 まとめ