Agile Cat — in the cloud

Facebook は 30 P Bytes の Hadoop HDFS を、どのようにして Oregon へ移動したのか

Posted in .Selected, Big Data, Data Center Trends, Facebook, Hadoop, Open Compute by Agile Cat on August 7, 2011

Facebook moves Hadoop stack to Prineville data center
Complete mammoth task by creating new process that can enhance future disaster recovery
Published 1st August, 2011 by Penny Jones


Elephants, war rooms and 30 petabytes – this is what it takes to keep Facebook’s data in check according to one of its most recent blog posts. After building out its new data center in Prineville, Oregon, which opened in April this year, the Internet giant then had to find a way of migrating what is said to be the largest HDFS Hadoop cluster in the world into it.  Facebook uses Hadoop – a program named after a toy animal belonging to a developer’s child — to mine and manipulate its data sets, and distribute its storage across switches and stacks. As Hadoop use grows, however, so too does the power and infrastructure required to accommodate it.

エレファントと、作戦司令室と、30 ペタ・バイト - Facebook がデータを保持していくためには、それらが欠かせないと、最新のブログ・ポストに書かれている。 Prineville, Oregon に新しいデータセンターを構築し、この 4月にオープンしたインターネットの巨人は、世界でも最大級と言われる HDFS Hadoop クラスタを、そこへ移行するための方式を見つけ出す必要があった。 Facebook は Hadoop(開発者の子供が持っていたぬいぐるみにちなんで名付けられた)を、データセットのマイニングと操作のために使用し、そのストレージを、スイッチとスタックのいたるところに分散している。 しかし、Hadoop の利用が増大するにつれて、それを受け入れるための、さらなるパワーとインフラストラクチャが必要になってきた。

facebook_logoFacebook Engineer Paul Yang recently highlighted the challenges Facebook had when moving the Hadoop application stack to its newest data center. “We considered a couple of different migration strategies,” Yang said. “One was a physical move of the machines to a new data center – we could have moved all the machines within a few days with enough hands at the job.” Such a move, however, would have required Hadoop to be down for a period of time that could have been too long for analysts and users of Facebook.

Facebook の Engineer である Paul Yang は、最新のデータセンターに Hadoop アプリケーション・スタックを移行する際の、Facebook における課題にスポットライトを当てる。「私たちは、2種類のマイグレーション・ストラテジーについて検討した。 1つは、新しいデータセンターに、マシンを物理的に移行することであり、充分な人員を投入することで、私たちは数日のうちに、それを完了できたずだ 」と、Yang は発言している。しかし、そのような移行は、Hadoop に対して長すぎるダウンタイムを要求することになり、また、Facebook のアナリストとユーザーを待たせ過ぎることになる。

The solution was a complicated replication system set up to mirror changes from the old cluster to the new, larger cluster, which at switchover time could easily be redirected to the new cluster.  “This approach is more complex as the source is a live file system, with files being created and deleted continuously,” Yang said. This was done in two steps. First a bulk copy transferred most data from the source cluster to the destination using DistCp, a tool used for cluster copying. “Our Hadoop engineers made code and configuration changes to handle special cases with Facebook’s datasets, including the ability for multiple mappers to copy a single large file and for the proper handling of directories with many small files,” Yang said. A custom Hive plug in was then used to detect file changes and add these to an audit log.

そして、ソリューションとして選ばれたのは、古いクラスタから新して大規模なクラスタへ向けて、変更点をミラーリングしていくという、複雑なリプリケーション・システムであった。 それであれば、新しいクラスタにリダイレクトすることで、容易な切替が実現される。 「そのソースが、ライブ・ファイル・システムであり、また、ファイルが作成/削除が連続的に行われるため、このアプローチは更に複雑化していった」、と Yang が言う。 それは、2つのステップで完了した。 最初のステップは、ソース・クラスタからデスティネーションへ向けたバルク・コピーによる、大半のデータの転送である。 そこでは、クラスタ・コピーのための  DistCp というツールが用いられた。 「 私たちの Hadoop エンジニアたちは、Facebook のデータセットにおける特殊性に対応するために、コードとコンフィグレーションに手を加えた。それらの特殊性には、大規模なシングル・ファイルをコピーするためのマルチ・マッパー機能や、たくさんの小さなファイルを持つディレクトリの、適切な取り扱いなどが含まれる 」と、 Yang は付け加えている。 続いて、ファイルの変更を検出し、そのことを監査ログに加えていくために、カスタムな Hive プラグインが用いられた。

“At the final migration switchover time, we set up a camp in a war room and shut down Hadoop JobTracker so that new files would not be created. Then the replication system was allowed to catch up,” Yang said. DNS entries were then changed so hostnames referenced by Hadoop jobs pointed to servers in the new cluster.

そして、2つめのステップだが、「 最終的なマイグレーションとなる切替時において、私たちは作戦司令室にキャンプを設営し、それ以降に新しいファイルが作られないよう、Hadoop JobTracker をシャットダウンしていった。 続いて、リプリケーション・システムによる捕捉を実行していった」と、Yang は言う。 その後に、 DNS エントリーが変更され、新しいクラスタでサーバーを Hadoop ジョブが指し示めすことで、ホスト名が参照されるようになった。

Elephant challenges

The project was not, however, without its challenges. Yang said simply designing a system to handle the size of the replication project, given the huge amounts of data it was dealing with, put the team to the test. Facebook also had to ensure that replication of the system was fast enough to allow for corrupt files to be fixed without eating into the team’s schedule. “If the replication process could just barely keep up with the workload, then any recopy could have resulted in missed deadlines.

しかし、このプロジェクトは、チャレンジ無くして、成立するものではなかった。 Facebook が取り扱う膨大なデータ量を前提として、このリプリケーション・プロジェクトの規模を、シンプルに取り扱うようにシステムをデザインし、そのチーム自身がテストして行くようにしたと、Yang は言う。 さらに Facebook は、そのシステムのリプリケーションにより、チームのスケジュールを圧迫することなく、破損したファイルの修復を高速で処理していく必要があった。 そのリプリケーション・プロセスが、ワークロードに遅れを取とることなく追随できるなら、デッドラインの範囲内で、あらゆる再コピーが達成できる。

big-hadoop-logoThe result has not only been a shift to the new data center, where infrastructure is built out in a more efficient manner and space is available for further scaling out, but a new way of building in redundancy, according to Yang. “The replication system also demonstrated a potential disaster-recovery solution for warehouses using Hive,” Yang said. “Unlike a traditional warehouse using SAN/NAS storage, HDFS-based warehouses lack built-in data recovery functionality. “The replication system could increase the appeal of using Hadoop for high reliability enterprise applications.”

求められる結果は、新しいデータセンターへの単なる移行だけではなく、新しい方式による冗長性の構築も対象となっていた。つまり、さらに効率の良い方式でインフラストラクチャを構築し、また、将来のスケールアウトのための空間を確保することも、必要とされていた。「 このリプリケーション・システムは、Hive を用いたウェアハウスについて、DR(disaster-recovery)ソリューションを証明するものでもある」と、Yang が言う。 SAN/Nas ストレージを用いる伝統的なウェアハウスとは異なり、HDFS ベースのウェアハウスは、ビルトイン・データリカバリ機能を欠いている。「このリプリケーション・システムより、高信頼性のエンタープライズ・アプリケーションへの Hadoop の適用について、強くアピールすることが可能になった」と Tang は締めくくっている。

Related Stories


まぁ、そうれは、そうするんでしょうが、30 Peta Bytes の引越しですか。。。 気の遠くなる内容の話ですが、それが、こうして、本当にできてしまうところに驚きます。 これからは、こんな引越しが、あちら こちら で、起こってくるんでしょうね ーーー __AC Stamp 2



Facebook は正攻法で、Billion 単位のメッセージを処理していく
Facebook は 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理する!
Facebook における 1300万/秒 クエリーの秘密
Facebook の HBase は、毎月 1350億 メッセージを処理する!
Big Data を探せ! アメリカの 5つの具体的な事例とは?
Big Data – だれが、どこで、使うのか?


Comments Off on Facebook は 30 P Bytes の Hadoop HDFS を、どのようにして Oregon へ移動したのか

%d bloggers like this: