NDC 런던 컨퍼런스. 마이크로서비스 재해를 예방합니다. 1 부

모놀리스를 마이크로서비스로 재설계하는 데 수개월을 보냈고 마침내 모두가 함께 모여 스위치를 전환했습니다. 첫 번째 웹페이지로 이동하면... 아무 일도 일어나지 않습니다. 다시 로드하면 아무 소용이 없습니다. 사이트가 너무 느려서 몇 분 동안 응답하지 않습니다. 무슨 일이에요?

강연에서 Jimmy Bogard는 실제 마이크로서비스 재해에 대한 "사후 분석"을 실시할 예정입니다. 그는 자신이 발견한 모델링, 개발 및 생산 문제와 그의 팀이 어떻게 새로운 분산형 단일체를 온전한 최종 그림으로 천천히 변화시켰는지 보여줄 것입니다. 설계 오류를 완전히 방지하는 것은 불가능하지만 최소한 설계 프로세스 초기에 문제를 식별하여 최종 제품이 안정적인 분산 시스템이 되도록 할 수 있습니다.

안녕하세요 여러분, 저는 Jimmy입니다. 오늘 여러분은 마이크로서비스를 구축할 때 대규모 재해를 피할 수 있는 방법에 대해 듣게 될 것입니다. 이것은 배가 빙산과 충돌하는 것을 방지하기 위해 약 90년 반 동안 일한 회사의 이야기입니다. 이 이야기를 제대로 전달하려면 시간을 거슬러 올라가 이 회사가 어디서 시작했는지, 시간이 지남에 따라 IT 인프라가 어떻게 성장했는지 이야기해야 합니다. 이번 재난에서 무고한 이들의 이름을 보호하기 위해 나는 이 회사의 이름을 벨컴퓨터로 바꾸었습니다. 다음 슬라이드에서는 XNUMX년대 중반 이러한 기업의 IT 인프라가 어떤 모습이었는지 보여줍니다. 이는 컴퓨터 철물점 운영을 위한 대규모 범용 내결함성 HP Tandem 메인프레임 서버의 일반적인 아키텍처입니다.

그들은 모든 주문, 판매, 반품, 제품 카탈로그, 고객 기반을 관리할 수 있는 시스템을 구축해야 했기 때문에 당시 가장 일반적인 메인프레임 솔루션을 선택했습니다. 이 거대한 시스템에는 회사에 대한 모든 정보와 가능한 모든 정보가 포함되어 있으며 모든 거래가 이 메인프레임을 통해 수행되었습니다. 그들은 모든 달걀을 한 바구니에 담아두었고 그것이 정상이라고 생각했습니다. 여기에 포함되지 않은 유일한 것은 우편 주문 카탈로그와 전화 주문입니다.

시간이 지남에 따라 시스템은 점점 더 커지고 그 안에 엄청난 양의 쓰레기가 쌓였습니다. 또한 COBOL은 세계에서 가장 표현력이 뛰어난 언어가 아니기 때문에 시스템은 결국 크고 단일한 쓰레기 조각이 되었습니다. 2000년에 그들은 많은 회사들이 웹사이트를 통해 모든 비즈니스를 수행한다는 사실을 알고 최초의 상업용 닷컴 웹사이트를 구축하기로 결정했습니다.

초기 디자인은 꽤 괜찮아 보였고 최상위 사이트 bell.com과 개별 애플리케이션을 위한 여러 하위 도메인(catalog.bell.com, account.bell.com,orders.bell.com, 제품 검색 search.bell)으로 구성되었습니다. com.com. 각 하위 도메인은 ASP.Net 1.0 프레임워크와 자체 데이터베이스를 사용했으며 모두 시스템 백엔드와 통신했습니다. 그러나 모든 주문은 모든 쓰레기가 남아 있는 하나의 거대한 메인프레임 내에서 계속 처리되고 실행되었지만 프런트 엔드는 개별 애플리케이션과 별도의 데이터베이스가 있는 별도의 웹사이트였습니다.

그래서 시스템의 디자인은 질서정연하고 논리적으로 보였지만 실제 시스템은 다음 슬라이드와 같았습니다.

모든 요소는 서로에 대한 호출, 액세스된 API, 내장된 타사 DLL 등을 처리했습니다. 버전 제어 시스템이 다른 사람의 코드를 가져와 프로젝트 내부에 밀어 넣으면 모든 것이 중단되는 경우가 종종 있었습니다. MS SQL Server 2005에서는 링크 서버라는 개념을 사용했는데, 슬라이드에 화살표를 표시하지는 않았지만, 여러 데이터베이스에서 얻은 데이터를 기반으로 테이블을 구성하는 데에는 문제가 없기 때문에 각 데이터베이스도 서로 통신을 했습니다.

이제 시스템의 서로 다른 논리적 영역이 어느 정도 분리되었기 때문에 이는 분산된 먼지 덩어리가 되었으며 가장 큰 쓰레기 조각은 여전히 ​​메인프레임 백엔드에 남아 있습니다.

재미있는 점은 이 메인프레임이 Bell Computers의 경쟁업체에 의해 구축되었으며 여전히 해당 기술 컨설턴트에 의해 유지 관리된다는 것입니다. 자사 애플리케이션의 성능이 만족스럽지 못하다고 확신한 회사는 해당 애플리케이션을 제거하고 시스템을 재설계하기로 결정했습니다.

기존 응용 프로그램은 15년 동안 생산되었으며 이는 ASP.Net 기반 응용 프로그램 중 기록입니다. 이 서비스는 전 세계의 주문을 받아들였으며, 이 단일 애플리케이션의 연간 수익은 XNUMX억 달러에 달했습니다. 수익의 상당 부분은 bell.com 웹사이트에서 창출되었습니다. 블랙 프라이데이에는 사이트를 통한 주문 건수가 수백만 건에 달했습니다. 그러나 기존 아키텍처에서는 시스템 요소의 견고한 상호 연결로 인해 실제로 서비스 변경이 허용되지 않았기 때문에 개발이 허용되지 않았습니다.

가장 심각한 문제는 이러한 거래 계획이 글로벌 기업에서 매우 일반적이라는 사실에도 불구하고 한 국가에서 주문을 하고 다른 국가에서 비용을 지불하고 제XNUMX국으로 보낼 수 없다는 것입니다. 기존 웹사이트에서는 이런 것이 허용되지 않아 전화로 주문을 접수하고 접수해야 했습니다. 이로 인해 회사는 아키텍처 변경, 특히 마이크로서비스로의 전환에 대해 점점 더 많이 생각하게 되었습니다.

그들은 비슷한 문제를 어떻게 해결했는지 알아보기 위해 다른 회사를 살펴보는 현명한 일을 했습니다. 이러한 솔루션 중 하나는 API와 외부 데이터베이스를 통해 연결된 마이크로서비스로 구성된 Netflix 서비스 아키텍처였습니다.

Bell Computers 경영진은 특정 기본 원칙을 준수하면서 이러한 아키텍처를 구축하기로 결정했습니다. 첫째, 공유 데이터베이스 접근 방식을 사용하여 데이터 중복을 제거했습니다. 데이터가 전송되지 않았고, 반대로 데이터가 필요한 모든 사람이 중앙화된 소스로 이동해야 했습니다. 그 다음에는 격리와 자율성이 뒤따랐습니다. 각 서비스는 다른 서비스와 독립적이었습니다. 그들은 절대적으로 모든 것에 웹 API를 사용하기로 결정했습니다. 데이터를 가져오거나 다른 시스템을 변경하려는 경우 모두 웹 API를 통해 수행되었습니다. 마지막으로 중요한 점은 경쟁사의 하드웨어를 기반으로 한 "Bell" 메인프레임과 달리 "Bell on Bell"이라는 새로운 메인프레임이었습니다.

그래서 18개월에 걸쳐 이러한 핵심 원칙을 중심으로 시스템을 구축하고 사전 제작 단계에 이르렀습니다. 주말을 마치고 업무에 복귀한 개발자들은 함께 모여 새 시스템이 연결된 모든 서버를 켰습니다. 18개월의 작업, 수백 명의 개발자, 가장 현대적인 Bell 하드웨어 - 긍정적인 결과는 없습니다! 많은 사람들이 이 시스템을 랩탑에서 여러 번 실행했지만 모든 것이 괜찮았기 때문에 이것은 많은 사람들을 실망시켰습니다.

그들은 이 문제를 해결하는 데 모든 돈을 투자하는 것이 현명했습니다. 그들은 스위치가 있는 가장 현대적인 서버 랙을 설치하고, 엄청난 양의 RAM을 갖춘 가장 강력한 서버 하드웨어인 기가비트 광섬유를 사용하고, 모든 것을 연결하고 구성했지만, 다시 한 번 아무것도 하지 않았습니다! 그런 다음 그들은 그 이유가 시간 초과일지도 모른다고 의심하기 시작하여 모든 웹 설정, 모든 API 설정으로 이동하여 전체 시간 초과 구성을 최대 값으로 업데이트하여 그들이 할 수 있는 일은 앉아서 무언가가 일어나기를 기다리는 것뿐이었습니다. 사이트에. 그들은 웹사이트가 마침내 로드될 때까지 9분 XNUMX초를 기다리고 또 기다리고 또 기다렸습니다.

그 후 현 상황에 대한 철저한 분석이 필요하다는 점을 깨닫고 우리를 초대해 주셨습니다. 우리가 가장 먼저 알아낸 사실은 18개월의 개발 기간 동안 단 하나의 실제 "마이크로"가 생성되지 않았다는 것입니다. 모든 것이 더 커졌을 뿐입니다. 이후 우리는 재난의 원인을 파악하기 위해 '뇌폭풍'과 비슷한 '비난 폭풍'이라고도 알려진 '회고', '슬픈 회고'라고도 불리는 사후 부검을 쓰기 시작했습니다.

우리는 몇 가지 단서를 얻었는데 그 중 하나는 API 호출 당시 트래픽이 완전히 포화되었다는 것이었습니다. 모놀리식 서비스 아키텍처를 사용하면 오류를 일으킬 수 있는 모든 것을 보고하는 단일 스택 추적이 있기 때문에 정확히 무엇이 잘못되었는지 즉시 이해할 수 있습니다. 여러 서비스가 동일한 API에 동시에 액세스하는 경우 WireShark와 같은 추가 네트워크 모니터링 도구를 사용하는 것 외에는 추적을 추적할 수 있는 방법이 없습니다. 덕분에 단일 요청을 검사하고 구현 중에 어떤 일이 발생했는지 확인할 수 있습니다. 그래서 우리는 하나의 웹페이지를 가져와 거의 2주 동안 퍼즐 조각을 모으고, 다양한 호출을 하고, 각 페이지가 어떤 결과를 가져왔는지 분석했습니다.
이 사진을 보세요. 이는 하나의 외부 요청이 서비스에 반환되는 많은 내부 호출을 수행하도록 요청하는 것을 보여줍니다. 각 내부 호출은 필요한 정보를 얻기 위해 다른 곳으로 돌아갈 수 없기 때문에 이 요청을 독립적으로 처리할 수 있도록 추가 홉을 만드는 것으로 나타났습니다. 이 그림은 외부 요청이 추가 서비스를 호출하고, 이 추가 서비스가 다른 추가 서비스를 호출하는 등 거의 무한정 호출되므로 의미 없는 연속 호출처럼 보입니다.

이 다이어그램의 녹색은 서비스 A가 서비스 B를 호출하고, 서비스 B가 서비스 C를 호출하고, 다시 서비스 A를 호출하는 반원을 보여줍니다. 결과적으로 "분산 교착 상태"가 발생합니다. 단일 요청으로 수천 개의 네트워크 API 호출이 생성되었으며 시스템에는 내결함성 및 루프 보호가 내장되어 있지 않았기 때문에 이러한 API 호출 중 하나라도 실패하면 요청이 실패했습니다.

우리는 수학을 좀 했습니다. 각 API 호출의 SLA는 150ms 이하, 가동 시간은 99,9%였습니다. 한 요청으로 인해 200개의 서로 다른 호출이 발생했으며 가장 좋은 경우 페이지는 200 x 150ms = 30초 내에 표시될 수 있습니다. 당연히 이것은 좋지 않았습니다. 99,9% 가동 시간에 200을 곱하면 가용성이 0%가 됩니다. 이 아키텍처는 처음부터 실패할 운명이었던 것으로 밝혀졌습니다.

우리는 개발자들에게 18개월의 작업 후에도 이 문제를 인식하지 못한 이유를 물었습니다. 그들은 실행한 코드에 대해서만 SLA를 계산했지만 서비스가 다른 서비스를 호출한 경우에는 SLA에 해당 시간을 계산하지 않은 것으로 나타났습니다. 한 프로세스 내에서 시작된 모든 것은 150ms의 값을 고수했지만 다른 서비스 프로세스에 대한 액세스는 전체 지연을 몇 배나 증가시켰습니다. 배운 첫 번째 교훈은 "당신이 SLA를 통제하고 있습니까, 아니면 SLA가 당신을 통제하고 있습니까?"였습니다. 우리의 경우는 후자였습니다.

다음으로 우리가 발견한 것은 그들이 Peter Deitch와 James Gosling이 공식화한 분산 컴퓨팅 오해의 개념을 알고 있었지만 그 첫 부분을 무시했다는 것입니다. “네트워크는 안정적이다”, “지연 시간 없음”, “무한한 처리량”이라는 진술은 오해입니다. 또 다른 오해로는 "네트워크는 안전하다", "토폴로지는 절대 변하지 않는다", "관리자는 항상 한 명뿐이다", "데이터 전송 비용은 XNUMX이다", "네트워크는 동질적이다" 등이 있다.
그들은 로컬 컴퓨터에서 서비스를 테스트하고 외부 서비스와 연결하지 않았기 때문에 실수를 저질렀습니다. 로컬에서 개발하고 로컬 캐시를 사용할 때 네트워크 홉이 발생하지 않았습니다. 18개월의 개발 기간 동안 그들은 외부 서비스가 영향을 받으면 어떤 일이 일어날지 한 번도 생각해 본 적이 없습니다.

이전 그림의 서비스 경계를 ​​보면 모두 잘못된 것을 알 수 있습니다. 서비스 경계를 ​​정의하는 방법에 대해 조언하는 소스가 많이 있으며, 대부분은 다음 슬라이드의 Microsoft처럼 잘못 수행합니다.

이 사진은 "마이크로서비스 구축 방법" 주제에 대한 MS 블로그에서 가져온 것입니다. 이는 간단한 웹 애플리케이션, 비즈니스 로직 블록 및 데이터베이스를 보여줍니다. 요청은 직접적으로 이루어지며 웹용 서버 한 대, 비즈니스용 서버 한 대, 데이터베이스용 서버 한 대가 있을 것입니다. 트래픽을 늘리면 그림이 약간 변경됩니다.

여기에는 두 개의 웹 서버, 웹 서비스와 비즈니스 로직 사이에 위치한 캐시, 비즈니스 로직과 데이터베이스 사이에 있는 또 다른 캐시 간에 트래픽을 분산시키는 로드 밸런서가 있습니다. 이것이 바로 Bell이 2000년대 중반 로드 밸런싱 및 블루/그린 배포 애플리케이션에 사용한 아키텍처입니다. 이 계획은 모놀리식 구조를 대상으로 했기 때문에 얼마 전까지는 모든 것이 잘 작동했습니다.

다음 그림은 MS가 모놀리스에서 마이크로서비스로 이동하도록 권장하는 방법을 보여줍니다. 즉, 각 주요 서비스를 별도의 마이크로서비스로 분할하기만 하면 됩니다. Bell이 실수를 한 것은 이 계획을 실행하는 동안이었습니다.

그들은 모든 서비스를 다양한 계층으로 나누었으며 각 계층은 많은 개별 서비스로 구성되었습니다. 예를 들어, 웹 서비스에는 콘텐츠 렌더링 및 인증을 위한 마이크로서비스가 포함되었고, 비즈니스 로직 서비스는 주문 및 계정 정보 처리를 위한 마이크로서비스로 구성되었으며, 데이터베이스는 특화된 데이터를 포함하는 여러 개의 마이크로서비스로 분할되었습니다. 웹, 비즈니스 로직, 데이터베이스 모두 상태 비저장 서비스였습니다.

하지만 이 그림은 회사의 IT 클러스터 외부에 어떤 사업부도 매핑하지 않았기 때문에 완전히 잘못된 것이었습니다. 이 계획은 외부 세계와의 연결을 고려하지 않았기 때문에 제XNUMX자 비즈니스 분석을 얻는 방법 등이 명확하지 않았습니다. 나는 또한 더 많은 돈을 벌기 위해 가능한 한 많은 사람을 관리하려는 개별 직원의 경력을 개발하기 위해 여러 가지 서비스를 발명했다는 점에 주목합니다.

그들은 마이크로서비스로의 전환이 내부 N 계층 물리적 계층 인프라를 가져와서 그 위에 Docker를 설치하는 것만큼 쉽다고 믿었습니다. 전통적인 N 계층 아키텍처가 어떤 모습인지 살펴보겠습니다.

이는 UI 사용자 인터페이스 수준, 비즈니스 로직 수준, 데이터 액세스 수준 및 데이터베이스의 4개 수준으로 구성됩니다. 보다 진보적인 것은 DDD(Domain-Driven Design) 또는 소프트웨어 지향 아키텍처로, 두 중간 수준은 도메인 개체와 저장소입니다.

저는 이 아키텍처에서 다양한 변화 영역, 다양한 책임 영역을 살펴보려고 노력했습니다. 일반적인 N 계층 애플리케이션에서는 구조에 수직으로 위에서 아래로 침투하는 다양한 변경 영역이 분류됩니다. 이는 개별 컴퓨터에서 수행되는 카탈로그, 구성 설정 및 체크아웃 확인이며 우리 팀에서 처리했습니다.

이 체계의 특징은 이러한 변경 영역의 경계가 비즈니스 논리 수준뿐만 아니라 데이터베이스까지 확장된다는 것입니다.

서비스가 된다는 것이 무엇을 의미하는지 살펴보겠습니다. 서비스 정의에는 6가지 특징적인 속성이 있습니다. 이는 다음과 같은 소프트웨어입니다.

• 특정 조직에서 생성하고 사용합니다.
• 시스템 내에서 특정 유형의 정보의 내용, 처리 및/또는 제공을 담당합니다.
• 특정 운영 요구 사항을 충족하기 위해 독립적으로 구축, 배포 및 실행할 수 있습니다.
• 소비자 및 기타 서비스와 통신하여 계약 또는 계약 보증에 따라 정보를 제공합니다.
• 무단 액세스로부터 자신을 보호하고 정보 손실로부터 보호합니다.
• 정보 손상으로 이어지지 않는 방식으로 장애를 처리합니다.

이 모든 속성은 '자율성'이라는 한 단어로 표현될 수 있습니다. 서비스는 서로 독립적으로 운영되고, 특정 제한 사항을 충족하며, 사람들이 필요한 정보를 받을 수 있는 계약을 정의합니다. 나는 그 사용이 자명한 특정 기술에 대해서는 언급하지 않았습니다.

이제 마이크로서비스의 정의를 살펴보겠습니다.

• 마이크로서비스는 크기가 작고 하나의 특정 문제를 해결하도록 설계되었습니다.
• 마이크로서비스는 자율적입니다.
• 마이크로서비스 아키텍처를 만들 때 도시 계획 비유가 사용됩니다. 이는 Sam Newman의 저서 Building Microservices에 나온 정의입니다.

제한된 컨텍스트의 정의는 Eric Evans의 책 Domain-Driven Design에서 따왔습니다. 이는 볼륨 아키텍처 모델을 사용하여 이를 서로 다른 바인딩된 컨텍스트로 나누고 이들 간의 상호 작용을 명시적으로 정의하는 아키텍처 디자인 센터인 DDD의 핵심 패턴입니다.

간단히 말해서 바인딩된 컨텍스트는 특정 모듈이 사용될 수 있는 범위를 나타냅니다. 이 컨텍스트 내에는 예를 들어 비즈니스 도메인에서 볼 수 있는 논리적으로 통합된 모델이 있습니다. 주문 관계자에게 '고객이 누구인가'라고 물으면 한 가지 정의가 나오고, 영업 관계자에게 물어보면 또 다른 정의가 나오고, 출연자들은 세 번째 정의를 내린다.

따라서 제한된 컨텍스트에서는 서비스 소비자가 무엇인지 명확하게 정의할 수 없다면 이 용어의 의미에 대해 이야기할 수 있는 경계를 정의한 다음 이러한 다양한 정의 간의 전환점을 정의하자고 말합니다. 즉, 주문 관점에서 고객에 대해 이야기하면 이것이 의미하고, 판매 관점에서 보면 이것이 의미합니다.

마이크로서비스의 다음 정의는 모든 종류의 내부 작업을 캡슐화하여 작업 프로세스 구성 요소가 환경으로 "누출"되는 것을 방지하는 것입니다. 다음은 SLA에서 반환되는 계약이라는 아이디어로 표현되는 "외부 상호 작용 또는 외부 통신을 위한 명시적 계약의 정의"입니다. 마지막 정의는 셀 또는 셀에 대한 은유입니다. 이는 마이크로서비스 내의 일련의 작업과 외부 세계와의 통신을 위한 수용체의 존재를 완벽하게 캡슐화하는 것을 의미합니다.

그래서 우리는 Bell Computers 직원들에게 이렇게 말했습니다. “돈이 없기 때문에 여러분이 만든 혼란은 고칠 수 없습니다. 하지만 서비스 하나만 고치면 모든 것이 잘 될 수 있습니다. 감각." 이제 9분 XNUMX초보다 빠르게 요청에 응답하도록 유일한 서비스를 수정한 방법부터 설명하겠습니다.

22:30 분

조만간 계속...

일부 광고

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com