20. Microservice Architecture

Traditional Monolithic Design

Monolithic Architecture and its Problems

• Monolithic Architecture: Popular in Web Applications
  • Usually all-in-one in the Web Application Server
    • UI, DB, Logic/App
  • One build and deployment unit, One code base, and One technology stack (Linux, JVM, Tomcat, Libraries)
• Pros
  • Easy to develop (simple structure)
  • (Partially) Easy to scale (replication)
• Cons
  • Changes made to a small part of the application requires the entire monolithic to be rebuilt and deployed

Layered Systems and its Problems

• A layered system decomposes a monolith into layers
  • Usually: presentation, logic, data access
  • At most one technology stack per layer
    • Presentation: Linux, JVM, Tomcat, Libs, EJB client, JavaScript
    • Logic: Linux, JVM, EJB container, Libs
    • Data Access: Linux, JVM, EJB JPA, EJB container, Libs
• Pros
  • Limited Dependency
• Cons
  • huge codebases
  • Scaling works better, but still limited
  • Communication between teams is biased by layer experience
    계층별 경험에 따라 팀 간 의사소통이 편향됨

A State Known as Fear Cycle

• Monolithic이 쉽고 편하고 간단하지만:
  1) The app has become so overwhelmingly complicated that no single person understands it.
  2) You fear making changes - each change has unintended and costly side effects.
  3) New features/fixes become tricky, time-consuming, and expensive to implement.
  4) Each release becomes as small as possible and requires a full deployment of the entire application.
  5) One unstable component can crash the entire system.
  6) New technologies and frameworks aren’t an option.
  7) It’s difficult to implement agile delivery methodologies.
  8) Finally, the consultants come in and tell you to rewrite it
  마침내 컨설턴트들이 들어와서 다시 쓰라고 합니다

Cloud Native

Cloud Native Definition by CNCF (Cloud Native Computing Foundation)

• Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.
  • Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
• These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
• Neflix has 600+ services in production. Deploy 100 times per day
• Uber has 1000+ services in production. Deploy several thousand times each week

The pillars(기둥) of cloud native

• The cloud and its underlying Service Model
• Modern Design Principles
• Microservices
• Containerization and Orchestration
• Automation including Infra as Code and code deployment
• Cloud based Backing Services such as DB and message brokers

Cloud Native: Summary

• Kubernetes is the hosting environment of choice for most cloud-native applications.
• Service communication becomes a significant design decision when constructing a cloud-native application.
  서비스 통신은 클라우드 네이티브 애플리케이션을 구축할 때 중요한 설계 결정이 됩니다.
  • Applications typically expose an API gateway to manage front-end client communication. Then backend microservices strive to communicate with each other implementing asynchronous communication patterns, when possible.
• gRPC is a modern, high-performance framework that evolves the age-old(오래된) remote procedure call (RPC) protocol.
• Distributed data is a model often implemented by cloud-native applications.
  • Each microservice encapsulates its own dependencies, data, and state. The classic shared database model evolves into one of many smaller databases, each aligning with a microservice.
    각각의 마이크로서비스는 독립적으로 종속성, 데이터, 그리고 상태를 캡슐화합니다. 전통적인 공유 데이터베이스 모델은 여러 작은 데이터베이스 중 하나와 일치하는 방식으로 진화합니다.
• No-SQL databases refer to high-performance, non-relational data stores.
• Resiliency(복원력) is the ability of your system to react to failure and still remain functional.
  복원력은 시스템이 장애에 대응하고 기능을 유지하는 기능입니다.
  • Cloud-native systems embrace distributed architecture where failure is inevitable. Applications must be constructed to respond elegantly to failure and quickly return to a fully functioning state
    애플리케이션은 실패에 우아하게 대응하고 빠르게 완전히 작동 상태로 복구할 수 있도록 구성되어야 합니다.
• Code automation is a requirement for cloud-native applications.
  • Modern CI/CD systems help fulfill this principle. They provide separate build and deployment steps that help ensure consistent and quality code. The build stage transforms the code into a binary artifact. The release stage picks up the binary artifact, applies external environment configuration, and deploys it to a specified environment. Azure DevOps and GitHub are full-featured DevOps environments.

Microservice Architecture

Service Oriented Architecture

Functional Decomposition

• SOA systems also focus on functional(기능적) decomposition(분해), but
  • Services are not required to be self-contained with data and UI, most of the time the contrary is pictured.
    서비스는 데이터와 UI를 통해 자체적으로 유지할 필요가 없으며, 대부분의 경우 그 반대의 상황이 묘사됩니다.
  • It is often thought as decomposition within tiers, and introducing another tier – the service orchestration tier
    흔히 계층 내 분해로 간주되며, 또 다른 계층인 서비스 조정 계층을 도입합니다

    SOA 시스템은 기능적 분해를 강조하지만, 서비스가 데이터와 UI를 스스로 포함할 필요는 없으며, 대부분의 경우 서비스는 다른 서비스나 외부 시스템과 상호작용하여 필요한 데이터와 UI를 가져옵니다.

• Microservices can be seen as “SOA – the good parts”
  • SOA is focused on enabling business-level programming through business processing engines and languages such as BPEL and BPMN
  • SOA does not focus on independent deployment units and its consequences

둘 다 서비스 중심의 아키텍처이지만, SOA가 여러 서비스를 하나의 단위로 배포하는 반면, 마이크로서비스는 각 서비스가 독립적으로 배포되고 확장될 수 있음을 의미한다.

MicroService

the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

단일 애플리케이션을 개발하는 접근 방식으로, 각각이 독립적인 프로세스에서 실행되며 경량 메커니즘을 통해 통신하는 소규모 서비스들의 모음으로 구성됩니다. 통신 방식은 대부분 HTTP 리소스 API를 사용합니다.

These services are built around business capabilities and independently deployable by fully automated deployment machinery.
"이러한 서비스들은 비즈니스 기능을 중심으로 구축되며, 완전히 자동화된 배포 시스템에 의해 독립적으로 배포될 수 있습니다

There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Underlying Principles of MSA

• The term “micro” refers to the sizing: a microservice must be manageable by a single development team (5-9 developers)
• Functional system decomposition means vertical slicing (in contrast to horizontal slicing through layers)
• Independent deployability implies no shared state and inter-process communication (often via HTTP REST-ish interfaces)

이 새로운 애플리케이션은 아래 다이어그램과 같은 모듈식 육각형 아키텍처를 가지게 됩니다:

애플리케이션의 핵심은 비즈니스 로직으로, 서비스, 도메인 객체, 이벤트를 정의하는 모듈에 의해 구현됩니다. 핵심을 둘러싼 부분에는 외부 세계와 인터페이스를 제공하는 어댑터가 있습니다. 어댑터의 예로는 데이터베이스 접근 컴포넌트, 메시지를 생성하고 소비하는 메시징 컴포넌트, API를 제공하거나 UI를 구현하는 웹 컴포넌트 등이 있습니다.

논리적으로 모듈화된 아키텍처를 가지고 있지만, 이 애플리케이션은 하나의 거대한 패키지로 배포되는 모놀리식입니다. 실제 형식은 애플리케이션의 언어와 프레임워크에 따라 다릅니다.

이런 스타일로 작성된 애플리케이션들은 매우 흔합니다. 우리의 IDE와 다른 도구들이 하나의 애플리케이션을 구축하는 데 중점을 두고 있기 때문에 개발하기 간단합니다. 또한 이런 종류의 애플리케이션들은 테스트하기도 쉽습니다.

https://www.nginx.com/blog/introduction-to-microservices/

많은 기업들, 예를 들어 아마존, 이베이, 넷플릭스 등은 이제 마이크로서비스 아키텍처 패턴으로 알려진 방법을 채택함으로써 이 문제를 해결했습니다. 거대하고 모놀리식의 단일 애플리케이션을 만들기보다는, 애플리케이션을 더 작고 상호 연결된 서비스들의 집합으로 분리하는 것이 핵심 아이디어입니다.

서비스는 일반적으로 주문 관리, 고객 관리 등과 같은 일련의 독특한 기능이나 기능성을 구현합니다. 각 마이크로서비스는 자체 비즈니스 로직과 다양한 어댑터를 포함하는 자체 육각형 아키텍처를 가진 미니 애플리케이션입니다. 일부 마이크로서비스는 다른 마이크로서비스나 애플리케이션의 클라이언트가 사용하는 API를 제공할 수 있습니다. 다른 마이크로서비스는 웹 UI를 구현할 수 있습니다. 런타임에서 각 인스턴스는 종종 클라우드 VM이나 도커 컨테이너입니다.

예를 들어, 앞서 설명한 시스템의 가능한 분해는 다음 다이어그램에서 보여주는 것과 같습니다:

애플리케이션의 각 기능 영역은 이제 자체 마이크로서비스에 의해 구현됩니다. 더불어, 웹 애플리케이션은 더 간단한 웹 애플리케이션들의 집합(예를 들어 택시 호출 예에서 승객용 하나와 운전자용 하나)으로 분리됩니다. 이렇게 하면 특정 사용자, 장치, 또는 특화된 사용 사례에 대해 독특한 경험을 배포하는 것이 더 쉬워집니다.

각 백엔드 서비스는 REST API를 노출하고 대부분의 서비스는 다른 서비스가 제공하는 API를 사용합니다. 예를 들어, 운전자 관리는 가능한 여행에 대해 사용 가능한 운전자에게 알리기 위해 알림 서버를 사용합니다. UI 서비스는 웹 페이지를 렌더링하기 위해 다른 서비스를 호출합니다. 서비스는 비동기 메시지 기반 통신을 사용할 수도 있습니다. 서비스 간 통신은 이 시리즈에서 뒤에 더 자세히 다루게 될 것입니다.

일부 REST API는 운전자와 승객이 사용하는 모바일 앱에도 노출됩니다. 그러나 앱은 백엔드 서비스에 직접 액세스할 수 없습니다. 대신, 통신은 API 게이트웨이라는 중개자에 의해 조정됩니다. API 게이트웨이는 로드 밸런싱, 캐싱, 접근 제어, API 계량, 모니터링 등의 작업을 담당하며, NGINX를 사용하여 효과적으로 구현할 수 있습니다.

Independent Deployability is key

• It enables separation and independent evolution of
  • code base
    • Each service has its own software repository
  • technology stacks
    • The technology stack can be selected to fit the task best
    • Teams can also experiment with new technologies within a single microservice
  • Scaling
    • Identified bottlenecks can be addressed directly
    • Data sharding can be applied to microservices as needed
    • Parts of the system that do not represent bottlenecks can remain simple and un-scaled
  • and features, too
    • Microservices can be extended without affecting other services
    • For example, you can deploy a new version of (a part of) the UI without re-deploying the whole system

Stable Interfaces – standardized communication

• Communication between microservices is often standardized using
  • HTTP(S) – battle-tested and broadly available transport protocol
  • REST – uniform interfaces on data as resources with known manipulation means
  • JSON – simple data representation format
• REST and JSON are convenient because they simplify interface evolution (more on this later)

Characteristics (Componentization via Services)

• Interaction mode: share-nothing, cross-process communication
• Independently deployable (with all the benefits)
• Explicit, REST-based public interface
• Sized and designed for replaceability(교체 가능성)
  • Upgrading technologies should not happen big-bang, all-or-nothing-style
• Downsides(단점)
  • Communication is more expensive than in-process
    마이크로서비스는 각 서비스가 독립적으로 실행되기 때문에, 서비스 간 통신은 네트워크를 통해 이루어져야 합니다. 이는 프로세스 내부에서의 통신보다 더 많은 시간과 리소스를 소비하게 됩니다.
  • Interfaces need to be coarse-grained
    마이크로서비스에서는 각 서비스가 독립적으로 개발되고 운영되기 때문에, 서비스 간 통신 인터페이스는 잘 정의되고, 변경이 쉽지 않아야 합니다
  • Re-allocation of responsibilities between services is harder
    한 서비스에서 다른 서비스로 책임을 이동시키는 것은 복잡하고 시간이 많이 소요될 수 있습니다
• Having to deploy significant number of services forces operations to automate the infrastructure for
  상당한 수의 서비스를 배포해야 하므로, 운영팀은 다음을 위한 인프라를 자동화해야 합니다
  • Deployment (Continuous Delivery)
  • Monitoring (Automated failure detection)
  • Managing (Automated failure recovery)
• Netflix uses Chaos Monkey to further enforce infrastructure resilience