kenu
61k
2022-03-28 17:04:23
11
6854

MSA는 80%정도의 희망고문


요즘 k8s는 잠잠해지고 있습니다. docker 사용하기 편하라고 나온 기술인데, 2년 전보다 조용하게 느껴집니다.

k8s를 사용하는 기업은 서버 자원 팡팡 써도 될만큼 트래픽 많고, 민감한 곳에서 사용하는 기술입니다.

k ubernate s
    ☝8char

5,6년 전에는 빅데이터가 비슷한 단어였습니다. 그런데 현재 빅데이터 분야에서 일하는 개발자 몇분이나 계신지요. 사람이 많으면 블로그 글도 많고, 이슈도 많이 공개될 터인데, 제 주변에서는 조용합니다. 물론 잘 하시는 분들은 소리 소문없이 조용하지요.

이런 생각을 하는 분 혹시 계실 수도 있다고 생각합니다.

닭 잡는데 소 잡는 칼 쓰면,

유튜브 콘텐츠 건지겠다. <-- 이런 느낌

서두에 얘기한 쿠버네티스나 도커를 사용하면 서버 유지비 제법 듭니다. 저는 이 비용 때문에 그냥 shell script로 퉁 칩니다. 왜냐하면 트래픽이 별로 없기 때문입니다. 뭐, 국가에서 연구비 지원받으면서 연구할 수 있다면, 당근 빠따로 돌립니다.


프로그래밍 취업하느라 입구컷은 알고리즘이고, 면접컷은 요즘 MSA입니다. 알고리즘은 백준이나 프로그래머스에서 시도나 부담없이 해 볼 수 있지, MSA는 서버 구성해서 한 시간 정도 제대로 사용하면 천원 이상 듭니다. 하루 24시간이면 2만4천원 한달이면 70만원+

클라우드 서비스는 테스트하고 서버는 Terminate 하는 게 미덕입니다.

하지만 회사 입장에서 월 70만원은 뭐 투자라고 하기에도 적은 금액입니다만 회사는 HA 그리고 서비스 안정성으로 함부로 건드리기 힘들죠.


MicroServices Architecture 에서 유명한 분이 Chris Richardson 입니다.

2012년 그분의 발표를 어쩌다가 듣게 되었는데, 그 당시에는 아키텍처는 있는데, 그 아키텍처에 대한 이름이 없었습니다. 
다음 년도 발표자료라 조금 다르지만 아직 소개된 책을 읽지는 못했습니다.
https://www.slideshare.net/chris.e.richardson/decomposing-applications-for-deployability-and-scalabilityspringsource-webinar


이 책에서 얘기하는 것은 언제 나눌 것인가를 고민하는 내용입니다. 서비스가 너무 커지면 나누기 힘들고, 엮인 것 때문에 그렇다고 계속 가자니 비용이 많이 들고,

반대로 처음부터 나누자니 네트워크 코스트는 큰데 기민성이 떨어지고, 매출도 안 나오고, 콘트롤 하기도 쉽지 않고

이런 고민을 분석한 책으로 알고 있습니다. 번역서 아직 없습니다. 


글이 길어질까봐, 그리고, localStorage 임시 저장 기... 아닙니다.

여튼

세상은 가혹해지고 있고,

거기에 자기만의 적응력이 필요한 것이라고 표현하고 싶습니다.

혼자는 말구요. 함께, 같이, 팔로우 좋아요 뭐 이런 거 하면서 말입니다.


다시 언급하지만, OKKY.kr 사이트는 자신의 경험을 공유하는 공간입니다. #사장님이싫어할수도

하지만 프로그래밍과 삶은 연결되어 있습니다.


- kenu

23
6
  • 댓글 11

  • kenu
    61k
    2022-03-28 17:07:29 작성 2022-03-28 17:12:47 수정됨

    저 영어 조금하는 덕분에 몇 권 없지만 결제해서 구매한 킨들 원서 공개합니다. 다 읽은 건 없고, Refactoring 2판은 많이 재밌게 읽었습니다.


  • leemong77
    1k
    2022-03-28 17:39:46

    와 케누님 말씀 너무 멋지게 하시네요

  • returner
    2k
    2022-03-29 11:36:18

    Enterprise Integration Patterns 참 좋은 책이죠. 두툼해서 꽂아두면 책등을 볼때마다 뿌듯해집니다.

    물론 읽진 않았습니다.



  • jsonobject.com
    593
    2022-03-30 12:13:01

    수년 전 대기업 전산실 근무 시절 kenu 님에게 이메일로 진로 상담 메일을 보냈었는데, 장문의 정성 어린 답장을 받은 기억이 있습니다. 수년이 지난 지금은 나름 스타트업 업계에서 대용량 처리와 클라우드 MSA 전문가로 밥벌어 먹고 살고 있습니다. 유닉스 서버에 자바를 올리던 시절부터 시대의 요구에 카멜레온처럼 변해가며 지금까지 생존하며 느끼는 건, 10년 전이나 지금이나 기술의 본질은 크게 달라진 것이 없다는 생각이 듭니다.

  • 사자카로스
    1k
    2022-03-31 12:26:04 작성 2022-04-01 12:29:57 수정됨

    MSA형태로 개발하다가 요즘은 최대한 소스들을 통합하고 있습니다.

    기능이 적을땐 MSA로 개발하는게 오히려 편했습니다.

    API와 이벤트에 대한 처리방법, 도메인 설계만 잘 해놓으면

    하나의 서비스 역할에만 집중해서 구현하면 되기에 개발 퍼포먼스도 잘 나왔죠.

    근데 서비스의 기능이 복잡해지고 커지면서 신경써야 할 것들이 기하급수적으로 커져버립니다.

    애초에 기획에서 이렇게는 절대 안 한다고 했던 부분들이 지켜지질 않습니다.

    이런 부분들을 수정하기 위해 인력을 투입해서 그 이상의 매출을 늘릴수 있으면 상관없지만

    대기업 아니면 인력충원하기는 쉽지 않죠.

    결국 기능에 집중한 개발을 지향하기 위해 MSA 형태로 개발했으나(+기타 이유)

    복잡도가 증가하면서 교통정리하는데 더 많은 리소스를 쏟는 모양새가 되었습니다.

    새로운 기능(or 서비스)이 추가되더라도

    새로 서비스를 만들기보단 현재 있는 서비스에 어떻게든 껴넣는 형태로 개발을 진행할 예정입니다.

  • 무포로
    -392
    2022-04-02 11:05:47

    인정..

  • 아슈
    1k
    2022-04-04 09:48:50

    EIP 책 너무 좋아요 두툼해서 모니터 밑받침으로 쓰면 이만한 책이 없습니다. ㅋㅋ


  • SWE
    33
    2022-04-07 19:55:56 작성 2022-04-07 19:57:13 수정됨

    요즘 k8s는 잠잠해지고 있습니다. docker 사용하기 편하라고 나온 기술인데, 2년 전보다 조용하게 느껴집니다.

    퍼블릭/프라이빗 클라우드 환경에서 컨테이너를 활용하는 기업은 점점 늘어나고 있고, 최근까지도 대부분의 경우 컨테이너를 활용할 때 가장 먼저 고려대상이 되는게 K8s입니다. 

    K8s는 docker 를 위한 기술은 아닙니다. 오히려 docker 를 쓰지 않는 방향으로 나가고 있죠.

    MSA도 K8s도 스타트업에 적합한 모델/기술이 아니라는 말씀에는 동의합니다.


  • 코딩잘하기
    1k
    2022-04-09 16:39:59

    희망고문이라기 보다는 트래픽 많아야 쓸만한 기술이 아닌가 싶네요. 

  • SWE
    33
    2022-04-12 16:51:52

    단순하게 트래픽이 많은거면 스케일 아웃 하면 되죠. (획일적으로 생각할 수 있는건 아니지만)

    나중에는 스케일링해도 트래픽을 쫓아가지 못하는 상황이 생기지만, 그건 MSA랑 상관 없는 이야기인것 같구요.


    개발 조직이 너무 크거나, 여러개로 쪼갤 수 있는 도메인이 너무 크거나, 단일 소스 레포지토리가 너무 크면 MSA도입을 고려할 때인 것 같고, 그게 아니라면 MSA에 관해 논할 필요조차 없는 것 같습니다. 논할 필요가 없으니 희망고문이 될 이유가 없죠. 일반적으로 서비스 개발 시작은 모놀리식으로 하는게 맞다는 전제입니다.

  • SWE
    33
    2022-04-12 17:07:19 작성 2022-04-12 17:09:46 수정됨

    모놀리식으로 가다가 하나 하나 분리해 나가다 보면 MSA가 되는거죠. MSA는 도입할지 안할지를 결정해야하는 '기술 스택'같은게 아니라, 대규모 서비스 (조직이 대규모이든, 단일 도메인이 대규모이든, 소스 레포가 대규모이든) 가 지향해야할 아키텍쳐'론'이라고 생각합니다. 

    MSA가 왜 존재하는지에 대한 이유 없이, 다른 유명한 서비스는 MSA 로 이런부분이 좋았다는데 왜 우리는 저렇게 안될까를 고민하기 시작하면 희망고문이겠네요.

    애시당초에 한국에서 MSA를 논해야할 정도로 대규모인 서비스가 몇개나 될까요. 서비스의 크기도 그렇지만, 남한에서 서비스 런칭하는 정도라면 클라우드 리전 하나로 커버됩니다. 트래픽 늘어나면 단일 리전 내에서 스케일링해버리면 문제 없죠. 북미같은 경우엔 서비스 자체는 대규모가 아니어도 디플로이/테스트/스케일링을 생각하면 컨테이너(K8s)와 MSA를 고려하는 곳도 있는 것 같습니다. 한국 국내서비스에선 여러 리전에 디플로이/테스트/스케일링 할 고민을 하지 않아도 되니 MSA 고민해야할 이유가 하나 더 적어집니다.

    MSA철학에 준거해서 도메인을 잘게 나누어서 각각을 서비스로 하려고 하면, 손 정말 많이 갑니다. 필요에 따라 거대 도메인이 생기지 않을정도로 나누면 충분할 것 같군요.

    -2
  • 로그인을 하시면 댓글을 등록할 수 있습니다.