Slide 1
Slide 1 text
© 2019 catabira Inc.
catabira.com における Amazon EKS 活用事例
Kubernetes による継続的デリバリ編
株式会社catabira
池内 孝啓 / Takahiro Ikeuchi
1
Slide 2
Slide 2 text
自己紹介
2
Slide 3
Slide 3 text
池内 孝啓 / Takahiro Ikeuchi
● 株式会社catabira 代表取締役 CEO
○ 株式会社SQUEEZE 技術顧問
3
ITベンチャー数社を経て2011年に 株式会社ALBERT へ入社。ECサイト向け
商品推薦システムの開発やデータ活用クラウドプラットフォーム事業の立ち上げ
などに従事。執行役員として2015年に東証マザーズ上場を経験後、独立起業。
Slide 4
Slide 4 text
ソフトウェア・エンジニアとして
Python や Go、React などによる アプリケーション開発のほか、
ブロックチェーンやビッグデータ領域、Webデザインなどを広く手がける
4
Slide 5
Slide 5 text
follow me!
5
@iktakahiro
@iktakahiro
Slide 6
Slide 6 text
Agenda
6
Slide 7
Slide 7 text
Agenda（40分）
1. 自己紹介（2分）
2. 会社・プロダクト紹介（3分）
3. 技術スタック & AWS システム構成紹介（5分）
4. Kubernetes と 継続的デリバリ（20分）
5. EKS / k8s Tips（5分）
6. 質疑応答（5分）
7
Slide 8
Slide 8 text
今日伝えたい 3つのこと
● Kubernetes は楽しいのでぜひトライを！
● Kubernetes でもこれまでの CI, CD の考え方は変わらない（と思う）
● EKS はプロダクション環境に導入して問題なし
8
Slide 9
Slide 9 text
今日話さないこと
● Amazon EKS 以外の Kubernetes マネージドサービスとの比較
● Kubernetes 自体の解説
9
Slide 10
Slide 10 text
会社紹介
10
Slide 11
Slide 11 text
株式会社catabira / catabira Inc.
● 設立 : 2015年8月4日
● 代表取締役 : 池内 孝啓
● 本社 : 東京都新宿区新宿7丁目26-7 ビクセル新宿1F
11
創業時よりスタートアップ企業やエンジニアのための B2B SaaS を開発・運営。
2018年よりブロックチェーン領域へ進出。
2019年1月、ブロックチェーン特化型データアナリティクス・プラットフォーム
catabira.com をローンチ。
Slide 12
Slide 12 text
社名の由来とロゴについて
社名である catabira (カタビラ) の由来は鎖帷子（くさりかたびら）。
ブロックチェーンの鎖を想起させるとともに、人々の結びつきが織りなす
ネットワークを表します。帷子は日本の伝統的な衣服でもあります。
12
ロゴは、人とテクノロジーの未来を示す "羅針盤" という企業理念を反映し、
航海に用いるコンパスをモチーフとしてデザインされました。
明るい未来への期待と調和への願いが込められています。
Slide 13
Slide 13 text
役員紹介
13
代表取締役 CEO
池内 孝啓
取締役 CTO
中村 智浩
取締役
花村 直親
Slide 14
Slide 14 text
プロダクト紹介
14
Slide 15
Slide 15 text
ブロックチェーン特化型
データアナリティクス・プラットフォーム
15
Slide 16
Slide 16 text
catabira.com とは
ブロックチェーン・サービスのためのデータアナリティクス・プラットフォーム
第一弾としてモニタリング機能を SaaS として提供
16
Slide 17
Slide 17 text
ブロックチェーン・データを可視化
暗号通貨のトランザクション量や残高情報など重要なメトリクスを
時系列チャートとして可視化。日々の変動や傾向が一目瞭然に。
17
Slide 18
Slide 18 text
18
● 対象メトリクスや集計方法・期間を
柔軟に指定可能
● 意図しない取引や残高の減少を検知
● チャットサービスへの通知や
Webhook によるシステム連携に対応
異常検知を
リアルタイムに通知
Slide 19
Slide 19 text
技術スタック
19
Slide 20
Slide 20 text
おもな採用言語・サービスなど
● Go, TypeScript, YAML
● React, MobX
● AWS Lambda, Amazon Aurora
● Amazon EKS, Kubernetes
● Elasticsearch
● Netlify
● New Relic
● CircleCI
● Google BigQuery
20
Slide 21
Slide 21 text
おもな採用言語・サービスなど
● Go, TypeScript, YAML
● React, MobX
● AWS Lambda, Amazon Aurora
● Amazon EKS, Kubernetes
● Elasticsearch
● Netlify
● New Relic
● CircleCI
● Google BigQuery
このへんが
本日のメイントピック
つらい
21
Slide 22
Slide 22 text
AWS 構成概略図
22
● EKS
● ALB（Ingress）
● EC2 Node Group x 3
● EBS（PV）
● Aurora PostgreSQL
● SQS, Lambda
● CloudFront
Slide 23
Slide 23 text
ブロックチェーンと
Kubernetes
23
Slide 24
Slide 24 text
ブロックチェーン事業者 特有の悩み:
ノードの運用どうしよう問題
● https://github.com/paritytech/parity-ethereum
● Parity = Ethereum クライアントの1つ
● Rust + RocksDB
● 同期に時間がかかる（3Hours, nDays 〜）
● ディスク容量を食う（100GB 〜, 1TB 〜）
● まれにデータが壊れる
要するに RDB や NoSQL を EC2 + EBS で運用するようなものなので 色々つらい
24
EC2
Parity プロセス
EBS
ブロックチェーンデー
タ
Slide 25
Slide 25 text
WorkAround 1 : Persistent Volumes
25
Slide 26
Slide 26 text
PersistentVolume の設定例
apiVersion: v1
kind: PersistentVolume
metadata:
name: parity-pv
annotations:
pv.beta.kubernetes.io/gid: "1000"
spec:
capacity:
storage: 300Gi
accessModes:
- ReadWriteOnce
storageClassName: parity-sg
persistentVolumeReclaimPolicy: Retain
awsElasticBlockStore:
volumeID: your-volume-id
fsType: ext4
26
Slide 27
Slide 27 text
PersistentVolumeClaim の設定例
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: parity-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 300Gi
storageClassName: parity-sg
27
Slide 28
Slide 28 text
Deployment の設定例（抜粋）
apiVersion: apps/v1
kind: Deployment
# ...
volumeMounts:
- name: parity-volume
mountPath: "/parity-data"
# ...
volumes:
- name: parity-volume
persistentVolumeClaim:
claimName: parity-pvc
28
Slide 29
Slide 29 text
PersistentVolume で得られるもの
● Root Volume と異なり不揮発なボリュームを得られる（EBS なので）
● Amazon Data Lifecycle Manager でバックアップ管理が可能（EBS なので）
PersistentVolume で失うもの
● Availability Zone をまたげない（EBS なので！）
29
Slide 30
Slide 30 text
WorkAround 2 : Stateful Sets
30
Slide 31
Slide 31 text
31
Load Balancer 配下に Stateful Sets を並べる作戦
● 参考 : https://github.com/carlolm/kube-parity
● スケールはするが運用の負が解消するわけではない
Stateful Sets
Slide 32
Slide 32 text
わたしたちは
Amazon Managed Blockchain を
応援しています ლ(╹◡╹ლ)
32
Slide 33
Slide 33 text
Kubernetes と
継続的デリバリ
33
Slide 34
Slide 34 text
継続的デリバリとは（おさらい）
● ソフトウェアを継続的に出荷できること
● デプロイ・フィードバック・改善のイテレーションを高速に回すこと
34
Slide 35
Slide 35 text
Kubernetes と継続的デリバリ
● 基本的な考え方はこれまでと同じ
● マニフェストファイルをどう管理・運用していくかが鍵
35
Slide 36
Slide 36 text
CircleCI config.yml 設定例（抜粋）
version: 2.1
orbs:
aws-eks: tiendanube/[email protected]
# ...
jobs:
deployment:
docker:
- image: 'circleci/openjdk:8-jdk'
steps:
- aws-eks/deploy:
cluster_name: my-eks-cluster-name
region: us-east-1
steps:
- checkout
- run: kubectl apply -f deployment.yml
36
Slide 37
Slide 37 text
CircleCI によるマニフェスト適用・更新の課題
● 環境によって ConfigMap の内容を変えたい
● 環境によって一部パラメータ（ReplicaSet の数とか）を変えたい
● ConfigMap だけを変更した場合でも Deployment に反映したい
37
Slide 38
Slide 38 text
CircleCI によるマニフェスト適用・更新の課題
● 環境によって ConfigMap の内容を変えたい
● 環境によって一部パラメータ（ReplicaSet の数とか）を変えたい
● ConfigMap だけを変更した場合でも Deployment に反映したい
それ全部 kustomize でできるよ！
38
Slide 39
Slide 39 text
kustomize とは
● https://github.com/kubernetes-sigs/kustomize
● k8s の YAML ファイル群をよしなに管理できるコマンドラインツール
● ざっくりイメージ : 複数の YAML ファイルを部分更新して結合してくれる
39
Slide 40
Slide 40 text
kustomize 利用時のディレクトリ構成例
├── base
│ ├── alb-deployment.yml
│ ├── api-deployment.yml
│ └── kustomization.yml
├── prod
│ ├── alb-deployment-patch.yml
│ ├── api-deployment-patch.yml
│ └── kustomization.yml
└── stage
├── alb-deployment-patch.yml
├── api-deployment-patch.yml
└── kustomization.yml
40
Slide 41
Slide 41 text
base/kustomization.yml 設定例
resources:
- api-deployment.yml
- alb-deployment.yml
● 複数ファイルを連結
41
Slide 42
Slide 42 text
stage/kustomization.yml 設定例
bases:
- ./../base
configMapGenerator:
- name: catabira-api-configmap
literals:
- ENV="stage"
- AWS_DEFAULT_REGION="us-east-1"
# ...
patches:
- alb-deployment-patch.yml
- api-deployment-patch.yml
● base/kustomization.yml を参照
● 環境ごとの Environment 指定（stage 用）
42
Slide 43
Slide 43 text
prod/kustomization.yml 設定例
bases:
- ./../base
configMapGenerator:
- name: catabira-api-configmap
literals:
- ENV="prod"
- AWS_DEFAULT_REGION="us-east-1"
# ...
patches:
- alb-deployment-patch.yml
- api-deployment-patch.yml
● base/kustomization.yml を参照
● 環境ごとの Environment 指定（prod 用）
43
Slide 44
Slide 44 text
stage/api-deployment-path.yml 設定例
apiVersion: apps/v1
kind: Deployment
metadata:
name: catabira-api
spec:
replicas: 1
● base/api-deployment.yml の設定に追記・上書き更新したい項目を記述
44
Slide 45
Slide 45 text
prod/api-deployment-path.yml 設定例
spec:
replicas: 2
strategy:
rollingUpdate:
maxSurge: 3
maxUnavailable: 1
type: RollingUpdate
● プロダクション環境は 複数レプリカ、ローリングアップデートを指定
45
Slide 46
Slide 46 text
マニフェストファイル群の生成と適用
kustomize build ./stage | kubectl apply -f -
46
● ここまで準備できればあとは CircleCI の準備をするだけ！
Slide 47
Slide 47 text
CircleCI + kustomize
47
Slide 48
Slide 48 text
デプロイメント戦略
● develop ブランチへのマージ
-> ステージング環境にデプロイ
● master ブランチへのマージ
-> プロダクション環境にデプロイ
● git-flow に基づくブランチ運用（従来と同じ）
48
Slide 49
Slide 49 text
デプロイメント・プロセス
1. ブランチへのマージをフックにビルド開始
2. ユニットテストを実行
3. Docker イメージを生成
4. Amazon ECR に Docker イメージをプッシュ
5. kustomize でマニフェストファイルを生成
6. kubectl でマニフェストファイルを apply
49
Slide 50
Slide 50 text
CircleCI config.yml
version: 2.1
orbs:
aws-ecr: circleci/[email protected]
# ...
jobs:
# ...
deployment:
docker:
- image: 'circleci/openjdk:8-jdk'
parameters:
tag:
type: string
env:
type: enum
enum: ['stage', 'prod']
50
Slide 51
Slide 51 text
CircleCI config.yml - 続き
steps:
- aws-eks/deploy:
cluster_name: your-eks-<< parameters.env >>-cluster-name
region: us-east-1
steps:
- checkout
# ...
- run: ./kustomize build ./<< parameters.env >> | kubectl apply -f -
● パラメータ env の値 でどのディレクトリを対象にして build するかを
切り分け
51
Slide 52
Slide 52 text
質疑応答
52
Slide 53
Slide 53 text
今日話したおもなこと
● catabira の EKS 構成例
● ブロックチェーン領域特有の課題感について
● kustomize でマニフェストファイルを良い感じに管理する方法
● ECR, EKS への操作をデプロイメント・プロセスに載せる方法
53
Slide 54
Slide 54 text
EKS & k8s Tips
54
Slide 55
Slide 55 text
eksctl を使う
● https://eksctl.io/
● EKS やノードグループの構築をよしなにやってくれるコマンドラインツール
● よしなにやってくれるあまり一部 暗黙的な設定変更をする点には注意
● 他の選択肢 : Terraform, kops
55
公式ドキュメント : Amazon EKS の使用開始 はおすすめしません
（挫折しちゃいそうなので）
Slide 56
Slide 56 text
New Relic を使う
● パフォーマンスモニタリグ SaaS
● k8s のモニタリングに対応したマニフェストあり
● コンテナが期待数立ちあがっているかの監視も行える
● 他の選択肢 : Datadog, Mackerel
56
Slide 57
Slide 57 text
57
CloudWatch Logs でコンテナログを保全する
● コンテナが異常終了して削除されたときログもロストするようだと
調査ができない問題
● https://kubernetes.io/docs/concepts/cluster-administration/logging/
● 取り急ぎとして CloudWatch Logs への保全をおすすめ
○ Fluentd を DaemonSet として稼働させるのが楽
● 他の選択肢 : Datadog Log Management, Stackdriver, Elasticsearch
Slide 58
Slide 58 text
AWS ALB Ingress Controller for Kubernete を使う
● https://github.com/kubernetes-sigs/aws-alb-ingress-controller
● マニフェストファイルとして ALB を定義・構築可能
58
metadata:
name: catabira-api-ingress
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/backend-protocol: HTTP
● 独立して管理したほうがよいという説も（要出典
Slide 59
Slide 59 text
Virginia Region を使う
● GA が 2018.06.05 、そこから 6ヶ月後の 2018.12.05 に Tokyo でローンチ
● catabira は 2018.08 時点から検証を開始したので知見が貯められた
● みんなが好きな Web サービスの多くは Tokyo リージョンにないし
Tokyo リージョンを使う意味はないのではないか説
59
※ レイテンシにシビアであったり法務的に国内リージョンに置いたほうがよい
判断がなされた場合を除く
Slide 60
Slide 60 text
60
Worker は Private Subnet に配置し SSM を使う
● Worker ノードは Master ノードと疎通できればいいので
Public に置く意味は基本ないです（一応 用途による）
● Private エリアへの SSH 接続用に踏み台サーバーを用意するのは辛いので
Session Manager を使おう
○ IAM と紐付くので、鍵を共有してしまう運用あるあるよりはセキュア