Managed Runtime 개요

Managed Runtime은 PWA Kit 스토어프런트를 배포, 호스팅 및 모니터링할 수 있는 인프라를 제공합니다.

이 가이드에서는 Managed Runtime의 주요 요소와 액세스 방법에 대해 설명합니다.

환경은 Managed Runtime에서 호스팅하는 특정 스토어프런트의 모든 클라우드 인프라 및 구성 값을 설명하는 용어입니다. 환경은 개발, 테스트 등의 다른 용도로 배포되는 스토어프런트와 프로덕션 스토어프런트를 구분하는 데 사용됩니다.

환경은 자동으로 확장 및 축소되는 매우 효율적인 마이크로서비스에서 실행되므로, 추가 비용 없이 필요한 만큼의 환경을 만들 수 있습니다. 예를 들어 단일 애자일 개발 스프린트 전용으로 수명이 짧은 환경을 만들거나, 스프린트 내의 단일 사용자 사례를 위한 환경을 만들 수 있습니다. 환경이 더 이상 필요하지 않은 경우 해당 파일을 삭제하는 것이 좋습니다.

Production으로 표시된 환경은 Salesforce의 지원 팀이 우선적으로 모니터링합니다. 프로덕션 환경의 경우 Log Center를 사용하여 디버깅할 수도 있습니다. 다음 두 가지 방법으로 환경을 Production으로 표시할 수 있습니다.

1. Runtime Admin 도구를 사용합니다. 환경을 생성하거나 기존 환경을 편집하는 방법에 대한 단계별 지침은 관리 가이드에서 환경 섹션을 참조하십시오.
2. Managed Runtime API를 사용합니다. projects_target_create 엔드포인트와 projects_target_partial_update 엔드포인트 모두에는 is_production 매개변수가 있습니다. 환경을 프로덕션으로 표시하려면 이 is_production을 true로 설정합니다.

환경에서 실행되는 스토어프런트 코드를 번들이라고 합니다. PWA Kit에 포함된 개발자 도구를 사용하여 번들을 생성하고 Managed Runtime에 푸시합니다.

번들을 푸시한 후 Runtime Admin 또는 Managed Runtime API를 사용하여 번들을 "배포됨" 상태로 지정할 수 있습니다. 각 프로젝트에는 여러 번들이 있을 수 있지만 각 환경에는 배포됨 상태로 지정된 번들이 하나만 있을 수 있습니다. 배포됨 상태로 지정된 번들은 언제든지 변경할 수 있습니다. 자세한 내용은 번들 푸시 및 배포를 참조하십시오.

여러 환경을 쉽게 관리할 수 있도록 각 환경은 프로젝트에 속하고 각 프로젝트는 조직에 속합니다. 조직은 여러 개의 스토어프런트에 대한 여러 프로젝트를 포함할 수 있으며 각 프로젝트는 여러 환경을 포함할 수 있습니다. Managed Runtime 사용자는 여러 조직에 속할 수 있으며, 이 경우 서로 다른 작업 스트림이 구분됩니다.

각 조직은 총 최대 100개의 환경과 최대 10개의 프로덕션 환경을 가질 수 있습니다. 이러한 한도를 늘려야 할 경우 Salesforce 지원 담당자에게 문의하십시오.

조직 및 사용자 조직 멤버십은 Account Manager의 설정에 따라 결정됩니다. 사용자는 멤버 또는 관리자로 조직에 속할 수 있습니다. 멤버는 프로젝트 역할이 할당된 Managed Runtime의 프로젝트에 대해서만 상호 작용할 수 있습니다. 관리자는 조직 내의 모든 프로젝트와 상호 작용할 수 있습니다.

사용자는 Managed Runtime 프로젝트에 다음 기능을 사용할 수 있습니다.

• 탐색: Runtime Admin에서 프로젝트를 봅니다.
• 리디렉션 관리: 프로젝트의 리디렉션을 관리합니다. 자세한 내용은 리디렉션 설명서를 참조하십시오.
• 배포: 새 번들을 배포하거나 배포를 이전 번들로 되돌립니다.
• 팀 관리: 프로젝트에서 팀원의 역할을 보고, 추가하고, 초대하고, 제거하고, 편집합니다.
• 액세스 로그: 모든 환경에 걸쳐 로그를 추적합니다.
• **환경 변수 보기 및 관리:**각 환경에서 환경 변수를 보고 관리합니다. 환경 변수를 참조하십시오.

각 사용자에게는 수행할 수 있는 작업을 결정하는 프로젝트 역할이 할당됩니다. (사용자별로 역할을 하나만 할당할 수 있습니다.) 프로젝트 역할은 조직의 어느 사용자에게나 할당될 수 있습니다.

다음 표는 각 역할과 관련한 기능을 보여줍니다.

각 Managed Runtime 환경에서, 게시된 번들의 React 앱은 Node.js 환경 내에서 실행됩니다. 페이지 요청에 응답하고 결과를 렌더링하기 위해 PWA Kit의 렌더링 및 라우팅 시스템을 통해 Express 웹 프레임워크를 사용합니다. 이러한 React, Node 및 Express의 조합을 앱 서버라고 합니다. (단, 엄밀히 말하면 앱 서버는 "서버리스" 기술을 기반으로 실행됩니다.) 앱 서버는 낮은 컴퓨팅 비용, 고가용성, 빠른 렌더링 및 대규모 확장 용량을 제공하는 클라우드 인프라에서 실행되도록 최적화되었습니다.

PWA Kit의 렌더링 및 라우팅 시스템은 로컬 개발 환경과 Managed Runtime 환경 간의 차이를 처리하므로 코드를 배포할 때 코드가 예측 가능한 방식으로 실행됩니다. 이러한 예측 가능성은 개발 팀이 번들을 더 자주 빌드하도록 유도하여 생산성을 높입니다.

현재 앱 서버는 Transport Layer Security(TLS, 전송 계층 보안) 버전 1.2 이상을 지원합니다.

앱 서버에서 실행 중인 코드는 다음 환경 변수에 액세스할 수 있습니다.

• DEPLOY_TARGET: 환경의 ID
• EXTERNAL_DOMAIN_NAME: 환경의 도메인 이름 세트
• MOBIFY_PROPERTY_ID: 환경이 속한 프로젝트의 ID

앱 서버는 다음과 같은 몇 가지 엣지 서비스를 지원합니다.

• 공격자로부터 환경을 보호하는 웹 애플리케이션 방화벽(WAF)
• API 요청 속도를 높이는 프록시 서버
• 요청을 캐시하고 페이지 로드 속도를 높이기 위한 컨텐츠 제공 네트워크(CDN)
• 요청을 처리하고 리디렉션을 처리하는 엣지 함수

프록시 서버 및 CDN은 요청 프록싱 가이드에서 자세히 다룹니다. 요청 프로세서라는 엣지 함수는 캐시 적중률 극대화 가이드에서 다룹니다.

Managed Runtime의 엣지 서비스는 퍼블릭 클라우드 인프라 전체에 전략적으로 배포됩니다. 각 서비스는 더 빠른 성능을 위해 사용자에게 최대한 가깝게 배치됩니다.

조직, 프로젝트, 환경 및 번들에 대한 설정을 관리할 수 있도록 다음 두 가지 도구를 제공합니다.

1. 웹 기반 UI인 Managed Runtime Admin
2. 웹 기반 도구와 동일한 기능과 일부 추가 기능을 제공하는 REST API인 Managed Runtime API

환경에 새 코드 번들을 배포하는 것과 같은 일상적인 작업의 경우 Runtime Admin 도구를 사용합니다. 지속적인 통합 스크립트의 일부로 환경을 자동으로 생성하는 등 프로그래밍 제어가 필요할 때마다 API를 사용합니다.

관리자 도구를 사용하면 다음과 같은 다양한 설정을 직접 구성할 수 있습니다.

• 허용되는 IP 주소
• 허용되는 액세스 제어 헤더
• 현재 배포된 번들
• 배포 지역
• 프록시
• 리디렉션
• 사용자 권한
• Production 환경 플래그

관리 도구에 대한 액세스는 Account Manager 역할과 API 키로 제어됩니다. 지속적 통합(CI) 및 지속적 전송(CD) 프로세스의 경우 일반적으로 자체 API 키를 가진 전용 봇 사용자가 조직에서 프로비저닝합니다.

재미있는 사실: 스토어프런트처럼 Runtime Admin 도구는 Managed Runtime에 배포되는 헤드리스 React 앱입니다.

스토어프런트를 구축할 때는 다음과 같은 Managed Runtime 환경의 제약 조건을 고려하십시오.

• 환경은 HTTP Host 헤더가 Runtime Admin에 설정된 외부 호스트 이름과 일치하는 요청에만 응답합니다.
• 경로 /는 HTTP GET 요청만 받습니다.
• 요청 및 응답 크기는 6MB를 초과할 수 없습니다.
• HTTP 요청 줄 및 헤더의 최대 크기는 10,240바이트입니다. 이 크기를 초과하는 요청은 HTTP 413 Content Too Large 오류를 반환합니다.
• HTTP 요청 Cookie 및 HTTP 응답 Set-Cookie 헤더를 포함한 쿠키는 기본적으로 지원되지 않습니다. projects_target_partial_update 엔드포인트가 있는 환경에서 allow_cookies 특성을 설정하여 활성화할 수 있습니다. Runtime Admin의 환경 설정에서 쿠키를 활성화할 수도 있습니다. 쿠키는 PWA Kit 버전 3.1.0 이상에서 지원됩니다. 쿠키를 사용한 개인화를 참조하십시오.
• _로 시작하는 헤더가 있는 요청은 지원되지 않습니다. 이러한 요청은 삭제됩니다.
• Managed Runtime 환경에서 발생하는 HTTP 요청은 고정 IP 주소를 사용하지 않습니다. 앱 서버의 요청을 허용 목록에 추가하려면 EC2의 AWS IP 범위를 사용합니다. 프록시의 요청을 허용 목록에 추가하려면 CLOUDFRONT_ORIGIN_FACING을 사용합니다.
• 경로 접두사 /mobify는 관리되는 엔드포인트용으로 예약되어 있습니다. 이러한 엔드포인트에는 다음이 포함됩니다.
  • /mobify/ping: 환경이 정상적으로 작동할 때 HTTP 200 응답 코드를 반환합니다.
  • /mobify/redirect/$path: projects_target_redirect_retrieve와 유사한 응답을 반환합니다.
  • /mobify/proxy/$name: 프록시의 응답을 반환합니다.
• HTTP 요청 헤더 x-mobify-cachebreaker: 1를 사용하여 CDN 캐시를 우회할 수 있습니다.
• 환경 IP 허용 목록은 최대 250개의 IP 주소를 지원합니다. 이 한도는 올릴 수 없습니다.
• 환경 액세스 제어 헤더는 최대 2개의 헤더를 지원합니다. 각 헤더:
  • 최대 128자를 포함할 수 있습니다.
  • 영숫자와 - 및 _ 문자의 조합을 사용할 수 있습니다.
  • 액세스 제어 헤더를 참조하십시오.

• 앱 서버 요청의 실행 시간은 20초로 제한됩니다. 이 시간이 지나면 HTTP 504가 반환됩니다.
• 처리되지 않은 promise 거부가 있으면 앱 렌더링이 중단됩니다.

• 번들의 최대 크기는 400MB이고 번들 내의 모든 ssr_only 및 ssr_shared 파일의 최대 크기는 249MB입니다.
• 업로드 및 제공 가능한 정적 자산은 application/javascript, application/json, image/png ,image/gif, image/jpeg, image/svg+xml, image/webp, text/css, text/plain, 글꼴(ttf, woff, woff2, otf 등) 등의 컨텐츠 유형으로 제한됩니다. 다른 모든 콘텐츠 형식은 외부 시스템에서 제공해야 합니다.

Managed Runtime 프록시에는 서로 다른 제약 조건이 적용됩니다.

Salesforce Status에서 Managed Runtime 서비스의 가용성과 관련한 업데이트를 구독할 수 있습니다.

이제 Managed Runtime의 주요 부분에 대한 개요를 살펴보았습니다. 이제 실제로 사용해 보겠습니다. 먼저 번들 푸시 및 배포 가이드를 참조하십시오.

• Managed Runtime 관리
• Managed Runtime API 가이드
• Managed Runtime API 참조