フレクトのHeroku Lab

ども。
最近Herokuの提供するkensaというツールをちょっと触ったんですが、これがなかなかユニークな代物だったんでちょっと紹介してみたいと思います。

★ kensaとは

HerokuのAddon Provider向けに提供されているAddonインターフェース作成の補助ツールです。
Ruby製のコンソールアプリなのでgem installでインストールすることが出来ます。
おそらく名前の由来は日本語の「検査」で、文字通りAddonインターフェースの実装が正しく行われているかどうかを検査してくれるものです。

Heroku Addonの多くは実体は独立したWebサービスです。
それをAddon化するためにはサービス側でいくつかのHerokuが規定するAPIを実装する必要があります。
例えば

• heroku addons:add コマンド実行時に新しいユーザを作成しその情報を返す
• heroku addons:update でプラン変更を行う
• Heroku Dashboardからシングルサインオンで管理画面を表示する

などです。
これらはすべてWebAPIとして実装する必要があるわけですが、kensaはその実装URLに対して様々なテストを実行してくれます。

• HTTPレスポンスが200 OKで返ってくるか？
• Basic認証が正しく実装されているか？
• レスポンスボディがJSONになっているか？
• JSON内に必要な情報が含まれているか？

などなど。

これ、つまりテスト駆動開発で最初からテストが揃っている状態で開発できるということなんです。
もちろん、サービス側のブラックボックスである実際のユーザ登録などのバックエンド処理はkensaでテストすることはできないわけですが、まだ何も実装していない状態で、kensaのテストが404 Not Foundで落ちるのを確認するところからはじめて、すべてのテストをクリアするまで実装を進めていくというのはなかなか面白い経験でした。

実際にテスト駆動開発を行っている場合でも、先にテストだけが全部揃っているという状況はなかなか無いでしょうしね。(^^;

★ なんか色々応用出来そう

実際に試してみて思ったのは数あるテストをクリアしていくのはなんかゲームみたいで楽しいな、ということです。

個人的には新人研修の最後や入社試験なんかでこうした課題があると面白いんじゃないかと思いました。
他にもプログラミング教育系のサービスに取り込んでも面白いでしょう。
所用時間や実行回数を計測してランキング化するゲームにするのもアリです。

ていうか、むしろ自分で作りてーとちょっと思いました。(いやマジで)(^^;

ちなみにkensaの使い方と作るべき課題の説明はこちらです。

https://devcenter.heroku.com/articles/building-a-heroku-add-on

バックエンドの処理を実装せずにkensaに合格するだけのものを作るだけなら、速い人なら1時間くらいでクリアできると思います。（Herokuまったく使ったことが無いと実装すべきもののイメージがわからなくて辛いと思いますけど）

社内で新人の教育なんかにも関わる立場の人であれば一回触ってみると面白いかもしれませんよ(^^;

今朝はHerokuからこんなサブジェクトのメール来てました。

Set the maintenance window for your database

どうやらHeroku Postgresにセキュリティパッチを充てるために停止を伴うメンテナンスが行われるらしい。

ここまでは過去にも数回あったことだしまたか、という感じなわけですが今回のメールがちょっと違うのは必要だったらメンテナンスの希望時間を設定しろ、という文章が続いてたこと。

$ heroku pg:maintenance window="Friday 18:15" pink -a myapp

というコマンドで希望時間を設定できるようです。(時刻はUTC。Fridayっていつのだよ？って思うけど普通に考えて次の金曜日のことでしょうね。)

詳細なドキュメントはこちら。

https://devcenter.heroku.com/articles/heroku-postgres-maintenance

これ見ると希望への対応はBest Effort(前後4時間)で、Standard/Premium-4より上のプランでのみ希望時間を設定できるようですね。

実際に作業を行う人達は多分サンフランシスコだからちょうど日本と昼夜逆転してて日本時間の深夜帯での希望は結構通りやすいんじゃないですかね。

また、heroku pg:info でメンテナンスの予定時刻も確認できるようです。(手元で試したら何故かnot requiredになってたけど。。。)

あれ？でも、このメールをうけた対象DBはRonin(Standard-2相当)なんだけど。。。。？？？

旧プランの扱いがなんかおかしいんだろうか。。。(--

pg:infoの件と言い、メンテナンス自体が手動で行われるものであるならメンテナンス時刻の設定も自動ではないと思うので、その辺若干怪しいにおいがしないでもない。。。

メンテナンス自体がちゃんと行われるのであればこうした周辺機能(サービスというべきか)が少々おかしくても文句はないですけどね。

ていうか、Postgresのプランをあげなければ。。。(--

世間はお盆で会社にも人が少ないわけですが、今朝はHerokuのChangeLogが6件もあがってたよ。。。(--
そのほとんどがPostgres関連。

https://blog.heroku.com/archives/2014/8/12/the_new_database_experience_with_heroku_postgres

なんかまたプランが変わってプラン名もこれまでのYanariとかTenguとかの妖怪シリーズじゃなくなってStandard0とかPremium7とかの無味乾燥な名前になるようです。

なんだかちょっと残念。。。
まぁ妖怪シリーズもどれが強いのかがよくわからないという欠点はあったんですが、どうせならPiccolo、Begeta、Freezaとかの方が序列がわかって良かったかも(^^;

そんな今回のUpdate、ざっくりまとめると以下のような感じです。

★ Performance Analytics

6月頃に紹介されてたExpensive Queries ToolがGAになったってことかな？

https://postgres.heroku.com/

から使えます。
DBを選択すると遅いクエリのSQLを特定してくれて一週間分のそのクエリのパフォーマンスグラフを表示してくれます。

この手のパフォーマンス問題はインデックス一個追加するだけで劇的に改善されたりもするんですが、その手掛りとしては最高レベルの情報提供だと思います。

また、CLIで

heroku pg:diagnose

というコマンドが追加されました。

diagnoseは診断という意味ですが、このコマンドを実行するとRed、Yellow、Greenという診断結果と共に各診断項目のレポートが返ってきます。

診断項目としては

• Hit Rate
• Indexes
• Connection Count
• Long Queries
• Idle in Transaction
• Bloat
• Blocking Queries
• Load

があるようです。例えばIndexesであれば「このインデックス全く使われてないから削除した方が良いよ」みたいな提案がされます。

診断項目自体はHerokuの中の人が恣意的に決めたものだと思いますが、そこは十万単位のProductionデータベースを運用している人達です。きっと良い感じの提案をしてくれるのでしょう。(^^;

PostgreSQLにはデフォルトで収集されているパフォーマンス改善のための統計情報テーブルがたくさんあるんですが、よっぽど必要に迫られた時以外はそれらの見方を調べようとは思わない訳で、それがコマンド一つでエキスパートによるレポートとして返ってくるというのはかなりイケてる話だと思います。

もっとも、手元のDBでいくつか試してみたところHit Rate以外はAll Greenになるのでどんなレポートが返ってくるのかイマイチありがたみがよくわかりませぬ。(^^;;;

★ Continuous Protection と On-disk Encryption

Premiumプランでは継続的なDB保護とDB自体の暗号化がされます。

DB暗号化は特に説明不要かと思いますが、Continuous Protectionってのはなんなんでしょうね？
60秒おきの新データのアーカイブとか30秒おきのヘルスチェックとか書かれてますが、要するにHA(High Availabity)を担保するためにこんなことしてますよ、ってことではないかと。

PremiumプランのHAオプションは、元々裏でFollow DBが自動的に作られて障害時には自動的に切り替わるというものなので、その安全性がさらに高まったという話なんだと理解しました。

★ 2倍のメモリ、3倍のパフォーマンス

これが今回の発表で一番重要な情報です。

新プランのラインアップは完全に旧プランと対応していて、旧プランの価格と同じ価格のプランがすべて揃っていますが、価格は同じでもメモリは2倍、パフォーマンスは計測上は3倍になっています。

ただし、この恩恵を受けるためには明示的にAddonをアップデートする必要があります。(メモリが変わるってことはPostgresが実行されているホストも切り替わるから)

https://devcenter.heroku.com/articles/upgrading-heroku-postgres-databases

pgbackups:transfer というコマンドが追加されて移行も簡単にできるようになったみたいですね。

ProductionプランでHeroku Postgresを運用している人は早めに切り替えた方が良いでしょう。

★ PremiumとStandardの違い

最後にStandardプランとPremiumプランの違いをまとめておきます。
違いは全プラン共通で以下の3点です。

• Encryptionされない
• Rollback可能な時間が60分(Premiumは7日間)
• High Availabilityじゃない

Rollbackはそう言えばそんな機能あったなぁ、と今思い出しましたが過去にブログ書いてます。

http://blog.flect.co.jp/labo/2013/11/heroku-postgres-62fb.html

読み返すと旧バージョンではRollback可能な期間がプラン毎にバラバラだったのが今回60分と7日間に統一されたようですね。
さすがに一ヵ月はやりすぎだと気が付いたらしい。(^^;

個人的にはStanndardの60分は短すぎて実質的には使えないような気がしますが、実際のところはどうなんでしょうね？ 逆に過去の統計からRollbackが使われる場合の期間の大半はこれで十分という判断があったのかも。

まぁ、実際には一度も使ったことがないのでどうでも良いんですけどね。(^^;;;

やっぱりStandardとPremiumの選択時のポイントはHAの有無だと思います。

先週、Herokuの新しいダッシュボードのリリースと合わせるようにして、Herokuボタンという機能もリリースされました。

イマイチ惹かれるところがなかったので、スルーするつもりだったんですがその間にnaoya氏がブログを書かれていて、それが面白かったんでリンクを張っておきます。

http://d.hatena.ne.jp/naoya/20140809/1407556488

特にPullReqからデプロイできるというお話が興味深いです。そんな発想はなかった。。。(^^;

実際にはPullReqの度に新しいHerokuアプリを作るというのはやりすぎだと思いますが、ボタン一発で既存アプリのコピーをHeroku上に作れるというのは実は色々と使い道があるのかもしれません。

例えば開発チームに新しいメンバーが入ってきた時にコピーを作ってもらってそこで色々試してもらうとか。

実際のイニシャルデプロイではAddonの追加とか、CREATE TABLEの実行とかgit push以外にも必要な作業があるんですが、それもapp.jsonで設定することができるようです。

postdeployとして任意のスクリプトを実行できるのでそこにCREATE TABLEを実行するスクリプト(当然中でrakeやjavaの実行も可)を指定すればOK。

postdeployは通常のgit pushで動くものではないので既存アプリへの影響もありません。(多分)

そして、ここまでくればapp.jsonを読み込んでDockerでローカルにHerokuアプリを再現することもできるはず。

ググってみると同じ事を考えている人もちらほらいるみたいだからそのうち出てくるんじゃないかなぁ。。。(自分でやる気はまったくない(^^;)

ていうか中の人がこんなの作ってるのも見つけたよ。

https://github.com/ddollar/heroku-docker

日付も新しいし最近作り始めたっぽい。

というわけで自分の興味分野からは若干外れた内容ではあるモノの興味ある人はwatchしてると良いんではないでしょうか。

app.jsonはPlatform APIでGenerateもできるようなのでとりあえず作っておくと良いと思うよ。
(^^;

Herokuの新しいDashboardがpublicベータになったらしいです。

https://blog.heroku.com/archives/2014/8/5/new-dashboard-and-metrics-beta

現在のHeroku Dashboardの上の方に表示される「Try out the New Heroku Dashboard」のリンクをクリックするか、直接

https://dashboard-next.heroku.com/

にアクセスすれば使うことができます。

ざっと試した感じでは、2Dyno以上使っている場合にのみMetrics画面で

• ResponseTime
• Throughput
• CPU
• Memory

が見られるようになった以外は機能的な変更はない気がします。
これらはNewRelicやLibratoをいれた場合に見られるものと同じですけど、2Dyno以上(すなわち課金アプリ)限定とはいえ標準画面で見られるのは嬉しいですね。(逆の言い方をすれば無料で使っているアプリでもAddonを入れればこれらの数字を見ることは可能です。)

あと地味にFavoriteなアプリがサイドバーに常に表示されているのも使い勝手が良いです。

しかしもっとも特筆すべき点はなんといっても画面が白くなったってことじゃないかな。(^^;

トップページだけは大分前からこのテイストになってたけど、今後はこっちに統一されていくのかも。

今ならFeedbackも反映されやすいと思うので、使い勝手にご意見ある人はガンガンFeedback送ると良いと思います。(こうしたFeedbackへのHerokuのレスポンスはかなり良いです。)

★追記

Metrics画面ではErrorsも見れます。

これは10分単位でその間にHerokuのエラーコードがログに出力した回数を数えたもののようです。

かなりイケてます。(^^v

先週の予告通りAuth0を使ったLDAP連携についてです。

LDAP。触ったの3年ぶり位。前職の時にはLDAP連携とかも作ってましたが転職してからはほとんど名前を聞くこともなくなってました。
世の中的にもそんなもんなんじゃないかと思ってるんですが、Active Directory使っているところは今でも普通に使ってるのかな？

★ LDAPとは

今さら説明不要かもしれませんが、とりあえず雑な説明を(^^;

LDAPとはLightweight Directory Access Protocolの略で、「Lightweight」「Directory Access」という単語が示す通り

• - 軽量
• - ディレクトリ構造(ツリー構造)のデータにアクセス

という特徴を持つプロトコルです。(直訳やんけ)

LDAPサーバにはOpenLDAP、Apache DSなどの実装があり、ユーザ管理に使われることが多いです。(組織の階層構造を表すのにディレクトリ構造が都合良いため)

といっても、純粋LDAPサーバはほとんど普及しておらず実際に使われているプロダクトのほとんどはActive Directory(以下AD)です。
ADはMS独自の製品でLDAPサーバよりも遥かに多機能ですが、LDAPインターフェースを備えているので(プロトコルとしての)LDAPでもアクセスできます。

MS独自APIでしかアクセスできないと利用者が限られてしまうのでオープンなプロトコルであるLDAPも使えるようになっているということです。

★ クラウドとLDAP

HerokuやSalesforce等のクラウドサービスのサーバは当然ながらインターネット上にあります。
一方で企業のユーザを管理するLDAP/ADサーバはほとんどの場合イントラネット内にあります。

このためクラウドサービスから企業内のLDAP/ADサーバに直接アクセスすることは普通はできません。

★ Auth0とLDAP

この課題をAuth0はどうやって解決しているんだろう？という点に興味津津だったんですが、その答えはこれ。

https://github.com/auth0/ad-ldap-connector

なんのことはない。企業内に中継用のコネクタサーバをインストールしてもらうだけです。

。。。あー、うん。。。。これが許されるんならどうにでもなるわー。
なんかもっと画期的な方法があるのかと期待したけど、どうやらそんなものはないらしい。。。(--

上記のGitHubがコネクタサーバのリポジトリなわけですが、具体的には以下のように設定していきます。

1. Auth0のダッシュボードでAD/LDAPのコネクションを作成
2. LDAP Connector(node.js製サーバ)をイントラネット内のサーバにインストール
3. LDAP ConnectorでAuth0のAPIキーとLDAPサーバへの接続情報を設定
4. (必要であれば) LDAP Connectorインストールディレクトリ直下のconfig.jsonにユーザ検索クエリを設定

実際に試してみてちょっとはまったのは以下の2点です。

• Windows用のインストーラが提供されているが、それでProgram files以下に保存した場合うまく動かない。(おそらくインストールディレクトリ直下の設定ファイルの書き換えがうまくいっていない)
• 検索クエリの変更方法がソースをGREPしないとわからなかった

デフォルトの検索クエリは「(sAMAccountName={0})」なので、ADを使っている場合は変更不要なはずです。
が、テストはApacheDSで行ったため変更が必要でその方法がドキュメントに載ってなかったんですよね。。。(後から気が付きましたがGitHub上のREADME.mdには載ってました。)

このあたりもLDAPはほとんどADでしか使われてないんだなという背景をうかがわせます。

ちなみに今回は試せませんでしたが、ADでKerberosが有効になっている場合ログイン画面もスキップした完全なシングルサインオンもできるようです。

★ まとめ

クラウドからのLDAP連携。多分そうだろう、とは思ってましたがやはり直接やる方法はないようですね。
Auth0は自前のLDAP Connectorを企業内にインストールさせているわけですが、そんなやり方で良ければ自前でもできるな～と思ったりもします。
Auth0製のLDAP Connectorがオープンソースで公開されているので、LDAP連携の部分をコピってちょっと直すだけでもそれっぽいものが作れそうな気がしますしね。(^^;

実際に必要な場面になったら、どうするかはわかりませんがとりあえずやり方だけはなんとなくわかりました。