最終更新日 2022年11月07日(月)

Heroku で Java アプリケーションを構築するには、どのような種類のスキルセット (JEE、Spring など) が必要ですか?

Heroku では任意の Java アプリケーションをデプロイできます。これは JEE やその他のフレームワークに限定されません。WAR デプロイ​を使用して WAR ファイルとしてパッケージ化された Java Web アプリケーションをデプロイしたり、Git バージョン管理システムを使用して任意の種類の Maven ベースの Java プロジェクトをデプロイ​したりできます。どちらの場合も、選択した任意のフレームワークやライブラリ (サーブレット、JSP、JDBC ドライバーなどの Spring および JEE コンポーネントを含む) を自由に使用できます。

標準の Java Web アプリケーションを Heroku にデプロイできますか?

はい。すべての一般的な API (サーブレット、JSP、JDBC、taglib、JSF など) を使用する Java Web アプリケーションをビルドしてデプロイできます。Java Web アプリケーションは 2 つの方法でデプロイできます。ローカルでビルドし、WAR パッケージとして Heroku にデプロイ​するか、または埋め込み Webapp Runner を含む Maven WAR プロジェクト​として設定し、Git を使用して Heroku にデプロイできます。ほとんどの Java 開発者にとっては、前者のほうがよりなじみのあるアプローチです。後者は、継続的デリバリー向けにより最適化されています。

Java アプリケーションは Heroku 上の JEE コンテナで動作しますか?

WAR ファイルとしてデプロイされたアプリケーションは Tomcat コンテナで動作します。Git を使用してデプロイされたアプリケーションはコンテナにデプロイされません。代わりに、Jetty や埋め込み Tomcat などの Web サーバーライブラリ内にバンドルすると、アプリケーションは自己完結型のユニットとして実行できます。Thorntail​ などのフレームワークでは、これが自動的に行われます。後者のアプローチによって、環境への変更を最適に制御できる、継続的デリバリーに最も最した設定が提供されます。前者のほうが、ほとんどの Java 開発者になじみのある、より一般的なアプローチです。

Heroku に JEE コンテナをインストールするためのサードパーティの buildpack​ がいくつか存在します。

WAR ファイルとしてパッケージ化されたアプリケーションを Heroku にデプロイできますか?

はい。WAR ファイルのデプロイ​に関する記事を参照してください。

Heroku で (Web アプリケーションではない) スタンドアロンの Java アプリケーションを実行できますか?

はい。実際、Heroku にとって、スタンドアロンのアプリケーションと Web アプリケーションの間に違いはありません。これらは、どちらも Java プロセスです。Web アプリケーションは TCP ポート上の Web リクエストをリッスンし、それをサーブレット API などの何らかのフレームワークを使用して処理します。

アプリケーションは、ワーカープロセス (これは終了することがない)、heroku run​ コマンドで起動する 1 回限りのバッチスクリプト、または Heroku Scheduler​ によって実行されるスケジュールされたプロセスのいずれかとして実行できます。

スレッドを生成して制御することはできますか?

はい。

ファイルシステムとの間の読み取りや書き込みはできますか?

はい。ただし、このファイルシステムは一時的​です。ファイルシステムに書き込んだデータはアプリケーションの他の dyno から使用できません。一般に、リクエストの先頭で書き込まれたファイルは、前の制約に従って、そのリクエストの期間中は使用できると想定することができます (dyno がリクエストの最中に再起動される可能性がある)。保持しておきたいデータについてはローカルファイルシステムに依存しないでください。

標準出力に書き込まれたデータはどうなりますか?

標準出力は、Heroku ログサービス​にパイプされます。heroku logs​ コマンドを使用すると、このログストリームを (–tail オプションを追加した場合はストリーミングモードで) 取得できます。また、ログストリームを取得する Syslog シンクを追加し、それをログファイル内に保存したり、検索やレポートのためにインデックス処理したりすることもできます。

コア Java API の使用に関して何か制約はありますか?

いいえ。アプリケーションは、変更なしで最新バージョンの OpenJDK​ を使用して実行されます。

アプリケーションで使用する JDK を指定するにはどうすればよいですか?

Heroku には、アプリケーション内から Java バージョンを宣言的に指定する方法が用意されています。詳細は、「Java バージョンの指定​」を参照してください。

ソースコードを Heroku にプッシュする必要がありますか?

いいえ。ソースコードをプッシュした場合は Heroku がアプリを自動的にビルドしますが、自分でアプリケーションを WAR ファイルにビルドしたい場合は、WAR ファイルを直接 Heroku にデプロイ​することもできます。

ソースコードを Heroku にプッシュすることにメリットはありますか?

はい。Git リポジトリの内容をプラットフォームにプッシュすることには多くのメリットがあります。

• ビルド環境とランタイム環境の違いは、従来のデプロイ環境での不適切なデプロイの一般的な原因です。 アプリのビルドを、そのアプリが後で実行されるのと同じ環境で行うと、このリスクが大幅に削減されます。
• ビルドするのではなく、コードをプッシュすると、どのようなコードがどこにデプロイされているかについての高い可視性がユーザーやチームに提供されます。 たとえば、コマンド git diff production/master staging/master​ は、ステージング環境と本番環境の間の正確なコードの違いを表示します。
• Git は、変更された内容のみを送信するように高度に最適化されています。 つまり、完全なビルド成果物の転送が何分もかかる可能性があるのに対して、ほとんどのコードプッシュ (最初のプッシュを除く) は数秒しかかかりません。
• リビジョン管理を使用したデプロイにより、デプロイ権限を持つチームメンバー間の共同作業がより滑らかになります。 たとえば、これにより、最新のデプロイを古いデプロイで誤って上書きすることに対する上書き可能な保護手段が提供されます。

Maven とは別のビルドシステムを使用できますか?

Heroku でアプリケーションを自動的にビルドするようにしたい場合は、Maven または Gradle から選択できます。ただし、Ant ベースのビルドは、ここ​に示すようなサードパーティ提供の buildpack で実行できます。当社の Maven サポートを利用する場合は、プロジェクトの最上位レベルで pom.xml​ ファイルを指定する必要があります。必要に応じて、Maven を使用して、Ant スクリプトやその他の種類のビルドスクリプトを起動できます。

WAR ファイルをデプロイしている場合は、もちろん、希望する任意のビルドシステムでビルドできます。

Heroku では、その他の任意の種類のビルドをカスタム buildpack​ 経由でサポートできます。

Heroku で Force.com や Database.com の Java アプリケーションをビルドするにはどうすればよいですか?

Java 用の Database.com SDK​ を使用します。

Heroku でアプリケーションを開発する場合は、どのような制約に注意する必要がありますか?

Heroku でアプリケーションを設計する場合に念頭に置いておくべきいくつかの点を次に示します。

• アプリケーションのソースコードにビルトされた成果物を加えた容量は、圧縮時に 500 MB 未満である必要があります。Git リポジトリ内のファイルがデプロイされるパッケージに含まれないようにするには、.slugignore を使用します。
• 1 つのアプリケーション内に多数のプロセスタイプが存在できますが、ルーティングレイヤーからリクエストを受信する Web プロセスになれるのは、それらのタイプのうちの 1 つだけです。
• Web プロセスは、1 つのポートだけでリッスンする必要があります。このポートは、$PORT 変数で指定されたものである必要があります。プロセスが他のポートでリッスンすると、Heroku によってシャットダウンされます。
• Heroku のルーティングインフラストラクチャで “スティッキーセッション” はサポートされません。クライアントからのリクエストは、アプリケーションを実行しているすべての dyno にランダムに分散されます。
• 同じプロセスタイプ (Web プロセスタイプなど) の個々の dyno プロセスが互いに直接通信することはできません。たとえば、それらの間で状態を複製することはできません。Heroku は、各ノードが完全に分離されているシェアナッシングアーキテクチャです。
• 1 つの dyno (たとえば、Web プロセスタイプの 1 つのインスタンス) が、Heroku によっていつでも再起動される可能性があります。アプリケーションは、データが失われたり、ユーザーエクスペリエンスが大きな影響を受けたりすることなく、再起動を予測するように設計されている必要があります。dyno は、強制終了される前に SIGTERM シグナルを受信します。このシグナルを捕捉すると、整然としたシャットダウンを実行できます。
• ファイルシステムに書き込んだデータはアプリケーションの他の dyno から使用できません。一般に、リクエストの先頭で書き込まれたファイルは、前の制約に従って、そのリクエストの期間中は使用できると想定することができます (dyno がリクエストの最中に再起動される可能性がある)。保持しておきたいデータについてはローカルファイルシステムに依存しないでください。
• アプリケーションは 1 分以内に起動する必要があります。
• アプリケーションのメモリ設定を JAVA_OPTS 環境設定で指定されているデフォルト値から増やすことができます。ただし、最終的にパフォーマンスは低下します。ヒープの増加に頼るのではなく、常に、可能であれば水平方向のスケールアウトを考慮して設計する必要があります。この設定は heroku config​ で確認できます。

Heroku の組み込みの PostgreSQL データベースを Java で使用できますか?

はい。Java から共有データベースまたは Heroku Postgres データベースのどちらにも接続できます。JDBC または使い慣れたデータベース接続のその他の任意の手段を使用できます。また、アプリケーションをトラブルシューティングするためにローカルマシンから Heroku Postgres データベースに接続することもできます。Dev Center には、Heroku Postgres​ に関する詳細情報が含まれています。