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

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

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

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

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

パフォーマンスの構造 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

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

推測するな計測せよ(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

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

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

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

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

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

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

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

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

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

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

おわり