PinterestにおけるApache Kafkaのスケールアップ

Pinterestでは、リアルタイムストリーミングアプリケーションのデータ転送やロギング、監視のためのメトリクスの可視化にApache Kafkaを採用している。AWSにホストされているPinterestのKafkaインストレーションでは、レプリケーションと高可用性のためにMirrorMakerとDoctorKafkaツールが使用されている。

PinterestのKafkaインストレーションは2,000以上のブローカを実行している、と同社の技術リーダであるYu Yang氏は記している。処理メッセージ数は1日8億以上で1.2ペタバイトに達し、3つのAWSリージョンに展開されている。同社の主要なKafkaツールセットの中には、KafkaのMirrotMakerと同社独自のDoctorKafkaが含まれている。MirrotMakerはソースクラスタからのデータをコンシュームし、ターゲットクラスタにパブリッシュすることで、効率的にソースクラスタのレプリカを生成する。Pinterestのチームではこれを使って、3つのAWSリージョンにデータを展開している。ブローカの大半はus-east-1にあるが、最も古いAWSリージョンであるための問題も抱えている。各クラスタのKafkaブローカは3つのアベイラビリティゾーンに展開しており、トピックパーティションのレプリカをそれぞれのゾーンに分散させることで、最大2つのブローカの障害に耐えることができる。

Kafkaブローカの障害は珍しいことではない。ダウンしたブローカを置き換えてワークロードを再調整するためには、“パーティションの再配分ファイルを慎重に作成および修正して、Kafkaスクリプトコマンドを手動で実行する必要がある”、とYang氏は以前の記事に書いている。その結果生まれたのが、これらのステップを自動実行するオープンソースツールであるDoctorKafkaだ。DoctorKafkaは障害を検知し、健全なブレーカにワークロードを自動的に割り当てる能力を備える。基本的にはマスタ/エージェントモデルを採用しており、各ブローカ上でエージェントが動作して収集したメトリクスを、中央のマスタサーバが解析して障害を検知し、適切なアクションを行うコマンドを実行する仕組みだ。DoctorKafkaは、信頼できる場合にのみ修正操作を行なうという意味において“保守的”であり、それ以外の場合にはアラートを送信する。Kafkaデプロイメントの大部分では、MirrorMakerあるいは同様のツールによるレプリケーション策を採用している。

PinterestはKafkaをAWS d2.2xlargeインスタンスで運用している。Yang氏によると、EBSコンテンションに起因するパフォーマンス上の理由により、st1 EBSディスクにスループットを最適化したc3.2xlargeから、ローカルストレージを備えるd2インスタンスに移行したのだという。しかしながら、他のベンチマークでは逆の結果も報告されている。Kakfaは同社のロギングインフラストラクチャのバックボーンも構成しており、1日に100テラバイト以上のデータを処理する。サービスがディスクにデータを書き込むと、Singerと呼ばれるログエージェントがそれをピックアップしてKafkaに書き込む。もうひとつのカスタムツールであるSecorは、KafkaからログメッセージをピックアップしてS3に永続化することで、“Kafkaの貧弱な結果整合性モデル”を克服するためのものだ。

将来的にPinterestでは、いくつかの他企業ですでに実施しているように、Kafkaデプロイメントの抽象化レイヤとしてKubernetesの利用を検討している。同社のサービスの一部はすでにコンテナに移行している。もうひとつの目標は、新しいEBSサービスの最適化が改善されたことを受けて、ストレージとして再度EBSを検討することだ。