Spring Cloud 공부 후기

Spring Cloud를 직접 처음으로 공부해보고, 후기를 통해 공부 시작을 고민하는 사람들을 위해 글을 쓴다.

 

 

0. 시작 계기

많은 대기업들이 MSA를 사용하고 있어서 최근에 관심을 가지게 됐다.

 

여러 MSA의 장점들을 알게되고 프로젝트에 적용하고 싶었다.

 

무작정 인프런의 Spring Cloud 강의를 사서 공부하기 시작했다.

 

 

 

 

1. 강의 수강

(광고아님)

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4#curriculum

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) | Dowon Lee - 인프런

 

 

강의 자체는 최신 강의는 아니었다. 

강의는 Spring Boot 2 버전 시점인데, 최근에 Spring Boot 3 버전으로 코드를 업데이트하셨다.

 

이에 맞춰서 Security 버전도 마이그레이션 하신 것 같다.

 

그런데 영상 자체는 Spring Boot 2 버전이라서 고민 했었지만, 마땅한 Spring Cloud 강의가 없는 것 같아서 수강했다.

 

강의를 모두 듣진 않았고, 이미 알고 있거나 필요한 부분이 아니면 건너뛰고 들었다.

그렇다 보니 70%정도 들었다.

 

강의 자체는 도움이 되었다.

조금 아쉬웠던게 있다면 (물론 필연적인 내용이지만,) Spring Cloud외에 내용 외 다른 내용에 집중되는 내용이 있었던 거..?

 

 

2. 왜 MSA?

 

MSA 아키텍쳐를 본격적으로 설계하고 개발하다 보니 많이 무겁다는 느낌을 많이 받았다.

 

모놀리식이었다면 필요하지 않았을 추가적인 통신, 메세지 큐 관리, 추가적인 서버 등등..

 

테스트용 서버 빌드 조차 무거워진다. 특히 Spring MSA는 더욱 그런거 같다.

 

그 과정에서, "왜 MSA를 선택"하는지가 가장 중요한 것 같다.

 

MSA 입문용으로 프로젝트를 적용하려고 한다면,

 

MSA 아키텍쳐의 수용할만큼 정말 필요한가?

 

의 답을 찾는게 가장 중요할 것 같다.

 

Spring Cloud는 결코 가볍게 공부할 수 있는 범위가 아니다.

 

초보의 입장에선 적어도 수 개월이 걸린다고 생각한다.

 

 

 

대기업이 MSA를 선택하는 이유는 대기업의 규모 자체가 방대하기 때문에 MSA를 선택한다.

 

물론 아닌 경우도 있다.

 

https://jaypark.me/13

 

메타의 '스레드'는 모놀리식 구조로 1억명의 유저를 수용했다. 

 

무조건 MSA가 정답은 아니였던 것이다.

 

 

 

 

3. 신입의 MSA 공부?

 

MSA관련 지식이나 공부는 우대사항이 되었다.

직접 공부해서 프로젝트에 적용하는 것도 해보는 것 까진 좋다고 생각한다.

 

사실 MSA를 접하면서, "신입은 MSA를 차라리 건들지 않는게 좋다"는 말을 굉장히 많이 들었다.

 

내가 생각하는 그 이유는 다음과 같다.

 

1. MSA의 방대한 양을 충분히 공부할 역량이 되기 어렵다.

 

2. 보통 신입은 MSA 아키텍쳐를 선택할만큼 큰 규모의 프로젝트를 하기 힘들다.

 

3. 제대로 공부하지 않으면 차라리 안하는게 낫다.

 

물론 자신이 정말 세세하고 깊이있게 공부할 자신이 있다면 해도 좋을 것 같다. (나도 그 생각으로 시작했다)

 

하지만 그것보다 기본을 더 충실하게 하는게 더 중요하다고 생각한다.

 

 

4. 방향성

 

나는 이미 프로젝트에 Spring Cloud를 적용시키고 돌이킬 수 없을 만큼 많이 진행했다.

 

나는 MSA에 대한 접근을 다음과 같이 해보려고 한다.

 

4-1. MSA vs Monolithic 성능 비교분석

MSA아키텍쳐와 모놀리식아키텍쳐 모두 동일 조건 하에 서버를 구동하고, 각 서버의 성능 차이를 비교하려고 한다.

 

각 서버간 얼마나 성능 차이가 나고, 어느 부분에서 어떤 부분이 좋은지 직접 비교해보려고 한다.

 

이를 통해 MSA를 선택하는게 어떤 이점이 있는지, 어떤 관점에서 장점인지 몸소 느껴보려고 한다.

 

4-2. MSA를 경험한 것과 안한 것의 차이

MSA 아키텍쳐의 서버를 만들어 본 것 자체에 큰 의미가 있었다.

 

설계, 개발 과정에서 모놀리식이라면 경험해보지 못할 여러 고민들을 덕분에 할 수 있었다.

 

- DB의 분리

각 서버마다 갖고있는 DB를 어떻게 나누어야 할지, 어떤 도메인을 기준으로 나누어야 할지 고민했다.

 

다른 서버 테이블의 참조값을 얻을 수 없다보니, 구현 방법에서 많은 고민을 했다.

https://www.popit.kr/id%EB%A1%9C-%EB%8B%A4%EB%A5%B8-%EC%95%A0%EA%B7%B8%EB%A6%AC%EA%B2%8C%EC%9E%87%EC%9D%84-%EC%B0%B8%EC%A1%B0%ED%95%98%EB%9D%BC/

ID로 다른 애그리게잇을 참조하라 | Popit

이러한 고민들은 분명히 도움 될 것이다.

 

 

- 각 서버간의 의존성

각 서버들을 분리한 만큼, 서버들간의 의존성이 낮아야 한다.

 

각 서비스들은 단독으로 실행될 수 있어야 한다.

 

이를 고민하면서 여러 구현 방법을 고민했다.

 

조사를 많이 진행해 보았지만 어디에도 명쾌한 답은 없었다.

 

서버를 분리하는 것은 어떠한 프로세스와 데이터를 어디까지만, 누가 갖고 있을 것이냐 사이의 줄타기라는 것을 느꼈다.

 

그 판단의 기준은 논리적인 이유이거나 경험에 의한 것이다. 어려운 과제 중 하나였다.

 

나중에는 억지로 MSA에 끼워맞춰서 설계하는 식으로도 흘러가는 역효과가 일어나기도 했다.

 

 

- 설정(Configuration) 주입 분리

각 서버들의 설정 파일(yml 등)은 어떻게 처리할 것인지, 중복 내용이나 refresh에 대한 내용들을 공부했다.

 

외부 저장소에서 설정 파일을 주입하는 방법까지 알게 되었다.

 

- 각 서버간의 통신

각 서버에서 필요한 데이터를 구하기 위해선 서버들간의 통신이 불가피하다.

 

통신하는 과정 자체의 오버헤드가 크기 때문에 효율에 대한 고민을 많이 했다.

 

또한 에러 발생에 대한 대응은 어떻게 해야할지 추가적으로 고민하게 되었다.

 

 

- 데이터 동기화 방법

한 서버에서 가지고 있는 영속성 데이터들은 다른 서버와 동기화(Synchronize)되어야 한다.

 

데이터 동기화를 위해 Kafka 등 여러 방법을 고민하고 운용도 경험해 보았다.

 

 

 

외 등등 서버 빌드, 테스트, bus-refresh, 인가 과정, Response객체 정규화 등 여러 고민을 수도 없이 했다.

 

 

 

 

 

 

 

 

당연히 공부에 정답은 없다. 나의 경험이 100% 누구에게 적용되는 것도 아니다.

 

다만 무엇에 집중할지 잘 선택하는 것이 대체적으로 좋은 발전이 될 확률이 높다.