Google の著名なフェローである Urs Hölzle 氏が、Google のインフラストラクチャの拡張、連鎖的な障害への対処、現代のデータセンターにおけるフラッシュ ストレージの台頭の課題について語ります。
Google は、大規模なトラフィック需要に直面しても信頼性が期待できるテクノロジーを運用しています。
サービスを拡大するために、同社は MapReduce や Google File System などの多くのシステムを開発しました。これらはその後、Yahoo によってオープンソース化され、一般的なアプリケーションに組み込まれました。 Hadoop データ分析フレームワーク.
しかしその裏では、同社は双子の悪魔との戦いを続けていた。 カスケード フェイルオーバーと、サービスを大規模に拡張することでますます困難になる複雑さのレベル 持ってくる。
Urs Hölzle は Google のエンジニアリング担当初代副社長でした。 Google に入社する前は、オブジェクト指向言語の高性能実装に取り組んでいました。 Darpa の国家コンパイラ インフラストラクチャ プロジェクトに貢献し、Smalltalk および Smalltalk 用のコンパイラを開発しました。 ジャワ。
Hölzle 氏によれば、「大規模化するとすべてが壊れる」ため、Google はシステムの拡張を拡大しつつ、次のようなカスケード フェイルオーバーを回避するという綱渡りをしなければなりません。 今年 3 月に Gmail に影響を及ぼした障害.
Q: 物理的なインフラストラクチャに焦点を当てることとは別に、 データセンター、ソフトウェアを大規模に実行することで Google が得られる効率はあるのでしょうか?
A: そこには間違いなく非常に大きなメリットがあると思います。おそらく、物理的な効率から得られる以上のものです。 それは、オンプレミス サーバーを使用している場合、サーバーのサイズを適切なサイズに設定することがほぼ不可能だからです。 なぜなら、ほとんどのサーバーは実際には強力すぎるため、[サーバーを使用している] ほとんどの企業は比較的負荷が低いからです。 小さい。
[しかし] 何百万ものアカウントが 1 か所にある大規模な電子メール サービスを使用している場合は、その負荷に合わせてサーバーのプールのサイズを調整する方がはるかに簡単です。 負荷を集約すると、サーバーを適切に活用し続けることが本質的にはるかに簡単になります。
Google は社内ソフトウェア ツールの進化についてどのような計画を立てていますか?
明らかに進化があります。 たとえば、現在、ほとんどのアプリケーションは [Google ファイル システム (GFS)] を使用していません。 実際、私たちは GFS を段階的に廃止し、よく似た次世代ファイル システムを採用していますが、それはもう GFS ではありません。 拡張性が向上し、レイテンシー特性も優れています。 今から 3 年後には、フラッシュ メモリが登場し、より高速なネットワークとより高速な CPU が登場し、私たちのやりたいことが変わることになるので、それを廃止しようとすると思います。
素晴らしいことの 1 つは、今日誰もが Bigtable 圧縮データベースフラッシュを適切に処理する、より優れた Bigtable が将来的にあるとします。その場合、API が安定している限り、これらすべてのアプリケーションを移行するのは比較的簡単です。
MapReduce や Google File System などのバックエンド システムを導入することがいかに重要であるか — 他者による公開や適応を通じて、Hadoop などのオープンソース アプリケーションを生成する 企業？
[オープンソース] が誰もが必要とする最低レベルのオペレーティング システムから始まったという意味では、これは避けられない傾向です。 しかし、オープンソースの力は、Web サーバー用の Apache など、既存のインフラストラクチャを構築し続けることができることです。 現在、私たちはクラウドを通じて利用できる幅広いサービスに参入しています。
たとえば、クラスター管理自体、または何らかのオープンソース バージョンが実現するでしょう。なぜなら、誰もがそれを自分のものとして必要としているからです。 計算の規模が大きくなり、その問題は単一のマシンの管理ではなく、多数のマシン全体の管理になります。 彼ら。 平均的な IT ショップには、数百台の仮想マシン (VM) または必要なマシンが存在します。 したがって、彼らの仕事の多くはクラスタ管理に関するものであり、個々のクラスタの管理に関するものではありません。 VM。
多くの場合、計算が十分に安価であれば、あまり意味がありません。
...独自の解決策を講じてください。 独自のソリューションを実行できるかもしれませんが、オープンソース システム内にとどまるのではなく、ソフトウェア エンジニアリングの取り組みとその後の継続的なメンテナンスを正当化することはできないかもしれません。
あなたの役割において、あなたが対処する最も魅力的な技術的問題は何ですか?
大きな課題はそれほど変わっていないと思います。 失敗に対処することだと思います。大規模になると、何をしてもすべてが壊れてしまうからです。 それを合理的にきれいに処理し、実際に使用している人々からそれを隠そうとする必要があります。 システム。
大規模になると、何をしてもすべてが壊れてしまうため、合理的にきれいに対処し、実際にシステムを使用している人々からそれを隠そうとする必要があります。
その大きな理由は2つあります MapReduce-Hadoop は本当に人気があります. 1 つは、自動的に並列化され、マシン間で負荷分散が自動的に行われるため、並列化の問題が解決されることです。 しかし 2 つ目は、大規模な計算を行う場合、失敗に対処することです。 したがって、10 時間の計算の途中で [あなたの] マシンの 1 つが停止したとしても、大丈夫です。 それはただ起こるのです。
2 つ目はステートフルで可変な状態を扱うことだと思います。 MapReduce は簡単です。なぜなら、MapReduce に多数のファイルを指定してそれらを計算させるだけで、問題が発生してもやり直すだけで済むからです。 しかし、Gmail、IM、その他のステートフル サービスでは、セキュリティ (稼働時間とデータ損失) への影響が大きく異なります。
私たちがこの時代でもテープを使用しているのは、テープが Gmail の最後の手段として実際に非常に費用対効果の高い方法であるためです。 これを入れた理由は物理的なデータの損失ではありませんが、一度は、すべてのコピーを破壊するバグに遭遇するでしょう。 オンライン データであり、唯一の保護は、同じソフトウェア システムに接続されていないものを保持することです。そうすれば、やり直すことができます。 それ。
私たちが直面している最後の課題は、汎用ハードウェアを使用しながら、急速なイノベーション サイクルに直面してもそれを実際に機能させることです。 たとえば、これは新しい HDD (ハードディスク ドライブ) です。 市場では、それを世に出さなければならないという大きなプレッシャーがかかっています。 3TBドライブ 多くのコスト圧力がありますが、実際にこれらのドライブの信頼性を高めるにはどうすればよいでしょうか?
大規模ユーザーとして、私たちはすべての例外的なケースを確認しており、たとえそれが出荷時のハードウェアであっても、使用するほぼすべてのハードウェアにバグが見つかります。
同じオペレーティング システムを使用している場合、次のように Linux10,000 台のマシンで同じ計算を実行し、毎日そのうち 100 台が失敗すると、「これは間違っている」と言うでしょう。 しかし、自分でやった場合、失敗率は 1 パーセントです。 したがって、年に 3 回はサーバーを変更する必要があります。 おそらく、デバッグに労力を費やさず、偶然のまぐれだと考えるか、デバッグしてももう起こらないと考えるでしょう。
すべてのサービスが相互に通信できるようにしたいようです。 しかし、これはそれ自体が複雑な問題を引き起こすのではないでしょうか?
自動化は重要ですが、危険でもあります。 バグがある場合は、すべてのマシンを自動的にシャットダウンできます。 均一性と自動化が必要なため、これは非常に難しい作業の 1 つですが、 同時に、多くの安全策がなければ、すべてを実際に自動化することはできません。そうしないと、連鎖的な障害が発生します。
物事をシンプルに保ちながらスケーラブルに保つことが、実際には最大の課題です。
複雑さは、物事の大局的には悪です。なぜなら、複雑さによって、目に見えないバグが潜んでいる可能性があるからです。 2、3 年に 1 度しかありませんが、実際に見ると大きな話題になります。 効果。
物事をシンプルに保ちながらスケーラブルに保つことが、実際には最大の課題です。 本当に本当に大変です。 ほとんどのことは大規模ではそれほどうまく機能しないため、ある程度の複雑さを導入する必要がありますが、それを抑える必要があります。
次のような新しいハードウェアを調べたことがありますか? PCIeリンクフラッシュ?
私たちはアプリオリに何かを排除しているわけではなく、常に物事をいじっています。 PCIe フラッシュはオペレーティング システムにフラッシュを公開する非常に優れた方法であるため、PCIe フラッシュが商品になると私は期待しています。 しかし、フラッシュは耐久性があまり良くないので、まだ難しいです。
これらはすべて、アプリケーションの作成方法に大きな影響を与える可能性があると思います。 可動ヘッドではなく、このような記憶媒体にデータを保存すると、1,000 倍のデータが膨大になります。 違い。 しかし、これらのものは、ストレージ コストの点でまだディスクに達していません。
最新のテクノロジー ニュースや分析、ブログ、レビューを入手してください。 あなたの受信箱に直接配信されます ZDNet英国のもの。 ニュースレター.