마이크로서비스란 무엇입니까?

마이크로서비스는 마이크로서비스 아키텍처라고도 하며 애플리케이션을 결합된 서비스 모음으로 구성하는 소프트웨어 개발 방법을 나타냅니다. 기본적으로 이 애플리케이션 제품군은 그 자체로 완전한 애플리케이션으로 배포되며 이러한 서비스는 모두 함께 작동하여 전체 애플리케이션을 구성합니다. 마이크로서비스는 모두 다음 패턴을 따릅니다. 비즈니스 기능을 중심으로 구성되고 느슨하게 연결되어 있으며 독립적으로 배포할 수 있으며 테스트할 수 있습니다. 느슨하게 결합되어 있기 때문에 마이크로서비스를 독립적으로 구축, 배포 및 확장할 수 있습니다.

각 서비스는 표준화된 API(애플리케이션 프로그래밍 인터페이스)를 통해 다른 서비스와 통신하므로 서비스들을 서로 다른 언어 또는 다른 기술로 작성할 수 있습니다. 이는 서비스가 불가분하게 상호 연결되고 함께 확장될 수만 있는 단일 구조로 구축된 시스템과 완전히 다릅니다.

각 서비스에는 일반적으로 단순한, 제한된 기능만을 가지기 때문에 크기와 복잡성이 훨씬 더 작습니다. 마이크로서비스라는 용어는 이와 같은 분리된 기능 설계에서 유래되었습니다.

마이크로서비스는 애플리케이션을 특정 비즈니스 기능을 구현하는 개별 서비스로 분해함으로써 현시대 개발자에게 확장성이 뛰어나고 유연한 애플리케이션을 설계할 수 있는 방법을 제공합니다.

마이크로서비스를 사용하는 이유는 무엇인가요?

마이크로서비스는 그것의 모듈식 특성으로 하여 유연성, 확장성 및 개발 노력 감소를 달성할 수 있기 때문에 인기가 높아졌습니다. 배포 유연성과 클라우드 네이티브 서버리스 및 FaaS( 서비스형 기능) 배포 옵션(예: AWS Lambda 및 Microsoft Azure Cloud Functions)의 출현은 오늘날의 IT 환경에서 마이크로서비스가 번창할 수 있는 완벽한 환경으로 되었습니다. 이러한 클라우드 플랫폼을 사용하면 고객이 사용하는 컴퓨팅 용량에 대해서만 비용을 지불하면서 마이크로서비스와 기능을 비활성 상태에서 대용량으로 확장했다가 다시 되돌릴 수 있습니다.

기업이 보다 민첩하려고 하고 병목 현상을 줄이며 애플리케이션 제공 시간을 개선하기 위해 지속적으로 노력함에 따라 마이크로서비스 아키텍처의 인기가 계속 높아지고 있습니다.

지난 시기 기업은 다음과 같은 세 가지 주요 요소로 구성된 특수 엔터프라이즈 애플리케이션을 개발했습니다.

• 일반적으로 사용자 컴퓨터에서 실행되는 HTML 페이지인 클라이언트 대면 인터페이스
• 일반적으로 관계형 데이터베이스 관리 시스템의 많은 테이블로 구성된 데이터베이스
• 데이터 검색, HTTP 요청 및 HTML 브라우저 채우기와 같은 모든 요청을 처리하는 서버 측 애플리케이션.

사용자의 관점에서는 모든 것이 단일 접점을 통해 진행되는 것처럼 나타납니다. 개발, 테스트 및 배포는 배포 파이프라인을 사용했으며 사용자는 여러 인스턴스를 실행하여 수평으로 확장할 수 있습니다.

그러나 개발하는 데 비용이 상당히 많이 들었고 모든 변경에는 전체 시스템 재설계, 재구축 및 재배포가 따르며 조직이 성장하고 변경됨에 따라 깨끗한 모듈식 구조를 유지하기가 어려웠고 확장하려면 전체 애플리케이션을 다시 테스트하고 확장해야 했습니다. 그리고 아무리 작은 수정이라도 모든 변경 사항에 대해 재배포해야 했습니다. 이러한 모든 문제로 인해 시스템은 비용이 많이 들고 민첩하지 않았으며 이로부터 급속히 변화하는 기술 환경이 빠르게 성장하였습니다.

이러한 전통적인 단일 시스템을 연상시키는 가지 방법은 기성품 인형의 집입니다. 구조나 레이아웃을 편집할 수는 있지만 쉬운 일이 아니며 다른 인형의 집을 사서 기존 인형의 집에 붙이지 않는 한 전체 크기에 제한이 있습니다.

마이크로서비스를 사용하면 전체 애플리케이션을 재배포하지 않고 필요한 서비스만 재배포할 수 있습니다. 인형의 집과 같은 단일한 구조적 실체 대신 마이크로서비스를 레고 브릭 더미로 생각하십시오. 기술적으로는 모두 독립적이지만 함께 모이면 전체 구조적 애플리케이션을 형성합니다. 구획을 추가하거나 무언가를 종료하려는 경우 전체 애플리케이션을 종료하지 않고도 변화하는 요구 사항에 맞게 빠르고 효율적으로 제거, 추가, 확장 및 편집할 수 있습니다.

마이크로서비스 아키텍처의 이점

마이크로서비스를 채택하고 이를 제품에 통합하려는 기업에는 여러 가지 중요한 이점이 있습니다. 이에 대해서는 아래에서 더 자세히 살펴보겠습니다.

시장 출시 시간 단축

기능을 빠르게 추가 및 제거할 수 있다는 것은 비즈니스가 엄청나게 민첩해질 수 있다는 것을 의미합니다. 기업은 비즈니스 성장에 발맞추어 새로운 기능을 빠르게 추가할 수 있습니다. 기존의 단일 소프트웨어와 달리 시스템의 한 부분에서 코드를 변경해도 다른 모듈에는 영향을 미치지 않으므로 추가 테스트, 전체 애플리케이션 종료 또는 모든 것을 재배포할 필요가 없습니다.

기능 향상 및 운영 비용 절감

마이크로서비스의 모듈은 모두 분리되어 있기 때문에 잠재적인 버그나 오류로 인해 전체 애플리케이션이 실패할 위험이 훨씬 적습니다. 기능의 한 부분이 변경되면 다른 부분에서 결함이나 버그가 발생할 수 있는 기존 소프트웨어 시스템과 달리 격리 및 느슨한 결합을 통해 구획화된 업그레이드 및 개선 사항을 구현할 수 있습니다. 또한 마이크로 서비스를 통해 클라우드 네이티브 서비스로서의 기능 구축 옵션을 사용할 수 있으므로 운영 비용을 크게 절감할 수 있습니다.

쉽게 확장 가능한 애플리케이션

마이크로 서비스에 대한 확장 결정은 세분화된 수준에서 이루어지므로 시스템 최적화를 위한 가장 효율적인 결정을 내릴 수 있습니다. 조직은 마이크로서비스를 채택함으로써 규모를 확장해야 할 바로 그 순간에 가장 적합한 선택을 할 수 있습니다.

지속적 통합

마이크로서비스는 개별적인 지속적인 개발 및 배포 스트림을 사용하여 개발합니다. 이러한 스트림은 한 팀이 고객 피드백에 따라 변경을 적용할 때 다른 서비스에 중단이 없도록 유지될 수 있으므로 최종 사용자 만족도가 더 높아집니다.

전담 개발자 팀

여러 개발 팀을 유지할 수 없는 단일 시스템과 달리 마이크로서비스는 시스템의 특정 부분을 전담하는 팀을 지원할 수 있습니다. 소프트웨어 모듈은 서로 상호 작용하지 않기 때문에 버그나 팀 간 작업이 중복될 위험이 없으므로 마이크로서비스 팀은 전문 소프트웨어 개발자는 물론 서로 다른 시간대 또는 지리적 위치에서 작업하는 팀을 보유할 수 있습니다.

이러한 모든 이점은 아마도 가장 중요한 이점인 비즈니스 민첩성으로 귀결됩니다. 작고 간단한 변경도 신속하게 수행할 수 있어 프로세스 실험이 가능합니다. 비즈니스에서 큰 도약을 하거나 실패를 최소화하고 빠르게 실시간으로 대응하는 능력은 마이크로서비스를 통해 가능해집니다. 또한 연구에 따르면 마이크로서비스 아키텍처를 배포한 후 몇 개월 이내에 조직의 1/3이 이점을 얻기 시작합니다. 즉, 개발 기간이 단축되고 코드 오류가 적고 기능이 향상되어 비즈니스 운영에 대한 긍정적인 영향을 거의 즉시 느낄 수 있습니다.

마이크로서비스의 특징

• 느슨한 결합
• 독립적으로 배포 가능한 구성 요소
• 자동화된 배포
• 분산 데이터 및 언어 제어
• 유지 보수 용이성
• 쉽게 테스트 가능
• 비즈니스 또는 조직의 필요와 능력을 중심으로 구성
• 각 서비스는 보통 소규모 팀이 소유

마이크로서비스의 도전 과제

마이크로서비스는 많은 문제를 해결하지만 아키텍처를 통해서뿐만 아니라 초기 채택에서 직면할 수 있는 몇 가지 어려움과 문제가 여전히 남아있습니다.

분산 데이터 관리

단일 시스템과 달리 마이크로서비스는 일반적으로 회사 데이터의 단일 소스 역할을 하는 하나의 데이터베이스에 의존하지 않습니다. 고객 데이터는 한 위치에 있고 공급업체 데이터는 다른 위치에 있을 수 있습니다. 재고 정보는 온라인 판매 포털에 저장되지만 주문 시스템은 별도의 데이터베이스에 보관됩니다. 이에 대한 구체적인 계획을 세우지 않는 한, 이로 인해 데이터 품질 및 일관성에 문제가 발생할 수 있습니다.

기업 문화 및 조직 내부 도전과제

기업이 새로운 소프트웨어 시스템을 수용하고 적응하도록 하는 것은 어려울 수 있습니다. 종종 경영진은 통제권 포기를 꺼려할 수 있으며 부서는 자기의 사일로를 방어할 것입니다. 새로운 시스템을 수용해야 하는 팀의 반발에 대한 이유가 무엇이든 간에 결론은 때때로 사람들은 변화를 좋아하지 않는다는 것입니다.

조직 전체에서 마이크로서비스를 채택하도록 하려면 새로운 시스템과 프로세스를 도입하는 것이 파괴적일 수 있다는 점을 인식하는 것이 중요하지만 이점이 그만한 가치가 있음을 알려주는 것 또한 중요합니다. 마이크로서비스로의 전환을 시작할 때 아키텍처 계획시 영향을 받는 팀을 참여시키는 것이 가장 좋습니다. 사용 가능한 솔루션을 평가할 계획을 세우고 비즈니스 요구 사항에 가장 적합한 솔루션을 선택했는지 확인하십시오.

마이크로서비스로 인해 아키텍처가 복잡해질 수 있음

마이크로서비스를 구성하는 개별 서비스는 그 자체로 작고 단순할 수 있지만, 결합할 경우 애플리케이션 전반에서 관리하기 어려운 이동 부분이 많아질 수 있습니다. 수백 또는 수천 개의 상호 연결이 있는 마이크로서비스에서는 복잡성이 빠르게 증가할 수 있습니다.

마이크로 서비스를 구현할 때 충분한 사전 고려와 계획을 설계 및 기본 구현에 적용하는 것이 좋습니다. 미래의 성장과 변화를 허용하는 훌륭한 기본 아키텍처 설계를 사용하면 많은 복잡성을 피할 수 있습니다.

마이크로서비스 아키텍처 사용 사례

클라우드 네이티브 배포 옵션 채택: 보다 효율적이고 확장 가능한 운영을 위해 서버리스 및 FaaS(서비스형 기능)를 활용합니다.

레거시 애플리케이션의 기능 마이그레이션: 대규모 단일 애플리케이션에서 서비스를 분해하여 독립적으로 유지 관리하고 확장할 수 있습니다.

최신 애플리케이션 아키텍처 활용: 이벤트 기반의 느슨하게 연결된 마이크로서비스 애플리케이션 패턴을 수용하고 사용 사례 요구 사항에 따라 다양한 프로그래밍 언어를 활용할 수 있습니다. 예를 들어, 계산량이 많은 기능, 빠른 웹 개발에는 Node.js 등을 사용하십시오.

DevOps란 무엇이며 종종 마이크로서비스와 연결되는 이유는 무엇입니까?

DevOps는 도구 중심의 이데올로기로 설명할 수 있습니다. 기본적으로 도구와 기술을 결합하여 개발자가 수행해야 하는 작업을 단순화하는 일련의 관행입니다. 개선된 도구와 함께 운영 팀과 개발 팀 간의 협력을 통해 프로젝트를 더 빠르고 효율적으로 완료할 수 있습니다.

예를 들어, 사용자가 계정 잔액을 확인할 수 있는 애플리케이션을 구축한다고 가정해 보겠습니다. 지난 시기에는 종종 앱 개발 주기에서 개발자가 앱을 빌드한 다음 최종 결과에 대한 책임 없이 운영 팀에 전달했습니다. 앱이 작동하도록 하는 것은 운영 팀의 일이었습니다. 보다 응집력 있는 DevOps 환경에서는 양쪽이 함께 책임집니다. 개발자는 처음부터 끝까지 앱의 수명 주기를 소유합니다. 즉, 릴리스 중에 대기 상태가 됩니다. 모든 것이 성공하고 시장 출시 속도, 더 쉬운 개발 주기, 더 많은 책임과 같은 DevOps의 모든 이점을 얻으려면 두 그룹 간의 일관된 커뮤니케이션이 필요합니다.

새로운 DevOps 워크플로 모델은 주요 문화적 변화를 만듭니다. 새로운 도구를 사용한다고 해서 DevOps 계획이 성공하는 것은 아닙니다. 새로운 도구가 모든 것이 적절하게 구현될 것이라고 의심도 하지 않고 믿는 것은 성공의 방해물일 수 있습니다.

마이크로 서비스의 특성으로 인해 배포를 위해 강력한 DevOps 프로세스가 필요한 경우가 많습니다. 도구 사용의 증가와 더욱 강력한 공유 방식은 팀이 모든 작은 이동 부분에 압도되는 것을 덜어줍니다. 계속해서 혜택을 받으면서 이러한 변화로 인한 중단이나 부담을 줄일 수 있습니다.

미래: 이벤트 기반 마이크로서비스, 서버리스 컴퓨팅 및 FaaS

사람들이 처음 마이크로서비스 실험을 시작할 때 RESTful API와 같은 친숙한 기술을 사용하는 경우가 많습니다. REST는 요청-응답 유형의 통신에서 작동합니다. 이 동기식 접근 방식의 문제는 응답을 기다려야 하기 때문에 서비스가 서로 종속된다는 것입니다. 즉, 한 서비스가 느리게 실행되거나 응답하지 않으면 이를 호출한 서비스가 더 느리게 실행되거나 실패하게 됩니다. 이러한 결합은 마이크로서비스 아키텍처의 이점 중 일부를 상실하여 SOA(서비스 지향 아키텍처) 스타일과 유사한 더 상호 의존적인 구조가 생성될 수 있습니다.

REST 이상 또는 이벤트 기반 모델을 사용하여 서비스를 설계하는 경우 전체 애플리케이션이 응답하지 않는 것과 달리 애플리케이션의 일부는 계속 작동하고 다른 부분은 작동과 관련되지 않을 수 있습니다. Netflix는 이에 대한 완벽한 예입니다. 경우에 따라 "계속 시청" 버튼이 표시되지 않는 경우가 있습니다. 특정 서비스를 사용할 수 없기 때문입니다. 그러나 그렇다고 해서 모든 Netflix가 중단되는 것은 아닙니다. 사용자는 프로그램 탐색 및 미리보기를 계속할 수 있으므로 한 서비스를 사용할 수 없다고 해도 Netflix 서비스의 다른 측면은 여전히 작동합니다.

마이크로서비스 접근 방식을 완전히 수용하는 개발자는 느슨한 결합 및 이벤트 기반 아키텍처를 통해 진정한 확장성을 실현할 수 있음을 알고 있습니다. 서비스는 비동기식으로 동작을 수행하고 메시지를 브로드 캐스팅하고 다른 서비스의 응답을 기다릴 필요없이 기본 기능을 계속할 수 있습니다.

마이크로서비스는 어떻게 작동합니까?

마이크로서비스는 새로운 아이디어가 아닙니다. 30여 년 전 Unix는 이와 유사한 설계 원칙을 사용하여 SOA를 개발했지만 구현하는 데 비용이 많이 들고 기업을 위한 적합한 옵션으로 간주되지 못했습니다. 20년 후, 마이크로서비스는 서비스 전반에 걸쳐 훨씬 더 나은 일관성을 갖게 되었고 그 이후로 훨씬 더 성공적으로 채택되었습니다.

마이크로서비스가 실제로 작동하는 방식을 보면 먼저 소프트웨어 기능이 작고 격리된 모듈로 나뉩니다. 이러한 모듈에는 독립 실행형 작업이 정의되어 있습니다. 그런 다음 시스템은 API(애플리케이션 프로그래밍 인터페이스)를 사용하여 이러한 작은 소프트웨어 조각을 함께 연결하여 작동합니다.

API는 서로 관련이 없는 두 프로그램이 서로 '대화'하도록 하는 코드 세그먼트입니다. 실행 중인 API의 한 가지 예로는 Google 지도가 내장된 앱이나 웹사이트를 들 수 있습니다. API는 Google 지도와 정보를 주고받는 앱 사이에 위치하여 사용자가 실시간으로 지도를 보고, 운전자에게 지침을 제공하고, 신뢰할 수 있는 연락처에 귀하의 위치를 알릴 수 있도록 합니다. Google 지도는 별도의 엔터티로 남아 있지만 API를 사용하면 지도와 앱 간의 통신이 가능합니다. 따라서 모든 것이 계획되고 단단하며 변경하기 어려운 조립식 인형의 집 대신 API를 커넥터로 사용하여 함께 클릭하는 유용한 작은 레고 조각을 소유하게 됩니다. 표준화된 기술 플랫폼은 제한적일 수 있지만 모든 문제가 못일 수 없고 모든 해결법이 망치일 수는 없습니다. 마이크로서비스를 통해 작업에 적합한 도구를 사용할 수 있습니다.

마이크로서비스에는 고유한 이점이 있으며, 아키텍처 모델로 마이크로서비스를 성공적으로 채택한 회사는 더 빠르고 민첩한 비즈니스 IT 구조의 이점을 얻었습니다. 그러나 일부 조직에서는 시스템이 생산성을 저해하고 운영 부담이 크다는 사실을 알게 되었습니다. 성공과 실패의 차이는 두 부분에 있습니다. 조직의 문화와 마이크로서비스를 수용하고 사용하려는 의지, 그리고 마이크로서비스 지도에 담긴 계획과 사전 생각입니다.

종종 새로운 시스템의 진정한 이점이나 비용은 수년 동안 실현되지 않습니다. 단일 아키텍처는 때때로 이미 지나치게 성장했거나 쇠퇴하기 시작했습니다. 마이크로서비스 내에서 이러한 부패 가능성이 적고 문제를 패치하는 것이 훨씬 더 간단한 문제입니다.

이러한 다양한 잠재적 문제에 대한 한 가지 솔루션은 단일체로 시작하는 것입니다. 이를 통해 기본 소프트웨어는 확장에 따라 다른 것을 볼트로 고정하여 레고 확장 기능이 있는 인형의 집을 만들 수 있습니다. 이것이 가장 우아한 접근 방식은 아닐지라도, 특히 운영의 중심에 있는 기존 데이터베이스나 프로그램을 중심으로 비즈니스가 진행될 수 있는 방법입니다.