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

Transcript

1. © LayerX Inc. しぶい SRE サーバから⾒えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 Hokuto Hoshi (kanny@layerx.co.jp) CISO, VP of Engineering (Bakuraku Div), LayerX Inc. 2026/07/11 SRE NEXT 2026
2. © LayerX Inc. 2 • 株式会社 LayerX 執⾏役員 CISO 兼 バクラク事業部 VP of Engineering ◦ 全社の情報セキュリティとバクラク事業部のエンジニア組織責任者 • コーポレートエンジニアリング室⻑, CTO 室⻑ バクラク事業部 プラットフォーム開発本部⻑ 元 SRE グループマネージャー (~2026/06) • プロダクトのフロントつくる以外の技術だいたい担当 • 2024年1⽉にLayerX⼊社。前職では⼤規模レシピサービスのセキュリティエンジニア、 SRE、コーポレートエンジニア、海外本社出向などを経て2023年に CTO 兼 CISO • 今⽇は組織の話も経営の話もほとんどしません 星 北⽃ (HOSHI, Hokuto) / @kani_b
3. LayerX とバクラクについて
4. 4 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに、複合的な事業を通して⽇本の社会 課題を解決し、AIの⼒で⼈々の創造⼒がより発揮される未来をつくります。 事業紹介 バクラク事業 バックオフィス向け AIエージェントサービスを提供 Fintech事業 資産運⽤サービス 「ALTERNA（オルタナ）」を提供 Ai Workforce事業 エンタープライズ向け AIプラットフォームを提供 Security事業 AIエージェントによる ⾃律的なペネトレーションテストを提供
5. 5 © LayerX Inc. LayerX のバクラク事業
6. 6 「バクラク」の事業領域 Coming Soon AIエージェント HCM領域 (人的資本管理) 稟議・ワークフロー 領域 BSM / ARM領域 （債務・債権管理） Payment 領域
7. © LayerX Inc. 7 バクラクのAI Agent機能 バクラク債権管理、「⼊⾦消込エージェント」を提供開始。⽇々のログイン不 要で⼊⾦確認から消込まで⾃動化 差し戻しゼロへ。バクラク、AIエージェント「AI申請レビュー」をリリース。 AIが⾃社の規程‧ルールに基づき経費精算申請を即時レビュー LayerX、「バクラクAIエージェント」の新機能として「領収書分割エージェン ト」を提供開始 AIエージェント「AI明細仕訳」 をリリース。明細OCR×⽣成AIで、明細⾏が多 い‧毎回取引内容が変わる請求書の処理を⾃動化。 - バクラク バクラク経費精算、AIが申請不備を検知‧指摘する「AI申請レビュー」全ユー ザーへの提供開始 〜9割の企業が抱える「⼿戻り」を解消。設定機能アップ デートにより、⾃社規定のAI実装が容易に LayerX、「バクラクAIエージェント」の新機能として「AI勤怠初期設定」を提 供開始 AIが就業規則を読み解き、複雑な有給休暇の付与ルールを⾃動提案
8. © LayerX Inc. 8 • 複数プロダクトを横断する少⼈数チーム • プロダクトの信頼性を保つことに責任を持つ ◦ 可⽤性、パフォーマンス、キャパシティ、バックアップ、セキュリティ • サービス基盤は AWS に展開、複数の外部 API などに接続して利⽤ ◦ いわゆる「よくある構成」 • AI エージェントのための基盤も同じインフラ上に展開 バクラクの SRE
9. こんな経験ありませんか？
10. © LayerX Inc. 10 • 「◯◯という機能が使えない」「遅い」「メールが届かない」etc… • サポートチームから連絡を受けて、 調査開始 • サーバーのログやメトリクスを⾒てみるが、異常は⾒当たらない • サポートへの返答 ◦ 「サーバー側に異常はありませんでした。おそらくお客様の環境に起因するのではないでしょ うか。ブラウザや端末、ルーターを再起動いただくようご案内ください」 • ⾊々試すも直らず、がっかりされてしまう お客様からの問い合わせ
11. © LayerX Inc. 11 「サーバーサイドのメトリクス」が⽰すもの クライアント (ブラウザ) サーバー
12. © LayerX Inc. 12 「サーバーサイドのメトリクス」が⽰すもの クライアント (ブラウザ) ここで起きていること サーバー
13. © LayerX Inc. 13 実際に問題が起きているのは、クライアント側 クライアント (ブラウザ) サーバー
14. © LayerX Inc. 14 • いわゆる「レスポンスタイム」の計測はサーバ上で⾏われる ◦ 例えば nginx の場合 ◦ リクエストの最初のバイトを読み込んだら計測開始 ◦ レスポンスの最後のバイトをソケットに書き込んだら計測終了 • 「受け取った」「返し切った」先は、クライアント (ユーザ) と直結しているわけではない ◦ サーバ側のリバースプロキシやロードバランサ ◦ クライアント側のプロキシ、ゲートウェイ そのメトリクスは何を⽰しているのか？
15. © LayerX Inc. 15 実際には、こう クライアント (ブラウザ) サーバ ロードバランサ ファイアウォール
16. © LayerX Inc. 16 • OS やブラウザだけじゃない • 特に企業ネットワークには多くのソフトウェアや機器が使われ、コントロールされている ◦ メール環境 ◦ ネットワーク機器 (スイッチ、ルーター、ファイアウォール) ◦ セキュリティ機器 (ゲートウェイ) ◦ 構成管理 (MDM) ◦ セキュリティソフト (アンチウイルス、EDR、Web フィルタ) ◦ プリンター • 無数に存在するこれらの要素を組み合わせた環境が、個々のお客様の環境となる 200種類以上あるユーザー環境
17. © LayerX Inc. 17 多数の異なる環境から使われている サーバ ロードバランサ ここだけを⾒ても 原因はわからない
18. © LayerX Inc. 18 • ⾃らがコントロールできる範囲だけを⾒ていないか ◦ サーバー上のログ ◦ モニタリングサービスのメトリクス、外形監視 ◦ 依存している SaaS のステータス ◦ これらでは図の「右端」しか⾒たことにならない • ユーザーの環境との組み合わせで起こる問題に対処できない ◦ 実際にボトルネックになっている箇所を観察さえできないことがある ◦ 同じプロトコルであってもクライアントによって挙動は異なる • 結果として「原因不明」「再現不能」となってしまう 「サーバーサイド」だけではわからない
19. © LayerX Inc. 19 • 管理主体が異なる ◦ そもそも⾃社の環境ではない ◦ システム管理者 = 環境の管理者とも限らない ◦ 例: システムのお客様環境を管理するのは財務部⾨の⽅だが、システム管理は 情報システム部⾨が⾏う • 管理者であっても全てを把握しているわけではない ◦ 外部に委託されるようなケースも存在する ◦ ソフトウェアの個々の挙動をつかむことは難しい 「お客様環境」のデバッグも難しい
20. © LayerX Inc. 20 • 「サービスの信頼性」は、お客様に使ってもらってこそ成り⽴つ ◦ ラストワンマイルのトラブルにもできる限り対応したい • どうしても限界はある ◦ お客様環境をコントロールすることはできない ◦ 全ての環境調査に出かけていくことも⾮現実的 • ではどうするのか？ ◦ 持てる⼿段を使って情報を集め、仮説を⽴て検証し、原因を特定する ◦ よくあるトラブル解決と同じ流れではある • トラブルの種類によって⽅法は異なる ◦ 数をこなして感覚を磨いていく ◦ 「よくやるパターン」と「具体的なケース」について紹介します それで良いのだろうか
21. お客様環境の調査をするために
22. © LayerX Inc. 22 • カスタマーサポートや営業など、コミュニケーションを担当する⼈と密にやり取りする ◦ 問い合わせを SRE が直接受けることは多くない (はず) • 可能な限り⼀次情報を受け渡してもらう ◦ 受け取ったチケット、メールやファイル、会話の内容などを直接⾒られるとなおよい ◦ ⼜聞きは問題をさらに複雑にする コミュニケーションチャネルの確⽴と情報収集
23. © LayerX Inc. 23 • ヒアリングしたい項⽬をパターン化しておく ◦ 使われているソフトウェア (OS, ブラウザ, メールクライアント, バージョン) ◦ ハードウェアの性能 ◦ 特にセキュリティに関するソフトウェア (EDR、フィルタ、プロキシ) • ユーザーとの往復を可能な限り減らすことを意識する ◦ 特に、ユーザーがヒアリング内容を転送しなければならないような場合 ◦ サポート中の体験も含めて、サービスの体験 • 可能な限り⽣データをいただく ◦ ログファイルなどを送っていただく場合 ユーザーからの情報収集
24. © LayerX Inc. 24 • ブラウザで実⾏できる環境情報収集のしくみ • データ転送時の帯域幅、各プロダクトエンドポイントへのレイテンシーを測定できる • エンコードした測定結果をメールなどで受け渡してもらい分析する 利⽤環境チェッカー
25. © LayerX Inc. 25 • まずはきちんと⾃社システムに問題がないかを確認する ◦ ログやメトリクスから状況を読み取る ◦ ユーザーからの情報収集はその後で • ⾃社システムの構成と、ヒアリング環境を接続して、問題が起こりうる箇所を整理する ◦ メトリクスから読み取れた範囲を明確にしておく ◦ 図にしても良い • 問題の仮説を⽴てて、確認検証していく ◦ ヒアリングした環境に近い環境を作れるとなおよい ◦ ⾃社側のドキュメントや検証で確認できることも多くある ◦ 難しいものは追加でヒアリングを進めていく ⾃社システムとヒアリング環境の分解
26. 問題の例とその調査、対処
27. Webブラウザ
28. © LayerX Inc. 28 • オフィスネットワークの中で使っているが、読み込みに⾮常に時間がかかる ◦ サーバーサイドのログを特定したが、レスポンスタイムは正常 • 他のシステムは問題なく使えている、インターネット環境の障害もない • クライアントのスペックも⼗分なものが使われている • ヒアリングから、サーバーがレスポンスしてからクライアントに届くまでに問題が起きている であろうことは明らかなので、調査のために HAR ファイルをいただく Case 1: システムが遅い！
29. © LayerX Inc. 29 • ブラウザによるサイトとのやり取り (パフォーマンスデータを含む) を保持する フォーマット ◦ 実体は JSON • ブラウザや各種 HAR ビューワで読むことが できる • POST パラメータや Cookie など機微な データが含まれるため、受け渡しや取り扱い には注意が必要 ◦ HAR Sanitizer などを使う HAR (HTTP Archive)
30. © LayerX Inc. 30 • パフォーマンスに関する情報を得るうえで、⾮常に解像度の⾼い情報 • お客様のブラウザで起きている事実を得るための、簡単な⼿段 ◦ DNS の解決結果、ヘッダ、パフォーマンス測定結果をはじめとしたデータ ◦ 取得のためにお客様に⼤きな負担をかけない ▪ より深いヒアリングをする前に洞察を得ることができる • リモートで近いデータを集める仕組みとして RUM (Real User Monitoring) もある ◦ 各リクエストに応じてログを収集するため、肥⼤化しがち ◦ マネージドサービスで全量集めようとすると⾼コスト ▪ そのため多くの場合サンプリングする ▪ サンプリングをする場合、トラブル解決には向かないことが多い HAR の便利な点
31. © LayerX Inc. 31 ネットワークコネクションの様⼦も⾒られる
32. © LayerX Inc. 32 • キュー ◦ ブラウザからのリクエスト待ちに⼊れられている時間 ◦ 前のリクエストが詰まっていると時間が伸びる (コネクション数を使い切っていた場合など) • ストール ◦ プロキシへの接続など、リクエスト送信の準備をする前段階の時間 ◦ プロキシネゴシエーションがある場合 HTTP レイヤにプロキシがあるとわかる • DNSルックアップ ◦ DNS問い合わせの時間 ◦ ここがボトルネックになることもまれによくある • 初期接続 ◦ TCP Handshake, TLS handshake (negotiation) ◦ 同⼀ TCP セッションを使う最初のリクエストで発⽣する ざっくりした説明
33. © LayerX Inc. 33 • リクエスト送信 ◦ ネットワークリクエストを送信するのにかかった時間 ◦ send() してソケットバッファに書くまで (TCP ACK を待たない) • 応答待機 ◦ いわゆる TTFB ◦ HTTPレスポンスにおいて、最初のバイトを 受け取るまでの時間 (処理時間 + 伝送時間) • コンテンツダウンロード ◦ 受信にかかる時間 ▪ ⼤きなファイルで帯域幅が狭い場合などはここで 時間がかかる ざっくりした説明 ページを表⽰する際のウォーターフォールチャート
34. © LayerX Inc. 34 • サーバへの TCP/TLS 接続が完了するまでにそもそも時間がかかっている • リクエストの送信および TTFB (最初のデータを受け取るまで) に時間がかかっている ◦ ネットワークは⽇本にある ◦ サーバサイドのレスポンスタイムは正常 (~50ms) であり、こんなに時間はかかっていない • データ転送⾃体は⼀瞬で終わっている • 複数の応答待ちが同時に発⽣し同時に完了する 読み解けること
35. © LayerX Inc. 35 • TCP 接続を中継する「何か」がいる ◦ HTTP プロキシの場合はプロキシ接続の記録が残るので HTTP レベルではない • 何か: 多くの場合ファイアウォール ◦ TLS を復号して検査する機能を持つものが多い • HTTP/2 により1つの TCP セッションで複数のリクエストを多重化している ◦ ストリーム単位でバッファリングして復号 -> 問題なければクライアントに流す (?) ◦ 製品によって実装は様々だがこのような挙動の製品もある ここから推測できること
36. © LayerX Inc. 36 • かなりよくある問題の⼀つ • 事業者側にできることはそう多くはない ◦ HTTP/1.1 のみを使うことで体感速度が改善するケースもある ◦ アセットをまとめる、minify するなどのパフォーマンスチューニングも有効ではある • お客様側で問題解決する⽷⼝になる ◦ 情シスの⽅に問い合わせていただき解決することは多い ◦ フィルタリングルールの⾒直しなど どう対処するのか
37. メール
38. © LayerX Inc. 38 • 2026年現在でも以下の性質を持っている ◦ 特定企業やプラットフォームに⾮依存 ▪ 異なるサービス間でも相互に通信が可能 ◦ 個⼈や組織、システムなど、主体の種類を問わず同じ仕組みで通信できる ◦ 送受信が⾮同期、相⼿に依存しない ◦ テキスト以外の情報も送受信が可能 ◦ 組織の境界を越えて公式な記録としても扱うことができる • グローバルでオープンなメッセージ基盤！！！！ ◦ 他の組織とつながるのに NDA を結ぶ必要もなく、 Enterprise Plan も不要 ◦ 安価なサービスでも運⽤ができる 令和にメール？？？
39. © LayerX Inc. 39 • システムからの通知⼿段として最も使われる • ユーザが送付するユースケースもある ◦ 請求書発⾏ • 送信だけでなく受信も⾏う ◦ メール送付される請求書などの⾃動ダウンロード (請求書受取‧受領代⾏) ◦ 証憑ファイル取り込みのフックにもなる (AIエージェント) • システムとシステム、⼈をつなぐ重要な⼿段のひとつ バクラクとメール
40. © LayerX Inc. 40 SMTP SMTP Server (Sender) SMTP Server (Destination) • SMTP (メーラー) • HTTP (Web) • SMTP • POP/IMAP (メーラー) • HTTP (Web)
41. © LayerX Inc. 41 転送もできる SMTP Server (Sender) SMTP Server (Destination) SMTP Server (Relay)
42. © LayerX Inc. 42 • メール環境も⾮常に多様 ◦ SMTP Server ▪ Postfix, Sendmail, Exchange, Domino, qmail, etc ◦ SMTP Client ▪ Gmail, Windows Mailer, Outlook, Apple Mail, Becky!, Thunderbird, etc ◦ セキュリティゲートウェイ ▪ メールを事前に検査してくれる (Relay としてふるまうものが多い) ◦ ⾔語 ▪ MIME によるエンコーディング • 利⽤企業ごとに環境が混在 ◦ 本当に多様かつ重要度が⾼くデバッグが難しい 運⽤は割とたいへん
43. © LayerX Inc. 43 • 今⽇ではなんらかのクラウドサービスを使うのが⼀般的 ◦ 到達性を上げながら、メール運⽤の複雑性を下げる • バクラクにおいても外部サービスを利⽤ ◦ メール送受信の両⾯で利⽤ ▪ 外部サービスを経由して Amazon S3 に保存、システム連携を⾏う • クラウドサービスだから全て問題ないかというと… メール送受信の実装
44. © LayerX Inc. 44 • お客様がバクラクからメールを送っても送付先に届かない事象が発⽣ • 外部サービス上のステータスは正常送信済み ◦ エラーではないので逆に調査しにくい • 送付先を確認しつつヒアリング ◦ MX にはメール転送サービスのホストが記載されていた ◦ メール転送先では “SMTPUTF8 に対応していないエラー” を確認できた Case 2: メールが届かない！ (最近の SMTP 編)
45. © LayerX Inc. 45 ざっくりした構成 SMTP Server (Sender) SMTP Server (Destination) SMTP Server (Relay) ここで落ちてる
46. © 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 も増えている ◦ Postfix は対応 (smtputf8_enable) ◦ 利⽤していた外部サービスも対応 SMTPUTF8
47. © LayerX Inc. 47 不幸なパターン SendGrid SMTP Server (Destination) SMTP Server (Relay) SMTPUTF8 対応 SMTPUTF8 対応 SMTPUTF8 ⾮対応
48. © LayerX Inc. 48 • 送信元は受信元 (実態は Relay) が SMTPUTF8 をサポートしていると判断しメール送出 ◦ エンドツーエンドで確認をするわけではない • Relay は SMTPUTF8 で来たメールをそのまま転送先へ転送 • 転送先が対応していないためエラーになる • ここから先は Relay の実装 (設定) 依存 ◦ Relay は受信を完了しており、送信元に送れなかったエラーを直接は返さない ▪ DSN を返すことができれば通知できるが、そうでない場合はメールがロストする ◦ 対応していない送信先に対し、メールをダウングレード (再エンコード) する規格はある (RFC6857) が、実装されている MTA は少ない • 検証⽤の環境を Amazon EC2 に作成して⼀つひとつ検証 Relay だけが SMTPUTF8 をサポートすると起こること
49. © LayerX Inc. 49 • そう簡単にはいかなかった ◦ ⾃前の MTA ではないのである… • 外部サービスの仕様を探る ◦ 検証した結果、「添付ファイルのファイル名に⽇本語が使われていること」が SMTPUTF8 が 使われる条件であることが判明 ◦ ローマ字のみのファイル名でメール送付するか、別の機能によって添付ファイルを送らないこ とで回避可能なことがわかる • SMTP Relay サービスは SMTPUTF8 を切ってほしい (切実) SMTPUTF8 をやめよう！
50. © LayerX Inc. 50 • 「バクラクにファイル添付したメールを送ったが添付ファイルがない」という問い合わせ • 「プリンターから直接」スキャンしたデータを送付されていることを確認 ◦ プリンターもメールクライアントの⼀つ • 確認したところそもそも添付ファイルが到着している気配がない • Content-Type: message/partial Case 3: メールを正しく受け取れない
51. © LayerX Inc. 51 • “メール本体” を分割することのできる MIME Type ◦ RFC2046 ◦ 分割されたメールはそれぞれ1通ずつのメールとして送信される • ちなみに歴史は古く “message/partial” で検索すると2000年代前半の記事がたくさん… ◦ そういう時期に必要だったものということで • 対応するには受信側で組み⽴てなければならない ◦ オチが⾒えてきましたね message/partial
52. © LayerX Inc. 52 • 当然のように⾮対応 • 個々のメールは Body を考慮しないそれぞれのメールとして着信することが判明 ◦ よって添付ファイルも消失する • さすがに回避不能かと思われたが… 外部サービスと message/partial
53. © LayerX Inc. 53 • ヒアリングからプリンタの機種を特定し、ドキュメントを確認したところ スキャンファイルをメール送付する際の分割形式を指定できることを発⾒ ◦ 設定項⽬として明記はされていないが、 message/partial で送付するか、ファイルのページを分割して送付するかを選べた • 分割して送付いただくことで回避できた プリンタ側設定で回避
54. DNS
55. © LayerX Inc. 55 • システムから送信された通知のリンクが開けない！という問い合わせ ◦ 複数のお客様で発⽣していた • 通知状況トラックのため、外部サービスによる Click Tracking 機能を有効化していた ◦ 外部サービスによる計測⽤エンドポイントに置き換えてリダイレクト • エラー画⾯を⾒たところ DNS_PROBE_FINISHED_NXDOMAIN • だが、 DNS レコードは正常に参照できているようにしか⾒えない ◦ よく⾒ると外部サービスの計測⽤エンドポイントが36⾏のAレコードを返していた Case 4: クリックカウントの罠
56. © LayerX Inc. 56 • DNS はデフォルトで UDP を使う。 UDP を⽤いる場合応答全体が512バイトに収まる必要がある ◦ 今回のケースでは600バイトを超えていた ◦ IPv6 メインになる場合にはさらに厳しくなる • 512バイトを超える場合、 EDNS0 と呼ばれる DNS 拡張もしくは TCP に fallback する • 企業ネットワーク内では以下のいずれかが問題になることが多い ◦ ネットワーク内に置かれた DNS キャッシュサーバが両者に対応していない ◦ 53/tcp の egress が塞がれており TCP fallback ができない • 上記をクリアしない場合、単に DNS 応答がされないためクライアントからはエラーになる DNS の TCP fallback 問題
57. © LayerX Inc. 57 • Click Tracking ⾃体を無効化 ◦ 送付済みの通知は救えない • サービスプロバイダ側に対応してもらうしかないので即コンタクト ◦ サービスプロバイダ側からすると「ほんの⼀部のトラフィックが来ない」だけなので 気づきにくい ◦ 影響について説明しながら対応を⼊れてもらい根本解決 解決策は努⼒と根性
58. おわりに
59. © LayerX Inc. 59 • 開発者、運⽤者としての仕事 ◦ アプリケーション開発 -> Claude Code でだいたい書けちゃう ◦ Terraform -> Claude Code で (略) ◦ ログ分析、サーバサイドの障害分析 -> ⾃動化エージェントがバンバン出てきてる • 組織における仕事も AI Based になってきた ◦ 依頼対応 ◦ 障害時ポストモーテムの作成 ◦ ⽬標策定、振り返り、評価 • けれど… かわりゆく SRE の領域
60. © LayerX Inc. 60 • アプリケーション • サードパーティの API ◦ ⽣成 AI のエンドポイントも今のところほぼ同じように⾒える • コンテナ • OS • ネットワーク • 制御の⽅法が⼤きく変わりつつあるが、仕組み(プロコトル)が変化しているわけではないのが現状 ◦ 将来的に変わりゆくだろうが、AI の出現で TCP/IP が変わるかというと？？？ • 何より、こういうことに向き合うのって楽しい ◦ もちろん程度によるけれど 動いてるものはそんなに変わってない
61. © LayerX Inc. 61 • システムはサーバーサイドで完結しない ◦ むしろユーザー環境はサーバーサイド以上の複雑さと多様性をもつ • ログやメトリクス上の「成功」は必ずしもユーザー体験としての成功を意味しない ◦ ラストワンマイルのデリバリーがうまくいっているかは別の話 ◦ SRE として、最終的なユーザー体験がどうなっているかにも気を配りたい • プロトコルは同じでも実装や環境によって挙動が異なる ◦ ゆえにデバッグが難しくなる • 問題の再現が難しい状況でも、適切なコミュニケーションや仮説検証で原因を特定することは可能 ◦ やっていきましょう まとめ
62. © LayerX Inc. 62 • LayerXの各事業では SRE を積極採⽤しています ◦ 特にバクラクSREにみんな来てくれ！！！！！！！１ • AIに全⼒投球しつつも、「しぶい」ノウハウや調査⼒がとても重要です ◦ メールの安定運⽤ ◦ お客様環境を考慮したデバッグ ◦ データベースに関わる課題解決 (テナント規模の増⼤、負荷、メンテナンス性) ◦ パフォーマンス (データベースだけでなくアプリケーション処理や⾔語まで) ◦ コスト最適化、セキュリティ、etc • ビジネス, AI, ソフトウェア, インフラの全てを楽しんで向き合いたい⼈に⼼からお薦めします ◦ 少しでも興味があればお声がけください We’re hiring
63. おわり