Scott Tiger Tech Blog

W dzisiejszym artykule będziemy się zasadniczo poruszać w konsoli webowej właściciela konta AWS, we frontendzie usługi Billing.

Okres rozliczeniowy kończy się o północy ostatniego dnia każdego miesiąca, a na ogół faktura jest wystawiana w ciągu następnych 7 dni księgowych.

Promocja przez pierwszy rok

Przez pierwszy rok po założeniu konta AWS obowiązuje promocja, w ramach której za użycie szeregu usług (do pewnych granic, zależnych od usługi) nie zapłacimy nic – patrz Free Tier. Jeśli nie wykorzystasz wszystkich dobrodziejstw promocji w danym miesiącu, nie przenoszą się one na następny miesiąc. Gdy kończy się czas działania promocji, na adres email podany przy zakładaniu konta przychodzi stosowne powiadomienie.

Na kokpicie bilingowym można na bieżąco śledzić zużycie najdroższych zasobów w ramach promocji, z widocznymi ostrzeżeniami w razie spodziewanego przekroczenia limitu w miesiącu – patrz rysunek.

Faktura

Możesz oglądać sobie PDFy faktur z dowolnego miesiąca na zakładce Bills. Z combo wybieramy dowolny miesiąc z przeszłości, a link do faktury uzyskujemy rozwijając gałąź Usage Charges and Recurring Fees, jak na poniższym rysunku:

Jak widać, można też łatwo ściągnąć dane w formacie CSV.

Czytaj więcej »

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 »