Webアプリケーションの進化

「新しいことはすべて悪い」と議論するのは誰にとっても楽しいことです。ここ数年、サーバーではNoSQL / NewSQLを、クライアントではAngular / Knockout / Emberを熱心に議論し、試してきました。 しかし、これらの傾向は終わりのようです。 座って次のことを考える素晴らしい瞬間です。 M.アンドリーセンが言ったように、「ソフトウェアは世界を食い物にしている」。 同時に、モバイル/ウェブアプリは通常のアプリを食べます。 したがって、把握することは特に興味深いですが、モバイルアプリケーションとWebアプリケーションの世界では、すべてがどこに向かっているのでしょうか。 結局のところ、彼らは結局のところ、すべての人をすべて食べます。 次の大きなトピックはデータの同期になると思います。その理由は次のとおりです。

クライアントで実際に何が起こるのでしょうか？

ブラウザでは、開発者はすでに本格的な「通常の」MVCアプリケーションを構築しています。 MVCアーキテクチャ自体は（1970年代から）新しいものではありませんが、Google Mailとともに10年前にウェブに登場しました。 おもしろいのは、GMailプロジェクトが最初はオタクの迷いとして認識されていたことですが、ラリーペイジが言ったように、 「通常のユーザーは10年後には私たちのように見えるでしょう」 。 まあ、それは機能し、GMailはすべてを使用するようになりました。



HTML5の出現により、ブラウザにはすでに独自のデータウェアハウス（2つも）、JavaScriptの独自のビジネスロジック、およびサーバーへの永続的な接続があります。 現在、開発者は、ローカルアプリケーションの可用性と即時応答、およびWebアプリケーションの一定の「オンラインモード」という2つの世界の利点を組み合わせようとしています。





不快感の主な原因はサーバーリクエストです。 これは特にモバイルデバイスで感じられます。 皮肉なことに、無線インターネットは、最も必要なときにクラッシュします-道路（地下鉄）、公共のイベント、および野外で。 自宅でも仕事場でも、彼はスムーズに走ります。ありがとう。 そして、それでも同じYandexのオフィスでは、WiFiは完璧ではありません。明らかに、1平方メートルあたりのギークが集中しているためです。 FOSDEMのような会議では、WiFiは機能しませんでした。



LTEを使用すると、問題はなくなると思うかもしれません。 ほとんどない。 スループット、ストレージ容量、チップ密度は指数関数的に増加しており、RTT（サーバー応答時間）とCPU周波数は過去10年間でほとんど改善されていません。 モバイルネットワークの場合、物理学とは、何百万トンものコンクリート、鉄筋、岩、およびどこにも行かない電波スペクトルの特性を意味します。 データキャッシュとバックグラウンド同期を同じGMailで保存し、全員の前に配置します。 Dropboxもこの点で満足していますが、Evernoteはあまり満足していません。同期の失敗やデータ損失に関する苦情がいっぱいです。





それについて考えてみましょう。 より多くのデータとロジックがクライアントに移行しています。 WebStorage、CoreData、IndexedDB。 より多くのデータ、クライアント上のより多くのスペースがあり、サーバーへのジョギングは簡単になりません。 データのダウンロードは簡単で、キャッシュはさらに簡単です。ロケット科学は同期から始まります。 失敗したモバイルは、空のデータをサーバーに「保存」します-おっと、紛失、ユーザーは不満です。 データは複数のデバイスで一度に変更されます-おっと、競合、ユーザーが歯を磨きます。 そして、そのようなおっとがあとどれくらいになるか。 クライアントの新しい条件は、すでに「大規模」システムの条件を連想させます-多くの機器、多くのデータ複製、すべてが常に故障し、それは正常です。 クライアントはすぐに「ビッグボーイ」の武器庫のツールを必要とするようです。

そして、実際にサーバー上で何が起こりますか？

サーバー上で、すべてが簡単かつ論理的に開始されると、トラブルの前兆はありませんでした。 真実の1つのソースがありました-データベース（たとえば、MySQL）、ロジック（たとえば、PHP）を備えた1つのサーバーがあり、クライアントはフラットビューを受け取り、HTTP GETリクエストを介してサーバー上のロジックを引き出しました。 最初は、ステートレスサーバーの増加を通じて、誰もが単純に論理スケーリングを記録しました。 データベースは徐々にレプリケーション（マスタースレーブ）を必要とし始め、キャッシュ（Memcache）でデータベースを保護し、プッシャーを追加してイベントをリアルタイムでクライアントに送信する必要がありました。 その後、状況はさらに複雑になり始めました。 Hadoopはどこかに、どこかにNoSQLに、どこかにグラフデータベースにねじ込まれました。多くのストレージがありました。 また、分析、検索、郵送など、すべてが専門サービスで大きくなりすぎていました。





特殊なシステムのこの急速な乗算も、データ同期の問題を引き起こしました。 「動物園」の最も成功したソリューションとして、多くの人がApache Kafkaに言及しています。 そのようなアーキテクチャでは、「バス」を介してイベントを交換することを好む異なるシステムに異なるデータスライスが保存されます。 実際、N個のシステムを統合する場合、O（N * N）アダプターまたは1つの共通イベントキューのいずれかを作成できます。 N = 2..3では、このニュアンスはまだあまり目立ちませんが、LinkedInでは明らかにNは素晴らしいです。



そして今、2つのたばこの吸い殻が同時に。 サーバーとクライアント側の両方で、システム内の同じデータのレプリカの数を想像してください。 MongoDB + Redis + Hadoop + WebStorage + CoreDataとしましょう。 これをすべて有能に同期する方法は？

そして、これはすべて何につながりますか？

では、今後のトレンドはどうなるのでしょうか？ 誰も確かに言うことはありませんが、何を探すべきかを知ることができます。 実際、新しいアイデアは非常にゆっくりと出現し、非常にまれです。 たとえば、MongoDBはoplog経由のマスタースレーブレプリケーションを使用します。これは、増分改善のみがbinlog経由のMySQLレプリケーションと異なり、レスリーランポートによる1979年から1984年までのステートマシンレプリケーションの作業に基づいています。



NoSQLシステム-Riak、Voldemort、Cassandra、CouchDBは、重要な一歩を踏み出し、最終的な一貫性、因果関係、論理クロック、ベクトルクロックから何かを絞り込もうとします-これらのアプローチは、80年代後半の同じL.ランポートとC.フィージの作品に遡ります。



Google WaveとDocsの超大型の操作変換同時編集技術は、1989年にCA EllisとSJ Gibbsによって最初に記述され、現在は廃止されています。



新鮮なだけでは十分ではありませんが、出くわします。 NoSQLベンダーによるCRDTデータ構造で水を試す試みは、2000年代後半の理論に基づいています-非常に典型的な新入生です。



それでは、新しい環境で成長するものについて考えてみましょう。 新しいトレンドは、狭い円ですでに広く知られているものによって必然的に決定されます。 主な容疑者は3人です。

共通バスおよびイベント指向

最初の最も有望なトレンドは、イベントソーシングと同様に、イベント指向のリアクティブアーキテクチャです。 これらのアプローチでは、システムでの作業は現在の状態自体だけでなく、「最初のカテゴリ」のオブジェクトであるそれを変更する操作でも行われます。それらは状態とは別に処理、転送、保存されます。 カフカと私がすでに言及した一般的なイベントバス。 考えてみると、クライアント側の作業のロジックはイベント指向です。 ここにイベント指向のビジネスロジックを追加すると、興味深いパズルが組み立てられ始めます。





特に、イベント指向のアプローチは、ACIDトランザクションへの依存を減らします。 トランザクションの主な論点は「お金を数えるとどうなりますか？」です。皮肉なことに、実際に大きなお金を数える金融業界自体では、SQLがトランザクションで発明される前は、何千年もの間完全に冷静でした。 中世に形を変えた形での勘定と残高の簿記は、イベントソーシングの典型的な例です。操作は州で記録、削減、収集されます。 古代のハワラ集落システムでも同じことがわかります。 ACIDなし、純粋な結果整合性。 たとえば、スペイン帝国の発展した金融システムについて書かれた本は、100年にわたって信用で戦ってきました。 首都から周辺の地方への手紙は一年振り向いた。 そして何も、物資は配達されず、軍隊は戦い、バランスは低下した。 しかし、私のビジネスパートナーは「コンピューターが凍結」しているため、最近3回税務署に行きました。

情報中心のアーキテクチャ

2つ目は、情報中心のアーキテクチャです。 データが任意の場所に保存され、自由に流れる場合、ストレージ接続場所のロジックではなく、常にデータから踊るアプリケーションを実装することは理にかなっています。 情報中心型ネットワークの歴史的な例-USENETおよびBitTorrent; 最初は、メッセージはグループ名と独自のIDによって識別され、サーバー間を自由に流れます。 2番目の方法では、データは一般にハッシュによって識別され、参加者は互いに有益なデータを交換します。 一般原則：データを確実に識別し、参加者とそのネットワークトポロジを構築します。 これは、参加者が信頼できず、常に出入りする場合に特に重要です。これは、モバイルクライアントにとって非常に重要です。



約5年前、インターネットの情報中心性に関する興味深い意見交換がありました。 TCPのパイオニアであるVan Jacobsonは、既存のアーキテクチャはスケーラビリティの限界に達し、情報中心のインターネットをゼロから設計する必要があると主張しています。 Ion Stoicaを思い出すことができる別の参加者グループは、一般的にHTTPが時代遅れであるという立場を一般的に保持していましたが、HTTPのCDNインフラストラクチャを調整することにより、URLをサーバーファイルパスではなく情報の単なる識別子として理解できます。 したがって、HTTP + CDNダブレットは、HTTPでの静的の拡散に関するすべての差し迫った問題を解決するために必要な程度まで情報中心にすることができます。 そして、おそらく、男はほとんど正しかった。



興味深い質問は、類推により、最初からアーキテクチャを再設計することなく、Webアプリケーションのデータの情報中心性をキャプチャできるかどうかです。

CRDTタイプ

そして、私が新入生としてすでに言及した3番目の興味深い傾向は、CRDT（Conflict-free Replicated Data Types）です。 彼らはすでに、高負荷のNoSQLシステムにそれらをねじ込み始めています（CassandraとRiakについては確かに知っていますが、他の誰かがそうだったようです）。 CRDTの主な考え方は、システム内のすべての操作の線形化を放棄し（これはMySQLがレプリケーションに使用するアプローチです）、良好なプロパティ（因果順序）を持つ半順序の存在に制限します。 したがって、操作の簡単な並べ替えを壊さないデータ構造とアルゴリズムのみを使用できます。



すべての操作の完全な線形化が原則として不可能な場合、CRDTを使用すると、複数のレプリカを楽観的に同期できます。 文献では、CRDTの基本的なデータ構造（セット、マップ、カウンター、テキスト）を実装する方法のオプションについて説明しています。



これは最も有望なアプローチであり、競合するレコーディング中に、原作の最終作者が勝ち、危険な潜在的なデータ損失よりも少し先に進むことができます。 もちろん、主な難点は、開発者がCRDTの機能を理解する必要があることです。 一般に、これはどのテクノロジーにも当てはまります。 さらに、すべてのデータとアルゴリズムをCRDTベースに分解できるわけではありません。 そして、主な利点は、競合する書き込みアクセスで、レプリカとデータウェアハウスの動物園で同期の問題を解決できることです。



モバイルアプリケーションのCRDTエンジンを使用すると、永続的なインターネット接続がなくてもデータを完全に操作でき、接続が表示された場合にのみ、競合やデータ損失なしに同期できます。 理想的には、これはユーザーにはまったく見えないことがあります。 オブジェクトの一種のDropbox / git。 はい、Firebase、Meteor、Derby、Google Drive Realtime API-この方向に向かっています。 しかし、MySQLまたはjQueryのレベルである爆弾はまだ実現していません。つまり、まだ準備が整っていないということです。



たとえば、情報中心でイベント指向のCRDTを精神的に横断すると、仮想のCRDTバスが得られます。これにより、同じCORBA / DCOM / RMIとは異なり、リモートオブジェクトにアクセスするだけでなく、ローカルコピーを操作することができます。 同時に、これらのローカルコピーはフラットな「キャッシュ」ではなく、記録機能を備えた本格的なライブレプリカであり、自動的に同期されます。



将来のWebアプリケーションのアーキテクチャではないものは何ですか？