Azure blue-green deployment

Niebieski vs zielony deployment, czyli podejście wdrożenia nowego (zielonego) deploymentu bezpośrednio po starym (niebieskim). Cechuje się ono wysokim stopniem bezpieczeństwa przy średniej prędkości wdrażania kodu produkcyjnego i przy okazji maksymalnie minimalizuje przestoje procesu wprowadzania deploymentu. Niestety ma on swoje wady w postaci wysokich zasobów obliczeniowych, co jest zasadniczym minusem całego przedsięwzięcia. Opcjonalnym podejściem gwarantującym wysoką prędkość wdrożenia jest Rolling Deployment o znacznie wyższych kosztach obliczeniowych, ale gwarantujących lepszą elastyczność projektu.

Standardowa metodologia:

1) Docker - dedykowany dla aplikacji, aby unikąnać problemów z alokacją pamięci (środowiska produkcyjne i testowe).

2) Kubernetes - do zarządzania kontenerami, tak by można było stosować automatyzację oraz skalowalność.

3) Continuous Integration/Continuous deployment (CI/CD) - czyli cały holistycznie ujęty proces automatyzacji, gdzie możemy prześledzić etapy procesu ewoluujące od wdrażania, tak aby uniknąć powstania potencjalnych błędów. Nieodzowny element w funkcjonowaniu całego procesu Blue-Green.

Proces wdrożenia oraz testowania blue-green deploymentu przebiega w tzw. izolacji, gdy w czasie rzeczywistym przekierowujemy do wdrożenia tj. green określony procent ruchu (ang. traffic). Na starcie mamy wdrożenie typu blue, które dedykowane jest pierwszej wersji modelu. Musi ulec przeskalowaniu, aby umożliwoc obsługiwanie innej liczby zadań - czyli większej niż było to na samym początku.

Interfejs wiersza polecenia skalowania platformy Azure:

az monitor autoscale rule create \

--autoscale-name $AUTOSCALE_SETTINGS_NAME \

--condition "RequestLatency > 70 avg 5m" \

--scale out 1 \

--resource $ENDPOINT_RESOURCE_ID

Alternatywna wersja skalowania - zestaw SDK (Azure Machine Learning SDK) pisany w Pythonie:

mon_client.autoscale_settings.create_or_update(

resource_group,

autoscale_settings_name,

parameters = {

"location" : endpoint.location,

"target_resource_uri" : deployment.id,

"enabled" : False

}

)

Switch, czyli przełączenie ruchu - uwzględniamy określoną procentowość dla środowiska „blue” i „green”:

stosujemy następujące wielkości %: 0, 10, 90 i 100. Definiują one poszczególny stopień ruchu, który ma ulec weryfikacji w czasie rzeczywistym. Weryfikuje to przy okazji, czy występują jakieś błędy w HTTP.

W przypadku zastosowania traffic=10% jako opcji filtrującej ruch (ang. mirrored traffic, czyli ruch lustrzany lub zdublowany) w procesie wdrażania deploymentu - klienci maja jedynie przewidywania z opcji green (z endpoint´u ruch jest odbierany w wersji green: model wersja 2 (tj. GPU). Przełączenie ruchu bazuje na zasadzie rozdysponowania procentowego ruchu np. blue: traffic= 90%, green: traffic =10%.

Po zakończeniu procesu testowania należy usunąć pierwotną wersję wdrożenia, czyli blue, bo nie bedzie już dalej potrzebne. Jeśli usuniemy finalną postać, czyli punkt końcowy wdrożenia w wersji blue, to tym samym, eliminuje się wszystkie pierwotne (podstawowe) wdrożenia.

Można to zrobić za pomocą następującego wiersza poleceń:

az ml online-endpoint delete --name $ENDPOINT_NAME --yes --no-wait