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
0
160
めぐろLT#6 怖い話 サーバーが次々死んでいく
めぐろLTでの登壇資料
https://meguro-lt.connpass.com/event/288484/
kiyoshi yamashita
August 31, 2023
Tweet
Share
More Decks by kiyoshi yamashita
See All by kiyoshi yamashita
ユニットテスト環境改善/improve-unit-test-environment
ky6yk
0
310
画像のバリデーションはファイルサイズチェックだけでいいと思ってない?
ky6yk
0
390
ES2021/2022
ky6yk
0
26
Other Decks in Programming
See All in Programming
Swiftコンパイラ超入門+async関数の仕組み
shiz
0
170
Jaspr Dart Web Framework 박제창 @Devfest 2024
itsmedreamwalker
0
150
毎日13時間もかかるバッチ処理をたった3日で60%短縮するためにやったこと
sho_ssk_
1
550
歴史と現在から考えるスケーラブルなソフトウェア開発のプラクティス
i10416
0
300
情報漏洩させないための設計
kubotak
5
1.3k
AHC041解説
terryu16
0
400
Azure AI Foundryのご紹介
qt_luigi
1
210
良いユニットテストを書こう
mototakatsu
11
3.6k
PHPで学ぶプログラミングの教訓 / Lessons in Programming Learned through PHP
nrslib
4
1.1k
ASP.NET Core の OpenAPIサポート
h455h1
0
120
watsonx.ai Dojo #6 継続的なAIアプリ開発と展開
oniak3ibm
PRO
0
170
最近のVS Codeで気になるニュース 2025/01
74th
1
100
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Side Projects
sachag
452
42k
YesSQL, Process and Tooling at Scale
rocio
170
14k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.5k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
Optimising Largest Contentful Paint
csswizardry
33
3k
A Modern Web Designer's Workflow
chriscoyier
693
190k
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でコミットした人を見ると...私でした
まとめ - 推測するな、計測せよ!! - メモリリークは気付きづらくて怖い - 解決までに時間がかかってしまった