【freee × プレイド】Tech Meetup 〜インフラ監視編〜
を支えるインフラ監視【freee × プレイド】Tech Meetup
View Slide
#plaidtech
話すこと● freee で使っている監視系サービス● 少人数で運用するためのノウハウ
話さないこと● 監視の基本的なこと● 各監視サービスの比較や使い方
自己紹介Twitter / GitHub@manabusakai
自己紹介● 坂井 学(さかい まなぶ)● 2016 年にインフラエンジニアとして入社● Scala / Ruby / PHP を書いてました● 得意分野は AWS○ AWS 認定ソリューションアーキテクト - プロフェッショナル○ AWS 認定 DevOps エンジニア - プロフェッショナル
スモールビジネスに携わる方がより創造的な活動にフォーカスできるよう
freee が提供するサービス● 会計 freee● 給与計算 freee● 会社設立 freee● マイナンバー管理 freee● 開業 freee
freee が提供するサービス
freee で使っている監視系サービス
● サーバー監視○ Mackerel ○ CloudWatch ○ Prometheus ● パフォーマンス監視○ New Relic ○ MONyog ● トラッキング○ Redash ○ Kibana
それぞれの守備範囲AWS サーバ アプリ データベースMackerel ◯ ◯ ◯CloudWatch ◯Prometheus ◯New Relic ◯MONyog ◯
インフラエンジニアは何人いますか?
3 / 80 人
1 人あたり20 万事業所
効率化しないと回らない!
少人数で運用するために工夫していること
① 情報はプルよりプッシュ必要な情報は一か所にプッシュされる仕組みを作る。● Slack に通知しているもの○ Mackerel からのアラート○ GitHub など外部サービスの障害情報○ アプリケーションのパフォーマンスサマリー○ AWS のコスト○ Qiita:Team の新着記事
① 情報はプルよりプッシュ
② フルマネージドサービスの活用AWS のフルマネージドサービスを活用して、監視するポイントを根本から減らす。● トレードオフとの兼ね合い○ 運用が楽になる ⇔ ブラックボックスが増える○ ノーメンテナンス ⇔ 障害が起きたら手が出せない○ 設定が簡単 ⇔ 痒いところに手が届かない
③ 障害が起きることを前提に障害が起きることを前提にインフラを設計する。● 例えば○ サーバは Auto Scaling で管理し可用性を担保する○ 単一障害点を作り出さない○ リトライを前提としたコードを書く○ etc...
③ 障害が起きることを前提に“障害を避ける最もよい方法は、常に障害を起こすことである”
④ 本業にフォーカスするサービスをより良くすることにフォーカスする。それ以外の部分はお金で解決するのもアリ。● Zabbix から Mackerel へ移行○ 結果的には Mackerel のコストは充分ペイした○ Mackerel Meetup #8 Tokyo (2016/10/17) で発表■ ref. Zabbix から Mackerel へ - Mackerel で実現したコストダウン
④ 本業にフォーカスする
⑤ トラッキングして見える化数値をトラッキングして見える化する。● 数値は嘘をつかない○ 曖昧さを排除できる○ 数値を元に改善サイクルを回す
⑤ トラッキングして見える化様々なメトリクスをトラッキングして、見える化
まとめ
まとめfreee はごく普通の監視サービスを使っていますが、工夫することで少人数を実現しています。1. 情報はプルよりプッシュ2. フルマネージドサービスの活用3. 障害が起きることを前提に4. 本業にフォーカスする5. トラッキングして見える化
エンジニア募集中
最後に宣伝今年から個人事業主として開業しました。● AWS の導入支援● AWS アーキテクチャのコンサルティングなどをやっています。興味を持った方は、気軽にお声がけください