はじめに

はじめまして。CyberAgent group Infrastructure Unit（CIU）に所属している木村洸太です。Cycloud の KaaS 基盤である AKE（Astro Container Engine）や LBaaS 基盤である CLB (Cycloud Load Balancing) の開発運用を担当しています。

今回は、Cycloud の新基盤の全貌に迫る連載シリーズの第6回として、新リージョンで開発した 内製 Network Load Balancer を中心にお届けします。

本記事では、CLB で API として統一採用している Gateway API の選定理由を紹介しながら、新リージョン LB 基盤として技術的挑戦である「LB 筐体の N+1 構成に伴うスケジューリング機構」に焦点を当てます。NW 編で紹介した LB 筐体の N+1 構成により、ユーザーの LB 設定を適した LB 筐体に同期するための機構が必要になりました。どのように実現したのか、その設計の裏側を深掘りします。

CLB (Cycloud Load Balancing) の概要

CLB は、Cycloud の LBaaS として開発しているマネージドロードバランサーサービスです。新リージョンでは、L7 (HTTP / HTTPS) をバランシングする Application Load Balancer と L4 (TCP / UDP) をバランシングする Network Load Balancer を提供しています。

Application Load Balancer  では IAP（Identity-Aware Proxy）の機構を実装しており、社内サービスをグローバル公開する際にアクセス制御機能により、安全にインターネット上に公開することができます。また ACME HTTP-01 を利用して TLS 証明書の発行管理を Application Load Balancer に委譲することができる機能も提供しています。

Gateway API 採用の背景

CLB では L4・L7 共通でサービス API として、Gateway API を採用しています。

Gateway API は、Kubernetes における L4 および L7 ルーティングに特化した公式Kubernetes プロジェクトで、Kubernetes Ingress プロジェクトであった課題を解決するため、当初より拡張性やロール志向に基づいたリソース設計になっている特徴があります。

GatewayAPI におけるロール志向デザイン (公式ドキュメントより引用)

GatewayClass はプラットフォーム提供者が管理するリソースで、ロードバランサーのタイプを表現するリソースです。Gateway はクラスタ管理者が管理するリソースで、ロードバランサーの入口となるエンドポイントを表現するリソースです。HTTPRoute はアプリケーション開発者が管理するリソースで、ロードバランサーのトラフィックをどのようにアプリケーションまでルーティングするのかを表現するリソースです。

CLB では、以下の3点の理由から Gateway API をサービス API として採用しました。

1点目は、L4・L7 ロードバランサーで共通した API をユーザーに提供できる点です。上述の通り、GatewayClass を用いることで CLB として提供するロードバランサーの種別を表現することができ、ユーザーは Gateway 設定の GatewayClass を変えるだけで他の設定を変えることなく異なるロードバランサーを払い出すことができます。

2点目は、CLB がサービスを構成するための技術として異なる技術を採用しても、ユーザー API に影響なく行える点です。Gateway API は L4 および L7 ルーティングの共通規約をベンダーニュートラルに策定することを意識されており、特定の技術に関わる API 仕様は入らないように気をつけています。そのため、ユーザーと CLB のインターフェースとなるサービス API で GatewayAPI のみに依存することで、ユーザー影響が最小限になるように設計しています。

3点目は、サイバーエージェントではコンテナ・Kubernetes の採用が盛んな点です。Cycloud では KaaS 基盤である AKE も提供しているため、Kubernetes との親和性が高い点や Kubernetes クラスタ上から容易に利用できる環境を整えることで、Cycloud プラットフォームとしての利便性を高め、ユーザーにより良いサービス体験を提供できるように心がけています。

Network Load Balancer

ここからは新リージョンで開発した Network Load Balancer にフォーカスして紹介していきます。

まずユーザーの利用イメージとして、上記で説明した GatewayAPI リソースを作成するリクエストを送ることで LB 設定を行います。その結果、レスポンスとして複数の IP を紐付けることのできるドメインが返ってきて、このドメインにユーザードメインを紐づけることで疎通が可能になります。

このように単一アドレスではなくドメインを返却することで、ユーザーが可用性を担保したい場合は複数 IP を紐づけるように指定ができたり、LB 筐体の障害時にはドメインから特定 IP を抜くことで安定した LB 基盤を提供することができます。

Gateway API には、このような設定を表現する field が存在しないため、CycloudGatewayPolicy というリソースを定義して対応しています。
このリソースは GatewayAPI の PolicyAttachment という概念に沿って定義しています。

https://gateway-api.sigs.k8s.io/geps/gep-713/ 

PolicyAttachment は、従来の Ingress における annotation に独自ベンダーの追加設定を指定することを改善するために、特定リソースに対して追加設定を付与したい場合に利用することが想定されています。
そのため、以下のように追加設定を表現する field と設定を適用する対象を指定する (.spec.targetRefs ) field を持つ構造になっています。

apiVersion: loadbalancing.cycloud.jp/v1
kind: CycloudGatewayPolicy
metadata:
  name: example
spec:
  default:
    network:
      replicas: 2
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: target-gw

apiVersion: trafficcontrol.network.loadbalancing.cycloud.jp/v1
kind: CycloudNetworkDataplaneTarget
metadata:
  name: target1
spec:
  targetLabel: dataplane1
status:
  targetRefs:
  - kind: CycloudNetworkDataplane
    name: lb00
  - kind: CycloudNetworkDataplane
    name: lb01

apiVersion: trafficcontrol.network.loadbalancing.cycloud.jp/v1
kind: CycloudNetworkDataplane
metadata:
  name: lb01
spec:
  endpoint: https://10.0.0.1

ここで意図的に CRD に LB 筐体の active や standby といった概念は取り入れずに実現する方式を採用しました。LB 筐体の状態管理を行う責務は NW チームが持つ形になっているため、もし CRD に状態を表す概念を入れてしまうと NW チームのメンバーが Kubernetes クラスタを頻繁に操作する必要が生じてしまいます。責任の境界を明確に分けて、LB 筐体の設定を変えるだけで NW チームが LB 筐体の状態を表現できるためにラベルという識別子を持たせています。

例えば dataplane1 という識別子が active 筐体の1台目を表し、dataplane2 という識別子が active 筐体の2台目を表す取り決めをしていた場合は、以下のように LB 筐体にラベルをふることで論理的に active・standby を表現できるようにしています。

LB01 : dataplane1
LB02 : dataplane2
LB03 : dataplane1,dataplane2 (LB01とLB02 の設定を保持する)

Gateway reconciler

ユーザーのリクエストの値を検証し、実際に LB 筐体に同期する処理の単位である GatewayInstance を管理する役割をもちます。GatewayInstance を作成する際に、指定の CycloudNetworkDataplaneTarget と紐づけています。

ユーザーがロードバランサーを冗長構成にしたい場合は、複数の GatewayInstance を作成し、それぞれが異なる CycloudNetworkDataplaneTarget と紐づくように管理することで冗長性を担保しています。

各 Gateway がどの Target を対象として紐づけることができるかを決めるために、事前に以下の Policy CRD を作成することで、Target の紐付け処理を実現しています。

apiVersion: trafficcontrol.network.loadbalancing.cycloud.jp/v1
kind: ClusterCycloudNetworkDataplaneTrafficPolicy
metadata:
  name: network-internal-default
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: GatewayClass
    name: network-internal
  trafficConfig:
    dataplaneTargetRefs:
    - kind: CycloudNetworkDataplaneTarget
      name: target01
    - kind: CycloudNetworkDataplaneTarget
      name: target02

GatewayInstance reconciler

GatewayInstance の設定をもとに実際に LB 筐体に設定を同期する役割をもちます。

以下のように CycloudNetworkDataplaneTarget への参照を保持していることで、CycloudNetworkDataplaneTarget の status から対象の Dataplane を特定し、特定の筐体に設定を同期しています。

apiVersion: network.loadbalancing.cycloud.jp/v1
kind: GatewayInstance
metadata:
  name: example
spec:
  ...
  dataplaneTargetRef:
    kind: CycloudNetworkDataplaneTarget
    name: dp00

おわりに

本稿では、設計の背景などを中心に内製で開発している LB 基盤に関して紹介してきました。

Kubernetes のエコシステムや CRD をフル活用することで、安定した LB 基盤を実現するとともにユーザーが利用しやすいサービスの実現を目指して奮闘しています。

今回は割愛した Application Load Balancer のデータプレーン選定の内容も過去の Developers Blog にありますので、興味がある方はぜひそちらの記事もご覧ください。

https://developers.cyberagent.co.jp/blog/archives/62184/ 

次回予告

次回は「 KaaS 編」と題して CIU の KaaS基盤である AKE（Astro Container Engine）に関して新リージョン対応についてお届けしていきますので、お楽しみに！

連載記事一覧

本シリーズでは、各チームが新基盤構築における技術的挑戦を公開しています。他のレイヤーの知見については、ぜひ連載の他の記事も併せてご覧ください。

Cycloud 新基盤の全貌 第一回 新リージョン基盤の全体像

Cycloud 新基盤の全貌 第二回 HW 編

Cycloud 新基盤の全貌 第三回 NW 編

Cycloud 新基盤の全貌 第四回 IaaS 編

Cycloud 新基盤の全貌 第五回 ComputeController 編

Cycloud 新基盤の全貌 第六回 LB 編

Cycloud 新基盤の全貌 第七回 KaaS 編

Cycloud 新基盤の全貌 第八回 FrontEnd 編

各レイヤの Cycloud の新基盤に関して、より詳細な仕様や設計思想を知りたい方は、上記各チームの Developers Blog 記事をぜひご一読ください。