フェイス・ソリューション・テクノロジーズ株式会社 IS 本部 OS ユニットの Saki@猫好き です。AWS 活用していますか?
いくら AWS 認定資格 6 冠を達成していても、基本は大事。今日は、Lambda について学習しなおしてみようと思います。いえ、どちらかというと。AWS 初心者の OS ユニットのメンバーの「お勉強のお時間」です!
はじめに
AWS Lambda とは
AWS Lambda(ラムダ)とは、サーバーレスの肝となる AWS のサービスです。サーバーやクラスターについて検討することなくコードが実行できます。
インフラストラクチャのプロビジョニングや管理をすることなくコードを実行コードを書いて、.zip ファイルやコンテナイメージとしてアップロードするだけです。
改めて読むとちょっと日本語おかしいのはご愛敬。実行させたいコードを Lambda のコンソールに直接書いたり、実行させたいコード群を zip ファイル化したりコンテナイメージ化して Lambda のコンソールからアップロードすれば、利用できるようになります(S3 に置いたり、AWS CLI でスマートにアップロードする方法もあります)。
1 日に数十イベントから 1 秒に数十万イベントまで、あらゆる規模のコード実行リクエストに自動的に対応します。
幅がありすぎる。自動的にスケールされるから、ユーザー側では何も考えなくて良いよ、ってことが言いたいのだと推測します。
ピーク時の容量に備えてインフラストラクチャを事前にプロビジョニングするのではなく、使用するコンピューティング時間に対してのみミリ秒単位で支払うことで、コストを削減できます。
AWS Lambda の実行時間に対してのみ料金が発生します。実行時間は 1 ミリ秒単位で計算されるので、Lambda 関数を作成するときは、余計な処理がないか、余計なリソースを設定していないか、十分確認しましょう。
適切な関数のメモリサイズにより、コードの実行時間とパフォーマンスを最適化します。Provisioned Concurrency により、2 桁のミリ秒で高い需要に対応します。
AWS Lambda では実行する Lambda 関数で使用するメモリサイズを指定できます。適切なメモリサイズに設定することで、実行時間が飛躍的に改善することがあります。2 桁ミリ秒レベルでの応答が必要ならば、プロビジョニング済み同時実行を予約しておきます。これにより、Lambda 関数のコールドスタートを防ぐことができます。追加料金がかかるので本当に必要かどうかは考えよう。
お勉強のお時間とは
AWS だけではなく、日常業務のことでも、それ以外のことでも、事務所内は気軽に会話ができる環境です。
AWS Lambda を触ってみる
お約束の「Hello World」をやってみる
AWS Lambda のコンソール画面左柱の「関数」→「関数の作成」を選択します
「一から作成」を選択します。
(シンプルな Hello World の例で開始します、親切丁寧!)
関数名を入力、ランタイムを選択して、「関数の作成」をクリックします
ここでは、関数名を「HelloWorld_test」、ランタイムを「Python 3.9」としました。
ランタイムで選択できるもの
ちょっと小さな文字で書かれていますが、コンソールエディタで関数の編集を行う場合は、「Node.js」「Python」「Ruby」しか使えません。しかし、コンソールエディタを利用する方法以外で関数を作成する場合は、「Java」「Go」「PowerShell」「C#」が利用可能です。さらに、AWS Lambda ランタイムは、どのプログラミング言語でも実装可能です。そのため、実質、どのプログラミング言語でも AWS Lambda を利用することが可能であると言えます。
アーキテクチャは何を選べばいいのか
AWS Lambda 関数を作成するときに、アーキテクチャとして「x86_64」と「arm64」が選択できます。もし、「x86_64」アーキテクチャに依存しない Lambda 関数を利用するのであれば、コスト効率的に「arm64」を試すことも選択肢に入れられると思います。
AWS Lambda の利用料金は使用するメモリサイズに応じて 1 ミリ秒単位で課金されます。
以下の表は、「x86_64」と「arm64」においての 1 ミリ秒あたりの使用するメモリサイズごとの料金の比較表です。(単位は USD)
メモリ | x86_64 | arm64 | arm64 の割引率 |
---|---|---|---|
128 | 0.0000000021 | 0.0000000017 | 19.05 % |
512 | 0.0000000083 | 0.0000000067 | 19.28 % |
1024 | 0.0000000167 | 0.0000000133 | 20.36 % |
1536 | 0.0000000250 | 0.0000000200 | 20.00 % |
2048 | 0.0000000333 | 0.0000000267 | 19.82 % |
3072 | 0.0000000500 | 0.0000000400 | 20.00 % |
4096 | 0.0000000667 | 0.0000000533 | 20.09 % |
5120 | 0.0000000833 | 0.0000000667 | 19.93 % |
6144 | 0.0000001000 | 0.0000000800 | 20.00 % |
718 | 0.0000001167 | 0.0000000933 | 20.05 % |
8192 | 0.0000001333 | 0.0000001067 | 19.95 % |
9216 | 0.0000001500 | 0.0000001200 | 20.00 % |
10240 | 0.0000001667 | 0.0000001333 | 20.04 % |
性能比較でも、「arm64」アーキテクチャの方が良い結果が出ていることが多い模様。ただ、互換性の問題で現状足踏み中。長い目で見ると「arm64」を選択した方が良い気がしている。
アクセス権限はどうするのが良いのか
今回は、デフォルトの実行ロールを選択した状態で Lambda 関数を作成しました。
ベストプラクティスには「最小権限の原則」と記載がある通り、Lambda 関数にも、必要以上の権限を与えないようにすることが求められます。
デフォルトのまま Lambda 関数を作成すると、「関数名-role-文字列」という名前のロールが自動で作成されます。このロールにアタッチされているポリシーは、CloudWatch Logs にログを書き込むことを許可するポリシーです。
必要に応じて、このロールに最小権限の原則に則ったポリシーをアタッチすることも可能ですし、新たにロールを作成して、Lambda 関数にそのロールをアタッチすることも可能です。
新たにロールを作成して、Lambda 関数にそのロールをアタッチして、Lambda 関数の動作確認をしていたところ、CloudWatch でログを見ることができない! それは、CloudWatch Logs への書き込み許可ポリシーをロールにアタッチしていないからじゃない?
しばらく待つと、Lambda 関数が作成されました
Hello World をテストしてみる
テストタブを開きます
「テスト」をクリックします
「詳細」を選択します
Hello World ・・・では無い! だと。
確かにコードを見ると「ラムダからこんにちは」ってなってる。
課金期間が 21 ミリ秒ですので、今回のテストでは、約 0.000006 円かかりました。
最後に
Lambda 関数を「一から作成」の説明では、シンプルな Hello World の例で開始するんじゃなかったのかよ!
OS ユニットの諸君、簡単に Lambda 関数を作成し、テストすることができただろう。本当に簡単でしょ? 環境の用意もいらず、ただコードを書くだけで良いのだから。
なお、CloudWatch のロググループに「/aws/lambda/関数名」で、ログが記録されています。今回テストで作成した Lambda 関数を削除しても、このロググループは残り続けてしまうのでご注意ください。本当に不要であれば、CloudWatch のコンソールから「/aws/lambda/関数名」を削除しましょう。
IS 本部のアカウントにも、メンバーがいろいろ試したんだろうなぁという「/aws/lambda/関数名」のログがたくさん残っています。OS ユニットの諸君、地味に 0.033 USD/GB の料金がかかるので、不要なログは消しましょう。
Saki@猫好き も、消し忘れていた不要なログを見つけてさっき消しました。見つめ直すって大事。
是非、Lambda で快適なサーバーレス生活を行うことができるよう、学習してみてください。
引き続き、よろしくお願いします!
コメント