サービスベースへと進化するネットワーク（前編）

インフラをサービスとして提供する時に重要となるのがサービスディスカバリ、ネットワーク保護、ネットワークタスク自動化、アクセス制御です。ネットワークをサービスIDベースに移行するとワークフローなどが変化します。問題はセキュリティです。

クラウドは私たちのネットワーキングに対する考え方を根本的に変えました。今やネットワークは組織が定義した境界の外でも運用しており、複数のデータセンターまたはクラウドにもまたがっています。しかし、すべてがオンプレミスのデータセンターに置かれていた時代と比べて、ネットワークは本当に変わったのでしょうか。

結局のところ、一貫して接続を確立すること、セキュリティポリシーを適用することがすべてです。その点では変わりません。ではクラウドでは、なぜこれほど異なり、複雑に見えてしまうのでしょうか。

最新のネットワークへの進化をより深く理解するには、一歩下がって、これらの変更を定義するコアワークフローを特定することが重要になります。

• サービスの発見
• ネットワークの保護
• ネットワークタスクの自動化
• アクセスの制御

本稿では、これらの各ワークフローについて説明し、それらを組み合わせることで最新のサービスベースのネットワークソリューションを実現する方法について説明します。

ネットワーク変更を定義する4つのコアワークフロー

アプリケーションまたはサービスIDは、実は新しい概念ではありません。組織のネットワーク運用に携わるのであれば、特定のネットワーク上で実行されているアプリやサービスがどこにあり、到達可能かどうかを常に把握しようとします。ここも昔から変わりません。新しいのは、ネットワーク環境に加えられる変更の頻度が劇的に増加しているということです。

近年、継続的デリバリーとマイクロサービスが浸透するにつれ、手動追跡という形のボトルネックが課題となっています。スプレッドシートや構成管理データベース (CMDB)ツールからIPアドレスを追跡しようとしても、クラウド環境にまで拡張することはできません。それでは、ネットワーク運用者はどうすればいいのでしょうか。

まずは、サービスディスカバリの概念から考えていきましょう。サービスディスカバリとはネットワーク上でどのようなサービスが実行されているか、どこにあるか、リアルタイムで到達可能かどうかを確認する一連のプロセスです。

こうしたサービスディスカバリを自動化する必要性が高まることで、ZookeeperやConsulといったサービス検出ツールが登場するようになりました。

例えば、2014年にConsulが初めてリリースされたときには、コア機能は動的なサービスレジストリで、基本的にはアプリケーションを追跡するためのカタログという位置づけでした。この種のサービスレジストリでは、ユーザーは自動化スクリプトをアプリケーションの展開と一緒にパッケージ化し、カタログにアプリケーションを自動的に登録することで、アプリケーション情報がある単一の信頼できるソースを作成することができます。

後にアプリケーション配信が進化するにつれ、Kubernetes、Mesos、Docker Swarmなどのオーケストレータが検出機能を統合し、手動スクリプトの必要性を減らしました。これはこれで素晴らしいことですが、それ以外にもネットワーキングの進化に多くのものをもたらしました。

オーケストレータがサービスを追跡できるようにするには、依然としてサービスIDに基づく必要があります。またアプリケーションIDはネットワークポリシーの基礎となります。

サービスIDベースに移行した時のセキュリティへの影響

ネットワーク要件をサービスIDベースに移行すると、他のワークフローにも連鎖的に影響を及ぼします。特に重要になるのがセキュリティです。サービスディスカバリは環境に変更があろうとも動的にサービスを追跡できるようになりますが、アプリケーションに一貫したセキュリティポリシーを適用することには役立ちません。

セキュリティと機密データへのアクセスを強化することは、今も昔も変わらずネットワークにおける重要な要件にあたります。ファイアウォールやロードバランサーが導入される理由を考えてみればわかります。適切なサービスのみがネットワークにアクセスできるようにするためです。ただし、ネットワーク上で実行されているサービスをIPアドレスで追跡するなら、うまくいきます。しかし、代わりにサービスIDを使う場合ならどうでしょうか。

シンプルに「それならIPアドレスではなく、サービスIDに基づいてセキュリティポリシーを作成すればいいのでは」と考えるかもしれません。アプリケーションIDが分かるなら、そのIDをもとに仕組みを作れるのではないかと。

しかし残念ながら、従来のネットワークセキュリティポリシーでは、そうしたパターンを想定していません。このアプローチでは開発チームはチケットベースのシステムに頼らざるをえなくなり、運用者と開発者の間にボトルネックとフラストレーションを生じさせてしまいます。

幸いなことに、この課題に対処する方法は2つあります。運用者の手動タスクをなくすことと、セキュリティポリシーをレイヤー3からレイヤー7へと移行することです。

次回はセキュリティポリシーをレイヤー3からレイヤー7へと移行することについて詳しく解説します。