Scott Tiger Tech Blog

Odporność na awarie

Podstawą odporności aplikacji chmurowej na awarie jest przygotowanie własnych obrazów instancji EC2 (AMI), aby być w stanie szybko uruchomić nową instancję maszyny wirtualnej. Praktykuje się nawet trzymanie w odwodzie gotowej uruchomionej instancji zapasowej (ang. spare instance) aby wprowadzenie jej do aplikacji sprowadzało się tylko do przemapowania elastycznego adresu IP.

Jeśli instancje wchodzące w skład aplikacji są bezstanowe i systematycznie podmieniane na nowsze wersje, aplikacja cały czas się odświeża.

Autoskalowanie zwykle jest używane celem dostosowania architektury sieciowej do bieżącego zapotrzebowania na zasoby, ale jak najbardziej możemy wykorzystać je do automatycznego, zaplanowanego podmieniania instancji po upływie określonego czasu, aby zapobiec chociażby wyciekom pamięci i innego rodzaju przejawom degradacji.

Pomimo tego że wolumeny EBS przechowują dane w sposób redundantny (dzięki czemu są co najmniej 20-krotnie mniej awaryjne niż przeciętny dysk twardy na rynku), łatwo jest zrobić ich migawkę (ang. snapshot) przechowywaną w S3, na podstawie której łatwo utworzyć nowy wolumen EBS.

Na szkielet odpornej na awarie aplikacji rozproszonej dobrze się nadaje usługa SQS, czyli kolejka komunikatów. Każda kolejka ma przypisany URL, przez co może być dostępna spoza chmury, o ile pozwalają na to uprawnienia (Access Control List, ACL). SQS świetnie się nadaje do rozrzucania zadań pomiędzy instancje, zwłaszcza w połączeniu z autoskalowaniem, które dopasowuje liczbę instancji do ilości zadań zalegających w kolejce. Nawet jeśli zdarzy się że wszystkie instancje przetwarzające padną, kolejka przechowuje komunikaty do 4 dni.

Usługa S3 szczególnie dobrze nadaje się do przechowywania obiektów binarnych i choć sama jest skalowalna i odporna na awarię, to może też dobrze zabezpieczać przed błędami dewelopera – dzięki włączeniu wersjonowania dla wybranych kubełków można łatwo odzyskać nieopatrznie skasowane obiekty.

Usługa RDS (relacyjnych baz danych) domyślnie tworzy backupy danych i logów każdej bazy. Na żądanie można robić migawki całych instancji RDS, co pozwala później uruchomić z takiej migawki instancję aby np. odtworzyć przypadkowo usunięte przez administratora dane. Dodatkową opcją jest tworzenie synchronicznej rezerwowej repliki bazy danych w osobnej strefie dostępności (ang. availability zone, AZ).

Czytaj więcej »

Wydawnictwo O’Reilly oferuje ok. 100 darmowych książek z dziedziny analizy danych i data science pod adresem: http://www.oreilly.com/data/free/archive.html.

Wprowadzenie

W dzisiejszym artykule zajmiemy się zagadanieniem tworzenia skalowalnych, odpornych na awarie rozproszonych aplikacji w chmurze AWS. Kluczowy jest tu styl zarządzania infrastrukturą zobrazowany schematycznie na poniższym rysunku:

1. Nowe komponenty infrastruktury są automatycznie aprowizowane z repozytorium systemu kontroli wersji w powtarzalny i przewidywalny sposób.
2. Instancje EC2 są bezstanowe, w związku z tym mogą być wyjmowane z sieci i niszczone w dowolnym momencie, bez ryzyka utraty stanu aplikacji i jej danych.

Aprowizacja nowych instancji EC2

Zdarzenia inicjujące pojawienie się nowych instancji w aplikacji rozproszonej mogą być rozmaite:

• pierwotne uruchomienie podstawowych instancji aplikacji,
• zastąpienie nowym egzemplarzem instancji która uległa awarii,
• reakcja na zwiększony ruch klientów poprzez zwiększenie liczby instancji w grupie autoskalowania,
• stopniowe wdrażanie nowej wersji oprogramowania (np. metodą blue-green).

Proces automatycznej aprowizacji nowych instancji i uruchomienie ich w kontekście aplikacji nosi nazwę rozruchu (ang. bootstrapping). Dwa najpopularniejsze sposoby rozruchu to wykorzystanie odpowiednio przygotowanych AMI (Amazon Machine Image) oraz użycie konfiguracji dynamicznej.

Czytaj więcej »

Wielką popularnością obecnie cieszy się programowanie zwinne (ang. agile software development), które rozpoczęło żywot w 2001 roku, a z czasem zdobyło wielką popularność i dość skutecznie wyparło tradycyjny „wodospadowy” model tworzenia oprogramowania. Metodyki zwinne odnoszą się zwłaszcza do współpracy pomiędzy programistami a użytkownikami biznesowymi.

Tymczasem w czeluściach procesu tworzenia oprogramowania czai się jeszcze inny konflikt, tym razem w obrębie organizacji: pomiędzy deweloperami a osobami odpowiedzialnymi za wdrożenie oprogramowania. Tradycyjnie w dużych firmach IT deweloperzy chcą szybko tworzyć i modyfikować oprogramowanie, podczas gdy na drodze staje im dział eksploatacji (ang. IT operations, czyli administratorzy, architekci infrastruktury sprzętowej i personel wsparcia klienta) zainteresowany głównie stabilnością i niezawodnością, a nie zmianami (patrz kultowy rysunek obok, pochodzący z jednej z pierwszych konferencji DevOps w 2010 roku). Na konflikcie interesów traci cała firma.

DevOps to kombinacja kultury, praktyk i narzędzi które łącznie przyspieszają dostarczanie klientom kolejnych wersji aplikacji i usług. W środowisku deweloperów DevOps skupia się na pojęciach takich jak budowanie kodu (ang. code building), testy pokrycia, testy jednostkowe, pakowanie i wdrażanie. W środowisku eksploatacji mówimy o aprowizacji (ang. provisioning), konfiguracji, orkiestracji i wdrażaniu. Dla obu obszarów wspólne pojęcia to zarządzanie wersjami, wdrażanie, wycofywanie zmian (ang. roll back) i testowanie.

Można powiedzieć, że o ile klasyczne metodyki zwinne dotyczą zwinności biznesowej, DevOps odnosi się do zwinności IT.

Czytaj więcej »

PowerPoint wciąż rządzi w świecie prezentacji, ale od dawna już istnieje szereg narzędzi do prezentowania slajdów w przeglądarce.

Mają one sporo zalet:

• przeglądarka WWW jest popularniejsza niż Windowsy z PowerPointem, co bardzo poszerza grono potencjalnych widzów,
• można podać URL do konkretnego slajdu,
• dzięki najnowszym możliwościom przeglądarek (HTML5, CSS3) nie jesteśmy zmuszani do instalowania pluginów takich jak Flash/Java; ponadto dostajemy przyjemne dla oka efekty przewijania slajdów, nawet 3D (patrz Impress.js demo),
• osoby z uzdolnieniami plastycznymi i webmasterzy mogą popisać się swoimi umiejętnościami aby uczynić pokaz wyjątkowym, pozostali mogą uzyskać zadowalające efekty niskim kosztem,
• na slajdach można zagnieździć działające aplikacje webowe,
• pokaz slajdów może na ogół działać na przeglądarkach mobilnych, obsługując przewijanie slajdów dotykiem.

Wbrew pozorom, funkcjonalność oferowana przez tego typu narzędzia jest w stanie całkiem sensownie zaspokoić potrzeby przeciętnego prelegenta. Dzisiaj chciałbym krótko zaagitować na rzecz narzędzia Reveal.js, które zwróciło moją uwagę. Dobrym punktem wyjścia jest przykładowa prezentacja, ukazująca możliwości narzędzia (patrz też obok).

Slajdy można przewijać klawiaturą (strzałki, spacja), klawisz ESC otwiera podgląd slajdów (można wybrać myszką ten do którego chcemy przejść).

Czytaj więcej »