Pinterestが課金フローのログ収集に使っているSectorをオープンソースで提供しました。KafkaからAmazon S3などの長期保存用のストレージにログを送る仕組み (構成図) ですが、Amazon S3を利用した場合も、その結果整合性（アップロードされたデータがすぐ可視できる状態にならないケース & ファイルが一旦消えたようになり後ほど復活するケースが起こりうる。）に影響うけずに、データ消失がなく、スケール可能で、日付でデータのパーティションを区切ることもできるとのこと。

その信頼性を担保できている工夫は、

• S3に書込んだデータを再度読込まないことで、結果整合性の問題を回避。Kafkaコンシューマのオフセット管理プロトコルで、何がS3にアップロードされたかをトラックしている。Kafkaが根拠となるメタデータをZooKeeperに保存し、一方、メタデータのコミットポイントはSectorにコントロールされ、かなり低い頻度（ざっと言うと、1時間でKafkaのパーティションあたり一回のアップデート。）で発生するようになっている。
• メタデータがデータと別に保存されていることは、その同期に関して複雑な問題を生む可能性がある。Sectorはこれを、データはメタデータよりも先に更新されることを担保し、決まったS3のパスを利用することで解決している。データが更新されたのにメタデータへのコミットが失敗したケースは、次のステートの更新時に自動的に修正される。

メリットをまとめると、

• 複数のマシンに分散可能。
• 負荷に対処するためにスケールさせるのは、新しいプロセスを起動するのと同程度に簡単。実行中のプロセスをkillすることで、リソースのフットプリントを減らすことが可能。増減はデータの整合性に影響を与えない。
• パーティションで分けられたS3のパスに保存され、Hiveなどでのダイレクトインポートが可能。
• サイズ単位、もしくは時間単位で、S3におけるデータの整合性をいつコントロールするか設定できる。例えば、「ローカルのバッファーが100MBになる、もしくは1時間に一回のタイミングでデータをアップロードする。」
• Ostrichでデータ監視。OpenTSDBにエクスポートも可能。
• 設定のカスタマイズで他のログメッセージパーサーも導入できる。
• Quboleに接続して、Hiveテーブルに最終的なアウトプットのパーティションを追加できる。

#pinterest #opensource #kafka #amazons3