catabira.com における Amazon EKS 活用事例Kubernetes による継続的デリバリ編 / eks-cd-usecase-at-catabira

Slide 1

Slide 1 text

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 と紐付くので、鍵を共有してしまう運用あるあるよりはセキュア