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
めぐろLT#6 怖い話 サーバーが次々死んでいく
Search
kiyoshi yamashita
August 31, 2023
Programming
230
0
Share
めぐろLT#6 怖い話 サーバーが次々死んでいく
めぐろLTでの登壇資料
https://meguro-lt.connpass.com/event/288484/
kiyoshi yamashita
August 31, 2023
More Decks by kiyoshi yamashita
See All by kiyoshi yamashita
ユニットテスト環境改善/improve-unit-test-environment
ky6yk
0
460
画像のバリデーションはファイルサイズチェックだけでいいと思ってない?
ky6yk
0
550
ES2021/2022
ky6yk
0
55
Other Decks in Programming
See All in Programming
dRuby over BLE
makicamel
2
300
Spec Driven Development | AI Summit Lisbon
danielsogl
PRO
0
130
SPMマルチモジュールで テストカバレッジを取得する技法
yosshi4486
0
140
AI時代のUIはどこへ行く?その2!
yusukebe
19
6.5k
プラグインで拡張される Context をtype-safe にする難しさと設計判断
kazupon
2
550
[2026年度第1回ORセミナー] 計画最適化ベンチャーと競技プログラミング人材
terryu16
0
240
AIチームを指揮するOSS「TAKT」活用術 / How to Use “TAKT,” an OSS Tool for Orchestrating AI Teams
nrslib
6
800
代数的データ型って何が嬉しいの? #frontend_phpcon_do
kajitack
8
3.1k
不変条件と整合性境界—ビジネスが決める設計判断と実現パターン / Invariants and Consistency Boundaries
nrslib
13
3.3k
今さら聞けないCancellationToken
htkym
0
220
CSC307 Lecture 17
javiergs
PRO
0
310
TypeSpec で繋ぐ複数プロダクトの型安全
maroon8021
1
330
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
55
8.2k
Mind Mapping
helmedeiros
PRO
1
230
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
360
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
310
It's Worth the Effort
3n
188
29k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
400
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.3k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
130
Transcript
サーバーが次々死んでいく... 株式会社ラクーンHD yamashita.kiyoshi
まずは自己紹介 名前:山下 清史 所属:株式会社ラクーンホールディングス 技術戦略部 開発チーム 主な仕事:BtoB卸売りサイト スーパーデリバリーの開発
APサーバーをDocker化した - 今までのサーバーのセットアップは手作業でやっていた - Dockerfileにサーバーの設定をかける - 開発環境構築が楽になった - ログフォーマットをjsonにした -
ログを標準出力に出すようにした - サーバにsshしてログファイルを確認しなくてよくなった - fluentd -> Elasticsesarch -> kibanaでログを確認できる
進め方 - Dockerfileなどを作成する - ログをモダンにする - 不要なログを削除し、標準出力に出す - セキュリティ対策 -
機密情報をDockerfileに書かないようにした - ひたすらテスト 俺、このプロジェクトが終わったら長期休暇を取って海外旅行へ行くんだ... APサーバーをDocker化した
開発は上手くいった そして本番稼働して、初めの1、2日は上手く動いていた APサーバーをDocker化した
サーバーが死んでいく いきなりサーバーが死んでサービスサイトに繋がらなくなった アクセスログは全て500 会員が商品を購入できなくなった
サーバーが死んでいく 大量の同時アクセスが来ていたようだ…
一時的な高負荷によりメモリが足りなくなった? →メモリ割り当てを増やした 負荷テストが足りなかったなぁ~ 考えられる原因
メモリを2倍割り当てたはずなのにサーバーがまた死んだ... 対策した結果
パフォーマンス劣化のたびに対処療法(メモリ割り当てを増やす)を行った しかし、ついにアクセスが少ないときにサーバーが死んだ… 一時的な高負荷が問題じゃなかった… それでもまた…
計測 現在のアプリケーションサーバーにおいてヒープ領域の使用状況を確認すると 異常にメモリを使っているクラスが見つかった... そのクラスを確認したら
進め方 - Dockerfileなどを作成する - ログをモダンにする - 不要なログを削除し、標準出力に出す - セキュリティ対策 -
機密情報をDockerfileに書かないようにした - ひたすらテスト このプロジェクトが終わったら長期休暇を取って海外旅行へ行くんだ・・・ APサーバーをDocker化した
原因 不要なログ削除時の対応がミスっていたことが発覚した 対応ミスしたログの動作 - ログ出力前に、スレッド変数内にデータをためる - ログ出力後にデータをクリアする データをためるところを消さずにデータをクリアするコードのみを消していた
→メモリリーク発生
原因 gitでコミットした人を見ると...私でした
まとめ - 推測するな、計測せよ!! - メモリリークは気付きづらくて怖い - 解決までに時間がかかってしまった