Scribdが実践したデータ取り込みコスト99%削減術：クラウドネイティブアーキテクチャへの移行
データエンジニアリングの世界では、大規模データの取り込み（インジェスト）は常にコストと運用負荷の大きな要因です。特に、リアルタイム性を求めれば求めるほど、常時稼働するSparkクラスターなどのリソースがコストを圧迫します。
この課題に対し、Scribd社のTyler Croy氏がData + AI Summitで発表した講演「Let's Save Tons of Money With Cloud-Native Data Ingestion!」は、非常に示唆に富むアプローチを提示してくれました。彼らは、クラウドネイティブなアーキテクチャとイベント駆動の考え方を組み合わせることで、データ取り込みコストを劇的に削減することに成功しました。
本記事では、Croy氏の講演内容を基に、Scribdがどのようにして従来のSpark中心のアプローチから脱却し、コストを90%削減、さらにその2年後に追加で90%（合計約99%）ものコスト削減を達成したのか、その技術的な核心と実践的なノウハウを詳しく解説します。
背景：データ取り込みの常識を覆した2つの発見
このアーキテクチャ変革の根底には、2つの重要な気づきがありました。
1. Delta Lakeの核心は「トランザクションログ」にある
まず基本として、このアーキテクチャの主役であるDelta Lakeについて触れておきましょう。Delta Lakeは、データレイクに信頼性をもたらすオープンソースのストレージレイヤーです。その最大の特徴は、データファイルとは別に管理される「トランザクションログ（_delta_log）」にあります。このログによって、データレイク上でACIDトランザクションが保証され、データの信頼性が担保されます。
Croy氏が強調したのは、「Delta Lakeの面白い部分はトランザクションログ。データファイル自体はどこから来ても構わない」という点です。データファイルは標準的なParquet形式であり、トランザクションログさえ適切に管理できれば、それはもう立派なDeltaテーブルとして機能します。この「データファイル生成」と「トランザクションログ管理」の分離という考え方が、今回のアーキテクチャの鍵となります。
2. 主要クラウドサービスはすでに「Parquet」を話せる
Scribdが次に気づいたのは、多くのクラウドサービスがParquet形式でのデータ出力をネイティブにサポートしているという事実でした。
従来のアプローチでは、各種データソースからJSONやCSV形式でデータを受け取り、それをSparkクラスターで読み込んでParquetに変換し、Delta Lakeに書き込むという処理が一般的でした。しかし、Croy氏が調査したところ、AWS AuroraやKinesis Data Firehose、Airbyteなどが、追加の変換処理なしに直接ParquetファイルをS3に出力できる機能を持っていました。例えば、AuroraのParquetエクスポート機能は2020年から提供されています。
この発見により、「データ取り込みのために高価なSparkクラスターを動かす必要はないのではないか？」という発想の転換が生まれました。データファイルの生成は各クラウドサービスに任せ、自分たちは最も重要なトランザクションログの管理に集中すれば良いのです。
クラウドネイティブデータ取り込みを支える主要コンポーネント
この新しいアーキテクチャは、既存のクラウドサービスと、Scribdが開発したオープンソースツールを巧みに組み合わせて実現されています。
- Aurora Export: AWS Auroraからテーブルやスナップショットのデータを直接Parquet形式でS3にエクスポートする機能。バッチ処理が不要となります。
- Kinesis Data Firehose: ストリーミングデータをほぼリアルタイムでS3に配信するサービス。Parquet形式への変換もネイティブに対応。
- Airbyte: 多様なデータソースに対応したオープンソースのELTツール。S3を出力先に設定すれば、Parquet形式でファイルを配置可能。
- Kafka Delta Ingest (KDI): ScribdがRustで開発した、KafkaからDelta Lakeへ書き込む軽量ツール。Spark不使用でフェーズ1のコスト削減を実現。
- Oxbow: S3へのParquetファイル配置をS3 Event Notificationsで検知し、LambdaでDelta Lakeのトランザクションログを追記するシンプルツール。データファイル生成とログ管理を完全分離。
- SQS Ingest: SQSキューを活用し、メッセージをまとめてParquet化するLambdaベースの仕組み。データが流れていない間はコストゼロ。
イベント駆動アーキテクチャの全体像
これらのコンポーネントを組み合わせたアーキテクチャは、非常にシンプルかつ強力です。
- Aurora ExportやAirbyteなどがParquetファイルをS3に書き込む
- S3 Event Notificationsが作動し、SQSに通知を送信
- SQSメッセージをトリガーにLambda（Oxbow）が起動
- LambdaがDelta テーブルのトランザクションログにコミット情報を追記
Croy氏はメダリオンアーキテクチャの遵守、特にBronze層をAppend-Onlyに保つ重要性を強調しています。データ取り込みの入り口を追記専用とし、更新・削除はSilver/Gold層に任せることでトランザクション競合を回避。ファイル生成は各サービスに分散し、Lambdaがログ管理のみを担うため、ボトルネックが生まれにくい設計です。
Scribdが達成した驚異的なコスト削減
移行プロセスとコスト削減効果
移行は大きく2つのフェーズで進みました。
フェーズ1: SparkからKDIへ Spark Streamingベースの処理をRust製のKDIに置き換え、データ取り込みコストを約90%削減。
フェーズ2: KDIからOxbow/SQS Ingestへ コンテナ常時稼働の運用課題を解決するため、イベント駆動型のOxbow/SQS Ingestへ移行し、残存コストの約90%をさらに削減。
この結果、当初と比較してトータルで約99%のコスト削減を実現しました。
運用負荷の削減と開発アジリティの向上
特にSQS Ingestの「無負荷時コストゼロ」設計により、開発チームはインフラやコストを気にせず実験的なパイプラインを迅速に立ち上げ可能に。実験が不要になればデータ送信を停止するだけでコストは発生せず、イノベーションの加速に大きく寄与しました。
実践から得られたベストプラクティス
- メダリオンアーキテクチャを厳格に守る：Bronze層はAppend-Onlyに徹する。
- Lambdaのペイロード制限に対応：トリガー後にSQSから追加取得し、まとめてファイル化。
- JSON/CSVにも柔軟対応：一部ソースがParquet非対応でも、Lambda内でParquet変換。
- トランザクション同時実行を管理：シンプルなAppend-Onlyワークフローで競合回避。
まとめと今後の展望
Scribdの事例は、データ取り込みのパラダイムシフトを明確に示しています。データファイル生成とトランザクションログ管理を分離し、クラウドサービスのネイティブ機能を最大活用するイベント駆動型アーキテクチャは、コスト・運用負荷・開発速度の全てで従来を凌駕します。まずはご自身の組織で、データソースがParquet形式をサポートしていないかを確認し、Scribd製のOxbowなどを活用してみてはいかがでしょうか。
この手法はDelta Lakeだけでなく、Apache Icebergなど他のテーブルフォーマットにも応用可能です。クラウドネイティブ技術の進化とともに、データエンジニアリングの世界はより効率的でスマートな方向へ進んでいきます。
