はじめに
ある現場で
リーダー「簡単なWebアプリだからAWSにちゃちゃっと移行しといて」
私「わかりました。PHPとMySQLで作られているようなのでEC2とRDS使いますね」
リーダー「ダメ。APIGatewayとLambda使ってサーバーレスにして。あとDBはDynamoDB」
とよくわからないことを言われました。
APIGatewayもLambdaもDynamoDBもサーバーレスもよく知らない状態から
なんとか本番リリースできたので、感想をまとめておきます。
(2016年時点での話になります。)
環境について
| 移行前 | 移行後 | |
|---|---|---|
| 環境 | オンプレミス | AWS |
| 言語(サービス) | PHP | APIGateway, Lambda |
| DB | MySQL | DynamoDB |
APIGatewayについて
- Lambdaにデータが渡らない等の問題が発生した場合、原因究明が大変。ログは出力されるけどわかりにくい。特に本番では大量にログ出力されるため、探すだけでも大変。
- 当時はバグらしきものが結構あった。(Mapping Templatesにミスがあったり、設定更新が反映されてなかったり。でも数日で修正されてた。)
- APIGatewayのキャッシュが便利。というかアクセスが多い場合は必須。
- APIGateway設定のバックアップ、リストアが完全にできなかった。
Lambda(Node.js)について
- Lambda単体であればローカル環境でも簡単にデバッグ可能。
- APIGatewayと組み合わせて使用する場合は、ローカル環境ではAPIGatewayのモックが必要。
当時は良いフレームワークやライブラリがなかったためモックも自作した。 - 初回起動に時間がかかる。Lambdaだけタイマーで定期的に動かしてみたけど、APIGatewayを通して呼び出すとやっぱり初回は時間がかかってしまう。
- ひとつのLambdaをどれくらいの規模（ひとつのリクエスト、ひとつの機能、ひとつのアプリ等）にすべきか難しい。
- Webアプリとして考えるとバージョン管理が大変。Lambda単位でバージョンをつけるため。
DynamoDBについて
- 一般的なNoSQLの特徴。（RDBとは異なるテーブル設計が必要。テーブル結合できない。パーティションキーが重要等。）
- 空文字が利用できない。
- ローカル環境でも使用できるので開発中は便利。
- データ取得時の容量制限（1MB）があるので、大量に取得したい場合は複数回呼び出す必要がある。
- アクセスが多いとお金が結構かかる。
その他
- アクセス数によっては、サーバーレスよりEC2とRDSを使用したほうが、かなり安い。
- テスト環境、本番環境、リリース手順、切り戻し手順等をどう運用するか事前に
しっかり考えておかないとめんどくさいことになる。 - APIGateway経由で定期的にLambdaを呼び出しておけば、すぐにレスポンス可能だが、
スパイクアクセス時にはスケールしきれず、アクセスの取りこぼしがある。 - APIGateway＋Lambdaの組み合わせは開発やデバッグ、設定等が大変なため、大規模なシステムには今のところ向かない。
- WebAPI(マイクロサービス)として利用するのであればAPIGateway＋Lambdaはかなり良いと思う。
最後に
ほんとはもっと役立つ記事にしたかったのですが、2年前のことなので、かなり忘れてしまいました。
現時点では変わっていることもいろいろありそうなので、やっぱり記事はすぐに書かないとだめですね。