ಇಂಟರ್ನೆಟ್ ವಿನಂತಿಗಳನ್ನು ವೇಗಗೊಳಿಸಿ ಮತ್ತು ಶಾಂತಿಯುತವಾಗಿ ನಿದ್ರೆ ಮಾಡಿ

ನೆಟ್‌ಫ್ಲಿಕ್ಸ್ ಇಂಟರ್ನೆಟ್ ಟೆಲಿವಿಷನ್ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಮುಂಚೂಣಿಯಲ್ಲಿದೆ - ಈ ವಿಭಾಗವನ್ನು ರಚಿಸಿದ ಮತ್ತು ಸಕ್ರಿಯವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವ ಕಂಪನಿ. ನೆಟ್‌ಫ್ಲಿಕ್ಸ್ ಗ್ರಹದ ಪ್ರತಿಯೊಂದು ಮೂಲೆಯಿಂದ ಲಭ್ಯವಿರುವ ಚಲನಚಿತ್ರಗಳು ಮತ್ತು ಟಿವಿ ಸರಣಿಗಳ ವ್ಯಾಪಕ ಕ್ಯಾಟಲಾಗ್‌ಗೆ ಮತ್ತು ಪ್ರದರ್ಶನದೊಂದಿಗೆ ಯಾವುದೇ ಸಾಧನಕ್ಕೆ ಮಾತ್ರವಲ್ಲದೆ ಅದರ ವಿಶ್ವಾಸಾರ್ಹ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ವಿಶಿಷ್ಟ ಎಂಜಿನಿಯರಿಂಗ್ ಸಂಸ್ಕೃತಿಗೆ ಹೆಸರುವಾಸಿಯಾಗಿದೆ.

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

ವರದಿಯು ಸಮ್ಮೇಳನದಲ್ಲಿ ಭಾಗವಹಿಸುವವರಿಂದ ಉತ್ತಮ ವಿಮರ್ಶೆಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದೆ ಮತ್ತು ನಾವು ನಿಮಗಾಗಿ ಪಠ್ಯ ಆವೃತ್ತಿಯನ್ನು ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ.

ತನ್ನ ವರದಿಯಲ್ಲಿ, ಸೆರ್ಗೆಯ್ ವಿವರವಾಗಿ ಮಾತನಾಡಿದರು

• ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಇಂಟರ್ನೆಟ್ ವಿನಂತಿಗಳ ವಿಳಂಬದ ಮೇಲೆ ಏನು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು;
• ಈ ವಿಳಂಬವನ್ನು ಹೇಗೆ ಕಡಿಮೆ ಮಾಡುವುದು;
• ದೋಷ-ಸಹಿಷ್ಣು ವ್ಯವಸ್ಥೆಗಳನ್ನು ಹೇಗೆ ವಿನ್ಯಾಸಗೊಳಿಸುವುದು, ನಿರ್ವಹಿಸುವುದು ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು;
• ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ಸಾಧಿಸುವುದು ಹೇಗೆ, ಮತ್ತು ವ್ಯವಹಾರಕ್ಕೆ ಕನಿಷ್ಠ ಅಪಾಯದೊಂದಿಗೆ;
• ಫಲಿತಾಂಶಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವುದು ಮತ್ತು ತಪ್ಪುಗಳಿಂದ ಕಲಿಯುವುದು ಹೇಗೆ.

ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಗಳು ದೊಡ್ಡ ಸಂಸ್ಥೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವವರಿಗೆ ಮಾತ್ರವಲ್ಲ.

ಪ್ರಸ್ತುತಪಡಿಸಿದ ತತ್ವಗಳು ಮತ್ತು ತಂತ್ರಗಳನ್ನು ಇಂಟರ್ನೆಟ್ ಉತ್ಪನ್ನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮತ್ತು ಬೆಂಬಲಿಸುವ ಪ್ರತಿಯೊಬ್ಬರೂ ತಿಳಿದಿರಬೇಕು ಮತ್ತು ಅಭ್ಯಾಸ ಮಾಡಬೇಕು.

ಮುಂದಿನದು ಸ್ಪೀಕರ್ ದೃಷ್ಟಿಕೋನದಿಂದ ನಿರೂಪಣೆಯಾಗಿದೆ.

ಇಂಟರ್ನೆಟ್ ವೇಗದ ಪ್ರಾಮುಖ್ಯತೆ

ಇಂಟರ್ನೆಟ್ ವಿನಂತಿಗಳ ವೇಗವು ನೇರವಾಗಿ ವ್ಯವಹಾರಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ. ಶಾಪಿಂಗ್ ಉದ್ಯಮವನ್ನು ಪರಿಗಣಿಸಿ: 2009 ರಲ್ಲಿ ಅಮೆಜಾನ್ ಮಾತನಾಡಿದರು100ms ವಿಳಂಬವು ಮಾರಾಟದ 1% ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಮೊಬೈಲ್ ಸೈಟ್‌ಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಂತರ ಹೆಚ್ಚು ಹೆಚ್ಚು ಮೊಬೈಲ್ ಸಾಧನಗಳಿವೆ. ನಿಮ್ಮ ಪುಟವನ್ನು ಲೋಡ್ ಮಾಡಲು 3 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡರೆ, ನಿಮ್ಮ ಅರ್ಧದಷ್ಟು ಬಳಕೆದಾರರನ್ನು ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಜೊತೆಗೆ ಜುಲೈ 2018 ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳಲ್ಲಿ ನಿಮ್ಮ ಪುಟದ ಲೋಡಿಂಗ್ ವೇಗವನ್ನು Google ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: ಪುಟವು ವೇಗವಾಗಿರುತ್ತದೆ, Google ನಲ್ಲಿ ಅದರ ಸ್ಥಾನವು ಹೆಚ್ಚಾಗುತ್ತದೆ.

ಲೇಟೆನ್ಸಿ ನಿರ್ಣಾಯಕವಾಗಿರುವ ಹಣಕಾಸು ಸಂಸ್ಥೆಗಳಲ್ಲಿ ಸಂಪರ್ಕದ ವೇಗವೂ ಮುಖ್ಯವಾಗಿದೆ. 2015 ರಲ್ಲಿ, ಹೈಬರ್ನಿಯಾ ನೆಟ್ವರ್ಕ್ಸ್ ಮುಗಿದಿದೆ ನ್ಯೂಯಾರ್ಕ್ ಮತ್ತು ಲಂಡನ್ ನಡುವೆ $400 ಮಿಲಿಯನ್ ಕೇಬಲ್ ನಗರಗಳ ನಡುವಿನ ಸುಪ್ತತೆಯನ್ನು 6ms ರಷ್ಟು ಕಡಿಮೆ ಮಾಡಲು. 66 ಎಂಎಸ್ ಲೇಟೆನ್ಸಿ ಕಡಿತಕ್ಕೆ $1 ಮಿಲಿಯನ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ!

ಪ್ರಕಾರ ಸಂಶೋಧನೆ, 5 Mbit/s ಗಿಂತ ಹೆಚ್ಚಿನ ಸಂಪರ್ಕದ ವೇಗವು ಇನ್ನು ಮುಂದೆ ವಿಶಿಷ್ಟ ವೆಬ್‌ಸೈಟ್‌ನ ಲೋಡಿಂಗ್ ವೇಗವನ್ನು ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಸಂಪರ್ಕದ ಸುಪ್ತತೆ ಮತ್ತು ಪುಟ ಲೋಡಿಂಗ್ ವೇಗದ ನಡುವೆ ರೇಖಾತ್ಮಕ ಸಂಬಂಧವಿದೆ:

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

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

ನೆಟ್‌ಫ್ಲಿಕ್ಸ್ ಒಳಗೆ

ಸಾವಿರಾರು ವಿಭಿನ್ನ ಸಾಧನಗಳು ನೆಟ್‌ಫ್ಲಿಕ್ಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ. Android, iOS, TV ಮತ್ತು ವೆಬ್ ಬ್ರೌಸರ್‌ಗಳಿಗಾಗಿ ಕ್ಲೈಂಟ್‌ನ ಪ್ರತ್ಯೇಕ ಆವೃತ್ತಿಗಳನ್ನು ಮಾಡುವ ನಾಲ್ಕು ವಿಭಿನ್ನ ತಂಡಗಳಿಂದ ಅವುಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ. ಮತ್ತು ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ಸುಧಾರಿಸಲು ಮತ್ತು ವೈಯಕ್ತೀಕರಿಸಲು ನಾವು ಸಾಕಷ್ಟು ಪ್ರಯತ್ನಗಳನ್ನು ವ್ಯಯಿಸುತ್ತೇವೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ನೂರಾರು A/B ಪರೀಕ್ಷೆಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ನಡೆಸುತ್ತೇವೆ.

ವೈಯಕ್ತೀಕರಣವನ್ನು AWS ಕ್ಲೌಡ್‌ನಲ್ಲಿ ನೂರಾರು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳು ಬೆಂಬಲಿಸುತ್ತವೆ, ವೈಯಕ್ತಿಕಗೊಳಿಸಿದ ಬಳಕೆದಾರರ ಡೇಟಾ, ಪ್ರಶ್ನೆ ರವಾನೆ, ಟೆಲಿಮೆಟ್ರಿ, ಬಿಗ್ ಡೇಟಾ ಮತ್ತು ಎನ್‌ಕೋಡಿಂಗ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಸಂಚಾರ ದೃಶ್ಯೀಕರಣವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಪ್ರದರ್ಶನದೊಂದಿಗೆ ವೀಡಿಯೊಗೆ ಲಿಂಕ್ (6:04-6:23)

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

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

ಇಂಟರ್ನೆಟ್ ಟ್ರಾಫಿಕ್ ಎಕ್ಸ್ಚೇಂಜ್ ಪಾಯಿಂಟ್ (ಇಂಟರ್ನೆಟ್ ಎಕ್ಸ್ಚೇಂಜ್ - IX) ನಲ್ಲಿ ಈ ಸರ್ವರ್ಗಳ "ಗೋಡೆ" ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಇಂಟರ್ನೆಟ್ ಎಕ್ಸ್‌ಚೇಂಜ್ ಇಂಟರ್ನೆಟ್ ಸೇವಾ ಪೂರೈಕೆದಾರರು ಮತ್ತು ವಿಷಯ ಪೂರೈಕೆದಾರರಿಗೆ ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ನೇರವಾಗಿ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲು ಪರಸ್ಪರ "ಸಂಪರ್ಕ" ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಪ್ರಪಂಚದಾದ್ಯಂತ ಸರಿಸುಮಾರು 70-80 ಇಂಟರ್ನೆಟ್ ಎಕ್ಸ್‌ಚೇಂಜ್ ಪಾಯಿಂಟ್‌ಗಳಿವೆ, ಅಲ್ಲಿ ನಮ್ಮ ಸರ್ವರ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಸ್ಥಾಪಿಸುತ್ತೇವೆ ಮತ್ತು ನಿರ್ವಹಿಸುತ್ತೇವೆ:

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

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

ಬೈ ಸ್ಯಾಂಡ್‌ವೈನ್ ಅಂದಾಜು, ನಮ್ಮ CDN ಮೂಲಸೌಕರ್ಯವು ಪೀಕ್ ಸಮಯದಲ್ಲಿ ವಿಶ್ವದ ಇಂಟರ್ನೆಟ್ ಟ್ರಾಫಿಕ್‌ನ ಸರಿಸುಮಾರು ⅛ ಮತ್ತು ನೆಟ್‌ಫ್ಲಿಕ್ಸ್ ಅತಿ ಉದ್ದವಾದ ಉತ್ತರ ಅಮೆರಿಕಾದಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಪ್ರಭಾವಶಾಲಿ ಸಂಖ್ಯೆಗಳು, ಆದರೆ ನನಗೆ ಅತ್ಯಂತ ಅದ್ಭುತವಾದ ಸಾಧನೆಗಳೆಂದರೆ ಸಂಪೂರ್ಣ CDN ಸಿಸ್ಟಮ್ ಅನ್ನು 150 ಕ್ಕಿಂತ ಕಡಿಮೆ ಜನರ ತಂಡವು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ ಮತ್ತು ನಿರ್ವಹಿಸುತ್ತದೆ.

ಆರಂಭದಲ್ಲಿ, CDN ಮೂಲಸೌಕರ್ಯವನ್ನು ವೀಡಿಯೊ ಡೇಟಾವನ್ನು ತಲುಪಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿತ್ತು. ಆದಾಗ್ಯೂ, AWS ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಡೈನಾಮಿಕ್ ವಿನಂತಿಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ನಾವು ಇದನ್ನು ಬಳಸಬಹುದು ಎಂದು ಕಾಲಾನಂತರದಲ್ಲಿ ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ.

ಇಂಟರ್ನೆಟ್ ವೇಗವರ್ಧನೆಯ ಬಗ್ಗೆ

ಇಂದು, Netflix 3 AWS ಪ್ರದೇಶಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಕ್ಲೌಡ್‌ಗೆ ವಿನಂತಿಗಳ ಸುಪ್ತತೆಯು ಗ್ರಾಹಕರು ಹತ್ತಿರದ ಪ್ರದೇಶದಿಂದ ಎಷ್ಟು ದೂರದಲ್ಲಿರುತ್ತಾರೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಸ್ಥಿರ ವಿಷಯವನ್ನು ತಲುಪಿಸಲು ಬಳಸಲಾಗುವ ಅನೇಕ CDN ಸರ್ವರ್‌ಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಡೈನಾಮಿಕ್ ಪ್ರಶ್ನೆಗಳನ್ನು ವೇಗಗೊಳಿಸಲು ಈ ಚೌಕಟ್ಟನ್ನು ಬಳಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿದೆಯೇ? ಆದಾಗ್ಯೂ, ದುರದೃಷ್ಟವಶಾತ್, ಈ ವಿನಂತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಅಸಾಧ್ಯ - API ಗಳನ್ನು ವೈಯಕ್ತೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ಪ್ರತಿ ಫಲಿತಾಂಶವು ಅನನ್ಯವಾಗಿದೆ.

CDN ಸರ್ವರ್‌ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿಯನ್ನು ಮಾಡೋಣ ಮತ್ತು ಅದರ ಮೂಲಕ ಸಂಚಾರವನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸೋಣ. ಇದು ವೇಗವಾಗಿರುತ್ತದೆಯೇ?

ಮೆಟೀರಿಯಲ್

ನೆಟ್ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್ಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೆನಪಿಸೋಣ. ಇಂದು, ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ದಟ್ಟಣೆಯು HTTP ಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಇದು ಕೆಳಗಿನ ಪದರದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು TCP ಮತ್ತು TLS ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು, ಅದು ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸುರಕ್ಷಿತ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು, ಕ್ಲೈಂಟ್ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಮೂರು ಬಾರಿ ಸಂದೇಶಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು ಕನಿಷ್ಠ ಒಂದು ಬಾರಿ. ಪ್ರತಿ ರೌಂಡ್ ಟ್ರಿಪ್‌ಗೆ (RTT) 100 ms ನಷ್ಟು ಸುಪ್ತತೆಯೊಂದಿಗೆ, ಮೊದಲ ಬಿಟ್ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ನಮಗೆ 400 ms ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ:

ನಾವು CDN ಸರ್ವರ್‌ನಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಇರಿಸಿದರೆ, CDN ಹತ್ತಿರದಲ್ಲಿದ್ದರೆ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಮಯವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು. CDN ಸರ್ವರ್‌ಗೆ ಲೇಟೆನ್ಸಿ 30ms ಎಂದು ಊಹಿಸೋಣ. ನಂತರ ಮೊದಲ ಬಿಟ್ ಸ್ವೀಕರಿಸಲು 220 ms ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ:

ಆದರೆ ಅನುಕೂಲಗಳು ಅಲ್ಲಿಗೆ ಮುಗಿಯುವುದಿಲ್ಲ. ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಿದ ನಂತರ, TCP ದಟ್ಟಣೆ ವಿಂಡೋವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ (ಸಮಾನಾಂತರವಾಗಿ ಆ ಸಂಪರ್ಕದ ಮೂಲಕ ಅದು ರವಾನಿಸಬಹುದಾದ ಮಾಹಿತಿಯ ಪ್ರಮಾಣ). ಡೇಟಾ ಪ್ಯಾಕೆಟ್ ಕಳೆದುಹೋದರೆ, TCP ಪ್ರೋಟೋಕಾಲ್‌ನ ಕ್ಲಾಸಿಕ್ ಅಳವಡಿಕೆಗಳು (ಟಿಸಿಪಿ ನ್ಯೂ ರೆನೋ ನಂತಹ) ತೆರೆದ "ವಿಂಡೋ" ಅನ್ನು ಅರ್ಧದಷ್ಟು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ದಟ್ಟಣೆಯ ವಿಂಡೋದ ಬೆಳವಣಿಗೆ ಮತ್ತು ನಷ್ಟದಿಂದ ಅದರ ಚೇತರಿಕೆಯ ವೇಗವು ಸರ್ವರ್‌ಗೆ ವಿಳಂಬ (RTT) ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಈ ಸಂಪರ್ಕವು CDN ಸರ್ವರ್‌ನವರೆಗೆ ಮಾತ್ರ ಹೋದರೆ, ಈ ಚೇತರಿಕೆಯು ವೇಗವಾಗಿರುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಪ್ಯಾಕೆಟ್ ನಷ್ಟವು ಪ್ರಮಾಣಿತ ವಿದ್ಯಮಾನವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ವೈರ್ಲೆಸ್ ನೆಟ್ವರ್ಕ್ಗಳಿಗೆ.

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

ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು (OSI ಮಟ್ಟ 7) ಸಹ ಸುಪ್ತತೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುತ್ತವೆ. HTTP/2 ನಂತಹ ಹೊಸ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಸಮಾನಾಂತರ ವಿನಂತಿಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತವೆ. ಆದಾಗ್ಯೂ, ಹೊಸ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸದ ಹಳೆಯ ಸಾಧನಗಳೊಂದಿಗೆ ನಾವು Netflix ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ನವೀಕರಿಸಲಾಗುವುದಿಲ್ಲ ಅಥವಾ ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಅದೇ ಸಮಯದಲ್ಲಿ, CDN ಪ್ರಾಕ್ಸಿ ಮತ್ತು ಕ್ಲೌಡ್ ನಡುವೆ ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಣ ಮತ್ತು ಹೊಸ, ಸೂಕ್ತ ಪ್ರೋಟೋಕಾಲ್ಗಳು ಮತ್ತು ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯವಿದೆ. ಹಳೆಯ ಪ್ರೋಟೋಕಾಲ್‌ಗಳೊಂದಿಗಿನ ನಿಷ್ಪರಿಣಾಮಕಾರಿ ಭಾಗವು ಕ್ಲೈಂಟ್ ಮತ್ತು CDN ಸರ್ವರ್ ನಡುವೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದಲ್ಲದೆ, ನಾವು CDN ಮತ್ತು ಕ್ಲೌಡ್ ನಡುವೆ ಈಗಾಗಲೇ ಸ್ಥಾಪಿಸಲಾದ ಸಂಪರ್ಕದಲ್ಲಿ ಮಲ್ಟಿಪ್ಲೆಕ್ಸ್ ವಿನಂತಿಗಳನ್ನು ಮಾಡಬಹುದು, TCP ಮಟ್ಟದಲ್ಲಿ ಸಂಪರ್ಕ ಬಳಕೆಯನ್ನು ಸುಧಾರಿಸಬಹುದು:

ನಾವು ಅಳೆಯುತ್ತೇವೆ

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

• ವೇಗ: ಪ್ರಾಕ್ಸಿ ವೇಗವಾಗಿರುತ್ತದೆಯೇ?
• ವಿಶ್ವಾಸಾರ್ಹತೆ: ಇದು ಹೆಚ್ಚಾಗಿ ಒಡೆಯುತ್ತದೆಯೇ?
• ಸಂಕೀರ್ಣತೆ: ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಹೇಗೆ ಸಂಯೋಜಿಸುವುದು?
• ವೆಚ್ಚ: ಹೆಚ್ಚುವರಿ ಮೂಲಸೌಕರ್ಯಗಳನ್ನು ನಿಯೋಜಿಸಲು ಎಷ್ಟು ವೆಚ್ಚವಾಗುತ್ತದೆ?

ಮೊದಲ ಹಂತವನ್ನು ನಿರ್ಣಯಿಸಲು ನಮ್ಮ ವಿಧಾನವನ್ನು ವಿವರವಾಗಿ ಪರಿಗಣಿಸೋಣ. ಉಳಿದವುಗಳನ್ನು ಇದೇ ರೀತಿಯಲ್ಲಿ ವ್ಯವಹರಿಸಲಾಗುತ್ತದೆ.

ವಿನಂತಿಗಳ ವೇಗವನ್ನು ವಿಶ್ಲೇಷಿಸಲು, ನಾವು ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ಡೇಟಾವನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತೇವೆ, ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ವ್ಯಯಿಸದೆ ಮತ್ತು ಉತ್ಪಾದನೆಯನ್ನು ಮುರಿಯದೆ. ಇದಕ್ಕಾಗಿ ಹಲವಾರು ವಿಧಾನಗಳಿವೆ:

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

ಎರಡೂ ವಿಧಾನಗಳ ಅನುಕೂಲಗಳನ್ನು ನೀವು ಹೇಗೆ ಸಂಯೋಜಿಸಬಹುದು?

ನಮ್ಮ ತಂಡವು ಪರಿಹಾರವನ್ನು ಕಂಡುಕೊಂಡಿದೆ. ನಾವು ಒಂದು ಸಣ್ಣ ಕೋಡ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ - ಮಾದರಿ - ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ನಾವು ನಿರ್ಮಿಸಿದ್ದೇವೆ. ನಮ್ಮ ಸಾಧನಗಳಿಂದ ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಿತ ನೆಟ್‌ವರ್ಕ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಮಾಡಲು ಪ್ರೋಬ್‌ಗಳು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ. ಇದು ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:

1. ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಿದ ನಂತರ ಮತ್ತು ಆರಂಭಿಕ ಚಟುವಟಿಕೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ ನಂತರ, ನಾವು ನಮ್ಮ ಶೋಧಕಗಳನ್ನು ರನ್ ಮಾಡುತ್ತೇವೆ.
2. ಕ್ಲೈಂಟ್ ಸರ್ವರ್ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಪರೀಕ್ಷೆಗಾಗಿ "ಪಾಕವಿಧಾನ" ವನ್ನು ಪಡೆಯುತ್ತದೆ. ಪಾಕವಿಧಾನವು HTTP(ಗಳು) ವಿನಂತಿಯನ್ನು ಮಾಡಬೇಕಾದ URL ಗಳ ಪಟ್ಟಿಯಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪಾಕವಿಧಾನ ವಿನಂತಿಯ ನಿಯತಾಂಕಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ: ವಿನಂತಿಗಳ ನಡುವಿನ ವಿಳಂಬಗಳು, ವಿನಂತಿಸಿದ ಡೇಟಾದ ಪ್ರಮಾಣ, HTTP(ಗಳು) ಹೆಡರ್‌ಗಳು, ಇತ್ಯಾದಿ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಹಲವಾರು ವಿಭಿನ್ನ ಪಾಕವಿಧಾನಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಪರೀಕ್ಷಿಸಬಹುದು - ಸಂರಚನೆಯನ್ನು ವಿನಂತಿಸುವಾಗ, ಯಾವ ಪಾಕವಿಧಾನವನ್ನು ನೀಡಬೇಕೆಂದು ನಾವು ಯಾದೃಚ್ಛಿಕವಾಗಿ ನಿರ್ಧರಿಸುತ್ತೇವೆ.
3. ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಸಂಪನ್ಮೂಲಗಳ ಸಕ್ರಿಯ ಬಳಕೆಯೊಂದಿಗೆ ಸಂಘರ್ಷವಾಗದಂತೆ ಪ್ರೋಬ್ ಲಾಂಚ್ ಸಮಯವನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ. ಮೂಲಭೂತವಾಗಿ, ಕ್ಲೈಂಟ್ ಸಕ್ರಿಯವಾಗಿಲ್ಲದಿದ್ದಾಗ ಸಮಯವನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ.
4. ಪಾಕವಿಧಾನವನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಕ್ಲೈಂಟ್ ಪ್ರತಿಯೊಂದು URL ಗಳಿಗೆ ಸಮಾನಾಂತರವಾಗಿ ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ವಿಳಾಸಗಳಿಗೆ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸಬಹುದು - ಕರೆಯಲ್ಪಡುವ. "ದ್ವಿದಳ ಧಾನ್ಯಗಳು". ಮೊದಲ ನಾಡಿಯಲ್ಲಿ, ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಮತ್ತು ಡೇಟಾವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು ಎಂಬುದನ್ನು ನಾವು ಅಳೆಯುತ್ತೇವೆ. ಎರಡನೇ ನಾಡಿಯಲ್ಲಿ, ಈಗಾಗಲೇ ಸ್ಥಾಪಿಸಲಾದ ಸಂಪರ್ಕದ ಮೂಲಕ ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯವನ್ನು ನಾವು ಅಳೆಯುತ್ತೇವೆ. ಮೂರನೆಯದಕ್ಕೆ ಮೊದಲು, ನಾವು ವಿಳಂಬವನ್ನು ಹೊಂದಿಸಬಹುದು ಮತ್ತು ಮರುಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವ ವೇಗವನ್ನು ಅಳೆಯಬಹುದು, ಇತ್ಯಾದಿ.

   ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ಸಾಧನವು ಪಡೆಯಬಹುದಾದ ಎಲ್ಲಾ ನಿಯತಾಂಕಗಳನ್ನು ನಾವು ಅಳೆಯುತ್ತೇವೆ:

   • DNS ವಿನಂತಿ ಸಮಯ;
   • TCP ಸಂಪರ್ಕ ಸೆಟಪ್ ಸಮಯ;
   • TLS ಸಂಪರ್ಕ ಸೆಟಪ್ ಸಮಯ;
   • ಡೇಟಾದ ಮೊದಲ ಬೈಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವ ಸಮಯ;
   • ಒಟ್ಟು ಲೋಡ್ ಸಮಯ;
   • ಸ್ಥಿತಿ ಫಲಿತಾಂಶ ಕೋಡ್.
5. ಎಲ್ಲಾ ಕಾಳುಗಳು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಮಾದರಿಯು ವಿಶ್ಲೇಷಣೆಗಾಗಿ ಎಲ್ಲಾ ಅಳತೆಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ.

ಕ್ಲೈಂಟ್‌ನಲ್ಲಿನ ತರ್ಕದ ಮೇಲೆ ಕನಿಷ್ಠ ಅವಲಂಬನೆ, ಸರ್ವರ್‌ನಲ್ಲಿ ಡೇಟಾ ಸಂಸ್ಕರಣೆ ಮತ್ತು ಸಮಾನಾಂತರ ವಿನಂತಿಗಳ ಮಾಪನ ಪ್ರಮುಖ ಅಂಶಗಳು. ಹೀಗಾಗಿ, ನಾವು ಪ್ರಶ್ನೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ವಿವಿಧ ಅಂಶಗಳ ಪ್ರಭಾವವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಮತ್ತು ಪರೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಅವುಗಳನ್ನು ಒಂದೇ ಪಾಕವಿಧಾನದಲ್ಲಿ ಬದಲಾಯಿಸಬಹುದು ಮತ್ತು ನೈಜ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯಬಹುದು.

ಈ ಮೂಲಸೌಕರ್ಯವು ಕೇವಲ ಪ್ರಶ್ನೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿಶ್ಲೇಷಣೆಗಿಂತ ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ಸಾಬೀತಾಗಿದೆ. ಪ್ರಸ್ತುತ ನಾವು 14 ಸಕ್ರಿಯ ಪಾಕವಿಧಾನಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 6000 ಕ್ಕೂ ಹೆಚ್ಚು ಮಾದರಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಭೂಮಿಯ ಎಲ್ಲಾ ಮೂಲೆಗಳಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಸಾಧನದ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನೆಟ್‌ಫ್ಲಿಕ್ಸ್ ಮೂರನೇ ವ್ಯಕ್ತಿಯಿಂದ ಇದೇ ರೀತಿಯ ಸೇವೆಯನ್ನು ಖರೀದಿಸಿದರೆ, ಅದು ವರ್ಷಕ್ಕೆ ಮಿಲಿಯನ್‌ಗಟ್ಟಲೆ ಡಾಲರ್‌ಗಳಷ್ಟು ವೆಚ್ಚವಾಗುತ್ತದೆ, ಹೆಚ್ಚು ಕೆಟ್ಟ ವ್ಯಾಪ್ತಿಯೊಂದಿಗೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಪರೀಕ್ಷಾ ಸಿದ್ಧಾಂತ: ಮೂಲಮಾದರಿ

ಇಂತಹ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ, ನಾವು ವಿನಂತಿಯ ಸುಪ್ತತೆಯ ಮೇಲೆ CDN ಪ್ರಾಕ್ಸಿಗಳ ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು. ಈಗ ನಿಮಗೆ ಅಗತ್ಯವಿದೆ:

• ಪ್ರಾಕ್ಸಿ ಮೂಲಮಾದರಿಯನ್ನು ರಚಿಸಿ;
• CDN ನಲ್ಲಿ ಮೂಲಮಾದರಿಯನ್ನು ಇರಿಸಿ;
• ನಿರ್ದಿಷ್ಟ CDN ಸರ್ವರ್‌ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿಗೆ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಹೇಗೆ ನಿರ್ದೇಶಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ;
• ಪ್ರಾಕ್ಸಿ ಇಲ್ಲದೆ AWS ನಲ್ಲಿನ ವಿನಂತಿಗಳಿಗೆ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ.

ಉದ್ದೇಶಿತ ಪರಿಹಾರದ ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಕಾರ್ಯವಾಗಿದೆ. ಉತ್ತಮ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಲೈಬ್ರರಿಗಳ ಲಭ್ಯತೆಯಿಂದಾಗಿ ನಾವು ಮೂಲಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು Go ಅನ್ನು ಆರಿಸಿದ್ದೇವೆ. ಪ್ರತಿ CDN ಸರ್ವರ್‌ನಲ್ಲಿ, ಅವಲಂಬನೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ಏಕೀಕರಣವನ್ನು ಸರಳಗೊಳಿಸಲು ನಾವು ಪ್ರೋಟೋಟೈಪ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಸ್ಥಿರ ಬೈನರಿಯಾಗಿ ಸ್ಥಾಪಿಸಿದ್ದೇವೆ. ಆರಂಭಿಕ ಅನುಷ್ಠಾನದಲ್ಲಿ, ನಾವು ಸಾಧ್ಯವಾದಷ್ಟು ಪ್ರಮಾಣಿತ ಘಟಕಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ ಮತ್ತು HTTP/2 ಸಂಪರ್ಕ ಪೂಲಿಂಗ್ ಮತ್ತು ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ವಿನಂತಿಗಾಗಿ ಸಣ್ಣ ಮಾರ್ಪಾಡುಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ.

AWS ಪ್ರದೇಶಗಳ ನಡುವೆ ಸಮತೋಲನ ಮಾಡಲು, ನಾವು ಭೌಗೋಳಿಕ DNS ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ, ಅದೇ ಗ್ರಾಹಕರನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ಗಾಗಿ CDN ಸರ್ವರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು, ಇಂಟರ್ನೆಟ್ ಎಕ್ಸ್‌ಚೇಂಜ್ (IX) ನಲ್ಲಿ ಸರ್ವರ್‌ಗಳಿಗಾಗಿ ನಾವು TCP Anycast ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಈ ಆಯ್ಕೆಯಲ್ಲಿ, ನಾವು ಎಲ್ಲಾ CDN ಸರ್ವರ್‌ಗಳಿಗೆ ಒಂದು IP ವಿಳಾಸವನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ IP ಹಾಪ್‌ಗಳೊಂದಿಗೆ CDN ಸರ್ವರ್‌ಗೆ ನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ. ಇಂಟರ್ನೆಟ್ ಪೂರೈಕೆದಾರರು (ISP ಗಳು) ಸ್ಥಾಪಿಸಿದ CDN ಸರ್ವರ್‌ಗಳಲ್ಲಿ, TCP Anycast ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ನಾವು ರೂಟರ್‌ನ ಮೇಲೆ ನಿಯಂತ್ರಣವನ್ನು ಹೊಂದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ಬಳಸುತ್ತೇವೆ ಅದೇ ತರ್ಕ, ಇದು ವೀಡಿಯೊ ಸ್ಟ್ರೀಮಿಂಗ್‌ಗಾಗಿ ಇಂಟರ್ನೆಟ್ ಪೂರೈಕೆದಾರರಿಗೆ ಗ್ರಾಹಕರನ್ನು ನಿರ್ದೇಶಿಸುತ್ತದೆ.

ಆದ್ದರಿಂದ, ನಾವು ಮೂರು ರೀತಿಯ ವಿನಂತಿ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ: ಮುಕ್ತ ಇಂಟರ್ನೆಟ್ ಮೂಲಕ ಕ್ಲೌಡ್‌ಗೆ, IX ನಲ್ಲಿನ CDN ಸರ್ವರ್ ಮೂಲಕ ಅಥವಾ ಇಂಟರ್ನೆಟ್ ಪೂರೈಕೆದಾರರಲ್ಲಿರುವ CDN ಸರ್ವರ್ ಮೂಲಕ. ಉತ್ಪಾದನೆಗೆ ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಯಾವ ಮಾರ್ಗವು ಉತ್ತಮವಾಗಿದೆ ಮತ್ತು ಪ್ರಾಕ್ಸಿಯ ಪ್ರಯೋಜನವೇನು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ನಮ್ಮ ಗುರಿಯಾಗಿದೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಈ ಕೆಳಗಿನಂತೆ ಮಾದರಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುತ್ತೇವೆ:

ಪ್ರತಿಯೊಂದು ಮಾರ್ಗಗಳು ಪ್ರತ್ಯೇಕ ಗುರಿಯಾಗುತ್ತವೆ, ಮತ್ತು ನಾವು ಪಡೆದ ಸಮಯವನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ವಿಶ್ಲೇಷಣೆಗಾಗಿ, ನಾವು ಪ್ರಾಕ್ಸಿ ಫಲಿತಾಂಶಗಳನ್ನು ಒಂದು ಗುಂಪಿನಲ್ಲಿ ಸಂಯೋಜಿಸುತ್ತೇವೆ (IX ಮತ್ತು ISP ಪ್ರಾಕ್ಸಿಗಳ ನಡುವಿನ ಉತ್ತಮ ಸಮಯವನ್ನು ಆಯ್ಕೆಮಾಡಿ), ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಇಲ್ಲದೆ ಕ್ಲೌಡ್‌ಗೆ ವಿನಂತಿಗಳ ಸಮಯದೊಂದಿಗೆ ಅವುಗಳನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ:

ನೀವು ನೋಡುವಂತೆ, ಫಲಿತಾಂಶಗಳು ಮಿಶ್ರವಾಗಿವೆ - ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಉತ್ತಮ ವೇಗವನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಪರಿಸ್ಥಿತಿಯು ಗಮನಾರ್ಹವಾಗಿ ಹದಗೆಡುವ ಸಾಕಷ್ಟು ಸಂಖ್ಯೆಯ ಗ್ರಾಹಕರು ಸಹ ಇದ್ದಾರೆ.

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಹಲವಾರು ಪ್ರಮುಖ ಕೆಲಸಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ:

1. CDN ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಕ್ಲೌಡ್‌ಗೆ ವಿನಂತಿಗಳ ನಿರೀಕ್ಷಿತ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನಾವು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದ್ದೇವೆ.
2. ನಾವು ಎಲ್ಲಾ ರೀತಿಯ ಸಾಧನಗಳಿಂದ ನೈಜ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.
3. ಸಿದ್ಧಾಂತವು 100% ದೃಢೀಕರಿಸಲ್ಪಟ್ಟಿಲ್ಲ ಮತ್ತು CDN ಪ್ರಾಕ್ಸಿಯೊಂದಿಗಿನ ಆರಂಭಿಕ ಪ್ರಸ್ತಾಪವು ನಮಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ.
4. ನಾವು ಅಪಾಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಿಲ್ಲ - ನಾವು ಗ್ರಾಹಕರಿಗೆ ಉತ್ಪಾದನಾ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲಿಲ್ಲ.
5. ಏನೂ ಮುರಿಯಲಿಲ್ಲ.

ಮೂಲಮಾದರಿ 2.0

ಆದ್ದರಿಂದ, ಡ್ರಾಯಿಂಗ್ ಬೋರ್ಡ್‌ಗೆ ಹಿಂತಿರುಗಿ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮತ್ತೆ ಪುನರಾವರ್ತಿಸಿ.

100% ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸುವ ಬದಲು, ನಾವು ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ವೇಗವಾದ ಮಾರ್ಗವನ್ನು ನಿರ್ಧರಿಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಅಲ್ಲಿ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತೇವೆ - ಅಂದರೆ, ಕ್ಲೈಂಟ್ ಸ್ಟೀರಿಂಗ್ ಎಂದು ಕರೆಯಲ್ಪಡುವದನ್ನು ನಾವು ಮಾಡುತ್ತೇವೆ.

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

ಉತ್ತರವು DNS ಅನ್ನು ಬಳಸುವುದು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ನಮ್ಮದೇ ಆದ DNS ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ಸರ್ವರ್‌ಗಳು ಸರ್ವಾಧಿಕಾರಿಯಾಗಿರುವ ಡೊಮೇನ್ ವಲಯವನ್ನು ನಾವು ಹೊಂದಿಸಬಹುದು. ಇದು ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:

1. ಕ್ಲೈಂಟ್ ಹೋಸ್ಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು DNS ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ, ಉದಾಹರಣೆಗೆ api.netflix.xom.
2. ವಿನಂತಿಯು ನಮ್ಮ DNS ಸರ್ವರ್‌ಗೆ ಆಗಮಿಸುತ್ತದೆ
3. ಈ ಕ್ಲೈಂಟ್‌ಗೆ ಯಾವ ಮಾರ್ಗವು ವೇಗವಾಗಿದೆ ಎಂದು DNS ಸರ್ವರ್‌ಗೆ ತಿಳಿದಿದೆ ಮತ್ತು ಅನುಗುಣವಾದ IP ವಿಳಾಸವನ್ನು ನೀಡುತ್ತದೆ.

ಪರಿಹಾರವು ಹೆಚ್ಚುವರಿ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೊಂದಿದೆ: ಸರ್ವಾಧಿಕಾರಿ DNS ಪೂರೈಕೆದಾರರು ಕ್ಲೈಂಟ್‌ನ IP ವಿಳಾಸವನ್ನು ನೋಡುವುದಿಲ್ಲ ಮತ್ತು ಕ್ಲೈಂಟ್ ಬಳಸುವ ಪುನರಾವರ್ತಿತ ಪರಿಹಾರಕದ IP ವಿಳಾಸವನ್ನು ಮಾತ್ರ ಓದಬಹುದು.

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

ಪರಿಹರಿಸಲು, ನಾವು ಅದೇ ಮಾದರಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ, ಪ್ರತಿ ಪುನರಾವರ್ತಿತ ಪರಿಹಾರಕಗಳಿಗೆ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಮಾಪನ ಫಲಿತಾಂಶಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಿ ಮತ್ತು ಈ ಗುಂಪನ್ನು ಎಲ್ಲಿಗೆ ಕಳುಹಿಸಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತೇವೆ - TCP Anycast ಬಳಸಿಕೊಂಡು IX ಮೂಲಕ ಪ್ರಾಕ್ಸಿ, ISP ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಅಥವಾ ನೇರವಾಗಿ ಕ್ಲೌಡ್‌ಗೆ.

ನಾವು ಈ ಕೆಳಗಿನ ವ್ಯವಸ್ಥೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ:

ಪರಿಣಾಮವಾಗಿ ಡಿಎನ್ಎಸ್ ಸ್ಟೀರಿಂಗ್ ಮಾದರಿಯು ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಕ್ಲೌಡ್‌ಗೆ ಸಂಪರ್ಕಗಳ ವೇಗದ ಐತಿಹಾಸಿಕ ಅವಲೋಕನಗಳ ಆಧಾರದ ಮೇಲೆ ಗ್ರಾಹಕರನ್ನು ನಿರ್ದೇಶಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಮತ್ತೊಮ್ಮೆ, ಪ್ರಶ್ನೆಯು ಈ ವಿಧಾನವು ಎಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ? ಉತ್ತರಿಸಲು, ನಾವು ಮತ್ತೆ ನಮ್ಮ ತನಿಖೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ, ನಾವು ಪ್ರೆಸೆಂಟರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ, ಅಲ್ಲಿ ಗುರಿಗಳಲ್ಲಿ ಒಂದು DNS ಸ್ಟೀರಿಂಗ್‌ನಿಂದ ದಿಕ್ಕನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಇನ್ನೊಂದು ನೇರವಾಗಿ ಕ್ಲೌಡ್‌ಗೆ ಹೋಗುತ್ತದೆ (ಪ್ರಸ್ತುತ ಉತ್ಪಾದನೆ).

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಫಲಿತಾಂಶಗಳನ್ನು ಹೋಲಿಸುತ್ತೇವೆ ಮತ್ತು ಪರಿಣಾಮಕಾರಿತ್ವದ ಮೌಲ್ಯಮಾಪನವನ್ನು ಪಡೆಯುತ್ತೇವೆ:

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಹಲವಾರು ಪ್ರಮುಖ ವಿಷಯಗಳನ್ನು ಕಲಿತಿದ್ದೇವೆ:

1. DNS ಸ್ಟೀರಿಂಗ್ ಬಳಸಿಕೊಂಡು ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಕ್ಲೌಡ್‌ಗೆ ವಿನಂತಿಗಳ ನಿರೀಕ್ಷಿತ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನಾವು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದ್ದೇವೆ.
2. ನಾವು ಎಲ್ಲಾ ರೀತಿಯ ಸಾಧನಗಳಿಂದ ನೈಜ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.
3. ಪ್ರಸ್ತಾವಿತ ಕಲ್ಪನೆಯ ಪರಿಣಾಮಕಾರಿತ್ವವು ಸಾಬೀತಾಗಿದೆ.
4. ನಾವು ಅಪಾಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಿಲ್ಲ - ನಾವು ಗ್ರಾಹಕರಿಗೆ ಉತ್ಪಾದನಾ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲಿಲ್ಲ.
5. ಏನೂ ಮುರಿಯಲಿಲ್ಲ.

ಈಗ ಕಷ್ಟಕರವಾದ ಭಾಗದ ಬಗ್ಗೆ - ನಾವು ಅದನ್ನು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ

ಸುಲಭವಾದ ಭಾಗವು ಈಗ ಮುಗಿದಿದೆ - ಕೆಲಸ ಮಾಡುವ ಮೂಲಮಾದರಿ ಇದೆ. ಈಗ ಕಠಿಣ ಭಾಗವು ನೆಟ್‌ಫ್ಲಿಕ್ಸ್‌ನ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್‌ಗೆ ಪರಿಹಾರವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಿದೆ, 150 ಮಿಲಿಯನ್ ಬಳಕೆದಾರರು, ಸಾವಿರಾರು ಸಾಧನಗಳು, ನೂರಾರು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳು ಮತ್ತು ನಿರಂತರವಾಗಿ ಬದಲಾಗುತ್ತಿರುವ ಉತ್ಪನ್ನ ಮತ್ತು ಮೂಲಸೌಕರ್ಯಗಳಿಗೆ ನಿಯೋಜಿಸುತ್ತದೆ. ನೆಟ್‌ಫ್ಲಿಕ್ಸ್ ಸರ್ವರ್‌ಗಳು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಲಕ್ಷಾಂತರ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ ಮತ್ತು ಅಸಡ್ಡೆ ಕ್ರಿಯೆಯೊಂದಿಗೆ ಸೇವೆಯನ್ನು ಮುರಿಯುವುದು ಸುಲಭ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಸಾವಿರಾರು ಸಿಡಿಎನ್ ಸರ್ವರ್‌ಗಳ ಮೂಲಕ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ರೂಟ್ ಮಾಡಲು ನಾವು ಬಯಸುತ್ತೇವೆ, ಅಲ್ಲಿ ಏನಾದರೂ ನಿರಂತರವಾಗಿ ಮತ್ತು ಅತ್ಯಂತ ಅಸಮರ್ಪಕ ಕ್ಷಣದಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು ಒಡೆಯುತ್ತದೆ.

ಮತ್ತು ಈ ಎಲ್ಲದರ ಜೊತೆಗೆ, ತಂಡದ ಅಭಿವೃದ್ಧಿ, ನಿಯೋಜನೆ ಮತ್ತು ವ್ಯವಸ್ಥೆಯ ಸಂಪೂರ್ಣ ಬೆಂಬಲಕ್ಕೆ 3 ಎಂಜಿನಿಯರ್‌ಗಳು ಜವಾಬ್ದಾರರಾಗಿದ್ದಾರೆ.

ಆದ್ದರಿಂದ, ನಾವು ವಿಶ್ರಾಂತಿ ಮತ್ತು ಆರೋಗ್ಯಕರ ನಿದ್ರೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ.

ಅಭಿವೃದ್ಧಿಯನ್ನು ಹೇಗೆ ಮುಂದುವರಿಸುವುದು ಮತ್ತು ನಿಮ್ಮ ಎಲ್ಲಾ ಸಮಯವನ್ನು ಬೆಂಬಲಕ್ಕಾಗಿ ಕಳೆಯಬಾರದು? ನಮ್ಮ ವಿಧಾನವು 3 ತತ್ವಗಳನ್ನು ಆಧರಿಸಿದೆ:

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

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

ಸಹಜವಾಗಿ, ಹಿನ್ನಡೆಯ ಹೊರತಾಗಿಯೂ, ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ನಾವು ಸ್ಪಷ್ಟವಾದ ಶಿಸ್ತನ್ನು ಅನುಸರಿಸುತ್ತೇವೆ:

1. ಮಾದರಿ ಪರೀಕ್ಷೆ.
2. A/B ಪರೀಕ್ಷೆ ಅಥವಾ ಕ್ಯಾನರೀಸ್.
3. ಪ್ರಗತಿಪರ ರೋಲ್ಔಟ್.

ಮಾದರಿಗಳೊಂದಿಗೆ, ವಿಧಾನವನ್ನು ವಿವರಿಸಲಾಗಿದೆ - ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ ಪಾಕವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಬದಲಾವಣೆಗಳನ್ನು ಮೊದಲು ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ.

ಕ್ಯಾನರಿ ಪರೀಕ್ಷೆಗಾಗಿ, ನಾವು ಬದಲಾಯಿಸಬಹುದಾದ ಮೊದಲು ಮತ್ತು ನಂತರ ಸಿಸ್ಟಮ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಹೋಲಿಸಬಹುದಾದ ಹೋಲಿಸಬಹುದಾದ ಜೋಡಿ ಸರ್ವರ್‌ಗಳನ್ನು ನಾವು ಪಡೆಯಬೇಕಾಗಿದೆ. ಇದನ್ನು ಮಾಡಲು, ನಮ್ಮ ಅನೇಕ CDN ಸೈಟ್‌ಗಳಿಂದ, ಹೋಲಿಸಬಹುದಾದ ದಟ್ಟಣೆಯನ್ನು ಪಡೆಯುವ ಜೋಡಿ ಸರ್ವರ್‌ಗಳನ್ನು ನಾವು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ:

ನಂತರ ನಾವು ಕ್ಯಾನರಿ ಸರ್ವರ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ನಿರ್ಮಾಣವನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ. ಫಲಿತಾಂಶಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು, ನಾವು ನಿಯಂತ್ರಣ ಸರ್ವರ್‌ಗಳ ಮಾದರಿಯೊಂದಿಗೆ ಸರಿಸುಮಾರು 100-150 ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೋಲಿಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ರನ್ ಮಾಡುತ್ತೇವೆ:

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

ಸಾಮಾನ್ಯವಾಗಿ, ಈ ವಿಧಾನದ ಪರಿಣಾಮಕಾರಿತ್ವ ಮತ್ತು ಸುರಕ್ಷತೆಯು ಸಂಗ್ರಹಿಸಿದ ಮೆಟ್ರಿಕ್‌ಗಳ ಪ್ರಮಾಣ ಮತ್ತು ಗುಣಮಟ್ಟವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ನಮ್ಮ ಪ್ರಶ್ನೆ ವೇಗವರ್ಧಕ ವ್ಯವಸ್ಥೆಗಾಗಿ, ನಾವು ಎಲ್ಲಾ ಸಂಭಾವ್ಯ ಘಟಕಗಳಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ:

• ಗ್ರಾಹಕರಿಂದ - ಅವಧಿಗಳು ಮತ್ತು ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ, ಫಾಲ್ಬ್ಯಾಕ್ ದರಗಳು;
• ಪ್ರಾಕ್ಸಿ - ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಸಮಯದ ಅಂಕಿಅಂಶಗಳು;
• DNS - ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳು;
• ಕ್ಲೌಡ್ ಎಡ್ಜ್ - ಕ್ಲೌಡ್‌ನಲ್ಲಿ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಂಖ್ಯೆ ಮತ್ತು ಸಮಯ.

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

ನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ

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

ತಾತ್ತ್ವಿಕವಾಗಿ, ನೈಜ ಸಮಯದಲ್ಲಿ ಎಲ್ಲಾ ರೀತಿಯ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಫಿಲ್ಟರ್‌ಗಳಿಗೆ ಪೂರ್ಣ ಪ್ರವೇಶ. ಆದರೆ ಸಾಕಷ್ಟು ಮೆಟ್ರಿಕ್‌ಗಳಿವೆ, ಆದ್ದರಿಂದ ವೆಚ್ಚದ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಸಾಧನಗಳನ್ನು ಈ ಕೆಳಗಿನಂತೆ ಪ್ರತ್ಯೇಕಿಸುತ್ತೇವೆ:

ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಚಿಕಿತ್ಸೆ ನೀಡಲು ನಾವು ನಮ್ಮದೇ ಆದ ತೆರೆದ ಮೂಲ ನೈಜ-ಸಮಯದ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುತ್ತೇವೆ ಅಟ್ಲಾಸ್ и ಲುಮೆನ್ - ದೃಶ್ಯೀಕರಣಕ್ಕಾಗಿ. ಇದು ಮೆಮೊರಿಯಲ್ಲಿ ಒಟ್ಟು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ ಮತ್ತು ಎಚ್ಚರಿಕೆಯ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತದೆ. ಸ್ಥಳೀಕರಣ ಮತ್ತು ರೋಗನಿರ್ಣಯಕ್ಕಾಗಿ, ನಾವು Elasticsearch ಮತ್ತು Kibana ನಿಂದ ಲಾಗ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಮಾಡೆಲಿಂಗ್‌ಗಾಗಿ, ನಾವು ದೊಡ್ಡ ಡೇಟಾ ಮತ್ತು ದೃಶ್ಯೀಕರಣವನ್ನು ಕೋಷ್ಟಕದಲ್ಲಿ ಬಳಸುತ್ತೇವೆ.

ಈ ವಿಧಾನವು ಕೆಲಸ ಮಾಡಲು ತುಂಬಾ ಕಷ್ಟ ಎಂದು ತೋರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಪರಿಕರಗಳನ್ನು ಕ್ರಮಾನುಗತವಾಗಿ ಸಂಘಟಿಸುವ ಮೂಲಕ, ನಾವು ಸಮಸ್ಯೆಯನ್ನು ತ್ವರಿತವಾಗಿ ವಿಶ್ಲೇಷಿಸಬಹುದು, ಸಮಸ್ಯೆಯ ಪ್ರಕಾರವನ್ನು ನಿರ್ಧರಿಸಬಹುದು ಮತ್ತು ನಂತರ ವಿವರವಾದ ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಕೊರೆಯಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ, ಸ್ಥಗಿತದ ಮೂಲವನ್ನು ಗುರುತಿಸಲು ನಾವು ಸುಮಾರು 1-2 ನಿಮಿಷಗಳನ್ನು ಕಳೆಯುತ್ತೇವೆ. ಇದರ ನಂತರ, ನಾವು ಡಯಾಗ್ನೋಸ್ಟಿಕ್ಸ್ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ತಂಡದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ - ಹತ್ತಾರು ನಿಮಿಷಗಳಿಂದ ಹಲವಾರು ಗಂಟೆಗಳವರೆಗೆ.

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

• ಕ್ಲೈಂಟ್ ಫಾಲ್ಬ್ಯಾಕ್ ಶೇಕಡಾವಾರು - ಗ್ರಾಹಕರ ನಡವಳಿಕೆಯ ಮೌಲ್ಯಮಾಪನ;
• ಶೇಕಡಾವಾರು ಪ್ರೋಬ್ ದೋಷಗಳು - ನೆಟ್ವರ್ಕ್ ಘಟಕಗಳ ಸ್ಥಿರತೆ ಡೇಟಾ.

ಬಹುಪಾಲು ಬಳಕೆದಾರರಿಗೆ ಸಿಸ್ಟಮ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂಬುದನ್ನು ಈ ನಿರ್ಣಾಯಕ ಎಚ್ಚರಿಕೆಗಳು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತವೆ. ವಿನಂತಿಯ ವೇಗವರ್ಧನೆಯನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಎಷ್ಟು ಕ್ಲೈಂಟ್‌ಗಳು ಫಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಬಳಸಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ಸಿಸ್ಟಂನಲ್ಲಿ ಟನ್‌ಗಟ್ಟಲೆ ಬದಲಾವಣೆಗಳು ನಡೆಯುತ್ತಿದ್ದರೂ ಸಹ ನಾವು ವಾರಕ್ಕೆ ಸರಾಸರಿ 1 ಕ್ರಿಟಿಕಲ್ ಅಲರ್ಟ್‌ಗಿಂತ ಕಡಿಮೆ ಇರುತ್ತೇವೆ. ಇದು ನಮಗೆ ಏಕೆ ಸಾಕು?

1. ನಮ್ಮ ಪ್ರಾಕ್ಸಿ ಕೆಲಸ ಮಾಡದಿದ್ದರೆ ಕ್ಲೈಂಟ್ ಫಾಲ್ಬ್ಯಾಕ್ ಇರುತ್ತದೆ.
2. ಸಮಸ್ಯೆಗಳಿಗೆ ಸ್ಪಂದಿಸುವ ಸ್ವಯಂಚಾಲಿತ ಸ್ಟೀರಿಂಗ್ ವ್ಯವಸ್ಥೆ ಇದೆ.

ನಂತರದ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ವಿವರಗಳು. ನಮ್ಮ ಪ್ರಯೋಗ ವ್ಯವಸ್ಥೆ, ಮತ್ತು ಕ್ಲೈಂಟ್‌ನಿಂದ ಕ್ಲೌಡ್‌ಗೆ ವಿನಂತಿಗಳಿಗೆ ಸೂಕ್ತವಾದ ಮಾರ್ಗವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ಧರಿಸುವ ವ್ಯವಸ್ಥೆಯು ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಭಾಯಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ನಮ್ಮ ಮಾದರಿ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು 3 ಮಾರ್ಗ ವರ್ಗಗಳಿಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ. ಲೋಡ್ ಮಾಡುವ ಸಮಯದ ಜೊತೆಗೆ, ನಾವು ವಿತರಣೆಯ ಸತ್ಯವನ್ನು ನೋಡಬಹುದು. ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ವಿವಿಧ ಮಾರ್ಗಗಳಲ್ಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ನೋಡುವ ಮೂಲಕ ನಾವು ಎಲ್ಲಿ ಮತ್ತು ಯಾವುದು ಮುರಿದುಹೋಗಿದೆ ಮತ್ತು ವಿನಂತಿಯ ಮಾರ್ಗವನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ನಾವು ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸರಿಪಡಿಸಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸಬಹುದು.

ಉದಾಹರಣೆಗಳು:

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

ಹೀಗಾಗಿ, ಸಿಸ್ಟಮ್ ಬೆಂಬಲದ ತತ್ವಗಳನ್ನು ಈ ಕೆಳಗಿನಂತೆ ರೂಪಿಸಬಹುದು:

• ಸ್ಥಗಿತಗಳ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು;
• ಮಾಪನಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು;
• ನಮಗೆ ಸಾಧ್ಯವಾದರೆ ನಾವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ಥಗಿತಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತೇವೆ;
• ಅದು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನಾವು ನಿಮಗೆ ತಿಳಿಸುತ್ತೇವೆ;
• ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ನಾವು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು ಮತ್ತು ಚಿಕಿತ್ಸೆಯ ಸರದಿ ನಿರ್ಧಾರ ಟೂಲ್‌ಸೆಟ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ.

ಕಲಿತ ಪಾಠಗಳು

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

ನಮ್ಮ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ, ನಾವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಶಿಫಾರಸು ಮಾಡಬಹುದು:

1. ನಿಮ್ಮ ಅಂತಃಪ್ರಜ್ಞೆಯನ್ನು ನಂಬಬೇಡಿ.

   ನಮ್ಮ ತಂಡದ ಸದಸ್ಯರ ಅಪಾರ ಅನುಭವದ ಹೊರತಾಗಿಯೂ ನಮ್ಮ ಅಂತಃಪ್ರಜ್ಞೆಯು ನಮ್ಮನ್ನು ನಿರಂತರವಾಗಿ ವಿಫಲಗೊಳಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, CDN ಪ್ರಾಕ್ಸಿ ಅಥವಾ TCP Anycast ನ ನಡವಳಿಕೆಯನ್ನು ಬಳಸುವುದರಿಂದ ನಿರೀಕ್ಷಿತ ವೇಗವನ್ನು ನಾವು ತಪ್ಪಾಗಿ ಊಹಿಸಿದ್ದೇವೆ.

2. ಉತ್ಪಾದನೆಯಿಂದ ಡೇಟಾವನ್ನು ಪಡೆಯಿರಿ.

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

3. ಇತರ ಜನರ ಸಲಹೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಅನುಸರಿಸಬೇಡಿ - ನಿಮ್ಮ ಸ್ವಂತ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿ.

   ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ವಿಶ್ಲೇಷಿಸಲು ತತ್ವಗಳನ್ನು ಅನುಸರಿಸಿ, ಆದರೆ ಇತರ ಜನರ ಫಲಿತಾಂಶಗಳು ಮತ್ತು ಹೇಳಿಕೆಗಳನ್ನು ಕುರುಡಾಗಿ ಸ್ವೀಕರಿಸಬೇಡಿ. ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ನಿಖರವಾಗಿ ಏನು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಮಾತ್ರ ತಿಳಿದುಕೊಳ್ಳಬಹುದು. ನಿಮ್ಮ ಸಿಸ್ಟಂಗಳು ಮತ್ತು ನಿಮ್ಮ ಗ್ರಾಹಕರು ಇತರ ಕಂಪನಿಗಳಿಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ಭಿನ್ನವಾಗಿರಬಹುದು. ಅದೃಷ್ಟವಶಾತ್, ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳು ಈಗ ಲಭ್ಯವಿದೆ ಮತ್ತು ಬಳಸಲು ಸುಲಭವಾಗಿದೆ. ನೀವು ಪಡೆಯುವ ಫಲಿತಾಂಶಗಳು ನೆಟ್‌ಫ್ಲಿಕ್ಸ್, ಫೇಸ್‌ಬುಕ್, ಅಕಾಮೈ ಮತ್ತು ಇತರ ಕಂಪನಿಗಳು ಹೇಳಿಕೊಳ್ಳುವಂತಹದ್ದಲ್ಲ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, TLS, HTTP2 ಅಥವಾ DNS ವಿನಂತಿಗಳಲ್ಲಿನ ಅಂಕಿಅಂಶಗಳ ಕಾರ್ಯಕ್ಷಮತೆ Facebook, Uber, Akamai ಫಲಿತಾಂಶಗಳಿಂದ ಭಿನ್ನವಾಗಿದೆ - ಏಕೆಂದರೆ ನಾವು ವಿಭಿನ್ನ ಸಾಧನಗಳು, ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಡೇಟಾ ಹರಿವುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.

4. ಅನಗತ್ಯವಾಗಿ ಫ್ಯಾಷನ್ ಪ್ರವೃತ್ತಿಗಳನ್ನು ಅನುಸರಿಸಬೇಡಿ ಮತ್ತು ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ.

   ಸರಳವಾಗಿ ಪ್ರಾರಂಭಿಸಿ. ನಿಮಗೆ ಅಗತ್ಯವಿಲ್ಲದ ಘಟಕಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ಕಳೆಯುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಸರಳವಾದ ಕಾರ್ಯ ವ್ಯವಸ್ಥೆಯನ್ನು ಮಾಡುವುದು ಉತ್ತಮ. ನಿಮ್ಮ ಅಳತೆಗಳು ಮತ್ತು ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಕಾರ್ಯಗಳು ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿ.

5. ಹೊಸ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸಿದ್ಧರಾಗಿ.

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

   • AWS ಪ್ರದೇಶಗಳಲ್ಲಿ ಸಂಚಾರವನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು ಮತ್ತು ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು;
   • ಸಿಡಿಎನ್ ಸ್ಥಿರತೆಯನ್ನು ರೂಪಿಸಲು;
   • DNS ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು;
   • TLS/TCP ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು.

ತೀರ್ಮಾನಕ್ಕೆ

ವರದಿಯಲ್ಲಿ, ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಕ್ಲೌಡ್ ನಡುವೆ ಇಂಟರ್ನೆಟ್ ವಿನಂತಿಗಳನ್ನು ವೇಗಗೊಳಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ನೆಟ್‌ಫ್ಲಿಕ್ಸ್ ಹೇಗೆ ಪರಿಹರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನು ವಿವರಿಸಿದೆ. ಕ್ಲೈಂಟ್‌ಗಳ ಮೇಲೆ ಮಾದರಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಡೇಟಾವನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ವೇಗವಾದ ಮಾರ್ಗದ ಮೂಲಕ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಉತ್ಪಾದನಾ ವಿನಂತಿಗಳನ್ನು ರೂಟ್ ಮಾಡಲು ಸಂಗ್ರಹಿಸಿದ ಐತಿಹಾಸಿಕ ಡೇಟಾವನ್ನು ಬಳಸುತ್ತೇವೆ. ಈ ಕಾರ್ಯವನ್ನು ಸಾಧಿಸಲು ನಾವು ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು, ನಮ್ಮ CDN ಮೂಲಸೌಕರ್ಯ, ಬೆನ್ನೆಲುಬು ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು DNS ಸರ್ವರ್‌ಗಳ ತತ್ವಗಳನ್ನು ಹೇಗೆ ಬಳಸುತ್ತೇವೆ.

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

ಸಮಸ್ಯೆಗೆ ನಮ್ಮ ಪರಿಹಾರವು ನಿಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ನಿಮ್ಮ ಸ್ವಂತ CDN ಮೂಲಸೌಕರ್ಯವನ್ನು ನೀವು ಹೊಂದಿಲ್ಲದಿದ್ದರೂ ಅಥವಾ ಅದು ನಮ್ಮಿಂದ ಗಮನಾರ್ಹವಾಗಿ ಭಿನ್ನವಾಗಿದ್ದರೂ ಸಹ, ಸಿದ್ಧಾಂತ ಮತ್ತು ವಿನ್ಯಾಸದ ತತ್ವಗಳು ಉಳಿಯುತ್ತವೆ.

ವ್ಯಾಪಾರ ವಿನಂತಿಗಳ ವೇಗದ ಪ್ರಾಮುಖ್ಯತೆಯು ಸಹ ಮುಖ್ಯವಾಗಿದೆ. ಮತ್ತು ಸರಳವಾದ ಸೇವೆಗಾಗಿ ಸಹ ನೀವು ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗಿದೆ: ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರು, ಸರ್ವರ್ ಸ್ಥಳ, CDN ಮತ್ತು DNS ಪೂರೈಕೆದಾರರ ನಡುವೆ. ನಿಮ್ಮ ಆಯ್ಕೆಯು ನಿಮ್ಮ ಗ್ರಾಹಕರಿಗೆ ಇಂಟರ್ನೆಟ್ ಪ್ರಶ್ನೆಗಳ ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ಪ್ರಭಾವಿಸುತ್ತದೆ. ಮತ್ತು ನೀವು ಈ ಪ್ರಭಾವವನ್ನು ಅಳೆಯಲು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮುಖ್ಯವಾಗಿದೆ.

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

ಈ ವರ್ಷ ಸಮ್ಮೇಳನವು ಜುಲೈ 6 ರಿಂದ 10 ರವರೆಗೆ ನಡೆಯಲಿದೆ ಆನ್ಲೈನ್ ​​ರೂಪದಲ್ಲಿ. ನೀವು DevOps ನ ಪಿತಾಮಹರಲ್ಲಿ ಒಬ್ಬರಾದ ಜಾನ್ ವಿಲ್ಲಿಸ್ ಅವರಿಗೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬಹುದು!

ಮೂಲ: www.habr.com