ಎಲ್ಲರಿಗೂ ನಮಸ್ಕಾರ, ನನ್ನ ಹೆಸರು ಅಲೆಕ್ಸಾಂಡರ್, ನಾನು CIAN ನಲ್ಲಿ ಎಂಜಿನಿಯರ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಆಡಳಿತ ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಪ್ರಕ್ರಿಯೆಗಳ ಯಾಂತ್ರೀಕರಣದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದೇನೆ. ಹಿಂದಿನ ಲೇಖನಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ, ನಾವು ದಿನಕ್ಕೆ 4 TB ಲಾಗ್‌ಗಳನ್ನು ಎಲ್ಲಿ ಪಡೆಯುತ್ತೇವೆ ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ಏನು ಮಾಡುತ್ತೇವೆ ಎಂದು ಹೇಳಲು ನಮ್ಮನ್ನು ಕೇಳಲಾಯಿತು. ಹೌದು, ನಾವು ಬಹಳಷ್ಟು ಲಾಗ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಪ್ರತ್ಯೇಕ ಮೂಲಸೌಕರ್ಯ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ, ಇದು ಸಮಸ್ಯೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪರಿಹರಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿರುವ ಡೇಟಾದ ಹರಿವಿನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನಾವು ಒಂದು ವರ್ಷದ ಅವಧಿಯಲ್ಲಿ ಅದನ್ನು ಹೇಗೆ ಅಳವಡಿಸಿಕೊಂಡಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ಮಾತನಾಡುತ್ತೇನೆ.
ನಾವು ಎಲ್ಲಿಂದ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ?
ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಲ್ಲಿ, cian.ru ನಲ್ಲಿನ ಲೋಡ್ ಬಹಳ ಬೇಗನೆ ಬೆಳೆದಿದೆ ಮತ್ತು 2018 ರ ಮೂರನೇ ತ್ರೈಮಾಸಿಕದಲ್ಲಿ, ಸಂಪನ್ಮೂಲ ದಟ್ಟಣೆಯು ತಿಂಗಳಿಗೆ 11.2 ಮಿಲಿಯನ್ ಅನನ್ಯ ಬಳಕೆದಾರರನ್ನು ತಲುಪಿದೆ. ಆ ಸಮಯದಲ್ಲಿ, ನಿರ್ಣಾಯಕ ಕ್ಷಣಗಳಲ್ಲಿ ನಾವು 40% ಲಾಗ್‌ಗಳನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ, ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಘಟನೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಎದುರಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಮತ್ತು ಅವುಗಳನ್ನು ಪರಿಹರಿಸಲು ಸಾಕಷ್ಟು ಸಮಯ ಮತ್ತು ಶ್ರಮವನ್ನು ವ್ಯಯಿಸಿದ್ದೇವೆ. ನಾವು ಆಗಾಗ್ಗೆ ಸಮಸ್ಯೆಯ ಕಾರಣವನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಅದು ಮರುಕಳಿಸುತ್ತದೆ. ಇದು ನರಕವಾಗಿತ್ತು ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಏನಾದರೂ ಮಾಡಬೇಕಾಗಿತ್ತು.
ಆ ಸಮಯದಲ್ಲಿ, ನಾವು ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರಮಾಣಿತ ಸೂಚ್ಯಂಕ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ElasticSearch ಆವೃತ್ತಿ 10 ನೊಂದಿಗೆ 5.5.2 ಡೇಟಾ ನೋಡ್ಗಳ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ. ಒಂದು ವರ್ಷದ ಹಿಂದೆ ಜನಪ್ರಿಯ ಮತ್ತು ಕೈಗೆಟುಕುವ ಪರಿಹಾರವಾಗಿ ಇದನ್ನು ಪರಿಚಯಿಸಲಾಯಿತು: ನಂತರ ಲಾಗ್ಗಳ ಹರಿವು ತುಂಬಾ ದೊಡ್ಡದಾಗಿರಲಿಲ್ಲ, ಪ್ರಮಾಣಿತವಲ್ಲದ ಸಂರಚನೆಗಳೊಂದಿಗೆ ಬರಲು ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ.
ಐದು ElasticSearch ಸಂಯೋಜಕಗಳಲ್ಲಿ ವಿವಿಧ ಪೋರ್ಟ್‌ಗಳಲ್ಲಿ ಒಳಬರುವ ಲಾಗ್ಗಳ ಸಂಸ್ಕರಣೆಯನ್ನು ಲಾಗ್‌ಸ್ಟಾಶ್ ಒದಗಿಸಿದೆ. ಒಂದು ಸೂಚ್ಯಂಕ, ಗಾತ್ರವನ್ನು ಲೆಕ್ಕಿಸದೆ, ಐದು ಚೂರುಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು. ಗಂಟೆಯ ಮತ್ತು ದೈನಂದಿನ ತಿರುಗುವಿಕೆಯನ್ನು ಆಯೋಜಿಸಲಾಗಿದೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ, ಪ್ರತಿ ಗಂಟೆಗೆ ಸುಮಾರು 100 ಹೊಸ ಚೂರುಗಳು ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡವು. ಹೆಚ್ಚಿನ ಲಾಗ್‌ಗಳು ಇಲ್ಲದಿದ್ದರೂ, ಕ್ಲಸ್ಟರ್ ಚೆನ್ನಾಗಿ ನಿಭಾಯಿಸಿದೆ ಮತ್ತು ಅದರ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಯಾರೂ ಗಮನ ಹರಿಸಲಿಲ್ಲ.
ತ್ವರಿತ ಬೆಳವಣಿಗೆಯ ಸವಾಲುಗಳು
ಎರಡು ಪ್ರಕ್ರಿಯೆಗಳು ಒಂದಕ್ಕೊಂದು ಅತಿಕ್ರಮಿಸಿದ ಕಾರಣ, ರಚಿಸಲಾದ ಲಾಗ್ಗಳ ಪರಿಮಾಣವು ಬಹಳ ಬೇಗನೆ ಬೆಳೆಯಿತು. ಒಂದೆಡೆ, ಸೇವೆಯ ಬಳಕೆದಾರರ ಸಂಖ್ಯೆ ಬೆಳೆಯಿತು. ಮತ್ತೊಂದೆಡೆ, ನಾವು C# ಮತ್ತು ಪೈಥಾನ್‌ನಲ್ಲಿ ನಮ್ಮ ಹಳೆಯ ಏಕಶಿಲೆಗಳನ್ನು ಗರಗಸುತ್ತಾ ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಸಕ್ರಿಯವಾಗಿ ಬದಲಾಯಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಏಕಶಿಲೆಯ ಭಾಗಗಳನ್ನು ಬದಲಿಸಿದ ಹಲವಾರು ಡಜನ್ ಹೊಸ ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳು ಮೂಲಸೌಕರ್ಯ ಕ್ಲಸ್ಟರ್‌ಗೆ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಿನ ಲಾಗ್‌ಗಳನ್ನು ರಚಿಸಿದವು.
ಕ್ಲಸ್ಟರ್ ಪ್ರಾಯೋಗಿಕವಾಗಿ ನಿರ್ವಹಿಸಲಾಗದ ಹಂತಕ್ಕೆ ನಮ್ಮನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡಿತು. ಲಾಗ್‌ಗಳು ಸೆಕೆಂಡಿಗೆ 20 ಸಾವಿರ ಸಂದೇಶಗಳ ದರದಲ್ಲಿ ಬರಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಆಗಾಗ್ಗೆ ಅನುಪಯುಕ್ತ ತಿರುಗುವಿಕೆಯು ಚೂರುಗಳ ಸಂಖ್ಯೆಯನ್ನು 6 ಸಾವಿರಕ್ಕೆ ಹೆಚ್ಚಿಸಿತು ಮತ್ತು ಪ್ರತಿ ನೋಡ್‌ಗೆ 600 ಕ್ಕೂ ಹೆಚ್ಚು ಚೂರುಗಳು ಇದ್ದವು.
ಇದು RAM ನ ಹಂಚಿಕೆಯಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಯಿತು, ಮತ್ತು ನೋಡ್ ಕ್ರ್ಯಾಶ್ ಮಾಡಿದಾಗ, ಎಲ್ಲಾ ಚೂರುಗಳು ಏಕಕಾಲದಲ್ಲಿ ಚಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು, ದಟ್ಟಣೆಯನ್ನು ಗುಣಿಸಿ ಮತ್ತು ಇತರ ನೋಡ್‌ಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತವೆ, ಇದು ಕ್ಲಸ್ಟರ್‌ಗೆ ಡೇಟಾವನ್ನು ಬರೆಯಲು ಅಸಾಧ್ಯವಾಯಿತು. ಮತ್ತು ಈ ಅವಧಿಯಲ್ಲಿ ನಾವು ದಾಖಲೆಗಳಿಲ್ಲದೆ ಉಳಿದಿದ್ದೇವೆ. ಮತ್ತು ಸರ್ವರ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆಯಿದ್ದರೆ, ನಾವು ಮೂಲತಃ ಕ್ಲಸ್ಟರ್‌ನ 1/10 ಅನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಣ್ಣ ಸೂಚ್ಯಂಕಗಳು ಸಂಕೀರ್ಣತೆಯನ್ನು ಸೇರಿಸಿದವು.
ಲಾಗ್‌ಗಳಿಲ್ಲದೆ, ಘಟನೆಯ ಕಾರಣಗಳು ನಮಗೆ ಅರ್ಥವಾಗಲಿಲ್ಲ ಮತ್ತು ಬೇಗ ಅಥವಾ ನಂತರ ಮತ್ತೆ ಅದೇ ಕುಂಟೆಯ ಮೇಲೆ ಹೆಜ್ಜೆ ಹಾಕಬಹುದು, ಮತ್ತು ನಮ್ಮ ತಂಡದ ಸಿದ್ಧಾಂತದಲ್ಲಿ ಇದು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ, ಏಕೆಂದರೆ ನಮ್ಮ ಎಲ್ಲಾ ಕೆಲಸದ ಕಾರ್ಯವಿಧಾನಗಳು ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ - ಎಂದಿಗೂ ಪುನರಾವರ್ತಿಸಬೇಡಿ ಅದೇ ಸಮಸ್ಯೆಗಳು. ಇದನ್ನು ಮಾಡಲು, ನಮಗೆ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಲಾಗ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ವಿತರಣೆಯು ಬಹುತೇಕ ನೈಜ ಸಮಯದಲ್ಲಿ ಅಗತ್ಯವಿದೆ, ಏಕೆಂದರೆ ಆನ್-ಡ್ಯೂಟಿ ಎಂಜಿನಿಯರ್‌ಗಳ ತಂಡವು ಮೆಟ್ರಿಕ್‌ಗಳಿಂದ ಮಾತ್ರವಲ್ಲದೆ ಲಾಗ್‌ಗಳಿಂದಲೂ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ. ಸಮಸ್ಯೆಯ ಪ್ರಮಾಣವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಆ ಸಮಯದಲ್ಲಿ ದಾಖಲೆಗಳ ಒಟ್ಟು ಪರಿಮಾಣವು ದಿನಕ್ಕೆ ಸುಮಾರು 2 TB ಆಗಿತ್ತು.
ಲಾಗ್ಗಳ ನಷ್ಟವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೊಡೆದುಹಾಕಲು ನಾವು ಗುರಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ELK ಕ್ಲಸ್ಟರ್‌ಗೆ ಅವುಗಳ ವಿತರಣೆಯ ಸಮಯವನ್ನು ಫೋರ್ಸ್ ಮೇಜರ್ ಸಮಯದಲ್ಲಿ ಗರಿಷ್ಠ 15 ನಿಮಿಷಗಳವರೆಗೆ ಕಡಿಮೆಗೊಳಿಸುತ್ತೇವೆ (ನಾವು ನಂತರ ಈ ಅಂಕಿಅಂಶವನ್ನು ಆಂತರಿಕ KPI ನಂತೆ ಅವಲಂಬಿಸಿದ್ದೇವೆ).
ಹೊಸ ತಿರುಗುವಿಕೆಯ ಕಾರ್ಯವಿಧಾನ ಮತ್ತು ಬಿಸಿ-ಬೆಚ್ಚಗಿನ ನೋಡ್ಗಳು
ElasticSearch ಆವೃತ್ತಿಯನ್ನು 5.5.2 ರಿಂದ 6.4.3 ಗೆ ನವೀಕರಿಸುವ ಮೂಲಕ ನಾವು ಕ್ಲಸ್ಟರ್ ಪರಿವರ್ತನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಮತ್ತೊಮ್ಮೆ ನಮ್ಮ ಆವೃತ್ತಿ 5 ಕ್ಲಸ್ಟರ್ ಸತ್ತುಹೋಯಿತು, ಮತ್ತು ಅದನ್ನು ಆಫ್ ಮಾಡಲು ಮತ್ತು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನವೀಕರಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ - ಇನ್ನೂ ಯಾವುದೇ ಲಾಗ್‌ಗಳಿಲ್ಲ. ಆದ್ದರಿಂದ ನಾವು ಈ ಪರಿವರ್ತನೆಯನ್ನು ಕೇವಲ ಒಂದೆರಡು ಗಂಟೆಗಳಲ್ಲಿ ಮಾಡಿದ್ದೇವೆ.
ಈ ಹಂತದಲ್ಲಿ ಅತ್ಯಂತ ದೊಡ್ಡ ಪ್ರಮಾಣದ ರೂಪಾಂತರವೆಂದರೆ ಮಧ್ಯಂತರ ಬಫರ್‌ನಂತೆ ಸಂಯೋಜಕನೊಂದಿಗೆ ಮೂರು ನೋಡ್‌ಗಳಲ್ಲಿ ಅಪಾಚೆ ಕಾಫ್ಕಾವನ್ನು ಅಳವಡಿಸಲಾಗಿದೆ. ElasticSearch ಸಮಸ್ಯೆಗಳ ಸಮಯದಲ್ಲಿ ಲಾಗ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳದಂತೆ ಸಂದೇಶ ಬ್ರೋಕರ್ ನಮ್ಮನ್ನು ಉಳಿಸಿದ್ದಾರೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಕ್ಲಸ್ಟರ್‌ಗೆ 2 ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ ಮತ್ತು ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಚರಣಿಗೆಗಳಲ್ಲಿ ಇರುವ ಮೂರು "ಬಿಸಿ" ನೋಡ್‌ಗಳೊಂದಿಗೆ ಬಿಸಿ-ಬೆಚ್ಚಗಿನ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲೂ ಕಳೆದು ಹೋಗದಂತಹ ಮುಖವಾಡವನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಅವರಿಗೆ ಲಾಗ್‌ಗಳನ್ನು ಮರುನಿರ್ದೇಶಿಸಿದ್ದೇವೆ - nginx, ಹಾಗೆಯೇ ಅಪ್ಲಿಕೇಶನ್ ದೋಷ ಲಾಗ್‌ಗಳು. ಸಣ್ಣ ಲಾಗ್‌ಗಳನ್ನು ಉಳಿದ ನೋಡ್‌ಗಳಿಗೆ ಕಳುಹಿಸಲಾಗಿದೆ - ಡೀಬಗ್, ಎಚ್ಚರಿಕೆ, ಇತ್ಯಾದಿ, ಮತ್ತು 24 ಗಂಟೆಗಳ ನಂತರ, “ಹಾಟ್” ನೋಡ್‌ಗಳಿಂದ “ಪ್ರಮುಖ” ಲಾಗ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸಲಾಯಿತು.
ಸಣ್ಣ ಸೂಚ್ಯಂಕಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸದಿರಲು, ನಾವು ಸಮಯ ತಿರುಗುವಿಕೆಯಿಂದ ರೋಲ್ಓವರ್ ಕಾರ್ಯವಿಧಾನಕ್ಕೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ. ಇಂಡೆಕ್ಸ್ ಗಾತ್ರದ ಮೂಲಕ ತಿರುಗುವಿಕೆಯು ತುಂಬಾ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ ಎಂದು ವೇದಿಕೆಗಳಲ್ಲಿ ಸಾಕಷ್ಟು ಮಾಹಿತಿ ಇತ್ತು, ಆದ್ದರಿಂದ ನಾವು ಸೂಚ್ಯಂಕದಲ್ಲಿನ ದಾಖಲೆಗಳ ಸಂಖ್ಯೆಯಿಂದ ತಿರುಗುವಿಕೆಯನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ನಾವು ಪ್ರತಿ ಸೂಚ್ಯಂಕವನ್ನು ವಿಶ್ಲೇಷಿಸಿದ್ದೇವೆ ಮತ್ತು ಸರದಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕಾದ ದಾಖಲೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ದಾಖಲಿಸಿದ್ದೇವೆ. ಹೀಗಾಗಿ, ನಾವು ಸೂಕ್ತವಾದ ಚೂರು ಗಾತ್ರವನ್ನು ತಲುಪಿದ್ದೇವೆ - 50 GB ಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ.
ಕ್ಲಸ್ಟರ್ ಆಪ್ಟಿಮೈಸೇಶನ್
ಆದರೆ, ನಾವು ಸಮಸ್ಯೆಗಳಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಮುಕ್ತಿ ಪಡೆದಿಲ್ಲ. ದುರದೃಷ್ಟವಶಾತ್, ಸಣ್ಣ ಸೂಚ್ಯಂಕಗಳು ಇನ್ನೂ ಕಾಣಿಸಿಕೊಂಡವು: ಅವು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಪರಿಮಾಣವನ್ನು ತಲುಪಲಿಲ್ಲ, ತಿರುಗಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಮೂರು ದಿನಗಳಿಗಿಂತ ಹಳೆಯದಾದ ಸೂಚ್ಯಂಕಗಳ ಜಾಗತಿಕ ಶುಚಿಗೊಳಿಸುವಿಕೆಯಿಂದ ಅಳಿಸಲಾಗಿದೆ, ಏಕೆಂದರೆ ನಾವು ದಿನಾಂಕದಿಂದ ತಿರುಗುವಿಕೆಯನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇವೆ. ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಸೂಚ್ಯಂಕವು ಸಂಪೂರ್ಣವಾಗಿ ಕಣ್ಮರೆಯಾಯಿತು ಎಂಬ ಅಂಶದಿಂದಾಗಿ ಇದು ಡೇಟಾ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಯಿತು ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಸೂಚ್ಯಂಕಕ್ಕೆ ಬರೆಯುವ ಪ್ರಯತ್ನವು ನಾವು ನಿರ್ವಹಣೆಗಾಗಿ ಬಳಸಿದ ಕ್ಯುರೇಟರ್‌ನ ತರ್ಕವನ್ನು ಮುರಿಯಿತು. ಬರವಣಿಗೆಯ ಅಲಿಯಾಸ್ ಅನ್ನು ಸೂಚ್ಯಂಕವಾಗಿ ಪರಿವರ್ತಿಸಲಾಯಿತು ಮತ್ತು ರೋಲ್ಓವರ್ ತರ್ಕವನ್ನು ಮುರಿದು, 600 GB ವರೆಗಿನ ಕೆಲವು ಸೂಚ್ಯಂಕಗಳ ಅನಿಯಂತ್ರಿತ ಬೆಳವಣಿಗೆಗೆ ಕಾರಣವಾಯಿತು.
ಉದಾಹರಣೆಗೆ, ತಿರುಗುವಿಕೆಯ ಸಂರಚನೆಗಾಗಿ:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
ಯಾವುದೇ ರೋಲ್ಓವರ್ ಅಲಿಯಾಸ್ ಇಲ್ಲದಿದ್ದರೆ, ದೋಷ ಸಂಭವಿಸಿದೆ:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
ಮುಂದಿನ ಪುನರಾವರ್ತನೆಗಾಗಿ ನಾವು ಈ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಬಿಟ್ಟು ಇನ್ನೊಂದು ಸಮಸ್ಯೆಯನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ: ನಾವು ಲಾಗ್‌ಸ್ಟಾಶ್‌ನ ಪುಲ್ ಲಾಜಿಕ್‌ಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ, ಇದು ಒಳಬರುವ ಲಾಗ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ (ಅನಗತ್ಯ ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಹಾಕುವುದು ಮತ್ತು ಪುಷ್ಟೀಕರಿಸುವುದು). ನಾವು ಅದನ್ನು ಡಾಕರ್‌ನಲ್ಲಿ ಇರಿಸಿದ್ದೇವೆ, ಅದನ್ನು ನಾವು ಡಾಕರ್-ಕಂಪೋಸ್ ಮೂಲಕ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಲಾಗ್‌ಸ್ಟ್ಯಾಶ್-ರಫ್ತುದಾರರನ್ನು ಅಲ್ಲಿ ಇರಿಸಿದ್ದೇವೆ, ಇದು ಲಾಗ್ ಸ್ಟ್ರೀಮ್‌ನ ಕಾರ್ಯಾಚರಣೆಯ ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪ್ರೊಮೀಥಿಯಸ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಈ ರೀತಿಯಾಗಿ ನಾವು ಪ್ರತಿಯೊಂದು ರೀತಿಯ ಲಾಗ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ಲಾಗ್‌ಸ್ಟ್ಯಾಶ್ ನಿದರ್ಶನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸರಾಗವಾಗಿ ಬದಲಾಯಿಸಲು ಅವಕಾಶವನ್ನು ನೀಡಿದ್ದೇವೆ.
ನಾವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸುಧಾರಿಸುತ್ತಿರುವಾಗ, cian.ru ನ ಸಂಚಾರವು ತಿಂಗಳಿಗೆ 12,8 ಮಿಲಿಯನ್ ಅನನ್ಯ ಬಳಕೆದಾರರಿಗೆ ಹೆಚ್ಚಾಯಿತು. ಪರಿಣಾಮವಾಗಿ, ನಮ್ಮ ರೂಪಾಂತರಗಳು ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಹಿಂದೆ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಇದೆ ಎಂದು ಬದಲಾಯಿತು, ಮತ್ತು "ಬೆಚ್ಚಗಿನ" ನೋಡ್ಗಳು ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಲಾಗ್ಗಳ ಸಂಪೂರ್ಣ ವಿತರಣೆಯನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ ಎಂಬ ಅಂಶವನ್ನು ನಾವು ಎದುರಿಸಿದ್ದೇವೆ. ನಾವು ವೈಫಲ್ಯಗಳಿಲ್ಲದೆ "ಬಿಸಿ" ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ, ಆದರೆ ಉಳಿದವುಗಳ ವಿತರಣೆಯಲ್ಲಿ ನಾವು ಮಧ್ಯಪ್ರವೇಶಿಸಬೇಕಾಗಿತ್ತು ಮತ್ತು ಸೂಚ್ಯಂಕಗಳನ್ನು ಸಮವಾಗಿ ವಿತರಿಸಲು ಹಸ್ತಚಾಲಿತ ರೋಲ್ಓವರ್ ಅನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ ಲಾಗ್‌ಸ್ಟ್ಯಾಶ್ ನಿದರ್ಶನಗಳ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವುದು ಮತ್ತು ಬದಲಾಯಿಸುವುದು ಇದು ಸ್ಥಳೀಯ ಡಾಕರ್-ಕಂಪೋಸ್ ಆಗಿರುವುದರಿಂದ ಜಟಿಲವಾಗಿದೆ ಮತ್ತು ಎಲ್ಲಾ ಕ್ರಿಯೆಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಲಾಗಿದೆ (ಹೊಸ ತುದಿಗಳನ್ನು ಸೇರಿಸಲು, ಎಲ್ಲವನ್ನೂ ಹಸ್ತಚಾಲಿತವಾಗಿ ಹಾದುಹೋಗುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಡಾಕರ್-ಕಂಪೋಸ್ ಅಪ್ -ಡಿ ಎಲ್ಲೆಡೆ ಮಾಡಿ).
ಲಾಗ್ ಪುನರ್ವಿತರಣೆ
ಈ ವರ್ಷದ ಸೆಪ್ಟೆಂಬರ್‌ನಲ್ಲಿ, ನಾವು ಇನ್ನೂ ಏಕಶಿಲೆಯನ್ನು ಕತ್ತರಿಸುತ್ತಿದ್ದೇವೆ, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಹೊರೆ ಹೆಚ್ಚುತ್ತಿದೆ ಮತ್ತು ಲಾಗ್ಗಳ ಹರಿವು ಸೆಕೆಂಡಿಗೆ 30 ಸಾವಿರ ಸಂದೇಶಗಳನ್ನು ಸಮೀಪಿಸುತ್ತಿದೆ.
ನಾವು ಹಾರ್ಡ್‌ವೇರ್ ಅಪ್‌ಡೇಟ್‌ನೊಂದಿಗೆ ಮುಂದಿನ ಪುನರಾವರ್ತನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನಾವು ಐದು ಸಂಯೋಜಕರಿಂದ ಮೂರಕ್ಕೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ, ಡೇಟಾ ನೋಡ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ ಮತ್ತು ಹಣ ಮತ್ತು ಶೇಖರಣಾ ಸ್ಥಳದ ವಿಷಯದಲ್ಲಿ ಗೆದ್ದಿದ್ದೇವೆ. ನೋಡ್ಗಳಿಗಾಗಿ ನಾವು ಎರಡು ಸಂರಚನೆಗಳನ್ನು ಬಳಸುತ್ತೇವೆ:
- "ಹಾಟ್" ನೋಡ್ಗಳಿಗಾಗಿ: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot3 ಗಾಗಿ 1 ಮತ್ತು Hot3 ಗಾಗಿ 2).
- "ಬೆಚ್ಚಗಿನ" ನೋಡ್ಗಳಿಗಾಗಿ: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
ಈ ಪುನರಾವರ್ತನೆಯಲ್ಲಿ, ನಾವು ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳ ಪ್ರವೇಶ ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಸೂಚ್ಯಂಕವನ್ನು ಸರಿಸಿದ್ದೇವೆ, ಇದು ಮುಂಭಾಗದ ಸಾಲಿನ nginx ಲಾಗ್‌ಗಳಂತೆಯೇ ಅದೇ ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮೂರು "ಹಾಟ್" ನೋಡ್ಗಳ ಎರಡನೇ ಗುಂಪಿಗೆ. ನಾವು ಈಗ 20 ಗಂಟೆಗಳ ಕಾಲ "ಬಿಸಿ" ನೋಡ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಉಳಿದ ಲಾಗ್‌ಗಳಿಗೆ "ಬೆಚ್ಚಗಿನ" ನೋಡ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸುತ್ತೇವೆ.
ಸಣ್ಣ ಸೂಚ್ಯಂಕಗಳು ಅವುಗಳ ತಿರುಗುವಿಕೆಯನ್ನು ಮರುಸಂರಚಿಸುವ ಮೂಲಕ ಕಣ್ಮರೆಯಾಗುವ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಪರಿಹರಿಸಿದ್ದೇವೆ. ಈಗ ಸೂಚ್ಯಂಕಗಳನ್ನು ಪ್ರತಿ 23 ಗಂಟೆಗಳಿಗೊಮ್ಮೆ ತಿರುಗಿಸಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಸ್ವಲ್ಪ ಡೇಟಾ ಇದ್ದರೂ ಸಹ. ಇದು ಚೂರುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸ್ವಲ್ಪ ಹೆಚ್ಚಿಸಿತು (ಅವುಗಳಲ್ಲಿ ಸುಮಾರು 800 ಇದ್ದವು), ಆದರೆ ಕ್ಲಸ್ಟರ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ ಇದು ಸಹನೀಯವಾಗಿದೆ.
ಪರಿಣಾಮವಾಗಿ, ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ ಆರು "ಬಿಸಿ" ಮತ್ತು ಕೇವಲ ನಾಲ್ಕು "ಬೆಚ್ಚಗಿನ" ನೋಡ್ಗಳು ಇದ್ದವು. ಇದು ದೀರ್ಘಾವಧಿಯ ಮಧ್ಯಂತರಗಳಲ್ಲಿ ವಿನಂತಿಗಳ ಮೇಲೆ ಸ್ವಲ್ಪ ವಿಳಂಬವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಆದರೆ ಭವಿಷ್ಯದಲ್ಲಿ ನೋಡ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.
ಈ ಪುನರಾವರ್ತನೆಯು ಅರೆ-ಸ್ವಯಂಚಾಲಿತ ಸ್ಕೇಲಿಂಗ್ ಕೊರತೆಯ ಸಮಸ್ಯೆಯನ್ನು ಸಹ ಪರಿಹರಿಸಿದೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಮೂಲಸೌಕರ್ಯ ನೊಮ್ಯಾಡ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ - ನಾವು ಈಗಾಗಲೇ ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಿಯೋಜಿಸಿರುವಂತೆಯೇ. ಸದ್ಯಕ್ಕೆ, ಲೋಡ್ ಅನ್ನು ಅವಲಂಬಿಸಿ ಲಾಗ್‌ಸ್ಟ್ಯಾಶ್ ಪ್ರಮಾಣವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬದಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ನಾವು ಇದಕ್ಕೆ ಬರುತ್ತೇವೆ.
ಭವಿಷ್ಯದ ಯೋಜನೆಗಳು
ಅಳವಡಿಸಲಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಮಾಪಕಗಳು ಸಂಪೂರ್ಣವಾಗಿ, ಮತ್ತು ಈಗ ನಾವು 13,3 TB ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ - ಎಲ್ಲಾ ಲಾಗ್‌ಗಳು 4 ದಿನಗಳವರೆಗೆ, ಇದು ಎಚ್ಚರಿಕೆಗಳ ತುರ್ತು ವಿಶ್ಲೇಷಣೆಗೆ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ನಾವು ಕೆಲವು ಲಾಗ್‌ಗಳನ್ನು ಮೆಟ್ರಿಕ್‌ಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತೇವೆ, ಅದನ್ನು ನಾವು ಗ್ರ್ಯಾಫೈಟ್‌ಗೆ ಸೇರಿಸುತ್ತೇವೆ. ಎಂಜಿನಿಯರ್‌ಗಳ ಕೆಲಸವನ್ನು ಸುಲಭಗೊಳಿಸಲು, ಮೂಲಸೌಕರ್ಯ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ನಾವು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಗಳ ಅರೆ-ಸ್ವಯಂಚಾಲಿತ ದುರಸ್ತಿಗಾಗಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮುಂದಿನ ವರ್ಷಕ್ಕೆ ಯೋಜಿಸಲಾದ ಡೇಟಾ ನೋಡ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಿದ ನಂತರ, ನಾವು 4 ರಿಂದ 7 ದಿನಗಳವರೆಗೆ ಡೇಟಾ ಸಂಗ್ರಹಣೆಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ. ಕಾರ್ಯಾಚರಣೆಯ ಕೆಲಸಕ್ಕೆ ಇದು ಸಾಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ನಾವು ಯಾವಾಗಲೂ ಘಟನೆಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ತನಿಖೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ ಮತ್ತು ದೀರ್ಘಾವಧಿಯ ತನಿಖೆಗಳಿಗೆ ಟೆಲಿಮೆಟ್ರಿ ಡೇಟಾ ಇರುತ್ತದೆ.
ಅಕ್ಟೋಬರ್ 2019 ರಲ್ಲಿ, cian.ru ಗೆ ಸಂಚಾರ ಈಗಾಗಲೇ ತಿಂಗಳಿಗೆ 15,3 ಮಿಲಿಯನ್ ಅನನ್ಯ ಬಳಕೆದಾರರಿಗೆ ಬೆಳೆದಿದೆ. ಇದು ಲಾಗ್‌ಗಳನ್ನು ತಲುಪಿಸಲು ವಾಸ್ತುಶಿಲ್ಪದ ಪರಿಹಾರದ ಗಂಭೀರ ಪರೀಕ್ಷೆಯಾಗಿದೆ.
ಈಗ ನಾವು ElasticSearch ಅನ್ನು ಆವೃತ್ತಿ 7 ಕ್ಕೆ ನವೀಕರಿಸಲು ತಯಾರಿ ನಡೆಸುತ್ತಿದ್ದೇವೆ. ಆದಾಗ್ಯೂ, ಇದಕ್ಕಾಗಿ ನಾವು ElasticSearch ನಲ್ಲಿನ ಅನೇಕ ಸೂಚಿಕೆಗಳ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ನವೀಕರಿಸಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅವುಗಳು ಆವೃತ್ತಿ 5.5 ರಿಂದ ಸ್ಥಳಾಂತರಗೊಂಡಿವೆ ಮತ್ತು ಆವೃತ್ತಿ 6 ರಲ್ಲಿ ಅಸಮ್ಮತಿಸಲಾಗಿದೆ ಎಂದು ಘೋಷಿಸಲಾಗಿದೆ (ಅವು ಆವೃತ್ತಿಯಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. 7) ಇದರರ್ಥ ನವೀಕರಣ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಖಂಡಿತವಾಗಿಯೂ ಕೆಲವು ರೀತಿಯ ಫೋರ್ಸ್ ಮೇಜರ್ ಇರುತ್ತದೆ, ಇದು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಾಗ ಲಾಗ್‌ಗಳಿಲ್ಲದೆ ನಮ್ಮನ್ನು ಬಿಡುತ್ತದೆ. ಆವೃತ್ತಿ 7 ರಲ್ಲಿ, ಸುಧಾರಿತ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಹೊಸ ಫಿಲ್ಟರ್‌ಗಳೊಂದಿಗೆ ನಾವು ಕಿಬಾನಾವನ್ನು ಹೆಚ್ಚು ಎದುರು ನೋಡುತ್ತಿದ್ದೇವೆ.
ನಾವು ನಮ್ಮ ಮುಖ್ಯ ಗುರಿಯನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ: ನಾವು ಲಾಗ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದನ್ನು ನಿಲ್ಲಿಸಿದ್ದೇವೆ ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಕ್ಲಸ್ಟರ್‌ನ ಅಲಭ್ಯತೆಯನ್ನು ವಾರಕ್ಕೆ 2-3 ಕ್ರ್ಯಾಶ್‌ಗಳಿಂದ ತಿಂಗಳಿಗೆ ಒಂದೆರಡು ಗಂಟೆಗಳ ನಿರ್ವಹಣಾ ಕೆಲಸಕ್ಕೆ ಕಡಿಮೆಗೊಳಿಸಿದ್ದೇವೆ. ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಈ ಎಲ್ಲಾ ಕೆಲಸವು ಬಹುತೇಕ ಅಗೋಚರವಾಗಿರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಈಗ ನಾವು ನಮ್ಮ ಸೇವೆಯೊಂದಿಗೆ ನಿಖರವಾಗಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬಹುದು, ನಾವು ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಶಾಂತ ಮೋಡ್‌ನಲ್ಲಿ ಮಾಡಬಹುದು ಮತ್ತು ಲಾಗ್‌ಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ ಎಂದು ಚಿಂತಿಸಬೇಡಿ. ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು ತೃಪ್ತರಾಗಿದ್ದೇವೆ, ಸಂತೋಷಪಡುತ್ತೇವೆ ಮತ್ತು ಹೊಸ ಶೋಷಣೆಗಳಿಗೆ ತಯಾರಿ ನಡೆಸುತ್ತೇವೆ, ಅದನ್ನು ನಾವು ನಂತರ ಮಾತನಾಡುತ್ತೇವೆ.
ಮೂಲ: www.habr.com