GCP ハンズオン: NLB と HTTP ロードバランサ
何をやっても三日坊主が常ですが、ブログに記録を載せておけば改善されるかなと学習内容を記録していくことにします。
休職・転職活動中に見つけた qwiklabs という非常に有用なサイトで時折ハンズオンで勉強をしています。
qwiklabs.com
これは GCP / AWS のハンズオン学習サイトで、カリキュラム（qwiklabs 内ではラボと呼ばれています）ごとに都度新規の環境が用意され、その環境内でハンズオンを行います。 カリキュラム 1回ごとに料金がかかり、かつクラウド環境の利用に制限時間がありますが、都度新規の環境で作業できること、また個人でクラウド環境を用意した際に、使用しなくなったリソースを削除し忘れて余計な請求が発生してしまうということもないので、学習環境としては安心して使える優れものです。 カリキュラムの大半が英語ですが、日本語のものもあります。
最初から手順に沿ってハンズオンを進めてもよいですが、個人的には説明を読んだ後でカリキュラムをスタートすることをお勧めします。 作業手順に沿ってコマンドを実行するだけでは理解は進みませんし、前述の通りクラウド環境の利用に制限時間があります。 そのため手順や各ドキュメントにじっくり目を通して理解を深めてから手を動かすようにすると時間を有意義に利用できます。
さて本題。 本日は qwiklabs で次のハンズオンをやりました。
ネットワーク ロードバランサと HTTP ロードバランサを設定する
前職でも GCP の経験がなかったので、いちから基礎を勉強していてその基礎コース内の最後のラボになります。 当然 LB の操作自体は経験はありましたが、今回のハンズオンで GCP の L7 ロードバランサである HTTP ロードバランサはリバースプロキシ的な動作で実装されているというのは目から鱗というか、言われてみれば確かにそうだと再認識させられました。
直近の疑問としては、インフラエンジニアとして L7 をどこまで気にすることになるか、という点があります。 URL マップにより処理を振り分けられるというのは、例えば example.com/ja と example.com/en でそれぞれ別のインスタンスグループに処理を割り振れるということです。 HTTP ロードバランサを適切に設定するためには URL レベルでサイトの構成を把握している必要があります。 文字通り上位レイヤでの把握が必要になるので、おおよそ L4 までが守備範囲のインフラエンジニア単独では適切な設計は難しいかも、という気がしています。
