Slide 1

Slide 1 text

長期運用を支える Platform Engineering 工藤 剛

Slide 2

Slide 2 text

2 2017 年新卒として入社、運用タイトルのサーバーエンジニアを経て SRE チームを経て PE (Platform Engineering) チームへ 主にミドルウェアの更新対応やアプリケーションの保守性向上などに 取り組んでいる PHP が結構好き 氏名  : 部署名 : 自己紹介 工藤 剛 技術基盤本部 第 3 バックエンドエンジニア部 サーバー基盤グループ SREチーム PE チーム

Slide 3

Slide 3 text

3 今日話す内容

Slide 4

Slide 4 text

Platform Engineering とは 4

Slide 5

Slide 5 text

わからん 5

Slide 6

Slide 6 text

6 ChatGPT に聞いてみた

Slide 7

Slide 7 text

7 長いので要約してもらった > 開発者が効率的に働ける環境を提供するエンジニアリング これだ!

Slide 8

Slide 8 text

抱えている 課題の整理 8

Slide 9

Slide 9 text

● 速度と質のバランスがとても難しい ○ 理想はもちろんテストコードがしっかりと書かれていること ○ 猛烈な PDCA サイクルが求められる ■ "試してみないとわからない" ことがとにかく多い! ● 度重なるスクラップアンドビルド... ○ テストを書いてもいつの間にか負債になる悪循環... ● 速度を優先したばかりに保守性が低下していく悪循環 ○ 新機能の開発にかかる工数が膨大化 ○ 修正が意図しない箇所に影響 ○ 後に保守する人がつらい思いをすることに 9 課題1: ゲームアプリケーションであるということ

Slide 10

Slide 10 text

● サポート対象バージョンに追従する難しさ ○ 特に PHP は破壊的変更が多い ○ 前述の通り、テストも完全にカバーできているとは言い切れない ○ "次の次" に非推奨になるコードが新たに書かれることもある... ● "お行儀の悪いコード" への対応がままならない ○ "今は動くが、将来的に非推奨になるようなコード" がレビューをすり抜けてしまう ■ "${variableName}" 等 ● 荒ぶる E_DEPRECATED ○ 一人ですべてのコードをレビューするわけにもいかない 10 課題2: ミドルウェア更新への追従

Slide 11

Slide 11 text

● "暗黙の約束" がどんどん増えていく ○ 例: 引数に string 以外を渡しちゃダメだから "(string) 123" でキャストしてね ○ 気付きようもないので新規にアサインされた人が罠を踏んでしまう ● プロジェクトによって異なるお作法が生まれてしまう ○ プロジェクト間のコンテキストスイッチが大変 ■ array vs Collection ■ JSON vs YAML ■ Tab vs Space ■ CSV vs TSV 11 課題3: 運用でカバーしてほしくない

Slide 12

Slide 12 text

昨今の PHP には強力な静的解析ツールが揃っている ● PHPStan https://phpstan.org/ ● Psalm https://psalm.dev/ また、静的解析結果を元にコードを自動修正 (リファクタ) するツールもある ● Rector https://getrector.org/ ● PHP-CS-Fixer https://cs.symfony.com/ これらの活用を自ら推進・普及していく でも、そもそも静的解析って何? 12 静的解析

Slide 13

Slide 13 text

13 ChatGPT (GPT-4) くんが説く静的解析の魅力

Slide 14

Slide 14 text

"社内のサーバーエンジニアの共通認識" をPHPStan のルールにして共有 例: ● mt_srand / mt_rand 関数の使用を検出 ○ なぜダメなのか: https://zenn.dev/zeriyoshi/articles/abd808d1c6d31b ● 浮動小数点数丸め誤差の起きる数値演算を検出 ● etc... 14 PHPStan の活用

Slide 15

Slide 15 text

警告だけじゃなくて 修正も自動で やりたい 15

Slide 16

Slide 16 text

Rector の活用 方法がわかってるなら修正まで自動でやっちゃえば良い https://github.com/colopl/php-colopl_bc/blob/main/tests/Rector/Equal/EqualToBCMigrateRector/Fixture/basic_replace_op erator.php.inc 16

Slide 17

Slide 17 text

新たな問題 17

Slide 18

Slide 18 text

18 静的解析が 重すぎる

Slide 19

Slide 19 text

レベル (スペック) を上げて物理で殴る 19

Slide 20

Slide 20 text

● 消費リソース的にローカルで実行しておくのは困難 ○ GitLab CI を用いて実行することに ■ キャッシュが適切に利用できないので強いインスタンスで対応 ■ インスタンススペックでゴリ押し 20 CI パイプラインの整備

Slide 21

Slide 21 text

それでも無理な 非互換が... 21

Slide 22

Slide 22 text

colopl_bc Extension https://github.com/colopl/php-colopl_bc どうしても対応できない PHP の非互換に対応するための PHP Extension 詳細は COLOPL Tech Blog にて近日中に書きます 22

Slide 23

Slide 23 text

● 保守性向上には静的解析が有用 ○ 必要であればルールを自作しイレギュラーの発生を抑制 ● 継続的インテグレーションは大切 ○ 性善説に基づく "ローカルで実行" は現実的ではない ● いざとなったら低レイヤーで対応 ○ 自分たちの使っている技術スタックを深く理解しておく 23 まとめ