마이크로서비스 아키텍처 와 MSA 패턴 이해대시보드

모듈형 모노리스도 컨테이너화 할 수 있다. 쿠버네티스의 꼭 마이크로서비스만 올리는게 아닌 모노리스도 그냥 올릴 수 있다. 그것만으로도 확장성,배포성,탄력성이 보장이 되기도 한다. 라고 하셨었는데이 부분에대해서 조금 더 상세하게 알고싶어서 질문드립니다. 확장성,배포성,탄력성 부분에서 어떤 장점들이 있는지 조금 더 디테일하게 궁금합니다.그렇다면 모노리스 서버 구조의 아키텍처 설계 대신에 항상 쿠버네티스를 쓰는게 좋지 아니한가해서 질문드립니다. 

헥사고날 아키텍쳐에 대해 좀더 자세히 공부하고싶은데 참고할만한 깃주소 같은게 있을까요 ? 패키지구조도 사람마다 조금씩 다른거같아서 궁금합니다

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요.강의를 듣던 도중 궁금증이생겨 질문드립니다.제가 알기로는rolling update는 서버 관점에서 점진적으로(정수 단위, 혹은 비율 단위) 구 버전에서 신 버전으로 교체하는 것canary는 유저 관점에서 점진적으로 (특정 지역 유저 대상, 혹은 A/B 테스트 대상 등) 구 버전에서 신 버전으로 교체하는 것  으로 알고 있습니다. 즉 강의에서 말씀하셨던 'canary는 rolling update와 blue/green의 중간 격의 배포 전략'은 틀린 말이며, 각 배포 전략들은 각각 고유한 배포 전략을 가지고 있는 것으로 생각이 됩니다. 혹시 제가 잘못 알고있는 부분이 있다면 말씀 부탁드립니다. 감사합니다. 

세션 10 -1 강의에서설계동향 리액티브 선언 설명해주시는 부분 중유연성과 탄력성을 평가할 수 있는 항목이나 지표를 예를 들어 설명해주시면 이해가 잘 될 거 같습니다!

안녕하세요~ 강의 잘보고 있습니다.첫번째로는 DIP 에 대해서 조금 이해가 가지않는 부분이 있어서 질문드립니다.먼저 Class A 가 Class B , C 를 의존하고 있을떄 그 사이에 interface 를 둠으로써 의존관계를 B C 가 아닌 interface 로 DIP 가 적용이 된다고 생각하는데요 B C 도 interface 를 의존하고있으므로 그래서 전 설명해주신 레이어라는게 어떤레이어를 말하는것인지 잘이해가 되질않습니다.두번째로는 msa 아키텍처 에서 저장소를 분리하였지만 api call 을 통해서 조합할떄 결국 시간복잡도(성능) 이 크게 달라질것같지않습니다. 그래서 이러한 궁금증 들이 있습니다.감사합니다 !!

궁금합니다.아키텍트 관련 도서 추천받을수있을까요?

강의 내용과 살짝 벗어난 질문일 수 있는데 궁금하여 문의 드립니다. 마이크로 서비스가 모놀리식에 비해서 여러면에서 자원을 효율적으로 사용 가능한 것으로 알고 있습니다. 하지만 실제 운영 하다보면 JVM 힙 설정에서 오히려 모놀리식보다 과하게 메모리가 사용될 수 밖에 없는상황이 있을 수 있을 거 같아 좀 더 효율적으로 관리 할 수 있는 방안이 있는지 문의 드립니다.  예를 들어모놀리식에서는 heap 최대최소 4G의 (G1 GC 정책)으로 큰 문제 없이 운용하다가(CPU 및 기타 자원의 사용량은 충분다하고 할 경우) 마이크로서비스 20개로 변경을 하여 각 1개의 서비스(도커내 WAS)에 개당 1G (Palllel GC)로 적용할 경우 총 20G의 힙메모리가 필요하여 메모리로 인한 자원이 부족해 질수 있을텐데요.(그렇다고 1G 이하로 설정하면 너무 비정상적으로 Full Gc가 발생하여 설정이 힘들다면) 이러한 상황인 경우 서비스가 지속적으로 늘어나는 상황에서는 오히려 많은 메모리 확장 혹은 추가의 서버(EC2) 증설이 필요한 상황이 발생할 텐데 힙메모리 관리 측면에서 모놀리식보다 효율적인 관리할 수 있는 방안이 있을까요? 

안녕하세요, MSA패턴1- 인프라 섹션의 컨테이너 오케스트레이션 챕터에서 몇가지 질문이 있습니다. 먼저, node 와 pod 의 관계가 헷갈립니다.주신 자료의 k8s 아키텍처 이미지를 보면 각 worker node 는 여러개의 pod 를 가질 수 있는 것 같은데 보통 한개의 node 에 여러개의 pod 를 설정하는 경우가 흔한가요?Scale out 을 진행 할 때 실제로 Scale out 되는 주체는 worker node 가 맞는건가요? (worker node 에 하나 이상의 Pod 가 존재 한다는 가정하에)보통 실무에서는 pod 수를 늘려주세요 라는 요청을 많이 들어봤는데요, 결국 node 를 늘리므로써 pod 가 늘려지는게 맞는건지 아니면 특정 node 안에서 pod 수 만 늘리는 건지 궁금합니다.보통 이런 요청은 Scale out 의 목적으로 pod 수를 늘려달라는 요청인데, 특정 node 안에서 pod 수만 늘어난다면 이게 Scale out 맞는건가 라는 생각이 들어서요. 그 다음은 worker node 에 관한 질문입니다. master node 는 연결된 worker node 들을 API 를 통해 관리하는 목적으로만 쓰이는것이 맞을까요? 인그레스는 master node 에서 관리하는 설정이 맞는지 궁금합니다.

SOA 와 MSA 를 명확하게 구분지을 수 있는 요소가 각각의 서비스에 대한 오토스케일링 (수평확장) 가능 여부 라고 이해해도 될까요? 클라우드 환경에서 수평 확장을 위한 가장 효율적인 시스템유형이 Cloud Native Application 이다 라고 설명 해주셨는데요, 클라우드 환경에서 수직 확장은 효율적이지 못한건가요? (잘 쓰이질 않는건가요?)강의 내용중에 수평 확장을 해놓고 그 상태에서 수직 확장을 하는 방식으로 적용을 한다. 라는 설명을 해주셨는데, 이 맥락과 연관이 있는지 궁금합니다!아직 실습을 해보지 않은 상황에서 단순하게 생각해보면, 수직확장은 반영에 시간이 걸린다 라고 설명해주셨는데 그렇다면 수직확장 부터 미리 반영시켜 놓고 서비스 운영 중에 자동으로 수평 확장이 될 수 있도록 오토스케일링 설정을 해놓아야 하는게 아닌가 라는 생각이 듭니다.

좋은 강의 감사합니다. 이런 양질의 강의를 이 가격에 들을 수 있다는게 참 좋네요 ㅎㅎ   다름이 아니라 다음 강의와 다다음 강의는 언제 쯤 릴리즈되나요? 다시 한번 좋은 강의 감사합니다.