これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
今回は、2016年に公開された論文「Evolve or Die: High-Availability Design Principles Drawn from Google's Network Infrastructure」をもとにして、Googleのネットワークインフラの信頼性を高めるための取り組みと、障害事例の分析結果を紹介します。
前回の図1で紹介したように、Googleのネットワークインフラは、次の3つのパートで構成されています。
この中でも、クラスターネットワークとB4は、データプレーンとコントロールプレーンを分離してソフトウェアでネットワークを制御する、SDN（Software Defined Network）のアーキテクチャーが採用されています。それぞれの詳細は、第13回〜第17回の記事を参考にしてください。そして、これらのネットワークの信頼性を確保する上での克服するべき課題として、次の点があげられています。
・大規模な異機種混在環境
クラウドの利用が広がるにつれて、大規模なサーバー環境では、常に一部の機器で故障が発生している前提でシステムを管理するという考え方が一般的になってきました。これは、ネットワークについても同様です。Googleの大規模なネットワークインフラでは、常に一部の機器に故障が発生している前提で管理を行う必要があります。この際、システム環境を均一化して、一部の機器の障害がシステム全体の稼働に影響を与えないようにするというのが、基本的な考え方になりますが、ネットワークのシステム環境を均一化するというのは、それほど簡単なことではありません。
たとえば、B2では、外部ISPとの相互接続性を確保するために、一般的なベンダー機器を使用する必要があります。この際、特定機器の潜在的な問題がシステム全体に影響を及ぼさないように、あえて、複数ベンダーの機器を混在させると言った対策が必要となります。あるいは、データセンターのクラスターネットワークにおいても、すべてのクラスターを一斉にアップグレードすることは不可能ですので、常に複数世代のネットワークが混在することになります。このように、アーキテクチャーや管理手法の異なる複数のネットワーク環境を効率的に維持・管理するための取り組みが必要となります。
・ネットワークトラッフィクの増加速度
図1は、前回紹介した論文「B4: Experience with a globally-deployed software defined WAN (PDF)」からの引用で、B4におけるSDNの機能拡張とトラッフィク増加の様子を表したものになります。数年の間に、驚くほどのトラッフィク増加が発生していることが分かります。このような急激なトラッフィク増加に対応するには、ネットワークの機能拡張を継続的に実施する必要があります。常に一部の機器で故障が発生しているばかりではなく、常に一部の機器でアップグレード作業が発生している前提でシステム構成を管理することが必要となります。
図1 B4の機能拡張とトラッフィク増加（論文からの引用）
・複雑な機器管理
SDN環境では、個々の機器の機能を抽象化することで、多数の異なる機器を統一的に管理することが可能になります。しかしながら、それでも個別の機器管理がまったく無くなるというわけではありません。API経由での管理に対応しておらず、古典的なCLIベースの自動化スクリプトが必要となる機器、あるいは、機器単位、さらには、チップ単位での管理作業を要求する管理ツールも数多く残ります。
・リソースに対する高い要求
ネットワーク機器の変更作業には、長時間を要するものがあります。たとえば、境界ルーターのアップグレード作業では、8時間以上の時間を要したこともあったそうです。あらゆるネットワーク環境は冗長化されているので、原理的には、サービスを停止せずに変更作業を行うことも可能です。ただし、長時間に渡って変更作業が続くと、一時的に冗長性が失われた状態となり、片系障害によるサービス停止の可能性が発生します。そのため、一般的には、該当のネットワークを使用するクラスター上のアプリケーションを他のクラスターに移動して、影響を受けるクラスターの利用を停止した状態でアップグレード作業を行います。しかしながら、あらゆる変更作業でこれを行っていると、アプリケーションが必要とするサーバーリソースを確保できなくなる恐れもあります。そのため、多くのアップグレード作業は、クラスターの利用を停止せずに実施する必要があります。
さらに、この論文では、ネットワークの冗長化を実現するための考え方も紹介されています。ここでは、電源やケーブルなどの物理レベルでの冗長化、あるいは、SDNのコントロールプレーンを構成する管理ソフトウェアの冗長化、そして、障害時の縮退によってネットワーク帯域が不足することのないように、さまざまな障害パターンを考慮したキャパシティプランニングを行うなど、システム管理の基本とも言える考え方がならんでいます。前回紹介したTE（Traffic Engineering）サーバーなど、グローバルなWAN環境全体を管理するコントローラーは、地理的に分散した環境で冗長化するなどの説明もなされています。その他には、変更手順のドキュメント化や定期的な障害テストの実施、そして、影響度の高い障害が発生した際は、必ず、「POST-MORTEM REPORTS」（障害の事後分析レポート）を作成することが紹介されています。
このPOST-MORTEM REPORTSでは、障害の影響を受けたサービス提供部門を含むすべての関係者が協力して、次のような内容がレポートにまとめられます。
そして、この論文では、これまでのPOST-MORTEM REPORTSを元にした、障害の発生状況、および、発生要因に関するデータがまとめられています。詳細については、論文を参照していただくことにして、ここでは主要なポイントを紹介します。まず、図2は、障害発生箇所についてのデータですが、クラスターネットワーク、B2、B4のそれぞれで、ほぼ同程度の数の障害が発生しており、コントロールプレーン、データプレーン、管理サーバーについても、やはり同程度の数になっています。これは、障害の発生は、本質的には、ネットワークのアーキテクチャーに起因するものではないことを示唆しています。
図2 ネットワークごとの障害発生件数（論文からの引用）
一方、前述のように、Googleのネットワークでは、ネットワークトラッフィクの増加に対応するための機能拡張がほぼ継続的に行われています。図3は、障害の発生原因をこのようなネットワークの拡張に関連付けて整理したグラフになります。該当の障害が発生した際に、機器のアップグレード（Upgrade）、新しいソフトウェアの展開（Roollout）、システム管理作業（MOp）、構成変更作業（Configuration）などが行われていたかどうか、あるいは、ソフトウェアのバグ（Bug）が要因となったかなどを示すものです。新しいソフトウェアの展開に伴ってバグが発見されるなど、１つの障害が複数の項目に該当することもあります。
図3 ネットワーク拡張作業と障害の関連性（論文からの引用）
この結果を見ると、管理作業に伴う障害の発生率が高いことがわかります。ただし、これは、管理作業の頻度とも比較して考える必要があります。論文の中では、典型的には、一週間の間に585回ものシステム管理作業が行われていた点が指摘されています。そしてまた、管理作業に次いで、ソフトウェアのバグも主要な原因の１つであることが指摘されています。この結果を見ると、ネットワークの機能拡張への要求と安定稼働への要求を両立することが、大規模ネットワークの管理における大きなチャレンジであることがよく理解できます。これは、システムの変更管理作業を減らせばよいというものではありません。さまざまな作業を頻繁に実施することにより、ソフトウェアの潜在的なバグを発見する可能性が高くなり、ソフトウェアの品質を保つ上では好ましい点も論文の中では指摘されています。
今回は、Googleのネットワークにおける信頼性向上への取り組みと障害事例分析に関する論文を紹介しました。論文の中では、より具体的な事例の説明や、管理作業や新たなソフトウェアの導入に伴う障害を防止するための手法についても解説がなされています。ネットワークに限らず、システムの安定稼働に関わる知見が得られる内容ですので、興味のある方は、ぜひ一度、目を通してみることをお勧めします。
次回は、データセンターのエネルギー効率に関する話題をお届けしたいと思います。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
