1. Datadog Agent on CloudRunによるGCPト
レーサビリティの向上
株式会社ビットキー 佐々木 了

2. Outline
1. Bitkeyにおけるサービスのアーキテクチャ
や分散トレースについて
2. GCP CloudTraceの問題点
3. Datadog AgentをGCPで低コストで使うため
に頑張った話
4. 懸念点と今後の話
2

3. 佐々木 了
Ryo Sasaki
2012/04
2017/07
某 通信系SIer 入社
・元々はNWエンジニアだったので BGP使った他拠点 NW作ったりとか
・自治体とか官公庁系システムに携わったりすることが多かったかな
・橋梁点検ロボット開発やったりとか
フリーランスに転向
・ペネトレーションテストやったりとか
・OpenStatkとOpenShift結構やってたりとか
・ハイブリッドクラウド作ったりとか
2021/11 ビットキーにSREとしてジョイン
※ぶっちゃけあまり SREやってないけどね
公の場で人に説明できるような輝かしい経歴は持ってないので
サクッと流します！！！

4. 4
(タイトルでネタバレしてるけど)
Datadog AgentをCloudRunで動かして、
CloudFunctionsなどのFaaSからAPMを利用できるようにしたよって
いう話です
(正確にはTrace)

5. Bitkeyにおける
サービスアーキテクチャ
5

6. Bitkeyにおけるサービスアーキテクチャ
- 基本的にGCPを利用したサーバーレスアーキテクチャ
- CloudFunctions (AWSでいうところのLambda)
- CloudRun (AWSでいうところのAppRunnerが近い)
- IoT製品がいくつか存在するが、それらはAWS IoTによって構成
- 加えてそれらを処理するためにLambda + API Gatewayを利用
6
GCP x AWS な アーキテクチャ

7. Bitkeyにおけるサービスアーキテクチャ
7
ここが全てGCPの
CloudFunctions or
CloudRun

8. Bitkeyにおける
現状の分散トレース利用について
8

9. Bitkeyにおける現状の分散トレース利用について
- 1000近いFaaSが存在するため、どこがどう繋がっていて、何がどう処理が進
んだかがわからない
- ドキュメントもまともになく仕様/設計の把握が困難
- トラブルシュートや何かリファクタするのにとてつもない工数が発生
9
x 1000弱
x 100弱

10. Bitkeyにおける現状の分散トレース利用について
- 1000近いFaaSが存在するため、どこがどう繋がっていて、何がどう処理が進
んだかがわからない
- ドキュメントもまともになく仕様/設計の把握が困難
- トラブルシュートや何かリファクタするのにとてつもない工数が発生
10
x 1000弱
x 100弱
どうにかできないか・・・？
せめてトラブルシューティングを何とか・・・！

11. Bitkeyにおける現状の分散トレース利用について
11
OpenTelemetry による分散トレースをやろう！
※時間がないので分散トレースって何やねんの話は省きます

12. Bitkeyにおける現状の分散トレース利用について
- ちなみにこの時点でAWS側はX-Rayを使ってサクッとトレースを実装
- Datadogでは公式ガイドに従って設定すれば、超簡単にX-Rayのトレースデータ
をDatadog APM に集約可能
- 特にハマる部分もなく非常に簡単
- ref. https://docs.datadoghq.com/ja/integrations/amazon_xray/
12
pull
Lambda
Functions
X-Ray

13. Bitkeyにおける現状の分散トレース利用について
- なぜOpenTelemetry ?
- GCPのフルマネージドの分散トレース可視化サービス(CloudTrace)が
OpenTelemetryをサポートしていたから
- OSSなので、何かしらのロックインも発生しないし、Instrumentationの開発も活発
に進んでいるので将来的に安定して使っていけるだろうという判断
13

14. Bitkeyにおける現状の分散トレース利用について
- なぜDatadog APMのTrace機能ではダメだったの？
- 最初に考えたのは当然 Datadog APMだった
- APM利用のためには Datadog Agent が必要
- k8sやAWS Fargateでは公式サポートされているが、
BitkeyのメインであるGCP Cloud Functionsではサポートされていない
14
それもそのはずでAgentはサイドカー的に動く
※k8sの場合ちょっと語弊のある言い方だけど

15. Bitkeyにおける現状の分散トレース利用について
- LambdaであればExtensionやDatadog Forwarderなどを使って簡単にトレースやログデータ
を収集できる
- X-Rayで良いならさらに簡単に連携できる
- dd-trace vs X-Rayは以下を参照
- https://docs.datadoghq.com/ja/serverless/distributed_tracing/
- Fargateの場合、そもそもPod的に複数コンテナをまとめて起動できるため
Agentをサイドカーとして起動できる
15
GCF や CloudRun ではこれができない

16. Bitkeyにおける現状の分散トレース利用について
16
というわけで、APMは利用せず、OpenTelemetryに頼った
可視化もGCP CloudTraceで出来るから楽ちん！
これで完璧や！！

17. Bitkeyにおける現状の分散トレース利用について
17
そうは問屋が卸さない

18. GCP CloudTraceの問題点とAPM
の利用検討
18

19. GCP CloudTraceの問題点とAPMの利用検討
19
問題点: CloudTraceの機能が貧弱すぎる

20. GCP CloudTraceの問題点とAPMの利用検討
- フィルタリングが結構きつい
- 目的のリクエストを探すのがしんどすぎる
- 毎秒数百〜数千っていうトレースが記録されていくのに、
そこから手動で探すのは流石に苦痛すぎる
20

21. Datadog AgentをGCPで
低コストで使うために頑張った話
21

22. Datadog AgentをGCPで低コストで使うために頑張った話
22
やっぱりDatadog APM使いたいなぁ。
AWS側もそうだしRUMを使った
フロントからのトレーシングも簡単にできるしなぁ。
しかもあっちの方がUI/UXが優れてるもんなぁ。

23. Datadog AgentをGCPで低コストで使うために頑張った話
23
というわけでGCPのCloudFunctionsやCloudRunにてAPM Traceを
利用できるように検討してみる。

24. Datadog AgentをGCPで低コストで使うために頑張った話
24
課題
・どうやってDatadog AgentをGCPで実装するか？
・如何にメンテナンスコストを下げた構成にできるか？
・スケーラビリティを上げられるか？

25. Datadog AgentをGCPで低コストで使うために頑張った話
25
とにかく楽に管理したい。
あーだのこーだのやりたくない。
だからと言って止まって欲しくない。安定稼働してほしい。

26. Datadog AgentをGCPで低コストで使うために頑張った話
- Compute Engine (AWSでいうEC2) でLinuxインスタンスでも立てて、そこで動
かせば？？
26
令和4年の今、積極的にその方法を採用したくはない。

27. Datadog AgentをGCPで低コストで使うために頑張った話
- AWS Fargateでサポートされているなら、そっちでデプロイしてGCP側から投
げてあげれば良いのでは？
27
できなくはないだろうけど、うーん。。。
あまり綺麗じゃないよね。
こんなことのためにグローバル横断して通信させたくない。
気にするほどのことではないとはいえレイテンシの問題もある。

28. Datadog AgentをGCPで低コストで使うために頑張った話
- APMはk8sでは正式サポートされているんだから、GKE用意してAgentを置い
てあげたら？
28
流石にこのためだけにk8s用意するのはコスパ悪い気が。
既にGKEを利用しまくっていて、多くのエンジニアが扱える状況なら良いんだけど、、、
前述の通り大半のプロダクトはFaaSで動いている関係で皆k8sを使い慣れていない。

29. Datadog AgentをGCPで低コストで使うために頑張った話
29
そんな時思いついた。
てか、Datadog AgentってDockerサポートされているよね？？
そりゃそうだ。そもそもk8sとかFargateでサポートされてるんだし。
それ使ってCloudRunで動かせば良くね？？
※BitkeyではCloudRunは割と利用されていて社内でのノウハウがある

30. Datadog AgentをGCPで低コストで使うために頑張った話
30
https://docs.datadoghq.com/ja/integrations/ecs_fargate/?tab=webui
やっぱりね
https://docs.datadoghq.com/ja/containers/docker/

31. Datadog AgentをGCPで低コストで使うために頑張った話
31
https://hub.docker.com/r/datadog/agent
そりゃあね

32. Datadog AgentをGCPで低コストで使うために頑張った話
32
課題
・どうやってDatadog AgentをGCPで実装するか？
・如何にメンテナンスコストを下げた構成にできるか？
・スケーラビリティを上げられるか？
全てCloudRunで解決できる！！！

33. Datadog AgentをGCPで低コストで使うために頑張った話
33
(唐突だけど) できた :tada:

34. Datadog AgentをGCPで低コストで使うために頑張った話
exporterの投げ先を変えるだけ！！！！
34
gcloud beta run deploy dd-agent
--image gcr.io/datadoghq/agent
--port 8126
--memory 1024Mi
--region asia-northeast1
--allow-unauthenticated
--set-env-vars "DD_HOSTNAME=common-dd-agent"
--set-env-vars "DD_APM_ENABLED=true"
--set-env-vars "DD_APM_NON_LOCAL_TRAFFIC=true"
--set-secrets "DD_API_KEY=DD_API_KEY:latest"
--execution-environment gen2
おもむろにgcloudコマンドを載せておく。これで終わり。

35. Datadog AgentをGCPで低コストで使うために頑張った話
Datadog Agent on CloudRunの良さ
- フルマネージドなのでめちゃくちゃ運用コストが低い
- 付随リソース(VPCやLB)の設計や管理が不要
- 公式に提供されているコンテナイメージを使って、あとは環境変数として
コンフィグを与えてあげればそれで終わり
35 CloudFunctions Datadog Agent on Cloud Run
dd-trace Push Container Registry

36. Datadog AgentをGCPで低コストで使うために頑張った話
Datadog Agent on CloudRunの良さ
- 何も考えずとも勝手にオートスケールしてくれるので
今後のスケーラビリティにも非常に優れる
- Bitkey実績だと、インスタンス数:1~20ぐらいで日々スケールしている
- どうせGCPのDC内部でインターコネクトな通信が行われるので
GCFから見てレイテンシが現実的に問題になることはないはず (妄想)
36

37. Datadog AgentをGCPで低コストで使うために頑張った話
● 参考程度にDatadog Agentで使う環境変数とか
○ https://docs.datadoghq.com/ja/containers/docker/?tab=%E6%A8%99%E6%BA%96#environment-variables
○ https://docs.datadoghq.com/ja/containers/docker/apm/?tab=linux
● この辺をよく使うはず
37
Key Value 補足
DD_APM_ENV your_environment datadog上で認識される envのデフォルト設定。
クライアントコード側で上書きできる。
DD_HOSTNAME your_ddagent_name 指定したホスト名で datadogに記録されるのでちゃんと考
えて！
DD_APM_ENABLED true APMの有効化設定
DD_OTLP_CONFIG_RECEIVER_P
ROTOCOLS_HTTP_ENDPOINT
0.0.0.0:4318 後述するOpenTelemetyのサポートのために必須
DD_APM_NON_LOCAL_TRAFFIC true 外部トラフィックを受け付ける設定。
今回のようなケースの場合 true必須
DD_API_KEY Secret:DD_API_KEY:latest 言わずもがな。平文で置かないようにしましょう。

38. Datadog AgentをGCPで低コストで使うために頑張った話
38
さらに現在のDatadog AgentはOTLPコレクターをサポートしている！
DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT を定義してあげれば OK
OpenTelemetryの取り込みができる！dd-traceに依存する必要がない！！
既存実装のOpenTelemetryの部分を変えず、Exporterの実装をDatadog Agentに向けてあげれば終わり!! (後述)
CloudFunctions Datadog Agent on Cloud Run
OpenTelemetry Push
OTLP コレクター

39. Datadog AgentをGCPで低コストで使うために頑張った話
注意点
- CloudRunはFargateと違って直接的にDokcerHubからPullしてこれない
- ただしGoogle Container Registyにコンテナイメージが
既にパブリッシュされているので、それをそのまま使えばOK
- gcr.io/datadoghq/agent
39

40. Datadog AgentをGCPで低コストで使うために頑張った話
注意点
- CloudRunの Gen2 を使おう
- Gen1はLinuxのエミュレーションであることもあって
めちゃくちゃエラー出る
- Gen2はLinuxそのものなので全く問題なし
- ただしそれでもDatadog Agentが提供する各種機能が
ちょこちょこエラー出すタイミングがあるので無駄な機能は停止しちゃった方が良い
- process とか sysprobe とか
40

41. Datadog AgentをGCPで低コストで使うために頑張った話
41
Infrastructure as Code も楽勝
● 既にCloudRunを構成するためのterraformコードは社内で既に確立
○ この構成もサクッとコード化完了！
● CloudRunなので余計なことを考えることも少なくめちゃくちゃ楽ちん運用！
● 勝手にスケールしてくれるので採用プロダクトが増えてきたから負荷が・・・とか考え
なくてOK!

42. Datadog AgentをGCPで低コストで使うために頑張った話
アプリケーションコード側の実装
- 普通にDatadog Agent on CloudRunが起動したら
あとはそこに対して投げつけるように実装すればOK
42
CloudFunctions Datadog Agent on Cloud Run
push

43. Datadog AgentをGCPで低コストで使うために頑張った話
exporterの投げ先を変えるだけ！！！！
43
import tracer from 'dd-trace';
export const setupTracing = (args: {serviceName?: string; serviceVersion?: string}) => {
return tracer.init({
service: args.serviceName ?? 'unknownFunction',
version: args.serviceVersion ?? 'unknownVersion',
url: 'https://your-dd-agent.run.app',
env: 'develop',
});
};
すっごい単純。url渡してあげるだけ。環境変数でも可。

44. Datadog AgentをGCPで低コストで使うために頑張った話
OpenTelemetryでの実装が既にあるなら、exporterの投げ先を変えるだけ！
44
const exporter = new OTLPTraceExporter({url: "https://your-dd-agent.run.app"});
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

45. Datadog AgentをGCPで低コストで使うために頑張った話
- CloudRun + LoadBalancerを予め構築しておけば
好きなFQDNでアクセスできるのでさらに良し
45
CloudFunctions Datadog Agent on Cloud Run
push
https://your.custom.domain
LoadBalancer
https://hogehoge.a.run.app

46. Datadog AgentをGCPで低コストで使うために頑張った話
46
環境やサービス単位
での絞り込みめっちゃ
簡単！
クエリ書いて爆速検索！
APM の UI いい！いいよ！！

47. Datadog AgentをGCPで低コストで使うために頑張った話
47
紐づくメタデータやログ
も紐づいているので調
査もしやすい！
各トレースを開けば、スパン
がめっちゃわかりやすく表示
される！ HTTPもgRPCもRDBへの
SQLも全て丸見え！！

48. 懸念点と今後の話
48

49. Datadog AgentをGCPで低コストで使うために頑張った話
49
懸念点
これだとグローバルに露出しているので
不特定多数からのアクセスがあるのでは？

50. Datadog AgentをGCPで低コストで使うために頑張った話
- yes
- ある程度、CloudArmorで不正な通信は防御可能
- が、そのエンドポイントに対してDatadog Agentが構築されていることを
知られた場合にはどうしようもない
- 現実的に本番環境で採用するのであれば、サーバーレスコネクターで
GCFやCloudRunたちとインターナル接続し、内部的なアクセスだけに
限定しておいた方が絶対良い
50

51. 懸念点と今後の話
- 現状と今後
- この仕組みを使って、OpenTelemetry + CloudTraceの環境から
一部を移行させてテスト中
- Datadog APMのTrace機能が非常に優秀で
トレースを使った分析やトラブルシュートが非常に捗る！捗る！
51

52. 懸念点と今後の話
- 現状と今後
- dd-traceも現実的に使えるようになったので、
OpenTelemetry vs dd-traceな評価も実施中
- AWS側のLambdaたちもAPMに集約させているので
クラウド横断かつフロント〜バックエンド〜IoTな一気通貫なトレースを目指したい
- ただし前述の懸念点があるので、このまま使い続けるかは不透明
- 一方でかなりAPMに良さを感じているのでチューニングしつつ
当面は評価し続けたい
52

53. 懸念点と今後の話
- まとめ
- Datadog APMはUI/UXが優れていてマジで捗るよ
- k8sやAWSに依存したサービスじゃないんだよなぁ・・・
APM使えないんかなぁっていう人、諦めないで！！
- コンテナイメージがあるんだからどうにでもなるよ
- CloudRun使えばマジで超絶楽ちんに実装と運用ができるよ
- 今のDatadog AgentはOpenTelemetryに対応しているので、
既存実装からのマイグレーションは低コストにいけるよ
53

54. 懸念点と今後の話
- オチ
- k8s使い慣れてるなら
GKE Autopilotで実装した方が
楽だし安心できそう。
Helmでインストールもできるしね。
- 参考: https://docs.datadoghq.com/ja/containers/kubernetes/distributions/?tab=helm#autopilot
54
apiVersion: apps/v1
kind: Deployment
metadata:
name: dd-agent
spec:
replicas: 3
selector:
matchLabels:
app: dd-agent
template:
metadata:
labels:
app: dd-agent
spec:
containers:
- name: dd-agent
image: datadog/agent:latest
ports:
- containerPort: 8126
env:
- name: DD_API_KEY
valueFrom:
secretKeyRef:
name: dd-api-key
key: DD_API_KEY

55. おわり
55