현대 인프라: 문제와 전망

5 월 말 우리 주제로 온라인 회의를 열었습니다. “현대적인 인프라와 컨테이너: 문제와 전망”. 우리는 컨테이너, Kubernetes 및 오케스트레이션 원칙, 인프라 선택 기준 등에 대해 이야기했습니다. 참가자들은 자신의 실습 사례를 공유했습니다.

참가자 :

• ITSumma의 CEO, 예브게니 포타포프(Evgeniy Potapov). 고객의 절반 이상이 이미 Kubernetes로 전환 중이거나 전환을 원하고 있습니다.
• Dmitry Stolyarov, CTO "Flan". 컨테이너 시스템 작업 경험이 10년 이상입니다.
• Denis Remchukov(일명 Eric Oldmann), COO argotech.io, 전 RAO UES. 그는 "피묻은"기업의 사례에 대해 이야기하겠다고 약속했습니다.
• 안드레이 페도로프스키(Andrey Fedorovsky), CTO “News360.com”다른 플레이어가 회사를 구매한 후 그는 여러 ML 및 AI 프로젝트와 인프라를 담당합니다.
• Ivan Kruglov, 전 Booking.com 시스템 엔지니어.자신의 손으로 Kubernetes로 많은 일을 해낸 바로 그 사람입니다.

주제 :

• 컨테이너 및 오케스트레이션(Docker, Kubernetes 등)에 대한 참가자의 통찰력 실제로 시도되었거나 분석된 내용.
• 사례: 회사는 수년간 인프라 개발 계획을 수립하고 있습니다. 인프라를 컨테이너와 Kuber로 구축(또는 현재 마이그레이션)할지 여부는 어떻게 결정되나요?
• 클라우드 네이티브 세계의 문제, 무엇이 빠졌는지, 내일 무슨 일이 일어날지 상상해 봅시다.

흥미로운 토론이 이어졌고, 참가자들의 의견이 너무 달랐고 많은 댓글이 생겨서 여러분과 공유하고 싶습니다. 먹다 XNUMX시간짜리 영상, 아래는 토론 내용을 요약한 것입니다.

Kubernetes는 이미 표준인가요, 아니면 훌륭한 마케팅인가요?

“아직 아무도 그것에 대해 알지 못했을 때 우리는 그것에 왔습니다 (Kubernetes. - Ed.). 그가 거기에 없을 때에도 우리는 그에게 왔습니다. 우리는 전부터 그것을 원했어요" - 드미트리 스톨야로프

Reddit.com의 사진

5~10년 전에는 수많은 도구가 있었고 단일한 표준은 없었습니다. XNUMX개월마다 새로운 제품이 등장하거나 심지어 두 개 이상이 등장합니다. 먼저 Vagrant, 그다음 Salt, Chef, Puppet... “그리고 XNUMX개월마다 인프라를 재구축합니다. 구성을 다시 작성하느라 끊임없이 바쁜 관리자가 XNUMX명 있습니다.”라고 Andrey Fedorovsky는 회상합니다. 그는 Docker와 Kubernetes가 나머지를 "밀어냈다"고 믿습니다. Docker는 지난 XNUMX년 동안 표준이 되었고, Kubernetes는 지난 XNUMX년 동안 표준이 되었습니다. 그리고 그것은 업계에 좋은 일입니다..

Dmitry Stolyarov와 그의 팀은 Kuber를 좋아합니다. 그들은 그러한 도구가 나타나기 전에 그것을 원했고 아무도 그것에 대해 알지 못했을 때 그 도구를 사용했습니다. 현재 편의상의 이유로 Kubernetes를 구현하지 않을 것임을 이해하는 경우 클라이언트를 맡지 않습니다. 동시에 Dmitry에 따르면 회사는 "끔찍한 유산을 재창조하는 데 대한 수많은 성공 사례"를 보유하고 있습니다.

Kubernetes는 컨테이너 오케스트레이션일 뿐만 아니라 개발된 API, 네트워킹 구성 요소, L3 밸런싱 및 Ingress 컨트롤러를 갖춘 구성 관리 시스템으로, 인프라의 하위 계층에서 리소스 관리, 확장 및 추상화를 상대적으로 쉽게 만듭니다.

불행하게도 우리 인생에서 우리는 모든 비용을 지불해야 합니다. Ivan Kruglov가 믿는 것처럼 개발된 인프라를 갖춘 회사의 Kubernetes로의 전환에 대해 이야기하는 경우 특히 그렇습니다. 그는 전통적인 인프라를 갖춘 회사와 Kuber에서 자유롭게 일할 수 있었습니다. 가장 중요한 것은 회사와 시장의 특성을 이해하는 것입니다. 그러나 예를 들어 Kubernetes를 모든 컨테이너 오케스트레이션 도구로 일반화하는 Evgeny Potapov의 경우 그러한 질문이 발생하지 않습니다.

Evgeniy는 객체지향 프로그래밍이 복잡한 애플리케이션을 프로그래밍하는 방식으로 등장했던 1990년대 상황에 비유했습니다. 당시에도 논쟁은 계속되었고 OOP를 지원하는 새로운 도구가 등장했습니다. 그러다가 모놀리식 개념에서 벗어나기 위한 방법으로 마이크로서비스가 등장했습니다. 이는 결국 컨테이너와 컨테이너 관리 도구의 출현으로 이어졌습니다. “작은 마이크로서비스 애플리케이션을 작성할 가치가 있는지 여부에 대해 의문의 여지가 없고 기본적으로 마이크로서비스로 작성되는 시대가 곧 올 것이라고 생각합니다.”라고 그는 믿습니다. 마찬가지로 Docker와 Kubernetes는 결국 선택의 여지가 없는 표준 솔루션이 될 것입니다.

상태 비저장 데이터베이스의 문제

님이 촬영 한 사진 트위터: Unsplash의 @jankolario

요즘에는 Kubernetes에서 데이터베이스를 실행하는 방법이 많이 있습니다. 조건에 따라 데이터베이스의 애플리케이션 부분에서 I/O 디스크와 함께 작동하는 부분을 분리하는 방법도 있습니다. 미래에는 데이터베이스가 너무 많이 변경되어 상자에 담겨 제공될 가능성이 있습니까? 여기서 한 부분은 Docker와 Kubernetes를 통해 조정되고 인프라의 다른 부분에서는 별도의 소프트웨어를 통해 스토리지 부분이 제공됩니다. ? 베이스가 제품으로 바뀌나요?

이 설명은 대기열 관리와 유사하지만 기존 데이터베이스의 정보 안정성 및 동기화에 대한 요구 사항은 훨씬 높다고 Andrey는 믿습니다. 일반 데이터베이스의 캐시 적중률은 99%를 유지합니다. 작업자가 다운되면 새 작업자가 시작되고 캐시가 처음부터 "워밍업"됩니다. 캐시가 준비될 때까지 작업자는 느리게 작동하므로 사용자 로드로 로드할 수 없습니다. 사용자 로드가 없는 동안에는 캐시가 워밍업되지 않습니다. 그것은 악순환입니다.

Dmitry는 근본적으로 이에 동의하지 않습니다. 쿼럼과 샤딩이 문제를 해결합니다. 그러나 Andrey는 이 솔루션이 모든 사람에게 적합한 것은 아니라고 주장합니다. 어떤 상황에서는 쿼럼이 적합하지만 네트워크에 추가 부하를 줍니다. NoSQL 데이터베이스는 모든 경우에 적합하지 않습니다.

밋업 참가자들은 두 개의 진영으로 나뉘었습니다.

Denis와 Andrey는 데이터베이스 등 디스크에 기록되는 모든 작업이 현재 Kuber 생태계에서는 불가능하다고 주장합니다. Kubernetes에서는 프로덕션 데이터의 무결성과 일관성을 유지하는 것이 불가능합니다. 이것은 기본적인 특징입니다. 솔루션: 하이브리드 인프라.

MongoDB 및 Cassandra와 같은 최신 클라우드 네이티브 데이터베이스나 Kafka 또는 RabbitMQ와 같은 메시지 대기열에도 Kubernetes 외부에 영구 데이터 저장소가 필요합니다.

Evgeniy는 다음과 같이 반대합니다. "Kubera의 기지는 러시아에 가깝거나 기업에 가까운 피해입니다. 이는 러시아에 클라우드 채택이 없다는 사실과 관련이 있습니다." 서양의 중소기업은 클라우드입니다. Amazon RDS 데이터베이스는 Kubernetes를 직접 조작하는 것보다 사용하기가 더 쉽습니다. 러시아에서는 Kuber를 "온프레미스"로 사용하고 동물원을 없애려고 할 때 기지를 Kuber로 이전합니다.

Dmitry는 또한 Kubernetes에 데이터베이스를 보관할 수 없다는 설명에 동의하지 않았습니다. “베이스는 베이스와 다릅니다. 그리고 거대한 관계형 데이터베이스를 푸시한다면 어떤 상황에서도 발생하지 않습니다. 반일시적인 삶을 위해 정신적으로 준비된 작고 클라우드 기반의 무언가를 추진한다면 모든 것이 잘 될 것입니다.” Dmitry는 또한 데이터베이스 관리 도구가 Docker나 Kuber에 준비되어 있지 않아 큰 어려움이 발생한다고 언급했습니다.

Ivan은 Stateful과 Stateless의 개념을 추상화하더라도 Kubernetes의 엔터프라이즈 솔루션 생태계는 아직 준비되지 않았다고 확신합니다. Kuber를 사용하면 입법 및 규제 요구 사항을 유지하기가 어렵습니다. 예를 들어, 서버에 삽입되는 하드웨어까지 엄격한 서버 식별 보장이 요구되는 ID 제공 솔루션을 만드는 것은 불가능합니다. 이 부분은 개발 중이지만 아직 해결책은 없습니다.
참가자들은 동의하지 않았으므로 이 부분에서는 결론을 도출하지 않습니다. 몇 가지 실제적인 예를 들어보겠습니다.

사례 1. Kubera 외부에 기반을 둔 “대규모 규제 기관”의 사이버 보안

개발된 사이버 보안 시스템의 경우 컨테이너와 오케스트레이션을 사용하면 공격과 침입에 맞서 싸울 수 있습니다. 예를 들어, 한 대규모 규제 기관에서 Denis와 그의 팀은 실시간으로 로그를 분석하고 공격, 해킹 또는 실패 프로세스를 결정하는 훈련된 SIEM 서비스와 오케스트레이터의 조합을 구현했습니다. 공격이 발생하거나 무언가를 배치하려는 시도가 있거나 랜섬웨어 바이러스 침입이 발생하는 경우 오케스트레이터를 통해 감염되거나 공격자가 공격하는 것보다 더 빠르게 애플리케이션이 포함된 컨테이너를 선택합니다.

사례 2. Booking.com 데이터베이스를 Kubernetes로 부분 마이그레이션

Booking.com에서 기본 데이터베이스는 비동기 복제 기능을 갖춘 MySQL입니다. 마스터와 전체 슬레이브 계층 구조가 있습니다. Ivan이 회사를 떠날 무렵, 특정 피해를 입힐 수 있는 노예를 이송하는 프로젝트가 시작되었습니다.

메인 베이스 외에도 Kuber가 주류에 진입하기 전부터 작성된 자체 작성 오케스트레이션이 포함된 Cassandra 설치가 있습니다. 이와 관련하여 문제는 없지만 로컬 SSD에서는 지속됩니다. 원격 스토리지는 동일한 데이터센터 내에서도 대기 시간이 길어지는 문제로 인해 사용되지 않습니다.

데이터베이스의 세 번째 클래스는 각 서비스 노드가 데이터베이스인 Booking.com 검색 서비스입니다. 검색 서비스를 Kuber로 전송하려는 시도가 실패했습니다. 각 노드는 60-80GB의 로컬 스토리지로 "리프트" 및 "워밍업"이 어렵기 때문입니다.

그 결과 검색 엔진이 Kubernetes로 이전되지 않았으며 Ivan은 가까운 시일 내에 새로운 시도가 있을 것이라고 생각하지 않습니다. MySQL 데이터베이스는 절반으로 전송되었습니다. "샷"을 두려워하지 않는 슬레이브만 전송되었습니다. 카산드라는 완벽하게 자리를 잡았습니다.

일반적인 솔루션 없이 작업으로 인프라 선택

님이 촬영 한 사진 Pexels의 마누엘 가이싱거

새로운 회사가 있거나 인프라의 일부가 기존 방식으로 구축된 회사가 있다고 가정해 보겠습니다. 수년간 인프라 개발 계획을 수립합니다. 컨테이너와 Kuber에 인프라를 구축할지 여부는 어떻게 결정되나요?

나노초 단위로 싸우는 기업은 논의에서 제외됩니다. 건전한 보수주의는 신뢰성 측면에서 성과를 거두지만, 여전히 새로운 접근 방식을 고려해야 하는 기업이 있습니다.

Ivan: “저는 확실히 클라우드에서 회사를 시작할 것입니다. 클라우드가 더 빠르기 때문입니다.” 물론 더 저렴할 필요는 없습니다. 벤처캐피털리즘이 발달하면서 스타트업은 돈에 큰 문제가 없으며, 시장을 선점하는 것이 주된 임무이다.

이반은 이렇게 생각한다. 현재 인프라의 개발이 선택 기준입니다. 과거에 심각한 투자가 있었고 효과가 있었다면 다시 실행할 필요가 없습니다. 인프라가 개발되지 않았고 도구, 보안, 모니터링에 문제가 있는 경우 분산 인프라를 살펴보는 것이 합리적입니다.

세금은 어떤 경우에도 납부해야 하며 Ivan은 미래에 더 적은 금액을 납부할 수 있는 세금을 납부할 것입니다. "왜냐하면 내가 다른 사람들이 움직이는 기차를 타고 있다는 사실만으로도 내가 직접 연료를 넣어야 하는 다른 기차에 앉아 있는 것보다 훨씬 더 멀리 여행할 것이기 때문입니다.“이반은 말합니다. 회사가 신규이고 대기 시간 요구 사항이 수십 밀리초인 경우 Ivan은 현재 기존 데이터베이스가 "래핑"되는 "운영자"를 찾을 것입니다. 장애 조치 등의 경우 자체적으로 전환되는 복제 체인을 발생시킵니다.

두 대의 서버를 보유한 소규모 회사의 경우 Kubera는 적합하지 않습니다.”라고 Andrey는 말합니다. 그러나 수백 대 이상의 서버로 확장할 계획이라면 자동화와 리소스 관리 시스템이 필요합니다. 케이스의 90%는 비용만큼 가치가 있습니다. 또한 부하 및 리소스 수준에 관계없이. 스타트업부터 수백만 명의 청중을 보유한 대기업에 이르기까지 모든 사람이 점차적으로 컨테이너 오케스트레이션 제품을 찾는 것이 합리적입니다. “예, 이것이 바로 미래입니다.” Andrey는 확신합니다.

Denis는 두 가지 주요 기준을 설명했습니다. 확장성과 운영 안정성. 그는 작업에 가장 적합한 도구를 선택합니다. “무릎 위에 조립된 노네임일 수도 있고 Nutanix Community Edition이 탑재되어 있습니다. 이는 복제되고 RTO 및 RPO 매개변수가 지정된 백엔드에 데이터베이스가 있는 Kuber의 애플리케이션 형태의 두 번째 줄일 수 있습니다."(복구 시간/지점 목표 - 약).

Evgeniy는 직원에게 가능한 문제를 식별했습니다. 현재 시장에는 '배짱'을 이해하는 높은 자격을 갖춘 전문가가 많지 않습니다. 실제로 선택한 기술이 오래된 것이라면 삶이 지루하고 지친 중년 외에는 채용하기 어렵다. 다른 참가자들은 이것이 인력 교육의 문제라고 생각합니다.
선택의 문제를 제기한다면: Amazon RDS의 데이터베이스를 사용하여 퍼블릭 클라우드에서 소규모 회사를 시작하거나 Kubernetes의 데이터베이스를 사용하여 "온프레미스"로 소규모 회사를 시작하려면 몇 가지 단점에도 불구하고 Amazon RDS가 참가자의 선택이 되었습니다.

모임 청취자의 대다수는 "피폐한" 기업 출신이 아니기 때문에 분산 솔루션은 우리가 노력해야 할 것입니다. 데이터 스토리지 시스템은 분산되고 안정적이어야 하며 최대 수십 밀리초 단위로 측정되는 대기 시간을 생성해야 합니다.“Andrey가 요약했습니다.

Kubernetes 사용량 평가

청취자 Anton Zhbankov는 Kubernetes 옹호자들에게 함정 질문을 했습니다. 타당성 조사를 어떻게 선택하고 수행했습니까? 예를 들어 Kubernetes가 필요한 이유는 무엇이며 가상 머신은 어떻습니까?

님이 촬영 한 사진 Unsplash의 타티아나 에레미나

Dmitry와 Ivan이 대답했습니다. 두 경우 모두 시행착오를 거쳐 일련의 결정이 내려졌고 그 결과 두 참가자 모두 Kubernetes에 도달했습니다. 이제 기업들은 Kuber로 이전하는 데 적합한 소프트웨어를 독립적으로 개발하기 시작했습니다. 우리는 1C와 같은 전통적인 타사 시스템에 대해 말하는 것이 아닙니다. Kubernetes는 논스톱 지속적인 개선을 통해 개발자가 신속하게 릴리스해야 할 때 도움을 줍니다.

Andrey의 팀은 가상 머신을 기반으로 확장 가능한 클러스터를 만들려고 했습니다. 노드가 도미노처럼 무너져 클러스터가 붕괴되는 경우도 있었습니다. “이론적으로는 손으로 마무리하고 받쳐주면 되지만, 귀찮잖아요. 그리고 즉시 작업할 수 있는 솔루션이 시중에 나와 있다면 우리는 기꺼이 그 솔루션을 사용하겠습니다. 결과적으로 우리는 전환했습니다.”라고 Andrey는 말합니다.

이러한 분석과 계산에 대한 표준이 있지만 실제로 작동하는 하드웨어에서 얼마나 정확한지는 누구도 말할 수 없습니다. 계산을 위해서는 각 도구와 생태계를 이해하는 것도 중요하지만 이는 불가능합니다.

우리를 기다리는 것

님이 촬영 한 사진 Unsplash의 드류 비머

기술이 발전함에 따라 점점 더 많은 이질적인 조각이 나타나고 단계 전환이 발생하며 모든 것을 하나의 도구로 통합할 수 있을 만큼 충분한 반죽을 완성한 공급업체가 나타납니다.

Linux 세계에 Ubuntu와 같은 도구가 등장할 때가 올 것이라고 생각하시나요? 아마도 단일 컨테이너화 및 오케스트레이션 도구에는 Kuber가 포함될 것입니다. 온프레미스 클라우드 구축이 쉬워질 것입니다.

Ivan은 다음과 같이 대답했습니다. "Google은 현재 Anthos를 구축하고 있습니다. Anthos는 클라우드를 배포하고 Kuber, Service Mesh, 모니터링 등 온프레미스 마이크로서비스에 필요한 모든 하드웨어를 포함하는 패키지 제품입니다." 우리는 거의 미래에 와있습니다."

Denis는 또한 컨테이너화 없이도 유사한 작업을 처리할 수 있는 vRealize Suite 제품이 포함된 Nutanix와 VMWare를 언급했습니다.

Dmitry는 “고통”을 줄이는 것과 세금을 줄이는 것이 개선을 기대할 수 있는 두 가지 영역이라는 의견을 공유했습니다.

논의를 요약하기 위해 현대 인프라의 다음과 같은 문제를 강조합니다.

• 세 명의 참가자가 즉시 상태 저장 문제를 확인했습니다.
• Docker가 여러 버전의 Python, 애플리케이션 서버 및 구성 요소를 갖게 될 가능성을 포함한 다양한 보안 지원 문제.
  과잉 지출은 별도의 회의에서 논의하는 것이 좋습니다.
  오케스트레이션으로서의 학습 과제는 복잡한 생태계입니다.
  업계에서 흔히 발생하는 문제는 도구의 오용입니다.

  나머지 결론은 귀하에게 달려 있습니다. Docker+Kubernetes 조합이 시스템의 "중앙" 부분이 되기는 여전히 쉽지 않다는 느낌이 있습니다. 예를 들어 운영 체제는 하드웨어에 먼저 설치되지만 컨테이너 및 오케스트레이션에 대해서는 말할 수 없습니다. 아마도 미래에는 운영 체제와 컨테이너가 클라우드 관리 소프트웨어와 통합될 것입니다.

  
  님이 촬영 한 사진 Pexels의 가브리엘 산토스 사진

  이 기회를 빌어 어머니께 인사드리고 Facebook 그룹이 있다는 사실을 알려드리고 싶습니다. "대규모 IT 프로젝트 관리 및 개발", 채널 @feedmeto 다양한 기술 블로그의 흥미로운 출판물을 통해 그리고 내 채널 @rybakalexey, 여기서는 제품 회사의 개발 관리에 대해 이야기합니다.

출처 : habr.com