DAT319:AirbnbはどうやってセルフマネージRedisをElastiCacheに移行したのか? #reinvent

はじめに

本記事はAWS re:Invent 2018のセッション「DAT319 - Airbnb's Journey from Self-Managed Redis to ElastiCache for Redis」のレポートです。

3行まとめ

• EC2 上の Redis を ElastiCache Redis にダウンタイム無しに移行
• 多段レプリケーション方式を採用
• ElastiCache Redis はレプリカにはなれないので、特別に許可してもらった

スピーカー

Julie Trias(Site Reliability Engineer , Airbnb)

セッション概要

At Airbnb, we use Redis extensively as an in-memory data store to reduce latency and provide sub-millisecond response for our website, search, images, payments, and more. We migrated our self-managed Redis environment from EC2 classic to fully-managed Amazon ElastiCache for Redis to reduce operational overhead and improve availability. Now, all our Redis is in an AWS managed service that provides multi-Availability Zone support, automatic failover, and maintenance. Attend this session to learn how we migrated our Redis environment while ensuring data integrity and zero downtime.

セッション資料

なぜ ElastiCache for Redis に移行するのか?

EC2 時代には、SimpleStack redis 方式と HARedis の2種類の構成が存在しました

どちらの構成もメリット・デメリットがあります。

• 運用負荷の軽減
• スケーラビリティの確保
• 利用費の軽減(メモリの多いEC2インスタンスは高い)

などのために ElastiCache for Redis へ移行することになりました。

SimpleStack Redis

特別なミドルウェアを使わず、昔ながらの Redis の機能で primary-replica 構成を組みます。

• メリット
  • 構成がシンプル
  • Multi AZ
• デメリット
  • 手動フェイルオーバー
  • シャード未対応

HARedis

Redis Sentinel を利用して HA 構成を組みます。

• メリット
  • フェイルオーバー
  • Multi AZ
• デメリット
  • Ops チームが Sentinel を理解しきれず運用負荷が高い
  • シャード未対応
  • 一部コマンドが未対応

移行の要件

• ダウンタイムを発生させない
• データ損失を発生させない
• 移行直後にキャッシュが存在しないコールドスタートは不可

ElastiCache for Redis への移行の流れ

ElastiCache Redis を EC2 Redis のレプリカとして追加し(???)、切り替えのタイミングでプライマリーに昇格させて移行します。

順に見ていきましょう。

初期状態

EC2 上で Redis の レプリケーション構成が動作しています。

ElastiCache for Redis のレプリカを追加

ElastiCache for Redis を1ノード構成で作成し、レプリカとして追加(！)します。

注意

ElastiCche for Redisはslaveof コマンドが無効化されているため、通常であれば、 レプリカとして追加することは出来ません。

test.bmdeh9.0001.euc1.cache.amazonaws.com:6379> slaveof
(error) ERR unknown command `slaveof`, with args beginning with:

参考 : Restricted Redis Commands

(理解する限りでは)ElatiCache チーム協力の元、slaveof コマンドを特別に許可してもらったようです。

レプリケーション完了後にプロモートに昇格

データ損失を発生させないため、一時的に、Redis クラスターへの書き込みを停止させます。 ElastiCache for Redis のレプリカノードがプライマリと完全に同期したことを確認後(OFFSET で確認)、プライマリに昇格します。

アプリケーションは ElastiCache for Redis のエンドポイントを利用するように切り替えます。

ElastiCache for Redis を冗長構成に

ElastiCache for Redis は1ノード構成のため、レプリカを追加し、マルチ AZ を有効にして完了です。

最後に

DBMS on EC2 を RDS に移行する際に、RDS インスタンスを一度レプリカとして起動し、レプリケーション完了後に、プライマリに昇格させるアプローチはしばしば採用されます。

ElastiCache でも同じアプローチを採用したいところですが、ElastiCache for Redis では、スレーブ用コマンド(slaveof)が無効化されています。

Airbnb のケースでは、 (理解する限りでは)Elaticache Redis チームの協力の元、特別に ElastiCache クラスターをスレーブ化することが許され、ダウンタイムのない移行を実現出来ました。

禁じ手をパブリックに事例紹介することにモヤモヤしますが、それはともかく、「もしElastiCache for Redis が slaveof コマンドを使えたら?」の妄想が実現した事例紹介でした。

参考

• Restricted Redis Commands