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 の恩恵は確実に得られている。