Depop が AWS を使用してデータスワンプ (沼) を脱し、データレイク (湖) へと改善した方法とは

今回のゲスト寄稿者は Depop 社のリードプラットフォームエンジニア、Alexej Tessaro 氏です。

2011 年に PIG Magazine および RETROSUPERFUTURE サングラスの共同創業者である Simon Beckerman が設立したロンドンベースのスタートアップ企業、Depop は友人やインフルエンサーがその瞬間に掘り出したものをベースとしたユニークなアイテムを顧客が売ったり、買ったり、発見したりできるソーシャルマーケットプレースを提供しています。

こうしたネットワークは必然的に大量のデータを生成します。アプリ上では刻々とユーザーが互いにフォローし、メッセージを送り、新しい商品が公開、販売され、そうした商品に対しコメントやいいねなどのリアクションが起きています。Depop ではそうしたデータをすばやく効率的に処理できなければなりません。なぜならこうしたイベントのひとつひとつが、ビジネス戦略、運営、マーケティング、商品開発、その他の活動において、十分な情報を得たうえでの決定を下すのに欠かせない極めて貴重なインテリジェンスをもたらすからです。

これを実現するため、私たちはビジネス構造とニーズをサポートするデータアーキテクチャを定義し、Depop が機能するためのこうしたコンポーネントのパフォーマンスや可用性に影響を及ぼさない、信頼性と回復力があり高パフォーマンスなデータパイプラインを構築する必要がありました。

背景として、私たちは元々、プライマリデータストア、特に、リレーショナルデータベースとキーバリュー型データベースしか持っていませんでした。商品情報を必要としていた組織のすべてのチームがそうしたデータベースに負荷のかかるクエリを実行していました。当社のマーケティング、運営、製品チームはユーザーのアクティビティをモニタリングし、統計的なインサイトを収集し、負荷の掛かる複雑な SQL クエリを実行するビジネスインテリジェンスツールを使用していました。その一方で、当社のユーザーは iOS や Android のアプリ、また当社のウェブサイトを利用していました。

これではわざわざ障害を起こそうとしているようなものです。実際に、この (非) アーキテクチャのせいで私たちはたびたび機能の停止を経験しました。さらに、着々と増え続けるユーザーベースも重なり、データレイヤへのアクセスをスケーリングすることはさらに困難になったのです。最終的にチームはデータレイクの概念を採り入れることを決め、その後、スキーマの更新を望んではいませんでした。当社のビジネスストラクチャとニーズをサポートするデータアーキテクチャを定義する間に私たちが学んだことについて詳しくは、こちらをご覧ください。

このブログの作者：ミシェル・クン – Michelle Kung

ミシェルは、AWSのスタートアップマーケティングチームに所属し、コンテンツ制作を率いています。AWSに参加する前は、Index Venturesのコンテンツリードとして活躍していました。それ以前には、The Wall Street Journalにおける貴社および編集者を経験、Huffington Postのビジネス記事編集者、THe Boston Globeの特派員、Publisher’s Weekでのコラムニスト、Entertainet Weeklyにおけるライターの経験を持っています。