GrouponがモノリシックRailsアプリケーションから新しいNode.jsインフラストラクチャに移行した方法

I-Tier：モノリス切断

最近、米国でのGrouponの年間Webトラフィック移行プロジェクトを、モノリシックなRuby on Railsアプリケーションから新しいNode.jsスタックに完了し、大きな成果を上げました。



最初から、アメリカのフロントエンドWebフロントエンド全体がRubyの単一のソースコードでした。 フロントエンドコードは急速に開発されたため、新しい機能を追加するプロセスの維持と複雑化が困難になりました。 この巨大なモノリスの問題の解決策として、フロントエンドをより小さく、独立した、管理しやすいパーツに分割することにより、フロントエンドを再構築することにしました。 このプロジェクトの基本は、モノリシックWebサイトをいくつかの独立したNode.jsアプリケーションに分離することでした。 また、インフラストラクチャを再設計して、すべてのアプリケーションが連携するようにしました。 その結果、インタラクション層（I-Tier）ができました。



このグローバルアーキテクチャ移行のハイライトの一部を以下に示します。



•サイト上のページの読み込みがはるかに高速



•開発チームは、新しい機能をより迅速に開発および追加でき、他のチームにあまり依存しません。



•Grouponが利用可能なさまざまな国で同じ機能を再開発することを回避できます。



この投稿は、Googleがサイトを再構築した方法と、Groupon社の発展の基礎となる将来的に見られる大きな利点に関する一連の投稿の最初のものです。

簡単な歴史

Grouponはもともと、シカゴの住民への毎日の取引を表示する1ページのサイトでした。 そのような典型的な取引の例としては、地元のレストランの割引や地元のコンサートのチケットがあります。



各トランザクションには「転換点」があります。これは、トランザクションを有効にするためにトランザクションを購入する必要がある最小数です。 十分な数の人が転換点に達する取引を購入した場合、誰もが割引を受けました。 そうでなければ、誰もが敗者でした。



このサイトは元々、Ruby on Railsアプリケーションとして作成されました。 Railsアプリケーションは、開発チームにとって、サイトをすばやく立ち上げて立ち上げる最も簡単な方法の1つであったため、最初は良い選択でした。 さらに、Railsを使用して新機能を実装するのはかなり簡単でした。 その時点では、機能のセットが常に増加していたため、私たちにとって大きなプラスでした。



元のRailsアーキテクチャは非常にシンプルでした。







ただし、単一のデータベースクラスターを対象とした単一のRailsアプリケーションでは、すべてのトラフィックを処理する能力がすぐに大きくなりました。 フロントエンドサーバーとデータベースレプリカをさらに追加し、すべてをCDNの背後に配置しましたが、これはデータベースへの書き込みが重要な要素になるまでしか機能しませんでした。 注文処理により、データベースに多数のエントリが発生しました。 その結果、このコードをRailsアプリケーションから別のデータベースクラスターを使用する新しいサービスに移動することにしました。



既存のバックエンドの割り当てを新しいサービスに分割し、同様のパターンを継続しましたが、ウェブサイトの他のすべて（ビュー、コントローラー、リソースなど）は元のRailsアプリケーションの一部のままでした：







このアーキテクチャの変更は時間を稼ぎましたが、それが長くは続かないことはわかっていました。 ソースコードは、以前のように、当時は開発者の小さなチームでしか管理できませんでした。これにより、トラフィックのピーク時にサイトを混雑から守ることができました。

グローバリゼーション

この頃、Grouponはグローバルに拡大し始めました。 短期間で、米国のみでの事業から48か国での事業に移行しました。 この間に、CityDealなどの国際企業も買収しました。 各買収には、すでに独自のソフトウェアスタックが含まれていました。



CityDealアーキテクチャはGrouponアーキテクチャと類似していますが、別のチームによって作成された完全に自律的な実装でした。 その結果、設計と技術に違いがありました-Rubyの代わりにJava、nginxの代わりにApache、MySQLの代わりにPostgreSQL。







ご覧のように、急速に発展している企業の場合、異なるスタックの統合のペースを遅くするか、両方のシステムをサポートするかを選択する必要がありました。 会社のより急速な発展と引き換えに、アメリカとヨーロッパの販売を分離するという国際的な決定を初めて行いました。 そして、買収が増えるにつれて、アーキテクチャに複雑さが追加されました。

モバイルアプリ

また、iPhone、iPad、Android、およびWindows Mobile用のモバイルクライアントを作成しました。 Grouponが利用できる国ごとに個別のモバイルアプリケーションを作成したくはありませんでした。 代わりに、バックエンドソフトウェアプラットフォームのそれぞれの上にAPIレイヤーを作成することにしました。 モバイルクライアントは、ユーザーの国に対応するAPIエンドポイントを使用しました。







私たちのモバイルチームにとってはうまくいきました。 彼らは、私たちの国のすべてで機能するモバイルアプリケーションを構築できます。



しかし、まだ問題がありました。 新しい製品または機能を作成するときはいつでも、最初にWeb用に作成してからAPIを作成したので、その機能はモバイルデバイスで使用できます。



私たちの会社はアメリカで半分モバイルになったので、まずモバイルの考え方を構築する必要があります。 したがって、最小限の開発労力でモバイルクライアントとデスクトップクライアントに個別のバックエンドが対応できるアーキテクチャを作成したいと考えています。

複合モノリス

Grouponは新しい製品の開発と発売を続けましたが、Rubyフロントエンドのソースコードの量は増加していました。 同じコードに取り組んでいる開発者が多すぎます。 これは、開発者がアプリケーションをローカルで実行するのを困難にするほどでした。 テストスイートの速度が低下し、信頼性の低いテストが問題になりました。 また、1つのコードベースであったため、アプリケーション全体を緊急に展開する必要がありました。 1つの機能ではなく、ロールバックを必要とする運用環境でエラーが発生した場合、各チームへの変更が返されます。 つまり、モノリシックコードには多くの問題がありました。



しかし、私たちは繰り返し同様の問題に直面しています。 米国でコードを処理する必要があっただけでなく、ヨーロッパのコードでも同じ問題の多くが発生しました。 フロントエンドを完全に再構築する必要がありました。

すべて書き換える

フロントエンド全体を再構築するのは危険です。 これには多くの時間を要し、多くの異なる人々が関与します。そして、最終的には古いシステムよりも良い結果が得られない大きな可能性があります。 または、さらに悪いことに、それは多くの時間を要し、あなたは途中でgiveめ、それに多くの努力を費やしますが、結果は得られません。



しかし、インフラストラクチャの小さな部分を再構築したとき、過去に大きな成功を収めました。 たとえば、モバイルWebサイトとクライアントポータルの両方が優れた結果で再構築されました。 この経験は良い出発点となり、それからプロジェクトの目標を設定し始めました。

目標1：フロントエンドを組み合わせる

さまざまな国で同じ機能を実装する多数のソフトウェアスタックがあるため、必要な速度で移動できませんでした。 スタックの冗長性を排除する必要がありました。

目標2：モバイルアプリをウェブと同等にする

米国の会社の約半分がモバイルになったため、デスクトップとモバイルのバージョンを個別に作成する余裕はありませんでした。 Webがモバイルアプリケーションと同じAPIを使用する別のクライアントになるアーキテクチャが必要でした。

目標3：サイトを高速化する

私たちのサイトは私たちが望んでいたよりも遅かった。 急いでサイトの成長を制御しようとしていましたが、米国のフロントエンドは技術的負債を蓄積していたため、最適化が困難でした。 リクエストを処理するために多くのコードを必要としないソリューションを探していました。 シンプルなものが欲しかった。

目標4：チームが独立して前進できるようにする

Grouponが最初にローンチされたとき、サイトは本当にシンプルでした。 しかし、それ以来、世界中のそれらをサポートするために、開発チームに多くの新製品を追加しました。 各チームが、他のチームとは独立して、迅速に機能を作成および展開できるようにしたかったのです。 チーム間の相互依存関係を排除する必要がありました。その理由は、すべてが1つのコードに含まれていたためです。

アプローチ

最初に、サイトの各主要機能を個別のWebアプリケーションに分解することにしました。







Node.jsにフレームワークを構築しました。これには、すべてのアプリケーションに必要な一般的な機能が含まれていたため、チームはこれらの個々のアプリケーションを簡単に作成できました。

注：Node.jsを使用する理由

新しいフロントエンドレイヤーを構築する前に、いくつかの異なるソフトウェアスタックを評価して、どれが最適かを判断しました。



特定のタスクのソリューションを探していました-多くの着信HTTPリクエストを効率的に処理し、これらの各HTTPリクエストのサービスに対して並列APIリクエストを実行します。 結果をHTMLに返します。 また、自信を持って監視、展開、サポートできるものが必要でした。



複数のソフトウェアスタックを使用してプロトタイプを作成し、テストしました。 詳細については後ほど詳細を掲載しますが、一般的にNode.jsはこの特定の問題に適していることがわかりました。

アプローチ、続き...

次に、上部にルーティングレイヤーを追加し、ユーザーがアクセスしたページに基づいて適切なアプリケーションにリダイレクトしました。







Grouponルーティングサービス（Groutと呼ばれる）をnginxモジュールとして構築しました。 これにより、異なるサーバー上の同じアプリケーションの異なる実装間でA / Bテストを実行するなど、多くの興味深いことができます。



これらの独立したWebアプリケーションがすべて正常に連携するように、一般的な構成をサポートし、A / Bテストモードを制御するレイアウトとCSSスタイルを共有するための個別のサービスを作成しました。 これらのサービスに関する詳細情報は後日掲載します。



これらはすべてAPIの前にあり、フロントエンドレイヤーではデータベースまたはバックエンドサービスに直接アクセスすることはできません。 これにより、デスクトップアプリケーションとモバイルアプリケーションの両方に対応する単一の統合APIレイヤーを作成できます。







バックエンドシステムの統合に取り組んでいますが、短期的には米国および欧州のサブシステムをサポートする必要があります。 したがって、同時に、2つのバックエンドで動作するフロントエンドを開発しました。

結果：

米国のフロントエンドのRubyから新しいNode.jsへの移行が完了しました。 古いモノリシックフロントエンドは約20の個別のWebアプリケーションに分割され、それぞれが完全に書き直されました。 現在、1分あたり平均50,000件のリクエストを処理していますが、このトラフィックはホリデーシーズン中に増加すると予想されます。 そして、この数は他の48か国からトラフィックを移動するため、大幅に増加します。



これらは私達が最近確認した利点です：



-ページの読み込みが速くなります-通常は50％。 これは、一部はテクノロジーの変更によるものであり、一部は、すべてのWebページを書き換えて物事を高速化する機会があったためです。 また、追加の変更を行っているため、ここで重要な変更を行う予定です。



-古いスタックよりも少ない機器で同じ量のトラフィックを処理します。



-チームは、アプリケーションへの変更を独立して展開できます。



-古いアーキテクチャを使用するよりもはるかに高速に個々の機能のコードを変更できます。



一般に、この移行により、開発チームはより少ない相互依存関係でページをより速く読み込むことができ、古いプラットフォームのパフォーマンスの制限が取り除かれました。 ただし、将来的には他の多くの改善を行う予定であり、近い将来に詳細を掲載する予定です。



[engineering.groupon.comの元の記事 ]