第３回【Serveless初級編その１】¶
サーバレスアーキテクチャ
マネージドなサービスだけで構築するアーキテクチャ。
いわゆるオンプレ的な"サーバ"として意識するものがないだけで、実際の物理的なサーバはどこかにある。
従量課金で永久的な無料枠もあるのでほとんど0円での運用も可。セキュリティパッチを当てるなどの必要もないのでバックエンドに関しては放置も可能。
先日開催されたAWS DEV DAYでもServerless関連の話題たくさん。
最もオーソドックスなのはSPA(あるいはAndroidやiOSアプリ)＋ApiGateway＋Lambda＋DynamoDB（＋ユーザ認証基盤にCognito）。
ApiGateway¶
名前の通り、APIの入り口を提供するサービス。
Lambda単体ではただの関数。他のサービスと組み合わせることで無限の可能性。
RestAPIの場合はApiGatewayと連携させる。
Cognitoと連携させたユーザ認証や、カスタムオーソライザによる任意の認証で保護できる。
デフォルトでアマゾンが提供するドメインのHTTPSのURLが利用できるが、Route53と連携して独自ドメインでの提供も可能。
WebSocketにも対応。
ApiGatewayの兄弟分（弟）のサービスとしてAppSyncがある。
AppSyncはRestAPIではなくGraphQLによるクエリを提供するマネージドサービス。
Lambda¶
前述のとおり、他のサービスと組み合わせることでいろいろできる。
サーバレスアーキテクチャの核になるサービスといえる。
メモリの設定を上げることで、他のスペックもと料金も上がる。
結構な無料枠が用意されている。
最大の処理時間15分の制限あり。（小規模なバッチ処理ならLambdaで十分）
通常のLambdaはVPC外のサービス。
VPC内のサービス(主にRDS)にアクセスするにはVPC内に配置する必要あり。
VPC内に配置するとENIの起動コストがすごくかかるのでVPCLambdaは極力利用しないのがセオリー → ENIの起動コストについては最近改善された模様。
アーキテクチャ上、コネクションプーリングは無理。
新しいインスタンスが立ち上がる時にコールドスタートが発生する。
Javaは仕組み上コールドスタートが遅いので、RestAPIのバックエンドとして使う分にはpythonやnodejsより向いていない。
一方、一度起動したインスタンスでの処理はpythonやnodejsなどより高速らしいので、用途に応じて適切なものを使えばよい。
標準のものやAWSのSDK(pythonの場合はboto3)は素の状態でimportできる。
サードパーティーのlibraryに依存する場合は一緒にzipで固めてアップロードする必要あり（→SAMやServerlessを利用すると楽。というか利用しないと辛い）。
SAM(ServerlessApplicationModel)という公式の開発フレームワーク的なものが提供されている→SAM-CLIはCloud9環境で最初から使えるようになっている。
公式ではないがServerlessという有名な開発フレームワーク？がある（SAM登場以前のスタンダード？）。
CloudFrontにアタッチして使うLambda@Edgeというものもある。
→ 工夫しだいでいろいろできる。（例：画像の自動リサイズ）
Amazon CloudFront & Lambda@Edge で画像をリサイズする
DynamoDB¶
NoSQLなのでテーブル設計には従来のRDBMSとは全く別の考え方が必要。
複雑なクエリでデータを取得するような要件があるシステムには不向き。
→ 分析専用に別の構成を用意することで解決するアプローチも。(DynamoDBStream→RDSやRedShift、S3＋Athena、等)
料金¶
lambdaの料金
apigatewayの料金
dynamodbの料金
hello worldといえど、認証で保護していないAPIを公開しておくのはアレなのでステージを削除しておきましょう