Hadoopハイブリッドクラウドが可能に

弊社の初めての“クラウド”についてのWebinar(Making Hybrid Cloud a Reality)の情報。概要は以下のとおり。詳しくはリプレイをご覧ください。
弊社はHadoopクラスタ間でデータ複製を行うFusionという製品を昨年出荷しました。オンプレのHadoopクラスタ間で使用されてきたが、最近はクラウドとオンプレのハイブリッドのサポートに力を入れている。クラウドとオンプレの間で通常業務を止めないで即時に双方向のデータ複製が可能になるので、RTO/RPOがほぼゼロのDRを安価に実現することが可能となる。ピーク時のみ(例えば年末)クラウドを使用する、クラウドにオンプレのHadoop(異なるディストリビューションでもOK)を集約する等々も簡単に行える。
HDFSとHDFSの間のみでなくHFDSとS3/EMR間でも複製を行うことができる。さらにHadoopの動いていないシステムのフラットファイル(PosixまたはNFS)をS3に複製することも可能である。
HadoopのData Nodeは現実的には同一データセンタに置くしかないが、Fusionの提供するActive -Active複製によりデータロスのない、トランザクショナル(正確にはWriteの順番が保証された)データ移動がオンプレとクラウドの間で可能になる。

Subversion 1.9の新機能

What’s New in Subversion 1.9 (クリックでリプレイ)と題したWebinarの概要です。

1.9ではクライアント側とサーバー側の両方の強化が行われています。
svn auth, copy, merge,blame, cleanup,infoに新しいオプションが追加されています。1.8のWorking Copyに対する互換を保障しているので、1.9クライアントと1.8を一緒に使うことも可能になります。
Lock(コミット中に他の人がコミットしないようにする)の数が数百を超えるとスケールしないとの問題に対応しています。一つは既にGETで使われているHTTP PipelineのLockへの適用です。クライアント側のみの変更のため、クライアント側を1.9にすることで効果を得られます。多数のLock発生時、サーバー側での余計なデータの書き込みオーバヘッド解消のため、FSFSにMulti Lock機能が追加されています。LockのHock(post-lock, post-unlock)が複数パスで使用できるようになっています。
FSFSは1.9で新しくFormat7になりました。従来、性能向上はキャッシュに頼ってきましたが、リポジトリが大きくなると限界がありました。Format7ではRevisionファイルにLogicalアドレスを使用しディスクアクセスの効率化を図っています。また、今まではチェックサムがリポジトリの全てを対象にしていませんでした、全体を対象にすることになりデータ破壊の検出の精度が向上しています。Pack実行中のコミットがブロックされる期間も大幅に短縮されています。
新バックエンドFSXは性能改善、Packのボトルネック解消を目指して開発中であり、正式なリリースは1.10になる予定。
Server側もリポジトリ、クライアントとの互換は保障しています。

詳細はApacheのサイトを参照ください。

参考:
WANdisco社はSubversion活用の為に必要な総合的なサービスを提供しています。
ご興味あれば、お気軽にご連絡ください(wandisco.japan@wandisco.com)。

Subversion Offer

Subversion Offer

Subversion Offer

最新版Subversion 1.9 がダウンロード可能に

Subversionの最新版には多くの新機能とバグ修正が含まれています。性能改善、ネットワークリソース有効利用も可能になっています。リポジトリのバックエンドとして長く使われてきたFSFSが新しいもの(FSX)になりました。これによりログ・マージ等が改善されました。
9月15日(日本では16日2:00AM)に下記のWebinarで新機能を紹介します。

“What’s New in Subversion 1.9.” Register
(Replayもあります。上記の“Register”で登録すれば、Replyに関するメールも届きますので、是非、登録ください。Webinar概要については別途、本ブログにアップ予定です)
詳細な説明は以下で参照できます。

http://subversion.apache.org/docs/release-notes/1.9.html
弊社でテスト済のSubversion 1.9のバイナリは以下からダウンロード可能です。

http://www.wandisco.com/subversion/os/downloads

ビッグデータ時代のストレージ選択

調査会社451と弊社のWebnar:Big Data Storage: Options & Recommendationsのまとめです。Big data storage size

ビッグデータ/Hadoop対応のストレージの需要は(驚くことに)いまだに4%程度。全体の需要の伸びにも追い付いていないのが現状ではあるが、少しずつ変わりつつある。

元々Hadoopは、バッチ処理中心で安価なローカルディスクを使用するのが一般的であった。

しかしながら、リアルタイム処理、解析等々多様なアプリに使われだした為、色々な種類のストレージが使われ始めた。一例としてNetwork Storageを何に使うかを調べたところビッグデータの伸びが一番大きかった。クラウドであろうがオンプレであろうが各種ストレージを適材適所で使用していく事が成功のカギとしている。Stodare hadoop

こうした環境では異なるストレージ間のコネクタ、複製が必要となってくる。一つの解としてWD Fusionが紹介された(WDFusionについては過去のブログを参照ください)

リプレイは下記URL

https://www.brighttalk.com/webcast/11809/153683

ODP(Open Data Platform)とは? Apache v.s. ODP

ODP(Open Data Platform)が今年2月に設立された。スポンサーはHortonworks, Pivotal, IBM, SAS等の19社。OPDは企業向けのHadoopおよびBig Dataを推進する業界共同の努力であるとしている。Hadoopベンダー同士の争いように見え、よく分からないところがあるが、datanamiの”Hadoop’s Next Big Battle: Apache Versus ODP”という記事の解説が興味深いので紹介する。

Apache Software Foundation(AFS)のオープンソースモデルが今日のHadoopの作り上げたこと、このモデルがHadoop強みであることは疑いの余地はない。しかしながら今後の発展をどう進めるかでHadoopコミュニティの中で意見が分かれている。別のガバナンス機関、即ちODPが必要とする意見と不必要とする意見である。

ODPの推進派として弊社CEOの考え方が紹介されている。Hadoopの開発スピードが速すぎて、3rd Partyがついていけない。Name NodeのプラグインによりHadoopのHA・DR対応の製品を出していたが、認証の為の時間・コストが大きすぎる。弊社はこのため上位のプロクシ―で同等の機能を提供するWD Fusionへ切り替え問題は回避したが、ユーザ・3rd Party の為には、APIを一貫性が重要。ODPにこの役目を期待している。技術革新はASFが担いODPは標準化のQAの役割を果たすものであり、開発は行わないとしている。

MapR CEOは反対派の意見としてODPは冗長であり、必要のない課題を解こうとしていると述べている。Hadoopユーザはベンダーロックインの懸念は持っていない。Gartnerの調査でも相互接続、ロックインが問題としているのは1%以下との事。ODPのガバナンスがどうなるのかも不透明。ClouderaのCTOも同意見であり、ODPは昔、OSFがUNIXを分断してしまったのと同じとしている(個人的にはODPはX/Openであるべきと思うが。。。。。)

HadoopがUNIXよりはずっと複雑であり、ユーザにとっても懸念事項である。ASFの中のプロジェクト間、Hadoopディストリビューション間等々でいろんな争うが起きている。DatanamiはODPというスーパー標準がでてきたことでHadoopが2つに分かれてしまうのではないかとの懸念を示している。

新製品WD Fusion発表に関わるCTOのQ&A

弊社CTOのJaganeによるWD FusionのQ&Aを紹介します。

Q1: WANdisco Fusionを簡単にいうと何?

一貫したトランザクションの複製を可能とするエンジンを核にした技術により、異なるタイプのストレージをシームレスに統合する。

ビジネス、ITが直面する数多くの問題に答え、ビックデータイニシアティブから企業が、より多くのものを得られるように設計されている。

何が最もよいかと言えば、全てのデータセンタが同時にアクティブな状態である事。つまりどのセンタに対してでもリード・ライトが可能。この結果、バックアップとかスタンバイ用途で、アイドルになってしまうハードウエアは不要になる。

Q2:どのようなビジネスの問題を解決できるのか?

2つの重要な新しい機能を提供する。一つ目はデータセンタが世界のどこにあろうと複数データセンタ間のデータの一貫性を保障すること。

これにより異なるタイプのストレージを単一Hadoopシステムに統合することが可能となる。WD Fusionを使えば、あるデータセンタではPivotal、他ではHortonworks、さらに別のデータセンタではEMC Isilonを使っていても問題なく、全てを同一に扱える。

Q3:異なるストレージシステム間でデータ複製する必要性は?

答えは簡単。ストレージに詳しい人ならそれぞれのストレージシステムがどんなに違うかを知っている。ストレージシステムはアプリケーションに依存した強みを各々持っている。

しかしながら、データの同期を取ることはとても難しい。Fusionがデータの一貫性を保障して、この問題を解決する。

Q4:それは将来のHadoop展開にどう係わってくるか?

企業のシステム更新手順に於いてFusionは重要な要素になると考える。アプリケーションの稼働を損なうことなく、また更新終了後の大量データのコピーも不要となり、データセンタ毎に、順次、更新することでHadoopインフラ全体を更新することが出来る。

これにより、Hadoopベンダーとアプリケーションベンダーの両方が協調してシステム更改をスムーズに行えるようになる。

Q5:ストレージレベルの複製の方がFusionより効率的では?

ショートアンサーはNO。ストレージレベルではファイルシステムが許容する遅延の限界が問題になってくる。現実的には距離の離れた、例えばWAN環境では使えない。

ストレージレベルではFusionと同様な機能は実現できない。LANレベルでは使えるが本来のWAN環境では使えない。

Fusionを使えば、異なるシステム、例えばNFSとHadoopを統合することもできる。これにより個々のストレージシステムの強みと能力を十二分に引き出すことができる。私自身、こんなエキサイティングで革新的なプロジェクトは初めてだ。

Q6:WD Fusionはどのようにして生まれたのか?

顧客のデータセンタを訪れた時に彼らの直面している課題が分かった。多様なストレージ環境が必要なことに気付くのに長い時間は必要なかった。

顧客は各々のアプリケーションと相性が良い多様なストレージが存在することに気付いていた。さらにそうしたやり方を好んでいた。複数のデータセンタでストレージタイプを一つに統一することは望んでおらず、各々の強みを発揮出来るようにしたいと考えている。

その時点で異なるシステム間でデータの一貫性を保つような製品のアイデアが浮かんだ。その結果がWD Fusion:データの一貫性を保つ完全なトランザクションベースの複製エンジンである。一度、設定すれば、以降、データが矛盾ないかのチェックで悩むことはなくなる。

Hadoop環境での使用効率100%、異なるストレージ環境でのデータ一貫性がこの製品を考え始めた時に思い描いたビジョンである。

Q7:あなたはHadoopの仕事をここ10年している。その目からみてWD Fusionは破壊的な技術になると思うか?

実際には15年以上、ストレージ業界で働いている。共有ストレージシステムを長く携わり、その後Hadoopに関わった。WD Fusionはストレージインフラの使い方に革命を起こす大きな可能性を持っている。正直言ってこんなにエキサイティングなプロジェクトは経験したことがない。

Hadoopエコシステム充実に伴い、異なるストレージを統合する仮想ストレージシステムのニーズが出てくると考えていた。

複数のデータセンタを跨がってHadoopを動かす努力は多くの場合、うまく行っていない。WANdiscoが初めて、複数データセンタのHadoopデータの一貫性保障を可能にした。

これが何故エキサイティングなのかといえば、Hadoopを世界中に散らばったデータセンタ間で使えるものに変えるからだ。Hadoopの創始者が当初は考えていなかったようなことが、突然、実現出来るようになったことになる。Fusionが何故、エキサイティングなのかの理由である。

―――――――――――

WD FusionのDatasheetは以下を参照ください。

Datasheet-WD-Fusion-A4-WEB April2015

SubversionかGitかそれとも両方?

SubversionとGitは最もよく使われている世代管理ソフトであり、OSSプロジェクトでは85%、企業においても約60%が使用しています。Gitを使っている、検討中という話を日本でもよく聞くようになりました。両者の比較、選択の指針、マイグレーションの注意事項等々をWebcastで紹介しています。概要を紹介します。

Subversionは集中型であり、Gitは分散型ですが、Gitにおいても企業ユースでは、Subversion同様、管理されたマスターリポジトリ(Golden Master)を持つことになります。しかしながらGitでは、開発者同士が変更を自由に共有できること、例えば開発者Aさんが自分の変更を開発者Bさんだけに渡す(Push)ことが可能です。例えばAさんがマスターリポジトリにPushする権限を持っていなくともBさんによりAさんの更新がマスターリポジトリ反映されるようなことも起こります。

Gitは自由度が大きいので多様なワークフローを実現できるのでメンタルチェンジが必要という事です。一方、GitHub, GitLab, Gerrit等の管理ツールが充実してきており企業ユースのハードルも下がってきています。SubversionからGitに移行するには一定期間、共存させるのが、お勧めで、ツールも用意されています。Gitを使用する際の注意点は、リポジトリサイズを小さく維持し管理していく事です。

最後に今までのコンサル経験からSubversionかGitかについてコメント。開発者はGitのパワフルな機能に魅かれるが実際に企業内で使いだすと色々な問題に遭遇しているのが現状であり、注意深く進めることが必要です。

詳しくはhttps://www.brighttalk.com/webcast/11815/152641をご覧ください。

(最初の2分程、エコーがかかって聞けませんが肝心なところからは問題ありませんのでちょっと我慢して下さいね)。

 

GitLabのデモは下記のWebcastで見ることができます。

https://www.brighttalk.com/webcast/11817/150559?utm_campaign=communication_viewer_followup&utm_medium=email&utm_source=brighttalk-transact&utm_content=webcast

最後に、Subversion・Git共通のアクセス制御を可能とするAccessControlPlusのデータシートです。

WD-Datasheet-ACplus-A4-Japan-WEB

スマートメータのデータをHadoopで解析

british gasConnected HomeはBritish Gasが開発をしているエネルギー使用をモニター・コントロールするサービス。暖房を点けたり、消したりするサービスアプリを提供している。インタネットは家庭の娯楽は大きく変えてきたが、日常生活そのものについてはまだこれからであり、3rd Partyも活用しサービスの差別化をしていくことをBritish Gasは目指している。

WANdiscoは2014年3月に100万世帯のスマートメータからデータを取得し、エネルギー使用のモニタ・コントロールを行うトライアルに参加した。収集されたリアルタイムデータを解析することで、需要パターンと供給をダイナミックにマッチングし、需要に見合う供給を行い、かつ企業および一般家庭での使用のコントロールが可能となることが実証することが目的。

リアルタイム性、コンプライアンス対応のため、Non-Stop Hadoopが導入され、100ノードのクラスタでのデータ損失、ダウンタイムを最小限にし、ストレージコストも大幅に削減することができた。

10か月のトライアルが成功裏に終わり、2倍のスケールで本番運用に入ることになった。WANdiscoは3年間のSubscription契約をUS$750KでBritish Gasと締結。

Hadoopが金融のメインストリームへ (Whitepaper要約)

 

“Bringing Hadoop into the banking mainstream”はグローバル銀行が技術、商習慣、規制を如何に乗り越えてHadoopをミッションクリティカルなアプリに使用しているかの事例です。詳細は以下のURLを参照ください。

https://www.brighttalk.com/webcast/11809/134895

背景:

事例の銀行は北米、ラテンアメリカ、ヨーロッパ、アフリカ、APACで事業を展開、従業員は225千人、資産はUS$2500M。保有するアプリは数千。Hadoopを導入し大幅なコスト削減を達成している。しかしながら何人かのIT担当役員はHadoopの成熟度に懸念を示していた

挑戦:

この銀行が感じているHadoopの主な問題点は以下のとおり。

・バックアップ、信頼性、クラスタ間・地域間でのデータ一貫性

通常、DistCPをベースとしたツールが使われているが、高負荷で他のアプリに影響を与えてしまう。このためバックアップをとるのは1日1回が限度となっている。ロードバランサーで工夫はできるが、復旧不能なデータロスも起こる。こうした状況は規制の観点から受け入れられないところである

・混在するワークロードでの性能保障

いくつかの重要なリアルタイムアプリをインメモリで動かそうとするが、Hadoopはクラスタ内にゾーンを作ることができない。このため、次のような問題が発生する。①すべてのアプリをハイエンドサーバで動くようにすると予算オーバ ②ハイエンド、ローエンドサーバの組み御合わせて全てのアプリを動かすと重要なアプリに最適化されない ③アプリの特性毎に個別クラスタを作ると冗長、柔軟性欠如であり運用費もUP

・データレイクとプライバシー保護法

EUの一部、アルゼンチン、サウジアラビア他では個人情報を国外に転送することを法律で禁止。Hadoopでグローバルな分析を行う際にDistCPでデータを移動することができず、特別なアプリが必要になってしまう

・複数地点のデータのタイムリーな解析

標準的なHadoopではデータをいくつものサイトからコピーする必要があり、時間がかかるし、信頼性も問題となる

解決策:

Non-Stop Hadoopは以下のような特長があり、銀行の要望を満足

・可用性とデータの一貫性保障による規制への準拠

いくつもの規制は特定のデータが常に利用可能であることを要求。バックアップ、ディザスタリカバリが必要であり、かつそのデータが元データと整合していることが求められている。Non-Stop HadoopのActive-Active複製がソリューションとなる

・コンピュータリソースを100%利用する事によるコスト削減

Active-ActiveアーキテクチャによりすべてのサーバはRead/Write可能。従い、Read Onlyのバックアップ・ディザスタリカバリセンタをアプリからも使用できる。

・データ保護規制への準拠

Non-Stop Hadoopは複製する範囲を選択可能。また、複製しないデータについては、ローカルに存在しないときはデータのあるセンタをアクセスします(WAN/LAN経由)。従い、不正検出、マーケット解析をグローバルなデータセットで規制に準拠しつつ、実行可能

・クラスタゾーンによる性能最適化とコスト削減

Non-Stop Hadoopは仮想クラスタを作れます。ハイエンドサーバからなる仮想クラスタをキーとなるデータセンタ内につくり不正検出、マネーロンダリング防止のアプリを動かしている。大きなHWへの投資なしにクリティカルなアプリの性能の担保をすることが可能

・高速、高信頼のデータ複製と複数データセンタでのデータロード

データはどこのセンタで投入されても任意の数のデータセンタに複製が自動的に作成される。DistCPでのコピーする際に発生しうるエラーや運用者の負荷が下がる。一方、クライアントアプリはLANスピードでのRead/Writeが可能。銀行の顧客(攻撃もふくめ)は多国籍になってきており、例えば不正検出をグローバルベースで行うことがクリティカルです。

Hadoopが金融業の主流に

米調査会社のForesterリサーチと弊社のWebinarの紹介です。Webinarのリプレイは以下で見ることができます。

https://www.brighttalk.com/webcast/11809/134895

最初のスピーカはForesterのJost Hoppermann VP。金融業でのビッグデータ事例を紹介。最初はRisk管理が最重要課題であり、データウェアハウス、インメモリ技術を適用し、これに対応したドイツの銀行の例です。銀行はビッグデータという名前は使わないが、実際はビッグデータであるという一例。次に別の観点からのビッグデータの必要性を指摘している。81%の銀行が2018年までに変革を考えているとの調査結果があり、この実現にはビッグデータが必要。どこからこの変革を起こすかといえば、非定型も含めた顧客データからであり、ビッグデータがこれを支えるのは間違いない。コアバンキングも例えば顧客との組み合せでビッグデータが入り込むチャンスはあるとしている。少し視点が変わるが、クロスボーダーでの可能性が紹介された。個人情報は国外持出し制限、全面禁止となる国もあるが、必要データを切り分け、一つのデータセンタに集めることで統一されたリスク管理ルールを使用して成果をあげた事例が示された。

次のスピーカはLeslie Owen VP。現状は利用可能データの15%しか使われていないことを指摘。従来の整理された高価なデータから、安価で多様なデータを利用して世界の動きを理解する将来の姿に向け、考え方が変わりつつあるのが現在と分析。2014年のビッグデータの定義は「利用可能な大量のデータとそれをビジネスの為に使う能力のギャップを縮める技術と商習慣」としている。2012年の定義は5つV(Volume、Verity, Variability, Velocity, Value)を如何に扱うかとの技術視点であったが、これにビジネス視点が加わりバランスのとれたものになったと見ている。ビジネスおよび技術のデシジョンメーカへのビックデータへの期待に関するアンケートからのこの傾向が見てとれる。次にパラダイムシフトに必要な3C(Culture, Competence, Capability)について触れている。ビッグデータで成功している会社はR&Dとして投資するCultureを持っているとのこと。従業員が、Fact(データ)がどうなっているかを考えるような環境作りが重要。

最後にWANdisco社のRandy Defauwが金融業の3つのイノベーションについて説明。一つ目はアルゴリズムに基づく意思決定。金融業は一過性のデータも使い、遅延ない意思決定を行おうとしている。不正検出がよくある例として挙げられている。2つ目は前述と関連するがData Lakeの話。兎に角、いろいろなデータをため込み顧客・市場を理解すること。3つ目はプロセスのイノベーション。金融業界は特に短期間でのリターンが要求される。伝統的なデータウェアハウスからHadoopに変えて大きなコスト削減を行っている。これらにイノベーションの要求に如何にNon-Stop Hadoopが答えるかについての説明している。

この詳細については次回Whitepaperをベースに紹介します。

Paxosと分散コーディネーションエンジン(DConE)

分散環境でのActive-Active複製を可能にするDConEの紹介です。Paxosを拡張して、WAN環境でも情報の一貫性が保障されるようになっています。
1. Paxosについて
Leslie Lamportが提案した信頼性の低いプロセッサから構成されるネットワークにおいての合意の問題を解決するためのプロトコルの集合。Paxosプロトコルは1990年に登場し命名されたが、論文として出版されたのは1998年でした。
PaxosアルゴリズムではState Machine(状態機械)が分散システムの各ノードにインストールされ、トランザクションの順序を保障します。State MachineはProposers、Acceptors、Learnersのいずれかの役割を果たす。Paxosアルゴリズムでは以下の3つのフェーズがコンセンサスの取れるまで繰り返されます。①CoordinatorになるNodeが選択され②トランザクションProposeがブロードキャストされ、受け取ったノードはAcceptするかReject③関連するノードの過半数がAcceptすれば、コミットメッセージがブロードキャストされトランザクションを実行。プロポーザル番号は一意となるようにします。

2. DConE(Distribution Coordination Engine)についてスライド1
DConEはPaxosをWANでも使えるように拡張したものです。DConEの主な構成要素は図の通りです。実際の動きを簡単に説明します。
アプリケーションの書き込みトランザクションが発生すると当該ノードのProposal ManagerはLocal Sequence Number(LSN)を付与したProposalを生成し、障害発生に備え、セーブします(Proposal Log)。次にAgreement Managerは保持しているGlobal Sequence Number(GSN)をIncrementしたAgreement Memberを決定します。GSNは全てのNodeでAcceptされた最後のProposalの番号です。このAgreement Memberにより当該トランザクションに関するコンセンサスをすべてのノードに対して取ることを試みます。このデータもAgreement Logとしてセーブされ、障害時にはProposal Logと一緒に回復処理に使われます。
過半数がAcceptすれば、Agreement NumberがそれらのノードのGSNになります。コンセンサスに達するとDConEはトランザクションをLocking Managerに渡します。Proposalを発行したNodeはGSNの合意は待ちますが、他のノードのトランザクションの完了を待つことはありません。以下、DConEの特長を説明します。

2.1 ローカルな順序の保持(米国特許#8364633)
DConEは性能向上のため、並列してコンセンサスの処理を行います。このため、ノード内でアプリが求める順序がGSNを決める際に逆転してしまう可能性があります。ノード内の順序を決めるためのLSN(Local Sequence Number)とネットワークで接続されたノードでのGSN(Global Sequence Number)の2つによりトランザクションの順番を決定します。ネットワークはLANでもWANでも対応可能です。

2.2 Locking Scheduler
Locking SchedulerはGlobal Orderは意識しません。ローカルキューに従ってトランザクションの処理をします。アプリとのインターフェースはDConE は持っておらず、Locking Schedulerが面倒をみます。Locking Schedulerという名前ですがロックのスケジュールをする訳ではなく、言ってみれば、Database Schedulerのような振る舞いをする訳です。

2.3 性能・スケーラビィリティの向上
DConEは大規模なWAN環境でもPaxosアルゴリズムが動くような強化をしています。主なものは以下です。

・Paxosは多数決論理で動く訳ですが、オプションで決め方が選べます。あるノード(Singleton)のみがプロポーザルのレスポンスをするような設定が可能です。一番多くユーザが使っているところをSingletonノードにすることでWANのトラフィックを下げることができます。リージョンで多数決論理を動かすことでFollow the Sunのようなことも可能です。また偶数ノードの場合はTie Breakerを決めることで対応できます。
・複数のプロポーザルの処理を並行して行うこともできます。Agreement Number取得の際に発生する衝突による性能劣化への対処もされています。新しいノードの追加・既存ノードの削除も動的に行えます。
・ディスク・メモリ上にセーブされたState Machineの情報をいつまで保持すべきかは、安全性とリソース使用率のバランスをとるのに苦労するところです。一定間隔でノード同士がメッセージをやり取りすることで解決しています。

2.3 自動バックアップとリカバリ
Active-Activeの複製により全てのノードのホットバックアップが取られます。あるノードにネットワーク障害が起きてもリードだけは可能としています。ライトは禁止されSplit Brainにより情報不一致が発生することを避けています。CAP定理によればC(Consistency)、A(Availability)、P(Partition-Tolerance)の3つを同時に満たすことはできません。DConEはCとAを優先するような設計思想となっています。
障害が復旧すれば、DConEが障害の期間中にAgreeされたトランザクションをAgreementログ、Proposal Logより自動的に復旧します。

3. 終わりに
以上、大まかな説明ですが、詳しくはDConEのWhitepaperを参照ください。
http://www.wandisco.com/system/files/documentation/WANdisco_DConE_White_Paper.pdf

Name Node単一障害点回避 (QJMとNon-Stop Name Node)

ThinkIT Web記事で「NameNode障害によって発生するSingle Point of Failure問題を解決するソリューション」として弊社のNon-Stop Hadoopを紹介して頂きました。http://thinkit.co.jp/story/2014/11/11/5413

同様のソリューションとしてQJMもありますので、少し補足をしておきたいと思います。

QJMについてスライド1

2012年にCloudera社のTodd Lipcon氏が提案したものです。HadoopのアーキテクチャではNameNodeが単一障害点になっていたのを冗長化するものです。StandbyのNamaNodeを追加し、Journal Nodeで複数のジャーナルをとり、Zookeeperにより障害を検出し手動・自動でのフェールオーバーが可能となりました。右上図のような構成になります。

 

Non-Stop NameNodeについて

Paxos(パクソス)を拡張したActive-Activeの複製を行う仕組み(Distributed Coordination スライド1Engine: DConE)をNameNodeに組みこんでいます。これによりHSDF-6469に準拠したConsensusNodeとして複数のNameNodeが同一のメタデータを保持し同等に動作することになります。あるNameNodeが障害になっても多数決論理によりNameNodeのメタデータの更新を行うので、過半数のNameNodeが生きていれば継続稼働が可能です。右下図では5つNameNodeがあるので2つが落ちてもHadoopが止まることはありません。当該NamaNodeの障害が復旧すれば最新のメタデータまで自動的に復元されます。

QJMと比較した特長は以下の通りです。

  • 100%の稼働を、運用者に障害時・回復時の負担を掛けずに実現できます
  • 全てのNameNodeはActiveであり、またQJMで必要となるJournal、Zookeeperも不要です。リソースは100%活用されます
  • 複数NameNodeによる負荷分散が可能となり、性能向上が可能です。またシステムを止めないで拡張が可能です

更にNon-Stop HadoopはDataNodeのデータを、指定した範囲で自動的に複製する機能を提供しています。これにより以下のようなことも可能となります。

  • NameNodeがWANを跨がった別のデータセンタにあってもメタデータの一貫性は保障されます。容量の大きいDataNodeの複製は非同期に行います。遠隔地にあるデータセンタに複製が自動的に作られ、ディザスタリカバリも可能となります。
  • 異なる場所のデータセンタにその地域で発生したデータを格納し、別の場所から使用することも可能になります。例えばクレジットカード使用データは東京、NY、シンガポールのデータセンタに適宜格納し、不正検出のアプリは東京で動かすといった使い方が可能となります。

要は複数のHadoopクラスタを、仮想的に一つに見せることが可能という事です。これはクラスタが別のデータセンタに分散している場合も可能です。

NameNodeのメタデータの一貫性が保障されることで、述べてきたようなことが可能になっています。分散環境での一貫性の保障を行うのがPaxosを拡張した弊社の特許技術であるDistribution Coordination Engineです。これについては別途、紹介したいと思います。

最近のトレードショーから見るHadoopの動向

最近のHadoop関連の展示会の状況の報告です。10月末にNYCでStrata+Hadoop World が開催されました。今回は6000人の参加。5年前はTシャツ、ジーパンの人ばかりでしたが(それはそれで技術のフィードバックを得る上で大切なことですが)、今年は背広を来たビジネスマンが増えました。Hadoopが実システムに使われ始めたという現れかと思います。Wikibonの調査によれば、87%のユーザーがHadoopを複数のデータセンタで稼働させ、72%が24×7を必要としています。弊社のブースもNon-Stop Hadoopを理解しようという方が多く訪問されました。医療での事例は以下でご覧頂けます(日本語の字幕あり)

一方、日本で11月初めに行われたCloudera World Tokyo 2014の参加者は650名程度。弊社も講演を行いました。Non-Stop Hadoopというテーマでまだ大規模な実システムが少ない日本の現状では、低調になるかと心配していたのですが60名の方に参加頂きました。日本でもそろそろ、実システムでのHadoopが必要になってきているのかと思われます。Non-Stop Hadoopは24×7の稼働を可能にしますが、データの複製を持つこともできるのでシステムを止めない移行、Version UPを可能とします。まだαリリース段階ですが、異なるディストリビューション間でデータを共有することも可能になります。最適なHadoopをベンダーロックインなしに使えるようになります。Hadoopが実システムに移行していく際に遭遇する色々な問題に対応できるものと思っております。

avatar

About Kenji Ogawa (小川 研之)

WANdisco社で2013年11月より日本での事業を展開中。
以前は、NECで国産メインフレーム、Unix、ミドルウェアの開発に従事。その後、シリコンバレーのベンチャー企業開拓、パートナーマネージメント、インドでのオフショア開発に従事。