Postmortem problemów z 15.03.2019 - timeouty i ucięte odpowiedzi

### Analiza niestabilności WebAPI - timeout'y i ucięte odpowiedzi

Poniżej znajdziecie dokładny opis błędu związany z wątkami: #1358, #1353, #1393 i #1402

W **piątek 15 marca o godzinie 16:00** zaczęliśmy dostawać zgłoszenia o zwiększonej liczbie timeout'ów oraz uciętych odpowiedziach, między innymi przy pobieraniu WSDL'a.
Jednocześnie po naszej stronie zaczęliśmy obserwować zwiększone czasy odpowiedzi na niektórych metodach WebAPI.

Żądanie do Allegro WebAPI przechodzi przez kilka warstw. Load balancery, usługa API Gateway i na końcu nasza monolityczna aplikacja. Tam również obsługa może być hybrydowa, to znaczy częściowo przez monolit i częściowo przez mikrousługi.

Z tego powodu analiza powyższego problemu była złożona. Zwiększone czasy odpowiedzi widzieliśmy na zbiorczych metrykach API Gateway. Tam też pojawiły się timeout'y na linii gateway - monolit. Jednak metryki dla samych metod były w normie. Dlatego w pierwszej kolejności założyliśmy, że problem miał charakter aplikacyjny i był związany z użyciem zasobów bądź zakleszczeniem wątków. Sprawdziliśmy, czy coś się zmieniło na platformie bądź w infrastrukturze, ale w tym czasie nie było żadnych wdrożeń ani zmian konfiguracyjnych.

Problem był o tyle trudny, że nie byliśmy w stanie zreprodukować błędów, a części zgłoszeń nie widzieliśmy w naszych logach. Dzięki wskazówce @mindc (https://github.com/allegro/allegro-api/issues/1402#issuecomment-476546466), skierowaliśmy się w stronę analizy ruchu sieciowego. W zgłoszeniach błędów od użytkowników API przodował jeden dostawca usług hostingowych i na nim się skupiliśmy.

Analiza wykazała, że 15.03 ok. 16:00 dostaliśmy trasy (via BGP) jednego z dużych dostawców hostingu z jednego z punktów wymiany ruchu (IX) z których korzystamy, co spowodowało automatycznie wybranie tej trasy jako najlepszej i przekierowanie na nią ruchu (trasa miała najkrótszy AS_PATH). Weryfikując logi znaleźliśmy korelację pomiędzy rozpoczęciem problemów w dostępie do API, a zmianą w routingu (pojawienie się prefixów dostawcy w IX). Zrobiliśmy test polegający na przekierowaniu ruchu do danej sieci (ASN) innym łączem, co sprawiło, że błędy przestały występować. Obecnie ignorujemy trasy od tego uczestnika w IX i problemy nie występują. Nie obserwowaliśmy i nie obserwujemy na naszych łączach do punktu wymiany ruchu problemów w łączności do innych uczestników.