Razelo 기술노트

최근 만들고 있는 어플리케이션에서 큐를 사용하게 되어 큐를 사용하는 아키텍쳐에 대한 고민을 해봤다.  복잡하게 데드레터 정책까지 가져가면서 큐의 메세지에 대한 retry를 실행하려하진 않았다. 실패한 메세지의 경우 어차피 깨진 상태를 갖고 있다고 가정하고 warn 로그를 남기고 아카이브에 해당 작업을 실패로 기록한 뒤 큐에서 곧장 소비해서 없애버리는 정책을 가져가고자 했다.  큐에 넣을 메세지는 어떤 작업을 지시하는 Job에 대한 정보로 사용하고자 했다. 그러다보니 api endpoint를 한 개만 남겨두고 기존에 만들어뒀던 api들을 모두 없애버리는 방법도 있었다. 한 개의 endpoint는 queue에 submit하는 역할만 하는 일종의 producer전용 api가 되는 것이다. 반대쪽 consume..

작년 2월에 입사하고 벌써 1년이 훌쩍 넘었다.  졸업하자마자 곧장 신입으로 일했고 이것 저것 하다보니 벌써 신입 타이틀을 떼고 주니어가 되었다는게 신기하다.프론트엔드, 백엔드 등등 가리지않고 많은걸 해볼 수 있었다. 신입, 주니어, 시니어 등등 이런건 그저 호칭에 불과하지만 오늘따라 유독 와닿는 단어인것 같다.  마침 카페에 와서 글을 쓰다보니 유독 의미에 대해 생각하게 되는 것 같다.  처음 입사했을 때 지라 티켓만드는 것도 몰랐고, git rebase를 할 줄 몰라서 꼬인 커밋을 해결하지못하고 다시 clone받아야했던 적도 있다. MR은 어떻게 드려야하는지, 질문은 어떻게 해야하는지 그리고 문서 작성과 업무에 대한 공유까지 모든게 낯설었다. 어려운 프로젝트도 있었고 쉬운 프로젝트도 있었다. 그래서 ..

최근 exception핸들링에 대해서 고민이 있다. 애플리케이션을 만들때 어떻게 예외를 처리해야할지에 대해 근본적인 해답이 없다는 생각이 든다.  외부 api호출같은 IO작업에서 주로 try catch같은 exception 처리를 하는게 좋은데, 이미 요청이 실패하거나 크리티컬한 이유로 실패해서 exception이 터졌다면 애초에 처리하고자하는 정상적인 상태에서 깨진 상황인데 이상황에서 뭘 더 핸들링할까라는 생각이 든다. 바꿔 말하자면 이미 깨진 상태인데 뭘 더 하겠냐라는 뜻이다.  크리티컬한 이슈가 아닌 경우를 생각해보자면, 뭔가를 등록하려는데 중복 등록이라던지 혹은 워닝으로만 남겨도 될만한 작업이라면 쉽다. 그런데 인증이 잘못되었거나 뜬금없는 timeout 혹은 전혀 대비되지 않았던 예외케이스처럼 크..

아래 것들을 공부해야할 것 같다...  KotlinMSA DynamoDB MySQL