[Django 웹프로젝트] 11. 인메모리 캐시 사용해도 될까? 심층분석

동현 유 2022. 3. 19. 03:57

[Django 웹프로젝트] 10. 호환성을 고려한 소셜로그인 버그 수정 (2022-03-14~15)

(문제상황) - 소셜로그인을 통해서만 로그인이 가능하도록 구현되어있다. - OAuth2 인증 후 제공받는 사용자의 이메일 정보와, 회원가입 시 기재한 프로필 정보를 매핑해서 보관하고 있었다. - (로

letsmakemyselfprogrammer.tistory.com

위 작업 중, 소셜 계정 추가 연동 부분에서 보안처리를 변경할 때 했던 고민을 찾아봤다.

<콜백 url의 get 파라미터로 사용자 id 를 넘겨야하는 상황>

[기존 방식] - 단방향 md5 로 사용자id 를 암호화하여 넘김.
=> 복호화를 할 수 없으니 모든 사용자를 순회하면서 일치하는 확인했어야했다.

[수정 방식] - key 를 이용하여 signature 를 생성하고 id 를 제외한 signature 만 넘김.

=> signature - id 를 쌍으로 캐시에 저장하고 콜백 됐을때 캐시에서 id를 꺼냄. (인메모리 캐시)

=> 사용자 한명에 대한 쿼리만 실행하면 됨!!

인메모리 캐시로 해도 괜찮은걸까?
(동시접근에 따른 데이터 무결성 문제는 발생하지 않나?)
(파이썬은 멀티쓰레드? 멀티프로세스? 자원경합? 문제들을 어떻게 해결하나?)
uwsgi 는 python 이랑 붙어서 뭐하는 친구지..?
콜백되었을 때, 같은 프로세스에 다시 할당된다는 보장이 있나? (해당 캐시에 접근해야하므로)

: 분량이 많아서 따로 포스팅으로 뺐다. - [Python 뜯어보기] 3. 파이썬 Thread 와 GIL

: 분량이 많아서 따로 포스팅으로 뺐다. - [Python 뜯어보기] 4. WSGI 와 Python

uwsgi 설정 파일을 들여다봤다.

저번학기에 uwsgi 레퍼런스 정독해가면서 설정했던 파일인데,, 호호

cheaper 옵션을 따로 명시적으로 설정하지 않았기 때문에,

기본 프로세스 하나가 디폴트로 떠있다.

max request 를 50 으로 잡아놔서 아마 50개 이상의 동시요청이 발생하면 프로세스를 fork 할 것으로 보인다.

혼자 5개 기기로 동시접속 before after 해봤는데, 프로세스는 늘어나지 않았다.

(위에 있는 프로세스가 uwsgi 본체이고, 그 밑에 있는 프로세스가 worker 인듯하다.)

www.inhabas.com 에는 하루 평균 접속자 수가 90명 정도이고, 1인당 요청 트래픽이 평균 30건 정도된다.

간편하게 인메모리를 사용하려면, 한 프로세스 내부에서 같은 자원을 공유해야한다.

클라이언트 A 가 접속해 있는 상태에서, 소셜계정 추가 연동 요청 -> 콜백되었을 때

과연 같은 프로세스로 요청이 매핑되는것을 보장할 수 있을까?? 라는 고민.

python 앱 + uwsgi 특성 상 요청이 많으면 프로세스가 늘어나거나, 줄기도 하는데

평균 접속자 수의 통계를 보니 프로세스가 늘어날 일은 거의 없겠다!

지금은 max request 를 50으로 잡아놨는데, 혹시 모르니 더 크게 늘려놓으면 되겠다!

우리 서비스에서는 인메모리 간단하게 사용해도 된다!!

위와 같이 인메모리를 간단하게 사용해도 되지만,, request cookie 를 이용하면 된다. spring 으로 인증 모듈을 구현하다가 깨달아버렸다. (SpringSecurity 인증 모듈 개발 (OAuth2, jwt, 소셜로그인))