環境を再現できない場合のテストと最適化の方法は？

過去には、さまざまな環境で働いてきました。デスクトップアプリ、ゲーム、埋め込みコンテンツ、Webサービス、コマンドラインジョブ、Webサイト、データベースレポートなど。これらの環境はすべて同じ特徴を共有しました。複雑さやサイズに関係なく、テストするマシンまたは開発環境でアプリケーションのサブセットまたはスライスを常に保持できました。

今日はしません。今日私は、スケーラビリティに主眼を置いている環境にいることに気づきました。環境を再現することは法外に費用がかかります。環境の一部を取りますが、もっともらしい（一部のピースはシミュレートする必要があるか、実行しないようにシングルインスタンスモードで使用する必要があります）が、同時実行性とロードを不明瞭にするため、目的を無効にします実際のシステムが遭遇します。小さな「テスト」システムにも欠陥があります。2つのノードがある場合と64のノードがある場合は、動作が異なります。

最適化への私の通常のアプローチ（測定、何かを試す、正しさを検証する、違いを測定する、繰り返す）は、重要な問題の部分（同時実行性の堅牢性とパフォーマンスの下で効果的にステップ2と3を実行できないため、ここでは実際に機能しません負荷）。ただし、このシナリオはユニークではないようです。この種の環境でこの種のタスクを行うための一般的なアプローチは何ですか？

関連する質問がいくつかあります。

• この質問は、ハードウェア（スペクトルアナライザーなど）が利用できないことに関するものであり、（比較的）簡単にエミュレートできます。
• この質問は、実稼働環境にのみ存在するバグを追跡することに関するものです。これは役に立ちますが、異なる種類のアクティビティです。

実際には難しいですが、多くの比較可能な状況では、それは主に組織的な問題であると確信しています。唯一の実行可能なアプローチは、おそらく「1つの特効薬」ではなく、組み合わせた手段の混合物です。あなたが試すことができるいくつかのこと：

• ロギング：すでにコメントで書いたように、過剰な時間とリソースのロギング（プロファイリングの一種）は、本番環境での実際のボトルネックを特定するのに役立ちます。これは、代替の実装がより適切に機能するかどうかを教えてくれないかもしれませんが、アプリケーションの完全に間違った部分の最適化を回避するのに役立つでしょう。

• 事前にテストできるものをテストします-事前に多くの計画を立てて徹底的に。確かに、物事は本番では異なる動作をしますが、すべてではありません。多くの場合、異なる実装の正確性は事前に確認できます-実装の規模が適切であれば、別の質問になります。しかし、計画は大いに役立ちます。テスト環境で解決できる問題と、そうでない問題について真剣に考えてください。「事前にテストすることはできません」と一見しただけで信じていることはほとんど常にありますが、よく考えてみると、より多くの可能性があります。

• チームとして働く。新しいアプローチやアイデアを試すときは、チームの他の1人以上と話し合ってください。別のアルゴリズムを実装するときは、コード検査とQAを主張します。事前に回避できるバグや問題が多いほど、本番環境で解決する必要のある深刻な問題は少なくなります。

• 事前にすべてをテストすることはできないため、本番環境で問題が発生することを期待してください。したがって、新しいコードを本番環境に導入する際には、本当に優れたフォールバック戦略を準備してください。新しいコードが古いソリューションよりも動作が遅いリスクがある場合、またはクラッシュするリスクがある場合は、できるだけ早く前のバージョンに変更できることを確認してください。実稼働データを破壊するリスクがある場合は、適切なバックアップ/リカバリを用意してください。また、システムに検証メカニズムを追加して、このような障害を必ず検出してください。

• プロジェクトの日記またはソリューションログを保存する-真剣に。毎日、環境について何か新しいことを見つけて、それを書き留めてください-成功事例と失敗事例。同じ失敗を2回繰り返さないでください。

その要点は、試行錯誤を繰り返すことができない場合の最善の選択肢は、保守的な古典的な事前計画とQAテクニックです。

ライブ環境を再現できない場合、不快な現実は、何をするにしても、十分にテストされていないことです。

だから、あなたは何ができますか？

スケールする必要があるものは何でも、プロセス、サーバークラスター、またはデータベースボリュームは、潜在的なボトルネック/制限がIO、CPU、CPU負荷、インターである場所を特定するために、ゼロ、1、無限のルールを念頭に置いてテストする必要があります-プロセス通信など

これを取得したら、どのようなテストが影響を受けるかを把握する必要があります。単体テストの場合、これは伝統的に開発者の立場にあります。統合/システムテストの場合、他のチームとのタッチポイントがあり、追加の専門知識やツールの改善を支援できる場合があります。

ツールといえば、開発環境で可能なことを超えてシステムをロードテストすることは、実際には開発者の権限ではありません。これは、テスト部門または他のサードパーティにプッシュする必要があります。

もちろん、部屋の象は、システムが常に予測可能な方法で拡大縮小するとは限らないということです！

以前は、数十億行の銀行データベースのDBAであり、入力ボリュームが与えられたアイドルデータベースでクエリがどのくらいの時間かかるかを一般的に予測できる実行計画を備えていました。ただし、これらのボリュームが特定のサイズに達すると、クエリ/データベースが調整されない限り、実行計画が変更され、パフォーマンスが急速に低下します。

実験をお勧めします。

ロギングはボトルネックを見つけます。その後、一部のマシンで、または一定の確率で、または限られた期間で、すべてのマシンで代替実装を試すことができます。次に、ログを再度比較して、改善を確認します。

理論と実験と測定のサイクルは以前と同じですが、本番環境で仮説を実行する必要があるため、セットアップに費用がかかります。また、量によっては、本番環境からの重要なデータの受信も遅くなる場合があります。