【ITニュース解説】Step 3: High Level Design (HLD) for a Rate Limiter with Distributed Redis

システムエンジニアを目指す皆さんにとって、日々のWebサービスやアプリケーションがいかにして大規模なユーザーからのアクセスを処理しているのかは興味深いテーマだろう。ここでは、膨大なアクセスを適切に制御し、システムの安定稼働を支える「レートリミッター」という重要な仕組みについて、その設計思想と具体的な構成要素を解説する。これは、一日に数十億ものリクエストと、１０億人規模のユーザーを抱えるような巨大なサービスを想定した、高レベルな設計（HLD）の概要であり、特に「分散型Redis」という技術を核としている。

まず、レートリミッターとは、ユーザーやアプリケーションからのリクエストが一定期間に集中しすぎないように制限を設ける装置のことだ。例えば、「１０秒間に１００回のアクセスまで」といったルールを設定することで、悪意のある攻撃や予期せぬアクセス集中からバックエンドのサーバーを守り、サービスが遅延したり停止したりするのを防ぐ役割を果たす。この設計では、１０億人のユーザーがそれぞれ１００種類のサービスを使い、１つのサービスに対して１０秒間に最大１００回のリクエストを生成するという、非常に高い負荷が想定されている。この場合、一時的に最大８０テラバイトという膨大なデータ量が発生する可能性があるが、データをわずか１０秒間だけ保持することで、必要なストレージを最適化している点が重要だ。システムは、障害が発生してもサービスを継続できるよう、複数のアベイラビリティゾーン（AZ）と呼ばれる物理的に独立したデータセンター区画に分散して配置される。

このレートリミッターシステムの全体像は、クライアントからのリクエストが「グローバルCDN/ロードバランサー」を経由し、複数の「レートリミッターサービスインスタンス」へと振り分けられることから始まる。レートリミッターサービスインスタンスは、実際にアクセス制限の判断を行い、そのために「分散型Redisクラスター」からユーザーの過去のアクセス履歴（タイムスタンプ）を参照する。アクセスが許可されれば、リクエストは「アプリケーションサーバー」へと送られ、本来の処理が行われる。同時に、システム全体の動作状況や制限されたリクエストの詳細は「監視・ロギングシステム」で記録される。また、制限ルール自体は「設定データベース」に格納されるが、これはリアルタイム処理のボトルネックにならないよう、別途管理される。

各コンポーネントの役割を詳しく見ていこう。「レートリミッターサービスインスタンス」は、ユーザーからのリクエストを受け取り、どのユーザーがどのサービスにアクセスしているかを特定する。そして、分散型Redisクラスターに保存されている過去１０秒間のリクエスト履歴を高速に照会し、設定された制限ルールと比較して、リクエストを許可するかブロックするかを判断する。このサービスは、非常に多くのリクエストを処理するため、多数のインスタンスが複数のAZに分散して配置され、負荷分散と高い可用性を実現している。

システムの心臓部とも言えるのが「分散型Redisクラスター」だ。Redisは、データをメモリ上に保持することで超高速な読み書きを実現するデータベースであり、レートリミッターのようなリアルタイム性が求められるシステムに最適だ。ここでは、各ユーザーが各サービスにアクセスしたタイムスタンプを保存する。データの量が増えることに対応するため、データは「シャード（Sharding）」という技術によって複数のRedisサーバーに分散して格納される。これにより、一台のサーバーがすべてのデータを抱え込むことなく、全体として巨大なデータ量を効率的に扱える。さらに、データが失われるのを防ぐため、「レプリケーション（Replication）」によって各データのコピーが複数のサーバーに保持される。もし一部のRedisサーバーが故障しても、別のサーバーがすぐにその役割を引き継ぎ、サービスが中断しないようにする。また、前述した「１０秒間しかデータを保持しない」という要件は、Redisの「TTL（Time-To-Live）」機能によって実現される。これにより、１０秒を過ぎた古いタイムスタンプデータは自動的に削除され、メモリ使用量が常に最適な状態に保たれる。１０億ユーザーのうち、常に一部のユーザーしかアクティブでないことを考慮すれば、必要なメモリ量は大幅に削減されるわけだ。

「グローバルCDN/ロードバランサー」は、世界中からのリクエストを最も近い、または最も負荷の少ないレートリミッターサービスインスタンスへと賢く誘導する役割を持つ。これにより、ユーザーは低い遅延でサービスを利用でき、システム全体への負荷も均一に分散される。レート制限を通過したリクエストを処理する「アプリケーションサーバー」もまた、複数のAZに分散して配置され、高い信頼性を提供する。「監視・ロギングシステム」は、システムが正常に動作しているか、どのくらいのペースでリクエストが制限されているかなど、あらゆるデータを収集し、問題の早期発見や性能改善に役立てられる。そして「設定データベース」は、どのユーザーにどのような制限をかけるかというルールを管理する。これはリアルタイム処理には直接関与しないため、高頻度なアクセスが必要なRedisとは異なる種類のデータベースが使われる。

この設計の核心は、数十億という膨大なリクエストと、１０億人という巨大なユーザーベースに対応するための「スケーラビリティ（拡張性）」と「フォールトトレランス（耐障害性）」を追求している点にある。多数のコンポーネントを地理的に分散された複数のAZに配置することで、一部の機器やAZに障害が発生してもシステム全体が停止することを防ぐ。また、Redisのインメモリ処理とシャード・レプリケーションの活用により、極めて低いレイテンシ（遅延）で、高いスループット（処理能力）を実現している。わずか１０秒というデータ保持期間は、必要最低限の情報だけを保持し、ストレージコストと処理負荷を劇的に削減する賢明な選択と言えるだろう。

このように、大規模なWebサービスを支えるレートリミッターの設計は、単に機能を実現するだけでなく、いかにして膨大なアクセスを安定的に、かつ高速に処理し続けるかという、複雑な課題に対する洗練されたソリューションなのだ。システムエンジニアを目指す皆さんにとって、この種の設計思想は、将来的に多大な影響を与えるだろう。