こんにちは、三宅です。
ここ最近、Salesforceが提供するHerokuのトレーニングであるHeroku基礎のプライベートトレーニングの講師を担当していました。
案件でHerokuの利用を検討している、またはすでに利用を始めているというお客様のところで、Herokuの特徴やアプリケーションを開発する上での基本的な考え方等について解説を行いました。
Heroku Enterpriseと銘打っているように、SalesforceはHerokuのエンタープライズでの利用を促進しています。Force.comとの連携が必要であったり、開発期間の短いような案件では、Herokuは有力な選択肢となりうると考えています。
ただ、HerokuにはPaaS(Platform as a Service)ならではの特徴があり、これまでオンプレミスのアプリケーションを開発していた人にとって戸惑う部分も多いと思います。今回は、Heroku基礎のプライベートトレーニングで出てきたそういった質問などを紹介していきます。

Herokuへのデプロイ方法

HerokuではGitを用いてアプリケーションをデプロイする仕組みとなっているが、別の方法はないのかという質問が出ました。
Subversionを用いてバージョン管理している場合などに、まず思いつく疑問だと思います。
「git push」以外にGitHub、Dropboxとの連携によるデプロイが可能ですが、GitHubでは結局Gitが必要であること、また共にセキュリティポリシー的に利用が難しい場合が多いでしょう。
Gitを用いたバージョン管理に移行するのが最も簡単ですが、それができない場合はバージョン管理は引き続きSubversionで行い、Gitはデプロイツールとしてのみ用いるという使い方が容易だと思います。
Gitによるバージョン管理の概念や詳細なコマンドを覚える必要がなく、最低限の学習コストですますことができます。

GitHubは必須か

HerokuのGitリポジトリはデプロイのためだけに利用するもので、バージョン管理は別のリポジトリで行う必要があります。
GitといえばGitHubというように取り上げられることも多いのですが、GitHub連携のデプロイを行わないのであれば、Bitbucketなどの別のホスティングサービスを利用したり、イントラネットにGitサーバを用意して利用するなどGitHubに限定されるわけではありません。
また、先ほどのHerokuへのデプロイ方法で述べたように、Suversionでバージョン管理を行うことができないというわけではありません。

ランタイムの選択

Javaランタイムの実装は何か、また選択は可能か、という質問をお客様から受けました。
HerokuのJavaランタイムはOpenJDKのみで、Oracleなどの別の実装を選択することはできません。また、Javaのバージョンは1.7及び1.8のみが利用できます。
Javaに限らず、Herokuでは言語ごとに利用可能なランタイムのバージョンが決まっており、それ以外のバージョンは利用することができません。
最初に利用する予定のライブラリや既存の資産が、Herokuで利用できるランタイムで動作するかの確認が必要になるでしょう。
各言語で利用できるバージョンやその指定方法は、公式ドキュメントのLanguagesに記載されています。

One-off Dynoの連続稼働時間

Herokuを初めてさわった人が戸惑うことの1つに、Dynoの1日1回の再起動が挙げられるでしょう。
レギュラーDyno、つまりリクエストを受け付けるWeb Dynoとバックグラウンドでタスクを実行するWorker Dyno、ともに1日に1回再起動が行われます。
Web Dynoではあまり問題にはならないとは思いますが、Worker Dynoでは時間を要するバッチなどを実行する場合などは気をつける必要があります。Herokuブログの以前のポストであるHerokuのWorker再起動問題を考えるも参考にしてみてください。
では、Heroku Schedulerなどで起動されたOne-off Dynoはどれくらい連続で稼働し続けるのか。
Schedulerの公式ドキュメントには、時間のかかるタスクはWorker Dynoを用いること、Schedulerにより起動されたDynoはスケジュールのインターバルより長い時間起動させることはできず、終了させられると記載されています。最長の期間が1日なので、1日を超えて起動させ続けることはできないと考えられます。
「heroku run」コマンドで起動したOne-off Dynoは自動でのリスタートを行わなため、明示的に接続を切らないと動作し続けると予想されますが、実際のサービスでの利用はとてもできないでしょう。
時間を要する処理がある場合は、適切な粒度に分割したジョブをキューに詰めて1件づつWorker Dynoで処理するなどの設計が必要となるでしょう。
キューを用いたバックグラウンドでの処理の実行の考え方について、Worker Dynos, Background Jobs and QueueingというHerokuの公式ドキュメントが公開されているので参考になると思います。

Web DynoへのリクエストをIPに基づいて制限する方法

調査した範囲内では、そのようなアドオンを発見することができませんでした。
RouterからWeb Dynoへのルーティングは完全にプラットフォームの制御下にあり、フックすることもできないため、Web Dynoにリクエストが到達してから、アプリケーション的に実装するしかないと考えられます。

負荷テストや侵入テスト

負荷テストについては明確なルールはないようで、フレクトではある程度アクセス数が想定されるようなアプリケーションについては、Herokuに対して事前通知などすることなく実施しています。
ただし、全国レベルのテレビ放送で紹介されるなど、プラットフォーム自体に影響があるレベルのアクセスが予想されるような場合は、テストの実施や放送日時などをHerokuへ知らせる必要があるでしょう。
逆に、侵入テストについてはPenetration Testing and Network Scanningに記載のように、事前に通知を送るように明確に定められています。
私はまだ実際にHerokuのアプリケーションに対して侵入テストを実施したことはないのですが。

今回のHerokuブログでは、Herokuのプライベートトレーニングで受けた主な質問を取り上げてみました。
実際の案件でHerokuを使う際の、設計・開発の参考にしていただければと思います。