Upgrade to Pro — share decks privately, control downloads, hide ads and more …

オンプレk8sとEKSの並行運用の実際

ch1aki
January 26, 2023

 オンプレk8sとEKSの並行運用の実際

カラーミーショップのエンジニアが話すこれまでとこれから 2023 (https://pepabo.connpass.com/event/266671/)

ch1aki

January 26, 2023
Tweet

More Decks by ch1aki

Other Decks in Technology

Transcript

  1. オンプレk8sとEKSの
    並行運用の実際
    next

    View Slide

  2. akichan
    2018年3月にペパボカレッジ6期生として中途
    入社。カラーミーショップをクラウドネイティブに
    するプロジェクトにSREとして携わっている。
    @ch11aki
    @ch1aki
    技術部プラットフォームグループ所属
    Speaker

    View Slide

  3. 今日話すこと
    ● カラーミーショップのインフラの歴史
    ● ShopSetアーキテクチャ
    ● オンプレk8sとEKSの並行運用の困難さ
    オンプレk8sとEKSの並行運用の実際

    View Slide

  4. カラーミーショップのインフラの歴史
    オンプレk8sとEKSの並行運用の実際
    〜2015年
    〜2019年
    〜2020年
    〜現在
    ● オンプレミスサーバー
    ● プライベートクラウド
    ● k8s on プライベートクラウド
    ● ハイブリッドクラウド
    ● next???
    ● データセンターで
    数十台の物理サーバーを管理
    ● トラブルがあったら
    データセンターへ駆けつける時代🏃

    View Slide

  5. 〜2015年
    〜2019年
    〜2020年
    〜現在
    ● オンプレミスサーバー
    ● プライベートクラウド
    ● k8s on プライベートクラウド
    ● ハイブリッドクラウド
    ● next???
    カラーミーショップのインフラの歴史
    オンプレk8sとEKSの並行運用の実際
    ● OpenStackを用いて
    プライベートクラウド「Nyah」を構築
    ● AWSのように、WebコンソールやAPIで
    サーバーの管理が可能
    ● AWS EC2、EBS、NLB相当の機能を低
    価格で提供

    View Slide

  6. 〜2015年
    〜2019年
    〜2020年
    〜現在
    ● オンプレミスサーバー
    ● プライベートクラウド
    ● k8s on プライベートクラウド
    ● ハイブリッドクラウド
    ● next???
    ● Nyah上でk8sクラスタを構築・
    管理する内製ツールを提供
    ● プライベートクラウドのVMとコンテナの
    並行稼動
    カラーミーショップのインフラの歴史
    オンプレk8sとEKSの並行運用の実際

    View Slide

  7. 〜2015年
    〜2019年
    〜2020年
    〜現在
    ● オンプレミスサーバー
    ● プライベートクラウド
    ● k8s on プライベートクラウド
    ● ハイブリッドクラウド
    ● next???
    ● AWS Direct Connectを利用し、
    プライベートクラウドとAWSが専用線で
    相互に通信可能
    ● ステートフルリソースのDBやキャッシュを
    AWSのマネージドサービスに移行し、運用
    コストを最適化
    カラーミーショップのインフラの歴史
    オンプレk8sとEKSの並行運用の実際

    View Slide

  8. 〜2015年
    〜2019年
    〜2020年
    〜現在
    ● オンプレミスサーバー
    ● プライベートクラウド
    ● k8s on プライベートクラウド
    ● ハイブリッドクラウド
    ● next???
    カラーミーショップの根本的な
    アーキテクチャによる様々な制約を取り払う
    次世代アーキテクチャを開発している
    カラーミーショップのインフラの歴史
    オンプレk8sとEKSの並行運用の実際

    View Slide

  9. カラーミーショップは「マルチテナント型」
    ● 複数のユーザーで一つのシステムを共有する形態
    ● システムの管理・運用コストを削減できるため、
    安価にサービスを提供可能
    App
    Load Balancer
    RDB
    ● 一方で、
    あるショップへのリクエスト増加による負荷が、
    他のショップに与える可能性がある
    (様々なレイヤで対策をしている)
    オンプレk8sとEKSの並行運用の実際

    View Slide

  10. オンプレk8sとEKSの並行運用の実際
    ● コロナ禍によるECへの需要が急増
    ● 既存の仕組みではショップ間の影響を抑えることが
    困難なケースが多発
    ● 負荷の高いショップをインフラレベルで隔離して対応
    →一定の効果
    ● 分離された環境は構築と管理の手間がかかった
    ○ どのショップをどこに向けるか
    ○ レートリミットの閾値
    ○ etc...
    App
    Load Balancer
    RDB
    App
    Load Balancer
    共用 隔離
    課題

    View Slide

  11. ShopSetアーキテクチャ
    ● 複数の論理的な分離された環境を
    効率的に作成する
    Takuya Takahashi.「カラーミーショップの 可用性向上のための インフラ刷
    新」. GMO Developers Night (2021).
    https://speakerdeck.com/takutakahashi/karamisiyotupufalse-ke-yong-xin
    g-xiang-shang-falsetamefalse-inhurashua-xin
    ● ショップの閲覧から購入に関わるアプリケーション
    ロールをまとめた単位(ShopSet)で分離
    ● 複数ショップでShopSetを共有
    ● 必要に応じてShopSetを専有したり、複数
    ShopSetで冗長化
    オンプレk8sとEKSの並行運用の実際

    View Slide

  12. ShopSetがk8sの上で実現されている理由
    ● 高度な自動化を実現するエコシステムがある
    ○ k8s Operator (例: DB運用や証明書管理の自動化が可能)
    ○ Operatorを実装することで「分離された環境を構築する」という定義をデプロイすれば、分離環
    境の自動維持管理が実現可能
    ● クラウド環境が抽象化されハイブリッドクラウド構成が実現可能
    ○ ShopSetは当初から複数クラウド環境での動作を前提
    ○ クラウドサービスにk8sというレイヤーを挟む→操作するAPIの差を吸収
    オンプレk8sとEKSの並行運用の実際

    View Slide

  13. ShopSet on ハイブリッドクラウド
    オンプレk8sとEKSの並行運用の実際
    ● ハイブリッドクラウド化で解決したい課題
    ○ プライベートクラウドの可用性に依存しない
    ○ より柔軟なスケーリング
    ● AWSのマネージドk8sサービスのEKSを採用
    ○ 既にShopSet対象外の多数のステートフルリソースがAWS上で動作
    ○ プライベートクラウドと相互に内部通信可能なため使い勝手が良い

    View Slide

  14. オンプレk8sとEKSの並行運用の困難さ
    「k8sにすればプラットフォームが抽象化されて可搬性がよくなる」は
    単純な話ではなかった
    ● 意識しなければならない環境の違い
    ● 最適なスケーリング戦略の違い
    ● k8sクラスタの管理方法の違い etc…
    オンプレk8sとEKSの並行運用の実際

    View Slide

  15. 意識しなければならなかった環境の違い
    オンプレk8sとEKSの並行運用の実際
    type: LoadBalancer サービス
    ● LoadBalancer typeのService
    リソースを定義する際に動作する
    コントローラー
    ○ OpenStack:
    cloud-provider-openstack
    ○ EKS: AWS LoadBalancer
    Controller
    Service
    (type: LoadBalancer)
    Cloud
    Provider
    ①Deploy
    ②API Call
    LB
    ③Create
    Service
    (type: LoadBalancer)
    ALBC
    ①Deploy
    ②API Call ③Create

    View Slide

  16. オンプレk8sとEKSの並行運用の実際
    type: LoadBalancer サービス
    ● k8sのServiceのspecで表現できない
    設定は、それぞれの環境の
    cloud-provider/controller向けの
    設定をannotationで行う
    ● それぞれの環境向けのannotationを
    設定
    apiVersion: v1
    kind: Service
    metadata:
    name: my-service
    annotations:
    # For Nyah
    loadbalancer.openstack.org/proxy-protocol: "true"
    # For AWS
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
    spec:
    type: LoadBalancer
    ports:
    ...
    意識しなければならなかった環境の違い

    View Slide

  17. オンプレk8sとEKSの並行運用の実際
    PersistentVolume(永続化ボリューム)
    ● PVを作成した時、OpenStack環境では
    Cinder、EKS環境ではEBSが作成
    ● Nyahの設計による制限によりCinderは特定
    のノードタイプでしかマウントできないため、
    PVをマウントするPodは特定のlabelが付いた
    nodeに配置する必要がある
    Deploy
    Cinder
    volume
    Cloud Provider
    PVC
    Pod
    type: storage
    Node
    type: normal
    Node
    Pod
    API Call
    Crate
    Mount
    PVを利用するPodは
    特定Nodeに
    Scheduleが必要
    意識しなければならなかった環境の違い

    View Slide

  18. PersistentVolume(永続化ボリューム)
    ● 一方AWSはそのような制限がない。
    同じラベルを付与したノードグループを作成して、
    同じマニフェストを適用できるようにした
    ○ 開発者が環境差分を考慮する必要がないことを重視
    ○ kustomize等を用いて環境毎の差分をpatchする
    方法は選択しなかった
    Deploy
    EBS
    Cloud Provider
    PVC
    Pod
    type: storage
    Node
    type: normal
    Node
    Pod
    API Call
    Crate
    Mount
    EKS環境では
    どのNodeでもマ
    ウント可
    互換性のために
    ラベルをあえて
    付与
    オンプレk8sとEKSの並行運用の実際
    意識しなければならなかった環境の違い

    View Slide

  19. カスタムコントローラーの改修
    ● Route53で数十万のショップのDNSレコードを高速に操作するため、カスタムコント
    ローラーを作成
    ● Service ResourceのStatusに差異がある
    ○ OpenStack: Global IPアドレスが入る
    ○ EKS: エンドポイント名が入る
    ● OpenStack前提の処理になっていたため、エンドポイント名が入っていたら
    エイリアスレコードで登録するように改修
    オンプレk8sとEKSの並行運用の実際
    意識しなければならなかった環境の違い

    View Slide

  20. スケーリング戦略の違い
    ● プライベートクラウドのリソースを使いきり、
    間に合わない分をパブリッククラウドに
    オフロードするのが最もコスト効率が良い
    ● 別事業部でも同じ課題があり、独自オペレーター
    を作成
    菅原千晶.「k8s Operatorで運用負担減 &ハイブリッドクラウドのコスト最適化を
    した話」. CNDT2022.
    https://speakerdeck.com/ch1aki/k8s-operatordeyun-yong-fu-dan-jian-and-h
    aiburitudokuraudonokosutozui-shi-hua-wositahua
    オンプレk8sとEKSの並行運用の実際

    View Slide

  21. クラスタ管理方法の差異
    ● オンプレk8sでは内製ツール(NKE)により、社内のセキュリティポリシーに準拠した
    コンポーネント(audit log, FIM, 監視)がbuild-in
    ● NKEはOpenStack依存な部分があるため、そのままEKSへ流用は不可
    ● Terraformを用いてクラスタの構築と
    Build-inコンポーネントのセットアップを行っている
    ● NKE側の更新に追従して更新の手間がかかっているため改善したい
    オンプレk8sとEKSの並行運用の実際

    View Slide

  22. 大変なのにそれでもEKSを使うのは?
    年間1,000億円以上の流通を支えるのに見合うコストであるから
    ● プライベートクラウド全体の障害でもサービス継続が可能になる
    ● DBやキャッシュとの物理的な距離が近くなり、
    数百msのリクエストレイテンシーの改善ができる
    オンプレk8sとEKSの並行運用の実際

    View Slide

  23. 「k8sを使えば可搬性がよくなる」は
    単純な話ではなかった
    まとめ
    ShopSetではオンプレk8sとEKSで高可用性を実現していきます!

    View Slide