カラーミーショップのエンジニアが話すこれまでとこれから 2023 (https://pepabo.connpass.com/event/266671/)
オンプレk8sとEKSの並行運用の実際next
View Slide
akichan2018年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の並行運用の実際
カラーミーショップは「マルチテナント型」● 複数のユーザーで一つのシステムを共有する形態● システムの管理・運用コストを削減できるため、安価にサービスを提供可能AppLoad BalancerRDB● 一方で、あるショップへのリクエスト増加による負荷が、他のショップに与える可能性がある(様々なレイヤで対策をしている)オンプレk8sとEKSの並行運用の実際
オンプレk8sとEKSの並行運用の実際● コロナ禍によるECへの需要が急増● 既存の仕組みではショップ間の影響を抑えることが困難なケースが多発● 負荷の高いショップをインフラレベルで隔離して対応→一定の効果● 分離された環境は構築と管理の手間がかかった○ どのショップをどこに向けるか○ レートリミットの閾値○ etc...AppLoad BalancerRDBAppLoad Balancer共用 隔離課題
ShopSetアーキテクチャ● 複数の論理的な分離された環境を効率的に作成するTakuya Takahashi.「カラーミーショップの 可用性向上のための インフラ刷新」. GMO Developers Night (2021).https://speakerdeck.com/takutakahashi/karamisiyotupufalse-ke-yong-xing-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 LoadBalancerControllerService(type: LoadBalancer)CloudProvider①Deploy②API CallLB③CreateService(type: LoadBalancer)ALBC①Deploy②API Call ③Create
オンプレk8sとEKSの並行運用の実際type: LoadBalancer サービス● k8sのServiceのspecで表現できない設定は、それぞれの環境のcloud-provider/controller向けの設定をannotationで行う● それぞれの環境向けのannotationを設定apiVersion: v1kind: Servicemetadata:name: my-serviceannotations:# For Nyahloadbalancer.openstack.org/proxy-protocol: "true"# For AWSservice.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: LoadBalancerports:...意識しなければならなかった環境の違い
オンプレk8sとEKSの並行運用の実際PersistentVolume(永続化ボリューム)● PVを作成した時、OpenStack環境ではCinder、EKS環境ではEBSが作成● Nyahの設計による制限によりCinderは特定のノードタイプでしかマウントできないため、PVをマウントするPodは特定のlabelが付いたnodeに配置する必要があるDeployCindervolumeCloud ProviderPVCPodtype: storageNodetype: normalNodePodAPI CallCrateMountPVを利用するPodは特定NodeにScheduleが必要意識しなければならなかった環境の違い
PersistentVolume(永続化ボリューム)● 一方AWSはそのような制限がない。同じラベルを付与したノードグループを作成して、同じマニフェストを適用できるようにした○ 開発者が環境差分を考慮する必要がないことを重視○ kustomize等を用いて環境毎の差分をpatchする方法は選択しなかったDeployEBSCloud ProviderPVCPodtype: storageNodetype: normalNodePodAPI CallCrateMountEKS環境ではどの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-haiburitudokuraudonokosutozui-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で高可用性を実現していきます!