(レポート)MBL314:世界レベルでクラウドにつながったワイヤレススピーカー「Sonos」を開発する #reinvent

ワイヤレススピーカーを展開している Sonos 社が行ったデータ処理パイプラインの再構築についての事例をレポートします。

MBL314 - Building World-Class, Cloud-Connected Products: How Sonos Leverages Amazon Kinesis

パイプラインを

• Collect
• Store
• Process
• Consume

という4つのフェーズに分割し、新旧アーキテクチャーが比較されます。

資料

Sonos データパイプライン V1

設計のゴール

• ユーザーがどのような音楽をどのような媒体(地元ラジオ番組など)聞いているのか
• スパイクなどがあっても、データロストしない
• パイプライン下流のデータ処理が元データを破壊的に更新しない(バックアップからのデータ再投入が可能であること)

(1)Collect : Data Collector すべてのデータを SQS に放り込む

(2)Store : Initial SQS queue キューのペイロードによって、対応する Process 用 SQS に放り込む

(3)Process : SQS queues

Consume フェーズ向けにデータ加工して送信

(4)Consume:Visualization

• Splunk
• Google Analytics

などプロプライエタリ・ソフトウェアを利用

V1 の問題点

• データをザクっと見られるようになったことで、データについてより深く知りたいという要求が社内から出てきた(導入に対して、好ましいサイクルではある)
• データソースが増えるたびに追加改修が必要(汎用的な作りになっていない)
• 費用がかかりすぎる

Sonos データパイプライン V2

設計のゴール

• 集約型のレポートからイベントベースのレポート
• どんなデータ型でも処理できる
• 生データはセキュアに保存
• 費用を削減する

パイプライン V1 のアーキテクチャーの問題

V1 Collect の問題

V1 パイプラインでは Collect フェーズが Store/Processフェーズも見越した責任範囲の広い大きな処理を行っていた。

Amazon Kinesis と Kafka の比較

Sonos は lean devops を実践 自社サービスのコアではない運用にリソースを取られたくない。一番最後のマネージドサービスを利用することが重要。

V2 Store の特徴

データはS3に保存 データレイクとしてデータをただひたすら貯めこむ。 データ構造を意識する必要はなく、処理する側が知っていれば十分。

Kinesis Record の処理に関して

kinesis Consumer library は必要な物が全て揃っている シャード・イテレーターを意識することなくデータ処理でき、 データをアグリゲートするのでスループットも上がる

我々にとって重要なのはデータ処理方法ではなく、データそのもの

V2 Process  の特徴

Spark を利用すうる データソースを指定して処理するだけ

V2 Consume の特徴

直ぐに分析結果を見れるようにする

• Splunk
• Redshift
• Kibana

等を利用

Data Pipeline v2 のメリット

• データをトレースしやすくなった
• Collect/Store フェーズの処理能力が EC2/Kinesis/S3 の追加で線形にスケール
• 費用が1/20になった

パイプラインの V1 から V2 への移行プラン

並行運用でデータの不一致を探す

V1 パイプラインのコレクトフェーズで Kinesis にデータをコピーし、V1/V2 パイプラインを並行で走らせる

V2の運用コストはV1に比べてかなり安いので、平行運用の追加コストもそれほど気にならない。

V1/V2 のベンチマーク

10億イベントあたりのV1/V2比較

処理時間については 2700% の性能向上

費用は V1 : > $5,000 V2 : $650

今後の改善点

• データパイプライン V1 を落とす
• Kinesis が落ちた時の対応。Circuit Breakerパターン
• データコレクターをC++でかき、Kinesis Produer Librarとの親和性を良くする
• EC2上で動いているSparkを　EMR に引っ越す

Final takeaways

Separation of concerns。各システムの責任範囲を明確にする 分析システムは自前で実装し、社内の要望にきめ細かにこたえられるようにする AWSのマネージドサービスを活用し、DevOpsのオーバーヘッドを小さくする

その他

Q&Aによると、リシャーディングは手動で行い、Consumer フェーズでは KCL を利用しているので、リシャーディングによるシャード変動は意識せずにすんでいるそうです。