Apache Airflow でタスクスケジューリングしてみた ～ログを退避させる～

外部データベースに切り替えて負荷分散とリスク回避を行う

前回までは実際に開発した経験からAirflowのジョブ作成について説明しました。暫くしてから運用関係のご報告を…っと考えていたのですが、本番稼働してまだ1ヵ月ちょっとですが早くも問題が出てきたのでAirflow運用関係のノウハウをご説明します。

Airflowのログは溜まりやすい

現在、Airflowで1つのジョブを短い間隔で実行し、リアルタイムバッチ処理を行っているのですが、いつの間にかディスクの空き容量が意外となくなっていることに気づきました。原因を探したところ、Airflow内のローカルデータベースとログフォルダに大量のログが記録されいる事が分かりました。特にログファイルはジョブ内のタスクごとに分かれて吐き出され、ログの中にはAirflowのデバック情報も出力されているため、それなりの容量ログが大量に吐き出されていました。

とりあえず、リアルタイム性の必要がないタスクはジョブから独立させて、別ジョブに固めて低頻度で稼働させることにより、ログの出力量は減ったのですが、それでもディスクフルでサーバーダウンする恐れがあるためログを退避することにしました。

外部データベースに切り替える

Airflowではジョブ（DAG）の定義情報、variablesやconnectionsなどの設定値、ログなどをAirflow管理用のローカルデータベースに保存しています。ローカルデータベースはAirflowの初期設定で「airflow initdb」をコマンド実行することでSQLiteのデータベースファイルが作成されます。

SQLiteは簡易データベースでAndroidアプリの記憶システムとして使用されている動作が軽いデータベースですが、データ量が多くなると遅くなったり、バックアップの機能がないなどデータベースとして弱い部分もあります。そのため、Airflowの管理用データベースをちゃんとした外部データベースに切り替え、負荷分散とリスク回避を行います。

今回は外部データベースとしてMySQLを選択しました。Airflowの標準インストールではMySQLに接続できないため、初めに以下のコマンドのいずれかでパッケージを追加します

次に外部データベースへの切り替え方法はAirflowの設定ファイル（airflow.cfg）の「sql_alchemy_conn」を書き換えるだけです。その後、「airflow initdb」コマンド実行すれば切り替え先のデータベース内にテーブルが作成されます。

古いログはクラウドストレージに退避させる

ログファイルはAirflowの設定ファイルの「base_log_folder」に指定されたフォルダに出力されています。ログファイルはAirflow全体のログが日単位、ジョブ中のタスクのログが実行ごとにファイルが分かれて保存されています。

Airflowの設定ファイルの「remote_base_log_folder」や「s3_log_folder」を使うことで、ログファイルのバックアップを Google Cloud Storage や Amazon S3 のクラウドストレージにバックアップを取れるようですが、ローカルストレージ上のログファイルの世代管理（古いファイルは消すなど）まではやってくれそうもありません。

そこでAirflowメンテナンス用のジョブ（DAG）を作成して、定期的にログフォルダの中のある程度古いログファイルはクラウドストレージに移動するようにしました。

GCP上でAirflowを運用中です

上記のAirflow運用をGoogle Cloud Platform（GCP）の Compute Engine、Cloud SQL for MySQL（以下、Cloud SQL）、Cloud Storage を使用して運用中です。Cloud SQL は記憶容量によってディスクを最大10TBまで自動拡張してくれますし、Cloud Storage は記憶容量無制限ですのでディスクフルを心配する必要はなくなります。

また、Cloud SQL は、サービスの単位がデータベースサーバーのため、複数のデータベースを作成すれば、複数のAirflow環境を1台の Cloud SQL で運用できるため運用コストはそれほどでもありません。（Cloud SQL のdb-g1-smallで約$50/月で運用できます）

連載：Apache Airflow でタスクスケジューリングしてみた

• Airflowによって開発負荷が変わる
• 公式ドキュメントの読み解き方
• タスク開発のポイント
• ログを退避させる（本編）