re:Invent 2024: AWSがAmazon EBSの新機能と可用性向上を発表
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - What’s new with Amazon EBS (STG213)
この動画では、Amazon EBSのProduct Management DirectorのJody GibneyとSenior Product ManagerのHeather Horbochukが、EBSの新機能と可用性向上のための取り組みについて解説しています。単一のio2 Block Expressボリュームで最大256,000 IOPSを実現する高性能な機能や、Amazon ECSとAWS FargateでのEBSタスクアタッチメント機能の追加など、この1年間の主要な機能拡張を紹介しています。また、CloudWatchメトリクスを活用したボリュームの健全性監視や、最小1秒単位の粒度でパフォーマンスを確認できるEBS詳細パフォーマンス統計機能、Time-based Snapshot Copyなど、システムの可用性とレジリエンシーを高めるための新機能についても詳しく説明しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon EBSの概要と進化：パフォーマンスと信頼性の向上
みなさん、こんにちは。Mandalay Bayまでお越しいただき、ありがとうございます。私はAmazon EBSのProduct Management DirectorのJody Gibneyです。そして、一緒に登壇するHeatherをご紹介します。みなさん、こんにちは。Amazon EBSのSenior Product ManagerのHeather Horbochukです。
ありがとう、Heather。本日は、Amazon EBSの新機能について、この1年間に導入された機能や、ベストプラクティス、そしていくつかの便利な使い方についてご紹介させていただきます。これは200レベルのセッションですので、ほとんどの方がAmazon EBSの基本的な概念についてはご存知だと思います。簡単におさらいのスライドは用意していますが、Heatherのパートではより詳細な内容に踏み込んでいきます。
おさらいとして、Amazon EBSは最も基本的には、EC2インスタンス用のネットワーク接続された永続的なストレージ、つまりブロックストレージです。ストレージはネットワークで接続されているため、EC2インスタンスとは分離されています。インスタンスを停止して再起動しても、EBSボリュームはそのまま残っており、独立したライフサイクルを持っています。また、Amazon EBSはスナップショットの作成機能や、様々なデータサービス機能も提供しています。重要なポイントとして、Amazon EBSは単なるプロビジョニングされたディスクではありません。EBSエンジニアチームによって維持・運用される大規模な分散ストレージシステムであり、このシステムを通じて、異なるパフォーマンス要件や耐久性要件に対応する様々なボリュームタイプを提供しています。
Amazon EBSの最も基本的な価値提案は、パフォーマンスです。事実上どのようなスケールでも利用できる、シンプルで高性能なブロックストレージであり、異なるパフォーマンスレベルを提供する様々なボリュームタイプを用意しています。私たちのパフォーマンスは時とともに大きく進化してきました。 私はAWSで10年目を迎えていますが、2014年に専用のEBS帯域幅を手に入れて興奮していた小さなスティックフィギュアのような新人として始めました。Amazon EBSが2008年にローンチされた当時は、ネットワークトラフィックと共有される帯域幅で、わずか100 IOPSしか実現できませんでした。それが今日では、状況は大きく変わりました。現在では、単一のボリュームで最大256,000 IOPSを、専用のEBS帯域幅を通じて実現でき、単一のEC2インスタンスに対しては最大420,000 IOPSまで可能です。私たちは常にパフォーマンスの限界に挑戦し続けています。これらの数値は急速に古くなってしまうので、常にチェックしておいてください。私たちは継続的に改善を重ねています。
Amazon EBSは、コア機能としてのパフォーマンスを提供するだけでなく、io2 Block Expressボリュームによって最大5ナインの耐久性を備えた、高い信頼性と耐久性を持つストレージサービスを提供しています。さらに、私たちは常にセキュリティにも注力しています。Amazon EBSのすべてのセキュリティ機能については詳しく説明しませんが、1つの設定を行うだけで、リージョン内のすべての新しいEBSボリュームを暗号化できることは言及しておきたいと思います。このように、高性能で安全なストレージを簡単に利用できるよう努めています。
レジリエンシーの設計：リスク理解からボリューム選択まで
新機能の説明に入る前に、私たちがResiliencyについてどのように考えているかをお話ししたいと思います。これが2024年のロードマップとこの講演に非常に関連している理由は、2024年の私たちの焦点の多くが、お客様にResilientなアーキテクチャを設計するためのサポート機能を提供することにあったからです。Resiliencyとは何を意味するのでしょうか？基本的には、必要なときにアプリケーションが利用可能な状態であることを確実にすることです。 Resiliencyを考える上で、主に3つのステップがあります。最初のカテゴリーは、潜在的なリスクと障害を理解することです。これは、アプリケーションの可用性に影響を与える可能性のある依存関係のことです。
考慮すべき障害にはさまざまな種類があります。例えば、ボリュームの損失やネットワークの切断などです。アプリケーションの特性や重要度に応じて、どのような種類の障害が発生する可能性があるかを事前に判断する必要があります。 次に、影響の範囲を最小限に抑え、サービスやアプリケーションが遭遇する可能性のある様々な障害の影響範囲を特定する必要があります。このステップでは、アプリケーションが応答しなくなった場合、ビジネスにどのような影響があるのかを考えます - それが大きな影響なく停止できる重要度の低いサービスなのか、顧客の取引を記録するような極めて重要なものなのかを判断します。
最後に、復旧について考える必要があります。リスクを特定し、すべての依存関係を確認したら、これらの障害からどれだけ早く復旧できるか、そしてできれば復旧を自動化する方法を考える必要があります。Heatherがこれについて詳しく説明する予定ですが、私はこの基本的なフレームワークを最初に提供したかったのです。 では、最初のカテゴリーである、リスクと潜在的な障害の理解について見ていきましょう。 ここで重要なのは、アプリケーションの可用性に影響を与える依存関係を評価することです。なぜなら、強い依存関係を持つサービスが中断すると、あなたのサービスも中断してしまうからです。可用性を設計する際に最初に自問すべきことは、このアプリケーションが障害やダウンタイムを経験した場合、顧客やコアビジネスにどのような影響があるかということです。もし答えがコアビジネスに重大な影響があるというものであれば、おそらくそれはTier 1のミッションクリティカルなシステムであり、可用性とResilienceのアーキテクチャを設計する際にそれを考慮に入れる必要があります。
Amazon EBSには、アプリケーションのニーズに応じて異なるボリュームタイプがあります。GP3は最新のGeneral Purpose SSDボリュームタイプで、ほとんどのワークロードに十分なIOPSとスループット性能を提供します。どのボリュームを選べばいいかわからない場合に覚えておくべきことが1つあるとすれば、とりあえずGP3を選べばいいということです - ほとんどの用途に適しています。IO2 Block Expressボリュームは、IOが集中し、一貫して最低のレイテンシーを必要とする最も重要な高性能アプリケーション向けに特別に設計されています。ST1ボリュームは、高いスループットは必要だがレイテンシーやIOPSの要件が同じではないBig DataやAnalyticsワークロードに最適です。そしてSC1ボリュームは、基本的にデータをオンラインで保持する必要があるものの、アクセス頻度が低いプレアーカイブユースケース向けで、非常に安価です。
プレゼンテーションの様々な場面で触れることの1つに、Elastic Volumesを使用したストレージの柔軟性があります。この機能により、アプリケーションのダウンタイムや影響なしに、Amazon EBSボリュームのタイプ変更、サイズ増加、IOPSやスループット性能レベルの変更を動的に行うことができます。 異なるボリュームタイプの基本的な機能を理解したところで、アプリケーションの要件を理解する必要があります。最初に取り組むべき質問は、パフォーマンスのニーズについてです - アプリケーションにはIOPSとスループット性能、そしてレイテンシーの面で何が必要でしょうか。データベースのレプリケーションなど、他の考慮事項もあります - 異なるAvailability ZoneやRegionにデータをレプリケートするデータベースの組み込み機能を使用する予定はありますか？同様にパフォーマンスの観点から、IO2 Block Expressの最高かつ最も一貫した性能が必要なのか、それとも優れた価格性能比を持つGP3の性能で十分なのでしょうか？最後に、どのEC2インスタンスタイプが必要ですか？バースト性能で満足できますか？Amazon EBSへの専用帯域幅が必要ですか？また、インスタンスからEBSへの最大IOPSとスループット、そして個々のボリュームまたはボリューム群が実現できる性能も確認する必要があります。どのボリュームタイプを使用すべきかわからない場合は、GP3を使用してください。
GP3は、ボリュームあたり3,000 IOPSと125メガバイト/秒のスループットを基本性能として提供し、最大で16,000 IOPSまたは1,000メガバイト/秒まで拡張できます。必要に応じてスループットやIOPS性能を個別に追加プロビジョニングすることも可能ですが、これが初期の基本性能となります。
io2 Block Expressボリュームは、最も高いIO集約型の性能要件に対応し、一貫してミリ秒未満のレイテンシーを提供するために特別に設計されました。IO集約型アプリケーションやデータベースは、重要なビジネストランザクションの中核を担うことが多いため、io2 Block Expressはそれらを念頭に置いて設計されています。io2の設計時には、SRD（Scalable Reliable Datagram）という新しいネットワークプロトコルを作成しました。この情報を使う機会はないかもしれませんが、すべてのio2 Block ExpressボリュームはSRDプロトコルで動作し、コンピューティング環境内で最低のレイテンシーと最も安定したネットワークを保証します。
昨年のre:Inventで、io2 Block ExpressボリュームがNitroシステムを搭載したすべてのEC2インスタンスで利用可能になったことを発表しました。単一のio2 Block Expressボリュームで、最大256,000 IOPS、またはインスタンスあたり最大420,000 IOPSを実現でき、ストレージ容量は64テラバイトまで拡張可能です。これは、以前のio1ボリュームと比べて、ストレージ容量、最大IOPS、スループット性能が4倍になっています。また、最新のEBSサーバーアーキテクチャの改善点と、io1の100倍となる99.999%の耐久性を自動的に享受できます。
レイテンシーとその一貫性について説明すると、io2 Block Expressがアウトライアーレイテンシーを10分の1に削減すると言う時、実際にはこのようなグラフになります。発生頻度の低い外側のパーセンタイルに進むにつれて、io2 Block Expressは非常に一貫した低レイテンシーを維持しているのに対し、赤線で示されているgp3ではより高いアウトライアーレイテンシーが見られます。これはレジリエンス設計における重要な要素の一つです - アプリケーションが高レイテンシーの単一のアウトライアーIOにどのように対応するかということです。このレイテンシーの一貫性が必要な場合はio2 Block Expressが最適で、そうでない場合はgp3で十分でしょう。
まとめると、IO集約型で高性能なデータベースにはio2を使用し、KafkaワークロードのようなストリーミングにはST1が適しています。どれを使えばいいか分からない場合は、とりあえずGP3を使用してください。 Amazon RDSでデータベースを実行している方々向けには、3月にRDSがio1ボリュームと同じ価格でio2 Block Expressボリュームをサポートすることを発表しました。RDSのio1からio2 Block Expressへのアップグレードはダウンタイムなしで実行できます。
Figmaのようなお客様から、io2 Block Expressが提供する最低レイテンシーの一貫性を活用できたという声をいただいています。 彼らは、動的なボリューム変更を可能にするElastic Volumes機能を使用して、io1からio2への移行を1〜2週間程度で完了することができました。
今年、Amazon ECSとAWS FargateでEBSタスクアタッチメントを発表しました。特にFargateのお客様にとって、これは大きな改善でした。なぜなら、Fargateの一時的なボリュームの最大容量である200ギガバイトに制限されることなく、中央のFargateアカウントではなく、お客様自身のアカウントに存在するボリュームをアタッチできるようになったからです。例えば、特定のデータセットでコンテナを起動する前にボリュームを準備したり、事前にデータを投入したりする必要がある場合、EBS Snapshotを使用してそれを実現できます。これは特にFargateのお客様にとって大きな進歩です。
これらの設定はすべてFargateのタスク定義で指定できます。EBSがサポートする最大値まで、希望するボリュームタイプやパフォーマンス仕様を事前に指定することができます。また、Elastic Volumes機能を使用して、ボリュームのパフォーマンスやタイプを変更することもできます。それでは、Heatherに引き継ぎたいと思います。ありがとう、Jody。
EBSの監視とパフォーマンス最適化：新機能と詳細統計
ここで、レジリエンシーについての考え方に立ち返りたいと思います。 まず、影響範囲の最小化という2番目の観点について説明します。問題が発生した際に、お客様への影響を抑えるために影響範囲を最小限に抑えることは非常に重要です。EBSでは、障害やパフォーマンスの分離を防ぐために懸命に取り組んでおり、高可用性で高性能なサービスを実現できていると自負しています。しかし、インフラストラクチャーで稀に障害が発生した場合に備えて、影響範囲を最小限に抑えることは依然として重要です。
障害について言及する際に重要なのは、障害は二元的なものではないということです。つまり、単純に「障害が発生したか、しなかったか」ではありません。影響にはスペクトラムがあります。私たちが障害について考える際には、どの機能が影響を受けたのか、完全に利用できなくなったのか、それとも部分的な影響だったのか、そしてどれだけの数のお客様、ワークロード、場所に影響があったのかを考慮します。影響範囲を最小限に抑えるための重要な方法の1つは、複数のAvailability Zoneを使用して構築することです。EBSの基本原則の1つは、Availability Zone間の独立性です。これは、複数のAvailability Zoneにまたがる単一障害点を避けることを意味します。各Availability Zoneには、独立した電源、バックアップ電源、ネットワーク、そしてコントロールプレーンが備わっています。
影響範囲を最小限に抑えるもう一つの方法は、ボリュームの監視を確実に行うことです。障害が発生した際には、できるだけ早く対応できるようにする必要があります。多くのお客様から、アプリケーションのパフォーマンス問題が発生した際に、最も時間がかかるのは根本原因の特定だと聞いています。監視について考える際、実は3つの異なるレベルで監視を行う必要があります。最も詳細なのは、個々のボリュームレベルでの監視です。EBSはデフォルトで、接続されているすべてのボリュームの1分間メトリクスを提供します。これにより、IOパフォーマンスやレイテンシーなどを監視することができます。
中間層は、インスタンスレベルでのボリュームパフォーマンスの監視です。このレベルでは、インスタンスと、それに接続されているボリュームを監視します。このレベルでは、スループットやIOPSなど、インスタンスで実現しているパフォーマンスを監視できます。EC2はデフォルトで5分間の粒度でメトリクスを提供し、詳細メトリクスを有効にすることで1分間の粒度も利用できます。最も高次なメトリクスは、CloudWatchエージェントを使用したOSレベルでの監視で、これはカスタムCloudWatchメトリクスとして提供されます。これらのメトリクスでは、最短1秒の粒度まで取得できます。お客様に「ボリュームを監視していますか？」と尋ねると、「もちろんです」と答えることが多いのですが、詳しく聞いてみると、実際にはすべての層を監視しているわけではなく、OSレベルだけを監視していることがわかります。
OSレベルでの監視は、エンドユーザーへの影響を把握するのに役立ちますが、インフラストラクチャのどの層でパフォーマンスのボトルネックが発生しているかを特定することはできません。そのため、3つのレベルすべてを監視することが重要です。過去2年間、Amazon EBSは、お客様のボリューム監視を支援するため、より良いシグナルの提供に投資してきました。ベストプラクティスとして、3つの監視項目をお勧めしています。1つ目はボリュームの健全性です - ボリュームでIOが完了しているか、あるいは障害が発生しているかを確認します。2つ目はIOレイテンシーで、これはボリュームのストレージレイテンシーを示します。アプリケーションのレイテンシーが発生した場合、インフラストラクチャのどの層で発生しているかを知る必要があるためです。3つ目は総オペレーション数とバイト数です - ボリュームでどの程度のパフォーマンスを実現しているか、そしてワークロードに対してボリュームやインスタンスが適切なサイズになっているかを確認します。
昨年、私たちはボリュームの健全性に関するより良いシグナルの提供から始めました。2つの異なるAmazon CloudWatchメトリクスを導入しました。1つ目は、インスタンスレベルのステータスチェックで、これはインスタンスに接続されているすべてのボリュームを確認し、すべてのボリュームがIOを処理できているか、あるいは障害が発生しているボリュームがあるかを示すバイナリシグナルです。2つ目は、Stalled IOチェックと呼ばれるボリュームレベルのチェックで、ボリュームのIOパフォーマンスを確認し、このボリュームがIOを処理できているか、あるいは送信されたIOがキューに滞留しているかを判断します。これらのメトリクスは、接続されているすべてのボリュームに対して無料で提供される1分間メトリクスです。
また昨年、Fault Injection SimulatorにEBS Pause IOアクションも導入しました。これにより、ボリュームが数秒から数時間にわたって利用できなくなった場合に、システムがどのように応答するかをテストできます。短時間の中断に耐えられるか、あるいは長時間の中断時にシステムの回復がどのように機能するかを理解するのに役立ちます。また、これらの2つのCloudWatchメトリクスに基づいてアラームを設定している場合、そのアラームのテストも可能です。
今年は、IO レイテンシーに注力してきました。IO レイテンシーについて話す際、私たちは EBS ボリュームに対する読み取りや書き込み操作を送信してから、その操作が完了するまでの時間について言及しています。先ほど触れたように、アプリケーションに影響が出た場合に原因を特定できるよう、ボリュームレベルのレイテンシーを把握しておくことが重要です。 レイテンシーとボリュームの追跡をより簡単にするため、10月下旬に EBS は平均レイテンシーを追跡するための CloudWatch メトリクスセットをリリースしました。これにより、アプリケーションのレイテンシーやボリュームのレイテンシーに影響が出た場合の原因特定にかかる時間が短縮されます。しきい値に基づいてアラームを設定したり、異常な動作を検知するための CloudWatch の異常検知機能などを使用したりすることができます。これらのメトリクスは、接続されているすべてのボリュームで1分間隔で利用可能です。
3番目のカテゴリーである総操作数とバイト数に移りましょう。ボリュームで実際にどのくらいの負荷がかかっているかを知ることは重要です。ボリュームが適切なサイズに設定されていることを確認する必要があります。なぜなら、適切なサイズでない場合にボリュームのパフォーマンス制限に達すると、予想以上に高いレイテンシーが発生する可能性があるからです。 お客様から、パフォーマンス制限に達しているかどうかを把握するのが難しいというフィードバックをいただきました。ボリュームで高いレイテンシーが発生しているものの、それが制限に達しているためなのか、インフラの問題なのかが分からないという状況でした。10月に、パフォーマンス制限に継続的に達しているかどうかを通知する CloudWatch メトリクスセットをリリースしました。これにより問題の原因特定が容易になり、ボリュームのリサイズやノード間でのロードバランスが必要なタイミングが分かるようになりました。これらも接続されているボリュームで1分間隔で利用可能です。
レイテンシーに非常に敏感なアプリケーションをお持ちのお客様もいらっしゃることは承知しています。そういったお客様からは、1分間隔では対応するには長すぎる、IOパフォーマンスについてもっと詳細な情報が欲しいというご要望をいただいていました。そこで最近、EBS 詳細パフォーマンス統計機能をリリースしました。
この機能を使用すると、最小1秒単位の粒度でボリュームのパフォーマンスを確認することができます。これらの統計情報は、インスタンスの NVMe コントローラーから直接取得でき、ボリュームで何が起きているかをリアルタイムで把握することができます。アプリケーションでボリュームレベルのパフォーマンスのボトルネックが発生した場合、これらの情報を使って迅速に原因を特定することができます。
この機能が提供する情報について見ていきましょう。Amazon CloudWatch で取得できる統計情報と似ていますが、1分間隔ではなく異なる粒度で提供されます。EBS NVMe stats を NVMe CLI で使用すると、CloudWatch と同様に、総操作数、読み取り/書き込み操作数、総バイト数、時間を確認することができます。 また、ボリュームレベルの制限やインスタンスレベルの制限に達した場合のモニタリング機能も組み込まれています。アプリケーションがこれらの制限に達した時間をマイクロ秒単位で表示するため、継続的に制限に達しているかどうかを把握し、リサイズを検討する必要があるかどうかを判断することができます。
さらに、特に注目すべき機能として、ボリュームのI/Oレイテンシーヒストグラムを確認できるようになりました。これにより、ボリュームで実行されているすべてのI/O操作のパフォーマンスとその特性を把握することができます。一見、数字の羅列のように見えるかもしれませんが、このデータを使って印象的な分析を行うことができるんです。 これらのヒストグラムをGrafanaのような可観測性プラットフォームに取り込むと、パフォーマンスの興味深いトレンドを確認することができます。その期間中のボリュームにおけるP50、P90、P99のI/Oレイテンシーを実際に確認できるんです。Jodyが先ほど触れていたように、特にio2を使用しているレイテンシーに敏感なアプリケーションの場合、外れ値のレイテンシーがどのような状態かを確認し、必要に応じてロードバランシングや別のノードへの変更といった回復アクションを取ることができます。
自動リカバリーとディザスタリカバリー：EBSの高可用性戦略
これらが、私たちが今年取り組んできた可観測性機能の多くです。そして、これらの機能を皆様と共有できることを嬉しく思います。次に、3番目のカテゴリーである、リカバリーの計画と自動化の支援について説明したいと思います。というのも、リカバリーを自動化することは、常にお客様を支援する最も迅速な方法だからです。 AWSには、リカバリーを容易にするためのいくつかの機能があります。Amazon CloudWatchアラームを作成し、レイテンシーやI/O停止などのメトリクスに基づいてリカバリートリガーを定義し、AWS Lambda関数を構築して自動リカバリーを実現できます。EC2の問題については、インスタンスのステータスチェックに基づいてCloudWatchアラームでトリガーされるEC2の自動リカバリー機能を使用できます。リカバリーされたインスタンスは、同じインスタンスIDとメタデータを保持し、元のインスタンスと同一になります。
また、EC2インスタンスにはロードバランサーやAuto Scaling groupsを使用することもできます。Auto Scaling groupsは、異常のあるインスタンスを自動的に終了し、新しいインスタンスを作成することで、一定数のインスタンスを維持します。ワークロードが数分程度のリカバリー時間を許容できる場合は、Auto Scaling groupsが解決策となるかもしれません。 今年、Auto Scaling groupsをより使いやすくするために、アタッチされたステータスチェックをインスタンスステータスチェックAPIとEC2 Auto Scaling groupsに統合しました。EC2インスタンスが基盤となるEBSボリュームと通信できないためにインスタンスが異常になった場合、それを使用してAuto Scaling groupのリカバリーをトリガーできます。影響を受けたインスタンスが自動的に置き換えられ、アプリケーションの高可用性と信頼性が確保されます。
そして最後になりますが、災害復旧のために、スナップショットをAvailability Zone間でコピーすることができます。
また、災害復旧のために、スナップショットをAWS Region間でコピーすることもできます。ボリュームに障害が発生するという稀なケースでも、データを復旧できることが重要です。EBSには、スナップショットによる完全マネージド型の組み込みバックアップソリューションが用意されています。スナップショットは、S3に保存されるボリュームのポイントインタイムコピーで、11ナインの耐久性を提供します。EBSスナップショットは増分的でクラッシュコンシステントであり、インスタンスにアタッチされているすべてのボリューム、または一部のボリュームのクラッシュコンシステントなスナップショットを取得できます。
災害復旧において、スナップショットを別のリージョンやアカウントにコピーすることは一般的なユースケースです。 先週、私たちは Amazon EBS Time-based Snapshot Copy という新機能をリリースしました。これにより、スナップショットのコピー時間を15分から48時間の間で指定できるようになりました。この機能によって、時間に関する要件や制限を満たすことができ、コピーワークフローの予測可能性と一貫性が確保されます。災害復旧に使用する場合は、重要なスナップショットが Recovery Point Objectives (RPOs) を満たす時間内にコピーされることを保証できます。また、テスト目的で最新のデータを配布したり、開発者に定期的かつ頻繁に更新されたスナップショットデータを提供したりすることもできます。
重要なポイントとして、Time-based Snapshot Copy を使用することで、リージョン間やアカウント間で大量のスナップショットをコピーする際の管理オーバーヘッドを削減できます。Time-based Snapshot Copy は、標準のスナップショットコピーに適用される同時実行制限の影響を受けません。さらに、完全に異なるインフラストラクチャを使用しているため、標準コピーのパフォーマンスにも影響を与えません。 Time-based Snapshot Copy の有効化は非常に簡単です。Console、API、CLIのいずれかを通じて有効にできます。Consoleで有効にする場合は、ボタンをクリックして有効化し、希望する時間を入力するだけです。
ここまで、私とJodyで多くの内容をお伝えしてきました。 今年開発してきた多くの機能と、私たちのメンタルモデルにおけるロードマップについて、皆様と共有できることを大変嬉しく思います。 ご参加いただき、ありがとうございました。ご質問がございましたら、私とJodyは会場の端におりますので、お気軽にお声がけください。また、直接連絡していただくことも可能です。お時間を取っていただき、ここまでお越しいただき、ありがとうございました。セッションのアンケートもお忘れなく。私たちは常にフィードバックを確認し、改善に活かしています。本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion