ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 이상하게 데이터가 누락되어지는 경우 잡아내기
    잡담 2023. 5. 29. 14:20

    서론

    반도체 MES(React+Django) 관련 프로젝트를 도와줬던 때의 일이다.

     

    해당 프로젝트의 경우에는 기한이 약 2달 정도 남아있었고

    그때 설명으로 들었을 때에는 거의 개발이 완료되었고 버그 부분만 수정을 해주면 된다고 이야기를 들었었다.

    그래서 나의 입장에서는 음... 쉽겠다라고 생각을 하고 일을 진행했었다.

     

    그런데 그때 당시에 그 일을 맡고 경악을 금치 못했던게 세번이 있었는데

    첫번째는 서비스의 속도가 너무 느리다는 것

    두번째는 코드의 퀄리티가 너무 떨어졌다는 것

    세번째는 거의 개발이 완료되었다는 것이 거짓말이었다는 것

     

    서론 해결

    일단 서비스의 속도의 원인은 70%(React) + 30%(Django) 였다.

    일단 React 의 경우 쓸데없이 전체부분이 재렌더링이 되어지다보니

    속도저하 이슈(5초)가 생기고 있었고 그것을 다시 컴포넌트화해서 해당 부분을 필요한 부분만 재렌더링되게 개선했다.

    이렇게 했을 때 다행히 속도 저하가 많이 줄었고(1초 이내로) 일상영역에서 쓸수있는 범주내로 만들어졌다.

    그리고 Django의 경우 DB 관련해서 bulk로 처리해야 할 것들이 각각 하나로 처리되어지다보니 그 속도가 매우 느렸다.

    참고로 bulk로 해도 느리기는 했을 것이다. N+1 문제도 발생하고 있어서 해당 부분을 prefetch (상황이 역참조) 를 사용해서 해결을 했다.

     

    두번째의 경우에는 솔직히 전체를 건드리지는 못했고 필요한 경우에만 내가 개선을 진행했었다.

    왜냐하면 누군가는 유지보수를 해야할텐데 코어에 있는 코드들이 너무 지저분하면 사실 그 누구도 일을 하기 싫을 것 같아서

    어려운 부분은 주석을 달면서 진행을 했고 코드만으로도 나름 의미가 해석되게 작성했었다.

     

    세번째의 경우에는 총 공정이 31개의 공정을 관리를 해야한다면

    이 프로젝트를 착수했을 때 공정이 약 15개 반?만 관리를 하는 코드가 작성이 되어있었다.

    사실 이때 뭔가 문제가 있는 것이기에 애매했지만 그래도 진행을 했다.

    하나의 웨이퍼가 있으면 그것을 통해서 만들어지는 완성품을 이력관리를 해야한다.(품질, 수율, 폐기율 등등...)

    그런데 특별한 공정때마다 그 부품이 쪼개지는데 만약에 1개의 웨이퍼가 있으면 어떤과정을 지나면 16개의 다이?로 쪼개졌었다.

    그리고 또 어떤 공정을 지나면 쪼개지고 그래서 최종적으로 1개의 웨이퍼에서 256개의 칩? 으로 가는 과정을 이력을 남기고 했어야했는데 그 특별공정이 16번 부터 일어나는 데 그것이 안되어있어서 문제가 있었고 그것을 구현했었다.

     

    본론

    앞에서 말했듯이 공정이 15개 반으로 되어있었다라고 말했었다.

    이유는 여기에서도 진행을 하다가 멈추었기 때문이다. 이유는 다른 일들이 겹쳐서 바빠졌기 때문이다.

    뭐 그래도 되어있는 코드를 보고 나도 어느정도 감을 잡으면서 하고는 있었기에 도움이 되었다.

     

    그런데 문제가 생겼었다.

    원래 기존에 있던 코드를 통해서 구현을 하고 다음 공정에 부품이 쪼개지는 것을 확인해야하는데

    문제는 이전 부품은 완료처리가 되었는데 중간에 부품이 쪼개져서 생성이 되지않는 것이었다.

     

    그래서 해당하는 부분을 찾으려고 처음부터 진행을 했었는데 동일하게 오류가 발생을 했으면 좋겠지만 또 그러지는 않았다.

    이럴때가 난감하다. 차라리 무조건 발생하는 오류라면 빠르게 원인파악을 하고 문제를 해결하는데 그러지 못했던 것이다.

     

    문제는 이러했다.

    종종 16번 공정에서 이전 부품에서 완료처리는 되었지만 파생 부품이 생성이 되지 못하는 오류가 발생

     

    본론해결

    일단 문제 파악을 위해서 나는 전체 순서를 테스트하는 코드(1번 부터 16번까지의 공정 테스트 코드)를 작성했다.

    이유는 이전 사람들이 테스트코드없이 하나하나 작업을 했고 이게 참 노가다랑 다를 게 없었다.

    만약에 16번에서 케이스가 발생을 안하면 다시 1번부터 시작을 하는 기이한 일이 발생하기 때문이다.

     

    이렇게 테스트 코드를 작성해서 돌려보니 문제를 빠르게 파악을 할 수 있었다.

     

    문제는 웨이퍼에 초기에 시리얼 넘버같은게 붙는데 이 시리얼 넘버를 통해서 앞으로 붙을 부품에도 웨이퍼 시리얼넘버 + 부품 넘버 이러한 형태를 띄게되어진다.

     

    그런데 이러한 과정에서 만약에 적법한 시리얼넘버가 들어오지 않는 경우에는 에러를 발생하게 되어지는데 이러한 부분들이 기존에 정확하게 작성이 되어있지 않아서 문제가 발생했던 것이다.

     

    그러다보니 이전 작업에서는 완료가 되었지만 다음 작업에 생성될 부품들이 생성이 되어지고 그 다음에 외래키가 설정되어져야하는데 해당 부분이 오류를 통해서 중간에 문제가 생기다보니 누락이 되어지는 부분이 생긴 것이다.

     

    이것 또한 단일로 처리되어지다보니 만약에 16개가 생성이 되어져야한다면 11개쯤에서 생성하다가 오류가 발생해 터졌던 것이다.

    그러니 누락이 되어진것이였다.

     

    그래서 내가 했던 경우는 다음과 같았다.

    1. 시리얼 넘버 작성 기준과 시리얼 넘버가 이상한 경우 대응 방안

    2. 원자성 부여로 중간에 문제 발생시 롤백을 시키는 방안

    3. 1~31 번 까지의 공정 관리 코드 작성 및 테스트 코드 작성

     

    결말

    다행히 일은 별 문제없이 마무리 되었고 성능도 많이 개선이 되어서 나름 만족을 하면서 작업을 했었다.

    사실 성능은 10초에서 1초 안으로 줄이는 것은 의외로 쉬운 경우에 속하는 것 같다.

    진짜로 계산 양이 방대하지 않은 경우에는 보통은 소스코드에 문제가 있기 때문이다.

    물론 이번 프로젝트의 경우에는 계산이 많기는 했다.

    아마 저기가 한달에 쌓이는 데이터를 봤을 때 1억개 정도는 쌓였던 것 같았다.

    그래서 초기에 어느정도 DB 작업을 하면서 고려하면서 진행을 했지만 현재는 잘 되어지고 있는지는 모르겠다.

    그리고 이 프로젝트를 통해서 치질을 얻어서 3일간 고생했다. ㅠㅠ

Designed by Tistory.