100 ಕೋಟಿಗೂ ಹೆಚ್ಚು ChatGPT ಬಳಕೆದಾರರಿಗೆ ಆನ್‌ಲೈನ್ ಸಂಗ್ರಹಣೆಯ ತ್ವರಿತ ವಿಸ್ತರಣೆ (ಭಾಗ 2)

ಎಲ್ಲ OpenAI ಉತ್ಪನ್ನಗಳಿಗೂ ಡೇಟಾವನ್ನು ವೇಗವಾಗಿ, ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಪಡೆಯುವ ಅಗತ್ಯವಿದೆ. ಅದನ್ನು ನಮ್ಮ ಸಂಗ್ರಹಣಾ ವೇದಿಕೆ Habitat ಒದಗಿಸುತ್ತದೆ. ಅದು 40 ಭೌಗೋಳಿಕ ವಲಯಗಳಲ್ಲಿರುವ 100 ಕೋಟಿಗೂ ಹೆಚ್ಚು ಬಳಕೆದಾರರಿಗೆ ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು. ನಮ್ಮ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಅಸಾಧಾರಣ ಸವಾಲು ಎದುರಾಯಿತು: ಭಾರಿ ಬೆಳವಣಿಗೆ ಮತ್ತು ಹೊಸ ಬಳಕೆಯ ಸಂದರ್ಭಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತಲೇ ವಿಶ್ವಾಸಾರ್ಹತೆ, ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿಯ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುವುದು. ಅದನ್ನು ಪರಿಹರಿಸಲು ನಮ್ಮ ಆನ್‌ಲೈನ್ ಸಂಗ್ರಹಣಾ ವೇದಿಕೆಯ ವಿನ್ಯಾಸ ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಣೆಯನ್ನು ಮರುಚಿಂತಿಸಬೇಕಾಯಿತು. ಮೊದಲು ನಿರ್ಣಾಯಕ ಉತ್ಪನ್ನ ವಿನಂತಿಗಳಿಗೆ ಸಾಕಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹತೆ, ನಂತರ ಜಾಗತಿಕ ಬಳಕೆದಾರರಿಗೆ ಬೇಕಾದ ವೇಗ, ಕೊನೆಗೆ ಬೃಹತ್ ಪ್ರಮಾಣದಲ್ಲಿ ಸುಗಮ ಕಾರ್ಯನಿರ್ವಹಣೆ ಎಂಬ ಕ್ರಮ ಅನುಸರಿಸಿ, ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ನಿರಂತರವಾಗಿ ತೂಗಿದೆವು.

ಸರಳ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಆಗಿದ್ದ Habitat ಅನ್ನು 500 ಪೆಟಾಬೈಟ್‌ಗೂ ಹೆಚ್ಚಿನ ಡೇಟಾ ಒದಗಿಸುವ ಜಾಗತಿಕ ವಿತರಣಾ ಸಂಗ್ರಹಣಾ ವೇದಿಕೆಯಾಗಿ ಹೇಗೆ ಬೆಳೆಸಿದೆವೆಂದು ಈ ಎರಡು ಭಾಗಗಳ ಸರಣಿ ವಿವರಿಸುತ್ತದೆ. Python ಕ್ಲೈಂಟ್‌ನಿಂದ ಸೇವೆಯಾಗಿ Habitat ವಿಕಸನಗೊಂಡ ರೀತಿಯ ಮೇಲೆ ಭಾಗ 1 ಗಮನಹರಿಸಿತು. Python ಆಧಾರಿತ ಸೇವೆಯನ್ನು ಅನೇಕರ ಪ್ರಕಾರ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಸಾಧ್ಯವಿರುವುದಕ್ಕಿಂತ ಬಹಳ ಮುಂದೆ ಕೊಂಡೊಯ್ಯಲು ನೆರವಾದ ತಂತ್ರಗಳನ್ನೂ ಅದು ವಿವರಿಸಿತು.

ಈ ಭಾಗ 2 ರ ಲೇಖನದಲ್ಲಿ, ಆಧಾರ ಸಂಗ್ರಹಣಾ ಘಟಕವಾದ Azure Cosmos DB ಅನ್ನು ಹೇಗೆ ವಿಸ್ತರಿಸಿದೆವೆಂದು ವಿವರಿಸುತ್ತೇವೆ. Azure ತಂಡದ ನಿಕಟ ಸಹಯೋಗದಿಂದ, ಜಂಟಿಯಾಗಿ ನಿರ್ವಹಿಸುವ ಕಂಟೇನರ್‌ಗಳ ಕಾರ್ಯಸಾಧ್ಯ ಬಹು-ಬಾಡಿಗೆದಾರ ವಿಧಾನವನ್ನು ರೂಪಿಸಿದೆವು. ಇದು ಬೃಹತ್ ಜಾಗತಿಕ ಪ್ರಮಾಣದಲ್ಲೂ ಅತ್ಯುತ್ತಮ ಓದುವ ಕಾರ್ಯಕ್ಷಮತೆ ನೀಡುತ್ತದೆ.

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

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

Habitat ನಲ್ಲಿ ಬೃಹತ್ ಪ್ರಮಾಣದ ವಿಶ್ವಾಸಾರ್ಹ, ದಕ್ಷ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆ ವಿನ್ಯಾಸಗೊಳಿಸಲು ಈ ಎಲ್ಲ ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ತೂಗಬೇಕಾಯಿತು. ಇಂದು Habitat ಅನೇಕ OpenAI ಉತ್ಪನ್ನಗಳಿಗೆ ಬಹು-ಬಾಡಿಗೆದಾರ ಡೇಟಾಬೇಸ್ ಪದರವಾಗಿದೆ. ಆದರೆ ನಮ್ಮ ಪಯಣ ವೃತ್ತಾಕಾರವಾಗಿತ್ತು: ಒಂದೇ ಬಹು-ಬಾಡಿಗೆದಾರ Azure Cosmos DB ಕಂಟೇನರ್‌ನಿಂದ ಆರಂಭಿಸಿ, ಏಕ-ಬಾಡಿಗೆದಾರ ಆಧಾರ ಕಂಟೇನರ್‌ಗಳನ್ನು ಒದಗಿಸಿ, ಕೊನೆಗೆ ಮತ್ತೆ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಬಹು-ಬಾಡಿಗೆದಾರ ಕಂಟೇನರ್‌ಗೆ ಮರಳಿದೆವು. Habitat ನ ಬಹು-ಬಾಡಿಗೆದಾರ ಪಯಣದಲ್ಲಿ ನಾವಿನ್ನೂ ಆರಂಭದಲ್ಲಿದ್ದೇವೆ. ಅನೇಕ ಬಳಕೆಯ ಸಂದರ್ಭಗಳನ್ನು ಬೆಂಬಲಿಸಿದರೂ, ಸಾಧ್ಯವಾದಲ್ಲೆಲ್ಲ Azure Cosmos DB ಯ ಅಂತರ್ನಿರ್ಮಿತ ಮೂಲ ಸೌಲಭ್ಯಗಳನ್ನು ಬಳಸಿ ಈ ಕ್ಷೇತ್ರದ ಹೂಡಿಕೆಯನ್ನು ಮುಂದೂಡಲು ಸಾಧ್ಯವಾಗಿದೆ.

ನಮ್ಮ Azure Cosmos DB ಪಯಣವನ್ನು ವಿವರಿಸುವ ಮೊದಲು, ಕೆಲವು ಮೂಲಭೂತ ಮಾಹಿತಿ:

• Azure Cosmos DB ಖಾತೆಯು ಕಂಟೇನರ್‌ಗಳ ಗುಂಪು ಮತ್ತು ಪ್ರತಿಲಿಪಿ ನೀತಿಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ

• ಪ್ರತಿ ಕಂಟೇನರ್‌ಗೆ ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿ ಘಟಕಗಳ (RU/s) ಲೆಕ್ಕದಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಥ್ರೂಪುಟ್ ಒದಗಿಸಲಾಗುತ್ತದೆ

• ಪ್ರತಿ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ನಿರ್ದಿಷ್ಟ ತಾರ್ಕಿಕ ವಿಭಾಗ ಕೀ ಆಧರಿಸಿ ತುಂಡುಗಳಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಪ್ರತಿ ತಾರ್ಕಿಕ ವಿಭಾಗ ಕೀಗೆ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಥ್ರೂಪುಟ್‌ನ ದಾಖಲಿತ ಮಿತಿಗಳಿರುತ್ತವೆ

• Azure Cosmos DB ತಾರ್ಕಿಕ ವಿಭಾಗ ಕೀಗಳನ್ನು ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಆಧಾರ ಭೌತಿಕ ವಿಭಾಗಗಳಲ್ಲಿ ಹಂಚುತ್ತದೆ. ಸಂಗ್ರಹಣೆ ಮಿತಿ ಮೀರಿದಾಗ ಅಥವಾ ಒದಗಿಸಿದ ಥ್ರೂಪುಟ್ ಉಳಿಸಿಕೊಳ್ಳಲು ಹೆಚ್ಚಿನ ಭೌತಿಕ ವಿಭಾಗಗಳು ಬೇಕಾದಾಗ, ಅವನ್ನು ಹಲವು ಭೌತಿಕ ವಿಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ

ಆರಂಭದಲ್ಲಿ ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಹೊರೆಯನ್ನು ಒಳಬಿಡುತ್ತಿದ್ದೆವು. ಹೊರೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಪ್ರತಿ ತಾರ್ಕಿಕ ವಿಭಾಗ ಕೀಗೆ ತಿಳಿಸಲಾಗಿದ್ದ 10 ಸಾವಿರ RU/s ಮಿತಿಯನ್ನೇ ಅವಲಂಬಿಸಿದ್ದೆವು. ಆರಂಭದಲ್ಲಿ ಪ್ರತಿ ಖಾತೆಯಲ್ಲೂ ಒಂದೇ ಡೀಫಾಲ್ಟ್ Azure Cosmos DB ಕಂಟೇನರ್ ಬಳಸುತ್ತಿದ್ದೆವು. ಇದು ಸಾಕಷ್ಟು ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಿದರೂ, ಕೆಲವು ಕಾರಣಗಳಿಂದ ಸಮಸ್ಯೆಗಳು ಎದುರಾದವು:

ಆರಂಭಿಕ API ಆಯ್ಕೆಗಳಿಂದಾಗಿ ತಾರ್ಕಿಕ ವಿಭಾಗ ಕೀಯ ಆಯ್ಕೆಯನ್ನು ನೇರವಾಗಿ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ನೀಡಿದ್ದೆವು. ಪರಿಣಾಮವಾಗಿ, ವಿವಿಧ ಉತ್ಪನ್ನ ಬಳಕೆಯ ಸಂದರ್ಭಗಳಲ್ಲಿ user_id ಅಥವಾ workspace_idಯಂತಹ ಸಾಮಾನ್ಯ ವಿಭಾಗ ಕೀಗಳು ಆಗಾಗ ಒಂದಕ್ಕೊಂದು ತಾಳೆಯಾಗಿ ಘರ್ಷಣೆ ಉಂಟಾಗುತ್ತದೆ. ಈ ಬಳಕೆಯ ಸಂದರ್ಭಗಳು ಒಂದೇ ತಾರ್ಕಿಕ ವಿಭಾಗ ಕೀಗಳ Azure Cosmos DB ಮಿತಿಗಳನ್ನು ಹಂಚಿಕೊಂಡಿದ್ದರಿಂದ, ಈ ವಿನ್ಯಾಸವು ಒಬ್ಬ ಬಳಕೆದಾರನ ಒಟ್ಟು ಥ್ರೂಪುಟ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಿತು.

Habitat ಮತ್ತು Azure Cosmos DB ಗೆ ಬರುವ ಮೊದಲು Postgres ವಿಸ್ತರಿಸುವಾಗ ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಯೊಂದನ್ನು ಎದುರಿಸಿದ್ದೆವು: ಅತಿಹೆಚ್ಚು ಬಳಕೆಯ ಸಂಸ್ಥೆ ಅಥವಾ ಕೀಯಿಂದ ಬರುವ ಅನೇಕ ವಿನಂತಿಗಳು ಇಡೀ ಡೇಟಾಬೇಸ್ ಸ್ಥಗಿತಗೊಳಿಸಬಲ್ಲವು. ಅಂದರೆ ಒಬ್ಬ ಬಾಡಿಗೆದಾರನೇ ಅಸಮಾನವಾಗಿ ಹೆಚ್ಚಿನ ಹೊರೆ ಸೃಷ್ಟಿಸುತ್ತಿದ್ದ. ಆ ಕೀಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡಲು ಮತ್ತು ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಡೇಟಾ ಸಿಗದಾಗ ತಾತ್ಕಾಲಿಕ ಹಕ್ಕು ನೀಡುವ ವ್ಯವಸ್ಥೆ ನಿರ್ಮಿಸಲು ಸಾಕಷ್ಟು ಜಂಟಿ ಶ್ರಮ ವ್ಯಯಿಸಲಾಯಿತು. ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಡೇಟಾ ಸಿಗದ ವಿನಂತಿಗಳ ಹೊರೆ ಆಧಾರ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಕುಗ್ಗಿಸದಂತೆ ತಡೆಯುವುದು ಇದರ ಉದ್ದೇಶವಾಗಿತ್ತು.

ದಾಖಲಿತ ಡೇಟಾ ಗಾತ್ರ ಮತ್ತು ಥ್ರೂಪುಟ್ ಮಿತಿಗಳು ತಾರ್ಕಿಕ ವಿಭಾಗ ಕೀಗಳಿಗೆ ಅನ್ವಯಿಸಿದರೂ, ವಾಸ್ತವದಲ್ಲಿ ಮಿತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸುವುದು ಭೌತಿಕ ವಿಭಾಗದಲ್ಲಿ. ಹೀಗಾಗಿ ಪ್ರಾಯೋಗಿಕವಾಗಿ ತಾರ್ಕಿಕ ವಿಭಾಗಗಳು 10,000 RU/s ತಲುಪಲಾಗುವುದಿಲ್ಲ. ಬದಲಿಗೆ, ಅದೇ ಭೌತಿಕ ವಿಭಾಗದಲ್ಲಿರುವ ಇತರ ಎಲ್ಲ ತಾರ್ಕಿಕ ವಿಭಾಗ ಕೀಗಳೊಂದಿಗೆ ಅವು ಆ ಭೌತಿಕ ವಿಭಾಗದ ಮಿತಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ.

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

ಭೌತಿಕ ವಿಭಾಗದ ಥ್ರೂಪುಟ್ ಮಿತಿಯೂ ಸ್ಥಿರವಲ್ಲ; ಅದು Azure Cosmos DB ಕಂಟೇನರ್‌ಗೆ ಹಂಚಿಕೆಯಾದ ಒಟ್ಟು ಥ್ರೂಪುಟ್ ಅನ್ನು ಅವಲಂಬಿಸುತ್ತದೆ. ಕಂಟೇನರ್‌ಗೆ ಒದಗಿಸಿದ ಥ್ರೂಪುಟ್ ಅನ್ನು ಅದರ ಭೌತಿಕ ವಿಭಾಗಗಳ ನಡುವೆ ಸರಿಸುಮಾರು ಸಮನಾಗಿ ಹಂಚಲಾಗುತ್ತದೆ.

ಡೇಟಾ ಪ್ರಮಾಣ ಹೆಚ್ಚಿದಂತೆ ಭೌತಿಕ ವಿಭಾಗಗಳು ವಿಭಜನೆಯಾಗಿ ಒಟ್ಟು ವಿಭಾಗಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚುತ್ತದೆ. ಆದರೆ ಒದಗಿಸಿದ ಒಟ್ಟು ಥ್ರೂಪುಟ್ ಬದಲಾಗುವುದಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ಡೇಟಾ ಗಾತ್ರ ಹೆಚ್ಚಿದಂತೆ ಪ್ರತಿ ವಿಭಾಗಕ್ಕೆ ಸಿಗುವ ನೈಜ ಥ್ರೂಪುಟ್ ಮಿತಿ ಕುಗ್ಗುತ್ತದೆ.

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

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

ಬಲವಾದ ಪ್ರತ್ಯೇಕತೆ ಅಗತ್ಯವಿರುವ ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಹೊಸ ಬಳಕೆಯ ಸಂದರ್ಭಗಳಿಗೆ ಪ್ರತ್ಯೇಕ Azure Cosmos DB ಕಂಟೇನರ್‌ಗಳನ್ನು ಬಳಸಲಾರಂಭಿಸಿದೆವು. ಜೊತೆಗೆ, ಪ್ರತಿ ಕಂಟೇನರ್‌ಗೆ ಒದಗಿಸಿದ ಒಟ್ಟು ಥ್ರೂಪುಟ್ ಅನ್ನು ಅದರ ಭೌತಿಕ ವಿಭಾಗಗಳ ಸಂಖ್ಯೆಗೆ ಹೊಂದಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ ಮೂಲಕ ದುರ್ಬಲ ವಿಭಾಗಗಳನ್ನು ನಿರ್ವಹಿಸಿದೆವು. ಇದರಿಂದ ಎದುರಿಸುತ್ತಿದ್ದ ಬಹುತೇಕ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಿದೆವು.

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

ಇದು ಇಡೀ ತಾಣ ಸ್ಥಗಿತಗೊಳ್ಳುವ ಅನೇಕ ಘಟನೆಗಳನ್ನು ತಪ್ಪಿಸಿತು. ಪರಿಣಾಮವು ನಿರ್ದಿಷ್ಟ ವೈಶಿಷ್ಟ್ಯ ಅಥವಾ ಸೇವೆಯ ಕಾರ್ಯಕ್ಷಮತೆ ಕುಸಿತಕ್ಕೆ ಸೀಮಿತವಾಯಿತು. ಆದರೆ ಹೊಸ ಕಂಟೇನರ್‌ಗಳನ್ನು ಒದಗಿಸುವ ಹೆಚ್ಚುವರಿ ಕೆಲಸ ಕೊನೆಗೆ ಹೊರೆಯಾಯಿತು:

ಹಳೆಯ ಹಂಚಿಕೆಯ ಡೀಫಾಲ್ಟ್ ಕಂಟೇನರ್‌ನಲ್ಲಿ, ಒಂದು ಹೊಸ ಬಳಕೆಯ ಸಂದರ್ಭವು 0 QPS ನಿಂದ 10 ಲಕ್ಷ QPS ಗೆ ಏರಿದರೂ ಒಟ್ಟು ಬಳಕೆ ಗಮನಾರ್ಹವಾಗಿ ಬದಲಾಗುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆಯಿತ್ತು. ಆದರೆ ಪ್ರತ್ಯೇಕ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಹೊಸ ಬಳಕೆಯ ಸಂದರ್ಭವು 0 ರಿಂದ 10 ಲಕ್ಷ QPS ಗೆ ಏರಿದರೆ, ಅದು ಆಂತರಿಕ ಪ್ರಾಯೋಗಿಕ ಬಳಕೆಯ ಮೂಲಮಟ್ಟಕ್ಕಿಂತ 1,000 ಪಟ್ಟು ಹೆಚ್ಚಿನ ಹೊರೆಯಾಗಬಹುದು.

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

ವಿವಿಧ ಕಾರ್ಯಭಾರಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುವುದು ಬಹು-ಬಾಡಿಗೆದಾರ ವ್ಯವಸ್ಥೆಗಳ ಪ್ರಮುಖ ಪ್ರಯೋಜನ. ಈ ಕಂಟೇನರ್ ತಂತ್ರದಲ್ಲಿ ಉತ್ತಮ ಪ್ರತ್ಯೇಕತೆಗಾಗಿ ನಾವು ಆ ಪ್ರಯೋಜನವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ.

ಕಾಲಕ್ರಮೇಣ, ಮೀಸಲು ಕಂಟೇನರ್‌ಗಳ ಬಳಕೆ ಮೇಲ್ವಿಚಾರಣೆಗೂ ವಿನಂತಿಗಳ ಪ್ರಮಾಣ ಯಾವಾಗ ಬದಲಾಗುತ್ತದೆ ಅಥವಾ ಹೆಚ್ಚುತ್ತದೆ ಎಂಬ ಉತ್ಪನ್ನದ ಆಳವಾದ ತಿಳಿವಳಿಕೆ ಬೇಕಾಯಿತು.

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

ಪ್ರತಿ ಸೇವೆಯ ಜವಾಬ್ದಾರಿಯ ತಂಡವು Azure Cosmos DB ಸಂಪನ್ಮೂಲ ಹಂಚಿಕೆಗೆ ನೀಡಿದ ಗಮನದಲ್ಲಿ ಬಹಳ ವ್ಯತ್ಯಾಸವಿತ್ತು. ಹೀಗಾಗಿ ಸಂಸ್ಥೆ ವಿಸ್ತರಿಸಿದಂತೆ ಈ ವಿಧಾನ ಹೊಂದಿಕೊಳ್ಳಲಿಲ್ಲ.

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

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

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

Azure Cosmos DBಯಲ್ಲಿ ಮೊದಲೇ ಸರ್ವರ್‌ರಹಿತ ಮೋಡ್ ಇತ್ತು. ಅದು ಪೂರ್ವಹಂಚಿಕೆ ಮೋಡ್‌ನಲ್ಲಿದ್ದ ನಮ್ಮ ದುರ್ಬಲ ವಿಭಾಗಗಳ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬಹುದಿತ್ತು. ಆದರೆ ಒಂದು ದೊಡ್ಡ ಕೊರತೆಯಿತ್ತು: ಅದು ಸಂಗ್ರಹಣಾ ಬಳಕೆಯ ಆಧಾರದಲ್ಲಷ್ಟೇ ವಿಸ್ತರಿಸುತ್ತಿತ್ತು ಮತ್ತು ಪ್ರತಿ ಭೌತಿಕ ವಿಭಾಗಕ್ಕೆ RU ಬಳಕೆಯನ್ನು 5 ಸಾವಿರ RU/sಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತಿತ್ತು. ಇದು ದುರ್ಬಲ ವಿಭಾಗಗಳ ಸಮಸ್ಯೆ ಪರಿಹರಿಸಿದರೂ, ಹೆಚ್ಚು RU ಬೇಕಾಗುವ ಬಳಕೆಯ ಸಂದರ್ಭಗಳನ್ನು ವಿಸ್ತರಿಸಲು ಅಡ್ಡಿಯಾಗುತ್ತಿತ್ತು.

Azure Cosmos DB ತಂಡ ನಮಗಾಗಿ ನಿರ್ಮಿಸಿದ ಸುಧಾರಿತ ಸರ್ವರ್‌ರಹಿತ ಮೋಡ್ ಪ್ರತಿ ಭೌತಿಕ ವಿಭಾಗವನ್ನೂ 10 ಸಾವಿರ RU/sವರೆಗೆ ವಿಸ್ತರಿಸಲು ಅವಕಾಶ ನೀಡಿತು. ಸಂಗ್ರಹಣಾ ಬಳಕೆಯ ಜೊತೆಗೆ RU ಬಳಕೆ ಆಧಾರಿತ ವಿಭಜನೆಯನ್ನೂ ಪರಿಚಯಿಸಿತು. ಹೀಗಾಗಿ ಕಂಟೇನರ್‌ಗಳನ್ನು ಕೈಯಾರೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ ವಿಸ್ತರಿಸುವ ಅಗತ್ಯ ತಪ್ಪಿತು.

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

ಕಂಪನಿಗಳು OpenAI ಮಟ್ಟಕ್ಕೆ ಬೆಳೆದಾಗ, ನಿರ್ವಹಿತ ಸೇವೆಗಳ “ನಿರ್ವಹಣೆ” ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಅನೇಕ ಕಾರ್ಯಭಾರಗಳು ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ಸಾಮಾನ್ಯ ಮಿತಿಗಳಾಚೆ ಹೋಗುತ್ತವೆ. OpenAI, Azure Cosmos DBಯ ಅತಿ ದೊಡ್ಡ ಬಳಕೆದಾರರಲ್ಲಿ ಒಂದಾದಂತೆ, ಯಶಸ್ವಿ ಕಾರ್ಯನಿರ್ವಹಣೆಗೆ ಬೇರೆ ವಿಧಾನ ಬೇಕಾಯಿತು: ಜಂಟಿ ಪರೀಕ್ಷೆಗಳು, ಹಂಚಿಕೆಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು, ನೇರ ಎಂಜಿನಿಯರಿಂಗ್ ಸಂಪರ್ಕ ಮಾರ್ಗಗಳು ಮತ್ತು ನಮ್ಮ ಪ್ರಮಾಣದಲ್ಲಷ್ಟೇ ಕಾಣಿಸುವ ವೈಫಲ್ಯಗಳಿಗೆ ಜಂಟಿ ಜವಾಬ್ದಾರಿ. ಇಂದು ನಮ್ಮ ಅತಿ ದೊಡ್ಡ Azure Cosmos DB ಖಾತೆಯು ಹತ್ತಾರು ಪೆಟಾಬೈಟ್ ಡೇಟಾ ಸಂಗ್ರಹಿಸಿ, 2 ಕೋಟಿಗೂ ಹೆಚ್ಚು QPS ನಿರ್ವಹಿಸುತ್ತದೆ. ನಮಗೆ ತಿಳಿದಂತೆ, ಈ ಪ್ರಮಾಣದಲ್ಲಿ Azure Cosmos DB ನಿಯೋಜಿಸಿರುವ ಏಕೈಕ ಕಂಪನಿ ನಾವು.

2024ರ ಕೊನೆಯಲ್ಲಿ ಸಂಭವಿಸಿದ ವಲಯಮಟ್ಟದ ಸ್ಥಗಿತವು ಈ ಸಹಯೋಗದ ಅಗತ್ಯವನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಿತು. ಆಗ ನಮ್ಮ ಅತಿ ದೊಡ್ಡ Azure Cosmos DB ಖಾತೆಗಳಲ್ಲೊಂದರ ಪ್ರಾಥಮಿಕ Azure ವಲಯದಲ್ಲಿ ವಿದ್ಯುತ್ ಕಡಿತವಾಯಿತು. ಅದರಿಂದ ಸೇವೆಯನ್ನು ದ್ವಿತೀಯ ವಲಯಕ್ಕೆ ವರ್ಗಾಯಿಸುವಾಗ, ನಮ್ಮ ಅತಿ ದೊಡ್ಡ ಖಾತೆಗಳ ವರ್ಗಾವಣೆಗೆ ಹಲವು ಗಂಟೆಗಳು ಬೇಕೆಂದು ತಿಳಿಯಿತು. ನಮ್ಮ ತಂಡವಾಗಲಿ Azure Cosmos DB ತಂಡವಾಗಲಿ ನಮ್ಮ ಪ್ರಮಾಣದಲ್ಲಿ ಇದನ್ನು ಪರೀಕ್ಷಿಸಿರಲಿಲ್ಲ.

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

ಪ್ರತಿ ಸ್ಥಗಿತದಲ್ಲೂ OpenAI ಮತ್ತು Azure ತಮ್ಮ ಘಟನೆ ನಿರ್ವಹಣಾ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಅನುಸರಿಸಿದವು. ಹಲವು ಮೂಲ ಕಾರಣಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿ ಪರಿಹಾರಗಳನ್ನು ಜಾರಿಗೊಳಿಸಲಾಯಿತು. ಆದರೆ ಈ ಸ್ಥಗಿತಗಳು ನಮ್ಮ ತಂಡ ಮತ್ತು Azure Cosmos DB ತಂಡ ಕೆಲಸ ಮಾಡುವ ಹಾಗೂ ಪರೀಕ್ಷಿಸುವ ವಿಧಾನಗಳ ನಡುವಿನ ದೊಡ್ಡ ವ್ಯವಸ್ಥಾತ್ಮಕ ಸಮಸ್ಯೆಯ ಲಕ್ಷಣಗಳಾಗಿದ್ದವು. ಆರಂಭದಲ್ಲಿ ನಿರ್ವಹಿತ ಸೇವೆಗಳ ಬಳಕೆ ನಮಗೆ ವೇಗವಾಗಿ ಮುಂದುವರಿಯಲು ಮತ್ತು ವ್ಯವಹಾರ ಗುರಿಗಳತ್ತ ಗಮನಹರಿಸಲು ಅವಕಾಶ ನೀಡಿತು. ಆದರೆ ಪ್ರಮಾಣ ಹೆಚ್ಚಿದಂತೆ ನಿರ್ವಹಿತ ಸೇವೆಗಳನ್ನು ಪೂರೈಕೆದಾರರಿಗಷ್ಟೇ ಬಿಡಲು ಆಗುವುದಿಲ್ಲ. ವಿನ್ಯಾಸದಿಂದ ಕಾರ್ಯಾಚರಣೆಯವರೆಗೆ ಎಲ್ಲ ಹಂತಗಳಲ್ಲೂ ಸೇವಾ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ಆಳವಾದ ಏಕೀಕರಣ ಬೇಕಾಗುತ್ತದೆ.

ಇಂದು Habitat ಮತ್ತು Azure ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು, ನಮ್ಮ ಸೇವಾ ಪದರಗಳಿಂದ Azure Cosmos DBಯ ಭೌತಿಕ ಸಂಗ್ರಹಣಾ ಪದರಗಳವರೆಗೆ Habitatನ ಪ್ರತಿ ಪದರವನ್ನೂ ಜಂಟಿಯಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತವೆ. ನೈಜ ಸೇವೆಯ ಗಾತ್ರದ್ದಾದರೂ ನೈಜ ಸೇವೆಗೆ ಬಳಸದ Azure Cosmos DB ಖಾತೆಯಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಚಲಾಯಿಸಿ ಪರೀಕ್ಷಿಸುತ್ತೇವೆ. SDKಗಳನ್ನು ಜಂಟಿಯಾಗಿ ಪರೀಕ್ಷಿಸಿ ಪರಿಷ್ಕರಿಸುತ್ತೇವೆ. ನಮ್ಮ Azure Cosmos DB ಖಾತೆಗಳ ಗಾತ್ರ ನಿರ್ಧರಿಸಲು ಮತ್ತು ವಿಸ್ತರಿಸಲು ಉತ್ತಮ ವಿಧಾನಗಳನ್ನು ರೂಪಿಸುತ್ತೇವೆ. Teams ಮೂಲಕ ಪರಸ್ಪರ ನೇರ ಎಂಜಿನಿಯರಿಂಗ್ ಸಂಪರ್ಕವಿದೆ. ಬೆಂಬಲದ ಹಂತಗಳನ್ನು ದಾಟದೆ ಪರಸ್ಪರ ನೇರ ತುರ್ತು ಸೂಚನೆ ಕಳುಹಿಸುವ ಮಾರ್ಗಗಳನ್ನೂ ಒದಗಿಸಿದ್ದೇವೆ.

ಕಳೆದ ವರ್ಷ Azure Cosmos DB ನಿಯಂತ್ರಣ ಪದರ ಮತ್ತು ಗೇಟ್‌ವೇಯ ವಿಸ್ತರಣಾ ಸಾಮರ್ಥ್ಯ ಹೆಚ್ಚಿಸಲು ಸಾಕಷ್ಟು ಜಂಟಿ ಕೆಲಸ ನಡೆದಿದೆ. Azure Cosmos DB ಮೆಟಾಡೇಟಾ ವಿಭಾಗವನ್ನು ರಕ್ಷಿಸಲು ಗೇಟ್‌ವೇಯಲ್ಲಿ ಹೊರೆ ರಕ್ಷಣೆ ಮತ್ತು ವಿವಿಧ ಮೆಟಾಡೇಟಾದ ಕ್ಯಾಶಿಂಗ್ ಸೇರಿಸಿದ್ದೇವೆ. ಸಂಪರ್ಕ ಪೂಲಿಂಗ್ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಪರ್ಕ ಮರುಬಳಕೆಯ ಮೂಲಕ ನಮ್ಮ Python habitat-service ಪ್ರಕ್ರಿಯೆಗಳ ಸಮೂಹದಿಂದ ಬರುವ ಒತ್ತಡ ಕಡಿಮೆ ಮಾಡಿದ್ದೇವೆ. ಸಾಧ್ಯವಾದಲ್ಲಿ ಕಾರ್ಯಭಾರಗಳನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿದ್ದೇವೆ; ಬೇರೆ ಬೇರೆ VPC ಗಳ ಮೂಲಕ ನಿರ್ಣಾಯಕ ಕಾರ್ಯಭಾರಗಳನ್ನು ಆಫ್‌ಲೈನ್ ಕಾರ್ಯಭಾರಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಿದ್ದೇವೆ.

ಕಳೆದ ವರ್ಷ ನಮ್ಮ Azure Cosmos DB ಸ್ಥಿರತೆಗೆ ಈ ಮಟ್ಟದ ಜಂಟಿ ಎಂಜಿನಿಯರಿಂಗ್ ನಿರ್ಣಾಯಕವಾಗಿತ್ತು. ಸಾಕಷ್ಟು ದೊಡ್ಡ ಅಥವಾ ನಿರ್ಣಾಯಕ ವ್ಯವಸ್ಥೆಗೆ ಇಂಥ ತಂಡಕಾರ್ಯ ಅಗತ್ಯ: ಜವಾಬ್ದಾರಿಯ ಗಡಿಗಳನ್ನು ಮೀರಿ, ಸಂಸ್ಥೆಗಳ ನಡುವೆ ಸಹಯೋಗದಿಂದ ಕೆಲಸ ಮಾಡುವುದು.

ಭಾಗ 1 ರಲ್ಲಿ ಹೇಳಿದಂತೆ, ನಮ್ಮ ಮೂಲ ತತ್ವ: ಮೊದಲು ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡಿ, ನಂತರ ವೇಗ ಹೆಚ್ಚಿಸಿ, ಕೊನೆಗೆ ವೆಚ್ಚ ಕಡಿಮೆ ಮಾಡಿ. ಮೊದಲು ವಿಶ್ವಾಸಾರ್ಹತೆ, ನಂತರ ಕಾರ್ಯಕ್ಷಮತೆ, ಆಮೇಲೆ ಸಂಪನ್ಮೂಲ ದಕ್ಷತೆ. Habitat, OpenAI ಗೆ ನಿರ್ಣಾಯಕ ಮೂಲಸೌಕರ್ಯವಾಗಿತ್ತು. ಆದ್ದರಿಂದ ಅದನ್ನು ವಿಶ್ವಾಸಾರ್ಹಗೊಳಿಸುವುದೇ ಮೊದಲ ಆದ್ಯತೆಯಾಗಿತ್ತು. 2025ರಲ್ಲಿ ವ್ಯವಸ್ಥೆ ಸ್ಥಿರಗೊಂಡು OpenAI ಜಾಗತಿಕವಾಗಿ ವಿಸ್ತರಿಸಿದಂತೆ, ಬಳಕೆದಾರರು ಮತ್ತು ಉತ್ಪನ್ನ ತಂಡಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಾ ವಿಳಂಬ ಮುಂದಿನ ಅಡಚಣೆಯಾಯಿತು.

ಗಣನಾ ಮತ್ತು ಸಂಗ್ರಹಣಾ ಸಾಮರ್ಥ್ಯಗಳು ಹೆಚ್ಚಾಗಿ ಬೇರೆ ಬೇರೆ ವಲಯಗಳಲ್ಲಿದ್ದುದರಿಂದ, ವಲಯಗಳ ನಡುವಿನ ವಿನಂತಿಗಳು ಅನಿವಾರ್ಯವಾಗಿದ್ದವು.

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

2026 ರಲ್ಲಿ ಇದಕ್ಕೆ ಹೆಚ್ಚಿನ ಒತ್ತು ನೀಡಿದ್ದೇವೆ. Habitat ವಿನಂತಿಗಳಲ್ಲಿ 90% ಕ್ಕೂ ಹೆಚ್ಚಿನವು ಓದುವ ವಿನಂತಿಗಳಾಗಿದ್ದು, ಅವುಗಳ ಕಾರ್ಯಕ್ಷಮತೆ ಹೆಚ್ಚಿಸಲು ಬಹುಪದರ ತಂತ್ರ ರೂಪಿಸಿದ್ದೇವೆ:

ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿ ಅವಶ್ಯಕತೆಗಳಿರುವ ಬಳಕೆದಾರರಿಗಾಗಿ ವಿಶ್ವದ ವಿವಿಧ Azure ವಲಯಗಳಲ್ಲಿ ಹಲವಾರು Azure Cosmos DB ಖಾತೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಕಟ್ಟುನಿಟ್ಟಿನ ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿ ಅವಶ್ಯಕತೆಗಳಿಲ್ಲದ ಬಳಕೆದಾರರಿಗೂ ಅವರ ಹತ್ತಿರವೇ ಡೇಟಾ ಇರಿಸುವುದು ವಿಳಂಬ ಕಡಿಮೆ ಮಾಡಿ ಅನುಭವ ಸುಧಾರಿಸುತ್ತದೆ.

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

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

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

ಪ್ರತಿ ವಿನಂತಿಗೂ ಬೇಕಾಗುವ ದೃಢೀಕರಣ ಮೆಟಾಡೇಟಾದಂತಹ, ಕನಿಷ್ಠ ವಿಳಂಬ ಬೇಕಿರುವ ಕಾರ್ಯಭಾರಗಳಿಗೆ ಹಲವು ದ್ವಿತೀಯ ವಲಯಗಳಲ್ಲಿ ಪ್ರತಿಲಿಪಿಗಳಿರುವ Azure Cosmos DB ಖಾತೆಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದರಿಂದ ಗಣನಾ ವ್ಯವಸ್ಥೆ ಮತ್ತು Habitat ನಡುವಿನ ಹೋಗಿ-ಬರುವ ಸಮಯ (RTT) ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಕೆಲವು ಖಾತೆಗಳು ನಾವು ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಎಲ್ಲ 40 Azure ವಲಯಗಳಲ್ಲೂ ಪ್ರತಿಲಿಪಿ ಮಾಡುತ್ತವೆ; ಇತರವು ಪ್ರತಿ ಖಂಡದ ಕನಿಷ್ಠ ಒಂದು ವಲಯದಲ್ಲಿ ಪ್ರತಿಲಿಪಿ ಮಾಡುತ್ತವೆ.

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

ಆದರೆ ಈ ವಿಧಾನಕ್ಕೂ ಅಂತಿಮವಾಗಿ ಸಾಮರ್ಥ್ಯದ ಮಿತಿಯಿದೆ. ಹೀಗಾಗಿ ಇದನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಆಯ್ದ ಕೆಲವೇ ಡೇಟಾಸೆಟ್‌ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿದ್ದೇವೆ.

Habitat ಕಾರ್ಯಭಾರಗಳಲ್ಲಿ ಓದುವಿಕೆಯೇ ಬಹುಪಾಲು. ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಸ್ಥಿತಿ ಮತ್ತು ಇತರ ಗುಣಲಕ್ಷಣಗಳನ್ನು ನಿರಂತರವಾಗಿ ಪಡೆಯುತ್ತವೆ. ಪದೇಪದೇ ಬಳಸುವ ಡೇಟಾ ಪ್ರಕಾರಗಳ ಚಿಕ್ಕ ಗುಂಪೇ ಹೆಚ್ಚಿನ ವಿನಂತಿಗಳಿಗೆ ಕಾರಣ. ಹೀಗಾಗಿ ಈ ವ್ಯವಸ್ಥೆ ವಿತರಣಾ ಕ್ಯಾಶಿಂಗ್‌ಗೆ ಬಹಳ ಸೂಕ್ತವಾಗಿದೆ. ಕ್ಯಾಶಿಂಗ್ ಒಂದೇ ವಲಯದ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆ ಹೆಚ್ಚಿಸುತ್ತದೆ. ಹಲವು ವಲಯಗಳಲ್ಲಿ ಇದರ ಲಾಭ ಇನ್ನಷ್ಟು ಹೆಚ್ಚುತ್ತದೆ: ವಲಯಗಳ ನಡುವಿನ ವಿಳಂಬವನ್ನು “ಮರೆಮಾಡಲು” ಇದನ್ನು ಬಳಸಬಹುದು.

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

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

Meta ದ TAO ದಂತಹ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಅನುಸರಿಸಿ, ಅಮಾನ್ಯಗೊಳಿಸಲು ಇನ್ನಷ್ಟು ಸುಧಾರಿತ ವಿಧಾನ ಬಳಸಿದ್ದೇವೆ. Habitatನ ಏಕೀಕೃತ ಕ್ಯಾಶ್, Azure Cosmos DB ಯ ಬದಲಾವಣೆ ಹರಿವಿನ ಮೂಲಕ ಬದಲಾವಣೆ ಡೇಟಾ ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು (CDC) ಬಳಸುತ್ತದೆ. ಅಮಾನ್ಯೀಕರಣಗಳನ್ನು ಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಜಗತ್ತಿನಾದ್ಯಂತ ಹರಡಿ, ಹಳಸುವಿಕೆ ಕಡಿಮೆ ಇಟ್ಟು ಹೆಚ್ಚಿನ ಕ್ಯಾಶ್ ಯಶಸ್ಸಿನ ದರ ಸಾಧಿಸುತ್ತದೆ. ನಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ಸೇವೆಯೊಂದು ಈ ಬದಲಾವಣೆ ಹರಿವನ್ನು ಸ್ವೀಕರಿಸಿ, ಮೂಲ ಡೇಟಾ ನವೀಕರಣವಾದಾಗ ಸ್ಥಳೀಯ ಕ್ಯಾಶ್ ಪ್ರತಿಗಳನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ. ಮುಂದಿನ ಓದುವಿಕೆಯಲ್ಲಿ ಆ ಡೇಟಾ ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಸಿಗುವುದಿಲ್ಲ. ಆಗ ಡೇಟಾದ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯಿಂದ ಕ್ಯಾಶ್ ತುಂಬಿಸಲಾಗುತ್ತದೆ.

ಮೂಲ Python ಗಿಂತ ಹೆಚ್ಚು ಕಾರ್ಯಕ್ಷಮವಾದ Rust ನಲ್ಲಿ ಕೋಡ್ ಮರುಬರೆದು, Habitat ಸೇವೆಯೊಳಗಿನ ಹೆಚ್ಚುವರಿ ಹೊರೆ ತೆಗೆದುಹಾಕಿದ್ದೇವೆ. ಇದರಿಂದಲೂ ವಿಳಂಬ ಬಹಳ ಕಡಿಮೆಯಾಗಿದೆ.

ಈ ಎಲ್ಲ ಬದಲಾವಣೆಗಳಿಂದ ಜಾಗತಿಕ ಓದುವಿಕೆಯ ಒಟ್ಟಾರೆ p50 ಸಮಯ ಸುಮಾರು 120 ರಿಂದ 10 ಮಿಲಿಸೆಕೆಂಡ್‌ಗೆ ಇಳಿದಿದೆ. ಈ ವರ್ಷದ ಆರಂಭದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಒತ್ತು ನೀಡಲಾರಂಭಿಸಿದಂದಿನಿಂದ ಇದು 12 ಪಟ್ಟು ಸುಧಾರಣೆಯಾಗಿದೆ.

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

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

ಆಂತರಿಕ ನಿಯಂತ್ರಣ ಪದರವು ಎಲ್ಲ ಅಗತ್ಯ ಕಂಟೇನರ್‌ಗಳ ಬದಲಾವಣೆ ಸೆರೆಹಿಡಿಯುತ್ತಿರುವುದನ್ನು ನಿರಂತರವಾಗಿ ಖಚಿತಪಡಿಸುತ್ತದೆ. ಯಾವ Cosmos ವಲಯದಿಂದ ಓದಬೇಕೆಂದು ಆಯ್ದು, ಹಲವು ವಲಯಗಳ ಸಾವಿರಾರು ಕಾರ್ಯಕರ್ತರಿಗೆ ಕೆಲಸವನ್ನು ದಕ್ಷವಾಗಿ ಹಂಚುತ್ತದೆ. ಪ್ರತಿಲಿಪಿ ವಲಯಗಳು ಮತ್ತು ಕಡಿಮೆ ಆದ್ಯತೆಯ ಹರಿವು ಓದುವಿಕೆಗಳನ್ನು ಬಳಸಿ, ವಿಳಂಬಕ್ಕೆ ಸೂಕ್ಷ್ಮವಾದ Habitat ವಿನಂತಿಗಳನ್ನು ಹಿನ್ನೆಲೆಯ ಸೆರೆಹಿಡಿಯುವ ಕಾರ್ಯಭಾರಗಳಿಂದ ರಕ್ಷಿಸುತ್ತೇವೆ. ಇಷ್ಟು ದೊಡ್ಡ ಸಮೂಹದಲ್ಲಿ ಕಾರ್ಯಕರ್ತರ ಕ್ರ್ಯಾಶ್‌ಗಳು, ಕಂಟೇನರ್ ಸಮಸ್ಯೆಗಳು, ತಾತ್ಕಾಲಿಕ ಹಕ್ಕು ಸಂಗ್ರಹದ ದೋಷಗಳು, ಅಮಾನ್ಯ ಸಂರಚನೆ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ವೈಫಲ್ಯಗಳು ನಿರಂತರವಾಗಿ ಸಂಭವಿಸುತ್ತವೆ. CDC ಕಾರ್ಯಕರ್ತರ ಜೀವನಚಕ್ರ ಮತ್ತು ತಾತ್ಕಾಲಿಕ ಹಕ್ಕು ನಿರ್ವಹಣೆ ಬಲಪಡಿಸಿ, ಹರಿವುಗಳ ನಡುವೆ ವೈಫಲ್ಯ ಹರಡದಂತೆ ಮಾಡಿದ್ದೇವೆ. ಸಂರಚನಾ ಬದಲಾವಣೆ ಮತ್ತು ಬಿಡುಗಡೆಗಳಿಗೆ ರಕ್ಷಣೆಗಳನ್ನೂ ನಿರ್ಮಿಸಿದ್ದೇವೆ. ಶಾಶ್ವತ ವಿತರಣಾ ವೈಫಲ್ಯಗಳು ಸರದಿಯ ಮುಂಭಾಗ ತಡೆಯದಂತೆ, ವಿಫಲ ಸಂದೇಶಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಸರದಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಓದುವ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಪರ್ಯಾಯ Cosmos ವಲಯಗಳಿಗೆ ಬದಲಿಸಿ ವಲಯಮಟ್ಟದ ಸ್ಥಗಿತಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತೇವೆ. ನಮ್ಮ ಪ್ರಮಾಣದಲ್ಲಿ Azureನ CDC SDK ಯನ್ನೂ ಬದಲಿಸಬೇಕಾಯಿತು. ಪ್ರಗತಿ ಗುರುತುಗಳನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಒಟ್ಟುಗೂಡಿಸಿ, ನಿಯತಕಾಲಕ್ಕೆ ಮಾತ್ರ ಸಂಗ್ರಹಕ್ಕೆ ಬರೆಯುವಂತೆ ಮಾಡಿ ಅದರ ಪ್ರಗತಿ ದಾಖಲಿಸುವ ವಿಧಾನವನ್ನು ದಕ್ಷಗೊಳಿಸಿದೆವು.

Habitat ಒಳಗೆ Azure Cosmos DB ಬಳಕೆ ಸಂಕೀರ್ಣವಾಗಿದೆ. ಆದರೆ ಮೂಲಸೌಕರ್ಯ ವಿವರಗಳಿಂದ ಉತ್ಪನ್ನ ಡೆವಲಪರ್‌ಗಳನ್ನು ಮುಕ್ತಗೊಳಿಸಿ ಅಭಿವೃದ್ಧಿ ವೇಗ ಹೆಚ್ಚಿಸುವುದೇ ಅದರ ಮುಖ್ಯ ಮೌಲ್ಯ. ನಮ್ಮ CDC ವೇದಿಕೆಯೂ ಇದೇ ತತ್ವ ಅನುಸರಿಸುತ್ತದೆ.

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

ಮುಂದಿನ 100 ಕೋಟಿ ಬಳಕೆದಾರರಿಗಾಗಿ Habitat ಮತ್ತು ಸಂಭಾಷಣೆ ಸಂಗ್ರಹಣೆ ವಿಸ್ತರಿಸಲು, ನಮ್ಮ ಮೂಲಸೌಕರ್ಯದಾದ್ಯಂತ ಇನ್ನಷ್ಟು ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಡೇಟಾ ಪ್ರತಿಲಿಪಿ ಮಾಡುವ ಸವಾಲನ್ನು ಪರಿಹರಿಸಬೇಕು. ಇದಕ್ಕೆ ಮುಂಚಿತ ಸಿದ್ಧತೆಯಾಗಿ, ದೊಡ್ಡ ಗಾತ್ರದ Habitat ಡೇಟಾ ಪ್ರಕಾರಗಳಿಗೆ ಹೊಂದುವ ಎಕ್ಸಾಬೈಟ್-ಪ್ರಮಾಣದ ಆನ್‌ಲೈನ್ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಆಂತರಿಕವಾಗಿ ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ. ಅಭಿವೃದ್ಧಿಯಲ್ಲಿರುವ ಈ ವ್ಯವಸ್ಥೆ Rocksetನ RocksDB Cloud ಮೂಲ ಘಟಕವನ್ನು Raft ಆಧಾರಿತ ಪ್ರತಿಲಿಪಿಯೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತದೆ. ಇದು Azure Cosmos DB ಯಂತೆಯೇ ದಸ್ತಾವೇಜು ವಿನ್ಯಾಸ ಬಳಸುತ್ತದೆ. ಆದರೆ ಪ್ರತ್ಯೇಕೀಕೃತ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಭೌತಿಕ ಪ್ರತಿಲಿಪಿಯಿಂದ ಅಗತ್ಯ ಫ್ಲ್ಯಾಶ್ ಸಾಮರ್ಥ್ಯ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ; ಇದಕ್ಕೆ ಪ್ರತಿಯಾಗಿ ಗರಿಷ್ಠ qps ಕಡಿಮೆಯಾಗುತ್ತದೆ.

ಅತ್ಯಾಧುನಿಕ ಪ್ರಮಾಣದಲ್ಲಿ ಇಂಥ ಡೇಟಾ ಮೂಲಸೌಕರ್ಯ ಕೆಲಸಗಳಲ್ಲಿ ಆಸಕ್ತಿಯಿದ್ದರೆ, ನಮ್ಮ ಖಾಲಿ ಹುದ್ದೆಗಳನ್ನು ನೋಡಿ⁠.