フレクトのHeroku Lab

2日続けてこんにちは

今朝Heroku ヨーロッパリージョンリリースのニュースが飛び込んできました。
めでたい。v(^^)v

ヨーロッパができるなら時間の問題でTokyoにも来ると思うので、それに備えて素振りしておきたいと思います。

★リージョンの指定

単純にheroku createコマンドに「--region eu」をつけるだけのようです。

heroku create my-app --region eu

作成したアプリのリージョンを途中で変更することはおそらくできません。つまり現在USリージョンで動いているアプリをEU(あるいは今後登場が予想されるTokyo)で動かそうと思ったら新しくアプリを作り直す必要があります。

git pushはともかく、環境変数やAddonの追加まで考えると結構な手間ですが、これを簡略化するために「heroku fork」という新しいコマンドが用意されました。

forkは要するに既存のアプリをコピーして新しいアプリを作成するコマンドで、これを使用すると

• gitのコードベース
• 環境変数
• すべてのAddOn(!)
• PostgreSQLのデータ(!!)

がコピーされるらしいです。

課金AddOnは多分同じプランでコピーされるんでしょうね。実際に移行するとなるとある程度並行稼働(というよりもテスト)の期間が必要でしょうからそこは注意が必要です。

PostgreSQLのデータコピーも嬉しいんですが、並行稼働を考えるとどの道pgbackups経由のデータ移行が必要になると思われます。

逆にコピーされない情報としてはドメインの設定全般(おそらくSSLの証明書も)と、あとはPapertrail等のサードベンダー製Addonの設定情報も無理でしょうね。Papertrailでログ監視設定をたくさん設定している場合などはちょっとめんどくさいかもしれません。

DNSの設定はどうなるんだろ？？？
僕はほとんどDNSの設定を自分でやることがないのであまり知見がありませんが、Route53とかだと設定変更はすぐに反映される印象があります。
単純に新しいHerokuアプリを指すようにすれば良いだけのはずですが、既存のHerokuアプリをリネームして新しいアプリを同じ名前で作るという方法でも可能なはずです。
(直観的には素直にやる方のがリスク少ないだろうと思いますけど。)

★AddOnとか

EUリージョンにともないいくつかのAddOnもEUで動くようになったようです。

これ、すごく重要なことで例えばPostgreSQLなどはアプリがEU、DBはUSという状態で動かすとかなり悲惨なことになります。

PostgreSQLに限らず通信の発生するAddOnでは常にネットワーク遅延の問題がつきまとうので、アプリをEUで動かすなら使用するAddOnも同じリージョンで動くことはほぼ必須です。

幸いなことに僕が日常的に使用しているAddOnはすべてEUに来ています。ので、こいつらもいずれ日本に来ると信じてます。

ちなみにAddOnのリージョンはアプリのリージョンによって自動的に選択されるようですね。デフォルトはそれでまったく問題ないんですが、PostgreSQLのFollowDBなんかは違うリージョンに作りたいことがあるんじゃないの？ともちょっと思います。

★ひとつのアプリを複数のリージョンで動かす場合

単純にアメリカの人はUSにあるホストを、ヨーロッパの人はEUのホストを見るようにしてもらえと言うポリシーのようです。

それはそれで良い気がしますが、DBが別になるのでワールドワイドで単一のDBを参照させたい場合とかはちょっと難しいかもしれません。

参照専用であればFollowDBで。。。
。。。
あ、今リージョン違いのFollowは作れないんじゃ疑惑をさっき書いたばかりだった。。。(--

まぁ、いいや。多分FollowDBは時間の問題でリージョン指定して作れるようになると思うので、参照専用の場合はそれで良いとして、次に欲しくなるのはPostgreSQLの双方向レプリケーションのような気がします。

□□□□

日本にも来るのが待ち遠しいですな。(^^;

こんにちは

最近珍しくSalesforceを触っています。(FLECTではSalesforce素人の僕の方が少数派なんですが。。。)

案件需要として「RDBMSのデータを定期的にSalesforceに同期する」という要件があるのでそれが汎用的にできるツールを作成しているのです。

で、そのバックロジックとしてはBulk APIを使うのでざっと検証したその動作を書きとめておきたいと思います。

★Bulk APIとは？

大雑把に言ってしまえばCSVで作成したデータを一気にSalesforceに取り込むためのAPIです。
他にもXML形式で取り込めたりクエリでSELECTした大量のCSVデータをダウンロードしたりもできますがここでは触れません。

Salesforce識者の方にはDataLoaderが裏で使用しているAPIというのがわかりやすいでしょうか。 (といいつつ、DataLoaderはデフォルトではSOAP APIを使用する設定になっており設定変更しないとBulkAPIは使われませんが。)

★とりあえず使ってみる

BulkAPIの使い方自体はドキュメントを読めばなんとなくわかります。

簡単にまとめると

1. WebAPIのOpenJOBメソッドでジョブを開始
2. WebAPIのAddBatchメソッドでCSVファイルをPOST(複数回可)
3. WebAPIのCloseJOBメソッドでジョブを完了

ジョブの実行自体は非同期なのでAddBatchがリターンした時にはまだデータの更新は完了していません。ただしAddBatch自体がかなり重たいメソッドのようで7MB程度のファイルのアップロードで2分前後の時間がかかっています。

AddBatchからリターンした後にはまだデータ更新の途中であってもCloseJobメソッドを実行してしまって構いません。それでデータ更新が中断されるようなことはなく、データ更新終了時に自動的にクローズされます。

CloseJobを実行しなかった場合、ジョブは一週間オープンしたまま残ります。(とドキュメントに書いてあります。)

クローズした後でもJobのステータスは確認できるのでAddBatchが終わったらさっさとクローズしてしまった方が良いです。

★ジョブの実行結果の確認

ジョブのステータスの確認はWebAPIでもできますが、Salesforceの画面上で行う方が簡単です。

    設定 ＞ 管理者設定 ＞ 監視 ＞ 一括データ読み込みジョブ

の項にジョブの状況確認画面があります。

この画面では処理に成功したレコードが何件あるか、失敗したレコードは何件あるかと言ったサマリ的な情報を確認できる他にバッチの「結果を表示」を実行することで処理を行った全レコードについて

• レコードのID
• 処理に成功したかどうか
• 処理内容はInsertかUpdateか
• エラーがあった場合そのエラーメッセージ

が、CSV形式で確認できます。

★エラー時の動作検証

さて、このBulkAPI。正常ケースは特に迷うところはありません。
API実行しました。データ入りました。以上終わり。です。

ここではガバナ制限やレコードデータの不正などエラーケースについてどのような動作をするかを検証していきたいと思います。

ちなみにテストはDeveloperEditionを使用して1万5000件くらいのデータを使用して行いましたが、その環境は現在こんなことになっています。

ストレージ使用量600%です。(^^;;;
BulkAPIでもディスク容量のチェックはもちろん行われますが、ジョブの実行中はしばらく容量超過に気が付かないようで、100%を越えてもしばらくはデータがInsertできます。

バッチの途中からでもエラー(ストレージ超過)になることはあるので、どういうタイミングでチェックが行われているのかは謎ですが、これはそういうもののようです。

まぁそうでなければ今回のテストはほとんど実行できなかったので良いのですが。(^^;;
ちなみにこれだけ容量を超過していてもBulkでのUPDATEは問題なく実行できます。(INSERTはもちろんエラーになりますが。)

以下、今回チェックしたエラー時の動作です。検証はBulk APIのドキュメントにあるLimitsを超過したケースといくつかのレコードエラーについて実施しました。

AddBatchのファイルサイズが10MBを越えていた場合

この場合、AddBatchのレスポンスとしてHttp status「400 BadRequest」が返ってきます。当然バッチはジョブに追加されませんし実行もされません。

CSVに1万1行以上のレコードがあった場合

AddBatchには成功し、バッチジョブも実行されます。ただし、1万行を越えたレコードについては無視されて処理が実行されません。
実行結果を確認すると、「失敗したバッチ数」はカウントアップされていますが、「レコードの失敗」には無視されたレコードはカウントされません。

CSVに1000万文字以上の文字があった場合

未テストです。日本語データを含む場合1000万文字は確実に10MBを超えると思われるのであまり意味がありません。

1フィールドに32000文字以上の文字があった場合

AddBatchには成功しますが、バッチ処理全体が実行されません。例えば1行だけにエラー行があって他のレコードには問題がない場合であっても1行も処理は実行されません。

エラーのない行については処理してくれても良さそうなものですが。。。LongTextの上限が32768文字であるにも関わらずここでの制限が32000文字であることも謎です。

CSVに5000フィールド以上あった場合

未テストです。。。(--

ネタとしてMetadataAPIで5000フィールド作ろうかとも思いましたがやっぱり面倒なので。(^^;;;
BulkうんぬんよりもSalesforceの設定画面の方が先に限界を迎えそうな気がします。

1レコードに40万文字以上あった場合

これも未テストです。。。(--

一般的なスキーマでテストしようとすると先に1フィールド32000文字の制限に引っ掛かると思うので。
おそらく結果は1フィールドの超過の場合と同じだろうと予想しています。

テキスト項目サイズ超過(256文字)のレコードがある場合

そのレコードだけがエラーになります。

エラー内容はジョブの確認画面からダウンロードできる結果CSVで行単位に確認できます。

選択項目に未定義の選択値がある場合

エラーとはならずそのまま更新されます。

予想としてはエラーになると思ったんですが、識者に確認するとこれはそういうものらしいです。。(--

メール項目に不正なメールアドレスがある場合

そのレコードだけがエラーになります。

エラー内容はテキスト項目サイズ超過の場合と同じように確認できます。

基本的にはレコードのエラーはその行だけがエラーになると考えて良さそうです。
(選択項目の挙動がイマイチ納得いきませんが。。。)

★Bulk APIの運用方法

ここまでの結果から、なんとなくCSVを作成してとりあえず投げてみて結果はジョブ確認画面で確認。で十分な気がします。

レコード数超過だけは半端な結果になるのでCSV作成時に10000行を越えないことだけは注意した方が良いですが、それ以外のケースはエラー確認後にCSVを修正してリトライで十分な気がします。

レコードの項目エラーについてもSalesforce側でちゃんとチェックしてくれるので、事前にチェックする必要性はあまり感じません。(メールアドレスなんかは事前にチェックしたとしてもチェック内容が同じかどうかなんてわかりませんし。。。)

□□□□

そんな感じでRDBからのSELECT結果をなんとなくBulkで突っ込むツールがもうじき完成します。(^^;

こんにちは

Herokuのログ解析をするツールを公開しました。
紹介スライドはこちら。これ以上ドキュメント的なものを書く予定はないのであしからず。(^^;;;

(聞かれたことには答えますけど)

★何ゆえの公開？

FLECTは基本SIを生業とする会社なのですが、僕はその中で一人R&DチームとしてSI案件には深く入り込まずに比較的自由に色々なことをさせてもらっています。(非常に感謝しています。)

その業務のひとつとして、自社内の業務で共通的に使用できるツールあるいはライブラリの作成と言うのがあるのですが、これらは可能なかぎりソース公開した状態で作って行こうかと思っています。

そうしようと思った理由は大きく3つあります。

1、もはや社内ツールやライブラリは企業にとっての強みとなりえない

世は大オープンソース時代です。

ある日誰かがこんなことしたいなぁ、と思ったとして最初にやることはまず検索。そして恐ろしいことに大抵のモノは見つかります。

もちろん、SIという業種においてはそれですべてが賄えるということはまずないので、それで仕事がなくなることはないのですが、少なくともSI屋にとっては部品は作るものではなく拾うものであるというのが個人的な認識です。

という、社内での自分の立位置をいきなり全否定するような現状認識がまずありまして。。。(^^;
要するに自分の作るようなものは多分どこかで誰かが似たようなものを作っているだろうし、仮になかったとしてもすぐに同じものが作れちゃうだろうと思う訳です。

だからと言って自分の仕事には価値がないと思っているわけでは全くないので念のため。Closedでやることに意味がないと思っているだけでむしろ部品屋の需要と価値は高くなっているはずです。そして中の人がそれを作っているということは大きなアドバンテージになると思っています。(まぁ、もちろん作るモノにもよるわけですが。。。)

2、100%を目指さないという実験

この業界にいる人なら誰もが気が付いていることだと思いますが、8割の完成度のものを作るのは比較的簡単です。今回のログ解析ツールなどもまさに8割程度の完成度だと思います。

8:2の法則という言葉もある通り、ほとんどの場合残りの2割を埋めるために多くの時間が費やされていると思います。

逆に言えばこの2割をカットすればもっとずっとアウトプットは多くなるはずです。

業務アプリであれば、それは許されないことですがこれから作成しようと思っているものについては少なくとも当面は最後の完成度をあげていくことよりもアウトプットの量を増やすことに比重を置きたいと思っています。

ぶっちゃけた話僕にとって詰めるのが辛い最後の2割とはほぼUIです。。。(--

3、Herokuでお手軽アプリ

今回のログ解析ツールは

1. git clone
2. Herokuにpush
3. いくつかの個人用のconfigを設定

するだけで動きます。

こうしたスタイルでのリリースはHerokuがなければあり得なかったことです。こういうアプリは面白いと思うし、もっと増えると良いなと思う訳です。

何よりすごいのはこの程度のアプリであれば無料で動かせるということですね。(^^;

□□□□

そんな感じで今年はちょっとアウトプットを増やそうかと思ってます。(^^v

ログ解析ツールについてはScalaのことも書きたいんですが、それはまたいずれ。

こんにちは

Heroku meetup #8に行ってきました。
てか、WAZAレポとLTでしゃべってきました。(^^;

久々に人前で喋ったのとMacでプレゼンやったのが初めてだったのとでかなりテンパリましたね。(--
もうちょっと素振りしてから望むべきでした。あいすいません。m(_ _)m

僕のことはともかく内容的にはかなり面白いミートアップだったと思います。
以下内容を振り返ります。

★オープニング

まず最初にHerokuの相澤さんによる３つのフィーチャーピックアップがありました。

1、PostgreSQL 9.2のこと

ちょっと前にPostgreSQLを9.1から9.2にアップデートするエントリを書きましたが、現在はオプション付けずとも9.2になるそうです。めでたい。(^^v

実は昨日たまたま新しくHerokuPostgresを追加する機会があったんですが、これのバージョンを確認すると9.2.4になってました。(もっとも、この時は「--version=9.2」をつけて追加しましたけど)

これを書きながらPostgreSQL本家に最新版のバージョンを確認しに行ったんですが、、お、最新版のバージョンも9.2.4。。。

。。。あれ？？？

リリース日 2013年4月4日！！？

昨日やんけ。。。。

気になって他のアプリのPostgreSQLバージョンも確認したところ、9.2系はすべて9.2.4に、9.1系はすべて9.1.9(9.2.4と同時リリースの9.1系最新版)になっているようです。

あ～、数日前にHerokuからDBメンテナンスのアナウンスが来てたのはこれかぁ。。。
リリースアナウンスに

These releases fix a number of bugs in previous releases, including a serious security issue.

Users are strongly advised to upgrade as soon as possible.

とあるからセキュリティ上の問題で緊急に全部のDBをアップデートしたのね。。。

しかし、それにしても素早い！
逆算すると完全に本家のリリースよりも先に作業してるよ。(^^;;;

HerokuのPostgreSQLへの力の入れ具合がわかるというものです。
JavaはいまだにJava6がデフォルトなのにね。(--

2、2X Dynoのこと

メモリが従来の2倍(1024MB)のDynoが使えるようになるということです。

これは正直かなり嬉しい！！！

Javaでアプリを作っているとやっぱりどうしてもメモリは食うので。(R14 Memory quota exceededの警告ログが延々と出続けるのは日常茶飯事)

お値段も2倍ですが、これは多分使います。(^^v

現在ベータ版扱いだそうでまだ一般ユーザーには公開されてないとのことでしたが、僕のHerokuコンソールには普通に設定UIが表示されてますね。周囲の同僚も同様。パートナー企業だからかな？

3、OAuthのこと

HerokuがOAuthのサービスプロバイダになるそうです。

つまり自分の作ったアプリからHerokuアカウントで認証して許可をもらったあれやこれやの情報をゴニョゴニョするようなアプリを作れる。

.。。。と、いうことはわかるんですが、正直Herokuアカウントにひもづく情報はそれなりに機密性の高い情報ばかりなんじゃないの？という気がしていて何が認可対象になるのかイマイチぴんときてません。

例えば僕は現在社内需要からS3にあるPapertrailのアーカイブログをダウンロードして解析するアプリを作ろうかと思っていますが、こういうのはコンシューマアプリの候補になりえるのかな？

まだまだ絶賛開発中らしいので当面は静観ですかね。

★Treasure Data

さてお次はTreasure Dataの中川さんのセッションです。

最近なにかと話題のBigDataを扱う快進撃ベンチャー。

Herokuとの連携はprintlnでJSONを標準出力に書けば良いだけなのでとてもお手軽です。ていうかこれ以上簡単にしようがないですよね。(^^;

僕は最近評価目的で無償版を入れましたけど、中の人に「使うかどうかわからないけどとりあえずデータを突っ込んでおくという使い方はアリなの？」と尋ねたところ「よっぽど行儀の悪い使い方をしない限り全然OKです。」という回答だったのでしばらくアクセスログ的なものを突っ込んでみようかと思ってます。

ちょっとでも開発コストがかかるならこういう使い方はしないですけど、まぁprintlnだけですしね。(^^;;;

ちなみにもうじきPigにも対応するらしいです。

★WAZAレポ

そして次は僕も含む4人のWAZAレポート。

僕自身は向こうで演者の人達とだいたい一緒に行動していたのでうんうんという感じでしたがWAZAというイベントとHerokuという会社のことが少しは伝わったでしょうか？

皆さんと僕自身も何度も言っていましたが、一番重要なことはHerokuという会社がものすごくオープンでフレンドリーだと言うことです。ブラックボックスが少ないということは開発者にとってとてつもないメリットだと思います。

そしてもう一つ重要なことはランチの行列はなんとかすべきだということです。

★ライトニングトーク

鬼畜相澤の無情の3分制限をかけられたライトニングトーク(^^;;;

僕はそれ以前に初めてプロジェクタにつないだMacの画面が小さすぎて下の方が全く見えないという残念感で説明するのをあきらめたところがあるんですが。。。(--

あんなんで果たして内容伝わったかな？？？(^^;;;
ベースとなる技術のソースはGitHubにあって、何ができるかを解説したスライドも書いたんで興味ある方はご覧になってください。

今のところこの先どうするというあてはありません。(爆)

##追記

PostgreSQLの話はherokuのblogで公式アナウンスがでてますね。

https://blog.heroku.com/archives/2013/4/4/heroku_postgres_databases_patched