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
1,800万人が利用する『家族アルバム みてね』におけるK8s基盤のアップグレード戦略と継続的...
Search
kohbis
September 29, 2023
Technology
5
4.3k
1,800万人が利用する『家族アルバム みてね』におけるK8s基盤のアップグレード戦略と継続的改善 / FamilyAlbum's upgrade strategy and continuous improvement for K8s infrastructure
SRE NEXT 2023
https://sre-next.dev/2023/schedule/#jp093
kohbis
September 29, 2023
Tweet
Share
More Decks by kohbis
See All by kohbis
潜在的課題探索活動の近況報告 / Exploration of latent challenges
kohbis
2
75
いま、あらためて考えてみるアカウント管理 with IaC / Account management with IaC
kohbis
3
840
〜『世界中の家族のこころのインフラ』を目指して”次の10年”へ〜 SREが導いたグローバルサービスの信頼性向上戦略とその舞台裏 / Towards the Next Decade: Enhancing Global Service Reliability
kohbis
3
3.2k
Grafana MCP serverでなんかし隊 / Try Grafana MCP server
kohbis
0
720
Custom Prometheus Exporterによる オブザーバビリティ拡張 / Extending observability with Custom Prometheus Exporter
kohbis
1
170
データベースで見る『家族アルバム みてね』の変遷 / The Evolution of Family Album Through the Lens of Databases
kohbis
5
1.4k
SREコミュニティイベントとわたし / Me and SRE community events
kohbis
2
250
サクッと試すNew Relic Kubernetes APM auto-attach / New Relic Kubernetes APM auto-attach
kohbis
0
420
悩ましきインシデント管理 みてねのケース / Incident management is a tough
kohbis
2
810
Other Decks in Technology
See All in Technology
Wasmのエコシステムを使った ツール作成方法
askua
0
210
能登半島災害現場エンジニアクロストーク 【JAWS FESTA 2025 in 金沢】
ditccsugii
0
890
物体検出モデルでシイタケの収穫時期を自動判定してみた。 #devio2025
lamaglama39
0
220
今この時代に技術とどう向き合うべきか
gree_tech
PRO
2
2k
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
速習AGENTS.md:5分で精度を上げる "3ブロック" テンプレ
ismk
6
1.7k
これがLambdaレス時代のChatOpsだ!実例で学ぶAmazon Q Developerカスタムアクション活用法
iwamot
PRO
8
1.1k
"プロポーザルってなんか怖そう"という境界を超えてみた@TSUDOI by giftee Tech #1
shilo113
0
200
dbtとBigQuery MLで実現する リクルートの営業支援基盤のモデル開発と保守運用
recruitengineers
PRO
3
100
セキュアな認可付きリモートMCPサーバーをAWSマネージドサービスでつくろう! / Let's build an OAuth protected remote MCP server based on AWS managed services
kaminashi
3
350
Dylib Hijacking on macOS: Dead or Alive?
patrickwardle
0
220
ガバメントクラウド(AWS)へのデータ移行戦略の立て方【虎の巻】 / 20251011 Mitsutosi Matsuo
shift_evolve
PRO
2
200
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Making the Leap to Tech Lead
cromwellryan
135
9.6k
Designing for Performance
lara
610
69k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Fireside Chat
paigeccino
40
3.7k
Into the Great Unknown - MozCon
thekraken
40
2.1k
Context Engineering - Making Every Token Count
addyosmani
7
260
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
600
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Music & Morning Musume
bryan
46
6.8k
Transcript
1,800万人が利用する 『家族アルバム みてね』における K8s基盤のアップグレード戦略と 継続的改善 @kohbis SRE NEXT 2023
MIXI, Inc. About Me • SIer (Infra/Backend) ➡ Startup (Backend/Frontend)
➡ いま Kohei SUGIMOTO 株式会社MIXI 2022/04 ~『家族アルバム みてね』 SRE X/GitHub: @kohbis
MIXI, Inc. 本日お話しすること/お話ししないこと お話しすること • 『家族アルバム みてね』におけるK8s運用 • K8sを導入することにより発生しうる課題とその向き合い方 K8s
<運用, 改善 お話ししないこと • K8sや各サービスそのものが何か • 具体的な設定内容
MIXI, Inc. 子どもの写真・動画を家族で共有し、 コミュニケーションして楽しむサービス
MIXI, Inc.
MIXI, Inc. 家族アルバム みてね 世界中の家族の”こころのインフラ”を作る • 2015年4月リリース • 現在7言語・175の国と地域でサービスを提供 •
海外では FamilyAlbum という名称で展開中 • 2023年5月に利用者数が1,800万人を突破 ※1 • 日本国内ではママやパパの約半数となる47.1% の方がご利用 ※2 ※1 iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計 ※2「みてね」登録時に入力されたお子さまの誕生日と厚生労働省発表「人口動態統計」から算出。2022年8月時点で47.1%
MIXI, Inc. Amazon EKS導入の背景 • AWS OpsWorks※1 環境においての課題 ◦ プロビジョニング、デプロイに時間がかかり高速なオートスケールができない
◦ Chefのバージョンアップが困難※2 ◦ AWSマネジメントコンソールやSSHなどの手動オペレーション ◦ スポットインスタンス活用が困難※3 アプリケーションのコンテナ化とコンテナサービス導入を実施 ※1 OpsWorksは2024年5月にサービス終了 ※2 Chefの最新バージョンに対応していない。OpsWorksのスタックごと入れ替えが必要になる ※3 OpsWorksの自動ヒーリングがスポットインスタンスでは機能しない
MIXI, Inc. コンテナ化とEKS導入に伴う変化 • 高速かつ柔軟なオートスケール • Dockerfile, Terraform, HelmでのIaC管理 •
Argo CDによるGitOps導入 • EC2の手動オペレーションが不要に • サービス全体でのスポットインスタンス利用率は9割以上に 【参考】コンテナ移行ってこんなに大変? ~「家族アルバム みてね」を支えるインフラの裏側~ https://speakerdeck.com/isaoshimizu/container-migration-in-familyalbum
MIXI, Inc. (補足)よくある質問 Q. AWSマネージドなコンテナサービスにはECSもありますが、なぜEKSなのでしょう? A. 検討当時のECSはいまほど多機能/高機能ではなく、EKSがマッチしました。 Q. もしいまのECSとEKSで選ぶならどちらになりますか? A.
『みてね』のサービス規模で、ECSのスケールスピードやコストの検討して、EKSとフ ラットに比較することになりそうです。 Q. 導入を検討しているのですが、ECSとEKSどちらがよいでしょう? A. サービス規模や特性次第ですが、基本的にはECSから検討するのがよさそうです。
MIXI, Inc. 新たな戦いのはじまり • K8sは、年3回のマイナーバージョンリリース&12か月間サポート • EKSは、K8sに対応するマイナーバージョンのリリースから14か月間サポート ▼ 最低1年以内にはサービス基盤のアップデートが必要(なので実際はもっと高頻度) •
影響範囲がサービス全体 • 毎回同様の作業が発生する • 多くの工数を消費する
MIXI, Inc. サービス基盤の安定稼働 ▼ サービスの信頼性
MIXI, Inc. EKSクラスタのBlue/Green戦略による無停止アップグレード • みてねはAWSマルチリージョン構成 • 複数リージョンにEKSクラスタが存在 各リージョンに新バージョンのクラスタ作成 ▼ ALBの加重ルーティングで徐々にトラフィック
移行 ▼ メトリクス監視に異常がなければ完全移行 加重ルーティングで 徐々に移行 Route53 レイテンシーベース ルーティング
MIXI, Inc. 安全に移行はできる だが手間がかかる
MIXI, Inc. EKSクラスタの管理以外にも やるべきことはたくさんある
MIXI, Inc. 継続的な改善で 少しずつ楽にしていく
MIXI, Inc. EKSアップグレードで発生する作業 • 新バージョンのEKSクラスタ構築 ▼ • Argo CDの手動インストール ▼
• 各コンポーネントのインストール、アプリケーションのデプロイ ▼ • リクエストのトラフィックやバッチジョブを旧→新に切り替え ▼ • 旧バージョンのEKSクラスタ削除
MIXI, Inc. EKSアップグレード作業の改善 アップグレード手順の確立 • 「実施→問題やつまづきの発生→手順に反映 or 自動化」の繰り返し • コード化、自動化できる手順は都度改善
➡ 再現性の向上と作業工数の削減 • もしサービスに影響がでた場合は、ポストモーテムを書いて知見共有 ➡ 「年に数回」だからこそ知見の偏りを防ぐ
MIXI, Inc. EKSアップグレード作業の改善 新バージョンのEKSクラスタ構築、旧バージョンのEKSクラスタ削除 (課題)毎回作成/削除するTerraformリソースがそれなりの量 • EKSクラスタ、ノードグループ、VPC、IRSAなど • 作成/削除漏れが発生する可能性 ▼
(改善) • バージョンやノードグループなど最低限の設定値のみ可変としたTerraformモジュー ル実装 • 新クラスタ移行後はTerraformモジュールのブロックを削除するだけ
MIXI, Inc. EKSアップグレード作業の改善 Argo CDの手動インストール (課題)毎回発生する作業 • Helmによる手動インストール • 内部ドメインからアクセスする
= Argo CDのUIで作業できるようにするための手動設 定(認証やIngress) ▼ (改善) • Argo CDのインストールや内部ドメインでアクセスできるようになるまでの認証設定な ど、定型コマンドをスクリプト化
MIXI, Inc. 「地味じゃない?」
MIXI, Inc. 「地味なのです」
MIXI, Inc. EKSアップグレード作業の改善 • アップグレード手順 ➡ アップグレードタイミングごとに見直し • EKSクラスタ作成/削除、新旧切り替え ➡
TerraformとHelmで(ほぼ)自動化 • 各コンポーネントのインストール、アプリケーションのデプロイ ➡ Argo CDによる自動化 Argo CDインストール ➡ 手動オペレーションがまだ残っている状態
MIXI, Inc. ならば Argo CDを毎回つくらなければ よいのでは?
MIXI, Inc. Argo CDと『みてね』サービスは同一クラスタに存在していた
MIXI, Inc. 同一クラスタだと何が困るの? • EKSバージョンアップグレードのたびに毎回同じ作業 ◦ Argo CDのインストール ◦ Argo
CDを機能させるための最低限の設定 • 責務の異なるアプリケーションが同一クラスタに存在している ◦ 変更に伴う影響範囲が適切ではない • 新旧クラスタの並行稼働期間はそれぞれのArgo CDが複数存在し 切り替えが地味に面倒
MIXI, Inc. EKSクラスタ分割という選択 • Miteneクラスタ ➡『みてね』サービスが稼働するクラスタ。Blue/Greenアップグ レード • Opsクラスタ ➡
EKS群を管理するManagerクラスタ。インプレースアップグレード 『みてね』サービスが稼働する Miteneクラスタ EKSクラスタ群を管理する Opsクラスタ 分割
MIXI, Inc. Argo CDと『みてね』サービスのクラスタ分割
MIXI, Inc. クラスタ分割によって得られたもの • OpsクラスタにArgo CDが常駐するようになった ➡ EKSアップグレードのたびに発生していたArgo CD構築作業がなくなった ➡
新旧Miteneクラスタの並行稼働期間でも見るべきArgo CDがひとつになった • アプリケーションの責務ごとにOpsクラスタとMiteneクラスタに分割された ◦ 『みてね』サービスに直接関わらないものをOpsクラスタで稼働 ▪ e.g. Redash, Grafana, リモート開発環境(like. Codespaces) ➡ 変更に伴う影響範囲が最低限に • 「クラスタを増やしたい」となった場合にも管理しやすくなった ➡ 未来のスケールにも対応可能
MIXI, Inc. Fin?
MIXI, Inc. No.
MIXI, Inc. みてね’s SRE NEXT • Opsクラスタのインプレースアップグレード対応 ➡ Managerクラスタ構成の運用知見の蓄積 •
TerraformやHelmコードのリファクタリング ➡ 変更を容易にしておき工数を削減 • 各コンポーネント、Helm chartsの継続的メンテナンス ➡ 最新状態を保ちクラスタアップグレードの妨げにならな いようにしておく(e.g. APIバージョンへの対応) • さらなる自動化 etc.
MIXI, Inc. マルチクラスタ管理やManagerクラスタ構成を 導入されている皆さまぜひ知見をご教示ください!!
MIXI, Inc.