1,800万人が利用する『家族アルバムみてね』におけるK8s基盤のアップグレード戦略と継続的改善 / FamilyAlbum's upgrade strategy and continuous improvement for K8s infrastructure

Slide 1

Slide 1 text

1,800万人が利用する『家族アルバムみてね』における K8s基盤のアップグレード戦略と継続的改善 @kohbis SRE NEXT 2023

Slide 2

Slide 2 text

MIXI, Inc. About Me ● SIer (Infra/Backend) ➡ Startup (Backend/Frontend) ➡ いま Kohei SUGIMOTO 株式会社MIXI 2022/04 ~『家族アルバムみてね』 SRE X/GitHub: @kohbis

Slide 3

Slide 3 text

MIXI, Inc. 本日お話しすること/お話ししないことお話しすること ● 『家族アルバムみてね』におけるK8s運用 ● K8sを導入することにより発生しうる課題とその向き合い方 K8s ＜運用, 改善お話ししないこと ● K8sや各サービスそのものが何か ● 具体的な設定内容

Slide 4

Slide 4 text

MIXI, Inc. 子どもの写真・動画を家族で共有し、コミュニケーションして楽しむサービス

Slide 5

Slide 5 text

MIXI, Inc.

Slide 6

Slide 6 text

MIXI, Inc. 家族アルバムみてね世界中の家族の”こころのインフラ”を作る ● 2015年4月リリース ● 現在7言語・175の国と地域でサービスを提供 ● 海外では FamilyAlbum という名称で展開中 ● 2023年5月に利用者数が1,800万人を突破 ※1 ● 日本国内ではママやパパの約半数となる47.1％の方がご利用 ※2 ※1 iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計 ※2「みてね」登録時に入力されたお子さまの誕生日と厚生労働省発表「人口動態統計」から算出。2022年8月時点で47.1％

Slide 7

Slide 7 text

MIXI, Inc. Amazon EKS導入の背景 ● AWS OpsWorks※1 環境においての課題 ○ プロビジョニング、デプロイに時間がかかり高速なオートスケールができない ○ Chefのバージョンアップが困難※2 ○ AWSマネジメントコンソールやSSHなどの手動オペレーション ○ スポットインスタンス活用が困難※3 アプリケーションのコンテナ化とコンテナサービス導入を実施 ※1 OpsWorksは2024年5月にサービス終了 ※2 Chefの最新バージョンに対応していない。OpsWorksのスタックごと入れ替えが必要になる ※3 OpsWorksの自動ヒーリングがスポットインスタンスでは機能しない

Slide 8

Slide 8 text

MIXI, Inc. コンテナ化とEKS導入に伴う変化 ● 高速かつ柔軟なオートスケール ● Dockerﬁle, Terraform, HelmでのIaC管理 ● Argo CDによるGitOps導入 ● EC2の手動オペレーションが不要に ● サービス全体でのスポットインスタンス利用率は9割以上に【参考】コンテナ移行ってこんなに大変？～「家族アルバムみてね」を支えるインフラの裏側～ https://speakerdeck.com/isaoshimizu/container-migration-in-familyalbum

Slide 9

Slide 9 text

MIXI, Inc. （補足）よくある質問 Q. AWSマネージドなコンテナサービスにはECSもありますが、なぜEKSなのでしょう？ A. 検討当時のECSはいまほど多機能/高機能ではなく、EKSがマッチしました。 Q. もしいまのECSとEKSで選ぶならどちらになりますか？ A. 『みてね』のサービス規模で、ECSのスケールスピードやコストの検討して、EKSとフラットに比較することになりそうです。 Q. 導入を検討しているのですが、ECSとEKSどちらがよいでしょう？ A. サービス規模や特性次第ですが、基本的にはECSから検討するのがよさそうです。

Slide 10

Slide 10 text

MIXI, Inc. 新たな戦いのはじまり ● K8sは、年3回のマイナーバージョンリリース&12か月間サポート ● EKSは、K8sに対応するマイナーバージョンのリリースから14か月間サポート ▼ 最低1年以内にはサービス基盤のアップデートが必要（なので実際はもっと高頻度） ● 影響範囲がサービス全体 ● 毎回同様の作業が発生する ● 多くの工数を消費する

Slide 11

Slide 11 text

MIXI, Inc. サービス基盤の安定稼働 ▼ サービスの信頼性

Slide 12

Slide 12 text

MIXI, Inc. EKSクラスタのBlue/Green戦略による無停止アップグレード ● みてねはAWSマルチリージョン構成 ● 複数リージョンにEKSクラスタが存在各リージョンに新バージョンのクラスタ作成 ▼ ALBの加重ルーティングで徐々にトラフィック移行 ▼ メトリクス監視に異常がなければ完全移行加重ルーティングで徐々に移行 Route53 レイテンシーベースルーティング

Slide 13

Slide 13 text

MIXI, Inc. 安全に移行はできるだが手間がかかる

Slide 14

Slide 14 text

MIXI, Inc. EKSクラスタの管理以外にもやるべきことはたくさんある

Slide 15

Slide 15 text

MIXI, Inc. 継続的な改善で少しずつ楽にしていく

Slide 16

Slide 16 text

MIXI, Inc. EKSアップグレードで発生する作業 ● 新バージョンのEKSクラスタ構築 ▼ ● Argo CDの手動インストール ▼ ● 各コンポーネントのインストール、アプリケーションのデプロイ ▼ ● リクエストのトラフィックやバッチジョブを旧→新に切り替え ▼ ● 旧バージョンのEKSクラスタ削除

Slide 17

Slide 17 text

MIXI, Inc. EKSアップグレード作業の改善アップグレード手順の確立 ● 「実施→問題やつまづきの発生→手順に反映 or 自動化」の繰り返し ● コード化、自動化できる手順は都度改善 ➡ 再現性の向上と作業工数の削減 ● もしサービスに影響がでた場合は、ポストモーテムを書いて知見共有 ➡ 「年に数回」だからこそ知見の偏りを防ぐ

Slide 18

Slide 18 text

MIXI, Inc. EKSアップグレード作業の改善新バージョンのEKSクラスタ構築、旧バージョンのEKSクラスタ削除（課題）毎回作成/削除するTerraformリソースがそれなりの量 ● EKSクラスタ、ノードグループ、VPC、IRSAなど ● 作成/削除漏れが発生する可能性 ▼ （改善） ● バージョンやノードグループなど最低限の設定値のみ可変としたTerraformモジュール実装 ● 新クラスタ移行後はTerraformモジュールのブロックを削除するだけ

Slide 19

Slide 19 text

MIXI, Inc. EKSアップグレード作業の改善 Argo CDの手動インストール（課題）毎回発生する作業 ● Helmによる手動インストール ● 内部ドメインからアクセスする = Argo CDのUIで作業できるようにするための手動設定（認証やIngress） ▼ （改善） ● Argo CDのインストールや内部ドメインでアクセスできるようになるまでの認証設定など、定型コマンドをスクリプト化

Slide 20

Slide 20 text

MIXI, Inc. 「地味じゃない？」

Slide 21

Slide 21 text

MIXI, Inc. 「地味なのです」

Slide 22

Slide 22 text

MIXI, Inc. EKSアップグレード作業の改善 ● アップグレード手順 ➡ アップグレードタイミングごとに見直し ● EKSクラスタ作成/削除、新旧切り替え ➡ TerraformとHelmで（ほぼ）自動化 ● 各コンポーネントのインストール、アプリケーションのデプロイ ➡ Argo CDによる自動化 Argo CDインストール ➡ 手動オペレーションがまだ残っている状態

Slide 23

Slide 23 text

MIXI, Inc. ならば Argo CDを毎回つくらなければよいのでは？

Slide 24

Slide 24 text

MIXI, Inc. Argo CDと『みてね』サービスは同一クラスタに存在していた

Slide 25

Slide 25 text

MIXI, Inc. 同一クラスタだと何が困るの？ ● EKSバージョンアップグレードのたびに毎回同じ作業 ○ Argo CDのインストール ○ Argo CDを機能させるための最低限の設定 ● 責務の異なるアプリケーションが同一クラスタに存在している ○ 変更に伴う影響範囲が適切ではない ● 新旧クラスタの並行稼働期間はそれぞれのArgo CDが複数存在し切り替えが地味に面倒

Slide 26

Slide 26 text

MIXI, Inc. EKSクラスタ分割という選択 ● Miteneクラスタ ➡『みてね』サービスが稼働するクラスタ。Blue/Greenアップグレード ● Opsクラスタ ➡ EKS群を管理するManagerクラスタ。インプレースアップグレード『みてね』サービスが稼働する Miteneクラスタ EKSクラスタ群を管理する Opsクラスタ分割

Slide 27

Slide 27 text

MIXI, Inc. Argo CDと『みてね』サービスのクラスタ分割

Slide 28

Slide 28 text

MIXI, Inc. クラスタ分割によって得られたもの ● OpsクラスタにArgo CDが常駐するようになった ➡ EKSアップグレードのたびに発生していたArgo CD構築作業がなくなった ➡ 新旧Miteneクラスタの並行稼働期間でも見るべきArgo CDがひとつになった ● アプリケーションの責務ごとにOpsクラスタとMiteneクラスタに分割された ○ 『みてね』サービスに直接関わらないものをOpsクラスタで稼働 ■ e.g. Redash, Grafana, リモート開発環境（like. Codespaces） ➡ 変更に伴う影響範囲が最低限に ● 「クラスタを増やしたい」となった場合にも管理しやすくなった ➡ 未来のスケールにも対応可能

Slide 29

Slide 29 text

MIXI, Inc. Fin?

Slide 30

Slide 30 text

MIXI, Inc. No.

Slide 31

Slide 31 text

MIXI, Inc. みてね’s SRE NEXT ● Opsクラスタのインプレースアップグレード対応 ➡ Managerクラスタ構成の運用知見の蓄積 ● TerraformやHelmコードのリファクタリング ➡ 変更を容易にしておき工数を削減 ● 各コンポーネント、Helm chartsの継続的メンテナンス ➡ 最新状態を保ちクラスタアップグレードの妨げにならないようにしておく（e.g. APIバージョンへの対応） ● さらなる自動化 etc.

Slide 32

Slide 32 text

MIXI, Inc. マルチクラスタ管理やManagerクラスタ構成を導入されている皆さまぜひ知見をご教示ください！!

Slide 33

Slide 33 text

MIXI, Inc.