Splunkが"Lambda Ready"に：AWSとの新しいパートナーシップを発表

SplunkはAWSとパートナーを組み、新しいAWS Service Readyプログラム「Lambda Ready」に参加します。AWS Lambda Readyの指定を受けることで、Splunkは、サーバーレスアプリケーションを開発、管理、実行するための検証済みのソリューションをお客様に提供できます。Splunkは今後、AWSパートナーネットワーク(APN)の一員として、Lambda関数のオブザーバビリティ(可観測性)と監視に重点を置いた検証済みの統合と実績あるカスタマーサクセスを提供していきます。

企業はLambda関数を導入することで、新しい機能を迅速に提供し、顧客を重視しながらイノベーションを加速できます。サーバーレスアーキテクチャは以下のメリットをもたらします。

• 運用負担の軽減：AWS Lambda上でサーバーレスアプリケーションを運用すれば、永続的なホストやアプリケーションインスタンスを管理する必要がなくなります。インフラは完全に抽象化されるため、チームはアプリケーションコードに集中できます。
• 拡張の効率化：Lambdaプラットフォームでは、負荷に応じて必要なだけの実行環境を配備できます。関数が1インスタンスだけ必要になったときは、その環境が1つだけすばやく用意されます。数百万単位のインスタンスが必要になったときでも、DevOpsチームの手を煩わせることなく環境が効率的に拡張されます。
• コストの削減：Lambda環境の料金体系は、ほぼ完全なクラウド使用量ベースです。料金は、リクエスト数、関数の実行時間、関数の実行に必要なメモリー量によって決まります。

これらのメリットが、あらゆる業界でサーバーレステクノロジーの普及を後押ししています。ガートナー社の予測では、IaaSを導入している企業の90%が2021年までに本番環境でサーバーレスアプリケーションを利用すると見込まれています。また、CNCFの最新調査では、少なくとも41%の企業が現在サーバーレスアプリケーションを利用しています。

サーバーレスがもたらす新たな課題

Lambdaは企業のソフトウェアイノベーションを加速させ、コストを抑制する一方、監視とオブザーバビリティに関する独自の課題をもたらします。

• エージェントベースのアプローチを利用できない。サーバーレスではコードとその実行インフラが切り離されるため、エージェントをインストールしてオブザーバビリティデータを収集および転送することができません。
• データのバッチ処理ができない。バッチ/クエリーアーキテクチャを採用する従来の監視ツールは、ストリーミングデータ分析に対応していないため、サーバーレス環境に適していません。サーバーレス環境で使用すると、データポイントの取りこぼしが発生して分析が不正確になります。
• CloudWatchで一般的な5分間隔でメトリクスを取得するとインサイトを十分なスピードで取得できない。間隔を短くすると、AWSのAPI制限を超過する可能性があります。

コスト拡大とユーザーエクスペリエンス低下に対処するためのリアルタイムの可視化

Lambda関数を呼び出すと、リクエストが新しいコンテナ環境で処理されます。関数が実行されない状態が一定時間続くか、同時リクエストの処理数が増えると、関数を実行するための新しい環境が自動的に起動されます。このとき、ランタイムとコードの初期化によって、一般的にコールドスタートと呼ばれる遅延が生じます。複数のLambda関数を1つのチェーンとして呼び出すとさらに遅延が生じ、結果としてユーザーエクスペリエンスが低下します。実際、Akamai社の調査では、Webサイトの読み込み時間が100ミリ秒遅くなるごとにコンバージョン率が7%下がる傾向があることが明らかになっています。Lambda関数の実行はミリ秒単位で課金されるため、これらの遅延に対処しないとAWSのコストは簡単に膨れ上がります。コストを抑制して円滑なユーザーエクスペリエンスを提供するには、遅延をリアルタイムで可視化することが欠かせません。

リアルタイムのサーバーレスオブザーバビリティ

Splunkソリューションを導入すれば、DevOpsチームは、アプリケーション環境全体のパフォーマンス、利用状況、ボトルネックを簡単に把握できます。アプリケーションが100%サーバーレスであっても、サーバーレスと従来形式が混在していても、クラウドスタック全体をリアルタイムで監視できます。

すべてのサーバーレス関数の一元監視

すべてのサーバーレス関数の主要メトリクスを表示するにようにあらかじめ設定されたダッシュボードで、サーバーレスアーキテクチャのパフォーマンスを包括的に把握できます。検索、フィルタリング、並べ替え機能を使って、エラー、重大な遅延、コールドスタートが発生している関数の詳細をすばやく確認することもできます。使用率、場所、アカウント、ランタイム、リソース、その他のディメンションに基づいて、関数にタグを設定したり関数をグループ分けしたりすることもできます。

簡単なドリルダウンによるパフォーマンスとコストの最適化

開発チームは、コールドスタートを避けるために、プロビジョニングされた同時実行機能を使用できます。関数の同時実行では、起動の遅延が一定である場合にトラフィックが瞬時に急増することがあります。同時実行の量と時間をプロビジョニングして設定すれば、この問題を回避できます。ただし、プロビジョニング分の料金が増すことになるため、プロビジョニングする同時実行数とスピルオーバーの割合を把握することが重要です。Splunkのダッシュボードでは、コールドスタート、同時実行、スロットル、スピルオーバーの状況を細かく確認して、プロビジョニングされていない関数を管理し、遅延を最適化してコストを削減できます。

上の図では、プロビジョニングされた同時実行で、スピルオーバーが高く、使用率が100%に達し、時間のかかるコールドスタートが発生しているため、数を増やして改善する余地があることがわかります。

サービスの可視化、依存関係マッピング、トラブルシューティング

SignalFx Microservices APMでは、サービス(サーバーレス関数、従来のアプリケーション、サードパーティのAPI、データベースの呼び出しなど)間のリアルタイムのデータ交換状況に基づいて自動的に作成されるサービスマップで、サービスとその依存関係を可視化できます。

トランザクションごとにトレースビューで詳細を確認することもできます。SignalFx Microservices APMでは、すべてのサービス間の各トランザクションがNoSampleによる完全忠実なトレーシングによって捕捉されるため、すべてのトレースを詳細に分析できます。

一般的な言語でコードを計測できるオープンソースのトレーシングライブラリや、一般的なフレームワークに対応した自動インストルメンテーションを利用することもできます。

LambdaメトリクスとビジネスKPIのリアルタイムインサイトを提供するラッパー

CloudWatchでは調査できない詳細レベルで関数の呼び出しやエラーを追跡したい場合もあるでしょう。Splunkなら、SignalFxの呼び出しを追加する関数ラッパーを使用して、呼び出し回数、エラー件数、実行時間、コールドスタート回数を取得できます。CloudWatchでのLambdaメトリクスの取得間隔は標準で5分、最短でも1分ですが、このラッパーを使用すれば数秒間隔でリアルタイムのインサイトを取得できます。

現時点で、Node.js、Java、Python、Ruby、Golang、C#のLambdaラッパーが提供されています。SignalFxのリクエストハンドラーには、ラッパーをそのまま使用するものと、コードを手動で計測するものの2種類が用意されています。

ご利用のAWSリージョンでSignalFxがホストする言語固有のLambda Layersを使用すれば、関数のサイズを縮小し、依存関係の管理を効率化して、関数のアップグレードを簡素化することもできます。

さらにラッパーには、コードを計測して重要なカスタムメトリクス(ビジネスKPIなど)を取得するための簡単な仕組みも用意されています。これらのメトリクスを捕捉してSignalFxに送信するための数行のコードを関数に追加するだけで済み、パフォーマンスが低下する心配もありません。

AWS Lambdaのオブザーバビリティを強化

AWSとパートナーを組むことは大変有益であり、このパートナーシップが両社のお客様のサーバーレス導入を加速させるものと期待しています。大規模かつ高度なユースケースで実績をあげ、多くの企業に信頼されているエンタープライズレベルのソリューションを導入すれば、オブザーバビリティに対する投資を将来の成功につなげることができます。サーバーレス監視機能は、SignalFx Infrastructure Monitoringで利用できます。無料トライアル版をご用意しておりますので、ぜひご利用ください。

このブログはこちらの英語ブログの翻訳です。

ブログ関連情報

毎月１回、Splunkブログの更新情報をメールでお届けします。ぜひマンスリー ダイジェスト をこちらからご登録ください！