크라슈
1k
2021-12-24 10:33:29 작성 2021-12-27 09:36:34 수정됨
8
682

MSA라... SOA가 생각나네요.


한때 이슈가 매우 컸던 SOA는 서비스와 서비스를 연결하자는 의미인데,

전통적으로 기업내부의 시스템의 연동을 담당했던 EAI가 있었다면, 

SOA는 ESB,SOAP등을 활용해서 서비스와 서비스를 연결하고자 하는 분산시스템의

결정체(?)라고 생각을 했었죠.


2000년대 초반에 EJB,CORBA,COM/COM++등의 분산처리기술들이 나오고, 

웹에 기술과 사상들이 녹아들어가기 시작했죠. 


지금은 용어만 생각나는데, 스텁?,스켈레톤,리플렉션 호출등등,

EJB는 원격기반의 메세지처리나 트랜잭션 처리등 현재거론되는 아키텍처들의 기능적인

요소들을 많이 다루고 있었습니다.


여튼 이런게 중요한게 아니라...SOA가 한때 자바진영의 커뮤니티에서 엄청난 화제여서

당시 재야의 고수분들이 기술적인 베이스는 엄청난 논검들을 했었고,

저는 쪼렙이어서, 오호~ 이런 기술적인 논쟁들이 있는데, 뭔소리인가? 했던 기억이 있습니다.


예전 커뮤티니 중 특히 자바서비스넷이라고 국내에서 자바기반의 기술들에 대한 고수들이

많이 모였던 곳이 있었는데, 제 기억이 맞다면 지금 제니퍼소프트의 이원영 대표님(?)이 

커뮤니티 마스터였던 것으로 기억합니다. 


당시 제니퍼는 신생 솔루션 업체들 중에서 평판이 좋았던 네임드 기업이기도 하죠. 

기억이 맞다면 파주(?)에 사옥도 짓고,카페도 있고,

직원들에 대한 복지가 중소업체들 중에서는 상당히 좋았던 걸로 기억합니다. 

지금이야 뭐 중소기업이라 부르기도 어려울 만큼 성장한 좋은 회사니, 기회가 된다면 입사서류를 내보시는 것도 좋을겁니다. 


각설하고, SOA의 가장 큰 문제점은 ESB의 비대화라고 해야 할까요? 당시에는 기술력도 부족하기는 했지만,ESB에 집중되는 트랜잭션을 감당하기 힘들고, 결국 운영시 부하를 감당하기 힘들었던걸로 기억합니다.


그러다가 최근에 와서 MSA가 등장하죠. 사상은 SOA랑 비슷한데, ESB의 문제점을 어떻게 해결했으니까 결국 최근에 각광을 받고 있겠죠.


전세계적으로 가장 성공한 MSA는 아마존과 넷플릭스입니다. 글로벌 기업이기도 합니다. 사실 제가 하고 싶은 말은 여기입니다. MSA를 서비스하는 것이 좋은 것 같지만, 과연 규모에 상관없이 적용하는게 맞는가?라는 거죠


흔히 MSA의 트랜잭션 처리는  API GateWay라는 부분에서 담당하고 있죠. 게이트웨이는 OSI 7계층에서 4계층에서 쓰는 통신장비입니다.

다른 영역대의 프로토콜을 연결해주는 네트워크 장비죠. 

뭐 실제적으로 실무에서 TCP/IP프로토콜이 주로 쓰이니, 네트워크 장비 최종단계라 봐도 무방합니다. 


일단 이 API 게이트웨이를 앞단에 두고, 분기를 받아서 API-Server라 해야 하는 각각의 쪼개진 마이크로 서비스단에 각각 장비해서 지난날 중앙집중방식의 ESB의 트랜잭션의 문제를 해결하기는 했는데, 위에서도 거론되었듯이, 분산처리시스템은 일단 메세지로 데이터를 주고받습니다.


MSA는 글로벌한 서비스를 위해서는 매우 이상적이기는 한데, 국내한정으로 비지니스 업무처리할 때를 생각해 보죠.


예를 들면, 지금은 로그인을 하고,주문을 하는 것이 DB조인을 하고, 회원정보를 알아내고, 상품에 대한 결제처리가 하나의 트랜잭션에서 원활하게 이루어진다면, 

MSA는 회원에 서버1, 주문에 서버1, 상품에 서버1 등등 각각 부여하고, 통신을 할 겁니다. 그리고 이벤트가 일어나고 메세지로 통신을 할때, 지난날에는 당연히 하나의 사이클에서 쭉 처리되는데......

지금은 로그인 했네요-메세지-상품을 찾습니다-상품서버-오케이......이렇게 통신하고,연결해서,계속 통신을 해야 합니다.


당연히 장점이 많지만, 딱봐도 이런 MSA에는 트랜잭션이 많고,오류가 많을 수밖에 없죠.

결국 오류처리에 신속한 대응을 하기 위한 조직/체계/문화가 필요합니다.

통상적으로 우리는 이걸 DevOps라 부르죠. 운영과 개발을 같이 하면서 소스코드에 대한 실시간 반영을 위한 CI/CD나 도커,쿠버네티스도 필요하고,서비스를 위한 애자일방식을 적용한다면, 스크럼도 해야 할겁니다.


다 좋은데, 한국은 한국 특유의 빨리빨리도 있고, 애자일도 변형된 방식으로 운영이 되고, 개발자들을 혹사시키죠.

더구나 상명하복에 꼰대문화도 꽤 많고, 크런치 모드니 해서 쥐어짜내는 방식으로 일하니......오히려 국내도입된 애자일은 외국사례와 달리 상당히 변질되어서 이용되더군요.


갑자기 오키에서 마이크로서비스 이야기를 보니, 몇마디 써봅니다.


아....참고로 제가 잘 모르고, 틀린 부분도 있을 겁니다. 그런 부분을 알려주신다면 감사히 배우겠습니다.

뭐 그렇다는 겁니다.


0
  • 댓글 8

  • 배틀크루저
    43
    2021-12-24 10:41:04

    MSA에 대한 사상, 이해가 전혀 없는 인간들이 어디서 MSA 듣고와서 MSA로 가는 것만큼

    망조든일도 없다 생각합니다. 아키만 변하는게 아니라 기획, 설계, 개발 서비스에대한 개념자체가

    모두 바껴야 하는데 거기에 대한 이해도 공부할 생각도 없이 MSA한답시고 추진하니 시스템 난리 나더군요

  • 라이라
    4k
    2021-12-24 11:03:17

    포프님이 MSA에 대해서 한때 엄청 깠었죠

  • pooq
    8k
    2021-12-24 11:13:31

    ??? : 못해서 안하는게 아니라 안하니까 못하는겁니다. 

    제대로 모른다고 안하면 영영 못하게 됩니다.
    일단 기본적인 장단점 분석 및 현재 시스템에 적용시 개선 사항등을 분석해서 득이되는 부분이 많다 싶으면 추진해보는거고, 그런 과정에서 새로운 경험을 쌓고, 그러면서 고급 개발자가 되는거죠.


  • 제운
    1k
    2021-12-24 12:58:52

    배민앱 등등 엄청 규모가 크고 트래픽이 많이 발생하는 서비스라면 msa가 필요할거 같습니다. 포스코나 lg 등 msa로 변하는 추세고요. 주로 클라우드랑 접목시키면 적은비용으로 독립적인 서비스를 할수 있다는게 장점이죠.

    트래픽이 크게 발생하지 않는 일반 기업용 사이트라면 굳이 할필요가 없죠.

  • 페코옹
    1k
    2021-12-24 13:08:55

    말씀 하신거 처럼 모든 정보를 silo하게 만들어서 트랜잭션 기반으로만  처리하는 경우도 있고, 

    데이터 중복을 허용해서 트랜잭션을 최소화하는 형태도 있고,

    굉장히 다양한 msa의 사용형태가 있지요.


    예를 들어 상품 리뷰 정보에 사용자 id, 이름, 아바타 등의 유저 정보를 중복되게 저장하고,

    사용자 정보가 변경되면 리뷰 정보에 있는 사용자 정보도 같이 수정하는 형태이죠.


    이런 식으로 모놀리틱에 비해 전체 아키텍쳐가 복잡하고 트랜잭션 처리나 디비 구조에 대한 고민할 부분이 많고 유지보수 포인트 증가 등 단점이 있지만 명확한 msa의 장점이 있는 만큼, 우리나라 많은 기업들이 앞다투어 도입하는 거 아닌가 하네요. 


  • 페코옹
    1k
    2021-12-24 13:18:43
    무엇보다 메시지 기반 처리를 하다보니

    사용자 정보는 노드 postgresql로
    상품 정보는 파이썬 mysql로
    결제 정보는 자바 몽고디비로

    요즘 같이 자바 스프링만이 아닌 다양한 백엔드 프레임워크가 사용되는(아닌가요? ㅋㅋ) 시대에 어울리는 아키텍처가 아닌가해요.
  • 구직인
    629
    2021-12-24 14:07:17

    트래픽이 배민수준이라면 msa는 선택이 아니라 필수아닌가요?

    대체 할 수 없을텐데...

  • star16m
    809
    2021-12-25 09:01:44

    api 게이트웨이는 그런게 아닙니다

    말그대로 api들의 입구라고 생각하시면 됩니다

    트랜잭션은 msa에서 다른방식으로 해결합니다

    오히려 오프라인에서의 업무방식과 유사하죠


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