2022-07-20 Google Cloud Skills Boost の実施
先日、スライドの PDF が提供されているページを見つけ、ビデオを見なくてもいいことがわかった。引き続き、今日もスライドの PDF を読み進めていった。
今日は、 「1. Hybrid Connectivity」という箇所を読み進めた。
しかし、オンプレ環境との接続においては特に VPN 周りの前提知識が必要で、今までの内容に比べると少し難しかった。
Overview
Hybrid Connectivity (GCP 環境とオンプレ、もしくは他クラウド環境などを混在させた環境) を実現するためのサービスがいくつか用意されている。
- Direct Peering
- Carrier Peering
- Dedicated Interconnect
- Partner Interconnect
- Cloud VPN
- Network Connectivity Center
Cloud VPN
VPN によって、 GCP 環境と任意のネットワークを接続する。Cloud VPN を利用して GCP 側に VPNエンドポイントを用意し、オンプレ環境の VPNルータ機器、AWS の virtual private gateway などとの間に VPNトンネルを構成することで、VPNネットワークを構成する。
Classic と HA のふたつの構成があり、 HA は GCP 側の VPNエンドポイントが 2つになる (2つの IPアドレスを持つ)。 SLA はそれぞれ 99.9％、 99.99％となる。
HA 構成の Cloud VPN を 99.99％の SLA を保つ形で活用するためには、対向の VPN エンドポイントを二つ用意し、トンネルを 2つ構成する必要があることに注意する。
Cloud VPN は拠点間 VPN であり、GCP 側の VPNエンドポイントと対向の VPNエンドポイントで暗号化/復号化が行われる。
また、MTU は 1460Bytes が上限である。
そのためか、 Cloud VPN が提供できる回線帯域の大きさは 3Gbps くらいが限度となる。
Dedicated Interconnect
Google が用意しているコロケーション施設にオンプレミスの物理 VPN ルータを設置する。
Cloud VPN では不十分な膨大なデータのやり取りを行う場合は、こちらを利用することが推奨される。
追加の帯域幅を用意するなどよりも安価に済む場合がある。
Partner Interconnect
Google が用意しているコロケーション施設が、地理的にオンプレ環境の近くに存在しない場合に利用する。
Direct Peering
Google Workspace および、その他の Google のサービスのエンドポイントと、オンプレのネットワークを直接接続する。
Google がこのような用途のために用意している PoP (Edge Points of Presence) という接続点に、オンプレのネットワークを接続する。接続方法については現状わからない、後々調べてみる予定。
Google Workspace およびその他の Google のサービスを利用するにおいて、広い帯域幅での通信を行うことができる。
Carrier Peering
Partner Interconnect 同様、 Google が提供する PoP が近くにない場合に選択肢となる。
パートナ企業が提供するエンドポイント経由で Direct Peering のサービスを利用する。
2022-07-19 Google Cloud Skills Boost 実施
今までビデオを見ていたのだが、スライドの PDF で同様の内容を確認できることが分かった。
Course Resources | Google Cloud Skills Boost for Partners
こちらを確認して進めていくことにした。
今日は、 Cloud Load Balancer について。
Cloud Load Balancer
Cloud Load Balancer には Global のものと Regional のものがある。
Global
Regional
TCP/UDP は Andromeda、 Network は Maglev という何かを利用しているらしい。
Managed Instance Group
Instance をひとまとめにしたもの。 AWS EC2 の Auto Scaling Group のように水平スケーリングをしたり、グループ内のインスタンスが停止した場合にインスタンスを自動生成したりすることができる。
グループ内に作成するインスタンスはインスタンステンプレートによって定義し、指定する。
Auto Scaling
前述したとおり、 Managed Instance Group には自動スケーリングの機能がある。
負荷 (Load) に応じてスケーリングする。負荷 (Load) は CPU の Load のみならず、 Traffic 量他様々な負荷 (Load) を利用することができる。Auto Scaling Policy によって定める。
Architecture
トラフィックは、以下のように流れる。
- Internet
- Global Forwarding Rule
- Target HTTP Proxy
- URL Map
- Backend Service
Global Forwarding Rule
ここ少しあやふや。また明日調べなおす。
Cloud Load Balancer はクライアントの送信元 IP アドレスから判断して、地理的に近いリージョンのサービス (Backend Service?) からコンテンツを提供する。
このサービスを司るのが Global Forwarding Rule であると理解している。
一番近いリージョンで障害が発生していて利用できなかったり、キャパシティが一杯だった時には次に近いリージョンにルーティングを行う。
Session affinity
AWS の Sticky Session みたいなもの。
Capacity Setting
「Global Forwarding Rule」で「キャパシティが一杯」と判断する閾値を決定する。
ここの理解は少しあやふや。
QUIC
「Quick UDP Internet Connection」の略称。
UDP を利用して早い通信を行うことができるらしい。
TCP の代替となるよう Google が作成したもので、LB で利用できるプロトコルとして説明されていた。
Cloud Armor
DDoS に対する防御を行うサービス。
standard と、 managed plus という二つのプランがある。
Cloud Load Balancer と組み合わせて利用できる。
Hybrid Connectivity NEG backend
Load Balancing の Backend Service としてオンプレ環境も利用できるという話。
ただ直接 Backend Service としてオンプレ環境を指定できるわけではなく、 Hybrid Connectivity NEG backend というものをかます必要があるみたい。
ここもあやふや。またやろう。
Cloud CDN
3つのモードがある。
- USE_ORIGIN_HEADER
- CACHE_ALL_STATIC
- FORCE_CACHE_ALL
SSL Proxy Load Balancing
暗号化された、 HTTP でないトラフィック用
TCP Proxy Load Balancing
暗号化されていない、 HTTP でないトラフィック用
Network Load Balancer
Regional な Load Balancer のうちのひとつ。
TCP/SSL Proxy Load Balancer でサポートされていない、 UDP やその他特殊なポートの通信に利用できる。
Proxy Load Balancer ではないので、送信元や送信先のアドレスは書き変わらない。
2022-07-18 ドコモ光からコラボ光に事業者変更を行った
ドコモ光の契約更新月となった。回線の契約を見直していたところ、現在契約しているドコモ光 (プロバイダ：とくとくBB) よりもコラボ光 (とくとくBB) の方が月額として安く利用できることに気がついた。
ドコモ光から、とくとくBB光というコラボ光のサービスに契約を切り替えることにした。
コラボ光
コラボ光とは、「光コラボレーションモデル」のことで、とくとくBB などのプロバイダ事業者などがフレッツ光から回線を借りて、その上でインターネット接続サービスなどを提供するサービスの総称のようだ。
ドコモ光もとくとくBB光もコラボ光。
コラボ光からコラボ光への切り替えの場合の手続きは特殊だが簡単にできるようにできており、各事業者で解約手続きと新規契約手続きなどをすることなく、事業者変更承諾番号というものをフレッツ光から取得、新しく契約する事業者 (今回であればとくとくBB) にこの番号を伝えることで切り替えが完了するようになっている。
事業者変更承諾番号の取得
「ドコモ光」から他社光サービスへのきりかえ（事業者変更） | ドコモ光 | NTTドコモ のページにて、「WEB でお申し込み」をクリック。
遷移先で、事業者変更を申し込む。
2日後くらいに、事業者変更承諾番号を告げる電話がかかってきた。
GMOとくとくBB光への申し込み
GMOとくとくBB光【公式】｜シンプルに安い・速い光回線 のページから申し込みを行う。
一番上から手続き。手続きを終えると申込みが完了した。とくとくBB側の回線が開通して切り替わったタイミングで、自動的にドコモ光は解約となるらしい。
余談
前述のページで「工事不要でかんたん乗り換え！」と謳われているが、本当に不要なのだろうか。まだサービス開始していないのでよくわからない。
契約後、工事日の打ち合わせについて連絡が来てしまったのだけれど。
一回、電話でそのあたり問い合わせてみようか。後で。
2022-07-13 Google Cloud Skills Boost 実施
Cloud IAM の Custom Role
predefined role を選択して表示されるメニューから、「create role from this role」をクリックすることでサクッと作成できる。
Firewall rules
- デフォルトでは、ネットワーク全体に適用される。
- 特定のインスタンスにのみ適用する方法がある (Target の指定)
Target
以下の 3種類の指定方法がある。「ネットワーク内の全て」については物理の firewall においても馴染みのある設定だが、他の二つについては Google Cloud に特殊な設定だなと思った。
- ネットワーク内のすべて
- 特定の Target Tag が付与されたもの
- 特定の Service account が付与されたもの
Source
以下の 4種類の指定方法がある。「IP range」については馴染みのある設定だが、他の 3つについては Target で述べたのと同じく、物理の firewall では馴染みのない設定だなと思った。
- IP range
- Subnet (VPC Subnet)
- Source tag
- Service account
Firewall rules についての Lab
例によってこれも実施できなかった。 Review の動画を確認したのみとなる。
「Web-Server」のタグを付与した Blue サーバとタグなしの Green サーバの二つのサーバを作成する。
「Web-Server」タグをターゲットとして、送信元 IPアドレス全許可で、 80番ポートのインバウンドトラフィックを許可する firewall ルールを作成する。
最後に、external アドレスを指定して Compute Engine インスタンス、ブラウザなどから HTTP アクセスを行う。
Blue サーバに対しては HTTP でアクセスできるが、 Green サーバに対してはできないことを確認する。
また、作成した firewall ルールを削除し、 Blue サーバに対しても HTTP アクセスができなくなることを確認する。
Shared VPC
「XPN」と呼称されたりもする。
同じ組織において、異なるプロジェクトの間で通信を行いたい場合に必要となる。
Multiple Network interface で同様のことを実現することも可能だが、こちらの手法のほうがシンプルですっきりした構成を作れるのかなと思った。
同様のサービスに VPC Network Peering がある。
Shared VPC は同一組織においてのみ利用できる。
VPC Network Peering は、同一組織か否かに関わらず利用できる。
Shared VPC の設定方法
Cloud IAM を利用して、権限の委譲を行う。
まず「Organization Admin」の権限を持つアカウントが、「Shared VPC Admin」の権限をアカウントに割り当てる。
プロジェクトの作成や削除は、「Organization Admin」の責務である。
「Shared VPC Admin」権限を割り当てられたアカウントは、ホストプロジェクトで「Shared VPC」を有効化し、サービスプロジェクトとして構成する他のプロジェクトをポチポチと選択する。
加えて、「Service Project Admin」権限をアカウントに割り当てる。これによって、Shared VPC Network の一部または全部のアクセスの権限を委譲する。
「Service Project Admin」の権限を割り当てられたアカウントは、 Shared VPC で定義されたリソースを管理する。
ハンズオン
「Service Project Admin」権限を割り当てられたアカウントで Compute Engine インスタンスを作成する際、ネットワークのカラムで、「Network shared with me」という選択肢が選択できる。
これを選択することで、VM インスタンスを Shared VPC 上に作成できる。
ハンズオンでは、同じ Shared VPC に作成した異なるプロジェクトのインスタンス同士が内部IPアドレス経由で ping で疎通できることを確認した (異なるプロジェクトのインスタンスは、通常内部IPアドレス経由で ping 疎通を行うことはできない)
2022-07-12 Google Cloud Skills Boost 実施
Google Cloud Skills Boost 実施
Lab Review: Getting Started with VPC Networking | Google Cloud Skills Boost for Partners から開始して、 IAM roles | Google Cloud Skills Boost for Partners まで実施した。
VPC Networking 周りは馴染みがなくやや難しかったが、 IAM 周りは Cloud Developer で一通り理解していたため、復習のような気持ちでスラスラと学習を進めることができた。
Lab
Lab は何故かエラーが発生して実施できなかったので、「Lab Review」の動画を確認するだけとなった。残念。
Lab は、以下のような内容だった。
ざっくりいうと、 VPC ネットワークを自身で作成したり、設定変更したり、削除したりしてみようというところ
- デフォルトのネットワークを削除する
- インスタンスを作成しようとするが、割り当てられるサブネットがないために作成できないことを確認する
- Auto Mode で VPC ネットワークを作成する
- インスタンスが再度作成できるようになることを確認する
- 各種ファイアウォールルールを削除すると、それに応じて PING や SSH の通信ができなくなることを確認する
Multiple Network Interface
Cloud Compute Engine に複数のネットワークインターフェースを割り当て、複数のネットワークに所属させるという技術。物理ではよくある構成だよなと思った。
結構制限があった。インスタンスが所属する複数のネットワークにおいて、アドレス範囲の重複があってはならないというような当然だなと思うこともあれば、「なんで？」って思うような内容もあった。「なんで？」って思った制限事項について以下に記載する。
また、 Internal DNS は nic0 のアドレスで名前を解決するようになる。これはまあ納得。
Lab
Multiple Network Interface についても Lab があった。これも同様にエラーが出て実施できず、残念だった。
3つのネットワークに所属するインスタンスから、各ネットワークに所属するインスタンスへ PING を送り、疎通できることを確認した。
3つのネットワークに所属するために、 vCPU は 3以上ないといけないそうだ。なので、この Lab で利用されているインスタンスの vCPU は 4だった。
VPC ネットワークへのアクセスを制御する方法
方法は大きく分けて二つあるとのこと。
Cloud IAM
前述したとおり、また Cloud IAM の説明になった。
子は、親のレイヤで許可された権限を制限できない
一つ、ここでの基本的な説明で新しく学んだことはこれ。
Organization で許可された権限を、その下のフォルダやプロジェクトレイヤで無効にしたり、制限したりすることはできない。
ゆえになおさら、 Google Cloud では Principle of least privilege に従うことが推奨される。
Network 関連の Pre-define roles
Network Viewer
ネットワーク設定の inspection を行うアプリケーションなどに付与することが推奨される。
Network Admin
firewall や SSL Certification などのセキュリティ関連を除く Admin 権限が付与される。
Organization policy constraints
組織やフォルダ、プロジェクト単位で制約を設定することができる。
例えば、 Compute Engine で IPv6 を利用しないようにするなど。
Organization policy constraints | Resource Manager Documentation | Google Cloud
2022-07-11 期待したパスにリクエストが来ていることを確認する
やりたいこと
外形監視として、 HTTP リクエストを送るアプリケーションがある。
このリクエストで指定されたパスが、想定通りのものであるか確認をしたい。
例.) http://example.example/path/to/file?query=string&query2=string2 に HTTP リクエストした場合、 example.example 側で /path/to/file?query=string&query2=string2 というリクエストが受け付けられること。
方法
cat ./index.php <?php var_dump($_SERVER['REQUEST_URI']);
var_dump() は不要に思う。
標準出力されるログで、パスが確認できる。
php -S 0.0.0.0:80 -t . [Mon Jul 11 17:48:41 2022] PHP 7.4.3 Development Server (http://0.0.0.0:80) started [Mon Jul 11 17:46:21 2022] 192.168.13.123:50394 Accepted [Mon Jul 11 17:46:21 2022] 192.168.13.123:50394 [404]: GET /path/to/file?query=string&query2=string2 - No such file or directory [Mon Jul 11 17:46:21 2022] 192.168.13.123:50394 Closing
