# Bootstrapping an Infrastructure > [!abstract] 概要(abstract の日本語訳) > システムインフラストラクチャを展開・管理する際、インフラ全体を一体のものとしてではなく個々のマシン単位で考えることが依然として一般的である。この標準的な慣行は、労働集約的な管理、高い所有コスト、大規模インフラの管理に使える一般に利用可能な知識やコードの不足を含む多くの問題を生み出す。 > 我々が説明するモデルは、インフラストラクチャを単一の大きな分散仮想マシンとして扱う。このモデルを用いることで、大規模インフラの問題により効果的に取り組めることが分かった。このモデルは、グローバルな金融取引フロアの4年間にわたるミッションクリティカルな展開と運用管理の過程で開発された。典型的なインフラの規模は300〜1000台のマシンであったが、この原則ははるかに小規模な環境にも同様に当てはまる。これらのインフラを合計すると約15,000ホストになる。その後、NASA Amesでの経験に基づきさらなる改良が加えられた。 > ここで説明する方法論は、例示のオペレーティングシステムとしてUNIXとその亜種を用いる。我々は、この原則が他のオペレーティングシステムに基づくインフラの管理にも同様によく当てはまり、同じくらい切実に必要とされていることを見出している。 > 本論文は生きた文書である。改訂と追加は今後も予想され、www.infrastructures.org で入手できる。我々はまた、インフラ設計・実装の課題を議論するためのメーリングリストも運営している。詳細はウェブサイトで確認できる。 ## 論文情報 - タイトル: *Bootstrapping an Infrastructure* - 著者: [[Steve Traugott]](Sterling Software / NASA Ames Research Center)・[[Joel Huddleston]](Level 3 Communications) - 会議: 12th Systems Administration Conference (LISA '98)、1998年12月6日〜11日、ボストン - URL(PDF): https://www.usenix.org/legacy/publications/library/proceedings/lisa98/full_papers/traugott/traugott.pdf - 会議ページ: https://www.usenix.org/conference/lisa-98/bootstrapping-infrastructure - 原本: `.raw/papers/lisa98-traugott-bootstrapping.pdf`(17ページ) ## 概要 インフラストラクチャを個々のマシンの集合体ではなく「単一の疎結合な分散仮想マシン」とみなす思考の枠組みを提示する論文である。1990年代半ばの金融取引フロア(300〜1000台規模、延べ約15,000ホスト)の運用経験から抽出された、インフラを新規構築または再構築する際に踏むべき16段階の「Infrastructure Bootstrap Sequence」を提示し、各段階の目的・前提条件・当時使われたツール(CVS、SUP、NIS、NTP、cfengine相当の自作Makefile機構など)を具体的に説明する。中心的な主張はpush型ではなくpull型の変更配布を使うべきだという点と、ゴールドサーバー(gold server)と呼ぶ単一の正本マシンから全ての変更を発生させ、他のマシンには決して直接ログインして変更しないという規律である。 ## 問題設定 1990年代当時、個々のツール・技法・ポリシーに関する文献(nemeth, frisch, stern, evard, limoncelli, andersonなどへの参照)は充実していたが、数十台を超える規模の「全体をどう組み立てるか」を扱う文献はほとんど存在しなかった。インフラは通常アドホックに構築されるため、新規構築にせよ既存インフラの掌握にせよ、必要な手順の発見は時間がかかり誤りを招きやすく、初期段階の誤りは後々まで除去が困難だった。著者らは4年間、複数の異なる国にまたがる複数のミッションクリティカルなインフラを同時に展開・改修・運用する中で、この手順(bootstrap sequence)と対応するツール群を体系化した。 ## 提案手法 ### インフラを仮想マシンとして捉える思考法 インフラを「何百・何千ものハードディスクとCPUを持つ、疎結合の単一仮想マシン」とみなす。この視点は次の帰結を持つ。 - 全ノードは特定用途に固有化させず、コモディティなリソースを提供する汎用ノードとして扱うべきである。ノードの追加・削除・置換が容易になる。 - 単一ノードの喪失は仮想マシン全体からみれば軽微な影響しか持たない。 - 認証は仮想マシン全体で単一化する(同じユーザID・パスワードでどのノードにログインしても良い)。これはフリーシーティング(自由な座席移動)を容易にする。 - アプリケーションやパッチの「インストール」は個々のマシンではなく中央リポジトリに1回投入し、そこから全ハードディスクへ伝播させる操作として捉える。 ### Infrastructure Bootstrap Sequence(16ステップ) 各ステップは先行ステップへの依存関係を持ち、順序を誤ると問題の発見が遅れ、後戻りのコストが大きくなる。 ![[fig01-infrastructure-bootstrap-sequence.png]] *図1(Figure 1): Infrastructure Bootstrap Sequence。バージョン管理からゴールドサーバー、ホストインストールツール、アドホック変更ツール、ディレクトリサーバー、認証サーバー、時刻サーバー、ネットワークファイルサーバー、ファイルレプリケーションサーバー、クライアントファイルアクセス、クライアントOS更新、クライアント構成管理、クライアントアプリケーション管理、メール、印刷、監視までの依存関係を示す。* 1. **バージョン管理**(前提: なし)— CVSでOS設定ファイル・OSおよびアプリケーションのバイナリ/ソース・管理スクリプトを追跡し、変更の追跡・巻き戻し・複数インフラへの移植を可能にする。 2. **ゴールドサーバー**(前提: バージョン管理)— インフラ内で唯一CVSで直接管理する受動的なマシン。他の全マシンへの変更は必ずゴールドサーバーから伝播させ、直接ログインして変更しないという規律を徹底する。 3. **ホストインストールツール**(前提: ゴールドサーバー)— デスクトップとサーバーを同一の方法で管理し、人手を介さずに新規ホストをインストールできるようにする。パッチなしの最も素の(vanilla)OSイメージを使い、初回起動時にゴールドサーバーへ接続するフックのみを組み込む。 4. **アドホック変更ツール**(前提: rshd/sshd/telnetdが動く壊れた状態のインストール済みホスト)— `expect`ベースの自作ツール「rabbit」で、インストール直後に欠けている要素を緊急に修正する用途に限定して使う。日常的な push型変更には使わない。 5. **ディレクトリサーバー**(前提: ホストインストールツール)— DNS・NIS・LDAP等でホスト名解決やUID/GIDマッピングを提供する。 6. **認証サーバー**(前提: ディレクトリサーバー)— NISやKerberosで単一の認証点を提供する。ディレクトリサービス(一方向信頼)と認証サービス(双方向信頼)を区別する。 7. **時刻同期**(前提: ディレクトリサーバー)— NTPでファイルタイムスタンプの整合性を保つ。金融取引では時刻のずれが実損につながりうる。 8. **ネットワークファイルサーバー**(前提: ディレクトリサーバー・認証サーバー・時刻サーバー)— NFSを中心に、デスクトップとサーバーのディスクイメージ差分を最小化する。 9. **ファイルレプリケーションサーバー**(前提: ディレクトリサーバー・時刻同期)— Carnegie MellonのSUPで/etc以下を6分ごと、/usr/localを1時間ごとに同期する(800クライアント規模のトレーディングフロアでの実績)。 10. **クライアントファイルアクセス**(前提: ネットワークファイルサーバー・ファイルレプリケーションサーバー)— automounterとシンボリックリンクファームで、ローカル/リモートのどちらに実体があっても同一の名前空間に見せる。 11. **クライアントOS更新**(前提: ネットワークファイルサーバー・ファイルレプリケーションサーバー)— 自作の「Hostkeeper」が起動時にゴールドサーバーへ問い合わせ、`make`をステートエンジンとして使い、`touch`されたスタンプファイルで同一パッチの再適用を防ぐ。 12. **クライアント構成管理**(前提: ネットワークファイルサーバー・ファイルレプリケーションサーバー)— ホスト名・IPアドレスなどホスト固有の値を除き、可能な限り全クライアントで同一のファイルを配布し、異なる部分だけをスクリプトで当て込む。 13. **クライアントアプリケーション管理**(前提: クライアント構成管理)— 自作の「autosup」(SUPでアプリケーションをローカルディスクへ複製)と「autolink」(シンボリックリンクファームを最適な配置先へ更新)を組み合わせる。 14. **メール**(前提: クライアント構成管理)— SMTPベースのメールに統一する。 15. **印刷**(前提: クライアント構成管理)— 新規インフラ稼働後の最初の数日は作業時間の約80%が印刷トラブル対応に費やされたと報告する。 16. **監視**(前提: クライアントアプリケーション管理)— 上記が全て整えば必要な監視は少なくて済んだとする一方、集中syslogdサーバーとページングの整備を怠ったことを反省点として挙げている。 ### push対pull ゴールドサーバーからクライアントへの変更伝播は、push(r-command・rdistなど)ではなくpullであるべきだと強く主張する。r-commandベースのpushスクリプトは30台を超えると必ずダウンしているホストが出て、タイムアウト処理・リトライ・ソケット枯渇対策などの複雑なラッパーコードが必要になり、実用に耐えないと報告する。pull方式(SUP、CVSup、cfengineのようなツール)では、各クライアントが自分の都合でゴールドサーバーに接続して自分のリビジョンレベルを維持する責任を負う。 ### クライアントOS更新の実装(Hostkeeper) Hostkeeperは起動時の構成適用と継続的な保守という2つの基本機構からなる。起動時、ゴールドサーバーの`/is/conf`(NFSマウント)を参照し、`make`をステートエンジンとして使う。プラットフォームごとのMakefile(`Makefile.{platform}`)のターゲットは航空宇宙業界から借用した「block」という用語(block00=素のマシン、block10=最初のパッチ層、…)で表され、各パッチスタンザ末尾の`touch`コマンドが同じスタンザの再実行を防ぐ。 ``` block00: localize block10: block00 14235-43 xdm_fix01 14235-43 xdm_fix01: /is/conf/patches/$(PLATFORM)/$@/install_patch touch $@ localize: /is/conf/bin/localize touch $@ ``` *Listing 1: Hostkeeper makefileの例(block00/block10のパッチ適用と、touchによる冪等な再実行防止)。* 異種OS/ハードウェアの命名は`/usr/local/bin/platform`スクリプト(`uname -a`を整形したもの、例: `sunos_4.1.4_sparc`)で解決し、自動マウントやビルドファイルなど至るところで参照する。 ![[fig02-heterogeneous-usr-local-sup-tree.png]] *図2(Figure 2): 異種プラットフォーム混在の/usr/local SUPサーバーツリーの例。プラットフォーム名ごとのディレクトリの下にbin/lib等を配置する構成。* ### 既存インフラの移行 移行は「新しい仮想マシンを起動し、既存ハードウェアをその仮想マシンへ移住させる」作業として捉える。デスクトップ機については、(1)ホストインストールツールで置換用ホストを新規作成、(2)ユーザーをログオフさせる、(3)データをNFSサーバーへ移行、(4)automounterマップに新しいNFSディレクトリを追加、(5)新クライアントをデスクに置く、という手順を推奨する。著者らの経験では、既存の100ホストインフラを1ファイルずつ収束させようとした場合は1年経っても完了しなかったのに対し、ホストを丸ごと置き換える方式では管理者0.5人でも3か月未満でフルコンバートできた。 ## 新規性 - インフラストラクチャ全体を「単一の疎結合な分散仮想マシン」とみなす思考モデルを提示し、ノード管理・認証・アプリケーション配布・障害復旧の設計判断を一貫した比喩の下に統合した点。 - 個々のツール論ではなく、16ステップの依存関係を持つ「Infrastructure Bootstrap Sequence」という順序立ったロードマップとして、インフラ構築・移行の手順を体系化した点(当時この規模を扱う文献がほとんど存在しなかったと著者ら自身が述べている)。 - push型のアドホック変更ツール(r-command系)を明確に否定し、pull型配布(SUP・CVSup・cfengine相当)を推奨する設計原則を、実運用での障害事例(30台超で必ずダウンホストが出る)に基づいて論証した点。 - 「ゴールドサーバーは受動的であり、他のマシンへは直接ログインして変更しない」という規律を明文化し、CVSによるバージョン管理と組み合わせることで変更の再現性・追跡可能性・巻き戻し可能性を確保した点。 ## 実験設定 査読論文的な実験セクションは持たず、4年間・300〜1000台規模(延べ約15,000ホスト)の複数の実運用金融取引フロアインフラ、およびNASA Amesでの経験から得られた事例報告(ケーススタディ)として構成されている。定量的な比較実験ではなく、実運用での障害・移行・災害復旧の実例を根拠として提示する。 ## 実験結果 - 800クライアント規模のトレーディングフロアで、SUPにより`/etc`以下を6分ごと、`/usr/local`を1時間ごとに同期できた。 - 開発用インフラを災害復旧サイトとして流用し、本番トレーディングフロア(サーバー含む)全体を2時間以内に復旧できた(共有ハードウェアやスタンバイ機材なしで)。 - 既存100ホストインフラの移行で、ホスト置換方式は管理者0.5人×3か月未満でフルコンバートを完了したのに対し、1ファイルずつの収束方式は1年経っても完了しなかった。 - 定量的な厳密測定はできていないと断りつつ、この手法群によりシステム管理コストを最大1桁削減できたと報告する。 ## 考察 著者らは、ファイルレプリケーション(SUP)とMakefileベースの状態エンジン(Hostkeeper)という2つの異なる機構を併用したことについて、実運用上は問題を起こさなかったものの、両者の適切な役割分担が本来はより明確に定義されるべきだったと自己批判している。また当時のcfengineは開発初期段階だったため採用を見送ったが、もし今から作るなら`make`の代わりにcfengineを使っていただろうと述べており、Hostkeeperのmakeベースの状態エンジンは事実上cfengineの前段階の代替実装だったことを示唆している。著者らはインフラ構築を担う人材のキャリアパス(「インフラアーキテクト」と「シスアドミン」の違い)についても論じ、両者は必要とするマインドセット・スキルセットが異なる別の職種だと主張している。 ## 強み / 弱点・課題 - 強み: 個別ツールの紹介にとどまらず、依存関係を持つ順序立った手順(bootstrap sequence)として大規模インフラ構築を体系化し、push対pullという設計原則を実運用の障害事例で裏付けた点。ゴールドサーバーの受動性という規律がバージョン管理・再現性・障害復旧を一貫して支える中心的な設計判断として機能している。 - 弱点・課題(本文に明記された限界): 定量的な厳密測定(ベンチマーク)は行っておらず、コスト削減効果は著者ら自身の主観的評価に基づく。SUPとMakefileベースの状態エンジンの役割分担が明確に定義されていなかったと自ら認めている。中央syslogdサーバーの構築を怠り、ページングも安定して機能していなかったと反省点を述べている。ファイル交換プロトコルSUP・cfengine初期版・r-commandsなど、2020年代の読者には既に廃れたツール名が中心であり、個別ツールの実装詳細は現代の実務には直接適用できない。