この記事はJAWS-UG コンテナ支部 #14のブログ参加枠のためのものになります。
Abema Towersの柿落し勉強会でした!
catabira.com における Amazon EKS 活用事例 - Kubernetes による継続的デリバリ編
- 池内孝啓さん(@iktakahiro / 株式会社 catabira CEO)
- 発表スライド
- CircleCIはじめYAML全編の発表
- 自己紹介
- 前職ではDWH(RedShift)の話をよくしていた
- JAWS中央線の立ち上げにかかわっていた
- Python, Go好き
- 本もいくつかだしました
- EKSのCDの話がメイン
- k8sでもCI/CDの考え方はかわらない
- EKSは本番環境でも導入して問題なし
- EKS起因の問題は発生していない
- 話さないこと
- EKS以外のk8s
- k8s自体の話
- 会社紹介
- ブロックチェーンをやっているスタートアップ
- 役員全員コード書いてプロダクト作っている
- B/C専用のデータアナリティクスSaaS
- Public Beta
- トランザクションの可視化
- リアルタイム異常検知
- 流出事件は未だ絶えない
- B/Cのモニタリングはプレイヤーがまだ少ない
- 使用言語
- Go, TS, YAML, etc.
- YAMLつらい…
- AWS構成図
- 3つのNodeGroupを使っている
- アプリが動いているもの
- EthereumのNode運用用
- リソース(メモリ)を必要とするので分離している
- Aurora PostgreSQL
- 3つのNodeGroupを使っている
- B/C事業者の悩み
- B/CのNode運用どうするか問題
- P2Pネットワークで各Nodeでデータをもつ
- Parity=クライアントの1つ
- Rustで書かれている
- RocksDB
- データ同期に時間がかかる
- ディスク容量が必要
- まれにデータが壊れる
- EC2とEBSでデータ運用するのがつらい
- PersistentVolumeを使って永続化
- Parity Nodeにmountする
- バックエンドはEBS
- EBSなのでバックアップ可能
- しかしながらEBSはA/Zをまたげない
- AWSからはこの構成は非推奨といわれたがやらざるをえない
- LB配下にStatefulSetsを並べる作戦
- https://github.com/carlolm/kube-parity
- 可用性を高められる
- これで全てが解決できるわけではない
- そこでAmazon Managed Blockchain!
- Ethereumはまだ未サポート
- まだプレビュー
- 世界中でまちのぞまれている
- k8sとCDの話
- k8sのマニフェストをどう管理・運用していくかが鍵
- コンテナ化されていることは前提
- CircleCI config.yml
- EKSコマンドが使えるOrbsを使う
- 課題
- 環境によってConfigMap変えたい
- 環境によって一部のパラメータを変えたい
- ConfigMap変更したらDeploymentで反映させたい
- 解決策
- kustomize使う
- YAMLのconcat、パラメータ差し替えなど
- 環境毎にdirectoryを切っている
- 共通YAMLはbase以下
- baseで
resourcesで複数YAMLをたばねている - 各環境内で
configMapGeneratorなどで設定を切り替えてる -
patches- baseのYAMLに追記・上書きしたいときに使用
- replicaの数やdeploy戦略の上書きなどで使う
- CircleCIでbuild and apply
- デプロイメント
- masterにマージされたら本番、developmentにマージされたらstagingにdeploy
- UnitTestしてimage build, image push to ECR
- kustomizeでdeploymentを更新
- CircleCIのパラメータ機能を使っている
- Orbsの機能
- 環境を渡している
- kustomizeでbuildするdirectoryを指定するのに使用
- cluster nameの切り替えにも使用
- QA
- どれぐらいデプロイに時間かかる?
- Goだと1minかかんないぐらい
- k8sのCDでkustomizeつかってると最終形のYAMLが見えにくくなるけど?
- kustomizeで再現性あるのでそのYAMLだけ管理することで担保している
- deploy前に差分確認したくなるけど?
- 勝手にkubectl使ってる人がいて事故ったことあったんでなんかやりたいと思ってる
- どれぐらいデプロイに時間かかる?
- Tips
- ekstclを使おう
- https://eksctl.io
- CFn使うのはおすすめしない
- Terraform, kopsもある
- New Relic使う
- パフォーマンスモニタリングとしてよくできてる
- Datadogなどはdaemonsetでagentをたてる、New Relicも同じ
- コンテナ起動数の期待値の監視など
- CloudWatch Logsでログ収集
- とりあえず最低限としてはよい
- FluentdをDaemonSetとして動かすのがよい
- Datadog Log Management, Stackdriver, ElasticSearchでもよい
- AWS ALB Ingress Controller for k8sを使う
- https://github.com/kubernetes-sigs/aws-alb-ingress-controller
- annotationで定義
- 証明書の自動更新してくれる
- もしかしたら罠があるかも
- Virginia Regionを使う
- Tokyoにきてないサービス使えるので
- Worker NodeはPrivate subnetにおいてSSMでSSHする
- 踏み台サーバ不要
- IAMで管理できる
- デバッグとかできる
- ekstclを使おう
ECSとFargateを本番投入して得た悲喜交交
- 田代和浩さん(@masa2129 / CyberAgent, Inc.)
- センター街を抜けて出社しないといけないのは心をもっていかれるｗ
- 自己紹介
- 一週間前にスキンヘッドにした
- スキンヘッドも本番投入したｗ
- 頭をimmutableにしたかった
- デメリット
- 寒い
- 暖房の風がすでに寒い
- 深剃りしても残る
- 寒い
- OpenSaaS Studio所属
- Fargateを本番でつかってみた
- 使いこなせなかった
- 捨ててしまおうかと思った
- でもSpark joyした
- Simply
- 社内向け課金決済基盤を開発
- ECS, Aurora, etc.
- サーバサイドKotlin
- EC2 typeとFargateの比較
- メリットはEC2管理しなくていい
- デメリットはsshできない、起動が遅い
- 起動遅い
- ELBのヘルスチェックにひっかかる
- sshできない
- トラシューむずかしい
- メモリリークの調査が難しかった
- ELSヘルスチェック kills ECS task
- 生き死にしてる
- unhealthyなので
- サイドカーを使う構成に変えたタイミングで起動時間が大幅に遅くなった
- AWSに問合せたら「ヘルスチェックの猶予期間」を変更することに
- ECSのサービス設定で変更可能
- ELB側ではない
- Datadogだとヘルスチェック失敗イベントのアラート設定楽にできる
- datadog monitor
- 生き死にしてる
- sshできない
- そもそもsshすべきじゃない
- log、metricsで状態を確認できるようにしておくべき
- …とはいえ不具合起きたときには背に腹は変えられない
- メモリリークの原因調査で苦しむ
- fargate jmx error
- 対応してくれない
- EC2で再現しようとしたが再現しなかった
- Spring Boot Actuator
- system metrics用のE/Pを提供してくれる
- curlでheapdumpを取得
- Datadog APMとSpring Webfluxを両方使っていると問題が起きていた
- fargate jmx error
- 邪道
- sshdコンテナをインストール
- まとめ
- マイクロサービス、Serverless、コンテナ運用
- 物理サーバ運用でやってたやり方は通用しない
- いろんなツールに助けてもらいながらシステムを作る
- 異常発生時に動けるようになっているか?
- Fargate好きです
- 周辺ツールの拡充を期待してる
- Fargateはサポートしていませんといわれて心折れそうになった…
- マイクロサービス、Serverless、コンテナ運用
- コンテナ起動順の制御ができるようになった
- 対応しているのはEC2のみですｗ
- QA
- Kotlinはコンテナ相性悪いと思うけどどうして採用したの?
- あとで辛いと思った
- Java経験者が多いチームだった
- Java辛いなでKotlinをえらんだ
- FargateはEC2より起動遅いというのはどれぐらい違いがあるの?
- ちゃんと比較はしてない
- いまだと180secsぐらいかかってる
- EC2だとヘルスチェックの猶予期間=0でも問題なかった
- Kotlinはコンテナ相性悪いと思うけどどうして採用したの?
LT
フロントエンドとマイクロサービスとコンテナの話
- スライド
- @ zozoテクノロジーズ
- よくあるフロントエンドのコンテナ活用例
- CIでnodeイメージをregitryにpush
- そういう話はしない
- コンテナとマイクロサービス
- ポリグロットだったり
- コンテナといえばmiscroservice
- miscroservieとfrontend
- frontも同じでAPIでデータを取得する
- SPA構成
- SPAの弱点
- SEOに弱い
- 画面の設計思想が変わる
- SSR/BFFの登場
- 初期レンダリングの高速化
- SEO対応
- SSR→API Aggregator→miscroservice
- SSR, API Aggregatorにコンテナを使う
- 仕様変更に素早く対応するため
- SSRするためにはServiceが必要
- showKs
- 技術書典に出展
Engineering life with containers on AWS
- スライド
- tnirさん
- DevOpstを支えるCI/CD動向
- EKS使っていきたい
- fintech, teleco, microservice DevOps
- k8sのオンライントレーニングした
- 45mins
- helm/charts
- EKSはコンソール上から作れるのでとっつきやすい
- コンプラ要件考えるとAWS
- ECSは使いにくい
ETL処理をServerlessにしてみた件
- リクルートの人
- Glueじゃないよ!
- 用途によってログの扱い方が違うよね
- Logstash→S3→Logstash→ElasticSearch
- ETLが複雑になるとCPUがきつい
- Multi pipelineをつかう
- EC2だとリソース気になる
- Fargateでやてみた
- リソース足りなくなってきたらtaskふやす
(途中きけてなかったです)
体当たりでecs-cli
- スライド
- ECSあるあるLT
- ecs-cliでcreate/updateのオプションが違う
- docker-composeを使いまわしたい
- できなかった
- volume指定してると使えない?
- ヘルスチェック(NLB)の頻度がすごい
- 1秒に一回以上くる
- deployが8minsぐらいかかる
- 以前は11mins
Farageはなにが嬉しいのか
- スライド
- コネヒトの人
- @shnagai
- PHPプロジェッショナル開発という本をかいた
- ママリの運用の話
- 半年ほどFargateをつかってる
- リソースの割り当てがシンプルになった
- EC2に意図通りにtaskを配置してくれているかの確認が煩雑
- Fargate起因の障害は0
FargateとECRでelastalert構築
- スライド
- 仮想通過取引所の運用してる人
- Elasticsearchの監視どうしてますか?
- elastalertをつかってる
- by Yelp
- docker imageがある
- https://githubja.com/yelp/elastalert
- elastalertをFargateに起動してElastichsearchのAPIを叩いて監視
- slackに通知
- elastalertの死活監視をmackerelに任せられる
- ルール設定が難しい
- YAML
- APIを使うという手もある?
- 管理方法を考える必要がある
Fargate Blue Green Deployment
- koarakkoさん
- Blue Green Deploymentとは
- BlueとGreen2つの環境をhot standby
- LBの切り替えでリリース
- 手順
- ALB/NBを作成
- listenrを2つ用意
- ECSのservice作る
- deployment typeにblue/greenを選択
- リスナーポートをひもづけ
- 80, 8080
- ターゲットグループひもづけ
- ALB/NBを作成
- よかったところ
- デプロイ負担が軽減
- ロールバック簡単
- 旧環境の退役が自動化される