예전부터 개발해온 시스템이 있는데 전 잡단위 process로 분기했다고 표현했는데 명칭이 msa네요.. 한수 배워갑니다. 대용량으로 가면 반드시 프로세스 단위로 가는게 좋더라구요.. 이전까지 문제는 프로세스간 동기화 문제에 대한 기술적 처리를 어떻게 하는가였는데 요즘 카푸카나 grpc로 인해서 문제가 깔끔히 해결된 느낌입니다
모놀리식 아키텍쳐도 오토스케일링이 가능한데요. 기능이 인증, 게시판, 결제로 이루어진 MSA에선 결제 서비스에 부하가 발생하면 결제만 증설 할 수 있는 장점이 있어요. 모놀리식에선 결제 기능의 부하가 발생해도 인증과 게시판 기능도 함께 스케일링 되다보니 불필요한 서버 자원이 낭비되게 되는거죠. 거기서 비용의 차이가 발생하게 됩니다.
영상 잘봤습니다. Msa의 장점은 코드를 조직에 맞춰 쪼갠다는 점에 있지 않을까요? 거대기업에서 msa 인력을 더 투입할 순 있는데 투입대비 너무 낮은 생산성에서 시작한다고 생각합니다. 그래서 바운더리를 정해서 팀간의 간섭을 최소화한 서비스형태가 msa 라고 생각합니다. 아직 규모가 작은 업체에서 개발팀 한개 두고 있는데 굳이 마이크로 서비스를 할필요는 없다고 생각합니다. 개발팀 한갠데 서비스를 여러개 관리하는게 힘드니까요. 근데 개발팀이 여러개인 조직에서는 각팀의 바운더리를 쪼갠 아키텍쳐가 더 효율적이지 않을까합니다.
여쭤볼게 있는데 MSA 아키텍처에서 -> 한 시스템 내에 각각의 서버들과 DB들이 연결되어 있는데, 연결 된 DB별로 RDBMS가 서로 다르던데(예, 각각 MSSQL, POSGRE, ORACLE)무슨차이 인지 굳이 그렇게 하는 이유가 무엇인지 조심히 여쭙니다. MSA 적용 단위 별 개발언어 차이로 그런가요? (물론 본 강의 관련 질문은 아닙니다.) 알려주시면 너무 감사하겠습니다.
MSA 목적 중 하나가 큰 시스템을 어플리케이션 몇 개로 나누는데요. 쪼갠 어플리케이션의 특성에 맞게 아키텍쳐도 구성하고, DB도 적합한 것으로 사용하려고 하는 의도가 있구요. 혹시 기존 DB에서 일부만 변경했을 수도 있구요. 일종의 DB의 폴리글랏이라고 볼 수 있는데요. 폴리글랏을 한번 찾아보시는 것도 좋을거 같습니다~
마이크로 서비스 아키텍쳐 아키텍쳐 자꾸핫하다 주위에서 말하길래...결국에는 이전에도 이 개념은 있었던것 아닌가요? 이게 무슨 새로운 패러다임이라고 하는건지? WAS에서 모듈단위로 인스턴스화 해서 개별관리 해왔는데 그게 2010년도인데 마이크로서비스 아키텍쳐랑 너무 같은거 같은데요 참 궁금하네요 아닌가요? WAS에서 개별 모듈로 관리하면서 독립 실행이었고 독립 디폴로이 독립DBPool 물론 각 모듈간의. 인터페이스는 이루어지고 있었습니다만 누군가가 그러더군요 MSA는 하나의 모듈이 죽어도 정상동작한다 그게 가능한가요 독립된 구조라 하지만 모듈 한쪽이 죽으면 모듈간 상호I/F가 안되는데 그게 가능한지. 만일 제가 생각한게 맞다면 장점. 영역을 확실하게 구분지을수있다. 상호인터페이스가 이루어지지 않는 영역이라면 타 서비스가 죽더라도 영향을 받지 않는다 단독 관리가 가능하므로 해당 모듈에 대해서만 배포 라이브러리관리 기능추가가 가능하다. 단점: 서비스간의 인터페이스가 이루어 져야하므로 인터페이스 영역을 단독으로 수정했다간 타서비스에 영향을 끼친다. MSA를 접해보지 않은 일인으로서 제대로된 개념조차 모르시는 분들이 그냥 핫하다고 하니까 도입할려고 하는건 아닌지 ..
아 저 말씀하신 내용과 비슷한 얘기를 하고 다녔습니다. 그때도 CBD, SOA 등으로 모듈을 분리하였고, 그렇게 관리하고 있었습니다. IT는 용어가 바뀌면서 마치 처음 나오는 개념인냥 마케팅을 하지만, 개발을 해본 사람이라면 이런 시도가 처음이 아니라는 것을 몸이 알고 있습니다. 껍데기만 바뀐듯한 모습 다만 좀 컨테이너나 API G/W 같은 개념들이 들어오고, 실제 넷플릭스같은 대규모 성공사례와 실제적인 효과가 보이면서 더 부각된거 같아요. 즉 사상은 비슷한 시도들이 있었는데, 그게 좀 더 실체화 되고, 실용화 되었다? 물론 좀 더 세밀하게 본다면 기존 모듈을 나눈다보다는 MSA가 좀 더 진보된 것은 있다고 생각은 되구요. 아래 말씀하신 것은 명언입니다. 제가 어제도 회의 때 했던 말입니다. 동감합니다. 단점: 서비스간의 인터페이스가 이루어 져야하므로 인터페이스 영역을 단독으로 수정했다간 타서비스에 영향을 끼친다. MSA를 접해보지 않은 일인으로서 제대로된 개념조차 모르시는 분들이 그냥 핫하다고 하니까 도입할려고 하는건 아닌지 ..
아 MSA 관련해서 좀 더 자세한 영상들을 올리려고 하는데요. 먼저 답변을 드리면 언어는 유지가 가능한데요. 소스는 변경이 좀 많을 수 있다고 생각됩니다. 그리고 API Gateway를 AWS에 서비스를 사용한다면 변경 범위가 작을 수 있지만, 오픈 소스같은 것을 도입한다면 소스 변경이 상당히 많을 것으로 보입니다.
완전 공감되는 댓글입니다. 제가 딱 그렇게 생각하고 있습니다. 업계의 리더들이 MSA를 주장하고 있지만, 한사람의 개발자 출신으로 아키로 생각해볼 때 꼭 능사는 아니다. 필요하다면 필요한 곳에 적용하는게 맞다라고 생각됩니다. 상당히 복잡한 구조를 가짐으로 인해서 생각지 못한 다른 문제들이 발생될 수 있다고 봅니다.
![[Talk&Talk] 누구나 쉽게 이해할수 있는 마이크로서비스 아키텍처(MSA) #1편](http://i.ytimg.com/vi/8d4h7K_Fq-0/mqdefault.jpg)
![[우아콘2020] 배달의민족 마이크로서비스 여행기](/img/n.gif)
좋은 점보다 안좋은 점을 먼저 들으니 이해가 더 쏙쏙 됩니다. 감사합니다!!!
이런 내용 너무 좋습니다. 평소에 영상만 보는데 너무 재밌어서 이렇게 댓글남기네요. 감사합니다
오~ 좋아해주시니 좋네요! 재미 있을만한 내용 올려볼께요~
동감
설명을 잘해주셔서 쉽게 이해했습니다. 감사합니다!
앗 뜨거 !! 주제가 넘 뜨겁네용 !!
관심있던 주제였는데 좋은 내용 감사합니다~
ㅋㅋㅋ 넹 뜨겁네요. 매우~
존경합니다행님. 지식의 나눔에 감사드립니다
아이쿠 이런 감사합니다. 위에서부터 봤는데, 나이트님 댓글 많이 달아주셨네요~ 관심과 댓글 감사해요~
감사합니다. 잘배워가요~~~!!^^
고객사 요구로 msa 아키텍처를 그리고 공부하고 있는데 bm까지 생각이 들 정도로 혜안있는 설명이었어요 정말 감사합니다
비전문가인데 말씀을 조목조목 해주셔서 MSA에 대해서 잘 알았습니다. 감사합니다.
좋은 강의 감사 합니다.
설명 너무 좋습니다 ! ㅎㅎ 목소리도 좋으시네요
댓글 좋아요~ ^^
좋은 내용 감사함니다
영상 너무 좋아요 !! MSA 아키텍쳐도 올려주세요 !!!!
MSA 요즘은 정말 MSA가 대세인거 같네요..^^ 다음에 또 올려볼께요^^
감사합니다!
잘들었습니다.
궁금하신 내용 더 있으심 말씀하세요~ !
설명 잘 들었 습니다.
다음 설명은 언제 하시나요..?
아~ 다음을 기대하시는 군요. 그렇다면 제가 한편 준비해보겠습니다!
예전부터 개발해온 시스템이 있는데 전 잡단위 process로 분기했다고 표현했는데 명칭이 msa네요.. 한수 배워갑니다. 대용량으로 가면 반드시 프로세스 단위로 가는게 좋더라구요.. 이전까지 문제는 프로세스간 동기화 문제에 대한 기술적 처리를 어떻게 하는가였는데 요즘 카푸카나 grpc로 인해서 문제가 깔끔히 해결된 느낌입니다
어려운거 하시네요~ 요즘 아키텍쳐가 MSA로 카프카 이용하여 문제 해결 하는 분위기네요~
감사합니다.
좋아요!
감사합니다~ 잘 지내시죠?
아~ 넹! 오래간만입니당! 아주 잘 지내진 못하지만,,, 그래도... 괜찮습니다!
안녕하세요 알렉님 혹시, IaC 관련 영상도 있을까요?
아 laC 이건 좀 준비를 해야 할거 같은데요^^;
와 오눌 소프트웨어 공학에서 요즘 핫하다고 배웠는데
아~ 그랬군요. 맞아요. 요즘 하태하태~!
MSA 장점중에 Auto-Scale을 도입할 수 있다고 말씀하셨는데 그 이유가 뭔가요? 모듈의 크기가 크다면 Auto-Scale 기능을 도입하기 어려운가요?
Auto-Scale 과 모듈의 크기는 무관할 거 같은데요. 모듈의 규모를 최적화해서 사용하면서 필요 시 늘려가면 좀 더 효율적으로 비용을 사용할 수 있어서 말씀드린 내용입니다.
모놀리식 아키텍쳐도 오토스케일링이 가능한데요. 기능이 인증, 게시판, 결제로 이루어진 MSA에선 결제 서비스에 부하가 발생하면 결제만 증설 할 수 있는 장점이 있어요.
모놀리식에선 결제 기능의 부하가 발생해도 인증과 게시판 기능도 함께 스케일링 되다보니 불필요한 서버 자원이 낭비되게 되는거죠. 거기서 비용의 차이가 발생하게 됩니다.
전에는 클라우드로 전환했을때 장점중 하나가 오토스케일링이라고 했죠. msa의 장단점을 해결하는 다른 솔루션들도 많고, 이 꼭 이것만의 장단점도 아니고 그냥 마케팅용어라 봐도 될 것 같네요
msa는 관리하는 인력이 더필요하죠
MSA가 맞는 서비스가 있고, 아닌 곳도 있고, 아키텍쳐라는게 그런거 같아요. 잘맞게 적용해야 함. 더 복잡해지고, 자원도 많이 쓰고, 사람도 더 많이 필요할 수 있음.
감사합니다 :)
허당차니님~ 오랜간만이예요~ 잘되고 있는거죠?
영상 잘봤습니다. Msa의 장점은 코드를 조직에 맞춰 쪼갠다는 점에 있지 않을까요? 거대기업에서 msa 인력을 더 투입할 순 있는데 투입대비 너무 낮은 생산성에서 시작한다고 생각합니다. 그래서 바운더리를 정해서 팀간의 간섭을 최소화한 서비스형태가 msa 라고 생각합니다. 아직 규모가 작은 업체에서 개발팀 한개 두고 있는데 굳이 마이크로 서비스를 할필요는 없다고 생각합니다. 개발팀 한갠데 서비스를 여러개 관리하는게 힘드니까요. 근데 개발팀이 여러개인 조직에서는 각팀의 바운더리를 쪼갠 아키텍쳐가 더 효율적이지 않을까합니다.
동의 합니다~ MSA는 어쩌면 서비스와 조직의 형태에 따라서 선택하고, 몇 개로 쪼개어지는 기준이 생길 거 같아요~
여쭤볼게 있는데 MSA 아키텍처에서 -> 한 시스템 내에 각각의 서버들과 DB들이 연결되어 있는데, 연결 된 DB별로 RDBMS가 서로 다르던데(예, 각각 MSSQL, POSGRE, ORACLE)무슨차이 인지 굳이 그렇게 하는 이유가 무엇인지 조심히 여쭙니다. MSA 적용 단위 별 개발언어 차이로 그런가요? (물론 본 강의 관련 질문은 아닙니다.) 알려주시면 너무 감사하겠습니다.
MSA 목적 중 하나가 큰 시스템을 어플리케이션 몇 개로 나누는데요. 쪼갠 어플리케이션의 특성에 맞게 아키텍쳐도 구성하고, DB도 적합한 것으로 사용하려고 하는 의도가 있구요. 혹시 기존 DB에서 일부만 변경했을 수도 있구요. 일종의 DB의 폴리글랏이라고 볼 수 있는데요. 폴리글랏을 한번 찾아보시는 것도 좋을거 같습니다~
@@with2511 감사합니다. 알렉님^^
마이크로 서비스 아키텍쳐 아키텍쳐 자꾸핫하다 주위에서 말하길래...결국에는
이전에도 이 개념은 있었던것 아닌가요?
이게 무슨 새로운 패러다임이라고 하는건지?
WAS에서 모듈단위로 인스턴스화 해서 개별관리 해왔는데 그게 2010년도인데 마이크로서비스 아키텍쳐랑 너무 같은거 같은데요 참 궁금하네요 아닌가요?
WAS에서 개별 모듈로 관리하면서 독립 실행이었고 독립 디폴로이 독립DBPool 물론 각 모듈간의. 인터페이스는 이루어지고 있었습니다만 누군가가 그러더군요 MSA는 하나의 모듈이 죽어도 정상동작한다
그게 가능한가요 독립된 구조라 하지만 모듈 한쪽이 죽으면 모듈간 상호I/F가 안되는데 그게 가능한지.
만일 제가 생각한게 맞다면
장점. 영역을 확실하게 구분지을수있다.
상호인터페이스가 이루어지지 않는 영역이라면 타 서비스가 죽더라도 영향을 받지 않는다
단독 관리가 가능하므로 해당 모듈에 대해서만 배포 라이브러리관리 기능추가가 가능하다.
단점: 서비스간의 인터페이스가 이루어 져야하므로 인터페이스 영역을 단독으로 수정했다간 타서비스에 영향을 끼친다.
MSA를 접해보지 않은 일인으로서 제대로된 개념조차 모르시는 분들이 그냥 핫하다고 하니까 도입할려고 하는건 아닌지 ..
아 저 말씀하신 내용과 비슷한 얘기를 하고 다녔습니다.
그때도 CBD, SOA 등으로 모듈을 분리하였고, 그렇게 관리하고 있었습니다.
IT는 용어가 바뀌면서 마치 처음 나오는 개념인냥 마케팅을 하지만,
개발을 해본 사람이라면 이런 시도가 처음이 아니라는 것을 몸이 알고 있습니다.
껍데기만 바뀐듯한 모습
다만 좀 컨테이너나 API G/W 같은 개념들이 들어오고,
실제 넷플릭스같은 대규모 성공사례와 실제적인 효과가 보이면서
더 부각된거 같아요. 즉 사상은 비슷한 시도들이 있었는데,
그게 좀 더 실체화 되고, 실용화 되었다?
물론 좀 더 세밀하게 본다면 기존 모듈을 나눈다보다는 MSA가 좀 더 진보된 것은 있다고 생각은 되구요.
아래 말씀하신 것은 명언입니다. 제가 어제도 회의 때 했던 말입니다. 동감합니다.
단점: 서비스간의 인터페이스가 이루어 져야하므로 인터페이스 영역을 단독으로 수정했다간 타서비스에 영향을 끼친다. MSA를 접해보지 않은 일인으로서 제대로된 개념조차 모르시는 분들이 그냥 핫하다고 하니까 도입할려고 하는건 아닌지 ..
채용공고에 마이크로 서비스를 사용하고 있다고 적혀있는 걸 봤었을때 무슨 말인가 했는데, 이제 좀 이해가 되는 것 같습니다! 하나의 API서버로 관리하는게 아니라 기능별로 API서버를 따로 만들어 관리하는 것이 맞을까요?
하나의 API서버를 분리한다고 보셔도 될거 같습니다. 그 분리의 기준과 방법 기술적인 연동에 대한 고민이 MSA 구축의 시작점일거 같구요.
@@with2511 감사합니다!!
Return On Investment
영상 잘봤습니다. 제 생각에는 MSA정도 하려면 시스템 규모가 꽤 큰 회사일 듯 하네요... MSA라고 하는게 기존 시스템의 언어는 그대로 유지하고 구조만 더 세분화 한다고 보면 될까요 ㅎㅎ
아 MSA 관련해서 좀 더 자세한 영상들을 올리려고 하는데요. 먼저 답변을 드리면 언어는 유지가 가능한데요. 소스는 변경이 좀 많을 수 있다고 생각됩니다. 그리고 API Gateway를 AWS에 서비스를 사용한다면 변경 범위가 작을 수 있지만, 오픈 소스같은 것을 도입한다면 소스 변경이 상당히 많을 것으로 보입니다.
ROI = Return on Investment
개인적으로 마이크로서비스 아키텍처라는 단어가 좋지만 않습니다. 무조건 쪼개면 좋아지는 것 처럼 잘 못 이해되는 부분 도 있는것 같아요.
애플리케이션을 유지 보수가 잘하고 비즈니싀 민첩성을 좋게 하기 위한 하나의 수단이라고 생각합니다.
완전 공감되는 댓글입니다. 제가 딱 그렇게 생각하고 있습니다. 업계의 리더들이 MSA를 주장하고 있지만, 한사람의 개발자 출신으로 아키로 생각해볼 때 꼭 능사는 아니다. 필요하다면 필요한 곳에 적용하는게 맞다라고 생각됩니다. 상당히 복잡한 구조를 가짐으로 인해서 생각지 못한 다른 문제들이 발생될 수 있다고 봅니다.
조금 더 깊은 내용 알려주세요 그리고 궁금한게 마이크로서비스 는 무조건 자바로 변경 해야 하는건가요?
아~ 그렇지 않아도 조금 깊은 내용 저도 보고 있고, 한번 더 해보려고 합니다~
무조건 자바로 변경 그건은 아닌거 같아요~ MSA를 말할 때 언어를 특정지어 말하진 않습니다.