LinguaLeo Chronicles：Node.jsとDynamoDBを使用して英語で対話を作成した方法

LinguaLeoユーザーは、 ジャングルで英語を学び始めます-複雑さ、フォーマット、テーマのレベルが異なる数千の資料のリポジトリ。 ネイティブスピーカーのスピーチを聞き、理解し、語彙を増やすことを段階的に学びます。 誰が文法を必要としますか？ コースに行きます。 語彙は、個人辞書になじみのない単語を追加するだけでなく、個々の学習に利用できる準備済みの単語セットの助けを借りて、ジャングルから補充されます 。 コミュニケーションセクションでは、英語でダイアログを行い、リアルタイムモードで他のLinguaLeoユーザーと言語を練習し、コミュニケーションのトピックを選択できます。 英語のみのコミュニケーション！



英語でダイアログを作成するために、Node.js、DynamoDB（すべてAWSで）を使用しました。 次に、経験を共有します。

█Node.jsを使用する 理由

「...ユーザーにコミュニケーションの機会をすべて提供するために、Node.jsを選択しました。 なんで？ Node.jsは、膨大な数のモジュールがあるストリームでの作業に適しています 。 さらに、Nodeで作業する有能なJavaScriptプログラマーは、サーバーパーツだけでなく、タスクのスコープ全体を実装できます（たとえば、Erlangスペシャリストとは異なります）。



サーバーとクライアント間の「トランスポートノード」として、情報を配信する最速の方法としてWebSocketを使用しました。



クロスプラットフォームの問題を解決するために、 Sock.JSライブラリを選択しました 。 第一に、WSのW3C準拠により、第二に、Sock.JSは私たちのニーズに最適です。







行きましょう。 Amazon EC2の「クラウド」機能でNode.jsデーモンを起動しました。 アプリケーションはgitを介してデプロイされます。 foreverモジュールは、ロギングと再起動を担当します。 ちなみに、Amazonには非常に便利なサービスであるAmazon Cloudwatchがあります。 その機能により、システムの主要なパラメータを監視できます。最も重要なことは、その尊厳は、本当に重要なものだけを監視できるカスタマイズ可能な通知です。 アプリケーションの状態に関する詳細情報を取得するには、 nodetimeを使用します 。







dynodeモジュールは、DynamoDBを操作するためのドライバーとして使用されます。 彼は自分自身を立証しましたが、不完全な技術文書は蜂蜜の樽にタールを加えました。 Amazonの公式Node.js SDKは後で発表され、まだ開発者プレビュー段階にあります。 そのような自然な方法で 、すべての技術的要件を満たすため、Amazonの製品を使用することが決定されました。

█Node.jsの微妙な点

ダイアログサーバーでのユーザー認証の問題に特に注意を払いました。 サーバーCookieの承認については、弊社が責任を負います。 これは速度の点では非常に「高価な」ソリューションですが、安定性とセキュリティに加えて、独立したサービス指向のアーキテクチャが印象的です。



どのように機能しますか？ ユーザーCookieはWebSocketを介してダイアログサーバーに送信されます。→ダイアログサーバーは、受信したCookieを含むリクエストをAPIに送信することでCookieの有効性を確認し、ユーザーデータを既に送信します。 データがエラーなしで受信された場合、Dialogサーバーはそのジョブを実行（許可）し、データをユーザーに送信します 。



多くの人が自宅だけでなく職場でもLinguaLeoを練習していることを知っています。 多くの場合、企業のファイアウォールが過度に厳密に構成されているため、標準ポート以外のすべてのポートを使用できません。 これを覚えており、WebSocket接続にはポート443を使用します（httpsにバインドしません）。 このソリューションは、潜在的なネットワークの問題を回避します。

█DynamoDBの 機能

1年ほど前、Amazonは分散型NoSQLデータベースAmazon DynamoDBをリリースしました。 システムアーキテクチャの設計段階で、MongoDBとDynamoDBの2つの製品から選択する必要がありました。 管理の難しさから最初のオプションを拒否しました。製品の場合はサポートが必要ないため、選択はAmazonに委ねられました。 まあ、もちろん、さらに使用するために自分で技術を「壊す」ことは興味深いことでした。



DynamoDBでの作業は、これまで見てきたすべてのものとは非常に異なることが判明しました。 このことから、SaaS製品であるため、httpリクエストの時間を考慮する必要がありました。 Amazonデータセンター内では、平均クエリ時間は約20ミリ秒です。そのため、結論に至ったのは、インデックスのみを使用してすべての選択を行うことが非常に望ましいことです（これは高速で安価です）。スキャン要求は、分析または移行専用に使用する必要があります。

█ データ構造

ダイアログ-ダイアログのメタデータを保存し、最後のメッセージをキャッシュします。







UserDialogs-ユーザーダイアログのリスト、キャッシュ+未読メッセージのカウンター。







メッセージ-すべてのユーザーメッセージ。







User2User-ダイアログの参加者。







例1



「英語のマイダイアログ」ページのすべてのユーザーダイアログを取得するプロセスは、非標準で実装されています。 このページでは、未読メッセージの総数と各ダイアログの最後のメッセージを含む、すべてのダイアログがユーザーに表示されます。



データは2つのクエリで選択されます。 1つ目は、 Queryを使用してUserDialogsテーブルからすべてのdialogldsをフェッチすることです。 2番目は、BatchGetItemを介してダイアログを取得します。 わずかなニュアンスがあります-BatchGetItemは一度に最大100個のメッセージを選択します。 したがって、ユーザーが242を持っている場合、3つの要求を行う必要があります。これには約70〜100ミリ秒かかります。 これを念頭に置いて、パフォーマンスの最適化の向上に努め、ダイアログデータをElasticCacheにキャッシュし、新しいメッセージごとに更新します。







例2



ダイアログに新しいメッセージを追加することも重要です。 DynamoDBのレコードを待機しないため、データベースの速度はそれほど重要ではありません。 結局、大量の記録を実施する必要があり、これはその後のサンプリングの速度に重要な役割を果たします。 最初に、 Messages PutItemテーブルに新しいメッセージを書き込み、次にDialogs UpdateItemテーブルをキャッシュします。 次に、各ユーザー（UpdateItem）のUserDialogsテーブルでmessageCounterをインクリメントする必要があります。 結局、すべてが起こり、突然、ユーザーの1人がダイアログを削除し、メッセージカウンターをリセットすることにしました。 合計= 4リクエストで、約70〜100ミリ秒が時間内に収集されます。 残念ながら、そのようなトランザクションはDynamoDBではサポートされていません。これにより、データの整合性が重要なプロセスに明確な制限が課せられます。



一般に、製品要件の変更は非常に一般的な出来事です。 これには、データ構造の変換が必要になる場合があります。 リレーショナルデータベースでは、ALTER TABLEを使用してこれを解決しますが、DynamoDBではこのことはまったくありません。 ここで回路を変更すると、非常に費用がかかります。 テーブルを再作成するか、 Elastic MapReduceを使用する必要があります。 両方のオプションを支払う必要があります。 大量のデータ=大量のお金。 これにどうにか対処するために、Scan'om 1メガバイトのすべてのデータを選択してから、新しいテーブルに書き込む必要がありました。 これには多くの時間がかかりますが、これはDBAが不足しているための費用です。

█DynamoDBの 印象

DynamoDBの使用に関する実験は成功しました。 これは、拡張が容易な素晴らしいデータベースです。 それを使って管理を忘れてください。 ただし、見返りに、アーキテクチャ設計段階で慎重に処理する必要があることを忘れないでください。 それ以外の場合、あらゆる種類の予期しないターンと不快なレーキがそこで可能です。 重要ではないデータが大量にあり、それらを頻繁に使用する必要がある場合は、DynamoDBを使用することをお勧めします。 私たちは使用します-私たちはそれが好きです:)



***

英語のダイアログで簡単かつ自然にコミュニケーションをとる -快適な会社で英語を練習し、 チームに参加しましょう！



Facebook 、 Vkontakte 、 Twitterでニュースをフォローし、印象を共有して楽しんでください。 コミュニケーションの自由は素晴らしい！



LinguaLeoチーム