フレクトのHeroku Lab

世間はお盆で会社にも人が少ないわけですが、今朝は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連携の部分をコピってちょっと直すだけでもそれっぽいものが作れそうな気がしますしね。(^^;

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

先日からぼちぼちと作っているHerokuサンプルですが、新たにソーシャルログインのサンプルを追加しました。(ちなみにPDF出力のサンプルも追加されています。)

http://flect-heroku-sample.herokuapp.com/auth

このサンプル。Auth0というAddonを使っているんですが機能的にはかなりの優れモノです。。

どういうシロモノであるかはサンプルページを見ていただければわかるはず！(^^;
というか、全くわからないようなら説明の書き直しも考えなければならないのですが。。。詳しく説明しようとするならOAuthの説明からする羽目になりそうでなかなかバランスが難しいです。(--
知ってる人からすればそんな説明冗長でしかないわけですし。

OAuthはまだしも、JWT(Json Web Token)については知らない人の方が多そうですがこれも必要最小限の説明にとどめています。(実際のところ小西の理解もこの程度です。)

ご意見ご感想等あれば適当にTweetしてくれれば誰か(?)が拾います。(^^;

★ Auth0の良いところ

さて、ここではサンプルサイトでは書かなかったAuth0の評価について少し書いておきたいと思います。

Auth0の扱っている課題はソーシャルログインとシングルサインオンな訳ですがその課題に対するソリューションのセンスはとても良いです。

ざっと良いと思う点をあげると

• ユーザーのログイン履歴をダッシュボードで確認できるところ
• メールアドレス＋パスワードでのログインをAuth0側の管理DBでサポートしており、なおかつサインアップ時のメール確認フローまで備えているところ
• 対応ソーシャルアプリ30個以上
• テスト環境ではソーシャルアプリ側にOAuthアプリの登録不要
• 周辺機能(Loginダイアログ、LDAP Connector等)の多くがオープンソース

等があります。(実際に列挙してみると思ってたよりたくさんありました。)


コンシューマアプリではFacebookやTwitterでのログインはもはや当たり前になった感がありますが、これまで個別に実装・管理しなければならなかったソーシャル連携を一元化できるのは大きなメリットです。

ソーシャルのみならずAD/LDAP、Windows Azure AD、SAMLなどもサポートしており、認証関連の処理は全部まかせとけ！的な気概が感じられるところも良いです。(^^;

あと、地味に嬉しかったのはソーシャルアプリ側のOAuthアプリ登録について、こことここだけ設定すればOKという最低限の設定方法のヘルプがスナップショット付きで説明されているのがメチャメチャ助かりました。
FacebookやGoogleのOAuthアプリ設定、たまにしかやらないから見る度に画面変わっててとまどうんですよね。。。(^^;(ググっても古い画面の情報が引っ掛かることが多いし)

★ Auth0の課題

一方でこれどうなんよ？と思う点もいくつかあります。

設定系のドキュメントが充実している一方で参照系のダッシュボードの説明がほとんどないというのがまず一点ですが、一番どうかと思うのはユーザの詳細画面で見られるユーザ情報が詳しすぎるという点です。

ユーザ画面では一切説明なく色々な情報が列挙されているんですが、Salesforceアカウントでログインしたユーザ情報を眺めていた時に

あれ？これSalesforceのSessionIDじゃね？

という項目があったので、試しにそれをSessionIdとしてSalesforceのAPIにアクセスしてみたらできてしまったという。。。。(--

これはアカンだろ！！！

もちろん、これをするためにはSalesforce側のOAuthアプリの設定でAPIアクセスを許可しておく必要がありますが、逆に言えばAuth0を使う場合絶対にソーシャルアプリ側から提供する権限を最低限(ユーザ情報の参照のみ)にしておく必要があります。

特定のソーシャル連携を密に行うアプリの場合は複数ソーシャルをサポートする必要はないわけで、Auth0の目的からしたらこれでも問題ないのかもしれませんが、こんなSensitiveな情報は隠しておいて欲しい。。。(--

また、ユーザ画面に「Sign in as User」というボタンがあるのもかなり衝撃的です。

え、このユーザとしてログインする。ってことが一撃でできるってこと？？？

と思って、これまたアリえねーと思いつつ試してみたところ、

An error ocurred. "impersonator_id is a required parameter."

というエラーになりました。(そして、これに対する説明はどこを探してもありません。)
エラーメッセージから推測するに代理ログインする人(impersonator。他者になり済ます人の意)のIDを明示する必要があって誰が代理ログインしたかはわかるようにはなっているのかな？

であればギリギリ。。。
ん～、便利かもしれないけどやっぱりちょっとデンジャラスな気が。。。(--


□□□□
つらつらと書いてきましたが、まぁこんな感じです。(^^;

個人的な評価としては永続的なサービスではあんまり使いたくないけど、短期のキャンペーンサイトなどではむしろ積極的に使いたいと思いました。

ログインはそこがこけると全機能が停止するクリティカルポイントなので信頼性(事業の継続性や障害時の対応)の心配もあって永続的なサービスで使うのはちょっと怖い気がするんですよね。。。

★ 次回予告

今回はAuth0のソーシャルログイン機能を中心にお話ししましたが、LDAP連携についても試しているのでそのお話をしようかと。
(ローカルにLDAPまたはActive Directoryが必要になるのでサンプルサイトには載りません。)

なんかいつの間にかブログタイトル変わってるなぁ。。。
まぁ8割くらいはHeroku関連のこと書いてる良いんだけど。(^^;

さて、先週金曜日は昼間はAWS Summit、夜はHerokuのBiz Meetup #2となかなか忙しい一日でした。

AWS Summitはなぁ。。。
個人的にどストライクゾーンのテンションが上がるような発表がなかったのはしょうがないとして。
とりあえず人多すぎ。。。(--

どこの花火大会かと思ったよ。。。

登録者数も1万人を越えてたらしいし次回はもっと大きな箱でやって欲しいものです。

★ Heroku Biz Meetup

もう一方のHeroku Biz Meetup。

これはHeroku関連のイベントとはいえビジネスよりの集会ということで当初は行く気なかったんですが、弊社村田が登壇するということで賑やかしのために参加することにしました。

その発表資料がこちら

http://www.slideshare.net/muritaiga3/heroku-37234972

ほほぅ。。。
なんと、8月1日からHeroku基礎というセミナーが始まるらしいですよ！
さらに、プライペートの一社研修もあるらしいですよ！
要するに、Heroku触ったことない人でもこれを受ければなんとなくその日からHerokuでアプリを公開できるらしいですよ！

ということでこれからHerokuを始める人は受けてみると良いんじゃないかと思います。(^^;

★ Heroku サンプル集

ところでこの資料、最後の方にさらっととても重要なことが書かれています。

それはこのURLです。

http://flect-heroku-sample.herokuapp.com/

なんと、Herokuで各種処理を行うためのサンプルコード集だったり。
(現時点ではソース未公開です。ちなみに言語はJava。)

とりあえず10個ということで適当にネタを選んで集中開発しましたが、ネタは他にもあるのでおいおい追加されるはずです。直近では先に紹介したHyPDFのサンプルが待機中。(^^;

開発方針としては

• Heroku初心者向け
• Addonの使い方の紹介
• Heroku特有の処理の紹介

というような感じで考えてますが、場合によってはHerokuとほとんど関係ないようなサンプルも含めても良いかと思ってはいます。(FacebookやTwitterのOAuth連携とか。環境変数にAPIKeyを設定する以外は一般的な話でしかないんですが、そこで躓くような層がターゲットということでもあります。)

追加のトリガとしてはこのブログ連動でのネタやセミナーでの質問が大きな駆動力になると思いますが、こういうサンプルが欲しいと言う要望があれば、@flect_jpにメンションいただければそれもスタックしますよ。(^^;;;

あ、AddonベンダーさんからのうちのAddonを追加してくれ！というお話もWelcomeです。FLECTまで使い方の説明をしに来ていただけるなら、かなり高い確率で実装できるのではないかと。(^^;;;


□□□□
ちなみにソースコード。
まだ開発途中であるということと社内にソースコードはセミナーの特典にしてはどうかという意見のあることが現在非公開の理由です。

わかる人はソースなくても説明だけ見ればわかると思うのでそれでも良いかと思ったりもしますが。。。。

まぁ最終的にどうなるかは未定です。(^^;;;

ふと思い立ってPDF出力のAddonの調査していたら予想外に大変な便利Addonにぶちあたりました(^^;
多分これは今年一番のお役立ちエントリです。一度でもPDF出力に悩まされたことのある人なら読まないと後悔するレベル(かも)

★HerokuのPDF Addon

Addonを探すとDocRaptorとHyPDFという二つのAddonが見つかります。
どちらもHTMLを渡せばそれをPDFに変換してくれるというサービスのようです。

多分、DocRaptorの方が有名なので、最初こちらから試そうと思ったんですが。。。
料金プランを見てビックリ

• Starter(Free) - 月に5件まで
• Basic($19) - 月に125件まで
• Professional($37) - 月に325件まで
• Premium($95) - 月に1250件まで
• Max($189) - 月に5000件まで

無料プランがあるのは良いんだけど、月に5件ってなんだよ。。。(--
そんなのテストしてたら一瞬で消費するっちゅーの。

一番上のプランでも月に5000件、一日換算だと166件しか出せないって。。。
なんでこんな料金プランにしてるんだろ。。。

一方のHyPDFの料金プランは以下

• Nano(Free) - 日に5件まで
• Milli($15) - 日に15件まで
• Kilo($30) - 日に45件まで
• Mega($60) - 日に135件まで
• Giga($120) - 無制限

安っ！
制限のリセットも１日単位なので、ちょっと試すだけでもこちらの方が扱いやすそうです。
何より$120で使い放題というのは太っ腹。(^^;

ていうか、あんまり商売っ気がないのかも。
ブラウザで「www.hypdf.com」にアクセスすると、いきなりHeroku AddonsのページにリダイレクトされるのでどうもHyPDF単体ではサービス提供しておらず、Heroku Addonとしてしか提供されてないみたいなんですよね。
そういうのもアリなのか。。。(^^;

そんなこんなでまずはHyPDFから試してみることにしました。

(後から気がつきましたがDocRaptorにもHyPDFにもテストモードがあって、その場合は制限回数は更新されません。と言ってもDocRaptorの方はもはや試していませんが。。。)

★HyPDFの使い方

https://devcenter.heroku.com/articles/hypdf#api-reference

基本的な使い方としてはJSONで出力対象のHTMLと各種オプションを渡すだけです。
そうするとレスポンスのHTTPボディでPDFのバイナリが返ってきます。
HTMLの渡し方には文字列でHTMLを丸ごと渡す方法と、URLで外部サイトへの参照を渡す方法の両方がサポートされています。

オプションとしては

• ヘッダ、フッタ
• 上下左右の余白
• グレイスケール
• コールバックURL(指定した場合PDF生成が非同期となり生成完了時にこのURLがキックされる)
• 生成したPDFをS3にアップロードするためのオプション情報

などが指定できます。
何回か試したところ、PDF生成には最大10秒くらいかかることがあったのでHerokuから使う場合は非同期にした方が良いかも。

使い方は難しくないですけど唯一の注意点はHyPDFの使っている証明書がStartCom(StartSSL)の証明書だという点です。
知らなかったんですがこの証明書、デフォルトではOracle JDKのキーストアには入ってないんですね。なので、接続するためには自分で証明書をインストールするかHostNameの検証をスキップするかする必要があります。
(この辺を調べてる過程でさらに憂鬱な衝撃の事実を知ったんだけど、それはまた別に書きます。)

一応JavaのAPIラッパーも作ったのでサクッと試したい場合は使ってみてください。

https://github.com/shunjikonishi/hypdf4j

ちなみにHeroku上ではOpenJDKだからなのか、キーストアをHerokuが独自で用意しているからかわかりませんが証明書のインストールは不要です。

ちなみにちなみにPDF生成以外にも

• PDFのプロパティ情報取得(pdfinfo)
• PDFのテキスト取得(pdftotext)
• PDFの連結(pdfunite)
• 複数ページのPDFから指定ページの抜き出し(pdfextract)

といったことが(APIラッパーでも)できますが、多分そんなに使うことはないです。(^^;

★PDFの日本語出力は必ずはまることになっている

そして、とりあえず試しに作ってみたPDFがこんな。

。。。
あー、うん。。。。この豆腐見慣れてるなぁ。。。(--

思い出したけど、自力でPDF生成を試みた時も日本語フォントで挫折したんだった。。。。
PDFを生成するホストに日本語フォントをインストールすれば出力することはできるんだけど、ライセンス関係がどうなっているのかがイマイチ確信が持てなくて結局棚上げにしたような気が。

これはアカンかもなぁ。。。と思いつつ、一応サポートに日本語出ないんだけどと投げてみました。
で、その間にDocRaptorの方も試してみるかとドキュメントを読んでたらなんと20分後には返事が来ました。

早っ！！

You can use any custom font by including it with @font-face in your styles:

@font-face {
    font-family: MyFont;
    src: url(www.somecdn.com/my_font.ttf);
}

body {
    font-family: MyFont;
}

な・る・ほ・ど！！！
ここでWebフォントなのか！！！！

Webフォントって図形文字や凝ったデザインの文字を使う場合に使用するものというイメージでしたが、探してみるとIPAフォントとか標準的なものもあるんですね。

IPAフォントを組み込んで出力してみると日本語も正しく出力されるようになりました。素晴らしい！(^^v

PDFのフォント問題って世界中の開発者が頭を抱えてる問題のような気がしますけど、これはかなり見事な解決方法だと思います。
心の底から感心しました。

★excel2canvasと組み合わせてみる

ところで僕はexcel2canvasというHTMLのCanvasを使ってExcelをブラウザ上で表示するというライブラリを作ってたりするんですが、それとHyPDFを組み合わせた場合どうなるかということが気になってちょっと試してみました。

Canvasへの描画はちょっと厳しいんじゃないかと事前には思ってたんですが、試してみると結果はこんな感じ

凄っ!!!
思った以上にイケてるやんけ！

何パターンか試してみたところ、HyPDFはHTMLの横幅に合わせてスケールを調整するらしく、幅がExcelの標準レイアウトで1ページに収まらないようなものはレイアウトが崩れますが、印刷前提でレイアウトが調整されているようなExcelファイルはだいたい良い感じに出力されました。(^^v

今時のExcelはファイルをHTML形式で保存できたりもしますが、Webフォントへの変更とかそれなりに手間だったりもするので、これはこれでアリなソリューションだと思います。

勢い余ってデモサイトも作ってみたのでご興味ある方はお試しあれ。

http://hypdf-excel.herokuapp.com/

ていうか、これこのままHerokuアドオン化しても需要ありそうじゃね？(^^;

になったようです。

https://blog.heroku.com/archives/2014/7/7/websockets_now_ga

めでたい。(^^v

今後は「heroku labs:enable websockets」としなくても標準でWebSocketが使えます。

Router自体が新しいものに置き換わるようで、上記のアナウンスブログからリンクされているImproved Routerのドキュメントはなかなか読みごたえあります。

Routingや接続過多の場合のキューイング方法などについても詳しく説明されており、高負荷なアプリケーションを開発している人には必読のドキュメントだと思います。

要約しようかと思ったけど、100 Continueのあたりがよくわからなかったので止めた。(^^;

ほとんどは前にもどこかで書いたことのある話だったし。

一個だけ、へぇ、と思ったのはRoutingのところにあったこの一文。

Inbound requests are received by a load balancer that offers HTTP and SSL termination. From here they are passed directly to a set of routers.

SSL terminationをするLoad Balancerと各Dynoにリクエストを割り振るRouterは別モノだって。少なくともssl:endpointを有効にした場合はそうなっているっぽいと思ってたけど、ちゃんと文書で読んだのは初めてかも。

昨日は午後から半日FlyDataのセミナに行ってきました。
体調も微妙だったので正直半日セミナは辛いなぁと思ってたんですが、なかなかどうしてかなりアタリのセミナでした。
RedshiftもFlyDataも2、3の飛ばし記事を斜め読みしただけのエンジニアがそれらをなんとなくわかった気になるには十分な内容でした。

★ Redshiftとは

Amazonが提供するビッグデータのエンジンです。
ローンチは2013年2月。既に60以上の新機能追加が行われており現在Amazonがもっとも気合を入れて作りこんでいるプロダクトと言っても良いと思います。
その特徴としては以下があげられます。

• 速い
• 安い
• SQL互換

ビッグデータの分野ではHadoopが有名ですが、後発なだけあってそれよりも速度、価格の両面で大きな優位があります。
また、検索インターフェースがPostgreSQL互換なので使いなれたSQLがそのまま使えることも魅力です。
PostgreSQL互換なので既存のBIツールの多くがそのままRedshiftでも使うことができます。

技術的にはカラムナデータベース(列指向DB)の上に超並列処理(MPP)アーキテクチャと呼ばれる技術が採用されており、ノードを追加すると線形にパフォーマンスが向上するという特徴があります。

アーキテクチャはビッグデータに特化しており、数十GB程度までのデータであればRedshiftよりも高速に捌くプロダクトはたくさんあります。
ですが、それらのプロダクトではデータ量がテラバイト、ペタバイト単位になった場合にパフォーマンスが指数関数的に劣化し、それに対する解決策がほとんどないのに対しRedshiftはノードを追加するだけで必要なパフォーマンスを得ることができます。

検索性能のトレードオフとして更新性能(特に1行単位のデータ更新)は極めて遅いです。

★ FlyDataとは

Redshiftの現状の機能と新機能追加の力配分は大きく検索系の処理に傾けられています。言い換えればデータ投入の部分はあんまり使いやすくないにも関わらず、それほど大きな改修は行われていません。

そこを補完するのがFlyDataです。
FlyDataはRedshiftへのデータ投入のインターフェースとして以下の二つを提供します。

• JSONログ
• RDB(MySQL)とのレプリケーション

JSONについては最近Redshift本体にも取り込み機能が追加されたようですが、使い勝手の面ではまだまだFlyDataに優位があるようです。

また、Redshiftはメンテナンスのために定期的に更新処理が停止されるらしいんですが、その間の更新データのバッファリングもFlyDataがよしなにやってくれます。

□□□□
というのが、現状の小西の理解(THE にわか知識)ですが、多分そんなに大きくは外してないと思います。(^^;;;

★ 特別講演: モバイル＆クラウドでビッグデータをイノベーション基盤に

今回のセミナでは最後に特別講演としてNTTドコモ 栄藤氏によるビッグデータ活用に関する講演が行われました。

Redshift、FlyDataに関する講演が知りたいと思っていたことを知れたという意味で満足度が高かったのに対し、この講演は今まで考えもしなかったような視点に気がつかされたという意味で大変有意義でした。

この日の公演は7月17日のAWS Summitで栄藤氏が行う話の予告編的な位置づけだったようで、スライド等は公開されていないようですが非常にエキサイティングな内容でした。
本講演を聞きに行けないのが無念です。(^^;

その要旨を一言でまとめると

ビッグデータの解析は莫大なデータの中から平均的なトレンドを発見するために行うものではない。

というものです。
そういうことがやりたいのであれば、全データを解析する必要はなくサンプリング調査で十分なんだそうです。実際、精度もほとんど変わりません。

そうではなくて、ビッグデータの意義は

莫大なデータの中から異常なトレンドをすくい上げることにある。

というお話が深く心に刻まれました。

例えば、Twitterの膨大なツィートの中である特定の1時間だけ「docomo」「携帯」「スマホ」みたいな単語を含むツィートが極端に多かったとします。

そのデータからdocomoのサーバで障害が発生していた時間がほぼ特定できるそうです。(^^;;;(もちろんauやsoftbankでも同じです。)

これに位置情報も加われば、地理的時間的な異常を検出できるので確かに今までとは違う世界が開けるかもしれません。

かえすがえすAWS Summitに申し込んでなかったのは不覚です。。。。(--

ども、小西です。

最近アプリ開発はもっぱらPlay2 + Gruntの環境で行っています。

Playにはassetsコンパイルの機能もあるので当初はそれを使っていたんですが、SinglePageAppの場合、どうしてもJavaScriptのコード量が大きくなるのでファイル分割とかしたくなるんですよね。

それで思い立ってGruntを導入したわけですが、これがなかなかいけてます。(^^v

勢い余ってGrunt超入門というスライドも書いたのでこれから導入される方はご参考に。

http://shunjikonishi.github.io/slides/grunt-introduction/index.html

今のところ使っているのは主にjsの連結、ミニファイ、文法チェックぐらいですが、おいおいその他のタスクも導入していきたいと思います。

ていうか、自分でなんかタスク作りたいなぁ。。。

watchが軽くて超絶便利なので、汎用タスク以外にもプロジェクト固有タスクを作るとか色々と使い道がありそうです。

★ Heroku連携での課題

さて、このPlay2 + Grunt開発。

ローカル開発時には特に不満はないんですが、Herokuで動かす場合には一つ大きな課題を抱えていました。

というのは、HerokuのbuildpackではGruntタスクが動くわけではないのでGruntで生成するファイル(連結とミニファイを施行したファイル)は、そのままだとSlugに含まれないのです。

この課題を解決するための一番安直な方法として昨日まではGitリポジトリにGruntで生成したファイルもコミットしていたんですが、この方法は本来バージョン管理の対象ではないファイルまでGitに含めることになるのでイマイチです。

理屈としてはカスタムbuildpackでbuild時にGruntを実行すれば良いだけなので、絶対誰かもう作ってる奴いるだろうと思って探してみたんですが

• heroku-buildpack-nodejs-grunt
• heroku-buildpack-grunt-java

など、nodeやjavaの標準buildpackにGruntタスクの実行を追加したものは見つかりましたがscala版は見つかりませんでした。。。

ていうか、このやり方だと言語毎に専用のbuildpackが必要になるし、標準buildpack側に改修があった場合それに追随するのも面倒なのでイマイチだと思うんですよね。。。

このケースの場合buildpack-multiを使って標準のbuildpackとGruntタスクを実行するだけのbuildpackを自由に組み合わせることができた方が良いと思います。

★ 作ってみた

試しにbuildpackのmultiで

• heroku-buildpack-nodejs-grunt
• heroku-buildpack-scala

の二つを組み合わせてみたら問題なく、

• build時にGruntタスクを実行し、
• Dyno起動時にはscalaアプリを実行する（要Procfile）

アプリが作成できました。素晴らしい。(^^v

ただし、このままだとSlugの中に実行時には不要なNodeのランタイムが含まれてしまいます。(約30MB弱)

PlayのアプリはただでさえSlugサイズがでかいので、このオーバーヘッドは見逃せません。

なので、heroku-buildpack-nodejs-gruntをフォークして、

• 明らかに不要そうな行をコメントアウト
• 最後にnode_modulesフォルダと.npmフォルダを削除

しただけのbuildpackを作ってみました。

https://github.com/shunjikonishi/heroku-buildpack-with-grunt-task

buildpackの中身はあんまりちゃんと読んでないので、もうちょっと効率的な実装をすることも可能な気がしますけど、とりあえずちゃんと動いているようなので今回はこれでよしとします。

ご興味のある方は使ってみてくだされ。(^^v