Songkick、Memorystore でインフラストラクチャを刷新

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

Songkick は、音楽ファンとライブイベントを結び付ける、コンサート紹介サービス兼ライブ ミュージック プラットフォームです。Warner Music Group の傘下で、英国を拠点としています。世界中で年間 1 億 7,500 万人の音楽ファンが、モバイルアプリやウェブサイトを通じてお気に入りアーティストの最新情報、コンサート情報、ライブ配信情報を取得したり、オンラインで安全にチケットを購入したりしています。

当社のデベロッパーは 15 名で 4 つのチームに分かれており、全員がロンドンに配属されています。私の職務は、技術面での意思決定とソリューションの構築を支援することで、これらのチーム全体をサポートすることです。Google Cloud に移行した後、フルマネージド型のキャッシュ ソリューションの導入を検討しました。デベロッパーが慣れ親しみ始めていた他の Google ツールと問題なく統合し、デベロッパーがお客様を喜ばせる革新的な製品の開発に集中できるようにするためです。スケーラブルで安全かつ可用性の高い Google の Redis 向けメモリサービス、Memorystore が、これらの目標の達成を支援してくれました。

フルマネージド型の Memorystore が煩雑さを解消

当初のキャッシュ インフラストラクチャはオンプレミスの Memcached のみで構築されていました。当時はこれが使いやすかったのです。その後、Redis を利用して辞書やインクリメントなどの高度な機能を活用するようになりました。当社のサービス指向アーキテクチャでは、これらのオープンソース データストアを両方とも利用していました。2 つの Redis クラスタがあり、1 つは永続データ用、もう 1 つはフロントエンドとサービスの間の簡単なキャッシュ レイヤでした。

Google Cloud の利用方法について検討していたとき、2 つのキャッシュ テクノロジー（Memcached と Redis）があることにメリットはないことに気づき、Redis のみを使用することにしました。当社の用途には Redis ですべて対応できるためです。こうすれば、両方のデータベースに関する知識が不要になります。Redis の方が使用も管理も複雑であることは知っていますが、大きな不安はありませんでした。というのも、Memorystore を使用すれば、Google Cloud が完全に管理してくれるからです。高可用性、フェイルオーバー、パッチ適用、モニタリングの有効化といった複雑な Redis のタスクを Memorystore が自動化するため、空いた時間で新たなエンジニアリングの可能性を模索できます。

壊れた Redis クラスタの修復やネットワーク問題の解決に、どれほどの時間を費やしてきたでしょう。チームが豊富な経験をもつ分野は、インフラストラクチャの管理ではなく開発です。つまり、Redis に関する問題はチームにとって本来の業務を邪魔する、時間のかかるものでした。また、セルフマネージド型のツールの場合、ユーザーにダウンタイムが発生する可能性があります。それに対して、Memorystore は安全なフルマネージド型のオプションであり、コスト効率に優れ、こうした煩雑さを解消してくれるものと見込まれました。Redis のメリットを、その管理という代償を払わずに手に入れることができるのです。このツールを選択することに迷いはありませんでした。

当社での Memorystore の活用方法

Memorystore のユースケースをいくつかご紹介します。当社では Memorystore で 2 つのレベルのキャッシュを利用しています。フロントエンドでサービスに対する API 呼び出しの結果をキャッシュし、一部のサービスでデータベースの結果をキャッシュしています。通常、フロントエンド サービスのキャッシュキーは、URL と、渡されるプリミティブ値です。フロントエンドは、URL とクエリ パラメータを使用して、その結果をすでに取得しているか、サービスとの通信を開始する必要があるかを確認します。

いくつかのサービスでは、サービス自体の中にキャッシュ レイヤがあり、まず Redis と通信してから、ビジネス ロジックを呼び出し、データベースと通信する必要があるかどうかを判断します。このキャッシュはサービスの前に配置され、フロントエンド キャッシュと同じ原則で動作します。

また、フロントエンドの前のキャッシュ レイヤとして Fastly も使用しています。このため、個々のページレベルでは、ページ全体が集中的に Fastly にキャッシュされることがあります。例えば、プラットフォームの人気アーティストのリーダーボード用のページなどの場合です。

Memorystore はユーザーレベルのコンテンツ向けです。例えば、アーティストに関する情報やイベントに関する情報、アーティストに関するおすすめの情報を pull するイベントページなどです。アーティストのページの Fastly のキャッシュが期限切れになった場合は、フロントエンドに移動します。フロントエンドでは、リクエストされた情報すべてをページに表示するために、各種サービスに通信しなければならないことを把握しています。この場合、Redis キャッシュには 3 つの個別のデータがあると考えられます。アーティストのページには Fastly にキャッシュされないコンポーネントがあり、そうした場合は、Redis への依存度が高まります。

当社の Redis キャッシュ TTL（有効期間）は非常に短くなる傾向があり、場合によってはわずか 10 分のキャッシュとなることもあります。その一方、非常に静的なデータの場合は、Redis に数時間キャッシュできることもあります。各データ項目について妥当なキャッシュ時間を判断し、その判断に基づいて TTL を設定しています。1 日に 10 万回呼び出されるアーティストなら、10 分間のキャッシュを設定するだけでも、サービスに取り込まなければならない 1 日あたりの呼び出しの数が大きく違ってきます。

このユースケースでは、約 4 GB のメモリを備えた可用性の高い Memorystore クラスタ 1 つで、allkeys-lru というキャッシュ エビクション ポリシー（最も長い間使用されていないものを削除する）を使用しています。そのクラスタでは現在、ピーク時には 1 秒あたり約 400 件のリクエストを受け取っています。これは平均的な 1 日のアクセス集中時ですが、状況によってはこれを大きく上回ることもあります。

古いインフラストラクチャには 2 つの異なる Redis クラスタがありました。1 つ目はご説明したとおりです。2 つ目は永続的な Redis でした。Google Cloud への移行を検討していたとき、Redis の優れた性能を存分に発揮させようと考えました。そして、Cloud SQL for MySQL または BigQuery を利用して、この永続的な Redis を使用する 4 つか 5 つの機能を簡素化し再設計することにしました。Redis を使用してデータを集計することもありましたが、今では Google Cloud を導入しているため、BigQuery を利用できます。つまり Redis での集計よりも、はるかに優れた分析オプションを手に入れました。

また、Memorystore を分散ミューテックスとしても使用しています。システムにおいて、同時に発生して欲しくないアクションというものがあります。例えば、特定のイベントのデータを移行する際に、2 人の管理者が同時に同じ作業をピックアップしようとするような場合です。このデータ移行作業を同時に行うと、システムに障害が発生することがわかっています。このため、Redis を異なるプロセス間のミューテックス ロックとして使用し、これらのプロセスが同時ではなく連続的に発生するようにしています。

Memorystore と Redis は安心の組み合わせ

移行後、Redis に関して問題は一切ありません。また、標準機能として使用できる Memorystore のモニタリング機能も気に入っています。新しい機能をデプロイするとき、その機能がすぐにキャッシュを埋めるかどうか、またはヒット率が非常に低いため、実装でエラーがあった可能性はないかどうかを簡単に確認できます。

もう一つのメリットは、Memorystore のインターフェースの動作が Redis を操作する場合とよく似ている点です。開発環境では通常の Redis を Docker コンテナで使用しているため、ローカルで実行する場合、キャッシュ コードが意図したとおりに機能していることをシームレスに確認できます。

本番環境とステージング環境は両方とも Virtual Private Cloud で、それぞれ独自の Memorystore クラスタを使用して管理しています。単体テストでは Redis を一切使用しません。また、統合テストでは Docker 内のローカルの MySQL と Docker 内の Redis の両方と通信します。さらに、承認テストも行います。これは、ステージング環境で実行されるブラウザの自動化テストであり、Cloud SQL および Memorystore と通信します。

Memorystore に期待するその他の役割

ほぼ決まっていますが、将来的に考えられる Memorystore のユースケースとして、インフラストラクチャへの Pub/Sub の追加があります。短い間隔で同じメールを 2 回送りたくない場合などに、Redis を使用して、Pub/Sub から届くメッセージの重複除去を行います。Pub/Sub のフルマネージド型サービスの登場も期待しています。現在は RabbitMQ を利用していますが、あまりにも頻繁にデバッグが必要になるためです。同じユースケースについて Pub/Sub を使用したテストを行ったところ、結果は非常に良好で、今回も簡単に決断できました。

Memorystore は、当社が日々使用している Google のデータクラウド ソリューションの一つにすぎません。他に、Cloud SQL、BigQuery、Dataflow も、ETL パイプライン、データ ウェアハウジング、分析サービスのために使用しています。これらによって、アーティストが関与するデータを集計し、それを MySQL にフィードバックして、アーティスト関連サービスで利用しています。Pub/Sub を導入すれば、ほぼすべてが Google Cloud データベース型になるでしょう。このことは、Google Cloud のツールに関する当社の考えを雄弁に物語っています。

音楽のためのサービスと製品を提供している Songkick の詳細をご確認ください。Memorystore について詳しくは、Google Cloud のブログで Memorystore for Redis のパフォーマンスを調整する際のベスト プラクティスをご覧ください。

-Songkick プリンシパル アーキテクト Paul Lawson