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の並行運用の実際 〜2015年 〜2019年 〜2020年 〜現在 • オンプレミスサーバー • プライベートクラウド

    • k8s on プライベートクラウド • ハイブリッドクラウド • next??? • データセンターで 数十台の物理サーバーを管理 • トラブルがあったら データセンターへ駆けつける時代🏃
  2. 〜2015年 〜2019年 〜2020年 〜現在 • オンプレミスサーバー • プライベートクラウド • k8s

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

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

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

    on プライベートクラウド • ハイブリッドクラウド • next??? カラーミーショップの根本的な アーキテクチャによる様々な制約を取り払う 次世代アーキテクチャを開発している カラーミーショップのインフラの歴史 オンプレk8sとEKSの並行運用の実際
  6. カラーミーショップは「マルチテナント型」 • 複数のユーザーで一つのシステムを共有する形態 • システムの管理・運用コストを削減できるため、 安価にサービスを提供可能 App Load Balancer RDB

    • 一方で、 あるショップへのリクエスト増加による負荷が、 他のショップに与える可能性がある (様々なレイヤで対策をしている) オンプレk8sとEKSの並行運用の実際
  7. オンプレk8sとEKSの並行運用の実際 • コロナ禍によるECへの需要が急増 • 既存の仕組みではショップ間の影響を抑えることが 困難なケースが多発 • 負荷の高いショップをインフラレベルで隔離して対応 →一定の効果 •

    分離された環境は構築と管理の手間がかかった ◦ どのショップをどこに向けるか ◦ レートリミットの閾値 ◦ etc... App Load Balancer RDB App Load Balancer 共用 隔離 課題
  8. 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の並行運用の実際
  9. ShopSetがk8sの上で実現されている理由 • 高度な自動化を実現するエコシステムがある ◦ k8s Operator (例: DB運用や証明書管理の自動化が可能) ◦ Operatorを実装することで「分離された環境を構築する」という定義をデプロイすれば、分離環

    境の自動維持管理が実現可能 • クラウド環境が抽象化されハイブリッドクラウド構成が実現可能 ◦ ShopSetは当初から複数クラウド環境での動作を前提 ◦ クラウドサービスにk8sというレイヤーを挟む→操作するAPIの差を吸収 オンプレk8sとEKSの並行運用の実際
  10. ShopSet on ハイブリッドクラウド オンプレk8sとEKSの並行運用の実際 • ハイブリッドクラウド化で解決したい課題 ◦ プライベートクラウドの可用性に依存しない ◦ より柔軟なスケーリング

    • AWSのマネージドk8sサービスのEKSを採用 ◦ 既にShopSet対象外の多数のステートフルリソースがAWS上で動作 ◦ プライベートクラウドと相互に内部通信可能なため使い勝手が良い
  11. 意識しなければならなかった環境の違い オンプレ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
  12. オンプレ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: ... 意識しなければならなかった環境の違い
  13. 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の並行運用の実際 意識しなければならなかった環境の違い
  14. カスタムコントローラーの改修 • Route53で数十万のショップのDNSレコードを高速に操作するため、カスタムコント ローラーを作成 • Service ResourceのStatusに差異がある ◦ OpenStack: Global

    IPアドレスが入る ◦ EKS: エンドポイント名が入る • OpenStack前提の処理になっていたため、エンドポイント名が入っていたら エイリアスレコードで登録するように改修 オンプレk8sとEKSの並行運用の実際 意識しなければならなかった環境の違い
  15. スケーリング戦略の違い • プライベートクラウドのリソースを使いきり、 間に合わない分をパブリッククラウドに オフロードするのが最もコスト効率が良い • 別事業部でも同じ課題があり、独自オペレーター を作成 菅原千晶.「k8s Operatorで運用負担減

    &ハイブリッドクラウドのコスト最適化を した話」. CNDT2022. https://speakerdeck.com/ch1aki/k8s-operatordeyun-yong-fu-dan-jian-and-h aiburitudokuraudonokosutozui-shi-hua-wositahua オンプレk8sとEKSの並行運用の実際
  16. クラスタ管理方法の差異 • オンプレk8sでは内製ツール(NKE)により、社内のセキュリティポリシーに準拠した コンポーネント(audit log, FIM, 監視)がbuild-in • NKEはOpenStack依存な部分があるため、そのままEKSへ流用は不可 •

    Terraformを用いてクラスタの構築と Build-inコンポーネントのセットアップを行っている • NKE側の更新に追従して更新の手間がかかっているため改善したい オンプレk8sとEKSの並行運用の実際