IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

 [IT研修]注目キーワード   OpenStack  OpenFlow/SDN  情報セキュリティ  Python  システムトラブルシュート 

第18回 ネットワークインフラの信頼性と障害事例分析 (中井悦司) 2017年6月

はじめに

 今回は、2016年に公開された論文「Evolve or Die: High-Availability Design Principles Drawn from Google's Network Infrastructure」をもとにして、Googleのネットワークインフラの信頼性を高めるための取り組みと、障害事例の分析結果を紹介します。

 

ネットワークの基本構成と管理上の課題

 前回の図1で紹介したように、Googleのネットワークインフラは、次の3つのパートで構成されています。

  • クラスターネットワーク:データセンター内のサーバー群を相互接続するネットワーク
  • B2:外部ISPと相互接続するためのグローバルネットワーク
  • B4:データセンター内のアプリケーションが相互通信するためのグローバルな内部ネットワーク

 この中でも、クラスターネットワークとB4は、データプレーンとコントロールプレーンを分離してソフトウェアでネットワークを制御する、SDN(Software Defined Network)のアーキテクチャーが採用されています。それぞれの詳細は、第13回〜第17回の記事を参考にしてください。そして、これらのネットワークの信頼性を確保する上での克服するべき課題として、次の点があげられています。

 

・大規模な異機種混在環境

 クラウドの利用が広がるにつれて、大規模なサーバー環境では、常に一部の機器で故障が発生している前提でシステムを管理するという考え方が一般的になってきました。これは、ネットワークについても同様です。Googleの大規模なネットワークインフラでは、常に一部の機器に故障が発生している前提で管理を行う必要があります。この際、システム環境を均一化して、一部の機器の障害がシステム全体の稼働に影響を与えないようにするというのが、基本的な考え方になりますが、ネットワークのシステム環境を均一化するというのは、それほど簡単なことではありません。
 たとえば、B2では、外部ISPとの相互接続性を確保するために、一般的なベンダー機器を使用する必要があります。この際、特定機器の潜在的な問題がシステム全体に影響を及ぼさないように、あえて、複数ベンダーの機器を混在させると言った対策が必要となります。あるいは、データセンターのクラスターネットワークにおいても、すべてのクラスターを一斉にアップグレードすることは不可能ですので、常に複数世代のネットワークが混在することになります。このように、アーキテクチャーや管理手法の異なる複数のネットワーク環境を効率的に維持・管理するための取り組みが必要となります。

 

・ネットワークトラッフィクの増加速度

 図1は、前回紹介した論文「B4: Experience with a globally-deployed software defined WAN (PDF)」からの引用で、B4におけるSDNの機能拡張とトラッフィク増加の様子を表したものになります。数年の間に、驚くほどのトラッフィク増加が発生していることが分かります。このような急激なトラッフィク増加に対応するには、ネットワークの機能拡張を継続的に実施する必要があります。常に一部の機器で故障が発生しているばかりではなく、常に一部の機器でアップグレード作業が発生している前提でシステム構成を管理することが必要となります。

fig01

図1 B4の機能拡張とトラッフィク増加(論文からの引用)

 

・複雑な機器管理

 SDN環境では、個々の機器の機能を抽象化することで、多数の異なる機器を統一的に管理することが可能になります。しかしながら、それでも個別の機器管理がまったく無くなるというわけではありません。API経由での管理に対応しておらず、古典的なCLIベースの自動化スクリプトが必要となる機器、あるいは、機器単位、さらには、チップ単位での管理作業を要求する管理ツールも数多く残ります。

 

・リソースに対する高い要求

 ネットワーク機器の変更作業には、長時間を要するものがあります。たとえば、境界ルーターのアップグレード作業では、8時間以上の時間を要したこともあったそうです。あらゆるネットワーク環境は冗長化されているので、原理的には、サービスを停止せずに変更作業を行うことも可能です。ただし、長時間に渡って変更作業が続くと、一時的に冗長性が失われた状態となり、片系障害によるサービス停止の可能性が発生します。そのため、一般的には、該当のネットワークを使用するクラスター上のアプリケーションを他のクラスターに移動して、影響を受けるクラスターの利用を停止した状態でアップグレード作業を行います。しかしながら、あらゆる変更作業でこれを行っていると、アプリケーションが必要とするサーバーリソースを確保できなくなる恐れもあります。そのため、多くのアップグレード作業は、クラスターの利用を停止せずに実施する必要があります。

 

POST-MORTEM REPORTSによる障害の傾向分析

 さらに、この論文では、ネットワークの冗長化を実現するための考え方も紹介されています。ここでは、電源やケーブルなどの物理レベルでの冗長化、あるいは、SDNのコントロールプレーンを構成する管理ソフトウェアの冗長化、そして、障害時の縮退によってネットワーク帯域が不足することのないように、さまざまな障害パターンを考慮したキャパシティプランニングを行うなど、システム管理の基本とも言える考え方がならんでいます。前回紹介したTE(Traffic Engineering)サーバーなど、グローバルなWAN環境全体を管理するコントローラーは、地理的に分散した環境で冗長化するなどの説明もなされています。その他には、変更手順のドキュメント化や定期的な障害テストの実施、そして、影響度の高い障害が発生した際は、必ず、「POST-MORTEM REPORTS」(障害の事後分析レポート)を作成することが紹介されています。
 このPOST-MORTEM REPORTSでは、障害の影響を受けたサービス提供部門を含むすべての関係者が協力して、次のような内容がレポートにまとめられます。

  • 障害の発生箇所と発生期間
  • トラフィックへの影響、パケットロスの発生率、サービスへの影響
  • 障害発生前後に発生した事象の時系列に従った記述
  • 障害発生の根本原因と関連するアーキテクチャー図
  • 再発防止のアクションアイテム

 そして、この論文では、これまでのPOST-MORTEM REPORTSを元にした、障害の発生状況、および、発生要因に関するデータがまとめられています。詳細については、論文を参照していただくことにして、ここでは主要なポイントを紹介します。まず、図2は、障害発生箇所についてのデータですが、クラスターネットワーク、B2、B4のそれぞれで、ほぼ同程度の数の障害が発生しており、コントロールプレーン、データプレーン、管理サーバーについても、やはり同程度の数になっています。これは、障害の発生は、本質的には、ネットワークのアーキテクチャーに起因するものではないことを示唆しています。

fig02

図2 ネットワークごとの障害発生件数(論文からの引用)

 

 一方、前述のように、Googleのネットワークでは、ネットワークトラッフィクの増加に対応するための機能拡張がほぼ継続的に行われています。図3は、障害の発生原因をこのようなネットワークの拡張に関連付けて整理したグラフになります。該当の障害が発生した際に、機器のアップグレード(Upgrade)、新しいソフトウェアの展開(Roollout)、システム管理作業(MOp)、構成変更作業(Configuration)などが行われていたかどうか、あるいは、ソフトウェアのバグ(Bug)が要因となったかなどを示すものです。新しいソフトウェアの展開に伴ってバグが発見されるなど、1つの障害が複数の項目に該当することもあります。

fig03

図3 ネットワーク拡張作業と障害の関連性(論文からの引用)

 

 この結果を見ると、管理作業に伴う障害の発生率が高いことがわかります。ただし、これは、管理作業の頻度とも比較して考える必要があります。論文の中では、典型的には、一週間の間に585回ものシステム管理作業が行われていた点が指摘されています。そしてまた、管理作業に次いで、ソフトウェアのバグも主要な原因の1つであることが指摘されています。この結果を見ると、ネットワークの機能拡張への要求と安定稼働への要求を両立することが、大規模ネットワークの管理における大きなチャレンジであることがよく理解できます。これは、システムの変更管理作業を減らせばよいというものではありません。さまざまな作業を頻繁に実施することにより、ソフトウェアの潜在的なバグを発見する可能性が高くなり、ソフトウェアの品質を保つ上では好ましい点も論文の中では指摘されています。

 

次回予告

 今回は、Googleのネットワークにおける信頼性向上への取り組みと障害事例分析に関する論文を紹介しました。論文の中では、より具体的な事例の説明や、管理作業や新たなソフトウェアの導入に伴う障害を防止するための手法についても解説がなされています。ネットワークに限らず、システムの安定稼働に関わる知見が得られる内容ですので、興味のある方は、ぜひ一度、目を通してみることをお勧めします。

 次回は、データセンターのエネルギー効率に関する話題をお届けしたいと思います。

 

Disclaimer:この記事は個人的なものです。ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません。

 


 

 [IT研修]注目キーワード   OpenStack  OpenFlow/SDN  情報セキュリティ  Python  システムトラブルシュート