Hadoopをクラウドに移行: ストレージ容量が2倍に、運用コストが削減

チュートリアル
Hadoop

Yimianは、デジタル商取引データに特化したAIドリブンのデータ分析プロバイダーとしてリーディングカンパニーです。ビジネス戦略、製品開発、デジタル商取引運用に関するリアルタイムの洞察を提供しています。カスタマーには、ロータリーケア、メイクアップ、F&B、ペット、自動車などの業界リーダーが多く、P&G、Unilever、Marsなどが含まれます。

当社のオリジナル技術アーキテクチャは、オンプレミスのデータセンターで構築されたCDH（Cloudera Distributed Hadoop）を使用したビッグデータクラスターでした。ビジネスが拡大するにつれて、データ量が大幅に増加しました。

スケーリングサイクルが長く、コンピューティングとストレージリソースが一致しない、メンテナンスコストが高いなどの課題に対処するため、データアーキテクチャを変革し、クラウドへの移行を決定、ストレージとコンピューティングの分離アプローチを採用しました。慎重な評価の後、Alibaba Cloud Elastic MapReduce（EMR） + JuiceFS + Alibaba Cloud Object Storage Service（OSS）に移行しました。

現在、JuiceFSを使用して、コンピューティングとストレージの分離されたアーキテクチャを実装し、総ストレージ容量を2倍にしました。特に、パフォーマンスへの大きな影響は観察されず、運用コストは大幅に削減されています。

この記事では、Hadoopをクラウドに移行するためのアーキテクチャ設計を共有し、なぜJuiceFS+EMR+OSSを選択したのか、そして新しいアーキテクチャからどのような利点を得ることができるのかを説明します。この投稿を通じて、同様の課題に直面している方々に貴重な洞察を提供することを目的としています。

古いアーキテクチャと課題

アプリケーションのニーズを満たすために、数百の大規模ウェブサイトからデータをクローリングし始めました。現在では500を超えるウェブサイトからのデータを収集しています。時間の経過とともに、大量の生データ、中間データ、結果データが蓄積されています。ウェブサイトのクロール範囲と顧客基盤を拡大していくうちに、データ量が急速に増加していきました。そのため、拡大する要件に対応するためにハードウェアを拡張することを決定しました。

オリジナルアーキテクチャ

以下の図は、データセンター内に展開されたCDHベースのビッグデータクラスタを含む以前のアーキテクチャを示しています。

  • 主要コンポーネントにはHive、Spark、HDFSが含まれていました。
  • Kafkaを含むいくつかのデータ生産システムがクラスタにデータを供給していました。
  • Kafkaに加えて、TiDB、HBase、MySQLなどの他のストレージソリューションも使用していました。

Original architecture at Yimian

データは上流のアプリケーションシステムおよびデータ収集システムから流れ込み、Kafkaに書き込まれました。Kafka Connectクラスタを使用してデータをHDFSに同期していました。

このアーキテクチャの上に、様々なタスクを管理するカスタムデータ開発プラットフォームであるOneWorkを開発しました。これらのタスクはAirflowによってスケジュールされ、タスクキューで処理されました。

私たちの苦痛ポイント

直面していた課題は以下の通りです。

  • アプリケーションデータの急速な成長と長いスケーリングサイクル: 2016年に展開された私たちのCDHクラスタは、2021年までにすでにペタバイト単位のデータを処理していました。しかし、データの成長はしばしばハードウェアの計画を上回り、6ヶ月ごとに頻繁にスケーリングが行われました。これにより、多くのリソースと時間が消費されました。
  • ストレージとコンピューティングの結合と容量計画の困難性: 従来のHadoopアーキテクチャのストレージとコンピューティングの密接な結合は、独立してスケールし、ストレージまたはコンピューティングの要件に基づいて計画することを難しくしています。例えば、ストレージを拡張する場合、不必要なコンピューティングリソースの購入も必要になります。これにより、リソース配分が非効率的になりました。
  • CDHバージョンのためのアップグレードを躊躇: 私たちのCDHバージョンは古く、安定性と互換性に関する懸念からアップグレードを躊躇していました。
  • 高い運用コスト: 約200人の従業員がいたにも関わらず、専任の運用スタッフは1人だけでした。これにより、重い業務負担が生じました。これを緩和するために、より安定したシンプルなアーキテクチャを求めました。
  • 単一データセンターの単一障害点: 単一のデータセンターに保存されたすべてのデータは長期的なリスクを抱えていました。ケーブルの損傷やその他の問題が発生した場合、単一のデータセンターは単一の障害点を作り出します。

新しいアーキテクチャの要件

私たちの課題に対処し、増大するニーズに応えるために、いくつかのアーキテクチャの変更を決定しました。アップグレードについて検討した主な側面は以下の通りです:

  • クラウド採用、弾力的なスケーラビリティ、および運用の柔軟性: クラウドサービスを採用することで運用を簡素化できます。例えば、クラウドベースのストレージを活用することで、アプリケーションに集中でき、保守作業から解放されます。さらに、クラウドリソースを利用することで、長いハードウェア展開やシステム構成なしで弾力的なスケーラビリティを実現できます。
  • ストレージとコンピューティングの分離: より良い柔軟性とパフォーマンスを達成するために、ストレージとコンピューティングを分離することを目指しました。
  • オープンソースコンポーネントへの好み、ベンダーロックインの回避: クラウドサービスを使用しながら、特定のベンダーへの依存を最小限に抑えることを目指しました。AWS Redshiftを顧客サービスに使用しながら、社内運用ではオープンソースコンポーネントに傾きました。
  • 既存のソリューションとの互換性、コストとリスクの制御: 開発コストを最小限に抑え、アプリケーションへの影響を最小限に抑えるために、現在のソリューションとの互換性を確保することを目指しました。

JuiceFS+EMR+OSSを選んだ理由

様々なソリューションを評価した結果、ストレージとコンピューティングを分離したビッグデータプラットフォームを構築するためにEMR+JuiceFS+OSSを選び、徐々に社内データセンターをクラウドに移行しました。


New architecture at Yimian

この設定では、オブジェクトストレージがHDFSを置き換え、JuiceFSがPOSIXおよびHDFSプロトコルをサポートするためプロトコル層として機能します。最上位には、ハブ、インパラ、スパーク、プレストオ/トリノなどのコンポーネントを含む、セミマネージドのハッカドップソリューションであるEMRを使用します。

アリババクラウド vs. 他のパブリッククラウド

慎重な評価の後、アリババクラウドをAWSやAzureよりも選ぶことにしました。以下の要因がその理由です:

  • 近接性: アリババクラウドの可用性ゾーンが私たちのデータセンターと同じ都市にあることで、低遅延とネットワークコストの削減を保証しています。
  • 包括的なオープンソースコンポーネント: アリババクラウドEMRは、幅広いHadoop関連オープンソースコンポーネントを提供しています。私たちがヘビーに使用しているHive、Impala、Spark、Hueに加え、Presto、Hudi、Icebergなどとのスムーズな統合も提供しています。研究中に、EMRだけがImpalaをネイティブに含むのに対し、AWSやAzureはより低いバージョンを提供するか、手動でのインストールとデプロイが必要であることがわかりました。

JuiceFS vs. JindoFS

JuiceFSとは何ですか？

JuiceFS は、高性能なオープンソース、クラウドネイティブ、分散ファイルシステムです。完全なPOSIX互換性を提供し、異なるプラットフォームや地域でオブジェクトストレージを巨大なローカルディスクとして使用できます。

JuiceFSはデータ-メタデータ分離アーキテクチャを採用し、分散ファイルシステムの設計を可能にします。JuiceFSを使用してデータを保存する際、データはAmazon S3のようなオブジェクトストレージに永続化され、メタデータはRedis、MySQL、TiKV、SQLiteなどのデータベースに保存できます。

POSIXに加え、JuiceFSはHDFS SDKと完全に互換性があり、ストレージ-コンピューティング分離のためにHDFSの置き換えを容易にします。


The JuiceFS architecture

JuiceFSをJindoFSより選んだ理由

以下の考慮事項に基づいて、JuiceFSをJindoFSより選びました：

  • ストレージ設計: JuiceFSはデータとメタデータの分離されたストレージアーキテクチャを採用し、分散ファイルシステムの設計を可能にします。データはオブジェクトストレージに永続化され、メタデータはRedis、MySQL、TiKV、SQLiteなどの様々なデータベースに保存でき、より高い柔軟性を提供します。一方、JindoFSのメタデータはEMRクラスタのローカルハードディスクに保存されており、保守、アップグレード、移行が不便です。
  • ストレージの柔軟性: JuiceFSは様々なストレージソリューションを提供し、異なるスキーム間のオンライン移行をサポートし、移植性を高めます。JindoFSのブロックデータはOSSのみをサポートしています。
  • オープンソースコミュニティのサポート: JuiceFSはオープンソースコミュニティを基盤としており、すべてのパブリッククラウド環境をサポートしています。これにより、将来的にマルチクラウドアーキテクチャへの拡張が容易になります。

全体的なアーキテクチャ設計

データセンターのHadoopクラスタに残されるアプリケーションも考慮し、実際にはハイブリッドクラウドアーキテクチャを採用しています。以下の図を参照してください。


A hybrid cloud architecture

アーキテクチャ図では:

  • 最上部にはAirflowとOneWorkがあり、どちらも分散デプロイをサポートしているため、容易に水平スケーリングが可能です。
  • 左側はIDCで、従来のCDHアーキテクチャといくつかのKafkaクラスタを使用しています。
  • 右側はAlibaba Cloud上に展開されたEMRクラスタです。

IDCとEMRクラスタは高速の専用線で接続されています。

新しいアーキテクチャからのメリット

ストレージとコンピューティングの分離の利点

ストレージとコンピューティングの分離実装により、総ストレージ容量は倍増しましたが、コンピューティングリソースは安定しています。時折、必要に応じて一時的なタスクノードを有効にしています。私たちのシナリオでは、データ量は急速に増加していますが、クエリの需要は安定しています。2021年以来、データ量は倍増しています。当初から現在まで、コンピューティングリソースについては最小限の変更を行っていますが、特定のアプリケーションのニーズに応じて、エラスティックリソースと一時的なタスクノードを時折有効にしています。

パフォーマンスの変化

私たちのアプリケーションシナリオは、主にオフライン計算の大規模なバッチ処理に関与しており、パフォーマンスには大きな影響はありません。しかし、PoCフェーズ中に、インスタントクエリの応答時間が改善されたことが観察されました。

PoCフェーズ中に、いくつかの簡単なテストを行いました。しかし、様々な影響要因があるため、結果を正確に解釈するのは難しいです：

  • HDFSからJuiceFSへの移行
  • コンポーネントのバージョンアップ
  • Hiveエンジンの変更
  • クラスタ負荷の変化

これらすべてが、ベアメタルサーバー上のCDHの以前のデプロイと比較したパフォーマンスの違いについて明確な結論を引き出すことを困難にしています。

使いやすさと安定性

JuiceFSで問題を経験したことはありません。

EMRを使用している間、軽微な問題がありました。全体的に、CDHはより安定しており、使いやすいと感じています。

実装の複雑さ

シナリオで最も時間を要するプロセスは、増分デュアルライトとデータ検証です。振り返ってみると、検証に過度に投資しており、簡略化できる可能性があります。

複雑さに影響を与える複数の要因:

  • アプリケーションシナリオ（オフライン/リアルタイム、テーブル/タスク数、上位アプリケーション）
  • コンポーネントバージョン
  • サポートツールとリソース

今後の計画

今後の計画には以下が含まれます:

  • 残りのアプリケーションのクラウドへの移行を継続します。
  • JuiceFS+OSSを使用した冷/熱階層ストレージ戦略の検討。JuiceFSファイルはOSSで完全に分解されているため、ファイルレベルの階層化を実装することは困難です。現在のアプローチでは、JuiceFSからOSSに冷たいデータを移行し、アーカイブストレージとして設定し、使用に影響を与えずにHiveテーブルまたはパーティションのLOCATIONを変更します。
  • データ量が増加し、Redisの使用に圧力がかかる場合は、将来TiKVやその他のエンジンに切り替えることを検討する可能性があります。
  • EMRの弾力的なコンピューティングインスタンスを探索して、アプリケーションサービスレベル契約を満たしながら使用コストを削減します。

Source:
https://dzone.com/articles/migrating-hadoop-to-the-cloud-2x-storage-capacity