クラウド同上

GCPネットワークの”見える化”を支えるNetwork Intelligence Center

Author
ShanX
Lv:2 Exp:442

SREです。旧車マニアです。軽油は苦くて美味しいです。

GCPで提供されるNetwork Intelligence Centerは、GCPで管理または接続されたネットワークを可視化し、トラフィックの分析や構成や問題を確認するサービスです。
本記事ではこのサービスの使い方や仕様、注意ポイントについて、実際に一般的な環境を構築し、解説していきます。

Network Intelligence Centerとは

Network Intelligence Center は”ネットワークの見える化”と”トラブルシューティングの迅速な対応”に重点を置いた、モニタリングサービスです。
このサービスが提供されたことにより、従来 Stackdriver Logging などでログを見るなどして使用帯域の分析や接続確認、ファイアウォールルールの動作確認などをしていた GCP ネットワーク管理者の負担は大きく減ることになりました。

GCPネットワークを可視化することでトラブルシューティングに役立てることが出来、全体のネットワーク管理をより簡単に行なえます。

本記事では以下のスコープに当てはまる読者を想定しています。
・ 最低限のネットワーキングの技術と知識がある
・ ネットワーク管理者である
・ ネットワークの接続確認やトラブルシューティングが不慣れである

Network Intelligence Centerを構成する代表機能

Network Intelligence Center を構成する代表機能として、下記の2つがあります。
1. ネットワークトポロジの可視化
2. 接続性のテスト
このセクションでは各機能に焦点を当て、どのような特性やメリットを持つのか、気をつけなければならない点などを解説していきます。

機能① : ネットワークトポロジの可視化

機能①:ネットワークトポロジは、GCPのインフラ基盤からリアルタイムの構成データをテレメトリにて収集し、”ネットワークの見える化”を実現します。ネットワークトポロジは、構成情報・メトリック・ログなどをキャプチャして、プロジェクト内またはプロジェクトを跨いだネットワークリソースの可視化をすることができます。

メリット
・ エージェントの追加が不要
・ 素早く簡単にネットワークトポロジを把握できる
・ ネットワークパフォーマンスの分析にも役立つ

特徴と注意点
・ 2日〜6週間キャプチャしたデータを保存可能(クォータ申請にて延長できる最大が6週間)
・ 保存したキャプチャは現在エクスポートなどができない
・ トラフィックを送受信しなければ表示されない

確認可能なリソース
・ VMインスタンス
・ HTTP(S)負荷分散
・ ネットワーク負荷分散
・ TCP/SSL プロキシ負荷分散
・ 内部負荷分散
・ Cloud NAT
・ VPC ピアリング(補足1)
・ 接続先パブリックインターネットの国(地域インターネットレジストリ)

追加で抑えておきたいポイント
・ データは1時間おきに収集され、表示される
・ 20分後にデータは固定のものとされる
・ オーバーレイの帯域幅は、最後に集計された最後の5分間を計算し平均値で出力される(補足2)
・ 帯域幅/トラフィック量を確認できる

補足
1. TCP通信の場合のみ表示され、かつ表示までに若干のタイムラグが発生します。
2. 例として、現在の時間がAM10:10 の場合、オーバーレイされる値はAM09:55からAM10:00 までの平均値が出力されます。

機能② : 接続性のテスト

機能②:接続性のテストでは、下記の3つをテストすることが可能です。[1]

構成変更や不適切な構成などをユーザが設定したことによるネットワーク接続断や、トラブルシューティングに役立ちます。
・ VPCネットワーク – GCP リソース 間
・ VPCネットワーク – パブリックインターネット 間
・ VPCネットワーク – オンプレミスネットワーク 間

[1] この機能を利用するには Network Management API を有効にしてください。

メリット
・ ネットワーク間の接続構成を簡単にテストできる
・ 主要なプロトコルを利用してテストができる
・ Interconnect などを利用した オンプレミス間でのテストもできる

特徴
・ GCP 外の IPアドレス も宛先/送信元に選択できる
・ 幅広いプロトコルをテストできる
・ 「どこから」「どこに」「どのような」通信ができるか否かを確認できる

確認可能なリソース
・ IP アドレスまたは VMインスタンス
・ TCP / UDP ICMP / ESP / AH / SCTP / IPIP
・ GCPプロジェクトまたはオンプレミスなど他のネットワーク
・ ポートは任意に指定可能

追加で抑えておきたいポイント
・ 複数プロジェクト間でもOK

料金について

このプロダクトの課金要素は”接続性テストの回数”です。

GA(一般提供)開始までのベータ期間は無料で使うことができますが、GA後は下記の価格で提供されます。

20テスト以下 / 月 Always Free(無料利用枠)
20テスト超過移行 / 月 $0.15/1テスト

ネットワークトポロジは無料で利用可能です。
例として、100テストを行った月の課金額を挙げてみます。
100テスト-20テスト(無料枠) = 80テスト
80テスト ✕ $0.15 = $12
100回のテストのうち、20回までは無料ですので、残りの80回分が請求対象となります。

画面の見方と使用方法

代表的な2つの機能と料金体系について触れてきました。
ここからは、実際に下記のリソースを作成し、画面を見ながら使用方法を解説します。
・ パブリックインターネットと接続されたVMインスタンス
・ Cloud NAT
・ VPCピアリング
・ HTTP(s)負荷分散
・ GKEクラスタ

ネットワークトポロジ

パブリックインターネットと接続されたVMインスタンス

エフェメラルな外部IPアドレスが付与されたVMインスタンスが、パブリックインターネットに接続している時のトラフィックをモニタリングしてみます。

チェックポイント

・ パブリックインターネットに送受信しているデータ量と帯域幅インスタンスがどこにアクセスしているのか、されているのか、使用した帯域幅はどれだけか、ということがすぐ視認できます。

Cloud NAT

外部IPアドレスが付与されていないVMインスタンスが、Cloud NAT ゲートウェイを経由することで、パブリックインターネットに接続している時のトラフィックをモニタリングしてみます。

チェックポイント

・ Cloud NAT ゲートウェイを経由してパブリックインターネットに接続されているかを確認します。

VPCピアリング

2つのVPCをVPCピアリングで接続した時のVMインスタンス間のトラフィックをモニタリングしてみます。

チェックポイント

・ ピアになったVPCネットワーク同士が内部的な通信を行なっていることが視認できます。

HTTP(s)負荷分散

HTTP(s)負荷分散がどのようにバックエンドサービスへトラフィックを分散させているのかをモニタリングしてみます。

チェックポイント

・ 特定のインスタンスにだけトラフィックが偏ることなく、トラフィックが均等になるよう分散されインスタンスに着信していることが視認できます。

GKEクラスタ

HTTP(s)負荷分散同様、Pod/Nodeのトラフィックをモニタリングし負荷分散がどのように行われているかを確認します。

チェックポイント

・ Pod/Nodeに対し、HTTP(s)負荷分散同様トラフィックが均等に分散されていることが確認できます。

接続性テスト

上記ネットワークトポロジにて作成したリソースに対して正常に接続できているのかチェックをしてみます。
パブリックインターネットと接続されたVMインスタンスでクラウドエース株式会社からのPINGテストを行なってみます。

作成画面

まず、「接続テストを作成」ボタンをクリックし、”接続テストの作成”へアクセスします。

テストを作成していきます。

・ テスト名(任意のわかりやすい名前にしましょう)
・ テストしたいプロトコル
・ 送信元IPアドレス または 送信元インスタンス
・ IPアドレスの場合、GCPプロジェクトで管理されているか否か
・ GCPプロジェクトで管理されている場合はプロジェクト名を指定
・ 宛先IPアドレス または 宛先インスタンス
・ IPアドレスの場合、GCPプロジェクトで管理されているか否か
・ GCPプロジェクトで管理されている場合はプロジェクト名を指定
・ 宛先ポート(TCP または UDPを指定した場合のみ)

上記をそれぞれ入力し、テスト内容を確認して問題がなければ作成ボタンを押します。
本件ではPINGテストでICMPが通るか確認するため、以下のような構成とします。
テスト名:icmp-test
プロトコル:icmp
ソース:IPアドレス、クラウドエース株式会社のIPアドレス
宛先:VMインスタンス、VMインスタンス名

成功例

アクセスが成功したことが確認できました。

失敗例

また、ICMPをブロックするような誤ったファイアウォールルールなどを作成し、わざと失敗して画面上での表示も確認してみます。
アクセスが失敗したことが確認できました。

この場合、Stackdriver Logging にてインスタンスのログを確認し、ファイアウォールログを確認し、そしてVPCフローログを確認するといった流れでトラブルシューティングを進めることができます。

考察

本機能は Google Cloud Next ’19 in Tokyo にて ラクシュミーシャルマ氏によるブレイクアウト セッション「D1-7-S06: 徹底解説: Google Cloud が提供する高速ネットワーク」にて、alpha機能として公開されたものでした。
以前より研究情報などを追っていた非常に興味深いプロダクトで、ネットワーク管理者だけでなく、ネットワークに起因する多くの問題を抱えているユーザにとっては革新的なプロダクトになると考えていました。
GAとなった際に、個人的には「ついに来たか!」と思ってしまったほど、トラブルシューティングやトラフィック分析に役立つ魅力的なモジュールがあります。
今後、GCPネットワークの情報収集を行ううえで、大いに役立つのではないでしょうか。

まとめ

本記事では Network Intelligence Center の使い方から見方、仕様上の注意点などをまとめてみました。
実際のトラブルシューティングは、このサービスだけでなく、複数のサービスを使い調査することになります。
その際の解決の糸口になったり、日々のネットワークリソースのモニタリングに少しでも役立てば光栄です。
今後、名前の通りよりインテリジェンスなサービスとして、ネットワーク担当者の負担軽減につながるプロダクトへと成長していくことを期待しています。