大規模組織でオブザーバビリティツール導入を検討する際の勘所

はじめに

こんにちは。Datadog Japan で Sales Engineer をしている 木村健人(AoTo)です。

Sales Engineer という職種は、Datadog の導入を検討されているお客様にプリセールスの段階で専任のスペシャリストとして導入支援を行う役割を担うことが主な業務です。

すでに成熟した SRE 組織がオブザーバビリティツールの導入を検討されることもありますが、多くの場合は SRE の体制とともに初めてのオブザーバビリティツール導入の検討を行います。その際、初めから複数のチームにまたがっての導入を検討されるケースも多くあります。

本記事では、大規模組織つまり複数のプロダクトチームが関わるオブザーバビリティツール導入を検討する際の勘所をまとめました。

免責事項

本記事内で説明される内容は、筆者個人の経験に基づく意見・考え方の一例であり、所属組織を代表するものでは一切ございません。

オブザーバビリティツールの特性と導入判断

大規模組織におけるオブザーバビリティツール導入は、単なるツール選定として進めることが難しい場合があります。なぜなら、大規模組織が抱えているシステム全体と、オブザーバビリティツールのような広範な機能を提供するツールの機能全体を全て評価しようとした場合、(システムの総数) × (ツールの機能数) の項目を検討する必要があるためです。

このように、すべての項目を考慮してオブザーバビリティツールを評価することは事実上不可能であり、数多の評価項目の中からプロダクトチームや利用者に求められる項目を限定する必要があります。そのため、求められる機能・非機能の項目をまとめる工程、いわゆる「要件定義」を行うことが、導入時の評価・検討を意味あるものとするために重要です。

大規模組織つまり複数のプロダクトを導入対象とする場合は、それそれのプロダクトチームや利用者が抱える様々な要求を評価・検討します。その際、それぞれの要求にどのような背景があるかを整理(要求定義)し、適切な機能・非機能要件に反映(要件定義)することが求められます。

要件定義

ここで、本記事で利用される「要件定義」という用語の立ち位置について整理します。 一般的な要件定義は、システム(開発・構築)の発注時に実施される各工程の内、発注者のシステム像を明確にすることが目的とされます。¹

一方で、既成のプロダクトを利用する際は、システムの利用者が求めるものを同様に明確にする必要がありますが、その内容に基づいた機能開発は実施されないため、必ずしも機能・非機能要件が満たされないことが前提となります。

さらに、システム設計・開発は実施されないため、これらに対応するシステム開発に対応するテスト工程も実施されません。代わりに、「要件定義」で定められた各項目に既成のプロダクトや機能が対応可能かを、概念実証を通して評価する必要があります。

この前提で、オブザーバビリティツールの導入に必要な「要件定義」の要素を考えてみましょう。

要件定義の項目は、大きく機能要件と非機能要件に大別されます。その上で各要件の大項目・中項目・小項目と段階的に項目を定義していきます。 ここからは、それぞれの大項目を正しく定義するために必要・考慮すべき情報と、定義のプロセスを整理していきます。

機能要件

機能要件では、オブザーバビリティツールを利用する上でどういった機能が必要となるかを定義します。

導入対象

オブザーバビリティツールは、実働しているシステムの状態を外部から把握して、問題の根本原因や解決策を特定するためのツールです。オブザーバビリティを向上するためのアプローチは単一ではなく、オブザーバビリティの主要シグナル²であるメトリクス・ログ・トレース・プロファイル・ダンプをはじめ、多種多様な監視情報をまとめることが考えられます。こうした特性上、どのシステムどのような状態を把握したいかを導入前に判断する必要があります。

さらに、導入対象は既存で他の監視・オブザーバビリティツールを利用しているシステムの場合もあれば、監視・オブザーバビリティツールの導入実績のないシステムや新規システムの場合もあります。複数のプロダクトチームにまたがる大規模組織への導入の場合は、これらを整理しておく必要があります。

これにより、導入の判断に関わるチームとそのチームが監視・オブザーバビリティに求める要求を明らかにするための準備が整います。加えて、オブザーバビリティツールが提供する監視エージェントや API が監視対象の技術スタック³への互換性を提供しているかを確認し、最低限の足切り条件を早々に判断できます。

これにより「要件定義」では、導入対象のシステムに応じて、求められるオブザーバビリティを考慮することができます。

導入プロダクト

前述の通り、オブザーバビリティツールは多種多様な監視情報を扱えるように設計されています。オブザーバビリティツールに含まれるすべての機能・プロダクトを対象とするのではなく、導入対象のシステムに求められるオブザーバビリティを考慮し、導入するプロダクトを検討します。

一般的に、オブザーバビリティツールはメトリクス・トレース・ログ・プロファイル・RUM・外形監視・イベント管理などのプロダクトカテゴリーが提供され、近年ではこれら以外のプロダクトカテゴリーを用意している場合も多くあります。求められるオブザーバビリティが考慮されていれば、これらの内どのプロダクトカテゴリーを検証と対象とするかをシステム毎に限定できます。

これにより、どのチームの要求がどの機能に対する要件として落とし込む必要があるかを把握し、各プロダクトを大項目として機能に対して「要件定義」を開始できます。

非機能要件

非機能要件では、オブザーバビリティツールを利用する上で各機能に求められる品質や保証を定義します。

オブザーバビリティツールを導入する際にも、「非機能要求グレード」で定められる「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つの分類⁴をを非機能要件の大項目として利用できます。

これに加え、オブザーバビリティツールにおいて非機能要件を考慮する上で重要な内容を整理していきます。

オブザーバビリティへの理解

導入対象と導入プロダクトが決まっても、利用するオブザーバビリティツールの理解がない場合、オブザーバビリティツールが提供し得ない要件を定めてしまう場合があります。

特に、トレースや APM と称されるカテゴリーは、これまでオブザーバビリティツールを利用したりオブザーバビリティツールの導入を検討したことがない場合、その特性を事前に把握しておく必要があります。

一例として、トレースデータはあるアプリケーションの個々のリクエスト処理にかかった時間やステータスを示しますが、こうした監視情報を全て長期間保持することは稀です。一般的には、トレースデータはアプリケーションの動きを代表するトレースと特異なトレースのみをサンプリングし、インシデントの根本分析やパフォーマス改善に活用することが想定されています。

こうしたオブザーバビリティツールの特性に理解がなく、すべてのトレースデータを長期間保持することを要件に加えた場合、導入時のコストが許容できないものとなり、現実的な導入判断が難しくなります。

オブザーバビリティの目的

改めて、オブザーバビリティとは「システムの状態を外部から把握して、問題の根本原因や解決策を特定する尺度⁵」とされます。そして、そのオブザーバビリティを向上することで、システムの信頼性を向上させることができます。

こうしたオブザーバビリティとそれを向上する目的を正しく理解しなければ、目的に沿わない・必要以上の非機能を要件としてしまう可能性が高まります。一般的なオブザーバビリティの目的と、それぞれのシステムに求められるオブザーバビリティとその目的を見定め、オブザーバビリティツールに求められる非機能要件を明確にしていくことが重要です。

おわりに

以上のように、大規模組織においてはオブザーバビリティツールの導入を検討する際、ツールの機能を網羅的に検討するのではなく、自組織とそれぞれのシステム求められるオブザーバビリティを明らかにすることで、有効な導入判断ができることを説明しました。

これに加え、求められるオブザーバビリティを明確にするには、ある程度の要求定義のプロセスも重要となります。つまり、なぜオブザーバビリティが必要かを、現状の把握・問題や課題の抽出・目的や目標の明確化を通して整理する必要があります。この工程は「ユーザーのための要件定義ガイド」にもある、一般的なビジネス要求定義やシステム化要求定義のプロセスが適用できるように思います。