# しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 — transcript source ## 公式アブストラクト サーバは正常、メトリクスも問題なし、アラートもない。それでもお客様からは「使えない」という声が…このような “観測できない障害” に遭遇したことはありませんか？ 本セッションでは、企業向けプロダクトの運用に携わるエンジニアを主な対象として、ユーザー環境に起因する問題に対して実践的に切り分け・調査を行うための具体的なアプローチを解説します。 プロダクトとユーザーの間には、ブラウザ、メーラー、プリンター、ネットワーク機器といった無数のソフトウェア、そしてデバイスが存在します。とりわけ企業ネットワークにおいては、環境の差異やセキュリティへの取り組みによって「サーバサイドから見ているだけでは気づかない」問題が起こりやすい傾向があります。 こうした問題が起こると、どこに原因があろうとユーザーから見れば「使えないプロダクト」と感じられてしまいます。サービスの信頼性に責任を持つSREとしては、こうした問題にも踏み込んでいくことが求められます。 本セッションでは、発表者が企業向けプロダクトの運用において実際に遭遇した「ページが表示されない」「表示が遅い」「メールが届かない」といったトラブルを題材に、調査から解消に至るまでのプロセスを具体的に紹介します。業務効率化AIエージェントサービス「バクラク」の事例をもとに、HARファイルの読み解きによるパフォーマンス問題の特定、SMTPやメール仕様に起因する配送トラブル、DNSリゾルバと長大なレコードによる問題など、現代でも発生する“ラストワンマイル”の障害に対する実践的なデバッグ手法を解説します。 これらの知見を通じて、サーバサイドの観測だけでは捉えきれない問題に対して、再現性のある調査・切り分けを行い、ユーザー環境に踏み込んで解決できるようになるための視点と具体的な手法を提供します。 ## 登壇者略歴 株式会社LayerX 執行役員 CISO 兼 バクラク事業 VPoE 星 北斗 kani_bkanny 2024年1月に株式会社LayerXに入社。コーポレートエンジニアリング室 室長、バクラク事業部 PlatformEngineering部 SRE グループマネージャーを務め、2024年7月より部門執行役員 CISO、2025年10月より現職。クラウドとセキュリティと料理が好き。 ## 逐語文字起こし **しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践** **スピーカー: 星 北斗（株式会社LayerX 執行役員 CISO 兼 バクラク事業 VPoE）** --- そんなバクラクの基盤を作って運用しているチームが、SREチームとなっております。先ほどご紹介した全部のプロダクトを、横断しているチームで、今は4人でやっております。プロダクトの信頼性を保つということに責任を持って、主にパフォーマンスとかキャパシティプランニング、バックアップ、セキュリティ、あとは開発生産性だったりとか、そういったところの領域をやっていける。サービス基盤は、AWSの上にありまして、いろんな外部サービスとかに接続されていたりするわけです。いわゆるよくある構成だなという風に思っています。先ほどちょっと紹介したAIエージェントのための基盤も、同じインフラの上に乗っているという感じでございます。 というわけで、ざっくり会社とプロダクトの説明でございました。散々AIエージェントの話をしたんですけども、ここから先、AIの話は一切出てこないので、そのつもりで聞いていただければと思います。本題にいきましょう。 皆さん、普段のお仕事でも、プロダクトの運用に色々な形で関わられているんじゃないかなという風に思います。そんな中で、普段こんな経験をしたことはないでしょうか。 ある日お客様から問い合わせをいただくと。いわく、この機能が使えないとか、この機能が遅いとか、あるいはメールが届かないみたいな感じですね。サポートチームから連絡をもらって、調査を始めます。サーバのログとかメトリクスを見てみるんだけど、特に異常がなくて、普段通りのデータになってます。なので、サポートチームには、「サーバには異常がなかったので、たぶんお客様の環境の問題じゃないかな。色々再起動してみて、見てもらえますか」って伝えたりするんだけど、結局直らなくて、ある日チケットの返信がぷっつり途絶えちゃったりだとか、あるいはがっかりされちゃったりだとか、そういったことが起きて、モヤモヤすることってあると思うんですよね。 この時、サーバのメトリクスって話をしたんですけど、皆さんが見ているログとかメトリクスってどこのデータだと思いますかと。どこのデータだと思いますかね。 分かりやすいように、クライアントとインターネットとサーバの関係をマッピングした、極めて高度なネットワーク図をご用意しました。サーバサイドのログとかメトリクスっていうのは、つまりサーバのログとかメトリクスのことです。何を言っているのかという話なんですけども、つまりこの図において、右側の領域、このサーバサイドだけの領域を観測するためのデータなんですね。あくまでサーバ側で起きていることを理解するためのデータというのがサーバサイドのメトリクスになっています。 ところがですよ、実際に問題が起きているのは、さっきのケースでもあったんですけど、左側。サーバじゃなくて、クライアントだったりとか、そこに至るまでの通信環境だったりするわけなんですね。 クライアント側で起きている問題っていうのは、やっぱりサーバのログとかメトリクスから判断できないことっていうのがとっても多いような形になっています。 こういった形で、ログとかメトリクスっていうのが、実際にはどの領域を、どの領域のことを指しているのかっていうのを意識するのはめちゃめちゃ大事なことだと思ってます。サーバ上、例えばそのレスポンスタイムっていうことを1つ取ってみても、みんな、もはや使わないケースも多いかもしれないんですけど、Nginxの書いてあるやつだと、リクエストの最初のバイトを読み込んだら計測を始めて、レスポンスの最後のバイトをソケットに書き込んだら計測が終わるわけです。これって、でも、あくまでNginxから見た始まりと終わりであって、そのデータを受け取ったり、返し切る前後の通信先を示しているわけではないんですよね、実際には。 Nginxから見えるレスポンスタイムが100ミリ秒だったからといって、お客様の手元に100ミリ秒でデータが届いているわけではなくて、実際にはその間には、リバースプロキシだったりとか、ロードバランサー、クライアント側のプロキシとかゲートウェイがあったりするわけです。 さっきの図はめちゃくちゃ単純だったわけなんですけど、なので実際にはこんな感じで、色んなものが挟まっているわけです。なんですが、なんですが、これだけじゃないと。 ユーザー環境って200種類、200種類以上あると言われています。OSとかブラウザだけではなくて、特に企業のネットワークではそれが顕著で、色んなソフトウェアとかハードウェアが使われてコントロールされているわけです。 ネットワークのスイッチとか、ルーターとかファイアウォールだけじゃなくて、メーラーとかメールサーバとか、あとは、あるいはセキュリティゲートウェイとか。 EDRとか、プリンターとか、そういう無数に色んな要素があるんですけども、そういったものを組み合わせた環境が、お客様が我々が提供するサービスを使う環境になっているわけです。 なので、絵にするとこんな感じなんですけど、実際にはサーバからクライアント、というか、実際のそのユーザー、使う人に至るまでには、めちゃくちゃ色んな要素があります。サーバサイドのメトリクスは、この中、この中、この中の右端だけを示しているので、当然やっぱりここから見えるものっていうのは限られているわけなんですね。 ですので、我々として気をつけなきゃいけないというところは、トラブルがあった時、あるいは普段から、自分たちがコントロールできる範囲だけを対象にしてものを見ていないかと、いうことに関して気をつける必要があるという風に考えています。全人類が、好きとされている、モニタリングダッシュボードなんかも、結構便利なものだったりするわけなんですけども、やっぱりそのサーバサイドのメトリクスだけを見ている限りは、さっきの図の右端の話でしかないわけなんですね。 これだとユーザーの環境との組み合わせで起こる問題っていうのをうまくキャッチしていくっていうのはちょっと難しいわけです。実際そのボトルネックになっている場所を観測さえできないこともありますし、プロトコルが同じでもクライアントによって挙動が違ったりします。その結果、原因不明とか再現不能になってしまってお客様をがっかりさせてしまうということが起こるわけです。 までも、無茶言うなという話でもあります。そもそも管理主体というか責任を持っている側が違うわけですし、システム管理者が必ずしもその環境の管理者だとは限らないわけです。どういうことかというと、実際そのバクラクのお客様環境って、管理されているのは経理の方とか、そのいわゆる財務の方であることが多いわけなんですけども、他のシステム管理はいわゆる情シス部門の方が観ていたりします。 また、管理者であっても全てを把握しているわけではなくて、外部に構築とか運用とかを依頼されているケースもあったりします。 他にも、EDRをはじめ、セキュリティソフトってめちゃくちゃ色々あって、しかもその個々に、オリジナルティーと言えば言葉が良いんですけども、個々の挙動が色々と違いますと。そういったものを掴むのは非常に難しいわけなんですね。 なので、仕方ないかと。再起動で、ワンチャン直ってくれないかなと、言ったようなことを、つい考えてしまうわけです。わけなんですが、それでいいんですかというのが、今回行いたいようなお話でございます。我々、提供するサービスの信頼性に責任を持っている集団です。この信頼性というのは、お客様というか、ユーザーが使うことで初めて成立するものだと思っています。 僕はそう思ってます。なので、そのラストワンマイル、つまりお客様の手に届くその瞬間のトラブルにもできるだけ対応できたらいいなという風に思ってます。なんですが、やっぱりどうしても限界はあって、お客様環境でコントロールできないですし、その問題が起きた場所全部に出かけて行って直すってことも非現実的なわけなんですよね。ではどうするのかというと、できることはそのホテル、そのツールを使って情報を集めて、仮説を立てて検証して原因を特定すると、そういう、いわゆるよくあるトラブル解決ですね。同じようなことをやるというな形になります。ただ、この解決のための方法が、種類によって方法が異なったりするわけです。これをやり切るためには、やっぱりある程度数をこなしていって、その感覚というか、どういうところで問題が起きてどう考えるのかというところを、磨いていく必要があると思ってます。というわけで、今日はこのあたり、私がその遭遇したトラブル解決の中で、解決のために多くやっていることですとか、あるいは具体的なケースに関して、1つのケースとして、共有できればなという風に思っています。 まず、お客様環境の調査をするためには何が必要でしょうか。 色々、エンドユーザーのパフォーマンスを可視化するみたいな色々あると思うんですけども、私が一番大事なことだと思っているのは、お客様とのコミュニケーションのためのチャネルをきちんと確立することだと思っています。カスタマーサポートの方とか、あとはあるいは営業の方とかですね、皆さんの会社にもそういうその矢面に立ってお客様とコミュニケーションを取ってくださる方っていると思います。そうした方と密にやり取りできる体制を作るというところがまずステップ1。そこを通して可能な限り一時情報を極めてもらうと。受け取ったチケットとかメールとか添付ファイルですね。会話とか、そういったものを、直接知ることができると尚いいなという風に思ってます。また聞きでこれを推測しようとすると、やっぱり問題がさらに複雑になったりするので、できるだけ一時情報に触れるというところがすごい大事な部分かなという風に思っています。そういうチャネルを通して、ユーザーからやっぱり情報をいただきます。この時に、よくあるヒアリング項目だったりだとかは、パターンとして自分の中で持っておくといいですね。 OSとかブラウザとかメールのクライアントのバージョンとか、あとはハードウェアの性能とか、特にセキュリティに関する環境、これが問題を引き起こすことがすごくよくあるんですけども、そういったものだったりとかを集めていきます。この時可能な限りですけど、そのユーザーとの往復、いわゆるその聞いて返してもらう、聞いて返してもらうっていうのをできるだけ減らすっていうのは、すごい大事なことだなという風に思ってます。ただでさえ、システムが期待通り動いていない状況でユーザーが協力してくれているわけですし、そのヒアリングした内容を確認するために、例えば情シス部門とか他のチームとやり取りしなきゃいけないってことがあるわけなんですね。そういったそのサポートの中の体験も含めて、総合したものがプロダクトの体験だと思ってますので、そういったところで、非常に重要な部分かなというところ。最後に先ほど一時情報の話をしたんですが、可能な限り生データだったり、ログだったりというのを貰うのが非常に大事だなという風に思ってます。これは言うまでもないかなというところです。 利用環境を、まとめて収集できるようにチェックを作っておくのもいいなという風に思ってます。バクラクでは、ブラウザで実行できる環境情報収集の仕組みを用意しています。なので、トラブルがあったお客様には「この画面を送って、これを実行して、その結果を返してください」というようなことをやってます。実際にはやっぱりクライアント側のJSで、そのデータ転送する時の帯域幅だったりだとか、そのプロダクトのエンドポイントへのレイテンシーを測定したり、あとはネットワークがどこにあるのかっていうのを調べることができるようになってます。 結果が、BASE64でエンコードされるんで、それをメールでいただいて、こちらでデコードすると、これだけでも知ることができる情報の量っていうのは結構多かったりするという感じです。 そこから、自社システムとヒアリングした環境を繋いで分解してみます。まずはちゃんと自社のシステムに問題がないか確認すると、これはサーバサイドの確認できますし、ユーザーのヒアリングがそのあとにいいと。そこからメトリクスとかヒアリングで得た情報を、総合して問題が起こり得る場所を整理していく。図にしてもいいと思いますが、そうしていくと、その問題が起きるとしたらどこかと、いうところがだんだん分かってきます。あとはそれぞれの場所について仮説を立てて、確認したり検証していくというようなことですね。 ヒアリングした環境にその近いものを作れると尚いいと思うんですけども、その自社のドキュメントとか自社、自分側での検証で、検証できるものはいっぱいあるので、例えばネットワークの帯域幅とかパケットのドロップが問題になっているなっていう風に思ったら、そういう環境というかそういうルーターを、意図的に作ったりすることもできるわけですね。なので、そういったものは自分の手、自分の手で作ってしまって、それでも難しいものは追加でヒアリングを進めていくというのが通常よくある流れかなという風に思います。 さて、ベースラインの情報収集の話はしたので、次に、実際の問題の例と、その調査ですとか対処を、どういった形でやっていったのかというところに関してお話をしていきます。まずはWebブラウザ編でございます。 最初のケース、システムが遅いというやつですね。皆さんもよく聞くんじゃないでしょうか。オフィスネットワークで使っているんだけど、読み込みに時間がめっちゃかかると。他のシステムには問題がないのに、みたいなやつですね。よくあるかなという風に思います。インターネット環境の障害は特になくて、マシンのスペックとかも、確認したけど全然申し分ないものが使われていそうです。ただ、サーバ側でもログを見たんだけど、やっぱりレスポンスタイムは正常。なので、すべてのこちら側で確認できるものに関しては、正常なものが返ってきてます。こっから分かることはまず1つで、サーバがレスポンスしてからクライアントに届くまで、あるいはそのクライアントでそれが最終的に処理されるまでに、何らかの問題が起きているということが分かります。なので、この調査のために非常に強力な、HARファイルというやつを貰うようにしましょうということでございます。 HARファイル、皆さん使ったことがある方も、結構いるんじゃないかなという風に思います。ブラウザにおいて、ウェブサイトとのやり取り、特定の処理にどれぐらいかかったかだとか、そういう、そのパフォーマンスデータを含む、データを保持するためのフォーマットです。実際は中身JSONになってます。ブラウザでも読めますし、色んなHARビューワーと言われるやつでも、読むこともできるようになってます。このデータをお客様の手元で取得いただいてそれを送っていただくというのが、まずステップ1かなというところです。ただ1点注意として、そのPOSTのパラメータとか、クッキーのデータだったりとか、そういう結構機微な情報を送るので、この受け渡しとか取り扱いは非常に注意が必要です。HARサニタイザーという、クッキーの情報なんかを除去する処理をするものもあるので、そういったものを使ってから取り扱うといいかなと思います。 HARの何が便利かというと、パフォーマンスとか接続性とか、そのお客様のブラウザで起きている事実を得るために非常に解像度の高い情報があるというところが一番デカい部分です。DNSの解決結果とかヘッダーとかそういうデータもありますし、何よりその取得のために、お客様にそう大きく負荷をかける必要もないんですよね。「ソフトを実行してください」という手順に従って、ブラウザの操作をしてくださいという感じになります。なので、より深いヒアリングをする前に、情報収集をする前に、洞察を一定掴むことができます。こうしたデータをリモートで集めるための仕組みとしてRUM、リアルユーザーモニタリングですね、というやつもあったりします。あるんですけど、やっぱりそれぞれのリクエストに応じてログを収集するんで、どうしてもボリュームがデカくなりがちですね。 皆さんも、マネージドサービスに送信したログの、コスト管理に苦しんだことが、たぶん誰しも1回はあるんじゃないかなという風に思うんですけども、やっぱり全量を集めようとするとどうしてもコストが高いと。大体の場合はなので、サンプリングすると思うんですけど、今度サンプリングしちゃうと、トラブルが起きた時の解決がどうしても難しくなっちゃいます。なので、個別ケースに向き合う時には、直接HARを貰うというのが一番近道かなという風に思います。 HARを使うと、ネットワークコネクションの様子も観察をすることができます。 例えばどういうものが入っているかというと、ブラウザからのリクエストに待ちに入れられているキューの時間だったりだとか、ユーザー側のプロキシに接続するまでの時間とか、DNSルックアップする時間、そっからTCPとかTLSのハンドシェイクをする時間などが入っています。 そこに、さらにリクエストの送信にかかっている時間だったりだとか、サーバの応答を待つ時間。さっきサーバ側のメトリクスの話をしたんですけど、サーバからレスポンスが返ってくるまでに、これだけのイベントがブラウザ側で起きているわけですね。そしてコンテンツのダウンロードと。皆さんもよく、デベロッパーコンソールとかで見ていると思うんですけど、ページを表示する時に、このアセットについてそのデータを並べたウォーターフォールチャートを見ることができたりもします。 このウォーターフォールチャートだったりを眺めるのも、かなり有用な手立ての1つかなという風に考えてます。これが今回の例なんですけど、これを見ると、1つのことが分かります。どういうことが読み取れるかというと、サーバへのTCP接続にそもそも時間がかかっているし、リクエストの送信にデータを受け取るのに時間がかかっていると。ネットワーク上は日本にいるはずなんだけども、アメリカぐらいのレイテンシーになってます。サーバサイドではレスポンスタイムが50ミリ秒とかなんで、あれおかしいなという風に言われます。 ただ、データの転送自体は、この下の緑の、緑じゃない、一番右の、青いグラフですけど、一瞬で終わっています。さっきのウォーターフォールチャートを見ると分かるんですけど、複数の応答待ちが同時に起きて同時に終わるっていうような感じの挙動になっています。 こっからおそらく、クライアントとサーバの間にTCP接続を中継する何かがいるんだなっていうのが、なんとなく分かってきます。HTTPプロキシだったり、プロキシのコネクションの記録とかがあるんで、それがないので、TCPレイヤーかなという。このケースはだいたいファイアウォールかなという風に思ってます。TLSを、間で復号して検査したりするわけですね。この接続は、HTTP/2が使われてたんですけど、HTTP/2の場合は、1つのTCPセッションの中で、1つというか複数のリクエストを、多重化して送受信するという形になっているので、おそらくTCPセッションとか、あるいはHTTP/2のストリーム単位で、バッファリングして復号して検査してクライアントに渡すみたいなことをしているんだろうなというのが、だいたいここから想像がつくかなというところです。要は一定時間バッファして、まとめてバホッと送るっていうような挙動をしているわけですね。 まあこういうファイアウォールは色々あるんですけど、こういう挙動をする製品もありますというところでございます。 ここまでで、おそらくユーザー側のセキュリティ製品がボトルネックになってそうだなということが分かりました。これは、企業ネットワークのよくある問題の1つで、残念ながら、事業者側でできることはそう多くはないです。HTTP/2を切ることで、体感上の速度が、改善したりすることもあるんですけど、あとはアセットをまとめたり、ミニファイするみたいなチューニングは有効なこともあります。ただ、お客様側で解決する大きな糸口になるかなっていう風に思ってまして、そこから情シスの方に問い合わせてチューニングのためのルールを改善してもらう。 いうところで改善するということもよくあったりします。 仕様です。さてブラウザの話はしたので、次はメールにいきましょう。 令和にメールと、思うかもしれないんですけど、皆さんメールってすごいんですよ、皆さん。Slack大好き、Slackとか色々な、チャットツール大好きだと思うんですけど、メールってすごいと僕は思ってます。2026年でも、特定の企業とかプラットフォームに依存しなくて、違うサービスの間での通信もできますし、個人とか組織とか、そのシステムだったりだとか、主体の、主体を問わずに、同じシステムでやり取りができます。送受信も非同期で相手に依存しませんし、テキストじゃない情報も送受信できる。組織の境界を超えて、公式な記録として扱う例もあったりするわけですよね。メールのログは裁判に使われたりするケースもあったりするわけです。というわけで、メールは実はグローバルで、オープンなメッセージ基盤なわけです。はい。他の組織と繋がるのにNDAを巻く必要もないですし、エンタープライズプランもいらないわけですよね。 っていうところで。まあ、かつ、安価なサービスで十分に運用できたりもします。色々メールに関しては、言われているところもあるんですけど、僕は個人的には結構好きな、好きな仕組みの1つです。 バクラクでもメールは、通知手段の1つとして多く使われています。お客様が、ワークフローを実行する時に、そのワークフローからの通知として扱われることもあるんですが、お客様の取引先にメールを送付するみたいなユースケースもあったりします。 あとは、受信もします。請求書ってメールで受け取ることよくあると思うんですけど、バクラクはそれをシステムで受信して、自動的にダウンロードしにいったりますとか、あるいはパースしてデータ化するということをやってます。 というわけで、システムとシステムであったりだとか、システムと人を繋ぐための重要な手段の1つがメールとなっています。 そんなメールは、すごく古いSMTPというプロトコルによって、歴史の、歴史の長いプロトコルに、支えられています。はい。いわゆるSMTPサーバがメーラーとかウェブアプリケーションから、クライアントからメールを受け取って相手先に転送するという仕組みになります。はい。これめっちゃ歴史の長いプロトコルですよね。 SMTPの中では、転送をすることもできます。あるサーバから、あるSMTPサーバから、別なSMTPサーバにメールを送って、さらにそのサーバから別なサーバにメールを転送するというような形で転送も、転送もしますというところです。 そんなSMTPサーバ、SMTPなんですけど、運用は割と大変だなという風に思ってます。はい。メールは、SMTPサーバを自前で運用したことがある方がどれくらいいるか分からないんですけど、結構大変だなと思ってます。メール環境、バラエティがめっちゃ多くて、サーバだけ見てもそうだし、クライアントの種類も多いわけです。メールの検査をするゲートウェイもありますし、あと、言語もそうですよね。はい。メールの文字化けというやつに苦しんだ方も、いっぱいいるんじゃないかなという風に思いまが、MIMEという仕組みでエンコーディングされたりするわけです。こういう形で利用企業とか人によって環境が混在しているんですけど、メッセージ基盤としては重要度が高いというわけですね。バグだったりとか、ちゃんと運用する難易度がそこそこ高いものになってます。 ちゃんと運用するのが難しいんで、最近は何らかのクラウドサービスを使うのが非常に一般的だなと思います。メールの届く可能性を、到達性を上げつつ、複雑性を下げると。 ためのとても便利なものです。バクラクでも、外部サービスを使ってます。送信は普通にやるだけなんですが、受信は外部サービスから、Webhookを受け取って、Amazon S3に保存して連携するみたいなことをやってます。 ただ、クラウドサービスだから問題ないかというと、やはり、メールって難しくて、色んな問題が起こるわけです。というわけで、次のケースはメールが届かないというものでございます。 バクラクでメールを送っても送付先に届かないと。我々が使っているサービスのログは、ログを見ると正常です。はい。エラーじゃないので逆に調査しにくいんですよね。 はい。送信先の、ドメインなんかも実際にお伺いしながら、ヒアリングを進めていくと、送付先からSMTPUTF8に対応していないエラーが出ていたという、重要な事実を知ることができました。また、MXレコード見てみると、とあるメール転送サービスのホストを指していました。 はい。皆さん、SMTPUTF8ってご存じですか。 ご存じですか。マジで全然伝わらないなっていう気持ちでいながら喋っているんですが、さっきの構成をざっくり図にするとこんな感じで、間にリレーサーバが挟まってるんですけど、この真ん中でメールが落ちているという現象になってます。何なんだろうと思うんですけど、このキーワードは非常に役に立つと。 SMTPUTF8というのは、国際化メールアドレスに対応するような規格です。はい。このsushi@だんげ.jp、このだんげ.jpというのは僕が持ってるドメインなんですけど、まあこういう形で、いわゆるメールアドレスに日本語だったりだとか、そのマルチバイトの文字が使われているケースに対応するような規格になってます。これを使うと、本来メールヘッダーってMIMEエンコードされるべきなんですけども、MIMEエンコードされる必要のないメールヘッダーにUTF-8をそのまま入れて送ることができるようになってます。 ただ、送受信をするMTAの両方で対応する必要があるので、対応する場合はSMTPグリーティングというか、HELLO、HELLOというそのメッセージを最初に送るんですけど、それに対してEHLOというメッセージを返してくれます。その中にSMTPUTF8って対応しているものが書いてあるので判別ができるようになってます。なので、ここで対応していれば、UTF-8のまま送るし、対応してなければMIMEエンコーディングして送るというような対応をとるというところです。MTAの対応はすごく増えて、例えばPostfixなんかは、でも使えますし、我々が使ってた外部サービスも対応してましたと。 一見すごく便利なものに見えるんですけど、消耗するパターンもあるというのか、さっき話した、転送のケースでございます。はい。真ん中に、SMTPリレーがいるというところで、左側が対応している、真ん中のリレーサーバも対応している、ただしデスティネーションが対応していないというような構成の場合は、非常に不幸なことが起こります。 転送サーバだけはSMTPUTF8をサポートしているとどういうことが起きるかというと、送信元は、受信元、実際はリレーなんですけど、がSMTPUTF8をサポートしていると判断してメールを送ります。ただ、これはエンドツーエンドで確認するわけじゃないので、転送先のことは送信元は知らないわけです。リレーは、SMTPUTF8できたメールをそのまま転送先に転送します。ここで転送先が対応してないためにエラーになるんですけど、ここから先がリレーの実装依存で、リレーは実際にはもう受信を完了していて送信元に、送れなかったエラーを直接、その送るかどうか、直接は返さないことがあるわけです。ここに、通知を送る仕組みもありまして、それを返すことができれば通知されるんですけど、そうでない場合はメールがサイレントにロストするというような形になってます。 はい。今回ヒットしたケースでは、サイレントにロストする仕様となってしまっていたというようなところですね。実際には対応していない送信先に対してその中継、中継中に、メールをダウングレードするっていう手法もあったりするんですが、こっちに関しては実際にもう今実装されているMTAはそんなに多くないというか、たぶんほぼないかなっていうような状態になってます。っていうようなものですね、Amazon EC2の上に検証の環境を構築して検証したりするわけです。はい。 じゃあ、SMTPUTF8をやめようと言いたくなるんですが、そう簡単にはいかないと。自前のMTA、MTAではないので。ただ、外部サービスの仕様を探っていくと、添付ファイルのファイル名に日本語が使われていると、SMTPUTF8が使われるということが判明したので、そこで、どうにか回避する方法を見つけて回避してもらうというようなところでございます。あらゆるリレーサービスは、SMTPUTF8に対応してほしいなという風に思ってますというところでございます。次はメールを正しく受け取れないケースですね。これは、バクラクにファイル添付したメールを送ったんですけど、添付ファイルがないという問い合わせをいただきました。で、聞いていくと、プリンターから直接送りましたという風に言われました。領収書とか、プリンターでスキャンしてそのまま送られるケースっていうのが多々あります。 で、確認したところそもそも添付ファイルが、全然到達している気配がなくて、空のメールが送られているみたいな感じでした。ただ、コンテンツタイプの中に、message/partialというものが、コンテンツタイプの中に含まれていました。 message/partialって皆さんごじでしょうか。 ネットで、ググると、2000年代前半の記事が大変出てくるようなものになってます。メール本体を分割することができる仕様みたいだという、分割されたメールはそれぞれ1通のメールとして送信されるというところです。対応するには、これを、受信側で組み立てなければならないということで、パズルのピースが見えてきたかなというふうに思うんですけども、外部サービスには、当然、メッセージパシャールを処理するような機能がなくて、個々のメールは、ボディを考慮しない形でそれぞれ空のメールとして着信するということが判明しました。 で、なので添付ファイルがなくなっちゃいます。さすがにこれは回避できないかなっていう風に思ったんですが、なんと、プリンター側の設定で、お客様へのヒアリングでプリンターの型番を聞きまして、その型番から、ドキュメントをさがしてみていたところ、プリンターの機種で、ドキュメントを確認したら、スキャンファイルをメール送付する際の分割形式という、めちゃくちゃマニアックな項目があって、その中で、設定項目として明記はされてないんですけど、メッセージパシャールで送付するか、ファイルのページそのものを分割して送付するかっていうものが選べるようになってまして、それを、分割して送付いただく設定にすることで回避ができたというものになってます。まあ、そういうこともあるというところです。最後DNSですね。 終わるな。クリックカウント、システムから送付、送信された通知のリンクを開けないということが、複数のお客様で急に発生し始めます。 我々あの通知状況をトラッキングするために、外部サービスでクリックトラッキングの機能を使ったりとかしていました。でお客様から送られたエラーから見ると、NXDOMAIN、つまりドメインが引けませんというようなエラーが返ってくると。ただ、DNSレコードを見ると、正常に参照できているようにしか見えないわけです。なんですが、よくよく見ると、このエンドポイントが、36行のAレコードを返してたと。 これによって何が起こるか、DNSのTCPフォールバック問題が起きます。いわゆる、DNSは、デフォルトにUDPを使うんですが、UDPを使う場合は応答全体を512バイトに収まる必要がある。ただ今回のケースは、Aレコードが36行もあったので600バイトを超えてました。で、 512バイト超える場合は、EDNS0というDNSの拡張か、もしくはTCPにフォールバックをする必要がある。ただ、企業ネットワークの中で、ネットワーク内に置かれたDNSのキャッシュサーバが、これらに対応していないか、あるいは、TCP53番が、外に出るためのイーグレスが塞がれていてTCPフォールバックできないみたいなケースが多々あります。 というわけで、こういう時には単にDNS応答がされないのでクライアントからエラーが返ってくると。 ただし、これはサービスプロバイダー側から観測できないんですよ。みんな、DNS、普通にドメインの正引きのテストが落ちるだけなんで、サービスプロバイダー側からしても特にエラーとして何かが返ってくるわけではないというところですね。サービスプロバイダーに直接コンタクトして、こういうことが起きてこういう、こういうところで困るからなんとかしてくれって話を、懇々と説明して解決してもらうと。 いうところが必要になりますというところでございます。 喋りきってきたな。だんだんですね。ここまで色んなケースを紹介してきたので、最後に、ご静聴、まとめたいと思います。 SREの領域における仕事はめちゃくちゃ変わってきてます。開発者とか運用者としての仕事も、アプリケーション開発とか、Terraform書いたりとか、ログ分析とか、サーバサイド of 障害分析とか、AIエージェントとかっていうやつで、シュッとできるような、時代になってきましたし、組織における仕事も、AIベースに結構なってきたなっていう風に思ってます。なんですが、やっぱり動いてるもの、上で動いてるものって別にもうそんな変わってないわけです。アプリケーションがあってAPIがあってコンテナがあってOSがあってネットワークがあってとかいう、そういったものに関しては特に変わってないし、制御の方法は変わりつつあるんですけど、仕組みが変化しているわけではないという見当です。将来的に変わりゆくものだと、ものかもしれないけど、AIの出現でじゃあTCPIPが急速に置き換えられるかというとそうではないわけですね。なので、そうしたプロトコルだったりだとかどう動いているかっていうのをきちんと把握して、広い視野で動いて問題を解決していくっていうことが、これからの人間にも求められることなんじゃないかなという風に思っています。何より、こういうの楽しくないですか。 というのを、皆さんに伝えたくて、僕は楽しいなという風に思っています。AIでできるかもしれないですけど、簡単には渡したくないなっていう気持ちもちょっとだけあったりするというところです。というわけでまとめでございます。システムは、サーバサイドで完結しないので、むしろユーザー環境はサーバサイド以上の複雑さと多様性を持っていますし、 ログとかメトリクス上の成功というのは、必ずしも、最終的なユーザー体験としての成功を意味しないわけです。ラストワンマイルのデリバリーが上手くいっているかどうかというのは別の話ですし、 そこに、やっぱりそこも信頼性の1つとして捉えてSREとして、最終的なユーザー体験がどうなっているかによっても、にも寄与したいなという風に思ってます。プロトコルは同じでも、実装とか環境によって挙動も異なるんで、よりデバッグが難しくなるんですが、問題の再現が難しい状況であっても、適切なコミュニケーションだとか、仮説の検証で原因を特定することができるので、やっていきましょうというところでございます。 最後に、LayerXでは各事業による、SREを積極採用してまして、特にバクラクSREめちゃめちゃ募集してます。皆来てほしいなというところでございます。AIに全力投球しつつも、こういう渋いノウハウとか調査力、あとは執着力って言うんですかね、がとても大です。メールの安定運用もそうだし、お客様環境を考慮したWebもそうだし、データベースに関わる課題解決、パフォーマンスとか、コスト最適化、セキュリティとか色々あるんですけども、そういったところ、ビジネスとAIとソフトウェアとインフラと、全部を楽しんで向き合いたい人に心からお勧めしたい募集でございますので、少しでも声、興味がある方は、この後、色んなところに僕たちも、僕も引きますんで、ぜひお声がけいただければと思います。 というところで、ジャスト30分かな。終わりにしたいと思います。今日ありがとうございました。