はじめに
こんにちは、株式会社LegalOn TechnologiesでSREをしている石垣と申します。
2026年1月31日に開催された「SRE Kaigi 2026」にて登壇する機会をいただき、弊社のSRE Enablingの歴史をお話ししました。トピックの一つとしてObservabilityの向上策をお話ししたのですが、そこでObservability BackendとしてDatadogを導入したことについて触れました。しかし、発表時間の都合上、弊社でDatadogをどう使っているかについては泣く泣く割愛することになりました‥。Datadogの活用事例として参考になればと思い、今回ブログで公開することにしました。
なお、「SRE Kaigi 2026」で投影した資料については以下にアップしておりますので、もしよろしければこちらもご覧いただければと思います！
アプリケーションプラットフォーム”Akupara”
Akuparaとは？
なお、Akuparaの重要なポイントとして、マルチリージョン・マルチプロダクトに対応している点があります。弊社のメインプロダクトである「LegalOn」は2025年7月に米国に展開しておりますが、これもAkuparaがマルチリージョンに対応しているからこそ実現できています。また、弊社では現在「LegalOn」以外のプロダクトも鋭意開発中であり、このマルチプロダクト展開が実現できるのもAkuparaがマルチプロダクトに対応しているからこそなのです。
Akupara Observabilityに求められる要件
さて、そんなマルチリージョン・マルチプロダクトに対応したアプリケーションプラットフォームであるAkuparaですが、従来利用していたGoogle Cloud ObservabilityツールだけではObservabilityの向上やセルフサービス化が困難などの課題を抱えていました。こちらについては登壇の中で触れているので細かいところは資料をご参照いただくとして、本記事ではAkuparaの「マルチリージョン・マルチプロダクト向け」という特性上求められる要件についてご説明します。
「マルチリージョン」という観点では、Telemetry Dataをどこに保管するか、ということが重要になってきます。セキュリティ要件上各国向けプロダクトのTelemetry Dataは、当該国に保管しておく必要があります。例えば、日本向けのプロダクトであれば、Telemetry Dataは日本に保管しておかねばなりません。「LegalOn」を使用していただいているお客様の中には、エンタープライズ企業様も数多くいらっしゃるので、このセキュリティ要件は特に重要になってきます。一方、「マルチプロダクト」という観点では、各プロダクトのTelemetry Dataをしっかり分離しておく必要があります。こちらもセキュリティ要件上必要な対応で、例えばプロダクトAの開発者はプロダクトBに関するTelemetry Dataは閲覧できない、といったように閲覧権限を制限する必要があります。
Datadog for Akupara
Datadogを導入するまでの道のり
私が所属するSRE&Platformチームとしては、Akupara Observabilityが抱える課題を解決するためDatadogを導入したいと考えていたのですが、上で述べたセキュリティ要件がクリアできるかどうかというところが課題でした。
弊社のプロダクトは現在日本・米国で展開しているので、Telemetry Dataはこれらの国で保管される必要があります。幸い、Datadogは米国のSaaSであるのでメインは米国ですし、また2023年4月に東京リージョン（AP1）のデータセンターも開設されているので、この点に関しては問題なさそうでした。一方、各プロダクトのTelemetry Data分離に関しても、Data Access Controlを使えば要件を満たせそうでした(検証当時はPreview版でしたが、最近晴れてGAされましたね！)。
ということで、セキュリティ要件はなんとかクリアできたので、AkuparaにいざDatadogを導入！ということになりました。以降では、Akuparaの「マルチプロダクト・マルチリージョン」に対応するための、具体的なDatadog構成についてご説明します。
Datadog Organization構成
まず、「マルチリージョン」の要件に対応するために、国内向けにDatadog AP1リージョンのOrganization、米国向けにUS3リージョンを開設しました。Datadogでは、Multiple-Organizationという機能があり、一つ契約アカウントで複数のOrganizationを管理するための機能があります。しかし、この機能は同一リージョンに限られます。よって、今回はリージョンごとに別個のアカウントを契約することになりました。
なお、1つのmicroserviceを監視するために、AP1リージョン用のDatadogリソースとUS3リージョン用のDatadogリソースを作成する必要がありますが、この辺りはObservability専用のTerraform Moduleを作成して抽象化しています。詳細は私の登壇資料をご覧いただけると良いかと思います。
Data Access Control
Telemetry Data Tag設計
次に、「マルチプロダクト」の要件に対応するために、Data Access Controlの設定を行いました。Data Access Controlは、以下のように各Telemetry Dataのquery結果に対して、閲覧できるroleを設定する、といった使い方ができます。
今回はプロダクトごとのTelemetry Data閲覧権限を設定したいので、プロダクトごとのTelemetry Dataを簡単に抽出できる必要があります。そのため、Telemetry Dataにproduct というCustom Tagを設定するようにしました。Akuparaでは、DatadogにTelemetry Dataを送信するのにDatadog Agentを用いており、これをHelm Chart経由でDeployしています。そのため、Helm Chartのvalues設定において、このCustom Tagの設定をします。具体的には、以下のように、すべてのPodにproductを識別するlabelを付与し、そこからDatadog用Custom Tagを抽出するようにしています。
# values.yaml ... podLabelsAsTags: # Podにはどのproductを示す`*legalontech.dev/product`というlabelがついている # その値をDatadogの`product` tagの値として抽出する "*.legalontech.dev/product": "product"
少し今回の本筋から外れますが、参考としてそのほかどういったTagをつけているか、少しご紹介しておきましょう。
servicetag
これはDatadogにおいて最も重要なtagと言っても過言ではないものです。Akupara上のプロダクトは、複数のmicroserviceで構築されているので、Akuparaの管理方針としては、Datadogのservice をmicroserviceの粒度で設定しています。具体的には、以下の命名規則でこのtagの値を設定しています。
{product name}-{microservice name}
ちなみに、product というtagをつけておきながら、わざわざmicroservice nameの前にproduct nameをつけている理由は、プロダクト間で同名のmicroserviceが存在するためです。service tagに設定した値はDatadog上ではAPMサービスとして認識されます。これにより、プロダクト間で同名のmicroserviceが存在すると、次のような問題が生じます。
例えば、認証認可系の”identity”サービスがプロダクトAにもプロダクトBにも存在するとします。service tagの値に”identity”とだけ設定してしまうと、Datadog上ではプロダクトAのidentityサービスもプロダクトBのidentityサービスも同じAPMサービスとして認識されてしまいます。Akuparaではこれらを別個のAPMサービスとして扱いたいので、product prefixをつけているのです。
componenttag
こちらは、Kubernetesのnamespace内に存在するDeploymentやCronJobなどのworkload名を設定します。Akuparaでは、1 microservice = 1 namespaceという構成をとっているため、microserviceを構成するworkloadと考えてもらって差し支えありません。
Roleとrestriction query設計
Custom Tagの設定ができたら、あとはプロダクトごとにRoleを作成して、product tagによるqueryの閲覧権限をこれらのRoleに割り当てるだけです。ただ、この際に少し注意点があるので、その辺りもご説明しておきます。
Datadogには、LLM ObservabilityというAI特化の機能があります。これを使うには、まずApplication(ml_app)を作成する必要があります。LLM ObservabilityでData Access Controlを設定する際は、設定できるrestriction queryがこのml_appおよびDatadogが標準で用意しているtagだけにしか適用できません。この点には留意しておきましょう。Akuparaの場合では、プロダクト単位でml_appを作成することで、この辺りの制限を回避しました。
考察／今後の展望
Datadogは導入できたので、あとは開発者にしっかり有効活用してもらえるようにSREが支援していかねばならないと考えています。この辺りの話は「SRE Kaigi 2026」でも触れておりますが、開発者に対するEnablingを実施中です。Datadogを通して、開発者全員がObservabilityについてしっかり考えられる環境を作っていきたいと考えていきます。
謝辞
弊社にDatadogを導入する際、SRE&Platformチームのメンバー以外にも実にさまざまな方々にお世話になりました。CTOの深川さん、Staff Platform Engineerの杉田さんには弊社でDatadogをどう使うかについて何度も議論させていただきました。SRE&PlatformチームManagerの小市さんには、セキュリティ的な懸念をクリアするためIT&セキュリティ部門との折衝をしていただきました。また、法務の皆様にもリーガル面での懸念がないかレビューいただきました。
ここではすべての方を挙げきれませんが、関わっていただいたすべての方に最大限の感謝の言葉を述べたいと思います。本当にありがとうございました！
仲間募集！
LegalOn Technologiesでは一緒に働く仲間を募集しています！ご興味のある方はぜひご応募ください。お待ちしております。
