背景
- WafrisはオープンソースのWebアプリケーションファイアウォール企業で、Railsミドルウェアクライアントを提供している
- 初期のv1クライアントはローカルRedisデータストアを必要としていたが、現在はSQLiteを使用するv2クライアントを公開している
- この記事では、RedisからSQLiteへの移行を決断した過程、性能面の考慮事項、アーキテクチャ変更について扱う
要約
- SQLite、Redis、従来型RDBMS（Postgres/MySQL）にはそれぞれ長所と短所がある
- これらのデータストアは相互に完全な代替ではなく、置き換えようとすると問題が生じることがある
- この記事では、Redisベースのv1クライアントをSQLiteベースのv2クライアントへ再構成する過程を説明する
この変更を余儀なくされた理由は？
- Wafrisの目標は、開発者がサイトを簡単に保護できるようにすること
- v1クライアントはRedisデータストアを使用していたが、多くのユーザーがRedisのデプロイに問題を抱えていた
- Redis管理者になる負担を減らすため、SQLiteへ移行した
速度とは何か？
- Redisは従来型RDBMSと比べて高速だが、それでも管理すべき要素が多い
- クラウド環境ではネットワーク遅延が大きな問題となる
- SQLiteはネットワークの往復時間を減らし、より高速な性能を提供できる
モノリシックな前提
- 多くの分散アプリケーションはRedisの利用で問題を引き起こす
- Redis利用の複雑さを減らすため、アーキテクチャを見直した
SQLiteの導入
- SQLiteはネットワークIOのボトルネックを減らす
- SQLiteが競う相手はファイルオープン（fopen()）であり、クライアント/サーバー型データベースではない
SQLiteとRedisのベンチマーク
- SQLiteは特定のユースケースでRedisより約3倍高速
- ネットワーク遅延を考慮しない場合でもSQLiteのほうが速い
チャートで欠けている内容
- たとえベンチマークでSQLiteの性能が劣って見えても、実環境ではネットワーク遅延のためにより高速になる可能性がある
- SQLiteは水平スケーリングが容易で、ユーザーのインストールや設定の負担を減らす
同期アーキテクチャの構築
- v1（Redis）では、ユーザーがルールを更新するとRedisデータストアに反映された
- v2（SQLite）では、クライアントが定期的に更新済みルールを確認し、新しいSQLiteデータベースをダウンロードする
SQLite分散アーキテクチャ
- SQLite DBを各コンピューティングインスタンスに同期し、データベースのボトルネック問題を解決する
結論
- SQLiteベースのv2アーキテクチャは、多くのサイトが攻撃に耐えてオンライン状態を維持する助けになる
- ユーザーの負担を減らし、より安全でセキュリティが強化されたインターネットを提供する
GN⁺のまとめ
- この記事は、RedisからSQLiteへの移行プロセスとその理由を説明している
- SQLiteはネットワーク遅延を減らして性能を向上させ、ユーザーのインストールや設定の負担を減らす
- SQLiteの分散アーキテクチャはデータベースのボトルネック問題を解決する
- この記事は、Webアプリケーションファイアウォールを簡単にデプロイし、高速に動作させる方法についての洞察を提供する
1件のコメント
Hacker Newsのコメント
各アプリケーションサーバーがSQLiteデータベースファイルをコピーし、定期的に入れ替えるモデルに関心がある
Redisの読み書きレイテンシは、問い合わせたキー数に比例する
データセットは120万件の項目に見えるが、実際には大きくない
Neonの社内ハッカソンで、RedisのプロトコルをPostgresクエリに変換するNode.jsサーバーを書いた
RailsWorld 2023ではRedisに対して否定的な空気があった
SQLiteは、サーバー側でレプリケーションなしでもうまく動くニッチなユースケースがあるように見える
Redkaという、RedisをSQLiteで実装したプロジェクトがある
最高の引用: "SQLiteはクライアント/サーバー型データベースとは競合しない。SQLiteが競合するのはfopen()である。"
Redisは従来のRDBMSと比べて高速だが、運用管理が必要
ベンチマーキングとは、非常に精密な数字で自分をだます暗黒芸術だ