Redis से SQLite में पुनर्रचना (Rearchitecting)

xguru · 2024-09-26T09:31:01+09:00

Wafris एक open source web application firewall कंपनी है, जो Rails middleware client प्रदान करती है v1 client को local Redis data store की ज़रूरत थी, लेकिन v2 में SQLite का उपयोग किया गया है यह Redis से SQLite में migrate करने के फैसले की पृष्ठभूमि, performance considerations, और architecture changes को समझाता है TL;DR SQLite कुछ काम बहुत अच्छी तरह करता है, और कुछ नहीं Redis कुछ काम बहुत अच्छी तरह करता है, और कुछ नहीं पारंपरिक RDBMS(Postgres/MySQL) कुछ काम बहुत अच्छी तरह करते हैं, और कुछ नहीं इन data stores को सीधे एक-दूसरे से बदला नहीं जा सकता, और ऐसा करने की कोशिश करने पर दिक्कत होती है यह लेख Redis-आधारित v1 client को SQLite-आधारित v2 client में rearchitect करते समय हुए tests और decision-making process को समझाता है बदलाव के लिए मजबूर करने वाले कारण Wafris का लक्ष्य है कि developers आसानी से अपनी साइट की सुरक्षा कर सकें Redis deployment issues की वजह से v1 इस लक्ष्य को पूरी तरह हासिल नहीं कर पाया Heroku जैसे environments में काम करने के कारण, जहाँ Redis आसानी से इस्तेमाल किया जा सकता था, Redis चुना गया था, लेकिन कई users को Redis deployment issues का सामना करना पड़ा Redis जैसे अलग DB का उपयोग करवाना users के हित में नहीं था "गति" क्या है? Redis पारंपरिक RDBMS से "तेज़" है, लेकिन फिर भी connections, memory, processes आदि को manage करना पड़ता है cloud environment में network latency एक बड़ी समस्या हो सकती है हर incoming HTTP request पर Wafris rules का evaluation करना पड़ता है, इसलिए network latency application को धीमा कर सकती है Monolith-ish मान्यता पूरी तरह distributed applications मौजूद हैं, लेकिन ज़्यादातर Rails apps "Majestic Monoliths" हैं कई regions में deploy की गई, overlapping functionality वाले servers में बंटी हुई, या केवल आंशिक रूप से Rails पर बनी apps में Redis उपयोग करने पर और ज़्यादा समस्याएँ आती हैं architecture पर पुनर्विचार Wafris एक web application firewall है, जो Rails middleware के रूप में install किया जाता है सरल रूप से इसे 2 चरणों में बाँटा जा सकता है: 1) HTTP request की rules से तुलना, 2) processing result की reporting rules का "read" (चरण 1) "write" (चरण 2) से कहीं अधिक महत्वपूर्ण है reads को sequentially process होना चाहिए, fail नहीं होना चाहिए, और ये user-perceived performance को प्रभावित करते हैं writes को धीमे, batch में, या asynchronously किया जा सकता है Enter SQLite SQLite किन उपयोगों के लिए उपयुक्त है, यह दूसरे लोग अच्छी तरह समझा चुके हैं SQLite client/server DB से प्रतिस्पर्धा नहीं करता, बल्कि fopen() से करता है network round-trip हटाने पर उम्मीद थी कि यह Redis से कहीं तेज़ होगा SQLite और Redis का benchmark evaluation करने का फैसला किया गया SQLite और Redis benchmarking benchmarking एक ऐसी अंधेरी कला है, जिसमें बहुत सटीक संख्याओं से खुद को भ्रमित करना आसान है data store benchmarking और भी कठिन है लक्ष्य absolute speed निकालना नहीं था, बल्कि हमारे data और use case के हिसाब से खास benchmarks बनाना था optimization tweaks को नज़रअंदाज़ किया गया। मकसद था कि Wafris app में डालते ही काम करे theoretical benchmarks नहीं, बल्कि हमारे app के hot paths और worst-case queries को test किया गया IP ranges (IPv4, IPv6) को categories से map करने वाली जटिल "lexical decimal" data structure request सबसे खराब query थी range lookups को पहले से calculate करके SQLite tables और Redis sorted sets में लिखा गया हर incoming HTTP request पर request IP की तुलना allow/block custom ranges, GeoIP ranges, और IP reputation ranges से करनी होती है test protocol M2 MacBook Air पर Homebrew से install किए गए Redis और local SQLite DB के साथ test किया गया मौजूदा range dataset (12 लाख items) पर test किया गया कई IP sets को SQLite और Redis पर समान क्रम में चलाया गया हर multiple पर test 5 बार चलाया गया और average निकाला गया test results SQLite ने Redis को स्पष्ट रूप से हरा दिया (हमारे विशेष use case में) SQLite local Redis instance से लगभग 3 गुना तेज़ था यह network latency को ध्यान में रखने से पहले का परिणाम था अगर SQLite सिर्फ Redis के बराबर भी होता, तब भी network time हटने से फायदा होता चार्ट में जो शामिल नहीं है benchmark में SQLite की performance 2 गुना खराब भी हो, तो भी असल में network latency की वजह से यह तेज़ हो सकता है Redis server कितना भी शक्तिशाली हो, network bandwidth, connections जैसी सीमाएँ और regions के बीच latency बनी रहती है SQLite के साथ लगभग असीम horizontal scaling "मुफ़्त में" मिल सकती है SQLite से onboarding बहुत बेहतर हो जाता है। users को शायद पता भी न चले कि यह इस्तेमाल हो रहा है Redis से और performance निकाली जा सकती थी, लेकिन users को Redis settings बदलने के लिए मनाना मुश्किल था नतीजे बस शुरुआत हैं यह साबित हो गया कि SQLite Redis से तेज़ है, लेकिन वास्तविक trade-offs मौजूद हैं ऊपर के tests में writes पर विचार नहीं किया गया reads और writes की प्रतिस्पर्धा को manage करने के लिए DB connections, connection pools, transactions आदि चाहिए जैसे electric supercar से concrete blocks ढोना मुश्किल है, वैसे ही SQLite को उसके लिए अनुपयुक्त भूमिका में इस्तेमाल नहीं करना चाहिए sync architecture बनाना v1(Redis) में जब user Wafris Hub में rules update करता था, तब Redis data store के rules update हो जाते थे SQLite के साथ web server पर "push" नहीं किया जा सकता, इसलिए यह तरीका काम नहीं करता v2(SQLite) में 1) user Wafris Hub में rules update करता है 2) client तय interval पर updated rules check करता है 3) rules update होने पर पूरी तरह नया SQLite DB download करता है इससे users की installation और configuration की ज़िम्मेदारी काफ़ी कम हो गई v2 client की installation success rate 3 गुना बढ़ गई SQLite distributed architecture auto-scaling enabled cloud providers पर deploy की गई Rails app पर विचार करें अगर requests 100req/s से बढ़कर 10,000req/s हो जाएँ, तो compute instances scale होते हैं, लेकिन DB नहीं वास्तव में Rails apps के overload होकर बंद होने का यही मुख्य कारण है SQLite DB को हर compute instance पर sync करके इस समस्या को हल किया जा सकता है, क्योंकि तब सभी calls local रहती हैं writes का क्या? app को read (rule evaluation) और write (reporting) paths में बाँटने के बाद write path को नज़रअंदाज़ किया गया write path को फिर 1) asynchronously Wafris Hub से connect करके report करना 2) reports को batch में भेजना 3) client में DB writes को पूरी तरह हटाना — इस तरह redesign किया गया यह सबके लिए काम न करे, लेकिन हमें सिर्फ उन users की परवाह है जो deploy करने में आसान और तेज़ Wafris client चाहते हैं निष्कर्ष SQLite इस्तेमाल करने वाली v2 architecture से वे बहुत संतुष्ट हैं यह पहले से ही कई sites को attacks झेलने और online बने रहने में मदद कर रहा है शुरुआत करना बहुत आसान हो गया है, जिससे उनकी support मेहनत और users की झंझट दोनों कम हुई हैं उनका मानना है कि यह अधिक सुरक्षित और संरक्षित internet के लिए एक जीत है

(wafris.org)

12 पॉइंट द्वारा xguru 2024-09-26 | 7 टिप्पणियां | WhatsApp पर शेयर करें

Wafris एक open source web application firewall कंपनी है, जो Rails middleware client प्रदान करती है
v1 client को local Redis data store की ज़रूरत थी, लेकिन v2 में SQLite का उपयोग किया गया है
यह Redis से SQLite में migrate करने के फैसले की पृष्ठभूमि, performance considerations, और architecture changes को समझाता है

TL;DR

SQLite कुछ काम बहुत अच्छी तरह करता है, और कुछ नहीं
Redis कुछ काम बहुत अच्छी तरह करता है, और कुछ नहीं
पारंपरिक RDBMS(Postgres/MySQL) कुछ काम बहुत अच्छी तरह करते हैं, और कुछ नहीं
इन data stores को सीधे एक-दूसरे से बदला नहीं जा सकता, और ऐसा करने की कोशिश करने पर दिक्कत होती है
यह लेख Redis-आधारित v1 client को SQLite-आधारित v2 client में rearchitect करते समय हुए tests और decision-making process को समझाता है

बदलाव के लिए मजबूर करने वाले कारण

Wafris का लक्ष्य है कि developers आसानी से अपनी साइट की सुरक्षा कर सकें
Redis deployment issues की वजह से v1 इस लक्ष्य को पूरी तरह हासिल नहीं कर पाया
Heroku जैसे environments में काम करने के कारण, जहाँ Redis आसानी से इस्तेमाल किया जा सकता था, Redis चुना गया था, लेकिन कई users को Redis deployment issues का सामना करना पड़ा
Redis जैसे अलग DB का उपयोग करवाना users के हित में नहीं था

"गति" क्या है?

Redis पारंपरिक RDBMS से "तेज़" है, लेकिन फिर भी connections, memory, processes आदि को manage करना पड़ता है
cloud environment में network latency एक बड़ी समस्या हो सकती है
हर incoming HTTP request पर Wafris rules का evaluation करना पड़ता है, इसलिए network latency application को धीमा कर सकती है

Monolith-ish मान्यता

पूरी तरह distributed applications मौजूद हैं, लेकिन ज़्यादातर Rails apps "Majestic Monoliths" हैं
कई regions में deploy की गई, overlapping functionality वाले servers में बंटी हुई, या केवल आंशिक रूप से Rails पर बनी apps में Redis उपयोग करने पर और ज़्यादा समस्याएँ आती हैं

architecture पर पुनर्विचार

Wafris एक web application firewall है, जो Rails middleware के रूप में install किया जाता है
सरल रूप से इसे 2 चरणों में बाँटा जा सकता है: 1) HTTP request की rules से तुलना, 2) processing result की reporting
rules का "read" (चरण 1) "write" (चरण 2) से कहीं अधिक महत्वपूर्ण है
reads को sequentially process होना चाहिए, fail नहीं होना चाहिए, और ये user-perceived performance को प्रभावित करते हैं
writes को धीमे, batch में, या asynchronously किया जा सकता है

Enter SQLite

SQLite किन उपयोगों के लिए उपयुक्त है, यह दूसरे लोग अच्छी तरह समझा चुके हैं
SQLite client/server DB से प्रतिस्पर्धा नहीं करता, बल्कि fopen() से करता है
network round-trip हटाने पर उम्मीद थी कि यह Redis से कहीं तेज़ होगा
SQLite और Redis का benchmark evaluation करने का फैसला किया गया

SQLite और Redis benchmarking

benchmarking एक ऐसी अंधेरी कला है, जिसमें बहुत सटीक संख्याओं से खुद को भ्रमित करना आसान है
data store benchmarking और भी कठिन है
लक्ष्य absolute speed निकालना नहीं था, बल्कि हमारे data और use case के हिसाब से खास benchmarks बनाना था
optimization tweaks को नज़रअंदाज़ किया गया। मकसद था कि Wafris app में डालते ही काम करे
theoretical benchmarks नहीं, बल्कि हमारे app के hot paths और worst-case queries को test किया गया
IP ranges (IPv4, IPv6) को categories से map करने वाली जटिल "lexical decimal" data structure request सबसे खराब query थी
range lookups को पहले से calculate करके SQLite tables और Redis sorted sets में लिखा गया
हर incoming HTTP request पर request IP की तुलना allow/block custom ranges, GeoIP ranges, और IP reputation ranges से करनी होती है

test protocol

M2 MacBook Air पर Homebrew से install किए गए Redis और local SQLite DB के साथ test किया गया
मौजूदा range dataset (12 लाख items) पर test किया गया
कई IP sets को SQLite और Redis पर समान क्रम में चलाया गया
हर multiple पर test 5 बार चलाया गया और average निकाला गया

test results

SQLite ने Redis को स्पष्ट रूप से हरा दिया (हमारे विशेष use case में)
SQLite local Redis instance से लगभग 3 गुना तेज़ था
यह network latency को ध्यान में रखने से पहले का परिणाम था
अगर SQLite सिर्फ Redis के बराबर भी होता, तब भी network time हटने से फायदा होता

चार्ट में जो शामिल नहीं है

benchmark में SQLite की performance 2 गुना खराब भी हो, तो भी असल में network latency की वजह से यह तेज़ हो सकता है
Redis server कितना भी शक्तिशाली हो, network bandwidth, connections जैसी सीमाएँ और regions के बीच latency बनी रहती है
SQLite के साथ लगभग असीम horizontal scaling "मुफ़्त में" मिल सकती है
SQLite से onboarding बहुत बेहतर हो जाता है। users को शायद पता भी न चले कि यह इस्तेमाल हो रहा है
Redis से और performance निकाली जा सकती थी, लेकिन users को Redis settings बदलने के लिए मनाना मुश्किल था

नतीजे बस शुरुआत हैं

यह साबित हो गया कि SQLite Redis से तेज़ है, लेकिन वास्तविक trade-offs मौजूद हैं
ऊपर के tests में writes पर विचार नहीं किया गया
reads और writes की प्रतिस्पर्धा को manage करने के लिए DB connections, connection pools, transactions आदि चाहिए
जैसे electric supercar से concrete blocks ढोना मुश्किल है, वैसे ही SQLite को उसके लिए अनुपयुक्त भूमिका में इस्तेमाल नहीं करना चाहिए

sync architecture बनाना

v1(Redis) में जब user Wafris Hub में rules update करता था, तब Redis data store के rules update हो जाते थे
SQLite के साथ web server पर "push" नहीं किया जा सकता, इसलिए यह तरीका काम नहीं करता
v2(SQLite) में 1) user Wafris Hub में rules update करता है 2) client तय interval पर updated rules check करता है 3) rules update होने पर पूरी तरह नया SQLite DB download करता है
इससे users की installation और configuration की ज़िम्मेदारी काफ़ी कम हो गई
v2 client की installation success rate 3 गुना बढ़ गई

SQLite distributed architecture

auto-scaling enabled cloud providers पर deploy की गई Rails app पर विचार करें
अगर requests 100req/s से बढ़कर 10,000req/s हो जाएँ, तो compute instances scale होते हैं, लेकिन DB नहीं
वास्तव में Rails apps के overload होकर बंद होने का यही मुख्य कारण है
SQLite DB को हर compute instance पर sync करके इस समस्या को हल किया जा सकता है, क्योंकि तब सभी calls local रहती हैं

writes का क्या?

app को read (rule evaluation) और write (reporting) paths में बाँटने के बाद write path को नज़रअंदाज़ किया गया
write path को फिर 1) asynchronously Wafris Hub से connect करके report करना 2) reports को batch में भेजना 3) client में DB writes को पूरी तरह हटाना — इस तरह redesign किया गया
यह सबके लिए काम न करे, लेकिन हमें सिर्फ उन users की परवाह है जो deploy करने में आसान और तेज़ Wafris client चाहते हैं

निष्कर्ष

SQLite इस्तेमाल करने वाली v2 architecture से वे बहुत संतुष्ट हैं
यह पहले से ही कई sites को attacks झेलने और online बने रहने में मदद कर रहा है
शुरुआत करना बहुत आसान हो गया है, जिससे उनकी support मेहनत और users की झंझट दोनों कम हुई हैं
उनका मानना है कि यह अधिक सुरक्षित और संरक्षित internet के लिए एक जीत है

7 टिप्पणियां

aer0700 2024-09-26

SQLite काफ़ी अच्छा है, लेकिन इस मामले में ऐसा लगता है कि शायद यह बस Redis के लिए उपयुक्त use case ही नहीं था...

kandk 2024-09-26

M2 पर benchmark किया गया था, ये थोड़ा...

colossus 2024-09-29

तो क्या फिर हर AWS instance पर अलग-अलग मापना पड़ेगा? आप open source से कुछ ज़्यादा ही उम्मीद कर रहे हैं।

toru123 2024-09-27

यह उसी server environment में किया गया था, तो क्या यह समस्या है?
क्या benchmark के लिए कोई खास CPU इस्तेमाल करना चाहिए...?

superwoou 2024-09-26

m2 पर किया गया सेटअप किन मामलों में समस्या पैदा कर सकता है? (इस तथ्य के अलावा कि वास्तविक service environment m2 प्रोसेसर नहीं है)