Data Center アップグレード ガイド
組織はそれぞれ異なり、組織ごとに移行ジャーニーも異なります。ステップ バイ ステップのアップグレード ガイドに従って、Atlassian Server から Data Center へのスムーズなトランジションを確実に行ってください。
評価
組織にはそれぞれ独自のニーズと要件があるため、適切なアップグレードを計画できるように選択肢を理解することが重要です。
アーキテクチャとインフラストラクチャの要件を理解する
Data Center に決めましたか? サポートされている Data Center アーキテクチャとデプロイ構成について、ご確認ください。
Data Center は、2 つの異なる方法、非クラスタまたはクラスタでデプロイできます。どちらの方法でもエンタープライズ機能をご利用いただけますが、検討すべき事項が異なります。下表は、非クラスタ アーキテクチャとクラスタ アーキテクチャの違いを示しています。
非クラスタ 推奨
インフラストラクチャ要件
非クラスタ アーキテクチャでは、既存のインフラストラクチャで Data Center にアップグレードできるため、インフラストラクチャの変更は不要です。
推奨ユース ケース
非クラスタ化アップグレード・パスを利用して Data Center にアップグレードしていただくことを、すべてのお客様にお勧めします。Data Center で稼働したら、お客様は必要に応じてクラスタ化アーキテクチャを実装できます。
利点
クラスタリングに依存しないエンタープライズ機能を最大限に活用します。
通常、Data Center への移行を開始するお客様は、まず、非クラスター アップグレードに着手します。移行をスムーズに進めるために、この 2 分でアップグレードを利用することをお勧めします。
クラスタ化
非クラスタ化アップグレード・パスを利用して、最初に Data Center にアップグレードしていただくことを、すべてのお客様にお勧めします。Data Center を正常にアップグレードしたら、お客様は必要に応じてクラスタ化アーキテクチャを実装できます。
インフラストラクチャ要件
クラスタで Data Center にアップグレードするには、以下のコンポーネントが必要です。
- ロードバランサー
- アプリケーション ノード
- すべてのアプリケーション ノードからアクセス可能なファイル システム
- ElasticSearch ノード (Bitbucket)
推奨ユース ケース
- 高可用性が必要
- ダウンタイムなしでアップグレードする
- 短期間に XL 規模 に拡張する予定がある
利点
クラスタリングが提供できるエンタープライズ機能を活用します。
- Enterprise フィーチャーと機能
- 高可用性とフェイルオーバー – アプリケーション クラスタのいずれかのノードがダウンした場合は、他のノードが負荷を引き受けるため、ユーザーは中断されることなく製品にアクセスできます。
- 即時に拡張可能: ダウンタイムや追加のライセンス料金なしでクラスタに新しいノードを追加できます。インデックスとアプリは自動的に同期されます。
- ディザスタ リカバリ: オフサイトでのディザスタ リカバリ システムをデプロイして、完全なシステム停止の場合にもビジネス継続性を実現します。共有製品インデックスにより、素早く元の状態に戻って製品を実行することができます。
計画と準備
Data Center パスを選択できたので、詳細なアップグレード計画の作成を開始できます。
タイムラインを構築する 必須
以下に示すのは、アップグレードの所要時間の推定に使用できる基本タイムラインです。
| | 非クラスタ | クラスタ化 |
|---|---|---|
| 計画 | 非クラスタ 0 – 2 週間 | クラスタ化 1 か月 + |
| 予行演習 | 非クラスタ 0 – 1 週間 | クラスタ化 3 – 6 か月間 |
| 稼働開始 | 非クラスタ 0 – 1 週間 | クラスタ化 ～ 6 – 9 か月間 |
含まれるタイムラインは、Data Center に正常にアップグレードした弊社の多数のお客様の事例をもとにしていますが、実際のタイムラインは、お客様の環境に固有の要因 (規模、複雑性、準備状況など) に応じて異なります。
Data Center 環境を定義する 必須
アプリケーション レイヤー
インスタンスと場所
- インスタンスをフェデレーションまたは統合しますか?
- あなたの将来の成長はどのようなものですか?
- データの分離が必要ですか?
- ステージング環境や本番環境など、チームにはいくつの環境がありますか?
インスタンス プロファイル
- インスタンスにアクセスする人は何人いますか?
- あなたのチームはどこにいますか?
- 現在、インスタンスにはどのくらいのデータがあり、インスタンスに追加する予定のデータはどれくらいありますか?
アプリ、統合、カスタマイズ
それらはすべて必要ですか? それとも、これを機に簡素化しますか?
インフラストラクチャ レイヤー
インスタンスのサイズ
- 将来の成長予測はどのようなものですか?
- ユーザー トラフィックのレベルが低いことはありますか?
詳細については、ノード サイジングの概要を以下に示します。
アカウント構造
- 環境をデプロイする必要があるのはどのアカウントですか?
- 環境ごとに異なるアカウントを関連付けますか?
- Data Center 製品で、他の CI/CD またはコラボレーション ツールと同じアカウントを使用しますか?
ガバナンス モデル
- ガバナンス モデルはどのようなものですか?
- 最低限のシステム標準はどのようなものをお考えですか?
- 中央ログを使用していますか?
- ユーザー管理ニーズはどのようなものですか?
ガバナンス モデルの一部として、AWS ランディングゾーンと AWS System Manager を使用することをご検討ください。
VPC
-
新しい VPC (仮想プライベート クラウド) を使用しますか?
新しい VPC にデプロイする場合でも、既存の VPC を使用する場合でも、ASI (Atlassian Standard Infrastructure) テンプレートを活用できます。
- オフィスや VPN ネットワーク ルーティングのパブリック インターネット アクセスや内部 IP アドレス指定の制限など、変更するネットワークの原則はありますか?
- TLS 証明書を使用する必要がありますか?
地域
-
既存の VPC を使用している場合は、オフィスと VPN ネットワーク アクセスの計画を立てましたか?
製品の使用量は時間の経過とともに増加する可能性が高いため、すべてのオフィスと VPN からのアクセスを許可することをお勧めします。
Direct Connect
- Direct Connect を使用してパフォーマンスとセキュリティを強化しますか?
- サーバー インスタンスから Data Center に移行するために必要なデータの量はどれくらいですか?
AWS Snow ファミリーは、大量のデータを移行する場合にお勧めのリソースです。
事業継続とディザスタリカバリ
バックアップ
バックアップ戦略はどのようなものですか?
既存のバックアップ戦略と AWS に組み込まれたバックアップ機能の両方を組み合わせて使用することをお勧めします。詳細については次をご参照ください。
AWS は、特異な停止が発生しにくいインフラストラクチャ サービスを提供します。
リージョンのフェイルオーバー
コールド、ウォーム、またはホットの各サイトを複数のリージョンに実装する必要がありますか?
通常、ディザスタ リカバリのニーズは、複数のアベイラビリティ ゾーンでサービスを実行することで満たされますが、リージョンの停止を軽減することもお勧めします。これらのサイトを複数のリージョンに実装するかどうかを決定する際には、次の点を考慮してください。
- インフラストラクチャとデータ転送のコスト
- AWS と復旧速度の比較
- リカバリ サイトのメンテナンスとテストの所要時間
- サイトの運営コスト
Data Center (非クラスタ) にアップグレード 推奨
非クラスタ化アーキテクチャを利用して Data Center にアップグレードしていただくことを、すべてのお客様にお勧めします。非クラスタ化アップグレードは、より迅速でシンプルなアップグレード・オプションで、Data Center のセキュリティ、サポート、エンタープライズ機能にすばやくアクセスできます。
Data Center (クラスタ化) にアップグレード 非推奨
アップグレードは複雑なため、最初にクラスタ化アーキテクチャで Data Center にアップグレードすることはお勧めしません。非クラスタ化アップグレード・パスを利用して、まずは Data Center にアップグレードしていただくことを、すべてのお客様にお勧めします。その後、クラスタ化アーキテクチャを必要とするお客様は実装を開始できます。
非クラスタ化アーキテクチャで Data Center にアップグレードした後、高可用性が必要な場合にはクラスタ化アーキテクチャを実装できます。
クラスタに必要なインフラストラクチャを確保する
クラスタでの Data Center のデプロイには、以下のコンポーネントが有用です。
- データベース
- ロードバランサー
- アプリケーション ノード
- 共有ファイル システム
- ElasticSearch ノード (Bitbucket)
ロードバランサー
ロード バランサーは、クラスタでデプロイする場合にユーザーの要求が最初に到達する部分です。要求がロード バランサーに到達すると、ロード バランサーは各要求をアプリケーション ノードに分散します。ハードウェアまたはソフトウェア ベースのロード バランサーを使用できます。ソフトウェアとハードウェアのどちらのソリューションでも、高速 LAN 接続を使用してロード バランサーをアプリケーション クラスタに接続し、広帯域幅と低レイテンシを確保する必要があります。すべてのソフトウェア ロード バランサーは専用のマシンで実行する必要があります。
Data Center 製品は、セッションの間、各ユーザーのリクエストが同じノードに送信されると想定しています。リクエストが別のノードに送信されると、ユーザーが予期せずログアウトしたり、セッション内で保存された情報が失われたりすることがあります。そのため、ロード バランサーでは Cookie ベースの 「スティッキー セッション」 (セッション アフィニティ) を有効にして、セッションを同一ノードにバインドする必要があります。Cookie ベースのスティッキー セッションを使用すると、製品で発行された Cookie を使用したり、ロード バランサーで生成された Cookie を使用したりすることができます。
ロード バランシング ソリューションに冗長性を加えて、保護レイヤーを追加し、ロード バランサーが単一障害点にならないようにします。そのためには、アクティブ/パッシブ構成内に 2 つのロード バランサーを設定します (両方のロード バランサーで 1 つの仮想 IP アドレスを使用)。アクティブ側のロード バランサーで障害が発生した場合は、パッシブ側のロード バランサーにフェイルオーバーします。
詳細については「ロード バランサー設定オプション」をご参照ください。
アプリケーション ノード
アプリケーション ノードとは、実際に製品が稼働する場所です。レイテンシを最小限に抑えるため、Data Center クラスタ内の各ノードは、製品の同じバージョンで動作して同じ場所に置かれる必要があります。ただし、地理的に分散したチームのパフォーマンスは、コンテンツ デリバリ ネットワーク (CDN) によってサポートできます。これらのノードは、ユーザーに製品を提供するため、1 つのクラスタにおいて 1 つのノードとして機能するように設定されます。クラスタ内のノードの数は、ニーズや製品の構成方法によって異なります。通常、ほとんどのクラスタでは 2 - 4 ノードで十分ですが、適切な数を判断するためにノード サイズ ガイドをご利用ください。
Bitbucket には、コード検索を可能にする ElasticSearch 専用の追加アプリケーション ノードが必要です。
共有ファイル システム
共有ファイル システムには、任意のアプリケーション ノードからアクセスできる必要があるデータ (添付ファイル、git リポジトリなど) が保存されます。
Data Center 環境では、共有ファイル システムを独自のノードとしてセットアップする必要があります。共有ファイル システム用の NFS ベース NAS または SAN プログラムを使用することもできますが、パフォーマンスを維持するため NFS3 を推奨します。DFS などの分散プロトコルはサポートされていないため、使用しないでください。
ステージング環境の作成
マルチノードへのアップグレードを完了させるため、本番環境での稼働前に、ステージング環境を作成して Data Center を試してみることをお勧めします。
ステージング環境は、リバース プロキシ、SSL 設定、またはロード バランサーを含めて、本番環境を厳密に複製する必要があります。異なる物理サーバーまたは仮想ソリューションを使用することもできます。重要なことは、本番環境に見合ったレプリカとすることです。
詳細については、以下を参照してください。
エキスパートと話す
移行オプションやパスについてご不明な点がある場合は、移行スペシャリストのチームから専門的なガイダンスをお受けください。