Atlassian Data Center のノード サイズの概要

Data Center アプリケーションを構成する際に最も重要なのは、パフォーマンス要件を満たすようにクラスター内のアプリケーション ノードのサイズを設定することです。クラスター内のノードの数とサイズは、ニーズや、アプリケーションの構成方法によって異なります。ただし、ノードのサイズ設定へのアプローチの開始点として使用できる記事がいくつかあります。ハードウェアを構成する際に最も重要なのは、選択したハードウェア構成でアプリケーションをテストし、その選択がパフォーマンスのニーズを満たしているかどうかを確認することです。Confluence Data Center および Bitbucket Data Center の場合、Atlassian パフォーマンス テスト フレームワーク を使用できます。Jira Data Center でのパフォーマンス テスト用としては、これらのツールが用意されています。

Jira Data Center でのリソースのサイズ設定

Jira サイズ設定ガイドは、単一ノードで、ユーザー、課題、カスタム フィールド、ワークフローなどの数に基づいてサイズ設定にアプローチする方法についてのガイダンスを提供します。この情報は、各ノードに必要な CPU のタイプや RAM の量について把握するための良い出発点となります。

  • 2 ノードの Jira Data Center クラスターの場合、上記のサイズ設定ガイドを使用してノード サイズを見積もることをお勧めします。これらの見積もりでは、1 つのノードが失敗した場合に他のノードが負荷を処理してアプリケーションが操作を続行するための十分な容量を提供します。
  • 2 ノード以上のクラスターの場合、少ないメモリや速度の遅い CPU でノードの構成を使用できる場合があります。ただし、1 つのノードが失敗した場合に、予測される負荷を残りのクラスターで処理できるための十分な容量を確保することは、引き続き重要です。詳細は、「クラスター化された Jira 環境でのノードのサイズ設定」をご覧ください。

Confluence Data Center

Confluence Data Center の場合、サーバーには、Confluence アプリケーションと、メモリや CPU に負荷のかかるタスクを処理する外部プロセス プール用に十分な RAM が必要です。Synchrony が Confluence と同じノードで実行されている場合、共同編集用に Synchrony のための追加 RAM を許可する必要があります。メモリ要件の完全な概要については、「Confluence Data Center の技術的概要」を参照してください。

Confluence Data Center のノード サイズを見積もる際には、Confluence Server と同じ見積もりガイドラインを使用することをお勧めします。また、ノード間で信頼できるネットワーク通信を確保する必要があります。各ノードに 2 つの物理ネットワーク インターフェイス カード (NIC) を使用することが理想的です。1 つのネットワーク カードがユーザー リクエストを分散し、もう片方はノード間通信を管理します。Confluence ノードのサイズ設定へのアプローチ方法を理解するには、「Confluence Server ハードウェア要件ガイド」を参照してください。

デプロイを予定しているインスタンスのサイズが "Large"、または "XLarge" の場合、「エンタープライズ規模の Confluence インスタンスの推奨インフラストラクチャ」をお読みください。ここでは、包括的なパフォーマンス テストによって裏付けされた推奨 AWS インフラストラクチャ構成を提供します。

Bitbucket Data Center

次のガイドと記事では、ノード サイズを計算する際に、git の同時操作の数が CPU の数や RAM の量に及ぼす影響について説明します。実際の動作は組織の使用状況によって異なるため、これらの計算に基づいて環境をテストすることが重要です。たとえば、多数の git clone 操作を使用する組織と、git clone の使用頻度が少ない同規模の組織では、必要なリソースが異なる場合があります。

クラスターに含めるおおよそのノード数は、単一のノードが処理できる git の同時操作の数と、組織全体でサポートする必要がある操作数に基づいて見積もることができます。たとえば、40 の git 同時操作をサポートする 1 つのノードがあり、200 の git 同時操作をサポートする必要がある場合、Data Center デプロイメントはこのようなノードを 5 つ構成する必要があります (40 x 5 = 200)。ただし、ノードの追加は、ノード間で必要な通信の量も増やします。そのため、多数の低出力ノードではなく、少数の高出力ノードを使用した環境をお勧めします。ニーズをサポートする最適のオプションを決定する際には、両方のタイプのクラスターをテストすることをおすすめします。

Bitbucket Data Center に関する追加情報については、拡張を考慮した構築についてのブログ投稿を参照してください。

AWS にデプロイする Bitbucket Data Center のインスタンス サイズに関する詳細については、AWS で Bitbucket を実行する際の推奨事項をご覧ください。

Hipchat Data Center

Hipchat Data Center は、アプリケーションを使用するユーザーの数や、組織が高可用性 (HA) を必要とするかどうかに応じて、3 つの構成をサポートします。HA クラスターをすばやくデプロイするために、追加で AWS CloudFormation オプションを利用できます。また、独自の AWS デプロイメントを構築できる場合、サイズ設定情報も利用できます。サイズ設定やデプロイメントに関する詳細は、「Hipchat Data Center のデプロイメント オプションとサイズ設定ガイドライン」をお読みください。

AWS EC2 インスタンス タイプの選択

AWS における Jira Data Center、Confluence Data Center、および Bitbucket Data Center アプリケーション ノードの既定の EC2 インスタンス タイプは c3.xlarge です。インスタンス タイプは自由に選択できますが、サイズ設定ガイドに記載されているように、各製品のシステム要件を満たすように選択する必要があります。また、アプリケーション ノードとして T2 インスタンス タイプを使用しないことが重要です。T2 インスタンスは本番環境には不十分です。本番環境で使用すると、パフォーマンスの問題や障害が発生する場合があります。

Atlassian が提供するサービス

Atlassian テクニカル アカウント マネージャーは戦略的ガイダンスを提供し、お客様のハードウェア構成が組織のオペレーションニーズや長期的な目標を満たすよう、お客様とコラボレーションを行います。

Atlassian のプレミア サポート チームは、お客様のアプリケーションのデプロイメントがユーザーのニーズを完全に満たしていることを確認するためにヘルス チェックを実行し、アプリケーションとログを慎重に分析します。ヘルス チェックによってパフォーマンスのギャップが判明した場合、プレミア サポートがお客様のハードウェア構成で実施可能な変更を提案いたします。


最終更新日 2019 年 4 月 4 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.