初めに
こんにちは！最近AWSを触り始めたデータレイクグループ・マスタチームの後藤です。
今回は最近行った、オンプレミス環境にあるデータをAWSのS3にアップロードする仕組みを構築した際の体験を共有します。
この記事は、私と同じようなAWS初心者の方に向けて書いています。
JMDCは「敷居が高そう」と言われることがあるそうなので、私のようなAWS初心者が発信することで、少しでもその敷居が下がれば嬉しいです。
システム構成の概要
今回は以下のような構成で、オンプレミスのデータをエージェント経由でAWSへ連携する構成です。
すでに同様の連携の仕組みが作成されており、エージェントは事前にインストール済みのため、4〜6のAWSリソースの作成からスタートになりました。
- データ（オンプレミス）
- AWSエージェント
- オンプレミス環境に設置済
- AWS CLIをインストール済み
- シェルスクリプト
- AWSコマンドでLambdaを呼び出してデータ同期を開始
- Lambda
- LambdaがDataSyncタスクを実行
- DataSync
- オンプレミスのデータをS3に転送
- S3バケット
- 最終的な格納先
構築作業
構築作業は、既存の仕組みを参考にしつつ、不明点はGeminiに質問することでサクサク進みました。
S3 / DataSync: S3バケットやDataSyncタスクは、基本的に作成するだけでした。IAMの設定やDataSyncのロケーション作成も、Geminiに意味を教えてもらいながら既存の構成と比較することで、問題なく設定できました。
Lambda: 作成したDataSyncタスクを呼び出すコードを書くだけでした。
苦労せずにできた～と思った矢先、DataSyncタスクが何度実行しても失敗するという壁にぶつかりました。
必要なIAMロールは設定済みのはず。LambdaやDataSyncのログを見ても原因は不明…。Geminiに壁打ちしてもよい回答は得られず、途方に暮れながら過去の資料やAWSの構成を深く調べていったら、原因を発見しました。
それは、「オンプレミス側のファイアウォールが、DataSync用VPCエンドポイントのプライベートIPアドレスへの通信を許可していなかった」というものでした。
私たちの構成では、セキュリティを高めるために通信をインターネットに出さず、AWSとのプライベートな接続を利用していました。エージェントが通信する先は、そのプライベート接続の入口となるVPCエンドポイントのプライベートIPアドレスだったのです。この重要な点に全く気づいていませんでした。
すぐにインフラチームに連絡し、該当のプライベートIPアドレスへの通信を許可してもらうことで、無事データ転送に成功しました。
得られた知見
学び：サービスだけでなく、通信経路全体を疑う
DataSyncはオンプレミス側にエージェントを設置しますが、サービス「本体」はAWS側で稼働しています。そのため、エージェントからAWS上のVPCエンドポイントへの通信を、オンプレミス側のファイアウォールで許可する必要がありました。
→ つまり、エージェントを設置するだけでなく、その通信経路となるネットワーク設定まで含めて考える必要があるということです。
所感
今回の構築を通じて、失敗の直接的な原因となったネットワークの知識はもちろん、設定段階で学んだIAMロールの重要性についても理解が深まり、大きな収穫となりました。特にIAMロールは、Geminiに「許可証」のようなものだと教えてもらったことで、各サービス間の権限の受け渡しがイメージしやすくなりました。
AIをエンタープライズで使えるのは非常にありがたく、過信は禁物ですが、初めて行うタスクでも作成するスピードは段違いに上がったと感じます。
