【IIJ GIOの裏側を語る#4】 無停止運用を目指したライブマイグレーション

カテゴリー: 裏側を語る
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第4回です。

前回の本ブログで触れたとおり、今回はP2の運用プロセスについてお話しします。
解説者は引き続き、IIJクラウド本部の田口です。

keisuk-t_01_150

執筆者の紹介

株式会社インターネットイニシアティブ
クラウド本部 クラウドサービス1部 部長
田口 景介

「第4回:無停止運用を目指したライブマイグレーション」

突然ですが、以下の図は、昨年のカレンダーにメンテナンスを実施した日にチェックを付けた記録です。

giomente3

ご覧になっていかがでしょうか。多いと感じられますか?それとも見慣れた頻度に感じられますか?おそらく、大半の方には、単一システムのメンテナンス頻度としては、度を超えて多いと感じられるのではないでしょうか。

それぞれのメンテナンスは大小様々です。
大掛かりな新サービスメニューをリリースするメンテナンス、定期的に実施されるサーバプールやストレージの増設メンテナンス、ハードウェア障害に伴う保守交換作業、脆弱性対応のための緊急システムアップデート、一部リソースにかかる負荷を平準化させるためのマイグレーションなど、内容は多岐にわたります。

これだけの頻度でメンテナンスが実施されるのは、それだけIaaSというものが他のサービスに比較して相当に複雑なものであり、数十のマイクロサービスから構成されていることが理由の一つです。

サービスを停めないメンテナンス戦略

かようにP2では頻繁にメンテナンスが実施されているわけですが、実のところサービス停止を伴うメンテナンスは1度しか行われていません。しかも、それはコントロールパネルが停止されるだけで、仮想サーバやネットワークアプライアンス類のリソースが停止するものではありません。

P2をご利用いただいているお客様にも、これほどメンテナンスが実施されているとは思われていないのではないでしょうか。

それはIaaSとして当然のように感じられるかもしれませんが、何の戦略もなく実現することではありません。サービスの設計段階からシステムの更新を無停止で行うことをスペックに盛り込み、実装されているからこそ可能なのです。

また、メンテナンスを無停止で実行できるということは、障害に対する可用性が高いことも意味しています。残念ながら昨年ネットワーク障害に起因するサービス停止を発生させてしまいましたが(大変申し訳ありません・・・)、それを除けば設計どおりの品質を担保できたのではないでしょうか。

避けられないハードウェア障害

もっとも、サーバのハードウェア障害はいかんともしがたく、即仮想サーバの停止に至ります。

稀にクラウドサービスはいかなる障害にも耐性があると思われ、たとえサーバにハードウェア障害が起ころうとも無停止で利用できることを期待される方がいらっしゃいます。しかし、IaaSにおいてサーバの冗長化は利用者の責任とされていますので、この点はどうかご容赦ください。

もっとも、いったん停止しても自動的に別筐体が割り当てられるので、すぐに起動が可能です。また、グループを分けてアクティブ・スタンバイに構成することで、物理的にネットワークやサーバを分離して複数の仮想サーバを収容することが可能です。

ハイパーバイザのメンテナンス

それでは、ハードウェア障害による停止はやむを得ないとして、仮想サーバが収容されるハイパーバイザノードにメンテナンスが必要になった場合、どうなるでしょう?

もしハイパーバイザの再起動が必要となれば、それは障害発生時と同じことで、仮想サーバの停止を伴うことになります。IaaS基盤の都合に合わせてお客様の仮想サーバを停止することはおいそれとできませんが、かといって仮想サーバを動かしたままハイパーバイザをアップデートすることもできません。

そこで活躍するのがライブマイグレーションです。ご存じの方も多いと思いますが、ハイパーバイザからハイパーバイザへ、仮想サーバを停めることなく移動させる技術です。

P2の運用にはライブマイグレーションが積極的に活用されており、メンテナンスが必要な時、あるいは特定のリソースに過剰な負荷が集中しているとき、ライブマイグレーションを利用して仮想サーバを停めずにさまざまな作業を実施しています。

hyper_5

ライブマイグレーションを前提とした設計

ただし、ライブマイグレーションは便利な技術ですが、どんなIaaSでも利用されているわけではありません。それは、利用を前提にサービスがデザインされていなければならないからです。

ライブマイグレーションとは、仮想サーバのCPUやメモリなどの状態を別ハイパーバイザ上へ転送し、後にストレージをつなぎ直し、IPアドレス等のリソースを再度割り当てることで、仮想サーバを移動させる技術です。これを短時間に実行するために、ローカルディスクのように別筐体へつなぎ直すことができないストレージはサービススペックに盛り込めません。逆に言えば、ローカルディスクを提供しているIaaSでは、ライブマイグレーションを利用できない可能性が高いのです。

また、ごくまれにゲストOS(の特定のカーネルバージョン)によっては、ライブマイグレーションに失敗するケースが存在します。例えば、一見マイグレーションに成功したかに見えても、パケットを受信できなくなるなどの症状が発生し得ます。したがって、検証済みのOSのみ利用できるようにすることがサービスを安定運用する一つの条件になります。

つまり、サービスを安定運用するためのライブマイグレーションと、いくつかのサービススペックの有無はトレードオフの関係にあるのです。

膨大なサーバを半自動的にアップデートする仕組み

もっとも、ライブマイグレーションが利用できたとしても、数千、数万というサーバから構成されるIaaS基盤において、仮想サーバを一切停めずにハイパーバイザのアップグレードを実施するのは簡単なことではありません。手作業では困難なものになることは容易に想像ができるでしょう。

その点、P2の基盤にはハイパーバイザを半自動的にアップデートする仕組みが実装されていますし、必要とあらばライブマイグレーションを活用することもできるので、無停止でハイパーバイザを更新することが可能です。その仕組みを簡単に紹介しましょう。

まず、P2のハイパーバイザサーバは起動時に最新のソフトウェアを使ってリモートブートし、自動的に構成されて稼働を始めます。つまり、サーバを再起動するだけで最新のハイパーバイザへアップデートが完了します。

そこで、まず仮想サーバを一つも収容していない空のハイパーバイザサーバへ再起動するように指示を出します。すると、それ以降に起動される仮想サーバはアップデート済みのハイパーバイザにだけ収容される仕組みになっているので、仮想サーバが停止されるに従い旧バージョンのハイパーバイザから仮想サーバが抜けていきます。

そして、空になったハイパーバイザは自動的に再起動され、徐々にアップデートが進んでいきます。その後、一定期間経過してもアップデートされていないサーバのみライブマイグレーションを利用し、手作業でのアップデートを実行、これで完了です。

このように、随所に無停止かつ自動化された運用プロセスがサービス開発当初から計画されており、それがサービスデザイン、システムデザインに反映されているがゆえに、常にセキュアで安定したIaaSがご提供できているのです。


次回は、他社と一線を画すIIJのVMwareサービス「VWシリーズ」について解説します。

IIJ GIOサービスアップデート(2016年12月分) — Arcserve社ソフトウェアの月額提供を開始しました。

カテゴリー: インフラストラクチャーP2, サービスアップデート, ホスティングパッケージ
このエントリーをはてなブックマークに追加

あけましておめでとうございます。サービス企画部の鍋倉です。

昨年の12月で、IIJ GIOサービスは提供開始から丸7年となりました。
これまで、皆様よりたくさんのご意見等をいただきながら、IIJ GIOサービスの改善に努めてまいりました。これからも一層皆様のビジネスを支援していくためのサービス・機能をご提供できるよう、サービス開発・改善に邁進していきます。
本年もIIJ GIOサービスをよろしくお願いいたします。

それでは2017年1回目の、IIJ GIOのリリース・アップデート情報をお届けします。

2016年12月のIIJ GIOサービス更新情報

IIJ GIOインフラストラクチャーP2

リリース日:2016/12/21

プライベートリソース サービスコネクタ リリース

サービスコネクタの下記2品目をリリースしました。

  • サービスコネクタ 1Ux2/IIJマネージドファイアウォールサービス
  • サービスコネクタ 2Ux2/IIJマネージドファイアウォールサービス

サービスコネクタを利用すると、P2プライベートリソースと他のIIJのサービスで提供される機器を組み合わせて利用することが可能になります。
今回リリースした品目は、IIJマネージドファイアウォールサービスとL2接続での連携を実現します。
IIJマネージドファイアウォールサービスについては、サービスページを参照ください。

IIJサブスクリプションライセンス

リリース日:2016/12/12

Arcserve ライセンス提供開始

IIJサブスクリプションライセンスにて、2016年12月12日からArcserve社のバックアップソフトウェア製品の提供を開始しました。提供可能なソフトウェア製品は、以下のシリーズになります。

  • Arcserve Backup
  • Arcserve UDP
  • Arcserve Backup for UDP
  • Arcserve Replication/High Availability

サーバのバックアップ、リカバリー、データファイルコピー等を行うソフトウェアとなります。ソフトウェアパッケージを購入することなく、IIJ GIO P2などと組み合わせて、月額料金にてご利用いただけます。
仕様については、Arcserve 社のオフィシャルサイトをご覧ください。

IIJ GIOホスティングパッケージサービス

リリース日:2016/12/21

CentOS 7 提供開始

IIJ GIOホスティングパッケージサービスにて、CentOS 7の提供を開始しました(※1,2)

  • (※1)ベーシックプランのみの提供となります。
  • (※2)OSアーキテクチャは、x64(64bit版)のみとなります。

IIJは本年も、安全で便利に利用いただけるクラウドサービスを提供してまいります。

(クラウド本部 サービス企画部 鍋倉)

【IIJ GIOの裏側を語る#3】 自社開発に拘るクラウドオーケストレータ

カテゴリー: 裏側を語る
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第3回です。

前回に続き、IIJクラウド本部の田口が「自社開発に拘るクラウドオーケストレータ」をテーマに解説します。

keisuk-t_01_150

執筆者の紹介

株式会社インターネットイニシアティブ
クラウド本部 クラウドサービス1部 部長
田口 景介

「第3回:自社開発に拘るクラウドオーケストレータ」

サービスを構成するソフトウェアにオープンソースのプロダクトは欠かせません。OS、Webサーバ、アプリケーションサーバ、データベース、etc…。ご多分に漏れず、P2のシステムでもCentOS、MySQL、Railsなどが随所に利用されています。

一方で、サービスのコアとなるシステムは、当然ながらサービス固有のソフトウェアで構成されます。P2を構成する多数のマイクロサービス群は、ほとんどが自社開発のIIJ独自技術が満載されたものになっているのです。

今回はその辺りの自社開発に込められたこだわりの部分に触れたいと思います。

OpenStackと自社基盤

実は、3年前にIIJ GIOのIaaSを抜本的にリニューアルすることが決まった際、OpenStackの採用も検討しました。

OpenStackの品質にいささか不安はありましたが、プロビジョニングシステムとしては完成度を高めつつありました。さらに、オンプレでOpenStackの導入を検討されているお客様から、ハイブリッドクラウドを構成するにはパブリッククラウド側もOpenStackで構成されていると都合が良いとの声もいただいていました。
それに、サードパーティから提供されるさまざまなドライバ等、今後OpenStackをとりまく環境が充実していくであろうことに魅力を感じていたことも事実です。

ですが、やはり最終的には既存の自社基盤を大幅にアップデートすることで、サービス全体のエンハンスを進めていく方針に決定しました。その過程には紆余曲折がありました。

しかし今振り返ってみると、システムの可用性や運用の効率化を高いレベルで実現するには、やはり自社基盤に一日の長ありと判断したことは間違いではなかったと思います。

small_key

運用プロセスがサービスデザインに反映されたP2

サービスを成長させていくためには、魅力的な機能を提供していくことはもちろんのことですが、長期的に安定してサービス提供されることが同等以上に大事なことだと考えています。なんらかのメンテナンスの度に停止を伴うようでは、お客様に安心してシステムをお預けいただくことは難しいでしょう。

P2はこの点を重視して、サービスデザインの段階から運用プロセスを合わせて設計しています。障害にしろメンテナンスにしろ、極力止まらないクラウドを目指して開発が進められました。

これはIIJ GIOだけでなく、長年のあいだ自社サービス基盤を運用してきた実績から得られた知見に基づくものです。これだけの大規模なシステムで起こりうる課題を把握し、その対応策をシステム設計に反映するのは、そう簡単に真似できるものではありません。

実際にP2をサービスインしてから1年がたちましたが、機能停止をともなうメンテナンスは一度しか行っていません。その裏では数々のハードウェア障害や数百回に及ぶ大小さまざまなメンテナンスが実施されているのですが、それをお客様が意識することはほとんど無かったはずです。

お客様の仮想マシンが稼働するハイパーバイザに脆弱性が発覚したこともありましたが、それすらも大半のお客様には影響を及ぼすことなく対応を終えています。

運用に高度なノウハウが求められるOpenStack

一方、OpenStackを取り巻く環境は日々変わっているものの、少なくとも検討段階では可用性を考えるといくつか不安がありました。

まず、OpenStackは半年ごとのリリースサイクルが取られていますが、古いパッケージはセキュリティアップデートも比較的早い段階で終わり、EOL(End Of Life)を迎えます。つまり、セキュアな基盤を維持するためには毎年アップデートを続けなければならないということです。しかも、無停止でアップデートを成功させるには、かなりのノウハウが必要とされることは明白でした。

このことはOpenStackに独自の改修を行うのであれば、アップデートのたびに新パッケージへ改修箇所を追随させていかなければならないことも意味します。さらには、OpenStackのいくつかのコンポーネントは冗長構成を独自に検討しなければならず、これもまた大きな負担となることが想像できました。

OpenStackベースのクラウドサービスを提供されている事業者、独自拡張を加えたディストリビュータ、オンプレをOpenStackで管理されている方々、それぞれかなりのノウハウを蓄積しながら運用を行っているはずです。素のOpenStackで不足なく利用されているケースはおそらく少数派でしょう。

かつて開発と運用はそれぞれ役割分担してサービス開発、提供を行っていたものですが、いまや運用を知らずしてサービスを開発できる時代ではなくなりました。

可用性、スケーラビリティ、将来を見越したアップデート計画などを開発者自身が精通していないと、サービスリリースにこぎつけたとしても、その後の苦労は並々ならぬものが待っているはずです。

P2でとられている具体的な運用プロセスなど、その辺りのお話は次回のポストで触れたいと思います。

今後の連載予定

IIJ GIOアカデミー開催報告(2016年11~12月)

カテゴリー: GIOアカデミー
このエントリーをはてなブックマークに追加

こんにちは。IIJ GIOアカデミー事務局です。
2016年11月から12月に開催したプログラムを一気にレポートします。

11月24日 巨額制裁金を回避せよ!IIJ GIOによるEU個人データ保護法対策(IIJ Europe Limited 小川)

EUの新しい個人データ保護法(一般データ保護規則:GDPR)が2018年5月25日より施行されます。GDPRは、個人データの処理と個人データをEU域内から第三国に移転するために、満たすべき法的要件を規定しています。インターネットの爆発的な普及により国境を越えてプライバシーデータのやりとりが頻繁に起こるようになったため、従来のEU加盟各国で制定されている保護法より強力な枠組みが必要だと考えられた背景があります。
GDPRにより欧州でビジネスを行う日本企業にどんな影響があるのか、適用までの残り一年半の間に企業として何をするべきか・・・基本概要からITにおける対策のポイントをお話しました。

gioac_1201

まず頭に入れておきたい点として、GDPR違反の場合には、最大で企業の全世界年間売上の4%以下、または、2,000万ユーロというこれまでにない高額の制裁金が課せられる恐れがあるということです。
適用対象は、EU域内に拠点を有する企業だけではなく、EU域内の個人に対して商品やサービスを提供しているEU域外の企業も含まれます。欧州でビジネスを展開する企業にとっては、厳しい状況になることは間違いありません。

様々なIT対策がある中、一年半後までにすべて対応することは非常に大変です。「時間がない」「コストがかかる」「人が足りない」など問題を抱えた企業は多いのではないでしょうか。
そこで、重要なポイントとなるのが、現状を把握し、優先度を決めて計画を考えることです。必要最低限の対応で最大限の効果を得ることがカギとなります。

特に高い制裁金が課されることになる“第三国への個人データ移転”についての対策として、IIJグループではBCR(拘束的企業準則)の申請を行い、来年の秋には承認の取得を目指しています。BCRは、GDPRを含むEUのデータ保護法を遵守していることを確認するものになりますので、IIJグループのクラウドサービスを利用することで、お客様はより負担の少ない形で、EUの個人データの処理・移転を行うことが可能となります。是非対策の一つとして、「IIJ GIO」をお考えいただければと思います。

疑問・質問はお気軽にお問い合わせください。
<お問い合わせ先:global-marketing@iij.ad.jp>


12月8日 IIJ GIOサービスの裏側

2016年最後の講演は、普段お話することのないIIJ GIOの開発や運用といった裏側をサービスに関わるエンジニアからIIJ GIO統合運用管理サービスとIIJ GIOインフラストラクチャーP2を中心にご紹介しました。

煩雑化する大量の監視アラートを整理(IIJ サービス基盤本部 福原)

giologac_1202

まずはクラウドからオンプレミス環境まで、点在するシステムの監視・運用を包括的に管理するIIJ GIO統合運用管理サービスの運用の裏側をお話しました。

ユーザ企業がシステム運用をする上でよくある課題として、“ナレッジ不足”、“障害対応の基本フロー未整備”、“業務体制と役割のミスマッチ”などが挙げられます。

なぜこういった状況に陥るかを考える過程において、そもそもシステム運用の現場は“大量のアラートに忙殺されてしまう”という根本的な問題が浮上してきます。

そして、アラート発生状況を分析していくと、実際に対処が必要なアラートは3%程度であった実態も浮かび上がってきました。そこで、対処不要のアラート数を削減することで、システム運用の現場負担を大幅に抑制にできるだろうと考えました。

そこでIIJでは、大量の機械処理を入れてシステムを開発。それが「アラート中継システム」です。IIJが長年の大規模な商用サービスの基盤運用で培った独自のナレッジを、自社開発のシステムの中核に組み込むことで、アラート数の約90%を削減、オペレーション負荷を1/5まで軽減し、対応スピードが2倍に向上しました。

実はこのシステム、すでにIIJ GIO統合運用管理サービスの基本機能に含まれております。ご興味のある方がいましたらお問い合わせください。
<お問い合わせ先:gio-part-info@iij.ad.jp>

クラウドサービスの作り方(IIJ クラウド本部 田口)

次に【IIJ GIOの裏側を語る】でも登場した田口から、IIJ GIOインフラストラクチャーP2のパブリックリソースについて開発者の視点からクラウド運用の舞台裏をお話しました。

giologac_1203

IIJでは、お客様に高品質で安定したサービスを提供するため、OpenStackや CloudStackといったオープンソースのクラウド基盤は利用せず、独自開発することで開発・運用プロセスを一体化してシステムを設計しています。

例えばIIJ GIO P2では、脆弱性対応や機能リリース、お客様に見えにくい仕様のアップデートなど様々なメンテナンスをほぼ毎日実施していますが、お客様に一切影響を与えず無停止状態のように見せながら利用できるよう運用プロセスが設計されています。(当日は2016年4月~11月までにメンテナンスを行った日のカレンダーを公開しました)

またIIJ GIO P2は、IIJサービスの中でも群を抜いて大規模で複雑な構造をしており、サービスを維持するために運用を前提にした設計をしています。

  • 開発~デプロイまでの様々なフローを自動化
  • 開発側の都合でサービスをできる限り停止せずアップデートを行う工夫
  • IIJサービス全体の監視システムとIIJ GIO統合運用管理サービスを連携し、階層構造で監視

これら3つの観点から、サービス開発はシステムを実装するだけでなく、継続的に提供するための仕組みを作ることの重要性をお伝えしました。


次回のIIJ GIOアカデミーは2017年1月24日(火)に開催します。
8月に開催し大好評だったIIJ GIO P2のめっちゃ詳細シリーズの再講演が決定!VWシリーズの特長や仕様・制限など、”めっちゃ詳細”にご紹介します。
IIJ GIO P2にご興味がある方はもちろん、前回参加できなかった方もこの機会にぜひ、ご参加ください!

2016年もまもなく終了、寒さも厳しくなってきましたが体調管理にはくれぐれもお気をつけください。
少し早いですが、来年もIIJ GIOアカデミーをどうぞ、よろしくお願いします!

(IIJ GIOアカデミー事務局)

【IIJ GIOの裏側を語る#2】 ネットワークの仮想化がもたらすメリット

カテゴリー: 技術情報, 裏側を語る
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第2回です。

今回は「ネットワークの仮想化がもたらすメリット」について、IIJクラウド本部の田口がご説明します。

keisuk-t_01_150

執筆者の紹介

株式会社インターネットイニシアティブ
クラウド本部 クラウドサービス1部 部長
田口 景介

「第2回:ネットワークの仮想化がもたらすメリット」

前回はIIJ GIOインフラストラクチャーP2(以下「P2」)の全体像についてお話ししましたが、第2回から第4回にかけてはP2のパブリッククラウド要素を担うパブリックリソースのアーキテクチャについてお話ししたいと思います。

パブリックリソースとプライベートリソースは互いに補い合う、異なるアーキテクチャを採用しています。その特徴的なポイントにフォーカスしていきましょう。

今回取り上げるのはネットワークアーキテクチャについてです。クラウドのように大規模なマルチテナントシステムを支えるネットワークは、一般的な常識が通じない部分が少なくありません。

クラウドの設計とは、一般的な企業システムでは遭遇しえない様々な制約が立ちはだかる、“規模との戦い”なのです。VLAN ID数の上限であったり、スイッチにおけるMACアドレスの学習上限であったり、テナント同士の帯域のフロー制御であったり、その制約と課題は様々です。

P2パブリックリソースのネットワークを支えるSDN技術

P2パブリックリソースでは、全面的なSDN(Software Defined Network)の導入によって、こうした多くの困難な課題を克服しています。

もっとも、ネットワークがSDNにより仮想化されているかどうかをユーザーから認識することはありません。仮想マシン上のゲストOSからはeth0, eth1といったごく普通のNICが見えるだけです。エンドユーザーがハイパーバイザの先でテナントごとで固有のVLANに接続されていることも、さらにその先でVXLANによるオーバーレイネットワークが存在していることも知ることはできません。

それでは、ネットワークの仮想化がユーザーのメリットにつながっていないのかと言えば、そんなことはありません。P2の特徴的な仮想ネットワークがもたらすメリットは、ユーザーにも高性能、高可用性、高信頼性といった品質という形でお届けできているはずです。

ところで、一言でSDNを導入したネットワークといっても、確立した設計やプロトコルがあるわけではありませんから、実装によってその姿はさまざまです。

giolog_acr10

giolog_arc12

P2パブリックリソースのネットワークアーキテクチャは、いくつかの特徴的な構造を備えています。

  • 特徴1 物理L2面で構成されたゾーンをL3でスケールアウト可能なサイト設計
  • 特徴2 同一L2内では通常のVLANとして、ゾーンをまたぐトラフィックのみオーバーレイするハイブリッドな仮想化ネットワーク
  • 特徴3 高可用性と公平性を実現するHA構成の独立型VTEP
  • 特長4 複数サーバの可用性を保証するマルチグループネットワーク構成

ソフトウェアスイッチがもたらすメリット

なかでも最も特徴的なのは、VTEP(*1)がハードウェアスイッチでもなく、ハイパーバイザでもなく、独立したソフトウェアスイッチとして実装されていることです。このひと手間かけた構造が、多くのメリットをもたらしているのです。

(*1)Virtual Tunnel End Point:VXLANによるオーバーレイネットワークを終端する装置あるいはソフトウェア

まず、ハイパーバイザを通じて送出されたパケットは通常のVLANで構成されたネットワークに流され、宛先が同一ゾーン内にある場合はそれで完結します。

VTEPによってパケットがカプセル化されるのは、宛先が異なるゾーンに存在する場合だけでよいのです。小規模なシステムは全体が同一ゾーンに収まっている可能性が高いため、多くの場合ネットワークの仮想化によるオーバーヘッドを避けることができます。さらに、サイト全体での総VXLANトンネル数を減らすことになるので、VTEPの負荷軽減にもつながります。

こうして最小限のオーバーヘッドでネットワークの仮想化が実現しているのです。

シンプルな構造が品質向上につながる

このアーキテクチャは運用の容易さにも貢献してくれます。

もしVTEPが各ハイパーバイザに存在していて、すべてのトラフィックが仮想ネットワークを通るのならば、VXLANトンネルが数千台のハイパーバイザ間で無数に張られることになります。一方、P2の構造ではVTEP間だけでトンネルが張られるので、全体像を捉えるのは容易です。しかも、前述したように無用なトンネルはそもそも作られないので、サイト全体の規模がスケールしていっても、比例してトンネルの本数が増加するわけではありません。

システムの構造がシンプルであるということは安定的な運用につながり、またトラブルシューティングを容易にしてくれるため、結果的に品質の向上につながります。

ソフトウェアスイッチならではの柔軟な制御

さらには、ネットワークのフロー制御にも役立ちます。

例えば、一部のテナントで突発的にネットワーク帯域を必要としたとしましょう。P2全体としてはかなり余裕を持ったネットワーク設計がなされているので十分な帯域を割り当て可能だとしても、VTEPがボトルネックになれば他テナントへのネットワークリソースの割り当てに影響が出ることが考えられます。しかし、P2のアーキテクチャならばVTEPが独立型であることを活かして、必要に応じて柔軟にスケールアウトさせることが可能です。

また、必要ならば特定のテナントを専用のVTEPに隔離することで、公平にネットワークリソースを割り当てる制御が可能です。これは個々のテナントに快適なネットワークを提供するという面と、一部のテナントに過剰なネットワークリソースが消費され、他テナントへ影響が及ぶ事態を避けられるという面があり、双方でネットワーク品質の向上につながっています。

以上のように、P2の仮想ネットワークはVXLANという標準的な技術で実装されていながらも、独特のアーキテクチャを採用することで、クラウドという大規模なネットワークインフラを効果的に制御しているのです。


次回、第3回「自社開発に拘るクラウドオーケストレータ」では、引き続きP2パブリックリソースのクラウド制御の仕組みについて解説する予定です。

今後の連載予定