本記事では、スプラシアのDevOps環境を支えているクラスタの概念についてまとめてみました。
スプラシアのDevOps環境の全体構成図は過去記事でご紹介しておりますので、ご興味のある方はまずこちらをご参照ください。
「docker + Kubernetesの存在は知っているが、その概念が今一つピンとこない。」
こういった方にピッタリの内容だと思いますので、是非ご一読ください。
前提として、これまでのシステムと比較をするために、例えとしてシステムを「牛」と捉えます。
これまでの牛（システム）
牛の体は、いくつものパーツによって構成されています。
ユーザーが牛に対し、「牛乳（データ）をください。」と言えば、牛は牛乳をユーザーに提供することができます。
しかし、牛も提供する牛乳には限界があります。
そのため、牛の管理人（開発者）は牛を増やすことで実質的に限界値を上げることはできますが、遺伝子レベルで全く同じ牛を用意することは実質不可能です。
システムもこれと同様に、全く同じステージング環境/本番環境を構築しようにも、システムを構成するツールのバージョン等をすべて手動で整えることはかなり大変で困難な作業です。
しかし、クラスタを取り入れることで、全く同じ牛を用意することが可能になります。
クラスタを取り入れた牛（システム）
牛は頭や胴体等で構成されており、頭や胴体は目や口、角、脚といった要素を組み合わせることで成立します。それらの要素を1つ1つのテンプレート（docker image）として別の場所に保管します。
牛の構成に必要な頭や胴体等をつくりだすために、要素を保管している場所にあるテンプレートを選択して取得します。そのテンプレートを用いて1つの頭や胴体等を作成します。これを「コンテナ化」といいます。
牛をつくりだすためには場所が必要です。その場所を「namespace」と呼び、namespace内にあるコンテナを納めるための箱を「workload」と呼びます。
namespaceは環境（本番環境/ステージング環境…）毎に区切られるため、ステージング環境から本番環境にアクセスされるといった心配はありません。
また、workload内に複数のコンテナを納めることで、仮に1つのコンテナが機能不全に陥ったとしても残りのコンテナが代わりに稼働するため、サービスを継続させることができます。これにより、高い冗長性を保つことができます。
牛をつくりだした後は、牛を生活させるための農場（牧場）が必要になります。取引先によっては要求する牛の種類や大きさ等が異なるケースもあるでしょう。
そこで、農場に取引先ごとに柵を設け、牛を管理します。この農場を「クラスタ（cluster）」と呼び、柵を「project」と呼びます。
システムの全体図
以上で必要な情報は揃いました。
それでは一度、システムの全体図を表示します。
例えば、開発者がアプリを作成/改修した場合、そのアプリをdocker imageとしてAWS EC2にプッシュします。そのあと、システム作成に必要な要素を設定ファイルに書き込み、実行することで、AWS EC2やdocker hubから必要なdocker imageを取り込み、システムの構築と管理をするようになります。
こういった動作をするツールの代表格を「Kubernetes」といいます。しかし、KubernetesはCUIで動いており、管理するには難易度が高いです。そのためスプラシアでは、「Rancher」を用いて、Kubernetesの実行結果をGUIで視覚化しております。
クラスタの概念は、コンテナやイメージといった概念もある程度理解することが必要になってくるため、とても複雑です。
まず、「docker/kubernetesとは？」から始めていただき、そのあと「rancherとは？」と学んでいくことをお勧めします。
参考：
