これまで、noteの記事「Web APIアーキテクチャ」や「マネージドサービス、コンテナ、サーバレス」等で、ガバメントクラウドでのアーキテクティングの考え方について説明してきました。ここでは、そうした考え方を使った具体的アーキテクチャのサンプルについて、これまで一般的だったシステム構成との違いを含め説明します。

サンプルとして想定する業務

なんらかの届出・申請を行う業務を想定することにします。国民や企業からの情報の届出や申請の受付とその後のデータ処理を行う業務を想定し、次の3つの業務処理が含まれることとします。1. 届出・申請、2. 審査・承認、3. 届出状況や審査状況等のレポート。

これまでのアーキテクチャ

これら業務を実装していくためのアーキテクチャとしては、いわゆる「3層Webアプリケーション」のアーキテクチャがよく使われてきたと思います。

「3層Webアプリケーション」のアーキテクチャでは、ユーザのパソコンのブラウザからHTTPリクエストの形で業務アプリケーションの操作や関連するデータが送信され、負荷分散装置が受け付けてWebアプリケーションサーバに振り分け、Webアプリケーションサーバでは受け付けたHTTPリクエストからデータを取り出し処理を加えた上でRDB（リレーショナル・データベース）にデータが書き込まれます。

書き込まれたデータは、アプリケーション閉局後の夜間にバッチアプリケーションで読み取られて処理され、情報系として用意された別のRDBに処理結果が保管されてレポート業務などに使われていきます。

こうしたWebアプリケーションの周辺には、アプリケーションをリリースするための仕組みや、バッチアプリケーションを順番に処理させるジョブ管理の仕組み、システム全体を監視する仕組みやログを集める仕組み、ネットワークログを集めて分析するセキュリティ管理の仕組みなどがサーバインスタンスとして構築されることが多いと思います。

また、サーバインスタンスのWindows OSやLinux OSにログインしてソフトウェアやエージェントをインストールしたり管理したりするための踏み台サーバとそこでの認証の仕組み、およびOSのパッチ適用のための仕組み、OSのアンチウイルスソフトウェアを管理する仕組みなどが構築されます。

システム構成イメージとしては図1となります。

クラウド最適なアーキテクチャ

5つのポイントとメリット

次に、想定している同じ業務アプリケーションをクラウド最適に構成した場合のアーキテクチャの例を説明します。同じアーキテクチャをクラウド最適に作り変える場合、次の5つのポイントを考慮することが重要となります。

1. Web APIアーキテクチャ
   まず、利用者からのアクセスと業務処理はWeb APIアーキテクチャとなります。Web APIアーキテクチャについてはこちらのnoteの記事で説明しましたので方式やメリットなどはそちらを参照ください。
   

2. データベースは業務ごとに分離
   RDBは1つに統合するのではなく、業務ごと（今回の例であれば、届出・申請、審査・承認、レポート）で分離します。分離する基準としては、その業務アプリケーションに要求されるサービスレベルや運用パターンで分離します。
   
   広いユーザ層から24時間365日受け付ける届出・申請はスケーラビリティを重視し、RDBでInsertとSelectのみにしてUpdateを無くしDBMSのロックをシンプルにして大量リクエストをさばけるようにするか、スケーラビリティに強いNoSQLも検討します。業者による審査・承認業務は夜間は停止可能で届出・申請よりはアクセス数が予測できスケーラビリティはそこまで高くなく処理可能です。
   
   その代わり、検索性などを考慮してRDBか場合によっては全文検索サービスとも連携させます。広く一般にデータ公開するレポート業務は、分析済み整形済みのデータをオブジェクトストレージに入れて大規模なスケーラビリティを確保します。
   
   ハードウェアが高価だった時代はDBの統合に大きな意味がありましたが、クラウドになりインスタンスを分けることがコストにそこまで影響しなくなったため、人件費に直結するメンテナンスや運用の容易性の方をより重視してサービスレベルや運用パターンで最適なデータベースを使用し、分離して管理します。
   

3. 夜間バッチではなくイベントドリブン処理
   クラウドのマネージドサービスではRead Replica構成が簡単に組めるため、これを使えば申請を受けての後続処理を即時に行っても性能影響を与えない構成が組みやすくなりました。
   
   後続処理はRead Replicaからデータを読み取るため、更新側のデータベースに性能影響は出ません。更新があるたびにその更新データに対して加工や集計などの処理を動かし次の処理を行うデータベースにデータを保管していくことで、性能影響を考慮して夜間にバッチアプリケーションとして処理をしなくてもよくなります。
   
   夜間バッチアプリケーションが必要になるのは、締め処理や期間での統計等ある一時点の静止点データが必要な処理か、夜間に外部から渡ってくるデータを処理する外部要因のケースと考えられます。そうした処理も途中までの処理は都度処理で済ましておくことができます。それ以外のほとんどのケースは都度の後続処理で対応できると考えます。
   
   夜間バッチアプリケーションについては、これがあると、システムの閉局が必要になったり、夜間の監視要員が必要になったり、バッチアプリケーションが失敗したときの朝の開局までのリカバリーが難しかったりして、システム運用の難度を上げる大きな要因でした。これを廃止、もしくは極小化し、更新イベントがあるたびに後続処理を行う、イベントドリブン処理とすることでシステム運用のシンプル化に大きく貢献します。
   
   また、夜間バッチアプリケーションを廃止・極小化することで、複雑なジョブ連携をジョブフローとして管理するジョブ管理サーバも不要となります。
   

4. 監視やログ管理、リリース管理はマネージドサービスを利用
   多くのクラウドサービスでは、監視やログ管理、リリース管理等の機能がマネージドサービスとして用意されており、ほとんどのサービスとあらかじめ機能連携されていて、簡単に利用開始できます。かつほとんどの場合は低コストです。
   
   これを使うことで高コストなサーバインスタンスを利用しなくてもよくなり、運用管理系ソフトウェア・ライセンスの購入もなくなり、冗長化構成などの検討やソフトウェア設計も不要で設計構築工数も抑えられます。

5. コンテナの利用
   Web APIやイベントドリブン処理アプリケーションはコンテナで管理します。コンテナは仮想化やサーバ統合の文脈で語られることもありますが、その文脈でコンテナを使う価値よりも、アプリケーションのリリースや運用管理の文脈にこそコンテナを使う価値があります。
   
   多くのクラウドサービスにはコンテナインフラやコンテナ管理をマネージドサービスとして用意してあり、これを使えば高コストなサーバインスタンスを使う必要がなく、簡単にコンテナをリリース管理できるCI/CD環境が構築可能です。クラウドインフラ構成のCI/CDとあわせてコンテナのCI/CD環境を構築することが必須となります。

これら5つのポイントを反映したクラウド最適なアーキテクチャ例として図2を参照ください。

クラウド最適なアーキテクチャにすることによる追加のメリット

想定する業務アプリケーションをクラウド最適なアーキテクチャにする5つのポイントとそのメリットを説明してきました。それに加えて「3層Webアプリケーション」アーキテクチャと比べた追加のメリットについて説明します。

まずは、5つのポイントの副次効果として、システム構成に管理しなければいけないOSがなくなることにより、踏み台サーバやOSパッチ管理サーバ、ウイルス対策管理サーバが不要になることです。それに伴い、踏み台の認証やパッチ管理のネットワーク経路等の運用管理のセキュリティについても考慮点が大幅に減ります。

また、OSの構成が不要になるため、インフラ構成がすべてクラウドのIaCコードとコンテナのConfigで表現できるようになり、インフラに対する追加変更削除作業をGit経由に一元化できます。GitにあるインフラコードとConfigをレビューすればインフラ構成のレビューができるようになり、セキュリティの確保がしやすくなり、インフラ構成のホワイトボックス化にもつながります。

さらには、コスト高なサーバインスタンスがなくなり、運用管理系のソフトウェア・ライセンスも不要となり、インフラコストを大幅に下げることができます。

これらの効果については、「イミュータブルなインフラ運用」や「マネージドサービス、コンテナ、サーバレス」にも書きましたので参照ください。

ガバメントクラウドでのクラウド最適なアーキテクチャへ向けた取組み

今回想定したような業務アプリケーションをコスト効率よく実現するためには、従来のような重たいWebアプリケーションやRDBでインフラを構成するのではなく、上の5つのポイントで整理したようなクラウド最適なアーキテクチャが効果を発揮すると考えます。

また、他のタイプの業務アプリケーションであっても、同じポイントを考慮することで同様の高いコスト効率を実現できると考えます。

ガバメントクラウドとしては、こうしたポイントを抑えたアーキテクチャをより簡単に実現できるよう、サンプルとなるテンプレートを開発していくことを検討しています。あわせてテンプレートのガイドも用意していきますので、利用システムがそれらを活用してクラウド最適なアーキテクチャを実現していけるよう貢献していきたいと考えています。

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

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

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