ランタイム間でワークロードを移す
既存の実行は移行元で完了させ、新規開始を移行先に送ります。この手順は独立したサービスモードのランタイムを対象とします。履歴のエクスポートは証跡の保存であり、Server で開始した実行を稼働状態のまま転送する機能ではありません。対応する embedded v2 インポートは、条件を満たす embedded の移行元だけを受け付けます。
移行先を選ぶ
| 移行 | 移行先の準備 |
|---|---|
| セルフホスト Server から別のセルフホスト Server | 独自の正本データベース、ペイロードストレージ、認証情報で移行先をデプロイします。デプロイガイドに従ってください。 |
| セルフホスト Server から Cloud | 移行先の名前空間をプロビジョニングし、返されたランタイム URL、認証情報、機能を確認します。Cloud の設定に従ってください。 |
| Cloud からセルフホスト Server | アプリケーションのトラフィックを変更する前に、移行先と SDK ワーカーを準備します。移行元の実行が完了するまでは Cloud をプロビジョニング済みのまま維持します。 |
両方のランタイムを準備する
移行元の各エンドポイント、名前空間、ワークフローインスタンス ID、実行 ID、タスクキュー、ワークフローとアクティビティの型、ペイロードストレージの依存関係を記録します。セルフホストのストレージには検証済みの復旧手段を確保します。Cloud からの移行は、データベースバックアップへのアクセスや認証情報のコピーを許可するものではありません。移行先の実際のリリースと機能、ロール別認証情報、ワーカー登録、公開された型を確認してください。
新規開始を小さな単位で切り替える
- 移行元と並行して移行先とワーカーを起動します。一意の ID を持つカナリア実行で、代表的なアクティビティと結果まで完了させます。実際の業務に影響しないよう副作用を隔離してください。
- アプリケーション呼び出し、スケジュール、webhook/bridge アダプター、サービス呼び出しなど、開始元をすべて把握します。ワークフローの1系統について切り替え時点を決めます。スケジュールの一時停止と移行先への登録を調整し、同じ予定を両方のランタイムで開始しないようにします。
- その系統の新規開始を移行先に送ります。各ワークフローを受理したエンドポイントと名前空間をアプリケーション側で記録します。別のランタイムで同じ業務キーを使っても、ランタイム間の重複排除にはなりません。
- シグナル、承認、更新、クエリ、キャンセル、結果と履歴の読み取りは、実行を所有するランタイムに送り続けます。移行元のワーカー、キュー、タイマー、認証情報、ペイロードへのアクセスを維持します。クライアントの URL を変えても、受理済みの処理やアクティビティのリースは移りません。
- 次の系統に進む前に結果と失敗を確認します。通信の問題で開始結果が不明な場合は、別のランタイムへ送信する前に元のランタイムで結果を確認します。終端状態にならない長期間の実行は、ドレインできていません。
廃止する前に証跡を保存する
必要な継続実行すべて、元のペイロードバイト列、コーデックを含め、保持する必要がある履歴をエクスポートします。互換性のある読み取り側で完全性と整合性を確認し、正確な生成側の識別情報を保存します。履歴エクスポートとリプレイのガイドで、それぞれの確認を説明しています。監査用エクスポートによって、Server の実行を稼働状態でインポートできるようにはなりません。
実際にエクスポートを提供する生成側を確認してください。Core 2.11.4 だけでは、Server、付属 CLI、SDK HTTP、Cloud のエクスポートは検証済みになりません。別途行われる Server HTTP 生成側とイメージの検証を確認してください。過去の欠損したバンドルは無効なままです。数値やチェックサムを書き換えて受理させてはいけません。必要な証跡を取得または検証できない間は、正本の移行元を破棄しないでください。
移行元は最後に廃止する
対象の名前空間すべてと一覧の全ページを確認し、移行元が所有する非終端の実行が残っていないことを確かめます。待機中の親子や、残った開始元が作る実行も対象です。正常なエンドポイント、空の最初のページ、取得不能なメトリクスだけでは、未完了の処理がない証明にはなりません。呼び出し元、コールバック、ワーカーに依存が残っておらず、必要なアーカイブを読めることを確認してください。
その後でセルフホストのリソースを廃止するか、Cloud ランタイムをデプロビジョニングします。Cloud の容量料金は、アイドル中やドレイン中も、プロビジョニングされている間は発生します。デプロビジョニングは稼働データと認証情報を削除する操作であり、一時停止と再開ではありません。既存プランから返された課金条件を使用してください。この手順による自動返金や課金の例外はありません。
実行を移さずルーティングを戻す
今後の新規開始を戻す場合は、正常で互換性のある移行元だけを使います。移行先がすでに受理した実行は引き続き移行先が所有し、終端状態になるまでそのワーカーとコマンドのルーティングが必要です。両方の所有記録を保ち、重複した開始を防いでください。新しく受理した状態に古い移行元のストレージを上書きしたり、同じ実行の2つ目の稼働コピーを再開したりしてはいけません。