시간과 공간 그리고 진실의 방

전 포스팅에서 한번 언급한 바가 있지만, 고도몰에 접속하거나 토큰에 의해서 데이터를 가져오게 되는 경우 Session 연결을 성립하게 되는 경우다.

Android 단에서 ApiService.kt 단에서 GET method 방식으로 Shop의 User Profile 을 확인하는 부분을 추가시켜 주었고, 원래라면 앱이 켜졌을 때마다 accessToken 을 가지고 고도몰에 대해서 End-Point 단위로 request 를 날려주려 했으나 비효율적이라는 판단이 들은 것 같다.

1.

앱을 사용하는 사용자들이 전부다 샵을 이용할 계획이 있는 것은 아니기 때문이다.

이러한 부분에서 앱을 키자마자 무조건적으로 샵에 대해서 request 를 전송하게 되면, 불필요한 트래픽과 동시에 request 가 발생하게 된다.

2.

WebView 에 의해서 Shop 이 로드됫을 때 (init) 시점마다 request 를 던져주게 되면, 자연스럽게 WebView 안에 있는 Web 에 대해서도 Session Handling 을 할 수 있게 되기 때문에 이 부분이 구조적으로 볼 때에 정상적이라고 볼 수 있을 것 같았다.

여하튼 패치 후, 정상적으로 세션 끊김 문제는 해결되었고

 Signed Key를 이용하여 Deploy 를 하기위해 Android Market 에 검토요청을 올렸다.

세션 풀림 문제 중 가장 중요한 것 하나는 Android Side - Back-end Side - Godomall 로 이어지는 연계순서였다.

중간에 이 과정에서 Spring 에서 "Bearer " 에 대한 String 을 떼어버리고 파싱한 뒤에 Godomall 쪽에 이어지는 순서로 접근하게 되는데, 이 과정에서 다시 한 번 Session Connection 이 이루어질 수 있었다.

자 그러면 본론으로 돌아가서 왜 한번의 Session 발급 이후에 Session 이 풀리고나서 로그인하기 힘들었던 이유가 있었는지 생각해보자

1. 

Moyamo Android Side run - init - Shop request 

이 순서상에서 이루어질 때, 앱을 처음 실행한 사용자라던가 캐시가 없는 사용자라면 해당하는 부분에 대해서 다시금 Session Sync 가 이루어졌어야 하기 때문에 한번의 연결은 정상적으로 작동하게 된다.

다만 그 이후에 refresh Token 이라던지 access Token 이 들어왔을 때에 주기적으로 돌아야 하는게 없었기 때문이다.

- 물론 이 부분에 대해서 찾아보면 refresh Token 이나 access Token 에 대한 로직이 있을지라도 활성 사용자수인 25만명에비하여 실사용자는 5~7만명에 그칠 것이기에 데이터베이스에서 직접 긁어다가 작동시키는 부분은 생각보다 비효율적인 트래픽을 야기할 수 있다.

2.

그렇다면 어차피 끊긴 김에 User의 Shop Profile 을 확인하는 End-Point 를 호출해서 소환하는 구조로 간다.

- 이 경우 Android 사이드에서 앱이 켜질때마다 request 를 날려주는 번거로움이 있긴 하지만 적어도 Session 에 대한 안정성은 보장할 수 있다. 따라서 Web-View 상에서 불러오는 쿠키의 Session 에 대해서도 변함없이 사용자가 서비스를 지속적으로 이용하게 해줄 수 있다.

따라서 이번엔 2번으로 접근하는 것을 유도해보고, 1번은 별도의 분석에 들어가기로 했다.

발생했던 Shop 에서의 Session 동기화 문제를 정상적으로 수정했다.

일단 내가그린기림기르김그림 을 기반으로 설명해보자면

결과적으로 예전에 China Developer 에 의해서 Credential Key가 노출되서 이 부분에 대해서 변경하고 재배포 하는 과정에서 Scheduler 를 가동할 수 있는 곳이 따로 있었던 곳을 발견했다.

즉  tools 인스턴스 안에서도 가능하고, scheduler 인스턴스 안에서도 가능했던 것이다

문제 1. Ranking Serviece 및 Score 부분에서 2번 집계되는 현상 발생

자 이 부분에서 해결하기 위해서, scheduler 인스턴스 내에서 관리할 수 있도록 해당 부분에서 daemon을 activate시키고

tools 에 있던 scheduler 는 deactivate 시키는 것을 했었다. 

그 이후에 참조를 이루는 부분에서 scheduler 에 있는 부분에서 sync 가 정상적으로 이루어지지 않았으니

tools 에 기반하는 scheduler 에서 정상적으로 작동할 수 있냐는 의문을 가졌던 것이다.

그렇게 판단한 기반 근거를 살펴보자

1. scheduler 내에서 사용되던 log 가 2020 ~ 2021년 사이에는 존재했으나, 그 이후에는 로그 기록이 확보되지 않았다. 물론 이러한 부분에서 log rotate 가 작동된 것일 수 있겠으나, 이러한 부분에서 deprecated 됬었을 수 있다는 것을 추론 할 수있다.

2. tools 내의 scheduler 에서 가동되던 log를 살펴보면 2022년 6월 22일 정도를 마지막으로 이루어졌다가 이후 약 2~3개월의 Gap 이 있다가 다시 3월까지 이루어졌었다.

이러한 부분에 의하여 Scheduler 가 고도몰의 Custom Session Method 를 연결하여 지속적으로 연결을 성립하는 역할을 한다면, 충분히 참조될 만 하다는 것이다.

그렇다면 여기서 놓치고 있는 것이 무엇이였을까?

추측 가능한 결론

1. 아마도 EIP 에 의해서 Static IP가 주어지고, 해당하는 부분에 의해서 지속적으로 연결을 수립하여 생기는 과정 중에 tools 에 고정해놨을 반면에 scheduler 에서는 EIP 가 배정되지 않았던 것과 동시에 별도의 IP가 존재하는 부분

하지만 이러한 부분에서 약간의 추론을 더 생각해보자면, 내부적으로 ELB를 호출해서 rest 쪽을 호출했었고, 이러한 부분에 의하여 rest의 End-Point 를 호출하기 때문에 별도의 Scheduler 에 의한 부분을 찾지 못했던 것이다.

추가적으로 찾아봐야 할 것

샵에서 로그인이 풀리는 이슈나 종종 로그인 세션이 잡히기는 하지만 풀리는 이슈에 대해서 완전히 해결되긴 하였다.

하지만, tools 에 관련된 부분을 참조하여 지속적으로 이루는 부분이 있는지 확인사살을 해야할 것 같다. 아마 분명히 있을 것이라 본다.

AWS Instance 내에서 기본적으로 보여지는 2가지의 Duplicated 된 것이 보였는데,

moyamo-scheduler 

그리고 moyamo-tools 내에서 운영되는 scheduler 가 중첩되었었다.

이러한 부분에서 두 가지의 scheduler 가 다른 역할을 하냐고 물어본다면, 역시나 아니다.

한 가지의 scheduler 는 분명히 suspend 되거나 terminated 되었어야 할 것 같은데, 내부 Log상으로 봐서 예전에 쌓여있던 로그 자체에서도 moyamo-scheduler 는 2021년에 사용하던 기록에서 유래된 것이고, 이러한 부분들은 확실히 ELS와 기타 다른 module 들이 합쳐진 곳에서 운영되는 scheduler 와는 별도로 관리되었던 것이다.

여하튼 2개를 같이 키면 당연히 scheduler가 2번 수집하게 되므로, Record 도 2번 쌓이게 되는데

그렇다면 발생하는 문제는

랭킹 Score 에서 2배로 쌓이는 것

그리고 해당하는 부분에 있어서 Score 가 문제가 아닌 댓글 Counting 에 대해서도 2배가 되는 현상이 발견되었었고

이 때문에 해당하는 부분에 대하여 해결하기 위하여 예전에는 moyamo-scheduler 내에서만 daemon을 가동시키고

tools에서는 종료를 시켰었다.

하지만 관리 포인트의 증가와 동시에 Tools 에서 참조하는 문제가 뭔가가 벌어졌어지리라고는 생각하지 못했는데,

공교롭게도 전 개발사에 의하여 Credential Key가 노출되는 상황이 벌어졌었고, 그 때문에 Credential key를 교체하는 상황에서 해당하는 부분에 대하여 내가 인지하지 못했었다.

그 이후에 Credential Key를 교체하고 전부 jar 로 컴파일하여 정상적인 모듈로 탑재하였으나, 모야모 샵 내에서 고도몰 세션 이슈가 발생했었는데.. 아무리 코드를 분석해봐도 예전에는 정상적으로 작동되던 것이 어떤 부분때문에 문제가 되는지 정말 어리둥절 하기도 했고

그 때문에 Spring - Android - Godomall 사이에서 오가는 Log를 수집하면서 accessToken 에 대한 byte 길이의 차이라던가 그런 부분에 대하여 파악하기도 하였고

Godomall 내부에서 overwritten 된 Custom Session Code에 대하여 전부 분석해보았으나, 에러찾기는 굉장히 애매한 상태인 것이다.

고렇다면 문제가 무엇일까

1. 

아마 예상컨데 Session 을 주기적으로 연결하고 끊는 과정에서 생기는 어느정도의 간헐적인 Delay 이슈일 수도 있을 것

2.

그리고 Android 에서 Spring 쪽을 호출하고, Spring 쪽에서 호출하는 뭔가 메세지 브로커 같은 것이 정상적으로 관리가 안되고 있을 가능성

3. 

망할놈의 Hikari CP 안에서 정상적으로 데이터베이스에 대해서 놓고 빼고 놓고 빼고를 하지 못할 가능성

그렇다고 해서 커넥션 풀을 최적화 하는걸 배제하고 read, write instance 에 대해서 증가시키는 것은 좀 에바참치니까 일단 풀부터 조져봐야한다

4.

고도몰 내에서 작성된 Custom Session 코드와 Spring 쪽에서의 통신 문제 - 근데 이건 다 살펴봐서 패스

5.

Android 측면에서 발견될 문제로 생각될 수도 있는데, 이건 Yagnesh 가 아무리 생각해도 Back-end Issue 라고 하니까 뭐 어케든 처리해야것다