joinc(주)는 글로벌한 회사로 성정하고 있다. 이 회사는 서울리전, 도쿄리전, 캘리포니아 리전, 런던리전에 VPC를 전개하고 있다. 이외에 대한민국에 데이터 센터를 가지고 있다. 현재 회사는 VPC와 데이터센터의 네트워크 통합에 어려움을 겪고 있다. 서비스가 더 커지기 전에 이들을 통합하는 작업을 수행해야 한다. CTO는 DevOps 팀에 이들 네트워크를 통합할 설계를 지시했다. 지시의 요구사항은 아래와 같다.
클라우드 시스템은 위임이다. 컴퓨팅, 메모리, 디스크와 같은 하드웨어 외에도 로드밸런서, 메시지큐, 로깅, 모니터링, 배포, 확장, 데이터 수집 등을 IaaS, PaaS, SaaS 형태로 비즈니스로직으로 부터 분리하여 위임하는 시스템이다. 따라서 개발조직은 다른 것들에 신경쓰지 않고 서비스 개발에만 집중 할 수 있다. 클라우드에 대한 다양한 관점이 있겠는데, 이중에서 위임이라는 관정을 중요하게 보는 이유는 조직이 핵심가치인 비즈니스에만 집중할 수 있게 해주는 것, 이를 통해서 혁신을 이루기 쉬원 환경으로 만들어주는게 클라우드의 가장 큰 메리트라고 보기 때문이다. 나는 장표상에 계산되는 비용보다 더 중요한 관점이라고 생각한다.
애플리케이션에 대한 아이디어를 실현하는 가장 좋은 방법은 MVP(Minimum Viable Product)로 시작하는 것이다.인터넷은 수백 수천개의 회사가 경쟁하는 열린 공간이다. 이 공간에서 성공하는 것은 쉽지 않다. 성공을 하기 위해서는 고객이 원하는 것이 무엇인지를 찾아서 가능한 빨리 시장에 내놓아야 한다. MVP(Minimum Viable Product)는 2011년 Eric Ries가 도입한 린 스타트업방법론에서 시작된 개념이다. MVP의 정의는 다음과 같다.
Go 언어를 이용해서 백앤드 애플리케이션을 개발한다. 이 애플리케이션은 유저정보를 저장하고, 조회하는 2개의 REST API를 제공한다. 이 애플리케이션을 구조적으로 견고하고 확장가능한 형태로 만들어보려 한다. 아이디어는 에서 가져왔다. 이 문서에서는 클린 아키텍처의 제약 조건을 아래와 같이 설정하고 있다. 1. 프레임워크와 무관하다. 아키텍처는 특정 소프트웨어 라이브러리에 의존하지 않는다. 특정 시스템에 제한된 제약 조건을 두지 않고, 다양한 프레임워크를 도구로 사용 할 수 있어야 한다.
이 문서의 원문은 httpsGitLab 시스템은 루비 온 레일즈(Ruby on Rails)를 이용해서 개발됐지만, 여러 프로젝트에 Go를 사용하고 있다. Go는 많은 장점을 가지고 있는 강력한 언어로 IO(디스크/네트워크)처리, HTTP 요청, 병렬 처리등의 프로젝트에 적합하다. GitLab은 프로젝트를 시작할 때 Ruby on Rails와 Go 어느 것을 선택할지 신중하게 평가해서 선택한다. Go는 2018년 8월까지 자체적인 의존성 관리 시스템을 제공하지 않았다. 개발자들은 각자가 적당한 의존성 관리 툴을 사용해야 했었는데, 다행히 Go 1.11(2018년 8월 24일) 버전 부터 Go Modules 기능이 들어가면서 의존성 관리 환경을 통일 할 수 있게 됐다.
문서에서 로컬에 kubernetes 개발환경을 구축다. 에서 애플리케이션 deployment를 만들었다. Kubernetes POD는 원리적으로 프로세스의 집합이다. 프로세서들이 라이프사이클을 가지는 것처럼 POD 들도 라이프사이클을 가진다. 만약 워커 노드가 죽으면, 워커노드위에 작동하는 POD들도 종료된다. 서버가 죽으면 서버 위에서 작동하던 프로세스의 생명이 어떻게 될지를 생각하면 된다.쿠버네티스에서는 POD에 대한 복제본을 설정할 수 있기 때문에, 워커 노드의 문제로 POD가 내려갈 경우 다른 작동 중인 노드에서 POD를 만들어서 복제본의 총합을 유지한다.
포인터라는 개(멍멍이)가 있다. 이 개는 사냥감의 위치를 가리키는 일을 한다. 위치 정보를 알려주는 녀석이라고 보면 되겠다. 소프트웨어 개발에서 포인터도 마찬가지다. 소프트웨어의 가장 중요한 일은 데이터를 읽고 쓰는 것인데, 이 데이터들은 메모리에 위치한다. 데이터가 저장된 메모리의 주소를 우리는 메모리 주소라고 하며, 0x123456 과 같은 16진수로 표현한다. 따라서 이론적으로 메모리 주소를 알고 있으면 모든 데이터를 조작 할 수 있다. 하지만 인간이 16진수 값으로 데이터를 조작하기는 쉽지 않으니, 변수로 한단계 추상화해서 사용한다. 0x12345 에 "yundream@example.com"을 저장하라는 것 보다 email에 "yundream@example.com"을 저장하라는게 훨씬 쉽다.
헤드리스 이커머스를 다루기 전에 헤드리스 아키텍처(Headless architcture)를 살펴봐야 할 것 같다.헤드리스 아키텍처라고 하면 낯설게 들리겠지만, 오래전에 존재해왔다. 헤드리스 아키텍처라는 것은 모든 비지니스 로직과 기능을 API 세트로 만들어서 제공하는 것을 의미한다. 이 API는 전문화된 백앤드 서버에스 구동되며, 고객이 원하는 모든 경험을 API 형태로 제공한다. 여기까지 설명을 들었다면 요즘 OpenAPI, RESTful API형태로 이미 사용하고 있는 건데 ?라는 생각을 하게 될 것이다. 기본적으로 이 생각이 맞다. 그래서 오래전에 존재해왔다는 의미가 되겠다.
Uber System Design. Design Ride-Hailing Application 영상에 대한 분석이다. 영상내용을 기반으로 좀 더 깊이 들어가보려 한다. 1. Uber의 Ride-Haling Application을 개발하기 위한 요구사항 분석 1. 하이레벨에서 컴포넌트 다이어그램 작성 1. 각 컴포넌트의 시퀀스 다이어그램 작성 1. 잠재적인 병목구간의 확인과 최적화 애플리케이션을 개발하기 위한 일반적인 절차들이다. 개발 요구사항을 분석하면서, 해당 요구사항을 만족하기 위한 주요 컴포넌트들을 식별할 수 있을 것이다. 이제 각 컴포넌트들의 작동방식을 시퀀스 다이어그램으로 만들면 기본적인 개발 분석이 끝난다. 이후에 이루어지는 작업은 요구사항과 다이어그램을 유저스토리로 만들고, 유저스토리를 feature 단위로 쪼개서 구현하는 것이다.
전자상거래는 인터넷을 통해서 제품을 구매하거나 판매하는 활동을 의미한다. 전자 상거래에는 모바일, 전자 자금 이체, 공급망 관리, 인터넷 마케팅, 온라인 거래 처리, 전자 데이터 교환(EDI), 재고관리 시스템 및 데이터의 수집과 분석등의 다양한 시스템으로 구성된다. 전자상거래는 기술 주도의 서비스이며 특히 전자 산업이 가장 큰 영향을 미치고 있다. 전자상거래에는 온라인 소매(online retailing), 온라인 마켓(electronic markets), 온라인 경매 (online auctions)의 3개 영역으로 구분 할 수 있다.
16 POSTS HERE
삼성 클라우드 : AWS Transit Gateway를 이용한 글로벌 AWS Region 네트워크 최적화
joinc(주)는 글로벌한 회사로 성정하고 있다. 이 회사는 서울리전, 도쿄리전, 캘리포니아 리전, 런던리전에 VPC를 전개하고 있다. 이외에 대한민국에 데이터 센터를 가지고 있다. 현재 회사는 VPC와 데이터센터의 네트워크 통합에 어려움을 겪고 있다. 서비스가 더 커지기 전에 이들을 통합하는 작업을 수행해야 한다. CTO는 DevOps 팀에 이들 네트워크를 통합할 설계를 지시했다. 지시의 요구사항은 아래와 같다.
AWS에서의 중앙 집중식 로깅 시스템 구축
클라우드 시스템은 위임이다. 컴퓨팅, 메모리, 디스크와 같은 하드웨어 외에도 로드밸런서, 메시지큐, 로깅, 모니터링, 배포, 확장, 데이터 수집 등을 IaaS, PaaS, SaaS 형태로 비즈니스로직으로 부터 분리하여 위임하는 시스템이다. 따라서 개발조직은 다른 것들에 신경쓰지 않고 서비스 개발에만 집중 할 수 있다. 클라우드에 대한 다양한 관점이 있겠는데, 이중에서 위임이라는 관정을 중요하게 보는 이유는 조직이 핵심가치인 비즈니스에만 집중할 수 있게 해주는 것, 이를 통해서 혁신을 이루기 쉬원 환경으로 만들어주는게 클라우드의 가장 큰 메리트라고 보기 때문이다. 나는 장표상에 계산되는 비용보다 더 중요한 관점이라고 생각한다.
MVP로 비즈니스 계획을 구현하기
애플리케이션에 대한 아이디어를 실현하는 가장 좋은 방법은 MVP(Minimum Viable Product)로 시작하는 것이다.인터넷은 수백 수천개의 회사가 경쟁하는 열린 공간이다. 이 공간에서 성공하는 것은 쉽지 않다. 성공을 하기 위해서는 고객이 원하는 것이 무엇인지를 찾아서 가능한 빨리 시장에 내놓아야 한다. MVP(Minimum Viable Product)는 2011년 Eric Ries가 도입한 린 스타트업방법론에서 시작된 개념이다. MVP의 정의는 다음과 같다.
견고하고 확장가능한 Go 애플리케이션 구축 방법
Go 언어를 이용해서 백앤드 애플리케이션을 개발한다. 이 애플리케이션은 유저정보를 저장하고, 조회하는 2개의 REST API를 제공한다. 이 애플리케이션을 구조적으로 견고하고 확장가능한 형태로 만들어보려 한다. 아이디어는 에서 가져왔다. 이 문서에서는 클린 아키텍처의 제약 조건을 아래와 같이 설정하고 있다. 1. 프레임워크와 무관하다. 아키텍처는 특정 소프트웨어 라이브러리에 의존하지 않는다. 특정 시스템에 제한된 제약 조건을 두지 않고, 다양한 프레임워크를 도구로 사용 할 수 있어야 한다.
GitLab의 Go 표준 스타일 가이드라인
이 문서의 원문은 httpsGitLab 시스템은 루비 온 레일즈(Ruby on Rails)를 이용해서 개발됐지만, 여러 프로젝트에 Go를 사용하고 있다. Go는 많은 장점을 가지고 있는 강력한 언어로 IO(디스크/네트워크)처리, HTTP 요청, 병렬 처리등의 프로젝트에 적합하다. GitLab은 프로젝트를 시작할 때 Ruby on Rails와 Go 어느 것을 선택할지 신중하게 평가해서 선택한다. Go는 2018년 8월까지 자체적인 의존성 관리 시스템을 제공하지 않았다. 개발자들은 각자가 적당한 의존성 관리 툴을 사용해야 했었는데, 다행히 Go 1.11(2018년 8월 24일) 버전 부터 Go Modules 기능이 들어가면서 의존성 관리 환경을 통일 할 수 있게 됐다.
Kubernetes Service
문서에서 로컬에 kubernetes 개발환경을 구축다. 에서 애플리케이션 deployment를 만들었다. Kubernetes POD는 원리적으로 프로세스의 집합이다. 프로세서들이 라이프사이클을 가지는 것처럼 POD 들도 라이프사이클을 가진다. 만약 워커 노드가 죽으면, 워커노드위에 작동하는 POD들도 종료된다. 서버가 죽으면 서버 위에서 작동하던 프로세스의 생명이 어떻게 될지를 생각하면 된다.쿠버네티스에서는 POD에 대한 복제본을 설정할 수 있기 때문에, 워커 노드의 문제로 POD가 내려갈 경우 다른 작동 중인 노드에서 POD를 만들어서 복제본의 총합을 유지한다.
GoLang 포인터 101
포인터라는 개(멍멍이)가 있다. 이 개는 사냥감의 위치를 가리키는 일을 한다. 위치 정보를 알려주는 녀석이라고 보면 되겠다. 소프트웨어 개발에서 포인터도 마찬가지다. 소프트웨어의 가장 중요한 일은 데이터를 읽고 쓰는 것인데, 이 데이터들은 메모리에 위치한다. 데이터가 저장된 메모리의 주소를 우리는 메모리 주소라고 하며, 0x123456 과 같은 16진수로 표현한다. 따라서 이론적으로 메모리 주소를 알고 있으면 모든 데이터를 조작 할 수 있다. 하지만 인간이 16진수 값으로 데이터를 조작하기는 쉽지 않으니, 변수로 한단계 추상화해서 사용한다. 0x12345 에 "yundream@example.com"을 저장하라는 것 보다 email에 "yundream@example.com"을 저장하라는게 훨씬 쉽다.
Headless ECommerce
헤드리스 이커머스를 다루기 전에 헤드리스 아키텍처(Headless architcture)를 살펴봐야 할 것 같다.헤드리스 아키텍처라고 하면 낯설게 들리겠지만, 오래전에 존재해왔다. 헤드리스 아키텍처라는 것은 모든 비지니스 로직과 기능을 API 세트로 만들어서 제공하는 것을 의미한다. 이 API는 전문화된 백앤드 서버에스 구동되며, 고객이 원하는 모든 경험을 API 형태로 제공한다. 여기까지 설명을 들었다면 요즘 OpenAPI, RESTful API형태로 이미 사용하고 있는 건데 ?라는 생각을 하게 될 것이다. 기본적으로 이 생각이 맞다. 그래서 오래전에 존재해왔다는 의미가 되겠다.
Uber System Design 분석
Uber System Design. Design Ride-Hailing Application 영상에 대한 분석이다. 영상내용을 기반으로 좀 더 깊이 들어가보려 한다. 1. Uber의 Ride-Haling Application을 개발하기 위한 요구사항 분석 1. 하이레벨에서 컴포넌트 다이어그램 작성 1. 각 컴포넌트의 시퀀스 다이어그램 작성 1. 잠재적인 병목구간의 확인과 최적화 애플리케이션을 개발하기 위한 일반적인 절차들이다. 개발 요구사항을 분석하면서, 해당 요구사항을 만족하기 위한 주요 컴포넌트들을 식별할 수 있을 것이다. 이제 각 컴포넌트들의 작동방식을 시퀀스 다이어그램으로 만들면 기본적인 개발 분석이 끝난다. 이후에 이루어지는 작업은 요구사항과 다이어그램을 유저스토리로 만들고, 유저스토리를 feature 단위로 쪼개서 구현하는 것이다.
Ecommerce 개요 - 역사
전자상거래는 인터넷을 통해서 제품을 구매하거나 판매하는 활동을 의미한다. 전자 상거래에는 모바일, 전자 자금 이체, 공급망 관리, 인터넷 마케팅, 온라인 거래 처리, 전자 데이터 교환(EDI), 재고관리 시스템 및 데이터의 수집과 분석등의 다양한 시스템으로 구성된다. 전자상거래는 기술 주도의 서비스이며 특히 전자 산업이 가장 큰 영향을 미치고 있다. 전자상거래에는 온라인 소매(online retailing), 온라인 마켓(electronic markets), 온라인 경매 (online auctions)의 3개 영역으로 구분 할 수 있다.