CloudNative Days Tokyo 2022レポート 9

CNDT 2022、楽天のエンジニアが解説するKubernetesのマルチリージョン化

CNDT 2022から、楽天のSREがAzure上のクラスターをマルチリージョン化した経験を解説したセッションを紹介する。

松下 康之 - Yasuyuki Matsushita

2023年6月5日 6:00

CNDT 2022から、楽天のエンジニアがAzure上のKubernetesクラスターをマルチリージョン化した経験を解説するセッションを紹介する。プレゼンターの佐藤匠氏は、2020年の新卒で楽天グループ株式会社に入社、現在の所属はService Operation Kaizen Section(SOK)という経歴を持つ。SOKは楽天グループが横断的に使う9つのサービスの運用を行っているという。

プレゼンテーションを行う佐藤氏

プレゼンテーションを行う佐藤氏

●動画:Kubernetesのマルチリージョン化ってどうやるの!?教えて楽天のエンジニアさん!

まず説明したのは「ゾーン」と「リージョン」の違いについてだ。ゾーンはデータセンターが存在する完全に隔離された地域を指し、それをリージョンの中に含めることで複数のゾーンがリージョン内に存在するという説明はごく普通の認識と言って良いだろう。そしてマルチリージョンにしたかった理由については、可用性の実現であるとしてこれも普遍的なニーズの実現と言える。

特に問題として説明したのは、これまではリージョンに障害が起こった際の復旧に2時間程度かかっていたということだと言う。またKubernetesのアップグレードについても、コントロールプレーンが活きたままコンポーネントのアップグレードを行うことが必要となってしまっていたとして、運用担当者にとっては心理的にリスクが伴う作業となっていたことを挙げた。

マルチリージョン化の目的

マルチリージョン化の目的

その上でマルチリージョン化には4つのポイントがあったことを説明。ここでは内部アプリと外部アプリの説明を行い、AKS上で動いている外部アプリはリバースプロキシとして稼働するシステムであり、内部アプリの下部に図式化されているRedisは内部アプリのヘルスチェックのためのデータストアであると説明されている。

マルチリージョン化の4つのポイント

マルチリージョン化の4つのポイント

最初はクラスターの冗長化ということで、東のリージョンにセカンダリーとして西のリージョンを追加して、同じアプリ構成が実行されるようにしたことを説明した。この場合、東がプライマリー、西がセカンダリーなのは西のリージョンにはまだマルチリージョンを組む機能が用意されていなかったからと語った。

2つ目のポイントはAzureが用意するGSLB(Global Server Load Blancing)の導入だ。これによって同じIPアドレスへのアクセスを振り分けることが可能になったと説明した。3つ目のcronjobについては、KubectlのPatchコマンドで活性化/非活性化を行えるようにしたと説明した。

そして4つ目のRedisのデータストアに関しては単純に複製を行うのではなく、コスト軽減の観点から別のやり方を編み出したことを解説した。

ヘルスチェックのためのRedisデータストアは単純に複製するとコストが跳ね上がる

ヘルスチェックのためのRedisデータストアは単純に複製するとコストが跳ね上がる

このデータストア自体は高可用性が求められる性質のものではなかったとして、変更のチェックとバックアップをGitHub Actionsで記述して実行、切り替え時には保存されていたバックアップデータから復元することでコストを2倍に抑えたことを解説した。

切り替え時にはバックアップから復元することでコストを2倍に抑えた

切り替え時にはバックアップから復元することでコストを2倍に抑えた

またシステムが利用するシークレットの管理にはHashiCorpのVaultを利用していたが、OSS版のVaultではマルチリージョンには対応していなかったことからマルチリージョンに対応するEnterprise版のVaultを導入して利用を始めたという。

Enterprise版のVaultを導入してマルチリージョン化に対応

Enterprise版のVaultを導入してマルチリージョン化に対応

これらのポイントをクリアして実際に東西のリージョンを切り替えた場合の試験も実施し、これまで2時間かかっていた復旧作業が20分で切り替えられるようになったと説明。ここで目的は達成していることを解説した。またKubernetesのアップグレードも問題なく可能になったという。

切り替えについてはRedisのデータストアの部分においてのみ先にバックアップを復元してからGSLBを切り替えるという順序が存在するが、おおむね希望通りの実装になっていることを説明した。

GSLBの切り替えも重みを変更することで5分で終了

GSLBの切り替えも重みを変更することで5分で終了

最後にまとめとして、障害からの復旧が20分で終了するようになったこと、切り替えに対する精神的な圧力が少なくなり気楽に行えるようになったこと、AKSのアップグレードも安心して実施可能になったこと、そしてシステム全体でカナリアリリースが行えるようになったことなどを述べてセッションを終えた。

基本的にはマネージドのサービスであるAKSを使ってAzureのリージョンに複製を行い、プライマリーとセカンダリーを切り替えるという標準的な実装となっており、マネージドサービスを変にカスタマイズしないという方針が感じられる内容であった。Redisのデータストアの部分にコスト削減の意図が見えるのは、コスト意識が高い楽天のエンジニアならではと言ったところだろう。

この記事をシェアしてください

人気記事トップ10

人気記事ランキングをもっと見る