grasys blog

​マルチクラスタ化実現に向けたIngress for Anthos 本番導入にあたっての検証

文●grasys 編集● ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

※この記事は2020年10月8日に配信されたGoogle Cloud Anthos Dayのセッション内容をもとに作成しています。

 ​grasysは実プロジェクトにおいて、マルチクラスタ化を実現するためにIngress for Anthosの本番導入を検討しています。今回は本番導入を考慮し、実際にどのような検証を行なったのかを解説します。

既存のシステム構成と課題

 今回ご紹介するプロジェクトはGKEのシングルクラスタ構成(リージョンクラスタ)で、日本だけでなくアメリカやヨーロッパなど世界中からアクセスされるシステムです。そして、他のプロジェクトのサービスとAPIで外部連携しています。

 GKEクラスタは、Google Cloudのアイオワリージョンに配置し、クラスタごとに共通のAPIを持った専用のサービスを用意しています。

 ​また、それとは別に自身のプロジェクト用のサービスを持った構成です。

 ​他サービスからの接続はIngressのL7負荷分散で、パスパターンによってサービスを選択しています。リージョンクラスタ構成なのでひとつのゾーンで障害が発生した場合は影響がありませんが、リージョン全体で障害が発生した場合は全てのAPIサービスが停止し、本サービスを利用しているユーザーだけでなく他サービスを利用しているユーザーも共通APIが利用できなくなり、かなり広範囲に影響を与えてしまう恐れがあります

Ingress for Anthosによる課題解決

 この課題を解決するために、Ingress for Anthosを導入し、マルチクラスタ構成による冗長化を検討しました。

 Anthosは、クラウド環境とオンプレミス環境で一貫性のある開発と運用ができるアプリケーション管理プラットフォームです。Anthos GKE On-Premを用いたオンプレミス 環境のクラウドネイティブ化や、Anthos GKE on AWSを用いたマルチクラウド化のために使用するイメージが強いですが、それ以外にも様々な機能があります。そのひとつがIngress for Anthosです。

 Ingress for Anthosは、ひとことで言うとAnthosのマルチクラスタのロードバランシングサービスです。Google Cloudの同一プロジェクト内にある複数のGKEクラスタをマルチクラスタ構成にすることができ、これによりマルチリージョン対応や、通常のロードバランサーと同様に物理的にユーザーに一番近いクラスタへのルーティング等を行なうことができます。また、クラスタの移行や、セキュリティと組織を分離して開発を行なうときにも使用できます。

 今回は、クラスタとリージョンの可用性と、ユーザーから物理的に近いクラスタへのルーティングができるという観点からIngress for Anthosの導入を考えました。

Ingress for Anthosを導入する場合の全体構成

 もともとはアイオワリージョンのみにクラスタを配置している状態でしたが、これに加えて、新たに東京リージョンに同じアプリケーション構成のクラスタを作成します。サービスAを利用するユーザーは共通APIとしてクラスタ内のサービスへアクセスしますが、マルチクラスタIngressにより、日本からの接続は東京リージョンのクラスタへ、アメリカやヨーロッパからの接続はアイオワリージョンのクラスタへ振り分けられるようになります。

 Ingress for Anthos を使用している場合、アイオワリージョン全体での障害が発生し、サービスが止まると、ロードバランサーのヘルスチェックが失敗することにより、障害が発生していない日本リージョンへトラフィックが送られます。これにより、他サービスや自身のサービスのユーザーに影響を与えることなく、接続を継続できます。アイオワリージョンの障害が復旧し、ヘルスチェックが成功することで、再びアメリカやヨーロッパのユーザーからの接続は、アイオワリージョンのクラスタへ届けられるようになります。

​本番導入に向けた検証:必要な作業手順

 Ingress for Anthosでマルチクラスタ構成をとるワークロードとして、最低限で下記の作業が必要です。

1. 新たなクラスタ作成

2. クラスタのメンバー登録
- GKE Hubへの登録
- 構成クラスタの設定

3. MultiClusterServiceリソースの反映
- 構成クラスタのみにデプロイ
- メンバーの各クラスタにサービスが作成される

4. MultiClusterIngressリソースの反映
- 構成クラスタのみにデプロイ

 手順2で登場するGKE Hubとは、Anthosのクラスタ管理サービスです。この登録を行なうことでクラスタがAnthos GKEとして登録され、さまざまななAnthosのサービスが利用できるようになります。また、構成クラスタはマルチクラスタ用のリソースを管理するものです。プロジェクト内でひとつだけ設定が可能で、このクラスタからのみマルチクラスタ用のリソースをデプロイすることができます。デフォルトでは、最初にGKE Hubに登録したクラスタが構成クラスタとなり、これは後から変更が可能です。手順3と4のリソースの反映については、構成クラスタのみにデプロイすることで、メンバーの各クラスタにService/Ingressが作成されます。それぞれ通常のService/Ingressとほぼ同じ書き方で定義できます。

既存システムが使用できるかの確認・検証

 最低限の作業手順を説明しましたが、実際の環境では様々な設定があり、FrontendConfigやBackendConfig、監視ツールの設定などを見直す必要があります。多くのGKE Ingressで対応しているものはAnthos Ingressでも使用できますが、一部使用できない機能もあります。そこで、これらを確認・検証しました。

 まず、GKE Ingressには対応しているが、Anthos Ingressに非対応な機能を確認しました。GoogleマネージドSSLはAnthos Ingressに非対応ですが、GoogleセルフマネージドSSLは対応しているので、そちらへ移行する必要があります。また、SSLポリシーもAnthos Ingressには対応していません。ただし、今回のシステムではこれらを使用していないため、検証はしていません。

 既存システムではGKEバージョンが1.14と古かったため、Readiness Probeからのヘルスチェックのみを実施していましたが、BackendConfigの使用により、ヘルスチェック設定の上書きも行なえるようになりました。Cloud Armorについては既存のものをそのまま取り込むことができました。

 問題となったのは、現時点でIngress for Anthosに非対応のHTTPアクセスロギングです。本システムではCloud Logging/Cloud Monitoringでの監視を行なっています。アクセスパスによって、HTTPのレスポンスステータス等のチェックを行なっているため、HTTPアクセスロギングが使えないと困ってしまいます。2020年9月にRapidチャンネルでリリースされ、確認した限りだと構成クラスタのみのアップデートがあり、メトリクスの取得ができるようになっていました。このため、本番導入は早くてもレギュラーチャンネルでリリースされてからを想定しています。

 ​監視ツールは現在PrometheusとGrafanaを使用しています。マルチクラスタ構成になったので、federation機能を利用して一つのPrometheusへメトリクスを集める形にしています。

既存システムへの影響

 運用中のクラスタをマルチクラスタ化したい場合、既存システムに影響が出てしまうのではないかという懸念があるかと思いますが、MultiClusterIngressとMultiClusterServiceで新たにIngressとServiceを作成するので、既存システムに影響することなく、運用を継続したままマルチクラスタ化することができます。実際に切り替えるときは、既存の静的IP AddressとMultiClusterIngressで設定を行なった静的IP AddressをDNSで切り替える予定です。

 また、GKEバージョンが違うクラスタをマルチクラスタにできるのかも気になる点かと思います。既存のGKEバージョンが古くて選択できなかったり、リージョンによって選択できるGKEバージョンが違ったりと統一できないケースもあるかと思います。しかし、そのような場合も問題なく動作しました。なるべく自動アップデートなどを設定し、常に最新のバージョンを選ぶのが望ましく、手動対応をする場合も構成クラスタは最新版にするのが良いと思います。また、MultiClusterServiceは全てのメンバーのクラスタにサービスを作成するので、マニフェストは古いバージョンに合わせて記述するのが良いと思います。バージョンによって記述方法が違う場合は、よく確認する必要があります。

クラスタ単位でのリリース/GKEのアップグレードが可能に

 アプリはクラスタごとにデプロイされるため、クラスタ単位でのカナリアリリースができるようになります。そのため、先にアイオワリージョンでリリースし、そのあとタイミングをずらして東京リージョンでリリースするというような使い方ができます。また、GKEバージョンのローリングアップグレードができるようになります。今回のシステムはマルチリージョン構成なのでゾーンごとにアップグレードを行なえば問題ないですが、もしシングルリージョン構成の場合はダウンタイムが発生してしまうため、そういった問題を解決することができます。

バックエンドの接近性に課題

 Ingress for Anthosを使用すれば、マルチクラスタ構成を短時間で容易に構成することができます。今回ご紹介していない他のBackendConfigの設定なども、ほぼそのままIngress for Anthhosで移行することができます。ただし、構成にもよりますが、監視設定の変更やデプロイの運用方法の変更などIngress for Anthhos以外の対応に時間がかかってしまう場合もあるので、注意が必要です。

 また、Ingress for Anthhosによってフロントエンドの冗長化対応や接近性を上げることはできましたが、データベースなどのバックエンドについては課題が残ります。バックエンドは、Cloud Spannerのマルチリージョン構成やCloud SQLのクロスリージョンレプリカで対応することになると思いますが、Cloud Spannerでは大陸をまたいだ構成をとる場合は、書き込みで選択できる近いリージョンはアイオワかオクラホマ、読込みは台湾になってしまいます。Cloud SQLではひとつのリージョンでしか書き込みができません。そのため、接近性の解決が難しいのですが、Google Cloudの内部通信は速いので、そこまで気にする点ではないかもしれません。​

■関連サイト

過去記事アーカイブ

2021年
03月
04月
05月
06月
07月
08月
09月
10月
11月
2020年
04月
05月
08月
09月
10月
11月
12月
2018年
09月
2017年
06月
2014年
07月