ನಾವೇ ನಮ್ಮ ಸ್ವಂತ ಸೇವೆಗಳ ರೇಟ್ ಅನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತಿದ್ದೆವು

Mythex ನ API ಒಂದು ನೆಟ್‌ವರ್ಕ್ ವಿಳಾಸದಿಂದ ನಿಮಿಷಕ್ಕೆ 300 ವಿನಂತಿಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಆ ಮಿತಿ ಒಬ್ಬ ವ್ಯಕ್ತಿ ಅಥವಾ ಸ್ಕ್ರಿಪ್ಟ್ API ಅನ್ನು ಅತಿಯಾಗಿ ಬಳಸದಂತೆ ರಕ್ಷಿಸಲು ಇದೆ. ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ, ಅದು ನಮ್ಮ ಸ್ವಂತ ಸೇವೆಗಳನ್ನೇ ನಿರಾಕರಿಸಲಾರಂಭಿಸಿತು — ಪ್ರಕಟಿತ ಆ್ಯಪ್‌ಗಳನ್ನು ಸೇವೆ ಮಾಡುವ ನಮ್ಮ ಎಡ್ಜ್‌ನ ಭಾಗ ಮತ್ತು AI ಏಜೆಂಟ್ ಅನ್ನು ಚಲಾಯಿಸುವ ಸೇವೆ — ಏಕೆಂದರೆ ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಕೆಲವೇ ವಿಳಾಸಗಳಿಂದ API ಅನ್ನು ತಲುಪುತ್ತದೆ. ನಮ್ಮ ಆಂತರಿಕ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಹೊಂದಿರುವ ವಿನಂತಿಗಳಿಗೆ ಈಗ ವಿನಾಯಿತಿ ಇದೆ, ಮತ್ತು ಉಳಿದವರನ್ನು ಮೊದಲಿನಂತೆಯೇ ಮಿತಿಗೊಳಿಸಲಾಗುತ್ತದೆ.

ಲಕ್ಷಣ

API ನಮ್ಮ ಸ್ವಂತ ಆಂತರಿಕ ಕರೆಗಳಲ್ಲಿ ಕೆಲವಕ್ಕೆ 429 Too Many Requests ನೊಂದಿಗೆ ಉತ್ತರಿಸಲಾರಂಭಿಸಿತು. ಮೂರು ವಿಧದ ಕರೆಗಳು ಹೊಡೆತ ತಿಂದವು, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ Mythex ಬಳಸುವ ಯಾರಿಗಾದರೂ ಮುಖ್ಯ:

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

ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಬೇರೆಯವರು API ಕರೆದದ್ದಲ್ಲ. ಎಲ್ಲವೂ ನಾವೇ ಆಗಿದ್ದೆವು.

ಇದು ಏಕೆ ಸಂಭವಿಸಿತು

ಪ್ರತಿ-ವಿಳಾಸದ ರೇಟ್ ಮಿತಿ ಒಂದು ಊಹೆಯನ್ನು ಮಾಡುತ್ತದೆ: ಒಂದು ವಿಳಾಸ ಸುಮಾರಾಗಿ ಒಬ್ಬ ಕರೆಯುವವರು. ಜನರಿಗೆ, ಅದು ಸಾಕಷ್ಟು ಹತ್ತಿರ. ನಮ್ಮ ಸ್ವಂತ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ, ಅದು ತೀರಾ ತಪ್ಪು.

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

ಆದ್ದರಿಂದ ಒಬ್ಬ ವ್ಯಕ್ತಿಗಾಗಿ ಇದ್ದ ಬಜೆಟ್ ಇಡೀ ಸೇವೆಯ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ನಡುವೆ ವಿಭಜನೆಯಾಗುತ್ತಿತ್ತು. ಆ ಸೇವೆಗಳು ಅದನ್ನು ಒಟ್ಟಾಗಿ ಖಾಲಿ ಮಾಡಿದವು, ಮತ್ತು ಮಿತಿ ತನಗೆ ಹೇಳಿದ್ದನ್ನು ಮಾಡಿತು: ಅದು ಅವುಗಳನ್ನು ನಿರಾಕರಿಸಿತು.

ಪರಿಹಾರ

ನಮ್ಮ ಸ್ವಂತ ಸೇವೆಗಳು ತಾವು ಯಾರು ಎಂದು ಈಗಾಗಲೇ ಸಾಬೀತುಪಡಿಸುತ್ತವೆ. ಪ್ರತಿ ಆಂತರಿಕ ಕರೆ ಆಂತರಿಕ ಟೋಕನ್ ಅನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ, ಮತ್ತು API ಯ ಆಂತರಿಕ ವಿಭಾಗದ ಪ್ರತಿ ರೂಟ್ ಏನಾದರೂ ಮಾಡುವ ಮೊದಲು ಆ ಟೋಕನ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

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

ಇದು ಭದ್ರತಾ ರಂಧ್ರವಾಗದಂತೆ ತಡೆದ ಎರಡು ವಿವರಗಳು:

1. ತಪ್ಪಾದ ಟೋಕನ್‌ಗೆ ವಿನಾಯಿತಿ ಇಲ್ಲ. ಅನುಮತಿ ಪಟ್ಟಿ ನಿಜವಾದ ಆಂತರಿಕ ಟೋಕನ್‌ಗೆ ಮಾತ್ರ ಹೊಂದುತ್ತದೆ. ನಕಲಿ ಟೋಕನ್ ಹೊಂದಿರುವ ವಿನಂತಿಯನ್ನು ಉಳಿದವುಗಳಂತೆಯೇ ಎಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಮಿತಿಗೊಳಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಆಂತರಿಕ ರೂಟ್‌ಗಳು ಅದನ್ನು 401 Unauthorized ನೊಂದಿಗೆ ಇನ್ನೂ ತಿರಸ್ಕರಿಸುತ್ತವೆ.
2. ಮಿತಿ ಸ್ವತಃ ಬದಲಾಗಲಿಲ್ಲ. ಜಾಗ ಮಾಡಲು ನಾವು ಸಂಖ್ಯೆಯನ್ನು ಏರಿಸಲಿಲ್ಲ. ಏರಿಸಿದ್ದರೆ ಸಮಸ್ಯೆ ಸ್ವಲ್ಪ ಕಾಲ ಮರೆಯಾಗುತ್ತಿತ್ತು, ಆದರೆ ಟ್ರಾಫಿಕ್ ಮತ್ತೆ ಬೆಳೆದಾಗ ಮತ್ತೆ ವಿಫಲವಾಗುತ್ತಿತ್ತು, ಮತ್ತು ಮಿತಿ ಯಾವ ಪ್ರಕರಣಕ್ಕಾಗಿ ಇದೆಯೋ ಅದರ ರಕ್ಷಣೆಯನ್ನು ದುರ್ಬಲಗೊಳಿಸುತ್ತಿತ್ತು.

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

ನಾವು ಇದರಿಂದ ಕಲಿತದ್ದು

• ಮಿತಿಗಳು ಊಹೆಗಳನ್ನು ಹೊತ್ತಿರುತ್ತವೆ. “ಒಂದು ವಿಳಾಸ, ಒಬ್ಬ ಕರೆಯುವವರು” ಪ್ರತಿ-ವಿಳಾಸದ ಮಿತಿಯಲ್ಲಿ ಅಂತರ್ಗತವಾಗಿದೆ. ನಿಮ್ಮ ಸ್ವಂತ ಸೇವೆಗಳು ಹಂಚಿದ ವಿಳಾಸಗಳ ಹಿಂದೆ ಇದ್ದ ಕ್ಷಣ ಅದು ನಿಜವಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ — ಮತ್ತು ಅನೇಕ ಸೇವೆಗಳು ಹಾಗೆಯೇ ಇರುತ್ತವೆ: ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು, ಎಡ್ಜ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳು, ಕಂಟೇನರ್‌ಗಳು, ಕಚೇರಿ ನೆಟ್‌ವರ್ಕ್‌ಗಳು.
• ನಿಮ್ಮ ಸ್ವಂತ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವಿಳಾಸದಿಂದಲ್ಲ, ಗುರುತಿನಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ. ವಿಳಾಸಗಳು ಟ್ರಾಫಿಕ್ ಹೇಗೆ ಬರುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ, ಯಾರು ಕಳುಹಿಸಿದರು ಎಂಬುದನ್ನಲ್ಲ. ಕರೆ ನಮ್ಮದೆಂದು ಸಾಬೀತುಪಡಿಸುವ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ನಮ್ಮಲ್ಲಿ ಈಗಾಗಲೇ ಇತ್ತು; ಲಿಮಿಟರ್ ಅದನ್ನು ನೋಡುತ್ತಿರಲಿಲ್ಲ ಅಷ್ಟೆ.
• ಸಂಖ್ಯೆ ಏರಿಸಿ ಸರಿಪಡಿಸಬೇಡಿ. ದೊಡ್ಡ ಮಿತಿ 429ಗಳನ್ನು ಕೆಲಕಾಲ ಮಾಯವಾಗಿಸುತ್ತಿತ್ತು, ಕಡಿಮೆ ರಕ್ಷಣೆ ನೀಡುತ್ತಿತ್ತು, ಮತ್ತು ನಂತರ ಮತ್ತೆ ವಿಫಲವಾಗುತ್ತಿತ್ತು.
• ಯಾರನ್ನು ಮಿತಿಗೊಳಿಸಲಾಗುತ್ತಿದೆ ಎಂದು ನೋಡಿ. ನಿಮ್ಮ ಸ್ವಂತ ಸೇವೆಗೆ ಬೀಳುವ 429 ನಿಮ್ಮ ಮಿತಿಗಳ ಬಗ್ಗೆ ಒಂದು ದೋಷ ವರದಿ, ಲಿಮಿಟರ್ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂಬುದರ ಸಂಕೇತವಲ್ಲ.

ನೀವು Mythex ನಲ್ಲಿ ನಿರ್ಮಿಸಿದರೆ ಇದರ ಅರ್ಥವೇನು

ನಿಮ್ಮ ಕಡೆ ಬದಲಾಯಿಸಬೇಕಾದ್ದು ಏನೂ ಇಲ್ಲ. ಕಸ್ಟಮ್ ಡೊಮೇನ್‌ಗಳಲ್ಲಿನ ಪ್ರಕಟಿತ ಆ್ಯಪ್‌ಗಳು, ಏಜೆಂಟ್ ಟರ್ನ್‌ಗಳು ಮತ್ತು ಪೂರ್ವವೀಕ್ಷಣೆಗಳು ಇನ್ನು ಉಳಿದ Mythex ಎಷ್ಟು ಬ್ಯುಸಿ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿಲ್ಲ. ನಿಮ್ಮ ಆ್ಯಪ್‌ನ ಸ್ವಂತ ಟ್ರಾಫಿಕ್ ನಿಮ್ಮ ಆ್ಯಪ್‌ನ ವಿಷಯ: ಇಲ್ಲಿ ವಿವರಿಸಿದ ಮಿತಿ ನಮ್ಮ API ಮೇಲಿದೆ, ನೀವು ಪ್ರಕಟಿಸುವ ಆ್ಯಪ್‌ಗಳ ಮೇಲೆ ಅಲ್ಲ.

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