django 서드파티 라이브러리 개발기 (django-dynamodb-cache)

• 개요
• 여러 버전을 커버하는 라이브러리는 달랐다
• 그럼 어떻게 테스트하지?
• 하나의 환경, 동시에 도는 테스트
• django cache framework 와의 호환성
• 마무리

개요

나는 오픈소스 생태계를 좋아하는데 그 이유는 투명하게 공개되기 때문에 누구나 쉽게(?) 참여할 수 있고 모두 함께 퀄리티를 높여나가는데 기여할 수 있기 때문이다.

그리고 내가 오픈소스 라이브러리들을 무료로 사용할 수 있는데에는 많은 개발자들의 헌신이 있었기 때문이라고 생각해서 받은 만큼 돌려주고자 노력하는 편이다.

작게는 오타 수정부터 문서, 기능 개발, 버그 수정 같은 자잘한 부분에서 기여를 하고 있다. (star 를 눌러주는것 또한 기여라고 생각한다.)

나는 이번주에 django 서드파티 라이브러리를 릴리즈했다.

이전에 rcs-pydantic 을 릴리즈 해 본 경험이 있었지만 이번에는 더욱 쉽지 않았다.

개인적으로 만들면서 느꼈던점들을 정리해보려고 한다.

여러 버전을 커버하는 라이브러리는 달랐다

기존에 릴리즈했던 rcs-pydantic 은 아직 pydantic 이 버전마다 기능이 크게 차이나지 않고 왠만하면 호환되기 때문에 python 여러 버전만 호환되게끔 개발하고 pydantic 은 그냥 최신버전에 맞춰서 개발했고 릴리즈했다.

하지만 이번에 새로 릴리즈한 django-dynamodb-cache 는 시작부터 달랐다.

각 python 버전을 호환해야하고, 여러 django 버전을 함께 호환시켜야 했기 떄문이다.

django-dynamodb-cache 는 python 버전 3.8, 3.9, 3.10, 3.11 과 django 버전 3.0, 3.1, 3.2, 4.0 이 호환되도록 만들었는데, 각 파이썬 버전마다 각 장고 버전을 커버하려면 4 * 4 = 16개의 케이스를 테스트해야했다.

그럼 어떻게 테스트하지?

이전 rcs-pydantic 을 릴리즈하고 썼던 글에서는 테스팅에 대한 언급을 하지 않았었는데, 사실 github actions 코드를 살펴보면 알겠지만 github 에서 제공하는 python matrix 로 여러 버전을 나눠서 pytest 한번 하고 끝이었다.

아까 언급했던 것 처럼 django-dynamodb-cache 는 여러 파이썬 버전에 또 여러 django 버전을 테스트해야 하기 때문에 tox 를 사용하기로 했다.

간단히 설명하면 테스팅에 대한 환경을 자동으로 생성해주는 파이썬으로 개발된 자동화 툴이다.

tox 에 대한 사용법은 나중에 따로 포스팅 하겠다.

하나의 환경, 동시에 도는 테스트

dynamodb 에 대한 서드파티이기 때문에 로컬 환경에서 dynamodb에 대한 샌드박스 환경을 만들 수 없었다.

물론 mocking 을 통해 가짜 동작을 만들어주긴 했지만 aws 환경은 자주 변경되기 때문에 실제로도 동작하는지 확인이 필요했다.

그런데 테스트하려면 무조건 테이블을 생성해놓고 데이터를 넣고 빼고,, 해야하는데 동시에 16개의 테스트가 돌아버리니 테스트코드가 실패하는 케이스가 많이 발생했다.

예를들어 이런 경우인데

• 1번 테스트 코드: 값을 넣고 넣은 값이 정확한지 확인한다.
• 2번 테스트 코드: 삭제하고 삭제가 잘 되었는지 확인한다.

동시에 돌다보니 이런 순서가 자주 발생했다.

• 1번 테스트: 값을 넣는다.
• 2번 테스트: 값을 삭제한다.
• 1번 테스트: 넣은 값을 확인한다 -> 값이 없다! (테스트 실패)

따라서 이런식으로 생성되는 테이블 이름의 마지막에 랜덤값을 붙여 중복을 피했다.

test-table-name-01295329472398472
test-table-name-52874829863847843

django cache framework 와의 호환성

django 에서 내가 만든것과 같은 서드파티들을 잘 지원하기 위해 추상화를 굉장히 잘 해놓았다는 생각이 들었다.

createcachetable 같은 명령어를 그대로 사용하고, 기본 세팅에 BACKENDS 옵션만 바꿔주면 바로 동작한다는 점에서 그랬다.

반대로 django cache framework 구조를 파악해야한다는 점에서는 조금 러닝커브가 있었지만 워낙 문서화가 잘 되어 있어서 크게 어렵지 않았다.

마무리

이 프로젝트는 dynamodb 를 백엔드로 사용하는 캐시 백엔드가 없네? 라고 생각해서 시작했던 프로젝트이다.

솔직히 django cache framework 내부 구조에 대해 자세히 알지 못한 채로 개발을 시작했지만 개발을 하다보니 어쩔 수 없이 공부를 하게 된 것 같다.

이렇게 제대로 오픈소스를 만든게 처음이라 이슈가 들어오면 어떻게 해야 할지 아직 잘 모르겠지만 최소한 앞으로 django cache 와 dynamodb 에 대한 지식은 강제로 쌓일 것 같다는 예감이 든다.

마지막으로 사이드 프로젝트를 만들 때 캐시가 필요한데 redis 인스턴스를 올리기에는 가격이 부담스럽다 하시는분들은 dynamodb 캐시를 사용해 보시고 이슈나 PR 을 제출해주시면 감사하겠습니다

https://github.com/xncbf/django-dynamodb-cache