2018年4月から2年目を迎えた。森久です。

前々回はHerokuについて紹介致しました。
https://www.acceluniverse.com/blog/developers/2018/04/heroku-part1.html

前回はHerokuのアドオンついて紹介致しました。
https://www.acceluniverse.com/blog/developers/2018/06/heroku-part2.html

今回は題名にもある通りアドオンで詰まった備忘録を記載致します。
詰まったアドオンは「QuotaGuard Static」です。

結論から記載すると原因はHeroku Schedulerの一時的なDyno（one-off dynos）に関して設定がなされていなかったためです。

要件は下記になります。
1. アプリ自体をHerokuのPrivate Spaces（AWS VPCを用いた隔離環境）からCommon Runtime（Private Spacesとは逆にpublicに開かれた環境）に移行する。
2. DBはシステムの構成上、Private Spacesに残す。
3. DBにアクセスし更新するバッチはHeroku Schedulerにて設定している。(Common Runtime上)

※AWSとはクラウドサービスで、HerokuはAWS上で動いています。
AWS VPCについては以下を参照してください。（今後ブログで紹介するかもしれないです。）
https://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Introduction.html

QuotaGuard Staticの手順に則り下記のように設定を進めました。
少し詳細を説明させていただくと、まず接続するにあたって、HTTPプロキシを使用するかSOCKS5プロキシを使用するかを決めます。
今回はDBにアクセスするためSOCKS5プロキシを指定しました。（Herokuの公式によるとwebはHTTPプロキシ・それ以外はSOCKS5プロキシがオススメだったため）
参考：https://devcenter.heroku.com/articles/quotaguardstatic

SOCKS5プロキシを使用して「Common Runtimeのアプリ」から「Private SpacesのDB」にアクセスするにはproxyを通す必要があります。

Proxyの通す方法

1. 下記コマンドでpgtunnelをインストール

2. Procfileを編集（Dynoの設定を記述するファイル）
web: bin/bgtunnel アプリケーションサーバ名 ドキュメントルート
上記の「bin/bgtunnel」を先頭に付けることでDynoに対しproxyを通せます。

準備は整いました。新たにCommon Runtime上でproxyを通したアプリ(Private Spacesで展開していたアプリと同様のもの)を作成します。
ログイン画面に遷移し、ログイン情報を入力するとログインできました。（ログイン情報はDBに格納）
これでDBに接続できることは確認できました。

～～数日後～～

バッチが動いていません...
下記エラーが発生していました。

DBに接続できていない。先ほど記載した通りログインはできますし、アプリからDBの更新処理も行えます。
調査を行いましたが分からず、Herokuに問い合わせました。

迅速な対応をしていただき、共に調査を行なったことで原因が判明。
アプリのDynoにはproxyを通したためDBに接続できましたが、Heroku Schedulerはバッチ処理を行う際、一時的にアプリとは異なるDynoを立ち上げます。
そのDynoにはproxyが通っていないためDBに接続できなかったのでした。
一度気づけば、納得ですが気づかないと詰まると思いました。（他のアドオンとかでも場合によっては起きそう）

proxyを通し無事解決

まとめ

1. Heroku Schedulerで立ち上げるDynoはアプリのDynoとは別物（もはや関係すらない）
2. Herokuに問い合わせた際の対応が迅速でよかった。

以上3回に渡ってありがとうございました。