長期運用を支える 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
   工藤 剛
   

   View Slide

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

   View Slide

3. 3
   今日話す内容
   

   View Slide

4. Platform
   Engineering
   とは
   4
   

   View Slide

5. わからん
   5
   

   View Slide

6. 6
   ChatGPT に聞いてみた
   

   View Slide

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

   View Slide

8. 抱えている
   課題の整理
   8
   

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

17. 新たな問題
    17
    

    View Slide

18. 18
    静的解析が
    重すぎる
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide