日頃からHerokuをお使いいただいているみなさま、誠にありがとうございます。Heroku Advent Calendar 2020 23日目。かしゆかの誕生日、しょっさんです。
誕生日おめでとう、ゆかちゃん。なんで今年は休みじゃないんだろうか
ということで、日々、TV・ラジオやライブに忙しいPerfumeのかしゆかですが、彼女たちが舞台の上に立つまでには多くの練習とリハーサルを重ねて、本番を迎えていくんだと思います。
われわれエンジニアも、いきなり本番をリリースするわけではなく、泣きながらプログラムを書き、マニュアルとにらめっこして視力を落としながら設定をし、テストの結果をExcelに貼り付けながら本番リリースを迎えます。Herokuだって万能じゃない。Herokuで本番を迎えるには、それ相応の努力(設定とお金)が必要です。
今年は、Heroku で本番リリースする時に頼りになる、Production Check に焦点を当てます。
Heroku を本番リリースする
さて、特に泣き出すこともなく Heroku で本番サービスを提供している方はとても多いと認識しています。しかし、そのサービス。本番サービスに値するのでしょうか? このHeroku構成で本番リリースしてはよいのだろうか?
本番としてリリースするとなると、そういった不安要素がついて回りますね。さて、こういった時にある程度の基準があると嬉しいですよね。
はい、あります。
その名もまさに Production Check という機能です。こいつを攻略さえすれば、みなさまの Heroku アプリはある程度の基準に達したと言うことで、安心してリリースすることができるのではないでしょうか?
もちろん、これさえ通れば万事OKではありません。そのWebアプリ自体は誰も保証してくれるわけではありません。しかし、そのWebアプリを動かすためのプラットフォームが、どこまで本番として価値あるものかをチェックするには良き機能でしょう。では、この Production Check 、いかにして攻略していくか、何のために必要なのか解説していきましょう。ジャジャーン
とりあえず Production Check してみる
今(2020/12/22)、何も考えずに Herokuアプリを create して、実際に Production Check をしてみると、こんな感じになります。
何一つクリアできていません。さすが空の箱を一つ作っただけのことはあります。
あ、そうそう。使い方は簡単です。Heroku ダッシュボードで、チェックしたいHerokuアプリケーションを開きます。おもむろに右上にある "More"をクリックして、その中の "Production check" をクリックするだけです。簡単です。
Heroku Stack を解決する
上から順番にクリアしていきましょう。まずは Heroku Stack の最新化です。これは、Herokuアプリの"Settings"タブの "App Information" 内に Stack 情報が表示されているとこで "Upgrade Stack" するだけです。
設定変更自体は簡単ですが、OSに影響するようなアプリケーションを書いている場合には、Heroku Stack を更新することによって、アプリケーションが動かなくなる可能性があります。気をつけて更新しましょう。また、"Upgrade Stack"をすると、すぐさま適用されるわけではありません。次回のアプリケーションデプロイ時に Stack が一緒に更新されビルドされます。
Heroku Stack は最新化していればよい、ということではありません。サポートされている Heroku Stackを使っていれば良いので必須ではありません。ですので、 Production Check でも FAILED ではなく、WARNING どまりです。しかし、ぼやぼやしていると気がつくとサポート切れの Stackになってしまっていて、shutdown されますので、気をつけましょう。わたしもEOLを迎えて自動停止したCedarアプリがいくつかあります(はやくshutodwnせいよ)。
詳細は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
Dyno を冗長化しよう
Heroku Dyno は、障害が発生して停止としても直ちに起動するように構成されています。とはいえ、停止から機能の間には停止時間が生まれ、無停止で運用できるわけではありません。24時間+αで restartも発生します。停止せずに安定したサービスを提供するためには、Dyno の冗長化は必須です。設定は簡単。利用する Web Dynoを 2つ以上動作させるだけ、それだけです。
Standard Dyno なら、標準で最大 100Dyno 動かすことも夢じゃありません。
詳細は Scaling from the CLI/Autoscaling
オートスケール機能を使うするなら、Performance 以上ですよ⊂二二二（ ＾ω＾）二⊃ﾌﾞｰﾝ
本番用のHeroku Postgrsを利用する
Heroku Postgres を利用する場合、本番として推奨される Standard以上の Heroku Postgres を準備しましょう。では、Hobby Postgres では何がいけないのでしょうか。
Heroku Postgres Plan にすべてが書いてあります。Hobbyでは、Fork,Follow,Rollback,高可用性,暗号化すべての機能が利用できません。本番として利用するには、拡張性もなく、以前の状態に戻せないともなると不安で仕方ありませんね。
HA構成の Heroku Postgresを利用する
前段の指定ではStandard以上とはなっていますが、Premium以上でなければ、HA=高可用性構成となりません。ですからPremium以上でなければ結局本番としては「ダメ」と言うことです。
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
アプリケーションモニタリングの利用
サービスの死活監視は最低限必要です。エンジニアが生きて行くには、サービスの監視が必須です。監視のモニタを見て、オールグリーンであることが人生の幸福です。みんなで幸せを分かち合いましょう。
具体的には monitoringカテゴリ内にあるアプリケーションモニタリングツールを採用します。それぞれの監視目的に合わせて、どれか一つでも入っていれば、チェック上は問題ありません。しかし、可能であれば(お金があれば)、用途ごとに入れておくことが望ましいです。
たとえば、アプリケーションのパフォーマンス監視や障害の解析に利用できるNew Relic APMやメモリやコードの稼働分析に利用できるScout APM、パフォーマンス分析・ダッシュボードの使えるLibratoなど、運用管理の目的に合わせていずれか、またはすべてを組み合わせて利用しましょう。
サイトの死活監視だけに特化したPingdomなども機能をめりっと特化した分、利用しやすかったりします。
詳細は Visibility and Monitiroing
ログモニタリングの利用
Herokuのログは1,500行しか遡れない...。
ロギング機能を利用するには大きすぎる理由です。障害の解析はもとより、メッセージごとにアラートを出す機能などはあって当然、の機能です。連携したいサービスに合わせて、ロギングのツールもlogginカテゴリからチョイスします。
ちなみにですが、Herokuとまったく関係なく個人的に自分の家にあるサーバなどのロギングにPapertrailにお金を払って使っています。アイコン以外は好きです。アイコン以外は。
詳細は Log monitoring
カスタムエラーページの作成
アプリケーションでエラーが発生したり、障害でアクセスできないと Heroku のエラー画面が出ます。
「お、こいつHeroku使ってるじゃん」と言われたって別に何にもかまいはしませんが、ブランディングとしては失敗です。エラーページもカスタマイズすることで「より本番感」がでます。これがユーザ体験です。
設定は至って簡単、次の二つの環境変数でURLを指定するだけ。
| 環境変数名 | 内容 |
|---|---|
| ERROR_PAGE_URL | アプリケーションエラーが発生したときに表示されるURL |
| MAINTENANCE_PAGE_URL | メンテナンスモードにしたときに表示されるURL |
宛先はhtmlではなくても、画像ダイレクトも可能です。なんなら私が使っているエラーページは画像です。
詳細は Custom pages
SSL の使用
世界はSSL必須の世の中にほぼ変わりました。SSLではないというだけで警告の出る世の中です。
Herokuは何を設定せずとも、有料Dynoを利用するだけでSSLが利用できるようになっています。ただし、*.herokuapp.comなワイルドカード証明書です。これが悪いわけじゃありませんが、ボクはHeroku使ってますアピールでとてもありがたいです。
そうではなくて、やはり本番サービスを提供するサイトであれば、独自ドメインでサービスを提供するべきです。Herokuはもちろん独自ドメインにも対応していまして、CNAMEレコードで割り当て可能です。また、Let's Encrypt を利用したACM - Automated Certificate Managementが使えます。もちろん取得したSSLも使えます。最近たまたま設定したら、カスタムドメイン設定しただけで自動的にACMがオンになってました。びっくり。
詳細は Heroku SSL
これが本番リリースを迎えた Heroku アプリケーションだ
このような形で、これらをすべてクリアーするとみられるのが、このオールグリーン画面です。
あなたのサービスは、何色かな?