Herokuの料金体系改定について
本題に入る前に、５月上旬に発表されたHerokuの料金体系の改定について触れておきます。
5月７日のHerokuのブログにおいて、2015年6月以降、Herokuの料金体系が大きく改定されることがアナウンスされました。
現在、原稿の料金体系で運用しているアプリケーションのWebコンソールにアクセスすると「This app uses Traditional dynos」というメッセージが表示され、新しい料金体系への変更が促されます。
新しい料金体系では以下の5つのプランがあります。
- Free
- Hobby
- Standard 1X
- Standard 2X
- Performance
それぞれのプランの詳細はこちらの表にまとまっています。以前に比べると、かなりシンプルで分かりやすくなっているのではないでしょうか。改定内容を簡単にまとめると、
- Dyno Hourベースの料金体系からDynoサイズに基づく月額固定料金となった
- 無償プランでは1日6時間（以上）のスリープが必須になった
- 趣味で運用するようなアプリケーションのために、7米ドル／月のHobbyプランが新設された
- 一部の機能が完全にStandardプラン以上での提供となった
という感じです。
個人で無償枠を利用してサービスを運用していた人にとっては、7米ドルのコストがかかるようになったのは痛いかもしれませんが、複数Dynoを利用してサービスを運用していた人にとっては、むしろ値下げとなっています[1]。
[1] 以前は750時間の無償枠があったので必ず安くなるわけではありませんが。
Herokuアプリケーションからログを出力する
それでは本題のログについて、話を始めましょう。
まず、Heroku上で動くアプリケーションからどのようにしてログを出力すればよいかというと、これは単純に標準出力に文字列を出力するだけです。Javaなら「System.out.println」、Rubyなら「puts」だけでもOKです（もちろん、何らかのLoggerクラスを使用したほうがよいですが）。
一般にオンプレミス、あるいはIaaS上のクラウドサーバ上でアプリを実行する場合には、ログはファイルに出力するように設定することが多いと思います。しかし、Herokuの場合、ファイル出力を指定すると、逆にDyno再起動のタイミングでそれまでに記録したログが消えてう点に注意が必要です。
Herokuのログ集約エンジン「Logplex」
こうして出力されたログは「Logplex」というログの収集エンジンによって集約されます。例えば、Dynoを2台で運用している場合、それぞれのDynoが別々にログを出力しますが、Logplexはこれらを集約してくれます。そのおかげでユーザは、あたかも1つのアプリケーションサーバがログを出力したかのように統合された形でログを見ることができます[2]。
また、Logplexが集約するログ情報には、ユーザが自分で出力した情報だけでなく、次のようなHeroku自身が出力するログも含まれます。
- Heroku Router
- Slug Compiler
Heroku Routerからのログ出力には、以下の情報が含まれます。
- method - HTTP Method（GET/POST/DELETEなど）
- path - Path
- host - Hostヘッダの値
- fwd - クライアントIP
- requestId - リクエストID（アプリケーションにリクエスト転送される際にX-Request-IDとして設定される）
- dyno - リクエストを処理したDynoのナンバー
- connect - Dynoへの接続に要した時間（ミリ秒）
- service - Dyno接続からレスポンスを受け取るまでに要した時間（ミリ秒）
- status - HTTPステータスコード
- bytes - HTTPボディサイズ
一般的なWebアプリケーションが必要とするアクセスログ情報は概ね含まれていると思いますが、特にservice時間が出力されるのがうれしいところです。service時間は、パフォーマンス調整をする際の重要な手掛かりとなります。
[2] そのログがどのDynoから出力されたログであるかは、ログの属性情報として出力されます。
