Strategie optymalizacji wydajności

Terraform to potężne narzędzie, ale w przypadku dużej lub złożonej infrastruktury operacje mogą trwać długo. Optymalizacja konfiguracji ma kluczowe znaczenie z kilku powodów:

• Szybsze cykle wdrażania: Krótszy czas wykonywania plan i apply oznacza szybsze iteracje i dostarczanie zmian.
• Niższe koszty chmury: Efektywne projektowanie zasobów często przekłada się na niższe wydatki na infrastrukturę.
• Lepsze doświadczenie programistów: Mniej czekania, więcej działania!

Przyjrzyjmy się strategiom, dzięki którym przepływy pracy Terraform będą szybsze i bardziej efektywne.

Domyślnie Terraform został zaprojektowany z myślą o efektywności. Automatycznie analizuje konfigurację, aby zbudować graf zależności.

Graf ten określa, które zasoby zależą od innych. Niezależne zasoby mogą być tworzone, aktualizowane lub niszczone jednocześnie (równolegle). Znacząco przyspiesza to operacje w porównaniu z przetwarzaniem sekwencyjnym.

• Graf zależności: Terraform odwzorowuje relacje między zasobami.
• Współbieżność: Niezależne operacje są wykonywane jednocześnie.

Mogą Państwo precyzyjnie dostosować poziom równoległości Terraform za pomocą flagi -parallelism używanej z terraform apply lub terraform destroy. Ustawia ona maksymalną liczbę jednocześnie wykonywanych operacji.

Wyższa wartość może przyspieszyć operacje, ale może też doprowadzić do osiągnięcia limitów zapytań API dostawcy chmury lub powodować konflikty. Niższa wartość może być przydatna podczas debugowania lub ograniczania obciążenia. Wartość domyślna to 10.

Przykład: aby ograniczyć liczbę jednoczesnych operacji do 5:

Jedną z najbardziej znaczących strategii optymalizacji jest po prostu udostępnianie mniejszej liczby zasobów. Każdy zasób zarządzany przez Terraform zwiększa obciążenie związane z planowaniem, wywołaniami API i zarządzaniem stanem.

Przed zdefiniowaniem nowego zasobu proszę rozważyć:

• Czy ten zasób jest absolutnie niezbędny do osiągnięcia bieżącego celu?
• Czy zamiast tworzyć nowy zasób można ponownie wykorzystać istniejące zasoby lub skonfigurować je inaczej?
• Czy są dostępne bardziej opłacalne typy zasobów spełniające wymagania?

Źródła danych są przydatne do dynamicznego pobierania informacji o istniejącej infrastrukturze chmurowej lub usługach zewnętrznych. Dzięki temu konfiguracje są elastyczne i dostosowują się do zmian.

Każde źródło danych zazwyczaj skutkuje jednym lub większą liczbą wywołań API podczas faz plan i apply. Jeśli wartość jest rzeczywiście statyczna, niezmienna i znana w czasie konfiguracji (np. region AWS), przekazanie jej jako zmiennej wejściowej lub wpisanie jej na stałe może wyeliminować niepotrzebne zapytania do API i przyspieszyć operacje.

Wiele providerów Terraform oferuje specjalne opcje konfiguracji, które mogą wpływać na wydajność. Ustawienia te często określają sposób komunikacji providera z bazowym API chmury.

Przykłady:

• max_retries: Dostosowanie liczby prób ponawianych przez providera po nieudanym wywołaniu API.
• Pula połączeń: Niektórzy providerzy mogą oferować ustawienia umożliwiające ponowne wykorzystanie ustanowionych połączeń.
• Buforowanie uwierzytelniania: Korzystanie ze współdzielonych plików danych uwierzytelniających lub przejmowania roli może przyspieszyć początkowe uzgadnianie uwierzytelniania.

Zawsze należy zapoznać się z dokumentacją używanego providera dotyczącą opcji związanych z wydajnością.

Każda operacja na zasobie (utworzenie, odczyt, aktualizacja, usunięcie) oraz każde zapytanie źródła danych przekłada się na jedno lub więcej wywołań API dostawcy chmury. Konfiguracja Terraform zawierająca setki pojedynczych, niewielkich zasobów może generować dużą ilość ruchu API.

Aby ograniczyć liczbę zapytań do API:

• Łączenie zasobów: Jeśli to możliwe, należy łączyć wiele małych zasobów w mniejszą liczbę większych (np. jedna grupa zabezpieczeń dla wielu instancji).
• Używanie pętli: Należy wykorzystywać for_each lub count do efektywnego zarządzania podobnymi zasobami, zamiast deklarować każdy z nich osobno.

Flaga -target pozwala zastosować zmiany tylko do określonych zasobów lub modułów. Może to znacznie przyspieszyć operacje podczas debugowania lub naprawiania odizolowanego problemu dotyczącego pojedynczego zasobu.

Flagi -target należy jednak używać z najwyższą ostrożnością! Pomija ona pełny graf zależności Terraform, co może prowadzić do rozbieżności stanu, niekompletnych wdrożeń lub nieoczekiwanych skutków ubocznych. Zasadniczo odradza się jej stosowanie podczas rutynowych wdrożeń całej infrastruktury.

Przykład: aby zastosować zmiany tylko do instancji EC2 o nazwie „web”:

Plik stanu Terraform to kluczowy składnik, który śledzi wdrożoną infrastrukturę. Bardzo duży lub złożony plik stanu może spowalniać operacje plan i apply, ponieważ Terraform musi go odczytać, przeanalizować i przetworzyć.

Wskazówki dotyczące utrzymywania niewielkiego i wydajnego pliku stanu:

• Mniejsze moduły: Należy używać ukierunkowanych modułów do pojedynczych celów zamiast modułów monolitycznych.
• Dzielenie konfiguracji: W przypadku bardzo dużej infrastruktury warto rozważyć podzielenie konfiguracji na kilka mniejszych modułów głównych, z których każdy ma własny plik stanu.
• Usuwanie osieroconych zasobów: Należy ostrożnie używać terraform state rm do usuwania zasobów, które już nie istnieją lub nie są już zarządzane przez Terraform.

Które z poniższych strategii mogą pomóc zoptymalizować wydajność i czas wykonywania Terraform?

Omówiliśmy kilka kluczowych strategii optymalizacji konfiguracji Terraform pod kątem lepszej wydajności i efektywności:

• Zrozumienie i dostosowanie równoległości operacji Terraform.
• Projektowanie konfiguracji z użyciem mniejszej liczby połączonych zasobów w celu ograniczenia obciążenia.
• Staranne równoważenie użycia źródeł danych i wartości statycznych.
• Optymalizacja konfiguracji providera w celu usprawnienia komunikacji z API.
• Ograniczenie łącznej liczby wywołań API dostawców chmury.
• Selektywne i niezwykle ostrożne używanie -target do konkretnych poprawek.
• Utrzymywanie niewielkiego i uporządkowanego pliku stanu.

Stosując te techniki, mogą Państwo uzyskać szybsze wdrożenia, obniżyć koszty chmury i poprawić ogólną łatwość zarządzania infrastrukturą jako kodem.