企業のビジネス部門のマネジャーは、SaaS（Software as a Service）プロバイダーからサービスを直接購入することが多い。だが、こうしたSaaSサービスのネットワークでのパフォーマンスが不十分な場合、責められるのはネットワークエンジニアだ。あるネットワークエンジニアの技術的要望リストでは、SaaSプロバイダーのIPアドレススキームの可視性向上が、真っ先に挙がっているようだ。

　「ほとんどのSaaSプロバイダーは、URLやDNS名で物事を処理しようとする。だが、ルータやファイアウォールはそうしたやり方で動いているわけではない」と、人材派遣・紹介会社の米Randstad USでネットワークマネジャーを務めるフォレスト・シュロス氏は語る。「SaaSプロバイダーに送られるトラフィックの優先順位付け、シェーピング、セキュリティ確保を行うには、プロバイダーから、どのIPアドレスが重要で、どのIPアドレスが重要でないかを教えてもらう必要がある。例えば、Googleにトラフィックを送信する場合、どのIP空間に入るか分からない。送信はDNS名宛てに行われるからだ。トラフィックにはYouTube、電子メール、Dropbox、暗号化された動画、Google通話など、多種多様なものがある。Googleは、ユーザーからのトラフィックがどこに送られるかについては、『Googleに送られ、Googleが処理する』ということしか教えてくれない」

待望されるポート単価の値下がり

　われわれは、需要と供給の法則がいずれは働くことを知っているが、ネットワークエンジニアはより安価な広帯域ポートを必要としている。それは彼らにとって今すぐ欲しいものだ。

　「バックボーンを100ギガビットイーサネット（GbE）にアップグレードすることを検討しているが、価格はいまだに桁外れだ」と、米サウスフロリダ大学のシニアネットワークエンジニア、ジョー・ロジャーズ氏は語る。「この問題は時間しか解決してくれないと思うが、オプティクスの単価は定価でまだ5万ドルもする。とんでもない値段だ。他の人たちも買い始めて、価格低下に貢献してくれればと願っている」

　10GbEのポート単価ですら、多くの企業にとって依然として高すぎる水準だ。「われわれはVMwareを使って、全てのサーバで10GbE NICに移行しようとしている。データセンターで消費しているポートが多すぎるからだ」と、医療機器メーカーの米DJO Globalのエンタープライズインフラ担当副社長、ジョン・イラシ氏は語る。「これからはサーバ1台につき2つか3つの10GbEポートが集約されていく計算になるため、合理的な運用が始められる」

無駄に面倒なネットワークソフトウェア、改善のポイントは？

　ネットワークベンダーは、ブラックボックスを提供していると思われている。ずっと一貫してハードウェアのスペシャリストとしてビジネスを行ってきたからだ。しかし、米Cisco Systems、米Juniper Networks、米Arista Networksのような企業は、多くの新興SDN（Software Defined Networking）ベンダーとともに、自らについて、「ソフトウェア会社でもあり、その企業カテゴリーから連想される、アジリティやサービスの機動性も兼ね備えている」とアピールしている。だが残念ながら、ネットワークベンダーがこれまで行ってきたコードの管理やコントロールのやり方は、顧客に厄介な重荷を背負わせてきた。

　例えば、ソフトウェアのバグは依然として広く見られる問題だ。「JuniperやCisco、Brocadeのファイアウォールからスイッチ、ワイヤレスに至るまでの製品について、われわれは常にコードの高い安定性を求める」とロジャーズ氏。「それはコードの機動的な提供に関わる問題だ。われわれはこれらの製品の機能追加を要望するが、その一方で、コードが安定していることも求める。だが、機能追加とコード変更を頻繁に続けていれば、コードの安定性を保つのは難しくなる。それでも、もっと良いコードの管理方法やリリース前のコード検証方法があるはずだ」

　ソフトウェアのアップデートもエンジニアにとって複雑過ぎると、イラシ氏は語る。

　「われわれはさまざまな機器のコードのアップデートに多くの時間を費やしている。システムのアップデートがもっと自動的に行われるようになり、もっと間違いなく確実にできるようになってほしい」とイラシ氏。同氏のチームは、ルータ群やファイアウォール群のコードレベルをそれぞれ統一しておくために苦労している。機器の多くが遠隔地にあり、エンジニアがじかに触ることができないからだ。

　「どのベンダーも、ネットワークソフトウェアをアップデートするためのシステムとしては、ちっぽけなものしか用意していないようだ」と、イラシ氏のチームのネットワークエンジニアであるマーク・ケリー氏は指摘する。「もっとグローバルな仕組みが欲しい。結局のところ、われわれはTFTP（Trivial File Transfer Protocol）を使って作業をしているのが現状だからだ。通常、アップグレードを行うときには、システム、ルータ、ファイアウォール、WAN高速化アプライアンスを全て同時にいじる羽目になる。ある管理システムから別の管理システムに切り替えたり、手動で組み込みを行い、TFTP作業をするといった具合だ。管理の観点から見て、これは悲惨なやり方だ」

　ネットワークベンダーは、オープンソースソフトウェアにもう少し依存し、スクラッチ開発のOSへの依存をもう少し減らせば、こうした複雑さを大きく軽減できる可能性があると、ある産業機器メーカーのネットワークエンジニアで、ITディレクターを務めるテレン・ブライソン氏は見る。どのベンダーも独自の管理システムを持っているだけでなく、当然のことながら、どのベンダーのソフトウェアにも固有のバグがある。また、ベンダーはエンジニアに、自社技術に関する専門的なスキルセットを要求する。

　「ネットワークエンジニアを雇わなければならない場合、彼らはCisco製品やCisco IOS（Cisco Internetwork Operating System）に非常に詳しい可能性が高い」とブライソン氏。「彼らはCiscoの機器を操り、さまざまな仕事をこなせる。一方、Juniperのような企業も優れた製品を作り、良い価格で販売しているが、彼らは、既存のインタフェースをコピーしなかった。このため、Juniper製品を使って何かをしようと思ったら、Juniper製品を熟知した人を雇わなければならない。さもないと、Cisco製品に精通した人を再教育しなければならなくなる」

　ブライソン氏は、ネットワークベンダーが自らのコアOSへの注力を弱め、自らに可能なコアOS関連の付加価値の提供にもっと注力することを望んでいる。コマンドラインインタフェースが企業間競争の勝敗を分けるわけではないとしている。「私がCiscoからArista、Juniper、Hewlett Packard、Brocadeへと乗り換えても、共通のインタフェースが使えてしかるべきだ。価値の差を生む源泉はインタフェースではない。他の機能、スピード、フィードだ。それこそが、製品を選んで買う決め手だ。エンジニアが入力する特定のコマンドは決め手にならない」

　「オープンソースの利用は、こうした価値の差別化を行う1つの方法だ。オープンソースを利用すれば、CiscoはOSを開発せず、Juniperなど他社と共用することになり、付加価値分野に余力を振り向けることができるからだ。このような観点に立って、どのベンダーも舞台裏でLinuxを多種多様な用途に使っていくことが考えられる」とブライソン氏。「Linuxは、開発の基盤となる優れたプラットフォームだ。こうした展開は絵に描いたモチだが、私としては、この種の動きが出てくることを期待している」

Ciscoのファイアウォールは巻き返しが必要

　完全無欠のベンダーは存在しない。エンジニアはどのベンダーにも苦情がある。だが、Ciscoのファイアウォール事業は出直しが必要なことは明らかだ。

　「Ciscoに対する私の最大の苦情は、彼らは次世代ファイアウォールを生み出す必要があるというものだ」（前出Randstad USのシュロス氏）

　シュロス氏は、Ciscoが次世代ファイアウォールとして売り込んでいる「Adaptive Security Appliance（ASA）5500-X」シリーズは、Palo Alto NetworksやCheck Point Software Technologiesの製品に太刀打ちできないと指摘する。CiscoはASAプラットフォームに機能を詰め込みすぎ、非常に複雑なものにしてしまっているという。

　ブライソン氏も、ASAは、そうした他のファイアウォールに見られる堅牢性に欠けると付け加える。例えば、Palo Alto製品はユーザーアイデンティティーが緊密に統合されている。このため、エンジニアがポリシーを強制しやすい。「Cisco ASAはまだ柔軟性が足りない。管理者が設定した厳しいルールをそのまま適用することが多い。社員の異動があったら、手動のコーディングやルール変更を大量に行わなければならない」

　シュロス氏は、ASAは、基本的なルーティング機能が欠けているという点で、Juniperなどの競合製品に及ばないとも指摘する。「ASAをデフォルトルートに設定すると、理にかなった方法でそこから送信を行うことができない。全てのトラフィックをルータに送信し、そのルータからファイアウォールに送信する必要がある。これに対し、他のファイアウォール製品では基本的なルーティングが可能だ」

ベンダーはIPv6の機能パリティに本腰を

　IPv6は、世界で主流のIPプロトコルにはまだ程遠い。だが、時間は刻々と過ぎている。アーリーアダプターは、ネットワークベンダーがIPv6についてユニバーサルサポートを提供し、IPv4との機能パリティを実現することを必要としている。

　「われわれはIPv6のアーリーアダプターだ」と、サウスフロリダ大学のロジャーズ氏は語る。「新たに展開するスイッチは全て、IPv6管理ができるようにしている。クライアントネットワークではIPv6を有効にしている。しかし、一部のツールがまだない」

　例えば、IPv6 NLB（Network Load Balancing）マルチキャストは、多くのネットワークプラットフォームで動かないと、ロジャーズ氏は説明する。また、Ciscoの無線LAN製品のIPv6対応は、まだ道半ばだ。アクセスポイント（AP）はIPv6クライアントをサポートするが、APとコントローラーの通信は、いまだにIPv4のみとなっている。

　「われわれは管理にかかわる技術については、IPv6対応をできるだけ全面的に推進している」とロジャーズ氏。「最近のスイッチは、機能パリティをまずまず実現しているが、一部の無線技術は対応が遅れている。VPN技術の問題もある。JuniperのVPN製品は、IPv6サポートが開始され始めたばかりだ。われわれとしては、ベンダーには、『とにかくしっかり対応していってほしい』と言いたい。IPv6はしばらく前から使えるようになっているのだから。ユニバーサルサポートが進むことを期待したい」