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

60b23ea19504c9ec936a1d8e9ee35f8d?s=47 yoshiaki sudo
May 12, 2016
4.2k

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

60b23ea19504c9ec936a1d8e9ee35f8d?s=128

yoshiaki sudo

May 12, 2016
Tweet

Transcript

  1. 4.
  2. 7.
  3. 10.

    10 スタートアップとSaaS よくあるパターン 1. インフラ担当者がいない。App Engと兼務している 2. なんとなく動いているが、詳細がよくわからない 3. そもそもモニタリングされてない

    4. インフラ担当としてJoinしたが、インフラ以外の仕事のほう が多い 5. インフラ = 何でも屋 という暗黙の了解がある…
  4. 12.

    12

  5. 21.

    21 Mackerelの使い方 EC2以外のモニタリングは、Service Metricにて収集 ELB, RDS, Elasticache, DynamoDB, etc… fluent-plugin-cloudwatch/fluent-plugin-mackerel

    一台収集サーバを用意している アラート通知はH/WリソースとService Metricで実施 ミドルウェアや混みいった監視は sensuやNewRelicで実施
  6. 22.

    22 Mackerel ちょっと変わった使い方 AWSの請求情報を収集しています Service Metricとして登録したいので、 fluent-plugin-mackerelで収集 コンポーネント別と、 Total Amountをとっている

    このデータを元にインフラで使っているお金の管理を実施 経営陣にもこのデータを伝えて費用管理に生かしている AWS consoleをわざわざ見に行かなくて良い /AWS IAM渡したくない人にも共有できる インフラの定例会議でもメンバーで眺めてチェックしている あれ増えすぎじゃない? もうちょっとリッチに使ってもいいかもね?
  7. 25.
  8. 26.

    26 規模 - インスタンス - About 150 instance EC2, RDS,

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

    28 楽してなにをする? インフラを “kaizen” しよう 通常監視、運用はできるだけシステムに任せる レガシーなコードを取り除いたり、システムの陳腐化を防ぐために新しいことを試したり プロダクトを “kaizen” しよう

    インフラチーム怖い … 相談しにくい… インフラチーム忙しそうで声かけにくい … これは負のスパイラル 時間を多く使ってフレンドリーに相談に乗る。インフラ側から出向いて相談する 社内の困ってる事案を “kaizen” しよう インフラエンジニアは技術の幅が広い傾向にある その技術を使って社内 ITやったり、社内セキュリティを担当したり、 お助けプログラム書いたり
  10. 29.

    29 餅は餅屋へ SaaS = プロフェッショナル お金をとってサービスしているプロに任せちゃおう 片手間でやるよりプロへお願いする メンテナンスコストからの解放 監視サーバがパニックした …

    負荷が大きくて表示が遅い …増設しないと… あんな機能が欲しい = リクエストすれば叶う? 自分の時間を使わずとも機能が増えていく可能性