Slide 1

Slide 1 text

1 SREが取り組む カラーミーショップへの k8s導入 Pepabo Tech Conference #14 (2021/02/25 ) 菅原 千晶 / GMO Pepabo, Inc.

Slide 2

Slide 2 text

2 自己紹介 ● 技術部プラットフォームグループ(PFG)所属 ● 経歴 ○ 2015/4~ システム運用系SE ○ 2018/3~ ペパボカレッジ6期入社 ● 業務内容:カラーミーショップのインフラ運用 ○ 運用効率化 ○ 可用性の改善 ● 趣味 ○ 自作キーボード⌨ ○ 猫の撮影🐈 2 菅原 千晶 / akichan 2021/7/1入社 ペパカレ(SRE) 現在募集中!

Slide 3

Slide 3 text

3 3 目次 1. ペパボにおけるSREの取り組み 2. カラーミーショップへのk8s導入 3. 今後の話 SREとして 注力している 施策

Slide 4

Slide 4 text

4 ペパボにおける SREの取り組み 4

Slide 5

Slide 5 text

5 5 ペパボにおけるSREの取り組み ● 技術部のミッションは「全社統合的なアプローチで、 技術による効率化と事業成果の最大化を図る」 ● セキュリティ対策、基盤プロダクトなどのサービス共通の問題を 解決するソリューションをプラットフォームとして提供 ● IT運用に対するソフトウェア・エンジニアリング アプローチである Site Reliability Engineeringを取り入れ、事業成果の最大化に貢献 技術部がSREに取り組む理由

Slide 6

Slide 6 text

6 6 SRE活動の 実例

Slide 7

Slide 7 text

7 7 ペパボにおけるSREの取り組み ● ショップの売り上げに対する影響が大きいところを計測 ○ e.g. 決済関連、ショップの管理画面、ショップページ ● 週次で SLIを振り返る会 を実施 ○ 可用性に影響する可能性があるリリース予定の共有 ○ SLIのトレンドの変化の確認 ○ 直近で発生したインシデントやオンコールの確認 カラーミーショップのSLO設定 SLOを維持するために、需要増の傾向に対して 事前にスケールアウトなどの対策ができた

Slide 8

Slide 8 text

8 8 ペパボにおけるSREの取り組み ● 失敗から学ぶための振り返り ● 2018年以降、200件以上の ポストモーテムを作成 (全サービス合計) ● ポストモーテムは社内のオープンな リポジトリで管理される ポストモーテム インシデントハンドリングを支援するslack botを利用 - 関係者の召集 - タイムキーピング - ポストモーテム作成の支援 - etc ポストモーテムの結果、システムアーキテクチャの 変更などによる可用性向上の取り組みが行われた

Slide 9

Slide 9 text

9 9 ペパボにおけるSREの取り組み モニタリングの改善 ● あるとき、外部のメールリレーサービスで送信障害が発生 ● 監視が不十分で気づくことができなかった ○ 管理画面からはメトリクスの変化が追跡しづらく異常の判断が困難 ○ 監視サービスに対応していない ■ APIで瞬間的なメトリクスが取得可能だった ● メトリクスの変化を追跡可能にするため、Mackerelプラグインを開発 ソフトウェアエンジニアリングによる問題解決 メトリクスの傾向の変化から、 従来よりも早く異常を検知可能になった

Slide 10

Slide 10 text

10 10 ソフトウェアエンジニアリングによる問題解決 ペパボにおけるSREの取り組み 監視設定の トレーサビリティ改善・属人化の排除 ● 依頼を元にSREが監視設定を手動で変更していた ● 監視設定の抜け漏れ、意図しない変更によって障害影響範囲の特定が遅延 ● 監視設定のコード化&デプロイ自動化 ○ Mackerel設定をTerraform化 ○ PRマージでTerraform自動適用 ○ mercari/tfnotify によってPR上でplan結果確認&適用後の結果を通知 監視設定変更のセルフサービス化& 変更履歴の追跡が可能に

Slide 11

Slide 11 text

11 カラーミーショップへの k8s導入 11

Slide 12

Slide 12 text

12 12 カラーミーショップのインフラが抱える課題 カラーミーショップへのk8s導入 ● OS, ミドルウェアのバージョンアップにかかる時間的コストが多い ○ インスタンスを作成し、アップデート、動作検証、本番環境へ ○ ロールバックの場合はさらに一手間 ● スケーリングに時間がかかり急なアクセス増に十分に対応できない ○ インスタンス作成、プロビジョニングで数十分程度 ● Nyahにロックインしている ○ IaCやアーキテクチャがNyah前提 ○ マルチクラウド化を進める際に改修や管理の工数が膨らむ

Slide 13

Slide 13 text

13 13 コンテナプラットフォームへ 移行することで改善できそう

Slide 14

Slide 14 text

14 14 コンテナプラットフォーム移行を行うことで改善できそうなこと カラーミーショップへのk8s導入 ● OS, ミドルウェアのバージョンアップ ○ 手元の再現性が高い環境で動作検証が可能 ○ バージョンアップ・ロールバックはイメージの入れ替えで済む ● スケールアウト時間 ○ インスタンスの追加の代わりにコンテナの数を増やす ○ 数分程度で簡単にリソースを増減できる ● ロックインからの解放 ○ クラウドインフラ環境が抽象化され、サービスのポータビリ ティが向上

Slide 15

Slide 15 text

15 15 ペパボのk8sを取り巻く環境 カラーミーショップへのk8s導入 ● プライベートクラウド Nyah (OpenStack) ● クラスタ管理ツール NKE (Nyah Kubernetes Engine) ○ 社内のセキュリティ基準に準拠した構成でクラスタを構築 ○ built-inのモニタリングコンポーネント ○ 全社共通ログ基盤へシステムコンポーネントログを集約 ● 各サービス毎にNKEでNyah上にクラスタを構築し運用

Slide 16

Slide 16 text

16 16 k8s導入初期 カラーミーショップへのk8s導入 ● クラスタ構築 🆕 ● 既存アプリケーションがコンテナ化され本 番稼働開始 🎊 ● 新規開発のアプリケーションが稼働開始 ● 2019 2020 k8s移行が さらに加速?

Slide 17

Slide 17 text

17 17 このまま 全てのアプリケーションが コンテナ化されたら? 🤔

Slide 18

Slide 18 text

18 18 全アプリケーションがコンテナ化される時の懸念 カラーミーショップへのk8s導入 導入当初、マニフェストの適用は手動オペレーションで行っていた ● オペレーションミスの増加 → 可用性の低下 ● 変更のトレーサビリティが失われる → MTTR増加 ● k8sに不慣れな開発者が多い → デプロイ作業の属人化 k8sへの移行を効率的に進めるために、 まずはデプロイの改善が必要と考えた

Slide 19

Slide 19 text

19 19 “GitOps”で 解決できそう

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

21 GitOps実現のために考えたこと 21 カラーミーショップへのk8s導入 ヒューマンエラー の介入防止 変更の追跡 デプロイ属人化 の排除 ● アプリケーションの更新 をトリガーに、自動で最 新イメージのタグへ更新 するPR作成 ● manifestリポジトリで stagingへの反映後に自動 でproductionへの反映PR 作成 ● イメージタグ更新PR上でアプリ ケーションの変更差分の確認 ● リリース完了の通知 ● わかりやすいWebインター フェースを持つArgoCDを 選択 ● manifestはシンプルに全て 一つのリポジトリ

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 23 GitOps化の結果 カラーミーショップへのk8s導入 ● 順調にk8sで稼働するアプリケーションが増加 ● デプロイミスなどリリース起因の障害は発生していない ● k8sに慣れていない開発者でもデプロイができるようになった ● 構成ドリフトを検出・自動で修正することができるようになった

Slide 24

Slide 24 text

24 今後やっていくこと 24

Slide 25

Slide 25 text

25 25 今後やっていくこと ● これまで2度クラスタマイグレーションを実施 ○ クラスタのアップグレードでダウンタイムが発生するため ○ 毎回クラスタの切り替えには手間と時間がかかっている ● 実現したいこと ○ クラスタ障害、クラウド環境の障害影響を低減 ○ プライベートクラウドのコストメリットを最大限に活用した、 コスパのいいコンテナプラットフォーム マルチクラウドでk8sマルチクラスタ化による可用性向上

Slide 26

Slide 26 text

26 26 今後やっていくこと ● 単純なコンテナ化では解決できない課題 ○ 全ショップでリソースを共有するアーキテクチャのため、特定ショッ プ起因の障害が全ショップへ波及する(e.g. 人気商品の販売) ● 実現したいこと ○ マルチクラスタやリソースの論理的分割による可用性向上 現在、既存アプリのコンテナ化に並行してリアーキテクチャ進行中 カラーミーショップのリアーキテクチャ

Slide 27

Slide 27 text

27 まとめ 27

Slide 28

Slide 28 text

28 まとめ ● ペパボのSREが普段やっていることを紹介 SLO, ポストモーテム, 改善活動 ● 注力しているカラーミーショップへのk8s導入とGitOps の取り組みを紹介 ● 今後やっていくことを述べた ○ k8sマルチクラスタ化による可用性向上 ○ カラーミーショップのリアーキテクチャ 28