# 6 必須検討事項 ## 6.1 モダンアプリケーション化ガバメントクラウド利用組織は旧来のアーキテクチャを単純移行するに留まらず、マネージドサービスやコンテナ、サーバレス、マイクロサービスなどを活用してモダンアプリケーション化を検討すること。モダンアプリケーション化の検討において、SaaS利用は開発量の削減に繋がるため強く推奨される。ただし、SaaS利用が無条件に推奨されるわけではない。利用者数の段階的な増加が見込まれる場合等、運用段階でSaaS利用料が高額となるケースもあるため、ライフサイクルコストの観点から真にコスト削減効果が発現するかを慎重に評価する必要がある。例えば、SaaSと同様の機能をマネージドサービスで実現することが可能であれば、ライフサイクルコストの観点から両方式を比較して十分に評価すべきである。移行パターンについて、ガバメントクラウドでは「図 6‑1 ガバメントクラウドへの移行パターン」を想定しており、このうちRebuildをモダンアプリケーションと考え、Replatformは２段階移行における第一段階としての一時的なものと考える。また、ガバメントクラウドへの移行時にはR1(Replatform)、R2(Rebuild)ともに、シンクラ、VDI、DaaSは原則として使用しないものとする。特にガバメントクラウド上でのVDI構成やDaaSの利用は行わない。シンクラ、VDI、DaaSを必要としないセキュリティ対策を行い、クラサバ方式やクライアント上のアプリやデータに依存する方式はWebシステム（フロントエンド・バックエンド分離型）に変更することを前提とする。但し、以下については例外とする。＜例外１＞組織内の既存の標準端末がシンクラ、VDI、DaaSであり、標準端末からガバメントクラウド上の利用システムを使う場合。＜例外２＞モダン化されることが予定されているが、それまでの間にオンプレミスで構築したVDI環境等の継続が困難であり、ガバメントクラウド上のDaaSを暫定的に使用することが合理的とガバメントクラウド管理組織で評価される場合。＜例外３＞クラサバ等によるPC内のデータ保護が目的ではなく、サービス利用、サービス連携等の手段としてVDI、DaaSの利用がCSPから推奨されており、他に技術的な選択肢がない場合。 ![図 6‑1 ガバメントクラウドへの移行パターン](/images/general_overview-explanation-chapter-06-01.png) **図 6‑1 ガバメントクラウドへの移行パターン** ### 6.1.1 バッチ処理のモダン化クラウド移行により、システムリソースの制約からの解放やマネージドサービスの活用によって、以下の効果が期待できるため、従来のバッチ処理の在り方を再考すること。 - コスト削減 - クラウドではオンデマンドでのリソース確保が可能となり、バッチ処理用のシステムリソースを常時確保する必要がなくなるため、コスト削減が可能 - 高額なバッチ処理管理用のミドルウェアからクラウドのマネージドサービスに変更することでコスト削減が可能 - サービス提供価値の向上 - システムリソース制約の解放やイベントドリブン型への変更を通じて、バッチ処理タイミングの見直しを行うことにより、利用者や関連システムへの情報連携、情報提供の間隔を短縮することが可能となり、サービス提供価値を向上することが可能 - 作業工数の削減 - バッチ処理のタイミングに応じた運用業務を見直すことで、通常業務時間外の運用の削減が可能 - 各種マネージドサービスを活用し、自動化を推進することで作業工数を削減することが可能利用組織はクラウド移行による制限の解放（ストレージ容量、物理サーバ、ミドルウェアの機能、外部システム連携など）の観点でバッチ処理の在り方を見直し、クラウドに最適化されたバッチ処理を検討すること。 ![図 6‑2 バッチ処理の見直しとクラウド最適化](/images/general_overview-explanation-chapter-06-02.png) **図 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（マイクロサービスアーキテクチャ）マイクロサービスとは、対象となるアプリケーションをコンポーネント分割して開発を行うアプローチやアーキテクチャを指し、システムをマイクロサービスアーキテクチャへ移行することによって以下のような利点が得られる。 |項目|説明| |---|---| |高い変更容易性|他のコンポーネントとの独立性が担保されたマイクロサービスアーキテクチャは、CI/CDとの親和性が高く、新機能の
リリースやロールバックが容易となる。| |開発サイクルの改善|マイクロサービスアーキテクチャでは、コンポーネントの分割単位で小規模のチームを組成することが望ましく、これに
よりチームメンバのサービスへの理解向上やきめ細かな権限付与を実現し、より自発性、俊敏性が高い開発サイクルへ
促すことが可能となる。| |高い耐障害性|特定コンポーネントに障害が発生しても、他のコンポーネントとの独立性によりアプリケーション全体がダウンすること
を回避できる。| |柔軟なスケール|アプリケーション全体をスケーリングさせず、高負荷状態のコンポーネントのみを迅速にスケールアップ・スケールアウト
させることができ、突発的な需要増へも対応が可能となる。| 従来システムアーキテクチャではリリースに係る調整コストがシステムメンテナンスに係る人件費の増加要因のひとつであったが、マイクロサービスアーキテクチャを採用することにより、コンポーネントごとのチーム組織やデプロイとなるためリリースに係る調整コストの低減も期待できる。 - マイクロサービスアーキテクチャの基準システム企画を進めるうえで、マイクロサービスアーキテクチャであるかどうかについて一定の仮定を置き検討することが必要と想定される。そのため、便宜のため、以下に基準を示す。
![図 6‑3 マイクロサービスアーキテクチャ基準](/images/general_overview-explanation-chapter-06-03.png) ![図 6‑3 マイクロサービスアーキテクチャ構成例](/images/general_overview-explanation-chapter-06-04.png) **図 6‑3 マイクロサービスアーキテクチャ構成例と基準マッピング**
（２）基本形2（フロントエンド・バックエンド分離）フロントエンド・バックエンド分離型Webシステムは、ユーザーインターフェース（フロントエンド）とデータ処理やサーバーサイドロジック（バックエンド）が明確に分離されているアーキテクチャのことを指し、分離することによって以下のような利点が得られる。 |項目|説明（「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」再掲）| |---|---| |高い再利用性|これまで画面生成に埋め込んでいた同じコードの繰り返し再利用による無駄（開発規模の肥大化）を解消でき、開発
コストを削減できる。| |開発規模の適正化|利用者体験（ユーザーエクスペリエンス）を踏まえた全体アーキテクチャ検討の後に、UX 設計をワイヤーフレーム
（画面レイアウト）まで具体化したフロントエンドを作成することで、真に使いやすいシステムにできる。
使いやすいシステムは多階層の大規模な画面構成とならないため、開発規模の適正化（開発コスト削減）にも寄与する。| |高い変更容易性|フロントエンドとバックエンドを API によって独立させ、疎結合にすることで変更に強いアーキテクチャとなる。
画面表示の修正はフロントエンドのみの修正、業務処理の修正はバックエンドのみの修正となり、将来の改修時の改修
対象が限定、極小化され、保守費用が削減される。| |通信量やサーバ負荷
の軽減|分離型にすると、バックエンドではインタフェースが API のみとなるのでアーキテクチャがシンプルになり、画面処理
もなくなるのでセッション情報の維持なども減る。また、これまでサーバ側で処理していたレンダリング（画面生成）
をクライアント側で行うので、サーバ（クラウド）側に必要なコンピュートリソースも少なくなってコスト削減につながる。
更には、クライアントとサーバ（クラウド）間の通信も最小化され処理の高速化にも寄与する。| ![図 6‑4 フロントエンド・バックエンド分離構成例](/images/general_overview-explanation-chapter-06-05.png) **図 6‑4 フロントエンド・バックエンド分離構成例** また、複数の異なるシステムやサービスに対して共通機能や蓄積データを提供するシステム（一般的にAPI連携基盤、認証基盤、データ連携基盤、分析統計・データレイクシステムと称されるシステムを念頭に置く）は、必ずしもユーザーへ提供する業務機能や業務画面を有しているわけでなく、かつ必ずしもマイクロサービスアーキテクチャが相応しいとは限らない。このようなシステムであっても、管理用の画面や機能などのフロントエンドがある場合においては、R2基本形1・2に沿った実装を行うこと。管理用の画面や機能などのフロントエンドを全く有さず、かつ、マイクロサービスアーキテクチャが適さない場合においても、R2基本形2のバックエンド部分に準じた構成を行うこと。その際、バックエンドは適切な粒度まで機能分割をすること。
（３）例外 R2例外1は以下状態のシステムを念頭に置く。 - 統廃合やSaaS利用、共通機能の利用へ切り替えなどによって将来的に廃止となるシステム - 将来のアプリケーション改修を経てR2基本形となるシステムまた、システム企画を進めるうえで、R2例外1の「長期塩漬けシステム」や「今後の運用コストが極小のシステム」かどうかについては一定の仮定を置き検討することが必要と想定され、便宜のため以下に基準を示す。なお、政府情報システムを念頭に置いた記載となる。 ![図 6‑5 R2例外1 基準](/images/general_overview-explanation-chapter-06-06.png) **図 6‑5 R2例外1 基準** ## 6.2 データの可視化ガバメントクラウド利用組織は利用システムの成功を判断するために、KPIの達成状況を計測・追跡するためのデータの可視化を検討すること。利用システムとして成功しているかどうかの基準を数字で定義表現し、その数字を計測できるよう元となるデータを収集・加工・可視化を行う。たとえば、実際の利用者が増えることがそのシステムの成功とする場合、毎日の利用ユーザー数が増えていくことを数字で表現することを考え、その日ログインしたユニークユーザー数をアクセスログの収集・分析して算出し、グラフとして可視化する。毎日もしくは週次の運用でこのグラフを確認し、必要に応じて改善策等を検討する。日次のユニークユーザー数というKPIはデジタル庁にも共有し、デジタル庁としてもシステムごとのKPIの数値を収集し、ガバメントクラウド全体での統計的分析に利用する。KPI情報の共有方法については別途定義し、GCASの運用に伴い順次整備を進めていく。 ![図 6‑6 データの集約と閲覧](/images/general_overview-explanation-chapter-06-07.png) **図 6‑6 データの集約と閲覧** データの可視化はオンプレミスの常識に囚われずに以下のような観点で抜本的に見直すこと。 - サービス／アプリケーションとしてのKPIとコストを監視する - 不必要なアラートを発砲しないため、インフラの監視は原則実施しない - サービス／アプリケーションとして監視する - 1ヶ月遅れの状況を見ても意味がないため、Word/Excelで月次運用報告書を作らない - 準リアルタイムに状況を可視化するダッシュボードを用意する - 運用監視要員の貼り付け（常駐）を前提としない - 手順化できるものは自動化できるため、すべての監視とその対応を人間不要の自動化する - Word/Excelの月次報告書を成果物や納品物として定義しない - 報告する側と報告を受けるだけの側に役割を固定せず、ダッシュボードで一緒に監視していく - 監視項目や可視化は運用中つねに相談しながら見直していく - 報告書が不可欠の場合は、ダッシュボードを報告書として整理する可視化したデータを運用監視に活用する際は表 6‑1のようなオンプレミスとスマートなクラウド利用の違いを意識して活用すること。 **表 6‑1 運用監視に関するオンプレミスとスマートなクラウド利用の違い** | 異なる点 | 運用監視への影響 | 理由 | オンプレ的監視を維持することによる悪影響 | | ---------- | ---------- | ---------- | ---------- | | クラウドではリソースを
即時（秒〜分）に用意できる | 中長期的なリソース監視は不要
→サーバごとのCPU使用率やディスク
　使用率などの月次運用報告書は不要 | 3ヶ月前や半年前にリソース不足傾向を把握
しなくても、不足しそうになったら調達や搬入
設置なしで即座にリソース追加変更可能
適切なマネージドサービスを使えば、CPUや
ストレージ容量は無限に使える
（正確には無限ではないが、基本的に意識する
必要なし） | CPU 100%はむしろ有効活用している証拠
中長期的なリソース監視報告をやり始めると、逆に、
CPUスカスカでリソース縮小してコスト削減すべきもの
を見逃す
CPUスカスカこそ監視すべきだが、月次報告ではなく、
クラウドサービスとして空きリソースを発見しアラート
する機能があるのでこれを使うべき | | クラウドでは、インフラ構成の
追加変更は自動化できる | リソース監視アラートは必須ではない
→アラート上げてもよいが、それよりも
　対応の自動化が重要 | リソース不足を検知したらリソースの追加を
自動でできるため、人手を介する必要がなく
人がリアルタイムにリソース不足を知る必要
がない
リソース追加や削減イベントの発生だけ事後
的に把握すれば負荷状況などわかるため有用
（リアルタイム監視ではない） | リソース監視アラートをあげると、それを見張る要員が
必要になり、対応の手順等を用意していくことになり、
運用費用増加の原因になる | | クラウドのマネージドサービス
では、インフラが落ちたか意識
する必要がない | インフラ単体での障害報告や月次報告
でのインフラ障害状況報告は不要
→サービス／アプリケーションとして
　利用できない状況にならないことが
　重要で、インフラ単体の障害の監視
　は意味がない | インフラ単体で障害が起きても自動で切替や
復旧するよう構成し、サービス／アプリケー
ションとして利用できない状況にしないこと
が重要
マネージドサービスを使えば、インフラの障害
は見えない | インフラ障害報告を月次報告書として出すと、1ヶ月前
の障害の調査や整理に時間使い、大事な未来の対応に
時間を割けない | | クラウドではインフラ稼働データ
は自動で集まる | 監視システム構築は不要
→データは自動で集まるので、網羅的
　なリソース監視一覧の作成は不要で、
　どういうデータをどう見せたいかに
　頭を使う | クラウドでは、監視サービスが標準で稼働して
おり、かつ他サービスと最初から連携されて
おり、設定なし、若しくは簡単な設定でCPU
使用率等稼働データが収集保管される
監視設計は大きく変わり、監視一覧の作成で
はなく、何をどう見せたいかから設計する | 監視システム構築費用が無駄
監視設計も大きく変わるため、クラウドに適した監視
設計をしないと、こちらも工数が無駄になる | なお、データの可視化に関しては、定量的計測サンプルテンプレートの提供を予定している。 ## 6.3 クラウドに適したディザスタリカバリ環境クラウドのディザスタリカバリ（以下DRと称す）環境は、オンプレのような本番環境と同環境を用意する考え方と違い、データコピーの容易性、環境構築の俊敏性、リソースの柔軟性等、クラウドの特徴を活用し検討することに加え、DR環境のリージョンで利用できるサービスに不足がないことを確認しながら設計することが必要となる。また、関東圏全域といったリージョン全域にわたる⼤規模災害（以下⼤規模災害とする）への対策を想定するか否かもシステムアーキテクチャ、システム構成、及びコストに大きな影響を与えるために重要な要素となる。ガバメントクラウドでは4つのDRパターンを定義しており、基本的にはこのパターンに従い、コスト効果の高いパターンを選択する。4つのDRパターンは、図6-7のとおり、・(1)⼤規模災害を想定しないが、コスト効果が高く冗長性を担保したマルチゾーンパターン・(2)⼤規模災害を想定し、データをクラウドの機能で遠隔保管することで発災時もデータを保護できコスト効果の高いバックアップパターン・(3)コストはかかるものの災対リージョンでは縮小構成を保持しておき被災時には災対リージョンで稼働を続けるウォームスタンバイパターン・(4)コストをかけてでも被災時にサービスを変わらず継続する必要のあるアクティブ-アクティブパターンである。職員向けシステムや、一部領域や地域の国民向けサービスは、基本的にパターン(1)か(2)になり、広く国民向けサービスのうち、停止すると国民生活に影響のあるもののみ(3)か(4)を検討することになると想定する。なお、各CSPにおける具体的な実装方式は、各CPSマニュアルを参照すること。 ![図 6‑7 DR環境の構成パターン](/images/general_overview-explanation-chapter-06-08.png) **図 6‑7 DR環境の構成パターン** ただし、システムの複雑化と高コスト化の要因となるため、パブリッククラウドが全面的に利用不能となるレベルの災害を想定する場合を除き、オンプレミスを災害対策用に利用することは避けることとする。 ## 6.4 クラウドに適したバックアップオンプレミスではアーカイブ、レプリケーション、世代管理などをバックアップソフトウェアやジョブ、運用で実現するケースが多かったが、クラウドではマネージドサービスを活用することで、バックアップに係る機能を容易に実現できるため、コスト削減（バックアップソフトウェアが不要になる、余分なストレージ容量が不要になるなど）や作業工数の削減が期待できる。なおCSPが公表している耐久性などのSLAは、満たされなくても返金処理されるだけとなり、消失したデータが復旧する訳ではないため留意すること。 ![図 6‑8 バックアップ要件毎の実現例](/images/general_overview-explanation-chapter-06-09.png) **図 6‑8 バックアップ要件毎の実現例** ## 6.5 ハイブリッド構成についてクラウドとオンプレミスを組み合わせてデータを処理・保存する利用形態（ハイブリッド構成）については、オンプレミスからクラウドへの移行期、データの多重バックアップ、ネットワーク遅延が許容できない場合を除き、システムの複雑化と高コスト化の要因となるため、その適用を避けることとする。各構成の詳細を①～③に示す。
① オンプレミスからクラウドへの移行期未移行部分がオンプレミス、移行済み部分はクラウドとなる、段階的にガバメントクラウドへ移行するような構成を指す。 ② データの多重バックアップガバメントクラウド上のデータをオンプレミスへバックアップするような構成を指す。 ③ ネットワーク遅延が許容できない場合ネットワーク遅延が許容されない部分はオンプレミス、それ以外の部分はガバメントクラウドを利用するような構成を指す。
さらに、主たる環境として利用するIaaS/PaaSのCSPを複数とするマルチクラウドはコストが増大することが多いため、真に必要性がある場合を除いては避けることとする。上記を踏まえ、ガバメントクラウドにおけるハイブリッド構成の許容方針を図6-9に示す。 ![図 6‑9 ガバメントクラウドにおけるハイブリッド構成の許容方針](/images/general_overview-explanation-chapter-06-10.png) **図 6‑9 ガバメントクラウドにおけるハイブリッド構成の許容方針** [前の章へ](/general/overview-explanation-chapter-05/) | [次の章へ](/general/overview-explanation-chapter-07/)

ガバメントクラウド概要解説_6 必須検討事項