こんにちは、検索チームのよこやまです。
今年のはじめに「各チームに SRE が参画するよ」と噂を聞き、「検索チームには誰が来るんだろうなー」と楽しみにしていたら「お前がなるんだよ」と言わて半年+αが経ちました。 検索チーム専属の SRE に任命されてから取り組んだことをご紹介させていただきます。
自分の背景
ビザスクの検索チームに所属しているバックエンドエンジニアであり、SRE やインフラに関する知識は殆どありませんでした。 一方で SRE に任命される前から検索チーム管理下である Cloud Run などのインフラリソースの調整を少しですが行っており、検索チーム内では多少の知見がありました。
そういった中で、検索チームのインフラを重点的に見つつ、検索チームに SRE のナレッジを広める ミッションを持った Embedded SRE としての役割をアサインされました。
取り組んだこと
input
全く知識のない状態からのスタートです。 そのため、まずは SRE や GCP、terraform の知識の input を行いました。加えて検索チームで勉強会を実施し、学んだことについてチームに共有しました。
- 読書
- 入門 監視
- システム運用アンチパターン
- SRE サイトリライアビリティエンジニアリング (現在進行系)
- ビザスクの terraform リポジトリの把握
- terraform や GCP のドキュメントを引きつつ、それぞれの役割や設計の把握
www.amazon.co.jp www.amazon.co.jp www.amazon.co.jp
チームで確認できるダッシュボードの整備
過去にチーム外のインフラ担当の方が検索チーム用のメトリクス確認ダッシュボードを作ってくださったこともあり、チームで定期的に関連リソースのメトリクスを確認してはいました。
一方で自分たちにインフラの知識がなく、「このメトリクスを見ていて何の意味があるんだろう」「このメトリクスがどうなったらマズいんだろう」といった、見方はわからないがとりあえず見ている状況でもありました。
そこで SRE にアサインされた自分が最初の取り組みは、チームが意味を理解して確認できるダッシュボードの整備です。 自分は元から検索チーム所属のため、自分たちの検索サービスにとって何が重要かは把握できており、また上記の input で「どのようなインフラ構造か」「何を監視すべきか」を少しずつ理解してきている立場です。
よって監視におけるプラクティスを反映しながらも、自分たち検索チームにとって意味を見いだせるように、ダッシュボード上のメトリクスの追加修正、加えて確認しなくてもよいメトリクスを削除しました。 さらにチームに対しても「なぜこれを見る必要があるのか」を説明し、チームで納得感を持って各メトリクスを確認できる状況にしました。
チームに存在するトイルの洗い出し
検索チームは他のチームと比べて人数が多くないため運用コストは直に響いてきます。そのため、トイル※を減らし開発に費やせる時間を守るのは重要です。
※ トイルとは？
「トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。」
まずは自分でトイルだと思われる作業をリストアップしつつ、チームメンバーに「トイルかどうかはともかく面倒だと思っている作業」のピックアップを定期的に依頼しています。 その上でリストアップされた作業に対し、自分たちがどれぐらい時間を使っているかを定量的に計算し、順次対応を進めています。
ポストモーテムの企画
これまで検索チーム管理下の機能に障害が起こったとき、障害の対応は当然行いつつも振り返る文化はありませんでした。 そこでまずは軽めの障害を利用してポストモーテムを実施してみました。
チームメンバーにポストモーテムを実施する理由やポストモーテムで大事なことを伝えた上で、自分が大枠を作り、チームメンバーと miro を使いつつ「良かったこと」「悪かったこと」「幸運だったこと」を中心に振り返りました。 その上で悪かったことを改善するため、そして幸運だったことを幸運で終わらせないよう、ネクストアクションを決め実施しました。
中長期的に増加する負荷に耐えうるインデキシング基盤の考案
ビザスクのユーザーや内部で抱えるコンテンツが徐々に増えてきたこともあり、RDB から Elasticsearch にデータを変換して入れる処理(インデキシング処理)の負荷が徐々に高まってきている状況でした。 しばらくは関連リソースのスケールアップ or スケールアウトで十分耐えることができそうでしたが、中長期的に見るとそれでも限界があるため、インデキシング処理を行う基盤のアーキテクチャの見直しを実施しました。
現状のインデキシング処理は GCP の Cloud Run と Cloud Tasks を利用してインデキシングを行っています。 そこで、より ETL に特化した Pub/Sub と Dataflow を試行し、将来的な負荷増加に耐えるアーキテクチャと、それらを利用した開発フローを考案しました。
これから
ビザスクの検索周りはまだまだやりたいことが山積みです。 これからも検索のバックエンドエンジニアとして検索に取り組むのはもちろんのこと、SRE としても検索の改善に取り組んでまいります。
