サーバーを増やしても短くならない処理がある：直列時間と仕事量から考える増設判断

仮に、一つの計算に100分かかるとします。四台で分担したところ40分になったので、次は八台、十六台に増やせば、締切をもっと前にできるはずだ。ところが増やすほど短縮幅が小さくなる。使っている台数は増えたのに、最後の処理だけが長く残っている。

この場面では、増設の性能倍率だけでなく、分担できない時間が何分あるかが判断を変えます。同じ計算を早く終えることと、同じ時間で大きな計算をすることも分ける必要があります。ここでは一つの計算ジョブを対象に、締切と一件あたりの費用から増設の境界を考えます。

全体を分担できるとは限らない

各部分を同時に計算できても、前の結果がそろわなければ始められない処理は残ります。例えば、最後に結果を一つに統合して整合性を確認する実装です。同じ入力から同じ品質の結果を得る条件のもとで、この部分を一つの処理単位で順番に実行しているなら、分担する計算機だけを増やしても、その時間は短くなりません。

Gene Amdahlの1967年論文は、並列計算の性能を考える際に、順番に進める処理や問題の不規則さを無視できないと論じました。IEEEが2007年に再掲した原論文本文では、データ管理の処理などが制約として挙げられています。1960年代の機械を対象とする議論であり、そこで示された割合を現在の業務システムへそのまま当てはめることはできません。

以下の計算は、原論文の実測値ではありません。直列部分と分担可能な部分の違いを説明するため、通信や分担の偏りを除いて単純化した仮想例です。利用者の依頼が集中して待つ問題は、平均負荷が低いのに遅い場合の記事で扱っています。ここで測るのは、実行を始めた一つのジョブが終わるまでの時間です。

20分が残るなら、増設だけで15分にはできない

同じ性能の計算機一台では、直列処理に20分、分担できる処理に80分、合計100分かかるとします。直列処理は一台で実行し、並列部分はN台へ均等に分けられるという仮定です。入力、必要な出力、計算の精度は変えません。

このとき、N台での所要時間は「20＋80÷N」分です。四台なら20＋20で40分。八台なら20＋10で30分。十六台なら20＋5で25分になります。一台の100分を割ると、性能倍率はそれぞれ2.5倍、約3.33倍、4倍です。四台から八台へ倍増しても、40分が20分になるわけではありません。

台数をどこまでも増やしても、直列の20分は残ります。この仮定の性能倍率は5倍へ近づきますが、有限の台数では20分にも届きません。必要な締切が15分なら、並列部分を担当する台数の追加だけでは満たせないと分かります。

では費用はどうでしょうか。仮に一台一分10円で、開始から終了まで全台を確保して支払うとします。起動時間、最低課金、通信、ソフトウェアの利用料は含めません。

費用は「台数×所要時間×10円」です。締切が35分以内、予算が一件3,000円以内なら、表の選択肢では八台が両方を満たします。十六台はさらに5分早いものの、予算を超えます。この比較は、最も速い構成を選ぶことと、必要な締切を予算内で満たすことが違うと示しています。

ただし、速い構成ほど総額が高いとは限りません。AWSの2022年のCFD資料は、ライセンス費用を含めると最も速い実行が最も安くなる場合もあると説明しています。例えば仮に、ジョブ全体に台数と無関係な一分400円の利用料が追加されるなら、八台の総額は2,400＋30×400＝14,400円、十六台は4,000＋25×400＝14,000円です。計算機の費用だけの大小と逆になります。400円は実際の契約価格ではなく、課金条件が判断を変える例です。

直列処理中に使わない台を解放できる契約なら、この費用計算は変わります。クラウドの資源を止められる条件や残る契約費用は、費用が減らない理由を調べる記事をご参照ください。ここでは全台を確保し続ける条件に限定しています。

同じ時間に大きな仕事をした結果と区別する

同じ入力・精度・必要な出力を固定し、台数だけを増やして所要時間を調べるのが、強スケーリングです。一方、台数に比例して問題規模も増やし、一台あたりの仕事量を一定にするのが弱スケーリングです。理想的には後者の所要時間は一定になりますが、どちらも実際にそのように動く保証ではありません。AWSの2022年CFD資料は、流体計算を例にこの区別を説明しています。

John Gustafsonの1988年論文は、計算機が増えると利用者が格子の細かさや時間刻みなどを変え、一定時間でより大きな問題を解く見方を示しました。固定した仕事の直列部分がなくなるという主張ではなく、増設で何を達成したいかが変わります。

例えば、四台で実行する計算の直列部分が20分、並列部分が80分とします。四台の並列部分を一台へ戻すと320分かかる量なので、同じ大きな仕事を一台で実行すれば、20＋320で340分です。四台の100分に対する倍率は3.4倍になります。

ここでの比較対象は、先ほど一台で100分だった仕事ではありません。並列部分の仕事を80分相当から320分相当へ増やした別の規模です。直列部分を固定したこの例では、全体の仕事量は元の3.4倍であり、厳密に全体を四倍へ増やす弱スケーリング試験とも区別します。

固定量を四台で実行するときの直列割合は、元の一台100分のうち20分です。仕事を増やした例の20%は、四台で実行した100分のうち20分です。一台で実行する340分に対しては約5.88%となります。割合が同じ数字だからといって、同じ分母の測定として式へ入れてはいけません。

夜間の限られた時間で詳しい計算をしたいなら、問題規模を広げる試験は役立ちます。しかし、毎回同じ入力を15分以内に処理したいなら、大きな問題を100分で解けた実績だけでは判断できません。性能報告には台数と倍率に加え、入力の規模・精度・所要時間のどれを固定したかが必要です。

台数を決める前に、残った時間を測る

先ほどの20＋80÷Nは、通信時間も分担の偏りも増えない理想化です。AWSのHPC公式資料は、密接に連携する処理では計算機間の通信遅延や帯域が重要になると説明しています。台数を増やすことで結果交換の負担が増えれば、表より短縮しない場合もあります。逆に、一台そのものを速くする変更は直列時間も変え得るため、同性能の台数追加と分けて測ります。

実際のジョブでは、理想どおりに分担できない時間もあります。準備、各部分の計算、結果の集約を区切り、同じデータで一台、四台、八台を比べると、増設しても縮まない段階が見えます。全体時間が縮んでも、必要な結果が省かれたり精度が落ちたりしていれば、同じ仕事の短縮とはいえません。

測定で集約部分の20分が残ると分かったなら、そこで初めて処理設計を見直す根拠ができます。重複した確認の除去、途中結果の再利用、集約手順の分割などが候補になります。ただし、分けて実行できるか、変更しても出力の意味が保たれるかは個別の検証が必要です。新しい設計が速いという期待を、旧実装の20分を使った式で証明することはできません。

直列部分を短くする変更にも、開発費、検証費、障害時の運用負担がかかります。35分の締切を八台で満たせるなら、全面的な作り直しを急ぐ必要はないかもしれません。反対に15分が必要なら、増設案を細かく比較する前に、直列部分を変えられるかを調べるほうが判断を進めます。

増設を選ぶのは、同じ仕事で実測した短縮が締切を満たし、そのための費用を許容できる場合です。直列時間が締切を越えて残るなら、台数の追加とは別の変更が必要になります。一定時間で仕事量を増やす目的なら、その規模を成果として測る。固定するものを先に決めることで、性能倍率が実際の仕事の判断につながります。