6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【セミナーレポ】Google&Datadogさん共催のオブザバセミナーに参加してきました

Posted at

Google Cloud Japanさん&Datadog Japanさん共催の 「マルチクラウド環境とオブザーバビリティ」 というオフラインセミナーに参加してきました。

内容をざっくりシェアします。聴きながらの走り書きベースなので超雑ですみません!

※プライベートセミナーのため一般公開されているページ等はありませんが、私は会社経由でご案内をいただき同僚と参加。他のユーザー企業さんも複数いらっしゃいました。
レポ記事公開についてはご承諾をいただいています。(ありがとうございます!)

セミナー内容の紹介

アジェンダ

  • Dash 2022およびGoogle Cloud Next 2022からの新機能など紹介
  • SRE・オブザーバビリティ Deep Dive
  • 懇親会

私の場合、実務でゴリゴリ使っているのはDatadogの方だけなのですが、GoogleさんからSREのお話が直接聞けるということで思わず申し込みました。

Dash 2022およびGoogle Cloud Next 2022からの新機能など紹介

Datadogの主なユースケース

  • クラウド移行
  • 監視ツール一元化
  • クラウドネイティブ監視(モダナイゼーション)

GCPでDatadogを使うメリット

  • オンプレ/マルチクラウド監視一元化
  • クラウドと請求一本化
  • GCPクレジット活用

事例

  • メモアプリ某社:GCP移行を9ヶ月想定→70日へ短縮
  • アパレルEC某社:AIOps機能でアラートを日あたり10,000件→20件に削減

※DatadogでいうAIOpsのイメージとして、私はWatchdogを思い浮かべながら話を聞いていました。他にもあるかも知れません。

2022年のアップデート

セキュリティ:最近一番アップデートが多い。PCIはじめコンプラ準拠とか

  • 既存機能 CWS:eBPFでホスト監視など
  • CSM:セキュリティ統合ダッシュボード(Sec部門とも共有していきたい思想)
  • ASM:Datadog上で不審アクセスをそのままブロック可能

コラボレーション:ダッシュボード、インシデント管理など

  • サービスカタログ:構成サービス一覧&所有者を明記
  • CoScreen:開発、トラシュー中の画面共有

オブザーバビリティパイプライン:色んな製品経由のテレメトリーを一元集約

  • 新機能:GUIエディターが追加
  • ユースケース:不要データ加工削除、移行中ルーティング、転送状況可視化

小噺として、Dashでは他社の大規模イベントと異なりCEOのキーノートを3分ほどで終わらせてしまい、さっさと各チームからの新機能紹介に時間を割くというお話があり興味深かったです。ビジョンよりも技術を重視する同社の姿勢が表れているとのこと。

SRE・オブザーバビリティ Deep Dive

あの有名なGoogle 山口さんから直々にSREのお話を聞ける素敵なセッションでした。
ただし、今日たまたま体調が悪かったとのことでリモート講演でした。それでもありがたい。

SREとは

  • システムの信頼性を維持するための方法論。全組織で取り組む必要がある
  • 原則
    • いかなるシステムでも最も重要な「機能」は信頼性
(100%ではなくバランスよくユーザーのニーズに応える)
    • 信頼性を決めるのは監視システムではなく「ユーザー」である
  • 運用保守コストは構築よりも長期なのでバカにならない
    • 開発&運用チームの目的が合致していないのが問題(アジリティ vs 安全性)
    • 共通の基準を「ユーザーの信頼性」にして全部署のインセンティブを揃えるべし
    • SLOを用いる
      • SLO > SLA(SLO未達の場合の規約)
      • 100%を目指さない分、投資に回す

オブザーバビリティとは

  • 原義:制御理論
    • システムで言うと:運用やビジネスに必要な判断をするための内部情報を把握できること
    • オンプレの場合
      • アプリケーション:取得に工夫が必要
      • インフラ:自ら取得・整理が必要
    • クラウドの場合
      • アプリケーション:取得に工夫が必要(変わらず)→ ここがより重要
      • インフラ:自動取得が可能
    • ただ取得するのではなく、SLI選別&分析しやすさが必要

SREを実践するときの流れ

  1. サービス価値&CUJの確認
    • ユーザージャーニー整理
    • 過去の問い合わせ確認
    • デリバリーのリードタイム、レイテンシー
    • 優先度づけ
      • 歯磨きジャーニー(定期的に発生するイベント)
      • ヒポタルジャーニー(たまにしかないけど重要なイベント)
  2. SLI&SLO設定
    • SLI:(良いイベント/有効なイベント)x 100%
    • 候補
      • リクエスト/レスポンス
      • データ処理
      • ストレージ
    • 期間&目標%を決めればSLOになる
      • 残りの%がエラーバジェットになる(チャレンジできる失敗)
  3. 計装&テレメトリー収集
  4. アラート設定
    • エンジニアがアクション可能な内容&頻度にする
    • エラーバジェットが「なくなりそう」な少し前に鳴らす
  5. SLI&SLO見直し → 2.に戻って以降繰り返し

感想

SREというキーワードとは長いこと付き合っていたつもりでしたが、山口さんから直々に「SREとは」「オブザバとは」という話を聞けたことで、改めて論点がぼやけがちな「SRE」について腹落ちするメインストリームな考え方をおさらいすることが出来ました。

また、渋谷ストリームのGoogleさんオフィスもめちゃ綺麗でした。ドロイドくんと写真撮影してきました✌️
スクリーンショット 2022-10-25 21.47.50.png

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?