Lambda Layersを使うとデプロイは遅くなり、コールドスタートは高速化する？！Lambda Layersを使って巨大なLambda Functionを分割した場合の挙動の変化 | DevelopersIO
2019/10/26追記 最近類似の検証を流した際は ・ サイズの大きなFunctionのパッケージ ・ サイズの小さなFunctionのパッケージ & Layer どちらもコールドスタートの所要時間に差異がありませんでした。 若干検証パターンが違うので一概に比較はできませんが、Layerを使うだけで常にコールドスタートが高速化するわけでは無さそうです。 ブログ執筆時以後にLambdaの内部的な挙動が変わった可能性もあります。 以後の内容は、あくまでブログ執筆時点における検証結果として参考にするに留めて下さい はじめに サーバーレス開発部＠大阪の岩田です。 前回のブログでLambda Functionに紐付けるレイヤーのサイズを増加させていった場合の挙動について考察しました。 巨大なレイヤーを紐付けたLambda Functionの挙動を観察してみた 今回は Lambda Layersを使
勤労統計問題の原因は「COBOLプログラムのバグ」 – アゴラ
厚生労働省の毎月勤労統計調査についての特別監察委員会の報告書が出され、樋口委員長の記者会見が行われた。疑問も残るが、おおむね事実関係は明らかになった。焦点になっている東京都の大企業の抽出調査については次の通り： 2003年5月22日付の事務連絡に「事業所規模５００人以上の抽出単位においては、今回から全国調査でなく、東京都の一部の産業で抽出調査を行うため注意すること」と書かれている。この事務連絡は雇用統計課長の決裁をへて他部局にも公式に伝達されており、隠蔽の事実はない。 当時の担当課長は「抽出調査としたことについて、覚えていないが当時自分が決裁したと思われる決裁文書を見たらそのように残っていたのでそうなのだと思う。ただ、抽出していたとしても労働者数に戻す復元を行っていれば問題ない」と供述しているが、この復元が行われた形跡がない。 システム改修を行った担当係によると「外部業者等に委託することな
Fargateで起動するコンテナのログをFluentd経由でS3に保存してみた | DevelopersIO
現状、Fargate上のコンテナが利用できるログドライバーはawslogsのみです。つまり、アプリケーションログ（標準出力）の集約先としてはCloudWatch Logsしかありません。 「それはわかっている。でもどうしてもFluentd経由で外部にログを送信したいんだ。。」 そんなことがありました。ということで今回はFargate上で起動するコンテナのログをFluentd経由で外部に送信する方法を紹介したいと思います。 ログ転送イメージ アプリケーションコンテナおよびFluentdコンテナで共有ボリュームをマウントします。アプリケーションコンテナはそのボリューム上にログを出力し、Fluentdコンテナはそのログ参照します。 ECSの言葉でいうと、1つのTaskにアプリケーションコンテナ、Fluentdコンテナ、およびVolumesを定義し、両コンテナのMountPointsで同一のVol
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
