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

あるいは、不幸な巨大企業はどれも、それぞれの意味で不幸なのです。

Dodo ISシステムの開発は、Dodo Pizza事業の開始直後、つまり2011年に始まりました。そのアイデアは、ビジネスプロセスの完全かつ包括的なデジタル化に基づいており、私自身で2011 年当時でも多くの疑問や懐疑的な意見が寄せられていました。しかし、私たちはモノリスから始まった独自の開発で、この道を歩み始めてから 9 年が経ちました。

この記事は、「なぜアーキテクチャを書き直し、このような大規模で時間のかかる変更を行うのか？」という質問に対する「答え」です。前の記事へ「Dodo IS アーキテクチャの歴史: バックオフィスの旅」。まず、Dodo IS の開発がどのように始まったのか、初期のアーキテクチャはどのようなものだったのか、新しいモジュールがどのように登場したのか、そしてどのような問題が大規模な変更を必要としたのかについて説明します。

連載記事「Dodo IS とは何か?」以下についてお話します:

Dodo IS の初期のモノリス (2011-2015)。（あなたはここにいる）
バックオフィスパス：データベースとバスを分離.
クライアント部分のパス：ベースの上のファサード（2016-2017）。（進行中…）
実際のマイクロサービスの歴史。（2018-2019年）。（進行中…）
モノリスの切断とアーキテクチャの安定化が完了しました。（進行中…）

オリジナルの建築

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

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

顧客がピザ屋に電話をかけます。
マネージャーが電話に出る。
電話での注文も受け付けております。
同時に、注文受付インターフェースに入力され、クライアント、注文の詳細、配送先住所に関する情報が考慮されます。

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

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

2012年XNUMX月に若干改善

情報システム Dodo Pizza デリバリーピザレストラン

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

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

ASP.NET MVC、C# 言語のバックエンド。開発者はドットネット開発者であり、このスタックは彼らにとって馴染み深く、快適なものでした。
Bootstrap と JQuery のフロントエンド: カスタムスタイルとスクリプトのユーザーインターフェイス。
MySQL データベース: ライセンス費用がかからず、使いやすい。
サーバー Windows Server.NET は、 Windows （伝染性単核球症については議論しません。）

物理的には、これらすべてが「ホストの専用サーバー」で表現されていました。

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

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

ここにあります。

Asp.Net MVC は、フォームまたはクライアントから要求されたときにサーバー側でレンダリングされた HTML ページを生成する Razor です。クライアントでは、CSS および JS スクリプトによってすでに情報が表示されており、必要に応じて JQuery 経由で AJAX リクエストが実行されます。

サーバー上のリクエストは *Controller クラスに送信され、そこでメソッドが処理して最終的な HTML ページを生成します。コントローラーは、*Services と呼ばれるロジック層にリクエストを送信します。各サービスは、ビジネスの何らかの側面に対応していました。

たとえば、DepartmentStructureService はピザ店に関する情報を部門別に提供しました。部門とは、1 つのフランチャイジーによって管理されるピザ店のグループです。
ReceivingOrdersService は注文の構成を承認し、計算しました。
そして、SmsService は SMS 送信用の API サービスを呼び出して SMS を送信しました。

サービスはデータベースからのデータを処理し、ビジネスロジックを保存しました。各サービスには、対応する名前を持つ 1 つ以上の *Repository がありました。これらには、データベース内のストアドプロシージャへのクエリとマッパーのレイヤーがすでに含まれていました。ストアにはビジネスロジック (特にレポートデータを生成するロジック) が含まれていました。 ORM は使用されず、全員が手書きの SQL に依存していました。

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

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

注文経路

このような注文を作成するための簡略化された初期パスを見てみましょう。

当初、このサイトは静的なものでした。値段が書かれていて、上部には電話番号と「ピザが欲しかったらこの番号に電話して注文してください」という文字が書かれていました。注文するには、簡単なフローを実装する必要があります。

クライアントは価格が記載されている静的サイトにアクセスし、製品を選択して、サイトに記載されている番号に電話をかけます。
顧客は注文に追加したい製品に名前を付けます。
住所と名前を伝えます。
オペレーターが注文を承諾します。
注文は、承認された注文インターフェースに表示されます。

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

顧客が商品名を指定すると、オペレーターが + 製品の横にクリックすると、サーバーにリクエストが送信されます。製品に関する情報がデータベースから取得され、製品に関する情報がカートに追加されます。

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

次に、クライアントの住所と名前を入力します。

「注文を作成」をクリックすると：

リクエストを OrderController.SaveOrder() に送信します。
セッションからカートを取得します。そこには必要な数量の製品が含まれています。
Cart にクライアントに関する情報を補足し、それを ReceivingOrderService クラスの AddOrder メソッドに渡して、データベースに保存します。
データベースには、注文、注文構成、クライアントを含むテーブルが含まれており、それらはすべて接続されています。
注文表示インターフェースは最新の注文を取り出して表示します。

新しいモジュール

注文を受けることは重要かつ必要でした。ピザを販売するための注文受付システムがなければ、ピザのビジネスを行うことはできません。そのため、システムは2012年から2015年頃に機能を獲得し始めました。この間に、多くの異なるシステムブロックが登場しました。 モジュールサービスや製品の概念とは対照的です。

モジュールとは、共通のビジネス目標によって統合された一連の機能です。同時に、それらは物理的に同じアプリケーション内に配置されます。

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

技術的には、モジュールはエリアとして設計されました（このアイデアは 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軒のピザ店がオープンし、システムはルーマニアに拡大され、米国での出店も準備されました。開発者はすべてのタスクを処理するのではなく、チームに分かれて取り組むようになりました。それぞれがシステムの独自の部分に特化しています。

問題

アーキテクチャの理由も含みます（ただしそれだけではありません）。

基地の混乱

ベースは1つあると便利です。一貫性はリレーショナルデータベースに組み込まれたツールを使用して実現されます。特にテーブルやデータが少ない場合には、使い慣れていて便利です。

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

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

表内のデータは必ずしも最適な形式ではありませんでした。。どこかで非正規化を行う必要がありました。定期的に受信されるデータの一部は XML 構造形式の列であったため、実行時間が長くなり、クエリが長くなり、開発が複雑になりました。

同じテーブルに非常に多くの変更が加えられました 異種のリクエスト。上記のような人気のテーブルは特に受注またはテーブル ピザ屋。これらは、キッチンの操作インターフェースや分析を表示するために使用されました。サイト側も連絡を取った（dodopizza.ru）、特定の時間に大量のリクエストが突然到着する可能性があります。

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

多くの場合、コードは必要のないときにデータベースに入力されます。どこかで一括操作が十分でなかったり、速度を上げて信頼性を高めるために、コードを通じて 1 つのリクエストを複数に分割する必要がありました。

コードにおける凝集性と絡み合い

業務の一部を担うはずのモジュールが、それを正直に実行しませんでした。。役割の機能が重複しているものもありました。たとえば、自分の市内のネットワークのマーケティング活動を担当する地元のマーケティング担当者は、「管理者」インターフェイス（プロモーションを設定するため）と「オフィスマネージャー」インターフェイス（プロモーションがビジネスに与える影響を表示するため）の両方を使用する必要がありました。もちろん、内部的には両方のモジュールがボーナスプロモーションに対応する 1 つのサービスを使用していました。

サービス (単一のモノリシックな大規模プロジェクト内のクラス) は相互に呼び出してデータを拡充できます。

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

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

これらは些細な問題のように思えますが、開発の速度が大幅に低下し、品質が低下し、不安定性やバグが発生しました。

大規模開発の複雑さ

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

システムの一部では、これに適したデータベースを使用できる。。例えば、その後、注文カートを保存するために Redis から CosmosDB に切り替える前例がありました。

各分野で働くチームや開発者は、開発と展開の両面で、サービスの自律性を高めたいと明確に望んでいました。マージ中の競合、リリース中の問題。開発者が 5 人であればこの問題は重要ではありませんが、10 人になると、特に計画されている増加に伴い、すべてがより深刻になります。そして、その先にはモバイルアプリケーションの開発（2017年に開始され、2018年には大落下).

システムのさまざまな部分には、異なる安定性指標が必要でした。ただし、システムの接続性が強力であるため、これを保証することはできませんでした。コードは共通かつ再利用可能であり、データベースとデータも同じであるため、管理パネルで新しい機能を開発する際にエラーが発生すると、サイトの注文受付に影響が出る可能性があります。

このようなモノリシックモジュールアーキテクチャのフレームワーク内では、責任の分離、コードとデータベースの両方のリファクタリング、レイヤー間の明確な分離、品質の毎日監視などを行うことで、これらのエラーや問題を回避できる可能性があります。しかし、選択されたアーキテクチャソリューションとシステム機能の急速な拡張に重点が置かれたことで、安定性の面で問題が発生しました。

ブログ「心の力」がレストランのレジを破壊した経緯

ピザチェーン（および荷物）の成長が同じ割合で継続した場合、しばらくすると減少が起こり、システムは上昇しなくなります。次の話は、2015 年までに私たちが直面し始めた問題をよく表しています。

ブログでは「心の力「ネットワーク全体の年間収益データを表示するウィジェットがありました。このウィジェットは、このデータを提供するパブリックDodo APIにアクセスしていました。これらの統計は現在、 http://dodopizzastory.com/。ウィジェットはすべてのページに表示されるため、20 秒ごとにタイマーでリクエストが送信されます。リクエストは api.dodopizza.ru に送信され、次の内容が要求されました。

チェーン内のピザ店の数。
年初からのネットワークの総収益。
今日の収益。

収益統計のリクエストはデータベースに直接送信され、注文に関するデータのリクエスト、即時にデータの集計、合計の発行が開始されました。

レストランのレジ係は同じ注文テーブルに行き、本日受け付けた注文のリストをダウンロードし、そこに新しい注文を追加しました。レジは 5 秒ごとに、またはページが更新されるたびにリクエストを送信しました。

図は次のようになります。

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

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

これは唯一の話ではありません。 2015 年の秋までに、毎週金曜日のシステム負荷は深刻な状態になりました。私たちはパブリック API を何度もオフにしましたが、何も役に立たなくなったため、サイトをオフにしなければならなかったことさえありました。負荷がかかったときにオフにされる順序を記載したサービスのリストもありました。

この時から、負荷との闘いとシステムの安定化に向けた闘いが始まります（2015 年秋から 2018 年秋まで）。その時それが起こったのです。大崩壊その後、時折、非常に敏感な障害も発生しましたが、全般的な不安定な時期は終わったと考えられます。

ビジネスの急速な成長

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

また、2014年から2015年にかけてルーマニアでも開設され、米国でも開設の準備が進められていました。

ネットワークは急速に成長し、新しい国がオープンし、フードコートにピザ屋がオープンするなど、新しいピザ屋の形態が登場しました。これらすべてには、Dodo IS の機能拡張に多大な注意を払う必要がありました。これらすべての機能、つまりキッチンでの追跡、システムでの製品と損失の計算、フードコートでの注文の配達の表示がなければ、「正しい」アーキテクチャや開発への「正しい」アプローチについて議論することはほとんどできないでしょう。

アーキテクチャのタイムリーな改訂、そして一般的に技術的な問題への注意を妨げるもう一つの障害は、2014 年の危機でした。このようなことは、特に Dodo Pizza のような新しいビジネスの場合、チームの成長の可能性を損ないます。

役に立つ簡単な修正

解決する必要のある問題。従来、ソリューションは次の 2 つのグループに分けられます。

火を消し、少しの安全余裕を与え、変更を加える時間を稼いでくれる素早いもの。
全身的であるため、長期間持続します。多数のモジュールを再設計し、モノリシックアーキテクチャを個別のサービスに分割します（そのほとんどはマイクロサービスではなく、マクロサービスであり、これに関する投稿があります。アンドレイ・モレフスキーによる報告).

簡単な変更点のリストは次のとおりです。

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

もちろん、負荷に対処するために最初に行うことは、サーバーの容量を増やすことです。これはマスターベースと Web サーバーに対して実行されました。残念ながら、これは一定の限度までしか不可能です。それ以降は高額になりすぎます。

2014年からAzureに移行しており、当時もこのトピックについて「Dodo Pizza が Microsoft Azure クラウドを活用してピザを配達する方法しかし、一連の値上げにより、基地のサーバーは価格の上限に達しました。

読み取り用の基本レプリカ

ベースのレプリカを 2 つ作成しました。

リードレプリカ 参照クエリ。これは、都市、通り、ピザ屋、製品（ゆっくり変化するドメイン）などのディレクトリの読み取りや、小さな遅延が許容されるインターフェースで使用されます。これらのレプリカは 2 つあり、マスターと同じ方法で可用性を確保しました。

レポートクエリの ReadReplica。このデータベースの可用性は低かったのですが、すべてのレポートがこのデータベースに送信されました。膨大なデータの再計算の要求が多々あるかもしれませんが、少なくともメインのデータベースや操作インターフェースには影響しません。

コード内のキャッシュ

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

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

増加する負荷に対応するために、アプリケーションのバックエンドも拡張する必要がありました。 1 台の IIS サーバーからクラスターを作成する必要がありました。私たちは引っ越しましたアプリケーションセッションメモリから RedisCache に移行し、シンプルなラウンドロビンロードバランサーの背後に複数のサーバーを配置できるようになりました。最初はキャッシュとして同じ Redis が使用されていましたが、その後、複数に分割されました。

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

…しかし、緊張は少し和らぎました。

そして、ロードされたコンポーネントを作り直す必要があり、私たちはそれを引き受けました。これについては次のパートでお話しします。

出所： habr.com

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