쫄보의삽질 블로그

Airflow 3.0.1 remote logging 에러 해결

쫄보삽질러 — Sun, 25 May 2025 11:57:23 +0900

기존 2.10.3 버전을 사용중이던 Airflow를 3점대 버전으로 업그레이드 하는 과정에서 마주한 에러해결 과정을 공유해봅니다.

⚙️ 개발 환경
airflow를 ECS에서 멀티클러스터로 구축했습니다.

api-server
scheduler
dag-processor
worker(CeleryExecutor)
redis

Airflow UI에서 DAG 실행을 하면
1. DAG run이 생성이 되고 metadata DB에 queued 상태로 저장됨
2. dag-processor가 DAG를 파싱하고 DB내 DAG의 metadata 업데이트 함
3. Scheduler가 DB를 감지하고 있다가 queued task 정보(DAG ID, task ID, execution date, etc.)를 redis에 메세지로 보냄
4. 이 task는 Celery worker가 가져가서 작업할 수 있게 "available" 상태가 됨
5. Celery worker는 redis 큐에서 task 메세지를 가져가서 실행하고, DB에 running 상태로 업데이트 함
6. 작업 종료 후 DB에 task 상태를 success/fail로 업데이트하고 이후 작업이 남아있다면 Scheduler가 다시 체크하는 식의 반복

이러한 프로세스로 DAG가 실행되는데, 5번 worker가 작업을 실행하면 로컬 경로에 로그파일을 저장합니다.
하지만 컨테이너 기반의 서비스를 운영할 때의 문제점인 특정 서버 의존성을 방지하기 위해
"중앙 집중식 로그 저장"인 s3 remote logging 방식을 사용하려고 합니다.

이 때 로그 저장 및 read 프로세스는
1. airflow.cfg에 remote_logging = True 를 설정했다면 retmote logging에서 read 먼저 시도
2. remote logging이 실패해서 읽어들이지 못한다면, falls back to local 로컬 경로에서 읽기 시도

다음은 remote logging 설정 방법입니다:

# airflow.cfg
remote_logging= True

remote_log_conn_id = s3_conn
remote_base_log_folder = s3://airflow-logs # 로그 저장할 버킷 경로

delete_local_logs = False # 로그 삭제는 기본으로 허용하지 않음
remote_task_handler_kwargs = {"delete_local_copy": true} # remote logging에 성공했을 시 로그 삭제

remote_log_conn_id에는 airflow connections에 추가할 변수명을 입력하고 airflow connections에도 다음과 같이 추가합니다.

--airflow CLI
airflow connections add 's3_conn' --conn-type 'aws' --conn-extra '{"region": "ap-northeast-2"}'

*airflow 2.x 버전에서는 conn-type이 's3'였지만, 3점대 부터는 'aws'로 변경해줄 것
AWS IAM role을 사용하면 직접 Access Key와 Secret Access Key를 사용하지 않아도 됨으로 보안상 안전함!

위와 같이 설정을 하고 난 이후에도 DAG task를 실행하면 계속 fail이 났는데 에러를 보면,

# UI 실행
::group::Log message source details: sources=["Could not read served logs: Invalid URL 'http://:8793/log/dag_id=init_test_3.0.1/run_id=manual__2025-05-22T01:53:43.876152+00:00/task_id=print_time/attempt=1.log': No host supplied"]

# webserver container cli
- test/success
details: sources=["Could not read served logs: HTTPConnectionPool(host='ip-172-XX-X-XXX.ap-northeast-2.compute.internal', port=8793): Max retries exceeded with url: /log/dag_id=init_test_3.0.1/run_id=manual__2025-05-22T02:23:08.251172+00:00/task_id=print_time/attempt=1.log (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xffff795e7080>: Failed to establish a new connection: [Errno 111] Connection refused'))"]

- trigger/fail
details: sources=["Could not read served logs: Invalid URL 'http://:8793/log/dag_id=init_test_3.0.1/run_id=manual__2025-05-22T02:23:51.280531+00:00_chCfWUle/task_id=print_day/attempt=1.log': No host supplied"]

# worker container cli
- test/success
details: sources=["Could not read served logs: 404 Client Error: NOT FOUND for url: <http://ip-172-XX-X-XXX.ap-northeast-2.compute.internal:8793/log/dag_id=init_test_3.0.1/run_id=manual__2025-05-22T02:27:10.433362+00:00/task_id=print_time/attempt=1.log>"]

- trigger/fail
details: sources=["Could not read served logs: Invalid URL 'http://:8793/log/dag_id=init_test_3.0.1/run_id=manual__2025-05-22T02:27:45.665350+00:00_QmabUKOl/task_id=print_time/attempt=1.log': No host supplied"]

UI에서도 실행해보고, airflow cli로 airflow dags test와 trigger로도 실행해봐도
worker host를 찾지못하거나 connection error가 발생했습니다.

worker container 로그를 보면, task가 killed되어 죽는 것을 볼 수 있었고, 405 Method Not Allowed 에러를 발견했습니다.
또한 컨테이너 logs/ 경로 아래에도 보면 로그 파일은 쌓이지만, 빈 로그 파일이었기 때문에,
task를 실행하기도 전에 죽어서 task를 실행하지 못하고 있음을 볼 수 있었습니다.

또 다른 에러로는 scheduler container 로그에서 not_found in serialized_dag table 에러를 발견했는데
scheduler container log:

 ERROR - DAG 'init_test_3.0.1' for task instance <TaskInstance: init_test_3.0.1.print_time manual__2025-05-23T01:11:24.335987+00:00 [queued]> not found in serialized_dag table

해당 DAG를 찾지 못하는 것 같아서 DB에 serialized_dag 테이블을 확인해보면 DAG가 잘 저장되어 있었습니다.

그래서 refresh 차원에서 airflow db migrate와 airflow dags reserialize를 실행해 봤지만, 결과는 똑같았습니다..

그러다가!! 찾은 한줄기 빛!! ✨
https://github.com/apache/airflow/issues/50191

base_url gives state mismatch and task fail error. · Issue #50191 · apache/airflow

Apache Airflow version 3.0.0 If "Other Airflow 2 version" selected, which one? No response What happened? Recently, I upgraded Airflow from 2.10 to 3.0. I've deployed Airflow behind Nginx. I was ab...

github.com

airflow git issue로 올라온 비슷한 케이스를 발견하고 아래 방법을 시도해봤습니다.

✅ 해결 방안
처음 3버전으로 setting 후 dag를 실행했을 때 발생한 worker 에러가 있었는데,

AirflowConfigException: section/key [core/execution_api_server_url] not found in config

Airflow 3.0+에서는 CeleryExecutor를 사용하면 worker가 webserver에 호출될 때 execution API endpoint로 호출되므로,
API가 아래와 같이 airflow.cfg에 추가가 되어야 합니다:

[core]
execution_api_server_url = http://<your-webserver-host>:8080

그래서 처음 초반에 <url>:8080으로 설정해놨었는데
default(주석처리)라면 endpoint path에 <base_url>/execution/ 이 붙겠지만,
custom하게 설정하면 뒤에 /execution/을 붙여주어야 했습니다.

[core]
execution_api_server_url = http://<url>:8080/execution/

그래서 제가 마주한 에러를 순서대로 나열하자면, 이렇게 정리해 볼 수 있을 것 같습니다.
host not found > scheduler mark task state fail > no worker instace recorded> scheduler log not_found in serialized_dag table

에러 해결 과정에서 등록한 github issue도 공유합니다!
https://github.com/apache/airflow/issues/50866

remote logging for s3 fails while still looking for internal logs · Issue #50866 · apache/airflow

Apache Airflow version 3.0.1 If "Other Airflow 2 version" selected, which one? No response What happened? After upgrading to airflow 3.0.1, remote logging is not working as intended. I have set air...

github.com

- 이상 오늘의 삽질일기 끄읏

여기저기 삽질도 해보고
날려도 먹으면서
배우는 게
결국 남는거다
- Z.Sabziller

Crontab 설치가 실패한다면? 마지막 줄에 줄바꿈 체크하기!

쫄보삽질러 — Sun, 5 Jan 2025 15:43:06 +0900

-바쁜 현대인들을 위한 한 줄 summary-

‘newline before EOF’ 오류 해결: 줄바꿈 문자 확인하기"

crontab을 docker container에서 실행하기 위해

아래의 명령어를 Dockerfile에 추가하고 image 빌드하는 순간,

RUN crontab -u airflow /opt/crontab.sh

* /opt/crontab.sh 파일을 "airflow" user의 crontab(cron 잡)으로 설정하기 위한 명령어

다음과 같은 에러가 발생했습니다.

> [4/9] RUN crontab -u airflow /opt/crontab.sh && chmod u+s /usr/sbin/cron: #6 0.344 new crontab file is missing newline before EOF, can't install. ------ executor failed running [/bin/bash -o pipefail -o errexit -o nounset -o nolog -c crontab -u airflow /opt/crontab.sh && chmod u+s /usr/sbin/cron]: exit code: 1

즉, crontab.sh 파일에 줄바꿈 문자가 빠져있음을 의미하고,

맨 마지막줄에 띄어쓰기(엔터)를 해주면 깔끔하게 해결쓰.

또 다른 방법으로는,

RUN echo >> /opt/crontab.sh

1. cron job 스크립트 파일에 빈 줄을 추가해주거나

RUN sed -i -e '$a\' /opt/crontab.sh

2. 파일 마지막에 newline이 있는지 체크하고 없으면 추가하는 방식

으로 해결할 수 있는데, crontab이나 JSON, Dockerfile과 같이 명령어의 구조가 명확한 파일 타입의 경우

2번을 더 추천드립니다!

여기저기 삽질도 해보고

날려도 먹으면서

배우는 게

결국 남는거다

- Z.Sabziller

python multiprocessing Pool을 활용한 데이터 병렬 처리

쫄보삽질러 — Sun, 8 Dec 2024 21:59:51 +0900

배경

tfidf 추천 모델의 cosine 유사도 추출 후 추천 결과를 뽑기 위한 단계에서

16만건의 유저 데이터를 처리하기 위한 분산처리 및 최적화가 필요했습니다.

해결방법

python의 threading은 GIL(Global Interpreter Lock) 기능 때문에 병렬처리가 어려움으로

여러 작업을 효율적으로 병렬 처리할 수 있는 방식인 multiprocessing.Pool을 활용했습니다.

https://ninano1109.tistory.com/294

multithread vs multiprocess (feat. Process, Pool 비교)

멀티스레드와 멀티프로세스는 모두 데이터 병렬처리를 위한 python 모듈로 약간의 차이점과 용도별 차이가 있습니다. 스레드 vs 프로세스스레드하나의 프로세스 안에 여러개의 스레드 존재4가지

ninano1109.tistory.com

Pool의 장점으로는:

1. 미리 지정된 수의 프로세스 생성 후 프로세스 풀에서 작업 처리

2. 작업이 완료된 프로세스는 다시 풀에 반환되어 작업을 재실행하므로 프로세스 풀의 재사용

3. 배치 작업 시 유용하며 효율적인 자원 사용이 가능하며

4. 이 모든 프로세스를 자동으로 관리해줌이 있습니다.

def process_chunks(data, num_processes, chunk_size=3000):

results = []

with mp.Pool(processes=num_processes) as pool:

for i in tqdm(range(0, len(data), chunk_size)):

chunk = data[i:i + chunk_size]

for result in pool.imap_unordered(work, chunk):

results.append(result)

pool.close()

pool.join()

return results

Pool을 사용해 병렬 작업을 위한 함수를 만들어줍니다.

1. 먼저 병렬처리를 위해 데이터를 청크 사이즈 3000으로 나누어 전체 데이터를 3000개씩 쪼개어 작업을 병렬로 처리합니다.

2. mp.Pool로 멀티프로세싱을 위한 풀을 생성하고 num_processes 수 만큼 프로세스를 병렬로 생성하여 작업을 처리합니다.

3. 청크 사이즈로 쪼갠 데이터를 pool.imap_unordered를 사용하여 병렬로 work 함수를 실행 후 결과 값 results에 저장합니다.

* imap은 한 번에 모든 데이터 처리하지 않고, 필요한 시점에 결과 생성 => 대용량 데이터 처리 시 메모리 사용 최적화!

4. 더 이상 추가 작업이 남아 있지 않다면 pool을 종료하고, pool.join()으로 모든 프로세스가 끝날 때까지 기다립니다

def work(user_pair):

user = user_pair[0]

top_view_list = user_pair[1] #Top 5

# 해당 user가 조회한 전체 item

view_all_list = view_all_dict[user]

temp_list = []

for item in top_view_list:

try:

recomm_item = cosine_sim_df.loc[int(item)].drop_duplicates().sort_values(ascending=False)[:12]

recomm_item_list = list(zip(recomm_item.index, recomm_item)) #index = item, recomm_item = 유사도

# 추천 대상 item 중 본 item, 추천 대상 리스트 중복, 유사도 1 제외

final_recomm_list = [r for r in recomm_item_list if r[0] not in view_all_list and r[0] not in [t[0] for t in temp_list] and int(r[1]) != 1]

temp_list.extend(final_recomm_list)

except Exception as e:

pass

new_list = list(set(temp_list))

new_list.sort(key=lambda x:x[1], reverse=True)

final_list= new_list[:12]

recomm_df = pd.DataFrame(final_list, columns = ['item', 'cos_sim'])

recomm_df.insert(0, 'user', user)

return recomm_df

다음으로 데이터 작업을 위한 work 함수를 생성합니다.

1. user가 가장 많이 조회한 item top 5와 조회한 전체 item 리스트를 저장합니다.

2. top_view_list의 아이템 각각에 대하여 코사인 유사도 데이터프레임에서 가장 유사한 12개의 추천 대상 아이템을 가져옵니다.

* (5X12= 총 60개의 추천 대상 아이템 추출하기)

3. 위 추천 대상 아이템 중에서 user가 이미 본 아이템이거나, 중복된 아이템이거나, 유사도가 1인(스펙이 똑같은) 아이템은

제외한 나머지를 최종 추천 아이템 리스트에 저장합니다.

4. 어느정도 추려진 추천 대상 중 유사도가 높은 순으로 정렬하여 최종적으로 12개의 item을 뽑아서

pandas 데이터프레임으로 반환하기

최종코드

from tqdm import tqdm

import multiprocessing as mp

def work(user_pair):

user = user_pair[0]

top_view_list = user_pair[1] #Top 5

# 해당 user가 조회한 전체 item

view_all_list = view_all_dict[user]

temp_list = []

for item in top_view_list:

try:

recomm_item = cosine_sim_df.loc[int(item)].drop_duplicates().sort_values(ascending=False)[:12]

recomm_item_list = list(zip(recomm_item.index, recomm_item)) #index = item, recomm_item = 유사도

# 추천 대상 item 중 본 item, 추천 대상 리스트 중복, 유사도 1 제외

final_recomm_list = [r for r in recomm_item_list if r[0] not in view_all_list and r[0] not in [t[0] for t in temp_list] and int(r[1]) != 1]

temp_list.extend(final_recomm_list)

except Exception as e:

pass

new_list = list(set(temp_list))

new_list.sort(key=lambda x:x[1], reverse=True)

final_list= new_list[:12]

recomm_df = pd.DataFrame(final_list, columns = ['item', 'cos_sim'])

recomm_df.insert(0, 'user', user)

return recomm_df

def process_chunks(data, num_processes, chunk_size=3000):

results = []

with mp.Pool(processes=num_processes) as pool:

for i in tqdm(range(0, len(data), chunk_size)):

chunk = data[i:i + chunk_size]

for result in pool.imap_unordered(work, chunk):

results.append(result)

pool.close()

pool.join()

return results

num_processes = mp.cpu_count() #712 cores

results = process_chunks(user_recomm_list, num_processes)

all_user = pd.concat(results, ignore_index=True)

총 코어 수 712개와 청크 사이즈 3000으로 설정했을 때,

유저 수 16만개에 대한 병렬 처리 작업의 소요 시간을 9분 정도로 줄일 수 있었습니다!(기존: days+'α')

multiprocess.Pool을 활용한 병렬처리

당신이 어떤 것을

할머니에게 설명해주지 못한다면,

그것은 진정으로 이해한 것이 아니다.

- A.Einstein

[Airflow] Airflow db 업그레이드 에러 해결(feat. 2.10.0 버전)

쫄보삽질러 — Tue, 29 Oct 2024 21:35:17 +0900

airflow db upgrade 명령어 실행 시,

(airflow 2.7.0 대 버전 부터 airflow db upgrade -> airflow db migrate)

[SQL: ALTER TABLE dag_run ADD COLUMN clear_number INTEGER DEFAULT '0' NOT NULL]
ERROR:  column "clear_number" of relation "dag_run" already exists

위와 같은 에러가 발생함

db 접속 후 해당 컬럼을 삭제해주고(저는 metadata db로 postgresql을 사용했습니다)

> ALTER TABLE dag_run DROP COLUMN IF EXISTS clear_number;

다시 airflow db upgrade 명령어를 실행하면,

ALTER TABLE log ADD COLUMN owner_display_name VARCHAR(500);
ERROR:  column "owner_display_name" of relation "log" already exists

ALTER TABLE import_error ADD COLUMN processor_subdir VARCHAR(2000);
ERROR:  column "processor_subdir" of relation "import_error" already exists

이런식으로 해당 컬럼을 삭제해도 다른 컬럼이 없다는 에러 계속 반복..

> airflow_db=> SELECT * FROM alembic_version;

 version_num
--------------
 405de8318b3a

https://airflow.apache.org/docs/apache-airflow/2.10.0/migrations-ref.html

405de8318b3a는 기존 2.7.0점 대 버전의 Revision ID 이고,

다음 버전인 2.8.0점 버전으로 업데이트 하는 과정에서

add new field ‘clear_number’ to dagrun 명령을 실해하던 중 에러 발생.

=> 바로 버전을 2.10.0으로 바꾸어주어 문제 해결

airflow_db=> UPDATE alembic_version SET version_num = '22ed7efa9da2';
UPDATE 1

다시 airflow upgrade를 해주면

INFO - Creating tables
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
Database migrating done!

성공적으로 migrate 됩니다!

- 이상 오늘의 삽질일기 끄읏

여기저기 삽질도 해보고
날려도 먹으면서
배우는 게
결국 남는거다
- Z.Sabziller

'쫄보의삽질' 블로그 탄생스토리가 궁금하다면:

Git push 취소 방법 (feat. '쫄보의삽질' 블로그 탄생 배경)

아래는 저의 생생한 경험담을 바탕으로 작성한 것 입니다. Github 관리 폴더의 이름을 실수로 변경하고 삭제해버렸다. 작업 후 commit 하려고 아무리 찾아봐도 폴더가 보이지 않았다. 나의 피땀눈물

ninano1109.tistory.com

Debezium - Oracle 접속 실패

쫄보삽질러 — Thu, 26 Sep 2024 21:12:49 +0900

데이터 변화 감지(CDC)를 위해 debezium과 oracle(aws rds) 연동 시 oracle DB 접속에 실패하는 에러가 발생했습니다.

1. oracle-connector error

{"error_code":400,"message":"Connector configuration is invalid and contains the following 1 error(s):\nUnable to connect: Failed to resolve Oracle database version}

먼저 oracle-connector로 REST API를 생성할 때 나타난 에러이고,

실행 중이던 kafka connect에 나타난 에러를 보면 다음과 같습니다.

2. kafka connect error

Caused by: java.sql.SQLException: No suitable driver found for jdbc:oracle:thin:@test-db.ct.ap-northeast-2.rds.amazonaws.com:1521/ORCL

해당 에러는 oracle에 접속하기 위한 jdbc driver를 찾지 못해서 발생한 오류로 ojdbc8.jar 파일의 경로를 바꿔주어 해결했습니다.

먼저 로컬에서 ojdbc8.jar 파일 다운로드 후, kafka container에 복사해주었습니다.

docker cp ojdbc8.jar kafka:/opt/kafka_2.13-2.8.1/connectors/

=> 기존 plugin.path=/opt/kafka_2.13-2.8.1/connectors에 설정한대로, 해당 플러그인 경로에 복사했습니다.

그러나 계속해서 동일한 에러가 발생했고, debezium 공식문서를 참고한 결과,

# debezium 공식문서 참고

/kafka/libs/ 디렉토리 아래에 다시 파일을 옮겨주었습니다.

mv ojdbc8.jar ../libs/

# oracle-connector 실행
curl -X POST -H "Content-Type: application/json" --data @oracle-config.json http://localhost:8083/connectors

이후 oracle-connector를 재실행 했더니 정상적으로 oracle db 접속에 성공했습니다!

- 이상 오늘의 삽질일기 끄읏

여기저기 삽질도 해보고
날려도 먹으면서
배우는 게
결국 남는거다
- Z.Sabziller

'쫄보의삽질' 블로그 탄생스토리가 궁금하다면:

Git push 취소 방법 (feat. '쫄보의삽질' 블로그 탄생 배경)

ninano1109.tistory.com

[Datahub] slack notification 연동하기(feat. docker-compose.yml env 적용)

쫄보삽질러 — Thu, 25 Jul 2024 20:17:34 +0900

Datahub 내 발생하는 변동 및 업데이트 사항에 대해 slack 알림을 받을 수 있는 설정을 해보려고 합니다.
먼저 공식문서에 나와 있는 링크를 참고합니다.

https://datahubproject.io/docs/actions/actions/slack/

Slack | DataHub

| | |

datahubproject.io

공식문서에서 확인할 수 있듯이

Adding or Removing a tag from an entity (dataset, dashboard etc.)
Updating documentation at the entity or field (column) level.
Adding or Removing ownership from an entity (dataset, dashboard, etc.)
Creating a Domain
and many more.

와 같은 datahub가 관리하는 metadata에 여러가지 변경 사항을 업데이트 할 때, slack으로 실시간 noti를 보내줍니다.

설정을 위해서 해야할 것은 아래 두가지가 있는데요,
1. slack api 설정
2. datahub 설정

1번 slack api에서의 설정은 공식문서를 보면 아주 자세~히 나와있기 때문에 무난하게 설정할 수 있으므로 pass! 하구요,
이번 글에서는 2번 datahub 설정을 다뤄보겠습니다.(이 부분이 시간을 많이 잡아먹었..)

먼저 공식문서에서 볼 수 있듯이,
어떤 설치 방법으로 datahub를 설치했는지에 따라 slack 설정 또한 4가지 방법으로 나뉠 수 있는데요.
저는 가장 무난하게 또 쉽게 사용할 수 있는 방법인 #Quickstart 버전으로 사용했기 때문에, 해당 방법을 참고하겠습니다.

여기서 보면 docker compose로 설치하는 datahub-actions container에 이미 Slack action이 미리 설치가 되어 있기 때문에,
몇가지 환경변수 설정만 해주면 끝! 입니다.

export DATAHUB_ACTIONS_SLACK_ENABLED=true
export DATAHUB_ACTIONS_SLACK_SIGNING_SECRET='65e...'
export DATAHUB_ACTIONS_SLACK_BOT_TOKEN='xoxb-601...'
export DATAHUB_ACTIONS_SLACK_CHANNEL='C0..'

# 이후 docker 재실행
datahub docker quickstart --stop && datahub docker quickstart

문제는 이거를 어디다가 적용하느냐! 인것인데..
저도 처음에는 호스트 서버에서 명령어를 입력하고 docker restart를 했지만, 실패했습니다.

docker logs {datahub-actions-1 container id} 를 실행해보면 아래와 같이 slack_action이 아직 비활성화 상태임을 볼 수 있습니다.
....
Skipping pipeline datahub_slack_action as it is not enabled
Skipping pipeline datahub_teams_action as it is not enabled
Action Pipeline with name 'ingestion_executor' is now running.
...

그리고 datahub 커뮤니티에서 간신히 발견한 한줄기 빛.
host가 아닌 docker container 안에 환경변수가 포함되어야 할 것!

그저 빛..

그러면 방법은 quickstart로 docker를 띄울 때 환경변수를 포함시키는 것.
그러나, docker datahub quickstart로는 환경변수를 넘길 수 없고, 실행하는 순간 새로운 docker-compose.yml 파일을 내려받아서
컨테이너를 띄우기 때문에, 임의로 환경변수 값을 넣은 커스텀 파일로 quickstart를 해보자!

docker-compose-custom.yml 이라는 명으로 파일을 하나 생성 후

docker-compose.yml 파일

datahub-actions 컨테이너 아래 env 부분에 4개의 환경변수를 추가해줍니다.
이때 또 중요한 것은 저는 각 변수 값을 스트링으로('') 감쌌더니 에러가 나서 살짝 당황할뻔 했지만,

# 대충 이런 에러
BoltError: `token` is invalid (auth.test result: {'ok': False, 'error': 'invalid_auth'})

# 아무 터미널에서 실행
$curl -X POST -H 'Authorization: Bearer xox...' https://slack.com/api/auth.test
=> {"ok":true,"url":"https://X.slack.com/",...}% --토큰값 정상 확인

curl 명령어로 확인했을 때 토큰 값도 잘 맞았기 때문에, 고민하다가, docker-compose.yml 파일 내 다른 변수들에 string이 없길래 없애고 시도해봤더니 에러 없이 성공했습니다.
사실 저는 그냥 값을 하드코딩으로 넣었지만.. .env를 활용한 숨기는 방향으로 고민해보시는 것도 좋을 것 같습니다.
(단, quickstart 명령어가 아닌 docker compose로 실행해야 합니다.)

다시 docker를 재실행 합니다. 이때 -f 로 커스텀으로 사용할 파일을 명시합니다.

datahub docker quickstart --stop && datahub docker quickstart -f docker-compose-custom.yml

datahub-actions 컨테이너 log

컨테이너 로그에도 성공적으로 활성화된 상태를 확인할 수 있고,
바로 실시간으로 slack 알림 메시지도 확인 가능합니다:)

- 이상 오늘의 삽질일기 끄읏

[datahub] 오픈소스 컨트리뷰트 후기

https://ninano1109.tistory.com/286

나의 인생 첫 오픈소스 컨트리뷰트 성공 후기

예전부터 오픈소스 컨트리뷰터라고 하면 뭔가 "찐개발자" 같다는 생각을 하곤 했다.그래서 나의 버킷리스트이기도 했던 꿈의 오픈소스 컨트리뷰트를 예상치 못한 시점(?)에얼떨결에 하게 되었

ninano1109.tistory.com

여기저기 삽질도 해보고
날려도 먹으면서
배우는 게
결국 남는거다
- Z.Sabziller

multithread vs multiprocess (feat. Process, Pool 비교)

쫄보삽질러 — Wed, 8 May 2024 18:55:24 +0900

멀티스레드와 멀티프로세스는 모두 데이터 병렬처리를 위한 python 모듈로 약간의 차이점과 용도별 차이가 있습니다.

스레드 vs 프로세스

스레드

하나의 프로세스 안에 여러개의 스레드 존재

출처: Inpa Dev

4가지 메모리 영역중 스레드는 고유의 stack을 보유함 > stack은 독립적 함수 호출 가능 > 독립적 실행 흐름 추가

출처: Inpa Dev

프로세스

메모리 내 별도의 주소 공간에서 실행(독립적 구조)
동시성(concurrency) vs 병렬성(parallel)
- 동시성: 동시에 실행하는 것처럼 보이는 → 각 프로세스 작업을 작게 쪼개어 번갈아 처리 → context switching
- 병렬성: 실제 물리적인 동시 실행

멀티스레드

1. 여러개의 스레드가 하나의 프로세스 내에서 실행되며,

2. 동일한 메모리 공간을 공유

3. context switching이 가벼워 메모리 및 성능 효율적이며, 스레드 간의 데이터 공유가 용이함.

4. 파일을 읽고 쓰기위한 I/O 작업에 적합함.

5. 동시성(concurrency)을 주로 다룸 => CPU가 스레드 간에 전환하면서 작업 실행(동시 처리처럼 보이는)

멀티프로세스

1. 각 프로세는 독립적 메모리 공간에서 실행됨

2. 프로세스간 직접적인 데이터 공유 불가능

3. 메모리 공간이 독립적이므로, 한 프로세스에의 오류가 다른 프로세스에 영향 미치지 않음.

4. cpu 집약적 작업에 적합함.

5. 진정한 병렬성 구현 가능 => 여러 작업 동시 처리 가능

Python multiprocessing 모듈

1. Process

하나의 작업에 대해 개별 프로세스 생성하여 독립적으로 실행
여러작업 병렬로 처리 위해 여러 process 객체 생성
독립적 메모리 공간에서 서로 직접적인 데이터 공유 X
프로세스 직접 관리

Process 예시코드

2. Pool

미리 지정된 수의 프로세스 생성 후 프로세스 풀에서 작업 처리
작업이 완료된 프로세스는 다시 풀에 반환되어 작업 재실행 ⇒ 프로세스 풀 재사용
배치 작업 시 유용하며 효율적인 자원 사용 가능
프로세스 자동관리

Pool 예시코드

ref:

https://inpa.tistory.com/entry/%F0%9F%91%A9%E2%80%8D%F0%9F%92%BB-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%E2%9A%94%EF%B8%8F-%EC%93%B0%EB%A0%88%EB%93%9C-%EC%B0%A8%EC%9D%B4

‍ ‍완전히 정복하는 프로세스 vs 스레드 개념

한눈에 이해하는 프로세스 & 스레드 개념 전공 지식 없이 컴퓨터의 프로그램을 이용하는데는 문제 없어 왔지만 소프트웨어를 개발하는 사람으로서 컴퓨터 실행 내부 요소를 따져보게 될때, 아

inpa.tistory.com

당신이 어떤 것을

할머니에게 설명해주지 못한다면,

그것은 진정으로 이해한 것이 아니다.

- A.Einstein

[Airflow] Airflow dag 추가 에러 현상

쫄보삽질러 — Sat, 24 Feb 2024 14:04:08 +0900

Airflow에 새로운 DAG를 추가할 때 db 관련 에러가 발생하여 db 업그레이드 진행 시 에러발생

> airflow db upgrade

raise sa_exc.PendingRollbackError(
sqlalchemy.exc.PendingRollbackError: This Session's transaction has been rolled back due to a previous exception during flush. To begin a new transaction with this Session, first issue Session.rollback(). Original exception was: (psycopg2.errors.NotNullViolation) null value in column "max_consecutive_failed_dag_runs" of relation "dag" violates not-null constraint
DETAIL:  Failing row contains (boaz_analysis_dag, null, t, f, t, 2024-01-11 02:31:28.735741+00, null, null, null, null, /airflow/dags/analysis_dag.py, null, airflow, null, grid, null, Never, external triggers only, 16, 16, f, f, null, null, null, null, null, null, null).

[SQL: INSERT INTO dag (dag_id, root_dag_id, is_paused, is_subdag, is_active, last_parsed_time, last_pickled, last_expired, scheduler_lock, pickle_id, fileloc, processor_subdir, owners, description, default_view, schedule_interval, timetable_description, max_active_tasks, max_active_runs, has_task_concurrency_limits, has_import_errors, next_dagrun, next_dagrun_data_interval_start, next_dagrun_data_interval_end, next_dagrun_create_after) VALUES (%(dag_id)s, %(root_dag_id)s, %(is_paused)s, %(is_subdag)s, %(is_active)s, %(last_parsed_time)s, %(last_pickled)s, %(last_expired)s, %(scheduler_lock)s, %(pickle_id)s, %(fileloc)s, %(processor_subdir)s, %(owners)s, %(description)s, %(default_view)s, %(schedule_interval)s, %(timetable_description)s, %(max_active_tasks)s, %(max_active_runs)s, %(has_task_concurrency_limits)s, %(has_import_errors)s, %(next_dagrun)s, %(next_dagrun_data_interval_start)s, %(next_dagrun_data_interval_end)s, %(next_dagrun_create_after)s)]
[parameters: ({'dag_id': 'analysis_dag', 'root_dag_id': None, 'is_paused': True, 'is_subdag': False, 'is_active': True, 'last_parsed_time': datetime.datetime(2024, 1, 11, 2, 31, 28, 735741, tzinfo=Timezone('UTC')), 'last_pickled': None, 'last_expired': None, 'scheduler_lock': None, 'pickle_id': None, 'fileloc': '/airflow/dags/analysis_dag.py', 'processor_subdir': None, 'owners': 'airflow', 'description': None, 'default_view': 'grid', 'schedule_interval': 'null', 'timetable_description': 'Never, external triggers only', 'max_active_tasks': 16, 'max_active_runs': 16, 'has_task_concurrency_limits': False, 'has_import_errors': False, 'next_dagrun': None, 'next_dagrun_data_interval_start': None, 'next_dagrun_data_interval_end': None, 'next_dagrun_create_after': None}

원인

metadat DB의 dag 테이블 내 max_consecutive_failed_dag_runs 컬럼이 not null로 설정되어 있는데

NOT NULL CONSTRAINT 조건에 violate하여 에러 발생

해당 DAG에 값이 빠져 있는 원인은 2가지 정도로 볼 수 있는데:

1.Missing Field in DAG Definition: The DAG definition might not include the `max_consecutive_failed_dag_runs` field, or it might not be initialized properly when the DAG is created. This field should have a default value, but sometimes during upgrades or custom DAG creation, this might not be set automatically.
2. Database Inconsistency: During migrations or upgrades, the database might have missed setting the default value for the `max_consecutive_failed_dag_runs` field for existing DAGs, leading to this issue during migrations.

1. DAG를 작성했을 때의 DAG Definition이 제대로 작동하지 않았거나,

2. DB 업그레이드 시 디폴트 값 설정하는 부분에서 누락이 발생했을 수 있음

해결방안

pg 접속
=> \d dag;

=> ALTER TABLE dag
   ALTER COLUMN max_consecutive_failed_dag_runs SET DEFAULT 0;

Casae1. dag file name != dag id

1) Dag id 이름만 바꿨을 때, scheduler log:

    - INFO - Deleted DAG tableau_EC2_management_dag in serialized_dag table 
    - INFO - Deactivated 1 DAGs which are no longer present in file. 
    - INFO - DAG tableau_EC2_management_dag is missing and will be deactivated.

2) airflow dag table 확인

이전 EC2 dag_id 의 fileloc 컬럼 = 현재 dag 위치와 동일

'/airflow/dags/A_dag.py'

=> 현재와 다른 새로운 이름으로 바꿔주기

  UPDATE dag
  SET fileloc = '/airflow/dags/A.py'
  WHERE dag_id = 'A';

processor_subdir = NULL
=> 현재 dag_folder 경로로 바꿔주기

  UPDATE dag
  SET processor_subdir = '/airflow/dags/
  WHERE dag_id = 'A';

airflow scheduler 재가동 이후, scheduler log에 더이상 에러 메세지 나타나지 않음.

이전 삭제된 DAG, tasks들 스케줄 되어 trigger 되는 현상:

metadata DB에 이전 기록들이 남아있는 상태로, 종료되지 않은 상태로 유지되어 있으면
scheduler 재가동 시 매번 해당 dag 정보를 가져오는 현상
db clean으로 오래된 데이터를 삭제하기
airflow db clean --clean-before-timestamp '2024-01-01'

- 이상 오늘의 삽질일기 끄읏

여기저기 삽질도 해보고
날려도 먹으면서
배우는 게
결국 남는거다
- Z.Sabziller

'쫄보의삽질' 블로그 탄생스토리가 궁금하다면:

Git push 취소 방법 (feat. '쫄보의삽질' 블로그 탄생 배경)

ninano1109.tistory.com

[Linux] ec2 방화벽 port 설정 명령어(feat. firewall-cmd)

쫄보삽질러 — Thu, 1 Feb 2024 22:27:40 +0900

방화벽 등록 리스트 확인

$ sudo firewall-cmd --list--all

방화벽 상태 check

$ sudo firewall-cmd --state

방화벽 port 등록

$ sudo firewall-cmd --permanent --add-port={port number}/tcp

=> 바로 반영 안됨

방화벽 리로드

$ sudo firewall-cmd --reload

당신이 어떤 것을

할머니에게 설명해주지 못한다면,

그것은 진정으로 이해한 것이 아니다.

- A.Einstein

나의 인생 첫 오픈소스 컨트리뷰트 성공 후기

쫄보삽질러 — Sun, 17 Dec 2023 21:54:16 +0900

예전부터 오픈소스 컨트리뷰터라고 하면 뭔가 "찐개발자" 같다는 생각을 하곤 했다.
그래서 나의 버킷리스트이기도 했던 꿈의 오픈소스 컨트리뷰트를 예상치 못한 시점(?)에
얼떨결에 하게 되었다는,, 후기를 남겨보려고 합니다.

때는 바야흐로.. 데이터 디스커버리 플랫폼(A.K.A DDP)인 Datahub를 구축하고,
내부 기능들을 살피던 중 코드 커스텀화를 위해 공식문서와 github 코드들을 리뷰하던 때였다.

datahub의 metadata-ingestion source를 tableau로 활용했기 때문에,
tableau recipe 코드를 탐색하던 중 config에 뭔가 빠져있는 듯한 허전한 느낌이었다.

그래서 내가 짰던 recipe 코드와 비교해보니 token값이 빠져있는 것을 발겼했고,
저의 경우 token 값이 빠져있어 생기던 에러를 token 값을 추가함으로써 해결했기 때문에,
꼭 token이 필요한 경우(예를 들면 tableau 서버 접속에 2차 인증이 필요한 경우)도 있을 수 있다고 판단하여
token value를 추가하여 commit 했고, 바로 approved를 받을 수 있었다.

첫 commit 후 받았던 approved 메세지

사실 반신반의 하며 했던 commit이었기도 했고, 어차피 수락 아니면 거절이었기 때문에
시작이 반이다라는 말처럼 첫 컨트리뷰트 시도라도 해보자는 마인드로 무작정 커밋을 했던 터라
이 때까지만해도 거절당하지 않고 reviewer에게 approved라도 받을 수 있어서 매우매우 기뻤따!!
그리고 token이 필수 사항은 아니었어서 옆에 (optional)이라는 추가 코멘트와 함께 commit이 되었다.

그리고 막상 merge까지는 몇일 더 걸렸는데,
이 몇일이 계속 긴장의 연속이었다,, 하루에도 몇번을 들락날락하면서 확인하고 또 확인했다.
그래서 approved 이후에 merge가 안되는 이유도 계속 구글링하면서 기다리다 그냥 포기하고 있던 시점에

merge된 나의 commit!

이렇게 뙇! Merge가 되어버려땋,,,
크으으 감격의 순간

이유는 모르겠지만 내부적으로 reviewer 사이에서 논의가 있었던 것도 같구 흠
암튼 내 github 프로필에 가보니 이런것도 새로 생김ㅎㅎㅎㅎ 뿌듯

앞으로도 더 많은 오픈소스에 컨트리뷰트를 해봐야겠다는 각오를 다지는 시간이었다.
급 마무리ㅎㅎㅎ

나도 이제 오픈소스 컨트리뷰터닷! ‍♀️

'쫄보의삽질' 블로그 탄생스토리가 궁금하다면:

Git push 취소 방법 (feat. '쫄보의삽질' 블로그 탄생 배경)

ninano1109.tistory.com