優れた分散システムを設計するにはどうすればよいでしょうか?重要な要素、ツール、戦略はすべてここにあります

  [[282266]]

導入

今日のアプリケーションは、分散システム開発の驚異です。異なるシステム アーキテクチャに基づいて、アプリケーションを構成する各機能またはサービスは、地理的に異なる場所に配置され、異なるコンピューター言語で記述された異なるシステム上で実行される場合があります。アプリケーションのコンポーネントは、ユーザーが携帯し、世界中のアプリケーション コンポーネントまたはサービスと通信できる強力なシステム上でホストされる場合があります (それらはすべてデータ センター内のレプリカです)。

驚くべきことに、これらのアプリケーションのユーザーは、複雑な環境の要求に応答しないことがよくあります。このようなリクエストには、現地時間、現地の天気、ホテルまでの道順などが含まれます。

まず、これらすべてを可能にする産業上の魔法を見て、この複雑さに対処する際に開発者が心に留めておくべきアイデアやルールについて考えてみましょう。

システム設計の進化

アプリケーション開発は、プログラマーがアプリケーションを作成し、それを作業中のマシンの言語に手作業でコンパイルし、トグル スイッチを使用して個々のマシン命令とデータをコンピューターのメモリに直接入力していた時代から大きく進歩しました。

プロセッサがより強力になり、システムメモリとオンラインストレージ容量が増加し、コンピュータネットワーク機能が大幅に向上するにつれて、開発方法も変化しました。初期のコンピュータがシステム メモリからプロセッサ自体にデータを転送するよりも高速に、データを地球の端から端まで転送できるようになりました。

この驚くべき変革のハイライトをいくつか見てみましょう。

モノリシック設計

初期のコンピュータ プログラムはモノリシック設計に基づいており、すべてのアプリケーション コンポーネントが単一のマシン上で実行されるように設計されていました。つまり、ユーザー インターフェイス (ユーザーが実際にプログラムを操作できる場合)、アプリケーション処理ルール、データ管理、ストレージ管理、ネットワーク管理 (コンピューターがコンピューター ネットワークに接続されている場合) などの機能がすべてプログラムに含まれているということです。

これらのプログラムは作成は簡単ですが、次第に複雑になり、文書化、更新、変更が困難になる可能性があります。この時点で、マシン自体がビジネスにとって最大の費用となるため、アプリケーションはマシンを最大限に活用するように設計されます。

クライアント/サーバーアーキテクチャ

プロセッサがより強力になり、システムおよびオンライン ストレージの容量が増加し、データ通信がより高速かつ経済的になるにつれて、アプリケーション設計は開発のペースに合わせて進化してきました。アプリケーション ロジックはリファクタリングまたは分解され、各アプリケーションを異なるマシンで実行できるようになり、コンポーネント間には常に改善されたネットワークが挿入されました。これにより、一部の機能を現在利用可能な最も低コストのコンピューティング環境に移行できるようになります。この進化は次の段階を経てきました。

• 端末と端末エミュレーション 初期の分散コンピューティングは、専用のユーザー アクセス デバイス (端末) に依存していました。アプリケーションは、使用する通信プロトコルを理解し、デバイスに直接コマンドを発行する必要があります。安価なパーソナル コンピュータ (PC) が利用可能になると、端末は端末エミュレーション プログラムを実行する PC に置き換えられました。この時点では、アプリケーションのすべてのコンポーネントは、依然として単一のメインフレームまたはミニコンピュータ上に存在します。
• 軽量クライアント PC がより強力になり、より大きな内部ストレージとオンライン ストレージをサポートするようになり、ネットワーク パフォーマンスが向上するにつれて、企業はアプリケーションをセグメント化または分散化し、ユーザー インターフェイスを抽出してローカル PC 上で実行できるようになりました。アプリケーションの残りの部分は、データセンター内のシステム上で引き続き実行されます。これらの PC は、一般的に、置き換える端末よりも安価であり、追加の利点があります。これらの PC は、置き換える端末では利用できない生産性向上アプリケーションを実行できる多機能デバイスです。この組み合わせにより、企業はアプリケーションを更新またはリフレッシュする際に、クライアント/サーバー アプリケーション アーキテクチャを採用するようになりました。
• ミッドレンジ クライアント PC の成長は急速に続いています。より強力なストレージ容量を備えたシステムが利用可能になると、企業はそれらを使用して、より多くの処理操作をデータセンターの高価なシステムからユーザーのデスク上の安価なシステムに移行しました。この時点で、ユーザー インターフェイスと一部のコンピューティング タスクはローカル PC に移行されます。これにより、メインフレームとミニコンピュータ (現在のサーバー) の寿命が長くなり、企業の全体的なコンピューティング コストが削減されました。
• ヘビークライアント PC の性能が上がるにつれて、バックエンド サーバーから移動できるアプリケーションが増えます。ここでは、データとストレージ管理機能を除くすべての機能が移行されています。
• インターネットとワールド ワイド ウェブの登場 この頃、パブリック インターネットとワールド ワイド ウェブが登場しました。クライアント/サーバー コンピューティングは現在でも使用されています。全体的なコストを削減するために、一部の企業は、標準のインターネット プロトコルを使用した通信を容易にし、以前にカスタマイズされたユーザー インターフェイス機能の代わりに Web ブラウザーを使用するように分散アプリケーションを再構築し始めています。その後、アプリケーションの機能の一部は、クライアントのコンピューター上でローカルに実行できるように、JavaScript 言語で書き直されました。
• サーバーの改善 業界のイノベーションは、クライアント側の通信リンクに重点を置くだけでなく、サーバーにも大きな改善をもたらします。企業は、多くの小型で安価な業界標準サーバーを活用し始めており、その強力な機能を活用して、元のメインフレームベースの機能の一部またはすべてをサポートしています。このようにして、導入する必要がある高価なホスト システムの数を削減できます。リモート PC は、それぞれが独自のアプリケーション コンポーネントをサポートする多数のサーバーと通信できるようになります。この環境では専用のデータベース サーバーとファイル サーバーが使用されます。後で、他のアプリケーション機能をアプリケーション サーバーに移行できます。ネットワーキングは、業界にとって大きな関心事であるもう一つの分野です。企業は、ファイアウォールやその他のセキュリティ機能、アプリケーションのデータ アクセスを高速化するファイル キャッシュ機能、電子メール サーバー、Web サーバー、Web アプリケーション サーバー、分散ネーミング サーバーなどを提供する専用ネットワーク サーバーを使い始めています。これらのサーバーは、データやアプリケーションにアクセスするためのユーザー資格情報を追跡および制御します。デバイス サーバーにパッケージ化されたネットワーク サービスのリストは常に増え続けています。

オブジェクトベース開発

PC とサーバーの機能の急速な変化と、処理能力、メモリ、ネットワークの劇的な価格低下が相まって、アプリケーション開発に大きな影響を与えています。 IT 分野における最大のコスト支出は、もはやハードウェアとソフトウェアではなく、通信、IT サービス (スタッフ)、電力、冷却システムです。

ソフトウェア開発、ソフトウェア保守、IT 運用は新たな重要性を帯びるようになり、システムは安価である一方で人件費、通信費、電気代は高騰するという新たな状況に対応するために開発プロセスも変化しました。

企業は、データとアプリケーションのアーキテクチャを改善することで、従業員を最大限に活用したいと考えています。その結果、オブジェクト指向のアプリケーションと開発方法が生まれます。次のような多くのプログラミング言語がこのアプローチをサポートしています。

C++、C#、COBOL、Java、PHP、Python、Ruby

データ構造を定義して文書化することで、アプリケーション開発者は変更に対応するアプリケーションをより体系的に作成できるようになります。このアプローチにより、アプリケーションの保守と改善も容易になります。

オープンソースソフトウェア

Opensource.com では、オープン ソース ソフトウェアを次のように定義しています。「オープン ソース ソフトウェアとは、誰でも検査、変更、拡張できるソース コードを持つソフトウェアです。」 「一方、一部のソフトウェアのソースコードは、それを作成した個人、チーム、または組織のみが変更でき、そのソフトウェアに対する排他的管理を維持しています。このような種類のソフトウェアは、「プロプライエタリ」または「クローズドソース」ソフトウェアと呼ばれます。」

独自のソフトウェアのオリジナルの作成者だけが、そのソフトウェアを合法的にコピー、検査、および変更できます。プロプライエタリ ソフトウェアを使用するには、コンピューター ユーザーは、ソフトウェアの作成者の明示的な許可なしにソフトウェアに変更を加えないことに同意する必要があります (通常は、ソフトウェアを初めて実行したときに表示されるライセンスに同意することによって)。 Microsoft Office や Adob​​e Photoshop は独自ソフトウェアの例です。

オープン ソース ソフトウェアはコンピューティングの初期の頃から存在していましたが、完全なオープン ソース オペレーティング システム、仮想化テクノロジ、開発ツール、データベース エンジン、およびその他の重要な機能が登場した 1990 年代まで、前面に出てくることはありませんでした。オープンソース テクノロジーは、多くの場合、Web ベースおよび分散コンピューティングの重要なコンポーネントです。その中でも、次のカテゴリのオープンソース ソフトウェアが人気です。

• 開発ツール
• アプリケーションサポート
• データベース (フラット ファイル、SQL、No-SQL、インメモリ)
• 分散ファイルシステム
• メッセージトランスポート/キュー
• オペレーティング·システム
• クラスタリング

分散コンピューティング

強力なシステム、高速ネットワーク、高度なソフトウェアの利用可能性の組み合わせにより、主要なアプリケーション開発はモノリシックな形式からより分散された形式へと移行しました。しかし、企業は、古いアプリケーションをリファクタリングしたり分解したりするよりも、ゼロから始める方がよい場合があることに気付きました。

企業が分散アプリケーションの作成に取り組むと、興味深い副産物が見つかることがよくあります。適切に設計され、個別の機能またはサービスに分割されたアプリケーションは、別々のチームによって並行して開発できます。

DevOps とも呼ばれる迅速なアプリケーション開発と展開は、新しい環境を活用するための 1 つのアプローチです。

サービス指向アーキテクチャ

業界がクライアント/サーバー コンピューティング モデルからより分散化されたアプローチへと進化するにつれて、「サービス指向アーキテクチャ」という用語が登場しました。このアプローチは、分散システムの概念、メッセージ キューイングと配信の標準、およびデータとデータ定義を共有するための標準的な方法としての XML メッセージングに基づいています。

個々のアプリケーションの機能は、特定のサービスを実行するように要求するメッセージを受信し、サービスを実行した後、サービスを要求した機能に応答を返すネットワーク対応サービスにパッケージ化されます。

このアプローチでは、特定のサービスをネットワーク上の複数の場所でホストできるという追加の利点も得られます。これにより、全体的なパフォーマンスが向上し、信頼性が高まります。

これに加えて、サービス要求を受信し、使用可能な容量を確認し、使用可能な容量が最も大きいサービスに要求を転送し、要求者に応答を返すために使用されるワークロード管理ツールが現在では数多くあります。特定のサーバーが時間内に応答しない場合、ワークロード マネージャーはサービスを別のインスタンスに転送するだけです。また、応答しないサービスを失敗としてマークし、サービスがまだ実行中であることを示すメッセージを受信するまで、そのサービスに追加の要求を送信しません。

分散システムの設計における重要な考慮事項

50 年にわたるコンピューティングの歴史を経て、分散システム開発者向けの経験則をいくつか見てみましょう。分散ソリューションでは、さまざまな種類のシステム上のさまざまな場所でコンポーネントとサービスが実行され、作業を実行するためにメッセージをやり取りする必要があるため、考慮すべき点が多数あります。これらのソリューションをうまく作成するには、慎重な思考が必要です。これに加えて、使用されるホスト システム、開発ツール、メッセージング システムごとに提供される必要がある専門知識があります。

何をする必要があるかを判断する

最初に考慮する必要があるのは、正確に何を達成する必要があるかということです。これは単純に聞こえますが、非常に重要です。

何が必要なのかを正確に把握する前に、何かを作り始める開発者がどれほど多いかは驚くべきことです。多くの場合、これは不必要な機能を構築し、時間を無駄にすることを意味します。ヨギ・ベラの言葉を引用すると、「どこへ行くのか分からなければ、どこか別の場所にたどり着くことになる」。

まず、何をしたいのか、どのようなツールやサービスがすでに利用可能か、そして最終的なソリューションを使用するユーザーに何が表示されるのかを把握する必要があります。

インタラクティブおよびバッチ処理

多くの場合、高速応答と低レイテンシが要件となるため、ユーザーが待機している間に何を行うべきか、イベント駆動型または時間駆動型のスケジュールで実行されるバッチ プロセスに何を組み込めるかを考えることが賢明です。

機能の初期セグメント化を検討した後、バックグラウンド プロセスとバッチ プロセスをいつ実行する必要があるか、これらの機能がどのデータに対して動作するか、これらの機能が信頼性が高く、利用可能であり、データ損失から保護されていることをどのように保証するかを計画することをお勧めします。

機能はどこでホストする必要がありますか?

「何を達成するか」を詳細に計画した後で初めて、「どこで」そして「どのように」それを実行するかを検討する必要があります。開発者にはお気に入りのツールや方法があり、それが最善の選択ではない場合でも、それらを頻繁に呼び出します。バーナード・バルークはこう言った。「ハンマーしか持っていなければ、すべてが釘に見える。」

企業が策定した企業基準を理解することも重要です。現在人気があるという理由だけでツールを選択するのは賢明ではありません。このツールは目的を達成できますが、構築したものはすべてメンテナンスする必要があることを覚えておくことが重要です。自分だけが理解したり保守したりできるものを構築すると、残りのキャリアを通じてその機能に縛られることになるかもしれません。私自身も、自分が作成した機能は適切に動作し、軽量で、信頼性が高いと考えていた経験があります。しかし、私がその会社を辞めてから 10 年経っても、これらの機能についての問い合わせが続きました。後続の開発者がこれらの機能の実装方法を理解できず、私が書いたドキュメントが長い間捨てられていたためです。

分散ソリューションでは、各機能またはサービスを個別に検討する必要があります。この機能は企業のデータセンターに配置する必要がありますか?あるいはクラウド サービス プロバイダーを使用しますか?それとも両方ですか?また、業界によっては、データをどこにどのように維持および保存する必要があるかについての選択を導く規制要件があることも考慮してください。

他に考慮すべき事項としては、以下のものがあります。

• この機能のホストはどのようなタイプのシステムである必要がありますか?この機能にもっと適したシステム アーキテクチャはありますか?システムは ARM、x86、SPARC、Precision、Power、メインフレームのどれをベースにすべきでしょうか?
• 特定のオペレーティング システムは、この機能に適したコンピューティング環境を提供しますか? Linux、Windows、UNIX、System I、System Z のどれがより良いプラットフォームでしょうか?
• この機能には特定の開発言語の方が適しているでしょうか?それは特定の種類のデータ管理ツールですか?フラット ファイル、SQL データベース、No-SQL データベースのどれを使用すればよいでしょうか?それとも、非構造化ストレージメカニズムの方が優れているのでしょうか?
• 移植性、自動化、オーケストレーションを容易にするために、関数を仮想マシンまたはコンテナーでホストする必要がありますか?

2000 年代初頭には、Windows または Linux 仮想マシンを実行することが好まれる選択肢になることが多かったです。メソッドに重要な分離を提供し、必要に応じてメソッドの再起動や移動を容易にしますが、処理、メモリ、およびストレージの要件は非常に高くなります。コンテナーは仮想化に対処する別の方法であり、同様のレベルの分離、メソッドの再起動と移行の機能を提供しますが、消費する処理能力、メモリ、またはストレージははるかに少なくなります。

パフォーマンス

パフォーマンスももう一つの重要な考慮事項です。ソリューションを構成する機能やサービスを定義する場合、開発者は、処理、メモリ、またはストレージの要件が重要かどうかを認識する必要があります。これらの質問を注意深く検討し、機能をさらに細分化または分解できるかどうかを確認することが重要です。

さらにパーティショニングすることで並列処理が強化され、パフォーマンスが大幅に向上する可能性があります。もちろん、トレードオフとして、複雑さが増し、管理とセキュリティ保護が困難になる可能性があります。

信頼性

重要な企業環境では、ソリューションの信頼性が非常に重要です。開発者は、データの再入力や機能の再実行をユーザーに依頼してもよい場合と、機能が利用できなくなる場合を検討する必要があります。

データベース開発者は 1960 年代にこの問題に直面し、アトミック関数の概念を開発しました。つまり、関数が完了するか、更新の一部をロールバックして、データが関数の開始前の状態に戻るようにする必要があります。分散システムでは、サービス障害やトランザクション停止が発生した場合でもデータの整合性が維持されるようにするために、この考え方も必要です。

たとえば、重要なメッセージング システムでは、受信者がメッセージを受信したことが確認されるまでメッセージを保存する必要があります。メッセージが正常に受信されなかった場合、元のメッセージを再送信し、システム管理者に失敗を報告する必要があります。

管理性

コアアプリケーション機能ほど興味深いものではありませんが、管理性は、アプリケーションが適切に機能し続けるための重要な要素です。すべての分散機能は、管理者が各機能の現在の状態を理解し、必要に応じて機能のパラメータを変更できるように、完全にインストルメント化されている必要があります。結局のところ、分散システムは、それが置き換えるモノリシック システムよりも多くの可動部分で構成されています。開発者は、この分散コンピューティング環境を使いやすく、保守しやすいものにすることを常に意識する必要があります。

したがって、管理者が現在の状態を把握できるように、すべての分散機能を適切に計測する必要があるという絶対的な要件が生まれます。結局のところ、分散システムは、置き換えるモノリシック システムよりも本質的に複雑であり、可動部分も多くなります。

安全

分散システムのセキュリティを確保することは、モノリシック環境のセキュリティ問題よりも桁違いに困難です。各機能は個別に機密性を保つ必要があり、機能間の通信リンクも機密性を保つ必要があります。ネットワークの規模と複雑さが増すにつれて、開発者は機能へのアクセスを制御する方法、許可されたユーザーのみがそれらの機能にアクセスできるようにする方法、およびサービスを他のサービスから分離する方法を考慮する必要があります。

セキュリティは、後から付け加えるのではなく、すべての機能に追加する必要がある重要な要素です。機能やデータへの不正アクセスは回避し、報告する必要があります。

プライバシー

プライバシーに関する規制はますます厳しくなっています。 EU の GDPR と米国の HIPPA 規制は、顧客対応システムのすべての開発者にとって重要な考慮事項です。

複雑さを克服する

開発者は、複雑なコンピューティング環境においてすべての要素がどのように組み合わされるかについて時間をかけて考える必要があります。サービスは単一の機能、または密接に関連した少数の機能にカプセル化される必要があり、そのようなルールを維持するのは非常に困難です。機能が複数の場所に実装されている場合、保守と更新が困難になります。関数のインスタンスが更新されない場合はどうなりますか?この問題は非常に困難です。

つまり、複雑なアプリケーションの開発者にとって、各機能がどこに配置されているかを示す視覚的なモデルを維持し、ルールやビジネス要件が変更された場合に更新できるようにすることは非常に役立ちます。

通常、開発者は、機能の場所や仕組みを理解するために他の人がコードの山に目を通さなくても済むように、自分が何をしたか、いつ変更したか、その変更の目的は何だったかを時間をかけて文書化する必要があります。

分散システムの設計者になるには、開発者は複雑さをマスターする必要があります。

開発者が習得すべき方法

開発者は、アプリケーション アーキテクチャの分解とリファクタリング、チームの視点からの思考、迅速なアプリケーション開発と展開 (DevOps) 方法論におけるスキルの向上を習得する必要があります。結局のところ、どの機能が互いに独立しているか、どの機能が他の機能の出力に依存して動作しているかを体系的に考えることができなければなりません。他の機能に依存する機能は、単一のサービスとして実装するのが最適です。これらを個別の機能として実装すると、不必要な複雑さが生じ、アプリケーションのパフォーマンスが低下し、ネットワークに不必要な負担がかかる可能性があります。

仮想化は広範囲に及ぶ

仮想化は、単なる仮想マシン ソフトウェアやコンテナーよりも広いカテゴリです。これら両方の機能は仮想化テクノロジーと見なされます。現在使用されている仮想化テクノロジには、少なくとも 7 種類あります。仮想化テクノロジーを使用すると、ユーザーがアプリケーションにアクセスする方法、アプリケーションが実行される場所と方法、処理が実行される場所と方法、ネットワークが機能する方法、データが保存される場所と方法、セキュリティが実装される方法、管理機能が実装される方法を強化することができます。次の仮想化テクノロジ モデルは、開発者が仮想化の概念を理解するのに役立ちます。

ソフトウェア定義ソリューションの検討

開発者にとって、「ソフトウェア定義」ソリューションの観点から考えることも重要です。つまり、制御を実際の処理から分離して、機能を自動化および調整できるようにします。

どのようなツールや戦略が利用できますか?

開発者がこの複雑な世界に足を踏み入れる際、孤独を感じるべきではありません。ベンダーやオープンソース コミュニティからは、強力なツールが数多く提供されています。さまざまな形式の仮想化テクノロジーは、開発者の強い味方となり得ます。

1. 仮想化はあなたの親友

• コンテナを使用すると、互いに干渉することなく実行でき、ワークロードのニーズに基づいてシステム間で移行できる機能を簡単に開発できます。
• オーケストレーション テクノロジーにより、複数の機能を制御し、それらの機能が適切かつ確実に実行されるようになります。障害が発生した場合には再起動したり移動したりすることもできます。
• 増分開発をサポート: 機能を並行して開発し、準備ができたら展開できます。他の部分を変更することなく、新しい機能で更新することもできます。
• 高度に分散されたシステムのサポート: 関数は、エンタープライズ データ センターにローカルに展開することも、クラウド サービス プロバイダーのデータ センターにリモートで展開することもできます。

2. サービスの観点から考える

つまり、開発者はサービスとそれらが相互に通信する方法について考える必要があります。

明確に定義されたAPI

明確に定義された API により、複数のチームがより効率的に連携し、すべてが計画どおりに機能することを保証できます。多くの場合、これは事前に多くの作業が必要になることを意味しますが、最終的にはそれだけの価値があります。なぜ？全体的な開発が速くなるからです。また、ドキュメント作成作業の負担も軽減できます。

迅速なアプリケーション開発をサポート

このアプローチは、DevOps とも呼ばれる迅速なアプリケーション開発と迅速なプロトタイピングにも最適です。 DevOps を適切に実行すると、展開時間も非常に短くなります。

基準の観点から考える

分散システムの開発者は、単一のベンダーに依存するのではなく、複数のベンダーの国際標準を考慮する必要があります。このアプローチにより、ベンダーロックインを回避し、さまざまな分野で最適なサプライヤーを見つけることができます。

要約する

迅速なアプリケーション開発と分散システムの導入に関するガイドラインは、「ゆっくり進める」ことから始まることに注意することが重要です。最も賢明なのは、どこに向かい、何をするかを計画することです。そうしないと、目標を達成できず、開発予算を使い果たし、何も達成できない可能性が高くなります。