はじめに

なぜモダン化が必要なのか

ガバメントクラウドは、「デジタルの活用により、一人ひとりのニーズに合ったサービスを選ぶことができ、多様な幸せが実現できる社会」の実現に貢献するため、データの安全な連携を可能とし、ニーズに合わせて柔軟に対応できる情報システムを実現する共通基盤を目指している。

情報システムのモダン化は、外部環境の変化に合わせて情報システムを変更していくプロセスである。例えば、手続き処理が紙ベースからシステム化されることに伴い、技術的には大規模大容量のデータを取り扱えるようになった。さらに、ネットワークやプロトコルがコモディティ化し、疎結合な仕組みによるデータ連携が一般的になっている。

上記を実現するためには、新しい技術を活用し、システムの価値を高める必要がある。一方、ガバメントクラウド上で稼働する公共情報システムには安定性も求められる。そのため、ガバメントクラウドでは最先端の実験的な技術ではなく、ある程度一般化した新しい技術を活用する方針を採用しており、これを「モダン化」と呼んでいる。
情報システムの開発運用の安定化およびコスト最適化の観点から、レガシー技術からモダン技術を採用して情報システムを変更していくことが重要である。

ガバメントクラウドにおけるモダン化の定義

2025年現在、上記を実現するモダン技術やこれらを活用したモダンな公共情報システム運用の実践をガバメントクラウドにおけるモダン化の定義とし、以降に詳細を記載する。
なお、この定義以外のモダン化のあり方についても、今後検討していく。

1. APIベースのシステム構成
2. ステートレスなアーキテクチャ
3. マネージドサービスの活用
4. 運用のコード化、自動化
5. サービスレベルの定義、計測

また、ガバメントクラウドへの移行パターンとしてR1(Replatform)とR2(Rebuild)がある。R1(Replatform)においては「3. マネージドサービスの活用」を原則求めており、R2(Rebuild)においては、1-5の実現を求めている。

ただし、ガバメントクラウドへ移行する際、すべての項目を完全に満たす必要があるわけではない。移行の考え方や例外については「01_ガバメントクラウド概要解説_6 必須検討事項open_in_newOpens in new tab」を参照すること。

1. APIベースのシステム構成

あるサービスを構成するシステム間を疎結合化して、APIベースでデータ連携する。
現在、RESTful APIやGraphQL、gRPCなどの疎結合なシステム間連携を実現できる技術仕様があり、これらによってAPIベースの情報システムを構成することで、手続きや組織をまたがったデータ連携が実現しやすくなる。

APIによるデータ連携は、バッチ的な連携と比べて以下のメリットがある。

• 連携するデータが常に最新になるので、ユーザ体験が向上する。
• 順次処理となるのでエラーハンドリングが容易であり、障害インパクトも小さくできるため、可用性を高めることができる。

さらに、モダンなアーキテクチャとするためには以下に留意する。

非同期処理とする

• 複数のシステムが互いの処理完了を待たずに、それぞれが独立して処理を進める。
• あるシステムの処理に時間がかかる場合、処理の依頼が完了した時点でAPI処理を一度終了させ、後でポーリングして結果を取得する。
  • または、API提供側から完了通知を送信する。
• APIフロント側は、API呼び出しのエラーを適切なメッセージにしてユーザに示し、リトライ後、次の処理に繋げるロジック（サーキットブレーカー）を実装する。
• APIバック側で処理に時間がかかる場合は、APIで受け付けたデータを永続化し、イベントドリブンに順次処理して結果を永続化する。

上記のようにAPI利用時は非同期処理とすることで、フロントエンドとバックエンド双方の非機能要件（性能、信頼性など）を別々に考えればよくなり、ユーザー体験とコスト最適化を両立できる。

APIの定義を利用システムに公開する

• APIの使い方やオプションの意味、レスポンス内容やデータの意味を明確に定義し、利用システム側に提示する。
• 既存API定義の変更や削除は基本的には避ける。オプションの追加やレスポンスデータ項目の追加に留めるようにし、呼び出し元の処理の影響を最小限に抑える。

APIで取り扱うデータ管理の責任範囲を明確にする

• API提供側は、システムの業務領域で取り扱う範囲で管理の責任を負う。
• 利用システム側は、APIで取得したデータを利用しやすい形式に自身で変換する。
• 利用システム側でのデータ活用（管理）は利用者自身が負う。

データの定義を明示する

• API提供側は、データの「名称」「フォーマット」「意味」「目的」「更新頻度」などを定義し、利用システム側に提示する。

データ管理の責任範囲を明確にし、定義を明示することで、APIの提供側/利用側それぞれが独立して目的に合った形式でデータを管理、利用できる。

フロントエンド・バックエンドアーキテクチャ

• フロントエンドはユーザーインターフェイス、ユーザー体験に責任を持ち、バックエンドはビジネスロジックやデータ管理に責任を持つ。
• フロントエンドとバックエンドはAPIを介してデータをやり取りする。
• フロントエンドはAPIで取得したデータをユーザー体験に合わせて適宜加工する。

フロントエンドとバックエンドを分離することで、フロント側だけで独立してユーザー体験に合わせて、柔軟かつ頻繁に更新でき、開発速度が向上する。

バッチ処理をイベントドリブン化する

オンプレミスで多く用いられている夜間バッチは、夜間にバッチ処理が止まると翌日の業務に支障が出るため、年に数回程度の障害のためにオペレーターが監視し続ける必要がある。また、バッチ処理はまとめて処理するため、バッチアプリケーション内のジョブ間でステータス情報を引き継いだり、順序性を維持する必要がある。そのため、システムに高い可用性が必要になり、障害時の復旧の複雑性を増している。これによってコストと運用負荷が大きくなる。

• オンプレミスでは、バッチ処理はコンピューティングリソースの制約によって処理量が減る夜間に多く実施されてきた。
  • クラウドはリソースを必要な時に必要なだけ追加できるので、夜間にバッチ処理をする必要性がない。
• イベントドリブン処理は、APIでリクエストを受け付けた際に、受け付けたというイベントをトリガーにバックのアプリケーションがリクエストを読み出して処理し、結果を永続化すると同時に次のイベントを起こして後続の処理に通知する。
  • イベントごとに一件ずつ処理するため、リトライや再処理がシンプルで実現しやすい。
  • ステートによって結果が変わることなくインプットに対してアウトプットが出力され、かつステート情報を前後の処理で共有しないので、疎結合な状態となる。

ある時点のデータで一括処理が必要など、バッチ処理を完全になくすことはできないが、イベントドリブンアーキテクチャを実現することで運用負荷を下げると同時に、常に最新データでサービスを提供できるので、ユーザー体験の向上も見込める。

2. ステートレスなアーキテクチャ

ステートレスとは、状態（ステート）を保持しない（レス）ことである。ステートレスなアーキテクチャによって、同じシステムを構成するどのサーバで処理しても同じ結果を返すことができる。サーバ間でセッション情報や構成情報を共有する必要がないため、ステート”フル”なアーキテクチャと比べて以下の特長がある。

• 障害が起きてもクライアントの情報が失われないので、信頼性が向上する。
• 負荷に応じてサーバ台数を柔軟に増減することが容易であり、コスト削減できる。

（参考）ステートフルとステートレス

• ステートフル
  • 複数のAPIリクエスト間に関連や順序を持たせるためにクライアントとサーバ間でセッション情報などを保持する。
  • 負荷分散装置で振り分け先を固定したり、共有ストレージを使って複数サーバで構成情報を共有するアーキテクチャ
• ステートレス
  • APIを呼び出す順序や場所に依存関係がなく、他のリクエストとは独立した応答がなされるため、サーバ間でセッション情報などを共有しなくても良い。
  • どのサーバで処理しても同じ結果が得られ、サーバ間が疎結合なアーキテクチャ

  	ステートフル	ステートレス
  クライアント情報	記憶する	記憶しない
  スケーラビリティ	各サーバにセッション情報やクライアント情報を 記憶する仕組みが必要なので、スケールしにくい	各サーバにセッション情報やクライアント情報を記憶する 仕組みが不要なので、スケールしやすい
  可用性	サーバがダウンするとセッション情報が失われるため、 ダウンさせない可用性が必要	セッション情報がないため、サーバがダウンしてもクライアントから リクエストを再送すればよく、影響を局所化できる
  コスト	サーバの冗長構成やクラスタソフト、 復旧のための運用など高コストになる	障害時の影響を局所化できるので、 ステートフルと同等の冗長構成は不要。そのため低コストになる

コンテナを活用する

コンテナはソフトウェアのバイナリだけでなく、ライブラリなどの実行環境を含めてパッケージングする技術である。環境に固有な情報はコンテナイメージにパッケージングするのではなく、コンテナ起動時に環境変数としてコンテナに渡すことで、コンテナ自体はステートレスなアーキテクチャとする。

コンテナを利用する際は、以下を考慮することでコンテナの価値を活かすことができる。

• ステートレスにする
  • 上記のようにアプリケーションなどの状態を表す情報や各コンテナごとの固有な情報をコンテナイメージには含めない。セッション情報などが必要なアプリケーションの場合は、コンテナ外部に保存するようにし、コンテナ自体はステートレスなアーキテクチャとする
• イミュータブルにする
  • コンテナは不変（イミュータブル）であり、アプリケーションのバージョンアップやパッチ適用などが必要な場合は、コンテナイメージを再ビルドしてコンテナを作り直す。

コンテナをステートレスでイミュータブルにすることによって、コンテナは高い可搬性（ポータビリティ）を有する。これによってCI/CDによるアプリケーションを含めたコンテナデプロイの自動化やリクエストの変動によるコンテナの追加削除が容易となる。

オートスケールを活用する

オートスケールはアプリケーションを稼働させるインスタンス/コンテナを負荷に応じて自動的に増減（スケールアウト、イン）させる技術である。インスタンス/コンテナをステートレスなアーキテクチャにすることで、稼働済みのインスタンス/コンテナとは独立して追加、削除することができる。

• インスタンスのオートスケール
  • クラウドの機能として、負荷や障害の監視結果および事前に設定したスケジュールに応じて自動でインスタンス数を増減させることができる。
  • オートスケールするためには、増えたインスタンスに監視や運用系含めて同じ構成を再現できたり、減らす際にインスタンスを削除しても全体として挙動が変わらないような疎結合でステートレスなアプリケーション構成が必要となる。
• コンテナのオートスケール
  • コンテナをdockerコマンドではなく、クラウドの機能またはマネージドのコンテナオーケストレーションツールで管理、運用する。コンテナオーケストレーションツールにはオートスケール機能があり、負荷に応じてコンテナを追加削除できる。
  • 何らかの原因でコンテナが停止した場合、オーケストレーションツールのセルフヒーリング機能で自動で回復させる。

オートスケールを活用することで、負荷に応じて拡張縮小が容易になるので、運用負荷の低減、コストの最適化、可用性の向上などが期待できる。

3. マネージドサービスの活用

クラウドにはビルトインされたマネージドサービスが多く用意されている。仮想マシンにログインして監視サーバやデータベースなどを構築するのではなく、予め用意されたマネージドサービスを目的に応じて活用することで構築や運用が容易になる。
また多くのマネージドサービスは使用した分だけの課金（稼働時間、リクエスト数、データ量など）のため、リソース確保型のサービス（仮想マシン、ブロックボリュームなど）よりも一般的に低コストとなる。

作らない

監視機能・ログ管理機能・バックアップ機能・セキュリティ機能などの非機能要件に関わるものや、データベースはマネージドサービスで構築する。

監視機能をマネージドサービス化する

独自に監視サーバを立てたりせず、クラウドにビルトインされた監視サービスで監視する。監視結果の可視化も、クラウドが用意する監視ダッシュボード機能を利用する。

• より高度な監視の分析を行う場合も、クラウドの各種データ分析サービスに監視データを取り込むことで実現できる。

ログ管理機能をマネージドサービス化する

独自にログ管理サーバを立てたりせず、クラウドにビルトインされたログ管理サービスでログを収集管理する。収集したログの可視化も、クラウドが用意する監視ダッシュボード機能を利用する。

• より高度なログの分析を行う場合も、クラウドの各種データ分析サービスにログデータを取り込むことで実現できる。

バックアップ機能をマネージドサービス化する

独自にバックアップサーバを立てず、クラウドにビルトインされたバックアップ／スナップショット機能でデータベースやファイルをバックアップする。

• オブジェクトストレージは自動的に複数ゾーン間でデータをコピーするため、障害対応目的でのオブジェクトストレージ内のデータのバックアップは不要。
• ファイル単位での細かいバックアップ／リストア要件がある場合は、オブジェクトストレージのバージョニング機能で詳細なファイルバックアップ運用ができる。
• 災害対策としては、別リージョンへデータをコピーすることが有効。クラウドのリージョン間コピー機能を使用するか、スクリプトなどを使用し、定期的に別リージョンへデータコピーする。

セキュリティ機能をマネージドサービス化する

ファイアウォール、IDS(/IPS)、WAF、ウイルス対策管理、脆弱性管理等のセキュリティ機能は、クラウドにビルトインされた機能もしくはOSに標準で備わっている機能で対策する。合理的なリスク判断を通じて、過剰にならないような適切なセキュリティ対策が重要となる

• ネットワークのセキュリティ
  • クラウドは外部インターネットからの攻撃はクラウド自身が自動で防御している。利用者が管理しなければいけないのは、明示的に開けたポートに対してのみとなる。
  • インターネットからHTTPS通信しか許可していない場合は、クラウドのWAFサービスを利用する。
• ソフトウェアのパッチ管理
  • マネージドサービスは一般的にはOSの管理が不要となり、パッチはクラウド側で自動で適用されるので、常にセキュリティが維持され運用負荷も下がる。

データベースをマネージドサービス化する

クラウドは主要なRDBやNoSQL DBがマネージドサービスとして用意されており、これを利用する（Oracle DB、Microsoft SQL Server、MySQL、PostgreSQL、MongoDB、Cassandra等）。

• DBのマネージドサービスは、標準もしくは設定することで、冗長構成やバックアップ等のDB運用に必要な機能を構成できる。
• 既存環境から移行する場合、環境によっては、OS上で実行していた運用系プログラムをリモート化する等の運用系の一部変更を検討する。

共有ストレージをオブジェクトストレージ化する

アプリケーションサーバから使用する共有ストレージやファイルサーバは、NFSファイルサーバをそのままクラウドサービスに置き換えると、一般的には高価かつ密結合なシステムとなり、耐障害性が低くなる。そのため、共有ストレージをオブジェクトストレージに置き換え、APIベースで連携することで、疎結合かつ安価にできる。

• ステートレスなアーキテクチャでは、アプリケーションのステート情報や構成情報を持たないため、この目的での共有ストレージは不要となる。

インスタンスサイズを拡張、縮小する

クラウドの仮想マシンサービスやデータベースサービスはインスタンスや容量を拡張/縮小（スケールアップ、ダウン）することが容易であり、負荷に応じてサイズを変更することでコストの最適化とサイジングの簡素化ができる。

• 負荷状況に応じて自動的にサイズ変更できるサービスを採用することで、拡張、縮小の運用負荷を低減できる。
• 自動的にサイズ変更できないサービスは、再起動が必要となる。繁忙期があらかじめ予測できるサービスの場合は、自動（または手動）で再起動するようにする。
  • サービス間で依存関係がない疎結合なアプリケーションの場合、再起動しても他のサービスへの影響はない。

4. 運用のコード化、自動化

手作業はミスが多くなる。ミスを防ぐために手順書を作成し、ダブルチェックしながらコマンドなどを実行している場合もあるが、これだけではミスを完全になくすことはできない。
ユーザーに対して価値を提供し続けるためには可能な限り自動化し、障害が起きたら復旧するだけでなく、今後起きないよう改善・改修する必要がある。特に定型作業を自動化、無人化することがモダンなシステムに対して重要となり、コード化することで自動化、無人化が容易となる。

インフラ管理をIaC(Infrastructure as Code)化する

インフラの運用管理をクラウドのコンソールやコマンド操作ではなく、コード化しコードを実行することでインフラを構築、変更する。

• IaCとは、インフラの構成および変更をコードにより定義・管理する手法である。これをCI/CDパイプラインと連携させることで、各環境へのデプロイを自動化し、手動による操作や環境へのログインを不要にすることができる。
• IaCはクラウドのマネージドサービスを使用することで、すべてのインフラ機能を一元的にコードで表現できるようになる。ただし、データベースやストレージ等の永続データを保管するサービスについてはIaCによる管理から外す等の工夫が必要となる。

定型的な作業を自動化する

手作業による運用は運用コストに影響し、かつミスを起こすリスクがある。ステートレスなアーキテクチャおよびイベントドリブンなアーキテクチャにし、マネージドサービスを活用することで、コード化が容易となり、手作業をなくし自動化できる。

本番環境にログインしない

コード化、自動化することで、人が本番環境に直接アクセスすることを避け、全ての操作を自動化やツールを通じて間接的に運用する「Zero Touch Production」を実現できる。

• IaCとCI/CDパイプラインでインフラ構成管理を自動化することで、本番環境に人がログインし、本番環境の構成を手作業で変更することが不要となる。
• 本番環境に人がログインしなくなれば、セキュリティ上のリスクも大幅に軽減でき、本番環境をセキュアに作業するための踏み台サーバやそのログ取得等も不要になる。
• 本番環境への手作業がなくなると、システム監査を受ける際にも、管理ポイントが減って監査の対応がより容易になる。
• 万が一、本番環境が破壊的な状況になったときのための非常時ログインは残す必要がある。この非常時ログインだけを例外対応としてプロセス管理し、厳格に管理すれば、本番環境をセキュアに運用できる。

アプリケーションをリリースする際、適切なデプロイ戦略を選択する

アプリケーションをステートレスなアーキテクチャにし、コード化、自動化することで、アプリケーションをデプロイする際に、様々なデプロイ戦略（Rolling Update、Blue-Green Deploymentなど）を選択できる。

• Rolling Update、Blue-Green Deploymentなどを選択することで、サービスを無停止でアプリケーションをリリースできる。これによって新しいアプリケーションをユーザーにタイムリーに提供することができ、、ユーザー体型を向上させることができる。
  • ただし、無停止でリリースできるデプロイ戦略はコスト増となる場合もあるので、設定したサービスレベルの範囲で、サービスの停止を許容する判断も必要となる。
• 新しいアプリケーションにはバグがある場合がある。一定期間、新旧のバージョンを並行稼働させるデプロイ戦略（Blue-Green Deployment、Canary Releaseなど）を選択することで、バグの影響を最小化したり、ロールバックすることができる。

障害対応を自動化、リモート化する

繰り返し発生する手作業（Toil: トイル）を極力減らし、エンジニアがより作業に集中できるよう、障害対応を自動化、リモート化する。

• 障害発生時に人手を介さずに自動的に復旧する仕組み、機能を取り入れる。仮に障害があっても自動復旧するようにして、サービスレベルの範囲内であれば特別な対応はしない。
  • 死活監視と自動再起動
  • 自動フェイルオーバー
  • オートスケール
  • セルフヒーリング　など
• サービスレベルを下回る障害に備えて、２次対応をリモートで実施できる体制を構築する。
  • リモートアクセス環境の整備
  • チャットツールやビデオ会議システムの導入
  • 障害対応手順の整備、作成　など

5. サービスレベルの定義、計測

クラウドは構成の変更やインスタンスの追加、削除が容易なことから、オンプレミスと違ってサービスイン後も継続的に変えていくことがベストプラクティスになる。
モダンなシステムの運用は、サービスやシステムがユーザーに価値を提供し続けるための活動であり、その価値を継続して提供できるようプロアクティブに活動すべきものと認識を改める必要がある。そのためにはサービスやシステムの価値をKPIとして定量的に定義し、KPIに対するサービスレベルを定義する。

定義したKPIやサービスレベルに対して、その内容を計測し、継続的に振り返り、改善することが重要となる。

KPIやサービスレベルを定義し、計測する

• サービスやシステムの価値をユーザーに提供できていることをシステム的に定量的に表現できるものをKPIとして定義する。
  • KPIには稼働率やレスポンス、エラー率、登録ユーザー数などがあるが、そのサービスがどのような価値を提供するかによって異なる。
• サービスレベルは上記のKPIに対して、稼働率を99.5%など計測できる定量的な値を定義し、ダッシュボードで可視化、計測できるようにする。

継続的に振り返り、改善する

• モダンなシステムの運用では、サービスイン後も継続的にユーザに価値を提供するために、日々の振り返りと改善が重要となる。
• ダッシュボードで可視化したKPIやサービスレベル、セキュリティに関するメトリクスを日次や週次で確認し、メトリクス劣化やリスクを洗い出し、優先度をつけて改善する。
• 可視化は改善活動につながるものに絞り込み、監視項目が多くならないようにする。また、クラウドサービスのアドバイス機能を活用する。
• 定型的な月次報告書ではなく、ダッシュボードを使って常に最新の情報をステークホルダーが確認できるようにし、KPIやサービスレベル、改善対応、リスク対応を説明することが重要となる。

改訂履歴