나누면 분명히 장점도 있지만, 나눴을 때 비용도 크잖어.
그 비용을 부담하고서라도 msa를 도입이 더 이득인 상황이 어떤 상황이었는지 궁금함.
예를들어, 서비스끼리 비동기 통신하게 되는 케이스, 오히려 각 서비스에서 도메인을 잘 나눠 제공하는게 깔끔해지는 것 같기도 하고...
반면에 동기 서비스는 굳이 서비스를 나눠서 트랜잭션 관리를 어렵게 하는것보다, 한번에 같이 가는게 더 나을 것 같기도 하고.
아니면 요즘은 시스템이 잘 되어있어서, 안정적으로 쉽게 운영이 가능한 상황이라서 한다던지..
안해봤어서 또 다른 어떤 포인트가 있는지 궁금함.
그냥 하나의 서비스로 떼어낼만큼 충분히 커지면 떼어내는게 당연한거 아님? 오버엔지니어링을 조심해야겠지만 요즘같이 방법론 다 정해진 이상 뭐 비용이 크게 들지도 않을거고
충분히 커지면이라는 기준이 궁금하긴함 (사업적으로도 그렇겠지만, 기술적으로..). 서비스를 뗀다는건 데이터를 어디에 어떻게 저장하는것과 관련이 깊다고 생각이 드는데. 그게 레고블럭처럼 되는 구조인지도 궁금하기도 하고.. 그냥 이미 패턴화되서 분리에 코스트가 줄어들었다고 보는게 맞는건가.. 분리했을 때 서로 한번에 처리해야하는 일들은 어떻게 처리하는지 궁금하기도 하고 (이건 해본적없어서 모름)
거대한 모놀리식 프로젝트는 배포한번 하는게 큰일이라 Cicd를 하기가 힘들어서?
ci cd라는게 여기서 배포 파이프라인을 의미한다면.. 서비스를 나누는 극단적인 방법이 아닌 빌드레벨에서 해결할 수 있는 방법이 있지 않나 싶은데 (이건 생태계 빨을 타려나..?)
동기/비동기 는 msa랑 직접적인 관련은 없다고 생각함
직접적인 관련은 없다는것에는 동의하지만, 혹시 msa를 도입하려는 이유 중 한가지는 될 것 같아서 적어봤음. 비동기로 관리되는 케이스는(물론 서비스를 나눌 필요는 없지만) 해당 요청간의 의존도가 느슨해지기도하고.. 그럼 자연스럽게 서비스가 나눠질 수 있다고 생각이 들긴 함. 근데 이건 안써본상태에서의 추측이므로.. 의미는없음.
msa를 할 때 따라오는 장점은 코드가 격리되는 건 있음. 생각보다 추상화나 분리적 사고 이런게 안 되는 사람들이 많은데 이런 사람들이 오랫동안 개발한 소스가 한 덩어리면 꽤나 지저분해짐. 그런데 쪼개 놓은 상태면 지저분함의 전파가 갇히게 되지. 물론 이건 msa 안 하고 한 서비스 내에서 gradle 모듈 분리 같은 걸로도 할 수는 있다
응 나도 그런 류들은 모듈화(application layer)해서 처리가능할것같긴한데.. 서비스를 본격적으로 분리하면 더 로우레벨(network layer)로 가서 소통할 수 밖에 없을 것 같아서 물어봄..
정말 보수적으로 생각하면 msa를 반드시 써야하는 상황은 서비스의 특정 부분을 scale out해야하는 상황밖에 없는 것 같기도 하고?
msa 통신 방식은 언어중립적이라는 장점도 있긴 해. 이런 면에서 개인적으로 spring cloud config 같은 거 별로 안 좋아함
나는 오히려 그런 부분에서는 보수적으로 보지 말자는 입장이긴 함 ㅋㅋ; 오히려 network layer 계층에서의 컨트롤을, 언어를 강제해서 컨트롤이 간단해지면 이득이라고 보는 입장. 기술의 다양성보다는 서비스 운영 컨트롤이 더 중요해서 ㅋㅋ;;
근데 뭔가 지금까지 댓글이 msa를 꼭 도입해야된다기 보단, msa 도입 이후 얻을 수 있는 부산물에 대한 설명이 주가 되는거 보니까.. 현재 msa 도입이 그만큼 패턴화되고 간편화되어서 누구나 쉽게 도입할 수 있다는걸로 보이긴 하네..
반대로 패턴화되고 간편화되지 않은 패턴을 사용한다면 예측하지못한 고통을 맛볼 수 있다는 의미이기도 할 듯...
맞아. 해야하는 이유와 따라오는 장점을 구별할 필요는 있는데 그렇다고 너무 보수적으로 생각할 필요가 있나 싶음. 물론 준비는 제대로 해야지
나는 보수적으로 잡지 않으면 님이 말하는 제대로 준비하는 과정이 없다고 생각해서 이 질문을 쓴 것 같긴함.
외부서비스도 많을거고 내부서비스가 커지는것에대한 부담감도 있어서 분리하게됨 - dc App
외부 서비스(퍼블릭)와 내부 서비스(인터널 프로덕트)의 개념적/기술적 분리를 원한다는거?
하나의 모놀리스로 서비스 모듈을 나누는 방식은 결국 한 서비스에 장애가 생기면 애플리케이션 전체가 죽는다는 것도 있음. 마이크로서비스로 나누면 더 안정적으로 서비스할 수 있지
그럼 동기식으로 구성되어있는 서비스들은 사실상 한 서비스가 죽으면 그 기능을 사용하는 부분도 죽는거라서 크게 의미가 없지 않는거 아니라고 생각이 들긴 해. MSA를 한다면 좀 더 Fine-Grained 하게 컨트롤이 가능해서 그런건가? 예를들어서 CQRS로 구성해놨으면 command 서버가 죽어도 query 서버는 살아있다던지.. 아니면 서비스별로 캐시 서버를 별도로 둬서 회복가능성르 둔다던지?
걍 서버 규모가 존나 커지면 필요하긴 하지. 대부분의 경우에서는 쓸데없는 데다, 유지관리비용이 훨씬 늘어나는데 무지성으로 도입하는 게 문제긴 하지만, 내가 생각하기에 가장 큰 장점은 스케일 아웃과 팀 단위 빌드속도임. 도메인별로 MSA로 서버를 쪼개놓으면, 서버를 확장하기가 좋음. 단일 코드 베이스에서 암만 레이어를 나누어서 작업하다고 한다라도, 그 프로젝트 내의 기술 스택에 종속적일 수 밖에 없슴. 그리고 침범하기 쉽다보니, 쉽게 코드가 의존성 범벅으로 뒤덮일 위험도 높고. 솔까 모든 스택을 겸비하고 있는 중견이상 회사가 아니면 쓸데없는 말장난이라고 생각함.
네트워크 레이어까지 서비스로 까지 가서 나눠야 할 필요가 있을까 였었는데, 필요에 맞게 어느 레이어까지 딥하게 갈지 고민하면 되긴 하겠네. 근데 확실히 네트워크 레이어까지 가서 분리한다면(= MSA) 간다면 장애대응, 스케일 아웃 같은것도 컨트롤이 가능한것도 있고. 대신 제대로 알지 못하면 힘든 부분이 생길거고. 네트워크 레이어까지 분리되면 당연히 어플리케이션 레벨에서 분리햇을 때 오는 장점도 부산물처럼 따라오는것 같고..
Msa가 정답이고 꼭필요한 곳은 없고 여러상황을 고려해서 의사결정을 하는건데, 질문자는 그냥 툭던져놓고 이유가 나올때마다 하나하나 반박하면서, 그것들은 이유가될수없는데? 도입하면서 나오는 부산물이잖아. 하고있음 그냥 답정너같다 정중한 말투속에 난 msa가 싫어 그거 왜하는거야 라는 메세지가 삐져나와있네
그렇게 보였다면 미안해. 나도 궁금해서 답을 찾아가는 과정이라 최대한 보수적으로, 회의적으로 접근한 부분이 있는것 같은데 (소중한 시간 내줘 답변해줬는데, 내가 원하는 답변 내놔 징징거리는 것 같기도 하고 그러네 ㅎㅎ;;) 시간 내서 답변내고 읽어줘서 고마워.
이게 정답이네
답글까지 읽으니 오키에서 맛봤던 특유의 답답함을 깃갤에서 처음으로 느낀다
나도 다시읽어보니 반박하는것도 반박하는건데 결론은 내말만 맞아 라고 마무리 되고 있어서 재수없긴 하다. 지식을 너무 과하게 탐구하려고했네. 좋은 금요일날 기분 상하게 했다면 미안~ 점심 식사 맛있게 하고~!
관심사도 분리하고, 단일장애점도 쉽게줄일수있고, 플젝 규모가커지고 부서가분리되면 msa로 가는게 관리하기는 편함 부서마다 맡으면되니까 - dc App
유튜브에서 엘릭서 홍보하는 발표봤는대 동싣저리성이 매우매우높아서래요 - dc App
어디서 참고하셨는지 링크 있으면 부탁드려도 될까용