はじめに
こんにちは、SRE部カート決済SREブロックの伊藤（@_itito_）です。普段はZOZOTOWNのカート決済機能のリプレイス・運用・保守に携わっています。また、DB領域でのテックリードを担っており、データベース（以下DB）周りの運用・保守・構築に関わっています。
現在、ZOZOには DBを専門で扱う部署はありません。一部メンバーでDatabase Reliability Engineeringのワーキンググループ（以下DBRE-WG）を構成して、DBの信頼性を高めるための活動をしています。
本記事ではZOZOにおけるDBRE-WGの概要と発生していた課題と、いかにして開発メンバーを招き、その結果どのような効果があったかの事例をご紹介します。
ZOZOにおけるDBRE活動について
SRE部で行っているワーキンググループについて
現在私が所属しているEC基盤開発本部SRE部は複数のブロック（チーム）で構成されています。このSRE部内の、ブロックを跨いだ活動を促進するための横断組織として複数のWGが存在しており、この中の1つとしてDBRE-WGが存在します。
DBRE-WGで行っていること
DBRE-WGは「各プロダクトのデータベース健全性を維持向上させる」ことを目的として、以下のような取り組みを実施しています。
DB関連での問い合わせ・レビュー対応
DBの設計や運用に関する質問や、パフォーマンス悪化や予期せぬエラーの発生といった緊急性の高い問い合わせなど、様々な問い合わせに対応しています。作成予定のテーブルの設計が問題ないか、ZOZO内でのDBの開発ガイドラインに沿っているかなどのレビューも行っています。
各種案件におけるDB周りのサポート
DB設計が重要な役割を担う場合や、保守期限が迫っていてDB更改をする必要がある場合など状況に応じてDBREが参画します。参考までに、過去にDBREメンバーが主導してリプレイスを実施した記事は以下のとおりです。
イベント時の監視対応
ZOZOTOWNでは1年を通じて様々なセールイベントを開催しており、大きな負荷が想定されるイベントではリアルタイムで監視しています。特に最大級のアクセスが発生する新春セールには最も力を入れており、当日も監視しますが、それに備えた負荷試験においてのDB負荷状況の確認も行っています。
DB周りでの自動化やパフォーマンス可視化
手動運用していた作業の自動化やパフォーマンスの可視化なども進めています。可視化については具体的には以下の記事で紹介しています。
技術共有会の実施
不定期ではありますが、全社的な技術力向上を目的としてDBに関わる技術共有会を開催しています。
DBRE活動を進める上で発生した課題
上記の活動を進める上でいくつかの課題が生じてきました。その状況を図示したのが次の画像です。
特に、特定のDBにおいて、パフォーマンスの悪化やトラブル・問い合わせが増加傾向にあり、改善したい課題でした。
しかし専任というわけではないので大きく時間を割くことが難しく、問題の原因となるクエリを見つけたとしても、そのサービスに詳しくないため改善のための手順が増えてしまい、改善を進めづらい状況でした。
カート決済SREとしてDBと関わることとの違い
冒頭でも述べた通り、私はカート決済SREとしても活動しています。いわゆるEmbedded SREのような立場であり、開発側を担当しているカート決済部と連携を取りながらDBの運用・保守をしています。
カート決済SREとして活動しているときは前述のような課題を感じず、振り返ってみると立ち位置の違いが大きいように感じました。
問題が起きているDBに対しても、同じような立場で動ける人を増やすことで効率良く改善が進むと考え、そのためのアクションを取ることにしました。
課題解決に向けた取り組み
開発チームへの提案
上記から、パフォーマンス問題が発生しているDBに関わる 開発チームのメンバーから数人、DBRE-WGの活動に参加してもらえないか 提案することを決めました。
SRE側から増やすことも考えましたが、SQLを自在に書ける人材が少なく、1から学習する必要があるため、あまり現実的ではないと判断しました。（組織変更などもあり、2024年11月現在は問題となったDBに大きく関わるDBREメンバーも存在）
また、開発側から参画してもらうことで初期学習コストが低い以外にも、下記のようなメリットが考えられました。
- 開発側の方がサービスの実装に詳しく、直近の問題にも対応できること
- 開発側でノウハウが蓄積されれば根本から解決できる可能性があること
- DBREと開発側との連携不足の解消
DBRE-WGの活動へと参加してもらう理由については、双方の連携を向上させるとともに、実際に発生している問題を題材にペアプロすることでスキルの伝達を速やかにできると考えたためです。
DBAとDBREについて
開発側に打診するにあたって、DBAの役割を担える人材を増やしたいという目的を話しています。ここでDBAとDBREの違いについて明確に整理するために、ChatGPTからの回答を引用します。
DBA（Database Administrator） ・役割: データベースの管理、設定、保守を行う。 ・主な業務: データベースのインストール、バックアップ、リカバリ、パフォーマンスのチューニング、セキュリティの管理など。 ・目的: データベースが正常に機能し続けることを保証する。 DBRE（Database Reliability Engineering） ・役割: データベースの信頼性、可用性、スケーラビリティを向上させることに焦点を当てる。 ・主な業務: システム全体のアーキテクチャを考慮し、障害時の復旧手法の設計や、自動化を推進することなど。 ・目的: 高可用性のシステムを実現し、ビジネスニーズに応じたパフォーマンスを維持する。
今回大きく問題となっていたのはパフォーマンス面であり、SRE的な部分までお願いする予定はないため、DBREではなくDBAを増やすことを目的としています。また、元々DBRE-WGはSRE部の中の1つの活動であり、「DBREに参加 ≒ SRE側への引き抜き」のような誤った形で捉えられないようにする意味でもこの辺りを明示しています。
開発チームとの話し合い
実際の話し合いには以下のような内容をまとめた資料を用いてプレゼンを実施しました。
- DBRE-WGとは
- 現状のDBREにおける課題感
- 開発側メンバーを誘いたい理由
- DBのパフォーマンス状況
- 悪化傾向にあり、エラー数も増加傾向にあることを示すグラフの提示
- 期待する人物像
- 懸念点
- メンバーjoin時の双方の工数が具体的にどのくらい増えるか
- DBRE業務をどこまでお願いできるか
結果として、DBに関して同じ課題感を抱えていると認識し合い、ぜひ協力したいという意見をいただきました。
メンバー参加後の活動
上記を経て2名の開発メンバーに参加してもらうことになりました。
参加に伴って問い合わせやテーブル設計のレビューなどをペアプロ形式で行うとともに、DBのパフォーマンス改善に向けた定例会を設けました。
定例会では、以下の例のように最近のDBの状況を確認し、ボトルネックを特定したうえで、それに対する改善策を検討・実施しました。
DBRE-WGに参加してもらった結果
問題となっていたDBのパフォーマンス改善
改善活動を行ったことでクエリタイムアウト起因のエラー数が減少し、それに伴うレスポンスタイムの改善を確認できました。
参加メンバーの自主的な動きによる効果
上記以外にも、参加してもらったメンバーによる効果が以下のようにありました。
- エラー発生時の初動対応の迅速化
- 背景：エラーが多数発生するとSlack通知が行われ、原因を調査するためのスレッドが立ち上がる
- 以前まで：調査が行われ、DBが関係していそうならばDBREに問い合わせが行われる
- メンバー参加後：参加メンバーがエラー発生時から積極的に見てくれるため、早期段階でDBの関係有無の周知とDB側調査が開始される
- 既存のアプリ改修による運用改善
- 背景：処理が失敗してしまうとDB全体の動きに影響を与えてしまうバッチアプリが存在する
- 以前まで：成否が重要なものの、既存アプリだとわかりづらく、運用でのカバーとなっていた
- メンバー参加後：アプリ自体の改修を実施し、万が一失敗した場合には、重要なアラートが通知されるSlackチャンネルに通知が届くようになった
振り返ってみると
書籍、データベースリライアビリティエンジニアリングにおいて、DBREの基本原則として以下の記述があります。
1.1.2 周囲を巻き込め
才能あるDBREは、サイトリライアビリティエンジニア(SRE)よりもはるかに希少な存在です。DBREを雇えたとしても、せいぜい1人か2人が関の山でしょう。これはつまり、多くのことを自分たちで、つまり限りあるリソースを最大限に活用して、自給自足で成し遂げる必要があるということです。
意図していたわけではありませんでしたが、開発チームも一緒になって改善を進めるというアプローチで、上記を実現できており、相乗効果を生んでいるように感じています。
展望
DBのパフォーマンス改善
前述のように改善効果があったものの、まだまだ改善すべき点は多くあります。そのため、引き続き改善に向けた活動を継続していきます。
体制について
理想としては次の画像のような体制が望ましいと考えています。
サービスの実装に精通したDBAがいることで、問題が発生しても迅速に対応できるほか、有識者によるDB設計やクエリのレビューが行われることで、サービスの品質向上が期待できると考えています。
また、弊社はマイクロサービス化を進めており、それぞれのチームでクラウド管理しているDBの数も増えています。各チームのノウハウや、Aurora MySQLのアップグレードのような定期的な作業なども、個別に調査するのではなく、情報を共有し横展開することで全体の効率化が進むと考えています。
このような体制を目指し、これからもDBの信頼性を高めるための活動を続けていきます。
最後に
ZOZOでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！
