CCIE から Google Cloud Network Engineer へ : 知っておくべき 4 つのこと

※この投稿は米国時間 2019 年 2 月 13 日に Google Cloud blog に投稿されたものの抄訳です。

ハイテク産業の転職市場で必要とされる存在であり続けるには、新しいテクノロジーに乗り遅れないことと、そうしたテクノロジーに精通しているという証明を手にすることが大切です。Google Cloud には、新しい Professional Cloud Network Engineer（現時点ではベータ）をはじめ、プロフェッショナル向けのさまざまな認定資格が用意されています。マルチクラウドの世界では、このような認定資格が大きな財産になるはずです。

あなたが従来のオンプレミス IT 環境の出身者なら、Professional Cloud Network Engineer の取得に向けて勉強を始める前に、知っていると役に立つことがあります。私自身、従来の主流だった IT 運用の世界で 25 年を過ごし、その後クラウドに移ってきた人間です。元 CCIE（Cisco Certified Internetwork Expert）でありながら、私は過去と決別し、少し異なる角度から新しい技術を見て学ばなければなりませんでした。本稿では、皆さんが勉強を始める前に理解しておくと役に立つことを紹介します。クラウドとオンプレミスにおけるネットワーキングの違いを早く知れば知るほど、成功をつかむチャンスは広がります。

1. パケットではなくワークフローに着目する

ネットワーク エンジニアは通常、エンドポイント自体ではなく、エンドポイント間に位置するネットワーク機器に着目します。図 1 の Router-1 が示すように、トラフィックの大半はルータを通過します。トラフィックは、いわゆる goes-inta インターフェースから入り、goes-outta インターフェースから出ていきます。ルータ自体を終点とするトラフィックは比較的わずかです。それに対し、ほかのネットワーク機器を終点とするトラフィックには、コントロール プレーン通信、管理トラフィック、悪意のある攻撃などがあります。この「通過と終点」のトラフィック バランスはすべてのネットワーク機器（スイッチ、ルータ、ファイアウォール、ロード バランサ）で共通です。そのため、ネットワーク機器の構成、運用、障害対応では「goes-inta / goes-outta」の世界観でものを見ます。

ところが、クラウド エンジニアになると、アトミックな単位が変わります。パケットとヘッダではなく、ワークフローとそれに関連づけられたデータセットになるのです。図 2 は、典型的な 3 層のウェブ システムを使ってこの概念の違いを示したものです。従来の「ネットワーク」は抽象化、分散化されています。トラフィック パターンはひっくり返り、多くのトラフィックの起点 / 終点は、クラウド リソース間のネットワーク機器ではなく、クラウド リソース上のクラウド サービスやアプリケーションとなります。

このことは、http-inbound と呼ばれるファイアウォール ルールの設定方法を見ればわかります。このルールは VPC との関連で設定されるものの、ターゲットは gcloud コマンドの --target-tags、 もしくは --target-service-accounts=[IAM Service Account] パラメータで指定しなければなりません。しかも、トラフィックの入り口か出口かに応じて起点または終点のどちらか一方のフィルタを設定するだけで、両方を設定したりはしません。これは、情報の半分がターゲット自体だと見なされているからです。つまり、着目の対象は特定のクラウド サービスに出入りするデータなのです。

2. 構成要素が変わったことを認識する

旧来のネットワーキングには、スイッチ、ルータ、ファイアウォール、ロード バランサ、ケーブル、ラック、電源、BTU 計算といった具体的な構成要素がありました。また、IETF の RFC が定義する機能やメソッド、ベンダーのプロプライエタリなプロトコルとその手順、有限オートマトン、データ構造、タイマーというような無形の構成要素もあります。これらを組み合わせ、エンドユーザーと、ビジネスを動かすアプリケーションとの間で相互接続の環境を構築する、というのが従来のやり方でした。こうした仕組みの実装には数日から数週間かかり、しかもネットワークが拡大するにつれて、付随する管理作業や運用コストもビジネスの規模に合わないほど大きくなっていきました。

クラウド ソリューションは、この複雑さをソフトウェア問題として扱い、抽象化のためのレイヤをエンドユーザーとワークロードの間に追加し、旧来の構成要素に関連する複雑な部分を取り除いたり隠したりします。クラウドでの構成要素は、Google Compute Engine、Cloud SQL、Cloud Functions、Cloud Pub/Sub といったクラウド ベースのサービスや機能です。IaaS、PaaS、SaaS、FaaS ソリューションの提供というニーズに基づいて、これらの新しいリソースを組み合わせていきます。Cloud VPN や Cloud Interconnect で企業ネットワークをつなぎ、VPC、Cloud Load Balancing、Docker コンテナを Google Kubernetes Engine でデプロイするようになると、デプロイのスケジュールは、数日～数週間という単位から、数秒～数分という単位へと短縮されます。Cloud Deployment Manager、Stackdriver、Google Cloud 料金計算ツールなどを併用すれば、管理の複雑さも最小限に抑えられます。皆さんの仕事は、単にエンドポイント間の接続環境を構築することではなく、インフラストラクチャをコードとして扱い、仮想環境を実現することになるのです。

3. グローバル ファイバー ネットワークのパワーを理解する

このアプローチ（図 3）には、世界中のどこにいてもインターネット経由でアクセスできるという利点があります。しかし、次のような欠点もあります。

• 複雑な管理 : クラウドのフットプリントが広がり、さまざまなピアリング オプションを介して通信を行う「VPC の孤島」がリージョンを越えて必要になると、それに付随して構成、運用、障害対応も複雑化します。

• 予測不能なパフォーマンス : 公衆インターネットでは、ジッタ、遅延、パケット ロスなどを管理できません。

• 最適ではない経路 : トラフィックが通るインターネット上のホップ数は、ビジネスにとって最適なものとは限りません。ネットワーク機能の停止や通信事業者の BGP ポリシーの影響を受けます。

• 高まるセキュリティ リスク : インターネットの利用者には（皆さんのような）善良な人たちだけでなく、残念ながら悪い人たちもいます。転送中のトラフィックは暗号化できますが、公衆インターネットを介してリージョン間で通信するときは依然としてセキュリティリスクが伴います。

Google Cloud の Network Service Tiers プレミアム階層は、こうした欠点を一気に解消します。図 4 に示すように、公衆インターネットはグローバル VPC の外側にはじき出され、ネットワークの中核は Google 所有のプライベート ファイバー ネットワークになります。

これにより、さまざまな面で状況が改善されます。

• クラウドのフットプリントを、各地に分散された「VPC の孤島」という形で構成する必要がなくなります。大規模な同種のクラウド ネットワークがインフラストラクチャになります。最初は地域限定的なものであっても、準備さえ整えば、さほど苦労せずにグローバルなフットプリントに拡大できます。

• 公衆インターネットの場合に比べて、パケット ロス、遅延、ジッタなどの問題は大幅に緩和されます。

• エンドポイント間のホップ数は大幅に削減されます。Google ネットワークに入ったトラフィックは、通信事業者のネットワークではなく、Google が提供する最適な経路を通ります。

• グローバルなロード バランシングとエニーキャスト アドレスにより、トラフィックが Google ネットワークから外れてホップする場所はエンドユーザーから最も近い所になります。

• リージョン間のプライベート アクセス トラフィックは、アプリケーションからは透明な形で自動的に暗号化され、プライベート ファイバー バックボーン経由で送られます。インターネットを利用しないため、トラフィックが悪意のある人にさらされることはありません。

4. API、クライアント ライブラリ、SDK、コンソールの柔軟性を活用する

とはいえ、CLI にも限界はあります。新機能が欲しければソフトウェアのアップグレードが必要で、アップグレードするにはまずテストを行わなければなりません。しかし、それには時間とコストがかかります。CLI のコマンド構造や出力が変更されると、既存の自動処理やスクリプトは動かなくなります。また、数百、数千の機器を使っている大規模ネットワークでソフトウェアのバージョンに一貫性がないとしたら、その管理は悪夢のような状況に陥るでしょう。確かに SNMP がありますし、SNMP がダメなら XML スキーマと NETCONF/YANG モデルでシステムを正しい方向に発展させていくことは可能です。しかし、クラウドの世界にいったん足を踏み入れたら、そういったものは、プログラムによるアクセスから得られるものには到底追いつけません。

構成、運用、障害対応という観点から言えば、富士山頂へのルートと同じくらいたくさんの道筋がクラウドにはあり、図 5 はそのことを示しています。自分のスキル レベルに合うものや、仕事をやり遂げるのに適したものを自由に選んでください。Google Cloud では、シェル スクリプトやインタラクティブなセッションに使用できる CLI ベースの SDK が用意されていますが、必ずしもそれを使わなければならないわけではありません。アプリケーションを開発している場合や、プログラムによるアプローチが好みだという場合は、さまざまな機能を提供する多数のクライアント ライブラリから 1 つを選んで使うことをお勧めします。経験が豊富で特定のニーズに応えられるプログラマーの方であれば、REST API 自体に直接アクセスするのも手です。逆に、まだ学習の途上だとか、ビジュアルなアプローチのほうが好きだということなら、コンソールを使ってもかまいません。

上記ツールに加えて、大規模なトポロジーを定期的に作る必要がある場合は、Cloud Deployment Manager の利用を検討するとよいでしょう。クラウド プロバイダーの違いに関係なく機能する、ベンダーに縛られないツールが欲しいということなら、オープンソースの Terraform を調べてみてください。これらのソリューションは、いずれもインフラストラクチャ プログラミングを命令型から宣言型に転換するものです。リソースのプロビジョニングにおいて開発と運用のワークフローをもっと統一的なものにしなければならない場合は、これがうまく合うかもしれません。

まとめ

おそらく皆さんは、ネットワーク ベンダーのウェブサイトに用意されているドキュメント セクションのことをよくご存じでしょう。Google Cloud のネットワーキングについて理解するには、同じように Google のドキュメントを熟読するのが一番です。ネットワークの階層レベルやピアリング、ハイブリッド接続といった高水準の概念に関するドキュメントが用意されています。また、個々のクラウド サービスごとにドキュメント セットがあり、コンセプト、ハウツー、クォータ、料金などに細分化されています。それらのクラウド サービスがどのような作りになっているのかを復習し、ブックマークを付けていくと、学習と認定資格取得のプロセスが大幅に楽になります。何よりも、そうして勉強していけば、ずっと優れたクラウド エンジニアになれるでしょう。

最後に、皆さんにはあえて居心地の良い場所の外に出ていくことをお勧めしたいと思います。クラウド エンジニアへの転向は、仮想化、オートメーション、プログラミング、その他新しい分野の専門能力を身につけることを意味します。Google Cloud Platform が VPC をどのように実装しているかを学習するレベルで留まるわけにはいかないのです。短期の目標に加えて長期の目標を設定しましょう。あなたのスキル セットが必要とされ、あなたが価値を提供できる新しい領域はたくさんあります。あなたならできます。1 分たりとも、そのことを疑わないでください。

次回のブログ投稿では、クラウドの学習に対するアプローチについて取り上げる予定です。これを読めば、学習と認定資格の取得プロセスが簡単になり、Professional Cloud Network Engineer を取得するための準備がはかどるはずです。それまでは、Google Cloud に関するノウハウを広げるために、Google Cloud トレーニング チームが用意しているさまざまな手段を試してみてください。そして、今すぐ Google Cloud 認定資格のページにアクセスし、最初の目標を設定しましょう。幸運を祈ります。
- By Tom Taggart, Solution Architect, Google Cloud