Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
グノシー におけるEKS活用事例
Search
RossyWhite
March 20, 2020
Technology
2
2.2k
グノシー におけるEKS活用事例
RossyWhite
March 20, 2020
Tweet
Share
Other Decks in Technology
See All in Technology
転生CISOサバイバル・ガイド / CISO Career Transition Survival Guide
kanny
2
390
自動テストの世界に、この5年間で起きたこと
autifyhq
10
7.1k
AndroidXR 開発ツールごとの できることできないこと
donabe3
0
110
スクラムのイテレーションを導入してチームの雰囲気がより良くなった話
eccyun
0
110
10分で紹介するAmazon Bedrock利用時のセキュリティ対策 / 10-minutes introduction to security measures when using Amazon Bedrock
hideakiaoyagi
0
170
モノレポ開発のエラー、誰が見る?Datadog で実現する適切なトリアージとエスカレーション
biwashi
6
770
Platform Engineeringは自由のめまい
nwiizo
4
1.9k
データの品質が低いと何が困るのか
kzykmyzw
6
1k
Nekko Cloud、 これまでとこれから ~学生サークルが作る、 小さなクラウド
logica0419
2
730
「海外登壇」という 選択肢を与えるために 〜Gophers EX
logica0419
0
500
目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる / Every little bit counts
soudai
22
5.8k
Culture Deck
optfit
0
330
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Writing Fast Ruby
sferik
628
61k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Adopting Sorbet at Scale
ufuk
74
9.2k
Bash Introduction
62gerente
610
210k
The Cult of Friendly URLs
andyhume
78
6.2k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Building Adaptive Systems
keathley
40
2.4k
Transcript
株式会社 Gunosy 技術戦略室SRE部 城井大輝 2020年3月20日 グノシー におけるEKS活用事例
(C) Gunosy Inc. All Rights Reserved. PAGE | 2 ▪
城井大輝 / Daiki Shiroi ▪ 2019/04/01 ~ – SRE Engineer at Gunosy Inc. ▪ GitHub: @RossyWhite ▪ Twitter: @rossywhite_ 自己紹介
~ 今回のテーマ ~ グノシーにおけるEKS活用事例 (C) Gunosy Inc. All Rights Reserved.
(C) Gunosy Inc. All Rights Reserved. PAGE | 4 株式会社Gunosy
ギリシャ語で「知識」を意味する「Gnosis(グノーシス)」+「u(“you”)」 「”Gnosis” for “you”」あなたのための知識 =情報を届けるサービスを提供し続ける、という意味 ▪ 2012年11月創業 ▪ 2015年4月東証マザーズ上場 ▪ 2017年12月東証第一部に市場変更 ▪ 従業員数 215 名 (2019年5月末現在 連結ベース) ▪ 事業内容 – 情報キュレーションサービスその他メディアの開発及 び運営 ▪ 提供サービス グノシー、ニュースパス、LUCRA(ルクラ) 企業理念「情報を世界中の人に最適に届ける」
(C) Gunosy Inc. All Rights Reserved. PAGE | 5 ▪
コンテナ移行によって得られたメリット ▪ プロダクション環境でEKSを運用するための工夫 – 良かったことも苦労していることも。。 お話すること
(C) Gunosy Inc. All Rights Reserved. PAGE | 6 ▪
EKS導入のメリットや課題をイメージできるようになる 今日のゴール
グノシーのシステムの概要と課題 (C) Gunosy Inc. All Rights Reserved.
(C) Gunosy Inc. All Rights Reserved. PAGE | 8 グノシーのアーキテクチャ
https://aws.amazon.com/jp/solutions/case-studies/gunosy/ より 今日の話の中心
(C) Gunosy Inc. All Rights Reserved. PAGE | 9 ▪
構成管理 – AWS OpsWorks ▪ 開発言語 – Golang ▪ データストア – RDS, DynamoDB, ElastiCache... ▪ モニタリング – CloudWatch, Datadog.. ▪ その他 – CircleCI 従来の主な使用技術
(C) Gunosy Inc. All Rights Reserved. PAGE | 10 ▪
Chefのクックブックの管理コスト ▪ インスタンスの立ち上げ速度 – Setupが遅い... ▪ スケーラビリティ – 柔軟にスケールできない – スパイキーなアクセスで落ちる 全てがOpsWorks文脈という訳ではないが。。。 従来の課題 ▪ コスト効率が悪い – サービスごとにVMが存在 – スポットインスタンスが使いにくい ▪ 手作業でのデプロイ ▪ ローカル開発環境が貧弱
EKSへの移行 (C) Gunosy Inc. All Rights Reserved.
(C) Gunosy Inc. All Rights Reserved. PAGE | 12 ▪
コストダウン ▪ ポータブルなインフラ ▪ 開発環境の改善 – CI/CD, リリース頻度 – ローカル開発/テスト環境の整備 ▪ 柔軟なスケーリング など 移行により解決したかったこと
(C) Gunosy Inc. All Rights Reserved. PAGE | 13 ▪
Kubernetes自体はオープンソース – 情報量・最悪コード読める ▪ コントロールプレーンはマネージド ▪ 一貫性のある定義方法、拡張方法 ▪ 利用側にとってはシンプル(`kubectl apply`するだけ) ▪ 新規プロダクトでの事例 ▪ Kubernetesのエコシステム Kubernetes (EKS) 選択の背景
(C) Gunosy Inc. All Rights Reserved. PAGE | 14 ▪
4人くらい – サーバーサイドエンジニア + SRE ▪ アプリのコンテナ化 + クラスタ構築 ▪ 半年くらい? 移行プロジェクト概要
(C) Gunosy Inc. All Rights Reserved. PAGE | 15 クラスタ作成
▪ PrivateSubnet内にASG ▪ App + Envoy(サイドカー) でメッシュを構築 - Istioは入れてない ▪ トラフィックはNodePort経由 ▪ Envoyは ▪ ログはfluentdで収集 - Papertrailに集約
(C) Gunosy Inc. All Rights Reserved. PAGE | 16 アプリのコンテナ化
▪ Dockerで動作可能に – カスタムjsonの内容の移植 • ConfigMaps, Secrets • 環境変数 ▪ Podとして動作可能に – 依存をサイドカーに寄せる – プロキシ(Envoy)通じて通信できるか
(C) Gunosy Inc. All Rights Reserved. PAGE | 17 ▪
大幅にコストカット – クラスタの6~7割くらいがスポットインスタンス • aws-node-termination-handler で中断通知をhandle – インスタンス一台あたりの稼働率が上がった – 1/3くらいコストが削減された ▪ 柔軟なスケーリング – ASGのオートスケーリング – インスタンスの初期化が軽くなった ▪ 開発速度の向上 移行による嬉しさ
プロダクション運用を支える仕組み (C) Gunosy Inc. All Rights Reserved.
(C) Gunosy Inc. All Rights Reserved. PAGE | 19 ▪
スケーリング戦略 ▪ Infrastructure as Code ▪ 開発環境 プロダクション運用を支える仕組み
スケーリング戦略 (C) Gunosy Inc. All Rights Reserved.
(C) Gunosy Inc. All Rights Reserved. PAGE | 21 ▪
HPA – Podの負荷に応じてPod数を増減させる • CPU, Memory, CustomMetrics ▪ CA – 起動できないPodがある場合にノードを増やす Horizontal Pod Autoscaler(HPA) + Cluster Autoscaler(CA) スケーリング戦略
(C) Gunosy Inc. All Rights Reserved. PAGE | 22 スケーリングの流れ
▪ deploymentレベルでHPAを設 定しておけば、ノードのCPU 使用率を考えなくても良いの でシンプル
(C) Gunosy Inc. All Rights Reserved. PAGE | 23 ▪
Podがpendingしないとスケールアウトしない => 負荷に先回りすることはできない ▪ スケールまでのラグの要素 – HPAのインターバル – CAのインターバル – ノードの初期化 – Podの初期化 HPA + CAだけではうまくいかなかった 3~3.5minくらいはかかる (もちろん環境次第) Push通知時の瞬間的なリクエスト数に対応できない
(C) Gunosy Inc. All Rights Reserved. PAGE | 24 ▪
Push送信時には、通常の10~30倍程度のrpsが瞬間的に発生 => HPA+CAの方式だと間に合わない ▪ 事前にスケールさせておく必要がある ▪ Push送信イベントをlambda受け取ってHPAのminReplicasを更新 Push通知時のスケーリング
(C) Gunosy Inc. All Rights Reserved. PAGE | 25 ▪
VPA(Vertical Pod Autoscaler) – PodのResource Request を調整してくれる – 一部のPodは数を固定して、VPAで調整してる ▪ descheduler – ノード間での偏りの調整 – 高負荷なノードからPodをevict – CronJobとして、2回/day くらい実行している その他の機構
infrastructure as code (C) Gunosy Inc. All Rights Reserved.
(C) Gunosy Inc. All Rights Reserved. PAGE | 27 ▪
Codenize.tool ▪ Chef (OpsWorks) ▪ Terraform ▪ Kustomize 使っている(いた)ツール
(C) Gunosy Inc. All Rights Reserved. PAGE | 28 ▪
インフラのコード管理自体は以前より行っていた ▪ Codenize.toolsを使用 (OpsWorks自体は管理対象外) => 1年ほど前にTerraformに移行開始 ▪ Terraformへの移行とコンテナへの移行が同時に発生 前提
(C) Gunosy Inc. All Rights Reserved. PAGE | 29 [初期の判断]
単一のリポジトリでの管理を試みる ▪ 今までの慣例から自然な流れ ▪ 一元管理した方が一貫性が保てる ▪ 開発スピードの低下・SREのレビュー負担 Kubernetesのマニフェストも管理しなければなくなった。。。 Kubernetesのマニフェストをどこにおくか
(C) Gunosy Inc. All Rights Reserved. PAGE | 30 ▪
ライフサイクルの異なるリソースが同一リポジトリに存在 – 開発者が複数リポジトリを触る必要性 – デプロイのスピードが低下 ▪ SREのレビュー負担 – コンテキストもあまり分からない – 人数的にも厳しい ▪ リポジトリ自体の肥大化 – applyが遅くなる 何が問題だったか 境界線の再定義する必要性
(C) Gunosy Inc. All Rights Reserved. PAGE | 31 ▪
クラスタレベル(サービスが共有して使用) – Daemonsets, VPC, Subnet... ▪ サービスレベル(サービス固有) – Deployments, Services, ConfigMaps, ALB, IAM, SG…. リソースの2つのレイヤー
(C) Gunosy Inc. All Rights Reserved. PAGE | 32 ▪
クラスタ関連のリソース – DaemonSets – kube-system関連のDeployment ▪ terraformで管理されてたAWSリソース ▪ codenize.toolsの残党... ▪ 各Microserviceのリソース – k8sのマニフェスト • Deployments • Service • ConfigMaps 現状の管理方法 中央リポジトリ 各マイクロサービス のリポジトリで管理
(C) Gunosy Inc. All Rights Reserved. PAGE | 33 ▪
軽い ▪ 分かりやすい ▪ 環境ごとに簡単に値を変更可能 (若干Helmに移行検討中) 主にk8sのマニフェストの管理、Applyに使用 Kustomize 公式からの抜粋 (実際も似たような感じ)
(C) Gunosy Inc. All Rights Reserved. PAGE | 34 ▪
できていること – Kubernetesのyamlに関してはきれいに分離されている ▪ できていないこと – 以前からterraformで管理されてたIAM・SGなどがサービス側に移譲で きてない 開発者に自由を与えつつ、守るべきは守る仕組みをどう作るか? - 規模感、組織の文化にもよる。難しい。 できている事、できていない事
開発環境 (C) Gunosy Inc. All Rights Reserved.
(C) Gunosy Inc. All Rights Reserved. PAGE | 36 ▪
localではdocker-composeで動かすが、デプロイはOpsWorksで行う => localとremoteでの環境差が大きい ▪ リモートの環境は供用として使用 従来の開発環境 今からstaging 環境使います
(C) Gunosy Inc. All Rights Reserved. PAGE | 37 ▪
本番反映される環境と開発環境の差分は小さくしたい ▪ ローカルでテストデータ生成は嫌 ▪ でも手軽さは欲しい お気持ち
(C) Gunosy Inc. All Rights Reserved. PAGE | 38 ▪
GoogleがOSSで開発しているCI/CDツール ▪ コードの変更を検知して、コンテナのビルド~デプロイまで行う ▪ リモート環境でローカル開発っぽいことができる Skaffold
(C) Gunosy Inc. All Rights Reserved. PAGE | 39 ▪
コードの変更を検知 => 自動で再デプロイ Skaffold
(C) Gunosy Inc. All Rights Reserved. PAGE | 40 ▪
ローカルではなく、Stagingクラスタを使用 – skaffoldの起動時に開発者ごとの一時的なNamespaceを作成 – ECRにpushされるimageはタグで識別 – 依存しているアプリはdefault namespaceにあるPodにアクセス 現在の開発の流れ
(C) Gunosy Inc. All Rights Reserved. PAGE | 41 ▪
localで動かすのと違って、本番同等の環境で開発可能 ▪ 依存先のマイクロサービスは常に最新状態 – localで動かすなら毎回pullして来ないといけない ▪ 開発者ごとに隔離された環境を提供可能 この方法の嬉しさ
今の課題 (C) Gunosy Inc. All Rights Reserved.
(C) Gunosy Inc. All Rights Reserved. PAGE | 43 ▪
Envoyのyamlがつらい – そもそもk8sのyamlもそこまで優しくはない ▪ キャッチアップの努力は必要だが、負荷は減らしたい ▪ 最低限必須な設定は担保したい – 信頼性に影響が出るようなもの – 命名規則だったり、社内で使っているタグ – 監視の設定し忘れ防止 ▪ Canary Releaseもしたい 今はmicroservice用のboilerplateの提供に留まっている 開発速度と信頼性の担保
まとめ (C) Gunosy Inc. All Rights Reserved.
(C) Gunosy Inc. All Rights Reserved. PAGE | 45 ▪
移行を頑張るだけの価値はある – コスト削減 – 開発速度向上 ▪ Kubernetesは難しくない – 勉強は必要だがそれは他も同じ – プラクティスは出揃いつつある – 周辺ツールを使えばなんとかなる(EKSもある) ▪ k8sそのものより、エンジニアの責務の分担が難しい まとめ
情報を世界中の人に最適に届ける