Microservice : 사일로 깨기 위한 NGINX 가이드

해당 포스트에서는 ThermoFisher의 전 제품 소유자인 Carlos Ponce가 모놀리식 애플리케이션에서 탈피할 때의 이점과 NGINX Microservice 로 전환하기 위한 기본 단계에 대한 전문가 조언을 공유합니다.

모놀리식 애플리케이션은 대부분의 대규모 조직의 중추입니다. 비즈니스 운영에 중요한 안정적인 수익원을 창출하지만 개발, 릴리스 관리 및 프로젝트 관리를 위해 복잡한 프로세스 및 플랫폼에 연결되는 경우가 많습니다. 결과적으로 이러한 모놀리식 시스템 기능 블록(또는 사일로)은 오늘날 기업이 직면한 가장 큰 문제 중 하나입니다.

목차

1. 현대적 개발을 방해하는 엔터프라이즈 모놀리식
2. 속도는 생존의 중요한 요소입니다
3. NGINX Microservice를 시작하는 방법
 3-1. Microservice가 올바른 선택입니까?
 3-2. 올바른 구현 선택
 3-3. 올바른 파이프라인 구축

1. 현대적 개발을 방해하는 엔터프라이즈 모놀리식

개발팀이 새로운 기술과 소비자의 기대에 부응하기 위해 고군분투함에 따라 모놀리식 시스템은 혁신과 새로운 수익 창출의 장벽이 되었습니다.

Carlos는 “전통적인 조직은 비즈니스에서 상당한 수익을 창출하기 때문에 대규모 모놀리식 애플리케이션을 유지하는 경향이 있습니다.”라고 말합니다. “동시에 이러한 모놀리식은 현재 개발 프로세스를 차단하는 사일로 플랫폼에 연결됩니다.”

모놀리식의 크기와 범위가 커짐에 따라 일반적으로 코드가 밀접하게 결합되어 확장하거나 변경하기가 매우 어렵습니다. 

2. 속도는 생존의 중요한 요소입니다

이제 회사는 아이디어를 제품으로 얼마나 빨리 변환하고 고객을 위한 새로운 가치를 창출할 수 있는지에 따라 순위가 매겨집니다. 실제로 기업의 80%는 주로 고객 경험(CX)을 기반으로 경쟁할 것으로 예상합니다.

그리고 고통스러운 현실은 모놀리식 시스템이 지속적인 배포 및 제공을 방해하여 종종 애플리케이션 팀이 주요 시장 출시 기간을 놓치게 한다는 것입니다.

이와는 대조적으로 DevOps 및 애자일 방법론의 도움으로 기술 서비스를 제공하기 위한 조치를 취한 회사는 기준을 높였습니다.

예를 들어 Amazon은 약 10년 전에 물리적 서버를 Amazon Web Services(AWS) 클라우드로 이전했을 뿐만 아니라 DevOps로 전환했습니다.

2015년까지 그들은 개발, 테스트 및 생산 호스트에 대해 매일 5천만 건의 배포를 달성할 수 있었습니다. 이는 초당 평균 1건의 배포입니다. Amazon 개발자가 지금 무엇을 할 수 있는지 상상해 보십시오.

“1980년대의 제조 혁명과 유사합니다. 린 원칙을 채택하여 품질을 제어하고 더 나은 피드백을 수집하며 생산성을 높이는 데 도움이 되는 회사는 더 많은 시장 점유율을 얻었습니다. 남겨진 [회사]는 사업을 접거나 상당한 손실을 입었습니다.”라고 Carlos는 말합니다.

“오늘날에도 같은 이야기가 펼쳐지고 있습니다. 모든 것이 더 빠르고 안정적인 배포로 귀결됩니다. 대규모 모놀리식 애플리케이션을 보유한 회사는 필요할 때 새로운 기능을 제공할 수 없습니다.”

3. NGINX Microservice 를 시작하는 방법

미래에 성공하려면 지속적인 제공, 지속적인 실험 및 고객 피드백이 대규모 조직에 매우 중요합니다. 많은 사람들에게 이는 모놀리식 아키텍처에서 Microservice 로 이동하는 것을 의미합니다.

그렇다면 최선의 계획은 무엇입니까?

Carlos에 따르면 고려해야 할 세 가지 중요한 사항이 있습니다.

3-1. Microservice 가 올바른 선택입니까?

Microservice 로 전환하려면 매우 신중하고 철저한 계획이 필요하다는 것은 말할 필요도 없습니다. 그러나 올바른 선택인지 먼저 확인하는 것도 중요합니다.

모놀리식 분해는 상당한 엔지니어링 투자일 뿐만 아니라 보다 광범위한 구조적 전환을 필요로 합니다.

Carlos는 시간을 내어 한 걸음 물러나 정직하게 평가할 것을 권장합니다. “정말 노력할 가치가 있는지 신중하게 분석해야 합니다. 예를 들어 애자일 문화를 채택하지 않고 Microservice 를 구현한다면 이러한 전환 유형의 이점을 실제로 얻을 수 없을 것입니다.”

3-2. 올바른 구현 선택

회사가 Microservice 아키텍처로 이동하기로 결정할 때 애플리케이션 설계 및 아키텍처에서 가장 큰 변화는 기능 구성 요소와의 통신이 네트워크를 통해 발생한다는 것입니다. 이에 비해 모놀리식 애플리케이션은 메모리에서 통신합니다.

결과적으로 애플리케이션을 마이그레이션하거나 그린필드 프로젝트를 시작할 때 올바른 네트워크 설계 및 구현을 얻는 것이 중요합니다.

도움을 주기 위해 Carlos는 조직에서 Microservice 애플리케이션을 만드는 데 도움이 되는 NGINX Microservice 참조 아키텍처 (MRA)를 사용할 것을 제안합니다.

Carlos는 “NGINX는 Microservice 움직임이 시작된 이래로 존재해 왔습니다. 고성능, 경량 및 유연성을 갖추고 있어 Microservice 에 가장 적합합니다.”라고 설명합니다.

모델은 단순한 것부터 복잡한 것까지 다양합니다.

  • 프록시 모델(Proxy Model)  – NGINX Plus를 Microservice 애플리케이션용 컨트롤러 또는 API Gateway로 구현하는 데 적합한 간단한 네트워킹 모델입니다. 이것은 모놀리식 애플리케이션이 상당히 단순할 때 좋은 출발점입니다.
  • 라우터 메시 모델(Router Mesh Model)  – 각 호스트의 로드 밸런서와 시스템 간 연결 관리를 통해 네트워킹에 대한 보다 강력한 접근 방식입니다. 이것은 더 복잡한 모놀리스에 매우 적합합니다.
  • 패브릭 모델(Fabric Model)  – 이 모델에는 각 컨테이너에 Forward 및 Reverse 프록시 역할을 하는 NGINX Plus가 있습니다. 고부하 시스템에서 잘 작동하고 모든 수준에서 SSL/TLS를 지원하며 NGINX Plus는 서비스 검색, 대기 시간 감소 및 지속적인 SSL/TLS 연결을 제공합니다.

3-3. 올바른 파이프라인 구축

Carlos는 클라우드 네이티브 앱 및 아키텍처의 이점을 진정으로 활용하려면 강력한 CD(지속적 배포) 파이프라인을 갖추는 것이 필수적이라고 생각합니다.

많은 기업이 DevOps를 활용하여 더 빠른 속도로 애플리케이션을 제공하는 데 관심을 갖게 되었으며 전담 팀에서 End-to-End 제공 주기에 대해 더 많은 책임을 지는 보다 자율적인 팀으로 이동했습니다.

NGINX Plus는 다음을 제공하여 DevOps를 지원합니다.

  • 배포 파이프라인에 직접 통합할 수 있는 상태 지표의 JSON 피드와 함께 애플리케이션 상태에 대한 실시간 피드백을 제공하는 맞춤형 모니터링.
  • 백엔드 서버 그룹을 동적으로 재구성하여 지속적인 배포를 지원하므로 구성 파일을 수동으로 다시 작성하고 다시 로드하지 않고도 백엔드 서버를 자동으로 검색 할 수 있습니다.
  • 로드 밸런싱 자동화는 Ansible, Chef 및 Puppet과 같은 DevOps 도구로 구성을 자동화할 수 있는 유연성과 구성 가능성을 제공합니다.

NGINX Plus가 모놀리식 애플리케이션을 분리하고 DevOps 접근 방식을 지원하는 데 어떻게 도움이 되는지 자세히 알아보려면 NGINX Plus의 30일 무료 평가판을 시작하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.