Atlassian Data Center の移行計画
この記事では、Atlassian Server アプリケーションを 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 への移行のスコープを考慮し、プロジェクトにエグゼクティブ購入担当者を加えることをおすすめします。 |
| 運営委員会 | 方針レベルと方式レベル両方の指針を提供する、プロジェクト運営委員会です。 |
| テクニカル プロダクト/プロジェクト マネージャー | テクニカル プロダクト (またはプロジェクト) マネージャーは、スケジュールを管理し、タスクの完了を確認し、機能横断的な課題を解決します。また、この人物は、ステークホルダーにはプロジェクトの最新情報を、エンド ユーザーにはお知らせを伝えます。 |
| テクニカル アカウント マネージャー | Atlassian のテクニカル アカウント マネージャーはデプロイメント計画の指針を提供し、お客様の組織で適切な部門がプロセスに参加していることを確認します。 |
| 方式の検討 | |
| パワー ユーザー | 多くの場合、Jira のプロジェクト管理者または Confluence のスペース管理者です。Data Center が正常に機能していることを確認するために、テストの際に機能やパフォーマンスを厳しく検証します。 |
| ヘルプ デスク、システム アドミニストレーター | 移行の際に L1 のサポート課題が発生した場合、弊社の最前線のスタッフが対応いたします。これにより、Atlassian 製品の管理者は、プロセスでのより重要な課題に焦点を当てることができます。 |
| データベース管理者 |
データベース管理者 (DBA) は、プロセス中も最前線のサポートを提供します。また、DBA は、Data Center の DR 運用と足並みを揃えるために、組織の災害復旧計画の見直しと更新を行います。 |
| ネットワーク エンジニア | ネットワーク エンジニアは接続性を分析し、Data Center 向けにネットワーク要件を更新します。また、ネットワーク エンジニアは、Data Center 内の必須コンポーネントであるロード バランサの選択や構成に関する専門知識とガイダンスを提供します。 |
| サイト信頼性エンジニア (SRE) | SRE は、Data Center が正常に機能し、組織の他のテクノロジー インフラストラクチャとのバランスを取れるようにします。 |
| セキュリティ エンジニア | セキュリティ エンジニアは、Data Center が組織のセキュリティ プラクティスを順守するようにします。 |
| プレミア サポート | Atlassian プレミアサポートは、デプロイメントの際にチームが遭遇したあらゆる課題に対し、24/7 (24 時間 365 日) のサポートを提供します。また、プレミア サポートは現在の Server インストールを確認し、Data Center への移行に対応しているかを検証いたします。 |
Data Center の目標についてチームで合意する
Data Center は、お客様のニーズに合わせてさまざまなメリットを提供します。このような理由、関連する目標、および Data Center による影響と改善を示すメトリックについて、組織全体で確認および合意し、文書化することが重要です (プロジェクトの途中でスタッフが交代する場合は特に有効です)。実装の際、チームはこれらの条件に基づいて継続/中止の判断を検証します。自信を持って本番環境に実装するには、すべてのステークホルダーが、ビジネス、機能、およびパフォーマンスに関する互いに合意した移行目標について、足並みをそろえる必要があります。事前調整を適切に行うことで、インストール、テスト、およびリリース プロセスをスムーズに進めることができます。
現在のサーバー インストールを確認する
サーバー アプリケーションのベンチマーク テストと微調整、ガバナンスの評価と更新、およびインストールされたアプリの見直しを行います。
Server アプリケーションのベンチマーク テスト
Data Center への移行の組織の目標に関連する、システムの機能/パフォーマンスのベースライン測定を行います。テストを通じて、チームは Data Center への移行で期待される機能/パフォーマンスを測定できます。
Server アプリケーションの微調整
Data Center の水平方向に拡張可能なマルチノード クラスターでは、アプリケーションが処理可能な同時ユーザー数が大幅に増加します。これは大きなメリットですが、Atlassian ツールのユーザー数の追加を進めているような成長途上の組織は特に、Data Center は個別ノード自体のパフォーマンスを本質的に改善するわけではないことを理解しておくことが重要です。Server アプリケーションの設定や使用率によって発生する、同時並列性に関連しないパフォーマンス問題は、Data Center では解消されず、悪化する可能性もあります。たとえば、大量のカスタム フィールドがある Jira Server アプリケーションは、パフォーマンスが低下する可能性が高くなります。この Jira アプリケーションを Data Center にデプロイしても、既存のカスタム フィールドが引き続きパフォーマンスを低下させるため、パフォーマンスは改善されません。この例の場合は、パフォーマンスを改善するために、カスタム フィールドの使用を見直し、不要な場合は削除することが重要です。Data Center の価値を最大限に活用するには、既存の Server インストールを徹底的に見直して最適化し、できるだけ多くのパフォーマンス障害を取り除くことが重要です。
たとえば、Jira では、次の要素が増えると、アプリケーションのパフォーマンスが損なわれる可能性があります。
- Jira 課題の数
- カスタム フィールドの数
- メール通知の数
- アプリの数
- ワークフロー手順の実行数
- アプリケーションを実行しているサーバーの種類
これらの各要素を見直し、パフォーマンスを最大化するためにできるだけ利用率を減らします。必要な最適化の実施には 1～2 週間かかる可能性がありますが、この作業を早い段階で行わない場合、デプロイがより長く困難になる可能性があります。
アプリケーションの最適化にあたっては、次のリンクを参照してください。
ガバナンスの評価と更新
ユーザーがアプリケーションを操作する方法も、アプリケーションのパフォーマンスに影響します。たとえば、頻繁にレポートを実行するユーザーがいると、システムに負荷がかかり、パフォーマンスが低下する可能性があります。Data Center をデプロイする前に、このような利用用途の特徴を特定する必要があります。REST 呼び出しやその他の連携を行うスクリプトに制限を設定する必要がある場合があります。特に、多くの書き込み操作を実行するスクリプトは、書き込み操作ですべてのノードにわたって同期を行うため、クラスターのパフォーマンスを低下させる可能性があります。チームは、組織のニーズに沿ったユーザー機能とパフォーマンスの正しいバランスを決定する必要があります。
インストールされたアプリの確認
前述のように、多数のアプリを使用するとアプリケーションのパフォーマンスが低下する可能性があります。システム機能にとって重要でないアプリを削除して、システム全体のパフォーマンスを向上させることができます。一部のアプリは Data Center との互換性がないため (認証済みの Data Center アプリは Atlassian Marketplace で見つけることができます)、必要に応じて代替策を調査することが必要になります。詳細は、「Data Center への移行に向けたアプリの評価」を参照してください。
現在のプロセスの文書化
アプリケーションのチューニング後、Server インストールの状況を文書化します。これは、Data Center デプロイの構成オプションを検討し、Data Center によるプロセス変更を周知し、デプロイ後に見られる課題が新規のものか既知のものかを特定するのに役立ちます。次のような点を記載します。
- Data Center デプロイの挙動が新規のものか既存のものかを見分けるための、Server アプリケーションの操作、機能、またはパフォーマンスに関する一般的なシステム動作ベンチマーク
- アプリケーションの API アクセス パターン (API の使用率が高い場合、API トラフィックを処理するために特定のノードへのプロビジョニングが示される場合があります)
- バックアップ プロセスと頻度
- レポートのプロセス、頻度、および受信者
- 監視ツールおよび測定対象
- スケジュールされたメンテナンス間隔
- 組織用のディザスタ リカバリ ガイド
異なるアプリケーション インスタンスにわたるプロセスは、文書化および評価し、Data Center アプリケーションの 1 つのプロセス セットに適切にまとめる必要があります。このような変更を、影響を受ける各チームに継続して連絡することが重要です。
技術上の決定を検証する
次の内容に対する技術上の決定やタスクの先を見据えることは、組織のニーズに合う本番環境に対応したクラスター環境をチームが素早く設計するのに役立ちます。
コンポーネント
これらは、マルチノード クラスター環境の主要コンポーネントです。Atlassian では使用するベンダーやオプションに関する具体的な推奨は行っておりませんが、このような決定に役立つサポートを提供しています。
ロード バランサ
ロード バランサはユーザーからクラスター ノードへのリクエストを分散させ、アプリケーションに高い可用性を提供します。ロード バランサの詳細は、次のリンクを参照してください。
アプリケーション ノード
Data Center ノードは、受信リクエストのワークロードを共有します。すべてのノードが同じデータ センター内にある必要があり、アクティブ状態で、リクエストを処理します。ノードがダウンすると、ロード バランサはクラスター内の残りのノードにリクエストを送信します。
単一 Server デプロイメント用のガイドも含まれていますが、必要な事項を検討するために次のリンクをご利用いただけます。
- クラスタ化された Jira 環境でのノードのサイズ設定
- 「サーバー ハードウェア要件ガイド」の Confluence のノード サイズの設定要件
- 「Bitbucket Server の拡張」の Bitbucket のノード サイズの設定要件
- Hipchat デプロイメント オプションおよび Hipchat Data Center のサイズ設定ガイドライン
共有データベース
Data Center アプリケーションは一般的に Server アプリケーションでサポートされるデータベースと同じものをサポートします。
Bitbucket Data Center は現時点では MySQL をサポートしていません。
共有データベースを設定する場合、全ノード間の最大接続数に対応可能であることを確認してください。たとえば、ノードが 3 つあり、それぞれが最大で 50 接続をサポートする場合、データベースは 150 接続以上をサポートする必要があります。多くの場合、管理やその他の目的のために、追加接続を構成する必要があります。
共有ファイル システム
すべての Data Center アプリケーションには共有ファイル システムが必要です。一例として、NFS など、ファイル システム プロトコルを経由した NAS があります。クラスタ内のすべてのノードは、同じパスで共有ディレクトリにアクセスできる必要があります。共有ファイル システムに保存されるものの例として、プラグイン、共有キャッシュ、リポジトリ、添付ファイル、アバターなどがあります。
各製品のこれらのコンポーネントの詳細は、次のリンクを参照してください。
- Confluence Data Center の技術的概要
- Jira Data Center のリソース
- Bitbucket Data Center の要件
- Hipchat Data Center 用の設定要件
クラスターのセットアップ
組織のニーズを満たすように、クラスター構成の評価、設定、および最適化に時間をかけることをおすすめします。過去にお客様のインストールを確認した際の例をいくつか示します。
- ノードの数を減らしてサイズを大きくしたクラスターと、ノードの数を増やしてサイズを小さくしたクラスターのどちらがお使いの環境により適しているかを評価します。
- ノードのサイズを決定する際には、エラーが雪だるま式になる場合を考慮します。このようなエラーは、インスタンスがダウンし、残りのインスタンスが受信負荷を処理できない場合に発生します。
- 特定のノードが特定の種類のトラフィックを処理できるよう、トラフィックのセグメント化を検討します。
- クラスターの拡張をよりうまく管理するために、Docker、Chef、Puppet などの仮想化/自動化ツールを調査します。
- New Relic、Splunk、ELK などの堅牢な監視ツールへの投資を検討します。
- 既存の監視ツールがマルチノード環境を処理できるよう再構成されていることを確認します。
テストおよびデプロイ プロセスの実施
Data Center のインストールをテストして、本番環境で Data Center を立ち上げます。
Data Center インストールのテスト
Data Center を自信をもって本番環境にデプロイするには、チームが機能テスト、統合テスト、パフォーマンステストを繰り返し実施し、Data Center インストールを徹底的に検証する必要があります。チーム メンバーは Data Center のデプロイに対する続行/中止の判断を効果的に検証するため、一連のメトリックに合意しておく必要があります。デプロイを成功させるためにお客様に勧める一般的なプロセスは次のとおりです。
各ステップのタイミングは、Data Center のインストールに成功したお客様の事例を参考にしています。
- テスト: アプリケーションをテスト環境に移行した後、チームはユーザー受け入れテストを実施する必要があります。このテストでは、組織に関連する機能、パフォーマンス、および統合を検証します。各テストは 1 ～ 2 週間かかる場合があり、一連のメトリックが満たされていることを確認します。さまざまな角度からテストしてアプリケーションが本番環境に対応していることを確認する、反復的なプロセスです。これは移行プロセスの最も集中的な部分であり、一般的には、実施に約 3 ～ 6 カ月かかります。
- 調整: ユーザー受け入れテストの結果は、アプリケーションの構成をどのように最適化し、アプリケーションの利用を管理するプロセスをどのように強化すればよいかをチームに指示するのに役立ちます。これにより、組織のプロセスとアプリケーション構成を緊密に組み合わせることができます。
- 文書化: チームはプロセス全体ですべての内容を文書化し、この期間に、インストール、構成、ネットワーク図、アーキテクチャ図、反省点、バグ、解決策、およびアプリケーションに関するその他すべてのことに関するすべてのドキュメントを整理して見直します。
Data Center を本番環境で立ち上げる
- コミット: チームは、テストや調整の結果を使用して、Data Center を本番環境に進める準備が整ったかどうかを評価します。まだであると判断された場合、テストを繰り返して、見直しが必要な部分やギャップを特定します。
- 実行: 一般的、週末や使用率が低い時期に本番環境にプッシュします。ローンチ プロセスをテスト/検証するために「モック デプロイ」を選ぶお客様もいます。このプロセス、エンド ユーザーへの通知の送信を確認します。
- サポート: Data Center アプリケーションを立ち上げ後に監視し、機能やパフォーマンスの問題がないことを確認することは、チームにとって非常に重要です。
Atlassian が提供するサービス
Atlassian のテクニカル アカウント マネージャー (TAM) は、アプリケーションの Data Center への移行に関心のあるお客様に戦略的なガイダンスを提供します。TAM はお客様と協力して、組織の運用や長期的な目標に沿った Data Center を構成、デプロイ、および実行できるベスト プラクティスを構築します。
Atlassian のプレミア サポートは、Data Center への移行プロセスでお客様に 24/7 (24 時間 365 日) のサポートを提供します。また、プレミア サポートでは、お客様の環境の準備レベルを評価するヘルス チェック分析も提供しています。
Atlassian エンタープライズ パートナー は、エンタープライズ組織が Data Center 移行を含めた Atlassian ツールを最大限に活用できるよう、幅広いサービスを提供します。アプリケーション インスタンスを 1 つの Data Center デプロイメントに統合したいお客様には、エンタープライズ パートナーを特におすすめします。
また、Atlassian Community で過去の質問を確認したり新しく質問を追加したりして、Data Center の問題を解決するることもできます。