Wsparcie load balancera aplikacji (ALB) w szyfrowaniu End-to-End HTTP/2 i gRPC

Dzięki swojej wydajności i wsparciu dla licznych języków programowania, gRPC stanowi bardzo popularny wybór dla integracji mikrousługi oraz komunikacji na linii klient-serwer. gRPC stanowi wysokiej klasy szkielet RPC (remote procedure call), używając HTPP/2 do transportu oraz Protocol Buffers w celu opisania interfejsu.

Aby użycie gRPC wraz aplikacjami było prostsze, load balancer aplikacji (ALB) od teraz wspiera szyfrowanie HTTP/2 end-to-end, umożliwiając Ci publikowanie serwisów gRPC wraz z serwisami niebędącymi gRPC poprzez pojedynczy load balancer. Możesz użyć instancji Amazon Elastic Compute Cloud (EC2) lub adresów IP (na przykład z AWS Fargate) jako targetów gRPC wraz ze wsparciem dla kontroli kondycji grup targetowych. W ten sposób możesz użyć ALB do terminacji, kierowania i bilansowania ruchu gRPC pomiędzy Twoimi mikrousługami lub pomiędzy uaktywnionym gRPC a klientami i usługami.

ALB zapewnia funkcje routingu oparte na treści w celu sprawdzenia wezwań gRPC i przekierowania ich do właściwych serwisów. Konkretniej,= ALB zapewnia kontrole kondycji, które mogą badać status kodu gRPC dla liczby żądań gRPC, logi dostępu (protokół dostępu), który różnicuje żądania gRPC oraz określone nagłówki odpowiedzi gRPC. Dodatkowo możesz czerpać korzyści z funkcji natywnych jak różne algorytmy równoważenia obciążeń i terminacji TLS.

W jaki sposób korzystać z gRPC z load balancerem aplikacji

Aby przetestować nową funkcję, rozpoczynam od przygotowania serweru aplikacji gRPC. Korzystam z języka programisty Python oraz route_guide demo zawartym w grpc repo. Używam tej aplikacji, ponieważ w szybki sposób przedstawia kilka ze sposobów, dzięki którym klient i serwer mogą komunikować się poprzez gRPC, na przykład:

• jednoargumentowe wywołanie procedury (unary remote procedure call RPC) – klient wysyła żądanie do serwera i czeka na odpowiedź, tak jak w przypadku zwykłego wywołania funkcji;
• serwerowe przesyłanie strumieniowe RPC (server-side streaming RPC) – klient wysyła żądanie do serwera, otrzymuje strumień komunikatów i czyta ze strumienia do momentu, w którym nie ma więcej komunikatów;
• przesyłanie strumieniowe RPC po stronie klienta (Client-side streaming RPC) – klient zapisuje sekwencję komunikatów, przesyła je do serwera, następnie czeka na serwer, aż przeczyta wszystkie i odeśle komunikat zwrotny;
• dwukierunkowe przesyłanie strumieniowe RPC (Bidirectional streaming RPC) – klient i serwer przesyłają komunikaty w sposób niezależny, przy zachowaniu odpowiedniej kolejności.

Po pierwsze przygotowuję Dockerfile, aby w swoim kontenerze mieć działającą aplikację route_guide. Z technicznego punktu widzeni, nie jest to konieczne, ponieważ równocześnie mógłbym użyć zwyczajnej instancji EC2, jednakże korzystanie z kontenerów z gRPC jest powszechne i sprawia, że ten przykład staje się bardziej trafny.

Tworzę obraz kontenera i wgrywam do Amazon Elastic Container Registry.

W konsoli ECS Amazona (Amazon ECS console) tworzę nowy klaster, używając opcji Networking only. Tytułuję klaster jako demo i tworzę dla niej nowy VPC, pozostawiając wszystkie inne wartości jako domyślne. Konsola ECS korzysta z AWS CloudFormation w celu skonfigurowania zasobów dla klastra. Po kilku minutach wszystkie zasoby zostają poprawnie utworzone, a ich klaster jest gotowy.

Aby dać dostęp do ruchu gRPC, tworzę grupę zabezpieczeń, która zezwala na ruch przychodzący TCP w porcie 50051 z laptopa klienta. Tytułuję tę grupę zabezpieczeń gRPC.

Następnie tworzę load balancer. W konsoli EC2 wybieram Load Balancers (po lewej stronie), a następnie Utwórz Load Balancer (Create Load Balancer). W następnym kroku tworzę aplikację load balancera (ALB) i tytułuję jako route-guide. Pozostawiam domyślne połączenie z internetem, ponieważ chcę połączyć się z serwisem gRPC poprzez publiczną sieć. W sekcji Odbiorców (Listeners) wybieram HTTPS jako protokół, a 50051 dla portu. Poniżej wybieram nowo utworzony VPC oraz dwie Strefy Dostępności (Availability Zones) utworzone przez konsolę ECS.

Potem w ustawieniach bezpieczeństwa wybieram certyfikat, który stworzyłem wcześniej, zarządzany przez AWS Certificate Manager (ACM).

Później wybieram domyślne zabezpieczenia grupy oraz grupę zabezpieczeń gRPC, którą stworzyłem powyżej. Każdy VPC automatycznie dociera z domyślną grupą zabezpieczeń, która daje sieci dostęp do pozostałych zasobów korzystających z tej samej grupy zabezpieczeń.

W sekcji routingu tworzę nową grupę targetową o nazwie route-guide. Ponieważ planuję użyć AWS Fargate do uruchomienia serwera, wybieram target adresu IP. ALB wspiera zarówno chronione, jak i niechronione połączenia dla grup targetowych korzystających z protokołu gRPC. Tutaj wykorzystuję HTTP (jako że korzystam z niechronionego połączenia pomiędzy load balancerem a kontenerami obsługującymi serwer gRPC) z portem 50051. Następnie wybieram VPC używane przez klaster ECS. Dla Wersji Protokołu (Protocol Version) korzystam z gRPC.

W zaawansowanych ustawieniach sprawdzania kondycji (Advanced health check settings) mogę określić, który z gRPC Success codes użyć podczas sprawdzania poprawnej odpowiedzi. Pozostawiam domyślnie z Code 12, co oznacza unimplemented (niezaimplementowane).

Kod 12 zostaje zwrócony przez serwer gRPC, jeśli metoda nie została znaleziona. W tym przypadku działa, ponieważ używam ścieżki, która nie jest implementowana przez aplikację route_guide. Bardziej ogólnie: sprawdzanie dla Kodu 12 stanowi szybki sposób na zweryfikowanie, czy Twój serwer gRPC działa poprawnie. Aby być bardziej precyzyjnym w sprawdzaniu kondycji, możesz użyć pojedynczego kodu, listy lub zakresu, w zależności od tego, czego oczekujesz od swojej implementacji.

W następnym kroku nie rejestruję żadnego targetu i kończę tworzenie grupy targetowej.

W konsoli ECS tworzę definicję nowego zadania, kompatybilną z typem Fargate. Tytułuję ją jako route-guide i daję minimalną liczbę zasobów: 0.5 GB pamięci i 0.25 unitów CPU. Dodaję definicję kontenera, używając obrazu URI z obrazu kontenera, który wgrałem do ECR, i portu kontenera 50051/tcp. Port sieci jest widoczny w Dockerfile powyżej.

Z wybraną definicją zadań (task definition) route-guide wybieram utwórz usługę (Create Service). Używam Fargate, route-guide jako nazwy usługi i 2 jako liczby zadań. W kolejnym kroku dodaję dwie podsieci w VPC i wybieram default zabezpieczenia grupy, aby umożliwić load balancerowi dotarcie do zadań. W sekcji Load balancing wybieram Application Load Balancer i route-guide load balancer.

Dla Container to balance wybieram route-guide:50051:50051 oraz Add to load balancer.

Następnie wybieram route-guide dla grupy targetowej.

W kolejnym kroku wybieram Do not adjust the service’s desired count, aby nie używać automatycznego skalowania w tym demo.

Kończę tworzenie usługi ECS. Po kilku minutach możemy zauważyć, że dwa zadania posiadają status RUNNING. Patrząc na tabelę Targetów w grupie targetowej route-guide, widzę, że dwa targety są zaakceptowane jako HEALTHY. Od teraz load balancer jest gotowy, aby zaakceptować ruch.

W konsoli Amazon Route 53 (Amazon Route 53 console) tworzę record DNS jako zastępczą nazwę load balancer. Używam domeny pasującej do domeny nazwy certyfikatu, którą wybrałem podczas tworzenia load balancer.

Na laptopie klienta edytuję plik route_client.py w gRPC repo, aby użyć bezpiecznego kanału, kiedy łączę się z load balancer. To jest część kodu, którą zmieniam:

Następnie uruchamiam klienta w celu przetestowania kanału gRPC z pewnym obciążeniem pracą. W informacjach wyjściowych widzę, że aplikacja route_guide używa jednoargumentowego, serwerowego, klientowego oraz dwukierunkowego przesyłania strumieniowego zarówno w żądaniu, jak i odpowiedzi.

Cóż, informacje wyjściowe są stosunkowo długie, ale tak jak powiedziałem na początku tego tekstu, demo route-guide pokazuje na wiele różnych sposobów, że klient i serwer mogą komunikować się, używając gRPC poza podstawowymi innowacjami RPC.

Dostępne od teraz

End-to-end HTTP/2 i gRPC Support są dostępne od dzisiaj dla nowych i już istniejących Application Load Balancers we wszystkich regionach. Możesz używać tej funkcji poprzez konsolę, AWS Command Line Interface (CLI) czy AWS SDK. Pracujemy także nad dodaniem wsparcia AWS Cloud Formation.

Dla korzystania z protokołu gRPC i ALB nie ma żadnych dodatkowych kosztów. Aby uzyskać więcej informacji, możesz zapoznać się z Elastic Load Balancing pricing page.

Wraz z nowymi funkcjami korzystanie z gRPC w celu integrowania Twoich aplikacji lub ulepszenia komunikacji na linii klient-serwer staje się o wiele prostsze. Aby dowiedzieć się więcej, skorzystaj z dokumentacji.

Źródło: https://aws.amazon.com/

PYTANIA? SKONTAKTUJ SIĘ Z NAMI