AWS Ground StationとAzure Orbital Ground Stationを比較してみた②

この記事は、前回投稿した[AWS Ground StationとAzure Orbital Ground Stationを比較してみた①](https://qiita.com/hirarin-142131/items/9d9dcbbc240cd3d0b98f)の続き第二弾となります。もしよければ第一弾も読んでいただけると嬉しいです。

第二弾の本記事では、Azure Orbital Ground Stationを使って、実際に衛星データを取得して解析するところまで実施してみます。

# 機能要件の評価
AWS・Azureのそれぞれ宇宙サービスのGround Stationについて、機能要件として以下を評価してみます。（前回第一弾からの続きになっているので、Noも9からとなっています）

| No | 分類 | 評価項目 |
| :---: | :---: | :--- |
|9|	機能要件	|衛星データ収集サービスが利用可能となるまでのリードタイムを比較する|
|10|	機能要件	|	利用者が指定するパブリッククラウドサービスに衛星データを連携可能か|
|11	|機能要件	|	衛星から受信したデータの復調方式はカスタマイズ可能か|
|12	|機能要件	|	衛星データの補正・圧縮処理の開発効率化が可能か|

上記の機能要件を検証するために、衛星データを提供する**サービス提供者**と衛星データを解析してビジネスに活用する**サービス利用者**を想定し、机上調査をした上でプロトタイプを構築しました。シナリオとしては、以下フロー図のように、サービス利用者が指定した衛星のデータを、サービス提供者が手続き・生データの処理を実施し、解析可能な状態でサービス利用者に提供する流れを想定しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3281098/24a11483-4181-77f9-db72-62490274eb95.png)

AWS・Azureへの申請や実際にプロトタイプの構築を通して、主に以下2点を確認しました。
###### 衛星データ収集サービス利用開始までの手続きを明らかにしたい
ヒアリング結果より、地上局の建設後から実際にアンテナを利用して衛星データを受信するまでには多くの申請や手続きが必要です。そこで、クラウド上の**衛星データ収集サービスを利用する場合に必要となる手続きや申請**を実際に実施して確認します。
    
###### 性能要件を満たす環境下で機能要件を満たせるか確認したい
機密データを含む衛星データは、パブリック通信を利用しないことが前提となります。そこで、**プライベートな環境で機能要件を実現できるか**を確認します。

なお、実装にあたっては以下を参考にしています。

https://learn.microsoft.com/ja-jp/azure/orbital/geospatial-reference-architecture

https://learn.microsoft.com/ja-jp/azure/orbital/sar-reference-architecture

https://learn.microsoft.com/ja-jp/azure/orbital/satellite-imagery-with-orbital-ground-station?tabs=portal2

## 構築したプロトタイプ環境
構築したプロトタイプの構成図は以下の通りです。**Azure Orbital Ground Stationが東日本リージョンに非対応**（2024年2月時点）のため、利用リージョンは全て米国中北部リージョンとした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3281098/19eb72ec-fc38-c029-578d-1a27a70ba770.png)

各リソースの利用目的と設計ポイントについて、吹き出しで追記しています。
Azure Orbital Ground StationとVM間の通信はプライベートネットワークでの接続を実施しており、「操作ログの保管用」「衛星の生データ保管用」のStorage Accountを作成しています。また、RunbookのAutomationによってストレージへの出力を自動化しており、VM上で処理後のデータ保管はData Lake Storageで設計しました。

それでは、機能要件の評価をしていきます。

## 9.機能要件：開発可能となるまでのリードタイムの評価
### 検証観点
衛星データ収集サービス利用に関する手続きや申請の観点と、実際にサービスを利用して衛星データを利用者に提供するまでの時間をAWS・Azureで比較します。

### 検証内容
- AWS・Azureでそれぞれ衛星データ収集サービスを利用するにあたって必要となる申請を実施
- 承認後に衛星からデータ取得可能となるように、環境整備や各種設定を実施

### 検証結果
手続き・申請に関するAWS・Azureの比較結果を以下にまとめます。

| 観点 | AWS | Azure |
| :---: | :--- | :--- |
|申請が必要となるタイミング|・利用したい衛星の追加<br>・利用したい地上局の追加<br>・コンタクトスケジュールの設定や変更|・利用したい衛星の追加<br>・KSAT社の地上局の追加|
|申請方法|・メール（英語）	|・AzureポータルよりSR起票（英語）|
|申請内容	|・アカウントID<br>・衛星名称<br>・利用目的	|・衛星名称<br>・利用目的|
|承認までに要した時間（実測値）	|5営業日以降（検証時は7日）	|	翌営業日以降（検証時も翌営業日）|

以上より、AWSの方が若干申請は煩雑で、かつ時間がかかることも分かりました。一方で、Azureに関しては、申請内容自体もシンプルで、かつ承認までの時間も短期間で済むことが分かりました。（今回試したタイミングが、たまたまこのような結果になっただけかもしれませんが）

### コンタクトスケジュールとは
衛星とデータを送受信する際に、地上局側で衛星とのコンタクトを試みるスケジュールのことを指します。Azureでは、自身で設定したコンタクトプロファイル(対象の衛星やコンタクト時間、衛星の高度、帯域などを設定)や地上局、データ通信を実施したい時間帯に基づき、候補となるスケジュールが表示されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3281098/5ea6f119-f07b-9941-24c5-8d43afa7b261.png)

## 10.機能要件：衛星データ取得から解析環境までのデータ連携先の切替
### 検証観点
サービス提供者によって処理されたデータが、サービス利用者の環境で閲覧可能となるか確認します。

### 背景：Azure Orbital Ground Stationを使用する際のデータ連携について
衛星からAzure上にデータ連携する経路としては、衛星→Azure Orbital Ground Station→VMの経路のみとなります。その後、VM以降のデータ連携は、クラウドサービスを使用して柔軟に構築することが可能となる想定です。

### 検証内容
以下経路が実現可能となるようにAzure Orbitalや他リソース上の設定をしました。
① Azure Orbital Ground Stationから衛星データの処理を実施するVMへの連携
② VMからサービス提供者側のストレージサービスへのデータ格納
③ サービス提供者側のストレージからサービス利用者のストレージサービスへ連携

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3281098/4a929673-a5fd-dd87-4db0-669085862e1a.png)

### 検証結果
###### ①Azure Orbital Ground StationからVMへのデータ連携
**コンタクトプロファイル**というリソースを使用して、連携先のVMを指定することで、**Azure Orbital Ground Stationをサポートしたリージョン**であれば**任意のVMを複数**指定することが可能でした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3281098/4cbf7dfe-f843-def3-5beb-c62cd5a5822e.png)

一方で、2024年2月時点でAzure Orbital Ground Stationは日本リージョンをサポートしていないため、**国内に閉じたデータ連携は不可**となっています。

###### ②③VMからストレージへのデータ連携
Azure上のクラウド機能により、リージョンやリソースグルプ跨ぎのデータ連携が可能でした。
また、利用者希望に沿ったストレージサービスへ連携することも可能です。

## 11.機能要件：衛星データの復調構成の検証
### 検証観点
衛星から受信したデータの復調方式はカスタマイズ可能か

### 背景
衛星からの信号を変換して処理するにあたって、復調にモデムが必要となります。モデムの種類やパラメータを変更が求められるケースもあるため、検証します。

### 検証内容
独自のモデムで復調可能となるようにAzure OrbitalとVMを設定します。

### 検証結果
**Azure Orbital上の設定で、復調前の生データをVMに連携**することはできました。**アプリ(GNU Radio)をデータ連携先のVM上にインストール**し、モデムとして機能させられます。また、復調時のパラメータ等を**自由に設定可能な環境**を構成することも可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3281098/abf54d9c-3291-eac3-d7e3-c03bd9349dcd.png)

参考までに、マネージドモデムと独自のモデムについて説明します。
Azure Orbital Ground StationからVMへデータ連携する際に設定するコンタクトプロファイルにて、チャネルごとにAzureが提供するマネージドモデム(Preset Named Modem Configuration) と、独自のモデム(Raw XML)が選択可能となっています。

###### マネージドモデム選択時
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3281098/88c7881a-62a0-44b2-ca5b-094703301ff6.png)

###### 独自のモデム選択時
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3281098/ffc1415e-2865-9f49-3cc8-3f3beaf5a0ed.png)

Azure Orbitalのマネージドモデムは、DIFIを利用してデジタル化されたRF信号を送受信するデジタイザーで構成されています。


## 12.機能要件：衛星データの補正・圧縮処理の検証
### 検証観点
衛星から受信したデータの補正や圧縮処理が実施可能であるか

### 背景
地上局で受信された生データは、**データ補正や圧縮処理**を実施する必要があるため、検証します。

### 検証内容
**データ連携先のVM**上に、補正・圧縮処理を実施するアプリを構成した。

### 検証結果
**Azureの機能**として、データの補正や圧縮処理を**マネージドに実施してくれるサービスはありませんでした**。しかし、補正・圧縮可能なアプリ(NASA Direct Readout Laboratoryツール)を使用して処理を実施することができました。ただ、アプリでの対応が必要となるため、**衛星によっては衛星固有情報を取り込んだ特有の作り込みが必要**となることも判明しました。

なお、今回はクラウドサービスによる衛星データの前処理の実現可否の検証が目的であるため、補正手法等が問われる高次処理については実施していません。


# まとめ
第一弾で紹介した性能要件なども含め、今回評価した項目のまとめを以下に記載します。

| No | 分類 | 評価項目 | 評価結果 |
| :---: | :---: | :--- | :--- |
| 1 |	セキュリティ要件 | プライベートネットワーク環境下でデータ連携が可能か |・**AWS・Azureともにインターネットに出ることなくデータ連携することは可能**<br>|
|2|	セキュリティ要件 |	通信データの暗号化が可能か|・**AWS・Azureともに暗号化することは可能**<br>・AWSは配信先がEC2・S3ともに、暗号化用のカスタマーマネージド AWS KMS キーを使用した暗号化によるデータ配信が可能<br>・Azureは、Azure ネットワーク標準規定によって、地上局からクラウド上への暗号化はサポート|
|3|	性能要件|	プライベートネットワーク環境下で衛星データが連携されるまでのリードタイムを比較する|・Azureはデータ処理するVMに直接データ連携することが可能だが、AWSはS3を介するため、Azure方が短い時間で衛星データを利用者に連携できる|
|4|	コスト要件|	衛星データ収集サービスの利用料を比較する|・専用の地上局の準備が不要なため、パブリッククラウドの衛星データ収集サービスを採用することで大幅なコスト削減の実現は可能|
|5|	耐障害性要件|	地上局・データ配信先を冗長化することが可能か|・AWS・Azureともに1つの衛星利用時に複数地上局の選択可能<br>・1つの地上局に対する**リージョンレベルの冗長性は、Azureの方が取りやすい**|
|6|	耐障害性要件|	マルチクラウド構成を取ることが可能か|・AWS Ground StationとAzure Orbitalを利用できる衛星であれば、**マルチクラウド構成を取ることが可能**|
|7|	法規制・監査要件	|日本国内のデータ保管に絞ることが可能か|・AWS・Azureともに衛星データ収集サービスをサポートしているリージョンに依存するため、2024年2月時点では**国内に限定することは不可**|
|8|	法規制・監査要件	|	クラウドベンダーによる衛星データの利用があるか|・サポートより、AWS・Azureともに**衛星データを取得される可能性はない**と回答あり|
|9|	機能要件	|衛星データ収集サービスが利用可能となるまでのリードタイムを比較する|・承認までに要した時間および申請頻度の少なさから、**Azureの方がリードタイム短く利用開始可能**<br>・AWSに関してはコンタクトスケジュール設定時に初めは申請が必要となるため、運用時の管理者の負荷は高くなると考えられる|
|10|	機能要件	|	利用者が指定するパブリッククラウドサービスに衛星データを連携可能か|・地上局や衛星データ収集サービスを利用している環境とは異なるリージョン・リソースグルプ跨ぎで、**任意のストレージサービスに連携することは可能**|
|11	|機能要件	|	衛星から受信したデータの復調方式はカスタマイズ可能か|・**復調時のパラメータ等を自由に設定可能な環境構築は可能**<br>・Azure Orbital上の設定で、マネージド・カスタムモデムを選択できる<br>・アプリ(GNU Radio)をデータ連携先のVM上にインストールし、モデムとして機能させることができた。|
|12	|機能要件	|	衛星データの補正・圧縮処理の開発効率化が可能か|・**VM上に補正・圧縮可能なアプリを構成することで実現可能**<br>・**Azureの機能**として、データの補正や圧縮処理を**マネージドに実施してくれるサービスはない**<br>・また、衛星別の情報を取り込んだアプリの作り込みは必要|

今回、AWS・Azureのそれぞれ宇宙サービスであるGround Stationのサービスや、サービス利用時の構成等も踏まえた検証を実施したが、申請フローやプライベートネットワーク環境化での構成に多少違いはあるものの、AWS・Azure間で衛星データ収集サービス内容や機能として大きな差異はないことが判明しました。

ただ、やはりオンプレと比較すると多くのメリットがあることでしょう。自前で地上局を準備する期間に比べ、開発準備のリードタイムの短縮と費用削減効果が見込まれるうえ、複数地上局を利用できることやマルチリージョン構成が可能なため、冗長性という観点でも優位性を示せたのではないでしょうか。

普段の業務とは離れて、気になっているサービスをとことん調べてみるのも面白いですね。