Heroku でアプリケーションを本番リリースする


日頃から`Heroku`をお使いいただいているみなさま、誠にありがとうございます。[Heroku Advent Calendar 2020](https://qiita.com/advent-calendar/2020/heroku) 23日目。かしゆかの誕生日、しょっさんです。

誕生日おめでとう、ゆかちゃん。なんで今年は休みじゃないんだろうか

ということで、日々、TV・ラジオやライブに忙しいPerfumeのかしゆかですが、彼女たちが舞台の上に立つまでには多くの練習とリハーサルを重ねて、本番を迎えていくんだと思います。

われわれエンジニアも、いきなり本番をリリースするわけではなく、泣きながらプログラムを書き、マニュアルとにらめっこして視力を落としながら設定をし、テストの結果をExcelに貼り付けながら本番リリースを迎えます。Herokuだって万能じゃない。Herokuで本番を迎えるには、それ相応の努力(設定とお金)が必要です。

今年は、Heroku で本番リリースする時に頼りになる、`Production Check` に焦点を当てます。

# Heroku を本番リリースする

さて、特に泣き出すこともなく `Heroku` で本番サービスを提供している方はとても多いと認識しています。しかし、そのサービス。本番サービスに値するのでしょうか? このHeroku構成で本番リリースしてはよいのだろうか?

本番としてリリースするとなると、そういった不安要素がついて回りますね。さて、こういった時にある程度の基準があると嬉しいですよね。

はい、あります。

その名もまさに [Production Check](https://devcenter.heroku.com/articles/production-check) という機能です。こいつを攻略さえすれば、みなさまの Heroku アプリはある程度の基準に達したと言うことで、安心してリリースすることができるのではないでしょうか?

もちろん、これさえ通れば万事OKではありません。そのWebアプリ自体は誰も保証してくれるわけではありません。しかし、そのWebアプリを動かすためのプラットフォームが、どこまで本番として価値あるものかをチェックするには良き機能でしょう。では、この [Production Check](https://devcenter.heroku.com/articles/production-check) 、いかにして攻略していくか、何のために必要なのか解説していきましょう。ジャジャーン

## とりあえず Production Check してみる

今(2020/12/22)、何も考えずに Herokuアプリを create して、実際に [Production Check](https://devcenter.heroku.com/articles/production-check) をしてみると、こんな感じになります。

![Screen Shot 2020-12-10 at 15.44.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37263/192d117c-605a-3c4a-290a-6858af2a116a.png)

何一つクリアできていません。さすが空の箱を一つ作っただけのことはあります。

あ、そうそう。使い方は簡単です。Heroku ダッシュボードで、チェックしたいHerokuアプリケーションを開きます。おもむろに右上にある "More"をクリックして、その中の "Production check" をクリックするだけです。簡単です。

![Screen Shot 2020-12-10 at 19.37.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37263/ebb82330-59b4-4dad-9f09-2186d6e4bd11.png)

## Heroku Stack を解決する

上から順番にクリアしていきましょう。まずは Heroku Stack の最新化です。これは、Herokuアプリの"Settings"タブの "App Information" 内に Stack 情報が表示されているとこで "Upgrade Stack" するだけです。

![Screen Shot 2020-12-10 at 19.49.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37263/ed14df72-1af4-4f68-a153-6ee53b17cf24.png)

設定変更自体は簡単ですが、OSに影響するようなアプリケーションを書いている場合には、Heroku Stack を更新することによって、アプリケーションが動かなくなる可能性があります。気をつけて更新しましょう。また、"Upgrade Stack"をすると、すぐさま適用されるわけではありません。次回のアプリケーションデプロイ時に Stack が一緒に更新されビルドされます。

Heroku Stack は最新化していればよい、ということではありません。サポートされている Heroku Stackを使っていれば良いので必須ではありません。ですので、 [Production Check](https://devcenter.heroku.com/articles/production-check) でも ``FAILED`` ではなく、``WARNING`` どまりです。しかし、ぼやぼやしていると気がつくとサポート切れの Stackになってしまっていて、shutdown されますので、気をつけましょう。わたしもEOLを迎えて自動停止したCedarアプリがいくつかあります(はやくshutodwnせいよ)。

詳細は[Upgrading to the Latest Stack](https://devcenter.heroku.com/articles/upgrading-to-the-latest-stack) 

## 本番用のDynoを利用する

本番に適した Heroku Dyno というものがあります。`free` と `hobby` 以外です。Heroku では `Standard-1x` 以上の Dyno を本番利用として推奨しています。`free`と`hobby`の何が本番として不足しているかというと。`free` は何もアクセスがないと 30分で sleep に入ってしまいます。`hobby` では Dynoタイプやスケールに制限があります。

従って、本番運用するに当たっては `Standard-1x` 以上、もし安定したパフォーマンスの恩恵を受けたい場合であれば、dedicated にアサインされる `Performance` 以上の Dyno を利用しましょう。

本番用のDynoを利用することで、安定したパフォーマンス、自由なスケーラビリティを得ることができます(๑•̀ㅂ•́)و✧

詳細は [Dyno Types](https://devcenter.heroku.com/articles/dyno-types#available-dyno-types) 

## Dyno を冗長化しよう

Heroku Dyno は、障害が発生して停止としても直ちに起動するように構成されています。とはいえ、停止から機能の間には停止時間が生まれ、無停止で運用できるわけではありません。24時間+αで restartも発生します。停止せずに安定したサービスを提供するためには、Dyno の冗長化は必須です。設定は簡単。利用する `Web Dyno`を 2つ以上動作させるだけ、それだけです。

`Standard` Dyno なら、標準で最大 100Dyno 動かすことも夢じゃありません。

![Screen Shot 2020-12-22 at 13.51.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37263/5a504f45-e133-724e-f550-8ae424b2cc22.png)

詳細は [Scaling from the CLI/Autoscaling](https://devcenter.heroku.com/articles/scaling#scaling-from-the-dashboard)

オートスケール機能を使うするなら、Performance 以上ですよ⊂二二二（　＾ω＾）二⊃ﾌﾞｰﾝ

## 本番用のHeroku Postgrsを利用する

Heroku Postgres を利用する場合、`本番`として推奨される `Standard`以上の Heroku Postgres を準備しましょう。では、`Hobby` Postgres では何がいけないのでしょうか。

[Heroku Postgres Plan](https://devcenter.heroku.com/articles/heroku-postgres-plans) にすべてが書いてあります。`Hobby`では、`Fork`,`Follow`,`Rollback`,`高可用性`,`暗号化`すべての機能が利用できません。本番として利用するには、拡張性もなく、以前の状態に戻せないともなると不安で仕方ありませんね。

![Screen Shot 2020-12-22 at 13.54.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37263/20bc9efa-cc0f-b6bd-55ff-e07dd9d87188.png)

詳細は [Production-tier database](https://devcenter.heroku.com/articles/production-check#production-tier-database)

## HA構成の Heroku Postgresを利用する

前段の指定では`Standard`以上とはなっていますが、`Premium`以上でなければ、HA=高可用性構成となりません。ですから`Premium`以上でなければ結局本番としては「**ダメ**」と言うことです。

![Screen Shot 2020-12-10 at 16.09.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37263/ed7666e0-ce4d-71c8-8fc6-7a85b41c9786.png)

Heroku PostgresをHA構成にすると、AZを考慮して実装されます。メインとなるPostgresに対して、FollowのPostgresが作成されます。これらは非同期に同期され、コミットされる度にFollow側のPostgresにデータが反映されます。

障害が発生した場合には、環境変数 `DATABASE_URL` が書き換わり、自動的に Follow側のURLになります。環境変数に変更が発生すると、Dynoは強制的にリスタートしますので、このタイミングでFollow側のデータベースへと切り替わる仕組みです。

ですから、Premium以上のHeroku Postgresを利用していたとしても `DATABASE_URL` を使ってアクセスしていない場合には、切り替えの恩恵にあずかれないので注意が必要です(´∀｀*)ε｀　)ﾁｭｯ

詳細は [High Availability on Heroku Postgres](https://devcenter.heroku.com/articles/heroku-postgres-ha)

## アプリケーションモニタリングの利用

サービスの死活監視は最低限必要です。エンジニアが生きて行くには、サービスの監視が必須です。監視のモニタを見て、オールグリーンであることが人生の幸福です。みんなで幸せを分かち合いましょう。

具体的には [monitoring](https://elements.heroku.com/addons#monitoring)カテゴリ内にあるアプリケーションモニタリングツールを採用します。それぞれの監視目的に合わせて、どれか一つでも入っていれば、チェック上は問題ありません。しかし、可能であれば(お金があれば)、用途ごとに入れておくことが望ましいです。

たとえば、アプリケーションのパフォーマンス監視や障害の解析に利用できる[New Relic APM](https://elements.heroku.com/addons/newrelic)やメモリやコードの稼働分析に利用できる[Scout APM](https://elements.heroku.com/addons/scout)、パフォーマンス分析・ダッシュボードの使える[Librato](https://elements.heroku.com/addons/librato)など、運用管理の目的に合わせていずれか、またはすべてを組み合わせて利用しましょう。

サイトの死活監視だけに特化した[Pingdom](https://elements.heroku.com/addons/pingdom)なども機能をめりっと特化した分、利用しやすかったりします。

詳細は [Visibility and Monitiroing](https://devcenter.heroku.com/articles/production-check#visibility-and-monitoring)

## ログモニタリングの利用

Herokuのログは1,500行しか遡れない...。

ロギング機能を利用するには大きすぎる理由です。障害の解析はもとより、メッセージごとにアラートを出す機能などはあって当然、の機能です。連携したいサービスに合わせて、ロギングのツールも[loggin](https://elements.heroku.com/addons#logging)カテゴリからチョイスします。

ちなみにですが、Herokuとまったく関係なく個人的に自分の家にあるサーバなどのロギングに[Papertrail](https://elements.heroku.com/addons/papertrail)にお金を払って使っています。アイコン以外は好きです。アイコン以外は。

詳細は [Log monitoring](https://devcenter.heroku.com/articles/production-check#log-monitoring)

## カスタムエラーページの作成

アプリケーションでエラーが発生したり、障害でアクセスできないと Heroku のエラー画面が出ます。

![heroku-error-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37263/bba1c0fa-4b3f-761a-b35f-042d66839f37.png)

「お、こいつHeroku使ってるじゃん」と言われたって別に何にもかまいはしませんが、ブランディングとしては失敗です。エラーページもカスタマイズすることで「より本番感」がでます。これがユーザ体験です。

設定は至って簡単、次の二つの環境変数でURLを指定するだけ。

| 環境変数名 | 内容 |
|---|---|
|ERROR_PAGE_URL|アプリケーションエラーが発生したときに表示されるURL|
|MAINTENANCE_PAGE_URL|メンテナンスモードにしたときに表示されるURL|

宛先はhtmlではなくても、画像ダイレクトも可能です。なんなら私が使っているエラーページは[画像](https://public-oshiire.s3-ap-northeast-1.amazonaws.com/404_2.jpg)です。

詳細は [Custom pages](https://devcenter.heroku.com/articles/error-pages#customize-pages)


## SSL の使用

世界はSSL必須の世の中にほぼ変わりました。SSLではないというだけで警告の出る世の中です。

Herokuは何を設定せずとも、有料Dynoを利用するだけでSSLが利用できるようになっています。ただし、`*.herokuapp.com`なワイルドカード証明書です。これが悪いわけじゃありませんが、ボクはHeroku使ってますアピールでとてもありがたいです。

そうではなくて、やはり本番サービスを提供するサイトであれば、独自ドメインでサービスを提供するべきです。Herokuはもちろん独自ドメインにも対応していまして、`CNAMEレコード`で割り当て可能です。また、`Let's Encrypt` を利用した[ACM - Automated Certificate Management](https://codezine.jp/article/detail/10252)が使えます。もちろん取得したSSLも使えます。最近たまたま設定したら、カスタムドメイン設定しただけで自動的に`ACM`がオンになってました。びっくり。

詳細は [Heroku SSL](https://devcenter.heroku.com/articles/ssl)


# これが本番リリースを迎えた Heroku アプリケーションだ

このような形で、これらをすべてクリアーするとみられるのが、このオールグリーン画面です。

![2020-12-21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37263/7f5803a0-c016-aaff-d7d1-5b6daca3e831.png)

あなたのサービスは、何色かな?