こちらの記事はツクリンクアドベントカレンダー2024の記念すべき初日の記事です🎉
是非他の記事も気になるものがあれば見てみてください！
ツクリンクでSREエンジニアをやってるida.です。
ツクリンクは、現在Railsをメインとしてシステムが構築されてますが、それをフロントエンドを独立して構築するプロジェクトが立ち上がりました。この変更に伴い、インフラ構成をどうするべきか技術選定をSREチームで行いました。この記事では、その検討過程やPoC（概念実証）、最終的な選択について書こうと思います。
技術選定の背景と目的
ツクリンクはこれまで、フロントエンドもRailsに大きく依存した構成で構築していました。ただ、この構成では、開発効率や運用の柔軟性に課題がありました。そこで、開発効率を高め、運用負荷を軽減することを目的にフロントエンドのリアーキテクトプロジェクトが発足されました。
SREチームもこのプロジェクト内でインフラ開発を行うことになり、アーキテクチャの選定から対応しました。プロジェクトの目的や前提条件はざっくり以下のような感じです。
プロジェクトの目的:
- 開発効率の向上: フロントエンドとバックエンドを独立させ、開発チームの作業を並行化する。
- 運用負荷の軽減: システム全体への影響範囲を限定し、柔軟な運用を可能にする。
- 技術スタックの追加：フロントエンドを独立させることでフロントエンド専任のエンジニアの採用もしやすくなる。
前提条件:
- 環境はAWS上に構築されている。
- 既存サーバーはAmazon ECS(以下、ECS)上で稼働している。
- 段階的に移行するため、特定パスのみを新フロントサーバーへルーティングする必要がある。
- SREチームが主導で、以下の要件をもとにインフラ構成案を検討する。
- フレームワークの柱（運用性、コスト、セキュリティ、パフォーマンス、信頼性、持続可能性）を考慮して選定する。
検討した構成案とそのPoC（概念実証）
今回は以下3案を候補として、検証を進めました。
1. AWS Amplify案
2. ECS案
3. Vercel案
1. AWS Amplify案
AWS Amplifyとは、フロントエンドとモバイルアプリ開発を簡素化するためのフルマネージドサービスです。ホスティングの他にバックエンドの構築・管理やCI/CDを迅速に構築できます。
Amplifyを利用することで、サーバーレスアーキテクチャを迅速に構築し、開発から運用まで一貫したサポートが可能です。
＜構成図＞
構築自体も簡単で、開発生産性の向上やCI/CDが簡単でメリットも多かったのです。
ただ、特定パスだけルーティングさせる際にEC2プロキシが必要で信頼性やパフォーマンスの懸念がありました。
こちらはAWSのサポートにも確認しましたが、既存サービスが存在して部分的な移行や刷新を行う場合は少し相性の悪さを感じました。
2. ECS案
既存サービスはECSで構築されているので、流用する案です。近年のAWSのサーバ構成だとメジャーな構成かと思います。
既存で構築している環境の流用で構築できるため、構築は非常にスムーズでした。
また、この構成だとAPIサーバとの通信にALBを経由せずにService Connectを利用して通信することもできそちらについてPoCを通して利用できることを確認しました。
既存流用のため構築も容易で、Service Connectと組み合わせることでALBの料金が不要でコストパフォーマンスも高く、セキュアな構成にできるため好感触でした。
＜構成図＞
3. Vercel案
最近よく聞くVercelにのせる案になります。Vercelは静的サイトやSPAのホスティングももちろんできますが、サーバーレス関数やWebアプリを無料で簡単にホストできるPaaSになります。
しかし、結論として、VercelはPoCを実施しませんでした。コスト見積もりの段階で、他の2案と比較してコスト効率が悪かったためです。また、APIサーバとの通信においてもクラウドを跨いでの通信となるため他案と比べセキュリティも考慮する必要がありました。
そういった事情から導入前の段階で除外したため、詳細な検証は行いませんでした。
＜構成図＞
検討案を比較した結果
検討した各構成案について、メリットとデメリットを以下の表にまとめました。
| 構成案 | メリット | デメリット |
|---|---|---|
| 1.AWS Amplify | ・インフラの構築が簡単で手軽に始められる ・CI/CDが柔軟で、ブランチごとに迅速なデプロイが可能 ・開発ブランチを活用したデプロイが容易で、開発生産性の向上が見込める ・自動でスケーリングするので運用管理の負担が少ない |
・特定のパスだけを新しいフロントエンドに向ける場合、EC2プロキシとの併用が必要 ・この構成によりシステムが複雑化し、信頼性の低下やパフォーマンスへの影響が懸念される |
| 2.ECS | ・既存環境の流用のため構築が容易 ・構成的にも統一されているため保守がしやすい ・Service Connectとの組み合わせでコストやセキュリティに恩恵がある |
・Amplifyと比べスケーリング等は自前で設計が必要 |
| 3.Vercel | ・高速デプロイ ・フロントエンド向けの最適化 |
・コスト効率が悪い |
まず、Vercelについては、フロントエンド全体を統一して構築する場合には非常に魅力的な選択肢でした。しかし、今回のように部分的な移行を進める要件には、コスト面や構成の複雑さが見合わず、採用を見送りました。
次に、Amplifyはメリットが多く、最後まで有力候補として検討しました。ただし、EC2プロキシを導入する必要がある点で、管理負荷や信頼性、パフォーマンス面の不安が残り、最終的に断念することとなりました。
そして、ECSについては、既存の環境を流用できることから、構築・運用コストを抑えつつ実現可能である点が大きな強みでした。また、Service Connectとの組み合わせにより、さらにメリットが得られることもポイントでした。デメリットについても既存の構成内で十分に対処可能であり、特に大きな課題はありませんでした。
最終的に、ECS案を採用し、この構成で無事に構築からリリースまで完了することができました。
まとめ
結局は無難な既存流用のよくある選定結果に落ち着きましたが、AmplifyやVercelといった新しいサービスも調査、検討できたことは収穫があったと思います。
最終的にECSを採用する形でプロジェクトを進めましたが、新規でサービス立ち上げだったり状況次第ではAmplifyやVercelという選択肢も有効だなと思いました。
Discussion