みなさんは、AWS Lambda は活用されていますでしょうか。
コンピュータで自動化のタスクを実行するためには、かつてはサーバを自分で用意して常時稼働させておき、タスクをサービス化して常時立ち上げて実行したり、定期実行の仕組みで一定間隔でタスクを実行したりするのが当たり前でした。
AWS Lambda を利用すると、常時稼働のサーバを自前で用意することなく、AWS のコンピューティング環境の上で、タスクを実行したい時に実行したい分だけ実行することができます。
料金は、処理を実行したコンピュータの性能と、処理を呼び出した回数、処理にかかった時間などに対してのみ発生するという、オンデマンドな料金体系になっているため、無駄なコストを極力省くことができるようなサービスになっています。
そんな AWS Lambda ですが、すごく便利でコスト削減効果も期待できる反面、処理の効率を考えず、さらに無駄な処理が多かったりすると、それらに対するコストも請求されてしまう、ということを意味します。
本日は、例を用いて少し紹介したいと思います。
私は AWS Lambda では、専ら Python 3 で処理を実装しているので、Python 3 での例になります。

Python には、複数の要素を含むひとつのまとまりの中から、欲しい要素が含まれているかどうかを調べることのできる「in」演算子というものがあります。
基本的な利用例は、次のようになります。

>>> numbers = [1, 2, 3, 4, 5]
>>> 4 in numbers
True

「numbers」という 1 から 5 までの数字を含むまとまり (この場合、リスト) の中に、4 が含まれているかどうかを「in」演算子で調べた結果、True、つまり含まれている、という答えが返ってきた例です。

それでは、別の例を見てみましょう。
Python には、先ほど「複数の要素を含むひとつのまとまり」と表現したものを表す方法がいくつかあり、それらはオブジェクトの型といいますが、代表的なものに次のような種類のものがあります。

• リスト (配列)
• タプル (変更不可能な配列)
• ディクショナリ (辞書)
• セット (集合)

最初の例では、「リスト (配列)」を使って 5 つの数字を含むひとつのまとまりを表現しました。
今度は、1 から 1000 まで順番に並んだ、合計 1000 個の数字を含むまとまりの中に、555 という数字を含むかどうかを調べる例を考えます。
上記の 4 種類の異なるオブジェクトの型を用いて、それぞれ同じように「in」演算子を用いて要素を調べるコードを書きました。
そして、それぞれの処理にかかる時間を計測して比較してみます。
以下に出力結果だけ掲載します。

#1 => set: 0.0000013830 seconds (#1 x 1 times)
#2 => dict: 0.0000015610 seconds (#1 x 1 times)
#3 => tuple: 0.0000122370 seconds (#1 x 9 times)
#4 => list: 0.0000129700 seconds (#1 x 9 times)

すると、リストやタプルを用いて調べた場合は、ディクショナリやセットを用いて調べた場合と比較して、約 9 倍もの処理時間がかかっていることがわかります。
今回のケースは、1 から 1000 まで順番に並んだ、合計 1000 個の数字を含むまとまりの中に、555 という数字を含むかどうか調べる処理を試しましたが、1000 個の数字のまとまりをシャッフルしたりすると、その差は 15 倍以上になるケースもありました。

「1000 個の数字を含むまとまりの中に、ある数字を含むかどうか調べる」という例を紹介しましたが、その目的を達成するだけでも、複数の方法 (手段) があることがわかります。
今回の例に限らず、多くの場合、目的を達成する手段はひとつではなく、複数存在していて、さらにその手段によっては処理にかかる時間、ひいてはコンピュータ資源の利用効率など、様々な点で大きな違いが出てくる可能性があるということです。
AWS Lambda では、コンピュータの性能や処理時間に対して発生する料金が違ってくるため、実装の仕方の良し悪しによっては、請求額に大きな差が出てくることもあるということが分かりました。
今回、 Python においてオブジェクトの型によって処理時間が大きく異なる例を紹介しましたが、これは Python の言語処理系の実装上の違いにより、処理時間に違いが出たものですが、他の言語でも同様のことが発生するでしょう。
便利なクラウドコンピューティングのサービスを利用するからといって、効率の悪い実装をして良いことにはならないことを再確認したので、今後も色々な場面で最適な実装方法を模索していきたいと思います。

Featured Image by Victor Semionov – Brainstorming (2017) / CC BY 2.0