Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
31
Help us understand the problem. What is going on with this article?
@reireias

Kubernetesで学ぶ分散システムデザインパターン

More than 1 year has passed since last update.

コンテナを使ったシステムのアーキテクチャパターンが掲載されている、分散システムデザインパターンという良書に出会ったので、Kubernetesの勉強を兼ねて各デザインパターンを実装してみましたので、ご紹介です。

この本は執筆者の論文が元になっており、そちらの翻訳記事もあるので、一読することをおすすめします。
Qiita | コンテナ・デザイン・パターンの論文要約

本記事で扱うデザインパターンとその例

分散システムデザインパターン中では、大別して2種のデザインパターンが紹介されています。

  • 1台のノード上で複数のコンテナが動作するシングルノードパターン
  • 複数のノード上で実現されるマルチノードパターン

本記事では、シングルノードパターンから以下のデザインパターンとその例を、Kubernetesでの実装例とともに解説します。

  • サイドカーパターン
    • ex1. git-sync
    • ex2. topz
  • アンバサダパターン
    • ex1. twemproxy
  • アダプタパターン
    • ex1. redis exporter
    • ex2. mysql-healthcheck

リポジトリ

本記事の内容の英語版は以下のリポジトリで公開しております。

サイドカーパターン

サイドカーパターンはポッド(ノード)の中で、主となるコンテナを補助する様なコンテナを持つ構成です。
sidecar.png

ex1. git-sync

git-syncというツールを利用したサイドカーパターンの例です。
git-syncは定期的にリポジトリへアクセスし、常に最新のコードにローカルのコードを保つツールです。

この例での構成は下記のようになります。

     +--------+           +--------+
     | client |           | GitHub | html file
     +--------+           +--------+
          |                   |
          | access            | git pull
          |                   |
+---------------------------------------+
|         |                   |         |
|  +-------------+     +-------------+  |
|  |    Nginx    |     |   git-sync  |  |
|  | <Container> |     | <Container> |  |
|  +-------------+     +-------------+  |
|         |                   |         |
|         | mount             | mount   |
|         |                   |         |
|         |  +-------------+  |         |
|         +--| source code |--+         |
|            |  <Voluem>   |            |
|            +-------------+            |
|                 <Pod>                 |
+---------------------------------------+
  • git-syncが定期的にgitリポジトリへアクセスし、最新のコードを取得します。
  • 取得されたコードはノード上のVolumeへ保存され、git-syncコンテナとメインとなるコンテナ(ここではNginx)からアクセスできるように構築されています。
  • この構成により、Nginxのコンテナに手を入れなくとも、常に最新のコードをNginxのコンテナから参照できるようになります。

※コードの更新後、再起動が必要なケースでは、git-syncにもう少し複雑な設定を追加する必要があります。

マニフェスト

マニフェストファイルの実装は下記のようになります。

git-sync.yml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: git-sync
spec:
  replicas: 1
  selector:
    matchLabels:
      app: git-sync
  template:
    metadata:
      labels:
        app: git-sync
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
            - containerPort: 80
          volumeMounts:
            - name: git-sync-volume
              mountPath: /usr/share/nginx
        - name: git-sync
          image: gcr.io/google_containers/git-sync:v3.1.1
          volumeMounts:
            - name: git-sync-volume
              mountPath: /sync
          env:
            - name: GIT_SYNC_REPO
              value: https://github.com/reireias/git-sync-example.git
            - name: GIT_SYNC_BRANCH
              value: master
            - name: GIT_SYNC_ROOT
              value: /sync
            - name: GIT_SYNC_DEST
              value: html
      volumes:
        - name: git-sync-volume
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: git-sync
  labels:
    app: git-sync
spec:
  selector:
    app: git-sync
  type: NodePort
  ports:
    - port: 80
      targetPort: 80

解説

  • git-syncコンテナとNginxコンテナを持つPodを1台構築するDeploymentが定義されています
  • Deployment中のPodの設定では、コードをコンテナ間で共有するためのvolumeを定義しています
  • git-syncで最新のコードを取得するリポジトリは、git-syncコンテナの環境変数で指定しています
    • もし、自分で起動して確認する場合は、自分でpush可能なリポジトリを指定するために、上記リポジトリをforkし、そのリポジトリを利用してください
  • Nginxのコンテナを外部へ公開するための、Serviceを定義しています

minikube上での実行

miniubeでの実行例です。

# デプロイする
kubectl apply -f git-sync.yml

# ブラウザでgit-syncサービス(Nginx)へアクセスする
minikube service git-sync

# git-syncで参照しているリポジトリのコードを更新する

# サイドブラウザでアクセスし、htmlファイル等が更新されていることを確認する

ex2. topz

サイドカーパターンの2つめの例はtopzを用いたリソース監視です。

構成は下記のようになります。

+---------------------------------------------+
|  +---------------------------------------+  |
|  |  +-------------+     +-------------+  |  |
|  |  |    Nginx    |     |     topz    |  |  |
|  |  | <Container> |     | <Container> |  |  |
|  |  +-------------+     +-------------+  |  |
|  |            <PID namespace>            |  |
|  +---------------------------------------+  |
|                    <Pod>                    |
+---------------------------------------------+
  • topzコンテナとNginxコンテナ間でPID namespaceを共有させています
  • topzからNginxのプロセス情報が参照できるようになっています
  • これをwebアクセスで参照できるのがtopzの機能です

マニフェスト

マニフェストファイルの実装は下記のようになります。

topz.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: topz
spec:
  replicas: 1
  selector:
    matchLabels:
      app: topz
  template:
    metadata:
      labels:
        app: topz
    spec:
      shareProcessNamespace: true
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
            - containerPort: 80
        - name: topz
          image: brendanburns/topz:db0fa58
          ports:
            - containerPort: 8080
          command:
            - /server
          args:
            - -addr
            - 0.0.0.0:8080
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  selector:
    app: topz
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
      name: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: topz
  labels:
    app: topz
spec:
  selector:
    app: topz
  type: NodePort
  ports:
    - port: 8080
      targetPort: 8080
      name: topz

解説

  • DeploymentでNginxとtopzコンテナを持つPodを定義しています
  • 外部からアクセスできるように、topzとNginxのそれぞれのServeceを定義しています

minikube上での実行

# デプロイします
kubectl apply -f topz.yml

# サービス一覧からエンドポイントを確認できます
minikube service list
|-------------|----------------------|-----------------------------|
|  NAMESPACE  |         NAME         |             URL             |
|-------------|----------------------|-----------------------------|
| default     | nginx                | http://192.168.39.196:31831 |
| default     | topz                 | http://192.168.39.196:30532 |
|-------------|----------------------|-----------------------------|

# 下記コマンドでNginxサービスへアクセスできます
minikube service nginx

# topz側のエンドポイントは下記コマンドで表示できるので、ブラウザでアクセスします
echo "$(minikube service topz --url)/topz"
# リソース使用状況が表示されるはずです

アンバサダパターン

アンバサダパターンはメインのコンテナから外部へ接続する際に仲介する仕組みです。
キャッシュを利用したり、リクエストに応じて接続先を切り替えたりする用途で利用します。
ambassador.png

ex1. twemproxy

Redis用のproxyサーバーであるtwemproxyを利用する例です。

構成は下記のようになっています。

                     +-----------------+
                     | +-------------+ |
                     | |    Nginx    | |
                     | | <Container> | |
                     | +-------------+ |
                     |        |        |
                     | +-------------+ |
                     | |  twemproxy  | |
                     | | <Container> | |
                     | +-------------+ |
                     |        |  <Pod> |
                     +-----------------+
                              |
            +-----------------+-----------------+ 
            |                 |                 |
  +---------+-----------------+-----------------+---------+
  |         |                 |                 |         |
  | +---------------+ +---------------+ +---------------+ |
  | | Redis Shard 0 | | Redis Shard 1 | | Redis Shard 2 | |
  | |     <Pod>     | |     <Pod>     | |     <Pod>     | |
  | +---------------+ +---------------+ +---------------+ |
  |                     <StatefulSet>                     |
  +-------------------------------------------------------+
  • twemproxyは高速かつ軽量なmemcached/Redis用プロキシです
  • リクエスト中のキーに応じて接続先のRedisサーバーを自動的に選択してくれます
  • ハッシュを利用しているので、同じキーの保存/取得リクエストはすべて同じRedisサーバーへ送られます
  • この仕組みにより、Redisサーバーの負荷の分散が実現できます。

マニフェスト

マニュフェストは下記のようになります。

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sharded-redis
spec:
  selector:
    matchLabels:
      app: redis
  serviceName: "redis"
  replicas: 3
  template:
    metadata:
      labels:
        app: redis
    spec:
      terminationGracePeriodSeconds: 10
      containers:
        - name: redis
          image: redis
          ports:
            - containerPort: 6379
              name: redis
---
apiVersion: v1
kind: Service
metadata:
  name: redis
  labels:
    app: redis
spec:
  ports:
    - port: 6379
      name: redis
  clusterIP: None
  selector:
    app: redis
---
apiVersion: v1
kind: Pod
metadata:
  name: ambassador-example
spec:
  containers:
    - name: nginx
      image: nginx
    - name: twemproxy
      image: ganomede/twemproxy
      command:
        - "nutcracker"
        - "-c"
        - "/etc/config/nutcracker.yml"
        - "-v"
        - "7"
        - "-s"
        - "6222"
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: twem-config

解説

  • StatefulSetにて、Redisコンテナを3台定義しています
  • DeploymentにてNginxとtwemproxyコンテナをもつPodを定義しています
  • 下記に記載してあるtwemproxy用の設定ファイルを参照できるようにconfigMapとそのマウントを定義しています
  • nginxコンテナからは同一Pod上にtwemproxyコンテナが存在するので、127.0.0.1:6379でtwemproxyに接続ができます

事前にconfigMapに登録しておく、twemproxyの設定ファイルは下記のようになります。

nutcracker.yml
redis:
  listen: 127.0.0.1:6379
  hash: fnv1a_64
  distribution: ketama
  auto_eject_hosts: true
  redis: true
  timeout: 400
  server_retry_timeout: 2000
  server_failure_limit: 1
  servers:
   - sharded-redis-0.redis:6379:1
   - sharded-redis-1.redis:6379:1
   - sharded-redis-2.redis:6379:1

minikube上での実行

# 最初にconfigMapにtwemproxy用の設定ファイルを登録します
kubectl create configmap twem-config --from-file=./nutcracker.yml

# デプロイします
kubectl apply -f twemproxy.yml

# redisクライアントでの動作確認
# nginxコンテナでbashを起動します
kubectl exec -it ambassador-example --container nginx bash 
# redis-cliをインストールします
apt update
apt install -y redis-tools

# twemproxy経由で値をRedisに格納します
redis-cli
127.0.0.1:6379> set hoge 1
127.0.0.1:6379> set fuga 2

# twemproxy経由で値を取得します
127.0.0.1:6379> get hoge

# ローカルマシンに戻り、下記の各コマンドで、各Redisの登録されたキーを確認できます
kubectl exec -it sharded-redis-0 --container redis redis-cli
127.0.0.1:6379> keys *
kubectl exec -it sharded-redis-1 --container redis redis-cli
127.0.0.1:6379> keys *
kubectl exec -it sharded-redis-2 --container redis redis-cli
127.0.0.1:6379> keys *

アダプタパターン

アダプタパターンはメインのコンテナの不均一なインターフェースを吸収し、統一されたインターフェースを外部に公開するのに利用するパターンです。
監視用のインターフェースを提供するのによく利用します。
adapter.png

ex1. redis-exporter

redis_exporterを使い、監視ツールPrometheus用のインターフェースを提供するパターンです。

構成は下記のようになります。

    +------------+        +-------+
    | Prometheus |        |  app  |
    +------------+        +-------+
          | get metrics       |
+---------+----------------------------+
|         |                   |        |
| +----------------+   +-------------+ |
| | redis_exporter |---|    redis    | |
| |   <Container>  |   | <Container> | |
| +----------------+   +-------------+ |
|                <Pod>                 |
+--------------------------------------+
  • RedisはPrometheus用リソース監視I/Fは持っていませんが、この構成で提供できます

マニフェスト

マニュフェストは以下のようになります。

redis-with-exporter.yml
---
apiVersion: v1
kind: Pod
metadata:
  name: adapter-example
  namespace: default
  labels:
    app: exporter
spec:
  containers:
    - name: redis
      image: redis
    - name: exporter
      image: oliver006/redis_exporter
      ports:
        - containerPort: 9121
---
apiVersion: v1
kind: Service
metadata:
  name: exporter
  labels:
    app: exporter
spec:
  selector:
    app: exporter
  type: NodePort
  ports:
    - port: 9121
      targetPort: 9121

解説

  • Pod内にRedisコンテナとredis_exporterコンテナを定義しています
  • Serviceでredis_exporterを外部に公開しています

minikube上での実行

# デプロイします
kubectl apply -f redis-with-exporter.yml

# 下記コマンドで、Prometheus用I/Fにアクセスし、メトリクスが取得できることを確認します
curl $(minikube service exporter --url)/metrics

ex2. mysql rich healthcheck

golang製のリッチなMySQL用ヘルスチェックツールによるアダプタパターンです。

構成は下記のようになります。

                             +--------+
                             | Client |
                             +--------+
                                  |
                                  | access to "/"
                                  |
+---------------------------------------------+
|                                 |           |
| +-------------+       +-------------------+ |
| |    MySQL    | query | mysql-healthcheck | |
| | <Container> |-------|    <Container>    | |
| +-------------+       +-------------------+ |
|                    <Pod>                    |
+---------------------------------------------+
  • reireias/mysql-healthcheckを利用して、MySQLに特定のクエリを発行してヘルスチェックを行います
  • mysql-healthcheckコンテナへアクセスがあった際にクエリは発行されます

マニフェスト

マニュフェストは下記のようになります。

mysql-with-rich-healthcheck.yml
---
apiVersion: v1
kind: Service
metadata:
  name: healthcheck
spec:
  type: NodePort
  ports:
    - name: healthcheck
      port: 8080
      targetPort: 8080
  selector:
    app: mysql
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: mysql:5.6
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: password
            - name: MYSQL_USER
              value: user
            - name: MYSQL_PASSWORD
              value: password
            - name: MYSQL_DATABASE
              value: test
          ports:
            - name: mysql
              containerPort: 3306
          volumeMounts:
            - name: mysql-persistent-storage
              mountPath: /var/lib/mysql
        - name: healthcheck
          image: reireias/mysql-healthcheck
          env:
            - name: MYSQL_USER
              value: user
            - name: MYSQL_PASSWORD
              value: password
            - name: MYSQL_DATABASE
              value: test
            - name: MYSQL_QUERY
              value: 'show databases;'
            - name: MYSQL_HOST
              value: mysql
            - name: MYSQL_PORT
              value: '3306'
            - name: ADDRESS
              value: 0.0.0.0:8080
          ports:
            - name: healthcheck
              containerPort: 8080
      volumes:
        - name: mysql-persistent-storage
          persistentVolumeClaim:
            claimName: mysql-pv-claim
mysql-pv.yml
---
kind: PersistentVolume
apiVersion: v1
metadata:
  name: mysql-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

解説

  • MySLQコンテナとmysql-healthcheckコンテナをDeploymentで定義しています
  • 個々のコンテナの環境変数で設定を指定しています
  • mysql-healthcheckをServiceで公開するように定義しています
  • PersistentVolumeは依存関係で事前に作成するため、別のマニュフェストファイルとして作成しています

minikube上での実行

# PersistentVolumeをデプロイします
kubectl apply -f mysql-pv.yml

# PodとServiceをデプロイします
kubectl apply -f mysql-with-ritch-healthcheck.yml

# ヘルスチェックが実行されるか確認します
curl $(minikube service healthcheck --url)
# OKと返るはずです

まとめ

分散システムで利用できるデザインパターンのうち、シングルノードパターンを実例とともにいくつか紹介しました。
意外と既に実践していたパターンがいくつかあったのではないでしょうか?
デザインパターンは知っておくと便利ですし、それに適したコンテナがDockerHubで公開されていたりするので、活用していきましょう。

31
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
reireias
SRE(Site Reliability nEko)
medpeer
国内医師の3人に1人が参加する国内有数のUGC型ドクタープラットフォーム「MedPeer」や遠隔医療サービスなどを運営するヘルステックカンパニー

Comments

No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
31
Help us understand the problem. What is going on with this article?