|

Защо EFS не е най-добрият вариант за WordPress?

Elastic File System (EFS) услуга на AWS, която предлага високодостъпна, сигурна, serverless файлова система. С две думи EFS е отговорът на Amazon за т.н. network-attached file system (NFS).

Наскоро ми се наложи да работя по three-tier ахритектура за WordPress, следваща всички най-добри практики на AWS. Конфигурацията включва VPC setup, WAF, Cloudfront, EC2 instances с Litspeed, load balancing, auto-scaling, RDS Aurora Serverless, ElastiCache и… разбира се EFS.

wordpress on aws

Скоро след като всичко бе свързано и конфигурирано забелязах, че сайтът е бавен. Много бавен. Дори при чиста WordPress инсталация, зареждането на бекенда беше в рамките на 1-2, а на моменти над 5 секунди. Беше странно, имайки предвид, че съм следвал всички препоръки на Amazon, но забавянето беше прекалено очевидно. Обикновено бекенда на WordPress е много по-лек, но в случая дори и той бе неизползваем. Очевидно не бях конфигурирал нещо правилно и започнах да търся.

Първоначално реших, че нещо с Litespeed не е наред, но всичко изглеждаше правилно настроено. Може би Cloudfront създава проблеми заради лоша връзка с load balancer-а? След като го изключих се оказа, че проблемът не е там. Свързах Aurora и Redis cluster-а и дори тогава сайтът беше бавен. Реших, че може би по някаква причина самият Web ACL (WAF) създава забавяне. Само че WAF-а е свързан с Cloudfront и се прилага самостоятелно на всеки Edge location, така че не би трябвало да води до толкова голямо забавяне.

Накрая реших да проверя и EFS. Премахнах EFS и изпозлвах локалната файлова система на сървъра и резултатът беше очевиден – WordPress зареждаше за 0.12s – в пъти по-бързо от преди. Честно казано никак не очаквах проблемът да е в EFS, тъй като AWS официално препоръчват EFS за файлова система за WordPress архитектури в своята документация. След като проучих допълнително въпроса, се оказа, че EFS никак не са добър избор за low-latency файлова система, която изисква често четене на хиляди малки файлове.

Основният проблем на EFS е, че има нисък throughput, когато файловата система е малка. Обикновено архитектурите на AWS с WordPress включват сравнително малък application code, докато медийните файлове се прехвърлят в S3 или някъде другаде. Някои хора дори препоръчват създаването на dummy файл, който е поне 256 GB, за да може EFS автоматично да премине към по-висок клас на throughput и следователно файловата система да работи по-бързо, но това само ще доведе до излишни разходи, а разликата наистина няма да е осезаема.

Въпреки че през годините AWS направиха промени в метода на работа на EFS, до ден днешен той никак не е подходящ за WordPress и като цяло за application code файлова система. В случай, че използвате Burstable throughput, то трябва да следите burst credit-ите на EFS, иначе файловата система ще стане бавна. Още по-лошо – ако използвате плъгин за бекъп или malware scanner, който сканира файловата система – то много бързо burst кредитите ви ще се похарчат и EFS ще стане много бавна за крайния потребител. Използването на Provisioned throughput също не решава проблема – тя отново е бавна при тестовете, които съм правил.

По-добра алтернатива

Тъй като Amazon EFS на практика е network-attached filesystem (NFS), то една от по-добрите алтернативи е сами да си изградите NFS сървър, който да използвате като файлова система за WordPress. Вярно е, че EFS и като цяло NFS не е най-добрия вариант за application code, но собствен NFS сървър ще бъде в пъти по-бърз от EFS. Свържете го в private subnets и NAT gateway към публични подмрежи и load balancer, и скоростта ще бъде много по-добра.

Проблемът с тази конфигурация е т.н. SPOF – single point of failure. В случай, че нещо се случи с NFS сървъра, всички application сървъри ще бъдат засегнати. В този случай това, което правя, е – създавам копие на NFS сървъра, на което автоматично се синхронизират файловете от master NFS сървъра с Lsyncd например, така че ако единият сървър спре по някаква причина, тогава backup NFS сървъра лесно да може да замени master сървърa. В зависимост от нуждата, могат да се създадат и няколко такива бекъп сървъра.

Друг много добър вариант е да използвате изцяло локална файлова система, която се синхронизира с master сървър чрез Ansible, Puppet или друг подобен софтуер. Проблемът е, че синхронизацията става сложна, когато използвате auto-scaling с private сървъри, чийто internal IP адреси трябва да се добавят и премахват автоматично от конфигурацията на самия софтуер, който синхронизира сървърите. Но ако не планирате да използвате auto-scaling, то този вариант е доста по-добър. В крайна сметка, локалната файлова система (почти) винаги ще е по-бърза от NFS.

Като цяло плюсовете на EFS са, че е scalable – автоматично увеличава размера си според нуждата (не се налага да предвиждате колко GB ще използвате), може да поеме високо натоварване и предлага автоматичен бекъп на файловата система с restore points, както и възможността за replication на EFS. Но много трудно може да работи добре с WordPress.

Ако все пак ви се налага да постигнете highly-available WordPress в AWS с EFS, то непременно го съчетайте с Оpcache и cachesfilesd. Ще подобри скоростта на сайта, но поне при мен, подобрението не бе задоволително. Все пак проверете внимателно дали EFS ще върши работа за вашия use case, но имайте предвид, че никак не е подходящ за софтуер като WordPress и ще ви създаде проблеми, ако все пак решите да го ползвате. EFS е подходящ за медийни файлове – видео клипове, снимки и други файлове, за който не се налага нисък latency и бързо четене на файлове, но не и за архитектура, включваща WordPress.

Ако имате нужда от качествена, бърза и сигурна архитектура в Amazon Web Services, Google Cloud Platform или Oracle Cloud, свържете се с мен и ще се радвам да обсъдим вашия проект.

Допълнителни материали

Вашият коментар

Вашият имейл адрес няма да бъде публикуван.