ネットワーク設計入門:初歩の初歩

    本ページは英語ドキュメントを翻訳したものです。

     


     

    ネットワーク設計入門:初歩の初歩

    はじめに

    私たちの大半は、ネットワーク構成図について(ネットワーク エンジニアとして)考察していたら、突然いくつかの疑問が心に浮かんだという経験を何度かしているのではないでしょうか。たとえば、「この図は最適なのか」、”“「改善する方法はないだろうか」、”“「改善できるとしたらどうしようか」というような疑問です。”


    この記事では、ネットワークの設計に関する初歩的な視点を紹介し、工程を進めているうちに起こりうる状況や状態について共有していきます。それらの状況は設計の最終結果に影響を与えるものであり、こうした状況を念頭に置いて適切な心構えで作業すれば、結果を良いものにできるはずです。


    この投稿の目的は、懸念事項、メリット、障害、ネットワーク設計の作成にあたってアーキテクチャに従わなければならないタイミング、そして環境における状況が変化したときに何が起きるのかについて明らかにすることです。実装の視点から見た技術的な内容については詳しく取り上げません。設計は厳密な科学ではなく、ゴールを達成するための方法は複数あるためです。


    ネットワーク アーキテクチャとネットワーク設計

    この投稿を執筆する過程で、以下で取り扱う情報については、何人かの専門家による協力のもと、チェックと検証を受けています。その過程で私は、ネットワーキングにおいて使用される「アーキテクチャ」と「設計」という言葉の意味について、興味深い話題に出会いました。プロセスには複数のビジョン、技術、視点が関与することから、対応する定義の意味は、人によっては不明確で不正確なものになってしまっています。また、関係する役割や人が異なれば、そうした定義の意味が変わってしまうこともあるのは明らかです。協力していただいた専門家たちは全員、自分の視点から適切な知識を提供してくれました。次の段落は、そうした人々からのアドバイス、知識、そして経験をまとめた成果です。


    エンタープライズ アーキテクチャの開発に使用されるフレームワークであるオープン グループ アーキテクチャ フォーラム [英語] (TOGAF)によると、「アーキテクチャ」という言葉は以下のようにして定義されるとのことです。


    1. システムの公式な説明、またはコンポーネント レベルでのシステムの詳細な計画であり、そのシステムの実装をガイドする(出典:ISO/IEC 42010:2007)。

    2. コンポーネントの構造、コンポーネントの内部的な関係、およびコンポーネントの設計や発展を経時的に統制するための指針およびガイドライン。


    また、テクノロジー アーキテクチャについては、以下のように具体的に説明されています。


    テクノロジー アーキテクチャは、ビジネス、データ、およびアプリケーションの各サービスをサポートするために必要な、論理的なソフトウェアおよびハードウェアの機能である。これには IT インフラストラクチャ、ミドルウェア、ネットワーク、通信、処理、標準などが含まれる。



    この概念の背景にある主要な目的はそのままに、説明を理解しやすくするために(そうなると良いのですが)言い方を少し変えると、アーキテクチャとは「全体像」だと考えることができます。「全体像」の主な目的は、現状から最終的な状況に至るまで、ネットワークのモデル化、形成、整形を構想することにあります。ネットワーク設計とは、結局は制約を踏まえつつ、ビジネスのニーズおよび要件やアプリケーションの要件を満たす物を作るということに尽きます。つまり、ネットワークを造形し、詳細を設定し、作り上げることだと考えることができます。


    環境に関するアプローチ

    考えられるシナリオには次の 2 つがあり、これらのシナリオに対処するために必要なアプローチを理解しておくことが重要です。これらのシナリオについて説明します。


    新規:新規の環境には、以前の作業による制約が一切ありません。つまり、何もない状態からすべての構築を開始する環境のことです。


    既存:新規の環境とは異なり、既存の環境には以前の作業による制約が存在します。実際に稼働している設定済みのネットワークを変更する必要があります。現実には、これがよくあるケースです。


    双方のシナリオに対するアプローチは、対処する条件に応じて異なります。先に説明した用語を使って説明すると、既存の環境ではネットワークをビジネスおよびアプリケーションの要件に合わせて形成する必要があり、既存の設計と稼働しているインフラストラクチャが存在することから、これまでの制約について念頭に置いておく必要があります。一方、新規の環境では、ネットワークを最初から設計するため、初めからその概念に合わせて検討された要件に合わせた状態で作成し、提供します。


    先ほど述べたように、私たちがネットワークを作成するには、現状をどのような形にするかを理解していなければなりません。芸術家が彫像を彫るには、彫るものの形やインスピレーションが頭の中になければならないのと同じです。ここで、私たちはビジネス側との交流が必要になります。


    どの設計モデルに従うべきかを理解し、実装する技術やトポロジ、そして実装方法を理解するために、私たちはビジネス側と対話しなければなりません。実装の目的が何であっても、ビジネス ニーズを最初から明確化しておくことが必要です。このフェーズには困難が伴う場合があります。管理スタッフや技術スタッフからさまざまなビジョンが提示されるためです。


    こんな話があります。もし、技術スタッフに必要なものを尋ねたら、フェラーリを買えるぐらいの予算を要求されるでしょう。しかし、技術スタッフから提示された要件を携えて経営陣のところに行くと、大体の場合、もらえるのは起亜自動車(韓国の自動車)を買う程度の予算でしょう。全員(技術関係者)が 3 秒間で 0 から 100 Kmph になるネットワークを使いたいと思っている(そうでない人がいるはずはありません)にも関わらず、これはビジネス側の視点では最適な結論でない場合もあり、実現可能でなかったり、必要ではないと判断されることさえもあります。賢明な工程は、情報を収集して、両者の折り合いを付けるためにミーティングを行うことです。ビジネス ニーズはどのようなものでしょうか。そして、技術的な視点からそうしたニーズに対応するためにはどうしたらよいでしょうか。各種の技術の中から、特定の技術を実装した成果はどうなるでしょうか。


    こうした要件を念頭に、連係する特定の技術を複数使用して、目標を達成するためのネットワークを設計することができます。この目標には、設計したネットワークを利用できるようにしてアプリケーションが必要とするサービスを提供し、ビジネスが利益を得られるようにすることが含まれているはずです。


    企業が予算上の理由からフェラーリではなく起亜を選ぶことはよくあることです。そして大きな変更が発生した結果、その修正のために、最初にフェラーリを選んだ場合と同じか、場合によってはもっと多くのコストがかかってしまうのです。つまり、予測が常に重要だということです。ディスカッションを行う場合は、現在と将来のことを検討しなければなりません。たとえば、将来導入される技術と予期されるネットワークの拡張を考慮する必要があります。


    ネットワーク設計は厳密な科学ではないため、あらゆるケースに対して完璧に機能する究極のソリューションなどは存在しないものの、具体的なニーズや要件に対しては対応できるということを確認しておく必要があります。誤った設計というのは、唯一、ビジネスおよびアプリケーションの要件を考慮せずに考えられた設計のことです。もちろん、要件があれば制約も存在します。そうした制約の例としては、すでに実装されていて考慮する必要があるレガシーな技術(テクノロジー間の互換性/相互運用性)、単一ベンダー/マルチベンダーの環境(ベンダー固有の技術/オープンな標準)、経済上の制約(限られた予算)、地理的な制約(デバイスの設置場所、地域で利用可能なサービス プロバイダー、WAN 伝送の利用可能性)、アプリケーションの要件/制約(ジッターの許容度、再接続、TCP/UDP ベース、マルチキャスト/ユニキャスト伝送の必要性、データの暗号化)などが考えられます。その他、理解しておく必要がある多数の詳細も設計の結果に影響を与えます。


    ネットワーク設計の原則

    要件と制約に加えて、理想的な設計の概念には、基盤として以下の原則が含まれている必要があります(必ずしもそうなっているとは限らないのですが)。


    階層化:大規模な設計を小規模な領域またはレイヤに分け、領域間の区分を明確にし、機能を割り当てて、その領域を構成するデバイスを使用することが、常に理想的です。各デバイスによって実行される機能は明確に定義する必要があります。

     

    モジュール性:階層化の導入により、モジュール性も強化されます。ネットワークと機能を複数のモジュールまたは領域に区分けすることで、障害が発生したドメインを特定の領域に絞り込むことができます。つまり、特定のモジュール/レイヤ/領域の障害(ハードウェア/ソフトウェア/リンク)は、その領域自体への影響を示しており、ネットワークの他の部分には影響する可能性も、しない可能性もあるということです。


    拡張性:ネットワークのキャパシティは、そのモジュールに属している機能や、その他のレイヤまたはモジュールに影響を与えることなく拡張される必要があります。ネットワークの拡張はモジュール性にも依存するため、他のモジュールの追加に関係する問題でもあります。


    復元力:永続的なサービスの提供に対するユーザまたはビジネスの期待に対応するために、ネットワークの高可用性を確保します。ネットワークは通常の状況、異常な状況(例:デバイス/リンク/ソフトウェアの障害、トラフィックへの大規模な負荷、DoS 攻撃)、およびスケジュールされたイベント(メンテナンス期間など)のいずれの場合にも稼働できる必要があります。可用性の強化を実現するには複数の方法があります。その方法の 1 つが、障害が発生したドメインの間に冗長な接続を設定することです(この接続はチョーク ポイントと呼ばれます)。これにより、ネットワークが障害から回復するまでの時間が短縮され、そのドメインを開始してトラフィックを送信することができます。これにより、障害発生時のサービス提供を保証することができます。


    柔軟性:ネットワークの各セクションを変更できること、新しい技術およびモジュールを追加できること、そして大規模な変更をせずにプロトコル同士が連係できるようにすることです。


    企業は設計の変更を突然決断する可能性があり、そうした場合には「ネットワーク設計にはこうした変更に対応できるだけの柔軟性があるか」という疑問に直面する可能性があることを、常に念頭に置いておきましょう。設計を一からやり直さずに変更を行うことはできますか。


    これまでに説明したようなねじれを避けるためには、できるだけ早くに設計の範囲と目的を設定すると同時に、制約についても考慮することが重要です。設定の後に新しい要件が提示された場合は、その要件を現在の設計に統合する方法や、その要件が合意済みのプロセス全体(スケジュールや費用に関する問題)に与える影響について、クライアントと合意しなければなりません。


    最後に

    このブログは、設計に関する意識の持ち方、考慮事項、背景にある理由を、実際に発生する可能性が大きい、現実の状況や状態とともに説明することを目的としています。趣旨は、設計という言葉を広めて、設計とは単に部品を組み合わせてトラフィックを流し、問題がなければよいというものではないと伝えることです。設計とは、詳細な思考、準備、そして分析を必要とする工程です。


    このブログが、設計に関する皆さんの疑問の解消に多少でも役に立てば幸いです。関連する資料を詳細に見直した後、あらゆる情報をまとめて簡潔に紹介しようと考えました。つまり、混乱を招きやすく把握しにくいトピックや用語を理解できるようにすることが必要だと考え、このブログを執筆しました。

    CLNBanner