Mackerelの技術の全て。これまでの道のりと更なる発展に向けて

JTF 2016

Jul 24th, 2016

Profile

songmu

id: Songmu (ソンムー/松木)
Masayuki Matsuki
おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/
趣味はCPANizeです
最近はGoばっか書いてる
はてな東京オフィスチーフエンジニア
Mackerelディレクター

経歴

2004 中国でIT起業に関わる
- 中国語/Java
2005 語学学校
- 営業兼・システム/Web担当
- レッスン予約システム
- ASP/ColdFusion/Windows Server
2009 印刷系SIer
- 金融系のとあるシステム
- Webキャンペーン
- PHP/Legacy perl/Java/VB(.NET)?/組み込みBasic
2011 カヤック
- Perl/Ruby/Node.JS
2014 はてな
- Mackerel
- Go/Scala/Perl

インフラを意識してコードを書くということ

http://developer.hatenastaff.com/entry/2016/05/30/080000
インフラ・ミドルウェアアーキテクチャを含めたアプリケーション構築が好き
Webサービスは運用しながら育てていくもの

私とPerl

Perlが好き
CPANモジュールを65個くらい上げている
- 日本で7番目くらい
rebuildfmの宮川さんは235個なので格が違う

私とISUCON

ISUCON 3度優勝 (fujiwara組)
- ISUCON1, ISUCON2, ISUCON5
今年は出題やります

私とGo

最近はもっぱらGo

最近Goで作ったもの

ニッチなツールを作るのが趣味

https://github.com/Songmu/horenso
- バッチジョブのためのラッパ
https://github.com/Songmu/ghch
- githubの履歴から
https://github.com/Songmu/make2help
- Makefileからヘルプ的なのを作る
https://github.com/Songmu/ghg
- GitHub Releasesから実行ファイルを取得する君

https://mackerel.io/
サーバー管理・監視ツール as a Service
前身: はてなの社内ツール
管理対象のサーバーから送信するメトリクスを集計
- モニタリングとアラート通知
- グラフによる可視化
監視サーバー不要で利用登録から3分でサーバー監視開始

可視化

アラート

最大1ロール2554台!

これはちょっと格が違う例
- 本来のユースケースからは外れ値的に逸脱している
はてなでも最大1ロール数百台

100週連続リリース

100週連続リリースの裏側

毎週火・木が定期リリース
機能として出せるものを告知している
以前は当たり前のように毎週出せていた
いつしかチームとしてのコミットメントに

なぜサーバー監視・監視SaaSなのか

ツールのクラウド化の流れ

社内メールサーバー → Gmail
メール送信サーバー → Sendgrid
社内svn/gitサーバー → GitHub
社内Jenkins → TravisCI/CircleCI
オンプレ → Cloud/PaaS

ビジネスの本質に集中するため

社内監視サーバー → Mackerel

監視システムを自前で持つことの割の合わなさ
- 小規模でも大規模でも割に合わない
カオスになりがち

技術の進化への追随

新しい概念への追随
- クラウド
- コンテナ
- microservices
外部サービスとの連携
- AWS
- Slack
- Github
サーバー管理・監視ツール自体も進化し続ける必要がある
- SaaSであれば自動的に機能追加
UI/UX

モニタリングの重要性の向上

すべてのサービスで健全性と一般的な監視関連のメトリックを同じように出力することをおすすめします。(中略) どれを選んでも、標準化するようにしてください。

やっていくしかない(みたいなことが書いてある)
Webサービスへの要求の向上
シビアなビジネス要件
リアルタイム性

Mackerelの開発について

開発体制

人員体制
- プロダクトマネージャーチーム 3人
- エンジニア4人
- デザイナー2人
- インフラ1人
- セールス3人
  - 先週1人入社！
スクラム(のような開発フロー)を採用
- 2週間スプリント

アーキテクチャ

オンプレ
push型監視

技術スタック

ユーザー画面はAngularJS + TypeScript

Mackerel開発における言語多様性

Scala
Go
JavaScript
Perl
Ruby
python
面白がってたくさん採用しているわけではない!(多分)
適材適所に言語を選択する

MackerelとScala

サーバーサイドに Play Framework を採用

Why Scala?

表現力の高い静的型システム
記述の柔軟さ簡潔さ
世の中でのWeb開発の事例
- TwitterとかNetflixなどの超ビッグプレイヤー
Java資産を含む豊富なライブラリ
ミッションクリティカルなサービスなのでかっちりした言語を使いたい
社内で関数型書きたい人たちがいた
- リードエンジニアは本当はHaskell使いたかったらしい

Scalaの使いドコロ

大きめのものをかっちり作るのに向いている
- 型があるし、Option型を使うことでNullを避けられる
はてなブックマークのリニューアルもコア部分はScala

MackerelとGo

事例1: mackerel-agent

OSS: https://github.com/mackerelio/mackerel-agent
ユーザーのホストにインストールする常駐プロセス
メトリック収集とHTTP APIを叩いてサーバーの状態やメトリックを送信

Why Go?

シングルバイナリが吐けるのでセットアップが簡単
マルチプラットフォーム対応が比較的容易
- OSX/Windowsでも動作可能
常駐プロセスを書くことに向いている
フットプリントが小さく監視対象のサーバーのパフォーマンスに影響を及ぼさない
- 実際去年のISUCONでインストールしていたが全くスコアに影響せず

事例2: mkr

Mackerel操作のためのコマンドラインツール

事例3: URL外形監視ワーカー

URL外形監視用のジョブキューシステム
通信はHTTP
- HTTP APIでジョブを受付
- 結果の通知もHTTPで行う
ジョブキューにはRedisを利用
外部URLへのクローリング
AWSインテグレーションも同様のアーキテクチャ

外形監視ワーカーのアーキテクチャ

OSS副産物

Perlのモジュールの思想を受け継いだものが結構できた

github.com/Songmu/timeout
- GNU coreutilsのtimeoutの移植
- 外部プロセスのタイムアウト処理
github.com/Songmu/retry
- リトライ処理
- Sub::Retryの移植
github.com/Songmu/prompter
- コマンドラインでプロンプトを出す
- ターミナルにつながってない場合に処理がブロックされない
- cgoを使っていない
github.com/hakobe/paranoidhttp
- プライベートネットワークへのアクセスを禁止するHTTPクライアント実装
- LWPx::ParanoidHandlerの移植
- hakobe++

Go本体への貢献

特定のカーネルオプションが向こうになっている環境でGoが即死する問題を修正。

Golangを書いてみて

型がありつつコンパイルが速いので嬉しい
実装をちょっと書いて、テストをちょっと書いて、テストを回してのLL的なリズムで書ける
それでいて高速なバイナリができるのが嬉しい
並行・並列処理が言語組み込み
- goroutine/channel楽しい
文字列処理、リスト処理はLLに比べると気持ちよくない
- とは言えあのレイヤの言語でSliceは良くできている
- 素朴にやればなんでもできる

Goの使いドコロ

コマンドラインツール
microservices的なアーキテクチャを実現するコンポーネント
- ミドルウェア
- サブシステム
- 機能の少ないAPIサーバー
大きすぎるものも思想的にマッチしなさそう
書捨てみたいなのにはそこまで向いてない(個人的印象)
- 1ツール1リポジトリが基本になる

MackerelにおけるPerl

事例: mackerel-agentのリリースの自動化
ベターシェルスクリプト
標準モジュール縛りで使う

自動化機構の罠

自動化機構は属人的になり負債になりやすい
肥大化する独自シェルスクリプト/Rakefile/Makefile
ブラックボックス化/メンテ不能
それどうやってテストするの？

ツールをテストする

面白機構
- 実行 % perl tool/releng
- テスト実行 % prove tool/releng
一枚のPerlスクリプトの中にテストも書かれてる
- ドキュメントとテストコードつきのPerlスクリプトを書く方法
- $ENV{HARNESS_ACTIVE}を見て分岐

ちゃんとテストを書けるのは安心

if (!$ENV{HARNESS_ACTIVE}) {
    main();
} else {
    # When called via `prove`, tests will run.
    run_tests();
}

Perlの使いドコロ

プロジェクトの渋い脇役としても活きる

だいたいどこでも入っている
ベターシェルスクリプトとしての汎用性の高さ
- awk/sedの環境差異に悩まされるよりPerl使ったほうが良いことも多い
自動化スクリプトにテストを同梱する
- 自動化がブラックボックス・メンテ不能になるのを避ける
検証サーバーをplackupでさくっと立てる
テキスト操作
検証スクリプトの作成

MackerelにおけるRuby

事例1: fluent-plugin-mackerel

3つのgem
Mackerelのサービスメトリック投稿に利用
- HRForecastのようなAPIによる数値投稿・グラフ描画
fluentdは便利
何らかのデータストリームに対して集計をおこないそれをMackerelに投稿させる
集計処理や再送制御などを任せられる

その他Ruby事例

cookbook-mackerel-agent
- https://github.com/mackerelio/cookbook-mackerel-agent
- Chef cookbook
- はてなでも利用
Capistrano
- はてなは各チーム横断でdeployには Capistrano を利用
git-pr-release
- https://github.com/motemen/git-pr-release

Rubyの使いドコロ

fluentdやChefなどのエコシステムに乗っかる
手元で使うツール作成

Mackerelにおけるpython

Graphite

Python製の時系列データベース
- Mackerelを支える時系列データベース技術
これを活用しつつ、最近は結構Contributeしている

Graphiteの構成

Carbon (twisted daemon)
- シンプルなtcpテキストプロトコル
- % echo "local.random.diceroll 4 $(date +%s)" | nc localhost 2003
whisper (tsdb file)
Webapp (Django)
- JSON
- ブラウザでグラフ表示(あまり使われない)