Recommendations for running Bitbucket Data Center in AWS

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

デプロイ方法としての AWS クイック スタート テンプレートはアトラシアンではサポートされなくなりましたテンプレートは今後も利用できますが、保守や更新は行われません。

より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをお勧めします。Kubernetes へのデプロイに関する詳細はこちらをご確認ください。

AWS は、現在、AWS クイック スタート テンプレートで使用される起動設定を起動テンプレートに切り替えることを推奨していますが、AWS クイック スタート テンプレートのサポートは終了しているため、アトラシアンではこの切り替えを行う予定はありません。そのため、このテンプレートを使用して起動設定を作成することはできません。

ご自身のインスタンスの負荷プロファイルを把握しておくことは、インスタンスの成長を計画したり、メトリクスの増長を確認したり、インスタンスを適切なサイズに保ったりするのに役立ちます。Bitbucket Data Center サイズ プロファイルでは、インスタンスが "Small"、"Medium"、"Large"、または "XLarge" のどれに該当するかを確認するためのシンプルなガイドラインを示しています。これらのサイズ プロファイルはさまざまな Server および Data Center のケース スタディに基づいており、あらゆるインフラストラクチャ サイズおよび構成を網羅しています。

特に高可用性が不要な場合には、"Small" または "Medium" サイズのデプロイでは単一ノードが適切だといえます。 
既存の Server インストールがある場合は、Data Center にアップグレードする際にそのインフラストラクチャを引き続き使用できます。Data Center 専用の多くの機能 (SAML シングル サインオンレート制限によるシステムの保護CDN サポートなど) では、クラスタ インフラストラクチャは不要です。Server インストールのライセンスをアップグレードするだけで、Data Center のこれらの機能の使用を開始できます。
tip/resting Created with Sketch.

クラスタ化が必要かどうかの詳細については「Data Center のアーキテクチャとインフラストラクチャのオプション」をご参照ください。

負荷が増加して "Large" または "XLarge" サイズに近づいてきたら、定期的にインフラストラクチャを評価する必要ががあります。環境内でパフォーマンスや安定性の問題が発生し始めたら、クラスタ (またはクラスタ対応) インフラストラクチャへの移行を検討します。これを行う際は、効果的に行うための方法は常に明確であるとは限らないということに注意します。たとえば、成長しつつある "Medium" サイズのインスタンスにアプリケーション ノードを追加してもパフォーマンスが向上するとは限りません (低下する場合もあります)。 

アトラシアンではお客様によるインフラストラクチャの設定または成長の計画立案をサポートするため、一般的な "Medium"、"Large" および "XLarge" サイズのインスタンスで一連のパフォーマンス テストを実施しました。これらのテストは、ご利用のクラスタ化されたデプロイメントのアプリケーションおよびデータベース ノードに有用なデータ主導の推奨事項を確認できるように設計されています。これらの推奨設定は、プロジェクト化されたコンテンツおよびトラフィックのサイズに合った適切なクラスタ化環境の計画に役立てることができます。

大規模なリポジトリはパフォーマンスに影響を与える可能性がある点にご注意ください。

定期的にパフォーマンスを監視することをおすすめします。

アプローチ

すべてのテストを AWS 環境で実施しました。これにより、複数のテストを簡単に定義および自動化し、大規模で信頼性の高いテスト結果のサンプルを取得することができます。

テスト インフラストラクチャの各部分は、すべての AWS ユーザーが利用できる標準の AWS コンポーネントからプロビジョニングされています。つまり、お客様はアトラシアンの推奨設定を簡単にデプロイすることができます。また、AWS ドキュメントで仕様を確認できます。お客様の組織が別のクラウド プラットフォームまたは特注のクラスタ ソリューションを使用することを希望している場合、ここで同等のコンポーネントや構成を見つけることができます。 

Bitbucket Data Center デプロイ用 AWS クイック スタートを使用することもできますが、アトラシアンではクイック スタート テンプレートのサポートや保守を終了しています。代わりに、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをおすすめしています Kubernetes へのデプロイについて詳しくはこちらをご確認ください。

考慮事項

幅広い構成で Bitbucket のベンチマーク テストを効果的に行うため、テストは簡単にセットアップしてレプリケートできるよう設計されています。ご利用の本番環境と弊社のベンチマークを比較する場合、次の点を考慮してください。

  • コア製品に最適な設定を見つけることに焦点を当てていたため、テスト インスタンスへのアプリのインストールは行っていません。お客様のインフラストラクチャを設計する際には、インストールしたいアプリが与える影響を考慮する必要があります。

  • すべてのテストにおいて、RDS を既定設定で使用しました。これにより、最小限のセットアップと調整で一貫した結果を実現できます。

  • アトラシアンのテスト環境では、同じサブネット上でホストされている専用の AWS インフラストラクチャを使用しています。これによりネットワーク遅延を短縮できます。

  • アトラシアンでは Trikit という内部テスト ツールを使用して、git パケットの流入のシミュレーションを実施しました。これにより、クライアント側の git パフォーマンスを測定しなくても、git リクエストの速度を測定しました。また、ツールは git データを受信して復号化するだけなので、テストでは git refs を解凍していません。

  • git 操作のパフォーマンス (応答時間) は、リポジトリ サイズの影響を大きく受けます。アトラシアンのテスト リポジトリのサイズは平均 14.2 MB でした。リポジトリのサイズが大きくなると、より性能に優れたハードウェアが必要になる可能性があることが推測されます。

  • AWS の制限により、テストを開始する前に NFS サーバー上の EBS ボリューム (ストレージ ブロック) を初期化しました。ディスクを初期化しない場合、ディスクの遅延が大幅に増加し、テスト インフラストラクチャのパフォーマンスが数時間低下します。

    各テスト インスタンスで分析を有効化し、使用状況データを収集しました。詳しくは、「データ収集設定の変更」を参照してください。

    テスト手法

    各テストでは、異なる AWS 環境にある Bitbucket データ セットに同じ量のトラフィックを適用しました。次のコンポーネントに最適な構成を見つけるために設計された、3 つの一連のテストを実行しました。

    • Bitbucket アプリケーション ノード

    • データベース ノード

    • NFS ノード

    ベンチマークの信頼性を確保するため、EBS ボリュームを初期化し、各構成を 3 時間テストしました。各テストを通じて、安定した応答時間を確認しました。Large インスタンスのテストには Bitbucket Data Center 5.16 を使用し、XLarge には Bitbucket Data Center 6.4 を使用しました。v1 プロトコルを実行しているカスタム ライブラリ (Trikit) を使用して Git トラフィックのシミュレーションを行いました。

    データセット

    "Large" サイズのインスタンス

    次のディメンションを持つ "Large" サイズの Bitbucket Data Center インスタンスを作成しました。

    メトリック

    値 (概数)

    リポジトリ

    52,000

    アクティブ ユーザー数

    25,000

    プル リクエスト

    850,000

    トラフィック (1 時間あたりの git 操作)

    40,000

    コンテンツとトラフィック プロファイルは「Bitbucket Data Center 負荷プロファイル」に基づき、インスタンスの全体的な負荷プロファイルを "Large" プロファイルの上限レベルに含めるようにしています。これらのメトリックは、実際に使用されている "Large" サイズの Bitbucket Data Center インスタンスの大部分を表すことを意図しています。

    メトリック

    値 (概数)

    ユーザー

    25,000

    グループ

    50,000

    プロジェクト (個人用を含む)

    16,700

    プル リクエストへのコメント

    3,500, 000

    メトリック

    合計

    コンポーネント

    値 (概数)

    合計リポジトリ数

    52,000

    標準リポジトリ

    26,000

    パブリック フォーク

    9,000

    プライベート リポジトリ

    17,000

    プル リクエストの合計数

    859,000

    オープンなプル リクエスト

    8,500

    プル リクエストのマージ

    850,000

    トラフィック

    (1 時間あたりの git 操作)

    40,000

    Clones

    16,000

    フェッチ

    14,000

    Pushes

    10,000

    "XLarge" サイズのインスタンス

    次のディメンションを持つ "XLarge" サイズの Bitbucket Data Center インスタンスを作成しました。

    メトリック

    値 (概数)

    リポジトリ

    110,000

    アクティブ ユーザー数

    50,000

    プル リクエスト

    1,790, 000

    トラフィック (1 時間あたりの git 操作)

    65,000

    コンテンツとトラフィック プロファイルは「Bitbucket Data Center 負荷プロファイル」に基づき、インスタンスの全体的な負荷プロファイルを "XLarge" プロファイルに置いています。これらのメトリックは、実際に使用されている "XLarge" サイズの Bitbucket Data Center インスタンスの大部分を表すことを意図しています。

    メトリック

    値 (概数)

    ユーザー

    25,000

    グループ

    3,000

    プロジェクト (個人用を含む)

    52,000

    プル リクエストへのコメント

    8,700, 000

    メトリック

    合計

    コンポーネント

    値 (概数)

    合計リポジトリ数

    105,000

    標準リポジトリ

    52,000

    パブリック フォーク

    17,000

    プライベート リポジトリ

    35,000

    プル リクエストの合計数

    1,790, 000

    オープンなプル リクエスト

    130,000

    プル リクエストのマージ

    1,660, 000

    トラフィック

    (1 時間あたりの git 操作)

    70,000

    Clones

    18,700

    フェッチ

    25,300

    Pushes

    26,000


    ベンチマーク

    テストでは、次のベンチマーク メトリックを使用しました。

    ベンチマーク メトリック

    しきい値

    理由

    Git スループット、または 1 時間あたりの git ホスティング操作 (フェッチ / クローン / プッシュ) の数

    Large の場合は 32,700 (最小)

    XLarge の場合は 65,400 (最小)

    高いほうがよい

    これらのしきい値は、Bitbucket Data Center の負荷プロファイルで定義されたトラフィックの上限です。git トラフィックがスパイクしやすいことを受け、これらの上限を設定しました。

    平均 CPU 使用率 (アプリケーション ノードの場合)

    75% (最大)、低いほうがよい

    アプリケーション ノードの平均 CPU 使用率が 75 % 以上に達すると、Bitbucket のアダプティブ スロットリングは、対話型ユーザー向けのアプリケーションの応答性を確保するために、Git のホスティング操作のキューイングを開始しますこれにより、Git の速度が低下します。

    安定性

    オフラインになるノードがない

    インフラストラクチャが負荷の処理に不十分な場合、ノードがクラッシュする可能性があります。

    テスト トラフィックでは、git ホスティング操作の量を調節するために、スリープ時間を固定しました。つまり、ベンチマークされた git スループットは、各構成で処理できる最大値を表すものではありません。

    アーキテクチャ

    各構成は、AWS 上に新しくデプロイされた Bitbucket Data Center インスタンスでテストされました。各構成は次の共通の構造にしたがっています。

    機能

    ノードの数

    仮想マシンのタイプ

    注意

    アプリケーション ノード

    変数

    m5.xlarge

    m5.2xlarge

    m5.4xlarge

    m5.12xlarge

    m5.24xlarge

    m5.xlarge (16 GB の RAM) のテストでは、8 GB の JVM ヒープを使用しました。それ以外では 12 GB の JVM ヒープを使用しました。最大ヒープ数 (Xms) はすべてのテストで 1 G に設定しました。

    ほとんどのインスタンスでは、小規模な JVM ヒープ (2 ~ 3 GB) の使用で十分であることを確認しています。

    また、Git 操作はメモリの消費量が多く、Java 仮想マシンの外部で実行されることにご注意ください。Bitbucket Data Center のスケーリングの詳細を参照してください

    各 Bitbucket アプリケーションおよびでローカル ストレージに 30 GB の汎用 SSD (gp2) を使用しました。このディスクには EBS ボリュームが接続されており、ベースラインは 100 IOPS で、3,000 IOPS まで拡張可能です。

    データベース

    1

    m5.xlarge

    m5.2xlarge

    m5.4xlarge

    Amazon RDS Postgresql バージョン 9.4.15 を既定設定で使用しました。各テストは 1 つのノードのみを対象としました。

    NFS ストレージ

    1

    m5.4xlarge

    m5.2xlarge

    m5.xlarge

    NFS サーバーでは、ストレージに 900 GB の汎用 SSD (gp2) を使用しました。このディスクには EBS ボリュームが接続されており、ベースラインは 2700 IOPS で、3,000 IOPS まで拡張可能です。前述のように、各テストの開始時にこのボリュームを初期化しました。

    Bitbucket Data Center の共有ファイル サーバーのセットアップの詳細については、「Bitbucket Data Center のインストール」の「ステップ 2. 共有ファイル システムのプロビジョニング」をご覧ください。このセクションでは、Bitbucket Data Center 用の NFS のセットアップの要件や推奨事項について説明しています。

    Load balancer

    1

    AWS アプリケーション ロード バランサ (ELB)

    AWS Elastic Load Balancer を使用しました。パフォーマンス テスト時、アプリケーション ロード バランサでは SSH トラフィックを処理していません。

    各コンポーネントに最適な構成を見つけるため、実際の "Large" および "XLarge" サイズの Bitbucket Data Center インスタンスで複数のケース スタディを実施しました。特に m5 シリーズの仮想マシン タイプ (汎用インスタンス) が多く使用されていることを確認したため、アプリケーション ノードではさまざまなシリーズの構成のベンチマークに重点を置きました。

    アトラシアンのテストで使用されたそれぞれの仮想マシンタイプの詳細についてはインスタンス タイプの AWS ドキュメント(特に「汎用インスタンス)をご参照ください。

    "Large" サイズのインスタンスの推奨設定

    アトラシアンではベンチマークを分析し、次の最適構成を導きました。

    パフォーマンスと費用対効果が最も高い構成 

    コンポーネント

    推奨事項

    Application nodes

    m5.4xlarge ノード x 4

    データベース ノード

    m5.2xlarge

    NFS ノード

    m5.2xlarge

    この構成のパフォーマンス

    • Git スループット: 45,844 /時間

    • 1 時間あたりのコスト 1: $4.168

    • 平均 CPU 使用率: 45%

    1 "Large" サイズ プロファイルの推奨設定において、各構成の1 時間あたりのコストを見積もりました。この情報は、各構成での価格の比較を支援するために提供されます。このコストは、Bitbucket アプリケーションとデータベース、および NFS ノードに使用したノードの価格のみを計算します。アプリケーションのその他のコンポーネント (共有ホーム、アプリケーション ロード バランサなど) の使用コストは含まれません。

    これらの金額は USD で、2019 年 7 月時点の値です。

    パフォーマンスの安定性は、インスタンスの平均 CPU 使用率がしきい値である 75 % からどの程度逸脱しているかで測定しました。前述のように、このしきい値に達すると、git 操作の速度が低下し始めます。インスタンスが 75 % から低下するとそれだけ、トラフィックのスパイクによって速度が低下する可能性が低くなります。

    ただし、より優れたパフォーマンスを提供する、大きなサイズのハードウェア (m5.12xlarge など) を使用することによるデメリットはありません。

    低コスト構成

    また、1 時間あたり $2.84 で許容可能なパフォーマンスを提供する低コスト構成も導きました。

    コンポーネント

    推奨事項

    Application nodes

    m5.4xlarge x 3

    データベース ノード

    m5.xlarge

    NFS ノード

    m5.xlarge

    この低コスト構成では、1時間あたりの git ホスティング呼び出しが 43,099 回となり、最適な構成よりも Git スループットが低くなります。それでも、1時間あたりの git ホスティング呼び出しが 32,700 回の最低しきい値を上回っています。コストのトレードオフになるのはフォールト トレランスです。インスタンスで 1 つのアプリケーション ノードが失われると、CPU 使用率は 85%に急上昇し、最大しきい値を超えます。インスタンスは存続しますが、パフォーマンスは低下します。

    推奨設定の詳細

    次の表は、しきい値である 1 時間あたり 32,500 の git ホスティング操作を超え、CPU 使用率が 75% を下回り、ノードのクラッシュが発生しなかったすべてのテスト構成を示しています。各構成をスループットの降順に並べました。

    Application nodes

    データベース ノード

    NFS ノード

    Git スループット

    1 時間あたりのコスト

    m5.4xlarge x 6

    m5.4xlarge

    m5.4xlarge

    46,833

    6.800

    m5.12xlarge x 2

    m5.4xlarge

    m5.4xlarge

    45,848

    6.792

    m5.4xlarge x 4

    m5.4xlarge

    m5.4xlarge

    45,844

    5.264

    m5.2xlarge x 8

    m5.4xlarge

    m5.4xlarge

    45,626

    5.264

    m5.4xlarge x 3

    m5.4xlarge

    m5.4xlarge

    44,378

    4.496

    m5.4xlarge x 3

    m5.2xlarge

    m5.4xlarge

    43,936

    3.784

    m5.2xlarge x 6

    m5.4xlarge

    m5.4xlarge

    43,401

    4.496

    m5.4xlarge x 3

    m5.xlarge

    m5.xlarge

    43,099

    2.840

    m5.4xlarge x 3

    m5.xlarge

    m5.4xlarge

    43,085

    3.428

    確認できるように、アプリケーションに対して m5.4xlargex 4 ノードを使用する構成では、最高の git スループットにはなりません。ただし、高スループットの構成ではより多くのコストがかかり、パフォーマンスもわずかしか向上しません。

    XLarge インスタンスの推奨設定

    アトラシアンではベンチマークを分析し、次の最適構成を導きました。


    パフォーマンスが最も高い構成

    コンポーネント

    推奨事項

    Application nodes

    m5.12xlarge x 4

    データベース ノード

    m5.2xlarge

    NFS ノード

    m5.2xlarge

    この構成のパフォーマンス

    • Git スループット: 75,860 /時間

    • 1 時間あたりのコスト 1: $10.312

    • 平均 CPU 使用率: 65%

    パフォーマンスの安定性は、インスタンスの平均 CPU 使用率がしきい値である 75 % からどの程度逸脱しているかで測定しました。前述のように、このしきい値に達すると、git 操作の速度が低下し始めます。インスタンスが 75 % から低下するとそれだけ、トラフィックのスパイクによって速度が低下する可能性が低くなります。

    1 "XLarge" サイズ プロファイルの推奨設定において、各構成の1 時間あたりのコストを見積もりました。この情報は、各構成での価格の比較を支援するために提供されます。このコストは、Bitbucket アプリケーションとデータベース、および NFS ノードに使用したノードの価格のみを計算します。アプリケーションのその他のコンポーネント (共有ホーム、アプリケーション ロード バランサなど) の使用コストは含まれません。

    これらの金額は USD で、2019 年 7 月時点の値です。

    低コスト構成

    また、1 時間あたり $7.02 で良好なパフォーマンスを提供する低コスト構成も導きました。

    コンポーネント

    推奨事項

    Application nodes

    m5.8xlarge x 4

    データベース ノード

    m5.2xlarge

    NFS ノード

    m5.xlarge

    この低コスト構成では、1時間あたりの git ホスティング呼び出しが 74,275 回となり、最適な構成よりも Git スループットが低くなります。それでも、1 時間あたりの git ホスティング呼び出しが、しきい値である 65,400 回を上回っています。コストのトレードオフになるのはフォールト トレランスです。m5.8xlargex 3 ノードではタイムアウトやエラーが観察されたため、アプリケーション ノードがダウンするとパフォーマンスが低下する可能性があります。

    次の表は、しきい値である 1 時間あたり 32,500 の git ホスティング操作を超え、CPU 使用率が 75% を下回り、ノードのクラッシュが発生しなかったすべてのテスト構成を示しています。各構成をスループットの降順に並べました。

    Application nodes

    データベース ノード

    NFS ノード

    Git スループット

    1 時間あたりのコスト

    m5.12xlarge x 4

    m5.2xlarge

    m5.2xlarge

    75,860

    $10.31

    m5.4xlarge x 8

    m5.2xlarge

    m5.2xlarge

    73,374

    $7.24

    m5.8xlarge x 4

    m5.2xlarge

    m5.xlarge

    74,275

    $7.02

    m5.4xlarge x 6

    m5.2xlarge

    m5.2xlarge

    71,872

    $5.70

    m5.12xlarge x 3

    m5.2xlarge

    m5.2xlarge

    66,660

    $8.01


    アプリケーション ノードのテスト結果

    Large サイズのインスタンス

    最初のテスト シリーズでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけることに焦点を当てました。これらのテストでは、データベースに 1 つの m4.4xlarge ノード、NFS サーバーに 1 つの m4.4xlarge ノードを使用しました。

    ベンチマークを見ると、m5.4xlarge (16 CPU) および m5.12xlargeノード (46 CPU) を使用した場合に最高の git スループットが実現されています。m5.4xlarge には 3 つ以上のノード、m5.12xlarge には 2 つのノードが必要です。

    次のアプリケーション ノード構成では、CPU の利用率は 30 % に過ぎません。

    • m5.4xlarge x 6

    • m5.12xlarge x 2

    これは、両方の構成がオーバープロビジョニングされていることを示しています。アプリケーションには 3 つまたは 4 つの m5.4xlarge ノードを使用するほうが費用対効果が高くなります

    ただし、3 ノードの m5.4xlarge のセットアップでは、いずれかのノードで不具合が発生した場合、CPU 使用量は ~85 % になります。このため、フォールト トレランスを向上させるために、4 ノードの m5.4xlargeのセットアップを使用することをおすすめします。

    XLarge サイズのインスタンス

    最初のテスト シリーズでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけることに焦点を当てました。これらのテストでは、データベースに 1 つの m4.2xlarge ノード、NFS サーバーに 1 つの m4.2xlarge ノードを使用しました。

    ベンチマークを見ると、m5.12xlarge (48 CPU) および m5.8xlargeノード (32 CPU) を使用した場合に最高の git スループットが実現されています。どちらのインスタンス タイプにも 4 つのノードが必要となります。

    2 ノード (96 CPU) でもパフォーマンス テストを実施しましたが、パフォーマンスが低く、しきい値を満たすことができませんでした。テスト結果により、2 ノードのデプロイメントは XLarge の負荷に適していないことがわかりました。2 ノードのテストではカーネルでの所要時間が大きくなりましたが、4 つ以上のノードの場合はそれほどではありませんでした。

    データベース ノードのテスト結果


  • Large サイズのインスタンス

    アプリケーション ノードの一連のテストにより、アプリケーションに 3 つの m5.4xlarge ノードを使用すると、最もフォールト トレランスな状態ではないが、最適なパフォーマンスを実現できることがわかりました。2 度目の一連のテストでは、データベースで次の仮想マシン タイプに対してこの構成をテストしました。

    • m4.large

    • m4.xlarge

    • m4.2xlarge

    • m4.4xlarge

    予想どおり、性能の良い仮想マシンを使用するほど、パフォーマンスが向上します。CPU 使用率が最も大きく向上し、Git のスループットはわずかに向上しました。


    m5.large のみが CPU 使用率のしきい値に到達しませんでした。テストした他のすべての仮想マシン タイプは許容範囲内でしたが、m5.xlarge は CPU 使用率のしきい値である 60 % に非常に近い値を示しました。

    XLarge サイズのインスタンス

    アプリケーション ノードの一連のテストにより、アプリケーションに 4 つの m5.12xlarge ノードを使用すると、最適なパフォーマンスを実現できることがわかりました。2 度目のテスト シリーズでは、データベースで次の仮想マシン タイプに対してこの構成をテストしました。

    • m4.xlarge

    • m4.2xlarge

    • m4.4xlarge

    m4.xlarge は CPU 使用率が 100 % に達し、db.m4.4xlarge はパフォーマンスが向上しませんでした。このため、XLarge の負荷においても m4.2xlarge が推奨インスタンス タイプとなります。CPU 使用率は m4.2xlarge では ~ 40 % でした。


    NFS ノードのテスト結果

    Large サイズのインスタンス

    以前のテスト (異なるアプリケーションとデータベース ノードの構成をベンチマークとして使用したテスト) では、m5.4xlarge を NFS ノード (NFS プロトコル v3) に使用しました。これらの各テストの間、NFS ノードの CPU 使用率は 18 % 以下に過ぎませんでした。NFS サーバーをダウングレードできるかどうかを確認するため (そして、よりコスト効率の高い推奨設定を見つけるため)、テストをさらに実施しました。結果は、ダウンサイズした m5.xlarge NFS ノードを使用した場合と同一の git スループットを示しました。これにより、低コストの推奨設定を導きました。

    コンポーネント

    推奨事項

    Application nodes

    m5.4xlarge x 3

    データベース ノード

    m5.xlarge

    NFS ノード

    m5.xlarge

    前述のように、この推奨設定のコストは 1 時間あたり $3.044 ですが、フォールト トレランスは低くなります。

    他のテスト結果に基づき、NFS ノードには、IOPS 1500 以上を実現する m5.xlarge 以上を使用することをおすすめします。

    XLarge サイズのインスタンス

    XLarge サイズのテストのベンチマークではすべて、m5.2xlarge を NFS インスタンスに使用しました。これらの各テストの間、NFS ノードの CPU 使用率は 25 % 以下に過ぎませんでした。NFS サーバーをダウングレードできるかどうかを確認するため (そして、よりコスト効率の高い推奨設定を見つけるため)、テストをさらに実施しました。結果は、ダウンサイズした m5.xlarge NFS ノードを使用して CPU 使用率 60 % を実現した場合と同一の git スループットを示しました。

    これにより、低コストの推奨設定を導きました。


    コンポーネント

    推奨事項

    Application nodes

    m5.8xlarge x 4

    データベース ノード

    m5.2xlarge

    NFS ノード

    m5.xlarge

    ディスク I/O


    Large サイズのインスタンス

    ディスク I/O のパフォーマンスは制限要因となることが多いため、ディスクの使用率にも注意を払いました。テストでは、NFS ノードに使用した次のディスク仕様がトラフィックに適切であったということがわかりました。

    • ストレージ用に 900 GB の汎用 SSD (gp2)

    • IOPS:

      • 2700 IOPS のベースライン

      • 3,000 IOPS にバースト可能

    前述のように、各テストの開始時にこのボリュームを初期化しました。

    IOP 要件は使用パターンによって異なるため、この情報はガイドラインにすぎないことに注意してください。

    次の表は、NFS ノードのディスクにおけるテストの I/O への影響を示しています。

    メトリック

    合計スループット (読み取り + 書き込みスループット)

    1,250 IOPS

    読み取りスループット

    700 IOPS

    書き込みスループット

    550 IOPS

    読み取り帯域幅

    100 MB/s

    書き込み帯域幅

    10 MB/s

    平均キュー長

    1.3

    平均読み取りレイテンシ

    1.5 ms/op

    平均書き込みレイテンシ

    0.6 ms/op

    ディスク使用率

    45%

    XLarge サイズのインスタンス

    ディスク I/O のパフォーマンスは制限要因となることが多いため、ディスクの使用率にも注意を払いました。テストでは、NFS ノードに使用した次のディスク仕様がトラフィックに適切であったということがわかりました。

    • ストレージ用に 1800 GB の汎用 SSD (gp2)

    • IOPS: 4500 IOPS のベースライン

    前述のように、各テストの開始時にこのボリュームを初期化しました。

    IOP 要件は使用パターンによって異なるため、この情報はガイドラインにすぎないことに注意してください。

    メトリック

    合計スループット (読み取り + 書き込みスループット)

    9,00 IOPS

    読み取りスループット

    2,700 IOPS

    書き込みスループット

    IOPS

    読み取り帯域幅

    113 MB/s

    書き込み帯域幅

    15 MB/s

    平均キュー長

    3.5

    平均読み取りレイテンシ

    1.0 ms/op

    平均書き込みレイテンシ

    0.70 ms/op

    ディスク使用率

    80%

    平均ディスク使用率は 80 % と高くなっていますが、読み取りと書き込みのレイテンシは 1 ms/op 未満と低くなっていました。NFS サーバーのディスクはボトルネックとならないよう、4500 IOPS 以上にすることをおすすめします。

最終更新日 2019 年 9 月 2 日

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

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