Cloud 移行を計画する
Atlassian Server または Data Center 製品の移行準備に役立つドキュメント。
Jira Cloud Migration Assistant の移行前チェックリスト
Jira Cloud Migration Assistant は、データに一般的なエラーがないかどうかを自動的に確認します。次の点が確認されます。
すべてのユーザーに有効で一意のメール アドレスが紐付けられているかどうか
プロジェクト名またはキーが Cloud にすでに存在するプロジェクト名またはキーと競合していないこと
移行アシスタントが最新かどうか
ただし、すべてが確認されるわけではないため、移行の開始前に、この移行前チェックリストを一通り確認する必要があります。
はじめる前に
移行前のチェックを完了するには、次のようなアクセス権が必要になる場合があります。
Jira Server/Data Center または Cloud ユーザー インターフェイスへのアクセス
解凍された Jira サポート ZIP にアクセスする。サポート ZIP ファイルの作成方法をご確認ください
解凍された Jira XML バックアップにアクセスする。XML バックアップの作成方法をご確認ください
SQL クエリをソース インスタンスで実行する方法
1. ユーザーの移行計画を作成する (必須)
外部ディレクトリ
アクティブな外部ユーザー ベースを同期して、ユーザー戦略の一環としてすべてのユーザーやグループが適切に移行されていることを確認します。また、これによって、移行中にデータが適切なユーザーに引き続きリンクされるようにします。ユーザー移行戦略について詳細をご確認ください
外部 ID プロバイダーを使用してユーザーを管理している場合は、移行前にそれらのユーザーがアクティブで Jira と同期されていることをご確認ください。
Jira Server ユーザー インターフェイスによって同期する
右上隅の歯車アイコンを選択します。
[ユーザー管理] を選択します。
[ユーザー ディレクトリ] を選択します。
[同期] を選択します。
サポート Zip を使用した検証
Epoch タイムスタンプは https://www.epochconverter.com/ などのサイトで照合できます。
必要なディレクトリがアクティブに設定されていることを確認します。
前回の外部ユーザー同期の検証
1
2
3
4
5
6
7
grep "com.atlassian.crowd.directory.sync.laststartsynctime" <Support Zip Location>/auth-cfg/directoryConfigurationSummary.txt
Example Output:
com.atlassian.crowd.directory.sync.laststartsynctime: 1586922783853
com.atlassian.crowd.directory.sync.laststartsynctime: 1586911983804
com.atlassian.crowd.directory.sync.laststartsynctime: 1579025414214アクティブな外部ディレクトリの検証
1
2
3
4
5
6
7
8
9
grep "Active:" <Support Zip Location>/auth-cfg/directoryConfigurationSummary.txt
Example Output:
Active: true
Active: true
Active: true
Active: false
Active: trueJira Cloud Migration Assistant は次を移行します。
すべてのユーザーまたはグループ
選択したプロジェクトに関連するユーザーとグループ
2. Jira Server のバージョンを確認する (必須)
Jira がサポート対象バージョンで実行されていることをご確認ください。サポート対象外のバージョンである場合、Migration Assistant は機能しません。サポート対象バージョンの詳細をご確認ください。
Jira Server ユーザー インターフェイスによって検証する
右上隅の歯車アイコンを選択します。
[システム] を選択します。
左側ナビゲーション パネルの [システム情報] を選択します。
Jira バージョンを探します。
サポート Zip 製品バージョン検証によって検証する
1
2
3
4
5
grep "<product name" <Support Zip Location>/application-properties/application.xml
Example Output:
<product name="Jira" version="8.7.1"/>3. 無効なメール アドレスや重複したメール アドレスを修正する (必須)
無効なメール アドレスや重複したメール アドレスは Jira Cloud でサポートされていないため、Jira Cloud Migration Assistant で移行できません。移行がブロックされないようにするには、アシスタントを使用してそのようなメールアドレスを特定し、手動で修正します。または、重複したメール アドレスのマージや関連ユーザーの無効化といった推奨オプションのいずれかを適用して、移行時に自動的に修正します。
Jira Cloud Migration Assistant を開きます。
[Assess and prepare users (ユーザーの評価と準備)] カードで、[Begin assessing (評価を開始)] を選択します。空の結果のページに移動します。
評価を開始するには、[Begin assessing (評価を開始)] を選択します。評価が完了すると、要件を満たしていないメール アドレスの数が表示されます。詳細を表示して、これらのメール アドレスの修正方法を選択できます。
4. 適切な権限を持っていることを確認する (必須)
移行を実行するユーザーが、次の権限を持っていることを確認します。
サーバー インスタンスのシステム管理者権限を持っている
宛先のクラウド サイトに存在すること
Jira Cloud の組織の管理者ロールを持っている
サーバーの <Jira ホーム ディレクトリ /export ディレクトリに対して必要なディスク アクセス権限を持っている。このディレクトリは、移行プロセス中に一時ファイルを作成するために使用されます。
5. グループ名の競合を確認する (必須)
Cloud サイトのグループ名が Server サイトのいずれのグループとも異なることをご確認ください (意図的にマージしようとしている場合を除く)。Migration Assistant がグループ名の競合を管理する方法をご確認ください
一部の移行シナリオでは、Server サイトにアドオン ユーザーが発生する場合があります。Server の世界においてアドオン ユーザーは一般的ではないため、クラウドに戻す移行の際にいくつかの問題が発生する可能性があります。移行前に、これらのアドオン ユーザーを削除または更新します。
SQL を使用した検証 (Postgres でテスト済み)
次のクエリでこれらのユーザーを見つけて削除するか、メール アドレスを @connect.atlassian.com 以外のものに更新します。
1
2
--ADD-ON USERS - TESTED ON POSTGRESQL
select * from cwd_user where lower_email_address like '%connect.atlassian.com%';6. ファイアウォールの許可ルールを更新する (必須)
移行アシスタントは移行を実行するためにアトラシアンのドメインに接続します。ファイアウォールまたはリバース プロキシによってドメインがブロックされると、移行は失敗します。移行の実行前に、Atlassian Cloud 製品の IP アドレスとドメインがセキュリティ ルールによってブロックされていないことを確認します。
Cloud 製品によって使用される IP アドレスとドメインについて詳細をご確認ください
7. アプリの移行方法を決定する (必須)
Jira Cloud Migration Assistant によってアプリ データを移行できます。移行するアプリの Marketplace パートナー (アプリ ベンダー) に連絡して、構築した移行パスが Jira Cloud Migration Assistant をサポートしているかどうかを確認したうえで、データの効率的な移行方法についてアドバイスを求めましょう。
8. パブリック アクセス設定を確認する (必須)
Jira Server または Jira Cloud サイトをインターネットに公開するように構成できます。コンテンツを意図的に公開する場合を除いて、プロジェクト権限を確認する必要があります。Jira Server に公開しているプロジェクトがある場合は、Cloud に移行する前にそれらの匿名アクセスのセットアップを削除します。移行後、これらのプロジェクトはいつでも公開できます。
SQL を使用した検証 (Postgres でテスト済み)
プロジェクト
これによっていずれかの権限が [すべてのユーザー] に設定されているプロジェクトにフラグが付けられます。
1
2
3
4
5
6
7
8
9
10
11
SELECT p.id, p.pname, ps.name, sp.permission_key FROM project p
INNER JOIN nodeassociation na ON
p.id = na.source_node_id
INNER JOIN schemepermissions sp ON
na.sink_node_id = sp.scheme
INNER JOIN permissionscheme ps ON
na.sink_node_id = ps.id
WHERE na.source_node_entity = 'Project'
AND na.sink_node_entity = 'PermissionScheme'
AND sp.perm_type='group'
AND sp.perm_parameter is null;フィルター
"全員で共有" 共有タイプ (グローバル) のフィルターの一覧を取得します。
1
2
3
4
5
// get list of filters which has share type as "share with everyone" (i.e. global)
SELECT sr.filtername, sp.sharetype AS current_share_state, sr.username AS owner_name, sr.reqcontent AS JQL
FROM searchrequest sr
INNER JOIN sharepermissions sp ON sp.entityid = sr.id
WHERE sp.sharetype='global' and sp.entitytype ='SearchRequest';アジャイルボード
"全員で共有" 共有タイプ (グローバルなど) のアジャイル ボードのリストを取得します。
1
2
3
4
5
6
// get list of Agile boards which has share type as "share with everyone" (i.e. global)
SELECT DISTINCT "rv"."NAME" as "Board Name", sr.filtername, sp.sharetype AS current_share_state, sr.username AS owner_name
FROM "AO_60DB71_RAPIDVIEW" as rv
INNER JOIN searchrequest sr ON sr.id = rv."SAVED_FILTER_ID"
INNER JOIN sharepermissions sp ON sp.entityid = sr.id
WHERE sp.sharetype='global' and sp.entitytype ='SearchRequest'; ダッシュボード
"全員で共有" 共有タイプ (グローバル) のダッシュボードの一覧を取得します。
1
2
3
4
5
6
// get list of Dashboard which has share type as "share with everyone" (i.e. global)
SELECT DISTINCT pp.id as Dashboard_Id, pp.pagename AS Dashboard_name, sp.sharetype AS current_share_state, pp.username AS owner_name
FROM portalpage pp
INNER JOIN sharepermissions sp ON sp.entityid = pp.id
WHERE sp.sharetype='global' and sp.entitytype ='PortalPage'
ORDER BY pp.id;9. Server のセットアップを確認する (必須)
アプリケーション メモリ (JVM ヒープ サイズ)
移行する課題またはプロジェクトの数によっては、移行全体をクラッシュさせる可能性がある OutOfMemory エラーが Jira Server で発生する場合があります。これを防ぐためには、アプリケーションが 4GB 以上のヒープ割り当てで実行されていることを確認します。Jira のアプリケーション メモリを増やす方法についてご確認ください
一般的なインスタンス データセットのサイズとリソース (CPU コア、RAM、ヒープ) に基づくベンチマーク
次の表は、インスタンスのサイズ プロファイルの定義を示しています。
特大 | 32 CPU、64 GB RAM、31 GB ヒープ |
|---|---|
大 | 16 CPU、32 GB RAM、16 GB ヒープ |
中 | 8 CPU、16 GB RAM、8 GB ヒープ |
小 | 4 CPU、8 GB RAM、4 GB ヒープ |
大と特大は、データセットのサイズとそれに対応するインスタンス プロファイルの最大値/最小値への近さに基づいて選択できます。
「AWS でのエンタープライズ Jira インスタンスの推奨インフラストラクチャ」もご覧ください。
開いているファイル数の上限
また、オープンなファイルの制限を確認します。32768 になるべく近い数が理想的です。システムに設定されるオープンなファイルの数は、Linux ディストリビューションに応じて異なる場合があります。これをシステム コマンド経由で確認する方法が不明な場合は、サポート Zip を作成し、application-properties/application.xml ファイルを開いて、<max-file-descriptor> を検索します。必要に応じて値を調整します。これは、Windows を実行している場合には適用されません。
「Too many open files」エラーの詳細をご確認ください。
サポート Zip を使用した検証
アプリケーション メモリ (JVM ヒープ サイズ)
Xmx および Xms の値が 4096m または 4g 以上であることを確認します。
1
2
3
4
5
grep -i "xmx"" <Support Zip Location>/application-properties/application.xml
Example Output:
<JVM-Input-Arguments>-Djava.awt.headless=true -Datlassian.standalone=JIRA -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Xms4g -Xmx4g 開いているファイル数の上限
<max-file-descriptor> の値が 32768 に近いことを確認します。
1
2
3
4
5
grep -i "<max-file-descriptor>"" <Support Zip Location>/application-properties/application.xml
Example Output:
<max-file-descriptor>32,000</max-file-descriptor>ヒープ サイズを検証する別の方法
Linux
/jira-installation-directory/bin/setenv.sh ファイルに移動し、次の両方のパラメーターが 4096m または 4g (メガバイトではなくギガバイトで設定されている場合) を上回っていることを確認します。
1
2
JVM_MINIMUM_MEMORY="4096m"
JVM_MAXIMUM_MEMORY="4096m"Windows - サービスとして実行していない
/jira-installation-directory/bin/setenv.bat ファイルに移動し、次の両方のパラメーターが 4096m または 4g (メガバイトではなくギガバイトで設定されている場合) を上回っていることを確認します。
1
2
JVM_MINIMUM_MEMORY="4096m"
JVM_MAXIMUM_MEMORY="4096m"Windows - サービスとして実行
Jira のアプリケーション メモリを増やす方法についてご確認ください
データベース接続プール
Jira は Apache Commons DBCP に基づく DBCP (データベース接続プール) によって、基盤となるデータベースへの Jira のアクセスを管理します。Jira がデータベースにアクセスする (読み込みまたは書き込みを行う) 必要がある際は、データベース接続が必要になります。
通常の使用では、Jira のデータベース接続プールは正常に動作する可能性があります。しかし、Jira Cloud Migration Assistant を追加すると、データベース接続プールのサイズが適切でない場合にプールが枯渇する可能性があります。
その場合、Jira のパフォーマンスに大きな影響が及び、移行アシスタントだけでなく、アプリ全体に影響します。通常の回避策は、データベース接続プールのサイズを増やすことです。
修正
既定では、Jira の DB 接続プールの最大サイズは 20 です。一般的な解決策は、その数を 10 ずつ増やして、Jira と Migration Assistant の両方に対応するように接続プールを微調整することです。DB 接続プールの最大サイズを 40 まで増やせば、移行のニーズに十分に対応できるはずです。
DB 接続プールを操作してサイズを大きくするには、以下の参照リンクをご覧ください。
10. Advanced Roadmaps の共有チームを確認する（推奨）
Jira Cloud に移行するカスタマーには、メンバーシップが必要なアトラシアン チームに変換される共有チームがあります。アトラシアン チームの詳細をご確認ください。
移行時に、メンバーがいないチームには既定メンバーが割り当てられます。このメンバーは、組織管理者権限とチーム管理アクセス権のいずれか、または両方を持つユーザーです。
チームへの予期しない変更を避けるため、移行前に共有チームを確認することをおすすめします。
SQL を使用してメンバーがいないチームを見つける (Postgres でテスト済み)
こうすることで、メンバーがいない共有チームが見つかります。
1
2
3
4
5
6
7
8
9
10
select "TITLE"
from "AO_82B313_TEAM"
where "ID" not in (
select distinct "TEAM_ID"
from "AO_82B313_RESOURCE" r
inner join "AO_82B313_PERSON" p on r."PERSON_ID" = p."ID"
inner join app_user on p."JIRA_USER_ID" = app_user."user_key"
inner join cwd_user cu on app_user."lower_user_name" = cu."lower_user_name"
where active = 1)
and "SHAREABLE" = true;その後、<Jira base url>/secure/TeamManagement.jspa のチーム管理ページを使用して個々のチームを見つけ、必要に応じてメンバーシップを調整できます。
11. Advanced Roadmaps プランにリンクされているすべてのプロジェクトを特定する [推奨]
プロジェクトを選択する前に、Advanced Roadmaps プランにリンクされているすべてのプロジェクトを特定できます。次の API リクエストを使用します。
API リクエスト
GET:/rest/migration/latest/advanced-roadmaps/all-plan-projects-map
curl を使用した API 呼び出しの例
1
curl -u {username}:{password} https://{your-server-base-url}/rest/migration/latest/advanced-roadmaps/all-plan-projects-mapレスポンスの例
API を呼び出すと、JSON レスポンスが次の形式で生成されます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
[
{
"planId": 1,
"projectKeys": [
"ABSHI",
"ABNFI",
"AAUDXA"
]
},
{
"planId": 2,
"projectKeys": [
"AKERIA",
"ALTRAA",
"ACAPI",
"ACPMI",
"ACICRA"
]
},
{
"planId": 4,
"projectKeys": [
"AKERIA",
"ALTRAA",
"AMNUA",
"ASAE",
"AMTEE"
]
},
{
"planId": 5,
"projectKeys": [
"ASILA",
"ASOTIA",
"ASRESA"
]
},
{
"planId": 6,
"projectKeys": [
"ASSTS",
"ANNUS",
"ANIKEA"
]
},
{
"planId": 7,
"projectKeys": [
"ASACSA",
"BADOI",
"AVERS"
]
},
{
"planId": 8,
"projectKeys": [
"BBVISA"
]
}
]この JSON レスポンスには、Advanced Roadmaps プランの ID 、およびインスタンス内の各プランに関連付けられているプロジェクト キーが含まれています。関連付けは課題ソースに由来するものであり、プロジェクト、ボード、またはフィルターにリンクできます。
12. 共有されている設定名の重複を修正する (推奨)
移行の競合を防ぐために、Cloud サイトの共有設定と同名の Server インスタンスの共有設定 (ワークフローまたは権限スキーム) の名前を変更します。競合が見つかった場合は、移行中に設定の名前が変更されることがあります。Migration Assistant がデータをリンクする方法をご確認ください
13. Server または DC の空きディスク容量を考慮する [推奨]
移行に十分なディスク容量がサーバーまたは DC にあることを確認してください。必要な容量は、Jira インスタンスのサイズと移行の仕様によって異なります。移行中に作成される一時ファイル用の追加ストレージを考慮に入れてください。
詳細は、以下のドキュメントを参照してください。
14. Cloud 上のストレージ上限を超えないことを確認する [推奨]
アトラシアンの Cloud プランには個別のストレージ制限があります。移行前に、現在使用しているディスク スペースと Cloud 内のストレージと制限に関する情報を確認してください。Cloud ストレージについて詳細をご確認ください
15. Server インスタンスを準備する [推奨]
Server データが正常に移行されるように、データベース整合性チェッカー (Jira Server のネイティブ機能) と Atlassian Marketplace の Integrity Check for Jira アプリによって、データのステータスを確認します。
他のチェックおよび実行すべきアクションは次のとおりです。
すべての必須フィールドに値があって null ではない
移行した非アクティブなユーザー ディレクトリを再有効化していること
サーバー インスタンスのクリーンアップについて詳細をご確認ください
カスタム フィールドの説明に埋め込まれた HTML または JavaScript コードを修正する
Jira Cloud 製品では、HTML や JavaScript コードをカスタム フィールドの説明に埋め込むことは許可されていません。こうしたコードは、Cross-site Scripting (XSS) などのセキュリティ脆弱性の攻撃ベクトルになる可能性があるためです。移行する前に、Jira Server でこうしたフィールドを調整または削除する必要があります。Jira Server の該当するカスタム フィールドは、ドキュメント「説明にカスタム JavaScript が含まれるフィールドを識別する方法」に記載されているクエリを使用して特定できます。
16. Cloud サイトを準備する [推奨]
クラウド サイトのセットアップ時には次の点を考慮します。
各製品への製品アクセスを持つグループが存在する場合、Cloud サイトでは Server サイトと同じ Jira 製品が有効化されている必要があります。これは、すべてのユーザーとグループを正常に移行するためです。
Cloud サイトの言語が、Server サイトの言語と同じであることを確認します。言語が異なる場合は、一部のフィールドが適切に移行されない場合があります。
Atlassian Guard Standard を使用している場合は、移行前にそれをセットアップし、ユーザーを最適に移行する方法について詳細を確認する必要があります。ユーザー移行戦略の詳細をご確認ください。
17. 移行に向けて Jira Align を準備する [オプション]
Jira Align を使用する場合は、移行前、移行中、移行後に追加の手順を完了する必要があります。その中には、Jira Align サポート チームとの協力が必要な作業もありますので、移行タイムラインについてお知らせいただく必要もあります。
18. データをバックアップする [推奨]
移行を実行する前に、現在の Jira Server サイトをバックアップすることをお勧めします。移行先の Cloud サイトに既存のデータがある場合は、同様に Jira Cloud サイトもバックアップします。
19. テスト移行を実行する [推奨]
テスト移行を実行してから本番環境に移行することを強くお勧めします。
20. 移行プランをサポートに通知する [推奨]
週末や祝日に移行する、または Cloud 上のユーザーが 1,000 人を超える場合は、1 ～ 2 か月前に移行サポート チームにお問い合わせすることをお勧めします。アトラシアンで人員を確保したうえで、移行をサポートします。
21. ネットワークの帯域幅を確認する
本番環境への移行の直前に、サーバーでネットワーク テストを実行して、ネットワークが正常であることを確認することをお勧めします (ダウンロード、アップロード、転送帯域幅)。
速度テストを実行するために推奨される CLI ツール: Speedtest CLI: コマンド ラインのインターネット速度テスト
本番環境に追加のセキュリティ制御がないことを確認してください (例: Egress トラフィック スキャナー)。Atlassian Cloud 環境へのデータ アップロードが遅くなる可能性があります。
詳細情報とサポート
移行をサポートする多数のチャンネルをご用意しています。
移行計画に関する情報は、Atlassian Migration Program の Web サイトをご覧ください。
技術的な問題が発生している、または戦略やベスト プラクティスに関するサポートが必要な場合は、サポート チームにお問い合わせください。
ピア アドバイスについては、アトラシアン コミュニティでご質問ください。
専門家によるガイダンスについては、アトラシアン パートナーでご相談ください。
追加のサポートが必要な場合は「Cloud 移行ガイド」をご確認、またはライブ チャットによる Q&A を含む Cloud 移行デモにご登録ください。
この内容はお役に立ちましたか?
さらにヘルプが必要ですか?
アトラシアン コミュニティをご利用ください。