게이트웨이 코드를 작성하다 보면, 이게 제대로 작동은 하는 것인가? 하고 의문이 들때가 있다 이러한 의문은 개인 프로젝트를 진행할 때뿐만 아니라 회사에서 동료들과 일할 때도 자주 떠올랐다 그리고, 비슷한 URI와 Route들의 순서 배열에 따라 몇몇 Route들이 동작하지 않기도 했다 길어진 Route 명세를 파악하기 위해 모니터를 위 아래로 훑는 시간도 많이 들고, 이 과정에서 실수할 소지가 많다는 것을 느꼈다 그래서 시간을 내서 리펙터링을 했고 성공적이었다 아래는 그때의 노하우를 좀 더 가다듬은 방식으로 진행한 것이다 문제의 YAML 명세 spring: cloud: gateway: routes: - id: ITEM-SERVICE uri: lb://ITEM-SERVICE predicates: - Pat..

종종 배포할때 느린 마이크로서비스 등록 과정 때문에 빠르게 확인할 수 없어서 답답했다 단독 모놀리스면 바로 확인이 가능했지만 마이크로서비스는 정상 기동 후 1분 정도를 기다려야 503 Service Available이 없어진 후 확인이 가능했다 그러나 이건 잘못됐다. 등록은 사실 바로 된 것이다. 문제는 다른 곳에 있었다. 이걸 위해서는 Spring Cloud Nexflix이자 Service Discovery인 Eureka에 대해 알아야 한다 Eureka는 Service Discovery의 Server로, Netflix가 MSA에 관련해서 만든 것 중 하나이다 (Gateway 등) 그건 중요하지 않다 (응?) 등록 과정 Eureka에는 Server 와 Client가 있다 client는 자신의 IP, Po..

저번 글이 너무도 MSA에 대한 단점을 기술해서 장점 또한 분명히 있다는 것을 적기 위해 작성했다 (하하..) 아래는 실제로 MSA 환경에서 일하면서 느꼈던 장점을 적어보았다 독립적인 작업의 용이함 팀원과 같이 작업을 하다보면 항상 출근 직후 하는 한 가지 루틴이 있다 바로 개발 브랜치를 다운 후 작업 중인 브랜치와 싱크를 맞추는 것이다 - git pull origin dev - git checkout feat/my-working-branch - git merge dev 저게 별거 아닌 것 같아도 은근 번거로울 때가 많다 작업 중에 긴급하게 배포해야 하는 경우 - main 브랜치 이동 - pull & sync - hot-fix 브랜치 따기 - 버그 수정 - 확인후 배포 - main 브랜치 병합 - dev..

이 글은 마이크로 서비스 아키텍처에 대해 굉장히 주관적인 생각을 담고 있습니다 혹시나 불편하실 수 있다는 점 말씀드립니다... MSA를 하는 회사에 처음 들어가게 되었다... 회사에서 프로젝트를 보기 전엔 회사 아키텍처가 MSA란 것을 알지 못했다 공고엔 Spring Cloud라고 적혀있었지만, 특정 기술로 구성된 서버만 별도로 분리하고 그 외의 백엔드 서버는 모놀리식으로 구성되어 있다고 생각했다 큰 규모의 회사도 아니었고 그런 비용이 높은 설계를 굳이 채택할 필요가 없었다는 생각이 있었던 것 같다 그 덕분에 MSA에 대해 직접적인 경험을 할 수 있었다 사실 난 MSA에 관해 아주 많은 관심이 있던 사람 중 한 명이다 패션을 좋아하면 올해에 무슨 색이 시그니처인지 관심이 가는 것 처럼, 나 또한 22~2..

보통 yaml 파일을 리펙터링하면 서버를 재기동하면서 제대로 설정됐는지를 확인한다 내 노트북 같은 경우 보통 재기동하면 40초 ~ 2분 정도의 시간이 걸린다... 참으로 답답하지 않을 수 없다 Spring Cloud Config 을 이용하면 변경한 yaml 파일을 동적으로 반영해서, 빠르게 리펙터링을 해나갈 수 있다 우선 아래 정보를 참고해서 Spring Cloud Config을 설정한다 (설명이 친절하지 않아서 미안...) - Section 7: Cloud Configuration (tistory.com) - Section 8, 9: Cloud Bus, 암호화 (tistory.com) 아래와 같은 상황이 있다고 가정해보자 (내 상황이었음) 정~말 긴 yml 파일이 있는데... route 설정 정보로 인..