株式会社エアークローゼットでSREをしています、Cutと申します。
Cutは社内ニックネームです 
今回は、データウェアハウス移行から約1年が経過したので、実際どうだったのかを振り返っていきたいと思います。
当時の課題や現在の状況についても触れるので、移行判断について悩んでいる方の参考になれば幸いです。
この記事では、具体的な移行手順については紹介しません🙏
そもそもなぜ移行した？
当時、エアークローゼットではGCPのBigQueryを使用していました。
いくつかの記事でも触れられている通り、BigQueryの最大の武器はなんといってもそのスピードです。膨大なデータからでも数秒で取得ができるため、ノンストレスで使用できます。
しかし、エアークローゼットにとっては「コスト」が大きすぎるネックでした 
そもそもエアークローゼットでは、SQLの実行ログを集積するためにデータウェアハウスを使用しており、「オペレーション業務における調査手段の一つ」としての用途がメインでした。
用途が用途であるため、本来はそこまで多額の請求が発生することはないのですが、クエリのミスや操作ミスによって、とんでもない範囲のデータを検索してしまい、莫大なクエリ費用を発生させてしまう事件が稀に起こり、一つの課題になっていました。
※ この記事を書くにあたって「BigQuery 事故」で軽く調べましたが、同様のケースはやはりあるようです... 
なぜRedshift Serverlessを選択した？
エアークローゼットではリソースの多くをAWSに集約しているため、まず候補に上がったのがAWSのDWHサービスであるRedshiftでした。
元々はRedshiftの存在しか知りませんでしたが、AWSの担当者様とお話しする中でRedshift Serverlessの存在を知りました (当時はまだ正式リリースから半年だったようです)。
用途ともマッチしており、コスト調査の結果、削減が見込めそうだったため、移行する運びとなりました。
移行から1年経過して見えたメリット・デメリット
メリット
①コスト削減効果
これは狙い通り、コストを削減することができました。
RedshiftServerlessの強みである「実行時間あたりの課金」は、DHW上でクエリを1日数回程度しか実行しないエアークローゼットにとってかなりのコストメリットをもたらしています。
もちろんクエリの実行コストは低下しましたが、同時に「転送料の削減」も嬉しいポイントでした。
元々はCloudWatchからSubscriptionFilterでLambdaを経由し、GCPのPub/Sub、CloudDataflowからBigQueryへとデータを送る流れだったため、AWS→GCPのデータ転送料が地味に痛かったのですが、AWS内に閉じたことでデータ転送料をバッサリとカットすることができました。
②心理的安全性の確保
移行の理由で紹介した通り、BigQueryにはミスによる暴発のリスクがあったため、使用するエンジニアは怯える子猫のように、かなりの注意を払ってBigQueryを使用していました。
Redshift Serverlessに移行してからは、過度に心配することなく使用することができています(万が一の事態に備え、CloudWatchで使用料をモニタリングし、アラートを飛ばす設定もしています)。
本質的ではない部分で神経をすり減らす機会が減ったのは、とても嬉しいポイントでした。
デメリット
①スピード
想定してはいましたが、やはりスピード面ではBigQueryに大きく劣ってしまうのが現状です。
特に初回の実行は、クエリによっては結果が時間内に返ってこないこともしばしば。
2回目以降の実行ではさほど遅さを感じないものの、頻繁に使用するようなユースケースであればストレスを感じるかもしれません。
まとめ
ユースケースによっては、BigQueryからRedshiftに移行することで大きなコストメリットを得られる場合があります。
AWSの資料でも紹介されている通りですが、クエリが実行されていない時間が長いような環境では、特にその効果を発揮してくれると感じています。
最後までご覧いただきありがとうございました。