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

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

Clock Icon2019.06.14

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

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

登壇者

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

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

最新のk8s監視

  • なぜk8sユーザーが数が爆発的に増えているのか?
    • インフラとアプリケーションを纏めて管理したいという目的が合った
    • オーケストラレーションのリーダーとして扱われる
    • モノリシックからk8sへシフトが始まった
      • VM上のアプリケーション
      • VM上のコンテナ内にアプリケーション
      • オーケストラレートされたアプリケーション
  • 以前のモノリシックアプリケーションとの違いは?
    • 特定のコードが「いつ」「どこで」実行されているかわからなかった
    • 例として、Javaが動いているサーバーを特定し、依存関係を把握出来、デプロイ感覚も多くなかった
    • 現在では250のマイクロサービスが動いており、非常早いスパンでアプリケーションのデプロイが実現されている
    • 一つの障害によって、被疑箇所の特定が難しくなっていく
  • k8sでは、様々なハードウェア(Node)でPodが実行され、Pod中にコンテナが起動している
  • ユーザー側から見えている部分(フロントエンド)は、どのコンテナを指しているのか把握することが非常に難しかった
  • そこでNewRelic Oneの「Cluster Exploler」を提供しており、1画面ですべての要素(Pod,node,cluster)を確認することができるインターフェースを提供している

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

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.