미하일 살로신. 골랑 밋업. Look+ 애플리케이션의 백엔드에서 Go 사용

미하일 살로신(이하 – MS): - 안녕하세요 여러분! 내 이름은 마이클입니다. 저는 MC2 Software에서 백엔드 개발자로 일하고 있습니다. Look+ 모바일 애플리케이션의 백엔드에서 Go를 사용하는 방법에 대해 이야기하겠습니다.

여기 하키 좋아하는 사람 있나요?

그렇다면 이 응용 프로그램은 당신을 위한 것입니다. Android 및 iOS 용이며 온라인에서 다양한 스포츠 이벤트 방송을 시청하고 녹화하는 데 사용됩니다. 이 애플리케이션에는 다양한 통계, 문자 방송, 컨퍼런스 테이블, 토너먼트 및 팬에게 유용한 기타 정보도 포함되어 있습니다.

또한 응용 프로그램에는 비디오 순간과 같은 것이 있습니다. 즉, 경기의 가장 중요한 순간(골, 싸움, 승부차기 등)을 시청할 수 있습니다. 방송 전체를 시청하고 싶지 않다면 가장 흥미로운 방송만 시청하면 됩니다.

개발에 무엇을 사용하셨나요?

주요 부분은 Go로 작성되었습니다. 모바일 클라이언트와 통신하는 API는 Go로 작성되었습니다. 휴대폰으로 푸시 알림을 보내는 서비스도 Go로 작성되었습니다. 우리는 또한 언젠가 이야기하게 될 자체 ORM을 작성해야 했습니다. 글쎄, 일부 작은 서비스는 Go로 작성되었습니다: 편집자를 위한 이미지 크기 조정 및 로드...

데이터베이스로는 PostgreSQL을 사용했습니다. 편집기 인터페이스는 ActiveAdmin gem을 사용하여 Ruby on Rails로 작성되었습니다. 통계 제공자로부터 통계를 가져오는 것도 Ruby로 작성되었습니다.

시스템 API 테스트에는 Python 단위 테스트를 사용했습니다. Memcached는 API 결제 호출을 조절하는 데 사용되고, "Chef"는 구성을 제어하는 ​​데 사용되며, Zabbix는 내부 시스템 통계를 수집하고 모니터링하는 데 사용됩니다. Graylog2는 로그 수집용이고 Slate는 클라이언트용 API 문서입니다.

프로토콜 선택

우리가 직면한 첫 번째 문제: 우리는 다음 사항을 기반으로 백엔드와 모바일 클라이언트 간의 상호 작용을 위한 프로토콜을 선택해야 했습니다.

• 가장 중요한 요구 사항은 클라이언트의 데이터가 실시간으로 업데이트되어야 한다는 것입니다. 즉, 현재 방송을 시청하고 있는 모든 사람은 거의 즉시 업데이트를 받아야 합니다.
• 단순화를 위해 클라이언트와 동기화된 데이터는 삭제되지 않고 특수 플래그를 사용하여 숨겨지는 것으로 가정했습니다.
• 모든 종류의 드문 요청(통계, 팀 구성, 팀 통계 등)은 일반적인 GET 요청을 통해 획득됩니다.
• 게다가 시스템은 동시에 100만명의 사용자를 쉽게 지원해야 했습니다.

이를 기반으로 두 가지 프로토콜 옵션이 있었습니다.

1. 웹소켓. 그러나 클라이언트에서 서버로의 채널은 필요하지 않았습니다. 서버에서 클라이언트로 업데이트만 보내면 되므로 웹소켓은 중복 옵션입니다.
2. 서버 전송 이벤트(SSE)가 바로 나타났습니다! 이는 매우 간단하며 기본적으로 필요한 모든 것을 충족합니다.

서버에서 보낸 이벤트

이 작업이 어떻게 작동하는지에 대해 몇 마디...

http 연결 위에서 실행됩니다. 클라이언트가 요청을 보내고 서버는 Content-Type: text/event-stream으로 응답하고 클라이언트와의 연결을 닫지 않지만 계속해서 연결에 데이터를 씁니다.

데이터는 고객과 합의된 형식으로 전송될 수 있습니다. 우리의 경우에는 변경된 구조(사람, 플레이어)의 이름이 이벤트 필드로 전송되고, 플레이어에 대해 새로 변경된 필드가 포함된 JSON이 데이터 필드로 전송되는 형식으로 보냈습니다.

이제 상호작용 자체가 어떻게 작동하는지 이야기해 보겠습니다.

• 클라이언트가 가장 먼저 하는 일은 서비스와의 마지막 동기화가 수행된 시간을 확인하는 것입니다. 즉, 로컬 데이터베이스를 살펴보고 마지막 변경 사항이 기록된 날짜를 확인합니다.
• 이 날짜로 요청을 보냅니다.
• 이에 대한 응답으로 우리는 해당 날짜 이후 발생한 모든 업데이트를 그에게 보냅니다.
• 그 후에는 라이브 채널에 연결되며 다음 업데이트가 필요할 때까지 닫히지 않습니다.

우리는 그에게 변경 사항 목록을 보냅니다. 누군가 골을 넣으면 경기 점수가 변경되고, 그가 부상을 입으면 이 내용도 실시간으로 전송됩니다. 따라서 클라이언트는 경기 이벤트 피드에서 최신 데이터를 즉시 수신합니다. 주기적으로 클라이언트가 서버가 종료되지 않았으며 서버에 아무 일도 일어나지 않았음을 이해할 수 있도록 15초마다 타임스탬프를 보냅니다. 그러면 모든 것이 정상이고 다시 연결할 필요가 없음을 알 수 있습니다.

실시간 연결 서비스는 어떻게 제공되나요?

• 우선, 버퍼링된 업데이트를 수신할 채널을 만듭니다.
• 그 후에는 이 채널을 구독하여 업데이트를 받습니다.
• 클라이언트가 모든 것이 정상임을 알 수 있도록 올바른 헤더를 설정했습니다.
• 첫 번째 핑을 보냅니다. 우리는 단순히 현재 연결 타임스탬프를 기록합니다.
• 그런 다음 업데이트 채널이 닫힐 때까지 루프의 채널에서 읽습니다. 채널은 현재 타임스탬프나 열린 연결에 이미 쓰고 있는 변경 사항을 주기적으로 수신합니다.

우리가 직면한 첫 번째 문제는 다음과 같습니다. 클라이언트에서 열린 각 연결에 대해 15초마다 한 번씩 작동하는 타이머를 만들었습니다. 하나의 시스템(하나의 API 서버 포함)에서 6개의 연결이 열린 경우 6 수천 개의 타이머가 생성되었습니다. 이로 인해 기계가 필요한 하중을 유지하지 못하게 되었습니다. 문제는 우리에게 그다지 명확하지 않았지만 약간의 도움을 받아 문제를 해결했습니다.

결과적으로 이제 핑은 업데이트가 제공되는 동일한 채널에서 제공됩니다.

따라서 15초마다 한 번씩 작동하는 타이머는 하나만 있습니다.

여기에는 헤더, 핑 및 구조 자체를 보내는 몇 가지 보조 기능이 있습니다. 즉, 테이블 이름(사람, 경기, 시즌)과 이 항목에 대한 정보가 여기로 전송됩니다.

업데이트 전송 메커니즘

이제 변경 사항이 어디에서 왔는지에 대해 조금 설명합니다. 실시간으로 방송을 시청하는 편집자 분들이 여럿 계십니다. 그들은 모든 이벤트를 만듭니다. 누군가는 퇴장당했고, 누군가는 부상을 입었고, 어떤 종류의 교체 선수가 생겼습니다...

CMS를 사용하면 데이터가 데이터베이스에 입력됩니다. 그런 다음 데이터베이스는 Listen/Notify 메커니즘을 사용하여 이에 대해 API 서버에 알립니다. API 서버는 이미 이 정보를 클라이언트에 보냅니다. 따라서 기본적으로 데이터베이스에 연결된 서버는 몇 대뿐이며 클라이언트가 어떤 방식으로든 데이터베이스와 직접 상호 작용하지 않기 때문에 데이터베이스에 특별한 로드가 없습니다.

PostgreSQL: 수신/알림

Postgres의 수신/알림 메커니즘을 사용하면 일부 이벤트가 변경되었음을 이벤트 구독자에게 알릴 수 있습니다. 일부 레코드가 데이터베이스에 생성되었습니다. 이를 위해 간단한 트리거와 함수를 작성했습니다.

레코드를 삽입하거나 변경할 때 data_updates 채널에서 알림 함수를 호출하여 테이블 이름과 변경되거나 삽입된 레코드의 식별자를 전달합니다.

클라이언트와 동기화해야 하는 모든 테이블에 대해 레코드를 변경/업데이트한 후 아래 슬라이드에 표시된 함수를 호출하는 트리거를 정의합니다.
API는 이러한 변경 사항을 어떻게 구독합니까?

팬아웃 메커니즘이 생성되어 클라이언트에 메시지를 보냅니다. 모든 고객 채널을 수집하고 다음 채널을 통해 받은 업데이트를 보냅니다.

여기서 데이터베이스에 연결하고 채널(data_updates)을 수신하겠다고 말하는 표준 pq 라이브러리는 연결이 열려 있고 모든 것이 정상인지 확인합니다. 공간을 절약하기 위해 오류 검사를 생략하고 있습니다(검사하지 않는 것은 위험합니다).

다음으로, 15초마다 핑을 보내는 Ticker를 비동기적으로 설정하고 우리가 구독한 채널 청취를 시작합니다. 핑을 받으면 이 핑을 게시합니다. 어떤 종류의 항목이 수신되면 해당 항목을 이 팬아웃의 모든 구독자에게 게시합니다.

팬아웃은 어떻게 작동하나요?

러시아어에서는 "분배기"로 번역됩니다. 일부 업데이트를 수신하려는 구독자를 등록하는 개체가 하나 있습니다. 그리고 이 개체에 업데이트가 도착하자마자 이 업데이트를 모든 구독자에게 배포합니다. 충분히 간단합니다.

Go에서 구현되는 방법:

구조가 있으며 Mutex를 사용하여 동기화됩니다. 여기에는 Fanout의 데이터베이스 연결 상태를 저장하는 필드가 있습니다. 즉, 현재 수신 중이며 업데이트를 수신할 뿐만 아니라 사용 가능한 모든 채널 목록(맵, 키는 채널 및 구조체 형식)을 수신합니다. 값(본질적으로 어떤 방식으로도 사용되지 않음).

연결됨(Connected) 및 연결 끊김(Disconnected)이라는 두 가지 방법을 사용하면 베이스에 연결되어 있고 베이스에 대한 연결이 끊어졌음을 팬아웃에 알릴 수 있습니다. 두 번째 경우에는 모든 클라이언트의 연결을 끊고 더 이상 아무것도 들을 수 없으며 연결이 끊어졌기 때문에 다시 연결한다고 알려야 합니다.

"청취자"에 채널을 추가하는 Subscribe 메소드도 있습니다.

클라이언트 연결이 끊어지면 리스너에서 채널을 제거하는 Unsubscribe 메서드와 모든 구독자에게 메시지를 보낼 수 있는 Publish 메서드가 있습니다.

질문 : – 이 채널을 통해 무엇이 전송되나요?

MS: – 변경된 모델 또는 ping이 전송됩니다(기본적으로 숫자, 정수만).

MS: – 무엇이든 보내고, 어떤 구조든 보내고, 게시할 수 있습니다. JSON으로 변환하면 그게 전부입니다.

MS: – Postgres로부터 알림을 받습니다. 여기에는 테이블 이름과 식별자가 포함되어 있습니다. 테이블 이름과 식별자를 기반으로 필요한 레코드를 얻은 다음 이 구조를 게시용으로 보냅니다.

하부 구조

인프라 관점에서 볼 때 이는 어떤 모습입니까? 우리는 7개의 하드웨어 서버를 보유하고 있습니다. 그 중 하나는 데이터베이스 전용이고 나머지 6개는 가상 머신을 실행합니다. API 사본은 XNUMX개가 있습니다. API가 있는 각 가상 머신은 별도의 하드웨어 서버에서 실행됩니다. 이는 안정성을 위한 것입니다.

접근성을 향상시키기 위해 Keepalived가 설치된 두 개의 프런트엔드가 있으므로 문제가 발생하면 하나의 프런트엔드가 다른 프런트엔드를 대체할 수 있습니다. 또한 – CMS 사본 XNUMX개.

통계 수입업체도 있습니다. 주기적으로 백업이 이루어지는 DB 슬레이브가 있습니다. Zabbix, Graylog2 및 Chef와 같은 인프라 항목뿐만 아니라 클라이언트에 푸시 알림을 보내는 애플리케이션인 Pigeon Pusher가 있습니다.

실제로 이 인프라는 중복됩니다. 더 적은 수의 서버로 100만 대에 서비스를 제공할 수 있기 때문입니다. 그러나 철이있었습니다 – 우리는 그것을 사용했습니다 (우리는 그것이 가능하다고 들었습니다 – 왜 안됩니까).

바둑의 장점

우리가 이 애플리케이션을 작업한 후에 Go의 이러한 명백한 장점이 드러났습니다.

• 멋진 http 라이브러리. 그것으로 당신은 즉시 많은 것을 만들 수 있습니다.
• 또한 클라이언트에게 알림을 보내는 메커니즘을 매우 쉽게 구현할 수 있는 채널도 있습니다.
• 놀라운 점은 Race 감지기를 사용하여 몇 가지 중요한 버그(스테이징 인프라)를 제거할 수 있다는 것입니다. 스테이징에서 작동하는 모든 것이 실행되고 Race 키로 컴파일됩니다. 따라서 우리는 스테이징 인프라를 살펴보고 어떤 잠재적인 문제가 있는지 확인할 수 있습니다.
• 미니멀리즘과 언어의 단순성.

우리는 개발자를 찾고 있습니다! 원하시는 분 계시면 부탁드립니다.

질문

청중의 질문(이하 – B): – 팬아웃과 관련하여 중요한 점 하나를 놓치신 것 같습니다. 클라이언트에게 응답을 보낼 때 클라이언트가 읽기를 원하지 않으면 차단한다는 것을 이해하는 것이 맞습니까?

MS: - 아니요, 차단하지 않습니다. 첫째, nginx 뒤에는 이 모든 것이 있습니다. 즉, 느린 클라이언트에는 문제가 없습니다. 둘째, 클라이언트에는 버퍼가 있는 채널이 있습니다. 실제로 거기에 최대 XNUMX개의 업데이트를 넣을 수 있습니다. 채널에 쓸 수 없으면 채널이 삭제됩니다. 채널이 차단된 것을 확인하면 채널을 닫으면 됩니다. 문제가 발생하면 클라이언트가 다시 연결됩니다. 따라서 원칙적으로 여기에는 차단이 없습니다.

에서 : – 식별자 테이블이 아닌 Listen/Notify에 레코드를 즉시 보내는 것은 불가능합니까?

MS: – 수신/알림에는 전송하는 사전 로드가 8바이트로 제한됩니다. 원칙적으로는 적은 양의 데이터를 처리한다면 전송이 가능하겠지만, 제가 보기엔 이 방법이 더 안정적일 것 같습니다. 제한 사항은 Postgres 자체에 있습니다.

에서 : – 클라이언트는 관심이 없는 경기에 대한 업데이트를 받나요?

MS: - 일반적으로 그렇습니다. 일반적으로 2-3개의 경기가 동시에 진행되며 심지어 아주 드물게 진행됩니다. 클라이언트가 무언가를 보고 있다면 대개는 진행 중인 경기를 보고 있는 것입니다. 그런 다음 클라이언트에는 이러한 모든 업데이트가 추가되는 로컬 데이터베이스가 있으며, 인터넷 연결 없이도 클라이언트는 업데이트가 있는 과거 일치 항목을 모두 볼 수 있습니다. 기본적으로 우리는 클라이언트가 오프라인으로 작업할 수 있도록 서버에 있는 데이터베이스를 클라이언트의 로컬 데이터베이스와 동기화합니다.

에서 : – 왜 ORM을 직접 만들었나요?

Alexey(Look+ 개발자 중 한 명): – 그 당시(XNUMX년 전)에는 ORM이 꽤 많았던 지금보다 ORM 수가 적었습니다. 대부분의 ORM에서 제가 가장 좋아하는 점은 대부분이 빈 인터페이스에서 실행된다는 것입니다. 즉, 이러한 ORM의 메서드는 구조, 구조 포인터, 숫자, 전혀 관련 없는 것 등 무엇이든 처리할 준비가 되어 있습니다.

우리 ORM은 데이터 모델을 기반으로 구조를 생성합니다. 내 자신. 따라서 모든 방법은 구체적이며 반사 등을 사용하지 않습니다. 그들은 구조를 받아들이고 그에 따른 구조를 사용할 것으로 기대합니다.

에서 : – 몇 명이 참여했나요?

MS: – 초기에는 XNUMX명이 참여했다. 우리는 XNUMX월쯤에 시작했고 XNUMX월에 주요 부분(첫 번째 버전)이 준비되었습니다. XNUMX월에 출시가 있었습니다.

에서 : – SSE를 설명하는 경우에는 시간 초과를 사용하지 않습니다. 왜 그런 겁니까?

MS: – 솔직히 말해서 SSE는 여전히 html5 프로토콜입니다. 제가 이해하는 한 SSE 표준은 브라우저와 통신하도록 설계되었습니다. 브라우저가 다시 연결할 수 있도록 하는 추가 기능(등)이 있지만 정보 연결 및 수신을 위한 모든 논리를 구현할 수 있는 클라이언트가 있었기 때문에 해당 기능이 필요하지 않습니다. 우리는 SSE를 만든 것이 아니라 SSE와 비슷한 것을 만들었습니다. 이것은 프로토콜 자체가 아닙니다.
필요가 없었습니다. 내가 아는 한 클라이언트는 거의 처음부터 연결 메커니즘을 구현했습니다. 그들은별로 신경 쓰지 않았습니다.

에서 : – 추가로 어떤 유틸리티를 사용하셨나요?

MS: – 스타일 통일을 위해 govet과 golint를 가장 적극적으로 활용했고, gofmt도 활용했습니다. 다른 것은 사용되지 않았습니다.

에서 : – 디버깅에 무엇을 사용했나요?

MS: – 디버깅은 주로 테스트를 통해 이루어졌습니다. 우리는 디버거나 GOP를 사용하지 않았습니다.

에서 : – Publish 기능이 구현된 슬라이드를 돌려주실 수 있나요? 한 글자로 된 변수 이름이 혼란스럽나요?

MS: - 아니요. 가시성의 범위가 상당히 "좁습니다". 여기를 제외한 다른 곳에서는 사용되지 않으며(이 클래스의 내부를 제외하고) 매우 컴팩트합니다. 단 7줄만 필요합니다.

에서 : – 왠지 아직은 직관적이지 않은데…

MS: - 아냐 아냐 이건 진짜 코드야! 스타일에 관한 것이 아닙니다. 그것은 매우 실용적이고 매우 작은 클래스입니다. 클래스 내부에는 필드가 3개뿐입니다.

MS: – 대체로 클라이언트(시즌 경기, 선수)와 동기화되는 모든 데이터는 변경되지 않습니다. 대략적으로 말하면, 경기를 변경해야 하는 다른 스포츠를 만들 경우 새 버전의 클라이언트에서 모든 것을 고려하고 이전 버전의 클라이언트는 금지됩니다.

에서 : – 타사 종속성 관리 패키지가 있습니까?

MS: – 우리는 go dep을 사용했습니다.

에서 : -제보 주제에 영상 관련 내용이 있었는데, 영상 관련 내용은 전혀 없었습니다.

MS: – 아니요, 영상에 관한 주제에 대해서는 아무 것도 없습니다. "Look+"라고 합니다. 이것이 바로 애플리케이션의 이름입니다.

에서 : -클라이언트에게 스트리밍된다고 했죠?..

MS: – 우리는 비디오 스트리밍에 관여하지 않았습니다. 이것은 전적으로 Megafon에 의해 수행되었습니다. 예, 해당 애플리케이션이 MegaFon이라고 말하지 않았습니다.

MS: – Go – 모든 데이터 전송 – 점수, 경기 이벤트, 통계 등 Go는 애플리케이션의 전체 백엔드입니다. 클라이언트는 사용자가 경기를 볼 수 있도록 플레이어에 대해 사용할 링크를 어딘가에서 알아야 합니다. 준비한 영상과 스트리밍 링크를 올려드립니다.

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $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