re:Invent 2025: ElastiCacheがValkeyへの移行でコストを33%削減した経緯
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025-Disagree in Commits:The Performance Improvements That Cut Costs by a Third-OPN309
この動画では、Amazon ElastiCacheのPrincipal EngineerであるMadelyn Olsonが、AWSサービスがオープンソースへの貢献を通じて価格を下げるに至った経緯を解説しています。ElastiCacheは基本的にオープンソースのRedisやMemcachedをそのまま実行するマネージドサービスであり、TLS実装などの機能追加で内部フォークのメンテナンスコストに直面しました。Redis LimitedがBSDライセンスからSSPLへ変更した際、コミュニティはValkeyとしてフォークし、Linux Foundationの下でオープンガバナンスを確立しました。Valkeyではマルチスレッドやメモリ効率改善などの革新が加速し、ElastiCache for ValkeyはRedis版より20-33%安価になりました。皮肉なことに、Redisは現在Valkeyの改善を取り込んでおり、オープンソースの真の価値が実証されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Disagree and Commit：ElastiCacheとオープンソースの旅の始まり
それでは皆さん、Disagree and Commitへようこそ。これからお話しするのは、あるAWSサービスが、オープンソースへの貢献がコミュニティやお客様にとって素晴らしいものだと気づき、その結果として価格を下げることを決定したという物語です。私の名前はMadelyn Olsonです。Amazon ElastiCacheチームのPrincipal Engineerを務めており、今日は私のサービスであるElastiCacheと、オープンソースを通じた私たちの旅について、少し裏側をお見せしたいと思います。そして、皆さんご存知のAWS批評家、Corey Quinnにもご参加いただいています。彼が公平でバランスの取れた経済的視点を提供してくれます。
つまり、Madelynはとても賢くてサービスの内部の複雑な仕組みについて話すので、私はステージで彼女の隣に立って時々ジョークを叫ぶだけ、という丁寧な言い方ですね。私のプログラミング言語は、力技と情熱を組み合わせたものの2つだけが得意です。でも今はロボットをサイバーいじめできるので、山も動きます。私は2011年からValkeyとそのダウンストリームのプロプライエタリフォークであるRedisを使ってきたので、この辺りについては色々と意見があります。
多くの人がCorey Quinnについて警告してくれましたが、彼はほとんど無害だと思います。それでは早速始めましょう。Amazon ElastiCacheについて、そして裏側でどのように見えるのか、サービスを構築するために使用しているサービスやコーディング、プロジェクトの種類についてお話しします。正直なところ、これについて学ぶことが、このトークをやりたいと思った理由の全てです。なぜなら、実際に内部で何が起こっているのか、いつも気になっていたからです。まあ、これは知る良い機会ですね。
それでは、私が最初にサービスに参加した時のAmazon ElastiCacheがどのようなものだったかについてお話しします。お客様としては、VPCを持って私たちのサービスに来ていただくと、キャッシングエンドポイントを提供します。Amazon ElastiCacheは、様々な基盤エンジンを提供するマネージドキャッシングサービスです。つまり、サービスはElastiCacheですが、Redis、Memcached、そして近々Valkeyと互換性のあるエンドポイントを提供しています。
ElastiCacheの内部構造とTLS実装の課題：プロキシからネイティブ統合へ
多くの人は、私たちが内部に非常に複雑なシステムを持っていると思っていますが、実際はとてもシンプルです。 Amazon ElastiCacheでキャッシュクラスターを作成しようとすると、お客様専用のVPCを作成します。 そして、キャッシュノードと呼ばれるEC2インスタンスをいくつか作成します。ここには少しの管理プロセスをインストールします。これらはヘルスチェック、ディスクが正常かどうかの確認、パラメータの更新など、私たちが大好きな退屈で差別化されない重労働の全てを担当しています。
そして、キャッシュエンジンをインストールします。ええ、私がいつも見ていて面白いと思うことの一つは、Availability Zone間でデータが通過するたびに、プロダクトマネージャーが天使の羽を手に入れるか、少なくとも既に持っているヨットに加えて小さなヨットを手に入れるということです。ただし、ElastiCacheのようなもので、レプリケーショントラフィックが課金されない場合は別です。これは多くの場合、クロスAZデータ転送の一部を回避するための素晴らしい方法なんです。なぜそうなっているのかは、神のみぞ知るですが、便利ですし、私たちはそれを活用することができます。
次に、ENIをVPCにアタッチして、クラスターとアプリケーショントラフィックを送信できるようにします。ここで重要なのは、これらのキャッシュエンジンはほとんどの場合、単なるオープンソースエンジンだということです。先ほど申し上げたように、私たちはオープンソースのMemcachedをサポートしています。実際、私たちのMemcachedとオープンソースのMemcachedを区別するのは、おそらく100行程度のコードです。Memcachedはパーミッシブなオープンソースライセンスなので、コードを修正することが許可されており、バグを見つけた場合は報告しています。
さらに、Redisについても同じことが言えます。私たちのサービスのコアインフラストラクチャは、当時のRedisオープンソースをベースにしていましたが、いくつかカスタム変更を加える必要がありました。 それでは、これらの変更の一つをどのように実装したかについてお話しします。お客様から要求されたことの一つは、TLSサポートでした。実際、CTOがステージ上で「すべてを暗号化せよ」と書かれたシャツを着て歩き回っていたんです。そして私は実際にある年、同じシャツの下に括弧書きで「難しい場合を除く」と追加したものを作ったんですが、どうやらそういうことではないようです。
ええ、私たちはTLSを要求しました。暗号化はベストプラクティスです。これはベストプラクティスであり、お客様はコンプライアンスのためだけでなく、社内のセキュリティチームからの要求としても必要としていました。お客様は私たちのところに来て、すべてのトラフィックを暗号化したいと望んでいました。 当時のベストプラクティスは、これは2018年頃のことですが、RedisオープンソースもMemcachedオープンソースもどちらもTLSをサポートしていなかったため、TLSプロキシを使用することでした。つまり、すべてのトラフィックはまずTLSプロキシに送信され、復号化されてから、プレーンテキストで基盤となるキャッシングエンジンに送り返されるわけです。
ええ、常に疑問があります、エンドツーエンドで暗号化されていない、TLSはどこで終端するのか？それは、まあ、一般的にフロアでインフラストラクチャをセットアップすると、だからこそインフラストラクチャが得意な人たちにその差別化されない重労働をオフロードできるのは良かったんです。その通りです。私たちはこれらのTLSプロキシをホスト自体で実行していました。そして、それはキャッシュホストとTLSプロキシ間の実際のトラフィックが暗号化されていることを確認するための良い方法でした。
これらすべてのインフラストラクチャが整っていました。コントロールプレーンもあり、管理プロセスもありました。しかし問題がありました。問題は、CPUの観点から見て非常に高コストで遅かったということです。TLSを全く使わない場合とほぼ同じくらい高コストでした。短期的には、それの方が安上がりです。長期的には、全く逆なんですけどね。でも、まあいいでしょう。だからこそCISOは消耗品として知られているわけです。侵害があったら一人クビにして、新しい人と交代させる。時にはインターンのせいにして逃げ切れることもありますが、最近はそれも難しくなってきています。戦略的な決定を下したのはインターンじゃなかったかもしれないと、人々が気づき始めているからです。今ではLLMがやったことにされますけどね。
さて、Redisの基本バージョンは、コアあたりのシングルスレッドアーキテクチャをフル活用して、約13万リクエスト毎秒を処理できました。プロキシでTLSを使おうとしたところ、約8万リクエスト毎秒しか処理できず、主にそのTLSプロキシがボトルネックになっていました。これは直感的に理解できます。Redisは基本的にTCPサーバーに接続されたハッシュマップであり、TLSプロキシというのは実際には2つのTCPサーバーが互いに通信し、その間でTLSを行っているだけです。つまり、基盤となるエンジンよりも実際にはるかに多くの作業を行っているわけです。プロトタイピング作業を行った結果、TLSをRedis自体に直接組み込む方が大幅にパフォーマンスが高いことがわかりました。リソース消費を抑えながら、より良いスループットを得ることができました。そしてこれこそが、AWSでお客様のためにやりたいことなのです。私たちのハードウェアを活用する、お客様にとって最良のものを構築したいのです。
プライベートフォークの悪循環：マージコンフリクトとメンテナンスの重荷
そこで、マネージドサービス向けに構築したのがこれです。RedisオープンソースのフォークにTLSを直接組み込み、それが基本的に今後メンテナンスしていくものとなりました。これを構築したのはRedisがまだRedis 3の時代で、Redis 6までずっとメンテナンスし続けてきました。その間、多くの機能をローンチしました。これらの機能の多くはTLSとは何の関係もないように見えますが、それでも対処しなければならないマージコンフリクトが発生しました。豆知識ですが、開発者グループの集合名詞は実際にはマージコンフリクトなんです。
例えば、Redisにはクラスタリングというシステムがあり、その中のパーティションの基本単位はスロットと呼ばれています。スロットを移動させるメカニズムがありました。明らかにネットワークが関与しているので、そのトラフィックも暗号化する必要があります。つまり、時間をかけて書いてメンテナンスしなければならないコードがさらに増えるわけです。しかし、Redisにはダイナミックコマンドリネーミングという機能もありました。これは、flush allやkeysのような非常に危険なコマンドを実行しないようにするための非常に奇妙な方法でした。このメカニズムは、私たちがTLS設定を構築した方法では正しく動作せず、新しいバージョンが出るたびにマージコンフリクトを解決しなければなりませんでした。
また、パスワードローテーション、オンラインデータマイグレーション(これはElastiCacheへのデータ移行です)、クロスリージョンレプリケーションといったこともやらなければなりませんでした。これらの機能は、必ずと言っていいほど、私が必要に迫られてそれを持たないサービスのために何とかパッチを当て終わった翌週に、AWSがクロスリージョンレプリケーションを実装するんです。そして彼らは「ああ、それは素晴らしい。さあ、コーヒーを一口飲んで、今日のAWSブログをチェックして新機能を見てみよう」って感じです。ええ、うまくいきませんでしたね。でも正直なところ、機能を完成させる最良の方法は、私にやらせることでした。そうすれば彼らがすぐにやってきて、私の仕事をゴミのように見せてくれるんです。これらはすべて2018年から2020年の間に構築した機能で、Redisの新しいバージョンが出るたびに、これらのコンフリクトをどうメンテナンスするか考え出さなければなりませんでした。
そして、これが私が内部プライベートフォークの悪循環と呼んでいるものです。ご存知の通り、私たちには限られた数のエンジニアしかいません。そして、もしそれらのエンジニア全員がマージコンフリクトの処理に時間を費やしているとしたら、それは上流に作業を送る時間が少なくなることを意味します。結局、私たちは内部機能をどんどん構築することに時間を費やすことになります。つまり、内部で機能を構築すればするほど、上流からの変更をマージするのにより多くの時間を費やすことになり、その結果、それらを上流に送る十分な時間がなくなり、さらに内部で機能を構築することになります。これはAmazon内部の多くのサービスに当てはまります。多くの場合、私たちは貢献したいと思っています。これは、私が入社した当時、会社がオープンソースに何かを貢献するために必要なすべての承認を得るのに実際に長い時間がかかったという事実によってさらに悪化していました。私が初めて貢献したバグでは、IP弁護士と話さなければなりませんでした。GMとも話さなければならず、さらにビジネスライン弁護士とも話して、基本的にこれらすべてを解決しなければなりませんでした。
オープンソース貢献への転換：パスワードのスペース問題からTLS抽象化まで
では、進化した少し異なるプロセスについて話しましょう。そして、なぜ私がそれがずっと良いと思ったのかについてです。なぜなら、オープンソースに貢献することは私にとって非常に重要だったからです。では、非常にシンプルなバグについて話したいと思います。 Redisはレプリケーションと呼ばれる機能をサポートしていました。つまり、プライマリがあり、データを結果整合性でレプリカにレプリケートします。TLSについて少し話しました。また、そのパスウェイには認証もありました。これはAUTHコマンドを通じて行われました。レプリカは設定されたパスワードを使ってプライマリにAUTHコマンドを送信します。
私はこの機能を構築した人の一人でした。そして、テストをしている間に、ほとんどのパスワードは機能するのですが、私が与えられた製品定義では、パスワードにはアットマークとnull文字を除いて何でも使用できると書かれていました。これには空白文字も含まれます。この機能に対して積極的なテストを行っていたところ、Redisのパスワードにスペースを入れると機能せず、レプリケーションが成功しないことがわかりました。最も敏感な空白文字は、本当に会社の取締役会だけに制限されるべきです。
パスワードのようなものをテストする際には、さまざまなものでテストすることが重要です。認証ベースのことをやっているときにテストするパスワードのテストリストの中で、私のお気に入りの一つはEICAR文字列です。これは、実際にライブマルウェアを回すことなくウイルス検出器をトリガーするように設計されたファイル、文字列です。理論的には、絶対に何も壊れないはずです。実際には、私がカンファレンスのステージでこれについて言及しているという事実が、どれだけ多くのものが壊れる傾向にあるかについて多くを物語っているはずです。はい、多くのものが実際に壊れます。
私の目標の一つは、このコードを内部で保守したくないということでした。なぜなら、実際に同じTLSパス上にあったからです。同じ接続確立パス上にありました。だから、これを修正しようと思いました。私たちが実際に使用していたコードベースを見つけました。Redis内の2つの異なるプロトコルの1つです。Redisにはインラインプロトコルと呼ばれるものがあり、これは一連のスペース区切りのコマンドです。そして、RESP2プロトコルもあり、これはすべてバイナリセーフで、スペースのようなものもサポートしています。だから、インラインプロトコル用に特別な処理をして、このauthコマンドを正しく送信しようと思いました。法務部門と話して承認を得た後、このプルリクエストを提出しました。そして、当時のRedisのメンテナーであるSalvatore Sanfilippoから素晴らしい返答をもらいました。彼は、いや、このRESP2プロトコルに移行しようと言いました。それははるかに堅牢です。それが私たちがやるべきことです。
これはオープンソースの素晴らしい成功例です。私たちはバグを見つけました。私が修正案を提案したところ、私よりもシステムに詳しい人から情報を得て、さらに良いものにすることができました。では、なぜ自分でそれをメンテナンスしたいと思うのでしょうか？まあ、パスワードにスペースを含められることを競争優位性と考えるのは馬鹿げていると私たちは気づきました。他の人たちが同じ問題につまずき続けているのに理由がわからない中、フォークをサポートしてメンテナンスし続けることは、あなたにとってより大きな負担になります。その通りです。そして、これがなぜAWSがオープンソースへの貢献を時間とともにますます増やしてきたのか、私が非常に重要だと考える理由につながると思います。オープンソースをより良くすることで、より多くのエンジニアがAWS上でオープンソースを使うことを選択するようになり、それは素晴らしいフライホイールになりますよね？それは同時に利他的であり、自己利益にもかなっています。それが正しいやり方です。まさに、潮が満ちればすべての船が浮かぶということです。その通りです。
当時は貢献するのに多くの努力が必要でしたが、実際に私たちはもっと多くの貢献を始めました。私の時間の一部、Amazon ElastiCacheでの時間のほぼ50%を、ただ修正を貢献するために与えられました。そして私が取り組んだ最初の大きなものは、先ほどお話ししたこのTLSの作業でした。少しお話ししたいのですが、私はこの時点で大学を卒業して3年目でCコードを書いていました。私は優れた開発者ではありませんでしたが、このようなコードをたくさん書きました。それが私の仕事です。私はダメな開発者なんです。特にCコードでは、TLSが有効ならXをする、そうでなければYをする、というようなif文がたくさんあります。
Redisカンファレンス、開発者向けの年次カンファレンスに行ったとき、Redis内部でのトランジット暗号化が本当に必要で、とても重要だということを広めるために、先ほどお話しした保守担当者は、あなたのコードは良くない、醜い、あまりうまく動作しない、もっと良い解決策が必要だと言い続けていました。しかし私は粘り強いだけが取り柄で、人々と協力し続け、最終的に解決策を見つけました。私たちは最終的に、これらすべての低レベルの詳細を隠すような接続の抽象化を構築しました。これは非常にシンプルだったように見えますが、実際には必要な通りの接続抽象化を得るのに多くの努力が必要でした。そうすることで、私たちが行わなければならなかったすべてのTLS作業を完全に抽象化することができました。そして、最近認定されたダメな開発者として、片方のコードは何をしているのか、なぜそうしているのかを理解して答えにたどり着くのがはるかに簡単です。もう片方よりもね。可読性は重要です。
可読性は本当に重要です。そしてこれは素晴らしい成功事例です。私たち、つまりAWSは、最終的に受け入れられたコードを実際には貢献しませんでした。それは実際にはRedis Labs、現在のRedis Limitedによって行われました。しかしこれは依然として素晴らしい成功です。なぜなら、これはオープンソースがコラボレーションとして機能しており、単に一つのグループがコードを投げ捨てて、これが私たちが望む見た目だと言っているのではないからです。私は実際にコードがどのように見えるべきかについて強い意見を持っていましたが、コミュニティは別のものを望んでいました。そして私たちは皆で集まって、コミュニティとして望むものを構築しました。
ですので、重要だと思うので改めて言いたいと思います。Amazon ElastiCacheでは、マネージドサービスの運用に役立つコードのみを内部でメンテナンスしたいと考えています。ですから、バグ修正のようなものを改善したいのです。信頼性を向上させたいのです。パフォーマンスの最適化を貢献したいのです。
これらはすべて、私たちがコミュニティに自由に貢献したいと考えているものです。アップストリームに貢献したいんです。社内に留めておきたくないんですね。なぜなら、そうすることでメンテナーから専門知識を得られますし、コミュニティの成長を助けることができますし、システムをより信頼性が高く持続可能なものにすることができるからです。結局のところ、コミュニティ内でメンテナンスを手伝いたいと思っています。なぜなら、後でバグが混入した場合、それを私たちのサービスに取り込んで適用する時に発見するよりも、コミュニティ内で発見する方がずっと良いからです。
このスライドの「私たち」はAWSだけではないということを明確にしておきたいと思います。もうお分かりだと思いますが、私はAWSで働いていません。弁護士と、今この会場の梁に隠れているAWSのスナイパーは、私がそれをはっきりと言う必要があると強く主張しています。しかし、コミュニティとしての「私たち」、より大きな全体として、私たちが活動しているエコシステムとして、これはコンセンサスによる決定として浮かび上がってきました。これが私たちが望むモデルなんです。それがオープンソースの好循環なんです。
Serverlessの実現とCluster Slot Statistics：拒絶されたイノベーション
少し早送りしましょう。2018年と2019年についてたくさん話してきました。私たちのサービスはそれ以来少し進化しましたが、核となるアイデアは今も同じです。2020年に、Redisの前任のメンテナーが退任し、私が一時期Redisのメンテナーになりました。そしてそれが、私たちがオープンソースにより多く貢献することを助けてくれました。では、現在の私たちのサービスがどのようなものか見てみましょう。
まだこれらのカスタマーVPCがあります。ENIからVPCエンドポイントに進化しました。新しいトレンディな技術で、プロビジョニングがずっと速くなりました。今はNLBを使っていて、このNLBは、皆さんが私たちのクラスターに送るトラフィックをプロキシフリートを通してバランシングするのに役立っています。これにより、より迅速かつインテリジェントにスケールできるようになりました。お気づきかと思いますが、カスタマーごとのVPCではなく、サービスVPCを持つようになりました。これにより、より迅速にプロビジョニングできるようになり、受信するスケールにより動的に適応できるようになりました。しかし結局のところ、私たちは依然として先ほどお話しした全く同じキャッシュノードを実行しており、それらは同じ管理プロセスを持ち、その上で同じオープンソースエンジンが動いています。プロキシフリートに高度なクラスタールーティングがあるとはいえ、結局のところ、このオープンソース技術がうまく機能することに深く依存しているのです。
また指摘しておきたいのですが、このトークはElastiCacheについてで、これはある種のデータベースなんですが、このスライドにはRoute 53が登場していて、これは間違いなくデータベースです。TLSで抱えていた似たような問題についてお話ししたいと思います。それは、サーバーレスでスパイキーなワークロードをどう処理するかということです。従来のキャッシングでは、ここに見えるようなスループットを処理するためにプロビジョニングするかもしれません。これは食品配達サービスをエミュレートしているようなものです。ランチタイムに小さなスパイクがあり、ディナータイムにより大きなスパイクがあるのが見えると思います。
従来のキャッシングは常にデータを提供できるようにしたいので、高水準マークの上にある程度のバッファを持つようにしています。しかし、エンジニアとしてのあなたは、これほど多くのオーバープロビジョニングがあるという事実に満足できないはずです。とはいえ、ある程度はそうせざるを得ないのですが。歴史的に、オートスケーリングは素晴らしいものでした。予期せぬことが起きたときに、必要になってから20分後に必要な容量が得られるというものでした。しかし、このパターンは非常に予測可能なワークロードを持つ場所でさえ見られました。人々は、容量の問題に決して遭遇したくないと言って、絶対的な最高水準マークを目指し、決してスケールダウンしないのです。パフォーマンスの制限にぶつかっているか、オーバープロビジョニングをしてその特権に対して料金を支払っているかのどちらかです。これは最適化の機会であり、これがElastiCacheで解決したかった差別化されない重労働だったのです。だからこそ、私たちはServerlessを構築しました。
Serverlessのスケーリング方法は、依然としてある程度のバッファを持っています。なぜなら、一日を通して常に発生する瞬間的なトラフィックを処理できるようにしたいからです。しかし、システムの実際のスループット要件にはるかに近い状態を維持しようとしています。これには、常に予測を行い、その負荷を処理するためにスケーリングする必要があります。では、どのようにしてこれを実現できるのでしょうか？実際に行っているのは、先ほど述べたスロットを追跡することです。Redis内のデータはスロットと呼ばれるものに分割されており、クラスタ内のすべての単一スロットのスループット、使用状況、ネットワークの入出力バイト数を常に追跡しています。特にホットになっているものを検出すると、基本的にそれよりも冷たいスロットをそのキャッシュノードから移動させることで、それを分離しようとします。
少し直感に反するかもしれません。最もホットなスロットを移動させようとしているのではなく、他のホットなスロットを最もホットなものから遠ざけようとしているのです。本当に強調しきれないのは、以前は計画を立てなければならなかったということです。私は多くのキャッシュクラスタを運用していました。当時のスケールは、今日では可愛らしいものです。これは私たちがしなければならなかった多くの作業であり、他の大規模なElastiCacheの顧客と話すたびに、彼らもまったく同じことをしているように感じました。最終的には、これは本当にプロバイダーに代わりにやってもらいたい種類のことのように思えました。ほとんどの場合、もうこのようなことはないので、私はこれを覚えています。
素晴らしいことです。では、どのようにしてこれを解決できたのでしょうか？基本的に、Cluster Slot Statisticsと呼ばれるものを構築しました。さて、このPRを特に強調したいのは、その日付のためです。ElastiCacheは2023年のre:InventでServerlessをローンチしました。私たちはこのPRを丸1年前にオープンしました。Amazon ElastiCacheは結局のところ、お金を稼ぎ、顧客のために機能を構築しなければならないサービスですが、オープンソースでは、この機能を構築するために長いリードタイムが必要であることを知っていました。最初に構築してからコードをダンプするのではなく、コミュニティと協力して、私たち全員が一緒に望むものを構築したかったのです。
これはAWSだけに利益をもたらす変更ではありません。これは、大小を問わず非常に多くの顧客にとって大いに意味があります。実際、当時GCPからも素晴らしいエンゲージメントがあり、彼らも同様のものを検討していました。そして、ご覧のとおり、このPRには111のコメントがあります。非常にエキサイティングな会話があり、マージされることに非常に楽観的でした。私はこれに多くの賭けをしました。多くの時間を費やしました。編集したのがわかると思いますが、コミュニティに対して私たちが望むことを可能な限り効果的に伝えられるようにしたかったからです。
しかし、このPRはマージされませんでした。そして、その答えは少しがっかりするものでした。数ヶ月後、約3ヶ月後、4ヶ月後、かなり時間が経ってから、Redis Limitedが単純にこのパッチを受け入れたくなかったということが分かりました。そして、いつマージされる可能性があるのかについて、一切のコミットメントを示してくれませんでした。さて、私よりも冷笑的で小心な人間であれば、これは彼らが特定のビジネスモデルのための特定のロードマップを守ろうとしていたからだと示唆するかもしれませんが、きっと彼らには、顧客や他のプロバイダーに大いに役立つであろう変更を実装しない、もっと良い理由があったのでしょう。ただ、私にはその他の理由が何なのか分かりません。もしかしたら皆さんにはアイデアがあるかもしれませんね。本当に、自分で冒険を選んでください、という感じです。
結局のところ、私たちはこのコミットを社内で保持し続けることになりました。それでもServerlessを提供する必要があったので、結局Serverless向けに構築することになりました。しかし、次に起こったことは、私たちが予想していたものではありませんでした。 さて、Madelynが今お見せしたように、AWSは多くのオブザーバビリティ、多くのパフォーマンス改善、多くのコスト効率を向上させる素晴らしい機会を持つ、興味深いものを構築しました。そして、Redisは何らかの理由でこれを社内に留めました。これは、AWSや他の大規模プロバイダーがオープンソースと協働したい方法ではありません。
Redisのライセンス変更とValkeyの誕生：コミュニティの反撃
では、当時何が起こったのでしょうか？実は、水平線上にトラブルが醸成されていたのです。余談ですが、なぜRedisのブランディングが今や1950年代のダイナーのように見えるのか、私には全く理解できませんが、まあいいでしょう、付き合えます。2024年3月以前は、 RedisはBSDライセンスでした。これは真に寛容なオープンソースです。基本的に何でも好きなことができます。商用利用もできます。マネージドサービスとして運用することもできます。あなたの小さな心が望むことは何でもです。
2024年3月に、Redis LimitedはSSPLとRSAL v2に変更しました。これはキーボードの上に猫が落ちたような音ですが、これが意味するのは、これらが制限的なライセンスであり、もしこれをマネージドサービスとして運用するなら、インフラ全体をオープンソース化しなければならない、ということです。おそらく彼らが意味しているのは、デュアルライセンスアプローチを通じて、あるいは巨額の小切手を切れ、ということです。Open Source Initiative、OSIは、SSPLをオープンソースライセンスとして認めていません。つまり、これはRedisのオープンソースブランチの閉鎖であり、これは基本的に誰も喜ばせませんでした。
個人的な実体験から言えるのは、AWSを揺さぶって金を取ろうとするのは極めて困難だということです。みんなの時間にはもっと良い使い道があります。ですから、これが実際に達成したのは、膨大な数の人々を怒らせることだけでした。そして、これによって私は皮肉だけれども 非常に真実な観察をすることができます。例えば、ステージに敷物がないのは、Redisがリハーサル中にそれを引っ張り続けようとしたからです。このrug pullの問題は、彼らがそれに失敗したということです。これはどういうわけかさらに悪いことです。なぜなら、もしコミュニティを裏切るつもりなら、少なくともちゃんとやるべきだからです。
しかし、実際に起こったことはそうではありませんでした。なぜなら、数週間のうちに、コミュニティがRedisのバージョン7.2.4、つまり最後のBSDライセンス版をフォークしたからです。このフォークはBSDライセンスの下でValkeyと呼ばれ、これは怪しげなランダムな数人の不満を持った人々が決めたものではありませんでした。元のRedisメンテナーたちがフォークに参加し、他の人々もそれを支持しました。AWSのような大手企業はもちろんですが、Google、Oracle、そして他にもたくさんの企業が支持しました。
Linux Foundationが中立的なガバナンスを提供し、これが再び起こらないようにし、BSDライセンスのまま維持されました。梯子は外されません。そして2025年5月、Redisは方針を転換しようとしました、あるいは試みました。彼らはAGPLに切り替えましたが、これは依然として制限的ではあるものの、オープンソースライセンスではあります。しかし、遅すぎました。コミュニティはすでに移行していました。Valkeyには勢いがありました。ガバナンスがあり、すでにRedisよりも速く革新を進めていました。一度鳴らした鐘を元に戻すことはできません。簡単には元に戻せないこともあるのです。
さて、このトークの冒頭でMadelynが言及したことに基づいて、私は何かを認めなければなりません。私たちがこの準備を始めるまで、私は素朴にも思っていました、なぜAWSが実際のRedisのライセンスについて気にする必要があるのか？明らかに彼らはRedisのオープンソース版をただ取ってきて、いくつかのインスタンスに載せて、それで良しとしているわけではありません。それは私たちがマネージドサービスを構築する方法ではありません。それは私たちがやることです。彼らは明らかに代わりに魔法のようなものを持っているはずです、なぜならただオープンソース版を実行するだけなんて、それは正気の沙汰ではないからです。それで彼女はRedisが内部でどのように動作するかのシンプルな図を示しましたが、これが私が作成したバージョンです。
私の頭の中では、ElastiCacheのようなものは単にRedisとAPIが互換性があり、内部では非常に特別なもののコンセプトの周りにラッパーがあって、実際には共通点がないものだと明らかでした。つまり、ElastiCacheはRedisプロトコルを実装していますが、同じように動作します。すべて独自のコードで、まったく異なる実装です。私は今、これが間違っていたことを知っています、なぜなら彼らがやったことはそうではなかったからです。彼らは結局何かを構築しました。彼らは実際のオープンソースRedisを最小限の変更、約100行のコードで構築しました。ElastiCacheは文字通りRedisバイナリ、つまり利用可能にされたオープンソースコードを実行しています。それがオープンソース上に構築されたマネージドサービスが実際に意味することなのです。
彼らはオープンソースエンジンを実行し、その周りのインフラストラクチャを管理しています、だから彼らは気にするのです。だからRedisがライセンスを変更したとき、これはああ、AWSはAPIの互換性を維持する必要があるという問題ではありませんでした。これはAWSが新しいライセンス条項の下でこのコードを法的に使用できなくなったということでした。それは全く異なる問題です。AWSは行動しなければなりませんでした。それで彼らは何をしたのでしょうか、Madelyn？彼らは私にValkeyをフォークさせてくれました。やった、そして大いに喜びがありました、少なくともこの界隈では。これが私のスライドだとわかりますね、なぜならAI生成ではないからです。はい、正気でもありますね。はい、これはもっと普通です。その通りです。
Valkeyのガバナンスとコミュニティ：Linux Foundationの下での真のオープンソース
さて、CoreyがValkeyについてかなり高いレベルでの理解を提供してくれましたが、私はもう少し詳しくお話ししたいと思います。そして、これがAWSによるRedisのフォークではないということを明確にしておきたいと思います。これはOpenSearchで起きたこととは違います。OpenSearchの時は、Elasticsearchを取り、オープンソースだった最後のバージョンを取って、まずディストリビューションを、そしてその後プロジェクト自体をオープンソースにしました。Valkeyは初日からLinux Foundationの中で作られたもので、AWSによって一切コントロールされていません。私たちがテクニカルステアリングコミッティと呼んでいるものには6人のメンバーがいて、私と、私と一緒にRedisから来たもう一人のメンテナーであるZhaoを含め、他にRedisオープンソースプロジェクトの非常に活発な貢献者が4人います。Ericssonから1人、Huaweiから1人、Tencentから1人、そしてGCPから1人です。
ええ、これは指摘しておきたいんですが、正直に言うと、若い世代の一部の方々や、業界に新しく入ってきた方々の間で必ずしもよく理解されていないと思うからです。GitHubで何かをフォークするというのは、何かをより良くするためのワークフローの一部であって、私の場合は大幅に悪化させることになるんですが、それはプロジェクトの完全なフォークとは同じではありません。完全なフォークというのは、ガバナンスと注目を移行し始めて、それが新しい権威あるソースになるというものです。つまり、私がフォークボタンをクリックしても、誰も本当に気にしないんです。まあ、Linuxか何かに対してやっている場合は別ですが、そうするとどこかでLinus Torvaldsが冷や汗をかきながらパニックで目を覚ますんです。何か恐ろしいことが起きたぞ、と。何だ?って。ええ、私は全てを悪化させますからね。逆のスカトロジカルなミダスタッチみたいなものです。
でも、ええ、通常フォークボタンをクリックしても、親プロジェクトにとっては意味がないんです。コミュニティ全体、努力、そして注目をそれと一緒に持っていかない限りは。そして、それこそが私たちが一生懸命やろうとしたことです。50以上の組織に私たちと一緒に来てもらい、Valkeyプロジェクトの構築を支援してもらいました。コアメンテナーの何人かについてお話ししましたが、Percona、Snap、Verizon、Oracleといった企業からのサポートもありました。これらは全て大きくて有名な企業で、プロジェクトをオープンに保ち、オープンなガバナンスの下に置くことに関心を持っています。なぜなら、Redisはライセンスを変更しただけではなかったからです。彼らはある意味コミュニティを変えてしまい、私たちはそれに満足していませんでした。
実際にフォークを作成して以来、150人のユニークなコード貢献者がいます。数千のコミットがあり、私たちは非常にうまくいっています。数千万のコンテナプルがあります。これはRedis Open Sourceの数十億には及びませんが。
でも、コミュニティを大切にする人たちのために、私たちが構築を続けられていることを本当に嬉しく思っています。そしてもちろん、Amazon ElastiCacheも一緒についてきました。Amazon ElastiCache for Valkeyは、依然としてオープンソースのValkeyの上に構築されています。イノベーションを続けなければなりません。データベースやキャッシングサービスを構築して、安定した状態にしたら、その後は二度と触らないということはできません。SimpleDBでない限りは。あれはしばらく聞いていないサービスですね。
Valkeyでの技術革新：マルチスレッドIO、メモリ効率、ベクトル類似検索
それでは、私たちが構築したいくつかのイノベーションと、コミュニティで構築された他の主要なイノベーションについて、そしてなぜそれらが構築されたのか、そしてそれらがコミュニティとエコシステム全体をどのように改善しているのかについて、少しお話ししたいと思います。さて、ここで非常に明確にしておきたいことがあります。皆さんは、このような公開の場でAWSに具体的な数字を出させることがどれほど大変か、全く想像もつかないでしょう。このスライドに書かれていて、私がステージ上で血を流していないのであれば、それは真実です。これらの数字は確実なものです。本物です。だからこそ、彼らはほとんど数字を出さないのです。なぜなら、嘘、大嘘、そしてベンダーのベンチマークというものがありますからね。これらは本物です。そして、これからお話しする数字については、Valkeyのウェブサイトに2つの完全なブログ投稿があり、私たちがこれを具体的にどのように測定したか、そして皆さん自身でどのように再現できるかについて説明しています。ですので、私の言っていることに疑問があれば、喜んで検証させていただきます。
2018年頃、Amazon ElastiCacheは水平および垂直スループットの改善に取り組み始めました。以前にも述べましたが、Redisオープンソースは主にシングルスレッドでした。IOスレッドという概念があり、多少のスケールには役立ちましたが、突然ワークロードに大きなスパイクが発生し、特定のキーでそれを処理する必要があるという問題に直面するお客様がいました。キャッシングはしばしば非常に不均一です。非常にムラがあり、1秒間に数百、場合によっては数百万のリクエストを処理する必要があるホットキーが存在することがあります。そこで、それを支援するために何かを構築したいと考え、実際に何度かこれをオープンソース化しようとしましたが、コンセンサスを構築することが非常に難しく、会話は何度も停滞してしまいました。
しかし、Valkeyが登場すると、新しいtechnical steering committeeと共に実際にもう一度挑戦し、皆が実際に非常に興奮していました。そして私は、TLSの時と同じ感覚を持ちました。つまり、誰もがこれを実現したいと思っていて、どうやってそれを実現するかを喜んで考えようとしていたのです。実装方法は基本的に、メインスレッドに単一のコーディネータースレッドがあり、他のIOスレッドに作業を分散できるというもので、当時の他の設計とは少し異なります。これに興味がある方は、このre:Inventで別の講演を行い、詳細について説明しました。
しかし、私たちが観察した主なことは、これが本当にサーバーレスオファリングに役立ったということです。つまり、ElastiCacheがこれを構築しました。サーバーレスでより迅速にスケールするために必要だったのです。Redis 7.2では、0リクエスト/秒から500万リクエスト/秒に到達するのに約70分かかりました。必要になってから70分後に必要な容量が得られるわけです。ただし、その間ずっと指数関数的にスケールしていました。しかし、Valkey 8と、先ほどお話しした新しいマルチスレッドIOを使用することで、0から500万リクエスト/秒まで約15分で到達できるようになりました。そして実際に私が実行したテストでは、12分で到達しました。ですので、これらの数字は私が実行したテストに基づいており、興味のある方にはベンチマークをお見せできます。
これが、私たちがオープンソースに期待する働き方です。特定のシャードで迅速にスケールするというお客様からのニーズがあり、それをプライベートフォークだけで維持するためにすべての作業を行いたくありません。コミュニティと協力して、誰もがその恩恵を受けられるようにしたいのです。しかし、私は8人で構築したものについて話しています。他の人たちは何を構築したのでしょうか？ Ericssonは最近、基本的に新しいメモリ効率の高いハッシュテーブルを貢献しました。これは私が何年も言い続けてきたことですが、Redisは個々のキーバリューペアの保存方法に多くのオーバーヘッドがありました。最悪の場合、Redisオープンソースエンジン内に「food」や「bar」のような単純な文字列を保存するために、約100バイトのオーバーヘッドがありました。
そして多くの人々が、非常に動的なデータに対してキャッシングを使用しています。通常はデータベースによって駆動されるものです。そしてそのデータの多くはかなり小さいんです。ですから、もし100バイトのオーバーヘッドがあると、それらすべてを保存するためのDRAMコストという観点で、はるかに多くの費用を支払うことになります。また、これが私がこの件について通常よりも懐疑的でなくなった理由の一つだったことも指摘しておきたいと思います。もしこれが単なるAWSのプロジェクト、あるいはAWSと仲間たちだけのものだったら、ライセンスの再ライセンスやフォークをめぐる多くのドラマについて、私はもっと懐疑的だったでしょう。しかしEricssonは色々な側面を持つ企業ですが、私の知る限り、同じような意味でのクラウドサービスプロバイダーではありません。彼らはホスト型のRedisオプションを販売しているわけではないんです。ですから、彼らがこのようなものに貢献し始めたとき、それが本物だと分かったんです。そうなり始めて、他に誰がこのようなことをしているのか調べてみたら、スライドに載せる許可を取るには多すぎるほどのロゴがありました。
これを気にかけている非常に大きな企業がたくさんあり、Ericssonもその一つです。彼らにはVictorという名前のエンジニアがいて、彼の仕事全体がEricssonが製造する製品の一部の中でValkeyが効率的かつ効果的に動作することを確認することでした。この仕事のほとんどは、私がそれに触れることが許されないということを意味していて、それが戦いの半分なんです。まさにその通りですね。
先ほど申し上げたように、AWS内でも、これは私たちにとっても大きなメリットです。これはElastiCache上で動作している大手フードデリバリーサービスの一つから得たグラフで、彼らはValkey 7.2からValkey 8.1に移行したときに、合計で41%のメモリ削減を実現できました。さて、41%の削減があったと言うとき、この計算は混乱を招くものであることを指摘しておきたいと思います。なぜなら、足し算ではなく掛け算をしなければならないからです。そしてリハーサル中にAWSの特定の非常に細かいことにこだわる人々が、この計算をめぐって丁寧な企業版の怒鳴り合いのようなものになってしまいました。もし計算に疑問があれば、どうぞご自由にスケジュールから3時間を空けてラウンド2に臨んでください。私は二度目はそこから50マイル以内にいたくありません。
ちなみに、計算式はこれです。そんなに難しくないと思うんですけどね。みんな大げさにしすぎです。正直言って、二人の学者が互いに怒鳴り合っているのを見ているようでしたが、丁寧にです。お二人とも終身在職権があるんじゃないですか?他のことをやってもらえませんか?素晴らしかったです、素晴らしかった、最高でした。
では、3つ目のストーリーについてお話ししたいと思います。私の意見では、これが私のお気に入りのストーリーです。AmazonにはMemoryDBという別のRedisオープンソース互換サービスもあります。これももっとマーケティングをうまくやれるかもしれないサービスですね。このサービスの中で、私たちはVector Similarity Searchという機能をローンチしました。これは基本的にRedisオープンソースへの拡張機能、モジュールと呼ばれるものとして構築されたもので、セマンティック検索のようなものに使用されるベクトル類似性検索を提供します。エージェント関連のものでは非常にトレンディですが、もし彼が望むなら、それについてはもっと彼に話してもらいましょう。
はい、このゲームはGoogle Cloudからも強くプッシュされました。現在Googleで働いている多くの人々を含め、自分たちの会社が何をしているのか忘れてしまった人が多いのですが、皆さんの多くが生まれる前の太古の昔、Googleは検索会社だったんです。そして彼らはそれが本当に得意でした。だからこの種のことをプッシュし始めるのは、彼らのルーツに戻るようなものなんです。ああそうだ、あの頃を思い出すよ、という感じです。ほとんどAltaVista時代のような感覚ですね。
Google Cloudも実装を持っていました。そして先ほど述べたように、彼らはTSCメンバーの一員でした。Google Cloudもベクトル類似検索の実装を持っていて、彼らの実装は私たちがMemoryDBで持っていたものよりも優れていました。水平スケーラビリティを備えていたんです。私たちがMemoryDBで持っていたものは単一シャードしか許可していませんでした。そして先ほどお話ししたように、人々は100ギガバイトではなく、テラバイト規模のベクトル類似性データを求めていました。両方をオープンソース化して、どちらがより優れているか調べたとき、私たちはGoogleのものを選びました。
オープンソースコミュニティでは、私たち全員がより優れた実装の周りに結集しました。これが私たちのやりたい方法です。AWS の私たちにとって、自分たちが最高のプロジェクトを構築しなかったことを受け入れるのは少し難しいことですが、ごく最近、ElastiCache内部で、キャッシングベースのValkeyバージョン向けにベクトル類似検索を立ち上げることを決めたとき、私たちはMemoryDB上に構築されたものではなく、Googleの実装を使用することを選びました。ここに引用がありますが、11月17日時点で最速だと言っています。これはAWS用語で、もしかしたら状況が変わっているかもしれないという意味です。ええ、このスライドを皆さんの前に出したいなら、この特定の日付を要求した2.5兆ドル企業がどこか、一度推測してみてください。私たちの会社ですが、それでもこれは非常にエキサイティングなことです。なぜなら、インメモリデータベース向けのベクトル類似検索は、非常に高い再現率を必要とするアプリケーションにとって、依然として非常に重要なワークロードだからです。再現率とは基本的に、ベクトル類似検索から近似検索を行う際に得られる正しい結果の割合のことです。
ビジネス価値の実現：価格削減、逆転の皮肉、そしてshitposting.aiのデモ
心配しないでください。ビジネス価値について話しましょうというイントロがどんな感じに聞こえても、これはAIのセールスピッチへの導入ではありません。Madelynは技術的な勝利をすべてお見せしました。より高速なパフォーマンス、より優れたメモリ効率、改善された信頼性。これらはすべて本物で、すべて測定可能です。しかし、それをビジネスにとって重要なことに翻訳させてください。それは皆さんが支払う価格に帰結します。なぜなら、ElastiCache Valkeyは、まったく同じElastiCache Redis相当のものよりも安く、互いに交換可能にドロップインできるからです。私は後ほど説明するものを構築しましたが、それを繰り返し行いました。変わったのはエンドポイントだけでした。
これらの数字は、私たちがここで話している単なるパフォーマンスベンチマークではありません。これらは実際のAWSの値下げです。Serverlessは、まったく同じRedis相当のものより33%安いんです。同じサービス、異なるエンジン、3分の1安い。
ノードベースのデプロイメントでも同じ話になりますが、数字は20%です。なぜなら、サーバー相当のものを実行するにはまだオーバーヘッドがあることが判明したからです。これは昔の人たちもやっていたことですね。まったく同じサービス機能のまったく同じプレゼンテーションを得られるわけです。そのうちの一つが、実質的にはるかに低コストなだけなんです。
そしてここからが面白いところです。少しトロール的なシャーデンフロイデにお付き合いいただけるなら。Madelynが先ほど見せたパフォーマンス改善を覚えていますか？AWSがライセンス騒動やその他の間、内部に留めていたあれです。Valkeyがフォークしてその変更を含めてリリースした後、Redisはそれを取り込みました。これは調べられますよ。公式RedisプロジェクトのPR 14039です。彼らが奪おうとしたものを、今度はフォークから取り戻しているんです。
それからマルチスレッディングです。Redisは独自バージョンのマルチスレッディングを実装しましたが、Valkeyのものより遅かったんです。だから彼らはValkeyのコードを読んで、その学びを適用しなければなりませんでした。まったく同じロジックフローで、自分たちのものを同じくらい良くするために。2つのPRが必要でした。最初が13556で、次が14017です。そして私の個人的なお気に入りは、RedisがRedis 8のローンチブログ投稿で発表したことです。「レプリケーションのメモリ使用量を35%削減しました」と。素晴らしく聞こえますよね。そして実際素晴らしいです。なぜならそれはValkeyのコードPR 13732で、ほぼそのまま取り込まれたものだからです。ここで嫌味を言おうとしているわけではありませんが、RedisがValkeyから取り込んでいる機能は数十個あります。彼らがロックダウンしようとしたものが、彼らのアップストリームになったんです。彼らが収益化しようとしたコミュニティが、今では彼らのイノベーションの源になっているんです。
ここで非常に、非常に明確にしておきたいことがあります。彼らがこれを行うことは完全に許されています。なぜならこれはオープンソースだからです。BSDライセンスです。誰でも使えます。彼らがこれらを取り込むことは、法的にも、道徳的にさえも何も間違ったことをしていないと私は主張します。しかし、皮肉は壮観です。なぜなら、ライセンスを変更してプロジェクトをコントロールしようとしたのに、代わりに完全にコントロールを失い、今ではあなたを置き去りにしたフォークのダウンストリームになっているからです。これが最も純粋な形でのオープンソースのビジネスケースなんです。
真にオープンなコミュニティがイノベーションを推進しているとき、あなたの周りのすべての人、関わるすべての人が恩恵を受けます。Madelynのチームはメモリ改善を構築し、それをコントリビュートバックしました。他の企業も参加しました。機能がはるかに速いペースで流れ始めました。多くの人々がこれに取り組み始めました。イノベーションが加速しました。本物のイノベーションです。AWSが基調講演で時々話すバージョンのイノベーションではありません。あれは「あなたが6年間も求めていた機能をついにリリースしました」の略語のようなものですから。Redis自身でさえこれから恩恵を受けています。そうあるべきです。それがオープンソースというものですから。
ラグはしっかりと床に固定されたままです。なぜならライセンスはオープンであり、今後もオープンであり続けるので、誰もそれを引き抜くことはできないからです。そしてその結果、Valkeyに切り替える以外に何もしていないのに、あなたのAWSの請求額は下がります。これがコミュニティがコードを所有した時に起こることです。クラウドプロバイダーからゆすり取ろうとする企業ではなくね。さて、私はValkeyの上に何かを構築しました。それはAWSに、私にマイクと基本的にすべてへのアクセス権を与えたことを、彼らがすでに後悔している以上に後悔させるものです。では、携帯電話を取り出してください。
興味がある方は、shitposting.aiにアクセスしてみてください。もちろん、AIなしでトークはできませんからね。今すぐアクセスして一緒にやってみてください。皆さんはこういったカンファレンスに参加したことがあるでしょうし、ラスベガスで3年のように感じた1週間を過ごした理由を上司に正当化するための出張報告書を書かなければならなかったことがあるでしょう。今、私はそれを自動化しました。私がここで構築したものは、Strands SDKを含む様々なものの上で動いています。それは私の声で書きます。また、AWSから出てきたすべてのニュースを収集します。私がステージに上がった時点で130ほどの発表がありました。おそらく今はもっと増えているでしょう。そしてカテゴリー別、新しい順、くだらないものを除外することでソートできます。それによってかなり管理しやすい数に減ります。そして下部で、ここで気になることについて追加のコンテキストを与えると、それがあなたのために文章を書いてくれます。
すべてが完了して出力されるまで1分ほどかかります。コンピューターは少し遅いですからね。でもこれは構築できる種類のものです。私は一週間ずっとこれを実行して、この中に発表を流し込んできました。そして昨夜、スライドデッキを完成させなければならなかった時に、なぜなら事前に物事をやるべきですからね、今月のValkeyサイドでの請求額は54セントでした。確かに、Redisだったら80数セントという立派な金額だったでしょうが、ポイントは実際のコスト削減ではありません。パフォーマンスの話があります。より安価で、切り替えもエンドポイントを変更するだけで済みました。そしてもちろん、面白いです。
そう、サイトはshitposting.aiです。使ってみて、出張報告書を生成してください。そしてオープンソースのメンテナーが、このような場所に会社の金でバケーションに行くあなたを含め、みんなの生活をより良くしていることを忘れないでください。なぜなら最高のお金は他人のお金ですから。聞いてくれてありがとうございました。私はCorey Quinnです。あなたはMadelyn Olsonです。このプレゼンテーションが気に入ったら、アプリで5つ星をつけることを忘れないでください。気に入らなかった場合は、5つ星をつけて、私の問題が正確に何なのかを教えてくれる侮辱的なコメントを残してください。私たちにはアイデアがあります。あなたのアイデアを聞きたいです。ありがとうございました。そして何かあれば、外で質問を受け付けます。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion