Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SREが取り組むカラーミーショップへのk8s導入

ch1aki
February 25, 2021

 SREが取り組むカラーミーショップへのk8s導入

Pepabo Tech Conference #14

ch1aki

February 25, 2021
Tweet

More Decks by ch1aki

Other Decks in Technology

Transcript

  1. 2 自己紹介 • 技術部プラットフォームグループ(PFG)所属 • 経歴 ◦ 2015/4~ システム運用系SE ◦

    2018/3~ ペパボカレッジ6期入社 • 業務内容:カラーミーショップのインフラ運用 ◦ 運用効率化 ◦ 可用性の改善 • 趣味 ◦ 自作キーボード⌨ ◦ 猫の撮影🐈 2 菅原 千晶 / akichan 2021/7/1入社 ペパカレ(SRE) 現在募集中!
  2. 7 7 ペパボにおけるSREの取り組み • ショップの売り上げに対する影響が大きいところを計測 ◦ e.g. 決済関連、ショップの管理画面、ショップページ • 週次で

    SLIを振り返る会 を実施 ◦ 可用性に影響する可能性があるリリース予定の共有 ◦ SLIのトレンドの変化の確認 ◦ 直近で発生したインシデントやオンコールの確認 カラーミーショップのSLO設定 SLOを維持するために、需要増の傾向に対して 事前にスケールアウトなどの対策ができた
  3. 8 8 ペパボにおけるSREの取り組み • 失敗から学ぶための振り返り • 2018年以降、200件以上の ポストモーテムを作成 (全サービス合計) •

    ポストモーテムは社内のオープンな リポジトリで管理される ポストモーテム インシデントハンドリングを支援するslack botを利用 - 関係者の召集 - タイムキーピング - ポストモーテム作成の支援 - etc ポストモーテムの結果、システムアーキテクチャの 変更などによる可用性向上の取り組みが行われた
  4. 9 9 ペパボにおけるSREの取り組み モニタリングの改善 • あるとき、外部のメールリレーサービスで送信障害が発生 • 監視が不十分で気づくことができなかった ◦ 管理画面からはメトリクスの変化が追跡しづらく異常の判断が困難

    ◦ 監視サービスに対応していない ▪ APIで瞬間的なメトリクスが取得可能だった • メトリクスの変化を追跡可能にするため、Mackerelプラグインを開発 ソフトウェアエンジニアリングによる問題解決 メトリクスの傾向の変化から、 従来よりも早く異常を検知可能になった
  5. 10 10 ソフトウェアエンジニアリングによる問題解決 ペパボにおけるSREの取り組み 監視設定の トレーサビリティ改善・属人化の排除 • 依頼を元にSREが監視設定を手動で変更していた • 監視設定の抜け漏れ、意図しない変更によって障害影響範囲の特定が遅延

    • 監視設定のコード化&デプロイ自動化 ◦ Mackerel設定をTerraform化 ◦ PRマージでTerraform自動適用 ◦ mercari/tfnotify によってPR上でplan結果確認&適用後の結果を通知 監視設定変更のセルフサービス化& 変更履歴の追跡が可能に
  6. 12 12 カラーミーショップのインフラが抱える課題 カラーミーショップへのk8s導入 • OS, ミドルウェアのバージョンアップにかかる時間的コストが多い ◦ インスタンスを作成し、アップデート、動作検証、本番環境へ ◦

    ロールバックの場合はさらに一手間 • スケーリングに時間がかかり急なアクセス増に十分に対応できない ◦ インスタンス作成、プロビジョニングで数十分程度 • Nyahにロックインしている ◦ IaCやアーキテクチャがNyah前提 ◦ マルチクラウド化を進める際に改修や管理の工数が膨らむ
  7. 14 14 コンテナプラットフォーム移行を行うことで改善できそうなこと カラーミーショップへのk8s導入 • OS, ミドルウェアのバージョンアップ ◦ 手元の再現性が高い環境で動作検証が可能 ◦

    バージョンアップ・ロールバックはイメージの入れ替えで済む • スケールアウト時間 ◦ インスタンスの追加の代わりにコンテナの数を増やす ◦ 数分程度で簡単にリソースを増減できる • ロックインからの解放 ◦ クラウドインフラ環境が抽象化され、サービスのポータビリ ティが向上
  8. 15 15 ペパボのk8sを取り巻く環境 カラーミーショップへのk8s導入 • プライベートクラウド Nyah (OpenStack) • クラスタ管理ツール

    NKE (Nyah Kubernetes Engine) ◦ 社内のセキュリティ基準に準拠した構成でクラスタを構築 ◦ built-inのモニタリングコンポーネント ◦ 全社共通ログ基盤へシステムコンポーネントログを集約 • 各サービス毎にNKEでNyah上にクラスタを構築し運用
  9. 18 18 全アプリケーションがコンテナ化される時の懸念 カラーミーショップへのk8s導入 導入当初、マニフェストの適用は手動オペレーションで行っていた • オペレーションミスの増加 → 可用性の低下 •

    変更のトレーサビリティが失われる → MTTR増加 • k8sに不慣れな開発者が多い → デプロイ作業の属人化 k8sへの移行を効率的に進めるために、 まずはデプロイの改善が必要と考えた
  10. 20 20 What’s GitOps? カラーミーショップへのk8s導入 • weaveworks社が提唱し始めた k8s運用のプラクティス • Git管理のmanifestを信頼でき

    る唯一の情報源として扱い、 継続的デプロイ • 得られる効果 ◦ 変更がコミット履歴で追跡可 ◦ 構成ドリフトの解消 引用: weaveworks blog. “What DevOps is to the Cloud, GitOps is to Cloud Native”. https://www.weave.works/blog/gitops-is-cloud- native
  11. 21 GitOps実現のために考えたこと 21 カラーミーショップへのk8s導入 ヒューマンエラー の介入防止 変更の追跡 デプロイ属人化 の排除 •

    アプリケーションの更新 をトリガーに、自動で最 新イメージのタグへ更新 するPR作成 • manifestリポジトリで stagingへの反映後に自動 でproductionへの反映PR 作成 • イメージタグ更新PR上でアプリ ケーションの変更差分の確認 • リリース完了の通知 • わかりやすいWebインター フェースを持つArgoCDを 選択 • manifestはシンプルに全て 一つのリポジトリ
  12. 22 22 feat master release manifests repo staging production sample-app

    image registory Build & Push image Create PR (update image tag) カラーミーショップへのk8s導入 Merge master sync sync notify
  13. 25 25 今後やっていくこと • これまで2度クラスタマイグレーションを実施 ◦ クラスタのアップグレードでダウンタイムが発生するため ◦ 毎回クラスタの切り替えには手間と時間がかかっている •

    実現したいこと ◦ クラスタ障害、クラウド環境の障害影響を低減 ◦ プライベートクラウドのコストメリットを最大限に活用した、 コスパのいいコンテナプラットフォーム マルチクラウドでk8sマルチクラスタ化による可用性向上
  14. 26 26 今後やっていくこと • 単純なコンテナ化では解決できない課題 ◦ 全ショップでリソースを共有するアーキテクチャのため、特定ショッ プ起因の障害が全ショップへ波及する(e.g. 人気商品の販売) •

    実現したいこと ◦ マルチクラスタやリソースの論理的分割による可用性向上 現在、既存アプリのコンテナ化に並行してリアーキテクチャ進行中 カラーミーショップのリアーキテクチャ
  15. 28 まとめ • ペパボのSREが普段やっていることを紹介 SLO, ポストモーテム, 改善活動 • 注力しているカラーミーショップへのk8s導入とGitOps の取り組みを紹介

    • 今後やっていくことを述べた ◦ k8sマルチクラスタ化による可用性向上 ◦ カラーミーショップのリアーキテクチャ 28