DATADOG MAKES YOU HAPPY #datadogJP

Datadog Meetup#1 -Datadogはじめました！-での発表資料です。
#datadogJP

Transcript

1. Datadog Meetup#1 #datadogJP DATADOG MAKES YOU HAPPY 2019年01月22日 株式会社野村総合研究所 ビッグデータイノベーション推進部 吉江 瞬
2. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 2 自社サービスの現状把握 自社製監視ツールを使わなかった理由 なぜ、Datadogにしたか Datadogでやりたいこと ～セキュリティ風味～ モニタリングツールにおける辛み Datadogで検証したこと 目次 ZabbixからDatadogへの移行 今後の課題
3. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 3 自社サービスの現状把握  2018年8月に長いこと勤めたNRIセキュアテクノロジーズの出向解除および退社、NRIへの異動  異動先の業務はAWSを利用している自社サービス(TRAINAというシリーズの Smart Knowledge)のインフラ運用保守/セキュリティ対策/ 品質向上(と思っている)  異動して、業務が引き継がれていく中で、サービスの現状を把握 https://www.traina.ai/
4. Copyright （C） Nomura Research Institute, Ltd. All rights reserved.  判ったこと  珍しくもサービス開発はアジャイル開発  アジャイル開発だけど、会話レベルで蜜なインフラとアプリの連携が出来ていない(ある意味、部の問題)  モニタリングツールはZabbix+CloudWatch、ジョブツールはJob Arranger  監視するサーバ台数少ないのに、年間保守費が高い  モニタリングされていないコンテナサービスがいることが判明(今後もコンテナが本番に登場してくる予定)  アプリのモニタリングについては、特定の文字列のみを取り上げる監視が行われている(パフォーマンス監視がない)  ログはS3に貯まるが監視は特にされていない  URL監視はない  監視アラートが鳴っても、メールしか飛んでこない 4 自社サービスの現状把握
5. 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 くらい
6. 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を利用したマネージド・サービス
7. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 7 自社製監視ツールを使わなかった理由  自社製監視ツールおよびジョブツールもあるが、 珍しくもサービス開発はアジャイル → 「設定変更反映まで◯◯営業日かかります」が辛い。 モニタリングツールはZabbix+CloudWatch、ジョブツールはJob Arranger → リプレイスにおけるビジネスインパクトは？ 監視するサーバ台数少ないのに、年間保守費が高い → むしろ、自社製のほうがという可能性 モニタリングされていないコンテナサービスがいることが判明 → ここを解決したいので、厳しい
8. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 8 自社製監視ツールを使わなかった理由  自社製監視ツールおよびジョブツールもあるが、 アプリのモニタリングについては、特定の文字列のみを取り上げる監視が行われている(パフォーマンス監視がない) → 自社製でも代替はできそうだが ログはS3に貯まるが監視は特にされていない → 自社製だと出来るはず？ URL監視はされていない → たぶん出来ないはず 監視アラートが鳴っても、メールしか飛んでこない → オペレータから電話かかってくるようになる！  さすがに、フルAWSな構成でかつアジャイル開発をやっているのに、モニタリング元はオンプレ環境で、作業依頼して◯◯営業日で設定を 行いますとかは、辛い。
9. 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/
10. 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の採用は見送る。
11. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 11 自社製監視ツールを使わなかった理由  コンテナのモニタリングをしたいだけでなく、弊部の別サービスについては、オンプレでのサービスも提供していることから、オンプレのモニタ リングはもちろん、将来性からも、k8s、Serverlessのような構成にも対応できるモニタリングツールを考えたかった。
13. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 13 Datadogを採用した理由  Integrationしている製品の数とその内容
14. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 14 Datadogを採用した理由  有名所のソリューションはもちろん、CNCF landscapeに記載されている製品を今後も引き続きウォッチし、Integrationしていくという事業の 方向性が気にいった。 https://landscape.cncf.io/
15. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 15  Dashboardのカスタマイズが可能  見たい項目の画面だけでカスタムできることが魅力的  SIEM(Security Information and Event Management)ライクなことをDatadogで代替できないか検討したかった。 Datadogを採用した理由
16. 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
17. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 17  犬好きの友人のせい Datadogを採用した理由
18. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 18 モニタリングツール運用における辛み  外部ベンダーにモニタリングアウトソースしている場合  外部ベンダーが運用するモニタリングツールでは、◯◯営業日後に設定反映ということ多々  障害テストなどやりたくても、ベンダーモニタリングツールによる設定可否や設定ミスなどですぐに修正できるかもわからない  自前運用の場合  対象となるサーバやアプリのモニタリング設定を追加する際は手作業での監視項目追加を行っていた  あるタイミングからはAMIのゴールデンイメージとfabricとCloudFormationでなんとか  モニタリングツールそのもののサーバやセキュリティ運用保守が面倒くさい
19. 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  こういった対応を自分たちで行うことが大変だからこそ、できるならモニタリングツールはアウトソースで安く利用したい
20. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 20  開く画面を一つにしたい。（つまり、Datadogの画面だけで簡潔できる嬉しさ）  これは人によりけりかもですが、オンプレ時代には、モニター画面が2枚の状態で、  メーラー開いてる  作業手順書開いてる  Windowsの踏み台サーバにRDPしてる画面を開いて、その中で  Terminal開いてる(作業用、ログモニタリング用)  WAFの管理画面を開いてる  NGFWの画面を開いてる  SIEMの画面を開いてる  なにか問題が起きたとしても、DatadogのDashboardだけで確認できるオペレーションは非常に楽 モニタリングツール運用における辛み
21. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 21 Datadogで検証したこと  Freeアカウントで、14日間チャレンジ  Datadogの検証アカウントを作成  開発環境用AWSアカウントを連携するだけで、すでにいくつかのモニタリングが開始される  利用しているAWSのサービスをInstallするだけで、稼働してるインスタンス全台のリソースがモニタリングされる  これまで、Zabbixの監視項目を手作業で追加してた人が、興味を示し始める。
22. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 22 Datadogで検証したこと  さらに、一台にエージェントを入れると、詳細なリソースやOS情報が取れるようになって、さらに驚き始める
23. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 23 Datadogで検証したこと  その上で動いているJavaやTomcatのIntegrationもすると、詳しいメモリの情報や利用リソース状況などが取得できて、さらに驚き始める
24. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 24 Datadogで検証したこと  アプリ担当からも、先日のパフォーマンス障害もこれが入ってれば気づけたのに！というので、アプリ担当も驚き始める  検証期限が切れたので、延命依頼
25. Copyright （C） Nomura Research Institute, Ltd. All rights reserved.  その他、アプリケーションのIntegrationやログ分析周りの検証も2度程の延命を行って、ほとんどの検証は終了  Datadogの採用について、社内プレゼンをして、採用確定  現行のZabbixで行っているモニタリング内容をどれだけ、Datadogで引き継げるかを確認  既存の運用フローはほぼ変更せずに切り替えられそう  検証アカウントは検証用に(黒)。  本番をモニタリングするアカウントを作成(白)して、14日のFree期間を経て、課金開始。 25 Datadogで検証したこと
26. 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/
27. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 27 Datadogでやりたいこと ～セキュリティ風味～  GuardDutyのIntegration  GuardDutyでイベント検知したものをDatadogで取り込む。  Datadogで必要なアラートのみフィルタリングした上で、SNS経由で、Twilioに連携
28. 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
29. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 29 ZabbixからDatadogへの移行  各種エージェントのインストール作業とAMIゴールデンイメージの作成  Excelで確認した移行後の設定を行う。  移行後の運用確認
30. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 30 今後の課題  他にも運用のために作っておきたいDashboardをこれから用意していく  必要なアラート、不要なアラートの簡易チューニングの実施  弊部別ソリューションのDatadog Monitoringへの移行  別の3rd Party Toolが吐き出すログをIntegrationしていくか検討  コンテナセキュリティツールの検証とDatadog Integration  k8s検証とDatadog Integration
32. Copyright （C） Nomura Research Institute, Ltd. All rights reserved.  吉江 瞬  s-yoshie@nri.co.jp  所属コミュニティ  OWASP Japan PR Team  Security-JAWS  X-Tech JAWS  Fin-JAWS  JAWS DAYS 2019 実行委員 32 自己紹介