![見出し画像](https://assets.st-note.com/production/uploads/images/83029302/rectangle_large_type_2_e894d143be9ca92542bb8608bb4a46dc.png?width=1200)
JaSST'22 Niigataで学んだ『Observabilityと監視』|イベント参加レポート
きっかけ
こんにちは。株式会社SHIFTでQAエンジニアをしている坪根です。
最近銀座鈴屋の釜出し甘納豆を初めて食べました。甘すぎなくてバクバク食べられちゃうのですが、缶詰に食べきりサイズで入っているので少しずつ食べられるのがうれしいです。
先日のJaSST'22 Tohokuに引き続き、2022年7月8日(金)に開催されたJaSST'22 Niigataに参加してきました。
なおJaSST'22 Niigataのテーマは「可観測性・Observability」です。
今回は以下のセッションで学んだことと感想を残していきたいと思います。
【基調講演】 「オブザーバビリティと監視」 松浦 隼人氏(オーティファイ)
【事例発表】 「そのプロダクト、「正常に動いてます!」と言えますか?QA視点からのObservability入門」 小島 直毅氏(リンクアンドモチベーション)
オブザーバビリティと監視【基調講演】
■講演者:松浦 隼人氏(オーティファイ)
オブザーバビリティとは
システムの振る舞いや内部をどれだけ把握できるかの程度。
監視とは
システムやコンポーネントの振る舞いや出力を観察し続けること。
■オブザーバビリティと監視の違い
以下のとおり対応できる状況が違う。
オブザーバビリティ
オブザーバビリティを高めることで未知の状況に対応できる。
監視
監視することで既知の状況に対応できる。
■なぜオブザーバビリティが必要なのか?
システムが複雑化、抽象化し、コンポーネントの数が増加している。
結果、問題が発生するパターンが増加している。
従来の監視ではすべてのパターンに対応できないため、オブザーバビリティが必要とされる。
■監視すべきところ、オブザーバビリティを考えるべきところ
ビジネス上の価値がインフラにある場合、オブザーバビリティより監視の方が重要。
ビジネス上の価値がソフトウェアにある場合は監視よりオブザーバビリティの方が重要。
■オブザーバビリティの「3つの柱」
以下の3つの情報がオブザーバビリティを高めるために必要な「3つの柱」である。
①メトリクス
何かがあった時に気づくための情報。
②ログ
個別のアクセスについて知るための情報。
以下の3点が高いログはオブザーバビリティを高める。
-カーディナリティ
一意にアクセスを特定できる可能性のこと。
-ディメンショナリティ
1イベント情報に対して付加情報をどれだけ持っているかのこと。
カーディナリティを向上させるためにすべての情報に一意キーを付与したり、ディメンショナリティを向上させるために付加情報を付与し過ぎるとログの可読性が下がってしまう。
なのでカーディナリティと可読性、ディメンショナリティと可読性それぞれのバランスをとることが重要。
-トレース
リクエストがどのような状態を辿ったかを知るための情報。
③構造化
ログの検索性を向上させるためにログへの情報の出力のされ方を整理すること。
■オブザーバビリティの「3つの柱」の功罪
「3つの柱」さえできていればいいと捉えられる場合もあるが、未知の状況に対応することが目的なので「3つの柱」はあくまで手段。
「3つの柱」を使って未知の状況に対応できるように準備できていなければならない。
《このセッションの感想》
オブザーバビリティと監視の違いについて理解できました。
私の所属する組織はソフトウェアにビジネス上の価値があるので、監視よりオブザーバビリティの方が重要なのだとわかりました。
なので私の所属する組織のオブザーバビリティがどうなっているのか確認してみようと思います。
「そのプロダクト、「正常に動いてます!」と言えますか?QA視点からのObservability入門」
■講演者:小島 直毅氏(リンクアンドモチベーション)
事例
講演者の組織では元々監視はSREというチームが担当していた。
ただしシステムが成長し複雑化することで監視対象のシステムの内容についてのSREの認知負荷が上がってしまった。
またシステムの複雑化と同時に組織の複雑化も起こりSREの監視対象のシステムが増えてしまった。
結果SREがシステムの内容を把握しきれなくなり、SREの監視から漏れてしまい障害が発生してしまったケースがあった。
そこでシステムの内容についてSREよりも認知負荷が低いQAが監視を担当し、SREはObservabilityの実現に注力できるようになった。
結果QAが「チーム全体がObservabilityを実現できる体制」の後押しをできた。
《このセッションの感想》
Observabilityを実現させるためにSREの代わりにQAが監視を担当しているのがすごいと思いました。
QAはシステムの内容についての認知負荷が低いというのは仰る通りだと思うのですが、私自身はシステムの仕様書などの資料更新くらいでしか普段のQA業務で得たシステムの内容についての知識をチームへ還元できていません。
なのでQAが監視を担当する第一歩として監視についての勉強を始めようと思います。
JaSST'22 Niigataに参加した感想
監視については自身の担当するプロダクトの死活監視に関する知識しかないので、知識が不足していることを知るいい機会になりました。
死活監視以外にもどういった監視が必要か勉強して、不足している監視があれば所属する組織・チームに監視の追加を提案してみようと思います。
またObservabilityについては今回初めて知りました。
監視の勉強をしていればObservabilityについての知識も少しは身につくと思うので、その中でObservabilityについて気になるところがあれば勉強しようと思います。
執筆者プロフィール: 坪根 圭佑
ERPパッケージソフトの開発会社で会計ソフトの手動テストを2年経験したのち、2019年にSHIFTに参画しました。普段はAPIテストを担当しています。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/