GigaOM Radar Edge Platform Leader & Outperformer 2024 | 
모든 장점에도 불구하고 대규모 카탈로그와 빈번한 업데이트가 있는 전자 상거래 웹 사이트에 Jamstack을 적용하는 것은 많은 어려움을 수반합니다. Salesforce Commerce Cloud, Magento 또는 SAP-Hybris와 같은 백엔드 플랫폼에서 전자 상거래 사이트를 운영하고 있다면 이미 그 중 일부에 직면했을 것입니다.
이 문서에서는 대규모 이커머스 Jamstack 사이트 구축의 주요 과제와 Layer(현재 Edgio)가 이러한 문제를 해결하는 데 어떤 도움을 줄 수 있는지 설명합니다.
Jamstack Conference 2020에서 Layer0 CTO Ishan Anand의 전체 프레젠테이션을 보려면 공식 Layer0 YouTube 채널로 이동하십시오.
Layer0(현재 Edgio)이란 무엇입니까?
Layer0은 Jamstack의 장점을 이커머스에 도입하여 사이트 속도를 높이고 개발 워크플로우를 간소화합니다. 엣지에서 브라우저로 캐시된 데이터를 스트리밍하여 요청하기 전에 엣지에서 웹사이트를 스트리밍함으로써 웹사이트가 쇼핑객의 도청보다 5초 앞당겨질 수 있습니다. Sharper Image, Revolve 및 Shoe Carnival은 Layer0 Jamstack 플랫폼을 활용하여 개발자 생산성을 높이고 웹 사이트를 1초 이내로 제공하는 사이트의 예에 불과합니다.
대규모 이커머스에 Jamstack을 사용할 때 직면하는 과제는 무엇입니까?
특히 카탈로그가 크거나 업데이트가 빈번한 사이트 또는 모놀리식 전자 상거래 플랫폼의 사이트에서 Jamstack 및 Headless for eCommerce를 사용하는 것은 일반적으로 다음과 같은 문제를 해결하는 것과 관련이 있습니다.
- 긴 빌드 시간
- 빈번한 업데이트
- 까다로운 사이트 마이그레이션
- 동적 데이터
- 개인 설정
- A/B 테스트
- 불완전한 API
- 데이터 파이프라인 아키텍처
- API로 인한 사용자 지정 손실
- 데이터베이스 연결 제한
- 팀 역량
- CMS 통합
- CMS 콘텐츠에 포함된 스타일
- 백오피스 워크플로우 통합
시간 제약 및 기타 도전 과제를 대규모로 구축
Jamstack에는 높은 트래픽 확장성이 내장되어 있습니다. 그러나 빌드 단계에서는 빌드 중에 일반적인 정적 렌더링이 발생하므로 새로운 배율 차원이 도입됩니다. 웹 사이트를 확장하거나 자주 변경하면 Jamstack이 빠르고 민첩하게 작동하는 스위트 스팟에서 빠릅니다. 그 결과 빌드 시간 마찰이 발생합니다. 작은 사이트에서 작업하는 경우 러그 아래에서 문제를 쉽게 해결할 수 있지만 일반적인 전자 상거래 사이트에서는 그렇지 않습니다.
기억해야 할 또 다른 중요한 점은 사이트가 개발자만큼 개발자가 아닌 사람에 의해 만들어진다는 것입니다. 컨텐츠, 마케팅 및 머천다이징은 끊임없이 변화하기 때문에 시간 제약 조건은 전체 조직에 빠르게 문제가 될 수 있습니다.
이 모든 것은 “규모에서”당신이 생각하는 것보다 더 많이 발생하며 전자 상거래에 국한되지 않습니다. 소매업체와 뉴스 웹 사이트 간의 비교를 살펴보십시오. 전자 상거래 사이트의 경우 SKU 수는 페이지 수에 대한 프록시입니다.
많은 제품(SKU)이 있는 전자 상거래 사이트, 많은 기사가 있는 게시자
기사가 많은 출판사
아마존과 같은 사이트에서만 수백만 개의 SKU를 처리한다고 생각할 수 있지만 사실이 아닙니다. 자동차 부품 웹 사이트는 YMMV(연도/모델/제조업체/차량 검색 기준)를 기반으로 수백만 개의 제품을 호스팅하는 좋은 예입니다. 예를 들어, TruPar.com 은 8M SKU를 포함한 지게차 부품을 독점적으로 판매합니다.
고맙게도 몇 가지 정적 및 동적 렌더링 기술은 Jamstack의 규모 문제를 처리하는 데 도움이됩니다.
“정적” 기법
- 빌드 시간 최적화
- 클라이언트 쪽 렌더링
- 증분 정적(재)생성
“동적” 기법
- 서버리스 서버측 렌더링 + CDN
- 병렬 정적 렌더링
“혼합” 렌더링 기법
- 각 페이지 클래스에 가장 적합한 렌더링 기술 선택
- 필요에 따라 기술을 혼합할 수 있는 프레임워크 및 플랫폼 선택
다음 단락에서는 이러한 기술이 의미하는 바에 대해 논의 할 것입니다.
정적 기법
빌드 시간 최적화
동적 JavaScript 페이지의 빌드 시간을 최적화하는 방법은 여러 가지가 있습니다.
증분 빌드
증분 빌드를 사용하면 빌드 아티팩트를 저장하고 변경된 내용만 다시 생성할 수 있습니다. 한 페이지만 변경된 경우 해당 단일 페이지는 다시 생성됩니다.
병렬 빌드
프레임워크는 빌드를 여러 프로세스 또는 스레드로 분할합니다. 이 기능은 이미지 처리에 유용합니다.
대체 정적 사이트 생성기
기본적으로 전원이 공급되는 SSG는 새롭게 등장하는 방법이며, 구축 시간이 단축되는 것으로 나타났습니다. Hugo(GO) 및 Nift(C++)가 그 예입니다. 그러나 기본적으로 작성된 많은 정적 사이트 생성기는 JavaScript를 많이 사용하는 웹 사이트에서는 잘 작동하지 않습니다. 비교적 새로운 토스트는 그것을 해결하기 위해 노력하고 있습니다.
병렬 및 증분 빌드에 대한 프레임워크 및 클라우드 제공업체의 지원은 다양하다는 점에 유의해야 합니다. 그들 모두가 그것을 지원하는 것은 아니며, 제한된 지원만 제공하는 사람들입니다.
방문 빈도가 낮은 페이지에 대한 잠재적 초과 비용
또한 잠재적 인 초과 비용의 문제도 있습니다. 수만 개 이상의 SKU가 있는 대규모 사이트가 있는 경우 대부분의 트래픽은 전력 분배를 따르므로 방문하지 않을 페이지를 재구축하는 데 추가 컴퓨팅 시간이 소요됩니다. 사이트를 업데이트할수록 비용이 더 커집니다. 이러한 기술 중 일부를 생각할 때 기억하십시오.
willit.build(Gatsby Cloud에 구축된 사이트의 과거 빌드 시간을 제공하는 Gatsby 빌드 벤치마크 페이지)에 따르면 Contentful 및 WordPress 사이트의 빌드 시간은 페이지당 약 200ms이므로 10K 페이지가있는 사이트의 경우 전체 사이트 빌드가 25 분이 걸릴 수 있습니다. 증분 빌드를 사용하면 몇 분 안에 증분 빌드의 성능을 확인할 수 있습니다. 이 기술은 전체 빌드를 수행하지 않는 경우에 유용할 수 있습니다.
클라이언트 쪽 렌더링
애플리케이션 셸 또는 SPA 대체 모델이라고도 하는 클라이언트 측 렌더링은 CDN 라우팅입니다. 사이트가 백만 개의 제품을 호스팅하는 경우 이 모든 제품은 이 CDN 계층에 의해 index.html 으로 라우팅되고 앱 셸을 포함하는 하나의 정적 파일이 되며 클라이언트측 렌더링됩니다. 브라우저가 해당 페이지를 로드하면 클라이언트 사이트 라우터가 브라우저에서 페이지 콘텐츠를 가져와서 렌더링합니다.
클라이언트 쪽 렌더링을 사용하면 무한대의 페이지를 효과적으로 호스팅할 수 있지만 몇 가지 중요한 고려 사항이 있습니다.
CSR이 SEO에 부정적인 영향을 줄 수 있음
클라이언트측 렌더링의 경우 JavaScript가 로드될 때까지 페이지를 렌더링할 수 없기 때문에 성능이 저하될 수 있습니다. 2021년 5월부터 구글은 3단계 속도 측정 지표, CLS, LCP, FID를 기준으로 웹사이트 순위를 매길 예정이며, 이를 통칭하여 코어 웹 바이탈이라고 합니다. 클라이언트측 렌더링은 이러한 모든 것, 특히 누적 레이아웃 이동에 부정적인 영향을 줄 수 있습니다. 그것은 불가능하지 않습니다, 그리고 그것은 응용 프로그램 셸 모델과 좋은 CLS를 얻기 어렵다. 이렇게 하려면 각 페이지 유형에 대해 앱 셸의 사용자 지정 버전을 만들어야 합니다.
(일부) 봇이 클라이언트측 렌더링 페이지를 읽을 수 없음
일부 봇은 클라이언트측 렌더링 콘텐츠를 읽을 수 없습니다. 구글은 자사 봇이 자바스크립트를 렌더링하고 해석할 수 있다고 주장하지만, 대부분의 소셜 플랫폼을 포함해 대부분의 다른 봇은 그렇지 않다는 것을 알고 있습니다.
CSR에 재작성 및 리디렉션 규칙 지원 필요
CSR을 구현할 때 세 번째 주의사항은 CDN 제공업체의 재작성 및 리디렉션 규칙 지원이 필요하며, 일부는 다른 업체보다 더 우아하게 수행한다는 점입니다. 예를 들어 404 페이지 지원을 통해 AWS CloudFront에서 이를 구두로 만들거나 Lambda@Edge 핸들러를 사용해야 합니다.
고맙게도 선도적인 Jamstack 플랫폼 Netlify, Vercel 및 Layer0은 CSR을 활성화하는 매우 쉬운 방법을 제공합니다.
Netlify에는 리디렉션 파일이 있습니다. 200개의 수정자를 사용하면 다시 쓰기가 가능하지만 사용자가 결코 볼 수 없는 숨겨진 리디렉션입니다.
넷라이파이
Vercel은 vercel.json에서 재작성 지원을 제공하며 Next.js와 매우 긴밀하게 통합됩니다.
베르셀
Layer0의 CDN-as-JavaScript 명령 셸은 Next.js를 다시 작성하고 다른 프레임워크를 지원합니다.
Layer0(에지오)
증분 정적 생성
이 기술은 Next.js에 의해 개척되었으며 들어오는 트래픽에 대한 응답으로 필요에 따라 새로운 정적 페이지를 생성하는 것을 포함했습니다. 브라우저는 아직 방문하지 않은 새 페이지를 요청하며, 페이지가 무엇이든 상관없이 CDN은 플레이스홀더 데이터만 포함하고 콘텐츠는 없는 범용 폴백 페이지를 신속하게 반환합니다.
대체 페이지가 표시되는 동안 페이지의 정적 빌드 프로세스는 백그라운드에서 실행됩니다. 빌드가 완료되면 대체 페이지는 정적 JSON 데이터를 로드하고 마지막 페이지를 표시합니다. 그때부터, 미래의 방문은 정적으로 빌드된 HTML을 얻을 것이다.
점진적 정적 재생
증분 정적 재생이라고 하는 증분 정적 생성 버전이 있는데, 이는 본질적으로 동일한 프로세스입니다. 여전히 트래픽에 대한 응답으로 기존 정적 페이지를 업데이트하는 작업이 포함됩니다. 따라서 기본 데이터가 변경되면 빌드 프로세스를 다시 실행하게 됩니다. 이 프로세스는 널리 사용되고 있지만 널리 인정받지 않는 캐시 프로토콜인 오래된 재검증에서 영감을 얻게 됩니다. 이렇게 하면 페이지를 다시 빌드하는 동안 대체(fallback) 대신 오래된 버전의 페이지가 제공되고 빌드 프로세스가 완료되면 새 버전으로 바뀝니다.
점진적 정적 재생:
- 트래픽에 대한 응답으로 기존 정적 페이지를 업데이트합니다.
- 대체 대신 오래된 페이지 버전으로 사용됩니다.
증분 정적 재생은 특히 첫 번째 페이지에서 SEO 및 호환성에 사소한 영향을 미칩니다. 대체 페이지는 전적으로 CSR이며 데이터가 없기 때문에 봇이 어떻게 반응할지 불분명합니다.
동적 기법
정적 기법 외에도 전자 상거래 웹 사이트는 다음과 같은 동적 기법의 혜택을 누릴 수 있습니다.
- 서버리스 서버측 렌더링 + CDN
- 병렬 정적 렌더링
서버리스 서버측 렌더링 + CDN
CDN과 함께 SSR을 사용하면 트래픽에 대한 응답으로 온디맨드 페이지를 생성할 수 있으므로 몇 가지 장점이 있습니다. 이 기술은 또한 전통적인 전자 상거래 플랫폼이 만들어지는 방식과 더 호환됩니다. 이를 통해 많은 페이지를 지원하고 필요할 때 동적으로 생성할 수 있으며 기존 플랫폼과의 높은 호환성을 보장할 수 있습니다.
그러나 이 기술 또한 약간 논란이 있다. Jamstack 커뮤니티는 Jamstack이 무엇인지에 대해 매우 독단적인 경향이 있으며 Jamstack이 정적 생성이 필요하다고 주장합니다.
서버리스 서버측 렌더링은 다음 두 가지 조건이 충족될 때 효과적으로 Jamstack-ish입니다.
- DevOps 및 서버를 관리하지 않아도 됩니다. 서버가 필요 없으며 개발자는 스케일 웨이를 관리할 필요가 없습니다. 많은 Jamstack 플랫폼이 API를 구동하는 데 사용하는 서버리스 서버와 동일합니다. 즉, HTML 데이터를 구동하고 SSR을 통해 구동할 수 있습니다.
- HTML은 CDN에서 제공됩니다. 이는 심각한 상태입니다. 첫 번째 캐시 비적중 이후 CDN 지원 사이트는 정적으로 생성된 Jamstack 사이트와 같은 속도로 작동합니다. 이렇게 하려면 적절한 캐시 관리가 필요하며 다중 페이지 사이트에서는 더 어렵습니다.
병렬 정적 렌더링/SSR 사전 로드
Layer0을 사용하면 배포 중에 엣지에서 미리 렌더링하고 캐시해야 하는 URL 집합을 지정할 수 있으므로 사용자가 사이트에 액세스할 때 1초 이내로 작업을 수행할 수 있습니다.
정적 사전 렌더링에는 응용 프로그램 코드로 요청을 보내고 사이트가 배포된 직후에 결과를 캐싱하는 작업이 포함됩니다. 이러한 방식으로, 단순히 앱을 빌드하여 서버측 렌더링을 구현하고 페이지 일부 또는 전체에 대해 정적 사이트의 속도 이점을 얻을 수 있습니다. 이 기능은 특히 URL이 너무 많아 빌드 시간이 크게 길지 않으면서 PreRender에 너무 많은 복잡한 대형 사이트에 유용합니다.
SSR 사전 로딩은 페이지 속도를 가속화하기 위해 Layer0에서 사용하는 또 다른 기술입니다. 일반 SSR 파이프라인과 매우 유사하지만 배포 후 트래픽 로그를 분석하는 것을 기반으로 합니다. 트래픽이 많은 페이지는 배포와 병행하여 사전 로드됩니다. 트래픽이 많은 페이지를 즉시 비동기적으로 구축할 수 있습니다. 이러한 방식으로 빌드에서 배포를 분리합니다. 따라서 캐시 적중률을 극대화하면서 즉시 배포할 수 있습니다.
기본적으로 트래픽 수준이 높은 페이지에 대한 요청이 있을 경우 캐시 적중이 발생할 가능성이 높습니다. 이 환경에서 가능한 최상의 캐시 적중을 얻는 가장 좋은 방법입니다.
병렬 정적 렌더링을 사용하면 다음을 수행할 수 있습니다.
- 트래픽이 많은 페이지에 대한 로그 분석
- 배포 후 트래픽이 많은 페이지에 대한 HTML을 비동기적으로 가져오기 및 저장
- 캐시 적중률을 극대화하면서 즉시 배포
정적 사전 렌더링
혼합 렌더링 기법
정적 렌더링 기법과 동적 렌더링 기법 중에서 선택할 필요가 없습니다. 사이트의 각 페이지 클래스에 적합한 항목을 선택할 수 있습니다. “회사 소개”, “반품 정책” 또는 블로그 정적 및 장바구니, 제품 및 범주와 같은 기타 페이지를 동적으로 선언할 수 있습니다. 필요에 따라 기술을 유연하게 혼합할 수 있는 플랫폼 제공업체를 선택하는 것이 좋습니다. 특히 규모가 큰 경우 더욱 그렇습니다.
각 페이지 클래스에 대해 최상의 렌더링 기술을 선택합니다. 예를 들어, 일부 페이지는 정적(예: 블로그, 회사 소개 등), 다른 페이지는 동적(예: 장바구니, 제품, 카테고리 등) 선언합니다.
필요에 따라 유연하게 기술을 혼합할 수 있는 프레임워크 및 플랫폼 제공업체 선택
레이어 0으로 확장되는 Jamstack
오늘날의 CDN 캐시 이미지, JavaScript 및 CSS는 JSON이나 HTML 파일은 아니므로 페이지 로딩 시간이 지연됩니다. Layer0 CDN-as-JavaScript를 사용하면 서버가 없는 동적 SSR 환경에서도 엣지에서 데이터를 캐시할 수 있습니다.
Jamstack은 서버를 방정식에서 벗어나 CDN이 트래픽을 효과적으로 관리할 수 있게 해 주므로 트래픽 변동에 관계없이 쉽게 처리할 수 있습니다. Layer0은 동일하지만 다르게 수행합니다. 빌드 시 렌더링하는 대신 요청 시 렌더링하지만 각 빌드를 엣지에 캐시하므로 빌드 1개 후에는 빌드가 더 이상 필요하지 않습니다.
빌드 시 각 페이지를 렌더링하는 것은 소규모 사이트에 적합하지만 규모가 커지면 빌드 시간은 거의 견딜 수 없습니다. Jamstack은 맞춤화/개인화 또는 이를 제공할 수 있는 대안이 없기 때문에 이커머스 및 트래블과 같은 대규모 데이터베이스 기반 웹 사이트에서는 구축 시간이 덜 중요해졌습니다.
자바스크립트로서의 CDN
Layer0 CDN-as-JavaScript는 캐시 키, 헤더, 쿠키 등에 대한 강력한 에지 제어를 제공하며 코드와 함께 작동합니다. 코드와 프레임워크의 라우팅을 이해하고 로컬 또는 프로덕션 이전 환경에서 에뮬레이션할 수 있습니다.
엣지 규칙은 클래식 Jamstack에서와 마찬가지로 코드에 존재하므로 라이브 로그, 버전 관리 및 원클릭 롤백을 통해 엣지를 완벽하게 제어할 수 있습니다.
CDN-AS-JavaScript의 라우팅 패턴에 대한 자세한 예는 Layer0/Edgio Cookbook을 참조하십시오.
성능 모니터
캐시 적중률을 극대화하려면 먼저 이러한 속도를 파악하는 것이 중요하지만 이 정보는 대개 CDN의 액세스 로그 깊숙이 묻혀 있습니다.
Layer0에는 성능 모니터링이 내장되어 있어 페이지 캐시 적중 및 비적중 발생 시기를 쉽게 파악하고 이 정보를 개발자에게 매우 친숙한 방식으로 노출할 수 있습니다. Layer0의 성능 모니터를 통해 다음을 수행할 수 있습니다.
- URL이 아닌 경로를 기반으로 트래픽을 이해합니다. 개발자가 앱에 대해 생각하는 방식이 바로 이러한 방식이기 때문입니다. 또한 각 배포를 추적하여 개발자가 회귀를 정확히 찾아낼 수 있습니다.
- 스택 및 로딩 시나리오(API, SSR, Edge 등)의 성능 문제 측정
Layer0은 또한 응답이 오리진의 가장자리에서 오는지 진단하는 툴을 만들었습니다: DevTools. DevTools는 응답이 오리진의 엣지에서 왔는지 여부를 결정하는 데 도움이 됩니다. 아래 예제는 React Storefront를 사용하여 빌드된 앱 셸의 상단에서 어떻게 작동하는지 보여 주며, 요청이 도달했을 때를 보여 줍니다. 이 예제의 응답은 Layer0(현재 Edgio) 에지 네트워크를 통해 전달됩니다.
Layer0 DevTools를 사용하면 응답이 엣지 또는 오리진에서 왔는지 진단할 수 있습니다.
응답이 엣지 또는 오리진에서 왔는지 파악하는 것은 스케일에서 프리페치하는 데 중요하며, 이는 Layer0이 수행하는 또 다른 작업입니다.
스케일에서 프리페치
프리페치는 즉각적인 페이지 속도를 잠금 해제하기 때문에 성능에 중요합니다. Lighthouse에서 테스트하는 것과 같은 기존의 페이지 속도 테스트는 고객이 클릭 후 발생하는 상황에 초점을 맞춥니다. 하지만 고객이 도청하기 전에 많은 작업을 시작할 수 있으며 지연 시간이 0이고 대역폭이 거의 무한대에 이릅니다.
Layer0 DevTools를 사용하면 응답이 엣지 또는 오리진에서 왔는지 진단할 수 있습니다.
Layer0의 웹 사이트는 Layer0 CDN-as-JavaScript와 함께 고급 예측 프리페치를 사용하므로 쇼핑객의 도청 시간을 5초 앞당길 수 있습니다. 이 작업은 사용자가 다음 클릭 시 예상되는 사항에 따라 캐시된 동적 데이터를 엣지에서 사용자의 브라우저로 스트리밍하여 수행합니다. 즉, 매장에서 제공하는 다양한 제품, 가격 및 정보에 대한 JSON 데이터를 짧은 시간 내에 제공할 수 있습니다.
증분 마이그레이션
Layer0은 반복적 (점진적, 점진적) 마이그레이션을 제공하여 Martin Fowler의 strangler 패턴에 따라 한 번에 하나의 앱 섹션을 반복적으로 마이그레이션할 수 있습니다. 이러한 방식으로 특정 기능을 점진적으로 “교착”하고 새로운 응용 프로그램 및 서비스로 교체합니다. 마치 돌을 하나씩 움직이는 것과 같습니다.
증분 마이그레이션을 수행하려면 CDN 에지 또는 오리진에서 라우팅된 제어가 필요합니다. 다음은 CDN-as-JavaScript를 사용하여 Layer0에서 이 작업을 수행하는 방법의 예입니다.
개인화 및 세분화
대규모 사이트에서 점진적, 점진적, 점진적 마이그레이션이 중요합니다. 그러나 그것은 개인화에 국한되지 않습니다! 또한 언어, 지리 등을 다룹니다. 또한 대규모 사이트는 일반적으로 여러 지역에서 작동하며 사용자가 사이트를 방문할 때 콘텐츠를 사용자 지정할 수 있어야 하기 때문에 의미가 있습니다.
일반적인 지침은 다음과 같습니다. 이 콘텐츠가 폴드 아래에 있는 경우 지연 로딩 및 클라이언트 측 렌더링을 권장합니다. 폴드 이상의 개인 설정된 콘텐츠라면 서버 렌더링 출력으로 출력할 수 있습니다.
폴드 위에 개인 설정 = 캐시 키에 개인 설정 추가
Layer0에서는 사용자 지정 캐시 키를 선언하고 통화 또는 동작에 따라 개인 설정할 수 있습니다. CDN-as-JavaScript를 몇 줄만 사용하여 카테고리 페이지에서 프로모션 및 정렬 순서를 사용자 지정할 수 있습니다.
A/B 테스트 및 계층 0
A/B 테스트 및 개인화는 Jamstack 사이트를 구축하는 데 새로운 계층의 복잡성을 가중시킵니다. 테스트는 ROI를 기반으로 의사 결정이 이루어지며 전환율을 높이는 것으로 입증되어야 하는 대규모 사이트 및 대규모 조직에서 매우 중요합니다.
그러나 기존 Jamstack에서는 브라우저에서 실행되는 클라이언트 측 A/B 테스트만 선택할 수 있습니다. 문제는 성능에 영향을 미치고 두 가지 방법으로 테스트를 무효화할 수 있다는 것입니다. 변형의 성능을 저하시켜 모든 종류의 개선을 지울 수 있습니다. 그리고 때때로 A / B 테스트는 눈이 테스트 된 요소를 통과 한 후에 효과가 발생합니다. 헤더에 A/B 테스트가 있을 수 있으며, JavaScript가 실행되고 해당 요소가 변경되면 사용자는 이미 헤더를 지나서 스캔했습니다.
클라이언트 측 A/B 테스트의 문제
- 일반적으로 정적 사이트에 대한 유일한 옵션입니다.
- JavaScript가 실행될 때까지 실행되지 않습니다.
- 테스트를 무효화할 수 있는 성능 저하
Layer0 Edge 실험은 엣지에서 A/B 테스트를 활성화하여 이러한 문제를 해결합니다. XDN에서 새로운 환경은 항상 네이티브, 캐싱 및 1초 미만의 시간이 됩니다. 이것은 A / B 테스트를 넘어 귀하의 웹 사이트의 모든 변종으로 확장됩니다.
엣지 실험
Layer0은 또한 내장 된 강력한 에지 실험 엔진과 함께 제공 됩니다. 이 모듈은 CDN-as-JavaScript의 일부이며 모든 변형을 인식하므로 각 변형이 엣지에서 개별적으로 캐시됩니다. 이렇게 하면 방문자가 어떤 변형을 보는지 정확하게 제어할 수 있습니다.
Edge 실험을 통해 다음을 수행할 수 있습니다.
- 네트워크 에지에 구축된 지점으로 실시간 트래픽 라우팅
- A/B 테스트, 카나리 배포 또는 기능 플래그 실행
- 확률이나 헤더 값 및
- IP 주소
Edge Experiments를 사용하면 사이트 성능에 영향을 주지 않고 테스트를 쉽게 분할할 수 있습니다. 사용이 간편하면서도 강력한 인터페이스를 통해 엣지에서 분할이 실행됩니다. Edge 실험은 A/B 및 다변량 테스트, 카나리 배포, 파란색-녹색 테스트, 레거시 웹 사이트의 반복 마이그레이션, 개인화 등에 사용할 수 있습니다.
고객이 Layer0에서 얻는 이점
Layer0은 Jamstack 및 헤드리스(headless)로의 원활한 전환을 제공하며, 카탈로그가 크거나 업데이트가 빈번하거나 레거시 전자 상거래 플랫폼을 실행하는 사이트에 큰 이점을 제공합니다. 신발 카니발 및 턴키 휴가 대여는 Jamstack을 사용하는 대규모 사이트의 개발자 팀과 Layer0에서 전자 상거래를 위해 헤드리스(headless)를 사용하는 두 가지 예입니다.
Turnkey
Turnkey Vacation Rentals는 전국 최고의 여행 목적지에 있는 프리미엄 및 고급 수준의 임대 주택을 위한 풀 서비스 휴가 임대 부동산 관리 회사입니다. Airbnb와 같은 사이트와 달리 턴키는 사전 심사 된 리스팅만 제공합니다. 또한 표준화된 기술 도구 세트를 사용하여 관리 세부 사항을 중앙에서 처리합니다.
원래 설정
Turnkey는 AWS Elastic Beanstalk의 Docker 내부에서 앱을 실행하고 있었으며, 성능에 대한 보다 뛰어난 제어력과 통찰력을 제공하는 솔루션을 찾고 있었습니다.
Jamstack 솔루션 몇 가지를 고려했지만 Layer0과 같이 Next.js를 기본적으로 지원하는 플랫폼을 원했습니다. 결정적인 요인 중 하나는 Layer0을 사용하면 코드베이스와 데이터 파이프라인의 작동 방식을 리팩터링하는 것을 피할 수 있다는 것입니다.
Layer0은 아래에 나열된 몇 가지 기능으로 턴키 민첩성을 높이는 데 도움이되었습니다.
환경
과거에는 Turnkey가 Jenkins 내부에 구축된 맞춤형 파이프라인을 사용했으며 팀은 트렁크 지점에서 배포했으며 프로덕션 단계에 대한 완벽한 확신을 갖지 못했습니다.
Layer0을 사용하면 지점마다 개별 환경이 있으며 Turnkey의 팀은 원시 환경을 설정할 수 있습니다. QA를 통과할 때까지 스테이징 환경으로 병합되지 않습니다. 이것은 QA와 관련된 정신적 부담을 제거합니다.
로그
Beanstalk에서 서버 로그를 조사하는 것은 악몽일 수 있습니다. 찾고 있는 로그, 해당 로그가 켜져 있는 서버, 로드 밸런싱 여부 등을 정확히 파악해야 합니다. Layer0을 사용하면 빌드에서 직접 로그를 라이브 스트리밍할 수 있으므로 문제를 해결하려는 빌드를 찾고 재생을 누르고 로그를 볼 수 있습니다.
증분 마이그레이션
턴키는 React/Next.js가 아닌 페이지를 가지고 있었고 이전 아키텍처에서 실행되었습니다. Layer0을 사용하면 이미 마이그레이션한 것을 XDN에 추가하고 계속해서 점진적으로 마이그레이션할 수 있습니다.
Layer0은 턴키 도구의 팀에게 성능에 집중하도록 했습니다.
Shoe Carnival
Shoe Carnival Inc.는 미국의 신발 소매업체입니다. 이 회사는 현재 미국 중서부, 남부 및 남동부 지역에 419개의 오프라인 매장과 함께 온라인 매장을 운영하고 있습니다.
아래는 신발 카니발 팀이 특히 유용하다고 판단한 Layer0의 기능 중 일부입니다.
유연성
Shoe Carnival은 Salesforce Commerce Cloud를 사용하는데, 이는 Shoe Carnival과 같은 헤드리스 프런트엔드를 운영하기 위한 것이 아닙니다. 따라서 프런트엔드에 데이터를 실행하기 위해 백엔드 측에서 많은 공학과 이해가 있었습니다. 이러한 과제는 Salesforce와 React 프런트엔드 사이에 있는 Layer0 백엔드의 유연성 때문에 해결할 수 있었습니다. Shoe Carnival의 팀은 React를 사용하여 자유롭게 구축하고 Salesforce의 한계를 무시할 수 있었습니다.
생산 증진에 걸리는 시간
신발 카니발의 생산 시간은 극적으로 증가했습니다. 팀은 Salesforce 개발 주기와 분리되어 배포를 매우 빠르게 변경할 수 있습니다.
사이트 속도
생산 속도는 큰 이점이지만 Shoe Carnival의 평균 페이지 로드가 5-6초에서 단 몇 초로 증가했기 때문에 사이트 성능은 일반적으로 무시하기가 어렵습니다. 매우 세분화된 수준으로 캐싱할 수 있으며 고객이 원하는 정보를 항상 최신 상태로 유지할 수 있는 툴을 갖추고 있습니다.
증분 배포
점진적 배포를 통해 팀은 전체 응용 프로그램을 구축하여 배포하는 것보다 훨씬 빠르게 프로덕션에 배포할 수 있습니다.
Layer0으로의 마이그레이션의 영향에 대해 Shoe Carnival이 CDN 수준에서 헤드리스 사이트에 대해 50/50의 전환을 테스트했을 때 헤드리스 사이트가 항상 승리하여 오리진 사이트를 능가하고 속도와 가시성을 향상시켰습니다.
요약
Layer0에서는 Jamstack이 웹 개발의 미래라고 믿습니다. Layer0은 전통적인 정적 기법이 일반적으로 적용되지 않는 대규모 동적 이커머스 사이트의 프런트 엔드 개발자 팀에 Jamstack의 성능 및 단순성 이점을 제공합니다. 우리는 이것을 동적 Jamstack이라고 부릅니다. SPA 웹 사이트를 즉시 로드하고 개발하기가 쉽습니다.
Layer0에는 애플리케이션 인식 CDN-as-JavaScript가 함께 제공되므로 현재 CDN을 보완하거나 대체할 수 있으며 필요한 모든 웹 보안 기능을 엣지로 가져올 수 있습니다. Layer0에는 개발, 배포, 미리보기, 실험, 모니터링, 자동화된 전체 스택 미리 보기 URL, 프런트엔드를 위한 서버리스 JavaScript 백엔드, 고급 캐시 모니터링 등을 포함하여 헤드리스 프런트엔드를 간단하게 실행할 수 있습니다.
Layer0은 다음과 같은 기능을 제공하는 올인원 개발 플랫폼입니다.
- 사전 렌더링과 Just-in-Time 렌더링을 통해 전자 상거래용 Jamstack 활용
- 제품 카탈로그 API에서 데이터를 프리페치하여 지연 시간이 없는 네트워킹 지원
- 앱에서 기본적으로 엣지 구성(CDN-as-JavaScript)
- 에지 규칙을 로컬로 실행 및 사전 프로덕션에서 실행
- GitHub, GitLab 또는 Bitbucket에서 모든 새 브랜치와 푸시로 미리보기 URL을 만듭니다.
- 성능 A/B 테스트, 카나리 배포 및 개인화를 위해 엣지에서 분할 실행
- AWS Lambda보다 훨씬 쉽고 안정적인 서버리스 JavaScript
