AWS Web Servicesを使ったサーバーレスアプリケーション開発ガイドを読みました
Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド
- 作者: 西谷圭介
- 出版社/メーカー: マイナビ出版
- 発売日: 2018/03/16
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
上の本を読みました。全体的に
- Lambdaになれました
- Vueになれました*1
という感じなのですが、個人的に特に気になったトピック2つだけ並べておきます。
サーバレスで何をやるにしろまずIAMのことを考える件
- サーバレスのサービスを利用する
と書いてあったときにやる手順が、
- AWSサービスへの信頼ポリシーがインラインポリシーとして埋め込まれたロールを作成する
- サーバレスで実行したい関数で使う予定のリソースへのアクセス権限を記述したポリシーを書く
- 1.のロールに2.のポリシーを付与する
- 関数実行時のロールとして3.のロールを指定する
- (あるいは0.)Lambdaで実行したい関数などを書く
- 5の関数をデプロイして実行
となっていて、サーバレスをやるぞ、といったときに、想定しているのが5とか6だけだったので、自分がAWSに慣れてないだけかもな、と思いつつも、サーバレスよりまずIAMだなぁ、と思いました。
いや、自分で実行するタイミングとか制御しにくくなるので権限管理は余計に大事なんですがが。
めんどくさがっていても仕方ないので、せめて
- Lambda
- CloudFormation
の2つについては、それぞれ何をするサービスで、どういう権限が必要かをざっくりまとめておきます。
Lambda *2
使い方
あらかじめPython3.6など特定のバージョンの特定の言語のプログラムが動かせる実行環境がいくらか用意されているので、利用する実行環境を指定して、zipなどでコードをアップロードする。
実行条件はSDKからの呼び出し、タイマーでの設定(CloudWatchを利用)、他サービスでのイベント駆動(S3にファイルがアップロードされたらメタデータが入ったJSONを引数に実行開始、的な)などがある *3 。
与える必要のある権限
- 連携先のサービス(たとえばS3に)に与える権限で、Lambda関数へのアクセスを許可するための権限(
lambda:InvokeFunction
) - 実行するコードでアクセスするリソースへのアクセス権限
- ログを吐くためCloudWatchへのアクセス権限
CloudFormation *4
使い方
AWS CloudFormationを使うと、設定ファイルを書くことで、AWSのリソースの集合をスタックという単位で壊したり更新したり作成したりできるようになります。
ひらたくいうと、AWSが用意したYAMLで書けるTerraform*5で、大きな特徴として、必ずデプロイ用の設定を保管するS3のバケットを用意する必要があります。
Lambda + DynamoDB, API Gateway など、サーバーレス向きサービスだけ利用する場合は、SAMというサーバーレス用のフレームワークを用いて簡潔に記述できます。
与える必要のある権限
CLIで実行している間は開発者がなんでも権限を持っていたりするので気にならないんですが、CIの工程にCloudFormationによる環境構築を含めるときには
- package コマンドで作成した設定ファイルetc. をアップロードするS3のバケットへのアクセス権
- CloudFormationで操作する予定のサービスのアクションの許可(たとえば、DynamoDBをいじる設定を書いたのにDynamoDBを作成、削除、取得する権限がないと実行できない)
- IAMパスロール
- CloudFormationの変更セット*6を作成するための権限*7
- Lambda関数などサービスのリソースのロールにポリシーをアタッチ/デタッチするための権限(
iam:AttachRolePolicy
/iam:DettachRolePolicy
)
などが必要です。細かくは、本の p.246~ に例があって勉強になりました。
DynamoDBについて
本書を読んで
サーバレスでDynamoDBじゃなくてRDSでいいのでは、と思っていたけど、RDSを使うのがよくないのは、同時接続数が増やせたとしてもDB側のサーバのCPUやメモリを食うので、ストレージに対して高いインスタンスタイプ選ぶことになるけどいいの? ってことなのか
— woshidan (@woshidano) December 5, 2018
という具合に「RDSはLambdaに向かない」の意味を理解して、スキャンなどのAPIもさわって理解した気になっていたのですが、
- https://www.slideshare.net/SORACOM/aws-dev-day-tokyo-2018-amazon-dynamodb-backed
- https://www.slideshare.net/AmazonWebServicesJapan/dynamodb-121535114
などのスライドを見ていると、トランザクションの整合性に対する理解が特に弱いし全体的にまだよくわかっていないな...という感じなので精進します。
そういえば、indexを貼ってないキーでの検索はフルスキャンが強調されていますが、indexを貼ってないキーで検索するとフルスキャン、というのはRDBMSでもそうですね。
Kinesisについても触ってはみたもののよくわかってないな、という気持ちがあるのでがんばっていくことにします。
現場からは以上です。
*1:フロントエンドから直接データストア触ることが増えるんだったらバックエンドの人も何が起きてるのか調べるために最低限フロントエンド読めた方がよさそう、と思いましたがほどほどに頑張ります
*2:https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-s3-example.html
*3:テスト用のイベントデータ作成に困った時はコンソールでテストイベントの設定をクリックして出てくるイベントテンプレートのサンプルが便利です http://www.atmarkit.co.jp/ait/articles/1706/13/news008_2.html
*4:https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-s3-example.html
*5:作成、更新するときは、deployコマンドの前にpackageコマンドを実行するのですが、そうすると更新しようとしている内容を出力ファイルに吐き出してくれます。Terraformがapplyだろうがplanだろうがこれから更新する内容に差分があればコンソールに出力するようになっているので、え、何も出さずに更新するの? と最初少しビビりました
*6:https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-create.html
*7:CLIで同一のスタックに対し変更 => 再package & deploy を実行していたものの、変更セットについては特に意識せずに終わったので、CLIでスタックを更新する時は裏で作成されているっぽい