[レポート] Cloud Monitoring meetup with AWS #datadogjp
愛犬家のみなさま。 こんにちは オペレーション部 犬派の園部です。
今回は、3月20日に開催されました Cloud Monitoring meetup with AWS への参加レポートとなります。
イベント開催概要
変化し多様化するユーザーのニーズに応えるために柔軟なインフラが求められクラウド活用が進んでいます。 また、そのような環境下では開発と運用を切り離して考えることが難しくなり、 ユーザーへの安定したサービス提供と価値向上という目標を掲げたチーム体制が必要となります。 クラウド利用やマイクロサービス化によって複雑になるIT環境において、 複数のステークホルダーが同じ視点でサービス稼働をモニタリングすることがこれからのモニタリングで必要となってきます。 このMeetupでは、来日するDatadogのCTO AlexisからUSのトレンドや、モダンなモニタリングを実現するノウハウなどをお伝えします。
(引用:募集サイト)
How Datadog was born and grew with the cloud(Datadog CTO Alexis Lê-Quôc)
- 逐次通訳です!
- 1996 から現在までについて、IT技術の変遷の中でのDatadogの歴史をお話されていました。
- Datadogの由来や、DevOpsを意識した設計などが印象的でした。
- 初期のアイコンもいいですね。
How Datadog was born and grew with the cloud
Datadog の歴史と未来
1996-2010
- DevとOpsの懸け橋を目指して出発
- Datadog の由来は、当時利用していたOracleのマシンの愛称が由来
2011-
- 事業成長の時に、マシンリソースが必要となった際に、AWSと出会う
- クラウドならではのリソース変化に対して、タグでのモニタリング方式を採用
2014-
- Docker ブームが到来
- その時、Datadogは、Metrics サービスのみを提供
2015-
- コンテナの本格的な利用が開始
- k8s, Lambda 登場
- APM インテグレーションが進んでいく
- AI 技術の採用
- Datadog Traces サービスを追加(APM)
2016-
- パブリッククラウドの成長
- k8s, Serveless の本格化
2017-
- ECS, Fargate などのマネージドサービスの到来
- Datadog Logs サービスを追加
2018-
- DX 時代(Cloud, Container, Serverless)
- Datadog Synthetics サービスを追加
Datadog の将来展望
- End-To-End でのObservability を進めていきたい
- DX の変化スピードを停滞サービス提供
Datadogではじめるクラウドモニタリング(Datadog Sales Engineer 池山邦彦 様)
- Datadog 特徴と新しいサービスについてお話しされていました。
- 変化するインフラストラクチャへの対応
- コンテナ、サーバーレス、マイクロサービスなどのアーキテクチャへの対応
- AWSインテグレーションの豊富さと容易さ(IAMロール)は便利ですね。
- 外形監視がGA!!待っていたユーザーも多いはず。
Datadogとは
- 歴史的な背景からDevとOpsのためを意識
アーキテクチャの変遷
- ITインフラストラクチャに関連する状況について、変遷があり、Datadagは、次世代に対応している。
AWS x Datadog
- AWS との連携に力を入れている
- AWS Intergration (IAMロールで連携することでエージェントレスで、データを取得) Integrations
- 他クラウド環境をモニタリング対象とすることも可能
- CloudWatch or Datadog
- ハイブリッド、マルチクラウド、マルチアカウントへの対応がDatadogの強み(CloudWatchに比べて)
サーバーレスのモニタリング
- Datadog Cloud Functions
- Lambdaからメトリクス/トレース/ログを一元管理して相関検索が可能
コンテナのモニタリング
- k8s が活況
- Fargate 利用が増加
- モニタリングの方法
- コンテナの負荷状況や稼働状況を俯瞰することが可能
マイクロサービス
- 分散トレーシング
- 専用タグ(X-Datadog-Trace-IdとX-Datadog-Parent-Id)をHTTPリクエストヘッダに入れることで、トレーシングやサービスマップなどを可視化することが可能
- 新しいバージョンのOpenTracing の技術を採用
Synthetic(外形監視)
(引用: Datadog社より )
- 2019年3月にGA
- サービスの外側からHTTP(S)監視
- 複数拠点から監視
- APMは内側、Syntheticは外側
- Uptime Widget (現在:ベータ)を用いることで、SLO 指標をダッシュボードで表示することが可能
トライアル
- 14日間 利用可能
イベント告知
- 04/09 DevOps Days Tokyo 2019
- 04/16 Cloud Native Days Fukuoka
- 04/25 Cloud Native Sapporo #02
- 05/16 Datadog meetup #4
クラウド環境におけるモニタリングの重要性について(アマゾン ウェブ サービス ジャパン株式会社 大場 崇令 様)
- AWSの紹介、DevOpsの現状とAWSとの相性、CloudWatchの紹介について、お話しされていました。
- 「何の為に監視を行うかが大事」というの言葉がとても印象に残っています。自分も含めて、比較・導入する際に、機能やコストに大小に目がいきがちですが、何がしたいのか?に立ち返る・念頭に置くことを忘れてはいけないと思いました。
DevOpsの現状
- 俊敏さに必要な組織、人材とは?
- 要求の変化に柔軟に対応できる組織と人材
- 自動化を推進する組織、人材
- フィードバックを得て、素早く意思決定できる組織と人材
- DecOps を実現できる組織と人材
- DevOps = 無駄やボトルネックを取り除くことで、ライフサイクルを効率化し、高速化すること
- DevOps 重要な要素
- 文化 + 実践 + ツール
- AWSがDevOpsに適している理由
- インフラストラクチャのプロビジョニングと管理、アプリケーションコードのデプロイ、ソフトウェアリリースプロセスの自動化、アプリケーションとインフラストラクチャのパフォーマンスのモニタリングが簡素化される
- DevOpsで必要な(やるべき)要素が多く提供されている
モニタリングの必要性
- 継続的な改善にはモニタリングが必須
- 現状を理解して改善するには?
- ワークロードの健康状態を把握する
- 必要な項目(メトリクス)は?
- パフォーマンス
- プロセス
- アクセス数
- ツール
- 監視したい項目に合わせて適切なツールは検討できているのか?
- ツールの特性を理解する(得意/不得意)
Amazon CloudWatch
- CloudWatch: AWS 上で稼働するシステム監視サービス
- 死活監視 / 性能監視 /キャパシティ監視
- CloudWatch Logs: ログ管理プラットフォームサービス
- CloudWatch Logs Insights: ログ分析サービス
- CloudWatch Events: リソースの状態監視サービス、イベントトリガー
- 各サービスのハブ
- CloudWatch にも不得手な部分(≒ もっと得意な)があるので、目的にあわせて選択が必要
- モニタリングツールにこだわるのではなく、何がしたいのか?(目的と手段を間違えないこと)
- AWSに対応する製品は、 ESP オンライン から検索することが可能
ここがよかったDatadog 〜ソフトバンクのDatadog活用事例〜(ソフトバンク株式会社 山根 武信 様)
- 選定項目はまとめなのでもっと詳細なものがあるだと思いますが、他でも同じ指標として利用できると思いました。
Datadog採用の背景
- アプリケーション開発の課題
- 環境構築などアプリ開発以外の作業負荷
- CI/CD の見直し
- 開発から商用環境へのスムーズな移行、可用性の向上
- k8sの採用
- 監視設定・統計解析の作業負荷
- ZabbixからDatadogへ移行
選定経緯
- Zabbix vs Prometheus vs Datadog
- 学習コスト、オンプレ連携、構築工数、インスタンスオートディスカバリ、PoDオートディスカバリ の検討項目をたて、比較を行い Datadog を採用
Datadog でよかったこと
- モニター設定が簡単
- Multi Alert 機能(タグによる設定)
- Load Average がvCPU数に対応
- テンプレートでのホスト名埋め込み機能
- AutoDiscorvery
- 10分で100台設定できた!
- 連携機能が豊富
- AWS連携だけでも豊富
アジャイル開発のためのDatadog(ソフトバンク株式会社 関 修康 様)
- 仕様変更は当たり前!!そこへ対応するためにAgile、そして、それらを支援・加速させるDatadog というのが印象的でした。
仕様変更の連続
- 仕様変更はやめて欲しい!!(by エンジニア)
- 顧客であるビジネス部は、市場やお客様の変化に合わせていく必要があるため仕様変更は必須
- Agile + DevOps を採用
- 多様な構成要素のため、パフォーマンス問題が所在がわからなかった
- Datadog APM を採用
- 数日のうちに設定から原因究明まで完了
- Datadog 利用
- APM: 継続的なパフォーマンスモニタリングとして導入
- Monitors: Application死活監視の材料として導入
- Dashboards: Applicationの可視化ツールとして導入
- Log Management: ログ調査・分析ツールとして導入
- Agileと相性がよかった
全体へのQ&A
Q. Lambda インテグレーションに関して、基板側ログやメトリクスではなく、アプリケーションレベルのメトリクス取得はできるか?する想定はあるか? A. CloudWatch カスタムメトリクス、エージェントがあればdogstatd から取得は可能
Q. 分散トレーシングはヘッダーが必要不可欠? A. サービスマップや詳細な連携を見るには必要
Q. ダッシュボードをサービス単位で作成している場合に、どんなツールを使っていますか? A. 今は、手動です。terraform にサービスを該当するものがあるそうなので、そちらを検討している。