SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

CodeZine Press

Pythonは最も人気のあるLambdaランタイム――Datadogサーバレス実態調査から得られた8つのインサイト

  • X ポスト
  • このエントリーをはてなブックマークに追加

「サーバレス実態調査」の8つのインサイト

Lambda関数の多くでProvisioned Concurrencyを過剰利用

 サーバレスの関数は、内部的にはコンテナ技術が活用されている。コンテナを含む関数のインスタンスは、関数が実行されて、一定時間が経つと元のリソースにリリースされてしまう。関数インスタンスが消失される前に再実行されるとコンテナが再利用されるので実行時間が短くなるが、一度実行されてからしばらく時間が経った後に再実行されるケースでは、リクエストが来てから都度コンテナが作成され、ランタイムの起動や初期化が行われた後に関数の実行があるため、処理の時間が長くなるという課題がある。これを一般的にコールドスタートと呼ぶ。

 関数インスタンスがコールド状態になるまでの時間は決まっていないため、低いレイテンシーで処理を実行するために、特に処理をするものがなくても関数を定期的に実行するようなことが行われていた。しかし2019年リリースされたProvisioned Concurrencyという機能では、コンテナのランタイムを事前に立ち上げ、コールドスタートを確実に避けることができるようになった。

 このようなサービスは、Webやモバイル、IoTなどのレスポンスタイムが重要な処理では役に立つ。しかし、実際にはすべての処理でProvisioned Concurrencyを利用する必要はなく、例えば、キューに溜まっている処理の実行や、データベース上のオブジェクトに対する更新処理にはメリットが少ない。

 同社のデータによると、関数の57%において、設定されたProvisioned Concurrencyの80%未満しか使用していない一方、関数の43%はProvisioned Concurrencyを適切に使用していることが分かった。

Lambda関数の多くでProvisioned Concurrencyを過剰利用
Lambda関数の多くでProvisioned Concurrencyを過剰利用

サーバレスのデプロイツールとして人気のServerless Framework

 Serverless Frameworkは、サーバレスアプリケーションのデプロイや管理を容易にするツールとして、日本でも広く利用されている。

 同社の調査では、AWS CloudFormationでサーバーレスリソースを管理している組織の90%以上でServerless Frameworkが使用されていることが分かった。

Pythonは最も人気のあるLambdaランタイム

 Lanbdaは2018年以降、Node.js、Python、Java、Go、.NET、Rubyの6種類のランタイムのサポートを提供している。

 Lambdaユーザーの間では、従来よりPythonとNode.jsの人気が高く、両者を合せて全体の90%を占めている。そのうち58%がPythonで、これは前年比11%増だった。Node.jsは前年比8%減だったことから、人気がPythonに集中していることが分かる。

Pythonは最も人気のあるLambdaランタイム
Pythonは最も人気のあるLambdaランタイム

 環境の規模別に見ると、小規模なAWS環境ではNode.jsがPythonを上回っているが、規模が大きくなるに従ってPythonの割合が増えている。処理の種別で見たときには、機械学習のワークフローのような重い処理にはJavaが使われる傾向にあることが分かった。また、iOSアプリ開発に使われるSwiftも、メモリフットポイントが低く、高パフォーマンスかつ起動時間が短いという特徴があり、サーバレスアーキテクチャに最適であると注目されている。

大規模な環境ほどPythonが主流
大規模な環境ほどPythonが主流

サーバレスのベストプラクティス

 最後に守屋氏は、Datadogが考えるサーバレスのベストプラクティスを3つ紹介した。

 第1に、サーバレス関数をエンドツーエンドで監視すること。サーバレス関数のインシデント対応や診断を簡素化していくために、サービス毎、顧客毎、エラーコード毎といった形でタグのような仕組みでフィルタリングをすることで、容易に問題を特定することが重要になっている。なぜなら、処理が複数のコンポーネントにまたがり、異常箇所の特定や相関分析をすぐ実行する必要があるからである。

 また、常に新しい技術を取り込んでいく環境は、予測していたエラーだけが起こるとは限らない。機械学習を活用した異常値の検出や外れ値、予測モニターを活用して、エンドツーエンドで監視をすることが重要になる。

 第2に、サーバレスアプリケーションを一元的に可視化・集約し全体像を把握できること。企業が用いるテクノロジースタックはサーバレスだけではなく、他のテクノロジーも用いられている。サーバレスだけでなく、APIゲートウェイやキュー、データベースなどさまざまに含む、アーキテクチャ全体の健全性を1か所で可視化できることが重要になる。

 第3に、オーバーヘッドを増やすことなくビジネスメトリクスを追跡できること。ビジネスメトリクスを含むダッシュボードを作ると、開発者、運用者だけでなく、ビジネスユーザーも含んださまざまなステークホルダー間で共有できる情報源となる。これを使うことで、チーム間のサイロやコミュニケーションコストを削減し、迅速な新機能のリリースや、トラブルシューティングに寄与できる。

 なお、Datadogのサーバレス調査結果に関しては以下のページでも紹介されている。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine Press連載記事一覧

もっと読む

この記事の著者

近藤 佑子(編集部)(コンドウ ユウコ)

株式会社翔泳社 CodeZine編集部 編集長、Developers Summit オーガナイザー。1986年岡山県生まれ。京都大学工学部建築学科、東京大学工学系研究科建築学専攻修士課程修了。フリーランスを経て2014年株式会社翔泳社に入社。ソフトウェア開発者向けWebメディア「CodeZine」の編集・企画・運営に携わる。2018年、副編集長に就任。2017年より、ソフトウェア開発者向けカンファレンス「Developers...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/14791 2021/09/07 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング