Webアプリケーションのサーバー要件を計算する方法

私はモバイルアプリケーションのAPIを公開するバックエンドを開発しています。ユーザーは登録、製品の追加、製品のリンクを電子メール/ SMS /どこでも共有でき、他の人はそれをクリックして製品を購入できます。これは、モバイルアプリケーションの単純なワークフローです。アプリは、画像のアップロードと取得がサードパーティのクラウドサービスによって行われる、画像集約型のアプリです。SO画像部分は私のバックエンドで処理されません。

現在、私は開発チームの出身で、ハードウェアサーバー側の経験はほとんどありません。インフラストラクチャの要件を説明したところ、次の質問がありました。

1. アプリケーション/ストレージスループット
2. アプリケーションのスループット（3か月、6か月、1年の同時接続数）
3. ストレージスループット（3か月、6か月、1年でのデータの増加）
4. HA要件
5. DR要件

上記の3点をどのように予測すればよいかわかりません。スループットはどのように計算されますか？最初の1か月でアプリケーションに10000人のユーザーが登録すると推定されます。そのうち5000人がアクティブユーザーになります。アプリケーションへの平均ログインでは、ユーザーあたり10 APIヒットがあり、これは5000 * 10 = 50,000ヒット/月になります。これは、1分あたり1 APIヒット、つまり最初の月に最大2つの同時接続になります。

計算はこのようになりますか？データの増加をどのように計算しますか？それは、ユーザーが製品を登録、作成し、そのために消費されたデータベースサイズを合計すると、データの増加と呼ばれることになるということですか。

この質問は悲惨に思えるかもしれませんが、サーバーの要件に対してスループットがどのように計算されるかを理解するには、本当に助けが必要です。

最初の3つのポイントは容量計画です。組織は将来のために予算を立て、予測しようとしています。残念ながら、パフォーマンスとスケーラビリティを予測する簡単な方法や受け入れられた方法はありません。アプリケーションと環境はそれぞれ異なります。したがって、これに答える最良の方法は測定することです。

具体的には：

1. ユーザーの成長の可能性と、さまざまなユーザーの種類について、経営者または製品の所有者と話し合ってください。彼らが知らない場合は、推測してください。しかし、これらは推測であることを文書化してください。
2. アプリケーションの一般的なパスの自動実行を作成します。アクティビティを記録したり、JMeterなどの負荷テストアプリケーションに独自のアクティビティを入力したりできます。
3. 現在または予測されているハードウェアに一致するテスト環境を作成します。帯域幅、ストレージ、SSL、ロギング、またはパフォーマンスに影響を与える可能性のあるその他の頻繁に忘れられる要素に細心の注意を払ってください。可能であれば、小さいイメージまたは代表的なイメージを使用して、サードパーティのイメージサービスを模造します。
4. 負荷テストアプリケーションを使用して、さまざまな時点で予測されるユーザー数の提案を作成します。
5. AppDynamicsやDynaTraceなどのアプリケーションパフォーマンス管理ツールを使用して、パフォーマンスを測定し、ボトルネックを特定します。

上記の要件に加えて、これは次のことに役立ちます。

1. ご使用の環境が要求されたロードをサポートしていることを確認してください。
2. 環境がサポートする最大負荷を見つけます。
3. パフォーマンスまたはスケーラビリティを制限するボトルネックを見つけます。
4. さまざまな構成を試して、パフォーマンスまたはスケーリングの方法を確認します。
5. 障害が発生したときにシステムがどのように対処するかを観察します。

最後の2つのポイント、HA要件（高可用性）とDR（災害復旧、おそらくRPO（復旧ポイント目標）とRTO（復旧時間目標））は、実際にはビジネス要件であるため、予測が困難です。管理者または製品の所有者と、起こりうる障害と、それらを軽減または修正するのにかかる費用について話し合います。どちらもこれに慣れていない場合は、多くの推測と深夜を期待してください。

より客観的な根拠を提案します。既存のHTTPログに移動します。これがフィールドアプリの既存の更新であると想定して、ログをプルし、含まれているHTTPリクエストを調べます。これは、風をテストするために空中に濡れた指ではなく、負荷のモデリングに絶対的な客観的な基礎を提供します。

また、QAの観点からも留意してください。要件と検証の両方を所有することはできません。そのため、ログの目的データを使用して、負荷モデルの情報を構築できますが、ビジネスの誰かが実際の定義を承認する必要があります。どうして？これまで開発者、アーキテクト、プラットフォームマネージャーなどが利用できなかった要件をストリームに注入しているため、アプリに障害が発生した場合、背後にあるビジネスで数値が正確であることが必要です。

ログは何をプルできますか？

• 1時間あたりの最高トランザクションレート（1時間ごとにブロックされたリクエスト数）
• 1時間あたりの最大ユーザー数（1時間ごとにブロックされたIPアドレスをカウント）
• ユーザーデータフロー（以前のリクエストのツリーを構築するには、リクエストのリファラータグを参照してください）
• 既存の応答時間（Webサービス呼び出しでw3c所要時間フィールドが有効になっている場合）。これは、現在のモデルをヒットまたは超過するための客観的な基準で将来のリリースの期待を設定するために使用できます
• IPによるリクエスト間の遅延から時間を考えます。リファラータグを取得し、IPアドレスでブロックしてサンプルセットを作成することにより、任意の2つのリクエスト間の時間でサンプルポイントを実際にモデル化できます。次に、これらのサンプルの統計を、最小、最大、平均、90パーセンタイルの思考時間で取得できます。一体、統計パッケージの中には、乱数を挿入して本番環境に適した分布を取得できる関数を提供するものもあります
• 過去の期間のログがある場合は、観測モデルと望ましいモデルの成長モデルを予測できます（販売または予測を使用）

このタイプの作業にはSplunkを使用します。ほとんどの組織では、ELKスタックを使用する場合のように6ダースほどの異なるアプリを一緒にセットアップすることを心配する必要なく、30日分のログを無料枠に取り込むことができるはずです。

要件を間違えると、本番環境では決して発生せず、実際にはリスクを軽減しないエンジニアリングゴーストを追跡している可能性があります。ビジネス側の誰かが要件にサインオフすることを確認してください。そうでない場合は、欠陥のないものを追跡するために予算超過を個別に所有することができます。

私はあなたの質問が本当に好きです。その良いもの。これに対する本当の答えはないと思いますが、私は試みます。新しいサーバーを作成/設計する場合、適切な
環境と方法を選択することが最も重要です。すべての環境がスケーラブルであるわけではなく、ほとんどが限られた方法でのみです。ハードウェアチームが計算しようとしているのは、使用できるファイルシステムとインターフェイスの種類です。一部のファイルシステムはセットアップが簡単ですが、拡張が難しいものです。その他のセットアップは難しいですが、管理と拡張が簡単です。

私の意見で最も良いことは、これらの質問をしている質問者と連絡を取り、なぜ今すぐにこれらに答えることができないのかを説明することです。新しいアプリケーションまたはシステムを起動するとき、特に比較できる他のシステムがない場合、誰もがこれがすべてどのように進化するかを言うことはできません。しかし、あなたはあなたが設計したAPIについての知識を持っており、「ハードウェアマン」は彼の環境/サーバーがどのように機能するかについての知識を持っています。一緒にあなたは確かにこの質問を理解することができます。

これがお役に立てば幸いです。