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
AIエージェントについてまとめてみた
pharma_x_tech
8
4.8k
Fin-JAWS第38回reInvent2024_全金融系セッションをライトにまとめてみた
mhrtech
1
100
Autify Company Deck
autifyhq
2
41k
Creative Pair
kawaguti
PRO
1
130
Tech Blog執筆のモチベート向上作戦
imamura_ko_0314
0
730
インシデントキーメトリクスによるインシデント対応の改善 / Improving Incident Response using Incident Key Metrics
nari_ex
0
3.9k
GraphRAG: What I Thought I Knew (But Didn’t)
sashimimochi
1
220
HCP TerraformとAzure:イオンスマートテクノロジーのインフラ革新 / HCP Terraform and Azure AEON Smart Technology's Infrastructure Innovation
aeonpeople
3
980
Oracle Cloud Infrastructure:2025年1月度サービス・アップデート
oracle4engineer
PRO
0
180
Amazon Aurora バージョンアップについて、改めて理解する ~バージョンアップ手法と文字コードへの影響~
smt7174
1
240
Agentic AI時代のプロダクトマネジメントことはじめ〜仮説検証編〜
masakazu178
3
370
ソフトウェア開発現代史:製造業とソフトウェアは本当に共存できていたのか?品質とスピードを問い直す
takabow
15
5.3k
Featured
See All Featured
BBQ
matthewcrist
85
9.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
220
A Modern Web Designer's Workflow
chriscoyier
693
190k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
11
900
Rebuilding a faster, lazier Slack
samanthasiow
79
8.8k
For a Future-Friendly Web
brad_frost
176
9.5k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
3k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.4k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.5k
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そのものより、エンジニアの責務の分担が難しい まとめ
情報を世界中の人に最適に届ける