VALKEY · インメモリデータベース
Valkey vs Redis:
NAVERの開発者とともに100万TPSを完全攻略
NAVERで10年間サーバーを作り続ける中で経験した場面を、そのまま再現します。在庫がマイナスになり、キャッシュが一斉に期限切れとなってDBが揺らいだ瞬間などです。小規模なECを作りながら、キャッシュからレプリケーション・Sentinel・クラスターの運用まで続けて学び、最後にはノートパソコン1台で毎秒100万件を実際に超えてみます。
1,331,558 RPS
講師のノートパソコン(8コアのApple Silicon、Valkey 9.1)でGETを基準に実測した1秒あたりのリクエスト数です。コマンドを16個ずつまとめるパイプライン条件で得られたもので、条件が異なると98万まで下がることもあります。その差異も含めて、講義でそのままお見せします。(講義タイトルの'100万TPS'はスループットを総称する表現で、実測ラベルはRPSと記載しています。)
SET product:1001 EX 60 NX
HINCRBY cart:u1001 +1
ZINCRBY rank:daily 1
EVAL decr-stock.lua → -1
XADD stream:orders *
PFCOUNT visitors → 10089
SENTINEL failover mymaster
CLUSTER KEYSLOT {user:1001}
BGSAVE → dump.rdb
GET 1,331,558 rps
이런 경험 있으신가요
コマンドは知っていても、運用は別の話でした
"SET、GETは知っているけれど、実務でどう使うのかわかりません"コマンドを並べるだけの講義は多いものの、キャッシュ戦略・同時実行性・イベントパイプラインへとつながる実務の流れを扱う講義はめったにありません。
"在庫がマイナスになったのですが、原因がわかりません"同時実行による事故は、実際に経験してみなければわかりません。この講義では、あえてその事故を起こし、目で確認したうえで防ぐ方法を学びます。
"サーバーが落ちたら、サービスもそのまま一緒に落ちます"レプリケーション、自動フェイルオーバー、シャーディング――運用の領域をDockerで自ら構築し、サーバーを実際に停止させて確認します。
WHY VALKEY
なぜRedisではなくValkeyなのか
Valkeyは、2024年のRedisライセンス変更直後にコミュニティがRedisをフォークして作った、完全オープンソースのインメモリデータベースです。Linux Foundationの傘下で、AWS・Google・Oracleが支援しています。今からインメモリDBを新たに学ぶなら、まずこの分岐点から見ていくほうが理解が早いでしょう。
Valkey
- 完全オープンソース(BSDライセンスを維持)
- Linux Foundation傘下 · AWS・Google・Oracleが開発を支援
- フォーク後、I/Oスレッドの再設計など、性能に重点を置いた投資に注力
- AWS ElastiCacheでRedisエンジンより安価に提供される
Redis
- 2024年に商用ライセンスへ移行後、2025年に一部再オープン化
- 元祖プロジェクト、充実した資料エコシステム
- プロトコル・コマンドはValkeyと互換性あり
この講義はValkeyを基準に進めますが、プロトコルに互換性があるため、学ぶ内容のほとんどはRedisにもそのまま適用できます。Redisを使っていた方には、「Valkeyで変わった点」を講義の随所で取り上げます。
そしてもう一つ――Valkeyを基礎から運用まで扱った韓国語の資料は、まだ多くありません。今のうちに学んでおけば、知っている人の少ない知識になります。
MEASURED, NOT CLAIMED
この講義のすべての数値は実測値です
メーカーのベンチマークを書き写したものではありません。講義に登場する数値はすべて、講師が同じノートパソコン上で自ら実行して得た値で、うまくいかなかった結果もカットせずそのままお見せします――なぜうまくいかなかったのかのほうが、より重要な学びだからです。
46対0
50人同時購入時に消えた在庫(競合状態) vs アトミック操作で防いだ結果
4.5秒 → BUSY
遅いコマンド1つがサーバー全体を停止させる場面 — シングルスレッドを目で確認する
15秒
マスターを停止した後、Sentinelが自動的に新しいマスターを選出するまで
6.6倍
パイプライン処理だけで生じたスループットの差 — 100万の秘密
WHAT ACTUALLY HAPPENS
その数字が出た場面々
上の4つの数字がそれぞれどの画面から出たものなのか、図にまとめました。講義ではこれをターミナル上で実際に再現します。
セクション1
シングルスレッド — 前のコマンドが終わらないと、次のコマンドは実行されません
Valkeyはコマンドを一度に1つずつ処理します。重いLuaスクリプトの実行中、通常7ミリ秒のPINGが4.5秒待たされました。占有が5秒を超えると、サーバーは後続のクライアントにBUSYエラーを返します。
セクション5
競合状態 — GETとSETの間に別のリクエストが割り込みます
50件を処理したのに、減算は4件しか反映されていません。2つのクライアントが同じ値を読み取り、同じ値を書き込んだからです。実行するたびに46、47と結果が変わるのが競合状態(race condition)の特徴です。
セクション 9
Sentinel — 障害判定と昇格を人手なしで処理します
sentinel-1
sentinel-2
sentinel-3
応答が5秒(down-after)途切れると、各Sentinelが主観的ダウンとしてマークし、クォーラム2が集まると客観的ダウンとして確定します。マスタープロセスを直接終了した後、15秒も経てば新しいマスターが昇格しています。
セクション 2 · 11
ボトルネックはサーバー性能ではなく、ラウンドトリップ(往復)でした
1,331,558
ノートパソコン1台でGET基準 RPS・p50 0.975ms
サーバーもコマンドもそのままにして、往復だけを10個ずつまとめたところ、6.6倍(128,534 → 850,000)の差が生まれました。講義の最後にまとめる数を16個に増やして条件を合わせると、133万まで伸びます。
PREVIEW
百の説明よりも、
直接ご覧ください
理論スライドではなく、実際のターミナル画面です。講義で実際に扱う4つの場面を短く切り取ってまとめました。
6ノードのクラスターを構築します
Composeでノードを起動し、--cluster createで16384個のハッシュスロットを分担させる場面です。
遅いキーを直接突き止めます
--bigkeysとSLOWLOGで、どのキーがメモリを消費し、どのコマンドが応答を遅延させているのかを追跡します。
再起動してもデータが残るか確認します
BGSAVEでスナップショットを残し、appendonlyを有効にした後、再起動して実際に生き残るか目で確認します。
在庫がマイナスにならないように防ぎます
条件付き減算Luaスクリプトを登録し、EVALSHAで実行して、同時注文でも過剰販売が発生しないことを確認します。
これらの証拠を、自分で再現しながら学びます
先ほど見た4つの場面は、講義でそのまま再現します。
HOW IT FLOWS
小さなECが成長しながら、必要な分だけ学びます
データ構造を順番どおりに暗記することはしません。サービスに機能が必要になったその瞬間ごとに、ツールを取り出します。講義を終える頃には、キャッシュからクラスター運用まで備えたECバックエンドが一つ、手元に残ります。
- 商品ページが遅いキャッシュを導入します — String、TTL、cache-aside、スタンピード対策
- お客様が商品をカートに入れるカートとセッション — Hash、スライディング有効期限
- 人気ランキングを表示しようお気に入りとランキング — Set、ZSet、HyperLogLog、Bitmap
- 注文が殺到すると在庫が消える同時実行による障害の再現 — アトミック操作、分散ロック、Lua
- 注文後の処理が滞るイベントパイプライン — Listキュー、Pub/Sub、Streamコンシューマーグループ
- コマンドをコードでTypeScriptミニプロジェクト — CLIとコードが1:1で対応
- 再起動すると消える永続化とメモリ — RDB、AOF、eviction、診断ツール
- サーバーが1台停止したらレプリケーションとSentinel — 自動フェイルオーバーを自分で観察
- データが1台より大きくなったらCluster — ハッシュスロット、リシャーディング、クラスターfailover
- 最後の約束I/Oスレッドを有効にしたのにかえって遅くなる実測を見て、本当のボトルネックを見つけ、ノートパソコンで100万突破
WHY NOW
まだRedisしか
ご存じないのですか
NAVERで10年にわたりサーバーを構築してきた人の考えはこうです。Redisを知らなくていいという話ではなく、2024年のライセンス問題以降、すでに情勢は変わってしまったということです。数字で見ると、より明らかです。
10億RPS
Valkey 9が2,000ノードの大規模クラスターで処理する1秒あたりのリクエスト数。単一サーバーでも210万RPSを実現します
15,000台
Aivenが3か月でRedisからValkeyへ移行したサーバー数。公開されている移行事例の中で最大規模です
45%
Amazon AdsがValkeyへ移行して削減したインフラコスト。スループットはむしろ12%向上しました
2万7千
GitHubスター。フォーク1,300件に加え、700人以上のコントリビューターが参加しています
900万
Docker公式イメージのダウンロード数。valkey/valkeyを基準としています
AWS ElastiCacheとGoogle Memorystoreでは、新しいクラスターにValkeyがデフォルトで提供されます。主要なLinuxディストリビューションの標準キャッシュパッケージもValkeyです。Redisを使うには、今や別途選択する必要があります。
ただし、移行後の運用を担うのは結局のところ人間です。レプリケーションを設定し、failoverを確認し、スロットを再分割する作業です。この講座では、その部分を扱います。
出典:Valkey 9.0・9.1リリースノート · AWS Database Blog(Valkey turns two、Amazon Ads事例) · Aiven移行事例 · valkey-io GitHub · Docker Hub valkey/valkey
WHAT YOU CAN CLAIM
ポートフォリオと履歴書に
そのまま書けます
"Redisを使ったことがあります"と"同時購入50件で発生していた過剰販売を0件にしました"は、別の文章です。後者を書くには、実際に問題を起こして自分で測定してみる必要があり、この講義がそのプロセスです。以下の6行は、講義を終えればそのまま書き写せます。
履歴書にはこのように書きます
01
キャッシュスタンピードによるDB負荷の急増をTTLジッター・NX先取りで阻止
無効化のタイミングが重なる状況を再現し、2台のワーカーが同時に更新する際の防御戦略を設計しました
02
同時購入50件で発生していた在庫の過剰販売をアトミック操作・Luaで0件まで改善
GET・SETの競合状態をまず再現し、在庫数が46までずれることを確認したうえで防止しました
03
所有者トークンベースの分散ロックを実装し、他のプロセスによるロック解除事故を防止
SET NX PXで先取りし、unlock.luaでアトミックに解除することで、期限切れやフェイルオーバー時の二重取得の可能性まで検証しました
04
Sentinelベースの自動フェイルオーバーを構成し、マスター障害時に15秒以内の昇格を確認
マスタープロセスを直接終了し、一時的に2つのマスターが存在する状態から、降格・追いつきまで観察しました
05
6ノードClusterを構築し、オンラインリシャーディング・ハッシュタグでCROSSSLOTを解消
ハッシュスロット16384個の分配から、無停止でのスロット移動、クラスターフェイルオーバーまで自ら実施しました
06
パイプライン処理によってスループットを6.6倍に改善し、ボトルネックがラウンドトリップにあることを特定
I/Oスレッドを増やすとかえって12%遅くなる区間も併せて測定し、何が本当のボトルネックなのかを根拠として残しました
6行すべて、この講義で実際に作り、実際に測定するものです。面接で"それで、どう確認したのですか"と聞かれても、答えられる材料が残ります。
講義が終わると、ECバックエンドのリポジトリが1つ残り、それがそのままポートフォリオになります。
WHO & WHAT
このような方に適しています
- インメモリDBを初めて学ぶバックエンド開発者・就職準備中の方(事前知識不要)
- Redisをコマンドレベルでしか使ったことがなく、キャッシュ戦略・同時実行性・運用まで幅を広げたい方
- Redisのライセンス問題を受けて、Valkeyへの移行を検討している方
- レプリケーション・failover・クラスターを自分で構築してみたかった方
準備物:macOS(Apple Silicon推奨)+Homebrew。後半のレプリケーション・クラスタ実習でのみDocker Desktopを使用します。それまではターミナル1つで十分です。実習はvalkey-cliから始め、TypeScriptクライアントのiovalkeyへと進み、スループットはvalkey-benchmarkで実際に測定します。
INSTRUCTOR
講師紹介
NAVER本社で10年目のバックエンド開発者Andeと、板橋のプラットフォームサーバー開発者Hongが共同で制作しました。
NAVER・バックエンドエンジニア・10年目
Ande
NAVER本社でサーバーを開発している、10年目のバックエンドエンジニアです。在庫がマイナスになる事故や、キャッシュが一斉に期限切れとなってDBがぐらつく状況――講義で再現してお見せする場面のほとんどは、実際に現場で経験したことです。質問はお気軽にお寄せください。できる限り確認してお答えします。
うまくいった数字だけをお見せするわけではありません。うまくいかなかった数字からこそ、より多くを学べるからです。
現 ネイバーサーバー(本社)開発者 · 前 新世界グループ バックエンド開発者 · 前 ヘルスケアスタートアップ サーバー開発者 · ソウルの4年制大学でコンピュータ工学を専攻
大容量トラフィックバックエンドアーキテクチャインメモリキャッシュ障害対応
知識共有者・板橋プラットフォームサーバー開発
ホン
板橋でプラットフォームサーバーの開発を担当しています。自分で学んだ方法や、実務で直面する問題・解決策を共有するため、知識共有者としての活動を続けています。この講義では、カリキュラムの作成と撮影を担当しました。
Redisしか知らない人に、なぜValkeyを見るべきなのかというところから説明する必要がありました。その順序をそのまま講義に盛り込みました。
現職:パンギョのプラットフォームサーバー開発者 · 前職:ブロックチェーン・メタバースのバックエンド開発者 · インフラン知識共有者
カリキュラム設計バックエンド講義多数プラットフォームサーバー
MESSAGES
だから、Hong、本当に役に立つのかな?
講義をすべて受講しました。素晴らしい講義をありがとうございます講義を完走してオープンチャットに残してくださったメッセージ
おかげで大きな助けとなり、会社に合格できましたオープンチャットでお知らせいただいた合格の便り
こうしたご連絡をいただけることが、講義を作り続ける理由です。今回の講義も、そんな一言になればうれしいです。
FAQ
よくある質問
Valkeyとは何ですか?Redisとはどのような関係ですか?
Valkeyは、2024年のRedisライセンス変更後に、コミュニティがRedis 7.2をフォークして作成した完全オープンソース(BSD)のインメモリKey-Valueデータベースです。Linux Foundationの傘下でAWS・Google・Oracleの支援を受け、Redisプロトコルと互換性があります。講義の最初の動画で、この誕生の背景をストーリーとして解説します。
会社はまだRedisを使っていますが、それでも意味はありますか?
あります。ValkeyとRedisはプロトコルとコマンドに互換性があるため、講義で学ぶキャッシュ戦略・同時実行処理・レプリケーション・Sentinel・クラスター運用の知識は、Redis環境にもそのまま適用できます。逆に、会社がValkeyへの移行を検討することになった際の判断材料となるライセンスの背景や実測上の違いについても併せて扱います。
どの程度の難易度ですか?最初からすべて見る必要がありますか?
前半は事前知識なしでもついてこられる内容で、後半は永続性・レプリケーション・クラスター・パフォーマンスといった運用の応用編です。ECサービスを引き続き構築していく構成なので、最初からご覧になることをおすすめしますが、Redisの経験がある方は、同時実行性や運用の応用編から選んでご覧いただいても構いません。各動画で扱う内容は、下記のカリキュラム一覧にそのまま記載されています。
Redisを知らなくても大丈夫ですか?
できます。事前知識なしで始められるように設計しています。逆にRedisの経験者であれば、知っている内容がほぼそのまま通用し、Valkeyで変わった点(デフォルト値の改善・新機能)については講義の中で随時個別に解説します。
Windowsでも実習できますか?
講義はmacOS + Homebrewを前提に進めます。Windowsは画面やインストール手順が異なるため、公式にはサポートしていません。
本当に100万TPS出るのですか?
講師のノートパソコン(8コアのApple Silicon)で、GETを基準に、コマンドを16個ずつまとめるパイプライン条件で1,331,558 RPSを実測しました。その実行画面とコマンドを講義でそのままお見せします。同じ条件でも実行ごとに98万まで下がったり、I/Oスレッドを有効にしたところ、かえって遅くなった実測結果も併せて公開します。なお、講義タイトルの'TPS'はスループットを総称する表現で、ページの実測ラベルはGET基準のRPSと記載しています。
コーディングが苦手でもついていけますか?
講義の3分の2はターミナルコマンドの実習なので、コーディング経験はほとんど必要ありません。TypeScriptは1か所(ミニプロジェクト)にまとめてあり、すべてのコードを1行ずつ説明しながら進めます。
どのバージョンを使いますか?
Valkey 9.1を基準にしています。講義のすべてのコマンド・設定をこのバージョンで直接実行し、検証しました。
サーバーを実際に停止させ、100万件を実際に超えてみましょう
コマンドの暗記ではなく、サービスの成長に伴って生じる問題を一つずつ解決していく講義です。
講義が終わる頃には、在庫事故をアトミック操作で防ぎ、マスターを実際に停止させて復旧させ、6ノードのクラスターを構築した状態になります。
COMMUNITY
一人で勉強しなくても大丈夫です
受講中に行き詰まったこと、キャリアの悩み、現場の話――開発者が集まるオープンチャットで一緒に話しましょう。講義に関する質問も歓迎します。
キャリア・転職現役バックエンド技術Q&A勉強会
オープンチャットに参加する