Lambda+RDSはアンチパターン - Qiita
何が起きたのか 作成していたアプリではサーバレス構成にてLambdaからRDS(MySQL)を呼び出していました。 リクエストが増えるとRDSのコネクション数が増加して すぐにDBコネクションエラーになってしまいました。 最大コネクションの上限値 結論から言うとLambdaとRDS(MySQL)は相性が良くないです。 理由はLambdaからRDSのDBコネクションを貼ると リクエスト単位でコネクションを張ってしまうため 仕組み上、同時接続に耐えられません （RDSのコネクション上限数が少ない） さらにVPC設定すると・・・ セキュリティのため、RDSをLambdaからのみアクセスさせるためには LambdaとRDSを両方とも VPC領域に置く必要があるのですが、Lambdaの起動が遅くなる場合があります。 これは、一定時間Lambdaがコールしない場合にスリープ状態になり、 起動する際にE
AWS LambdaのRuby、カスタムランタイムで動作している説 - Qiita
AWS LambdaのRubyの実行環境が何で動いているのか気になって軽く使ってみたのでメモ ※2018-12-06追記 コメント欄でカスタムランタイムで動いていることを @JONAO33 さんに教えて頂きました。ありがとうございます！ "The Runtime API is the future of how we’ll support new languages in Lambda. For example, this is how we built support for the Ruby language." https://aws.amazon.com/jp/blogs/aws/new-for-aws-lambda-use-any-programming-language-and-share-common-components/ Hello worldをして呼び出し時間（課金時間
各Cloud Functions で使える言語比較(2018年7月) - Qiita
(バージョンが書かれていないのは公式Webサイトで情報を得られなかったもの) Node.js(JavaScript) はすべてのベンダーでサポート済み。 次に多いのは Java、その次が C#(.NET Core) になりました。 Java はマルチプラットフォーム前提ですが、 .NET Core も Linux や macOS などの非Win環境をフルサポートしているため、FaaS の実行環境が Windows でない場面でも使うことができます。 簡潔な処理だけを FaaS にまかせて、複雑な処理はホスティングしたアプリケーションサーバーやバッチサーバに行わせるのが一般的でしたが、サーバーレス、マイクロサービス化の流れが強くなってきているので、FaaS でやりたい事も増えつつあります。 その場合 JavaScript(TypeScript) ではツラい場面も増えると思われるので、他の(希
Google Cloud Functions で Go を使おう！ - Qiita
注意 今 Google Cloud Functions (GCF) はまだベータで、まだアメリカしか使えなくて、まだNodeJSしか使えませんから、将来にいつかこの方法を使えないかもしれませんが、やってみよう！ はじめに 普通に、前に AWS Lambda や GCF みたいな Function as a Service (FaaS) と言うサービスでは Go を使えませんでした。でも、今月 AWS Lambda がアプデイトされて、今 Go を使えますが AWS があまりすきじゃないんだから GCF で Go を使う方法をしらべました。そして、このプロジェクトを見つかりました。 それは日本語で「グーグル・クラウド・ファンクションの非公式の Go のネイティブのランタイム」です。 この方法について この方法は初めてのリクエストで NodeJS のプロセスを完全に入れ替えて Go のプロセス
AWS Lambda(Node.js)からAmazon RDSへIAM認証で接続する - Qiita
概要 現在開発しているburariというおでかけアプリでは、APIGatewayからLambdaを実行し、RDSのデータを取得している。 以前まで、LambdaからRDSへの安全な接続にはVPCが必須となっており、AWS Lambdaの定期実行をSAMを使って実装するにも書いたとおり、コールドスタート問題が懸念になっていたが、IAM認証でLambdaからRDSに接続できるようになったため、ついにVPCから解放される日がきた。VPCから解放されることにより、LambdaからSNSやKMSへの接続にNATが不要になるため、お財布にも優しいサービス運営が待ち受けている。 今回は接続まわりを実装してみる 💪💪 環境 Amazon RDS (MySQL v5.7.17, t2.micro) AWS Lambda (Node.js v8.10) Sequelize (ORM for Node.js
問い合わせフォームもサーバレスでDevOps! (Github,CircleCI,AWS lambda/cognito/ses) 後編 - Qiita
問い合わせフォームもサーバレスでDevOps! (Github,CircleCI,AWS lambda/cognito/ses) 後編GitHubAWSCircleCIlambdacognito 前回の記事で、単純な静的サイトのオートデプロイフローまで完了した後の続き。 後編 「問い合わせフォームもサーバレスでDevOps!」 認証 AWS Cognito 処理 AWS Lambda 通知 AWS SES を利用して、もちろんサーバレスで。 Gibhubへのstaging/masterへのpush のみで、 CircleCI経由で各種環境へ自動デプロイを実現。 前提 前回同様の続きなので、 s3site.proudit.jp -> 本番サイト st.s3site.proudit.jp -> ステージングサイト が、すでにGithub+CircleCiにてデプロイ可能である前提で進める。 構
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
