흑백과 디지털

 회사에서 Pipedrive 라는 프로그램을 사용하고 있다.  회사 자체적인 사내 시스템에 Pipedrive API를 연동해서 사용하고 있다. 그러다 버그가 있어 Pipedrive 에서 제공하는 chang log 를 확인해 보았다. 
 거기서 지난주 수요일 오전 12:10 이라고 되어 있는 부분에 문제가 발생했다. 그래서 회사 서버의 로그와 비교해 보았다. 그런데 이상하게도 회사 서버에서 Pipedrive API 를 사용한 로그가 없었다. 그러다 지난주 수요일이 지난 수요일을 잘못 표시한 거라는 것을 알게되었다( 이건 번역상의 실수로 보인다. ). 다행히 시간에 mouse 를 over 하니 날짜가 보였다.   그리고 좀 많이 오해를 살 만한 표현이다. 2025년 1월 17일(금요일)을 기준으로 지난 수요일은 1월 15일이고 지난주 수요일은 1월 8일 이어야 한다. 

   어째든 다시 지난 수요일로 로그를 확인해 보았다. 그런데도 회사 서버에서 로그를 찾을 수 없었다. 한참을 헛짓하다 오전 12:10 이라는 시간이 24시간 기준으로 00:10 이라는 것을 깨달았다. 사실 오전 12시라는 표현을 쓰지 않고 밤 12시라는 표현을 더 많이 사용하다보니 이런 일이 생겨버렸다. 

 그렇다. 그냥 2025-01-15 00:10 이랬으면 쉽게 날짜와 시간을 알았을 텐데, 지난주 수요일 오전 12:10  라는 표시 때문에 2번이나 고생했다. 날짜 시간이 중요한 요소인 곳에서는 제발 그냥 YYYY-MM-DD HH:mm:ss 를 사용하자. Change Log 정도는 날짜 시간이 꽤 중요한데, 그런 곳에서 까지 ~일 전, ~ 시간 전 이런 것을 좀 사용하지 말자. 

 오늘 javascript 을 사용하다가 dict을 for 문으로 돌리는데 key 가 number 가 아니라 계속 string type으로 유지되는 현상을 발견했다. 처음에는 내가 사용한 Object.entries 의 특성인지 알고 다른 방법들을 사용해 보았다. 그러다 검색을 통해 javascript 에서 dictionary 의 key는 자동으로 string 으로 형 변환 된다는 것을 알게 되었다. (참고 : https://stackoverflow.com/a/3633390/6652082 ) 

 내가 python 코드를 작성할 때, key 를 integer 를 사용하거나 파이썬은 아래 처럼 key를 tuple(리스트 같은 것이지만 변경이 불가능한 것)로 사용할 수도 있다. 

 a = {(1,2) : "test"}

그렇기에 당연히 javascript 에서도 사용 가능할 줄 알았다.  만약 정말 number 형 key 가 필요하다면 stackoverflow 에서 제시되었듯이 Map() 을 사용해야 한다.

const map1 = new Map();

map1.set(1,3)
map1.set('1','string')

javascript 에서 dictionary 가 key 만 사용된다는 것을 이제 알게 되다니, 아직 배워야 할 것들이 너무 많다. 

 이 글을 작성한지 꽤 오랜 시간이 흐른 후 읽는 사람이 있을 것 같다. 그리고 나와는 조금 다른 환경에서 다른 라이브러리가 필요한 일이 있을 것이다. 미래에는 lambda 기능 자체가 업데이트 되면서 변경될 수도 있다. 내가 문제를 해결한 방식을 잘 응용하면 해당 문제를 푸는데 도움일 될 수도 있을 것이다. 

aws 계층에 업로드된 파일의 경로 확인하기

내 경우는 python.zip 파일을 계층에 업로드 할 때 이 경로가 aws lambda 에서는 /opt/python 이었다. 이 경로가 어떻게 결정되는 것인지 모르겠지만 확인하는 방법이 있다. 

import requests
print(requests.__file__)

위 코드를 aws lambda 에 실행시켜 본다. 내 경우에는 /opt/python/requests/init.py  이라는 경로가 나왔다. __file__ 이라는 키워드는 파이썬 코드에서 사용이 가능하지만 module 에 대해서 경로를 확인하는 용도로도 사용이 가능하다. 

필요로 하는 shared_library 알기

참고 :  https://stackoverflow.com/a/47346043    
이번 작업에서 가장 어려웠던 일 중의 하나이다. https://aws.amazon.com/ko/blogs/compute/creating-faster-aws-lambda-functions-with-avx2/  에서 나왔던  파일들은 모든 파일을 포함되어 있지 않았다. 그래서  /usr/lib64 을 다 넣을까 하는 생각도 해봤지만 그렇기에는 zip 파일이 크게 나왔다. 어째든 stackoverflow 의 글을 잘 참고하면 된다. 그런데 lsof  가 없기 때문에 yum install lsof   로 설치해야 한다. 설치하고 나서 lsof 를 이용할 때는 /usr/sbin/lsof   라고 해야 한다. 기본 path 설정에 /usr/sbin 이 없는 것 같다. 어째든 저 방법을 이용해서 필요한 so 파일을 알 수 있다. 그리고 이 동작을 하기 위해서는 2개의 bash 터미널이 필요하다. 기존의 docker  container 에서 2개의 bash 터미널을 준비한다. 2개의 터미널을 각각 consoleA와 consoleB라고 하겠다. 

#### consoleA ####
# 파이썬 특정 경로 라이브러리 이용해서 실행
PYTHONPATH="/root/python" python3
>>> import os
>>> os.getpid()

아래 코드 동작전 consoleB의 before 파일 생성할 것

>>> from PIL import Image

위 코드 동작후 consoleB의 after 파일 생성할 것

############

#### consoleB ####
# os.getpid() 에서 나온 번호를 이용한다. 여기서는 1093 이라고 가정한다.
/usr/sbin/lsof  -p 1093 > before 

consoleA 에서 from PIL import Image 동작 후 
/usr/sbin/lsof  -p 1093 > after


# from PIL import Image 동작 후 추가된 so 파일 확인 하기 위해 
# before 파일과 after 파일 비교
diff <(awk '{print $NF}' after) <(awk '{print $NF}' before)

# 출력된 so 파일들이 로딩된 shared library 임

pillow-simd 의 경우 운이 좋아 from PIL import Image  할 때 shared library 가 호출 되었다. 경우에 따라서는 webp 파일을 불러올 때 특정 webp 라이브러리를 이용하는 식으로 얼마든지 lazy 하게 library 를 가져올 수도 있다. 이 경우는 이런 것들 동작까지 한 후 어떤 so 파일이 로딩되는지 확인해야 한다.

소스에 업로드된 파일 읽기 불가

내 경우에는 thumbnail 이미지를 만들때, png파일을 이용해서 watermark 를 붙인다. 이 watermark 이미지를 lambda 코드안에 파일로 업로드 했다. (python.zip 폴더 아니고 소스를 수정하는 vscode 화면에 직접 파일을 업로드 했음) 그런데 여기 올라온 이미지파일을 pillow로 열면 에러가 발생했다. 처음에는 png 문제라고 생각했는데, 웃기게도 aws s3 에 있으면 잘 읽어졌다. 파일사이즈나 데이터자체도  aws lambda 코드로 확인해봤는데 정상적이었다. 나 처럼 고생하지 말고 이런 현상 있으면 그냥 s3 를 이용하자. 

트리거 중복으로 추가할 수 없다고 에러 발생할 때

aws lambda 함수에 트리거를 걸어 넣고, 그냥 삭제해 버리면 이런 현상이 있다. s3 버킷 속성에 해당 트리거가 남아 있다. 해당 트리거를 지우도록 하자.