なにがでるか

少し前からSendGridのイベントデータの突っ込み先として Azure DocumentDB が使えないか調べていたところ、しばやんさんがこんなツイートしているのを見かけました。たまたまだったのですが、ちょうど突っ込む部分ができたので GitHub に上げておきました。 SendGridのイベントデータはEvent Webhookという機能を使って取得します。全てのイベントデータを自由に扱うために不可欠な重要な機能なのですが、取れるデータがスキーマレスのJSON形式のデータなので、いわゆるRDBに突っ込もうと思うとそれなりにスキーマの調整に手間がかかります。 こういうデータの保存先としては、 MongoDB （特に MongoLab → 最強 ）や Treasure Data なんかが相性がいいわけですが、ちょっと前にAzureでDocumentDBというサービスが追加されたとのこと、ちょっと出遅れた感はありましたが、丁度良い機会だったので試してみました。 DocumentDBのガイドをみると興味深い特徴がいくつもあります。 スキーマレス JSON REST API トランザクション ストアドプロシージャ トリガ SQLクエリ MongoDBっぽい使い方ができて、MongoDBがカバーしていないところをカバーしようとしている雰囲気が伺えます。いかにもMS様っぽい登場のしかたですね。 パッと見、この特徴だけ見るとSendGridのイベントデータをREST APIを使ってそのまま突っ込めばトランザクションも効いてトリガも使えて最強かっ！！と期待したのですが、残念ながらそんなに話はうまくいかなかったので、その辺中心にポイントとなる箇所をまとめてみます。 配列を受け付けてくれないREST API REST API を見て気になったのが、データを生成する際は配列を渡せないこと。 Create a Document では一つずつ渡すインターフェイスなんですね。 SendGrid側は基本的にイベントデータを配列で渡してくるので、REST APIでデータを突っ込もうと思ったらこのAPIを配列長分繰り返し呼ばなくてはいけません。パフォーマンス的に無理があるというのは直感的に想像がつきます。 認証に一手間必要なRES

はじめに メール関連の仕事をしていると、自分が受け取ったメールがどのサーバ（もしくはサービス）を経由して送られてきたのかがとても気になります。新しいメールが届く度、ヘッダを見ては「あーSESかー」とか「へーMandrillかー」とか「おっSendGrid！」といった感じで本文よりよっぽど楽しい場合もあったりします。でも、毎回生のヘッダを見るのはいい加減面倒になってきたので、もうちょっとマシな方法を考えてみました。 メールヘッダ SMTPというプロトコルはヘッダに経由情報が付加されていくという妙な性質を持っています。こういった振る舞いをするプロトコルって他にあるんですかね？あまり思い当たりません。元々、経由情報は正常にリレーされなかった場合のトラッキングが目的だったりするわけですが、様々な情報が得られるので意外と興味深いものだったりします。 経由情報を可視化する こうした経由情報ですが、正直見やすいものではありません。 Received: from [127.0.0.1] (localhost [54.64.73.243]) by ismtpd-047 (SG) with ESMTP id  14abd28c69e . 67a6 . 2d8d  for @yyyy.jp >; Tue, 06 Jan 2015 02:52:54 +0000 (UTC) この場合、ismtpd-047というホストがlocalhost [54.64.73.243]というホストからESMTP経由でメッセージを受け取ったよ、ということを表しています。 ルール を知っていれば読めるわけですが、実はフォーマットの自由度が高くて、この仕様決めた奴を一発ぶん殴りたくなるくらいフリーダムです。 せっかくこういった情報が公開されているわけなので可視化したら何か見えてこないかなー、と思っていたところ、以前から使ってみたかった Neo4j のことを思いつきました。Neo4jはグラフDBという類のDBで、Webベースの可視化機能も利用できるのでお手軽そうです。 システム構成っぽいやつ 受信したメールのヘッダを解析してNeo4jに突っ込む方法ですが、今回は、メールを受けるのにSendGridのParse Webhookを利用してみました。 普段使っているGmailに届