[프로젝트 회고] 코드스테이츠 DOB 3번째project

벌써 3번째 프로젝트가 끝났다는게 사실 믿기지는 않는다... 정말 이번이 마지막이라는 마음으로 해왔는데 얼추 성장 하고 있다는 생각은 든다 이번에 끝낸 프로젝트가 마이크로서비스 아키텍쳐를 서버리스로 구현하는건데 몇주 전 이였으면 이게뭐지... 이벤트를 어떻게 받는다고?? 이랬을건데 아무 트러블 없이 팀원분들과의 협업이 문제없이 끝났다..

 

 

프로젝트의 내용으론 주어진 시나리오를 보고 마이크로 서비스 아키텍쳐를 구성해서 서버리스로 구현 하는것이였다 

다이어그램을 설명하자면 세일즈 API를 통해 도넛을 구매하다가 제고가 떨어진다면 SNS로 제고가 떨어졌다는 이벤트가 날아가게되어서 정해진 수량만큼 sqs대기열로 메세지를 폴링해서  stock lambda에게 공장으로 만들어 달라고 메세지를 보내게된다 보냈다면 공장은 제고관리 하는 stock increase API로 만들어진 도너츠가 창고에 적재 되어진다 아래의 sqs대기열은 재고가 떨어졌을때 도너츠를 광고하고 있는 광고 담당자에게 광고를 멈춰달라는 내용을 ses를통해 이메일이나 SMS로 내용을 보내게되는 서비스이다 

 

 

느낀점

프로젝트를 진행하면서 어떤 상황에 서버리스로 마이크로서비스 아키텍쳐를 구성해야하는지 정확하게 알게된거같다

솔직히 부트캠프 들어오기전에 MSA많이들어봤었다... 근데 정작 "왜" 그리고 그렇게 좋은데 많이들 사용하지를 않는데 이게 의문이였다

문서를 찾아보면 모놀리식 배포방식으로 문제가없다면 굳이 마이크로서비스 아키텍쳐를 구성을 할 필요없다고도 말을 하고있다

하지만 로직에서 특정 로직이 자주 불리지않고 있다면 그건 리소스낭비가 생길 수 있다는것이다

이게 무슨 말이냐면 카톡으로 얘를 들어보겠다 카카오톡의 주 서비스는 채팅이다 채팅 관련 서비스는 계속해서 요청되는 로직이지만 프로필 사진은 기본인 사람들도 있으며 상대적으로 계속해서 주기적으로 불려지는 서비스는 아니다 이점에서 충분히 로직에서 분리해서 서버리스로 구성한다음 프로필 사진만 따로 처리하도록 로직을 구성하는게 비용적으로도 더 이득이라고 생각이든다 또한 sqs를 사용 하면서 비동기요청을 정확하게 이해 할 수 있었다 모놀리식 배포방식에서는 내부 로직이 서로 얽혀있으며 동기적으로 처리되어진다 그러다보니 특정 로직에서 에러가 발생한다면 얽혀있는 로직들이 연쇄적으로 에러가 발생할수 도있다 이러한점을 sqs 대기열을 통해 서로 로직에대해 책임을 확실하게 분리 시켜 에러가 발생해도 다른 로직에 피해가없도록 도움을 줄 수 있다

 

sqs로 느슨한 결합을 구현할때 FIFO 방식을 보다가 선입선출??? 순서 보장이라는 뜻만보고 FIFO로 구현 하려했었다 근데 생각해보니 

내가 하는 프로젝트에 정말 순서 보장이 필요한가였다 

 

FIFO의 사용 사례로 아래의 공식문서에서 확인할 수있는데 금융이나 환율 판매 가격등 변동성이나 순서에 맞게 가격을 정해야하는 곳에 어울린다고 생각이 들었다

다음 예에서는 Amazon SNS FIFO 주제 및 Amazon SQS FIFO 대기열을 사용하여 자동차 부품 제조업체에서 구축한 전자상거래 플랫폼을 설명합니다.

이 플랫폼은 다음 세 가지의 서버리스 애플리케이션으로 구성된다.

• 인벤토리 관리자는 가격 관리 애플리케이션을 사용하여 재고가 있는 각 항목의 가격을 설정합니다. 이 회사에서는 환율 변동, 시장 수요, 판매 전략의 변화에 따라 제품 가격이 변동될 수 있습니다. 가격 관리 애플리케이션은 가격이 변경될 때마다 SNS FIFO 주제에 가격 업데이트를 게시하는 AWS Lambda 기능을 사용합니다.
• 도매 애플리케이션은 자동차 차체 상점과 자동차 제조업체가 회사의 자동차 부품을 대량으로 구입할 수 있는 웹사이트에 대한 백엔드를 제공합니다. 가격 변경 알림을 받기 위해 도매 애플리케이션은 해당 SQS FIFO 대기열에서 가격 관리 애플리케이션의 SNS FIFO 주제를 구독합니다.
• 소매 애플리케이션은 자동차 소유자와 자동차 튜닝 애호가가 차량의 개별 자동차 부품을 구매할 수 있는 다른 웹사이트에 대한 백엔드를 제공합니다. 가격 변경 알림을 받기 위해 소매 애플리케이션도 해당 SQS FIFO 대기열에서 가격 관리 애플리케이션의 SNS FIFO 주제를 구독합니다.

우리의 서비스로는 단지 제고가 부족하다는 메세지를 sns로 보내고 제고를 몇개 채워넣는지 메세지를 sqs에게 보내기 때문에 결과적으로 순서만 맞다면 문제가 없었다 그렇다보니 sqsFIFO를 쓸 필요가 없었다 

 

마이크로서비스 분명 좋은 방식이다 하지만 느꼇던건 만들어가면서 산으로 가는 느낌을 받았다 내가 아직 부족해서 그랬던건지... 생각 해야하는게 너무 많아지고 고려해야할점이 너무 많았다 어디까지를 도메인을 잡아야하는지 이벤트가 문제없이 전달이되는지 정말 느슨하게 결합이 되어있는지... 그래도 팀원분들과 구현하면서 너무 재미있었다 트러블 슈팅도 트러블슈팅이지만 누구하나 빠짐 없이 적극적인 자세로 임해주셔서 너무 좋았다

 

동기분들이 나에게 정말 잘한다고 말씀해주시지만.. 나는 항상 내가 부족하다고 느낀다 누구와 비교하는것도 좋아하질않아서 가끔씩은 스스로에게 스트레스를 받을 때도 있다 너무 느린거같고 부족해서 답답해서.. 근데 또 다행인게 이게 나를 자극하는 원동력이 되는거같아서 다행인거같다 휴식문제 때문에 걱정이많은데... 그건 취업하고 생각해도 늦지않을까 하고있다... 긴장감을 놓치고싶지않다

 

 

읽을거리

https://docs.aws.amazon.com/ko_kr/sns/latest/dg/fifo-example-use-case.html

FIFO 주제 예 사용 사례 - Amazon Simple Notification Service