まず、Amazonのアーキテクチャ要件
分散型サービスアーキテクチャの会社の最も初期の実践は、2002年に戻ってはAWS（アマゾンウェブサービス）を基に表示されなければなりません、次のアーキテクチャ要件を、公布アマゾン、考えることが必要です。
1.すべてのチームは、自社のデータプログラムモジュールを持っていると機能がサービス・インタフェースを介しての道を開きます。
2.チームのプログラムモジュール間の情報通信は、これらのインターフェイスを通過します。
3.さらに、通信の他の手段が存在しません。他の形態でないとできません。直接、（リンクへのダイナミックリンクライブラリなど、他のチームのプログラム）他のチームを他のプログラムをリンクすることはできませんがなど、他の人がバックドアモジュールを使用することはできません、あなたは共有メモリモデルを使用することはできません、データベースを直接読み取ることはできません。唯一の通信手段許さサービスインタフェースを呼び出すことです。
4.任意の技術を使用することができます。たとえば、次のようにHTTP、CORBA、パブ/サブ、カスタムネットワークプロトコル。
5.すべてのサービスインタフェースは、例外なく、外の世界に開くことができるように、表面に骨から設計する必要があります。言い換えれば、チームはどの例外なく、世界にインタフェースするプログラマに、将来のオープンのために良い仕事の計画と設計を行う必要があります。
6.人々は解雇されそうはありません。
先に述べたように、分散システムアーキテクチャは、以下のような問題の多くをもたらすでしょう。
仕事の1つの断層線は異なるサービスと異なるチームの上に輸送中の裏返しでしょう。
2.各チームは、潜在的なDDoS攻撃者になることがあり、各サービスのチェッククォータとしない限り制限します。
3.監視とモニタリングの非常に強力な手段がない限り、トラブルシューティングには、より複雑になり、
4.サービスの発見とサービスの管理が非常に複雑になってきました。
これらの問題に直面し、練習のアマゾン年は、それは分散型サービスアーキテクチャの非常に複雑な操作や保守・管理することができます。主に以下の点で：
1.分散アーキテクチャサービスアーキテクチャは、分散チームが必要です
アマゾン、小さなチームが行ったサービス（2つのピザチーム、2枚のピザがチームを養うことができます）で。データに、操作および保守要件のオンライン分析にフロント。責任分担、労働のではなく、スキルによる除算によります。
2.分散サービスのトラブルシューティングは容易ではありません
より深刻な障害が発生したら、全体的なトラブルシューティングのための必要性。故障のS2の出現は、あなたが行になり、各チームを見ることができます。これは、出席の故障、皆の始まりと自分の自己検査システムでは、作業指示システムで見ることができます。何の問題だけでなく、オンラインスタンバイ（スタンバイ）、およびその問題が解決されていない場合。
3.そこにはフルタイムのテスターはなく、何のフルタイムの運用・保守担当者、開発者がすべてのことを行います
（自分のドッグフードを食べる）、自分のドッグフードを食べる - 開発者の利益はすべてを行うことです。自分のサポートを保護するために独自のコードを書き、そして開発者に知らせて、書き込みコードコードの複雑さを維持しやすいです。これは、コードを書く、設計を行い、需要のアクセスに開発することができ、ソフトウェアの長期的なメンテナンスを行う際に考慮されますツール。
簡素化と自動化を提唱4.運用・保守の優先順位、
非常に大きな努力で、このような複雑なシステム、運用・保守とAmazonの内部ダウンの運用および保守することができるようにします。今、彼らはアマゾンでは、この問題DevOpsチームを言う10年前。AmazonはAmazonが簡単に操作・保守AWSクラウドプラットフォームは、数十の仮想マシンのセットの何百万ものを持って行うことができますのでことを、必死にシステムを簡素化し、自動化し、運用・保守の中で最も強力です。
5.内部サービスおよび外部サービス契約
それは安全面、またはインタフェースの設計からであるかどうか、両方のプロセス、またはトラブルシューティングの操作やメンテナンス面の側面から、Amazonの内部システムと外部システムは、同じように扱われます。これの利点は、内部サービスのシステムは常にそれを開くことができるということです。また、最初の日から、サービスプロバイダーは、外部サービスへの能力を持っています。標準的なオペレーティングチームがどのように見える能力で、想像してみてください。
第二に、必要な注意を分散システムの問題
非標準の質問1.異種システム
異種システムは、標準的な問題は、主に反映されません。
-
- 非標準のソフトウェアおよびアプリケーション
- 非標準の通信プロトコル
- 非標準データ形式
- 開発、運用、保守のプロセスや方法は標準ではありません
異なるソフトウェア、言語は、当然異なった互換性と異なる開発、テスト、運用、保守の基準を持っています。当然のことながら、これは私たちに昇格アーキテクチャの複雑さにつながった開発・運用・保守、異なる方法を作ります。他の人が管理APIを呼び出す必要がありながら、例えば、いくつかのソフトウェア構成の変更は、の.configファイルを変更する必要があります。
通信の観点で、異なるソフトウェアは、たとえ同じプロトコル、データ形式など、異なるプロトコルを使用することができます。異なる技術、開発・運用・保守を使用して別のチームが、同じではありません。これらの違いは、全体の分散システムアーキテクチャが非常に複雑であることを確認してください。したがって、分散型システムアーキテクチャは適切な仕様を有します。ネットワーク通信には、例えば、多くのサービスのAPIエラーがHTTPエラーステータスコードを返しませんが、HTTPボディでJSON文字列で、通常のステータスコード200に戻り、エラーメッセージ。これは、モニターに大きな困難をもたらしました。今、私たちは、闊歩の使用を規制すべきです。
私たちは一例として、ソフトウェア構成管理：会社のソフトウェア構成管理の多くは、キーと値の形です。この柔軟な、非常に柔軟かつ容易に悪用することができる - 非標準、非標準値、あるいは直接コンテンツ表示構成のフロントエンドに指定した構成。
基礎となるオペレーティング・システムおよび関連する中間層と関連ミドルウェア、およびビジネスアプリケーショントップに関連する：良好な構成管理は、3つの層に分割されなければなりません。下と真ん中の層が顧客に修正するが、ユーザーではなくランダムな構成よりも、選択できるようにテンプレートを提供するために、柔軟性を許可することはできません。
別の例では、データ通信プロトコルである、合意プロトコルヘッダとボディが存在するであろう。プロトコルヘッダは、プロトコルは、実際の身体のビジネスデータで、基本的なプロトコルのデータを定義します。私たちは、このプロトコルを使用するすべてのチームが、仕様はプロトコルヘッダを定義して、次の要求が監視、制御および管理に簡単にすることができますしたいです。
システムアーキテクチャ2.サービスの依存関係の問題
マシンにリンクされている従来の単一のアプリケーション、ソフトウェアもハングします。だから、分散アーキテクチャであるかどうか、そのような事が起こるのではないでしょうか？実際には、分散型アーキテクチャ、サービスが依存しています。サービスは、サービスチェーンに依存し、それはドミノ効果を引き起こす可能性があり、ハングアップ。
分散システム、上述したように、依存サービスもいくつかの問題をもたらすでしょう。
-
- 非クリティカルなサービスが重要なビジネスに依存している場合、これは非クリティカルなビジネスクリティカルな操作になります。
- サービス依存チェーンは、「ショートボード効果。」が存在します SLAは、最悪のサービスの全体によって決定されます。
これは、サービスのガバナンスです。サービスガバナンスは、サービスの重要度を定義するために私たちを望んでいるだけでなく、我々は定義したり、メインルートの重要なビジネスやサービスの呼び出しを記述します。いいえ、サービス管理、運用、保守は、システム全体を管理することはできません。
ビジネスの分離を達成するために、アプリケーション層で多くの分散型アーキテクチャでは、しかし、データベース・ノードではありません。遅い死への非ミッションクリティカルなデータベースは、それが完全に停止につながる場合は利用できません。そのため、データベースはまた、適切なアイソレーション、データベースの独自のセットとのビジネスの好ましいラインを行う必要があります。これは、Amazonサーバの練習である - システム間で互いのデータベースを読み取ることができない、唯一のインタフェースはを通じてサービスを結合しました。これはマイクロサービス要件です。私たちは、だけでなく、各サービスの分割に対応するデータベースのための、サービスを分割したくありません。
3.失敗の大きな可能性
分散システムにおいて、なぜなら使用のマシンとサービスは非常になり、従って、故障の頻度は、従来の単一のアプリケーションよりも大きくなります。しかし、影響はあったものの影響は、大きなモノリシックなアプリケーションの故障、および分散システムた障害を単離することができるが、機械およびマルチサービス、マルチ周波数も失敗したため。誰が何を全体の構造を知らない管理が複雑のため、そして一方で、間違いを犯すことは非常に簡単です。分散システムアーキテクチャの運用・保守、同等の悪夢。
黄金のルールに匹敵する、次の2：
-
- 失敗はちょうどひどい障害回復時間が長すぎる、ひどいではありません。
- 失敗は影響が大きすぎる障害がひどいあった、ひどいではありません。
運用・保守チーム分散システムは、障害に対処するほとんどすべての時間、非常に忙しいです。モニター指標に独自のシステムを追加しようとした多くの企業が、これは実際には報われないです - あまりにも多くの情報が、情報なしに等しいです。また、SLAは、私たちは、重要な指標である「主要指標」を、定義する必要があります。ない戦術的、戦略的な怠惰なアプローチには困難である品質と重量のために。
すべての「火」ではなく「火。」上記 私たちは、操作および保守システムまたはを設計するとき、私たちは、障害（故障のためのデザイン）を低減する方法を検討する必要があります。あなたは、だけでなく、失敗を回復するために自動化された方法で避けることができない場合は、障害が衝突面を低減します。
人々は、複雑な物事の管理のすべての方法を行うことができず、自動化だけで私たちを助けることができる - マシンとサービスの数が上昇すると、それは本質的に欠陥がボトルネック人になります。
4.大きい多層アーキテクチャの運用および保守の複雑さ
私たちは通常、4層にシステムを分割します：
-
- ベース層：我々のマシン、ネットワーク、およびストレージ・デバイスです。
- プラットフォーム層：当社のミドルウェア層、Tomcatのは、MySQL、Redisの、ソフトウェアなどのカフカです。
- アプリケーション層：私たちのビジネスソフトウェアは、例えば、サービスのさまざまな機能。
- アクセス層は：ユーザーの要求は、アクセスゲートウェイ、負荷分散やCDNで、そのようなことをDNS。
いずれの問題は、問題の層全体につながることができます。何も操作および保守につながる、ビューおよび管理が統一されているが、より複雑で、その結果、分離されていません。
多くの企業は、労働者の技能、製品開発、ミドルウェア開発、事業運営および保守、システム運用・保守および他のサブチームへの技術チームに基づいて自分のスキルの一部門です。労働者のこうした部門の結果は、多くのことを完全に一緒に接続されていない、すべての管理プールの原因です。システム全体は、問題の一部として、それは大面積に分類されます、「ドミノ」のようになります。運用・保守の単一のビューが存在しないので、各サービスおよびリソースの後にどのようにサービスコールを知っている、そしてそれはコミュニケーションとポジショニングの問題に多くの時間を過ごすために障害が発生した場合にはリードしていません。
分業が問題ではないが、疑問があるかどうかを統一し、標準化の分割後のコラボレーション。この点は注意を払う必要があります。