본문 바로가기

D.S/DE

210130일 - airflow 작업 실패 기록?

728x90


작업 순서 수정

1. 도커파일을 빌드해서 도커를 앱의 환경설정에 먼저 맞추고 올리자.

  • 로컬에서는 airflow를 계속 올려서 사용하니까 다른 앱이 나오면 또 그 환경설정에 맞게 도커파일을 빌드해서 새로 띄워야 한다.
  • 쿠버네티스를 이용하면 worker가 필요할 때마다 pod를 띄워서 작업할 수 있는 듯. 리소스를 필요한 만큼만 사용하니 좋고 원하는 이미지를  사용해 pod를 띄울 수 있어 좋다.

2. 여러 작업들이 앱에 포함되어 있어서 계속 문제를 일으키니, 앱의 기능을 분리해서 airflow task로 넣어야 할 듯 (적어도 data나 log기록하는 부분은)


궁금한 점:

  • task1에서 env작업을 했음 → 그럼 연결되는 task2에서도 저 설정한 환경변수가 적용되어 있는가?
  • 한 dag에 설정되어 있는 task들은 같은 워커에서 작업되는지? 아니면 그냥 한 dag에 기술되어 있는 것에 상관없이 완전히 task 단위로 스케줄러가 worker에 랜덤하게 나눠주는지?




[210130일] 작업


작업은 그닥 순조롭지 않았다. 이런 단순한 구조인데도.


  • 슬랙으로 성공/실패 전달은 잘 되었음. (callback 처리) fail은 두렵지 않다. ㅋㅋㅋ

문제

  • 앱 환경설정이 포함되지 않은 디폴트 airflow를 사용하면서 생긴 문제
    • 가상환경(virtualenv)를 실행하고 거기에서 앱을 실행하는 쉘스크립을 실행하게 하려 하는데 가상환경이 제대로 동작 안 함.
    • 원 레포에 가상환경을 이미 만들고, 도커에 volume으로 연결해서 쓰는데 컨테이너 안에서는 가상환경이 동작을 안 함. 다시 컨테이너 안에서 설치해줘야 하고, 밖으로 나오면 그 env는 밖에서는 쓸 수 없음.
    • 근데 어떻게 보면 안 돌아가는게 당연한 건데 volume연결을 같은 path로 하고 같은 운영체제니까 되지 않을까?라고 넘겼다가... env 설정 path가 다르니.. (여기 파이썬 env 설명 좋음 )
    • 밑의 로그는 가상환경이 연결이 안 되서 패키지를 못 찾고 에러를 냄.
    • PythonvirtualenvOperator도 사용해봄 → 몽고db 관련 에러가 ㅠㅠ
[2022-01-30, 17:35:01 UTC] {subprocess.py:89} INFO -     selector, server_timeout, address)
[2022-01-30, 17:35:01 UTC] {subprocess.py:89} INFO -   File "/data/lucca/apps/apbot/env/lib/python3.6/site-packages/pymongo/topology.py", line 220, in _select_servers_loop
[2022-01-30, 17:35:01 UTC] {subprocess.py:89} INFO -     (self._error_message(selector), timeout, self.description))
[2022-01-30, 17:35:01 UTC] {subprocess.py:89} INFO - pymongo.errors.ServerSelectionTimeoutError: localhost:27020: [Errno 111] Connection refused, Timeout: 10.0s, Topology Description: <TopologyDescription id: 61f6cc2a38ee210e15fd8776, topology_type: Single, servers: [<ServerDescription ('localhost', 27020) server_type: Unknown, rtt: None, error=AutoReconnect('localhost:27020: [Errno 111] Connection refused',)>]>
[2022-01-30, 17:35:01 UTC] {subprocess.py:89} INFO -
[2022-01-30, 17:35:01 UTC] {subprocess.py:89} INFO - During handling of the above exception, another exception occurred:
[2022-01-30, 17:35:01 UTC] {subprocess.py:89} INFO -

  • 앱의 파일 logging 기능이 계속 fail을 냄. (로그기록한 파일을 앱 내 logs폴더에 저장)
    • logging config를 설정할 때 log 파일을 /tmp/{**_} 밑에서 찾으면서 파일이 없다고 함.
    • 로그에 찍히는 /tmp root 파일 위치를 바꾸면 되지 않을까 생각해봤는데 방법을 못 찾았음.
    • 앱 내에서 config 위치 변수도 다시 설정했는데 그것도 별 소용없음.
    • 구글링하면 저 tmp를 바꿀 수 있냐는 질문도 있긴 한데 별 도움되는 대답은 없었음
      • airflow how to change tmp root location로 검색
    • task run 시킬 때 —cfg-path 설정이 있음 : https://airflow.apache.org/docs/apache-airflow/stable/cli-and-env-variables-ref.html#
    • 그래서 로컬파일 logging을 다 주석처리하고 돌리면 괜찮음.

[2022-01-30, 19:00:01 UTC] {subprocess.py:62} INFO - Tmp dir root location: 
 /tmp
[2022-01-30, 19:00:01 UTC] {subprocess.py:74} INFO - Running command: ['bash', '-c', '\nbash /data/lucca/apps/apbot/start.sh']
[2022-01-30, 19:00:01 UTC] {subprocess.py:85} INFO - Output:




그래서 재작업시에

  • 앱 환결설정이 포함된 도커파일을 빌를 먼저 하고,
  • 여러 작업들이 앱에 포함되어 있어서 하나를 계속 문제를 일으키니, 앱의 로그 기능을 분리해서 airflow task로 넣기로 함


만약 에어플로우를 통해 글발행 파이프라인을 만드려면 기능들을 분리해서 task로 올릴 수도 있을 것 같고..적어도 계속 문제를 일으키는 logging 기능만이라도 따로 task로 분리를 해야되지 않을까 생각이 든다.
task로 분리할 수 있는 앱 내 작업들? 전부 작업하기엔 또 해체해야 하서 일단 로그만이라도.

  • 글 가져오기
  • 글 정제
  • 정제된 데이터 저장
  • 글발행
  • 로그 저장


반응형