将来に向けて大幅に拡張するためにプラットフォームを準備するにはどうすればよいですか？

Question

序文

現在、非常に小規模なプラットフォームを構築しており、来月中にはここで試作段階に移行する予定です。

今のところ、それは単なるWebアプリケーションです。次のようなものが含まれています。

ユーザー/プロファイル
コメントシステム
ユーザーが作成した投稿

驚くほど複雑なものはありません。でも、作品にはもっと多くの機能があります。といった：

サブスクリプション/支払い処理
二要素認証
自動化された電子メールとテキストメッセージ
モバイルアプリ

私のセットアップ

3つのメインサーバーがあります。

データベース：分離されたSQLサーバーはAPIサーバーからのみアクセスできます。プラットフォームに関連するすべての永続データが含まれます。
API： Go データベースサーバーへの間接アクセスを提供し、認証とトークンを管理するサーバー。
HTTPS：静的コンテンツを提供するためのNginxと動的コンテンツを管理するための別の Go サーバー。 APIサーバーと頻繁に通信します。

また、DNS管理、SSL証明書、およびDDoS保護に CloudFlare を使用しています。

APIサーバーを持つという考えは、モバイルアプリのシステムへの統合を容易にすることです。

分析

特にプロジェクトの機能に特に焦点を当てているわけではありませんが、プロジェクトを拡張する際に焦点を当てるべきであるプラクティスについては特にそうです。トラフィックの量が多いことが、現在の設定を損なう可能性のある主な問題になると思います。

静的コンテンツと動的コンテンツを提供するサーバーが1つしかないため、ますます多くのリクエスト（そしておそらく世界の他の場所からのリクエストさえ）を受け取るようになると、問題が発生するのではないかと心配しています。

私は負荷分散などのことを知っていますが、ここで私が得ている質問は、実際にそれをどのように実装するかについて、十分な情報に基づいたインテリジェントな決定を行うように自分自身に問うべきことです。

概要

ここでの主な目標は、大規模なプラットフォーム（SEなど）が直面するいくつかの問題と、その過程で考慮すべき事項に直面するように、このプラットフォームを準備することです。以前のフェーズでアプリケーションを構築して、後で来るより大きなものをサポートする方法と同じように。

Kain0_0 · Accepted Answer

情報に基づいたインテリジェントな決定

.。

データはありますか？

データがあれば、合理的な意思決定の基礎が得られます（これは非常に有益です）。

そうでなければ、あなたは不合理な意思決定の基礎となる推測作業を持っています（あなたが尋ねるならあなたはおそらくそれらの人々の一人ではないでしょう）。

トラフィックの負荷が高いサイトを置き換えますか？

既にanyトラフィック負荷のあるサイトを置き換える場合は、インテリジェントな決定を行うことができます。決定のインテリジェンスが、メリット（あるレベルのサービス内でユーザーにサービスを提供するWebサイト）とコスト（特定の実装）の違いである場合。候補ソリューションを特定し、最適な候補を選択することは（多少面倒な場合でも）簡単です。

そうでなければ、振り返ってみれば、決定の知性を前もって決定することは不可能です。あなたが何かをすることを選ばなければならないので、これは明らかに今あなたを助けません。

謙虚に

あなたはすぐ近くに何があるかわかりません、そしてあなたはあなたのサイトがどんな問題に直面するか知ることができません。そのため、コードを記述して、今は問題ないように見える選択を行うことになりますが、後で問題が発生することはありません。

その問題が発生すると、一般的に、新しいソリューションが以前は正当化されなかったことがわかります。実際、あなたはおそらくあなたが経験していることに対してあまりにも複雑/困難/過剰殺害としてそれを捨てたでしょう、そしてあなたは正しかったでしょう。世界はちょうど変わった。

そうは言っても変更が発生し、変更を簡単にするための準備をすることができます。

懸念事項

大まかに言えば、3つの懸念軸があります。

機能：これは、ユーザープロファイル、レポート、1日の終わりの処理などのシステム動作です...
運用：これは、ライトをオンに保つ方法です。スケーリングできるか、何人のユーザーを処理できるか、エラーから適切に回復できるかなど...
開発：これは、ソフトウェアを理解して変更するのがいかに簡単かです。他の機能/操作を中断することなく、機能を追加できますか？バグを簡単に見つけることができるか、ユーザーがバグを見つける前にバグを見つけることができるかなど...

行うすべての変更は、これらの軸に影響を与えます。できれば、これらのすべての軸を優れたものにしたい、高機能、低メンテナンス、夢の改善を望んでいます。残念ながら、ほとんどの選択により、これらの次元の1つが改善され、他の2つは悪化します。

モノをモジュラーに保つ

現在のツールは老朽化して壊れ、需要に応じて拡張されず、ニーズに応じて変化しないため、モジュール性が求められます。

少なくともそれらがモジュール式である場合、それらを置き換えることができます。メンテナンスの行き届いたツール、容量の大きいツール、高速なツール、機能の高いツールを入れ替えたり、オンデマンドでツールを選択したりできます。

モジュールは、変更される選択肢を含み、非表示にする必要があります。一般に、そのモジュールの少なくとも3つのバリアントを実装することをお勧めします。私は一般的に選択します：

本番環境で使用する実際の実装
ライト/シングルユーザーの実装。主に開発者、または自動化テストで使用され、開発/動作のチェックを高速化します。
テストをサポートするスタブ/プロキシ。インタラクションをログに記録し、使用状況を確認し、モジュールレベルのテストに参加します。

モジュールインターフェイスの欠陥を確実に明らかにするいくつかの実際の実装を実装することが可能であれば。

通信とカップリング

コミュニケーションの必要性を減らします。ソフトウェアが認識しなければならないモジュールが少ないほど、通信の頻度が少なくなり、通信が複雑にならないほど、通信は改善されます。

単一ページのWebアプリは、要求する静的データと動的データの多くをキャッシュできます。賢明に行うと、これはあなた自身のシステムの負荷を減らすことができます。
データベースはメモリ内キャッシュとペアにして、読み取りへのアクセスを高速化できます。
ビジネスアクションをローカルに保つと（2人のユーザーが互いに干渉することなく同じアクションを実行できます）、同期ポイントが不要なため、水平方向にスケーリングできます。

奇妙なことに、時々コミュニケーションを改善すると、より多くの情報を伝達しなければならなくなります。たとえば、1回だけ実行する必要があるアクションのべき等ID、または特定の要求の日没を示すタイムスタンプ。

適切なログと監視

何百万ものユーザーに直面すると、すべてのバグが見つかり、それぞれの制限が明らかになります。それらが見つかったとき、あなたはそれらが起こったこと、それらが何であったか、そして説明を知りたいです。これを効果的に行うには、ログに記録して適切にログを記録する必要があります。

ログインする必要があります：

マシンで何が起こっているのか
利用可能なリソース
例外は何でしたか、それについてのすべての詳細
その例外が発生した場所
どのようにしてその例外のポイントに到達したか
プログラムがこのコードを実行しようとしていた理由
ドメイン知識の興味深い部分
等...

ログに記録されるものは、ルール（またはスクリプト/ツール）によって分類可能である必要があります。

その後、これはあなたに警告する必要があります。これは10秒であなたの携帯電話にSMSを意味するかもしれません。それはあなたが月曜日に見るバグレポートを意味するかもしれません。

良いロギングは[〜＃〜]ハード[〜＃〜]ですが、ライトをオンに保つために不可欠な部分です。

クラフトマンシップ

何かが不適切であると通知されたら、時間をかけて元に戻します。

あなたとあなたのチームは常にコードを変更します。これが意味することは、学習するということです。つまり、すでに記述されているコードの一部は、現在作成できるほど良くないということです。それを改善するために時間をかけてください。

読みやすさを向上させる（たくさん読むことになります）
一貫性を向上させます（驚きを取り除き、違いを簡単に確認できるようにします）
ロジックを改善します（ここでnullをチェックしなかったので、そのチェックを追加します）。
アルゴリズムを改善する（より良いソートを選択し、count = 0ではなくemptyをテストする）
何かが小さすぎたり、大きすぎたり、統合されすぎたりした場合に注意して、動作を再配置します。