マネージド kubernetes ガチ本番運用...ifg ihh e g d e g f hf f f d i 502エラー...

de:code 2019 CD12

マネージド Kubernetes ガチ本番運用

in ZOZOTOWN

リーダー / エンジニア

鶴見純一 / 竹中達志

自己紹介

登壇者

ZOZO について

ZOZOTOWN

・日本最大級のファッションショッピングサイト / アプリ

・ 1,200以上のショップ、7,000以上のブランドの取り扱い

（2019年3月末時点）

・常時73万点以上の商品アイテム数と

毎日平均3,200点以上の新着商品を掲載

・即日配送サービス

・ギフトラッピングサービス

・ツケ払いなど

https : //zozo. jp/

WEAR

・日本最大級のファッションコーディネートアプリ

・ 1,300万ダウンロード突破、コーディネート投稿総数は800万件

以上（ともに2019年3月末時点）

・全世界（App Store / Google P layが利用可能な

全ての国）でダウンロードが可能

・ 10万人以上のフォロワーを持つユーザー（WEARISTA）も誕生

https : //wear . jp/

・「ZOZOSUIT」で計測した体型データをもとに、一人ひとりの

体型に合った「あなたサイズ」のアイテム

・「究極のフィット感」を実現したベーシックアイテムを提供

・アイテム : Ｔシャツ / デニムパンツ / シャツ / ビジネススーツ /

ネクタイ / ボーダーＴシャツ / 長袖クルーネックＴシャツなど

https : //zozo. jp/brand/zozo/?dord=21

ZOZOSUIT

・独自に開発した採寸用ボディースーツ

・全体に施されたドットマーカーをスマートフォンカメラで360度

撮影することで、体型データを計測

・計測した体型データは、瞬時に3Dモデル化され、ZOZOTOWN

アプリに保存。3Dモデルはあらゆる角度に動かすことができ、

体型を360度チェックすることが可能

https : //zozo. jp/zozosui t/

概要

対象者

内容

Kubernetes 採用の背景

なぜ Kubernetes を採用したのか？


セールセール

ZOZO

WEEK

ZOZO

WEEK

Kubernetes 運用の目的


安定運用

• 運用負荷軽減

マイクロサービスマルチクラウド

今後のビジョン

リプレースの歴史

システムリプレースについて

システムリプレースについて

システム名機能名リプレース状況

ECサイト参照系 ○

ECサイト更新系ー

バックエンドシステム基幹業務ー

バックエンドシステム物量配送業務ー

Kubernetes 状況

2018/08 2018/12 2019/01 2019/04

・ACS-Engine 稼働

・Kubernetes 脆弱性発覚CVE-2018-1002105

・AKS 検証

・AKS 稼働（Kubernetes Version Up）

・Kubernetes 脆弱性発覚2月：

4月：CVE-2019-1002100、CVE-2019-1002101、

CVE-2019-9946

・Kubernetes Version Up

運用について

Kubernetes 運用について

マイクロソフトユニファイドサポートが手厚い

マネージド Kubernetes について

なぜマネージド Kubernetes を利用したか？

コスト

運用

• サポートへの問い合わせが可能

コスト削減

Azure 上リソースの数

但し、カスタマイズ幅は小さくなる

Kubernetes 導入

Kubernetes 導入

Kubernetes の理論的には安定稼働する

Kubernetes 導入したところ無事に動いた

Kubernetes の構成

Kubernetes の構成

502エラー

難航するエラー調査

HttpStatus 400、500、502 エラー発生

調査すべき部分は広範囲

担保するべき要件

エラーレート 0.001% 以下

• 正常 99.999 %

AKS の特性

AKS の特性

Azure Active Directory

障害事例

事象：突然 pod が Apply 不可になった

原因：Service Principal の期限切れでクラウドリソースの

操作ができなくなったことが原因

Az コマンドで Kubernetes 操作

Az コマンドで Kubernetes 操作について

Az コマンドにて Kubernetes を操作できるが、

ラッパー例

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster

↓

kubectl drainkubectl uncordon

安定稼働までの道のり

本番運用

本番運用前の検証、実測が大事

• マネージドだから任せられる → NO

Kubernetes の知識が必須

• 動作を理解しないと検証ができない

検証・実測できる環境を作る

クラスターを使い捨てる

• 本番稼働中の環境を変更しない

• 人間なので、どの環境で何を変更したかは必ず忘れる

苦労したこと

Kubernetes のアーキテクチャに対する知識

広範囲のレイヤーに対する知識

想定外の事象

node や pod が落ちることがある

安定稼働させるための結論

• 検証できる環境整備が必要

• 検証、実測に基づくチューニングが必要

Rolling update の注意点

サービスが継続できる pod 数を常に確保する

maxSurge、maxUnavailable

• Deployment を用いた Rolling update 時

PodDisruptionBudget

• node からの Drain 時

Rolling update

maxSurge：3、maxUnavailable：0

PodDisruptionBudget

maxUnavailable：1

Graceful Shutdownの設定

アクセスの強制切断が発生しないように

Graceful Shutdown を設定する

lifecycle.preStop

• pod の termination時に実行される処理。pod の restart 時必要になる

• Service の更新と pod の termination は非同期なため、適切に設定する

• アプリケーションごとに必要な時間・処理が異なるので難しい

Graceful Shutdown

Termination of pods

ヘルスチェック

• pod 起動時間を考慮して Probe を開始する

• ヘルスチェック用のエンドポイントを設定する (/health など)

• データベースのタイムアウト値を考慮する

ヘルスチェック

リソース制限

• pod に割り当てる cpu やメモリが小さいと、立ち上がりが急激に遅くなる

pod の pending

pod pending に対する node のスケーリング

Rolling update結論

システムリプレースで躓いた箇所

データベースパフォーマンス

データベースのパフォーマンスがボトルネックの場合 pod、

node のスケールでは全体のパフォーマンス向上は難しい

総括

• 覚えることが多く、躓いた部分もあったが、安定運用している

• クラウド化により、リソース不足の心配がなくなった

• コンテナ化したことでマイクロサービス化の足掛かりになった

• マネージド Kubernetes にすることでコストを削減しつつ、運

用負荷も軽減できた

マネージド kubernetes ガチ本番運用...ifg ihh e g d e g f hf f f d i 502エラー...

Documents