Google Cloud Platform、コンテナネイティブなロードバランスを可能に。従来のVM単位を改善

2018年10月16日

Googleは、Google Cloud Platformにおいてコンテナネイティブなロードバランスを可能にしたと発表しました

これまで行われていた仮想マシン単位でのロードバランスと比較して、コンテナ単位でより効率の良い分散処理が可能になります。

fig 図上が従来のロードバランサーで、仮想マシン内のiptablesが使われていた。図下は新しいコンテナネイティブなロードバランサーで、ロードバランサーが直接コンテナを認識しトラフィックを分散する

コンテナネイティブなロードバンランスは、Google Cloud Platformで稼働しているKubernetesのIngressコントローラに新しくNetwork Endpoint Groups(NEG)と呼ばれるレイヤが組み込まれたことで実現されました。

NEGはHTTPやTCP、SSLのプロキシとしてバックエンドのIPアドレスとポートを指定できるため、仮想マシン内のコンテナ単位でトラフィックを分散できると説明されています。

コンテナネイティブなロードバランスによってロードバランサーがコンテナのヘルスチェック情報を把握できるようになりました。

そのおかげで、これまではロードバランサーがコンテナの状態を把握せずに仮想マシン内のコンテナへランダムにトラフィックを転送していた仕組みから、エンドポイントグループに属するコンテナのなかで正常に動作しているコンテナに対して、あらかじめ決められたアルゴリズムによってトラフィックを転送する仕組みとなりました。

またトラフィックのホップもノードの中継を介さずに直接ロードバランサーからコンテナへと送られるようになり、効率的になっているとともに、問題が発生したときのトラブルシュートも容易になるとされています。

関連記事

2019年10月に正式機能となることが発表されました。

Tags: Google Cloud Kubernetes クラウド

このエントリーをはてなブックマークに追加
ツイート
follow us in feedly





タグクラウド

クラウド / AWS / Azure / Google Cloud
コンテナ / Docker / Kubernetes
クラウドネイティブ / サーバレス
クラウド障害 / 運用・監視

プログラミング言語 / 開発ツール
JavaScript / Java / .NET / WebAssembly
HTML/CSS / Web標準

アジャイル開発 / スクラム / DevOps / CI/CD
ソフトウェアテスト・品質
ローコード/ノーコード開発

データベース / RDB / NoSQL / 機械学習・AI
Oracle Database / MySQL / PostgreSQL
Office / 業務アプリケーション

ネットワーク / HTTP / QUIC / セキュリティ
OS / Windows / Linux / VMware
ハードウェア / サーバ / ストレージ

業界動向 / 働き方 / 給与・年収
編集後記 / 殿堂入り / おもしろ

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本