DATADOG MAKES YOU HAPPY #datadogJP

Datadog Meetup#1 #datadogJP
DATADOG MAKES YOU HAPPY
2019年01月22日
株式会社野村総合研究所
ビッグデータイノベーション推進部
吉江瞬

View Slide

Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 2
自社サービスの現状把握
自社製監視ツールを使わなかった理由
なぜ、Datadogにしたか
Datadogでやりたいこと～セキュリティ風味～
モニタリングツールにおける辛み
Datadogで検証したこと
目次
ZabbixからDatadogへの移行
今後の課題

View Slide

 2018年8月に長いこと勤めたNRIセキュアテクノロジーズの出向解除および退社、NRIへの異動
 異動先の業務はAWSを利用している自社サービス(TRAINAというシリーズの Smart Knowledge)のインフラ運用保守/セキュリティ対策/
品質向上(と思っている)
 異動して、業務が引き継がれていく中で、サービスの現状を把握
https://www.traina.ai/

View Slide

Copyright （C） Nomura Research Institute, Ltd. All rights reserved.
 判ったこと
 珍しくもサービス開発はアジャイル開発
 アジャイル開発だけど、会話レベルで蜜なインフラとアプリの連携が出来ていない(ある意味、部の問題)
 モニタリングツールはZabbix+CloudWatch、ジョブツールはJob Arranger
 監視するサーバ台数少ないのに、年間保守費が高い
 モニタリングされていないコンテナサービスがいることが判明(今後もコンテナが本番に登場してくる予定)
 アプリのモニタリングについては、特定の文字列のみを取り上げる監視が行われている(パフォーマンス監視がない)
 ログはS3に貯まるが監視は特にされていない
 URL監視はない
 監視アラートが鳴っても、メールしか飛んでこない
4

View Slide

 普遍的なメトリックモニタリング
 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
くらい

View Slide

自社サービスのアーキテクチャ
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を利用したマネージド・サービス

View Slide

 自社製監視ツールおよびジョブツールもあるが、
珍しくもサービス開発はアジャイル
→ 「設定変更反映まで◯◯営業日かかります」が辛い。
モニタリングツールはZabbix+CloudWatch、ジョブツールはJob Arranger
→ リプレイスにおけるビジネスインパクトは？
監視するサーバ台数少ないのに、年間保守費が高い
→ むしろ、自社製のほうがという可能性
モニタリングされていないコンテナサービスがいることが判明
→ ここを解決したいので、厳しい

View Slide

 自社製監視ツールおよびジョブツールもあるが、
アプリのモニタリングについては、特定の文字列のみを取り上げる監視が行われている(パフォーマンス監視がない)
→ 自社製でも代替はできそうだが
ログはS3に貯まるが監視は特にされていない
→ 自社製だと出来るはず？
URL監視はされていない
→ たぶん出来ないはず
監視アラートが鳴っても、メールしか飛んでこない
→ オペレータから電話かかってくるようになる！
 さすがに、フルAWSな構成でかつアジャイル開発をやっているのに、モニタリング元はオンプレ環境で、作業依頼して◯◯営業日で設定を
行いますとかは、辛い。

View Slide

 NRIだからNRIのサービスを必ず使う必要があるか？というと、それはない（と思っている。）
 我々が提供するサービスに対して、他社サービスを利用するのも適材適所であればと考える。
 特に、Cloud Nativeな構成である場合においては、なおさら。
 電話をかける仕組みはどうするか？
→ Twilioの電話APIかPagerDutyで電話APIかつインシデント管理もできる仕組みを検討しようと内部で相談
→ 導入速度優先で、Twilioに決定
 障害メールは日々のチケット管理を行っているRedmineで障害対応漏れがないよう、すべてのアラートをチケット化することで、インシデント
管理も可能。以下のフォームをカスタマイズ
 RedmineでCSIRTのインシデント管理
http://blog.redmine.jp/articles/redmine-for-csirt/

View Slide

 ちなみに、前部署ではこれまた千手ではなく、はてな社製のMackerelを導入しました。
https://mackerel.io/ja/
 Mackerelを推したい理由：
 週一で機能追加リリースが行われるところ
 こちらからの要望がエンジニアに刺さると、要望取り入れて開発着手してくれる
 現部署では、コンテナのモニタリングというところでは、Mackerelでは厳しいと当時感じた。
 おそらく今だとできそう
https://mackerel.io/docs/entry/advanced/docker
 モニタリングしたいものはサーバだけではなかったことから、
Mackerelの採用は見送る。

View Slide

 コンテナのモニタリングをしたいだけでなく、弊部の別サービスについては、オンプレでのサービスも提供していることから、オンプレのモニタ
リングはもちろん、将来性からも、k8s、Serverlessのような構成にも対応できるモニタリングツールを考えたかった。

View Slide

View Slide

Datadogを採用した理由
 Integrationしている製品の数とその内容

View Slide

 有名所のソリューションはもちろん、CNCF landscapeに記載されている製品を今後も引き続きウォッチし、Integrationしていくという事業の
方向性が気にいった。
https://landscape.cncf.io/

View Slide

 Dashboardのカスタマイズが可能
 見たい項目の画面だけでカスタムできることが魅力的
 SIEM(Security Information and Event Management)ライクなことをDatadogで代替できないか検討したかった。

View Slide

 Datadog blog、Datadog Advent Calendar、Datadogユーザーによる登壇スライドなど、豊富な事例
https://speakerdeck.com/kazutomo/sabaresuapurikesiyonfalsejian-shi-yun-yong
https://speakerdeck.com/dmmlabo/awsenziniagaonpuremisutodui-zhi-surutoki

View Slide

 犬好きの友人のせい

View Slide

モニタリングツール運用における辛み
 外部ベンダーにモニタリングアウトソースしている場合
 外部ベンダーが運用するモニタリングツールでは、◯◯営業日後に設定反映ということ多々
 障害テストなどやりたくても、ベンダーモニタリングツールによる設定可否や設定ミスなどですぐに修正できるかもわからない
 自前運用の場合
 対象となるサーバやアプリのモニタリング設定を追加する際は手作業での監視項目追加を行っていた
 あるタイミングからはAMIのゴールデンイメージとfabricとCloudFormationでなんとか
 モニタリングツールそのもののサーバやセキュリティ運用保守が面倒くさい

View Slide

 最近、面倒くさかったのは、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
 こういった対応を自分たちで行うことが大変だからこそ、できるならモニタリングツールはアウトソースで安く利用したい

View Slide

 開く画面を一つにしたい。（つまり、Datadogの画面だけで簡潔できる嬉しさ）
 これは人によりけりかもですが、オンプレ時代には、モニター画面が2枚の状態で、
 メーラー開いてる
 作業手順書開いてる
 Windowsの踏み台サーバにRDPしてる画面を開いて、その中で
 Terminal開いてる(作業用、ログモニタリング用)
 WAFの管理画面を開いてる
 NGFWの画面を開いてる
 SIEMの画面を開いてる
 なにか問題が起きたとしても、DatadogのDashboardだけで確認できるオペレーションは非常に楽

View Slide

 Freeアカウントで、14日間チャレンジ
 Datadogの検証アカウントを作成
 開発環境用AWSアカウントを連携するだけで、すでにいくつかのモニタリングが開始される
 利用しているAWSのサービスをInstallするだけで、稼働してるインスタンス全台のリソースがモニタリングされる
 これまで、Zabbixの監視項目を手作業で追加してた人が、興味を示し始める。

View Slide

 さらに、一台にエージェントを入れると、詳細なリソースやOS情報が取れるようになって、さらに驚き始める

View Slide

 その上で動いているJavaやTomcatのIntegrationもすると、詳しいメモリの情報や利用リソース状況などが取得できて、さらに驚き始める

View Slide

 アプリ担当からも、先日のパフォーマンス障害もこれが入ってれば気づけたのに！というので、アプリ担当も驚き始める
 検証期限が切れたので、延命依頼

View Slide

 その他、アプリケーションのIntegrationやログ分析周りの検証も2度程の延命を行って、ほとんどの検証は終了
 Datadogの採用について、社内プレゼンをして、採用確定
 現行のZabbixで行っているモニタリング内容をどれだけ、Datadogで引き継げるかを確認
 既存の運用フローはほぼ変更せずに切り替えられそう
 検証アカウントは検証用に(黒)。
 本番をモニタリングするアカウントを作成(白)して、14日のFree期間を経て、課金開始。
25

View Slide

 機能検証
 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/

View Slide

 GuardDutyのIntegration
 GuardDutyでイベント検知したものをDatadogで取り込む。
 Datadogで必要なアラートのみフィルタリングした上で、SNS経由で、Twilioに連携

View Slide

 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

View Slide

ZabbixからDatadogへの移行
 各種エージェントのインストール作業とAMIゴールデンイメージの作成
 Excelで確認した移行後の設定を行う。
 移行後の運用確認

View Slide

今後の課題
 他にも運用のために作っておきたいDashboardをこれから用意していく
 必要なアラート、不要なアラートの簡易チューニングの実施
 弊部別ソリューションのDatadog Monitoringへの移行
 別の3rd Party Toolが吐き出すログをIntegrationしていくか検討
 コンテナセキュリティツールの検証とDatadog Integration
 k8s検証とDatadog Integration

View Slide

View Slide

 吉江瞬
 [email protected]
 所属コミュニティ
 OWASP Japan PR Team
 Security-JAWS
 X-Tech JAWS
 Fin-JAWS
 JAWS DAYS 2019 実行委員
32
自己紹介

View Slide

View Slide

DATADOG MAKES YOU HAPPY #datadogJP

DATADOG MAKES YOU HAPPY #datadogJP

Shun Yoshie

More Decks by Shun Yoshie

Other Decks in Technology

Featured

Transcript