Ch8. 既存ソリューションの継続的改善
lambdaのインターネット接続
そもそもlambdaは自分のVPCの中で立ち上げることも、VPCの外で立ち上げることも出来る。
All Lambda functions run securely inside a default system-managed virtual private cloud (VPC). However, you can also configure your Lambda function to access resources in a custom VPC.
lambdaからインターネットにアクセスするには、VPCに紐付けたうえでVPC内からインターネットゲートウェイ経由でアクセスを許可してやる必要がある。その際、lambdaを紐付けるのはプライベートサブネットにしたうえで、パブリックサブネットにNATゲートウェイを置く必要がある(RDSにインターネットからパッチを当てられるようにする構成と同じ)。
VPC の Lambda 関数へのインターネットアクセスを許可する
なお、lambdaからRDSへの接続には、lambdaにIAMロールを与えることで可能だがMySQLとPostgresqlに限られる。lambdaからRDSへの接続にIAMによる認証を利用するのは一見妥当な選択に見えるが、実は実現可能になったのは最近(2017/04末)だそう。
【全世界待望】Public AccessのRDSへIAM認証(+ SSL)で安全にLambda Pythonから接続する - サーバーワークスエンジニアブログ
さらに同時接続数を200に制限するなど、割と制約が多い。
AuroraDBのIAM認証に盛大にハマるの巻 - Qiita
Health-Check
HealthCheck機能はALBやRoute53だけでなく、CloudFrontにも存在する。両者はやや挙動が異なるようなので注意する。
ALBとRoute53のHealthCheckは、n回以上リクエストにエラーが返された場合と言った閾値を設定することでそのエラーを返したインスタンスをロードバランサから切り離す。オリジンでエラーが発生した場合ユーザーにはエラーを返却しつつ、別途ロードバランサからの切り離しが行われる。
一方、CloudFrontのフェイルオーバはより高機能である。
次のいずれかに該当する場合:
1. プライマリオリジンは、フェイルオーバー用に設定した HTTP ステータスコードを返す
2. CloudFront がプライマリオリジンへの接続に失敗する
3. プライマリオリジンからの応答に時間がかかりすぎる (タイムアウト)
CloudFront オリジンフェイルオーバーによる高可用性の最適化 - Amazon CloudFront
つまり、オリジンでエラーが発生してもセカンダリのオリジンのリクエストの結果をユーザーに返すことが出来る。
この仕組みは特に504エラー(Gateway Timeout)のような散発的に発生するエラーに対しては有効な一方、プライマリのオリジンがが完全に死んでしまったような場合は（一度プライマリへのリクエストを確認するプロセスが入るため）レスポンス時間の増大を招く。
lambda@Edge
lambda＠Edgeというと、lambdaの処理をCloudFrontのエッジローケーションでやってくれるのでレスポンスが非常に速い、といった特徴がある。
これは「ユーザーにとってレスポンスが非常に早くなる」以外にも「CloudFrontに対するコンテンツへのアクセスとトリガにして、CloudFront内でlambda関数を動作させることが出来る」というメリットもある。
コンテンツへのアクセスの認証サーバとしてlambda@Edgeを利用することで、オリジンサーバには配信対象のコンテンツだけを配置する極めてシンプルなアーキテクチャが実現できる上、可用性が高まる。
SNSのFanout
SNSを利用して様々な媒体にメッセージを出力することをFanoutと呼んでいる。
SNSは配信に失敗した場合、そのステータスをCloud Watchに吐き出させることが出来る。 また送信先がSQSであった場合、メインのSQSが受信に失敗した場合に備えて、再度の再生に備えるためにサブのSQSを用意しておくことがある。CloudWatchが配信失敗を検知した場合、手動でサブのSQSから後続にメッセージを再配信するのだ。
これはイベント再生パイプラインと呼ばれ、SNSの配信失敗に備えたフェイルオーバーの仕組みとしてSNSのドキュメントにも掲載されている。 へのファンアウトAWSイベントフォークパイプライン - Amazon Simple Notification Service
なおSNSは配信に失敗したメッセージだけを保管するデッドレターキュー(DLQ)という仕組みもあるのでこちらを利用することも出来る。 Amazon SNS デッドレターキュー (DLQ) - Amazon Simple Notification Service
ネットワーク帯域幅の拡張
必要なネットワーク帯域幅が確保されていない場合、AutoScalingによってスケールアウトすることでインスタンスの数が増えてそれに伴い帯域幅も確保されるように感じられる。
しかしビデオのような大きなファイルをEC2にアップロードする場合は、インスタンス1つあたりの帯域幅が増えない限りスケールアウトによる並行処理のメリットを受けることが出来ないので意味がない。 例えば、クライアント側でビデオを小さなファイルに分割し、スケールアウトされた別々のインスタンスに対して転送し各インスタンスで保存するような構成にしなければファイルの転送を並行処理できない。
ネットワークの帯域幅はインスタンスタイプによって予め固定されている。
例えばu-24tb1.metalインスタンスタイプ(SAP Hanaの本番などに利用される超大型インスタンス)は100Gbpsの帯域幅を持つのに対してm5.largeは最大10Gbpsとなっている。
