Close

Data Center 移行ガイド

組織はそれぞれ異なり、組織ごとに移行ジャーニーも異なります。移行を成功させる鍵は計画です。


ガイド 2: 移行を計画する

移行パスを確認し、選択できたので、Data Center への移行の計画を開始できます。

チームの構築 必須

このジャーニーの最も重要な要素の 1 つが、適切なチームを構築することと、それをできる限り早く実施することです。Data Center の立ち上げは、組織の複数のチームに影響を与え、全員の共同での取り組みが必要です。

プロジェクト チーム構築後、共有された目標に合わせてチームの足並みを揃え、同意された目標日でスケジュールを立てることが重要です。

チームに含めるべき役割とメンバーの人数について、決定的な答えはありません。ただし、チームの構築に当たっては以下の専門領域を考慮することが重要です。


アプリケーション管理者

役割

アプリケーション管理者は、日々の管理を扱います。製品の深い知識を持って、パフォーマンスと信頼性に配慮し、Marketplace アプリを評価、保守します。また、エンド ユーザーと密接に連携して、そのニーズを理解し、支援またはトレーニングを提供する場合もあります。

責務
  • Data Center が正常に機能していることを確認するために、テストの際に機能やパフォーマンスを厳しく検証します。
  • アップグレード時に Data Center 認定ではないアプリを維持するかどうかを決定します。
  • 移行全体を通して、ユーザーと権限が正しく維持 (または変更) されていることを確認します。

システム管理者

役割

システム管理者は、インフラストラクチャから製品インターフェースに至るまですべてを扱います。バックアップ、ストレージ、ネットワーク、パフォーマンスの管理を担当します。

責務
  • 必要なハードウェア (物理または仮想) を集めます。
  • 実際の Data Center のインストールを実行します。
  • クラスタでのデプロイを選択した場合、すべてのコンポーネントが正しく機能していることを確認します。
  • 監視とセキュリティ戦略を可能にするため、オンディスクからログ アグリゲーターにログを移します。

プロジェクトのリーダー

役割

プロジェクト リードは、ビジネスと深く関係し、企業の目的を満たすために製品を使用する方法とその理由を知っています。製品全体のガバナンスを維持するための適切なトレードオフを行う方法も知っています。

責務
  • 主要なマイルストーンとその推定達成日をもって、プロジェクトを軌道に乗せます。
  • スケジュールを管理し、タスクの完了を確認し、機能横断的な課題を解決します。
  • ステークホルダーにはプロジェクトの最新情報を、エンド ユーザーにはお知らせを伝えます。
  • Data Center の購入において、主要な関係者と連携します。

クラスタ アーキテクチャで Data Center をデプロイしている場合、以下の分野の技術的専門性を有するチーム メンバーの採用も検討してください。

  • ネットワーク エンジニアリング: 仕様を確認し、インフラストラクチャを構築します。
  • データベース管理: データベースの完全性とスムーズな運用を確認します。
  • サイトの信頼性: インスタンス アップタイム、パフォーマンス、ディザスタ リカバリ運用を確立します。
  • セキュリティ: セキュリティ標準 (VPN、ファイアウォールなど) を確実に遵守します。

追加チーム メンバーの必要性

必要に応じて、アトラシアンが移行のサポートを提供します。

Data Center をフル活用

Priority サポート (最初の 6 か月間): アトラシアン サポートに要求を送信すると、課題が当社の最も経験豊富なシニア エンジニアに直接送信されます。シニア エンジニアが、より高品質の SLA と迅速なトリアージ、速やかな解決を実現することをお約束します。アトラシアンでは現在、Jira Software、Jira Service Desk または Confluence の Data Center ライセンスをお持ちのお客様にこのサービスを提供しています。

*これは、2021 年 2 月 2 日に利用可能になる Data Center のサブスクリプションに含まれます。

カスタマー サクセス マネージャー: チームの目標とビジネスのニーズのサポートをご希望ですか?Data Center の新規のお客様は、初年度を通して継続的なリソースとして専任のカスタマー サクセス マネージャーのサポートを受けられます。こちらからお問い合わせください。

アトラシアン コミュニティ: クラウド ソーシングをご希望ですか?他のアトラシアン ユーザーからの質問や回答をご確認ください。エンタープライズ コミュニティ グループに参加して、アトラシアン製品を大規模環境で使用する際のストーリー、ヒント、およびベスト プラクティスを確認することをお勧めします。

有料サポート リソース

テクニカル アカウント マネージャー: 製品と業界の知識をもつ、経験豊富なアトラシアン アドバイザーをご希望ですか?テクニカル アカウント マネージャーは、アトラシアンのすべてに精通した戦略的なパートナーです。専門性を提供し、お客様ご自身では思いつかない疑問点を挙げることで、お客様のジャーニーをガイドします。

プレミア サポート: ハイレベルのサポートが必要であれば、アトラシアンのプレミア サポートが、専任のシニア サポート チームへの年中無休のアクセスを含む、最高レベルのサポートを提供します。

エンタープライズ パートナー: ワンストップ ショップをご希望ですか?エンタープライズ パートナーは、参加型のシステム統合、デプロイメントおよびアップグレードを行います。エンタープライズ パートナーは、複雑な要件がある組織またはオンサイトの支援を求めている組織には有効な選択肢です。アトラシアンのパートナー ディレクトリでお客様に最適なパートナーを見つけてください。

タイムラインを構築する 必須

以下に示すのは、移行の所要時間の推定に使用できる基本タイムラインです。

 

非クラスタ

クラスタ化

計画する

0 - 2 週間

1 か月 +

予行演習

0 - 1 週間

3 - 6 か月

稼働開始

0 - 1 週間

- 6 - 9 か月

情報アイコン

含まれるタイムラインは、Data Center のインストールに成功した弊社の多数のお客様の事例をもとにしていますが、実際のタイムラインは、お客様の環境に固有の要因 (規模、複雑性、準備状況など) に応じて異なります。

サーバー インスタンスの確認とインフラストラクチャの最適化

選択した Data Center のデプロイ方法 (非クラスタまたはクラスタ) にかかわらず、サーバー インスタンスを確認し、移行中に最適化したい領域があるかどうかを把握してください。

最新の LTS リリースへのアップグレード 推奨

アップグレードと移行を同時に実施するのは難しい場合があるため、まだ最新の LTS リリースに製品をアップグレードしていない場合はまずアップグレードすることをお勧めします。それによって、移行をよりスムーズに進めやすくなります。

インスタンスのサイズの評価 必須

Data Center は、大規模なチームのニーズをサポートするようにビルドされています。移行が成功するようにインフラストラクチャをセットアップするには、現在のサーバー インスタンスの規模を確認し、推奨されるプロフィール サイズに基づいて調整してください。サイズを調整する際、規模を適切に調整できるよう、成長率を考慮してください。

サーバー インスタンスのベンチマーク 推奨

システムの既存の機能とパフォーマンスのベースライン測定を行います。カスタム フィールド オプティマイザー、アーカイブなどの機能を使用する場合、Data Center と既存のサーバー インスタンス間のパフォーマンス改善を測定できます。

サーバー インスタンスの微調整 推奨

インスタンスをクール ダウンするため当社の機能 (アーカイブ、カスタム フィールド オプティマイザーなど) をすぐに活用する予定の場合でも、移行前にサーバー インスタンスを微調整する必要があります。現在のサーバー インスタンスを確認し、次善の設定を特定、修正する時間を設けてください。早い段階でこの時間を設けることで、Data Center インスタンスのより強固な基礎を構築しやすくなります。

ガバナンスの評価と更新 必須

ユーザーが製品を操作する方法も、アプリケーションの製品に影響します。Data Center のデプロイ前に、このような利用状況の特徴を評価し、REST 呼び出しまたはその他の統合によってパフォーマンスを保護するスクリプトなどを制限する必要があるかどうか判断します。

現在のプロセスの文書化 推奨

インスタンスの調整後に、サーバー環境を文書化してください。この文書化は、Data Center 移行の構成の決定を検討し、プロセス変更を周知し、移行後に見られる課題が新規のものか既知のものかを判断するのに役立ちます。

現在のアプリの監査

使用するアプリの数が多いと、インスタンスのパフォーマンスが低下する可能性があります。システム機能にとって重要でないアプリを監査、削除して、システム全体のパフォーマンスを向上させることが重要です。Data Center バージョンが公開されている場合、アプリを Data Center バージョンにアップグレードする必要があるため、アプリが Data Center に対応していることも確認してください。

現時点でアプリの Data Center バージョンがない場合、サーバー アプリを引き続きご利用いただけますが、Data Center バージョンが公開されしだい、アップグレードする必要があります。

Data Center の総所有コストの要素として、アプリの現在および将来の価格を両方考慮してください。詳細については、総所有コスト ページを参照してください。

技術上の決定を検証する

技術の決定に先行することで、組織のニーズに合わせた Data Center 製品の本番に対応した環境の設計が早くなります。クラスタ環境と非クラスタ環境のどちらで Data Center 製品をデプロイする予定なのかを問わず、製品の実行に現在使用しているインフラストラクチャを確認し、AWS、Azure、または自社のハードウェアでデプロイするのが有効かどうか検討してください。クラスタ環境でのデプロイを決定した場合、ロード バランサー、ファイル システム、アプリケーション ノードなど、必要な追加コンポーネントの評価を開始する必要があります。何が使用可能か、または何を購入できるかを判断してください。

技術の決定の評価に役立つ追加推奨事項とリソースについては、デプロイ チェックリストをダウンロードしてください。

Understand environment changes if you’re using a cloud provider

Browser grid icon

Application layer


Instances and locations

  • Do you want to federate or consolidate your instances?
  • What does your future growth look like?
  • Do you need to have any data isolation?
  • How many environments does your team have, such as staging or production environments?

Instances profiles

  • How many people are going to be accessing your instance?
  • Where are your teams going to be located?
  • How much data is currently in your instance and how much data do you plan to add to your instance?

Apps, integrations, and customizations

Do you need all of them, or is this an opportunity to simplify?

Server icon

Infrastructure layer


Instance sizing

  • What are your future growth projections?
  • Are there times when you have lower levels of user traffic?
Information icon

Looking at your user traffic can help determine your organization’s scale patterns. If there are times when you have more teams accessing your products, you can also consider setting up a scaling schedule.

For more information, here’s our node sizing overview.

Account structure

  • Which accounts should your environment be deployed on?
  • Do you want different accounts associated with each of your environments?
  • Do you want your Data Center products to use the same account as your other CI/CD or collaboration tools?

Governance model

  • What does your governance model look like?
  • What are your minimal system standards?
  • Are you using centralized logging?
  • What are your user management needs?

Consider using AWS landing zone and AWS System Manager as part of your governance model.

VPC

  • Do you want to use a new virtual private cloud (VPC)?

Information icon

Whether you want to deploy in a new VPC or use an existing one, you can leverage the Atlassian Standard Infrastructure (ASI) template.

  • Are there any network principles that you want to change, such as limiting public internet access and internal IP addressing for office and VPN network routing?
  • Should you use TLS certificates?

Geography

  • If using an existing VPC, have you come up with a plan for office and VPN network access?

Information icon

We recommend that you allow access from all offices and VPNs as your product usage will most likely grow over time.

Direct Connect

  • Do you want to use Direct Connect to help with performance and security?
  • How much data do you need to move from your server instance to Data Center?
Information icon

AWS Snow Family may be a resource that you may want to consider if you’re moving large amounts of data.

Safe icon

Business continuity and disaster recovery


Backup

What does your backup strategy look like?

Information icon

We recommend that you use a combination of both your existing backup strategy and backup capabilities built into AWS. For more information, see:

AWS provides infrastructure services that are less prone to singular outages. Our Quick Start templates use some of those services to provide high availability for your instance:

Regional failover

Do you need to implement cold, warm, or hot sites in different regions?

Typically, your disaster recovery needs are met by having your services run over multiple availability zones, but you may want to mitigate regional outages too. As you’re deciding if you want to implement these sites in different regions consider the following:

  • Cost of infrastructure and data transfer
  • Speed of recovery vs AWS
  • Time spent maintaining and testing the recovery site
  • Cost of running the site