 本記事は TechHarmony Advent Calendar 12/17付の記事です。 |
はじめに
私は主にインフラ・運用領域でのソフトウェアエンジニアであり、最近は通信や仮想ネットワーク周りを主戦場としています。
先日、弊社の Cato クラウド担当が次のブログ記事を書いていました。
この記事にインスパイアされ、私も Cato クラウドに関して思うところを書いてみたいと思います。特に、Cato クラウドのようなサービスを真似して開発・提供することを想像し、そのような視点で書いてみます。
Cato クラウドのすごいところ
Socket の存在
Cato クラウドでは Socket がアプライアンス機器として提供される点が最も良いところだと思っています。
Cato クラウドの立場になって SASE を提供することを考えると、利用者にルータを用意してもらって IPsec か何かでインターネット VPN を張ってもらうのが最も楽ですし、拠点側に何か置くとしても機器ではなく仮想マシンイメージのような形でアプライアンスを提供するのがソフトウェア屋としては楽です。どちらにせよ利用者任せにしてしまいがちなところですが、専用機器というソフトウェア以外の部分も提供して利用者の手間を減らしている点は簡単には真似できないなぁと感じています。
また、Socket の管理画面でインターネット接続の設定は設置拠点ごとに必要となるものの、VPN 接続やそれ以降の設定は集中的な管理画面 (CMA) で行えるという点も良いです。特に、VPN 接続を張る際のクレデンシャル (パスワードやクライアント証明書など) を利用者に入力させることなく、いったん Cato クラウドのサンドボックス的な場所に接続させることで集中管理できるようにするという発想は良いアイデアで、機会があれば真似したい部分です。
イベントのダッシュボード機能が良い
Cato クラウドの管理画面 (CMA) で各種イベントログを1つのダッシュボードで自由に検索して見られる点も良いですね。
イベントの発生源としては、Cato クラウド内部の各種機能だけでなく、Socket や Cato Client など様々なものがあります。これら様々なイベントを構造化データとして1つのドキュメントDBに放り込み、さらに検索もしやすくするというのは実装上けっこう面倒で手間がかかる部分なのに、それが上手く作られているなぁと感心しています。
また、イベント量は10億レコード以上あってかなり多いにもかかわらず、検索機能は意外と早く結果を返してきますので、インデックスや検索の実行計画が上手くチューニングされている印象です。時間フィールドだけでなく検索キーとして頻繁に利用されるフィールドもインデックスが張られているのでしょうけど、これは地道な改善の積み重ねが必要な部分です。
Web UI も全体的に良い
イベントのダッシュボードに限らず、管理画面 (CMA) の Web UI も全体的に良く作られている印象があります。
Cato クラウドは機能が多いため必然的に1つの画面の情報量も多いですが、そのぶんシンプルかつ機能性重視の画面となっており、エンタープライズ的にも利用しやすいように感じています。また、ブラウザの開発者ツールで眺めてみると、フロントエンドは React、バックエンドは GraphQL で作られているようです。こういったレイヤのアプリケーション開発は私は敬遠しがちですので、しっかりと作られているものを見ると敬意を払いたくなります。
ただ、Web UI では非同期リクエストが多用されているために、ページを開いてから遅れて描画されるという部分は正直好きではないです…。モニタリング画面はまだ良いのですが、ネットワークやセキュリティの設定画面は素早く描画されるほうが嬉しいですね。
Socket で DPDK が利用されている
Socket の Web UI を見ていると、その内部では DPDK が利用されている形跡が見つかります。
DPDK とは “Data Plane Development Kit” の略で、ネットワークのパケット処理を高速に行うためのライブラリやドライバのセットです。もともとは Intel が開発したものですが、現在は Linux Foundation の配下で開発されています。
Socket の内部では当然何らかのソフトウェアが動作しており、ネットワークに関する機能が実現されています。Linux Kernel には標準でネットワーク機能 (デバイスの操作、イーサネット、IP、UDP 通信など) が用意されていますので、UDP 以下のレイヤの通信やルーティングなどは Kernel の機能を活用して実現しつつ、UDP より上の DTLS 通信やその他機能は独自のソフトウェアで実装するというのがシンプルな発想です。
しかし、DPDK を利用しているということは、Kernel のネットワーク機能を使わずに DPDK で実現しているということであり、実装の難易度も高いです。DPDK を利用する場合、通常はC言語で開発する必要がありますので苦痛も多いです。Kernel を利用するよりもパケット処理を高速化できるかもしれないというメリットがあるとはいえ、技術的に高度で複雑なことを行っていることが覗えます。
Cato クラウドのいまいちなところ
API が GraphQL なので扱いづらい
Cato クラウドの API は全て GraphQL 形式で提供されています。
GraphQL は比較的新しい仕組みであり、RESTful あるいは REST API と比べて馴染みが薄いです。また、Cato クラウドの API に対するクライアントライブラリが用意されているわけでもないため、API を利用するには GraphQL 自体を理解する必要があり、学習コストがけっこう高い印象です。データ参照系の API だと GraphQL のメリットもあると思いますが、データ更新系 (設定変更など) の API だとメリットが多くなくて扱いづらいだけなのではと思っています。
今後 API が拡充されていくときに、利用しやすい API になっていることを期待したいです。
全ての通信が暗号化される
Socket や Cato Client と PoP との間の通信は全て DTLS や TLS によって暗号化されています。また、独自にルータを用意して IPsec で PoP に接続する場合も暗号化されます。
拠点間通信のための閉域網やインターネット VPN の代替として Cato クラウドを活用する場合は、拠点と PoP の間の通信は全て暗号化されてインターネットを通ることを期待します。しかし、PoP 経由で行うインターネットとの通信については、拠点と PoP 間で暗号化されている必要は特にないように思います。Web サイトへのアクセスは HTTPS を使うことが一般的ですので、HTTPS で暗号化された通信をさらに暗号化する必要はないですよね。暗号化することは、スループット低下やレイテンシ増加に繋がりますので。
シンプルに考えるなら、PoP 経由のインターネット通信では暗号化せず、WAN 通信では暗号化するというのが良さそうなのですが、どうなのでしょうか。もちろん、暗号化する目的は単に機密性だけではなく、通信相手の認証、改ざん防止、リプレイ攻撃の防止などもありますので、全く暗号化しないというのも問題があるかもしれませんが。
ブロックされる通信もいったん PoP に送られる
SASE (Secure Access Service Edge) における Edge とは、Cato クラウドでは PoP のことを指しています。Cato クラウドには Firewall, SWG, IPS, NGAM, ZTNA など様々な機能があり、これら機能は PoP で実現されています。
SASE 登場前のアーキテクチャ (※多数の拠点やリモートユーザがデータセンターに閉域網や VPN 接続を行い、そのデータセンター経由でインターネットや WAN 通信を行う構成) と比較して、Cato クラウドの SASE は効率的な通信や処理の負荷分散という観点で理にかなっています。一方で、従来であれば各拠点のファイアウォールで制御していた通信についても、Cato クラウドだと PoP で行うようになっているのではないでしょうか。
通信の中身を見ずに行えるファイアウォール機能は、ユーザにより近い Socket や Cato Client でも行うようになれば良いなぁと思っています。そうすれば、ブロックされる通信は PoP に送られなくなり、不要なトラフィックや通信コストを削減できますので。通信の中身を見るセキュリティ機能は負荷の高い処理ですし、PoP で行うというのは自然だとも思います。
将来的に SASE という概念がより高度化され、ユーザの手元にも Edge があるという時代が来るのだろうなぁと想像しています。
結びとして
Cato クラウドは便利ですし機能も豊富なので、価格が見合うなら良いサービスだと思います。中の実装はブラックボックス的に外から観察して推測することしかできませんが、見える範囲ではしっかりと作られている印象ですし、技術的に高度なことも行われていますので、今後も永く続くサービスであって欲しいと願っています。
この記事を書き連ねる中で、こういうネットワークサービスを作る立場になるのも良いかもしれないと改めて感じました。