마이크로 서비스 디자인 설계 패턴: 종속성 기반 분해(DDD)입니다 (Micro-Service Design Pattern: Dependency Driven Decomposition (DDD))

이 글은 Ben LugavereMicro-Service Design Pattern: Dependency Driven Decomposition (DDD)글을 번역했습니다. 저의 모든 글은 허가를 받고 진행 하였습니다

대규모 시스템을 구축할 때는 필연적으로 라이브러리 및 타사 api(third party apis)들과 통합해야 합니다. 종종 통합 작업에서 많은 부담을 덜어주는 클라이언트 SDK를 발견할 수 있지만, 필요 없거나 결국 사용할 수 있는 기능도 많이 노출됩니다. 그럼에도 불구하고 코드(및 그 종속성!)는 서버에 휴면 상태로 남아 있습니다.
이로 인해 오랫동안 실행되고 있는 빌드가 비대해지고, 콜드 스타트 속도가 느려지며, 복잡한 프로젝트 설정 및 보안 취약성에 대한 광범위한 노출이 발생합니다.
이 문제에 대한 몇 가지 해결책은 클라이언트 측 세계에 있습니다. 예를 들어 "webpack’s “tree shaking”"은 애플리케이션이 실제로 클라이언트로 전송하기 위해 사용하는 코드만 번들하지만 이러한 솔루션도 서버 측 환경에 최적화되어 있지 않습니다.
서버가 없는 환경에서는 패키지 및 인프라 종속성이 컨테이너 계층에 설치되고 캐시되지만, 실행 때마다 새로운 프로세스가 생성되어 실제로 함수 처리기가 실행됩니다. 즉, 모든 기능을 실행할 때마다 동기적으로 가져온 모든 모듈을 평가하고 실행해야 하며, 비즈니스 로직을 실행하기 전에 모든 초기화 db 연결 및 db 호출이 수행되어야 합니다. 이는 성능 저하 요인이며, 클라우드 공급자가 CPU 사용량에 따라 요금을 청구하는 경우에도 신용 카드 살인자가 될 수 있습니다. 의존성이 높은 애플리케이션의 경우, 규모의 경제를 실현하기 때문에 서버를 사용하는 것이 서버를 사용하지 않는 것보다 더 많이 잘 이해할 수 있습니다.
또한 Leaner 빌드는 더 빠른 연속 통합/CI/CD(Continuous Delivery)를 의미합니다. 즉, 개발 부서에서 빌드에 대기하는 시간을 줄이고 문제를 해결하는 데 더 많은 시간을 소비합니다. 언제든지 수십 개의 빌드가 병렬로 실행되고 있습니다. 컨테이너 시작 기준선을 축소할 수 있는 경우라면 언제든 엄청난 규모입니다.
이제 CI/CD뿐만 아니라 개발 시간과 테스트 시간도 중요합니다. 많은 NPM 패키지를 동시에 가져오면 응용 프로그램의 콜드 스타트 시간이 완전히 으스러집니다.
개발 워크플로우에서 nodemon을 사용하고 싶습니까? 잊어 버리세요. 앱이 시작될 때까지 5-10초를 기다려야 하는 경우에는 감시 모드에서 로컬로 앱을 실행할 수 없습니다.
mocha 대신 jest를 사용 할까요? 말도 안돼요. Mocha는 테스트를 동기식으로 실행하고 노드의 내장 모듈 캐시를 활용하므로 가져오기가 정확히 한 번 필요합니다. Jest를 사용하면 모든 제품군이 한 번에 모든 모듈 분해능을 시작하고 cpu를 잠그는 새로운 프로세스를 구현합니다.
게으른 평가와 같은 문제에 대한 몇 가지 해결책이 있지만, 런타임에도 모든 의존성을 해결해야 합니다. 어느 시점에서는 철값을 지불해야 합니다. 이것은 특히 서버 없는 시대에 접어들면서 JavasScript에서 매우 현실적인 문제입니다.
그래서, 모노리스 시리즈( monolith series)를 녹이는 과정에서, 저는 제가 야생에서 인지했던 또 다른 패턴을 강조하고 소개하고자 했습니다. 저는 이것을 "Dependency Driven Decomposition 또는 DDD라고 부릅니다.
높은 응집력, 낮은 결합력, 고비용 또는 의견의 의존성으로 상태 비저장 구성 요소를 서버 비저장 기능으로 추출합니다. 코어 도메인을 두 번 내리고 기울임과 집중을 유지합니다.
자, 만약 여러분이 그것이 많은 예선이라고 생각한다면 -- 이 남자가 무슨 말을 하고 있는지 -- 여러분이 옳을 것입니다. 이 성분들이 유니콘과 비슷하다는 것은 입이 무겁고 진실입니다. 이러한 툴은 매우 드물고 최적화되어 있지만 항상 툴 벨트에 이러한 툴을 사용하는 것이 좋습니다.
이러한 구성 요소는 대개 주문량이 더 높은 구성 요소입니다. 즉, 이미 존재하는 패키지 또는 유틸리티에 래퍼로 싸여 있지만 팀에서는 이러한 구성 요소와 함께 작업하기 쉽게 하는 일부 내재된 가정이나 규칙을 사용합니다.
여기 예가 있습니다.
PDF Generation. 한동안 우리는 PhantomJS를 사용했습니다. Phantom은 시스템에 독립 바이너리를 설치하고 실행 한 다음 node가 액세스 할 수있는 클라이언트 라이브러리가 필요했습니다. 나중에 PhantomJS는 더 이상 사용되지 않으며 선호하는 PDF 생성 라이브러리는 기본적으로 동일한 기본 바이너리(the same underlying binary)를 사용하여 wkhtmltopdf가되었습니다. 어느 시점에서 우리는 기본 리포지토리에이 패키지 중 4 개를 모두 설치했으며, 설치시 기본 바이너리를 다시 컴파일해야하는 유일한 패키지가 설치되었습니다. 이는 빌드마다 45 초가 추가되었습니다 (테스트마다 모든 빌드마다) 거의 사용되지 않는 총 2 개의 엔드 포인트에 대해 container!). 이것은 우리가 빌드 시간을 단축하고 엔지니어링 속도를 얻기 위해 코어에서 제외 할 수있는 많은 구성 요소 중 하나 일뿐입니다.
다시 한 번 말하지만, 이 패턴의 핵심은 의존성을 상태 저장 핵심 서비스 내에서 유지하도록 최적화합니다. 네트워크 홉을 클라우드 내의 "niche components"와 교환하여 엔지니어링 속도를 높일 수 있습니다. 또한 동기식으로 연결된 마이크로 서비스에서 가용성 트레이드오프가 감소한다는 사실을 알고 있습니다.
다른 사람 생각나세요? 알려주세요! 모든 것을 서버화 하기 전에 아래 코멘트에서 이야기해보죠!
presentation
읽어주셔서 감사합니다!
Ben Lugavere는 Boxed Wholesale의 Lead Engineer 및 Architect로서 주로 JavaScript와 TypeScript를 사용합니다. Ben은 JavaScript, 시스템 설계 및 아키텍처에 대한 모든 내용을 적으며 @benlugavere의 트위터에서 찾을 수 있습니다.
더 많은 글를 보려면 medium으로 저를 따라오거나, 오픈소스를 보려면 github에서 저를 따라오세요!

이 글은 번역 글입니다. 원본 링크입니다.


안녕하세요! Early adopter입니다.
페이스북 [DTF] 디자인 번역 공장 - Design Translation Factory 그룹도 많이 가입해주시길 바랍니다.
"보버"에서 "디자인 번역 공장" 연재를 저와 함께 해주실 분을 찾습니다. 하단 "리뷰" 또는 "페이스북"으로 편하게 메시지 주세요!
PS. 제가 사용하는 블로그 "보버"에 "함께 쓰는 블로그"라는 기능이 요번에 추가됐네요 ㅋ (미디엄에 퍼블리케이션 같은 기능..)
하단 링크 글을 보시면 "디자인 번역 공장"에 어떻게 함께 연재할 수 있는지 자세히 설명되어있습니다. 또는 쉽게 FB 메시지 주세요!
https://bit.ly/2LxR0Bz