hacomono TECH BLOG

フィットネスクラブ・スクールなど施設・店舗のための会員管理・予約・決済システム「hacomono」 開発チームの技術ブログ

今年振り返って失敗したこと

こちらの記事はhacomono Advent Calendar 2023の15日目の記事です

大阪でエンタープライズ領域の開発を担当している和田です。

ライドケミートレカの PHASE: 00 がどこにも定価で売ってないんですが、どこかリアル店舗だったら売ってるんでしょうか。

情報求む。

今年を振り返る

タイトルの通り、失敗したなーということを述べていきたいと思います。

ただ、失敗したと思いつつも別のいい案があるわけでないものもございますのでご了承ください。

ちなみに自分の目下の業務は以下のようなことを行っておりますので、それを前提で眺めていただければと思います。

  • 公開API に関する開発、およびそれに付随する業務
  • 顧客毎に作っているアドオンを動かす環境(インフラや開発基盤)の管理
  • SSO などエンプラっぽい機能開発

1. Terraform の Workspace を顧客毎に切って管理したこと

現在はA社のアドオン環境(例えば Fargate + RDS など)、B社のアドオン環境、C社の、、、といった環境を作る際に、Terraform の Workspace を切り替えながら作ってます。

これをやっていると、途中で構成変更、とまでは行かなくとも命名ルールを見直すなどしただけでも、作成済み環境においてリソース再作成が必要となってしまいダウンタイムとれない環境ではコードとの乖離がでるようになってしまいました。

変更かける際はそのあたり気にしながらやっていけばいい話ではあるんですが、後の祭りです。

今は諸問題を回避するため、よくないのですが AWS の Terraform のモジュールをローカルに落としてきて改変して使ってます。

どのみち環境が増えていったときに辛くなるので、Workspace は使い所を見極めて利用していきたいと感じました。

2. バッチを ECS の Run Task で実現したこと

Capacity is unavailable at this time. Please try again later or in a different availability zone.

ECS(Fargate) で Run Task したときにこんなエラーがでて起動してくれないことがありました。

0時頃に起動させていたバッチなんですが、ある日を境に連日このエラーが出るようになりました。

どうも AWS 側のコンピューティングリソースがシンプルに不足しているらしく(?)、0時15分に起動するようにしたら一旦は解消してます。

解消は難しそうで、対応策としては Step Functions など用いて、エラーハンドリングするしかないようです。うーん。

これを大きく見直そうとすると、1 で述べた問題にぶつかるという悩ましい問題です。

3. Rails のコードから機械的に API ドキュメントを起こしてること

API を公開するとなれば API ドキュメントを起こさないといけないわけですが、スキーマ駆動で開発しておらず、更に Ruby となると中々に手間がかかる作業になります。

そこでドキュメント生成スクリプトを組んで出力することにしました。

path や schema の情報は、Rails の Rails.application.routesActiveRecord、および独自のモデルクラスから取れるので、まあまあ機械的に出力することができています。

また、コントローラーには YARD コメントでリクエストのモデル、レスポンスのモデルを手書きしてます。

イメージとしては以下のようなものを記載しています。

# @description メンバーを登録します
# @request Member::MemberEntity
# @response [{ "name": "member", "type": "Member::MemberViewModel", "description": ... }]
class XxxxxController ...

これをスクリプトで拾って OpenAPI 形式のドキュメントに、そこから redoc で html 化という流れになってます。

と、いう感じで作ってるんですが、微妙に実際のAPI仕様と差が出てしまうところがあったりするんですよね、、、(ご迷惑おかけしている方々。申し訳ございません。)

その微妙な問題を吸収するためのスクリプト改修を、今もまさにやってます。

具体的な問題は今回の本質ではないので語りませんが、時間がかかってもスキーマ定義を書いていくのが実は近道なんじゃないかと思い始めてます。

とはいっても開発全体をスキーマ駆動でやっていこうと運用変えるのはパワーのいる話ですし、そうしなければスキーマ定義をリバースでいちいちメンテしないといけなくなるので、どうするのが正解なのか、未だに悩みながらやってます。

まとめ

今年は自分があまり経験したことのない領域の開発をやらせていただくことが多く、一方で、ここには書いてない細かい失敗もあったりと、学びも多い1年でした。

この記事を読んで、私ならちょちょいのちょいと思った方は、読者になるボタンの登録、採用エントリー、よろしくお願いします!


株式会社hacomonoでは一緒に働く仲間を募集しています!
採用情報や採用ウィッシュリストも是非ご覧ください!