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

SRE NEXT 2023
https://sre-next.dev/2023/schedule/#jp093

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

5. MIXI, Inc.
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

29. MIXI, Inc.
    Fin?
    

    View Slide

30. MIXI, Inc.
    No.
    

    View Slide

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

    View Slide

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

    View Slide

33. MIXI, Inc.
    

    View Slide