「前任者が辞めて、ネットワーク運用が辛すぎるんですが......」 アイティメディアの"ほぼ一人情シス"が聞いた、その解決策とは？

前編：ネットワークのスキルを持つ前任者が辞めた......専門家に「本気」の悩み相談

限られた人数で運用されてきたアイティメディアの社内インフラだが、ネットワーク運用スキルを持ったエンジニアが退職することに。
手間を掛けることなく安定したネットワークサービスを提供したい――そんなタスクを引き継いだメンバーへのアドバイスとは？

サーバの設定にストレージの管理、ネットワークの運用にエンドユーザー対応......社内システム運用にまつわるもろもろの作業を一手に引き受けている「一人情シス」は、世の中少なくないでしょう。何を隠そう、アイティメディアの IT システムもほぼそんな状態で、少ない人数で運用されてきました。

そんな折、なんと、高いネットワーク運用スキルを持つエンジニアが退職してしまい、残るメンバーがタスクを引き継ぐことになってしまったのです。幸い、今のところ大きなトラブルは発生していないとのことですが、この先もずっとそうであり続ける保証はありません。

「他の案件もあったからちょっと目をそらしていたところもあったけど、この下期で何とかしたいんだよな......」。アイティメディアの情報システム担当、淺野のこんな悩みをどこからか聞きつけた ITmedia エンタープライズ編集部。

「だったら専門家に聞きに行きましょう！　なーに、取材という体で話を聞けば大丈夫ですって」

そして半ば強引（？）に淺野を連れ、編集部が向かったのはヴイエムウェア。サーバ仮想化だけでなく、ネットワーク仮想化のプロフェッショナルでもある中本氏に率直に悩みをぶつけてみたのです。

引き継ぎ資料はもらったものの最悪の場合は「メッセージで連絡を」

地味ながら甚大な負荷のかかる ACL のメンテナンス作業

中本：今のアイティメディアの社内ネットワーク構成はどのようになっているのでしょうか？

淺野：公開 Web サーバは別として、物理的に 1 つのネットワークを社内サーバセグメントとユーザーセグメントとに分け、その間の通信は全社ネットワークのコアを担うレイヤー 3（L3）スイッチのアクセスコントロールリスト（ACL）で制御しています。

中本：おお......。それだとメンテナンスが大変じゃないですか？

淺野：ACL がだいたい 100 行以上ありまして......サーバを 1 つ追加するたびにそのメンテナンスが必要になります。「このサーバにアクセスする人は限られるか、限られないか。もし限られる場合は誰がアクセスしてもいいのか」といった事柄を確認し、それに沿って ACL に新しいルールを追加していますが、なにぶん「一人情シス」状態なので、本当にこの設定でいいのかを確認してもらえる人がいません。今は、別の技術部門の詳しい人に聞いた上で、念のため CTO の了承を取ってから反映するようにしています。

中本：ACL のメンテナンスの負荷って意外と大きいですが、それが全部 IT 管理者に集中してしまっていますよね。ACLは行きと帰りの両方を管理しなければいけませんし、記述するにもその IP アドレスが何を意味しているのか、どのサーバ、どのセグメントを指しているか把握しておかなければいけませんが、何十年もシステム管理に携わってきた、そのシステムの "主" のような人でもなければ、難しいことだと思います。

淺野：「この IP アドレスって何に割り当てていたっけ」というのが分からなくなった場合は、まず DNS サーバで引いてみて、それでも分からなければ、Excel で作成した「IP アドレス表」と見比べています。
けれど、その台帳自体に更新漏れがあったりするので、最悪の場合は直接ログインしてサーバ名を調べています。意外と多いんですよね、使われている IP アドレスが記録されていなかったり、今後のサーバ増設に備えて「ここは使わないでください」と予約してあるのに使われていたり......。

中本：ありがちな話ですね（笑）。これも、ネットワークセグメントを分けないことによって生じる弊害の 1 つだと考えています。皆が共有する場所で、個人の庭ではないのに、勝手に種をまいて「ここは掘らないで」と看板を立てるようなものですよね。ネットワークのセグメントを分けるというのは、システム単位で管理者の責任範囲を明確にするためにも必要なものだと思います。

ビジネス停止につながるネットワークトラブル、影響範囲の大きさがプレッシャーに

淺野：もう 1 つ、自分にとって最も心理的な負担が大きいのが、いざ設定変更をするときの覚悟です。全てのネットワーク設定がコアの L3 スイッチ 1 カ所に集約されているため、万一そこでミスが発生すると、ネットワーク全体、社内全体に影響が生じてしまいます。引き継ぎ資料を確認して大丈夫だと分かってはいても、いざメンテナンスするときには、やはり覚悟がいりますね。一度でもトラブルを経験した覚えのあるエンジニアなら、誰でもそうじゃないかと。

中本：「Office 365」が典型例でしょうが、ネットワークにつながらなくなると、コンピュータで動いているほぼ全てのアプリケーションが使えなくなりますからね。今やローカルで動作するアプリケーションはほとんどなく、Web ブラウザを立ち上げ、どこかのシステムにつなげて動いています。仮にコアの L3 スイッチでトラブルが起きると、そこを通る全てのアプリケーションがダメになってしまいます。

淺野：言ってしまえば、ACL の設定作業それ自体はそんなに複雑なものではなく、コマンドを 1 つ打てば済みます。けれど、その作業によって生じる影響の大きさを一度でも感じたことがあれば、慎重にならざるを得ません。それに、影響範囲が広くなればなるほど、メンテナンスを行うタイミングの調整も複雑になりますし、告知も必要です。「明日止まるからよろしく」というわけにはいきません。

中本：どの部署にも影響が生じない日時を探そうとすると、ゴールデンウィークや年末年始など、全社が一斉休業しているときしかありませんよね。それすら今や、働き方改革や 24 時間 365 日体制でのサービスを考えると、日程の確保が難しくなっています。

淺野：今後、社員からの要望に応え、外部からも社内システムにアクセスできるような環境を整えるなど、新しい取り組みも進めていきたいのですが、検討すべき事柄は少なくありません。

中本：本来、サーバネットワークというのは、もっと頻繁に変更すべきものだと思っています。クライアント側のネットワークは一律のポリシーで決め打ちできるでしょうが、サーバ側はユーザーからどんどん寄せられる、さまざまな要求にきっちり対応したり、新しいシステムを追加したりするたびに変更していくのがあるべき姿です。にもかかわらず、現行の多くのネットワークではそれができていません。ひとえに作業が大変だからです。

淺野：本当によく分かります。

中本：物理的にネットワークを分けてしまえば厳密に制御できますが、普通の企業にとってはコスト面で見合わないものになるでしょう。1 つの物理ネットワークを共用することになるでしょうが、分け方はいくつかあります。最もきちんと制御できるのは、セグメントを分け、その間をファイアウォールなどできちっと制御すること。その次が ACL による制御です。
それすら行わず、「社内に入っているものならば大丈夫だろう」という前提で全て素通しという企業もあります。きちんと制御しようとすればするほど作業量も増え、運用の負荷が増えるのは事実です。最初はきちんと設定していても、アプリケーションが追加されるたびに作業が発生して「もうやっていられない」と放置されるケースもありますね。ACL にしても「この行は何を意味しているのか？」を把握しきれません。一方、何もしなければ運用は楽でしょうが、IP アドレスの重複といったトラブルが起こり得ますし、ネットワークが不安定になる恐れがあります。

淺野：理想はやはり、自分が何もしなくてもいい状態を保てることですね。ステータスチェックなどを行って正しく動いていることが可視化されている一方で、いざ何か起きたときにはすっと入れて、確実かつ迅速に対応し、短時間で復旧できる......そんな状態が実現できるといいですね。

中本：今までは残念ながら、「きちんと作るが運用の手間が大変」と「ほぼ何もしない」の二者択一しかなく、その中で各社がバランスを取りながら、落としどころを見つけるしかありませんでした。でもそれは本当はおかしなこと。
守るべきところ、安定すべきところはしっかり作りつつ、手間を減らすという新たな選択肢があるべきだと思います。その 1 つの解決策がネットワークを仮想化し、細分化することだと考えています。淺野さんのような悩みを持っているなら「VMware NSX」を使うと、いろいろとうまくいくんじゃないでしょうか？

• 1
• 2
• 次へ