마이크로 서비스 아키텍처란 무엇입니까?
마이크로서비스 아키텍처 는 애플리케이션을 특정 비즈니스 기능을 구현하는 개별 서비스로 분해하여 현대 개발자에게 확장성이 뛰어나고 유연한 애플리케이션을 설계할 수 있는 방법을 제공하는 기술을 의미합니다. "느슨하게 결합 된" 서비스라고도 하는 이러한 서비스는 독립적으로 구축, 배포 및 확장할 수 있습니다.
각 서비스는 서비스를 다른 언어 또는 다른 기술로 작성할 수 있게 하는 표준화된 API (애플리케이션 프로그래밍 인터페이스)를 통해 다른 서비스와 통신합니다. 이것은 서비스가 뗄 수없이 서로 연결되어 있고 함께 확장될 수 있는 모 놀리식 구조로 구축된 시스템과는 완전히 다릅니다.
각 서비스는 기능이 제한되어 있기 때문에 크기와 복잡성이 훨씬 적습니다. 마이크로서비스라는 용어는 물리적 크기가 아닌 이 개별 기능 설계에서 비롯됩니다.
마이크로서비스 아키텍처를 선택해야 하는 이유?
마이크로서비스 아키텍처는 모듈식 특성이 유연성, 확장성 및 개발 노력 감소로 이어지기 때문에 인기가 높아졌습니다. 배포 유연성과 클라우드 네이티브 서버리스 및 서비스로서의 기능 배포 옵션 (예 : AWS Lambda 및 Microsoft Azure Cloud Functions)의 부상으로 마이크로서비스가 오늘날의 IT 환경에서 번창할 수 있는 완벽한 환경이 만들어졌습니다. 이러한 클라우드 플랫폼을 사용하면 마이크로서비스 와 기능을 비활성 상태에서 대량으로 확장하고 다시 되돌릴 수 있으며 고객은 사용하는 컴퓨팅 용량에 대해서만 비용을 지불합니다.
기업이 보다 민첩하려고 하고 병목 현상을 줄이며 애플리케이션 제공 시간을 개선하기 위해 지속적으로 노력함에 따라 마이크로서비스 아키텍처의 인기가 계속 높아지고 있습니다.
마이크로서비스 아키텍처의 이점
- 애플케이션 구성 요소를 여러 가지 프로그래밍 언어로 구축 가능
- 지속적인 개별적 개발 및 배포 스트림 유지 가능
- 확장성이 뛰어난 애플리케이션 구축 가능
- 클라우드 네이티브 서비스로서의 기능 배포 옵션 사용 가능
- 종종 운영 비용 절감
- 분리 및 느슨한 결합으로 구획화된 업그레이드 및 향상 가능
마이크로서비스 아키텍처 사용 사례의 예
- 클라우드 네이티브 배포 옵션 채택: 보다 효율적이고 확장 가능한 운영을 위해 서버리스 및 서비스로서의 기능 을 활용합니다.
- 레거시 애플리케이션의 기능 마이그레이션: 대규모 모놀리식 애플리케이션에서 서비스를 분해하여 독립적으로 관리하고 확장할 수 있습니다.
- 최신 애플리케이션 아키텍처 활용: 사용 사례 요구 사항에 따라 다양한 프로그래밍 언어를 활용할 수 있는 기능과 함께 이벤트 중심의 느슨하게 결합된 마이크로서비스 애플리케이션 패턴을 수용합니다. 예를 들어 계산량이 많은 함수를 위해, 빠른 웹 앱 개발을 위해 Node.js 등을 선택합니다.
DevOps란 무엇이며 종종 마이크로서비스와 연결되는 이유는 무엇입니까?
DevOps 는 도구 중심 이념으로 설명할 수 있습니다. 기본적으로 도구/기술은 개발자가 수행해야 하는 작업을 단순화하는 데 사용됩니다. 개선된 도구 사용과 함께 운영팀과 개발팀 간의 협력은 프로젝트를 더 빠르고 효율적으로 완료하는 데 도움이 됩니다.
예를 들어 사용자가 계정 잔액을 확인할 수 있는 애플리케이션을 개발한다고 가정해 보겠습니다. 과거에는 종종 앱 개발주기에서 개발자가 앱을 빌드한 다음 최종 결과에 대한 책임없이 운영 팀에 넘겨야 했습니다. 그것을 작동시키는 것은 운영 팀의 일이었습니다. 보다 응집력있는 DevOps 환경에서는 양측이 함께 협업합니다. 개발자는 처음부터 끝까지 앱의 수명주기를 관리하게 되며, 이는 예를 들어 출시 기간 동안 대기 중임을 의미합니다. 모든 것이 성공적이고 DevOps의 이점 (시장 출시 속도, 개발주기 용이, 책임 성 향상 등)을 얻으려면 두 그룹 간의 일관된 커뮤니케이션이 필요합니다.
새로운 DevOps 워크플로 모델은 주요 문화적 변화를 만듭니다. 새로운 도구를 사용한다고 해서 DevOps 계획이 성공하는 것은 아닙니다. 새로운 도구가 모든 것이 적절하게 구현될 것이라고 의심도 하지 않고 믿는 것은 성공의 방해물일 수 있습니다.
마이크로서비스의 특성으로 인해 배포에 강력한 DevOps 프로세스가 필요한 경우가 많습니다. 도구 사용의 증가와 더 강력한 공유 관행은 팀이 작고 변화되는 모든 부분에 의한 압도를 덜어줍니다. 혜택을 계속 받으면서 이러한 변화의 중단이나 부담을 줄입니다.
미래: 이벤트 기반 마이크로서비스, 서버리스 컴퓨팅 및 FaaS
사람들이 처음으로 마이크로서비스를 실험하기 시작할 때 RESTful API 와 같은 익숙한 기술을 사용하는 경우가 많습니다. REST는 요청-응답 유형의 통신에서 작동합니다. 이 동기식 접근 방식의 문제점은 응답을 기다려야 한다는 것이며 서비스가 서로 의존하게됩니다. 따라서 한 서비스가 느리게 실행되거나 응답하지 않으면 해당 서비스를 호출한 서비스도 느리게 실행되거나 실패합니다. 이러한 결합은 마이크로서비스 아키텍처의 이점 중 일부를 무의미하게 하고 SOA(서비스 지향 아키텍처) 스타일과 유사한 상호 의존적인 구조를 만드는 것을 의미할 수 있습니다.
이벤트 기반 모델을 사용하여 서비스를 설계하는 경우 전체 애플리케이션이 응답하지 않는 것과는 반대로 애플리케이션의 일부는 계속 작동하고 다른 부분은 관련되지 않을 수 있습니다. Netflix를 예로 들어 보겠습니다. 때때로 "계속 보기" 버튼이 표시되지 않는 것을 알 수 있습니다. 특정 서비스를 사용할 수 없기 때문입니다. 그러나 그렇다고 모든 Netflix가 중단되는 것은 아닙니다. 사용자는 여전히 프로그램을 검색하고 미리보기를 볼 수 있으므로 Netflix 서비스의 다른 측면은 여전히 사용할 수 있습니다.
마이크로서비스 접근 방식을 완전히 수용하는 개발자는 느슨한 결합 및 이벤트 기반 아키텍처를 통해 진정한 확장성을 실현할 수 있음을 알고 있습니다. 서비스는 비동기식으로 동작을 수행하고 메시지를 브로드 캐스팅하고 다른 서비스의 응답을 기다릴 필요없이 기본 기능을 계속할 수 있습니다.