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

Transcript

1. 1 スタートアップとSaaS Kaizen Platform, Inc. Engineer Yoshiaki Sudo 2016/5/12
2. 2 注意: 本日私からは技術的なお話は ほぼありません…
3. 3 honzit - 私とkaizenの紹介 - スタートアップとSaaS - Kaizenのインフラ監視 - KaizenとMackerel - まとめ
4. 4 Intro
5. Yoshiaki Sudo Internet Backbone Router 6年 Infrastructure 11年 AD tech 2年 Management 少々
6. 6 Kaizen Platform Kaizen Platform
8. 8 Kaizen infraで大事にしていること ➔ 楽をしよう ➔ code化しよう ➔ ビジネスに寄与するインフラであろう ➔ 仲間/家族を大切にしよう
9. 9 スタートアップとSaaS
10. 10 スタートアップとSaaS よくあるパターン 1. インフラ担当者がいない。App Engと兼務している 2. なんとなく動いているが、詳細がよくわからない 3. そもそもモニタリングされてない 4. インフラ担当としてJoinしたが、インフラ以外の仕事のほう が多い 5. インフラ = 何でも屋　という暗黙の了解がある…
11. 11 スタートアップとSaaS とにかくなんでもやらないといけないのがスタートアップ それが醍醐味でもあるんですが … だったら楽しよう。人手をかけずにシステムに任せよう ↓ SaaSを最大限活用してみよう いろんなSaaS触れて楽しそうだ …! ワーイ
13. 13 監視システム http://blog.glidenote. com/blog/2014/12/03/monit oring-system-version-dec- 2014/
14. 14 infra的構成管理 https://speakerdeck. com/mdoi/kai-fa- suruyouniyun-yong- suruinhura-jaws-days- 2015
15. 15 KaizenとMackerel
16. 16 なぜMackerel? 2014年2月 「サーバのリソースモニタリングちゃんとしないとね」 DATADOGにしよう！Sensuも並行して使ってみよう いろいろストをしてみよう と思ったら 2014/5月 !!! Mackerel 爆誕 !!!
17. 17 なぜMackerel? Mackerel作ったから使ってみてよ いいよー。試してみるわ。 須藤くんよろしく はーい
18. 18 採用時のMackerel 試してはみたが…… ぶっちゃけ採用は相当悩みました…… できたばかりのプロダクトで機能が圧倒的に不足していた 田中さんの熱意とロードマップを聞いて、期待も込めて採用 結果素晴らしいプロダクトに成長している
19. 19 Mackerelにしてよかったこと カスタマーに寄り添った開発 リクエストすれば、ロードマップに盛り込んでくれたり 使い勝手どうですか？とインタビューしてくれたり twitterで愚痴ると、丁寧に教えてくれたり
20. 20 Mackerelの使い方 AWS, GCPでインフラのほぼ全てを構成 Kaizenは、物理的サーバを一台も保有していません Web web api batch Service Role Role Role Log front back batch Service Role Role Role
21. 21 Mackerelの使い方 EC2以外のモニタリングは、Service Metricにて収集 ELB, RDS, Elasticache, DynamoDB, etc… fluent-plugin-cloudwatch/fluent-plugin-mackerel 一台収集サーバを用意している アラート通知はH/WリソースとService Metricで実施 ミドルウェアや混みいった監視は sensuやNewRelicで実施
22. 22 Mackerel ちょっと変わった使い方 AWSの請求情報を収集しています Service Metricとして登録したいので、 fluent-plugin-mackerelで収集 コンポーネント別と、 Total Amountをとっている このデータを元にインフラで使っているお金の管理を実施 経営陣にもこのデータを伝えて費用管理に生かしている AWS consoleをわざわざ見に行かなくて良い /AWS IAM渡したくない人にも共有できる インフラの定例会議でもメンバーで眺めてチェックしている あれ増えすぎじゃない？ もうちょっとリッチに使ってもいいかもね？
23. 23 SaaSを多様して見えてきたこと
24. 24 SaaSを多様して見えてきたこと - Pros - 最小人数でインフラを回せる 人が少ない場合が多いスタートアップに有効でした（弊社の場合 ) システムメンテナンス対応がなくて楽 脆弱性対策とかとかとか ………… - Cons - 最初の学習コストが高い 管理が煩雑になりがち しっかりサービスの一覧管理とか、費用管理とかしている
25. 25 現状
26. 26 規模 - インスタンス - About 150 instance EC2, RDS, DynamoDB, etc - インフラエンジニア - 現在2名 Max人員の時で3名 - 負荷 - 適切なワークライフバランスが実現できている たのしく健康に働けるのが何より大事
27. 27 SaaS(mackerel)を使って楽しよう
28. 28 楽してなにをする？ インフラを “kaizen” しよう 通常監視、運用はできるだけシステムに任せる レガシーなコードを取り除いたり、システムの陳腐化を防ぐために新しいことを試したり プロダクトを “kaizen” しよう インフラチーム怖い …　相談しにくい…　インフラチーム忙しそうで声かけにくい …　これは負のスパイラル 時間を多く使ってフレンドリーに相談に乗る。インフラ側から出向いて相談する 社内の困ってる事案を “kaizen” しよう インフラエンジニアは技術の幅が広い傾向にある その技術を使って社内 ITやったり、社内セキュリティを担当したり、 お助けプログラム書いたり
29. 29 餅は餅屋へ SaaS = プロフェッショナル お金をとってサービスしているプロに任せちゃおう 片手間でやるよりプロへお願いする メンテナンスコストからの解放 監視サーバがパニックした … 負荷が大きくて表示が遅い …増設しないと… あんな機能が欲しい = リクエストすれば叶う? 自分の時間を使わずとも機能が増えていく可能性
30. 30 まとめ
31. 31 まとめ スタートアップにこそSaaS 人が足りないからできない！ではなく、足りないなりに効率を最大化しよう 本質的なことに時間を使おう インフラエンジニアだって会社の発展に直接貢献したい !!! より良いインフラを作るために時間をたくさん使いたい SaaSを選ぶ時はエンジニアフレンドリーなものを 大事なところを任せるわけなので選定は大事 困った時にどうにかできるものを (OSSで提供されてるなど )
32. 32 おまけ
33. 33 WE ARE HIRING! https://kaizenplatform.com/hiring/engineer.html
34. 34 THANK YOU!