2차 스프린트 회고

220814 블로그 포스팅

1. 들어가며
   1. 2차 스프린트가 끝난지 꽤 됐는데, 너무 늦지 않게 써야할 것 같아서 적는 포스팅이다.
   2. 2차 스프린트의 목표는 1차 스프린트에서 발생한 많은 구조적, 비용적 문제들을 해결하고, Cycle Time과, 그에 따라 나올 수 있는 지표들을 구체화 하는 것 이었다.
   3. 물론 다 하는 것은 실패 했지만… 그렇다. 열심히 살았다. 스프린트가 끝나고 나서도 잔업하느라고 블로그를 못 썼다.(핑계다.)

이전 아키텍처

레이어를 두개로 나눠서 이벤트를 처리해주는 아키텍처 예시. 이 정도는 너무 부담스럽다.

우리와 조금은 비슷한 구조를 가지고 있는 어느 회사의 아키텍처, 하지만 이쪽도 투레이어다.

구글 4keys의 구조. 사실 비슷비슷하다.

1. 구조+비용 문제
   1. 우리는 Azure + GCP Hybrid Cloud Architecture를 사용하고 있었다.
      1. 단순히 당장 데이터를 처리하는 방식을 알고 싶었다.
      2. 그런 데이터를 처리하는 것은 Spark SQL이라던가 /Hadoop 등을 써야지 싶은디
         1. 개발공수랑 가성비가 안 나오기도 하고…
         2. 클라우드에서 돌릴건데, 가장 유명한 상품 쓰면 좋지 않나? 싶었다.
            1. Azure Synapse Analystic을 사용하기엔 너무 어려웠다. 레퍼런스가 있어야 말이지…
      3. 하지만 문제점이 여러개 생겼다.
         1. 비용 관리를 하기가 어렵다. 우리는 세명인데, 클라우드가 두개라니?
         2. GCP로 보내기 위해서 일부러 Azure Blob을 사용해서 넘겨주는 이상한 방식을 차용하게 됨으로써 불필요한 비용이 생긴다.
   2. 각자의 Azure에서 크레딧으로 비용을 소모하고 있었다.
      1. 소마에서 돈을 주는데 뭐하러…?
      2. 그래서 내가 합쳐주기로 했다 일단은.
      3. 추가적으로, 추후에 biceps을 이용하여 자동 배포를 하기로 했다. 어떻게 하려나?
   3. 해결책
      1. GCP Storeage + BigQuery → Azure MS SQL(OLAP) + Query(JAVA ETL)을 이용하기로 했다.
         1. 그리고 MS SQL의 경우 OLAP + OLTP 의 방식 모두를 사용할 수 있어서 서비스단의 DB도 여기서 사용하기로 했다. 문제 생기면 나중에 OLTP DB(mySql 같은거) 사용하면 되지 뭐^&^
2. Cycle Time 개발
   1. 일단 내가 맡은 Listener에는 많은 문제가 있었다.
      1. 확장성이 아주 좋지 않았다.
         1. 어떠한 디자인 패턴도 사용하지 않은 그냥 코딩이라 그렇다.
         2. 핑계이긴 하지만 처음 코딩할 때는 webhook 자체를 분석하느라 바빴다.
      2. 해결책
         1. Factory patern을 사용하기로 했다.
         2. 확장성을 높이기 위해 각각의 상황을 분리, 하부의 모듈에서 이벤트를 생성해주는 식으로 진행했다.
         3. 왜냐하면… 좋은 코드를 쓰고 싶기도 했고, 내가 아닌 누군가가 와도 개발을 진행했으면 좋겠다고 생각했다.
         4. 결론 : 리팩토링 했다. 복잡도 아주 낮아졌다.
   2. CI/CD 파이프라인
      1. 이 때 까지만 해도 우리 아키텍처가 고정되지 않은 상태였다. 개발도 어떻게 하지? 보단 가능한가? 에 대한 질문이 훨씬 더 많은 시점이었다.
      2. 그래서 내가 맡은 Listener에 대한 파이프라인만 고정시켜놨고, 나머지는 각자 알아서 개발하는 것으로 잡아놨다.
   3. 내가 맡지 않은 부분들
      1. Vue.js를 이용한 간단한 차트 개발
         1. Power BI를 쓰면 좋겠다는 유저스틴 멘토님과 조대협 멘토님의 강한 권유에도 다들 Vue.js를 쓰겠다는 결정을 했다.
            1. 아무래도 처음 보는 개념이라 어려워서 그랬던 것 같다.
      2. Data Warehouse 기본 개발
         1. Deploy관련한 문제는 저 시점에서 해결하지 못한 문제이다. 어떤 것을 Deploy로 볼 것이고 Deploy가 실패했다고 보는 기준은 무엇이 되어야할까?
            1. issue(github / jira)
               1. 버그와 Deployment fail은 다르지 않을까? 그리고 특정 issue가 어떤 Deploy와 연관되었다고 특정 지을 수 있을까?
            2. github action
               1. github action은 너무 다양한 것들을 할 수 있다.
               2. 그리고, 여기서 실패하는 것이 Deploy fail인가? 정확한가? Build Error이긴 한데, 런타임에서 문제가 생기는 것은 잡아주지 못한다.
            3. k8s
               1. 아니 이거… 일단 가능한가? 우리는 k8s에 대해서 잘 알지 못한다. 사용도 안 해봤는데, 어떻게 합니까 거.
               2. 그리고, K8S를 네이티브로 사용하는 팀이 얼마나 될까?에 대한 질문도 좀 있었다.
3. 결론 및 잡담
   1. 생일이었다. 여자친구와 데이트를 옴팡지게 했다. 재밌었다. 아쿠아리움 최고~!
   2. 스프린트는 실패했지만, 우리는 열심히 살았다. 회고 및 리뷰때는 서로 칭찬을 많이 해주었다.

1.  

왜 뒤집혔는지 모르겠다.

저기서... 지켜지고 있는 것은 commit convention/github branch 전략 정도인 듯 하다.