

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 移行の計画
<a name="plan-migration"></a>

移行プロセスを計画することは、移行を円滑かつ成功させるために重要です。以下のセクションでは、移行の計画方法と、移行に関する主な考慮事項について概説します。

**Topics**
+ [何を移行するかを決定する](migration-decision-process.md)
+ [構成のデスケーリング](descale-configurations.md)
+ [インスタンスタイプの選択](instance-choice.md)
+ [重要な決定ポイント](key-decision-points.md)
+ [高レベルの移行概要](high-level-migration-overview.md)

# 何を移行するかを決定する
<a name="migration-decision-process"></a>

移行するときは、どのワークロードが不可欠で、どのワークロードが必須ではないが「あれば良い」のか、どのワークロードが不要で、[移行が完了したら廃止できるか](https://docs.aws.amazon.com//prescriptive-guidance/latest/migration-retiring-applications/welcome.html)を判断する必要があります。

意思決定プロセスの大部分は、自動化、API、ツール、その他のプロセスに関する個別の要件に関係します。また、組織の機能要件やパフォーマンス要件も考慮する必要があります。

たとえば、ユーザーパーティションのある既存のデータセンターで共有ハードウェアプラットフォームを使用したことがあるかもしれません。ただし、移行の際には、ハードウェアアクセラレーションソリューションからの移行によるパフォーマンス上の制限により、あまり広く共有されていないシステム上でサービスを実行する必要が生じる場合があります。たとえば、Secure Sockets Layer (SSL) の 1 秒あたりのトランザクション数 (TPS) では、特定のサービスを共有システム上で実行しないことが必要になる場合があります。

移行するアプリケーションとその要件を特定して文書化したら、次のベストプラクティスを使用してソースシステムを準備する必要があります。
+  AWS クラウドで実行するのと同じバージョンの F5 TMOS を実行します。[バージョン 14.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-14-1-0.html) 以降が推奨されますが、[バージョン 13.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-ve-13-1-0.html) 以降も使用できます。バージョン [12.1.x](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-12-1-5.html) を移行することはできますが、セキュリティ、自動化、保守性の問題が発生する可能性があります。
+  各デバイスのすべての設定について、有効なバックアップが必要です。Univention Corporate Server (UCS) のバックアップにはデータセンター固有のアトリビューションとオブジェクト (IPアドレス、ノード、プールメンバーなど) が含まれているため、F5 ではシェルコマンドファイル (SCF) を作成して構成を編集およびマージすることを推奨しています。
+  関連するセキュリティ証明書をすべてバックアップし、パフォーマンスを向上させるために RSA 暗号化から ECC 暗号化への変更を検討してください。
+ スケーリングとキャパシティプランニングのために、仮想サーバーレベルで詳細なパフォーマンスメトリックを用意してください。
+ データセンターから AWS クラウドへのカットオーバー用の [F5 Global Server Load Balancing (GSLB)](https://www.f5.com/solutions/use-cases/global-server-load-balancing-gslb) ソリューションを用意します。
+ ハードウェアアプライアンスモデルからソフトウェアおよび仮想化モデルへの移行がパフォーマンス、スケーラビリティ、および高可用性の観点から与える影響を理解してください。
+  AWS クラウドに移行する要件を定義し、以下の考慮事項に注意してください。
  +  AWS クラウドへの移行には、設定全体または一部の移行を決定する必要があることに注意してください。通常、一度に 1 つの部分的な移行を行う方が効率的です。
  +  どのルートと IP アドレスが変更されるかを把握しましょう。
  +  どの SNAT プールを F5 SNAT Automap に置き換える必要があるかを特定してください。

 また、[AWS パートナー](https://partners.amazonaws.com/partners/001E000000Rl12PIAR/F5%20Networks)または F5 プロフェッショナルサービスチームに相談することも検討してください。これにより、移行が成功する可能性が高くなります。

# 構成のデスケーリング
<a name="descale-configurations"></a>

「デスケール」とは、最初の検出結果後に必要な特徴量や指標に基づいて、F5 BIG-IP 構成をより低い、またはよりコスト効率の高い構成に移行することを意味します。これらのオプションはすべてアーキテクチャと必要なインスタンス数に影響するため、慎重に評価する必要があります。

次の図は、デスケーリングがニーズや要件に適しているかどうかを評価するのに役立ちます。

 ![\[Process flow for descaling a configuration.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-descale.png) 

この移行により、以下の点でも新たな検討事項が生まれます。
+ **ネットワークトポロジ** – は現在`802.1q `、タグ付けされた VLANsをサポート AWS していないため、インスタンスインターフェイスの数 (管理用の 1 つを除く) は、インスタンスがサポートできるネットワークの数に制限があります。特定のトポロジが必要な場合は、F5 が AWS クラウドでサポートするさまざまなインスタンスと比較して評価する必要があります。
+ **SSL パフォーマンス** — F5 アプライアンスとシャーシは、`x86` で達成できることを上回る SSL パフォーマンスを備えています。集約型および仮想サーバごとの SSL 要件を評価する必要があります。
+ **ネットワークパフォーマンス** – 集約、アウトバウンド、および内部のネットワーク特性を評価する必要があります。 AWS インスタンスタイプには、考慮すべき異なるネットワーク特性 (低、中、高、最大 X、または専用) があります。また、1 つのインスタンスがアウトバウンドまたは直接接続を介して送信できるトラフィック量にも制限があります。
+ **VIP 密度** — 仮想 IP アドレス (VIP) の数が多い場合は、ネットワークインターフェースにマッピングできる VIP の数に対するインスタンスの制限を考慮する必要があります。
+ **同時接続** — インスタンスがサポートできる接続の最大数にはフロー制限があります。
+ **セッションステート** — アプリケーションが異なれば、使用する永続性のタイプも異なります。ステートフルアプリケーションとステートレスアプリケーションでは、使用されるメソッドが共有ステートに変更され、イン/アウト操作をスケールする際に影響する可能性があります。

# インスタンスタイプの選択
<a name="instance-choice"></a>

F5 は複数のインスタンスタイプをサポートしているため、どのインスタンスタイプを使用するかを選択するの難しい決断です。ほとんどの移行では、ネットワーク性能、CPU 密度、インターフェイス密度、インスタンスでサポートできる IP 数の組み合わせを提供するため、`c5n.2xl` と `c5n.4xl` が最も一般的なインスタンスの選択肢になります。次の図は、使用している F5 製品に基づいて、どのインスタンスを選択すべきかの例を示しています。



 ![\[Process flow for choosing which instance type to use.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-instance-choice.png) 

# 重要な決定ポイント
<a name="key-decision-points"></a>

移行には考慮すべき点がたくさんありますが、F5 BIG-IP ワークロードの移行を開始する前に、次の質問を自問して移行プロセスを明確にしてください。

**アプリケーションのユーザーは誰ですか?**

これらが内部ユーザー (Elastic IP アドレスを経由しない) ユーザーなのか、外部 (Elastic IP アドレスを経由しない) ユーザーなのかを評価してください。ユーザーが内部ユーザーの場合は、アベイラビリティーゾーンやアクティブなデプロイの障害に対応するためにアプリケーションが DNS を使用できるかどうかを評価してください。サブネットを複数のアベイラビリティーゾーンにまたがるような代替デザインパターンを使用する必要があるかどうかも確認する必要があります。

**アプリケーションのどの部分を AWS クラウドに移行しますか? ** 

アプリケーション全体を移行するのか、プレゼンテーション層だけを移行するのかを評価してください。セキュリティと DNS ネームスペースに関するその他の依存関係も考慮する必要があります。評価では、ネットワークトポロジーに何が必要かを判断する必要があります。さらに、アベイラビリティーゾーン、VPC、または AWS リージョンレベルでイベントが発生した場合に、サービスレベルアグリーメント (SLA) に何が必要かを決定します。

**なぜアプリケーションが移行されるのですか?**

データセンターを閉鎖したり、伸縮性を高めたいという理由で、アプリケーションを移行しているかもしれません。アプリケーションがアプリケーションごとのアーキテクチャに移行しようとしているかどうかを、多くのデータセンターに共通するモノリシックパターンと比較して評価してください。また、移行に伴ってどのようなモダナイズの取り組みを行うべきかも検討する価値があります。

**アプリケーションの移行先はどこですか?**

アプリケーションを 1 つのアベイラビリティーゾーンを持つ単一の VPC に移行する必要があるのか、それとも 2 つのアベイラビリティーゾーンに移行する必要があるのかを評価します。ピア VPC またはトランジット VPC のトポロジと、マルチリージョンデプロイの必要性を判断します。これらは移行パターンの設計に影響します。



# 高レベルの移行概要
<a name="high-level-migration-overview"></a>

移行を開始する前に、プロセス全体を概略的に整理しておくと便利です。F5 BIG-IP ワークロードを AWS クラウドに移行する手順の例を次に示します。F5 BIG-IP 移行のより詳細な手順とプロセスは、 [AWS クラウド上の F5 BIG-IP ワークロードを F5 BIG-IP VE に移行する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-f5-big-ip-workload-to-f5-big-ip-ve-on-the-aws-cloud.html?did=pg_card&trk=pg_card)パターンで確認できます。

1.  個々の要件に基づいて、必要な数の VPC をデプロイします。これは手動で行うことも、[AWS ランディングゾーン](https://aws.amazon.com//solutions/implementations/aws-landing-zone/) などのツールを使用して自動化することもできます。

1.  現在の F5 のライセンス、使用状況、構成を評価してください。

1. 公開アプリケーションと社内アプリケーションを評価します。

1.  現在の F5 構成を評価してください。

1.  サイズと IP アドレスの要件を評価し、F5 インスタンスと AWS インスタンスの必要な数とタイプを選択します。

1.  どの移行戦略をデプロイすべきかを特定します。たとえば、リフトアンドシフト、リフト、シフトアンドモダナイズ、またはハイブリッドなどです。

1.  DNS 設計を評価し、特定します。

1.  オンプレミスと AWS クラウドの両方に存在する場合、トラフィックがどのようにアプリケーションに転送されるかを評価します。

1.  AWS CloudFormation テンプレートを使用して F5 インスタンスの初期デプロイを実行します。

1.  エラスティックネットワークインターフェースとルートテーブルを追加して、トポロジー要件を満たすようにデプロイを変更します。

1.  Elastic IP アドレスをセルフ IP または管理 IP に合わせ、Elastic IP から仮想 IP (VIP) へのマッピングを計画します。

1.  エラスティックネットワークインターフェイスに VIP 用のセカンダリアドレスを作成します。

1.  AWS クラウドにセカンダリアドレスを適用します。

1.  Elastic IP アドレスを VIP のセカンダリアドレスにマッピングします。

1.  設定をプルし、移動するオブジェクトのリストをコンパイルします。

1.  構成を F5 BIG-IP にデプロイします。

1.  セカンダリアドレスを VIP にマッピングします。

1.  トラフィックをテストします。

1.  フェイルオーバーテスト。

1.  ハイブリッドを構築する場合は、必ずシステムを F5 DNS に組み込んでください。

**重要**  
 AWS API エンドポイントへのアクセスが必要です。アベイラビリティーゾーン内またはアベイラビリティーゾーン間の高可用性を実現するには、NAT または Elastic IP アドレスも必要です。

次の図は、F5 BIG-IP 移行の高レベルなプロセスフローを示しています。

 ![\[High-level process flow for an F5 BIG-IP migration\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-high-level.png) 