1. 비지니스 민첩성

1) 인터넷 기업들의 비지니스 민첩성

Amazon 이나 Netflix, Uber 같은 기업들은 익숙한 비지니스에 새로운 비지니스 기술을 융합해 자신만의 특화된 서비스를 제공
자신만의 특화된 서비스를 제공하려는 시도를 빨리 실행했고 사용자 피드백을 반영해 끊임없이 서비스를 개선
이런 기업들의 가장 큰 장점은 비지니스 민첩성(Agility)이며 이것이 기업 성공의 가장 큰 요인
Amazon의 배포 속도
- 2011년에 11.6 초마다 아마존 쇼핑몰의 소스 코드가 변경되어 배포된다고 발표
- 2019년에는 이 주기가 초당 1.5번
비지니스는 계속 변경이 되고 이로 인해서 개선된 시스템도 계속 배포가 되어야 함
- 기업은 새로운 아이디어를 시스템에 반영해 적시에 오픈하고 그 반응을 살펴보고자 하고 기존 서비스를 보완하는 부가 서비스가 필요한 시점
- 새로운 서비스를 공개했지만 반응이 좋지 않아 이를 개선해야 할 때
- ==> 시스템을 빠르게 변경해서 배포해야 하므로 빠른 배포 주기는 비지니스 민첩성을 간접적으로 보여주는 지표
Public Cloud 인프라의 등장: 기존의 On Premise 환경에서는 인프라를 준비하는 시간이 오래 걸리고 별도의 조직도 운영해야 했는 Public Cloud 의 등장으로 시간이나 비용이 단축

2)Scale Up 과 Scale Out

성능 및 가용성을 높이는 방법
Scale Up(수직 확장): 하드웨어의 성능을 높이는 것
Scale Out(수평 확장): 하드웨어 개수를 늘리는 것
쇼핑몰을 운영하는 도중에 타임세일 기간에 밀려올 트래픽을 대비하고자 용량을 늘리고자 하는 경우
- 스케일 업 작업은 전체 트래픽 최대치를 계산해서 대용량 처리가 가능한 시스템으로 업그레이드를 할 수 있음
- 확장 탄력성을 보장하는 스케일 아웃 작업을 수행: 인스턴스를 늘리는 것
특정 서비스만 탄력성 있게 확장
- 애플리케이션을 개발할 때 레고 블록 처럼 여러 개의 조각으로 분리해서 개발했다면 특정 모듈만 스케일 아웃이 가능

3)Cloud Friendly 와 Cloud Native

Cloud Friendly: 작은 단위의 서비스 연계로 시스템을 구성하지 않고 전체 시스템을 하나의 덩어리로 만들어 Cloud 플랫폼에 올려도 된다.
- 하나로 묶으면 Cloud 플랫폼에 배포할 때 편리
- 모노리스 형태의 서비스
Cloud Native: 독립적으로 분리되어 배포할 수 있는 조각으로 구성된 애플리케이션을 Cloud 인프라에 가장 어울리고 효과적이라는 의미로 Cloud Native Application 이라 부르며 궁극적으로 Cloud Friendly -> Cloud Native로 전이해야 한다고 함
- 마이크로 서비스 형태

4)Monolithic 과 Micro Service

Monolithic

하나의 단위로 개발되는 일체식 애플리케이션
3 Tier로 개발: 사용자 인터페이스(클라이언트), 데이터베이스 그리고 서버쪽 애플리케이션
서버측 애플리케이션이 논리적인 단일체로서 아무리 작은 변화에도 새로운 버전으로 전체를 빌드해서 배포해야 하고 일체식 애플리케이션은 단일 프로세스에서 실행되기 때문에 확장이 필요한 경우 특정 기능만 확장할 수 없고 반드시 전체 애플리케이션을 동시에 확장해야 하는데 보통은 로드밸런서를 앞에 두고 여러 인스턴스 위에 큰 덩어리를 복제해서 수평으로 확장
변경이 발생하면 Monolithic 시스템의 단점이 극대화되는데 수평으로 확장된 형태이기 때문에 여러 개 시스템 모두를 전부 다시 빌드하고 배포를 해야 합니다.
데이터베이스가 통합되어 하나이므로 탄력적으로 대응할 수 가 없음

Micro Service

서버 측을 여러 개의 조각으로 구성
각 서비스가 별개의 인스턴스로 로딩되며 각기 저장소가 다르기 때문에 모듈의 경계를 명확하게 구분
각 서비스가 독립적이어서 서로 다른 언어로 개발하는 것도 가능하며 각 서비스의 소유권을 분리해서 서로 다른 팀이 개발 및 운영할 수 있음

5)SOA 과 Micro Service

소프트웨어 공학에서 말하는 모듈화 개념의 발전 흐름을 보면 단순히 기능을 하향식 분해해서 설계해 나가는 구조적 방법론부터 시작해서 객체 지향 방법론으로 넘어간 후
기능 별로 재사용 가능한 컴포넌트 단위의 개발 방법론(CBD - Component Based Development)으로 진화한 후
컴포넌트 들을 모아서 비지니스 적으로 의미있고 완결적인 서비스 단위로 모듈화하는 것이 Service Oriented Architecture
CBD 나 SOA도 넓게 보면 Micro Service
SOA는 일반적으로 이론적인 개념이고 Micro Service는 구체화된 사례

Micro Service의 조건
- 여러 개의 작은 서비스의 집합으로 개발
- 각 서비스는 개별 프로세스에서 실행되고 HTTP 자원 API 같은 가벼운 수단을 사용해서 통신
- 서비스는 비지니스 기능 단위로 구성되고 자동화된 배포 방식을 사용
- 중앙 집중적인 관리는 최소화하고 각 서비스는 다른 언어 와 데이터 저장 기술을 사용할 수 있음

하나의 서비스를 구현하는데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방법을 Polyglot 하다라고 표현합니다.

6)Micro Service를 위한 조건

업무 기능 중심 팀으로 조직을 변화

예전에는 기술 별(UI, Server, Data 등)로 팀을 나누고 그 팀이 의사소통을 해가면 개발
마이크로 서비스를 구현하는 팀은 업무 기능 중심의 팀이어야 하는데 이 팀은 역할 또는 기술별로 팀이 분리되는 것이 아니고 업무 기능을 중심으로 기술이 다양한 사람들이 하나의 팀이 되어 서비스를 만드는 것
팀원들이 같은 공간, 같은 시간을 공유하기 때문에 의사 소통도 원할하고 의사 결정도 빠르게 진행할 수 있음
팀의 크기를 보통 피자 두판을 나누어 먹을 수 있는 정도로 구성: two pizza team

관리체계의 변화
- 자율적인 분권 서비스: 팀이 개발 과 운영 모두 책임지며 중앙의 강력한 거버넌스를 추구하지 않음
- 폴리글랏
개발 수명 주기의 변화 : 프로젝트가 아니라 제품 중심
- 비니지스를 제공하는 제품으로 소프트웨어를 바라보고 개발한 뒤에 반응을 보고 개선하는 방식으로 진행

개발 환경의 변화 : 인프라 자동화
저장소의 변화

Monolithic 시스템은 통합 데이터베이스를 사용
- 데이터의 안정성 과 효율성을 추구한 결과로 잘 정리하는 정규화가 반드시 추구해야 할 가치였지만 지금은 스토리지 가격이 저렴하고 네트워크 대역폭이 매우 커져서 데이터를 억지로 뭉쳐서 작은 공간에 넣을 필요가 없음
폴리글랏 저장소 접근법을 선택하고 서비스 별로 데이터베이스를 갖도록 설계
- 각 저장소가 서비스 별로 분산되어야 하며 다른 서비스의 저장소를 직접 호출할 수 없고 API를 통해서만 접근
이러한 구조에서는 비지니스 처리를 위해 일부 데이터의 복제 와 중복 허용이 필요한데 여기서 반드시 등장하는 문제가 있는데 Micro Service 저장소에 담긴 데이터의 비지니스 정합성(무결성)을 맞춰야 하는 데이터 일관성 문제
데이터 일관성 처리를 위해서는 보통 2단계 커밋 같은 분산 트랜잭션 기법을 사용
- 각각 다른 서비스를 하나의 트랜잭션으로 묶다 보면 각 서비스의 독립성도 침해
- NoSQL 같은 경우는 2단계 커밋을 지원하지 않기 때문에 MicroService 에서 데이터 일관성 문제를 해결하기 위해서는 단일 트랜잭션으로 묶는 방법이 아니라 비동기 이벤트 처리를 통합 협업을 강조
- -->결과적 일관성이라는 개념으로 표현하는데 이 개념은 일시적으로 불일치하는 시점이 있지만 결과적으로는 일치해진다.

위기 대응 방식의 변화: 실패를 고려한 설계
- 넷플릭스에서는 chaos monkey 라는 일부러 장애를 발생시키는 도구를 만들어서 위기에 어떻게 대처하고 있는지 점검

MSA 에 대한 이해

1)Reactive 선언

2014년에 현대 애플리케이션이 가져야 하는 바람직한 속성들에 대한 선언으로 Responsive(응답성), Resilient(탄력성), Elastic(유연성), Message Driven(메시지 기반)을 강조
응답성: 사용자에게 신뢰성있는 응답을 빠르고 적절하게 제공하는 것
탄력성: 장애가 발생하거나 부분적으로 고장이 나더라도 시스템 전체가 고장나지 않고 빠르게 복구하는 능력 - 단일 장애점을 만들면 안된다.
유연성: 시스템의 사용량에 변화가 있더라도 균일한 응답성을 제공하고 시스템 사용량에 따라 자원을 늘리거나 줄이는 능력
메시지 기반: 비동기 메시지 전달을 통해 위치 투명성, 느슨한 결합, 논블로킹 통신을 지양

2)강결합에서 느슨한 결합의 아키텍쳐 변화

특정 벤더에 종속되지 않도록 개발
- 특정 벤더에 종속되면 특정 기술에 Lock-In이 되어 쉽게 변경하거나 확장하지 못하다는 단점이 있음
최근의 클라우드 관련된 기술들은 오픈소스 기반이 많은데 이 제품들이 유명 벤더의 제품군 만큼이나 품질이 높아졌고 다양 기능을 지원하고 서로 다른 오픈 소스 제품 간에도 충분한 호환성을 제공하므로 특정 벤더의 제품 보다는 오픈 소스를 사용하는 것을 권장

3) 구성 요소

인프라 구성 요소

Public Cloud & Private Cloud
VM(운영체제 가상화 - 쉬움) & Container(데이터 와 코드의 가상화: 이식성, 신속성, 재사용성에서 이점)
컨테이너 오케스트레이션
CaaS(Container as a Service):컨테이너 기반 가상화를 사용해서 컨테이너를 업로드하고 구성할 수 있는 서비스

AWS의 ECS, EKS, MS의 AKS, Google의 GKE, Kakao의 DKOS 등의 서비스

플랫폼 구성 요소: DevOps 인프라 구성

서비스 단일 진입을 위한 API 게이트웨이 패턴
BFF(Backend for Frontend): API 게이트웨이 와 같이 진입점을 하나로 두지 말고 Frontend의 유형에 따라 별도로 두는 패턴
외부 구성 저장소 패턴: 데이터베이스 접속 정보 같은 애플리케이션을 구동하는데 필요한 정보 중에서 시작할 때만 필요하고 나중에는 필요하지 않은 정보들은 별도의 저장소에 관리
인증(Authentication - 로그인)/인가(Authorization - 권한) 패턴
- 중앙 집중식 세션 관리: 모놀리식에서 사용했던 방식은 서버 세션에 사용자의 로그인 정보 및 권한 정보를 저장하고 이를 통해서 애플리케이션의 인증/인가를 판단하는 방식인데 이 방식은 MicroService에 사용하기는 어려운 방식
  - 모든 서비스가 동일한 사용자 데이터를 사용하기 위해서 데이터베이스(속도 때문에 메모리 데이터베이스 이용)를 이용
- 클라이언트 토큰: 세션은 중앙 서버에 저장되고 토큰은 사용자의 브라우저에 저장되는 방식으로 사용자의 신원 정보를 클라이언트에 저장한 후 서버로 요청을 보낼 때 전송하는 방식
  - 이 때 사용하는 토큰 형식이 JWT(JSON Web Token)
- API Gateway를 이용한 토큰 인증 방식
서킷 브레이커 패턴: 하나의 서비스에 장애가 발생했을 때 다른 정상적인 서비스로 요청을 변경하게 해주어서 장애가 다른 서비스에 영향을 주지 않도록 하는 패턴
모니터링 과 추적 패턴: 장애를 실시간으로 감지하고 모니터링하고 추적하는 패턴이 필요 - Spring Cloud에서는 히스트릭스라는 라이브러리 제공, 최근에는 ELK Stack을 많이 사용
중앙화된 로그 집계 패턴: ELK Stack 과 Kafka(다양한 데이터 소스로부터 데이터를 수집하는 용도로 사용) 사용을 권장

E(Elastic Search - 분석 엔진)L(Logstash - 로그 집합기)K(Kibana - 시각화 도구)
- 여러가지 패턴들이 있는데 이를 한꺼번에 해결하기 위한 솔루션들이 등장했는데 Kubernetes 나 OpenShift 등 입니다.
- 최근에는 Kubernetes + Istio 기술이 많이 사용

애플리케이션 패턴

Monolithic Front End: 여러 API를 호출하고 조합 한 후 화면으로 구성해서 보여주는 방식
UI Composite Pattern(Micro Front End): 메인 화면을 여러 조각으로 나누고 각 조각은 여러 개의 Micro Front End 의 조합으로 서비스
통신 방식은 동기(송신자 와 수신자가 직접 통신) 와 비동기 방식(생산자 와 소비자로 구분해서 통신 - 구독 과 게시) 모두 사용

비동기로 하는 경우 직접 구현할 것인지 Public Cloud의 완전 관리형 메신저 서비스를 사용할 것인지 결정

저장소 분리 패턴
분산 트랜잭션 처리 패턴
읽기 와 쓰기 분리: CQRS(Command Query REsponsibility Segregation) 패턴

LIST