🎉

SRE NEXT2025 参加してきました！

に公開
webx
idea

概要

  • 2025/07/11~12にかけて開催されたSRE NEXT2025に参加してきました (都合により、11日しか参加できませんでした)

Brendan Gregg氏の基調講演

  • 「Fast by Friday」というコンセプトのもと、コンピュータパフォーマンス分析の進化と、現代における迅速なトラブルシューティング手法が紹介されました。
    • 週初めに発覚したパフォーマンス問題は、必ずその週内に解決する
    • 日別のアプローチで段階的に問題を可視化・分析・解決
    • ケーススタディを通じてノウハウを組織知に昇華
  • 発表では、パフォーマンス分析の進化を以下のように区分していました：
    • 1950s–1960s: ストップウォッチ時代
      • ハードウェア最適化のみ
      • 直列計算中心
    • 1960s–2000s: ソフトウェアメトリクス時代
      • タイムシェアリング、制限的なSWメトリクス、推論
    • 2000s–2020s: 「すべてを可視化」時代
      • 動的インスツルメンテーション（例: eBPF）
      • オープンソースツールの台頭
    • 2030s〜: 「すべてを解決」時代へ
      • 新たな解決志向のツール群
      • 自動化と学習によるトラブル解決
  • 所感
    • ツール選定だけでなく、「時間軸に基づいた分析プロセス設計」という、野口は経験したことのない視点が強調されていました。
    • SREやパフォーマンスエンジニアにとって非常に実践的かつ再現可能性の高い内容に思いました。

Ubie社「SREへの問い合わせ対応にかかるToil削減」

Ubie社のSREチームは、「SREへの問い合わせ対応にかかるToil削減」 を目的に、SlackベースのAI自動化ツール「infra-help-otter」を開発・運用。その背景、実装、効果、そして今後の展望が本セッションで詳細に語られました。

![R0004643.jpg](https://image.docbase.io/uploads/368edf9a-ee78-4bd1-82c1-dff56d9593f5.jpg =WxH)

🔍 課題と背景

  • 問い合わせ件数が月100件以上と急増し、SRE/インフラチームの業務を圧迫。
  • SREチーム全体の50%以上の作業時間が問い合わせ対応に充てられる状況。
  • 属人的な知識共有の欠如により、再発する問い合わせや冗長な確認作業が発生。

🤖 対応策：「infra-help-otter」の開発

✨ 特徴

  • SlackとWebアプリケーションによるAIチケット管理システム。
  • 問い合わせスレッドから直接チケットを生成し、AIが一次回答を行う。
  • チケットの種類分類と適切な担当者アサインをAIが自動で判断。
  • 各ステージの進行ステータスをSlack上で可視化。

🛠️ アーキテクチャ概要

  • Slack → Cloud Functions（GCP）でトリガー
  • ナレッジベースは Google Cloud Storage、BigQuery
  • AIモデルは Vertex AI Search + OpenAI（Chat系API）を利用

📈 成果と改善効果

✅ コミュニケーションの明確化

  • 断片的なメッセージを排除し、統一されたスレッドベースの運用へ移行。
  • hello-xxx による簡単なトリガーでチケットを自動生成。

✅ 工数削減の可視化

  • 「チケット作成→解決」にかかる平均時間が明確に短縮。
  • ドキュメント整備とAIの即時回答により、SREの介入タイミングが後ろ倒しに。
  • 再発チケットの減少、問い合わせ傾向の分析も可能に。

🧠 今後の展望と開発計画

  • AI機能のさらなる強化
    • 「AIのみで50%以上の問い合わせ解決を目指す」
    • 一次回答精度の向上、類似チケットのバルク回答、自動クロージング機能など
  • Slack UXの改善
    • Agentのフィードバックを元にUIや通知ロジックを最適化
  • 他部署や非エンジニア層への展開
    • サポート部門、BizOps への応用も視野に

🧾 まとめ

項目 内容
実施期間 2025年4月〜6月（約3か月間）
対応チケット数 327件（社内全体）
成果 Toilの削減、AIによる一次回答の浸透、問い合わせの分類・自動処理の仕組み化
最終目標 「問い合わせなくても解決できる状態」＝ナレッジ駆動型組織の構築

✍️ 所感

この発表は、AI×Slack×SREの融合による現場課題の着実な解決事例として説得力がありました。
特に優れていた点は以下の3つです：

  1. 定量的な改善効果（件数・時間・再発率）を明示
  2. 「一次回答」「分類」「アサイン」などプロセスごとにAIを活用
  3. 文化醸成や習慣（hello-xxxなど）の整備も並行して推進

🔐 STORES 株式会社「TLSから見るSREの未来」

セッション概要

このセッションでは、TLS（Transport Layer Security）に関する基本的な仕組みから、証明書の自動化・短期化・セキュリティ強化の最新事情まで、SREが今後意識すべき実践的な内容が幅広く解説されました。
特に「証明書の運用自動化」や「TLS 1.3移行」、「ポスト量子暗号」など、未来を見据えたセキュリティ体制構築が主軸でした。

📘 セッション内容の要点まとめ

1. TLSの基本的な仕組み

  • サーバとクライアントが鍵交換し、証明書を使って署名を検証。
  • 共通鍵を導出し、通信の暗号化と完全性を確保。
  • PKI（公開鍵基盤）による信頼の連鎖が核。

2. 証明書運用の変化と自動化

🛠️ 運用の流れ（モダンな証明書発行）
  • CSR作成 → API経由申請 → 所有権確認 → 発行 → 自動適用。
  • Let's Encryptなどの無料証明局が標準化しつつある。
⏱️ 有効期限の短縮と自動ローテーション
  • かつて825日 → 現在398日 → 将来47日へ短縮予定。
  • 有効期限が短くなるほど、自動化が必須。

3. TLS 1.2 → 1.3への進化ポイント

項目 TLS 1.3 の改善点
事前秘密性 必須（ECDHEの強制使用）
接続確立までのRTT 2-RTT → 1-RTT（さらに0-RTT再接続も可能）
セキュリティ強化 セッション鍵の再利用排除
パフォーマンス CDNなどにおける高速性向上

4. 暗号アルゴリズム・証明書仕様の進化

  • EC鍵（ECDSA / Ed25519）がRSAに代わり主流へ。
  • AES-GCM / ChaCha20-Poly1305などのモダン暗号スイートが利用推奨。
  • 一部の旧クラウド・旧デバイスで非対応の懸念も。

5. SREとしての対応戦略

  • 証明書の自動取得・更新
    • ACMEプロトコル、cert-manager などの導入が前提。
  • 証明書状態の監視と可観測性の確保
    • Prometheus/Grafanaでの期限管理などが推奨。
  • 暗号スイート・仕様の定期的なキャッチアップ
    • TLS 1.3対応、将来的にはPQC（ポスト量子暗号）も視野に。

✅ 発表のまとめスライドから

  • 暗号技術は進化し続ける対象であり、証明書も監視・自動化の対象となった。
  • SREは、TLSの変化に追従し、安全かつ継続的な運用基盤を支える必要がある。
  • 組織に適したTLS戦略を模索し、Toil削減・可用性・セキュリティ向上のバランスを取ることが求められる。

✍️ 所感

このセッションは、TLSや証明書管理がSREの業務領域であることを明示的に認識させる好例でした。以下の点が特に印象的でした：

  • 「証明書は開発環境の外にあるから関係ない」という時代は終わった
  • 自動化が前提となり、「手動更新」はリスクでしかないことが強調された
  • TLS 1.3 や ECDSA など、現代の仕様を理解しなければ安全な運用はできない

SREやプラットフォームエンジニアにとって、セキュリティと可用性を両立するための「証明書インフラ運用」の知識は、今や不可欠。まさに「TLSは設定して終わりではない」ことを、丁寧かつ体系的に再確認できる講演でした。

さくらインターネット株式会社『とあるSREの博士「過程」』

📘 要約：博士課程を通じてSREが得た知見と研究

1. コンピュータサイエンスと博士課程の位置付け

  • CSとは何か？
    • 多くの研究がデータベース（インデックス、シャーディング）、分散システム（Paxos/Raft）、ネットワーク（仮想化・輻輳制御）、機械学習（CNN、Transformer等）に分類される。
  • 博士課程の意義（yuuk1視点）
    • エンジニアリングとコンピュータサイエンスの交差点にあり、「知」の積み上げが目的。
    • 博士課程は一足飛びに到達できるものではなく、訓練が必要。

2. 個別研究とその挑戦

研究①：時系列DBの運用最適化
  • 問題：運用を楽にしたい、複数DBMSの統合利用を実現したい。
  • 課題：学術的な貢献をどう言語化するか。
  • 貢献：エンジニアにDB製品の選択肢を提供するアーキテクチャを提案。
研究②：NWコールグラフトレーシング
  • 目的：NW通信経路上に計測点を設け、依存構造を把握する。
  • 手法：アプリ/カーネル/スイッチなど、経路上での測定。
研究③：AIOpsによる障害原因の特定
  • 入力：メトリクス＋NWコールグラフ
  • 出力：障害原因の機械学習による推定
  • 使用モデル：RNN/LSTM/GNNなど多岐にわたる
  • 課題：ノイズの多さにより特徴量が増大 → 特徴量削減が鍵

3. 博士論文のまとめ方と中核概念

  • 中核概念：「Scaling Telemetry Workloads」
  • 各研究に共通する問題
    • 計測：NW接続数増大 → CPU消費増
    • 保存：メトリクス数増加 → IO/リソース増
    • 分析：メトリクス数増加 → 精度向上のために時間消費
  • 目的：運用複雑性を抑えながら効率的にスケーリングする方法論の確立

4. 博士課程の振り返り

  • 成果
    • 博士論文で決まるわけではなく、自分らしさを体現できた。
  • 楽しさ
    • トップ研究者の思考に触れる
    • 知的好奇心の満足（「こんなこと考えてるの自分だけかも！」）
    • eBPFやAIOpsなど、日常業務では触れない先端技術を活用
    • 国内では前例が少ない感覚にやりがい

5. 論文との付き合い方

  • メッセージ：「異世界の情報源＝論文」への常時アクセス能力が武器になる
  • SRE・クラウド関連論文はSNSに流通しない
  • 新技術をキャッチアップするには「論文ファースト」が有効

✍ 所感

この発表は、SREという実践的な職務と学術的な探究の架け橋を見事に示しています。以下の観点で特に示唆に富んでいました。

🔍 実務と研究のギャップをどう埋めるか？

  • 実務における問題意識をいかに学術的な貢献へと言語化するかという苦悩は、研究テーマ選定におけるリアルな課題を象徴しています。
  • 特に「マネージドサービスの利便性」が学術的貢献にならないという壁に直面しながらも、「選択肢を広げるアーキテクチャ」を提案するという視点は本質的です。

🧠 博士課程＝自己内省のプロセス

  • 発表者の「体系を自分の中に築いていく感覚」という表現が印象的でした。研究は何よりも自己理解の深化をもたらす営為である。

📚 論文ファーストの意識

  • 技術的先端を追いかける手段として、SNSよりも論文に軸足を置くという姿勢は、現在の情報過多な環境下で極めて有効な知の整理手法。

Discussion