프로비저닝 큐 재작성

5년 동안 이곳에서 서버를 구매하는 데 걸린 중앙값은 결제 웹훅부터 받은 편지함에 자격 증명이 도착할 때까지 3분 20초였습니다. 아무도 불평하지 않았습니다. 대부분의 업계보다 빨랐고, 사람의 승인이 필요한 어떤 것보다 상당히 빨랐습니다.

또한 직렬이어서는 안 될 4개의 직렬 단계였으며, 일단 알아차리면 계속 눈에 띌 수밖에 없습니다. 재작성은 3월에 배포되었고 중앙값은 이제 47초, 95번째 백분위수는 4분 미만입니다.

이전 방식이 했던 일

4단계, 하나의 전역 작업자 풀, 그리고 같은 사이트의 모든 주문이 대기해야 하는 주소 풀에 대한 잠금. 조용한 화요일에는 괜찮았습니다. 프로모션 기간이나 대규모 고객이 40개의 생성 요청을 스크립트로 실행한 후 1시간 동안에는 중앙값이 두 배로 늘어나고 꼬리 부분은 12분을 넘겼습니다.

변경한 사항

이미지는 사전 시딩되며 복사되지 않습니다. 모든 노드는 카탈로그에 있는 모든 이미지에 대한 씬 클론 베이스를 보유하며 매일 밤 새로 고쳐집니다. 이제 볼륨 생성은 네트워크 풀링이 아닌 로컬 Gen4 NVMe 미러에 대한 copy-on-write 클론입니다. 이 단계는 84초에서 2초 미만으로 줄었습니다.

주소는 사전에 예약됩니다. 각 사이트는 역방향 DNS가 이미 작성된 할당된 주소의 웜 풀을 유지하며, 해당 사이트의 약 6시간 수요에 맞게 크기가 조정됩니다. 이제 할당은 잠금, 스캔, DNS 쓰기 대신 사전 구축된 풀에서 pop하는 것입니다. 46초가 약 400밀리초가 되었습니다.

큐는 사이트별로 있습니다. 프랑크푸르트의 러시가 상파울루의 생성을 더 이상 늦추지 않습니다. 당연해 보이지만 원래 설계는 그렇지 않았습니다. 원래 설계에는 사이트 4개와 엔지니어 1명이 있었기 때문입니다.

작업자는 멱등적이며 재개 가능합니다. 모든 단계에 키가 있으므로 작업자가 중간에 죽으면 반쯤 만들어진 인스턴스와 지원 티켓 대신 재개 가능한 작업이 남습니다. 실패한 생성에 대한 수동 개입은 주문 약 400건 중 1건에서 9,000건 중 1건으로 줄었습니다.

결과

과정에서 발생한 문제

3월에 11시간 동안 4개 사이트에서 씬 클론 베이스의 야간 새로 고침이 자동으로 실패했고, 사전 시딩된 Debian 이미지가 9일 지난 포인트 릴리스를 제공했습니다. 그로부터 약 90개의 인스턴스가 구축되었습니다. 지난 포인트 릴리스는 패키지 업데이트만 하면 최신 버전이 되므로 그중 어느 것도 흥미로운 방식으로 손상되지 않았지만, 서버를 구매하는 사람이 확인해야 하는 일은 아닙니다.

요청 여부와 관계없이 영향을 받은 인스턴스 90개를 모두 다시 구축하고 이메일을 보냈으며, 노드가 생성 요청을 제공하기 전에 베이스 이미지 해시를 카탈로그와 비교하는 검사를 추가했습니다. 야간 작업의 자동 실패는 가장 지루한 원인이며, 지루하기 때문에 기록할 가치가 있습니다.

여전히 느린 부분

• 사용자 지정 ISO 설치. 여전히 수동이며, 여전히 수십 분 단위로 측정되며, 일반적으로 1시간 이내에 완료됩니다. 병목 현상은 이미지가 업로더가 설명한 대로 작동하는지 사람이 확인하는 것입니다.
• Windows. 라이선스 활성화는 2~3분이 추가되며 당사가 통제할 수 없습니다.
• 베어 메탈. 같은 분이 아닌 당일. 물리적 머신에는 물리적 재구축이 필요하며, 이길 수 없는 시계를 시작하는 것보다 정직하게 견적을 드리는 것이 낫습니다.
• IPv6 /48 위임. 패브릭 구성이 더 오래된 3개 사이트에서 수동. 천천히 수정 중입니다.

여기서 멈춘 이유

인스턴스를 미리 부팅해 두고 결제만 하면 바로 넘겨주는 방식으로 중앙값을 약 20초까지 낮출 수 있습니다. 즉, 유휴 용량을 보유해야 하며, 아무도 사용하지 않는 코어 비용을 지불해야 하며, 모든 사람에게 조금 더 많은 비용을 청구하여 새 주문이 11초 더 빨라진 느낌을 받게 해야 합니다.

47초는 고객이 결제를 확인하는 체인이 당사가 하는 어떤 것보다 제약이 될 만큼 짧습니다. 고객이 인지하는 지점을 넘어 최적화하는 것은 취미이지 엔지니어링이 아닙니다.