Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
問題解決に必要な能力 〜CodeBuildとOPCacheに振り回された話〜 / Abilit...
Search
Masakazu Matsushita
April 22, 2022
Programming
0
290
問題解決に必要な能力 〜CodeBuildとOPCacheに振り回された話〜 / Ability to solve problems
2022/01/27 kaonavi Tech Talk #1で登壇したときの資料です。
https://kaonavi.connpass.com/event/235914/
Masakazu Matsushita
April 22, 2022
Tweet
Share
More Decks by Masakazu Matsushita
See All by Masakazu Matsushita
It's up to you 〜 楽しさドリブンで歩んだ道 〜
matsukaz
0
77
withコロナでカオナビに起こった3つの変化
matsukaz
1
1.1k
Other Decks in Programming
See All in Programming
CloudNativePGを布教したい
nnaka2992
0
110
Django NinjaによるAPI開発の効率化とリプレースの実践
kashewnuts
1
250
Bedrock Agentsレスポンス解析によるAgentのOps
licux
3
920
CDK開発におけるコーディング規約の運用
yamanashi_ren01
2
250
Djangoアプリケーション 運用のリアル 〜問題発生から可視化、最適化への道〜 #pyconshizu
kashewnuts
1
260
ML.NETで始める機械学習
ymd65536
0
230
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
230
負債になりにくいCSSをデザイナとつくるには?
fsubal
10
2.6k
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta27
0
300
.NET Frameworkでも汎用ホストが使いたい!
tomokusaba
0
200
Datadog DBMでなにができる? JDDUG Meetup#7
nealle
0
140
XStateを用いた堅牢なReact Components設計~複雑なClient Stateをシンプルに~ @React Tokyo ミートアップ #2
kfurusho
1
990
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Optimising Largest Contentful Paint
csswizardry
34
3.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
Unsuck your backbone
ammeep
669
57k
Designing for Performance
lara
604
68k
Faster Mobile Websites
deanohume
306
31k
Gamification - CAS2011
davidbonilla
80
5.2k
4 Signs Your Business is Dying
shpigford
182
22k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
990
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
Transcript
問題解決に必要な能力 松下雅和 / @matsukaz 2022/01/27 〜CodeBuildとOPCacheに振り回された話〜 kaonavi Tech Talk #1
CTO Webエンジニア CTO SE アーキテクト 都築電気 株式会社 株式会社 オープンストリーム 株式会社
トランスリミット 株式会社 サイバーエージェント 株式会社 カオナビ 松下 雅和 @matsukaz 株式会社カオナビ CTO AWS, Node.js, TypeScript, Ruby, Python, PHP, Go, Scrum 2001.04 2005.08 2011.01 2014.10 2020.02 漫画, ゲーム, カメラ, 自転車
• 前提知識 ◦ OPCache ◦ Apache MPM Prefork ◦ ビルドパイプラインのBefore/After
• とある事象発生 • 調査&解決までの流れ • 問題解決に必要な能力 アジェンダ
前提知識
• コンパイル済みバイトコード(OPCode)を共有メモリに保存し、実行のた びにスクリプトの読み込み・パースの手間を省く仕組み OPCache Lexer PHP Script Check OPCode Cache
OPCode Compiler Save OPCode Execute (Zend VM) OPCode キャッシュなし Shared Memory OPCode OPCode Parser Optimizer
• コンパイル済みバイトコード(OPCode)を共有メモリに保存し、実行のた びにスクリプトの読み込み・パースの手間を省く仕組み OPCache PHP Script Check OPCode Cache Read
OPCode Execute (Zend VM) キャッシュあり Shared Memory OPCode OPCode
• コンパイル済みバイトコード(OPCode)を共有メモリに保存し、実行のた びにスクリプトの読み込み・パースの手間を省く仕組み OPCache Lexer PHP Script Check OPCode Cache
OPCode Compiler Save OPCode Read OPCode Execute (Zend VM) OPCode キャッシュなし キャッシュあり Shared Memory OPCode OPCode Parser Optimizer
Apache MPM Prefork • Apache起動時に予め(pre)子プロセスをコピー(fork)し、アクセスに備 える方式 • リクエストを1つの子プロセスが処理する ◦ 他のプロセスの影響を受けないが、多くのメモリやCPUが必要
子プロセス コントローラー プロセス http リクエスト # ps auxf | grep httpd USER PID ... COMMAND root 11 ... httpd -DFOREGROUND apache 12 ... \_ httpd -DFOREGROUND apache 13 ... \_ httpd -DFOREGROUND 子プロセスを管理 http リクエスト SAPI 子プロセス SAPI
Apache MPM Prefork + OPCache • OPCodeを共有メモリで管理(ファイル共有も可能) ◦ プロセスをまたがっても同じOPCodeを共有 ◦
OPCodeの保存や読み込みはセマフォを利用して排他制御 子プロセス コントローラー プロセス http リクエスト http リクエスト http リクエスト SAPI 子プロセス SAPI 子プロセス SAPI Shared Memory OPCode
• 同一サーバに新しいバージョンのコードを配置 • symlinkでコードの参照を切り替え • httpd reloadコマンドを実行 ◦ 設定ファイルの再読み込み ◦
OPCacheのクリア ビルドパイプライン (Before) # tree /var/www/html -L 2 /var/www/html ├── current │ ├── app │ ├── … │ └── releases ├── 20211115100000 └── 20211116100000
• CodeBuild + CodeDeployを利用したBlue-Green Deployment ◦ リリースのたびに新しいサーバに切り替わる仕組み ALB ビルドパイプライン (After)
• CodeBuild + CodeDeployを利用したBlue-Green Deployment ◦ リリースのたびに新しいサーバに切り替わる仕組み デプロイ ビルド CodeDeploy
CodeBuild ALB ALB ビルドパイプライン (After)
• CodeBuild + CodeDeployを利用したBlue-Green Deployment ◦ リリースのたびに新しいサーバに切り替わる仕組み デプロイ 切り替え ビルド
CodeDeploy CodeBuild ALB ALB ビルドパイプライン (After) ALB
とある事象発生
• ロードアベレージが高くなる現象が発生 ある日のリリースにて
• 現象発生直前のリリースが怪しいと判断し、リバートを決断 • ただ、リバート後も判断しきれない状態が続く (サーバを増設したのに負荷が下がりきらない) ◦ 月末によるカオナビの機能(人事評価)の駆け込み需要? • その後も、リリースのたびに負荷が高かったり低かったり… 現象確認と初動対応
• OPCacheが怪しい… インフラGで本格的な調査開始 キャッシュヒット率
• OPCacheが怪しい… インフラGで本格的な調査開始 キャッシュミス回数
• ステージング環境でもOPCacheのヒット率低下が発生 • 決め手がないまま、サーバの増設・縮退で高負荷を回避 • 「カオナビの動作が最近遅い」との問い合わせも…(関連は不明) • 開発側のメンバーも参戦! ここからは松下目線の話 根本原因がわからず
調査&解決までの流れ
• OPCacheの状態を手軽に確認したい ◦ https://gist.github.com/ck-on/4959032 • OPCacheのウォームアップを一気に行いたい ◦ https://gist.github.com/klimslim/ce8f727b3b419badce243bf5a74389b6 ◦ require_once()とopcache_compile_file()による違いはない
• ローカルの検証環境は大体できた まずはOPCacheの仕組みを理解
• ビルドパイプラインの変更とOPCache関連がやはり怪しい 以前との違いを再確認 デプロイフローの確認 以前の方式の挙動確認
• キャッシュミスが発生し続ける = opcache_compile_file()でキャッシュ されないファイルがあるはず • realpathまわりが怪しい? 当たりをつける https://www.slideshare.net/hnw/realpath-opcache ▪余談
php-fpmを利用していた場合は、 OPCacheと realpathとの関連はものすごく重要! 詳しくはこちらの資料を参照 →
挙動を再現!
• OPCacheの設定 ◦ max_accelerated_files = 10000(デフォルト) ◦ OPCacheは、内部でsymlinkとrealpathの両方のパスを 保持する(?)ため、2倍のキーを消費 ◦
16229 / 2 = 8115で頭打ちに つまり?
• どんな仕組みでそうなっているのかちゃんと把握 裏取り http://blog.jpauli.tech/2015-03-05-opcache-html/
だがしかし…
oh...
再び盛り上がる人々
• 誰も利用していない時間のステージング環境で再現確認 本番に近い環境で再検証
• 突然再現しなくなる(キャッシュミスしなくなる) 本番に近い環境で再検証
!?
• 現象発生中にキャッシュされていたファイル一覧を出力 より詳細に調査
• OPCache側ではなくてファイルかディレクトリの問題? • 適当にファイル作ってみる → キャッシュされる より詳細に調査 New
• OPCache側ではなくてファイルかディレクトリの問題? • 適当にファイル作ってみる → キャッシュされる • 同じ内容のファイルを作ってみる → キャッシュされる
より詳細に調査 New Not Cached New
• OPCache側ではなくてファイルかディレクトリの問題? • 適当にファイル作ってみる → キャッシュされる • 同じ内容のファイルを作ってみる → キャッシュされる
• コピーしてみる → キャッシュされ…ない?! より詳細に調査 New Not Cached New Not Cached Copied
• statで該当ファイルを見てみる… なぜか未来日付!! より詳細に調査
大勝利!!
解説
そして解決へ…
• いまだ不明… • 必ずなるわけでもない、ますます謎 • AWSのサポートに問い合わせてみたものの分からず ◦ CodeBuildでビルドした時点でなってる模様 そもそもなぜ未来日付になる?
問題解決に必要な能力
• インフラ ◦ ファイルシステム、symlink ◦ AWS関連(Codepipeline、CodeDeploy) • ミドルウェア ◦ Apache
MPM Prefork • PHPの動作の仕組み ◦ OPCache 対象に関連する前提知識
• 論理的思考 ◦ 広く・深く考える ◦ 分割して考える ◦ 筋道を考える • ラバーダッキング
マインド・考え方
• 発生している事象を正確に洗い出す • 期待する状態との差異を把握 問題解決までの行動 現状認識 原因特定 解決策の 立案 解決策の
実施
問題解決までの行動 現状認識 原因特定 • 原因となりうる要素の洗い出し • 再現環境の構築・再現方法の確立 • 原因の絞り込み ◦
当たりをつける(思い込みには注意) ◦ どこまでOKでどこからNGか、境界を見極める 解決策の 立案 解決策の 実施
問題解決までの行動 現状認識 原因特定 解決策の 立案 解決策の 実施 • 取りうる選択肢の洗い出し •
判断軸をもとに解決策を決定 ◦ 暫定対応・恒久対応 ◦ 緊急性 ◦ 対応にかかるコスト ▪ スピード・リソース ◦ 影響範囲・副作用の有無
問題解決までの行動 現状認識 原因特定 解決策の 立案 解決策の 実施 • 解決策による効果を測定 •
想定外の副作用に注意 • いつでも実施前の状態に戻せるようにする
• 実装技術の向上やフルスタックエンジニアを目指す以外にも、それぞれの 領域を深く掘り下げる意識も必要 ◦ フロントエンジニア ▪ 通信やブラウザの仕組み、端末の挙動 ◦ バックエンドエンジニア ▪
実行環境の設定・ミドルウェア・OSの仕組み ◦ インフラエンジニア ▪ 動作させるミドルウェアやアプリケーションの特性や挙動の特徴 エンジニアとして大事なこと
• インシデントは初動が大事 ◦ いろんなレイヤーで起こるため、原因の切り分けが難しい ◦ 組織全体で協力が必要な場面もある ◦ 「自分は関係ない」ではなく、 「知ってる知識が役に立つかも?」というスタンスで •
スピード感を持って動ける体制を作る 組織として大事なこと
• 問題解決のときにこそ、その人の地力が現れる ◦ 組織力としても同様 • エンジニアリングの世界は奥が深い! • 完全に理解した、から一歩その先へ まとめ
おわり