トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

トレタAdventCalendar2023:エンジニアkentaroが語るインフラ移行の舞台裏

こちらはトレタAdventCalendar2023 24日目の記事です。
タイトルはAIタイトルアシストにつけてもらいました。

qiita.com

はじめに

こんにちは、トレタでソフトウェアエンジニアをしているkentaroです。
トレタO/Xという飲食店向けモバイルオーダーの開発を担当しています。
担当しているゲートウェイサーバのインフラを GCP に移行したのでその話を紹介したいと思います。

O/Xのシステム構成図。赤枠がゲートウェイサーバー。ちなみに筆者はユーザー向けアプリ・スタッフ向けアプリの開発も担当している。

なぜインフラを移行するのか

移行前は AWS の EKS 環境でした。当時は環境を追加したい等インフラに手を加える際にはインフラエンジニアへ作業を依頼して実施してもらう形をとっていました。
このスタイルのメリットはアプリケーション担当のエンジニア(自分)の工数があまりかからないことと、インフラを得意とするエンジニアによる作業なので安心感があったことです。
デメリットとしてはインフラエンジニアが複数のプロジェクトを横断してサポートしていたので日程調整のコストが発生していたことと、担当エンジニアのインフラの解像度が低くなってしまいがちなことでした。

ちょうどO/Xでは各サービスの担当者がオーナーシップを持って開発を推し進めていくことを重要視していく機運が高まっていた(し、自分もその方針のほうが性に合っていると考えていた)ので、当時のスタイルのデメリットのほうが大きくなってきていました。
そこで、多少不慣れであってもサービスの開発者自身がインフラも含めて一気通貫で開発ができるようにしていく意思決定を行った次第です。

採用したのはGoogle Cloud の Cloud Run で、オペレーションの負担をなるべく小さくするという意図があります。

アーキテクチャ

ゲートウェイサーバーのインフラアーキテクチャ図

アキーテクチャは上図のとおりです。
Cloud Run の前段に Cloud Load Balancing を配置しています。今後 Cloud Armor などを入れやすくするのが目的です。

デプロイ周り

Cloud Build で Docker build して Artifact Registry に push し、 Cloud Run にデプロイしています。

Infrastructure as Code (IaC)

Terraform を利用し、 GitHub でバージョン管理しています。
PRでのレビューを実施できるのが嬉しいですし、手動でのうっかりミスが発生しないという点も嬉しいです。
Apply は Terraform Cloud を利用しています。特定のブランチへ向けたPRがマージされたら自動的に Plan が、設定によっては Apply まで行われるので便利です。

担当者のスキルセット

普段は TypeScript でバックエンドもフロントエンドも開発しています。
また、 Flutter を触ることもあります。
O/X にジョインするまでは予約台帳アプリのiOS開発を担当していました。

今は得意な言語も好きな言語も TypeScript です。

というわけでインフラ周りを業務でガッツリ触るのは今回が初でした。

移行を終えた感想はどうなのよ?

よかったこと

インフラに変更を加えたいときに、チームレベルでさっと対応できるのがスピード感があっていいなと感じています。 オーナーシップの醸成にも寄与しているかなと。

大変だったこと

インフラ初心者なので、何かするたびにつまづくのが大変でした。
具体的には Terraform Cloud で Plan や Apply コケまくる問題が発生したことです。
トライ & エラーを繰り返したり、インフラの知見を持つメンバーに助けてもらったりしながらなんとか移行を終えました。

おわりに

経験のない分野のことでもどんどん挑戦していきたい方、あるいは自分の得意分野でバリューを発揮したい方。飲食店の未来をアップデートする事業に興味があれば気軽に話を聞きにきていただければと思います。何卒!

corp.toreta.in

© Toreta, Inc.

Powered by Hatena Blog