しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 / Shibui SRE

by Hokuto Hoshi

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© LayerX Inc. 2 ● 株式会社 LayerX 執⾏役員 CISO 兼バクラク事業部 VP of Engineering ○ 全社の情報セキュリティとバクラク事業部のエンジニア組織責任者 ● コーポレートエンジニアリング室⻑, CTO 室⻑バクラク事業部プラットフォーム開発本部⻑元 SRE グループマネージャー (~2026/06) ● プロダクトのフロントつくる以外の技術だいたい担当 ● 2024年1⽉にLayerX⼊社。前職では⼤規模レシピサービスのセキュリティエンジニア、 SRE、コーポレートエンジニア、海外本社出向などを経て2023年に CTO 兼 CISO ● 今⽇は組織の話も経営の話もほとんどしません星北⽃ (HOSHI, Hokuto) / @kani_b

Slide 3

Slide 3 text

LayerX とバクラクについて

Slide 4

Slide 4 text

4 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに、複合的な事業を通して⽇本の社会課題を解決し、AIの⼒で⼈々の創造⼒がより発揮される未来をつくります。事業紹介バクラク事業バックオフィス向け AIエージェントサービスを提供 Fintech事業資産運⽤サービス「ALTERNA（オルタナ）」を提供 Ai Workforce事業エンタープライズ向け AIプラットフォームを提供 Security事業 AIエージェントによる⾃律的なペネトレーションテストを提供

Slide 5

Slide 5 text

5 © LayerX Inc. LayerX のバクラク事業

Slide 6

Slide 6 text

6 「バクラク」の事業領域 Coming Soon AIエージェント HCM領域 (人的資本管理) 稟議・ワークフロー領域 BSM / ARM領域（債務・債権管理） Payment 領域

Slide 7

Slide 7 text

© LayerX Inc. 7 バクラクのAI Agent機能バクラク債権管理、「⼊⾦消込エージェント」を提供開始。⽇々のログイン不要で⼊⾦確認から消込まで⾃動化差し戻しゼロへ。バクラク、AIエージェント「AI申請レビュー」をリリース。 AIが⾃社の規程‧ルールに基づき経費精算申請を即時レビュー LayerX、「バクラクAIエージェント」の新機能として「領収書分割エージェント」を提供開始 AIエージェント「AI明細仕訳」をリリース。明細OCR×⽣成AIで、明細⾏が多い‧毎回取引内容が変わる請求書の処理を⾃動化。 - バクラクバクラク経費精算、AIが申請不備を検知‧指摘する「AI申請レビュー」全ユーザーへの提供開始〜9割の企業が抱える「⼿戻り」を解消。設定機能アップデートにより、⾃社規定のAI実装が容易に LayerX、「バクラクAIエージェント」の新機能として「AI勤怠初期設定」を提供開始 AIが就業規則を読み解き、複雑な有給休暇の付与ルールを⾃動提案

Slide 8

Slide 8 text

Slide 9

Slide 9 text

こんな経験ありませんか？

Slide 10

Slide 10 text

© LayerX Inc. 10 ● 「◯◯という機能が使えない」「遅い」「メールが届かない」etc… ● サポートチームから連絡を受けて、調査開始 ● サーバーのログやメトリクスを⾒てみるが、異常は⾒当たらない ● サポートへの返答 ○ 「サーバー側に異常はありませんでした。おそらくお客様の環境に起因するのではないでしょうか。ブラウザや端末、ルーターを再起動いただくようご案内ください」 ● ⾊々試すも直らず、がっかりされてしまうお客様からの問い合わせ

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© LayerX Inc. 14 ● いわゆる「レスポンスタイム」の計測はサーバ上で⾏われる ○ 例えば nginx の場合 ○ リクエストの最初のバイトを読み込んだら計測開始 ○ レスポンスの最後のバイトをソケットに書き込んだら計測終了 ● 「受け取った」「返し切った」先は、クライアント (ユーザ) と直結しているわけではない ○ サーバ側のリバースプロキシやロードバランサ ○ クライアント側のプロキシ、ゲートウェイそのメトリクスは何を⽰しているのか？

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© LayerX Inc. 16 ● OS やブラウザだけじゃない ● 特に企業ネットワークには多くのソフトウェアや機器が使われ、コントロールされている ○ メール環境 ○ ネットワーク機器 (スイッチ、ルーター、ファイアウォール) ○ セキュリティ機器 (ゲートウェイ) ○ 構成管理 (MDM) ○ セキュリティソフト (アンチウイルス、EDR、Web フィルタ) ○ プリンター ● 無数に存在するこれらの要素を組み合わせた環境が、個々のお客様の環境となる 200種類以上あるユーザー環境

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© LayerX Inc. 18 ● ⾃らがコントロールできる範囲だけを⾒ていないか ○ サーバー上のログ ○ モニタリングサービスのメトリクス、外形監視 ○ 依存している SaaS のステータス ○ これらでは図の「右端」しか⾒たことにならない ● ユーザーの環境との組み合わせで起こる問題に対処できない ○ 実際にボトルネックになっている箇所を観察さえできないことがある ○ 同じプロトコルであってもクライアントによって挙動は異なる ● 結果として「原因不明」「再現不能」となってしまう「サーバーサイド」だけではわからない

Slide 19

Slide 19 text

© LayerX Inc. 19 ● 管理主体が異なる ○ そもそも⾃社の環境ではない ○ システム管理者 = 環境の管理者とも限らない ○ 例: システムのお客様環境を管理するのは財務部⾨の⽅だが、システム管理は情報システム部⾨が⾏う ● 管理者であっても全てを把握しているわけではない ○ 外部に委託されるようなケースも存在する ○ ソフトウェアの個々の挙動をつかむことは難しい「お客様環境」のデバッグも難しい

Slide 20

Slide 20 text

© LayerX Inc. 20 ● 「サービスの信頼性」は、お客様に使ってもらってこそ成り⽴つ ○ ラストワンマイルのトラブルにもできる限り対応したい ● どうしても限界はある ○ お客様環境をコントロールすることはできない ○ 全ての環境調査に出かけていくことも⾮現実的 ● ではどうするのか？ ○ 持てる⼿段を使って情報を集め、仮説を⽴て検証し、原因を特定する ○ よくあるトラブル解決と同じ流れではある ● トラブルの種類によって⽅法は異なる ○ 数をこなして感覚を磨いていく ○ 「よくやるパターン」と「具体的なケース」について紹介しますそれで良いのだろうか

Slide 21

Slide 21 text

お客様環境の調査をするために

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© LayerX Inc. 23 ● ヒアリングしたい項⽬をパターン化しておく ○ 使われているソフトウェア (OS, ブラウザ, メールクライアント, バージョン) ○ ハードウェアの性能 ○ 特にセキュリティに関するソフトウェア (EDR、フィルタ、プロキシ) ● ユーザーとの往復を可能な限り減らすことを意識する ○ 特に、ユーザーがヒアリング内容を転送しなければならないような場合 ○ サポート中の体験も含めて、サービスの体験 ● 可能な限り⽣データをいただく ○ ログファイルなどを送っていただく場合ユーザーからの情報収集

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© LayerX Inc. 25 ● まずはきちんと⾃社システムに問題がないかを確認する ○ ログやメトリクスから状況を読み取る ○ ユーザーからの情報収集はその後で ● ⾃社システムの構成と、ヒアリング環境を接続して、問題が起こりうる箇所を整理する ○ メトリクスから読み取れた範囲を明確にしておく ○ 図にしても良い ● 問題の仮説を⽴てて、確認検証していく ○ ヒアリングした環境に近い環境を作れるとなおよい ○ ⾃社側のドキュメントや検証で確認できることも多くある ○ 難しいものは追加でヒアリングを進めていく⾃社システムとヒアリング環境の分解

Slide 26

Slide 26 text

問題の例とその調査、対処

Slide 27

Slide 27 text

Webブラウザ

Slide 28

Slide 28 text

© LayerX Inc. 28 ● オフィスネットワークの中で使っているが、読み込みに⾮常に時間がかかる ○ サーバーサイドのログを特定したが、レスポンスタイムは正常 ● 他のシステムは問題なく使えている、インターネット環境の障害もない ● クライアントのスペックも⼗分なものが使われている ● ヒアリングから、サーバーがレスポンスしてからクライアントに届くまでに問題が起きているであろうことは明らかなので、調査のために HAR ファイルをいただく Case 1: システムが遅い！

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© LayerX Inc. 30 ● パフォーマンスに関する情報を得るうえで、⾮常に解像度の⾼い情報 ● お客様のブラウザで起きている事実を得るための、簡単な⼿段 ○ DNS の解決結果、ヘッダ、パフォーマンス測定結果をはじめとしたデータ ○ 取得のためにお客様に⼤きな負担をかけない ■ より深いヒアリングをする前に洞察を得ることができる ● リモートで近いデータを集める仕組みとして RUM (Real User Monitoring) もある ○ 各リクエストに応じてログを収集するため、肥⼤化しがち ○ マネージドサービスで全量集めようとすると⾼コスト ■ そのため多くの場合サンプリングする ■ サンプリングをする場合、トラブル解決には向かないことが多い HAR の便利な点

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© LayerX Inc. 32 ● キュー ○ ブラウザからのリクエスト待ちに⼊れられている時間 ○ 前のリクエストが詰まっていると時間が伸びる (コネクション数を使い切っていた場合など) ● ストール ○ プロキシへの接続など、リクエスト送信の準備をする前段階の時間 ○ プロキシネゴシエーションがある場合 HTTP レイヤにプロキシがあるとわかる ● DNSルックアップ ○ DNS問い合わせの時間 ○ ここがボトルネックになることもまれによくある ● 初期接続 ○ TCP Handshake, TLS handshake (negotiation) ○ 同⼀ TCP セッションを使う最初のリクエストで発⽣するざっくりした説明

Slide 33

Slide 33 text

© LayerX Inc. 33 ● リクエスト送信 ○ ネットワークリクエストを送信するのにかかった時間 ○ send() してソケットバッファに書くまで (TCP ACK を待たない) ● 応答待機 ○ いわゆる TTFB ○ HTTPレスポンスにおいて、最初のバイトを受け取るまでの時間 (処理時間 + 伝送時間) ● コンテンツダウンロード ○ 受信にかかる時間 ■ ⼤きなファイルで帯域幅が狭い場合などはここで時間がかかるざっくりした説明ページを表⽰する際のウォーターフォールチャート

Slide 34

Slide 34 text

© LayerX Inc. 34 ● サーバへの TCP/TLS 接続が完了するまでにそもそも時間がかかっている ● リクエストの送信および TTFB (最初のデータを受け取るまで) に時間がかかっている ○ ネットワークは⽇本にある ○ サーバサイドのレスポンスタイムは正常 (~50ms) であり、こんなに時間はかかっていない ● データ転送⾃体は⼀瞬で終わっている ● 複数の応答待ちが同時に発⽣し同時に完了する読み解けること

Slide 35

Slide 35 text

© LayerX Inc. 35 ● TCP 接続を中継する「何か」がいる ○ HTTP プロキシの場合はプロキシ接続の記録が残るので HTTP レベルではない ● 何か: 多くの場合ファイアウォール ○ TLS を復号して検査する機能を持つものが多い ● HTTP/2 により1つの TCP セッションで複数のリクエストを多重化している ○ ストリーム単位でバッファリングして復号 -> 問題なければクライアントに流す (?) ○ 製品によって実装は様々だがこのような挙動の製品もあるここから推測できること

Slide 36

Slide 36 text

© LayerX Inc. 36 ● かなりよくある問題の⼀つ ● 事業者側にできることはそう多くはない ○ HTTP/1.1 のみを使うことで体感速度が改善するケースもある ○ アセットをまとめる、minify するなどのパフォーマンスチューニングも有効ではある ● お客様側で問題解決する⽷⼝になる ○ 情シスの⽅に問い合わせていただき解決することは多い ○ フィルタリングルールの⾒直しなどどう対処するのか

Slide 37

Slide 37 text

メール

Slide 38

Slide 38 text

© LayerX Inc. 38 ● 2026年現在でも以下の性質を持っている ○ 特定企業やプラットフォームに⾮依存 ■ 異なるサービス間でも相互に通信が可能 ○ 個⼈や組織、システムなど、主体の種類を問わず同じ仕組みで通信できる ○ 送受信が⾮同期、相⼿に依存しない ○ テキスト以外の情報も送受信が可能 ○ 組織の境界を越えて公式な記録としても扱うことができる ● グローバルでオープンなメッセージ基盤！！！！ ○ 他の組織とつながるのに NDA を結ぶ必要もなく、 Enterprise Plan も不要 ○ 安価なサービスでも運⽤ができる令和にメール？？？

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© LayerX Inc. 42 ● メール環境も⾮常に多様 ○ SMTP Server ■ Postﬁx, Sendmail, Exchange, Domino, qmail, etc ○ SMTP Client ■ Gmail, Windows Mailer, Outlook, Apple Mail, Becky!, Thunderbird, etc ○ セキュリティゲートウェイ ■ メールを事前に検査してくれる (Relay としてふるまうものが多い) ○ ⾔語 ■ MIME によるエンコーディング ● 利⽤企業ごとに環境が混在 ○ 本当に多様かつ重要度が⾼くデバッグが難しい運⽤は割とたいへん

Slide 43

Slide 43 text

Slide 44

Slide 44 text

© LayerX Inc. 44 ● お客様がバクラクからメールを送っても送付先に届かない事象が発⽣ ● 外部サービス上のステータスは正常送信済み ○ エラーではないので逆に調査しにくい ● 送付先を確認しつつヒアリング ○ MX にはメール転送サービスのホストが記載されていた ○ メール転送先では “SMTPUTF8 に対応していないエラー” を確認できた Case 2: メールが届かない！ (最近の SMTP 編)

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© LayerX Inc. 46 ● 国際化メールアドレス (e.g. 寿司@段階.jp) に対応するための規格 (RFC6531, 6532) ● メールヘッダにおける Subject, From, Cc などに UTF-8 がそのまま⼊ることを許容する ○ MIME ヘッダ (Content-Type, Content-Transfer-Encoding) は引き続き使われる ○ 添付ファイルも MIME エンコーディングされ続ける ● 送受信を⾏う MTA 双⽅の対応が必要 ○ 対応している場合 EHLO に SMTPUTF8 を含むため判別可能 ○ 対応していない場合従来通り MIME エンコーディングして送付するか、送信元 MTA で bounce する ● 実装している MTA も増えている ○ Postﬁx は対応 (smtputf8_enable) ○ 利⽤していた外部サービスも対応 SMTPUTF8

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© LayerX Inc. 48 ● 送信元は受信元 (実態は Relay) が SMTPUTF8 をサポートしていると判断しメール送出 ○ エンドツーエンドで確認をするわけではない ● Relay は SMTPUTF8 で来たメールをそのまま転送先へ転送 ● 転送先が対応していないためエラーになる ● ここから先は Relay の実装 (設定) 依存 ○ Relay は受信を完了しており、送信元に送れなかったエラーを直接は返さない ■ DSN を返すことができれば通知できるが、そうでない場合はメールがロストする ○ 対応していない送信先に対し、メールをダウングレード (再エンコード) する規格はある (RFC6857) が、実装されている MTA は少ない ● 検証⽤の環境を Amazon EC2 に作成して⼀つひとつ検証 Relay だけが SMTPUTF8 をサポートすると起こること

Slide 49

Slide 49 text

© LayerX Inc. 49 ● そう簡単にはいかなかった ○ ⾃前の MTA ではないのである… ● 外部サービスの仕様を探る ○ 検証した結果、「添付ファイルのファイル名に⽇本語が使われていること」が SMTPUTF8 が使われる条件であることが判明 ○ ローマ字のみのファイル名でメール送付するか、別の機能によって添付ファイルを送らないことで回避可能なことがわかる ● SMTP Relay サービスは SMTPUTF8 を切ってほしい (切実) SMTPUTF8 をやめよう！

Slide 50

Slide 50 text

© LayerX Inc. 50 ● 「バクラクにファイル添付したメールを送ったが添付ファイルがない」という問い合わせ ● 「プリンターから直接」スキャンしたデータを送付されていることを確認 ○ プリンターもメールクライアントの⼀つ ● 確認したところそもそも添付ファイルが到着している気配がない ● Content-Type: message/partial Case 3: メールを正しく受け取れない

Slide 51

Slide 51 text

© LayerX Inc. 51 ● “メール本体” を分割することのできる MIME Type ○ RFC2046 ○ 分割されたメールはそれぞれ1通ずつのメールとして送信される ● ちなみに歴史は古く “message/partial” で検索すると2000年代前半の記事がたくさん… ○ そういう時期に必要だったものということで ● 対応するには受信側で組み⽴てなければならない ○ オチが⾒えてきましたね message/partial

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

DNS

Slide 55

Slide 55 text

© LayerX Inc. 55 ● システムから送信された通知のリンクが開けない！という問い合わせ ○ 複数のお客様で発⽣していた ● 通知状況トラックのため、外部サービスによる Click Tracking 機能を有効化していた ○ 外部サービスによる計測⽤エンドポイントに置き換えてリダイレクト ● エラー画⾯を⾒たところ DNS_PROBE_FINISHED_NXDOMAIN ● だが、 DNS レコードは正常に参照できているようにしか⾒えない ○ よく⾒ると外部サービスの計測⽤エンドポイントが36⾏のAレコードを返していた Case 4: クリックカウントの罠

Slide 56

Slide 56 text

© LayerX Inc. 56 ● DNS はデフォルトで UDP を使う。 UDP を⽤いる場合応答全体が512バイトに収まる必要がある ○ 今回のケースでは600バイトを超えていた ○ IPv6 メインになる場合にはさらに厳しくなる ● 512バイトを超える場合、 EDNS0 と呼ばれる DNS 拡張もしくは TCP に fallback する ● 企業ネットワーク内では以下のいずれかが問題になることが多い ○ ネットワーク内に置かれた DNS キャッシュサーバが両者に対応していない ○ 53/tcp の egress が塞がれており TCP fallback ができない ● 上記をクリアしない場合、単に DNS 応答がされないためクライアントからはエラーになる DNS の TCP fallback 問題

Slide 57

Slide 57 text

Slide 58

Slide 58 text

おわりに

Slide 59

Slide 59 text

© LayerX Inc. 59 ● 開発者、運⽤者としての仕事 ○ アプリケーション開発 -> Claude Code でだいたい書けちゃう ○ Terraform -> Claude Code で (略) ○ ログ分析、サーバサイドの障害分析 -> ⾃動化エージェントがバンバン出てきてる ● 組織における仕事も AI Based になってきた ○ 依頼対応 ○ 障害時ポストモーテムの作成 ○ ⽬標策定、振り返り、評価 ● けれど… かわりゆく SRE の領域

Slide 60

Slide 60 text

© LayerX Inc. 60 ● アプリケーション ● サードパーティの API ○ ⽣成 AI のエンドポイントも今のところほぼ同じように⾒える ● コンテナ ● OS ● ネットワーク ● 制御の⽅法が⼤きく変わりつつあるが、仕組み(プロコトル)が変化しているわけではないのが現状 ○ 将来的に変わりゆくだろうが、AI の出現で TCP/IP が変わるかというと？？？ ● 何より、こういうことに向き合うのって楽しい ○ もちろん程度によるけれど動いてるものはそんなに変わってない

Slide 61

Slide 61 text

© LayerX Inc. 61 ● システムはサーバーサイドで完結しない ○ むしろユーザー環境はサーバーサイド以上の複雑さと多様性をもつ ● ログやメトリクス上の「成功」は必ずしもユーザー体験としての成功を意味しない ○ ラストワンマイルのデリバリーがうまくいっているかは別の話 ○ SRE として、最終的なユーザー体験がどうなっているかにも気を配りたい ● プロトコルは同じでも実装や環境によって挙動が異なる ○ ゆえにデバッグが難しくなる ● 問題の再現が難しい状況でも、適切なコミュニケーションや仮説検証で原因を特定することは可能 ○ やっていきましょうまとめ

Slide 62

Slide 62 text

© LayerX Inc. 62 ● LayerXの各事業では SRE を積極採⽤しています ○ 特にバクラクSREにみんな来てくれ！！！！！！！１ ● AIに全⼒投球しつつも、「しぶい」ノウハウや調査⼒がとても重要です ○ メールの安定運⽤ ○ お客様環境を考慮したデバッグ ○ データベースに関わる課題解決 (テナント規模の増⼤、負荷、メンテナンス性) ○ パフォーマンス (データベースだけでなくアプリケーション処理や⾔語まで) ○ コスト最適化、セキュリティ、etc ● ビジネス, AI, ソフトウェア, インフラの全てを楽しんで向き合いたい⼈に⼼からお薦めします ○ 少しでも興味があればお声がけください We’re hiring

Slide 63

Slide 63 text

おわり