モダンなアプリケーション設計や運用を助けるHerokuの追加機能

Herokuではじめるチーム開発と運用　第5回

　ここまでの連載では、Herokuの開発時に便利な機能やセキュリティ関連のトピックを中心にご紹介してきました。今回は、より柔軟なアプリケーション設計を可能にしたり、リリース後の運用を楽にする機能をご紹介します。

Release Phase

　1つめの機能はRelease Phaseです。

　アプリケーションをリリースする際、DBスキーマの更新やCDNへアセットのアップロードなど、一度だけ任意の処理を挟み込みたいというケースがよくあります。Release Phaseの機能を使うと、それが簡単に実現できます。

　今までも、アプリケーション定義ファイルであるapp.jsonファイル内に「postdeploy」を定義することによって、アプリケーションのリリース時に処理を定義することが可能でしたが、postdeployはアプリケーションを作成した際にしか動作せず、更新のリリース毎に動作させることはできませんでした。

　Release Phaseを使えば、アプリケーションのデプロイ（Gitプッシュ、Config Varsのセット、ロールバック、Platform APIを使ったアプリケーションの更新など）ごとに処理を挟み込めるので、各リリース毎に行いたい処理を差し込むのに便利です。

　定義方法はシンプルで、Procfile内にリリース時に呼び出してほしいコマンドを記載するだけです。

Procfile

release: ./release-tasks.sh

　Release Phase中になんらかの処理が失敗した場合にはデプロイ処理が中止されるため、リリースに必須な処理を挟み込む際にも安心して利用できます。

Private Spaces DNS Service Discovery

　2つめの機能はPrivate Spaces DNS Service Discovery （以下DNS Service Discovery）です。

　前回の記事でもご紹介しましたが、Herokuには閉じられた仮想ネットワーク内に、HerokuのDynoインスタンスやPostgreSQLを展開できるPrivate Spacesという機能があります。このPrivate Spaces内に複数のアプリケーションを構成して、それぞれのアプリケーションをDNS経由で見つけることができるのがDNS Service Discoveryです。

　サイズの小さなアプリケーションであったり、モノリシックなアーキテクチャ構成でアプリケーションが実現できる場合には必要性の薄い機能ですが、アプリケーションが機能ごとに分かれていて、それぞれがAPIを通して通信するようなマイクロサービスアーキテクチャを構成する場合、プライベートネットワーク内で、どのIPにアプリケーションがいるのかを知る必要があります。

　そこで、DNS Service Discoveryを利用すると、

[Dyno番号].[プロセスタイプ(Procfile記述)].[アプリケーション名].app.localspace

　のFQDN（Fully Qualified Domain Name：完全修飾ドメイン名）でアプリケーションの場所を特定できるようになります。

　例えば、Private Spaces内に、メッセージングを行うアプリ「space-service」と、Webアプリケーションである「space-web」という2つのアプリケーションがある場合、DNS Service Discoveryを利用した呼び出し方は以下のようになります。

space-serviceアプリケーション - Procfile

message: space-service

space-serviceアプリケーションの処理

router.GET("/hello", func(c *gin.Context) {
    c.JSON(http.StatusOK, gin.H{"message": "Service!", "status": http.StatusOK})
})
router.Run(":8080")

space-webアプリケーションからspace-serviceアプリケーションを呼び出す場合

resp, err := http.Get("message.space-service.app.localspace:8080");

　このようにすると、Webアプリケーション側で「Service!」というメッセージを受け取ることができます。

　Dyno番号はオプションなので、特定のDynoにメッセージングをしたい場合以外には省略できます。通常の設計であれば特に必要になることは少ないでしょう。

　このケースだと、space-serviceアプリケーションはmessageというプロセス名のWorker Dynoとして動かしています。これは、Private Spaces内のアプリはWeb Dynoとして動作させた場合のみ、インターネット経由からのHTTP／HTTPS（80＆443ポート）通信を許可するという仕様を持っています。マイクロサービスで構築した場合の各サービスは、通信はREST（HTTP）で行っていますが、それ自体を外部に公開したいわけではない場合が大半です。

　このような場合は、Worker Dynoを利用して、プライベートネットワーク内のみで参照可能なWebプロセスとして定義します。

　また、今回のspace-serviceアプリケーションはポート番号8080で動作していますが、Private Spaces内のアプリケーションのポート番号は、1024から65535までのポートを自由に使ってよいことになっています。しかし、80や443ポートは実質動作しますが、推奨されていないポートなので、ポート番号は明示的に指定しましょう。