인프런 커뮤니티 질문&답변
작성한 질문수
python 코드 디버깅 문의
작성
·
48
답변 2
0
안녕하세요 min0님!
아쉽게도 아마도 min0님이 원하시는 수준으로 로컬에서 정밀하게 체크해서 오류를 예방하고 서버에 올리는 방법은 없을겁니다.
대신 어느정도 로컬에서 충분히 오류를 예방할 수 있습니다. 문법의 경우 IDE 툴로 어느정도 체크가 가능합니다. 아래의 (1)과 (2) 에서 설치한 라이브러리 목록을 비교하자면
(1) docker 로 올린 airflow 컨테이너들이 가지고 있는 라이브러리
(2) 우리가 로컬에 pip install apache-airflow[celery]... 명령으로 설치했을 때 설치되는 라이브러리
(1)과 (2)의 라이브러리 목록이 서로 다릅니다. 보통 (1)이 더 다양한 라이브러리가 설치됩니다.
대표적으로 pandas 라이브러리는 (1)에 기본 포함되어 설치되지만 (2)에는 설치돼있지 않습니다. 그래서 로컬 환경에서 IDE 툴로 개발하다보면 포함돼있지 않은 라이브러리는 인식하지 못해서 빨간줄 그어지기도 하죠. 그런것들은 별도로 pip install 명령으로 로컬에 설치해주시면 문법에러를 포함한 실수는 많이 줄일 수 있습니다. Airflow web에서 import 에러 뜨는 것들은 문법 에러이므로 IDE 툴만 잘 활용해도 import 에러는 많이 줄일 수 있습니다.
그 다음 정상적으로 import 잘 된 다음 실제 실행했을 때에도 문제없음을 보장하는 방법이 있을까?
이것은 사실 좀 어렵습니다. CLI 명령 중에서 airflow dags test 라는 CLI 명령이 있어서 이걸로 미리 수행해보고 (실제로 수행되지는 않음) 오류가 있는지 없는지 확인할 수는 있습니다. 하지만 우리의 실습 환경에서 이 명령을 수행하려면 컨테이너 내부에서 명령을 수행해야 하는데 이미 DAG작성을 마치고 git push를 마친 상태여야 합니다. 아마도 이 방식은 min0님이 원하는 절차는 아닐 것 같습니다 ^^
그래서 import 가 잘 된 이후에 실제 수행까지 잘 될것이냐의 여부는 사실 한번 돌려봐야 합니다. min0님이 질문주신 챕터를 보니 Template 문법을 사용하는 부분인데, Template 문법을 쓸 때 String 형태로 '{{ xxxxx }}' 이런식으로 작성하다보니 저 string 부분이 정상적으로 인식될지 안될지 여부는 실제 돌려볼 수 밖에 없습니다.
현업에서는 보통 개발 서버와 운영 서버를 분리해서 운영하므로 개발에서 테스트해보고 완성된 dag을 운영 branch에 넘깁니다. (물론 이 방식이 쉽지는 않습니다. 개발과 운영 데이터가 서로 다르기도 하고 운영에 필요한 소스나 타겟 시스템 정보들을 개발에도 똑같이 방화벽/계정 등 뚫어야 하는 기반 작업이 필요한 일입니다)
결론적으로
DAG import 에러 뜨는 것을 방지하는 것은 IDE 툴에 의존해서 최대한 문법 에러를 줄인다.
Import 가 잘 된 이후에는 실제 한번 수행해봐야 알 수 있다.
정도로 정리하면 될까요?
오 좋은 질문입니다!
보통 현업에서 운영 환경에 airflow 를 셋업하면, 예상하는 dag 수나 부하에 따라 다르겠지만 실습 환경처럼 단일 서버에 container로 구성하지는 않습니다. 다만 container 대신 k8s의 pod를 이용해서 구성하는 경우는 많습니다.
제가 경험해본 설치 형태는 크게 2가지였는데
k8s 환경 (GCS의 GKE)에 스케줄러와 워커를 pod로 구성하고 Celery Executor를 쓰는 형태 --> 부하 증가시 워커 pod 를 늘리면 되므로 부하 대응이 쉬운 편
온프레미스 서버 형태에 스케줄러 노드 N대 + 워커 M대 구성하고 Celery Executor를 쓰는 형태 --> airflow 전용 노드를 구성해서 쓰는 방식으로 관리가 쉬운 편
참고로 1번 형태에서, GCP의 GKE를 쓰면 워커노드는 EC2같은 워커노드에 구축됩니다. 그래서 min0님께서 언급하신 EC2 에 컨테이너(pod)가 올라가는 구조라 볼 수 있습니다.
2번 형태 같은 경우 Celery Executor 를 쓴다고 가정했을 때 스케줄러와 워커 외 요소(웹서버와 Redis)를 어떻게 구성할지는 자유자재로 구성하면 됩니다.
예를 들어 워커 서버3대에 Redis Cluster 도 같이 구성해서 쓴다든지 스케줄러 노드에 웹서버도 같이 띄운다던지 그런 구성이 가능하고 컨테이너가 아닌 프로세스로써 구성하면 됩니다.
그리고 언급하신 AWS의 MWAA 서비스나 GCP의 Cloud Composer를 써도 장점도 많지만 클라우드 서비스의 제약을 강하게 받는다는 단점이 있습니다.
예를 들어 어느 수준 이상으로는 로그 디버깅이 쉽지 않고 심지어 버전이 오래되면 단종되니 업그레이드를 일정 기간 내 하라고 강제하기도 합니다. 저는 아직 MWAA에서 운영해보진 않았어요 ^^
답변이 충분했을까요?
0
안녕하세요, 인프런 AI 인턴입니다. min0님.
Python 코드로 Airflow DAG을 작성할 때, 사전 디버깅을 통해 오류를 최소화하는 것이 매우 중요합니다. 일반적으로 Airflow DAG의 디버깅은 코드 작성 후 에러 발생 시에 시작되지만, 사전에 아래 방법을 통해 디버깅을 할 수 있습니다.
Local Python 환경에서 문법 오류 체크: 코드를 작성한 후에는 항상 기본적인 문법 오류를 체크하는 것이 좋습니다. Visual Studio Code 같은 코드 에디터에서는 실시간으로 문법 오류를 감지할 수 있는 기능이 있습니다. Python 파일에서 어떤 오류라도 나타나면 이를 먼저 수정하세요.
Unit Test 작성: DAG에 포함될 Python 함수를 별도로 테스트 가능하게 작성하고, unittest 모듈 등을 활용해 단위 테스트를 진행하는 것도 좋은 방법입니다. 이렇게 하면 작은 부분에서부터 오류를 확인할 수 있습니다.
Airflow CLI 사용: 로컬에 Airflow를 설치한 후
airflow tasks test <dag_id> <task_id> <exec_date>명령어를 사용하여 개별 태스크를 테스트 할 수 있습니다. 이는 실제로 DAG 실행 환경에서 돌아가지만, 전체 DAG 런타임에 영향을 미치지 않으므로 빠른 디버깅에 도움이 됩니다.로컬 설정 사용: Airflow는 Docker와 같은 도구를 통해 로컬에서 실행할 수 있습니다. 이를 사용하면 실제 서버 환경과 별개로 안전하게 테스트해볼 수 있습니다. 이는 웹서버에 반영 전에 여러 가지 작은 문제를 파악하는 데 도움이 됩니다.
코드 리뷰 및 협업: 마지막으로, 가능한 경우 다른 사람과 코드 리뷰를 통해 코드를 점검하는 것이 좋습니다. 본인이 놓칠 수 있는 문제를 다른 시각에서 파악할 수 있습니다.
이 외에도 아래 유사한 질문과 답변을 통해 보다 상세한 내용을 확인하실 수 있습니다:
- Airflow의 디버깅 방법에 대한 자세한 설명에서는 Airflow 환경에서의 디버깅 기법에 대한 다양한 정보를 얻을 수 있습니다.
사전에 이러한 방법들을 활용하시면 DAG 디버깅에 큰 도움이 될 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
상세한 답변 감사합니다.
pip install 했을때 , 로컬환경과 airflow 설치된 라이브러리가 다른걸 인지하였습니다.
webserver dag 오류 대부분 라이브러리 호환 문제가 대부분입니다.
말씀하신대로, indent와 같은 문법적인 오류는 IDE에 의존하여 사전 검사후 git에 반영하고 있습니다.
+ 추가적인 질문은
AWS EC2에 docker 이미지를 설치하고 webserver 및 기타 컨테이너를 올리는것이 일반적인지에 대한 질문입니다.
aws 자체적으로 MWAA 서비스를 제공중인것으로 알 고 있습니다.
그러나 해당 서비스를 이용하지않고 기존 EC2에 airflow 서버를 설치하여 배치 스케줄링을 운영하는것이 가능한지에 대한 궁금증입니다.
현재의 수업 커리큘럼이 로컬에서 server를 띄우고 ETL 해오는 것이지만,
"실제 EC2 인스턴스에 웹 애플리케이션을 운영중이고 특정 서브넷에 ETL을 위한 별도의 인스턴스를 구축한다"는 가정하에 질문을 드립니다.
수업과는 무관한내용으로 꼭 답변하시지 않으셔도 괜찮습니다.
감사합니다 .