Recommended
More Related Content
What's hot
What's hot (20)
Similar to Datadog Agent on CloudRunによるGCPトレービリティ向上
Similar to Datadog Agent on CloudRunによるGCPトレービリティ向上 (20)
More from Ryo Sasaki
More from Ryo Sasaki (12)
Datadog Agent on CloudRunによるGCPトレービリティ向上
- 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やってないけどね 公の場で人に説明できるような輝かしい経歴は持ってないので サクッと流します！！！
- 6. Bitkeyにおけるサービスアーキテクチャ - 基本的にGCPを利用したサーバーレスアーキテクチャ - CloudFunctions (AWSでいうところのLambda) - CloudRun (AWSでいうところのAppRunnerが近い) - IoT製品がいくつか存在するが、それらはAWS IoTによって構成 - 加えてそれらを処理するためにLambda + API Gatewayを利用 6 GCP x AWS な アーキテクチャ
- 9. Bitkeyにおける現状の分散トレース利用について - 1000近いFaaSが存在するため、どこがどう繋がっていて、何がどう処理が進 んだかがわからない - ドキュメントもまともになく仕様/設計の把握が困難 - トラブルシュートや何かリファクタするのにとてつもない工数が発生 9 x 1000弱 x 100弱
- 10. Bitkeyにおける現状の分散トレース利用について - 1000近いFaaSが存在するため、どこがどう繋がっていて、何がどう処理が進 んだかがわからない - ドキュメントもまともになく仕様/設計の把握が困難 - トラブルシュートや何かリファクタするのにとてつもない工数が発生 10 x 1000弱 x 100弱 どうにかできないか・・・？ せめてトラブルシューティングを何とか・・・！
- 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で出来るから楽ちん！ これで完璧や！！
- 20. GCP CloudTraceの問題点とAPMの利用検討 - フィルタリングが結構きつい - 目的のリクエストを探すのがしんどすぎる - 毎秒数百〜数千っていうトレースが記録されていくのに、 そこから手動で探すのは流石に苦痛すぎる 20
- 23. Datadog AgentをGCPで低コストで使うために頑張った話 23 というわけでGCPのCloudFunctionsやCloudRunにてAPM Traceを 利用できるように検討してみる。
- 26. Datadog AgentをGCPで低コストで使うために頑張った話 - Compute Engine (AWSでいうEC2) でLinuxインスタンスでも立てて、そこで動 かせば？？ 26 令和4年の今、積極的にその方法を採用したくはない。
- 27. Datadog AgentをGCPで低コストで使うために頑張った話 - AWS Fargateでサポートされているなら、そっちでデプロイしてGCP側から投 げてあげれば良いのでは？ 27 できなくはないだろうけど、うーん。。。 あまり綺麗じゃないよね。 こんなことのためにグローバル横断して通信させたくない。 気にするほどのことではないとはいえレイテンシの問題もある。
- 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
- 48. 懸念点と今後の話 48
- 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