Sprout Social のビッグデータへのアプローチを再発明する

Sprout Social は、本質的にデータ駆動型の企業です。 Sprout は、毎日複数のソーシャル ネットワークからの数十億のメッセージを処理します。 このため、Sprout のエンジニアは独自の課題に直面しています。非常に大量にプラットフォームに届く同じメッセージ (つまり、リツイート、コメントなど) の複数のバージョンを保存および更新する方法です。

複数のバージョンのメッセージを保存しているため、Sprout のエンジニアは 1 日に数回「世界を再作成する」という任務を負っています。これは、ソーシャル メッセージのすべての部分を 1 つの「真実の情報源」に統合するためにデータ セット全体を反復処理する必要がある重要なプロセスです。

たとえば、1 つの Twitter 投稿のいいね、コメント、リツイートを追跡します。 これまで、私たちは自己管理型の Hadoop クラスターに依存して、このような大量のデータを維持および処理してきました。 各 Hadoop クラスターは、Sprout プラットフォームのさまざまな部分を担当します。これは、ビッグ データ プロジェクトを大規模に管理するために Sprout エンジニアリング チーム全体で利用されているプラ​​クティスです。

Sprout のビッグデータ アプローチの鍵

私たちの Hadoop エコシステムは、スケーラブルで分散型の NoSQL データベースである Apache Hbase に依存していました。 ビッグ データを処理するアプローチにおいて Hbase が重要な理由は、データセット全体に対して迅速な範囲スキャンを実行できるだけでなく、高速でランダムな単一レコード ルックアップを実行できることです。

また、Hbase を使用すると、データの一括読み込みとランダム データの更新が可能になるため、順不同または部分的な更新で到着するメッセージや、ソーシャル メディア データに伴うその他の課題をより簡単に処理できます。 しかし、自己管理型の Hadoop クラスターは、災害復旧、クラスター拡張、ノード管理を手動で管理するなど、インフラストラクチャ エンジニアに高い運用コストを負担させます。

数百テラバイトのデータを持つこれらのシステムの管理にかかる時間を短縮するために、Sprout のインフラストラクチャおよび開発チームは、自己管理型の Hadoop クラスターを実行するよりも優れたソリューションを見つけるために協力しました。 私たちの目標は次のとおりです。

• Sprout エンジニアが大規模なデータ セットをより適切に構築、管理、操作できるようにする
• エンジニアが手動でシステムを所有および保守するための時間投資を最小限に抑える
• クラスタの拡張による過剰なプロビジョニングの不要なコストを削減
• より優れたディザスタ リカバリ方法と信頼性を提供する

現在のビッグ データ システムに代わるものを評価する際に、現在の処理とパターンに簡単に統合でき、クラスターを手動で管理することに伴う運用上の労力を軽減できるソリューションを見つけることに努めました。

新しいデータ パターンの代替案の評価

私たちのチームが検討したソリューションの 1 つは、データ ウェアハウスでした。 データ ウェアハウスは、データ分析と集計のための集中型ストアとして機能しますが、Hbase と比較すると、従来のリレーショナル データベースによく似ています。 それらのデータは構造化され、フィルター処理され、厳密なデータ モデル (つまり、1 つのオブジェクトに対して 1 つの行を持つ) を持っています。

多数のバージョンのメッセージが並んで存在するソーシャル メッセージを保存および処理するというユース ケースでは、データ ウェアハウスのモデルは私たちのニーズに対して非効率的でした。 既存のモデルをデータ ウェアハウスに効果的に適応させることができず、パフォーマンスは予想よりもはるかに遅くなりました。 データ ウェアハウス モデルに適応するようにデータを再フォーマットするには、タイムラインでやり直すための大きなオーバーヘッドが必要になります。

私たちが検討したもう 1 つのソリューションは、データ レイクハウスです。 データ レイクハウスは、データ ウェアハウスの概念を拡張して、構造化されていないデータ、安価なストレージ、および機密データに関する追加のセキュリティ レイヤーを可能にします。 データ レイクハウスは、データ ウェアハウスよりも多くの機能を提供しましたが、現在の Hbase ソリューションほど効率的ではありませんでした。 マージ レコードと挿入および削除処理パターンをテストした結果、バッチ ジョブで許容できる書き込みレイテンシを生成できませんでした。

AWS EMR でオーバーヘッドと維持費を削減する

データ ウェアハウジングとレイクハウス ソリューションについて学んだことを踏まえて、マネージド Hbase を実行する代替ツールを検討し始めました。 現在の Hbase の使用は Sprout での業務に効果的であると判断しましたが、「主要な使用パターンを維持しながら、Hbase をより適切に実行して運用上の負担を軽減するにはどうすればよいでしょうか?」と自問しました。

これは、Hbase 向けの Amazon の Elastic Map Reduce (EMR) マネージド サービスの評価を開始したときです。 EMR を評価するには、データ ウェアハウスやレイクハウスをテストしたのと同じ方法でパフォーマンスを評価する必要がありました。たとえば、データの取り込みをテストして、パフォーマンス要件を満たすことができるかどうかを確認しました。 また、データ ストレージ、高可用性、災害復旧をテストして、インフラストラクチャ/管理の観点から EMR がニーズに合っていることを確認する必要がありました。

EMR の機能により、現在のセルフマネージド ソリューションが改善され、Hbase で行ったのと同じ方法でジョブの読み取り、書き込み、および実行に現在のパターンを再利用できるようになりました。 EMR の最大の利点の 1 つは、ノード自体ではなく S3 にデータを保存する EMR ファイル システム (EMRFS) の使用です。

私たちが見つけた課題は、EMR では高可用性オプションが制限されていたため、1 つのアベイラビリティ ゾーンで複数のメイン ノードを実行するか、複数のアベイラビリティ ゾーンで 1 つのメイン ノードを実行することしかできなかったということでした。 このリスクは、EMRFS を活用することで軽減されました。EMRFS は、災害復旧のための追加のフォールト トレランスと、コンピューティング機能からのデータ ストレージの分離を提供します。 EMR を Hbase のソリューションとして使用することで、スケーラビリティと障害復旧を改善し、クラスターを維持するために必要な手動介入を最小限に抑えることができます。 最終的に、EMR が当社のニーズに最適であると判断しました。

移行プロセスは事前に簡単にテストされ、顧客のダウンタイムなしで数十億のレコードを新しい EMR クラスターに移行するために実行されました。 新しいクラスターでは、パフォーマンスが向上し、コストが 40% 近く削減されました。 EMR への移行がインフラストラクチャ コストの削減とパフォーマンスの向上にどのように役立ったかについて詳しくは、AWS を使用した Sprout Social のケース スタディをご覧ください。

私たちが学んだこと

このプロジェクトの規模と範囲により、私たちインフラストラクチャ データベース信頼性エンジニアリング チームは、複数のエンジニアリング チームと機能横断的に作業する機会を得ました。 挑戦的ではありましたが、共同エンジニアリング組織として Sprout で取り組むことができる大規模プロジェクトの素晴らしい例であることが証明されました。 このプロジェクトを通じて、当社のインフラストラクチャ チームは、Sprout のデータがどのように使用、保存、処理されるかについてより深く理解することができ、将来の問題のトラブルシューティングを支援するための準備が整いました。 私たちは複数のチームにまたがる共通の知識ベースを作成しました。これにより、次世代の顧客機能を構築することができます。

私たちが構築しているものに興味がある場合は、私たちのチームに参加して、今すぐオープン エンジニアリングの役割に応募してください。