「SRE NEXT 2024（Day 2）」に参加してきました

• 2024/8/4
• https://sre-next.dev/2024/

宇宙科学研究所の探査機運用システムにおけるSREのプラクティスの導入と月着陸実証機SLIMでの利用

• 中平 聡志さん(宇宙科学研究所)

人工衛星探査機の運用とデータ

• 人工衛星
  • 地球近郊を周回
• 探査機
  • 地球の重力県外の活動
• 運用
  • 地上にたくさんのデータが流れてきて監視している
  • 情報が多すぎて慣れが必要
  • モノリシックなシステム
• データ
  • サイエンスデータ
    • 論文とかで使う時間をかけて使うデータ
  • HK(House Keeping)データ
    • 機器の健全性のモニタリング
    • 電圧電流など
  • IoTやSREで使われてるソフトウェアの利用ができるのではないか

システムの設計構築

• 十数人程度の利用者
  • 想定外の負荷向上などは起きない
• 単方向
  • 送られてきたデータを表示するだけ
• Observability
  • 着陸時の20分がとても重要
  • 画面を見て判断する時間を1病でも削りたい
  • リアルタイム以外での深い調査
    • 数千数万の項目から探して表示
    • 過去の期間のデータ
  • これまで手動でやっていた複雑な計算などはリアルタイムで自動で
  • 運用やアラートの自動化まではしない
  • OSSも活用
• データはGrafanaで可視化 -20程度のダッシュボード

オブザーバビリティのマクロからミクロまで〜あるいはなぜ技術書を翻訳するのか

• 山口能迪さん(Google)
• https://speakerdeck.com/ymotongpoo/observability-from-macro-to-micro

開発とオブザーバビリティ

• ミクロとマクロで求められるオブザーバビリティが違う
• ミクロ
  • 個人
  • 数日〜数週間の単位
  • リリース前
• マクロ
  • チーム/組織
  • 数週間〜数ヶ月
  • 本番環境
• 4象限
  • 知ってることを知っている
    • 単体テスト/アラート
  • 知ってることを知らない
    • 第六感による問題特定
  • 知らないことを知っている
    • システム監視
  • 知らないことを知らない
    • 未知の故障系の対応

マクロなオブザーバビリティ

• SLOを定義して脅かすものを明らかにする
  • 信頼性から原因を遡っていく
• デプロイ以後のフェーズ
• マクロレベルの主要なシグナル
  • 複数コンポーネントの関連
  • シグナルの関連付け
  • 長期的な分析
  • -> 分散トレース/メトリクス/ログ/継続的プロファイル

ミクロなオブザーバビリティ

• 求められる性能を確実に提供する
• リリースまでに想定した状態になってるかテストする
• 性能をテストの一環として行う
  • テスト/修正/ベンチマーク/ 最適化
    • TFBO(test/fix/benchmark/optimization)
  • 関数ごとのテスト
    • 最大レイテンシーとかメモリが基準値以下になってることを確認
    • 言語ごとにだいたい機能がある
• ミクロレベルの主要なシグナル
  • ベンチマーク
  • プロファイル
  • トレース

内製化を見据えた効果的なSRE支援のアプローチ

• 岩﨑 勇生さん(株式会社スリーシェイク)
• https://speakerdeck.com/kojake_300/sre-next-2024-nei-zhi-hua-wojian-ju-etaxiao-guo-de-nasrezhi-yuan-noapuroti

内製化を踏まえたSRE支援

• SRE支援として自走して内製化してもらうことをゴールとしておいている
• SREを発展させつつ知識を移転する
  • これを繰り返してサイクルを回す
  • SREの意義やプラクティスを定着させる
• 暗黙知を形式知に置き換えて伝える
• オブザーバビリティが高いとシステムの暗黙知を形式知にしやすい

徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例

• 多羽田 俊さん(株式会社MIXI)
• https://speakerdeck.com/bbqallstars/che-di-de-nazi-dong-hua-totoirunopu-mie-deshi-xian-suruxiao-lu-de-nasrenoshi-jian-li-sre-next-2024

少人数でのSRE

• IaCのモジュール化テンプレート化
  • Terraform Module
  • tr generatorでコードを自動生成
  • 社内でのパターンはだいたい3つでそれを生成できる
• モノレポで運用
  • 効率的にCI/CD回せてる
  • 50ワークスペース
  • GitHubActionsで並列実行してる
  • 100並列で5分くらい
• 脆弱性の継続的な予防検知対応
  • AWS Personal Health Dashboardを監視
  • AWS Systems Manager Patch Manager
  • GitHub dependabot
  • tfupdate
• モニタリングとアラート
  • CloudWatch LogsでEC2のログ収集
  • Synthetics Canariesを使った外形監視
  • AWS SNSとPagerDuty

本人確認サービスにおける信頼性の定義とアラート対応の継続的改善

• 五島 宙也さん(株式会社TRUSTDOCK)

アラート対応

• アラートの取りこぼし
  • 緊急性高いものとそうでないものが似た内容で見落とした
• サービスの特性上ライフサイクルが長い
  • 免許証などをアップしてもらって本人確認するサービス
  • 複数のステップがある 回避フローがあるエラーと回避できずフローが止まってしまうエラーがあった
  • フローが正しく回ることが大切
• フローが正常に進まないパターンを整理
  • どこで止まった時にどれくらいの人にどれくらいの影響があるか
  • 対象者が広いエラーはアラートやヘルスチェックで気付ける
  • 局所的な人に対して致命的なエラーは検知しづらい
• アラートのトリアージ
  • 機械的な判断は諦めた
  • 開発者が中身を見て判断
  • 曜日ごとにSREと開発チームで確認作業を分担
    • トイルの性質が高いので作業負荷を分散できるといい
  • 1人で完璧に判断するのは大変
    • 全員でカバーできるように
• 長期的な改善
  • すぐに問題は起きないが対応した方がいいアラート
  • テストやstg環境の整備がされていることが前提
  • 対応のコスパがよさそうなものからやっていくといい

SREの技術トレンド2024

• 北野 勝久さん(株式会社スタディスト)
• rrreeeyyyさん(株式会社Topotal)
• yuuk1さん(さくらインターネット株式会社)
• deeeetさん(Mercari, Inc.)

パネルディスカッション

• メルカリはPlatformチームとSREチーム分かれてる
  • 小さい規模ならPlatformチームはオーバースペック
• SRE
  • 顧客視点での信頼性向上
• PlatformEngineering
  • devopsの一形態
  • 全社に対してツールを提供するとか
• インシデントレスポンスをやっていく流れが最近高まってる