ID:67466さん

### 前提 当時の会員基盤はオンプレでJava + Springのアプリケーションで動いていて、データストアとしてMySQL + Couchbase + Cassandraを組み合わせたシステムとなっていました。 また、会員基盤の機能として会員の個人情報やステータスだけではなく、パスワードなどの認証情報やセッション管理などもおこなっていました。 また、プロジェクト参画当時はJavaに強いエンジニアが一人もいない状況となっており、担当チームではメンテナンスが出来ない状況となっていました。 この結果、3年以上ライブラリの更新やランタイムの更新もせず機能の追加などすら出来ない状況になっていました。 ### 役割 バックエンドチームのチームリーダー兼テックリードとしてチームの開発面の中心として業務に参加しました。 立ち上げ当初は3名のチームでしたが、採用活動なども対応し結果として最大20名のチームを運営していました。 ### 対応 大きくフェーズを4つに分けて対応しました。 1. 明確に見えている大きな問題の解決 2. 会員機能と認証機能の分離 3. 会員機能のクラウド(AWS)への移行 4. Golangでのリプレイス この中でも1、2についてはプロジェクトリーダー兼エンジニアとして対応していました。 また、3、4の対応については並行して別のプロジェクトを進めることになったので、チームメンバーにプロジェクトリーダーとしての権限を移譲し、私自身はテックリードとしてコア部分のレビューや技術支援を中心に対応していました。 ### 工夫した点 会員基盤システムでは3000万以上の会員を抱えていて2000rps以上のアクセスがあるシステムでした。 そのためシステムが停止することがあると大きな機会損失に繋がります。 そのため自動テストに力を入れて対応しました。 具体的にはKarateを利用したAPIのE2Eテストを導入しリグレッションテストの効率化を行いました。 また、単体テストやAPIの機能網羅のための結合テストも自動化しています。 これらのテストの責務はTestSizeをもとに決定しました。 また、今回対象としているシステムは80本以上のAPIがあったためGolangへのリプレイスはそれなりのコード開発量となっていました。 ここでの開発のスピードをFindyTeams+を利用して可視化し、プルリクエストのサイズの最適化やレビューの効率化をおこなっています。 具体的には単体テストを実施しつつDDDのレイヤにごとに実装を進めることでプルリクエストのサイズを減らしました。 結果としてFindyTeam+を利用している会社、チームの中でも上位に入る開発スピードを実現することができました。

### 前提 参画した企業ではCtoCとBtoCそれぞれのECサイトを運営していました。 それぞれのECサイトでは出品のシステムが異なっており、商品の露出を増やすためにCtoCサイトの方に企業が出品をしたい場合は両方のサイトで商品の出品が必要な状況でした。 これを改善するためにBtoCサイトで商品を登録するためのシステムから連携された商品情報をCtoCサイトでも登録できるようにする対応を実施しました。 ### 役割 開発チームのリーダーとしてチームに参加しました。 この時、参画した企業側のエンジニアではJavaでの開発経験があるエンジニアがいなかったためアーキテクチャの設計やCICD、アプリケーションの運用ルールやモニタリングの仕組みの構築まで担当しています。 ### 対応 出品機能自体がもともと複雑な条件を持っていたため業務ロジックが肥大化しやすい状況になっていました。 今後の保守を加味してDDDを導入し、業務ロジックをなるべくドメインオブジェクトに寄せることによってテストの書きやすいコードになるように指導しつつ開発を進めました。 また、運用面では当初オンプレのVM上に構築する前提でしたが顧客の企業全体でPaaS・CaaSの導入が進んでたこともありPaaSを中心にした運用の仕組みを提案して導入しました。 ### 工夫した点 対象となるBtoCでの出品システムでは1万件を超える出品を一度に実施できるものとなっていました。 しかし、CtCでの出品基盤では同時に捌ける件数が少なかったためそのまま流してしまうとサービス全体が停止するリスクがありました。 これらを回避するため、顧客環境で前例があったPulsarを利用したPub・Subを間に挟むことでCtoCシステムへのスループットを調整しました。 運用監視については顧客ではログベースの監視のみを想定していました。 しかし、性能限界などを監視するためにログベースではなくメトリクスベースでの監視の仕組みも導入しました。 具体的にはSpringBootを利用していたのでMicroMeterとPrometheusを利用しデータを取得しGrafanaを利用して可視化・監視を行いました。 これによってシステムに対しての大量アクセスや出品の滞留状況などの可視化を行い運用の改善に繋げることができました。 開発フローについては自動化を極力取り入れた仕組みを導入しました。 具体的には顧客の基盤として存在していたScrewDriver.CDを利用し、単体テストや機能テストを自動化しました。 また、DBの管理についてもFlywayやSchemaspyを利用し、手動での運用をなるべく減らす仕組みを構築しました。