オブザーバビリティの展望
- グーグル合同会社 山口能迪さん
オブザーバビリティ
- CNCFでオブザーバビリティとはこういうものと定義されている
- システムの開発ライフサイクルのすべてのフェーズで使えるもの
- システムから出てきたアウトプットを元に改善していくこと
- システムの出すアウトプットをシグナルという
- シグナルを元にシステムが動いてることをチェックする
- 可観測性(制御理論)
- 1950年代からある考え方
- ルドルフカルマン
監視の変遷
- 昔はネットワークを見るものが多かった
- RRDtool
- Zabbix
- googleが先進的だったがオープンになるまでの時差があった
- メインフレームの時代はハードウェアとアプリが密結合
- それがだんだん分離されてきた
- マシンが高いからアプリにリソースを割り当てる
- ダウンサイジング->仮想マシン
- 止まったら動かなくなるところだけ監視
- OS/ハイパーバイザー/ハードウェア/ネットワーク
- DevとOpsが分かれてた
- ハードありきでインフラの監視が大事
- アプリはログがメイン
- 仮想マシン->k8s
- アプリ側での監視が進む
- マネージドサービス使うとOSなどは面倒見なくていい
- マネージドk8s->サーバーレス
- アプリが主役
- ハードウェアが貴重な時代
- インフラの可用性を守る
- 特定のインフラから特定のシグナル
- クラウドネイティブな時代
- 不特定のインフラから様々なシグナル
- 分散システムのトレースが必要になる
今後の展望
- 過去の変遷を後から見ると納得感がある
- 現在から未来を予測するのは難しい
- 現状の課題
- シグナルを保存するストレージのコスト
- シグナルの相関を実現するための計装作業が大変
- 外的変化が多く異常値/ハズレ値の検知が難しい
- テレメトリー以外のコンテキストを含んだ障害要因の発見
- オブザーバビリティSaaSにとっては大きなチャレンジ
ヌーラボの組織とモニタリングの変遷
- 株式会社ヌーラボ 二橋宣友さん
長期運用による課題
- 2005にbacklog
- その後5年おきくらいに新しいサービス
- 開発運用の肥大化複雑化
- 古いシステムの移行
- 新旧システムの混在
- チーム間の連携鈍化
- 意思疎通が複雑化
組織体制の変遷
- 初期は少人数で開発運用すべて
- ユーザ数急増
- インフラエンジニア採用
- 開発と運用のチームを分離
- 開発と運用やプロダクト間の連携に課題
- 横断のSREチームを配置
- チーム規模の拡大
- 機能/職能別チームへ
- 横断の特定の分野に特化したSMEの導入
- Subject Matter Expert
- 技術差や車輪の再開発の課題
- PlatformSREの発足
- SMEにSRE関連も追加
モニタリングとオブザーバビリティの変遷
- 昔はOSS
- 今は
- mackerel
- OpenSearch
- pagerduty
- Mackerelを導入して
- モニタリングのための労力から開放された
- システム運用からサービス運用へ
- インフラ担当以外も含めたモニタリング
- 成熟度
- モニタリングは安定稼働
- ログ収集
- アラート設定
- オンコール体制
- オブザーバビリティは改善の余地あり
- 職人技への依存
- トレーシングは検討段階
- モニタリングは安定稼働
Mackerelが取り組むオブザーバビリティ
- Mackerel 井上幸亨郎さん
Mackerel
- オブザーバビリティプラットフォームとして進化していく
- OpenTelemetryメトリック対応
- メトリックエクスプローラで探索できる
- OpenTelemetryトレーシング対応
- トレーシングを検索できる
- SLOの設定監視できる
- エラーからドリルダウンして見たり
- SAML対応
- カスタムダッシュボードのおまかせ生成
- 今後すべてのOpenTelemetryシグナルに対応していく
- 洞察を得て対応していけるように
- APMの提供
- Application Performance Monitoring
- 今まではインフラのメトリックが中心でアプリ内部に焦点を当てづらかった
- サービスマップ
- 遅いエンドポイント
- スロークエリ
