Build ブログ
熱設計電力（TDP）の台頭
CPUはCPUであって、やはりCPUである。トランジスタから700Wのソケットまで、データセンターインフラへの浅い潜水。
コンピュート需要の高まりはTDP上昇の波を生み、データセンター設計の方向性を、そしてその延長として私たち全員が動かしているクラウドプラットフォームのあり方を変えつつあります。
CPU、すなわち中央処理装置とは、その時代における最先端の製造方法で作られたシリコンダイを1つ、あるいは複数パッケージしたものです。
世の中には幸せな人々がいて、その一方で、現代のデータセンターの終わりのない通路をさまよう自分に気づく人々がいます。その内側で耳を満たすのは、高揚のざわめきではなく、トランジスタとファンとフライホイールが立てる永遠のうなりです。それらはレーザーの光が走るファイバーを通じて、この地球の尖った四隅すべてに、インターネットにつながったコンピュートを届けています。
データセンターが顧客に請求する唯一の継続的な費用であるkVA（またはkW）を、計算可能な形で製品やサービスへと変換すること。まさにそこにCPUの責務があります。
というのも、GPU、CGRA、FPGA、DSP、VPU、RDUと数え上げていっても、逐次的な依存関係を持つ処理の実行役は、依然としてCPUなのです。
この記事では、クラウドコンピューティングの内部の仕組みと、それを形づくる風について、いくらかの洞察をお届けしたいと思います。
なぜ熱設計電力なのか
トランジスタの話をしましょう。トランジスタはデジタル論理の最も基礎的な構成要素です。それらはテキストファイルとして記述され、世界中のファウンドリでシリコンウェハーに刻み込まれます。
私は、入力側の線路、出力側の線路、そして制御信号を備えた跳ね橋を思い浮かべます。制御信号がなければ跳ね橋は上がったままで、線路には何も流れません。制御信号を加えると橋が下がり、通行が可能になります。
ただしこの場合、通行するものも制御信号も、どちらも電子です。そして頼りになる制御信号には、跳ね橋を動かすだけのエネルギーが必要です。電圧が足りなければ、橋は下がりません。
さらに、熱という形での損失もあります。これは決定的に重要な点です。シリコントランジスタは超伝導体ではありません。橋が下がって電子が流れるとき、電子は通過する途中で速度を落とし、橋を熱くします。
パッケージ全体の放熱要件を管理するために、メーカーはワット単位の数値を公表します。これが熱設計電力、すなわちTDPです。
入るワット、出るワット
ここで少し待ってください。ワットは電力、つまりエネルギーの移動量を測る単位です。それがなぜ放熱の指標に使われるのでしょうか。
おそらく、CPUに入るエネルギーはほぼすべてが熱になります。そしてその熱の大部分が、パッケージ内に温度勾配を生みます。エネルギーが増えれば熱も増え、勾配も大きくなります。
CPUは空気のある場所に設置できます。周囲の空気へ十分に熱を移すことができれば、パッケージは設計上の動作範囲内に保てます。空気がない場合、あるいは空気だけでは熱として十分なエネルギーを逃がせない場合には、パッケージ上に液体を循環させたり、大きな固体の熱伝導部材を使ったりすることになります。
広く採用されている方法のひとつは、熱伝導材を挟んで銅またはアルミの部材をパッケージ上に載せ、ファンでその部材に空気を通す、というものです。
君はもう過去だ
コア数が急速に増え、それに伴ってTDPも上がっていることを示すのに、グラフは必要ありません。
E5-2699Aは、Intelが製造した10年前の生産終了済みCPUパッケージです。22コア44スレッドを備えています。TDPは145Wです。
7713は、AMDが製造した5年前のCPUパッケージです。64コア128スレッドを備えています。TDPは225Wです。
6980Pは、Intelが製造した2年前のCPUパッケージです。128コア256スレッドを備えています。TDPは500Wです。
Zen 6のフラグシップは、AMDが製造する未発表のCPUパッケージです。私の見立てでは、256コア512スレッドになるでしょう。そしてTDPは700Wになるでしょう。
だいたいの傾向はつかめたと思います。もちろん、クラウドプロバイダーとして十分な影響力があるなら、自分専用のCPUを頼めばよいだけです。X8iやMI300C、いかがでしょうか。
ピザの箱
ピザボックスサーバー。これは現在、高さ1U、幅19インチ、奥行きは任意の空冷スチール製シャーシを指す言葉として使われています。
その内部には、1台以上の電源ユニット（PSU）、ドライブベイ、ファン、そしてマザーボード自体が収まっています。マザーボードには1つ以上のCPUソケットが実装されています。電源ユニットは、供給電圧をCPU、マザーボード、ドライブ、ファンが必要とするロジック電圧まで整流して落とす役割を担います。
ファンは、シャーシ内に十分な空気を通すという決定的な役割を担います。かつて広く使われた1U用のファンは、電力を大量に消費する新しいソケットが求める風量の増加によって、次々と役目を終えつつあります。さらに、サーバー1台あたりの消費電力の増加とラックあたりの電力上限が重なり、サーバー1台あたりの高さはもはや大きな関心事ではなくなってきています。
こうしてピザボックスサーバーは姿を消しつつあり、より大きなファンブレードを備えた2Uシステムや、もはや個々のサーバーを見分けられない液冷の一体型筐体に置き換わっています。
ここで一歩引いて、データセンター全体を見てみたいと思います。
その熱を外へ出せ
エネルギーはラック内のサーバーに電気として入り、より高温の空気として出ていきます。単純な話ですよね。ただし、その熱を空気に移してしまった以上、今度はその空気を建物の外に出さなければなりません。
どうやって空気を建物の外に出すのでしょうか。横風が吹く立地なら、壁をすべて開けてしまえばよいのです。（実際にそうしているハイパースケーラーもあります。）壁を開けられないなら、産業用の排熱設備が必要になります。
この一連のプロセスの効率は、電力使用効率、すなわちPUEとしてモデル化されます。PUEは、建物への入力電力と、ワークロードを実行するシステムへの入力電力との比です。エベレストに建てたデータセンターならPUEは1.0000になるでしょう。あの動じることのない氷の山が、空気を設計上の動作範囲内に保つという途方もない仕事を引き受けてくれるからです。
グッドハートの法則のおかげで、ハイパースケーラーたちはこの指標をうまく悪用する方法を見つけるたびに、互いに一歩上を行こうとする競争を繰り広げています。それでも効率は依然として非常に重要で、熱の再利用は、海面高度にあるデータセンターが引き起こすあの例のものを少しでも減らすために欠かせません。
とはいえ、単独で建っているデータセンターはほとんど役に立ちません。インターネットは結局のところサービスのネットワークです。さて、提供するための電力が手に入ったところで、私たちはワークロードをどう動かすのでしょうか。
ファンクション対インフラ対プラットフォーム
インターネットサービス全体を、限られたコンテキストの範囲内で、区切られた実行時間の中で動く個々の関数として表現できるなら、Function as a Service（FaaS）はあなたに向いた製品です。とはいえ真面目な話、制御しきれない使用量ベースの課金と極端なベンダーロックインを別にすれば、FaaSは自分が実行している基盤を気にしなくてよいという利点をたしかに提供します。
では反対方向に行きたいとしましょう。IaC（Infrastructure as Code）が最新の流行で、あなたは4年前のチュートリアル動画を観て最先端の知識を仕入れたばかりです。さあサーバー、あるいはVMやクラスタ、ともかく最近のハイパースケーラーが推しているものを乗りこなしにいきましょう。ただし、正しいインフラ定義ファイルをバージョン管理にコミットすること、そしてタイプミスで本番データベースを消してしまわないことは、くれぐれもお忘れなく。スナップショットまで一緒に消してしまわないように。あるいは、誰かが自分のプライベートデータストアにアクセスした分だけ課金される、そんなことは起こり得ない、そうですよね。
Buildのようなプラットフォームは、その下にあるインフラに対する統一された抽象化を提供します。私たちは、エンタープライズ向けアプリケーションアーキテクチャの継続的デプロイを、扱いやすい開発者体験と組み合わせて実現します。何百もの独自サービスに囲い込むのではなく、オープンな標準を採用しています。アクセス制御は素直で読みやすく、入り組んだ権限継承の迷路をたどる必要はありません。CLIはエージェントによるデプロイを可能にし、そして都合よく、バックアップをすべて破壊する機能は持っていません。さらに、24時間体制の開発チームが、ご都合のよいタイミングでビデオ通話に参加して支援します。サポートの階層をかき分ける必要はありません。
すべては日々の仕事のうち
TDPという主題は、急速に拡大するデータセンター産業という大海原を見渡すための、私たちの潜望鏡でした。それを通して私たちはスタックの各層を一枚ずつはがし、Webアプリケーションのデプロイを形づくっている物理法則を見てきました。
CPUの電力は上がる一方であり、それに伴って冷却も、専用のパッケージングも、そしてそれらを収めるサーバーの複雑さも増していきます。ハードウェアがますます精巧になっていくなかで、開発者がソフトウェアづくりに集中できるプラットフォームを頼りにできることは、きわめて重要です。
Lex SiegelはBuild.ioの創業者です。Build.ioは、プロダクトチームがインフラを管理することなく本番アプリケーションをデプロイし、運用できるフルスタックのクラウドプラットフォームです。