Wstępne buforowanie dynamicznie generowanych obrazów dla wielu lokalizacji krawędzi na Amazon Cloudfront

Question

Obecnie korzystamy z CloudFront w wielu lokalizacjach Edge, aby wyświetlać obrazy produktów (prawie pół miliona), które są dynamicznie przeskalowywane do rozmiarów o różnych rozmiarach. Nasza dystrybucja Cloudfront używa skryptu źródłowego EC2 php do pobrania oryginalnego obrazu z S3, przekształcenia go dynamicznie w oparciu o dostarczone kryteria zapytania (szerokość, wysokość, kadrowanie, itp.) I przesłania go z powrotem do Cloudfront, który przechowuje je w lokalizacji krawędzi.

Jednak użytkownik odwiedzający stronę po raz pierwszy ładujący obraz bez pamięci podręcznej zostaje trafiony przez tę dość ciężką transformację.

Chcielibyśmy mieć możliwość "wstępnego buforowania" naszych obrazów (za pomocą zadania wsadowego wymagającego każdego adresu URL obrazu), aby użytkownicy końcowi nie byli pierwszymi, którzy uderzyliby obraz w określonym rozmiarze itp.

Niestety, ponieważ obrazy są przechowywane tylko w pamięci podręcznej w lokalizacji krawędzi przypisanej do usługi buforowania wstępnego, użytkownicy odwiedzający stronę używający innej lokalizacji krawędzi nie otrzymają obrazu z pamięci podręcznej i zostaną trafieni ciężkim skryptem zmiany rozmiaru na serwerze źródłowym.

Jedynym rozwiązaniem zaszliśmy od z, gdzie każdy może pobrać Położenie krawędzi obrazu w rozsądnym czasie ładowania, jest to:

Mamy dystrybucję CloudFront wskazujący na skrypcie php pochodzenie EC2. Ale zamiast wykonywać transformację obrazu opisaną powyżej, skrypt początkowy przekazuje żądanie i parametry zapytania do innej dystrybucji Cloudfront. Ta dystrybucja ma pochodny skrypt PHP EC2, który wykonuje transformację obrazu. W ten sposób obraz jest zawsze zapisywany w pamięci podręcznej w lokalizacji Edge w pobliżu naszej instancji EC2 (Irlandia), co pozwala uniknąć przeprowadzenia kolejnej transformacji, gdy obraz jest wymagany z innej lokalizacji krawędzi.

Na przykład, żądanie w Szwecji trafienia/image/stream/id/12345, które szwedzka lokalizacja nie ma w pamięci podręcznej, więc wysyła zapytanie do kraju pochodzenia, którym jest maszyna EC2 w Irlandii . Strona "streaming" EC2 ładuje/image/size/id/12345 z innej dystrybucji Cloudfront, która trafia w lokalizację Irish Edge, która również nie ma jej w pamięci podręcznej. Następnie przesyła żądanie do miejsca pochodzenia, ponownie do tej samej maszyny EC2, ale do strony "rozmiaru", która zmienia rozmiar. Następnie zarówno lokalizacja Edge w Szwecji, jak i w Irlandii mają buforowany obraz.

Teraz wniosek Francji żąda tego samego obrazu. Lokalizacja francuskiej krawędzi nie ma jej w pamięci podręcznej, więc wywołuje pochodzenie, którym jest maszyna EC2 w Irlandii, która wywołuje drugą dystrybucję CF, która ponownie uderza w irlandzką lokalizację krawędzi. Tym razem obraz jest przechowywany w pamięci podręcznej i można go natychmiast zwrócić. Teraz francuska lokalizacja krawędzi ma również buforowany obraz, ale bez konieczności wywoływania strony "zmiana rozmiaru" - tylko strona "streaming" z obrazem z pamięci podręcznej w Irlandii.

Oznacza to również, że nasza „pre-buforowanie” usługa partia w Irlandii można zrobić wniosek przeciwko irlandzki krawędzi Położenie i pre-cache obrazów przed ich prośbę naszych odwiedzających.

Wiemy, że to wygląda trochę absurdalne, ale z pragnieniem, które mamy, aby użytkownik końcowy nie musiał długo czekać podczas zmiany rozmiaru obrazu, wydaje się, że jest to jedyne konkretne rozwiązanie:

Czy przeoczyliśmy inne/lepsze rozwiązanie? Wszelkie komentarze do powyższego?

Answer 1

Nie jestem pewien, czy to zmniejszy czas ładowania (jeśli był to y nasz cel).

Tak, ta konfiguracja pozwoli zaoszczędzić trochę "czasu transformacji", ale z drugiej strony stworzy dodatkową komunikację między serwerami.

I.E. Klient dzwoni Francuski POP >> Francuski POP dzwoni Irlandia POP = Dwa razy czas pobierania (i niektóre), który może być dłuższy niż "czas transformacji" ...

Pracuję dla Incapsula i tak naprawdę opracowaliśmy własną unikalne zachowanie analizujące proces heurystyczny do obsługi dynamicznego buforowania treści. (Krótko udokumentowany tutaj: http://www.incapsula.com/the-incapsula-blog/item/414-advanced-caching-dynamic-through-learning)

Nasz lokal jest:

Podczas gdy jedna strona może mieć miliony obiektów dynamicznych, tylko niektóre z nich podlegają wielokrotnym życzenie.

Zgodnie z tą logiką mamy algorytm, który uczy się wzorców odwiedzin, znajduje dobrych "kandydatów" do Buforowania, a następnie zapisuje je na zbędnych serwerach. (unikając w ten sposób wspomnianego wyżej "podwójnego pobrania")

Zawartość jest następnie ponownie skanowana co 5 minut, aby zachować świeżość i system heurystyczny śledzi, aby upewnić się, że zawartość jest nadal popularna.

To jest zbyt uproszczone wyjaśnienie, ale demonstruje kluczową ideę, która brzmi: Dowiedz się, czego najbardziej potrzebują użytkownicy. Wejdź na wszystkie TZO. Śledź, aby zachować świeżość i wykrywać trendy.

Mam nadzieję, że to pomoże.

Answer 2

Po prostu myśl ...

Uruchom dwie pamięci podręczne.

1. Jeden na każdej lokalizacji EDGE,
2. Jeden na serwerze (lub elasticache jeśli wielu serwerach) w Irlandii. Nie trzeba ich przechowywać w pamięci podręcznej dłużej niż przez kilka minut.

Mają mikro instancji działającej dołączony do rurociągu danych lub kolejce,

Gdy nadejdzie żądanie do serwera pochodzenia, wrócić i cache serwer obraz. Opuść także URL do kolejki.

Następnie niech demon wykona wiele połączeń do każdej lokalizacji krawędzi. W tym momencie serwer zostanie ponownie trafiony (ponieważ inne lokalizacje krawędzi nie będą miały obrazu) - ale zostanie natychmiast udostępniony z pamięci podręcznej - bez konieczności przeprowadzania kosztownej transformacji.

Jeśli nie wykonuje transformacji i obsługuje tylko pamięć podręczną - nie powinno to być wielkim problemem.

więc przepływ byłby tak

Request -> Cloud Front -> EC2 -> Add to cache -> Response -> CloudFront Cache -> User 
    -      -> Queue new request at each edge location 
Request -> Cloud Front -> EC2 -> already cached -> Response -> CloudFront -> User 

że trzeba jakąś formę markera stwierdzić, że to było serwowane i już buforowane, poza którą kończy się w nieskończonej pętli.