Kubernetes 내에서 클라우드 FaaS를 만들고 Tinkoff 해커톤에서 우승한 방법

우리 회사는 작년부터 해커톤을 조직하기 시작했습니다. 그러한 첫 번째 대회는 매우 성공적이었습니다. 우리는 이에 대해 다음과 같이 썼습니다. 기사. 두 번째 해커톤은 2019년 XNUMX월에 열렸으며 그에 못지않게 성공적이었습니다. 얼마 전 후자를 유지하려는 목표에 대해 내가 쓴 조직자.

참가자들에게는 구현을 위한 기술 스택을 완전히 자유롭게 선택할 수 있는 다소 흥미로운 작업이 주어졌습니다. 빠른 애플리케이션 흐름과 함께 작동하고, 높은 로드를 견딜 수 있으며, 시스템 자체가 쉽게 확장될 수 있는 고객 채점 기능을 편리하게 배포하기 위한 의사결정 플랫폼을 구현해야 했습니다.

참가자 프로젝트의 최종 프레젠테이션을 시연하는 동안 확신했듯이 이 작업은 간단하지 않으며 여러 가지 방법으로 해결할 수 있습니다. 해커톤에는 6명으로 구성된 5개 팀이 참여했으며, 참가자 모두 좋은 프로젝트를 진행했지만 우리 플랫폼이 가장 경쟁력이 있는 것으로 나타났습니다. 우리는 이 기사에서 이야기하고 싶은 매우 흥미로운 프로젝트를 가지고 있습니다.

우리의 솔루션은 Kubernetes 내부의 서버리스 아키텍처를 기반으로 하는 플랫폼으로, 새로운 기능을 프로덕션에 적용하는 데 걸리는 시간을 줄여줍니다. 이를 통해 분석가는 편리한 환경에서 코드를 작성하고 엔지니어와 개발자의 참여 없이 프로덕션에 배포할 수 있습니다.

득점이란 무엇인가

많은 현대 회사와 마찬가지로 Tinkoff.ru에는 고객 점수가 있습니다. 스코어링은 데이터 분석의 통계적 방법을 기반으로 한 고객 평가 시스템입니다.

예를 들어, 고객이 우리에게 대출을 요청하거나 개인 기업가 계정을 개설해 달라는 요청을 합니다. 그에게 대출을 제공할 계획이라면 그의 지급 능력을 평가해야 하며, 해당 계좌가 개인 기업가인 경우 고객이 사기 거래를 하지 않도록 해야 합니다.

그러한 결정을 내리는 기초는 애플리케이션 자체의 데이터와 스토리지의 데이터를 모두 분석하는 수학적 모델입니다. 점수 매기기 외에도 고객을 위한 신제품에 대한 개별 권장 사항을 생성하는 서비스에 유사한 통계 방법을 사용할 수도 있습니다.

이러한 평가 방법은 다양한 입력 데이터를 수용할 수 있습니다. 그리고 어느 시점에서는 과거 데이터 분석 결과를 기반으로 서비스 사용 전환율을 높이는 새로운 매개변수를 입력에 추가할 수 있습니다.

우리는 고객 관계에 관한 풍부한 데이터를 보유하고 있으며, 이 정보의 양은 지속적으로 증가하고 있습니다. 점수가 제대로 작동하려면 데이터 처리에 응용 프로그램을 승인할 사람, 거부할 사람, 몇 가지 추가 제품을 제공할 사람을 신속하게 결정하여 잠재적인 관심을 평가할 수 있는 규칙(또는 수학적 모델)도 필요합니다.

당면한 업무를 위해 우리는 이미 전문적인 의사결정 시스템을 사용하고 있습니다. IBM WebSphere ILOG JRules BRMS, 분석가, 기술자 및 개발자가 정한 규칙에 따라 고객에게 특정 은행 상품을 승인할지 거부할지 결정합니다.

시장에는 채점 모델과 의사결정 시스템 자체를 포함하여 기성 솔루션이 많이 있습니다. 우리 회사에서는 이러한 시스템 중 하나를 사용합니다. 그러나 비즈니스는 성장하고 다양화되고 있으며 고객 수와 제공되는 제품 수가 모두 증가하고 있으며 이와 함께 기존 의사 결정 프로세스를 개선하는 방법에 대한 아이디어가 나타나고 있습니다. 확실히 기존 시스템을 사용하는 사람들은 시스템을 더 간단하게, 더 좋게, 더 편리하게 만드는 방법에 대해 많은 아이디어를 갖고 있지만 때로는 외부의 아이디어가 유용할 때도 있습니다. 뉴 해커톤은 건전한 아이디어 수집을 목표로 조직되었습니다.

일

해커톤은 23월 XNUMX일에 개최되었습니다. 참가자들에게는 다양한 조건을 충족해야 하는 의사결정 시스템을 개발하는 전투 임무가 제공되었습니다.

기존 시스템이 어떻게 작동하는지, 운영 과정에서 어떤 어려움이 발생하는지, 개발된 플랫폼이 어떤 사업 목표를 추구해야 하는지에 대해 이야기를 나눴습니다. 시스템은 분석가의 작업 코드가 가능한 한 빨리 생산에 들어갈 수 있도록 규칙 개발을 위한 시장 출시 시간이 빨라야 합니다. 그리고 들어오는 응용 프로그램 흐름의 경우 의사 결정 시간이 최소화되어야 합니다. 또한, 개발 중인 시스템은 당사가 승인하고 고객의 잠재적인 관심이 있는 경우 고객에게 다른 회사 제품을 구매할 수 있는 기회를 제공하기 위해 교차 판매 기능을 갖추고 있어야 합니다.

확실히 프로덕션에 들어갈 준비가 된 프로젝트를 하룻밤 사이에 작성하는 것은 불가능하고 전체 시스템을 포괄하는 것도 꽤 어렵기 때문에 우리는 그 중 적어도 일부를 구현해 달라는 요청을 받았습니다. 프로토타입이 충족해야 하는 여러 가지 요구 사항이 설정되었습니다. 모든 요구 사항을 전체적으로 충족하는 동시에 개발 중인 플랫폼의 개별 섹션에 대해 세부적으로 작업하는 것이 가능했습니다.

기술에 관해서는 모든 참가자에게 완전한 선택의 자유가 주어졌습니다. 데이터 스트리밍, 머신러닝, 이벤트 소싱, 빅데이터 등 모든 개념과 기술을 사용할 수 있었습니다.

우리의 솔루션

약간의 브레인스토밍 끝에 우리는 FaaS 솔루션이 작업을 완료하는 데 이상적이라고 결정했습니다.

이 솔루션의 경우 개발 중인 의사결정 시스템의 규칙을 구현하는 데 적합한 서버리스 프레임워크를 찾는 것이 필요했습니다. Tinkoff는 인프라 관리를 위해 Kubernetes를 적극적으로 사용하고 있으므로 이를 기반으로 기성 솔루션을 여러 가지 살펴보았는데 이에 대한 자세한 내용은 나중에 설명하겠습니다.

가장 효과적인 솔루션을 찾기 위해 우리는 사용자의 눈으로 개발 중인 제품을 살펴보았습니다. 우리 시스템의 주요 사용자는 규칙 개발에 참여하는 분석가입니다. 규칙은 서버에 배포되어야 하며, 우리의 경우처럼 후속 의사 결정을 위해 클라우드에 배포되어야 합니다. 분석가의 관점에서 워크플로는 다음과 같습니다.

1. 분석가는 웨어하우스의 데이터를 기반으로 스크립트, 규칙 또는 ML 모델을 작성합니다. 해커톤의 일환으로 MongoDB를 사용하기로 결정했지만 여기서는 데이터 저장 시스템의 선택이 중요하지 않습니다.
2. 분석가는 기록 데이터에 대해 개발된 규칙을 테스트한 후 자신의 코드를 관리 패널에 업로드합니다.
3. 버전 관리를 위해 모든 코드는 Git 리포지토리로 이동됩니다.
4. 관리 패널을 통해 코드를 별도의 기능적 서버리스 모듈로 클라우드에 배포할 수 있습니다.

클라이언트의 초기 데이터는 웨어하우스의 데이터로 초기 요청을 강화하도록 설계된 특수 강화 서비스를 통과해야 합니다. 단일 저장소(분석가가 규칙을 개발할 때 데이터를 가져오는 저장소)와 작동하여 통합된 데이터 구조를 유지하는 방식으로 이 서비스를 구현하는 것이 중요했습니다.

해커톤 이전에도 우리는 사용할 서버리스 프레임워크를 결정했습니다. 오늘날 이 접근 방식을 구현하는 기술이 시장에 많이 나와 있습니다. Kubernetes 아키텍처 내에서 가장 널리 사용되는 솔루션은 Fission, Open FaaS 및 Kubeless입니다. 심지어 있다 설명과 비교 분석이 담긴 좋은 기사.

장단점을 모두 따져본 후 선택하게 된 것은 분열. 이 서버리스 프레임워크는 관리가 매우 쉽고 작업 요구 사항을 충족합니다.

Fission을 사용하려면 기능과 환경이라는 두 가지 기본 개념을 이해해야 합니다. 함수는 Fission 환경이 있는 언어 중 하나로 작성된 코드 조각입니다. 이 프레임워크 내에 구현된 환경 목록 Python, JS, Go, JVM 및 기타 널리 사용되는 언어 및 기술이 포함됩니다.

Fission은 또한 여러 파일로 나누어 아카이브로 미리 패키지된 기능을 수행할 수 있습니다. Kubernetes 클러스터에서 Fission의 작동은 프레임워크 자체에서 관리되는 특수 포드에 의해 보장됩니다. 클러스터 포드와 상호 작용하려면 각 함수에 자체 경로가 할당되어야 하며 POST 요청의 경우 GET 매개변수 또는 요청 본문을 전달할 수 있습니다.

결과적으로 우리는 엔지니어와 개발자의 참여 없이 분석가가 개발된 규칙 스크립트를 배포할 수 있는 솔루션을 얻을 계획이었습니다. 또한 설명된 접근 방식을 사용하면 개발자가 분석 코드를 다른 언어로 다시 작성할 필요가 없습니다. 예를 들어, 우리가 사용하는 현재 의사결정 시스템의 경우 고도로 전문화된 기술과 언어로 규칙을 작성해야 하며 그 범위는 극도로 제한되어 있으며 모든 은행 규칙 초안이 있기 때문에 애플리케이션 서버에 대한 의존도가 높습니다. 단일 환경에 배포됩니다. 결과적으로 새로운 규칙을 배포하려면 전체 시스템을 릴리스해야 합니다.

우리가 제안한 솔루션에서는 규칙을 공개할 필요가 없으며 버튼 클릭만으로 코드를 쉽게 배포할 수 있습니다. 또한 Kubernetes의 인프라 관리를 사용하면 로드 및 확장에 대해 생각할 필요가 없으며 이러한 문제는 즉시 해결됩니다. 그리고 단일 데이터 웨어하우스를 사용하면 실시간 데이터와 기록 데이터를 비교할 필요가 없어 분석가의 작업이 단순화됩니다.

우리가 얻은 것

우리는 기성 솔루션(우리의 환상 속에서)을 가지고 해커톤에 왔기 때문에 우리가 해야 할 일은 우리의 모든 생각을 코드 라인으로 변환하는 것뿐이었습니다.

모든 해커톤에서 성공의 열쇠는 준비와 잘 작성된 계획입니다. 따라서 우리가 가장 먼저 한 일은 시스템 아키텍처가 어떤 모듈로 구성되고 어떤 기술을 사용할지 결정하는 것이었습니다.

우리 프로젝트의 아키텍처는 다음과 같습니다.

이 다이어그램은 분석가(우리 시스템의 주요 사용자)와 클라이언트라는 두 개의 진입점을 보여줍니다.

업무 프로세스는 이렇게 구성되어 있습니다. 분석가는 자신의 모델에 대한 규칙 기능과 데이터 강화 기능을 개발하고 Git 저장소에 코드를 저장하며 관리자 애플리케이션을 통해 모델을 클라우드에 배포합니다. 배포된 함수가 어떻게 호출되고 클라이언트로부터 들어오는 요청에 대해 결정을 내리는 방법을 고려해 보겠습니다.

1. 클라이언트는 웹사이트에서 양식을 작성하고 컨트롤러에게 요청을 보냅니다. 결정을 내려야 하는 신청서는 시스템 입력으로 들어오고 원래 형식으로 데이터베이스에 기록됩니다.
2. 다음으로 필요한 경우 보강을 위해 원시 요청이 전송됩니다. 외부 서비스와 스토리지의 데이터로 초기 요청을 보완할 수 있습니다. 결과 강화 쿼리도 데이터베이스에 저장됩니다.
3. 강화된 쿼리를 입력으로 사용하고 스토리지에도 기록되는 솔루션을 생성하는 분석 기능이 시작됩니다.

원래 요청을 포함한 보강 서비스가 REST 컨트롤러를 통해 모든 데이터를 집계했기 때문에 JSON 문서 형식의 문서 중심 데이터 저장으로 인해 MongoDB를 시스템의 저장소로 사용하기로 결정했습니다.

따라서 플랫폼을 구현하는 데 XNUMX시간이 걸렸습니다. 우리는 역할을 매우 성공적으로 분배했으며 각 팀원은 프로젝트에서 자신의 책임 영역을 가졌습니다.

1. 분석가의 작업을 위한 프런트 엔드 관리 패널을 통해 작성된 스크립트의 버전 제어 시스템에서 규칙을 다운로드하고, 입력 데이터를 강화하기 위한 옵션을 선택하고, 규칙 스크립트를 온라인으로 편집할 수 있습니다.
2. 프론트용 REST API 및 VCS와의 통합을 포함한 백엔드 관리입니다.
3. Google Cloud에 인프라를 설정하고 소스 데이터 보강을 위한 서비스를 개발합니다.
4. 후속 규칙 배포를 위해 관리 애플리케이션을 서버리스 프레임워크와 통합하기 위한 모듈입니다.
5. 전체 시스템의 성능을 테스트하고 최종 시연을 위해 수신 애플리케이션(결정)에 대한 분석 집계를 테스트하기 위한 규칙 스크립트입니다.

의 순서대로 시작하자.

우리의 프론트엔드는 뱅킹 UI 키트를 사용하여 Angular 7로 작성되었습니다. 관리자 패널의 최종 버전은 다음과 같습니다.

시간이 부족해서 핵심 기능만 구현하려고 했습니다. 쿠버네티스 클러스터에 기능을 배포하려면 이벤트(클라우드에 규칙을 배포해야 하는 서비스)와 의사결정 로직을 구현하는 기능의 코드를 선택해야 했습니다. 선택한 서비스에 대한 규칙을 배포할 때마다 이 이벤트에 대한 로그를 작성했습니다. 관리자 패널에서는 모든 이벤트의 로그를 볼 수 있습니다.

모든 함수 코드는 원격 Git 저장소에 저장되었으며 관리 패널에서도 설정해야 했습니다. 코드 버전을 관리하기 위해 모든 기능은 저장소의 다른 분기에 저장되었습니다. 관리자 패널은 작성된 스크립트를 조정할 수 있는 기능도 제공하므로 프로덕션에 기능을 배포하기 전에 작성된 코드를 확인할 수 있을 뿐만 아니라 필요한 변경도 수행할 수 있습니다.

규칙 기능 외에도 우리는 강화 기능을 사용하여 소스 데이터를 점진적으로 강화하는 기능도 구현했습니다. 그 코드는 데이터 웨어하우스로 이동하고 타사 서비스를 호출하고 예비 계산을 수행할 수 있는 스크립트이기도 했습니다. . 우리의 솔루션을 시연하기 위해 우리는 요청을 떠난 클라이언트의 별자리를 계산하고 타사 REST 서비스를 사용하여 그의 이동 통신사를 결정했습니다.

플랫폼의 백엔드는 Java로 작성되었으며 Spring Boot 애플리케이션으로 구현되었습니다. 처음에는 Postgres를 사용하여 관리 데이터를 저장할 계획이었지만 해커톤의 일환으로 시간을 절약하기 위해 간단한 H2로 제한하기로 결정했습니다. 백엔드에서는 쿼리 보강 기능과 규칙 스크립트의 버전을 지정하기 위해 Bitbucket과의 통합이 구현되었습니다. 원격 Git 저장소와의 통합을 위해 우리는 다음을 사용했습니다. JGit 라이브러리, 이는 CLI 명령에 대한 일종의 래퍼로, 편리한 소프트웨어 인터페이스를 사용하여 모든 git 명령을 실행할 수 있습니다. 그래서 우리는 강화 기능과 규칙을 위한 두 개의 별도 저장소를 갖고 있었고 모든 스크립트는 디렉터리로 나누어졌습니다. UI를 통해 저장소의 임의 분기에 대한 스크립트의 최신 커밋을 선택할 수 있었습니다. 관리자 패널을 통해 코드를 변경할 때 변경된 코드의 커밋이 원격 저장소에 생성되었습니다.

우리의 아이디어를 구현하려면 적절한 인프라가 필요했습니다. 우리는 Kubernetes 클러스터를 클라우드에 배포하기로 결정했습니다. 우리의 선택은 Google Cloud Platform이었습니다. Fission 서버리스 프레임워크는 우리가 Gcloud에 배포한 Kubernetes 클러스터에 설치되었습니다. 처음에는 소스 데이터 보강 서비스가 k8s 클러스터 내부의 Pod에 래핑된 별도의 Java 애플리케이션으로 구현되었습니다. 그러나 해커톤 중간에 우리 프로젝트의 예비 시연 이후, 우리는 수신 애플리케이션의 원시 데이터를 강화하는 방법을 선택할 수 있는 기회를 제공하기 위해 강화 서비스를 보다 유연하게 만들 것을 권장했습니다. 그리고 우리는 강화 서비스도 서버리스로 만들 수밖에 없었습니다.

Fission을 사용하기 위해 우리는 Kubernetes CLI 위에 설치해야 하는 Fission CLI를 사용했습니다. k8s 클러스터에 기능을 배포하는 것은 매우 간단합니다. 클러스터 외부 액세스가 필요한 경우 들어오는 트래픽을 허용하기 위해 내부 경로를 할당하고 함수에 수신하기만 하면 됩니다. 하나의 기능을 배포하는 데 일반적으로 10초가 채 걸리지 않습니다.

프로젝트 최종 발표 및 요약

우리 시스템이 어떻게 작동하는지 보여주기 위해 우리는 은행 상품 중 하나에 대한 신청서를 제출할 수 있는 원격 서버에 간단한 양식을 배치했습니다. 신청하려면 이니셜, 생년월일, 전화번호를 입력해야 했습니다.

클라이언트 양식의 데이터는 컨트롤러로 이동하여 사용 가능한 모든 규칙에 대한 요청을 동시에 보내고 지정된 조건에 따라 이전에 데이터를 강화하여 공통 저장소에 저장했습니다. 전체적으로 우리는 수신 애플리케이션에 대한 결정을 내리는 기능 4개와 데이터 강화 서비스 XNUMX개를 배포했습니다. 신청서를 제출한 후 고객은 다음과 같은 결정을 받았습니다.

거부 또는 승인 외에도 고객은 우리가 동시에 보낸 요청인 다른 제품 목록도 받았습니다. 이것이 우리 플랫폼에서 교차 판매 가능성을 입증한 방법입니다.

총 3개의 가상 은행 상품이 있었습니다:

• 신용 거래.
• 장난감
• 저당.

시연 중에 우리는 각 서비스에 대해 준비된 기능과 강화 스크립트를 배포했습니다.

각 규칙에는 고유한 입력 데이터 세트가 필요했습니다. 그래서 모기지를 승인하기 위해 우리는 고객의 별자리를 계산하고 이를 음력 논리와 연결했습니다. 장난감 승인을 위해 고객이 성년이 되었는지 확인하고, 대출을 위해 외부 공개 서비스에 이동통신사 확인 요청을 보내고 이에 대한 결정을 내렸습니다.

우리는 데모를 흥미롭고 대화형으로 만들려고 노력했으며 참석한 모든 사람이 우리 양식으로 이동하여 가상 서비스의 가용성을 확인할 수 있었습니다. 그리고 프레젠테이션 마지막에는 접수된 지원서에 대한 분석을 시연했는데, 이를 통해 우리 서비스를 사용한 사람 수, 승인 횟수, 거부 횟수를 알 수 있었습니다.

온라인으로 분석 내용을 수집하기 위해 오픈 소스 BI 도구를 추가로 배포했습니다. 메타베이스 그리고 그것을 우리 저장 장치에 나사로 고정했습니다. 메타베이스를 사용하면 관심 있는 데이터에 대한 분석이 포함된 화면을 구축할 수 있습니다. 데이터베이스에 대한 연결을 등록하고 테이블(우리의 경우에는 MongoDB를 사용했기 때문에 데이터 컬렉션)을 선택한 다음 관심 있는 필드를 지정하기만 하면 됩니다. .

그 결과 우리는 의사결정 플랫폼의 좋은 프로토타입을 얻었고, 시연 중에 각 청취자가 직접 그 성능을 확인할 수 있었습니다. 흥미로운 솔루션, 완성된 프로토타입, 성공적인 시연 덕분에 다른 팀과의 치열한 경쟁에도 불구하고 우리는 승리할 수 있었습니다. 각 팀의 프로젝트에도 흥미로운 글이 쓰일 수 있을 거라 확신합니다.

출처 : habr.com