본문 바로가기

일상

TIL - 20241123 도메인 주소 검증 로직에서 주의해야 할 점만약 특정 주소를 입력했을 때의 도메인의 주소를 블랙리스트 혹은 화이트리스트 방식으로 관리한다면 주의해야 할 점이다.먼저 도메인에 특정 문자열이 포함되는지 여부로 해서 허용을 한다면 fully matched 방식으로 체크해야 한다.예를 들어 "humit.tistory"라는 문자열이 포함되어 있는지 여부로 체크해서 포함되는 경우에만 허용한다면, 공격자가 "humit.tistory.victim.com" 으로 해서 우회할 수 있는 위험이 있다.그리고 도메인 주소의 경우 대소문자를 구분하지 않느다는 특징이 있다. 즉 HUMIT.TisTOry.CoM 으로 접속하더라도 humit.tistory.com으로 접속하는 것과 동일하다.그래서 허용하지 않을 도메인주소를 블랙리스트로 ..
TIL - 20241122 Kubernetes PodOperator로 수행한 Spark local 모드 수행 모니터링spark local 모드로 수행하는 경우 4040 포트로 history 로그를 볼 수 있는 웹서버가 뜨게 된다.그래서 이걸 보기 위해서는 Pod를 띄울 때 4040 포트를 접근할 수 있도록 port 정보를 추가해서 잡을 제출하고 kubectl port-forward 명령어를 사용해서 로컬에서 접근할 수 있도록 하고 해당 주소로 접근해서 잘 동작하는지 확인하면 된다.물론 이렇게하지 않더라도 spark.eventLog.dir 설정을 적용해서 로그를 리모트 저장소에 저장할 수 있게 하고 historical 서버가 해당 경로를 바라도록 하면 port-forward 를 사용하지 않더라도 조회할 수 있다.
TIL - 20241121 Dynamic task mapping 사용시 팁Dynamic task mapping을 사용하면 airflow 웹 서버에서 task 수행되는 것을 보면 0, 1, 2, 3과 같이 숫자로 찍힌다.이렇게 되면 해당 task가 어떤 잡인지 알기 어려운 점이 있다.이를 map_index_template 값을 사용하면 dynamic task가 끝난 시점에 task 이름 정보를 업데이트하고 이걸 airflow UI에서 해당 내용을 확인할 수 있다.다만 이게 task 수행이 끝나야지만 업데이트가 되기 때문에 이 점을 유의해야 한다.
TIL - 20241120 Yarn cluster에서 spark-submit으로 잡을 제출했을 때 로그 건 수 줄이기yarn cluster에 spark-submit을 사용해서 잡을 제출하면 1초마다 한 번씩 해당 앱의 상태를 조회해서 체크합니다. 그렇기 때문에 잡 수행시간이 긴 경우에는 불필요하게 로그가 많이 찍히는 이슈가 있습니다.이를 조절하기 위해서 spark 에서 spark.yarn.report.interval 설정을 통해 적용할 수 있습니다. 해당 값의 경우 기본 값이 '1s'로 설정되어 있고 이를 적절하게 사용하면 출력되는 로그 건 수를 줄일 수 있습니다.분 단위로는 'm', 'min'으로, 시간 단위는 'h'로 표현하면 됩니다.
TIL - 20241119 Airflow에서 schedule interval을 수정하는 경우airflow schedule interval을 변경하는 경우 이전 시간인지 아니면 이후 시간인지에 따라 동작 방식이 살짝 달라진다.예를 들어 기존 0시 5분으로 설정했는데 해당 DAG의 스케줄 시간을 0시 10분으로 변경한다면 DAG가 업데이트 된 시점에 한 번 실행이 되고 다음날 0시 10분에 실행이 된다.만약 기존 0시 10분으로 설정했는데 해당 DAG의 스케줄 시간을 0시 5분으로 변경하면 다음날 0시 10분에 실행된다.최근 Airflow 버전에서는 다음 스케줄링 시간에 대한 정보를 airflow 웹 화면에서 확인할 수 있다.
TIL - 20241115 MySQL 데이터 전체를 가져올 때 유의할 점.mysql에 직접 쿼리를 날리면서 분석하는 경우 부하 이슈라던지 혹은 다른 db와 연결해서 분석하는 것이 어렵기 때문에 mysql 데이터 전체를 가져와서 하둡에 적재하고 이를 Hive나 Spark 등을 사용해서 분석합니다. 다만 직접 쿼리를 날릴 때도 한 번에 많은 데이터를 가져오려고 하면 db에 부하가 가기 때문에 적절한 조건문을 걸어서 조회해가는 것이 필요합니다. 그래서 pk를 사용해서 범위로 조회하는 것이 좋으며 이 범위를 잘 설정하는 것이 중요합니다. 너무 짧게 잡게되면 연결을 자주하는 이슈가 있고, 너무 크게 잡으면 db 입장에서 데이터를 쿼리하는 과정에서 부하가 발생합니다. 이 때 당연히 데이터를 조회할 때 항상 pk를 기준으로 정렬해서 보여주는 ..
TIL - 20241114 Airflow backfill 과정에서 backfill이 안되는 경우Airflow 2.9.1 버전을 기준으로 airflow backfill을 실행하는 과정에서 겪었던 backfill이 안되는 다양한 이슈에 대해 정리합니다.하나의 DAG에 대해 2개 이상의 backfill을 수행하는 경우Deadlock 에러가 발생하면서 실행이 안되는 이슈가 있습니다. 따로 해결 방안은 없고 그냥 최대 1개의 backfill만 수행하도록 하며 필요한 경우 DAG를 복제해서 여러개를 돌리거나 혹은 max_active_runs 값을 늘려서 해당 backfill 잡이 여러 개의 dag run을 수행할 수 있도록 합니다.DAG에 명시된 start_date와 end_date를 벗어나는 기간에 대해 backfill을 수행하는 경우주어..
TIL - 20241113 Airflow task가 queue 상태로 유지되는 이슈관련 환경Kubernetes 상에서 CeleryExecutor로 실행Redis를 큐로 사용DB의 경우 postgresql을 사용문제가 된 TaskSpark 잡을 제출하기 위해서 SparkSubmitHook을 사용하는 custom operator를 만들었고 해당 operator를 Dynamic Task Mapping를 활용해서 task를 생성함.해당 task가 scheduled 에서 queue 상태로는 잘 가는데 그 이후로 running 상태로 변경되지 않는 문제가 있었음원인원인은 매우 심플했는데 custom operator를 만들 때 yarn 제출 시 사용할 queue에 대한 정보를 생성자에서 전달받을 수 있도록 queue 파라미터를 추가했는데, 이..