データセンターの冷却ループの一つが壊れた。

これはほぼ間違いなく機器の故障が原因だね。データセンターの冷却は、他のすべてと同じように過剰にも不足にもなってる。大きな熱交換ユニットはN+1（または非常に重要で小さい負荷の施設では2N/3N）で過剰に設計されてるんだ。これは、定期的にメンテナンスのために停止させる必要があるからで、従来のDCコンポーネントに比べて故障率が高く、専門的な労働が必要な機械修理が必要なんだ。大きな施設では、Nが大きくなると冷却がN+3以上になることも珍しくない。常に何かをメンテナンスしているか、ブロワーアセンブリを待っている状態だから。これがもう存在しない部品で、機械工が旋盤で作らなきゃいけないから、全ユニットを交換するよりも安く済むんだ。システムは過剰に設計されている一方で、もし施設内のすべての計算能力が突然平均の電力消費から100%に上がったら、冷却能力がオーバーロードすることもあるし、電気や他の経路でもオーバーロードすることがよくある。過剰設計は業界の性質なんだ。一般的には、これらの問題は本当の問題にはならない。計算負荷は100%にはならないし、もしそうなっても長くは続かないから、誰も冷却や電力容量のギリギリで施設を作らない。問題は、複数のイベントが交差したときに起こる。冷却システムを平均負荷の200%に設計しているから、メンテナンスや停電のための余裕がたくさんある。修理の人が火曜日にユニットの作業に来て、悪いベアリングを見つけたら、隣の州から取り寄せなきゃいけないから、そのユニットを一晩オフにしておく。そうすると、隣の冷却ユニットが少しだけ頑張って補うことになるけど、そのうちの一つもモーターがちょっと不均衡だったり、ヒューズが緩んで温まってたりして、負荷が増えたことで、何年も問題なかったのに壊れちゃう。これでN+2の施設でユニットが2つ減っちゃった。まあ、200%の平均負荷に設計してるから、そんなにひどくはない。最初に壊れたユニットの反対側にある3つ目のユニットも、今はもっと負荷がかかっていて、故障が出る。これでN+2の施設でユニットが3つ減っちゃった。まだ致命的ではないけど、200%の平均負荷に設計してるからね。問題は、今は午前4時で、現場のオペレーションの人がこれらの故障を修理できなくて、ベンダーに電話しなきゃいけない。ベンダーは午前7時まで起きないし、午前9時まで現場には来ない。負荷が上がり始める。これらのことは、アメリカのどこかのデータセンターで毎日起こってる。おそらく、すべてのデータセンターで年に一度は起こる。次に起こるのは、ニュースになるようなイベントの交差だ。大きな顧客の一つが、今が巨大なバッチ処理ジョブを始める絶好のタイミングだと決める。あるフィンテック企業が市場が開く前に大きなモデルを動かしたいとか、ある石油会社が新しいフィールドの迅速な分析をしたいとか。彼らは1万台の新しいVMを立ち上げる。通常なら問題ないけど、余裕があるからね。でも、平均冷却能力の200%を計画してたことを思い出して。これは、忙しいけどそんなに忙しくないノードじゃなくて、最大の電力を引き出して、最大の廃熱を排出するような、集中的に最適化された数値計算をしているノードなんだ。機械の総数が急増しただけでなく、廃熱の影響も平均して大きくなる。バン！カスケード故障が起こって、冷却がN-4になっちゃう。サーバーファンが早く回り始めて、もっと電力を消費する。冷却がN-5に。アラームが鳴り響く。冷却ユニットの安全装置がトリップし始めて、負荷を超えて冷媒圧が上昇する。冷却がN-6に。冷却がN-7に。冷却が0になっちゃう。

複数の冗長チラーが屋上にあって、各フロアにも冗長クーラーがあったデータセンターで働いてたけど、水道管が何らかの理由で壊れた時に、建物全体の冷却が一度に失敗したんだ。どうやって壊れたかは言わなかったけど、各フロアと屋上の間のパイプは冗長じゃなかったらしい。修理にほぼ24時間かかったよ。

同じようなトピックについての良いリスニングはこちら： https://signalsandthreads.com/the-thermodynamics-of-trading/

これはただの推測だけど、海の近くの土地はもっと高いし、人口も多いからじゃないかな。水は比較的安いし。

大学院でデータセンター（HPCインフラ）についての授業を受けたことがある。教授はアメリカの真ん中あたりの、暑い気候のデータセンターを例に使ってた。理想的なシナリオ（天候、電源など）と比較してたスライドがあって、データセンターを建てる場所を決める要因がいくつかあった。十分なスペースと、そこで働くスキルのある人を見つけることが含まれてた。時には次のデータセンターの場所を選ぶのに政治が関わることもあるってコメントしてた。

思いつくままに言うと、海水の塩分濃度を維持するのはすごくコストがかかる（セカンダリループでも）。沿岸の土地もずっと高いし。もし遠くの沿岸サイトに行くと、電力へのアクセスがあまり良くないかも。沿岸のサイトは通常、より厳しい気象条件にさらされることが多いし。他にも予測不可能な問題があって、例えばディアブロキャニオンの原発は、塩水冷却の取り入れ口がゴミやクラゲの移動で詰まる問題があったりする。 https://www.nbcnews.com/news/world/diablo-canyon-nuclear-pla...

アシュバーンVAはデータセンターのハブなんだ。なぜなら、世界初の非政府のインターネットエクスチェンジポイント（IXP）がそこにあったから（https://en.wikipedia.org/wiki/MAE-East）。1990年代には、世界中のインターネットトラフィックの半分くらいがMAE-Eastを通ってた。それがAWSが最初のリージョンをそこに置くきっかけになった（us-east-1はeu-west-1より2年早く、us-west-1より3年早い）。その後、データセンターを作るのが得意な人たちや、それを供給するベンダーがたくさんいたから、ダレスコリドーは多くの企業のデータセンターの主要なハブになった。AWSにとって、us-east-1は最初だったから、他のリージョンよりもずっと複雑で変わったところで、他のAWSサービスの多くのコントロールプレーンがそれに依存してる。だから、他のリージョンよりもダウンすることが多く、ダウンすると全国ニュースになるんだ。例えば、スペインのeu-south-2とは違ってね。でも、ノバはポール・クルーグマンがノーベル経済学賞を受賞した経済クラスターと基本的に同じようなもので、工場じゃなくてデータセンターのためのものなんだ。

海には塩があるよね。塩水は普通の水よりも電子機器に悪影響を与えるんだ。水深も十分にないと、表面温度まで温まっちゃうし。伝統的な蒸発冷却と価格競争力も必要だよ。トロントはその成功例だね。深い淡水湖の近くにあって、ダウンタウンは高級不動産があって伝統的な方法が使えないんだ。

面白いことに、私は2つの異なるデータセンターでの重要なダウンタイムの加熱事件に関わったことがある。一つはHosting.comのSOMAデータセンターがあまりにも熱くなって、屋根の上でホースを使って冷やしていたとき。もう一つは、AlibabaのChai Wanデータセンターがあまりにも熱くなって、そこにあるすべてがダウンしたとき、制御プレーンも含めて。だから、海に近いことが緊急の熱処理において特に有利になるとは思えないね。熱を排出するための能力はxで、海の近くにいてもネブラスカの真ん中にいても関係ない。システム全体がある性能に対して設計されている必要があるんだ。

最近、ミシガン湖の近くにデータセンターを建てる提案がたくさんあるけど、ウィスコンシンの住民は自動車部品店と製紙工場しか求めていない。完全に悪者扱いされてる。都市や郡はデータセンター禁止の法律を通しているけど、そこはデータセンターにとって完璧な場所なのに。

確かに、時々そうだね。Googleは2011年にフィンランドの古い製紙工場の跡地にこれを建てたんだけど、バルト海から水を引くようにすでに設計されていたんだ（大西洋ほど塩辛くはないけど、淡水でもない）：https://datacenters.google/locations/hamina-finland/ > 「フィンランド湾の海水を使用した冷却システムと新しいオフサイト熱回収施設を使って、私たちのハミナデータセンターは持続可能性とエネルギー効率の向上の最前線にいます。」

湿度と腐食、これはトレードオフだね（どっちを選ぶかって感じ）。

伝聞だけど（まあ、もっと「聞いた話」って感じだけど…）US-East-1からUS-East-2に移行した人たちの影響で、何かしらの影響があったみたい。だから、複数の地域やAZの話が単なる見せかけだってのがちょっと面白いよね。でも、私たちはみんなそれをクラウド宗教の信条として信じているみたい。

本当にeast-1がもっと失敗してるのか、それとも他の場所での失敗についてはあまり聞かないだけなのか？最後に聞いたAzureの障害は、HNのフロントページにも載ってなかったし。

使ってる人が多すぎる。ファンタジーの魔法の夢の世界では、負荷は異なるクラウドプロバイダーに均等に分散されている。単一障害点なんて存在しない。初めての彼女とうまくいったのと同じように。双子は英語と韓国語が流暢だし、大規模サービスを展開する際にはAWSだけに依存しないことを知ってる。アメリカの医療は手頃だし、いろんな魔法のようなものがここには存在する。でも、違うんだ。今日はまた別の日。AWSのUS-East 1がインターネットの大半をダウンさせることができるんだよね。

みんなそう言うけど、これは単一のAZの話で、私のスタートアップが主にus-east-1で運営されている3年間で、地域的な障害は1回だけだったし、それも部分的なもので、ほとんどのインスタンスには影響がなかった。正直言って、他の人のシステムもus-east-1にあるから、少なくともあなたの障害は顧客と関連してるよね（笑）。

AWSのサービスが完全に地域化されているとか孤立しているという考えは、ずっと神話だった。中国以外のパブリッククラウドのアイデンティティとアクセスサービス（従業員には「awsパーティションのIAM」と呼ばれている）は、us-east-1に集中している。この集中化は、アカウント、請求、権限を一貫して把握するために本質的に必要なんだ。そしてIAMは完全に独立したソフトウェアスタックではなくて、DynamoDBや他のいくつかのサービスに依存していて、それらもIAMに循環依存している。us-east-1の障害中は、他のリージョンで既存の認証トークンやセッションを使い続けることができることもあるけど、新しいものを発行することはできない。私がそこで働いていた時、少なくとも一度、私のチームのオンコールがsshセッションやAWSコンソールのブラウザタブを閉じないようにアドバイスされたことを覚えてる。障害が終わるまでロックアウトされるのが怖かったから。

大手テック企業が倫理的なエンジニアを雇うのはいいことだよね。お金や社会的地位だけを気にする人じゃなくて。

これらのことは危険だね。AWSをダウンさせることができるような従業員が賭けをする可能性がある。もし賭けサイト自体がAWSのダウンで閉鎖されたらどうなるか想像してみて。 （半分冗談だけど） > これらの賭けは見た目ほど無邪気じゃない。なぜなら、賭ける人が結果に影響を与えたり変えたりできることが多いから。全体的に見て、これらの賭け市場がインサイダー取引を促進することもあるという君の意見には同意するよ。そういう状況を利用するインセンティブを与えてしまうからね。

east-1って「コア」データセンターで、しかも一番古いんじゃない？他の地域よりも負荷が大きいと思うし、構築したときの経験が少なかったから技術的負債やアーキテクチャ的な負債も多いんじゃないかな。それに、確か一部のサービスはeast-1に依存しているから、構成の単一障害点になってるよね（IAMとかS3の一部とか？）

面白いことに: > AWS 2025年: あなたが知っていると思っていることが今は間違っている > us-east-1はもう悲しみと後悔の燃えるゴミ箱じゃない。— https://www.lastweekinaws.com/blog/aws-in-2025-the-stuff-you... それ以外はいい記事だね！

それは最も古いリージョナルシステムで、構造的に重要な役割を持ってると思う（例えば、内部CAがそこにあるはず）。

暗号通貨の会社を信用しちゃダメだよ。

公式な情報は見つからないけど、爆風半径はAZに限られてない気がする。us-east-1でシステムを動かしてるけど、事件の間に今まで見たことのない説明できない断続的な接続問題が発生したんだ、az4以外でもね。

SLIグラフを見ながら地域が爆発するのを待ってたけど、結局何も起こらなかった。いくつかの環境で単一AZのEBSボリュームが劣化してただけだった。完全に単一のAZ（use-az4）だったよ。

East-1がダウンすると、他のAZからも何か影響を受けることが多いよね。East-1に依存してるものが必ずあるから。

OVHに愛がないのはなぜ？ヘッツナーのUIは超わかりにくくて、管理が難しいと思うんだけど。