Mythex ನ ಸರ್ವರ್‌ಗಳನ್ನು ARM ಗೆ ಏಕೆ ಸ್ಥಳಾಂತರಿಸಿದೆವು

ಸೆಪ್ಟೆಂಬರ್ 19ರಂದು ನಾವು Mythex ನ ಪ್ರೊಡಕ್ಷನ್ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು x86 ಸರ್ವರ್‌ಗಳಿಂದ ಚಿಕ್ಕ ARM-ಆಧಾರಿತ AWS Graviton ಸರ್ವರ್‌ಗಳಿಗೆ ಸ್ಥಳಾಂತರಿಸಿದೆವು, ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಹ Graviton ಇನ್‌ಸ್ಟೆನ್ಸ್‌ಗೆ ಸ್ಥಳಾಂತರಿಸಿದೆವು. ಕಾರಣ ಸರಳ: ಭಾರೀ ಕೆಲಸವನ್ನು — ಪ್ರತಿ ಬಳಕೆದಾರರ ಆ್ಯಪ್ ಅನ್ನು ಚಲಾಯಿಸುವುದು ಮತ್ತು ನಿರ್ಮಿಸುವುದು — ಪ್ರತ್ಯೇಕ ಪ್ರತಿ-ಪ್ರಾಜೆಕ್ಟ್ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗಳಿಗೆ ಸ್ಥಳಾಂತರಿಸಿದ ನಂತರ, ನಮ್ಮ ಮುಖ್ಯ ಸರ್ವರ್‌ಗಳು ತಮ್ಮ ಮೆಮೊರಿಯ ಸುಮಾರು ಮೂರನೇ ಒಂದು ಭಾಗದಲ್ಲಿ ಉತ್ತುಂಗ ತಲುಪುತ್ತಿದ್ದವು. ಚಿಕ್ಕ ARM ಯಂತ್ರಗಳು ನಿಜವಾದ ಲೋಡ್‌ಗೆ ಹೊಂದುತ್ತವೆ ಮತ್ತು ತಿಂಗಳ ಸರ್ವರ್ ಬಿಲ್ ಅನ್ನು ಸುಮಾರು 30% ಕಡಿಮೆ ಮಾಡುತ್ತವೆ.

ನಮ್ಮ ಸರ್ವರ್‌ಗಳು ಈಗ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತವೆ

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

ನಮ್ಮ ಸ್ವಂತ ಸರ್ವರ್‌ಗಳ ಮೇಲೆ ಉಳಿದಿರುವುದು ಸಮನ್ವಯ: API, ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗಳು ಮತ್ತು ಪ್ರಕಟಣೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್, ದೃಢೀಕರಣ, ಬಿಲ್ಲಿಂಗ್ ಮತ್ತು ಗೇಟ್‌ವೇ. ಆ ಕೆಲಸ ಸ್ಥಿರ ಮತ್ತು ಹಗುರ. ಸ್ಥಳಾಂತರದ ನಂತರ, ಸರ್ವರ್‌ಗಳು ಸುಮಾರು ಮೂರು ಪಟ್ಟು ಮೆಮೊರಿ ಇರುವ ಯಂತ್ರಗಳಲ್ಲಿ ಸುಮಾರು 1.3 GB ಮೆಮೊರಿಯಲ್ಲಿ ಉತ್ತುಂಗ ತಲುಪುತ್ತಿದ್ದವು.

ARM ಏಕೆ

AWS ನ Graviton ಪ್ರೊಸೆಸರ್‌ಗಳು AWS ವಿನ್ಯಾಸಗೊಳಿಸಿದ ARM ಚಿಪ್‌ಗಳು. ಒಂದೇ ಹಣಕ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಹೋಲಿಸಬಹುದಾದ x86 ಇನ್‌ಸ್ಟೆನ್ಸ್‌ಗಿಂತ ಹೆಚ್ಚಿನ ಸಾಮರ್ಥ್ಯ, ಅಥವಾ ಕಡಿಮೆ ಹಣಕ್ಕೆ ಅದೇ ಸಾಮರ್ಥ್ಯ ಸಿಗುತ್ತದೆ — ಮತ್ತು ನಮ್ಮಂಥ ಕೆಲಸದ ಹೊರೆಗೆ (Node.js ಸೇವೆಗಳು, Docker, Postgres) x86 ಗೆ ಬಂಧಿಸುವ ಯಾವುದೂ ಇಲ್ಲ.

ನಾವು ಸ್ಥಳಾಂತರಿಸಿದ್ದು:

• ಎರಡು ಆ್ಯಪ್ ಸರ್ವರ್‌ಗಳು, ಮಧ್ಯಮ ಗಾತ್ರದ x86 ಇನ್‌ಸ್ಟೆನ್ಸ್‌ಗಳಿಂದ ತಲಾ 2 GB RAM ಇರುವ ಚಿಕ್ಕ Graviton ಇನ್‌ಸ್ಟೆನ್ಸ್‌ಗಳಿಗೆ.
• ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಡೇಟಾಬೇಸ್, ಚಿಕ್ಕ x86 ಡೇಟಾಬೇಸ್ ಇನ್‌ಸ್ಟೆನ್ಸ್‌ನಿಂದ ಅದರ Graviton ಸಮಾನಕ್ಕೆ.

ಒಂದೇ ನಿಜವಾದ ತೊಡಕು: ಎರಡು ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಿಗಾಗಿ ಇಮೇಜ್‌ಗಳು

ನಮ್ಮ ಸ್ಟೇಜಿಂಗ್ ಪರಿಸರ ಇನ್ನೂ ಚಿಕ್ಕ x86 ಸರ್ವರ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಪ್ರೊಡಕ್ಷನ್ ಈಗ ARM ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಒಂದಕ್ಕಾಗಿ ನಿರ್ಮಿಸಿದ ಕಂಟೇನರ್ ಇಮೇಜ್ ಇನ್ನೊಂದರಲ್ಲಿ ಚಲಿಸುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ ಪ್ರತಿ ಇಮೇಜ್ ಈಗ ಒಂದೇ ಟ್ಯಾಗ್ ಅಡಿಯಲ್ಲಿ ಎರಡೂ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಿಗೆ ನಿರ್ಮಿಸಲ್ಪಡುತ್ತದೆ — ಮಲ್ಟಿ-ಆರ್ಕ್ ಇಮೇಜ್. ಪ್ರತಿ ಯಂತ್ರದಲ್ಲಿ Docker ಸರಿಯಾದ ಆವೃತ್ತಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಡೆಪ್ಲಾಯ್ ಪೈಪ್‌ಲೈನ್ ಯಾವ ಪರಿಸರಕ್ಕೆ ತಳ್ಳುತ್ತಿದೆ ಎಂದು ತಿಳಿಯಬೇಕಾಗಿಲ್ಲ. ವೆಚ್ಚ ಉದ್ದವಾದ CI ಬಿಲ್ಡ್; ಲಾಭ ಸ್ಟೇಜಿಂಗ್ ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ ಒಂದೇ ಟ್ಯಾಗ್‌ನಿಂದ ನಿಖರವಾಗಿ ಒಂದೇ ಕೋಡ್ ಚಲಾಯಿಸುವುದು.

ಸ್ಥಳಾಂತರಕ್ಕೆ ಮೊದಲು ರೋಲ್‌ಬ್ಯಾಕ್ ಯೋಜನೆ

ಲೈವ್ ಸೇವೆಯ ಅಡಿಯಲ್ಲಿ CPU ಆರ್ಕಿಟೆಕ್ಚರ್ ಬದಲಿಸುವುದು ನಿಮಿಷಗಳಲ್ಲಿ ಹಿಂತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ಬದಲಾವಣೆ ಆಗಿರಬೇಕು. ಬದಲಿಸುವ ಮೊದಲು, ನಾವು:

• ಹಿಂದಿನ ಸರ್ವರ್ ಟೆಂಪ್ಲೇಟ್ ಆವೃತ್ತಿಯನ್ನು ಹೆಸರಿಟ್ಟ ರೋಲ್‌ಬ್ಯಾಕ್ ಗುರಿಯಾಗಿ ಇಟ್ಟುಕೊಂಡೆವು,
• ಡೇಟಾಬೇಸ್ ಗಾತ್ರ ಬದಲಿಸುವ ಮೊದಲೇ ಡೇಟಾಬೇಸ್ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ತೆಗೆದುಕೊಂಡೆವು, ಮತ್ತು
• ಸ್ಥಳಾಂತರ ಮತ್ತು ಹಿಂದಿರುಗುವ ದಾರಿಯನ್ನು ಒಳಗೊಂಡ ರನ್‌ಬುಕ್ ಬರೆದೆವು.

ರೋಲ್‌ಬ್ಯಾಕ್ ನಮಗೆ ಬೇಕಾಗಲಿಲ್ಲ. ಮತ್ತೊಮ್ಮೆ ಮಾಡಿದರೂ ಅದೇ ರೀತಿ ಮಾಡುತ್ತೇವೆ.

ನಾವು ಏನನ್ನು ಗಮನಿಸಬೇಕು

ಚಿಕ್ಕ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಡಿಮೆ ಹೆಡ್‌ರೂಮ್ ಇರುತ್ತದೆ. ಅದರಿಂದ ಎರಡು ವಿಷಯಗಳು ಅನುಸರಿಸುತ್ತವೆ:

1. ಭಾರೀ ಕೆಲಸ ಎಂದಾದರೂ ಈ ಸರ್ವರ್‌ಗಳಿಗೆ ಮರಳಿದರೆ, 2 GB ಸಾಕಾಗುವುದಿಲ್ಲ. ಆಗ ಪರಿಹಾರ x86 ಗೆ ಹಿಂತಿರುಗುವುದಲ್ಲ, ದೊಡ್ಡ Graviton ಗಾತ್ರ.
2. ಚಿಕ್ಕ ಯಂತ್ರಗಳಿಗೆ ಸ್ವಾಪ್ ಬೇಕು. ಒಂದು ವಾರದ ನಂತರ ಈ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದು, ತಾಂತ್ರಿಕವಾಗಿ ಮೆಮೊರಿ ಖಾಲಿಯಾಗದೆಯೇ ಮೆಮೊರಿ ಒತ್ತಡದಿಂದ ಹೆಪ್ಪುಗಟ್ಟಿತು — ಕಾಣೆಯಾದ ಸ್ವಾಪ್ ಫೈಲ್‌ನ ಕಥೆ.

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

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