연주 로그

지속적 통합(CI) 

여러 사람이 작업하는 코드들의 동기를 맞출 목적으로 지속적 통합이 필요하다. 이러한 지속적 통합을 마이크로 서비스에 어떻게 매핑할 것인가.

마이크로 서비스에서는 하나의 서비스를 변경해서 다른 것과 독립적으로 배포할수 있기를 원한다. 책에서는 3가지 방법을 소개하는데 첫번째는 모든 마이크로 서비스를 위해 통으로 묶어 단일 저장소와 CI빌드를 사용하는 것. 두번째는 첫번째 방법의 변형으로 모든 코드를 포함하는 단일 소스 트리를 두고 다수의 CI빌드가 소스 트리의 부분들과 매핑되도록 하는 것. 즉 독립된 빌드와 매핑된 서브 디렉토리를 가진 단일 저장소가 있는 것이다. 세번째는 마이크로서비스당 하나의 코드 저장소와 CI빌드를 사용하는 것이다. 

지속적 배포(CD)

빌드 파이프라인이란 빌드 내에 여러 다른 단계를 두어 각 단계를 완료하면서 소프트웨어 과정을 추적하면서 품질을 높힐 수 있는 방법이다. 소프트웨어의 생산 경로 전체를 모델링함으로써 소프트웨어 품질의 가시성을 크게 향상시키고 개선할 주요 사안인 빌드 및 릴리즈 프로세스를 한 곳에서 볼 수 있다.

마이크로서비스 역시 CI와 마찬가지로 서비스 하나당 하나의 파이프라인을 갖을 필요가 있다.

산출물

루비의 gem 자바의 jar,war 파이선의 egg같은 산출물은 특정 기술 스택에 한정되어 있어 여러 기술이 혼용될 때 배포가 어렵기 때문에 운영체제에 네이티브한 산물물을 생성하는 것이 좋다. 장점으로는 배포의 관점에서 하부 기술에 신경 쓰지 않아도 되지만 처음 패키지를 생성할 떄 어려움이 있고 다른 운영 체제에 배포할 때 문제가 될 수 있다. 

커스텀이미지

자동화된 구성 관리 시스템은 머신 상에서 스크립트 실행 소요시간이 관건이다. 이를 줄이기 위한 한가지 방법은 공통적으로 의존하는 것들을 주입한 가상 머신 이미지를 만드는 것이다. 가상화 플랫폼을 이용하여 자체 이미지를 만들어 낸다면 배포시 이 커스텀 이미지의 인스턴스를 가동시킨 후 서비스의 최신 버전을 설치하기만 하면 된다. 이미지를 한 번만 빌드하기 때문에 이미지의 복제본을 연속 실행시킬 때 그것들을 설치하는 시간이 필요 없어 시간 절약에 도움이 된다. 단점으로는 이미지 자체의 생성 시간이 오래 걸릴 수 있고 생성된 이미지가 매우 클 수 있다. 이러한 단점을 회피할 수 있는 컨테이너 기술은 도커가 있다.

서비스와 환경구성과 호스트 매핑 

소프트웨어가 CD파이프라인 단계를 거치면서 다양한 종류의 환경에 배포되기 때문에 환경 구성이 종요하다. 환경마다 바뀌어야 하는 환경 구성은 전적으로 최소화 되어야 한다. 서비스의 환경마다 바뀌어야 하는 환경구성이 있다면 배포 프로세스의 일부로서 이를 어떻게 관리해야 할까? 먼저 환경당 하나의 산출물을 빌드하고 환경 구성을 그 산출물에 포함시킬 수 있는데 이는 실환경에서의 검증을 보장할 수 없으며 이 산출물들을 빌드하기 위해 추가시간이 소요되고 빌드시간에 어떤 환경이 존재야 하는지 알아야 한다. 민감한 환경구성 데이터를 어떻게 다룰 것인가도 문제다. 더 나은 방법으로는 단일 산출물을 생성하여 환경 구성을 분리해서 관리하는 것이다. 대규모 마이크로 서비스에서는 환경 구성을 제공하는 전용 시스템을 사용하는것이 바람직하다.

서비스를 설치하고 실행하는 운영 체제 단위인 호스트에 얼마나 많은 서비스르 넣을 것인지 생각해야 한다. 호스트당 다수의 서비스를 매핑하거나, 여러개로 분리된 서비스나 어플리케이션이 하나의 호스트 상의 어플리케이션 컨테이너에 상주하는 모델이 있다. 이는 자원 부족을 최적화 하기 위한 시도이다. 또한 호스트당 단일 서비스를 갖을 수 도 있다. 단일 호스트보다 더 높은 수준의 추상화 대상ㅇ에서 작업하는 서비스로서의 플랫폼이 있다.(PaaS) - ex 헤로쿠

자동화

자동화는 생산성을 유지할 수 있는 탁월한 비결이다. 개발자들에게 그들이 담당하는 개별 서비스 또는 서비스 그룹을 셀프 프로비저닝할 수 있어야 하고 자동화를 가능하게 하는 기술을 잘 선택해야 한다. 

많은 수의 호스트를 관리하는 데 사용하는 핵심 수단중 하나는 기존 물리 머신을 더 작은 부분으로 묶어야 하는데 VMWare이나 AWS와 같은 전통적인 가상화는 호스트 관리의 부담을 줄이는 데 엄청난 해택을 주었지만 주목해야할 새로운 기술은 베이그런트와 리눅스컨테이너, 도커이다.

배포인터페이스 

우리의 산출물과 하부 플랫폼이 무엇이든 간에 특정 서비스를 배포하는데 일관된 인터페이스를 유지하는 것이 필수이다. 어떤 배포도 실행시킬 수 있는 가장 타당한 방법은 매개 변수 전달이 가능한 한 줄의 명령행이다. CI도구로 실행되는 스크립트로 또는 직접 입력하여 시작할 수 있다. 책에서 스크립트를 제공한다.

접합부 

접합부란 코드베이스의 나머지 부분에 영향을 주지 않는 격리된 코드 부분 

경계가 있는 콘텍스트는 훌륭한 접합부를 만든다

분해하기 : 접합부 주변으로 코드베이스의 구조 변경 

경계가 있는 콘텍스트 인식

콘텍스트들을 대표하는 패키지 생성 후 코드 이동 

이 과정에서 패키지 간의 의존성을 분석할 수 있는 코드 사용 가능 

경계가 있는 콘텍스트를 대표하는 패키지들은 실세계 에서 도메인과 같은 방식으로 상호작용해야 한다 

조금씩 깍아내듯이 점진적으로 분리해야한다.

코드베이스를 분리했을 때 가장 큰 혜택이 있는 부분을 먼저 분리

문제에 대처

저장소 계층을 두고, 객체 또는 데이터 구조를 데이터베이스와 매핑하기 쉽게 만들어서 코드를 데이터베이스와 바인딩 하는 것. 

특정 콘텍스트의 코드 내에 데이터베이스 매핑 코드를 함께 배치하면 어떤 코드가 데이터베이스의 어느 부분을 사용하는지 이해할 수 있다. 

예) 외부 키 관계 꺠뜨리기, 공유 정적 데이터, 공유 데이터, 공유 테이블

데이터베이스 리팩토링

단일스키마에서 스키마를 분리 > 어플리케이이션을 서비스로 분리 

트렌잭션

데이터베이스를 분리할 경우 단일 트랜잭션에 의해 제공되는 안정성을 잃는다

나중에 재시도 하거나, 전체 작어을 중지하는 것 또는 분산 트렌젝션을 사용할 수는 있다.

그러나 이러한 솔루션들은 복잡성을 증가시킨다.

리포팅 

데이터 저장 방법과 장소를 분리하는 것은 리포팅에 문제가 될 수 있지만 기존 프로세스와 협업 방식을 정하는 것은 의미가 있고 집중해야할 대상을 하나

씩 정해야 한다. 서비스 호출을 통한 데이터 추출, API를 통한 데이터 추출. BUT 대용량일 겨우 실패 

이벤트 데이터 펌프

개체의 상태가 변경될 떄 이벤트를 발생하고 리포팅 데이터베이스로 데이터를 밀어 넣는 자체의 이벤트 구독자를 작성할 수 있다.

당점은 필요한 모든 정보를 이벤트로 확산해야 한다. 

#필요에 따라 데이터를 다양한 장소로 라우팅할 수 있는 포괄적인 이벤트 시스템

#변경비용을 고려하면 가장 영향도가 낮은 실수부터 시도

#드러난 서비스 경계에 따라 접합부를 찾아서 시스템을 점진적인 방법으로 분해. 이 접합부의 발견에 능숙해지고 처음부터 서비스 분리의 비용을 줄이도록 작업하면서 어떠한 신규 요구 사항도 만족하도록 시스템을 계속 성장시켜야함,

이상적인 통합 기술 모색

호환성을 깨뜨리는 변경 피하기, 기술 중립적인 API생성, 소비자를 위한 서비스 단순화, 내부 구현 상세 감추기

공유 데이터베이스

데이터베이스 통합은 서비스 들이 쉽게 데이터를 공유하지만 어떠한 행동양식도 공유하지 못한다. 서비스의 내부 표현이 네트워크를 통해 소비자에게 노출되면 호환성을 깨뜨리는 변경을 회피하게 매우 어려워지며, 필연적으로 모든 변경에 대한 두려움으로 이어진다.

동기와 비동기

동기 - 유지 / 비동기 - 클라이언트와 서버간의 접속 유지가 어려운 경우, 결과를 기다리는 동안 중단된 호출이 성능 저하를 일으키는 곳에서 짧은 지연시간이 필요할 때 

요청,응답 / 이벤트 기반 - 본질상 비동기적이며 결합도가 낮은 방식 

오케스트레이션과 코레오그래피

오케스트레이션 - 중앙 의존 / 코레오그래피 - 이벤트 구독 후 적절히 행동. 느슨한 결합 but 시스템 경계를 넘어 프로세스 모니터링 작업 필요. 

원격 프로시저 호출

이벤트 기반 시스템은 본질상 비동기적이며.  지능이 고르게 분산되어 있다. 비즈니스 로직이 핵심 두뇌로 집중화되기보다는 다양한 협업자들에 고르게 분배된다. 기술 결합, 지역 호출은 원격 호출과 다르다, 취성, RPC는 형편없는가 

REST

REST 와 HTTP, 애플리케이션 상태 엔진으로서의 하이퍼미디어, JSON XML 또는 다른 것, 지나친 평의를 주의하라, HTTP기반 REST단점  

비동기 이벤트 기반의 협업 구현 

기술선택, 비동기 아키텍처의 복잡성 

장점을 극대화하고 잠재적인 단점을 회피할 수 있는 마이크로서비스의 경계에 대해 생각해보는 장이다. 그러기 위해서는 작업할 대상이 먼저 필요하다.

뮤직코퍼레이션 

     좋은 사례를 통해 마이크로서비스의 개념이 어떻게 현실 세계에서 작용하는지 살펴보자. 뮤직코퍼레이션은 가능한 한 쉽게 변하는      것에 기회가 있다고 판단했다. 그 성공의 열쇠가 마이크로 서비스다.  

무엇이 좋은 서비스를 만든가?

느슨한 결합 : 마이크로서비스의 요점은 시스템의 그 어떤 부분도 추가 변경할 필요 없이 특정 서비스를 변경하고 배포할 수 있다는 것. 강한 결합을 일으키는 요인은 서비스를 서로 강하게 엮는 통합 방식을 택하는 것이다. 

강한 응집력 : 특정 행위를 변경하고자 할 땐느 한 곳에서 변경하고 가능한 한 신속하게 릴리즈할 수 있어야 한다. 서로 연관된 행위가 한 곳에 모이고, 다른 경계와는 가능한 한 느슨하게 소통할 수 있도록 우리 문제 영역내에서 경계를 찾고자 한다.

경계가 있는 콘텍스트

실제세상의 도메인을 모델링하는 시스템 구축 방법. 모든 도메인은 다수의 경계가 있는 콘텍스트로 구성되며, 각 콘텍스트 내에는 외부와 통신할 필요가 없는 것뿐만 아니라 경계가 있는 다른 콘텍스트 외부와 공유되는 것이 함께 존재한다. 경계가 있는 모든 콘텍스트에는 명백한 인터페이스가 존재하며, 그것은 어떤 모델이 다른 콘텍스트와 공유될지 결정한다.  또다른 정의는 명료한 경계에 의해 강제된 구체적인 책임이다. 도메인은 운영 중인 전체 사업에 해당한다. 잘 와닿지 않음.. 

감춰진 공유 모델 : 두 경계가 있는 콘텍스트 간에 공유될 필요가 있는 모델이 있으며, 필요한 부분만 노출한다. 모든 것을 노출할 필요는 없다. 

모듈과 서비스 : 경계가 있는 콘텍스트여야 구성 요소의 경계 구분에 적합하다. 도메인에서 경계가 있는 콘텍스트들을 발견했다면 공유되고 감춰진 모델을 이용하여 그것들을 여러분 코드 내에서 몯듈로 모델링 하라. 

성급한 분해 : 소트워크스의 성급한 분해 사례. 서비스의 사용 사례들이 제각각 아주 미묘하게 달라지면서 서비스 경계에 대한 초기 견해가 옳지 않아 많은 비용을 치뤄야 했다. 여러모로 기존 보드베이스를 마이크로 서비스로 분해하는 것이 처음부터 마이크로서비스로 가는 것보다 훨씬 쉽다고 한다.

비지니스 능력

경계가 있는 콘텍스트에 관해 고민할 때는 공유 데이터 관점이 아닌 나머지 도메인을 제공하는 콘텍스트의 능력 관점에서 봐야 한다. 이 콘텍스트는 무엇을 하는가와 그 일을 하기 위해 어떤 데이터가 필요한가? 를 뭔저 물어보라. 이들 능력이 서비스로 모델링될 떄 그것은 네트워크를 통해 다른 협업자(서비스)에 노출될 주요 행위가 된다.

거북이 밑에 거북이

마이크로서비스의 경계를 고려할 때는 우선 더 넓고 큰 단위의 콘텍스트 관점에서 생각한 뒤 접합부의 분리를 통한 해택을 발견했을 때 내포된 콘텍스트에 따라 세분화 하라. 완전 분리 방식과 내포 방식(조직구조기반 한 팀에 의해 관리할 경우)

비지니스 콘셉트 관점에서의 커뮤니케이션

비지니스 컨셉트의 관점 / 도메인 / 경계가 있는 콘텍스트 / 마이스코서비스의 경계 / 인터페이스

기술적 경계

서비스가 부정확하게 모델링되었을 때 사례. 

모놀리식 시스템 / 수직적인 비지니스에 초첨을 맞춰 스택을 나눈다 / 동작중인 API를 수평으로 나눈다 (기술 접합부에 따라 서비스 경계를 모델링) 

Mac iTerm scrollback line 늘리기

디폴트가 1000라인 뿐이라 서버별로 각각 들어가서 설정해줘야 한다. 

Preferences > Profiles > Profile Name 선택 > Termianl > Scrollback Buffer 설정