第2部：アーキテクチャの構成要素 on Designing Network Automation at Scale

04 - Source of Truth

Mon, 01 Jan 0001 00:00:00 +0000

4. Source of Truth#

新しいサービスを週末までに本番稼働させる必要があった。変更内容は単純だった。新しいVLAN、新しいサブネット、ファイアウォールルールの更新、エッジルーターへのBGPコミュニティの追加。担当のネットワークエンジニアは何をすべきかを正確に把握していた。ところが実際には、5つのシステムにまたがる4日間の調整作業が待っていた。サブネットを予約するIPAMツール、サービスを登録するCMDB、新しいポリシーを適用するファイアウォール管理プラットフォーム、BGPコミュニティを設定するルーター構成システム、そして新しいしきい値を追加する監視プラットフォーム。各システムはそれぞれ独自のインターフェース、独自のデータモデル、独自の承認ワークフローを持っていた。共通の参照点がなかったため、エンジニアは手動でコンテキストを持ち回るしかなかった。あるシステムから値をコピーして次のシステムに貼り付け、途中でデータが変わっていないことを祈りながら。

6カ月後、そのサービスは廃止された。VLANは削除され、サブネットも解放された。しかしファイアウォールルールはそのまま残った。そのルールがそのサービスに紐付いていたことを誰も覚えていなかった。BGPコミュニティは2台のエッジルーターに残り続けた。監視のしきい値は低優先度のアラートを出し続けたが、NOCはいつしかそれを無視することを学んでいた。時間とともに、ネットワークには孤立した設定が積み重なっていった。完全に追跡されず、完全に削除されず、共通の意図の記録に紐付けられることもなかった変更の残骸が。

これが、Source of Truth なしにネットワークを運用するということの実態だ。一度の劇的な障害ではなく、じわじわと積み重なる不整合。すべての変更が複数の分断されたシステムの更新を必要とし、何が関連しているかを追い続けるものが何もない状態。

すべての自動化システムは一つの問いから始まる。実際に何をしようとしているのか? ファイアウォールルールを展開するとき、IPアドレスを追加するとき、VLANを設定するとき、あなたは何らかのインテントの表現に基づいて行動している。その表現こそが Source of Truth だ。つまり、何が展開されるべきかを示す、唯一の信頼できるバージョン。

「Source of Truth」と「Intent」は本書では同じ意味で使用している。概念としてまったく同一だ。

信頼できる Source of Truth なしでは、ネットワーク運用は属人的な知識の塊になってしまう。エンジニアは何が展開されているかで意見が食い違う。スプレッドシートは実際に動いているものと矛盾する。2つの異なる自動化システムが同じデバイスに対して競合する変更を加える。何かが壊れると、考古学者のような作業が始まる。「なぜこう設定されているのか? 誰が承認したのか? いつ変わったのか?」

本章では、デバイスが数十台であれ数十万台であれ機能し、データを必要とするすべての人(人間、自動化、他のシステム)に提供し、データの正確性と信頼性を維持し、複数のソースからのデータ収集の複雑さを処理できる Source of Truth の構築方法を解説する。6つの構成要素を取り上げる。Modeling、Consumption、Enforcement、Versioning、Aggregation、Design-Driven だ。これらが組み合わさることで、ネットワーク自動化の堅固な基盤が生まれる。既存のネットワークをこのシステムに取り込む際の実践的な課題にも触れ、実際に利用可能なソリューションも紹介する。

4.1. 基本原則#

Source of Truth は3つのことを行う。インテントをどう表現するかの方法を定義し、そのインテントがどこに存在するかを定め、それを長期にわたって信頼できる状態に保つ方法を確立する。これがなければ、他の構成要素は共通の参照点を持たない単独ツールの集まりになってしまう。これがあれば、それらは連携して機能する。

4.1.1. ゴール#

Source of Truth が果たすべき6つの役割がある。

必要なすべてを把握する。ネットワークの全体像を保存する。設定、資産、トポロジー、サービス、IPアドレス、回線、デバイス仕様、認証情報、メンテナンスウィンドウ、コンプライアンス要件、所有者情報。現在稼働しているものだけでなく、計画中のものと廃止予定のものも含める。このデータがスプレッドシートや担当者の頭の中ではなく一か所に集まって初めて、自動化システムは賢い判断を下すために必要なコンテキストを手にできる。
オペレーターがビジネスの言葉で考えられるようにする。スタッフはビジネスレベルで作業すべきだ(「新しいブランチを追加する」や「MPLSサービスをセットアップする」など)。Command Line Interface (CLI) レベルで作業するのではなく。裏側で、システムが実際のデバイス固有の設定を導き出す。こうすることで、人は低レベルの詳細ではなく、達成しようとしていることに集中できる。
人とシステムが簡単にデータにアクセスできるようにする。自動化がデータを取得・更新できるよう Application Programming Interface (API)(Representational State Transfer (REST), GraphQL)が必要だ。人間が閲覧・編集できるよう Web UI と Command Line Interface (CLI) も必要だ。すべての人に対して、見るべきものだけが見えるアクセス制御が必要だ。数百の自動化ワークフローが同時に動き、数十のスタッフがデータを編集し、外部システムが同期していても、一貫性とパフォーマンスが保たれる必要がある。

05 - Execution

Sat, 01 Nov 2025 00:00:00 +0000

5. Execution#

Playbookは何カ月も完璧に動作していた。ラボの10台のアクセススイッチに対してエンドツーエンドで2分、毎回クリーンな結果。チームが800台のスイッチの全インベントリにロールアウトすることを決めたとき、誰も問題を予想しなかった。最初の600台のデバイスは問題なく更新された。そしてジョブが遅くなった。そして止まった。RADIUSサーバーが突然150件の同時SSH認証リクエストを受け取り、接続を拒否し始めた。Ansibleは150台のデバイスの実行途中でハングした。エンジニアがジョブを強制終了した。

次に来たのがより難しい問題だった。600台のデバイスのどれが更新されて、どの150台がそうでないか、誰にも分からなかった。実行状態が記録されていなかった。Playbookを再実行して、冪等性が助けてくれることを願った。その時は助かった。しかしこのインシデントは重要なことを明らかにした。実行レイヤーはラボ向けに設計されており、ネットワーク向けではなかった。速度、並列処理、エラー境界、状態追跡、何も考慮されていなかった。自動化は機能していた。実行アーキテクチャが機能していなかった。

多くの人はネットワーク自動化を「同じデータを使って、人間としてCLIに接続せずに、ネットワークで何かをする」と考える。ネットワーク自動化を始める多くの人がそこから始めると思う。そしてそれが Execution ブロックの行うことだ。しかし本書全体で見てきたように、ネットワーク自動化はこの最初のステップより大きく、Executionはアーキテクチャ内のひとつのコンポーネントに過ぎない。

Execution ブロックは最も危険な操作(設定変更や再起動など)のためにネットワークと直接やり取りする。だからこの章を飛ばさないこと。正しく行うことが重要だ。

この章では、このブロックが提供するゴールと柱、それを達成するために必要な内部機能について解説する。

5.1. 基本原則#

5.1.1. コンテキスト#

Executionはどのようにアクションを実行するかを定義する。何を行うかはIntentブロックから、いつ行うかはOrchestrationから来る。

初期のネットワーク自動化プロジェクトでは、特定のデバイスとインターフェース名に対してインターフェースをバウンスするスクリプトが最初の成果となることがある。その旅は、はるかに洗練されたシステムへと成長する可能性がある。

5.1.2. ゴール#

実行システムが実際に行うべきことは何か? 5つのことが重要だ。

適切なデータを準備する。 何かを実行する前に、何を実行するか(インテント)、どこで実行するか(どのデバイスに)、どのようにアクセスするか(認証情報、接続の詳細)を知る必要がある。これはSource of Truth(第4章で詳述)からインベントリを取得し意図された状態をフェッチすることを意味し、時には現在の状態を把握するためにオブザーバビリティデータをクエリすることも含む。この統合なしでは、実行エンジンはただ盲目的にコマンドを実行するだけだ。精神的健康のために、それは避けること。
今すぐでも後でも、必要なときに開始する。 即時の実行が必要なこともある。エンジニアが「デプロイ」をクリックして、すぐに実行されることを期待する。また、実行を待機させるべき場合もある。メンテナンスウィンドウ中にデプロイする、デバイスがオンラインになるまで待つ、オブザーバビリティからのイベントに反応する、などだ。システムは同期と非同期の両方のトリガーをサポートする必要がある。
時間の経過とともに状態を追跡する。 ネットワーク全体の操作は瞬時ではない。数時間かけて数百台のデバイスにデプロイすることがある。どのデバイスが成功したか? どれが失敗したか? どれがまだ保留中か? 状態管理はまた冪等性(同じタスクを2回実行しても同じ結果)、ロールバック(行ったことを元に戻す)、再開(失敗後に中断した場所から再開)を可能にする。状態追跡なしでは、すべての実行が一発勝負のギャンブルになる。
スケールで確実に実行する。 5台のデバイスで動くスクリプトは500台ではしばしば壊れる(または劣化する)。並列実行、エラー処理、リトライ、レート制限、ドライラン機能が必要だ。システムは部分的な失敗を適切に処理し、何が問題だったかを明確にフィードバックし、ネットワークを未定義の状態に放置しないこと。操作によって異なる戦略が必要だ。高速で並列なものもあれば、低速でシリアルなものもある。
あらゆるネットワークデバイスやプラットフォームで動作する。 ネットワークにはおそらくCisco、Arista、Juniper、クラウド Application Programming Interface (API)、Linuxボックス、ファイアウォール、ロードバランサーがある。それぞれが異なるプロトコルを使い、異なる操作パターンを持つ。実行レイヤーはそれらすべてへのアダプターが必要で、残りの自動化が違いを気にしなくてもよい共通インターフェースを持つ。

これらのゴールを念頭に置いて、実際に必要なアーキテクチャ機能は何か?

5.1.3. 柱#

各ゴールは特定の機能に対応する。

データ統合レイヤー。 実行エンジンは孤立して存在しない。Source of Truth(インベントリ、認証情報、インテント)、オブザーバビリティシステム(現在の状態、ヘルスメトリクス)、そして潜在的に他のシステム(チケット、変更管理、承認ワークフロー)へのプログラム的なアクセスが必要だ。これは Application Programming Interface (API) クライアントの実装、認証の安全な処理、データの適切なキャッシング、実行開始前に必要なものがすべて揃っているかの検証を意味する。

06 - オブザーバビリティ

Mon, 01 Jan 0001 00:00:00 +0000

6. オブザーバビリティ#

あるサービスプロバイダーのコアルーターで、ファンモジュールが夜間に無音で故障した。アラートは何も発生しなかった。ラインカード上の熱管理サブシステムが温度上昇を検知し、ハードウェアを保護するためにフォワーディングASICのスロットリングを開始した。本番トランジットリンクのスループットが40%低下した。監視システムは何も捉えなかった。ポーリングしていた温度センサーはシャーシスーパーバイザー上のものであり、個々のラインカード上のものではなかったのだ。SNMPポーリングは5分おきに実行されており、デバイスは正常と報告されていた。インターフェースカウンターはスループット低下を示していたが、そのリンクはずっと容量に余裕があったため、そのパターンに対するしきい値が設定されていなかった。

3時間後、顧客SLA違反がチケットを生成した。オンコールエンジニアがルーターにSSHし、ローカルアラームログでファンの故障を発見し、ファンモジュールを再起動した。ファンコントローラーが再起動し、熱スロットリングは数分で解除された。トラフィックは回復した。SLA違反が文書化され、顧客に通知され、インシデントはクローズされた。

根本原因は最後まで確認されなかった。調査が始まるころにはルーターは何時間も正常稼働していた。ラインカードの温度データもスロットリングイベントの記録もなく、どの監視システムにもスループット低下とファン故障を関連付ける手段がなかった。インシデントレポートの結論は「ハードウェア問題と推測、ハードウェアリセットで解決」だった。6ヶ月後、別のルーターで同じ事象が起きた。

この失敗はしきい値の欠如ではなかった。チームには数千ものしきい値があった。失敗は対象範囲の不完全さにあった。監視システムは従来からポーリングしていたソースからデータを収集していたが、デバイスの動作に影響しうるすべてのソースからは収集していなかった。3種類のシャーシすべてでgNMI経由のラインカード温度データは利用可能だった。ファン故障のためのランブックを誰も書いていなかったから、誰もその収集パスを設定しなかったのだ。

従来のネットワーク監視は壊れているものを監視する。インターフェースは上がっているか？CPUは90%を超えているか？このサービスは応答しているか？それは有用だが、リアクティブだ。障害を待ち受けているだけである。

オブザーバビリティは異なる。なぜ壊れているのか、あるいは壊れかけているのかを理解することだ。「あのデバイスがダウンしている」ではなく「なぜダウンしているのか、何がそれで壊れているのか、ビジネスへの影響は何か」という問いに答える。ネットワーク自動化において、オブザーバビリティはフィードバックループになる。何かを観察し、システムがそれを検知し、対応を決定し、アクションを実行し、修正が機能したことを検証する。このサイクルが繰り返されることが「クローズドループ自動化」だ。

本章では、ネットワークで起きていることを把握するために必要なすべてをカバーする。どのデータを収集するか、どうやって収集するか、どう保存するか、どうアラートを出すか、そして意思決定に本当に役立つ形で人々に見せる方法を説明する。

ここでは2つのビルディングブロック、CollectorとObservabilityを扱う。これらは密接に関連しているためだ。

従来のオールインワンプラットフォーム（SolarWinds、LibreNMS）、クラウドサービス（Datadog、New Relic）、オープンソースのピースから自前で構築するスタック（Prometheus、Grafanaなど）のいずれを使う場合でも、基本的なアーキテクチャは同じだ。これらのパターンを理解することで、自分のスケールとチームに合ったアプローチを選択できる。

注記: このセクションでは、例示のためにさまざまなベンダーやソリューションに言及している。これは推薦ではなく、あくまで説明目的である。

このセクションはPacktが出版した書籍Modern Network Observabilityから大きな影響を受けている。私はDavid FloresとJosh Vanderaaと共著したその書籍で、TPG（Telegraf-Prometheus-Grafana）スタックやその他のツールを用いた実装を手を動かして学びたい場合には、ぜひ参照してほしい。

6.1. 基礎#

低レベルの詳細に入る前に、ネットワーク自動化戦略の中におけるネットワークオブザーバビリティの基礎を確立し、そのゴール、支持する柱、およびスコープを定義する。

6.1.1. コンテキスト#

おそらく、すでにネットワークを監視しているだろう。Simple Network Management Protocol (SNMP)を使い、System Logging Protocol (Syslog)を見て、リンク使用率を示すダッシュボードを持っている。それが監視だ。物事が機能しているかを教えてくれる。

07 - オーケストレーション

Mon, 01 Jan 0001 00:00:00 +0000

7. オーケストレーション#

ネットワークチームはすべてを正しく行っていた。堅固な信頼できる情報源（SoT）があり、すべての操作に対してテスト済みのPlaybookがあり、それらを実行するための明確なランブックがあった。書類上では、新しいVLANサービスのデプロイは完全に自動化されていた。実際には、半日と特定のエンジニア一人が必要だった。

そのエンジニアはシーケンスを知っていた。まず、SoTデータが完全であることを検証する。次に事前チェックPlaybookを実行する。次に出力を確認し、失敗したデバイスを探し、続行するかどうかを決める。次にデプロイメントPlaybookをトリガーする。次に待つ。次に検証Playbookを実行する。次にServiceNowチケットを手動で更新する。途中でデバイスが失敗した場合は、他のデバイスが気づく前にロールバックする。彼女はそれをすべて、誰も完全に内面化していない共有ドキュメントのランブックにステップごとに持っていた。

彼女が休暇に入ると、デプロイメントが止まった。ジュニアエンジニアがシーケンスを試みて順序を間違えると、ネットワークは6時間部分的な状態のままだった。自動化は存在していた。調整は依然として手動だった。

それがこの章が解決する問題だ。オーケストレーションは、自動化ツールのコレクションを一体として動作するシステムに変えるビルディングブロックだ。他のブロックを調整し、いつ実行するかを決定し、障害を優雅に処理し、すべての決定を追跡し、エンジニアが手でフローを管理しながら中間に立つことなくこれらすべてを行う。

7.1. 基礎#

7.1.1. コンテキスト#

これまでカバーしてきたすべてのビルディングブロックはそれぞれ1つのことを得意とする。SoTはインテントを保持する。Executorはそれを適用する。コレクターは状態を取得する。オブザーバビリティはその状態を理解する。それぞれは専門家であり、専門家にはコネクターが必要だ: 各ブロックがいつ行動すべきかを決め、結果をどう処理するかを決め、何かがうまくいかないときにどう回復するかを決めるもの。

そのコネクターがOrchestratorだ。

第3章では、他のすべてを調整するブロックとしてNAFフレームワークの中心に置いた。第5章はExecutorが設定変更をどう適用するかを示した。第6章はオブザーバビリティが結果をどう検証するかを示した。本章ではオーケストレーターが両方をどう順序付けし、その間で起こりうるすべての問題をどう処理するかを示す。

オーケストレーションなしには、自動化を実行していない。誰かが正しい順序で、正しいタイミングで、正しい方法で解釈して呼び出さなければならないスクリプトを実行しているだけだ。それは名ばかりの自動化だ。

7.1.2. ゴール#

オーケストレーターは5つのゴールを達成する必要がある:

マルチブロックワークフローをエンドツーエンドで調整する。 デプロイメントは単一のアクションではなく、シーケンスだ。SoTのインテントを検証し、事前チェックを実行し、設定を実行し、結果を検証し、ステークホルダーに通知する。オーケストレーターがフルシーケンスをまとめて保持する。
人間の開始の有無にかかわらず、自動的にイベントに反応する。 ServiceNowの承認、オブザーバビリティのアラート、スケジュールされたコンプライアンスのスキャン: これらはすべて人間が手動で開始しなくてもワークフローをトリガーできる必要がある。
耐障害性とスケーラブルな実行。 800のスイッチを並列で操作するワークフローは確実に完了しなければならない。再起動を生き延びなければならない。成功したデバイスの作業を失うことなく部分的な障害を処理しなければならない。
改ざん防止の可視性を提供する。 オペレーターは今何が実行されているかを見る必要がある。監査員は先月何が実行されたか、誰がトリガーしたか、どのバージョンのワークフローが実行されたか、すべてのステップが何を生成したかを見る必要がある。両方のニーズが同じシステムから満たされなければならない。
ワークフロー定義を本番ソフトウェアとして管理する。 800のスイッチにデプロイするワークフローは不用意に変更できない。ロジック自体が、本番で動作する他のコードに適用されるのと同じ規律で永続化、バージョン管理、テスト、本番へのプロモーションが必要だ。

7.1.3. 柱#

5つの柱がこれらのゴールを支える:

ワークフローエンジン: 多段階プロセスの定義、実行、追跡
トリガーレイヤー: 手動、スケジュール、イベント駆動、Webhook
耐障害性実行: ワークフローが再起動を生き延びる。数百のデバイスにわたってデバイスごとのボトルネックなしにリトライ、ロールバック、並列操作をサポートする
監査とオブザーバビリティ: すべてのステップをログに記録し、すべての決定を追跡可能にする
パイプライン管理: ワークフロー定義を本番で安全に永続化、バージョン管理、プロモーションする

7.1.4. スコープ#

オーケストレーターは調整する。行動しない。

スコープ内:

他のビルディングブロックの調整
ワークフローロジックとステップ依存関係の定義
複数のソースからのトリガー処理
実行状態の追跡と監査証跡の生成
ステップが失敗したときのロールバック決定の管理

スコープ外:

08 - プレゼンテーション

Mon, 01 Jan 0001 00:00:00 +0000

8. プレゼンテーションレイヤー#

VLAN自動化は6週間稼働していた。ネットワークチームはそれを誇りにしていた。毎朝、アプリケーションチームから3〜4件の新しいサービスリクエストが届き、ネットワークチームの誰もキーボードに触れることなくオーケストレーターが処理した。デプロイメントは機能した。スイッチは設定された。ネットワークは健全だった。

エスカレーションは木曜日に届いた。アプリケーションチームのリードが、ポータルで「提出済み」と表示されているのにVLANリクエストが3〜5営業日かかる理由を尋ねていた。ネットワークチームはキューを確認した: 保留中のリクエストはゼロで、すべてのデプロイメントは成功していた。自動化は受信から20分以内にすべてのリクエストを処理していた。しかし、ServiceNowチケットはまだ「進行中」と表示されていた。チケットを更新する統合を誰も書いていなかったからだ。

自動化は仕事をしていた。結果が見えなかっただけだ。

1週間後、チームはアプリケーションチームがリクエストを直接提出してステータスを確認できるクイックなセルフサービスポータルをデプロイした。正午までに1時間で47件のVLANリクエストを受け取った。すべて有効だった。すべて正しくフォーマットされていた。問題は、ポータルに認証モデルがなかったことだ。URLを持っている誰からでも提出を受け付けた。すべてのリクエストはプラットフォーム全体の管理者権限を持つ単一のAPIトークン下で実行された。レート制限もなく、承認ゲートもなく、誰が何を提出したかの監査証跡もなかった。

自動化は機能した。アクセスモデルが機能しなかった。

これら2つの失敗はどちらもプレゼンテーションの失敗だ。1つはフィードバックループの欠如で、もう1つはガードレールの欠如だ。本章はそのギャップを埋める。

8.1. 基礎#

8.1.1. コンテキスト#

これまでカバーしてきたすべてのビルディングブロックは内側を向いている: 他のブロックに向けて、またはプラットフォームを構築して運用するエンジニアに向けて。Source of Truth (SoT)は自動化システムのためにネットワークインテントを保持する。ExecutorはデバイスにChangesを適用する。Observabilityは結果を検証する。Orchestratorはそれらすべてを調整する。これらのブロックそれぞれにUIとAPIまたはその両方があり、プラットフォームを構築して運用する人々のために設計されており、それとやり取りする必要があるすべての人のためではない。

09 - ネットワーク

Mon, 01 Jan 0001 00:00:00 +0000

9. ネットワーク#

VLANの自動化はラボで3週間稼働していた。3台のスイッチ、ベンダーごとに1台ずつ、すべてのワークフローが通過した。チームは自信を持っていた。最初の本番実行で、800台のキャンパススイッチのうち23台が失敗した。すべてHPEだった。すべて、誰もドキュメント化していなかったファームウェアバージョンを実行していた。

PlaybookはVLAN設定をプッシュした後、各デバイスからのエラーレスポンスを確認していた。モダンなHPEファームウェアでは、すでに存在するVLANはエラーコードduplicate-vlanを返す。この古いファームウェアバージョンでは、同じ条件がvlan-existsを返した。Playbookはduplicate-vlanをべき等シグナルとして扱うように書かれていた。つまり「これはすでに存在している、問題ない」という意味だ。vlan-existsを処理するようには書かれていなかったので、そのレスポンスを失敗として扱った。HPEフリートの3分の1が失敗を報告した。ロールバックはクリーンに実行された。ネットワークチームが実際に設定されたスイッチとそうでないスイッチを手動で監査する間、アプリケーションチームのチケットはさらに3時間オープンのままだった。

自動化は間違っていなかった。ネットワークに、誰もドキュメント化していなかった意見があったのだ。

6ヶ月後、同じチームはBuilding Bを反映したcontainerlabトポロジーを持っていた: 24台のスイッチ、一致するベンダーイメージ、HPEノードはSource of Truth (SoT)に記録された本番ファームウェアバージョンにロックされていた。そのトポロジーに対するVLANワークフローの最初のテスト実行で、8台のHPEノードがまさにそのエラーコードで失敗した。チームはHPEアダプターのべき等レスポンスのリストにvlan-existsを追加した。再実行: 24台のノードすべてが通過した。本番デプロイメント: 800台のスイッチ、ゼロの失敗。

違いは良いコードではなかった。現実を反映したテスト環境だった。

本章ではパート2を通じて常に暗黙的だったブロックを扱う: ネットワーク自体だ。これまで構築してきたすべてのビルディングブロックは自動化チームによって設計され、ドキュメント化されたインターフェースに従って動作する。ネットワークは受け継いだものだ。それには癖があり、多様なインターフェースがあり、ファームウェアの不整合があり、ベンダー、プラットフォーム、ソフトウェアの世代によって異なる機能がある。第9章は2つの問いを扱う: 自動化を確実にするためにネットワークに何が必要か、そして本番に触れる前に自動化ロジックをどう安全に検証するか？

9.1. 基礎#

9.1.1. コンテキスト#

第3章では、NAF Frameworkの7つのブロックの1つとしてネットワークを導入した: 自動化チームが「所有」しない唯一のブロック（ネットワークエンジニアリングのスコープにある）。彼らはそれを設定し、観察し、そのインテントをモデル化するが、オペレーティングシステム、データモデル、またはAPIインターフェースは構築しなかった。その依存関係は、その上のプラットフォームのすべての設計決定を形作る。