Dodo IS アーキテクチャの歴史: 初期のモノリス

あるいは、一枚岩を持つ不幸な企業はすべて、それぞれの形で不幸です。

Dodo IS システムの開発は、Dodo Pizza ビジネスと同様、2011 年にすぐに開始されました。 ビジネスプロセスの完全かつトータルなデジタル化という考えに基づいており、 私自身で、2011年の当時でさえ、多くの疑問と懐疑を引き起こしました。 しかし、9 年間、私たちはこの道をたどり、モノリスから始まった独自の開発を続けてきました。

この記事は、「なぜアーキテクチャを書き換えて、これほど大規模かつ長期的な変更を行う必要があるのか​​?」という質問に対する「答え」です。 前の記事に戻る 「Dodo IS アーキテクチャの歴史: バック オフィスのあり方」。 まず、Dodo IS の開発がどのように始まったか、元のアーキテクチャがどのようなものか、新しいモジュールがどのように登場したか、そしてどのような問題があったために大規模な変更を行う必要があったのかについて説明します。

連載「Dodo ISとは？」 について語ります:

1. ドードー IS の初期のモノリス (2011 ～ 2015)。 （あなたはここにいる）

2. バックオフィスのパス: 個別のベースとバス.

3. クライアント側のパス: ベース上のファサード (2016-2017)。 （進行中...）

4. 本物のマイクロサービスの歴史。 (2018-2019)。 （進行中...）

5. モノリスの切断が完了し、アーキテクチャが安定化しました。 （進行中…）

初期アーキテクチャ

2011 年の Dodo IS アーキテクチャは次のようになっていました。

アーキテクチャの最初のモジュールは注文の受付です。 ビジネスプロセスは次のとおりです。

• 顧客はピッツェリアに電話します。

• マネージャーが電話に出る。

• 電話で注文を受け付けます。

• 注文受付インターフェースに並行して入力します。クライアントに関する情報、注文詳細のデータ、配送先住所が考慮されます。 

情報システムのインターフェースはこんな感じでした…

2011 年 XNUMX 月の最初のバージョン:

2012年XNUMX月に若干改善

Dodoピザ情報システム 宅配ピザレストラン

最初の注文受付モジュールを開発するためのリソースは限られていました。 私たちは小規模なチームで多くのことを迅速に行う必要がありました。 将来のシステム全体の基礎を築いた 2 人の開発者からなる小規模なチームです。

彼らの最初の決定が、テクノロジー スタックの運命を決定しました。

• ASP.NET MVC、C#言語のバックエンド。 開発者は dotnetchiki で、このスタックは彼らにとって馴染みがあり、快適なものでした。

• ブートストラップと JQuery のフロントエンド: 自作のスタイルとスクリプトのユーザー インターフェイス。 

• MySQL データベース: ライセンス費用がかからず、使いやすい。

• Windows Server 上のサーバー。.NET は Windows 上でのみ存在できるためです (Mono については説明しません)。

物理的には、これらすべてが「主催者の献辞」で表現されました。 

受注アプリケーションのアーキテクチャ

当時、誰もがすでにマイクロサービスについて話しており、SOA は 5 年間にわたって大規模なプロジェクトで使用されていました。たとえば、WCF は 2006 年にリリースされました。 しかしその後、彼らは信頼性が高く実績のあるソリューションを選択しました。

ここにあります。

Asp.Net MVC は Razor であり、フォームまたはクライアントからの要求に応じて、サーバー レンダリングで HTML ページをレンダリングします。 クライアントでは、CSS スクリプトと JS スクリプトがすでに情報を表示し、必要に応じて JQuery を通じて AJAX リクエストを実行します。

サーバー上のリクエストは *Controller クラスに到達し、最終的な HTML ページの処理と生成がメソッド内で行われます。 コントローラーは、*Services と呼ばれるロジック層にリクエストを作成します。 各サービスはビジネスのいくつかの側面に対応していました。

• たとえば、DepartmentStructureService はピザ屋や部門に関する情報を提供しました。 部門とは、単一のフランチャイズ加盟者が運営するピッツェリアのグループです。

• ReceivingOrdersService は注文の構成を受け入れ、計算しました。

• そして、SmsService は SMS を送信する API サービスを呼び出して SMS を送信しました。

サービスはデータベースからのデータを処理し、ビジネス ロジックを保存します。 各サービスには、適切な名前を持つ XNUMX つ以上の *リポジトリがありました。 これらには、データベース内のストアド プロシージャへのクエリとマッパーの層がすでに含まれていました。 ストレージにはビジネス ロジックが存在し、特にレポート データを発行するストレージには多くのロジックが存在しました。 ORM は使用されず、全員が手書きの SQL に依存していました。 

ドメイン モデルの層と一般的なヘルパー クラス (注文を保存する Order クラスなど) もありました。 同じ場所のレイヤーに、選択した通貨に応じて表示テキストを変換するためのヘルパーがありました。

これらすべては次のようなモデルで表すことができます。

注文方法

このような注文を作成するための簡素化された最初の方法を検討してください。

当初、サイトは静的でした。 それには価格が書かれており、その上には電話番号と「ピザが欲しいなら、その番号に電話して注文してください」という碑文が書かれていました。 注文するには、次のような簡単なフローを実装する必要があります。 

• 顧客は価格が記載された静的サイトにアクセスし、製品を選択し、サイトに記載されている番号に電話します。

• 顧客は注文に追加したい製品に名前を付けます。

• 住所と名前を明かします。

• オペレーターが注文を受け付けます。

• 注文は受け付けられた注文インターフェイスに表示されます。

すべてはメニューを表示することから始まります。 ログインしたユーザーオペレーターは、一度に XNUMX つの注文のみを受け入れます。 したがって、ドラフト カートはそのユーザーのセッションに保存できます (ユーザーのセッションはメモリに保存されます)。 製品と顧客情報を含む Cart オブジェクトがあります。

顧客が製品に名前を付け、オペレーターが製品をクリックします。 + 製品の横にあるをクリックすると、リクエストがサーバーに送信されます。 製品に関する情報がデータベースから抽出され、製品に関する情報がカートに追加されます。

注意。 はい、ここではデータベースから製品を取得することはできませんが、フロントエンドから転送することができます。 ただし、わかりやすくするために、データベースからのパスを正確に示しました。 

次に、依頼者の住所と名前を入力します。 

「注文の作成」をクリックすると、次のようになります。

• リクエストは OrderController.SaveOrder() に送信されます。

• セッションからカートを取得します。必要な数量の製品があります。

• Cart にクライアントに関する情報を追加し、それを ReceivingOrderService クラスの AddOrder メソッドに渡し、データベースに保存します。 

• データベースには、注文、注文の構成、クライアントを含むテーブルがあり、それらはすべて接続されています。

• 注文表示インターフェイスは最新の注文を取り出して表示します。

新しいモジュール

注文を取ることは重要かつ必要でした。 販売注文がなければピザのビジネスはできません。 したがって、システムはおよそ2012年から2015年にかけて機能を獲得し始めました。 この間、システムのさまざまなブロックが出現しました。 モジュール、サービスや製品の概念とは対照的です。 

モジュールは、何らかの共通のビジネス目標によって統合された機能のセットです。 同時に、それらは物理的に同じアプリケーション内にあります。

モジュールはシステム ブロックと呼ばれることがあります。 たとえば、これはレポート モジュール、管理インターフェイス、 キッチンのフードトラッカー、認可。 これらはすべて異なるユーザー インターフェイスであり、視覚スタイルが異なるものもあります。 同時に、すべてが XNUMX つのアプリケーション、XNUMX つの実行プロセスのフレームワーク内にあります。 

技術的には、モジュールはエリアとして設計されました (そのようなアイデアは、 asp.netコア）。 フロントエンド、モデル、および独自のコントローラー クラス用に個別のファイルがありました。 その結果、システムはこれまでから変わりました...

...これに:

一部のモジュールは、完全に別個の機能のため、また部分的には少し別個の、より焦点を絞った開発のため、別個のサイト (実行可能プロジェクト) によって実装されます。 これ：

• Site - 最初のバージョン サイトdodopizza.ru。

• 輸出: 1C の Dodo IS からレポートをアップロードします。 

• 個人 - 従業員の個人アカウント。 これは個別に開発され、独自のエントリ ポイントと個別の設計を備えています。

• fs — 静的情報をホストするためのプロジェクト。 その後、私たちはそこから離れ、すべての静的情報を Akamai CDN に移動しました。 

残りのブロックは BackOffice アプリケーション内にありました。 

名前の説明:

• キャッシャー - レストランのレジ係。

• ShiftManager - 「シフト マネージャー」ロールのインターフェイス: ピッツェリアの売上に関する営業統計、製品をストップ リストに登録し、順序を変更する機能。

• OfficeManager - 「ピッツェリア マネージャー」および「フランチャイズ店」ロールのインターフェイス。 ここでは、ピッツェリアのセットアップ、ボーナスプロモーション、従業員の受け取りと協力、レポートに関する機能を集めました。

• PublicScreens - ピッツェリアに吊るされているテレビやタブレット用のインターフェイス。 テレビにはメニュー、広告情報、配達時の注文状況が表示されます。 

彼らは、共通のサービス層、共通の Dodo.Core ドメイン クラス ブロック、および共通のベースを使用しました。 時々、彼らはまだお互いに移行に沿ってリードすることができます。 dodopizza.ru やpersonal.dodopizza.ru などの個別のサイトも含めて、一般サービスに移行しました。

新しいモジュールが登場したときは、すでに作成されているサービス、ストアド プロシージャ、データベース内のテーブルのコードを最大限に再利用するようにしました。 

システムで作成されたモジュールの規模をよりよく理解するために、開発計画を含む 2012 年の図を次に示します。

2015 年までに、すべてが地図上にあり、さらに多くのものが実用化されました。

• 注文の受付はコンタクト センターの別のブロックに成長し、オペレーターが注文を受け付けます。

• ピッツェリアにはメニューや情報を掲示した公共スクリーンが設置されていました。

• キッチンには、新しい注文が到着すると「新しいピザ」という音声メッセージを自動的に再生し、宅配業者への請求書を印刷するモジュールがあります。 これにより、キッチンでのプロセスが大幅に簡素化され、従業員は多数の単純な操作に気を取られることがなくなります。

• 配送単位は別個の配送チェックアウトとなり、以前にシフトを担当していた宅配業者に注文が発行されました。 彼の労働時間は給与計算に考慮されました。 

並行して、2012 年から 2015 年にかけて 10 人以上の開発者が現れ、35 軒のピッツェリアがオープンし、ルーマニアにシステムを導入し、米国での店舗開設の準備をしました。 開発者はすべてのタスクを担当するのではなく、いくつかのチームに分かれるようになりました。 それぞれがシステムの独自の部分に特化しています。 

問題

アーキテクチャによるものも含まれます (それだけではありません)。

基地内の混乱

拠点が一つあると便利です。 一貫性は、リレーショナル データベースに組み込まれたツールを犠牲にして実現できます。 特にテーブルが少なくデータが少ない場合には、これを使用するのが馴染みがあり便利です。

しかし、4 年間の開発を経て、データベースには約 600 のテーブルと 1500 のストアド プロシージャがあり、その多くにはロジックも含まれていることが判明しました。 残念ながら、MySQL を使用する場合、ストアド プロシージャにはあまり利点がありません。 これらはベースによってキャッシュされず、そこにロジックを保存すると開発とデバッグが複雑になります。 コードの再利用も困難です。

多くのテーブルには適切なインデックスがありませんでした、どこか、逆にインデックスが多くて挿入が困難でした。 約 20 のテーブルを変更する必要がありました。注文を作成するトランザクションには約 3 ～ 5 秒かかることがありました。 

テーブル内のデータが常に最適な形式であるとは限りませんでした。 どこかで非正規化を行う必要がありました。 定期的に受信するデータの一部は XML 構造の形式で列に含まれていたため、実行時間が増加し、クエリが長くなり、開発が複雑になりました。

同じテーブルに非常に生産されました 異種リクエスト。 上記のテーブルのように、人気のあるテーブルが特に被害を受けました。 受注 またはテーブル ピザ屋。 これらは、キッチンでの操作インターフェイスの表示や分析に使用されていました。 別のサイトから連絡がありました (ドドピザ.ru）、いつでも大量のリクエストが突然来る可能性があります。 

データは集計されていませんでした そして、ベースを使用して多くの計算がその場で行われました。 これにより、不必要な計算と追加の負荷が発生しました。 

多くの場合、コードはデータベースに送信できなかったのに、データベースに送信されました。 バルク操作が十分ではない箇所があり、速度を上げて信頼性を高めるために、コードを通じて XNUMX つのリクエストを複数のリクエストに分散する必要がある箇所があります。 

コードの凝集性と難読化

ビジネスの一部を担当するはずのモジュールが誠実にそれを実行しなかった。 それらの中には、ロールの機能が重複しているものもありました。 たとえば、自分の都市でネットワークのマーケティング活動を担当する地元のマーケティング担当者は、「管理者」インターフェイス (プロモーションを作成するため) と「オフィス マネージャー」インターフェイス (ビジネスに対するプロモーションの影響を確認するため) の両方を使用する必要がありました。 もちろん、両方のモジュール内では、ボーナス プロモーションで機能する同じサービスが使用されました。

サービス (XNUMX つのモノリシックな大規模プロジェクト内のクラス) は、データを強化するために相互に呼び出しを行うことができます。

データを格納するモデルクラス自体では、 コード内の作業が異なる方法で実行されました。 どこかに、必須フィールドを指定できるコンストラクターがありました。 どこかでこれは公共財産を通じて行われました。 もちろん、データベースからのデータの取得と変換にはさまざまな方法がありました。 

ロジックはコントローラーまたはサービス クラスのいずれかにありました。 

これらは小さな問題のように見えますが、開発が大幅に遅れ、品質が低下し、不安定性やバグが発生しました。 

大規模な開発の複雑さ

開発自体に困難が生じた。 システムのさまざまなブロックを並行して作成する必要がありました。 各コンポーネントのニーズを単一のコードに適合させることはますます困難になってきました。 すべてのコンポーネントに同意し、同時に満足させるのは簡単ではありませんでした。 これに、特にベースとフロントエンドに関するテクノロジーの制限が加わりました。 特にクライアント サービス (Web サイト) の観点から、高レベルのフレームワークに向けて jQuery を放棄する必要がありました。

システムの一部では、これに適したデータベースが使用される場合があります。。 たとえば、後で注文バスケットを保存するために Redis から CosmosDB に移行するユースケースがありました。 

それぞれの分野に携わるチームや開発者は、開発と展開の両方の観点から、サービスの自律性を高めることを明らかに望んでいます。 マージ競合、リリースの問題。 5 人の開発者にとってこの問題は重要ではありませんが、10 人になると、さらに計画的な成長を伴うと、すべてがより深刻になります。 そして、その先にはモバイル アプリケーションの開発が待っていました (2017 年に開始され、2018 年には 大きな秋). 

システムの異なる部分には異なるレベルの安定性が必要です、ただし、システムの接続が強力であるため、これを提供できませんでした。 コードは共通で再利用可能であり、データベースとデータも同じであるため、管理パネルでの新しい機能の開発でエラーが発生した可能性は十分にあります。

おそらく、このようなモノリシックモジュール型アーキテクチャのフレームワーク内でこれらの間違いや問題を回避することは可能でしょう。責任を分担し、コードとデータベースの両方をリファクタリングし、レイヤーを互いに明確に分離し、品質を毎日監視します。 しかし、選択されたアーキテクチャ ソリューションとシステム機能の急速な拡張に焦点を当てた結果、安定性の点で問題が発生しました。

Power of the Mind ブログがレストランのレジをどのように導入したか

ピッツェリア ネットワーク (および負荷) の成長が同じペースで続いた場合、しばらくすると、システムが上昇しなくなるほど低下します。 2015 年までに私たちが直面し始めた問題をよく表しています。ここにそのような話があります。 

ブログでは「マインドパワー」は、ネットワーク全体の年間収益に関するデータを表示するウィジェットでした。 ウィジェットは、このデータを提供する Dodo パブリック API にアクセスしました。 この統計は現在、次の場所で入手できます。 http://dodopizzastory.com/。 ウィジェットはすべてのページに表示され、20 秒ごとにタイマーでリクエストを実行しました。 リクエストは api.dodopizza.ru に送られ、次のことが要求されました。

• ネットワーク内のピッツェリアの数。

• 年初以降のネットワーク収益の合計。

• 今日の収益。

収益に関する統計のリクエストはデータベースに直接送信され、注文に関するデータのリクエストが開始され、その場でデータが集計されて金額が表示されます。 

レストランのレジは同じ注文テーブルに行き、今日受け取った注文のリストをアンロードし、新しい注文がリストに追加されました。 レジは 5 秒ごと、またはページの更新時にリクエストを行いました。

図は次のようになりました。

ある秋、フョードル・オフチニコフは自身のブログに長くて人気のある記事を書きました。 多くの人がこのブログに来て、すべてを注意深く読み始めました。 訪問者がそれぞれ記事を読んでいる間、収益ウィジェットは適切に動作し、20 秒ごとに API をリクエストしました。

API はストアド プロシージャを呼び出して、チェーン内のすべてのピッツェリアに対する年初以降のすべての注文の合計を計算しました。 集計は、非常に人気のある注文テーブルに基づいて行われました。 その時間に開いているすべてのレストランのレジはすべてそこに行きます。 レジは応答を停止し、注文は受け付けられませんでした。 また、それらはサイトから受け入れられず、トラッカーに表示されず、シフトマネージャーのインターフェースでそれらを確認できませんでした。 

これだけの話ではありません。 2015 年の秋までに、毎週金曜日にはシステムの負荷が重大なものになりました。 何度かパブリック API をオフにし、何も役に立たなかったためにサイトをオフにしなければならなかったときもありました。 高負荷時にシャットダウン命令が出されているサービスのリストもありました。

これから、負荷との闘いとシステムの安定化への闘いが始まります（2015年秋から2018年秋まで）。 そのとき、それは起こった」素晴らしい秋」。 さらに、障害も時々発生し、その中には非常に敏感なものもありましたが、現在では一般的な不安定期間は過ぎたと考えられます。

ビジネスの急速な成長

なぜすぐに実行できなかったのでしょうか？ 次のグラフを見てください。

また、2014 年から 2015 年にかけてルーマニアでの出店があり、米国での出店も準備されていました。

ネットワークは非常に急速に成長し、新しい国が開かれ、新しい形式のピッツェリアが登場しました。たとえば、フードコートにピッツェリアがオープンしました。 これらすべてを行うには、特に Dodo IS 機能の拡張に多大な注意を払う必要がありました。 これらすべての機能がなければ、キッチンでの追跡、システムでの製品と損失の計算、フードコートのホールでの注文の発行の表示がなければ、「正しい」アーキテクチャや、「正しい」アプローチについて語ることはほとんどないでしょう。今開発中。

アーキテクチャをタイムリーに改訂し、技術的な問題に一般的に注意を払うことに対するもう 2014 つの障害は、XNUMX 年の危機でした。 このような事態は、特にドドピザのような若いビジネスにとって、チームが成長する機会に大きな打撃を与えました。

役に立った簡単な解決策

問題には解決策が必要でした。 従来、ソリューションは 2 つのグループに分類できます。

• 早いものは火を消し、わずかな安全マージンを与え、着替えの時間を稼ぎます。

• システム的であり、したがって長いです。 多数のモジュールのリエンジニアリング、モノリシック アーキテクチャの個別のサービスへの分割 (それらのほとんどはまったくマイクロ サービスではなく、むしろマクロ サービスであり、これには何かがあります) アンドレイ・モレフスキーのレポート). 

クイック変更の完全なリストは次のとおりです。

ベースマスターをスケールアップする

もちろん、負荷に対処するために最初に行われるのは、サーバーの容量を増やすことです。 これは、マスター データベースと Web サーバーに対して行われました。 残念ながら、これは一定の制限までしか可能であり、それを超えるとコストが高くなりすぎます。

2014 年以降、私たちは Azure に移行しました。このトピックについては、当時の記事「Dodo Pizza が Microsoft Azure クラウドを使用してピザを配達する方法」。 しかし、基地のサーバーを次々と増設した結果、コストがかかるようになりました。 

読み取り用のベースレプリカ

ベース用に XNUMX つのレプリカが作成されました。

リードレプリカ 参照リクエスト用。 これは、ディレクトリ、タイプ、都市、通り、ピッツェリア、製品 (ゆっくりと変更されるドメイン) を読み取るために、およびわずかな遅延が許容されるインターフェイスで使用されます。 これらのレプリカは 2 つあり、マスターと同じ方法で可用性を確保しました。

レポートリクエスト用のリードレプリカ。 このデータベースは可用性が低かったですが、すべてのレポートがそこに送られました。 膨大なデータの再計算を大量に要求しても、メインのデータベースや操作インターフェイスには影響しません。 

コード内のキャッシュ

コードのどこにもキャッシュは（まったく）ありませんでした。 これにより、ロードされたデータベースに対して、必ずしも必要ではない追加のリクエストが発生しました。 キャッシュは当初、メモリ内と外部キャッシュ サービス (Redis) の両方にありました。 時間によってすべてが無効になり、設定はコードで指定されました。

複数のバックエンドサーバー

増加したワークロードを処理するには、アプリケーションのバックエンドもスケーリングする必要がありました。 XNUMX つの iis-server からクラスターを作成する必要がありました。 予定を変更しました アプリケーションセッション メモリから RedisCache まで、ラウンドロビンを使用した単純なロード バランサーの背後に複数のサーバーを作成できるようになりました。 最初はキャッシュとして同じ Redis が使用されていましたが、その後いくつかに分割されました。 

その結果、アーキテクチャはより複雑になりました...

…しかし、緊張の一部は解消されました。

そして、ロードされたコンポーネントをやり直す必要があり、それを実行しました。 これについては次のパートで説明します。

出所： habr.com