地上系のAPI設計 — REST/gRPCというウェブ由来の設計思想を宇宙地上系に取り込む

この回で学ぶこと

MOサービスの回では、ミッション運用センター(MOC)内部のソフトウェアコンポーネントどうしを連携させるために、CCSDSが宇宙業界独自に育て上げたサービス指向アーキテクチャ(SOA)を見ました。MAL(Message Abstraction Layer)が定義するSEND・SUBMIT・REQUEST・INVOKE・PROGRESS・PUBLISH-SUBSCRIBEという6種類の相互作用パターン、その上に積み重なるCOM(共通オブジェクトモデル)、さらにその上の監視制御・プランニングといった具体的なサービス群——これらはいずれも、CCSDSという宇宙分野の標準化団体が、宇宙運用というドメインの要求から出発してゼロから設計したものでした。

しかし、ソフトウェアどうしを標準化されたインターフェースで連携させるという問題そのものは、宇宙業界だけのものではありません。地上のウェブ・クラウド業界でも、まったく同じ問題——性質の異なるサービスをどう疎結合に組み合わせるか——が何十年も前から扱われ、そこではREST(Representational State Transfer)やgRPCといった、宇宙業界とは独立に発展してきた設計思想・技術が広く定着しています。近年、地上局運用を商用サービスとして提供する事業者(GSaaSの回で見たGround-Station-as-a-Service)を中心に、こうした地上のウェブ・クラウド由来のAPI設計手法を、地上系ソフトウェアの統合に積極的に取り入れる動きが強まっています。

この回では、まずREST APIの3つの設計原則(リソース指向・HTTPメソッドによる意味づけ・ステートレス性)を整理し、次にgRPCがProtocol Buffersという型付きスキーマとHTTP/2ベースのストリーミングによってREST APIより高頻度・低遅延な通信に向いている理由を見ます。そのうえで、なぜ商用地上局サービスがCCSDS独自プロトコル(SLE等)ではなくこうしたモダンなAPI技術を好んで採用するのか、その実務的な動機を考えます。

直感的導入: 「宇宙業界の言葉」と「ウェブ業界の言葉」

MOサービスの回で見たMAL・COMのような枠組みを学ぶには、MOオブジェクト・相互作用パターン・COMの型システムといった、CCSDS独自の一連の概念を新たに習得する必要がありました。これは決して無駄ではなく、宇宙運用というドメインに合わせて練り上げられた、筋の通った設計です。しかし裏を返せば、ウェブ開発の経験を持つ一般的なソフトウエアエンジニアが、いきなりMOサービスのシステムに参加しようとすると、まずMAL・COMという「宇宙業界の方言」を学び直すところから始めなければならない、という参入障壁が生まれます。

一方、世の中の大多数のソフトウェアエンジニアは、日常的にREST APIやgRPCを扱っています。スマートフォンアプリがサーバからデータを取得する仕組みも、企業の内部システムがマイクロサービスどうしで通信する仕組みも、多くはREST APIかgRPCのどちらか(あるいは両方)で実装されています。つまりこれらは、宇宙業界の外側で自然発生的に「共通言語」としての地位を確立した技術です。

もし地上局サービスや衛星運用ソフトウェアが、こうした「ウェブ業界の共通言語」で外部インターフェースを公開すれば、宇宙分野の専門知識を持たない一般的なソフトウェアエンジニアでも、既存のスキルセットのままそのシステムと連携するソフトウェアを書けるようになります。この「参入障壁の低さ」こそが、この回で扱うREST/gRPC採用の中心的な動機です。以下、それぞれの設計思想を具体的に見ていきましょう。

定式化・整理その1: RESTfulウェブAPIの3つの設計原則

RESTは、2000年にRoy Fieldingの博士論文で提唱されたアーキテクチャスタイルで、今日のウェブAPIの大部分の基礎になっています。RESTそのものは特定のプロトコルや実装を指す言葉ではなく、いくつかの制約(constraint)の集合として定義されますが、実務上重要になるのは主に次の3点です。

(1) リソース指向: URLがリソースを表す

RESTでは、システムが扱う対象を**リソース(resource)**として捉え、各リソースに一意のURL(識別子)を割り当てます。たとえば、ある地上局のあるパス(可視時間帯)予約を表すリソースなら、

https://api.example-gs.com/v1/passes/{pass_id}

のように、「パスというリソースの集合(/passes)の中の、特定の1件({pass_id})」という階層構造がURLそのものに表現されます。これは、MOサービスの回で見たMOサービスのような「オブジェクト・属性・関係」という型システムをMAL・COMという専用の抽象層で表現していたのと対照的に、URLという既存のウェブの仕組みだけでリソースの識別・階層構造を表現してしまうという発想です。

(2) HTTPメソッドによる操作の意味づけ

リソースに対する操作は、HTTPが元々備えている**メソッド(動詞)**に対応づけられます。

HTTPメソッド	意味	例
GET	リソースを取得する(副作用なし)	GET /passes/{pass_id} — パス予約の詳細を取得
POST	新しいリソースを作成する	POST /passes — 新しいパス予約を作成
PUT	リソースを丸ごと置き換える(更新)	PUT /passes/{pass_id} — 予約内容を更新
DELETE	リソースを削除する	DELETE /passes/{pass_id} — 予約をキャンセル

重要なのは、「何をするか」という動詞が、URLの中に独自の文字列として書き込まれるのではなく、HTTPプロトコルが標準で持っているメソッドに乗るという点です。これにより、「あるパスの予約を取得したい」というリクエストを見た人間(あるいは中間にあるプロキシ・キャッシュサーバなどの汎用ソフトウェア)は、URLとメソッドの組み合わせだけから操作の意味を推測できます。GETリクエストは副作用を持たない(何度呼んでも状態が変わらない)という規約が徹底されていれば、たとえば途中のネットワーク機器がGETリクエストの結果を安全にキャッシュしてよい、といった最適化も可能になります。

(3) ステートレス性

RESTのもう1つの中心的な制約が**ステートレス性(statelessness)**です。これは、サーバ側が、クライアントとのやり取りの「文脈」をリクエストをまたいで記憶しないという原則を指します。あるリクエストを処理するのに必要な情報(認証情報、パラメータなど)は、そのリクエスト自体にすべて含まれていなければならず、「1つ前のリクエストで指定した条件を覚えておいて、今回はそれを踏まえて処理する」といったサーバ側の記憶に依存した振る舞いは許されません。

$$\text{Response} = f(\text{Request}), \qquad \text{(サーバの内部状態に依存しない)}$$

これは、MOサービスの回で見たMALの相互作用パターンのうち、たとえばINVOKEパターン(「受理された」と「結果が出た」を分離し、プロバイダ側が処理の進行状態をコンシューマとの間で一定期間保持する)のような、やり取りの途中経過をプロバイダ側が状態として持ち続ける設計とは対照的です。ステートレス性を徹底することで、サーバ側の実装がシンプルになり、複数のサーバインスタンスへの負荷分散(どのサーバがリクエストを受けても同じ結果が返る)がしやすくなり、途中でサーバが再起動しても進行中のやり取りの整合性を心配する必要が少なくなる、という運用上の利点が生まれます。ただし、ステートレス性はすべての要求パターンに万能というわけではなく、後述するようにリアルタイム性・双方向性が強く要求される場面では、この制約がむしろ不向きになる場合があります。

定式化・整理その2: gRPCが解決する問題

REST APIは「1回のリクエストに対して1回のレスポンスが返る」という単純なやり取りに向いていますが、テレメトリのリアルタイム監視のように、サーバから継続的に、高頻度でデータが流れ続ける場合には不向きな面があります。RESTでこれを実現しようとすると、クライアントが短い間隔でGETリクエストを繰り返し送る「ポーリング(polling)」という力ずくの方法に頼ることになり、これは不要なオーバーヘッド(リクエストヘッダの繰り返し送信、コネクション確立のたびのオーバーヘッド)を生みます。

gRPCは、Googleが開発した高性能RPC(Remote Procedure Call、遠隔手続き呼び出し)フレームワークで、この種の要求に対してREST APIとは異なるアプローチを取ります。gRPCの特徴は主に2つです。

Protocol Buffersによる型付きスキーマ定義

gRPCでは、やり取りするメッセージの構造を**Protocol Buffers(protobuf)**という言語非依存のインタフェース定義言語(IDL)であらかじめ厳密に定義します。たとえばテレメトリの1サンプルを表すメッセージなら、次のように型を明示して定義します。

message TelemetrySample {
  string parameter_id = 1;
  double value = 2;
  int64  timestamp_ms = 3;
}

このスキーマ定義から、C++・Python・Javaなど複数のプログラミング言語向けのコード(メッセージの構造体・シリアライズ処理)を自動生成できます。通信時には、このスキーマに基づいてコンパクトなバイナリ形式にシリアライズされてから送られるため、JSON(RESTでよく使われるテキストベースのデータ形式)のようにフィールド名の文字列を毎回送る必要がなく、シリアライズ・デシリアライズの計算コストとデータサイズの両方を削減できます。Protocol Buffersがどのようにバイト列へと変換されるか、その具体的な符号化方式の詳細は、次々回の宇宙データシリアライゼーションのレッスンで扱います。

HTTP/2ベースのストリーミング

gRPCは、リクエストとレスポンスが1対1で完結するREST的なやり取りに加えて、ストリーミングという通信パターンをネイティブにサポートします。gRPCが定義する4つの呼び出し方式を整理すると、次のようになります。

方式	やり取り	用途の例
Unary RPC	1リクエスト → 1レスポンス	REST的な単発の問い合わせ
Server streaming	1リクエスト → 複数レスポンスの連続配信	テレメトリのリアルタイム監視
Client streaming	複数リクエストの連続送信 → 1レスポンス	大量サンプルのバッチ送信後の集計結果取得
Bidirectional streaming	双方向で独立にメッセージを流し続ける	対話的なコマンド送信とステータス応答の同時進行

これが可能なのは、gRPCがHTTP/2を通信の基盤に採用しているためです。HTTP/2は、1本のTCPコネクションの上で複数の独立したストリームを多重化(マルチプレクス)できるため、RESTで一般的なHTTP/1.1のように「リクエストごとに新しいコネクションを張り直す、あるいは1本のコネクションを使い回すにしてもリクエストを順番に処理する」といった制約がなく、サーバがクライアントに向かって能動的にメッセージを送り続ける(サーバプッシュ的な)通信を、低いオーバーヘッドで実現できます。

$$\text{REST (HTTP/1.1, Unary)}: \quad \underbrace{C \to S}_{\text{リクエスト}} \; \underbrace{S \to C}_{\text{レスポンス}} \quad (\text{1往復で完結})$$ $$\text{gRPC (HTTP/2, Server streaming)}: \quad \underbrace{C \to S}_{\text{リクエスト1回}} \; \underbrace{S \to C, S \to C, S \to C, \ldots}_{\text{継続的な配信}}$$

MOサービスの回で見たMALのPUBLISH-SUBSCRIBEパターンやPROGRESSパターンが、それぞれ「複数コンシューマへの一斉配信」「長時間処理の途中経過報告」という要求に対応するために設計されたのと同じ動機が、gRPCのストリーミング機能にも見て取れます。ただし実現方式は対照的で、MOサービスがMAL・COM・個々のサービス定義という宇宙業界専用の階層を新たに積み上げて要求に応えたのに対し、gRPCはHTTP/2という地上のウェブインフラで既に広く普及している技術の上に、ストリーミングという振る舞いを型付きスキーマと組み合わせて実現するという違いがあります。低頻度な問い合わせにはREST(あるいはgRPCのUnary RPC)、テレメトリのような高頻度・低遅延なストリームにはgRPCのストリーミング、という使い分けが実務上の目安になります。

実務での使われ方

商用地上局サービスにおけるモダンAPIの採用

GSaaSの回で見た商用地上局サービスの多くは、パス予約・アンテナ設定・受信データの取得といった外部インターフェースを、CCSDSのSLE(Space Link Extension)ではなくREST APIとして公開する傾向を強めています。SLEはBIND-START-TRANSFER-DATA-STOP-UNBINDという骨格を持つ堅牢な標準ですが、SLEプロバイダ・ユーザのソフトウェアを実装するには、SLEの用語・状態遷移・トランスファーサービス(RAF・RCF等)の仕様を専門的に理解している必要があります。一方、パス予約や過去の受信データの一覧取得のような操作であれば、一般的なウェブ開発者が使い慣れたREST APIとして公開する方が、開発者エコシステムを取り込みやすいという実務上の利点があります。実際、多くの商用地上局サービス事業者は、Webベースの予約ポータルと並行して、同じ機能をプログラムから呼び出せるREST APIを提供し、ドキュメント(OpenAPI/Swagger仕様など、ウェブ業界で広く使われるAPI記述形式)を公開する、という形態を取ることが一般的になっています。

一方で、受信したテレメトリやハウスキーピングデータをリアルタイムに近い頻度で監視ダッシュボードやMOCへ配信するような場面では、ポーリングベースのREST APIよりも、gRPCのストリーミング機能(あるいは同種の性質を持つWebSocketなどの技術)の方が低遅延・低オーバーヘッドで適しており、これらを併用するハイブリッドな構成も見られます。

レガシーCCSDS標準とモダンAPIを橋渡しするゲートウェイ

SLEのような確立されたCCSDS標準は、地上局のRFハードウェアとの緊密な連携や、フレーム転送の信頼性・タイミング精度において長年の実績があり、すぐに置き換えられるものではありません。そこで実務では、**ゲートウェイ(あるいはアダプタ層)**と呼ばれる中間コンポーネントを設けて、両者を橋渡しする設計パターンがよく採用されます。

具体的には、地上局とのフレームのやり取りそのものは従来通りSLEプロトコルで行い、そのSLEプロバイダの手前に、REST APIやgRPCサービスとして外部に公開されるゲートウェイソフトウェアを配置します。このゲートウェイが、外部から来たREST/gRPCのリクエスト(たとえば「このパスの受信データを取得したい」)をSLEのBIND・START・TRANSFER DATA等の一連の手続きに変換し、SLE側から返ってきたフレームを、外部のクライアントが扱いやすいJSON形式やprotobuf形式のレスポンスに変換して返す、という役割を担います。

$$\text{外部クライアント} \;\xrightarrow{\text{REST / gRPC}}\; \text{ゲートウェイ} \;\xrightarrow{\text{SLE (RAF/RCF)}}\; \text{地上局}$$

この設計は、MOサービスの回で見た「MALが伝送技術に依存しない抽象層として、下層のトランスポートバインディングを差し替え可能にする」という発想と部分的に似ていますが、決定的な違いは、MOサービスがCCSDS自身が定めた抽象化の枠組みであるのに対し、このゲートウェイパターンは既存のCCSDS標準(SLE)を変更せずに温存したまま、その手前に地上のウェブ業界標準の技術で書かれた「翻訳層」を後付けするという点です。この方式であれば、地上局側の信頼性の高いSLE実装には手を入れず、外部に公開するインターフェースだけを段階的にモダン化していくことができ、既存のミッション運用資産を保護しながら新しい開発者エコシステムを取り込むという、現実的な移行戦略になっています。

演習問題

1. RESTの「ステートレス性」の制約を、MOサービスの回で学んだMALのINVOKEパターン(即時受理確認と非同期の結果を分離するパターン)と比較し、両者が「処理の進行状況」をどのように扱う点で異なるか説明してください。

2. あるミッション運用者が、(a) 過去1週間分のパス予約履歴を一括取得したい場合と、(b) 現在進行中のパスのテレメトリを1秒間隔でリアルタイムに監視したい場合の、2つの要求を持っているとします。それぞれにREST APIとgRPCのどちらが適しているか、この回で学んだ根拠とともに答えてください。

3. Protocol Buffersのようなバイナリ形式のシリアライゼーションが、JSONのようなテキストベースの形式と比べてデータサイズと処理速度の面で有利になる理由を、本文中のTelemetrySampleの例を参考にしながら、フィールド名の扱いという観点から説明してください。

4. 本文で紹介した「SLEとモダンAPIを橋渡しするゲートウェイ」という設計パターンについて、なぜ地上局側の信頼性の高いSLE実装そのものをREST/gRPCに置き換えるのではなく、ゲートウェイを挟むという間接的なアプローチが実務上好まれるのか、既存資産の保護という観点から考察してください。

まとめと次回予告

この回では、MOサービスの回で見た「宇宙業界が独自に発展させたサービス指向アーキテクチャ」とは対照的に、地上のウェブ・クラウド業界で磨かれたREST APIとgRPCという2つのモダンなAPI設計思想が、地上系ソフトウェア統合にどう応用されつつあるかを見ました。RESTのリソース指向・HTTPメソッドによる意味づけ・ステートレス性という3原則は、単発の問い合わせに適したシンプルな設計を、gRPCのProtocol Buffersによる型付きスキーマとHTTP/2ベースのストリーミングは、テレメトリのリアルタイム監視のような高頻度・低遅延な要求への対応を、それぞれ支えています。商用地上局サービスがこれらを採用する背景には、地上の一般的なソフトウェアエンジニアが扱いやすいインターフェースを提供することで開発者エコシステムを取り込みたいという実務的な動機があり、既存のCCSDS標準(SLE)とはゲートウェイ層で橋渡しするという、現実的な移行パターンも見ました。

次回は、この回で伏線として触れたProtocol Buffersのバイナリ符号化のような、宇宙探査機の限られた帯域・処理能力の中でデータをどう効率的にシリアライズするかという「宇宙データシリアライゼーション」のテーマを掘り下げます。あわせて、探査機に搭載されたコンピュータ自身が、限られたストレージ・電力・耐放射線性という制約の中でデータをどうファイルとして管理するかという「オンボードファイルシステム設計」の話にも軽く触れていきます。

参考文献

• R. T. Fielding, Architectural Styles and the Design of Network-based Software Architectures, Ph.D. dissertation, UC Irvine, 2000
• Google, gRPC Documentation (grpc.io)
• Google, Protocol Buffers Documentation (protobuf.dev)
• CCSDS 911.1-B, Space Link Extension—Return All Frames Service Specification (Blue Book)
• R. Fielding, J. Reschke (eds.), Hypertext Transfer Protocol Version 2 (HTTP/2), RFC 7540, IETF