ಡಿಪ್ಲಾಯ್‌ಗಳನ್ನು ಶೂನ್ಯ 502 ದೋಷಗಳಿಗೆ ಹೇಗೆ ಇಳಿಸಿದೆವು

Mythex ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಡಿಪ್ಲಾಯ್ ಮಾಡಿದ ಪ್ರತಿ ಸಲವೂ, ಕೆಲವು ವಿನಂತಿಗಳು 502 Bad Gateway ನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತಿದ್ದವು. ಹೆಚ್ಚೇನೂ ಅಲ್ಲ — ಆದರೆ ಡಿಪ್ಲಾಯ್ ಸಮಯದಲ್ಲಿ 502 ಎಂದರೆ ಯಾರದೋ ಕ್ಲಿಕ್ ಏನೂ ಮಾಡಲಿಲ್ಲ, ಅಥವಾ ಅವರು ನೋಡುತ್ತಿದ್ದ ಬಿಲ್ಡ್ ಒಂದು ಕ್ಷಣ ನಿಂತಿತು ಎಂದರ್ಥ. ಇದನ್ನು ಎರಡು ಪ್ರತ್ಯೇಕ ಸಮಸ್ಯೆಗಳಿಗೆ ಹಿಂತಿರುಗಿ ಪತ್ತೆಹಚ್ಚಿದೆವು: ಡಿಪ್ಲಾಯ್‌ಗಳ ವಿರುದ್ಧ ಹೋರಾಡುತ್ತಿದ್ದ ಸ್ವಯಂ-ದುರಸ್ತಿ ವಾಚ್‌ಡಾಗ್, ಮತ್ತು ಸರ್ವರ್ ಆಲಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ಸಮಯ ಮತ್ತು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅದಕ್ಕೆ ಟ್ರಾಫಿಕ್ ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ಸಮಯದ ನಡುವಿನ ಅಂತರ. ಫಿಕ್ಸ್‌ಗಳ ನಂತರ ಸತತ ಮೂರು ಉತ್ಪಾದನಾ ಡಿಪ್ಲಾಯ್‌ಗಳಲ್ಲಿ, ಎಣಿಕೆ 10 ರಿಂದ 6 ಕ್ಕೆ, ನಂತರ 0 ಕ್ಕೆ ಇಳಿಯಿತು.

ಸೆಟಪ್

ನಮ್ಮ API ಮತ್ತು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ AWS Application Load Balancer (ALB) ಹಿಂದೆ ಕೆಲವು ಸರ್ವರ್‌ಗಳ ಗುಂಪಿನಲ್ಲಿ ಕಂಟೇನರ್‌ಗಳಾಗಿ ಓಡುತ್ತವೆ. ಡಿಪ್ಲಾಯ್ ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ಸರ್ವರ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ: ಹಳೆಯ ಕಂಟೇನರ್‌ಗಳನ್ನು ಹರಿಸುತ್ತದೆ, ಹೊಸವುಗಳನ್ನು ಆರಂಭಿಸುತ್ತದೆ, ಮುಂದುವರಿಯುತ್ತದೆ. ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿರುವ ವಾಚ್‌ಡಾಗ್ ಕಂಟೇನರ್‌ಗಳು ಚಾಲನೆಯಲ್ಲಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ನಿಂತಿರುವ ಯಾವುದನ್ನೇ ಆದರೂ ಮರುಆರಂಭಿಸುತ್ತದೆ — ಮಧ್ಯರಾತ್ರಿ 3 ಗಂಟೆಗೆ ಕ್ರ್ಯಾಶ್ ಆದ ಪ್ರಕ್ರಿಯೆ ಯಾರನ್ನೂ ಎಚ್ಚರಿಸದೆ ಮರಳಲು ಇದು ಇದೆ.

ಇವೆರಡೂ ತಮ್ಮದೇ ಆಗಿ ಸಮಂಜಸವಾಗಿವೆ. ಆದರೆ ಒಟ್ಟಿಗೆ ಅವು ಸರಿಯಾಗಿ ಹೊಂದಲಿಲ್ಲ.

ಸಮಸ್ಯೆ 1: ವಾಚ್‌ಡಾಗ್ ಡಿಪ್ಲಾಯ್ ಜೊತೆ ಓಟಕ್ಕಿಳಿದಿತ್ತು

ವಾಚ್‌ಡಾಗ್ ಪ್ರತಿ ನಿಮಿಷಕ್ಕೊಮ್ಮೆ ಓಡಿ, ಒಂದು ವಿಫಲ ಆರೋಗ್ಯ ಪರಿಶೀಲನೆಯ ಮೇಲೆಯೇ "ದುರಸ್ತಿ" ಮಾಡುತ್ತಿತ್ತು. ಡಿಪ್ಲಾಯ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೇವೆಗಳನ್ನು 150 ಸೆಕೆಂಡುಗಳವರೆಗೆ ಹರಿಸುತ್ತದೆ — ಆ ಸಮಯದಲ್ಲಿ ಆರೋಗ್ಯ ಪರಿಶೀಲನೆ ವಿಫಲವಾಗುವುದು ನಿರೀಕ್ಷಿತ. ಆದ್ದರಿಂದ ವಾಚ್‌ಡಾಗ್ ಪ್ರತಿ ಡಿಪ್ಲಾಯ್ ಸಮಯದಲ್ಲಿ ಚಲಿಸುತ್ತಿತ್ತು.

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

ಫಿಕ್ಸ್‌ಗಳು:

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

ಸಮಸ್ಯೆ 2: ಟ್ರಾಫಿಕ್ ಹೋಗುವ ಮೊದಲೇ ಸರ್ವರ್ ಹೊರಟಿತ್ತು

ಎರಡನೇ ಸಮಸ್ಯೆ ಸದ್ದಿಲ್ಲದೆ ಇತ್ತು. ಡಿಪ್ಲಾಯ್ ಸರ್ವರ್ ಅನ್ನು ಹರಿಸಿದಾಗ, ಸರ್ವರ್ ತನ್ನ ಆರೋಗ್ಯ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ 503 ನೀಡಲು ಆರಂಭಿಸುತ್ತದೆ, ಆಗ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅದನ್ನು ಸರದಿಯಿಂದ ತೆಗೆಯುತ್ತದೆ. ನಮ್ಮದು 5 ಸೆಕೆಂಡುಗಳ ಕಾಲ ಹಾಗೆ ಮಾಡಿ, ನಂತರ ಮುಚ್ಚುತ್ತಿತ್ತು.

ಆದರೆ ALB ಆರೋಗ್ಯವನ್ನು ಕೆಲವೊಮ್ಮೆ ಮಾತ್ರ ಪರಿಶೀಲಿಸುತ್ತಿತ್ತು, ಮತ್ತು ಗುರಿಗೆ ಟ್ರಾಫಿಕ್ ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವ ಮೊದಲು ಸತತ ಹಲವು ವಿಫಲ ಪರಿಶೀಲನೆಗಳು ಬೇಕಾಗಿದ್ದವು — ಒಟ್ಟಾರೆ ಸುಮಾರು 60 ಸೆಕೆಂಡುಗಳವರೆಗೆ. ಹಾಗಾಗಿ ಸುಮಾರು 55 ಸೆಕೆಂಡುಗಳ ಕಾಲ, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಈಗಾಗಲೇ ಆಲಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ಸರ್ವರ್‌ಗೆ ನಿಜವಾದ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತಲೇ ಇತ್ತು. ಅವೇ ನಮ್ಮ 502 ಗಳಾಗಿದ್ದವು.

ಫಿಕ್ಸ್ ಎಂದರೆ ಎರಡು ಸಮಯರೇಖೆಗಳನ್ನು ಒಪ್ಪುವಂತೆ ಮಾಡುವುದು:

• ಗುರಿ ಗುಂಪು ಈಗ ಪ್ರತಿ 5 ಸೆಕೆಂಡ್‌ಗೆ ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು 2 ವಿಫಲತೆಗಳ ನಂತರ ಗುರಿಯನ್ನು ಅನಾರೋಗ್ಯಕರ ಎಂದು ಗುರುತಿಸುತ್ತದೆ — ಗಮನಿಸಲು ಸುಮಾರು 10 ಸೆಕೆಂಡುಗಳು.
• ಹರಿಯುವಿಕೆ ಆರೋಗ್ಯ ಪರಿಶೀಲನೆಗಳಲ್ಲಿ ವಿಫಲವಾಗಲು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ 15 ಸೆಕೆಂಡುಗಳವರೆಗೆ ನಿಜವಾದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸೇವೆ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವಾಗಲೂ ಅತಿಕ್ರಮಣ ಇರುತ್ತದೆ.
• ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಯಾರೋ ಒಮ್ಮೆ ಕ್ಲಿಕ್ ಮಾಡಿದ್ದರಲ್ಲಿ ಅಲ್ಲ, ಮೂಲಸೌಕರ್ಯವನ್ನು ಒದಗಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಇವೆ.

ಸಂಖ್ಯೆಗಳು ಪರಸ್ಪರ ಹೊಂದುವಂತೆ ಮಾಡುವುದು

ಇಂತಹ ಟೈಮ್‌ಔಟ್‌ಗಳು ಒಂದಕ್ಕೊಂದು ಅವಲಂಬಿತವಾಗಿವೆ. ಹರಿಯುವಿಕೆ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಗಮನಿಸಲು ಬೇಕಾದ ಸಮಯಕ್ಕಿಂತ ಉದ್ದವಾಗಿರಬೇಕು; ಹರಿಯುವಿಕೆ ಮತ್ತು ಶಟ್‌ಡೌನ್ ಸೇರಿ ಕಂಟೇನರ್ ಬಲವಂತವಾಗಿ ಕೊಲ್ಲುವ ಮೊದಲು ಮುಗಿಯಬೇಕು. ಆರು ತಿಂಗಳ ನಂತರ ಯಾರಾದರೂ ಒಂದು ಸಂಖ್ಯೆಯನ್ನು ಬದಲಾಯಿಸಿ ಈ ದೋಷವನ್ನು ಶಾಂತವಾಗಿ ಮರಳಿ ತರುವುದು ಸುಲಭ.

ಆದ್ದರಿಂದ ಆ ಸಂಬಂಧಗಳನ್ನು ಪರೀಕ್ಷೆಗಳಾಗಿ ಬರೆದಿಟ್ಟೆವು: ಹರಿಯುವಿಕೆ ಆರೋಗ್ಯ-ಪರಿಶೀಲನೆ ಮಧ್ಯಂತರ ಮತ್ತು ವಿಫಲತೆ ಮಿತಿಯ ಗುಣಾಕಾರಕ್ಕಿಂತ ಉದ್ದವಾಗಿರಬೇಕು; ಮತ್ತೆ ಆರೋಗ್ಯಕರ ಎಂದು ಗುರುತಿಸಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯ ಚಿಕ್ಕದಾಗಿರಬೇಕು; ಇಡೀ ಹರಿಯುವಿಕೆ ಕಂಟೇನರ್‌ನ ಸ್ಟಾಪ್ ಗ್ರೇಸ್ ಅವಧಿಯೊಳಗೆ ಹೊಂದಬೇಕು. ಒಂದು ಸಂಖ್ಯೆ ಬದಲಾಯಿಸಿ ಉಳಿದವನ್ನು ಬದಲಾಯಿಸದಿದ್ದರೆ CI ವಿಫಲವಾಗುತ್ತದೆ. ಪರೀಕ್ಷೆಗಳನ್ನೇ ಮ್ಯುಟೇಶನ್-ಪರೀಕ್ಷೆ ಮಾಡಿದೆವು — ಪ್ರತಿ ಸಂಖ್ಯೆಯನ್ನು ತಪ್ಪು ಮೌಲ್ಯಕ್ಕೆ ಬದಲಾಯಿಸಿ ಒಂದು ಪರೀಕ್ಷೆ ಅದನ್ನು ಹಿಡಿಯುತ್ತದೆಯೇ ಎಂದು ನೋಡಿದೆವು.

ಡಿಪ್ಲಾಯ್ ಅಳೆಯುವುದು ಸುಲಭವಾಗಿ ತಪ್ಪಾಗಬಹುದು

ನಮ್ಮ ಮೊದಲ ಅಳತೆ ಹೇಳಿದ್ದು ಸ್ವಚ್ಛ ಡಿಪ್ಲಾಯ್ ಸುಮಾರು 3% ಮುರಿದಿತ್ತು ಎಂದು. ಅದು ನಿಜವಾಗಿರಲಿಲ್ಲ. ನಾವು 200 ಅಲ್ಲದ ಪ್ರತಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಎಣಿಸುತ್ತಿದ್ದೆವು, ಮತ್ತು ಹರಿಯುವಿಕೆ ಸಮಯದಲ್ಲಿ ಆರೋಗ್ಯ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನಿಂದ ಬರುವ 503 ವೈಫಲ್ಯವಲ್ಲ — ಅದು ಹರಿಯುವಿಕೆ ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿರುವುದು, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಆ ಸರ್ವರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಡ ಎಂದು ಹೇಳುತ್ತಾ, ಅದು ನಿಜವಾದ ವಿನಂತಿಗಳನ್ನು ಸೇವೆ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ.

ಬಳಕೆದಾರರು ಅನುಭವಿಸುವುದು 502 — ವಿನಂತಿ ಏನನ್ನೂ ತಲುಪಲಿಲ್ಲ. ಆ ಮಾತ್ರ ಎಣಿಸಿದಾಗ ನಿಜ ಚಿತ್ರ ಸಿಕ್ಕಿತು — ಮೂರು ಉತ್ಪಾದನಾ ಡಿಪ್ಲಾಯ್‌ಗಳಲ್ಲಿ 10, ನಂತರ 6, ನಂತರ 0.

ನಾವು ಕಲಿತದ್ದು

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

Mythex ನಲ್ಲಿ ನೀವು ಆ್ಯಪ್ ಪ್ರಕಟಿಸಿದರೆ, ಇದು ಯಾವುದೂ ನಿಮಗೆ ಕಾಣುವುದಿಲ್ಲ — ಅದೇ ಉದ್ದೇಶ. ಸಂಬಂಧಿತ: ಪ್ರಕಟಿಸಿದ ನಿಮ್ಮ ಆ್ಯಪ್ ನೀವು ಮರುಪ್ರಕಟಿಸುವಾಗಲೂ ಹೇಗೆ ಚಾಲನೆಯಲ್ಲಿರುತ್ತದೆ.