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

JAWS-UG コンテナ支部 14 のセッションで使用した資料です。

* https://jawsug-container.connpass.com/event/122013/

Transcript

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