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
仕様変更に耐えるための"今の"DRY原則を考える
mkmk884
9
3.1k
ML.NETで始める機械学習
ymd65536
0
230
苦しいTiDBへの移行を乗り越えて快適な運用を目指す
leveragestech
0
990
How mixi2 Uses TiDB for SNS Scalability and Performance
kanmo
40
16k
GoとPHPのインターフェイスの違い
shimabox
2
210
Flutter × Firebase Genkit で加速する生成 AI アプリ開発
coborinai
0
170
Django NinjaによるAPI開発の効率化とリプレースの実践
kashewnuts
1
250
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
yahiru
8
1.3k
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
14
4.6k
PHPカンファレンス名古屋2025 タスク分解の試行錯誤〜レビュー負荷を下げるために〜
soichi
1
670
第3回関東Kaggler会_AtCoderはKaggleの役に立つ
chettub
3
1.1k
お前もAI鬼にならないか?👹Bolt & Cursor & Supabase & Vercelで人間をやめるぞ、ジョジョー!👺
taishiyade
7
4.2k
Featured
See All Featured
Gamification - CAS2011
davidbonilla
80
5.2k
Faster Mobile Websites
deanohume
306
31k
Become a Pro
speakerdeck
PRO
26
5.2k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.9k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Done Done
chrislema
182
16k
The Invisible Side of Design
smashingmag
299
50k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
It's Worth the Effort
3n
184
28k
Documentation Writing (for coders)
carmenintech
67
4.6k
Writing Fast Ruby
sferik
628
61k
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の仕組み ◦ インフラエンジニア ▪ 動作させるミドルウェアやアプリケーションの特性や挙動の特徴 エンジニアとして大事なこと
• インシデントは初動が大事 ◦ いろんなレイヤーで起こるため、原因の切り分けが難しい ◦ 組織全体で協力が必要な場面もある ◦ 「自分は関係ない」ではなく、 「知ってる知識が役に立つかも?」というスタンスで •
スピード感を持って動ける体制を作る 組織として大事なこと
• 問題解決のときにこそ、その人の地力が現れる ◦ 組織力としても同様 • エンジニアリングの世界は奥が深い! • 完全に理解した、から一歩その先へ まとめ
おわり