数ヶ月間、私はWindowsマシンでWSL2のRSSインジェスト、DockerのPostgres、Kestraオーケストレーション、dbt変換を使用してデータパイプラインを構築しました。すべてがローカルで機能しました。なぜなら、すべてが1台のマシンで実行されていたからです。CLIを介してAWSに移行すると、隠れた前提が明らかになりました。

t3.small EC2インスタンスをUbuntu 22.04で設定するのは簡単でした。驚きは、8GBのディスクが小さすぎて、growpartとresize2fsが必要だったことですが、新しいNitroインスタンスはドライブを`xvda`ではなく`nvme0n1`と命名します。Kestraのイメージプル中にインスタンスが「障害」になり、1GBのスワップファイルを追加して修正しました。Elastic IPとセキュリティグループの制限が小さな作業を追加しました。

rsync、Docker、docker composeでパイプラインを転送できましたが、Kestraのフローは内部データベースにあり、ファイルではないため、fetch_rssフローは手動でYAMLを貼り付ける必要がありました。これは、前提が1つずつ崩れるパターンを浮き彫りにしました。

本当の課題はAWS自体ではなく、「同じマシン」の前提に基づく隠れた依存関係であり、元の構築よりも多くのことを教えてくれました。