Jira の移行をスピードアップする方法
これまでの Enterprise 移行の経験に基づくと、現在、Jira Cloud Migration Assistant の平均スループットは 24 時間につき課題数 370 万件のスピードであると判断されます。これは平均スループットの推定値であり、環境によって異なる場合があります。このページで説明されている最適化を適用すれば、平均の 2 〜 3 倍以上のスループットを達成できる可能性があります。一部の移行では、24 時間で1,400 万件もの課題のスループットが実行されたケースもあります。
移行を遅らせる要因
ネットワーク品質
事前チェック中のエラー
プロジェクト内の課題の数
プロジェクトの数
添付ファイルのサイズ
ワークフローとカスタム フィールドの数
すべてのユーザーを移行するか、選択したユーザーだけを移行するか
対応策
このページでは、移行をスピードアップして、希望する時間枠に確実に収めて、ビジネスに不可欠なアプリケーションのダウンタイムを最小限に抑えるためにできることを説明します。
以下のヒントは変更を、早い段階で行うもの、移行直前に行うもの、移行中に行うものに分けて説明しています。
一般的な推奨事項
一般的な推奨事項は次のとおりです。
ハードウェア要件を確認し、CPU リソースを割り当てる
この推奨事項は、ユーザー数が 500 人を超える大規模なインスタンスに適用されます。小規模なインスタンスの移行速度ではそれほど長いダウンタイムは発生しないはずですが、この情報を利用して改善することはできます。
ハードウェアおよびサイズの設定要件を確認してください。要件を満たすことで、最適な移行速度が確保されます。一般的に、各ノードには最低 16 個の CPU を推奨します。ノード (Data Center 用) と CPU を追加すると、さらにスピードアップできます。
Jira Data Center のインフラストラクチャの推奨事項
移行用の AWS インフラストラクチャ
AWS を使用して移行のための環境をテストまたは設定する必要がある場合は、次の推奨事項を検討してください。これにより、100 万件以上の課題に対応できます。
AWS タイプ | システム メモリ | CPU コア |
|---|---|---|
db.m5.2xlarge | 32 GB | 8 コア |
ec2.c6i.4xlarge | 32 GB | 16 コア |
CPU とプロジェクトの並列処理
CPU の数によって、並行して移行できるプロジェクトの数が決まります。そのため、少なくとも 16 個の CPU を使用することをお勧めします。CPU をさらに追加すると、プロジェクトや課題を移行するために動的に割り当て、最高のパフォーマンスを実現します。
場合によっては、ユーザーがテスト移行に割り当てる CPU が本番環境よりも少ないことがあります。移行時間だけを測定したい場合は、CPU の数が少なければ、テスト移行は後で行われる実際の移行よりも時間がかかることに注意してください。
CPU の割り当て方法
以下の表では、すべての CPU コアを利用してデータを並列処理することでスピードアップするアプローチを示しています。計画内のプロジェクト数によって数値が異なる場合がありますが、スレッド数が利用可能な CPU コアを超えないようにします (最初のシナリオを除く)。
CPU コア | 並行してエクスポートされるプロジェクト | 並行してエクスポートされる課題 (プロジェクトごと) | 並列スレッドの合計数 | 推奨される課題の数 | 最小 JVM ヒープ サイズ | 最小システム メモリ |
|---|---|---|---|---|---|---|
2 | 2 | 2 | 4 | < 10,000 | 8 GB | 8 GB |
4 | 2 | 2 | 4 | 15,000 | 8 GB | > 8 GB |
8 | 4 | 2 | 8 | 60,000 | 8 GB | > 16 GB |
16 | 8 | 2 | 16 | 2,000,000 | 16 GB | > 32 GB |
32 | 8 | 4 | 32 | 10,000,000 | 16 GB | > 32 GB |
ネットワークの推奨事項
We don’t have strict requirements for bandwidth, but we’ve observed that 250 Mbps improves the data upload, attachment upload, and communication between Data Center and Cloud, resulting in overall faster migration.
移行アシスタントのアップデート
移行速度の改善は継続的にリリースされるため、アシスタントを確実にアップデートすることが重要です。たとえば、バージョン 1.10.17 では、データ スループットを大幅に向上させる改善をリリースしました。以前のバージョンで移行した場合、これらの変更は使用できませんでした。
When updating the assistant, make sure that the new version is compatible with your current versions of Jira, database, and any Marketplace apps you’re using.
サーバー上の必須でないタスクを無効にする
移行を実行するときは、追加リソースを消費する可能性がある次のようなタスクとアクティビティをすべて無効にしてください。
アンチウイルス スキャン
Jira のバックアップ作成 (XML)
インデックスの完全再作成
Automation or Marketplace apps that might be updating issues in bulk
その他の必須でないタスク
可能な限り、移行にのみリソースを利用できるようにしてください。
トラフィックが少ない時間帯や営業時間外に移行を実行する
サーバーとネットワークのトラフィックを減らすために、移行のスケジュールを営業時間外に設定し、実行してください。これにより、IT チームは移行のみに集中でき、問題が発生したときにも対応できます。
移行計画の作成と実行のベスト プラクティス
次のベスト プラクティスによって、移行が大幅にスピードアップすることが確認されています。
複数の移行計画を同時に実行しないでください。
移行計画内のプロジェクトは並行して移行されます。移行を迅速に行うには、課題数が類似している複数のプロジェクトを 1 つの計画に含めることをお勧めします。通常、合計移行時間は最大のプロジェクトの移行にかかる時間と等しくなります。
移行前の任意の時期
ソース環境とターゲット環境を準備する
移行アシスタントが開始されたら、最初のステップは事前チェックです。これらのチェックの多くは、ソース環境とターゲット環境に関連しています。たとえば、メール アドレスが無効なユーザーと重複しているユーザー、Cloud に適切な製品がインストールされているかどうかを確認します。事前チェックに失敗した場合は、関連する課題を修正するまで移行を続行できません。移行日にチェックがスムーズに行われるように、次の点をご確認ください。
冗長なサイトやプロジェクトをアーカイブしましたか?
無効なユーザーまたは重複しているユーザーをクリーンアップまたは修正しましたか?
Have you installed all required Atlassian cloud apps on the destination site?
正しい権限を設定しましたか?
Cloud サイトには適切な数のライセンスがありますか?
宛先サイトで専用の RDS を有効にしていますか?
移行前にインスタンスをクリーンアップする方法をご確認ください。
移行の 1 〜 2 日前
ネットワークを準備する
インターネット接続の速度と質は、移行のスピードを左右する大きな要因です。ネットワークが最適な状態であることを確認するには、以下をご確認ください。
ネットワーク接続が安定していることを確認しましたか?
移行期間中にパッチがリリースされないことを確認しましたか?
移行期間中に自動バックアップ サービスや Jira のインデックス作成タスクが予定されていないことを確認しましたか?
Jira Cloud Migration Assistant を許可リストに登録済みですか?
添付ファイルを事前に移行する
添付ファイルは、移行におけるデータ サイズ全体の大部分を占めます。移行中のデータ サイズを減らすには、移行前の任意の時点で添付ファイルを事前に読み込んでおくことをおすすめします。これにより、移行中は差分 (編集または追加された添付ファイル) のみが移行されます。これには次のような複数の利点があります。
移行にかかる時間を数時間短縮できます。
移行前の都合の良いときにいつでも実行できます。
ダウンタイムは発生しません。
移行計画を作成して、[添付ファイルのみ] を選択するだけです。
Jira の添付ファイルを事前に移行する方法についてご確認ください。
ユーザーを事前に移行する
ユーザーを事前に移行しておくと、プロジェクト データの移行にかかる時間を節約できます。最終的にはユーザーとグループを再度移行する必要がありますが、すでに移行したユーザーはスキップして、(もしあれば) 新しいユーザーを移行するだけです。これにより、ずっと高速になります。
手順の要約は次のとおりです。
本番環境の移行の前に、新しい移行計画を作成します (ユーザー ベースが大規模な場合は、1 日前が望ましい)。
プロジェクトをスキップして、ユーザーを除くすべてのオプションで [なし] または [スキップ] を選択します。
[すべてのユーザーとグループ] を選択します。
ユーザー移行のアプローチに応じて、ユーザーとグループを個別に移行するか、グループ メンバーシップを保持するかを選択します。通常、移行する顧客はグループ メンバーシップを保持することを選択します。
移行計画を実行します。
次に、後ろの段階で本番環境の移行を実行すると、ユーザーの差分のみが移行されます。注: 移行アシスタントではすべてのユーザーが移行中であると表示されますが、実際には差分のみなので、はるかに時間がかかりません。
Jira のユーザーとグループを事前に移行する方法をご確認ください。
移行前チェックを事前実行する
移行前チェックは Jira Cloud Migration Assistant が実行するチェックで、両方の環境で移行の準備ができていることを確認します。これらのチェックは数時間に及ぶことがあり、一刻を争う状況では、全体的な移行時間を数時間短縮することで違いが出る可能性があります。
移行前チェックを実行する間の時間を節約する
時間のかかる移行前チェックが再度実行されるのを防ぐには、Jira Cloud Migration Assistant を最新バージョンにアップグレードしてください。最新バージョンでは、効率を向上させるために成功した移行前チェックの結果が保存されます。 これらの結果は、将来のチェックをスピードアップするために使用され、時間を節約します。
注意:
移行日の少なくとも数日前に移行前チェックを実行することをお勧めします。 これによって、次が保証されます。
データに加えられたすべての変更が検証され、キャッシュに保存されます
the duration of running the pre-migration check is minimized, saving time on the migration day
キャッシュされた結果は 30 日間のみ保存されます。その後は自動的に削除され、すべてのチェックが再度実行されます。
移行のそれぞれで移行前チェックにかかる時間を見積もることは困難です。事前チェックが長時間にわたる場合は、アトラシアン サポートに確認することをお勧めします。例:
小規模インスタンス: 2 時間超え
中規模インスタンス: 4 時間超え
大規模インスタンス: 6 時間超え (この場合、通常はプレフライトが完了するまでに時間がかかります)
Jira Cloud Migration Assistant を使用して
「選択済み」ユーザーの代わりに「すべて」のユーザーを移行する
多くの場合、ユーザーは、すべてのユーザーではなく、移行するプロジェクトに接続しているユーザーのみを移行するオプションを選択しがちです。これは、ユーザー ベースをクリーンアップして、非アクティブなユーザーや重複しているユーザーを Cloud に取り込まないようにする簡単な方法だと考えられています。
ただし、移行速度を重視する場合は、すべてのユーザーを移行する方が、一部のユーザーを移行するよりもはるかに時間がかかりません。通常、選択したユーザーの数はすべてのユーザーよりもかなり少ないため、不可解だと感じられるかと思います。
しかし、選択したユーザーを移行する場合は、ユーザー データベース全体で毎回 Jira Cloud Migration Assistant が実行されて、このユーザーが移行されたプロジェクトのいずれかに接続しているかどうかを確認する必要があります。このプロセスには、単にすべてのユーザーを移行するよりもはるかに長い時間がかかります。
この内容はお役に立ちましたか?