この記事はヤプリ #1 Advent Calendar 2022 の16日目の投稿になります。
はじめまして。サーバーサイドエンジニアの柴田です。なにげにテックブログ初投稿となります。
今回は、ヤプリのデータ活用基盤であるYappli Data Hubのシステム運用を小規模のエンジニアチームで改善していった取り組みについてご紹介します。
背景
日々ヤプリの膨大な量のユーザー行動データや属性情報を取り扱うYappli Data Hubですが、システム運用保守の面で以下のような課題がありました。
① ナレッジの属人化
- Google CloudとAWSの複数サービスを組み合わせて実装されておりアーキテクチャが複雑
- 機能によって処理の流れ（実行間隔・データ処理のフロー等）が異なるため実装面でも仕様の把握が大変
- 障害発生時の対応にもナレッジが求められるため、対応メンバーに偏りが生じる
② エンジニアの運用コスト
- 大小様々なアラートが日常的に通知されてきており、アラート対応の定常コストが高い
- エラー箇所によっては顧客への影響があるものもあり、障害に繋がってしまうことがある
こういった課題を改善していこうと立ち上がったのが今回紹介する「Yappli Data Hub運用標準化チーム」です。
チームの発足
上記の課題を解決するため、2022年7月からサーバーサイドエンジニア4名+SRE 1名の計5名の有志により小規模のエンジニアチームが発足しました。メンバーはそれぞれ別のプロジェクトと兼任しているため、限られた時間で自主的に活動していく形となります。
課題は山積していましたが、改善を行うにもまずはシステムの把握が必要です。メンバーのうち1名は元々Yappli Data Hubの開発に携わっていたため、彼を中心にドキュメントを作成し解説してもらうことで基本的なシステムの全体像を掴むことができました。（この時のドキュメントは今でもバイブルのような扱いになっています）
また、週に1回もくもく会を実施し、メンバー間で助け合いながらコードリーディングを進めることで段々とシステムの理解を深めていきました。
技術的課題の把握
もくもく会の実施と平行して、日夜通知されてくるアラートの解消にも動き出しました。まずはアラートの内容の把握と整理のため、エラーメッセージ・原因・対応内容をスプレッドシートに書き出していく活動をはじめました。それらの内容を見ながら、コード修正やアラートの閾値調整等の対応方針をメンバーでわいわいと話しながら判断していきます。
この活動によって、頻発しているエラーの傾向が把握できただけでなく、これまで特定のメンバーに依存していたアラート対応の負担を複数人に分散できるようになってきました。今までは何も分からず恐怖していたアラート対応も、複数人いると心強く、段々と「エラーを1つ残らず駆逐してやる！」という自信とモチベーションが湧いてきます。
実際に手を動かしていく
システムの理解を深め、エラーの傾向もつかめてきたところで、いよいよシステムの改善に乗り出していきます。日々アラート対応をしている中で改善への意欲は非常に高まっていたので、有志による活動にも関わらず各メンバー前のめりに取り組んでいきました。
ごく一部を抜粋して、以下のような改善を行いました。
- 障害発生時の復旧方法の整備
- 開発環境の整備
- エラーの温床となっていた箇所の別の仕組みへの移行
- シェルスクリプトで実装されていた箇所をGoに書き換え、コードとログの可読性を向上
- 指数バックオフによるリトライ処理の追加（Goに書き換えた事により実装が簡単 👍 ）
アラートを整理していくなかでリトライ可能な偶発的エラーが多く発生していたという傾向は掴めていたので、リトライ処理を見越した形でGoへの移行まで行うことが出来ました。
これらの結果としてアラート通知は激減し、今ではすっかりSlackのアラート通知チャンネルが平和になりました 🎉
もっと改善していくために
このようにナレッジの属人化の解消とシステム品質の改善を行ってきたわけですが、開始から約半年という区切りであることと、今後さらに改善していくために、メンバー全員で振り返り(KPT)を行いました。
やはりメンバーからはドキュメントによるナレッジ共有やアラート対応コストの大幅削減（工数面だけでなく精神面も）といった点がKeepとして多く挙げられていました。その一方で、まだまだシステム構成自体の認知負荷が高くチーム外にナレッジ共有できていない点や、開発時の動作確認が困難である点などのProblemも挙げられており、今後に向けた改善点を再確認することができました。
まとめ
以上のように小規模のエンジニアチームでYappli Data Hubの技術的な課題に取り組んできました。このチームでは、メンバーの時間が限られている中でも上手くモチベーションを高めながら、課題を整理し、解決し、振り返るところまでを自走して行っていくことができました。
プロダクトの規模が大きくなってくると、どうしても複雑な部分で属人化が進んでしまい触りづらい領域が生まれてくるのはよくある話ですが、そういった領域にもエンジニアが主体的に切り込んでいけるのはプロダクトとしてもエンジニア組織としても健康的で良いことだなと感じています。
ということで、ヤプリでは引き続き一緒にプロダクトの課題を解決してくれる仲間を募集しています！ もしご興味をお持ち頂けましたら、是非カジュアル面談でお話しましょう。 open.talentio.com
