IoTネットワークのトラフィック管理①
はじめに
IoT(Internet of Things)の世界では、様々なモノがインターネットに接続され情報交換を通じて様々なモノが様々な方式で制御されることになりました。インターネットが利用されるという意味では、古くからあるウェブやメールと同様ですが、IoTの世界では流れるトラフィックの性格が様変わりし、従来の環境では考慮する必要のなかった様々な課題がたち現れています。それらの課題は一体どういったものでしょうか。
- 膨大な端末数
IoTで接続される端末は家電やドアの鍵、自動販売機や防犯カメラ、水道やガスのメーターなど文字通り様々なモノで、接続される端末は膨大な数に上ります。今後、すべての電子機器がインターネットに接続されるような事態になれば大変な数の端末がインターネットに接続されることになります。その場合、問題になるのはIPアドレスの割当てで、現在よく見られるのが同一のプライベートIPを複数端末で使い回すか、IPv6を割り当てるかのいずれかです。前者の場合、重複するIPアドレスをどう管理するかが課題になりますし、後者の場合はIPv6/IPv4変換（NAT64とDNS64）が課題になることが多いです。
- なが〜いセッション時間
ウェブやメールといった従来のアプリではセッションの継続時間はさほど長くなく、短い場合はほぼ瞬時に解消しますし、長い場合でも数分から数十分であることが大半です。ところがIoTの世界ではセッション確立後に次のトランザクションが発生するのは２４時間後だったり、長いものでは同一セッションであるにも関わらず１週間に１回しかトランザクションが発生しないようなケースもあります。もちろん、あくまで接続される端末同士が単に通信できればよいということであれば、これは何も問題ではないですが、IoTの世界でもファイアーウォールは必須ですし負荷分散を行いたいケースもたくさんあります。ファイアーウォールやロードバランサーのようなセッションステートを管理しなければならない機器はこの極端に長いセッションをきちんと管理出来る必要があります。
- IoT向けプロトコルの問題
ウェブやメールといった従来のアプリで利用されるプロトコルは所謂クライアント・サーバモデルのプロトコルで、一方は専らリクエストを送信するのみ、他方はレスポンスを返すのみといったものになっています。ブラウザを立ち上げたら突然どこかのサーバからリクエストがやってくるなどといったことは起きません。しかし、MQTTに代表されるIoT向けプロトコルは双方向にメッセージが飛び交うことを前提としているため、こうしたことが普通に発生します。従来のファイアーウォールやロードバランサーは基本的に一方向のクライアント・サーバモデルの通信を前提としているため、このようなプロトコルを扱うことができません。
それからIoT向けプロトコルでは1トランザクションが一つのL4セッションに対応するものではないことが大半です。MQTTなどは最初にL4セッションを作成すると、セッションを永続的に保持したまま、そのセッション内でメッセージをやり取りし続けます。この何が問題かというと、古典的なファイアーウォールやロードバランサーは処理の最小単位がL4セッションであるため、セッション成立後は何も関与することができないということです。L4セッション内のデータストリームをメッセージ単位で分割して処理できなければファイアーウォールやロードバランサーとしては動作できないことになります。
さらにL4セッションを保持し続けるタイプのプロトコルでは、やりとりするメッセージがなくとも起動時に予めセッションを作成すること義務付けるものや、アイドル時には定期的にWatchdogメッセージをやりとりすることを規定しているものがあります。ロードバランサーやファイアーウォールはメッセージを転送するだけでなく、こうしたセッションの確立やWatchdogメッセージを能動的に自ら作成して送信するといった自律したノードの1台として振る舞うことも要求されます。
このように、IoTの世界では基盤としてのインターネットは共通ではあるものの、そこで流れるトラフィックは従来とはかなり異なり、それに応じた新たな課題が発生しています。次回以降、これらの課題をBIG-IPがどう解決するか見ていきたいと思います。