ಇಂದು, Bitrix24 ಸೇವೆಯು ನೂರಾರು ಗಿಗಾಬಿಟ್‌ಗಳ ದಟ್ಟಣೆಯನ್ನು ಹೊಂದಿಲ್ಲ, ಅಥವಾ ಇದು ಸರ್ವರ್‌ಗಳ ದೊಡ್ಡ ಫ್ಲೀಟ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ (ಆದಾಗ್ಯೂ, ಸಹಜವಾಗಿ, ಕೆಲವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವುಗಳಿವೆ). ಆದರೆ ಅನೇಕ ಗ್ರಾಹಕರಿಗೆ ಇದು ಕಂಪನಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಮುಖ್ಯ ಸಾಧನವಾಗಿದೆ; ಆದ್ದರಿಂದ, ಬೀಳಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ. ಕ್ರ್ಯಾಶ್ ಸಂಭವಿಸಿದಲ್ಲಿ, ಆದರೆ ಸೇವೆಯು "ಚೇತರಿಸಿಕೊಂಡಿದೆ" ಯಾರೂ ಏನನ್ನೂ ಗಮನಿಸಲಿಲ್ಲವೇ? ಮತ್ತು ಕೆಲಸದ ಗುಣಮಟ್ಟ ಮತ್ತು ಗ್ರಾಹಕರ ಸಂಖ್ಯೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ವಿಫಲತೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಹೇಗೆ ಸಾಧ್ಯ? Bitrix24 ನಲ್ಲಿ ಕ್ಲೌಡ್ ಸೇವೆಗಳ ನಿರ್ದೇಶಕ ಅಲೆಕ್ಸಾಂಡರ್ ಡೆಮಿಡೋವ್, ಉತ್ಪನ್ನದ ಅಸ್ತಿತ್ವದ 7 ವರ್ಷಗಳಲ್ಲಿ ಮೀಸಲಾತಿ ವ್ಯವಸ್ಥೆಯು ಹೇಗೆ ವಿಕಸನಗೊಂಡಿದೆ ಎಂಬುದರ ಕುರಿತು ನಮ್ಮ ಬ್ಲಾಗ್‌ಗಾಗಿ ಮಾತನಾಡಿದರು.
“ನಾವು 24 ವರ್ಷಗಳ ಹಿಂದೆ SaaS ಆಗಿ Bitrix7 ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಮುಖ್ಯ ತೊಂದರೆಯು ಬಹುಶಃ ಈ ಕೆಳಗಿನಂತಿತ್ತು: ಇದನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿ SaaS ಎಂದು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ಈ ಉತ್ಪನ್ನವು ಪೆಟ್ಟಿಗೆಯ ಪರಿಹಾರದ ಸ್ವರೂಪದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ. ಗ್ರಾಹಕರು ಅದನ್ನು ನಮ್ಮಿಂದ ಖರೀದಿಸಿದರು, ಅದನ್ನು ತಮ್ಮ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಿದ್ದಾರೆ, ಕಾರ್ಪೊರೇಟ್ ಪೋರ್ಟಲ್ ಅನ್ನು ಹೊಂದಿಸಿದ್ದಾರೆ - ಉದ್ಯೋಗಿ ಸಂವಹನ, ಫೈಲ್ ಸಂಗ್ರಹಣೆ, ಕಾರ್ಯ ನಿರ್ವಹಣೆ, ಸಿಆರ್‌ಎಂ, ಅಷ್ಟೆ. ಮತ್ತು 2012 ರ ಹೊತ್ತಿಗೆ, ನಾವು ಅದನ್ನು SaaS ಆಗಿ ಪ್ರಾರಂಭಿಸಲು ಬಯಸುತ್ತೇವೆ ಎಂದು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಅದನ್ನು ನಾವೇ ನಿರ್ವಹಿಸುತ್ತೇವೆ, ದೋಷ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ. ನಾವು ದಾರಿಯುದ್ದಕ್ಕೂ ಅನುಭವವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಅಲ್ಲಿಯವರೆಗೆ ನಾವು ಅದನ್ನು ಹೊಂದಿರಲಿಲ್ಲ - ನಾವು ಕೇವಲ ಸಾಫ್ಟ್‌ವೇರ್ ತಯಾರಕರು, ಸೇವಾ ಪೂರೈಕೆದಾರರಲ್ಲ.
ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ, ದೋಷ ಸಹಿಷ್ಣುತೆ, ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಸೇವೆಯ ನಿರಂತರ ಲಭ್ಯತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನೀವು ಸರಳವಾದ ಸಾಮಾನ್ಯ ವೆಬ್‌ಸೈಟ್, ಅಂಗಡಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ಮತ್ತು ಅದು ನಿಮ್ಮ ಮೇಲೆ ಬೀಳುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳುತ್ತದೆ. ಒಂದು ಗಂಟೆ, ನೀವು ಮಾತ್ರ ಬಳಲುತ್ತಿದ್ದೀರಿ, ನೀವು ಆದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ, ನೀವು ಗ್ರಾಹಕರನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ, ಆದರೆ ನಿಮ್ಮ ಕ್ಲೈಂಟ್‌ಗೆ ಇದು ತುಂಬಾ ನಿರ್ಣಾಯಕವಲ್ಲ. ಅವರು ಅಸಮಾಧಾನಗೊಂಡರು, ಆದರೆ ಅವರು ಬೇರೆ ಸೈಟ್ನಲ್ಲಿ ಅದನ್ನು ಖರೀದಿಸಿದರು. ಮತ್ತು ಇದು ಕಂಪನಿಯೊಳಗಿನ ಎಲ್ಲಾ ಕೆಲಸಗಳು, ಸಂವಹನಗಳು, ನಿರ್ಧಾರಗಳನ್ನು ಒಳಗೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದ್ದರೆ, ಬಳಕೆದಾರರ ವಿಶ್ವಾಸವನ್ನು ಗಳಿಸುವುದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯ, ಅಂದರೆ ಅವರನ್ನು ನಿರಾಸೆಗೊಳಿಸಬಾರದು ಮತ್ತು ಬೀಳಬಾರದು. ಏಕೆಂದರೆ ಒಳಗೆ ಏನಾದರೂ ಕೆಲಸ ಮಾಡದಿದ್ದರೆ ಎಲ್ಲಾ ಕೆಲಸಗಳು ನಿಲ್ಲಬಹುದು.
Bitrix.24 SaaS ಆಗಿ
ನಾವು 2011 ರಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಬಿಡುಗಡೆಗೆ ಒಂದು ವರ್ಷದ ಮೊದಲು ಮೊದಲ ಮೂಲಮಾದರಿಯನ್ನು ಜೋಡಿಸಿದ್ದೇವೆ. ನಾವು ಅದನ್ನು ಸುಮಾರು ಒಂದು ವಾರದಲ್ಲಿ ಜೋಡಿಸಿದ್ದೇವೆ, ಅದನ್ನು ನೋಡಿದೆವು, ಅದನ್ನು ತಿರುಗಿಸಿದೆವು - ಅದು ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. ಅಂದರೆ, ನೀವು ಫಾರ್ಮ್‌ಗೆ ಹೋಗಬಹುದು, ಅಲ್ಲಿ ಪೋರ್ಟಲ್‌ನ ಹೆಸರನ್ನು ನಮೂದಿಸಿ, ಹೊಸ ಪೋರ್ಟಲ್ ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರ ನೆಲೆಯನ್ನು ರಚಿಸಬಹುದು. ನಾವು ಅದನ್ನು ನೋಡಿದ್ದೇವೆ, ಉತ್ಪನ್ನವನ್ನು ತಾತ್ವಿಕವಾಗಿ ನಿರ್ಣಯಿಸಿದ್ದೇವೆ, ಅದನ್ನು ಸ್ಕ್ರ್ಯಾಪ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಇಡೀ ವರ್ಷ ಅದನ್ನು ಸಂಸ್ಕರಿಸುವುದನ್ನು ಮುಂದುವರಿಸಿದ್ದೇವೆ. ನಾವು ಒಂದು ದೊಡ್ಡ ಕಾರ್ಯವನ್ನು ಹೊಂದಿರುವುದರಿಂದ: ನಾವು ಎರಡು ವಿಭಿನ್ನ ಕೋಡ್ ಬೇಸ್‌ಗಳನ್ನು ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ, ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಉತ್ಪನ್ನವನ್ನು ಬೆಂಬಲಿಸಲು ನಾವು ಬಯಸುವುದಿಲ್ಲ, ಪ್ರತ್ಯೇಕ ಕ್ಲೌಡ್ ಪರಿಹಾರಗಳು - ನಾವು ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಕೋಡ್‌ನಲ್ಲಿ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ.
ಆ ಸಮಯದಲ್ಲಿ ಒಂದು ವಿಶಿಷ್ಟವಾದ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಒಂದು ಸರ್ವರ್ ಆಗಿದ್ದು ಅದರಲ್ಲಿ ಕೆಲವು PHP ಕೋಡ್ ರನ್ ಆಗುತ್ತದೆ, mysql ಡೇಟಾಬೇಸ್, ಫೈಲ್‌ಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ, ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು, ಚಿತ್ರಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಫೋಲ್ಡರ್‌ನಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ - ಅಲ್ಲದೆ, ಇದು ಎಲ್ಲಾ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅಯ್ಯೋ, ಇದನ್ನು ಬಳಸಿಕೊಂಡು ವಿಮರ್ಶಾತ್ಮಕವಾಗಿ ಸ್ಥಿರವಾದ ವೆಬ್ ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಅಸಾಧ್ಯ. ಅಲ್ಲಿ, ವಿತರಿಸಿದ ಸಂಗ್ರಹವನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಡೇಟಾಬೇಸ್ ಪ್ರತಿಕೃತಿಯನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.
ನಾವು ಅವಶ್ಯಕತೆಗಳನ್ನು ರೂಪಿಸಿದ್ದೇವೆ: ಇದು ವಿಭಿನ್ನ ಸ್ಥಳಗಳಲ್ಲಿ ನೆಲೆಗೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯ, ಪ್ರತಿಕೃತಿಯನ್ನು ಬೆಂಬಲಿಸುವುದು ಮತ್ತು ವಿಭಿನ್ನ ಭೌಗೋಳಿಕವಾಗಿ ವಿತರಿಸಲಾದ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಆದರ್ಶಪ್ರಾಯವಾಗಿದೆ. ಉತ್ಪನ್ನದ ತರ್ಕವನ್ನು ಮತ್ತು ವಾಸ್ತವವಾಗಿ, ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ಲೋಡ್‌ಗೆ ಅನುಗುಣವಾಗಿ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಅಳೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಸ್ಟ್ಯಾಟಿಕ್ಸ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸಹಿಸಿಕೊಳ್ಳಿ. ಈ ಪರಿಗಣನೆಗಳಿಂದ, ವಾಸ್ತವವಾಗಿ, ಉತ್ಪನ್ನದ ಅವಶ್ಯಕತೆಗಳು ಹೊರಹೊಮ್ಮಿದವು, ಅದನ್ನು ನಾವು ವರ್ಷದ ಅವಧಿಯಲ್ಲಿ ಪರಿಷ್ಕರಿಸಿದ್ದೇವೆ. ಈ ಸಮಯದಲ್ಲಿ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ, ಏಕೀಕೃತವಾಗಿ ಹೊರಹೊಮ್ಮಿತು - ಪೆಟ್ಟಿಗೆಯ ಪರಿಹಾರಗಳಿಗಾಗಿ, ನಮ್ಮ ಸ್ವಂತ ಸೇವೆಗಾಗಿ - ನಮಗೆ ಅಗತ್ಯವಿರುವ ವಿಷಯಗಳಿಗೆ ನಾವು ಬೆಂಬಲವನ್ನು ನೀಡಿದ್ದೇವೆ. ಉತ್ಪನ್ನದ ಮಟ್ಟದಲ್ಲಿಯೇ mysql ಪುನರಾವರ್ತನೆಗೆ ಬೆಂಬಲ: ಅಂದರೆ, ಕೋಡ್ ಬರೆಯುವ ಡೆವಲಪರ್ ತನ್ನ ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ವಿತರಿಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಯೋಚಿಸುವುದಿಲ್ಲ, ಅವನು ನಮ್ಮ API ಅನ್ನು ಬಳಸುತ್ತಾನೆ ಮತ್ತು ಮಾಸ್ಟರ್‌ಗಳ ನಡುವೆ ವಿನಂತಿಗಳನ್ನು ಬರೆಯಲು ಮತ್ತು ಓದಲು ಹೇಗೆ ಸರಿಯಾಗಿ ವಿತರಿಸಬೇಕೆಂದು ನಮಗೆ ತಿಳಿದಿದೆ. ಮತ್ತು ಗುಲಾಮರು.
ನಾವು ವಿವಿಧ ಕ್ಲೌಡ್ ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್‌ಗಳಿಗಾಗಿ ಉತ್ಪನ್ನ ಮಟ್ಟದಲ್ಲಿ ಬೆಂಬಲವನ್ನು ನೀಡಿದ್ದೇವೆ: google ಸಂಗ್ರಹಣೆ, amazon s3, ಜೊತೆಗೆ ಓಪನ್ ಸ್ಟಾಕ್ ಸ್ವಿಫ್ಟ್‌ಗೆ ಬೆಂಬಲ. ಆದ್ದರಿಂದ, ಇದು ನಮಗೆ ಸೇವೆಯಾಗಿ ಮತ್ತು ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಪರಿಹಾರದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅನುಕೂಲಕರವಾಗಿದೆ: ಅವರು ನಮ್ಮ API ಅನ್ನು ಕೆಲಸಕ್ಕಾಗಿ ಬಳಸಿದರೆ, ಫೈಲ್ ಅನ್ನು ಅಂತಿಮವಾಗಿ ಎಲ್ಲಿ ಉಳಿಸಲಾಗುತ್ತದೆ ಎಂದು ಅವರು ಯೋಚಿಸುವುದಿಲ್ಲ, ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಅಥವಾ ಆಬ್ಜೆಕ್ಟ್ ಫೈಲ್ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ.
ಪರಿಣಾಮವಾಗಿ, ನಾವು ಸಂಪೂರ್ಣ ಡೇಟಾ ಕೇಂದ್ರದ ಮಟ್ಟದಲ್ಲಿ ಕಾಯ್ದಿರಿಸುತ್ತೇವೆ ಎಂದು ನಾವು ತಕ್ಷಣ ನಿರ್ಧರಿಸಿದ್ದೇವೆ. 2012 ರಲ್ಲಿ, ನಾವು ಸಂಪೂರ್ಣವಾಗಿ Amazon AWS ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಏಕೆಂದರೆ ನಾವು ಈಗಾಗಲೇ ಈ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನೊಂದಿಗೆ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದೇವೆ - ನಮ್ಮ ಸ್ವಂತ ವೆಬ್‌ಸೈಟ್ ಅಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ. ಪ್ರತಿ ಪ್ರದೇಶದಲ್ಲಿ ಅಮೆಜಾನ್ ಹಲವಾರು ಲಭ್ಯತೆಯ ವಲಯಗಳನ್ನು ಹೊಂದಿದೆ ಎಂಬ ಅಂಶದಿಂದ ನಾವು ಆಕರ್ಷಿತರಾಗಿದ್ದೇವೆ - ವಾಸ್ತವವಾಗಿ, (ಅವರ ಪರಿಭಾಷೆಯಲ್ಲಿ) ಹಲವಾರು ಡೇಟಾ ಕೇಂದ್ರಗಳು ಪರಸ್ಪರ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಸ್ವತಂತ್ರವಾಗಿರುತ್ತವೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಡೇಟಾ ಕೇಂದ್ರದ ಮಟ್ಟದಲ್ಲಿ ಕಾಯ್ದಿರಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ: ಅದು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ವಿಫಲವಾದಲ್ಲಿ, ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಮಾಸ್ಟರ್-ಮಾಸ್ಟರ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ, ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಸ್ಥಿರ ಡೇಟಾವನ್ನು s3 ಆಬ್ಜೆಕ್ಟ್ ಸಂಗ್ರಹಣೆಗೆ ಸರಿಸಲಾಗುತ್ತದೆ. ಲೋಡ್ ಸಮತೋಲಿತವಾಗಿದೆ - ಆ ಸಮಯದಲ್ಲಿ ಅಮೆಜಾನ್ ಎಲ್ಬ್ ಮೂಲಕ, ಆದರೆ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ನಾವು ನಮ್ಮದೇ ಆದ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ಗಳಿಗೆ ಬಂದಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಮಗೆ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ತರ್ಕ ಅಗತ್ಯವಿದೆ.
ಅವರು ಬಯಸಿದ್ದನ್ನು ಅವರು ಪಡೆದರು ...
ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಬಯಸುವ ಎಲ್ಲಾ ಮೂಲಭೂತ ವಿಷಯಗಳು - ಸರ್ವರ್‌ಗಳ ದೋಷ ಸಹಿಷ್ಣುತೆ, ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, ಡೇಟಾಬೇಸ್‌ಗಳು - ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಸರಳವಾದ ಸನ್ನಿವೇಶ: ನಮ್ಮ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಒಂದು ವಿಫಲವಾದರೆ, ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ - ಅವುಗಳನ್ನು ಸಮತೋಲನದಿಂದ ಸ್ವಿಚ್ ಆಫ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಬ್ಯಾಲೆನ್ಸರ್ (ಆ ಸಮಯದಲ್ಲಿ ಅದು ಅಮೆಜಾನ್‌ನ ಎಲ್ಬ್ ಆಗಿತ್ತು) ಕ್ರಮಬದ್ಧವಾಗಿಲ್ಲದ ಯಂತ್ರಗಳನ್ನು ಅನಾರೋಗ್ಯಕರವೆಂದು ಗುರುತಿಸಿತು ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಲೋಡ್ ವಿತರಣೆಯನ್ನು ಆಫ್ ಮಾಡಿತು. ಅಮೆಜಾನ್ ಆಟೋಸ್ಕೇಲಿಂಗ್ ಕೆಲಸ ಮಾಡಿದೆ: ಲೋಡ್ ಹೆಚ್ಚಾದಾಗ, ಹೊಸ ಯಂತ್ರಗಳನ್ನು ಆಟೋಸ್ಕೇಲಿಂಗ್ ಗುಂಪಿಗೆ ಸೇರಿಸಲಾಯಿತು, ಲೋಡ್ ಅನ್ನು ಹೊಸ ಯಂತ್ರಗಳಿಗೆ ವಿತರಿಸಲಾಯಿತು - ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ. ನಮ್ಮ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳೊಂದಿಗೆ, ತರ್ಕವು ಸರಿಸುಮಾರು ಒಂದೇ ಆಗಿರುತ್ತದೆ: ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗೆ ಏನಾದರೂ ಸಂಭವಿಸಿದರೆ, ನಾವು ಅದರಿಂದ ವಿನಂತಿಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತೇವೆ, ಈ ಯಂತ್ರಗಳನ್ನು ಹೊರಹಾಕುತ್ತೇವೆ, ಹೊಸದನ್ನು ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. ಈ ಯೋಜನೆಯು ವರ್ಷಗಳಲ್ಲಿ ಸ್ವಲ್ಪ ಬದಲಾಗಿದೆ, ಆದರೆ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸಿದೆ: ಇದು ಸರಳವಾಗಿದೆ, ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ ಮತ್ತು ಅದರಲ್ಲಿ ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲ.
ನಾವು ಪ್ರಪಂಚದಾದ್ಯಂತ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ, ಗ್ರಾಹಕರ ಹೊರೆಯ ಶಿಖರಗಳು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿವೆ ಮತ್ತು ಸೌಹಾರ್ದಯುತ ರೀತಿಯಲ್ಲಿ, ನಮ್ಮ ಸಿಸ್ಟಂನ ಯಾವುದೇ ಘಟಕಗಳಲ್ಲಿ ನಾವು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಕೆಲವು ಸೇವಾ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ - ಗ್ರಾಹಕರ ಗಮನಕ್ಕೆ ಬರುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಕಾರ್ಯಾಚರಣೆಯಿಂದ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಆಫ್ ಮಾಡಲು ನಮಗೆ ಅವಕಾಶವಿದೆ, ಎರಡನೇ ಡೇಟಾ ಕೇಂದ್ರಕ್ಕೆ ಲೋಡ್ ಅನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡುತ್ತದೆ.
ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ? — ನಾವು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಡೇಟಾ ಸೆಂಟರ್‌ಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ - ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ಅಪಘಾತ ಸಂಭವಿಸಿದಲ್ಲಿ, ಇದು ಒಂದು ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ನಮ್ಮ ಯೋಜಿತ ಕೆಲಸವಾಗಿದ್ದರೆ, ನಂತರ ನಾವು ಈ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ದಟ್ಟಣೆಯ ಭಾಗವನ್ನು ಎರಡನೇ ಡೇಟಾ ಕೇಂದ್ರಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತೇವೆ, ಅಮಾನತುಗೊಳಿಸುತ್ತೇವೆ ಅದರ ಪ್ರತಿರೂಪ. ಎರಡನೇ ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ಲೋಡ್ ಹೆಚ್ಚಾದ ಕಾರಣ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಹೊಸ ಯಂತ್ರಗಳು ಅಗತ್ಯವಿದ್ದರೆ, ಅವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ. ನಾವು ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತೇವೆ, ಪ್ರತಿಕೃತಿಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಾವು ಸಂಪೂರ್ಣ ಲೋಡ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತೇವೆ. ನಾವು ಎರಡನೇ DC ಯಲ್ಲಿ ಕೆಲವು ಕೆಲಸವನ್ನು ಪ್ರತಿಬಿಂಬಿಸಬೇಕಾದರೆ, ಉದಾಹರಣೆಗೆ, ಸಿಸ್ಟಮ್ ನವೀಕರಣಗಳನ್ನು ಸ್ಥಾಪಿಸಿ ಅಥವಾ ಎರಡನೇ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬದಲಾಯಿಸಿ, ನಂತರ, ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು ಇನ್ನೊಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಅದೇ ವಿಷಯವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ. ಮತ್ತು ಇದು ಅಪಘಾತವಾಗಿದ್ದರೆ, ನಾವು ಎಲ್ಲವನ್ನೂ ಕ್ಷುಲ್ಲಕವಾಗಿ ಮಾಡುತ್ತೇವೆ: ನಾವು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಈವೆಂಟ್-ಹ್ಯಾಂಡ್ಲರ್‌ಗಳ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸುತ್ತೇವೆ. ಹಲವಾರು ತಪಾಸಣೆಗಳನ್ನು ಪ್ರಚೋದಿಸಿದರೆ ಮತ್ತು ಸ್ಥಿತಿಯು ನಿರ್ಣಾಯಕಕ್ಕೆ ಹೋದರೆ, ನಾವು ಈ ಅಥವಾ ಆ ತರ್ಕವನ್ನು ನಿರ್ವಹಿಸುವ ಹ್ಯಾಂಡ್ಲರ್ ಅನ್ನು ಈ ಹ್ಯಾಂಡ್ಲರ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತೇವೆ. ಪ್ರತಿ ಡೇಟಾಬೇಸ್‌ಗೆ, ಯಾವ ಸರ್ವರ್ ವಿಫಲವಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ ಮತ್ತು ಅದು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಎಲ್ಲಿ ಬದಲಾಯಿಸಬೇಕು. ಐತಿಹಾಸಿಕವಾಗಿ, ನಾವು ನಾಗಿಯೋಸ್ ಅಥವಾ ಅದರ ಕೆಲವು ಫೋರ್ಕ್‌ಗಳನ್ನು ಒಂದಲ್ಲ ಒಂದು ರೂಪದಲ್ಲಿ ಬಳಸುತ್ತೇವೆ. ತಾತ್ವಿಕವಾಗಿ, ಯಾವುದೇ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಇದೇ ರೀತಿಯ ಕಾರ್ಯವಿಧಾನಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ; ಈಗ ಮೇಲ್ವಿಚಾರಣೆಯು ಅಲಭ್ಯತೆಯಿಂದ ಪ್ರಚೋದಿಸಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ.
ನಾವು ಎಲ್ಲವನ್ನೂ ಕಾಯ್ದಿರಿಸಿದ್ದೇವೆಯೇ?
ನಾವು USA ಯಿಂದ ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಯುರೋಪ್‌ನಿಂದ ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಪೂರ್ವಕ್ಕೆ ಹತ್ತಿರವಿರುವ ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು - ಜಪಾನ್, ಸಿಂಗಾಪುರ್ ಮತ್ತು ಹೀಗೆ. ಸಹಜವಾಗಿ, ಗ್ರಾಹಕರ ದೊಡ್ಡ ಪಾಲು ರಷ್ಯಾದಲ್ಲಿದೆ. ಅಂದರೆ, ಕೆಲಸವು ಒಂದು ಪ್ರದೇಶದಲ್ಲಿ ಅಲ್ಲ. ಬಳಕೆದಾರರು ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಬಯಸುತ್ತಾರೆ, ವಿವಿಧ ಸ್ಥಳೀಯ ಕಾನೂನುಗಳನ್ನು ಅನುಸರಿಸಲು ಅವಶ್ಯಕತೆಗಳಿವೆ, ಮತ್ತು ಪ್ರತಿ ಪ್ರದೇಶದಲ್ಲಿ ನಾವು ಎರಡು ಡೇಟಾ ಕೇಂದ್ರಗಳನ್ನು ಕಾಯ್ದಿರಿಸುತ್ತೇವೆ, ಜೊತೆಗೆ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಸೇವೆಗಳಿವೆ, ಅದು ಮತ್ತೆ ಒಂದು ಪ್ರದೇಶದಲ್ಲಿ ಇರಿಸಲು ಅನುಕೂಲಕರವಾಗಿದೆ - ಗ್ರಾಹಕರಿಗೆ ಈ ಪ್ರದೇಶವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. REST ಹ್ಯಾಂಡ್ಲರ್‌ಗಳು, ದೃಢೀಕರಣ ಸರ್ವರ್‌ಗಳು, ಒಟ್ಟಾರೆಯಾಗಿ ಕ್ಲೈಂಟ್‌ನ ಕಾರ್ಯಾಚರಣೆಗೆ ಅವು ಕಡಿಮೆ ನಿರ್ಣಾಯಕವಾಗಿವೆ, ನೀವು ಅವುಗಳನ್ನು ಸಣ್ಣ ಸ್ವೀಕಾರಾರ್ಹ ವಿಳಂಬದೊಂದಿಗೆ ಬದಲಾಯಿಸಬಹುದು, ಆದರೆ ಅವುಗಳನ್ನು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಮತ್ತು ಏನು ಮಾಡಬೇಕು ಎಂಬುದರ ಕುರಿತು ಚಕ್ರವನ್ನು ಮರುಶೋಧಿಸಲು ನೀವು ಬಯಸುವುದಿಲ್ಲ ಅವರೊಂದಿಗೆ. ಆದ್ದರಿಂದ, ಹೆಚ್ಚುವರಿ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ಸಾಮರ್ಥ್ಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಬದಲು ನಾವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಹಾರಗಳನ್ನು ಗರಿಷ್ಠವಾಗಿ ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ಎಲ್ಲೋ ನಾವು ಕ್ಷುಲ್ಲಕವಾಗಿ DNS ಮಟ್ಟದಲ್ಲಿ ಸ್ವಿಚಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಅದೇ DNS ಮೂಲಕ ಸೇವೆಯ ಜೀವಂತಿಕೆಯನ್ನು ನಾವು ನಿರ್ಧರಿಸುತ್ತೇವೆ. ಅಮೆಜಾನ್ ರೂಟ್ 53 ಸೇವೆಯನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ನೀವು ನಮೂದುಗಳನ್ನು ಮಾಡಬಹುದಾದ DNS ಅಲ್ಲ ಮತ್ತು ಅದು ಇಲ್ಲಿದೆ-ಇದು ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ಅನುಕೂಲಕರವಾಗಿದೆ. ಅದರ ಮೂಲಕ ನೀವು ಜಿಯೋಲೊಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಜಿಯೋ-ವಿತರಿಸಿದ ಸೇವೆಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು, ಕ್ಲೈಂಟ್ ಎಲ್ಲಿಂದ ಬಂದಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಮತ್ತು ಅವನಿಗೆ ಕೆಲವು ದಾಖಲೆಗಳನ್ನು ನೀಡಲು ನೀವು ಅದನ್ನು ಬಳಸಿದಾಗ - ಅದರ ಸಹಾಯದಿಂದ ನೀವು ವಿಫಲವಾದ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು. ಅದೇ ಆರೋಗ್ಯ-ಪರೀಕ್ಷೆಗಳನ್ನು ರೂಟ್ 53 ರಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ನೀವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ಹೊಂದಿಸಿ, ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೊಂದಿಸಿ, ಸೇವೆಯ “ಲೈವ್‌ನೆಸ್” ಅನ್ನು ನಿರ್ಧರಿಸಲು ಯಾವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಹೊಂದಿಸಿ - tcp, http, https; ಸೇವೆಯು ಜೀವಂತವಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ತಪಾಸಣೆಗಳ ಆವರ್ತನವನ್ನು ಹೊಂದಿಸಿ. ಮತ್ತು DNS ನಲ್ಲಿಯೇ ನೀವು ಪ್ರಾಥಮಿಕ ಯಾವುದು, ಯಾವುದು ದ್ವಿತೀಯಕ, ಆರೋಗ್ಯ ತಪಾಸಣೆಯನ್ನು ಮಾರ್ಗ 53 ರೊಳಗೆ ಪ್ರಚೋದಿಸಿದರೆ ಎಲ್ಲಿ ಬದಲಾಯಿಸಬೇಕು ಎಂಬುದನ್ನು ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೀರಿ. ಇದೆಲ್ಲವನ್ನೂ ಇತರ ಕೆಲವು ಸಾಧನಗಳೊಂದಿಗೆ ಮಾಡಬಹುದು, ಆದರೆ ಅದು ಏಕೆ ಅನುಕೂಲಕರವಾಗಿದೆ - ನಾವು ಅದನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ ಒಮ್ಮೆ ಮೇಲಕ್ಕೆ ಮತ್ತು ನಂತರ ನಾವು ಹೇಗೆ ತಪಾಸಣೆ ಮಾಡುತ್ತೇವೆ, ಹೇಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ ಎಂದು ಯೋಚಿಸಬೇಡಿ: ಎಲ್ಲವೂ ತನ್ನದೇ ಆದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಮೊದಲ "ಆದರೆ": ಮಾರ್ಗ 53 ಅನ್ನು ಹೇಗೆ ಮತ್ತು ಯಾವುದರೊಂದಿಗೆ ಕಾಯ್ದಿರಿಸಬೇಕು? ಯಾರಿಗೆ ಗೊತ್ತು, ಅವನಿಗೆ ಏನಾದರೂ ಸಂಭವಿಸಿದರೆ ಏನು? ಅದೃಷ್ಟವಶಾತ್, ನಾವು ಈ ಕುಂಟೆಯ ಮೇಲೆ ಎಂದಿಗೂ ಹೆಜ್ಜೆ ಹಾಕಲಿಲ್ಲ, ಆದರೆ ಮತ್ತೆ, ನಾವು ಇನ್ನೂ ಕಾಯ್ದಿರಿಸಬೇಕಾಗಿದೆ ಎಂದು ನಾವು ಏಕೆ ಭಾವಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ಮುಂದೆ ಒಂದು ಕಥೆಯನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಇಲ್ಲಿ ನಾವು ಮುಂಚಿತವಾಗಿ ನಮಗಾಗಿ ಸ್ಟ್ರಾಗಳನ್ನು ಹಾಕಿದ್ದೇವೆ. ದಿನಕ್ಕೆ ಹಲವಾರು ಬಾರಿ ನಾವು ಮಾರ್ಗ 53 ರಲ್ಲಿ ಹೊಂದಿರುವ ಎಲ್ಲಾ ವಲಯಗಳ ಸಂಪೂರ್ಣ ಇಳಿಸುವಿಕೆಯನ್ನು ಮಾಡುತ್ತೇವೆ. Amazon ನ API ನಿಮಗೆ ಅವುಗಳನ್ನು JSON ನಲ್ಲಿ ಸುಲಭವಾಗಿ ಕಳುಹಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು ನಾವು ಹಲವಾರು ಬ್ಯಾಕ್ಅಪ್ ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅಲ್ಲಿ ನಾವು ಅದನ್ನು ಪರಿವರ್ತಿಸುತ್ತೇವೆ, ಅದನ್ನು ಕಾನ್ಫಿಗ್‌ಗಳ ರೂಪದಲ್ಲಿ ಅಪ್‌ಲೋಡ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ಬ್ಯಾಕಪ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಏನಾದರೂ ಸಂಭವಿಸಿದಲ್ಲಿ, DNS ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ನಾವು ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿಯೋಜಿಸಬಹುದು.
ಎರಡನೇ "ಆದರೆ": ಈ ಚಿತ್ರದಲ್ಲಿ ಏನನ್ನು ಇನ್ನೂ ಕಾಯ್ದಿರಿಸಲಾಗಿಲ್ಲ? ಬ್ಯಾಲೆನ್ಸರ್ ಸ್ವತಃ! ಪ್ರದೇಶದ ಮೂಲಕ ನಮ್ಮ ಗ್ರಾಹಕರ ವಿತರಣೆಯನ್ನು ತುಂಬಾ ಸರಳಗೊಳಿಸಲಾಗಿದೆ. ನಾವು bitrix24.ru, bitrix24.com, .de ಡೊಮೇನ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಈಗ 13 ವಿಭಿನ್ನವಾದವುಗಳಿವೆ, ಅವುಗಳು ವಿವಿಧ ವಲಯಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ನಾವು ಈ ಕೆಳಗಿನವುಗಳಿಗೆ ಬಂದಿದ್ದೇವೆ: ಪ್ರತಿಯೊಂದು ಪ್ರದೇಶವು ತನ್ನದೇ ಆದ ಸಮತೋಲನವನ್ನು ಹೊಂದಿದೆ. ಇದು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಗರಿಷ್ಠ ಲೋಡ್ ಎಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿ, ಪ್ರದೇಶಗಳಾದ್ಯಂತ ವಿತರಿಸಲು ಇದು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿರುತ್ತದೆ. ಇದು ಒಂದೇ ಬ್ಯಾಲೆನ್ಸರ್ ಮಟ್ಟದಲ್ಲಿ ವಿಫಲವಾದರೆ, ಅದನ್ನು ಸರಳವಾಗಿ ಸೇವೆಯಿಂದ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು dns ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ. ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳ ಗುಂಪಿನಲ್ಲಿ ಕೆಲವು ಸಮಸ್ಯೆಗಳಿದ್ದರೆ, ನಂತರ ಅವುಗಳನ್ನು ಇತರ ಸೈಟ್‌ಗಳಲ್ಲಿ ಬ್ಯಾಕಪ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ನಡುವೆ ಬದಲಾಯಿಸುವುದನ್ನು ಅದೇ ಮಾರ್ಗವನ್ನು ಬಳಸಿ ಮಾಡಲಾಗುತ್ತದೆ53, ಏಕೆಂದರೆ ಕಡಿಮೆ ಟಿಟಿಎಲ್‌ನಿಂದಾಗಿ, ಸ್ವಿಚಿಂಗ್ ಗರಿಷ್ಠ 2, 3, 5 ನಿಮಿಷಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ .
ಮೂರನೇ "ಆದರೆ": ಇನ್ನೂ ಏನು ಕಾಯ್ದಿರಿಸಿಲ್ಲ? S3, ಸರಿ. ನಾವು ಬಳಕೆದಾರರಿಗಾಗಿ ಸಂಗ್ರಹಿಸುವ ಫೈಲ್‌ಗಳನ್ನು s3 ನಲ್ಲಿ ಇರಿಸಿದಾಗ, ಅದು ರಕ್ಷಾಕವಚ-ಚುಚ್ಚುವಿಕೆ ಎಂದು ನಾವು ಪ್ರಾಮಾಣಿಕವಾಗಿ ನಂಬಿದ್ದೇವೆ ಮತ್ತು ಅಲ್ಲಿ ಏನನ್ನೂ ಕಾಯ್ದಿರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಆದರೆ ಇತಿಹಾಸವು ವಿಭಿನ್ನವಾಗಿ ನಡೆಯುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, Amazon S3 ಅನ್ನು ಮೂಲಭೂತ ಸೇವೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅಮೆಜಾನ್ ಸ್ವತಃ S3 ಅನ್ನು ಯಂತ್ರ ಚಿತ್ರಗಳು, ಸಂರಚನೆಗಳು, AMI ಚಿತ್ರಗಳು, ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಳಸುತ್ತದೆ... ಮತ್ತು s3 ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ಈ 7 ವರ್ಷಗಳಲ್ಲಿ ಒಮ್ಮೆ ಸಂಭವಿಸಿದಂತೆ, ನಾವು ಬಳಸುತ್ತಿರುವವರೆಗೆ bitrix24, ಇದು ಫ್ಯಾನ್‌ನಂತೆ ಅದನ್ನು ಅನುಸರಿಸುತ್ತದೆ - ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಅಸಮರ್ಥತೆ, API ವೈಫಲ್ಯ, ಇತ್ಯಾದಿ.
ಮತ್ತು S3 ಬೀಳಬಹುದು - ಅದು ಒಮ್ಮೆ ಸಂಭವಿಸಿತು. ಆದ್ದರಿಂದ, ನಾವು ಈ ಕೆಳಗಿನ ಯೋಜನೆಗೆ ಬಂದಿದ್ದೇವೆ: ಕೆಲವು ವರ್ಷಗಳ ಹಿಂದೆ ರಷ್ಯಾದಲ್ಲಿ ಯಾವುದೇ ಗಂಭೀರವಾದ ಸಾರ್ವಜನಿಕ ವಸ್ತು ಸಂಗ್ರಹಣಾ ಸೌಲಭ್ಯಗಳು ಇರಲಿಲ್ಲ, ಮತ್ತು ನಮ್ಮದೇ ಆದದನ್ನು ಮಾಡುವ ಆಯ್ಕೆಯನ್ನು ನಾವು ಪರಿಗಣಿಸಿದ್ದೇವೆ ... ಅದೃಷ್ಟವಶಾತ್, ನಾವು ಇದನ್ನು ಮಾಡಲು ಪ್ರಾರಂಭಿಸಲಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ನಾವು ಹೊಂದಿಲ್ಲದ ಪರಿಣತಿಯನ್ನು ಅಗೆದು ಹಾಕಿದ್ದೇವೆ ಮತ್ತು ಬಹುಶಃ ಗೊಂದಲಕ್ಕೊಳಗಾಗಬಹುದು. ಈಗ Mail.ru s3-ಹೊಂದಾಣಿಕೆಯ ಸಂಗ್ರಹಣೆಯನ್ನು ಹೊಂದಿದೆ, Yandex ಅದನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಹಲವಾರು ಇತರ ಪೂರೈಕೆದಾರರು ಅದನ್ನು ಹೊಂದಿದ್ದಾರೆ. ನಾವು ಅಂತಿಮವಾಗಿ, ಮೊದಲನೆಯದಾಗಿ, ಬ್ಯಾಕ್ಅಪ್ ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ಸ್ಥಳೀಯ ಪ್ರತಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಲು ಬಯಸುತ್ತೇವೆ ಎಂಬ ಕಲ್ಪನೆಗೆ ನಾವು ಬಂದಿದ್ದೇವೆ. ರಷ್ಯಾದ ಪ್ರದೇಶಕ್ಕೆ ನಿರ್ದಿಷ್ಟವಾಗಿ, ನಾವು Mail.ru ಹಾಟ್‌ಬಾಕ್ಸ್ ಸೇವೆಯನ್ನು ಬಳಸುತ್ತೇವೆ, ಇದು s3 ನೊಂದಿಗೆ API ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ನ ಒಳಗಿನ ಕೋಡ್‌ಗೆ ನಮಗೆ ಯಾವುದೇ ಪ್ರಮುಖ ಮಾರ್ಪಾಡುಗಳ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ನಾವು ಈ ಕೆಳಗಿನ ಕಾರ್ಯವಿಧಾನವನ್ನು ಮಾಡಿದ್ದೇವೆ: s3 ನಲ್ಲಿ ವಸ್ತುಗಳ ರಚನೆ/ಅಳಿಸುವಿಕೆಯನ್ನು ಪ್ರಚೋದಿಸುವ ಟ್ರಿಗ್ಗರ್‌ಗಳಿವೆ, Amazon Lambda ಎಂಬ ಸೇವೆಯನ್ನು ಹೊಂದಿದೆ - ಇದು ಕೋಡ್‌ನ ಸರ್ವರ್‌ಲೆಸ್ ಲಾಂಚ್ ಆಗಿದೆ ಕೆಲವು ಪ್ರಚೋದಕಗಳನ್ನು ಪ್ರಚೋದಿಸಿದಾಗ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ.
ನಾವು ಅದನ್ನು ಸರಳವಾಗಿ ಮಾಡಿದ್ದೇವೆ: ನಮ್ಮ ಟ್ರಿಗರ್ ಬೆಂಕಿಯಾದರೆ, ನಾವು Mail.ru ಸಂಗ್ರಹಣೆಗೆ ವಸ್ತುವನ್ನು ನಕಲಿಸುವ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ. ಡೇಟಾದ ಸ್ಥಳೀಯ ನಕಲುಗಳೊಂದಿಗೆ ಕೆಲಸವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಾರಂಭಿಸಲು, ನಮಗೆ ರಿವರ್ಸ್ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಕೂಡ ಬೇಕಾಗುತ್ತದೆ, ಇದರಿಂದಾಗಿ ರಷ್ಯಾದ ವಿಭಾಗದಲ್ಲಿರುವ ಗ್ರಾಹಕರು ಅವರಿಗೆ ಹತ್ತಿರವಿರುವ ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಮೇಲ್ ತನ್ನ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಟ್ರಿಗ್ಗರ್‌ಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಿದೆ - ಮೂಲಸೌಕರ್ಯ ಮಟ್ಟದಲ್ಲಿ ರಿವರ್ಸ್ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಆದರೆ ಇದೀಗ ನಾವು ಇದನ್ನು ನಮ್ಮದೇ ಕೋಡ್‌ನ ಮಟ್ಟದಲ್ಲಿ ಮಾಡುತ್ತಿದ್ದೇವೆ. ಕ್ಲೈಂಟ್ ಫೈಲ್ ಅನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿರುವುದನ್ನು ನಾವು ನೋಡಿದರೆ, ಕೋಡ್ ಮಟ್ಟದಲ್ಲಿ ನಾವು ಈವೆಂಟ್ ಅನ್ನು ಸರದಿಯಲ್ಲಿ ಇರಿಸುತ್ತೇವೆ, ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ರಿವರ್ಸ್ ರೆಪ್ಲಿಕೇಶನ್ ಮಾಡುತ್ತೇವೆ. ಅದು ಏಕೆ ಕೆಟ್ಟದು: ನಮ್ಮ ಉತ್ಪನ್ನದ ಹೊರಗೆ ನಮ್ಮ ವಸ್ತುಗಳೊಂದಿಗೆ ನಾವು ಕೆಲವು ರೀತಿಯ ಕೆಲಸವನ್ನು ಮಾಡಿದರೆ, ಅಂದರೆ, ಕೆಲವು ಬಾಹ್ಯ ವಿಧಾನಗಳಿಂದ, ನಾವು ಅದನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ಕೊನೆಯವರೆಗೂ ಕಾಯುತ್ತೇವೆ, ಶೇಖರಣಾ ಮಟ್ಟದಲ್ಲಿ ಟ್ರಿಗ್ಗರ್‌ಗಳು ಕಾಣಿಸಿಕೊಂಡಾಗ, ನಾವು ಕೋಡ್ ಅನ್ನು ಎಲ್ಲಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಿದರೂ, ನಮಗೆ ಬಂದ ವಸ್ತುವನ್ನು ಇನ್ನೊಂದು ದಿಕ್ಕಿನಲ್ಲಿ ನಕಲಿಸಲಾಗುತ್ತದೆ.
ಕೋಡ್ ಮಟ್ಟದಲ್ಲಿ, ನಾವು ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಎರಡೂ ಸಂಗ್ರಹಣೆಗಳನ್ನು ನೋಂದಾಯಿಸುತ್ತೇವೆ: ಒಂದನ್ನು ಮುಖ್ಯವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಇನ್ನೊಂದನ್ನು ಬ್ಯಾಕಪ್ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದ್ದರೆ, ನಮಗೆ ಹತ್ತಿರವಿರುವ ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ನಾವು ಕೆಲಸ ಮಾಡುತ್ತೇವೆ: ಅಂದರೆ, ಅಮೆಜಾನ್‌ನಲ್ಲಿರುವ ನಮ್ಮ ಗ್ರಾಹಕರು, ಅವರು S3 ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ರಷ್ಯಾದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವವರು ಹಾಟ್‌ಬಾಕ್ಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಪ್ರಚೋದಿಸಿದರೆ, ವೈಫಲ್ಯವನ್ನು ಸಂಪರ್ಕಿಸಬೇಕು ಮತ್ತು ನಾವು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಮತ್ತೊಂದು ಸಂಗ್ರಹಣೆಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ. ನಾವು ಈ ಪೆಟ್ಟಿಗೆಯನ್ನು ಪ್ರದೇಶದ ಮೂಲಕ ಸ್ವತಂತ್ರವಾಗಿ ಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಹಿಂದಕ್ಕೆ ಮತ್ತು ಮುಂದಕ್ಕೆ ಬದಲಾಯಿಸಬಹುದು. ನಾವು ಇದನ್ನು ಇನ್ನೂ ಆಚರಣೆಯಲ್ಲಿ ಬಳಸಿಲ್ಲ, ಆದರೆ ನಾವು ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸಿದ್ದೇವೆ ಮತ್ತು ಒಂದು ದಿನ ನಮಗೆ ಈ ಸ್ವಿಚ್ ಅಗತ್ಯವಿದೆ ಮತ್ತು ಸೂಕ್ತವಾಗಿ ಬರುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ. ಇದು ಈಗಾಗಲೇ ಒಮ್ಮೆ ಸಂಭವಿಸಿದೆ.
ಓಹ್, ಮತ್ತು ಅಮೆಜಾನ್ ಓಡಿಹೋಯಿತು ...
ಈ ಏಪ್ರಿಲ್ ರಷ್ಯಾದಲ್ಲಿ ಟೆಲಿಗ್ರಾಮ್ ನಿರ್ಬಂಧಿಸುವಿಕೆಯ ಪ್ರಾರಂಭದ ವಾರ್ಷಿಕೋತ್ಸವವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಇದರ ಅಡಿಯಲ್ಲಿ ಬೀಳುವ ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುವ ಪೂರೈಕೆದಾರರು ಅಮೆಜಾನ್. ಮತ್ತು, ದುರದೃಷ್ಟವಶಾತ್, ಇಡೀ ಪ್ರಪಂಚಕ್ಕಾಗಿ ಕೆಲಸ ಮಾಡಿದ ರಷ್ಯಾದ ಕಂಪನಿಗಳು ಹೆಚ್ಚು ಅನುಭವಿಸಿದವು.
ಕಂಪನಿಯು ಜಾಗತಿಕವಾಗಿದ್ದರೆ ಮತ್ತು ರಷ್ಯಾವು ಅದಕ್ಕೆ ಬಹಳ ಸಣ್ಣ ವಿಭಾಗವಾಗಿದ್ದರೆ, 3-5% - ಅಲ್ಲದೆ, ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು, ನೀವು ಅವುಗಳನ್ನು ತ್ಯಾಗ ಮಾಡಬಹುದು.
ಇದು ಸಂಪೂರ್ಣವಾಗಿ ರಷ್ಯಾದ ಕಂಪನಿಯಾಗಿದ್ದರೆ - ಇದು ಸ್ಥಳೀಯವಾಗಿ ನೆಲೆಗೊಂಡಿರಬೇಕು ಎಂದು ನನಗೆ ಖಾತ್ರಿಯಿದೆ - ಅಲ್ಲದೆ, ಇದು ಬಳಕೆದಾರರಿಗೆ ಸರಳವಾಗಿ ಅನುಕೂಲಕರವಾಗಿರುತ್ತದೆ, ಆರಾಮದಾಯಕವಾಗಿರುತ್ತದೆ ಮತ್ತು ಕಡಿಮೆ ಅಪಾಯಗಳು ಇರುತ್ತವೆ.
ಇದು ಜಾಗತಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕಂಪನಿಯಾಗಿದ್ದರೆ ಮತ್ತು ರಷ್ಯಾದಿಂದ ಮತ್ತು ಪ್ರಪಂಚದಾದ್ಯಂತ ಎಲ್ಲೋ ಸರಿಸುಮಾರು ಸಮಾನ ಸಂಖ್ಯೆಯ ಗ್ರಾಹಕರನ್ನು ಹೊಂದಿದ್ದರೆ ಏನು? ವಿಭಾಗಗಳ ಸಂಪರ್ಕವು ಮುಖ್ಯವಾಗಿದೆ, ಮತ್ತು ಅವರು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ಪರಸ್ಪರ ಕೆಲಸ ಮಾಡಬೇಕು.
ಮಾರ್ಚ್ 2018 ರ ಕೊನೆಯಲ್ಲಿ, ರೋಸ್ಕೊಮ್ನಾಡ್ಜೋರ್ ಅವರು ದೊಡ್ಡ ಆಪರೇಟರ್‌ಗಳಿಗೆ ಪತ್ರವನ್ನು ಕಳುಹಿಸಿದ್ದಾರೆ, ಅವರು ನಿರ್ಬಂಧಿಸಲು ಹಲವಾರು ಮಿಲಿಯನ್ ಅಮೆಜಾನ್ ಐಪಿಗಳನ್ನು ನಿರ್ಬಂಧಿಸಲು ಯೋಜಿಸಿದ್ದಾರೆ ... ಝೆಲೋ ಮೆಸೆಂಜರ್. ಇದೇ ಪೂರೈಕೆದಾರರಿಗೆ ಧನ್ಯವಾದಗಳು - ಅವರು ಎಲ್ಲರಿಗೂ ಪತ್ರವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಸೋರಿಕೆ ಮಾಡಿದರು ಮತ್ತು ಅಮೆಜಾನ್‌ನೊಂದಿಗಿನ ಸಂಪರ್ಕವು ಕುಸಿಯಬಹುದು ಎಂಬ ತಿಳುವಳಿಕೆ ಇತ್ತು. ಇದು ಶುಕ್ರವಾರ, ನಾವು servers.ru ನಿಂದ ನಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳಿಗೆ ಈ ಪದಗಳೊಂದಿಗೆ ಭಯಭೀತರಾಗಿ ಓಡಿದೆವು: "ಸ್ನೇಹಿತರೇ, ನಮಗೆ ಹಲವಾರು ಸರ್ವರ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ ಅದು ರಷ್ಯಾದಲ್ಲಿ ಅಲ್ಲ, ಅಮೆಜಾನ್‌ನಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ, ಉದಾಹರಣೆಗೆ, ಎಲ್ಲೋ ಆಮ್ಸ್ಟರ್‌ಡ್ಯಾಮ್‌ನಲ್ಲಿದೆ" ನಾವು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪ್ರಭಾವ ಬೀರದ ಕೆಲವು ಅಂತಿಮ ಬಿಂದುಗಳಿಗೆ ನಮ್ಮದೇ ಆದ VPN ಮತ್ತು ಪ್ರಾಕ್ಸಿಯನ್ನು ಹೇಗಾದರೂ ಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಮಾಡಲು, ಉದಾಹರಣೆಗೆ ಅದೇ s3 ನ ಎಂಡ್‌ಪಾಂಟ್‌ಗಳು - ನಾವು ಹೊಸ ಸೇವೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಮತ್ತು ಬೇರೆಯದನ್ನು ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ip, ನಾವು ನೀವು ಇನ್ನೂ ಅಲ್ಲಿಗೆ ಹೋಗಬೇಕಾಗಿದೆ. ಕೆಲವೇ ದಿನಗಳಲ್ಲಿ, ನಾವು ಈ ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ, ಅವುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ನಿರ್ಬಂಧಿಸುವಿಕೆಯು ಪ್ರಾರಂಭವಾದ ಕ್ಷಣಕ್ಕೆ ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ. ಆರ್‌ಕೆಎನ್ ಗಡಿಬಿಡಿ ಮತ್ತು ಗಾಬರಿಯನ್ನು ನೋಡುತ್ತಾ ಹೇಳಿದರು: "ಇಲ್ಲ, ನಾವು ಈಗ ಏನನ್ನೂ ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ." (ಆದರೆ ಇದು ನಿಖರವಾಗಿ ಟೆಲಿಗ್ರಾಮ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಲು ಪ್ರಾರಂಭಿಸಿದ ಕ್ಷಣದವರೆಗೆ.) ಬೈಪಾಸ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿಸಿ ಮತ್ತು ನಿರ್ಬಂಧಿಸುವಿಕೆಯನ್ನು ಪರಿಚಯಿಸಲಾಗಿಲ್ಲ ಎಂದು ಅರಿತುಕೊಂಡ ನಂತರ, ನಾವು ಸಂಪೂರ್ಣ ವಿಷಯವನ್ನು ವಿಂಗಡಿಸಲು ಪ್ರಾರಂಭಿಸಲಿಲ್ಲ. ಹೌದು, ಕೇವಲ ಸಂದರ್ಭದಲ್ಲಿ.
ಮತ್ತು 2019 ರಲ್ಲಿ, ನಾವು ಇನ್ನೂ ನಿರ್ಬಂಧಿಸುವ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತೇವೆ. ನಾನು ನಿನ್ನೆ ರಾತ್ರಿ ನೋಡಿದೆ: ಸುಮಾರು ಒಂದು ಮಿಲಿಯನ್ ಐಪಿಗಳನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ. ನಿಜ, ಅಮೆಜಾನ್ ಬಹುತೇಕ ಸಂಪೂರ್ಣವಾಗಿ ಅನಿರ್ಬಂಧಿತವಾಗಿದೆ, ಅದರ ಉತ್ತುಂಗದಲ್ಲಿ ಅದು 20 ಮಿಲಿಯನ್ ವಿಳಾಸಗಳನ್ನು ತಲುಪಿತು ... ಸಾಮಾನ್ಯವಾಗಿ, ವಾಸ್ತವವೆಂದರೆ ಸುಸಂಬದ್ಧತೆ, ಉತ್ತಮ ಸುಸಂಬದ್ಧತೆ ಇಲ್ಲದಿರಬಹುದು. ಇದ್ದಕ್ಕಿದ್ದಂತೆ. ತಾಂತ್ರಿಕ ಕಾರಣಗಳಿಗಾಗಿ ಇದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿರಬಹುದು - ಬೆಂಕಿ, ಅಗೆಯುವ ಯಂತ್ರಗಳು, ಎಲ್ಲವೂ. ಅಥವಾ, ನಾವು ನೋಡಿದಂತೆ, ಸಂಪೂರ್ಣವಾಗಿ ತಾಂತ್ರಿಕವಾಗಿಲ್ಲ. ಆದ್ದರಿಂದ, ಯಾರಾದರೂ ದೊಡ್ಡವರು ಮತ್ತು ದೊಡ್ಡವರು, ತಮ್ಮದೇ ಆದ ASಗಳೊಂದಿಗೆ, ಬಹುಶಃ ಇದನ್ನು ಇತರ ರೀತಿಯಲ್ಲಿ ನಿರ್ವಹಿಸಬಹುದು - ನೇರ ಸಂಪರ್ಕ ಮತ್ತು ಇತರ ವಿಷಯಗಳು ಈಗಾಗಲೇ l2 ಮಟ್ಟದಲ್ಲಿವೆ. ಆದರೆ ನಮ್ಮ ಅಥವಾ ಇನ್ನೂ ಚಿಕ್ಕದಾಗಿರುವಂತಹ ಸರಳ ಆವೃತ್ತಿಯಲ್ಲಿ, ನೀವು ಬೇರೆಡೆ ಬೆಳೆದ ಸರ್ವರ್‌ಗಳ ಮಟ್ಟದಲ್ಲಿ ಪುನರುಕ್ತಿ ಹೊಂದಬಹುದು, ಮುಂಚಿತವಾಗಿ ವಿಪಿಎನ್, ಪ್ರಾಕ್ಸಿ, ಆ ವಿಭಾಗಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಬದಲಾಯಿಸುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಅದು ನಿಮ್ಮ ಸಂಪರ್ಕಕ್ಕೆ ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಇದು ನಮಗೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಸೂಕ್ತವಾಗಿ ಬಂದಿತು, ಅಮೆಜಾನ್‌ನ ತಡೆಗಟ್ಟುವಿಕೆ ಪ್ರಾರಂಭವಾದಾಗ, ನಾವು ಅವುಗಳ ಮೂಲಕ S3 ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮಾತ್ರ ಅನುಮತಿಸಿದ್ದೇವೆ, ಆದರೆ ಕ್ರಮೇಣ ಇದನ್ನು ಪರಿಹರಿಸಲಾಯಿತು.
ಸಂಪೂರ್ಣ ಪೂರೈಕೆದಾರರನ್ನು ಕಾಯ್ದಿರಿಸುವುದು ಹೇಗೆ?
ಪ್ರಸ್ತುತ, ಸಂಪೂರ್ಣ ಅಮೆಜಾನ್ ಕೆಳಗೆ ಹೋದರೆ ನಾವು ಯಾವುದೇ ಸನ್ನಿವೇಶವನ್ನು ಹೊಂದಿಲ್ಲ. ನಾವು ರಷ್ಯಾಕ್ಕೆ ಇದೇ ರೀತಿಯ ಸನ್ನಿವೇಶವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ರಷ್ಯಾದಲ್ಲಿ, ನಾವು ಒಬ್ಬ ಪೂರೈಕೆದಾರರಿಂದ ಹೋಸ್ಟ್ ಮಾಡಿದ್ದೇವೆ, ಅವರಲ್ಲಿ ನಾವು ಹಲವಾರು ಸೈಟ್‌ಗಳನ್ನು ಹೊಂದಲು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ. ಮತ್ತು ಒಂದು ವರ್ಷದ ಹಿಂದೆ ನಾವು ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದ್ದೇವೆ: ಇವು ಎರಡು ಡೇಟಾ ಕೇಂದ್ರಗಳಾಗಿದ್ದರೂ, ಪೂರೈಕೆದಾರರ ನೆಟ್‌ವರ್ಕ್ ಕಾನ್ಫಿಗರೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ಈಗಾಗಲೇ ಸಮಸ್ಯೆಗಳಿರಬಹುದು ಅದು ಇನ್ನೂ ಎರಡೂ ಡೇಟಾ ಕೇಂದ್ರಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಮತ್ತು ನಾವು ಎರಡೂ ಸೈಟ್‌ಗಳಲ್ಲಿ ಅಲಭ್ಯರಾಗಬಹುದು. ಸಹಜವಾಗಿಯೇ ಅದು ಸಂಭವಿಸಿದೆ. ನಾವು ಒಳಗೆ ವಾಸ್ತುಶೈಲಿಯನ್ನು ಮರುಪರಿಶೀಲಿಸುವುದನ್ನು ಕೊನೆಗೊಳಿಸಿದ್ದೇವೆ. ಇದು ಹೆಚ್ಚು ಬದಲಾಗಿಲ್ಲ, ಆದರೆ ರಷ್ಯಾಕ್ಕೆ ನಾವು ಈಗ ಎರಡು ಸೈಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದು ಒಂದೇ ಪೂರೈಕೆದಾರರಿಂದ ಅಲ್ಲ, ಆದರೆ ಎರಡು ವಿಭಿನ್ನವಾದವುಗಳಿಂದ. ಒಂದು ವಿಫಲವಾದರೆ, ನಾವು ಇನ್ನೊಂದಕ್ಕೆ ಬದಲಾಯಿಸಬಹುದು.
ಕಾಲ್ಪನಿಕವಾಗಿ, ಅಮೆಜಾನ್‌ಗಾಗಿ ನಾವು ಮತ್ತೊಂದು ಪೂರೈಕೆದಾರರ ಮಟ್ಟದಲ್ಲಿ ಮೀಸಲಾತಿಯ ಸಾಧ್ಯತೆಯನ್ನು ಪರಿಗಣಿಸುತ್ತಿದ್ದೇವೆ; ಬಹುಶಃ ಗೂಗಲ್, ಬಹುಶಃ ಬೇರೆ ಯಾರೋ ... ಆದರೆ ಇಲ್ಲಿಯವರೆಗೆ ನಾವು ಆಚರಣೆಯಲ್ಲಿ ಗಮನಿಸಿದ್ದೇವೆ, ಅಮೆಜಾನ್ ಒಂದು ಲಭ್ಯತೆಯ ವಲಯದ ಮಟ್ಟದಲ್ಲಿ ಅಪಘಾತಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಇಡೀ ಪ್ರದೇಶದ ಮಟ್ಟದಲ್ಲಿ ಅಪಘಾತಗಳು ಅಪರೂಪ. ಆದ್ದರಿಂದ, ನಾವು ಸೈದ್ಧಾಂತಿಕವಾಗಿ "ಅಮೆಜಾನ್ ಅಲ್ಲ ಅಮೆಜಾನ್" ಕಾಯ್ದಿರಿಸುವಿಕೆಯನ್ನು ಮಾಡಬಹುದೆಂಬ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದು ಇನ್ನೂ ಅಲ್ಲ.
ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಬಗ್ಗೆ ಕೆಲವು ಪದಗಳು
ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಯಾವಾಗಲೂ ಅಗತ್ಯವಿದೆಯೇ? ಇಲ್ಲಿ ಡನ್ನಿಂಗ್-ಕ್ರುಗರ್ ಪರಿಣಾಮವನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುವುದು ಸೂಕ್ತವಾಗಿದೆ. "x" ಅಕ್ಷದಲ್ಲಿ ನಾವು ಪಡೆಯುವ ನಮ್ಮ ಜ್ಞಾನ ಮತ್ತು ಅನುಭವವಾಗಿದೆ ಮತ್ತು "y" ಅಕ್ಷದಲ್ಲಿ ನಮ್ಮ ಕ್ರಿಯೆಗಳಲ್ಲಿ ವಿಶ್ವಾಸವಿದೆ. ಮೊದಲಿಗೆ ನಮಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ ಮತ್ತು ಖಚಿತವಾಗಿಲ್ಲ. ನಂತರ ನಾವು ಸ್ವಲ್ಪ ತಿಳಿದಿರುತ್ತೇವೆ ಮತ್ತು ಮೆಗಾ-ಆತ್ಮವಿಶ್ವಾಸಿಯಾಗುತ್ತೇವೆ - ಇದು "ಮೂರ್ಖತನದ ಶಿಖರ" ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ, ಇದನ್ನು "ಬುದ್ಧಿಮಾಂದ್ಯತೆ ಮತ್ತು ಧೈರ್ಯ" ಚಿತ್ರದಿಂದ ಚೆನ್ನಾಗಿ ವಿವರಿಸಲಾಗಿದೆ. ನಂತರ ನಾವು ಸ್ವಲ್ಪ ಕಲಿತು ಯುದ್ಧಕ್ಕೆ ಸಿದ್ಧರಾಗಿದ್ದೇವೆ. ನಂತರ ನಾವು ಕೆಲವು ಮೆಗಾ-ಗಂಭೀರ ತಪ್ಪುಗಳ ಮೇಲೆ ಹೆಜ್ಜೆ ಹಾಕುತ್ತೇವೆ ಮತ್ತು ಹತಾಶೆಯ ಕಣಿವೆಯಲ್ಲಿ ನಮ್ಮನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ, ನಾವು ಏನನ್ನಾದರೂ ತಿಳಿದಿರುವಾಗ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ನಮಗೆ ಹೆಚ್ಚು ತಿಳಿದಿಲ್ಲ. ನಂತರ, ನಾವು ಅನುಭವವನ್ನು ಪಡೆದಂತೆ, ನಾವು ಹೆಚ್ಚು ಆತ್ಮವಿಶ್ವಾಸವನ್ನು ಹೊಂದುತ್ತೇವೆ.
ಕೆಲವು ಅಪಘಾತಗಳಿಗೆ ವಿವಿಧ ಸ್ವಯಂಚಾಲಿತ ಸ್ವಿಚ್‌ಗಳ ಕುರಿತು ನಮ್ಮ ತರ್ಕವನ್ನು ಈ ಗ್ರಾಫ್‌ನಿಂದ ಚೆನ್ನಾಗಿ ವಿವರಿಸಲಾಗಿದೆ. ನಾವು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ - ಏನನ್ನೂ ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ನಮಗೆ ತಿಳಿದಿರಲಿಲ್ಲ, ಬಹುತೇಕ ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ಕೈಯಿಂದ ಮಾಡಲಾಗುತ್ತದೆ. ನಂತರ ನಾವು ಎಲ್ಲದಕ್ಕೂ ಯಾಂತ್ರೀಕರಣವನ್ನು ಲಗತ್ತಿಸಬಹುದು ಮತ್ತು ಶಾಂತಿಯುತವಾಗಿ ಮಲಗಬಹುದು ಎಂದು ನಾವು ಅರಿತುಕೊಂಡೆವು. ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನಾವು ಮೆಗಾ-ರೇಕ್‌ನಲ್ಲಿ ಹೆಜ್ಜೆ ಹಾಕುತ್ತೇವೆ: ತಪ್ಪು ಧನಾತ್ಮಕತೆಯನ್ನು ಪ್ರಚೋದಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ ನಾವು ಇದನ್ನು ಮಾಡಬಾರದೆಂದಾಗ ನಾವು ಸಂಚಾರವನ್ನು ಹಿಂದಕ್ಕೆ ಮತ್ತು ಮುಂದಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತೇವೆ. ಪರಿಣಾಮವಾಗಿ, ಪ್ರತಿಕೃತಿಯು ಒಡೆಯುತ್ತದೆ ಅಥವಾ ಇನ್ನೇನಾದರೂ - ಇದು ಹತಾಶೆಯ ಕಣಿವೆ. ತದನಂತರ ನಾವು ಎಲ್ಲವನ್ನೂ ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಸಂಪರ್ಕಿಸಬೇಕು ಎಂಬ ತಿಳುವಳಿಕೆಗೆ ಬರುತ್ತೇವೆ. ಅಂದರೆ, ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ಇದು ತಪ್ಪು ಎಚ್ಚರಿಕೆಗಳ ಸಾಧ್ಯತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದರೆ! ಪರಿಣಾಮಗಳು ವಿನಾಶಕಾರಿಯಾಗಿದ್ದರೆ, ಅದನ್ನು ಕರ್ತವ್ಯ ಶಿಫ್ಟ್‌ಗೆ, ಕರ್ತವ್ಯದಲ್ಲಿರುವ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಬಿಡುವುದು ಉತ್ತಮ, ಅವರು ನಿಜವಾಗಿಯೂ ಅಪಘಾತವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅಗತ್ಯ ಕ್ರಮಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸುತ್ತಾರೆ ...
ತೀರ್ಮಾನಕ್ಕೆ
7 ವರ್ಷಗಳ ಅವಧಿಯಲ್ಲಿ, ಏನಾದರೂ ಬಿದ್ದಾಗ, ಪ್ಯಾನಿಕ್-ಪ್ಯಾನಿಕ್ ಇತ್ತು ಎಂಬ ಅಂಶದಿಂದ, ಸಮಸ್ಯೆಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, ಕಾರ್ಯಗಳು ಮಾತ್ರ ಇವೆ, ಅವುಗಳನ್ನು ಪರಿಹರಿಸಬೇಕು ಮತ್ತು ಪರಿಹರಿಸಬಹುದು ಎಂಬ ತಿಳುವಳಿಕೆಗೆ ನಾವು ಹೋದೆವು. ನೀವು ಸೇವೆಯನ್ನು ನಿರ್ಮಿಸುತ್ತಿರುವಾಗ, ಅದನ್ನು ಮೇಲಿನಿಂದ ನೋಡಿ, ಸಂಭವಿಸಬಹುದಾದ ಎಲ್ಲಾ ಅಪಾಯಗಳನ್ನು ನಿರ್ಣಯಿಸಿ. ನೀವು ಈಗಿನಿಂದಲೇ ಅವರನ್ನು ನೋಡಿದರೆ, ನಂತರ ಪುನರಾವರ್ತನೆಯನ್ನು ಮುಂಚಿತವಾಗಿ ಒದಗಿಸಿ ಮತ್ತು ದೋಷ-ಸಹಿಷ್ಣು ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿರ್ಮಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಒದಗಿಸಿ, ಏಕೆಂದರೆ ವಿಫಲಗೊಳ್ಳುವ ಮತ್ತು ಸೇವೆಯ ಅಸಮರ್ಥತೆಗೆ ಕಾರಣವಾಗುವ ಯಾವುದೇ ಅಂಶವು ಖಂಡಿತವಾಗಿಯೂ ಹಾಗೆ ಮಾಡುತ್ತದೆ. ಮತ್ತು ಕೆಲವು ಮೂಲಸೌಕರ್ಯ ಅಂಶಗಳು ಖಂಡಿತವಾಗಿಯೂ ವಿಫಲಗೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ನಿಮಗೆ ತೋರುತ್ತಿದ್ದರೂ ಸಹ - ಉದಾಹರಣೆಗೆ s3, ಇನ್ನೂ ಅವರು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ. ಮತ್ತು ಕನಿಷ್ಠ ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಏನಾದರೂ ಸಂಭವಿಸಿದಲ್ಲಿ ನೀವು ಅವರೊಂದಿಗೆ ಏನು ಮಾಡುತ್ತೀರಿ ಎಂಬ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿರಿ. ಅಪಾಯ ನಿರ್ವಹಣೆ ಯೋಜನೆಯನ್ನು ಹೊಂದಿರಿ. ನೀವು ಎಲ್ಲವನ್ನೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಥವಾ ಹಸ್ತಚಾಲಿತವಾಗಿ ಮಾಡುವ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಿರುವಾಗ, ಅಪಾಯಗಳನ್ನು ನಿರ್ಣಯಿಸಿ: ಯಾಂತ್ರೀಕೃತಗೊಂಡವು ಎಲ್ಲವನ್ನೂ ಬದಲಾಯಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ ಏನಾಗುತ್ತದೆ - ಇದು ಅಪಘಾತಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಇನ್ನೂ ಕೆಟ್ಟ ಪರಿಸ್ಥಿತಿಗೆ ಕಾರಣವಾಗುವುದಿಲ್ಲವೇ? ಬಹುಶಃ ಎಲ್ಲೋ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಬಳಕೆ ಮತ್ತು ಕರ್ತವ್ಯದಲ್ಲಿರುವ ಎಂಜಿನಿಯರ್‌ನ ಪ್ರತಿಕ್ರಿಯೆಯ ನಡುವೆ ಸಮಂಜಸವಾದ ರಾಜಿ ಮಾಡಿಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ, ಅವರು ನೈಜ ಚಿತ್ರವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಸ್ಥಳದಲ್ಲೇ ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಬೇಕೇ ಅಥವಾ "ಹೌದು, ಆದರೆ ಈಗ ಅಲ್ಲ" ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ.
ಪರಿಪೂರ್ಣತೆ ಮತ್ತು ನೈಜ ಪ್ರಯತ್ನ, ಸಮಯ, ಹಣದ ನಡುವಿನ ಸಮಂಜಸವಾದ ರಾಜಿ ನೀವು ಅಂತಿಮವಾಗಿ ಹೊಂದಿರುವ ಯೋಜನೆಯಲ್ಲಿ ಖರ್ಚು ಮಾಡಬಹುದು.
ಈ ಪಠ್ಯವು ಸಮ್ಮೇಳನದಲ್ಲಿ ಅಲೆಕ್ಸಾಂಡರ್ ಡೆಮಿಡೋವ್ ಅವರ ವರದಿಯ ನವೀಕರಿಸಿದ ಮತ್ತು ವಿಸ್ತರಿತ ಆವೃತ್ತಿಯಾಗಿದೆ .
ಮೂಲ: www.habr.com