Mackerel meetup #7 スタートアップとSaaS

by yoshiaki sudo

Slide 1

Slide 1 text

1 スタートアップとSaaS Kaizen Platform, Inc. Engineer Yoshiaki Sudo 2016/5/12

Slide 2

Slide 2 text

2 注意: 本日私からは技術的なお話はほぼありません…

Slide 3

Slide 3 text

3 honzit - 私とkaizenの紹介 - スタートアップとSaaS - Kaizenのインフラ監視 - KaizenとMackerel - まとめ

Slide 4

Slide 4 text

4 Intro

Slide 5

Slide 5 text

Yoshiaki Sudo Internet Backbone Router 6年 Infrastructure 11年 AD tech 2年 Management 少々

Slide 6

Slide 6 text

6 Kaizen Platform Kaizen Platform

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

8 Kaizen infraで大事にしていること ➔ 楽をしよう ➔ code化しよう ➔ ビジネスに寄与するインフラであろう ➔ 仲間/家族を大切にしよう

Slide 9

Slide 9 text

9 スタートアップとSaaS

Slide 10

Slide 10 text

10 スタートアップとSaaS よくあるパターン 1. インフラ担当者がいない。App Engと兼務している 2. なんとなく動いているが、詳細がよくわからない 3. そもそもモニタリングされてない 4. インフラ担当としてJoinしたが、インフラ以外の仕事のほうが多い 5. インフラ = 何でも屋　という暗黙の了解がある…

Slide 11

Slide 11 text

11 スタートアップとSaaS とにかくなんでもやらないといけないのがスタートアップそれが醍醐味でもあるんですが … だったら楽しよう。人手をかけずにシステムに任せよう ↓ SaaSを最大限活用してみよういろんなSaaS触れて楽しそうだ …! ワーイ

Slide 12

Slide 12 text

Slide 13

Slide 13 text

13 監視システム http://blog.glidenote. com/blog/2014/12/03/monit oring-system-version-dec- 2014/

Slide 14

Slide 14 text

14 infra的構成管理 https://speakerdeck. com/mdoi/kai-fa- suruyouniyun-yong- suruinhura-jaws-days- 2015

Slide 15

Slide 15 text

15 KaizenとMackerel

Slide 16

Slide 16 text

16 なぜMackerel? 2014年2月「サーバのリソースモニタリングちゃんとしないとね」 DATADOGにしよう！Sensuも並行して使ってみよういろいろストをしてみようと思ったら 2014/5月 !!! Mackerel 爆誕 !!!

Slide 17

Slide 17 text

17 なぜMackerel? Mackerel作ったから使ってみてよいいよー。試してみるわ。須藤くんよろしくはーい

Slide 18

Slide 18 text

18 採用時のMackerel 試してはみたが…… ぶっちゃけ採用は相当悩みました…… できたばかりのプロダクトで機能が圧倒的に不足していた田中さんの熱意とロードマップを聞いて、期待も込めて採用結果素晴らしいプロダクトに成長している

Slide 19

Slide 19 text

19 Mackerelにしてよかったことカスタマーに寄り添った開発リクエストすれば、ロードマップに盛り込んでくれたり使い勝手どうですか？とインタビューしてくれたり twitterで愚痴ると、丁寧に教えてくれたり

Slide 20

Slide 20 text

20 Mackerelの使い方 AWS, GCPでインフラのほぼ全てを構成 Kaizenは、物理的サーバを一台も保有していません Web web api batch Service Role Role Role Log front back batch Service Role Role Role

Slide 21

Slide 21 text

21 Mackerelの使い方 EC2以外のモニタリングは、Service Metricにて収集 ELB, RDS, Elasticache, DynamoDB, etc… fluent-plugin-cloudwatch/fluent-plugin-mackerel 一台収集サーバを用意しているアラート通知はH/WリソースとService Metricで実施ミドルウェアや混みいった監視は sensuやNewRelicで実施

Slide 22

Slide 22 text

22 Mackerel ちょっと変わった使い方 AWSの請求情報を収集しています Service Metricとして登録したいので、 fluent-plugin-mackerelで収集コンポーネント別と、 Total Amountをとっているこのデータを元にインフラで使っているお金の管理を実施経営陣にもこのデータを伝えて費用管理に生かしている AWS consoleをわざわざ見に行かなくて良い /AWS IAM渡したくない人にも共有できるインフラの定例会議でもメンバーで眺めてチェックしているあれ増えすぎじゃない？もうちょっとリッチに使ってもいいかもね？

Slide 23

Slide 23 text

23 SaaSを多様して見えてきたこと

Slide 24

Slide 24 text

24 SaaSを多様して見えてきたこと - Pros - 最小人数でインフラを回せる人が少ない場合が多いスタートアップに有効でした（弊社の場合 ) システムメンテナンス対応がなくて楽脆弱性対策とかとかとか ………… - Cons - 最初の学習コストが高い管理が煩雑になりがちしっかりサービスの一覧管理とか、費用管理とかしている

Slide 25

Slide 25 text

25 現状

Slide 26

Slide 26 text

26 規模 - インスタンス - About 150 instance EC2, RDS, DynamoDB, etc - インフラエンジニア - 現在2名 Max人員の時で3名 - 負荷 - 適切なワークライフバランスが実現できているたのしく健康に働けるのが何より大事

Slide 27

Slide 27 text

27 SaaS(mackerel)を使って楽しよう

Slide 28

Slide 28 text

28 楽してなにをする？インフラを “kaizen” しよう通常監視、運用はできるだけシステムに任せるレガシーなコードを取り除いたり、システムの陳腐化を防ぐために新しいことを試したりプロダクトを “kaizen” しようインフラチーム怖い …　相談しにくい…　インフラチーム忙しそうで声かけにくい …　これは負のスパイラル時間を多く使ってフレンドリーに相談に乗る。インフラ側から出向いて相談する社内の困ってる事案を “kaizen” しようインフラエンジニアは技術の幅が広い傾向にあるその技術を使って社内 ITやったり、社内セキュリティを担当したり、お助けプログラム書いたり

Slide 29

Slide 29 text

29 餅は餅屋へ SaaS = プロフェッショナルお金をとってサービスしているプロに任せちゃおう片手間でやるよりプロへお願いするメンテナンスコストからの解放監視サーバがパニックした … 負荷が大きくて表示が遅い …増設しないと… あんな機能が欲しい = リクエストすれば叶う? 自分の時間を使わずとも機能が増えていく可能性

Slide 30

Slide 30 text

30 まとめ

Slide 31

Slide 31 text

31 まとめスタートアップにこそSaaS 人が足りないからできない！ではなく、足りないなりに効率を最大化しよう本質的なことに時間を使おうインフラエンジニアだって会社の発展に直接貢献したい !!! より良いインフラを作るために時間をたくさん使いたい SaaSを選ぶ時はエンジニアフレンドリーなものを大事なところを任せるわけなので選定は大事困った時にどうにかできるものを (OSSで提供されてるなど )