asp.net - アプリの1つの大規模なインスタンスですか、それとも多くの中規模のインスタンスですか？

Question

私たちが作成した1人の顧客向けのWebアプリケーションは、製品化されて数十社に販売され、ホスティングを行います。

単一の（または非常に少数の）マルチテナントインスタンスを使用するのではなく、顧客ごとに個別のインスタンスを展開することの長所と短所に関するガイダンスを使用できます。

最初は、立ち上げるときに、新しい顧客ごとにアプリケーションの個別のインスタンスを展開する必要があります（一度に1つずつオンラインになります）。これが唯一の即時オプションだからです。メンテナンスに関しては、これはあまり拡張できないと思います。4つまたは5つを超えるインスタンスが存在すると、変更の展開は非常に面倒になり、エラーが発生しやすくなります。どういうわけかそれを自動化しない限り。

また、単一インスタンスの哲学は、人々がカスタマイズを必要とする場合、それがフォークの束につながる可能性があるようです。そして、それを避けるのはいいことです。

それで、これであなたの経験は何でしたか？

ボーナス質問＃1：それぞれ2mのレコードを持つ10台のSQL Serverと、20mの巨大な1台のSQL Serverのパフォーマンスの違いは何ですか？それらがすべて1つのテーブルにあり、主に単一のレコードに対して挿入と選択を行っているとします。選択は、インデックス付きのvarchar（12）または日付フィールドにある場合があります。

ボーナス質問＃2：フォークを回避するには、カスタマイズを構成可能にするか、プラグインアーキテクチャを構築する必要があると思います。ただし、それによってカスタマイズのコストが増える可能性があります。テキストボックスのサイズを変更するのに1週間かかるようなショップにはなりたくありません。また、インフラストラクチャに過剰な投資をしたくありません。それについて何か考えはありますか？

スケールの詳細

各顧客は、最大数百万のレコードまで、かなりの量のデータを持っています。

同時ユーザーの数は非常に少なく、顧客ごとに数人しかいません。さらに、社内の担当者も数人います。

各顧客がカスタマイズを必要とするかどうかは不明ですが、おそらく一部の顧客はカスタマイズを必要とし、おそらくそれらの変更の一部は他の顧客が見たくないものになるでしょう。

Answer 1

同様の課題に直面したとき、私たちがしたことは次のとおりです。

1. 複数のSQLサーバーを備えた1つのコードベースがあります。同じコードベースのコピーを使用して複数のIISサーバーを維持しています。パフォーマンスを最大化するために、クライアントをSQLサーバーからSQLサーバーに自由に移動できます。

2. 顧客がそのための$を持っている場合、私たちはそれらを自分のサーバーにインストールし、それらのために別のiisサーバーを維持します。これは、毎月はるかに多くのお金を払っている最大の顧客に対応します（10倍のお金）。ただし、個別のコードベースは提供していません。modが必要な場合は、クライアントごとに表示します（＃3を参照）

3. カスタムプログラミングは通常、構成可能なオプションになります。自分のサーバーを所有するために私たちにお金を払っている人でさえ、同じバージョンのコードを入手します。「顧客が「ourbigcustomerならこのオプションをオンにする」というコードの句のように単純な場合もあります。はい、それは厄介なハードコーディングですが、顧客が十分なお金を持っている場合は、それで問題ありません。

4. さまざまな顧客のデータを1つの大きなデータベースに混合したいかどうかという質問からは、まったくわかりませんでした。私たちのルールは、決してそうしないことです（決して）。これは、私たちがこれまでに行った中で最も賢明な選択の1つです。これにより、データ操作のリスクが大幅に軽減され、データの復元が容易になります。

Answer 2

私はあなたの2つの選択肢のどちらにも正当な理由がわかりません。本当の答えは真ん中のどこかにあると思います。複数のインスタンスがあり、それぞれが複数のクライアントをホストしています。

これにより、自動化処理の別のレイヤーが追加されますが、ホスティングを安価に保つことができ（すぐに外出してCrayを購入する必要はありません）、（うまくいけば）この種の考え方はフェイルオーバーバックアップをかなり簡単に実行できることを意味します。

しかし、先を行くのはやめましょう...私たちはWebアプリについて話しているのですよね？データベースとaspnetを別のマシンで取得します。データベースをクラスター化すると、さまざまなフロントエンドシナリオを試してみることができます。また、最初にパフが不足した領域をアップスケールすることもできます。

その音によると、完全な12台のデータベースマシンと2、3のフロントエンドボックスだけではないにしても、半分以上の1つのクラスター化されたデータベースになります。

カスタマイズに関しては、あなたはそれを釘付けにしました。完全にデータベースでホストされる編集可能なテンプレートのセットを提供するか、whoインスタンスをカスタマイズする必要があります。私はすべて最初です。これは多くの作業ですが（見返りはあまりありません）、アップグレードを行うときにコアコードを変更するだけでよいので、それだけの価値があります。100人の顧客のカスタムインスタンスを探して、安全にアップグレードできることを確認すると、開発者が殺されます。テンプレートがその答えです。少なくとも、苦労せずにカスタムCSSを許可することができます（ただし、自分のことを知っている人が必要です）。

編集：オールインワン方式の投稿をいくつか見てきました。インスタンスを複数のマシンに分割することで、いくつかのことからあなたを隔離します。

• テストで検出されなかったバグを導入した場合、一度に影響を受けるのは少数のクライアントのみです。

• ハードウェアに障害が発生します。1台のメガサーバーが倒れると、一度に多くの人が迷惑になります。フェイルオーバーメガサーバーを使用すると、非常にコストがかかります。実行中のサーバー3台または4台ごとに予備のフェイルオーバーボックスを用意する方がはるかに安価で、煩わしい人も少なくなります。

• クライアントごとにボックス間でパフォーマンスのバランスをとることができるため、使用頻度の低いクライアントと使用頻度の高いクライアントをいくつか配置したり、使用頻度の低いクライアントをいくつか使用したりすることができます。

• 同じ考えで、使用量の急増やその他の減速は、同じボックスのクライアントにのみ影響します。もちろん、これはデータベースにとって同じことを意味するわけではありませんが、そこに到達したときにクラスターのクラスターに分割することができます。

Answer 3

個々のインスタンスの大きな利点は、各顧客の需要が増えるにつれてスケールアウトすることです。たとえば、単一のサーバーで実行していて、1人の顧客が突然、より多くのパフォーマンスを必要とする場合、あなたは詰め込まれます。しかし、全員が個人である場合、その顧客を光沢のある新しいサーバーに移動するのは比較的簡単です。

大きな欠点は、インスタンスをすべて個別に管理することです。（すべてが同じサーバーで実行されているかどうかに関係なく）。

とにかく、コードベースのインスタンスは1つだけにする必要があります。また、カスタマイズはすべてプラグインと構成を介して制御する必要があります。フロントエンドは当然コンテンツから分離する必要があります。変更を加えるコストは高くなる可能性がありますが、他の顧客に提供できる機能（これはあなたが行うように求められたカスタマイズにすぎません）の面でのメリットはきっと報われるでしょう。これは、複数のコードベースとは対照的に、単一のコードベースの管理がどれほど簡単になるかについては言うまでもありません。

Answer 4

あなたの会社がホストする単一のインスタンスを使用することを強くお勧めします。これには次の利点があります。

• すべてのコードとデータベースに物理的にアクセスして、変更や更新を行うことができます。
• 実行しているハードウェアの品質を制御します。
• 共通コードのバグを修正すると、すべての顧客に対して1回修正されます。
• アプリケーション設計をリファクタリングして、顧客固有のコードをより適切にサポートし、フォークを回避できます。
• 顧客の数が増えるにつれて、サーバーをスケールアップおよびスケールアウトして、パフォーマンス/応答性の要件を満たすことができます。
• アプリケーションコードとデータベースは、「好奇心旺盛な」顧客によって改ざんされることはありません。

個別のインスタンスがいくつあるかではなく、アプリケーションが実行されている場所の方がほとんど重要であると言わざるを得ません。

確かに、複数の個別のインスタンスを維持することは、サポート/メンテナンスのオーバーヘッドのために理想的ではありませんが、これらのアプリの場合。すべてが制御するサーバー上にあるため、さまざまな顧客のネットワークやサーバーへのリモート/物理アクセスが必要になるよりもはるかに簡単です。

Joel Spolskyは、 StackOverflowポッドキャスト67でもこれについて正確に語っています。

JoelがFogbugzの販売から学んだことの1つは、顧客のサイトの社内サーバーにインストールされ、その顧客を完全に制御できるように設計されたソフトウェアは、面倒な価値がほとんどないということです。

比較的言えば、2,000万件のレコードは巨大なSQLServerデータベースではありません。適切にプロビジョニングされた単一のSQLServerは、このサイズを快適に処理できます。ただし、より重要なのは、データベースへの同時アクセスの数です。ただし、顧客あたりのユーザー数はわずかであるため、同時実行性のレベルが上がるまで、ユーザーに影響を与える可能性は低いとおっしゃっています。

Answer 5

上記のすべてが良い点ですが、2つの重要な質問が欠けています。サービスはどのような価格で提供され、最終的に何人の顧客（桁違い）をサポートする必要がありますか（つまり、市場規模）？3年間で、最大10人の顧客がいて、それぞれが年間500,000ドルを支払うのでしょうか、それとも500人の顧客が年間10,000ドルを支払うのでしょうか。高額のプレミアム顧客の少数のセットにとって、個々の展開の利点は明らかですが、低価格と大規模な顧客ベースは、共有ソリューション（アラオリのコメント）を要求するのが最善の方法です。または、クラウドプラットフォームを使用しますが、私は誇大広告を読んで、それを現場に展開するのではなく、いじくり回しました。

ボーナス質問1：テーブルのレイアウト、インデックス作成、読み取り/書き込みの数、ストアドプロシージャの効率と複雑さ（procまたは少なくともプリペアドステートメントを使用していますか？）はすべて、物理レコードの数よりもはるかに重要です。ある時点までのデータベース。それを超えると、上記で提起したいくつかの質問に応じて、顧客ごとまたは顧客のプールごとに個別のSQLServerインスタンスを提供する必要があることに気付くでしょう。

ボーナス質問2：この状況では、テンプレート作成とプラグインアーキテクチャに時間をかけることが不可欠であり、後でではなく早く行う必要があります。有料の顧客向けにコードをカスタマイズする作業に取り掛かると、それを正しく行う時間がなくなる可能性があります。この点は十分に強調することはできません。製品のデータ駆動型の変更にすばやく深くアクセスできるテンプレートと管理ツールを使用すると、将来の時間を大幅に節約できます。会社/グループが拡大するにつれて、カスタマイズとメンテナンスの90％を実行できる「製品エキスパート」となる技術スタッフを減らすことができ、コアを解放して開発を継続したり、他のプロジェクトに進んだりできます。最後に、この計画プロセスではデータ層を無視しないでください。

より具体的な提案が必要な場合は、幸運を祈ります。詳細をお知らせください。

Answer 6

ここで受け取ったアドバイスのいくつかに基づいて、アプリケーションのモノリシックマルチテナントバージョンを実装することになりました。

よかったです。それが完了するまでに、コードベースのフォークが3つまたは4つあり（主にカスタムスキンとnレベルのサポートがなかったものだけでなく、実際の機能もいくつかありました）、それはますますクレイジーになりました。

マルチテナントバージョンを立ち上げ、すべてをうまく折りたたむことができました。考えるべきことがたくさんあり、追跡することがたくさんありましたが、お客様は新しいシステムに移行したことすら知りませんでした。

実際の顧客の移行は少し負担でした。最初はバックエンドで手動で実行できると思っていましたが、作業を完了するためにかなり複雑なスクリプトを作成する必要がありました。ID列が多すぎたため、本番システムにインポートするときに一時的に制約をオフにできるわけではありません。