ਅਸੀਂ 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 ਇੰਸਟੈਂਸਾਂ ਤੋਂ ਛੋਟੇ Graviton ਇੰਸਟੈਂਸਾਂ ’ਤੇ, ਹਰ ਇੱਕ ਵਿੱਚ 2 GB RAM ਨਾਲ।
• ਪਲੇਟਫਾਰਮ ਡੇਟਾਬੇਸ ਇੱਕ ਛੋਟੇ x86 ਡੇਟਾਬੇਸ ਇੰਸਟੈਂਸ ਤੋਂ ਉਸਦੇ Graviton ਬਰਾਬਰ ’ਤੇ।

ਇੱਕ ਅਸਲੀ ਪੇਚੀਦਗੀ: ਦੋ ਆਰਕੀਟੈਕਚਰਾਂ ਲਈ ਇਮੇਜਾਂ

ਸਾਡਾ ਸਟੇਜਿੰਗ ਵਾਤਾਵਰਣ ਅਜੇ ਵੀ ਇੱਕ ਛੋਟੇ x86 ਸਰਵਰ ’ਤੇ ਚੱਲਦਾ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਹੁਣ ARM ’ਤੇ ਚੱਲਦਾ ਹੈ। ਇੱਕ ਲਈ ਬਣੀ ਕੰਟੇਨਰ ਇਮੇਜ ਦੂਜੇ ’ਤੇ ਨਹੀਂ ਚੱਲੇਗੀ।

ਇਸ ਲਈ ਹਰ ਇਮੇਜ ਹੁਣ ਦੋਵੇਂ ਆਰਕੀਟੈਕਚਰਾਂ ਲਈ ਇੱਕ ਟੈਗ ਹੇਠ ਬਣਦੀ ਹੈ, ਇੱਕ ਮਲਟੀ-ਆਰਚ ਇਮੇਜ। Docker ਹਰ ਮਸ਼ੀਨ ’ਤੇ ਠੀਕ ਵੇਰੀਐਂਟ ਆਪ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਡਿਪਲਾਇ ਪਾਈਪਲਾਈਨ ਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਕਿਹੜੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਭੇਜ ਰਹੀ ਹੈ। ਕੀਮਤ CI ਬਿਲਡ ਦਾ ਲੰਮਾ ਹੋਣਾ ਹੈ; ਫਾਇਦਾ ਇਹ ਕਿ ਸਟੇਜਿੰਗ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਬਿਲਕੁਲ ਇੱਕੋ ਕੋਡ ਇੱਕੋ ਟੈਗ ਤੋਂ ਚਲਾਉਂਦੇ ਹਨ।

ਲਿਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਰੋਲਬੈਕ ਦੀ ਯੋਜਨਾ

ਚੱਲ ਰਹੀ ਸੇਵਾ ਹੇਠ CPU ਆਰਕੀਟੈਕਚਰ ਬਦਲਣਾ ਉਹ ਤਬਦੀਲੀ ਹੈ ਜਿਸਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਵਾਪਸ ਲੈਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ:

• ਪੁਰਾਣਾ ਸਰਵਰ ਟੈਂਪਲੇਟ ਵਰਜਨ ਇੱਕ ਨਾਮਕ ਰੋਲਬੈਕ ਟਾਰਗੇਟ ਵਜੋਂ ਰੱਖਿਆ,
• ਡੇਟਾਬੇਸ ਦਾ ਆਕਾਰ ਬਦਲਣ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਡੇਟਾਬੇਸ ਦਾ ਸਨੈਪਸ਼ਾਟ ਲਿਆ, ਅਤੇ
• ਲਿਜਾਣ ਅਤੇ ਵਾਪਸੀ ਦੋਵਾਂ ਨੂੰ ਕਵਰ ਕਰਦੀ ਇੱਕ ਰਨਬੁੱਕ ਲਿਖੀ।

ਸਾਨੂੰ ਰੋਲਬੈਕ ਦੀ ਲੋੜ ਨਹੀਂ ਪਈ। ਅਸੀਂ ਫਿਰ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਕਰਦੇ।

ਅਸੀਂ ਕਿਸ ਗੱਲ ’ਤੇ ਨਜ਼ਰ ਰੱਖਾਂਗੇ

ਛੋਟੇ ਸਰਵਰਾਂ ਕੋਲ ਘੱਟ ਵਾਧੂ ਜਗ੍ਹਾ ਹੁੰਦੀ ਹੈ। ਇਸ ਤੋਂ ਦੋ ਗੱਲਾਂ ਬਣਦੀਆਂ ਹਨ:

1. ਜੇ ਭਾਰੀ ਕੰਮ ਕਦੇ ਇਹਨਾਂ ਸਰਵਰਾਂ ’ਤੇ ਵਾਪਸ ਆਵੇ, ਤਾਂ 2 GB ਕਾਫ਼ੀ ਨਹੀਂ ਹੋਵੇਗਾ। ਫਿਰ ਹੱਲ ਵੱਡਾ Graviton ਆਕਾਰ ਹੈ, x86 ’ਤੇ ਵਾਪਸ ਜਾਣਾ ਨਹੀਂ।
2. ਛੋਟੀਆਂ ਮਸ਼ੀਨਾਂ ਨੂੰ ਸਵੈਪ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸਰਵਰ ਮੈਮੋਰੀ ਦੇ ਦਬਾਅ ਨਾਲ ਜਮ ਗਿਆ, ਬਿਨਾਂ ਸੱਚਮੁੱਚ ਮੈਮੋਰੀ ਖਤਮ ਕੀਤੇ। ਗੁੰਮ ਸਵੈਪ ਫਾਈਲ ਦੀ ਕਹਾਣੀ।

ਅਸੀਂ ਇਸ ਤੋਂ ਕੀ ਸਿੱਖਿਆ

• ਆਰਕੀਟੈਕਚਰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਮਾਪੋ। ਭਾਰੀ ਕੰਮ ਨੂੰ ਸੈਂਡਬੌਕਸਾਂ ਵਿੱਚ ਲਿਜਾਣ ਨੇ ਸਾਡੇ ਸਰਵਰਾਂ ਦੀ ਲੋੜ ਬਦਲ ਦਿੱਤੀ; ਇੰਸਟੈਂਸ ਦੇ ਆਕਾਰ ਅਜੇ ਉਸ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾ ਰਹੇ ਸਨ।
• ਜੇ ਤੁਹਾਡੀਆਂ ਇਮੇਜਾਂ ਮਲਟੀ-ਆਰਚ ਹਨ, ਤਾਂ ARM ਆਮ ਵੈੱਬ ਸਟੈਕਾਂ ਲਈ ਘੱਟ-ਜੋਖਮ ਵਾਲੀ ਜਿੱਤ ਹੈ।
• ਰੋਲਬੈਕ ਪਹਿਲਾਂ ਲਿਖੋ। ਇਹ ਤਬਦੀਲੀ ਨੂੰ ਸ਼ਾਂਤ ਬਣਾਉਂਦਾ ਹੈ, ਭਾਵੇਂ ਤੁਸੀਂ ਉਸਨੂੰ ਕਦੇ ਨਾ ਵਰਤੋ।