6 つの分離技術のうち、いくつ知っていますか?

アプリケーションをサーバーにデプロイするには、ランタイム環境を構成する必要があります。下から上にかけて、次のような動作環境とコンテナがあります。

1. ハードウェアの分離: 仮想マシン
2. オペレーティング システムの分離: コンテナ仮想化
3. 分離の最下層: サーブレットコンテナ
4. 依存関係バージョンの分離: 仮想環境
5. ランタイム環境の分離: 言語仮想マシン
6. 言語の分離: DSL

実際には、これはリクエスト処理プロセスであり、HTTP リクエストは最初にホストに到達します。ホスト上で複数の VM インスタンスが実行されている場合、リクエストはこの VM に送信されます。または、Docker などのコンテナー内でプログラムを実行している場合も、最初に Docker に到達します。その後、リクエストは Apache や Nginx などの HTTP サーバーによって処理され、対応するアプリケーションまたはスクリプトに渡されて処理されます。その後、基礎となる言語命令によって処理されます。

[[275554]]

環境によってオプションは異なりますが、もちろんそれらを組み合わせることもできます。しかし、理論的には最外層に実機が存在するはずですが、これは皆さんも明確な概念を持っていると思いますので、詳しく説明はしません。

1. ハードウェア（仮想マシン）を分離する

仮想マシン テクノロジが登場する前は、さまざまなユーザー向けにアプリケーションを実行するには、その要件を満たすさまざまな物理マシンが必要でした。 Web アプリケーションの場合、Web サイトへのアクセスが少なく、システム リソースの消費量が少ないユーザーもいれば、Web サイトへのアクセスが多く、システム リソースの消費量が多いユーザーもいます。選択できるサーバータイプはさまざまですが、トラフィックの少ないほとんどのユーザーは同じ料金を支払う必要があります。これはかなり不合理に思えますし、多くのリソースを無駄にします。システム管理者にとって、これらのシステムを管理するのは簡単な作業ではありません。かつては、ハードウェア技術の革新が非常に速く、異なるマシン上でオペレーティング システムを実行することは容易ではありませんでした。

仮想マシンは、ソフトウェアによってシミュレートされ、完全なハードウェア システム機能を備え、完全に分離された環境で実行される完全なコンピュータ システムです。

これは、単一のホスト上で複数の異なるオペレーティング システムを同時に実行できる非常に興味深いテクノロジです。これらのオペレーティング システムには異なるハードウェアを使用でき、その上のアプリケーションは異なるテクノロジー スタックを使用して実行できますが、理論的には相互に影響を与えることはありません。そのアーキテクチャを下の図に示します。

仮想マシン テクノロジの助けを借りれば、より多くのリソースが必要になったときに、新しい仮想マシンを作成するだけで済みます。同時に、これらの仮想マシンは同じオペレーティング システムを実行し、同じ構成を使用できるため、自動化するにはいくつかのスクリプトを記述するだけで済みます。 IoT に問題が発生した場合でも、仮想マシンを別のホストに迅速に移行または復元できます。

2. オペレーティングシステムを分離する（コンテナ仮想化）

ほとんどの開発チームにとって、仮想マシンをベースにした自動化ツールを直接開発することは容易ではなく、使用コストも比較的高くなります。現時点では、プロセスとリソースを分離するための軽量仮想化を提供でき、命令解釈メカニズムや完全仮想化のその他の複雑さを提供する必要のない、より軽量なツール コンテナーが必要です。また、起動も早くなります。

ルクセンブルク

Docker を紹介する前に、LXC について簡単に説明しましょう。過去に LXC を使用した経験があるので、LXC は素晴らしいと思います。

LXC は、Linux Containers の略称に由来する、オペレーティング システム レベルの仮想化テクノロジであり、Linux カーネル コンテナ機能のユーザー空間インターフェイスです。アプリケーション ソフトウェア システムをソフトウェア コンテナーにパッケージ化します。このコンテナーには、アプリケーション ソフトウェア自体のコードのほか、必要なオペレーティング システム カーネルとライブラリが含まれます。統一された名前空間と共有 API を通じて利用可能なハードウェア リソースをさまざまなソフトウェア コンテナーに割り当てることで、アプリケーション用の独立したサンドボックス オペレーティング環境が作成され、Linux ユーザーはシステム コンテナーまたはアプリケーション コンテナーを簡単に作成および管理できるようになります。

前述の仮想マシンと簡単に比較すると、そのアーキテクチャ図は次のようになります。

仮想マシンにはハイパーバイザーの追加レイヤーがあり、物理サーバーとオペレーティング システムの間で実行され、複数のオペレーティング システムとアプリケーションが基本的な物理ハードウェアのセットを共有できるようになります。このレイヤーは、サーバー上のすべての物理デバイスと仮想マシンへのアクセスを調整できますが、このレイヤーがあるため、消費するエネルギーも増えます。 Ericsson Research と Aalto University が発表した論文によると、Docker、LXC、Xen、KVM は同じ作業を完了するのに 10% 少ないエネルギーを消費します。

LXC は主に cgroup と名前空間の機能を使用して、アプリケーション ソフトウェアに独立したオペレーティング システム実行環境を提供します。 cgroups (コントロール グループ) は、プロセス グループによって使用される物理リソースを制限、記録、分離できる、Linux カーネルによって提供されるメカニズムです。名前空間は分離と制御を担当します。

仮想マシンと比較すると、LXC は分離の点でいくつかの欠点があり、ポータブルな展開を実現するのが困難になります。現時点では、抽象化レイヤーと管理メカニズムを提供する Docker が必要です。

ドッカー

Docker はオープンソースのアプリケーション コンテナ エンジンであり、開発者がアプリケーションと依存関係をポータブル コンテナにパッケージ化して、一般的な Linux マシンに公開し、仮想化を実現することもできます。 Docker は、あらゆるアプリケーションを自動的にパッケージ化してデプロイし、軽量のプライベート PaaS クラウドを作成し、開発およびテスト環境を構築し、スケーラブルな Web アプリケーションをデプロイするなどを行うことができます。

Docker コンテナの構築は非常に興味深いプロセスです。このプロセスでは、まず、Ubuntu や Debian などの基本システムだけを含むベースイメージが必要です。また、初期化プロセス、SSH サービス、syslog-ng などのツールなどの一連のモジュールも含まれています。基本的なイメージは、上記の元のコンテンツから構築されます。以降のすべての変更はこの画像に対して行われます。これを使用して、レイヤーごとに積み重ねて新しい画像を生成することができます。ユーザーのプロセスは書き込み可能なレイヤーで実行されます。

上の図から、Docker コンテナが Aufs 上に構築されていることもわかります。 AUFS は、異なるディレクトリを同じ仮想ファイルシステムにマウントできるユニオンファイルシステムです。その目的は、元のディレクトリに影響を与えずに、上図に示す増分プロセスを実現することです。つまり、プロセスは次のようになります。

画像

増分プロセスは、最初にミラー レイヤーがあることを除けば、Git を使用するプロセスに少し似ています。変更は保存され、次に変更をコミットするときに、古いコミットで実行できます。

したがって、Docker と LXC の間のギャップは次の図のようになります。

LXC では、各仮想マシンは 1 つの仮想マシンのみになりますが、Docker は一連の仮想マシンになります。

3. 基盤となるレイヤー（サーブレットコンテナ）を分離する

上記の例では、オペレーティング システムの要因を分離しました。次に、オペレーティングシステムと開発環境によって生じる違いを解決する必要があります。 Web アプリケーションの開発の初期には、CGI テクノロジが使用されていました。CGI テクノロジにより、クライアントは Web ブラウザーからネットワーク サーバー上で実行されるプログラムにデータを要求できるようになりました。また、CGI プログラムは、システム上で実行可能な言語であれば、任意のスクリプト言語または完全に独立したプログラミング言語で実装できます。このようなスクリプト言語はほとんどの場合システム環境に依存しており、特に C++ などのコンパイル言語は異なるオペレーティング システムで再コンパイルする必要があります。

Java Servlet もまた興味深い存在です。これは、プラットフォームやプロトコルに依存せず、動的な Web ページを生成できるサーバー側 Java アプリケーションです。

トムキャット

Java Web アプリケーションの開発プロセスでは、起動環境でサービスを実行するために Jetty を使用し、運用環境でサービスを実行するために Tomcat を使用します。これらはすべてサーブレット コンテナーであり、同じサーブレット アプリケーションを実行できます。サーブレットは、Web アプリケーションのコンテキストで HTTP 要求に応答するように設計された、Java で記述されたサーバー側プログラムです。これは、アプリケーション サーバー内のコンポーネントとプラットフォーム間のインターフェイスのコレクションです。

Tomcat サーバーは、無料のオープン ソース Web アプリケーション サーバーです。実行時にシステムリソースをほとんど占有せず、優れたスケーラビリティを備え、負荷分散やメールサービスなど、アプリケーションシステムの開発で一般的に使用される機能をサポートします。さらに、サーブレットおよび JSP コンテナでもあります。独立したサーブレット コンテナは Tomcat のデフォルト モードです。そのアーキテクチャを下の図に示します。

サーブレットはアプリケーション サーバーにデプロイされ、そのライフ サイクルはコンテナーによって制御されます。実行時に、Web サーバー ソフトウェアは一般的な要求を処理し、サーブレット呼び出しを「コンテナー」に渡して処理します。また、Tomcat はいくつかの静的リソースの処理も担当します。

4. 依存バージョンを分離する（仮想環境）

Javaなどのコンパイル言語の場合、言語操作によって発生する問題はそれほど多くありません。この問題は、Ruby、Python、Node.js などの動的言語に存在します。この問題は主に開発環境に焦点を当てています。もちろん、サーバー上で複数の異なるアプリケーションを実行している場合にも、この問題は発生します。この種のツールには、Python の VirtualEnv、Ruby の RVM と Rbenv、Node.js の NVM などがあります。

次の図は、VirtualEnv を使用する場合のさまざまなアプリケーションのアーキテクチャ図です。

以下に示すように、異なる仮想環境で異なる依存ライブラリを使用できます。さまざまなアプリケーションを構築し、さまざまな Python バージョンを使用してシステムを構築できます。一般的に、このタイプのツールは主にローカル開発環境で使用されます。

5. 動作環境（言語仮想マシン）を分離する

最後に紹介するのは、より抽象的かもしれませんが、より実用的でもあります。この点では JVM が代表的です。プログラミングのキャリアの中で、クロスプラットフォームの問題に遭遇することはよくあります。開発マシンで開発したソフトウェアが、運用環境のマシンでは動作しないのです。特に、Mac OS または Windows マシンでアプリケーションを開発し、それを Linux システムで実行する必要がある場合、さまざまな問題が発生します。そして、再コンパイルが必要なライブラリを使用する場合、この問題はさらに厄介になります。

次の図はJVMのアーキテクチャ図を示しています。

JVM はコンピューティング デバイスの仕様です。実際のコンピュータ上でさまざまなコンピュータ機能をシミュレートして実装された架空のコンピュータです。 「一度書けばどこでも実行できる」ことが可能になります。

つまり、最下層で環境の分離を実装し、特定のオペレーティング システム プラットフォームに関連する情報を遮断することで、Java プログラムは Java 仮想マシン上で実行されるターゲット コード (バイトコード) を生成するだけで済み、変更なしで複数のプラットフォームで実行できるようになります。

これを踏まえると、他のプログラミング言語のコンパイラが正しい Java バイトコード ファイルを生成できる限り、この言語も JVM 上で実行できます。次の図は、JVM ベースの Jython 言語のアーキテクチャ図を示しています。

基盤となるレイヤーは JVM に基づいており、Python で記述されており、Java モジュールを使用してプログラミングできます。

同じアーキテクチャを持つ別の一般的なツールは MySQL です。次の図は MySQL のアーキテクチャを示しています。

MySQL は、最上位レベルで SQL と呼ばれるクエリ言語を提供します。このクエリ言語はデータベースをクエリするためにのみ使用できますが、より高度な使用法です。ソフトウェアのあらゆる問題をカバーする汎用言語とは異なり、特定の問題に特化して設計されたコンピュータ言語、つまりドメイン固有言語です。

6. 分離言語 (DSL)

これは非常に興味深く、刺激的な技術ですが、それを実現するのは簡単ではありません。

分離された環境についての説明の一環として、外部 DSL のみを検討します。内部 DSL と外部 DSL の最大の違いは、外部 DSL は新しい構文とセマンティクスを持つ新しい言語を作成することに似ていることです。次の図は、2 つの DSL の比較を示しています。

このような外部 DSL には、独自の文法、独自のパーサー、型チェッカーなどが含まれます。最も単純で最もよく使用される DSL は、次に示すように Markdown です。

ビジネス ロジックを DSL として記述できる場合は、基盤となる言語の変更が元のビジネス ロジックにあまり影響を与えることを心配する必要はありません。つまり、これは言語が分離された独自の環境を作成することに相当し、ビジネスを実装するためにどの言語を使用するかを考える必要はありません。