BlueVancouver- アラサー　エンジニア転職@カナダ

現在アラサーの駆け出しエンジニア。[文系学部卒]にも関わらず26歳の時にSoftware Engineerになる事を決意。東京の外資系コンサル会社を26歳で退職し、カナダでのコンピュータサイエンスの大学に理転しました。(業務未経験) & (アラサーからの理転) & (いきなりカナダ)　ですが、日本人としてもっと多様なキャリアがあってもいいと思い、情報共有しております。Youtube: https://www.youtube.com/channel/UCpa0EIrdETaR2gunXDEz-7A

2025年の学びと振り返り

年に一度しか更新しないようなブログとなっていますが、今年もとりあえず自分のために2025年の学びと振り返りをしていこうと思います。

 

2025年できたこと、学び

2025年はイベントが多かった2024年に比べどちらかと言えば次の年へ向けて準備する一年になりました。

  • 仕事面
    • メインは次の年のプロモーションへ向けて準備する一年になりました。今年はほとんどのプロジェクトが自分がメインでリードするプロジェクトとなり、プロジェクト以外にもメンターとしてインターン生を担当したり、プロジェクト外のツールに新たな機能を追加したり、あとはとにかく提案ドキュメントを大量に書いた。
    • メインの技術ドメインである、Spark, Airflow, Hive HMS, Yarn, k8s, Trinoの深い理解を深めることができ、Spark、Airflowについては夏休みをとって、コードベースを一から読むことにした。
    •  最近はプロジェクトの仕事を早く終え、できるだけ社内のforkしたこれらのrepoに新たな機能を加えたり、SEVが起きた時に調査に貢献したりした。インパクトドリブン開発という考えは好きではないが、社会人である以上嫌いなことをある程度割り切ってやっている。
      • プロモの話をすると長くなってしまいますが、プロジェクトはデリバーして当たり前という評価にしかならない、かつ自分の興味のある深掘りした技術調査とそのoptimizationは社内のプロジェクトではできないため、こうやってプロジェクト外で個人的に開発して、ある程度のものができたら面倒な承認プロセスを経て、みんなに共有してます。
  • 仕事外の個人プロジェクト
    • 自分の深掘りたい分野で仕事ではfundingがおりないような技術は週末に個人プロジェクトとして、触ってみたり調べてみたりすることにした。LLMのtrainingに必要なcommon crawlerの情報を品質を効率よくフィルタリし、整理し、LLM training pipelineに渡す用のデータを作るspark ML libのようなものを個人的に作ってみたりしています。私費でAWS EMRを立ち上げ、terraformで一元管理し、作ったlibraryでインターネットscaleのデータをprocessするlibraryをまだWIPですが、準備中。個人プロジェクト一番の難題はAWSのコスト。これとどこまで折り合いをつけるか。
    • あと今までpysparkでapplication側は書いてきましたが、初めてlibrary側として機能を作るので、scalaをちゃんと勉強する必要が出てきました。今まで避けてきたので作りながらscalaを勉強する。やはり最高の勉強はものを作りながら学ぶこと。
  • 家庭
    • 第一子が年明け産まれることとなりました。父として準備する一年でした。
    • 今後子育てとTechでの仕事が大変になりそうですが、自分なりに努力していきます。
  • 生活関係
    • 昨年にカナダでの永住権を取得してから二年目となり、オンタリオでドライバーライセンスも取得。第一子が2ヶ月後に産まれるため、新しい物件の契約が無事決まり、今よりも広い物件に引越しが決まった。

来年目指すこと

  • 子育てとtechの両立を頑張る、家族の時間を意識的にとる
  •  仕事/技術面で言えば、準備の一年だった2025年の努力が実ること
    • 社内
      • さらなるリーダーシップを発揮する。
      • ICEBERGをもっと深掘りする。
    • 社外の個人プロジェクトを良いベンチマーキングを叩き出すこと。
      • 今まで避けてきたscalaをプロフェッショナルレベルでかけるレベルに持っていく。
  • その他
    • 2027,2028年に向けた将来設計をする。

良い会社の定義とは何か

仕事・退職

目次

1: 前提の定義

2: 良い会社の要素

3: 良い会社のKPI

 

 

久しぶりのブログになります。

1: 前提

このブログではUS TECH企業にトロントで働くソフトウェアエンジニアの自分が個人的に考える良い会社とどう良いを定義するかを考える。

スタートアップからアマゾン、mid sizeのTECH企業も様々経験し、今後自分がどういうキャリアを進みたいかを考えたいから、このブログを書く。

あくまでも自身の思考の整理としてこのブログをアウトプットとして使っていますが、もし誰かの参考になれば幸いです。

2: 良い会社の要素

何を持って自分にとって良いと言えるのか。

自分が気にする良い会社の要素は以下になる。

  • 1.給料が良いか
    • 給料のためにわざわざトロントまで来たし、USテック企業で働いている。
  • 2.ワークライフバランスが良いか。
    • 家庭もあるので、休日も仕事という訳には行かない。
  • 3.レイオフやPIPがないか。
    • アマゾンではレイオフを経験し、これは一度経験して経験値としては財産になったが、今後は避けたい。レイオフやPIPがあるというだけで仕事に１００％集中できないと思うので、これは譲れない。
  • 4.働きやすいか
    • 少し関連しているが、会社文化も大事。同僚にブリリアントジャークがいないか、風通しがいいか、仕事の横取りはないか。特にマイノリティーに対して偏見がないかなど。
  • 5.技術的にtransferable skillが学べるか、深められるか。
    • 会社でソフトウェアエンジニアをするなら、ある程度どこの会社でも成長する機会はあるので、また、成長するかどうかは自分次第なところもあるので、あまり気にするようなことではないかも知れない。どちらかというと、自分が気にしているのは、１：今まであまり触ってこなかった技術に触れる機会が多ければ良い。そしてそれが２：transferable skillはもう少し噛み砕いて言えば、ABSTRACTIONがTOO MUCHじゃないこと、かつ他社でも使われる技術のこと。ABSTRACTIONやTRANSFERABLEじゃないとは、例えば全てがAWS上で完結するシステムであれば、AWSの機能だけ詳しくなって、そのunderlying technologyを理解できない・する必要のない状態のことを自分は意味する。仮にAbstractionされずに自分で何かscratchで開発してもそれがその会社の内部状況にやたら詳しくなるだけなら、意味がない。
    • 大企業になればなるほど、全てabstractしようとして、その中身がどう動いているかよくわからずに動くものが作れてしまうので、あまり学びがないし、仮にscratchで何か作るとなっても、それが社内ユーザーならまだいいが、社内システムの回収ならあまり魅了的ではない。
    • 周りに優秀なエンジニアがいるかというメトリックスを作ろうと思ったが、実際技術的にtransferable skillが学べるか、深められるか、という条件が良いエンジニアを引き寄せると個人的には思っているので、あえてメトリックスとしては切り出さない。

3: 良い会社のKPI

ではそれぞれの良い会社の要素について、どうKPIを設定していけば良いか。

これはあくまでも独断と偏見。

  • 1.給料が良いか
    • これ自体がKPI
  • 2.ワークライフバランスが良いか。
    • publicにある程度surveyでている。
  • 3.レイオフやPIPがないか
    • publicにannounceされているので、そういうのを避けるだけで良い。
  • 4.働きやすいか
    • まずはaverage tenureを自分は見ようと思う。average tenureだけ見ると1.給与と2.ワークライフバランスが良いかと3.働きやすさとレイオフやPIPの全てをcombineしたものが反映されるはずで、average tenureだけ見ても働きやすいかだけを見ることはできない。ただし、自分の場合はこれら全てを気にするため、average tenureをまずは見る。
    • Diversity関連の公開データ
      • 会社が公開しているDiversity Reportの数値
      • マイノリティのsenior positionの割合（偏見がないかの間接指標）
    • Boomerang rate（出戻り率）
      • 一度辞めた人が戻ってくる率は、働きやすさの良い指標になりえる
    • Internal mobility rate
      • 社内で別チームに移れる頻度・容易さ（閉塞感がないかの指標）
  • 5.技術的にtransferable skillが学べるか、深められるか。
    • job descriptionから求められる技術からある程度予想できる。使う技術がopen sourceのものだったり、自分が今まで触れてこなかったものなら良い。too much abstractionかどうかだけ、口コミで見るしかない。
    • 社員のカンファレンス登壇数
      • too much abstractionかどうか気にしているので、それに対してはこのメトリックスが役立ちそう。社員のカンファレンス登壇数は社内の開発が他社にも役立つという証明なので、直接KPIとして利用できる。
    • 卒業生の行き先（Alumni career path）
      • LinkedInで元社員がどこに転職しているか
      • 技術的に評価の高い会社に移れているなら、transferable skillが身についている証拠

逆に自分にとって良い会社の要素として優先度が高くはないもの

  • 昇進がしやすいかどうか
    • なぜか
      • そもそも昇進は社内政治や運も絡むのでコントロールできるものではない。
      • 技術的transferable skillがあれば、職位の昇進は後からついてくる（他社に移ればいい）という考え
      • 特にUS Techでは数年に一度の転職が普通なので、最悪、転職でランクをあげる。

上記以外に良いKPIやメトリックスがあればeditしようと思います。

2024年の学びと振り返り

仕事・退職 就職活動 海外移住

年に一度しか更新しないようなブログとなっていますが、とりあえず自分のために2024年の学びと振り返りをしていこうと思います。

 

2024年できたこと、学び

  • トロントで転職:
    • 昨年末のレイオフ後、テック冬の時代とも言われましたが、毎日leetcode, system design,筋トレを継続し、強く生きることができ、無事やりたいSoftware Engineerの仕事を見つけることができました。妻と周りのサポートに感謝。引き続きTech業界でSWEとして頑張ります。
    • レイオフ中はメンタルがどんそこで辛い日々でしたが、信じて頑張ってよかったです。チーム自体がなくなったので、マネジャーのせいでもチームメイトのせいでもないですが、チームをなくす選択をした人を数年後見返せるように今後も頑張ります。
  • カナダ永住権:
    • 2019年から住んできて、5年経ってようやく永住権を取得しました。長かったような短かったような。妻の永住権も取れたので、これでカナダにおいてはビザの心配する必要がなくなり、メンタルが一回り強くなりました。
    • 過去にどこかで書いたかもしれませんが、自分は人生における選択肢をできるだけ増やしたいと思っています。日本だけでなく、複数の国で働ける権利を持つことで、それなりの対応が取れるかと。
  • 技術面
    • Airflow:転職後ちゃんとcatch upでき、 特にAirflowの中までbasicな作りをcodeを追って理解する時が取れた。まだまだこれからなので、Airflowの理解を深めていきたい。
    • Spark: 前職から引き続き使い続け、特にarchitectureの部分の理解とhistory UIからbottleneckを見つける経験が増えて、見える範囲が広がった。こちらも来年は作る前にbottleneckの勘所が見えるように磨いていきたい。
    • Hiveエコシステム
      • 今までAWS Glue metadataだったので、今の仕事ではHiveのmetadataに触るようになり、どうmetadataが構成されているか理解が深まった。
      • 特にHadoop、HDFS、YARN、Trino、Icebergの本を読む時間をちゃんと取れて、Hiveエコシステム全般の理解が深まった。
    • ML system design
      • 現在の仕事場ではML modelをどうアプリで運用するかが大事で、modelに食わせるfeatureをどうデータとして持つか、そしてinference時にいかにE2Eで早く食わせるかのsystem designを学ぶことができた。こちらは技術というか知識ですね。今までデータ基盤構築、Data Ops、Data Infraのデザインを前職でやっていましたが、現職からはよりML Opsをデザインして構築する機会が増えて、まだまだ勉強の毎日です。
    • 2024年から、個人的な学びをgoogle docにoutputするようにしてきました。すでに150 page以上になってきていて、どこかでpublicにoutputしようとは思っていますが、また時間ができたら。
  • 旅行
    • やっぱり自分は旅が好きで、今年は妻と一緒にカナダ国内の旅行と、米国はマイアミ、サンフランシスコ、そしてメキシコのカンクンに行けたので最高の一年でした。来年も旅行に行けるように仕事を頑張る。

来年目指すこと

  • 家族の時間を意識的にとる
    • 妻と一緒に永住権をとって、日々一緒に過ごす時間が増えてきたので、意識的に時間をとっていきたい。
  •  仕事/技術面で言えば、
    • もっとML Opsの設計パターンの理解を増やす。
    • Spark,Airflowも書いたように、問題が起きる前にbottleneckの勘所が見えるように磨いていきたい。
    • Apache Icebergをもっと触る、そして現職でどう生かせるか理解し、検証してみたい。
    • Flinkにももっと触る機会を増やしたい、最低でも学んだ知識を実際にapplyできるようにする。
    • Hive metadataとSpark/Hadoop/YARN/HDFSのmetricsに対する理解を増やす。これができるとissue triageが早くなる。
    • 昇進とかあまり意識するのが個人的に好きじゃないので、あまり気にせずにできることの幅と深さを伸ばしてきます。
  • 旅行
    • 最低でも2箇所は旅行で行くと思うので、近場でもう一つくらいいきたいと思っています。
  • 健康
    • 体調管理しっかりする。

2025年も成長していけるように頑張ります。

年収も需要も時代が決める - 海外エンジニア

仕事・退職 技術

個人的意見と感想をただただ書いています。

私はトロントでソフトウェアエンジニアをしていて、今まで何人かの優秀なエンジニアを見てきました。PhDを終えて、エンジニアに新卒就職した人、PhDからポスドクを経てからエンジニアに転職した人、ポスドクを超えてAssociate Professorをやってからエンジニアに転職した人。どの方々も非常に優秀で自分では叶わないと思うような方々でした。

ただ、自分はそのようなScienceの分野では勝負しないので、今回はあくまでもその方々を見てきて思ったことを呟きます。

注）自分はPhDを持っているわけでもないので、これはただの独りごとです。

 

年収も需要も時代が決める。

自分は取れるものならPhDに挑戦したいとは思います。それは置いといて、とあるポスドク後の優秀な同僚のかたがいて、彼はとあるスタートアップでエンジニアをしています。とても優秀なのですが、バックグラウンドもマッチすることもあり、かなりニッチなscienceよりの分野でトップレベルのスキルを有しています。

当時留学中だった自分はどうやったら彼のようになれるか考えており、その過程でその同僚のタイトルになるといくらほど年収がもらえるかなんとなく調べていたところ、予想とは反対に市場の平均前後だったのです。彼はそのScienceの分野でエンジニアとしては本当にトップレベルの人材ということをなぜかマーケットが評価していないという数字が納得いきませんでした。

自分はそのそのスタートアップのインターン最終日に彼に、今後もこの分野の技術を続けるのか聞いたことがあります。彼はおそらくまだしばらくその分野でやっていくとおっしゃっており、それはそれで素晴らしいのですが、まだまだ時代がその新しい技術に追いついていないと感じました。その技術を続ける場合、かなりニッチなため他の企業でjob positngはほぼなく、州外または国外に行かないとおそらく転職はないかもしれないとLinkedInのjob postから思いました。

あくまでも自分の感想ですが、ここまで優秀でも、良くも悪くもニッチな領域だとなかなか他の企業からの需要が少なく、転職が厳しく、競合がいないということは平均的な年収で雇えてしまうのだろうと感じました。

価値観は人それぞれですが、シンプルにただただ年収をあげるのをを目指すのなら、ニッチに行きすぎず、程よく需要がある分野でそれなりに特化することが大事だと思います。なので、良くも悪くも、年収も転職需要も時代が決める。

年収に関してはどこに住むかも大きく影響しますが、それはまたどこかで書きたいと思います。

自分はこのことで今でも考えています。今はリアルタイムのデータ　ストリーミング、Data Ops Software、データ基盤構築、インフラ、IaaC、Big Dataのoptimizationなど結構データにニッチに生きていますが、これが良いのかどうか、考えてbackendに行くかML Opsなどに行くかいつかはシフトしていかないといけないと感じています。

年収も需要も時代が決めるので、どうにかその大きな流れについていけるように2024は頑張っていきます。

2023年の学びと振り返り

仕事・退職 海外移住

トロントでは、そろそろ2024年を迎えようとしていますので、自分の成長記録や個人的な備忘録として残しておきます。また時間ができたら別のエントリーで落ち着いたらもっと細かいエントリーも書くつもりですが、まずは自分用に2023年まとめを書いておきます。

 

キャリア面

2022年にData Ops系のソフトウェアを書くエンジニアとして、OLAPデータ基盤のゼロからの構築やML系dataのインフラ管理を、トロントで働き出し、2023年は今の会社で２年目を迎えたので、業務的なキャッチアップを終え、ようやく技術的にも気持ち的にも、本来のインプットを出せてきた年でした。

技術的な学びで言えば、成長した分野としては

  • Data Ops Software開発: Serverless なEvent Driven Designの理解を深め、Scalableな設計とあり方を実践できた。
  • Sparkのbig data処理: パフォーマンスoptimizationや、Memoryのdebugginなど細かい実務レベルでレベルが一つ上がった。
  • Data Modelling：大きく変化するビジネスモデルに合わせるData Modelを作れた。
  • Data Integration: RedshiftやData Lake on S3で持っているデータをRedshift data share使ったり、S3 to S3でやり方を調べたり、学ぶことが多かった。Data Integrationは技術というよりかは、ビジネスコミュニケーションが全てな気もしますが、これはエンジニアとして生きていく上で避けれないので、慣れるしかないですね。
  • CI/CD: AWSでCDKをちゃんと学びだしてから、CI/CDはまだproto type作るレベルで、それ以上は仕事では進まなかったですが、Data系のpipelineのcodeでもIntegration Testをちゃんとやろうという意識を持って日々の業務に取り組み、S3にexpected resultをparquetでstoreしておいて、CDKで決めておいたそれぞれのbatch jobがprocessしたデータに対して、あらかじめ作っておいたexpected data outputとマッチするかテストするPoCを下半期はやっていました。

来年やりたいこと

  • Airflowは学んだけど、普段使っているGlue Workflowよりどこまで細かいレベルで管理できるか。次なる職場で試してみたい。
  • Snowflake: 実際AWSは便利なので、Snowflake使うチャンスなかったけど、これも次の会社で使ってみたい。
  • Real-time streaming: Data OpsやData pipeline、ML系のデータインフラ構築、管理に加え、よりbackendに近い、real-time data streamingの仕事を増やしていきたい。それがML domainならなお良い。Kappa vs Lambda architectureのLambdaの方を実際に書く機会があれば尚良い。
  • Kotlin: これは言語として既に来年使うことが決まっているので、ちゃんと深めていきたい。Real-time streamingをkotlinでやるときに業務でしかencounterしないことは絶対あるので、backend系のReal-time streamingスキルセットをもっと深めたいので、頑張ります。
  • ML Ops: いずれはML Opsに軸足をシフトしていく。2023年はML系のデータを扱ってきたものの、deploy、ML pipelineなどをしてきたわけではないので、個人プロジェクトなどでhands-onで経験を積んでいく

今年の学び

正直GPTが凄すぎて、ただコード書くだけの人材はいらないとよくわかった一年だった。これはもう避けれることではないので、じゃあ今後どういうキャリアに集中するかに集中していきたい。自分はマネジメントは全く興味ないので、対策としては以下になるかと思います。

シニアエンジニアはdefaultで目指しているので良いとして、あとGPTに奪われないキャリアとしては、

  • data architectや設計の知識を増やす。Fundamentals of Software Architectureの本があと半分残っているので、まずはちゃんと技術書読むところから始める。
  • ML Opsに寄せる: ML Opsの経験積んで、データ系のソフトウェアエンジニアの知見を生かすML Opsになるのも面白い。

 

 

仕事以外の話

2022年に妻と入籍して、2023年に無事に結婚式を日本であげることができました。これからトロントで夫婦生活も始まるので、貴重な時間を大切にしていきたいと思います。

 

人生はA-くらいでいいと思っています。ここ数年はコロナや不況で正直大変な2,3年でしたが、人生を100%としたら、自分の場合の幸せは次のように定義できます。

  • 25%は身体の健康
  • 25%はメンタルの健康
  • 25%は家族との時間
  • 25%は資産と仕事の収入

なので、人生における仕事はたった25%もありません。散々と技術の話してきましたが、残りの75%を大切に2024年も1日1日大事に、growth mindsetを持って成長していきます。

 

スタンフォードMBAのEssay:What matters most to you, and whyについて考えてみた話

仕事・退職 海外移住

スタンフォードのMBAでは毎年Essayのお題でWhat matters most to you, and whyが出されます。私はMBAを取得したわけでも、今では行きたいわけでもありませんが、過去に外資コンサルで働いていた際に、MBA出願を目指し、このEssayについて考えたことがあり、これが原因というわけではありませんが、一つのきっかけとして、MBA、ついでにビジネス系のキャリアから一旦は技術職にshiftするきっかけになりました。

今ではこのスタンフォードGBSのお題にすごく感謝しています。

過去の話

外資コンサル時代、キャリアアップするにはMBAしかないと思い、アゴスや各スクールが東京に来る際には毎回ブースに足を運び、在校生の話を聞いていました。コンサルは3年できっちりやめて、MBAに行く予定だったので、2年目からこのEssayに週末に取り込んでいたと思います。

本題

What matters most to youですが、当時と今で少し考えは変わるかもしれませんが、今の自分を主観として誰からの評価も気にせず、本音で書くなら

1.健康

2.パートナーとの時間や関係

3.コントロールできる時間、または自分らしく居れる時間の割合

4.場所の自由(ビザや永住権など、働く場所に制限を受けない状態)

5.経済的自由

6.社会貢献(ボランティアという意味ではなく、仕事の延長で価値を提供し、貢献したい)

という感じです。

具体的に深掘りすると4,5,6は結局のところ自身のskillsetの向上と成長に言い換えられます。なぜなら、場所の自由を達成するには雇い主にvalueを提供する必要があり、その価値をわからせる必要があり、経済的自由も自身の価値提供のreturnとしての結果だからです。6についても自身の価値提供の大小で貢献度が決まります。

なので、Essayを書く過程で上の6点がここうなります。

1.健康

2.パートナーとの時間や関係

3.コントロールできる時間、または自分らしく居れる時間の割合

4.自身のskillsetの向上と成長

 

もう少し深掘りすると、3について、これは勤務時間を短くするわけではありません。例えば、もし仕事の内容が単純に趣味の延長だった場合、それは自分らしく居れる時間に含まれ、好きなことをしているので、自分の幸福に貢献します。

つまり、どれだけ他者貢献ができても、どれだけskillsetの向上に繋がっても、それが自分が勤務外でも進んでやりたいと思えないのであれば、その時間は義務となってしまいます。

詰まる所、MBA卒業後、Finance、VC、PrivateEquityの世界に行けたところで、それらの時間は自分が勤務外でも進んでやりたいと思えないので、What matters most to youに関係ないことがわかってしまいました。

 

今の技術職については、自分はやはり物作りが好きなので、この”What matters most to you”の自分の価値観に一番近いので、引き続き日々精進していきます。

他の言い方をすると、独立して何か物作りをすることもこの価値観に沿ってはいるので、いづれは独立も視野に入れておこうと考えさせられました。それにMBAが必要かどうかは答えは出ていません。Networkingという観点で見ればアリでしょうが、costがpayしないだろうというのが今の気持ち。Tech系のnetworkingは他にもあると思うので、一つのことに固執せず、自分の価値観に沿ってこれからも活動していくと思います。

当時はこのessayが書けず悩んでいましたが、今では書けなくて正解だったかもとも思います。

 

 

 

Redshiftで他システムと連携する方法 3つ【勉強メモ】

技術 仕事・退職

今までは個人ではGCPを良く使っていたのですが、AWS Redshiftについて、ここ最近学ぶことが多かったので、備忘録として残しておこうと思います。分かったことは、これという正解がない（複数の正解がある）ことがわかったということです。

 

そもそもRedshiftとは。そしてRDSとの違い

    • Redshiftは、大容量のデータを高速に解析・クエリすることが可能で、主に、大量の業務データから、複雑な分析やビジネスインテリジェンス（BI）に使用したい。
    • Redshiftは、カラムベースのストレージ方式を採用していて、高い圧縮率とクエリパフォーマンスを提供。また、複数のノードからなるクラスタ構成でスケーラブルな処理能力を持っている。

ここから本題

自分のAccountでRedshiftを持っているとする。他のAWS accountのRedshift(または別region)にデータを渡したい場合はどの選択肢があるか?

  1. COPYコマンドを使用する：
    • 自分のRedshift ->
      自分のs3 (相手のaccountにアクセス許す)->
      相手のaccountでs3からRedshiftにcopy
    • COPYコマンドを使用して、データを一括でエクスポートおよびインポートする。
    • ソースRedshiftクラスタからデータをエクスポートし、その出力データをS3に保存する。
    • ターゲットRedshiftクラスタでCOPYコマンドを使用して、S3からデータをインポートします。
    • この方法では、データの一括転送が可能ですが、データの一貫性や遅延に関する考慮が必要です。
    • Pro: シンプルでわかりやすい。自分のaccount内でcopyコマンドだけを実行するGlueJobまたはLambdaを作って、毎日決まった時間にスケジューリング可能。
    • Con:リアルタイムではない。相手が何らかのtransform必要な場合は追加でRedshiftの中でストアドか、s3からRedshiftの間にGlue Jobなど挟む必要あり。自分のRedshiftのschemaに何らかの変更があった場合、相手にいちいち連携する必要がある。よくこれで問題をみてきた。相手と自分で複雑な処理が必要な時はあまり向いていない。
    • まとめると、この方法だけでもさらに複数のパターンがあって、便利。
    • 1-1:Redshift (A)->S3(A)->copyしてRedshift (B)、つまり物理データを持つ
    • 1-2:Redshift (A)->S3(A)->copyせずGlueCrawlerでS3(A)の新しいデータを認識する。その後、external tableとしてaccess Redshift (B) 、つまり物理データを持たない
    • 1-3:Redshift (A)->S3(A)->何らかのtransformation->S3(B)->copyしてRedshift (B)
  2. クロスアカウントアクセスを設定する：
    • ソースAWSアカウントとターゲットAWSアカウント間でクロスアカウントアクセスを設定します。
    • ソースRedshiftクラスタのデータを、ターゲットRedshiftクラスタに直接クエリやデータの転送を行うことができる。
    • 注意として、自分はexternal schema を作る必要がある。

    • 例)
      GRANT USAGE ON DATABASE sales_db TO Bob;

      CREATE EXTERNAL SCHEMA sales_schema FROM REDSHIFT DATABASE sales_db;

      GRANT USAGE ON SCHEMA sales_schema TO GROUP Analyst_group;

    • Pro:相手が直接自分のRedshiftにアクセスできるので、リアルタイムかつ自分のすることは少ない。特定のスキーマだけアクセスを設定することも可能。
    • Con: アクセス権限(Viewを作るなど)とセキュリティに注意する必要がある。
    • 公式ドキュメント: 

      https://docs.aws.amazon.com/redshift/latest/dg/manage-permissions.html

    • Demo: 

      https://www.youtube.com/watch?v=FW63-BehQg0

  3. AWS Data Pipelineを使う

     

    • ソースとなるRedshiftクラスタからのデータエクスポートする。

    • Data Pipelineの定義ファイルで、ソースとなるRedshiftデータベースを指定。
    • エクスポート活動（ExportActivity）を定義し、ソースデータベースからデータを抽出し、一時的なデータストア（例：S3バケット）にエクスポートします。

       

    • 目的のRedshiftクラスタへのデータインポート:

      インポート活動（ImportActivity）を定義し、データのターゲットとなるRedshiftデータベースを指定します。
    • インポート活動のパラメータで、エクスポートされたデータの場所（S3パス）を指定。
    • 必要に応じて、データのマッピングや変換を行うために、データ変換活動（DataTransformActivity）を定義することもできます。

    • スケジュールの設定:

      Data Pipelineの定義ファイルで、エクスポート活動とインポート活動を含むパイプラインを定義します。
    • タスクスケジュール（例：毎日、毎週、または特定の日時）を設定して、パイプラインを実行する頻度を指定。

方法1) のcopyコマンドの自動化と方法3)のdata pipelineはどっちがいいのか。

人によって意見が分かれるかもしれませんが、自分の意見として、data pipelineではRedsihft->S3->Redshift間でデータストラクチャーのマッピングを定義できたり、追加のtransformationを加えられるので、柔軟。ただ、これは方法1-3のように、間にGlueJobやlambdaなど自分で追加処理は追加できるので、あまり柔軟性の軸で判断する意味はないと感じる。

どちらのoptionもLogとmonitoringを有効化すればcloud watchでアラートも設定できますし、あまり差は感じません。

個人的には、あまり言葉を選ばずに言えば、結局のところ、コストと速さをbench markingしてみて、あとは自分が慣れているものを使えばいいのではと思う。

まとめ

Cloudのプラットフォーム(AWS, GCP, Azure)の世界はどんどん便利になっていて、とてもありがたいですし、開発者の皆様に感謝しています。