$30 off During Our Annual Pro Sale. View Details »

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

kohbis
September 29, 2023

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

kohbis

September 29, 2023
Tweet

More Decks by kohbis

Other Decks in Technology

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