마이크로서비스의 이점은 무엇이며 귀하의 비즈니스에 비용을 지불할 것입니까?

소프트웨어 애플리케이션을 소규모 서비스 세트로 설계하는 접근 방식인 마이크로서비스의 개념은 적어도 2015년부터 존재해 왔습니다. 독립적인 배포 가능성 및 구성요소의 확장성과 같은 이점을 제공하는 마이크로서비스는 오늘날 대세입니다. 이는 이러한 마이크로서비스의 이점이 엄청나게 빠른 소프트웨어 개발 속도로 변환되기 때문입니다. 소비자가 자신의 선호도와 행동을 빠르게 변경함에 따라 마이크로서비스 채택자는 따라갈 수 있습니다. 인생은 이제 훌륭하다고 그들은 말합니다. 최근 IMB 설문조사에 참여한 기업의 56%가 향후 24개월 이내에 마이크로서비스 접근 방식을 채택할 계획입니다.

현재 사용자의 거의 80%는 비즈니스가 마이크로서비스에 대한 투자를 강화할 것이라고 말합니다. 마이크로서비스의 이점으로 인해 Netflix, Amazon, eBay, Twitter 및 기타 많은 기술 대기업은 모놀리식에서 마이크로서비스 아키텍처로 마이그레이션했습니다. 하지만 회사에서 마이크로서비스를 사용해야 합니까? 상황과 마이크로서비스의 장점이 애플리케이션의 단점을 능가하는지 여부에 따라 다릅니다. 이 블로그는 마이크로서비스와 모놀리식 접근 방식에 대한 개요와 마이크로서비스 아키텍처 사용의 5가지 주요 이점을 제공합니다. 또한 ITRex의 일부 마이크로서비스 경험을 공유하고 기업이 마이크로서비스를 사용해야 하는 경우에 대한 팁을 제공합니다. 다이빙

마이크로서비스 정의 및 모놀리식 아키텍처와의 비교

마이크로서비스 아키텍처 란 무엇입니까? 마이크로 서비스 스타일은 단일 비즈니스 워크플로를 중심으로 설계되고 함께 작동하는 작은 구성 요소 또는 서비스 제품군으로 클라우드 네이티브 소프트웨어 애플리케이션을 개발하는 접근 방식입니다. 기본적으로 마이크로서비스는 개발 및 IT 운영 팀이 자동화 도구를 사용하여 긴밀하게 협력하여 더 빠르게 제공하는 문화인 DevOps로의 근본적인 전환의 일부입니다.

마이크로서비스:

• 자율적으로 개발되고,
• 자체 데이터베이스를 사용하고 다른 언어로 작성될 수 있습니다.
• HTTP, 메시지 브로커 또는 이벤트 스트리밍과 같은 경량 프로토콜을 사용하여 API를 통해 통신하고
• 특정 비즈니스 기능을 수행합니다.

예를 들어, 마이크로 서비스 기반 전자 상거래 애플리케이션에는 제품 이미지, 사용자 프로필 관리, 검색, 재고 확인, 지불 처리 및 배송을 담당하는 독립적인 서비스가 있을 수 있습니다. 프런트 엔드(웹 사이트의 고객 대면 측면)는 백 엔드(비즈니스 대면)와 분리되어 별도로 사용자 지정 및 관리할 수 있습니다. Amazon의 예를 들면 마이크로서비스 아키텍처가 무섭지는 않더라도 압도적으로 보일 수 있습니다.

그러나 마이크로서비스 아키텍처를 사용하지 않았다면 Amazon은 세계에서 가장 가치 있는 회사 중 하나로 거의 발전하지 못했을 것입니다(2021년 12월 기준 시가 총액 1조 6940억 달러). 마이크로서비스의 이점을 활용하기로 한 결정은 느린 개발 및 코딩 문제로 인해 고객 기반 성장의 속도로 확장할 수 없다는 것을 Amazon이 이해한 2000년대 초반으로 거슬러 올라갑니다.

Netflix는 대규모 데이터베이스 손상으로 인해 며칠 동안 고객에게 DVD를 우편으로 보낼 수 없었던 2000년대 후반에 클라우드 기반 마이크로서비스 아키텍처의 이점을 알게 되었습니다. 애플리케이션을 700개가 넘는 마이크로서비스로 분할한 후 Netflix 엔지니어는 오늘날 하루에 수천 번 코드를 배포할 수 있게 되어 회사가 전 세계 2억 명 이상의 회원에게 매일 약 2억 5천만 시간 분량의 콘텐츠를 스트리밍할 수 있게 되었습니다. 이 기술 스타들과 다른 많은 회사들은 클라우드 이전 시대에 어떤 아키텍처를 사용했습니까? 그들은 모노리스를 사용했습니다.

모놀리식 아키텍처란 무엇입니까?

모놀리식 애플리케이션은 클라이언트 측 사용자 인터페이스, 서버 측 작업 및 데이터베이스를 포함한 모든 구성 요소를 결합하는 단일 단위로 구축됩니다. 일반적으로 모놀리식 아키텍처:

• 모든 기능에 대한 단일 코드베이스를 가지고 있으며,
• 밀접하게 결합되어 있으며,
• 중앙 집중식 데이터를 사용합니다.

모놀리식 접근 방식을 사용하여 개발된 전자 상거래 애플리케이션은 긴밀하게 연결된 프런트 엔드 및 백 엔드 서비스가 하나의 단위로 배포되어 구성됩니다. 비교).

모놀리식 애플리케이션은 죽지 않았습니다. 사실, 그것들은 종종 건설하기가 더 쉽고 저렴하기 때문에(적어도 초기에는) 여전히 좋은 선택이 될 수 있습니다. 그러나 단점이 있습니다. 업그레이드 목적이든 확장 목적이든 한 부분의 변경은 종종 전체 시스템을 재구축하고 재배포해야 합니다.

마찬가지로, 전체 시스템은 오작동하는 부분 하나에 의해 중단될 수 있습니다. 즉, 모놀리스가 깨지기 쉽습니다. 모놀리스는 성장함에 따라 유지 관리하기도 어렵고 타사 도구와의 통합도 즐겁지 않습니다. 이러한 단점은 기업이 생존과 번영을 위해 변화에 신속하게 대응해야 하는 오늘날의 파괴적인 시장 환경에서 무시하기 어렵습니다. 따라서 DevOps 팀이 구축한 마이크로서비스의 이점에 대한 소문이 있습니다.

마이크로서비스의 5가지 주요 이점

1. 독립 배포

마이크로서비스의 초기 개척자 중 한 명인 Sam Newman에 따르면 이것은 아마도 마이크로서비스의 가장 중요한 이점일 것입니다. 성능을 향상시키기 위해 애플리케이션을 변경하거나 새로운 사용자 요구에 대응하여 새로운 기능을 추가하는 것은 독립형 마이크로서비스를 사용하면 간단합니다. 각 서비스는 전체 시스템을 건드리지 않고 수정 및 업그레이드할 수 있습니다. 한 기능이 초과 요청으로 인해 너무 많은 부하를 받는 경우에도 서로 독립적으로 확장할 수 있습니다. 예를 들어 더 많은 지불을 받는 경우 다른 서비스의 리소스 소비를 늘리지 않고 지불 처리 서비스만 확장할 수 있습니다. 이러한 방식으로 프로세스는 더 적은 인프라를 필요로 하고 비용 절감으로 이어집니다.

2. 낮은 폭발 반경

마이크로 서비스 아키텍처의 느슨한 결합은 또한 마이크로 서비스의 또 다른 이점인 복원력 향상을 제공합니다. 마이크로 크기와 결합된 서비스 간의 명확한 경계는 새 릴리스의 영향을 제한하고 오류 격리를 보장합니다. 한 서비스에서 장애가 발생해도 관련 없는 기능은 중단되지 않으며 나머지 시스템은 그대로 유지되고 계속해서 사용자에게 서비스를 제공합니다.

3. 데이터 격리

이것은 올바르게 수행될 경우 마이크로서비스가 제공하는 세 번째 이점입니다. 구성요소별 데이터 주권은 마이크로서비스의 필수 기능입니다. 마이크로서비스 아키텍처를 사용하면 특히 조직이 의료 데이터 규정 또는 GDPR을 준수해야 하는 경우 데이터와 관련된 서비스를 명확하게 설명할 수 있습니다.

4. 올바른 기술의 사용

모놀리식 애플리케이션에는 단일 코드베이스가 있기 때문에 각 기능에 대한 기술 접근 ​​방식을 사용자 지정하기 어렵고 절충안을 찾는 경우가 많습니다. 이와 대조적으로 마이크로서비스는 기본적으로 비즈니스 기능을 중심으로 설계되어 팀이 특정 기능을 최대한 활용하기 위해 사용 가능한 최상의 기술을 선택할 수 있습니다. 마이크로서비스는 서로 다른 구성 요소에 대해 서로 다른 기술이나 프로그래밍 언어를 사용할 수 있기 때문입니다. 마이크로서비스는 또한 필요에 따라 최신 기술을 채택하거나 타사 도구와의 통합을 단순화합니다. 벤더 종속이 없다는 것은 느슨하게 결합된 아키텍처에서 자연스럽게 파생되는 또 다른 마이크로서비스 이점입니다.

5. 효율성

마이크로서비스 접근 방식을 통해 기업은 민첩한 방식으로 운영할 수 있는 하나의 서비스 또는 서비스 제품군을 중심으로 소규모의 교차 기능 팀을 구성할 수 있습니다. 이 모델은 한 팀이 다른 팀이 작업을 시작하기 전에 배포 또는 테스트를 완료하기 위해 다른 팀이 작업을 완료할 때까지 기다려야 하는 경우 핸드오프를 최소화합니다. 다른 팀에 의존하지 않고 개발 속도가 빨라집니다. IMB가 1,200명의 IT 임원 및 개발자를 대상으로 실시한 설문조사에 따르면 채택자들은 마이크로서비스 사용의 다양한 이점을 보고하고 있습니다. 그들이 느낀 가장 중요한 마이크로서비스 이점은 다음과 같습니다. 30% — 더 높은 고객 만족도 29% — 회사/고객 데이터의 더 나은 보안 29% — 더 빠른 시장 출시 28% — 개선된 애플리케이션 성능 27% — 리소스를 확장하거나 확장할 수 있는 더 큰 유연성 26% 감소 — 직원 생산성 향상 마이크로서비스에 문제가 있습니까? 글쎄요, 유명한 말처럼 마이크로서비스는 공짜 점심이 아닙니다. 읽어.

마이크로서비스의 나쁜 점

1. 복잡성

마이크로서비스의 고유한 복잡성은 서비스 수에 따라 증가합니다. 이 복잡성은 여러 가지이며 다음과 같은 원인에 기인합니다.

• 기술 및 운영 수준에서 하향식 제어가 불가능합니다.
• 테스트는 어렵고 테스트 자동화가 너무 많지는 않을 것입니다.
• 인터커뮤니케이션 구현이 까다로워서 유능한 개발자 필요
• 기록된 데이터의 양이 너무 커서 불일치가 발생할 수 있습니다.
• 새 버전에서는 호환성 문제가 발생할 수 있습니다.
• 적절한 양의 리소스를 프로비저닝하는 데 어려움이 있습니다.

2. 비용

마이크로서비스는 기업에 돈을 벌 수 있는 더 많은 옵션을 제공하지만 저축하지는 않습니다. 복잡한 마이크로서비스 환경을 구축할 수 있는 개발자를 고용하는 비용 외에도 클라우드 및 API 청구서가 있습니다. 좋은 소식은 마이크로서비스가 종량제 방식으로 온디맨드 리소스를 사용하므로 지속적인 비용이 크게 최적화될 수 있다는 것입니다.

3. 보안 위험

IBM 설문조사 응답자의 절반은 마이크로서비스 도입 과정에서 직면한 가장 큰 문제 중 하나로 보안을 꼽았습니다. 각 마이크로 서비스에는 다양한 인프라 수준을 통해 다른 사람과 통신하기 위한 고유한 진입점이 있으므로 처음부터 보안을 적용해야 하며 이로 인해 애플리케이션이 공격에 노출될 가능성이 높아집니다. 게다가 인프라를 확장하면 애플리케이션 구성 요소에 대한 통제력과 가시성을 잃을 위험이 커집니다.

마이크로서비스를 사용하지 않을 때

마지막으로 마지막 질문입니다. 언제 마이크로서비스 아키텍처가 번거로울 가치가 있습니까? 클라우드 네이티브 애플리케이션에 자연스럽게 적합하다는 마이크로서비스 뒤의 소문은 모두 정당하지만 기본 스타일이 되어서는 안 됩니다. 문헌은 간단하게 설명합니다. 모놀리스로 시작하여 확장성 또는 리소스 소비 문제가 발생하거나 마이크로서비스 경로를 택하는 것을 정당화할 수 있는 기타 문제가 발생하면 모놀리스를 분할합니다.

다음은 마이크로서비스를 사용하지 않을 때의 핵심 팁입니다.

1. 당신이 스타트업이라면 마이크로서비스는 나쁜 생각입니다. 모놀리식 애플리케이션으로 시작하여 피자 2인분 팀에게 너무 까다로워지면 더 작은 구성요소로 나누는 것이 더 현명할 것입니다. 당신이 원하는 것은 고객 가치가 아직 검증되지 않은 제품을 위한 복잡한 아키텍처를 구축하는 데 많은 시간, 노력 및 돈을 투자하는 것보다 값싼 실험을 실행하는 것입니다. 모놀리스는 MVP를 테스트(및 폐기)하여 고객에게 가치를 가져다 줄 것이 무엇인지 빠르게 배울 수 있는 완벽한 방법입니다. 또 다른 저명한 마이크로서비스 전문가인 Martin Fowler는 다음과 같이 말합니다. ii) 처음부터 마이크로서비스 시스템으로 구축된 시스템에 대해 들어본 거의 모든 경우는 심각한 문제로 끝났습니다. 참고: 제품 도메인이 불확실한 경우 시작할 때 마이크로서비스를 사용해서는 안 됩니다. 복잡한 아키텍처 결정에 뛰어들기에는 너무 이르고 커뮤니케이션 설정에 대한 접근 방식이 있고 프로젝트가 성숙해지면 경계선에서 벗어나게 될 가능성이 있습니다.

2. 마이크로서비스는 복잡하지 않고 상대적으로 소규모 팀에서 유지 관리할 수 있는 솔루션에는 좋은 선택이 아닙니다. 회사의 이벤트 일정 도구를 위한 복잡한 마이크로서비스 아키텍처를 롤아웃하면 실제로 개발자를 즐겁게 할 수 있지만 모든 문제를 해결할 가치가 있습니까? 마이크로서비스는 우선 복잡성이라는 한 가지 문제를 해결하도록 설계되었습니다. Martin Fowler가 말했듯이 "모놀리식으로 관리하기에 너무 복잡한 시스템이 없다면 마이크로서비스를 고려하지 마십시오."

3. 애플리케이션이 너무 작아 정당화할 수 없다면 마이크로서비스를 선택하지 마십시오. 재고 관리 또는 구매 시스템이 있는 그대로 완벽하게 잘 작동한다면 마이크로서비스로 전환해야 합니까? 다시 한 번, 마이크로서비스를 사용한다는 아이디어는 복잡한 애플리케이션을 작은 서비스 세트로 나누는 것입니다. 이미 작고 간단한 코드를 분해하는 것은 복잡성을 추가하는 효과만 있을 것입니다. 이제 전체 장치를 구식 방식으로 배포하는 대신 많은 아티팩트로 모든 배포, 상호 운용성 및 디버깅 문제를 탐색해야 합니다.

그렇다면 언제 마이크로서비스를 사용하여 이점을 얻을 수 있을까요?

마이크로서비스는 위의 진술 중 하나라도 거짓일 때 의미가 있습니다. 다시 말해:

• 제품이 길들여져야 하는 복잡한 것으로 발전 하거나 변경 사항을 따라잡고 모놀리식 아키텍처 병목 현상으로 인해 구현할 수 없는 중요한 기능을 추가하려는 경우.
• 처음부터 정의된 범위로 크고 복잡한 제품을 빌드할 때. 회사에서 수십 명의 개발자를 조직하여 명확한 기능 세트를 갖춘 대규모 솔루션을 구축하고자 할 때마다 단일 구성 요소를 담당하는 소규모의 교차 기능 팀을 구성하는 것을 고려해야 합니다. 이러한 방식으로 모든 팀은 API 관리, 데이터 파이프라인, 스키마 및 기타 기능을 처리하는 전담 인력과 함께 독립적으로 작업할 수 있습니다.

ITRex 포트폴리오의 공정하고 실제 사례는 고객이 SaaS(Security-as-a-Service) 플랫폼으로 변환하기를 원하는 사내 사이버 보안 도구입니다. 모놀리식 아키텍처는 SaaS 솔루션이 점점 더 많은 고객에게 서비스를 제공하는 데 필요한 확장성이나 진화하고 해커보다 앞서 나갈 수 있는 유연성을 제공할 수 없기 때문에 마이크로서비스가 이 프로젝트에 자연스럽게 적합했습니다.

또 다른 예시적인 프로젝트는 글로벌 소매업체를 위한 AI 기반 빅 데이터 플랫폼이었습니다. 우리 고객은 처음부터 클라우드에 구애받지 않는 솔루션을 원했습니다. 플랫폼이 수많은 데이터를 처리할 것이며 향후 추가될 새로운 데이터 소스를 수용할 수 있도록 확장 가능하도록 설계되어야 한다는 것은 처음부터 분명했습니다. 또한 여러 외부 서비스와 통신을 구축해야 할 필요성도 고려해야 했습니다. 따라서 이 프로젝트에서 마이크로서비스의 이점을 깨닫는 것도 자연스러운 전략이었습니다. 마이크로서비스 아키텍처를 통해 우리는 마이크로서비스와 API를 오케스트레이션하기 위해 Kubernetes를 사용하여 이 복잡한 시스템을 원활하게 롤아웃할 수 있었습니다.

그리고 3D 카메라가 장착된 AI 구동 피트니스 미러와 사용자 장비에 IoT 센서가 부착된 ML 모델이 제공되었습니다. 관리자 패널, Android 앱 및 규칙 관리 시스템을 포함한 주요 구성 요소는 프로젝트의 서로 다른 단계에서 서로 다른 코드와 아키텍처를 사용하는 서로 다른 팀에 의해 구축되었습니다. 그것들을 모두 처리하는 복잡성이 압도적이 되었을 때 우리는 중앙 집중식 관리를 위해 하나의 백엔드를 구축해야 한다는 것을 이해했습니다. 그리고 코드를 재설계하고 새 데이터베이스를 생성하여 마이크로서비스로 변환했습니다. 중복 코드나 기능을 피하는 것과 같은 마이크로서비스 접근 방식을 사용하면 다른 이점이 있습니다.

따라서 우리의 경험에 따르면 증가하는 데이터 볼륨을 관리하거나 상호 운용 복잡성을 처리하거나 시스템이 비즈니스와 함께 발전할 만큼 충분히 유연해야 할 때 마이크로서비스를 사용하는 것이 좋습니다.

미주

기업이 시장에서 우위를 점하기 위해 마이크로서비스의 이점을 실현함에 따라 마이크로서비스 혁명이 진행되고 있습니다. 마이크로서비스의 이점을 통해 조직은 새로운 표준이 된 혼란 속에서 민첩하고 민첩하게 대처할 수 있습니다. 더 나은 소프트웨어를 더 빠르게 배포할 수 있기 때문에 "다음 단계" 이후의 모든 것에 대비할 수 있습니다. 소송을 따르기 전에 회사에서 사용할 수 있는 마이크로서비스 이점과 번거로움이 정당화되는지 여부를 아는 것이 중요합니다. 그 외에 마이크로서비스는 놀라운 일을 할 수 있습니다.

회사가 마이크로서비스의 이점에 빠져야 하는지 여전히 혼란스럽습니까? ITRex 컨설턴트에게 연락하십시오. 우리는 당신이 그것을 알아낼 수 있도록 도울 것입니다.

2022년 1월 10일 https://itrexgroup.com에 원래 게시되었습니다.