システム開発には、アプリケーション、AP基盤、システム基盤・クラウド、ネットワーク、データベースなど、異なる専門性を持つエンジニアが関わります。
本記事では、その中からネットワークエンジニアを取り上げます。
ネットワークエンジニアは、利用者、サーバー、クラウド、外部システムの間で、安全かつ安定して通信できる仕組みを設計するエンジニアです。
企業のシステムでは、単にインターネットへ接続できればよいわけではありません。
利用者の端末から業務システムへ接続する通信、Webサーバーからアプリケーションサーバーへの通信、アプリケーションサーバーからデータベースへの通信、データセンターとクラウドを結ぶ通信、外部企業とのシステム連携など、多数の通信経路があります。
ネットワークエンジニアは、それぞれについて、どこからどこへ通信するのか、どの経路を通すのか、どの通信を許可するのか、障害が発生したときに通信を継続できるのかを設計します。
私自身も、キャリアの中でCisco機器を使ったオンプレミスのネットワークから、AWS Direct Connectを使ったクラウド接続まで経験してきました。
ネットワークの技術は大きく変わりましたが、通信を分離し、必要な通信だけを許可し、障害に備えて冗長化するという基本的な設計思想は変わっていません。
SEの職種全体と、それぞれの役割の違いについては、次の記事で整理しています。
ネットワークエンジニアは何を担当するのか
ネットワークエンジニアが扱う領域は広く、代表的なものだけでも次のようなものがあります。
LAN、WAN
IPアドレス
VLAN
ルーティング
DNS
ファイアウォール
ロードバランサ
プロキシ
VPN
閉域網
クラウド接続
通信経路の冗長化
ネットワーク監視
これだけを見ると、ルーターやスイッチを設定する仕事に見えるかもしれません。
実際のシステム開発では、機器の設定より前に多くの設計があります。
どのネットワークへ何を配置するのか、どの通信を許可するのか、外部システムとはどの経路で接続するのか、障害時にどこへ切り替えるのかを決めなければ、設定する値そのものが決まりません。
ネットワークエンジニアの仕事は、機器へ設定値を入力することではなく、システム全体の通信を成立させる設計を作ることです。
通信経路を設計する
利用者がWebブラウザから業務システムへアクセスする場合を考えます。
利用者のPCから直接Webサーバーへ接続するとは限りません。
社内LAN、ルーター、ファイアウォール、ロードバランサなどを経由し、その先にWebサーバーやアプリケーションサーバーがあります。
アプリケーションサーバーからデータベースへ接続する通信は、利用者からWebサーバーへ接続する通信とは別のネットワークへ分離することもあります。
バックアップ通信は大量のデータを転送するため、業務通信とは別のネットワークを使用する場合があります。
ネットワークエンジニアは、こうした通信を整理して、ネットワーク全体の構成を決めます。
システム全体で必要になる通信経路
ネットワークを分離する
企業システムでは、すべてのサーバーを同じネットワークへ接続するとは限りません。
例えば、利用者から接続されるフロント側のネットワーク、Web／APサーバーとDB間のネットワーク、運用管理用ネットワーク、バックアップ専用ネットワークなどに分けます。
オンプレミスではVLANを使用して、論理的にネットワークを分離する方法があります。
ネットワークを分けることで、不要な通信が流れる範囲を限定し、セキュリティや障害の影響範囲を制御できます。
IPアドレスも、環境や用途ごとに体系的に割り当てます。
本番、開発、テスト、管理などのネットワークを適当に増やしていけば、後からアドレスが不足したり、別システムとの接続時にアドレスが重複したりします。
ネットワーク設計では、現在の構成だけでなく、将来の拡張や外部接続まで考えてアドレス体系を決めます。
ルーティングで通信経路を決める
異なるネットワーク間で通信するには、どこを経由して接続するのかを決める必要があります。
これがルーティングです。
小規模なネットワークで経路がほぼ固定されていれば、ルーターへ通信経路を直接登録するスタティックルートでも対応できます。Cisco機器であれば、ip route コマンドで「このネットワークへ行く通信は、このルーターへ送る」といった経路を設定します。
ネットワークが大きくなり、接続先や経路が増えてくると、各ルーターへ個別に経路を登録し、変更のたびに修正していく運用は複雑になります。
私がネットワークも担当していた頃、システム内部では、ルーター同士で経路情報を交換するRIPを使用していました。
現在はOSPFやBGPなどが広く使われています。
外部ネットワークと接続する際、接続先がOSPFを使用していたため、境界部分で経路情報をどのように扱うかを相手側のネットワーク担当者と調整したことがあります。
RIPとOSPFを同時に使用すること自体は可能です。異なるルーティング方式の間で経路情報をどのように受け渡すのか、意図しない経路へ通信が流れないかを設計する必要があります。
ネットワークは、自分たちのシステムだけで設計が完結するとは限りません。
外部ネットワークと接続すれば、相手側のIPアドレス体系やルーティング方式も設計条件になります。
外部ネットワークとの接続は一発勝負になることもある
外部システムとの接続で難しいのは、設計だけではありません。
サービス開始前には、最終的に相手側の本番ネットワークと実際に接続し、通信できることを確認する必要があります。
接続に合わせて、ルーティング、デフォルトゲートウェイ、ファイアウォールやアクセスリストなどへ設定を追加・変更します。
自分たちのシステムが通信できればよいわけではありません。
新しいネットワークを接続したことで、相手側の既存システムへ意図しない経路が生まれたり、既存の通信へ影響を与えたりしないことも確認する必要があります。
本番ネットワークの変更は、好きな時間に何度でも試せるものではありません。
相手側との調整で作業可能な日時が決められ、限られた時間の中で設定変更、疎通確認、問題があった場合の切り戻しまで行います。
決められた作業枠の中で「つなぐ→確認する→ダメなら戻す」まで完了させる段取りが大変
通信できない場合に備えて、パケットキャプチャなどを使い、接続元からパケットが出ているのか、どこまで到達しているのかをすぐに解析できる準備もしておきます。
私が経験した外部接続でも、この作業にはかなりのプレッシャーがありました。試験環境で準備できることは確認していても、最後は本物のネットワーク同士を接続しなければ分からないことがあります。作業時間も限定されるため、感覚としては一発勝負に近いものがあります。
接続できた後も、単にpingが通れば完了ではありません。
名前解決、ポート単位の疎通、アプリケーションが実際に使用する通信、ファイル転送などを確認し、何をもって正常とするのかを事前に決めておく必要があります。
ネットワークとして基本的な疎通を確認した後、各アプリケーションチームが実際の通信試験を行います。
例えば、ファイル転送製品を使用しているシステムであれば、実際にその製品を使って送受信できることまで確認します。
ネットワークの本番接続では、つながることだけでなく、既存ネットワークへ影響を与えず、予定した通信だけが成立することまで確認して初めて成功です。
必要な通信だけを許可する
ネットワークでは、通信できることと同じくらい、不要な通信を通さないことが重要です。
例えば、アプリケーションサーバーからデータベースへ接続する必要があっても、すべての通信を許可する必要はありません。
接続元、接続先、プロトコル、ポート番号、通信方向を整理し、必要な通信だけをファイアウォールなどで許可します。
ここでネットワーク担当だけでは設計できない問題が出てきます。
どのアプリケーションが、どのサーバーへ、何番ポートで接続するのかは、アプリケーション担当から情報をもらわなければ分かりません。
監視、バックアップ、ログ転送、保守作業についても、運用担当や基盤担当から通信要件を集めます。
数百の通信経路を一つずつ確認する
大規模システムになると、この通信要件の整理が非常に大きな仕事になります。
私が関わったプロジェクトでも、各グループから提出されたトラフィックパターン（通信要件一覧のこと、通称トラパタ）を集め、ネットワーク担当が設定へ落とし込む作業がありました。
通信経路は数百単位になります。
1つの通信についても、接続元サーバー、接続先サーバー、TCPかUDPか、ポート番号、通信方向、業務通信か保守通信かを確認します。
アプリケーションが使用するポートだけではありません。
監視、バックアップ、ログ転送、リモートメンテナンス、製品間通信など、システムを維持するための通信もあります。
必要な通信を1件漏らせば、その機能は動きません。不要な通信まで許可すれば、セキュリティ上の問題になります。
実際の設定作業はネットワークの専門チームへ依頼していました。私は各チームから上がってくる通信要件を取りまとめる側からその作業を見ていましたが、数百件の一覧を見ながら、接続元、接続先、ポート、IN／OUTを一つずつ確認していく様子を見て、**「これは自分ではとてもやれない」**と感じたことを覚えています。
ネットワークエンジニアには、TCP/IPや機器の知識だけでなく、大量の通信条件を漏れなく正確に設計へ反映する能力が求められます。
Excelで管理すると膨大なリストになる
個別に設定するだけではネットワーク全体はそろわない
大規模システムでは、複数のサブシステムやチームが並行して設計を進めます。
それぞれが個別の判断でIPアドレス、ポート、通信制御、命名規則を決めると、システム全体で設計がばらつきます。
そこで、ネットワーク全体で共通に使う設計方針や構築ルールを定め、各チームから上がってくる設計内容がその方針に合っているかを横断的に確認します。
セキュリティも、外部からの入口にファイアウォールを置くだけでは成立しません。
Web／AP、AP／DB、管理、バックアップ、外部接続など、それぞれの通信について、必要な経路だけを許可する設計が必要です。
どことどこを許可するのかしないのか複雑極まりない
ネットワークエンジニアには、自分が担当する機器を設定するだけでなく、システム全体の通信設計をそろえる役割もあります。
冗長化するとネットワークは一気に複雑になる
業務システムでは、1台のネットワーク機器や1本の回線が故障しただけで、システム全体を停止させるわけにはいきません。
ルーター、ファイアウォール、ロードバランサ、スイッチ、回線などを冗長化します。
ここでは、私が担当した比較的小規模なシステムを例に見てみましょう。サーバー台数は10台程度です。
セキュリティを考慮して、利用者からWeb／APサーバーへ接続するフロント側、Web／APとDB間の通信、バックアップ専用LANなどをVLANで分離していました。
フロント側のルーターは2台構成とし、HSRPで冗長化します。サーバーを収容するスイッチも複数の経路で接続し、DBやバックアップ系にも障害時の通信経路を持たせます。
サーバーは10台程度しかないのに、物理ネットワーク構成図は驚くほど複雑になりました。
どのサーバーのNICが、どのスイッチの何番ポートへ接続されているのか。そのポートはどのVLANなのか。通常時はどの経路を通り、機器が故障するとどちらへ切り替わるのか。
これらを物理構成と論理構成の両方で把握する必要があります。
私自身、Cisco機器を扱い、ネットワーク資格も取得していました。それでも、このレベルになると構成図を追うだけでかなりの集中力が必要で、最後までネットワーク専門エンジニアには独特の専門性があると感じていました。
サーバー10台程度でも、通信分離と冗長化の組み合わせでネットワーク構成はここまで複雑になる
障害が起きると最初にネットワークを疑われる
ネットワークエンジニアの特徴がよく出るのが、障害対応です。
利用者から「業務アプリケーションが使えない」という問い合わせが来ても、原因は分かりません。
アプリケーションが異常になっている可能性があります。ApacheやTomcatが停止している可能性もあります。JavaでFull GCが発生し、処理がほとんど進まなくなっているケースもあります。
データベースが停止している、DNSで正常に名前解決できない、ファイアウォールで通信が遮断されているといった原因も考えられます。
私の経験でも、障害が発生すると調査する前から、
「ネットワークが切れているのではないか」
「データリンク層で通信できていないのではないか」
と言われることがありました。
実際には、物理的な断線やルーティングが突然壊れるケースより、アプリケーションやミドルウェアなど別のレイヤーに原因があるケースの方が多くありました。
利用者から見える現象だけで原因を判断することはできません。
緊急障害では各チームが同時に切り分ける
時間に余裕があれば、通信経路を順番に確認していく方法もあります。
本番障害では、一つずつ調べ終わるのを待っている余裕がないことがあります。
基盤・ネットワーク、アプリケーション、DBAなどが一斉に調査を開始します。
ネットワーク担当は、リンクダウンの有無、インターフェースの状態、ルーティングテーブル、通信経路などを確認します。
Cisco機器であれば、show interfaces、show ip interface brief、show ip route、tracerouteなどを使い、どこまで通信できているかを確認します。
アプリケーション担当は、ApacheやTomcatが起動しているか、HTTPリクエストへ応答できるか、Full GCなどが発生していないかを確認します。
DBAは、データベースが起動しているか、接続できるか、エラーや異常な待機が発生していないかを調べます。
各チームが、
「ネットワークはここまで正常」
「Webサーバーまでは到達している」
「DB接続でエラーが発生している」
と結果を持ち寄り、原因箇所を短時間で絞り込みます。
ネットワークエンジニアには機器の操作方法だけでなく、OSI参照モデルやTCP/IPの仕組みを理解し、どのレイヤーで通信が止まっているのかを切り分ける力が求められます。
DNSやセキュリティ製品の更新でも通信は止まる
ネットワークの問題は、ケーブルが抜けるような分かりやすい原因だけではありません。
本番切り替えでDNSの接続先を変更する場合、TTLが切れるまで古いDNS情報がキャッシュへ残り、新旧の接続先が一時的に混在することがあります。
私が担当したプロジェクトでも、DNS変更前後にどの名前がどのIPアドレスへ解決されるかを、事前のチェックリストへ入れて確認していました。
試験中には、セキュリティ製品の定期アップデートを契機に通信制御が変わり、それまで使用できていた通信が遮断された経験もあります。
適用されるルールは事前に精査していても、外部製品の更新によって通信条件が変化することがあります。
ネットワーク機器の設定だけを見ていても、原因へたどり着けないケースがあります。
クラウドになってもネットワークの基本は変わらない
AWSでは、物理的なルーターやスイッチを自分たちで設置する機会は減ります。
ネットワーク設計がなくなるわけではありません。
オンプレミスでVLANを使ってネットワークを分離していた考え方は、AWSではVPCやSubnetなどを使った論理的な分離へ置き換わります。
ファイアウォールによる通信制御はSecurity Groupなどへ、物理ロードバランサの冗長構成はALBなどのマネージドサービスへ変わります。
外部ネットワークとの専用接続にはDirect Connectを利用できます。
高可用性を確保する場合は、複数のAvailability Zoneへシステムを配置します。
私が関わったAWS移行でも、オンプレミスとAWSをDirect Connectで接続し、本番環境を複数AZへ配置する構成を採用しました。
オンプレミスでは、どのスイッチへ接続するか、どの物理ポートを使うか、どのVLANへ所属させるかといった複雑さが目に見えます。
AWSでは物理機器が見えなくなり、VPC、Subnet、Route Table、Security Group、DNS、Direct Connect、Load Balancer、Availability Zoneなどの論理設定へ複雑さが移ります。
AWSの管理画面から簡単にネットワークを作れるように見えても、通信経路やセキュリティを理解していなければ、システム全体として正しい構成にはなりません。
技術が進化しても根底にある設計思想は普遍
ネットワークエンジニアは特殊な専門性を持つ
私はインフラ、ネットワーク、DBなど複数の技術領域を経験してきました。
その中でもネットワークは、少し独特な専門性を持つ領域だと感じています。
物理的には、サーバーのNICがどのスイッチのどのポートへ接続されているのかを把握します。論理的には、VLAN、IPアドレス、ルーティング、DNS、ファイアウォールを追います。障害時には、通信がどのレイヤーまで成立しているのかを切り分けます。
切り分けを速くするには、ネットワークだけでなく、OS、Webサーバー、アプリケーションサーバー、データベースなど、接続先の動きもある程度理解していた方が有利です。
大規模システムでは、各チームから上がってくる数百件の通信要件を精査し、必要な通信だけを漏れなく設定へ反映します。
クラウドへ移行すれば、物理機器の代わりにVPC、Subnet、Route Table、Security Group、Direct Connectなどを組み合わせます。
扱う技術は変わっても、通信全体を頭の中で組み立てる力は変わりません。
ネットワークを専門として長く担当するエンジニアには、他の技術領域とは少し違う思考の仕方があると感じます。
まとめ：通す、通さない、切り替える
ネットワークエンジニアの仕事は、ルーターやスイッチを設定することではありません。
必要な通信を通す。不要な通信は通さない。障害が発生したときは、別の経路へ切り替える。
そのために、IPアドレス、VLAN、ルーティング、DNS、ファイアウォール、ロードバランサ、回線、冗長化など、多くの技術を組み合わせます。
実際のプロジェクトでは、各チームから集めた数百件の通信要件を一つずつ確認し、接続元、接続先、ポート、通信方向を漏れなく設計へ反映するような地道な作業もあります。
外部ネットワークとの接続では、限られた時間の中で本番ネットワークへ安全に接続し、既存システムへ影響を与えず、必要な通信が成立することまで確認します。
障害が起きれば、ネットワークだけを見るのではなく、アプリケーションやDBAなどのチームと同時に調査し、どこで通信や処理が止まっているのかを切り分けます。
オンプレミスからAWSへ環境が変わっても、通信を分離し、必要な通信だけを許可し、障害に備えて冗長化するという設計思想は変わりません。
ネットワークエンジニアは、個々の機器ではなく、システム全体の通信を成立させるエンジニアです。
関連記事
システム開発では、ネットワークエンジニアだけで仕事が完結することはありません。
アプリケーション、データベース、システム基盤など、それぞれの担当が連携してシステム全体を作ります。
アプリケーションエンジニアの仕事
業務要件を仕様へ落とし込み、設計・実装・テスト・障害対応まで担当するアプリケーションエンジニアの仕事を解説しています。
データベースエンジニア（DBA）の仕事
データベースを安定して利用できるよう、設計、性能管理、バックアップ、障害対応などを担当するDBAの仕事を解説しています。
コメント