re:Invent 2024: AWSがServerlessとContainersの10年を振り返る
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Celebrating 10 years of pioneering serverless and containers (SVS211)
この動画では、AWSのServerlessとContainersの10周年を記念したセッションの内容が紹介されています。AWS LambdaやAWS Fargateなどのサービスを通じて、インフラ管理の複雑さを抽象化し、開発者がビジネスロジックに集中できる環境を実現してきた10年間の歩みが語られます。毎月数十兆件のLambdaリクエストを処理する規模感や、Capital Oneでの導入事例では最大80%のコスト削減を実現した具体的な成果も共有されています。また、Generative AIの台頭に伴う流動的なリソース需要に対して、Serverlessが最適なソリューションとなることや、今後10年間もAWS Well-Architectedの基本原則を守りながら開発者体験の向上を目指していく展望が示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのServerlessとContainers：10年の進化と基本原則
皆様、こんにちは。この遅い時間帯にお集まりいただき、ありがとうございます。AWSのServerlessとContainersの10周年を祝う本日のセッションを、大変嬉しく思います。私はAWSのDirector of Serverless ComputeのNick Coultです。後ほど、同僚でDirector of LambdaのUsman Khalidが登壇する予定です。そして、Capital OneのCatherine McGarveyから、Serverlessの活用についての素晴らしい事例をご紹介いただきます。皆様とご一緒できることを大変楽しみにしております。
本日の議論で最も覚えていただきたいのは、現代における「スピード」という概念です。世の中のあらゆる変化を考えたとき、ビジネスや企業を運営している方々は、その変化に適応する準備が必要です。世界で起こる変化により素早く対応できれば、成功の可能性も高まります。これこそがServerlessの核となるミッションです。アイデアから本番環境までの移行をより迅速にすることで、皆様の成功をサポートすることです。このコアとなる考え方は、本日のプレゼンテーション全体を通して貫かれています。
Serverlessという言葉は、すでに10年の歴史があり、皆様もよくご存じかと思います。今日は、私たちがServerlessをどのように捉えているのか、そのメンタルモデルについてお話ししたいと思います。これは皆様のServerlessの取り組みを考える上で参考になるはずです。クラウドで動作するソフトウェアについて考えると、アプリケーションを実際に動作させるために必要な要素が階層的に存在します。その階層には物理的なインフラも含まれますが、クラウドで実行する場合は私たちがそれを管理します。Serverlessでは、より上位のレベルに集中していただき、下位レベルに時間を費やす必要がないようにすることで、皆様の開発スピードを向上させます。
この文脈でよく使用する用語の一つが、「差別化されていない重労働」または「差別化されていない運用タスク」です。ここでいう「差別化されていない」とは、実際にその作業が皆様のビジネスに独自の価値を付加しているかどうかという観点です。もし付加していないのであれば、それは差別化されていないということになり、なぜその作業に時間を費やす必要があるのか、考え直す必要があります。Serverlessでは、スタックの下位レベルにあるものすべてを私たちが管理することで、この差別化されていない重労働を取り除きます。これにより、皆様は理想的には最上位レベル、つまりビジネスロジックに専念できるようになります。私たちがその他すべてを担当する、これこそがServerlessの本質です。
本日は、Serverlessのすべてについてお話しするわけではありません。Serverlessの傘下には、コンピューティング、データベース、その他多くのサービスが含まれています。今日は特にServerlessコンピューティングに焦点を当てます。具体的には、オリジナルのServerlessコンピューティングサービスであるAWS Lambda、そしてコンテナモデルに重点を置いたAWS FargateとAmazon ECSについてお話しします。また、ServerlessイベントバスであるAmazon EventBridgeやワークフローを実行できるAWS Step Functionsとの連携についても触れていきます。
AWS LambdaとFargateの革新：10年間のイノベーションと成果
私が申し上げたように、Lambdaがサーバーレスの先駆けとなりました。2014年に、私たちはAWS Lambdaをプレビューとして発表し、同時にAmazon ECSもプレビューとしてローンチしました。それ以来、数多くのイノベーションを実現してきましたが、このスライドではその一部をご紹介しています。この10年間で何百もの新機能をリリースしてきましたが、お客様がより迅速に開発を進められるよう、様々な取り組みを行ってきました。これらのイノベーションの多くは、ストレージ機能、コンピューティング機能、より優れた可観測性ツール、そして開発者体験の向上に焦点を当てたものでした。このリストを見ていただくと、その大部分がお客様との対話から生まれたものだということがわかります。私たちはカスタマーオブセッションとワーキングバックワードについて話しますが、それは実際には、re:Inventなどの場でお客様と対話を重ねることを意味します。お客様が抱える問題や課題について伺い、開発の速度を妨げている要因を把握し、それらの解決策を構築していくのです。このリストにある項目のほとんどは、そういった対話から生まれたものであり、今週のre:Inventでも皆様との対話を続けています。まだ終わりではありません - サーバーレスにとってはまだDay Oneなのです。10年が経ち、多くのことを成し遂げましたが、これからもさらに多くのことが控えており、最近発表した新機能についても本日ご紹介する予定です。10年前に私たちはAWS Lambdaを発表し、
現在では、あらゆる規模のお客様がLambdaを利用しています。これらの数字をご紹介したいと思います - 毎月数十兆件のLambdaリクエストが処理されているという、規模的に驚異的な数字です。この数字はあまりにも大きすぎて理解するのが難しいかもしれません。ほとんどのお客様は毎月数十兆回のLambda呼び出しには到達しないでしょうが、たとえ小規模なお客様であっても、これらの統計から理解していただきたいのは、私たちがこの規模でサービスを運用できるようになるまでに得た全ての経験から恩恵を受けることができるという点です。
私たちにはよく使う言葉があります：「経験値には圧縮アルゴリズムがない」というものです。これは、いくつかの教訓は実際に経験して学ぶしかないということを意味します。過去10年間で、このような規模のサービスを安全に、高い回復力と可用性、そしてパフォーマンスを持って運用する方法について、数多くの教訓を学んできました。AWSでサーバーレスを採用すると、私たちが皆様に代わって苦労して得てきた10年分の教訓の恩恵を受けることができます。そしてその恩恵を得るために必要なのは、サービスを使い始めることだけなのです。
さて、サーバーレスの導入、サーバーレスコンピューティング、そしてサーバーレススタックについて話してきました。 ここでサーバーレスの4つの核となる原則について簡単にまとめたいと思います。私が最初の2つについて説明し、その後Usmanが残りについて説明します。その過程で、ポートフォリオ内のいくつかのサービスについて詳しく説明し、最近のリリースについても触れていきます。
Serverlessの4つの核となる原則：抽象化からパフォーマンスまで
第一の原則は、インフラストラクチャ管理の複雑さを抽象化することです。 これは具体的にどういう意味でしょうか？抽象化とは、多くの要素を新しい概念や構成要素としてまとめることです。AWS Lambdaを発表した時、私たちはコードを実行するための全く新しい抽象化を導入しました。これはLambda以前には存在しなかったものです - 関数の形でコードを書いて、そのままクラウドで実行できるという考え方です。サーバーもクラスターもネットワーク設定も必要なく、コードを書いてから実行するまでの間に何も介在しません。
あれから10年が経ちました。Lambdaユーザーの方々にとってはおなじみの概念だと思いますが、2014年当時、サーバーなしでコードを実行できるという考え方がいかに画期的だったかを強調してもしすぎることはありません。これは複雑さを取り除く新しい抽象化でした。その結果、開発者の俊敏性が向上しました。なぜなら、アイデアを試してみたい開発者が、どのインスタンスで実行するか、クラスターをどう作るか、どうやってスケールさせるかを考える必要がなくなったからです。コードを書いて、言語ランタイムを選んで、実行するだけでよくなったのです。
アイデアから本番環境までの道のりが大幅に簡素化されました。また、私たちがスケーリングを管理しているため、パフォーマンス面でもメリットがあります。毎月数十兆回のLambda呼び出しを処理している私たちは、非常に素早くスケールアップする方法を知っています。スケーリングについて考える必要はありません。関数を呼び出すだけで、必要なだけ実行されます。セキュリティも、あまり目立たないかもしれませんが、もう一つの利点です。Lambda関数を使用し、Java、.NET、Pythonなどでコードを書く場合、私たちが言語ランタイムの脆弱性パッチ適用を管理します。
脆弱性が公開された場合、そのランタイム言語を使用するすべての関数が、パッチ適用済みのバージョンで実行されるようにし、脆弱性にさらされないようにします。大したことに聞こえないかもしれませんが、これがないと、脆弱性にさらされるか - これは本当に避けたいことです - あるいはアップデートを確実に行うための作業が必要になります。開発者であるあなたがやらなくても、セキュリティチームが正しいバージョンの言語を使用していないと指摘してくるかもしれません。Lambdaではそのような作業は一切必要ありません。やるべき作業が減るため、俊敏性が向上します。また、組み込みのスケーリングと従量課金モデルにより、非常に低コストで実証実験を行い、必要に応じてスケールアップできるためコスト効率も向上します。
LambdaとLambda関数というこの抽象化により、市場投入までの俊敏性とスピードの方程式が劇的に変化しました。Lambdaが導入された頃、Containerも本当に普及し始めていました。
Containerが登場する前の世界を覚えている方々は、「自分のラップトップでは動くのに、なぜサーバーでは動かないんだ？」という一般的な問題を覚えているでしょう。Containerはすべての依存関係を一貫した方法でパッケージ化し、一貫した実行環境を提供することでこの問題を解決しました。Containerはソフトウェアを実行する非常に人気のある方法となりましたが、Container自体では十分ではありません - 多くのホストにわたって多数のContainerを同時に実行する管理方法が必要です。Amazon ECSは、導入時にこの問題を解決し、関数モデルの代わりに低レベルのContainerモデルを使用して、Lambdaと同様のメリットを提供しました。
コンテナの状況を大きく変えたのは、 AWS Fargateの導入でした。Fargateはコンテナ向けのサーバーレスコンピューティングエンジンです。Fargateについて顧客が特に興味深く感じているのは、サーバーのような感覚 - コンテナを実行してホストを得て、そのコンテナがLinuxカーネルで動作し、通常のマシンでできることはほぼ何でもできる - を得られながら、サーバーの管理が不要という点です。クラスターのスケーリングやOSのパッチ適用を行う必要がありません。サーバーレスの利点と従来のコンテナプログラミングモデルを組み合わせており、実際にホストではなくコンテナに対して課金されます。
これは2024年に行った大規模なローンチの一例で、 FargateとAmazon ECSに関するものです。これまでの年月をかけて、サーバーレス上でより速くアプリケーションを構築しやすくするための改善に投資してきたことは既に触れました。実際のアプリケーションを構築するには、コードだけでは不十分で、ストレージやデータベース、ネットワークが必要です。2024年初頭、Amazon Elastic Block Storeとの統合をローンチしました。これまでは、EBSボリュームをEC2インスタンスにアタッチし、そのインスタンス上で動作するコンテナでそのEBSボリュームを使用することしかできませんでしたが、それでもインスタンスとボリュームをコンテナとは別に管理する必要がありました。私たちは、ホストやボリュームの管理について心配する必要をなくしたいと考え、ECSでそれらのボリュームを直接使用できるインターフェースを提供しました。
私が話したい2つ目の原則は、 コンポーザビリティとコード量の削減です。FargateやLambda、そしてAmazon EventBridgeやAWS Step Functionsについても、同様の抽象化を導入しています。これらの抽象化された構成要素を組み合わせてアプリケーションを作成できることが重要です。サーバーレスを使用すると、実際にコード量を減らすことができます。
例えば、キューを持ち、そのキューから取り出したものを処理したい場合を考えてみましょう。コードをモノリスとして書く従来の世界では、キューと、そのキューの処理エンジンを持つことはできますが、キューを自分で管理するコードを書くか、ライブラリを使用して、キューを処理するのに十分なメモリがマシンにあることを確認する必要があります。サーバーレスでは、 Amazon SQSキューとそのキュー用のLambdaハンドラーを組み合わせるだけで、キューエントリの処理コードを正しく書くことだけに集中できます。
このプロセスをさらに簡単にするため、私たちはAWS Serverless Application Modelを開発しました。これは、関数やキュー、イベントバスなどのプリミティブを組み合わせてサーバーレスアプリケーションを構築することを容易にするオープンソースのフレームワークとツールです。パーツをローカルで構築してテストし、CLIを使用してクラウドに簡単にデプロイし、インフラストラクチャをコードとしてデプロイすることができます。実行中のスタックは、ライブログテイリングで監視できます。AWS Serverless Application Modelは、コンポーネントを組み合わせてコード量を減らす方法の1つです。なぜなら、コンポーズすることで、多くのビジネスロジックをコードではなくアーキテクチャに組み込むことができるからです。
AWS Step Functions は、コンポジションに特化した、もうひとつの強力なサーバーレスサービスです。 Step Functions を使用することで、ワークフローを実行できます。これは基本的にフローチャートやステートマシンのようなもので、ロジックやリトライ、エラー処理を管理し、Amazon ECS や AWS Lambda を含む様々な AWS サービスと連携します。Step Functions のステートマシンは、実際に異なるサーバーレスサービスや AWS サービスを結びつけ、より少ないコードでサーバーレスワークフローを構築することを可能にします。これらのワークフローは非常に強力で、数週間から数ヶ月にわたって実行することができます。re:Invent の直前に、Step Functions の重要な機能強化として、簡素化されたステート管理機能をリリースしました。定義された変数を持つワークフローがある場合、この機能によって変数の伝播やデータ変換が非常に簡単になります。これは開発者体験を大きく向上させる機能強化です。
もちろん、開発者が書くコードは依然として重要で、その重要性を軽視するつもりはありません。AWS はコーディングをより簡単にすることに重点を置いています。開発者向けの Amazon Q を提供しており、Lambda についても IDE 統合の大幅な機能強化を行いました。Lambda コンソールでは、VS Code を使用して Lambda 関数を記述できるようになりました。また、Amazon Q 統合やトラブルシューティングの提案機能を備えたローカル IDE 統合も提供しています。VS Code ユーザーの方は、ぜひ試してみることをお勧めします。開発者体験は私たちにとって非常に重要であり、さらなる改善を計画しています。
Serverlessの実践：可用性、セキュリティ、パフォーマンスの向上
それでは、残りの2つのサーバーレス原則と最近のリリースについて説明するため、同僚の Usman Khalid に引き継ぎたいと思います。ありがとうございました。皆さん、こんにちは。Nick、ありがとうございます。Lambda の General Manager を務める Usman Khalid です。AWS で11年以上働いており、サーバーレスチームに携わってきました。AWS Step Functions と Amazon EventBridge のローチに関わり、その前は Lambda を支え、コンテナ革命が起こるまで最も柔軟なアプリケーション構築方法だった EC2 Auto Scaling を担当していました。
Nick はインフラストラクチャの抽象化、コードの削減、そしてアーキテクチャについて触れました。サーバーレスプログラミングで高速性を実現できる秘訣のひとつは、最初から拡張性と統合の容易さを考慮して設計されたアーキテクチャを構築・活用できることです。これにより、現在の要件や予想される課題に対応できるだけでなく、将来の予期せぬ課題にも対応できる体制を整えることができます。これはアーキテクチャパターンとその構成要素から始まります。Lambda や Step Functions といった基本的な構成要素があります。その他には、API や API Gateway があり、そこで API を定義し、Lambda 関数やマイクロサービスをメッセージやイベントを通じて接続します。オーケストレーションが必要な場合や、コンポーネントを連携させたり、まとめて失敗させたりする必要がある場合は、Step Functions のようなワークフローを使用します。この組み合わせ可能性が拡張性につながり、サーバーレスアーキテクチャを構築する最も拡張性の高い方法のひとつが、イベント駆動アーキテクチャです。
この形のアーキテクチャは、進化的な性質を持つため、お客様から大きな関心を集め、成長を遂げています。プロデューサーがコンシューマーと直接やり取りする必要がないからです。私は、AWS 上でイベント駆動アーキテクチャを簡単に構築できるように特別に設計されたサービスである Amazon EventBridge のローンチチームに参加する機会に恵まれました。EventBridge には、多数のプロデューサーと多数のコンシューマーを接続できるイベントバス、1対1の接続を可能にするパイプ、イベントを追跡するためのスキーマレジストリなど、様々な機能があります。これらの機能には全て、イベント駆動アーキテクチャを簡単に構築できるよう AWS のベストプラクティスが組み込まれています。
これらは非同期アーキテクチャであり、トレードオフが存在します。これらのアーキテクチャの管理・運用を容易にする素晴らしい新機能についてお話しします。拡張性と進化的アーキテクチャの力は、アイデアを最初に本番環境に移行する際のスピードだけでなく、ビジネスやアイデアを発展させていく過程でも、ローンチ後も継続的に素早く動けるようお客様をサポートします。 EventBridgeの役割は、イベントをルールにマッチングさせ、APIを呼び出すことです - コンシューマーは常にAPIとなります。開発者がイベント駆動アーキテクチャを考える際、マイクロサービス用のAPIがないことを心配することがありますが、実際にEventBridgeが行っているのは、イベントをそれをリッスンしているコンシューマーにマッチングさせ、APIを呼び出すことです。
これまで、APIはAWSサービスであったり、Salesforce、Zendesk、PagerDutyなどのSaaS APIでした。嬉しいことに、たった3日前に、AWS PrivateLink のリソースエンドポイントを活用したStep FunctionsとEventBridgeでのプライベートAPIのサポートを発表しました。この機能により、VPC内のAPI - インターネットに公開していないマイクロサービスや、オンプレミスにあるAPIを呼び出すことが可能になりました。ここ数年、お客様は意外にもイベント駆動アーキテクチャをモダナイゼーションに活用してきました。メインフレームアプリケーションを持つお客様が、Stranglerパターンとイベント駆動アーキテクチャを使用して、機能を一つずつマイクロサービスに分解し、それらをイベントでトリガーする方法を採用している例を見てきました。
AWS Lambdaでは、APIやマイクロサービスを設計する際にネットワークについてあまり考える必要のない高次の抽象化が提供されています。しかし、コンテナベースのアプリケーションでは、リクエストを送信したいコンテナのDNS名とポートを把握する必要があります。数年前、私たちはAmazon ECS Service Connectをローンチしました。これにより、他のサービスやアプリケーションコードが呼び出せる、使いやすいアプリケーション名がサービスに提供されます。同じクラスター内で相互に通信するサービスに対して、優れたヘルスチェック、リトライ、モニタリング機能が提供されます。お客様は、コンテナ上でもアーキテクチャの接続と構成に関する余分な作業が不要になったことを高く評価してくださいました。
数週間前、私たちはAmazon ECSをAmazon VPC Latticeとネイティブに統合する機能を追加しました。これにより、単一のクラスター内のサービス接続だけでなく、複数のクラスターやVPCにまたがるサービスの通信と接続が可能になりました。VPC Latticeのターゲットグループを使用することで、ネットワーキングを適切に設定するためにApplication Load Balancerを中間に配置する必要がなくなりました。これはアーキテクチャの大幅な簡素化であり、管理すべき要素が減少したことを意味します。 以上がアーキテクチャの拡張性と進化的アーキテクチャに関する内容でした。次に、人々の迅速な行動を支援する4番目の原則についてお話ししたいと思います。お客様との関係においても、アプリケーションの可用性、セキュリティ、パフォーマンスの維持は共有責任です。Nickが言及したように、過去数年間で蓄積された膨大な経験により、これらの製品は設計の段階から、より多くの責任を担うようになっています。
お客様にも依然として責任はありますが、管理すべきタスクは大幅に減少しています。ソフトウェアエンジニアがソフトウェアを開発する際、通常、コーディング自体が最も時間がかかるわけではありません。スケーリング、テスト、パフォーマンスの最適化、運用準備とセキュリティの確保に、より多くの時間がかかるのが一般的です。サービスアプリケーションを使用することで、このプロセスは要件が少なくなり、より迅速になります。
EventBridge自体や、EventBridgeの多くの部分が、現在LambdaやFargateで動作していることをお伝えしたいと思います。小規模なエンジニアチームが、自分たちの技術力を信じることで、この1年間で大きなイノベーションを実現できました。それでは、詳しく見ていきましょう。まず可用性についてですが、Nickが説明した私たちのサービスは、すべてリージョンの境界を尊重しています。クロスリージョンの依存関係はなく、Availability Zoneに影響が出ても耐えられるように設計されています。デフォルトでマルチAZ構成となっており、お客様に代わってキャパシティを確保することで、AZ間でのキャパシティプランニングが不要になっています。
セルという概念について強調したいと思います。この10年間、私たちはセルラーアーキテクチャに注力してきました。開発者がセルラーアーキテクチャを考えるとき、多くの場合、影響範囲の制限を思い浮かべます。しかし、セルラーアーキテクチャが本当に私たちの役に立ったのは、月間数十兆回という呼び出しを実現できた点です。us-east-1全体のサイズではなく、最大セルサイズでソフトウェアをテストできるため、展開時にソフトウェアの信頼性を維持できます。つまり、変更による影響範囲は単一のリージョンよりもはるかに限定的になります。
セキュリティについて、まず基盤から説明すると、私たちはFirecrackerというマイクロVMを発明しました。これはオープンソース技術です。6年後の今となっては、まるでSFのような話に聞こえるかもしれません。これらの非常に小さなマイクロVMは1秒未満で起動し、仮想マシンとしての完全なセキュリティ境界を持っています。これらは、セキュリティが強化されたことで知られるAWS Nitro Systemを搭載したEC2インスタンス上で動作します。オペレーターは一切お客様のコードやデータにアクセスできません - これは完全に不可能です。システムに流入するデータは、保管時も転送時も暗号化され、オプションでお客様独自の鍵を使用できます。すべてのアーティファクトとリソースにAWS KMS暗号化をサポートし、アプリケーションレベルではコード署名をサポートして、提供されたコードが確実に実行されるようにし、リソースアクセスに対して詳細な権限設定が可能です。
セキュリティ面での大きな利点は、攻撃者が狙うことのできる永続的なボックスが存在しないことです。マイクロVMと基盤となるEC2インスタンスを常に循環させています。インフラストラクチャのフットプリントはステルス機のようにほとんど無視できるレベルです。とはいえ、アプリケーション内で何が起きているのかの可視性を提供したくないというわけではありません。最近、CloudWatchでの初のアプリケーションパフォーマンスソフトウェアとして、Lambdaのアプリケーションシグナルを発表しました。このソフトウェアでは、開発者がコードを計装する必要がなく、すぐにOpenTelemetryスタンダード、メトリクス、ログ、トレースを使用してアーキテクチャの動作を理解できます。
エラー、リクエスト量、レイテンシー、障害に関するメトリクスがすべて深く統合されています。単一のエラーをクリックするだけで、どのLambda関数やアーキテクチャのどの部分でエラーが発生しているか、あるいは顧客レベルの障害に寄与しているかを確認できます。数秒以内にアプリケーションログを詳しく調べることができます。最近のリリースでお気づきの方もいるかもしれませんが、Amazon Qで生成AIツールを使用して、クォータやシステムの変更を自動的に分析できるようになりました。これについては非常に期待しており、お客様からのフィードバックをお待ちしています。また、Amazon ECSの可観測性のためにContainer Insightsもリリースしました。このリリースでは、Lambdaの大規模ユーザーであるAmazonとして、私たちが監視しているメトリクスなど、自社のベストプラクティスをパッケージ化しています。
これを踏まえて、私たちはECSのお客様向けに、アプリケーションの運用と高可用性の提供に使用している独自のメトリクスもパッケージ化しました。これにより、お客様自身がベストプラクティスを見つけ出す必要がなくなります。クラスターレベルやアカウントレベルでのモニタリングから始めて、最終的には組織全体を網羅する単一の管理画面にまで拡張できます。組織内で稼働しているすべてのContainerサービスとそのパフォーマンスを確認し、詳細な性能分析まで行うことができます。
私は2018年にEC2 Predictive Auto Scalingを立ち上げたチームの一員でしたので、re:InventでECS向けのPredictive Auto Scalingを発表できたことを嬉しく思います。これはGenerative AIではなく機械学習を使用して、ALBに入ってくるリクエスト数/秒などの負荷メトリクスを分析します。Step ScalingポリシーやTarget Trackingポリシーで使用できるスケーリングメトリクスと履歴負荷を検証し、最も一般的なメトリクスであるCPUを基に、将来のワークロードに対して必要な最小タスク数を任意の時点で判断します。これはEC2で素晴らしい成果を上げており、ECSサービスとTarget-basedサービスにも提供できることを嬉しく思います。予測に基づいて事前にスケーリングを行うわけですが、予測というのは「より間違いが少なくなる」ということです。これらの機能はReactive Scalingポリシーとも完璧に連携するので、予測されていない突発的な負荷が発生した場合でも、必要なインスタンスを起動してキャッチアップできます。
SnapStartは2022年にリリースしたもので、パフォーマンス、スケーリング、可用性に関する共有責任の多くを開発者から引き受けようとする私たちの取り組みの一環です。これはJavaベースのFunctionでSnapStartを使用してコールドスタート時間を短縮するためのチェックボックス機能です。コールドスタートは、Lambda Functionの新しい呼び出しや新しい実行環境が起動される際に発生しますが、SnapStartを使用することで、そのリクエストを10倍速く、多くの場合1秒未満のレイテンシーで処理できます。
1週間前に、SnapStartのサポートをPythonと.NETランタイムにも拡張したことを発表できることを嬉しく思います。SnapStartで行っていることを説明しますと、Functionが提供されると、初期化を行い、初期化コードを使用し、使用するすべてのライブラリをロードして、メモリ全体のスナップショットを取ります。次回、コールドスタートと新しい実行環境が必要なリクエストが来た時に、そのスナップショットで環境を復元するため、コードができるだけ早く受信リクエストの処理準備が整います。
最後に、パフォーマンスについて触れると、お客様からApache Kafkaについて多くのフィードバックをいただいています。EventBridgeについて話しましたが、Kafkaもまた、お客様がEvent-drivenアーキテクチャやデータストリーミングを構築する際の人気の高い方法です。お客様はLambdaをより多く使用したいと考えています。なぜなら、Lambda Functionは本質的にイベントを処理するために設計されたイベントハンドラーだからです。しかし、Lambdaは非常に速くスケールするため、Kafkaコードがそのスケーリングに対応できない問題がありました。私たちはこの課題に取り組み、KafkaのためのLambda Provisioned Modeをリリースしました。お客様は、Provisionedポーラーの最小数と最大数を指定するだけでよく、以前のKafka統合と比べて10倍速くスケールできます。さらに重要なことは、これらのポーラーをKafkaブローカーのパフォーマンスに影響を与えないようにスケールすることで、SLAを確実に達成できることです。
Capital Oneのサーバーレス導入事例：戦略と成果
お客様と言えば、Capital Oneの取り組みについて、Catherine McGarveyにバトンを渡せることを嬉しく思います。Catherine、お願いします。皆様、こんにちは。ここに立てて光栄です。NickとImanに感謝申し上げます。彼らが共有してくださった内容は本当に素晴らしいですね。私たちがその恩恵を受けられることを嬉しく思います。私はCatherine McGarveyで、SVP of Engineeringを務めており、Enterprise Platform Techチームの一員として、Capital Oneの何千人もの開発者をサポートする素晴らしいチームに所属しています。私たちの取り組みと、その過程で得た教訓についてお話しさせていただきます。
私たちのServerlessへの取り組みは2017年に始まりました。当初は、モノリスの分解、標準化の推進、新機能のリリースまでの時間短縮に重点を置いていました。それから数年後の2021年初頭、アプリケーション開発のアプローチを近代化し、インフラストラクチャからアプリケーション中心のサービスへと移行して、インフラ管理から解放されるため、Serverlessコンピューティングソリューションの採用を検討し始めました。このアプローチを取ると、ビジネス上のメリットが明確になってきます。開発者がインフラではなく、ビジネスとして注力したい領域固有の課題に時間を費やせるようになることでイノベーションが加速し、アプリケーションのコストと複雑さが削減され、管理すべきコードが減少し、パフォーマンス、信頼性、品質が向上します。これらはすべて、インフラ管理から解放されることで得られる副次的な効果なのです。
独自のものを構築しようとするのではなく、AWSが提供する既存の抽象化レイヤーを活用することで、アプリケーション開発チームはSLOの設定や監視、環境設定などに費やす時間を減らし、アプリケーションそのものにより多くの時間を割けるようになりました。必要な賛同を得るために、いくつかのガイドラインを設定しました。まず「Functions First」として、アプリケーション構築のデフォルトとしてAWS Lambdaまたは関数を優先的に使用することを掲げました。これはアプリケーション設計の考え方における大きな転換でした。その他の部分ではContainerを継続的に検討し、可能な限り上位のスタックへと移行を進め、可能な場合はBackend as a Serviceを使用し、Event-drivenアーキテクチャを適切な場面で追求しました。
これらのフレームワークはシンプルさにつながります。そのため、標準化とその共有が重要な要素となり、事前に構築されたコンポーネントを活用し、生産性向上のメリットを最重要視しました。このような取り組みを行う際には、その成果と変化を実感することが大切です。Lambdaをデフォルトとして確立し、それ以外を選択する場合は正当な理由が必要とすることで、より多くの採用を促進しました。つまり、デフォルトはLambdaとし、より低レベルの抽象化レイヤーを使用したい場合は、その理由を説明する必要があるとしたのです。これにより、自然とスタックの上位への移行が促され、デフォルトとして設定することで適切な行動を促すことができました。
この取り組みは、開発者だけでなく、より広い範囲での賛同が必要だと認識していました。Capital Oneには独自の戦略アプローチがあり、このアプローチを共有する際には、すべてのビジネスパートナーの賛同を得て、この変更の価値を全員が理解することが重要でした。この過程で、技術的な知識が少ない人々でもLambdaの使用目的について質問できるようになり、それが健全なチェック＆バランスを生み出しました。これを促進するために、内省とフィードバックに注目しました。その一環として、異なるレベルの成熟度評価を作成しました：レベル0はServerlessなし、レベル1は特定の部分でのアドホックなServerless利用、機会主義的なレベルは人々がその機会について考え始める段階、体系的なレベルはServerlessが設計とアーキテクチャのデフォルトの選択肢となる段階、そして最適化されたレベルはすべてのユースケースでServerlessが優先的な選択肢となる段階です。
私たちは評価とフィードバックを行い、必要に応じてチームに探求を促しながら、対話を継続していきました。この過程で、リアルタイム処理、データ処理と変換、統合作業、ワークフローとイベント処理、API、機械学習、Backend as a Serviceなど、いくつかのアーキテクチャパターンを特定しました。既存のパターンを把握し続け、アーキテクチャがこのような形であるべきかを検討し始め、そのフィードバックをチーム間で共有しました。これを実現するために、リリースパイプラインも簡素化しました。
Serverlessアーキテクチャを採用し、これらの標準化されたパターンのいずれかを使用する場合、ロードバランサーはこのような構成にすべき、他のサービスはこのような構成にすべき、というデフォルトの推奨事項を提示しました。ゼロから始めるのではなく、あらかじめ構築されたデプロイメントパイプラインを提供したのです。私たちのサービスイニシアチブは、AWS Lambdaを活用することで、Capital One全体のインフラストラクチャ管理を根本的に変革しました。私たちはLeft Shiftを実践してチームを上位レイヤーに押し上げましたが、必要に応じてECS Fargateへの移行も許容しました。クラウドネイティブなコンピュート管理を効率化し、生産性、制御、パフォーマンスの面で大きな改善を達成しました。
チームがインフラストラクチャの負担を軽減しながら、アプリケーション開発に集中できるようになりました。これらのクラウドネイティブサービスは、効率性とパフォーマンスを明確に向上させ、いくつかの利点をもたらしました。私たちが運用している規模では、ランタイムエンジンのコストが最大40%削減されたことは非常に大きな成果です。コスト、時間、開発、ランタイムの最適化を考慮すると、コスト削減は最大80%に達しています。脆弱性の観点からは、スタックを上位に押し上げ、より高度な抽象化レベルを活用することで、場合によっては最大80%の脆弱性を回避できるようになりました。
マネージドインフラストラクチャのアプローチは、開発者が興味の薄い作業を減らし、より楽しめる領域や専門知識を活かせる分野に注力できるようになったため、熱心な採用につながりました。マネージドクラウドネイティブサービスとマネージドデータベースを活用するこのアプローチにより、アプリケーションのスケーラビリティが向上し、運用の複雑さが軽減されました。このアプローチを進める中で、私たちは何を学んだのでしょうか？もしこの道を進むのであれば、小規模から始めることをお勧めします。開発者にServerlessコンピュートの使用がどのようなものかを理解してもらうため、グループ全体に徐々に広がっていく様子を確認できるフレームワークを作成しました。
アーキテクチャを変更する必要がある理由について、時間をかけて説明することを重視しました。単にランタイムを置き換えるのではなく、ユースケース、適切なスタイル、最適化の対象について考える必要があります。この分野での実験を奨励しました。次に注目したのは、ローカル開発ツールの習得です。AWS Serverless Application Modelのようなツールが、デプロイメント前にアプリケーションのテストとデバッグを支援することを確認しました。開発チームの目標は、すべてのLambda関数をローカルで記述し、リアルタイムのフィードバックを得て、迅速な反復を可能にすることです。
最後に、早期の段階での標準化の実装について検討しました。標準を作成する際、開発チームから離れすぎていると、標準が抽象的すぎたり、実用的でなかったり、学習の要素を考慮できなくなってしまいます。これには、関数のタイムアウト、メモリ設定、価格モデルの理解、ログやモニタリングツールの効果的な使用が含まれます。私たちは、改善点の共有に重点を置き、エンジニアがCloudWatchログ、保持ポリシー、適切なバージョンのSDKの使用、アップデートの確認といったAWS特有のプラクティスを理解できるようにしています。大規模な開発者ベースでは、変更の周知や導入状況の追跡に労力がかかりますが、アップデートを受けずに管理を引き受けるよりはましです。それでは、Nickにバトンを渡します。
Serverlessの多様な活用事例：DoorDashからGenerative AIまで
ありがとうございます。私は本当にCapital Oneのこのストーリーが大好きです。カスタマーストーリーは私の心を動かします。皆様が目指す目標の達成をサポートすることが、私の仕事のモチベーションになっています。
他にもいくつか素晴らしいカスタマーストーリーをご紹介したいと思います。最初の例として、私が特に強調したいのがDoorDashの事例です。アメリカンフットボールのファンの方なら覚えているかもしれませんが、2023年のアメリカンフットボール選手権の際、彼らはTV放送中にプロモーションを実施しました。コンテストだったと思いますが、膨大な数のエントリーを処理する必要があり、AWS Lambdaを使用した革新的なアーキテクチャで、5時間の間に1,000万件のエントリーを処理することができました。特筆すべきは、これが長期間のインフラストラクチャのプロビジョニングや管理が必要な永続的なアプリケーションではなかったことです。イベントのためにスケールアップし、その後ゼロまでスケールダウンしました。これこそがServerlessで実現できることなのです。アプリケーションやスタックを永続的なものとして考える必要はなく、一回限りの使用のために構築し、スケールアップ、スケールダウンして終了することができます。彼らはこのキャンペーンで賞も受賞しました。
United Airlinesも私がよく取り上げる事例の一つです。航空会社というとテクノロジー企業というイメージはないかもしれませんが、航空会社は急速にそうなりつつあります。モバイルアプリなどを通じて優れた顧客体験を提供し、変化する旅行市場の状況に対応する能力は非常に重要です。United AirlinesはモバイルアプリケーションにAWS Fargateを採用し、機能の実装速度を劇的に改善し、以前よりもはるかに迅速に新機能をリリースできるようになりました。このスライドには他にも素晴らしい事例がありますが、詳しくは触れません。ただ、異なる業界のお客様がServerlessを活用して、より迅速な対応を実現している様々な成果を強調したかったのです。
よく受ける質問の一つが、「Serverlessで何が実行できるのか？」「どのようなアプリケーションがServerlessに最適なのか？」「Serverlessで何ができるのか？」というものです。答えは、Serverlessで実行できることは実に幅広いということです。ここでは最も一般的なものをいくつか紹介します。まず一つ目がLegacy App modernizationです。これは具体的に何を意味するのでしょうか？クラウド以前から存在するかもしれない、すべてのコードが一つの巨大なモノリスに含まれているようなコードベースがあるかもしれません。そしてそれをクラウドに移行し、マイクロサービスやイベント駆動型アーキテクチャに分割してモダナイズすることで、アジリティとスケーラビリティのメリットを得たいと考えています。Serverlessはモダナイゼーションに非常に適しています。多くのお客様が、クラウドへの移行時にモダナイゼーションも行い、同時にServerlessを採用しているのを目にします。
Serverlessは、FunctionやContainerにおいてWebアプリケーションでもよく使用されるユースケースです。データ処理も重要な用途の一つです。例えば、画像のリサイズや機械学習ワークロード向けのデータ準備など、処理するデータ量が大きく変動するケースが該当します。一日や一週間の中で、数万から数百万のファイルを処理する時もあれば、まったく処理がない時もあるかもしれません。Serverlessを使用すれば、処理するデータ量に応じて自動的にスケールアップ・ダウンし、常に低レイテンシーを維持できます。そのため、ETLやバッチ処理などのデータ処理に非常に人気があります。
あまり刺激的ではないかもしれませんが、ITオートメーションも非常に有用な用途です。例えば、アカウント内のインスタンスがシャットダウンするたびに、適切な対応を確実に行うために一連のステップを実行したい場合、インスタンスのシャットダウン時に発生するEventBridgeイベントに基づいてLambda関数を起動することができます。これはITオートメーションの簡単な例です。人工知能については、誰もが話題にしており、当然ながらニュースでも頻繁に取り上げられています。特にGenerative AIでは画期的な進展が見られます。しかし、AI/MLアプリケーションを実装する際に必要な作業を見てみると、データ変換やワークフローなど、多くの処理が必要になります。これらはすべてServerlessと相性が良い処理です。そのため、多くのお客様がこのような用途でServerlessを活用しています。次のスライドでもう少し詳しくお話しします。
特にGenerative AIとそれを使用して作成できるアプリケーションやソフトウェアについて考えると、コーディングアシスタントを使用してコードを書くだけでなく、現在私たちが目にしているAgentやBedrock Agentsが実現している機能のようなものも含まれます。このようなアプリケーションを見ると、使用するリソースやインタラクションは、開発者がコードで書く標準的なアプリケーションよりも流動的です。つまり、リソースのニーズとスケーリングは、これまで以上にダイナミックで流動的になるということです。私たちは、Serverlessがこのようなアプリケーションの実行に非常に適していると考えています。
企業全体でGenerative AIをより広く活用していく中で、まだこれらのユースケースでServerlessを使用していない場合は、検討する価値があると思います。これは、ドキュメントを処理してVector Databaseに格納する検索拡張生成（RAG）パイプラインなどでも見られます。このようなワークフローでは、AWS Step Functionsを使用する関数が多く見られ、Generative AIのワークロード全般で活用されています。
Serverlessの未来：変わらぬ原則と進化する技術
よく「Serverlessは10年の歴史がありますが、これからの10年はどうなるのでしょうか？」という質問を受けます。私には水晶玉がありませんので、将来を予測したり、今後10年で何が変わるかを知ることはできません。しかし、何が変わらないかについてはお話しできます。開発者体験がより複雑になることを望む人はいないでしょう。AWS Well-Architectedの基本原則が減ることを望む人もいないでしょう。サービスに対するコントロールがより複雑になることを望む人もいないでしょう。統合機能が減ることを望む人もいないでしょう。
私たちがServerlessで取り組んでいることは、これらの領域に焦点を当てています。今後10年間、皆さんがこれらのことについてより多くの、より良いものを求めていくことは分かっています。そして、私たちはそれを続けていきます。それらを実現する方法や、具体的に使用する技術については、まだ分かりません。物事は変化し、今は誰も考えていない新しい技術が登場するでしょう。そして、私たちはそれらの技術をServerlessで動作するようにしていきます。しかし、基本的な原則は変わりません。これが、今後10年間で何が来て、何が変わるのかと人々に聞かれた時の私の答えです。
以上で終わりにしたいと思います。ご清聴ありがとうございました。ここでQ&Aの時間も設けています。モバイルアプリでセッションのアンケートへのご回答もお忘れなくお願いいたします。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion