온라인의 많은 서비스들은 오프라인의 서비스의 구조를 그대로 가져가는 경우가 많다. 프리젠테이션 소프트웨어는 종이로 하던 것을 컴퓨터 상에서 할 수 있도록 한 것이며, HR 솔류션은 큰 틀에서 기존의 HR 프로세스를 소프트웨어적으로 구현 한 것이다. 고객관리 소프트웨어, ERP 모든게 마찬가지다. 기업의 프로세스를 따라가야 하니 당연히 그럴 수 밖에 없다. 프로세스는 그대로이고 실행 환경을 디지털화 한 것이라 보면 되겠다. 요즘엔 이것을 디지털 트랜스포메이션이라고 하는 것 같다.
Joinc 사이트는 PHPNuke로 시작했다. 그러다가 모니위키(moniwiki)로 갈아탔다. 그렇게 거의 15년 정도를 모니위키로 운영하다가 직접 개발한 위키엔진(엔진의 이름은 gowiki다. gowiki인 이유는 golang으로 개발해서다.) 으로 갈아탔다. 갈아탄 이유는 아래와 같다. 파일기반이라서 너무 느리다. 파일기반이라서 확장에 한계가 있다.gowiki로 갈아탔던 때가 2018년 쯤이었던 거 같은데, 모니위키에 쌓인 컨텐츠가 3,000 페이지 이상이었기 때문에 마이그레이션에도 신경을 써야 했다. 마이그레이션을 위해서 크게 3 부분을 신경썼다.
소프트웨어 개발은 문서로 시작해서 문서로 끝난다. 이유는 아래와 같다. 코드의 소유 동적 평형모든 이의 코드스타일을 알고 있으며, 함께 수년 동안 하나의 솔류션을 개발해 왔다면, 눈빛만으로 무얼하는지 알고 있다면, 즉 이미 아키텍처와 코드를 전부 다 이해하는 팀이라면 문서는 필요 없을 수 있다. 초기에 소수의 창업멤버끼리 사업 모델과 코드를 함께 만든 경우가 되겠다.
우리는 Shopify 서비스를 분석 할 것이다. 이커머스는 프론트 앤드, 백앤드, Payment, 주문, 배송, 상품(Products), 구매자, 사업자(몰 운영자), CRM, BI, 각 종 백오피스, 데이터베이스, 미디어처리, 메시지 처리, API를 포함한 매우 복잡한 시스템이다. 이러한 복잡한 시스템이 어떻게 구성되는지를 살펴보는 것은 엔지니어에게는 매우 흥미로운 과제가 될 것이다. 특히 나는 이커머스 업계에서 일을 하고 있기 때문에, 이러한 시스템을 분석하는 것은 시스템 개발에 큰 도움이 될 거라 생각한다.
ELB(Elastic Load Balancing)는 하나 이상의 가용 영역(AZ)에 있는 여러 개의 대상(Target)에 애플리케이션 트래픽을 자동으로 분산하는 AWS 서비스다. 원리적으로 Reverse Proxy 계통의 서비스이지만, 이쪽의 서비스들이 그렇듯이 기능이 크게 확장되어 있다.ELB는 3가지 유형이 있다. CLB(Classic Load Balancer) ALB(Application Load Balancer) NLB(Network Load Balancer) ELB는 Listener, Rule, Target Group, Health check 4개의 구성요소를 가진다.
5 POSTS HERE
이커머스의 주요 구성요소
온라인의 많은 서비스들은 오프라인의 서비스의 구조를 그대로 가져가는 경우가 많다. 프리젠테이션 소프트웨어는 종이로 하던 것을 컴퓨터 상에서 할 수 있도록 한 것이며, HR 솔류션은 큰 틀에서 기존의 HR 프로세스를 소프트웨어적으로 구현 한 것이다. 고객관리 소프트웨어, ERP 모든게 마찬가지다. 기업의 프로세스를 따라가야 하니 당연히 그럴 수 밖에 없다. 프로세스는 그대로이고 실행 환경을 디지털화 한 것이라 보면 되겠다. 요즘엔 이것을 디지털 트랜스포메이션이라고 하는 것 같다.
GoLang를 이용한 템플릿 엔진
Joinc 사이트는 PHPNuke로 시작했다. 그러다가 모니위키(moniwiki)로 갈아탔다. 그렇게 거의 15년 정도를 모니위키로 운영하다가 직접 개발한 위키엔진(엔진의 이름은 gowiki다. gowiki인 이유는 golang으로 개발해서다.) 으로 갈아탔다. 갈아탄 이유는 아래와 같다. 파일기반이라서 너무 느리다. 파일기반이라서 확장에 한계가 있다.gowiki로 갈아탔던 때가 2018년 쯤이었던 거 같은데, 모니위키에 쌓인 컨텐츠가 3,000 페이지 이상이었기 때문에 마이그레이션에도 신경을 써야 했다. 마이그레이션을 위해서 크게 3 부분을 신경썼다.
Airbnb System design 분석
소프트웨어 개발은 문서로 시작해서 문서로 끝난다. 이유는 아래와 같다. 코드의 소유 동적 평형모든 이의 코드스타일을 알고 있으며, 함께 수년 동안 하나의 솔류션을 개발해 왔다면, 눈빛만으로 무얼하는지 알고 있다면, 즉 이미 아키텍처와 코드를 전부 다 이해하는 팀이라면 문서는 필요 없을 수 있다. 초기에 소수의 창업멤버끼리 사업 모델과 코드를 함께 만든 경우가 되겠다.
Shopify System Design 의 분석
우리는 Shopify 서비스를 분석 할 것이다. 이커머스는 프론트 앤드, 백앤드, Payment, 주문, 배송, 상품(Products), 구매자, 사업자(몰 운영자), CRM, BI, 각 종 백오피스, 데이터베이스, 미디어처리, 메시지 처리, API를 포함한 매우 복잡한 시스템이다. 이러한 복잡한 시스템이 어떻게 구성되는지를 살펴보는 것은 엔지니어에게는 매우 흥미로운 과제가 될 것이다. 특히 나는 이커머스 업계에서 일을 하고 있기 때문에, 이러한 시스템을 분석하는 것은 시스템 개발에 큰 도움이 될 거라 생각한다.
AWS Cheat Sheet - ELB
ELB(Elastic Load Balancing)는 하나 이상의 가용 영역(AZ)에 있는 여러 개의 대상(Target)에 애플리케이션 트래픽을 자동으로 분산하는 AWS 서비스다. 원리적으로 Reverse Proxy 계통의 서비스이지만, 이쪽의 서비스들이 그렇듯이 기능이 크게 확장되어 있다.ELB는 3가지 유형이 있다. CLB(Classic Load Balancer) ALB(Application Load Balancer) NLB(Network Load Balancer) ELB는 Listener, Rule, Target Group, Health check 4개의 구성요소를 가진다.