アップグレードする前にシステムの容量を確認する

GitHub Enterprise Server をアップグレードする前に、これらの容量チェックを行い、推奨される手順を実行する必要があります。

この記事の内容

GitHub Enterprise Server の新しいバージョンにアップグレードすると、通常、リソースの消費量が増えます。 各機能リリースで追加される新機能は、一部は既定で、それ以外はオプトインによって有効になり、より多くの処理能力が必要になります。 お客様の使用パターンも需要に影響します。たとえば、何万もの organization を含む Enterprise では、リソースの使用量が増える可能性があります。

リソースの増加は、多くの場合、CPU 使用率、1 秒あたりの I/O 操作数 (IOPS)、メモリ使用量、または Aqueduct キュー バックログの上昇として表面化します。 これらの変化に備えるには、アップグレードを行う前にシステムで利用できる容量を調べて、推奨される修復を適用します。 最も正確な結果を得るには、日または週を通して最も負荷が大きい時間帯にこれらのチェックを実行します。

リソース要件

インスタンスをアップグレードする前に、必要なリソースの要件をシステムが満たしていることを確認することが重要です。

  1. CPU 使用率が 70% 未満である
  2. メモリ使用率が 70% 未満である
  3. ディスクが飽和していない
  4. Unicorn キューが 200 から 300 未満である
  5. Aqueduct バックログが 1 から 2 時間未満である

CPU 使用率が 70% 未満である

  1. CPU 使用率を調べます。 [Management Console] で、モニター ページ (https://HOSTNAME.com:8443/setup/monitor) に移動して CPU グラフを表示します。

    • 使用率が通常 70% 未満である場合は、メモリの使用状況に進みます。
    • 使用率が通常 70% を超えている場合、システムはアップグレードの条件を満たしていません。

  2. 使用率と CPU 負荷平均を比較します。 この比較は、ディスクの飽和状態の可能性を確認するのに役立ちます。

    • Operational Health ビューに移動して、Load グラフを調べます。

    • マトリックスで、shortterm 行と avg 列の交点の値を見つけます。

    • 負荷平均パーセンテージを計算します。

      (short-term avg ÷ number of vCPUs) × 100

    • 同じビューで、CPU グラフを調べます。 マトリックスで、idle 行と avg 列の交点の値を見つけます。 この値を 100 から引いて使用率を取得します。

  3. 結果を解釈します。

    CPU 負荷平均パーセンテージが使用率より 50% 以上高い場合、これはリソースの競合を示している可能性があります。 ディスクの飽和の可能性を調べるまで、アップグレードを続けないでください (「ディスクが飽和していない」を参照してください)。

メモリ使用率が 70% 未満である

  1. メモリの使用率を調べます。 [Management Console] で、モニター ページ (https://HOSTNAME.com:8443/setup/monitor) に移動して Memory グラフを表示します。

  2. 結果を解釈します。

    • メモリ使用率が通常 70% 未満である場合は、「ディスクが飽和していない」に進みます。
    • メモリ使用率が通常 70% を超えている場合、システムはアップグレードの条件を満たしていません。

ディスクが飽和していない

  1. プロバイダーの仕様を調べます。 クラウドまたはハードウェアのプロバイダーからディスク使用率メトリックが提供されている場合は、それを使ってディスクが飽和状態かどうかを確認します。

    • メトリックを利用できない場合は、最大スループットや最大 IOPS などのディスクの仕様をプロバイダーに要求します。
    • これらの制限を実際のディスク使用量と比べます。 使用量が最大値に近づいている場合、ディスクは飽和状態になっています。

  2. [Management Console] でディスクのグラフを調べます。 モニター ページ (https://HOSTNAME.com:8443/setup/monitor) に移動します。

    • Disk Operations と Disk Traffic のグラフを表示します。
    • Y 軸の値とプロバイダーの仕様を比べます (グラフに表示される最大スケールではありません)。
    • データとルートの両方のディスクを確認します。

    これらのグラフは、[System & Application Insights] ビューで見ることができます。

  3. 結果を解釈します。 ディスク使用量がプロバイダーによって定義された最大値に近づいている場合、ディスクは飽和状態になっています。 この場合、システムはアップグレードの条件を満たしていません。

Unicorn キューが 200 から 300 未満である

  1. キュー内の要求数のグラフを調べます。 [Management Console] で、モニター ページ (https://HOSTNAME.com:8443/setup/monitor) に移動して Queued Requests グラフを表示します。

    このグラフは、[System & Application Insights] ビューで見ることができます。

  2. 結果を解釈します。

    • キュー内の要求の数が常に 200 未満である場合は、「Aqueduct バックログが 1 から 2 時間未満である」に進みます。
    • キュー内の要求の数が通常 200 から 300 以上である場合、システムはアップグレードの条件を満たしていません。

  3. オプション: Unicorn ワーカーの使用率を調べます。 管理シェルから、次を実行します。

    ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git

    出力の最後の列を確認します。 すべてのプロセスで > 90% utilization と示されている場合、さらに多くの unicorn ワーカーが必要です。

Aqueduct バックログが 1 から 2 時間未満である

  1. Aqueduct キューの深さを調べます。 [Management Console] で、モニター ページ (https://HOSTNAME.com:8443/setup/monitor) に移動して Aqueduct queue depth グラフを表示します。

    このグラフは、[System & Application Insights] ビューで見ることができます。

  2. 結果を解釈します。

    • バックログの残存時間が 1 から 2 時間未満の場合、この要件を満たしています。
    • バックログの残存時間が通常 1 から 2 時間より長い場合、システムはアップグレードの条件を満たしていません。

  3. index_high キューを監視します。 大規模なデプロイでは index_high キューの深さが大幅に増加する場合があり、バックログが悪化する可能性があります。 監視するときは、このキューに特に注意してください。

すべての条件 (CPU、メモリ、ディスク、unicorn キュー、Aqueduct バックログ) が満たされている場合は、ターゲットの機能バージョンへのアップグレードに進むことができます。 アップグレードした後は、リソースの消費量がさらに増えるものと思ってください。

いずれかの条件が満たされていない場合は、アップグレードを試みる前に、基になっている問題を解決します。

ハードウェアのアップグレードとワーカーの微調整

システムが 1 つ以上のリソース要件を満たしていない場合は、アップグレードする前に容量を増やす必要があります。 以下のセクションでは、ハードウェア リソースを追加し、ワーカーの構成を調整して、一般的なボトルネックを解決する方法について説明します。

  1. CPU が 70% を超えている
  2. メモリが 70% を超えている
  3. ディスクが飽和している
  4. Unicorn キューが 200 から 300 を超えている
  5. Aqueduct バックログが 1 から 2 時間を超えている

CPU が 70% を超えている

CPU 使用率が常態的に 70% を超えている場合:

  • CPU リソースを増やします。 vCPU を 20% 以上追加します。
  • 新しいワーカーを考慮します。 ワーカーごとに 1 つの vCPU を割り当てます。 たとえば、5 個の unicorn ワーカーと 10 個の Resque ワーカーを追加する場合は、vCPU を少なくとも 15 個増やします。

メモリが 70% を超えている

メモリ使用率が常態的に 70% を超えている場合:

  • メモリを増やします。 RAM を追加して、平均使用率を 70% 未満に減らします。
  • 新しいワーカーを考慮します。 ワーカーごとに 1 GB のメモリを割り当てます。 たとえば、5 個の unicorn ワーカーと 10 個の Resque ワーカーを追加する場合は、メモリを少なくとも 15 GB 増やします。

ディスクが飽和している

ディスク飽和チェックで飽和状態が示された場合は、スループットと最大 IOPS がより高いディスクにアップグレードします。

Unicorn キューが 200 から 300 を超えている

キュー内の unicorn 要求が常に 200 から 300 を超えている場合は、より多くの unicorn ワーカーを追加する必要があります。 次の手順に従って、総ワーカー数の目標を決めて、構成を更新します。

1.追加するワーカーの数を推定する

ピーク時に次のコマンドを実行して、ワーカーごとの使用率を表示します。

ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git

出力例:

git      3048972 3045762  0 Aug01 ?        00:07:47 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[00]: 20491 reqs,  10.8 req/s,   13ms avg,   85.2% util
git      3048979 3045762  0 Aug01 ?        00:07:53 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[01]: 20951 reqs,  12.5 req/s,   13ms avg,   80.3% util
git      3048985 3045762  0 Aug01 ?        00:08:04 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[02]: 21502 reqs,  10.5 req/s,   15ms avg,   76.5% util
git      3048992 3045762  0 Aug01 ?        00:07:45 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[03]: 20249 reqs,  14.2 req/s,   15ms avg,   86.9% util

1 秒間の平均要求数は 12 要求/秒です。

この出力から、1 秒あたりの平均要求数 (要求数/秒) を計算します。

  • 上記の例: 12 要求数/秒。

  • 目標は、キュー内の要求数を 100 以下に減らすことです。

  • 計算式:

    (Queued requests – 100) ÷ avg req/s

  • 例: (280 – 100) ÷ 12 = 15 個のワーカーを追加する必要があります。

    ヒント

    結果を確認したい場合は、GitHub Enterprise サポート にアクセスし、バンドルをアップロードして 目標の unicorn ワーカー総数を要求し、お問い合わせください。

2.現在の構成を確認する

ワーカーの総数 (unicorn + Resque) が vCPU の数を超えないことを確認します。 ワーカーごとに少なくとも 1 つの vCPU を割り当てます。

現在の数を確認します。

  • Unicorn ワーカー

    ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git | wc -l

    計算で得られた新しいワーカーの数をこの値に加えて、目標の総数を取得します。

  • Resque ワーカー

    ps -ef | grep aqueduct-1.1.0 | grep -v "grep aqueduct-1.1.0" | wc -l

3.構成を調整する

Unicorn + Resque ワーカーの合計が vCPU より多い場合は、続ける前に vCPU を追加します。

Unicorn ワーカーの数を更新します。

ghe-config app.github.github-workers <NUM-WORKERS>
ghe-config-apply

を unicorn ワーカーの目標総数に置き換えます。

Aqueduct バックログが 1 から 2 時間を超えている

Aqueduct ジョブが 1 から 2 時間より長くバックログに残るのが常態化している場合は、キュー バックアップのリスクを軽減するために、resqued-low ワーカーを追加します。 アップグレード後にこの問題が悪化することがよくあります。

1.resqued-low ワーカーを追加する

  • ワーカーの数を 5 から 10 個増やします。 CPU の容量に注意してください。ワーカーごとに少なくとも 1 つの vCPU が必要です。
ghe-config app.github.resqued-low-workers <NUM-WORKERS>
ghe-config-apply

を resqued-low ワーカーの新しい総数に置き換えます。

2.ワーカーの総数を検証する

Unicorn + Resque ワーカーの合計数が vCPU の総数を超えないことを確認します。 現在のワーカー構成を調べる手順については、「Unicorn キューが 200 から 300 を超えている」をご覧ください。