마이크로 서비스 패턴 -1 (모놀리식 지옥)

모놀리식의 장점

• 개발이 간단 : 단일 애플리케이션 구축에 초점
• 쉽게 변경 : 코드 db스키마 변경 빌드 배포 용이 (규모가 작을때 아닐까..?)
• 테스트 하기쉽다 : 이것도 규모가 작을때
• 배포 확장이 쉬움 -> 로드 밸런서를 이용해 인스턴스 여러개

모놀리식 지옥 실상

• 하지만 사이즈가 점점 커지면서 구현 스토리 늘어나고, 코드베이스 오버헤드 증가.
• 엄청나게 커진 애플리케이션.. 모놀리식 장점이 다 사라지고 있다?
• 개발도 느려짐 -> 어플이 너무 크니 실행속도 빌드 시간 오래걸림
• 테스트 도 느려진다

이 부분이 공감이 조금 갔다 현재 회사에서도 모놀리식인대 테스트 코드가 많다보니(API테스트)
아직은 오래걸리지 않으나 점점 오래 걸리고 있다. 또한 빌드 실행 속도도 조금 느린 편이긴하다

• 책에서는 지속적인 배포가 어렵다고한다 이건 왜지?

• 블루그린 이런 방식으로 배포하면되지않나?

• 확장하기 어려움 -> 각 도메인마다 요건이 맞지 않음 (인메모리 디비 필요한 부분, CPU처리가 높아야되는 부분등..)

• 전체 모듈이 같은 프로세스로 실행되 결함 격리가 되지않아 전체의 문제로 번짐.

• 기술스택 도입도 어려움.

• 전반적인 이런 내용.

블루그린 이런 방식으로 배포하면되지않나?

1 . 애플리케이션 크기와 복잡도: 모놀리식 애플리케이션은 대개 크고 복잡하기 때문에, 작은 변경 사항에도 전체 빌드와 배포가 필요합니다. 이는 배포 시간을 늘리고 실패 위험을 높음

2. 인프라 비용: 블루-그린 배포를 위해서는 추가 인프라가 필요한데, 모놀리식 애플리케이션의 경우 단일 유닛이므로 관련 인프라 전체를 복제해야 할 수 있습니다. 이는 상당한 비용 부담으로 작용

3. 데이터베이스 스키마 변경: 스키마 변경 시 테이블 락으로 인한 다운타임이 발생할 수 있고, 이를 해결하는 방법은 복잡성을 증가

• 아직까지 작은 프로젝트만해서그런가 3번은 중요한거 같다.

마이크로 서비스 아키텍처가 답이다?

• 마이크로서비스 아키텍처?
• 경계 컨텍스가 있는 느슨하게 결합된 엘리먼트 구성된 서비스 지향 아키텍처

X축 확장: 다중 인스턴스에 고루 요청 분산

• X축 확장은 동일한 애플리케이션의 여러 인스턴스를 실행하고 들어오는 요청을 이 인스턴스들에 고르게 분산시키는 방식

• 애플리케이션의 복제본을 여러 개 만들어 트래픽을 감당하는 것이 X축 확장의 핵심

• 부하 분산기(load balancer)는 X축 확장의 핵심 요소인데, 마치 식당에서 손님을 빈 테이블로 안내하는 점원과 같은 역할

• 모놀리식 애플리케이션의 확장 방법으로서 X축 확장이 갖는 의의를 부각시키고, 마이크로서비스 아키텍처와의 차이점을 암시하기 위해 이 내용을 언급 한 듯 ?

Z축 확장: 요청 속성별 라우팅

• Z축 확장은 애플리케이션의 여러 인스턴스를 실행하되, 각 인스턴스가 전체 데이터의 일부분만 처리하도록 하는 방식

• 예를 들어, 사용자 데이터를 다루는 애플리케이션이 있다고 가정 Z축 확장을 적용하면, 사용자 ID에 따라 요청을 분산시킬 수 있다. 즉, 특정 범위의 사용자 ID를 처리하는 전용 인스턴스를 여러 개 만드는 것

• 각 인스턴스는 자신이 담당하는 사용자의 데이터만 처리하면 되므로, 데이터량이 늘어나도 효과적으로 대응

• 이 때 라우터(router)는 트래픽 경찰과 같은 역할. 들어오는 요청의 속성(예: 사용자 ID)을 확인하고, 해당 요청을 처리할 적합한 인스턴스로 요청을 보내주는 것

• Z축 확장을 파이 나누기에 비유한 이유는 데이터를 분할하여 처리한다는 특징을 강조하기 위해서

• Z축 확장이 트랜잭션과 데이터 볼륨 증가에 효과적으로 대처할 수 있는 이유를 언급함으로써, 이 방식의 장점과 활용 시나리오를 명확히 하고자 함 이는 모놀리식 애플리케이션의 확장성 문제를 해결하기 위한 한 가지 방안으로서 Z축 확장의 의의를 부각시키려는 의도

• Z축 확장이 트랜잭션과 데이터 볼륨 증가에 효과적으로 대처할 수 있다는 말은, 애플리케이션이 처리해야 하는 요청(트랜잭션)의 수가 늘어나고 다뤄야 할 데이터의 양이 증가하는 상황에서 Z축 확장이 유용하다는 의미

• 예를 들어, 사용자 데이터를 다루는 애플리케이션에 Z축 확장을 적용했다고 가정. 사용자 수가 크게 증가하더라도, 각 인스턴스는 자신이 담당하는 사용자의 데이터만 처리하면 되므로 부하가 분산됨 이는 트랜잭션 처리 속도를 유지하고, 응답 시간을 안정적으로 유지하는 데 도움

Y축 확장: 기능에 따라 애플리케이션을 서비스로 분해

• Y축 확장은 모놀리식 애플리케이션을 기능에 따라 여러 개의 작은 서비스로 분해하는 것
• 마치 큰 조직을 기능별로 여러 부서로 나누는 것
• Y축 확장의 핵심은 각 서비스가 집중된 책임을 갖는다는 것 이는 각 부서가 명확한 업무 분장을 갖는 것과 같다.
• 서비스의 집중된 책임을 강조한 것은, 이것이 마이크로서비스 아키텍처의 핵심 원칙 중 하나
• 이를 통해 모놀리식 애플리케이션을 마이크로서비스로 전환할 때 고려해야 할 중요한 포인트를 부각

• y축 확장 결과

  마이크로 서비스는 모듈성을 갖고 있따.

• 크고 복잡한 애플리케이션은 한 사람이 이해하기 어려움

• 여러 모듈단위로 분해해 각 서비스는 api라는 경계선을 가짐

• 사이즈가 작아지니 유지하기 훨씬 쉬워짐

  서비스마다 db가 따로 있다.

• 키텍처에서 각 서비스가 자체 데이터베이스를 갖는다는 것은, 마치 각 부서가 자체적인 문서 보관 시스템을 갖는 것과 비슷

• 마이크로 서비스는 느슨한 결합으로 api 통해서만 통신.

• 각각 디비를 가지고 있다는 말은 서로 다른테이블을 쓴다는 의미?

• 각 서비스가 자체 데이터베이스를 가진다는 것은 논리적인 분리를 의미?. 물리적으로는 여러 서비스가 하나의 데이터베이스 서버를 공유할 수도 있다

  추가

• 마이크로서비스 애플리케이션은 대개 가벼운 오픈 소스 기술을 사용하며, 메시지 브로커(message broker, 중계기)나 REST 또는 gRPC처럼 가벼운 프로토콜 위주의 덤 파이프(dumb pipe)를 통해 서비스 간 통신

  마이크로 서비스 장점

• 크고 복잡한 애플리케이션 지속 전달 배포

• 규모 작아 관리쉽고

• 서비스 독립적 배포/확장

• 각 팀이 자율적으로 움직임

• 결함 격리 잘됨

• 새로운 기술 도입쉬움!

• 뭐 당연한 얘기?

• 작으니 테스트 하기 쉽고

• 독립적으로 배포하니 변경분 반영 쉽고

• 결합이 느슨하니 여러 팀으로 나눌수도 있고 신속히 대응가능..

  단점

• 딱 맞는 서비스 찾기힘듬 -> 보통 큰 회사에서 하는 거 같다 왠만한 기업은 모놀리식으로 가는거 같다

• 또 복잡하기 때문에 개발 테스트 배포 어려움 (분산 시스템)

• 언제 도입해야될지도 어렵고

• 여러 서비스에 걸친 기능 배포 잘 조정

  마이크로서비스 아키텍쳐도 만병 통치약은아님

• 생산성 10배 늘려주는 기법 기술은 없음

• 정답은 없다 동기vs 비동기 , 객체지향 vs 함수형 등..

  소프트웨어 개발 커뮤니티에 속한 사람들은 자신의 감정을 극복한 상태에서 기술을 논할 방법을 강구해야 합니다. 그것이 바로 패턴 포맷(pattern format)으로 기술(technology)을 객관적으로 기술(describe)하는 것입니다. 기술을 패턴 포맷으로 나타내면 자연히 그 단점도 드러나게 됩니다.

• 소프트웨어 개발자들이 새로운 기술이나 방법론에 대해 토론할 때, 감정적인 판단을 배제하고 객관적으로 접근해야 한다

• '패턴 포맷'을 활용할 것을 제안합니다. 패턴 포맷이란 소프트웨어 설계 패턴을 문서화하는 표준화된 방식으로, 주로 문제(Problem), 해법(Solution), 결과(Consequence) 등의 구성 요소를 포함

• 기술을 패턴 포맷으로 기술하면, 그 기술이 어떤 문제를 해결하는지, 어떤 방식으로 해결하는지, 그리고 그에 따른 결과와 트레이드오프는 무엇인지 객관적으로 파악할 수 있다.

• 패턴 포맷이 기술을 객관적으로 바라보는 데 어떻게 도움이 되는지 간략히 설명함으로써, 저자의 제안이 가진 실용성을 강조

  책에서 나온 전략 패턴

  전략 패턴(Strategy Pattern)은 알고리즘 군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든 디자인 패턴입니다. 전략 패턴을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있습니다.

• 마치 게임에서 무기를 교체하듯이, 상황에 따라 알고리즘을 유연하게 바꿔 사용

  상용 패턴의 구조

• 상용 패턴(Commercialization Pattern)은 실제 업무에 적용할 수 있도록 추상적인 해법을 구체화한 것

• 일반적인 설계 패턴을 실제 시스템에 적용할 때 고려해야 할 현실적인 제약 조건과 요구사항을 반영한 패턴

• 쉽게 말해, 상용 패턴은 추상적인 설계 원칙을 실제 업무에 적용할 때 필요한 구체적인 가이드라인. 마치 요리책에서 요리 이론을 설명한 후, 실제 레시피를 제공하는 것과 비슷

  강제조항

• 강제 조항은 문제를 해결하기 위해 반드시 고려해야 할 사항들을 의미

• 마치 여행 계획을 세울 때, 반드시 고려해야 할 요소들(예산, 일정, 동행자 등)을 리스트업

• 소프트웨어 개발에서는 코드의 가독성, 성능, 유지보수성 등 다양한 측면을 고려해야 함

• 리액티브 프로그래밍 스타일로 작성한 코드를 예로 들었는데, 이는 성능 면에서는 우수하지만 개발자가 이해하기는 상대적으로 어려울 수 있다는 것

• 강제 조항을 명시적으로 나열하고 우선순위를 정하는 것이 중요합니다. 이를 통해 주어진 상황에서 가장 중요한 문제가 무엇인지 명확히 파악하고, 해결 방안을 모색

  결과 맥락

• 결과 맥락은 디자인 패턴을 적용한 후 나타나는 결과를 객관적으로 평가하는 영역

• 패턴 적용의 장단점과 새로운 문제점을 포함

  약의 부작용 확인에 비유할 수 있습니다. 새로운 약을 개발했을 때, 그 약의 효능(장점)과 함께 부작용(단점)을 반드시 확인해야 합니다. 또한 약을 복용한 후 예상치 못한 새로운 증상(이슈)이 나타나는지도 주의 깊게 관찰해야 합니다. 이런 전반적인 평가를 통해 약의 실제 효용성을 판단

• 마찬가지로 디자인 패턴을 적용한 후에는 의도한 문제가 해결되었는지(장점), 다른 문제가 발생하지는 않았는지(단점), 예상하지 못한 새로운 문제는 없는지(이슈) 종합적으로 분석해야 한다.

• 약의 효능만 보고 부작용은 간과하면 위험할 수 있듯이, 디자인 패턴의 장점만 보고 단점과 새로운 문제점은 간과하면 설계의 질을 저하시킬 수 있다

  연관 패턴: 다섯 가지 관계 유형

  연관 패턴: 다섯 가지 관계 유형

  

  선행자 패턴

• 이 패턴을 필요하게 만든 선행 패턴. 가령 마이크로서비스 아키텍처 패턴은 모놀리식 아키텍처 패턴을 제외한 나머지 패턴들의 선행자입니다.

  선행자 패턴은 출발점과 같습니다. 이 패턴이 있어야 다른 패턴들로 나아갈 수 있습니다. 후행자 패턴은 목적지와 같습니다. 현재 패턴에서 출발하여 후행자 패턴으로 가야 완전한 여정이 됩니다.

  대안 패턴

• 이 패턴의 대체 솔루션을 제공하는 패턴. 가령 모놀리식 아키텍처 패턴과 마이크로서비스 아키텍처 패턴은 서로를 대신할 수 있는 애플리케이션 아키텍처링 수단 둘 중 하나 선택

  대안 패턴은 같은 목적지로 가는 다른 경로와 같습니다. 교통 상황이나 개인 선호도에 따라 다른 경로를 선택할 수 있듯이, 상황에 따라 더 적합한 패턴을 선택할 수 있습니다.

  일반화

• 문제를 해결하는 일반적인 솔루션에 해당하는 패턴

  일반화 패턴은 고속도로와 같습니다. 광범위하고 일반적인 솔루션을 제공합니다.

  세분화

  세분화 패턴은 고속도로에서 갈라져 나온 작은 길과 같습니다. 특정 목적지에 더 빠르고 정확하게 도달할 수 있습니다.

  마이크로서비스 아키텍처 패턴 언어

  마이크로서비스 아키텍처 패턴 언어는 마치 레고 블록 세트와 같다고 볼 수 있습니다. 레고 블록 세트에는 다양한 모양과 크기의 블록들이 포함되어 있어, 이를 조합하여 원하는 구조물을 만들 수 있습니다.

• 마이크로서비스 아키텍처 패턴 언어는 전체 애플리케이션을 마이크로서비스 아키텍처로 구성할 때 유용한 패턴의 모음집

• 패턴 언어는 모놀리식 아키텍처 및 마이크로서비스 아키텍처의 구조와 장단점을 기술하기 때문에 무엇보다 마이크로서비스 아키텍처를 사용하는 것이 옳은 일인지 결정할 때 요긴

• 각각의 패턴은 마이크로서비스 아키텍처를 구축하는 데 필요한 특정 문제를 해결하는 방법을 제공

• 개발자는 이 패턴들을 선택하고 조합하여 자신의 애플리케이션에 가장 적합한 아키텍처를 설계

  

애플리케이션 아키텍처 패턴

• 전체 애플리케이션의 구조를 결정하는 데 도움

• 마치 레고 구조물의 전체적인 모양을 결정하는 큰 블록

  솔루션 패턴

• 마이크로서비스 아키텍처를 구현하는 과정에서 발생하는 다양한 문제들을 해결하는 방법을 제공합니다. 이는 레고 구조물의 세부 디테일을 추가하는 작은 블록들과 같다

  솔루션 패턴은 다시 인프라 패턴, 애플리케이션 인프라 패턴, 애플리케이션 패턴으로 분류됩니다. 이는 마치 레고 블록을 색깔이나 모양에 따라 분류하는 것과 유사합니다. 이런 분류는 개발자가 특정 문제를 해결하는 데 필요한 패턴을 쉽게 찾을 수 있도록 도와줍니다.

• 인프라 패턴 : 주로 개발 영역 밖 인프라 문제해결

• 애플리케이션 인프라 : 개발에도 영향을 미치는 문제 해결

• 애플리케이션 패턴 - 개발자가 맞닥뜨리는 문제 해결