世界で最も非効率なデータセンター構築ガイド

構築するもの

このサイトのすべてのガイドでは、コマンドを順番どおりに実行する方法、正しい結果の見た目、発生する障害を説明しています。このガイドは異なります。今日は、あくまで仮定の話として、資金、電力、そして思い上がりによって実現できる、最も非効率なデータセンターを設計します。

指標が必要なので、業界独自の指標を使います。PUE（Power Usage Effectiveness）は、施設全体の消費電力を、実際にコンピューティング機器へ届く電力で割った値です。ハイパースケールデータセンターは約1.1で稼働し、ほぼすべてのワットが有効な処理に使われます。十分な企業サーバールームなら1.5程度です。私たちの目標は4.0以上です。つまり、コンピューティングに1ワット使うごとに、さらに3ワットが何の役にも立たず失われます。重大なガイドでバックアップを繰り返し取り上げるように、今後この数値を何度も参照します。

サイトの選定: 熱が目的です

実際のデータセンターでは、冷却が最大の単独コストです。そのため、私たちのサイトは熱力学の本拠地で熱力学に立ち向かいます。理想的な場所は屋根裏です。南向きが適しています。できれば、サーバーに直接光が当たる天窓を設置します。これにより、マシンは自身の排熱と太陽熱の両方を受けます。電気料金と恒星が協力する形です。

冬は、窓を開けて冷却します。実際のデータセンターでも外気を使用します。この手法はフリークーリングと呼ばれ、設計段階で管理され、ろ過され、湿度も制御されます。私たちは、雨、花粉、そして四半期ごとに少なくとも1羽の困惑した鳥まで通す窓を使って、偶然この方法を実施します。

さらに本格的にするには、エアコンを設置します。その後、エアコンのサーモスタットから2 feet離れた場所にスペースヒーターを置き、エアコンの設定温度より2 degrees高く設定します。これで両方の機器が、完全に意見を違えたまま、永遠に連続稼働します。電力会社からクリスマスカードが届きます。

サーバーは1台、大規模で、愛着がある

冗長化すると、責任感が薄れます。私たちのデータセンターにはサーバーがちょうど1台だけあります。しかも非常に大規模です。RAMが512 GBある1台のマシンは、インフラらしく感じられます。一方、小型のマシンが4台あると、やることの一覧に見えます。

そのサーバーには名前があります。ホスト名ではなく、名前です。通常はGandalf、またはOdinです。Odinを廃止することはできません。Odinは5年間稼働しています。

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

この数字は誇りの証です。そのため、スクリーンショットを撮って投稿します。そして、そのスクリーンショットを見た攻撃者も、これを印象的だと感じます。稼働時間1,847日は、誰も修正していないカーネルの脆弱性が1,847日分あるということです。そもそも再起動は問題外です。再起動すると、2021年に手動で起動され、systemd unitに記述されていないサービスがどれか判明してしまいます。どれなのか、誰も覚えていません。現在、このサーバーは組織図を支える存在になっています。

ストレージ: 速度と、その他のデータ喪失方法

ディスクはパフォーマンスを優先して RAID 0 に構成されています。ゼロは、故障してもよいディスク数を示します。効果を最大にするため、異なる出所のストレージにアレイをストライピングします。適切な SSD 2台、老朽化したスピニングディスク 1台、そしてカンファレンスでもらった USB メモリ 1本を使用します。アレイの信頼性は、カンファレンスでもらった USB メモリとまったく同じです。これが設計上の仕様です。

バックアップは、同じアレイ上にある backup_final_v2_REAL というディレクトリで処理します。このディレクトリには、以前の命名規則の tarball が含まれています。オフサイトバックアップは、「オフサイトバックアップを設定する」と書いた付箋で代用します。この付箋をノート PC の蓋に貼って自宅へ持ち帰れば、技術的にはオフサイトに保存されています。

正しい結果は、df が使用率 97% を報告し、次のスプリントで対処する計画がある状態です。

ネットワーク: すべてを1本に集約

DNSサーバーはマシン自体で稼働しています。そのため、サーバーが停止すると、障害の原因を調べるために使用するDNSレコードも失われます。これは集約と呼ばれます。

ファイアウォールは、何かをデバッグするために2021年に一時的に無効化されました。デバッグは完了しましたが、ファイアウォールは再び有効化されませんでした。後で時間を節約するため、ルーターのすべてのポートがサーバーに転送されています。また、リモート管理を便利にするため、ルーターの管理画面は工場出荷時のパスワードのままWAN側からアクセスできます。あなたからも、他者からもアクセスできます。

最近、サーバーは屋根裏部屋にしても異常に高温で動作しています。topによると、最も負荷の高いプロセスはxmrigという名前です。これを使用中の監視ツールだと考えています。インストールした覚えはありませんが、ポートを転送した直後に自動的に現れました。これは、エコシステムが活発に機能している兆候だと判断しています。24時間監視しています。

電力は、複数の民生用電源タップを連結して供給しています。合計の長さはブレーカーパネルまで歩く距離を超えています。これは、ある意味では効率的です。ブレーカーパネルへ頻繁に行くことになるためです。

複雑性による冗長化

重要な箇所では冗長化を拒否したため、ここでは不要な箇所に冗長化を追加します。会社のホームページは静的なHTMLファイル1つですが、12ノードのKubernetesクラスターで配信します。これにより、エンジニアが「履歴書駆動型アーキテクチャ」と呼ぶ構成を実現できます。ページの読み込みはnginxなら40ミリ秒で完了するところ、コンサルタントが必要になる障害が発生するようになります。

分離のため、クラスター自体を仮想マシン内の仮想マシン内の仮想マシンで実行します。各層がセキュリティを追加しますが、その仕組みは七面鳥の中に鶏を詰め、その中にさらに鳥を詰める料理に似ています。お問い合わせフォームは9つのマイクロサービスで構成します。そのうち2つは一度も呼び出されていません。1つは負荷を支えていますが、どれなのか誰も知りません。

サービスとしての暖房

最新のサーバーは電力を計算と熱に変換します。ここでは、後者の出力を最大化します。GPUなしのメディアサーバーは典型的な方法です。単一の4KストリームをCPUでトランスコードすると、16個のコアをフル稼働させて小さな寝室を暖めます。映画も再生できるspace heaterです。さらに意欲的な運用者は、CPUで大規模言語モデルを実行する段階へ進みます。これはAPIを備えた700億パラメータのspace heaterで、トークン生成速度は季節単位で測るのが適切です。

監視システムが自分自身を監視します

可観測性は重要です。そのため、セルフホスト型の稼働監視システムを、監視対象と同じサーバーにデプロイします。Odin が停止すると、監視システムも同時に停止します。ここが重要です。アラートは発報されません。アラートがなければ、インシデントもありません。インシデントがなければ、測定上は完全な稼働率になります。月次レポートの見栄えは、これまでになく良好です。

念のため説明すると、アラートメールは Odin 上でも稼働している mail server を経由して中継します。したがって、アラート通知のパイプラインは完全に自己完結しています。これは、蛇が自分の尾を食べ続けることで完全に満腹になるようなものです。

気が進まない部分

ここが、私が先延ばしにしてきた部分です。ここに書く内容はすべて実話です。かけがえのないサーバー、同じボリュームにバックアップを保存した RAID 0、「一時的に」無効化したファイアウォール、1ページを配信する Kubernetes クラスター、自分自身を監視する監視システム。これらはすべて本番環境で見てきました。今年見たものもあります。初期の頃には、そのうち1つか2つを自分で構築したこともあります。

実際の効率化は退屈です。そのため、その場では議論に負けますが、10年かけて成果を出します。誰かが設計したため、意識する必要のない PUE。所有者の自己イメージではなく、ワークロードに合わせたサイズのマシン。爆発が起きる前に検討された影響範囲。スケジュールに従い、カレンダーのリマインダーを設定し、英雄的な対応をせずに復元テストを行うバックアップ。目立たない冗長化。高価で優れたものを1つ用意するより、安価なものを2つ用意するほうが、私が対応を求められたあらゆる障害で、常に有効でした。

そして、運用できる最も効率的なデータセンターは、運用しないデータセンターです。VPS を利用すると、電力、冷却、冗長化、午前3時のハードウェア障害への対応を、それらを大規模かつ退屈なほど効率的に処理する人々に任せられます。これはインフラストラクチャに与えられる最高の評価です。そのうえで、本当に面白い部分である その上で自分のサービスを運用すること に集中できます。失っても構わないマシン上で行うべきです。実験に使うマシンは、それだけが適しています。

FAQ

実際にこれらを行うべきですか？

いいえ。このガイドの各セクションは、週末を何度も失う結果になった、文書化されたアンチパターンです。現在の構成が2つを超えるセクションに当てはまる場合は、このFAQの最後の質問へ、示されている順番で進んでください。その順番がトリアージの手順です。

実際のところ、適切なPUEとは何ですか？

ハイパースケールのデータセンターは約1.1で稼働し、適切に運用された企業のサーバールームでは1.4から1.6を達成します。一方、冷却されておらず、space heaterとの競合まである物置では、実際に3を超えることがあります。自宅で1.1と有意に競争することはできません。これが、計算資源を提供できる相手から借りることの、控えめですが経済的な根拠です。

サーバーで建物を暖房することは、実際に行われていますか？

はい。適切に実施されています。複数の国の地域暖房プロジェクトでは、熱交換器を使用してデータセンターの排熱を回収し、設計、エンジニアリング、契約に基づいて住宅へ配管しています。上記の風刺は、サーバーの熱で部屋を暖められないという意味ではありません。問題は、それを偶然行い、その偶然を戦略と呼ぶことです。

私のサーバーはすでにこのような状態です。最初に何をすべきですか？

まず、今夜バックアップを取得してください。保存先はサーバー以外にします。その後、テストリストアを実行してください。テストしていないバックアップは、単なる噂です。次に、パッチを適用し、避けていた再起動を計画したメンテナンス時間内に実施してください。監視しながら、何が壊れるかを確認できます。3つ目に、単一障害点を分離します。DNSと監視をそのサーバーから移してください。それ以外は、落ち着いて対応できる週まで待てます。ただし、この3つは待てません。