※ このブログはヌーラバー Advent Calendar 2020 6日目の記事です。

こんにちは。インハウスシステム課の大塚です。「管理部」所属の社内エンジニアとして活動しています。

私達の大きなミッションは以下の二つです。

• 社内の業務プロセスの定義、改善、自動化という業務ハックを推し進める
• 社内のデータ分析、活用、及びデータマネジメントを推し進める

この活動は企業が成長していく上でとても重要ですが、残念ながら大きくリソースを割り当てることはできません。

私達は小さなチームの限られたリソースでこのミッションを達成するため、AWSサービスをどのように選定して、活用していくかについて、その方針を事例と合わせながら書きたいと思います。

TL;DR

• 社内エンジニアがAWSサービスをマネージドなサービスを導入する理由
  • 企業の成長で課題は増えていく
  • 目的達成のために注力する
• Airflowを運用していく中で再確認した思い
  • 運用コストはサービス利用コストを上回ることがある
  • サーバレス、マネージドサービスの価値

利用しているサービス

インハウスシステム課では、業務システム、データ分析基盤、業務ハックのためのスクリプトなどの保守、管理を行っています。

業務システムでは、Fargate、Elastic Beanstalk、データ分析基盤では、Glue、Athena、S3、QuickSight、業務ハックスクリプトでは Lambda などの様々な AWS サービスを利用しています。

私達のチームにはインフラやシステム運用の先任者がいません。そのためここで挙げているサービス達は、どれも構築や運用を楽にするために選んだものがほとんどです。自前で構築することを極力避け、目的達成のために課題に注力できるように選定しています。

現在はデータ分析基盤の改善していくことが多いです。そんな中でもOSSのワークフローエンジンである Airflow を構築、運用していく中で、どのように改善が必要だったかについて紹介させて頂きます。

ちなみにAirflow では、色々なリソースから定期的にデータをデータレイクに収集し、データウェアハウス、データマート などの更新を行ったり、Backlog の課題更新イベントを元にバッチ処理を実行したりなど様々なワークフローを動かしています。

※Airflow の詳細については、公式ドキュメントを参照ください。

Airflowの導入から運用

導入時

Airflow 自体は、Fargate 上で、かれこれ１年以上運用しています。

最初はオートスケールできない全部入りの1つの ECS サービスとして運用していました。データパイプラインのタスクをある程度並行実行できるようにしていたため、パイプラインが実行されていないときも無駄に高いスペックで起動し続けていました。

サービス利用コストは高くついていましたが、それでもパイプライン自体の要望も進めていかないといけないという状況でした。

オートスケール対応

次にパイプラインの開発要望に対応していると、パイプライン上で実行するタスク数も増えていきました。そうなってくると、並列実行数が固定されていたためタスク数の増加に応じて実行時間も伸びていきました。これを改善するため、並列実行するタスク数に応じてオートスケールするような対応を行いました。

結果として、パイプラインが実行されていないときのサービス利用コストは下がり、データパイプラインの実行時間も短くなりました。

その他の運用

オートスケールに対応して、サービス利用コストも下がったことで、またデータパイプライン作成の方にに注力できるようになりましたが、オートスケールを継続するための閾値の調整なども必要になります。Airflow 自体もバージョンアップなどに対応する必要があります。ECS 上で動作する Docker イメージ自体にも実行コードが含まれているのでコンテナイメージの管理もしないといけません。

運用してみて

Airflow をこれまで運用してみてデータパイプラインとしてもとても扱いやすいと思います。また提供される管理画面では、各タスクの実行状況、実行時間などを確認することもできますし、エラーログも容易に確認することができます。ただ、この Airflow をスケーラブルで安定して動くように改善していく時間を、データパイプラインを構築して改善していく方向に時間をかけられると理想的だなと感じました。

そしてフルマネージドへ

ここまで OSS の Airflow の運用について話をしてきましたが、なんと、なんと、遂に AWS からもマネージドサービスとして Amazon Managed Workflows for Apache Airflow (MWAA) がリリースされました🎉

フルマネージドなサービスのためスケール管理や、メトリクス管理、ログ管理などいい感じやってくれると思います。移行すればこれまで以上にデータパイプラインの作成に注力していける！？と期待も込めて検討していきたいと思います。

最後に

インハウスシステム課では、業務上の課題を解決するためにフルスクラッチで開発して構築・運用することは最終の手段だと考えています。そのため今回話をしたような特定の目的を達成するための OSS などは、ECS 上で簡単に構築できるものであれば今後も導入を検討していくでしょう。

ただそこにも導入や運用コストが発生します。特にスケーラビリティが求められるようであればさらにコストがかかります。それで本当に目的を達成するために注力はできるでしょうか。システムを開発、構築、運用するのはエンジニアとして面白いですが、マネージドなサービスを導入することを選択肢に入れてもう一度考え直してみるのも良いかもしれません。

実際にフルマネージドなサービスの導入を試算するとサービス利用コストは何倍にもなることもかも知れませんが、利用ユーザー数も限られていますしサービス規模としては大きなものにならないと思います。それらを運用し続けている内に企業は成長していきます。その時解決できた課題は、数年後にはそのシステムでは対応できなくなっているかも知れません。このようなシステムを複数抱えた状態で私達のミッションは達成できるでしょうか。難しいと思います。

特に社内エンジニアは限られた人的リソースで次々新しい課題に取り組んでいかなければなりません。そのために構築、運用コストが抑えられるマネージドやサーバレスのサービスを活用することが不可欠であると改めて感じました。

(それと次々出てくる新しいサービスを試す時間も確保したいですよね😁）

今回の話が何かのお役に立てれば幸いです。

インハウスシステム課ではAirflowと共に過ごしてくれるデータエンジニアを募集中です。