スケーラビリティについて考え始めるのはいつですか？
私はおかしいけどひどい問題を抱えています。新しい（iPhone）アプリを起動しようとしています。それは私自身のカスタムバックエンドで実行されるターンベースのマルチプレイヤーゲームです。しかし、私は立ち上げることを恐れています。
どういうわけか、それは何か大きなものになるかもしれないと思うし、その人気は私の貧しい孤独な単一サーバー+ MySQLデータベースを殺すと思います。
一方では、それが成長している場合は、準備を整えて、スケーラブルなインフラストラクチャーをすでに準備しているほうがよいと考えています。
一方、私はそれを世界に送り出し、何が起こるかを見たいと思っています。
私は「時期尚早な最適化がすべての悪の根源である」などの記事をよく読んだり、手元のツールを使用して今すぐキラーゲームを構築し、後でスケーラビリティなどの他の項目について心配するべきだと言っています。
これについて、専門家や経験のある人から意見を伺いたい。ありがとう！
それは実際には非常に簡単な選択です。
現在、ユーザーはゼロであり、スケーラビリティは問題ではありません。
理想的には、何百万人ものユーザーがいて、スケーラビリティが問題になるポイントに到達する必要があります。
現時点では、スケーラビリティの問題はありません。ユーザー数の問題があります。スケーラビリティの問題に取り組んでいる場合、ユーザー数の問題を修正することはできません。つまり、まだ持っていない問題を解決し、あなたが抱えている問題を解決していないことになります。最も可能性の高い結果は、あなたの製品がそれを作ることができず、あなたのすべての仕事が無駄になるということです。
ユーザー数の問題に取り組む場合は、今ある問題を解決し、その後次の問題に集中できます。スケーラビリティかもしれません。
スケーラビリティの問題のいいところは、定義上、通常、ビジネスがかなり良いことを意味します。これは、スケーラビリティの最適化にお金を費やす余裕があることを意味します。ユーザー数がゼロから一晩で1,000万人になることはありません。システムのパフォーマンスに目を光らせていれば、時間が来たら最適化するための十分な時間があります。
もちろん、今必要なコードを記述している間、スケーラビリティを念頭に置いておくと役立ちますが、機能がわからない機能に何十、何百もの時間を費やすことはあまり意味がありません。必要になることはほとんどありませんが、最も可能性の高いシナリオは、必要がないということです。 現在、あなたの主な関心事は出荷することです。その後何が起こりますか。まあ、あなたは後でそれについて心配することができます。
最適化が必要であることがわかるまで、最適化する理由はありません。最適化が必要であることをどのようにして知っていますか？あなたが測定します。
サーバーに何らかのWebベースのインターフェースがあると仮定すると、 Apache JMeter などのツールを使用して、多くのユーザーをシミュレートできます。ツールの使用方法を学び、バックエンドのストレステストを開始します。システムにどのような制限があるかを理解するのに十分な知識が必要です。次に、その情報を、所有しているユーザー数および同時に実行している平均数と組み合わせて、いつスケールアップするかを決定できます。
TL; DRコードの最初の行を書く前に、スケーラビリティについて考える必要があります。
まず最初に。スケーラビリティ！=最適化
コードの最初の行を書く前に、スケーラビリティについて考える必要があります。これは、ゲームがヒットする可能性が出てきたときに大きなインフラストラクチャを構築するという意味ではありません。スケーラビリティについて考えることは、次のことを意味します。
- スケールするようにコードが記述されていることを確認します。スケールする必要がないと考えられているプロジェクトがたくさんあります。その結果、コードベースは、投入したハードウェアに関係なく拡張されないか、拡張が非常に高価になります。
- スケーリング戦略を理解します。すべてのユーザーをサポートする方法について計画を立てます。あなたはMySQL dbを持っています、あなたはそれを分割するのですか、それともクラスター、あるいは何か他のものですか？シャーディングのような戦略は、アーキテクチャーに要件を課すため、ある程度の事前検討が必要です。クラスタリング、それほどではありません。セッションをサポートしていますか？セッションは複数のフロントエンドサーバーとどのように反応しますか？ロードバランサーでスティッキーセッションが必要ですか？.
- 実装戦略を考え出す。 AWSを使用してスケーリングしますか？すぐに使用できる動的なスケーリングを可能にする製品やサービスを活用できますか？これには、コストの理解も含まれます。
[〜＃〜] but [〜＃〜]すでにコードベースを持っているようです。ここで問題になるのは、いつスケーリングを開始するかです。これはコードに完全に依存しています。
コードがスケーリングに適している場合次に、難しい部分を実行します。 AWSアカウントを取得し、必要に応じてサーバーを起動して、離れて行くことができます。
コードがスケーリングしない、またはボトルネックがある場合次に、実行する作業があります。ボトルネックを特定して修正する必要があります。 「いつ」を知るのは本当に難しい。一部のサービスは停滞し、一部は着実に上昇し、一部は爆発しました。スケーリングなどでリソースをいつ投入するかを決定することは、通常、ビジネスの機能であり、リスクの評価です。
あなたの立場で、私は「ベータ版」としてリリースし、ユーザーの期待を管理するかもしれません。そうすれば、製品を取り出して、どのように展開するかを確認できます。
したがって、スケーラビリティについて考える必要があるのは2回あります。
まず、1行のコードを書く前に、そっと熟考する必要があります。これは、スケーラビリティホールに自分を書き込まないようにするためと、2回目に必要な測定値を提供するようにコードが実装されていることを確認するためです。
スケーラビリティを検討する2番目の時間は、物事の進歩が許容できないほど遅くなるのに十分です。つまり、「遅すぎる」の意味と、負荷がかかったときの反応を知る必要があります。ドライバー（おそらくqps）が1か月あたりN％増加するサービスがある場合、リソース使用量が負荷の二乗または負荷の線形であると、「消費されるマシンリソースの95％」とはかなり異なる時間になります。
ターンベースのゲームでは、適切な安全マージンを確保する必要があります（おそらく、単一のゲームワールドがなく、そうした場合、おそらく内部ジオメトリが存在します。ターン」の問題）。
詳細がわからなければ、スケーリングの問題がどこにあるのか、そしてそれらを解決するためにどのような戦略があるのかを考えるのに1日か2日かかります。しかし、これは重要です。考えないでください（そして文書化してください）。数百のユーザーで顕在化するスケーラビリティの問題がない限り、負荷を確認してより多くのバックエンドリソースを起動する時間があります。
あなたの説明から、2つの可能な結果があるように聞こえます：
- ゲームは失敗であり、あなたは気にしません。
- ゲームは成功し、バックエンドは負荷を処理できなくなり、結果は失敗になります。
うーん。
あなた自身に尋ねるいくつかの質問があります：
- 現在のバックエンドは、許容可能なパフォーマンスで何人のユーザーを処理できますか？
- なんらかの急成長が見られる場合（たとえば、一時的にゲームをアプリストアからプルするなど）、現在のユーザーへの影響を制限するための何らかの計画はありますか？
- 成功した場合、どれだけ早くバックエンドを改善できるでしょうか？
- 待つことのビジネスへの影響は何ですか。自分を養うことができますか？リスクは何ですか？
- 上記の質問に対する答えを与えられた今リリースすることのビジネスへの影響は何ですか？.
これらを検討すると、質問への回答が明らかになるはずです。すべてのシステムが異なり、すべてのビジネスが異なるので、専門家は詳細情報なしでは何をすべきかをあなたに教えることができません。
サーバーはユーザーがインタラクティブに使用します。つまり、レイテンシがユーザーエクスペリエンスに非常に大きな影響を与えています。レイテンシが悪いと、常にユーザーエクスペリエンスが低下します。
少なくとも、Bryanが説明しているように、アドホックロードテストを実行します。
より深刻なアプローチ
いくつかのシミュレーションを実行し、ユーザー体験に対してレイテンシーが何を行うかを調べます（ネットワーク遅延シミュレーションを使用するか、アプリケーション内で単にsleep（）を使用します）。レイテンシが目立ち、煩わしくなり、使用できなくなる原因を調べます。
次に、最適化の方向への最初のステップになります。サーバーのSLA=を決定します。例：最悪の場合、迷惑なレイテンシのある10％の呼び出しと使用できないレイテンシのある1％の呼び出し。これらの制限により、負荷テストを使用して、ユーザー数を調べることができます。サーバーがサポートできます。
レイテンシを測定せずに（または少なくとも負荷テスト中にサーバーを手動で使用して）純粋なスループットテストは、測定されたスループット数が耐えられるユーザーエクスペリエンスをもたらすかどうかを通知しないため、それほど役に立ちません。
Gil Teneによるレイテンシの測定に関する非常に素晴らしいプレゼンテーション： http://www.infoq.com/presentations/latency-pitfalls
ビジネス要件の段階で、アーキテクチャ、運用、開発、QA、製品の監視など、下流のすべての要素のパフォーマンスに関する共通の理解を確立するために使用されます。事前に何が必要であるかについて共通の理解を確立していない場合、組織のライフサイクル全体で特定のタスクに従事するときに、組織の各部分がパフォーマンスについて仮定する（またはそれらについてまったく考えない）ことになります。応用。これは、あなたがウォーターフォール、ショートウォーターフォール、アジャイルに従事している場合でも、その時点の開発方法論が、履歴書キーワードリストで注目されている場合でも当てはまります。
パフォーマンスとスケーラビリティは難しいです。機能は簡単です。不十分なスケーリングコードは、提供するすべてのリソースプールを埋めるために大きくなるため、より大きなハードウェアを購入してコストバブルをシフトすることは、非効率的なコードを修正するか、これまで以上にハードウェアを購入する必要がある前にしかかかりません。これを優先して継続させることも非常にコストがかかります。アプリケーションのライフサイクルの早い段階で行われるアーキテクチャと設計の決定には、パフォーマンスに関連する遅れて到着する要件を満たすために完全に逆にする必要がある場合があります-高性能のスポーツカーメーカーがアルミニウムから設計サイクルの後半で炭素繊維を使用して、パフォーマンスに関連する出力/重量比を達成し、これが工具、トレーニング、自動車の構造などにどのように影響するか...
組織のアーキテクト、開発者、運用担当者に、アプリケーションのパフォーマンス要件を尋ねます。これらがビジネスから取得されない場合でも、同じグループ内であっても、異なる個人から異なる回答（または回答なし）を受け取っても驚かないでください。これらの「前提条件」は、常に組織の展開に影響を与えます。