Enviar pesquisa
Carregar
Datadog Agent on CloudRunによるGCPトレービリティ向上
•
0 gostou
•
373 visualizações
Ryo Sasaki
Seguir
Bitkey x 3-Shake Datadog勉強会資料
Leia menos
Leia mais
Engenharia
Denunciar
Compartilhar
Denunciar
Compartilhar
1 de 55
Baixar agora
Baixar para ler offline
Recomendados
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
NTT DATA Technology & Innovation
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
[Cloud OnAir] BigQuery の仕組みからベストプラクティスまでのご紹介 2018年9月6日 放送
[Cloud OnAir] BigQuery の仕組みからベストプラクティスまでのご紹介 2018年9月6日 放送
Google Cloud Platform - Japan
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
NTT DATA Technology & Innovation
KubernetesでRedisを使うときの選択肢
KubernetesでRedisを使うときの選択肢
Naoyuki Yamada
Pokémon GOとGCP
Pokémon GOとGCP
Google Cloud Platform - Japan
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
Recomendados
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
NTT DATA Technology & Innovation
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
[Cloud OnAir] BigQuery の仕組みからベストプラクティスまでのご紹介 2018年9月6日 放送
[Cloud OnAir] BigQuery の仕組みからベストプラクティスまでのご紹介 2018年9月6日 放送
Google Cloud Platform - Japan
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
NTT DATA Technology & Innovation
KubernetesでRedisを使うときの選択肢
KubernetesでRedisを使うときの選択肢
Naoyuki Yamada
Pokémon GOとGCP
Pokémon GOとGCP
Google Cloud Platform - Japan
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
[GKE & Spanner 勉強会] Cloud Spanner の技術概要
[GKE & Spanner 勉強会] Cloud Spanner の技術概要
Google Cloud Platform - Japan
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
NTT DATA Technology & Innovation
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
NTT DATA Technology & Innovation
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
takezoe
Apache Kafka 0.11 の Exactly Once Semantics
Apache Kafka 0.11 の Exactly Once Semantics
Yoshiyasu SAEKI
Snowflakeって実際どうなの?数多のDBを使い倒した猛者が語る
Snowflakeって実際どうなの?数多のDBを使い倒した猛者が語る
Ryota Shibuya
トランザクション処理可能な分散DB 「YugabyteDB」入門(Open Source Conference 2022 Online/Fukuoka 発...
トランザクション処理可能な分散DB 「YugabyteDB」入門(Open Source Conference 2022 Online/Fukuoka 発...
NTT DATA Technology & Innovation
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
NTT DATA Technology & Innovation
設計書自動生成への取り組み~手書き設計書から脱却するには?~
設計書自動生成への取り組み~手書き設計書から脱却するには?~
SystemIntegrator2
Raft
Raft
Preferred Networks
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
NTT DATA Technology & Innovation
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
NTT DATA Technology & Innovation
Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
NTT DATA Technology & Innovation
HAクラスタで PostgreSQLレプリケーション構成の 高可用化
HAクラスタで PostgreSQLレプリケーション構成の 高可用化
Takatoshi Matsuo
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Toru Makabe
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
Preferred Networks
CentOS Linux 8 の EOL と対応策の検討
CentOS Linux 8 の EOL と対応策の検討
Masahito Zembutsu
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
例外設計における大罪
例外設計における大罪
Takuto Wada
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
NTT DATA Technology & Innovation
Graviton 2で実現する コスト効率のよいCDP基盤
Graviton 2で実現する コスト効率のよいCDP基盤
Kai Sasaki
Mais conteúdo relacionado
Mais procurados
[GKE & Spanner 勉強会] Cloud Spanner の技術概要
[GKE & Spanner 勉強会] Cloud Spanner の技術概要
Google Cloud Platform - Japan
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
NTT DATA Technology & Innovation
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
NTT DATA Technology & Innovation
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
takezoe
Apache Kafka 0.11 の Exactly Once Semantics
Apache Kafka 0.11 の Exactly Once Semantics
Yoshiyasu SAEKI
Snowflakeって実際どうなの?数多のDBを使い倒した猛者が語る
Snowflakeって実際どうなの?数多のDBを使い倒した猛者が語る
Ryota Shibuya
トランザクション処理可能な分散DB 「YugabyteDB」入門(Open Source Conference 2022 Online/Fukuoka 発...
トランザクション処理可能な分散DB 「YugabyteDB」入門(Open Source Conference 2022 Online/Fukuoka 発...
NTT DATA Technology & Innovation
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
NTT DATA Technology & Innovation
設計書自動生成への取り組み~手書き設計書から脱却するには?~
設計書自動生成への取り組み~手書き設計書から脱却するには?~
SystemIntegrator2
Raft
Raft
Preferred Networks
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
NTT DATA Technology & Innovation
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
NTT DATA Technology & Innovation
Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
NTT DATA Technology & Innovation
HAクラスタで PostgreSQLレプリケーション構成の 高可用化
HAクラスタで PostgreSQLレプリケーション構成の 高可用化
Takatoshi Matsuo
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Toru Makabe
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
Preferred Networks
CentOS Linux 8 の EOL と対応策の検討
CentOS Linux 8 の EOL と対応策の検討
Masahito Zembutsu
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
例外設計における大罪
例外設計における大罪
Takuto Wada
Mais procurados
(20)
[GKE & Spanner 勉強会] Cloud Spanner の技術概要
[GKE & Spanner 勉強会] Cloud Spanner の技術概要
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
Apache Kafka 0.11 の Exactly Once Semantics
Apache Kafka 0.11 の Exactly Once Semantics
Snowflakeって実際どうなの?数多のDBを使い倒した猛者が語る
Snowflakeって実際どうなの?数多のDBを使い倒した猛者が語る
トランザクション処理可能な分散DB 「YugabyteDB」入門(Open Source Conference 2022 Online/Fukuoka 発...
トランザクション処理可能な分散DB 「YugabyteDB」入門(Open Source Conference 2022 Online/Fukuoka 発...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
設計書自動生成への取り組み~手書き設計書から脱却するには?~
設計書自動生成への取り組み~手書き設計書から脱却するには?~
Raft
Raft
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
HAクラスタで PostgreSQLレプリケーション構成の 高可用化
HAクラスタで PostgreSQLレプリケーション構成の 高可用化
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
CentOS Linux 8 の EOL と対応策の検討
CentOS Linux 8 の EOL と対応策の検討
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
例外設計における大罪
例外設計における大罪
Semelhante a Datadog Agent on CloudRunによるGCPトレービリティ向上
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
NTT DATA Technology & Innovation
Graviton 2で実現する コスト効率のよいCDP基盤
Graviton 2で実現する コスト効率のよいCDP基盤
Kai Sasaki
GAE + Spannerで目指せ No (Uncomfortable) Ops
GAE + Spannerで目指せ No (Uncomfortable) Ops
Miniascape
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
Google Cloud Platform - Japan
私たちがGCPを使い始めた本当の理由
私たちがGCPを使い始めた本当の理由
gree_tech
Airflowを広告データのワークフローエンジンとして運用してみた話
Airflowを広告データのワークフローエンジンとして運用してみた話
Katsunori Kanda
GCPで実現するクラウドネイティブアプリケーション
GCPで実現するクラウドネイティブアプリケーション
Kiyoshi Fukuda
kubernetes(GKE)環境におけるdatadog利用
kubernetes(GKE)環境におけるdatadog利用
Koichi HARUNA
BazelでビルドしたアプリをGCPにデプロイしようとしてハマった話
BazelでビルドしたアプリをGCPにデプロイしようとしてハマった話
Katsunori Kanda
2016 06-30-deep-learning-archi
2016 06-30-deep-learning-archi
Daisuke Nagao
PF部第19回資料 poor man's JTAG
PF部第19回資料 poor man's JTAG
daye001
MEC (Mobile Edge Computing) + GPUコンピューティングについて
MEC (Mobile Edge Computing) + GPUコンピューティングについて
VirtualTech Japan Inc.
Rails on GKEで運用するWebアプリケーションの紹介
Rails on GKEで運用するWebアプリケーションの紹介
Makoto Haruyama
20190516_DLC10_PGStrom
20190516_DLC10_PGStrom
Kohei KaiGai
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
Insight Technology, Inc.
Windows 365 Enterprise に触れてみよう
Windows 365 Enterprise に触れてみよう
Yutaro Tamai
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
Kohei KaiGai
OpenStackネットワーク実装の現状 と運用自動化開発の実際
OpenStackネットワーク実装の現状 と運用自動化開発の実際
Shohei Yoshimoto
[VMware Partner Exchange Tokyo 14Apr2014] ネットアップセッション資料
[VMware Partner Exchange Tokyo 14Apr2014] ネットアップセッション資料
NetApp Japan
20220409 AWS BLEA 開発にあたって検討したこと
20220409 AWS BLEA 開発にあたって検討したこと
Amazon Web Services Japan
Semelhante a Datadog Agent on CloudRunによるGCPトレービリティ向上
(20)
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
Graviton 2で実現する コスト効率のよいCDP基盤
Graviton 2で実現する コスト効率のよいCDP基盤
GAE + Spannerで目指せ No (Uncomfortable) Ops
GAE + Spannerで目指せ No (Uncomfortable) Ops
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
私たちがGCPを使い始めた本当の理由
私たちがGCPを使い始めた本当の理由
Airflowを広告データのワークフローエンジンとして運用してみた話
Airflowを広告データのワークフローエンジンとして運用してみた話
GCPで実現するクラウドネイティブアプリケーション
GCPで実現するクラウドネイティブアプリケーション
kubernetes(GKE)環境におけるdatadog利用
kubernetes(GKE)環境におけるdatadog利用
BazelでビルドしたアプリをGCPにデプロイしようとしてハマった話
BazelでビルドしたアプリをGCPにデプロイしようとしてハマった話
2016 06-30-deep-learning-archi
2016 06-30-deep-learning-archi
PF部第19回資料 poor man's JTAG
PF部第19回資料 poor man's JTAG
MEC (Mobile Edge Computing) + GPUコンピューティングについて
MEC (Mobile Edge Computing) + GPUコンピューティングについて
Rails on GKEで運用するWebアプリケーションの紹介
Rails on GKEで運用するWebアプリケーションの紹介
20190516_DLC10_PGStrom
20190516_DLC10_PGStrom
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
Windows 365 Enterprise に触れてみよう
Windows 365 Enterprise に触れてみよう
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
OpenStackネットワーク実装の現状 と運用自動化開発の実際
OpenStackネットワーク実装の現状 と運用自動化開発の実際
[VMware Partner Exchange Tokyo 14Apr2014] ネットアップセッション資料
[VMware Partner Exchange Tokyo 14Apr2014] ネットアップセッション資料
20220409 AWS BLEA 開発にあたって検討したこと
20220409 AWS BLEA 開発にあたって検討したこと
Mais de Ryo Sasaki
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
Ryo Sasaki
ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜
ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜
Ryo Sasaki
ビットキーのIoT基盤におけるAWS IoT Rule Action 活用
ビットキーのIoT基盤におけるAWS IoT Rule Action 活用
Ryo Sasaki
[Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイフ...
[Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイフ...
Ryo Sasaki
[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜
[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜
Ryo Sasaki
CNDT2022_たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイブリッドクラウド
CNDT2022_たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイブリッドクラウド
Ryo Sasaki
DynamoDBの初心者に伝えたい初めて触るときの勘所
DynamoDBの初心者に伝えたい初めて触るときの勘所
Ryo Sasaki
OpenStackを導入・1年運用したチームの変化
OpenStackを導入・1年運用したチームの変化
Ryo Sasaki
AWSの真髄
AWSの真髄
Ryo Sasaki
Linux Kernel Parameter Tuning
Linux Kernel Parameter Tuning
Ryo Sasaki
Infrastructre as Ccodeの実現 - Ansibleの基本 -
Infrastructre as Ccodeの実現 - Ansibleの基本 -
Ryo Sasaki
きっと今すぐ使えるハッシュの基礎知識
きっと今すぐ使えるハッシュの基礎知識
Ryo Sasaki
Mais de Ryo Sasaki
(12)
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜
ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜
ビットキーのIoT基盤におけるAWS IoT Rule Action 活用
ビットキーのIoT基盤におけるAWS IoT Rule Action 活用
[Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイフ...
[Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイフ...
[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜
[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜
CNDT2022_たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイブリッドクラウド
CNDT2022_たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイブリッドクラウド
DynamoDBの初心者に伝えたい初めて触るときの勘所
DynamoDBの初心者に伝えたい初めて触るときの勘所
OpenStackを導入・1年運用したチームの変化
OpenStackを導入・1年運用したチームの変化
AWSの真髄
AWSの真髄
Linux Kernel Parameter Tuning
Linux Kernel Parameter Tuning
Infrastructre as Ccodeの実現 - Ansibleの基本 -
Infrastructre as Ccodeの実現 - Ansibleの基本 -
きっと今すぐ使えるハッシュの基礎知識
きっと今すぐ使えるハッシュの基礎知識
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やってないけどね 公の場で人に説明できるような輝かしい経歴は持ってないので サクッと流します!!!
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
Baixar agora