BPaaS が AWS Amplify Gen 2 を選択する理由

Last updated at 2024-12-02Posted at 2024-12-02

kubell Advent Calendar 2024 の投稿です。

2024年7月1日、Chatwork株式会社は株式会社kubellへと社名変更しました。

この投稿では、BPaaS プロダクト開発において AWS Amplify Gen 2 (Amplify) を選択した理由について書きます。

tl;dr

Amplify を選定した理由は、開発効率とスピード向上のため
AWS サービスとのネイティブ統合で認証やデータベース設定が簡単
自動ビルド・デプロイ機能により迅速な開発とリリースが可能
柔軟な環境管理でチームの要件に適合

前提

BPaaS サービスとは

チャット経由で会計、労務、総務など様々なバックオフィス業務をアウトソースできる「Chatwork アシスタント」などのサービスです。
私たちは現在バックオフィス業務管理システムの構築を進めています。

スキルスタック

私たちの共通のスキルスタックは TypeScript です。Full-Satck TypeScript がチームの方向性として合致していました。
Amplify は AWS CDK でインフラを構築でき、TypeScript との親和性が高いと思います。
- 私自身の経験としても、CDK for Terraform (CDKTF) ¹ を使用して構築した経験があり、前職での経験が Amplify に対応しやすいものとなっていました。

チーム状況

私たちがチームを構築したのは最近で、Developer は多くありません。そのため、効率的に開発を進める必要がありました。

Amplify を選定した理由

開発効率とスピードの向上

市場志向のチームとして、開発効率とスピードの向上という明確な理由があります。Amplify は、簡単に安全でスケーラブルなアプリを構築することができます。

プラグインアーキテクチャの活用

AWS の各種サービス、特に認証やデータベースとのネイティブな統合が特徴です。
Amplify が持つこの特徴より、必要に応じて Amazon Cognito などの AWS サービスを組み合わせることができ、柔軟なシステム設計が可能です。

プラグイン方式の恩恵により、アプリケーションへの依存は、コードベースでほぼ存在しません。ローカル環境のみで起動できますし、AWS 環境への接続も AWS CLI があれば気軽に行えます。 aws configure sso
Amplify で生成される設定ファイル (amplify_outputs.json) があります。フロントエンドアプリケーションがバックエンドリソースにアクセスするために必要な情報を含んでいます。

バックエンドの技術スタック選定

バックエンドの Frameowork として NestJS を選定しました。

この選択により、フロントエンド・バックエンドどちらも開発することができ、メンバーの作業負荷状況に合わせて、フロントエンド・バックエンドに移動しながら開発できます。
フロントエンド・バックエンド・インフラの重なる部分は、言語を意識する必要がありません。
- 例えば、バックエンドの Read Replicas の Extension の追加とインフラの Reader Instance の設定を SRE が実装しました。
- E2E Testing (Playwright) や負荷試験 (k6) も TypeScript でカバーしています。 ²
リポジトリは開発の効率を考慮し Monorepo を採用しています。 Nx ³ や Turborepo ⁴ は検討しましたが、2024年5月当時 Amplify の Framework 検知に誤作動があったため、見送りました。
- リポジトリルートの package.json の dependencies に next が含まれる場合、当該アプリのフレームワークが Next.js と認識される動作となっていた。
```
[ERROR]: !!! CustomerError: Can't find required-server-files.json in build output directory
```

自動デプロイと環境管理の柔軟性

Amplify には default で GitHub と連携して自動的にビルドやデプロイを行う機能があり、開発チーム全体のフローを円滑にする役割を果たしています。
特に私たちのように素早いプロダクトリリースとフィードバックサイクルを目財しているチームにとって、Amplify の自動デプロイ機能は非常に魅力的だと思います。
Amplify Console の利用により、異なるブランチを異なる環境（例えば Staging や Production）に割り当てることができるため、環境ごとのテストや確認がスムーズに行えます。

課題

Amplify Managed の制約

Amplify Managed Frontend は CloudFront、Lambda で構成されています。この構成は、開発者の作業を省力化するメリットがありますが、一部の制約も伴います。
特に、Lambda の設定を変更することができないという課題があります。具体的には、Lambda でアクティブトレースを有効化し、ログにトレース ID を出力することが望まれますが、Amplify の Managed 環境では現時点でこの設定がサポートされていません。⁵ この制約により、トラブルシューティングやパフォーマンス監視の効率が低下する可能性があります。

`ampx` コマンドのエラー解析の難しさ

ampx コマンドでデプロイ時に発生するエラーから原因を特定するのはその時点では難しいと感じられました。
- 例えば、ログに記録されている current_account-current_region は、Amplify が内部的に使用している CDK にて、CDK が内部的に使用しているアセットの destinationId の値となります。成功する場合にも current_account-current_region はコマンドの出力結果に含まれるので、これが当該事象の要因ではありません。
```
The CloudFormation deployment has failed.
Caused By: ❌ Deployment failed: Error: Failed to publish asset 7af0558dad8eb937cbd5c43b7fe6bec9b1f611815c892643b5099811a28c3480:current_account-current_region
```
一方 cdk diff cdk deploy の警告や StackTrace は多くの情報を与えてくれます。ampx コマンドと比較して。

Stateful な構成要素の扱い

当初はカスタムリソースとして、全てを Amplify で定義するつもりでした。

しかし、 Database などの Stateful な構成要素は変更が必要なタイミングが限られており、アプリケーションのデプロイサイクルとは異なります。
原理的にはカスタムリソースを用いれば、Database を含め Amplify で構成することも可能でした。私がサポートに確認した時点では、サポートの見解も同様でした。しかし、最終的にカスタムリソースの全面的な採用は断念しました。

Amplify で稼働している Lambda (Render) から Backend API の Endpoint である ALB への通信は、リージョン内およびリージョン間のトラフィックになります。

記事は以上です。

この投稿をみていただい方はいいねをお願いします。

それでは次回のアドカレでお会いしましょう👋

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up