会社の納会用に投票アプリを作りました（Kubernetes）

alt

オプト社内で先日納会が行われ、その中でOpt-Technologiesとして出し物用のWebアプリを作成しました。この記事では、今回の納会アプリのインフラ構成（Kubernetes/k8s）について解説します。

あいさつ
仕様
システム構成図
Google Container Engine (GKE)
Cloud DNS
Network Load Balancer
- LoadBalancer serviceに関する余談
Kubernetes
ハマった点
- Resource Quotaは設定必須
まとめ

あいさつ

どうも、 @ocadaruma です。

オプトでは半期ごとに納会を開催しており、先日行われた2016年度下期の納会では、様々な出し物の披露とともに、社員の表彰などがありました。

Opt-Technologiesも前回に引き続き、出し物に使うWebアプリを提供しました。

前回の技術スタックは納会の余興としてはオーバーキル気味でしたが、今回もそのマインドを受け継ぎ、技術検証の場として好き放題に利用させてもらいました。

この記事では、今回の納会アプリのインフラ周りについて解説します。

よろしければ、前回の納会アプリの記事も合わせてご覧下さい。

tech-magazine.opt.ne.jp

仕様

前回はクイズアプリでしたが、今回は投票アプリです。

有権者数は1000人ほど。
一人あたりの持ち票は10票。
AとB(仮名)が競うコンテンツが流れるので、好きな方に好きなだけ(10票以内で)票を投じる。
票数がリアルタイムで表示される。（焦りを誘う）
投票は全7回戦。
全投票が終わったら、管理者はランキング画面を表示する。
ランキング画面では、「7回戦通して、勝ち馬に投じた票数順」上位50名をカウントダウン表示

1人あたり10票持っているため、前回よりもリクエストが集中することが想定されます。

システム構成図

Kubernetes(k8s)を検証する名目で、投票アプリのシステム構成は下記のようにしました。

architecture

以降、それぞれについて解説していきます。

Google Container Engine (GKE)

GCPのマネージドk8s クラスタです。
この図には載せていませんが、dockerイメージはContainer Registryでホスティングしています。
本番は以下の2ノードで運用しました。（デフォルトのQuotaに引っかかり、n1-highmem-16で揃えられなかった）
- n1-highmem-16 × 1
- n1-highmem-8 × 1

Cloud DNS

せっかくなので納会専用にドメインを取得し、DNSサーバにCloud DNSを使用しました。
- Route53と違ってレジストラの機能は持ってないので、取得は別サービスを使いました...

Network Load Balancer

GKEでは、k8sのLoadBalancer serviceを作成すると、Network Load Balancerおよびターゲットプールが自動的に作られます。
最初はL7 Load Balancerを使ってSSL terminationもやろうとしたのですが、今回のアプリはWebSocketを利用するため断念し、各Podにtermination用のNginxを挟むことにしました。
- 参考: https://cloud.google.com/compute/docs/load-balancing/http/

LoadBalancer serviceに関する余談

LoadBalancer serviceを作成すると、Network Load Balancerつまり特定のポートの転送ルールが作られるわけですが、ということは80番をexposeするLoadBalancer serviceは一つしか作れないのか？と思いませんか？（port rewritingを行うようなGCEインスタンスが別途立ったりもしない）
もちろんそんなことはなく、k8sの各ノードに、転送ルールの外部IPからのパケットを振り分けるiptablesルールが設定されるため、特定のserviceへトラフィックを流すことができる仕組みになっています。
- 参考: http://qiita.com/apstndb/items/9d13230c666db80e74d0

Kubernetes

Services

Webアプリを外部にexposeするLoadBalancer serviceと、内部でのRedisへのエンドポイントを提供するClusterIP serviceの2つを作成しました。
ちなみに、minikubeなどローカル環境で動かしている場合でも、LoadBalancer serviceを作ることで自動的にNodePortも開くため、動作確認は問題なく行えます。(もちろんLBは立ちません)

---
apiVersion: v1
kind: Service
metadata:
  name: redis-service
  namespace: production
spec:
  type: ClusterIP
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    app: redis
---
apiVersion: v1
kind: Service
metadata:
  name: app-service
  namespace: production
spec:
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 443
  selector:
    app: server

Pod (Nginx + App)

前述の通り、今回の要件ではLBでSSL terminationが出来ないため、Akka-HTTPアプリの前にNginxを立てています。
yamlはこのような感じになりました。

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app-deployment
  namespace: production
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: server
      namespace: production
    spec:
      containers:
      - name: proxy
        image: /path/to/nginx_image
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        - containerPort: 443
        readinessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 5
          timeoutSeconds: 10
      - name: server
        image: /path/to/app_image
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3000
        env:
        - name: SERVER_PORT
          value: "3000"
        - name: REDIS_HOST
          value: "redis-service"
        - name: REDIS_PORT
          value: "6379"
        resources:
          limits:
            memory: "2500Mi"

Pod (Redis)

状態の共有および、リアルタイム投票結果のbroadcastにはRedisを使用しました。
- アプリのPodを複数立てるので、全WebSocketコネクションに投票結果を通知するために必要です。
実プロダクトで利用する際はReplicationやRedis-Clusterを利用すると思いますが、今回はSingle Podです。

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: redis-deployment
  namespace: production
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:3.2.6-alpine
        ports:
        - containerPort: 6379

ハマった点

Resource Quotaは設定必須

負荷試験で大量のコネクションを張った際、ノードごとunhealthyになって再起動を要する現象が発生しました。
k8sでは、Resource Quotaはデフォルトでかかっていないので、適切に設定しておくことが必要です。
- 参考: https://kubernetes.io/docs/admin/resourcequota/

まとめ

オプトではデプロイのcontainerizeはあまり進んでいないのが現状ですが、今回GKEを利用してみて、containerizeの知見がある程度得られました。
- ローカルと環境を揃えやすい点 / 簡単に複数環境を用意できる点 / デプロイが早い点がメリットに感じました。
今後、containerデプロイが適しそうな場面があれば、積極的に利用していきたいです。