ਡਿਪਲਾਇ ਨੂੰ ਜ਼ੀਰੋ 502 ਗਲਤੀਆਂ ਤੱਕ ਕਿਵੇਂ ਲਿਆਂਦਾ

ਹਰ ਵਾਰ ਜਦੋਂ ਅਸੀਂ Mythex ਦਾ ਬੈਕਐਂਡ ਡਿਪਲਾਇ ਕਰਦੇ ਸੀ, ਕੁਝ ਬੇਨਤੀਆਂ 502 Bad Gateway ਨਾਲ ਅਸਫਲ ਹੁੰਦੀਆਂ ਸਨ। ਬਹੁਤੀਆਂ ਨਹੀਂ, ਪਰ ਡਿਪਲਾਇ ਦੌਰਾਨ 502 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਿਸੇ ਦੇ ਕਲਿੱਕ ਨੇ ਕੁਝ ਨਹੀਂ ਕੀਤਾ, ਜਾਂ ਉਹ ਬਿਲਡ ਜੋ ਕੋਈ ਵੇਖ ਰਿਹਾ ਸੀ ਕੁਝ ਪਲ ਅਟਕ ਗਿਆ। ਅਸੀਂ ਇਸਦਾ ਪਤਾ ਦੋ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੱਕ ਲਾਇਆ: ਇੱਕ ਸਵੈ-ਮੁਰੰਮਤ ਕਰਨ ਵਾਲਾ ਵਾਚਡੌਗ ਜੋ ਸਾਡੇ ਡਿਪਲਾਇਆਂ ਨਾਲ ਲੜਦਾ ਸੀ, ਅਤੇ ਉਸ ਪਾੜੇ ਦੀ ਚੁੱਪ ਸਮੱਸਿਆ ਕਿ ਸਰਵਰ ਸੁਣਨਾ ਬੰਦ ਕਰਦਾ ਹੈ ਅਤੇ ਲੋਡ ਬੈਲੈਂਸਰ ਉਸ ਵੱਲ ਟ੍ਰੈਫਿਕ ਭੇਜਣਾ ਬੰਦ ਕਰਦਾ ਹੈ। ਫਿਕਸਾਂ ਤੋਂ ਬਾਅਦ ਲਗਾਤਾਰ ਤਿੰਨ ਪ੍ਰੋਡਕਸ਼ਨ ਡਿਪਲਾਇਆਂ ਵਿੱਚ ਗਿਣਤੀ 10 ਤੋਂ 6 ਅਤੇ ਫਿਰ 0 ਹੋ ਗਈ।

ਸੈੱਟਅੱਪ

ਸਾਡਾ API ਅਤੇ ਔਰਕੇਸਟਰੇਟਰ ਇੱਕ AWS Application Load Balancer (ALB) ਦੇ ਪਿੱਛੇ ਸਰਵਰਾਂ ਦੇ ਛੋਟੇ ਗਰੁੱਪ ’ਤੇ ਕੰਟੇਨਰਾਂ ਵਜੋਂ ਚੱਲਦੇ ਹਨ। ਇੱਕ ਡਿਪਲਾਇ ਇੱਕ ਵੇਲੇ ਇੱਕ ਸਰਵਰ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ: ਪੁਰਾਣੇ ਕੰਟੇਨਰ ਡਰੇਨ ਕਰਦਾ ਹੈ, ਨਵੇਂ ਚਾਲੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਗਲੇ ’ਤੇ ਜਾਂਦਾ ਹੈ। ਹਰ ਸਰਵਰ ’ਤੇ ਇੱਕ ਵਾਚਡੌਗ ਜਾਂਚਦਾ ਹੈ ਕਿ ਕੰਟੇਨਰ ਚੱਲ ਰਹੇ ਹਨ ਅਤੇ ਜੋ ਵੀ ਨਾ ਚੱਲੇ ਉਸਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਦਾ ਹੈ। ਇਹ ਇਸ ਲਈ ਹੈ ਕਿ ਸਵੇਰੇ 3 ਵਜੇ ਕਰੈਸ਼ ਹੋਈ ਪ੍ਰਕਿਰਿਆ ਕਿਸੇ ਨੂੰ ਜਗਾਏ ਬਿਨਾਂ ਵਾਪਸ ਆ ਜਾਵੇ।

ਦੋਵੇਂ ਆਪਣੇ ਆਪ ਵਿੱਚ ਵਾਜਬ ਹਨ। ਇਕੱਠੇ ਨਹੀਂ ਸਨ।

ਸਮੱਸਿਆ 1: ਵਾਚਡੌਗ ਡਿਪਲਾਇ ਨਾਲ ਦੌੜ ਲਾਉਂਦਾ ਸੀ

ਵਾਚਡੌਗ ਹਰ ਮਿੰਟ ਚੱਲਦਾ ਸੀ ਅਤੇ ਇੱਕ ਫੇਲ੍ਹ ਹੈਲਥ ਚੈੱਕ ’ਤੇ “ਠੀਕ” ਕਰਦਾ ਸੀ। ਡਿਪਲਾਇ ਜਾਣਬੁੱਝ ਕੇ 150 ਸਕਿੰਟ ਤੱਕ ਸੇਵਾਵਾਂ ਨੂੰ ਡਰੇਨ ਕਰਦਾ ਹੈ, ਜਿਸ ਦੌਰਾਨ ਹੈਲਥ ਚੈੱਕ ਨੂੰ ਫੇਲ੍ਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਲਈ ਵਾਚਡੌਗ ਹਰ ਡਿਪਲਾਇ ਦੌਰਾਨ ਚਲਦਾ ਸੀ।

ਜ਼ਿਆਦਾਤਰ ਵਾਰ ਉਹ ਦੌੜ ਬੇਕਾਰ ਹਾਰਦਾ ਸੀ। ਇੱਕ ਵਾਰ ਜਿੱਤ ਗਿਆ: ਉਸਨੇ ਡਿਪਲਾਇ ਦੇ ਵਿਚਕਾਰ compose ਫਾਈਲ (ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਕੰਟੇਨਰ ਚੱਲਣੇ ਚਾਹੀਦੇ ਹਨ) ਦੁਬਾਰਾ ਲਿਖ ਦਿੱਤੀ, ਅਤੇ ਇੱਕ ਸਰਵਰ ਨੂੰ ਬਿਨਾਂ ਗੇਟਵੇ ਕੰਟੇਨਰ ਦੇ ਛੱਡ ਦਿੱਤਾ, ਜਦਕਿ ਡਿਪਲਾਇ ਜੌਬ ਨੇ ਸਫਲਤਾ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ।

ਫਿਕਸ:

• ਇੱਕ ਲਾਕ। ਡਿਪਲਾਇ ਹੁਣ ਉਹੀ ਫਾਈਲ ਲਾਕ ਲੈਂਦਾ ਹੈ ਜੋ ਸਰਵਰ ਦੀ ਬੂਟਸਟਰੈਪ ਸਕ੍ਰਿਪਟ ਲੈਂਦੀ ਹੈ, ਤਾਂ ਵਾਚਡੌਗ ਅਤੇ ਡਿਪਲਾਇ ਕਦੇ ਇੱਕੋ ਵੇਲੇ ਨਹੀਂ ਚੱਲ ਸਕਦੇ।
• ਚਾਰ ਵਾਰ, ਇੱਕ ਨਹੀਂ। ਵਾਚਡੌਗ ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਗਾਤਾਰ ਚਾਰ ਫੇਲ੍ਹ ਚੈੱਕ ਚਾਹੁੰਦਾ ਹੈ। ਡਰੇਨ ਹੋ ਰਹੀ ਸੇਵਾ ਹੁਣ ਮਰੀ ਨਹੀਂ ਲੱਗਦੀ।
• ਇੱਕ ਪਰਿਭਾਸ਼ਾ। Compose ਫਾਈਲ ਦਾ ਹੁਣ ਬਿਲਕੁਲ ਇੱਕ ਸਰੋਤ ਹੈ, ਜੋ ਸਰਵਰਾਂ ’ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਕਾਪੀਆਂ ਜੋ ਵੱਖ ਹੋ ਸਕਣ।
• ਵਿਸ਼ਵਾਸ ਨਾ ਕਰੋ, ਜਾਂਚੋ। ਡਿਪਲਾਇ ਜੌਬ ਹੁਣ ਇਸ ਲਈ ਪਾਸ ਨਹੀਂ ਹੁੰਦਾ ਕਿਉਂਕਿ ਕੋਈ ਕਮਾਂਡ ਵਾਪਸ ਆਈ। ਇਹ ਹਰ ਸਰਵਰ ਦੇ API, ਔਰਕੇਸਟਰੇਟਰ, ਗੇਟਵੇ ਅਤੇ ਪ੍ਰਕਾਸ਼ਨ ਵਰਕਰ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਹੀ ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ।

ਸਮੱਸਿਆ 2: ਸਰਵਰ ਟ੍ਰੈਫਿਕ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾ ਗਿਆ

ਦੂਜੀ ਸਮੱਸਿਆ ਚੁੱਪ ਸੀ। ਜਦੋਂ ਡਿਪਲਾਇ ਸਰਵਰ ਨੂੰ ਡਰੇਨ ਕਰਦਾ ਹੈ, ਸਰਵਰ ਆਪਣੇ ਹੈਲਥ ਐਂਡਪੌਇੰਟ ’ਤੇ 503 ਦਿੰਦਾ ਹੈ ਤਾਂ ਕਿ ਲੋਡ ਬੈਲੈਂਸਰ ਉਸਨੂੰ ਰੋਟੇਸ਼ਨ ਤੋਂ ਕੱਢ ਦੇਵੇ। ਸਾਡਾ ਇਹ 5 ਸਕਿੰਟ ਲਈ ਕਰਦਾ ਸੀ, ਫਿਰ ਬੰਦ ਹੋ ਜਾਂਦਾ ਸੀ।

ਪਰ ALB ਹੈਲਥ ਚੈੱਕ ਸਿਰਫ਼ ਕਦੇ-ਕਦੇ ਕਰਦਾ ਸੀ, ਅਤੇ ਕਿਸੇ ਟਾਰਗੇਟ ਨੂੰ ਰੂਟਿੰਗ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਈ ਫੇਲ੍ਹ ਚੈੱਕ ਲਗਾਤਾਰ ਚਾਹੁੰਦਾ ਸੀ, ਲਗਭਗ 60 ਸਕਿੰਟ ਤੱਕ ਸਿਰੇ-ਤੋਂ-ਸਿਰੇ। ਇਸ ਲਈ ਲਗਭਗ 55 ਸਕਿੰਟ ਲੋਡ ਬੈਲੈਂਸਰ ਉਸ ਸਰਵਰ ਨੂੰ ਅਸਲ ਬੇਨਤੀਆਂ ਭੇਜਦਾ ਰਿਹਾ ਜੋ ਪਹਿਲਾਂ ਹੀ ਸੁਣਨਾ ਬੰਦ ਕਰ ਚੁੱਕਾ ਸੀ। ਉਹੀ ਸਾਡੇ 502 ਸਨ।

ਫਿਕਸ ਇਹ ਸੀ ਕਿ ਦੋਵੇਂ ਟਾਈਮਲਾਈਨਾਂ ਨੂੰ ਇਕਸਾਰ ਕੀਤਾ ਜਾਵੇ:

• ਟਾਰਗੇਟ ਗਰੁੱਪ ਹੁਣ ਹਰ 5 ਸਕਿੰਟ ਜਾਂਚਦਾ ਹੈ ਅਤੇ 2 ਫੇਲ੍ਹਾਂ ਬਾਅਦ ਟਾਰਗੇਟ ਨੂੰ ਅਣਹੈਲਥੀ ਮਾਰਕ ਕਰਦਾ ਹੈ। ਨੋਟਿਸ ਕਰਨ ਲਈ ਲਗਭਗ 10 ਸਕਿੰਟ।
• ਡਰੇਨ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ 15 ਸਕਿੰਟ ਬਾਅਦ ਤੱਕ ਅਸਲ ਟ੍ਰੈਫਿਕ ਸਰਵ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਕਿ ਹਮੇਸ਼ਾ ਓਵਰਲੈਪ ਰਹੇ।
• ਇਹ ਸੈਟਿੰਗਾਂ ਉਸ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਹਨ ਜੋ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਤਿਆਰ ਕਰਦੀ ਹੈ, ਕਿਸੇ ਕੰਸੋਲ ਵਿੱਚ ਨਹੀਂ ਜਿਸ ਨੂੰ ਕਿਸੇ ਨੇ ਇੱਕ ਵਾਰ ਕਲਿੱਕ ਕੀਤਾ ਸੀ।

ਨੰਬਰਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਨਾਲ ਮੇਲ ਕਰਨਾ

ਇਹ ਟਾਈਮਆਉਟ ਇੱਕ ਦੂਜੇ ’ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਡਰੇਨ ਨੂੰ ਉਸ ਸਮੇਂ ਤੋਂ ਲੰਮਾ ਚੱਲਣਾ ਪੈਂਦਾ ਹੈ ਜੋ ਲੋਡ ਬੈਲੈਂਸਰ ਨੂੰ ਨੋਟਿਸ ਕਰਨ ਲਈ ਚਾਹੀਦਾ ਹੈ; ਡਰੇਨ ਅਤੇ ਬੰਦ ਹੋਣਾ ਮਿਲ ਕੇ ਕੰਟੇਨਰ ਦੇ ਜ਼ਬਰਦਸਤੀ ਮਾਰੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਖਤਮ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਕੋਈ ਇੱਕ ਨੰਬਰ ਬਦਲ ਕੇ ਇਸ ਬੱਗ ਨੂੰ ਦੁਬਾਰਾ ਲਿਆ ਸਕਦਾ ਹੈ, ਆਸਾਨੀ ਨਾਲ।

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

ਡਿਪਲਾਇ ਨੂੰ ਮਾਪਣਾ ਆਸਾਨੀ ਨਾਲ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ

ਸਾਡੇ ਪਹਿਲੇ ਮਾਪ ਨੇ ਕਿਹਾ ਕਿ ਇੱਕ ਸਾਫ਼ ਡਿਪਲਾਇ ਲਗਭਗ 3% ਟੁੱਟਿਆ ਹੋਇਆ ਸੀ। ਅਜਿਹਾ ਨਹੀਂ ਸੀ। ਅਸੀਂ ਹਰ ਗੈਰ-200 ਜਵਾਬ ਗਿਣ ਰਹੇ ਸੀ, ਅਤੇ ਹੈਲਥ ਐਂਡਪੌਇੰਟ ਤੋਂ ਡਰੇਨ ਦੌਰਾਨ ਆਇਆ 503 ਕੋਈ ਫੇਲ੍ਹ ਨਹੀਂ, ਸਗੋਂ ਡਰੇਨ ਦਾ ਕੰਮ ਹੈ, ਬੈਲੈਂਸਰ ਨੂੰ ਦੱਸਣਾ ਕਿ ਉਸ ਸਰਵਰ ਨੂੰ ਨਾ ਚੁਣੇ ਜਦੋਂ ਉਹ ਅਸਲ ਬੇਨਤੀਆਂ ਸਰਵ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।

ਯੂਜ਼ਰ ਜੋ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ ਉਹ 502 ਹੈ: ਬੇਨਤੀ ਕਿਸੇ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੀ। ਸਿਰਫ਼ ਉਹਨਾਂ ਨੂੰ ਗਿਣਨ ਨਾਲ ਅਸਲ ਤਸਵੀਰ ਮਿਲੀ: ਤਿੰਨ ਲਗਾਤਾਰ ਪ੍ਰੋਡਕਸ਼ਨ ਡਿਪਲਾਇਆਂ ਵਿੱਚ 10, ਫਿਰ 6, ਫਿਰ 0।

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

• ਸਵੈ-ਮੁਰੰਮਤ ਨੂੰ ਯੋਜਨਾਬੱਧ ਡਾਊਨਟਾਈਮ ਦਾ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਵਾਚਡੌਗ ਜੋ ਡਿਪਲਾਇ ਅਤੇ ਕ੍ਰੈਸ਼ ਵਿੱਚ ਫਰਕ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਆਖਰਕਾਰ ਡਿਪਲਾਇ ਨਾਲ ਲੜੇਗਾ।
• ਡਰੇਨਿੰਗ ਇੱਕ ਹੱਥ-ਮਿਲਾਉਣਾ ਹੈ। ਸਰਵਰ ਨੂੰ ਉਦੋਂ ਤੱਕ ਸਰਵ ਕਰਦੇ ਰਹਿਣਾ ਪੈਂਦਾ ਹੈ ਜਦ ਤੱਕ ਲੋਡ ਬੈਲੈਂਸਰ ਸਾਬਤ ਰੂਪ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਭੇਜਣਾ ਬੰਦ ਨਾ ਕਰ ਦੇਵੇ, ਅਤੇ ਉਹ ਸਮਾਂ ਸਰਵਰ ’ਤੇ ਨਹੀਂ, ਬੈਲੈਂਸਰ ’ਤੇ ਤੈਅ ਹੁੰਦਾ ਹੈ।
• ਇਨਵੇਰੀਐਂਟ ਨੂੰ ਟੈਸਟਾਂ ਵਿੱਚ ਲਿਖੋ। ਓਪਰੇਸ਼ਨਲ ਨੰਬਰ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਨਾਲ ਜੋੜਨ ਵਾਲੇ ਟੈਸਟ ਨਹੀਂ ਬਦਲਦੇ।
• ਮਾਪਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕੀ ਮਾਪ ਰਹੇ ਹੋ। “ਗਲਤੀਆਂ” ਗਲਤ ਮੈਟ੍ਰਿਕ ਸੀ; “ਉਹ ਬੇਨਤੀਆਂ ਜੋ ਕਿਸੇ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੀਆਂ” ਸਹੀ ਸੀ।

ਜੇ ਤੁਸੀਂ Mythex ’ਤੇ ਕੋਈ ਐਪ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਤੁਹਾਨੂੰ ਨਜ਼ਰ ਨਹੀਂ ਆਉਂਦਾ, ਅਤੇ ਇਹੀ ਮਕਸਦ ਹੈ। ਸੰਬੰਧਿਤ: ਤੁਹਾਡੀ ਪ੍ਰਕਾਸ਼ਿਤ ਐਪ ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਸਮੇਂ ਕਿਵੇਂ ਚਾਲੂ ਰਹਿੰਦੀ ਹੈ।