Hacking Phoenix Performance

https://fukuokaex.connpass.com/event/272529/

LT talk

Transcript

1. Hacking Phoenix
   Performance
   2023/03/11 fukuokaex#53
   おーはら@tokyo.ex
   

   View Slide

2. About Me
   ● おーはら / Twitter: @ohrdev / Github: ohr486
   ● 株式会社ドリコム SRE部 部長
   ○ Work:
   ■ エンジニアマネージャ
   ■ サーバー/インフラエンジニア
   ■ 新規事業/ディレクター
   ● 負荷試験支援サービス
   ● DevOps推進支援/負荷試験/設計コンサル
   ● 月1くらいで社内外のシステムの負荷試験をしている
   ● Community
   ○ tokyo.ex / Japan Elixir Association / Erlang&Elixir Fest
   ○ JEAでカンファレンスを計画中（詳細は近々アナウンス できたらいいな）
   ● Hobby
   ○ 仏像制作, 自転車
   ○ Nerves & Gadget
   

   View Slide

3. agenda
   ● 「はやい」は正義
   ● Phoenixアプリのパフォーマンス
   ● パフォーマンスの構造
   ○ Phoenixアプリ
   ● 推測するな計測せよ
   ○ Webサービス
   ○ ErlangVM
   ○ インフラ
   ● 結局、何を見ればいいの？
   ○ 1. DB
   ○ 2. Plug(Cowboy)
   ○ 3. OS(Memory)
   ● プロファイリング
   ● まとめ
   ● 宣伝
   

   View Slide

4. 「はやい」は正義
   ● Webサービスの文脈で「高速」なのは重要
   ○ サービスの競争力に直結する
   ■ ex) Googleの実験
   ● 検索結果が表示されるまでの時間が長くなると利用者が減少する
   ○ Googleの検索順位はCoreWebVitalsの指標に影響を受ける
   ■ CoreWebVitals: Googleが掲げるWebサイトの健全性をチェックする際の重要指標
   ● LCP(Largest Contentful Paint) : 読み込み速度
   ● FID(FIrst Input Delay) : インタラクティブ性
   ● CSL(Cumulative Layout Shift) : ページコンテンツの視覚的安定性
   ○ コスト効率が良い
   ■ 1台のサーバーで単位時間あたりに処理できるリクエストが大きくなる
   ● システムのリソースコストが安くなる（少ないサーバー台数で運用できる）
   

   View Slide

5. Phoenixアプリのパフォーマンス
   ● どういう指標があるか？
   ○ レイテンシ(msec,μsec)
   ■ 利用者の リクエスト送信開始 から レスポンス受信完了 までの時間
   ■ 値が低いほど良い
   ○ スループット(rps)
   ■ 一定時間内に同時並行で処理できるリクエストの量
   ■ 値が高いほど良い
   ● パフォーマンスは深くて広いジャンル
   ○ https://www.oreilly.co.jp/books/9784814400072
   

   View Slide

6. パフォーマンスの構造
   internet
   DNS
   hop
   hop
   hop
   cloud
   LB
   VM or Cluster (AutoScaling)
   VM or Container (Linux base)
   OS
   ErlangVM
   OTP
   Elixir Phoenix
   RDB KVS
   browser
   チューニングできるかもし
   れないポイント
   ユーザーから見たレイテ
   ンシは、各ポイントのレイ
   テンシの合計値
   (AWS) Global Accelerator
   Asset size
   Preload
   Scale Out
   Scale Up
   Scale Up/Out Scale Up/Out
   Query Tuning
   DB Engine
   Paramter
   Kernel Parameter
   EVM Parameter
   

   View Slide

7. Phoenix
   パフォーマンスの構造(Phoenixアプリ)
   ErlangVM
   OTP
   Elixir
   Ecto/Ecto
   Controller
   Plug Cowboy Redix
   Channel
   Template
   Rendering
   LiveView
   Event
   Business
   Logic Module
   チューニングできるかもし
   れないポイント
   計測可能単位
   

   View Slide

8. 推測するな計測せよ(Webサービス)
   ● Phoenixアプリのパフォーマンス計測ライブラリ
   ○ OpenTelemetry
   ■ https://github.com/open-telemetry/opentelemetry-erlang-contrib
   ● phoenix
   ● ecto
   ● cowboy
   ○ AppSignal(APM SaaS)
   ■ https://www.appsignal.com/elixir
   ● phoenix
   ● ecto
   ● plug
   ○ Scount(APM SaaS)
   ■ https://scoutapm.com/elixir-monitoring
   ● phoenix
   ● ecto
   ○ NewRelic(APM SaaS)
   ■ https://github.com/newrelic/elixir_agent/blob/master/README.md
   ● phoenix
   ● ecto
   ● plug
   

   View Slide

9. 推測するな計測せよ(ErlangVM)
   ● Observer
   ○ Erlangのobserver
   ○ observer_cli
   ○ phoienix_live_dashboard
   ■ 本番環境では無効にして運用するケースが多い？
   ● Phoenixの計測ライブラリ
   ○ だいたいErlangVMのメトリクスも一緒に計測してくれる
   ● ErlangVMの内部メトリクスを知りたい場合
   ○ Erlang/Elixirのトレース/プロファイイングライブラリ
   ■ {c|e(x)|f}prof
   ■ recon_ex
   ■ …
   

   View Slide

10. 推測するな計測せよ(インフラ)
    ● クラウドを利用していれば、モニタリングのマネージドサービスでカバー可能
    ● 見るべきマネージドサービス
    ○ ロードバランサー
    ■ レイテンシ, スループット, ステータスコード
    ○ VM(Linuxサーバー)
    ■ CPU, Mem, IO
    ○ コンテナ
    ■ リソース(cpu/memory)
    ○ RDB
    ■ CPU, Mem, IO
    ● Webサービスの一般的なモニタリング
    

    View Slide

11. 結局、何を見ればいいの？
    ● 指標が多すぎ問題
    ● 重要なものから少しずつ見れるようになるのが良い
    ● ここだけは見ときたい
    ○ 1. DB(RDS)
    ○ 2. Plug/Cowboy
    ○ 3. OS(CPU/Memory)
    

    View Slide

12. 結局、何を見ればいいの？ 1.DB(RDB)
    ● Phoenixに限らず、Webアプリのボトルネックは大抵ここ（体感9割くらい)
    ● 運用が長くなり、データが増えてくると発生する
    ○ N+1
    ○ indexの貼り忘れ
    ○ etc
    ● スロークエリを出すようにしておけば検知できる
    ○ 検知できた時には、だいたい手遅れ
    ● 対策
    ○ N+1問題の回避（preload、join、etc)
    ○ index
    ○ LoadTest
    ■ データが少ない状態で試験をしても検知できないので、大量のデータを入れた状態でテスト
    する必要があるので注意
    

    View Slide

13. 結局、何を見ればいいの？ 2.Plug(Cowboy)
    ● API/リクエスト単位でレイテンシを計測
    ○ 遅い/速いの差が顕著に見える
    ● 注意
    ○ レイテンシ(レスポンスタイム)は以下の指標で見ること
    ■ パーセンタイル値(99,95,90あたり)
    ● 参考: https://ghw.pfizer.co.jp/comedical/evaluation/relation.html
    ■ 平均では見ない方が良い
    ● 問題があっても、平均にすることで性能が悪いリクエストが丸まってしまう
    

    View Slide

14. 結局、何を見ればいいの？ 3.OS(CPU/Memory)
    ● ErlangVMは多少無茶をしてもクラッシュしない（堅い）
    ● OS(VM,コンテナ)単位で監視
    ○ Phoenixアプリに異常が発生する際の挙動（あくまで個人の感想です）
    ■ ケース1: DBがつまる
    ● スロークエリが発生し、 DBのCPU/Memoryが100%近くに張り付く
    ● DB処理を内部的に行うリクエストのレイテンシが悪化
    ● LBでタイムアウトが発生し 500エラーとなる
    ● サービスダウン
    ■ ケース2: アプリがつまる
    ● Phoenixの問題のある内部処理により CPU/Memoryのリソースが枯渇する
    ● 最終的に結果は返すが、処理時間が長くなる（レイテンシが悪化する）
    ● リクエストのレイテンシが悪化
    ● LBでタイムアウトが発生し 500エラーとなる
    ● サービスダウン
    

    View Slide

15. プロファイリング
    ● インフラ
    ○ クラウドならマネージのモニタリングサービス
    ● サーバー
    ○ クラウドならマネージのモニタリングサービス
    ● アプリ
    ○ OpenTelemetry, APM
    ● ErlangVM
    ○ OpenTelemetry, APM
    ○ Erlang in Anger
    ■ https://www.erlang-in-anger.com/
    ■ 有志による翻訳版
    ● https://ymotongpoo.github.io/erlang-in-anger/text-ja.pdf
    

    View Slide

16. まとめ
    ● Phoenixアプリのパフォーマンスの構造について紹介しました
    ● よくあるパフォーマンス劣化のパターンを紹介しました
    ● ErlangVMのプロファイリングツールを紹介しました
    ● 「はやい」は正義💰
    

    View Slide

17. 宣伝(1) tokyo.ex#22
    ● tokyo.ex #22
    ○ 2023/03/19(日) 13:00-16:00
    ○ https://beam-lang.connpass.com/event/277585/
    

    View Slide

18. 宣伝(2) BUUURST.DEV BETA
    ● 負荷試験の支援サービス作っています
    ○ https://www.lp.buuurst.dev/ (β)
    ○ 詳しい話は打ち上げ /懇親会で
    ○ 興味がある方は@ohrdevのほうまで
    

    View Slide

19. おわり
    

    View Slide