ミハイル・サロシン。 Golang ミートアップ。 Look+ アプリケーションのバックエンドで Go を使用する

ミハイル・サロシン（以下、MS）： - こんにちは、みんな！ 私の名前はマイケルです。 私は MC2 Software でバックエンド開発者として働いており、Look+ モバイル アプリケーションのバックエンドでの Go の使用についてお話します。

ここにホッケーが好きな人はいますか？

それなら、このアプリケーションはあなたのためです。 Android と iOS 用で、さまざまなスポーツ イベントの放送をオンラインで視聴したり録画したりするために使用されます。 このアプリケーションには、さまざまな統計、テキストブロードキャスト、カンファレンス、トーナメントのテーブル、およびファンにとって役立つその他の情報も含まれています。

また、アプリケーションにはビデオモーメントのようなものもあります。つまり、試合の最も重要な瞬間（ゴール、戦い、シュートアウトなど）を見ることができます。 放送全体を視聴したくない場合は、最も興味深いものだけを視聴することができます。

開発では何を使用しましたか?

主要部分は Go で書かれています。 モバイル クライアントが通信する API は Go で書かれていました。 携帯電話にプッシュ通知を送信するサービスも Go で作成されました。 また、独自の ORM を作成する必要もありましたが、それについてはいつかお話しするかもしれません。 そうですね、いくつかの小さなサービスは Go で書かれています: エディター用の画像のサイズ変更と読み込みです...

データベースとしてPostgreSQLを使用しました。 エディター インターフェイスは、ActiveAdmin gem を使用して Ruby on Rails で作成されました。 統計プロバイダーからの統計のインポートも Ruby で記述されます。

システム API テストには、Python の Unittest を使用しました。 Memcached は API 支払い呼び出しの調整に使用され、「Chef」は構成の制御に使用され、Zabbix は内部システム統計の収集と監視に使用されます。 Graylog2 はログ収集用で、Slate はクライアント用の API ドキュメントです。

プロトコルの選択

私たちが遭遇した最初の問題: 以下の点に基づいて、バックエンドとモバイル クライアント間の対話用のプロトコルを選択する必要がありました...

• 最も重要な要件: クライアント上のデータはリアルタイムで更新される必要があります。 つまり、現在ブロードキャストを視聴している全員が、ほぼ瞬時に更新情報を受信する必要があります。
• 話を単純化するために、クライアントと同期されるデータは削除されず、特別なフラグを使用して非表示になると仮定しました。
• あらゆる種類のまれなリクエスト (統計、チーム構成、チーム統計など) は、通常の GET リクエストによって取得されます。
• さらに、システムは同時に 100 万人のユーザーを簡単にサポートする必要がありました。

これに基づいて、次の XNUMX つのプロトコル オプションがありました。

1. ウェブソケット。 しかし、クライアントからサーバーへのチャネルは必要ありませんでした。 サーバーからクライアントに更新を送信するだけでよいため、WebSocket は冗長オプションです。
2. Server-Sent Events (SSE) が正しく登場しました。 それは非常にシンプルで、基本的に必要なものをすべて満たしています。

サーバー送信イベント

これがどのように機能するかについて少し説明します...

これは http 接続上で実行されます。 クライアントがリクエストを送信すると、サーバーは Content-Type: text/event-stream で応答し、クライアントとの接続を閉じずに、接続へのデータの書き込みを続けます。

データはクライアントと合意した形式で送信できます。 私たちの場合は、次の形式で送信しました。変更された構造の名前 (人、プレーヤー) がイベント フィールドに送信され、プレーヤーの新しい変更されたフィールドを含む JSON がデータ フィールドに送信されました。

次に、インタラクション自体がどのように機能するかについて話しましょう。

• クライアントが最初に行うことは、サービスとの同期が最後に実行された時刻を判断することです。クライアントは、ローカル データベースを参照して、クライアントによって記録された最後の変更の日付を判断します。
• この日付を指定してリクエストを送信します。
• それに応じて、その日以降に発生したすべての更新情報を彼に送信します。
• その後、ライブ チャネルに接続し、次の更新が必要になるまで閉じません。

私たちは彼に変更のリストを送信します。誰かがゴールを決めた場合は試合のスコアを変更し、彼が怪我をした場合はこれもリアルタイムで送信します。 したがって、クライアントは試合イベント フィードで最新のデータを即座に受け取ります。 サーバーが停止していないこと、サーバーに何も起こっていないことをクライアントが理解できるように、定期的に 15 秒ごとにタイムスタンプを送信します。これにより、すべてが正常で再接続する必要がないことがクライアントに認識されます。

ライブ接続はどのように提供されますか?

• まず最初に、バッファリングされた更新を受信するチャネルを作成します。
• その後、このチャンネルを購読して更新情報を受け取ります。
• クライアントがすべてが正常であることを認識できるように、正しいヘッダーを設定します。
• 最初の ping を送信します。 現在の接続タイムスタンプを記録するだけです。
• その後、更新チャネルが閉じられるまでループでチャネルから読み取ります。 チャネルは、現在のタイムスタンプ、または接続を開くために既に書き込まれている変更を定期的に受信します。

私たちが最初に遭遇した問題は次のようなものでした。クライアントと開いた接続ごとに、15 秒ごとに刻むタイマーを作成しました。6 台のマシン (6 つの API サーバー) で XNUMX 個の接続を開いた場合、XNUMX 個の接続が開いていることがわかりました。千のタイマーが作成されました。 これにより、機械が必要な荷重を保持できなくなりました。 問題は私たちにとってそれほど明らかではありませんでしたが、少しの助けを得て修正しました。

その結果、ping はアップデートの送信元と同じチャネルから送信されるようになりました。

したがって、15 秒ごとに XNUMX 回作動するタイマーは XNUMX つだけです。

ここには、ヘッダー、ping、構造自体の送信など、いくつかの補助機能があります。 つまり、テーブルの名前 (人物、試合、季節) とこのエントリに関する情報がここに送信されます。

更新情報を送信するメカニズム

ここで、変更がどこから来たのかについて少し説明します。 リアルタイムで放送を見ている編集者が何人かいます。 彼らはすべての出来事を作り出します：誰かが退場になり、誰かが負傷し、何らかの交代が行われました...

CMS を使用して、データがデータベースに入力されます。 この後、データベースは Listen/Notify メカニズムを使用して、これについて API サーバーに通知します。 API サーバーはこの情報をすでにクライアントに送信しています。 したがって、基本的にデータベースに接続されているサーバーは少数であり、クライアントはいかなる形でもデータベースと直接対話しないため、データベースに特別な負荷はかかりません。

PostgreSQL: リッスン/通知

Postgres の Listen/Notify メカニズムを使用すると、イベント サブスクライバーにイベントが変更されたこと、つまりデータベースにレコードが作成されたことを通知できます。 これを行うために、簡単なトリガーと関数を作成しました。

レコードを挿入または変更するときは、data_updates チャネルで通知関数を呼び出し、そこにテーブルの名前と、変更または挿入されたレコードの識別子を渡します。

クライアントと同期する必要があるすべてのテーブルに対して、レコードの変更/更新後に、下のスライドに示されている関数を呼び出すトリガーを定義します。
API はこれらの変更をどのようにサブスクライブするのでしょうか?

ファンアウト メカニズムが作成され、メッセージがクライアントに送信されます。 すべての顧客チャネルを収集し、次のチャネルを通じて受信した更新情報を送信します。

ここでは、標準の pq ライブラリがデータベースに接続し、チャネル (data_updates) をリッスンしたいことを通知し、接続が開いていてすべてが正常であることを確認します。 スペースを節約するためにエラーチェックを省略しています（チェックしないと危険です）。

次に、15 秒ごとに ping を送信する Ticker を非同期に設定し、サブスクライブしたチャネルのリスニングを開始します。 ping を受信した場合は、この ping を公開します。 何らかのエントリーを受け取った場合、このエントリーをこのファンアウトのすべての購読者に公開します。

ファンアウトはどのように機能しますか?

ロシア語では、これは「スプリッター」と訳されます。 更新の受信を希望する購読者を登録するオブジェクトが XNUMX つあります。 そして、このオブジェクトに更新が到着するとすぐに、この更新をすべてのサブスクライバーに配布します。 非常に簡単です:

Go での実装方法:

構造があり、ミューテックスを使用して同期されます。 これには、データベースへの Fanout の接続の状態を保存するフィールド (つまり、現在リッスンしており、更新を受信する予定) と、利用可能なすべてのチャネルのリスト (マップ) があり、そのキーは次の形式のチャネルと構造体です。値（本質的にはいかなる形でも使用されません）。

Connected と Disconnected の XNUMX つのメソッドを使用すると、ベースへの接続があること、接続が表示されたこと、およびベースへの接続が切断されたことを Fanout に伝えることができます。 XNUMX 番目のケースでは、すべてのクライアントを切断し、クライアントへの接続が閉じられたため、もう何も聞くことができず、再接続することを伝える必要があります。

チャンネルを「リスナー」に追加する Subscribe メソッドもあります。

クライアントが切断された場合にリスナーからチャンネルを削除する Unsubscribe メソッドと、すべてのサブスクライバーにメッセージを送信できる Publish メソッドがあります。

質問： – このチャネルを通じて何が送信されますか?

MS： – 変更されたモデルまたは ping が送信されます (基本的には単なる数値、整数)。

MS： – あらゆるものを送信し、任意の構造を送信し、公開することができます。それは JSON に変換されるだけです。

MS： – Postgres から通知を受け取ります – これにはテーブル名と識別子が含まれています。 テーブル名と識別子に基づいて、必要なレコードを取得し、この構造を公開のために送信します。

インフラ

インフラストラクチャの観点からこれはどのように見えるでしょうか? 当社には 7 台のハードウェア サーバーがあり、そのうちの 6 台は完全にデータベース専用で、他の XNUMX 台は仮想マシンを実行します。 API のコピーは XNUMX つあります。API を備えた各仮想マシンは別のハードウェア サーバー上で実行されます。これは信頼性のためです。

アクセシビリティを向上させるために、Keepalived がインストールされた XNUMX つのフロントエンドがあり、何かが起こった場合に一方のフロントエンドがもう一方のフロントエンドに置き換わります。 また、CMS のコピーが XNUMX つあります。

統計インポーターもあります。 定期的にバックアップが作成される DB スレーブがあります。 Pigeon Pusher というクライアントにプッシュ通知を送信するアプリケーションや、Zabbix、Graylog2、Chef といったインフラストラクチャ関連のアプリケーションもあります。

実際、より少ないサーバーで 100 万件に対応できるため、このインフラストラクチャは冗長化されています。 しかし、鉄はありました - 私たちはそれを使いました（それが可能であると言われました - なぜ使わないのですか）。

囲碁の長所

このアプリケーションに取り組んだ後、Go のこのような明白な利点が明らかになりました。

• クールな http ライブラリ。 これを使用すると、すぐにさまざまなものを作成できます。
• さらに、チャネルにより、クライアントに通知を送信するメカニズムを非常に簡単に実装できるようになりました。
• 素晴らしいのは、Race detecter のおかげで、いくつかの重大なバグ (ステージング インフラストラクチャ) を排除できたことです。 ステージングで動作するものはすべて起動され、Race キーでコンパイルされます。 したがって、ステージング インフラストラクチャを調べて、どのような潜在的な問題があるかを確認できます。
• ミニマリズムと言葉のシンプルさ。

開発者を募集しています！ 欲しい人がいたらお願いします。

質問

聴衆からの質問 (以下、B): – ファンアウトに関する重要な点が XNUMX つ抜けているように思えます。 クライアントに応答を送信するとき、クライアントが読みたくない場合はブロックするという理解で正しいですか?

MS： - いいえ、ブロックしていません。 まず、nginx の背後にはこれらすべてが備わっています。つまり、クライアントが遅い場合でも問題はありません。 次に、クライアントにはバッファ付きのチャネルがあります。実際、そこに最大 XNUMX 件の更新を置くことができます。チャネルに書き込むことができない場合、チャネルは削除されます。 チャネルがブロックされていることがわかったら、チャネルを閉じるだけです。問題が発生した場合、クライアントは再接続します。 したがって、原則として、ここではブロックはありません。

で： – 識別子テーブルではなく、レコードをすぐに Listen/Notify に送信することはできないでしょうか?

MS： – Listen/Notify には、送信するプリロードに 8 バイトの制限があります。 少量のデータであれば基本的には送信可能ですが、単純にこちらの方が確実な気がします。 制限は Postgres 自体にあります。

で： – 顧客は興味のない試合に関する最新情報を受け取りますか?

MS： - 一般的にはそうです。 原則として、2 ～ 3 試合が並行して行われますが、それでも並行して進行することは非常にまれです。 クライアントが何かを見ている場合、通常は行われている試合を見ています。 その後、クライアントはこれらすべての更新が合計されるローカル データベースを持ち、インターネット接続がなくても、クライアントは更新があるすべての過去の試合を表示できます。 基本的に、クライアントがオフラインで作業できるように、サーバー上のデータベースとクライアントのローカル データベースを同期します。

で： –なぜ独自のORMを作ったのですか？

Alexey (Look+ 開発者の XNUMX 人): – 当時 (XNUMX 年前です)、ORM は現在よりも少なく、ORM は非常にたくさんありました。 世にあるほとんどの ORM で私が気に入っている点は、そのほとんどが空のインターフェイスで実行されることです。 つまり、これらの ORM のメソッドは、構造体、構​​造体ポインター、数値、まったく無関係なものなど、あらゆるものを受け入れる準備ができています。

当社の ORM はデータ モデルに基づいて構造を生成します。 自分自身。 したがって、すべてのメソッドは具体的であり、リフレクションなどを使用しません。メソッドは構造を受け入れ、それらの構造を使用することを期待しています。

で： –何名くらい参加されましたか？

MS： – 初期段階ではXNUMX名が参加していました。 XNUMX月くらいに着手して、XNUMX月には本編（初版）が完成しました。 XNUMX月にリリースがありました。

で： – SSE を記述する場合、タイムアウトは使用しません。 何故ですか？

MS： – 正直に言うと、SSE は依然として html5 プロトコルです。私が理解している限り、SSE 標準はブラウザーと通信するように設計されています。 ブラウザーが再接続 (など) できるようにする追加機能がありますが、接続して情報を受信するためのロジックを実装できるクライアントがあったため、それらは必要ありません。 私たちは SSE を作成したのではなく、SSE に似たものを作成しました。 これはプロトコルそのものではありません。
必要はありませんでした。 私の理解する限り、クライアントは接続メカニズムをほぼゼロから実装しました。 彼らは特に気にしませんでした。

で： – その他にどのようなユーティリティを使用しましたか?

MS： – スタイルを統一するために、gofmt だけでなく、govet と golint を最も積極的に使用しました。 他には何も使用されませんでした。

で： – デバッグには何を使用しましたか?

MS： – デバッグは主にテストを使用して実行されました。 デバッガや GOP は使用しませんでした。

で： – Publish機能を実装したスライドを返却してもらえますか？ 変数名が XNUMX 文字だと混乱しませんか?

MS： - いいえ。 可視範囲はかなり「狭い」です。 これらはここ以外では使用されず (このクラスの内部を除く)、非常にコンパクトです。必要な行数はわずか 7 行です。

で： – どういうわけかまだ直感的ではありません...

MS： - いいえ、いいえ、これは本物のコードです。 それはスタイルの問題ではありません。 これは非常に実用的な、非常に小さなクラスです - クラス内のフィールドは 3 つだけです...

MS： – 概して、クライアント (シーズンの試合、選手) と同期されるすべてのデータは変更されません。 大まかに言えば、試合を変更する必要がある別のスポーツを作成する場合、新しいバージョンのクライアントですべてが考慮されるだけで、古いバージョンのクライアントは禁止されます。

で： – サードパーティの依存関係管理パッケージはありますか?

MS： – go dep を使用しました。

で： – 報告書のテーマにビデオに関するものがありましたが、報告書にはビデオに関する記述はありませんでした。

MS： – いいえ、ビデオに関する話題は何もありません。 それは「Look+」と呼ばれるもので、それがアプリケーションの名前です。

で： – クライアントにストリーミングされるとおっしゃいましたが...

MS： – 私たちはストリーミングビデオには関与していませんでした。 これはすべて Megafon によって行われました。 はい、アプリケーションが MegaFon であるとは言いませんでした。

MS： – Go – スコア、試合イベント、統計などのすべてのデータを送信します。Go はアプリケーションのバックエンド全体です。 ユーザーが試合を視聴できるように、クライアントはプレーヤーにどのリンクを使用するかをどこかから知っている必要があります。 用意されたビデオやストリームへのリンクがあります。

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 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