Heroku free よ、さようなら

ども、@kimihom です。

今年の9月末、アプリ開発者にとって大きなニュースがHeroku から届いきました。

blog.heroku.com

Heroku 無料プランの終了です。

かつて誰もが作ったWebアプリをHerokuへアップし、「私がこれ作りました！」とTwitterでURLシェアし、すごいと思われた時代を思い出します。一番最初、私が大学生の時に作ったアプリはHerokuで動いていました。Heroku が無料であり続けていた最近まで、初心者Webアプリ開発者が、「Herokuでアプリを上げました」 ツイートを何度も見てきました。その役割が終わろうとしている今、少し寂しさを感じます。そうした初心者向けの無料サーバーのサービスは他にも探せばあるので、そちらに移っていくことでしょう。

Heroku は、本気でWebアプリを管理運用していくエンタープライズ向けに焦点を当てるようになったと言えます。

これは私としてはとてもいいニュースでした。なぜなら、ビジネスとして本気でHerokuを使っている(料金を支払っている) 私たちへのサポートに、より力を入れてもらえるようになるためです。

かつては無料で使っている大量ユーザーのサポートに時間をかけたことは安易に想像できます。初心者で初めてHerokuデプロイしてみた初心者プログラマの質問に、対応したりする必要があったでしょう。それにどれだけの時間をかけたことでしょうか。

しかし、初心者プログラマを完全に切った訳ではありません。最低限のサーバーとデータベースで 毎月$10 を支払えば、今まで通り利用は可能です。$10を毎月かけても、自分のWebサーバーを"Herokuで"運用したいと思えるくらい本気であれば、今後もHerokuを利用できます。なお、私が仕事ではなく個人で運営している「詠みラボ」は最低限のHeroku料金を毎月支払うことで運営してます。

www.yomilab.com

何に時間をかけるか

人それぞれ考え方は違うでしょう。

• 時間や複数契約サービス登録しても、0円で運営する。
• インフラは自前でやらないとダメ。AWS, GCP 以外あり得ない。
• Heroku のままにしよう。

Heroku を選ぶとはどういうことか、私の執筆本に書いております。

www.bokukoko.info

Heroku のままで運営し続けている今では、 Heroku Enterprise というビジネスプランを契約し、より安定したサービス運営を実現しています。それらの内容に関してはこのブログに記しました。

www.bokukoko.info

終わりに

Heroku free の終了に関して、色々な反応がありました。私としてはポジティブに、より良い Heroku 環境の実現に必要なことだったかと思ってます。

Heroku ありがとう、これからもよろしくお願いします。

私がHeroになるための決断です。

Heroku CI の導入と得られた結果

ども、@kimihom です。

この記事は、Heroku Advent Calendar 2021 の 18日目の記事です。ぜひ他の記事も読んでみていただければと思う。

今回は、つい最近 Heroku CI や Pipeline を導入したこと、そしてセキュリティ事情 について記す。

導入前の開発環境

今まで開発効率のテクニックが流行ってるのを聞き流し、目の前の個人開発に没頭してきた。一人でひたすら develop ブランチへプッシュ。STG へは手動デプロイ。最後リリースする時に master(main) へプルリクエストを出して、そのフェーズでの全体コードを一通り確認したら、 master へマージ。この開発体制ならなら以下の開発環境で十分だった。

• テストはローカル環境で実行
• git push origin develop で Bitbucket へプッシュ
• STG 環境へも 手動で git push staging develop:master
• プルリクエストからのマージ
• 本番へも git push production master

当時、プライベートなGit環境は有料だった GitHub を導入する必要性を感じず、Trello のついでに 無料で使える Bitbucket のプライベートリポジトリを長い間使い続けてきた。Bitbucket と Heroku の 2つの場所にそれぞれ push する手間はあったけど、その程度だったので問題だと感じていなかった。むしろ、それの方が安心して開発ができた。

きっかけは開発のチーム化

いよいよ開発環境の改善が必要になってきたのは、1人開発から開発チームとして数人のメンバーが加わったことにある。常に私がコマンドを叩かないと Heroku にデプロイできない状態だと、開発効率が下がることになってしまう。

ちょうど、GitHub も無料の範囲内で Private リポジトリを作れるようになっていた。

そこで、まずは以下の流れを基本とすることにした。

• 私自身、開発の際には develop ブランチから feature, bugfix ブランチなどを切って開発
• GitHub へそのブランチでプッシュ。この時点で Heroku CI でのテスト自動実行
• develop へプルリクエストして、問題なければマージ
• develop の変更があった時点で Heroku CI のテスト自動実行
• テスト成功すれば Heroku へ自動デプロイ、失敗すれば停止
• 結果を Slack へ通知

Heroku CI の利用

Heroku CI を使えば 細かな設定はほぼ不要で簡単に上記手順を追加できた。

まず、Staging 環境と Production 環境の Heroku App をそれぞれ Heroku Pipeline に設置する。

次に プロジェクトのルートに app.json を用意して、テストに必要な環境を記す。

{
  "description": "develop でテスト通り次第 Heroku デプロイ",
  "environments": {
    "test": {
      "addons":[ "heroku-postgresql" ],
      "formation": {
          "test": {
            "quantity": 1,
            "size": "standard-1x"
          }
      }
    }
  }
}

Heroku 側で勝手にどのテストをするか見つけてくれるようで、Rspec の場合は特に何も指定せずにテストが始まっていた。上記の app.json で具体的にどのテストをやるかを指定することもできる。 テスト環境でも環境変数が必要になるが、その設定も 通常の Heroku App と同じようにコードからセット or Settings から ブラウザ上でセットできた。

また、テストが通ったら Staging 環境へデプロイの流れも Heroku 側で設定するだけで動作した。

このおかげで、チーム開発での それぞれが書いてもらったコードをしっかりと読んで、コードに対してのやり取りを GitHub 内でできるようになった。

かつての git push staging develop:master のコマンドは不要になった。"develop へマージされたら勝手に Heroku に上がる" とさえ認識しておけば、git push heroku master しなくても勝手に上がることの違和感はすぐになくなった。

最初は "面倒そうだな" と感じていた新しい開発環境が、ここまで簡単にできるとは思わなかった。これこそ、「さすが Heroku」である。

GitHub の恩恵

それだけでも満足だったけど、GitHub を開くと Security 関連で 通知が出ていた。Dependant alerts というものだった。Dependant alerts のおかげで、Ruby の Gem や Node.js の yarn で使っているライブラリにおいて、秘密性、一貫性、可用性を損なう リスクのあるものが自動で通知が来るようになった。それぞれの通知に段階があり、危険なアラートに関してはすぐ対応を求められるようになった。

さらに、GitHub で各種ライブラリに最新版が出た対た時点で1日に1度の Slack 通知が来るようになった。単にプロジェクトのルートディレクトリに、.github ディレクトリを作り、そこにちょろっとファイル名を記載するだけで動作した。このおかげで、今までは一定の周期で 一括で gem アップデートしてテストしてたのを、毎回新しいリリース内容をチェックして、問題なさそうならすぐに最新へ更新というプロセスを踏むことができるようになった。

Log4j

さて、ものすごくタイムリーに、Log4j の脆弱性に関して話題になっている。これの大きな問題は、自分達は Java と全く関係ないプログラミング言語を使っていたとしても、開発で利用しているライブラリやWebサービス側にも気を配る必要があるという点だ。

まずメインの Heroku 。現状の最新は Salesforce 側のこちらで確認できる。Heroku を使っていれば Heroku Addons 提供者側の詳細を調べていく必要がある。それ以外にも、もちろんAWS の各種サービスや Twilio など、それぞれをしっかりとウォッチする必要がある。

障害と似ていて、障害より危険な状態だ。障害は先方が把握をしていて、いつか治るってことがわかる。だから "ひたすら祈る" っていうのが基本だろう。セキュリティに関しても基本は "各種サービスが セキュリティ対応を完了してもらうことをひたすら待つ" ということかもしれない。しかし、いつまでも来ずにスルーされている可能性もある。その場合は こちらから連絡したり、他の外部サービスを探すということが必要になってくる。

今までに経験したことのないような、世界規模での大規模な改修が必要なこの問題。より世界を安全にという意味で、今後こうしたのは増えていくのだろう。その時に、そのままスルーするのか、我ごととしてしっかりと調査していくのか。これが次世代のセキュリティ対応に必要になってくるのかもしれない。

終わりに

おっと、そもそも今回の記事は Heroku CI の話だった。ありがとう Heroku そして GitHub。この両者の密接な連携によって、チーム開発をより効果的に実施できるようになったと肌で感じることができた。

そして "今" まさに問題となっている Log4j 問題。しっかりと各種連携先まで調査し、対応が必要なら対応する。その姿勢を忘れずに過ごしていこう。Heroku ユーザーの間で、各種アドオンの最新情報を共有していければ幸いである。

恐れるな。さぁ立ち向かっていこう！

Heroku での npm バージョンの違いによるデプロイ失敗メモ

ども、@kimihom です。

急に Heroku での Node.js アプリのデプロイが失敗したので、その原因と(一次)対応について記しておく。

問題

いつも通り、git push heroku master でデプロイしたところ、以下のようなエラーが発生するようになった。

remote: -----> Installing binaries
remote:        engines.node (package.json):  15.x
remote:        engines.npm (package.json):   unspecified (use default)
remote:
remote:        Resolving node version 15.x...
remote:        Downloading and installing node 15.14.0...
remote:        Using default npm version: 7.7.6
remote:
remote: -----> Restoring cache
remote:        Cached directories were not restored due to a change in version of node, npm, yarn or stack
remote:        Module installation may take longer for this build
remote:
remote: -----> Installing dependencies
remote:        Installing node modules (package.json)
remote:        npm ERR! code ERESOLVE
remote:        npm ERR! ERESOLVE unable to resolve dependency tree
remote:        npm ERR!
remote:        npm ERR! While resolving: undefined@undefined
remote:        npm ERR! Found: bootstrap@3.4.1
remote:        npm ERR! node_modules/bootstrap
remote:        npm ERR!   bootstrap@"^3.3.7" from the root project

根本は bootstrap のバージョン指定? が定義されていない(undefined)ことのようだ。しかし、今まで問題なくデプロイできたのに、急にできなくなったのはなんでだろう？

対応

その答えが、npm のデフォルトバージョンが 7 に上がった ということだった。npm v7 に上がると、どうやら npm の dependency をインストールする際にバージョンチェックなどが走るようである。

取り急ぎ、すぐに7にあげる必要もまだないだろうし、問題なく動いている node 6 で動かすようにすることで解決できた。そのために、package.json に以下の記述をしている。

  "engines": {
    "node": "15.x",
    "npm": "6.x.x"
  }

これで Heroku にデプロイする際に npm 6 のバージョンでデプロイ準備してくれるため、正しく動くようになった。

Heroku キャッシュで動き続けることが

この問題、キャッシュで npm インストールが残っていたりすると、バージョン7でも問題なくデプロイできたみたいな複雑な問題となることがある。キャッシュの消し方については以下ページに記載があった。

How do I clear the build cache? - Heroku Help

テスト環境では動いたのに、本番で動かない！そんなことが起こらないようにしたいところである。

終わりに

もちろん、最新を追い続けるために、今後は npm 7 系でも問題なくインストールできるよう調整する必要はある。 あくまで一時的な対応方法として、本記事が参考になれば幸いである。

AppSignal でのサービス管理

ども、@kimihom です。

今回、エラー通知やサーバー管理のために AppSignal を導入したので記事としてまとめてみる。日本での事例があまりないようなので、今後増えていけばと思う。

利用サービス選定

まず、メインの目的はバグ管理だった。より見やすく管理しやすいようにすることが必要となり、Heroku にある Addons の中から選ぶことにした。以下のような選択肢があった。最終的には AppSignal, Rollbar, BugSnag の3つが候補となった。

AppSignal 無料プランなし。 有料 ＄12: 7日間,有料 ＄35: 30日 3,000,000 リクエスト。 Ruby. Elixir, NodeJS。 何が遅いかを監視できる。 フロントエンドのエラーも見れる。 コアRubyデベロッパの言及はあったが利用事例は少ない。

Rollbar 無料プランあり。 有料$39. 月30,000件、180日間。 Slack, BitBucket, Trello連携。 エラーが起きた原因をフロントエンドの状態から送る。

BugSnag 無料プラン ok。 Ruby ok。 有料: $29, 60日, ユーザー5。 日本での利用報告多い。

Sentry 無料プラン ok。 Ruby ok。 有料: $29 月50,000件まで, 90日 メンバー制限なし。 bitbucket, trello, slack 連携。 backend, frontend。 rails 専用ではない。gemの細かい設定が必要で複雑な感じがする。

RuntimeError 無料プランなし。 $4.99 のみ。10万件まで。 Github にエラーを直接送る。github 前提か。

Raygun Crash Reporting 無料プラン ok。 Ruby ok。 有料: $9, 90日分のデータ保存 15,000件まで。 UI みた感じ複雑そう。 日本での利用報告なし。

Honeybadger 無料プラン ok。 Ruby ok。 有料 全機能 $149。 日本での利用例ほとんどなし。

Airbrake Error Monitoring 無料プランあり。 $59 で 100,000件、30日間。 Bitbucket, Trello 連携。 国内の記事だとかなり古いがバズった模様。

利用の決断

色々とある中で、私がなぜ AppSignal を選んだか。それは Heroku Addons にとって、最適化どうかの判断が大きかった。 また、バグの管理だけでなく、統括的にサービスを監視できるサービスとして、NewRelic などのパフォーマンス系サービスを別で入れる必要もなく、AppSignal だけで管理できる魅力があった。

AppSignal は現在 Ruby. Elixir, NodeJS の3つだけのサポートとなっている。これが他の言語に色々と手をつけてカオスになっている監視アドオンや、Heroku では監視できないような項目をたくさん管理しているような 管理アドオンが多かったりする中、シンプルで、Ruby をメインに管理している点も良かった。

あと、ロゴも個人的に Heroku と似たシンプルさが好みである。無料から始められないデメリットはある。ただ今回はお金の面では問題ではなかったので採用となっている。

AppSignal ではフロントエンド JavaScript も同様に管理できるようになっている。まだベータ版ではあるけど、バックエンドとうまく連携しながらフロントエンドの監視ができるサービスとして便利に使えるだろう。

AppSignal

では AppSignal ではどんなことができるのか。簡単に調べたことだけ報告する。

Errors エラーが起きた場所や利用ユーザー情報、対象箇所の Git へのリンクなど、エラーの調査に必要な情報が綺麗にまとまっているページ。 エラーが起きた時の通知に、どの頻度で通知するかを設定できる。

Change notification frequency - Every occurrence: 毎回エラー出るたびに通知 - First in deploy: デプロイしてまたエラーが起きた時 - First after close: Close にした後またエラーが起きた時 - Never notify: 通知しない

上記はデフォルト設定の選択となる。エラーが起きるたびに通知をしたとしても、そのエラーごとに通知止めたりすることもできる。AppSignal のデフォルトはこの First in deploy で推奨のようである。デプロイしたことが Heroku から AppSignal へ情報を渡すようにすれば、"デプロイ後"っていう管理も AppSignal 側でうまく動作する。

Performance 遅い処理があった場合にリスト表示される。もちろんそれが何秒以上の時に通知出すのかっていう設定が可能だ。私のサービスの場合、多くの API 呼び出しがあるため、この Performance で処理が1秒以上かかることも1日数回起きてしまうため、設定の秒数を伸ばすで対応するしかないか。

Anomaly detection サービス全体として何か問題が起きた時に通知を出す。下記が基本のようだが、それ以外にもいくつか通知を出す条件が存在する。

• エラーの発生率が20%を超えた時
• 平均リクエスト処理時間が500ms 以上かかった時
• Swapが利用され始めた時
• ディスク利用量が90%超えた時 (Heroku 関係なし)

Inspect サービスを改善するための調査ができるページ。通知などは来ず、自分で定期的に見にいく形となる。

• Actions リクエスト処理の遅い、影響力の高いものリスト
• Slow events フレームワーク別 遅い処理リスト (ActiveRecord, ActionController, net_http など)
• Host usage, Host metrics Heroku ではあまり参考ならないので気にせずでok

Improve SQL と API のアクセスに時間のかかっているものを調べられる。

• Slow queries 遅いSQL文 影響力高い リスト
• Slow API requests 遅いAPI 呼び出し。AWS Lambda や Twilio, PAYJP の API

終わりに

AppSignal を使い始めているが、現在は満足して利用ができている。

こういったサービスは、「みんなが使うから俺も使お」っていう判断は危険かもしれない。自分にとって不要な機能が大量にあって複雑なサービスもたくさんあるからである。

Ruby on Rails の監視管理サービスとして、AppSignal を使ってみたレポートでした。

図解でなっとく！トラブル知らずのシステム設計　エラー制御・排他制御編

Heroku Postgres のアクセスが遅くなった時にした対応

ども、@kimihom です。

先日、Heroku Postgres の Hobby プランを使っていたら、急に DB へのアクセスが遅くなった事象が発生した。その原因と対応について記しておく。

問題の原因

まず、どんなときに遅くなったのかというと、1つのレコードに大量のデータが入ったときだった。それ以降、Heroku Addnons の NewRelic や Scout APM などのアドオンで重たい原因となっている部分を調べたところ、Active Record(DBアクセス) で 90% 以上の時間を費やしていることがわかった。

Postgres のレコードのカラムを text 型で保存し、そのカラムに大量の文字をテストで入れて保存してから、急にデータアクセスが遅くなってしまったのだった。そのデータは、ページロード時に読み込まれるデータであり、とりわけ Heroku Dyno を再起動した直後はまともにアクセスできず、 R12 Error が必ず発生してしまった。

その後、DB アクセスにキャッシュが入るようになると、それ以降は H12 は起きないものの、レスポンスが遅いことには変わりなかった。

問題の対応

まず、大量に入っているテキストのレコードはどれかを調べ、そのレコードを更新してみた。しかし、一度遅くなってしまったら、アクセスはずっと遅いままだった。

Hobby プランで使っていたのは、テスト環境のサーバーであったため、思い切って 一度 Heroku Postgres のバックアップをとってから削除し、改めて Heroku Postgres を入れることで対応した。

1. バックアップの保存、取得

まず Heroku Postgres のページへ遷移し、Durability から、 Create Manual Backup をクリックし、バックアップを作成する。しばらくすると、それがダウンロードできるようになるので、ダウンロードしてローカルのPCに保存する。

2. S3 など、アクセス可能な場所へ保存

ダウンロードしたバックアップを、S3 など URL でアクセスできるような場所に保存する。その URL を控えておく。

3. Heroku Postgres を再インストール

まず必要に応じて、メンテナンスモードを有効にする。その後、Heroku Postgres を削除する。

$ heroku maintenance:on -a myapp

$ heroku addons:destroy heroku-postgresql:hobby-dev -a myapp

$ heroku addons:create heroku-postgresql:hobby-dev -a myapp

4. バックアップデータを取り込む

先ほどバックアップしたデータを新しく入れた Heroku Postgres に入れる。無事に成功したら、メンテモードを OFF へ。

$ heroku pg:backups:restore 'https://myapp.s3-ap-northeast-1.amazonaws.com/backup' DATABASE_URL -a myapp

$ heroku maintenance:off -a myapp

この作業により、DB へのアクセスが劇的に速くなり、問題を解決できた。S3 にあげたデータの削除をお忘れなく。

終わりに

今回の話は、Heroku Hobby プランで起きた問題であり、より上位プランであれば、そもそも大量のデータが入っても遅くはならなかった(確認済み)。

テスト環境のデータはできる限り安く運用したいだろう。今回のデータベースの削除と再インストールは、そこまで手間ではないので、一度 Heroku Postgres が遅いと感じた場合には大きなデータを削除した後、再インストールを試してみて欲しい。

Heroku Enterprise までの道のりと結果

ども、@kimihom です。

ついにこの記事を書ける日が来たことに喜びを感じる。今回は運営する SaaSを Heroku Enterprise へ移設したので、その道のりと移すことで得られた結果について記す。

Heroku Enterprise 移設のきっかけ

まず、Heroku Enterprise 導入にあたって一番ハードルにあるであろう、「お金面のクリア」が必要なことは正直に記しておこう。今回の場合、移設前と比べて3倍近く金額がかかっている。私自身、長年 Heroku を使い続けてきたコアユーザーではあるが、やはりこの金額面から Heroku Enterpise は最初から "ないな" と思ってしまい、詳しく調査すらしてこなかった。

しかし時は流れ、お陰様で私の運営する SaaS は多くのお客様に利用いただけるようになり、費用をかけてでも更に高性能で信頼性のあるサーバーにしたいという思いが込み上げてくるようになった (一応フォローすると前の状態でも問題ないレベルのサーバー数を確保はしていたけども)。少数精鋭で機能開発にフォーカスする弊社にとって、自前で AWS/GCP で構築するという選択肢は最初からなかった。そのための時間や、インフラエンジニアを採用する必要があるからである。

Heroku Enterprise による利点に関しては Heroku コミュニティで実際に使っている方の話も聞いてきたので、とりわけ悩むこともなく Heroku Enterprise の導入を決めたのだった。

Heroku Enterprise の利点

事前調査の段階で、私が Heroku Enterprise へ移そうと思えた利点について以下にまとめる。

• 東京リージョンのサーバーによる高速化
• 専任の日本語バックエンドサポート
• セキュリティ強化 (プライベートサーバー)
• 安定性の向上 (共用から専用サーバーへ)
• Heroku 及び Salesforce との関係強化

Heroku ユーザーの話を聞いていると、やはり 「US にサーバーがあるからレイテンシが気になる」という声をよく聞く。私としては、そこまでレイテンシの課題を感じていなかったのだけど、それでも US よりは JP にサーバーがあったほうが良いに越したことはないなと思っていた。今回の Enterprise へ移設の決め手となったのは 東京リージョンではなく、それ以外の点にある。

日本語で専任のバックエンドのサポートが付くというのは私にとって大きなメリットだった。同じ金額でインフラエンジニアを雇うよりよっぽど専門知識のある方が必要な時に日本語でサポートしてくれる。またインフラ設計の相談にも乗ってくれる利点がある。今回だと例えば Heroku の Common Runtime から Private Spaces に移設する際の手順書をレビューしていただいた。少数精鋭の開発をやっている私にとっては、このレビューだけで十分で、他の実行は全部私がやれば良いだけなのだ。まさにインフラエンジニアを一人採用したかのような状態である。専門の Heroku サポートの方とやりとりを通じて、今後より安定・安心できるサービス提供を目指していく。

そしてセキュリティや高可用性など、エンタープライズに求められる要素を Heroku Enterprise では提供してくれている。もちろん、私自身もセキュリティや高可用性の勉強は定期的に続けてはいるのだけど、専門家よりは劣ることを認めざるを得ない。もしこれを自前サーバーで本気出してやるのなら、やはりここにも一人採用が必要となってしまう。それよりかは、Heroku の専門のスペシャリストの方にレビューいただき、修正は私の方でやるという体制を作ることもできた。サーバーは良いモノになったし、より安心して使っていただける環境を整えることができた。

「サービス開発」って文脈で Heroku と出会った人には案外知られていないんだけども、Heroku は CRM 大手の Salesforce 社が運営する PaaS である。とはいえもちろん Heroku で好き勝手にサービスを作って良いんだけども、企業とのやり取りのスペシャリストとも言える Salesforce 社が運営しているということもあって、安定・信頼などの部分は他の PaaS, IaaS に比べて大きな利点がある。その意味で SaaS でユーザーが増えてきたら Heroku Enterprise というのはとても理に適ったアップグレードであると考えている。

実際に使ってみて気づいたこと

やはり 実際に使ってみてわかることも出てくるものだ。

とりわけ Heroku Private Spaces リージョンのレイテンシ関係の話は、私のイメージとは異なっていた。一度テストで 東京リージョンでサーバーを立ち上げて、実際にどのくらい速くなるのかを確認してみた。具体的な数値は出してないけど、ランディングページなどは今までも結局 Faslty でキャッシュしてたので、最初のレスポンスだけ多少は速くなったかな? くらいのものだった。それよりむしろランディングページ以外は US にサーバーがあった方が速いことが判明した。これはサービス特性で頻繁に Twilio の REST API を呼ぶことが関係していた。Twilio のサーバー がUS にあるために、Heroku を東京リージョンにすると逆に Twilio API のレスポンスが遅くなるのである。

一般的に、「Heroku Private Spaces で東京リージョンにしてめっちゃ速くなりました！」って報告は、サービス内の外部API 呼び出し先が国内にあるから速くなったということであれば納得できる。

ということで最終的には Heroku Private Spaces のリージョンを US East の Virsinia にすることに決定した。これじゃ Private Spaces にする意味ないじゃん！と思われるかもしれないが、それは違った。

明らかにログイン後の管理画面のレスポンスは速くなっていたのである(リージョンは変わってないのに!)。てことで Heroku のレイテンシ以外に通常の Common Runtime だと Heroku アプリを遅くさせる要因があって、そっちの方が原因として大きいという理解をしている。スピードが速くなる大きな理由の一つとして、 一つの Private Spaces 内に Dyno と Heroku Postgres、Heroku Redis が置かれているから だと考えている。DB や キャッシュのアクセスが確実に速くなっていて、それによってアプリケーション全体のレスポンス速度が上がっている。プライベートな中に DB や キャッシュのサーバーも一緒に入ることで、データへのアクセスがより限定的になってセキュリティ的にも強固になって良いこと尽くしである。だから リージョンは US だとしても、 Heroku Privae Spaces の恩恵は確実に得られている。

終わりに

まだ Heroku Enterprise になってから数日しか経ってないので、より具体的な利点や欠点はこれから感じることになるだろう。移設が終わった現時点では、やはり費用にあった Heroku Enterprise のメリットがあって、その恩恵を受けることができていると感じている。

今回の話はまた時間が経った後に、コミュニティなどでお話しできればと考えている。引き続きガッツリ Heroku を使ってサービス開発に集中していく次第だ。

Heroku の Dyno を時間でスケールさせる方法

ども、@kimihom です。

今回は Heroku の Dyno を時間でスケールさせる実装を自前でしたので共有する。

Heroku の Dyno

Heroku には実行環境の Dyno と呼ばれる単位で管理されている。Web Dyno はもちろん、バックグラウンドで走る Worker Dyno や heroku run console で動く on-off Dyno など色々な種類がある。

んで、大事なのはこの Dyno の単位で Heroku へ課金額が決まるという点だ。例えば負荷のかかるピーク時は 5 Dyno, 夜間などは 2 Dyno などと変えることで、毎月かかる金額を調整することができる。

この点の実装を簡単にしてくれる Heroku Add-ons がいくつか存在する。ページ左のカテゴリより Dynos を選ぶと、その一覧を見ることができる。

大きく分けて、Dyno 管理の Add-ons は、「スケジュール」か「オートスケール」の2つに分類される。スケジュール系の Add-ons は「Process Scheduler」「FlightFormation」、オートスケール系の Add-ons は「Adapt Scale」「Rails Autoscale」がある。なお、Heroku のお高いプランを契約すると、Heroku の提供するオートスケール を利用することも可能だ。

リクエストが急激に増える時間帯を予測できない場合には、「オートスケール」系のアドオンが活躍することだろう。その反対にリクエスト数は大体予測できて、その分、時間帯によってしっかりとサーバー台数を決め打ちで起動させたければ「スケジュール」系の Add-ons が役に立つ。

基本的には上記 Add-ons を使うだけで解決するんだけど、今回は自前で実装することにしたので以下に記す。

スケジュール スケールの自前実装

今回は時間帯による「スケジュール」タイプのスケールを実装したので、それに関して記す。

Heroku の提供する API を使うことで、案外簡単に実装することが可能だ。Ruby の rake タスクとして実装しよう。Application Formation という API を利用する。

Platform API Reference | Heroku Dev Center

# gem 'platform-api'

namespace :heroku do
  desc 'Dyno サイズの変更'
  task :update_dyno_number => :environment do
    # $ heroku plugins:install heroku-cli-oauth
    # $ heroku authorizations:create -d "Platform API example token"
    # => HEROKU_API_TOKEN
    # HEROKU_API_TARGET: heroku app name

    heroku = PlatformAPI.connect_oauth(ENV['HEROKU_API_TOKEN'])

    period = {
      7 => 3,
      8 => 4,
      9 => 5,
      19 => 4,
      21 => 3,
      22 => 2
    }
    dyno_size = period[DateTime.now.hour]

    if dyno_size
      heroku.formation.update(ENV['HEROKU_API_TARGET'], 'web', {quantity: dyno_size})
    end
  end
end

今の時間帯にマッチする Dyno 数が見つかれば、その Dyno 数へアップデートする、というなんとも簡単なプログラムである。実を言うと、これだけでスケールのプログラムが書けてしまう。あとは Heroku Scheduler に 1時間に1回 この処理を実行させれば完了である。

自前で書くと、例えば土日や日本の祝日の Dyno 数を調整したり、月初は増やすとかのイレギュラーパターンも簡単に実装できるってのが利点だ。そのほかに、10分に1回実行にして、何かのリクエスト数に応じて Dyno 数を動的に変えたりするといったことも不可能ではない。

Dyno 数を変える Add-ons にお金を払うくらいなら自前でやってやるという選択も悪くはないだろう。

終わりに

今回は Heroku の Dyno スケールに関して記述した。ここはお金周りの絡むシビアな部分であるので、念入りに設計して実装したいところである。

初めて Heroku の Platfrom API を触ってみたのだけど、さすがは Heroku、よくできている。他にも大量の API が提供されているので、機会があれば見てみよう。

SaaS のアプリストアの可能性

ども、@kimihom です。

今回、Heroku Meetup で Zendesk App について LT してきたので、それに関連して SaaS アプリストアについて記事としてまとめる。

資料

Zendesk App を Heroku で作ってみた話

アプリストア の可能性

BtoC で「アプリを作って公開」ってなると、Android の Google Play か Apple の App Store の2択くらいになるだろう。しかし、BtoB に目を向けると、実は多くの アプリストアが存在する。

• Salesforce App Exchange
• Zendesk Marketplace
• HubSpot マーケットプレイス
• Zoho Marketplace
• Slack App Directory
• Intercom App Store
• kintone アプリストア
• ネクストエンジンアプリ

BtoC は100万DL とか、そういう数字の部分では確かに夢がある。

BtoB のアプリストアの場合、BtoC に比べてインストール数は少なくなるけど、ちゃんと使うってなった時に契約や支払いをした前提であることが大きな違いになるだろう。「無料アプリで広告載せて~」っていう BtoC の戦略とは根本的に異なる。

そして、まだ国内ではこうしたアプリ開発に注力している企業が少ないというのも、大きな特徴としてあるだろう。私は上記のアプリストアのほとんどにアプリを公開しているが、HubSpot や Intercom など最近国内でも話題になってきたサービスでは国産アプリは現状ほとんどない。むしろ私の作ったアプリしかないんじゃないかと思うくらいだが、今後こうしたサービスも発展とともに国産アプリが増えていくことだろう。

んで、BtoB のアプリストアは BtoC と違って作ったものを他のアプリストアにも同様に配布することができるのが大きな特徴だ。 Android で Google Play ストアに公開するには Android 独自で作る必要があって、それがうまく行ったとしても App Store にはまた iOS 独自に作る必要が出てきてしまって大変効率が悪い。BtoB ではそういうことがないのである。つまり、一つ枠組みを作った企業が、これらの BtoB アプリストアのシェアを独占してしまうとも言える。

こうした可能性を感じている企業が今、どんどんとこれらアプリストアへサービスを公開しているという訳だ。

求められる能力

ここで求められる能力は、"API, API, API" である。それぞれの企業が提供する API のドキュメントを読み込み、最適な形としてアプリに落とし込む必要がある。

ほとんどの場合、OAuth 認証で アクセストークンから REST API の JSON レスポンスでアクセスできるので、技術的に困るという部分は少ないだろう。ただ、それぞれのサービスにそれぞれの特徴があるので、それに合わせて微妙に仕様を変えたりといった検討が必要になる。

国内の SaaS は、基本的に REST API だけの提供 (or なし!) で、単に「データ連携させられる」ってだけなんだけど、こうしたアプリストアでは、「そのサービス内で他のサービス(アプリ)を使う」ってとこまでできる。ここが今、海外の SaaS と国内の SaaS の大きな違いの一つだと言えるだろう。

Zendesk App の所感

今回の LT タイトルが Zendesk App なので、Zendesk App に焦点を当ててみよう。

Zendesk App は他の SaaS アプリに比べて、アプリ内でできる幅が大きい。Zendesk App から Zendesk のあらゆる REST API を呼び出すことができるし、Zendesk 内の UI 動作の指定も多種多様である。ただし、その自由さ故なのか審査に1ヶ月以上もかかるというのがネックなポイントだ。

現状 Zendesk App で公開できるのは Zendesk Support と Chat の2つだけのようだ。今 Zendesk は他に多くのサービスを提供し始めていて、今後これらのサービスと統合したアプリ開発環境ってのが出てくるんじゃないかなと思っている。ただ Zendesk といえば「サポート」って印象が染み付いているので、ここで最近「Zendesk Explore」 や 「Zendesk Sell」などが出てきてどうなっていくのかな、という感じではある。今後の Zendesk に注目である。

終わりに

今回は Zendesk App の派生形として、SaaS アプリストアの可能性に関して言及した。

これら SaaS アプリの中に埋め込む場合、URL など気にする必要がない。てことで、 *.herokuapp.com で自由にアプリを作って公開する、そんな SaaS アプリストアでのアプリ公開が一つのトレンドになっていけば面白いなということでこの記事を閉めようと思う。

私はこの世界にお先に足を踏み込んでいる。あなたはこのウェーブに乗るか？

Heroku がもたらす次世代の開発手法

ども、@kimihom です。

この記事は Heroku Advent Calendar 2018 の 24日目の記事です。

heroku Advent Calendar 2018 - Qiita

SWTT 2018 の資料

Salesforce World Tour Tokyo 2018 で Heroku について熱く語らせていただいたので、今回はそのことについて記す。Heroku を知っていて少しくらいは使ったことがあるという方を想定した資料である。

speakerdeck.com

誰もが PaaS で開発できる時代へ。

このセッションで一番いいたかったことは、「Heroku は一部の個人開発者やスタートアップのみで使われている印象が強かったが、今ではどの規模の企業でも利用できるプラットフォームになっている」という点だ。

数年前に Heroku を触ったっきりの方は、ここ数年の Heroku の進化に驚くことだろう。今まで課題として言われていた「柔軟性」「パフォーマンス」「エンタープライズ」の全てをクリアしてきている。Heroku はお遊びで使う PaaS っていうレベルではない。"誰もが" 開発効率や最先端の開発手法などを得ることができる開発者プラットフォームなのだ。

Heroku の進化に気づいた方はどんどん本番環境の運用を Heroku に任せるようになってきている。その方が、自前 IaaS より安定的に稼動できるし、困った時も専門のスペシャリストに調査を依頼することができるのだ。これで私たちが本当にやらなきゃならないこと(顧客に価値を届ける)に集中することができる。

資料にあるように、Heroku の選択によって 私(少人数チーム)+Herokuインフラ という最強チームになる。このチーム構成によって素早くプログラムをデプロイしてバグの少ないシステムを運用することができる。

終わりに

次の時代へようこそ！

私たちデベロッパーが本当に必要なのは顧客に価値を届けることであり、インフラ管理に時間をかけることではない。

いきなり全てのシステムを Heroku に移設することは難しいかもしれないけど、一部だけでも簡単に Heroku へ移設することができる。今もシステム運用に時間をかけてしまっているような開発チームでは、何もしなければ今後ますますそのインフラに時間を取られていくことだろう。そのことにいち早く気づいて頂き、Heroku へ移行していくことを検討していってほしい。

来年は Heroku 出戻り組 が増えることを確信している。一度は Heroku を使ったことがあるけども、自前 IaaS にこだわった結果、その無駄を実感し、Heroku に戻って来る方々のことだ。私も Heroku 出戻り組のうちの一人として、率先して PaaS 化を推進していく次第だ。

「Heroku で成功させるサービス開発」を記事として公開した話

ども、@kimihom です。

先日の技術書典5で販売した「Herokuで成功させるサービス開発」を記事として公開した。

www.bokukoko.info

3万字に近い記事内容になっているので、時間のあるときに気軽に読んでみて欲しい。

この記事は普段ブログを購読いただいている方へのお知らせ目的だけなので、あとは上記リンク先の「Heroku で成功させるサービス開発」をお楽しみいただければ幸いである。

Happy Coding!

技術書典5で初執筆した本を販売した話

ども、@kimihom です。

本日、技術書典5 が開催され、1万人を超える入場者で大いに盛り上がった。今回初めて本を執筆して販売したので、そこで感じたことを記す。

技術書典

販売したモノ

私は Heroku のユーザーグループに関わっており、そこで PaaS 関連で本を出そうという仲間の提案から、ボクココのまとめ的な感じで書くことにした。

booth.pm

以下のような章立ての構成となっている。

• はじめに
• 筆者について
• 技術選定 - どんな時にHerokuを選ぶべきか
• 0→1フェーズでのHeroku
• 1→10フェーズでのHeroku
• Herokuコミュニティ活動
• おわりに

得られたこと、反省点

私の章は、ボクココの記事の中でも特に Heroku とそれに関連したサービス開発の部分をピックアップしたものとなっている。

本の場合、たかだか30ページくらいでも2万５千字以上の文章を書く必要がある。ブログの記事でいえば10記事以上のコンテンツが必要だ。それらを全体の構成を考慮しながら書く必要があるので、普段ブログでたくさん記事を書いていても本を書くのはまた別の難しさがあった。何回も構成を考えて読み直しては修正していくプロセスは、自分の文章力の向上に役立った。実際に本を書くよりも読み直しては修正しての作業の方が時間がかかって大変な作業だった。

普段、ブログではその時点で考えたことや感じたことがベースになっているため、同じようなワードで検索すると似たような記事が出てくることがある。そうした記事を擦り合わせて本として体系化することによって、自分の考えを統一することができた。今まで書いてきた Heroku やサービス開発に関する内容を一つにまとめられたのは良かったことだと思う。

初めて技術書典に参加したわけだが、ここまで多くの方が来場されるイベントだとは思わなかった。開始前で長蛇の列が並び、開始と同時に会場が一斉に満杯になった。ここまで多くの人混みに入ること自体、新鮮だった。みんな新しいことを学んで成長したいっていう思いできてるんだな〜と思うと、もっと自分も勉強して成長しなきゃと感じることができた。一冊だけだけど、売られていた Flexbox に関する本を購入して勉強することにした。

今回は私以外に同じ Heroku コミュニティ繋がりのお二方の記した章と合わせて一つの本にした。てことで買っていただいた方がどの章で買ってくれたのかが気になった。あと実際に試し読みまでして買わないって方もそれなりにいたので、本の執筆もサービス開発と同じようにターゲットを絞って提供することが大事だなと感じた。

"技術"書典で普段書いているような"サービス開発"に関して記したのは、少し技術から外れていたかもしれない。他のブースですごくたくさん売れていた本は、今のトレンドをバッチリ掴んでいて、本の内容もターゲットを絞って細かく解説されたものだった。参加者を見た印象では、技術にかなり関心があって既に一定以上の技術力を持つ方が多いように感じた。そうした方に響くコンテンツを提供するのが大事なのだろう。とはいえ細かすぎると一部の人だけってなっちゃうので、バランスの取れた内容にする必要があるのが本を作る上で難しいところなのかもしれない。

執筆活動の今後

本書の執筆にものすごく時間をかけたので、せっかくなら本を買っていただいた数十名の方以外にも読んでいただけるように公開したいと思っている。どのような形式で公開するかは検討中だけど、いつかまとまった文章として一般公開する予定だ。その際は改めて記事として公表する。かつて Basecamp が Getting Real という無料で読める Web ページを公開したのに似ている(今は ebook化されているようだ)。その記事を公開して愛読者の方が出てきてくれたら、改めて書籍化を検討するというプロセスの方が合っているはずだ。

来年も技術書典は開催されるだろう。私の場合、技術的な観点で言えば Heroku より Twilio のほうがより細かく記事を書けそうな気がした。てことで来年、もし書けそうなら一人で書くか Twilio コミュニティで有志を募ってみても面白いかもしれない。ただ今回の技術書典で本の執筆の大変さがわかったので、来年も確実にやるかといったらまだ50%くらいということにしておいてほしい。

おわりに

技術書典はものすごい盛り上がりを見せる一大イベントだった。いちエンジニア、いちブロガーとしてこのイベントで本を出展できたのはいい経験となった。

読者の方も、年に1回の壮大なアウトプットの場の一つとして、技術書典で本を出すというのを検討してみてはいかがだろうか。もちろんそれで儲かるほど売れるとかは難しいかもしれないけど、そこで体系的に一つのモノとして本を生み出すのは素晴らしい経験になる。

もし来年も本を出版できたら、現地でお会いしよう。

Heroku ログと Webhook を使った応用例

ども、@kimihom です。

先日の Heroku Meetup で、Heroku ログ処理について語ってきた。今回はそれについて語らせてもらう。

speakerdeck.com

Heroku ログ処理の便利さ

実際に自前でサーバー運用していると、当然複数のサーバーがあるわけで、ログはそれら全部のサーバーに吐かれているログを一括管理できる形にしないといけない。ログ収集専用のソフトウェアを各サーバーにインストールしたり、それぞれ定期的に自動で取ってきてどっかに保存するような処理を書いている方もいることだろう。それのインストールや学習、セットアップにどれだけ時間を使わなければならないのだろうか。最終的にやりたいことは、ログを一括で管理して、対象のログが出た時に通知したり、特定のコードを実行させたいといったゴールのはずである。

Heroku の Addon である Papertrail 等を使えば、これらの処理をインストール(heroku addons:add)し、Web 上のインターフェスで簡単に設定するだけで実現できる。手間の排除と、管理が不要になることのメリットは Heroku を利用することの魅力の一つである。

せっかく Heroku を利用するのなら、こうした既に実現された便利なテクノロジーを有効活用すべきだ。自前でサーバー構築して自由自在にできるようになるのと比べて、すぐに使ってすぐに活用できる Heroku のメリットを存分に享受したいところである。

AWS Lambda 上で処理するコード

Heroku じゃなくて Node.js のお話になるけど、補足として以下に記しておく。

本資料に書かれている Node.js のソースコードは、以下のような形となっている。

exports.handler = (event, context, callback) => {
  let body = event.body;
  let log = JSON.parse(require('querystring').parse(body)["payload"]);
  
  log.events.forEach(evt) => {
    // Papertrail 側での文字対応
    let json = JSON.parse(evt.message.replace(/^[^{]*|¥+$/g, ""));

    // Enjoy!
  }
}

ログにマッチして Papertrail から送られてくる Webhook のデータは1行のみとは限らない。例えば、1分間にマッチするログが5件くることもある。そのため、Papertrail からくる Webhook データは配列形式で送られてくることになる。

このサンプルでは、シンプルに forEach を使って回している。このサンプルコードの forEach 内で非同期処理を実装してしまった時点で、AWS Lambda の終了条件である callback を呼ぶことは不可能になる点に注意してほしい。あくまで上記サンプルは、forEach 内で同期処理だけをした場合のサンプルコード である。でもログ処理において、Node.js で非同期じゃない処理だけで終わるなんてケースはほとんどないよね。

てことでもし実践的にやるなら、Promise や async/await、Async などを使う必要がある。Node.js 経験者なら当たり前の話なんだけど、フロントエンドでくらいしか JavaScript を触ったことのない方は確実にはまるので気をつけよう。

例えば、以下のような記事が今回のケースに似ている。 async/awaitを、Array.prototype.forEachで使う際の注意点、という話 - Qiita

上記の記事を読めばわかるとは思うが、forEach での非同期処理ってだけでも Promise や Asnyc/Await だと複雑で読みづらい感じになってしまう。んで、私自身 AWS Lambda x Node.js を使った経験から、ぶっちゃけ今でも Async ライブラリは便利だと思っている。Async ライブラリを使えば、waterfall ってのをつかって配列の関数を定義するだけで実現できてしまう。実際には慣れの問題かもしれないが、コードの読みやすさ的に私は Async が気に入っている。

async.waterfall([
  (next) => {
     // some codes..
     // 第一引数はエラーオブジェクト。以降は次の関数に渡す任意の引数
     next(null, arg1, arg2); 
  }, (arg1, arg2, next) {
    // some codes..
    next();
  }
], (err) => {
  console.log("done!");
  callback(err);
})

終わりに

今回の Meetup では、Heroku を使った新しい活用方法の話だったり、そもそも Heroku の何がいいのかについての話もあった。引き続き、Heroku Meetup は Heroku を使っている方やこれから使おうとする方にとって有益な情報共有の場にしていきたいと思っている。

それでは、また次の Heroku Meetup で。 ciao !

Heroku Meetup で Heroku 運用フェーズについて話してきた

ども、@kimihom です。

今日、Heroku Meetup #20 "Heroku Yacht" が開催されて、そこで登壇した資料と、おまけ的な感じで資料の裏に込められた思いについて記していく。

登壇資料

発表資料の補足

Heroku を使っていても、サービスのフェーズごとに意識して取り組まなければならないことは変わってくる。とりわけ、これからサービスを作る/作ったばかりって状態の人に、運用フェーズの話をしていても全く意味がない。運用の整備する時間があったら、とにかく作ったものを顧客に見せ、反応を見ながら改善していくほうが重要だ。開発初期フェーズでのお話は以下の記事に私の考えを書いているので読んでいただけたら幸いだ。

www.bokukoko.info

それなりにユーザーを抱えるようになってきて、私が特に大事にしてきたのが「フロントエンド」の開発だ。つまり HTML5/JavaScript の活用である。そろそろエンジニアの皆さんは気づいてきたかもしれないが、より早く快適なサービスを実現するのに関して、フロントエンドのウェイトがますます上がってきているというのがある。フロントエンド側のキャッシュや裏で動くWorker などを駆使し、最高のユーザー体験を目指すことが可能だ。

かといって、私は Angular や React などを始めとした SPA フレームワークにはほとんど興味がない。それらライブラリの最新アップデートやバージョンアップに追従したところで、新しくできることなんて何もないのだ。根本である HTML5 を理解し、使いこなせるようになって初めて 今までできなかったことやフロントエンドの高速化を実現できるのである。

私の運営するサービスは、最高のユーザー体験を実現するために HTML5 のテクノロジーを数多く採用している。そしてフロントエンドの開発に注力できるようになったのは、間違いなく Heroku という PaaS の存在のおかげだ。私はバックエンドの心配を、Heroku や各種アドオンのスペシャリストに任せ、そもそも問題が起きにくい設計や運用をしてもらっている。それでも問題が起きれば、サポートもしてくれる。そんな環境は IaaS で自前で構築したら手にできない代物だ。

今回紹介した HTML5 の中で深く言及したのが ContentEditable という技術だ。ContentEditable は、 HTML5 の中でも地味だけどユーザー体験を極めたい人にとっては極めがいのある技術だと思っている。ContentEditable の大きなハードルをくぐり抜けた者だけが、最高のユーザー体験を提供できる。くれぐれも、この技術を初期開発フェーズで採用してはならないということに注意しよう。興味がある場合は以下の記事を参考にしてみてほしい。

拡張テキストエリアを ContentEditable で実現しよう - ボクココ

そして、管理ツールの開発に時間をかけるのは無駄だということも伝えた。そんなのの開発に時間をかけるのではなく、Heroku Dataclips を充実させて、より柔軟なデータ収集の方法(SQL)を、管理ツールを使う人たちに教えたらいいのではないか。この試みに関しては私も道半ばだけど、今作の "誰も SQL が使えるようになるべき"という風潮に乗っかって、 Heroku Dataclips は今後 より重要な立ち位置を示すようになると思う。

私は常日頃からエンジニアは最小限のチームで構成されるべきと説いてきている。この主張はこれからも変わらない。少人数で構成されたドリームチームから生まれたプロダクトは、彼らの溢れ出る思想がプロダクトにそのまま反映される。そんな人が目を輝かせながら語ってくれる発表を聞ける日が来るまで、これからも活動を続けていきたいと思う。

終わりに

今回は参加いただいた方も、自分でサービスを開発しているという気概のあるエンジニアの方が多く、私自身も感化された良い Meetup だった。サービス開発に対して本気になって自分の可能性に挑戦する人のプラットフォームとして、Heroku や Heroku コミュニティが盛り上がっていったら嬉しいなと思う。

Heroku を使って生まれる次の Hero は、そう、 "あなた" である！

Ruby on Rails の魅力と思想

ども、@kimihom です。

私は Web フレームワークは Ruby on Rails を利用している。かれこれバージョン2.2 の頃から使い続けているので 7年以上になる。そこまでして私が Ruby on Rails を使い続ける魅力について個人的な想いを記していく。

Rails の作者 DHH と彼の環境

Rails の作者として有名な DHH(David Heinemeier Hansson) という名前は、 Ruby on Rails を触ったことがあるなら必ずや聞いたことがあるだろう。しかし、彼のいる会社 Basecamp がどんな想いでどんなことをしているかを知っている人は案外少ない。

Basecamp はプロジェクト管理の SaaS である。今や世界中に顧客を抱える超有名サービスであり、Basecamp は Ruby on Rails の最新版をプロダクトに反映され続けている。そしてこの Basecamp という会社は、資金調達をせずに自己資本でサービスを成長させた Bootstrap の事例として最も有名なサービスの一つである。資金調達をせずに、大成功とまで言える領域にたどり着けた背景には Ruby on Rails が深く関わっていることに間違いはない。そして、DHH の想いが Basecamp の成功と Ruby on Rails の思想に深く関わっているはずだ。

Rails は誰のためのフレームワークか？

私が7年以上 Ruby on Rails を触り続けている立場として、以下の考察を記していく。

Ruby on Rails は、極少人数(理想は一人) がサービス開発するのに理想的なフレームワークであり、それを目指し続けていると考えている。Ruby on Rails の敷かれたレールに乗ることで、一気に目的地に到達することができる。

特に大事なのが極少人数で構成されたチームのためのフレームワークであるという点だ。 3人よりは2人がいいし、2人よりは1人で Ruby on Rails を扱うのがいい。関連する人が多ければ多いほど、逆に DB と View が密になっていることで開発効率を悪くさせてしまう。大人数での開発だと Ruby の柔軟な書き方であったり、Ruby on Rails のレールに乗ったプログラムの書き方が、逆にマイナスの側面を与えてしまうだろう。

DHH の会社や思想を理解せずに、単に "Ruby on Rails はみんな使ってるから自社で使う" という判断をすると手痛い思いをする。そして、そんな人が Ruby on Rails 自体を批判するようになる。「Ruby そのものが自由すぎる」だとか、「他人の書いた Rails コードを読みたくない」だとかいう批判をよく聞くけど、そういった声は基本的に5人以上で Rails を触ってしまった場合に起きる問題である。これをしている時点で、私からすれば Rails の思想に乗っ取った開発をしていないのではないかと考える。

Rails は、少人数であり続けられるチームが常に理想の速度で Web アプリケーションを開発・維持するために理想なフレームワークであり続けるだろう。 例えばスタートアップのように人数が急激に増えるような環境においては、必ずや Rails を使っていること自体に問題が発生していくことだろう。この機能を実現するのに Rails のレールから外れなきゃいけないだとか、View と DB が密になり過ぎて担当を分けられないから ActionView を使わないといった選択をするってわけだ。その意味で、5人以上の開発チームで Ruby on Rails を使うのはナンセンスだと考えている。それだけの規模で開発するのであれば、Rails ではなくフロントエンドとバックエンドが最初から疎になっているものを選ぶべきではないか。

ここで一つ大切な事実をお伝えしたいのが、DHH 自体が人を急激に増やしていくスタートアップそのものを否定することが多いということである。これは日本でなぜかあまり知られていない大切な事実である。

Ruby on RailsのDavid Heinemeier Hanssonが語るお金と幸福の関係 - ログミーBiz

にも関わらず、急激に人数を増やしているスタートアップな方が Ruby on Rails を使って、「Rails 辛い」といっているのを見ると、私からすれば滑稽な姿にしか見えないってわけだ。

Rails のホスティングの選択

そんな Rails をホスティングするには、やはり Heroku がおすすめだ。Heroku は Hero + Haiku の造語であることはよく知られている。まさに、「5・7・5 として少ない文字(機能)を磨き続ける人を Hero にする」という考えは、Ruby on Rails の少人数でサービス運営する人の考えと素晴らしくマッチするのである。

今では色々な言語やフレームワークがサポートされているけど、Heroku 初期は Rails のホスティングサービスであったことからも、Rails の思想から生まれたホスティングサービスであることがわかるかと思う。

終わりに

巷では、Rails を使った開発プロジェクトのお話がよく出てくるけど、案外 Rails の作者や Rails の思想について語られることは少ない。

Ruby on Rails の What(何ができるか) よりも、Why (なぜ Rails が存在するか) について深く知る機会があればいいなと思う。Why を知った上で Rails を使えば、本当の意味での Rails のファンになることができよう。

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

Heroku Dataclips を応用したデータ活用

ども、@kimihom です。

Heroku は、Heroku Postgres に対して手軽に SQL を発行してデータ取得できる Dataclips ってのを提供している。今回はその Dataclips をどうやって活用するのか、サンプルとともに紹介する。

前回似たような記事を書いているけど、今回はその発展版的な位置付けだ。

www.bokukoko.info

XLS, CSV, JSON エクスポート

Dataclips には取ってきたデータを簡単にエクスポートすることのできる機能が備わっている。データのエクスポートは、よくあるニーズなんだけど自前で実装するとなるとそれなりにめんどくさいし、実装に時間がかかる。社内向けのツールでデータをエクスポートしたいって場合にはまずは Dataclips の利用を検討しよう。それを知っているだけで、無駄な管理機能を実装する必要がなくなる。

具体的にはどんなケースで使うのかっていうのを以下の２パターンで紹介する。

一部のデータを落として特定のプログラムを一括で実行したい

本来であれば、定期的なジョブなら Heroku Scheduler を使って自動化すべきところなんだけど、イレギュラーなパターンで毎回違う SQL を叩かないといけないってことがサービスを運営しているとよくある。

そんな時は Dataclips で SQL を用意し、いつでも気軽に SQL を変えられるようにしておこう。実際にその Dataclips を使う時はちょっとパラメータを変えて結果を取得し、JSON 形式で取ってこれれば実行しやすいデータ形式にすることができる。

JSON をクリックするだけで手軽に落とすことができる

その他に、毎回 heroku run console で取ってくるってのも手としてある。これはこれで便利で有効な方法なので、うまく使い分けるようにしたいところだ。heroku run console は方法は誰でもマスター権限的な感じで何でも実行できちゃうので便利な反面リスクもある。

統計データをエクセルで可視化したい

よくある話として、分析担当の人がエンジニアに今月の売り上げを取ってきてほしいみたいなことがある。その度にエンジニアが特定の SQL を叩いて取ってきて、それを渡してあげる的なフローだ。

こういうのはまさに Dataclips を使っていきたいところだ。必要な SQL を予め準備しておいて、そこにアクセスするだけで XLS 形式で落とすこともできる。それをエクセルで開いて、グラフに描画したりフィルタかけたり、自由に扱うことができる。

統計分析の初歩として、エクセルを使うってのは今だに便利な方法だ。自分の好きなようにデータをフィルタリング、ソートをかけて、好きなようにグラフ表示ができ、計算式を通して集計も実現できる。それを SQL のような専門知識を通さずにできるのだから、やはりエクセルは今でもスゴイ。

最終的に目指す方向ってのは誰もが SQL が書けて、そのデータをグラフ表示や分析に活用できる Redash のようなツールを使うことになるんだろうけど、それは本当にデータが多くなってきて超大量のデータを分析するみたいな本格的なタイミングになった時でいいと思う。最初からそこに時間かけるよりも、手軽にすぐに修正できる Dataclips でまずは経験を積んで、欲しい情報はなんなのかを突き詰めた後でも遅くはないだろう。他の大企業の事例を小規模のチームで真似すると手痛い思いをするので気をつけて欲しい。

終わりに

今回は Dataclips の中でも特にエクスポートでの活用例について簡単にご紹介した。

サービス開発してると無駄に管理ツールにこだわって時間かけすぎて本質を見失ってるケースは多々ある気がしている。それは単に仕事をした気になっているだけの、無駄な時間だ。 Heroku を使っている方なら インフラに余計な時間を使わないようにしているように、 Dataclips を使うことで管理ツール構築の手間も削減していこう。

自前実装を減らして、提供されているツールを活用することを考える。そしてどうしても自前でやらないといけないくらいクリティカルな課題にぶち当たった時だけ自前を検討する。そうした意識を続けることで少数のエンジニアで最大の成果を生み出すことができるようになるだろう。