上級専門家が血を吐く要約: 有能なクラウド アーキテクトになるにはどうすればよいでしょうか?

クラウド アーキテクトは、特にクラウド テクノロジーが複雑化するにつれて、組織内のクラウド コンピューティング アーキテクチャを管理する責任を負います。クラウド コンピューティング アーキテクチャは、クラウド ストレージを管理するために必要なフロントエンド プラットフォーム、サーバー、ストレージ、配信、ネットワークなど、クラウド コンピューティングに関連するすべてをカバーします。

[[248138]]

この記事の著者は、クラウド アーキテクト向けの高度な戦略を次の側面から総合的に分析します。

• 3次元と6階層の建築
• クラウドコンピューティングの歴史的進化と基本原則を理解する
• オープンソースソフトウェアは進歩のための強力なツールです
• Linuxの基礎を学ぶ
• データセンターとネットワークの基礎を理解する
• KVM に基づくコンピューティング仮想化の理解
• Openvswitch に基づくネットワーク仮想化の理解
• OpenStack ベースのクラウド プラットフォームを理解する
• Mesos と Kubernetes に基づくコンテナ プラットフォームを理解する
• HadoopとSparkに基づくビッグデータプラットフォームについて学ぶ
• Lucene と ElasticSearch に基づく検索エンジンを理解する
• Spring Cloud に基づくマイクロサービスを理解する

3次元と6階層の建築

3次元

インターネット時代において、有能なクラウド アーキテクトになるには、3 つの主要なアーキテクチャに精通している必要があります。

ITアーキテクチャ

IT アーキテクチャは、実際にはコンピューティング、ネットワーク、およびストレージです。これはクラウド アーキテクトの基本的なスキルであり、従来のクラウド アーキテクトのほとんどが最初に習得すべき部分でもあります。

適切に設計された IT アーキテクチャは、CAPEX と OPEX を削減し、運用と保守の負担を軽減します。データ センター、仮想化、クラウド プラットフォーム、コンテナー プラットフォームはすべて IT アーキテクチャの範囲内に含まれます。

アプリケーションアーキテクチャ

アプリケーションが従来のアプリケーションからインターネット アプリケーションへと移行するにつれて、リソース レベルで弾力性に対処するだけでは不十分になります。多数のマシンが作成されても、大量の同時トラフィックをサポートできないことがよくあります。したがって、マイクロサービス ベースのインターネット アーキテクチャは、クラウド アーキテクトにとってますます必要なスキルになりつつあります。

適切に設計されたアプリケーション アーキテクチャは、高速な反復と高い同時実行性を実現できます。データベース、キャッシュ、メッセージキュー、Spring Cloud や Dubbo に基づくマイクロサービス フレームワークなどの PaaS はすべて、アプリケーション アーキテクチャのカテゴリに分類されます。

データアーキテクチャ

データは人工知能の時代における中核的な資産となっています。インターネットへの移行と同時に、人々はデジタルトランスフォーメーションを進め、戦略的にデータを収集することがよくあります。これには、クラウド アーキテクトが同時にビッグ データについて考えることが必要になります。

意識的に統合データプラットフォームを構築し、そのデータをデジタル運用に活用します。検索エンジン、Hadoop、Spark、人工知能はすべてデータ アーキテクチャのカテゴリに分類されます。

6つのレベル

上記の3つの次元は、人間の視点からのものです。システムの観点から見ると、アーキテクチャは 6 つのレベルに分かれています。

インフラストラクチャ層

データセンターには多数のラックとサーバーがあり、サーバーはスイッチとルーターを介して接続されています。 Oracle などの一部のアプリケーションは、物理マシンに展開する必要があります。

管理の利便性のため、VMware などの仮想化は物理マシン上に導入され、物理マシンの複雑な運用と保守を仮想マシンの柔軟な運用と保守に簡素化できます。

仮想化で採用されている運用保守方式は、主に運用保守部門によって管理されます。企業に多くの部門がある場合、適切なテナント管理が必要になることがよくあります。

パブリッククラウドで生まれたOpenStackは、クォータやQoSによるリソース制御、VPCによるネットワーク計画などで優れた成果を上げ、集中型の運用保守管理からテナントのセルフサービス利用モードへの移行を実現しました。

アプリケーション アーキテクチャの重要性が増すにつれて、標準化された配信と柔軟なスケーリングの需要が高まっています。コンテナは、ソフトウェア配信用のコンテナとして、イメージに基づいて環境間の移行を実現できます。 Kubernetes はコンテナ管理プラットフォームの事実上の標準です。

データレイヤー

データ層は、アプリケーションの中心的な軍事キャンプです。従来のアプリケーションの場合、Oracle と多数のストアド プロシージャが使用され、多数のテーブル結合クエリが実行されるため、コストが比較的高くなることがよくあります。

ただし、同時実行性の高いインターネット アプリケーションの場合、マイクロサービスを分割する必要があり、データベース インスタンスの数が増えます。オープンソースの MySQL を使用するのが一般的な選択肢です。

多数のストアド プロシージャと結合クエリにより、マイクロサービスを分割できなくなり、パフォーマンスが低下することがよくあります。そのため、複雑なビジネスロジックをアプリケーション層に配置する必要があり、データベーステーブルとインデックスの設計が非常に重要になります。

同時実行の量が比較的多い場合は、水平方向の拡張が必要となり、分散データベースと、単一のデータベースに基づく適切なテーブルおよびインデックスの設計が必要になります。

より柔軟な構造のデータの場合は、水平方向のスケーラビリティに優れた MongoDB データベースを使用できます。

大量の共同クエリが必要な場合は、高速で柔軟性の高い ElasticSearch などの検索エンジンを使用できます。

ミドルウェア層

データベース層では、データが失われないようにする必要があり、一部のトランザクションでは同時パフォーマンスがあまり大きくならないことがよくあります。

そのため、データベースは中央軍事キャンプであるとよく言われますが、すべてのリクエストがここに来るわけではないので、ほとんどのホットリクエストを傍受するにはキャッシュ層が必要です。

Memcached は、単純なキー値ストレージに適しており、メモリ使用率が比較的高く、マルチコア処理を使用しているため、比較的大きなデータに対して優れたパフォーマンスを発揮します。

しかし、その欠点も明らかです。厳密に言えば、Memcached にはクラスタリング メカニズムがなく、水平方向の拡張は完全にクライアントに依存します。

さらに、Memcached は永続化できません。クラッシュすると、すべてのデータが失われます。高可用性を実現するには、クライアントは二重書き込みを実行する必要があります。

Redis は豊富なデータ構造を持ち、永続性、成熟したマスター/スレーブ同期、フェイルオーバー機能を提供するため、高い可用性が保証されます。

さらに、マイクロサービスが分割された後は、注文の処理に多くのサービスを通過する必要があり、処理が遅くなることがあります。このとき、非同期処理を実現するには、メッセージ キューを使用して、サービス間の呼び出しをメッセージのサブスクリプションに変換する必要があります。

RabbitMQ と Kafka はよく使用されるメッセージ キューです。イベントが重要な場合は、データベースと組み合わせて信頼性の高いメッセージ キューが実装されます。

基本サービス層

場合によっては、中間プラットフォーム層となり、共通機能をサービスに抽象化し、外部にアトミック インターフェースを提供します。

このように、上位層は、ビジネスニーズに応じてこれらのアトミックインターフェースを柔軟に組み合わせることで、ビジネスニーズの変化に柔軟に対応し、機能の再利用や、さまざまなアプリケーションに分散しないユーザーデータや決済データなどのデータの一元管理を実現します。

さらに、基本サービス層は、アプリケーション、データベース、およびキャッシュ間の境界線となります。すべてのアプリケーションをデータベースに直接接続する必要はありません。データベースとテーブルのシャーディング、データベースの移行、キャッシュ選択の変更などが発生すると、その影響は非常に大きくなり、実行がほぼ不可能になります。

これらの基礎となる変更が基本サービス層でインターセプトされ、上位層が基本サービス層のインターフェースのみを使用する場合、基礎となる変更は上位層に対して透過的になり、徐々に進化することができます。

ビジネスサービス層または複合サービス層

ビジネス ロジックのほとんどはこのレベルで実装されます。ビジネス ロジックはよりユーザー指向であり、頻繁に変更されるため、基本サービスのインターフェイスを組み合わせて実装する必要があります。

このレイヤーでは、独立した開発、独立した起動、独立した拡張、独立した災害復旧およびダウングレードを実現するために、サービスが分割されることがよくあります。

マイクロサービスの分解は、動きではなく、結合の問題点に遭遇したときに継続的に解決し進化するプロセスである必要があります。

マイクロサービスが分割された後、複合サービス層にも実装されている複数の操作の原子性を保証するために、分散トランザクションを使用する必要がある場合があります。

ユーザーインターフェース層

ユーザー インターフェイス レイヤーは、エンド カスタマーに提示されるインターフェイスとアプリを指しますが、単なるインターフェイスではありません。

このレイヤーはアクセス レイヤーと呼ばれることもあります。この層では、動的リソースと静的リソースを分離し、静的リソースを CDN を使用してアクセス層にキャッシュする必要があります。

UI と API も分離する必要があり、インターフェースは結合された API を通じてデータを組み立てる必要があります。 API は、統合された API ゲートウェイを通じて一様に管理および制御されます。

一方、バックエンド複合サービス層の分割は APP に対して透過的です。一方、同時実行ボリュームが比較的大きい場合、このレイヤーで電流制限と劣化を実装できます。

これら 6 つのレベルをサポートするために、上図の左側にはいくつかの共通機能があります。

• 継続的インテグレーションと継続的リリースは、マイクロサービス分割プロセス中の迅速な反復を保証し、変更後も新しいバグを導入することなく機能が変更されないことを保証するためのものです。
• サービス検出とサービス ガバナンスは、マイクロサービス間の相互呼び出し、および呼び出しプロセス中に異常が発生した場合の回路ブレーカー、電流制限、および劣化戦略です。
• ビッグデータと人工知能は、ユーザーアクセスデータ、ユーザー注文データ、カスタマーサービス問い合わせデータなど、あらゆるレベルのデータを収集し、それらを統一されたミドルプラットフォームと組み合わせて、データを分析し、インテリジェントな推奨を行います。
• 監視と APM はインフラストラクチャとアプリケーションを監視し、リソース レベルの問題やアプリケーション呼び出しの問題を検出できます。

クラウド アーキテクトになるのは、依然として非常に複雑です。千里の道も一歩から始まる。ゆっくりやってみましょう。

クラウドコンピューティングの歴史的進化と基本原則を理解する

クラウド コンピューティングの広大な海に飛び込む前に、まず包括的な理解が必要です。知識を理解する出発点は、その知識の歴史を理解すること、つまり、それが今日の状態に至るまで段階的にどのように発展してきたかを知ることだと考える人もいます。こういった巨大なシステムは、実は段階的に追加されていくものなのです。

このような知識体系は、私たちにとっては冷たい知識ネットワークではなく、生身の人間なのです。私たちは進化の手がかりを追って、その気質を一歩ずつ理解する必要があるだけです。

クラウド コンピューティングをシンプルかつ分かりやすく説明するにはどうしたらよいか長い間考えていましたが、ついに以下の記事を書きました。ついにクラウド コンピューティング、ビッグ データ、人工知能をわかりやすく説明してくれる人が現れました!ここで、核心となるポイントを書いておきます。

まず、クラウド コンピューティングの本質は、リソースからアーキテクチャまで包括的な弾力性を実現することです。

柔軟性とは、時間の柔軟性と空間の柔軟性を指し、いつでも好きなときに好きなだけ柔軟性を得ることができることを意味します。

リソース レベルでの弾力性とは、コンピューティング、ネットワーク、およびストレージ リソースの弾力性を実現することも意味します。このプロセスは、物理マシンから仮想化、そしてクラウド コンピューティングへと進化してきました。

アーキテクチャ レベルでの弾力性とは、一般的なアプリケーションと独自のアプリケーションの弾力的な拡張を実現することも意味します。一般的なアプリケーションの場合、複数の統合が PaaS プラットフォームに統合されます。

独自のアプリケーションには、スクリプトベースの Puppet、Chef、Ansible を使用して、イメージベースのコンテナ プラットフォーム CaaS をコンテナ化します。

2つ目: ビッグデータには、データの収集、データの転送、データの保存、データの処理と分析、データの検索とマイニングなどのいくつかのプロセスが含まれます。

データ量が少ない場合、少数のマシンしかそれを処理できません。徐々にデータ量が増えていき、最高のサーバーでも問題を解決できなくなったら、どうすればいいでしょうか?

現時点では、複数のマシンのパワーを結集する必要があり、全員が協力してこの作業を完了します。みんなが燃料を追加すれば、火はさらに強く燃え上がります。

3つ目: 人工知能は、エキスパートシステムに基づく計画経済、統計に基づくマクロ経済制御、ニューラルネットワークに基づくミクロ経済学という3つの段階を経てきました。

オープンソースソフトウェアは進歩のための強力なツールです

アーキテクトは、大規模なアーキテクチャと理論を習得するだけでなく、実装に関するガイダンスを提供するために必要なスキルも備えている必要があります。つまり、デザインパターンとコードの両方を理解する必要があります。では、こうした優れた、有益で実用的な建築の実践をどこで学べるのでしょうか?

この世界には、特にプログラマーなど、情熱的な人々がまだたくさんいます。彼らは何をするのが好きですか?答えはオープンソースです。多くのソフトウェアはクローズド ソースかオープン ソースのいずれかであり、ソースはソース コードを指します。

ソフトウェアがうまく作られ、誰もがそれを愛用している場合、そのソフトウェアのコードは非公開となり、それを知っているのは自分の会社だけです。他に誰もそれを知りません。他の人がこのソフトウェアを使いたい場合、私に料金を支払う必要があります。これをクローズドソースと呼びます。しかし、世の中には、すべてのお金がひとつの企業によって稼がれているという事実に耐えられない大物たちが常に存在します。

専門家は、あなたがこの技術を持っているなら、私にもできると考えています。あなたが開発できるなら、私にもできます。私は開発費を請求せず、コードを全員と共有します。世界中の誰でも使用でき、誰もがその恩恵を受けることができます。これをオープンソースと呼びます。

オープンソース ソフトウェアのメリットは非常に大きいため、オープンソース ソフトウェアを理解し、深く研究し、さらには貢献することを強くお勧めします。

まず、オープンソース ソフトウェアを通じて、大手企業のアーキテクチャの原則と設計パターンを理解できます。

実際、日々の仕事の中で大物に出会うのは非常に難しいことです。彼は、あなたが憧れながらも手の届かない会社の社員なのかもしれません。海外でも、そういった企業に入りたければ、数年間にわたって質問の練習をし、N回の面接を受けなければ入ることはできません。

たとえ入社できたとしても、その人は会社の幹部で毎日とても忙しいので、あまり頻繁に会うことはないでしょう。直接相談しても時間があまり取れず、深いコミュニケーションを取るのは難しいでしょう。

大物の中には、自分でビジネスを始めたり、フリーランサーになることを選択する人もいます。彼らはとらえどころがなく、大企業でも見つけることができません。

しかし、インターネットとオープンソース コミュニティのおかげで、マスターが私たちのもとにもたらされました。メーリング リストを購読したり、ディスカッション グループに参加したり、マスターのデザインを確認したり、多くの人のコメント、質問、マスターからの回答を確認したり、マスターのデザインが一夜にして完璧になるわけではないことを確認したり、段階的な進化のプロセスを確認したりすることができます。

これらは、私たちのスキルを迅速に向上させるのに役立つ領域です。デザインを入手すると、長い時間情報を調べなければならないことがあります。最初は多くの用語が理解できないかもしれません。一生懸命働く意欲がある限り、それは問題ではありません。設計図がどんどんスムーズに読めるようになったら、進歩したことになります。

2 つ目: オープンソース ソフトウェアを通じて、コードレベルの実装方法を学ぶことができます。

時には、有名人が書いた本や記事をたくさん目にしたり、理論的な本をたくさん見たりしますが、理論は理解できても、アーキテクチャをうまく実行できないという問題があります。

なぜなら、コードを見なければ、すべての理論は空論に過ぎないからです。具体的なコード設計レベルに到達すると、学習した設計パターンを自分の実践に応用できなくなります。

幸いなことに、オープンソース ソフトウェアのコードはすべて公開されており、専門家の努力の成果が体現されています。専門家が実装する際に行った選択も確認できます。すべてがとてもリアルで、目に見えるし、触れることもできます。

コードを通じて学習することで、理論的な知識と組み合わせることで直接的な経験を積みやすくなり、コードを設計して記述するときに、それを参照シナリオにすぐにマッピングできるため、独自のシステムを構築するときに回り道を回避できます。

3 つ目: オープンソース ソフトウェアを通じてコミュニティに参加し、同じ状況にある他の技術者と共に進歩することができます。

私たちにとって専門家と接触することは容易ではないことが多く、技術的な問題を直接話し合う時間はさらに貴重です。しかし、それは問題ではありません。オープンソース ソフトウェアは、誰もが一緒に議論できるコミュニティを構築します。

あなたはそれをどう理解しますか、そして他の人はそれをどう理解しますか?議論し、コミュニケーションをとればとるほど、より明確になります。場合によっては、専門家に直接話すよりも、自分よりも少しだけ経験のある技術スタッフとコミュニケーションをとる方が効果的であることがあります。

専門家の言うことを理解するのに長い時間がかかるかもしれませんが、それでも専門家の言っていることが理解できないことがあります。専門家は、多くの一般人が感じる困難は明白であると考え、わざわざ説明しようとしないかもしれません。

ただし、コミュニティの技術スタッフはあなたと同じようにゆっくりと上達しており、過去にどのような点があなたを混乱させたかを知っている可能性があります。これらの落とし穴に陥った場合は、何らかの導きが得られ、突然光が見えてくるでしょう。

さらに、人によって遭遇する具体的な状況は異なり、働く業界も異なり、顧客のニーズも異なるため、ソフトウェアを設計する際に考慮される要素も異なります。

専門家は素晴らしいですが、必ずしもあなたと同じシナリオに遭遇するとは限りません。ただし、コミュニティにはあなたと同じ業界で同様の背景を持つ技術者がいるので、特定のシナリオに適したソリューションについて話し合うことができます。

4つ目: オープンソースソフトウェアのおかげで、私たち個人が仕事を見つけやすくなります。

面接の際、よく聞かれる質問は、前職での貢献、理解、デザイン、技術力をどのように示すか、ということです。

実際、多くのプログラマーはこれをうまく実行できず、面接で不利な立場に立たされる人が多いことがわかりました。

理由の 1 つは、背景情報が非対称であることです。たとえば、難しいビジネス上の問題に直面したとき、面接官は応募者が背景を理解しておらず、短時間で明確に説明できないため、応募者のレベルを過小評価してしまいます。

また、ほんの数分話を聞いただけで「これはとても簡単なことではないですか。これやあれをやればいいだけですよ」と言って、チームが 3 年間取り組んできたことを完全に否定するような面接官にもたくさん会いました。

理由 2: 有能なプログラマーの多くは自分自身を表現できず、その結果、実際にコードを書く人も自分自身のことを明確に説明できなくなります。おそらく、会社内では 1 人のパフォーマンスが非常に優れていて、もう 1 人のパフォーマンスが非常に低かったのですが、面接官に会ったときに 2 人のパフォーマンスは同等になったのです。

理由 3: 新しい会社は、前の会社で行った仕事がこの会社でも使えるかどうか確信が持てません。たとえば、仕事の 30% が特定のビジネス シナリオに関連し、70% が一般的なテクノロジに関連する場合、次の会社は一般的なテクノロジの部分に対してのみ支払いを行う可能性があります。

オープンソース ソフトウェアの利点は、参加者が習得したスキルが共通であり、全員が同じコンテキストでコミュニケーションをとるため、面接官と候補者間の情報格差が少なくなることです。特定のオープンソース ソフトウェアを習得することがいかに難しいかは、応募者が自ら言うまでもなく、誰もが知っています。

技術的能力は高いが表現力が弱いごく少数の人々にとって、話は安いのでコードを見せてください。

コードを提出することで、自分の能力を証明でき、面接官はたった 30 分でその人のことを知る必要がなくなり、多くの経歴調査を行うことができます。

また、習得した技術は汎用性が高いため、次の企業に行ったときにもウォーミングアップの時間がほとんど必要なく、すぐに業務に取り掛かることができ、双方にとってメリットがあります。

5 番目: オープンソース ソフトウェアを使用すると、採用担当者である私たちにとって、適切な人材を採用しやすくなります。

スタートアップで働いたことがある友人なら、スタートアップでは人材の採用が難しく、スタッフの入れ替わりが早く、全員が時間と競争しているため、開発要件が非常に厳しいことが多いことを理解しているでしょう。

したがって、オープンソース ソフトウェアは雇用主にとっても朗報です。まず第一に、スタートアップ企業は大企業ほど多くの技術専門家を抱えて、独自の完全なシステムを実装することはできません。オープンソース ソフトウェアを使用してプラットフォームを迅速に構築し、オンラインにするのが最善の選択肢です。

第二に、オープンソースソフトウェアを使用すると、採用が比較的容易になります。市場で人気のあるオープンソース ソフトウェアには、さまざまなフォーラムやコミュニティに参加する実践者が多数いるため、人材の募集が容易になります。

最後に、オープンソース ソフトウェアを使用すると、新規参入者はウォーミング アップに時間を費やす必要がなく、すぐに作業を開始できるため、開発のスピードが保証されます。

では、オープンソース ソフトウェアをすぐに使い始めるにはどうすればよいでしょうか?次の 9 つのステップをまとめました。

• 手動インストール。手動で行う必要があります。
• 使ってみて、XXX in Actionシリーズをおすすめします。
• 文書を読んでください。公式文書はすべて読んでください。たとえ覚えていられなかったり、理解できなかったとしても、読まなければなりません。
• 中核となる原則とアルゴリズムを理解するには、XXX 決定版ガイド シリーズをお勧めします。
• ソースコード分析に関する本を読むと、ソースコードを読む作業がより効率的になります。
• コアロジックのソースコードの読み取りを開始します。
• ソースコードをコンパイルしてデバッグします。
• プラグインを開発するか、コンポーネントに小さな変更を加えます。
• 豊富な運用および保守経験と、実際のシナリオに合わせたカスタマイズされた開発。
• したがって、クラウド アーキテクトはコードから離れるのではなく、常にオープン ソース ソフトウェアを採用する必要があります。

Linuxの基礎を学ぶ

クラウド アーキテクトとして最初にすべきことは、Linux の基本的な知識と原則に精通することです。

オペレーティング システムに関しては、一般的に次の 3 つの側面があります。

• デスクトップ オペレーティング システム
• モバイルオペレーティングシステム
• サーバー オペレーティング システム

Stack Overflow Developer Survey 2018 にはそのような統計があります。開発者にとって、デスクトップ オペレーティング システムのランキングは Windows、MacOS、Linux であるため、ほとんどの人の日常的なオフィス システムは Windows です。

もちろん、オフィスの都合上、Windows がより頻繁に使用されるため、学校では多くの学生が基本的に Windows オペレーティング システムに触れますが、コンピュータ業界で働くと、Linux のハードルを乗り越えなければなりません。

今年の W3Techs の統計によると、Unix 系 OS がサーバー側の約 70% を占めています。いわゆる Unix 系 OS には、下図に示すように、Linux、BSD、およびその他の一連の OS が含まれます。

この統計から、クラウド コンピューティング、ソフトウェア SaaS、サービス指向、さらにはマイクロサービス指向の発展により、コンピューティングの大部分がサーバー側で実行されることがわかります。したがって、クラウド アーキテクトになるには、Linux を理解する必要があります。

モバイルインターネットの発展に伴い、クライアントは基本的に Android と iOS になりました。下の図はガートナーの統計です。

Android は Linux カーネルをベースにしています。そのため、クライアントも Linux 陣営に参入し、スマート端末、スマートデバイスなどの開発職種では Linux を理解している人材を求めるケースが多くなっています。

Linux の学習は主に 2 つの部分から成ります。1 つは Linux の使い方、もう 1 つはプログラミング方法とその背後にある原理です。

使い方としては、まずは「Bird Brother's Linux Private Recipe」がおすすめです。このマニュアルに従って、Linux の基本的な使い方を学ぶことができます。さらに深く学びたい方には、Linux の運用・保守に必須の分厚い本『Linux システム管理技術マニュアル』をお勧めします。

プログラミングのやり方については、まずはコードや入門書、原理などが載っている「Advanced Programming in Unix Env​​ironment」をお勧めします。カーネルの原理に興味があるなら、「Linux カーネルの徹底理解」をお勧めします。

Linux のアーキテクチャは次のとおりです。

物理マシンには多くのハードウェアがあり、その中で最も重要なのは CPU、メモリ、ハードディスク、ネットワークであることはご存じのとおりです。しかし、物理マシンでは多くのプログラムを実行する必要があるため、これらのリソースを誰が使用すべきでしょうか?もちろん、全員が交代で使用してください。誰もそれを独占すべきではなく、誰も飢え死にすべきではない。

このタスクを実行するために、オペレーティング システムのカーネルはハウスキーパーの役割を果たし、ハードウェア リソースをさまざまなユーザー プログラムに割り当て、適切なタイミングでリソースを取り戻して他のユーザー プロセスに割り当てます。このプロセスはスケジューリングと呼ばれます。

オペレーティングシステムの機能の1つ：システムコール

ユーザー プログラムがリソースを要求する場合、カーネルとユーザー モード プログラムの境界線であるオペレーティング システムのシステム コール インターフェイスを呼び出す必要があります。

タクシーに乗りたいときと同じように、タクシー アプリのインターフェースからタクシーの指示を送信して、タクシー アプリが車を配車できるようにする必要があります。

オペレーティングシステムの2番目の機能：プロセス管理

ユーザー プロセスが実行されている場合、カーネルはプロセスにリソースを割り当てます。また、このプロセスに割り当てられているリソースを格納するデータ構造が常に存在する必要があります。このプロセスに割り当てられるリソースには、多くの場合、開いているファイル、メモリ領域などが含まれます。

オペレーティングシステムの3番目の機能: メモリ管理

各プロセスには独立したメモリ領域があり、倉庫のようにプロセスによってデータを格納するために使用されます。

プロセスの使用の便宜上、各プロセス メモリ空間はプロセスの観点から独立しており、つまり、倉庫 0、倉庫 1、倉庫 N まですべて排他的です。

しかし、オペレーティングシステムカーネルの観点から見ると、それを独占的に享受することは当然不可能であり、全員で共有することになります。 M倉庫は1つしかなく、使用している場合は使用できなくなります。これには、ユーザー プロセスの倉庫番号と実際に使用される倉庫番号を一致させる倉庫スケジューリング システムが必要です。

例えば、工程 1 の倉庫番号 10 は実際の倉庫番号 110 に対応し、工程 2 の倉庫番号 20 は実際の倉庫番号 120 に対応します。

オペレーティング システム機能 4: ファイル システム

Linux の場合、多くのものがファイルです。たとえば、プロセス番号はファイルに対応し、ネットワーク接続の確立もファイルに対応します。さまざまなファイルシステムが存在します。これらを均一に適応させるために、仮想ファイルシステムの中間層 VFS が存在します。

オペレーティング システム機能 5: デバイス管理

デバイスには 2 種類あり、1 つはブロック デバイス、もう 1 つはキャラクター デバイスです。たとえば、ハードディスクはブロックデバイスであり、ファイルシステムにフォーマットできます。もう 1 つの例として、マウスとキーボードの入出力は文字デバイスです。

オペレーティング システム機能 6: ネットワーク管理

Linux の場合、ネットワークもデバイスとファイル システムに基づいていますが、ネットワークには独自のプロトコル スタックがあるため、TCP/IP プロトコル スタック標準に従う必要があります。

データセンターとネットワークの基礎を理解する

クラウド プラットフォームは、もちろんデータ センターに展開されます。データセンター内のハードウェア設備も非常に専門的であるため、多くの場所ではコンピュータ室部門とクラウドコンピューティング部門が 2 つの部門になっています。

ただし、クラウド アーキテクトはコンピュータ ルーム部門とコミュニケーションを取る必要があるため、一定のデータ センターの知識が必要です。データセンターで最も扱いが難しいのはネットワークなので、ネットワークに関する知識が最も重要になります。

次の図は、典型的なデータ センターの図です。

最も外側の層はインターネット エッジ (エッジ ルーターまたは境界ルーターとも呼ばれます) で、データ センターとインターネット間の接続を提供します。

最初の層であるコア ネットワークには、多数のコア スイッチが含まれます。

• 利用可能ゾーンとエッジ ルータ間の通信。
• 利用可能なゾーン間の通信が提供されます。
• 高可用性接続 HA を提供します。
• 侵入防止サービスを提供します。
• 分散型サービス拒否攻撃の分析と軽減を提供します。
• ティア1ロードバランサーを提供する

各 AZ の最上位層である 2 番目の層は、集約層と呼ばれます。

3 番目の層はアクセス層であり、アクセス スイッチによって接続されたサーバーのラックで構成されます。

これは、アクセス層、集約層、コア層という典型的な 3 層ネットワーク構造です。データセンターだけでなく、アプリケーションアーキテクチャに取り組む場合でも、ネットワークの理解が必要です。

クラウド アーキテクチャは、究極的には分散アーキテクチャです。分散型であるため、非中央集権化されており、システムはネットワークを介して相互に通信する必要があります。そのため、大規模システムアーキテクチャとしてはネットワークは避けて通れないハードルとなります。

ネットワークの基本原則については、「Computer Networks - Translated by Yan Wei and Pan Aimin」および「Computer Networks: A Top-Down Approach」という書籍をお勧めします。

TCP/IP プロトコル スタックを理解するには、「TCP/IP 詳解」と「TCP/IP ガイド」が推奨される書籍です。

ネットワークプログラミングについては、「Unix ネットワークプログラミング」という本をお勧めします。ネットワーク プロトコル スタックの実装を理解したい場合は、「Linux ネットワーク インサイダーの詳細な理解」という本をお勧めします。

KVM に基づくコンピューティング仮想化の理解

物理マシンが構築されたら、次のステップは物理マシンに基づいて仮想マシンを構築することです。

仮想マシンについて知らない学生は、VirtualBox または Vmware を使用してラップトップ上に仮想マシンを作成できます。物理マシンのオペレーティング システム内に複数のオペレーティング システムをインストールするのは簡単であることがわかります。

この方法では、Windows オフィス システム内に Linux システムを簡単にインストールできるため、Linux システムの継続的な学習を維持できます。

先ほど Linux オペレーティング システムについて説明した際に、オペレーティング システムはシステム全体の管理人であると述べました。アプリケーションがリソースを申請する場合、オペレーティング システムのシステム コール インターフェイスを使用して、オペレーティング システム カーネルに CPU、メモリ、ネットワーク、ハード ディスクなどのリソースを割り当てるように要求する必要があります。

この時点で、仮想マシンも物理マシン上の通常のプロセスであることがわかります。仮想マシン内のアプリケーションがリソースを要求する場合、仮想マシンのオペレーティング システムに要求する必要があります。

ただし、仮想マシンのオペレーティング システム自体にはリソースを操作する権限がないため、物理マシンのオペレーティング システムからリソースを申請する必要があります。

これには追加の変換タスクが必要であり、このタスクを実行するソフトウェアは仮想化ソフトウェアと呼ばれます。たとえば、前述の VirtualBox と Vmware はどちらも仮想化ソフトウェアです。

ただし、翻訳のレイヤーが 1 つ増えると、パフォーマンスの低下も 1 つ増えます。仮想マシン内のすべての操作を翻訳する必要があり、ハードウェアを直接操作できない場合、パフォーマンスははるかに悪化し、単に使用できなくなります。したがって、上記の図に示されているハードウェア支援仮想化が表示され、特別なハードウェア構成によって達成されます。

たとえば、VT-XとVT-Dは、仮想マシンのオペレーティングシステムに、もはやネイティブオペレーティングシステムではなく、仮想マシンオペレーティングシステムであることを知らせます。元のモードでリソースを操作することはできなくなりましたが、代わりに特別なドライバーを使用してショートカットを撮影し、ハードウェア支援の方法で物理リソースを操作します。

私がちょうど話したのは、デスクトップ仮想化でした。これはあなたのラップトップでの意味です。データセンターでは、VMwareを仮想化に使用することもできますが、比較的高価です。スケールが大きい場合は、オープンソース仮想化ソフトウェアQEMU-KVMが使用されます。

QEMU-KVMの場合、原則は上記と同じであり、QEMUのEMUは翻訳の意味であるエミュレーターを意味します。

KVMはCPUハードウェア支援仮想化を使用する方法ですが、ネットワークとストレージには、高性能デバイス仮想化機能を提供するために特別なVirtioメソッドが必要です。

仮想化の基本原則を理解するために、「システム仮想化 - 原則と実装」という本をお勧めします。 KVMを理解するには、2冊の本「KVM Virtualization Cookbook」と「Mastering KVM Virtualization」をお勧めします。

さらに、KVMとQEMUの公式文書も必読であり、Redhatの公式Webサイトには、学習する価値のある記事がたくさんあります。

OpenVswitchに基づいたネットワーク仮想化の理解

仮想マシンが作成されると、最も重要な要件は、インターネットにアクセスしてオンラインリソースにアクセスできることです。 Webサイトが仮想マシンに展開されている場合、他の人がそれにアクセスできることも期待されています。

一方で、これはQEMU-KVMのネットワーク仮想化に依存して、仮想マシンから仮想マシンの外側にネットワークパケットを送信します。これには、仮想マシン内のネットワークカードと仮想マシンの外側の仮想ネットワークカードを形成するために、物理マシンカーネルの変換が必要です。

別の側面は、仮想マシンのネットワークを物理ネットワークに接続する方法です。物理ネットワークはしばしばアンダーレイネットワークと呼ばれ、仮想ネットワークはオーバーレイネットワークと呼ばれます。

物理ネットワークから仮想ネットワークへの移行はネットワーク仮想化と呼ばれ、OpenVswitchと呼ばれる仮想スイッチソフトウェアはこのタスクを非常にうまく達成できます。

OpenVswitchには、物理​​ネットワークカードを監視し、物理ネットワークカードに受け取ったパケットを持ち込むことができるカーネルドライバーがあります。

仮想マシンによって作成された外部仮想ネットワークカードもOpenVswitchに追加することもでき、OpenVSwitchはさまざまなネットワークパケット処理戦略を設定して、仮想マシンと物理マシン間でネットワークパケットを転送し、それによりネットワーク仮想化を実現できます。

OpenVswitchについては、主に公式文書を通じて調査しました。

OpenStackに基づいたクラウドプラットフォームの理解

仮想マシンを手に入れてインターネットにアクセスできるようになったら、次のステップはクラウドプラットフォームを構築することです。

クラウドは、コンピューティング、ネットワーク、およびストレージ仮想化テクノロジーに基づいています。クラウドと仮想化の主な違いは、管理者の管理モードが異なり、ユーザーの使用モードも異なることです。

仮想化プラットフォームには、マルチレベルでリッチなテナント管理、柔軟なクォータの制限、または柔軟なQoS制限がありません。

仮想ネットワークと物理ネットワークを接続するブリッジングモードがよく使用されます。仮想マシンは、コンピュータールームネットワークを直接使用します。仮想サブネットVPCの概念はありません。仮想ネットワークの管理と分離は、テナント分離で完全にマッピングすることはできません。

ストレージにも同じことが言えます。会社が統一されたストレージを購入したとしても、テナントの分離に完全にマッピングすることはできません。

仮想化プラットフォームを使用する特徴は、このプラットフォームの運用が運用および保守部門によって完全に管理されており、当局をビジネス部門に委任して自分で運営することはできないことです。

異なる部門が独力で動作することが許可されると、誰もがコンピュータールームネットワークを使用し、統一された管理と制御がなければ、ネットワークセグメントの競合が発生する可能性があります。

事業部門が仮想マシンを申請したい場合は、作業注文を通じて統一されたアプリケーションを運用および保守部門に提出する必要があります。もちろん、運用および保守部門は、このアプローチに非常に慣れています。これは、物理マシンが元々管理されていた方法だからです。

しかし、AWSなどのパブリッククラウドはこれを行うことはできません。何千ものテナントがあり、彼らは自分でしか操作できません。

プライベートクラウドでは、サービス指向およびマイクロサービス指向の開発の進歩により、サービスの数が増加し、反復速度がより速く速くなります。ビジネス部門は、仮想マシンをより頻繁に作成して消費する必要があります。運用および保守部門が依然として統一された承認と運用を担当している場合、運用およびメンテナンス部門に大きな圧力がかかります。

また、反復速度も大幅に制限されるため、テナント管理を導入する必要があります。操作およびメンテナンス部門は、各テナントの割り当てとQOを柔軟に構成できます。このクォータ内で、ビジネス部門は、運用およびメンテナンス部門に通知することなく、そのニーズに応じていつでも仮想マシンを作成および削除できます。

各部門は独自の仮想ネットワークVPCを作成でき、異なるテナントのVPCは完全に隔離されています。

したがって、ネットワークセグメントは競合する可能性があります。各ビジネス部門は、独自のネットワークアーキテクチャを計画しています。外部ネットワークまたはコンピュータールームから数個のマシンにアクセスする必要がある場合、いくつかのコンピュータールームIPが必要です。

これはテナントにもマッピングされ、ビジネス部門のコンピュータールームネットワークに割り当てられたIPアドレスの数内で自由に使用できます。このようにして、各部門は独立して動作することができ、反復速度を加速できます。

クラウドプラットフォームのオープンソースソフトウェアの代表はOpenStackです。クラウドで一般的なOpenStackの設計メカニズムを研究することをお勧めします。 OpenStackを理解した後、パブリッククラウドとコンテナクラウドの同様の概念とメカニズムを見つけることができます。

OpenStackの調査を通じて、非常に優れたクラウドプラットフォームのデザインパターンを見つけることができます。

最初：PKIトークンベースの認証モード

RESTFUL APIを実装し、統一された認証センターを持ちたい場合は、Keystoneの三角形の作業モードが一般的に使用されます。

リソースにアクセスしたい場合は、ユーザー名とパスワード、またはAK/SKでログインした後、認証が成功した場合は、常にユーザー名とパスワードを使用してリソースにアクセスする必要があります。代わりに、ログインするときにトークンを生成し、リソースにアクセスするときにトークンを使用する必要があります。サーバーはトークンを使用して、認証センターで検証できます。

検証ごとに認証センターにアクセスする必要がある場合、効率は比較的低くなります。その後、PKIトークンが導入されました。つまり、復号化されたトークンは、詳細なテナント情報を備えた文字列であるため、認証と承認をローカルで実行できます。



2番目：ロールベースのアクセス制御に基づく認証モード

許可制御のために、より一般的なロールベースのアクセス制御許可制御モードを学び、「ユーザーロール許可」承認モデルを形成しました。

このモデルでは、一般に、ユーザーと役割の間に、および役割と権限の間には多くの多くの関係があり、これにより、許可を非常に柔軟に制御できます。

3番目：クォータベースのクォータ管理

コンピューティング、ネットワーク、ストレージのクォータを設定することにより、テナントが独立して動作できるリソースの量を設定できます。

4番目：事前選択と最適化に基づくスケジューラメカニズム

リソースプールからノードを選択し、このノードのリソースを使用する必要がある場合、一般的なスケジューラメカニズムは次のとおりです。

まず、事前選択が実行されます。つまり、条件を満たさないフィルターが除外されます。

そして、それが望ましい、つまり、フィルタリング後に状態を満たしている候補者にとって、彼らは重量を計算して最良の候補を選択することができます。

5番目：独立した仮想サブネットに基づくネットワークモード

各テナントが独立して動作するためには、仮想ネットワークは物理ネットワークから独立している必要があります。そうすれば、異なるテナントが互いに影響を与えることなく独立したネットワーク計画を実行したり、物理ネットワークに影響を与えたりすることができません。クロステナントアクセスが必要な場合、または物理ネットワークにアクセスする必要がある場合、ルーターを通過する必要があります。

6番目：書き込みベースのミラーリングメカニズムをコピーします

仮想マシンで操作を行った後、この時点でミラーを保存して、いつでもこの時点に復元できるようにしたい場合があります。最も簡単な方法は、完全にコピーすることですが、ミラーが大きすぎるため、効率は非常に貧弱です。

したがって、書き込みメカニズムのコピーが採用されています。画像がミラーリングされている場合、新しいストレージ消費はありません。代わりに、新しいものを書くときは、元のデータをコピーして保存する場所を見つけます。これは書き込みのコピーです。

OpenStackの場合、採用するQCOW2をミラーリングするメカニズムがあります。

このミラーリングは、レイヤーごとにリストされたレイヤードのようなものです。

7番目：名前空間とcgroupに基づく分離とQoSメカニズム

OpenStackでは、ネットワークノードのルーターがネットワークネームスペースによって分離されます。

KVMが占有するCPUとメモリは、CGROUPを使用して分離されます。

ネットワークのQOSは、TCを使用して分離されています。

8番目：iptablesに基づくセキュリティメカニズム

ネットワーク内のノードが互いにアクセスできないことを願っています。最も単純なファイアウォールとして、iPtablesは重要な役割を果たします。将来、ACLメカニズムを実装する人は、iPtablesの使用を検討できます。

MesosとKubernetesに基づいてコンテナプラットフォームを理解します

仮想化レイヤーとクラウドプラットフォームレイヤーを構築した後、次のステップはコンテナレイヤーです。 Dockerにはいくつかのコアテクノロジーがあり、1つはミラーリングであり、もう1つはランタイムであり、孤立しているように見える名前空間に分割され、使用すると分離されたCgroupです。

Dockerの画像は、書き込み画像形式のコピーでもあります。次のレベルは読み取り専用であり、すべての書き込みはトップレベルにあります。

ランタイムの場合、Dockerは、次の表に示すように、ネットワーク名空間に加えて他の多くの名前空間を使用します。

Dockerは、Dockerを実行するときにCGROUPSを使用し、パス/SYS/FS/CGROUP/CPU/DOCKER/DOCKERを実行するときにコンテナが使用するリソースを制御します。

コンテナは新しいテクノロジーを使用するのではなく、新しい配信方法、つまりアプリケーションの配信をコンテナミラーで配信する必要があることがわかります。容器が起動したら、さまざまな変更のためにコンテナに入らないでください。これは不変のインフラストラクチャです。

コンテナ画像にはオペレーティングシステムのカーネルが含まれていないため、はるかに小さく、環境交差の移動と弾性スケーリングが可能になります。

コンテナを使用すると、次のステップはコンテナプラットフォームを選択することです。実際、Swarm、Mesos、およびKubernetesには独自の利点があり、さまざまな段階で異なるコンテナプラットフォームを使用することもできます。

MESOSベースのDCOは、コンテナ管理プラットフォームというよりもデータセンター管理プラットフォームに似ています。 Kubernetesオーケストレーションと互換性があり、さまざまなビッグデータアプリケーションを実行することもできます。

コンテナフィールドでは、Kubernetesベースのコンテナオーケストレーションが事実上の標準になりました。

Kubernetes管理コンテナパターンを掘り下げると、おなじみの顔も見ることができます。

Kubernetesでは、テナントは名前空間によって分離されます。これはDockerの名前空間ではなく、Kubernetesの概念です。

APIサーバーの認証は、ロールベースのアクセス制御モードにも基づいています。 kubernetes for namespaceには、ResourceQuotaを使用したクォータ構成もあります。

Kubernetesがポッドを実行するノードを選択したい場合、選択プロセスは2つの段階も渡されます。

プレセレクト（フィルタリング）

• podfitsResourcesはリソースを満たします。
• podselectormatchesはラベルに準拠しています。
• Podfitshostはノード名に準拠しています。

重み付け

• リアストレストプリアリティリソースの消費は最小限です。
• バランスリソーシールロケーションで最もバランスのとれたリソース使用量。

Kubernetes次のネットワークモデルの定義を指定します。

• すべての容器は、NATを使用せずに他のコンテナと通信できます。
• すべてのノードは、NATを使用せずにすべてのコンテナと通信できます。
• コンテナのアドレスは、他の人が見たアドレスと同じです。

つまり、コンテナプラットフォームには独自のプライベートサブネットが必要であり、一般的に使用されるものはフランネル、Calico、OpenVswitchです。

図フランネルに示すように、オーバーレイを使用できます。

図Calicoに示すように、BGPを使用することもできます。

HadoopとSparkに基づいてビッグデータプラットフォームを理解します

データアーキテクチャの部分では、実際には3つのプロセス、つまりHadoop Map-Reduce 1.0、YarnベースのMap-Reduce 2.0、およびSparkです。

次の図は、Map-Reduce 1.0のプロセスを示しています。

Map-Reduceプロセスは大きなタスクを回し、複数のマップタスクに分割され、複数のマシンに広がり、並行して処理し、プロセス結果をローカルで保存します。第2段階では、削減タスクは中間結果をコピーし、結果を集中的に処理し、最終結果を取得します。

Map-Reduce 1.0では、タスクを実行する方法は1つしかありませんでした。複雑なシナリオに対処するために、タスクスケジューリングとリソーススケジューリングは2つのレイヤーに分割されました。

リソースへの呼び出しは糸によって行われます。マップであろうと削減であろうと、要求する限り、無料のリソースが割り当てられたフリーリソースを見つけます。

各タスクが開始されると、アプリケーションマスターが特別に起動され、マップと削減を把握するタスクスケジューリングを管理します。これは、以下に示すように、Map-Reduce 2.0です。

ここでは、糸はアウトソーシング会社のボスに相当します。すべての従業員は労働者であり、彼のリソースです。アウトソーシング会社のボスは、彼が引き受けるすべてのプロジェクトを知っているわけではありません。

アプリケーションマスターは、彼が取る各プロジェクトのプロジェクトマネージャーと同等です。彼はプロジェクトの特定の状況を知っています。彼がプロジェクトを実行するとき、従業員が働く必要がある場合、彼はアウトソーシング会社のボスに申請する必要があります。

Yarnは、Map-Reduce 2とSparkを実行できる一般的なスケジューリングプラットフォームです。

Sparkは、スケジュールタスクのSpark独自のアプリケーションマスターも作成します。

Sparkがより速くなる理由は、初期段階でうまく行われているからです。それはMap-Reduceのようなものではありません。これは、タスクが割り当てられ、集約されたタスクが割り当てられ、集約されたたびにハードディスクを書き込む必要があります。代わりに、タスクを複数の段階に分割し、すべてのマップを1つの段階に組み合わせて、中央にディスクを落とす必要はありませんが、マージする必要がある場所に関しては、ディスクを落とす必要があります。

LuceneとElasticsearchに基づいた検索エンジンについて学びます

ビッグデータが処理されると、通常は2つの場所で保存されます。 1つはフォワードインデックスで、HBase、Cassandra、その他のドキュメントを使用して保存でき、もう1つは簡単な検索のためのリバースインデックスであり、Luceneに拠点を置くElasticsearchで保存されます。

スプリングクラウドに基づいてマイクロサービスを理解します

最後に、アプリケーションアーキテクチャ、つまりマイクロサービスになります。次に、マイクロサービスアーキテクチャデザインで知られている必要があるトップ10の重要なポイントについて話しましょう。

デザインポイント1：ロードバランシング + APIゲートウェイ

マイクロサービスを実装する過程で、当社は必然的にサービスの集約と分割に直面します。

バックエンドサービスの分割が比較的頻繁である場合、モバイルアプリとして、さまざまなサービスに異なるリクエストをルーティングするために統一された入り口が必要になることがよくあります。分割と集約が後でどのようになっても、携帯電話に対して透明です。

APIゲートウェイを使用すると、モバイルアプリ側で完了する必要がないように、モバイルアプリの消費電力が少なくなり、ユーザーエクスペリエンスが向上するように、単純なデータ集約をゲートウェイレイヤーで完了することができます。

統一されたAPIゲートウェイを使用すると、統一された認証と認証を実行できます。サービス間の相互呼び出しはより複雑ですが、より多くのインターフェイスがあります。

APIゲートウェイは、多くの場合、必要な外部インターフェイスのみを公開し、インターフェイスで統一された認証と認証を実行するため、内部サービスが互いにアクセスすると、再度認証と認証する必要がなくなり、効率が比較的高くなります。

Unified API Gatewayを使用すると、このレベルで特定の戦略を設定し、A/Bテスト、青緑色のリリース、事前発行環境交通の転換などを実行できます。APIゲートウェイはしばしばステートレスであり、外側にスケーリングできます。

キーポイント2：ステートレスおよび独立したステートフルなクラスター

アプリケーションの移行と水平スケーリングに影響を与える重要な要因は、アプリケーションのステータスです。ステートレスサービスは、この状態を外側に移動し、セッションデータ、ファイルデータ、および構造化されたデータを統一されたバックエンドストレージに移動し、アプリケーションにビジネスロジックのみを含むようにすることです。

Zookeeper、DB、Cacheなど、Zookeeper、DB、Cacheなどの状態は、これらすべてのステートフルなものを非常に集中したクラスターに収束させます。ビジネス全体が2つの部分に分かれています。1つは無国籍の部分であり、もう1つはステートフルな部分です。

ステートレス部分は2つのポイントを達成できます。

• コンピュータールーム、つまり移行をランダムに展開します。
• 弾性拡張と拡張は簡単に拡張できます。

Zookeeper、DB、Cacheなどのステートフルな部分には、独自の高可用性メカニズムがあり、この状態でクラスターを実装するために独自の高可用性メカニズムを使用する必要があります。

ステートレスですが、現在処理されているデータは依然としてメモリになります。現在のプロセスでデータが失われた場合、一部のデータは間違いなく失われます。

これを達成するためには、サービスには再試行のメカニズムが必要であり、インターフェイスには等容量メカニズムが必要です。サービス発見メカニズムを通じて、バックエンドサービスの別のインスタンスを1回呼び出すことができます。

設計ポイント3：データベースの水平スケーリング

データベースは最も重要であり、ボトルネックを持っている可能性が最も高いです。分散データベースを使用すると、ノードの増加とともにデータベースのパフォーマンスを直線的に増加させることができます。

分散データベースの最も重要なことはRDSであり、これがメインでスタンバイです。 MySQLのカーネル開発機能を通じて、マスターとスタンバイを切り替えるときにデータの損失がゼロを達成できます。

したがって、このRDSに陥ることは非常に安全です。ノードが吊り下げられていても、スイッチが完了した後はデータが失われません。

さらに上にあるのは、大きなスループットを水平に運ぶ方法の問題です。 LV、Haproxy、KeepAlived、およびクエリサーバーの層を使用して、上記のNLBのバランスを緩和する負荷バランスがあります。

クエリサーバーは、監視データに基づいて水平方向にスケーリングできます。障害が発生した場合、ビジネスレイヤーの認識なしに、いつでも交換および修理できます。

もう1つは、デュアルコンピュータールームの展開です。 DDBは、異なるコンピュータールームで異なるDDBを同期させることができるデータ運河NDCのコンポーネントを開発しました。

現時点では、1つのデータセンターに配布されるだけでなく、複数のデータセンターのデュアルアクティブに似たバックアップもあり、高可用性が非常に良い保証があります。

デザインポイント4：キャッシュ

キャッシングは、高い並行性シナリオで非常に重要です。データができるだけユーザーに近づくように、階層キャッシュが必要です。データが近いほど、ユーザーが運ぶことができる並行性が大きく、応答時間が短くなります。

モバイルクライアントアプリにキャッシュのレイヤーがあるはずです。すべてのデータが毎時バックエンドから取得されるわけではありませんが、重要で重要で頻繁に変更されるデータのみです。

特に静的データについては、たまにフェッチすることができ、データセンターからフェッチする必要はありません。 CDNを介してクライアントに最も近いノード上のデータをキャッシュして、近くにダウンロードできます。

CDNがない場合があるため、データセンターに戻ってダウンロードする必要があります。これはソースに呼び出されます。データセンターの最も外側のレイヤーでは、アクセスレイヤーと呼びます。キャッシュのレイヤーを設定して、ほとんどのリクエストをインターセプトして、バックグラウンドのデータベースに圧力をかけないようにすることができます。

動的なデータの場合、アプリケーションにアクセスするか、アプリケーションのビジネスロジックを介して生成するか、データベースから読み取る必要があります。データベースの圧力を減らすために、アプリケーションはローカルキャッシュまたは分散キャッシュを使用できます。

たとえば、MemcachedまたはRedisでは、ほとんどのリクエストはデータベースにアクセスせずにキャッシュを読み取ることができます。

もちろん、動的なデータは静的に調整することもできます。つまり、静的データに格下げされ、バックエンドの圧力が低下します。

設計ポイント5：サービス分割とサービスの発見

システムがアプリケーションに迅速に変化しない場合、より大きなサービスを一連の小さなサービスに分割することを検討する必要があることがよくあります。

これの最初の利点は、開発が比較的独立していることです。多くの人が同じコードリポジトリを維持する場合、コードの変更はしばしば互いに影響を与えます。

多くの場合、私は変更を変更せずにテストに合格することができず、コードを送信する際に競合がしばしばあり、コードマージが必要であるため、開発の効率が大幅に低下します。

もう1つの利点は、オンラインで独立していることです。物流モジュールは新しいエクスプレス会社に接続されており、注文と一緒に立ち上げる必要があります。これは非常に不合理な行動です。

私は変わらず、再起動するように頼みました、私は変更せず、私にリリースするように頼みました、私は変わらず、私に会議を開催するように頼みました、それが分裂する時です。

さらに、多くの場合、高い並行性期間の拡大は、最も重要な注文と支払いプロセスのみがコアです。キートランザクションリンクが拡張されている限り、容量を拡大するには十分です。現時点で他の多くのサービスが含まれている場合、拡張は経済的で危険ではありません。

さらに、災害復旧と格下げは、大きなプロモーション中にエッジとコーナーの関数の一部を犠牲にする必要がある場合がありますが、すべてのコードが一緒に結合されている場合、エッジとコーナーの機能の一部をダウングレードすることは困難です。

もちろん、分割が完了した後、アプリケーション間の関係がより複雑になるため、アプリケーション間の関係を管理し、自動修理、自動関連、自動負荷分散、自動フォールトトレラントスイッチングを実現するためにサービス発見メカニズムが必要です。

設計ポイント6：サービスオーケストレーションと弾性格納剤

サービスが分割された場合、多くのプロセスがあるため、サービスとコードの依存関係を管理するためにサービスオーケストレーションが必要です。これは、インフラストラクチャと呼ばれるサービスの展開です。

このようにして、オーケストレーションファイルを変更することで、リリース、更新、ロールバック、拡張、およびサービスの削減を実現でき、それにより、トレーサビリティ、管理可能性、および自動化機能が向上します。

オーケストレーションファイルはコードリポジトリでも管理できるため、5つのサービスを100のサービスで更新できます。オーケストレーションファイルの5つのサービスの構成を変更するだけです。

オーケストレーションファイルが送信されると、コードリポジトリはアップグレードスクリプトの自動展開を自動的にトリガーし、それによりオンライン環境を更新します。

新しい環境に問題があることがわかったら、もちろん、これらの5つのサービスを原子的にロールバックしたいと思います。オーケストレーションファイルがない場合は、今回アップグレードされた5つのサービスを手動で記録する必要があります。

オーケストレーションファイルを使用して、コードリポジトリで元に戻し、前のバージョンにロールバックしてください。すべての操作はコードリポジトリに表示されます。

設計ポイント7：統一された構成センター

サービスが分割された後、多くのサービスがあります。すべての構成が設定ファイルの形式でアプリケーションフォームにローカルに配置されている場合、管理することは非常に困難です。

数百または数千のプロセスで1つの構成に問題がある場合、それを見つけることは困難であると想像できます。したがって、すべての構成を管理し、統一された構成を発行するには、統一された構成センターが必要です。

マイクロサービスでは、構成はしばしば次のカテゴリに分割されます。

1つのタイプは、ほぼ変わらない構成で、コンテナ画像に直接挿入できます。

2番目のタイプは、起動時に決定される構成です。この構成は、コンテナが開始されると、環境変数を介して渡されることがよくあります。

3番目のカテゴリは統一された構成で、構成センターを介して発行する必要があります。たとえば、大規模なプロモーションの場合、一部の機能を格下げする必要があります。この機能は格下げでき、格下げできない機能はすべて構成ファイルで構成できます。

デザインポイント8：統一ログセンター

多くのプロセスがある場合、ログを表示するために数百のコンテナに1つずつログインすることは困難であるため、ログを収集するには統一されたログセンターが必要です。

収集されたログを分析しやすくするために、ログ仕様には特定の要件があります。すべてのサービスが統一されたログ仕様に準拠している場合、ログセンターでトランザクションプロセスを均一に追跡できます。

たとえば、トランザクション番号を検索する最後のログ検索エンジンでは、プロセスが発生するエラーまたは例外を確認できます。

設計ポイント9：ヒューズ、電流制限、ダウングレード

サービスには、回路を破壊し、電流を制限し、ダウングレードする機能が必要です。あるサービスが別のサービスを呼び出し、タイムアウトが発生すると、その場所でブロックする代わりに時間内に戻り、それによって他のユーザーのトランザクションに影響します。デフォルトのボトムアップデータを返すことができます。

サービスが呼び出されているサービスがビジーであること、スレッドプールがいっぱいであるか、接続プールがいっぱいになっているか、常にエラーがあることを発見した場合、次のサービスのエラーや忙しさのためにサービスが異常になるのを防ぐために時間内に起動する必要があります。

システム全体が実際にロードされすぎていることがわかった場合、最も重要なトランザクションプロセスの通過を確保するために、特定の機能または特定の呼び出しをダウングレードすることを選択できます。最も重要なリソースはすべて、最もコアプロセスを確保するために使用されます。

別の方法は現在の制限です。回路ブレーカーとダウングレード戦略の両方が設定されている場合、システム全体のサポート機能は、フルリンクストレステストを通じて知られる必要があります。

したがって、システムがテストされたサポート機能内でサービスを提供することを保証するために、現在の制限戦略を策定する必要があります。サポート機能を超えると、サービスが拒否される場合があります。

注文すると、システムが「システムがビジーです。もう一度やり直してください」というダイアログボックスを表示します。システムが死んでいるという意味ではありませんが、システムが正常に機能していることを意味しますが、現在の制限戦略が役割を果たします。

設計ポイント10：オールラウンドモニタリング

システムが非常に複雑な場合、統一された監視が必要です。主に2つの側面があります。1つはそれが健康であるかどうか、もう1つはパフォーマンスボトルネックがある場所です。

システムで異常が発生すると、監視システムはアラームシステムと協力して、システムのスムーズな動作を確保するためにタイムリーに発見、通知、介入することができます。

ストレステストの場合、ボトルネックに遭遇することがよくあります。また、ボトルネックポイントを見つけるために包括的な監視が必要であると同時に、サイトを保持できるため、包括的な最適化を追跡および分析し、実行できるようにします。