アプリケーションエンジニアがMackerelで楽しく監視構成している事例
- 2. © DMM.com Group • ⾃⼰紹介 • 導⼊ストーリー • 監視構成 • 得られた価値 • まとめ 2 アジェンダ
- 3. © DMM.com Group 太⽥浩⼀ • id:koudenpa • 中⼩SI→DMMへ来て2年半 • アプリケーションエンジニア • 他のレイヤはほどほど • 監視の構成経験なし • 最近の⼝癖「レイヤーとロールの違い」 3
- 4. © DMM.com Group ⻄岡景⼦ • id:heleeen • 2015年新卒 • 社会⼈3年⽬ • アプリケーションエンジニア • もちろん０からの監視構成はやったことない • 最近 • イカが楽しいです 4
- 5. © DMM.com Group 5 DMM.comについて DMM.comとグループについて
- 6. © DMM.com Group 6 グループについて DMM.com Groupは、動画や電⼦書籍など のダウンロード販売ほか、ゲームや通販、 オンラインレンタルなどを提供するサイト 「DMM.com」の構築から運営までを⼿が けているグループです。 About Group 株式会社DMM.com 事業の企画・営業 DMM.comラボ システム開発・運営 ネットワークインフラの提供 Webマーケティング株式会社 株式会社DMM.com証券 FX・CFDの運営 株式会社DMM.com OVERRIDE DMM GAMES制作・運営 2D / 3Dデザイン制作 ゲームネットワークインフラの運⽤ 株式会社DMM.com Base DISCメディアのプレス、アッセンブ リ業務、物流サービス事業 DVD、CD、BDなどのソフトレンタ ル事業 株式会社DMM.futureworks DMM VR THEATERの運営および プロデュース・企画、 ⾳楽・映像コンテンツの制作
- 7. © DMM.com Group 7 DMM.comは1999年から続く⽼舗サービス サイトです。時代のニーズに合わせた多彩 なコンテンツを、17年間培った独⾃プラッ トフォームで安定的に提供しています。 About DMM.com 40以上の幅広いサービスを展開 サービスについて 担当は ココ
- 10. © DMM.com Group 今回は • アプリケーションエンジニアから⾒た事例 • どなたにも参考になれば幸い 10
- 12. © DMM.com Group 12 DMM.makeとは 「モノづくり」に関係する「⼈」と 「情報」と「ツール」が集まる makerのためのプラットフォーム。 ３D、IoTのサービス郡。
- 13. © DMM.com Group 導⼊背景 • これまでDMMのサービスはオンプレミスが主流 • 担当サービスを世の流れにしたがってクラウド移⾏することに • これに伴いエンジニアの責務が変化 • クラウド移⾏前 • 仮想マシンとネットワークまではインフラエンジニアが担当 • 移⾏後 • アプリケーションエンジニアが全て担当 13
- 14. © DMM.com Group 今回話す内容 • 話のネタは数あれど • あくまで監視について • クラウド移⾏⾃体についても⾊々ありました 14
- 15. © DMM.com Group .makeのクラウド移⾏事情 • 移⾏先はAWS • 移⾏対象システムが⼤きく分けて３つ • 担当は主に2⼈ • フルコミットではない • 期間は半年くらい • 圧倒的に⼈⼿が⾜りていない 15
- 16. © DMM.com Group 監視はどうする？ 16 ？？？ オンプレミスデータセンター AWS クラウド 監視サーバー アプリケーションサーバー データベースサーバー ● 移⾏前は監視サービスを 独⾃にホスティング ● インフラからサービスに担当が変化 ● 移⾏後はどうする？ ※他にも監視要素は多々有
- 18. © DMM.com Group AWSで⼀元管理を想定 • すべてAWSにまとめよう • 全⾯的にAWSのマネージドサービス想定 • 監視は？ • CloudWatch+Lambdaを試⾏ • 監視して、通知して、まで 18
- 19. © DMM.com Group そんな中 AWS Summit Tokyo があった • EXPOのブースをまわった • Mackerelのブースへも⾏った • 即⽇営業メールがくる • 動きが早い • なんとなくで、営業を受けた 19
- 21. © DMM.com Group ２時間さわったアウトプット • 監視できた！ 通知来た！ • 指⽰に従うだけでやりたかったことができた • 遊んだ直後だったので、営業さんの話に実感を得られた • 担当営業id:soudai（現CRE） • 営業を受けて本格的に検討を始めた • Mackerel超簡単！！ 21
- 22. © DMM.com Group Letʼs 稟議 • 使⽤するサービスを増やす＝⼿続きが必要 • それでも導⼊する価値が⼤いにあると感じた • 特に、監視を構成する時間（⼈的コスト）が⼤いに削減される • 上⻑に処理を依頼 • 処理してくれる⼈がいて幸運だった 22
- 23. © DMM.com Group 稟議を通すにあたって⽐較はしました • ⽐較観点 • ⾃分たちが運⽤するにあたっての利便性 • 結論 • Mackerelはとにかく楽 • 論拠 • 簡単かつ柔軟に設定できた • メトリクス収集、通知設定 • ドキュメントが⽇本語であり理解しやすい • ドキュメントの構成⾃体が理解しやすいものでもあった • などのこちらの事情と上⼿くかみ合っていた 23
- 24. そして構築・運⽤がはじまった
- 26. 26 AWS クラウド CloudFront Image CloudFront Application S3 bucket Image Elastic Load Balancing EC2 Instances Application RDS Aurora AWS リソースを構築 監視Agentを含むVM内容を構成 メトリクスを収集 S3 bucket Resource VPC endpoint サービス毎のVPC
- 27. © DMM.com Group サーバーはまだペット • EC2の完全なIaCはできていない • 家畜ではなくペットとしてかわいがっている状態 • Terraformで構築 • Ansibleで各種設定 • の2段階管理 • Mackerel-Agent設定はAnsible-Role • https://github.com/mackerelio/ansible-mackerel-agent • GroupVers, HostVers で処理 27
- 28. © DMM.com Group 監視構成 • 監視対象 • EC2, ALB, RDS • アプリケーションのホスティング以外はマネージドサービスを利⽤ • EC2 • 各種メトリクス • ミドルウェア, アプリケーションの死活 • Check-Log • 他 • AWSインテグレーションにお任せ 28
- 29. © DMM.com Group サービス、ロール設定（Group Variables） mackerel_agent_roles: - "3dprint:webapp" - "3dprint:api" 29 mackerel_agent_roles: - "3dprint:batch"
- 30. © DMM.com Group mackerel_check_plugins: check-httpd: "check-procs -p httpd" check-appfront-log: "check-log xxx" mackerel_agent_plugins: httpd: "mackerel-plugin-accesslog xxx" 監視、チェック設定（Group Variables） 30
- 31. © DMM.com Group ホスト毎設定（Host Variables） mackerel_agent_display_name : "prd-3dprint-appfront-0" mackerel_agent_display_name : "prd-3dprint-batch-0" ... 31
- 32. © DMM.com Group • 狙った構成がサクッと⼊った • 楽だった • 気持ちもよかった 32 Ansibleでのエージェント設定
- 33. © DMM.com Group 監視設定の管理 • Jenkinsから”mkr monitor push” • 設定のJSONはGit管理 • 各種メトリクス監視、URL外形監視 • Web上で設定をお試しすること多し • チャンネル設定は⼿設定 33
- 34. © DMM.com Group 34 email CI状況等を含む汎⽤通知Channel - CheckLogは現状ここ ⾼い感受性が必要な通知Channel サービス・通知レベル毎にチャンネル設定 CRITICAL系通知 WARNING系通知 必要な通知を 必要なところで
- 35. © DMM.com Group その他の活⽤構成 • デプロイ時にアノテーション付け • 取りあえずしている • 何か取る様なサービスメトリクスがあるか？ • 検討中 • …… • …… • など、活⽤拡充中 35
- 37. © DMM.com Group 『楽』な監視構成 • 想定通りに平易に監視を構成できた • つまづくところがほぼなし • エージェントの設定 • プラグインの利⽤ • 監視設定 • ドキュメントが分かりやすかった 37
- 38. © DMM.com Group 『楽しく』監視構成 • 何をすればどうなるかがわかりやすい • やってみて、反映されるまでが早い • 現状上がっているアラート対応していく改善サイクル 38
- 39. © DMM.com Group 当たり前の気づき • 何はともあれAWSへ移⾏した • 結果、リソースが有り余っている……! 業務時間中だけRDSのCPUが80% !? • など、チューニングしていくためのネタ • 移⾏作業中、Check-Logでの通知が⼤量に • アプリケーションの不備に対処できた • 移⾏後も継続中ですが…… • これらの『あたり前の価値』を得られた 39
- 40. © DMM.com Group アプリケーションエンジニアの気づき • 通知時のグラフでぱっと⾒てやばさを知る • サービス、ロールによるサーバ郡の分類 • 明らかに異常なリソース消費しているインスタンスの特定ができた • アプリケーションエンジニアでも異常がわかる • Monitors設定はオンプレベースでまだまだ試⾏中 40
- 42. © DMM.com Group サービスとの距離が近い • フィードバックを送ってみたことがある • 即⽇返事をいただいた • さらに要望した機能のリリース時にもご連絡いただいた • これこそDevOps！ • Customer Reliability Engineerすごい • 今回含め、各種イベントへ参加 • 噂のまかないランチにもお呼びいただいた • イベントでプラグイン作成 • FBを積極的に聞いていく姿勢を⾒習いたい 42
- 43. © DMM.com Group その他の価値 • 何かしたらアノテーションを付与 • しておけば後から何か⾒えるかも？ • …… • …… • など、試⾏中 43
- 45. © DMM.com Group まとめ • 必要⼗分・当たり前の監視を⾏えている • VM、ミドルウェア、アプリケーション、それぞれの正常性 • アプリケーションエンジニアでも出来ている感 • 監視設定は試⾏途上 • 導⼊が『楽』で、運⽤が『楽しい』 • 結果、監視結果を受けてのカイゼンサイクルができつつある 45