Kamil Wysocki - Jak zrobić bramkę zdolną przyjąć miliony danych i nie strzelić sobie gola
•
0 gefällt mir•69 views
Wyobraźcie sobie sytuację, w której Klient chce przyjmować dane raportowe od 2 mln użytkowników. Dane każdego użytkownika są w różnych rozmiarach od 1B do 200GB. Wysyłane są co miesiąc, zazwyczaj tydzień przed terminem, w godzinach pracy... Brzmi jak konkretny DDoS? Zaprezentuję praktyczny „use case” tego typu systemu. Omówię krok po kroku jak go zbudowaliśmy, jakie błędy przy tym popełniliśmy i jak wyszliśmy z nich obronną ręką. System został zaprojektowany i zbudowany w środowisku Azure.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Kamil Wysocki - Jak zrobić bramkę zdolną przyjąć miliony danych i nie strzelić sobie gola
Ähnlich wie Kamil Wysocki - Jak zrobić bramkę zdolną przyjąć miliony danych i nie strzelić sobie gola (20)
Kamil Wysocki - Jak zrobić bramkę zdolną przyjąć miliony danych i nie strzelić sobie gola
- 1. Jak zrobić bramkę zdolną przyjąć miliony danych i nie strzelić sobie gola? Use case Kamil Wysocki – Cloud Solutions Architect, Billennium (kamil.wysocki@billennium.pl) Wybierz grafikę lub jeden z kolorów z koła kolorystycznego
- 2. Agenda • O mnie • Opis przypadku • Jak zrobić bramkę? • Problemy, błędy • Statystyki • Podsumowanie • Pytania
- 3. O mnie • Programista, architekt • 10 lat doświadczenia • Billennium Lab (R&D) • Pasjonat technologii chmurowych
- 4. Use case: chcę odebrać pliki! • Cyklicznie • Zazwyczaj tuż przed terminem • W godzinach pracy • O różnych rozmiarach (1KB – 300GB) • Od 2 mln klientów • Nie w moim data centrum! • Bezpiecznie
- 5. Azure Network 1. Własna sieć szkieletowa 2. Wbudowana systemy anty DDoS 3. Możliwość blokowania ataków DDoS na węzłach u partnerów
- 6. Proste. Chmura wszystko przyjmie ;) 1. Klienci wysyłają do chmury 2. Chmura przekazuje do data center 3. Data center potwierdza przyjęcie 4. Chmura potwierdza przyjęcie Rest Api
- 8. Valet Key Pattern • Azure Storage Blob • SAS • Komunikacja bezpośrednio do Azure Storage
- 9. REST API 1. Init Upload 2. Put (Azure Storage Blob REST Api) 3. Finish Upload 4. Status
- 10. Init Upload • Metadane biznesowe • Metadane o wysyłce • Informacja o wysyłanym pliku (MD5) • Podpis elektroniczny zgodny z Xades- Bes
- 11. Init Upload - response 1. Losowy storage 2. SAS – wygenerowany z policy 3. Dynamiczny timeout 4. MD5 5. HttpClient, SDK: .NET, Node.js, Java, C++, PHP, Ruby, Python, iOS, Xamarin
- 12. PutBlob
- 15. Baza danych 1. Co trzymamy w bazie? 2. Sql, czemu nie? 3. Insert, Select! 4. A kiedy wszystko już jest gotowe… 5. Testy wydajnościowe 6. Azure Storage Account Table
- 16. IntegracjaIntegracja z inną firmą IT
- 17. Integracja 1. Informacja o nowej wysyłce trafia do kolejki 2. Datacenter odbiera wiadomość tak szybko jak potrafi 3. Pobiera paczkę z Bloba 4. Wysyła informacje o statusach 5. Bramka pobiera informacje o statusach Storage CQRS (RA-GRS) Azure Service Bus Queue bramkabramka Azure Storage Blob Data centrumData centrum 1 2 3 4 3 Azure Service Bus Queue 5
- 18. Status • 44K w ciągu 2h • Nie mamy wpływu jak klienci używają naszego API • Throttling • Azure Redis Cache • SaaS – 250MB-530GB RAM
- 20. Statystyki • Avg. Response time 30 days
- 21. ASE – Statystyki • App Service Environment
- 22. Podsumowanie • Trudne w on-premises • Łatwe w chmurze
- 24. IT dla ludzi. Ludzie dla IT. Billennium Sp. z o.o. Ul. Tagore 3 02-647 Warszawa Poland www.billennium.pl +48 22 844 15 00 info@billennium.pl