序文
さて、ここのブロガーがまずは乾物満載のコラムを投稿していきます！
まずはブロガーの質の高いブログのまとめです。このコラムのブログはブロガーの皆さんの気の利いた文章ばかりです。辛口満載です。皆様のお役に立てれば幸いです。
それから、ブロガーが最近最も時間を費やしているコラム「Docker の実践から基礎となる原則への理解まで」です。皆さんももっと注目していただければ幸いです。
ブログ参照: Bit 雇用クラス
第 1 章 - 技術アーキテクチャ
スタンドアロンアーキテクチャ
導入
すべてのサービスは 1 つのサーバーにデプロイされます。
簡単に言えば、すべてが 1 つのサーバー上にあります。
原因
インターネットの初期には、用途は限られており、スタンドアロン サーバー アーキテクチャで要件を満たすことができました。
技術事例
関連ソフトウェア:
-
Web サーバー ソフトウェア: Tomcat、Netty、Nginx、Apache など。
-
データベース ソフトウェア: MySQL、Oracle、PostgreSQL、SQL Server など。
アーキテクチャの長所と短所
利点は、構成が簡単でオーバーヘッドが低いことですが、欠点は、パフォーマンスに重大な制約が生じ、データベースとアプリケーションがリソースをめぐって競合することです。
アプリケーションデータ分離アーキテクチャ
導入
非常に単純です。つまり、アプリケーション サービスとデータベース サービスは異なるサーバーを使用します。
データベースとアプリケーションの間には余分な線があり、この線がネットワークであることに注意してください。
原因
リソースを巡る激しい競争により、Web サイト単体では応答速度が遅くなる場合があります。
アーキテクチャの仕組み
DNS はアプリケーション サーバーの IP を返し、アプリケーション サーバーはそれを見つけるためにデータベース サービスにアクセスします。
長所と短所
-
利点: 高い経済的な制御性、スタンドアロン モードよりも優れたパフォーマンス、データベースの独立した分離における優れたパフォーマンス、アプリケーションの障害がデータベースに影響を与えず、一定のフォールト トレランスを備えています。
-
短所: ハードウェア投資の増加とパフォーマンスの制限により、大規模で同時実行性の高い要件に対処することが困難になります。
アプリケーションサービスクラスタのアーキテクチャ
導入
負荷分散が導入され、アプリケーションはクラスター モードで動作します。
原因
アプリケーション サーバーは高い同時実行性に耐えることができず、同時実行性が高いとクラッシュしやすくなります。
アーキテクチャの仕組み
概略図に示すように、高い同時実行性の圧力を軽減するために、複数のアプリケーション サーバーのレイアウト スキームが採用されています。
**負荷分散の意義:** ユーザーリクエストをどのアプリケーションサーバーに振り分けるかという問題を解決するには、トラフィック分散のための専用のシステムコンポーネントを導入する必要があります。実際のアプリケーションでは、負荷分散の範囲はアプリケーション層に限定されず、他のネットワーク層もカバーすることができます。
同時に、負荷分散アルゴリズムには多くの種類があり、以下にいくつかの一般的なものを簡単に紹介します。
- ラウンドロビン アルゴリズム (ラウンドロビン):公平性を確保するために、リクエストをさまざまなアプリケーション サーバーに公平かつ順番に分散します。
- 加重ラウンドロビン アルゴリズム (Weight-Round-Robin):サーバーのパフォーマンスなどの要因に応じて異なる重みを割り当て、パフォーマンスの高いサーバーがより多くのリクエストを割り当てることができます。
- 一貫したハッシュ アルゴリズム:ユーザーの特性 (IP アドレスなど) を計算してハッシュ値を取得し、そのハッシュ結果に従ってリクエストを分散します。この方法の利点は、一般的な専用の顧客担当サービスと同様に、同じユーザーからのリクエストが常に同じサーバーに割り当てられることです。
このレイアウトの利点は、同時実行性が高い状況に効果的に対処し、システムの安定性と応答速度を確保できることです。
DNS はどのように負荷分散を行うのでしょうか?
DNS がドメイン名を通じて IP アドレスを返すことができることはわかっています。
たとえば、www.taobao.com にアクセスしたい場合、最初の LVS を示すために初めて ip1 を返し、2 番目の LVS を示すために ip2 を返します...というようになります。DNS は負荷分散の作業を完了することもできます。
長所と短所
アドバンテージ：
- アプリケーション サービスの継続的な可用性を確保する: アプリケーション サーバーに障害が発生しても、Web サイト全体がクラッシュすることはありません。
- 一定の高いパフォーマンスを備えており、データベース (キャッシュされたデータなど) にアクセスせずに、大量のリクエストに迅速に応答できます。
- 一定の水平拡張性を有し、サーバーを水平に増設することでシステムの拡張が可能です。
短所:
- データベースのパフォーマンスがボトルネックになる: データベースは 1 つしかないため、複数のユーザーが同時にデータを要求すると、データベースのパフォーマンスの問題が発生する可能性があります。
- データベースは単一サーバーの独立したアーキテクチャであり、高可用性が欠けています。
- O&M の負担の増加: 導入の拡大に伴い、O&M タスクも増加し、迅速な導入の課題を解決するために対応するツールを開発する必要があります。
- より高いハードウェアコストを負担する必要があります。
読み書き分離/マスタースレーブ分離アーキテクチャ
導入
データベースの読み取りおよび書き込みタスクを異なるノードに割り当てることにより、データベース サーバーのマスター/スレーブ クラスターを確立しました。このクラスターでは、通常、1 つのマスター ノードと 1 つ以上のスレーブ ノードが構成されます。または、1 つのマスター ノードと複数のスレーブ ノードが存在する場合もあります。このアーキテクチャでは、プライマリ データベースは書き込み操作の処理を担当し、セカンダリ データベースは読み取り操作の処理専用になります。
原因
データベースがボトルネックになる状況では、特にインターネット アプリケーションでは、通常、書き込み操作よりも読み取り操作の方が大幅に多くなります。この場合、多数の読み取りリクエストによりデータベースに大きな負荷がかかります。したがって、読み取り操作と書き込み操作を分離して、この課題に対処できます。
アーキテクチャの仕組み
書き込み操作の場合は、マスター データベースにアクセスし、変更後にデータをすべてのスレーブ データベースに同期します。
読み取り操作の場合は、スレーブ データベースにアクセスするだけです。
このような一般的な中間コンポーネントには、MyCat、TDDL、Amoeba、Cobar などがあります。
長所と短所
アドバンテージ：
- データベース読み取りパフォーマンスの向上
- 読み取りは他のサーバーと共有され、書き込みパフォーマンスが間接的に向上します。
- データベースにはスレーブライブラリがあり、データベースの可用性が高い
欠点:
- ホットデータを頻繁に読み取るとデータベースの負荷が高くなる
- 同期が失敗するか、同期遅延が比較的大きい場合、書き込みライブラリと読み取りライブラリのデータが不整合になります。
- サーバーコストはさらに増加する必要がある
冷温分離アーキテクチャ
導入
キャッシュを導入し、ホットとコールドの分離を実装し、高速応答のためにホット データをキャッシュに置きます
原因
膨大な数のリクエストによりデータベースの負荷が高くなりすぎ、サイトの応答が再び遅くなりました。
アーキテクチャの仕組み
ホットスポット データの場合は、データベースではなくキャッシュに直接移動します。
書き込むときは、キャッシュとデータベースの両方に書き込む必要があります。そして、それは同時成功か同時失敗しか保証できません（ソフトウェアはそれを行うことができます）
読み込みの際、キャッシュにあれば直接キャッシュに読み込まれ、なければデータベースに読み込まれます。
アーキテクチャの長所と短所
アドバンテージ：
- パフォーマンスの大幅な向上: 読み取り操作と書き込み操作を分離することで、データベースへのアクセスの負担が大幅に軽減されます。
欠陥：
- キャッシュ関連の問題の原因: 一貫性の問題、キャッシュの故障、キャッシュの無効化、キャッシュなだれが発生する可能性があります。
- サーバーのオーバーヘッドの増加: この戦略を実装するには、サーバー機器の追加コストが必要になる場合があります。
- ビジネス規模が拡大すると、業務量の増加に伴いデータ量が増加し続けることでデータベースが過剰に大きくなったり、1 つのテーブル内のデータが大きすぎてクエリのパフォーマンスに影響を及ぼしたり、データベースが再びボトルネックになります。
垂直サブデータベース アーキテクチャ (分散データベース アーキテクチャ)
導入
データベースのデータは分割されており、データベース データの分散保存、分散処理、分散クエリも分散データベース アーキテクチャとして理解できます。
原因
前述の単一マシンでデータベースを書き込むと、徐々にパフォーマンスのボトルネックに達し、データ テーブルのデータ量が大きすぎる、処理負荷が高すぎる、テーブルを分割する必要がある、などの理由でデータベースを分割する必要があります。運用と保守の難しさを軽減するために、業界は分散データベースを徐々に開発しており、ライブラリ テーブルは当然分散をサポートしています。
アーキテクチャの仕組み
サブライブラリ、サブテーブルとは
写真が示すように。
分散データベースアーキテクチャ
長所と短所
アドバンテージ：
- データベースのスループットが大幅に向上し、ボトルネックではなくなりました
欠点:
- クロスデータベース結合や分散トランザクションなどの問題を解決する必要があります。現在の mpp には対応するソリューションがあります。
- 現在、データベースとキャッシュを組み合わせることで大量のリクエストを処理できますが、アプリケーションのコードは全体として結合されているため、コード行を変更するには全体として再公開する必要があります。
マイクロサービスアーキテクチャ
導入
マイクロサービスは、アプリケーション コードをビジネス分野に応じて分割するアーキテクチャ スタイルです。これにより、単一アプリケーションの責任がより明確になり、アプリケーションを互いに独立してアップグレードおよび反復できるようになります。
原因
- 拡張が難しい: アプリケーションを更新する必要があるたびにシステム全体を再構築する必要があるため、システムを簡単に拡張することはできません。
- 継続的な開発が妨げられる: 小さなコード変更でもアプリケーション全体を再デプロイする必要があるため、新しいバージョンを頻繁かつ簡単にリリースすることが困難になります。
- 信頼性の低さ: システムの単一の機能が失敗した場合でも、システム全体がクラッシュする可能性があります。
- 柔軟性の欠如: 異なるテクノロジーを使用して単一のアプリケーションを構築することはサポートされていません。
- コードのメンテナンスは困難です。すべての機能が密接に結合されているため、このコードを引き継ぐ人が改善の入り口を見つけるのが困難です。
アーキテクチャの仕組み
長所と短所
アドバンテージ：
- 高い柔軟性: 各サービスを個別にテスト、展開、アップグレード、リリースできます。
- 独立したスケーラビリティ: 各サービスは、他のサービスに影響を与えることなく、独立して拡張できます。
- 耐障害性の向上: 1 つのサービスの問題がシステム全体のクラッシュを引き起こすことはありません。
短所:
- 複雑な運用と保守: ビジネスの継続的な発展に伴い、アプリケーションとサービスの数が増加し、導入はより複雑になります。
- リソース要件の増加: 独立して実行される各マイクロサービスには、特定のリソースが必要です。
- トラブルシューティングの難易度の増加: リクエストには複数のサービス呼び出しが必要になる場合があるため、トラブルシューティングが困難になり、問題を特定するにはさまざまなサービスのログを確認する必要があります。
コンテナ オーケストレーション アーキテクチャ
導入
コンテナ化テクノロジ (docker など) を使用してサービス/アプリケーションをイメージにパッケージ化し、コンテナ オーケストレーション ツール (k8s など) を使用してイメージを動的に配布およびデプロイします。サービスはコンテナ化された方法で実行されます。
原因
- マイクロサービスは細かく分割されており、複数のサービスのデプロイには多くの作業が必要となり、構成は複雑でエラーが発生しやすくなります。
- マイクロサービスの数を拡張するのは面倒でエラーが発生しやすく、縮小・拡張のたびにサービスに対応した環境パラメータ情報を再設定するのは非常に煩雑です。
- これまでのところ、マイクロサービスの動作環境は競合する可能性があり、デプロイメントにより多くのリソースが必要になったり、構成を変更して競合を解決したりすることができます。
アーキテクチャの仕組み
長所と短所
アドバンテージ：
- 迅速な展開、簡単な運用とメンテナンス: シンプルなコマンドを使用して、数百のサービスの展開や拡張および縮小を完了します。
- 強力な分離: コンテナーはファイル システムとネットワークの点で高度に分離されており、環境の競合を回避します。
- 便利なローリング アップデート: 1 つのコマンドで異なるバージョンを切り替え、簡単なローリング アップデートをサポートします。
短所:
- テクノロジースタックは複雑であり、研究開発チームにとっては高い要件があります。
- マシン リソースの自己管理が必要です。オフピーク時間には、ピーク期間に備えるために多数のマシン リソースをアイドル状態にする必要がある場合があり、これによりマシンのコストと運用およびメンテナンスのコストに課題が生じます。この問題を解決するには、クラウド サービス プロバイダーが提供するサーバー リソースの購入を検討してください。