About MSA
모노리스 시스템
- 애플리케이션이 한 덩어리로 구성
- 단일 프로세스 실행
- 한꺼번에 수정, 배포
- 하나가 실패 -> 모두 실패
- 모노리스를 클라우드 인프라에서 활용
스케일 아웃시 모노리스 한덩어리가 됨, 확장성 탄력성이 보장은 되나 비용적으로 비효율적
그에 비해 마이크로서비스는 애플리케이션에 여러 서비스 조각으로 구성
- 서비스는 각기 독립적 기능
- 서비스가 사용하는 저장소는 다른 서비스와 완벽히 격리
- 독립적으로 수정은 가능, 별도 배포 확장 가능
- 하나의 서비스 실패 -> 전체가 아닌 부분 실패
확장시 특정 기능별 독립적 확장 가능
특정 서비스 변경시 서비스만 빌드 배포
독립적 서로 다른 언어로 개발 가능
마이크로서비스 성공을 위한 조건들
-
클라우드 적용시 가장 이상적인 애플리케이션 유형은 MSA
비즈니스 민첩성을 높이기 위해서는 기술 아키텍처 변화에 국한 X
개발프로세스 조직, 개발 문화의 동반적인 적은 변화 필요 -
개발과 운영이 함께 진행되야 한다.
자동화
빠른 소프테웨어 개발을 위해 개발 지원용 자동화 도구 필요
- 개발 지원 도구
- CI/CD 자동화
Infra
유연하고 민첩하게 제공되는 가변적 인프라 (cloud)
Public, Private, hybrid Cloud
Infra as Code (cloud 환경은 code로 제공)
Immutable Infra : 배포된 후 변경되지 않는 인프라 패러다임
-> 개발 환경이 달라지는 case = 수정 때문에 환경이 달라져 문제가 발생
-> container 환경 = 문제 발생시 문제가 발생된 container 삭제
개발 프로세스
반복/점진적 피드백 기반 프로세스
-> 에자일 개발 방식
2 ~ 3주의 이터레이션 또는 스프린트를 통한 소프트웨어 개발 후 feedback
실제로 올라가는 software 배포
feedback 기반 -> 다중 product를 만드는 방식, 변경사항 적음
DevOps 개발 문화
지속적인 피드백 제공, 빠른 문제 감지 및 복구
• 자동화테스트 , 피어 리뷰
• 피드백을 통한 개선
생산적인 신뢰/협업 문화 생성
• 실험/위험 감수, 조직 학습
• 비난하지 않는 포스트 모텀(post-mortems)
• 내부 기술 콘퍼런스
• 끊임없는 학습
data 중복, 결과적 일관성
Polyglot Persistence 접근 방식
서비스 별 DB 설계
- 각 저장소 분산 필수
- 다른 서비스 저장소 호출 불가능
- API만 통하여 접근 가능
언제든 실패 할 수 있음, 자연스럽게 대응할 수있도록 설계
다양한 실패 대비, 자동으로 테스트할 수 있는 환경 마련 실패 감지 및 대응을 위한 실시간 모니터링 체계 필요
서킷 브레이크 pattern
서비스를 모니터링 중 서비스 다운 또는 실패시 호출하는 서비스 연계 차단, 적절한 대응을 위해 만듦
