2022年12月のふりかえりです。 引き続き B 社(週4日)にて Rails 製の EC サイトの開発業務と Engineering Manager / Scrum Master 業務に携わっています。 M 社にて Engineering Manager 業務に携わっていましたが今月で終了しました。

B 社

12 月はマネジメント 1 割、プレイヤー 9 割といった割合で対応していました。

マネジメント系

  • エンジニア育成
    • 先月から引き続きでデータベース関連で、理論から学ぶ データベース実践入門 を読み進めており、12章まで進んでいます。
  • TechLead 業務
    • ひきつづき各エンジニアの成果物のレビューや、設計方針の相談・レビューなどに時間を使っています。

プレイヤー系

  • 検索関連
    • 月前半はファーストリリース後の積み残しの対応を行っていました。
    • 月後半は来年春のモノ日に向けた負荷対策でやろうとしている計画と組み合わせて、検索側のインデックスに追加情報を入れ込んでいく対応を進めていました。
      • 検索エンジン側の修正は他メンバーの対応になります。
    • API サーバー側でも同様の対応を進めました。これまで Lambda を非 VPC 環境で動作させていましたが、Aurora と ElastiCache にアクセスする必要が出てきたため CDK の修正を色々入れました。
      • Aurora の reader / writer endpoint 両方にアクセスするための実装や設定群を整理して実装しました。
        • AWS Lambda + ActiveRecord で複数データベースに接続する でまとめた話になります。
        • 既存 Rails 側システムの Production 環境は古い Rails を使用し続けないといけない状況であり、writer endpoint のみを R/W しているため、これがモノ日の負荷増に耐えられなくなってきていました。
          • 検索から導入した Lambda による API サーバーは、この課題を克服する手段としても重要な位置づけになっています。
      • ElastiCache(Redis) へのアクセスが想定していたレイテンシーにならず、様々調査した結果 memory 割り当て量が少なすぎたという問題があったためこれを修正しました。
        • いいタイミングだったので Lambda Power Tuning を導入し、他 Lambda の計測を行ったりもしました。
  • バッチ基盤関連
    • ついに、いくつかのバッチがこちらの基盤ベースで Production 動作しはじめています。
    • 順次対応を進めています〜！(他メンバーの対応です)
  • 来年春のモノ日向けパフォーマンス改善関連
    • 上記検索でも記載しましたが、来年春のモノ日向けパフォーマンス改善の計画を立てて実装を始めています。
    • 基本的な方向性としては、エンドユーザーがアクセスしてくる EC サイト上の UI パーツを組み立てる部分を、上記した API サーバー + React マイクロフロントエンド(検索と同じバンドルです)に実装し直していくという方向性にしています。
      • 既存システムの UI パーツの組み立てはパーツによりますが以下のような課題があります。これらを一挙に解決するため特にインパクトの大きい 2 つの UI パーツを修正することを目標としています。
        • MySQL へ大きいクエリを投げるため MySQL の CPU を大量に使う(MySQL で商品ランキング結果を生成しておりこれが非常に遅い)
        • Rails サーバー上で様々な計算を行うため CPU を大量に使う(MySQL で計算すべきところをアプリケーションで計算していたり、ActiveRecord インスタンスを生成しすぎていたり、経年によりデータモデルとUIが整合していないところを穴埋めするために計算していたり…)
        • Redis キャッシュに乗っていない時のレイテンシーが非常に厳しい状態
        • フロントエンドはサーバーサイドレンダリング、パーツによっては追加でクライアントでもレンダリングする(完全に技術負債なのですが、物量がありなかなか改善が進んでいかないポイントです)
      • 修正後は以下のような状態になることを目論んでいます。
        • 検索エンジン側の API を流用し、商品ランキングを生成するための負荷を MySQL に向けず Elasticsearch に向ける(ES であれば安定したレイテンシーを実現しやすい)
        • 商品ランキングに付加する情報を MySQL から取得する必要があるが、これを reader endpoint に向けることで writer の負荷を下げる、必要に応じて Redis キャッシュも入れる
          • 今年の春のモノ日は TV 露出がありまして、そのタイミングで Aurora Writer の負荷的にはほぼ CPU を使い切ってしまっていまして、これを解決できる想定でおります。
        • API Gateway での短時間キャッシュを入れて Lambda, MySQL, Redis へのアクセス発生頻度自体を低く抑える
        • フロントエンドは非同期で UI を組み立てるように変更することで、エンドユーザー観点でロード完了までの体感時間を向上させる
  • Developer Productivity Engineering 関連
    • 引き続き AWS Aurora MySQL1 の EOL 対応を進めています(他メンバーの対応)

M 社

No Code 系のツールを活用したシステムを運用していたところを AWS へ移行するプロジェクトが進んでいました。 このプロジェクトがある前提での参画でしたが、12 月に入ってから方針転換することになりプロジェクトをやめて引き続き No Code 系ツールでしばらく事業を継続することになったため僕の役割は必要なくなり撤退となりました。 (事業面を鑑みると No Code ツールで開発を続けるフェーズですね〜という提言をしていたのですが、それが刺さった感じでした)

おわり