サイト間VPNを用いてクラウド上のintdashサービスをエッジサーバに展開してみた

f:id:aptpod_tech-writer:20201216183025j:plain

Advent Calendar 2020 17 日目を担当します、 SREチームの川又です。

SRE チームでは自社開発プロダクトである intdash のサーバサイドインフラにおいて、主に以下の職務を行なっています。

設計・構築・運用
可用性・パフォーマンスの向上のための改善
セキュリティの維持

今回は、エッジロケーションにおけるセキュリティを維持したパフォーマンス向上のために、サイト間VPN 接続を用いて弊社intdashのトラフィックフローを効率化した話をご紹介します。

はじめに
課題
解決策
- エッジ側vRouter の構成
結果
おわりに

はじめに

弊社では年に1 回程度、サーキットを1日貸し切って、自社プロダクトを用いた車両走行・データ計測を行うイベントを行います。本イベントは以下を目的としています。

自社プロダクトに触れる (ドッグフーディング)
デモ用データ取得
自社新規プロダクトの検証

通算何回か行なっている本イベントですが、現地サーキットの通信環境の悪さを原因とする課題を抱えていました。この記事では、ネットワーク技術でその課題の解決を試みた話をご紹介します。

※ この実験を行ったのは昨年度です。今年度は、主に感染症対策のため本イベントは実施しておりません。

課題

例年先述のイベントを行なっているサーキットはモバイル網の通信速度が遅く、さらには、サーキット内にモバイル網がエリア外の敷地もありました。したがって、インターネット通信を行える帯域が小さく満足にクラウド側とデータ通信ができない課題がありました。

弊社の intdash Server は多様なデータパイプラインを備えており、車両等の計測対象からアップストリームされるデータをリアルタイムに取得することも可能です。また、同じく弊社のWebベースダッシュボードアプリケーション Visual M2M Data Visualizer を用いることでデータの多彩な可視化が行えます。

イベント当日は、サーキットに居る弊社社員のほぼ全員がVisual M2M Data Visualizerで車両計測データの確認を行うことが予測されました。ですが、先述の通りデータ通信帯域が限られているため何らかの対策を行う必要がありました。

本ネットワーク環境の概要図を以下に示します。

f:id:aptpod_tech-writer:20201215155148p:plain — ネットワーク環境概要図

何らかの対策を実施しなければ、下の図の様にクライアントにあたる各人のVisual M2M Data Visualizerがそれぞれインターネットを通してクラウド上のintdash Serverと通信を行い、帯域を逼迫させてしまいます。

f:id:aptpod_tech-writer:20201215160302p:plain — 問題点のイメージ図

解決策

この課題を解決するために、エッジロケーションにあたるサーキット側にもintdash Serverを設置し（以下、これをエッジサーバと呼びます）、インターネット上ではサーバ間のみで通信を行う様に環境を構築しました。この場合、クライアントはエッジサーバのみと通信を行うため、インターネット側の通信量は削減されます。

問題解決構成のイメージを以下の図に示します。

f:id:aptpod_tech-writer:20201216121848p:plain — 解決構成のイメージ図

弊社intdash ServerはリアルタイムストリームのPub/Sub メッセージングに NATS が利用可能です。このNATSを用いてクラウド側のintdash Serverとエッジ側のintdash Serverで連携を行い、クライアントへのリアルタイムストリームを提供可能にしました。概念としては、CDN( Content Delivery Network) におけるキャッシュサーバに近いです。

サーバ間の通信に関しては、以下の理由からサイト間VPN接続としました。

セキュアに通信を行う
サーバ側に追加設定を必要としない

サイト間VPN接続には以下を用いました。

クラウド側: AWS 仮想プライベートゲートウェイ (VGW)
エッジ側: vRouter VyOS

概要図を以下に示します。

f:id:aptpod_tech-writer:20201216121919p:plain — 解決構成概要図

エッジ側vRouter の構成

エッジ側のvRouter ではクライアントがサーバの接続先を意識しないで良い様に以下の機能を提供させました。

DHCP サーバ ( Dynamic Host Configuration Protocol )
DNS サーバ ( Domain Name System )
NAT ( Network Address Translation )
ルーティング(静的)
VPN ゲートウェイ

エッジ側ネットワークの機能およびリソースをvRouter の管理下に置くことで、クライアント側が接続先サーバのドメイン名を意識せずアクセス可能な構成としました。

結果

結果としては、理論通りの挙動をさせることには成功しました。ただし、他の検証施策もあった兼ね合いで、全てのクライアント側で同時にエッジサーバを利用して貰うことが叶わず、効果測定としては満足に行うことが出来ませんでした。次回、同じ構成を試す機会があれば、インターネット通信量の削減効果を測定してみたいと思います。