前回のnote記事「マネージドサービス、コンテナ、サーバレス」を説明した際に、Web API (Application Programming Interface)アーキテクチャを採用することで、従来のWeb 3層アーキテクチャ実現方式よりサーバアプリケーションを軽量化でき、コンテナ化と合わせて大規模なアプリケーションをより低コストで実現できると説明しました。

アプリケーションアーキテクチャを選択する際には、システム要求や既存の各種制約、開発効率、その他さまざまな観点から検討すると思いますが、ここではインフラ技術とコスト最適という観点からWeb APIアプリケーションアーキテクチャについて説明します。

従来のWebアプリケーションサーバで画面を生成してブラウザに返し、画面間の遷移を管理するというアーキテクチャに比べて、ユーザ体験設計との親和性が高く、シンプルな構成でアプリケーションを稼働でき運用負荷が下がると考えるためです。

Web APIについて

Web時代のAPIの経緯

1990年代以降、アプリケーションの通信プロトコルとしてHTTPが広く使われるようになってから、HTTPをベースとしたいくつかのAPIが利用されてきました。

大まかに捉えると、最初にシンプルなHTTP、次にSOA（Service Oriented Architecture）という考え方をベースにしたSOAP（Simple Object Access Protocol）、そしてWebサービスを実現するREST API（REpresentational State Transfer API）、さらにより発展させたGraphQLやgRPCというように分類できると考えます。

ここでは、厳密なAPIの定義やその歴史を述べませんが、REST以降、Webアプリケーションの作り方が大きく変わるものが出てきてWeb APIという総称で呼ばれるようになりましたので、REST以降を中心にWeb APIについて説明します。

RESTについて

RESTについて厳密な定義はここでは述べませんが、インフラ技術の観点から特徴を簡易的に整理すると、セッション管理が不要のステートレスであること、操作対象オブジェクトがURL（URI）で一意に識別されること、POSTやGET、DELETE等HTTPのメソッドを使って命令すること、JSON等構造的なデータをやり取りできること、が上げられます。

同じHTTPを使っていても、古いWeb 3層のアプリケーションで、JavaのAction Servletに対応する全体で1つのURLにPOSTだけを投げ、Key=Dataの自由な羅列を送りつけて画面を返してもらい、次のリクエストではセッションIDを渡してステートを維持していた方式と比べると大きく変わっています。

RESTによるWeb APIアプリケーションのイメージ

業務アプリケーションの処理の対象となるものをURLで一意に表現し、そのURLに対して情報の付け足しや変更、削除を行う処理をPOSTやPUT、DELETEといったHTTPメソッドと、HTTPボディに入れるJSON等のフォーマットで表現します。

たとえばあるアプリケーションでは、ユーザプロファイルという対象がhttps://…./profiles/123456789 というような一意のURLで表現され、ここに対して、性別やメールアドレス、電話番号をJSONフォーマットでPUTすることで、ユーザプロファイルを更新するというイメージが考えられます。

対象に対する処理は1リクエストに1つで、REST APIは更新に成功したか失敗したかと対応するデータを結果として返します。次のクライアントからのリクエストは、たとえばイベントへの申し込みであったとすると、イベントを一意に表すURLに対してHTTPリクエストで情報を渡していくことになります。これら2つのリクエストにセッション管理は不要です。

REST APIはリクエストに対して結果を返すだけなので、画面はクライアントアプリケーション側で構成されます。画面をクライアント側で生成する方式はCSR（Client Side Rendering）と呼ばれます。

パソコンであればブラウザ上のJavaScriptだったり、スマートフォンであればネイティブアプリでクライアントアプリケーションを開発することになります。とくにWebアプリケーションにおいては、ブラウザベースのSPA（Single Page Application）という方式が合わせて使われることが多く、SPAクライアントアプリケーションは、REST APIに対して必要なタイミングでAPI呼び出しを行いその結果を動的に画面に反映していきます。

Nuxt.jsやNext.jsのようなフレームワークで構築されたSSR（Server Side Rendering）やSG（Static Generation）もCSRと組み合わせて利用でき、この場合も動的データ取得にWeb APIを利用することになります。

バック側は、REST APIがデータ項目への単純操作だけのため、業務処理内容によっては非同期での追加処理を行う必要があるかもしれません。

たとえば、イベントの申し込みを受け付けたら、それをトリガーに非同期で予約席を確保するAPIを呼び出し、予約が確保できたら結果を非同期でクライアントに返すという処理が必要かもしれません。

もしくはイベント申し込みを受け付けたらそれをトリガーに非同期で一斉同報送信メールの宛先にメールアドレスを追加するという処理が必要かもしれません。

いずれにせよ、RESTによる対象の操作に対して、非同期で追加の処理を行い、次の業務処理に最適なデータを作っていくというような、イベントドリブンの連携アプリケーションがバックで動くことになると考えます。

Web APIのインフラ観点でのメリット

Web APIには、インフラ技術、とくにサーバ側の負荷という点で、従来のWebアプリケーションに比べて次のメリットがあります

• プレゼンテーション層をクライアントアプリケーションに任せる

• 各リクエストが独立しておりサーバ側で画面遷移等の複雑なセッション管理が不要

Web 3層で言うプレゼンテーション層をクライアントアプリケーションで実装することになるため、サーバ側でこの部分の負荷が軽くなります。サーバ負荷だけではなく、クライアントアプリケーション開発とバックアプリケーション開発の責任分界点がWeb APIを境にして明確になり、それぞれを独立して開発できます。

最近はUX (User Experience=ユーザ体験)設計をしたり、サービス開始後もUI（User Interface）を変更しながらユーザ体験を向上させることが増えてきており、バック側のサーバアプリケーションと独立してクライアントアプリケーションを管理・メンテし、バック側に変更入れることなく体験設計に応じて頻繁にフロントアプリケーションをリリースしていけることには大きなメリットがあります。

また、従来のWebアプリケーションでは、1つの業務処理が複数の画面にまたがって処理されることが多く、その場合、各画面の遷移をサーバ側で一連の流れとして把握するために、遷移間のセッション管理を実装する必要がありました。

そのため、負荷分散機能やセッション情報の連携や保管に専用の機能を作り込み対応してきました。Web APIでは、APIのリクエストはステートレスで、リクエスト間でアプリケーションの整合性を保つために複雑なセッションを維持する必要がなくなり、サーバ側の構成が単純になって、サーバ負荷も大幅に軽減されます。

プレゼンテーション層とセッション管理がサーバアプリケーションから不要となることで、サーバアプリケーションはロジック開発に集中でき、かつ実装としても非常に軽量になります。

URLで表現される対象への処理に単純化され、処理が軽量化されるためコンテナ化もしやすく、水平に多数コンテナを並べることで、ベースとなるインフラコストを抑えつつ、大量アクセスが来たときもスケールアウトしてコンテナ数を素早く増やすことでスケーラビリティを確保しやすくもなります。

従来の重たいWebアプリケーションのままコンテナ化するよりも、はるかにコンテナのメリットを享受できます。

最後に、RESTのような汎用的なWeb APIを利用すれば、システム間連携、アプリケーション間通信のインタフェースとして、システム外にも公開しやすい作りにすることができます。現状、対外的なアプリケーション通信のインタフェースとしてWeb APIが広く使われており、こうした公開Web APIも実現しやすくなります。

Web APIの考慮点

考慮点として、そもそも業務内容によっては、Web APIによるアプリケーション実装は難しいということもありえます。

とくに対象を一意のURLで表現するRESTでは、インベントリー管理系のアプリケーションやマスター管理系の処理には適していますが、トランザクション履歴管理系のアプリケーションでは工夫が必要です。

政府系や自治体系のアプリケーションではインベントリー管理系が多いため、Web APIの効果は得られやすいと考えます。

また、クライアントアプリケーション開発が必要になったり、イベントドリブンのバックアプリケーション開発が必要になったりし、従来の開発体制のままでは逆に効率が悪くなる可能性もあります。

イベントドリブンな仕組みはクラウドサービスでさまざまな機能があるため実現は容易になりました。ただ、これらを分割して開発することになるので、サブシステムスコープに応じた適切な開発体制を組めるかも重要になります。

さらには、SPA等インターネットWebサービスで使われてきている技術のため、完全に閉じたネットワーク内で利用するには、ライブラリやパッケージのインポートや、APIサービスを閉域網で使うために一工夫が必要です。

SPA等のフレームワークとしてオープンソース系のライブラリを使用しますので、プロジェクトによってはサポート含めたオープンソースソフトウェアの適切な扱いも考えないといけないという課題も出てきます。

ガバメントクラウドでのWeb API利用の考え方

ガバメントクラウドでのWeb API利用の考え方とイメージ

ガバメントクラウドは、あくまで利用システムのインフラとなるクラウドを提供していきますので、アプリケーションアーキテクチャについては利用システム側で検討いただきます。

ただし、インフラの観点から、コストが安く、スケーラビリティに強く、コンテナやサーバレスを活用できるWeb APIアプリケーションアーキテクチャを紹介し、主要なアーキテクチャパターンの1つとして推奨していきたいと考えています。

ガバメントクラウドでのWeb API利用イメージとしては、たとえば申請系のアプリケーションを例に取ると、利用者がブラウザから申請アプリにアクセスすると、ブラウザで動くSPAアプリケーションがダウンロードされ、必要な情報が申請Web APIから取得されてSPAアプリケーションに表示されます。

利用者がSPAアプリケーションに入力した情報は裏側でWeb API経由で更新されていきます。いったん入力が終わり申請が受け付けられると、裏側で連携先の審査承認アプリがAPIで呼び出され、職員による申請に対する受付、審査が始まります。審査承認後、申請API経由で承認結果が戻され、利用者に承認されたことが通知されるというようなイメージになります。

申請Web APIのAPI実装部分は、クラウドのAPIサービスを使っても、コンテナ等でアプリケーションとしても実現可能です。APIサービスの裏側のアプリケーションもしくはAPIを含んだアプリケーションは、APIへの要求に対応するデータを適切な処理をしつつデータベースに対して読み書きし、API経由でフロントのSPAアプリケーションに返します。

Web APIアプリケーションのコンテナは、ステートレスということもあり、大量に並べてリクエストを処理することも可能です。単純なAPIに対する情報の読み書きに対するためであれば、データベースもスケーラビリティに強いNoSQLなども使えます。

業務的な処理は後方のアプリケーションに非同期連携して、検索機能などを使いながら業務処理を行うことで、申請Web APIを受け付けるデータベースは複雑な機能が不要な代わりにスケーラビリティの高いデータベースを選択できます。

ガバメントクラウドでのWeb APIの効果

Web APIの効果はさまざまあると思いますが、ガバメントクラウドの観点ではこれまで説明してきたとおり、プレゼンテーション層とセッション管理機能が不要になることによるサーバアプリケーションの軽量化とサーバ負荷の軽減、それによるコスト削減が考えられます。

また、ステートレスで軽量なアプリケーションをコンテナで並列に並べることで高いスケーラビリティも実現できます。ガバメントクラウドで実現する国民向けのユーザ数の多いWebアプリケーション等では、アーキテクチャ設計上の重要なポイントになります。

さらには、アプリケーションの軽量化とそれによるコンテナ化により、別途説明しているイミュータブルなインフラ運用が実現しやすくなり、イミュータブルな運用で得られるコスト削減効果も期待できます。

副次効果として、Web APIアプリケーションアーキテクチャの設計次第ではありますが、Web APIによりアプリケーションの処理が半強制的にシンプルになることで、保守性の悪い巨大なモノリシックなアプリケーションが作れなくなる代わりに、複数のサービスで連携して全体業務を処理するアーキテクチャにしやすくなり、マイクロサービスの考え方が採用しやすくなります。マイクロサービスについては別途説明します。

このように、Web APIアーキテクチャを採用することで、インフラ観点では、ガバメントクラウドが目指す、コスト効率がよく、柔軟なインフラが実現しやすくなると考えます。

ガバメントクラウドでのWeb APIの方向性

Web APIのアーキテクチャを採用するかどうか含めてアプリケーションのアーキテクチャは利用システムで検討いただくことになります。

ガバメントクラウドとしてはWeb APIアーキテクチャにインフラ観点で大きなメリットがあると考えていますので、Web APIアーキテクチャを実現しやすいようなIaCコードのサンプルテンプレートを整理していくことを検討しています。

このサンプルテンプレートを利用システムに使っていただくことで、これまで説明してきたイミュータブルなインフラ運用やマネージドサービスの活用と合わせて、Web APIによるコスト効率がよく柔軟なインフラ運用が実現できると考えています。

Web APIは、RESTからGraphQLやgRPCなどに発展してきています。GraphQLにすることで、データの項目や型定義ができるようになり、参照や更新の他サブスクリプション処理も利用できるようになってサーバ側からのデータ送信や通知が実現しやすくなります。

gRPCでは、HTTP/2やプロトコルバッファという現状のHTTPの置き換えとなるプロトコルと合わせて効率的かつ高速な通信が可能となり、クライアントとサーバでデータ型含めてインタフェース定義ができるため、Web APIの実現がしやすくなります。これらについてもガバメントクラウドを利用するシステムで採用の検討はできると考えています。

ガバメントクラウドとしては、最新技術を採用しやすくすることも目的としていますので、RESTやGraphQL、gRPC等の技術を採用してシステム開発を進めやすくしていく検討をします。

GraphQLやgRPCでは対応するクラウドサービスも異なってくるため、利用要望に合わせて対応するテンプレートの準備を進めてWeb APIアーキテクチャを採用しやすくすることで、さらにコスト効率がよく柔軟なインフラの実現に向けての検討を進めていきます。

◆関連するデジタル庁の採用情報は以下のリンクをご覧ください。

◆デジタル庁Techブログの記事一覧は以下のリンクをご覧ください。

◆デジタル庁の採用に関する情報は以下のリンクをご覧ください。