NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'22 Niigata

はじめに

当イベントは2年ぶりのオンサイトとオンラインによるハイブリッド開催となった。
久しぶりの対面での交流を期待して筆者は現地に赴き、人生初である新潟の地を踏んだが、当日の新潟は東京や大阪と変わらない気温で、初夏の日差しは思った以上に強かった。
オンサイト会場のNINNO(ニーノ)は「新潟＋イノベーション」の拠点として名付けられた施設である。外光を取り入れた空間の明るさや横長の大型スクリーンが特徴的で、当イベントも奥行きを取らずに座席を設置しており、参加者はどの位置でもモニタが見やすいよう考慮されていた。

オープニング

今回のテーマ「可観測性・Observability」の説明があった。
ライフサイクルの複雑性が増している中、運用と監視の視点が抜けていると感じたことが、テーマの発端になっている。

基調講演
「オブザーバビリティと監視」
　松浦 隼人 氏（オーティファイ）

講演の概要は以下の通りである。

オブザーバビリティの概念

Observability(オブザーバビリティ／可観測性)は、Observe：観察する＋Ability：～できること、から来ている。
元々は機械の制御理論において使われていた。
ソフトウェアにおいては、システムの振る舞いや内部の把握、またはそれらを高めるための取り組みもオブザーバビリティと呼ばれることがある。
この5年で急激に使われるようになった概念である。

オブザーバビリティと監視の違い

「監視」・・・システムが外からみてどうか。コンポーネントやイントラネットに着目。
「オブザーバビリティ」・・・アプリケーションサーバの中身やソフトウェア、振る舞い、データベースの状態といったシステムの内部の把握

"オブザーバビリティが高い" とは？

• 今まで経験したことがないことが起きても、どういう状態かを把握できる
• 何らかのツールを使って外側から中身を覗ける

監視は既知の状況に対処する(監視はオブザーバビリティを高めるための手段でもある)。
オブザーバビリティは未知の状況に対応できる。
そして、この2つは対立するものではない。

なぜ今、オブザーバビリティが必要なのか

マイクロサービスの普及やコンポーネントの増加により問題が発生するパターンが増え、監視の追加による対応では難しくなってきた背景がある。
ネットワークにおいてもサービスメッシュなど仮想化・抽象化され、監視には厳しい状況になっている。
マルチテナント化やユーザができることの多様化が複雑なアクセスパターンを発生させている。
どういったコンポーネントがマイクロサービスをどう通りレスポンスが返されるか、"点"ではなく"線"で見ないとわからない。

監視とオブザーバビリティをどういう風に使い分けるか

ビジネス上の価値の高さで軸足が変わってくる。

• IaaSなどインフラに価値がある場合：　オブザーバビリティ ＜ 監視
• SaaS、ソフトウェアに価値がある場合：　オブザーバビリティ ＞ 監視

どうすればオブザーバビリティの高いシステムを作れるか

オブザーバビリティの「3つの柱」について

1. メトリクス：これだけだと何かが起きている、ということしかわからない
   • 現在の状態を知る
   • トレンドを知る
   • アラートを送る
2. ログ(イベント情報)
   • 個別のアクセス、リクエストを知る
   • ３つの要件
     1. 構造化：検索性が重要。ログの各行にメタ情報をタグ付けしパースしやすくする
     2. 高いカーディナリティ：一意にアクセスを特定できる可能性の高い情報
     3. 高ディメンショナリティ：含まれるキーは多ければ多いほど良い
3. トレース
   1つのリクエストで行われるトランザクションの詳細を知るための情報。
   リクエストがどのような処理を辿っていったかを確認する。

未知の問題に必要な情報は何かを念頭に考える。
「Observability-driven development」

• 早い段階から考える
• シフトレフト

テスタビリティを実現する要素としてオブザーバビリティがある。
これはシステムの品質を高めるために欠かせない要素である。

まとめ

• 監視とオブザーバビリティはパラダイムの違いである
• どちらも共存できる
• 複雑なシステムでは未知な状況が発生するためオブザーバビリティが大事になる
• 開発する段階からオブザーバビリティを考えることが必要

筆者感想

恥ずかしながら講演を聞くまでは知らない概念だったが、今後の開発においての重要性を認識することができた。
QAとして今後の要件や設計レビューに、オブザーバビリティの「3つの柱」の視点を盛り込むなど、引き続き理解を深めていきたい。

事例発表１
「可観測性の先へ～人間系を含んだシステムのテストとしての障害訓練」
　ただただし 氏（freee）

freee社で行われた全社障害訓練の話である。
これは年1回10月に行われており、2021年の実施が大きな話題となった。

障害訓練は以下のシナリオで行われた。

1. 攻撃者がマルウェアを開発者がよく使うライブラリに仕込んでおく
2. エンジニアは知らずにインストールする
3. マルウェアは攻撃者のサーバに情報を送り、社内SNSにログインする
4. 本番サーバに侵入するための2要素認証は、社内SNSを利用する
5. CEOに脅迫状を送付

訓練の狙い

• 色々な箇所に仕込んでいるセンサーを活用すれば、何が起きたかわかるはず
• 2要素認証のリセットでの本人確認、不正ログイン時のアラート、といった問題に気付ける要素への対策が為されているか
• 何かしらの痕跡が振り返りに使えるのではないか

実際に何が起きたか

• 経営者は経営層を集め秘密に会議を開いた
• 開発チームは開発者だけで集まった
• 経営層が正常系バイアスによる判断ミスを起こした

上記はすべて人間としての問題行動である。

結果、期待していた観測事象は訓練の時間内には間に合わなかった。
センサーをたくさん配置しても有効活用できておらず、オブザーバビリティのためには、まず人間を鍛えなくてはならないという結論になった。

全社訓練を終えての考察

全社訓練の前に、もっと地道な取り組みが必要である。
小規模な組織における問題解決を誰でもできるよう、いわゆるソフトウェア開発のユニットテストと同じことが人間の組織にも必要なのではないか。
部門単位でできている前提でそれらを統合し、そこで全社的な問題が出ないかを確認するのが正しいステップではないか。

さらに訓練に際しては以下のポイントを考慮する。

• 運用・監視プロセスの中に人間の成長を見込んでいるか
• 経験から学ぶ文化は会社として奨励する
• 人間のミスを機械・ソフトウェアが補う仕組みを導入しているか

筆者感想

ただ氏も話されていたが、セキュリティの全社訓練の考察がテストのカルチャーと共通する点が興味深かった。
人間を鍛えるためには、訓練と意識付けを組織的な理解を得ながら継続していく必要性を感じた。

事例発表２
「そのプロダクト、「正常に動いてます！」と言えますか？ QA視点からのObservability入門」
　小島 直毅 氏（リンクアンドモチベーション）

講演の最初に、オブザーバル(可観測量/観測可能量)をスイカに例える説明があった。
スイカを叩くと時間の経過(スイカの水分量の変化)で音が変わる。この音からスイカの食べ頃を知ることができるが、この"どうやったら中身を知ることができるのか"がオブザーバビリティなのではないか。

本発表で話したいことは、オブザーバビリティの一歩前に立ち戻ることが、逆にオブザーバビリティを開発全体で進めることであり、それによりQAは安心領域ができる、ということである。

テストのオブザーバビリティ

• テスタビリティ(テスト容易性)の1つ
• 「見えるものしかテストできない」という概念で、テストオラクルやインプットの定義が大事である
• オブザーバビリティはControllability(可制御性)とセットで語られる

私たちが知らない動作が起こりうる、ということに対して明らかにしていくことがオブザーバビリティである。
QAとSREは結託して役割分担していかなければならない。

プロダクトの肥大と認知負荷のアンチパターン

プロダクトが複雑化すると組織も人の観点でも複雑化する。いわゆる「認知負荷」が起きる。
プロダクトが増えていき、各プロダクトにそれぞれSREがいるような複雑な体制になると、役割を決めて監視しないと大変なことになるようなインシデントも発生してくる。
SREが監視に追われる状態になり、5プロダクトにもなると認知負荷の限界を迎えることになる。
認知負荷の高まらない構造を取っていくこと(例えばマイクロサービスアーキテクチャ化)が理想である。

事例：性能改善プロジェクトにおけるSREとQA連携の事例

性能改善はしているが、性能ネックが特定のデータ量に依存している問題があった。
これはすぐ直せないため、観測するところから始めることになったが、SRE側は何を検知してよいか、どういうタイミングか、誰に、いったところで揉めた。
監視体制としてSREとQAは互いの押し付けあいに問題があり、それらを考慮して最初から監視できていれば簡単な話だった。
認知負荷が増えていくプロダクトの実装環境において、どのような体制が最も認知負荷を抑制するのか。どれが開発効率を上げ、どれが顧客に価値を与えるのかを考えることが重要である。

事例：性能改善プロジェクトにおける性能アラート

• パフォーマンス改善に終わりはない
• いつリスクが出てくるかわからない

これらを踏まえ、検知できるようにネックになりそうなAPIや処理に閾値を設定した。
上記はシンプルな話だが、以下の3つがないと実現できない。

1. 性能ネックの理解
2. 継続的な監視
3. 監視への知識

まとめ

• 監視をSREが持っている限りはプロダクトの肥大に伴い認知負荷が増加する。QAもリリース以降の環境の品質に無関心ではいけない
• 判断基準となる認知負荷が上がり続ける組織体系をなくす
• QAこそ監視に絡み、チーム全体がオブザーバビリティを実現できる体制を後押ししよう

筆者感想

オブザーバビリティを1プロダクトの話ではなく「認知負荷」というワードを用いて、組織的に考えなければいけない問題として話している点で視野が広がった。
また、SREとQAの連携にあたっての具体的な数多くのヒントを得ることができた。

筆者感想（全体）

内容がそれぞれ異なる3講演であったが、共通点が幾つもあったように思う。
良いオブザーバビリティの実現には、役割を越境したコミュニケーションや、プロダクト単位から組織的活動へといった、スコープを拡げて考える必要がありそうである。
今後さらに複雑化するプロダクトへの準備として、良い事例と知見を頂けた。
本シンポジウムは例年よりテーマを絞ったチャレンジングなものであったが、その分、満足度が高く、今後のJaSSTのテーマ選定にも参考になりそうである。