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

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

Transcript

1. オンプレk8sとEKSの 並行運用の実際 next
2. akichan 2018年3月にペパボカレッジ6期生として中途 入社。カラーミーショップをクラウドネイティブに するプロジェクトにSREとして携わっている。 @ch11aki @ch1aki 技術部プラットフォームグループ所属 Speaker
3. 今日話すこと • カラーミーショップのインフラの歴史 • ShopSetアーキテクチャ • オンプレk8sとEKSの並行運用の困難さ オンプレk8sとEKSの並行運用の実際
4. カラーミーショップのインフラの歴史 オンプレk8sとEKSの並行運用の実際 〜2015年 〜2019年 〜2020年 〜現在 • オンプレミスサーバー • プライベートクラウド • k8s on プライベートクラウド • ハイブリッドクラウド • next??? • データセンターで 数十台の物理サーバーを管理 • トラブルがあったら データセンターへ駆けつける時代🏃
5. 〜2015年 〜2019年 〜2020年 〜現在 • オンプレミスサーバー • プライベートクラウド • k8s on プライベートクラウド • ハイブリッドクラウド • next??? カラーミーショップのインフラの歴史 オンプレk8sとEKSの並行運用の実際 • OpenStackを用いて プライベートクラウド「Nyah」を構築 • AWSのように、WebコンソールやAPIで サーバーの管理が可能 • AWS EC2、EBS、NLB相当の機能を低 価格で提供
6. 〜2015年 〜2019年 〜2020年 〜現在 • オンプレミスサーバー • プライベートクラウド • k8s on プライベートクラウド • ハイブリッドクラウド • next??? • Nyah上でk8sクラスタを構築・ 管理する内製ツールを提供 • プライベートクラウドのVMとコンテナの 並行稼動 カラーミーショップのインフラの歴史 オンプレk8sとEKSの並行運用の実際
7. 〜2015年 〜2019年 〜2020年 〜現在 • オンプレミスサーバー • プライベートクラウド • k8s on プライベートクラウド • ハイブリッドクラウド • next??? • AWS Direct Connectを利用し、 プライベートクラウドとAWSが専用線で 相互に通信可能 • ステートフルリソースのDBやキャッシュを AWSのマネージドサービスに移行し、運用 コストを最適化 カラーミーショップのインフラの歴史 オンプレk8sとEKSの並行運用の実際
8. 〜2015年 〜2019年 〜2020年 〜現在 • オンプレミスサーバー • プライベートクラウド • k8s on プライベートクラウド • ハイブリッドクラウド • next??? カラーミーショップの根本的な アーキテクチャによる様々な制約を取り払う 次世代アーキテクチャを開発している カラーミーショップのインフラの歴史 オンプレk8sとEKSの並行運用の実際
9. カラーミーショップは「マルチテナント型」 • 複数のユーザーで一つのシステムを共有する形態 • システムの管理・運用コストを削減できるため、 安価にサービスを提供可能 App Load Balancer RDB • 一方で、 あるショップへのリクエスト増加による負荷が、 他のショップに与える可能性がある （様々なレイヤで対策をしている） オンプレk8sとEKSの並行運用の実際
10. オンプレk8sとEKSの並行運用の実際 • コロナ禍によるECへの需要が急増 • 既存の仕組みではショップ間の影響を抑えることが 困難なケースが多発 • 負荷の高いショップをインフラレベルで隔離して対応 →一定の効果 • 分離された環境は構築と管理の手間がかかった ◦ どのショップをどこに向けるか ◦ レートリミットの閾値 ◦ etc... App Load Balancer RDB App Load Balancer 共用 隔離 課題
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の並行運用の実際
12. ShopSetがk8sの上で実現されている理由 • 高度な自動化を実現するエコシステムがある ◦ k8s Operator （例: DB運用や証明書管理の自動化が可能） ◦ Operatorを実装することで「分離された環境を構築する」という定義をデプロイすれば、分離環 境の自動維持管理が実現可能 • クラウド環境が抽象化されハイブリッドクラウド構成が実現可能 ◦ ShopSetは当初から複数クラウド環境での動作を前提 ◦ クラウドサービスにk8sというレイヤーを挟む→操作するAPIの差を吸収 オンプレk8sとEKSの並行運用の実際
13. ShopSet on ハイブリッドクラウド オンプレk8sとEKSの並行運用の実際 • ハイブリッドクラウド化で解決したい課題 ◦ プライベートクラウドの可用性に依存しない ◦ より柔軟なスケーリング • AWSのマネージドk8sサービスのEKSを採用 ◦ 既にShopSet対象外の多数のステートフルリソースがAWS上で動作 ◦ プライベートクラウドと相互に内部通信可能なため使い勝手が良い
14. オンプレk8sとEKSの並行運用の困難さ 「k8sにすればプラットフォームが抽象化されて可搬性がよくなる」は 単純な話ではなかった • 意識しなければならない環境の違い • 最適なスケーリング戦略の違い • k8sクラスタの管理方法の違い etc… オンプレk8sとEKSの並行運用の実際
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
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: ... 意識しなければならなかった環境の違い
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が必要 意識しなければならなかった環境の違い
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の並行運用の実際 意識しなければならなかった環境の違い
19. カスタムコントローラーの改修 • Route53で数十万のショップのDNSレコードを高速に操作するため、カスタムコント ローラーを作成 • Service ResourceのStatusに差異がある ◦ OpenStack: Global IPアドレスが入る ◦ EKS: エンドポイント名が入る • OpenStack前提の処理になっていたため、エンドポイント名が入っていたら エイリアスレコードで登録するように改修 オンプレk8sとEKSの並行運用の実際 意識しなければならなかった環境の違い
20. スケーリング戦略の違い • プライベートクラウドのリソースを使いきり、 間に合わない分をパブリッククラウドに オフロードするのが最もコスト効率が良い • 別事業部でも同じ課題があり、独自オペレーター を作成 菅原千晶.「k8s Operatorで運用負担減 &ハイブリッドクラウドのコスト最適化を した話」. CNDT2022. https://speakerdeck.com/ch1aki/k8s-operatordeyun-yong-fu-dan-jian-and-h aiburitudokuraudonokosutozui-shi-hua-wositahua オンプレk8sとEKSの並行運用の実際
21. クラスタ管理方法の差異 • オンプレk8sでは内製ツール（NKE）により、社内のセキュリティポリシーに準拠した コンポーネント（audit log, FIM, 監視）がbuild-in • NKEはOpenStack依存な部分があるため、そのままEKSへ流用は不可 • Terraformを用いてクラスタの構築と Build-inコンポーネントのセットアップを行っている • NKE側の更新に追従して更新の手間がかかっているため改善したい オンプレk8sとEKSの並行運用の実際
22. 大変なのにそれでもEKSを使うのは? 年間1,000億円以上の流通を支えるのに見合うコストであるから • プライベートクラウド全体の障害でもサービス継続が可能になる • DBやキャッシュとの物理的な距離が近くなり、 数百msのリクエストレイテンシーの改善ができる オンプレk8sとEKSの並行運用の実際
23. 「k8sを使えば可搬性がよくなる」は 単純な話ではなかった まとめ ShopSetではオンプレk8sとEKSで高可用性を実現していきます!