Upgrade to Pro — share decks privately, control downloads, hide ads and more …

catabira.com における Amazon EKS 活用事例 Kubernetes によ...

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

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

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

Takahiro Ikeuchi

March 20, 2019
Tweet

More Decks by Takahiro Ikeuchi

Other Decks in Technology

Transcript

  1. © 2019 catabira Inc. catabira.com における Amazon EKS 活用事例 Kubernetes

    による継続的デリバリ編 株式会社catabira 池内 孝啓 / Takahiro Ikeuchi 1
  2. 池内 孝啓 / Takahiro Ikeuchi • 株式会社catabira 代表取締役 CEO ◦

    株式会社SQUEEZE 技術顧問 3 ITベンチャー数社を経て2011年に 株式会社ALBERT へ入社。ECサイト向け 商品推薦システムの開発やデータ活用クラウドプラットフォーム事業の立ち上げ などに従事。執行役員として2015年に東証マザーズ上場を経験後、独立起業。
  3. Agenda(40分) 1. 自己紹介(2分) 2. 会社・プロダクト紹介(3分) 3. 技術スタック & AWS システム構成紹介(5分)

    4. Kubernetes と 継続的デリバリ(20分) 5. EKS / k8s Tips(5分) 6. 質疑応答(5分) 7
  4. 今日伝えたい 3つのこと • Kubernetes は楽しいのでぜひトライを! • Kubernetes でもこれまでの CI, CD

    の考え方は変わらない(と思う) • EKS はプロダクション環境に導入して問題なし 8
  5. 株式会社catabira / catabira Inc. • 設立 : 2015年8月4日 • 代表取締役

    : 池内 孝啓 • 本社 : 東京都新宿区新宿7丁目26-7 ビクセル新宿1F 11 創業時よりスタートアップ企業やエンジニアのための B2B SaaS を開発・運営。 2018年よりブロックチェーン領域へ進出。 2019年1月、ブロックチェーン特化型データアナリティクス・プラットフォーム catabira.com をローンチ。
  6. おもな採用言語・サービスなど • Go, TypeScript, YAML • React, MobX • AWS

    Lambda, Amazon Aurora • Amazon EKS, Kubernetes • Elasticsearch • Netlify • New Relic • CircleCI • Google BigQuery 20
  7. おもな採用言語・サービスなど • Go, TypeScript, YAML • React, MobX • AWS

    Lambda, Amazon Aurora • Amazon EKS, Kubernetes • Elasticsearch • Netlify • New Relic • CircleCI • Google BigQuery このへんが 本日のメイントピック つらい 21
  8. AWS 構成概略図 22 • EKS • ALB(Ingress) • EC2 Node

    Group x 3 • EBS(PV) • Aurora PostgreSQL • SQS, Lambda • CloudFront
  9. ブロックチェーン事業者 特有の悩み: ノードの運用どうしよう問題 • https://github.com/paritytech/parity-ethereum • Parity = Ethereum クライアントの1つ

    • Rust + RocksDB • 同期に時間がかかる(3Hours, nDays 〜) • ディスク容量を食う(100GB 〜, 1TB 〜) • まれにデータが壊れる 要するに RDB や NoSQL を EC2 + EBS で運用するようなものなので 色々つらい 24 EC2 Parity プロセス EBS ブロックチェーンデー タ
  10. 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
  11. PersistentVolumeClaim の設定例 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: parity-pvc spec:

    accessModes: - ReadWriteOnce resources: requests: storage: 300Gi storageClassName: parity-sg 27
  12. Deployment の設定例(抜粋) apiVersion: apps/v1 kind: Deployment # ... volumeMounts: -

    name: parity-volume mountPath: "/parity-data" # ... volumes: - name: parity-volume persistentVolumeClaim: claimName: parity-pvc 28
  13. PersistentVolume で得られるもの • Root Volume と異なり不揮発なボリュームを得られる(EBS なので) • Amazon Data

    Lifecycle Manager でバックアップ管理が可能(EBS なので) PersistentVolume で失うもの • Availability Zone をまたげない(EBS なので!) 29
  14. 31 Load Balancer 配下に Stateful Sets を並べる作戦 • 参考 :

    https://github.com/carlolm/kube-parity • スケールはするが運用の負が解消するわけではない Stateful Sets
  15. 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
  16. 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
  17. 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
  18. 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
  19. stage/api-deployment-path.yml 設定例 apiVersion: apps/v1 kind: Deployment metadata: name: catabira-api spec:

    replicas: 1 • base/api-deployment.yml の設定に追記・上書き更新したい項目を記述 44
  20. prod/api-deployment-path.yml 設定例 spec: replicas: 2 strategy: rollingUpdate: maxSurge: 3 maxUnavailable:

    1 type: RollingUpdate • プロダクション環境は 複数レプリカ、ローリングアップデートを指定 45
  21. マニフェストファイル群の生成と適用 kustomize build ./stage | kubectl apply -f - 46

    • ここまで準備できればあとは CircleCI の準備をするだけ!
  22. デプロイメント戦略 • develop ブランチへのマージ -> ステージング環境にデプロイ • master ブランチへのマージ ->

    プロダクション環境にデプロイ • git-flow に基づくブランチ運用(従来と同じ) 48
  23. デプロイメント・プロセス 1. ブランチへのマージをフックにビルド開始 2. ユニットテストを実行 3. Docker イメージを生成 4. Amazon

    ECR に Docker イメージをプッシュ 5. kustomize でマニフェストファイルを生成 6. kubectl でマニフェストファイルを apply 49
  24. 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
  25. 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
  26. 今日話したおもなこと • catabira の EKS 構成例 • ブロックチェーン領域特有の課題感について • kustomize

    でマニフェストファイルを良い感じに管理する方法 • ECR, EKS への操作をデプロイメント・プロセスに載せる方法 53
  27. eksctl を使う • https://eksctl.io/ • EKS やノードグループの構築をよしなにやってくれるコマンドラインツール • よしなにやってくれるあまり一部 暗黙的な設定変更をする点には注意

    • 他の選択肢 : Terraform, kops 55 公式ドキュメント : Amazon EKS の使用開始 はおすすめしません (挫折しちゃいそうなので)
  28. New Relic を使う • パフォーマンスモニタリグ SaaS • k8s のモニタリングに対応したマニフェストあり •

    コンテナが期待数立ちあがっているかの監視も行える • 他の選択肢 : Datadog, Mackerel 56
  29. 57 CloudWatch Logs でコンテナログを保全する • コンテナが異常終了して削除されたときログもロストするようだと 調査ができない問題 • https://kubernetes.io/docs/concepts/cluster-administration/logging/ •

    取り急ぎとして CloudWatch Logs への保全をおすすめ ◦ Fluentd を DaemonSet として稼働させるのが楽 • 他の選択肢 : Datadog Log Management, Stackdriver, Elasticsearch
  30. 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 • 独立して管理したほうがよいという説も(要出典
  31. Virginia Region を使う • GA が 2018.06.05 、そこから 6ヶ月後の 2018.12.05

    に Tokyo でローンチ • catabira は 2018.08 時点から検証を開始したので知見が貯められた • みんなが好きな Web サービスの多くは Tokyo リージョンにないし Tokyo リージョンを使う意味はないのではないか説 59 ※ レイテンシにシビアであったり法務的に国内リージョンに置いたほうがよい   判断がなされた場合を除く
  32. 60 Worker は Private Subnet に配置し SSM を使う • Worker

    ノードは Master ノードと疎通できればいいので Public に置く意味は基本ないです(一応 用途による) • Private エリアへの SSH 接続用に踏み台サーバーを用意するのは辛いので Session Manager を使おう ◦ IAM と紐付くので、鍵を共有してしまう運用あるあるよりはセキュア