法人のお客さま
お問い合わせ
ビジネスブログ

Alibaba Cloud Tair のグローバル分散キャッシュ機能を使ってみた

蒋 渊舒

クラウドエンジニア
蒋 渊舒

2025年5月22日掲載

キービジュアル

ご覧いただきありがとうございます。ソフトバンクの蒋です。

今回は、Alibaba Cloudが提供する高性能キャッシュサービスであるTairのグローバル分散キャッシュ機能について紹介します。

Tairは、Alibaba Cloudが独自に開発したRedisプロトコルに準拠したキャッシュサービスであり、現代のウェブサービスやアプリケーションにおいて普遍的に求められる高速なデータアクセスと迅速な応答に対するニーズに応えるため、広く利用されています。

従来の単一リージョンに配置されたキャッシュサービスでは、物理的に離れた場所からユーザーがアクセスした場合、ネットワーク遅延の影響を受けやすく、アプリケーションの応答速度が低下するという課題がありました。しかしながら、Tairのグローバル分散キャッシュ機能を利用することで、データを複数のリージョンに分散配置し、ユーザーに最も近いリージョンからデータを高速に提供することが可能となります。これにより、グローバルに展開するウェブサービスやアプリケーションにおいても、ユーザーエクスペリエンスを大幅に向上させることができます。

本記事では、Alibaba Cloud Tair のグローバル分散キャッシュ機能を実際に使ってみた経験を共有します。

目次

1. グローバル分散キャッシュ機能とは

Alibaba Cloud Tairのグローバル分散キャッシュ機能は、複数の地理的に離れたTairインスタンス間で高速なデータ同期を実現する、グローバルアクティブ/アクティブ型のキャッシュ機能です。最大3つのTairインスタンス間で低遅延の自動同期が可能となり、マルチリージョンでのアクティブ/アクティブ構成を容易にします。データとユーザーの物理的な距離が縮まるため、アクセス遅延が低減し、応答速度の向上が期待できます。

2. 全体構成図

グローバル分散キャッシュは、最大3つの異なるリージョンに構築されたTairインスタンスによって構成され、各インスタンス間において双方向のデータ同期が実施されます。現在、中国リージョンとそれ以外のリージョン間での利用には制限されており、本検証においては日本（東京）、シンガポール、米国（バージニア）の各リージョンのTairインスタンスを使用します。

1

3. 検証環境の作成

3-1. Tairコンソールにアクセスし、「New Instance」をクリックします。

1

3-2. 以下の条件にてTairインスタンスを作成します。

（注釈※のある条件は、グローバル分散キャッシュ機能の利用に必須となります）

Service：Redis（Open-Source Edition）※

Deployment Mode：Classic※

Region：Japan（tokyo）

Deployment Type：Dual-zone Deployment

Edition Type：Tair（In-Memory）※

Storage Type：In-Memory※

Version：Redis 5.0※

Architecture Type：Clusters

Shards：2

Instance Specifications：2 GB Cluster

1

3-3. 左側のナビゲーションペインから「Global Distributed Cache」を選択し、「Create Instance - Create from existing Instance」をクリックします。

1

3-4. 東京リージョンを選択すると、2-2で作成したTairインスタンスが表示されます。該当インスタンスにチェックを入れ、「OK」をクリックします。

1

3-5. グローバル分散キャッシュの子インスタンスに変換されるTairインスタンスは、「Changing Configuration」ステータスに変わります。

※変換作業は即時ではなく、Tairインスタンスのメンテナンスウィンドウ時間内に実行されます。Tairインスタンスのメンテナンスウィンドウ時間の設定方法については公式ドキュメントを参照してください。

1

3-6. Tairインスタンスのメンテナンスウィンドウ時間を待たずに即時変換を実行する場合は、左側のナビゲーションペインから「Task Center」を選択し、表示される変換タスクの右側に表示される「Modify switching time - Execute now - OK」をクリックします。

1

3-7. 変換完了後、「Add Child Instance」をクリックし、二つ目のグローバル分散キャッシュの子インスタンスを作成します。

※グローバル分散キャッシュの最初の子インスタンスは、新規作成または既存のTairインスタンスから変換できますが、二つ目以降は新規作成のみがサポートされます。

1

3-8. シンガポールリージョンを選択し、二つ目の子インスタンスを作成します。

1

3-9. 手順3-8と同様に、バージニアリージョンに三つ目の子インスタンスを作成します。

 

3-10. グローバル分散キャッシュからの子インスタンスの移出も可能です。その際、子インスタンスに対して「Remove」または「Release」を選択できます。

※「Remove」を選択した場合は、データ保持したTairインスタンスとして残りますが、「Release」を選択した場合は、即時リリースされます。

1

4. タイムラグの計測

Alibaba Cloud TairはRedisと同様、キーの作成日時や更新日時を記録しないため、各子インスタンスのキー登録時刻を直接取得して比較する手段は存在しません。そこで、タイムラグ計測プログラムを用いて、東京リージョンの子インスタンスに書き込み後、シンガポール、バージニアリージョンの子インスタンスでのキー存在確認を複数回実施し、レプリケーションラグを測定する方式を考案しました。

計測プログラムと子インスタンス間のネットワーク状況、及びプログラム実行所要時間等に起因する誤差が生じ得るため、以下の対策を講じました。

  • レプリケーション先の子インスタンスと同一リージョンに所在するFunction Computeを利用し、且つ、子インスタンスのイントラネットEndpointを利用することにより、ネットワーク遅延を最小化する
  • レプリケーション先の子インスタンスに既存するキーの存在確認も複数回実施し、その所要時間をレプリケーションラグから除外する

 

4-1. シンガポールリージョンで、Function Computeサービスを作成し、シンガポールの子インスタンスが配置されているVPCに接続します。

1

4-2. 下記既存キーの存在確認に要する時間を計測するコードをデプロイし、実行します。

import redis

import time

import random


def handler(environ, start_response):

    try_time = 100

    total_latency = 0

    key = ”testkey”

    value = "value"

    redis_target = redis.Redis(＜ターゲット子インスタンスのイントラネットEndpoint＞)

    redis_target.set(key, value)


    for i in range(try_time):

       start = time.time()

       while True:

            find = redis_target.exists(key)

            if find > 0:

                break

       redis_target.close()

       latency = time.time() - start

       total_latency += latency

       print(f"{i + 1}回目: {latency:.5f} 秒")


    avg_latency = total_latency / try_time

    print(f"平均値: {avg_latency:.5f} 秒")

    return b"FC Invoke End"

4-3.  既存キーの存在確認に要する平均時間は約「0.00243」秒です。これはネットワーク接続及びプログラム実行に起因するものと考えられます。

1

4-4. レプリケーションキーの存在確認に要する時間を計測するコードをデプロイし、実行します。

import redis

import time

import random


def handler(environ, start_response):

    try_time = 100

    total_latency = 0

    value = "value"


    for i in range(try_time):

       redis_tokyo = redis.Redis(＜東京子インスタンスのインターネットEndpoint＞)

       redis_target = redis.Redis(＜ターゲット子インスタンスのイントラネットEndpoint＞)

       key = ''.join(random.sample('ABCDEFGHIJKLMNOPQRSTUVWXYZ', 7))

       redis_tokyo.set(key, value)


       start = time.time()

       while True:

            find = redis_target.exists(key)

            if find > 0:

                break

       latency = time.time() - start

       total_latency += latency

       print(f"{i + 1}回目: {latency:.5f} 秒")

       redis_tokyo.close()

       redis_target.close()


    avg_latency = total_latency / try_time

    print(f"平均値: {avg_latency:.5f} 秒")

    return b"FC Invoke End"

4-5. レプリケーションキーの存在確認に要する平均時間は約「0.02657秒」です。これに対し、既存キーの存在確認に要する平均時間は約「0.00243秒」であり、その差分である「0.02414秒」は東京とシンガポールリージョン間のレプリケーションタイムラグであると考えられます。

1

4-6. 東京リージョンとバージニアリージョン間におけるレプリケーションタイムラグを、手順4-1から4-5と同様の手法で測定し、下記に各リージョン間のタイムラグを一覧表としてまとめました。

 

シンガポール（100回平均）

バージニア（100回平均）

既存キー

0.00243秒

0.00087秒

（東京からの）レプリカキー

0.02657秒

0.02992秒

（東京からの）タイムラグ

0.02414秒

0.02905秒

5. まとめ

Alibaba Cloudが提供する高性能キャッシュサービスであるTairのグローバル分散キャッシュ機能について検証を実施しました。

本検証では、日本（東京）、シンガポール、米国（バージニア）の各リージョンにTairインスタンスを配備し、複数の地理的に隔たったTairインスタンス間でグローバルアクティブ/アクティブ構成を構築しました。計測の結果、東京とシンガポール、バージニア間のレプリケーションタイムラグは約20ミリ秒台と測定されました。

本文には記載していませんが、Valueの値を若干大きくした場合の影響についても検証しました。

レプリカキーの場合、Valueサイズがおよそ10KBまでは両リージョンともに特段の変化は見られず(20ミリ秒台)、その後はサイズが増大するにつれて遅延も増大する傾向が見受けられました。100KBの場合、シンガポールでは200ミリ秒台、バージニアでは400ミリ秒台を記録しています。

一方、既存キーの場合は100KBであっても両リージョンとも2ミリ秒台で変化は見られず、Valueサイズが増加するとレプリカ所要時間が増加すると推察されます。グローバル分散キャッシュ機能を検討する際の参考にしていただければ幸いです。最後までご覧いただき、ありがとうございました。

関連サービス

Alibaba Cloud

Alibaba Cloudは中国国内でのクラウド利用はもちろん、日本－中国間のネットワークの不安定さの解消、中国サイバーセキュリティ法への対策など、中国進出に際する課題を解消できるパブリッククラウドサービスです。

MSPサービス

MSP（Managed Service Provider）サービスは、お客さまのパブリッククラウドの導入から運用までをトータルでご提供するマネージドサービスです。

 ＼ 業務課題をデジタルで支援 ／

デジタルツールの選定から導入の手引きまで、中小規模のお客さまへわかりやすくお伝えします。

中小規模のお客さま向けサイトをみる

メールマガジン登録（無料）
ビジネスに役立つ記事やウェビナー情報をお届けします。

おすすめの記事

条件に該当するページがございません

法人のお客さま向け イベント

イベント・セミナー

ビジネスに役立つ 資料ダウンロード

資料ダウンロード

「今」と「未来」を発信 ソフトバンクのビジネスブログ

ビジネスブログ

クラウドテクノロジーブログ

クラウドテクノロジーブログ