신입한테 물어보지 않았으면 좋겠는 질문. MSA
면접 질문으로 받았을 때, 제일 악랄하다고 느꼈던 질문이다.
- 모놀리식 아키텍처와 MSA에 대해 아시나요?
- 두개의 차이는 무엇인가요?
- 어떤 장점과 단점이 존재하나요?
개인적으로 이런 질문을 정말 싫어한다.
이유는 정말 단순한데, 경력자들도 하기 힘들어가지고 헤메는 작업인데
개발이라는 세상에 처음 발을 내딪는 신입한테 무슨 대답을 원하는지에 대한 의문이다.
뭐, 대답은 할 수 있다. 웹에 퍼져있는 수많은 정보를 외워가지고 대답을 할 수 있다.
이해를 해서 이야기를 한다? 그럴거면 신입이 아니라 시니어겠지...
경험해보지 않은 것에 대해서는 그저 웹에 퍼져있는 지식수준에서 넘어서지 못할 것이라 생각한다.
그래서 결론이 뭐냐면 제발 좀 저런건 물어보지 않았으면 좋겠다(....)
그럼에도 신입(취준생)인 내가 작성하는 이유
그럼에도 불구하고, 이러한 신입(취준생)인 내가 비교를 하려고 글을 작성하는 이유는 하나다.
내가 지식이 틀릴 때 마다 지적을 해주시는 분들이 너무 많았고, 찾아보라며 자료도 주시는 분들이 정말 많았다.
(언제나 감사드립니다.)
수많은 지식을 가지고 계신 시니어분들이 정말 많고, 그것을 알려주기 위하여 키워드, 자료, 서적을 찾아서
시크하게(ㅋㅋ) 한마디만 하고 가시는 분들이 정말 많다.
그래서 내가 알고 있고, 알 수 있는 수준에서, 헷갈렸던 부분을 적어보는 포스트를 작성한다.
덤으로 원래 잘 알고 있는 사람들이 설명을 하는 것보다
아무것도 모르는 애가 설명을 하는게 이해가 잘 되는 경우도 있다.
지식이라는 것은 도화지와도 같은 것이기에 처음에 선을 긋는 것이 중요하다고 생각하지만
이미 완성되어있는 그림을 고치려고 하면 쉽지 않다는 것을 느끼게 된다.
지식이 없을 경우, 편견이 없기에 사람의 질문이 날카롭다는 것과 동일하다.
모놀리식 아키텍처
모놀리식 아키텍처란, 애플리케이션을 구성하는 요소가 한개로 되어있는 형태를 이야기한다.
사전적 뜻과 같은 의미로 사용된다.
솔직히 이렇게 말하면 모르겠다, 그래서 사진을 많이 쓴다고 생각하는데
한개의 어플리케이션을 구성함에 있어서 한개의 폴더에서 모조리 다 작업하는 것이라고 볼 수 있을 것 같다.
이렇다면 발생할 수 있는 부작용이 무엇일까? 생각을 해보면, 내가 작업하고 있었던 것에서도 확인할 수 있다.
모놀리식 아키텍처의 단점
단점은 당연히 여러가지가 있다.
개인적으로는 장점보다는 단점이 중요하다고 생각하는 사람이기에, 단점을 먼저 언급하려고 한다.
1. 작은 수정사항에도 전체를 빌드 및 배포해야하는 문제.
내가 메인 프레임워크 사용하고 있는 NestJS에는 자동적으로 watch 옵션을 걸면
프로젝트 상의 코드가 바뀔 경우 재시작을 해주는 옵션이 존재한다.
하지만, 이것에는 아쉬운 점이 있는데. 나는 콘솔을 찍고 싶어서 콘솔로그 하나만 작성을 해서 저장을 했는데
프로젝트를 껐다가 새로 실행을 한다.
뭐, 가볍다면 문제가 없겠지만 팀프로젝트였기에 망정이지 프로덕트였다면 엄청 무거울 것이기에 시간적 손실이 발생할 것이다.
(물론 위의 문제에서는 Hot reload라는 해결책이 있다!)
그리고 저것은 "로컬"에서 벌어진 문제인데, 만약에 로컬이 아니라면 어떨까?
CI/CD를 거쳐서 배포가 이루어질 수는 있겠지만. 그래도 엄청난 시간이 소모가 될 것이다.
크리티컬한 문제가 발생해서, 수정을 무조건 해야만 하는데
한줄을 추가하기 위하여 몇시간의 빌드를 해야하는 상황이 생긴다는 것이다.(이건 잘 모르겠는데 설마 몇시간이 걸리나싶기도)
2. 한 개의 에러가 서버를 죽이는 문제.
위의 에러코드는 OAuth 서비스의 클라이언트 ID가 제대로 입력되지 않아 발생할 수 있는 문제다.
근데 저것으로 인하여 어떤 문제가 발생하냐면... 서버가 안켜진다.
물론, 소셜로그인 정말 중요하다. 로그인이 안되면 별 일이 다 생길 수 있다.
그런데 만약에 소셜로그인을 뒤늦게 도입하여, 사용자가 상당히 적고
상대적으로 로그인이 중요하지 않은 서비스를 하고 있다면 어떨까.
사용빈도수가 낮은 소셜로그인때문에 서버자체가 마비가 되서 홈페이지가 죽어버리는 상황이 발생한다.
많은 사람들이 작업을 하고 있고, CI/CD 테스트코드등 수많은 에러를 잡기 위한 노력을 함에도 불구하고
개발자들은 언제나 에러와 전쟁을 하고 있는데
예측하지 못한 에러가 발생하여 서버가 멈추고, 서비스가 중단되고 쉽사리 해결책을 찾지 못한다면
사용자입장에서는 부정적 경험이 쌓여서 사용을 멈출지도 모른다.
개인적으로는 제일 큰 단점이라고 생각한다. 그리고 에러를 고치면 또 긴 빌드와 배포도 필요한건 덤이다.
3. 언어와 프레임워크의 선택의 한계
이것은 내가 가지고 있던 착각이기도 하고, 이 글을 쓰게된 이유기도 하다.
무엇이냐면, 언어와 프레임워크를 섞어쓰기 위해서는 무조건 MSA를 사용해야만 한다! 라고 생각을 했었다.
근데 아니였다 (아니라고 혼났음)
언어를 섞어쓰는 것은 폴리글랏 프로그래밍이라는 용어가 따로 존재를 했다.
언어를 왜 섞어쓰냐? 라고 물어본다면, 언어적 특징이 존재하기 때문인데
올림피아드라던가 상위알고리즘 문제에서는 자바스크립트가 그냥 없다.
왜?
느려서일걸요?(아마도?)
C는 너무 천재의 영역이고 C++로 많이 푼다고 봤던 것 같은데..
언어적 특징이 존재하기 때문에 다양한 언어를 사용해야하는 일이 발생한다.
그러면 그냥 한개의 프로젝트에서 섞어쓰면 되는데 왜 안하냐? 라고 질문을 할 수 있다.
이 부분에 대해서는 조금 더 찾아봐야할 것 같은데 그냥 미친듯이 어려운 것같다.
검색해도 제대로 안나오고.... 맨날 언어 섞어쓸 때는 MSA를 해야한다 이런 말이 있는 것으로 보아서는(....)
<뭔가 정보가 생긴다면 추가로 작성해보겠습니다 이 부분에 관해서는>
4. 유지보수성의 문제.
이건 그냥 뻔한 문제라고도 생각한다. 한개의 프로젝트에 수많은 폴더와 파일이 존재하고 연관고리가 있다면 그것이 지옥이지..
내가 맨날 붙잡고 있는 객체지향에서도 죽어라 언급하는 문제인데
연관된 관계가 많으면 당연히 유지보수도 어렵고 걍 다 어렵다(.....)
단점을 봤으니, 장점에 대해서 이야기를 해보자.
모놀리식 아키텍처의 장점
아무리 생각해봐도 몇개 없고 길게 설명하기 힘든 것 같은데, 그 몇개가 그냥 엄청 큰 것 같다.
MSA의 단점과 비교를 하는게 맞다는 생각이 드는 것 같기도 하고
1. End-to-End 테스트가 용이하다.
도대체 ETE 테스트(?)가 뭔지 한번 찾아봤는데, 통합테스트인 것 같기도 하다.
애플리케이션의 시작부터 끝까지를 테스트하는 것이 End-to-End 테스트의 정의인데
모놀리식 아키텍처에서는 DB도 그렇고 다양한 옵션들이 붙어있기 때문에 테스트에 드는 비용이 상대적으로 적다는 것이다.
2. 서비스를 빠르게 만들 수 있다.
이것은 그냥 빠르다. 라는 의미보다는 MSA를 적용시킨 모델보다는 빠르게 만들 수 있다는 것에 가깝다.
한개의 언어, 프레임워크로 제작하는 것 뿐만이 아니라 모든 서비스가 연동이 되어있기 때문에
조금 더 서비스를 만듬에 있어 속도를 낼 수 있다는 것이다.
그럼 도대체 마이크로서비스 아키텍처는 무엇인지 알아보자.
마이크로서비스 아키텍처
사람마다 생각하는 것이 다르기에, 함부로 정의할 수 없고 기술이라고 부르기에는 또 애매모호한 점이 있는 용어.
심지어는 성공담만 알려지기 때문에, 이거 정말 좋데! 라는 이야기를 듣고
수많은 회사들에서 MSA를 적용하려고 하는 상황까지 도달했다.
실제로 채용공고를 보면 수많은 회사들이 MSA에 대한 지식을 요구하거나, 경험이 있는 사람을 찾는다는 문구를 볼 수 있다.
근데 경험해본 사람이 정말 희귀하다
그렇다면 MSA가 도대체 무엇이기에, 사람들이 열광을 하는 것일까?
솔직히 나는 모른다.
왜냐하면 경험을 해본 적이 전혀 없기 때문에, 편하다고 해도 얼마나 편한지 알 수 없다.
그래서 글과 유투브를 통하여 알아보려고 한다.
MSA의 특성
이것은 자료를 주셨던 유투브에서 PPT에 있는 문구를 가져온 것이다.
해당 유투브 링크 => https://www.youtube.com/watch?v=wgdBVIX9ifA
그렇지만 모조리 영어기도 하고, 도무지 모르겠으니 누군가 알려줬으면 좋겠다.
근데 내가 공부를 해야하네?
그래서 적어보는 MSA의 특성.
여기서 몇가지는 언급되지 않아서 제외했습니다.
제외된 목록
- Products not Projects. (프로젝트가 아닌 제품)
- Decentralized Governance. (분산된 거버넌스)
- Evolutionary Design. (진화적 디자인)
Componentization via services (서비스를 통한 구성요소화)
애플리케이션의 다양한 서비스를 구성요소로 만들어야한다.
서비스를 쪼개서 구성요소를 만드는 것으로 레고처럼 애플리케이션을 구축할 수 있다.
이럴 경우 서비스가 독립적이기 때문에 개선(업데이트)를 하는 것이 용이하다.
개선된 애플리케이션을 만들기 위하여 모든 것을 변경할 필요가 없다.
문제가 발생하였는데, 업데이트한 라이브러리에서 발생한 문제였다.
하지만 새롭게 추가가 된 라이브러리의 옵션은 무조건 사용을 했어야했는데
이것을 해결할 수 있다는 특성을 가지고 있다.
예시에서는 자바런타임에 관한 이야기가 들어있었으나, 각색했습니다.
Organized around business capbilities. (비즈니스 역량을 중심으로 구성)
비즈니스 기능을 중심으로 팀을 꾸려야한다.
이것을 위해서는 여러가지 요소가 필요한데, 그중에 이상적인 것으로는 최종 사용자에게 초점을 맞추는 것이다.
많은 회사들은 개발 조직이 기술을 중심으로 구성되는데, 그것이 아니라고 이야기하는 듯 하다.
(프론트, 백엔드, 데브옵스 이런 것을 이야기하는 것 같다.)
Smart endpoints and dumb pipes.(스마트 엔드포인트와 멍청한 파이프들?)
마이크로서비스에서는 미들웨어를 통하여 EBS로 모조리 처리하는 것을 거부하고,
해당 비즈니스 로직을 수행하는 것은 엔드포인트에 존재해야한다.
서비스 지향 아키텍처 (SOA)에서는 EBS라는 것이 존재하여 만능한 미들웨어를 통하여
라우팅과 비즈니스 로직을 적용한다는 아이디어가 존재한다.
EBS : 엔터프라이즈 서비스 버스(영어: Enterprise service bus, 약칭 ESB)는 서비스들을 컴포넌트화된 논리적 집합으로 묶는 핵심 미들웨어이며, 비즈니스 프로세스 환경에 맞게 설계 및 전개할 수 있는 아키텍처 패턴이다.
위키백과 참조
Decentralized Data Management. (분산된 데이터 관리)
마이크로서비스 관점에서는 각각의 서비스마다 데이터베이스가 나눠져있어야한다.
각각의 데이터베이스끼리는 서로 연관성이 존재하면 안되며 데이터는 API를 통해서만 사용이 가능하다.
또한 데이터의 지속성, 언어 및 도구의 선택은 전적으로 개별 서비스에서 정해야한다.
모놀리식 아키텍처에는 모든 데이터들이 한개의 데이터베이스에 들어가있다.
SOA에서는 논리적으로 큰 데이터베이스에서 데이터를 사용하는 것이 중요하지만, 반대의 성향이다.
Infrastructure Automation. (인프라 자동화.)
서로 다른 서비스가 유기적으로 연관되어있기 때문에 인프라 자동화가 매우매우매우 중요하다.
블루그린배포같은 지속적인 배포를 적용시켜,가동시간에 공백이 없도록해야만 한다.
더불어서 디버깅을 위한 모니터링 시스템의 구축이 절대적으로 필요하다.
Design for failure. (실패를 위한 설계)
여러 노드에 의해 프로그램이 돌아가기 때문에 실패를 방지하기 위한 설계가 중요하다.
문제를 해결하기 위하여 고의적으로 실패를 유발할 수 있는 도구를 가지고 있다는 것은
복구가 얼만큼 빠르게 되는지 확인을 할 수 있는 척도이기 때문에 필수요소다.
넷플릭스 같은 경우에는 혼돈의 원숭이들(시스템 공격 프로그램)을 통하여 무작위로 노드를 파괴하도록 구축하였다.
이것을 통하여 서비스가 얼마나 탄력적으로 운용할 수 있는지 확인을 하기 위해 사용했다.
영상에서 나오는 모놀리식과 마이크로서비스의 차이
모놀리식 아키텍처
- Simplicity(심플함)
- 한 개의 서비스로 운용하기 때문에 심플하다.
- Consistency(일관성)
- 한 개의 서비스에서 프로세스가 돌아가기 때문에 일관성을 유지할 수 있다.
MSA의 경우에는 다양한 서비스를 통하기 때문에 일관성을 유지하는 것이 어려울 수도 있다.
- 한 개의 서비스에서 프로세스가 돌아가기 때문에 일관성을 유지할 수 있다.
- Inter-module refactoring(모듈 간 리팩토링)
- 한 개의 서비스에서 통신이 오가기 때문에 모듈간 리팩토링이 용이하다.
MSA의 경우에는 각기 다른 서비스에서의 통신이 있기 때문에 상당히 어려운 편에 속한다.
- 한 개의 서비스에서 통신이 오가기 때문에 모듈간 리팩토링이 용이하다.
마이크로서비스 아키텍처
- Partial Deployment(부분 배포)
- 서비스가 부품처럼 나눠져있기에 업데이트가 매우 용이하다.
- Availability(가용성)
- 자동배포가 바탕이 되기 때문에 하루에 새로운 배포가 이루어지더라도 서비스는 끊임없이 제공된다.
- Preserve Modularity(모듈성 유지)
- 서비들이 서로 분리가 되어있기 때문에 모듈간 서로 영향을 끼칠 수 없어서 깨끗한 종속성을 가진다.
- Multiple Platforms(다중 플랫폼, 언어)
- 서비스가 분리되어있기 때문에 상황에 맞게 여러가지 프로그래밍 언어를 사용할 수 있다.
정리
경험을 해본 것이 아니라, 영상만으로 알게된 점을 정리해서 적어보았다.
그런데 계속보다보면, 블로그에 많이 포스팅되어있는 MSA의 장점이 적혀있는 것을 알 수 있었고,
어떤 것이 중요한지에 대해서 이해를 할 수 있었던 시간이였던 것 같다.
또한 MSA에서 폴리글랏이 아닐 수 있다는 것이, 나에게는 제일 큰 수확이라고 생각한다.
나는 지금까지 언어를 다양하게 사용하기 위해서 MSA를 사용한다고 알고 있었기에 더더욱 그런 것 같다.
그리고 반대로, MSA라는 것은 쉽게 도입할 수 없으며 정말 어렵다는 것을 영상 속에서 이야기해주고 있다.
포스팅의 대부분은 성공적인 MSA 구현기를 많이 작성하는데, 나는 반대로 실패한 이야기를 들어보고 싶다.
어떠한 문제가 있었고, 그 문제를 왜 해결하지 못해서 MSA 도입이 좌절되었는가 같은 이야기가 있다면
만약 나중에 내가 직접 작업을 해볼 일이 있을 때 더욱 신중하고 조심스럽게 접근을 할 수 있을 것이라 생각한다.
또, 내가 2014년 영상만 보고 2020년 영상은 보지 않았는데. 시간을 들여서 내용을 한번 업데이트를 할 예정이고
추가적으로 민규님께서 MSA에 대한 이야기를 해주신다고 해서 그 기점으로 글이 한번 더 업데이트가 진행될 예정이다.
면접에서 툭하면 물어보는 MSA에 대하여, 조금 더 심도있는 대답을 할 수 있으면 좋겠고
더불어서 나중에 작업을 하게 되었을 경우 자신있게 제안을 할 수 있었으면 좋겠다.
폴리그랏 : 언어를 여러가지 사용하는 것
점점 느끼는건데, 국내 블로그에서 볼만한 자료가 별로 없는 것 같다..
검색을 해도 중복되는 내용이 너-무 많아서 정작 세밀하게 작성되어있는 글을 보기 너무 힘들다(...)
추가 내용 작성 예정
마크로서비스에 대하여 <-
참고한 자료 & 보면 좋은 자료
Airbnb’s Microservices Architecture Journey To Quality Engineering
Microservices • Martin Fowler • GOTO 2014
When To Use Microservices (And When Not To!) • Sam Newman & Martin Fowler • GOTO 2020
Microservices
