Cisco SpacesとAWS連携してみた。-連携先サービス(AWS)の比較-

Cisco Spacesとは？

Ciscoが提供するクラウドプラットフォームの1つです。WLCやDNA Center経由でNW製品へのクライアントの接続状況を取得することができ、施設マップをインポートすることで取得した接続情報から位置情報を可視化することができます。また、NW製品だけでなくMerakiのセンサー製品等のIoTデバイスと連携することで各フロアの室温や滞在人数を表示することも可能です。

Cisco Spacesについて詳しく知りたい方は、Ciscoの紹介ページも併せてご覧ください。

Cisco Spaces（旧 Cisco DNA Spaces）- スマート ビルディング プラットフォーム - Cisco

このCisco Spacesで収集された情報を外部サービスと連携させることで、「社員が働きやすい環境を提供するサービスの開発ができないか」という発想をもとに、以下のポイントに注目しながら外部サービスとの連携の検証を行いました。

• リアルタイム性を損なわずデータを送信できるか

• 取得したデータを外部サービスの条件に合わせて送信できるか

検証を行う中でAmazon Kinesis Data StreamsとAmazon Data Firehoseを比較し、それぞれのサービスの利点や欠点について整理した内容をご紹介します。

外部サービスとの連携方法

Cisco Spacesで取得した情報をリアルタイムで外部サービスと連携させる際にはFirehose APIを利用します。

ただし、Firehose APIを使う場合はCisco Spacesだけでなく、Cisco Spaces Partner Dashboard(以下、Partner Dashboard)の利用権限が必要になります。これはCiscoのPartner Ecosystemを通じて申請をすることができます。

申請が完了してPartner Dashboardにログインできるようになったら、アプリケーションを作成し有効化することでFirehose APIを利用することができるようになります。

アプリケーションの作成方法はサンプルの設定ドキュメントが公開されているため、必要に応じてご確認ください。

Firehose APIの種類

Firehose APIにはPull Streaming ChannelsとPush Cloud Services Channelsの2種類のAPIが存在します。ユースケースや環境に応じて、どちらのAPIを利用するか検討する必要があります。

それぞれの形式のデータの特徴について説明します。

Pull Streaming Channels

クライアント側からCisco Spacesに接続すると、Cisco Spacesがデータを送信する形式です。

前述したPartner Dashboardでアプリケーションを作成し、有効化することで利用することができます。

認証には作成したアプリケーションのIntegration Detailsに記載されているAPI Keyを使います。

図1:Cisco Spaces Partner Dashboard API Key表示画面

今回は、検証用のクライアント（Linux）からcURLでリクエストを送って確認しました。

構成図では接続クライアントと同じNW内にあるクライアントから接続要求を送っていますが、Cisco Spacesに接続できる環境であれば、どのNWから送ってもデータを受け取ることができます。

図2:Pull Streaming Channels検証構成図

図3のようにCisco Spacesとの通信ができている状態で、何もイベントがない場合は15秒ごとにKEEP_ALIVEが送信されます。

Push Cloud Services Channels

Cisco Spaces側からクライアントに対してデータを送信する形式です。

Partner Dashboardでアプリケーションを作成する際にクライアントの認証情報を入力し、有効化することで利用ができます。

こちらはPull Streaming Channelsと異なり、利用できるクライアントが制限されており、2024年3月時点で以下のクライアントと連携することができます。

• Amazon Kinesis Data Streams
• Amazon Data Firehose
• Azure EventHub
• Google Pub/Sub

利用する際にはアプリケーションの設定画面にて、利用するクライアントのサービス名にチェックを入れ、必要な認証情報を入力します。

例としてAmazon Kinesis Data Streamsを利用する場合は以下の情報が必要です。

• 利用しているリージョン
• ストリームの名前
• アクセスキー
• シークレットキー

図5:Push Cloud Services Channels検証構成図

アプリケーションの有効化を行った直後からクライアントにデータが流れ始めます。

Amazon Kinesis Data StreamsとAmazon Data Firehoseの違い

Cisco SpacesとAWSの連携手段にはAmazon Kinesis Data StreamsとAmazon Data Firehoseの2種類のサービスがあります。

ストリーミングデータを受信・処理できるという点が共通しているサービスですがそれぞれ得意な処理に違いがあります。

今回の検証のきっかけは冒頭で説明した通り、リアルタイムなデータを送信できるか、別のエンドポイントへ加工したデータが送信できるか、がポイントとなっていました。

この2点に注目しながら両サービスを比較してみます。

リアルタイム性

Amazon Kinesis Data Streamsは大量のデータを高速に処理できるサービスです。入力されたデータは即時取り出すことができるようになるため、高速に処理を行うことができます(AWSのドキュメントには1秒未満の記載)。

一方で、Amazon Data Firehoseはデータを、特定のサイズ、または期間でバッファした後に、連携先に送信するサービスです。そのため、Amazon Data Firehoseはバッチ処理に適したサービスと言えます。

しかしながら、ゼロバッファリングを利用することで、リアルタイム処理を行うことも可能です。バッファの間隔は利用者側で設定することが可能なため、この間隔を0秒に指定することでゼロバッファリング機能を利用することができます。ただし、ドキュメントには「追加の処理を行わないほとんどのストリームは 5 秒以内に配信」との記載があり、厳密にリアルタイム性を求めるのであればAmazon Kinesis Data Streamsが適していると言えます。

図7:Amazon Data Firehoseバッファ設定画面

取得したデータを外部サービスの条件に合わせて送信できるか

Amazon Kinesis Data Streams、Amazon Data Firehoseでは、AWS内のサービスと連携することで、取得したデータを加工して、送信することができます。

Amazon Kinesis Data Streamsの場合は、Event BridgeのPipeが連携サービスとして用意されています。Pipeを構築することでデータをエンドポイントに送る前にフィルタリングしたり、加工したりすることができます。

Pipeのターゲット入力トランスフォーマーを設定することで、余計なデータの削除や、データの形式を設定することができます。これによって外部サービスの条件に合わせてデータを送信することができます。

図8:Amazon Kinesis Data Streams ターゲット入力トランスフォーマー設定画面

サービス間の連携のイメージとしては図9になります。EventBridgeと連携することでシンプルな構成で外部サービスの条件に合わせてデータを送信することができます。

Amazon Data Firehoseの場合は、Lambdaと連携することでデータの加工を行うことができます。前述の通り、Amazon Data Firehoseは特定のデータサイズ、期間のデータをためた後、データを送信するため、データの加工の際には最終的にAmazon Data Firehoseが定める形式にする必要があります。

外部サービス側でデータの受信後、データの分割や、不必要なデータの削除作業が発生します。

そのため、上記の作業を避けたい場合や、外部サービスで受信できるデータの形式に制約がある場合は、データ加工時に直接データを送信するか、データを任意の保存先に保存した後、Lambdaを使ってデータの加工及び送信を行う等、Amazon Data Firehoseの制約に左右されない構成を考える必要があります。

サービス間の連携のイメージとしては図10の通りです。

2つのサービスの違い

ここまでの記載を改めてまとめると図11になります。

図11:両サービスの比較

まとめ

今回は、Cisco SpacesとAWSの連携サービスとして Amazon Kinesis Data Streams と Amazon Data Firehose の2つのサービスの比較を行いました。

検証比較のポイントであるリアルタイム性、外部サービスに合わせたデータ加工に関しては、どちらのサービスでも構築次第で要件を満たせることが分かりました。
今後は、これらのサービス連携の性質を理解した上で、「社員が働きやすい環境を提供するサービス」の実現に向けてプロトタイプ開発に取り組んでいきたいと思います。
最後までご覧いただきありがとうございました。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。