6.1 モダンアプリケーション化

ガバメントクラウド利用組織は旧来のアーキテクチャを単純移行するに留まらず、マネージドサービスやコンテナ、サーバレス、マイクロサービスなどを活用してモダンアプリケーション化を検討すること。モダンアプリケーション化の検討において、SaaS利用は開発量の削減に繋がるため強く推奨される。ただし、SaaS利用が無条件に推奨されるわけではない。利用者数の段階的な増加が見込まれる場合等、運用段階でSaaS利用料が高額となるケースもあるため、ライフサイクルコストの観点から真にコスト削減効果が発現するかを慎重に評価する必要がある。例えば、SaaSと同様の機能をマネージドサービスで実現することが可能であれば、ライフサイクルコストの観点から両方式を比較して十分に評価すべきである。

移行パターンについて、ガバメントクラウドでは「図 6‑1 ガバメントクラウドへの移行パターン」を想定しており、このうちRebuildをモダンアプリケーションと考え、Replatformは２段階移行における第一段階としての一時的なものと考える。

また、ガバメントクラウドへの移行時にはR1(Replatform)、R2(Rebuild)ともに、従来型のPCに専用のクライアントソフトウェアをインストールするクライアント・サーバー方式はWebシステム（マイクロサービス型やフロントエンド・バックエンド分離型等）に変更することを原則とする。そのため、シンクライアント(以下、シンクラ)、Virtual Desktop Infrastructure(以下、VDI)、Desktop as a Service(以下、DaaS)は原則として使用せず、同技術を必要としないWeb接続のセキュリティ対策を実施することとする。特にガバメントクラウド上でのVDI構成やDaaSの利用は行わない。但し、R1(Replatform)、R2(Rebuild)共通として、以下については例外とする。

• ガバメントクラウド上でのシンクラ、VDI、DaaS利用における例外ケース(R1・R2共通)
  • 組織内の既存の標準端末がシンクラ、VDI、DaaSであり、標準端末からガバメントクラウド上の利用システムを使う場合。
  • モダン化が予定されているが、それまでの間にオンプレミスで構築したVDI環境等の継続が困難であり、ガバメントクラウド上のDaaSを暫定的に使用することが合理的とガバメントクラウド管理組織で評価される場合。
  • クライアント・サーバー方式等によるPC内のデータ保護が目的ではなく、サービス利用、サービス連携等の手段としてVDI、DaaSの利用がCSPから推奨されており、他に技術的な選択肢がない場合。

図 6‑1 ガバメントクラウドへの移行パターン

6.1.1 バッチ処理のモダン化

クラウド移行により、システムリソースの制約からの解放やマネージドサービスの活用によって、以下の効果が期待できるため、従来のバッチ処理の在り方を再考すること。

• コスト削減
  • クラウドではオンデマンドでのリソース確保が可能となり、バッチ処理用のシステムリソースを常時確保する必要がなくなるため、コスト削減が可能
  • 高額なバッチ処理管理用のミドルウェアからクラウドのマネージドサービスに変更することでコスト削減が可能
• サービス提供価値の向上
  • システムリソース制約の解放やイベントドリブン型への変更を通じて、バッチ処理タイミングの見直しを行うことにより、利用者や関連システムへの情報連携、情報提供の間隔を短縮することが可能となり、サービス提供価値を向上することが可能
• 作業工数の削減
  • バッチ処理のタイミングに応じた運用業務を見直すことで、通常業務時間外の運用の削減が可能
  • 各種マネージドサービスを活用し、自動化を推進することで作業工数を削減することが可能

利用組織はクラウド移行による制限の解放（ストレージ容量、物理サーバ、ミドルウェアの機能、外部システム連携など）の観点でバッチ処理の在り方を見直し、クラウドに最適化されたバッチ処理を検討すること。

図 6‑2 バッチ処理の見直しとクラウド最適化

6.1.2 システム間連携のモダン化

クラウドネイティブ化が進む中で、複数のシステムを連携し、迅速に業務処理を遂行することが求められるケースが少なくない。そこで、データ/処理/アプリケーションの連携を考慮しつつシステムの統合や連携を図る必要性がある。システム間連携を行うことで業務スピードの向上、業務正確性の向上、データ統合による全容の可視化、データ管理のコストの削減といったメリットを期待できる。従来の基本的なシステム連携のパターンとしては、ファイル転送、ディスク共有、データベース共有、RPCやWebサービスなどのアプリケーション連携、メッセージングなどであるが、これらの連携方法のアーキテクチャは互いのシステムの依存関係が強く密結合しているケースが多く、1つのシステムの障害や変更の影響が全体に及びやすい。そのため比較的規模の小さいシステム間の連携に向いている。一方でガバメントクラウドにおいてはモダン化の観点からAPI連携の使用を推奨する。

6.1.3 運用監視のマネージドサービス化

モダン化の第一段階として、運用監視のマネージドサービス化は必須となる。まずは、運用監視においては、ログベースアラートや通知設定で運用監視を自動化し、ジョブ管理においては、CSPから提供されるマネージドサービスの利用を検討すること。

なお、時間がなく改修費用を賄えない場合等（ただし、次期更改時のマネージド化は必須）については、少なくとも、監視やログ収集、バックアップといった運用監視はマネージドサービスを利用した上で、ジョブ管理においては、AWSであればEC2を利用したジョブ管理サーバを構築することは可能である。この場合もジョブ管理以外の監視はマネージドサービスを活用すること。

6.1.4 移行パターンR2でのアーキテクチャ見直し

移行パターンR2（Rebuild）ではアプリケーションを変更しクラウドサービスをフル活用したアーキテクチャとして、2つの基本形と例外形を定義しており、それぞれのアーキテクチャにおける検討事項を示す。
なお、移行パターンR2におけるコンピュートサービスはサーバレス、コンテナを用いることを前提としている。
加えて、このR2のアーキテクチャを採った場合でも、クラウドの柔軟性を活かし、定期的にシステムのスコープ見直しや技術進歩に伴う改修、BPR等を行い、システムの統廃合やSaaS・共通機能の利用を検討すること。

（１） 基本形1（マイクロサービスアーキテクチャ）

マイクロサービスとは、対象となるアプリケーションをコンポーネント分割して開発を行うアプローチやアーキテクチャを指し、システムをマイクロサービスアーキテクチャへ移行することによって以下のような利点が得られる。

表 6-1 マイクロサービスアーキテクチャの利点

従来システムアーキテクチャではリリースに係る調整コストがシステムメンテナンスに係る人件費の増加要因のひとつであったが、マイクロサービスアーキテクチャを採用することにより、コンポーネントごとのチーム組織やデプロイとなるためリリースに係る調整コストの低減も期待できる。

• マイクロサービスアーキテクチャの基準
  システム企画を進めるうえで、マイクロサービスアーキテクチャであるかどうかについて一定の仮定を置き検討することが必要と想定される。そのため、便宜のため、以下に基準を示す。

表 6-2 マイクロサービスアーキテクチャの基準

補足説明:
上記基準2～5のうちチーム体制やシステム要件などの観点とのトレードオフで実現が困難がある場合、基本形1で明確化する構成図上のコンポーネントにて下記の点を明らかにし、今後の見直しに向けて計画する必要がある。

• 具体的に達成できていない個所
• トレードオフの背景と内容
• どういった契機で見直し、どういった方向にしていくか

図 6‑3 マイクロサービスアーキテクチャ構成例と基準マッピング

（２） 基本形2（フロントエンド・バックエンド分離）

フロントエンド・バックエンド分離型Webシステムは、ユーザーインターフェース（フロントエンド）とデータ処理やサーバーサイドロジック（バックエンド）が明確に分離されているアーキテクチャのことを指し、分離することによって以下のような利点が得られる。

表 6-3 フロントエンド・バックエンド分離の利点

図 6‑4 フロントエンド・バックエンド分離構成例

また、複数の異なるシステムやサービスに対して共通機能や蓄積データを提供するシステム（一般的にAPI連携基盤、認証基盤、データ連携基盤、分析統計・データレイクシステムと称されるシステムを念頭に置く）は、必ずしもユーザーへ提供する業務機能や業務画面を有しているわけでなく、かつ必ずしもマイクロサービスアーキテクチャが相応しいとは限らない。
このようなシステムであっても、管理用の画面や機能などのフロントエンドがある場合においては、R2基本形1・2に沿った実装を行うこと。
管理用の画面や機能などのフロントエンドを全く有さず、かつ、マイクロサービスアーキテクチャが適さない場合においても、R2基本形2のバックエンド部分に準じた構成を行うこと。その際、バックエンドは適切な粒度まで機能分割をすること。

（３） 例外

R2例外は以下状態のシステムを念頭に置く。

• 統廃合やSaaS利用、共通機能の利用へ切り替えなどによって将来的に廃止となるシステム
• 将来のアプリケーション改修を経てR2基本形となるシステム

また、システム企画を進めるうえで、R2例外の「長期塩漬けシステム」や「今後の運用コストが極小のシステム」かどうかについては一定の仮定を置き検討することが必要と想定され、便宜のため以下に基準を示す。なお、政府情報システムを念頭に置いた記載となる。

表 6-4 R2例外 基準

6.2 データの可視化

ガバメントクラウド利用組織は利用システムの成功を判断するために、KPIの達成状況を計測・追跡するためのデータの可視化を検討すること。

利用システムとして成功しているかどうかの基準を数字で定義表現し、その数字を計測できるよう元となるデータを収集・加工・可視化を行う。たとえば、実際の利用者が増えることがそのシステムの成功とする場合、毎日の利用ユーザー数が増えていくことを数字で表現することを考え、その日ログインしたユニークユーザー数をアクセスログの収集・分析して算出し、グラフとして可視化する。毎日または週次の運用でこのグラフを確認し、必要に応じて改善策等を検討する。

日次のユニークユーザー数というKPIはデジタル庁にも共有し、デジタル庁としてもシステムごとのKPIの数値を収集し、ガバメントクラウド全体での統計的分析に利用する。KPI情報の共有方法については別途定義し、GCASの運用に伴い順次整備を進めていく。

図 6‑5 データの集約と閲覧

データの可視化はオンプレミスの常識に囚われずに以下のような観点で抜本的に見直すこと。

• サービス／アプリケーションとしてのKPIとコストを監視する
• 不必要なアラートを発砲しないため、インフラの監視は原則実施しない
  • サービス／アプリケーションとして監視する
• 1ヶ月遅れの状況を見ても意味がないため、Word/Excelで月次運用報告書を作らない
  • 準リアルタイムに状況を可視化するダッシュボードを用意する
• 運用監視要員の貼り付け（常駐）を前提としない
  • 手順化できるものは自動化できるため、すべての監視とその対応を人間不要の自動化する
• Word/Excelの月次報告書を成果物や納品物として定義しない
  • 報告する側と報告を受けるだけの側に役割を固定せず、ダッシュボードで一緒に監視していく
  • 監視項目や可視化は運用中つねに相談しながら見直していく
  • 報告書が不可欠の場合は、ダッシュボードを報告書として整理する

可視化したデータを運用監視に活用する際は表 6‑5のようなオンプレミスとスマートなクラウド利用の違いを意識して活用すること。

表 6-5 運用監視に関するオンプレミスとスマートなクラウド利用の違い

なお、データの可視化に関しては、各CSP利用ガイドの「定量的計測の実装方法」を参照のこと。

6.3 クラウドに適したディザスタリカバリ環境

クラウドのディザスタリカバリ（以下DRと称す）環境は、オンプレのような本番環境と同環境を用意する考え方と違い、データコピーの容易性、環境構築の俊敏性、リソースの柔軟性等、クラウドの特徴を活用し検討することに加え、DR環境のリージョンで利用できるサービスに不足がないことを確認しながら設計することが必要となる。また、関東圏全域といったリージョン全域にわたる大規模災害（以下大規模災害とする）への対策を想定するか否かもシステムアーキテクチャ、システム構成、及びコストに大きな影響を与えるために重要な要素となる。

ガバメントクラウドでは4つのDRパターンを定義しており、基本的にはこのパターンに従い、コスト効果の高いパターンを選択する。4つのDRパターンは、図6-6のとおり、

1. 大規模災害を想定しないが、コスト効果が高く冗長性を担保したマルチゾーンパターン
2. 大規模災害を想定し、データをクラウドの機能で遠隔保管することで発災時もデータを保護できコスト効果の高いバックアップパターン
3. コストはかかるものの災対リージョンでは縮小構成を保持しておき被災時には災対リージョンで稼働を続けるウォームスタンバイパターン
4. コストをかけてでも被災時にサービスを変わらず継続する必要のあるアクティブ-アクティブパターンである。

職員向けシステムや、一部領域や地域の国民向けサービスは、基本的にパターン(1)または(2)になり、広く国民向けサービスのうち、停止すると国民生活に影響のあるもののみ(3)または(4)を検討することになると想定する。

なお、各CSPにおける具体的な実装方式は、各CSPマニュアルを参照すること。

図 6‑6 DR環境の構成パターン

ただし、システムの複雑化と高コスト化の要因となるため、パブリッククラウドが全面的に利用不能となるレベルの災害を想定する場合を除き、オンプレミスを災害対策用に利用することは避けることとする。

6.4 クラウドに適したバックアップ

オンプレミスではアーカイブ、レプリケーション、世代管理などをバックアップソフトウェアやジョブ、運用で実現するケースが多かったが、クラウドではマネージドサービスを活用することで、バックアップに係る機能を容易に実現できるため、コスト削減（バックアップソフトウェアが不要になる、余分なストレージ容量が不要になるなど）や作業工数の削減が期待できる。

なおCSPが公表している耐久性などのSLAは、満たされなくても返金処理されるだけとなり、消失したデータが復旧する訳ではないため留意すること。

表 6-6 バックアップ要件毎の実現例

6.5 オンプレミス-クラウド間のハイブリッド構成

クラウドとオンプレミスを組み合わせてデータを処理・保存する利用形態（オンプレミス-クラウド間のハイブリッド構成）については、オンプレミスからクラウドへの移行期、データの多重バックアップ、ネットワーク遅延が許容できない場合を除き、システムの複雑化と高コスト化の要因となるため、その適用を避けることとする。ガバメントクラウドにおけるオンプレミス-クラウド間のハイブリッド構成の許容方針を表 6-7に示す。

表 6-7 ガバメントクラウドにおけるハイブリッド構成の許容方針

6.6 クラウド最適を実現するためのCSP選択の在り方

前節ではオンプレミスとクラウド間のハイブリッド構成について述べた。本節では、複数のCSP間での構成(マルチクラウド)について方針を示す。

6.6.1 マルチクラウド構成の基本方針

可用性や冗長性の確保を目的とした1つのシステムで複数のCSPを利用するマルチクラウド構成は、コスト増加や運用の複雑化を招くため推奨しない。真に必要な場合を除き、原則禁止とする。

6.6.2 マルチクラウドを許容するケース

一つのシステム内でも、特定用途においては異なるCSPの利用も一部想定される。例としては、データ分析やAIサービスの利用時に主たるCSP環境のサービスで要件を満たせない場合等が挙げられる。また、システムの一部としてのSaaSの活用は積極的に検討すること。

なお、異なるシステム間の連携において、データ連携や業務要件により、複数のCSPを利用することは問題ないものとする。

6.6.3 データ可搬性の確保

PJMOの判断にて将来的なCSPの変更の可能性を考慮する必要がある場合は、システムやデータの可搬性について考慮に入れておくことが望ましい。

CSPの変更を可能とする構成の検討においては、アプリケーションやシステムの可搬性に加え、データの可搬性の確保も必要である。逆に、アプリケーションやシステムだけを可搬にしても意味はないため、データの可搬性含めてトータルでの考慮を行う。CSPの変更は、数カ月から数年かけて行うことになることが想定されれるため、その前提での可搬性を検討する。

なお、本項における「データ」とは、アプリケーションが利用する業務データ（構造化データ、非構造化データ、設定情報、メタデータ等）を指す。経済合理性や事業戦略に応じた柔軟な対応を実現するため、以下の点を考慮すること。

• データの可搬性を確保した設計を行うこと
• 運用中においてもデータ可搬性を維持できる仕組みを整備すること
• SaaS利用時においても、契約終了やサービス変更に備え、データのエクスポートや移行手段を確保すること

前の章へ | 次の章へ