前例なき制約を抱えた「ガバメントクラウド移行プロジェクト」始動

私は、官公庁案件を中心に、行政機関のガバメントクラウド（ガバクラ）導入を支援してきました。そのなかから今回ご紹介するのは、中央省庁の政府情報システムをガバクラへ移行するプロジェクトです。

このプロジェクトは、大容量データ移行に加え、「AWS Snowball利用不可」「システム間の直接のデータ移行不可」という二重の制約に直面した、前例のない試みでした。

私は、この移行プロジェクトに、プロジェクト管理支援として関与し、官側・ベンダー側双方に助言を行いながら、技術的制約などを整理しました。

ガバクラ環境では、デジタル庁が定める共通のセキュリティ要件に加え、各省庁が独自に設ける規則も遵守しなければなりません。

特に重要となるのが、扱う情報の「機密性区分」です。政府が扱う情報は、その重要度に応じて3つの区分にわけられます。

• 機密性1：インターネットで公開されている情報
• 機密性2：漏洩すると政府的なインシデントに発展しうる重要な情報
• 機密性3：漏洩が国家安全保障に影響のあるレベルの秘密情報

私が支援したシステムが扱っていたのは「機密性2」の情報。これは、「機密性3」の情報には至らないが慎重なとり扱いが求められるレベルです。

当然、インターネット経由でのデータ移行は許されず、セキュリティを担保した経路の確保が大前提となりました。

Snowballもシステム連携も封印。制約をどうのり越えるか。

大容量データを安全かつ効率的に移行する手段として、多くのエンジニアが真っ先に思い浮かべるのが「AWS Snowball」でしょう。

専用の物理デバイスにデータを格納し、輸送することで、ネットワーク帯域の制約を受けずに高速なデータ移行を実現するサービスです。

しかし、このプロジェクトでは、そのベストプラクティスが通用しませんでした。省庁側から「Snowballは使えない」という通達があったのです。

その理由は、省庁が独自に定めていた「サプライチェーンリスクマネジメント」という規則にありました。

サプライチェーンリスクマネジメントとは、製品やサービスが提供されるまでの一連の流れ（サプライチェーン）に潜むリスクを管理・統制する考え方です。

Snowballを利用する場合、デバイスにデータを格納した後、物理的にAWSのデータセンターまで輸送するプロセスが発生します。この輸送を担うのは、AWSから委託を受けたパートナー企業です。

つまり、元請けのAWSから二次受け、三次受けの輸送業者へと、複数の企業が連鎖するサプライチェーンが形成されます。

省庁側は、この連鎖が長くなるほど統制がむずかしくなり、情報漏洩のリスクが高まると判断しました。

当時、その省庁では物理デバイスを外部業者に委ねることへの理解が得られなかったのです。これが、Snowballが使えなかった最大の理由でした。

さらに、プロジェクトを複雑にしたのが公共システム特有の調達による制約です。今回は、移行元のオンプレミス環境を運用する事業者と、移行先のガバクラ環境を構築する事業者が異なっていました。

それぞれのシステムは完全にわけて管理されており、移行先の事業者が移行元のシステムに直接アクセスしてデータを抽出することは不可能でした。

これにより、移行元から移行先へデータを直接転送するというシンプルな構成がとれず、二つの断絶したシステムをいかにしてつなぐか、という新たな課題が生まれたのです。

物理輸送NG、システム間の直接移行NG。残されたのは「通信の工夫」だけ。

Snowballによる物理輸送が不可能である以上、残された選択肢はネットワーク経由での転送です。ただし、機密性2の情報を扱うため、インターネットは使えません。

そこで活路を見出したのが、デジタル庁が整備するGSS G-Netを経由した、省庁LANとガバクラをつなぐ専用の閉域網でした。

物理的なモノの移動がリスクなら、厳格に管理された通信経路でデータを送る。これが第一のブレークスルーでした。

次に、システム間の断絶という組織的な課題も解決する必要があります。

移行元の事業者が移行先のシステムにふれず、かつ移行先の事業者が移行元のシステムにふれないようにするには、両者の間に緩衝地帯を設けるしかありません。

そこで考案したのが、以下のステップを踏むアーキテクチャです。

• 移行元の運用事業者が、オンプレミス環境からデータを抽出する。
• 抽出したデータを、移行先の構築事業者が「中継サーバー」に一旦配置する。
• 移行先の構築事業者が、別途調達した「データ移行用端末」を使い、中継サーバーからデータを取得する。
• その移行用端末から、閉域網を経由してガバクラ上の移行先環境へデータを転送する。

これは、ベストプラクティスとはほど遠い、制約のなかでひねり出した苦肉の策です。しかし、このアーキテクチャによって、2つの制約を同時にのり越えるための道筋がみえてきました。

安全な経路の先に残る、「転送の信頼性」という落とし穴

移行経路は定まりました。しかし、ここで新たな懸念が浮上します。それは、「単純なファイル共有でデータを転送するだけで、本当に安全なのか？」という点です。

閉域網とはいえ、万が一の事態は想定しなければなりません。転送中のデータが破損する可能性、あるいは何らかの要因でデータが漏洩するリスクはゼロではありません。

特に、官公庁のプロジェクトでは、あらゆるリスクを想定し、その対策を論理的に説明する責任があります。このままでは、もっとも重要な「セキュリティの担保」が不十分だと考えました。

技術の“勘”を裏づける、定量的アプローチとは

どうすれば、この特殊な経路で、安全かつ効率的に20TBものデータを移行できるのか。そこで考えたのが、「AWS DataSync」の活用です。

DataSyncは、オンプレミスとAWS間のデータ転送を自動化・高速化するサービスです。

転送中のデータは自動的に暗号化され、データの整合性もチェックしてくれるため、セキュリティと信頼性に優れています。この機能こそ、我々が抱える課題の最適解だと思いました。

しかし、「よさそうだから」という理由だけで高価なサービスを採用することはできません。特に、官公庁のプロジェクトでは、あらゆる決定に客観的で論理的な根拠が求められます。

そこで私たちは、データ移行方法の選択肢を3つに絞り、リスクとコストに重みづけを行い、各選択肢を定量的にスコアリングするというアプローチをとりました。

例えば、「移行データ漏洩リスク」の項目では、暗号化機能がないネットワーク共有のスコアを高く（リスク大）、標準で暗号化されるDataSyncのスコアを低く（リスク小）設定します。

同様に、コストやほかのリスク項目も数値化し、それぞれの重要度に応じて重みづけをして総合点を算出しました。

その結果は、一目瞭然でした。総合スコアがもっとも低かった（＝リスクとコストのバランスがもっとも優れていた）のは、DataSyncだったのです。

比較結果を共有したところ、技術的な詳細がわからない関係者にも、なぜDataSyncが最適なのかが論理的に伝わり、最終的に満場一致で採用が決定しました。

DataSyncを現実解に落とし込む「実践的アーキテクチャ」

最終的な構成は、非常にシンプルです。中継サーバーに置かれた移行対象データに対し、データ移行用に用意した物理端末からDataSyncを使ってAWS Direct Connect経由で転送します。

ここで1つ、実践的な工夫を加えました。DataSyncエージェントは通常、仮想マシン上での稼働が推奨され、メモリ64GB以上といった要件があります。

しかし、今回は移行のためだけに高性能な仮想化基盤を用意するのは現実的ではありませんでした。

そこで、調達した物理端末（メモリ64GB）に直接DataSyncエージェントをインストールして稼働させるという、少しイレギュラーながらも現実的なソリューションを選択。

これにより、コストを抑えつつ、要件を満たすことに成功しました。

制約は、思考停止のいいわけにならない

ガバクラ導入プロジェクトでは、規則の縛りなどによって、世の中でいわれるベストプラクティスをそのまま適用できないケースがあります。しかし、制約は思考停止のいいわけにはなりません。

ベストプラクティスを鵜呑みにするのではなく、なぜそれが最適とされるのか、その本質を理解すること。

そして、その本質を理解したうえで、目の前にある制約のなかでどうすれば目的を達成できるのかを考え抜くこと、その考えの妥当性を周囲にきちんと説明することが、これからを生きるエンジニアには必須のスキルになるでしょう。

（※本記事の内容および対象者の所属は、イベント開催当時のものです）