@sinwoobang

방신우 블로그

[sinwoobang]

aioredlock - Implementation of Lock for Python/Redis

I got restricted by a third party API provider. It is supposed to be called 10 requests per second, but I have called 800 requests per second. I totally agree with my mistake.

I needed to resolve this problem. Controlling the speed of calling API was the main point in this situation. And also, in this case, the caller was implemented using asyncio. In summary, controlling the *concurrent* calling API was the main point.

I checked Primitive types on asyncio first because it supports built-in Lock and built-in Semaphore. It was easy to use them so I tried using that.

But, the real problem was the concurrent tasks were run on distributed environments. It was impossible to use Python built-in since I had to deal with multiple nodes.

Fortunately, I could find a library called aioredlock. It was the lock implementation for Redis. The abstraction was perfect so what I did was using the simple interfaces such as lock(), is_locked().

I was going to attach an example code myself but it would be good to check the example code on the repository yourself because it is so easy.

I locked it when an API call has been started and released it after the call is ended.

So,

There might be good ways to implement Distributed Lock. I have written it for introducing an easy way. I hope this helps or will help you. Thank you for reading it.

[sinwoobang]

aioredlock을 이용한 분산 Lock 구현

최근에 한 서드파티 업체로부터 API 이용 제재를 받았다. 초당 10개씩만 호출해야하는데 초당 800개씩 호출해버렸으니 내가 봐도 제재를 받을만 했다.

의도한 건 아니었으나 대처를 하긴 해야했고, 문제의 본질은 asyncio를 이용한 비동기 작업들에 대한 속도 제어였다. 처음에 알아본 건 asyncio의 Primitive 타입들이었다.

asyncio는 Lock과 Semaphore를 제공한다. 굉장히 쉬운 인터페이스로 해당 기능들을 제공하고 있고 필자도 처음엔 그 기능을 사용했다.

문제는 비동기 작업들이 분산 환경에서 이루어진다는 것이었다. 분산 환경이라고 해봤자 EC2 2대였지만, 각 EC2에서도 프로세스를 여러개로 돌렸으니 대략 10개 이상의 환경에 대한 처리가 필요했다.

그래서 알아본게 분산 환경에서의 Lock 구현인데, 운 좋게도 aioredlock이라는 구현체를 접할 수 있었다.

“The redlock algorithm is a distributed lock implementation for Redis. This is the asyncio compatible implementation for python 3.5+.” by joanvila

쉽게 얘기하면 Redis에 Lock을 구현하는 알고리즘인 Redlock에 대한 Python 구현체였다. 추상화도 잘 되어있어서 사용자 입장에선 is_locked(), lock() 등의 최상위 인터페이스만 알고 있으면 되었다.

예시를 첨부하려했으나 사용법이 워낙 쉬워서 Repository 내에 examples을 보면 될 것 같다. 위에 적었던 문제는 API 호출 시에 Lock을 걸고 호출이 끝나면 Release 하는 방식으로 구현했다.

마무리

분산 Lock을 구현하는 방법엔 더 좋은 방법이 있을 수 있다. 방법 소개 차원에서 글을 적었다. 스치듯 지나가는 글이었다가 나중에 분산 Lock이 필요한 분이 떠올리게 되는 글 정도면 만족한다. 그럼 이만!

[sinwoobang]

Python Dictionary 순서 보장 원리

* 이 글은 스택 오버플로우에 올라온 질문을 재구성한 것 입니다. * 읽기 어려우신 문장은 원문을 확인해보시는 걸 권장해드립니다. * 이 글은 PC에서 보기 편합니다.

Python 3.6 이상에선 Dictionary가 순서 보장이 되나요?

네. CPython에선 삽입 순서가 유지됩니다. 하지만 CPython 외 다른 구현체에서는 보장되지 않습니다. 즉, 이 기능은 CPython 3.6의 Implementation detail 입니다. (Python 3.7부터, 위 내용이 Implementation detail이 아닌 언어 기본 feature가 되었습니다. Python 3.7부터는 구현체에 무관하게 삽입 순서가 보장됩니다.)

순서가 보장되는데 어떻게 메모리 사용을 줄였나요?

두 가지 배열을 사용합니다. PyDictKeyEntry 형식의 entry들을 담는 dk_entries 배열과 그 인덱스들을 담는 dk_indicies 배열을 씁니다.

첫번째 배열 dk_entries는 삽입 순서에 따라 entry(PyDictKeyEntry type)들을 저장합니다. 즉, 삽입 순서 보존이 이 배열에 의해 이뤄집니다.

두번째 배열 dk_indicies는 dk_entries의 각 요소에 대한 index들을 저장합니다. 즉, 각각의 index 값이 dk_entries의 요소를 가리킵니다. 이 배열은 해시 테이블 역할을 합니다. 키가 해시되면 그 키가 dk_indices 안에 저장된 index를 가리키고, 그 index는 그에 맞는 entry를 dk_entries에서 가져옵니다. 인덱스들만 저장되기 때문에, dk_indices의 형식은 Dictionary의 크기에 따라 결정됩니다.(int8_t부터 int32_6, int64_t까지)

이전 구현체에선, PyDictKeyEntry 형식의 희소 배열을 사용하고 dk_size에 크기를 저장했습니다. 하지만 성능을 이유로 배열이 dk_size의 2/3 이상을 사용할 수 없었고, 이에 따라 빈공간이 많이 생겼습니다. 게다가 빈공간이어도 PyDictKeyEntry 크기만큼 차지하고 있었기 때문에 문제가 더 컸습니다.

이젠 괜찮습니다. entry 배열에는 필수 entry들만 저장하고 dk_size의 2/3을 채우는 intX_t(X는 Dict에 따라 결정) 형식의 희소 배열이 유지됩니다. 빈공간 형식이 PyDictKeyEntry에서 intX_t로 바뀌었기 때문에 훨씬 메모리를 아낄 수 있습니다.

이 아이디어를 제안한 Raymond Hettinger씨의 원본 문서를 보면, 내용을 시각화 한 자료가 있습니다.

For example, the dictionary:

d = {'timmy': 'red', 'barry': 'green', 'guido': 'blue'}

is currently stored as:

entries = [['--', '--', '--'], [-8522787127447073495, 'barry', 'green'], ['--', '--', '--'], ['--', '--', '--'], ['--', '--', '--'], [-9092791511155847987, 'timmy', 'red'], ['--', '--', '--'], [-6480567542315338377, 'guido', 'blue']]

Instead, the data should be organized as follows:

indices = [None, 1, None, None, None, 0, None, 2] entries = [[-9092791511155847987, 'timmy', 'red'], [-8522787127447073495, 'barry', 'green'], [-6480567542315338377, 'guido', 'blue']]

위 자료에서 보듯, 이전에는 빠른 검색과 충돌 방지를 위해 많은 공간이 필수였습니다. 새로운 접근 방식에선, entry들이 아닌 index에 희소 배열을 사용함으로써 메모리를 많이 아낄 수 있습니다.

Python-Dev에서 이 feature를 다룬 대화를 확인할 수 있습니다. 관심 있으시면 읽어보셔도 즣을 것 같습니다.

--

첫번째 사진 출처 링크 I translated an English post of Stack overflow to Korean and reorganized it.

[sinwoobang]

Flask 1.0 Changelog 우리말 번역

드디어 Flask 1.0이 출시되었네요 :) http://flask.pocoo.org/docs/1.0/changelog/ 를 우리말로 번역해봤습니다. 의역, 오역 많을 수 있으니 참고로만 봐주세요. 감사합니다.

Flask 1.0 Changelog

Python 2.6과 3.3 지원이 중단되었습니다.

의존성이 업데이트 되었습니다. (Werkzeug >= 0.14, Jinja >= 2.10, itsdangersou >= 0.24, Click >= 5.1)

명령줄에서 앱을 실행할 때 app.run을 생략했습니다. 디버깅하기에 혼란스러운 동작을 피할 수 있게 되었습니다.

JSONIFY_PRETTYPRINT_REGULAR 기본값을 False로 바꾸었습니다. 이제 기본 설정에서는 디버그 모드일떄만 jsonify() 결과값이 prettify입니다.

Flask.init이 host_matching 인자를 받습니다. 이 값을 url_map에 설정합니다.

Flask.init이 static_host 인자를 받습니다. static route를 정의할 때, 이 값을 host 인자로 넘깁니다.

send_file()이 attachement_filename에 유니코드를 지원합니다.

오류가 발생하면 url_for()의 _scheme 값을 handle_url_build_error()로 넘깁니다.

add_url_rule()이 provide_automatic_options 인자를 받습니다. 이 값은 OPTIONS method 추가를 불가능하게 하기 위해 씁니다.

MethodView 서브 클래스들이 부모 클래스들의 method handlers들을 상속 받습니다.

요청 초기에 세션을 오픈하는 동안 생기는 오류들을 앱의 오류 핸들러에서 처리 가능합니다.

Blueprint에 json_encoder, json_decoder 속성이 생겼습니다. 이 속성들은 앱의 encoder와 decoder를 오버라이드합니다.

Flask.make_response()가 유효하지 않은 Response Type들에 대해 ValueError 대신 TypeError를 발생시킵니다. 왜 해당 Type이 왜 유효하지 않은지 알려주기 위해 오류 메시지를 개선했습니다.

CLI에 'routes' 명령을 추가했습니다. 이 명령은 앱에 등록된 라우팅들을 보여줍니다.

세션 쿠키 도메인이 bare hostname(ex. localhost)이거나 IP면 경고를 보여줍니다. Chrome과 같은 일부 브라우저에서는 제대로 작동하지 않을 수 있습니다.

정확한 세션 쿠키 도메인으로 IP 주소를 허용합니다.

SERVER_NAME에서 SESSION_COOKIE_DOMAIN이 감지되면, SESSION_COOKIE_DOMAIN이 설정됩니다.

앱 factory 함수 create_app 혹은 make_app을 자동으로 감지합니다.

flask 명령으로 작업하기 위해 script_info 매개 변수를 사용하는 것은 Factory 함수가 필요 없습니다. 만약에 단일 인자나 script_info라는 이름으로 인자를 받으면, ScriptInfo 객체가 넘어갑니다.

앱 factory를 FLASK_APP로 설정할 수 있습니다. 필요하면 인자도 같이 넣을 수 있습니다. ex. FLASK_APP=myproject.app:create_app('dev').

FLASK_APP은 로컬 패키지도 가리킬 수 있습니다. 로컬 패키지가 편집 가능한 상태가 아니어도 가능합니다. 물론 pip install -e를 설정하는게 선호되긴 합니다.

View 클래스 속성 provide_automatic_options가 add_url_rule()에서 감지되어, as_view()에 설정됩니다.

오류 핸들 시에 'blueprint, code', 'app, code', 'blueprint', 'exception', 'app exception'에 등록된 핸들러를 사용합니다.

요청 중에 세션에 접근할 경우 응답 Vary 헤더에 Cookie가 추가됩니다. (단, 세션이 삭제되지 않았어야 합니다.)

test_request_context()가 subdomain, url_scheme 인자를 받습니다. base URL을 만들 떄 이 값들을 사용합니다.

APPLICATION_ROOT 기본값을 '/'로 설정했습니다. 사실, 원래부터 값이 None이면 '/'로 작동하긴 했습니다.

TRAP_BAD_REQUEST_ERRORS가 디버그 모드에서 기본값으로 켜집니다. BadRequestKeyError 오류가 발생하면, 일반 모드에서는 일반적인 오류 메시지가 나오지만 디버그 모드에서는 메시지에 오류 키값이 들어있습니다.

TaggedJSONSerializer에 새로운 태그를 등록하는 것을 허용합니다. 이로 세션 쿠키에 다른 형식 저장을 지원합니다.

해당 요청이 아직 context stack에 들어가지 않았을때만 세션을 엽니다. stream_with_context() 제네레이터가 포함된 뷰에서 사용하는 것과 동일한 세션에 접근할 수 있습니다.

테스트 클라이언트 요청 메소드에 'json' keyword 인자를 추가했습니다. 주어진 객체를 JSON으로 덤프하고 적절한 Content type을 설정합니다.

요청 및 응답 클래스 모두에 적용되는 Mixin에 JSON처리를 추출했습니다. response에 is_json(), get_json() 메소드가 추가되어 JSON response 테스트가 더 쉬워집니다.

오류 핸들러 캐시를 제거했습니다. 이는 몇몇의 예외 처리에 상속 위계 문제를 일으켰습니다. MRO 통과를 피하려면 각 예외에 대해 명시적으로 핸들러를 등록해야합니다.

non-UTC datetime의 JSON 인코딩 버그를 고쳤습니다.

템플릿 자동 reloading은 이미 jinja_env에 접근했더라도 디버그 모드를 유지합니다.

다음 deprecated 코드들을 제거했습니다.

flask.ext - 확장들을 flask.ext namespace 말고 직접 import 해야합니다. ex. import flask.ext.sqlalchemy -> import flask_sqlalchemy

Flask.init_jinja_globals - Flask.create_jinja_environment()를 확장해서 사용하세요.

Flask.error_handlers - Flask.error_handler_spec으로 추적할 수 있습니다. 핸들러 등록은 Flask.errorhandler()를 쓰세요.

Flask.request_globals_class - Flask.app_ctx_globals_class를 쓰세요.

Flask.static_path - Flask.static_url_path를 쓰세요.

Request.module - Request.blueprint를 쓰세요.

Request.json - 이젠 deprecate 대상이 아닙니다.

EnvionBuilder 혹은 dict를 test_client.open에 넘기는 걸 지원합니다.

python-dotenv가 설치되어 있으면, flask 명령과 Flask.run()은 .env, .flaskenv 파일에서 환경 변수를 가져올 것 입니다.

전체 URL을 테스트 클라이언트에 넘기면, PREFERRED_URL_SCHEME 대신에 URL의 스킴이 쓰입니다.

Flask.logger가 간단해졌습니다. LOGGER_NAME과 LOGGER_HANDLER_POLICY 설정을 없앴습니다. 로거 이름은 항상 flask.app입니다.  레벨은 첫번째 접근 때 설정됩니다. 매번 Flask.debug를 확인하지 않습니다. Flask.debug에 따라 형식은 한개만 쓰입니다. 아무 핸들러도 제거되지 않고, 어떤 핸들러도 설정되어있지 않은 경우에만 추가됩니다.

Blueprint 뷰 함수는 점(.)을 포함하면 안됩니다.

유효하지 않은 Range 헤더 요청에 의해 발생하는 ValueError 버그를 고쳤습니다.

개발 서버는 기본으로 스레드를 사용합니다.

silent=True로 설정을 가져오면 ENOTDIR 오류를 무시합니다.

개발 서버에 HTTPS를 쓰고 싶으면 --cert와 --key 옵션을 flask run에 넘기면 됩니다.

세션 쿠키에 SameSite 속성을 제어하는 용도로 SESSION_COOKIE_SAMESITE를 추가했습니다.

테스트 용도로 Flask CLI 명령어를 실행할 수 있는 Click runner를 생성할 수 있도록 test_cli_runner()를 추가했습니다.

서브도메인 매칭을 기본값으로 꺼놓았습니다. SERVER_NAME 설정이 암시적으로 이것을 켜진 않습니다. subdomain_matching=True를 Flask 생성자에 넘김으로써 켤 수 있습니다.

앱에 blueprint가 등록될 때 blueprint url_prefix에서 마지막 /(slash)가 제거됩니다(stripped).

silent가 True면 Request.get_json() 파싱에 실패했을때 결과를 캐시하지 않습니다.

Request.get_json()는 더이상 임의 인코딩을 수용하지 않습니다. 요청 JSON은 RFC 8259에 근거한 UTF-8이어야 합니다. (UTF-16, UTF-32도 자동 감지합니다.)

브라우저가 무시했을 수 있는 큰 쿠키에 대해 Werkzeug가 경고할 때 이를 제어하기 위해 MAX_COOKIE_SIZE와 Response.max_cookie_size를 추가했습니다.

작은 창에서 문서를 더 쉽게 볼 수 있게 theme을 업데이트했습니다.

튜토리얼 문서와 예시 프로젝트를 재작성했습니다. 새로운 유저들이 흔히 겪는 어려움을 돕기 위해 체계화된 접근을 했습니다.

[sinwoobang]

Golang의 생산성

회사에서 크고 작은 프로젝트에 Golang을 사용해봤습니다. 알려진 장단점과는 별개로 개인마다 사용 후기가 다를 것 같더군요.

Python에서 Golang으로 넘어와본 입장에선 이렇습니다. “Golang은 좋은 생산성을 가졌다.”에 의문이 들더군요. 웹 개발, 서비스용 스크립트 작성에 Golang을 사용했습니다만 Python이 주는 문법 자율에 너무 익숙해졌는지 코드가 너무 길어진다는 생각이 들었습니다.

하지만 C++에 비해선 생산성이 탁월합니다. 모든 함수 인자에 Call by reference, value를 명시해야 한다거나, 클래스에 Copy Constructor를 만들 필요는 없습니다. 개인적인 일로 C++을 사용하다보니 Golang이 훨씬 편리하더군요.

자신이 기존에 어떤 언어를 사용해왔느냐, 어떤 상황에서 Golang을 사용하느냐에 따라 후기가 많이 달라질 것 같습니다. 개인적으로는 Python과 C++ 사이에서 성능 최적화가 필요할 때 다시 찾게 될 것 같네요. 이 글을 읽고 계신 분들도 주어진 상황에 맞게 Golang을 사용해보세요. 이 곳에 적은 내용 이외에도 좋게 생각할 여지가 많다고 생각합니다.