Google Cloud Next Tokyo ’23 で登壇 - 効果的な Serverless プロダクトの利用事例について
ttyfkyOverview
先日行われた Google Cloud Next Tokyo ’23 の Lightning Talk で登壇したのでご報告です。
今回の LT は Serverless 基盤を用いたマルチサービスのドメイン統合 という内容でお話をしました。
登壇の内容
登壇資料のオーナーは Google になっているので資料は今回は公開しませんが、 内容としては以下の内容で Serverless を活用したサービス運用とドメイン統合の話をしました。
この話は ヘッドレス Shopify を利用したにこスマ から更に発展し、買取のサービスとにこスマを統合した話を含みます。
にこスマとにこスマ買取は元々は別のサービスとして立ち上がりました。 サービス立ち上げ当時、にこスマ買取は Belong 買取というサービス名で、にこスマとは完全に独立していました。
2020 年時点のサービスのアーキテクチャ
これが、にこスマの Shopify ヘッドレス化と、にこスマ買取のリアーキテクチャを経て、以下のアーキテクチャになりました。
2022 年時点のサービスのアーキテクチャ
簡単に表現すると、元々 Shopify を用いたノーコードの EC サイトであった、にこスマをヘッドレス化したうえでフロントエンドを Cloud Run で運用し、 Firebase の Hosting や Functions を利用してサービスをホストしていた Belong 買取は Cloud Run に移行し API も拡張しました。
この時、Load Balancer を共有し、Path Based Routing を利用することで異なる Backend Service でホストしているにこスマと Belong 買取のフロントエンドを同一ドメイン以下に統合し、Belong 買取はにこスマ買取とリブランディングする形になっています。
このリアーキテクチャとドメイン統合により嬉しい部分が多くあるのですが、一方でヘッドレス化や API サーバーの増加で運用負荷は増えるというダウンサイドもあります。
元々フルマネージド状態でホストされていた、にこスマのフロントエンドの自分たちでの運用が必要になったり、API の運用を FaaS のレベルから PaaS のレベルにしたので考慮するべきことが多くなりました。
しかし、Cloud Run を主体とした Serverless プロダクトを活用することで、可用性やスケーラビリティは Google が提供する仕組みを活用して担保し、
ソフトウェアエンジニアはアプリケーションの開発に集中しやすい状態を維持できました。
上記アーキテクチャ図で利用されている Serverless プロダクトの活用例を挙げると、以下のようなものがあります。
- Load Balancing と簡単に紐付けられる Cloud CDN で静的コンテンツの素早い返答
- Path Based Routing による複数の Backend Service の共存
- Min Instance と CPU Boost によるスロースタート対策
- Serverless VPC Access と Cloud NAT を用いた IP の固定化
まとめ
本記事では Google Cloud Next Tokyo ’23 で登壇した内容について紹介しました。
Serverless プロダクトを用いるとスモールスタートしやすい、規模の割に運用負荷を抑えられる、少ない設定で高機能が利用できるというメリットがあります。
Belong では限られた開発者数でも多くの問題解決を可能にするために、Serverless プロダクトを積極的に活用しています。
今回紹介したアーキテクチャは 2022 年時点のもので、今年もにこスマ関連のプロダクトのアーキテクチャはさらに進化していますし、 今後もサービス間のシナジーを生むための開発を続けていきます。
にこスマ関連で発展的な Serverless アーキテクチャを構築したい方はもちろん、 ソフトウェアエンジニアとしてプログラミングを行うだけでなくクラウドのプロダクトを活用してゼロイチでサービスを立ち上げたい方、 自社サービスでプロダクト開発のフルサイクルに携わりたい方など、Belong では様々なエンジニアを募集しています。
ご興味がある方は是非 Belong に応募してください。カジュアル面談もお待ちしています。