प्रमाणीकरण सर्वर की response speed का optimization

• समस्या की पहचान
  • Airbridge प्रमाणीकरण सर्वर में बीच-बीच में response delay हो रहा था।
  • API request से पहले authentication/authorization किया जाता है, इसलिए प्रमाणीकरण सर्वर में delay का पूरे service stability पर सीधा असर पड़ता है।
  • Monitoring के नतीजों में 1 सेकंड से अधिक response delay के alerts धीरे-धीरे अधिक बार आने लगे → कारण विश्लेषण और optimization काम शुरू किया गया।
• कारण विश्लेषण
  • (1) अत्यधिक DB Query: permission check प्रक्रिया में हर request पर बहुत अधिक DB Query हो रहे थे, जिससे DB Connection Pool तेजी से खत्म हो रहा था → response delay हुआ।
  • (2) HikariCP Connection Pool saturation: DB Query के अधिक execution पर HikariCP pool भर गया → 30 सेकंड से अधिक thread wait होने की स्थिति की पुष्टि हुई।
  • (3) कम cache efficiency: TTL को 30 सेकंड जैसा छोटा रखा गया था + अक्षम caching logic → DB Query दोबारा होने की संभावना अधिक थी।
• सुधार रणनीति
  • (1) permission check और caching structure में सुधार
    • DB bulk lookup(findAllBy~) तरीका अपनाया गया → DB Query 134 बार → 4 बार(-97%) तक कम हुए।
    • application memory-आधारित mutableMap caching लागू की गई।
    • Single Responsibility Principle(SRP) लागू किया गया → methods को अलग किया गया और sub-logic के अनुसार caching strategy सेट की गई।
  • (2) 2-Layer Cache structure अपनाई गई
    • Local Cache(Caffeine, L1) + Remote Cache(Redis, L2) का मिश्रित structure लागू किया गया।
    • cache strategy को L1-Only, L2-Only, Hybrid में विभाजित कर operational efficiency बेहतर की गई।
    • cache memory usage analysis → Redis keys 5 लाख अनुमानित, memory requirement लगभग 190MB, और safety buffer सुरक्षित किया गया।
  • (3) Redis Pub/Sub-आधारित cache invalidation
    • TTL पर निर्भर रहने के बजाय permission information बदलते ही real-time cache synchronization किया गया।
    • एक server पर बदलाव होने पर Redis channel के जरिए सभी servers के Local Cache को synchronous invalidation किया गया।
  • (4) HikariCP connection pool tuning
    • maximum-pool-size 10 → 30 तक बढ़ाया गया।
    • Connection Timeout, Idle Timeout, Max Lifetime जैसे detailed options optimize किए गए → DB I/O contention कम हुआ।
• Performance test और परिणाम: बड़े पैमाने के traffic में भी stable performance बनाए रखी गई।
• production environment में सुधार का प्रभाव
  • deployment के बाद response delay alerts गायब हो गए और overall response time स्थिर हो गया।
  • service reliability और operational stability में बड़ा सुधार हुआ।
• अतिरिक्त optimization: JVM Warm-Up
  • deployment के तुरंत बाद JIT compilation delay के कारण initial requests के response delay की समस्या मिली।
  • Warm-Up Runner लागू किया गया:
    • application start पर dummy requests पहले से execute किए जाते हैं।
    • K8s Pod replacement के समय JIT पूरा होने के बाद traffic process किया जाता है → initial response time 1.07s → 94ms तक घटा।
• निष्कर्ष और प्रभाव
  • response delay समस्या का समाधान + traffic spike को संभालने वाली structure सुनिश्चित हुई।
  • Airbridge की समग्र service stability और reliability बेहतर हुई।
  • प्रमाणीकरण सर्वर के उपयोग को बढ़ाकर domain service development productivity में सुधार हुआ।

[anona]

हाल ही में Google deep link service के बंद होने से लगता है कि इस सेवा का उपयोग करने वाली कंपनियां बढ़ी होंगी।
स्थिर सेवा की उम्मीद है!

[daumkakao]

अरे... हमारी कंपनी ने भी हाल ही में यहाँ कॉन्ट्रैक्ट किया है, और आप लोग performance improvement के लिए जमकर मेहनत कर रहे हैं!!!