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
APIをリライトした時の失敗談_実行環境の差異が生んだ不具合と教訓.pdf
Search
rsym1290
March 19, 2026
140
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
APIをリライトした時の失敗談_実行環境の差異が生んだ不具合と教訓.pdf
rsym1290
March 19, 2026
More Decks by rsym1290
See All by rsym1290
Road_to_SRE_NEXT_福岡.pdf
rsym1290
3
670
技術基盤G_LT会_公開用_.pdf
rsym1290
0
570
サービスを構成する全サーバが トラックに載って 遠くのデータセンターへ旅立ったお話
rsym1290
0
310
4ペタバイトを超えるオブジェクトストレージを ハードウェアからアプリケーションにかけて 運用するノウハウ
rsym1290
2
4.1k
Featured
See All Featured
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
2
870
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
Unsuck your backbone
ammeep
672
58k
The SEO identity crisis: Don't let AI make you average
varn
0
500
Scaling GitHub
holman
464
140k
Agile that works and the tools we love
rasmusluckow
331
22k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
190
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.2k
[SF Ruby Conf 2025] Rails X
palkan
2
1.1k
Making Projects Easy
brettharned
120
6.7k
How GitHub (no longer) Works
holman
316
150k
A Soul's Torment
seathinner
6
3k
Transcript
APIをリライトした時の失敗談 実⾏環境の差異が⽣んだ不具合と教訓 GMOペパボ株式会社 Tsuyoshi Mikami (@rsym1290) 2026.03.19 tamachi.sre #3 1
⾃⼰紹介は時間があまったら 最後にやります! 2
今⽇話すこと Perl+FastCGIで⻑年運⽤していたAPIとその依存モジュールをGoでリライトし ました。テスト‧動作検証を経て本番リリースしたものの、障害が発⽣しまし た。これによってユーザの皆様に迷惑をおかけしました。本LTでは、障害の原 因とそこから何を学んだのかをお話しします。 ※詳細は⼀部伏せる形で発表させていただきます 3
リライトの背景 • ⻑年Perl+FastCGIで運⽤していたAPI • 運⽤上の課題があり刷新したかったが、事業⽅針上の優先度からなかなか着⼿できず • しかしAIエージェント(Claude Code)の登場によって状況が変化 • 別件対応の合間でも開発を進められるようになりGoでのリライトに踏み切った
• Goにした理由は本LTでは割愛(気になる⽅は懇親会で) Perl+FastCGIで⻑年運⽤していたAPIをGoでリライトすることにした 4
テストは全てOK • ユニットテスト‧結合テストは全てパス • ステージング環境での動作確認も問題なし • ⼗分にテストしたという⼿応えがあり、⾃信を持ってリリース テスト‧動作検証を経てリリース 5
しかし 🔥障害発⽣🔥 ⼤量のエラーで切り戻し。。。 6
障害の原因 • キャッシュされたソケットを取り出す時はMutexをかけていたが、そのソケットへの Read/Write時はMutexが外れていた • 複数のgoroutineが同じソケットに同時に読み書きし、あるリクエストに対して別のリクエスト のレスポンスが返る状態が起きた 原因はAPIが利⽤する依存モジュールの排他制御の不備によるレースコンディション 7 1プロセス(共有メモリ)
goroutine 1 goroutine 2 goroutine 3 ロック内 Socket 取得 ロック外 I/O (Read/Write) Backend
なぜリライトを機に障害が起きたのか🔥 「OSレベルのプロセス隔離」という安全装置がリライトによって無くなってしまった 8 Perl + FastCGI Req1 プロセス1 Socket1 Backend
Req2 プロセス2 Socket2 Req3 プロセス3 Socket3 プロセスが隔離 → 競合は構造的に起きない Go 複数goroutineが同時にRead/Write • リライト前(Perl+FastCGI):1リクエストにつき1プロセスが割り当てられメモリ空間が完全に 隔離 • リライト後:goroutineがソケットを共有していたため排他制御は必須 1プロセス(共有メモリ) goroutine 1 goroutine 2 goroutine 3 ロック内 Socket 取得 ロック外 I/O (Read/Write) Back end
教訓 (1) • 今回の障害は、コードには現れない前提(OS+FastCGIがプロセスの隔離に責任を持っていたこ と)がリライトで失われたことで発⽣した • このような前提‧暗黙知は⾒落としやすい • AIエージェントの登場で、開発速度が爆発的に向上 •
開発速度が上がるということは、⾒落としが本番に届くリスク‧機会も増えるということ • ましてやレビュアーの負担が増えるのでこのような落とし⽳に遭遇しやすい 実⾏環境の暗黙知‧前提は⼈間もAIも⾒落としやすい 9
教訓 (2) • ガードレール • セキュアコーディングガイドラインの整備 • サイバー攻撃対策の他に、実装の誤りに起因する内的要因に対するリスクもカバー • go
test -race のような動的検証をCIに組み込む • CLAUDE.mdを通じてAIにも反映 • カナリアリリース • リライトの背景と同様、整備の優先度が落ちていた • 開発速度が上がるほど、デリバリーの⼟台がないとリスクが顕在化する • オブザーバビリティ • リクエストパスやステータスコードなど汎⽤的なログだけでは不⼗分 • アプリ固有の⽂脈を持った計装がないと、実⾏環境に依存する不具合は捉えられない 個⼈の注意⼒ではなくガードレールで防ぐ & AI時代だからこそSREとしてやるべきことを改めて 10
時間があまったら⾃⼰紹介! 時間がなかったら懇親会で! 11
12 ⾃⼰紹介 技術部技術基盤グループ エンジニアリングリード 2016年9⽉ 中途⼊社 三上 烈史 Mikami Tsuyoshi ペパボでのニックネームは「れっしー」 由来は本名より
• X(Twitter) : @rsym1290 • GitHub: @rsym • 趣味:ランニング
13 Thank you!