StarLord

넷플릭스는 Key-Value String Data의 영속성 Layer로 어떠한것을 사용했는지, 어떤 비즈니즈 요구사항에 적용했는지 리서치 해보았다. 관련 포스팅https://netflixtechblog.com/introducing-netflixs-key-value-data-abstraction-layer-1ea8a0a11b30 Introducing Netflix’s Key-Value Data Abstraction LayerVidhya Arvind, Rajasekhar Ummadisetty, Joey Lynch, Vinay Chellanetflixtechblog.com https://netflixtechblog.com/introducing-netflix-timeseries-data-abstraction-l..

원문링크https://netflixtechblog.com/the-netflix-cosmos-platform-35c14d9351ad The Netflix Cosmos PlatformOrchestrated Functions as a Microservicenetflixtechblog.com Cosmos 소개Cosmos는 마이크로서비스의 장점과 비동기식 워크플로우 및 서버리스 기능을 결합한 컴퓨팅 플랫폼입니다. 그 장점은 몇 분에서 몇 년까지 지속되는 복잡한 계층적 워크플로우를 통해 조정되는 리소스 집약적 알고리즘을 포함하는 애플리케이션입니다. 한 번에 수십만 개의 CPU를 사용하는 높은 처리량 서비스와 인간이 계산 결과를 기다리는 대기 시간에 민감한 워크로드를 모두 지원합니다. Cosmos 탄생 배경Netfl..

원문링크 : https://netflixtechblog.com/rebuilding-netflix-video-processing-pipeline-with-microservices-4e5e6310e359 Rebuilding Netflix Video Processing Pipeline with Microservices This is the first blog in a multi-part series on how Netflix rebuilt its video processing pipeline with microservices, so we can maintain… netflixtechblog.com Netflix가 어떻게 마이크로서비스로 비디오 처리 파이프라인을 재구축하여 빠른 혁신 속도를 유지하고 회원 스트리..

관련링크 : https://www.cncf.io/blog/2020/04/13/serverless-open-source-frameworks-openfaas-knative-more/ Serverless Open-Source Frameworks: OpenFaaS, Knative, & more Originally published on the Epsagon blog by Ran Ribenzaft, co-founder and CTO at Epsagon This article will discuss a few of the frameworks mentioned above and will go deep into OpenFaaS and Knative to… www.cncf.io 지난 수년동안 Serverless Arch..

SaaS Boost 배포 과정 설명 1,2,3) SaaSBoost 환경을 프로비저닝 한다. https://github.com/awslabs/aws-saas-boost 4) 프로비저닝된 SaaSBoost 환경에 로그인 한다. 5) 앞으로 배포하게될 어플리케이션을 등록한다. 6) ECR레지스트리에 Image Build된 해당 어플리케이션을 Push 한다 7) 테넌트에 배포한다. SaaSBoost 콘솔 SaaSBoost 콘솔 아키텍처 Git소스코드를 보면 SaaSBoost의 모든 어플리케이션은 Lambda에서 돌아간다... 콘솔뿐만 아니라 다양한 도메인을 Lambda로 구성해서 운영하고 있다. 도메인은 Onboarding, Metrics, User, Settings, Tenant, Quata가 있다. Bill..

모든 개체에는 수명 주기가 있습니다. 객체는 생성되고 다양한 상태를 거치며 결국 아카이브되거나 삭제되어 죽습니다. 물론 이들 중 다수는 생성자를 쉽게 호출하여 생성되고 일부 계산에 사용된 다음 가비지 수집기에 버려지는 단순하고 일시적인 개체입니다. 그러한 개체를 복잡하게 만들 필요가 없습니다. 그러나 다른 개체는 수명이 더 길며 모든 개체가 활성 메모리에서 소비되는 것은 아닙니다. 그들은 다른 객체와 복잡한 상호 의존성을 가지고 있습니다. 그것들은 불변이 적용되는 상태 변경을 거칩니다. 이러한 개체를 관리하는 것은 MODEL-DRIVEN DESIGN 시도를 쉽게 탈선시킬 수 있는 Challenge를 야기합니다. Challenge는 두 가지 범주로 나뉩니다. 1. 라이프 사이클 전반에 걸쳐 무결성 유지 2..

결합 가능한 한 관계를 제한하는 것이 중요합니다. 양방향 결합은 두 객체가 함께있어야만 이해될 수 있음을 의미합니다. 응용 프로그램 요구 사항이 양방향 순회를 요구하지 않는 경우 순회 방향을 추가하면 상호 의존성이 줄어들고 설계가 단순화됩니다. 도메인을 이해하면 자연스럽게 방향성을 알수 있습니다. 미국에는 다른 많은 국가와 마찬가지로 많은 대통령이 있습니다. 이것은 양방향, 일대다 관계입니다. 그러나 우리는 "조지 워싱턴"이라는 이름으로 시작하여 "그는 어느 나라의 대통령이었습니까?"라고 묻는 경우는 거의 없습니다. 실용적으로 우리는 "국가"에서 "대통령"으로 이동하는 단방향 연결 관계를 줄일 수 있습니다. 이 개선은 실제로 도메인에 대한 통찰력을 반영할 뿐만 아니라 보다 실용적인 디자인을 만듭니다. 그..

객체 지향 프로그램에서 UI, 데이터베이스 및 기타 지원 코드는 종종 비즈니스 객체에 직접 작성됩니다. 추가 비즈니스 로직은 UI 위젯 및 데이터베이스 스크립트의 동작에 포함됩니다. 이것은 단기간에 작업을 수행하는 가장 쉬운 방법이기 때문에 발생하는 이슈 입니다. 도메인 관련 코드가 이렇게 많은 양의 다른 코드를 통해 확산되면 보고 추론하기가 매우 어려워집니다. UI에 대한 피상적인 변경은 실제로 비즈니스 로직을 변경할 수 있습니다. 비즈니스 규칙을 변경하려면 UI 코드, 데이터베이스 코드 또는 기타 프로그램 요소에 대한 세심한 추적이 필요할 수 있습니다. 일관된 모델 기반 개체를 구현하는 것은 비실용적입니다. 자동화된 테스트는 어색합니다. 각 활동에 관련된 모든 기술과 논리로 인해 프로그램은 매우 단순..

만약 소프트웨어 디자인이 도메인 모델과 매핑되지 않는다면, 그 모델은 가치가 없거나 소프트웨어의 정확성이 의심된다. 동시에 모델과 디자인 기능간의 매핑의 복잡성은 이해하기 어렵고 디자인 변경에 대한 유지관리가 어렵다. 분석과 디자인 사이에 치명적인 격차가 발생하여 각각의 활동으로 부터 얻은 인사이트가 서로 영향을 미치지 못하는 상태가 발생한다. MODEL-DRIVEN DESIGN은 해석 모델과 디자인의 이분법을 버리고 두 가지 목적을 모두 충족하는 단일 모델을 찾습니다. 순전히 기술적인 문제를 제외하고 디자인의 각 개체는 모델에 설명된 개념적 역할을 합니다. 이것은 두 개의 완전히 다른 목표를 충족해야 하기 때문에 우리에게 더 부담지우긴 합니다. 매핑이 명확하게 도메인 모델을 문자 그대로 소프트웨어 시스..

모델을 기반하는 커뮤니케이션은 UML과 같은 Diagram이 국한되어 하는 것이 아니다. 가장 효과적으로 모델을 사용하기 위해서 전달 방식을 스며들게 할 필요가 있다. 이것은 Text 문서의 활용성을 높일 뿐만아니라 에자일 프로세스에서 비형식적이고 캐쥬얼한 의사소통을 가능케한다. 이를 Ubiquitous Language라고 한다. 모델에 대한 설명의 비용, 오해의 리스크는 매우 높으므로 프로젝트에는 튼튼한 공통된 언어가 필요하다. 팀이 도메인 모델에 공을 많이 들이면 도메인 모델은 커뮤니케이션의 주측이 될 수 있다. 이것이 유비쿼터스 언어라고 할 수 있다. 초기 모델은 유비쿼터스 커뮤니케이션을 수용하기에는 부족한 수준으로 간결할 것이다. 해당 분야의 특정 용어에 대해서도 풍부하게 의미전달을 못할것이다. ..