Software Architecture
Antifragile
Autoscaling
MicroService
작게 분리된 독립적인 서비스
마이크로서비스라는 것은 클라우드네이티브 아키텍처 클라우드네이티브 어플리케이션을 핵심
Chaos engineering
변동, 예견되거나 예견되지 않은 불확실성에 대해 대처를 잘하고 잘 견디는것
Continuous deployments
Cloud Native Architecture
확장 가능한 아키텍처
시스템의 수평적 확정에 유연
확장된 서버로 시스템의 부하 분산, 가용성 보장
시스템 또는, 서비스 애플리케이션 단위의 패키지(컨테이너 기반 패키지)
모니터링
탄력적 아키텍쳐
서비스 생성 - 통합 - 배포, 비즈니스 환경 변화에 대응 시간 단축
분할 된 서비스 구조
무상태 통신 프로토콜
서비스의 추가와 삭제 자동으로 감지
변경된 서비스 요청에 따라 사용자 요청 처리 (동적 처리)
장애 격리
특정 서비스에 오류가 발생해도 다른 서비스에 영향을 주지 않는다.
Cloud Native Application
클라우드 네이티브 아키텍처에 의해 설계되고 구현 되는 어플리케이션
데브옵스
마이크로서비스에 문제가 발생하여 있을 경우에 바로 바로 수정해서 다시 배포하는 과정을 반복할 수 있는 형태.데브 옵스에서는 처음에 시스템이 기획되고 구현되고 테스트되고 배포되는 과정을 시스템이 종료될때까지 무한 반복 해 줌으로써 고객이 원하는 최선의 어플리케이션 최선의 결과를 만드는데 그 목적을 두고 있습니다.
CI/CD
지속적인 통합
통합서버, 소스관리(SCM), 빌드 도구, 테스트 도구
Jenkins, Travis Ci
지속적 배포
Pipeline
Devops
디벨로프먼트 와 운영을 뜻하는 오퍼레이션의 용어
개발정책과 운영조직 대통합
고객의 요구사항을 빠르게 반영하고 만족도높은 결과물을 제시하는 것이 그 목적을 두고 있다.
기존 엔터프라이즈 어플리케이션들은 고객의 요구 사항에 맞게 도메인을 분석하고 시스템을 설계, 그리고 어플리케이션 구형과 테스트 마지막으로 배포 과정을 거쳐 시스템 개발 완료한다.
고객의 요구사항과 같은 변경사항이나 오류 사항 개선 사항 같은 것들은 시스템 시스템의 개발 막바지 종반에 발생하는 것 보다는 필요할 때마다 바로 반영이 되고 필요할 때마다 바로바로 수정할 수 있는 구조가 더 좋다.
그때그때 고객의 요구사항을 반영하고 개발된 내용에 대해 테스트를 자주 하는 거 자체는 전체 개발 일정을 더디게 하나 요인이 될 수도 있겠지만 개발회사가 개발하려고 하는 서비스 라든가 어플리케이션은 궁극적으로 고객의 요구 사항에 맞는 에러없는 완성본이어야 한다..
따라서 자주 테스트하고 자주 피드백을 받고 자주 업데이트 하는 과정을 거쳐 전체 개발 일정이 완료될때까지 지속적으로 끊임 없이 진행하는것을 데브옵스라한다.
12 Factors
Heroku사 에서클라우드 네이티브 어플리케이션을 개발하거나 서비스를 운영할 때 고려해야 할 항목들을 정리한것
+3
API First
Telemetry
Authentication and Authorization
Monolithic VS MSA
Monolithic
애플리케이션을 개발함에 있어서 필요한 모든 요소를 하나의 커다란 소프트웨어 안에 전부 포함(패키징)시켜 개발하는 방법
데이터베이스 관련된 로직 이라든가 비즈니스로직뿐만 아니라 화면을 처리해주는 프론트엔드 기술까지이 모든 서비스에 대한 내용들이 하나의 어플리케이션에서 유기적으로 연결되어 작동하고 있고, 배포 되기 위해서 서로 의존성을 가진체 패키징 되고 운영서버에 배포하게 된다.
애플리케이션에서 사용하는 데이터가 한 곳에 모여 참조되어 서비스되는 형태
일부분만 수정한다 하더라도 전체 애플리케이션을 다시 빌드하고 테스트하고 패키징해야 한다는 단점이 있다.
MSA
애플리케이션을 구성하는 각각의 구성 요소 및 서비스의 내용을 분리해서 개발하고 운영하는 방식
모노리스 방식에 비해서 유지보수나 변경 사항을 적용하는데 훨씬 더 유리하다.
필요한 부분에 대해서만 개발을 하고 이렇게 분리된 서비스가 다른 서비스에 영향을 주지 않고 독립적으로 배포가 가능
마이크로서비스 방식은 각각 용도에 맞는 컨테이너들을 모아서 사용하는 서비스 개념
함께 작동한는 작은 규모의 서비스들
서로다른 프로그래밍 언어와 데이터 저장기술들을 사용할 수 있다.
최소한의 중앙집중식 관리가 되어야 한다.
서비스의 크기가 도메인의 도메인 특징을 고려해서 경계로 구분돼야 해야 되고, 구분된 서비스들은 독립적인 언어와 독립적인 데이터베이스를 사용할 수 있다.
고객 의뢰를 받고 프로젝트를 승인받는다. 개발조직을 구성하고 요구사항을 수립하고 업무 도메인 정의와 분석 그리고 시스템 설계의 과정을 거친다. 그후 어떤 DB, 언어 를 사용할 것인지 그리고 프로그래밍 언어를 위한 네이밍 룰을 이나 인터페이스등을 결정하고 진행
마이크로서비스에서는 이러한 프로그램을 개발, 언어 데이터베이스를 전체 어플리케이션에서 통일하는 것이 아니라 각각의 서비스별로 특성에 맞게 최적화 되어 있는 언어와 데이터베이스를 사용하는 것을 권장하고 있다
마이크로 서비스는 어플리케이션을 구성하는 다양한 서비스를 경계를 잘 분리하고,서비스의 상황과 기능에 맞춰 개발 언어를 선택하고 각각의 서비스들은 Restful APi와 같은 매커니즘을 통해서 서로의 데이터를 제공해서 사용할 수 있도록 개발을 하게 된다.
모놀리스 방식과 마이크로 서비스 방식 중간 정도의 개발 방식으로 프로트와 백엔드를 분리해서 개발하는 방식도 자주 사용된다.
서로의 상태에 대해서 Rest Api 방식으로 통신하는것을 권장
환경설정 정보는 외부에 두어서 관리하는것을 권장
마이크로서비스 아키텍처 적용전 고려사항
회원가입이라는 마이크로서비스에 저장된 회원목록 데이터를 결제 마이크로서비스에서 사용 하기 위해서는 두 개 서비스가 연결되거나 결제서비스에서 직접 회원 가입 서비스에 접속해서 데이터를사용 하는 방식이 아니라, API를 통해서 데이터를 요청하고 사용해야하고 회원가입 서비스에 문제가 생길 시에도 결제 서비스에는 직접적인 영향을 주지 않고 우회 할 수 있는 서비스를 제공할 수 있도록 구현된 것이 마이크로 서비스들의 관계이다.
SOA 와MicroService는 어디 까지 서비스를 공개하는냐에 큰 차이가있다.
다른 분리되어있는 데이터베이스에 저장 되어 있었지만 메시징 서비스 통해서처리하여, 데이터를 같이 동기화시킬 수 있다.
서비스간의 통신은 rest Api나, 메시징 시스템을 통해서 처리된다.
서비스 메쉬란 마이크로 서비스 아키텍처를 적용한 시스템 내부통신을 말하고 서비스 메쉬를 통해서 서비스간의 통신은 추상화하고 안전하고 빠르고 신뢰성 있게 만들어주는 인프라스트럭처의 레이어라고 볼 수 있다.
추상화를 통해 복잡한 내부 네트워크를 제어하고 추적하고 내부 내부네트워크 관련된 로직을 추가함으로써 안정성, 신뢰성, 탄력성, 표준성, 가시성, 보안성 등을 확보할 수 있게 됩니다.
