分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計

第Ⅰ部シングルノードパターン

この本の主題は、分散システムです。分散システムとは、多数の別々のマシン上で動く、複数の異なるコンポーネントから構成されるアプリケーションです。しかし、この本の最初の部分では、1台のマシンで動く場合のパターンを取り上げます。その理由は簡単です。コンテナはこの本に書かれているパターンの基礎になる構成要素であり、1台のマシン上に一緒に配置されたコンテナのグループは、分散システムのパターンのアトミックな要素を構成するものだからです。

Ⅰ.1　シングルノードパターンを使う理由

分散アプリケーションを別々のマシン上で動く別々のコンテナの集まりに分割する必要性については分かりやすいでしょう。しかし、1台のマシン上で動いているコンポーネントを別々のコンテナに分割する必要性は分かりにくいかもしれません。この動機を理解するには、コンテナ化のゴールを考える必要があります。一般的には、一定のリソース（このアプリケーションは2 CPUコアと8GBのメモリが必要、と言った例）に境界を設けるのがコンテナのゴールです。これは、チームのオーナーシップの境界（このチームはこのコンテナイメージを管理している、など）でもあります。さらに、関心の分離（separation of concerns）のための境界（あることだけをやるためのコンテナイメージ、など）でもあります。

これらが、1台のマシン上のアプリケーションをコンテナの集まりに分割する理由です。リソースの分離をまず最初に考えましょう。例として、あるアプリケーションが、ユーザ向けのアプリケーションサーバと、バックグラウンドの設定ファイル読み込みサーバという、2つのコンポーネントから構成されているとします。エンドユーザに対するリクエストのレイテンシが最優先なのは明らかなので、ユーザ向けのアプリケーションは、常に応答可能なように十分なリソースを確保している必要があります。一方で、ユーザからのリクエストが多い時には少しぐらい処理が遅れてもシステムとしては問題ないという点で、バックグラウンドの設定読み込みサーバは、普通はベストエフォートなサービスだと考えられます。また、バックグラウンドの設定読み込みサーバは、エンドユーザに対するサービス品質に影響を及ぼさないようにするべきです。このような理由から、ユーザ向けのサーバとバックグラウンドの読み込みサーバは、別々のコンテナとして分離しなければなりません。コンテナを分けると、それぞれに異なるリソース必要条件や優先順位を付けることができ、ユーザ向けサーバが空いている時に、バックグラウンドの設定読み込みサーバが邪魔することなくリソースを使えるようにできます。また、2つのコンテナに対するリソース必要条件を分けることで、メモリリークやメモリのオーバーコミットなどでリソース競合を起こした際に、ユーザ向けサーバよりも設定読み込みサーバが先に停止されるようにもできます。 ...