2023年7月のふりかえりです。 引き続き B 社(週3〜4日)にて Rails 製の EC サイトの開発業務と Engineering Manager / Scrum Master 業務に携わっています。 7月から新たに G 社(週2〜3日)を始めています。

B 社

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

マネジメント系

  • TechLead 業務
    • ひきつづき各エンジニアの成果物のレビューや、設計方針の相談・レビューなどに時間を使っています。

プレイヤー系

  • EC Store Front 面改善
    • いくつかの箇所で使用している、閲覧履歴を表示する UI が使用箇所でまちまちな実装になっていたのを新規実装した React + API な仕組みへ実装しなおしてリリースしました。
      • 高速化できていたり、UIの統一ができていたり、現代的な UX になっていたりという進歩もしています。
    • 以前よりマーケチームのメンバーとブレストベースで EC サイトの UI の表現力が乏しいだったり古いだったりという課題に対してどういうことをやっていきたいかというお話をしていました。このなかでやりたいことの方向性は見えてきていたのでそれを一段解像度を上げて要件に落とし込むための下準備を進めました。
      • 以前お話したことを思い返しつつ、ぼくの仮説等を踏まえつつでたたき台資料を作成して1時間ほどヒアリング・ブレストする時間を設けました。
      • 上記の会の結果を元に要件の記述を PRD フォーマットにまとめていっている最中です。
  • dev 環境を ECS ベースで実行できるようにするための検討や実装を開始しました。
    • ここ一年くらいで Production の VPC とは別に Development の VPC を運用するようになっており、この Dev VPC で動いている Aurora と Elasticache と接続する EC の実行環境を作ろうとしています。
      • 現行の開発環境(ステージングと呼ばれています)は Production と同じ VPC に配置している EC2 で運用しており、Dev VPC の Aurora と Elasticache を参照することはできない構成です(当然実装すればできますが、この方式にする予定はありません。)
      • Microservice 的に実装している Lambda 等の dev 環境はすでに Dev VPC で動いており、これら Microservice 群と EC の環境が開発時点で同じ DB を参照できていなくてちょっと困るようになってきた、というのが背景です。
    • EC のリポジトリのコードベースは非常に古い Ruby と Rails で実装されていること、大きく育った rails なので様々な依存関係が同梱されていること、あたりを背景として Docker image を構築すること自体が結構難儀すると想定していました。
      • まずは Ruby の Docker image を最新の状態に更新しました。
        • 元々1年以上前に一度 Docker image を作ったことがあり、そのコードベースにいくつかの修正、特に arm64 でビルドできるようにする対応をいれたというのがハイライトかなとおもいます。現状の docker buildx まわりはおおむね理解した感じがします。
      • 次に Rails の Docker image を作るのですが、これが相当に難儀しました。しばらく格闘した結果、実行できる状態には仕上がりましたがかなり課題を先送りしたような状態まで、という感じです。
        • まず、なぜか mysql2 gem が Rails initialize 中になんの問題もなさそうに見える SQL で ActiveRecord::InvalidStatement を吐くという問題にかなり悩まされました。
          • 例外が発生するクエリを直接様々な環境で実行しても例外にならず、Rails initialize のときだけ例外になるという状況で、結局原因が全く分からなかったため強制的に例外が発生しないクエリに書き換えるモンキーパッチを当てることでワークアラウンドとしました。
        • 次に、Rails が使用している gem で phantomjs があるのですが、arm64 版の phantomjs が存在していなかったためなんとかビルドしようと試行錯誤しましたが、結局断念しました。
          • この問題が解決できなかったため残念ながら Rails 環境は amd64 でのみ動かすことができるという結論になってしまいました。
            • ぼくは M2 Mac を使っており amd64 のビルドは大変遅いため大変残念です。(5倍くらい遅いのです)
        • アーキテクチャを変更しない前提なので Dockerfile 内で assets:precompile をする必要があるのですが、このタスクを実行するタイミングで Rails の initialize を通るため DB と Redis を参照し、結果として Docker build のタイミングでこれらへの接続ができる必要があることがわかりました。
          • ローカルで動かす際には docker compose なので問題ないですが、CD の際には現状 Github Actions で実行しているため DB と Redis への接続ができません。
          • 色々検討したのですが手軽な方法がなさそうなのでこちらはひとまずペンディングして precompile しない docker image として実装することでお茶を濁しています(これのせいでコンテナの実行速度がかなり遅くなっています)。
        • 他、様々細かい修正をいれています。
      • 次に CDK を実装しました。
        • Dev VPC で動作する ECS および関連リソースを一式生成するように実装しています。
        • 後続の Github Actions での CD でのビルドフローを整える意味で関連リソース群の生成順番をいい感じにできるようにスタックを分割したり整理したりもしました。
      • 上記をまとめて自動化するための CD を Github Actions で実装しました。
        • 上記までにつくった Dockerfile のビルドと ECR へのプッシュ、cdk deploy による一連のリソースの構築が矛盾なく実行できるように整えました。
  • 新認証基盤
    • MFA 導入を中心として検討が進んでいましたが、あらためて発端であった経済産業省から提示されている文書を読み直しつつ省庁に電話でお問い合わせしてみたところ、なんと、EC 事業者としては MFA 対応必須ではないということが判明しました。
    • という状況になったため、こちらの基盤整備の優先度は下がりまして、結果としてはペンディングとすることになりました。
  • Developer Productivity Engineering 関連
    • 7 月もメンバー離脱があったので、アカウント整理等をおこないました。
    • Aurora と Elasticache のスケールダウンを実施しました。
      • 想定よりも相当高速にインスタンスの入れ替えが完了してメンテナンス時間が短縮できてよかったです。
    • 運用中のバッチ基盤の ruby コードが吐き出すログが多すぎるという問題が顕在化してきたため原因を探っていましたが、こちらは僕が ECS 化に忙しくなったため他メンバーに引き継いでいます。
    • サイバーセキュリティ観点で露骨な攻撃アクセスが多くなっていたため、これをブロックするための WAF 設定をいれました。
      • WAF のログを Athena でクエリしたりしましたが、久しぶりすぎて完全に忘れていて時間がかかりました。
    • (他メンバーの対応)開発環境へのインターネット経由でのアクセスの際に長年 Basic 認証をかけていたのですが、これを ALB + Google OIDC に置き換えるという実装を入れはじめました。
      • しばらく運用してみて問題なさそうということになったら全部入れ替え予定です。
      • リスナールールの設定だけでよいという神機能ですね〜すばらしいです。

G 社

7 月下旬より参画しはじめました。 稼働としては週20時間程度を予定しています。

ロボットを販売している会社なのですが、その中でアフターサービスや生産管理、在庫管理など業務を健全に保つ・最適化するためのもろもろのお話に関わることになっています。

足元の作業としては BOM(部品表) を管理するシステムの導入周りで、使用予定の SaaS の仕様把握と現行業務の把握、BOM 管理システムにデータを投入するためのツールを Golang で書いたりし始めています。

おわり