SRE Next 2025 Day 2 セッションメモ
すみずみまで暖かく照らすあなたの太陽でありたい
Yodobashi Cloud、開発者はアーキタイプを意識せず、Region/Multi-Regionalな構成でアプリケーションをデプロイされる。OSSミドルウェアの監視にZabbixを導入したが、監視オペレータがなじみ深い監視ツールで見れる工夫
アクセスピークを制するオートスケール再設計: 障害を乗り越えKEDAで実現したリソース管理の最適化
アプリケーションの利用状況、イベントパターンによりピーク時期が変わる。今回の場合は確定申告の締め切り時期
CPU使用率でトリガーでHPAオートスケールするようにしたが、livenessProbe、ヘルスチェックでメモリ不足で失敗、サービスインのPod減、サービスイン中のPodに集中することでメモリ不足する悪循環に陥った。
リクエスト数でのトリガーにしておけば、リクエストの急増によるHPAに対応。GCの別要因でのメモリ意図せず解放されることもあるので、メモリトリガーは選択していなかったとのこと。GCだとCPUも上がるケースもある
150サービス連携を3人で運用する現場から ー 創業4ヶ月目におけるオブザーバビリティの実践
ログ監視だけでは、なにが、どこでなぜ起きているか、おきているか不明確
構造化ログ、トレースから関連したログを集約
SRE with AI:実践から学ぶ、運用課題解決と未来への展望
リクエストのトレースIDからNewrelic ログ情報を検索し、エラー原因を生成AIにまとめる
監査ログの異常、疑わしいアクティブティの分析
AWS EKS MCP Server、5xx多発したら、原因であるOMKilledを検出、CPU、Memoryの割当を調整まで行ってくれたとのこと
今はまだだが自律的にAI Agentが行動する時代がくる
大量配信システムにおけるSLOの実践 :「見えない」信頼性をSLOで可視化
送信処理(リクエスト成功)の成功率、配信時間の達成率、リレー、SESリトライなど別要因による遅延もあるので、技術側面のSLOはとれるが、ユーザにどういう影響があるかわかりずらい
ユーザに配信が届いたか、遅延していないかのSLO
一つ一つの技術側面の成功率ではユーザにどういう影響があるかのビジネス観点のSLOを設定できないケース
Kubernetes で管理する大規模 Edge クラスタ: 200台のEVチャージャーの安定稼働を支える技術
armv7などcpu architecutureが混在するEdge DeviceにIoT Gatewayをデプロイする必要がある
Edge Deviceのmetricsをpullしてクラウド上のOpenTelemetry Collector経由でGMPに集めている
制約のあるデバイスにはnode-exporter podから収集
顧客の画像データをテラバイト単位で配信する画像サーバを WebP にした際に起こった課題とその対応策 ~継続的な取り組みを添えて~
画像変換の仕組み変える場合、ユーザ体験を損なわず、改善する工夫が必要
jpegなのに、webpとして配信しようとして表示しないなど想定しない問題も起こっていた
SREのためのeBPF活用ステップアップガイド
BCCをビルドするのに、LLVM/CLangのバージョンを指定することが推奨。12-15が安定してそう
プロセスがSIGKILLした場合のトレースポイントの原因分析
Memcacheの負荷試験時の調査
eBPF、低オーバーヘッドで高頻度トレースも性能影響最小でカーネル内部に安全にアクセスできるので、システムコール、メモリ、ネットワーク、ファイルIO監視によさそう
システム障害対応のツマミになる話
クラウドネイティブ技術、分散システムの障害対応の難しさ
あくまで障害対応は復旧ではなく、ユーザ影響の極小化が目的
クラウドの場合、クラウドプロバイダ起因でPodが入れ替わったりするので、レイテンシなどユーザ影響のある監視の重要性