こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 宮形 です。
2023年から地方自治体様を中心としたガバメントクラウドにかかわるプリセールスやプロジェクトを担当しております。最近多くなってきたのが「標準化システム同士のデータ連携機能をAWSでどのように実装すればよいか？」というご相談です。本BLOGではAWSでの実装アーキテクチャ案についてご紹介したいと思います。
注意： 本BLOGは私の個人的な考察と、弊社有志のメンバーより頂いた知見より記載した内容となっております。 動作を保証するものではなく、また地方自治体様の業務内容によってはご利用いただけないことも十分考えられます。 各省庁から示される機能の標準仕様の合致についてもお約束できるものではありません。ご承知いただき、参考情報としてご覧いただけると幸いです。
AWSで実装した場合のアーキテクチャ図
いきなりですが、考案したAWSで実装した場合のアーキテクチャ図になります。ポイントとしては下記となります。
- AWSマネージドサービス・サーバーレスで構成することで冗長構成の設計・構築・維持の負担減や、運用コスト削減を図る
- 地方自治体様のマイナンバー利用事務系(閉域)との接続を想定し、各通信はVPCプライベート接続
- 円滑なクラウド移行となるようオンプレミスで使い慣れたプトロコルを用いる (図では FTP etc と表現)
- データ連携側からファイル転送処理を行うため AWS Lambda でビジネスロジックを実装
機能要件を理解する
データ連携については地方公共団体（本BLOGでは地方自治体と表記）毎に利用方法は様々だとは思いますが、デジタル庁より標準機能として定義された資料がありますので、基本はこちらを参考にすることになります。
本BLOG記載時点(2024年5月22日)では、データ連携機能については下記のセクションに機能要件が記載されていました。
これら資料を読んでいくと、2つのアーキテクチャとして「① REST による公開用 API 連携」「② ファイル連携」が表記されており、どちらかで実装することになるようです。
現行オンプレミスでのデータ連携については、おそらくですが SFTP・FTPS・FTP や SCP をご利用されている地方自治体様が多いと思われます。そのことから標準仕様書にも「SFTP、SCP等」と書かれている後者「② ファイル連携」の方式をご検討されるケースが多いと予想します。なので今回の本BLOGタイトルは「FTP編」とさせていただきました。
各パートの説明
ここからは各AWSサービスの紹介を交えながら、各パートの説明をさせていただきます。
Amazon S3 を利用したデータ連携用S3バケット
Amazon S3 は 99.999999999%(イレブンナイン)のデータ耐久性を誇る高い信頼性を有するオブジェクトストレージとなります。使った分だけ利用料金でストレージを安価に利用でき、OSやミドルウェアの管理も不要のため運用コストも抑えることが出来るサービスです。AWS KMS という暗号鍵管理サービスと組み合わせることでのストレージの暗号化や、バケットポリシー等による最小限のアクセスなどセキュアな環境下での利用も想定されております。データ連携用のファイル格納先として、最有力候補となるAWSサービスかと思われます。
なお、この Amazon S3 ですが、アクセスするプロトコルとしてはHTTPSをベースとしたS3のオブジェクトストレージ独自の規格となっており、AWSよりアクセスに利用するためのAPIやCLIを提供しております。従来のオンプレミスで利用されてきた FTP や SCP のプロトコルはS3バケット単体では機能を有していませんが、後述する AWS Transfer Family 等を組み合わせることで対応できます。
このS3バケットは バージョニング という世代管理や、レプリケーション といった機能も有しており高い可用性要件にも準拠することができます。
また、VPC Endpoint を用いることでインターネットに接続しない閉域ネットワークでの接続経路を用意し、地方自治体様のマイナンバー利用事務系ネットワークからもアクセスすることが出来るようになります。
FTPサーバーの役割を担うマネージドサービス Transfer Family
AWS Transfer Family はAWSが提供するシンプルかつスケーラブルなファイル転送サービスです。このサービス単独で利用することはなく、Amazon S3 や EFS 等ストレージ系のサービスにSFTP、SCP 等のプロトコルでアクセスを提供する時などに利用します。インターフェースにはオンプレミスで使い慣れたプロトコルを利用し、データ保管先は高い耐久性と可用性を誇る Amazon S3 を利用できるため、堅牢なファイル転送サービスを実現することが出来ます。
なお、各省庁からのガイドライン*3 にそって、通信の暗号化が要件となるケースにおいては FTP は平文での通信となりますので注意します。SFTP、SCP 等を利用することになるかと思われます。
データ連携側でビジネスロジックを担う AWS Lambda
標準化システムのデータ連携における「② ファイル連携」においては、ここまで記載した Amazon S3 と Transfer Family で基本となる要件を実現することが出来ると考えております。 ただし、ファイルがデータ連携側に到達したことをトリガーとして、データを加工したりファイルを別のシステムへ転送したりとロジックを実装する場合も考えられます。クラウド上でサーバーを持つことなくイベント発生時にコードを実行できる AWS Lambda の利用を検討します。
クラウドへの移行前オンプレミスでは、FTPサーバー上に常駐するアプリケーションやジョブスケジュール等で実現されていた処理をAWSクラウドではサーバーレスで実現することができます。これによりサーバーの運用や冗長構成の設計・構築・維持が不要になりますので、ビジネスロジックに集中することが出来るようになります。
認証情報をセキュアに保持する AWS Secrets Manager
AWS Secrets Manager は、機密性が高い認証情報などをAWSクラウド上に安全に保管・管理するためのサービスです。例えば前述の AWS Lambda を用いたファイルを別のシステムへ転送するロジックの場合、ファイル転送先にも何等かの認証行為が必要となります。認証方法がIDとパスワードの場合、AWS Lambda のコード内に直接IDパスワードを記載することはセキュリティ上望ましいとは言えませんし、パスワード変更した場合にもコード変更再コンパイルといった運用負担が生じます。AWS Secrets Manager にIDパスワード等の認証情報を格納することで、AWS Lambda は実行時にそちらから必要なIDパスワードを取り出し認証を行うことが出来るようになり、セキュリティを高めつつ運用負担を削減することが出来ます。
また AWS Secrets Manager に保管した情報は、AWS IAM により認証・認可を受けたAWSリソースのみが利用できますので、無関係なAWSリソースや利用者に参照されるリスクも排除することが出来ます。
ビジネスロジックのキューイングを実現する Amazon SQS
Amazon SQS はサーバーレスアプリケーションで利用できる完全なるマネージドサービスのメッセージキューになります。ファイルがデータ連携側に到達したことをトリガーとしてロジックを実行する場合、一度に大量のファイルが転送されたことで処理が集中するリスクがあります。前述の AWS Lambda においては、デフォルトではAWSアカウント同一リージョン内について 1,000 という同時実行数が設定されています。この上限に達すると Lambda は実行されず処理が失敗します。このような状況に対応するのがメッセージキューをマネージドサービス・サーバーレスで実現するのが Amazon SQS です。
また、Amazon SQS にはエラーのために処理できないメッセージを一時的に保管するデッドレターキュー(DLQ)という機能があります。標準化システムデータ連携の機能要件にも「モニタリング（実行状況、結果等）」というものがありますので、DLQ にメッセージが保管されたことを契機に Amazon CloudWatch Logs や Amazon SNS のメール送信を組み合わせる等して処理失敗のアラート環境を構築することができます。
メタデータを保管するサーバーレスのNoSQLデータベース Amazon DynamoDB
Amazon DynamoDB は、サーバーレスで利用することができる MySQL のフルマネージドデータベースです。EC2 や Amazon RDS のようにインスタンスを起動する必要がなく、保存に使ったストレージと読み取り、書き込みのオペレーション に対して利用料金がかかります。
データ連携においてはファイル転送先毎の送信元S3バケット名、フォルダパス、転送先のIPアドレス等といった小さいメタデータを格納しますので、専用のDBインスタンスを起動する程ではない限定的な用途として利用します。ここまで登場した AWSリソースと同様に、AWS IAM により認証・認可を受けたAWSリソースのみが利用できますので、無関係なAWSリソースや利用者に参照されることはありません。
注意点
データ連携側のFTPサーバーへはDNSホスト名での接続を推奨
転送元のサーバー等からファイル連携のFTPサーバーへ接続する際、DNSホスト名 vpce-xxxxxx.xxxxx.ap-northeast-1.vpce.amazonaws.com での接続が推奨となります。これは VPC Endpoint がマルチアベイラビリティゾーン(以下 AZ と記載)構成となることで、複数AZへの接続を冗長化するためにDNSが用いられる為です。マイナンバー利用事務系のネットワークは閉域ネットワークになりますので、AWSが提供するDNSホスト名を名前解決できない場合があります。IPアドレスでの接続も不可能ではありませんが、マルチAZの恩恵を受けることが出来なくなりますので推奨はされません。AWSが提供する閉域のプライベートネットワーク上でもAWSサービスのDNSホスト名の名前解決を可能にする Amazon Route 53 Resolver を組み合わせてご利用頂くなどの検討が必要となります。
マネージドサービス・サーバーレスを主体としているためAWS利用料金が見積しづらい
S3バケット、AWS Transfer Family、AWS Lambda といったマネージドサービス・サーバーレスを実現するAWSサービスの利用料金は、どれも使った分の従量課金となっています。インスタンススペックを決めればおおよそのAWS利用料金を試算しやすい EC2 や RDS 等に比べると、AWS利用料金の見積がしづらいです。見積にはどれだけのファイルがアップロード・ダウンロードされ、各ファイルの平均サイズ、ファイルの送り返しする Lambda 関数の実行回数や処理時間といった情報が必要になります。これらを机上理論で試算することは困難であり、「やってみないとわからない」地方自治体様が多いのではないかと思われます。令和6年度はガバメントクラウドの早期移行団体検証事業に採択されれば、AWSの利用料金は国費で負担される方針が出されております。是非この早期移行団体検証事業の間に、AWS利用料金を実測頂ければと考えております。
まとめ
いかがでしたでしょうか。データ連携機能についてはガバメントクラウドへの移行前オンプレミスではおそらくFTPサーバー等を立てて運用されていたと思われます。業務システム間のデータ連携はミッションクリティカルでありながらも、FTPサーバーは冗長構成が難しい等もありインフラや運用コストが悩みの種であったのではないかと予想します。
AWSのマネージドサービス・サーバーレスは従来オンプレミスでの常識が通用しないので悩まれておられる地方自治体のご担当者様も多いかもしれませんが、容易に冗長構成が構築できOSアップデート不要など少ない運用コストでご利用いただける印象を持っていただけれたなら幸いです。
*1:https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/4d056a04-6eba-4109-9850-a786d3e71971/7a1137c2/20240430_policies_local_governments_common-feature-specification_outline_02.pdf
*2:https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/4d056a04-6eba-4109-9850-a786d3e71971/3e27b053/20240430_policies_local_governments_common-feature-specification_outline_05.xlsx
*3:地方公共団体における 情報セキュリティ監査に関する ガイドライン(令和 5 年 3 月版)：https://www.soumu.go.jp/main_content/000873099.pdf
