ಅನೇಕ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳು ಇದರ ಮೂಲಕ ಹೋಗಿವೆ: ಪ್ರತಿದಿನ ಹೊಸ ಬಳಕೆದಾರರ ಜನಸಂದಣಿ ನೋಂದಾಯಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ತಂಡವು ಸೇವೆಯನ್ನು ಚಾಲನೆಯಲ್ಲಿಡಲು ಹೆಣಗಾಡುತ್ತಿದೆ.

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

ಮಾಹಿತಿಯನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಮತ್ತು ಮೂಲ ಸೂತ್ರವನ್ನು ಬರೆಯಲು ಪ್ರಯತ್ನಿಸೋಣ. ನಾವು 1 ರಿಂದ 100 ಬಳಕೆದಾರರಿಗೆ ಹಂತ ಹಂತವಾಗಿ ನಮ್ಮ ಹೊಸ ಫೋಟೋ ಹಂಚಿಕೆ ಸೈಟ್ Graminsta ಅನ್ನು ಅಳೆಯಲಿದ್ದೇವೆ.

ಪ್ರೇಕ್ಷಕರು 10, 100, 1000, 10 ಮತ್ತು 000 ಜನರಿಗೆ ಹೆಚ್ಚಾದಾಗ ಯಾವ ನಿರ್ದಿಷ್ಟ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಎಂಬುದನ್ನು ಬರೆಯೋಣ.

1 ಬಳಕೆದಾರ: 1 ಯಂತ್ರ

ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್, ಅದು ವೆಬ್‌ಸೈಟ್ ಅಥವಾ ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿರಲಿ, ಮೂರು ಪ್ರಮುಖ ಅಂಶಗಳನ್ನು ಹೊಂದಿದೆ:

• ಎಪಿಐ
• ಡೇಟಾಬೇಸ್
• ಕ್ಲೈಂಟ್ (ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ ಅಥವಾ ವೆಬ್‌ಸೈಟ್)

ಡೇಟಾಬೇಸ್ ನಿರಂತರ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. API ಈ ಡೇಟಾಗೆ ಮತ್ತು ಅದರ ಸುತ್ತಲೂ ವಿನಂತಿಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಬಳಕೆದಾರರಿಗೆ ಡೇಟಾವನ್ನು ರವಾನಿಸುತ್ತದೆ.

ವಾಸ್ತುಶಿಲ್ಪದ ದೃಷ್ಟಿಕೋನದಿಂದ ಕ್ಲೈಂಟ್ ಮತ್ತು API ಘಟಕಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರ್ಪಡಿಸಿದರೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವ ಬಗ್ಗೆ ಮಾತನಾಡುವುದು ತುಂಬಾ ಸುಲಭ ಎಂದು ನಾನು ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇನೆ.

ನಾವು ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಎಲ್ಲಾ ಮೂರು ಘಟಕಗಳನ್ನು ಒಂದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಬಹುದು. ಕೆಲವು ರೀತಿಯಲ್ಲಿ, ಇದು ನಮ್ಮ ಅಭಿವೃದ್ಧಿ ಪರಿಸರಕ್ಕೆ ಹೋಲುತ್ತದೆ: ಒಬ್ಬ ಇಂಜಿನಿಯರ್ ಒಂದೇ ಗಣಕದಲ್ಲಿ ಡೇಟಾಬೇಸ್, API ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ.

ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಕೆಳಗೆ ತೋರಿಸಿರುವಂತೆ ನಾವು ಅದನ್ನು ಒಂದೇ ಡಿಜಿಟಲ್ ಓಷನ್ ಡ್ರಾಪ್ಲೆಟ್ ಅಥವಾ AWS EC2 ನಿದರ್ಶನದಲ್ಲಿ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಬಹುದು:

ಅದರೊಂದಿಗೆ, ಸೈಟ್‌ನಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಳಕೆದಾರರು ಇದ್ದರೆ, ಡೇಟಾಬೇಸ್ ಲೇಯರ್ ಅನ್ನು ಅರ್ಪಿಸಲು ಇದು ಯಾವಾಗಲೂ ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ.

10 ಬಳಕೆದಾರರು: ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಮಟ್ಟಕ್ಕೆ ಸರಿಸುವುದು

ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಮೆಜಾನ್ ಆರ್ಡಿಎಸ್ ಅಥವಾ ಡಿಜಿಟಲ್ ಓಷನ್ ಮ್ಯಾನೇಜ್ಡ್ ಡೇಟಾಬೇಸ್‌ನಂತಹ ನಿರ್ವಹಿಸಿದ ಸೇವೆಗಳಾಗಿ ವಿಭಜಿಸುವುದು ದೀರ್ಘಕಾಲದವರೆಗೆ ನಮಗೆ ಉತ್ತಮ ಸೇವೆಯನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಒಂದೇ ಯಂತ್ರ ಅಥವಾ EC2 ನಿದರ್ಶನದಲ್ಲಿ ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್‌ಗಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿದೆ, ಆದರೆ ಈ ಸೇವೆಗಳೊಂದಿಗೆ ನೀವು ಪೆಟ್ಟಿಗೆಯಿಂದ ಸಾಕಷ್ಟು ಉಪಯುಕ್ತ ವಿಸ್ತರಣೆಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ ಅದು ಭವಿಷ್ಯದಲ್ಲಿ ಸೂಕ್ತವಾಗಿ ಬರುತ್ತದೆ: ಬಹು-ಪ್ರದೇಶ ಬ್ಯಾಕಪ್, ಪ್ರತಿಕೃತಿಗಳನ್ನು ಓದಿ, ಸ್ವಯಂಚಾಲಿತ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು ಮತ್ತು ಇನ್ನಷ್ಟು.

ಈ ವ್ಯವಸ್ಥೆಯು ಈಗ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

100 ಬಳಕೆದಾರರು: ಕ್ಲೈಂಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಮಟ್ಟಕ್ಕೆ ಸರಿಸುವುದು

ಅದೃಷ್ಟವಶಾತ್, ನಮ್ಮ ಮೊದಲ ಬಳಕೆದಾರರು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಟ್ಟಿದ್ದಾರೆ. ಸಂಚಾರವು ಹೆಚ್ಚು ಸ್ಥಿರವಾಗುತ್ತಿದೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಮಟ್ಟಕ್ಕೆ ಸರಿಸಲು ಸಮಯವಾಗಿದೆ. ಎಂಬುದನ್ನು ಗಮನಿಸಬೇಕು ಪ್ರತ್ಯೇಕತೆ ಘಟಕಗಳು ಸ್ಕೇಲೆಬಲ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ. ಸಿಸ್ಟಂನ ಒಂದು ಭಾಗವು ಹೆಚ್ಚಿನ ದಟ್ಟಣೆಯನ್ನು ಪಡೆಯುವುದರಿಂದ, ನಿರ್ದಿಷ್ಟ ಟ್ರಾಫಿಕ್ ಮಾದರಿಗಳ ಆಧಾರದ ಮೇಲೆ ಸೇವಾ ಮಾಪಕಗಳನ್ನು ಹೇಗೆ ನಿಯಂತ್ರಿಸಲು ನಾವು ಅದನ್ನು ವಿಭಜಿಸಬಹುದು.

ಇದಕ್ಕಾಗಿಯೇ ನಾನು ಕ್ಲೈಂಟ್ ಅನ್ನು API ಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಯೋಚಿಸಲು ಇಷ್ಟಪಡುತ್ತೇನೆ. ವೆಬ್, ಮೊಬೈಲ್ ವೆಬ್, iOS, Android, ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, ಥರ್ಡ್-ಪಾರ್ಟಿ ಸೇವೆಗಳು, ಇತ್ಯಾದಿ: ಬಹು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಕುರಿತು ಯೋಚಿಸಲು ಇದು ತುಂಬಾ ಸುಲಭವಾಗುತ್ತದೆ. ಅವರೆಲ್ಲರೂ ಒಂದೇ API ಅನ್ನು ಬಳಸುವ ಗ್ರಾಹಕರು.

ಉದಾಹರಣೆಗೆ, ಈಗ ನಮ್ಮ ಬಳಕೆದಾರರು ಹೆಚ್ಚಾಗಿ ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಕೇಳುತ್ತಾರೆ. ನೀವು ಕ್ಲೈಂಟ್ ಮತ್ತು API ಘಟಕಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿದರೆ, ಇದು ಸುಲಭವಾಗುತ್ತದೆ.

ಅಂತಹ ವ್ಯವಸ್ಥೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

1000 ಬಳಕೆದಾರರು: ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಸೇರಿಸಿ

ವಿಷಯಗಳು ಹುಡುಕುತ್ತಿವೆ. ಗ್ರಾಮಿನ್‌ಸ್ಟಾ ಬಳಕೆದಾರರು ಹೆಚ್ಚು ಹೆಚ್ಚು ಫೋಟೋಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುತ್ತಿದ್ದಾರೆ. ನೋಂದಣಿ ಸಂಖ್ಯೆಯೂ ಹೆಚ್ಚುತ್ತಿದೆ. ನಮ್ಮ ಏಕಾಂಗಿ API ಸರ್ವರ್ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಕಷ್ಟಕರ ಸಮಯವನ್ನು ಹೊಂದಿದೆ. ಹೆಚ್ಚು ಕಬ್ಬಿಣದ ಅಗತ್ಯವಿದೆ!

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

ನಾವು ವೆಬ್ ಕ್ಲೈಂಟ್‌ನ ಮುಂದೆ ಮತ್ತು API ಮುಂದೆ ಪ್ರತ್ಯೇಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ಇರಿಸಲಿದ್ದೇವೆ. ಇದರರ್ಥ ನೀವು API ಕೋಡ್ ಮತ್ತು ವೆಬ್ ಕ್ಲೈಂಟ್ ಕೋಡ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಬಹು ನಿದರ್ಶನಗಳನ್ನು ರನ್ ಮಾಡಬಹುದು. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಕಡಿಮೆ ಲೋಡ್ ಆಗಿರುವ ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ನಿರ್ದೇಶಿಸುತ್ತದೆ.

ಇಲ್ಲಿ ನಾವು ಮತ್ತೊಂದು ಪ್ರಮುಖ ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯುತ್ತೇವೆ - ಪುನರಾವರ್ತನೆ. ಒಂದು ನಿದರ್ಶನ ವಿಫಲವಾದಾಗ (ಬಹುಶಃ ಓವರ್‌ಲೋಡ್ ಅಥವಾ ಕ್ರ್ಯಾಶ್ ಆಗಿರಬಹುದು), ಒಳಬರುವ ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ಮುಂದುವರಿಸುವ ಇತರರೊಂದಿಗೆ ನಾವು ಉಳಿದಿದ್ದೇವೆ. ಒಂದೇ ಒಂದು ನಿದರ್ಶನವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ.

ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಸ್ವಯಂಚಾಲಿತ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಸಹ ಒದಗಿಸುತ್ತದೆ. ಪೀಕ್ ಲೋಡ್‌ಗೆ ಮೊದಲು ನಿದರ್ಶನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಮತ್ತು ಎಲ್ಲಾ ಬಳಕೆದಾರರು ಮಲಗಿರುವಾಗ ಅದನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು ಇದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.

ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನೊಂದಿಗೆ, API ಮಟ್ಟವನ್ನು ಬಹುತೇಕ ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಅಳೆಯಬಹುದು, ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾದಂತೆ ಹೊಸ ನಿದರ್ಶನಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ.

ಸೂಚನೆ. ಇದೀಗ ನಮ್ಮ ಸಿಸ್ಟಂ AWS ನಲ್ಲಿ Heroku ಅಥವಾ Elastic Beanstalk ನಂತಹ PaaS ಕಂಪನಿಗಳು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ನೀಡುವುದನ್ನು ಹೋಲುತ್ತದೆ (ಅದಕ್ಕಾಗಿಯೇ ಅವು ತುಂಬಾ ಜನಪ್ರಿಯವಾಗಿವೆ). Heroku ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಇರಿಸುತ್ತದೆ, ಸ್ವಯಂ-ಸ್ಕೇಲಿಂಗ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು API ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ವೆಬ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಹೋಸ್ಟ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆರಂಭಿಕ ಹಂತದ ಯೋಜನೆಗಳು ಅಥವಾ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳಿಗಾಗಿ Heroku ಅನ್ನು ಬಳಸಲು ಇದು ಉತ್ತಮ ಕಾರಣವಾಗಿದೆ - ನೀವು ಎಲ್ಲಾ ಮೂಲಭೂತ ಸೇವೆಗಳನ್ನು ಬಾಕ್ಸ್‌ನಿಂದ ಪಡೆಯುತ್ತೀರಿ.

10 ಬಳಕೆದಾರರು: CDN

ಬಹುಶಃ ನಾವು ಇದನ್ನು ಮೊದಲಿನಿಂದಲೂ ಮಾಡಬೇಕಾಗಿತ್ತು. ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು ಮತ್ತು ಹೊಸ ಫೋಟೋಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದು ನಮ್ಮ ಸರ್ವರ್‌ಗಳ ಮೇಲೆ ಹೆಚ್ಚು ಒತ್ತಡವನ್ನು ಉಂಟುಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದೆ.

ಈ ಹಂತದಲ್ಲಿ, ಸ್ಥಿರ ವಿಷಯವನ್ನು ಸಂಗ್ರಹಿಸಲು ನೀವು ಕ್ಲೌಡ್ ಸೇವೆಯನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ - ಚಿತ್ರಗಳು, ವೀಡಿಯೊಗಳು ಮತ್ತು ಹೆಚ್ಚಿನವುಗಳು (AWS S3 ಅಥವಾ ಡಿಜಿಟಲ್ ಓಷನ್ ಸ್ಪೇಸ್‌ಗಳು). ಸಾಮಾನ್ಯವಾಗಿ, ನಮ್ಮ API ಚಿತ್ರಗಳನ್ನು ಸರ್ವ್ ಮಾಡುವುದು ಮತ್ತು ಸರ್ವರ್‌ಗೆ ಚಿತ್ರಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುವಂತಹ ವಿಷಯಗಳನ್ನು ನಿರ್ವಹಿಸುವುದನ್ನು ತಪ್ಪಿಸಬೇಕು.

ಕ್ಲೌಡ್ ಹೋಸ್ಟಿಂಗ್‌ನ ಮತ್ತೊಂದು ಪ್ರಯೋಜನವೆಂದರೆ CDN (AWS ಈ ಆಡ್-ಆನ್ ಕ್ಲೌಡ್‌ಫ್ರಂಟ್ ಎಂದು ಕರೆಯುತ್ತದೆ, ಆದರೆ ಅನೇಕ ಕ್ಲೌಡ್ ಸ್ಟೋರೇಜ್ ಪೂರೈಕೆದಾರರು ಇದನ್ನು ಬಾಕ್ಸ್‌ನಿಂದ ಹೊರಗೆ ನೀಡುತ್ತಾರೆ). CDN ಪ್ರಪಂಚದಾದ್ಯಂತದ ವಿವಿಧ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ನಮ್ಮ ಚಿತ್ರಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ.

ನಮ್ಮ ಮುಖ್ಯ ಡೇಟಾ ಕೇಂದ್ರವು ಓಹಿಯೋದಲ್ಲಿ ನೆಲೆಗೊಂಡಿದ್ದರೂ, ಯಾರಾದರೂ ಜಪಾನ್‌ನಿಂದ ಚಿತ್ರವನ್ನು ವಿನಂತಿಸಿದರೆ, ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರು ಅದನ್ನು ನಕಲು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅವರ ಜಪಾನೀಸ್ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತಾರೆ. ಜಪಾನ್‌ನಲ್ಲಿ ಈ ಚಿತ್ರವನ್ನು ವಿನಂತಿಸಿದ ಮುಂದಿನ ವ್ಯಕ್ತಿಯು ಅದನ್ನು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ನಾವು ಫೋಟೋಗಳು ಅಥವಾ ವೀಡಿಯೊಗಳಂತಹ ದೊಡ್ಡ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಇದು ಮುಖ್ಯವಾಗಿದೆ, ಅದು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಮತ್ತು ಗ್ರಹದಾದ್ಯಂತ ರವಾನಿಸಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

100 ಬಳಕೆದಾರರು: ಡೇಟಾ ಲೇಯರ್ ಅನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವುದು

CDN ಬಹಳಷ್ಟು ಸಹಾಯ ಮಾಡಿದೆ: ಸಂಚಾರ ಪೂರ್ಣ ವೇಗದಲ್ಲಿ ಬೆಳೆಯುತ್ತಿದೆ. ಪ್ರಸಿದ್ಧ ವೀಡಿಯೊ ಬ್ಲಾಗರ್ ಮಾವಿಡ್ ಮೊಬ್ರಿಕ್ ನಮ್ಮೊಂದಿಗೆ ನೋಂದಾಯಿಸಿಕೊಂಡಿದ್ದಾರೆ ಮತ್ತು ಅವರು ಹೇಳಿದಂತೆ ಅವರ "ಕಥೆ" ಅನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿದ್ದಾರೆ. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಧನ್ಯವಾದಗಳು, API ಸರ್ವರ್‌ಗಳಲ್ಲಿನ CPU ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಕಡಿಮೆ ಇರಿಸಲಾಗಿದೆ (ಹತ್ತು API ನಿದರ್ಶನಗಳು ಚಾಲನೆಯಲ್ಲಿವೆ), ಆದರೆ ನಾವು ವಿನಂತಿಗಳ ಮೇಲೆ ಸಾಕಷ್ಟು ಸಮಯ ಮೀರಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದೇವೆ... ಈ ವಿಳಂಬಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ?

ಮೆಟ್ರಿಕ್‌ಗಳಲ್ಲಿ ಸ್ವಲ್ಪ ಅಗೆಯುವುದು, ಡೇಟಾಬೇಸ್ ಸರ್ವರ್‌ನಲ್ಲಿನ ಸಿಪಿಯು 80-90% ಲೋಡ್ ಆಗಿರುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ನಾವು ಮಿತಿಯಲ್ಲಿದ್ದೇವೆ.

ಡೇಟಾ ಲೇಯರ್ ಅನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವುದು ಬಹುಶಃ ಸಮೀಕರಣದ ಅತ್ಯಂತ ಕಷ್ಟಕರವಾದ ಭಾಗವಾಗಿದೆ. API ಸರ್ವರ್‌ಗಳು ಸ್ಥಿತಿಯಿಲ್ಲದ ವಿನಂತಿಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ನಾವು ಹೆಚ್ಚು API ನಿದರ್ಶನಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ. ಮೂಗು ಬಹುಮತ ಡೇಟಾಬೇಸ್‌ಗಳು ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಾವು ಜನಪ್ರಿಯ ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ (PostgreSQL, MySQL, ಇತ್ಯಾದಿ.).

ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು

ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವೆಂದರೆ ಹೊಸ ಘಟಕವನ್ನು ಪರಿಚಯಿಸುವುದು: ಸಂಗ್ರಹ ಪದರ. ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ವಿಧಾನವೆಂದರೆ ಇನ್-ಮೆಮೊರಿ ಕೀ-ಮೌಲ್ಯದ ರೆಕಾರ್ಡ್ ಸ್ಟೋರ್, ಉದಾಹರಣೆಗೆ Redis ಅಥವಾ Memcached. ಹೆಚ್ಚಿನ ಮೋಡಗಳು ಈ ಸೇವೆಗಳ ನಿರ್ವಹಿಸಿದ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿವೆ: AWS ನಲ್ಲಿ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ ಮತ್ತು Google ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಮೆಮೊರಿಸ್ಟೋರ್.

ಒಂದು ಸೇವೆಯು ಅದೇ ಮಾಹಿತಿಯನ್ನು ಹಿಂಪಡೆಯಲು ಡೇಟಾಬೇಸ್‌ಗೆ ಪದೇ ಪದೇ ಕರೆಗಳನ್ನು ಮಾಡಿದಾಗ ಸಂಗ್ರಹವು ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ. ಮೂಲಭೂತವಾಗಿ, ನಾವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ಪ್ರವೇಶಿಸುತ್ತೇವೆ, ಸಂಗ್ರಹದಲ್ಲಿ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಮತ್ತೆ ಸ್ಪರ್ಶಿಸಬೇಡಿ.

ಉದಾಹರಣೆಗೆ, ನಮ್ಮ ಗ್ರಾಮಿನ್‌ಸ್ಟಾ ಸೇವೆಯಲ್ಲಿ, ಪ್ರತಿ ಬಾರಿ ಯಾರಾದರೂ ಸ್ಟಾರ್ ಮೊಬ್ರಿಕ್‌ನ ಪ್ರೊಫೈಲ್ ಪುಟಕ್ಕೆ ಹೋದಾಗ, API ಸರ್ವರ್ ಅವರ ಪ್ರೊಫೈಲ್‌ನಿಂದ ಮಾಹಿತಿಗಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರಶ್ನಿಸುತ್ತದೆ. ಇದು ಮತ್ತೆ ಮತ್ತೆ ಸಂಭವಿಸುತ್ತದೆ. Mobrik ನ ಪ್ರೊಫೈಲ್ ಮಾಹಿತಿಯು ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಬದಲಾಗುವುದಿಲ್ಲವಾದ್ದರಿಂದ, ಇದು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಲು ಅತ್ಯುತ್ತಮವಾಗಿದೆ.

ನಾವು ರೆಡಿಸ್‌ನಲ್ಲಿನ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಕೀ ಮೂಲಕ ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ user:id 30 ಸೆಕೆಂಡುಗಳ ಮಾನ್ಯತೆಯ ಅವಧಿಯೊಂದಿಗೆ. ಈಗ, ಯಾರಾದರೂ Mobrik ನ ಪ್ರೊಫೈಲ್‌ಗೆ ಹೋದಾಗ, ನಾವು ಮೊದಲು Redis ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು ಡೇಟಾ ಇದ್ದರೆ, ನಾವು ಅದನ್ನು ನೇರವಾಗಿ Redis ನಿಂದ ವರ್ಗಾಯಿಸುತ್ತೇವೆ. ಈಗ ಸೈಟ್‌ನಲ್ಲಿನ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಪ್ರೊಫೈಲ್‌ಗೆ ವಿನಂತಿಗಳು ಪ್ರಾಯೋಗಿಕವಾಗಿ ನಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುವುದಿಲ್ಲ.

ಹೆಚ್ಚಿನ ಕ್ಯಾಶಿಂಗ್ ಸೇವೆಗಳ ಮತ್ತೊಂದು ಪ್ರಯೋಜನವೆಂದರೆ ಅವುಗಳು ಡೇಟಾಬೇಸ್ ಸರ್ವರ್‌ಗಳಿಗಿಂತ ಅಳೆಯಲು ಸುಲಭವಾಗಿದೆ. ರೆಡಿಸ್ ಅಂತರ್ನಿರ್ಮಿತ ರೆಡಿಸ್ ಕ್ಲಸ್ಟರ್ ಮೋಡ್ ಅನ್ನು ಹೊಂದಿದೆ. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಹೋಲುತ್ತದೆ1, ಇದು ನಿಮ್ಮ ರೆಡಿಸ್ ಸಂಗ್ರಹವನ್ನು ಬಹು ಯಂತ್ರಗಳಲ್ಲಿ (ಅಗತ್ಯವಿದ್ದರೆ ಸಾವಿರಾರು ಸರ್ವರ್‌ಗಳಲ್ಲಿ) ವಿತರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಬಹುತೇಕ ಎಲ್ಲಾ ದೊಡ್ಡ-ಪ್ರಮಾಣದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆಯನ್ನು ಬಳಸುತ್ತವೆ; ಇದು ವೇಗದ API ಯ ಸಂಪೂರ್ಣ ಅವಿಭಾಜ್ಯ ಅಂಗವಾಗಿದೆ. ವೇಗವಾದ ಪ್ರಶ್ನೆ ಸಂಸ್ಕರಣೆ ಮತ್ತು ಹೆಚ್ಚು ಉತ್ಪಾದಕ ಕೋಡ್ ಎಲ್ಲವೂ ಮುಖ್ಯವಾಗಿದೆ, ಆದರೆ ಸಂಗ್ರಹವಿಲ್ಲದೆ ಲಕ್ಷಾಂತರ ಬಳಕೆದಾರರಿಗೆ ಸೇವೆಯನ್ನು ಅಳೆಯಲು ಅಸಾಧ್ಯವಾಗಿದೆ.

ಪ್ರತಿಕೃತಿಗಳನ್ನು ಓದಿ

ಡೇಟಾಬೇಸ್‌ಗೆ ಪ್ರಶ್ನೆಗಳ ಸಂಖ್ಯೆಯು ಹೆಚ್ಚು ಹೆಚ್ಚಾದಾಗ, ನಾವು ಮಾಡಬಹುದಾದ ಇನ್ನೊಂದು ವಿಷಯವೆಂದರೆ ಡೇಟಾಬೇಸ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಓದುವ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಸೇರಿಸುವುದು. ಮೇಲೆ ವಿವರಿಸಿದ ನಿರ್ವಹಿಸಿದ ಸೇವೆಗಳೊಂದಿಗೆ, ಇದನ್ನು ಒಂದೇ ಕ್ಲಿಕ್‌ನಲ್ಲಿ ಮಾಡಬಹುದು. ಓದುವ ಪ್ರತಿಕೃತಿಯು ಮುಖ್ಯ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಪ್ರಸ್ತುತವಾಗಿ ಉಳಿಯುತ್ತದೆ ಮತ್ತು SELECT ಹೇಳಿಕೆಗಳಿಗೆ ಲಭ್ಯವಿದೆ.

ಈಗ ನಮ್ಮ ವ್ಯವಸ್ಥೆ ಇಲ್ಲಿದೆ:

ಮುಂದಿನ ಕ್ರಮಗಳು

ಅಪ್ಲಿಕೇಶನ್ ಸ್ಕೇಲ್ ಆಗುತ್ತಿರುವಂತೆ, ನಾವು ಸೇವೆಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಅಳೆಯಲು ಪ್ರತ್ಯೇಕಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳ ಸಂಸ್ಕರಣಾ ಕೋಡ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಸೇವೆಗೆ ಎಳೆಯಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ನಾವು ಅದನ್ನು ನಮ್ಮ ಸ್ವಂತ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನ ಹಿಂದೆ ಹೊಸ ನಿದರ್ಶನಗಳಲ್ಲಿ ಇರಿಸಬಹುದು, ಇದು ತೆರೆದ ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳ ಸಂಪರ್ಕಗಳ ಆಧಾರದ ಮೇಲೆ ಮತ್ತು HTTP ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಲೆಕ್ಕಿಸದೆ ಮೇಲಕ್ಕೆ ಮತ್ತು ಕೆಳಕ್ಕೆ ಅಳೆಯಬಹುದು.

ನಾವು ಡೇಟಾಬೇಸ್ ಮಟ್ಟದಲ್ಲಿ ನಿರ್ಬಂಧಗಳ ವಿರುದ್ಧ ಹೋರಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. ಈ ಹಂತದಲ್ಲಿಯೇ ಡೇಟಾಬೇಸ್ ವಿಭಜನೆ ಮತ್ತು ಹಂಚಿಕೆಯನ್ನು ಅಧ್ಯಯನ ಮಾಡುವ ಸಮಯ. ಎರಡೂ ವಿಧಾನಗಳಿಗೆ ಹೆಚ್ಚುವರಿ ಓವರ್ಹೆಡ್ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಹುತೇಕ ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಅಳೆಯಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ನಾವು ನ್ಯೂ ರೆಲಿಕ್ ಅಥವಾ ಡೇಟಾಡಾಗ್‌ನಂತಹ ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಅನಾಲಿಟಿಕ್ಸ್ ಸೇವೆಯನ್ನು ಸ್ಥಾಪಿಸಲು ಬಯಸುತ್ತೇವೆ. ನಿಧಾನವಾದ ಪ್ರಶ್ನೆಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಎಲ್ಲಿ ಸುಧಾರಣೆ ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನಾವು ಸ್ಕೇಲ್ ಮಾಡುವಾಗ, ನಾವು ಅಡಚಣೆಗಳನ್ನು ಹುಡುಕಲು ಮತ್ತು ಅವುಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಕೇಂದ್ರೀಕರಿಸಲು ಬಯಸುತ್ತೇವೆ - ಆಗಾಗ್ಗೆ ಹಿಂದಿನ ವಿಭಾಗಗಳಿಂದ ಕೆಲವು ವಿಚಾರಗಳನ್ನು ಬಳಸುತ್ತೇವೆ.

ಮೂಲಗಳು

ಈ ಪೋಸ್ಟ್ ಒಂದರಿಂದ ಪ್ರೇರಿತವಾಗಿದೆ ಹೆಚ್ಚಿನ ಸ್ಕೇಲೆಬಿಲಿಟಿ ಬಗ್ಗೆ ನನ್ನ ಮೆಚ್ಚಿನ ಪೋಸ್ಟ್‌ಗಳು. ಪ್ರಾಜೆಕ್ಟ್‌ಗಳ ಆರಂಭಿಕ ಹಂತಗಳಿಗೆ ಲೇಖನವನ್ನು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿ ಮಾಡಲು ಮತ್ತು ಅದನ್ನು ಒಬ್ಬ ಮಾರಾಟಗಾರರಿಂದ ಬಿಚ್ಚಿಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ನೀವು ಈ ವಿಷಯದ ಬಗ್ಗೆ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ ಓದಲು ಮರೆಯದಿರಿ.

ಅಡಿಟಿಪ್ಪಣಿಗಳು

1. ಅನೇಕ ನಿದರ್ಶನಗಳಲ್ಲಿ ಲೋಡ್ ವಿತರಣೆಯ ವಿಷಯದಲ್ಲಿ ಒಂದೇ ಆಗಿದ್ದರೂ, ರೆಡಿಸ್ ಕ್ಲಸ್ಟರ್‌ನ ಆಧಾರವಾಗಿರುವ ಅನುಷ್ಠಾನವು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಿಂತ ತುಂಬಾ ಭಿನ್ನವಾಗಿದೆ. [ಹಿಂತಿರುಗಿ]

ಮೂಲ: www.habr.com