모놀리스에서 마이크로서비스까지: M.Video-Eldorado 및 MegaFon의 경험

25월 XNUMX일, Mail.ru 그룹에서는 구름과 주변 환경에 관한 컨퍼런스를 열었습니다. 메일 수신자:클라우드. 몇 가지 주요 사항:

• 주요 러시아 공급자 — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center 및 Yandex.Cloud는 클라우드 시장과 해당 서비스의 세부 사항에 대해 이야기했습니다.
• Bitrix24의 동료들은 그들이 어떻게 했는지 말했습니다. 멀티클라우드에 왔습니다;
• Leroy Merlin, Otkritie, Burger King 및 Schneider Electric이 흥미로운 정보를 제공했습니다. 클라우드 소비자의 관점 — 비즈니스에서 IT에 대해 설정하는 작업은 무엇이며, 클라우드 기술을 포함하여 가장 유망하다고 생각하는 기술은 무엇입니까?

mailto:CLOUD 컨퍼런스의 모든 영상을 시청하실 수 있습니다 링크, 여기에서 마이크로서비스에 대한 논의가 어떻게 진행되었는지 읽을 수 있습니다. MegaFon 비즈니스 시스템 연구 개발 센터의 책임자인 Alexander Deulin과 M.Video-Eldorado 그룹의 정보 기술 이사인 Sergey Sergeev가 단일체를 제거한 성공적인 사례를 공유했습니다. 또한 IT 전략, 프로세스, 심지어 HR과 관련된 문제에 대해서도 논의했습니다.

패널리스트

• 세르게이 세르게예프, 그룹 CIO "M.Video-엘도라도";
• 알렉산더 데린, 비즈니스시스템연구개발센터장 메가폰;
• 중재자 — 드미트리 라자렌코, PaaS 부문 책임자 Mail.ru 클라우드 솔루션.

Alexander Deulin의 연설 후 “MegaFon이 마이크로서비스 플랫폼을 통해 비즈니스를 확장하는 방법” 그는 M.Video-Eldorado의 Sergey Sergeev와 Mail.ru Cloud Solutions의 토론 진행자 Dmitry Lazarenko가 토론에 참여했습니다.

아래에 토론 내용을 준비했습니다. 동영상도 시청하실 수 있습니다.

마이크로서비스로의 전환은 시장 요구에 대한 대응입니다.

드미트리 :

마이크로서비스로 마이그레이션한 성공적인 경험이 있습니까? 그리고 일반적으로 마이크로서비스를 사용하거나 모놀리스에서 마이크로서비스로 전환함으로써 가장 큰 비즈니스 이점을 얻는 곳은 어디입니까?

세르게이 :

우리는 이미 마이크로서비스로의 전환 과정을 어느 정도 진행했으며 이 접근 방식을 XNUMX년 넘게 사용해 왔습니다. 마이크로서비스의 필요성을 정당화한 첫 번째 요구는 다양한 프런트엔드 제품과 백오피스의 끝없는 통합이었습니다. 그리고 매번 추가 통합 및 개발을 수행해야 할 때마다 특정 서비스 운영에 대한 자체 규칙을 구현했습니다.

어느 시점에서 우리는 시스템 작동 속도와 기능 출력 속도를 높여야 한다는 것을 깨달았습니다. 그 당시에는 마이크로서비스나 마이크로서비스 접근 방식과 같은 개념이 이미 시장에 존재했고 우리는 그것을 시도하기로 결정했습니다. 이는 2016년부터 시작되었습니다. 그런 다음 플랫폼이 마련되고 처음 10개의 서비스가 별도의 팀에 의해 구현되었습니다.

첫 번째 서비스 중 가장 부하가 많았던 서비스는 가격 계산 서비스였습니다. 웹사이트나 소매점 등 M.Video-Eldorado 회사 그룹의 모든 채널에 접속하여 그곳에서 제품을 선택하고 웹사이트나 "바구니"에서 가격을 볼 때마다 비용이 자동으로 계산됩니다. 하나의 서비스로 계산됩니다. 이것이 필요한 이유: 이전에는 각 시스템에 할인 등 프로모션 작업에 대한 자체 원칙이 있었습니다. 우리 백오피스에서는 가격 책정을 처리하고 할인 기능은 다른 시스템에서 구현됩니다. 이는 중앙 집중화되어야 하며 이를 구현할 수 있도록 비즈니스 프로세스 형태로 생성된 고유하고 분리 가능한 서비스가 필요했습니다. 그것이 우리가 시작한 방법입니다.

첫 번째 결과의 가치는 매우 컸습니다. 첫째, 우리는 개별적으로 통합된 방식으로 작업할 수 있는 분리 가능한 엔터티를 만들 수 있었습니다. 둘째, 더 많은 시스템과의 통합 측면에서 소유 비용을 줄였습니다.

지난 XNUMX년 동안 우리는 XNUMX개의 최전선 시스템을 추가했습니다. 회사가 감당할 수 있는 동일한 양의 자원으로 이를 유지하는 것이 어려웠습니다. 따라서 내부 비용 및 효율성 측면에서 속도 측면에서 시장에 대응하면서 새로운 매장을 찾는 작업이 발생했습니다.

마이크로서비스로의 마이그레이션 성공을 측정하는 방법

드미트리 :

마이크로서비스로의 마이그레이션 성공 여부는 어떻게 결정됩니까? 각 회사의 '이전'은 무엇이었나요? 전환의 성공 여부를 판단하기 위해 어떤 측정 기준을 사용했으며 실제로 이를 결정한 사람은 누구입니까?

세르게이 :

우선, IT 내에서 새로운 기능을 "잠금 해제"하는 조력자로서 탄생했습니다. 우리는 시장 과제에 대응하면서 상대적으로 동일한 비용으로 모든 작업을 더 빠르게 수행해야 했습니다. 이제 성공은 다양한 시스템에서 재사용되는 서비스의 수, 프로세스 간의 통합으로 표현됩니다. 지금은 그렇습니다만, 그 순간에는 플랫폼을 만들고 이것을 할 수 있다는 가설을 확인하는 기회가 되었고, 효과를 주고 비즈니스 사례를 계산하게 될 것입니다.

알렉산더 :

성공은 오히려 내부 감정입니다. 기업은 항상 더 많은 것을 원하며, 백로그의 깊이는 성공의 증거입니다. 제가 보기엔 그런 것 같아요.

세르게이 :

그래, 난 동의. 30년 만에 우리는 이미 XNUMX개 이상의 서비스와 백로그를 보유하게 되었습니다. 팀 내 리소스에 대한 필요성은 매년 XNUMX%씩 증가하고 있습니다. 이런 일이 일어나는 이유는 사람들이 더 빠르고, 다르고, 기술도 다르고, 이 모든 것이 발전하고 있다고 느꼈기 때문입니다.

마이크로서비스가 등장하지만 핵심은 그대로 유지됩니다

드미트리 :

이는 개발에 투자하는 끝없는 프로세스와 같습니다. 비즈니스를 위한 마이크로서비스로의 전환은 이미 끝났습니까?

세르게이 :

대답하기는 매우 쉽습니다. 어떻게 생각하세요: 휴대폰 교체는 끝이 없는 과정인가요? 우리는 매년 휴대폰을 구입합니다. 속도가 필요하고 시장에 적응하려면 약간의 변화가 필요합니다. 이것은 우리가 표준적인 것을 버린다는 의미는 아닙니다.

하지만 모든 것을 한꺼번에 덮고 다시 할 수는 없습니다. 우리는 이전에 사용 가능했던 레거시 표준 통합 서비스(엔터프라이즈 버스 등)를 보유하고 있습니다. 하지만 밀린 일도 있고, 필요한 일도 있습니다. 모바일 애플리케이션의 수와 그 기능이 증가하고 있습니다. 동시에 30% 더 많은 돈을 받게 될 것이라고 말하는 사람은 아무도 없습니다. 즉, 한편으로는 항상 필요가 있고 다른 한편으로는 효율성을 추구하는 것입니다.

드미트리 :

생활은 양호합니다. (웃음)

알렉산더 :

일반적으로 그렇습니다. 우리는 풍경에서 핵심 부분을 제거하는 혁신적인 접근 방식을 갖고 있지 않습니다. 시스템이 서로에게 미치는 영향을 줄이기 위해 마이크로서비스 아키텍처와 보다 일관성이 있도록 시스템을 분해하는 체계적인 작업이 진행 중입니다.

하지만 우리는 핵심 부분을 유지할 계획입니다. 왜냐하면 운영자 환경에는 항상 우리가 구매하는 일부 플랫폼이 있기 때문입니다. 다시 말하지만, 우리에게는 건전한 균형이 필요합니다. 핵심을 잘라내려고 서두르면 안 됩니다. 우리는 시스템을 나란히 배치했고 이제 우리는 이미 많은 핵심 부품 위에 있다는 것이 밝혀졌습니다. 또한 기능을 개발하여 커뮤니케이션 서비스와 함께 작동하는 모든 채널에 필요한 표현을 만듭니다.

마이크로서비스를 기업에 판매하는 방법

드미트리 :

저는 또한 관심이 있습니다 - 아직 전환하지 않았지만 다음을 계획하고 있는 분들을 위해: 이 아이디어를 사업에 판매하는 것이 얼마나 쉬웠으며 모험, 투자 프로젝트였습니까? 아니면 의식적인 전략이었나요? 이제 우리는 마이크로서비스로 전환하고 있으며 그게 전부입니다. 아무것도 우리를 막을 수 없습니다. 당신은 어땠나요?

세르게이 :

우리는 접근 방식을 파는 것이 아니라 비즈니스 이점을 파는 것이었습니다. 사업에 문제가 있었고 우리는 그것을 해결하려고 노력했습니다. 그 당시에는 프로모션, 프로모션 등에 대해 별도로 가격을 계산하기 위해 채널마다 서로 다른 원칙을 사용했다는 사실로 표현되었습니다. 유지보수가 어려웠고, 오류가 발생했으며, 고객불만사항을 청취하였습니다. 즉, 우리는 문제에 대한 해결책을 팔고 있었지만 플랫폼을 만들려면 돈이 필요하다는 사실을 안고 왔습니다. 그리고 그들은 첫 번째 투자 단계의 예를 사용하여 비즈니스 사례를 보여주었습니다. 즉, 우리가 계속해서 이를 회수할 방법과 이를 통해 무엇을 할 수 있는지에 대한 것입니다.

드미트리 :

XNUMX단계의 시간을 어떻게든 녹음하셨나요?

세르게이 :

물론이지. 우리는 플랫폼으로서의 코어를 생성하고 파일럿을 테스트하는 데 6개월을 할당했습니다. 이 기간 동안 우리는 파일럿이 스케이트를 탈 수 있는 플랫폼을 만들려고 노력했습니다. 그러면 가설이 확인됐고, 효과가 있으니 계속해도 된다는 뜻이다. 그들은 팀을 복제하고 강화하기 시작했습니다. 이를 수행하는 별도의 부서로 옮겼습니다.

다음은 비즈니스 요구 사항, 기회, 리소스 가용성 및 현재 작업 중인 모든 사항을 기반으로 하는 체계적인 작업입니다.

드미트리 :

좋아요. 알렉산더, 뭐라고요?

알렉산더 :

우리의 마이크로서비스는 자원 절약, 서버 용량 형태의 남은 부분 및 팀 내 전력 재분배로 인해 "바다의 거품"에서 탄생했습니다. 처음에 우리는 이 프로젝트를 기업에 판매하지 않았습니다. 이는 우리가 그에 맞춰 연구하고 개발한 프로젝트였습니다. 우리는 2018년 초에 시작하여 열정적으로 이 방향을 발전시켰습니다. 이제 막 판매가 시작되었고 진행 중입니다.

드미트리 :

일주일에 하루 무료로 Google과 같은 일을 할 수 있는 기업이 있습니까? 그런 방향이 있나요?

알렉산더 :

연구와 동시에 비즈니스 문제도 다루었으므로 모든 마이크로서비스는 비즈니스 문제에 대한 솔루션입니다. 처음에만 우리는 가입자 기반의 작은 부분을 포괄하는 마이크로서비스를 구축했으며 이제는 거의 모든 주력 제품에 존재합니다.

그리고 중대한 영향은 이미 분명합니다. 우리가 이전 경로를 따랐다면 이미 셀 수 있고, 제품 출시 속도와 수익 손실을 추정할 수 있습니다. 이것이 바로 우리가 사건을 구축하고 있는 이유입니다.

마이크로서비스: 과대광고인가, 필요성인가?

드미트리 :

숫자는 숫자입니다. 그리고 수익이나 돈을 절약하는 것도 매우 중요합니다. 반대편을 보면 어떨까요? 마이크로서비스가 하나의 트렌드이자 과대 광고이며 많은 기업이 이를 악용하고 있는 것 같나요? 마이크로서비스로 변환하는 작업과 변환하지 않는 작업을 얼마나 명확하게 구분합니까? 지금 유산이라면 5년 뒤에도 유산을 남길 수 있을까요? 5년 후 M.Video-Eldorado와 MegaFon에서 작동하는 정보 시스템의 시대는 어떻게 될까요? XNUMX년, XNUMX년 된 정보 시스템이 존재할 것인가, 아니면 새로운 세대가 될 것인가? 이것을 어떻게 보십니까?

세르게이 :

아주 먼 곳에서 생각하는 것은 어려운 것 같습니다. 돌이켜보면 머신러닝, 얼굴을 통한 사용자 식별 등 기술 시장이 이렇게 발전할 것이라고 누가 상상이나 했을까요? 그러나 앞으로 몇 년을 살펴보면 회사의 핵심 시스템, 엔터프라이즈 ERP 급 시스템이 꽤 오랫동안 작동해 온 것 같습니다.

우리 회사는 총 25년의 역사를 갖고 있으며 시스템 환경에 매우 깊은 클래식 ERP를 보유하고 있습니다. 우리가 거기에서 일부 조각을 가져와 마이크로서비스로 통합하려고 노력하고 있다는 것은 분명하지만 핵심은 그대로 유지됩니다. 이제 우리가 그곳의 모든 핵심 시스템을 교체하고 새로운 시스템의 다른 밝은 면으로 빠르게 이동할 것이라고 상상하기 어렵습니다.

나는 클라이언트와 소비자에게 더 가까운 모든 것이 가장 큰 비즈니스 이점과 가치가 있는 곳, 즉 적응성과 속도, 변화, "시도, 취소, 재사용, 뭔가 다른 작업 수행"에 대한 초점이 있다는 사실을 지지합니다. 필요합니다.”—그곳에서 풍경이 바뀔 것입니다. 그리고 박스형 제품은 거기에 잘 맞지 않습니다. 적어도 우리는 그것을 보지 못합니다. 가장 쉽고 간단한 솔루션이 필요합니다.

우리는 다음과 같은 발전을 봅니다.

• 핵심 정보 시스템(주로 백오피스);
• 마이크로서비스 형태의 중간 계층은 코어를 연결하고, 집계하고, 캐시를 생성하는 등의 작업을 수행합니다.
• 일선 시스템은 소비자를 겨냥합니다.
• 일반적으로 마켓플레이스, 기타 시스템 및 생태계에 통합되는 통합 계층입니다. 이 레이어는 최대한 가볍고 단순하며 최소한의 비즈니스 로직을 포함합니다.

그러나 동시에 나는 오래된 원칙이 적절하게 사용된다면 계속해서 사용하는 것을 지지합니다.

고전적인 엔터프라이즈 시스템이 있다고 가정해 보겠습니다. 한 공급업체의 환경에 위치하며 서로 작동하는 두 개의 모듈로 구성됩니다. 표준 통합 인터페이스도 있습니다. 왜 다시 실행하고 마이크로서비스를 가져오나요?

그러나 백오피스에 5개의 모듈이 있고 그로부터 정보 조각이 비즈니스 프로세스로 수집되어 8~10개의 일선 시스템에서 사용되는 경우 이점이 즉시 눈에 띄게 나타납니다. XNUMX개의 백오피스 시스템을 가져와 비즈니스 프로세스에 초점을 맞춘 격리된 서비스를 만듭니다. 서비스를 기술적으로 발전시켜 정보를 캐시하고 내결함성을 가지며 문서 또는 비즈니스 엔터티와도 작동하도록 합니다. 그리고 이를 단일 원칙에 따라 모든 일선 제품에 통합합니다. 그들은 일선 제품을 취소했으며 단순히 통합을 중단했습니다. 내일은 모바일 애플리케이션을 작성하거나 작은 웹사이트를 만들고 기능에 한 부분만 추가해야 합니다. 모든 것이 간단합니다. 생성자처럼 조립하면 됩니다. 나는 적어도 우리나라에서는 이 방향으로 더 많은 발전이 있다고 봅니다.

알렉산더 :

Sergey는 우리의 접근 방식을 완벽하게 설명했습니다. 감사합니다. 우리가 확실히 가지 않을 곳, 즉 핵심 부분, 온라인 청구 주제에 대해 말씀 드리겠습니다. 즉, 평가 및 청구는 실제로 돈을 안정적으로 상쇄하는 "큰"탈곡기로 남을 것입니다. 그리고 이 시스템은 규제 당국의 인증을 계속 받을 것입니다. 물론 클라이언트를 바라보는 다른 모든 것은 마이크로서비스입니다.

드미트리 :

여기서 인증은 하나의 이야기입니다. 아마 더 많은 지원을 받을 것 같습니다. 지원에 거의 지출하지 않거나 시스템에 지원 및 수정이 필요하지 않은 경우에는 건드리지 않는 것이 좋습니다. 합리적인 타협.

안정적인 마이크로서비스를 개발하는 방법

드미트리 :

괜찮은. 하지만 나는 여전히 관심이 있습니다. 이제 당신은 성공 스토리를 말하고 있습니다. 모든 것이 괜찮았고 마이크로서비스로 전환했으며 비즈니스에 대한 아이디어를 옹호했고 모든 것이 잘 진행되었습니다. 하지만 다른 이야기도 들었습니다.

몇 년 전, 은행을 위한 새로운 마이크로서비스 플랫폼 개발에 XNUMX년을 투자했던 스위스 회사가 결국 프로젝트를 종료했습니다. 완전히 무너졌습니다. 수백만 스위스 프랑이 지출되었지만 결국 팀은 흩어졌습니다. 제대로 작동하지 않았습니다.

비슷한 이야기를 하신 적이 있나요? 어려움이 있었나요? 예를 들어, 마이크로서비스를 유지하고 모니터링하는 것도 회사 운영 활동의 골칫거리입니다. 결국 구성 요소의 수가 수십 배 증가합니다. 어떻게 보십니까? 여기에 실패한 투자 사례가 있습니까? 그리고 사람들이 그러한 문제에 직면하지 않도록 무엇을 조언할 수 있습니까?

알렉산더 :

실패한 예로는 기업이 우선순위를 변경하고 프로젝트를 취소하는 것이 있습니다. 좋은 준비 단계에 도달했을 때(사실 MVP가 준비됨) 기업은 "우리는 새로운 우선순위를 갖고 있으며 다른 프로젝트로 넘어가고 이 프로젝트를 종료할 예정입니다."라고 말했습니다.

마이크로서비스에서는 글로벌 실패가 발생하지 않았습니다. 우리는 평화롭게 잠을 자고 있으며 전체 BSS [비즈니스 지원 시스템]에 서비스를 제공하는 연중무휴 근무 시간을 갖고 있습니다.

그리고 한 가지 더 - 우리는 박스형 제품에 적용되는 규칙에 따라 마이크로서비스를 임대합니다. 성공의 열쇠는 먼저 프로덕션을 위한 마이크로서비스를 완벽하게 준비할 팀을 구성해야 한다는 것입니다. 개발 자체는 조건부로 40%입니다. 나머지는 분석, DevSecOps 방법론, 올바른 통합 및 올바른 아키텍처입니다. 우리는 보안 애플리케이션 구축 원칙에 특별한 주의를 기울입니다. 정보 보안 담당자는 아키텍처 계획 단계와 구현 프로세스 중에 각 프로젝트에 참여합니다. 또한 코드의 취약점을 분석하는 시스템을 관리합니다.

상태 비저장 서비스를 배포한다고 가정해 보겠습니다. Kubernetes에 해당 서비스가 있습니다. 이를 통해 서비스의 자동 확장 및 자동 증가로 인해 모든 사람이 평화롭게 잠을 잘 수 있으며 근무 교대 근무가 인시던트를 포착합니다.

마이크로서비스가 존재하는 전체 기간 동안 우리 라인에 도달한 사건은 한두 건에 불과했습니다. 이제 작동에는 문제가 없습니다. 물론 우리는 200개가 아니라 약 50개의 마이크로서비스를 보유하고 있지만 이는 주력 제품에 사용됩니다. 만약 그들이 실패한다면, 우리는 그것에 대해 가장 먼저 알게 될 것입니다.

마이크로서비스와 HR

세르게이 :

나는 지원팀으로의 전환에 대해 동료의 의견에 동의합니다. 즉, 작업을 올바르게 구성해야 한다는 것입니다. 그러나 물론 존재하는 문제에 대해 말씀 드리겠습니다.

첫째, 기술이 새롭다. 이는 좋은 의미에서 과대 광고이며, 이를 이해하고 만들 수 있는 전문가를 찾는 것은 큰 도전입니다. 자원 경쟁이 치열하기 때문에 전문가들은 금만큼의 가치가 있습니다.

둘째, 특정 경관이 만들어지고 서비스가 증가함에 따라 재사용 문제는 지속적으로 해결되어야 합니다. 개발자들이 즐겨 하는 것처럼 "지금 여기에 흥미로운 것들을 많이 써보자..." 이 때문에 시스템은 성장하고 비용, 소유 비용 등의 측면에서 효율성을 잃습니다. 즉, 시스템 아키텍처에 재사용을 포함하고, 서비스 도입 및 레거시를 새로운 아키텍처로 전환하기 위한 로드맵에 이를 포함해야 합니다.

또 다른 문제는 그 자체로는 좋지만 내부 경쟁입니다. "아, 여기에 새로운 패셔너블한 남자들이 나타났어요. 그들은 새로운 언어를 사용해요." 물론 사람들은 다릅니다. Java로 작성하는 데 익숙한 사람도 있고 Docker와 Kubernetes를 작성하고 사용하는 사람도 있습니다. 이들은 완전히 다른 사람들이고, 다르게 말하고, 다른 용어를 사용하며, 때로는 서로를 이해하지 못합니다. 이런 의미에서 실천, 지식 공유의 능력이나 무능력도 문제입니다.

음, 리소스를 확장합니다. "좋아 가자! 이제 우리는 더 빠르고 더 많은 것을 원합니다. 뭐, 할 수 없어? XNUMX년에 두 배로 배달할 수는 없을까? 그리고 왜?" 그러한 성장통은 아마도 많은 것, 많은 접근 방식의 표준일 것이며 느낄 수 있습니다.

모니터링 관련. 제가 보기에는 서비스나 산업 모니터링 도구가 이미 다른 비표준 모드에서 Docker와 Kubernetes를 모두 학습하고 있거나 작업할 수 있는 것 같습니다. 예를 들어, 이 모든 것이 실행되는 즉, 집계되는 500개의 Java 시스템으로 끝나지 않습니다. 하지만 이들 제품은 아직 성숙도가 부족해 이 과정을 거쳐야 합니다. 주제는 정말 새롭고 계속해서 발전할 것입니다.

드미트리 :

네, 매우 흥미롭습니다. 그리고 이는 HR에도 적용됩니다. 아마도 귀하의 HR 프로세스와 HR 브랜드가 지난 3년 동안 약간 변경되었을 것입니다. 당신은 다른 역량을 가진 다른 사람들을 채용하기 시작했습니다. 그리고 아마도 장점과 단점이 모두 있을 것입니다. 이전에는 블록체인과 데이터 과학이 과대 광고였으며, 그 전문가의 가치는 수백만 달러였습니다. 이제 비용은 하락하고 시장은 포화 상태에 이르렀으며 마이크로서비스에도 비슷한 추세가 있습니다.

세르게이 :

예, 물론입니다.

알렉산더 :

HR은 "백엔드와 프런트엔드 사이에 핑크색 유니콘이 어디에 있습니까?"라고 질문합니다. HR은 마이크로서비스가 무엇인지 이해하지 못합니다. 우리는 그들에게 비밀을 알려주고 백엔드가 모든 일을 하며 유니콘은 없다고 말했습니다. 그러나 HR은 변화하고 빠르게 학습하며 기본적인 IT 지식을 갖춘 인력을 채용하고 있습니다.

마이크로서비스의 진화

드미트리 :

대상 아키텍처를 보면 마이크로서비스는 정말 괴물처럼 보입니다. 당신의 여행에는 몇 년이 걸렸습니다. 다른 사람은 XNUMX년, 다른 사람은 XNUMX년입니다. 모든 문제, 대상 아키텍처를 예상했습니까? 변경된 사항이 있습니까? 예를 들어 마이크로서비스의 경우 이제 게이트웨이와 서비스 메시가 다시 나타납니다. 처음에 사용하셨나요, 아니면 아키텍처 자체를 변경하셨나요? 당신은 그런 어려움을 겪고 있습니까?

세르게이 :

우리는 이미 여러 통신 프로토콜을 다시 작성했습니다. 처음에는 하나의 프로토콜이 있었지만 이제는 다른 프로토콜로 전환했습니다. 안전성과 신뢰성을 높여드립니다. 우리는 Oracle, Web Logic과 같은 엔터프라이즈 기술로 시작했습니다. 이제 우리는 마이크로서비스의 기술적 기업 제품에서 벗어나 오픈 소스 또는 완전히 개방된 기술로 이동하고 있습니다. 우리는 데이터베이스를 버리고 이 모델에서 우리에게 더 효과적인 것으로 이동합니다. 더 이상 Oracle 기술이 필요하지 않습니다.

우리는 캐시가 얼마나 필요한지, 마이크로서비스와 연결은 없지만 데이터가 필요한 경우 무엇을 할지 등을 생각하지 않고 단순히 서비스로 시작했습니다. 이제 아키텍처를 설명할 수 있도록 플랫폼을 개발하고 있습니다. 서비스 언어가 아닌 비즈니스 언어로 말로 대화를 시작하면 비즈니스 논리를 한 단계 더 발전시킬 수 있습니다. 이제 우리는 문자로 말하는 방법을 배웠으며 다음 단계는 서비스가 일종의 집합체로 수집되는 단계입니다. 예를 들어 전체 제품 카드와 같이 이미 단어인 경우입니다. 마이크로서비스로 조립되지만, 이를 기반으로 구축된 API입니다.

안전은 매우 중요합니다. 접근 가능해지기 시작하고 많은 흥미로운 것들을 매우 빠르게 얻을 수 있는 서비스가 생기면 가장 안전하지 않은 방식으로 그것을 얻고자 하는 욕구가 생깁니다. 이를 벗어나기 위해 우리는 테스트와 모니터링에 대한 접근 방식을 바꿔야 했습니다. 팀, 배송 관리 구조, CI/CD를 변경해야 했습니다.

이것은 전화기와 마찬가지로 훨씬 더 빠른 진화입니다. 먼저 푸시 버튼 전화기가 있었고 그 다음에는 스마트폰이 나타났습니다. 시장의 요구 사항이 다르기 때문에 그들은 제품을 다시 작성하고 디자인했습니다. 이것이 우리가 진화하는 방식입니다: XNUMX학년, XNUMX학년, 일.

반복적으로 기술의 관점에서 뭔가가, 백로그와 요구의 관점에서 다른 것이 매년 배치됩니다. 우리는 하나를 다른 것과 연결합니다. 팀은 팀을 위한 기술 부채 및 기술 지원에 20%를 지출하고 사업체에 80%를 지출합니다. 그리고 우리는 왜 이 일을 하는지, 왜 이러한 기술적 개선을 하고 있는지, 그리고 그것이 무엇으로 이어질지에 대한 이해를 바탕으로 움직입니다. 그렇죠.

드미트리 :

시원한. MegaFon에는 무엇이 있나요?

알렉산더 :

마이크로서비스를 도입할 때 가장 큰 과제는 혼란에 빠지지 않는 것이었습니다. MegaFon의 건축 사무소가 즉시 우리와 합류했고 심지어 개시자이자 추진자가 되었습니다. 이제 우리는 매우 강력한 아키텍처를 갖게 되었습니다. 그의 임무는 우리가 어떤 목표 모델을 사용하고 어떤 기술을 시험해야 하는지 이해하는 것이었습니다. 건축 분야에서는 이러한 파일럿 작업을 직접 수행했습니다.

다음 질문은 “그럼 이 모든 것을 어떻게 활용할까요?”였습니다. 그리고 한 가지 더: "마이크로서비스 간의 투명한 상호 작용을 보장하는 방법은 무엇입니까?" 서비스 메시는 마지막 질문에 답하는 데 도움이 되었습니다. 우리는 Istio를 시험해 보았고 결과가 마음에 들었습니다. 이제 우리는 생산 영역으로 진출하는 단계에 있습니다. 우리는 모든 도전에 대해 긍정적인 태도를 가지고 있습니다. 즉, 끊임없이 스택을 바꾸고 새로운 것을 배워야 한다는 사실입니다. 우리는 오래된 솔루션을 활용하는 것이 아니라 개발에 관심이 있습니다.

드미트리 :

금단어! 이러한 도전은 팀과 비즈니스를 온전하게 유지하고 미래를 창조합니다. GDPR은 최고 데이터 보호 책임자를 만들었고, 현재의 과제로 인해 최고 마이크로서비스 및 아키텍처 책임자가 탄생했습니다. 그리고 그것은 기쁘게 생각합니다.

우리는 많은 논의를 했습니다. 가장 중요한 것은 마이크로서비스와 아키텍처 자체를 잘 설계하면 많은 실수를 피할 수 있다는 것입니다. 물론 그 과정은 반복적이고 진화적이지만 미래입니다.

모든 참가자들, Sergei와 Alexander에게 감사드립니다!

청중의 질문

청중의 질문 (1):

Sergey, 귀사의 IT 관리는 어떻게 바뀌었나요? 여러 시스템으로 구성된 대규모 스택이 있을 때 이를 관리하는 방법은 상당히 명확하고 논리적인 프로세스라는 것을 이해합니다. 매우 짧은 시간에 매우 많은 수의 마이크로서비스가 통합된 후 IT 구성 요소의 관리를 어떻게 다시 구축했습니까?

세르게이 :

나는 아키텍처가 변화의 원동력으로서 매우 중요하다는 동료의 의견에 동의합니다. 우리는 건축 부문부터 시작했습니다. 건축가는 기능 배포의 소유자이자 그것이 풍경에 어떻게 나타날지에 대한 요구 사항을 동시에 소유합니다. 그래서 그들은 또한 이러한 변화의 조정자 역할을 합니다. 그 결과 CI/CD 플랫폼을 만들 때 특정 전달 프로세스에 구체적인 변경 사항이 있었습니다.

그러나 표준, 개발의 기본 원칙, 비즈니스 분석, 테스트 및 개발은 취소되지 않았습니다. 속도만 추가했습니다. 이전에는 주기가 너무 길어서 테스트 환경에 설치하는 데 훨씬 더 많은 시간이 걸렸습니다. 이제 기업에서는 이점을 확인하고 "왜 다른 곳에서는 이 작업을 수행할 수 없습니까?"라고 말합니다.

좋은 의미에서는 백신 형태의 주사와 같습니다. 이 방법으로 할 수 있지만 다른 방법으로 할 수도 있습니다. 물론 인력, 역량, 지식, 저항력에 문제가 있습니다.

청중의 질문 (2):

마이크로서비스 아키텍처를 비판하는 사람들은 테스트와 개발이 어렵다고 말합니다. 상황이 복잡해지는 것은 논리적입니다. 귀하의 팀은 어떤 어려움에 직면했으며 이를 어떻게 극복했습니까? 모두를 위한 질문입니다.

알렉산더 :

마이크로서비스에서 플랫폼으로 전환할 때 어려움이 있지만 해결할 수 있습니다.

예를 들어, 우리는 5~7개의 마이크로서비스로 구성된 제품을 만들고 있습니다. 마스터 브랜치로의 이동에 대한 승인을 얻으려면 전체 마이크로서비스 스택에 대한 통합 테스트를 제공해야 합니다. 이 작업은 우리에게 새로운 것이 아니었습니다. 공급업체가 이미 출시된 솔루션을 우리에게 제공했을 때 우리는 BSS에서 오랫동안 이 작업을 수행해 왔습니다.

그리고 우리의 문제는 소규모 팀에만 있습니다. 하나의 조건부 제품에는 한 명의 QA 엔지니어가 필요합니다. 따라서 우리는 5~7개의 마이크로서비스로 구성된 제품을 출시하며 그 중 2~3개는 제XNUMX자가 개발할 수 있습니다. 예를 들어, 청구 시스템 공급업체인 Mail.ru Group과 MegaFon R&D가 참여하여 개발 중인 제품이 있습니다. 이를 프로덕션 환경으로 배송하기 전에 테스트를 통해 처리해야 합니다. QA 엔지니어는 한 달 반 동안 이 제품을 작업해 왔고 나머지 팀원들은 그의 지원 없이 남겨졌습니다.

이러한 복잡성은 확장으로 인해 발생합니다. 우리는 마이크로서비스가 진공 상태로 존재할 수 없으며 절대적인 격리도 존재하지 않는다는 것을 알고 있습니다. 하나의 서비스를 변경할 때 우리는 항상 API 계약을 유지하려고 노력합니다. 내부적으로 변경 사항이 있어도 프런트 서비스는 그대로 유지됩니다. 변경 사항이 치명적이면 일종의 아키텍처 변형이 발생하고 완전히 호환되지 않는 완전히 다른 데이터 메타 모델로 이동합니다. 그런 다음에야 v2 서비스 API 사양이 나타나는 것에 대해 이야기합니다. 우리는 첫 번째 버전과 두 번째 버전을 동시에 지원하며, 모든 소비자가 두 번째 버전으로 전환한 후에는 첫 번째 버전을 종료하기만 하면 됩니다.

세르게이 :

추가하고 싶습니다. 나는 합병증에 대해 절대적으로 동의합니다. 그런 일이 발생합니다. 환경은 더욱 복잡해지고 있으며, 특히 테스트에 대한 간접비가 증가하고 있습니다. 이를 처리하는 방법: 자동화된 테스트로 전환합니다. 예, 자동 테스트 및 단위 테스트 작성에 추가로 투자해야 합니다. 개발자가 테스트를 통과하지 않고는 커밋을 할 수 없도록 코드를 변경할 수도 없었습니다. 자동 테스트, 단위 테스트 없이는 푸시 버튼도 작동하지 않도록 합니다.

이전 기능을 유지하는 것이 중요하며 이는 추가 오버헤드입니다. 기술을 다른 프로토콜로 다시 작성하면 모든 것이 완전히 종료될 때까지 다시 작성됩니다.

우리는 개발을 중단하고 싶지 않기 때문에 의도적으로 엔드 투 엔드 테스트를 수행하지 않는 경우도 있습니다. 풍경은 매우 크고 복잡하며 많은 시스템이 있습니다. 때로는 단지 스텁일 수도 있습니다. 예, 안전 마진을 낮추면 더 많은 위험이 나타납니다. 그러나 동시에 공급을 해제합니다.

알렉산더 :

예, 자동 테스트와 단위 테스트를 통해 고품질 서비스를 만들 수 있습니다. 우리는 단위 및 통합 테스트 없이는 통과할 수 없는 파이프라인을 지향합니다. 모든 시스템을 테스트 존에 배치할 수는 없기 때문에 에뮬레이터와 상용 시스템을 테스트 존과 개발 환경으로 끌어다 놓아야 하는 경우가 많습니다. 게다가 단순히 물에 젖는 것이 아니라 시스템에서 완전한 응답을 생성합니다. 이는 마이크로서비스 작업에 있어 중요한 부분이며 우리도 여기에 투자하고 있습니다. 이것이 없으면 혼란이 일어날 것입니다.

청중의 질문 (3):

내가 아는 한, 마이크로서비스는 처음에는 별도의 팀에서 성장했으며 현재는 이 모델에 존재합니다. 장점과 단점은 무엇입니까?

비슷한 이야기가 있습니다. 일종의 마이크로서비스 공장이 탄생했습니다. 이제 우리는 개념적으로 이러한 접근 방식을 스트림 및 시스템별 생산으로 확장하는 지점에 도달했습니다. 즉, 우리는 마이크로서비스의 중앙화된 개발, 마이크로서비스 모델에서 벗어나 시스템에 더 가까워지고 있습니다.

따라서 우리의 작업은 시스템에도 적용됩니다. 즉, 이 주제를 분산화하고 있습니다. 당신의 접근 방식은 무엇이며 목표 스토리는 무엇입니까?

알렉산더 :

"마이크로서비스 공장"이라는 이름을 입에서 바로 꺼내셨는데요. 우리도 확장을 원합니다. 첫째, 이제 정말 하나의 팀이 있습니다. 우리는 MegaFon이 보유한 모든 개발팀에게 공통 생태계에서 작업할 수 있는 기회를 제공하고자 합니다. 우리는 현재 가지고 있는 모든 개발 기능을 완전히 인수하고 싶지 않습니다. 로컬 작업은 확장하는 것이고 글로벌 작업은 마이크로서비스 계층의 모든 팀에 대한 개발을 이끄는 것입니다.

세르게이 :

우리가 걸어온 길을 알려드리겠습니다. 우리는 정말 하나의 팀으로 일하기 시작했지만 이제는 혼자가 아닙니다. 나는 다음을 지지합니다: 프로세스의 소유자가 있어야 합니다. 누군가는 마이크로서비스 개발 프로세스를 이해하고, 관리하고, 제어하고, 구축해야 합니다. 그는 자원을 소유하고 자원 관리에 참여해야 합니다.

기술과 세부 사항을 알고 마이크로서비스 구축 방법을 이해하는 이러한 리소스는 제품 팀에 배치될 수 있습니다. 마이크로서비스 플랫폼의 사람들이 모바일 애플리케이션을 만드는 제품 팀에 섞여 있습니다. 그들은 거기에 있지만 개발 관리자와 함께 마이크로 서비스 플랫폼 관리 부서의 프로세스에 따라 일합니다. 이 부서 내에는 기술을 다루는 별도의 팀이 있습니다. 즉, 우리는 공통 자원 풀을 서로 혼합하고 나누어 팀에 제공합니다.

동시에 프로세스는 일반화되고 제어되며 일반 기술 원칙에 따라 진행되며 단위 테스트 등 모든 것이 위에 구축됩니다. 제품 접근 방식의 여러 부서에서 수집한 리소스 형태의 열이 있을 수 있습니다.

알렉산더 :

Sergey, 당신은 실제로 프로세스의 소유자입니다. 그렇죠? 작업 백로그가 공유되나요? 배포는 누가 담당하나요?

세르게이 :

보세요: 여기 다시 믹스가 있습니다. 기술 향상을 기반으로 형성된 백로그가 있는데, 이것이 하나의 이야기입니다. 프로젝트로 구성된 백로그와 제품으로 구성된 백로그가 있습니다. 그러나 각 서비스 제품에 대한 도입 순서나 이 서비스의 생성 순서는 제품 전문가에 의해 개발됩니다. 그는 IT 부서에 속해 있지 않으며 특별히 그곳에서 제거되었습니다. 하지만 우리 직원들은 확실히 같은 프로세스에 따라 일합니다.

다른 방향의 백로그 소유자(변경 백로그)는 다른 사람이 됩니다. 기술 서비스의 연결, 조직 원칙-이 모든 것이 IT에 있습니다. 나는 플랫폼과 리소스도 소유하고 있습니다. 맨 위에는 백로그와 기능 변경, 그리고 이러한 의미에서의 아키텍처와 관련된 내용이 있습니다.

어떤 기업이 "우리는 이 기능을 원하고, 새로운 제품을 만들고 싶고, 대출을 다시 만들고 싶습니다."라고 말한다고 가정해 보겠습니다. 우리는 “예, 다시 실행하겠습니다.”라고 대답합니다. 건축가는 다음과 같이 말합니다. "생각해 봅시다. 대출금의 어디에 마이크로서비스를 작성할 것이며 어떻게 할 것인가?" 그런 다음 이를 프로젝트, 제품 또는 기술 스택으로 나누어 팀에 배치하고 구현합니다. 내부적으로 제품을 만들고 이 제품에 마이크로서비스를 사용하기로 결정하셨나요? 우리는 "이제 우리가 가지고 있던 레거시 시스템, 즉 일선 시스템이 이러한 마이크로서비스로 전환되어야 합니다"라고 말합니다. 설계자들은 이렇게 말합니다. “그래서 일선 제품 내부의 기술 백로그에서 마이크로서비스로의 전환이 이루어졌습니다. 가다". 그리고 제품 전문가나 비즈니스 소유자는 할당된 용량, 할당 시기 및 이유를 이해합니다.

토론이 끝났지만 전부는 아닙니다

mailto:CLOUD 컨퍼런스가 개최되었습니다. Mail.ru 클라우드 솔루션.

우리는 또한 다른 이벤트도 진행합니다. @Kubernetes 모임, 우리는 항상 훌륭한 연사를 찾고 있습니다.

• Telegram 채널에서 @Kubernetes 및 기타 @Meetup 뉴스를 팔로우하세요. t.me/k8s_mail
• @Meetups에서 연설하고 싶으신가요? 요청을 남겨주세요 mcs.mail.ru/speak

출처 : habr.com