SQLが十分でない場合：大規模な新しいデータセンターの制御

コンテンツ

• Googleファイルシステム：ビッグケーススタディ
• バグやストレスなし-あなたの人生を破壊することなく人生を変えるソフトウェアを作成するためのステップバイステップガイド
• コアテクノロジーの概要
• 他の大きなシステムはこれをどのように達成しますか？
• DFSの維持

取り除く：

開発者とエンジニアは、1990年代の古典的なアーキタイプをはるかに超えて成長したプラットフォーム上で、サービスの高速化と改善を継続的に行う必要があります。

私たちの私生活に関する膨大なデータビットを保持している膨大なNSAデータセンターに関するすべての話題で、少なくともCNNについてはあまり話題にされていないことが1つあります。これには、クラウドテクノロジー、ビッグデータ、および現在世界中で構築されている印象的な物理データストレージセンターとともに発生したエンジニアリングの問題が含まれます。それで何ですか？これらの施設を運営する巨大なITシステムの管理者が誰であろうと、そのデータのすべてをパイプラインに迅速に出し入れできるソフトウェアシステムが必要です。このニーズは、今日のプロフェッショナルが直面する最も興味深いITの質問またはパズルの1つです。

多くの専門家が指摘するように、データ処理に対する今日の極端な需要は、従来のアプローチをはるかに超えています。簡単に言えば、単純なデータベース構造とSQLクエリインターフェイスなどのツールを使用しても、過去数年間に開発された独自のシステムに十分な処理能力や機能を提供することはできません。今日の大企業のアーカイブには、非常にスケーラブルな技術が必要です。単一のサーバーで実現できるよりもはるかに高いボリュームで結果を入出力できるデータ処理ツールが必要です。彼らは、成長のために迅速に立ち上げることができるソリューション、人工知能の複雑なレベルを含むソリューション、IT部門による管理を容易にするために設計されたソリューションを必要としています。

問題は、企業や政府機関が従来のデータ処理経路の限界をどのように克服するかです。ここで、1つの非常に有望なオプションを見てみましょう。ビッグデータと複数のデータセンターの管理を処理するソフトウェアです。

Googleファイルシステム：ビッグケーススタディ

Googleがデータセンターにアクセスするために使用する独自技術は、ビッグデータの処理と複数のデータセンターの管理のための一般的なモデルの最良の例の1つです。 2003年に開発されたGoogleファイルシステム（GFS）は、何百万人ものユーザーがクリックする単一のプラットフォームに大量の新しい情報を出し入れするデータシステムの膨大な量の高速修正をサポートするように設計されています。同じ時間。専門家はこれを分散ファイルシステムと呼び、「データオブジェクトストレージ」という用語を使用して、これらの非常に複雑な手法を説明しています。ただし、実際には、これらの用語は、作業内容を表す用語で表面を傷つけることすらありません。

個別に、GFSのようなシステムを構成する機能とコンポーネントは、画期的なものではないかもしれませんが、複雑です。それらの多くは、新しい常時接続の常時接続グローバルITシステムの基盤の一部である比較的新しいイノベーションとして、このサイトで取り上げられています。集合的に、GFSのようなシステムは、その部分の合計をはるかに超えています。個々のデータがこのように投げ込まれ、視覚的に完全にモデル化された場合はカオスのように見えるプロセスでいっぱいの、ほとんど見えないが非常に複雑なネットワークです。すべてのデータの行き先を理解するには、多くのエネルギーとコミットメントが必要です。これらのシステムの戦闘ステーションに配属されている人たちは、すぐに認めるでしょう。

「外部および内部の断片化、ログベースの更新とインプレースの更新、トランザクションの一貫性のレベルなど、使いやすさの領域に大きな影響を与える詳細が多すぎるため、1つの簡潔な文で動作を要約できません。 」とSanbolicのCEO兼共同設立者であるMomchil Michailov氏は言います。

「分散ファイルシステムは、ローカルネームスペースと参加ノードの空きスペースの分散アグリゲーター、または分散ロックマネージャーコンポーネントの助けを借りて共有ストレージにアクセスする複数のノードで実行されるローカルファイルシステムです。」

Kerry Lebelは、スケーラブルな自動化プラットフォームで知られるAutomicのシニアプロダクトマネージャーです。 Lebelは、DFSを、低コストのハードウェアに接続されたサーバーにワークロードを単純に割り当てるシステムとして説明するのは正確ですが、実際には全体を語っていないと言います。

バグやストレスなし-あなたの人生を破壊することなく人生を変えるソフトウェアを作成するためのステップバイステップガイド

誰もソフトウェアの品質を気にしない場合、プログラミングスキルを向上させることはできません。

「行方不明になるのは、すべてのクールな要因です どうやって 彼らは彼らがすることをします」とレーベルは言った。

技術的な詳細から離れて、分散ファイルシステムの背後にある基本的なアイデアを考えるだけで、Lebelが語る「クールファクター」は明らかです。これらのビッグデータ処理システムは、古いファイル/フォルダシステムを、複数の配信システムだけでなく、ボトルネックを防ぐために膨大な数のユニットをあちこちに配置する「オブジェクト指向」アプローチを含む構造に置き換えます。

たとえば、数十万台の車がただちにマルチレーンを通過するのではなく、きちんとした小さなクローバーリーフまたはオックスボウの支流にすくい上げられ、回転して送られる最先端の高速道路システムを考えてみてくださいさまざまな迂回の目的地に向かって。空から見ると、すべてがスイスの時計のように振り付けられているように見えます。それは、エンジニアがさまざまなレベルの多層データ包含スキーマに「キック」することによって制限を回避するための情報をルーティングする新しい方法を考えているときに見る一種の視覚モデルです。仕様は別として、これが処理システムの最上位の目標です。組み込みメタデータを持つ自己完結型オブジェクトを必要な場所に最高速度で移動し続ける、一貫性目標を達成する、エンドユーザーを満足させる、またはトップレベルの観察や分析を通知することさえできます。

コアテクノロジーの概要

Ars Technicaに掲載されたSean Gallagherの記事は、GFSの設計をやや扱いやすい部分に分割し、Googleのシートの下にあるものを示唆しています。

GFSは、データの読み取りと書き込みのための冗長でフォールトトレラントなモデルから始まります。ここでの考え方は、特定の更新を単一のドライブに書き込むのではなく、新しいシステムがデータのチャンクを複数の宛先に書き込むことです。そうすれば、1つの書き込みが失敗しても、他の書き込みは残ります。これに対応するために、1つのプライマリネットワークコンポーネントがデータ処理を他の下位ユニットにファームし、クライアントがデータを「呼び出し」たときにデータを再集計します。これはすべて、特定の更新と送信結果がより大きなシステム内のどこにあるかを特定するのに役立つメタデータプロトコルによって可能になります。

これのもう1つの非常に重要な側面は、これらの重複する重いシステムがどのようにデータの一貫性を強化するかです。 Gallagherが指摘しているように、GFSの設計は一貫性を犠牲にして「アトミック性を強制」するか、複数のストレージユニットでデータがどのように更新されるかの原則を守ります。 Googleの「緩和された一貫性モデル」は、一貫性を強化するためのより長い時間枠の見返りに、より柔軟性を提供するBASEモデルの本質的な理論に従っているようです。

他の大きなシステムはこれをどのように達成しますか？

「十分に大規模に達すると、データの矛盾または破損が避けられなくなります」とミチャイロフは言います。 「したがって、分散ファイルシステムの主な目標は、破損が発生した場合にできるだけ多くの操作を実行し、同時に破損に対処する効率的な方法を提供することです。」 Michailovは、冗長性を慎重に実装することでパフォーマンスを維持する必要性についても言及しています。

「たとえば、各ディスクにメタデータ（データに関するデータ）を作成すると、ミラーコピーが破損した場合にそのディスクが適切なデータ構造を再構築できるようになります」とMichailov氏は述べています。 「さらに、RAIDシステムレベルを使用して、ファイルシステムアグリゲーターレベルまたは共有ボリュームマネージャーレベルのいずれかでストレージ障害に対処できます。」

別の整合性モデルについて議論する際に、LebelはHadoop分散ファイルシステム（HDFS）と呼ばれるシステムに焦点を当て、これを「業界のデファクトスタンダード」と呼びます。

HDFSでは、各データブロックは異なるノードと2つの異なるラックに3回複製されます。データはエンドツーエンドでチェックされます。障害は、破損したブロックを取り除き、新しいブロックを作成するデータハンドラーであるNameNodeに報告されます。

これらはすべて、これらの大量データシステムの整合性にとって非常に重要な種類の「クリーンデータ」をサポートしています。

DFSの維持

GFSのもう1つの非常に異なる外観は、WiredのライターSteven Levyによる2012年10月の記事からのものです。 Googleの集合的なトップダウンネットワーク処理のためのソフトウェアアプローチを特徴付けるのははるかに簡単です。

「長年にわたって、Googleは無数のサーバーをまるで1つの巨大なエンティティであるかのように管理できるソフトウェアシステムを構築しました。社内の開発者は操り人形マスターのように振る舞い、 1台のマシンを実行するのと同じくらい簡単にタスクを実行できます。」

これを行うには、サーバーシステムを「破壊」しようとする専任のテストチームから、データクリプトのホール全体の温度を慎重に制御するまで、大量のサイバーベースの環境メンテナンスが必要です。

Levyは、クラウドアプリケーションツールであるMapReduceや、GFSといくつかの設計原則を共有する分析エンジンであるHadoopなど、GFSの補足技術にも言及しています。これらのツールは、大規模なデータセンター処理システムの設計方法や、今後登場する可能性のあるものに独自の影響を与えます。 （これらのテクノロジーの詳細については、「ビッグデータの進化」をご覧ください。）

Michailovは、MapReduceがこれまでにないデータセンターシステムをサポートする可能性があると考えており、ストレージ用のSSDを備えた共有クラスター内の統合ファイルシステムの名前ノードを維持できる共有および統合ファイルシステムの「単一実装」について語っています」

Lebelは、バッチ処理（Hadoopがサポートする方法）からストリーム処理への移行を期待しています。これにより、これらのデータ操作がリアルタイムに近づきます。

「データをより速く処理し、ビジネスの意思決定者または顧客が利用できるようになるほど、競争上の優位性が高まります」とLebel氏は述べ、上記の処理用語を、エンドユーザー。 「同期」アクティビティ、またはエンドユーザーアクションと同期されるアクティビティ、および実装の観点からより柔軟性のある「非同期」アクティビティについて考えることで、リーベルは、企業が特定のサービスシステムの動作方法を定義するためにSLAおよびその他のリソースを使用できると言います。

要するに、開発者とエンジニアは、1990年代の古典的な原型をはるかに超えて成長したプラットフォーム上でサービスを高速化し、改善するために継続的に取り組む必要があるということです。それは、データの仕組みを批判的に見て、人口の増加だけでなく、専門家が「次の産業革命」と呼んでいる急激な速度で起こる指数関数的な変化をサポートする方法でボトルネックを突破することを意味します。これらの面で最も基礎を破る人は、将来の市場と経済で支配的になる可能性が高いです。