마이크로서비스: Kubernetes가 있더라도 크기가 중요합니다

19월 XNUMX일 모스크바 일어났다 마이크로서비스에 전념하는 첫 번째 주제별 회의 HUG(Highload++ User Group). "마이크로서비스 운영: Kubernetes가 있더라도 크기가 중요합니다"라는 프레젠테이션이 있었는데, 여기서 우리는 마이크로서비스 아키텍처를 사용하여 프로젝트를 운영하는 Flant의 광범위한 경험을 공유했습니다. 우선, 현재 또는 미래의 프로젝트에서 이 접근 방식을 사용하려고 생각하는 모든 개발자에게 유용할 것입니다.

소개 보고서 영상 (50분, 기사보다 훨씬 더 유익함) 및 주요 발췌문을 텍스트 형식으로 제공합니다.

주의: 이 게시물 끝부분에서 비디오와 프리젠테이션도 볼 수 있습니다.

소개

일반적으로 좋은 이야기에는 시작, 주요 줄거리, 결말이 있습니다. 이 보고서는 서곡에 가깝고 비극적입니다. 또한 마이크로서비스에 대한 외부인의 관점을 제공한다는 점에 유의하는 것도 중요합니다. 운영.

이 그래프부터 시작하겠습니다. 작성자는 2015년에 작성했습니다. 했다 마틴 파울러:

이는 특정 값에 도달한 모놀리식 애플리케이션의 경우 생산성이 어떻게 감소하기 시작하는지 보여줍니다. 마이크로서비스는 초기 생산성이 낮다는 점에서 다르지만, 복잡성이 증가함에 따라 효율성 저하가 그다지 눈에 띄지 않습니다.

Kubernetes를 사용하는 경우에 대해 이 그래프에 추가하겠습니다.

마이크로서비스가 포함된 애플리케이션이 더 나은 이유는 무엇입니까? 이러한 아키텍처는 아키텍처에 대한 심각한 요구 사항을 제시하고 Kubernetes의 기능으로 완벽하게 처리되기 때문입니다. 반면에 이 기능 중 일부는 모놀리스에 유용할 것입니다. 특히 오늘날의 일반적인 모놀리스는 정확히 모놀리스가 아니기 때문입니다(자세한 내용은 보고서 후반부에서 설명).

보시다시피 최종 그래프(모놀리식 애플리케이션과 마이크로서비스 애플리케이션이 모두 Kubernetes를 사용하는 인프라에 있을 때)는 원본 그래프와 크게 다르지 않습니다. 다음으로 Kubernetes를 사용하여 운영되는 애플리케이션에 대해 이야기하겠습니다.

유용하고 해로운 마이크로서비스

주요 아이디어는 다음과 같습니다.

무엇인가 표준 마이크로서비스 아키텍처? 이는 실질적인 이점을 제공하여 작업 효율성을 높여줍니다. 다시 그래프로 돌아가면 이렇습니다.

그녀에게 전화하면 유능한, 그래프 반대편에는 해로운 마이크로서비스(작업을 방해함):

"주요 아이디어"로 돌아가서: 내 경험을 믿어야 할까요? 올해 초부터 살펴보니 85 개 프로젝트. 그들 모두가 마이크로서비스는 아니었지만(그 중 약 5분의 500에서 절반 정도가 그러한 아키텍처를 가지고 있었습니다), 이는 여전히 많은 수입니다. 아웃소싱 업체인 우리(Flant 회사)는 소규모 회사(개발자 XNUMX명)와 대규모 회사(개발자 약 XNUMX명) 모두에서 개발된 다양한 애플리케이션을 관리합니다. 추가적인 이점은 이러한 애플리케이션이 수년에 걸쳐 활성화되고 발전하는 것을 볼 수 있다는 것입니다.

왜 마이크로서비스인가?

마이크로서비스의 이점에 대한 질문에는 다음이 있습니다. 매우 구체적인 답변 이미 언급한 마틴 파울러(Martin Fowler)로부터:

1. 모듈성의 명확한 경계;
2. 독립적인 배포;
3. 기술을 선택할 자유.

저는 소프트웨어 설계자 및 개발자와 많은 대화를 나누고 왜 마이크로서비스가 필요한지 물었습니다. 그리고 나는 그들의 기대치 목록을 만들었습니다. 일어난 일은 다음과 같습니다.

"감각"의 일부 요점을 설명하면 다음과 같습니다.

• 모듈의 명확한 경계: 여기에는 끔찍한 단일체가 있으며 이제 모든 것이 Git 저장소에 깔끔하게 정리되어 모든 것이 "선반에" 있고 따뜻하고 부드러움이 혼합되지 않습니다.
• 배포 독립성: 서비스를 독립적으로 출시하여 개발 속도를 높일 수 있습니다(새로운 기능을 동시에 게시).
• 개발 독립성: 이 마이크로서비스를 한 팀/개발자에게 제공하고 다른 팀/개발자에게 제공할 수 있으므로 더 빠르게 개발할 수 있습니다.
• бо신뢰성 향상: 부분적인 저하가 발생하면(20개의 마이크로서비스 중 하나의 마이크로서비스가 중단됨) 단 하나의 버튼만 작동을 멈추고 시스템 전체는 계속 작동합니다.

일반적인(유해한) 마이크로서비스 아키텍처

현실이 우리가 기대하는 것과 다른 이유를 설명하기 위해 집단 다양한 프로젝트의 경험을 바탕으로 한 마이크로서비스 아키텍처 이미지입니다.

Amazon이나 적어도 OZON과 경쟁할 추상적인 온라인 상점을 예로 들 수 있습니다. 마이크로서비스 아키텍처는 다음과 같습니다.

여러 가지 이유로 이러한 마이크로서비스는 서로 다른 플랫폼에서 작성됩니다.

각 마이크로서비스에는 자율성이 있어야 하므로 대부분 자체 데이터베이스와 캐시가 필요합니다. 최종 아키텍처는 다음과 같습니다.

그 결과는 무엇입니까?

파울러도 이거 갖고 있어 기사가 있어요 — 마이크로서비스 사용에 대한 "지불"에 대해:

그리고 우리의 기대가 충족되었는지 살펴보겠습니다.

모듈의 경계를 명확하게 합니다...

하지만 실제로 수정해야 할 마이크로서비스는 얼마나 됩니까?변경 사항을 적용하시겠습니까? 분산 추적기 없이 모든 것이 어떻게 작동하는지 알아낼 수 있습니까? (결국 모든 요청은 마이크로서비스의 절반에 의해 처리됩니다.)

패턴이 있다"큰 흙 덩어리“그리고 여기에는 분산된 흙 덩어리가 있는 것으로 밝혀졌습니다. 이를 확인하기 위해 요청이 진행되는 방식에 대한 대략적인 그림은 다음과 같습니다.

배포 독립성...

기술적으로는 달성되었습니다. 각 마이크로서비스를 별도로 출시할 수 있습니다. 하지만 실제로는 항상 롤아웃된다는 점을 고려해야 합니다. 많은 마이크로서비스, 그리고 우리는 고려해야 할 사항이 있습니다 출시 순서. 좋은 의미에서는 일반적으로 릴리스를 올바른 순서로 롤아웃하는지 여부를 별도의 회로에서 테스트해야 합니다.

기술 선택의 자유…

그녀는. 자유는 종종 불법과 접해 있다는 점을 기억하십시오. 여기서는 단지 "플레이"하기 위해 기술을 선택하지 않는 것이 매우 중요합니다.

개발의 독립...

(너무 많은 구성 요소가 포함된) 전체 애플리케이션에 대한 테스트 루프를 만드는 방법은 무엇입니까? 하지만 여전히 최신 상태로 유지해야 합니다. 이 모든 것이 다음과 같은 사실로 이어집니다. 실제 테스트 회로 수, 원칙적으로 다음을 포함할 수 있습니다. 최소로 나온다.

이 모든 것을 로컬에 배포하는 것은 어떻습니까?.. 개발자는 회로를 테스트할 수 있을 때까지 기다려야 하기 때문에 작업을 독립적으로 수행하는 경우가 많지만 "무작위로" 수행하는 경우가 많습니다.

별도의 스케일링...

네, 하지만 사용하는 DBMS 영역에 제한이 있습니다. 주어진 아키텍처 예에서 Cassandra에는 문제가 없지만 MySQL과 PostgreSQL에는 문제가 있습니다.

Бо더 큰 신뢰성...

실제로 하나의 마이크로서비스가 실패하면 전체 시스템의 올바른 기능이 중단되는 경우가 많을 뿐만 아니라 새로운 문제도 있습니다. 모든 마이크로서비스를 내결함성으로 만드는 것은 매우 어렵습니다.. 마이크로서비스는 서로 다른 기술(memcache, Redis 등)을 사용하기 때문에 각각에 대해 모든 것을 생각하고 구현해야 합니다. 물론 가능하지만 막대한 리소스가 필요합니다.

부하 측정 가능성...

정말 좋습니다.

마이크로서비스의 "가벼움"...

우리는 거대할 뿐만 아니라 네트워크 오버헤드 (DNS에 대한 요청이 늘어나고 있는 등), 또한 우리가 시작한 많은 하위 쿼리로 인해 데이터 복제 (캐시 저장)으로 인해 상당한 양의 저장 공간이 발생했습니다.

그리고 우리의 기대에 부응한 결과는 다음과 같습니다.

하지만 그건 전부가 아닙니다!

왜냐하면 :

• 아마도 메시지 버스가 필요할 것입니다.
• 적시에 일관된 백업을 만드는 방법은 무엇입니까? 유일한 사람 реальный 옵션은 이에 대한 트래픽을 끄는 것입니다. 하지만 프로덕션에서는 어떻게 해야 할까요?
• 여러 지역을 지원하는 것에 대해 이야기하고 있다면 각 지역에서 지속 가능성을 조직하는 것은 매우 노동 집약적인 작업입니다.
• 중앙 집중식 변경 문제가 발생합니다. 예를 들어, PHP 버전을 업데이트해야 한다면 각 저장소(수십 개가 있음)에 커밋해야 합니다.
• 운영 복잡성의 증가는 기하급수적으로 증가합니다.

이 모든 것을 어떻게 해야 할까요?

모놀리식 애플리케이션으로 시작하기. 파울러의 경험 говорит 거의 모든 성공적인 마이크로서비스 애플리케이션은 너무 커지다가 파손된 단일체로 시작되었습니다. 동시에 처음부터 마이크로서비스로 구축된 거의 모든 시스템은 조만간 심각한 문제를 겪었습니다.

또 다른 귀중한 생각은 마이크로서비스 아키텍처를 갖춘 프로젝트가 성공하려면 다음 사항을 잘 알아야 한다는 것입니다. 주제 영역, 마이크로서비스를 만드는 방법. 그리고 주제 영역을 배우는 가장 좋은 방법은 단일체를 만드는 것입니다.

하지만 우리가 이미 이런 상황에 처해 있다면 어떨까요?

문제를 해결하는 첫 번째 단계는 문제에 동의하고 문제라는 점, 더 이상 고통받고 싶지 않다는 점을 이해하는 것입니다.

지나치게 자란 단일체의 경우(추가 리소스를 구매할 기회가 부족할 때) 이를 잘라내면 이 경우 반대 이야기가 나타납니다. 과도한 마이크로서비스가 더 이상 도움이 되지 않고 방해가 되는 경우 - 초과분을 잘라내고 확대하다!

예를 들어 위에서 설명한 집단 이미지의 경우...

가장 의심스러운 마이크로서비스를 제거하세요.

프런트엔드 생성을 담당하는 모든 마이크로서비스를 결합합니다.

... 하나의 언어/프레임워크로 작성된 하나의 마이크로서비스로:

여기에는 하나의 ORM(하나의 DBMS)과 먼저 두 개의 애플리케이션이 있습니다.

...하지만 일반적으로 훨씬 더 많은 것을 전송할 수 있으며 다음과 같은 결과를 얻을 수 있습니다.

게다가 Kubernetes에서는 이 모든 것을 별도의 인스턴스에서 실행하므로 여전히 로드를 측정하고 별도로 확장할 수 있습니다.

요약

더 큰 그림을 보세요. 마이크로서비스와 관련된 이러한 모든 문제는 누군가가 자신의 작업을 수행했지만 "마이크로서비스를 사용"하기를 원했기 때문에 발생하는 경우가 많습니다.

"마이크로서비스"라는 단어에서 "마이크로" 부분은 중복됩니다.. 그것들은 거대한 단일체보다 작기 때문에 "마이크로"입니다. 그러나 그것들을 작은 것으로 생각하지 마십시오.

마지막 생각을 위해 원래 차트로 돌아가 보겠습니다.

거기에 적힌 메모 (맨 위 오른쪽) 이라는 사실로 귀결된다. 프로젝트를 만드는 팀의 기술이 항상 최우선입니다 — 마이크로서비스와 모놀리스 중 하나를 선택하는 데 중요한 역할을 합니다. 팀의 실력이 부족해도 마이크로서비스를 만들기 시작한다면 스토리는 분명 치명적일 것입니다.

비디오 및 슬라이드

연설 영상 (약 50분; 아쉽게도 방문객들의 수많은 감정을 전달하지 못하여 보고서의 분위기를 크게 좌우했지만 그랬습니다):

보고서 발표:

PS

우리 블로그의 다른 보고서:

• «모니터링 및 Kubernetes» (Dmitry Stolyarov; 28년 2018월 XNUMX일 RootConf에서);
• «Kubernetes 및 GitLab을 사용한 CI/CD 모범 사례» (Dmitry Stolyarov; HighLoad++에서 7년 2017월 XNUMX일);
• «소규모 프로젝트에서의 Kubernetes 경험» (Dmitry Stolyarov; 6년 2017월 XNUMX일 RootConf에서);
• «CI/CD용 Docker 이미지를 dapp으로 빠르고 편리하게 구축합니다.» (Dmitry Stolyarov; HighLoad++에서 8년 2016월 XNUMX일);
• «Docker를 사용한 지속적인 전달 방식» (Dmitry Stolyarov; 31년 2016월 XNUMX일 RootConf에서).

다음 출판물에도 관심이 있으실 것입니다.

• «2018년 마이크로서비스 광기의 종말";
• «Google이 제시하는 컨테이너 사용에 대한 7가지 모범 사례";
• «Kubernetes 구현 문제에 대한 The New Stack의 통계".

출처 : habr.com