早いもので、今年もうもう終わりですね。
様々な事件のあった2018年ですが、今年を象徴するニュースといえば、5月1日のCloud Composerのベータリリースでしょう。
という訳で、Cloud Composerに関して（よくドキュメント見ると書いている）注意点を書いてみました。
DAGのタスクでない部分に重たい処理を書かない
Cloud ComposerというよりAirflowのプラクティスですが、DAGパース時に読み込まれる部分（i.e. タスクでない部分）には
- パースするwebserver（GAE）はマシンタイプを指定出来ない
- 重たすぎるとDAG読み込みが失敗する
ため、重たい処理を書かない方が良いらしいです。
DAGのタスクでない部分からの、外部アクセスに気をつける
また、webserver部分とworker部分でサービスアカウントが違います（workerがGKE、webserverはGAEで動いてます）。
そのため、（可能なら）プライベートなデータへのアクセスは使わない方が良いらしいです。
GCSをマウントしているディレクトリに注意
https://cloud.google.com/composer/docs/concepts/cloud-storage
/home/airflow/dags、/home/airflow/data、/home/airflow/plugin、/home/airflow/logsの４つのディレクトリは、
Cloud Stroage Fuseという機能で、
- ワーカーからは、普通のディレクトリのように見える
- 実態はGCS上のディレクトリ
として扱えます。
気をつけないといけないのは、普通のディレクトリのように 見える ってだけで、ローカルのストレージではない点です。
詳しくは、tora470さんの記事などをご覧ください。
アラートメールの出し方に注意
Airflowには、DAG Runが失敗した時にメールを出す機能があります。
が、Cloud Composerではsmtp_passwordで認証するSMTPサービスが利用出来ないので、ご注意ください。
ドキュメント記載のSendGridを使用推奨のようです（Googleの中のJamesさんの回答）。
バージョンに注意
https://cloud.google.com/composer/docs/concepts/versioning/composer-versions?hl=ja
何も指定しないと、Cloud ComposerのAirflowバージョンは1.9.0です（2018/12/17現在）。
Airflowのドキュメントの情報は1.10の場合が多いので注意しましょう。
Beta featuresを有効にすると、最新の1.10を使うことが出来ます。
（ドキュメントに無い？）PythonOperatorにも重たい処理を書かない
これは個人的に思う注意点です。
DAGのタスクでない部分に重たい処理書いちゃだめですが、PythonOperatorにも重たい処理を書くのは危ないかもです。
理由としては、
- Cloud Composerのアーキテクチャでは、workerとAirflowのシステム部分（Redis、Scheduler）が、同じクラスターで動くので、workerがメモリ使いすぎると、スケジューラーも不安定になる との報告がある
- 依存パッケージのインストールが面倒
- pip使えますが、デフォルトインストールと衝突したり、pure pythonでなかったりすると…
- すべてのAirflowWorkerにすべてのDAGの依存パッケージが必要（コンフリクトの危険が高まる…）
- namespaceを指定できるので、Airflowのシステム部分とのリソース競合を避けられる
- Docker imageで、より楽に環境・依存設定を行える
と思います。
世の中にはKubenatesOperator以外使うなという過激派もいるらしいです。
まとめ
（よくドキュメント見ると書いている）注意点、結構多いですね。
ドキュメントはよく読まないと…