Artykuł z magazynu ITwizProgramowaniePolecane tematy

Borg i Kubernetes: narzędzia rozwijane przez Google w Polsce

Polski dział R&D wyspecjalizował się w budowie narzędzi do automatycznego dostosowywania zasobów IT do potrzeb ich użytkowników. Liczy już ponad 100 osób. W tym roku chce zatrudnić kilkadziesiąt kolejnych. Szybki wzrost związany jest z projektami realizowanymi wokół Google Cloud Platform.

Borg i Kubernetes: narzędzia rozwijane przez Google w Polsce

Narzędzia do automatycznego dostosowywania zasobów IT do potrzeb ich użytkowników to całkowicie polska domena w Google. Kierowany przez Jarka Kuśmierka zespół inżynierów w warszawskim biurze pracował również nad odpowiednimi modułami systemu Borg służącemu do zarządzania centrami danych Google na potrzeby kilkudziesięciu tysięcy deweloperów tej firmy, ale i systemu Kubernetes, z którego korzystają klienci Google Cloud Platform. Platforma ta służy firmom IT i programistom do tego, aby mogli oni uruchamiać kod własnych aplikacji w chmurze. W przypadku tej ostatniej platformy, polscy inżynierowie stworzyli także jej front-end, m.in. Developers Console.

Początkowo warszawski dział R&D rozwijał się powoli. Zmieniło się to, gdy polscy inżynierowie zaczęli pracować właśnie nad platformami cloud computing. Obecnie wśród 100 inżynierów – w tym ok. 20% to kobiety – pracują nie tylko programiści, ale także UX Designerzy oraz Project i Program Managerowie. Warszawski dział badawczo-rozwojowy w tym roku chce zatrudnić kilkadziesiąt kolejnych osób, w tym osoby z doświadczeniem przy realizacji projektów.

Na początku każdy  zespół deweloperów – związany z wyszukiwarką, YouTube i innymi usługami Google – martwił się o swoje zasoby. Potem inżynierowie Google zaczęli pracować nad narzędziami, które miały maksymalnie ułatwić pracę programistom, w tym automatycznie uruchamiać poszczególne procesy. Pierwszym rozwiązaniem był Borg. Celem jego stworzenia było zbudowanie abstrakcji jednej wielkiej maszyny, która się nigdy nie psuje i ma nieograniczone zasoby. Borg zarządza dziś wszystkimi centrami danych.

Znajomość technologii – choć istotna – jest mniej ważna niż umiejętność kreatywnego myślenia i podchodzenia do rozwiązywania problemów, zadawania pytań „a po co to robimy? Kandydaci muszą oczywiście znać jakiś język programowania i na jego podstawie przeprowadzana jest rozmowa z kandydatem. Stawiamy jednak na proces myślowy, a nie wiedzę. Tym bardziej że i tak wybranych kandydatów będziemy szkolić z narzędzi, które opracowujemy wewnętrznie” – mówi Jarek Kuśmierek. „Teraz oprócz programistów poszukujemy także Product Managerów, architektów, osób zarządzających zespołami programistów” – dodaje.

Dostęp do danych i zapytania SQL w wersji Google

Początkowo rozwijaliśmy tylko rozwiązania dla centrów danych Google, ułatwiających deweloperom ‘odpalanie’ kodu ich aplikacji. Odkąd uruchomiono Google Cloud Platform, rozwijamy też narzędzia dla użytkowników zewnętrznych. Pracując nad projektami dla nich, musimy jednak kłaść większy nacisk na projektowanie interfejsu użytkownika. Stąd duża u nas grupa badaczy i projektantów interfejsów użytkownika” – twierdzi Jarek Kuśmierek.

Jednym z rozwiązań, nad którymi inżynierowie w Warszawie pracują wraz ze swoimi amerykańskimi kolegami, jest DataFlow – stworzona dla klientów zewnętrznych wersja mechanizmu MapReduce. Ułatwia on dostęp do danych przechowywanych w Google File System. Ten zaś wykorzystuje koncepcję przetwarzania i przechowywania danych w systemie rozproszonym Collossus. Google stworzył także własny silnik wykonywania zapytań SQL – Dremel. Jego odpowiednikiem dla klientów zewnętrznych jest rozwiązanie o nazwie BigQuery. „Dzięki niemu można ‘wrzucić’ zgromadzone dane i uruchomić ich analizę w naszej chmurze. Użytkownicy płacą jedynie za czas wykorzystania maszyn niezbędnych do analizy danych, nawet jeśli jest to 1000 maszyn wirtualnych, które pracowały przez zaledwie 5 minut. Choć oczywiście użytkownicy Google Cloud Platform mogą skorzystać też z silnika MySQL czy innego, komercyjnego rozwiązania” – wyjaśnia Jarek Kuśmierek.

Polscy inżynierowie odpowiadają także za zarządzanie maszynami wirtualnymi w ramach Google Cloud Platform, w tym za automatyzację analizy informacji na temat tego, ile ich de facto potrzeba.

Borg: narzędzie maksymalnie ułatwiające pracę programistów Google

Jak wspomina Jarek Kuśmierek, na początku każdy z zespołów deweloperów – związanych z wyszukiwarką, YouTube i innymi usługami Google – martwił się o swoje zasoby. Potem inżynierowie Google zaczęli pracować nad narzędziami, które miały maksymalnie ułatwić pracę programistom, w tym automatycznie uruchamiać poszczególne procesy. „Pierwszym rozwiązaniem był Borg” – mówi szef warszawskiego zespołu inżynierów Google. „Celem jego stworzenia było zbudowanie abstrakcji jednej wielkiej maszyny, która się nigdy nie psuje i ma nieograniczone zasoby. Borg zarządza dziś wszystkimi centrami danych Google” – dodaje.

Podstawową jednostką w Borg jest centrum danych Google. Zaawansowany użytkownik wie, gdzie uruchomić swój program. Ten mniej zaawansowany pozostawia to systemowi Borg. Na decyzje podejmowane przez niego wpływają m.in. fakt, skąd dane są czytane najczęściej, kto z nich korzysta, a nawet to, w którym z naszych centrów danych planowane są naprawy serwisowe.

Borg zarządza pulą maszyn, a także tym, jakie systemy na nich pracują, ile zasobów potrzebują, oraz metodologią najbardziej efektywnego upakowania maszyn. Jak wspominają przedstawiciele Google, jeśli mamy mniej ważne i bardziej ważne zadania na tej samej maszynie, to możemy zarządzać nimi w sposób bardzo dynamiczny, zabierając i oddając ten sam zestaw zasobów z korzyścią dla systemu, który w danej chwili „bardziej” go potrzebuje. Borg zarządza też cyklem życia maszyn fizycznych. Informuje, gdy trzeba je naprawić. Wówczas znajdujące się na niej procesy automatycznie przenosi na inny serwer.

System ten automatycznie analizuje – bazując na analizie kodu i danych historycznych – jak dużo zasobów potrzebuje dany program. Bardziej zaawansowani użytkownicy sami określą, że ma to być np. 5 maszyn wirtualnych, każda z 10 GB pamięci RAM. Mniej zaawansowany może jednak nie mieć informacji o potrzebnych zasobach. Wówczas Borg automatycznie dostosowuje je do potrzeb jego aplikacji. Przykładowo: porównuje ją z innymi serwisami, liczbą maszyn wirtualnych, na których pracują lub pracowały. W trakcie działania tego programu samodzielnie także dostosowuje wykorzystanie infrastruktury IT – dodaje lub odbiera zasoby w przypadku, gdy są zbyt duże.

Podstawową jednostką w Borg jest centrum danych. Zaawansowany użytkownik wie, gdzie uruchomić swój program. Ten mniej zaawansowany pozostawia to naszemu systemowi. Na decyzje podejmowane przez Borga wpływają m.in. fakt, skąd dane są czytane najczęściej, kto z nich korzysta, a nawet to, w którym z naszych centrów danych planowane są naprawy serwisowe” – opowiada Jarek Kuśmierek.

Zarządzanie klastrami kontenerów i maszyn wirtualnych

Deweloperzy w Google do uruchamiania swoich programów i usług wykorzystują kontenery. W kontenerach mechanizm izolacji istnieje na poziomie systemu operacyjnego, który znajduje się na hoście. „Tak naprawdę tę funkcjonalność zbudowaliśmy my i dorzuciliśmy ją do jądra Linuksa. Na tej podstawie powstał Docker” – mówi Jarek Kuśmierek. Wszystkie kontenery w Google – a co tydzień powstaje ich ponad 2 miliardy –  korzystają z tej samej dystrybucji systemu Linux, który znajduje się po stronie hosta. W kontenerze nie ma też zapisanych plików. Dzięki temu taka maszyna „wstaje” znacznie szybciej niż w kilkadziesiąt sekund, jak w przypadku maszyn wirtualnych.

Kubernetes rozwijany jest przez inżynierów Google w Polsce. Zarządza klastrem maszyn, na których można uruchamiać kontenery. Rozwiązanie to samodzielnie przydziela niezbędne zasoby. Użytkownik nie musi martwić się, na jakiej maszynie i ile kontenerów zostanie uruchomionych. Nawet jeśli system ma budowę wielowarstwową, jest oparty na mikroserwisach, to Kubernetes automatycznie odwzorowuje jego strukturę, a następnie wyskaluje niezbędne zasoby.

Maszyny wirtualne oferowane są w ramach Google Cloud Platform, ale tylko dlatego, że jej użytkownicy chcą mieć swobodę m.in. w wyborze systemu operacyjnego, skorzystać z innej dystrybucji Linuksa czy systemu Windows. Później – wewnątrz maszyny wirtualnej – użytkownicy mogą zarządzać swoim oprogramowaniem bezpośrednio lub pakując je w kontenery, jeśli chcą uruchomić więcej niż jeden program w maszynie wirtualnej. Do zarządzania zestawem kontenerów uruchomionych w klastrze maszyn wirtualnych wykorzystywany jest system Kubernetes.

Więcej w numerze ITwiz 4/2016, z którego pochodzi ten artykuł.
Tagi

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *