ID:75421さん

DMM グループの月額課金機能をプラットフォームとしてDMMグループへ提供するシステムの開発、運用を担当するチームに在籍し、新機能の開発の他に手作業運用業務の改善、DBバージョンアップグレードなどを担当。 ## Aurora MySQL の無停止バージョンアップグレード アクティブユーザー100万人超え、1000rps 以上 のバックエンドアプリのDBのバージョンアップグレードを無停止で行う必要があり。 リードエンジニアとして、無停止でのDBバージョンアップグレード方法の検討、それに伴うリスク調査、リカバリー手順の確立、QA、ランニングコスト見直し、各事業部とのスケジュール調整などプロジェクトの主担当業務を担当。 実作業は rps の低い夜間に作業を行うことで、データ不整合も発生せず、無事無停止でDBバージョンアップグレードを完了させた。 また、実績やテスト中に発生したAurora の問題をチーム外へ共有することで、他チームのアップグレード作業にも貢献を行なった。 さらにインスタンスのオートスケーリングを行う設定を追加し、ランニングコストの削減を行なっている。またDBに関するアラートが全くなかったが、メモリ使用率やcpu使用率のメトリクスを監視する設定を追加し、インスタンスに問題がある場合はアラートで気付ける仕組みを構築した。 ## プラットフォーム機能として、サービス受け入れを難易度改善 月額課金サービスとしてのプラットフォームを提供しているが、DMMグループの全ての月額サービスを取り込めているわけではない。 その理由は、最初の月額課金プラットフォームを利用するサービスに依存する形で設計されてしまっているからである。 現行取り込んでしまっているサービス依存（ビジネスロジック）を取り除くことは厳しいが、プラットフォームとして他サービスを受け入れるためにもシンプルな月額課金機能のみを提供する形で、サービスのビジネスロジックを極力削ぎ落とした形で再設計する必要があった。 こちらは現在進行中のプロジェクトで設計中の段階であり、2025年に完了する見込みである。 ## 手作業運用業務の改善 月額課金失敗ユーザーの復旧対応が自動化されておらず、毎日30分ほどの手作業でデータ修正を行なっていた。またユーザー数の増幅に伴い、バッチで行なっている月額課金の処理の仕組みが過去に調整した事業部からの要望を守ることが難しくなっていた。 要件を再整理し、お互いの着地点を決めた。また、pub/sub モデルを採用し処理を分散させることでユーザー増幅に強い設計へと再構築した。