ch11. 마이크로서비스 시작하기(MSA)

애플리케이션 개발 목표

오늘의 요구사항은 내일의 요구사항이 아니고, 오늘의 기술은 내일 사용할 기술이 아니다.  
기술과 비즈니스 환경은 끊임없이 변하고 있으며 계속해서 진화 중이다.  
애플리케이션이 이러한 변화에 얼마나 빨리 적응할 수 있는가?

1. 빠른 애플리케이션 구축 - 속도
2. 신뢰할 수 있는 애플리케이션 구축 - 안전 안전한 애플리케이션의 몇 가지 특성

• 신뢰성 - 애플리케이션이 예상대로 작동할까? - 정확하게 작동하는지
  • 기능 요구사항을 충족하였는가?
  • 얼마나 많은 결함이 발생하는가?
• 가용성 - 애플리케이션을 항상 사용할 수 있을까?
  • 24시간 내내 사용할 수 있어야 한다.
• 안전성 - 애플리케이션은 안전한가?
  • 인증, 권한과 데이터 보호에 대한 명확한 절차가 있어야 한다.
• 성능 - 애플리케이션이 충분히 빠른가?
  • 정해진 응답 시간을 보장하는 능력
• 높은 복원력 - 실패에 잘 반응할까?
  • 오류가 발생하는 경우 복원을 해주어야 한다.
• 확장성 - 애플리케이션 로딩이 급격히 증가할 때 무엇을 지원해야 할까?
  • 확장성이란 리소스를 확장할 때 애플리케이션이 어떻게 반응하는지 측정하는 것을 말한다.
  • 클라우드 세계에서는 확장성이 더욱 중요해지고 있다.

모놀리식 애플리케이션 문제

모놀리식이란 코드가 많은 애플리케이션, 10만 줄이 넘는 코드 라고 볼 수 있다.
모놀리식 특징

• 큰 크기 : 대부분의 모놀리식 애플리케이션에는 코드베이스가 많다.
• 대규모 팀 : 팀규모는 20명에서 300명까지 다양
• 같은 일을 하는 여러 가지 방법 : 팀 규모가 큰 탓에 의사소통에 차이가 있다.
• 자동화 테스트 부족 : 대부분의 애플리케이션에는 단위테스트가 거의 없으며, 통합테스트가 완벽하지 않다.

• 릴리스 업데이트의 문제 - 긴 릴리즈 주기
  • 모놀리식에서 한 부분의 코드를 변경하면 다른 부분에 영향을 줄 수 있다. 수동 테스트를 통해 결함을 찾는다.
• 확장의 어려움
  • 일반적인 모놀리식 애플리케이션은 클라우드 네이티브가 아니므로 클라우드에 배포하기 어렵다.
  • 수동 설치 및 수동 구성에 따라 다르다.
• 새로운 기술에 적응의 어려움
  • 대부분 모놀리식 애플리케이션은 오래된 기술을 사용한다. -> 새로운 기술을 추가하면 유지관리가 매우 복잡
• 새로운 방법론 적용의 어려움
  • 애자일같은 방법론은 소규모의 독립팀이 필요하다.
• 현대적인 개발 사례 적용의 어려움
  • TDD와 같은 단위 테스트 어려움

마이크로서비스 시작

더 많은 기능을 더 자주 배포할 수 있는 방법!

마이크로서비스란?

소프트웨어에서 좋아하는 원칙 중 하나는 소프트웨어를 작게 유지하는 것이다.
마이크로서비스는 '소프트웨어로 작게 유지한다'라는 원칙의 간단한 확장으로,
소규모의 기능 기반의 독립적으로 배포 가능한 서비스를 구축하는 데 중점을 둔 아키텍처 스타일이다.

• 모놀리식과 마이크로서비스의 차이 (참고) https://velog.io/@cclare/%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9D-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4 

  

마이크로서비스 특성

• 작고 가벼운 마이크로서비스
  • 5분 안에 마이크로서비스를 구축하고 배포할 수 있어야한다.
• 메시지 기반 통신
  • 핵심은 다양한 기술을 사용하는 시스템 간의 통신인 상호 운용성이다.
  • 상호 운용성을 달성하려면 메시지 기반 통신을 사용하는 방법이 가장 좋다.
• 독립적으로 배포 가능
  • 각 마이크로서비스는 개별적으로 구축 및 배포할 수 있다.
• 무상태 마이크로서비스
  • 이상적인 마이크로서비스는 상태가 없다. 요청 간에 정보를 저장하지 않는다.
  • 응답을 작성하는 데 필요한 모든 정보가 요청에 들어 있다. => (메세지)
• 완전 자동화된 빌드 및 릴리즈 프로세스
  • Continuous Integration(이하 CI) : 지속적인 통합, 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 병합되므로 여러명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결
  • Continuous Deployment(이하 CD) : 지속적인 서비스 제공 및 지속적인 배포 

    

• 이벤트 주도 아키텍처 준수 

  

   분산된 데이터 조회를 조회하는 일을 메시지 브로커에게 메시지만 전달해주면 다른 서비스들이 메시지 브로커에서 새 이벤트를 수신 후 이벤트 처리.
• 마이크로서비스 개발 및 지원을 하는 독립 팀 - 데브옵스 마이크로서비스를 개발하는 팀은 일반적으로 독립적. (개발, 테스트, 배포)
  프로덕션에서 마이크로서비스를 지원할 책임이 있다.

마이크로서비스 아키텍처의 장점

• 출시 기간 단축
  • 각 마이크로서비스는 단일 비즈니스 기능에 중점을 두기 때문에 마이크로서비스 확장은 쉽고 좀더 안정적이다.
• 기술 진화에 빠른 적응
  • 매일 새로운 언어, 프레임워크 등이 등장하고 있는데, 새로운 가능성에 적응할 수 있는 유연성 확보
• 확장성
  • 서비스마다 다르게 확장할 수 있음으로 유연
• 현재 개발 방법론(애자일)과의 호환성
  • 민첩하고 다른 최신 개발 방법론과 매우 잘맞음

마이크로서비스 아키텍처의 단점

• 자동화의 필요성 증가
  • 빌드, 릴리스와 배포 수가 몇 배로 늘어남, 단계를 수동으로 수행하면 매우 비효율적
• 서브 시스템의 경계 정의
  • 마이크로서비스의 범위를 결정하기 어렵다.
  • 느슨한 결합 및 높은 응집력은 기본
• 가시성 및 모니터링 필요성 증가
  • 마이크로서비스를 사용하면 하나의 애플리케이션이 여러 마이크로서비스로 분할
  • 여러 마이크로서비스 및 비동기 이벤트 기반 협업과 관련된 복잡성을 극복하려면 가시성을 높여야함 => 모니터링
  • 다른 마이크로서비스의 로그와 메트릭을 집계하는 중앙 집중식 로깅이 일반적으로 사용
• 내결함성 증가
  • 서비스를 작게 만들면 서비스가 중단될 가능성이 높음
  • 따라서 애플리케이션이 다운되는 상황에 어떻게 반응하는지 중요함
  • 내결함성이 있어야함. => 서비스가 중단되면 서킷 브레이커와 같은 동작 필요

클라우드 네이티브 애플리케이션

조직은 클라우드를 통해 필요에 따라 컴퓨팅, 네트워크 및 스토리지 장치를 프로비저닝 할 수 있다.
※ 프로비저닝 : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요할 때 시스템을 사용할 수 있는 상태로 만들어 줌.

클라우드 네이티브 애플리케이션은 클라우드에 쉽게 배포할 수 있는 애플리케이션을 구축할 수 있다.  

클라우드 네이티브 애플리케이션은 프라이빗, 퍼블릭 및 하이브리드 클라우드 환경 전체에 지속적인 개발과 자동화된 관리 환경을 제공하기 위해 특별히 설계된 애플리케이션을 뜻함.
애플리케이션을 신속하게 구축하고 업데이트하면서 품질을 개선하고 위험을 낮추는 접근 방식
마이크로 서비스 아키텍처를 기반으로 하며, 관리되는 서비스를 사용하고, 지속적인 업데이트를 활용하여 안정성을 확보하고 출시 시간을 단축

※타임투마켓 : 신속성

클라우드 네이티브를 위한 주요 4가지 요소

1. DevOps 애플리케이션 개발-운영 간의 협업 프로세스를 자동화하는 것을 말하며 결과적으로 애플리케이션의 개발과 개선 속도를 빠르게 함.
2. CI/CD 지속적인 통합(Continous Intergration)은 개발자가 작업한 코드를 자동으로 테스트하고 테스트에 통과하면 코드를 통합하여 저장 지속적인 배포(Continuos Deployment)는 작업한 코드 및 변경사항들은 테스트를 거쳐 리포지토리에 업로드되고 실 서비스 배포로 릴리즈까지 자동화
3. 컨테이너 기반 인프라 가상화 기술 중 하나로, 시스템을 가상화하는 것이 아니라 애플리케이션을 구동할 수 있는 컴퓨팅 작업을 패키징하여 가상화.
4. Microservice 애플리케이션을 구성하는 서비스들을 독립적인 작은 단위로 분해하여 구축하고 각 구성 요소들을 네트워크로 통신하는 아키텍처로 서비스 안정성과 확장성(scaling)을 지원

넷플릭스 사례로 보는 클라우드 네이티브의 이점

당면한 문제는 무엇이었을까?

• 모놀리식 구조로 인한 개발/개선 속도가 느림
변경이 발생할 때마다 모든 사람들이 한꺼번에 붙어서 작업을 해야 하고, 변경 시 문제가 발생되면 문제를 찾는 것 자체가 일이 되어버려 앱을 개발하고 개선하는 것이 비효율적

• 데이터베이스 의존적
거대한 하나의 오라클 데이터베이스를 사용했는데, 데이터베이스가 다운되면 모든 시스템이 다운되었으며, 매 2주마다 새 스키마를 적용하기 위해 적어도 10분의 가동 중지 시간이 생김.

• 데이터센터 비대화
트래픽이 몰리면 하드웨어를 추가해야 하며, 영상 스트리밍이라는 본질보다 데이터 센터가 더 커질 수 있는 상황이 됨

클라우드 네이티브 도입

• 마이크로서비스 아키텍처 도입
기능 하나를 고치거나 새 기능을 추가할 때 서비스를 통째 뜯어고칠 필요 없이 그 기능에 해당하는 애플리케이션만 손보면 되기 때문에 서비스를 빠르게 수정, 보안

• DevOps 환경 구축
넷플릭스의 경우 풀 사이클 개발자라는 개념으로 자사만의 데브옵스를 실천했습니다.
즉, 만든 사람이 운영하고 문제가 발생하면 직접 고치는 구조,
애플리케이션을 개발하고 테스트, 배포, 운영, 지원의 사이클을 신속하게 처리할 수 있는 DevOps 환경을 구축

• NoSQL 데이터 구조
무거운 관계형 데이터베이스에서 NoSQL 데이터베이스 구조로 변경하여 DB도 기능별로 나누어 사용하여 확장성, 고가용성을 확보

• 회복성 있는 아키텍처 데이터센터든 클라우드든 인스턴스 장애는 일어나기 마련이다.
따라서, 하드웨어 가용성에 의존하는 대신 자체 회복력을 가지는 아키텍처를 설계

---

빌드와 릴리스 단계

• 빌드 : 코드에서 실행 가능한 번들(EAR. WAR. JAR)과 여러 환경에 배포할 수 있는 의존 관게를 만든다.
• 릴리스 : 실행 가능한 번들을 특정 환경 설정과 결합해 배포한다.
• 실행 : 특정 릴리스를 사용해 실행 환경에서 앱을 실행한다.
  

  

---

마이크로서비스를 위한 스프링 프로젝트

모놀리식 시대에는 프레임워크를 설정하는 데 시간이 많이 걸렸다.
마이크로서비스 시대에는 개별 구성요소를 더 빨리 만들기 위해 스프링부트 프로젝트를 사용한다.
스프링부트의 목표는 최소한의 설정으로 스프링 기반 프로젝트를 개발할 수 있게 하는 것.

스프링 클라우드 시작하기

https://github.com/OpenIroStudy/Mastering-Spring-5-Study/blob/main/ch01/%EC%8A%A4%ED%94%84%EB%A7%81%20%ED%99%98%EA%B2%BD.md

• 구성 관리 : 스프링 클라우드는 마이크로서비스를 위한 중앙 집중식 구성 관리 솔루션인 스프링 클라우드 컨피그를 제공.
• 서비스 디스커버리 : 서비스 간 느슨한 연결을 촉진한다. 스프링 클라우드는 유레카, 주키퍼, 콘솔과 같이 인기있는 서비스 디스커버리 옵션과 통합.
• 서킷 브레이커 : 클라우드 네이티브 애플리케이션은 내결함성이 있어야하고, 서비스를 정상적으로 지원하지 못하는 문제를 처리할 수 있어야한다.
• API 게이트 웨이 : 중앙 집중식 집계, 라우팅, 캐싱 서비스를 제공, 넷플릭스 주울과의 통합 제공

스프링 클라우드 하위 프로젝트

• 스프링 클라우드 넷플릭스 : 넷플릭스는 마이크로서비스 아키텍처의 초기 채택자중 하나로써, 많은 넷플릭스 프로젝트가 오픈소스로 공개 ( 유레카, 히스트릭스, 주울)
• 스프링 클라우드 컨피그 : 다양한 환경의 여러 마이크로서비스에서 중앙 집중식 외부 구성이 가능
• 스프링 클라우드 버스 : 간단한 메시지 브로커와 마이크로서비스 통합을 보다 쉽게 가능
• 스프링 클라우드 슬러시 : 제프킨과 함께 분산 추적 솔루션 제공
• 스프링 클라우드 데이터 플로우 : 마이크로서비스 애플리케이션을 중심으로 오케스트레이션을 구축하는 기능 제공(REST API 등)
• 스프링 클라우드 스트림 : 스프링 기반 애플리케이션을 아파치 카프카나 RabbitMQ와 같은 메시지 브로커와 통합하기 위해 간단한 선언적 프레임워크 제공

스프링 클라우드 범주의 모든 프로젝트에 공통적으로 적용되는 사항

• 클라우드에서 애플리케이션을 개발할 때 발생하는 몇 가지 문제 해결
• 스프링 부트와의 훌륭한 통합 제공
• 일반적으로 간단한 어노테이션으로 구성
• 자동 설정 광범위하게 사용

※ 오케스트레이션은 여러 개의 컴퓨터 시스템, 애플리케이션 및/또는 서비스를 조율하고 관리하는 것으로, 여러 개의 작업을 함께 연결하여 크기가 큰 워크플로나 프로세스를 실행하는 방식

####스프링 클라우드 넷플릭스

• 유레카 : 마이크로서비스를 위한 서비스 등록과 검색 기능 제공
• 히스트릭스 : 서킷브레이커를 통해 내결함성 마이크로서비스를 구축하는 기능으로 대시 보드 제공
• 페인(Feign) : 선언적 REST 클라이언트를 사용하면 스프링 MVC로 생성된 서비스 쉽게 호출
• 리본(Ribbon) : 클라이언트 측 로드 밸런싱 제공
• 주울 : 라우팅, 필터링, 인증. 시큐리티 같은 일반적인 API 게이트웨이 기능 제공.

마이크로서비스 아키텍처의 최대 이점을 활용하려면 마이크로서비스가 클라우드 기반이어야하며 클라우드에 쉽게 배포할 수 있어야한다.  
12장에는 모든 문제에 대한 해결첵 구현.