サーバーレスアーキテクチャなエラートラッキングツール faultline

本エントリーは Serverless Advent Calendar 2016 - QiitaFusic Advent Calendar 2016 - Qiita の7日目の記事です。

今日は AWS re:Invent 2016 Serverless Follow Up がありますね。うらやましい。

サーバーレスアーキテクチャなエラートラッキングツール faultline を作っています。

logo

これは何

AWSのマネージドサービスのみで構築しているサーバーレスアーキテクチャなエラートラッキングツールです。

近いツールとしては、RollbarAirbrakeBugsnagerrbit などがあります。

エラートラッキングのためのAPIバックエンドを提供する faultline と、そのAPIを利用するWeb UIのサンプル実装の faultline-webui があります。

github.com

github.com

Web UI

機能

エラー管理をする上で、最低限の機能を実装しています。

  • エラートラッキング
    • 総数
    • 時間単位総数
    • エラー概要
    • 解決済かどうかのステータス
  • 通知
    • Slackのチャンネルへ通知
    • GitHub Issueへ登録
  • 通知間隔の設定
    • 最初は通知
    • 時間単位総数上限を超えた場合に再通知
    • n回ごとに再通知

なぜ作ったのか

アプリケーションエラーの管理が大変問題

作ったアプリケーションでエラーやExceptionなどがあった場合、 https://github.com/fusic/encounthttps://github.com/k1LoW/Exception を使ってメール通知をしています。

そして、「全てのエラーのメール通知が飛んできてツラい」とか、「どのエラーの解決が終わっているのかの管理ができなくてツラい」とか、よくある問題に遭遇しています(今)。

というわけでなんとかしたいと思っていました。

有償サービスのエラートラッキングツール

多くの有償サービスがあるのですぐにでも使いたいと思っているのですが、いざ会社で導入するとなったとき以下の点でちょっと躊躇しています。

  • どれくらいの費用対効果があるか検証できていない
  • 会社の業務の特性上、1年間だけをみても無数のプロジェクトが立ち上がり、さらにそこから運用フェーズになってアプリケーションとしては残るので、プロジェクト単位の課金だとツラい

正直、健全な方向としては有償サービスを使うべきだとは思っています。(採用するとしたらプロジェクト課金やユーザ課金でない Rollbar かも)

オープンソースのエラートラッキングツール

オープンソースで公開されているerrbitやSentry(OSS)も考えましたが、「サーバーの管理」という別の大きなコストがかかるので、勇気をもって選択できそうになかったです。

サーバーレスアーキテクチャのエラートラッキングツール

欲しい機能としては、

  • 同じエラーをある程度まとめて通知する機能(Slack通知だけでもいい)
  • エラーごとの概要を後から確認できる機能(簡単な時系列のグラフ表示とか)

だけがあればいいかなと思っていて、これにさらに「(ほぼ)管理レス」という無茶要件があったのですが、「もしかしてサーバーレスアーキテクチャで作れるのでは?」と思って試行錯誤してたらできました。

最近v1になったServerless Frameworkを採用することで、AWS Lambdaを中心にS3やDynamoDBも含めて管理できて、少ないコマンドでデプロイできる形に収めることができました。

まずは、サーバーレスなfaultlineの導入をすすめて、もしこれ以上の機能が必要になったら(それは、おそらく効果がでたのだから)、faultlineの拡張をするか、有償サービスを提案しようと思っています。

使い方

faultlineの使い方です。

faultline のデプロイ

まずエラートラッキングをするAPIバックエンドを構築するために falutline をデプロイします。

$ git clone https://github.com/k1LoW/faultline.git
$ cd faultline
$ npm install
$ (Edit ./config.yml)
$ AWS_PROFILE=XXxxXXX npm run deploy

config.yml は config.default.yml をコピーして修正してください。基本的に、S3のバケット名とAPI Keyを設定すればOKです。

npm run deploy まで実行できたらAPIバックエンドのデプロイは完了です。

デプロイ完了時に、StackOutputs に ServiceEndpoint が出力されるのでコピーしておきます。

テストエラー登録

サンプルエラーをcURLで登録してみます。

エラーの登録先URLは POST /projects/{project}/errors になります。ペイロードのサンプルとして sample-errors.json があるのでそれを利用します。

$ curl -X POST -H "x-api-key: [ここにconfig.ymlのclientApiKeyかapiKeyが入ります]" -H "Content-Type: application/json" -d @sample-errors.json [ここにServiceEndpointが入ります]/projects/sample-project/errors

faultline-webui の立ち上げ

次に、Web UIを立ち上げます。Macならローカルで open コマンドで確認可能です。

$ git clone https://github.com/k1LoW/faultline-webui.git
$ cd faultline-webui
$ (Edit ./config.js)
$ open index.html

config.jsはconfig.example.jsをコピーして修正してください。endpoint に faultline の ServiceEndpoint を、apiKey に faultlineのAPI Keyを記載するだけです。

これでWeb UI上でsample-project というプロジェクトにいくつかエラーが登録されていると思います。

通知

faultlineはエラーを保持するだけではなく、通知機能もあります。

Slack 通知

POSTするデータの notifications に Slackの設定を入れて、エラー登録をすればSlack通知ができます。

slack

GitHub Issue 登録

GitHubのIssue登録もUser Token認証限定ですが可能です。

github

費用

ミニマムで$0.1/monthくらいで運用できると思います。AWSの無料枠が残っていたら無料になるくらいのリソース消費量です。

ただ、トラッキングするエラーの流量によってはDynamoDBのキャパシティユニットを増やさないといけないし、保存されているデータも線形で増えていくのでその限りではありません。

Unlimited ProjectsだしUnlimited Users(そもそもUserという概念はない)なので、気にするべきはエラーの流量だけです。

費用がかかってきたら、有償サービスへの移行を検討すると良いと思います。


以下、いろいろと。

faultlineのコンセプト

faultlineを作るにあたって、作っていきたいものを分かりやすくするために、いくつかコンセプトをかかげています。

Simple deploy

構築までに面倒な作業ができるだけないようにしようとしています。

今のところデプロイまでのコマンドは、AWSのクレデンシャルが設定されていれば、config.ymlの作成を含めて5コマンドです。

できれば、これ以上は増やしたくないと思っています。

Manageless

エラー管理を楽にしようとして、結果サーバー管理をするのは本末転倒なので、ここは是非「サーバー管理レス」でいけるようにしたいです。

そのために、サーバーレスアーキテクチャの範囲(AWSマネージドサービスでできる範囲)から超えることなく実装していこうと思っています。

(もし、サーバー管理が必要な機能がでてきたら、その機能は多分あきらめます。)

POST errors with config

“Manageless” にもつながるのですが、1回デプロイすれば、運用時に追加で何か設定する必要がないようにしたいと考えていて、その1つの方法として、"POST errors with config" というアイデアで構築しています。

例えば「Slackのどのチャンネルに通知したいのか」や「どれくらいの頻度で通知したいのか」などの設定は、普通なら管理画面などで設定しそうなものですが、こういう設定をクライアント側からエラー登録と同時に毎回投げてもらう形にしています。

そうすることで、 faultline はエラートラッキング情報は保持しますが、それ以外にはデータを保持する必要がなくなります。

他に faultline が行うのは、エラー情報取得イベント発火時に設定に沿った通知処理などを実行するだけです。

Between “Only mail notify” and “Error tracking services”

あくまで、「エラーメール通知のみの開発の世界」と「有償のエラートラッキングサービスに任せているの開発の世界」の間を狙っています。

本当の「管理レス」は金の弾丸を使った有償サービスなので。

というわけで

最近のプライベートな開発はもっぱら faultline です(そういった意味でもPHPカンファレンス2016で、今までの興味とツールを話し切れたのは良かった)。

実は ServerlessConf Tokyo 2016 のときには、既にコンセプト実装としてある程度動くものができていていたのですが、見せるきっかけも特になく、結局ここまで時間を見つけてはチマチマと作っていました。

実装は、Serverless Frameworkのバージョンアップや、周辺技術の知見の増大や、ふとした思いつきと共に5回くらい作りなおしています。

(最近聞いている boot.fm で k0kubun さんが話していたツールの実装の流れに近い)

今の自分のServerless Framework力、JavaScript力はこれくらいっぽいです。

是非「エラーメール通知のみの開発の世界」から抜けだしましょう。

k1low/xlsx と同じようにPDFを扱えるPHPライブラリ k1low/pdf を作った

前に作って放置していたのを、ちゃんと整備してCakePHPへの依存性を外してPackagistに登録しておきました。

github.com

k1low/xlsxと同じように、テンプレートになるPDFに文字を書き込んで出力するだけのシンプルなライブラリです。

<?php
use Pdf\Pdf;

$pdf = new Pdf();
$pdf->appendTTFfont('/path/to/ipag.ttf');
    ->read('/path/to/template.pdf')
    ->setValue('あいうえお', ['x' => 10, 'y' => 20])
    ->setValue('6ページ目', ['x' => 10, 'y' => 20, 'page' => 5])
    ->setValue('あいうえお', [
        'x' => 120,
        'y' => 45,
        'width' => 100,
        'height' => 230,
        'fontSize' => 24
    ])
    ->write('/path/to/output.pdf');

TTFフォント以外はcomposerでインストールできるので、導入は楽です。「申込書の出力」などの決まりきったフォーマットの帳票出力には使いやすいかと思います。

こちらからは以上です

PHPカンファレンス2016に参加/発表してきました #phpcon2016

前回エントリに続き、PHPカンファレンスです。

「.ssh/configを管理する .ssh/configで管理する」というタイトルで発表してきました。

発表後の感想

.ssh/configというかなりニッチな話題でしたが、スライドのブクマ数を見る限りは、発表を見ていない人にも少しは興味を持ってもらえたんではないかなーと思いました。(解決方法になるかは別)

komad(仮)も今後も少しずつ考えていきたいなと思います。

PHPカンファレンス(無印)は規模が違った

7年ぶりに同じ開催場所に来たはずなのに、なんというか規模の大きさを感じました。本当にお祭りという感じ。

満席の発表が出たりするのも凄いなーと思うし、数少ないながらも見れた発表は面白かったし、スポンサーブースの充実度も良かったし、ネットワークは安定しているし、CakePHPは投票1番だし、懇親会では、いろいろお世話になっている人とリアルで会えるし、「これがPHPカンファレンスかー」という感じでした。

スタッフのみなさんありがとうございました!参加者、発表者のみなさんお疲れ様でした!

次回も参加できるように頑張っていきたい。

PHPカンファレンスで.ssh/configについて話します #phpcon #phpcon2016

7年振りの参加です。

phpcon.php.gr.jp

PHPは自分の主力言語なわけですが、PHPカンファレンスについては「(出力言語だし)スピーカーになれたら参加する」というオレオレルールを課しています。

そんな他人にはよくわからないルールを課していたら「PHPで話すことがない」ためにずっと参加できずじまいでした。

PHPが主力なのにPHPで話すことがないってどういうことなんですかね・・・)

↑のような楽しみをずっとできずにいました。

募集要項がちょっと違った

そんなわけで毎年PHPカンファレンスで話せるネタを探しては諦めていたのですが、今年PHPカンファレンスの募集要項を確認したら以下のような記述が。

トークのテーマは必ずしもPHPの話である必要はありません。JavaScriptの話、HTMLの話、開発環境の話、チームビルディングの話などなど、PHPエンジニアが聞いて面白ければ何でもOKです。

「これはPHPカンファレンス福岡と同じだ!」ということで、さっそくずっとどこかで喋りたかったことを応募しました。

.ssh/configを管理する。.ssh/configで管理する

様々なプロジェクトに関わっていると、自然と様々なサーバへのSSH(公開鍵認証)が必要になり、.ssh/configの管理も必要になります。これを管理する1つの方法、また、逆に .ssh/configを利用してサーバ情報などを管理しようとしている取り組みについて紹介します。

今年のPHPカンファレンスのテーマは"NEXT"ということです。

Docker界隈などで「SSHをしたら負け」と言われはじめている昨今の状況からすると、.ssh/configの話はあまり似つかわしくないかもしれません(言い訳をすると応募当初、今年のテーマを知りませんでした)。

ただ様々な事情からSSHを多用するエンジニアの方は(自分を含め)いますし、これからも .ssh/config と向き合っていく必要性はあると思います。

ただ、「普通に .ssh/configをホームディレクトリに置いてSSHだけをしている」方に、ちょっとだけ"NEXT"に行ってもらえるような話ができればと思います。

ちなみに本当の"NEXT"は多分もっと先か、別な方向なので、サイセンタンな方には物足りないかもしれません。

キーワード

  • .ssh/config
  • サーバ管理

PHPTokyoTyrantの組み合わせについてLTした以来のPHPカンファレンスでの発表!楽しみです! (はい!「TyokyoTyrant懐かしいなー」とか思ったアナタ!是非声かけてください!)

ところで

PHPカンファレンス(本家)が言語の制約を取っ払ったのは今年からですかね?

自分みたいなニッチなことにしかコミットしない(それ以外は普通な)エンジニアにはとてもありがたいです。

少なくとも応募できるのが嬉しい。

buildersconにも応募したかった人生だった。。。

Backlog Favicon ChangerをNew UIに対応させました

nulab-inc.com

というわけで、いつもお世話になっているBacklogにNew UIがやってきました。

ただ、残念ながら今回のアップデートでもファビコンは各プロジェクトのアイコンを反映するものではなかったので、「これはまたBacklog Favicon Changerの出番かな」と思ったらHTMLが変わった結果、見事に動かなくなりました。

というわけでNew UIに対応しました(v0.2.0)(Chromeウェブストアへの反映待ちです)。

chrome.google.com

というわけでニッチですがご利用下さい。

JAWS Festa 東海道2016でawspecとかAWSの構成テストとかについて話します

登壇者応募をして採択されたので今週末名古屋に遠征します。

楽しみです。

jft2016.jaws-ug.jp

AWSをテスト(?)

タイトルは「Inside of awspec -AWSをテストする方法。そしてその中のはなし-」ということなのですが、 25分という時間なので、内容的には、JAWS-UG福岡:3度目の濃い目にAWSの話をしてみよう - JAWS-UG九州 | Doorkeeper で喋った若干濃い内容を時間に合わせてぎゅぎゅっと濃縮して短くしたうえで、「AWSのリソース構成のテスト(?)」について思うことをしゃべろうと思います。

awspecのメンテナンスをしていると、いろいろなPull Requestを国内外からいただきます。本当にありがたいです。

そのPRから垣間見える「テストツール作ってくせにお前わかっていないな!ここをテストしたいんだよ!」という思いとかは、実際にPRをマージしている自分が紹介すると面白いかなーと思っています。

会社の元名古屋在住の同僚に20,000円オーバーの寿司屋の紹介をされて戸惑っているので、もう少しリーズナブルなところで美味しくご飯を食べたいです。

ぼっちだと思うので是非声かけて下さい!

Developers Summit 2016 FUKUOKAで発表してきました

発表してきました

思い起こせば10年たっていた

どうやら勤続10年目に突入していました。 実は、会社の全体合宿でサプライズで祝ってもらったことで気づきました。

気づいたら入社10年目。会社のツートップからのサプライズプレゼント。一生モノ。頑張ります。 #work10thyears

10年かー

と思いつつ、ちょうどいいので10年を振り返る形で、Fusicがどのように生き延びてこれたのかについて考えた結果を発表しました。

実際は正直わからない

ぶっちゃけたはなし、

いちエンジニアの想像ですし、全ては結果論でしかないので合っているかどうかはわからないです。

ただ、最後の結論について同意してくれる人が思いのほか多く、「もしかしたら間違っていないかも」とも思ったり。

こういうイベントで、ツートップが喋ったら面白いと思うんですけどねー。聞いてみたい。

というわけで

良い機会をいただきありがとうございました。