학교 공부를 복습할 겸 적는 것이기에 내용이 부족할 수 있습니다.
부족한 것은 상관 없으나, 잘못된 부분이 발견된다면 지적해주시면 감사하겠습니다.
Monolithic Architecture란?
모놀리틱 구조는 사용자 인터페이스, 데이터 베이스, 애플리케이션 로직과 같은 모든 요소를 단일 서버 내에 결합하는 것이 특징인 웹 애플리케이션의 일반적인 디자인 형태입니다.
모놀리틱 구조를 사용할 때의 장점은 간단한 구조덕에 개발이 쉬워지며, 확장성이 용이하다는 점입니다.
단점으로는 사소한 변경이 생길 때마다 시스템을 재구축하고 재배포해야하는 번거로움과, 애플리케이션이 너무 복잡해지는 등 문제가 발생할 수 있습니다.
이러한 문제점을 해결하기 위해 로직, 데이터 엑세스 레이어를 포함하여 별개의 레이어로 분류합니다.
Layered Systems
계층형 시스템은 모놀리틱 구조를 개별 계층으로 분해하여 애플리케이션의 구조화에 대한 다른 접근 방식을 제공해줍니다. 각 계층은 presentation, logic, data access가 포함되며, 자체 기술 스택을 활용할 수 있지만 일반적으로 유사한 프레임워크내에 존재한다고 합니다.
계층형 시스템의 장점은 각 계층은 다른 계층에 대한 종속성을 줄여 해당 계층 내의 유지 관리 및 업데이트를 단순화할 수 있다는 점입니다.
단점으로는 여전히 대형 코드베이스로 인해 관리하기가 어려울 수 있으며, 각 계층이 다르게 확장될 수 있어 자체 병목현상이 일어날 수 있습니다.
Cloud Native
CNCF(Cloud Native Computing Foundation)에서 정의한 클라우드 네이티브 컴퓨팅은 클라우드 네이티브 기술을 활용하여 현대적이고 역동적인 환경에서 확장 가능한 애플리케이션을 구축하고 운영하는 방식을 의미합니다.
이러한 환겨엥는 public, private, hybrid 클라우드 인프라가 포함됩니다.
클라우드 네이티브 컴퓨팅의 주요 특징으로는 컨테이너 사용, 마이크로서비스 아키텍쳐, 인프라 불편 등이 있습니다.
클라우드 네이티브 컴퓨팅을 사용할 때의 이점은 확장성, 복원력, 관리 용이성, 자동화 등이 있습니다.
클라우드 네이티브 기술을 광범위하게 채택한 실제 사례는 Netflix 및 Uber와 같은 회사에서 볼 수 있습니다. 넷플릭스는 600개 이상의 서비스를 프로덕션에서 운영하고 있으며 하루에 약 100번 정도 업데이트를 배포할 수 있는 것으로 알려졌습니다. Uber는 1,000개가 넘는 프로덕션 서비스를 운영하고 있으며 매주 수천 번 배포가 이루어지고 있습니다.
Microservice Architecture
마이크로서비스 아키텍처 스타일에는 소규모의 독립적인 서비스 모음으로 애플리케이션을 개발하는 것이 포함되며, 각 서비스는 자체 프로세스에서 실행되며 일반적으로 HTTP 기반 API와 같은 경량 메커니즘을 사용하여 통신합니다.
마이크로서비스는 "비공유" 아키텍처를 따릅니다. 각 서비스는 자체 프로세스로 작동하며 다른 서비스와 메모리나 데이터 저장소를 공유하지 않습니다.
비즈니스 기능을 중심으로 구성되어 각 서비스가 기능적으로 일관되고 비즈니스 목표에 부합하도록 보장하며,
종종 완전 자동화된 배포 프로세스를 사용하여 각 서비스를 독립적으로 배포할 수 있다는 것입니다.
마이크로서비스는 SOA(Service-Oriented Architecture)의 가장 효과적인 측면에 초점을 맞춘 SOA의 반복이라고도 합니다.
SOA와의 주요 차이점은 SOA의 경우 서비스가 더욱 상호 연결되고 중앙에서 관리되는 특성이지만, 마이크로서비스의 경우 독립적인 배포 가능성과 최소한의 중앙 집중식 관리에 중점을 둔다는 것입니다.
마이크로서비스 간 통신은 속도가 느리고 안정성이 떨어지는 네트워크 호출을 포함하므로 프로세스 내 통신에 비해 리소스 집약적입니다.
MSA의 기본 원칙
- "micro"라는 단어가 붙은 마이크로서비스는 단일 개발 팀(5-9명의 개발자)에 의해 관리될 수 있어야 합니다.
- 기능적 시스템 분해는 수직적 슬라이싱을 의미합니다.
- 독립적 배포 가능성은 공유된 상태가 없음을 의미하며, 프로세스 간 통신은 종종 HTTP REST 기반 인터페이스를 통해 이루어집니다.
독립적 배포 가능성이란 마이크로서비스 아키텍처(MSA)의 핵심 요소 중 하나입니다.
각 서비스는 자체 소프트웨어 저장소를 가지며, 이는 다른 서비스의 코드 베이스와 독립적으로 관리됩니다.
데이터 샤딩(sharding)과 같은 기법을 필요에 따라 마이크로서비스에 적용할 수 있습니다.
마이크로서비스는 다른 서비스에 영향을 주지 않으면서 확장될 수 있습니다.
UI의 일부를 새 버전으로 배포할 때 전체 시스템을 재배포할 필요가 없습니다.
Stable Interfaces – standardized communication
안정적인 인터페이스는 마이크로서비스 아키텍처의 중요한 측면입니다. 마이크로서비스 간의 통신을 표준화하면 일관성, 안정성 및 통합 용이성이 보장되기 때문입니다.
- HTTP(S) – 전송 프로토콜:
- HTTP(Hypertext Transfer Protocol) 및 보안 버전인 HTTPS는 마이크로서비스 통신의 전송 프로토콜로 널리 사용됩니다.
- 전투 테스트를 거쳤으며 광범위하게 사용 가능하므로 네트워크 통신을 위한 안정적인 선택입니다.
- HTTP(S)는 서비스가 웹을 통해 메시지와 데이터를 교환하는 표준화된 방법을 제공합니다.
- REST – 표현 상태 이전:
- REST는 네트워크 애플리케이션 설계에 사용되는 널리 사용되는 아키텍처 스타일입니다.
- 리소스로 취급되는 데이터에 접근하고 조작하기 위한 균일한 인터페이스를 제공합니다.
- RESTful 서비스는 GET, POST, PUT, DELETE와 같은 표준 HTTP 방법을 사용하여 서로 다른 서비스 간의 상호 작용을 단순화합니다.
- JSON – JavaScript 객체 표기법:
- JSON은 사람이 읽고 쓰기 쉽고 기계가 구문 분석하고 생성하기 쉬운 경량 데이터 교환 형식입니다.
- RESTful 서비스에서 구조화된 데이터를 표현하는 데 일반적으로 사용됩니다.
- JSON은 단순하므로 마이크로서비스의 데이터 표현에 편리한 선택입니다.
인터페이스 발전에 REST와 JSON이 편리한 이유:
- REST는 인터페이스 구조화에 유연하고 직관적인 접근 방식을 제공합니다. 웹 서비스에 사용되는 또 다른 프로토콜인 SOAP(Simple Object Access Protocol)와 달리 요청 및 응답 형식을 지정하는 방법에 대해 엄격한 규칙을 적용하지 않습니다. 이러한 유연성을 통해 시간이 지남에 따라 서비스가 변경됨에 따라 인터페이스를 더욱 쉽게 발전시키고 조정할 수 있습니다.
- JSON은 간단하고 널리 지원되는 형식이므로 데이터 구조를 쉽게 수정할 수 있습니다. 기존 클라이언트를 중단하지 않고 새 필드를 추가하거나 기존 필드를 수정하는 데 사용할 수 있습니다. 이는 다양한 서비스가 독립적으로 발전할 수 있는 마이크로서비스 아키텍처에서 특히 중요합니다.
요약하면 전송에 HTTP(S)를 사용하고 인터페이스 디자인에 REST를 사용하고 데이터 표현에 JSON을 사용하면 마이크로서비스 간 통신을 위한 강력하고 유연하며 간단한 프레임워크가 제공됩니다.