【レポート】Kubenetes監視のベストプラクティスを伝授！ZOZOTOWNの成功レシピより #AWSSummit

セキュリティ製品特集

#イベントレポート

#監視サービス

#レポート

#AWS

#Kubernetes

吉江健斗

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんばんわ、札幌のヨシエです。
AWS Summit Tokyo 2019 2日目のG2-04で行われたセッションのレポートを書きましたのでご査収頂ければと思います。

登壇者

New Relic株式会社シニアソリューションコンサルタント日吉潤一郎

クラウドにおけるインフラのスケーリング、アプリケーションのメンテナンサビリティ向上、運用性/開発速度の向上を目的にKubernetes環境でのサービス運用を実施。 New Relic のKubernetes Cluster Explorer によって、クラウド環境のパフォーマンス改善及び品質向上を実現したベストプラクティスをご紹介します。

ZOZOTOWNの成功レシピ

登壇者

株式会社ZOZOテクノロジーズ ZOZOTOWN リプレースチームリーダー鶴見純一

提供サービス

ZOZOTOWN
- 最大級のファッションサイト
WEAR
- ファッション用SNS
ZOZO
- プライベートブランド
ZOZOSUIT

Agenda

監視について
NewRelicの監視(k8s関し含む)
ZOZOTOWN監視/運用

監視について

監視について考える

よくある光景
- 深夜にアラート通知が有りって慌てて対応する
  - SlackやPagerdutyで携帯に連絡が来る
  - 常に携帯電話と一緒の状態になっていく...→楽しくないので辞めたい
- 休日のアラートに怯える
  - 「なにかあると...」という不安からPCを持ち歩いたりと、仕事の区切りがない。
    - 平日は仕事/監視
    - 休日監視
システム運用監視を楽にする方法を考える
- ZOZOTOWNは10年ほど立っており、すべての面で監視を見直した
監視について
- 監視方法は数点あると考えている
  - ビジネス監視
    - ビジネスKPIなどの数値を監視
  - フロントエンド
    - HTTPやJSのエラー、パフォーマンス
  - アプリケーション監視
    - アプリケーションの死活監視、パフォーマンス
  - サーバー監視
    - CPUなどのリソースやSSL証明書
  - ネットワーク監視
    - 帯域、スループット、レイテンシ
  - セキュリティ監視
    - SSHやsudoの監視
- 「入門監視」を参照した

書評「入門　監視」雰囲気で監視をやっているすべての人にオススメ

監視種類
- 各監視をは大きく「ビジネスに関する監視」と「システムの安定運用に関する監視」の2点に分類されると考えられる
- ビジネス監視
  - 売上貢献が目的
    - 売上が増えるなど
    - 動向調査
- 運用監視
  - システムの安定運用が目的
    - サーバー監視
    - ネットワーク監視
    - セキュリティ監視
- 両方の監視に含まれる
  - フロントエンド監視
  - アプリケーション監視

運用監視面を考える

背景として、数年前とシステム要素が変わっていることから監視を全面再検討している
再検討にあたって、4つのフェーズで考慮を進めた
- 監視一覧作成
  - 10年経過したZOZOTOWNとして何を監視するのか(監視対象）を検討した
  - アンチパターン
    - 監視対象を決める前にツールを選ぶ
    - 再検討前のツールと同じツールを使う(流用)すると本当に問題が発生しているのか判断がつかない
- 監視設定
  - 監視設定を行う
  - アンチパターン
    - 「ツールで監視できない」ということで特定分野の監視を諦める
    - 監視出来ない分野が存在することで監視しないではなく、監視できるように作るか、別のツールを使用するを検討するべき
- 監視体制整理
  - 複数人の持ち回りで監視する体制を整える
  - アンチパターン
    - 一人による24時間365日監視は絶対にNG
- 運用
  - なるべく運用を自動化し、監視における負荷を下げる
  - アンチパターン
    - 監視専任チームはないが、常に張り付いて監視する

ZOZOTOWNリプレースで重視しているところ

現状ZOZOTOWNのシステムリプレースは約10%ほど進んでいる
このリプレースで重視していることは2点ある
- 安定したインフラ基盤を確保
  - ZOZOTOWNは短時間のシステムダウンによる損失が大きい
  - 求められる条件
    - 突然のアクセス増、セールに耐えられる構成
    - システムの一部が破損してもサービス継続
- アプリケーションパフォーマンス
  - ロード時間が100ms改善することで売上が良くなった
  - 最適なページロードは2sec
  - 5.1secは影響が出る
  - ZOZOはの主要ページは2sec以下を目指している
NewRelicの導入
- 監視対象一覧の作成後に監視をなるべく手間を減らすためのツールとして、一部の監視をNewRelicを利用している
監視ツールに求めたこと
- 簡単に設定ができる
- 見やすいグラフ、ダッシュボード
- エラー箇所の特定
- 外部サービス連携(Slack、Pagerdutyなど
- 新サービスの登場に追随する速度感
ZOZOTOWNでの使い方
- 主にアプリケーションとサーバー監視で利用している
  - APM
  - Infra(k8s監視)
ZOZOTOWN NewRelicの監視対象
- k8sを構成している全てのコンポーネントを監視している
  - Node
  - Pod
  - Cluster
  - Javaのコード
Cluster ExplorerとAPMを連携して、Javaアプリの監視を出来るようにしている
- 例として、VMの不具合でPodのりスタートが頻発した
  - HTTP502エラーが頻発し、どのPodがリスタートしたのか調査が大変だった
NewRelicではインフラからアプリケーションまでのレイヤーを網羅的に確認することが出来る
APMでJavaの関数単位でエラーやボトルネックを監視するようにしている
こういったAPMとInfrastructureを掛け合わせて監視が出来ることで非常に価値が出ている

NewRelicを使う理由

複数のk8sClusterを一元管理
インフラからAPまで監視ができる効果
インフラの一元管理によって監視運用負荷の軽減
問題発生時の調査時間軽減
パフォーマンスの可視化

ZOZOTOWNの監視事例

過去にZOZOTOWNが監視環境を構築するにあたっていくつかの経験があった

監視設定や体制を整えたが、すぐに安定運用とはならなかった

「必要かもしれない」という理由でたくさんの監視を追加した、そうなるとアラートが毎日発報されるようになった
- 重要度が不明になり、アラートを無視する状況が生まれた
- サービス影響度を考慮し、監視を見直して影響がないものを監視しないようにした
- システムエラーが発生してもサービスに影響がなければ障害ではない
- k8sではオートヒーリングで自動復旧するので、こういう面でサービス提供に影響がないのであれば通知をやめることも視野に入れる

誰も見ていない監視用ダッシュボード

見ない(参照されない)ダッシュボードがあると混乱を招くだけ
- 必要のないものは削除する

障害対応方法のドキュメントがあるが、対応がそのとおりに行われない

組織変更などメンバー変更がある場合は定期的な障害対応訓練が必要(実施予定)

誰が監視を行うのか当番が決まっていない、リーダーが休日を含めて監視する

担当者レベルで権限を与えて、全体で管理できるようにするべきかと考える
- 監視不可を分散する
- 当事者意識が高まる

最後に

前半にNewRelicでのコンテナ環境監視に対するアプローチの発表があり、機能面が充実している事がわかりました。後半にはZOZOTOWNのリプレース時に見えてくる痛みの部分がわかりやすい形で発表されました。運用監視において「普通に動いて当たり前」を確保するために多くのアプローチに取り組んでおり、とても運用監視フェーズ部分に関してわかりやすい言語化でした。システム面はドキュメントに残るなど、目に見えやすい箇所が多いと思いますが実際の運用では見えない部分がストレスになるので常に障害対応を自動化で解決し、すべての事象が解決出来ることは全エンジニアの目標になるのかと思いました。