O tym, jak uczyłem się rzeczy zbędnych i dlaczego było warto

W ostat­nich dni­ach być może zauważyłaś, że nasza strona ład­owała się powoli. Baaard­zo powoli — mówimy o ok. min­u­cie cza­su. Bez bicia przyz­nam się, że to moja wina — co więcej, zro­biłem to z pełną pre­m­e­dy­tacją. Dlaczego? To bard­zo dobre pytanie…

Zaczni­jmy od początku, czyli co właś­ci­wie się zadzi­ało. Od jakiegoś cza­su blog jest hos­towany na naszym włas­nym ser­w­erze (VPSie dokład­niej rzecz ujmu­jąc, ale na potrze­by tego wpisu nie ma to więk­szego znaczenia). Sam host­ing www był w tym cza­sie całkowicie po naszej stron­ie, ale nadal korzys­tał z bazy danych zarządzanej przez zewnętrzną fir­mę. Zmi­any, które wprowadza­łem zasad­nic­zo sprowadza­ły się do prze­niesienia bazy danych na naszą włas­ną infra­struk­turę, a ponieważ moją wiedzę i doświad­cze­nie na tem­at admin­is­tracji baz danych moż­na pod­sumować liczbą 0, nie obyło się bez prob­lemów. W tym momen­cie zapewne zaczy­nasz zas­tanaw­iać się “ale po co / dlaczego??” i jest to jak najbardziej uza­sad­nione pytanie.

Z oszczędności?

To oczy­wiś­cie pier­wszy sen­sowny powód który może przyjść do głowy — w końcu blog prowadz­imy hob­bysty­cznie, nie wyświ­et­lamy (i nie planu­je­my) reklam ani nie naw­iązu­je­my komer­cyjnej współpra­cy z fir­ma­mi. Host­ing oczy­wiś­cie kosz­tu­je, a że kosz­ty pokry­wamy z włas­nej kieszeni to fajnie było­by je ograniczyć. Chci­ałbym tutaj zauważyć że cała migrac­ja zabrała mi około 30 godzin poświę­conych tylko na nią. Różni­ca w kosz­tach przed i po migracji to ok. 10$ miesięcznie, więc nawet nie uwzględ­ni­a­jąc cza­su który będzie potrzeb­ny na utrzy­manie nowej bazy danych, po uwzględ­nie­niu kosz­tu mojego cza­su wyszedłbym ‘na zero’ za co najm­niej kil­ka lat. Także zde­cy­dowanie nie był to powód migracji.

To pewnie wydajność/bezpieczeństwo?

To też wyglą­da na log­iczne uza­sad­nie­nie na pier­wszy rzut oka — w końcu utrzymy­wanie ser­w­era i bazy danych na różnych plat­for­ma­ch generu­je dodatkowe opóźnienia, trud­niej zabez­pieczyć ruch i dane przed ataka­mi i awari­a­mi oraz ciężej zsyn­chro­ni­zować zmi­any i aktu­al­iza­c­je. Poniekąd to wszys­tko praw­da, ale ponown­ie patrząc na fak­ty­czne dane, strona głów­na ładu­je się obec­nie w ok. 600ms (przy dobrym łączu) — w porów­na­niu do wcześniejszych ~800ms, nie jest to skór­ka warta wypraw­ki. Dodatkowo do tej pory nie mieliśmy prob­lemów z ataka­mi na bazę danych czy awari­a­mi na łączu. Ponown­ie — fałszy­wy trop.

??

Tak naprawdę, odpowiedzi­ałem już wcześniej — głównym powo­dem dla którego przeniosłem bazę danych na zarządzany przez nas ser­w­er jest fakt, że nie miałem poję­cia jak to zrobić.

????!

Uprzedza­jąc pyta­nia nie, nie zmieni­am ścież­ki kari­ery, nie szukam nowej pra­cy a moje codzi­enne obow­iąz­ki nie obe­j­mu­ją zbyt wiele sze­roko poję­tych DevOp­sów. Nie odpalamy pro­jek­tu związanego z zarządzaniem baza­mi danych i nie jest to konieczne z braku innych opcji. Główną motywacją była chęć nauczenia się czegoś nowego, trochę postaw­ienia sobie nie-try­wial­nego wyzwa­nia i nieco lep­szego zrozu­mienia tego, czego nie wiem (Google: cztery fazy kom­pe­tencji, cztery fazy kom­pe­tencji — definic­ja).

Ok, ale w takim razie jak?

“Jak nauczyć się czegoś, czego nie wiem że nie umiem” — kole­jne świetne pytanie! Podob­nie jak z dowol­nym pro­jek­tem najlepiej zacząć od celu — co chce­my osiągnąć. Ide­al­nie powinien być to cel real­ny (“zbu­dować per­pe­tum mobile” może być nieco zbyt ambit­nym przed­sięwz­ię­ciem na początek), zdefin­iowany i względ­nie mały (“zbu­dować w garażu auto wyś­cigowe” także może nie być najlep­szym wyborem), mierzal­ny (“ulep­szyć kod X” w wielu przy­pad­kach ciężko opisać liczbą) i przede wszys­tkim sen­sowny (coś, co będzie przy­datne lub uży­wane). W naszym przy­pad­ku migrac­ja bazy danych speł­ni­ała wszys­tkie te kry­te­ria, ale jeśli szukasz pro­jek­tu dla siebie może warto roze­jrzeć się wokół i wesprzeć jakąś orga­ni­za­cję non-prof­it? Możesz zbu­dować dla nich sys­tem, który pomoże im na codzień, albo skon­fig­urować i zarządzać gotowym narzędziem które będą mogli uży­wać w pra­cy. Inna opc­ja to pomóc w roz­wo­ju jakiegoś pro­jek­tu Open Source — wiele pro­jek­tów ma back­log rzeczy do zro­bi­enia, nad który­mi moż­na pra­cow­ać wiedząc, że ktoś z tego skorzysta.
Mając już pro­jekt, kole­jnym krok­iem jest odniesie­nie poraż­ki. Jeśli uda Ci się osiągnąć to, co założyłaś za pier­wszym razem to albo a) jesteś geniuszem lub b) wybrany pro­jekt mógł­by być ambit­niejszy — tutaj musisz odpowiedzieć sobie sama ;) . W naszym przy­pad­ku porażką było efek­ty­wne zablokowanie strony — która albo dzi­ałała super powoli albo wcale. I nie zrozum mnie źle — przed przełącze­niem blo­ga poczy­tałem tuto­ri­ale, przetestowałem rozwiązanie na innych aplikac­jach, prze­jrza­łem komen­tarze pod tuto­ri­ala­mi i porad­nika­mi oraz infor­ma­c­je na tem­at tego jak skon­fig­urować wszys­tko na początku. W momen­cie jak pojaw­ił się prob­lem, zaczęła się ta naprawdę ciekawa część .

Czemu to nie działa?

Pier­wszy krok to oczy­wiś­cie odt­worze­nie listy kroków, które zaplanowałaś wykon­ać i sprawdze­nie czy na pewno wszys­tko jest zro­bione i nie pojaw­iły się żadne błędy czy prob­le­my. Odhaczone.
Dru­gi krok to rand­ka z Google — opisu­je­my prob­lem w kilku słowach (“mysql word­press slow response”, “data­base long query time”, “mysql con­nec­tion time­out”) — im więcej wiemy (np. z logów) tym pre­cyzyjniej może­my wyszukać infor­ma­cji. Po przeczy­ta­niu kilku­nas­tu wątków na Stack­Over­flow, paru stron i blogów być może coś napraw­iłem, ale główny prob­lem wys­tępu­je nadal. Idziemy więc dalej.
Trze­ci krok to odpowiedze­nie sobie na pytanie: “Co tak naprawdę zro­biłem” i idąc ‘od ogółu do szczegółu’ znalezie­nie potenc­jal­nych źródeł prob­lemów. W tym wypad­ku wyglą­dało to mniej więcej tak:

• przeniosłem bazę danych na inny serwer
• nowy ser­w­er jest nieco lep­szy (2GB pamię­ci vs 1GB, podob­na moc obliczeniowa, podob­na tech­nolo­gia), ale zasad­nic­zo iden­ty­czny do poprzed­niego. Na pewno nie jest gorszy, więc to nie prob­lem z brakiem zasobów
• uży­wam nieco innego opro­gramowa­nia (MySQL vs Per­cona), ale w grun­cie rzeczy jest to to samo opro­gramowanie (Per­cona bazu­je na sil­niku MySQL, głów­na różni­ca pole­ga na ‘wyda­jniejszej’ domyśl­nej kon­fig­u­racji i kilku opty­mal­iza­c­jach w samym kodzie) — ewen­tu­alne różnice nie powodowały­by aż tak drasty­cznych zmian
• uży­wam domyśl­nej kon­fig­u­racji, wcześniej dzi­ałało to w opar­ciu o domyśl­ną kon­fig­u­rację Ama­zon RDS — mamy jak­iś trop, tak naprawdę nie wiem jaka była i jaka jest kon­fig­u­rac­ja i na co ona wpływa

Jako że był to pier­wszy sen­sowny trop, warto było sprawdz­ić. w MySQL może­my pode­jrzeć ustaw­ienia (‘SHOW GLOBAL VARIABLES;‘ — więcej infor­ma­cji na https://dev.mysql.com/doc/refman/5.7/en/show-variables.html ) — mamy bagatela kilka­set opcji dla każdej z baz danych. Kole­jny krok to odfil­trowanie szu­mu czyli ponown­ie — zrozu­mie­nie co tak naprawdę się zmieniło. Ponieważ wynik tego zapy­ta­nia łat­wo wyek­sportować do pliku tek­stowego, może­my użyć dowol­nego narzędzia, żeby porów­nać oba pli­ki, np. diffchecker.com (uwa­ga! taka kon­fig­u­rac­ja może zaw­ier­ać też wrażli­we dane jak np. klucze czy hasła; upewnij się, że nie wysyłasz ich na losowy ser­w­er w sieci lub sko­rzys­taj z jakiegoś narzędzia lokalnego — choć­by dowol­nego narzędzi do obsłu­gi Gita). Już lep­iej, około 100 różnic, z czego po odfil­trowa­niu praw­dopodob­nie nieis­tot­nych (ścież­ki do fold­erów, nazwy ser­w­era itp) zostało kilka­dziesiąt. W tym momen­cie wracamy do google, doku­men­tacji mysql i sprawdza­my każdy para­metr po kolei.

Kil­ka godzin (i masę stron doku­men­tacji) później, wyty­powałem 5 para­metrów które mogły mieć wpływ na obser­wowane prob­le­my, sko­pi­owałem ich wartoś­ci z kon­fig­u­racji Ama­zon RDS na swój ser­w­er i ponown­ie przepiąłem blo­ga na nową bazę danych.

Podsumowanie

Nie przedłuża­jąc — zadzi­ałało :) Blog (a przy­na­jm­niej jego część webowa) jest już w pełni na naszej infra­struk­turze, w efek­cie czego… nic się nie zmieniło :D To lep­iej niż nasze założone kry­teri­um sukce­su (w tym wypad­ku było to spadek wyda­jnoś­ci o strony mier­zony jako czas do załad­owa­nia się o nie więcej niż 25%).
W żad­nym wypad­ku nie oznacza to, że cała ta przy­go­da nie przyniosła korzyś­ci, wręcz przeciwnie!
Przede wszys­tkim, poczu­cie dobrze wyko­nanego zada­nia i pod­bu­dowanie pewnoś­ci siebie. Jeśli będę miał do zro­bi­enia w pra­cy czy pry­wat­nie coś, o czym nie mam bladego poję­cia, zami­ast panikować pomyślę sobie że “wtedy się udało, to i ter­az dam radę”.
Po drugie, wiem lep­iej czego nie wiem. Pod­czas pra­cy nad migracją przeczy­tałem więcej doku­men­tacji MySQLa niż ucząc się korzys­tać z baz danych. W żad­nym wypad­ku nie czu­je się ekspertem w tej dziedzinie ale jeśli napotkam prob­lem w przyszłoś­ci, będę umi­ał lep­iej go opisać komuś kom­pe­tent­ne­mu albo szy­b­ciej znaleźć odpowied­nie informacje.
Po trze­cie, to było po pros­tu ciekawe. Zaglą­danie ‘pod maskę’ bazy danych to super intere­su­ją­ca lekc­ja o tym jak budować wyda­jne opro­gramowanie oraz z jaki­mi prob­le­ma­mi moż­na się spotkać (w dojrza­łych pro­duk­tach, jakim jest np. mysql, każ­da decyz­ja i pode­jś­cie ma swo­je uza­sad­nie­nie i wyni­ka z jakichś prob­lemów napotkanych w przeszłości).
Po czwarte — ter­az mogę napisać o tym wpis z konkret­ny­mi przykładami ;)

Czy przy­da mi się to w pra­cy / kari­erze? Raczej nie (choć nigdy nie wiado­mo). Czy było warto (choć tytuł mógł być trochę spoil­erem…)? Zde­cy­dowanie TAK!

Zdję­cie w nagłówku autorstwa Susan Holt Simp­son pobrane z ser­wisu Unsplash