Common Runtime から Private Space へのアプリの移行
この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。
最終更新日 2023年04月27日(木)
このガイドは、アプリを Common Runtime から Private Space へ最小限のダウンタイムで移行するのに役立ちます。アプリを Common Runtime から Private Space へ直接転送することはできません。ランタイムインフラストラクチャのアーキテクチャ上の違いから、アプリを手動で移行する必要があります。このガイドの手順は、Private Spaces と Shield Private Spaces の両方に当てはまります。
Premier または Signature Success Plan の Heroku Enterprise の顧客は、Customer Solutions Architecture (CSA) チームに、移行に関する詳細なガイダンスを要求できます。ここでエキスパートコーチングセッションについて学習するか、または Salesforce の担当者にお問い合わせください。
移行の前に
カスタムメンテナンスページを設定する
Common Runtime アプリのカスタムページを設定して、アプリの移行中にユーザーにメンテナンスモードで表示されるようにします。
ダウンタイムの計画
ダウンタイムを最小限に抑えるために、移行の数日前に DNS エントリの TTL 値を 1 分に低下させます。移行プロセスには、Private Space で実行中の新しいアプリを指定するように DNS エントリを更新することが含まれます。DNS の更新を伝播させるための若干のダウンタイムを計画してください。
Private 層データサービスへのデータの移行にも、一定の期間のダウンタイムが必要です。
アドオンの可用性と要件を確認する
移行対象のアプリでアドオンを再プロビジョニングする必要があります。アドオンでは Private Space に対するさまざまなレベルの可用性が提供されています。考えられる問題については、Add-on Runtime Availability (ランタイムでのアドオンの利用可能状況) の表を参照してください。
Available (利用可能): これらのアドオンは Private Space リージョンと互換性がありますが、プロビジョニングされて Space の外部で動作します。プライベート dyno とアドオンリソースの間のネットワークトラフィックが、パブリックインターネットを経由して送信されます。
Available and installable in space (利用可能かつ Space にインストール可能): これらのアドオンは Space 自体の内部でプロビジョニングされます。dynos とアドオンリソースの間のすべてのネットワークトラフィックは、プライベートネットワーク環境の内部に留まります。
Unavailable (利用不可): これらのアドオンは、Space 内部でプロビジョニングできず、Private Space リージョンとの互換性もありません。
Private Space に、一部のアドオンの機能を置き換える機能があることも考慮してください。たとえば、Common Runtime 内に静的 IP を提供するためにアドオンを使用していた場合、これは Space の組み込み機能であるため不要になります。
Private Space への移行の最適な方法に関する具体的な手順をプロバイダーが用意している場合があるため、各アドオンのドキュメントを参照してください。
Private Space でのアドオンの使用の詳細については、こちらを参照してください。
移行プロセス
以下の手順は一般的な移行プロセスを示しています。以下の手順にいくつか軽微な変更を加えることで、Private Space から Private Space へ、または Private Space から Shield Space へアプリを移行できます。
Premier または Signature Success Plan の Heroku Enterprise の顧客は、Customer Solutions Architecture (CSA) チームに、移行に関する詳細なガイダンスを要求できます。
- Private Space 内に新しいアプリケーションを作成します。
- Common Runtime について使用したのと同じ方法を使用して、コードを新しい Private Space アプリにデプロイします。
- アドオンをプロビジョニングして、dynos をスケールします。Heroku ボタンまたは app.json マニフェストファイルを使用した Platform APIを使用してコードをデプロイした場合、アドオンと dyno はすでに自動的に設定されています。
- Heroku データサービスを使用する場合、データを移行することをお勧めします。Private Space 内のアプリが Common Runtime の Heroku データサービスを引き続き使用することも可能ですが、Space に移行するとセキュリティがさらに高くなります。
- Heroku Postgres: ダウンタイムを最小限に抑えるために、フォロワーの切り替え方式を使用します。この方式では、新しいプライベートデータベースがプロビジョニングしているときに既存のデータベースの動作を続行することができます。古いデータベースに関連付けられていたデータクリップを新しいデータベースに再割り当てする必要があります。これらのデータクリップを復旧するには、help.heroku.com 経由でサポートチケットを開いてください。
- Heroku Data for Redis: アプリがメンテナンスモードの間にフォーク方式を使用して移行します。
- Heroku Kafka: メンテナンスモード中にこの手順に従って移行します。
- カスタムドメインと SSL を設定します。特定のアプリでは、同じドメインを一時的に既存の Common Runtime と新しい Private Spaces アプリの両方に割り当てて、移行ダウンタイムを削減することができます。Heroku サポートに連絡して、自分のカスタムドメインを新しい Private Spaces アプリに「強制的に」割り当てることを要求します。それができないことが確認されたら、Common Runtime からカスタムドメインを削除し、新しい Private Spaces アプリにそれらを追加します。
- 新しい Private Space アプリを指定するように DNS エントリを更新します。移行前に TTL 値を減らした場合、通常の値に復元できます。
- 新しい Private Spaces アプリを監視します。アプリログを監視してエラーがないか確認し、メトリクスを調べてパフォーマンスの問題の徴候がないか確認します。
Postgres データベースを移行した場合、データベースを削除する前に、古いデータベースから新しいデータベースにデータクリップを関連付けるようサポートに連絡したか確認します。
データサービスを移行せず、Common Runtime アプリにまだアタッチされている場合、古いアプリを削除しないでください。削除した場合、アタッチされているデータベースが古いアプリと一緒に削除されます。
移行が正常に完了できたことを確認したら、古い Common Runtime アプリを破棄します。