はじめまして 株式会社リンクです。Mackerelはじめました。 / Mackerel Day #2 2019.12.23 登壇資料(株式会社リンク)

Mackerel Day #2 (2019.12.23開催)での、株式会社リンク様のご登壇資料です。

Transcript

1. ✕ はじめまして 株式会社リンクです。 Mackerelはじめました。
2. 2 本⽇お話しすること Part . MSPの変化とMackerel採⽤のなぜ？ Part . Mackerelをどうつかう？
3. 3 ⾃⼰紹介 ‧⼭本 誠⼀郎（やまもと せいいちろう） ‧1976年⽣まれ 43歳 ‧2児（3歳男と6歳男）の⽗ ‧株式会社リンク サポート部 部⻑  （ワンスタッド株式会社 代表取締役） 【経歴】 派遣会社のCMが湯⽔のように流れた2000年、抗うことなく派遣会社に⼊社し、 ⼊社1週間で国営の電話会社に派遣され社会⼈⼀年⽬がはじまる。 都会派サラリーマンを⽬指すが、2ヶ⽉後にはスーツを脱がされ 、作業着でLANケーブルの作成‧ 敷設、ネットワーク機器の設定や設置、障害対応で⾛り回る毎⽇ 2004年にMSP（マネージド‧サービス‧プロバイダ）へ転職し、運⽤のノウハウをに⾒つけ、 仕事の厳しさ‧楽しさ‧⾯⽩さを感じる。 SIerやコンサルなどの経験を積み、2014年に株式会社リンクに⼊社し、ベアメタルクラウドの⽴ち上げ に関わる。 気づいたらインフラに関わり続けて20年‧‧‧‧
4. 4 株式会社リンクって？ ೥݄೔૑ۀ ɹࠓ೥Ͱ ظ໨ͷاۀͰ͢ɻ
   *5ΠϯϑϥࣄۀΛϕʔεͱͨ͠෯޿͍*5αʔϏεΛఏڙ͍ͯ͠·͢ɻ 1996年に富⼭に本社を構えるエーティーワークスとの協業で専⽤サーバサービスをスタート。 ピーク時の運⽤対象サーバは2万台を超える。 2006年にスタートしたクラウド型テレフォニーサービス。 導⼊社数1,200‧稼働席数24,000を突破し、3年連続シェアNo. を達成したクラウド型CTI「BIZTEL」。 「PCI DSS Ready Cloud」は、クレジットカードの会員情報を安全に取り扱うことを⽬的として策定された、クレジット カード業界の世界的なセキュリティ基準「PCIDSS」に準拠するために必要なリソースをクラウド上で提供するサービス。 岩⼿県岩泉町で、1年を通して⼭に⽜を放牧する⾃然放牧酪農の牧場を運営しています。 2014年から物理サーバをベースとしたクラウドサービス「リンクベアメタルクラウド」をスタート 物理サーバの安定した性能と仮想サーバの⼿軽さを併せ持つサーバサービス。
5. 5 2000年頃のサイトって？ 2000年頃のホームページはこんな感じでした クライアント側の回線も細かったため、画像も少ない クリック→表⽰待ち→クリック→表⽰待ち→‧‧‧
6. 6 2000年前後のMSPって？ データセンタにサーバを設置する考えが⼀般的：⾃社で監視 SMBでホームページなどの⽤途でホスティング：ホスティング業者で監視 監視ツールは今と⽐べると⾮常に⾼価だったため、監視サービスの利⽤料も⾼額 ▪監視（1OS)  万円 ▪DCオンサイト 5万〜10万円 1台 10万円前後 監視サービスの⽐較も ‧監視項⽬の種類 ‧監視項⽬の数 運⽤を提供する側は ‧24時間体制の監視ルームはあったが、アラートメール/監視 マップ/警⼦ちゃんをトリガーにエンジニアへエスカレーション ‧エンジニアは肌⾝離さず⾮常に重いPCを持ち歩き対応
7. 7 ワンオペ＆１⼈24時間365⽇もチラホラ（経営者にとっては 都合の良い？）時代 とはいえ、時代が時代ですから緩い⼀⾯も… お客様との飲み会後、⾒送られたその⾜でデータセンタへ帰 宅していた（良い）時代 酔っ払いながらDCに⼊館しても守衛の⽅からは「お疲れさま です。⼤変ですね〜」と声を掛けられていた（良い？）時代
8. 8 MSPシステムの変化 システムを監視する⽅法は ①商⽤ツールにて⾃社で監視 ②OSSを組み合わせて⾃社で監視 ③ホスティング業者で監視 ①はツールのコストが⾼く、体制維持も⼤変 ②は開発コストが⾼く、品質維持は難しく、体制維持も⼤変 ③はシンプルに⾼かった システムの監視はお⾦がかかった 最近では‧‧‧ • AWS/Azure/GCPなどのマネージド型インフラの普及 • 運⽤はインフラは事業者へ • 安価に監視サービスの利⽤が可能に
9. 9 クラウドがもたらしたもの .クラウド利⽤の増加 インフラエンジニアメインのシステムから アプリケーションエンジニアメインのシステムへ
10. 10 監視ツールはZやNの旧来の監視ツールが使われており、 アプリケーションエンジニアにとっては”少しだけ”解り⾟いモノ .監視ツールは未だ旧来のツールが多い
11. 11 システム管理者が知りたいのは サーバやネットワークの健全性ではなく、システムの健全性 .もはやインフラは意識していない
12. 12 今からは インフラエンジニアも アプリケーションエンジニアも 利⽤し易く、共有可能な直感的かつ視覚的なツールが必要 .やっぱ、今ドキじゃないとダメっす！
13. 13 だから弊社も はじめました…
14. 14 弊社の監視システム 対象サービス：ベアメタルクラウド 監視サービス：サーバご利⽤中のお客様に以下をご提供 • 標準監視：HW関連/死活/リソース（CPU/メモリ/HDD/Traffic） • 拡張監視：ログ監視/プロセス監視などを始めとするユーザサービスに特化した項⽬ • 障害対応：⼿順書および⼝頭指⽰でのオペレーション実⾏ • 技術⽀援サービス：24時間365⽇エンジニアが直接電話を受け対応 • ミドルウェアの設計/構築/チューニング • 障害対応はもちろん、切り分けや原因調査なども • ユーザ数：400社 • システム系： 500ノード • ユーザ系：2100ノード 監視対象数
15. 15 弊社の監視システム 監視システム構成  ベアメタルクラウド内にnagios manager： 台/nagios worker： 台/nagios proxy： 台/NFS： 台  さくらさんおよびAWSさん上に監視の監視：2台2式 *OUFSOFU OBHJPT
    NBOBHFS º OBHJPT
    XPSLFS º ɾɾɾɾ OBHJPT
    QSPYZ º [BCCJY º ͓٬༷γεςϜ ɾɾɾɾ
16. 16 監視システム維持費⽤ • 物理サーバ：15台 • クラウドサービス：5インスタンス • ラック：1/2 • 管理者：0.5⼈⽉ • 開発費⽤：100万 • 年間保守費⽤：200万 年間3,000万〜4,000万円 参考）監視サービスを含めたポータルシステムを構築した場合は年間1億程度
17. 17 Mackerel採⽤のメリット • 監視システムの縮⼩ • エンジニアリソース縮⼩ • 監視トレンドの調査や検証の効率化 • インシデント管理ツールとの連携 Slack、Chatwork、Reactioなど コストダウン ＆ 効率化 これらのコストを既存サービスの強化や新サービスの開発へ分配し、⾃社の強みを強化‧構築することに集中 • サポートチームの強化 • 運⽤設計チームの強化 • サービス企画チームの強化 年間1,500万円削減
18. 18 しかし、もっとも期待するところは‧‧‧ 私達が監視サービスを提供するために使う多くの時間を、 ルーティーン業務からイノベーティブな 業務に変化させ、新しい価値の創造
19. 19 これからのLINKにご期待ください LINKはAWSを初めとする⼤型クラウド全盛の中、オンプレミスに近いシステムを必要とされる お客さまとエンジニアと直接会話できるサポートを必要とされるお客さまの⼀社⼀社‧⼀⼈ひ とりの声を聞き、エッジの効いたサービスを提供し続けます。 お客さまと同じ⽬線でシステムを守り続けるリンクにご期待ください！
20. 20 続いて 弊社、菱沼よりmackerelの活⽤事例について お話しさせていただきます。
21. 21 mackerelの活⽤事例
22. 22 サービス基盤の監視に を利⽤してみた！ からの移⾏と コンテナの監視！
23. 23 ⾃⼰紹介 [⽒名]   菱沼 憲司（ひしぬま けんじ） [出⾝地]   ⻘森県上北郡おいらせ町（旧百⽯町） [経歴]   SIer：インフラ＆プロジェクトのイロハを勉強   MSP：インフラ運⽤、サービスの重要性を勉強   クラウド：クラウド基盤の開発、サービス企画‧開発を勉強   現在：エバンジェリストから役職者へ（技術部⻑） [趣味（続けていること）]   ゴルフ：⼦供が⽣まれてからは半年に２回くらい   スノーボード：毎シーズン３回程度   ランニング：以前は110キロ⾛ってましたが、最近はサボり気味‧‧‧
24. 24 ⽬次 . 移⾏対象サービス基盤の説明 . Nagiosで監視している内容 . mackerelへ移⾏した結果 . まとめ . 最後に
25. 25 アジェンダ① 移⾏対象サービス基盤の説明
26. 26 ෺ཧαʔό サービス基盤のご紹介 ユーザへ⾼い到達率を実現する「メールリレーサービス」です。 リーズナブル な価格 多機能 ⾼い 到達率 ベアメールの3つの特⻑ 例えば、会員登録時の完了メールや商品購⼊や予約時の確認メールなど、ユーザに確実にメールを届けたい場合にキャリアからのブロックを避け、⾼い到達率でメー ル配信を⾏うことができるようになります。メール配信の設定や配信統計の確認、ログ検索、ログダウンロードまで、お使いのコントロールパネルから⾏うことがで きます（※リンクベアメタルクラウドをお使いでないお客さまでもご利⽤いただけます）。
27. 27 サービス基盤のご紹介 リレーメール配信利⽤例 Gmail docomo KDDI SoftBank ✖ メールが届かない ✖ ブロック Gmail docomo KDDI SoftBank 到達率UP ベアメール IP IP IP リレー配信 複数のIPから配信  同⼀のIPから配信 海外IPから配信 利⽤例 ✓ 会員向けの⾃社商品PR⽤のメール配信 ✓ 会員向けに広告⽤のメール配信 会員向けのメルマガなどで⼤量にメールを配信をする場合、同⼀IPから配 信するとキャリアからブロックされ、配信ができなくなるといったケース があります。 例えば、ECサイトなどの場合、会員向けのメール配信は売上に影響します ので、メールの到達率の向上はサービス運営に重要な要素です。 ⾃社サービス ECサイト メルマガ配信 トランザクション メール → → 開封率‧売上アップ 売上に影響 SMTPサーバ
28. 28 サービス基盤のご紹介 4FOEFS
    &OHJOF 4FOEFS
    &OHJOF ⼤量IPを利⽤して⼤量メールを配信 ※約4000万通/⽉ 4FOEFS
    &OHJOF 4FOEFS
    &OHJOF (MPCBM
    $*%3
    Yେྔ 8FC "1* ಺෦%/4 %PDLFS ίϯςφ /BHJPT
29. 29 サービス基盤のご紹介 4FOEFS
    4FSWFS <6TFS">
    1PTUpY
    $POUBJOFS <6TFS#>
    1PTUpY
    $POUBJOFS <6TFS">
    1PTUpY
    $POUBJOFS <6TFS#>
    1PTUpY
    $POUBJOFS 65.ʢ-#ʣ 6TFS"
    (*1 6TFS#
    (*1 SMTP Auth %PDLFS
    )PTU
     %PDLFS
    )PTU
     SMTP Docker Log syslog転送 プライベートリポジトリ コンテナイメージ保管 コンテナイメージ ダウンロード %PDLFS
    45( <%FW>
    1PTUpY
    $POUBJOFS イメージ アップロード ‧特定処理でしか利⽤しないためVMは不要 ‧リソース削減、コスト削減が最重要課題 ‧単純にリソースを集中できる物理サーバと相 性が良い ίϯςφ࠾༻ͨ͠ཧ༝ ‧Dockerのペストプラクティスをどこまで追求す るか ‧メールシステムのためIPアドレスの存在が必須 ‧Kubernetesなどのクラスタ、運⽤管理は利⽤ しない ‧役割分割、冗⻑化、コンテナデリバリ⾃動 化は独⾃で構築 ߏஙͷϙΠϯτ
30. 30 アジェンダ② Nagiosで監視している内容
31. 31 Nagiosで監視している内容 "-*7&؂ࢹ αʔόͷՔಇঢ়گΛ؂ࢹ
    ɾ1JOH؂ࢹ
    ɾ44)؂ࢹ
    ɾϋʔυ΢ΣΞ؂ࢹ
    ͳͲ ΞϓϦɾϛυϧ΢ΣΞͷՔಇ ঢ়گΛ؂ࢹ
    ɾΞϓϦͷϓϩηε؂ࢹ
    ɾϛυϧ΢ΣΞͷϓϩηε؂ ࢹ
    ɾ5$16%1ϙʔτ؂ࢹ
    ͳͲ 04ͷՔಇঢ়گΛ؂ࢹ
    ɾ$16
    -PBE"WFSBHF
    ɾϝϞϦ࢖༻཰
    ɾσΟεΫ࢖༻཰
    ɾωοτϫʔΫCQT
    ͳͲ ϓϩηεɾϙʔτ
    ؂ࢹ ϦιʔεɾτϥϑΟοΫ
    ؂ࢹ 04ɾΞϓϦͷϩάΛΩʔϫʔ υݕ஌Ͱ؂ࢹ
    ɾγεςϜϩά؂ࢹ
    ɾΞϓϦϩά؂ࢹ
    ͳͲ ϩά؂ࢹ ؂ࢹ࣮૷ͷϙΠϯτ
    ɾΞϥʔτ಺༰Ͱ͋Δఔ౓੾Γ෼͚ग़དྷΔ͜ͱΛॏࢹʂ
32. 32 Nagiosで監視している内容 ֎ܗ؂ࢹ ϓϥάΠϯ؂ࢹ ίϯςφ؂ࢹ ఏڙαʔϏεͱಉ༷ͷܦ࿏͔Β઀ ଓ؂ࢹ
    ɾ֎෦͔Βͷ4.51઀ଓ؂ࢹ
    ɾ֎෦͔Βͷ"1* IUUQT ઀ଓ؂ ࢹ
    ͳͲ /BHJPTϓϥάΠϯɾಠࣗ։ൃϓ ϥάΠϯ؂ࢹ
    ɾ࣌ࠁಉظঢ়ଶͷ؂ࢹ
    ɾ%#
    SFQMJDBUJPO؂ࢹ
    ɾ಺෦%/4ͷ໊લղܾͷ؂ࢹ
    ɾϝʔϧΩϡʔͷ؂ࢹ
    ͳͲ %PDLFSͰಈ͍͍ͯΔίϯςφͷ Քಇঢ়گΛ؂ࢹ
    ɾૄ௨؂ࢹ
    ɾϙʔτ؂ࢹ
    ɾεςʔλε؂ࢹ
    ɾϝτϦοΫ؂ࢹ
    ͳͲ ؂ࢹ࣮૷ͷϙΠϯτ
    ɾΞϥʔτ಺༰Ͱ͋Δఔ౓੾Γ෼͚ग़དྷΔ͜ͱΛॏࢹʂ
33. 33 Nagiosで監視している内容 ಉ͡ػೳͷαʔόΛॏͶ߹ΘͤͨΓɺಠࣗϓϥάΠϯ ͷσʔλΛՄࢹԽͰ͖ͳ͍ʁʁʁ
    αʔϏεͷਖ਼ৗੑΛݟ͑ΔԽ͍ͨ͠ʂ 僕 Nagios担当 /BHJPTͰ΋ग़དྷͳ͘͸ͳ͍͕ɺಛ ʹάϥϑ෦෼ͷ࡞ΓࠐΈ͕େมɻ
    ͔͠΋ɺྔ͕ଟ͍ͱ݁ߏαʔόෛՙ΋͔͔Δ ͔΋ɻɻɻ ͦ͏͔ͬ͢ɻɻɻ
    ΋Ͳ͔͍͠ͳ͊ɻɻɻ /BHJPTͷ՝୊
34. 34 Nagiosで監視している内容 ίϯςφ௥Ճͨ࣌͠ʹɺ౎౓؂ࢹઃఆ Λґཔͯ͠ΔΜͰ͕͢ɺखؒ΋ଟ͍ͷͰࣗಈ Խ͍ͨ͠ΜͰ͕͢ɻɻɻ 僕 Nagios担当 ࣗಈԽ෦෼͸࡞Γࠐ·ͳ͍ͱμϝͩ ͔Βɺ࣌ؒ͋Δ࣌ʹ࡞ΓࠐΉΑɻ ͦɺͦ͏ͬ͢ΑͶ͐ʙ ͋ͱɺίϯςφ͝ͱͷϦιʔε΍ॏͶ ߹ΘͤͰՄࢹԽ΋͍ͨ͠ΜͰ͕͢ʂ ΋ͬͱେม͔ͩΒʂʂʂ /BHJPTͷ՝୊
35. 36 アジェンダ③ mackerelへ移⾏した結果
36. 37 mackerelへ移⾏した結果 感 動 (; . ;)
37. 38 mackerelへ移⾏した結果 同じ機能のサーバのCPU負荷を重ね合わせて可視化したい！
38. 39 mackerelへ移⾏した結果 サービスの正常性を分析するために作り込んだ独⾃プラグインも可視化したい！
39. 40 mackerelへ移⾏した結果 【CPU監視】 【メモリ監視】 Docker コンテナごとの リソースみたい！ しかも、コンテナ増減で⾃動で 更新されてる！！！
40. 42 mackerelへ移⾏した結果 ※注意 当然ですが、mackerel だから何でも出来るわけではないです。 ‧mackerelでもデータを渡すための作り込みは必要 ‧UIですべて設定できるわけではなく、エージェント側で設定する内容も多い ‧コンテナ監視は可視化はできるけど、ALIVE系の監視は作り込まないとダメ
41. 43 アジェンダ④ まとめ
42. 44 ෺ཧαʔό まとめ アラートで可能な限り切り分けで きるように作り込んだ監視 データを集めて可視化し分析 グラフ化したいもの、できるものはもちろん、そ れ以外も基本はmackerelへ移⾏！ ALIVE監視、ハードウェア監視は 既存Nagiosのままオンプレミス運⽤！
43. 45 最後に！ サービスの正常性を維持するために、通常と異なったメールキューの滞留出た場合に気づきたい！ mackerelの「ロール内異常検知」であれば実現可能！？ 【メールキュー監視】 【ロール内異常検知】
44. 46 最後に！ ͱ͍͏͜ͱͰɺʮϩʔϧ಺ҟৗݕ஌ʯͰ ΍Ζ͏ͱ͓΋͏ΜͰ͕͢ग़དྷ·͢ΑͶʂʁ 僕 はてな社 エンジニア様 γεςϜϝτϦοΫͳΒ ग़དྷ·͢Αʂ Μʁ
    ࡞ΓࠐΜͩΧελϜϝτϦοΫͩͱʁ ·ͩग़དྷͳ͍Ͱ͢ɻɻɻ
45. 48 ͝੩ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠
    CBSFNFUBMKQ
    CBSFNBJMKQ
    CBSFTVQQPSUKQ