Managed Runtime の概要

Managed Runtime は、PWA Kit ストアフロントをデプロイ、ホスト、およびモニタリングするためのインフラストラクチャとなるものです。

このガイドでは、Managed Runtime の主要部分とそのアクセス方法について説明します。

環境とは、Managed Runtime でホストされている特定のストアフロントのすべてのクラウドインフラストラクチャと構成値を指す用語です。環境は、Production (本番) のストアフロントを、開発やテストなどのその他の目的でデプロイされたストアフロントから分離するために使用されます。

環境は、自動的にスケールアップまたはスケールダウンする効率の高いマイクロサービスで実行されます。このため、追加コストなしに必要に応じていくつでも環境を作成できます。たとえば、1 つのアジャイルな開発スプリントのために短期間の環境を作成したり、そのスプリント内に 1 つのユーザー事例のための環境を作成したりできます。環境は必要がなくなったら、削除することをお勧めします。

Production (本番) とマークされている環境は、Salesforce のサポートチームによるモニタリングで優先度が高くなります。Production (本番) 環境では、Log Center を使用してデバッグすることもできます。環境を Production (本番) としてマークするには、次の 2 つの方法があります。

1. Runtime Admin ツールを使用する。環境を作成する、または既存の環境に変更を加えるための詳細な手順については、「管理」ガイドの環境セクションで説明しています。
2. Managed Runtime API を使用する。projects_target_create および projects_target_partial_update の両方のエンドポイントで is_production パラメーターを使用します。これらのエンドポイントで環境を Production (本番) としてマークするには、is_production を true に設定します。

環境で実行されるストアフロントコードは、バンドル と呼ばれます。PWA Kit に含まれるデベロッパーツールを使用して、バンドルを生成したり、Managed Runtime にプッシュしたりします。

バンドルのプッシュ後、Runtime Admin または Managed Runtime API を使用してそのバンドルを「デプロイ済み」として指定することができます。各プロジェクトには複数のバンドルを含めることができますが、「デプロイ済み」として指定したバンドルは、各環境に 1 つのみ含めることができます。「デプロイ済み」として指定したバンドルは、いつでも変更できます。詳細については、バンドルのプッシュとデプロイを参照してください。

複数の環境の管理を支援するために、各環境はプロジェクトにも属し、各プロジェクトは組織に属します。組織には、複数のストアフロントの複数のプロジェクトを含めることができ、各プロジェクトには複数の環境を含めることができます。Managed Runtime ユーザーは、異なる作業ストリームを区別するために、複数の組織に属することができます。

各組織は最大合計 100 個の環境と、最大 10 個の Production (本番) 環境をもつことができます。これらの制限を増やしたい場合は、Salesforce サポートの担当者までご連絡ください。

組織とユーザー組織のメンバーシップは、Account Manager の設定によって決定されます。ユーザーは、メンバーまたは管理者のどちらかとして組織に所属することができます。メンバーは、Managed Runtime でプロジェクトの役割が割り当てられているプロジェクトにのみアクセスできます。管理者は、組織内のすべてのプロジェクトにアクセスできます。

ユーザーは Managed Runtime プロジェクトで以下の機能を使用できます:

• **参照: ** Runtime Admin でのプロジェクトの表示。
• リダイレクトの管理: プロジェクトのリダイレクトの管理。詳細については、リダイレクトのドキュメントを参照してください。
• デプロイ: 新規バンドルのデプロイ、または古いバンドルのデプロイの解除。
• チームの管理: プロジェクトのチームメンバーの役割の表示、追加、招待、および編集。
• アクセスログ: すべての環境にわたってログをテール。

割り当てられたプロジェクトの役割に応じて、各ユーザーが使用できる機能は異なります。(ユーザーは 1 つ の役割のみをもつことができます。) プロジェクトの役割は、組織内のどのユーザーにも割り当てることができます。

以下の表は、各役割に関連付けられている機能を示しています:

各 Managed Runtime 環境内では、公開されたバンドルの React アプリが Node.js 環境内で実行されます。ページリクエストに応答して結果をレンダリングするために、当社では Express Web フレームワークを PWA Kit のレンダリングとルーティングのシステムとともに使用しています。当社ではこの React、Node、および Express の組み合わせをアプリケーションサーバーと呼んでいます。(ただし、技術的な観点から言えば、このアプリケーションサーバーは「サーバーレス」テクノロジーで実行しています。) アプリケーションサーバーは、低コンピューティングコスト、高い可用性、高速のレンダリング、および大規模なスケーリング機能を提供するクラウドインフラストラクチャで実行するように最適化されています。

PWA Kit のレンダリングとルーティングのシステムによってローカル開発環境と Managed Runtime 環境の間の差が処理されるので、コードをデプロイすると予想通りに実行されます。この予測可能性によって、バンドルをより頻繁にデプロイすることが促進され、開発チームの生産性が向上されます。

現在アプリケーションサーバーは、Transport Layer Security (トランスポートレイヤーセキュリティー、TLS) バージョン 1.2 以降をサポートしています。

アプリケーションサーバー上で動作するコードは、次の環境変数にアクセスできます。

• DEPLOY_TARGET: 環境の ID。
• EXTERNAL_DOMAIN_NAME: 環境に設定されているドメイン名。
• MOBIFY_PROPERTY_ID: その環境が属するプロジェクトの ID。

アプリケーションサーバーをサポートするものに、以下にあげるいくつかのエッジサービスがあります:

• 攻撃者から環境を保護する Web アプリケーションファイアウォール (WAF)
• API リクエストを高速化するプロキシサーバー
• リクエストをキャッシュしてページの読み込みを高速化するコンテンツ配信ネットワーク (CDN)
• リクエストとリダイレクトを処理する Edge 関数

プロキシサーバーと CDN については、当社のリクエストのプロキシガイドに詳しく説明されています。リクエストプロセッサーと呼ばれるエッジ関数については、当社のキャッシュヒット率の最大化ガイドに説明されています。

Managed Runtime のエッジサービスは、当社のパブリッククラウドインフラストラクチャ全体に戦略的に分配されています。各サービスは、パフォーマンスを向上させるために、ユーザーにできるだけ近い場所に配置されています。

組織、プロジェクト、環境、およびバンドルの設定を管理するために、次の 2 つのツールが用意されています:

1. Managed Runtime Admin (Web ベースの UI)
2. Managed Runtime API (Web ベースのツールと同じ機能に加え、追加の機能を提供する REST 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 リクエスト行とヘッダーの最大サイズは 10240 バイトです。このサイズを超えるリクエストは、HTTP 413 Content Too Large を返します。
• Cookie (HTTP リクエスト Cookie と HTTP レスポンス Set-Cookie ヘッダーを含む) は、デフォルトではサポートされていません。これらは、projects_target_partial_update エンドポイントのある環境で allow_cookies 属性を設定することで有効にできます。また、Runtime Admin の環境設定で Cookie を有効にすることもできます。Cookie は、PWA Kit バージョン 3.1.0 以降でサポートされています。Cookie によるパーソナライズを参照してください。
• ヘッダーが _ で始まるリクエストはサポートされていません。これらのリクエストは破棄されます。
• 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 秒に制限されています。
• 未処理のプロミス拒否があると、アプリのレンダリングが破損します。

• バンドルの最大サイズは 400 MB で、バンドル内のすべての ssr_only および ssr_shared のファイルの最大サイズは 249 MB です。
• アップロードして提供できる静的アセットのコンテンツタイプは、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 状況 で Managed Runtime サービスの可用性に関する更新を購読できます。

これで Managed Runtime の概要の説明が終わりました。次は実践してみましょう。バンドルのプッシュとデプロイのガイドから始めることをお勧めします。

• Managed Runtime の管理
• Managed Runtime API ガイド
• Managed Runtime API 参照資料