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
http://www.datacenterdynamics.com/focus/archive/2011/08/facebook-moves-hadoop-stack-to-prineville-data-center

image

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 – だれが、どこで、使うのか?

 

クラウドへの移行を、経済面から考察する – Pennsylvania 州立大学

Posted in Businesses, Research by Agile Cat on July 28, 2011

Economics of Cloud Computing: When Does Moving to the Cloud Make Sense?
By Dick – July 13th, 2011
http://www.formtek.com/blog/?p=2247

_ formtek

Moving IT operations to the cloud saves money when compared to using on-site computing facilities. That’s a premise that’s increasingly believed, but the truth of which actually depends on a number of parameters.  A group of academics from the Pennsylvania State University looked at the economics of cloud computing and concluded that cloud computing currently makes the most sense economically for small businesses and applications with small workloads.

IT オペレーションのクラウドへの移行は、オン・サイトのコンピューティング・ファシリティ利用と比較して、コストを節約する。  それは仮説であり、その信頼性を高めているが、何が真実かといえば、数多くのパラメータに依存するという現状にある。 Pennsylvania State University のアカデミック・グループは、クラウド・コンピューティングの経済的側面に注目し、現状では、経済的に小規模なビジネスと、低いワークロドのアプリケーションに対して、意味をもたらすという結論に至った。

The researchers divided costs into categories of being “quantifiable” and “less quantifiable”, and “direct” and indirect.  Given this division, they constructed a matrix showing the classification of various costs.

この調査に参加して研究者たちは、コストについて「定量化しやすい」、「定量化しにくい」、「直接的」、「間接的」というカテゴリを定義した。  そして、この定義を前提として、各種のコストを、以下のマトリクスに分類していった。

The report considered the two option of pure in-house and pure cloud-based hosting, but it also considered combinations of the two approaches, which it termed as “hybrid” options.  In the hybrid model, they identified vertical partitioning and horizontal partitioning.  With vertical partitioning an application might be split so that part of it reside on-premise and another part of it resides in the cloud.  Horizontal partitioning replicates some parts of an application in the cloud and, as load on the application increases, usage can burst or spill over onto servers running in the cloud.

このレポートでは、ピュアなイン・ハウスとピュアなクラウド・ベース・ホスティングという、2つの選択肢について考察している。 しかし、その2つのアプローチの組み合わせを、「ハイブリッド」オプションと命名し、合わせて考察している。  この ハイブリッド・モデルにおいて、彼らは、垂直の仕分けと、水平の仕分けを認識している。  垂直の仕分けでは、アプリケーションは分割され、あるパートはオンプレミスに存在し、別のパートはクラウドに存在するようになるだろう。  水平の仕分けでは、アプリケーションの一部がクラウドにリプリケートされ、そのアプリケーションの負荷が増大するにつれて、クラウド上で動作するサーバーへ向けて、過大な負荷が溢れ出ていくことになる。

imageThe report found that “ (i) complete migration to today’s cloud is appealing only for small/stagnant businesses/organizations, (ii) vertical partitioning options are expensive due to high costs of data transfer, and (iii) horizontal partitioning options can offer the best of in-house and cloud deployment for certain applications.”

このレポートから、発見できるものは、以下のとおりである。(i)  現状におけるクラウドへの完全な移行は、小規模/不活性な企業/組織にのみにアピールする。 (ii)  垂直の仕分けは、データ転送におけるコストにより高価な選択となる。 (iii)  水平の仕分けは、特定のアプリケーションにおいて、ベストなイン・ハウス/クラウド・ディプロイメントを提供し得る。

ーーーーー

最近は、お馴染みさんになってきた Formtek ですが、今日のは、ちょっと解釈が難しいですね。 Agile_Cat の理解では、Hybrid を考えるときに、どのような仕分け方があるのかという視点で、タテ/ヨコを定義しているのかと・・・?  それにしても、文中のリンクからの論文も面白そう :) ーーー __AC Stamp 2

ーーーーー

<関連>

クラウドは 他の IT と比べて、4倍速で急成長していく – IDC
アメリカ市場では 28% の組織が、すでにクラウドを使用している
パブリック・クラウドがエンタープライズ市場を制する理由

%d bloggers like this: