Slide 1

Slide 1 text

1 実運用での失敗と学びについて 落ちる 落ちるよ サーバーは落ちる 2025.08.29 シナジーマーケティング株式会社 プロダクト開発部 プラットフォームG 末廣 雅利

Slide 2

Slide 2 text

自己紹介 末廣 雅利 2004年入社 インフラエンジニアとしては最古参 家族:妻、ネコ 趣味:ランニング、ピアノ 好き:スイカ、梨 嫌い:納豆、ドロドロ・ネバネバ系 2

Slide 3

Slide 3 text

会社紹介 シナジーマーケティング株式会社 大阪本社のSaaS企業 マーケティングSaaS「Synergy!」を提供して今年で20年 その他、マルチプロダクトを展開 3

Slide 4

Slide 4 text

それは15年ほど前のこと... 4

Slide 5

Slide 5 text

DBは落ちる DBは落ちる DBの子プロセスが異常終了 アプリのとある処理が失敗するのを調査していたところ、 DBの子プロセスが異常終了していた。 20XX-04-07 00:00:01 JST [4734]: [2-1] [] LOG: server process (PID 16974) was terminated by signal 29 謎 このDBはSignal 29を利用することはないはずなのに... 日付が変わるタイミングで何かが起きている? 5

Slide 6

Slide 6 text

DBは落ちる 調査 メトリックス CPU、メモリ、ディスクIO、ネットワークなどに異常は見られず サーバーリソースには余裕がある ログ OSやハードウェアのログに異常は見られず DBのログには先のエラー以外に異常は見られず 問題になりそうなクエリも見当たらず 原因を特定できないまま様子を見ることに 6

Slide 7

Slide 7 text

DBは何度も落ちる DBは何度も落ちる 発生日時 日付 時刻 4/14 14:00 4/15 20:00 4/16 13:00 4/16 15:00 発生時刻や間隔はバラバラだが、毎時0分に発生している さらに調査するも 他に異常は見当たらない 影響を受けたアプリは様々 なにかあるはずなのだが... 7

Slide 8

Slide 8 text

DBは何度も落ちる あらためてログを 見返してみると... PID が同じ! 20XX-04-14 14:00:01 JST [4734]: [2-1] [] LOG: server process (PID 16974) was terminated by signal 29 20XX-04-15 20:00:01 JST [4734]: [2-1] [] LOG: server process (PID 16974) was terminated by signal 29 20XX-04-16 13:00:01 JST [4734]: [2-1] [] LOG: server process (PID 16974) was terminated by signal 29 20XX-04-16 15:00:01 JST [4734]: [2-1] [] LOG: server process (PID 16974) was terminated by signal 29 相変わらず原因はわからないが、これなら対策できる! 8

Slide 9

Slide 9 text

対策を打つ 問題のPIDを確保する シェルスクリプト #!/bin/sh if [ $$ -ne 16974 ]; then exit fi trap 'date; echo "Signal 29 received."' 29 while true; do sleep 1 done 問題のPIDを掴むまで実行を繰り返す。 これでDBの子プロセスが落ちることがなくなった。 9

Slide 10

Slide 10 text

はずだったのに... 10

Slide 11

Slide 11 text

DBはそれでも落ちる DBはそれでも落ちる 今回は少し異なる 20XX-04-16 21:00:01 JST [4734]: [2-1] [] LOG: server process (PID 20765) was terminated by signal 29 PIDが変わってるではないか! なぜだ? 11

Slide 12

Slide 12 text

DBはそれでも落ちる 実は... 再発の30分ほど前にサーバーのディスク状態を確認するために RAID管理ツールを実行していた。 DBサーバーでは、ハードウェアRAID管理サービスが常時稼働し ており、管理ツールからアクセスすると管理サービスの子プロセ スが立ち上がる。その子プロセスに signal 29 が送られていた。 管理ツールを停止するとこの子プロセスも停止するが、signal 29 は送り続けられていた。 12

Slide 13

Slide 13 text

DBは落ちない DBは落ちない ディスク監視のためにRAID管理サービスを稼働させていたが、別 途監視する方法が見つかったので停止した。 それ以降、Signal 29が送られることもなくなり、DBが落ちるこ ともなくなった。 13

Slide 14

Slide 14 text

得られた学び 得られた学び 原因はわからなくても、打てる回避策はある 事象を正確に把握すれば、回避策を打てることがある。 ログをよく見るべし ログは宝の山。 見落としがないか、注意深く読み込むこと。 14

Slide 15

Slide 15 text

障害対応で心がけていること 障害対応で 心がけていること 1. 情報を集めて事象を正確に把握する ログ、監視・モニタリングツール 発生している事象を頭の中で再構築 2. 事象をすべて説明できるシンプルな仮説を立てる 3. 仮説を検証する 証拠集め、再現試験 仮説が間違っていれば 2. に戻る 4. 対策を打つ 仮説が正しければ、根本的な対策を打てる 15

Slide 16

Slide 16 text

さいごに ログを読むことは は成長につながる ログ解析ツールを自作しよう プログラミング言語の習得になる 手慣れたツールがあると調査が捗る ときにはソースコードにあたってみよう 特徴的なログメッセージでgrepすると該当箇所が見つかる ソースコードを読めばソフトウェアへの理解が深まる 主要なミドルウェアやアプリのソースコードを常時展開しておく 16