高負荷カンファレンスレビューfwdays'17

10月14日に、高負荷プロジェクトに特化したHighload fwdays会議がキエフで開催され、データベースとアーキテクチャ、特にマイクロサービス、機械学習、ビッグデータを操作しました。 DataArtは会議を後援しました。 また、同僚のIgor Masternoy （JavaコミュニティDataArt Kievのリーダー）とAnna Kolot（.NET、SharePoint Developer）が訪問したレポートについて話しました。



会議プログラムの詳細については、 こちらをご覧ください 。



FacebookのDmitry Okhonkoによる Log Deviceに関するレポートからレビューを始めましょう。 「さらに別のログストレージ」と考えるでしょう。 あなたは正しいでしょうが、このログストレージはその作成者から際立っています。 Facebookは帯域幅が1TB / sであると主張しています。 そして、そのような大量のデータの処理を彼らがどのように処理するかを知ることは興味深いことでした。

ログデバイス

ログデバイスとは何ですか？ 次のユーザー事例がプレゼンテーションで発表されました。

• サービス間の信頼できる通信。
• 先読みログ。
• 状態の複製。
• ジャーナリング。
• 大きな分散データストアでセカンダリインデックスを維持します。

このシステムは、迅速に確実にアクセスできるように設計されており、何世紀にもわたって、アドレス可能な最小単位である膨大な数の追加専用ログを記録します。 さらに、システムはログの記録順序と、必要に応じてログを取得する機能を保証する必要があります。 そのアーキテクチャを見てみましょう。





図 1 LogDeviceアーキテクチャ。



LogDeviceに書き込まれるデータは、開始のために、いわゆるシーケンサノードに移動します（図では、これらは赤と緑の菱形です）。 各ログには独自のシーケンサーがあり、元号とレコードのシリアル番号という2つの数字で構成される数字が生成されます。 この識別子の組み合わせは、シーケンサー自体のフォールトトレランスを保証するために必要です。 シーケンサノードが停止した場合、新しいノードはログを記録し続ける必要があり、その識別子は以前に記録されたものよりも多くなります。 このため、新しいノードは時代の数を増やします。 ログメタデータ、ログ時代の識別子は、zookeeperに保存されます。



次に、取得された識別子を持つログは、特定の数のストレージノードに記録されます。 スピーカーは、ストレージノード内で、Key-Value Rocks DBデータベースが回転していると説明しました。 その中の各ログは、次の形式の記録です。



{LOG_ID, LSN, COPYSET, DATE, Payload}

• LOG_ID-ログタイプ。
• LSN-レコード識別子。
• COPYSET-レコードを含むノードの識別子のリスト。
• ペイロード-ログの本文。

レコードの読み取りはどのように機能しますか？ 図からわかるように、各Readerクライアントは、必要なログのレコードを含むすべてのノードに接続します。 各ノードは、指定された識別子または日付で始まるレコードを発行します。 Readerクライアントのタスクは、重複を削除し、受信したレコードをソートすることです。



Facebookで LogDeviceの詳細を読むことができます。 オープンソースでの計画的なリリースは2017年の終わりです。

MLレポート

HighloadとBig Dataについてのスピーチがある近所では、機械学習のファッショナブルな方向性をより深く知ることができます。 Sergey Vashchilin（PayMaxi）の「セマンティックテキスト分析と盗作の検索」およびAleksand Zarichkova（Ring Ukraine）の「リアルタイムの顔検出より高速」のレポートを聞くことができました。

テキスト意味解析

講演者はこの分野の基本的なアルゴリズムについて説明しましたが、機械学習のトピックは明らかにされていませんでした。 レポートは、 SVDアルゴリズム、ドキュメントキーワードの検索用のtf-idf、シングルアルゴリズム 、および2つのドキュメントの類似性を比較するためのlzmアーカイバの使用を提示しました。 著者が説明したシステムは、ドキュメントの一致を比較的安価にチェックする方法です。



システムの入力時に、SVDを使用してキーワードが見つかったドキュメントが保存されます。これらの単語は、インターネット上の類似ドキュメントを検索するために使用されます。 キャッシュとして、Apache Luceneを使用して検索を高速化します。これにより、ドキュメントをローカルに保存してインデックスを作成できます。 見つかったドキュメントは、シングルアルゴリズムを使用して処理され、受信ドキュメントと比較されます。



このシステムの利点は、アナログと比較した場合のシンプルさと低開発コストです。 このシステムの欠点は、テキストの実際のセマンティック分析の欠如とキーワードのよりインテリジェントな検索です。

リアルタイムの顔検出よりも高速

このレポートは、写真内のオブジェクトを認識し、オブジェクト上の位置を特定するための機械学習方法の概要を提供しました（図2を参照）。 スピーカーは、 Viola-Jones検出器からYOLO、SSDなどの最新（2015年）の畳み込みニューラルネットワークに至るまでの認識方法の話をしました。





図 2オブジェクトとその場所の認識。



このレポートは、ウクライナのスタートアップRing Ringによって提示されたため、特に興味深いものでした。 スピーチから明らかなように、説明したニューラルネットワークは、ドアで鳴っている人の顔を判別するために広く使用されています。 話者によると、主な難点はリアルタイムでの発信者の定義のままであり、これには高速の認識自体が必要です。 最新のニューラルネットワークYOLOまたはSSDにはこのような特性があります。以下は、さまざまなニューラルネットワークのアーキテクチャの比較表です。



表1.ニューラルネットワークアーキテクチャの比較

モデル	電車	mAP	フロップ	Fps
ヨロ	BVOC 2007 + 2012	40.19	40.19	45
SSD300	VOC 2007 + 2012	63.4	-	46
SSD500	VOC 2007 + 2012	74.3	-	19
YOLOv2	VOC 2007 + 2012	76.8	34.90	67
YOLOv2 544x544	VOC 2007 + 2012	76.8	59.68	40
タイニーヨーロ	VOC 2007 + 2012	57.1	6.97	207

表1からわかるように、ニューラルネットワークは、速度（FPS-1秒あたりのフレーム数）と認識の精度（mAP-平均平均精度）の特性が異なるため、特定のタスクのニューラルネットワークを選択できます。

Elastic 6の新機能

ElasticのPhilip Krennによるレポートは、検索エンジンの人気を追跡するdb-engines.comの以下の表から始まりました。 Elasticは、最も近い競合他社であるSolrの2倍先を行っています。 CERN、Goldman Sachs、Sprintなどの組織で使用されています。







8月にリリースされた新しいElastic 6ベータ版の何がすごいのですか？ レポートでは、次のイノベーションが提示されました。

クロスクラスター検索

複数のElasticクラスターでデータを検索できます。 そのような機会はすでに存在していましたが、Tribeノードの助けを借りて最適に実装されていませんでした。 トライブは両方のクラスターのマージされた状態を保持し、各Elastic制御クラスターの状態の更新を受け入れました。 さらに、要求を受信したTribeノードは、どのインデックス、シャード、およびノー​​ドをポーリングし、どの上位Nドキュメントをロードするかを個別に決定しました。



クラスター間検索では、個別の専用ノードと両方のクラスターのマージされた状態は必要ありません。 どのノードでも、クラスター間要求を受け入れることができます。 クロスクラスター要求は、別のクラスターの3つの構成済みシードノードと通信する調整ノードによって処理されます。 また、コーディネーターからの接続を直接受け入れ、プロキシとして機能するゲートウェイノードを構成することもできます。 APIの観点から調整する場合、別のクラスターのインデックスの検索クエリに違いはありません。結果には、2番目のクラスターの名前のプレフィックスが付けられます。 クロスクラスター検索は、検索APIを統合し、Tribeノードと比較していくつかの制限を削除します（ローカルクラスターと関連クラスターで同じ名前のインデックスで検索します）。 詳細については、 こちらとこちらをご覧ください 。



既存のElastic 5クラスターをElastic 6に移行する方法は？ 6番目のバージョンから、Elasticクラスターを停止することなく、ローリングアップグレードを使用してバージョンを更新できます（Elastic 5.6からElastic 6への切り替えが有効）。

シーケンス番号

シーケンス番号は、Elastic 6の重要な新機能の1つです。更新、削除、書き込みの各操作にはシーケンシャル識別子が割り当てられるため、遅れるセカンダリレプリカは、ファイルをコピーせずにi番目から始まるトランザクションログから操作の進捗を復元できます。 ユーザーには、トランザクションログの保存時間を設定する機会が与えられます。

種類

Elasticsearchは以前、マッピングタイプをデータベース（インデックス）内のテーブルとして表現していました。 たとえそのたとえは完全に正確ではありませんが。 同じ名前のデータベース内の列は互いに依存していませんが、Elasticでは、2つの異なるマッピングタイプのフィールドは同じフィールドタイプでなければなりません。 あるタイプの削除された日付フィールドを別のタイプのブール値に割り当てることはできません。 これは、Elasticが型を正確に実装するためです。 Elasticのフードの下にあるApache Luceneは、同じフィールドに異なるタイプのフィールドを格納します。 現在、Elasticはインデックスのタイプを段階的に廃止することを決定しました。 Elastic 6では、各インデックスに含めることができるタイプは1つのみであり、インデックス作成時に指定することはできません。 将来のバージョンでは、型サポートは完全に廃止されます。

実際の高負荷プロジェクトのトップ10アーキテクチャファイル

Dmitry Menshikovのプレゼンテーション 「本当の高負荷プロジェクトのトップ10アーキテクチャファイル」が気に入りました。 ドミトリーは生まれつきのスピーカーであり、言葉を所有し、スピーチにユーモアを加え、観客の関心をサポートします。 講演者は10件の事例を示し、問題の原因と状況の解決方法を説明しました。



例：

• プロジェクトの運用開始後に発見された、日付+時間+ MACアドレスおよび128ビットの長さの形式のUUIDを選択する際の誤りとして、それは速度低下につながり、2年間の開発コストがかかりました。 そして、インデックスの長さを4バイトに増やすという簡単な決定として、状況を保存しました。 ご存知のように、タイムスタンプは60ビット値であり、UUIDバージョン1の場合、10月15日の00：00：00.00から始まる、UTCの100ナノ秒間隔のアカウントとして表示されます。 問題は、識別子の生成の特徴により、最初に第2部分が含まれる可能性と均一な分布の欠如が考慮されていないことでした。

• 新しい開発者が長期にわたるテストの修正を決定したとき、キーの存在のチェックを追加し、キーを持たない約200万のユーザーメッセージが失われました。

私たちの意見では、レポートは複雑な生産の詳細で飽和していませんでした。 しかし、結論は変わりません。実装されたソリューションは実際にテストされ、変更がシステムにどのように影響するかを考えなければなりません。

マイクロサービスアーキテクチャトラップ

GlobalLogicのシステムアーキテクトであるNikita Galkinは、 「Microservice Architecture Traps」というタイトルの論文を発表しました。 Nikitaによると、マイクロサービスの実装における主な問題は、テンプレートアプローチを使用せずに開発することです-ある場合には設定ファイルがconfigと呼ばれる場合-他の場合は設定など 開発プロセス中のドキュメントの毎日の更新の拒否。 既に実装されている製品のボックス手段によって問題を解決できるマイクロサービスの使用。

[ページ]の負荷が高い

興味深い報告は、世界中の家庭教師を見つけるためのサイトであるPreply.comの共同設立者であるDmitry Voloshinによる「高[ページ]負荷」でした。 Dmitryは、サイトの開発の歴史、ユーザー数が300万人から100万人に増加し、サイトが大陸間市場に参入したことで、ページの読み込み時間を測定および改善する必要が生じた方法について説明しました。



レポートの主なアイデアは、ページの読み込み速度に影響する要因を継続的に監視する必要があることです。 ビジネスの成功はページの読み込み速度に依存するため、パフォーマンスを改善するための作業の必要性。







ページの読み込み速度を上げるためにPreplyが使用するツール：

• 基本：キャッシュ、ormの最適化。
• より高度な：レプリカ、負荷分散。
• current：CDN、マイクロサービス。