スケーラブルな分散アプリケーションをゼロから作成する

どうやって始まったの

私はずっとWindowsを開発してきました。 最初にC ++で、次にC＃で。 フラッシュされたVB、Java Script、その他の悪霊の間。 しかし、少し前に、すべてが変わり、最初にLinux、Java、Scalaの世界に出会いました。 私の友人であり同僚でもある多くのアイデアを持つDenisには、すでに私たち自身のプロジェクトがありました。Windows用のユーティリティセットは、狭い範囲で大きな需要がありました。 ある時点で、私たちはこのプロジェクトへの関心を失い、疑問が生じました-次に何をすべきか。 デニスは、異なるプロジェクト間でクリップボードを交換するサービスという新しいプロジェクトのアイデアを開始しました。 このプロジェクトは、テクノロジーに加えて、対象者にも加えて、以前のプロジェクトとは大きく異なりました。 このサービスは、すべての人に役立つはずでした。 データをクリップボードにコピーし、他のデバイスに貼り付けます。 現在、さまざまなデバイスがいくつあるか、そしてそれが多数のユーザーにどのように機能するかを考えるまで、どこでも簡単に聞こえます。

最初のプロトタイプは数か月後に登場しました。 サーバーはASP.NETで記述され、MS IISでホストされていました。 2つのクライアントが作成されました。Windows用のC ++およびAndroid用のJavaです。







テストの結果、プロトタイプには約500個の化合物が含まれていることがわかりました。 しかし、もしそれらがもっとあるとしたら、数十万人のユーザーを頼りにしています）ハードウェアやソフトウェアのアップグレード中にオフにする必要がなく、簡単に拡張できる（つまり拡張する）多数の接続で動作できるサーバーを書く方法ユーザー数が増加した場合）。

分散スケーラブルシステム

私にとって、「分散スケーラブルシステム」（ 良い記事 ）のような複雑な用語は、技術と製品の観点からこの背後にあるものを理解するまで、通常空のままです。 そのようなシステムの特性を知るだけでは十分ではありません。そのようなシステムを自分で作成して、その利点と欠点をすべて実現したいと考えています。







したがって、スケーラブルなシステムには複数のノード（ノード）が必要です。そのため、負荷が増加した場合に新しいノードを追加し、1つのノードに障害が発生しても残りは機能し続けます。 ノードは、鉄または仮想マシンです。 この図およびその他の図では、各ボックスは、SOA（サービス指向アーキテクチャ）の最高の伝統に従って、サービスです。 将来、これらのサービスをどこにどのように配置するかについて話します。



現代の企業がサーバーに書き込むもの。 たとえば、TwitterはScalaの関数型言語を使用し、独自のライブラリFinagle（ Twitterスタック ）を持っています 。 Scalaでは、 非ブロッキング （ 非ブロッキング ）、不変（ 不変 ）コードを記述できます。 スレッドは、たとえばIO（入出力）操作中にリソースの解放を待機しないため、サーバーリソースを節約するために最初の方法が重要です。 2番目の方法では、いつでもコードを並列化し、追加の同期作業なしで異なるスレッドで計算を実行できます。 私たちは、Scala専用の新しいサーバーの作成を開始し、最初にFinagleを使用しましたが、後にPlayフレームワークに移行しました。 2番目の利点は、より動的に開発され、多くのプラグインが常に表示されることです。



お客様がサーバーに新しいクリップボードを追加することに関する情報を迅速に受け取るために、ロングポールテクノロジーを使用しました。 クライアントはサービスにアクセスし、サービスに新しいデータがない場合、すぐにはクライアントに応答しませんが、指定されたタイムアウト（たとえば60秒）の間接続を維持します。 このタイムアウト中にサーバーが新しいデータを受信した場合、保持された接続に対してすぐにそれらを返します。 したがって、クライアントは常にリクエストを繰り返し、更新されたデータを待ちます。



このメカニズムにより、サービスMyService1、MyService2などは、新しいバッファーについて相互に通知できる必要があります。 たとえば、クライアントがハングしてMyService1からの結果を待っているが、MyService2の別のクライアントによってバッファーが追加された場合、MyService1はすぐにそれを見つけます。 サービスがこのような変更について互いに通知できるようにするために、Akkaライブラリのリモートアクターを使用しました。 Akkaは、オブジェクトへのアクセスを同期せずにオブジェクトを使用できるライブラリです。 これは、各アクターにメッセージが送信され、直接の呼び出しは行われず、特定の時点で1つのメッセージのみがアクターによって処理されるという事実によって実現されます。 さらに、Akkaでは、ローカルアクターと同じ方法で、別のサービスからアクターを呼び出すことができます。 リモートアクターメカニズムはインターワーキングを隠し、開発を大幅に促進します。 したがって、Akka MyService1（および他のサービス）を使用すると、新しいデータを受信した場合に他のすべてのサービスに通知できます。



MyService1はMyService2およびMyService3のIPアドレスをどこで取得しますか。 ZooKeeperを使用してシステム構成を保存しました。 したがって、各サービスは、ZooKeeperのIPアドレスを知っており、そのアドレスに登録できます。また、システム内の他のノードに関する情報を取得できます。







図からわかるように、実行時にノードを直接追加または削除できるスケーラブルなシステムを作成しましたが、データベースは1つであり、システムの弱点のままです。 データベースへの各呼び出しは、かなり長い操作です。 ベースの負荷を減らし、システム全体のパフォーマンスを向上させるために、キャッシュを追加することにしました。 キャッシュとしてRedisを使用することが決定されました。 Redisは、NoSQLキー値データストアのメモリ内データストレージです。 あまり明確に聞こえないという事実にもかかわらず、このアイデアは非常に単純です。 Redisでは、キーで値を取得し、これをすべてメモリに保存できます。 したがって、Redisへの呼び出しは非常に高速です。 Redisを使用するために、サービスがそれに応じて変更され、新しいデータが最初にRedisに適用され、その後データが見つからない場合にのみデータベースに適用され始めました。 同様に、新しいバッファが到着すると、すぐにベースとキャッシュに落ちました。







回路内の正方形の数は常に増加していますが、システムの信頼性も向上しています。 MyService2を削除すると、リクエストは引き続きMyService1およびMyService3によって処理されます。 Redisを削除すると、サービスはデータベースから直接データを受け取ります。 削除...いいえ、DBとZooKeeperはまだ削除する必要はありません。システム全体がダウンする可能性があります:)



データベースの信頼性を確保するには、レプリケーションをサポートする必要があります。 サービスにJSONインターフェースがあり、MongoDBでサポートされているJSON形式で結果を保存する方が便利なため、NoSQL MongoDBデータベースを選択しました。 さらに、MongoDBはレプリケーションを完全にサポートします。MongoDBで複数のノードを起動し、それらを1つのレプリカにリンクできます。また、ノードに障害が発生した場合、すべてのクライアントが他のノードと連携できます。 MongoDBのレプリカは、少なくとも3つのノードで構成する必要があります：プライマリノード、セカンダリノード、および他のノードを監視するアービター。メインノードに障害が発生した場合、セカンダリノードをメインノードにします。







これで、MongoDBを使用してノードの1つを安全にオフにでき、システムはそれを認識しません。 ZooKeeperについては詳しく説明しませんが、システムのAchaelesのかかとではなく、MongoDBがレプリケーションをサポートします。



細心の注意を払った読者は、ノードMyService1、MyService2、およびMyService3の間で要求がどのように分散されるかという質問をバイパスしたことに気付くでしょう。 深刻なシステムでは、このためにロードバランサーが使用されます。 ただし、システムの無限の数の補助サービスにすでに飽きている場合は、DNSを単純なロードバランサーとして使用できます。 DNSのapi.myservice.comサービスにリクエストが届くと、いくつかのIPアドレスが返されます。 トリックは、リクエストごとにこれらのIPアドレスの順序が変わることです。 たとえば、最初のリクエストの場合、api.myservice.comは次の値を返しました。132.111.21.2、132.111.21.3、132.111.21.4、2番目の132.111.21.3、132.111.21.4、132.111.21.2の場合、クライアントは常にリストの最初のIPにのみアクセスしようとします。エラーの場合、2番目または3番目を使用します。

展開

その結果、真にスケーラブルな（サービスノードの追加と削除が可能）、分散（サービスは異なるノード、さらには異なるデータセンターにも配置可能）システムを構築しました。



アプリケーションがそのようなシステムの基本的な要件を満たしているかどうかを確認しましょう。

• 可用性-システムは常に利用可能です。 ノードのハードウェアを変更しても、他のノードは引き続き機能します。 ソフトウェアを更新することもできます
• パフォーマンス-より高度なロードバランサーを使用すると、ヨーロッパのユーザーをヨーロッパのノードに、アメリカのユーザーをアメリカのノードに負担をかけることができます。 さらに、Redisを使用すると、データベースアクセスが大幅に削減されます。
• 信頼性-ノードに障害が発生した場合、他のノードは引き続き動作します
• スケーラビリティ-好きなだけMyServiceNを追加できます
• 管理性-うーん、まだ質問がありますよね？
• コスト-このプロジェクトで使用されるすべてのテクノロジーとライブラリは無料またはオープンソースです

したがって、疑問の残る基準は1つだけでした。それは制御性です。 多数のサービスで構成されるSOAシステムを展開する最も簡単な方法は何ですか？ 私たちは、かなり新しく確立されたテクノロジーであるDockerを使用することにしました。 Dockerは、広く使用されている仮想マシンに多少似ていますが、いくつかの利点があります。 Dockerを使用すると、サービスごとにdockerコンテナーを作成し、それらをすべて1台または異なるマシンで実行できます。 重要な点は、DockerはLinuxに組み込まれた仮想化メカニズムを使用するため、仮想マシンとは異なり、追加のリソースを必要としないことです。 そこで、システムのすべてのノード用のコンテナを作成しました。 これにより、すべてのコンテナが1つのノードで実行されているテスト環境と、各コンテナが独自のノードにある作業環境を同様に簡単に展開できます。



ある時点で、システムをどこに配置するかという問題に直面しました。 最も人気のあるクラウドプロバイダーであるAmazonを検討しましたが、お金を節約し、より安価なデジタルオーシャンにアプリケーションを配置することにしました。