✔ 쿠버네티스 스터디 24 일차

혜
또 오늘 프로 서비스 아키텍처 굉장히 중요하다는 거를 많이 들어서 저희는 무조건은 아닌데 모놀로시 개발을 좀 운영해서 많이 배포하고 있으니까 마이크로 서비스로 단계적으로 바꾸기가 되게 어려운 환경인 것 같아요. 근데 사실은 이제 개발을
하고 나서 운영을 좀 배포하고 난 다음에 좀 이렇게 바꿔 나갈 수 있는 기간이 좀 필요한데 그런 게 없다보니까 대규모 모놀로직 하나의 대규모로 이렇게 운영하는 거를 유지할 수밖에 없는 그런 고충이 있어서 저희도 이번에 검색 엔진도 이렇게 바꿔보려고 하고 다른 것들도 많이 해보려고 했는데 시간? 그리고 설계 이런 게 굉장히 여기서도 나오잖아요. 설계를 되게 잘 해야 된다고 그런 게 진짜 물리적 자원 소비나 이런 것도 다 네트워크 트래픽 이런 것도 다 고려해야 되니까 굉장히 고차원의 설계가 필요하겠고 느꼈습니다. 

 

주

모놀리지 프로스트가 뭐 있어

 

혜
검색 엔진 대규모잖아 그거 모놀리지 그것만 봐도 검색엔진 그것만 단독으로 봤을 때 클러스터가 단독으로 하나가 떠 있지 근데 원래는 이런 구조라고 하면 클러스터를 좀 사용도에 맞게 나눠서 하거나 이러고 싶은데 그런 게 좀 어렵고 디비도 하나의 집중 중앙화 되어 있잖아 우리는 나는 그런 게 이 쿠버네티스 개념 말고도 그냥 설계적으로도 하나에 집중되어 있다라고 보거든 근데 꼭 이거를 나눠야 될까 이런 생각도 들긴 하는데 근데 쿠버네티스 관점에서는 이런 툴들이 있으니까 도와줄 수 있는 모니터링할 수 있는 툴이 있으면

 

주

클러스터 개념에서 에 대한 물리식을 생각해 볼 수도 있는데

 

윤

api나 이제 웹 기능이나 이런 쪽으로 가야 될 것 같은데 api도 솔직히 말하면 우리는 거의 일괄적으로 그러니까 우리는 디비 커넥션 개념이 거의 없잖아 그치 디비를 왔다. 갔다 하는 개념이었고 단순히 엘라스틱만 왔다 갔다 하고 그다음에 외에 주고 이건 솔직히 디이 심플한 강의기 때문에 얘도 msa랑은 솔직히 관련성이 거의 없어요. 근데 웹은 좀 다르지 근데 우리는 서비스가 하나이기 때문에 MS 라고 대입하기 조금 어려워요.

 

주

우리가 모놀리식 아키텍처가 그렇게 많지 않아 많을 수도 없고 왜냐하면

 

혜
그냥 단일 서비스라는 거지 그게 뭔가 엄청

 

솜

혜 선배님이 질문해 주신 거를 들으면서 말씀해 주신 걸 들으면서 뭘 모르고 있는지를 알게 된 것 같고요 알지도 못하는 거를 이런 걸 모르고 있었구나 내가 너무 유익한 ! 이제 거의 끝에 더 다르고 있는데 저는 그냥 아직 잘 모르기도 하니까 그냥 보면서 마이크로소프트 아키텍처의 가장 큰 장점은 다양한 언어로 개발할 수 있는 게 좀 장점인 것 같다. 생각이 들었어요. 뭔가 재밌을 것 같아요. 이 사람은 고로 개발하고 이 사람 파이썬으로 하고 이 사람을 잡아라 하고 딱 이렇게 하나의 서비스가 되는 게 너무 재밌을 것 같아요.

 

주

이게 필요에 의해서 하는 건 아니죠. 네 그냥 재밌어서 하면 안돼요

 

윤

나는 옛날부터 약간 이런 경향이 있거든 뭔가 개념을 정의를 들으면 일단 머릿속으로 도쿄라든지 그림을 먼저 물리적으로 그려보는 성향이 있는데 이 스티어의 엠보이라는 거를 아까 들었을 때 트래픽을 미리 처리를 하고 넘어간다는 개념이 아무래도 머릿속으로 그려지지가 않는 거야 그러니까 여기는 그림이 앱에 들어오기 전에 트래픽을 먼저 주고 엠보 쪽으로 그다음에 앱을 통하고 그러니까 이 개념이 왜 어떻게 해라는 생각밖에 안 들었어 그림으로서는 정희는 공부하기는 했는데 이게 어떻게 처리가 되는 거지 이런 패키지나 이런 개념이 전혀 모르겠더라고 그래서 강의 한번 들어야겠구나

 

주

사실 프로토콜 그래서 mv에서 지원하는 프로토콜이 제약돼 있잖아요. 제약돼 있는 프로토콜 내에서는 그렇게 하면 그냥 ..

 

윤

그러니까 리다이데트랑 이제 지연 철이라든지 아까 리트라이 이런 걸로 됐을 때 진짜 끝판왕이구나 이거는 

 

주

여기에 근데 안 나와 있는 것들도 있어요. 잉글레스 게이트웨이나 잉글레스 게이트가 있다. 빠져 있는 거 게이트

 

윤

잉그레스 할 때 잉그레스 게이트웨이라는 단어도 다 왔었던 것 같은데 왔어요.

 

주

그래서 저기 원래 코마니티스에 보면 잉그레스 서비스를 사용하잖아요. 대신에 이 인스튜브를 사용하게 되면 인스티 내부에서 제공하는 잉그레스 데이트비를 써야 돼요 그래서 약간 쿠버네티스 이미 있는 기능인데

 

수
저는 실질적으로 몸으로 부활을 느껴본 적이 없어서 저는 그런 걸 느끼지 않잖아요. 루시에 막 트래픽에 올리는 것도 아니고

 

혜

원하면 해줄 수 있어 

 

수

아니야 아니야 아니야 아니야 아니야 아니야 아니야 아니야 그래서 막 이렇게 와닿지는 않은데 나중에 멀리 생각하면 꼭 이런 게 필요할 것 같다라는 생각도 했고 아니요. 아니요. 여기 있잖아요. 용 대리님이 무서워하시더라고요 저희는 이렇게 트래픽 오면 난리가 날 거라고 그러면서 그런 그리고 딱히 뭐 느낀 점은 크게 없는 것 같아요.  근데 설계가 정말 중요한 것 같아요. 마지막에 보니까 모놀리식으로 접근하라고 하는데 저는 한 번 구성한 시스템을 바꾸는 건 참 어려운 일이라고 생각을 하거든요. 구성했다가 다시 덮으려면 그걸 또 짊어지는 사람은 그렇죠 그러니까 처음부터 잘하는 게 나은 것 같기도 하고 그런 생각을 조금 했습니다.

 

주

되게 어려운 게 만약에 쪼개봐 문서 화도에 다시 해야 되고 그거 엔드 포인트 다 관리해야 되는지 누가 할 거야 무조건 마이크로 서비스를 쪼갠다고 그래서 좋은 게 아니라고 좀 들었어요. 그런 하나 뭐야 링크 하나 공유해 드릴게요 네이버에서 되게 재밌었어

 

윤

나는 솔직히 얘를 도입하고 싶은 목적이 뭐냐면 속도거든 나는 속도요 일단 관리 포인트라기보다는 관리 포인트 어차피 우리는 다른 사람이 다 관리하는데 굳이 관리 포인트의 분산이라기보다는 속도에만 이슈를 맞추고 프로세싱 속도요
단계별 처리 속도 개발 속도 말씀하시는 거예요. 아니 아니 프로세싱 속도

 

주

프로세싱 속도는 모놀리가 더 빠를 텐데요. 
왜냐하면 리가 왜냐하면 네트워크 통신을 마이크로 서비스는 지속적으로 해야 되기 때문에 사실 속도를 마이크로 서비스를 개선하기는 좀 힘들 것 같아요.

 

윤
근데 데이터가 전체적으로 이동하고 이동하고 이동하는 개념이라면 솔직히 둘 다 별 차이가 없는데 그냥 리턴 값만 가져와서 처리하는 방식으로 한다면 결괏값만 가져와서 처리를 한다면 솔직히 그림이 그려지기는 하거든 지금 카프카로  할 때도 솔직히 이스티오를 넣거나 그럴 깜냥은 안 되지만

 

주
카프카를 하면 이 스튜를 중간에다가 끼어 다는 게 아니라 어차피 서비스는 이스티올 게 게이트웨를 통해서 가기 때문에 카프카에서는 굳이 얘가 이스트로 돼 있는지는 모르지만 결국엔 이스티오

 

윤

그러니까 엔드 포인트가 되게 많아지면 많아질수록 속도가 처리 속도가 되게 빨라지기는 하거든요. 개념적으로

 

주
반대 아니에요? 엔드 포인트가 많아질수록 느려지는 게 맞는데 왜냐하면 그만큼 네트워크 트래픽을 감당해야 되는데

 

윤

네트워크 트래픽을 감당한다면 ! 이거 우리 집은 물리적인 분석 속도가 느리기 때문에

 

혜
네트워크는 그냥 네트워크 속도의 그거 느린 것보다 물리적인 속도가 더 느리다는 말씀인 거죠.

 

윤

우리 한마디로 분산 처리를 되게 많이 하겠다. 

 

주
잘 모르겠습니다. 제가 생각하는 개념은 분산 처리와 마이크로 서비스는 좀 별개로 별개로 보는 게 맞는 것 같아서 저는 좀 힘들 것 같아요.