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

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

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

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

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

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

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

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

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

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

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の並行運用の実際

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

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

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

意識しなければならなかった環境の違い オンプレ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

オンプレ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: ... 意識しなければならなかった環境の違い

オンプレ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が必要 意識しなければならなかった環境の違い

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の並行運用の実際 意識しなければならなかった環境の違い

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

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

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

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

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