마이크로서비스(Microservice)란 큰 서비스 하나를 여러 개의 작은 서비스로 나눠서 개발하는 것을 뜻합니다. 원래 없던 개념이 아니고 레거시 인스턴스 방식으로 이미 구현이 가능하나, Serverless 방식이 마이크로서비스와 궁합이 잘 맞아서 점점 더 많이 사용되고 있는 추세입니다.
좋은 아키텍처(Architecture)란 무엇입니까 ?
추상화(Abstraction) + 디커플링(Decoupling)
추상화를 통해서 복잡성을 단순화 시키고, 디커플링을 통해서 결합을 느슨하게 해야 확장과 유지관리가 쉽습니다. 이는 앱개발, 프론트엔드, 백엔드 및 전체 설계와 관계없이 공통적으로 적용이 되는 말입니다.
마이크로서비스는 일반적으로 API를 통해서 서비스간 통신을 하며(추상화), 느슨하게 결합(loosely-coupled)된 구조(디커플링)로 분리합니다.
이미 구축된 큰 서비스를 여러 개의 모듈 형태의 작은 서비스로 분해할 수도 있고, 애자일(Agile) 방식의 개발을 하는 스타트업의 경우 뼈대가 없는 가지치기 형태로 서비스를 구축 및 확장해 나갈 수 있습니다.
AWS 마이크로서비스에서 말하는 마이크로서비스의 장점으로는 민첩성, 유연한 확장성, 손쉬운 배포, 기술적 자유, 재사용 가능한 코드, 복원성 등 그만큼 잘 구성할 경우 매우 좋은 설계 방식입니다. 단점으로는 트랜잭션의 구현이나 서비스간의 조정, 테스팅등이 약간 복잡해질 수도 있습니다.
폴리글랏(polyglot)이란 ?
마이크로서비스 설명을 찾아보다보면 폴리글랏(polyglot)하기 좋다는 말이 많이 나옵니다. 폴리글랏이란 하나의 서비스를 다양한 언어와 환경을 통해 구현 한다는 것입니다. 마이크로서비스는 서비스 하나하나가 독립적이다보니 A라는 서비스는 Node.js + DynamoDB로 구성하고 B라는 서비스는 Java + MySQL로 구성하는 것이 가능하다는 것입니다.
폴리글랏(polyglot)하지마세요!
마이크로서비스에 대한 글들을 읽다보면 마치 폴리글랏(polyglot)이 장점에 비추어 설명들을 많이 하고 자사에 마이크로서비스를 도입하면서 폴리글랏(polyglot)도 할 수 있게 되어 신난다는 직원의 포스팅도 보았습니다. 물론 한 가치 프레임에 갇혀서 똑같은 작업을 하다보면 폴리글랏 같은 것을 시도하여 재미를 느낄 수도 있지만 이는 인력풀이 충분한 중소기업 규모 이상의 회사에서의 얘기이고 인력이 적은 스타트업의 경우 폴리글랏의 도입은 운영이 더 힘들어질 수도 있습니다. 기존 스택이 Node인데 폴리글랏을 통해 Spring을 도입했다면 Node 개발자와 Java 개발자 모두가 필요하고 혹시나 Java 개발자가 아프거나 퇴사를 해버리면 다른 개발자가 백업을 하기 힘들수도 있습니다. 물론 모든 구성원이 폴리글랏의 모든 언어와 프레임워크를 알면 문제가 되지 않지만 하나만 잘하는 사람도 구하기 힘든 스타트업의 여건 상 폴리글랏은 도입하지 않는 것이 좋습니다.
출처: 위펄슨 기술블로그
