現在、多くの成功したプロジェクトは小さなスタートアップから成長し、後に商業的な成功を収め、大規模な国際企業になりました。 この成長の機会は、主にインターネットと「境界線の消去」の影響により、過去20年間に現れました。 どの国でも使用できるグローバルなインターネットアプリケーションとモバイルアプリケーションがあります。 以前は、ほとんどの場合、アプリケーションが国際プロジェクトである場合、そのような要件を考慮してすぐに設計されていました。 もちろん、進化的なアプローチを取ることができ、プロジェクトが成長するにつれて、必要な機能とスケーリングを追加します。 しかし、さらなる変更の実装を容易にするために、将来変更が困難ないくつかの基本的な機能の規模をすぐに考慮する必要があります。
私は2つのスタートアッププロジェクトに携わり、小規模な地域プロジェクトから数百万人のユーザーを抱える大企業を撮影し、成長しました。 驚いたことに、アプリケーションはさまざまなチームによって、さまざまなユーザー向けに作成されていましたが、多くの一般的な問題があることがわかりました。 スタートアップの遺産であるデータベースの一般的な問題、たとえばプロジェクトが当初小規模に計画されていたことを示す幼稚な成長の問題を見ることができます。
国際規模のプロジェクトをすぐに作成する必要はありませんが、必要に応じてプロジェクトを国際的な負荷の高いシステムに変換しやすくする基本的な機能を用意することが重要です。
そして、主なエラー：
- ローカライズの欠如。
私たちの世界は長い間グローバルになっており、ソフトウェアアプリケーションに境界はありません。 プロジェクトが1つの国だけでなく世界中で人気を博した場合、ローカライズの可能性は非常に重要です。 開発段階およびローカリゼーションの基盤を構築する段階では、情報を保存するためのデータ型を正しく選択することが重要です。これは国によって異なります。 そのような基盤がない場合、既にアクティブに使用されているアプリケーションをローカライズすることは困難です。 ローカライズする際に考慮すべき4つの主なポイントがあります。
- タイムゾーン
UTC形式で、またはクライアントのタイムゾーンを考慮して、日付と時刻を保存する必要があります。 すべてのサーバーの日付も、表示されるときにクライアントのタイムゾーンに変換する必要があることに注意してください。 ばかげて明白に見えますが、最初はプロジェクトの1つで、他の地域のサポートを提供するようオーナーに申し出たとき、彼はそのような成長を計画していないと言いました。 そして、成長がありました。 そして、彼らがすぐに横たえなかったという事実についての引き裂かれた髪。
- 異なる言語
テキストフィールドを選択するときは、Unicode形式またはNVarchar型を使用する必要があります。これにより、アプリケーションでの作業が容易になります。 データベース内の行の並べ替えと比較のルールに注意する必要があります。 デフォルトではCollationではなく、発音区別符号、象形文字、および非標準幅の文字を比較するときに正しく機能するソートを選択します。ただし、エンドユーザーが何らかの情報を入力する必要があります。 教えてください、あなたのアプリケーションはアメリカだけで機能しますか、それともヨーロッパだけで機能しますか？ 次に、エンドユーザーが入力できるデータがあるかどうかを自問する必要があります。 少なくとも何かコメント行やあなた自身のための情報ですか？ そのような可能性がある場合-Unicodeで文字列の保存を行います。 世界は長い間混乱しており、日本語を使用している人がユーザーとしてデータベースに何かを追加するという事実からあなたは安全ではありません。 最終的な目標は、ユーザーデータが正しく保存され、正しく表示されるようにすることです。
- 通貨
データベースに現金に関する情報が保存されている場合、保存する通貨を明確にし、アプリケーションを変更せずに別の通貨を入力できるメカニズムを導入することをお勧めします。 これは、レートの変換という形で完全な機能を実装することを意味するのではなく、それらのロードおよびその他のツールは最初の段階で冗長であり、ユーザーの国を変更するときにデータベースに保存されている異なる通貨の金額を区別できるように表に通貨単位の記号を保存します 一部の国では複数の通貨での取引が許可されていることを覚えておくことが重要です。
- ナチュラルキー
ほとんどすべての標準的なデータベースの教科書には、人工キーがどれほど効果的でなく、自然キーがどれほど美しいかが記載されています。 しかし、原則として、世界はまだ誰もが自然キーを使用できるほどのグローバル化レベルに達していません。自然キーが存在するためには、オブジェクトの統一された分類が必要であり、そのためにキーが選択され、世界全体で統一されたグローバルなままです。
たとえば、プロジェクトの1つで、TINを取引相手の自然なキーとして使用することを考えていましたが、この考えを放棄しました。 会社がロシア国外の法人と発展し協力するようになったので、私たちが後でこれを喜んだことを言葉で説明することはできません。
- タイムゾーン
- データ型
データ型の正しい選択は、アプリケーションの正常な動作の鍵であり、その結果、開発者の健康と静かな眠りになります。 データ型のディメンションを選択する場合、最大数のユーザーと操作から可能な最大数のオプションに焦点を合わせる必要があります。
たとえば、会社のみの従業員のリストを含むテーブルを作成する場合、会社が20億人に成長する可能性は非常に小さいため、タイプINTの主キーを使用することができます。 ただし、クライアントの会社の従業員のデータベースを作成する場合、BIGINTなどのより大きなディメンションのデータ型を使用する必要があります。これは、50万人の従業員が仕事の変更に応じて4回データベースに200万件のレコードを作成し、多数の顧客が存在するクライアント企業の従業員のリストを保存すると、20億を超える可能性があります。同じルールは、ユーザーログを保存するテーブルや、アプリケーションの成長に伴い増加する可能性のある他のビジネスオペレーションにも適用されます 私は百万回です。
- ユーザーアクションに対する同期された応答
システムを設計するときは、システムが成長した場合に、多数のシステムオブジェクトの変更または削除に関連するユーザーアクションを検討することが重要です。 たとえば、ユーザーが2000人の連絡先を持ち、招待状を送信した場合、システムはこの招待状をすぐに送信するか、リクエストが処理されていることを示すメッセージをユーザーに表示し、アクションが処理されたときにステータスを完了に更新します。
処理が即時の場合、将来のシステムの成長に伴い、サーバーのパフォーマンスに問題が生じる可能性があります。 また、すべての要求を同期的に処理するときのシステムのワークロードは、ユーザーのアクションに直接依存します。 たとえば、標準的なブートでは、システムには通常モードですべての要求を処理するための10％のリソースがあります。 一度に50万人のユーザーへの招待など、カスタムのスーパーリクエストが表示されると、システムの負荷が最大100％増加する可能性があります。 例はやや合成的ですが、本質は明らかだと思います。 この場合、システムはこの巨大なリクエストの処理が完了するまで、残りの個々のユーザーのリクエストの適切な処理を停止します。
どのようなユーザーアクションが大規模になる可能性があるかを考え、それらを非同期にします。 招待状の例では、システムはすぐに送信を開始せず、「ユーザーへの招待状の送信」という新しいタスクを作成します。 タスクが作成されると、システムは招待をバックグラウンドで送信し、完了時にユーザーにタスクの完了を通知します。 ユーザーの利便性のために、非同期モードで動作するシステムのアクションの通知も非常に重要です。
このような機能をシステムに組み込んだことで、大規模なユーザーアクションが発生した場合の過負荷を防ぐことができます。これは、主要な顧客から大規模なアクションが発生する企業システムでの作業に重要です。
- 不要なデータの蓄積
プロジェクトの作業の開始時には、ディスクスペースの価格は非常に手頃なため、開発者は原則として、システムで使用される空きスペースとディスクスペースの量を考えません。 システムが最初の100万人のユーザーに到達するまで、ディスク容量を節約することを考えている人はいません。 これに先立ち、各ユーザーアクションのログを永久に保存する余裕があります。
たとえば、ユーザーがテクニカルサポートに連絡した場合に備えて、ユーザーアクションログを1〜2週間保持することが重要です。 この情報は削除できます。 したがって、古いデータを大量に蓄積する前に、古いデータを削除するプロセスを考え直してすぐに導入することが重要です。 このプロセスがすぐに規定されていない場合、新しいデータの膨大なストリームがデータベースに追加されるときに問題が発生する可能性が高く、システムは不要なデータの削除に対処できません。 古いデータを削除するための効果的なシステムを検討する必要があります。これにより、新しいデータストリームの速度を超えるだけでなく、予測可能な時間内に過去数年間の作業で膨大な量の情報を削除できるようになります。
古いジャンクデータを削除するルールは、すべての新しい機能に適用する必要があります。
- テストとドキュメントの欠如
通常、スタートアッププロジェクトはより早く開始するために急いでいます。 また、通常、比較的小規模の開発者チームがストラトアップを実装します。ストラトアップは、アプリケーションのビジネスロジック全体を心得ており、ドキュメントの作成やテストの時間を無駄にする理由を理解していません。 この作業は、「今から始めて、次に書く」という原則に基づいて行われます。 ただし、システムが起動するとすぐに、膨大な数の新しいタスクが表示され、ドキュメントを作成する時間は残りません。
プロジェクトの開発が成功すると、会社は急速に成長し始め、新しい従業員を採用し始めます。 ドキュメントなしでチームに新しい開発者を含めることは非常に難しく、時間がかかります。 元のチームのメンバーのすべての作業時間が、新しい従業員にシステムの機能を説明するために費やされるときが来るかもしれません。
すぐにドキュメントを書くことを強くお勧めします。 その後、それは完全に完済します。
テストに関しては、開発チームが成長したらすぐに、新しい機能の開発または既存の機能の改良/修正が既存のシステム機能の残りに悪影響を及ぼさないことを確認する必要があります。 テストは、機能をテストする最も簡単で効果的な方法です。
- スケーリング
システムの負荷が増加するにつれて、システムの拡張が必要になります。 したがって、システムの設計中に、たとえば10倍の負荷の増加に伴ってシステムをスケーリングする可能性を考慮する必要があります。 スケーラビリティのために設計されたこの設計は、成長するシステムの新しい現実に対するその後の変更を容易にします。
自分と開発者に次の質問をするのはいいことです。
- 機器の容量を増やした場合、システムのパフォーマンスを向上させる方法は？
- 別のサーバーでシステムのコピーを作成して、それをオンにすることはできますか？ そうでない場合、これを可能にするために設計で何を変更する必要がありますか？
- システムを複数の部分に分割し、SOAまたはマイクロサービスの原則を使用してアーキテクチャを再構築するために必要な変更の規模はどれくらいですか？
これは、システムをすぐに大規模に設計する必要があるという意味ではありませんが、システムをさらに拡張するための基盤を築くことが重要です。 ストローを薄い層に置き、シーブをすぐにどこでも折り畳まないでください。
- 機器の容量を増やした場合、システムのパフォーマンスを向上させる方法は？
したがって、システム設計の初期段階では、将来の作業と現在の作業のバランスをとることが重要です。 また、通常は短時間で実装する必要がある特定の要件とタスクがあるため、現在はより重要です。 当初は期待されていた未来が来ないか、まったく異なるように見えるかもしれません。 市バスを作るように頼まれた場合、この将来が市バスで起こらないかもしれないので、すぐにそれを宇宙船に変えることを可能にする必要はありません。 したがって、システムをさらに分離するための基盤を構築することが理想的であり、その後、サービスとモジュールの多様性のために使用されます。