PyCon SG 2019にてApache Airflowについて発表しました
4月にPyCon APAC 2019で発表した時の記事を公開しましたが、今回は、地元シンガポールで2019年10月に開催されたPyCon SG 2019で発表しましたので、その際の模様を共有します。
前回、PyCon APAC 2019に参加した時の記事はこちら良ければご覧ください。
PyCon SG 2019での発表の模様
主催であるPyCon User Group Singaporeの皆さんが、発表時の動画を公開してくさってます。非常にありがたいです。
発表資料はこちらです。
発表の動機 = 地元シンガポールで発表したい！
現在、シンガポール在住なので、シンガポールで発表したいと思っていました。 PyCon APAC 2018がシンガポール開催だったので、2019もシンガポールで！と思っていましたが、実際はマニラ開催だったので、ようやく家の近所のイベントに参加できて大助かりです^^
発表の概要 = AWSとGCPの両方でAirflowを使った場合の違いを紹介
APACでの発表時は、AWS上でAirflowのクラスタを構築して、初めて本番環境でAirflowを使い始めた時のことを紹介しました。 今回は、当初、APACで質問を受けたSparkとの連携について話するつもりで申し込みまでしましたが、実際はここ最近、Sparkを全く使わなくなったので、タイトルをイベント開催前に変更しました^^;
最近はもっぱらGCPでAirflowを使っており、バッチ系のパイプラインはComposer（Airflowのマネージドサービス）で、ストリーム系はDataflowを使っています。
そういう背景もあり、Airlowの簡単な紹介をした後は、AWS上で自作クラスタを構築・運用してた時の経験、GCP上でマネージド・サービスを使った場合との比較を紹介しました。個人的には、データエンジニアリングをやる上では、インフラ周りはマネージドサービスに移譲できて、ビジネス価値に専念できて、GCPの方が楽だという感想です。
発表後の質疑応答では、Airflowそのものの質問というより、Airflowをどうやってデプロイするか、可用性の高いクラスタを構築するか、という話ばかりでした。発表が終わってからも10人くらいに囲まれて質問者もまじえての議論をしてました。皆さん、十分なインフラエンジニア・DevOpsエンジニアが確保できず、苦労しているんだなという印象でした ^^;
自分でやる余裕がない、スキルが足りない人には、GCPのCloud Composerを使うのが楽だと思います。
余談：gihyoの参加レポートに登場してました！
イベント前の日本人懇親会（元PyCon JPスタッフ同窓会も兼ねている）からPyCon SG 2019のイベントの模様まで、PyCon JPスタッフの鈴木さんが記事を公開されています。私も登場しています。ありがとうございます。
Discussion