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

https://stackoverflow.com/questions/1421764

07-07-2019
|

質問

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

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

最初は、立ち上げ時に、新しい顧客ごとに個別のアプリケーションのインスタンスを展開する必要があります（一度に1つずつオンラインになります）。。メンテナンスが行われる限り、これはあまりうまくスケールしないと思います-変更がロールアウトされるのは非常に退屈で、インスタンスが4つまたは5つ以上あるとエラーが発生しやすくなります。何らかの方法で自動化しない限り。

また、単一インスタンスの哲学は、カスタマイズが必要な場合、多くの分岐点につながる可能性があるようです。そして、それを避けるのがいいでしょう。

では、これについてどのような経験をしましたか？

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

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

スケールの詳細

各顧客には、適切な量のデータがあります-最大数百万件のレコード。

同時ユーザーの数は非常に少なく、顧客ごとに数人しかいません。また、私たちの側には少数の内部担当者がいます。

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

解決

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

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

しかし、先に進まないようにしましょう...私たちはwebappについて話しているのですか？データベースとASPNETを異なるマシンで取得します。データベースをクラスター化すると、さまざまなフロントエンドシナリオで遊ぶのに非常に時間がかかります。また、パフが足りなくなった部分を先に拡大することもできます。

その音によって、1ダースのデータベースマシンではなくても、半分以上のフロントエンドボックスが1つだけのクラスターデータベースが1つになります。

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

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

テストで捕捉されないバグを導入すると、少数のクライアントのみが同時に影響を受けます
ハードウェアは失敗します。 1台のメガサーバーが倒れると、一度に多くの人を困らせます。フェールオーバーメガサーバーを持つことは非常に高価です。実行中の3台または4台のサーバーごとに予備のフェールオーバーボックスを用意すると、ずっと安くなり、煩わしい人が少なくなります。
パフォーマンスはクライアントごとにボックス間でバランスを取ることができるため、重いクライアントでいくつかの軽いクライアントを配置したり、いくつかの中間的なクライアントでボックスを埋めたりすることができます。。
同じ考えで、使用量の急増やその他の速度低下は、同じボックス上のクライアントにのみ影響します。もちろん、これはデータベースで同じことを意味するわけではありませんが、そこに到達したら、クラスターのクラスターに分割できます。

他のヒント

同様の課題に直面した場合、次のようにしました：

複数のSQLサーバーを持つ1つのコードベースがあります。同じコードベースのコピーを使用して、複数のiisサーバーを維持しています。パフォーマンスを最大化するために、クライアントをSQLサーバーからSQLサーバーに自由に移動できます。
顧客が$を持っている場合、私たちはそれらを彼ら自身のサーバーにインストールし、彼らのために別個のiisサーバーを維持します。これは、毎月より多くのお金を支払う（10倍のお金）最大の顧客に対応します。ただし、個別のコードベースは提供しません。 MODが必要な場合は、クライアントごとに表示します（＃3を参照）
カスタムプログラミングは通常、構成可能なオプションになります。独自のサーバーを持つために私たちに支払う人でさえ、同じバージョンのコードを取得します。場合によっては、「顧客が＆quot; ourbigcustomer =このオプションをオンにした場合＆quot;」というコードの節と同じくらい簡単です。はい、それは気難しいハードコーディングですが、顧客が十分なお金を持っている場合、それは私で大丈夫です。
iは、異なる顧客のデータを1つの大きなデータベースに混在させるかどうかという質問からはまったく得られませんでした。私たちのルールは、これを（決して）しないことです。それは私たちがこれまでに行った最も賢明な選択の一つです。データ操作のリスクが大幅に軽減され、データの復元が容易になります。

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

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

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

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

すべてのコードに物理的にアクセスできますおよび変更するデータベースアップデート。
あなたは品質を管理します実行中のハードウェア。
共通コードのバグを修正すると、すべてを一度修正しました顧客。
アプリケーションをリファクタリングできます顧客をより良くサポートする設計特定のコードを作成し、フォークを避けます。
顧客の数が増えるにつれて、あなたはスケールアップおよびスケールアウトできます満たすサーバーパフォーマンス/応答性要件。
アプリケーションコードとデータベースによって改ざんすることはできません「好奇心＆盛」顧客。

アプリケーションが実行されている個別のインスタンスの数とは対照的に、アプリケーションが実行されている場所は、より重要であると言わざるを得ません。

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

Joel Spolskyは、 StackOverflow podcast 67 でもこれについて正確に説明しています。

ジョエルが学んだこと Fogbugzの販売：社内のサーバーにインストールする顧客のサイト、の完全な制御下その顧客は、ほとんど価値がない面倒

2000万件のレコードは、相対的に言えば、巨大なSQL Serverデータベースではありません。適切にプロビジョニングされた単一のSQL Serverでこのサイズを快適に処理できます。ただし、より重要なのは、データベースへの同時アクセスの数です。ただし、顧客ごとに数人のユーザーしかいないため、並行性のレベルが上がるまであなたに打撃を与える可能性は低いと言います。

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

ボーナス質問1：テーブルレイアウト、インデックス作成、読み取り/書き込みの数、ストアドプロシージャの効率と複雑さ（procsまたは少なくとも準備されたステートメントを使用していますか？）はすべて、データベース内の物理レコードをポイントに。さらに、上記で挙げた質問のいくつかに応じて、各顧客または顧客のプールに個別のSQL Serverインスタンスを提供する必要があります。

ボーナス質問2：この状況では、テンプレートとプラグインアーキテクチャの設計に時間を費やすことが不可欠であり、後で行うよりも早く行う必要があります。有料の顧客向けにコードをカスタマイズしようとしたら、おそらくそれを正しく行う時間がないでしょう。この点は十分に強調することはできません。製品のデータ駆動型の変更にすばやく深くアクセスできるテンプレートと管理ツールにより、今後の時間を大幅に節約できます。会社/グループが拡大するにつれて、「製品の専門家」になることができる技術スタッフを減らすことができます。カスタマイズとメンテナンスの90％を実行し、コアを解放して開発を続行したり、他のプロジェクトに移行したりできます。最後に、この計画プロセスでデータ層を無視しないでください。（ほぼ）不変のストアドプロシージャとテーブルのコアデータ層を持つことは非常に重要です。カスタムテーブルとストアドプロシージャは、適切な命名規則を使用して明確に区別されます。

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

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

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

マルチテナントバージョンを作成し、すべてを正常に組み込みました。最終的に、多くのことを把握し、追跡することが多くなりましたが、顧客は新しいシステムに移行したことすら知りませんでした。

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow