Heroku Addonを作る（概要編）

はじめに

BounscaleというHerokuのDynoをオートスケールするHeroku Addonを作って商用公開に向けて作業しています。
=> https://addons.heroku.com/bounscale

日本国内でAddon作って公開している人もそんなに多くないと思うので、手順に関する情報をまとめていきます。
今回は全体的な概要です。

Herokuって？

HerokuはRailsとかJavaとかPlayとかNodeとか色々動くPaaS環境を提供してくれるサービスです。
git pushするだけでWebアプリケーションを簡単に公開できます。

Heroku Addonって？

Heroku AddonはHerokuのアプリケーションに色々機能を付加できる仕組みです。
Addonカタログを見ての通り、相当な数のAddonが公開されています。

付加できる機能は、パフォーマンス分析からメール配信までアドオン毎に様々です。
個人的解釈としてはAppStoreのサーバサイドのライブラリ版みたいなものだと思っています。

エコシステム

Heroku自身が提供しているAddonもありますが大半はHerokuとは関係のない外部のAddon Providerが提供しています。レベニューシェアでHerokuの取分は30%です。

マルチPaaS・マルチProvider

Heroku本体とAddonのサービスは疎結合です。Herokuとは関係のない場所にサーバをたてて、WebAPIで紐づけだけを行います。

ですのでHerokuとは関係なくサービスを個別提供しているProviderも多数いますし、HerokuのライバルであるEngine YardにもAddon提供しているProviderも多いです。つまり、ProviderとしてはHerokuと一蓮托生ではなく、よそのPaaSとも付き合っていける構成です。

逆に見ると、HerokuのAddon内でも同種のサービスが複数存在しています。例えばMongoDBを利用できるAddonは「MongoHQ」と「MongoLab」の2種類があります。
つまり、Heroku自身もあるAddon Providerと一蓮托生ではないという事です。

結果として「マルチPaaS・マルチProvider」というオープンな関係と言えます。

何をすればいいの？

では、具体的に何を準備すればAddon Providerになれるのか。

基本的にDev Centerにドキュメントが公開されているのでこれに従って作業を進めていきます。ざっと書きだすと下記です。

• Addonとして動かすサービスそのものを構築する
• Provider Programに参加する
• APIサーバを構築する
• kensaツールでAPIが仕様を満たしているかテストする
• マニフェストファイルをアップロードする
• Private Alphaテストを実施する
• Private Betaテストを実施する
• Public Betaテストを実施する
• GA(商用版)を公開する

特徴的なのは、テストのステージがあらかじめ定義されている事です。ステージを進めるごとに公開の範囲が広がっていき、商用版に向けて品質を高めていきます。

これらの作業の詳細は別途記事としてまとめていきたいと思っています。
この記事では、概要を簡単に説明します。

Addonとして動かすサービスそのものを構築する

まずはこれがなくては始まりません。何よりこれの開発に注力すべきです。
あるいはすでにサービスを持っているのであれば、それをAddonとして公開することもできます。

Provider Programに参加する

Provider Programのサインアップ画面にアクセスして、規約を読み問題なければ同意します。

APIサーバを構築する

Addon向けにHerokuが定義しているAddon Provider APIに合わせて、Providerが個別にAPIサーバを立てる必要があります。これがAddon開発の肝です。

APIは下記の3つが定義されています。これらをProviderが独自に実装する必要があります。

• Provisioning : アプリ開発者のAddon利用・変更・解約申請を受け付けるAPIです。heroku addons:xxxコマンドを実行すると呼び出されます。
• Consumption : アプリからサービスに接続する情報をやりとりするAPIです。例えばDBのAddonであれば、DB接続情報をやり取りします。
• Single sign on : アプリ開発者がAddonの設定や利用を行うWebコンソールへのログインを行うためのAPIです。

sinatraで実装されたAPIサーバのサンプルが公開されていますので参考にしつつ、自サービスのテナント作成処理などとつなげます。

ちなみに今作っているオートスケールのAddon Bounscaleでは、AWSのus-eastリージョン上にAddonのサービスそのものとAPIのサーバを立てて運用しています。
おそらく、他のAddonもそのような構成になっていると考えられます。なぜなら、Heroku自体がAWSのus-eastリージョンにあるためレイテンシが小さいからです。
（最近ヨーロッパのリージョンも利用できるようになりましたが今のところやはりus-eastが主流です。）

kensaツールでAPIが仕様を満たしているかテストする

Herokuからkensaというツールがgemで提供されています。
kensaコマンドはAPIサーバに対してWebリクエストを発行し、想定しているレスポンスが返却されるかどうかをその名の通り「検査」します。

全ての検査をパスすれば、本番環境での正常動作について一定の保証を得られます。RSpecがはじめから提供されていると理解すれば大体あってます。

kensaを実施するには所定のJSONフォーマットに従ったマニフェストファイルにテスト対象に関する情報の記載が必要です。

マニフェストファイルをアップロードする

マニフェストファイルをkensa push コマンドでHerokuにアップロードします。

アップロードすると同時に該当のAddonの管理ページがHeroku上に作成され、後述のPrivate Alphaテストのステージに入ります。
この時点からheroku addons:add コマンドで任意のHerokuアプリにAddonを紐づけられるようになります。

Private Alphaテストを実施する

Private AlphaではAlphaテスタと呼ばれるテスタを個別に招待してaddonのテストをします。
招待しない限りには利用自体ができないため、サービスレベルが十分に担保できていないような状態でも、クローズドなテストを実施することができます。

この段階ではまだAddonカタログにアドオンが登録されることはありません。

Private Betaテストを実施する

十分にPrivate Alphaテストが終わったと判断したタイミングで [e-mail] にメールをするとPrivate Betaに移行します。（ちなみに以前はここはボタン1つで移行できたようなのですが、今は個別にメールを送る必要があります。）

Private BetaではHerokuの提供しているBetaプログラムに参加しているユーザのみがaddonの利用をできます。
Private Betaに移ってしばらくすると、Betaプログラム参加者向けのメーリングリストにAddonの情報が流れます。

このプログラムは誰でも希望すれば参加できるので、ここから世界中のイノベータが利用を開始してきます。

また、このタイミングで管理画面からマニュアルの公開や、利点、機能リストなど必要な情報を登録し承認を得ると、こんな感じでAddonカタログに表示されるようになります。

Public Betaテストを実施する

Private Beta移行時と同様に、十分テストが終わったと判断したタイミングで [e-mail] にメールをするとPublic Betaに移行します。

ちなみに、Addon ProviderのポータルページからPublic Beta移行のメールのmailto:があったりするのですが、ここのタイトルが間違っていて、「Please move Bounscale to GA」となっていたりするのでご注意を。

なお、あまりPrivate Betaが短いと、もっとテストした方がいい、と本国のHeroku addon担当の方からコメントをもらいます。目安的には1カ月前後位なのでしょうか。

Public Betaは課金以外はGAと同様という記載があります。
確認した限りでは、Private Betaとの違いは下記です。

• Addonカタログのトップページに追加される
• Betaプログラムに参加していない一般のHeroku利用者にもAddon利用が解放される

GAを公開する

まだよくわかっていません。一応、同様にメールでGA移行の依頼を送るみたいです。
商用版なのでここから課金できるようになるはずです。

おわりに

この記事はこれで終わります。次回以降、コードも交えて具体的にどう進めていくのか詳細をまとめていきたいと思います。