この記事は GMOペパボ エンジニア Advent Calendar 2025（🎅会場） の4日目の記事です。
オフィスとリモートのハイブリッドワークになり、オンラインミーティングをオフィスの自席でやることが増えました。GMOペパボは東京、福岡、鹿児島にオフィスが分かれています。チーム内外のメンバーも物理的に分散しているので、ミーティングは基本的に Google Meet でやっているのですが、自席だと周りの声が入るのが気になっていました。
Meet はノイズキャンセリング機能があって、キーボードの打鍵音などはキャンセルしてくれますが、周りで話していたり、同様にミーティングしている声を消すことはできません。同じオフィスから複数人がミーティングに参加する時はできるだけ会議室を使ってはいますが、常に空いているわけではないし、同じオフィスからのミーティング参加者が自分だけの時に会議室を使うのも気が引けます。そこで、自席でミーティングするためにコールセンターなどで使われているらしい Jabra のヘッドセットを買ってみました。
前に 記事 を書いた通り、Airflow で DAG 間の依存関係を扱う際は、下流の DAG が ExternalTaskSensor で上流の DAG の完了を待ち受けるのが良いと思っている。
この ExternalTaskSensor では、上流の DAG Run を一意に特定するために、上流の DAG ID と、上流の execution_date を得るための「下流と上流の DAG の execution_date の差（execution_delta）」または「上流の DAG の execution_date を返す関数（execution_date_fn）」を与える必要がある。
ただ、実用上は上流の DAG ID を指定するだけで直近の DAG Run を待ち受けるくらい簡単になってほしいので、次の通り PythonOperator と組み合わせてクラス化なりしておくと、 2 つの DAG の interval の大小関係に関わらず（ここが大事）、DAG からは上流の DAG ID を指定するだけで ExternalTaskSensor を使って依存関係を定義できるようになる。
ワークフローエンジンを運用していると、あるワークフローの完了後に別のワークフローを実行したい、という要求が出てくる。
Airflow では、DAG（ワークフロー）間の依存関係を扱う方法が以下の通り複数あるが、どの方法を選ぶのが良いのか一見分かりづらいように思う。1年くらい Airflow を運用して色々試した結果、自分のユースケースだとこれかなという方法が定まったので書いておく。
私物でメインマシンの MacBook Pro が 2012 年モデルで流石に厳しくなってきたのと、PC ゲームでやってみたいタイトルがあったのでゲーミング PC を組んだ。
研究所の輪読会で以下の論文を読んでいて、ネットワークにおける Assortativity という語句が出てきた。意味を知らなかったのでまとめる。
Cloud Composer へのワークフローのデプロイを簡単に行うために、Go で trinity というツールを作りました。
