Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DATADOG MAKES YOU HAPPY #datadogJP
Search
Shun Yoshie
January 22, 2019
Technology
2
4.1k
DATADOG MAKES YOU HAPPY #datadogJP
Datadog Meetup#1 -Datadogはじめました!-での発表資料です。
#datadogJP
Shun Yoshie
January 22, 2019
Tweet
Share
More Decks by Shun Yoshie
See All by Shun Yoshie
Behind the scenes of 24-hour global online event
syoshie
1
19
20240825_ClosingRemarks(JAWS PANKRATION 2024)
syoshie
0
19
20240824_OpeningRemarks(JAWS PANKRATION 2024)
syoshie
0
14
AWS re:Inforce 2024 に コミュニティから登壇してきた話
syoshie
1
80
AWS User Group Leader Workshop - JAWS-UG case introduction -
syoshie
0
37
20240704 Zero Trust Strategy Implementation and Operational Challenges
syoshie
1
190
Amazon InspectorとAWS Security Hubを用いた予防的統制におけるリスク分析と運用設計
syoshie
2
770
日本発24時間グローバルイベント"JAWS PANKRATION 2024"の紹介
syoshie
0
160
How organizations are actually applying AWS security best practices
syoshie
0
34
Other Decks in Technology
See All in Technology
【完全版】Dify - LINE Bot連携 考え方と実用テクニック
uezo
2
510
軽いノリで"自動化"に取り組んではいけないという話
tetsuyaooooo
1
580
ガバメントクラウド開発と変化と成長する組織 / Organizational change and growth in developing a government cloud
kazeburo
4
920
Perlで始めるeBPF: 自作Loaderの作り方 / Getting started with eBPF in Perl_How to create your own Loader
takehaya
1
950
Slackbot × RAG で実現する社内情報検索の最適化
howdy39
2
340
OPENLOGI Company Profile
hr01
0
54k
LeSSはスクラムではない!?LeSSにおけるスクラムマスターの振る舞い方とは / Scrum Master Behavior in LeSS
toma_sm
0
210
O'Reilly Superstream: Building a RAG App to Chat with Your Data
pamelafox
0
120
今こそ変化対応力を向上させるとき 〜ログラスが FAST に挑戦する理由〜 / Why Loglass is Talking on the Challenge of Agile Framework FAST
shioyang
0
110
プロダクト価値を考えるための情報透明化とチーム文化づくり
nyo_taro
1
150
組織デバイスのための効率的なアプリケーション更新戦略
kenchan0130
0
290
ゼロから実装まで!機械学習入門
natsuki0726
0
200
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
46
4.9k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2k
KATA
mclloyd
27
13k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
4
120
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.1k
A Modern Web Designer's Workflow
chriscoyier
692
190k
Facilitating Awesome Meetings
lara
49
6k
Ruby is Unlike a Banana
tanoku
96
11k
Become a Pro
speakerdeck
PRO
24
4.9k
Transcript
Datadog Meetup#1 #datadogJP DATADOG MAKES YOU HAPPY 2019年01月22日 株式会社野村総合研究所 ビッグデータイノベーション推進部
吉江 瞬
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 2
自社サービスの現状把握 自社製監視ツールを使わなかった理由 なぜ、Datadogにしたか Datadogでやりたいこと ~セキュリティ風味~ モニタリングツールにおける辛み Datadogで検証したこと 目次 ZabbixからDatadogへの移行 今後の課題
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 3
自社サービスの現状把握 2018年8月に長いこと勤めたNRIセキュアテクノロジーズの出向解除および退社、NRIへの異動 異動先の業務はAWSを利用している自社サービス(TRAINAというシリーズの Smart Knowledge)のインフラ運用保守/セキュリティ対策/ 品質向上(と思っている) 異動して、業務が引き継がれていく中で、サービスの現状を把握 https://www.traina.ai/
Copyright (C) Nomura Research Institute, Ltd. All rights reserved.
判ったこと 珍しくもサービス開発はアジャイル開発 アジャイル開発だけど、会話レベルで蜜なインフラとアプリの連携が出来ていない(ある意味、部の問題) モニタリングツールはZabbix+CloudWatch、ジョブツールはJob Arranger 監視するサーバ台数少ないのに、年間保守費が高い モニタリングされていないコンテナサービスがいることが判明(今後もコンテナが本番に登場してくる予定) アプリのモニタリングについては、特定の文字列のみを取り上げる監視が行われている(パフォーマンス監視がない) ログはS3に貯まるが監視は特にされていない URL監視はない 監視アラートが鳴っても、メールしか飛んでこない 4 自社サービスの現状把握
Copyright (C) Nomura Research Institute, Ltd. All rights reserved.
普遍的なメトリックモニタリング System metrics (CPU, memory, disk) Infrastructure metrics (AWS CloudWatch) Web tracking scripts (Google Analytics) URL metrics (URL外形, URL内形) Application agents (APM, error tracking) 普遍的なログモニタリング System logs (syslog) Application logs (Java, Elasticsearch) Server logs (Apache, MySQL) Platform logs (AWS CloudTrail) 5 モニタリング とりあえず、出来ていたのは、 System metrics Infrastructure metrics System logs Application logs くらい
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 6
自社サービスのアーキテクチャ Amazon Route 53 Internet gateway APサーバ 2号機 APサーバ 1号機 ElastiCache (memcached) APサーバ 2号機 APサーバ 1号機 ElastiCache (memcached) Sorryサーバ 踏台サーバ コンテンツ 生成サーバ ナレッジサーバ 運用管理 クライアント (Windows Server) 運用管理 サーバ Zabbix JobArranger Fluentd Amazon SES Amazon S3 AWS CloudTrail CloudWatch MySQL DB MySQL DB (Multi-AZ) MySQL DB MySQL DB (Multi-AZ) IAM Classic Load Balancing Classic Load Balancing Classic Load Balancing endpoints endpoints VPC NAT gateway 顧客A 顧客B 顧客共通 運用・監視 AWS Certificate Manager AWS KMS AWS Management Console client NRI オンプレミスでのサービス提供もやっているが、基本はAWSを利用したマネージド・サービス
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 7
自社製監視ツールを使わなかった理由 自社製監視ツールおよびジョブツールもあるが、 珍しくもサービス開発はアジャイル → 「設定変更反映まで◯◯営業日かかります」が辛い。 モニタリングツールはZabbix+CloudWatch、ジョブツールはJob Arranger → リプレイスにおけるビジネスインパクトは? 監視するサーバ台数少ないのに、年間保守費が高い → むしろ、自社製のほうがという可能性 モニタリングされていないコンテナサービスがいることが判明 → ここを解決したいので、厳しい
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 8
自社製監視ツールを使わなかった理由 自社製監視ツールおよびジョブツールもあるが、 アプリのモニタリングについては、特定の文字列のみを取り上げる監視が行われている(パフォーマンス監視がない) → 自社製でも代替はできそうだが ログはS3に貯まるが監視は特にされていない → 自社製だと出来るはず? URL監視はされていない → たぶん出来ないはず 監視アラートが鳴っても、メールしか飛んでこない → オペレータから電話かかってくるようになる! さすがに、フルAWSな構成でかつアジャイル開発をやっているのに、モニタリング元はオンプレ環境で、作業依頼して◯◯営業日で設定を 行いますとかは、辛い。
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 9
自社製監視ツールを使わなかった理由 NRIだからNRIのサービスを必ず使う必要があるか?というと、それはない(と思っている。) 我々が提供するサービスに対して、他社サービスを利用するのも適材適所であればと考える。 特に、Cloud Nativeな構成である場合においては、なおさら。 電話をかける仕組みはどうするか? → Twilioの電話APIかPagerDutyで電話APIかつインシデント管理もできる仕組みを検討しようと内部で相談 → 導入速度優先で、Twilioに決定 障害メールは日々のチケット管理を行っているRedmineで障害対応漏れがないよう、すべてのアラートをチケット化することで、インシデント 管理も可能。以下のフォームをカスタマイズ RedmineでCSIRTのインシデント管理 http://blog.redmine.jp/articles/redmine-for-csirt/
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 10
自社製監視ツールを使わなかった理由 ちなみに、前部署ではこれまた千手ではなく、はてな社製のMackerelを導入しました。 https://mackerel.io/ja/ Mackerelを推したい理由: 週一で機能追加リリースが行われるところ こちらからの要望がエンジニアに刺さると、要望取り入れて開発着手してくれる 現部署では、コンテナのモニタリングというところでは、Mackerelでは厳しいと当時感じた。 おそらく今だとできそう https://mackerel.io/docs/entry/advanced/docker モニタリングしたいものはサーバだけではなかったことから、 Mackerelの採用は見送る。
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 11
自社製監視ツールを使わなかった理由 コンテナのモニタリングをしたいだけでなく、弊部の別サービスについては、オンプレでのサービスも提供していることから、オンプレのモニタ リングはもちろん、将来性からも、k8s、Serverlessのような構成にも対応できるモニタリングツールを考えたかった。
None
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 13
Datadogを採用した理由 Integrationしている製品の数とその内容
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 14
Datadogを採用した理由 有名所のソリューションはもちろん、CNCF landscapeに記載されている製品を今後も引き続きウォッチし、Integrationしていくという事業の 方向性が気にいった。 https://landscape.cncf.io/
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 15
Dashboardのカスタマイズが可能 見たい項目の画面だけでカスタムできることが魅力的 SIEM(Security Information and Event Management)ライクなことをDatadogで代替できないか検討したかった。 Datadogを採用した理由
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 16
Datadog blog、Datadog Advent Calendar、Datadogユーザーによる登壇スライドなど、豊富な事例 Datadogを採用した理由 https://speakerdeck.com/kazutomo/sabaresuapurikesiyonfalsejian-shi-yun-yong https://speakerdeck.com/dmmlabo/awsenziniagaonpuremisutodui-zhi-surutoki
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 17
犬好きの友人のせい Datadogを採用した理由
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 18
モニタリングツール運用における辛み 外部ベンダーにモニタリングアウトソースしている場合 外部ベンダーが運用するモニタリングツールでは、◯◯営業日後に設定反映ということ多々 障害テストなどやりたくても、ベンダーモニタリングツールによる設定可否や設定ミスなどですぐに修正できるかもわからない 自前運用の場合 対象となるサーバやアプリのモニタリング設定を追加する際は手作業での監視項目追加を行っていた あるタイミングからはAMIのゴールデンイメージとfabricとCloudFormationでなんとか モニタリングツールそのもののサーバやセキュリティ運用保守が面倒くさい
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 19
モニタリングツール運用における辛み 最近、面倒くさかったのは、phpmailerの脆弱性対応 phpmailer: https://github.com/PHPMailer/PHPMailer そのままphpmailerのバージョンアップ対応ではメール配送ができなくなった Zabbix用phpmailerとの差分を検証する必要があった CVE-2018-19296 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19296 こういった対応を自分たちで行うことが大変だからこそ、できるならモニタリングツールはアウトソースで安く利用したい
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 20
開く画面を一つにしたい。(つまり、Datadogの画面だけで簡潔できる嬉しさ) これは人によりけりかもですが、オンプレ時代には、モニター画面が2枚の状態で、 メーラー開いてる 作業手順書開いてる Windowsの踏み台サーバにRDPしてる画面を開いて、その中で Terminal開いてる(作業用、ログモニタリング用) WAFの管理画面を開いてる NGFWの画面を開いてる SIEMの画面を開いてる なにか問題が起きたとしても、DatadogのDashboardだけで確認できるオペレーションは非常に楽 モニタリングツール運用における辛み
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 21
Datadogで検証したこと Freeアカウントで、14日間チャレンジ Datadogの検証アカウントを作成 開発環境用AWSアカウントを連携するだけで、すでにいくつかのモニタリングが開始される 利用しているAWSのサービスをInstallするだけで、稼働してるインスタンス全台のリソースがモニタリングされる これまで、Zabbixの監視項目を手作業で追加してた人が、興味を示し始める。
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 22
Datadogで検証したこと さらに、一台にエージェントを入れると、詳細なリソースやOS情報が取れるようになって、さらに驚き始める
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 23
Datadogで検証したこと その上で動いているJavaやTomcatのIntegrationもすると、詳しいメモリの情報や利用リソース状況などが取得できて、さらに驚き始める
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 24
Datadogで検証したこと アプリ担当からも、先日のパフォーマンス障害もこれが入ってれば気づけたのに!というので、アプリ担当も驚き始める 検証期限が切れたので、延命依頼
Copyright (C) Nomura Research Institute, Ltd. All rights reserved.
その他、アプリケーションのIntegrationやログ分析周りの検証も2度程の延命を行って、ほとんどの検証は終了 Datadogの採用について、社内プレゼンをして、採用確定 現行のZabbixで行っているモニタリング内容をどれだけ、Datadogで引き継げるかを確認 既存の運用フローはほぼ変更せずに切り替えられそう 検証アカウントは検証用に(黒)。 本番をモニタリングするアカウントを作成(白)して、14日のFree期間を経て、課金開始。 25 Datadogで検証したこと
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 26
Datadogで検証したこと 機能検証 Datadogによる各種サービスのIntegration AWS利用サービス全般(EC2、Lambda、BillingCost、X-Ray)、Java、Tomcat、Docker、Fluentd GuardDuty Integration (後述) Windows Server Integration (後述) URL内外監視 Dashboard作成 GUIの色を白から黒に変更(サポートに依頼) ROM専アカウントの作成 運用検証 特定監視項目における監視のOFF/ON(一時的なもの、恒久的なもの) https://www.datadoghq.com/blog/
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 27
Datadogでやりたいこと ~セキュリティ風味~ GuardDutyのIntegration GuardDutyでイベント検知したものをDatadogで取り込む。 Datadogで必要なアラートのみフィルタリングした上で、SNS経由で、Twilioに連携
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 28
Datadogでやりたいこと ~セキュリティ風味~ Windows Server Integration JPCERTの以下のブログを参考にログイン周りのイベントをモニタリングできるよう設定 https://blogs.jpcert.or.jp/ja/2017/11/logontracer.html イベントID 4624: ログオン成功 イベントID 4625: ログオン失敗 イベントID 4768: Kerberos認証(TGT要求) イベントID 4769: Kerberos認証(ST要求) イベントID 4776: NTLM認証 イベントID 4672: 特権の割り当て その他にもSecurityEventやCrtiticalなイベントを拾えるようにした。 以下のBlogを参考に http://htnosm.hatenablog.com/entry/2018/07/30/090000
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 29
ZabbixからDatadogへの移行 各種エージェントのインストール作業とAMIゴールデンイメージの作成 Excelで確認した移行後の設定を行う。 移行後の運用確認
Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 30
今後の課題 他にも運用のために作っておきたいDashboardをこれから用意していく 必要なアラート、不要なアラートの簡易チューニングの実施 弊部別ソリューションのDatadog Monitoringへの移行 別の3rd Party Toolが吐き出すログをIntegrationしていくか検討 コンテナセキュリティツールの検証とDatadog Integration k8s検証とDatadog Integration
None
Copyright (C) Nomura Research Institute, Ltd. All rights reserved.
吉江 瞬
[email protected]
所属コミュニティ OWASP Japan PR Team Security-JAWS X-Tech JAWS Fin-JAWS JAWS DAYS 2019 実行委員 32 自己紹介
None