ಡೆವಲಪರ್‌ಗಳು ತಾವು ಹೊಸದಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್, ಕೆಲವು ಸಾವಿರ ಬಳಕೆದಾರರು “go” ಕ್ಲಿಕ್ ಮಾಡಿದ ತಕ್ಷಣವೇ ನಿಂತುಹೋಗುವುದನ್ನು ನೋಡುತ್ತಾರೆ. ಈ ವಿಳಂಬವು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಲ್ಲಿನ ಬಗ್ (bug) ಆಗಿರುವುದಿಲ್ಲ – ಬದಲಾಗಿ ಅದು ಸರ್ವರ್‌ನ CPU ಮತ್ತು RAM ಸ್ಥಳಕ್ಕಾಗಿ ಹೋರಾಡುತ್ತಿರುತ್ತದೆ. ಈ ಅಡಚಣೆಯು (bottleneck) ದೀರ್ಘವಾದ ಪೇಜ್ ಲೋಡ್‌ಗಳು, ಟೈಮ್-ಔಟ್‌ಗಳು ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪೂರ್ಣವಾಗಿ ಕ್ರ್ಯಾಶ್ ಆಗುವ ರೂಪದಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಇದು ಬಳಕೆದಾರರ ಅನುಭವ (user experience), ಆದಾಯ ಮತ್ತು ಬ್ರ್ಯಾಂಡ್ ಮೇಲಿನ ನಂಬಿಕೆಯನ್ನು ಹಾನಿಗೊಳಿಸುತ್ತದೆ.

ಪ್ರಯೋಗಾಲಯದಲ್ಲಿ (lab) ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಸರ್ವರ್ ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಏಕೆ ನಿಂತುಹೋಗಬಹುದು

ಡೆವಲಪ್‌ಮೆಂಟ್ ಸಮಯದಲ್ಲಿ ಒಬ್ಬನೇ ಡೆವಲಪರ್ ಕೇವಲ ಕೆಲವು ವಿನಂತಿಗಳನ್ನು (requests) ಕಳುಹಿಸುವುದರಿಂದ, ಸರ್ವರ್‌ನ ಸಂಪನ್ಮೂಲಗಳು ಹೆಚ್ಚಿನ ಸಮಯ ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತವೆ. ಅಪ್ಲಿಕೇಶನ್ ಲೈವ್ ಆದಾಗ, ಪ್ರತಿಯೊಬ್ಬ ಭೇಟಿ ನೀಡುವವರೂ ಒಂದು ವಿನಂತಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತಾರೆ, ಇದಕ್ಕೆ ಎರಡು ಪ್ರಮುಖ ಅಂಶಗಳು ಬೇಕಾಗುತ್ತವೆ:

  • CPU (central processing unit) – ಪ್ರತಿಯೊಂದು ಲೂಪ್, ಫಂಕ್ಷನ್ ಮತ್ತು ಲೆಕ್ಕಾಚಾರವನ್ನು ನಡೆಸುವ ಪ್ರೊಸೆಸರ್. ಇದನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಸೀಮಿತ ಸಂಖ್ಯೆಯ ಖಾದ್ಯಗಳನ್ನು ಮಾತ್ರ ತಯಾರಿಸಬಲ್ಲ ಅಡುಗೆಯವನಿಗೆ ಹೋಲಿಸಬಹುದು. ಒಂದು ಆರ್ಡರ್ ತಕ್ಷಣವೇ ಸಿದ್ಧವಾಗುತ್ತದೆ; ನೂರು ಆರ್ಡರ್‌ಗಳಿದ್ದರೆ ಅಡುಗೆಯವನು ಅದೇ ವೇಗದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾನೆ, ಆದರೆ ಗ್ರಾಹಕರು ಹೆಚ್ಚು ಸಮಯ ಕಾಯಬೇಕಾಗುತ್ತದೆ.
  • RAM (random-access memory) – ಒಂದು ವಿನಂತಿಯನ್ನು ನಿರ್ವಹಿಸುವಾಗ CPU ಗೆ ಬೇಕಾದ ಡೇಟಾವನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಸಂಗ್ರಹಿಸುವ ಸ್ಥಳ. ಇದು ಅಡುಗೆಯವನು ಪ್ರತಿಯೊಂದು ಖಾದ್ಯಕ್ಕೆ ಬೇಕಾದ ಪದಾರ್ಥಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವ ಮೇಜಿನಂತೆ. ಒಂದು ವೇಳೆ ಮೇಜು ತುಂಬಿದ್ದರೆ, ಸ್ಥಳ ಖಾಲಿಯಾಗುವವರೆಗೆ ಅಡುಗೆಯವನು ಹೊಸ ಆರ್ಡರ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕಾಗುತ್ತದೆ.

ಸಾವಿರಾರು ಬಳಕೆದಾರರು ಏಕಕಾಲದಲ್ಲಿ ಲಾಗ್ ಇನ್ ಆದಾಗ, ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯು ತನ್ನದೇ ಆದ CPU ಸಮಯ ಮತ್ತು RAM ಅನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತದೆ. ಸರ್ವರ್‌ನ ಸೀಮಿತ ಸಂಪನ್ಮೂಲಗಳು ವಿನಂತಿಗಳ ನಡುವೆ ಹಂಚಿಕೆಯಾಗುತ್ತವೆ ಮತ್ತು ಕ್ಯೂ (queue) ಬೆಳೆಯುತ್ತದೆ. ಸರ್ವರ್ ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ನಿಧಾನವಾಗುವುದಿಲ್ಲ; ಬದಲಾಗಿ ಪ್ರತಿ ವಿನಂತಿಗಾಗಿ ಕಾಯುವ ಸಮಯ ಹೆಚ್ಚಾಗುತ್ತದೆ.

“ಕೇವಲ ದೊಡ್ಡ ಯಂತ್ರವನ್ನು ಖರೀದಿಸೋಣ” ಎಂಬ ಆಸೆ

ಸಾಮಾನ್ಯವಾಗಿ ಮೊದಲ ಪ್ರತಿಕ್ರಿಯೆಯೆಂದರೆ ಮಷೀನ್ ಅನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುವುದು – ಇದನ್ನು vertical scaling ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ CPU ಕೋರ್‌ಗಳು ಅಥವಾ ಹೆಚ್ಚಿನ RAM ಅನ್ನು ಸೇರಿಸುವುದರಿಂದ ಸಾಮರ್ಥ್ಯವು ಸುಧಾರಿಸುತ್ತದೆ: 4 ಕೋರ್‌ಗಳಿಂದ 16 ಕ್ಕೆ ಅಥವಾ 8 GB ಯಿಂದ 64 GB ಗೆ ಬದಲಾಯಿಸುವುದರಿಂದ ಯಾವುದೇ ಕೋಡ್ ಬದಲಾಯಿಸದೆ ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತಡೆದುಕೊಳ್ಳಬಹುದು.

ಆದರೆ, ವರ್ಟಿಕಲ್ ಸ್ಕೇಲಿಂಗ್ ಕೆಲವು ಮಿತಿಗಳನ್ನು ಎದುರಿಸುತ್ತದೆ:

  • ಭೌತಿಕ ಮಿತಿಗಳು (Physical limits) – ಪ್ರತಿಯೊಂದು ಮದರ್‌ಬೋರ್ಡ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಕೋರ್‌ಗಳು ಮತ್ತು ಸೀಮಿತ ಪ್ರಮಾಣದ ಮೆಮೊರಿಯನ್ನು ಮಾತ್ರ ಹೊಂದಲು ಸಾಧ್ಯ.
  • ಕಡಿಮೆಯಾಗುವ ಲಾಭಗಳು (Diminishing returns) – ಪ್ರತಿ ಹೆಚ್ಚುವರಿ ಕೋರ್ ಅಥವಾ ಗಿಗಾಬೈಟ್ ಹಿಂದಿನದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಆದರೆ ಅದರ ಕಾರ್ಯಕ್ಷಮತೆಯ ಲಾಭವು ಕಡಿಮೆಯಾಗುತ್ತಾ ಹೋಗುತ್ತದೆ.
  • ವೈಫಲ್ಯದ ಏಕೈಕ ಬಿಂದು (Single point of failure) – ಒಂದು ವೇಳೆ ಆ ದೊಡ್ಡ ಸರ್ವರ್ ಡೌನ್ ಆದರೆ, ಇಡೀ ಸೇವೆ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ.

ಈ ಮಿತಿಗಳಿಂದಾಗಿ, ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು, ಸರ್ಚ್ ಇಂಜಿನ್‌ಗಳು ಮತ್ತು ಇ-ಕಾಮರ್ಸ್ ಸೈಟ್‌ಗಳಂತಹ ಉದ್ಯಮದ ದೈತ್ಯರು ಒಂದೇ ದೊಡ್ಡ ಮಷೀನ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವುದನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿದ್ದಾರೆ.

ಪರ್ಯಾಯ ಮಾರ್ಗ: ಹೊರೆಯನ್ನು ಅನೇಕ ಸಣ್ಣ ಯಂತ್ರಗಳ ಮೇಲೆ ಹಂಚುವುದು

ಎತ್ತರದ ಗೋಪುರವನ್ನು ನಿರ್ಮಿಸುವ ಬದಲಿಗೆ, ಆಪರೇಟರ್‌ಗಳು ಸಾಧಾರಣ ಗಾತ್ರದ ಹೆಚ್ಚಿನ ಸರ್ವರ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಬಿಡುತ್ತಾರೆ. ಈ horizontal scaling ವಿಧಾನವು ಪ್ರತಿಯೊಂದು ಮಷೀನ್ ಅನ್ನು ಸುಗಮ ಕಾರ್ಯಕ್ಷಮತೆಯ ವ್ಯಾಪ್ತಿಯಲ್ಲಿಡುತ್ತದೆ ಮತ್ತು ವರ್ಟಿಕಲ್ ಅಪ್‌ಗ್ರೇಡ್‌ಗಳ ಅತಿಯಾದ ವೆಚ್ಚವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.

ಅನೇಕ ಮಷೀನ್‌ಗಳನ್ನು ಸಮನ್ವಯಗೊಳಿಸಲು load balancer ಬೇಕಾಗುತ್ತದೆ – ಇದು ಪ್ರತಿಯೊಂದು ಬರುವ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿ, ಅತಿ ಹೆಚ್ಚು ಲಭ್ಯವಿರುವ ಸಾಮರ್ಥ್ಯವಿರುವ ಸರ್ವರ್‌ಗೆ ವರ್ಗಾಯಿಸುವ ಸಾಫ್ಟ್‌ವೇರ್ ಅಥವಾ ಹಾರ್ಡ್‌ವೇರ್ ಆಗಿದೆ. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಸಂಕೀರ್ಣತೆಯನ್ನು ಕ್ಲೈಂಟ್‌ನಿಂದ ಮರೆಮಾಚುತ್ತದೆ; ಬಳಕೆದಾರರ ದೃಷ್ಟಿಕೋನದಲ್ಲಿ ಸೈಟ್ ಇನ್ನೂ ಒಂದೇ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನಂತೆ ಕಾಣುತ್ತದೆ.

ಹಾರಿಜಂಟಲ್ ಸ್ಕೇಲಿಂಗ್ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನೂ (resilience) ತರುತ್ತದೆ. ಒಂದು ನೋಡ್ (node) ಕ್ರ್ಯಾಶ್ ಆದರೆ, ಬ್ಯಾಲೆನ್ಸರ್ ಉಳಿದಿರುವ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ನೋಡ್‌ಗಳಿಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವರ್ಗಾಯಿಸುತ್ತದೆ, ಇದರಿಂದ ಸೇವೆ ನಿರಂತರವಾಗಿರುತ್ತದೆ.

ನೀವು ಹೆಚ್ಚಿನ ಮಷೀನ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು

  • Stateless design – ವಿನಂತಿಗಳು ಕೇವಲ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್‌ನ ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಡೇಟಾವನ್ನು ಅವಲಂಬಿಸಿರಬಾರದು; ಇಲ್ಲದಿದ್ದರೆ ಬಳಕೆದಾರರನ್ನು ಅಗತ್ಯ ಮಾಹಿತಿ ಇಲ್ಲದ ನೋಡ್‌ಗೆ ಕಳುಹಿಸುವ ಸಾಧ್ಯತೆ ಇರುತ್ತದೆ. ಶೇರ್ಡ್ ಕ್ಯಾಶೆಗಳು (shared caches) ಅಥವಾ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಬಳಸುವುದು ಇದಕ್ಕೆ ಪರಿಹಾರವಾಗಿದೆ.
  • Health checks – ಬ್ಯಾಲೆನ್ಸರ್ ವೈಫಲ್ಯ ಅನುಭವಿಸುತ್ತಿರುವ ಸರ್ವರ್ ಅನ್ನು ಬೇಗನೆ ಪತ್ತೆಹಚ್ಚಿ ಅದಕ್ಕೆ ಟ್ರಾಫಿಕ್ ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರಬೇಕು.
  • Auto-scaling policies – ಅನೇಕ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ನೀವು ಮಿತಿಗಳನ್ನು (CPU ಬಳಕೆ, ವಿನಂತಿ ವಿಳಂಬ) ವ್ಯಾಖ್ಯಾನಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತವೆ, ಇದು ಬೇಡಿಕೆಗೆ ಅನುಗುಣವಾಗಿ ಇನ್‌ಸ್ಟೆನ್ಸ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಲು ಅಥವಾ ನಿಲ್ಲಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಇದರಿಂದ ವೆಚ್ಚವು ನಿಯಂತ್ರಣದಲ್ಲಿರುತ್ತದೆ.

ವಿರೋಧಾತ್ಮಕ ಅಂಶ: ವರ್ಟಿಕಲ್ ಸ್ಕೇಲಿಂಗ್ ಅಳಿದು ಹೋಗಿಲ್ಲ

ಸಣ್ಣ ತಂಡಗಳಿಗೆ ಅಥವಾ ಕಡಿಮೆ ಟ್ರಾಫಿಕ್ ಇರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ, ಬಲವರ್ಧಿತ ಏಕೈಕ ಸರ್ವರ್ ಸರಳ ಮತ್ತು ಅಗ್ಗದ ಪರಿಹಾರವಾಗಬಹುದು. ಟ್ರಾಫಿಕ್ ಏರಿಕೆ ಮುನ್ಸೂಚನೆ ನೀಡಬಹುದಾದಾಗ (ಉದಾಹರಣೆಗೆ, ನಿಗದಿತ ಉತ್ಪನ್ನ ಬಿಡುಗಡೆ), ಹೊಸ ಇನ್‌ಸ್ಟೆನ್ಸ್‌ಗಳ ಸಮೂಹವನ್ನು ಸಿದ್ಧಪಡಿಸುವುದಕ್ಕಿಂತ ತಾತ್ಕಾಲಿಕ ವರ್ಟಿಕಲ್ ಅಪ್‌ಗ್ರೇಡ್ ಹೆಚ್ಚು ಪ್ರಾಯೋಗಿಕವಾಗಿರಬಹುದು.

ಪ್ರಮುಖ ವಿಷಯವೆಂದರೆ, "ದೊಡ್ಡ ಯಂತ್ರ" ಎಂಬ ತಂತ್ರವು ಯಾವಾಗ ಸಮಾನುಪಾತ ಮೌಲ್ಯವನ್ನು ನೀಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆಯೋ ಅದನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ವಿತರಣೆಯ (distribution) ಯೋಜನೆಗೆ ಸಿದ್ಧರಾಗಿ.

ಸಾರಾಂಶ (Takeaway)

ಲಾಂಚ್ ಆದ ನಂತರ ಸರ್ವರ್ ನಿಧಾನವಾಗುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಕೋಡ್ ದೋಷವಲ್ಲ, ಬದಲಾಗಿ ಇದು ಸಂಪನ್ಮೂಲಗಳ ಪೈಪೋಟಿ (resource-contention) ಸಮಸ್ಯೆಯಾಗಿದೆ. CPU ಸೈಕಲ್‌ಗಳು ಮತ್ತು RAM ಸ್ಲಾಟ್‌ಗಳು ಸೀಮಿತವಾಗಿವೆ, ಮತ್ತು ಅನೇಕ ವಿನಂತಿಗಳು (requests) ಒಟ್ಟಿಗೆ ಬಂದಾಗ ಅವು ಸಾಲಿನಲ್ಲಿ ನಿಲ್ಲುತ್ತವೆ, ಇದರಿಂದ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವು (response times) ಹೆಚ್ಚಾಗುತ್ತದೆ. ವರ್ಟಿಕಲ್ ಸ್ಕೇಲಿಂಗ್ (Vertical scaling) ನಿಮಗೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚಿನ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಇದು ಶೀಘ್ರದಲ್ಲೇ ಭೌತಿಕ ಮತ್ತು ಆರ್ಥಿಕ ಮಿತಿಗಳನ್ನು ತಲುಪುತ್ತದೆ. ಹಾರಿಜಂಟಲ್ ಸ್ಕೇಲಿಂಗ್ (Horizontal scaling)—ಅಂದರೆ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನ ಹಿಂದೆ ಹೆಚ್ಚಿನ ಸಾಧಾರಣ ಸರ್ವರ್‌ಗಳನ್ನು ಸೇರಿಸುವುದು—ಟ್ರಾಫಿಕ್ ಹೆಚ್ಚಾದಂತೆ ಕಡಿಮೆ ವೆಚ್ಚದ ಮತ್ತು ಹೆಚ್ಚು ದೃಢವಾದ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಸರತಿ ಸಾಲು ಉದ್ದವಾಗುತ್ತಿರುವುದನ್ನು ನೀವು ಗಮನಿಸಿದ ತಕ್ಷಣ, ಕೆಲವು ಹೆಚ್ಚಿನ ಕೋರ್‌ಗಳು (cores) ಸಾಕಾಗುತ್ತವೆಯೇ ಅಥವಾ ನೀವು ಲೋಡ್ ಅನ್ನು ಅನೇಕ ಯಂತ್ರಗಳ ನಡುವೆ ಹಂಚಲು ಪ್ರಾರಂಭಿಸಬೇಕೇ ಎಂದು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಸಮಯ ಬಂದಿದೆ ಎಂದರ್ಥ.

ಮೂಲ: dev.to ಲೇಖನ “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”