要約

  • AWSはS3 Filesの直接読み出しを、Lambdaのメモリー容量とは別に明示的に選べると発表した。
  • 実行の成功だけでは、実際の読み出し経路や費用削減を確認できない。

ストレージの読み方を変えたいだけなら、計算資源まで増やす必要があるのだろうか。9月11日のLambda発表は、S3 Filesの直接読み出しの明示的な選択を、関数のメモリー容量から切り離した。調整できる項目が増えたのであり、費用削減が実証されたわけではない。

APIにはAUTO、ENABLED、DISABLEDがあり、直接読み出しが失敗するとファイルシステム経由へ戻る仕組みも記されている。処理を継続できることには価値がある。ただし、呼び出しが成功しても、意図した経路でデータを読んだ証拠にはならない。

メモリーとCPUの関係は残る

LambdaのCPU割り当ては、引き続き設定メモリーに比例する。新しい選択肢を使って容量を減らすと、読み出しの設定と計算資源の両方を変える可能性がある。処理時間の変化も評価に含めなければならない。

例えばメモリーを半分にして課金対象時間が倍になれば、その積は減っていない。これは計算例であり、AWSの測定結果ではない。標準のLambda Functions料金には、リクエストとメモリーを反映した実行時間が含まれる。容量の数字が小さくなっただけでは、経済効果は決まらない。

ストレージには別の計量がある。S3 Filesはファイルシステムのデータアクセスと直接読み出しを区別し、後者にもS3 GETとメタデータ読み出しの料金がかかる。特定の読み出し料金を避けても、操作全体が無料になるわけではない。正しく完了した一件の仕事を単位に、伴うストレージ利用まで合わせて比較したい。

設定値と通った経路を分ける

公表文書には表現の違いもある。発表文はファイルの大きさによる振り分けを説明する一方、APIのENABLED欄は、すべての読み出しを指す広い表現になっている。両者を黙って一つの検証済み動作規則にまとめることはできない。本稿では実行試験を行っていない。

共通しているのは、メモリーとは別に読み出しの選択を明示できる点だ。一方、混在した処理の各操作が実際にどこを通るかを、設定値だけで確定するには足りない。

小さな項目を大量に読む処理と、大きなデータ群を順に読む処理では、適した選択が異なり得る。これは分析上の例であり、顧客の測定結果ではない。時間の使われ方と課金項目の変化を見なければ、ストレージ調整に伴う計算の減速や、別経路への切り替わりを見落とす。