はじめに
プロダクティビティーチームの鈴木です。
本記事では、400以上のAWS Lambda関数から構成されるアプリケーションのリアーキテクチャの過程を紹介し、直面した問題や解決策を解説します。
内容はこちらのスライドにもまとめているので合わせてご一読ください。
既存アーキテクチャの課題
既存アーキテクチャは以下の様な課題を抱えていました。
-
Amazon API Gateway,AWS Lambdaでの実行が前提となっているためローカル開発環境が困難 - アプリケーションコード、デプロイパイプライン、インフラが
serverlessで管理されているためデプロイの安定性が低く、処理も遅い - アプリケーションコードの増加に伴う
AWS Lambdaコールドスタート時のレスポンス遅延が発生 -
AWS Lambda数に比例する監視ツールのコスト増加
漸進的なリアーキテクチャ
私たちはこれらの問題を解決するためにリアーキテクチャを進めています。
リアーキテクチャで目指す状態は、400以上のAWS Lambda関数から構成されるアプリケーションをECS/EKSなどのコンテナ構成へ移行することです。
しかし、いきなり大規模なリアーキテクチャを行うには長期間の開発が必要になり、その間の技術の進化やビジネス要件の変化により計画が陳腐化し実現可能性のリスクも高まります。
そのため段階的に価値を積み上げながら移行し、最終的な理想へ近づける漸進的なアプローチが重要になります。
移植性(portability)について
引用文献: 「JIS X 25010：2013 (ISO/IEC 25010：2011) 図4−製品品質モデル 」
既存のアーキテクチャの様々な問題の要因は、AWS Lambda、アプリケーションコード、ビルド・デプロイパイプライン、インフラ構成がすべて密結合になっていることが大きな課題だと判断しました。
そのため、AWS Lambdaに強く依存したシステムを段階的に疎結合化し異なる環境への移行を容易にする移植性を高めることで、部分的に改善し、リアーキテクチャの開発のリスクを最小化することができると考えました。
そこで鍵となるのが移植性です。JIS X 25010:2013（ISO/IEC 25010:2011）では、移植性を「システム製品または構成要素を他の環境へ移すことができる有効性および効率性の度合い」と定義しています。
私たちは、既存のアーキテクチャをAWS Lambdaだけで動作する状態から、前述した密結合している各要素を独立して管理できるように分離し、ECS/EKS、ローカル開発環境などでも動作するようにする移植性の向上を目指し以下の対応を行いました。
1. AWS LambdaのアーティファクトのDocker化
AWS Lambdaのアーティファクトをzip形式からDockerに変更しました。
これにより、コンテナが実行可能な環境であればECS/EKS、ローカル開発環境などでも動作するようになります。
副次的な効果としてコールドスタート時のレイテンシ低下の恩恵が受けられました。
2. OpenAPIの整備
元々、メンテナンスが止まっている12,000行のopenapi.yamlが存在しており、後述するFastAPIの導入をスキーマ駆動開発で行いたかった為この大きなyamlを整理、構造化してメンテナンス可能な状態にしました。
これにより、OpenAPIからFastAPIのControllerレイヤーが自動生成可能になりました。
3. Lambdaのモノリシック化(Lambda-lith)
APIのアクションごとに存在していたAWS Lambdaを1つにまとめるLambda-lithという構成に移行しました。Lambda-lithについては、AWS Developer GuideではイベントドリブンのAnti-patternsとして紹介されており、AWS Compute Blogではサーバーレスマイクロサービスの設計アプローチの1つとして紹介されています。
事例も少なく、メリット、デメリットが顕著でしたが、今後計画しているECS/EKSへの移行を見据えてステップを踏むために採用しました。
まとめたAWS Lambda内でリクエストのルーティングのためにFastAPIを採用しています。
「2. OpenAPIの整備」の資産を使い自動生成を活用する事で、移行のコストを下げると同時に今後もスキーマ駆動開発の恩恵を受けた開発が可能になりました。
また、ルーティングをアプリケーションレイヤーで行うことでAPI Gatewayとの密結合も解消されます。
これにより、「Docker上で動作するFastAPIアプリケーション」がAWS Lambdaで実行されている状態になり、ECS/EKS、ローカル開発環境などで動作する移植性の向上が実現しました。
おわりに
このように、漸進的なリアーキテクチャを行うことで以下の恩恵を段階的に享受しながらシステム全体を持続的に進化させることができています。
- デプロイの安定性向上
- パフォーマンス最適化
- 運用コスト削減
- 移植性の向上
- スキーマ駆動開発の基盤構築
今後は以下の様な更なる進化を計画しています。
- アプリケーションレイヤーのデプロイが
serverlessのパイプラインから独立可能になった事から全体のデプロイの不安定さ解消や速度の改善 -
ECS/EKSへの移行
Discussion