イベントの概要
以下、イベントページから引用です。
Cloud Native Days でも Observabillity Conference 2022 が開催され、注目度が高まる オブザーバビリティ 、DevOps を正しく文化として定着させ、ユーザーに対してより良い価値を届ける為にも監視の重要性が増している状況です。
そして、昨今はマイクロサービス化やコンテナ化が進み、開発における利便性やサービスの安定性は高まりました。しかし、その分、システム全体としての構造は複雑化が進み、問題の特定などインシデント時のトラブルシューティングなどがより難しくなっており、監視も従来型の監視からレベルアップが求められています。
Forkwell の Observability Lounge #1 では『入門 監視 ― モダンなモニタリングのためのデザインパターン』の翻訳を手掛けられた現 Autify CTO の松浦 隼人氏をお迎えし、いま一度、監視の基礎を学ぶと共に、Splunk Services Japan合同会社の大谷 和紀氏を迎えて複雑化に対応する監視の最先端を実際の事例を踏まえてお話頂きます。
イベントで印象的だったこと
入門監視を出版してから5年間で変わったこと
5年間で変わったことの一つとして、まずはオブザーバビリティという単語の広がりが挙げられていました。*1
また、監視対象の変化についても論じられており、オンプレミスサーバーにおける監視から、抽象化が進みサーバレスにおける監視という変化が話題として出ていました。
監視のアンチパターン〜5年経った今も入門監視で言及されているアンチパターンはアンチパターンのままなのか？〜
ツール依存
どのようなものをなぜ監視するか考えずにツールベースで監視を考え始めて、監視の内容がツール依存になるのは現在もアンチパターンである一方、5年前に言われていた「一眼で全ての監視対象の状態が把握できるようなツールがあるなんて迷信だ」という部分は、ツールの進化が進んだ現代では、あながち迷信とは言い切れないような状況になっているというお話がありました。
役割としての監視
監視する役割を明示的におくことはアンチパターンの一つとして挙げられていましたが、これは5年経った今も変わらないのではないか、というお話でした。
チェックボックス監視
OSのメトリクスをチェックボックス的に監視することには意味がなくて、あくまでも動いているシステムに監視対象を絞ろう、という考え方自体は5年前から変わっていないというお話でした。
一方で、インフラの抽象化が進んでいる現代では、低レイヤーの監視の重要性は増しており、OSといったインフラのメトリクスを疎かにする危険性はより高まっているというお話がありました。
監視を支えにする
監視があるから何かあっても大丈夫、という考え方が誤っているというのは、5年前から変わっていないというお話が出ていました。
手動設定
IaCなどを活用し、監視の設定を入れるのが億劫になるような状態は避けた方がいいという話は、5年前から変わらず気をつけるべき話だというお話でした。
監視のデザインパターン〜5年経った今も入門監視で言及されているデザインパターンは有用なのか？〜
組み合わせて監視
複数項目を組み合わせて監視する重要性については、5年前から変わっていないというお話が出ていました。
ユーザー視点で監視
できるだけユーザー視点で監視しようという考え方自体は変わっていないものの、ユーザー視点を実現するためのハードルは5年前と比較して下がっている*2というお話が出ていました。
作るのではなく買う
まずは世の中にあるツールを使おうという話は、ツールの進化によって5年前と比較しても重要性が増しているということでした。
継続的な監視
これも5年前と変わらず、システムが一度作ったから終わりだということはあり得ないというお話でした。
オブザーバビリティが重要になってきた背景
未知の未知はモニタリングではなく扱えないが故、未知の未知を扱えるオブザーバビリティが重要になってきているというお話が出ていました。*3
フロントエンド監視における進化
Navigation timing APIの監視から、ユーザー中心メトリクスやWeb vitralsの監視にここ5年間で関心の対象が移っているというお話や、ロギングからトレースへ関心の対象が移っているというお話がありました。
アプリケーション監視における変化
トレースメトリクスの計装がOpenTelemetryの台頭によって容易になりつつある点や、アプリケーションログの収集・分析やインフラメトリクスと組み合わせた監視がツールの進化によってやりやすくなっているという話が挙がっていました。
サーバ監視における変化
ここはツールの進化が著しく、k8sなどコンテナ基盤の監視だったり、Prometheusを中心としたエコシステムの整備が進んでいるというお話が挙がっていました。
ネットワーク監視における変化
eBPFの台頭はあるものの、5年前に「残念ながら今あるのはSNMP」と言われていたSNMPがいまだにほぼ唯一無二になってしまっているということでした。
監視SaaSを選ぶ際に大事なポイント
- オープンなエージェントを入れること
- 監視サービスがベンダーロックインにならないこと
- 監視目的の整理がされていること(もし整理されていないのなら、まず使ってみてフリートライアルの範囲内で色々試してみるのが重要)
がポイントだというお話が挙がっていました。ツールはベストプラクティスを集約していることが多いので、なぜこのような機能があるんだろう？と考えるのも大事、というお話が出ていたのも面白かったです。
OSSと有償ツールの使い分け
費用対効果を面倒くさがらないことが重要だというお話が出ていました。(有償ツールを使うことでこれくらいのROIがある、と示すことが重要)
また、OSSのバージョンアップに手間が掛からなくても、セキュリティなどではリスクが潜在的にあることが多いので、注意した方がいいというお話が出ていました。
監視の運用見直し
問題が起きた時に次の問題が起きた時に備えた監視をすることが多い一方、オブザーバビリティの観点で先回りして監視しておくことも重要だというお話がまず挙がっていました。
また、テスト駆動開発で「不安をテストにする」という話が出ているのと同じように、「不安が出たらモニタリングしよう」という考え方を持っておくのが重要だというお話が出ていました。
インフラとアプリ側での分断
誰が何をやるのかを明文化しておく、というのがまず挙がっていました。
また、全部の状況を全員が見えるようにしておくことも重要だというお話が出ていました。(インフラだからフロントエンドのメトリクスがどうなっているのかは知らない、だとまずい)
また、ブラックボックス化して認知負荷を下げるという取り組みは重要な一方で、監視に関してはチーム全員がスキルとして持っている状態を目指した方がいいのではないかという意見が出ていました。*4
監視を導入するときの立ち上がり
SREはプラクティスなので、そのプラクティスを担当するチームを作ってしまうと、その担当チームがめちゃくちゃ辛い状況になってしまう、というお話が挙がっていました。
また、導入時にもしそういったチームを作ってしまった場合は、特定の人に負荷が偏りすぎないようにPagerツールなど仕組み化が重要だというお話が出ていました。
不安を監視すると運用コストに跳ね返ってきてしまう...
カーディナリティが大きすぎると運用コストに跳ね返ってくるため、カーディナリティを意識しましょうという話や、ユーザー視点での監視を心がけることが重要だというお話が出ていました。
今後監視がどのように変化していくと予想できるか？
閾値をベースにした監視から、過去の傾向から学んでアラートを出すという機能の整備が進んでいるので、今後は「こういったところを監視するといいよ」というアドバイスをくれるようなサービスが出てくるのではないか？というお話がまず松浦さんから挙がっていました。
大谷さんからは、関連のプラクティスを周りのツールと合わせてどう使いこなすか？というのがより重要になって、より成熟していくのではないか？というお話が挙がっていました。*5
会全体を通した感想
5年経った今でも監視に関する考え方は変わっていないものの監視対象のツールの進化が進んでいる現状がわかった点が面白かったです。
監視のスキルはまだまだ足りない状態なので、学びが多いイベントでした。
