Zalando が Amazon S3 でデータレイクを構築した方法



2008 年に設立された Zalando は、ファッションとライフスタイルのためのヨーロッパをリードするオンラインプラットフォームで、3,200 万人以上のアクティブな顧客を抱えています。私は Zalando のリードデータエンジニアであり、これまで会社のクラウドジャーニーに貢献してきました。このブログ投稿では、Amazon Simple Storage Service (Amazon S3) が当社のデータインフラストラクチャの要となった経緯について説明します。最初に、データの洞察を得るための Zalando のビジネスニーズと、その歴史的なテクノロジースタックがどのように異種の情報を提供したかについて説明します。次に、特にデータレイクを構築するために Amazon S3 を使用して AWS への移行を決定した方法について説明します。最後に、従業員にデータへのアクセス権を付与することから、さまざまな Amazon S3 ストレージクラスを使用してストレージコストを最適化することまで、Amazon S3 の使用法がどのように進化してきたかについて説明します。

私が共有する経験と、データ駆動型企業をマルチペタバイト規模で運営するのに役立つベストプラクティスを確立した方法を学習のお役に立てていただければ幸いです。

Zalando のテクノロジーの生い立ち

2015 年、Zalando は、大規模なオンプレミスのモノリスとして実行されている IT 環境を有するファッション小売業者でした。インフラストラクチャの主要部分は、トランザクション側でも分析側でも、直接統合され、相互に依存していました。システムの複雑さが増すと同時に、細部を追加するためのチームの数も増えていきました。その後、会社は、「単なる」オンライン小売業者からファッションのプラットフォームへと変貌を遂げることを決定しました。その目標を設定することは、スケールに向けた準備を意味していました。現在と将来のビジネスニーズを検討した結果、会社がクラウドに移行するのは論理的な決定でした。当社は、複数のクラウドプロバイダーを評価し、耐久性、可用性、およびスケーラビリティにより、クラウドプロバイダーとして AWS を選びました。また、当社が将来活用できる可能性がある、AWS が提供するサービスの広範なエコシステムも考慮に入れました。Zalando のモノリシックインフラストラクチャはマイクロサービスに分割され、分離された開発および運用スペースにおける技術ランドスケープについてのエンドツーエンドの責任を持つチームの創設につながりました。

テクノロジーインフラストラクチャの変更は、会社のデータランドスケープに直接影響を及ぼしました。多くのコンポーネントからアクセスされる中央データベースは分散バックエンドになり、通信は REST API を介して行われました。トランザクションデータストアに直接接続する中央データウェアハウスは、直接的な到達可能性を有しない分散型のデータ生成に対応する必要がありました。これらの課題を克服するために、Zalando にデータレイクを構築することを目標とする中心的なチームが組まれました (図 1)。当初のデータレイクを開始する動機は 2 つありました。すなわち、この新しい分散環境に一元的なデータアーカイブを持つことと、会社の分散コンピューティングエンジンを作成することです。

図 1: Zalando のデータレイクアーキテクチャ

リレーショナルデータベースのサイズ制限を解除した後、会社が潜在的に非常に高い価値のあるデータを生成していることがわかりました。当社には、増大するデータ量に対応できるデータストレージオプションが必要であり、当社が選択したオプションは、拡張性と信頼性を備え、手頃な料金で利用できるものである必要がありました。AWS のサービスポートフォリオを見ると、会社の新しい中央データレイクのベースレイヤーとして機能する選択肢が Amazon S3 であることは明らかでした。

新たにセットアップして空のデータレイクを開始する際の最優先事項は、会社の主要なデータソースの統合でした。その時までに、分散型マイクロサービス間の通信を行うことを主な目的とする中央イベントバスが確立されていました。2 番目の主な目的は、公開されたすべてのメッセージのコピーをデータレイクに保存するアーカイバーコンポーネントを導入することにより付加されました。主要なビジネスプロセスは既にイベントバスを介して通信していたため、そのコンテンツは分析処理にとって非常に高い価値のあるものでした。取り込みパイプラインはサーバーレスコンポーネントに基づいて構築されており、再フォーマットや再パーティション化などの基本的なデータ準備要件を満たしています。このパイプラインについては、このブログ投稿で詳しく説明しています。

以下の動画は、サーバーレスイベントデータ処理パイプラインを構築し、データをデータレイクにプッシュする方法に関する 5 分間の This Is My Architecture の動画です。

クラウドへの移行が進められている一方で、当社のデータセンターの元のデータウェアハウスに生成後に保存された貴重なデータセットはまだ大量にありました。そのようなデータセットの 1 つの例として、会社の中心的な販売ロジックが挙げられます。2 番目の中央パイプラインは、データレイクでデータウェアハウス (DWH) データセットを利用可能にする役割を担っていました。パズルの 3 番目の部分は、ウェブトラッキングデータでした。これは、生データのサイズが大きく、すでに存在するデータセットと組み合わせるとその価値が非常に高まるものでした。これらの 3 つのパイプラインにより、会社の初期のデータレイクへの安定した供給が保証されました。

S3 サービスオプションの詳細

Amazon S3 でデータレイクを継続的に成長させることで、S3 の多様な機能の使用を促進するさまざまな状況が生じました。このブログ投稿の残りの部分では、Zalando で使用されている機能について、その利点と適用可能なユースケースを含めて説明します。

データ共有とデータアクセス

大量のデータは、それを使用する人がいなければ、保存する意味がありません。そのため、当社が解決しなければならない最初の、そして最も重要な課題はデータ共有でした。Zalando では、多くのチームが独自の AWS アカウントを持っているため、アカウント間におけるデータ共有の要件を直ちに満たします。これを行う最も簡単な方法は、バケットポリシーです。バケットポリシーを使用すると、実行を許可されているいくつかのアクションが可能なプリンシパル (ロールなど) を指定するバケットに対して、直接定義をアタッチできます。このようなアクションの例としては、バケット内の特定のプレフィックスなど、特定のリソースに対する GetObject が挙げられます。これは非常に簡便に使い始めることができ、他のアカウントへの接続数が少ない場合に非常によく機能します。時間を経るごとに、ますます多くの人々がデータへのアクセスを希望するようになりました。増大するバケットポリシーの管理が少し面倒になっただけでなく、最終的にはそのサイズの上限にも達しました。

より分離され、よりスケーラブルなアプローチに変更する必要があったため、当社は IAM ロールの使用を開始しました。IAM ロールの機能は、この特定のユースケースのバケットポリシーと非常によく似ています。特定のリソースに対するアクションを指定することにより、インラインポリシーを追加します。これは、前のバケットポリシーの該当部分に非常によく似ています。唯一の違いはプリンシパルです。これは、ターゲットアカウントとの信頼関係によって解決されます。ロール自体では、信頼するアカウント番号を指定します。これにより、アカウントは作成されたロールを引き受け、それを介してアクセスを実行できます。

データのバックアップと復元

さまざまな本番環境における使用のために多くの人の間で大きなデータレイクを共有できるようにすると、次は、データのバックアップと、インシデントの場合に確実に復元できるようにすることについて考え始めることになります。これを行う最も簡単な方法は、本番バケットのバージョン管理をオンにすることです。バージョン管理により、古いバージョンにアクセスしたり、削除されたバージョンを復元したりする必要がある場合に備えて、標準の S3 API 呼び出しでは表示されない場合でも、以前のバージョンを保存できます。基本的に、各プレフィックスはオブジェクトのスタックになり、デフォルトでは最新のものだけにアクセスできます。

バージョン管理は、データパイプラインにバグが発生し、出力をロールバックする必要がある場合に便利です。さらに重要なことに、バージョン管理はデータの削除にも機能します。オブジェクトを実際に削除するのではなく、削除マーカーをそのオブジェクトのスタックの上に置き、オブジェクトを非表示にしますが、要求された場合は引き続きアクセスできます。2017 年、当社は、この機能によって救われました。新入社員が誤って本稼働データベースを削除する話は、誰でも聞いたことがあるはずです。大規模なインシデントにおいて、当社のウェブトラッキングデータのすべての履歴が削除され、テラバイト単位のオブジェクトが失われました。バージョン管理を有効にしていたおかげで、削除マーカーを削除するだけで 1 日以内にそれらすべてを復元できました。

データをバックアップするその他の方法をお探しであれば、S3 Cross-Region Replication (CRR) を検討してください。当社は、物理的に異なる AWS リージョンにデータのコピーを保存することを可能にする CRR を早期に使用し始めました。これを実装する簡便な方法は、本番バケットを別のリージョンに複製し、それをターゲットバケットのコンテンツの Amazon S3 Glacier への即時アーカイブと組み合わせることです。

ストレージコストの最適化

Amazon S3 は優れた価格モデルを持っていますが、ある時点でコスト最適化のための検討対象となります。ギガバイトとテラバイトのデータにとって取るに足らないものが、数ペタバイト規模のクラウド請求の大きな比重を占めるようになります。

これに対処するには、実際に保有しているデータを理解する必要があります。現在、当社の組織には約 400 のチームがあり、合計で 8000 を超える S3 バケットがあります。人によるインプットだけでストレージを理解することは不可能です。S3 インベントリは、設定されたバケット内のすべてのオブジェクトに関する基本情報を提供する機能です。オブジェクトのサイズや last_modified タイムスタンプのような単純なものは、データの古さと、それがコスト配分に与えている影響の大きさを示します。バージョン管理を有効にしている場合、これによって、最新バージョンではないオブジェクトの数を理解し、それらのクリーンアップをトリガーする必要があるかどうかを理解することができます。

S3 インベントリの可能性を最大限に引き出すために、S3 アクセスログと組み合わせます。この時点で、保存されたデータがコストに与える影響を認識していますが、S3 アクセスログを使用すると、ホットデータとコールドデータを区別できます。すなわち、常にアクセスされる価値の高いデータセットとは何か、また、サイズが大きいにもかかわらず、誰も読み取らないデータセットは何か、ということです。 後者は、クリーンアップ操作と影響力のあるコスト削減の明らかな候補です。

Amazon S3 には、さまざまな要件とアクセスパターンに対応するさまざまなストレージクラスがあります。S3 Standard がデフォルトのストレージクラスです。これは、最高の可用性を実現しながら、データ検索のためのコストを最も低く抑えるものです。しかし、純粋なストレージコストに関しては、より安価なオプションがあります。これは、他の 2 つの特性とのトレードオフがあるものです。S3 Standard-Infrequent Access (S3 標準 – IA) は、長い間触れられないが、(履歴データの低頻度の検索のために) 利用可能なままにしておく必要があるオブジェクトに最適なオプションです。ストレージは約 40% 安価ですが、アクセス要求のコストは約 2 倍です。S3 Glacier と S3 Glacier Deep Archive は、よりコスト効率の高いストレージクラスですが、取得速度が遅くなります。これらは、アクセスの少ない大量のデータに最適です。

ストレージクラスは、データとユースケースを正確に把握している場合にコストを削減するのに最適ですが、それらを手動で処理するのはかなりの労力がかかります。S3 Intelligent-Tiering は、事前定義された基準に基づいて、ストレージクラス間のオブジェクトの自動移行を可能にします。当社では、Amazon S3 Intelligent-Tiering を使用して、30 日以内に触れられなかったオブジェクトを S3 標準 – IA に自動的に移動することにより、ストレージコストを年間 37% 節約しています。アクセスがあれば、S3 標準に戻します。

多くのデータセットは、時間の経過とともに価値を失います。S3 Intelligent-Tiering を使用すると、データストレージの費用を節約できる一方で、時間が経過すると、適切に選択された保持時間でクリーンアップを実行することができます。ライフサイクルポリシーは、このような保持期間を設定するための優れた方法ですが、さらに多くのことを実現できます。たとえば、ストレージクラスの遷移やオブジェクトのタグ付けを定義して、今後の特別な状況下での使用に備えることができます。さまざまなユースケースの中で、当社は、法律により一定期間のみ保存できるデータセットをクリーンアップする簡単な方法として、ライフサイクルポリシーを使用しています。

まとめ

Zalando のここまでのクラウドジャーニーは、長い道のりでした。Amazon S3 にデータレイクを構築することで、組織全体の従業員は、以前はアクセスできなかったデータを使用できるようになりました。現在では複数のデータパイプラインがあり、社内ユーザーによって一元的に管理および運用されているため、Amazon S3 への取り込み量は継続的に増加しています。当社は、さまざまな Amazon S3 サービスを使用することで、ストレージコストを削減し、年間最大 40% を節約することができました。たとえば、S3 Intelligent-Tiering とライフサイクルポリシーを使用して、未使用のデータを削除する保持期間を設定しました。これにより、社内ユーザーは、当社が保存しているデータから情報を抽出して分析し、最終的に顧客が当社のウェブサイトやモバイルアプリケーションを通じて買い物をするときのエクスペリエンスを向上させることができます。

Amazon S3 データレイクを現在開始しようとしている方へのアドバイスで締めくくりたいと思います。Amazon S3 でデータレイクを構築する場合、データレイアウトを確立する方法に関して、さまざまなバケットや、バケット内のプレフィックスの選択に際して、多くのオプションがあります。結局のところ、命名および配布計画を選択することが重要であるだけでなく、その計画に従うことも同様に重要です。何千ものバケットの規模に到達したら、グローバルな管理性を保証するために、データストレージのクリーンアップと整理に多大な労力を費やす必要があります。

Zalando が最初の Amazon S3 ベースのデータレイクのセットアップを開始して以来、Zalando のデータインフラストラクチャと S3 自体の両方が大きく変化しました。当社は、過去 5 年間で、すでに利用可能となっている機能の多くを使用する機会がありました。話を 2020 年初頭まで進めると、Zalando は、ストレージの分散化を完全に採り入れており、チームは独自のバケットを使用して、一元的なガバナンスとデータ管理のアプローチを通じてデータセットを保存および共有しています。1 日にテラバイトの流入があり、合計ストレージボリュームは 15 PB で、現在も増加し続けている状況下において、当社は、新しいクラウドストレージ機能を常に評価し、データ管理に関する技術を革新しています。