【要約】Dagster Code Location Serverの監視システムの構築 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
EVERSTEELのデータエンジニアチームは、業務委託中心の体制である。そのため、システムへ常時張り付いて対応することは現実的ではない。既存の監視対象はdbtやDagster Daemon等に限定されていた。その結果、Code Location Serverの異常を検知できない課題があった。
- ・Code Location Serverの稼働状態が未監視。
- ・Pythonの構文エラーやインポートエラーを即座に検知できない。
- ・定義の更新時に発生するエラーへの対応が遅れるリスクがある。
// Approach
チームは、Webserverが利用するGraphQL APIを直接叩き、サーバーの状態を取得する手法を採用した。これにより、外部からCode Location Serverの評価結果を取得できる。
- ・AWS Lambdaを用いたバッチ実行型の監視サーバーを構築。
- ・VPC内のサーバーへ接続するため、LambdaをVPCに紐付け。
- ・GraphQLクエリ（workspaceOrError）でloadStatusを取得。
- ・EventBridgeで定期実行し、異常時はCloudWatch経由でSlackへ通知。
- ・Floci（AWSエミュレーター）を用いて、Lambdaのロジックを自動テスト。
// Result
開発者がDagsterの定義を更新した際、エラーがあれば即座にSlackへ通知される体制を整えた。これにより、エンジニアの検知タイミングが大幅に改善された。
- ・定義更新時のエラーを即座に検知し、迅速な対応が可能になった。
- ・導入後1ヶ月で3件の通知があり、実運用での有効性を確認。
- ・デプロイ直後のロード待ちによる誤検知が、今後の技術的課題として残った。
Senior Engineer Insight
> 運用負荷を最小化するためにLambdaとマネージドサービスを組み合わせた構成は、極めて合理的だ。GraphQL APIの直接利用は、UIに依存せず自動検知を実現する優れた解である。ただし、デプロイ時の過渡期における誤検知は、アラート疲れを招くリスクがある。CloudWatchの評価期間調整や、デプロイ完了を待つロジックの検討が、実運用における次のステップだ。