ざっくりとではあるが、以下の本を一読した。
日本語でRedisについて詳しく書かれた本はこの本くらいしかないかと思うが、それでも次のレベルを目指すWebエンジニアにはお勧めしたい本であった。
ただ、注意していただきたいのは本書は全く入門向けではないということ。確かに前半はコマンド一覧のような説明はあるが、後半からはがっつりと実戦的な内容が書かれている。本書はRedisの説明ではなく、Redisを使って一般的な問題をどう解決するか、ということに主眼が置かれている。
そういった意味で私も一回読んだだけでは到底全てを理解することはできなかった。時間をかけて他の文献も参考にしながらもう一度じっくり読みたいと考えている。
近年のサービスはRedis主体で作られる
もっとも有名な例はLINEだ。あれはペタバイトクラスのRedisを立ててメッセージをやりとりしている。本書にはチャットシステムの構築のヒントも書かれており、メッセージングシステムを構築するのにRedisが優れている点が説明されていた。
そのほかにも、転職システムやTwitterタイムライン、広告配信システム、ログ集計など最近のスタートアップが好んで扱う分野についてサンプルコードを含んで丁寧に説明されていた。それらスタートアップのほとんどは本書を参考にシステムを作ったのではないか、とも感じた。インフラの技術が進めば作れるサービスも変わる、ということを実感できた。そしてRedisが登場したからこそ今までできなかった大規模データ処理サービスが実現できるようになったのだとも言える。
RedisはSQLを書き換える？
Redisは本当にいろいろなことができると知った。今まではちょっと高機能なKVS(Key-Value Store)くらいにしか思っていなかったのだけど、そんなことはなくリレーショナルデータベース(RDB)並みの機能をRedisだけで実現できてしまうのだ!
ただReidsだけで全てを作るのはおすすめできない。結局はKVSの拡張であって設計が大変難しいのと、実際に後からメンテナンスするときもRedisだけで作ったシステムはとても複雑なものになるからだ。例えばキー名を"user:124"にして、中身をハッシュにする。といった設計でやっていく訳だがこれだけでもちょっとトリッキーな感じがしてしまう。
ではどういうときにRedisを使うべきなのか。それは高負荷がかかりそうな部分を補助するときに使う、という立ち位置だと考える。 大規模データを素早く処理したいときにRedisは威力を発揮する。
てことでそこまで負荷のかからない初期のスタートアップはぶっちゃけRDBだけでなんとかなると思う。それでサービスがうまくいったときに負荷のかかる処理をRedisに移行する、というやり方でいいような気もする。
それくらいRedisでデータ設計をするのは難しく失敗しやすい。
だからこそ、RDBの次に学ぶべきものとしてのRedisの立ち位置がもっとも良いのではないか、と思った。
現在のRedisの利用
今運用しているCallConnectでは、Redisを利用している。といってもログインセッションをRedisに置いているくらいだ。ただこの用途だけでもCookieに保存していたRailsのセッションをセキュアに管理できるようになるので大変有用だと考えている。今後バックグラウンドジョブのキューイング処理にまたRedisを利用したいと考えている。
それと同時に今後負荷のかかりそうなデータ処理を扱う際にはRedisの利用を検討していく。
