24년 1월 17일(수요일) - 72번째 TIL

오늘은 주간 멘토링을 받았다. 

 

오전 10시 10분에 받는 거였는데 팀원 한 분이 오전 6시까지 작업하시다가 졸아서.. 하마터면 멘토링 늦을 뻔했다 ㅋㅋ 

 

멘토링을 고봉밥으로 받아서, 정리를 한다고 했는데 한번 더 정리를 해야할 것 같다. 

 

크게 정리하면, 아키텍처 구상도 다시 하고, 기술 면접 준비를 잘 하자.. 이다 ㅋㅋ 

 

 

우선 스프링 배치를 쓴다고 하니, 배치와 스케쥴링의 차이를 물어보셨다. 

이건 단골 질문이니 알고 있었고, 정리를 하자면 배치는 특정 시점에 일괄 데이터를 처리하는 작업이고, 스케쥴링은 매 주기마다 특정 작업을 실행하는 작업이다. 

 

또 팀원분이 스프링 쿼츠랑 스프링 배치에 대해 어느 것을 쓰는 지를 여쭤봤었는데, 스프링 배치라 쿼츠를 흡수하여 현재는 스프링 배치 라이브러리를 다운받으면 쿼츠도 함께 다운받아진다고 하셨다. 질문을 할 때 참고 링크글이 11년 전임을 지적하면서, 기술 관련 구글링을 할 때는 가능한 3년 이내의 글을 참고하라고 하셨다. 

 

또한 동시성 관련 질문을 했을 때, 동시성 제어의 주체가 누구인 것 같냐고 역질문을 하셨다. 답변을 못하니 3 tier 아키텍처에서 가장 중요한 부분이 어디라고 생각하는지 물으니, 팀원은 둘간을 연결하는 컨트롤러가 중요할 것 같다고 대답했지만, 동시성 제어의 주체는 DBMS라고 알려주시며 모델이 중요하다고 하셨다. 

 

동시성 제어가 일반적으로 왜 필요로 하는지를 물으니 ACID를 지켜야 하기 때문이라 답했고, ACID하면 무엇이 좋은데 지켜야 하냐고 물으니 데이터 정합성을 유지할 수 있기 때문이라 답했다. 

 

 

아! 그리고 우리 서비스에서 배치 작업을 하는데, 인스턴스가 2개인 상황에서 어떻게 배치작업 중 동시성 제어를 할지를 고민했었는데, 우선 멘토님은 배치 인스턴스를 따로 띄워서 작업을 우선 말씀해주셨지만 물리적으로 구현 시간이 오래걸린다고 했다. 그래서 다음으로 기존 인스턴스에서 딱 1대만 실행하도록 (첫 번째 인스턴스가 담당하도록) 하게 하거나, 이마저도 안 되면 레디스 분산락을 걸라고 하셨다. 

 

하지만, 사실 우리가 이렇게 개발하는 것보다 돈 주고 상용 SW 쓰는 것이 더 낫다고 하셨다 ㅋㅋ 

그리고, 멘토링 이후 생각해보니 이는 람다를 이용하면 쉽게 해결될 문제라고 생각이 났다. 마침 나는 람다 쳐돌이라서... js랑 python으로 람다를 기존의 앱서비스에서 적극적으로 사용해오며 금방 개발할 수 있었기 때문에, 이는 아마 나중에 내가 담당할 것 같다. 

 

그리고 파사드나 프로바이더 쓰는 것은 그냥 ~~이란 문제가 있었고, 이를 해결하고자 ~~란 방법을 썼다 정도로만 가져가는 걸로 마무리했고, 아키텍처 구상도는 그림 상에 Saas와 functuon이 섞여있어서 유튜브 영상을 주셔서 이를 참고해서 재구성을 해보라고 했다. 

 

레디스를 지금은 EC2에 띄우고 있는데, 특별히 문제가 없다면 Elastic cache로 넘어가지 않아도 되는지를 물었었는데, 특별히 서비스를 하면서 문제가 없다면 현상유지해도 괜찮다고 했다. 하지만, 우리가 지금까지 단일 장애 지점 제로를 목표로 하는데 레디스만 EC2에다가 쓰고 있으니 이보다는 EC에다가 올리는 것이 더 좋다고 생각이 들어서 나중에 시간 남으면 변경해봐야 겠다. 

 

또 부하테스트를 어디다가 할지도 물었었는데, 그 전까지 전혀 생각을 못 해본 문제였다. 그냥 도메인에 쏘면 되는 거 아닌가? 하고 있었는데, 클라우드 프론트를 통하게 테스트하면 캐싱 성능을 테스트해보는 거고, 로드 밸런서를 통하게 테스트하면 부하가 잘 분산되는가를 테스트해볼 수 있는 거지만, 이는 돈이 많이 들어서 회사에서는 보통 안 하고, 또 우리의 서비스를 테스트할 때도 이를 테스트할 목적은 아니기 때문에 EC2에 바로 쏴줄 것 같다. 

그리고 오토 스케일링 테스트도 대용량으로 할 필요 없이 일회성으로 테스트해볼 수도 있다. 

 

정리한다고 했는데도 고봉밥이네 ! 흡수 잘 해서 내 것으로 만들어야 겠다.