Amazon Web Services ブログ

Wraptas とペライチにおける AWS App Runner の採用

AWS のコンテナサービスは様々なお客様のユースケースをサポートすべく、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、AWS Fargate に代表される多様なサービスを提供しています。2021年の5月に、さらに多くのお客様のニーズに応えるべく、AWS 上でコンテナ化された Web アプリケーションのビルドおよび実行するための最も簡単な方法として AWS App Runner がリリースされました。

本投稿では、株式会社ペライチ様がこの App Runner をどのような経緯で採用されたか、どういった課題の解決になったのか、採用のメリット等の実例を紹介します。

株式会社ペライチの CTO である 瀬川 伸一 氏によるゲスト投稿

はじめに

株式会社ペライチでCTOの瀬川です。株式会社ペライチでは、ホームページ作成サービスの「ペライチ」と、Notion を Webサイトにすることができる「Wraptas」という2つのサービスを開発・運営しています。

ペライチとWraptasでは共に AWS App Runner を利用しています。最初に Wraptas で App Runner を使い始め、徐々にペライチでも利用するようになっていきました。今回はペライチと Wraptas での App Runner の採用事例と導入経緯についてご紹介させていただきたいと思います。

Wraptas について

Wraptas は、Notion で書いたページを、そのまま Web サイトにすることができるサービスです。コンテンツの管理を Notion で行うことで簡単にページの管理・更新ができ、CSSや独自ドメインなどのカスタマイズも行うことができます。

@nabettu さんの個人開発プロダクトとして始まり、 2021年の10月に株式会社ペライチが買収し、開発・運営をしています。

Vercel から AWS への移行

ペライチにジョインした当時、Wraptas は Next.js で、管理画面は Firebase、ユーザーが作成したWebサイトのホスティングに Vercel を利用していました。

Vercelの機能で Web サイトに独自ドメインを設定していましたが、当時の Vercel は1チームに設定できる独自ドメイン数に制限があったため、Wraptas は独自ドメインを利用するユーザーが増えると Vercel のチームを追加していく運用でした。
Wraptas のサービスをスケールしていくにあたり、この構成がボトルネックになっていました。

ペライチでもユーザーに独自ドメインと常時SSLを提供する機能を持っており、AWS上に独自に構築していました。Wraptas にペライチと同じ構成を流用するために、インフラをAWSへ移行することになったのでした。

App Runner の採用

ペライチの独自ドメインは、アプリケーションサーバーの手前にTLSを終端して複数ドメインのSSL証明書管理を行うフォワードプロキシを置いて常時SSLを実現する構成になっています。Next.js のアプリケーションのホスティングには AWS Amplify、Amazon API Gateway + AWS Lambda、Application Load Balancer + Lambda、ECS などいくつかの選択肢がありましたが、最終的には以下の理由で App Runner が採用されました。

  • ユーザーが作成したコンテンツ内容によっては Notion からのデータの取得に時間がかかり、レスポンスに時間がかかることがある。
    • => App Runner のレスポンスタイムアウトは120秒あり、十分だった。
  • ユーザーが作成したWebページのコンテンツが多いと、レスポンスボディが非常に大きくなる場合がある。
    • => App Runner にはレスポンスボディサイズの制限がない。
  • フロントエンドエンジニアがインフラエンジニアの手を借りることなくサーバー構築できるようにしたかった。
    • => App Runner は操作が非常に簡単で、Vercel と同じようにGitHubと連携してビルド、デプロイを自動で行ってくれます。Docker を利用することもでき、当時は利用したい node.js バージョンが対応できてなかったことから Wraptas では Docker を採用しました。

AWS での Wraptas の構成

AWS に移行後の Wraptas は以下のような構成になっています。App Runner の手前に独自ドメインのSSL証明書を管理するリバースプロキシが置かれています。

App Runner では任意のカスタムドメインを設定することができますが、5つまでしか設定できないため、Wraptas のように不特定多数のホストへのリクエストを受け付けることができません。

Wraptasではエッジのリバースプロキシがカスタムヘッダーで元のリクエストのホスト名を伝え、それに対応したコンテンツを返す仕組みにしています。

ペライチへの横展開

ペライチは2022年12月に新サービスのペライチなんでもマーケットを開始しました。

ペライチではフロントエンドフレームワークにVue.jsを利用しており、Wraptas で Next.js を運用した実績を基に、新サービスではフロントエンドフレームワークに Nuxt.js、ホスティングに App Runner を採用しました。

ペライチはサービスのローンチから8年が経っており、サービスの拡大に伴いモノリスなアプリケーションをマイクロサービスに移行するモダナイゼーションが進行しています。さらに、なんでもマーケットの開発最中だった2022年の夏頃から断続的にDDoS攻撃が増加するなど、それらの対応によりインフラエンジニアのリソースが逼迫している状態でした。

App Runner を採用することでフロントエンドエンジニアがサーバーの環境構築を行うことができ、インフラエンジニアの負担を軽減しつつ、無事に計画通りの期日にサービスをリリースすることができました。

おわりに

App Runner は ECS Fargate など他のAWSサービスに比べて細かな設定はできませんが、その分環境構築が簡単でハマる部分が少ないサービスです。フロントエンドエンジニアでもオートスケールを備えたWebアプリケーションサーバーを構築することができ、Next.js / Nuxt.js などを使ったBFF(Backend For Frontend)としての使い勝手が良いと思います。

ペライチにおいては App Runner の魅力はサーバー構築コストの低さにありました。ECS Fargate に比べるとインスタンスコストは割高ですが、ロードバランサーのコストも含まれていることや、環境構築・運用に必要なエンジニアのコストを考慮するとトータルでは非常にコストパフォーマンスに優れていると思います。

株式会社ペライチはこの記事を書いている2023年3月現在、十数のマイクロサービスがあり、それに対して3名のインフラエンジニアで運用しています。少人数で効率よくインフラを運用していくために、今後のサービス拡張におけるマイクロサービス基盤の一部として App Runner を活用していく予定です。