Nginx 를 사용하여 안전한 마이크로 서비스 아키텍처를 신속하게 구축하는 방법

오늘 우리는 마이크로서비스와 Nginx 를 사용하여 빠르고 안전한 네트워크 시스템을 구축하는 방법에 대해 이야기하고자 합니다. 마지막으로 Fabric pattern 을 사용하여 빠르고 쉽게 마이크로서비스 프레젠테이션을 구축하는 방법을 보여 드리겠습니다.

Fabric 모델에 대해 논의하기 전에, 저는 Nginx 의 관점에서 마이크로서비스와 그것이 무엇을 의미하는지 이야기하고 싶습니다.

0:56- 엄청난 변화

마이크로서비스는 애플리케이션 아키텍처의 중대한 변화를 불러일으켰다.

내가 처음으로 응용 프로그램을 만들기 시작했을 때, 그것들은 모두 동일했다. 슬라이드에 표시된 전체 아키텍처는 응용 프로그램이 구축되는 방식을 상징합니다.

현재 나에게는 정상적인 Java 인 가상 머신 (VM) 이 있다. 가상 시스템에 적용된 기능 구성 요소는 메모리 내에서 서로 통신하는 객체로 존재하며 앞뒤로 처리되고 메서드 호출을 수행합니다. 경우에 따라 알림과 같은 메커니즘을 사용하여 데이터를 얻거나 정보를 전송하기 위해 다른 시스템에 연락합니다.

마이크로서비스를 통해 응용 프로그램의 구축 패턴은 완전히 다릅니다. 기능 구성 요소는 가상 시스템을 통해 동일한 호스트의 메모리 내에서 서로 통신하는 것에서 컨테이너에 배포되는 것으로 변경되고 Restful API 호출을 사용하여 HTTP 를 통해 상호 연결됩니다.

이것은 매우 강력하다, 왜냐하면 그것은 너에게 기능을 격리시켜 주기 때문이다. 보다 세밀한 확장성을 제공하며 오류를 처리할 수 있는 유연성을 제공합니다. 많은 경우 이것은 간단한 사실입니다. HTTP 를 사용하여 네트워크를 통해 호출하기만 하면 됩니다.

자, 이 방법에는 몇 가지 단점이 있습니다.

일화

나는 어두운 비밀이 하나 있다. 저는 마이크로소프트 직원입니다. 계속 일해왔습니다. 넷은 여러 해 동안 개발되었다. 제가 그곳에 있을 때, Showcase 라는 비디오 출판 플랫폼을 만들었습니다.

Showcase 는 Microsoft 에서 출시한 모든 비디오를 인터넷에 게시하는 도구입니다. 사람들은 이 동영상을 보고 Microsoft Word 를 사용하는 기술과 기술을 배울 수 있다. 이것은 많은 사람들이 사용하는 매우 인기 있는 플랫폼이며, 그들 중 많은 사람들이 우리가 발표한 비디오에 대해 논평할 것이다.

Showcase 는 처음부터. Net 단일 응용프로그램이었습니다. 그것이 점점 더 인기를 끌면서, 우리는 그것이 SOA 아키텍처로 대체되어야 한다고 결정했다. 변환이 비교적 쉽다. Visual Studio 는 기본적으로 DLL 호출을 Restful API 호출로 변환하는 반전 스위치 기능을 제공합니다. 작은 재구성을 통해 코드를 잘 실행할 수 있습니다. 또한 무선 도시 서비스는 어플리케이션의 이러한 의견 및 커뮤니티 기능에 사용됩니다.

폐쇄 루프 문제

보아하니 우리는 SOA 가 실행할 수 있는 것 같다. 우리의 첫 번째 테스트에서 모든 것이 잘 작동했다. 시스템을 스테이지 환경으로 전환하고 운영 환경 데이터를 사용하기 시작할 때까지 몇 가지 심각한 문제가 나타납니다. 페이지에는 이러한 문제에 대한 많은 의견이 있습니다.

이것은 매우 인기 있는 플랫폼이며, 그것의 일부 페이지에는 최대 2000 개의 논평이 있다. 무선 도시 서비스는 먼저 사용자 이름을 입력한 다음 각 사용자 이름에 대해 사용자 데이터베이스에 대한 네트워크 호출을 시작하여 사용자 세부 정보를 얻고 렌더링된 페이지에 채워야 하기 때문에 이러한 페이지를 렌더링하는 데 1 분이 걸린다는 것을 알게 되었습니다. 이는 매우 비효율적이며 페이지를 렌더링하는 데 1 ~ 2 분이 걸리지만 메모리에는 보통 5 ~ 6 초 밖에 걸리지 않습니다.

릴랙스

문제를 발견하고 해결하는 과정을 거친 후, 우리는 결국 모든 요청을 그룹화하는 것과 같은 몇 가지 조치를 통해 최적화 시스템을 조정했습니다. 우리는 몇 가지 데이터를 캐싱했고, 결국 우리는 네트워크를 최적화했고, 실제로 성능을 향상시켰다.

그렇다면, 이것은 마이크로서비스와 어떤 관련이 있습니까? 네, 마이크로서비스를 이용하면 기본적으로 SOA 아키텍처를 사용하여 ftl 엔진에 넣는다. SOA 스키마에서 모든 객체는 단일 가상 시스템에 포함되어 내부적으로 관리되고 메모리 내에서 서로 통신합니다. 이제 마이크로서비스에서 HTTP 를 사용하여 데이터를 교환합니다.

이렇게 하면 문제가 없을 때 성능과 선형 확장성을 얻을 수 있습니다.

Nginx 는 마이크로 서비스와 잘 어울립니다.

Nginx 는 마이크로서비스로 전환하는 데 사용할 수 있는 최고의 도구 중 하나입니다.

Nginx 와 마이크로 서비스에 대한 몇 가지 역사. 우리는 처음부터 마이크로서비스 운동에 참여했는데, 최초로 Docker Hub 에서 앱을 다운받았다. Dell 고객 및 최종 사용자는 인프라에서 Nginx 를 광범위하게 사용하는 세계 최대의 마이크로서비스 설치를 보유하고 있습니다.

그 이유는 Nginx 가 작고, 빠르고, 안정적이기 때문입니다.

Nginx 마이크로 서비스 참조 아키텍처

한동안 우리는 Nginx 에서 마이크로서비스를 사용하기 위해 노력해 왔다. 이것은 스타일화된 Nginx 마이크로서비스 참조 아키텍처로, 이미 구축되어 현재 AWS 에서 실행되고 있습니다.

Dell 은 6 개의 핵심 마이크로서비스를 보유하고 있으며, 모두 Docker 컨테이너에서 실행됩니다. 각 컨테이너가 다른 언어를 실행할 수 있도록 다국어 응용 프로그램을 구축하기로 결정했습니다. 현재 우리가 사용하고 있는 것은 루비, 파이썬, PHP, 자바, 노드. Java 입니다.

우리는 12 요소 응용 프로그램을 사용 하 여 시스템을 구축, 약간 수정, 그것은 마이크로 서비스에 더 잘 사용 되며, Roku 플랫폼을 대체할 수 있습니다. 잠시 후 demo 에서 실제로 실행되는 어플리케이션을 보여드리겠습니다.

MRA 의 가치

왜 이런 참조 마이크로서비스 아키텍처를 구축해야 합니까?

Dell 은 고객에게 마이크로서비스 구축을 위한 청사진을 제공해야 하기 때문에 이 참조 아키텍처를 구축했습니다. 또한 마이크로서비스의 맥락에서 Nginx 와 Nginx Plus 의 기능을 테스트하고 그 장점을 더 잘 활용할 수 있는 방법을 찾고자 합니다. 마지막으로, 우리는 마이크로서비스 생태계와 그것이 우리에게 제공할 수 있는 것에 대한 깊은 이해를 확보해야 한다.

네트워크 문제

우리가 논의한 큰 변화로 돌아가 봅시다.

메모리에서 실행되는 가상 시스템 관리 어플리케이션의 모든 기능 구성 요소 마이그레이션에서 네트워크를 통한 상호 작업 및 통신에 이르기까지, 애플리케이션을 효율적으로 운영할 수 있도록 해결해야 할 일련의 문제를 근본적으로 도입하게 됩니다.

첫째, 서비스 검색이 필요하고, 둘째, 아키텍처의 모든 다른 인스턴스에 대해 로드 밸런싱을 수행해야 하며, 셋째, 성능과 보안에 대해 걱정해야 합니다.

좋든 나쁘든, 이 문제들은 분리할 수 없으니, 너는 반드시 따져봐야 한다. 우리가 이 모든 문제들을 해결할 수 있는 방법이 있기를 바랍니다.

각 문제를 좀 더 자세히 살펴 보겠습니다.

서비스 발견

서비스 발견에 대해 이야기 해 봅시다. 단일 응용 프로그램 내에서 응용 프로그램 엔진은 모든 객체 관계를 관리합니다. 너는 영원히 한 물체와 다른 물체의 상대적 위치를 걱정할 필요가 없다. 간단히 메서드를 호출하면 가상 시스템이 객체 인스턴스에 연결되고 호출 후 삭제됩니다.

마이크로서비스의 경우, 그 서비스의 위치를 고려해야 합니다. 불행히도, 이것은 일반적인 표준 절차가 아닙니다. 당신이 사용하고 있는 다양한 서비스 등록 센터는 Zookeeper, Consul, etcd 등 다양한 방식으로 작동합니다. 이 과정에서 서비스를 등록해야 하며, 이러한 서비스가 어디에 있는지, 어디에 연결할 수 있는지 읽을 수 있어야 합니다.

로드 밸런싱

두 번째 문제는로드 밸런싱에 관한 것입니다. 여러 서비스 인스턴스가 있는 경우 쉽게 접속하고, 요청을 효율적으로 분배하고, 가장 빠른 방식으로 실행할 수 있기를 원합니다. 따라서 인스턴스 간 로드 밸런싱은 매우 중요한 문제입니다.

불행히도 가장 간단한 로드 밸런싱 방법은 효율성이 매우 낮습니다. 로드 밸런싱을 위해 다양하고 복잡한 시나리오를 사용하기 시작하면 더욱 복잡해지고 관리가 어려워집니다. 개발자가 애플리케이션 요구 사항에 따라 사용할 로드 밸런싱 시나리오를 결정할 수 있기를 바랍니다. 예를 들어, 상태 있는 응용 프로그램에 연결하는 경우 세션 정보가 보존되도록 지속성이 필요합니다.

안전하고 빠른 통신

마이크로서비스에서 가장 두려움을 불러일으키는 분야는 성능과 보안일 수 있다.

메모리에서 실행할 때 모든 것이 빠르다. 지금 인터넷에서 뛰면 한 단계 늦는다.

일반적으로 이진 형식으로 시스템에 안전하게 저장되는 정보는 이제 네트워크를 통해 텍스트 형식으로 전송됩니다. 이제 네트워크에서 스니퍼를 보다 쉽게 스케줄링할 수 있으며 애플리케이션이 이동 중인 모든 데이터를 모니터링할 수 있습니다.

전송 계층에서 데이터를 암호화하려는 경우 접속 속도와 CPU 활용에 많은 오버헤드가 발생합니다. SSL/TLS 는 전체 구현 단계에서 요청을 초기화하는 9 단계가 필요합니다. 시스템이 매일 수천 개, 수만 개, 수십만 개 또는 수백만 개의 요청을 처리해야 할 때 성능에 중요한 장애물이 됩니다.

하나의 해결책

Dell 은 Nginx 에서 개발한 일부 솔루션이 이러한 모든 문제를 해결하여 강력한 서비스 검색, 사용자 구성 가능한 로드 밸런싱 및 안전하고 빠른 암호화를 제공할 것으로 믿습니다.

네트워크 아키텍처

네트워크 아키텍처를 설치 및 구성하는 다양한 방법에 대해 살펴보겠습니다.

우리는 상호 배타적이지는 않지만 다양한 형식에 속한다고 생각하는 세 가지 네트워크 모델을 제안했습니다. 이 세 가지 모드는 에이전트 모드, 라우터 메쉬 모드 및 패브릭 모드이며 가장 복잡하며 여러 가지 방법으로 헤더에서 로드 밸런싱을 수행합니다.

프록시 모드

에이전트 모드는 마이크로서비스 응용 프로그램의 인바운드 트래픽에 완전히 집중하고 실제로는 내부 통신을 무시합니다.

Nginx 가 제공하는 HTTP 트래픽 관리의 모든 이점을 얻을 수 있습니다. SSL/TLS 종료, 트래픽 성형 및 보안을 가질 수 있으며 최신 버전의 Nginx Plus 및 ModSecurity 를 통해 WAF 기능을 사용할 수 있습니다.

또한 Nginx 가 제공하는 단일 애플리케이션에 대한 모든 것을 마이크로 서비스 시스템에 추가하여 Nginx Plus 의 도움을 받아 서비스 검색을 수행할 수 있습니다. Nginx Plus 는 API 인스턴스가 위아래로 부동할 때 로드 밸런싱 도구에서 동적으로 증감할 수 있습니다.

라우터 메쉬 모드

라우터 메쉬 모드는 액세스 트래픽을 관리하는 프런트엔드 프록시 서비스가 있지만 서비스 간의 중앙 집중식 로드 밸런싱도 증가시키는 프록시 모드와 유사합니다.

각 서비스는 서로 다른 서비스 간의 접속 분포를 관리하는 중앙 집중식 라우터 그리드에 연결됩니다. 라우터 메쉬 모드를 사용하면 융합 모드를 구축하여 어플리케이션에 유연성을 높이고 실패한 서비스 인스턴스를 모니터링하고 회수하는 조치를 취할 수 있습니다.

불행히도, 이 모드는 추가 링크를 추가하므로 SSL/TLS 암호화를 수행해야 하는 경우 실제로 성능 문제가 악화됩니다. 이것이 직물 패턴을 도입한 이유이다.

구조 모드

Fabric 패턴은 머리 속의 모든 것을 뒤집는 패턴이다.

앞의 다른 두 모드와 마찬가지로 들어오는 트래픽을 관리하는 프록시 서버가 앞에 있지만 라우터 메시 모드와는 달리 중앙 집중식 라우터 대신 Nginx Plus 를 사용하여 각 컨테이너에서 실행됩니다.

이 Nginx Plus 인스턴스는 모든 HTTP 트래픽에 대한 역방향 및 전달 에이전트 역할을 합니다. 이 시스템을 통해 서비스 검색, 강력한 로드 밸런싱 및 가장 중요한 고성능 암호화 네트워크를 얻을 수 있습니다.

우리는 이것이 어떻게 일어났는지, 그리고 우리가 이 일을 어떻게 처리하는지 토론할 것이다. 서비스가 요청 구조를 연결하고 배포하는 일반적인 프로세스를 살펴보겠습니다.

정상적인 과정

이 사진에서 투자 관리자가 사용자 관리자와 통신하여 정보를 얻어야 한다는 것을 알 수 있습니다. 투자 관리자는 서비스 등록 센터에 DNS 요청을 시작하고 반환된 IP 주소를 가져온 다음 사용자 관리자에 대한 SSL/TLS 연결을 초기화하는 HTTP 클라이언트를 만듭니다. 이를 위해서는 9 단계 협상 또는' 핸드쉐이킹' 프로세스가 필요합니다. 데이터 전송이 완료되면 가상 시스템은 연결을 종료하고 HTTP 클라이언트에 대한 가비지 수집을 수행합니다.

이것이 전체 과정입니다. 이것은 간단하고 이해하기 쉽다. 이러한 단계로 분할하면 패턴이 실제로 요청 및 응답 프로세스를 완료하는 방법을 확인할 수 있습니다.

구조 모드에서는 이를 변경했습니다.

직물 패턴의 디테일

우선, Nginx Plus 는 각 서비스에서 실행되며 응용 프로그램 코드는 Nginx Plus 와 로컬로 통신합니다. 이러한 연결은 로컬 연결이므로 암호화에 대해 걱정할 필요가 없습니다. Java 또는 PHP 코드가 Nginx Plus 인스턴스에 대한 HTTP 요청일 수 있습니다. 모두 컨테이너의 로컬 HTTP 요청입니다.

또한 Nginx Plus 가 서비스 등록 센터에 대한 연결을 관리합니다. 우리는 모든 사용자 관리자 인스턴스를 얻기 위해 레지스트리의 DNS 인스턴스를 비동기적으로 쿼리하고 미리 연결을 설정하여 Java 서비스가 사용자 관리자에게 데이터를 요청해야 할 때 미리 설정된 연결을 사용할 수 있도록 하는 파서를 가지고 있습니다.

영구 SSL/TLS 연결

마이크로서비스 간의 상태, 지속성 및 암호화된 연결은 진정한 이점입니다.

첫 번째 그림에서 서비스 인스턴스가 HTTP 클라이언트 생성, SSL/TLS 연결 협상, 요청 시작 및 종료와 같은 프로세스를 어떻게 거쳤는지 기억하십니까? 여기서 Nginx 는 미리 마이크로서비스 간의 연결을 설정하고 Keepalive 기능을 사용하여 호출 간의 지속적인 연결을 유지하므로 요청마다 SSL/TLS 협상을 처리할 필요가 없습니다.

기본적으로 우리는 서비스에서 서비스까지 미니 VPN 연결을 만들었습니다. 초기 테스트에서 연결 속도가 77% 빨라진 것을 발견했습니다.

퓨즈정극

패브릭 모드와 라우터 메쉬 모드에서는 혼합 모드 작성 및 사용의 이점도 얻을 수 있습니다.

기본적으로 서비스 내에서 사전 예방적 상태 점검을 정의하고 서비스를 사용할 수 없을 때 데이터를 저장할 캐시를 설정함으로써 완벽한 fuse 기능을 제공합니다.

그래서, 이제 Fabirc 패턴이 멋지다고 생각하시는지 확인할 수 있습니다. 실제 환경에서 시도해보고 싶으실 겁니다. (존 F. 케네디, Northern Exposure (미국 TV 드라마), 예술명언)