Atlassian Data Center の移行計画

この記事では、シングル ノード デプロイからクラスター Data Center デプロイへの移行の高レベル プロセス プランを紹介しています。その目的は、移行プロセスの実施前、実施中、実施後にプロジェクト アクティビティの概要と潜在的なタイムラインを提供することです。それは、従業員への協力の要請、技術オプションの評価、現在の Server アプリケーションの移行準備状態の確認をカバーしています。

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

この記事では、テクノロジー オプションやインストール構成に対する技術的な詳細な説明は含まれていません。

クラスタ化された Data Center 製品への移行は、次の要素に影響します。

• ユーザーのエクスペリエンスとワークフロー
• 組織全体のさまざまなステークホルダー
• 他のインフラストラクチャ コンポーネント

チームの構築 → インストールのレビュー → プロセスの文書化 → 意思決定のレビュー → テストとデプロイ

このタイムラインは、実装に成功するまでのフェーズを示しています。各段階で予測すべきことを特定し、プロセスで発生する問題を制御するための、人員確保、計画、意思決定などの初期段階の作業を確実に行うことができます。このプロセスを利用すると、Data Center への移行を、より生産的に実現していただけます。

Data Center への移行は次のいずれかになります。

• インプレース。1 つの Server アプリケーションをマルチノード Data Center アプリケーションとしてデプロイする。
• 統合。隔離されたノード上で実行している複数の Server アプリケーション (別のチームが使用する Jira の別のインスタンスなど) を、統一されたクラスタ化 Data Center アプリケーションとして再デプロイする。

このドキュメントでは、インプレース移行プロセスに焦点を当てています。移行の際にインスタンスを統合する必要がある場合は、「Atlassian Data Center インスタンス統合の概要」を参照してください。　

プロジェクト チームを構築する

スタッフを参加させ、Data Center の目標に向けてチームで合意します。

スタッフを参加させる

理想的な Data Center デプロイメントとは、チーム全体でロールと責任が定義されている、完全に独立したプロジェクトです。Data Center への移行に関心を持ったり、移行の影響を受けたりする個人やステークホルダーに、できるだけ早い時期に連絡しましょう。可能であれば、これらのスタッフをチームに加え、プロセスの一部として参加させます。プロセスを成功させるためのロールの概要は次のとおりです。

Data Center の目標についてチームで合意する

Data Center supports many features crucial to the management and operations of Jira, Confluence, Bitbucket, and Crowd at scale. It's important that these features, the associated goals of adopting these features, and the metrics showcasing the impact of meeting these goals are agreed upon and communicated to all stakeholders. During implementation, the team will evaluate a go/no-go decision based on these criteria. Deploying confidently to production requires that all stakeholders align on mutually agreed-upon business, functionality, and performance goals for the migration. Proper upfront alignment ensures a smoother installation, testing, and release process.

現在のインフラストラクチャを確認する

インフラストラクチャのベンチマーク テストと微調整、ガバナンスの評価と更新、インストールされたアプリの見直しを行います。

現在のインフラストラクチャのベンチマークをテストする

サイトのパフォーマンスのベースライン測定を行い、現状のままで組織のニーズを満たしているかを確認します。テスト中に、チームはクラスター化されたデプロイへの移行で見込まれる改善事項を測定することができます。すべての機能が適切に動作しているかを検証します。

現在のインフラストラクチャでパフォーマンスが十分な場合でも、ベンチマーク テストはパフォーマンスを数値化するのに役立ちます。組織の成長とともに、トラフィックや使用量も増加します。測定したベースライン値は、1 年後にインフラストラクチャの安定性を評価する際に使用できます。

アプリケーションを最適化する

もっとも拡張性の高いマルチノード クラスタ デプロイを使用すると、アプリケーションで大量のユーザーを同時に処理できます。これは、ビジネスが成長してアトラシアン アプリケーションに多数のユーザーを追加している場合は特に大きなメリットですが、クラスタ化が個々のノードのパフォーマンスを本質的に改善するわけではないことを理解しておくことが重要です。同時並列性に関連しないパフォーマンスの問題は、それらが単一ノード デプロイの構成や使用状況が最適化されていないことに起因する場合は特に、クラスタ化では解消されず、悪化する可能性もあります。 

たとえば、大量のカスタム フィールドがある単一ノード Jira インスタンスは、パフォーマンスが低下する可能性が高くなります。この同じ Jira インスタンスをクラスタ化された Data Center に移行しても、既存のカスタム フィールドが引き続きパフォーマンスを低下させるため、パフォーマンスは改善されません。この例の場合は、パフォーマンスを改善するために、カスタム フィールドの使用を見直し、不要な場合は削除することが重要です。Data Center 製品の価値を最大限に活用するには、既存の Server インストールを徹底的に見直して最適化し、できるだけ多くのパフォーマンス障害を取り除くことが重要です。

たとえば、Jira では、次の要素が増えると、アプリケーションのパフォーマンスが損なわれる可能性があります。

• Jira 課題の数
• カスタム フィールドの数
• メール通知の数
• アプリの数 ¹
• ワークフロー手順の実行数
• アプリケーションを実行しているサーバーの種類

これらの各要素を見直し、パフォーマンスを最大化するためにできるだけ利用率を減らします。必要な最適化の実施には 1～2 週間かかる可能性がありますが、この作業を早い段階で行わない場合、デプロイがより長く困難になる可能性があります。

アプリケーションの最適化にあたっては、次のリンクを参照してください。

• パフォーマンスおよび拡張のテスト
• Bitbucket Server の拡張
• Confluence のパフォーマンスのチューニング

ガバナンスの評価と更新

ユーザーがアプリケーションを操作する方法も、アプリケーションのパフォーマンスに影響します。たとえば、頻繁にレポートを実行するユーザーがいると、システムに負荷がかかり、パフォーマンスが低下する可能性があります。移行の前に、このような利用状況の特徴を特定する必要があります。REST 呼び出しやその他の連携を行うスクリプトに制限を設定する必要がある場合があります。特に、多くの書き込み操作を実行するスクリプトは、書き込み操作ですべてのノードにわたって同期を行うため、クラスタのパフォーマンスを低下させる可能性があります。チームは、組織のニーズに沿ったユーザー機能とパフォーマンスの正しいバランスを決定する必要があります。

インストールされたアプリの確認

アプリの数がインスタンスのパフォーマンスに影響を与える可能性があります。Data Center 認証済みアプリをインストールするとこの問題の軽減するに役立ちます。Data Center 認証アプリは、アトラシアンが行う厳密な技術的レビュー プロセスを経ています。このプロセスでは、Data Center 環境でのパフォーマンス、安定性、および全体的な適合性について、アプリのテストが行われます。このプロセスの詳細な情報については、Data Center アプリ開発のガイドラインを参照してください。

インストールしたアプリのレビューを行う際は、Atlassian Marketplace に Data Center 認証バージョンがあるかどうかを確認します。見つからない場合、他に利用できる代替アプリがあるかどうかを確認します。詳細については、「Data Center への移行に向けてアプリを評価する」を参照してください。

現在のプロセスの文書化

アプリケーションのチューニング後、単一ノード インストールさまざまな側面を文書化します。これは、以下のことに役立ちます。

• 新しいデプロイメントの構成オプション
• 移行によるプロセス変更の周知
• デプロイ後にみられる課題が新規のものか既知のものかの特定

次のような点を記載します。

• Data Center デプロイの挙動が新規のものか既存のものかを見分けるための、Server アプリケーションの操作、機能、またはパフォーマンスに関する一般的なシステム動作ベンチマーク
• アプリケーションの API アクセス パターン (API の使用率が高い場合、API トラフィックを処理するために特定のノードへのプロビジョニングが示される場合があります)
• バックアップ プロセスと頻度
• レポートのプロセス、頻度、および受信者
• 監視ツールおよび測定対象
• スケジュールされたメンテナンス間隔
• 組織用のディザスタ リカバリ ガイド

異なるアプリケーション インスタンスにわたるプロセスは、文書化および評価し、Data Center アプリケーションの 1 つのプロセス セットに適切にまとめる必要があります。このような変更を、影響を受ける各チームに継続して連絡することが重要です。

技術上の決定を検証する

次の内容に対する技術上の決定やタスクの先を見据えることは、組織のニーズに合う本番環境に対応したクラスター環境をチームが素早く設計するのに役立ちます。

コンポーネント

これらは、マルチノード クラスター環境の主要コンポーネントです。Atlassian では使用するベンダーやオプションに関する具体的な推奨は行っておりませんが、このような決定に役立つサポートを提供しています。

ロード バランサ

ロード バランサはユーザーからクラスター ノードへのリクエストを分散させ、アプリケーションに高い可用性を提供します。ロード バランサの詳細は、次のリンクを参照してください。

• ロードバランサーの構成オプション
• Atlassian Data Center を使用したトラフィック分布

アプリケーション ノード

クラスタ ノードは、受信リクエストのワークロードを共有します。すべてのノードが同じデータ センター内にある必要があり、アクティブ状態で、リクエストを処理します。ノードがダウンすると、ロード バランサはクラスタ内の残りのノードにリクエストを送信します。

単一 Server デプロイメント用のガイドも含まれていますが、必要な事項を検討するために次のリンクをご利用いただけます。

• クラスタ化された Jira 環境でのノードのサイズ設定
• 「サーバー ハードウェア要件ガイド」の Confluence のノード サイズの設定要件
• 「Bitbucket Server の拡張」の Bitbucket のノード サイズの設定要件
  

共有データベース

Data Center アプリケーションは一般的に Server アプリケーションでサポートされるデータベースと同じものをサポートします。

共有データベースを設定する場合、全ノード間の最大接続数に対応可能であることを確認してください。たとえば、ノードが 3 つあり、それぞれが最大で 50 接続をサポートする場合、データベースは 150 接続以上をサポートする必要があります。多くの場合、管理やその他の目的のために、追加接続を構成する必要があります。

共有ファイル システム

すべてのクラスタ化デプロイには共有ファイル システムが必要です。NFS など、ファイル システム プロトコルを経由した NAS がその一例です。すべてのアプリケーション ノードは、同じパスで共有ディレクトリにアクセスできる必要があります。共有ファイル システムに保存されるものの例として、プラグイン、共有キャッシュ、リポジトリ、添付ファイル、アバターなどがあります。

各製品のこれらのコンポーネントの詳細は、次のリンクを参照してください。

• Confluence Data Center の技術的概要
• Jira Data Center のリソース
• Bitbucket Data Center の要件

クラスターのセットアップ

組織のニーズを満たすように、クラスター構成の評価、設定、および最適化に時間をかけることをおすすめします。過去にお客様のインストールを確認した際の例をいくつか示します。

• ノードの数を減らしてサイズを大きくしたクラスターと、ノードの数を増やしてサイズを小さくしたクラスターのどちらがお使いの環境により適しているかを評価します。
• ノードのサイズを決定する際には、エラーが雪だるま式になる場合を考慮します。このようなエラーは、インスタンスがダウンし、残りのインスタンスが受信負荷を処理できない場合に発生します。
• 特定のノードが特定の種類のトラフィックを処理できるよう、トラフィックのセグメント化を検討します。
• クラスターの拡張をよりうまく管理するために、Docker、Chef、Puppet などの仮想化/自動化ツールを調査します。
• New Relic、Splunk、ELK などの堅牢な監視ツールへの投資を検討します。
• 既存の監視ツールがマルチノード環境を処理できるよう再構成されていることを確認します。

テストおよびデプロイ プロセスの実施

クラスタ化されたデプロイメントをテストし、Data Center 製品を本番環境で起動します。

クラスタ化されたデプロイメントをテストする

クラスタ化されたデプロイメントを自信を持って本番環境にデプロイするには、チームが機能テスト、統合テスト、パフォーマンス テストを繰り返し実施する必要があります。チーム メンバーは続行/中止の判断を効果的に検証するため、一連のメトリックに合意しておく必要があります。デプロイを成功させるためにアトラシアンがお客様に推奨している一般的なプロセスは次のとおりです。 

テスト → 調整 → 文書化 → コミット → 実行 → サポート

各ステップのタイミングは、クラスタ インフラストラクチャの移行に成功したお客様の事例を参考にしています。

• テスト: アプリケーションをテスト環境に移行した後、チームはユーザー受け入れテストを実施する必要があります。このテストでは、組織に関連する機能、パフォーマンス、および統合を検証します。各テストは 1 ～ 2 週間かかる場合があり、一連のメトリックが満たされていることを確認します。さまざまな角度からテストしてアプリケーションが本番環境に対応していることを確認する、反復的なプロセスです。これは移行プロセスの最も集中的な部分であり、一般的には、実施に約 3 ～ 6 カ月かかります。
• 調整: ユーザー受け入れテストの結果は、アプリケーションの構成をどのように最適化し、アプリケーションの利用を管理するプロセスをどのように強化すればよいかをチームに指示するのに役立ちます。これにより、組織のプロセスとアプリケーション構成を緊密に組み合わせることができます。
• 文書化: チームはプロセス全体ですべての内容を文書化し、この期間に、インストール、構成、ネットワーク図、アーキテクチャ図、反省点、バグ、解決策、およびアプリケーションに関するその他すべてのことに関するすべてのドキュメントを整理して見直します。

Data Center を本番環境で立ち上げる

• コミット : チームは、テストや調整の結果を使用して、クラスタ化されたデプロイメントを本番環境に進める準備が整ったかどうかを評価します。まだであると判断された場合、テストを繰り返して、見直しが必要な部分やギャップを特定します。
• 実行: 一般的、週末や使用率が低い時期に本番環境にプッシュします。ローンチ プロセスをテスト/検証するために「モック デプロイ」を選ぶお客様もいます。このプロセス、エンド ユーザーへの通知の送信を確認します。
  
• サポート: Data Center アプリケーションを立ち上げ後に監視し、機能やパフォーマンスの問題がないことを確認することは、チームにとって非常に重要です。

  Atlassian が提供するサービス