AWSから抜け出す方法も考えておく【ガバメントクラウド】

記事タイトルとURLをコピーする

こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 宮形 です。今年に入ってガバメントクラウドのブログを書くようになりまして、どの記事も前向きでポジティブな内容を心がけておりましたが、今回は一転して後ろ向きなタイトルになります。

本BLOGではガバメントクラウドにおいてAWSに各システムをリフト&シフトした後に、AWSから抜け出す方法 について検討した内容を記載させていただきます。

このBLOGを書こうと思い立った理由

理由は明快でして、少しでもクラウドへの移行リフト&シフトへの不安を払拭したい思いになります。

ガバメントクラウドについては日々多くのメディアやSNSで取り上げられていますが、先行きの不透明さや不安を煽るような情報が目立ち、肝心のクラウドやAWSの利点には焦点が当たっていないように思えます。

弊社では「クラウドシェルパ」というクラウド活用の伴走型支援サービスを提供しておりますが、この「シェルパ」は「登山者が山の頂上にたどりつくための手助けをする案内人」という登山用語になります。登山道の「登りの道」を手助けするのがシェルパの役目だとすれば、いざという時の「下りの道」(引き際) の確保もまたシェルパの重要な責任だと思いまして、本BLOG執筆に至ったわけでございます。

www.serverworks.co.jp

AWSから抜け出す方法を各サービス毎に検討する

AWSは200を超える多くのサービスで構成されていますので、ひとつに「AWSから抜け出す」といっても各サービス毎に検討する必要があると思いました。以降ではガバメントクラウドへのリフト&シフトに多用されると思われる代表的なAWSサービスに絞って、それぞれの「抜け出す方法」を難易度を添えて紹介します。ここでの難易度は個人的な所感であり、ご利用方法によって異なりますので参考までに捉えてください。

仮想サーバー EC2

難易度順:低

おそらく直近でガバメントクラウドへの早期移行で最も多く利用されるのが、仮想サーバーに相当する EC2 ではないかと思われます。

この EC2 ですが、仮想サーバーで多く利用されるイメージファイルにエクスポートする VM Import/Export という機能があります。

VM Import/Export とは - VM Import/Export

対応しているイメージファイルの形式としては、多くのハイパーバイザーやクラウドサービスで利用される下記が利用可能です。

  • OVA:VMware vSphere 等で利用可能
  • VHD:Citrix Xen および Microsoft Hyper-V 等で利用可能

もともと仮想サーバーにはポータビリティ(持ち運びができること)というメリットがありますので、AWSから抜け出す際にもその恩恵を受けることができます。この方法を用いれば、比較的容易にAWSから抜け出すことが可能と考えました。

データベースのマネージドサービス RDS、Aurora

難易度順:低

Amaon RDSAmazon Aurora はAWSがOS以下レイヤーを維持管理するデータベースのマネージドサービスです。オンプレミスでデータベースとしてご利用されていたDBサーバーのガバメントクラウド移行先として多く選択されることが予想されます。

マネージドサービスという立場上これらは仮想サーバーという単位で利用者が制御することができませんので、VM Import/Export は利用できません。ただし、データベースとして一般的に利用されるエクスポート・インポートのユーティリティが利用できます。

  • MySQL:mysqldump ユーティリティ 参考
  • PostgreSQL:pg_dump ユーティリティ 参考
  • Microsoft SQL Server:SQLServer ネイティブのバックアップ・リストア ユーティリティ 参考
  • Oracle Database:Oracle Data Dump、Export・Importユーティリティ 参考

これらユーティリティで取り出したバックアップファイルをオンプレミスや他社クラウドサービスへ移行することで、比較的容易にAWSから抜け出すことが可能と考えました。

コンテナの実行環境 ECS、Fargate

難易度順:低

ガバメントクラウドへの早期移行では選択する状況は少ないと思われますが、コンテナの実行環境となる Amazon ECSAWS Fargate を地方自治体様のシステムでご利用されるケースが考えられます。こちらは Docker のコンテナ形式でデプロイしますので、仮想サーバーと同様にポータビリティ(持ち運びができること)があります。コンテナイメージさえあれば、オンプレミスに構築する Linux や Windows での Docker サーバーや、他社クラウドサービスの Docker コンテナ形式をサポートするサービス等へ移行することができます。比較的容易にAWSから抜け出すことが可能と考えました。

ファイルサーバーのマネージドサービス FSx for Windows File Server

難易度順:低

Amazon FSx for Windows File Server は従来のWindows ファイルサーバーと互換性のあり、AWSがOS以下レイヤーを維持管理するマネージドサービスです。Active Directory ドメインサービスがあれば、比較的容易に利用開始できますので、ガバメントクラウドの早期移行でご利用検討される地方自治体様も多いと予想します。

この FSx for Windows File Server ですが、Windows ファイルサーバーと互換性 がありますので、容易に他のファイルサーバーへ移行することができます。移行に使われる代表的な方法としては Windows で標準提供される robocopy ユーティリティがあります。AWSから抜け出す先がオンプレミスであれば、ファイルサーバーやNASを用意して移行するだけで、クライアントからは同じプロトコルで引き続きアクセスできます。

他社クラウドサービスだと Azure Files 等が移行先候補となります。これらも恐らく robocopy が移行方法として利用できると思われます。ただし、総務省のガイドライン *1 に基づきデータ移行に用いるネットワークはインターネットや他用途ネットワーク(LGWAN接続系、インターネット接続系)と分離する必要があります。これには専用の閉域網を用意する必要があり、それぞれ機能をプライベート接続(インターネット非接続)で利用する方法を再設計しなくてはなりません。

AWSからの抜け出し先がオンプレミス、他社クラウドサービスどちらでも、クライアントが同じプトロコルでアクセス出来ることから、難易度は低いと考えました。

オブジェクトストレージ S3

難易度順:中

Amazon S3 はAWSが提供するオブジェクトストレージで、高い耐久性を誇り、EC2や他ストレージ系のAWSマネージドサービスと比較すると安価に利用することができます。ガバメントクラウドでの利用が想定されるのがバックアップ、ログ、過去アーカイブの保管先ではないでしょうか。

この Amazon S3 ですがクラウド特有のサービスということもあり、オンプレミスで同等機能というものが無いと考えています。代替で実現しようとするとオンプレミスにファイルサーバーやNASを用意することになるかと思います。しかしながら、これら代替方法はクライアントからアクセスするプロトコルが異なります。アプリケーション側の改修が必用になるかもしれません。また、巨大な過去データになるとテープドライブ・カートリッジ等の専用装置が必要になることも考えられます。

他社クラウドサービスだと Azure Blob StorageGCP Cloud Storage がオブジェクトストレージの移行先候補となります。移行先クラウドサービスの機能*2*3を用いてデータ転送を行うことが出来ますが、総務省のガイドラインに基づきデータ移行に用いるネットワークはインターネットや他用途ネットワーク(LGWAN接続系、インターネット接続系)と分離する必要があります。これには専用の閉域網を用意する必要があり、それぞれ機能をプライベート接続(インターネット非接続)で利用する方法を再設計しなくてはなりません。

AWSからの抜け出し先がオンプレミス、他社クラウドサービスどちらでも労力とコストが掛かる為、難易度はやや高い(中)かと考えました。

サーバーレス実行環境 Lambda ファンクション

難易度順:???

AWS Lambda はAWSクラウド上でサーバーや実行環境のインフラを保有することなく、アプリケーションの実行環境を使った分の従量課金で利用することができます。このような環境を「サーバーレス」と言ったりします。この Lambda ですが Python、Node.js、C#、PowerShell 等多くのランタイムや開発言語をサポートしており*4、これらでコーディングしたプログラムを「ファンクション(Functions)」という単位であつかいます。

仮にAWSから抜け出すとなった場合、これらファンクションの新しい実行環境を用意する必要があります。オンプレミスであれば、サーバーにランタイムを用意すれば原理的には引き続き実行することが可能です。ただし、クラウドネイティブで開発されたコードは、オンプレミスでは利用できないクラスやメソッドが用いられているかもしれませんし、利用するストレージも S3 からファイルシステムに変わる筈です。これら非互換に合わせてアプリケーションのコードを改修し、テストするための労力・工数が伴います。

他社クラウドサービスだと Azure FunctionsGCP Cloud Functions がサーバーレスのファンクション実行環境の移行先候補となります。オンプレミスへの移行ほど多くはないとは思いますが、やはり非互換がある可能性がありますので、アプリケーションのコードを改修し、テストするための労力・工数が伴います。

この難易度はファンクションの数や役割、コードの内容次第ですので、AWSからの抜け出す難易度を一概に評価すべきではないかと思いました。難易度は予測不要(???)とさせていただきます。

ディレクトリサービス AWS Managed Microsoft Active Directory、Simple AD

難易度順:高

AWS Managed Active DirectorySimple AD どちらも AWS Directory Service のファミリーに該当し、従来の Microsoft Active Directory や LDAP のガバメントクラウド移行先に選択されることが予想されます。

これらサービスですが、 Microsoft Active Directory に相当する機能は有しておりますが、残念ながらどちらもAWSマネージドサービス外部との Active Directory レプリケーション機能を有しておりません。そのため、AWSから抜け出すためには外部 Active Directory ドメインとの信頼関係を設定したうえでADMTツールを利用するなど、移行には創意工夫が必要となります。まったく移行する方法が無いわけではないにせよ、難易度はかなり高いと判断せざるを得ないと考えました。

なお、仮想サーバーに相当する EC2 に Active Directory ドメインサービスをインストールして利用する方法もあります。こちらであれば従来オンプレミスと同じく Active Directory レプリケーション機能を用いることでオンプレミスや他社クラウドサービスへ容易に移行することができます。

抜け出す際のAWSデータ転送費用も検討

ここまで各AWSサービス毎にAWSから抜け出す方法や、自分なりに思う難易度について書かせていただきました。

どのパターンにおいても多かれ少なかれAWSからデータを抜き取り移行するための「データ転送費用」が発生することに注意が必要です。地方自治体のマイナンバー利用事務系ネットワークにおいては、専用の閉域ネットワークで構成することが多いかと思われますので、具体的には Transit Gateway のデータ転送費用Direct Connect のデータ転送費用(Out) 等が対象となります。想定される費用は、データ量から AWSプライシングカリキュレーター より算出可能になります。

直近のAWSアップデートで、サポートへチケット(問合せ)を起票し受領されることで、AWSから移動するデータ転送費用を無料にする措置が公開されました。欧州の法律に合わせた対応のようです。この措置はインターネットを使ったデータ転送に限定されているようなので残念ながらマイナンバー利用事務系ネットワークにては適用できない可能性が高いですが、このような取り組みもAWSへのリフト&シフト推進を前向きに捉えることができる要素かと思います。

aws.amazon.com

まとめ

AWSから抜け出す方法と難易度をまとめると下記の表組となりました。

AWSサービス 方法 難易度
仮想サーバー EC2 ・仮想サーバーの実行環境用意
・VMイメージの移行
データベースのマネージドサービス RDS、Aurora ・DBサーバーの用意
・RDBMSのエクスポート・インポートの利用
コンテナの実行環境 ECS、Fargate ・Docker 実行環境の用意
・コンテナイメージの移行
ファイルサーバーのマネージドサービス FSx for Windows File Server ・ファイルサーバーの用意
・robocopy等の利用
オブジェクトストレージ S3 ・代替ストレージ設備の検討および用意
・移行方法の検討
・非互換の対応
サーバーレス実行環境 Lambda ファンクション ・ファンクションの実行環境の検討および用意
・非互換の対応
???
ディレクトリサービス AWS Managed Microsoft Active Directory、Simple AD ・移行方法が限定的なため創意工夫が必要

いかがでしたでしょうか。タイトルとしては後ろ向きな内容になってしまいましたが、各サービス毎にAWSから抜け出す方法を検討してみると、ガバメントクラウドの早期移行に利用される可能性高いAWSサービスではそれほど難しくなく前向きな印象を持っていただけたのではないでしょうか。

繰り返しになりますが、本BLOGはクラウドへの移行の足止めをするためではなく、不確定な将来へのリスクヘッジの情報となるよう心がけて書いております。

AWS専業ベンダーのエンジニアとしては、是非皆様のクラウドへの不安を少しでも払拭し、AWSクラウドの特徴や強味を生かし、システムの弾力性、スピード、変化への対応を強化いただければと願っております。

本BLOGの内容が、少しでも皆様の参考になれば幸いです。

*1:地方公共団体における 情報セキュリティ監査に関するガイドライン 令和 5 年 3 月版 : https://www.soumu.go.jp/main_content/000873099.pdf

*2:Azure Data Factory を使用して Amazon S3 から Azure Storage にデータを移行する : https://learn.microsoft.com/ja-jp/azure/data-factory/data-migration-guidance-s3-azure-storage

*3:Amazon S3 から Cloud Storage への単純な移行 : https://cloud.google.com/storage/docs/aws-simple-migration

*4:AWS Lambda 開発者ガイド : https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html

宮形純平(執筆記事の一覧)

エンタープライズクラウド部 ソリューションアーキテクト1課

好きなお酒は缶チューハイと本格焼酎