Redis

このチュートリアルでは、RedisのZREVRANGEBYLEXコマンドを使って、ソート済みセット（Sorted Set）から特定の範囲内の値を持つすべての要素を、辞書順の降順で取得する方法を解説します。 ZREVRANGEBYLEXコマンドとは ZREVRANGEBYLEXコマンドは、指定したキーに保存されているソート済みセットの要素のうち、max引数とmin引数で指定された範囲（要素の文字列表現）に該当するすべての要素を返します。このコマンドを利用する際は、ソート済みセットのすべての要素を同じスコアで挿入し、辞書順（レキシコグラフィカル順）での並び替えを強制するのが前提となります。返される

このチュートリアルでは、ソート済みセット（Sorted Set）の値から、特定の範囲に含まれる要素を削除する方法を解説します。そのために使用するのが、RedisのZREMRANGEBYLEXコマンドです。 ZREMRANGEBYLEXコマンドとは ZREMRANGEBYLEXコマンドは、ソート済みセットの値の中から、要素の文字列表現がmin引数とmax引数で指定した範囲内にあるすべての要素を削除します。 なお、このコマンドを使う前提として、ソート済みセット内のすべての要素には同じスコアが設定されている必要があります。これは、スコアではなく辞書順（レキシコグラフィカル順）で並べ替えを強制するため

このチュートリアルでは、RedisのZLEXCOUNTコマンドを使って、指定した範囲内の値を持つソート済みセット（Sorted Set）の要素数を取得する方法を解説します。 ZLEXCOUNTコマンドとは ZLEXCOUNTコマンドは、ソート済みセットに格納された要素のうち、min（最小値）とmax（最大値）の引数で指定した範囲に含まれる要素（要素の文字列表現）の数を返します。 このコマンドを利用する際は、ソート済みセットのすべての要素に同じスコアを挿入しておく必要があります。こうすることで、スコアではなく要素そのものの辞書順（レキシコグラフィカル順）による並び替えが強制されます。 範囲指定の

サーバーレス向けデータベースを設計する上で、私たちにとって最大の課題は、リクエスト単位の課金を収益性のある形で実現できるインフラを構築することでした。Upstashはこれを達成したと考えていました。しかし製品ローンチ後、もう一つの重大な課題が浮上しました。それがデータベース接続です。 なぜサーバーレスでデータベース接続が問題になるのか ご存知の通り、サーバーレス関数は0から無限大までスケールします。トラフィックが急増すると、クラウドプロバイダーは新しいコンテナ(Lambda関数)を並行して作成し、バックエンドをスケールアウトします。関数内で新しいデータベース接続を確立すると、あっという間にデー

はじめに本記事では、典型的なWebアプリケーションのユースケースを想定し、3つのサーバーレスデータベース——DynamoDB、FaunaDB、Upstash（Redis）——のレイテンシーを実測データに基づいて比較します。検証のためにニュースサイトのサンプルを構築し、サイトへの各リクエスト時にデータベース関連のレイテンシーを記録する仕組みを実装しました。実際のサイトとソースコードは公開しているので、興味のある方はぜひ参照してください。各データベースには、New York Times Archive APIから収集した7,001件の記事（2021年1月分の全記事）を挿入済みです。さらに、各記事に

私たちは、Redisを使えばサーバーレスアプリケーションをいかに手軽かつ実用的に開発できるかを示すため、サンプルアプリケーションの開発を続けてきました。これまでに公開した例の中で最も人気が高いのが「ロードマップ投票アプリケーション」です。しかし、実際の運用を始めると、次の2つの大きな課題が浮き彫りになりました。 スパム投稿の発生： アプリには管理ダッシュボードがなく、投稿を削除するにはRedisに直接接続する必要がありました。 リリース済み機能の管理： リストから一部の機能を実際にリリースした後も、「リリース済み」としてマークし、投票リストから除外する手段がありませんでした。 この2つの問

サーバーレスアーキテクチャの最大の魅力のひとつは、大規模なトラフィック急増時にも自動的にスケールできる点です。しかし残念ながら、スケーリングは金銭的にも技術的にも「無料」ではありません。そのため、開発者はアプリケーションのスケーラビリティを適切に制御する必要があります。 ここでは、サーバーレスアプリケーションにレート制限（Rate Limiting）メカニズムが必要となる主な理由を3つ紹介します。 レート制限が必要な3つの理由 1. リソースの保護 公開APIを提供している場合、トラフィックの急増はサービス品質の低下を招き、最悪の場合、全ユーザーに対するサービス停止につながる可能性があります。

Next.jsは、サーバーサイドレンダリング（SSR）と静的サイト生成（SSG）を組み合わせた、非常に人気の高いWebフレームワークです。SSGはCDNキャッシュによってWebサイトの表示速度を向上させ、SSRはSEO対策や動的なデータ処理において大きな強みとなります。 サーバーサイドレンダリングは、フルスタックアプリケーション開発を支援してくれる優れた機能です。しかし、注意深く設計しないと、Next.jsサイトのパフォーマンスは容易に低下してしまいます。本記事では、Redisを活用してNext.jsのAPI呼び出しを高速化する方法を解説します。その前に、まずはよりシンプルなパフォーマンス改善

このたびUpstashは、「マルチゾーンレプリケーション」機能の提供開始をお知らせいたします。この機能を有効にすると、データは複数のアベイラビリティゾーン（AZ）に複製されます。これにより、高い可用性と優れたスケーラビリティを同時に実現できます。 高可用性 マルチゾーンデータベースは、異なるゾーンで稼働するデータベースレプリカが存在するため、障害に対してはるかに強い耐性を持ちます。あるアベイラビリティゾーンが利用できなくなった場合でも、リクエストは自動的に正常なゾーンへ振り向けられるため、アプリケーションへの影響はありません。シングルゾーン構成でのフェイルオーバーには数分を要しますが、マルチゾ

エッジコンピューティングは、近年もっとも注目されている技術のひとつです。CDNがファイルをユーザーの近くに配置できるようにしたのと同じように、エッジコンピューティングはアプリケーションそのものをユーザーの近くで実行できるようにします。これにより、開発者はグローバルに分散され、高いパフォーマンスを発揮するアプリケーションを構築できるようになります。 Cloudflare Workersとステートレス性の課題 現在この分野をリードしている製品がCloudflare Workersです。コールドスタートのないサーバーレス実行環境を提供し、Cloudflareのグローバルネットワークを活かすことで、ア

Webサイトへのアクセスを特定のIPアドレスのみに制限したいというニーズはよくあります。この記事では、エッジコンピューティングを活用してIP許可/拒否リストを実装する方法を解説します。まずはCloudflare Workersについて簡単に紹介しましょう。 Cloudflare Workersとは Cloudflare Workersは、近年非常に注目されているテクノロジーです。2017年に一般公開され、Cloudflare KVストレージも2019年に利用可能になりました。 ここでは細部には立ち入らず、両者を簡単に説明します。Cloudflare Workersを使うと、HTTPリクエストを

この記事では、ServerlessなNext.jsをベースにしたTODOアプリケーションを構築します。可能な限りミニマルにすることを目指します。データベース接続は一切使わず、Next.js以外の余計な依存関係も持ちません。ボタンすらありません。ミニマリズムはクールで洗練されていて素晴らしいのですが、私がこれを愛する最大の理由は、単純に怠惰な開発者だからこそ実装の手間が少ないことに魅力を感じるからです:) なぜデータベース接続を避けるのか？ Next.jsは、フロントエンド開発者がフルスタックアプリケーションを開発できるようにするモダンなフレームワークです。サーバーレス関数は、Next.js開発

Upstashは、ネイティブなRedis APIに加えてREST APIもサポートしており、開発者はサーバーレス関数やエッジ関数から接続の問題を気にせずRedisへアクセスできます。しかし、同じ関数内で複数のRedisコマンドを実行する場合、その回数だけデータベースへの呼び出しが発生してしまうという課題がありました。 そこで、コミュニティメンバーの一人である@MasterGates氏が、Discordチャンネルで素晴らしい提案をしてくれました。それが「Pipeline API」です。 Pipeline APIとは Pipeline APIは、RedisのPIPELINEコマンドをREST A

Upstash Terraform プロバイダーが正式公開されました このたび、Upstash Terraform プロバイダーが一般公開されたことをお知らせいたします。私たちの基本理念は常に「開発者フレンドリーであること」。最近 REST API をリリースしたばかりですが、今回さらにツール群を拡充し、Terraform プロバイダープラグインを提供開始しました。 Terraform は、インフラストラクチャをコード(IaC)として定義できる強力な自動化ツールです。このアプローチにより、チームでの共同作業が格段に容易になり、すべての設定変更が履歴として残るため、インフラの状態を誰もが正確に把

AWS Lambdaはサーバーレスコンピューティングの先駆けであり、多くの開発者がサーバーレスこそが開発の未来だと考えています。真の従量課金（ペイ・パー・ユース）モデルを実現し、バックエンドインフラの保守やスケーリングから解放される点は大きな魅力です。しかし一方で課題も存在します。そのひとつが「ステートレス」であるという特性です。状態を保持するには外部のデータストアが必要になりますが、主要なデータストアの多くはコネクションベースで設計されています。以前の記事で解説したように、サーバーレス環境では接続の管理が大きな負担になりがちです。そこで私たちは、Upstash Redisの上に高性能なRES

Redisでは、データベースとクライアントが同じリージョン内にあれば、1ミリ秒のレイテンシは容易に実現できます。しかし、クライアントが世界中に分散している場合、レイテンシは100ミリ秒を超えてしまいます。この課題を解決するために開発されたのが「Edge Caching(エッジキャッシング)」です。 エッジキャッシングとは エッジキャッシングでは、CDNと同じようにREST APIのレスポンスが世界各地のエッジロケーションにキャッシュされます。エッジキャッシングを有効にすると、平均5ミリ秒というグローバルレイテンシを実現できます。実際に、10の異なるリージョンに配置したクライアントからレイテンシ

はじめに 本記事は、2021年4月に公開したブログ記事の続編です。 私たちは、一般的なWebユースケースとサーバーレス関数を用いて、主要なサーバーレスデータベースのパフォーマンスを比較するサンプルアプリケーションを構築しました。比較対象は、DynamoDB、MongoDB(Atlas)、Firestore、Cassandra(Datastax Astra)、FaunaDB、Redis(Upstash)の6つです。 アプリケーションおよびソースコードは公開しているので、ぜひご確認ください。 測定内容と方法 今回比較したのは、各データベースで上位10件のニュース記事を取得する際のレイテンシです。

サーバーレスは、アプリケーションを最小限の運用コストと費用でエンドツーエンドに構築したい開発者にとって理想的なアーキテクチャです。サーバーレス関数を使えば、バックエンドインフラを管理することなく自分のコードを実行できます。しかし、サーバーレス関数は設計上ステートレス(状態を持たない)であるため、外部のデータストアが必須となります。そこで次の疑問が生まれます。「どのデータベースがサーバーレスに最適なのか?」 幸いなことに、各データベースベンダーもサーバーレストレンドを認識しており、サーバーレス向けサービスの提供を開始したり、既存製品の対応を進めたりしています。本記事では、まず「サーバーレスに優れ

近年、アプリケーションのデプロイにおいて、サーバーレスアーキテクチャとエッジコンピューティングが急速に普及しています。しかし、サーバーレス関数やエッジ関数の中でアプリケーションの状態やデータを保存するのは、まったく別の話です。データベースへの接続管理、複数拠点からの高速なデータアクセスの実現など、乗り越えるべき課題が数多くあります。サーバーレスアクセスに対応したデータベースサービスは限られており、さらにエッジ関数にも適したものとなると、ごくわずかしか存在しません(詳細な分析はこちらの記事をご覧ください)。Upstashでは、創業当初から低レイテンシかつリクエスト単位の従量課金モデルを採用したサ

Upstashは、AWS Lambda関数にとって最良のデータベースとなることをミッションに、その歩みを始めました。その過程で、私たちはサーバーレス関数を構築するためのもう一つの優れた選択肢――Cloudflare Workersを発見しました。Cloudflare Workersは、世界中どこでも低レイテンシを実現しながら、低コストでコールドスタートもないという魅力的な製品です。しかし、AWS Lambdaと比較すると多くの制約があり、それによって利用できるデータベースの選択肢はさらに狭まります。私たちはこれを好機と捉え、「CF Workersはステートレスだが、データはどこに置くべきか?」