[12월 4주차] 도커 컨테이너 간 통신문제 해결, 배송물량 증가로 인한 프로그램 성능이슈, 앞으로의 공부 계획

1. 도커 컨테이너 간 통신문제 해결

회사에서 개발하는 서비스가 두개라, 로컬 환경에서 개발을 할 때 두 서비스의 컨테이너들을 각각의 docker-compose 파일으로 띄운다.

하나의 docker-compose 로 묶인 컨테이너들 간의 통신은 문제가 없는데, 다른 docker-compose파일로 띄워진 컨테이너와 통신을 하려니 문제가 생겼다. 

 

컨테이너 1과 컨테이너 9이 통신을 해야하는 상황

 

예를들어 컨테이너 1이 -p 50000:3000 으로 되어있다면 컨테이너 9에서 컨테이터 1으로 접근을 시도할 때

• localhost:50000 -> 안됨. (컨테이너 9에서의 localhost와 내 pc에서의 localhost는 다른 장소를 가리킴)
• 컨테이너 1의 사설ip, 예를들어 172.18.0.10:3000 으로 접근 -> 안됨. 이 방법은 무조건 되어야한다고 생각했는데 검색해 보니 맥에서 보안상의 이유로 막고있다고 한다. 관련 글: https://forums.docker.com/t/cannot-access-container-by-its-container-ip/22596/2
• 결국 컨테이너 내부에서 pc의 localhost로 연결시킬 수 있는 host.docker.internal 를 사용해서 문제를 해결했다. 관련 글 :https://www.cloudsavvyit.com/14114/how-to-connect-to-localhost-within-a-docker-container/

네트워크 지식이 부족하다 보니 꽤나 고생해서 문제를 해결했다. 통신에 성공했을 때 너무 뿌듯했다. ☺️

 

 

2. 배송물량 증가로 인한 여러 문제 발생, 임시 조치

첫 번째 이슈: 실시간 배송관리 화면 로딩속도 

퀵서비스 플랫폼에서 일을 하고 있는데, 요즘 회사가 잘되고있어서 배송물량이 갑자기 늘었다. 그래서 CS팀에서 사용하는 실시간 배송관리 화면의 로딩속도가 급격히 저하되는 문제가 발생했다(성능 안좋은 컴퓨터로 약 40초 정도). <실시간 화면은 소켓통신을 이용해서 신규오더가 들어오는 등 오더 데이터에 업데이트가 있을 경우 실시간으로 데이터를 업데이트 해 주는 페이지이다> 거기다 24일, 25일은 특히 배송물량이 많은 날이라 프로그램 성능이슈까지 더해지면 CS팀의 업무에 차질이 생길게 분명했다.

 

그래서 이번주 20일~22일(월~수)동안 프론트팀과 백엔드 팀이 성능개선할 방법을 찾아보았다.

 

성능저하 이슈가 생겼던 첫 번째 이유는 실시간 화면을 구성하는 데이터가 많다보니 프론트에서 DOM을 그리는 시간 자체가 오래걸리는것 이었다. -> 프론트단 이슈

 

두 번째 이유는 실시간 화면 구성에 필요한 여러 데이터들을 받아오기 위해 네트워크 통신이 여러번 일어나는 것 이었다. 백엔드가 MSA로 구성되어있다 보니 DB가 여러 서비스에 분산되어 있어서 데이터 조회에 필요한 key만 프론트에 던져주고, 프론트가 다시 그 key로 데이터를 조회해서 화면을 만든다. 이때, 전체 주문에 대한 데이터를 받아오고(API 콜 1번), 각 주문에 대한 주문자, 배송원 정보를 받아오기 위해서 API콜을 2번 더 해야한다. 그래서, 실시간 배송물량이 500개 정도 되면 실시간 화면을 구성하기위해 API콜을 최대 1000번 해야하는 상황이 발생한다... (500개 주문이 모두 다른 고객, 배송원을 가지고 있는 경우) 지금 생각해보니 더 심각하게 느껴진다. 

 

당장 배포해서 주말에 사용해야 하는거라 대대적인 개선은 힘들었고, 백엔드에서는 실시간 화면에서 오늘 배송물량만 보여주도록 API를 새로 만들었다(예전엔 배송완료되지 않은 모든 건이 실시간 화면에 나옴). 이것으로 약간의 속도개선은 되었다. 

 

그리고, 프론트에서 루프를 돌려 일일이 계산하던 값들(raw데이터에서 정보 가공하기)를 백에서 하도록 수정하였다. 미세한 성능개선이 있었다.

이때 몽고의 쿼리로 전부 계산하였는데 역시 mongoDB 는 데이터를 넣을땐 편하지만 꺼내올 땐 불편하다는걸 느꼈다..💦 mongoDB를 이용해 데이터를 가공하려 하면 쿼리가 정말 복잡해진다. (SQL으로 얼른 갈아타고싶다)

 

그래도 위의 API콜 수 문제는 얼른 해결해야할 문제이다. 지금은 서버부하가 생기면 AWS에서 인스턴스 수를 늘리는 방법으로 해결하고 있지만 서버를 무한정 늘릴  수는 없으니깐.. 

 

 

두 번째 이슈: 오더데이터 정렬 시 앱이 죽는 문제

크리스마스 기간에 오더수가 매우많이 늘면서 배송기사분들이 사용하는 어플이 죽는 문제가 나타났다.

원인은 새로운 오더가 들어올 때 마다 앱에서 오더데이터를 픽업시간 + 나와의 거리 두 조건으로 정렬을 하는데, 배송가능 오더수가 많아지니 정렬에 시간이 오래걸리고, 정렬하는 중에 계속 새로운 오더가 들어오면 다 처리하지 못하고 죽는것이었다...

 

오더데이터 정렬도 애초에 앱이 아니라 백엔드에서 해 주는것이 맞다고하는데, 이 부분을 당장 다음날 까지 고치긴 힘들어 임시방편으로 현재시간으로부터 4시간 이내(상황에 따라 시간 조정) 픽업인 물건들만 어플에서 확인할 수 있도록 하자는 얘기가 나왔다. 그럼 어플이 정렬해야 할 오더수가 줄어들어 문제가 조금은 개선될 것 같았다. 이것은 미리 코드를 작성해 놓고, 앱 사용관련 불만이 접수되면 바로 배포할 수 있도록 준비하였다. 

다행히도(?) 이 기능은 배포되지 않았다.

 

 

3. 꾸준히 할 공부 분야 정하기

백엔드 개발자로 일하면서 부족한 부분은 너무 많이 보이는데 무엇부터 공부해야 할 지 막막했다. Node.js를 하고 있으면서 다른 언어에 비해 제대로된 로드맵이 없다는 생각에 Java/Spring으로 갈아타야하나 하는 생각도 했다. 그래도 Node.js 가 앞으로 점유율을 더 늘려갈 것 같고, 지금까지 한 것을 다 버리고 새롭게 시작하긴 아까워서 Node.js를 팔 수 있는곳까지 파보기로 했다. 근 한 달여 간 여러 책들, 강의들을 거치며 방황한 끝에 일단 공부 분야를 세 가지로 압축해 보았다. 

 

첫 번째. 회사일에 필요한 지식 공부. 

두 번째. Javascript 중급 + 상급(?)책 공부.

    Eloquent Javascript를 2022년 3월까지 보고, You Don't Know JS를 2022년까지 끝낸다!
세 번째. Node.js 오픈소스 모듈 분석 + 기여.

    Axois라는 오픈소스를 분석하고있다. 회사코드에서는 사용하지 않는 고급기술들이 많이 사용되어 해석하기 힘들지만 열심히 분석해서 내년 1월안에 PR 하나를 보내는게 목표!

 

번 외로 1일1커밋, 개발 블로그 꾸준히 쓰기 등이 있다.

 

2022년는 2021년보다 더 즐겁게 개발을 할 수 있으면 좋겠다. 😁