この記事は、前回投稿したAWS Ground StationとAzure Orbital Ground Stationを比較してみた①の続き第二弾となります。もしよければ第一弾も読んでいただけると嬉しいです。
第二弾の本記事では、Azure Orbital Ground Stationを使って、実際に衛星データを取得して解析するところまで実施してみます。
機能要件の評価
AWS・Azureのそれぞれ宇宙サービスのGround Stationについて、機能要件として以下を評価してみます。（前回第一弾からの続きになっているので、Noも9からとなっています）
| No | 分類 | 評価項目 |
|---|---|---|
| 9 | 機能要件 | 衛星データ収集サービスが利用可能となるまでのリードタイムを比較する |
| 10 | 機能要件 | 利用者が指定するパブリッククラウドサービスに衛星データを連携可能か |
| 11 | 機能要件 | 衛星から受信したデータの復調方式はカスタマイズ可能か |
| 12 | 機能要件 | 衛星データの補正・圧縮処理の開発効率化が可能か |
上記の機能要件を検証するために、衛星データを提供するサービス提供者と衛星データを解析してビジネスに活用するサービス利用者を想定し、机上調査をした上でプロトタイプを構築しました。シナリオとしては、以下フロー図のように、サービス利用者が指定した衛星のデータを、サービス提供者が手続き・生データの処理を実施し、解析可能な状態でサービス利用者に提供する流れを想定しています。
AWS・Azureへの申請や実際にプロトタイプの構築を通して、主に以下2点を確認しました。
衛星データ収集サービス利用開始までの手続きを明らかにしたい
ヒアリング結果より、地上局の建設後から実際にアンテナを利用して衛星データを受信するまでには多くの申請や手続きが必要です。そこで、クラウド上の衛星データ収集サービスを利用する場合に必要となる手続きや申請を実際に実施して確認します。
性能要件を満たす環境下で機能要件を満たせるか確認したい
機密データを含む衛星データは、パブリック通信を利用しないことが前提となります。そこで、プライベートな環境で機能要件を実現できるかを確認します。
なお、実装にあたっては以下を参考にしています。
構築したプロトタイプ環境
構築したプロトタイプの構成図は以下の通りです。Azure Orbital Ground Stationが東日本リージョンに非対応（2024年2月時点）のため、利用リージョンは全て米国中北部リージョンとした。
各リソースの利用目的と設計ポイントについて、吹き出しで追記しています。
Azure Orbital Ground StationとVM間の通信はプライベートネットワークでの接続を実施しており、「操作ログの保管用」「衛星の生データ保管用」のStorage Accountを作成しています。また、RunbookのAutomationによってストレージへの出力を自動化しており、VM上で処理後のデータ保管はData Lake Storageで設計しました。
それでは、機能要件の評価をしていきます。
9.機能要件：開発可能となるまでのリードタイムの評価
検証観点
衛星データ収集サービス利用に関する手続きや申請の観点と、実際にサービスを利用して衛星データを利用者に提供するまでの時間をAWS・Azureで比較します。
検証内容
- AWS・Azureでそれぞれ衛星データ収集サービスを利用するにあたって必要となる申請を実施
- 承認後に衛星からデータ取得可能となるように、環境整備や各種設定を実施
検証結果
手続き・申請に関するAWS・Azureの比較結果を以下にまとめます。
| 観点 | AWS | Azure |
|---|---|---|
| 申請が必要となるタイミング | ・利用したい衛星の追加 ・利用したい地上局の追加 ・コンタクトスケジュールの設定や変更 |
・利用したい衛星の追加 ・KSAT社の地上局の追加 |
| 申請方法 | ・メール（英語） | ・AzureポータルよりSR起票（英語） |
| 申請内容 | ・アカウントID ・衛星名称 ・利用目的 |
・衛星名称 ・利用目的 |
| 承認までに要した時間（実測値） | 5営業日以降（検証時は7日） | 翌営業日以降（検証時も翌営業日） |
以上より、AWSの方が若干申請は煩雑で、かつ時間がかかることも分かりました。一方で、Azureに関しては、申請内容自体もシンプルで、かつ承認までの時間も短期間で済むことが分かりました。（今回試したタイミングが、たまたまこのような結果になっただけかもしれませんが）
コンタクトスケジュールとは
衛星とデータを送受信する際に、地上局側で衛星とのコンタクトを試みるスケジュールのことを指します。Azureでは、自身で設定したコンタクトプロファイル(対象の衛星やコンタクト時間、衛星の高度、帯域などを設定)や地上局、データ通信を実施したい時間帯に基づき、候補となるスケジュールが表示されます。
10.機能要件：衛星データ取得から解析環境までのデータ連携先の切替
検証観点
サービス提供者によって処理されたデータが、サービス利用者の環境で閲覧可能となるか確認します。
背景：Azure Orbital Ground Stationを使用する際のデータ連携について
衛星からAzure上にデータ連携する経路としては、衛星→Azure Orbital Ground Station→VMの経路のみとなります。その後、VM以降のデータ連携は、クラウドサービスを使用して柔軟に構築することが可能となる想定です。
検証内容
以下経路が実現可能となるようにAzure Orbitalや他リソース上の設定をしました。
① Azure Orbital Ground Stationから衛星データの処理を実施するVMへの連携
② VMからサービス提供者側のストレージサービスへのデータ格納
③ サービス提供者側のストレージからサービス利用者のストレージサービスへ連携
検証結果
①Azure Orbital Ground StationからVMへのデータ連携
コンタクトプロファイルというリソースを使用して、連携先のVMを指定することで、Azure Orbital Ground Stationをサポートしたリージョンであれば任意のVMを複数指定することが可能でした。
一方で、2024年2月時点でAzure Orbital Ground Stationは日本リージョンをサポートしていないため、国内に閉じたデータ連携は不可となっています。
②③VMからストレージへのデータ連携
Azure上のクラウド機能により、リージョンやリソースグルプ跨ぎのデータ連携が可能でした。
また、利用者希望に沿ったストレージサービスへ連携することも可能です。
11.機能要件：衛星データの復調構成の検証
検証観点
衛星から受信したデータの復調方式はカスタマイズ可能か
背景
衛星からの信号を変換して処理するにあたって、復調にモデムが必要となります。モデムの種類やパラメータを変更が求められるケースもあるため、検証します。
検証内容
独自のモデムで復調可能となるようにAzure OrbitalとVMを設定します。
検証結果
Azure Orbital上の設定で、復調前の生データをVMに連携することはできました。アプリ(GNU Radio)をデータ連携先のVM上にインストールし、モデムとして機能させられます。また、復調時のパラメータ等を自由に設定可能な環境を構成することも可能です。
参考までに、マネージドモデムと独自のモデムについて説明します。
Azure Orbital Ground StationからVMへデータ連携する際に設定するコンタクトプロファイルにて、チャネルごとにAzureが提供するマネージドモデム(Preset Named Modem Configuration) と、独自のモデム(Raw XML)が選択可能となっています。
マネージドモデム選択時
独自のモデム選択時
Azure Orbitalのマネージドモデムは、DIFIを利用してデジタル化されたRF信号を送受信するデジタイザーで構成されています。
12.機能要件：衛星データの補正・圧縮処理の検証
検証観点
衛星から受信したデータの補正や圧縮処理が実施可能であるか
背景
地上局で受信された生データは、データ補正や圧縮処理を実施する必要があるため、検証します。
検証内容
データ連携先のVM上に、補正・圧縮処理を実施するアプリを構成した。
検証結果
Azureの機能として、データの補正や圧縮処理をマネージドに実施してくれるサービスはありませんでした。しかし、補正・圧縮可能なアプリ(NASA Direct Readout Laboratoryツール)を使用して処理を実施することができました。ただ、アプリでの対応が必要となるため、衛星によっては衛星固有情報を取り込んだ特有の作り込みが必要となることも判明しました。
なお、今回はクラウドサービスによる衛星データの前処理の実現可否の検証が目的であるため、補正手法等が問われる高次処理については実施していません。
まとめ
第一弾で紹介した性能要件なども含め、今回評価した項目のまとめを以下に記載します。
| No | 分類 | 評価項目 | 評価結果 |
|---|---|---|---|
| 1 | セキュリティ要件 | プライベートネットワーク環境下でデータ連携が可能か | ・AWS・Azureともにインターネットに出ることなくデータ連携することは可能 |
| 2 | セキュリティ要件 | 通信データの暗号化が可能か | ・AWS・Azureともに暗号化することは可能 ・AWSは配信先がEC2・S3ともに、暗号化用のカスタマーマネージド AWS KMS キーを使用した暗号化によるデータ配信が可能 ・Azureは、Azure ネットワーク標準規定によって、地上局からクラウド上への暗号化はサポート |
| 3 | 性能要件 | プライベートネットワーク環境下で衛星データが連携されるまでのリードタイムを比較する | ・Azureはデータ処理するVMに直接データ連携することが可能だが、AWSはS3を介するため、Azure方が短い時間で衛星データを利用者に連携できる |
| 4 | コスト要件 | 衛星データ収集サービスの利用料を比較する | ・専用の地上局の準備が不要なため、パブリッククラウドの衛星データ収集サービスを採用することで大幅なコスト削減の実現は可能 |
| 5 | 耐障害性要件 | 地上局・データ配信先を冗長化することが可能か | ・AWS・Azureともに1つの衛星利用時に複数地上局の選択可能 ・1つの地上局に対するリージョンレベルの冗長性は、Azureの方が取りやすい |
| 6 | 耐障害性要件 | マルチクラウド構成を取ることが可能か | ・AWS Ground StationとAzure Orbitalを利用できる衛星であれば、マルチクラウド構成を取ることが可能 |
| 7 | 法規制・監査要件 | 日本国内のデータ保管に絞ることが可能か | ・AWS・Azureともに衛星データ収集サービスをサポートしているリージョンに依存するため、2024年2月時点では国内に限定することは不可 |
| 8 | 法規制・監査要件 | クラウドベンダーによる衛星データの利用があるか | ・サポートより、AWS・Azureともに衛星データを取得される可能性はないと回答あり |
| 9 | 機能要件 | 衛星データ収集サービスが利用可能となるまでのリードタイムを比較する | ・承認までに要した時間および申請頻度の少なさから、Azureの方がリードタイム短く利用開始可能 ・AWSに関してはコンタクトスケジュール設定時に初めは申請が必要となるため、運用時の管理者の負荷は高くなると考えられる |
| 10 | 機能要件 | 利用者が指定するパブリッククラウドサービスに衛星データを連携可能か | ・地上局や衛星データ収集サービスを利用している環境とは異なるリージョン・リソースグルプ跨ぎで、任意のストレージサービスに連携することは可能 |
| 11 | 機能要件 | 衛星から受信したデータの復調方式はカスタマイズ可能か | ・復調時のパラメータ等を自由に設定可能な環境構築は可能 ・Azure Orbital上の設定で、マネージド・カスタムモデムを選択できる ・アプリ(GNU Radio)をデータ連携先のVM上にインストールし、モデムとして機能させることができた。 |
| 12 | 機能要件 | 衛星データの補正・圧縮処理の開発効率化が可能か | ・VM上に補正・圧縮可能なアプリを構成することで実現可能 ・Azureの機能として、データの補正や圧縮処理をマネージドに実施してくれるサービスはない ・また、衛星別の情報を取り込んだアプリの作り込みは必要 |
今回、AWS・Azureのそれぞれ宇宙サービスであるGround Stationのサービスや、サービス利用時の構成等も踏まえた検証を実施したが、申請フローやプライベートネットワーク環境化での構成に多少違いはあるものの、AWS・Azure間で衛星データ収集サービス内容や機能として大きな差異はないことが判明しました。
ただ、やはりオンプレと比較すると多くのメリットがあることでしょう。自前で地上局を準備する期間に比べ、開発準備のリードタイムの短縮と費用削減効果が見込まれるうえ、複数地上局を利用できることやマルチリージョン構成が可能なため、冗長性という観点でも優位性を示せたのではないでしょうか。
普段の業務とは離れて、気になっているサービスをとことん調べてみるのも面白いですね。