スケーラビリティについて考え始めるのはいつですか？[閉まっている]

面白いけどひどい問題があります。新しい（iPhone）アプリを起動しようとしています。これは、自分のカスタムバックエンドで実行されるターンベースのマルチプレイヤーゲームです。しかし、私は立ち上げることを恐れています。

どういうわけか、私はそれが何か大きなものになるかもしれないと思います、そしてその人気は私の貧しい孤独な単一サーバー+ MySQLデータベースを殺すと思います。

一方では、それが成長している場合は、準備を整えて、スケーラブルなインフラストラクチャーをすでに準備しているほうがよいと考えています。

一方、私はそれを世界に送り出し、何が起こるかを見たいと思っています。

私は「時期尚早な最適化がすべての悪の根源である」などの記事をよく読んだり、ツールを手元に置いて今すぐキラーゲームを構築し、後でスケーラビリティなどの他のことについて心配するべきだと言っています。

私はこれについて専門家やこれを経験した人からこれについていくつかの意見を聞きたいです。ありがとう！

それは実際には非常に簡単な選択です。

現在、ユーザーはゼロであり、スケーラビリティは問題ではありません。

理想的には、何百万人ものユーザーがいて、スケーラビリティが問題になるポイントに到達したいと考えています。

現時点では、スケーラビリティの問題はありません。ユーザー数の問題があります。スケーラビリティの問題に取り組んでいる場合、ユーザー数の問題を修正することはできません。つまり、まだ持っていない問題を解決し、あなたが抱えている問題を解決していないことになります。最も可能性の高い結果は、あなたの製品がうまくいかず、すべての作業が無駄になるということです。

あなたはユーザ数の問題に取り組む場合は、あなたが今持っている問題を解決し、その後、あなたは、スケーラビリティかもしれない次の問題に焦点を当てることができます。

スケーラビリティの問題の良い点は、当然のことながら、それらを定義することは通常、ビジネスがかなり良いことを意味し、これは、スケーラビリティの最適化にお金を費やす余裕があることを意味します。ユーザー数がゼロから一晩で1,000万人に達することはありません。システムのパフォーマンスを監視している場合は、時間が来たら最適化するための十分な時間があります。

もちろん、今必要なコードを記述する際にスケーラビリティを念頭に置いておくと役立ちますが、機能がわからない機能に数十時間から数百時間もの時間を費やすことはあまり意味がありません。 「それが必要になるだろう、そして最もありそうなシナリオはあなたがそうしないということです。現在、あなたの主な関心事は出荷することです。その後何が起こるか まあ、あなたは後でそれについて心配することができます。

最適化が必要であることがわかるまで、最適化する理由はありません。どのようにして最適化が必要であるとわかりますか？あなたが測定します。

サーバーに何らかのWebベースのインターフェースがあると仮定すると、Apache JMeterなどのツールを使用して、多くのユーザーをシミュレートできます。ツールの使用方法を学び、バックエンドのストレステストを開始します。あなたはあなたのシステムにどのような制限があるかを知るために十分に学ぶことができるはずです。次に、その情報を、所有しているユーザー数および一度に実行している平均数と組み合わせて、いつスケールアップするかを決定できます。

TL; DRコードの最初の行を書く前に、スケーラビリティについて考える必要があります。

まず最初に。スケーラビリティ！=最適化

コードの最初の行を書く前に、スケーラビリティについて考える必要があります。これは、ゲームがヒットする可能性が高いときに、大規模なインフラストラクチャを構築するという意味ではありません。スケーラビリティについて考えることは、次のことを意味します。

• スケーリングできるようにコードが記述されていることを確認します。 規模を拡大する必要性が考慮されていないプロジェクトがたくさんあります。結果は、投じたハードウェアに関係なく拡張できないコードベースであるか、拡張が非常に高価です。
• スケーリング戦略を理解します。 すべてのユーザーをサポートする方法について計画を立てます。あなたはMySQL dbを持っています、それを分割するのか、それともクラスターにするのか、それとも何か他のものですか。シャーディングのような戦略は、アーキテクチャーに要件を課すため、事前の検討が必要です。クラスタリング、それほどではありません。セッションをサポートしていますか？セッションは複数のフロントエンドサーバーとどのように反応しますか？ロードバランサーでスティッキーセッションが必要ですか？
• 実装戦略を把握します。 AWSを使用してスケーリングしますか？すぐに使用できる動的なスケーリングを可能にする製品やサービスを活用できますか？これには、コストの理解も含まれます。

しかし、すでにコードベースを持っているようです。ここで問題になるのは、いつスケーリングを開始するかです。これはコードに完全に依存しています。

コードがスケーリングに適している場合は、難しい部分は完了しています。AWSアカウントを取得し、必要に応じてサーバーを起動して、離れて行くことができます。

コードがスケーリングしない、またはボトルネックがある場合は、やらなければならない作業があります。ボトルネックを特定して修正する必要があります。「いつ」を知るのは本当に難しい。一部のサービスは停滞し、一部は着実に上昇し、一部は爆発しました。スケーリングなどでリソースを投入するタイミングを決定することは、通常、ビジネスの機能であり、リスクの評価です。

あなたの立場では、私は「ベータ版」としてリリースし、ユーザーの期待を管理するかもしれません。そうすれば、製品を取り出して、どのように展開するかを確認できます。

したがって、スケーラビリティについて2度考えなければなりません。

まず、1行のコードを書く前に、そっと熟考する必要があります。これは、スケーラビリティホールに自分を書き込まないようにするためと、2回目に必要な測定値を提供するようにコードが実装されていることを確認するためです。

スケーラビリティを検討する2番目の時間は、物事の進歩が許容できないほど遅くなるのに十分です。つまり、「遅すぎる」の意味と、負荷がかかったときにどう反応するかを知る必要があります。ドライバー（おそらくqps）が1か月あたりN％増加するサービスがある場合、リソース使用量が負荷の2乗または負荷の線形であると、「消費されるマシンリソースの95％」とはかなり異なる時間になります。

ターンベースのゲームでは、適切な安全マージンを確保する必要があります（おそらく単一のゲームワールドがなく、その場合、おそらく内部ジオメトリがあります。つまり、「誰もがすべての人と相互作用することはできません。ターン」の問題）。

詳細がわからなければ、スケーリングの問題がどこにあるのか、そしてそれらを解決するためにどのような戦略があるのか​​を考えるのに1日か2日かかります。しかし、これは重要です。考えないでください（そして文書化してください）。数百のユーザーで顕在化するスケーラビリティの問題がない限り、負荷を確認してより多くのバックエンドリソースを起動する時間があります。

あなたの説明から、2つの可能な結果があるように聞こえます：

• ゲームは失敗であり、あなたは気にしません。
• ゲームは成功し、バックエンドは負荷を処理できなくなり、結果は失敗になります。

うーん。

ここにあなた自身に尋ねるいくつかの質問があります：

• 現在のバックエンドは、許容可能なパフォーマンスで何人のユーザーを処理できますか？
• なんらかの急速な成長が見られる場合（たとえば、一時的にゲームをアプリストアからプルするなど）に、現在のユーザーへの影響を制限する何らかの計画がありますか？
• あなたが成功した場合、どれくらい早くあなたはより良いバックエンドを思いつくことができますか？
• 待つことのビジネスへの影響は何ですか。あなたは自分自身を養うことができますか？リスクは何ですか？
• 上記の質問に対する答えを与えられた今リリースすることのビジネスへの影響は何ですか？

これらを検討すると、質問への回答が明らかになります。すべてのシステムが異なり、すべてのビジネスが異なるので、専門家は詳細情報なしでは何をすべきかをあなたに教えることができません。

サーバーはユーザーがインタラクティブに使用します。これは、待ち時間がユーザーエクスペリエンスに非常に大きな影響を与えていることを意味します。レイテンシが悪いと、常にユーザーエクスペリエンスが低下します。

少なくとも、Bryanが記述したアドホックロードテストを実行します。

より深刻なアプローチ

いくつかのシミュレーションを実行し、ユーザー体験に対してレイテンシーが何を行うかを調べます（アプリケーション内でネットワーク遅延シミュレーションを使用するか、sleep（）を使用します）。レイテンシが気になり、煩わしくなり、使用できなくなる原因を調べます。

次に、最適化の方向への最初のステップになります。サーバーのSLAを決定します。たとえば、最悪の場合、迷惑なレイテンシで10％の呼び出し、使用できないレイテンシで1％の呼び出し。これらの制限により、負荷テストを使用して、サーバーがサポートできるユーザー数を確認できます。

レイテンシを測定せずに（または少なくとも負荷テスト中にサーバーを手動で使用して）純粋なスループットテストは、測定されたスループット数が耐えられるユーザーエクスペリエンスをもたらすかどうかを通知しないため、それほど役に立ちません。

Gil Teneによるレイテンシの測定に関する非常に素晴らしいプレゼンテーション：http : //www.infoq.com/presentations/latency-pitfalls

ビジネス要件の段階で、アーキテクチャ、運用、開発、QA、製品の監視など、下流のすべての要素のパフォーマンスに関する共通の理解を確立するために使用されます。事前に何が必要であるかについて共通の理解を確立していない場合、組織のライフサイクル全体で特定のタスクに従事する際に、組織の各部分がパフォーマンスについて仮定する（またはそれらについてまったく考えない）ことになります。応用。これは、あなたがウォーターフォール、ショートウォーターフォール、アジャイルなど、レジュメキーワードリストで注目されている開発方法論に関係なく当てはまります。

パフォーマンスとスケーラビリティは困難です。機能は簡単です。不十分なスケーリングコードは、提供するすべてのリソースプールを埋めるために大きくなるため、より大きなハードウェアを購入してコストバブルをシフトすることは、非効率的なコードを修正するか、これまで以上にハードウェアを購入する必要がある前にしかかかりません。これを優先して継続させることも非常にコストがかかります。アプリケーションのライフサイクルの早い段階で行われるアーキテクチャと設計の決定がありますが、パフォーマンスに関連する遅れて到着する要件を満たすために完全に逆にする必要がある場合があります-高性能のスポーツカーメーカーがアルミニウムから炭素繊維は、設計サイクルの後半で、パフォーマンスに関連する出力/重量比を達成し、これが工具、トレーニング、車の構造などにどのように影響するかを示します。

組織のアーキテクト、開発者、運用担当者に、アプリケーションのパフォーマンス要件を尋ねます。これらがビジネスから取得されない場合でも、同じグループ内であっても、異なる個人から異なる回答（または回答なし）を受け取っても驚かないでください。これらの「前提条件」は、常に組織の展開に影響を与えます。