etcd ਨਾਲเอਸ਼ੀ-ਪੈਸੀਫਿਕ ਵੀਡੀਓ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੂਟ ਕਰਨਾ
ਅੱਠเอਸ਼ੀ-ਪੈਸੀਫਿਕ ਬਾਜ਼ਾਰਾਂ ਨੂੰ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰਨ ਵਾਲੇ ਇੱਕ ਵੀਡੀਓ-ਸਟ੍ਰੀਮਿੰਗ ਪਲੇਟਫਾਰਮ ਨੇ ਖੇਤਰ-ਵਿਸ਼ੇਸ਼ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ etcd ਵਿੱਚ ਬਦਲ ਕੇ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੀ ਰੂਟਿੰਗ ਦੀ ਗਲਤੀ ਨੂੰ ਰੋਕ ਦਿੱਤਾ। ਰੂਟਿੰਗ ਤਬਦੀਲੀਆਂ ਲਈ ਪ੍ਰੋਪਗੇਸ਼ਨ ਸਮਾਂ ਘਟ ਕੇ ਲਗਭਗ ਇੱਕ ਸਕਿੰਟ ਰਹਿ ਗਿਆ। ਐਡੀਟਰ ਹੁਣ ਕੋਡ ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਕੁਝ ਘੰਟਿਆਂ ਲਈ ਮਿਊਜ਼ਿਕ ਪੂਲ ਨੂੰ ਵਧਾ (boost) ਸਕਦੇ ਸਨ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਨੇ ਦੱਖਣੀ ਕੋਰੀਆ ਦੇ ਦਰਸ਼ਕਾਂ ਨੂੰ ਟੋਕੀਓ ਫੀਡ ਭੇਜਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ।
ਪੁਰਾਣਾ ਤਰੀਕਾ ਕਿਉਂ ਫੇਲ ਹੋ ਗਿਆ
ਹਰ ਰਿਕਵੈਸਟ ਲਈ ਹਰੇਕ ਰੂਟਰ ਤਿੰਨ ਮੁੱਲ ਪੜ੍ਹਦਾ ਸੀ: ਟ੍ਰੈਂਡਿੰਗ ਪੂਲ, ਭਾਸ਼ਾ-ਵਿਸ਼ੇਸ਼ ਟੋਕਨਾਈਜ਼ਰ, ਅਤੇ ਫਾਲਬੈਕ ਚੇਨ। ਵਪਾਰਕ ਫੈਸਲੇ—ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਨਵੇਂ ਕਲਾਕਾਰ ਨੂੰ ਪ੍ਰਮੋਟ ਕਰਨਾ, ਖੇਤਰੀ ਰੁਕਾਵਟ (outage) ਪ੍ਰਤੀ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣਾ, ਜਾਂ ਰਿਕਮੈਂਡੇਸ਼ਨ ਐਲਗੋਰਿਦਮ ਦੀ ਜਾਂਚ ਕਰਨਾ—ਉਨ੍ਹਾਂ ਮੁੱਲਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਸਨ, ਕੋਡ ਤਬਦੀਲੀਆਂ ਨੂੰ ਨਹੀਂ।
ਸ਼ੁਰੂ ਵਿੱਚ, ਹਰੇਕ ਡਿਪਲਾਈਮੈਂਟ ਰੂਟਿੰਗ ਟੇਬਲ ਦੇ ਨਾਲ ਇੱਕ JSON ਫਾਈਲ ਨੂੰ ਬੰਨ੍ਹ ਦਿੰਦਾ ਸੀ। ਕਿਸੇ ਘਟਨਾ ਦੌਰਾਨ, ਇੱਕ ਆਨ-ਕਾਲ ਇੰਜੀਨੀਅਰ ਨੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬੈਕਅੱਪ ਪੂਲ ਵੱਲ ਮੋੜਨ ਲਈ ਇੱਕ ਨੋਡ 'ਤੇ ਫਾਈਲ ਨੂੰ ਐਡਿਟ ਕੀਤਾ, ਪਰ ਬਾਕੀ ਸੱਤ ਨੋਡਾਂ ਨੂੰ ਕਦੇ ਅਪਡੇਟ ਨਹੀਂ ਕੀਤਾ। ਕੌਂਫਿਗ ਡ੍ਰਿਫਟ (Config drift) ਦੀ ਸਥਿਤੀ ਪੈਦਾ ਹੋ ਗਈ: ਅੱਠ ਦੇਸ਼ ਵੱਖ-ਵੱਖ ਟੇਬਲਾਂ 'ਤੇ ਚੱਲ ਰਹੇ ਸਨ, ਅਤੇ ਕੋਈ ਵੀ ਇੱਕ ਸਰੋਤ "ਸੱਚਾਈ" (truth) ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ। ਉਹ ਬੱਗ ਜੋ ਸਿਓਲ ਦੇ ਦਰਸ਼ਕਾਂ ਨੂੰ ਟੋਕੀਓ ਭੇਜ ਰਿਹਾ ਸੀ, ਉਹ ਬਣਿਆ ਰਿਹਾ ਕਿਉਂਕਿ ਕੋਡ ਉਹੀ ਰਿਹਾ; ਸਿਰਫ ਲੁਕੀ ਹੋਈ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵੱਖਰੀ ਸੀ।
ਸਿੰਗਲ ਸੋਰਸ ਆਫ ਟਰੂਥ ਵਜੋਂ etcd ਦੀ ਚੋਣ ਕਰਨਾ
ਟੀਮ ਨੇ ਤਿੰਨ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕੀਤੀ:
- SQLite/MySQL – ਇਹ ਹਰੇਕ ਰੂਟਰ ਨੂੰ ਡਾਟਾਬੇਸ ਨੂੰ ਪੋਲ (poll) ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ, ਜਿਸ ਨਾਲ ਲੇਟੈਂਸੀ ਵਧਦੀ ਜਾਂ ਕੁਏਰੀਆਂ ਦੀ ਭੀੜ ਹੋ ਜਾਂਦੀ।
- Consul – ਇੱਕ ਮਜ਼ਬੂਤ ਸਰਵਿਸ-ਡਿਸਕਵਰੀ ਟੂਲ, ਪਰ ਪਲੇਟਫਾਰਮ ਨੂੰ ਇਸਦੇ ਪੂਰੇ ਮੈਸ਼ ਫੀਚਰਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ।
- etcd – ਇੱਕ ਮਜ਼ਬੂਤ ਇਕਸਾਰ (strongly consistent) ਕੀ-ਵੈਲਯੂ ਸਟੋਰ, ਜਿਸ ਵਿੱਚ ਇੱਕ watch ਪ੍ਰੀਮੇਟਿਵ ਹੈ ਜੋ ਕਿਸੇ ਕੀ (key) ਦੇ ਬਦਲਦੇ ਹੀ ਕਲਾਇੰਟਸ ਨੂੰ ਸੂਚਿਤ ਕਰਦਾ ਹੈ।
'watch' ਫੀਚਰ ਨੇ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ। ਹਰੇਕ ਰੂਟਰ ਦੁਆਰਾ ਵਾਰ-ਵਾਰ "ਕੀ ਕੁਝ ਬਦਲਿਆ ਹੈ?" ਪੁੱਛਣ ਦੀ ਬਜਾਏ, ਰੂਟਰ ਉਦੋਂ ਤੱਕ ਵਿਹਲੇ ਰਹੇ ਜਦੋਂ ਤੱਕ etcd ਨੇ ਅਪਡੇਟ ਨਹੀਂ ਭੇਜਿਆ। ਬੇਲੋੜਾ ਨੈਟਵਰਕ ਟ੍ਰੈਫਿਕ ਖਤਮ ਹੋ ਗਿਆ ਅਤੇ ਹਰੇਕ ਇੰਸਟੈਂਸ ਨੇ ਇੱਕੋ ਸਮੇਂ ਤਬਦੀਲੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰ ਲਈ।
ਉਹ ਪੈਟਰਨ ਜੋ ਸਿਸਟਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੇ ਹਨ
ਸਿਰਫ਼ etcd ਨੇ ਸਾਰੇ ਜੋਖਮਾਂ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕੀਤਾ। ਇੰਜੀਨੀਅਰਾਂ ਨੇ ਤਿੰਨ ਪੂਰਕ ਪੈਟਰਨ ਜੋੜੇ:
- Leases – ਇੱਕ ਐਡੀਟਰ ਇੱਕ ਅਸਥਾਈ ਬੂਸਟ ਸੈੱਟ ਕਰ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਛੇ ਘੰਟਿਆਂ ਲਈ ਕੋਰੀਅਨ-ਪੌਪ ਪੂਲ ਦਾ ਭਾਰ ਵਧਾਉਣਾ)। ਲੀਜ਼ ਆਪਣੇ ਆਪ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਮੈਨੂਅਲ ਰੋਲਬੈਕ ਤੋਂ ਬਿਨਾਂ ਬੂਸਟ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।
- Compare-and-swap (CAS) – ਜਦੋਂ ਦੋ ਲੋਕ ਇੱਕੋ ਸਮੇਂ ਇੱਕੋ ਸੈਟਿੰਗ ਨੂੰ ਐਡਿਟ ਕਰਦੇ ਹਨ, ਤਾਂ CAS ਇੱਕ ਲਈ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਚੁੱਪਚਾਪ ਓਵਰਰਾਈਟ ਹੋਣ ਤੋਂ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ।
- Sidecar process – PHP ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਕਨੈਕਸ਼ਨਾਂ ਨਾਲ ਸੰਘਰਸ਼ ਕਰਦਾ ਹੈ। ਹਰੇਕ ਬਾਕਸ 'ਤੇ ਇੱਕ ਛੋਟਾ Go sidecar etcd 'ਤੇ ਨਜ਼ਰ ਰੱਖਦਾ ਹੈ ਅਤੇ ਰੂਟਿੰਗ ਟੇਬਲ ਦਾ ਇੱਕ ਸਨੈਪਸ਼ੌਟ ਸ਼ੇਅਰਡ-ਮੈਮੋਰੀ ਫਾਈਲ (
/dev/shm) ਵਿੱਚ ਲਿਖਦਾ ਹੈ। PHP ਉਸ ਸਥਾਨਕ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਰਿਕਵੈਸਟ ਹੈਂਡਲਿੰਗ ਦੌਰਾਨ ਕਿਸੇ ਵੀ ਨੈਟਵਰਕ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਬਣੀ ਲਚਕਤਾ
ਨਵਾਂ ਡਿਜ਼ਾਈਨ ਕਈ ਸੁਰੱਖਿਆ ਜਾਲ (safety nets) ਜੋੜਦਾ ਹੈ:
- Zero-latency reads – PHP hot path ਸਥਾਨਕ ਮੈਮੋਰੀ ਤੋਂ ਪੜ੍ਹਦਾ ਹੈ, ਇਸ ਲਈ ਰਿਕਵੈਸਟਾਂ ਰਿਮੋਟ ਸਟੋਰ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹੋਏ ਕਦੇ ਵੀ ਨਹੀਂ ਰੁਕਦੀਆਂ।
- Graceful degradation – ਜੇਕਰ etcd ਡਾਊਨ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਰੂਟਰ ਆਖਰੀ ਜਾਣੇ ਗਏ ਸਹੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਸੇਵਾ ਜਾਰੀ ਰੱਖਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਅਚਾਨਕ ਰੁਕਾਵਟ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
- Reliable updates – sidecar ਰੀਕਨੈਕਸ਼ਨ ਲੌਜਿਕ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕੋਈ ਵੀ ਤਬਦੀਲੀ ਨਹੀਂ ਛੁੱਟਦੀ, ਭਾਵੇਂ etcd ਕਨੈਕਸ਼ਨ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਡਿੱਗ ਜਾਵੇ।
ਜ਼ਮੀਨੀ ਪੱਧਰ 'ਤੇ ਕੀ ਬਦਲਿਆ
ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਬਾਅਦ, ਟੀਮ ਨੇ ਪੁਰਾਣੇ ਜਾਂ ਗਲਤ ਰੂਟਿੰਗ ਡੇਟਾ ਕਾਰਨ ਹੋਣ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਵਿੱਚ ਭਾਰੀ ਕਮੀ ਦੇਖੀ। ਹੁਣ ਇੱਕ ਸਿੰਗਲ ਕੰਸੋਲ ਮੌਜੂਦਾ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਐਡਿਟ ਇੱਕ ਸਕ
ਕਿਸੇ ਵੀ ਅਜਿਹੀ ਸਰਵਿਸ ਲਈ ਜਿਸ ਨੂੰ ਕਈ ਰੀਜਨਾਂ ਵਿੱਚ ਤੇਜ਼ ਅਤੇ ਤਾਲਮੇਲ ਵਾਲੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, etcd ਦੇ watch, lease, ਅਤੇ transaction primitives, ਫਾਈਲ-ਅਧਾਰਤ ਕੌਂਫਿਗਸ ਜਾਂ ਭਾਰੀ meshes ਦੇ ਇੱਕ ਹਲਕੇ ਅਤੇ ਮਜ਼ਬੂਤ ਤੌਰ 'ਤੇ ਇਕਸਾਰ (strongly consistent) ਵਿਕਲਪ ਪੇਸ਼ ਕਰਦੇ ਹਨ। ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਇੱਕ push-driven, self-cleaning ਸਟੋਰ ਵਿੱਚ ਬਦਲਣ ਨਾਲ ਘਟਨਾਵਾਂ ਦੀ ਇੱਕ ਪੂਰੀ ਸ਼੍ਰੇਣੀ ਖ਼ਤਮ ਹੋ ਗਈ ਅਤੇ ਪਲੇਟਫਾਰਮ ਨੂੰ ਇਸਦੇ routing logic ਉੱਤੇ ਰੀਅਲ-ਟਾਈਮ ਕੰਟਰੋਲ ਮਿਲਿਆ।