マイクロサービス アプリケーションのスケーリング: オープンソースから Google Cloud 上の Redis Enterprise へ

※この投稿は米国時間 2023 年 2 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

Redis は、高速キャッシング ソリューションやインメモリ データベースとして優れており、セルフ マネージド オープンソース技術としてスタートアップ企業に広く利用されています。しかし、やがてビジネスが成長し、オープンソースの制限を超えた場合や、OSS デプロイメントの管理に必要な専門知識が社内に不足した場合はどうなるでしょうか。ビジネスの中断やデータ損失を引き起こさずにスケールするには、どうしたらいいでしょうか。この記事では、Google Cloud と Redis を利用して、ビジネスの成長に合わせてオープンソースからエンタープライズ向けソリューションに容易に移行する方法について説明します。

デジタル ネイティブな企業でよく見られるこのシナリオについて、「Online Boutique」という名前の仮想の小売店を使って見ていきましょう。Online Boutique は、最近、顧客と商品をつなぐためのデジタル ストアフロントを立ち上げた人気のオンライン ショップです。このストアフロントでは、Redis オープンソースを使用したキャッシュ保存に加え、Google Kubernetes Engine（GKE）上で動作するマイクロサービス アーキテクチャを利用しています。

Online Boutique の DevOps チームは、この自社開発のマイクロサービス アプリケーションの本番環境へのデプロイとスケーリングを担当しています。チームのエンジニアが、Kubernetes エンジンとして GKE を選択しました。これは、GKE では、インフラストラクチャで 99.95% の稼働率の SLA を確保しながら、アプリケーションとビジネスの成長に合わせてスケールできるためです。

パフォーマンスをスケールし、障害発生時のダウンタイムを回避するために、エンジニアリング チームは、各インスタンスのレプリカの数を増やすだけでマイクロサービスをスケールアウトできるようにしました。DevOps チームは、GKE のクラスタ オートスケーラーと水平 Pod 自動スケーリングを実装することによって、クラスタとマイクロサービスを人間の介在なしに動的に拡大できるようにすることにしました。Online Boutique の Redis オープンソースの構成および管理方法では、複数のレプリカが作成された後、このサービスだけは自動的にスケールできないようになっていました。Redis は永続データを保存するため、レプリカ間でのデータの整合性を確保する必要があったからです。そのため、内部で高度なオーケストレーションが必要になり、管理が複雑になっていました。

チームは、Redis OSS に対するアプローチによって単一障害点が生じる可能性があるという事実と、スケーラビリティと信頼性を向上させるために、Redis をクラスタとしてデプロイする必要があるという点について話し合いました。オンライン ショップを立ち上げる期限が迫っていたため、リーダーは、単一の Redis オープンソース データベース インスタンスは、最初の立ち上げでは許容可能なリスクであると判断しました。Google Compute Engine（GCE）上で Kubernetes を実行していれば、99.5% の稼働率のサービスレベル契約（SLA）を実現できます。つまり、Redis インスタンスがダウンしても、別のノードが再作成され、永続ボリュームにマッピングされます。オンライン ショップを立ち上げたらすぐに、この脆弱性を解決するという約束の下、Redis オープンソースを単一のインスタンスとしてデプロイするという決定が下されました。

数か月が経ち、ついに恐れていた事態が起こりました。深夜 3 時に電話が鳴り始めたのです。Online Boutique のオンライン ストアがダウンしたという大量の通知が届いています。サポート エンジニアがオブザーバビリティ ツールを使用してログ、指標、トレースを調べたところ、Redis インスタンスが 13 回再起動して、「準備完了」状態になっていないことがわかりました。さらに詳しい調査の結果、この単一の Redis インスタンスに対して 1 秒間に 100 万件を優に超える大量のトランザクションが発生していたことが判明しました。これは、単一の Redis オープンソース インスタンスが処理可能な上限を超えています。

エンジニアが問題の診断を終えた後、サイトイベント インシデント（SEV）がトリガーされ、サイトをオンラインに戻すべく、全員が総力を挙げて取り組み始めました。今や、エンジニアリングの責任者とシニア ソフトウェア エンジニアを含めた DevOps チーム全員が電話対応に追われています。ウェブサイトで生じた大量のトラフィックは、セルフ マネージド Redis オープンソース インスタンスが処理できる量を超えていました。ウェブサイトのトラフィックが減少しないのであれば、サイトをオンラインに戻すには Redis をスケールするしかないと結論付けられました。チームは 3 つのグループに分けられました。第 1 グループは、ストアが一時的にオフラインになっていることをユーザーに伝えるため、ストアフロントの静的なランディング ページを作成しました。第 2 グループは、トラフィックが正当なものだったのか、悪意のある攻撃の結果だったのかを調査しました。第 3 グループは、Redis のスケーリングに対するアプローチに関する数か月前の話し合いを再確認しました。

チームは、実行可能ないくつかの対策について議論し、それぞれのアプローチとその長所と短所を整理しました。

Artifact Hub の Redis Operator

長所:

• 無料

• 調達プロセスが簡単

• 既存の GKE クラスタ内で実行可能

• クラウドに依存しない

短所:

• サポートがない

• デプロイ、スケール、アップグレードに関する高度な専門知識が必要

• 設計、テスト、デプロイに時間がかかる

• このオペレーターではマルチクラスタ デプロイメントがサポートされないため、マルチリージョンでの使用が不可能

• スケーラビリティが保証されない

Kubernetes 上の Redis Enterprise

長所:

• 24 時間 365 日のサポート

• 既存の GKE クラスタ内で実行可能

• クラウドに依存しない

• 無料トライアルが利用可能

• デプロイ、スケール、アップグレードに関するわかりやすいドキュメントがある

• マルチリージョンでの使用を可能にするためにマルチクラスタ デプロイメントをサポート

• 2 億件以上の秒間クエリ数（QPS）

短所:

• 費用がかかる（無料トライアル後）

• デプロイ、スケール、アップグレードに関するある程度の専門知識が必要

• 設計、テスト、デプロイに時間がかかる

Google Cloud Memorystore

長所:

• 24 時間 365 日のサポート

• 99.9% の SLA

• フルマネージド サービス

• Google Cloud アカウントを使用した簡単な支払い

• デプロイ、スケール、アップグレード関して必要な専門知識が最小限で済む

• 瞬時にデプロイ可能

• 1 つの画面でインフラストラクチャを管理できる

短所:

• 費用がかかる

• 最大 100 万件の秒間クエリ数（QPS）

• マルチリージョンでの使用が不可能

• 最大データセット サイズ: 300 GB

• クラウドに依存する

• 書き込みをスケールできない（リードレプリカのみ）

Redis Enterprise Cloud

長所: 

• 24 時間 365 日のサポート

• 99.999% の SLA

• フルマネージド サービス

• 瞬時にデプロイ可能

• Google Cloud Marketplace を使用している場合、Google Cloud アカウントから簡単に支払い可能

• 24 TB 以上のデータセット サイズ

• 24 TB 以上のフラッシュ ストレージが必要

• RAM の最大容量: 12 TB 以上

• マルチリージョンとマルチ クラウドでの使用が可能

• クラウドに依存しない

短所:

• 費用がかかる（無料トライアル後）

• インフラストラクチャを管理するための画面は 2 つ

早急にアプリケーションをオンラインに戻さなければならないため、選択肢 1 と 2 は却下されました。チームに、このような事態の再発を防ぐためのオープンソース ベースのソリューションを設計、テスト、デプロイするための十分な時間はありません。残された選択肢は、いずれも SaaS ソリューションである、Google Cloud Memorystore と Redis Enterprise Cloud です。2 つのソリューションの分析を行ったところ、実際的な争点は価格のみでした。しかし、Google Cloud Memorystore と Redis Enterprise Cloud の両方について、同規模のクラスタの価格をできるだけ正確に見積もった結果、価格はほぼ同等でした。

加えて、Redis Enterprise Cloud は可用性が高く、99.999% の SLA が確保されるため、将来的なダウンタイムとデータ損失を最小限に抑えることができます。1 ミリ秒未満のレイテンシ、非常に大規模なデータセットのサポート、クラスタを水平方向にも垂直方向にもシームレスにスケール可能な能力を備えた Google Cloud 上の Redis Enterprise は、将来にわたってあらゆる規模でアプリケーションの最適なパフォーマンスを確保するための明白な選択肢でした。  

次にチームは、Redis Enterprise Cloud をデプロイして、以前の Redis デプロイメントをセルフ マネージドのオープンソース インスタンスから Redis Enterprise Cloud に最小限のダウンタイムでデータを一切失うことなく移行する必要がありました。デプロイは、チームがすでに使い慣れている Google Cloud Marketplace から、非常に簡単に行えました。数回クリックするだけで（Terraform プロバイダもあります）、チームは、可用性の高い Redis Enterprise データベースをほんの数分でプロビジョニングできました。データベースが作成されたら、チームは GKE クラスタに GCP プロジェクトおよびネットワーク名を提供できるようになり、Redis Enterprise Cloud が Redis VPC を使用して GKE VPC をピアリングするための gcloud コマンドを提供しました。ピアリングの完了後は、GKE クラスタがデータベースのプライベート エンドポイント経由で Redis Enterprise データベースに接続できました。

この時点で、チームは、既存の Redis データベース インスタンスから Redis Enterprise Cloud データベースにすべてのデータを移行する必要がありました。これは、ローカル Redis インスタンスとクラウド インスタンスの両方に関する接続情報を次のように使用して、Kubernetes シークレットを作成することによって行われました。

次にチームは、Kubernetes ジョブを開始して、ローカル インスタンスからクラウド インスタンスにデータを移行しました（ローカル インスタンスは、静的なウェブページが配置されたことで、障害が発生した Redis OSS データベースの負荷が取り除かれ、オンラインに戻っていました）。このジョブは次のようなものです。

ジョブの完了後、チームは、次の Kubernetes パッチコマンドを使用して、Redis の新しい場所を指すようにデプロイメントを更新できました。

チームは、すべてが適切に動作していることを確認するためのチェックを実行し、すべてが「問題なく動作している」ことがわかって嬉しい驚きを味わいました。そして、静的なウェブページを取り下げて、トラフィックをストアフロントに戻して、問題なくアプリケーションを再度稼働し、移行しました。

チームが再招集され、一連の出来事やそこから学んだこと、同じ障害の再発を防ぐ方法について振り返りました。まだ答えが出ていない疑問が 1 つあります。「なぜこのようなトラフィックの急増が起きたか」ということです。どうやら、ソーシャル メディアのインフルエンサーが、サイト上で販売されていた靴をいかに気に入っているかを語ったところ、フォロワー全員が同時にストアを閲覧して購入しようとしたことが原因のようです。チームはこのことを、自社のソーシャル メディア アカウントに届いていた、同じ靴を購入したいのに購入できないという買い物客からの苦情で知りました。トラフィックの急増に対応できていたら、ソーシャル メディアのインフルエンサーの発言は嬉しい悲鳴になっていたことでしょう。今後はこれが問題になることはありません。いつでもビジネスのニーズを満たすようにスケールできます。

マイクロサービス アプリケーションをオープンソースから Google Cloud 上の Redis Enterprise にスケールすることによって、リアルタイム アプリケーションに必要なスケーラビリティと高可用性を実現する方法についてお読みいただき、ありがとうございました。Google Marketplace にアクセスして、さらに詳細を確認し、最初の一歩を踏み出すための無料の Marketplace クレジットなどの最新の特典をご利用ください。また、記事を読むだけでなく、実際にこのマイクロサービス アプリケーションをデプロイし、Redis オープンソースから Google Cloud 上の Redis Enterprise への移行がいかに簡単かをご自身で体験してみてください。コードと手順はすべて、GitHub に掲載されています。