ソフトウェア アーキテクチャとシステム設計: 全体像とリソース ガイド

こんにちは、同僚。

本日は、現代のソフトウェア システムの設計原則を比較的少量で概説した Tugberk Ugurlu による記事の翻訳をご検討いただくために提供します。 著者が自分自身について語っていることを要約すると次のとおりです。

2019年現在、アーキテクチャパターン＋デザインパターンという巨大なテーマをhabro記事で取り上げることは到底不可能なので、ウルグル氏の文章そのものだけでなく、同氏が親切に掲載してくださった多数のリンクも併せてご覧になることをお勧めします。 気に入っていただければ、分散システムの設計に関するより専門性の高いテキストを出版する予定です。

スナップショット アイザック・スミス アンスプラッシュより

ソフトウェア システムをゼロから設計するなどの課題に直面したことがない場合、そのような作業を開始するときに、どこから始めればよいのかさえわからないことがあります。 私は、まず境界線を引いて、正確に何をデザインしようとしているのかについて多かれ少なかれ自信を持って考え、それから腕まくりしてその境界線内で作業する必要があると考えています。 出発点として、製品またはサービス (理想的には本当に気に入ったもの) を取り上げ、それを実装する方法を考えます。 この製品がいかにシンプルに見えるか、そして実際にはどれほど複雑であるかに驚かれるかもしれません。 忘れてはいけない： シンプル - 通常は複雑、それで大丈夫です。

システムの設計を始めようとする人に私ができる最善のアドバイスは、これです。「仮定をしないでください」です。 最初から、このシステムについて既知の事実とそれに関連する期待を指定する必要があります。 設計を開始する際に役立つ質問をいくつか紹介します。

• 私たちが解決しようとしている問題は何ですか?
• システムを操作するユーザーの最大数はどれくらいですか?
• データの書き込みと読み取りにはどのようなパターンを使用するのでしょうか?
• どのような失敗が予想されますか?どのように対処しますか?
• システムの一貫性と可用性にはどのようなことが期待されますか?
• 作業する際に、外部の検証や規制に関連する要件を考慮する必要がありますか?
• どのような種類の機密データを保存するのでしょうか?

これらは、長年のプロとしての活動を通じて、私と私が参加したチームの両方にとって役立つ質問のほんの一部です。 これらの質問 (および作業する必要があるコンテキストに関連するその他の質問) に対する答えがわかっている場合は、問題の技術的な詳細を徐々に掘り下げることができます。

初期レベルを設定する

ここで言う「ベースライン」とは何を意味するのでしょうか？ 実際、現代では、ソフトウェア業界のほとんどの問題は、既存の方法やテクノロジーを使用して解決「可能」です。 したがって、この状況をナビゲートすることで、他の誰かが自分より先に解決しなければならなかった問題に直面したときに、ある程度有利なスタートを切ることができます。 プログラムはビジネスおよびユーザーの問題を解決するために作成されているということを忘れないでください。そのため、私たちは (ユーザーの観点から) 最も単純かつ単純な方法で問題を解決するよう努めています。 これを覚えておくことがなぜ重要なのでしょうか? おそらく、座標系ですべての問題に対する独自の解決策を探すのが好きなのでしょう。「どこでもパターンに従っていたら、私はどのようなプログラマーだろう」と考えているからです。 実際には、 ここで重要なのは、どこで何をするかを決定することです。 もちろん、私たち一人ひとりが時折、特有の問題に対処しなければならず、そのどれもが大きな課題です。 しかし、最初のレベルが明確に定義されていれば、何にエネルギーを費やすべきかがわかります。つまり、目の前に設定された問題を解決するための既製のオプションを探すか、それをさらに研究してより深い理解を得ることができます。

専門家が素晴らしいソフトウェア システムのアーキテクチャ コンポーネントが何であるかを自信を持って理解できれば、その知識はアーキテクトとしての技術を習得し、この分野で強固な基盤を築くために不可欠なものになるということを納得していただけたと思います。

さて、どこから始めればいいでしょうか？ U ドンナ・マルティナ GitHub 上に というリポジトリがあります。 システム設計入門書、大規模システムの設計方法を学び、このテーマに関する面接の準備をすることができます。 リポジトリには例を含むセクションがあります 実際のアーキテクチャここでは特に、システムの設計にどのようにアプローチするかが考慮されます。 いくつかの有名な企業例: Twitter、Uber など。

ただし、この資料に進む前に、実際に直面する最も重要なアーキテクチャ上の課題を詳しく見てみましょう。 これは、頑固で多面的な問題の多くの側面を指定し、特定のシステムで施行されている規制の枠組み内で解決する必要があるため、重要です。 ジャクソン・ギャバードフェイスブックの元従業員はこう書いた。 システム設計インタビューに関する 50 分のビデオで、彼は何百人もの応募者を審査した自身の経験を共有しました。 このビデオは大規模なシステム設計と、そのようなポジションの候補者を探す際に重要な成功基準に重点を置いていますが、システム設計時に最も重要なことについての包括的なリソースとしても役立ちます。 私も提案します まとめ このビデオ。

データの保存と取得に関する知識を構築する

通常、長期にわたってデータを保存および取得する方法に関する決定は、システムのパフォーマンスに重大な影響を与えます。 したがって、まずシステムで予想される書き込みおよび読み取りの特性を理解する必要があります。 次に、これらの指標を評価し、行われた評価に基づいて選択を行うことができる必要があります。 ただし、既存のデータ ストレージ パターンを理解している場合にのみ、この作業に効果的に対処できます。 原則として、これは以下に関する確かな知識を意味します。 データベースの選択.

データベースは、非常にスケーラブルで耐久性のあるデータ構造と考えることができます。 したがって、データ構造に関する知識は、特定のデータベースを選択するときに非常に役立ちます。 例えば、 Redisの は、さまざまなタイプの値をサポートするデータ構造サーバーです。 これにより、リストやセットなどのデータ構造を操作したり、よく知られたアルゴリズムを使用してデータを読み取ることができます。 LRU、そのような作業を耐久性があり、非常にアクセスしやすいスタイルで整理します。

スナップショット サミュエル・ゼラー アンスプラッシュより

さまざまなデータ ストレージ パターンを十分に理解したら、データの一貫性と可用性の検討に進みます。 まず第一に、理解する必要があります CAP定理 少なくとも一般的には、確立されたパターンを詳しく見て知識を磨きます。 一貫性 и 利用可能。 こうすることで、この分野についての理解を深め、データの読み取りと書き込みが実際には XNUMX つのまったく異なる問題であり、それぞれに独自の課題があることが理解できるようになります。 いくつかの一貫性と可用性のパターンを活用すると、アプリケーションへのスムーズなデータ フローを確保しながら、システムのパフォーマンスを大幅に向上させることができます。

最後に、データ ストレージの問題についての会話の締めくくりとして、キャッシュについても触れておく必要があります。 クライアントとサーバーで同時に実行する必要がありますか? キャッシュにはどのようなデータが含まれますか? なぜ？ キャッシュの無効化はどのように行うのでしょうか? それは一定の間隔で定期的に行われるのでしょうか？ 「はい」の場合、どのくらいの頻度でしょうか? これらのトピックについて勉強し始めることをお勧めします 次のセクション 前述のシステム設計入門書。

コミュニケーションパターン

システムはさまざまなコンポーネントで構成されます。 これらは、同じ物理ノード内で実行されている異なるプロセス、またはネットワークの異なる部分で実行されている異なるマシンである可能性があります。 ネットワーク内のこれらのリソースの一部はプライベートである可能性がありますが、その他はパブリックであり、外部からアクセスする消費者に対してオープンである必要があります。

これらのリソースの相互通信、およびシステム全体と外部世界との間の情報交換を確保する必要があります。 システム設計の文脈では、ここでも私たちは一連の新しくてユニークな課題に直面しています。 それらがどのように役立つかを見てみましょう 非同期タスクフロー、そして何p多彩な通信パターンが利用可能.

スナップショット トニー・ストッダード アンスプラッシュより

外部の世界とのコミュニケーションを組織するとき、常に非常に重要です セキュリティ、その規定も真剣に受け止め、積極的に推進する必要があります。

接続分布

このトピックを別のセクションに置くことが誰にとっても正当であると思われるかどうかはわかりません。 それでも、ここではこの概念を詳しく説明します。このセクションの内容は「接続分布」という用語によって最も正確に説明されると信じています。

システムは多くのコンポーネントを適切に接続することによって形成され、それらの相互の通信は多くの場合、TCP や UDP などの確立されたプロトコルに基づいて組織されます。 ただし、これらのプロトコル自体は、多くの場合、高負荷の下で動作し、ユーザーのニーズに大きく依存する最新のシステムのニーズをすべて満たすには不十分です。 多くの場合、システム上のこのような高負荷に対処するために、接続を分散する方法を見つけることが必要になります。

このディストリビューションはよく知られているものに基づいています。 ドメインネームシステム (DNS)。 このようなシステムでは、負荷の分散に役立つ重み付きラウンドロビンや待ち時間ベースの方法などのドメイン名変換が可能です。

負荷分散 は基本的に重要であり、現在私たちが扱っているほとんどすべての大規模なインターネット システムは XNUMX つ以上のロード バランサーの背後に配置されています。 ロード バランサーは、クライアントのリクエストを複数の利用可能なインスタンスに分散するのに役立ちます。 ロード バランサーにはハードウェアとソフトウェアの両方がありますが、実際には、より多くの場合、ソフトウェアのものを処理する必要があります。 ハプロキシ и ELB. リバースプロキシ 概念的にはロードバランサーと非常によく似ていますが、最初と XNUMX 番目の間には範囲があります。 明確な違い。 ニーズに基づいてシステムを設計するときは、これらの違いを考慮する必要があります。

についても知っておくべきです コンテンツ配信ネットワーク (CDN)。 CDN は、地理的に特定のユーザーに近いノードから情報を配信する、プロキシ サーバーのグローバル分散ネットワークです。 JavaScript、CSS、HTML で記述された静的ファイルを操作する場合は、CDN を使用することをお勧めします。 さらに、今日ではトラフィック マネージャーを提供するクラウド サービスが一般的です。たとえば、 Azure トラフィック マネージャーにより、グローバルな分散が可能になり、動的コンテンツを操作する際の遅延が軽減されます。 ただし、このようなサービスは通常、ステートレスな Web サービスを操作する必要がある場合に役立ちます。

ビジネスロジックについて話しましょう。 ビジネスロジック、タスクフロー、コンポーネントの構造化

そこで、システムのさまざまなインフラストラクチャの側面について議論することができました。 おそらく、ユーザーはシステムのこれらすべての要素について考えもせず、率直に言ってまったく気にしていません。 ユーザーは、システムと対話することがどのようなものなのか、これによって何が達成できるのか、またシステムがユーザー コマンドをどのように実行するのか、ユーザー データをどのように扱うのかに興味を持っています。

この記事のタイトルが示すように、私はソフトウェア アーキテクチャとシステム設計について話すつもりでした。 したがって、ソフトウェア コンポーネントがどのように作成されるかを説明するソフトウェア設計パターンを取り上げるつもりはありませんでした。 しかし、考えれば考えるほど、ソフトウェア設計パターンとアーキテクチャパターンの間の境界線は非常に曖昧であり、XNUMX つの概念は密接に関連しているように思えます。 たとえば イベント登録 (イベントソーシング)。 このアーキテクチャ パターンを採用すると、データの長期保存、システムに採用されている一貫性のレベル、システム内のコンポーネントの形状など、システムのほぼすべての側面に影響します。 したがって、ビジネス ロジックに直接関係するいくつかのアーキテクチャ パターンについて言及することにしました。 この記事では単純なリストに限定する必要がありますが、このリストをよく理解し、これらのパターンに関連するアイデアについて考えることをお勧めします。 はい、どうぞ：

• 堅固な原則
• 概念 ドメイン駆動設計特に 単位, チームとイベント
• 六角形のアーキテクチャ
• 責任をコマンドとリクエストに分離 (CQRS)
• イベント登録
• 俳優モデル
• MVC、MVVM、MVP の設計パターン

協力的なアプローチ

システム設計プロセスに単独で責任を負う参加者としてプロジェクトに参加することは、ほとんどありません。 それどころか、タスク内外で働く同僚とやり取りする必要がある可能性が高くなります。 この場合、選択したテクノロジ ソリューションを同僚と評価し、ビジネス ニーズを特定し、タスクを並列化する最適な方法を理解する必要がある場合があります。

スナップショット カレイディコ アンスプラッシュより

最初のステップは、達成しようとしているビジネス目標は何なのか、どのような変動部分に対処する必要があるのか​​について、正確かつ共通の理解を深めていくことです。 特にグループモデリング手法 嵐の出来事 (イベント ストーミング) は、このプロセスを大幅にスピードアップし、成功の可能性を高めるのに役立ちます。 この作業は、アウトラインを作成する前でも後でも実行できます。 サービスの境界線、そして製品が成熟するにつれてそれを深めます。 ここで達成される一貫性のレベルに基づいて、次のように定式化することもできます。 共通語 限られた状況で作業する場合に限ります。 システムのアーキテクチャについて話す必要がある場合に役立つかもしれません。 モデルC4提案された サイモン・ブラウン、特に、伝えたいことを視覚化して、問題の詳細にどれだけ踏み込む必要があるかを理解する必要がある場合。

おそらく、このトピックに関しては、ドメイン駆動設計と同じくらい有用な、成熟したテクノロジーがもう XNUMX つあるでしょう。 ただし、どういうわけか主題領域の理解に戻りますので、その分野の知識と経験 ドメイン駆動設計 役に立つはずです。

出所： habr.com