AWS Database Migration Service (AWS DMS) は、データベースと分析ワークロードを AWS に迅速かつ安全に移行するためのマネージド型のマイグレーションおよびレプリケーションサービスです。移行中もソースデータベースは完全に稼働し続けるため、データベースに依存するアプリケーションのダウンタイムを最小限に抑えることができます。AWS DMS は、最も広く使用されている商用およびオープンソースの ソースデータベース と ターゲットデータベース の間でデータを移行できます。 SQL Server は Microsoft が開発した リレーショナルデータベース です。 Amazon Relational Database Service (Amazon RDS) for SQL Server を使用すると、 クラウド 上で SQL Server の展開を簡単に設定、運用、スケーリングできます。Amazon RDS はデータ レプリケーションをサポートしており、 変更データキャプチャ (CDC) を有効にすることが、AWS DMS と Amazon RDS for SQL Server を使用するための 前提条件 の 1 つとなっています。CDC はテーブルのデータに加えられた変更をキャプチャします。それぞれの変更に関するメタデータを格納し、後で参照できます。 この投稿では、CDC パラメータについて深く掘り下げ、AWS DMS の設定時の影響について説明するとともに、いくつかのベストプラクティスについても説明します。 前提条件 この投稿に沿って進めるには、次の AWS サービスに精通している必要があります。 AWS DMS Amazon RDS for SQL Server さらに、このソリューションに必要なリソースを起動するのに十分な権限を持つ AWS アカウントが必要です。 AWS DMS は Amazon RDS for SQL Server とどのように連携するのか Amazon RDS for SQL Server の場合、AWS DMS は Microsoft の関数を使用してトランザクションログを読み取り、デフォルトで上位 50,000 イベントを取得します。AWS DMS は、 AWS DMS タスク で定義されたテーブルに関連する特定のパーティション ID のデータベースログを照会することから始まります。パーティション ID は、フルロードと CDC の両方で、各テーブルの再ロード、タスクの再起動、タスクの再開時に読み取られます。AWS DMS はオブジェクト ID を取得し、それらのオブジェクト ID に対応するデータパーティション ID を取得します。パーティション ID を取得した後、関連するパーティションをトランザクションログからフェッチします。このサイクルは 1 秒ごとに実行されます。 次の図は、アーキテクチャを示しています。この例では、Amazon RDS for SQL Server をソースとして使用しています。AWS DMS タスクのターゲットは、 サポートされている任意のエンドポイント になります。 AWS DMS は、Microsoft の関数を使ってトランザクションログを読み取り、AWS の DMS タスクの対象となるテーブルとソースデータベースで CDC が有効になっている必要があります。 なぜ AWS DMS で CDC が必要なのか ? テーブルで CDC が有効になると、SQL Server は cdc スキーマにテーブルを作成します。作成されたテーブル (変更テーブル) には変更データが格納され、トラッキングされているスキーマとテーブルに基づいて名前が付けられます。たとえば、 dbo スキーマに customer という名前のテーブルがある場合、 dbo.customer テーブルに対するすべての変更を記録するために cdc.customer_CT という名前のテーブルが cdc スキーマに作成されます。 AWS DMS は変更テーブルを読み取りません。AWS DMS は、変更がトランザクションログに確実に記録されるように CDC を有効にする必要があります。前のセクションで説明したように、AWS DMS は Microsoft の関数を使ってトランザクションログから変更を読み取ります。ソース側の次のテーブルを考えてみましょう。 CREATE TABLE [ dbo ] . [ dmstest ] ( [ id ] [ int ] NOT NULL , [ name ] [ varchar ] ( 50 ) NULL , CONSTRAINT [ PK_dmstest ] PRIMARY KEY CLUSTERED ( [ id ] ASC ) WITH ( PAD_INDEX = OFF , STATISTICS_NORECOMPUTE = OFF , IGNORE_DUP_KEY = OFF , ALLOW_ROW_LOCKS = ON , ALLOW_PAGE_LOCKS = ON , OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF ) ON [ PRIMARY ] ) ON [ PRIMARY ] SQL このテーブルに UPDATE ステートメントを発行して [name] 列を更新すると、 [RowLog Contents 0] と [RowLog Contents 1] に変更情報が更新されます。AWS DMS がソース上で実行する次のクエリの一部を示します。 select top 50000 [ Current LSN ] , [ operation ] , [ RowLog Contents 0 ] , [ RowLog Contents 1 ] -- After Image SQL クエリの結果を見ると、2 番目のレコードに CDC を有効にした後に発行した UPDATE ステートメントの状態がトランザクションログにキャプチャされていることが分かります。 Current LSN operation RowLog Contents 0 RowLog Contents 1 0000014f:0000c16d:0002 LOP_MODIFY_ROW 0x1800 746573747573657267 0x1900 74657374757365726162 0000014f:0000c9ba:0016 LOP_MODIFY_ROW 0x300008000200000002000001001900 74657374757365726162 0x300008000200000002000001001800 746573747573657267 CDC パラメータの理解 CDC では、2 つのジョブが作成されます。 キャプチャジョブ – トランザクションログファイルを読み取り、変更をトラッキングするテーブルにプッシュします。 クリーンアップジョブ – 保持期間を過ぎた変更トラッキングテーブルのレコードを削除します。 以下は、AWS DMS に関連する CDC パラメータ です。 max_trans – 各スキャンサイクルで処理するトランザクションの最大数 max_scans – ログからすべての行を抽出するために実行するスキャンサイクルの最大数 continuous – キャプチャジョブを継続的に実行するか (1)、1回だけ実行するか (0) を示します polling_interval – ログスキャンサイクル間の秒数 retention – 変更行がテーブルに保持される分数 AWS DMS は変更テーブルを読み取らないので、トランザクションログの変更の保持を制御するために CDC パラメータを調整する必要があります。 次のセクションでは、 max_trans 、 max_scans 、 polling_interval パラメータがトランザクションログ内のレコードの保持にどのように役立つのか、AWS DMS が変更をキャプチャするのに十分な期間変更が保持されるように調整する方法について説明します。 CDC パラメータの実行 これらのパラメーターを説明するために、次の手順を踏みます。 dmscdc データベースとその中の dmstestcdc テーブルを作成してください。 create database dmscdc ; use dmscdc ; CREATE TABLE dbo . dmstestcdc ( n INT NOT NULL PRIMARY KEY ) ; SQL データベース dmscdc およびテーブル dmstestcdc で CDC を有効にします。 exec msdb . dbo . rds_cdc_enable_db 'dmscdc' ; use dmscdc ; exec sys . sp_cdc_enable_table @source_schema = 'dbo' , @source_name = 'dmstestcdc' , @role_name = 'CDCRole' , @supports_net_changes = 1 ; SQL CDC パラメータを調整して、ログレコードが十分な期間保持されるようにする必要があります。そうすることで、AWS DMS がトランザクションレコード、つまり、ソースデータベースのトランザクションログファイルで探している特定のログシーケンス番号 (LSN) を照会できるようになります。これらは次の要因に左右されます。 ターゲットがソースに比べてどれくらいトランザクションが遅れているか CDC ジョブの実行頻度、つまり特定のポーリング間隔はどのくらいか Maxtrans と Maxscans の値は何か。これらのパラメータは、CDC が各実行でどれくらいのトランザクションを処理するかを決定します。 次のように取り込みジョブを構成してください。取り込みジョブのパラメーターを変更する場合は、毎回 CDC ジョブを停止して再起動する必要があります。この場合、 pollinginterval を変更する必要があります。 EXECUTE sys . sp_cdc_change_job @job_type = N 'capture' , @pollinginterval = 3599 ; --Setting the polling interval for 1 hour EXEC sys . sp_cdc_stop_job @job_type = N 'capture' ; EXEC sys . sp_cdc_start_job @job_type = N 'capture' ; SQL 次のコマンドを実行して CDC パラメータを確認してください。 exec sys . sp_cdc_help_jobs ; SQL job_id job_type job_name maxtrans maxscans continuous pollinginterval retention threshold A49487C5-BF3C-4A8C-9385-6AFA7A3541B9 capture cdc.dmscdc_capture 500 10 1 3599 0 0 17511020-59D2-4C9E-BEA9-0578C0D23B11 cleanup cdc.dmscdc_cleanup 0 0 0 0 4320 5000 前述の設定では、キャプチャジョブは 1 時間の周期で 5,000 レコード ( maxtrans * maxscans ) を処理します。 テーブル dmstestcdc にレコードをいくつか挿入して確認してください。 DECLARE @max AS INT , @min AS INT ; SET @max = 100000 ; SET @min = 1 ; WHILE @min <= @max BEGIN INSERT INTO dbo . dmstestcdc VALUES ( @min ) ; SET @min = @min + 1 ; END SQL キャプチャジョブは、トランザクションログから前の取引を読み取り、それらを replicated されたものとしてマークします。この場合は 100,001 レコードです。CDC ジョブが実行されると、キャプチャジョブはそれらの取引を完了としてマークします。 次のクエリを実行して CDC セッションを確認してください。これにより 10 行が取得されるはずです。このクエリにより、CDC が処理したレコード数が分かります。今回の場合は 5,000 件です。 SELECT tran_count , start_time , end_time , scan_phase from sys . dm_cdc_log_scan_sessions where scan_phase <> 'Aggregate' order by end_time desc SQL tran_count start_time end_time scan_phase 500 2023-12-07 20:34:15.100 2023-12-07 20:34:15.123 Done 500 2023-12-07 20:34:15.067 2023-12-07 20:34:15.083 Done 500 2023-12-07 20:34:15.037 2023-12-07 20:34:15.053 Done 500 2023-12-07 20:34:15.003 2023-12-07 20:34:15.023 Done 500 2023-12-07 20:34:14.963 2023-12-07 20:34:14.990 Done 500 2023-12-07 20:34:14.927 2023-12-07 20:34:14.950 Done 500 2023-12-07 20:34:14.883 2023-12-07 20:34:14.910 Done 500 2023-12-07 20:34:14.840 2023-12-07 20:34:14.870 Done 500 2023-12-07 20:34:14.797 2023-12-07 20:34:14.827 Done 500 2023-12-07 20:34:14.540 2023-12-07 20:34:14.773 Done 前述のレコードは、通常 5 分ごとに行われる Amazon RDS for SQL Server のトランザクションログのバックアップ時にトランザクションログから削除されます。これにより、トランザクションログのサイズを維持し、LSN を進めることができます。残りのレコード (95,001件) は、次のキャプチャジョブの実行時に取り込まれます。 SQL Server は CDC によってトランザクションが読み取られた後でしか トランザクションログをフラッシュしません。トランザクションログに保持するレコード数と AWS DMS のレプリケーションラグのバランスを取る必要があります。この場合、ポーリング間隔を短くすることで、キャプチャジョブのパラメータを積極的に設定します。その結果、トランザクションログから LSN が欠落するシナリオが発生する可能性があります。トランザクションログの切り捨てを回避して、変更が十分な期間トランザクションログに保持されるようにするには、次のコマンドを実行してポーリング間隔を 1 日に設定することをお勧めします。 use dbname EXEC sys . sp_cdc_change_job @job_type = 'capture' , @pollinginterval = 86399 exec sp_cdc_stop_job 'capture' exec sp_cdc_start_job 'capture' SQL CDC の履歴情報のキャプチャ キャプチャジョブの履歴情報を監視するには、 sys.dm_cdc_log_scan_sessions テーブルを照会できます。このテーブルには、現在のデータベース内の各ログスキャンセッションに対して 1 行が含まれています。最大 32 のスキャンセッションが含まれます。次のクエリを実行して、最新の 10 レコードを取得します。 SELECT session_id , start_time , end_time , duration , scan_phase , error_count , tran_count , command_count , last_commit_cdc_time , latency , empty_scan_count , failed_sessions_count FROM sys . dm_cdc_log_scan_sessions order by end_time desc OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY ; SQL 以下はサンプル出力です。 session_id start_time end_time duration scan_phase error_count tran_count command_count last_commit_cdc_time latency empty_scan_count failed_sessions_count 0 2023-12-07 19:21:27.283 2023-12-08 00:34:12.837 6 Aggregate 0 125001 125001 2023-12-07 19:50:32.657 17020 0 0 651 2023-12-08 00:34:12.820 2023-12-08 00:34:12.837 0 Done 0 500 500 2023-12-07 19:50:32.657 17020 0 0 650 2023-12-08 00:34:12.790 2023-12-08 00:34:12.810 0 Done 0 500 500 2023-12-07 19:50:31.700 17021 0 0 649 2023-12-08 00:34:12.760 2023-12-08 00:34:12.780 0 Done 0 500 500 2023-12-07 19:50:30.707 17022 0 0 648 2023-12-08 00:34:12.703 2023-12-08 00:34:12.723 0 Done 0 500 500 2023-12-07 19:50:29.757 17023 0 0 647 2023-12-08 00:34:12.670 2023-12-08 00:34:12.693 0 Done 0 500 500 2023-12-07 19:50:28.620 17024 0 0 646 2023-12-08 00:34:12.633 2023-12-08 00:34:12.660 0 Done 0 500 500 2023-12-07 19:50:27.523 17025 0 0 645 2023-12-08 00:34:12.587 2023-12-08 00:34:12.620 0 Done 0 500 500 2023-12-07 19:50:26.527 17026 0 0 644 2023-12-08 00:34:12.530 2023-12-08 00:34:12.573 0 Done 0 500 500 2023-12-07 19:50:25.490 17027 0 0 643 2023-12-08 00:34:12.500 2023-12-08 00:34:12.520 0 Done 0 500 500 2023-12-07 19:50:24.450 17028 0 0 ベストプラクティスと既知の問題 このセクションでは、CDC パラメーターに関するベストプラクティスと考慮事項をいくつか説明します。 Multi-AZ インスタンスでのフェイルオーバー時にトランザクションログレコードが切り捨てられる プライマリインスタンスで CDC パラメータを変更した場合は、必ず rds_set_configuration コマンドを実行して、フェイルオーバー時にも変更内容が保持されるようにしてください。 例えば、 dms_test データベース上で次のサンプルコマンドを実行して、 maxtrans と pollinginterval パラメータを設定できます。 USE dms_test ; EXEC sys . sp_cdc_change_job @job_type = 'capture' , @maxtrans = 10000 , @pollinginterval = 6000 ; SQL フェイルオーバー後もこれらの値が保持されるように、次のコマンドを実行してください。 EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxtrans' , 10000 ; EXEC rdsadmin . . rds_set_configuration 'cdc_capture_pollinginterval' , 6000 ; SQL AWS DMS レプリケーションインスタンスの計画的フェイルオーバーまたはメンテナンス Amazon RDS for SQL Server の場合、ソースでメンテナンス作業を行う際、あるいは関連する AWS DMS レプリケーションインスタンスの計画的なスケーリングを行う際に、AWS DMS タスクが停止する度にキャプチャジョブが実行されないようにする必要があります。キャプチャジョブが実行されると、スキャンされたイベントは Amazon Simple Storage Service (Amazon S3) で 5 分ごとにトランザクションログバックアップが行われるときにトランザクションログから削除されます。 次のコマンドを実行してキャプチャジョブを停止してください。 exec sp_cdc_stop_job 'capture' SQL AWS DMS タスクを停止します。 必要なメンテナンスを完了します。 AWS DMS タスクを再開します。 ソースの遅延 が 0 になるのを待ちます。 次のコマンドを実行してキャプチャジョブを開始します。 exec sp_cdc_start_job 'capture' SQL AWS DMS タスクは、上記の手順に従わない場合、次のエラーメッセージで失敗します。 2023-10-06T15:02:05 [SOURCE_CAPTURE ]E: Failed to access LSN '0000019f:00007fff:0008' in the backup log sets since BACKUP/LOG-s are not available. [1020465] (sqlserver_endpoint_capture.c:813) JSON ソースでキャプチャジョブを停止した後に LSN が切り捨てられているのを確認した場合、アクティブなトランザクションログ内に切り捨てを防ぐ CDC イベントがない可能性があります。これはデータベースがアイドル状態にあるか、トランザクション数が少ない場合に発生する可能性があります。この場合、手順は次のとおりです。 次のコマンドを実行してキャプチャジョブを停止してください。 exec sp_cdc_stop_job 'capture' SQL AWS DMS タスクを停止する前に、CDC 対応のデータベースにいくつかのトランザクションまたは変更があることを確認してください。毎秒 DML ステートメントを実行するスクリプトを実行できます。テストスクリプトを作成する場合は、このセクションの後半に記載されている手順に従ってください。 AWS DMS タスクを停止します。 必要なメンテナンスを完了させます。 AWS DMS タスクを再開します。 ソースレイテンシを監視して同期を待ちます。 ステップ 2 で設定したスクリプトを停止します。 次のコマンドを実行してキャプチャジョブを開始します。 exec sp_cdc_start_job 'capture' SQL ステップ 2 で言及されたテストスクリプトを実行するためのスクリプトを設定するには、以下の手順に従ってください。以下のスクリプトでは、dbo スキーマの下に test_table という名前のテーブルを作成し、その test_table テーブルで CDC を有効にします。次に、SQL Server エージェントジョブを設定し、上記のテーブルにレコードを挿入してから削除します。これにより、CDC ジョブによってピックアップされる必要のあるトランザクションログに変更があり、トランザクションログの切り捨てを防ぐことができます。 テストテーブルを作成します。 create table dbo . test_table ( id int not null PRIMARY KEY ) ; SQL 新しいテーブルを CDC に追加してください。 use dmscdc ; exec sys . sp_cdc_enable_table @source_schema = 'dbo' , @source_name = 'test_table' , @role_name = 'CDCRole' , @supports_net_changes = 1 ; SQL Amazon RDS で SQL Server エージェントジョブを作成し、1 分ごとにレコードを挿入または削除します。エージェントジョブで適切な owner_login_name と database_name の値を使用してください。 USE [ msdb ] GO /****** Object: Job [aws_dms_traffic_to_test_table] Script Date: 10/9/2023 4:17:28 PM ******/ BEGIN TRANSACTION DECLARE @ReturnCode INT SELECT @ReturnCode = 0 /****** Object: JobCategory [[Uncategorized (Local)]] Script Date: 10/9/2023 4:17:28 PM ******/ IF NOT EXISTS ( SELECT name FROM msdb . dbo . syscategories WHERE name = N '[Uncategorized (Local)]' AND category_class = 1 ) BEGIN EXEC @ReturnCode = msdb . dbo . sp_add_category @class = N 'JOB' , @type = N 'LOCAL' , @name = N '[Uncategorized (Local)]' IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback END DECLARE @jobId BINARY ( 16 ) EXEC @ReturnCode = msdb . dbo . sp_add_job @job_name = N 'aws_dms_traffic_to_test_table' , @enabled = 1 , @notify_level_eventlog = 0 , @notify_level_email = 0 , @notify_level_netsend = 0 , @notify_level_page = 0 , @delete_level = 0 , @description = N 'No description available.' , @category_name = N '[Uncategorized (Local)]' , @owner_login_name = N 'admin' , @job_id = @jobId OUTPUT IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback /****** Object: Step [generate_traffic] Script Date: 10/9/2023 4:17:28 PM ******/ EXEC @ReturnCode = msdb . dbo . sp_add_jobstep @job_id = @jobId , @step_name = N 'generate_traffic' , @step_id = 1 , @cmdexec_success_code = 0 , @on_success_action = 1 , @on_success_step_id = 0 , @on_fail_action = 2 , @on_fail_step_id = 0 , @retry_attempts = 0 , @retry_interval = 0 , @os_run_priority = 0 , @subsystem = N 'TSQL' , @command = N 'insert into dbo.test_table values (30); delete from dbo.test_table where id = 30; ' , @database_name = N 'dmscdc' , @flags = 0 IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback EXEC @ReturnCode = msdb . dbo . sp_update_job @job_id = @jobId , @start_step_id = 1 IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback EXEC @ReturnCode = msdb . dbo . sp_add_jobschedule @job_id = @jobId , @name = N 'schedule for running DML statements for generating user_traffic' , @enabled = 1 , @freq_type = 4 , @freq_interval = 1 , @freq_subday_type = 4 , @freq_subday_interval = 1 , @freq_relative_interval = 0 , @freq_recurrence_factor = 0 , @active_start_date = 20231006 , @active_end_date = 99991231 , @active_start_time = 0 , @active_end_time = 235959 , @schedule_uid = N '84a2b2ab-4234-40a3-add4-c04d561ad88f' IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback EXEC @ReturnCode = msdb . dbo . sp_add_jobserver @job_id = @jobId , @server_name = N '(local)' IF ( @ @ERROR <> 0 OR @ReturnCode <> 0 ) GOTO QuitWithRollback COMMIT TRANSACTION GOTO EndSave QuitWithRollback: IF ( @ @TRANCOUNT > 0 ) ROLLBACK TRANSACTION EndSave: GO SQL AWS DMS コンソールで、AWS DMS タスクのテーブル選択ルールにワイルドカード (%) を使用してこのテーブルを複製する場合は、 マッピング ルールを使用してこのテーブルを AWS DMS タスクから除外してください。 { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "dbo", "table-name": "test_table" }, "rule-action": "exclude", "filters": [] }, JSON SQL Server インスタンスの RDS の計画的な再起動またはフェイルオーバー RDS for SQL Server エージェントサービスは、RDS for SQL Server インスタンスの再起動やフェイルオーバーが発生するたびに再起動し、これにより再起動またはフェイルオーバー後に CDC ジョブが再実行されます。トランザクションログの切り捨てを回避するには、次の手順に従ってください。 AWS DMS タスクを停止します。 フェイルオーバー後に元に戻すため、現在の maxtrans と maxscans の値を取得します。 sys . sp_cdc_help_jobs ; SQL CDC の設定を変更して、 maxtrans と maxscans を 1 に設定します。 EXEC sys . sp_cdc_change_job @job_type = 'capture' , @maxtrans = 1 , @maxscans = 1 exec sp_cdc_stop_job 'capture' GO SQL フェイルオーバー後も CDC パラメーターを保持するため、次のステートメントを実行してください。 EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxtrans' , 1 ; EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxscans' , 1 ; SQL RDS for SQL Server インスタンスを再起動します。 AWS DMS タスクを再開します。 キャプチャされた構成で、キャプチャされたジョブを再起動します。次のスクリプトでは、 maxtrans を 500、 maxscans を 10 と想定していますが、ステップ 2 でキャプチャした値を使用する必要があります。 EXEC sys . sp_cdc_change_job @job_type = 'capture' , @maxtrans = 500 , @maxscans = 10 exec sp_cdc_stop_job 'capture' exec sp_cdc_start_job 'capture' GO SQL フェイルオーバー後も CDC パラメータを保持するために、次のステートメントを実行してください。 EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxtrans' , 500 ; EXEC rdsadmin . . rds_set_configuration 'cdc_capture_maxscans' , 10 ; SQL 後片付け 定期的な課金を避けるために、リソースをクリーンアップしてください。 AWS DMS コンソールで、設定したすべての AWS DMS タスクを削除します。 次のコマンドを実行してデータベースを削除します。 EXECUTE msdb . dbo . rds_drop_database N 'dmscdc' SQL 結論 この投稿では、Amazon RDS for SQL Server をソースとして AWS DMS タスクを構成する際の CDC パラメーターの設定の重要性を説明し、さらにベストプラクティスについても説明しました。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Suchindranath Hegde は、Amazon Web Services のデータマイグレーションスペシャリストソリューションアーキテクトです。AWS DMS を使用して AWS クラウドへのデータ移行に関するガイダンスと技術支援をお客様に提供しています。 Abhishek Chaturvedi は、Amazon Web Services の DMS チームのシニアデータベースエンジニアです。 Mahesh Kansara は、Amazon Web Services のデータベースエンジニアリングマネージャーです。彼は開発およびエンジニアリングチームと密接に協力し、移行およびレプリケーションサービスの改善に取り組んでいます。また、お客様と協力し、さまざまなデータベースおよび分析プロジェクトに関するリードとテクニカルサポートを提供し、AWS を使用する際のソリューションの価値向上をサポートしています。 Junu Thankappan は、Amazon Web Services のシニアデータベースエンジニアです。彼は AWS RDS チームに所属し、商用データベースエンジンと SQL Server に注力しています。

このブログは、 “Boost sales team productivity and effectiveness with Sales Concierge on AWS” の翻訳です。 急速に進化する製薬業界において、営業チームは医療従事者 (HCP) との効果的なエンゲージメントという大きな課題に直面しています。薬剤の複雑さや、革新的なGo-to-Marketモデル、そして激しい競争といったチャレンジの中で、営業チームに求められているのは、重要なデータへのアクセス、HCPとのコミュニケーションに関するガイダンス、そして事務作業の自動化などです。これらのニーズに応えることで、企業は営業チームを強化し、適切な顧客エンゲージメントを実現し、事業目標を達成することができます。このブログでは、Amazon Web Services (AWS) のAIを活用したアーキテクチャーガイダンス「Sales Concierge」を紹介します。これは、データ、インサイト、ツールを統合し、営業チームの生産性と効率を高めるものです。最近の マッキンゼーの記事 によると、営業チームのパフォーマンスは生成AIツールを利用することにより、生産性と効率を10~15%改善し、売上を1~2%押し上げる可能性があると述べられています。 現在の課題 現在、製薬企業の営業チームは、コールプランニング、コール後の報告、社内の事務作業など、日々の責任を果たすために、様々なツールやシステムを使い分けなければなりません。この断片化されたアプローチでは、生産性の課題が生じがちです。 HCPの好み、治療パターン、市場動向といった重要な情報へのアクセスの遅れ さまざまな情報源からのデータとインサイトを統合する時間の増加 HCPとのエンゲージメントを最適化するための有益な推奨を見逃すリスク これらの個別のシステムを操作する時間は、HCPや他の主要な関係者との対話といった、より価値のあるアクティビティを阻害しています。さらに、システムの手動更新の遅れや、管理業務に費やされる時間の無駄も、営業チームが本来の使命に集中できなくなる原因になっています。 これらの課題に加えて、現在の活動推奨エンジンはルールベースが主流で、個々のHCPシナリオや好みに合わせた賢明なコンテクスト化された推奨を提供できていません。このようなパーソナライズやインテリジェンスの欠如が、営業担当者 (MR) による利用率の低さにつながっており、HCPとの優れたエンゲージメントを実現し、ひいては業務目標の達成につなげることができずにいます。 これらの生産性課題から、データ、インサイト、ツールを統合したプラットフォームが切実に必要とされるようになりました。これにより、製薬企業の営業チームは戦略的な営業に集中し、HCPとのやり取りを強化することができるようになります。 ソリューションの概要 生成AIを活用したパーソナルアシスタントがすぐ手元にあることを想像してみてください。このソリューションでは、MRがHCPエンゲージメントのためのインサイトとガイダンスを受けられるだけでなく、企業レポート、ノウハウ、メトリクスへの簡単なアクセスも可能になります。加えて、事務作業、データ入力、その他の問い合わせにも対応します。 このブログでは、製薬企業が独自のカスタマイズされたSales Conciergeソリューションを構築し、営業チームを強化する方法を包括的にご案内します。このガイダンスには、自然言語インターフェース、重要データとインサイトの統合、事務作業の自動化を可能にする直感的な生成AIソリューションを構築するための主要な機能、サービス、ベストプラクティスが含まれています。 図1: Sales Concierge アプリケーションの例。1つ目の画像ではチャットなどのモジュールへのリンクがあるナビゲーションページ、2つ目の画像ではHCPとのやり取りについてのメトリクスがわかるインサイトページが示されている 。 この Sales Concierge ガイダンスの目的は、生成AIと自動化機能を活用し、営業の生産性、顧客エンゲージメント、業務目標達成を促進するためのフレームワークを提供することです。このガイダンスを検討する際は、これらの原則と技術を活用して、組織と営業チームの独自のニーズに合ったソリューションを構築する方法を検討してください。 Sales Concierge ガイダンスは、Veeva Vault CRM、Salesforce Marketing Cloud、データ製品、データ資産、製薬業界で広く使用されている他の営業・マーケティングツールとシームレスに統合されるよう設計されています。強力な統合機能を活用することで、このソリューションはこれらのシステムからデータにアクセスし、統合することができます。これにより、MRは顧客情報、エンゲージメント履歴、市場インサイトを包括的に把握できるようになり、Sales Concierge 内でそれらにアクセスできるようになります。 Sales Concierge ガイダンスを成功させるには、下記のようなデータへの統一されたアクセスを可能にすることが重要です。組織は Sales Concierge を使って、さまざまなデータドメインからデータとコンテンツを取得できます。これには、事前処理されたデータ製品、生のデータセット、非構造化ナレッジベース、さまざまなデータドメインのアプリケーションやAPIが含まれます。 図2: Sales Concierge アプリケーションを通じて営業チームの質問に答えるためのデータソース、API、アプリケーションの一覧。 この Sales Concierge ガイダンスには、生産性、効率性、優れた顧客エンゲージメントを促進する主要なビジネス機能を提供するチャットインターフェイスも含まれます。 マルチモーダルチャット: 生成AIによって動作し、音声とテキストの両方の入力を使って、データ、インサイト、システムと自然言語でやり取りできるようになります。オーケストレーションエンジンがこれらのやり取りを処理し、ユーザーの意図を検出し、質問を適切なデータソースに振り分けます。 プロセスは意図の検出から始まり、オーケストレーションエンジンがユーザーの質問を解釈し、エージェント、ナレッジベース、プロンプトなどの適切なツールを特定します。これらのツールは、SQLクエリの生成 (Text to SQL)、APIコールの作成 (Test to API)、非構造化データソースからのコンテンツ取得など、さまざまなタスクを実行します。これにより、MRはHCPインサイト、市場情報、アカウント詳細、競合情報、テリトリーデータ、業界トレンド、Next Best Action 推奨など、さまざまなデータやインサイトにクエリを投げることができます。 図3: ユーザーが生成AIオーケストレーションエンジンによって動作するSales Concierge アプリケーションとやり取りする方法。このエンジンはエージェントとナレッジベースを使ってユーザーの質問に応答する。 デジタルエージェント: 生成AI エージェントを活用することで、Sales Concierge ソリューションは、コールサマリの作成やコールノートの記録などのタスクを管理できます。関連するユースケース (サポートチケットの作成、CRMへのコールノートの更新、会議予定の更新など) のためにシステムを更新することもできます。同時に、さまざまなアプリケーションやデータ資産にアクセスするための一元的なデジタル窓口機能を提供します。 Sales Concierge は、さまざまなアプリ、ポータル、システムを起動するための入り口として機能し、営業チームがリソースにアクセスする際の中心的で効率的な方法を提供します。この革新的なアプローチは、営業チームが機能する方法に変革をもたらすものであり、生成AIと自動化機能を活用して、生産性を高め、顧客とのやり取りを向上させ、全体的な目標達成を実現します。 実行可能なインサイト: 複数のデータソースと統合することで、Sales Concierge ソリューションは、HCPとのより効果的なエンゲージを可能にするさまざまな重要な質問に答えることができます。これには、HCPインサイトとエンゲージメント、販売実績と市場シェア、日々の計画、トレーニングとパフォーマンス追跡に関する包括的な詳細が含まれます。 図4: Sales Concierge アプリケーション内のチャットモジュールの例を示す図。1つ目の画像にはサンプル質問付きのチャットインターフェースが、2つ目の画像には、自然言語の質問がSQLに変換され、データベースからデータを取得し、自然言語で出力される様子が示されている。 Sales Concierge が答えられるサンプル質問は次のとおりです。 HCPインサイトとエンゲージメント このHCPには新規および継続中の患者がどれくらいいますか? このHCPに最後に送信されたメッセージは何ですか? このHCPの処方傾向や情報収集活動はどうですか? このHCPとの過去のやりとり (メール、サンプル提供、競合他社訪問など) は何がありましたか? このHCPとの今後の訪問、カンファレンス、イベントは予定されていますか? コールプランニング このHCPへの未対応のフォローアップ、未解決のリクエスト、アクション項目はありますか? 今日はどのHCPを訪問すべきですか? このHCPの好みに基づいて、Next Best Actionやおすすめは何ですか? 売上・ブランドパフォーマンス 当社製品の最近の市場シェアと販売量の変化はどうですか? このテリトリーにおいて、当社の製品と主要競合製品を比べるとどうですか? 関連するデータソースと統合することで、Sales Concierge はMRに包括的なインサイトと実行可能な情報を提供します。これにより、営業チームは より情報に基づいた意思決定ができ、パーソナライズされたエンゲージメントを提供し、医療従事者とのやり取りでより大きな成功を収めることができます。 アーキテクチャの概要 このアーキテクチャは、AWSの幅広い機能とサービスを活用し、Sales Concierge ソリューションを効率的かつ効果的に実装するためのガイダンスを作成しています。この包括的で、モジュール化された、拡張性と柔軟性のあるアーキテクチャは、導入、スケーラビリティ、コスト効率の重要な成功要因に対応するよう設計されており、さまざまな機能を無理なく統合しています。 Sales Concierge の主な機能には、自然言語と音声インタラクション、構造化データ (Text to SQL) へのアクセス、APIと非構造化データへのアクセス、最適化された待ち時間とコストがあります。また、モジュール化と柔軟なデザイン、プライバシーと責任あるAIコントロール、強力なデータセキュリティとガバナンスコントロールも備えています。 このソリューションのインテリジェンスを支えているのが、AIエージェントです。これらは、システムや接続されたアプリケーションとのやり取りに必要なツール、API、アクションを適切に選択できます。これにより、MRの日常的なタスクを合理化し、ワークフローのオーケストレーションを効率化することができます。 図5: このアーキテクチャ図は、Sales Concierge ソリューションを支える包括的なAWSサービスを示している。アプリケーション、オーケストレーション、生成AIツール、データ管理の必要なサービスが含まれている 。 フロントエンドでは、 AWS Amplify を利用して、シームレスで軽快なユーザーインターフェースを提供しています。AWS Amplify は Amazon Lex と Amazon Polly とシームレスに統合し、マルチモーダルのインタラクションを実現しています。MRは音声とテキストの両方の入力でシステムとやり取りでき、ニーズに最適な形式で応答を受け取ることができます。 このフロントエンドは、 Amazon API Gateway を通してバックエンドに接続されています。API Gateway は、APIレイヤーを管理および保護し、ユーザーのリクエストを適切なサービスにルーティングします。バックエンドの中核処理は AWS Lambda が行い、さまざまなユーザーリクエストを処理します。 動的なコンテンツ生成、データ処理、生成AIを活用したインサイトを実現するため、このアーキテクチャは Amazon Bedrock と統合しています。Amazon Bedrock は、主要なAI企業による高性能な基盤モデル (FM) を選択できる、フルマネージドサービスです。 Amazon Bedrock Prompt Flows コンポーネントは、ユーザー入力をオーケストレーションし、その意図を検出し、ユーザーのニーズに基づいて複数のターゲットにクエリを振り分けます。 構造化データに対しては、 Amazon Bedrock Agents が Text to SQL のアプローチを使ってデータベースからデータにアクセスします。リアルタイムに近い情報に対しては、Text to API のアプローチを使用します。Text to API のアプローチを使うと、Amazon Bedrock Agent はユーザーに代わってアクションを実行することもできます。 Amazon Bedrock Knowledge Bases は、フルマネージド機能で、Retrieval Augmented Generation (RAG) ワークフロー全体を実装できます。これは、非構造化データリポジトリに基づいて質問に答えるために使用されます。Amazon Bedrock モデルは、 Amazon Bedrock Prompt Management 機能で管理されるプロンプトカタログから最適なプロンプトを選択し、カスタマイズされた応答を生成します。これらの応答は、その後 Amazon Polly または音声機能の Amazon Lex を使ってテキストから音声に変換され、ユーザーエクスペリエンスが向上します。 データの保存と取得には、このアーキテクチャは Amazon DynamoDB を使ってユーザーインタラクションのコンテキストとパーソナライゼーションを保持しています。大きなデータは Amazon Simple Storage Service (Amazon S3) に保存され、Amazon Bedrock Knowledge Bases と同期して、生成AIによるインサイトを強化しています。構造化データは Amazon Redshift のようなサービスに保存され、Amazon Bedrock Agents はText to SQL のアプローチを使ってこのデータに直接クエリを投げることができます。 システムのセキュリティを確保するため、このアーキテクチャには認証のための Amazon Cognito 、データガバナンスのための AWS Lake Formation 、コンテキストを踏まえたグラウンディングチェックとセーフガードデータのための Amazon Bedrock Guardrails といったAWSサービスを組み込んでいます。さらに、アクセス管理のための AWS Identity and Access Management (IAM) 、監査のための AWS CloudTrail 、モニタリングのための Amazon CloudWatch も利用されています。これらのサービスにより、Sales Concierge ソリューションは関連する規制 (医療保険の相互運用性と説明責任に関する法律 (HIPAA) や一般データ保護規則 (GDPR) など) を順守し、厳格なデータプライバシーとセキュリティ基準を維持できるよう保護されています。 さまざまなAWSサービスを統合したこの包括的なアーキテクチャにより、製薬業界の固有なニーズに対応した強力で、スケーラブルな、極めて効率的な Sales Concierge ソリューションが実現します。このガイダンスを採用することで、企業はHCPとのエンゲージメント向上を実現しながら、厳格なコンプライアンス要件にも準拠した上で、営業チームを強化することができます。 ベネフィット 包括的な Sales Concierge ソリューションの導入により、製薬企業の営業チームの生産性、顧客エンゲージメント、そして業務実績を大幅に向上させることができます。事務作業を自動化し、重要なデータ、市場インサイト、パーソナライズされたHCPプロファイルへのシームレスなアクセスを提供することで、MRは戦略的な販売活動に集中できるようになり、より高い成約率と有意義な顧客エンゲージメントにつながります。 統合されたデジタルツール、バーチャルエージェントサポート、継続的な学習リソースにより、営業チームは情報に基づいた意思決定ができ、顧客のニーズにより迅速に対応でき、ノウハウと能力を継続的に向上させることができます。さらに、スケーラブルで適応力のあるアーキテクチャにより、顧客関係管理 (CRM) やエンタープライズリソースプランニング (ERP) プラットフォームなど、既存のシステムとの統合が可能になります。これにより、このソリューションは急速に進化する製薬業界の環境に合わせて俊敏かつ対応力を維持し、市場シェア、収益の拡大、そして総合的な事業の成功をもたらすことができます。 Sales Conciergeの導入初期段階でお客様からは励ましの声が寄せられています。バイオ医薬品業界の有力企業のあるMRは「Sales Conciergeは情報への単一のアクセスポイントを提供してくれるので時間が節約できる」と述べています。他の担当者からも「事前の販売計画のためのきめ細かなコンテキストを提供してくれるので時間が節約できる」、「HCPとのより良いエンゲージメントにつながっている」といった前向きな声が聞かれました。 まとめ このガイダンスに基づいてSales Conciergeを実装することにより、ますます複雑化する製薬業界の状況の中でも営業チームを強化し、革新的なアプローチを取り入れることができます。データ、インサイト、生成AIによる機能を単一のソリューションに統合することで、業務を合理化し、負荷を軽減し、重要な情報へのアクセスを容易にします。包括的なプロファイルとインサイトに基づいてHCPとパーソナライズされたデータドリブンなやり取りができるようになれば、営業チームは卓越した成果を収め、顧客との強固な関係を構築できるようになります。 企業がSales Conciergeを導入すれば、効率性と生産性の新たな基準に到達し、より大きな成功に向けてスタートを切ることができます。このAWSからの革新的なアプローチは、営業の未来を切り開くものであり、顧客とのやり取り方を変革し、成長の機会を生み出します。生産性の向上、エンゲージメントの強化、継続的な学習、商業的成果の改善など、包括的なベネフィットを考えると、製薬企業にとってSales Conciergeは戦略的な投資対象となるでしょう。 Sales Conciergeアプリケーションが、営業チームの生産性向上と、医療従事者とのよりデータに基づいた有意義な関与をどのようにサポートできるかを確認してください。営業チームを強化し、顧客とのやり取りを向上させ、より大きなビジネスインパクトを生み出すための第一歩を踏み出しましょう。 AWSライフサイエンス担当者 に連絡して、ビジネスの加速化にどのようにお役立てできるかご相談ください。 参考情報 AWSのソリューション支援について、さらに学習を深めるためのリソースをご覧ください。 AWSのQnABot – 複数のチャネル(コンタクトセンターやソーシャルメディアなど)で、より高度で魅力的な会話型AIエクスペリエンスを素早く作成 React ネイティブアプリに Amazon Bedrock チャット機能を追加する Amazon Bedrock Knowledge Basesを使用してスケーラブル、セキュア、信頼性の高いRAGアプリケーションを構築する Amazon Bedrock Agents Amazon Bedrock Prompt Flows TAGS: customer engagement , life sciences Chris Kaspar Chris Kaspar は AWS のプリンシパルソリューションアーキテクトであり、ヘルスケアとライフサイエンスのお客様が安全でスケーラブルで革新的なソリューションを構築できるよう支援する責任があります。Chrisは、情報技術分野で20以上の資格を持つ電気・電子エンジニアです。20年以上ITに携わってきた彼は、そのうち18年間をヘルスケア部門で過ごし、世界的に認められたメイヨークリニックで16年間という長い在職期間を過ごしました。AWS では、Chris はグローバルヘルスケアおよびライフサイエンスイニシアチブを率いており、デジタルヘルス、創薬、臨床開発、ヘルスケア IT、ケア管理、ガバナンス、クラウド運用など、さまざまな分野でテクニカルアドバイザーおよびアーキテクトの役割を果たしています。 Aman Chhina Aman Chhina は、AWS のヘルスケアおよびライフサイエンス分野のグローバルアカウントマネージャーです。ライフサイエンス業界で15年以上にわたり、戦略、事業開発、コンサルティングに携わってきました。彼は、ライフサイエンスのクライアントチームが、利害関係者、そしてさらに重要なのは患者にとって有意義なビジネス成果をもたらすために、デジタル対応の変革を構想して実現するのを支援しています。 Atul Tannan Atul Tannan は AWS のグローバルアカウントマネージャーで、ライフサイエンス全体のデジタルトランスフォーメーションを専門としています。ライフサイエンス企業やCPG企業と提携して、テクノロジーを通じて企業の最大の課題を解決してきた15年以上の経験があります。彼の専門分野は、デジタルトランスフォーメーション戦略、オムニチャネルエンゲージメント、データ分析、AIの運用、サプライチェーンの近代化に及びます。 Somdeb Bhattacharjee Somdeb Bhattacharjeeは、データと分析を専門とするシニアソリューションアーキテクトです。彼は AWS のグローバルなヘルスケアおよびライフサイエンス業界の一員であり、顧客がデータプラットフォームソリューションをモダナイズしてビジネス成果を達成できるよう支援しています。 Subrato Majumdar Subrato は、AWS のヘルスケアおよびライフサイエンス事業部門の商用ソリューションと戦略を率いています。ライフサイエンス業界で20年以上コンサルティングを行ってきた彼は、臨床、医療、商業の各部門で顧客を支援してきました。彼が現在注力しているのは、オムニチャネル市場戦略を通じて、AIを適用して医療従事者と患者の顧客体験を変革することです。 このブログは、Senior Solutions Architectの松永が翻訳しました。

2024 年 11 月 8 日、 Amazon Location Service  は、 Routes 、 Places 、 Maps  機能の拡張と改善を可能にする 17 の新しい API と強化された API をリリースしました。これにより、開発者はより一貫性のある効率的な体験を得ることができます。これらの更新により、機能が強化され、移行が簡単になり、Amazon Location Service は、幅広いアプリケーションでより利用しやすく、便利なものになりました。 高度なルート最適化、通行料金の計算、GPSトレースのスナップ、静的および動的レンダリングオプションを備えたさまざまなマップスタイルにアクセスでき、また、興味のある場所に関する豊富な詳細情報を利用して、近接検索や予測提案ができるようになりました。 Amazon では、ロードマップの大部分はお客様からのフィードバックによって決定されています。Amazon Location Service を使用してアプリケーションを構築している多くのお客様から、位置情報データを使用する際に、専用に設計された API や、連絡先情報や営業時間などのより詳細な情報が必要であると意見が寄せられています。現行の API セットは多くのお客様にとって貴重なツールを提供してきましたが、開発者からは、詳細なルート計画、近傍検索、追加の場所の詳細情報、静的な地図画像などの追加機能に対する要望が寄せられています。これらの新しい API は、要望に応え、より包括的で、すぐに使える位置情報ソリューションを提供します。 新しい機能と強化された機能 本日発表されたのは、お客様のフィードバックに直接応える 10 の更新された API と 7 つのまったく新しい API です。 Routes、Places、Maps の各サービスは、より幅広い用途に対応できるよう、特定の機能強化が施されています。 Routes Amazon Location Routes API は、高度なルート計画とカスタマイズオプションをサポートするようになりました。これにより、ユーザーは以下を行うことができます。 CalculateIsolines  を利用することで、指定した移動時間または距離のエリアを特定可能 OptimizeWaypoints  を利用することで、最も効率的な経由地の順序を決定し、移動時間または距離を最小化 有料道路を含むルートについて、正確な料金を算出できます SnapToRoads  を使用して、道路ネットワークにポイントをスナップすることで、GPSトレースを正確に一致させることが可能 これらの機能により、より正確でダイナミックなルート体験をユーザーに提供できるようになります。例えば、物流会社は、リアルタイムの交通状況を考慮して配送ドライバーのルートを最適化し、配送にかかる移動コストを最小限に抑えることができます。 Maps 更新された Amazon Location Maps API には、熟練した地図製作者が作成した、より用途に特化した地図スタイルが追加されています。これらの地図スタイルは、市場投入までの時間を短縮し、カスタム地図の作成を不要にするプロフェッショナルなデザインを提供します。さらに、Static Map Image 機能により、開発者は静的地図をアプリケーションに統合することができ、継続的なデータストリーミングの必要性を減らし、インタラクティブ性が不要な使用事例におけるパフォーマンスを向上させます。 Maps API の主な機能には、以下のものがあります。 GetTile : 指定した X、Y、Z 座標の値を使用し、タイルセットからタイルをダウンロードする GetStyleDescriptor : スタイルに関する情報を取得する GetStaticMap : レポートや視覚化を目的とした非インタラクティブなマップのレンダリングを可能にする Places Amazon Location Places API の機能強化により、より詳細な検索機能が可能になり、位置データの精度向上に関する要望に対応できるようになりました。 新機能には、以下のものが含まれます。 SearchNearby  および  Autocomplete  近傍検索クエリをサポートし、予測テキスト機能によりユーザーエクスペリエンスを向上 営業時間、連絡先情報、その他の興味のある場所の属性などのカテゴリーによるビジネス詳細情報の強化 これらの機能は、ユーザーが近隣の場所に関する詳細な情報を必要とするアプリケーション、例えばフードデリバリーサービスや小売アプリケーションなどに特に役立ちます。お客様がフードデリバリーアプリケーションを開き、 SearchNearby  を使用して近くのレストランを検索し、営業時間や連絡先などのレストランの詳細情報を取得して利用可能かどうかを確認するとします。 複数のデリバリー注文がドライバーに割り当てられると、アプリケーションは OptimizeWaypoints を使用して、ピックアップと配送に最も効率的なルートを提案します。 ドライバーがルートに従うと、 SnaptoRoads  がドライバーの位置を正確に視覚化し、お客様のリアルタイムの追跡体験を向上させます。 拡張ロケーションサービスの利用例 API の呼び出しは簡単です。 AWS コマンドラインインターフェイス（AWS CLI） 、 AWS SDK  の、またはシンプルな REST API を使用できます。ただし、ウェブアプリやモバイルアプリでマップ上に情報を表示するには、追加の設定が必要です。このプロセスはドキュメントに記載があるので、今回は詳細には触れず、API の使用に焦点を当てます。 Amazon Location Serviceでは、2 つの方法による API コールの認証方法が提供されています。AWS API 認証（ AWS Sigv4 認証 ）または API キーを使用する方法です。エンドユーザーが認証されていないモバイルアプリケーションの開発や、 Amazon Cognito  との統合が不可能な場合、API キーの方が便利な場合があります。これは、フロントエンドアプリケーション向けの推奨される認証方法です。 API の汎用性と、アプリケーションへの統合がどれほど簡単かをお見せするために、デモの各ステップでは AWS CLI、cURL、グラフィカルな REST API クライアントを組み合わせて使用します。 ステップ1：APIキーの作成 まず、AWS CLI を使用してアプリケーション用の API キーを作成します。API キーは、 AWS マネジメントコンソール でも管理できます。 REGION=eu-central-1 KEYNAME=geo-key-seb aws location create-key --region ${REGION} --key-name ${KEYNAME} --restrictions \ AllowActions="geo-routes:*","geo-places:*","geo-maps:*",\ AllowResources="arn:aws:geo-routes:${REGION}::provider/default",\ "arn:aws:geo-places:${REGION}::provider/default",\ "arn:aws:geo-maps:${REGION}::provider/default" \ --no-expiry { "Key": "v1.public.ey...cy", "KeyArn": "arn:aws:geo:eu-central-1:02345678901:api-key/geo-key-seb", "KeyName": "geo-key-seb", "CreateTime": "2024-09-29T09:35:53.115000+00:00" } このコマンドにより API キーが生成され、これで Amazon Location API を呼び出すことができるようになりました。 ステップ2：地理座標の取得 次に、 curl コマンド  を使用して  GeoCode  を呼び出し、 QueryText  パラメータに住所を渡すことで、フランスのリール市の中心部の地理座標（ 経度 および 緯度 ）を取得します。 $ curl --silent -X "POST" "https://places.geo.eu-central-1.amazonaws.com/v2/geocode?key=v1.public.ey...cy" \ -d $'{ "QueryText": "Grand Place, Lille, France" }' {"ResultItems":[{"PlaceId":"AQ...5U","PlaceType":"Street","Title":"Grand'Place, 59800 Lille, France", "Address":{"Label":"Grand'Place, 59800 Lille, France", "Country":{"Code2":"FR","Code3":"FRA","Name":"France"}, "Region":{"Code":"HDF","Name":"Hauts-de-France"},"SubRegion":{"Name":"Nord"}, "Locality":"Lille","District":"Centre","PostalCode":"59800", "Street":"Grand'Place","StreetComponents":[{"BaseName":"Grand'Place","Language":"fr"}]}, "Position":[3.06361,50.63706], "MapView":[3.0628,50.6367,3.06413,50.63729], "MatchScores":{"Overall":1,"Components":{"Address":{"Country":1,"Locality":1,"Intersection":[1]}}}}]} これは、市街地の GPS 座標 ([3.06361, 50.63706]) を含む複数のデータポイントを返します。 ステップ3：近隣の場所を検索 取得した座標を使用して、REST API クライアントツールで  SearchNearby  APIを呼び出し、リール市街地の近隣の観光スポットを検索します。 画面の右側には、API レスポンスとして、レストラン、銀行、駐車場など、近隣の場所のリストが表示されます。さらに、カテゴリーを指定したり、検索するエリアを制限したりして、検索を絞り込むことができます。 SearchNearby API では、オプションの  Filter  パラメータを受け付け、このパラメータを使用すると、検索を境界ボックス内に制限したり、企業グループ、カテゴリー、国、または食品の種類を含めたり除外したりすることができます。 "Filter": { "BoundingBox": [ number ], "ExcludeBusinessChains": [ "string" ], "ExcludeCategories": [ "string" ], "ExcludeFoodTypes": [ "string" ], "IncludeBusinessChains": [ "string" ], "IncludeCategories": [ "string" ], "IncludeCountries": [ "string" ], "IncludeFoodTypes": [ "string" ] }, 近隣の観光スポットを検索したところ、検索結果の 1 つとして、国際的に有名なマクドナルド が返されました。 ステップ4： 運転ルートを取得 最後に、AWS CLI を使用して、ベルギーの ブリュッセル とフランスの リール という 2  つの都市の中心地間の運転ルートを計算します。 aws location calculate-routes \ --origin 4.35278 50.84687 \ --destination 3.06361 50.63706 \ --key "v1.public.ey...cy" 応答には、地図上に経路を表示するための ポリライン と、段階的な運転指示のリストが含まれています。 ... "TravelMode": "Car", "Type": "Vehicle", "VehicleLegDetails": { "TravelSteps": [ { "Duration": 15, "Distance": 75, "ExitNumber": [], "GeometryOffset": 0, "Type": "Depart" }, { "Duration": 10, "Distance": 8, "ExitNumber": [], "GeometryOffset": 2, "Type": "Turn", "TurnStepDetails": { "Intersection": [], "SteeringDirection": "Right", "TurnIntensity": "Typical" } }, ... ステップ5：地図上にルートを表示する 地図上にルートを表示するために、私は  MapLibre  ライブラリを使用しています。これは、ウェブやモバイルアプリケーションで地図を表示するためのレンダリングエンジンです。 Amazon Location Service Developer Guide  に従って、ルートを表示する基本的なアプリを作成しました。 MapLibre  に加えて、 AWS Amplify  を使用してAmazon Location データをアプリケーションに統合し、表示することもできます。 開始方法 これらの新しい API および更新された API により、Amazon Location Service はお客様のビジネスニーズに合わせたより包括的なマッピングおよび位置情報データスイートを提供します。これらの機能は、開発者の機敏性と拡張性を高めることで、お客様の開発ライフサイクルを加速します。 まずは、更新された Amazon Location Service 開発者ガイド を参照し、これらの機能の統合を今日から開始してください。また、 Amazon Location Service ページ にアクセスして詳細を確認したり、お好みの  AWS SDK  で API を試用して、アプリケーションの強化方法を確認することもできます。 — seb 本記事は「 Announcing new APIs for Amazon Location Service Routes, Places, and Maps 」を翻訳したものです。 著者について Sébastien Stormacq セバスチャンは、1980年代半ばに初めてコモドール64に触れて以来、コードを書き続けている。情熱、熱意、お客様擁護、好奇心、創造性を秘伝のブレンドで駆使し、AWSクラウドの価値を引き出すよう開発者を鼓舞している。関心のある分野は、ソフトウェアアーキテクチャ、開発者ツール、モバイルコンピューティング。彼に何かを売り込みたい場合は、API 付きであることを確認すること。X で @sebstoでフォローしましょう。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

このブログは 2024 年 10 月 21 日に Durga Prasad Katrapally によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 データレイク、機械学習 (ML)、分析を使用する企業には、スケーラブルなデータストレージが必要です。ただし、保存されているすべてのデータに同じようにアクセスするわけではありません。データの中には頻繁にアクセスされる部分もあれば、ほとんどアクセスされないデータ部分もあります。最新のクラウドストレージでは、使用頻度の低いコールドデータを低コストのストレージクラスに移動できます。これにより、ユーザーは頻繁にアクセスされないデータのストレージにかかる費用を節約できます。データ量が増えるにつれて、アクセスパターンを追跡し、データを適切なストレージクラスに移動してコストメリットを最大限に引き出すことが難しくなります。企業はストレージ階層を活用したコスト削減を最大化するために、データ使用量とストレージコストを注視する必要があります。 Amazon S3 は、パフォーマンス、アクセス、耐障害性、コストなどの異なるニーズを満たすさまざまなストレージクラスを提供するオブジェクトストレージサービスです。 S3 ライフサイクル および Amazon S3 Intelligent-Tiering ストレージクラスを使用すると、異なるストレージクラスまたは階層間でデータを自動的に移行してコストを最適化できます。ただし、完全なコスト削減を実現するには、まず実際のアクセスパターンを理解する必要があります。S3 Standard ストレージクラスにデータを保存すると、頻繁にアクセスされるデータとあまりアクセスされないデータで同じストレージコストが発生するため、節約できる可能性は限定的です。アクセスパターンの予測が可能か不可能かを考慮せずに S3 ライフサイクルポリシーや S3 Intelligent-Tiering を使用すると、オブジェクトが最小期間より前に削除された場合に取り出し料金や早期削除料金が高くなったり、より安価なストレージへの移行が遅れて、節約の機会を逃したりする可能性があります。 この記事では、 S3 ストレージクラス分析 を使用してアクセスパターンを分析し、データを別のストレージクラスに移行するタイミングを決定するのに役立つ情報を提供します。S3 ストレージクラス分析では、一定期間にわたってフィルタリングされたデータセットのアクセスパターンを観察し、その結果に基づいて、予測可能なデータアクセスパターンには S3 ライフサイクルポリシー、予測不可能なアクセスパターンには S3 Intelligent-Tiering ストレージクラスというように、適切な選択を行うことができます。このソリューションでは、ストレージアクセスパターンを分析し、異なるストレージクラスと階層を最大限に活用することで、ストレージコストを最適化することができます。 ソリューションの説明 このアプローチは 3 つのフェーズに分かれています。 有効化 : 特定のバケットで S3 ストレージクラス分析レポートを有効にします。このフェーズが終了すると、S3 ストレージクラス分析レポートが、設定時に指定した Amazon S3 のパスに配信されます。 分析 : 毎日更新される S3 ストレージクラスの分析レポートを分析します。このフェーズの終了時には、バケットのワークロードパターンが予測可能または予測不可能のいずれかで描画されます。 アクション : アクセスパターンの明確な指標を基に、分析フェーズの結果に基づいてアクションをします。 注意 : S3 ストレージクラスの分析は、 Amazon S3 の料金ページ に記載されているように、有料機能であり、オブジェクトごとに課金されます。 1. 有効化 このフェーズに進む前に、この ブログ記事 では、 S3 Storage Lens を使用してコスト最適化に適した大きなバケットを特定し、ターゲットにする方法を説明します。この記事のポイントは、S3 Storage Lens を使用して特定したバケットで S3 ストレージクラスの分析レポートを有効にすることです。 S3 Storage Lens は、お客様のすべての S3 バケットにわたる S3 の使用状況とアクティビティのメトリクスを組織全体で高レベルに表示します。最適化の機会を見つけ出し、ベストプラクティスを導入するのに役立ちます。ストレージクラス分析では、通常はペタバイトレベルの特定の大規模 S3 バケットのストレージアクセスパターン、オブジェクトの保存期間分布、移行の機会をモニタリングすることができます。これにより、個々の高いインパクトがあるバケットの正確なライフサイクル管理とコスト最適化が可能になります。 S3ストレージクラス分析レポートは、2つの形式で利用できます。S3バケットのメトリクスタブの分析機能として直接表示する方法と、カンマ区切り（CSV）形式で別のS3バケットにエクスポートする方法です。 この記事では、後者の形式、つまりCSV形式での分析に関する推奨事項に焦点を当てます。CSV形式のレポートでは、日付をドリルダウンして詳細に分析できるのに対し、メトリクスタブでは一定期間のメトリクスを適切に表示できます。 S3 ストレージクラスの分析レポートを有効にする Amazon S3 コンソール で、バケットを選択し、分析するバケットを選択し、メトリクスタブを選択します（ 図 1 参照）。 図 1：S3ストレージクラスの分析レポートの作成 ストレージクラス分析 に移動し、Create configurationをクリックします。 図 2：ストレージクラス分析レポートの設定を作成 Create Configuration をクリックした後、設定の詳細を入力します。 名前 にある S3 Storage Class Analysis レポートの 設定名 を入力します。 設定スコープ では、レポートの適用範囲を指定します。特定のプレフィックスに対しては 1 つ以上のフィルターを使用してこのルールのスコープを制限する を、バケット全体に対しては バケット内のすべてのオブジェクトに適用 を選択します。 CSV をエクスポート では、レポートのフォーマットを選択し、CSV をエクスポートの下で 有効にする にチェックを入れます。 送信先バケット のアカウント選択では、 このアカウント または 別のアカウント を選択します。 送信先 で、 図 3 のようにレポートをリダイレクトする 宛先バケット を選択します。 図 3：S3ストレージクラスの分析レポート有効化 S3ストレージクラス分析レポートの設定が完了したら、S3コンソールでフィルタに基づくデータ分析の監視を 24-48 時間後に開始します。ただし、S3 ストレージクラス分析では、結果を出す前に分析用の情報を収集するために、フィルタリングされたデータセットのアクセスパターンを30 日以上モニタリングします。アクセスパターンが変化するにつれて、最初の推奨事項が出された後も分析は継続され、更新されます。 S3 ストレージクラス分析レポートからの推奨事項は、 S3 Standard-Infrequent Access (S3 Standard-IA) への移行のみ を示します。しかし、検出されたパターンを使用して、既知または未知のパターンを導き出すことができます。既知および未知のパターンの例については、次のフェーズで説明します。 このフェーズの終了時には、設定を作成した際に指定した Amazon S3 バケットに S3 ストレージクラス分析レポートが送信されているはずです。 2. 分析 このフェーズでは、毎日更新される S3 ストレージクラスの分析レポートの分析に重点を置きます。有効化すると、各日付に対して複数のエントリが作成されます。 以下はサンプルレポートの例です。 図 4：複数のエントリーを含む S3 ストレージクラス分析レポートのサンプル S3 ユーザーガイド には、分析に使用される ObjectAge、Storage_MB、DataRetrieved_MB、GetRequestCount など、各カラムの説明が記載されています。 分析の開始点として、 図 5 に示されているように、レポートの最新の日付でフィルタリングすることが有効です。 図 5：日付を 1 つ指定してフィルタリングした S3 ストレージクラス分析レポートのサンプル パターンを導き出すために注目すると良い列には、Object Age、Storage_MB、DataRetrieved_MB、GetRequestCountなどがあります。 予測可能なワークロードの例 このセクションでは、 図 6 に示されているような予測可能な作業負荷パターンに関する S3 ストレージクラス分析レポートの例を紹介します。 図6：予測可能なパターンを持つ S3 ストレージクラス分析レポートのサンプル ObjectAge 列にはバケットに配置された経過時間のリストが表示され、例えば 000-014 は 0 日から 14 日の間のオブジェクト、015-029 は 15 日から 29 日の間のオブジェクトであることを意味します。 Storage_MB はバケットに配置された ObjectAge における総ストレージ容量を示します。例えば、000-014 日経過のオブジェクトの総使用ストレージ容量は 277847 MB、015-029 日経過のオブジェクトの総使用ストレージ容量は 290350 MB などです。 GetRequestCount は、バケットに配置された経過時間のグループ (ObjectAge のグループ) に送信された API コールの総数です。この例では、000-014 日のオブジェクトには約 12369 件の API コールがあり、その他の ObjectAge グループには API コールはありません。 DataRetrieved_MB Data は、ObjectAge グループにおけるその日の GET リクエストによるストレージクラスごとの転送データ量（MB）です。ObjectAge=’ALL’ の場合、その日のすべての ObjectAge グループに対する GET リクエストによる転送データ量（MB）の合計値となります。 分析をすると、前掲のレポート（ 図 6 ）からパターンが予測できることが分かります。0-14 日経過したオブジェクトは活発に使用されていますが、それ以降は他の経過日数のオブジェクトに対する API リクエストはありません。したがって、S3 ライフサイクルポリシーを使用して、ほとんどアクセスされないデータを 15日 経過後に S3 Glacier ストレージクラス に移動することができます。 予測不可能なワークロードの例 ここでは、予測不可能なパターンに関する S3 ストレージクラス分析レポートの例を見てみましょう。 次の S3 ストレージクラス分析レポート（ 図 7 ）は、最初の 30 日間にアクティブなアクセスがあります。次の 30 日間（つまり 30 日から 59 日まで）はアクティブなアクセスがなく、60 日から 119 日まで再びアクセスされ、120 日から 179 日まではアクセスリクエストがありません。ここには予測性はありません。古いデータの一部は依然としてアクセスされている一方で、まったくアクセスされない部分もあります。このシナリオでは、アクティブにアクセスされる部分と、アクセス頻度が低い部分の両方に対して、S3 Standard の料金を支払うことになるでしょう。 このバケットは、S3 Intelligent-Tiering に適しています。アクセスされないコールドな部分を、30日または90日後に自動的に低頻度アクセス階層またはアーカイブインスタントアクセス階層に移動させるからです。 図 7：予測不可能なパターンを含むS3ストレージクラス分析レポートのサンプル この分析では、特定の日のパターンを確認しました。一般的には、例えば 1 か月間といった一定期間のパターンを観察し、アクセス・パターンに関する結論を出します。このフェーズの終了時には、バケットワークロードのパターンは、予測可能なものと予測不可能なもののどちらかとして分類されます。 3. アクション 最後のフェーズでは、アクセスパターンを明確に示しながら、分析フェーズの結果に基づいてアクションをします。 予測可能なパターンに対するアクション 予測可能なパターンについては、S3 ライフサイクルポリシーを有効にして、アクセス頻度の低いデータを S3 Glacierストレージクラスに移動することで、最大限のコスト削減を実現できます。 S3 Glacier Instant Retrieval、S3 Glacier Flexible Retrieval、S3 Glacier Deep Archive のどれを選択するのかは、バケットのビジネス上のユースケースにより異なります。 データがミリ秒単位の検索パフォーマンスで利用可能であり、四半期に 1 回アクセスされる必要がある場合は、S3 Glacier Instant Retrieval が適しています。 データが非同期で数分から数時間でアクセス可能であり、半年に 1 回アクセスされる場合は、S3 Glacier Flexible Retrieval が適しています。24-48時間以内にデータが利用可能になり、毎年定時にアクセスされるというユースケースであれば、S3 Glacier Deep Archive が適しています。 S3 ライフサイクルポリシーを通じてデータを移動する際には、一時的な移行料金が発生し、アクセス時にはデータ取り出し料金が発生します。以下の表は、米国東部（バージニア北部） AWSリージョン の料金をまとめたものです。 移行先 S3 ライフサイクルでの移行リクエスト数 (1,000 リクエストあたり) データ取り出しリクエスト (1,000 リクエストあたり) データ取り出し(GB あたり) S3 Intelligent-Tiering $0.01 n/a n/a S3 Standard-IA $0.01 n/a $0.01 S3 Glacier Instant Retrieval $0.02 n/a $0.03 S3 Glacier Flexible Retrieval $0.03 $10.00 Expedited $0.03 $0.05 Standard $0.01 n/a Bulk n/a S3 Glacier Deep Archive $0.05 $0.10 Standard $0.02 $0.025 Bulk $0.0025 表 1：米国東部（バージニア北部）リージョンの移行費用 一時的な料金を計算するには、移行するコールドオブジェクトの総数が必要です。移行料金は1000オブジェクト単位であり、サイズによる料金設定ではないからです。 一時的な料金の計算 ここでは、パターンが予測可能な 図 6 と同じ例を使用します。現在のストレージでは、データのコールド部分（バケットに配置されて15日を越えるグループの合計）は約 6.31 TB です。これは、約 6.31 TB が 100 万のオブジェクトであり、ユーザーは 24-48 時間データ取得を待つことができると仮定しています。コールド部分は、S3 Glacier Deep Archive に移動できます。 S3 Standard から S3 Glacier Deep Archive にデータを移行する際には、1000 オブジェクトあたり $0.05 の一時的な移行料金が発生します（ 表 1 ）。 100 万個のオブジェクトの場合、移行料金は（1,000,000/1000）*0.05、つまり $50 となります。 この移行について考慮すべき重要な要素は、オブジェクトのサイズです。移行料金はオブジェクトの数に基づいており、サイズに基づいていないため、オブジェクトが大きければ大きいほど、ストレージの GB あたりの移行コストは低くなります。 例えば、10 TB のデータがあるとします。1 MB の小さなオブジェクトが 1000 万個ある場合、S3 Glacier Deep Archive への移行費用は $500 かかります。一方、10 MB のオブジェクトが 100 万個ある場合、移行費用は $50 です。 節約の効果 例えば、一時的な費用を差し引いた実質的な節約額を計算することができます。 図 6 から、15 日以上経過したオブジェクトのデータはほとんどアクセスされていないことが分かります。 15 日以上経過したオブジェクトを移動する S3 ライフサイクルポリシーにより、合計約 6.40 TB のオブジェクトがより安価なストレージクラスに移動されます。この例では、前述のとおり、S3 Glacier Deep Archive を移行先のストレージクラスとします。 現在のコールドストレージサイズ 現在の S3 Standard 料金 S3 Glacier Deep Archive へ移行する際の一時的な料金 S3 Glacier Deep Archive へ移行後の料金 * 節約効果 節約効果 % 6471 GB $323.55 $50 $6.40 (0.00099*5620) =323.55-$50 =$273.55 84.54% 表 2 : 予測可能なアクセスパターンの節約計算 *$0.00099 は、米国東部（バージニア北部）リージョンにおける S3 Glacier Deep Archive の GB あたりの料金です。 予測不可能なパターンに対するアクション 予測不可能なパターンに対しては、S3 Intelligent-Tiering が費用対効果に優れており、S3 ライフサイクルを使用してデータをS3 Standard ストレージクラスからS3 Intelligent-Tiering ストレージクラスに移行することができます。 S3 Intelligent-Tiering では、オブジェクトのモニタリングに少額の料金がかかります。さらに、128 KB を超えるオブジェクトのみがモニタリングの対象となり、最後にアクセスされた時間に基づいてストレージクラス間で移動されます。128 KB 未満のオブジェクトにはモニタリング料金はかかりません。また、S3 ライフサイクルでは、128 KB 未満のオブジェクトは S3 Intelligent-Tiering に移行されません。 一時的な料金の計算 まず、バケット全体で予測不可能なワークロードがあります。そのため、S3 Standard ストレージクラスのオブジェクトは S3 Intelligent-Tiering ストレージクラスに移行する必要があります。 S3 Standard から S3 Intelligent-Tiering への移行には、1000 オブジェクトあたり $0.01 の移行料金がかかります（表1）。 バケット内に 128 KB 以上のオブジェクトが合計 1000 万個あると仮定すると、 移行料金 は（10,000,000/1000）*$0.01 、つまり $100 となります。 S3 Intelligent-Tieringのモニタリング料金 次に、オブジェクトが S3 Standard ストレージクラスから S3 Intelligent-Tiering ストレージクラスに移動された場合、モニタリング料金が適用されます。 128 KB を超えるサイズのバケットに合計 1000 万のオブジェクトがある場合、そのバケットのモニタリング料金は次のようになります。（10,000,000/1000）*0.0025 = 1 か月あたり $25。 * 米国東部（バージニア北部）リージョンでは、モニタリング料金は 1 か月あたり 1,000 オブジェクトあたり $0.0025 です。 節約の効果 例えば、1 回限りの料金の支払い後にどれほど効果的な節約ができるかを見てみましょう。 図 7 から、30-44 日間、45-59日間、120-149日間、150-179日間の経過時間層のデータはアクセスされていません。 30日後 S3 Intelligent-Tiering がバケット上で有効になっている場合、S3 Intelligent-Tiering に移行してから 30 日後には、合計約5.82 TB がコールドとして識別されます。さらに、30 日後には低頻度アクセス階層に、90 日後にはアーカイブインスタントアクセス階層に移行します。 現在のコールドストレージサイズ 現在のコールドデータ部分に適用された S3 Standard 料金 S3 Intelligent-Tiering ストレージクラスへの移行に伴う一時的な費用 S3 Intelligent-Tieringストレージクラス（低頻度アクセス階層）のコールド部分の30日経過後の課金 節約 節約 % 5820 GB $137 $100 $0.0125*5820 = $72.8 $137-$72.8 = $64.25 46% 表3 : 30 日後の予測不能なパターンの節約額の計算 * $0.0125は、米国東部（バージニア北部）リージョンにおける 1 GB あたりの低頻度アクセス階層ストレージクラス料金です。 90日後 オブジェクトが低頻度アクセス階層に移動されてから 60 日後、S3 Intelligent-Tiering は移行コストなしで自動的にアクセスがない場合、現在の低頻度アクセス部分をアーカイブインスタントアクセスに移動します。これにより、コールドデータ部分がさらに節約できます。 わかりやすくするために、この例では、 アーカイブインスタントアクセスクラスに移動した低頻度アクセスデータの総量は 5820 GB のみとします。しかし、一般的に S3 Intelligent-Tiering は、新たにインポートされたオブジェクトで 30 日間アクセスがないものをモニタリングし S3 Standard-IA へ、90 日後にアーカイブインスタントアクセスクラスに移動します。 現在の 低頻度アクセス データ 現在の 低頻度アクセス 料金 他のストレージクラスへ移行する一時的な料金 S3 Intelligent-Tieringストレージクラス（アーカイブインスタントアクセス）によるコールドストレージの120日以降の料金 節約 節約 % 5820 GB $64.2 $0 $0.004*5820 = $23.8 $64.2-23.8 = $40.2 62% 表4：90日後の予測不能パターンの節約額計算 考慮すべきその他のツール 予測可能なアクセスパターンまたは予測不可能なアクセスパターンのいずれかで、他のストレージクラスへの移行対象となるオブジェクトの正確な数を把握するには、 Amazon S3 Inventory と Amazon Athena という 2 つの主要なツールが役立ちます。 Amazon S3 Inventory は、S3 バケット内のオブジェクトとそれに対応するメタデータを、日次または週次でリスト化したレポートを、CSV、Apache最適化行列形式（ORC）、またはApache Parquet出力ファイルのいずれかで提供します。Athena は、オープンテーブルおよびファイル形式をサポートするオープンソースフレームワークを基盤としたサーバーレスのインタラクティブな分析サービスです。Athena は Amazon S3 と緊密に統合されており、Amazon S3 インベントリレポートの分析が可能です。 ブログ「 Manage and analyze your data at scale using Amazon S3 Inventory and Amazon Athena 」では、Athena と Amazon S3 インベントリレポートの統合、および Amazon S3 インベントリメタデータに対するクエリについて説明しています。Amazon S3 インベントリレポートにクエリを実行することで、移行対象となる 128 KB を超えるオブジェクトや、一定期間以上経過したオブジェクトなどの洞察を得ることができます。これにより、S3 ライフサイクルアクションの初期費用や、S3 Intelligent-Tiering のモニタリング料金をより正確に算出することができます。 クリーンアップ アクセスパターンが分かったら、Amazon S3 ストレージクラス分析レポートを停止して、課金を停止できます。レポートを停止するには、以下の手順に従います。 Amazon S3 コンソールで、 バケット を選択します。S3 ストレージクラス分析レポートを無効にする必要がある バケット を選択します。 メトリクス タブに移動し、 ストレージクラス分析 を選択します。 図 8 : S3 ストレージクラス分析レポートのクリーンアップ方法 削除するレポートを選択し、 削除 を選択します。 図 9 : ストレージクラス分析レポートの削除 まとめ この記事では、S3 ストレージクラス分析レポートの設定方法と、コストを最適化するために大規模な Amazon S3 バケット全体のアクセスパターンの分析の重要性について説明しました。また、アクセス頻度の低いデータを、S3 ライフサイクルルールや Amazon S3 Intelligent-Tiering を使用して、よりコスト効率の高い Amazon S3 の ストレージクラス に移動することで、大幅なコスト削減を実現できるシナリオも確認しました。さらに、S3 Storage Lens やストレージクラス分析レポートなどのツールを使用して、S3 ライフサイクルポリシーと S3 Intelligent-Tiering のユースケースを紹介しました。また、コスト削減額と移行時の一時的な費用を計算することで、意思決定プロセスを導くこともできました。 Amazon S3 は、ストレージクラスと Intelligent-Tiering のオプションを提供しており、お客様のワークロードとビジネスニーズに基づいてコストを最適化することができます。S3 バケットのアクセスパターンを理解することは、最適化の機会を活用するために極めて重要です。S3 ストレージクラス分析レポートは、お客様のバケットを分析することでアクセスパターンを特定し、データを最も最適なストレージクラスに配置できるようにします。 この記事をお読みいただきありがとうございました。 追加のリソースについては、この 動画「Amazon S3 Storage Class Analysis」 や、その他の関連ストレージブログを参照してください。 Amazon S3 cost optimization for predictable and dynamic access patterns Dialog Axiata saves significantly on storage using Amazon S3 Intelligent-Tiering and S3 Storage Lens How Toyota Connected North America reduced storage costs by optimizing its growing data on Amazon S3 Durga Prasad Katrapally Durga Prasad Katrapally は、AWS のテクニカルアカウントマネージャーであり、多様な領域にわたる 14 年の IT 経験を持つ。戦略的コラボレーションを通じて、お客様の課題解決とクラウドの成功を推進することにやりがいを感じている。AWS プラットフォーム上のソリューション開発に携わり、お客様のニーズを主張し、長期的な成功に向けて積極的に導くことを使命としている。特に生成 AI、データ、ストレージの分野における新興技術の最新情報を入手することに熱心に取り組んでいる。

本稿では、AWS PrivateLink の User Datagram Protocol (UDP) サービスサポートを活用し、デュアルスタック Network Load Balancer (NLB) の UDP サポートにより Internet Protocol version 6 (IPv6) への移行を加速する方法について解説します。2つの新機能の設定手順やユースケース、既存環境に統合するためのベストプラクティスを解説します。 PrivateLink の UDP サポートが追加されたことで、AWS PrivateLink を使用して Amazon Virtual Private Cloud (VPC) を、PrivateLink エンドポイントを通じて公開される UDP ベースのサービスへプライベートに接続できるようになりました。サービスは、複数の VPC に跨る AWS 環境にデプロイでき、またはパートナーや Software as a Service (SaaS) プロバイダーがお客様の AWS アカウントと共有することができます。Transmission Control Protocol (TCP) ベースのサービスにアクセスする際と同様に、UDP ベースの VPC エンドポイントサービスにアクセスするための VPC エンドポイントを作成できるようになりました。 IPv6 導入の加速を支援するため、AWS では現在デュアルスタック NLB の UDP リスナーをサポートしています。これにより、リアルタイムゲームや Voice over IP (VoIP)、メディアストリーミングなどの UDP ベースのアプリケーションへの着信トラフィックを自動的に分散し、高可用性とスケーラビリティを確保することができます。デュアルスタック NLB は、IPv4 / IPv6 両方のクライアントがアプリケーションのエンドポイントにアクセスできるようにし、AWS 上での IPv6 の導入を加速させます。デュアルスタック NLB の UDP サポートにより、TCP リスナーで利用可能な機能 (ヘルスチェック、自動スケーリング、透過的アップグレードなど) を、カスタムロードバランシングソリューションを維持する必要なく利用できます。 前提条件 本稿では、 Amazon VPC や Elastic Load Balancing 、 NLB 、 AWS PrivateLink 、 Amazon CloudWatch など、AWS の基本的なネットワーキング構成に精通していることを前提としています。また、IPv4 や IPv6、TCP、UDP にも精通していることを想定しています。これらのサービスや概念の定義に焦点を当てるのではなく、2つの新機能のユースケースと設定手順を示すために使用します。AWS 上での IPv6 導入リソースの詳細は、AWS re:Postの記事「 Get started with IPv6 on AWS – Resources & Content 」を参照してください。 デュアルスタック NLB と AWS PrivateLink の UDP サポート デュアルスタック NLB の UDP サポートにより、クライアントは IPv4 / IPv6 の両方を使用して UDP サービスに接続できます。この機能を使用するには、デュアルスタック NLB の UDP リスナーに対して IPv6 タイプのターゲットグループを作成する必要があります。NLB は IPv6 を使用して UDP トラフィックをターゲットに送信します。 クライアントは、関連する Fully Qualified Domain Name (FQDN) を解決することで、UDP リスナーを持つデュアルスタック NLB に直接アクセスできます。また、UDP リスナーを持つデュアルスタック NLB を使用して AWS PrivateLink サービス (VPC エンドポイントサービス) を構成することもできます。クライアントは IPv4 または IPv6 を使用して、UDP ベースのサービスにアクセスするために、VPC 内に AWS PrivateLink エンドポイント (VPC エンドポイント) を作成することができます。 図1 は、クライアントが IPv4 または IPv6 を使用して UDP 経由で VPC エンドポイントサービスに接続するアーキテクチャです。NLB はデュアルスタックで、サービス用の UDP リスナーを持っています。サービスプロバイダーのサービスのターゲットグループは、IPv6 を使用する必要があります。クライアントには、IPv4、IPv6、またはデュアルスタック VPC エンドポイントをデプロイし、トラフィックを送信するオプションがあります。クライアントは、VPC エンドポイントに接続することで、UDP ベースのサービスを利用できます。 図1. デュアルスタック UDP NLB クライアントとターゲットの IP 互換性を示すネットワークトポロジー図 デュアルスタック NLB の 送信元 IP アドレスの保持 TCP および TLS リスナー IPv4 クライアントが IPv6 ターゲットを持つデュアルスタック NLB に直接接続する場合、NLB はクライアントの IPv4 アドレスを保持できません。IPv6 が IPv4 との下位互換性を持たないためです。IPv6 ターゲットはクライアントの IPv4 アドレスを処理できないため、NLB はクライアントの IPv4 送信元アドレスを自身の IPv6 アドレスに変換し、ターゲットの IP バージョンに合わせます。 同様に、IPv4 および IPv6 クライアントが VPC エンドポイントに接続する場合、NLB はプロトコルバージョンに関係なく、クライアントの IP アドレスを保持しません。NLB では IP NAT が行われるため、クライアント VPC とサービスプロバイダー VPC 間で IP アドレスが重複していても AWS PrivateLink を使用できます。NAT の結果、ターゲットアプリケーションはクライアントの IP アドレスを認識しません。ターゲットアプリケーションにクライアント IP アドレスを知らせるために、ターゲットグループで Proxy Protocol version 2 (PPv2) を有効にすることができます。これにより、NLB はクライアント IP アドレスを Type-Length-Value (TLV) としてパケットヘッダーに追加できます。この機能は、IPv4 および IPv6 の両方のタイプのターゲットグループで有効にできます。 UDP および TCP_UDP リスナー UDP はコネクションレスプロトコルであるため、デュアルスタック NLB の UDP サポートにおいて送信元 NAT には異なる実装が必要です。TCP と比較して2つの主要な違いがあります。 UDP は TCP と異なりコネクションの概念がないため、ポートを使用して NLB を通過するセッションを追跡することができません。そのため、NLB は IPv6 アドレスを使用して UDP リスナーの各クライアントを一意に識別します。 TCP トラフィックの場合、NLB はコネクションが確立されたときに最初のパケットにのみ PPv2 ヘッダーを追加します。UDP では、コネクションが確立されることはなく、各パケットが独立したものとして扱われます。その結果、UDP ターゲットグループで PPv2 が有効になっている場合、NLB はすべてのパケットに PPv2 ヘッダーを追加します。 デュアルスタック NLB の UDP リスナーと、UDP ベースの VPC エンドポイントサービスの設定手順を見ていきましょう。 デュアルスタック Network Load Balancers の UDP リスナーの設定 始める前に、以下の前提条件を満たしていることを確認してください。 VPC IP 設定の確認 ：VPC に IPv6 プレフィックスが関連付けられていることを確認してください。VPC における IPv6 の設定に関する詳細については、 Amazon VPC ユーザーガイド の「 VPC の IPv6 サポートを追加する 」を参照してください。 サブネット IP 設定の確認 ：NLB のサブネットはデュアルスタックである必要があります。ターゲットグループのサブネットはデュアルスタックまたは IPv6 のみのいずれかです。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス設定の確認 ：各インスタンスにはプライマリ IPv6 アドレスが設定されている必要があります。プライマリ IPv6 アドレスの設定に関する詳細については、 Amazon EC2 ユーザーガイド の「 ネットワークインターフェイスの IP アドレスを管理する 」を参照してください。 NLB と ターゲットのセキュリティグループインバウンドルールの作成 ：セキュリティグループのインバウンドルールで、NLB の UDP リスナーとターゲットがトラフィックを受信するように、設定されているポートで UDP を許可する必要があります。 アプリケーションが IPv6 トラフィックを許可していることの確認 ：アプリケーションが IPv6 トラフィックを処理でき、IPv6 をサポートするソケットライブラリを使用していることを確認してください。 次の手順は、新規および既存のデュアルスタック NLB に対して UDP リスナーを構成する方法を示しています。 ステップ1 (任意)：既存の NLB を変更してデュアルスタックとソース NATを使用する IP アドレスタイプをデュアルスタックに変更するには、既存の UDP および TCP_UDP リスナーを削除し、 図 2 に示すように NLB サブネットがデュアルスタックであることを確認する必要があります。 図2. NLB の IP アドレスタイプを変更する前の要件 既存の NLB の IP アドレスタイプを更新する場合、Amazon EC2 コンソールの ロードバランサー に移動し、対象の NLB を選択します。 図3 のように、 アクション を選択し、 IP アドレスタイプの編集 を選択します。 図3. NLB の IP アドレスタイプを編集 NLB を変更し、 ロードバランサーの IP アドレスタイプ を デュアルスタック に変更する際、 IPv6 ソース NATのプレフィックスを有効にする を オン (サブネットごとのソース NAT プレフィックス) に設定し、 サブネット を選択し、ソース NAT IPv6 アドレスを割り当てます。 図4 に例を示しています。 図4. デュアルスタックに変更し、IPv6 ソース NAT のプレフィックスを有効にし、IPv6 アドレス範囲を設定 ステップ2：新しいデュアルスタック UDP NLB を作成する UDP リスナーを持つ新しいデュアルスタック NLB を作成するには、Amazon EC2 コンソールの ロードバランサー に移動し、 ロードバランサーの作成 を選択します。 Network Load Balancer を選択し、 作成 を選択します。 基本的な設定 で、NLB に一意の名前を付け、スキーム ( 内部 または インターネット向け ) を選択します。 ロードバランサーの IP アドレスタイプ では、 デュアルスタック を選択します。 図5 に例を示しています。 図5. NLB の基本的な設定 ステップ3：NLB サブネットとソース NAT 設定を構成する 図6 に示されているように、NLB をデプロイする VPC を選択してください。 図6. NLB の VPC を選択 図7 に示すように、 IPv6 ソース NATのプレフィックスを有効にする を オン に設定します。 図7. IPv6 ソース NATのプレフィックスを有効化 図8 に示すように、ソース NAT IPv6 プレフィックスの割り当て方法を選択してください。 図8. ソース NAT IPv6 プレフィックスオプション NLB の アベイラビリティゾーンのマッピング 、 サブネット 、 セキュリティグループ を選択し、設定を確認して ロードバランサーの作成 を選択してください。 ステップ4：Amazon EC2 インスタンスをターゲットとして登録する 前提条件にて、プライマリ IPv6 アドレスを持つように IPv6 ターゲットを登録することを言及しました。 図9 に示すように、IPv6 ターゲットをターゲットグループに登録するために必要となります。 図9. ターゲットグループへのターゲットの登録 ステップ5：UDP リスナーを設定する リスナーの プロトコル を UDP または TCP_UDP に設定し、リスナーの ポート を選択する必要があります。図の例では、UDP とポート 53 を選択しています。ターゲットグループの IP アドレスタイプ の値は IPv6 に設定する必要があります。ターゲットグループの IP アドレスタイプ を確認するには、Amazon EC2 コンソールの ターゲットグループ を参照してください。ターゲットグループの IP アドレスタイプは作成後に変更できません。 図10 は、上記例における IPv6 ターゲットグループの UDP リスナー設定を示しています。 図10. NLB のリスナーとルーティング AWS PrivateLink を使用している場合は、以下の手順に進んでください。 デュアルスタック UDP の AWS PrivateLink サービスを作成する AWS PrivateLink サービスを作成する (サービスプロバイダー側) サービスプロバイダーであれば、AWS PrivateLink を使用して UDP サービスをクライアントと共有できるようになりました。サービスプロバイダーには、組織内のチームや Independent Software Vendors (ISV) などのパートナー、規制当局などの関連組織が含まれます。 1 つの手順だけで、VPC エンドポイントサービスを作成できます。Amazon VPC コンソールの エンドポイントサービス に移動し、 図11 に示すように エンドポイントサービスの作成 を選択します。 図11. VPC エンドポイントサービスの作成 図12 に示すように、以下のオプションを設定してください。 (任意) エンドポイントサービスに 名前 を付けます。 ロードバランサーの種類 を ネットワーク に選択します。 前もって設定した UDP リスナーを持つ NLB を選択します。 (任意) 承認が必要 を選択します。この設定の詳細については、 AWS PrivateLink ユーザーガイド の 接続リクエストを承諾または拒否する を参照してください。 (任意) プライベート DNS 名を有効化 を有効にします。エンドポイントサービスのプライベート DNS 名の詳細については、AWS PrivateLink ユーザーガイドの VPC エンドポイントサービス DNS の名前を管理する を参照してください。 VPC エンドポイントサービスが提供する IP アドレスタイプ を選択します。今回の例では、クライアントが IPv4 や IPv6、またはデュアルスタックの VPC エンドポイントを作成できるように、IPv4 と IPv6 の両方を選択します。 (任意) エンドポイントサービスに タグ を設定します。 図12. VPC エンドポイントサービスの設定オプション UDP の AWS PrivateLink エンドポイントを作成する (クライアント側) AWS PrivateLink サービスにアクセスするには、クライアント VPC に VPC エンドポイントを作成する必要があります。このセクションでは、本記事の構成前提条件セクションでネットワーク構成手順に従ったことを前提としています。 ステップ1：サービスプロバイダーがサポートしている IP バージョンを特定する VPC エンドポイントで IPv6 を有効にするには、サービスが SupportedIpAddressType として IPv6 を持っている必要があります。サービスが IPv6 をサポートしているかどうかは、以下のコマンドを実行して確認できます。レスポンスの中で、 SupportedIpAddressTypes が VPC エンドポイントサービスで有効になっている IP バージョンを示します。 aws ec2 describe-vpc-endpoint-services \ --service-names < service-name > Bash ステップ2：AWS PrivateLink エンドポイントを作成する VPC エンドポイントを作成するには、 図13 に示すように、以下の設定を行います。 (任意) VPC エンドポイントに 名前タグ を付けます。 適切な VPC エンドポイントサービスを サービス名 として選択します。 VPC エンドポイントをデプロイする VPC を選択します。IPv4、IPv6、またはデュアルスタックのエンドポイントを設定することができます。この設定は VPC エンドポイントサービスの SupportedIpAddressTypes 値とクライアントの機能に依存します。 (任意) 追加設定 で、 DNS 名を有効化 を有効にすることができます。この設定の詳細については、AWS PrivateLink ユーザーガイドの プライベートDNS名を有効にする を参照してください。 VPC エンドポイントの サブネット と セキュリティグループ を選択します。 図13. VPC エンドポイントを作成 新しく作成されたエンドポイント接続は、VPC エンドポイントサービスに対して承認が必要な場合、AWS PrivateLink サービスプロバイダーによって承認される必要があります。 Amazon CloudWatch を使用して UDP ベースのサービスを監視する この設定を完了すると、カスタマーは UDP ベースのサービスにトラフィックを送信できるようになります。サービスプロバイダーは、以下のような Amazon CloudWatch メトリクスを使用して、健全性とパフォーマンスを監視できます。 NewConnectionCount：NLB を通過する新しい UDP フローの数を測定します。 PacketsOutToTarget：NLB から登録されたターゲットに送信された UDP パケットの数を測定します。 HealthyHostCount：ターゲットグループ内の健全なターゲット数を測定します。 これらの CloudWatch メトリクスは、UDP ベースのサービスが期待通りにトラフィックを処理していることを確認し、潜在的な問題を特定するのに役立ちます。詳細については、AWS PrivateLink ユーザーガイド AWS PrivateLink の CloudWatch メトリクス を参照してください。 考慮事項 デュアルスタック UDP NLB は既存の機能を維持します。多数の NLB を持つ 1 つの VPC エンドポイントサービスをサポートします。これにはオンプレミスのターゲットにトラフィックを送信する機能も含まれます。UDP リスナーを持つデュアルスタック NLB を提供する VPC エンドポイントサービスは、エンドポイントポリシー、プライベート DNS 名、セキュリティグループをサポートします。UDP サポートのリリースでも、AWS PrivateLink のスループット、サービスクォータ、送信元 IP の保持は変更ありません。 まとめ 本稿では、UDP サービスで AWS PrivateLink のサポートを活用する方法と、デュアルスタック NLB の UDP サポートを使用して IPv6 への移行を加速する方法について説明しました。2つの新機能の設定手順、ユースケース、既存の環境に2つの新機能を統合するためのベストプラクティスを概説しました。これらの機能は、IPv6 の採用と UDP ベースのサービスの AWS への移行を加速し、リアルタイムゲーム、Voice over IP (VoIP)、メディアストリーミングなどの UDP ベースのアプリケーションへのインバウンドトラフィックを自動的に分散するのに役立ちます。デュアルスタック NLB の UDP サポートにより、カスタムロードバランシングソリューションを維持する必要なく、ヘルスチェック、自動スケーリング、透過的なアップグレードなど、TCP リスナーで利用可能な同じ機能の恩恵を受けることができます。 VPC コンソール のエンドポイントサービスとエンドポイントのオプションを使用して、AWS PrivateLink の使用を開始してください。詳細については、 AWS PrivateLink および VPC エンドポイント のユーザーガイドを参照してください。 本稿は、2024年10月31日に Networking & Content Delivery で公開された “ Accelerate IPv6 application migration with AWS PrivateLink and dual stack Network Load Balancers UDP support ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。

本ブログは 株式会社アーベルソフト様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの文珠です。 昨今、様々なお客様と会話している中で、今まで 自社開発で提供していた機械学習モデルから、サードパーティ製の生成 AI モデルに置き換えるケース が増えてきていると感じています。生成 AI モデルへの置き換えにより、精度向上やコスト削減だけではなく、新しいユースケースへの対応も可能となります。実際に AWS の生成 AI サービスを活用して、自社プロダクトのユースケースを拡大されているお客様は多くおられます。 本記事で紹介させていただく 株式会社アーベルソフト 様も、画像認識を行う機械学習モデルを開発し、自社サービスに組み込んでいました。アーベルソフト様はこちらの機械学習モデルを AWS の生成 AI サービスである Amazon Bedrock に置き換えることで、 精度を上げながらコストも削減し、自社プロダクトを新たなユースケースに対応させる検討 もすることができました。 アーベルソフト様の状況と経緯 アーベルソフト様は、災害写真情報サービス「 ビューちゃんねる（防災 DX） 」を開発しており、複数の自治体に向けてサービスを提供しております。 本サービスは、ほぼリアルタイムに地域の道路状況や河川状況を把握するソリューションとなっており、地域・自治体の方々に有益な情報を日々提供しております。例えば、大雨の日などに水害情報を遠隔で確認し、災害対策に用いることができます。 (出展: 株式会社アーベルソフト) サービスで提供される画像は電柱に取り付けられた IP カメラで取得され、数分おきに LTE 回線経由でイメージサーバーに送られています。イメージサーバーでは、プライバシーに配慮するための画像加工を行っており、保存した画像は後から閲覧することが可能です。 自社で開発した画像認識モデルを用いて、冠水を自動判定する Web サービスも提供しております。増水によって、水位があらかじめ設定した閾値を超えたと判断された場合には、通知を受け取ることができます。 (出展: 株式会社アーベルソフト) 本サービスを運用している中で、機械学習モデルの作成に必要な「 学習用のデータ収集 」や「 専門知識の獲得 」にかかる時間は大きな課題でした。本ユースケースの学習用データは災害時の画像データであり、データ収集に時間がかかりました。また、集めた画像データを用いてモデルの精度を上げるためにも、機械学習に関する専門的な知識が必要であり、独学での習得には時間がかかりました。機械学習モデルは一度作成したら終わりではなく、モデルの精度改善を行うために繰り返し学習を行う必要があるので、これらの作業が日々の開発工数を圧迫している状況でした。 ソリューション／構成内容 アーベルソフト様は上記の課題に対して、生成 AI サービスを用いた解決の検討を行いました。様々な生成 AI サービスがある中で「 複数のモデルを簡単に切り替られること 」や「 本番環境にすぐ活用できること 」を評価して、Amazon Bedrock を採用いたしました。本ユースケースでは、画像を入力値とするために Anthropic 社のマルチモーダルモデルである Claude 3.5 Sonnet (検証時の最新モデル) を選択して、検証を行いました。検証当初、工夫をせずに生成 AI を利用すると誤検知が頻繁に発生することがわかり、IP カメラの設置箇所ごとに生成 AI に対する命令(プロンプト)を作成することを考えました。具体的にはカメラの画角や写っているオブジェクトを見て、増水の判断をする材料だけ抽出するようなプロンプトを作成しました。生成 AI からのレスポンスも状況の説明をする文章を返すのではなく、結果ごとに比較が可能なスコアを JSON 形式で返すことで、より微細に現在の災害状況のトレンドを把握できるようにしました。 プロンプトの工夫以外にも、前段のイメージサーバーにて、画像から増水の判断に不要な部分を削除するプログラムを実装しました。また、誤検知への対策として、生成 AI が複数回連続で閾値を超えたと判断した際に、ユーザーへ通知を行うように実装しております。この判断に使う回数は増水の深刻度にあわせて可変な値とすることで、緊急度にあわせた対応ができるようになっています。通知機能は既存のサービスから利用できていたメールの他に、LINE のインターフェイスからも利用できるように再設計を行い、ユーザーエクスペリエンスの向上にも努めました。 自社開発モデルの代わりとして Amazon Bedrock を活用することで、精度を向上させることは勿論のこと、自社モデル開発の必要性がなくなり、開発・運用コストを大幅に削減できました。さらに、本対応で培った経験を生かして、水害以外の「交通事故」や「火災」などのユースケースにも対応できるように、現在検証・開発を進めております。 (出展: 株式会社アーベルソフト) 導入効果 Amazon Bedrock を導入することで、下記の3つの効果を得ることができました。 災害の状況を正しく判定する精度が従来から 約 45 %向上 自社モデル開発の必要性がなくなり、開発・運用コストが 年間約 260 時間削減 今まで行っていた水害監視以外に、交通事故や火災などの 幅広い災害を監視したいお客様のニーズに対応すること が可能に 精度の向上やコストの削減の他に、既存のユースケース以外の様々なニーズに対応することができるようになりました。削減できたコストはお客様に還元することを検討しており、最終的には約 40 %低減させた価格で提供できる見込みとなっております。その後も新たなお客様のニーズに応えるための機能検討や検証を継続して行っております。 本取り組みは、アマゾンウェブサービスジャパン合同会社 広域事業統括本部主催の生成 AI コンテストにてアイデアの革新性、ビジネスインパクト、実現性を含めた技術力が総合的に評価され、26 社の取り組みの中で 「生成AIコンテスト 開発実績部門」にて 1 位を獲得 されました。また、 10 月 31 日（木） に開催された「 AWS AI Day 」でもユースケース展示が行われました。 まとめ 今回は災害写真情報サービスで、独自開発の機械学習モデルを AWS の生成 AI サービスである Amazon Bedrock に置き換える事例を紹介させていただきました。Amazon Bedrock を用いることで「 精度向上 」、「 コスト削減 」、「 既存ユースケース以外のニーズに対応 」といった幅広いメリットを享受していただきました。生成 AI モデルへの切り替えは、単純な置き換えだけではなく、プロンプトの検討やデータの最適化など工夫する部分がありますが、比較的少ない工数で大きなメリットを享受することができます。今まで自社開発で提供していた機械学習モデルから、サードパーティ製の生成 AI モデルに置き換えることで、精度の向上やコストの削減をすることにご関心のあるお客様は、ぜひ AWS までお問い合わせください。 株式会社アーベルソフト : 代表取締役社長 西岡 和也 様 (中央右)、第3システム部第2システム課 課長 高橋 圭太郎 様 (中央左) Amazon Web Services Japan : アカウントマネージャー 瀧澤 栞 (左端)、ソリューションアーキテクト 文珠 啓介 (右端) ソリューションアーキテクト 文珠 啓介

みなさんこんにちは。プリンシパルソリューションズアーキテクトの梶本（かじもと）です。9月11日にAWSが主催する自動車業界向けイベント「AWS Autotech Forum 2024」を開催しました。AWS Japanでは、自動車業界の皆様にクラウドを活用してビジネスを加速して頂くことを目指し、 2018 年より事例や最新技術の活用方法等をご紹介する本イベント「AWS Autotech Forum」 を開催して参りました。今回で7回目となる本イベントは9月11日に目黒にあるAWS Japanオフィスにおいて約100名の方にご参加いただき、また収録内容を9月19日にはWebinar形式で昨年同様オンライン配信も行い1000名以上の多くの方にご登録頂きました。 SDV (Software Defined Vehicle) を中核に、クラウドを活用して車載ソフトウェアを効率的に開発するIn Carの取組み、自動車購入後も様々な顧客価値を利用者に提供するOut Carの取組みがデータを中核に融合しつつある今日、自動車産業が人々に提供する価値が大きくなっていることを私も感じています。今年の本イベントでは、自動車産業の変化を第一線で創造しているお客様を代表して、ソニー・ホンダモビリティ株式会社の高倉様、名古屋大学の高田教授様、トヨタ自動車株式会社の佐々木様、本田技研工業株式会社の野川様にご登壇頂きました。 オープニング –竹川 寿也　アマゾン ウェブ サービス　シニア事業開発マネージャー オープニングでは、自動車業界全体で加速するIn Car/Out Car全方位のデジタル化と言う今回のAutotech Forumのテーマについて、SDV技術により人間中心に変わった車室空間や、自動車が後から進化する動き、データを駆使した新たな事業を創造する成長トレンドについて触れ、Forumの意図を説明しました。 AFEELAが目指すMobility Experienceのご紹介 –高倉　大樹 様　ソニー・ホンダモビリティ株式会社　ネットワークサービス開発部　General Manager -柄澤　優子　アマゾンウェブサービス　プリンシパルセールス 本セッションでは、ソニー・ホンダモビリティのモビリティブランドであるAFEELAのプロトタイプ車両(AFEELA Prototype 2024)をAmazonのシアトル本社前のThe Spheres広場に展示いただき、現地からAFEELAが目指す顧客体験について、生中継でご説明いただきました。モビリティがユーザーを認識し、ドアが開く様子や、誕生日やドライビングスコアなど、あたかもモビリティがユーザーの友だちであるかのごとくメッセージを提示してくれる様子をデモしていただけました。またSDVを中核に常に進化し続けるサービスを提供することで、ソニー・ホンダモビリティ様では、お客様との接点を長く深く維持し続けるバリューチェーンの構築についてもご説明いただきました。また、エンタテインメントや物流など幅広いサービスで、異業種のパートナー様とも連携したオープンなエコシステムの形成も紹介されました。 このAFEELAの構想をインフラストラクチャとして支えるAWSクラウドは、自動車のデバイス認証やデータ収集で AWS IoT Core を提供、アプリケーションがデータやイベントの最新情報と同期を取って動作する機能として、 AWS AppSync を提供しており、これらを中核にAFEELAでは、ユーザー、デバイス、スマートフォンなどの認証、連携を実装しています。またデータレイク、分析にも様々なAWSサービスをご利用いただいており、今後もAWSはソニー・ホンダモビリティ様の新たなモビリティ体験の提供をご支援して参ります。 オープンSDVとクラウドサービスへの期待 –高田　広章 様　名古屋大学　教授 名古屋大学の高田先生は、日本におけるコンピュータ科学の重鎮のお一人であり、特に自動車産業に関する造詣も深く、自動車技術会や車載組込みシステムフォーラムなど多くの自動車関連団体の重職を務められています。本セッションでは急速に進む自動車のデジタル化（モビリティDX）やテスラ・中国OEMに代表される新興OEMの急速な進歩と言う大きなビジネス・技術環境の変化に対し、SDV技術を中核に日本の自動車産業をさらに成長路線に導くことを企図した経産省様・国交省様のモビリティDX戦略の意図と、高田先生がリードをされるオープンSDVイニチアチブの狙いについてご説明いただきました。 高田先生は、多種多様なハードウェアとソフトウェアの組合せで構成される自動車においては、SDVの考え方でソフトウェアとハードウェアの分離を行い、相互の進化を受け入れやすくすることが重要であることであることを説明され、次にSDVの進化をOTAによるアップデートが可能なステップ０、OTAにより機能向上し継続的に収益が上げられるステップ１、そしてサードパーティが開発したソフトウェアをインストールすることができる自動車になったステップ２と３段階の進化仮説に触れ、このステップ３を「オープンSDV」と名付けられました。オープンSDVの世界が来るためには安全性に関する取扱いが可能かと言った大きな課題はありますが、移動と言う価値など、自動車はプラットフォームとしてサードパーティに取り魅力的なプラットフォームではないかと高田先生は説かれました。その上で、サードパーティがソフトウェアを作りやすくするためにはビークルAPIの標準化が重要となると投げかけられました。そしてモビリティDX戦略でもビークルAPIの標準化に触れられており、現在COVESAのVSSなど海外でビークルAPIの標準化の動きがあることについても危機感を持たれておられます。そして名古屋大学が中核となりオープンSDVイニチアチブを立ち上げ、オープンなビークルAPI「Open SDV API」を策定していく方針を述べられました。 CXを中核にした「モビリティカンパニー」への取り組み –佐々木　英彦 様　トヨタ自動車株式会社　デジタル変革推進室 CX CENTER担当主査 担当部長 佐々木様は、トヨタ自動車株式会社様の中で、広報、デジタルマーケティングを経てお客様接点（CX）の変革を手掛けられてきています。本セッションでは、トヨタ様が提供されている様々なサービスにおいて、これまでは個別に定義されていたお客様ID体系を、NPS®（ネット・プロモーター：スコア）を指標としてTOYOTAアカウントに統合されたCXの変革についてご紹介いただきました。この変革により、お客様のペルソナが推定できるようになり、また、どの顧客接点がお客様に影響を与えているかも具体的に把握できるようになったとのことです。さらに、CX基盤を通じたお客様からのフィードバックから、車両開発における機能やデザインなど最適な商品開発や改良にも活用が始まったそうです。特にサービスからのデータ分析から車両設計へのフィードバックについては、AWSもデータを中心にした Big Loop構想をSDVで発信 していたため、その構想が具現化されている事例として非常に印象に残りました。今後はトヨタブランドを中核に、サービス、トヨタ車の顧客接点をさらにつなぎ、お客様中心の変革を実現し、モビリティカンパニーとしてのトヨタブランドを目指されると締めくくられました。 佐々木様のご講演では、CXお取組み概要を広く言及いただき、CX基盤を構築にあたりAWSの各種サービスを使っていただいているとのことでしたので、AWSとしても、今後も一層、トヨタ様のCX基盤の充実に協力して参ります。 SDMが導くHonda第二の創業期 –野川　忠文 様　本田技研工業株式会社　ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 ホンダ様は、コネクテッドサービスを以前から手掛けられており、多くの世界初の取り組みを実施されてこられました。そしてコネクテッドサービスは情報配信から車の機能の一部に昇華するとのビジョンを示されました。次に野川様がAWSのイベントであるre:invent 2023にご登壇いただいた時の内容を振り返り、ソフトウェアディファインドモビリティ(SDM)を実現するために、In-CarとOut-Car一体に一歩踏み込んだ「クロスドメイン」連携を行ったことや爆速開発のために、縦割りからクロスドメイン開発のためのSDM Platformを企画、AWSの Amazon Simple Storage Service (Amazon S3) を使ったデータレイク、 AWS IoT Core や AWS IoT Fleetwise を使ったコネクテッド機能などで構築されるDigital Proving Ground (DPG)について紹介されました。また、組織も、従来の縦割り開発チームからDPG Steering Committeeの傘下に開発支援と開発推進の２グループに再編されたOne Teamによつ進められていると報告されました。そして表題にあるHonda第2の創業期として、電動化や知能化を軸としたソフトウェア領域での価値創造を目指すとの方針を示され、多様なモビリティを通じてHonda独自の価値を提供していくSDM世界の実現への意気込みを表明されました。 パネルディスカッション： In Car/Out Carのデジタル化が開くモビリティの未来 パネリスト –佐々木　英彦 様　トヨタ自動車株式会社　デジタル変革推進室 CX CENTER担当主査 担当部長 –野川　忠文 様　本田技研工業株式会社　ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 –梶本 一夫　アマゾン ウェブ サービス　プリンシパルソリューションズアーキテクト ファシリテータ –竹川 寿也　アマゾン ウェブ サービス　シニア事業開発マネージャー パネルディスカッションでは、トヨタ佐々木様、ホンダ野川様に加え、AWSからSDVの技術リプレゼンタティブである梶本も参加して、今回のフォーラムのテーマである「In Car/Out Carのデジタル化が開くモビリティの未来」について、司会の竹川により各パネラーからの考え方や取組みについて改めてディスカッションを行いました。 トヨタの佐々木様からは、CX基盤を通じてお客様起点でフィードバックが入ることが重要で、Out Carのサービス群からIn Carの車両設計が始まった今、「もうIn Car、Out Carと区別することをやめませんか」と、非常に印象に残るご提言をいただきました。 ホンダの野川様からは、DPGによる爆速化の取り組みそのものが、佐々木様のご講演を聞いて正しいと確信したことや、コネクテッドサービスを長年継続することで、お客様起点で車両設計やサービス企画することが大切であることを理解していること、組織としてIn Car、Out Car一体化していることに自信を持てたとのコメントもいただけました。 AWSの梶本からは、ご講演者のお二人の発言を受け、お客様起点で考えるとIn CarとOut Carは区別なく、連続している視点の大切さに感銘した旨を回答。またAWS自身が、多くのお客様に耳を傾け、共通した課題となっている部分でサービスとしてまとめてきた歴史をご紹介し、今後も自動車産業の成長に寄与できるように努力すると決意表明しました。 デモ展示 今回のAutotech Forumでは、会場に来られたお客様に、ミニブースにおけるデモ展示も行いました。デモ展示はAWSからだけではなく、自動車産業に貢献されているパートナー様にも出展いただきました。デモは以下の６点でした。 – Elektrobit Automotive GmbH様:　Power TrainにおけるEVバッテリープラントモデルの最適制御仮想ECU スポーツモードなど走行モードにより配下のMCU群に指示を行うSoC上で動作するASIL-B取得のEB corbos Linux環境、バッテリー制御MCUで動作するEB tresos環境をAWS上で動かし、バッテリープラントモデルの制御最適化の試行錯誤をAWS上で行なう事例をご展示いただきました。 – パナソニックオートモーティブシステムズ株式会社様:　IVI向け仮想ECU virtual SkipGen、Unified HMI IVI向け仮想ECU virtual SkipGenでは、Android Automotive OSやAGL (Automotive Grade Linux)、QNXを動かし、その上でのアプリケーション開発をIVI向けECUが無くてもAWS上だけで行うことができます。さらにパナソニックオートモーティブ様がオープンソース化を推進されているUnified HMIを用いることで、様々なOSで制御されている車室空間のあらゆるディスプレイを一つの仮想ディスプレイからのマッピングとして定義でき、同じ車室空間体験の異なる車種への展開や、複数のディスプレイに跨る同時表示などの実装がAWS上で確認することで簡単になると言う事例をご展示いただきました。 – Wipro Technologies Limited様:　自動運転アルゴリズム開発ツールチェーンでのシャドーモード実演 ADASの改良においては、現在のアルゴリズムと次のアルゴリズム候補の間で、認識性能が改善されるかを確認していくことが重要となります。Wipro様には、同じ認識対象のインプットに対し、現行アルゴリズムでの処理に加え、シャドーモードで新たなアルゴリズムを同時に動かし、両者での差分も提示できるSDVプラットフォームについてご展示いただきました。認識結果の差分をAWS上のCI/CD環境に自動で入力することで再学習が必要な映像シーンを自動選択し、アルゴリズムを改善することで認識率向上を図ると言う自動化について訴求いただきました。 – 富士ソフト株式会社様:　運転環境試験用車両シミュレータ 運転制御のアルゴリズム開発においては、制御アルゴリズム適用時の運転者の挙動が重要なインプットとなります。実際に運転者が着座し、緊急ブレーキを体験でき、その運転者の挙動を観測・分析できるドライビング・シミュレータを富士ソフト株式会社様にはご展示いただきました。また制動状況のシミュレーションもAWS上で生成することで、様々な制動パラメータによる走行データで実験できるようになっていることも訴求いただきました。 – AWS: ①　 AWS IoT FleetWise と Amazon QuickSight を用いた路面画像認識の教師データ作成と学習 AWS IoT FleetWise は、CANデータやADASで使われるカメラ映像を、予め設定した条件に合致した場合にクラウドにアップロードできます。このデモではカメラ映像から降雪やぬかるみなどの路面状況を認識するAIを学習により作成する時、同時にアップロードされるCANデータからタイヤのスリップ状況などを分析した実際の路面状況を教師データとして利用する使い方を訴求しました。 Amazon QuickSight を用いて、各シーンごとにご認識してしまったカメラ映像を抽出し、再学習対象のデータとすることで、路面認識AIの精度を上げることができるようになりました。 – AWS: ②　生成AIを活用した自然言語による自動運転学習用シーン検索 自動運転のアルゴリズム改善が必要になった時、膨大なカメラ映像の中から特定のシーンのみを再学習用のデータとして抽出したいことが、よくあります。このデモでは生成AIを用いて、自動的に分類されたカメラ映像のカットの中から、「交差点を人が渡っているシーン」など自然言語で指示することで、当該シーンが検索できることを訴求しました。生成AIは、今後、自動車業界においても多くの分野で利用されることが期待されています。 過去のイベント – AWS Autotech Forum 2023 – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 梶本一夫（Kazuo Kajimoto） Principal Solutions Architect Amazon Web Services, Inc. 好きなOLP（ Our Leadership Principles ）はBias for Actionです。

みなさんこんにちは。プリンシパルソリューションズアーキテクトの梶本（かじもと）です。9月11日にAWSが主催する自動車業界向けイベント「AWS Autotech Forum 2024」を開催しました。AWS Japanでは、自動車業界の皆様にクラウドを活用してビジネスを加速して頂くことを目指し、 2018 年より事例や最新技術の活用方法等をご紹介する本イベント「AWS Autotech Forum」 を開催して参りました。今回で7回目となる本イベントは9月11日に目黒にあるAWS Japanオフィスにおいて約100名の方にご参加いただき、また収録内容を9月19日にはWebinar形式で昨年同様オンライン配信も行い1000名以上の多くの方にご登録頂きました。 SDV (Software Defined Vehicle) を中核に、クラウドを活用して車載ソフトウェアを効率的に開発するIn Carの取組み、自動車購入後も様々な顧客価値を利用者に提供するOut Carの取組みがデータを中核に融合しつつある今日、自動車産業が人々に提供する価値が大きくなっていることを私も感じています。今年の本イベントでは、自動車産業の変化を第一線で創造しているお客様を代表して、ソニー・ホンダモビリティ株式会社の高倉様、名古屋大学の高田教授様、トヨタ自動車株式会社の佐々木様、本田技研工業株式会社の野川様にご登壇頂きました。 オープニング –竹川 寿也　アマゾン ウェブ サービス　シニア事業開発マネージャー オープニングでは、自動車業界全体で加速するIn Car/Out Car全方位のデジタル化と言う今回のAutotech Forumのテーマについて、SDV技術により人間中心に変わった車室空間や、自動車が後から進化する動き、データを駆使した新たな事業を創造する成長トレンドについて触れ、Forumの意図を説明しました。 AFEELAが目指すMobility Experienceのご紹介 –高倉　大樹 様　ソニー・ホンダモビリティ株式会社　ネットワークサービス開発部　General Manager -柄澤　優子　アマゾンウェブサービス　プリンシパルセールス 本セッションでは、ソニー・ホンダモビリティのモビリティブランドであるAFEELAのプロトタイプ車両(AFEELA Prototype 2024)をAmazonのシアトル本社前のThe Spheres広場に展示いただき、現地からAFEELAが目指す顧客体験について、生中継でご説明いただきました。モビリティがユーザーを認識し、ドアが開く様子や、誕生日やドライビングスコアなど、あたかもモビリティがユーザーの友だちであるかのごとくメッセージを提示してくれる様子をデモしていただけました。またSDVを中核に常に進化し続けるサービスを提供することで、ソニー・ホンダモビリティ様では、お客様との接点を長く深く維持し続けるバリューチェーンの構築についてもご説明いただきました。また、エンタテインメントや物流など幅広いサービスで、異業種のパートナー様とも連携したオープンなエコシステムの形成も紹介されました。 このAFEELAの構想をインフラストラクチャとして支えるAWSクラウドは、自動車のデバイス認証やデータ収集で AWS IoT Core を提供、アプリケーションがデータやイベントの最新情報と同期を取って動作する機能として、 AWS AppSync を提供しており、これらを中核にAFEELAでは、ユーザー、デバイス、スマートフォンなどの認証、連携を実装しています。またデータレイク、分析にも様々なAWSサービスをご利用いただいており、今後もAWSはソニー・ホンダモビリティ様の新たなモビリティ体験の提供をご支援して参ります。 オープンSDVとクラウドサービスへの期待 –高田　広章 様　名古屋大学　教授 名古屋大学の高田先生は、日本におけるコンピュータ科学の重鎮のお一人であり、特に自動車産業に関する造詣も深く、自動車技術会や車載組込みシステムフォーラムなど多くの自動車関連団体の重職を務められています。本セッションでは急速に進む自動車のデジタル化（モビリティDX）やテスラ・中国OEMに代表される新興OEMの急速な進歩と言う大きなビジネス・技術環境の変化に対し、SDV技術を中核に日本の自動車産業をさらに成長路線に導くことを企図した経産省様・国交省様のモビリティDX戦略の意図と、高田先生がリードをされるオープンSDVイニチアチブの狙いについてご説明いただきました。 高田先生は、多種多様なハードウェアとソフトウェアの組合せで構成される自動車においては、SDVの考え方でソフトウェアとハードウェアの分離を行い、相互の進化を受け入れやすくすることが重要であることであることを説明され、次にSDVの進化をOTAによるアップデートが可能なステップ０、OTAにより機能向上し継続的に収益が上げられるステップ１、そしてサードパーティが開発したソフトウェアをインストールすることができる自動車になったステップ２と３段階の進化仮説に触れ、このステップ３を「オープンSDV」と名付けられました。オープンSDVの世界が来るためには安全性に関する取扱いが可能かと言った大きな課題はありますが、移動と言う価値など、自動車はプラットフォームとしてサードパーティに取り魅力的なプラットフォームではないかと高田先生は説かれました。その上で、サードパーティがソフトウェアを作りやすくするためにはビークルAPIの標準化が重要となると投げかけられました。そしてモビリティDX戦略でもビークルAPIの標準化に触れられており、現在COVESAのVSSなど海外でビークルAPIの標準化の動きがあることについても危機感を持たれておられます。そして名古屋大学が中核となりオープンSDVイニチアチブを立ち上げ、オープンなビークルAPI「Open SDV API」を策定していく方針を述べられました。 CXを中核にした「モビリティカンパニー」への取り組み –佐々木　英彦 様　トヨタ自動車株式会社　デジタル変革推進室 CX CENTER担当主査 担当部長 佐々木様は、トヨタ自動車株式会社様の中で、広報、デジタルマーケティングを経てお客様接点（CX）の変革を手掛けられてきています。本セッションでは、トヨタ様が提供されている様々なサービスにおいて、これまでは個別に定義されていたお客様ID体系を、NPS®（ネット・プロモーター：スコア）を指標としてTOYOTAアカウントに統合されたCXの変革についてご紹介いただきました。この変革により、お客様のペルソナが推定できるようになり、また、どの顧客接点がお客様に影響を与えているかも具体的に把握できるようになったとのことです。さらに、CX基盤を通じたお客様からのフィードバックから、車両開発における機能やデザインなど最適な商品開発や改良にも活用が始まったそうです。特にサービスからのデータ分析から車両設計へのフィードバックについては、AWSもデータを中心にした Big Loop構想をSDVで発信 していたため、その構想が具現化されている事例として非常に印象に残りました。今後はトヨタブランドを中核に、サービス、トヨタ車の顧客接点をさらにつなぎ、お客様中心の変革を実現し、モビリティカンパニーとしてのトヨタブランドを目指されると締めくくられました。 佐々木様のご講演では、CXお取組み概要を広く言及いただき、CX基盤を構築にあたりAWSの各種サービスを使っていただいているとのことでしたので、AWSとしても、今後も一層、トヨタ様のCX基盤の充実に協力して参ります。 SDMが導くHonda第二の創業期 –野川　忠文 様　本田技研工業株式会社　ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 ホンダ様は、コネクテッドサービスを以前から手掛けられており、多くの世界初の取り組みを実施されてこられました。そしてコネクテッドサービスは情報配信から車の機能の一部に昇華するとのビジョンを示されました。次に野川様がAWSのイベントであるre:invent 2023にご登壇いただいた時の内容を振り返り、ソフトウェアディファインドモビリティ(SDM)を実現するために、In-CarとOut-Car一体に一歩踏み込んだ「クロスドメイン」連携を行ったことや爆速開発のために、縦割りからクロスドメイン開発のためのSDM Platformを企画、AWSの Amazon Simple Storage Service (Amazon S3) を使ったデータレイク、 AWS IoT Core や AWS IoT Fleetwise を使ったコネクテッド機能などで構築されるDigital Proving Ground (DPG)について紹介されました。また、組織も、従来の縦割り開発チームからDPG Steering Committeeの傘下に開発支援と開発推進の２グループに再編されたOne Teamによつ進められていると報告されました。そして表題にあるHonda第2の創業期として、電動化や知能化を軸としたソフトウェア領域での価値創造を目指すとの方針を示され、多様なモビリティを通じてHonda独自の価値を提供していくSDM世界の実現への意気込みを表明されました。 パネルディスカッション： In Car/Out Carのデジタル化が開くモビリティの未来 パネリスト –佐々木　英彦 様　トヨタ自動車株式会社　デジタル変革推進室 CX CENTER担当主査 担当部長 –野川　忠文 様　本田技研工業株式会社　ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 –梶本 一夫　アマゾン ウェブ サービス　プリンシパルソリューションズアーキテクト ファシリテータ –竹川 寿也　アマゾン ウェブ サービス　シニア事業開発マネージャー パネルディスカッションでは、トヨタ佐々木様、ホンダ野川様に加え、AWSからSDVの技術リプレゼンタティブである梶本も参加して、今回のフォーラムのテーマである「In Car/Out Carのデジタル化が開くモビリティの未来」について、司会の竹川により各パネラーからの考え方や取組みについて改めてディスカッションを行いました。 トヨタの佐々木様からは、CX基盤を通じてお客様起点でフィードバックが入ることが重要で、Out Carのサービス群からIn Carの車両設計が始まった今、「もうIn Car、Out Carと区別することをやめませんか」と、非常に印象に残るご提言をいただきました。 ホンダの野川様からは、DPGによる爆速化の取り組みそのものが、佐々木様のご講演を聞いて正しいと確信したことや、コネクテッドサービスを長年継続することで、お客様起点で車両設計やサービス企画することが大切であることを理解していること、組織としてIn Car、Out Car一体化していることに自信を持てたとのコメントもいただけました。 AWSの梶本からは、ご講演者のお二人の発言を受け、お客様起点で考えるとIn CarとOut Carは区別なく、連続している視点の大切さに感銘した旨を回答。またAWS自身が、多くのお客様に耳を傾け、共通した課題となっている部分でサービスとしてまとめてきた歴史をご紹介し、今後も自動車産業の成長に寄与できるように努力すると決意表明しました。 デモ展示 今回のAutotech Forumでは、会場に来られたお客様に、ミニブースにおけるデモ展示も行いました。デモ展示はAWSからだけではなく、自動車産業に貢献されているパートナー様にも出展いただきました。デモは以下の６点でした。 – Elektrobit Automotive GmbH様:　Power TrainにおけるEVバッテリープラントモデルの最適制御仮想ECU スポーツモードなど走行モードにより配下のMCU群に指示を行うSoC上で動作するASIL-B取得のEB corbos Linux環境、バッテリー制御MCUで動作するEB tresos環境をAWS上で動かし、バッテリープラントモデルの制御最適化の試行錯誤をAWS上で行なう事例をご展示いただきました。 – パナソニックオートモーティブシステムズ株式会社様:　IVI向け仮想ECU virtual SkipGen、Unified HMI IVI向け仮想ECU virtual SkipGenでは、Android Automotive OSやAGL (Automotive Grade Linux)、QNXを動かし、その上でのアプリケーション開発をIVI向けECUが無くてもAWS上だけで行うことができます。さらにパナソニックオートモーティブ様がオープンソース化を推進されているUnified HMIを用いることで、様々なOSで制御されている車室空間のあらゆるディスプレイを一つの仮想ディスプレイからのマッピングとして定義でき、同じ車室空間体験の異なる車種への展開や、複数のディスプレイに跨る同時表示などの実装がAWS上で確認することで簡単になると言う事例をご展示いただきました。 – Wipro Technologies Limited様:　自動運転アルゴリズム開発ツールチェーンでのシャドーモード実演 ADASの改良においては、現在のアルゴリズムと次のアルゴリズム候補の間で、認識性能が改善されるかを確認していくことが重要となります。Wipro様には、同じ認識対象のインプットに対し、現行アルゴリズムでの処理に加え、シャドーモードで新たなアルゴリズムを同時に動かし、両者での差分も提示できるSDVプラットフォームについてご展示いただきました。認識結果の差分をAWS上のCI/CD環境に自動で入力することで再学習が必要な映像シーンを自動選択し、アルゴリズムを改善することで認識率向上を図ると言う自動化について訴求いただきました。 – 富士ソフト株式会社様:　運転環境試験用車両シミュレータ 運転制御のアルゴリズム開発においては、制御アルゴリズム適用時の運転者の挙動が重要なインプットとなります。実際に運転者が着座し、緊急ブレーキを体験でき、その運転者の挙動を観測・分析できるドライビング・シミュレータを富士ソフト株式会社様にはご展示いただきました。また制動状況のシミュレーションもAWS上で生成することで、様々な制動パラメータによる走行データで実験できるようになっていることも訴求いただきました。 – AWS: ①　 AWS IoT FleetWise と Amazon QuickSight を用いた路面画像認識の教師データ作成と学習 AWS IoT FleetWise は、CANデータやADASで使われるカメラ映像を、予め設定した条件に合致した場合にクラウドにアップロードできます。このデモではカメラ映像から降雪やぬかるみなどの路面状況を認識するAIを学習により作成する時、同時にアップロードされるCANデータからタイヤのスリップ状況などを分析した実際の路面状況を教師データとして利用する使い方を訴求しました。 Amazon QuickSight を用いて、各シーンごとにご認識してしまったカメラ映像を抽出し、再学習対象のデータとすることで、路面認識AIの精度を上げることができるようになりました。 – AWS: ②　生成AIを活用した自然言語による自動運転学習用シーン検索 自動運転のアルゴリズム改善が必要になった時、膨大なカメラ映像の中から特定のシーンのみを再学習用のデータとして抽出したいことが、よくあります。このデモでは生成AIを用いて、自動的に分類されたカメラ映像のカットの中から、「交差点を人が渡っているシーン」など自然言語で指示することで、当該シーンが検索できることを訴求しました。生成AIは、今後、自動車業界においても多くの分野で利用されることが期待されています。 過去のイベント – AWS Autotech Forum 2023 – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 梶本一夫（Kazuo Kajimoto） Principal Solutions Architect Amazon Web Services, Inc. 好きなOLP（ Our Leadership Principles ）はBias for Actionです。

本記事は 2023年10月17日に公開された”Announcing the AWS Well-Architected Framework DevOps Guidance”を翻訳したものです。 2024年3月26日 AWS Well-Architected Tool の Lens Catalog に DevOps Lens として DevOps Guidance が追加されました。 このアップデートにより、ユーザはクラウドベースのワークロードをこれらのベストプラクティスに照らして自己評価し、ツールのレポートを通じて改善計画を確認可能です。 Amazon Web Services (AWS) は、 AWS Well-Architected Framework DevOps Guidance を発表しました。AWS DevOps Guidance では、AWS DevOps Saga (訳注 Saga は冒険談や大河小説などを意味する単語です。DevOps を持続的に実践するには時間がかかり、継続的かつ相互に結びついた一連の能力が必要となることを反映し、「Saga」という言葉を用いています)について紹介しています。AWS DevOps Saga は、クラウドの規模でソフトウェア設計や開発、セキュリティ保護及び、効率的な運用を行っていくために、包括的なアプローチを形成していく最新の機能を集めたコレクションです。AWS DevOps Guidance は、Amazon 自身の変革の旅路から得た学びと、世界中に提供しているクラウドサービスを管理してきた経験を基に、あらゆる規模の組織にベストプラクティス、プロセス、技術的な能力を提供することで、ビジネス価値の向上とアプリケーションのより安全かつ高速な提供を促進するために作成されました。 Amazon の DevOps 変革の概要 2000 年代初頭、 Amazon は 独自の DevOps の変革を経験しました。この経験がオンライン書店から AWS クラウドコンピューティング部門の設立へと繋がっています。今日、 AWS は Amazon の経験した独自の DevOps のアプローチと同様の革新的な DevOps アプローチを採用した幅広いプロダクトとサービスを世界中のお客様へ提供しています。この変革のポジティブな効果により、AWS は DevOps の重要性を認識し、その採用と実装の最前線に立っています。 Amazon は自身の変遷と、クラウドへのマイグレーションやモダナイゼーションをお客様に支援してきた経験から DevOps の導入を成功させるための重要な能力についての洞察を得ました。これらの知見を活かし、お客様が DevOps を継続的に導入し実践できるよう、相互に関連する一連の能力を組み込んだ「DevOps Saga」を作成しました。各 DevOps Saga には、成功の指標となる能力、測定する指標、および避けるべき一般的なアンチパターンに対する規範的ガイダンスが含まれています。 DevOps Saga のご紹介 DevOps Saga は 5つの要素から構成され、AWS の DevOps のベストプラクティスを構成するソフトウェア開発プロセスにおける中核的な領域です。 DevOps Sagaを総合的に活用することでクラウド規模でのソフトウェアの設計や開発、セキュリティの確保、効率的な運用を包括的に行うための最新の機能を網羅できます。 DevOps Saga は、組織内での理解の共通化を促進し、DevOps という言葉に対する組織内の定義の統一に役立ちます。また、 DevOps の導入状況を長期間にわたり継続的に測定可能です。DevOps Saga を構成する要素は次の 5 つになります: 組織導入の Saga : お客様中心の適応力のある文化の形成を促進し、人間中心のプロセスの最適化、個人とプロフェッショナルとしての成長、開発者体験の改善に焦点を当てることで、DevOps 導入の基盤を築きます。 開発ライフサイクルの Saga : 組織のワークロードを迅速かつ安全に開発、レビュー、デプロイする能力を高めることを目指しています。フィードバックループ、一貫したデプロイ手法、「すべてをコード化する」アプローチを活用することで、デプロイの効率化を図ります。 品質保証の Saga : 開発プロセスに統合されたテストファーストな手法を提唱することにより、設計観点で well-architected であり、安全で、コストが最適化され、持続可能で、自動化を通じて俊敏性が向上したアプリケーションの提供を保証していきます。また、自動化によるアジリティが向上するように推進します。 自動化ガバナンスの Saga :開発プロセス全体で指令、検出、予防、対応措置の実施を容易にします。自動化されたプロセス、ポリシー、ガードレールを通じて、リスク管理、ビジネスプロセス遵守、アプリケーションおよびインフラストラクチャのコンプライアンスを様々な規模で実現することを重視しています。 可観測性(オブザーバビリティ)の Saga: 環境やワークロードに可観測性を組み込むアプローチを提示します。これによってチームが問題の検知や対処、パフォーマンスの改善、コストの削減およびビジネス目標と顧客ニーズとの整合性を確保できるようにします。 AWS DevOps Guidance は誰が利用すべきか？ 私たちは、すべての組織がユニークであり、 DevOps を実践するための万能なアプローチはないと認識しています。本記事で提示した推奨事項と例は、お客様の組織の環境、品質、セキュリティのニーズに合わせたカスタマイズして活用いただけます。AWS DevOps Guidance は、幅広いプロフェッショナルや組織を対象に設計されています。初めて DevOps に取り組むスタートアップ企業、プロセスの改善を図る企業、公的機関、クラウドネイティブな企業、AWS クラウドへの移行を検討する企業など、さまざまな組織に適しています。最高技術責任者 ( CTO ) や最高情報セキュリティ責任者 ( CISO ) として戦略的方向性を示す立場の方、ワークロードの設計や展開に携わる開発者やアーキテクト、品質保証、監査、ガバナンスを監督するコンプライアンス担当者など、どのような役割の方々にとっても、このガイダンスは役立つものとなっています。 ネクストステップ AWS DevOps Guidance のリリースを受け、お客様には本書をダウンロードし一読いただき、推奨事項に従ってワークロードの実装とテストを実施いただくことをお勧めします。AWS Well-Architected Framework と併せて AWS DevOps Guidance を活用することで、お客様の組織や個々のワークロードが DevOps のベストプラクティスに準拠しているかを評価し、強みと改善の余地がある領域を特定してください。開発者、運用担当者、意思決定者など、さまざまな役割のメンバーでチームを結成し、評価結果を共有しましょう。AWS DevOps Guidance から得られた洞察を活かして改善領域の優先順位を決め、DevOps 能力を継続的に向上してください。 AWS DevOps Guidance は、 AWS Well-Architected サイト からダウンロードできます。詳細については、AWS アカウントチームまでお問い合わせください。アーキテクチャやサービスの設計を検討する際や、Well-Architected レビューを実施する際には、AWS Well-Architected Framework やその他のガイダンスと同様に、AWS DevOps Guidance を早期から積極的に活用することをお勧めします。AWS DevOps Guidance をご利用の際には、ベストプラクティスやテクノロジーの進化に合わせて改善できるよう、ご意見やご感想をお寄せください。一般的なユースケースや新しい指標、ベストプラクティスが出てくる度に、内容は継続的に更新されます。 本記事はアマゾンウェブサービスジャパン合同会社の畠泰三が翻訳を担当しました。 原文はこちら

11 月 13 日は、 リソースコントロールポリシー (RCP) をご紹介します。これは、AWS Organizations で管理される新しい認可ポリシーで、組織全体のリソースに対する使用可能な最大の許可を設定するために使用できます。これは、AWS 環境に データ境界 を確立し、リソースに対する外部アクセスを大規模に制限するのに役立つ予防的コントロールの一種です。Organizations 内で一元的に強制適用される RCP により、中心的なガバナンスチームとセキュリティチームは、AWS アカウント内のリソースに対するアクセスが、組織のアクセスコントロールガイドラインに準拠していることに自信をもつことができます。 RCP はすべての商用 AWS リージョンで利用可能で、リリース時には次のサービスがサポートされています: Amazon Simple Storage Service (Amazon S3) 、 AWS Security Token Service (AWS STS) 、 AWS Key Management Service (AWS KMS) 、 Amazon Simple Queue Service (Amazon SQS) 、 AWS Secrets Manager 。 RCP を有効にして使用しても追加料金はかかりません。 サービスコントロールポリシー (SCP) との違い 本質的には似ている一方で、RCP は サービスコントロールポリシー (SCP) を補完しますが、独立して機能します。 サービスコントロールポリシー (SCP) を使用すると、AWS Identity and Access Management (IAM) ロールなどの組織内のプリンシパルに付与される許可を制限できます。これらの許可を Organizations 内で一元的に制限することで、AWS サービス、特定のリソース、さらにはプリンシパルが複数の AWS アカウントにまたがってリクエストを実行するために満たさなければならない条件に対するアクセスを制限できます。 一方、RCP を使用すると、組織内のリソースに付与される許可を制限できます。RCP は Organizations 内で一元的に実装するため、複数の AWS アカウントにまたがって、リソースに対する、一貫性のあるアクセスコントロールを強制適用できます。例えば、アカウント内の S3 バケットに対するアクセスを制限して、組織に属するプリンシパルのみがアクセスできるようにすることができます。RCP は、誰が API リクエストを実行しているのかにかかわらず、リソースがアクセスされたときに評価されます。 SCP と RCP のいずれも許可を付与するものではないことに留意してください。これらは、組織内のプリンシパルとリソースに使用可能な最大の許可を設定するだけです。許可を付与するには、適切な IAM ポリシー (ID ベースのポリシーやリソースベースのポリシーなど) を使用する必要があります。 SCP と RCP のクォータは、互いに完全に独立しています。各 RCP は最大 5,120 文字です。組織のルート、各 OU、およびアカウントに最大 5 個の RCP をアタッチでき、組織で最大 1,000 個の RCP を作成して保存できます。 開始方法 RCP の使用を開始するには、まず RCP を有効にする必要があります。これは、Organizations コンソール、 AWS SDK 、または AWS コマンドラインインターフェイス (AWS CLI) を使用して行うことができます。ポリシータイプを有効または無効にできるのは、Organizations 管理アカウントまたは委任された管理者のみであるため、必ずそれらを使用してください。 [すべての機能] オプションで Organizations を使用していることを確認してください。 [一括請求 (コンソリデーティッドビリング) 機能] モードを使用している場合は、RCP を有効にする前に、 すべての機能を使用するように移行 する必要があります。 コンソールユーザーは、まず Organizations コンソールに移動します。 [ポリシー] を選択すると、 [リソースコントロールポリシー] を有効にするオプションが表示されます。 RCP を有効にすると、 [リソースコントロールポリシー] ページで、 RCPFullAWSAccess という新しいポリシーが使用可能になっていることがわかります。これは、自動的に作成され、ルート、各 OU、AWS アカウントなど、組織内のすべてのエンティティにアタッチされる AWS マネージドポリシーです。 このポリシーにより、すべてのプリンシパルが組織のリソースに対して任意のアクションを実行できるようになります。つまり、独自の RCP を作成してアタッチするまで、既存の IAM 許可はすべてこれまでどおりに動作します。 これは、次のようになります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } RCP の作成 これで、最初の RCP を作成する準備が整いました。 例を見てみましょう。 デフォルトでは、AWS リソースは外部プリンシパルに対するアクセスを許可しません。リソース所有者は、ポリシーを設定することで、そのようなアクセスを明示的に付与する必要があります。デベロッパーはアプリケーションのニーズに応じてリソースベースのポリシーを柔軟に設定できますが、RCP を使用すると、中心的な IT チームは組織内のリソース全体で、有効な許可に対するコントロールを維持できます。これにより、デベロッパーが広範なアクセスを付与した場合でも、外部 ID によるアクセスは組織のセキュリティ要件に従って制限されます。 組織内のプリンシパルのみがアクセスできるように、S3 バケットに対するアクセスを制限する RCP を作成してみましょう。 [リソースコントロールポリシー] ページで、 [ポリシーを作成] を選択すると、新しいポリシーを作成できるページが表示されます。 このポリシーを EnforceOrgIdentities と呼びます。このポリシーがどのような効果を有するのかを一目で理解しやすくし、適切にタグ付けできるよう、明確な説明を入力することをお勧めします。 次のセクションでは、ポリシーステートメントを編集できます。事前入力済みのポリシーテンプレートを独自のものに置き換えます。 完全な JSON ポリシードキュメントは次のとおりです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceOrgIdentities", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "[MY ORG ID]" }, "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } } } ] } 詳しく見てみましょう。 Version – これは IAM ポリシーの標準かつ必須の要素です。AWS は下位互換性を維持しているため、最新バージョン (現在は 2012-10-17) を使用しても既存のポリシーが壊れることはなく、新しい機能を使用できます。 Statement – 1 つ以上のステートメントオブジェクトを含めることができる配列。これらの各ステートメントオブジェクトは、単一の許可または許可セットを定義します。 Sid – これはオプションのフィールドで、ポリシー管理とトラブルシューティングに役立ちます。この JSON ポリシードキュメントの範囲内で一意である必要があります。 Effect – 前述のとおり、デフォルトでは、組織内のあらゆるエンティティにアタッチされているすべての AWS プリンシパル、アクション、およびリソースに対するアクセスを許可する RCP があります。そのため、制限を適用するには、 Deny を使用する必要があります。 Principal – RCP では、このフィールドは常に "*" に設定する必要があります。このポリシーを特定のプリンシパルにのみ適用する場合は、Condition フィールドを使用します。 Action – このポリシーが適用される AWS サービスとアクションを指定します。この場合、アクセスコントロールガイドラインを満たしていない場合は、Amazon S3 とのすべてのインタラクションを拒否します。 Resource – RCP が適用されるリソースを指定します。 Condition – 各リクエストについてポリシーを適用すべきかどうかを決定するために評価される条件のコレクション。 RCP を適用するには、すべての条件が true と評価される必要がある ことを覚えておいてください。ここでは、2 つの条件を適用しています。 1.リクエストは外部プリンシパルによって実行されたか? "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "[MY ORG ID]" } この条件は、まず、キー aws:PrincipalOrgID がリクエスト内に存在するかどうかをチェックします。存在しない場合、この条件はそれ以上評価せずに true と評価します。 存在する場合、値を組織 ID と比較します。値が同じ場合は false と評価され、RCP は適用されません。なぜなら、すべての条件が true と評価される必要があるからです。組織内のプリンシパルに対するアクセスを拒否したくないため、これは意図された動作です。 ただし、値が組織 ID と一致しない場合は、リクエストが組織外のプリンシパルによって実行されたことを意味します。条件は true と評価されます。これは、2 つ目の条件も true と評価されれば、RCP が適用される可能性がまだあることを意味します。 2.リクエストは AWS サービスからのものか? "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } この条件は、 aws:PrincipalIsAWSService という特別なキーがリクエストに含まれているかどうかをテストします。このキーは、署名されたすべての API リクエストのリクエストコンテキストに自動的に挿入され、S3 バケットにイベントを書き込む AWS CloudTrail などの AWS サービスからのものである場合は true に設定されます。このキーが存在しない場合、この条件は true と評価されます。 存在する場合は、ステートメントで宣言した値と比較されます。ここでは、値が false と等しいかどうかをテストしています。等しい場合は、リクエストが AWS サービスによって実行されたものではなく、組織外の誰かによって実行された可能性があることを意味するため、 true を返します。それ以外の場合は、 false を返します。 つまり、リクエストが組織内のプリンシパルからのものではなく、AWS サービスからのものでもない場合、S3 バケットに対するアクセスは拒否されます。 このポリシーは単なるサンプルであり、独自のビジネス目標とセキュリティ目標に合わせてカスタマイズすべきです。例えば、このポリシーをカスタマイズして、ビジネスパートナーによるアクセスを許可したり、AWS サービスに対するアクセスを制限して、パートナーがお客様に代わってのみリソースにアクセスできるようにしたりすることができます。詳細については、「 Establishing a data perimeter on AWS: Allow only trusted identities to access company data 」をご覧ください。 RCP のアタッチ RCP をアタッチするプロセスは SCP に似ています。前述のように、組織のルート、OU、または組織内の特定の AWS アカウントに RCP をアタッチできます。 RCP をアタッチした後、影響を受ける AWS リソースに対するアクセスリクエストは RCP 制限に準拠する必要があります。大規模に強制適用する前に、アカウント内のリソースに対する RCP の影響を徹底的にテストすることをお勧めします。個々のテストアカウントまたはテスト OU に RCP をアタッチすることから始めることができます。 実際の動作 これで RCP を作成してアタッチしたので、実際に機能している様子を確認する準備ができました。 デベロッパーがリソースベースのポリシーを組織内の S3 バケットにアタッチし、外部アカウントの ID に対してアクセスを明示的に付与したと仮定します。 RCP は、ユーザーが RCP で許可されているよりも許容度が高いリソースベースのポリシーを保存することを妨げません。ただし、前述のとおり、RCP は認可プロセスの一環として評価されるため、外部 ID によるリクエストはいずれにしても拒否されます。 この外部アカウントを使用してバケットにアクセスを試みることで、これを証明できます。今回は AWS CLI から実行します。 $ aws s3api get-object —bucket 123124ffeiufskdjfgbwer \ --key sensitivefile.txt \ --region us-east-1 local_file An error occurred (AccessDenied) when calling the GetObject operation: Access Denied 環境内での RCP のデプロイのスケール これまで、コンソールを使用して RCP を管理する方法について見てきました。ただし、大規模なコントロール管理の場合は、それらを Infrastructure as Code として設定することを検討し、既存の継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインとプロセスに統合されることを確認すべきです。 AWS Control Tower を使用する場合は、SCP ベースのコントロールに加えて RCP ベースのコントロールをデプロイできます。例えば、AWS Control Tower を使用して、前述の例で作成したものと同様の RCP をデプロイし、外部プリンシパルが組織内の S3 バケットにアクセスできないようにすることができます。これにより、マネージドアカウントのリソースに RCP が一貫して適用され、アクセスコントロールガバナンスが大規模に合理化および一元化されます。 さらに、SCP と同様に、AWS Control Tower は RCP のためにドリフト検出もサポートしています。AWS Control Tower の外部で RCP が変更または削除された場合、ドリフトについて通知され、是正のステップが提供されます。 まとめ リソースコントロールポリシー (RCP) は、組織内の AWS リソースに使用可能な最大の許可に対する一元管理を提供します。SCP とともに、RCP は AWS 環境全体で データ境界 を一元的に確立し、意図しないアクセスを大規模に防ぐのに役立ちます。SCP と RCP は独立したコントロールであり、異なる一連のセキュリティ目標を達成することを可能にします。SCP または RCP のみを有効にするか、または両方のポリシータイプを併用して、多層防御セキュリティモデルの一部として包括的なセキュリティベースラインを確立するかを選択できます。 詳細については、「 AWS Organizations ユーザーガイド 」の「Resource control policies (RCPs)」をご覧ください。 Matheus Guimaraes | @codingmatheus 原文は こちら です。

私は数年前から AWS BuilderCards の進歩を見てきました。あらゆるスキルレベルのプレイヤーがこのカードを使用して、楽しく興味をそそる方法で AWS について学び、カードを組み合わせてアーキテクチャを形成しようと (友好的に) 競い合い、プレイしながら知識を得てポイントを獲得しています。 これまでに 15,000 セット以上の BuilderCards が印刷され、3 回の re:Invent、15 回の AWS Summit、複数のコミュニティイベントで使用されています。例えば、 JAWS Days 2024 の期間中、東京で楽しい時間を過ごしている AWS 愛好家グループの写真をご覧ください。 プレイヤーからのフィードバックは非常に好意的で、1,500 件以上の返信において星 4.8 の顧客満足度スコア (CSAT) を獲得しています。 第 2 エディションの発売開始 AWS BuilderCards の第 2 エディションが re:Invent 2024 で配布され、まもなくオンラインでも購入できるようになるとお知らせできることを嬉しく思います。第 1 エディションへのフィードバックに応えて、第 2 エディションに多くの変更を加えました。概要は次のとおりです。 デザイン – 変更後のデザインでは、カードの内容に重点を置き、カードをより魅力的で遊び心のあるものにするために、グラデーションやパターンが追加されています。フォントサイズが大きくなり、ゲームエフェクトがアイコンとして表示されるようになり、QR コードが BuilderCards サイトを指すようになりました。 ゲームの仕組み – 仕組みが見直され、バランスの改善、プレイの簡素化、一部のバイアスの排除が行われました。一般的なオンプレミスデータセンター環境を表すスターターカードもいくつかあります。 生成 AI アドオンパック – この新しいデッキには、生成 AI と AWS アーキテクチャが連携する方法を示すために設計された、50 枚の BuilderCards が追加されています。このアドオンパックには、ミッションカードのセットも含まれています。これらのカードは、公開されているベストプラクティスやソリューションにリンクする QR コードを使用して、コンテキストを追加します。カードはより大きくなり、テキストとアーキテクチャ図が追加されました。使用は任意で、プレイヤーはミッションを完了すると追加ポイントを獲得できます。各デッキには、カスタマイズに役立つ空白の BuilderCards が 5 枚と空白のミッションカードが 2 枚含まれています。 BuilderCards を入手 re:Invent 2024 に参加する予定なら、Caesar’s Forum の 1 階にある PeerTalk エリアの隣の BuilderCards プレイエリアを訪れてください。 日曜日 – 午前 10 時～午後 6 時 月曜日 – 午前 9 時～午後 5 時 火曜日 – 午前 9 時～午後 5 時 水曜日 – 午前 9 時～午後 5 時 木曜日 – 午前 9 時～午後 4 時 re:Invent の他の参加者と対戦したり、自分のゲームパックやアドオンパックを入手して持ち帰ったりすることができます (1 日あたり 1,000 個をプレゼントいたします)。 山口正徳 氏 (AWS ヒーロー) と 榎本航介 氏 (AWS コミュニティビルダー) の努力のおかげで、その場でプレイできる日本語の BuilderCards もご用意します。翻訳プロセスの詳細については、榎本氏のブログ記事 ( AWS BuilderCards Japanese Edition for JAWS DAYS ) をご覧ください。 re:Invent に参加できない場合でも、すぐに自分のデッキを購入できるようになります。詳細については、ここに戻ってご確認ください! ご期待ください BuilderCards チームは、拡張パックや追加の言語パックなど、その他の特典の開発に取り組んでいます。 – Jeff ; 原文は こちら です。

AWS ニュースブログは 20 周年を迎えました ! 2004 年 11 月 9 日、Jeff Barr は 初めてのブログ記事 を公開しました。当初、彼は TypePad を使用して個人のブログサイトを開設しました。会社やチームではなく、自分の個人的な声を読者に届けたかったのです。 2014 年 4 月 29 日、当社は 新しい AWS ブログサイト を作成し、すべての投稿をそのページに移行しました。現在、AWS ニュースブログには 4,300 件を超える投稿があり、そのうちの 3,200 件以上が Jeff による投稿です。 2016 年 12 月以降、AWS ニュースブログには新しいライターが追加されましたが、引き続き、初日に打ち立てられた AWS ニュースブロガー向けの Jeff のリーダーシップ・プリンシプル に沿って活動しています。AWS ニュースブログのユニークな点は、ブログ作成者が Customer Obsession (顧客第一主義) のリーダーシップ・プリンシプルに沿って製品チームの機能を事前に利用していること、そして Frugality (倹約) のプリンシパルに従って、お客様がそれらをすばやく使用して時間を節約する方法のウォークスルーに焦点を当てていることです。 過去 20 年間、Jeff が果たしてきた基本的かつ極めて重要な役割にとても感謝しています。また、これからの 20 年を楽しみにしています! 11 月 4 日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon MSK 向けの新しい Express ブローカー – Express ブローカーは Amazon MSK Provisioned の新しいブローカータイプで、標準の Apache Kafka ブローカーと比較して、ブローカーあたりのスループットが最大 3 倍向上し、スケールが最大 20 倍速くなり、回復時間が 90% 短縮されるように設計されています。Express ブローカーには、デフォルトで Kafka のベストプラクティスが事前設定されており、すべての Kafka API をサポートし、同じ低レイテンシーパフォーマンスを提供するため、既存のクライアントアプリケーションを変更することなく引き続き使用できます。 新しい Amazon Kinesis Client Library 3.0 – Kinesis Client Library (KCL) 3.0 では、ストリーミングデータを処理するためのコンピューティングコストを、以前の KCL バージョンと比較して最大 33% 削減できるようになりました。KCL 3.0 では、ストリーム処理ワーカーのリソース使用率を継続的にモニタリングし、過度に使用しているワーカーから十分に使用されていない他のワーカーにロードを自動的に再配分する、強化されたロードバランシングアルゴリズムが導入されています。詳細については、 AWS ビッグデータブログの記事 をご覧ください。 Amazon EC2 での Microsoft Windows Server 2025 イメージ – License Included (LI) Amazon マシンイメージ (AMI) で Microsoft Windows Server 2025 のサポートを開始しました。これにより、Windows Server の最新バージョンを簡単かつ柔軟に起動する方法をお客様に提供できるようになりました。 Amazon EC2 で Windows Server 2025 を実行することにより、お客様は Windows Server の最新機能を使用して AWS のセキュリティ、パフォーマンス、信頼性を活用できます。Amazon EC2 で Windows Server 2025 を実行する方法の詳細については、「 AWS での Windows ワークロード 」を参照してください。 Amazon Bedrock での Anthropic の Claude 3.5 Haiku モデル – Claude 3.5 Haiku は、Anthropic の最速モデルの次世代であり 、 迅速な応答時間と改善された推論機能を兼ね備えているため、スピードとインテリジェンスの両方を必要とするタスクに適しています。Claude 3.5 Haiku はあらゆるスキルセットで向上しており、コーディングを含む多くのインテリジェンスベンチマークで、Anthropic の前世代かつ最大のモデルである Claude 3 Opus をも上回っています。詳細については、 AWS ニュースブログの記事 をお読みください。 Amazon Bedrock Prompt Management GA – Amazon Bedrock Prompt Management で、プロンプトの作成、テスト、バージョニング、共有を簡素化できます。一般公開時に、プロンプトを設定し、生成 AI アプリケーションでそれらを呼び出すための拡張オプションを提供する新機能を追加しました。これには構造化プロンプトや、Converse と InvokeModel API の統合などが含まれます。詳細については、 AWS 機械学習のブログ記事 をご覧ください。 Amazon Polly 向けの 6 つの新しい合成型生成音声 – 生成エンジンは、生成 AI テクノロジーを活用した Amazon Polly の最も高度な音声合成 (TTS) モデルです。Ayanda (南アフリカ英語)、Léa (フランス語)、Lucia (ヨーロッパスペイン語)、Lupe (アメリカスペイン語)、Mía (メキシコスペイン語)、Vicki (ドイツ語) の 6 つの合成型生成音声 (女性) を新たに追加しました。これにより、13 の声と 9 つのロケールが拡張され、表現力豊かで魅力的な声の選択肢が増えました。 Amazon OpenSearch Service 延長サポート – 従来の Elasticsearch バージョンと OpenSearch バージョンの標準サポートおよび延長サポートのタイムラインの終了をお知らせします。6.7 までのレガシー Elasticsearch バージョン、7.1〜7.8 までの Elasticsearch バージョン、1.0〜1.2 までの OpenSearch バージョン、2.3〜2.9 までの OpenSearch バージョンの標準サポートは、2025 年 11 月 7 日に終了します。延長サポートでは、通常のインスタンス料金に重ねて段階的な定額料金を支払うことで、標準サポートの終了後も重要なセキュリティアップデートを引き続き受けることができます。詳細については、 AWS ビッグデータブログの記事 をご覧ください。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS のその他のニュース 興味深い他のニュース項目をいくつかご紹介します。 CEO の AWS データセンター訪問 – AWS の CEO である Matt Garman は先日、弊社の AWS データセンターの 1 つを訪問して素晴らしい時間を過ごし、チームによってもたらされる継続的なイノベーションを確認することができました。もちろん、Amazon の上級幹部がフルフィルメントセンター、コンタクトセンター、データセンターを訪れ、お客様のために作業を行うのは当然のことです。AWS データセンターは、あらゆる面でお客様向けに設計されており、最大の回復力、パフォーマンス、エネルギー効率を実現します。 AWS は、AWS データセンターの近くで中小企業の支援、雇用の創出、持続可能性に関する取り組みの立ち上げ、教育プログラムの開発を行っています。最新情報を入手 – コミュニティでの AWS: About Amazon News では、米国中のデータセンターの近くで起きていることをご紹介します 。 Amazon での Amazon Q Business – 以前、とある Amazon ストーリーをご紹介 しました。 Amazon Q Developer のコード変換を使用して、 30,000 件以上の古い Java アプリケーションを Java 17 バージョンに移行 したというものです。最新バージョンの Java に移行したことで、以前の手動作業に比べて 4,500 年分以上もの開発者の労力が削減され、同社は年間 2 億 6,000 万 USD を節約しました。 今日ご紹介するのは、 Amazon での Amazon Q Business のもう 1 つのドッグフーディングのストーリー です。Amazon は Amazon Q Business と共同で社内チャットボットを構築し、Amazon の開発者から寄せられた 100 万件を超える質問を解決しました。これにより、手作業による技術調査に費やす時間を 45 万時間以上削減できました。 私たちのチームは、何百万もの内部文書を使って Amazon Q Business をオンボーディングし、チームが毎日使用するツールに Q Business を統合しました。開発者は、Q&A 掲示板や Slack チャンネルで、複雑な技術的質問への回答を何時間も待つのではなく、数秒で得られるようになりました。 PGA TOUR の TOURCast – ゴルフがお好きなら、このニュースに興味があるはずです。 PGA TOUR は、 TOURCast を日本の 2024 ZOZO CHAMPIONSHIP でデビューさせました。これは、 CDW を利用した ShotLink と呼ばれる新しいスコアリングシステムに基づいて、より良い統計データを収集して広め、ファンとゲームとの距離を近づけるためです。PGA TOUR がこのテクノロジーをアジアに持ち込み、AWS の柔軟性とスケーラビリティを活用して独自の課題を克服したのはこれが初めてです。 PGA TOUR のボランティアが ZOZO CHAMPIONSHIP のフェアウェイに、特定のショットデータを入力して Shotlink Select Plus にフィードバックする GPS 機器を設置しているところ。[画像: PGA TOUR] 同社は過去 2 年間で、新しいクラウドスタックにスコアリングシステムを完全に再構築しました。AWS クラウドでは、ハイテクレーダーシステム、カメラ、手動入力のいずれから送信されるデータであっても、システムがすべてシームレスに処理します。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS GenAI Lofts – AWS GenAI Lofts は、テクノロジーを紹介するだけに留まらず、スタートアップ、開発者、投資者、業界エキスパートが一堂に集まって交流する場も提供します。深いインサイトを得たい、または 生成 AI の専門家から質問の回答を得たいと考えているかにかかわらず、GenAI Loft は皆さんのニーズに対応し、次のイノベーションの構築を開始するために必要な事柄のすべてを提供します。 サンパウロ (11 月 20 日まで) と パリ (11 月 25 日まで) のイベントに参加しましょう。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスに参加しましょう。日程は、 インドネシア、ジャカルタ (11 月 23 日)、 インド、コーチ (11 月 14 日) です。 AWS re:Invent – 12 月 2〜6 日にラスベガスで開催される毎年恒例の学習イベントに、引き続き ご登録 いただけます。驚くことに、Amazon の CEO である Andy Jassy は、 今年も戻ってきて AWS re:Invent に参加すると発言しました。彼はこう語っています。「いつものように、このイベントを学習イベントにすることが最優先事項です。そうすれば、お客様は大きな成果を取り戻し、自身の顧客体験やビジネスを変えることができます。また、皆様に気に入っていただけると考えているさまざまなことを発表する予定です」 お会いできるのを楽しみにしています! 近日開催されるすべての対面イベントと仮想イベントを閲覧できます。 11 月 11 日週はここまでです。11 月 18 日週の Weekly Roundup もお楽しみに! – Channy この記事は、 Weekly Roundup  シリーズの一部です。AWS からの興味深いニュースやお知らせを簡単にまとめたものを毎週ご紹介します! 原文は こちら です。

AWS CloudFormation を利用することで、クラウドアプリケーションのインフラストラクチャをコードとしてモデル化してプロビジョニングすることが容易になります。 CloudFormation テンプレートは直接 JSON または YAML で記述できるだけでなく、 AWS Cloud Development Kit (CDK) などのツールで生成することもできます。これらのテンプレートが CloudFormation サービスにサブミットされると、リソースはスタックという単位でまとめられ、依存関係を反映した順序でデプロイされます。スタックイベントの詳細は コンソール 上で表形式で確認できます。 そしてこの度、より視覚的で直感的なイベントのビューを提供する deployment timeline view という新機能が登場しました。この機能はスタック操作で CloudFormation が実行した一連のアクションを視覚化します。この機能が提供する視覚的なタイムラインは、リソースがプロビジョニングされた正確な順序、リソース間の依存関係、プロビジョニングにかかった時間を示します。デプロイが失敗した際は根本原因と考えられる箇所を示します。デプロイの舞台裏で起きていることについての追加コンテキストと可視性を提供することで既存の表形式のビューを補完します。 図 1: CloudFormation deployment timeline view の機能の概要 どのように動作するか 新機能の deployment timeline view を利用するために必要なのは、スタックの作成、更新、削除の操作だけです。AWS CloudFormation コンソールで Events タブを選択し、Table view の横にある Timeline view タブをクリックします。 CloudFormation がテンプレートで定義されたリソースのプロビジョニングを開始すると、各リソース操作がタイムラインビューで棒線として表示されます。 リソースは、最新の操作があったリソースが一番上になるように時系列順に垂直に積み上げらます。各リソースアクションは、それぞれのアクションに応じて色分けされた水平の棒で視覚化されます。 ダークモードではロールバック中とロールバック完了のスイッチの色が切り替わる バーの上にカーソルを移動させると、完全なリソース名やリソース操作の開始/終了時刻など詳細な情報が表示されます。 デプロイが失敗した場合は、CloudFormation は失敗の原因と考えられるリソース操作のバーを赤白の縞模様で強調表示します。このバーにカーソルを移動すると、具体的な失敗理由が表示されます。 シンプルなスタックを作成する CloudFormation コンソールを使用してシンプルなスタックを作成します。デプロイを開始して視覚的なタイムラインビューを確認します。 1. CloudFormation コンソールから、 Create stack をクリックし、 with new resources を選択します。 図 2: CloudFormation コンソールの create stack ボタン 2. スタック作成ウィザードで Choose an existing template をクリックし Upload a template file を選択します。 Choose file をクリックしデプロイするスタックのテンプレートファイルを選択してアップロードします。この記事では、 こちら で提供されているテンプレートを使用します。このテンプレートをダウンロードして使用するほかに、独自のテンプレートを使用することもできます。独自のテンプレートを使用した場合はタイムラインビューの内容がこの記事とは異なるものになります。 (翻訳者補足: ここで紹介されているテンプレートはオレゴンリージョンでのみデプロイに成功します) 図 3: CloudFormation コンソールの スタック作成ウィザード アプリケーションスタックには、Amazon EC2 インスタンス ( AWS::EC2::Instance )、Amazon VPC ( AWS::EC2::VPC )、およびサブネット ( AWS::EC2::Subnet ) やインターネットゲートウェイ ( AWS::EC2::InternetGateway ) などの VPC リソースが含まれています。 3. テンプレートをアップロードしたら Next をクリックし、必要に応じてスタック名とパラメータを入力します。 スタックデプロイの後続の手順を完了させ、スタックの作成を開始します。 4. スタックイベントページで、 Table view の横の Timeline view タブをクリックします。 CloudFormation が最初に VPC、その後でサブネット、最後に EC2 インスタンスをプロビジョニングしていく間の進捗状況をリアルタイムで確認できます。 図 4: CloudFormation が実行中のデプロイのタイムラインビュー 5. タイムラインは 5 秒ごとに表示をリフレッシュし、デプロイの進捗状況を更新します。5 秒後、次のようなタイムラインビューが表示されます。 図 5: 5 秒後に更新されたタイムライン 図 6: 完了したデプロイのタイムラインビュー 上のタイムラインでは、CloudFormation によってプロビジョニングされたリソースを表すバーが下から上に向かって並び、それぞれのリソース操作が発生した順序やリソース間の依存関係を読み取ることができます。 バーは操作の進行にともなって青 (進行中)、黄 (整合性チェック中)、緑 (成功)または赤 (失敗) に変化します。 図 7: リソース詳細ポップオーバー いずれかのバーにカーソルを置くと、各デプロイフェーズの開始/終了時間や完全なリソース名などの詳細が表示されます。グラフのポップオーバーに表示される詳細情報から、CloudFormation が InternetGateway リソースを 2 秒で作成し、その後 15 秒待機してリソースが完全に動作しているかどうかを確認してから完了としてマークしたことを読み取ることができます。このフェーズをリソース整合性チェックフェーズ (resource consistency check phase)、またはリソース安定化フェーズ (resource stabilization phase) と呼びます。これによって CloudFormation をはじめとする Infrastructure as Code (IaC) ツールは復元力のあるデプロイメントを確かなものにすることができます。詳しくは CloudFormation optimistic stabilization strategy の記事 (日本語翻訳版は こちら ) をお読みください。 ロールバック完了状態のスタック スタックのデプロイが失敗した場合、CloudFormation は現在のスタック操作の前の安定した状態にロールバックします。 以下のタイムラインビューでは、失敗したスタック操作が完全にロールバックされた状態で表示されています。 赤と白の縞模様で強調表示されているリソースが根本原因である可能性が高いので、すぐにトラブルシューティングを開始できます。 図 8: ロールバック完了状態のスタックのタイムラインビュー まとめ 新機能の CloudFormation deployment timeline view では、CloudFormation が Infrastructure as Code のテンプレートで定義されたリソースをプロビジョニングする際のオーケストレーションフローと依存関係を可視化できるようになりました。 この視覚的なタイムラインビューを活用することで、デプロイメントの失敗の根本原因を素早く特定したり、プロビジョニングプロセスの理解を深めることができます。 この機能は、現在 CloudFormation がサポートされているすべての AWS リージョンで利用可能です。 ぜひ CloudFormation コンソールにアクセスし deployment timeline view を使ってみてください。 著者紹介: Idriss Laouali Abdou Idriss は AWS のシニアプロダクトマネージャーであり、AWS IaC のお客様に最高の体験を提供することに尽力しています。仕事以外では、何千人もの学生を支援する教育コンテンツを作成したり、料理をしたり、ダンスをしたりしています。 Jamie To Jamie はフロントエンドエンジニアであり、過去 3 年間 AWS IaC のお客様にコンソール機能を提供してきました。仕事以外では、絵を描いたり、フーズボールをしたりするのが好きです。 Puran Zhang Puran は 過去 4 年間フロントエンドエンジニアとして IaC コンソールに貢献してきました。仕事以外では、キッチンやコーヒーバーにいるところ、または次のレストランへ急いでいるところをよく見かけます。 本記事は 2024/11/11 に投稿された  Peek inside your AWS CloudFormation Deployments with timeline view を翻訳したものです。翻訳は Solutions Architect : 国兼 周平 (Shuhei Kunikane) が担当しました。

11 月 8 日、 Amazon Location Service は、 Routes 、 Places 、 Maps 機能の能力を拡張および改善する 17 個の強化された新たな API をリリースしました。これにより、開発者にとって総合的かつ効率的なエクスペリエンスが実現します。機能を強化し、移行を簡素化するこれらの更新により、Amazon Location Service は幅広いアプリケーションでさらに利用しやすく、便利になりました。 静的および動的レンダリングオプションを使用して、高度なルート最適化、通行料計算、GPS トレーススナップ、さまざまなマップスタイルにアクセスできるようになりました。また、関心のある地点に関する豊富で詳細な情報を利用して、近接度ベースの検索と予測提案を実行できるようになりました。 Amazon のロードマップの大部分は、お客様からのフィードバックに基づいています。Amazon Location Service を使用してアプリケーションを構築している多くのお客様から、位置情報ベースのデータを扱う際には、専用の API と、連絡先情報や営業時間などのより詳細な情報が必要であるとのご意見が寄せられています。現在の API セットは多くのお客様に貴重なツールを提供してきましたが、開発者は詳細なルートプランニング、近接度ベースの検索、追加の場所の詳細、静的マップ画像などの追加機能を望んでいると表明しています。これらの新しい API は開発者の要求に応え、すぐに使用できるより包括的な位置情報ソリューションを提供します。 新機能と拡張機能 11 月 8 日のリリースでは、お客様のフィードバックに直接応える、10 個の更新された API と 7 個のまったく新しい API を紹介します。Routes、Places、Maps の各サービスには、より幅広いユースケースをサポートできるように設計された、特定の機能強化が施されています。 Routes Amazon Location Routes API は、高度なルートプランニングとカスタマイズオプションをサポートするようになり、ユーザーは次のことができるようになりました。 CalculateIsolines で、特定の移動時間または距離内のサービスエリアを特定する OptimizeWaypoints で最も効率的なウェイポイントの順序を決定し、移動時間または距離を最小限に抑える 通行料を計算して、有料道路を含むルートの正確なコスト見積もりを提供する SnapToRoads で地点を道路網にスナップすることで、GPS トレースを正確に照合する これらの機能により、ユーザーのためにより正確かつ動的なルートエクスペリエンスを設計できます。例えば、物流会社では、ライブ交通量を考慮して配達にかかる交通費を最小限に抑えながら、ドライバーのルートをリアルタイムで最適化できます。 Maps 更新された Amazon Location Maps API には、熟練した地図製作者によって作成された、用途に合ったマップスタイルが含まれています。これらのマップスタイルは、市場投入までの時間を短縮し、カスタムマップ作成の必要性を排除するプロフェッショナルなデザインを提供します。さらに、Static Map Image 機能により、開発者は静的マップをアプリケーション内で統合できるため、継続的なデータストリーミングの必要性が削減され、やりとりが不要なユースケースでのパフォーマンスが向上します。 Maps API の主な機能は次のとおりです。 GetTile で X、Y、Z 軸の値を指定して、タイルセットからタイルをダウンロードする GetStyleDescriptor でスタイルに関する情報を返す GetStaticMap で、レポートや視覚化を目的とした非インタラクティブなマップのレンダリングを可能にする Places Amazon Location Places API の強化によって、より詳細な検索機能が実現され、位置情報データをよりきめ細かいものにしてほしいというリクエストに対応できるようになりました。この新機能には以下のものが含まれます。 SearchNearby と Autocomplete が近接度ベースのクエリをサポートし、予測変換機能を有効にしたことによる、ユーザーエクスペリエンスの向上 関心のある地点の営業時間、連絡先情報、追加属性などのカテゴリを使用したビジネス詳細の強化 これらの機能は、フードデリバリーサービスや小売アプリケーションなど、ユーザーが近くの場所に関する詳細情報を必要とするアプリケーションで特に役立ちます。例えば、顧客がフードデリバリーアプリケーションを開き、 SearchNearby を使用して近くのレストランを検索し、営業時間や連絡先情報などのレストランの詳細を取得して空き状況を確認するとします。複数の配達注文がドライバーに割り当てられると、アプリケーションは OptimizeWaypoints を使用して、最も効率的な集荷および配達のルートを提案します。ドライバーがルートをたどると、 SnaptoRoads がドライバーの位置を正確に視覚化し、顧客によるリアルタイムの追跡体験を向上します。 Enhanced Location Service の実行 API の呼び出しは簡単です。 AWS コマンドラインインターフェイス (AWS CLI) 、当社の AWS SDK のいずれか、またはプレーンな REST API を使用できます。ただし、ウェブアプリまたはモバイルアプリのマップに情報を表示するには、追加の設定が必要です。このプロセスは詳しく説明されていますが、非常に詳細であるため、ここにすべて記載することはできません。このデモでは、API の使用に焦点を当てます。 Amazon Location Service では、API コールを AWS API 認証 ( AWS Sigv4 認証 ) または API キーを介する方法の 2 つの方法で認証できます。API キーは、エンドユーザーが認証されていないモバイルアプリケーションの開発者にとって、または Amazon Cognito との統合が不可能な場合に便利です。これはフロントエンドアプリケーションに推奨される認証方法です。 API の多様性と、アプリケーション内での統合がいかに簡単かを示すために、デモの各ステップで AWS CLI、cURL、グラフィカル REST API クライアントを組み合わせて使用します。 ステップ 1: API キーの作成 まず、AWS CLI を使用してアプリケーションの API キーを作成します。 AWS マネジメントコンソール で API キーを管理することもできます。 REGION=eu-central-1 KEYNAME=geo-key-seb aws location create-key --region ${REGION} --key-name ${KEYNAME} --restrictions \ AllowActions="geo-routes:*","geo-places:*","geo-maps:*",\ AllowResources="arn:aws:geo-routes:${REGION}::provider/default",\ "arn:aws:geo-places:${REGION}::provider/default",\ "arn:aws:geo-maps:${REGION}::provider/default" \ --no-expiry { "Key": "v1.public.ey...cy", "KeyArn": "arn:aws:geo:eu-central-1:02345678901:api-key/geo-key-seb", "KeyName": "geo-key-seb", "CreateTime": "2024-09-29T09:35:53.115000+00:00" } このコマンドによって API キーが生成され、これを使用して Amazon Location API を呼び出すことができます。 ステップ 2: 地理座標の取得 次に、 cURL を使用して GeoCode を呼び出し、 QueryText パラメータに住所を渡すことで、フランスのリール中心部の地理座標 ( 経度 と 緯度 ) を取得します。 $ curl --silent -X "POST" "https://places.geo.eu-central-1.amazonaws.com/v2/geocode?key=v1.public.ey...cy" \ -d $'{ "QueryText": "Grand Place, Lille, France" }' {"ResultItems":[{"PlaceId":"AQ...5U","PlaceType":"Street","Title":"Grand'Place, 59800 Lille, France", "Address":{"Label":"Grand'Place, 59800 Lille, France", "Country":{"Code2":"FR","Code3":"FRA","Name":"France"}, "Region":{"Code":"HDF","Name":"Hauts-de-France"},"SubRegion":{"Name":"Nord"}, "Locality":"Lille","District":"Centre","PostalCode":"59800", "Street":"Grand'Place","StreetComponents":[{"BaseName":"Grand'Place","Language":"fr"}]}, "Position":[3.06361,50.63706], "MapView":[3.0628,50.6367,3.06413,50.63729], "MatchScores":{"Overall":1,"Components":{"Address":{"Country":1,"Locality":1,"Intersection":[1]}}}}]} これにより、市内中心部の GPS 座標 [3.06361, 50.63706] を含む複数のデータポイントが返されます。 ステップ 3: 近くの場所の検索 取得した座標を使用しながら、REST API クライアントツールを利用して SearchNearby API を呼び出し、リール中心部周辺の興味深い場所を見つけます。 画面の右側に、API レスポンスが表示されます。レストラン、銀行、駐車場などの近くの場所のリストです。カテゴリを指定したり、検索範囲を制限したりすることで、さらに検索を絞り込めます。 SearchNearby API では、バウンディングボックス内の検索を制限したり、ビジネスチェーン、カテゴリ、国、食品の種類を含めたり除外したりするのに役立つ、オプションの Filter パラメータを使用できます。 "Filter": { "BoundingBox": [ number ], "ExcludeBusinessChains": [ "string" ], "ExcludeCategories": [ "string" ], "ExcludeFoodTypes": [ "string" ], "IncludeBusinessChains": [ "string" ], "IncludeCategories": [ "string" ], "IncludeCountries": [ "string" ], "IncludeFoodTypes": [ "string" ] }, 近くの関心のある場所を検索したところ、返された結果の 1 つは、国際的に有名なマクドナルドでした 。 ステップ 4: 道順の取得 最後に、AWS CLI を使用して 2 つの市内中心部 (ベルギーの ブリュッセル とフランスの リール ) 間のルートを計算します。 aws location calculate-routes \ --origin 4.35278 50.84687 \ --destination 3.06361 50.63706 \ --key "v1.public.ey...cy" レスポンスには、マップ上にパスをレンダリングするための ポリライン と、ルート案内のステップバイステップリストが含まれます。 ... "TravelMode": "Car", "Type": "Vehicle", "VehicleLegDetails": { "TravelSteps": [ { "Duration": 15, "Distance": 75, "ExitNumber": [], "GeometryOffset": 0, "Type": "Depart" }, { "Duration": 10, "Distance": 8, "ExitNumber": [], "GeometryOffset": 2, "Type": "Turn", "TurnStepDetails": { "Intersection": [], "SteeringDirection": "Right", "TurnIntensity": "Typical" } }, ... ステップ 5: マップでの道順の表示 マップ上のルートを視覚化するには、ウェブアプリケーションやモバイルアプリケーションでマップを表示するためのレンダリングエンジンである MapLibre ライブラリを使用します。 Amazon Location Service デベロッパーガイド の手順に沿って、ルートを表示する基本的なアプリを作成しました。 MapLibre に加えて、 AWS Amplify を使用してアプリケーションに Amazon Location データを統合して表示することもできます。 開始方法 これらの新規および更新された API を使用して、Amazon Location Service はお客様のビジネスニーズに応える、より包括的なマッピングおよびロケーションデータのスイートを提供します。これにより、開発者の俊敏性とスケーラビリティが向上し、開発ライフサイクルが加速されます。 はじめに、更新された Amazon Location Service デベロッパーガイド を確認し、今すぐこれらの機能の統合を開始してください。 Amazon Location Service ページ にアクセスして詳細を確認したり、お気に入りの AWS SDK で API を試して、アプリケーションをどのように強化できるかを確認したりすることもできます。 — seb 原文は こちら です。

11 月 7 日、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) の新しいブローカータイプであるエクスプレスブローカーの一般提供について発表します。Apache Kafka を実行している標準ブローカーと比較して、ブローカーあたりのスループットが最大 3 倍向上し、スケールが最大 20 倍速くなり、復旧時間が 90% 短縮されるように設計されています。エクスプレスブローカーには、デフォルトで Kafka のベストプラクティスが事前設定されており、Kafka API をサポートし、Amazon MSK のお客様が期待するのと同じ低レイテンシーパフォーマンスを提供するため、既存のクライアントアプリケーションを変更することなく引き続き使用できます。 エクスプレスブローカーを使用すると、Amazon MSK でプロビジョニングされたクラスターを使用する際に、Kafka アプリケーションのコンピューティングとストレージの伸縮性が向上します。Amazon MSK は、Apache Kafka をベースにした可用性が高くスケーラブルなアプリケーションを簡単に構築して実行できる、フルマネージド型の AWS サービスです。 エクスプレスブローカーが持つ主な機能と、享受できる利点について詳しく見ていきましょう。 ハンズフリーストレージ管理による運用の簡略化 – エクスプレスブローカーは、事前プロビジョニングなしで無制限のストレージを提供し、ディスク関連のボトルネックを解消します。クラスターのサイズ設定はより単純で、必要なのは入力と出力のスループットをブローカーごとの推奨スループットで割ったものです。これにより、プロアクティブなディスク容量の監視とスケーリングが不要になり、クラスター管理が簡素化され、潜在的な障害の原因が排除されることで耐障害性が向上します。 ブローカーの数が少なく、ブローカーあたりのスループットは最大 3 倍 – ブローカーあたりのスループットが高いほど、同じワークロードでクラスターを小さくできます。標準ブローカーのスループットはクライアントトラフィックとバックグラウンド操作を考慮に入れる必要があります。 m7g.16xl の標準ブローカーは 154 MBps の入力を安全に処理します。エクスプレスブローカーは独自の設定とリソース分離を採用しているため、 m7g.16xl サイズのインスタンスでは、クラスターイベント中にパフォーマンスや可用性を損なうことなく、最大 500 MBps の入力を安全に管理できます。 20 倍の高速スケーリングによる高い使用率 – エクスプレスブローカーはスケーリング中のデータ移動を減らし、標準ブローカーの最大 20 倍の速度を実現します。これにより、より迅速で信頼性の高いクラスターサイズ設定が可能になります。各ブローカーの入力スループットキャパシティを監視し、数分以内にブローカーを追加できるため、トラフィックの急増を見越してオーバープロビジョニングを行う必要がなくなります。 耐障害性が高く、復旧速度が 90% 向上 – エクスプレスブローカーは、高い耐障害性を必要とするミッションクリティカルなアプリケーション向けに設計されています。設定ミスによる障害を減らす 3 つの方法のレプリケーション (RF=3) など、ベストプラクティスがデフォルトであらかじめ設定されています。また、エクスプレスブローカーは、標準の Apache Kafka ブローカーと比較して、一時的な障害からの復旧が 90% 速くなります。エクスプレスブローカーの再調整と復旧は、最小限のクラスターリソースしか使用しないため、キャパシティプランニングが簡素化されます。これにより、リソース使用率が高まるリスクがなくなり、クラスターのサイズを適正化する際に継続的に監視する必要がなくなります。 Amazon MSK では、次のように、ワークロードと好みに応じてオプションを選択できます。 MSK プロビジョンド MSK Serverless 標準ブローカー エクスプレスブローカー 設定範囲 柔軟性が最も高い 柔軟 柔軟性が最も低い クラスターの再調整 カスタマーマネージド カスタマーマネージド ただし、最大で 20 倍速く MSK マネージド 容量管理 はい はい (コンピューティングのみ) なし ストレージ管理 はい なし なし エクスプレスブローカーは、コストを削減し、耐障害性を高め、運用上のオーバーヘッドを抑えることができるため、すべての Kafka ワークロードに最適な選択肢となっています。容量、設定、スケール方法の側面を一切管理せずに Kafka を使用したい場合は、 Amazon MSK Serverless を選択できます。これにより、完全に抽象化された Apache Kafka エクスペリエンスが提供され、インフラストラクチャの管理が不要になり、自動的にスケールされ、リソース利用を最適化する必要のない従量制料金の消費モデルで請求されます。 Amazon MSK のエクスプレスブローカーの開始方法 エクスプレスブローカーを使い始めるには、Amazon MSK が提供する サイズ設定と料金のワークシート を使用できます。このワークシートは、ワークロードに対応するために必要なクラスターサイズを見積もるのに役立ちます。また、発生する月次総コストのおおよその見積もりも得られます。 ワークロードのスループット要件は、クラスターのサイズを決定する主な要因です。クラスターに必要なブローカーのサイズと数を決定するには、パーティションや接続数などの他の要素も考慮する必要があります。例えば、ストリーミングアプリケーションで 30 MBps のデータ入力 (書き込み) と 80 MBps のデータ出力 (読み取り) の容量が必要な場合は、3 つの express.m7g.large ブローカーを使用してスループットのニーズを満たすことができます (ワークロードのパーティション数が、Amazon MSK が m7g.large インスタンスに推奨するパーティションの最大数以内であることを前提とします)。 次の表は、持続可能で安全な運用のための、インスタンスサイズあたりの推奨最大入力数、出力数、およびパーティション数を示しています。これらの推奨事項の詳細については、Amazon MSK デベロッパーガイドの ベストプラクティス セクションをご覧ください。 インスタンスサイズ 入力 (MBps) 出力 (MBps) express.m7g.large 15.6 31.2 express.m7g.4xlarge 124.9 249.8 express.m7g.16xlarge 500.0 1000.0 ワークロードに必要なエクスプレスブローカーの数とサイズを決定したら、 AWS マネジメントコンソール に移動するか、 CreateCluster API を使用して Amazon MSK でプロビジョニングされたクラスターを作成します。 Amazon MSK コンソール で新しいクラスターを作成するときに、 [Broker type] (ブローカータイプ) オプションで [Express brokers] (エクスプレスブローカー) を選択し、そのブローカーに対してプロビジョニングするコンピューティング容量の量を選択します。スクリーンショットでわかるように、エクスプレスブローカーには Apache Kafka 3.6.0 バージョンと Graviton ベースのインスタンスを使用できます。エクスプレスブローカーのストレージを事前にプロビジョニングする必要はありません。 また、これらの設定の一部をカスタマイズして、好みに応じてクラスターのパフォーマンスをさらにファインチューニングすることもできます。詳細については、Amazon MSK デベロッパーガイドの「 エクスプレスブローカーの設定 」を参照してください。 AWS コマンドラインインターフェイス (AWS CLI) で MSK クラスターを作成するには、 create-cluster コマンドを使用します。 aws kafka create-cluster \ --cluster-name "channy-express-cluster" \ --kafka-version "3.6.0" \ --number-of-broker-nodes 3 \ --broker-node-group-info file://brokernodegroupinfo.json brokernodegroupinfo.json という名前の JSON ファイルには、Amazon MSK にブローカーノードを分散させたい 3 つのサブネットを指定します。 { "InstanceType": "express.m7g.large", "BrokerAZDistribution": "DEFAULT", "ClientSubnets": [ "subnet-0123456789111abcd", "subnet-0123456789222abcd", "subnet-0123456789333abcd" ] } クラスターが作成されると、ブートストラップ接続文字列を使用してクライアントをクラスターエンドポイントに接続できます。 エクスプレスブローカーを使用すると、垂直方向にスケール (インスタンスサイズを変更) または水平方向にスケール (ブローカーを追加) できます。垂直スケーリングにより、パーティションを再割り当てしなくてもスループットが 2 倍になります。水平スケーリングではブローカーが 3 つセットで追加され、さらに多くのパーティションを作成できますが、新しいブローカーがトラフィックを処理するにはパーティションを再割り当てする必要があります。 エクスプレスブローカーの主な利点は、数分以内にブローカーを追加してパーティションを再調整できることです。一方、標準ブローカーを追加した後のパーティションの再調整には数時間かかることがあります。以下のグラフは、クラスターに 3 つのエクスプレスブローカーを追加し、各新しいブローカーに 2000 個のパーティションを再割り当てした後に、パーティションの再調整にかかった時間を示しています。 ご覧のように、これらのパーティションを再割り当てして新しいブローカーの追加容量を活用するのに約 10 分かかりました。標準ブローカーで構成される同等のクラスターで同じ実験を行ったところ、パーティションの再割り当てには 24 時間以上かかりました。 パーティションの再割り当ての詳細については、Apache Kafka ドキュメントの「 クラスターの拡張 」を参照してください。 知っておくべきこと エクスプレスブローカーについて知っておくべきことは次のとおりです。 データ移行 – Amazon MSK Replicator を使用して、既存の Kafka または MSK クラスターのデータをエクスプレスブローカーで構成されるクラスターに移行できます。これにより、クラスターのデータとメタデータの両方が新しいクラスターにコピーされます。 モニタリング – クラスター内のエクスプレスブローカーで構成されるクラスターを Amazon CloudWatch メトリクスを使用してブローカーレベルでモニタリングできます。また、Prometheus によるオープンモニタリングを有効にして、JMX エクスポーターとノードエクスポーターを使用してメトリクスを公開できます。 セキュリティ – 他のブローカータイプと同様に、Amazon MSK は AWS Key Management Service (AWS KMS) と統合して、エクスプレスブローカーのストレージを透過的にサーバー側で暗号化します。エクスプレスブローカーを使用して MSK クラスターを作成するときに、Amazon MSK が保管中のデータの暗号化に使用する AWS KMS キーを指定できます。KMS キーを指定しない場合、Amazon MSK が AWS マネージドキーを作成し、ユーザーに代わって使用します。 今すぐご利用いただけます エクスプレスブローカータイプは、11 月 7 日より米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の各リージョンでご利用いただけます。 エクスプレスブローカーの Apache Kafka ブローカーインスタンスの使用に対して時間単位の料金 (1 秒単位で請求) が発生します。手数料は、MSK クラスター内のブローカーインスタンスとアクティブなブローカーの規模によって異なります。また、エクスプレスブローカーに書き込まれるデータの GB 単位の料金 (バイト単位の解像度で請求) もお支払いいただきます。詳細については、「 Amazon MSK の料金 」ページにアクセスしてください。 Amazon MSK コンソール で Amazon MSK のエクスプレスブローカーをお試しください。詳細については、 Amazon MSK デベロッパーガイド をご覧ください。また、 AWS re:Post for Amazon MSK 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

(本記事は 2024/11/06 に投稿された How チャネルコーポレーション modernized their architecture with Amazon DynamoDB, Part 2: Streams を翻訳した記事です。) この記事は、チャネルコーポレーションの TaeHun Yoon と Changsoon Kim と共同で執筆されました。 チャネルコーポレーション は、 B2B ソフトウェア・アズ・ア・サービス（ SaaS ）スタートアップ企業で、オールインワン AI メッセンジャー「 チャネルトーク 」を運営しています。このシリーズの 第1部 では、 NoSQL 採用の動機、ビジネス成長に伴う技術的問題、そして PostgreSQL から Amazon DynamoDB への移行に関する考慮事項について紹介しました。この投稿では、 DynamoDB だけでは対処できなかった部分を解決するために、他のサービスと統合した経験を共有します。 背景：構造化データと非構造化データの取得問題 リレーショナルデータ設計と NoSQL にはいくつかの重要な違いがあります。 DynamoDB は、定義されたアクセスパターンに対する効率的なデータ取得に優れ、特定のクエリタイプに最適化されたパフォーマンスを提供します。この特徴により、次の チャネルコーポレーション のユースケースは DynamoDB だけでは解決が困難な状況でした。 様々なフィルタリング条件による構造化データの検索（メッセージ検索） – チャネルトーク はユーザーが会話を素早く検索できるようにします。ユーザーは、アサイン先、チーム、フォロワーなどの様々なフィルターを追加して検索することができる必要があります。次のスクリーンショットにその例を示します。 構造化されていないデータの検索（顧客データ検索） – 顧客データは、 チャネルコーポレーション の顧客が入力する情報に応じて異なるスキーマを持ちます。このスキーマは固定されておらず、執筆時点では、複数のフィールドを使用して最大 100 万件の顧客データレコードを迅速に検索できる必要があります。 チャネルコーポレーション は、これら 2 つの問題を解決するために DynamoDB と Amazon OpenSearch Service などの目的別検索サービスを使用する方が効果的で効率的であると判断しました。これを行うには、 DynamoDB と他のサービス間のデータ同期が必要です。 DynamoDB は Amazon OpenSearch Service とのゼロ ETL 統合を持っていますが 、 チャネルコーポレーション は現在、以下の理由で自己管理の ETL パイプラインを使用しています。 検索可能なデータに必要な最小限の情報のみを転送する必要がありました。また、特定の属性の値の変更を無視し、既存の値と現在の値の間の変更を比較する必要がありました 検索サービスで冪等性を確保するため、直接削除するのではなく、論理削除でレコードを変更および挿入する必要な場合がありました DynamoDB とのストリームインテグレーション 時系列に並んだ一連のイベントを ストリーム と呼びます。DynamoDB は、ストリームとして 変更データキャプチャ (CDC) を実行する 2 つの方法を提供します。 Amazon DynamoDB Streams は、DynamoDB テーブル内のアイテムレベルの変更の時系列順のシーケンスをキャプチャし、この情報を最大 24 時間ログに保存します。 Amazon Kinesis Data Streams は、DynamoDB テーブル内のアイテムレベルの変更をキャプチャし、それらを Kinesis データストリームに複製します。 チャネルコーポレーション は、これらのサービスを使用して、DynamoDB の変更データをストリームを介して検索性能の高いサービスに渡すことで、メッセージおよび顧客データ検索の問題を解決できました。 次の図は、DynamoDB Streams を使用したワークフローを示しています。 このソリューションは次の特性を提供します。 DynamoDB Streams からの読み取りは、 AWS Lambda ベースの消費者にとって無料です。 重複が削除された、時系列順のアイテムレベルの変更シーケンスを提供します。 しかし、次の点を考慮する必要があります： Lambda での障害やストリーム処理層での障害を処理する必要があります。 開始位置が LATEST に設定されている場合、 イベントを見逃す可能性 があります。 次の図は、 Kinesis Data Streams を使用したワークフローを示しています。 このソリューションは次の特性を提供します： Kinesis Data Streams と Lambda の両方のコストを含みます 最大 1 年間 のデータ保持期間を設定できます 5 つの開始位置オプション を提供します しかし、次の点を考慮する必要があります： Lambda やストリーム処理層での障害を処理する必要があります 開始位置が LATEST に設定されている場合、イベントを見逃す可能性があります 逆のイベントや重複したイベントが発生する可能性があります これをより詳細に理解するために、データが DynamoDB から各ストリームに渡される方法と、Lambda がストリーム上でどのように操作を実行するかを見てみましょう。 DynamoDB Streams DynamoDB は、各パーティション内の各アイテムに対して行われた変更を対応するシャードに送信し、変更が行われた順序を維持します。このプロセスは、特定のキーが最大 1 つのシャードに存在し、その順序が維持されることを保証にします。 Kinesis Data Streams Kinesis Data Streams のデータレコードは、アイテムの変更が発生したときとは異なる順序で表示される場合があり、同じアイテムの通知がストリームに複数回表示される場合があります。アイテムの変更が発生した順序を識別し、重複したレコードを識別するために、 ApproximateCreationDateTime 属性を確認することができます。 Lambda がストリーム上で処理を実行する方法 イベントソースマッピング は、ストリームおよびキューに基づくサービスからアイテムを読み取り、レコードのバッチで関数を呼び出す Lambda リソースです。イベントソースマッピングを使用して、 Lambda 関数を直接呼び出さないサービスのストリームまたはキューからのイベントを処理できます。 Lambda は DynamoDB Streams から直接呼び出されるのではなく、そのリソースを介して呼び出されることを理解して、各ソリューションと問題の特性に再度アプローチしましょう。 イベントソースマッピング構成の MaximumRecordAgeInSeconds および MaximumRetryAttempts 値を設定することで、基本的な再試行処理を処理できます。ただし、 Lambda コードのバグやデプロイ時の問題など、再試行のみでは解決できない障害が発生する可能性があります。 イベントソースマッピングリソース を参照すると、処理できなかったレコードに関する通知を Amazon Simple Queue Service （Amazon SQS） キューまたは Amazon Simple Notification Service （Amazon SNS） トピックに転送するための On-failure destination 設定を構成できます。次の例は、 DynamoDB ストリームの呼び出しレコードを示しています。 { "requestContext": { "requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81", "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction", "condition": "RetryAttemptsExhausted", "approximateInvokeCount": 1 }, "responseContext": { "statusCode": 200, "executedVersion": "$LATEST", "functionError": "Unhandled" }, "version": "1.0", "timestamp": "2019-11-14T00:13:49.717Z", "DDBStreamBatchInfo": { "shardId": "shardId-00000001573689847184-864758bb", "startSequenceNumber": "800000000003126276362", "endSequenceNumber": "800000000003126276362", "approximateArrivalOfFirstRecord": "2019-11-14T00:13:19Z", "approximateArrivalOfLastRecord": "2019-11-14T00:13:19Z", "batchSize": 1, "streamArn": "arn:aws:dynamodb:us-east-2:123456789012:table/mytable/stream/2019-11-14T00:04:06.388" } } 前述の情報に基づき、 DynamoDB Streams からレコードを取得して再試行する必要があります。DynamoDB Streams からレコードを取得して処理する際、すべてのイベントが時系列順に配信されるわけではないため、イベントの順序が乱れる可能性があります。 BatchSize が 1 を超え、一時的な障害により一部のアイテムの処理に失敗した場合、 Lambda は以前に処理されたレコードを含むバッチ全体を再試行します。適切に処理しないと、これにより重複イベントが発生する可能性があります。 さらに、イベントソースマッピングの開始位置が LATEST に設定されている場合、一部のイベントが見逃される可能性があります。 イベントソースマッピング に設定された MaximumRetryAttempts や MaximumRecordAgeInSeconds のような値は、初期設定と異なり、エラー処理や状況に応じて変更する必要があることがあります。この場合、一部のレコードが意図せず見逃される可能性があります。 この問題を解決するために開始位置を TRIM_HORIZON に変更すると、 DynamoDB Streams 内のすべてのデータが最初からイベントコンシューマーに配信され、イベントの重複処理が発生する可能性があります。 DynamoDB Streams と Kinesis Data Streams による問題解決 DynamoDB Streams と Kinesis Data Streams が同様の問題を解決する能力があると信じています。この記事では、次のユースケースについて説明します： すべてのストリーム処理関数を 冪等 に書くことは可能でしょうか？ Lambda 関数で問題が発生したときに再試行することはできますか？ 冪等性 ストリーム処理において最も重要なことの 1 つは、ロジックを冪等に設計することです。受信したイベントを検証し、以前に処理されたかどうかを判断する必要があります。イベントコンシューマーを冪等に書くことで、多くの問題を解決することができます。 例えば、ストリーム内のイベントが乱れた順序で表示される状況を見てみましょう。 前述の図に示すように、イベントの処理順序が不適切なためにデータ整合性が失われる可能性があります。 これを解決するためには、作成、更新、および削除操作で発生するすべてのイベントが時系列順に実行される場合、各状態は同じ最終状態になるため問題はありません。 言い換えれば、現在の最終状態が最新のイベントの結果である場合、前述の問題は簡単に解決できます。 これを実行するために、時刻を表すタイムスタンプが大きい場合にのみ更新が実行されるように実装を再設計しましょう。これにより、現在の状態以降のイベントのみが実行されます。 この場合、順序が乱れた配信が発生しましたが、これは現在の状態ではなく過去のイベントであるため、実行されず、同じ結果値を取得できます。DynamoDB は バージョン番号を使用した楽観的ロック を許可し、アイテムが更新されるたびにバージョン番号が自動的に増加します。更新または削除リクエストは、クライアント側のオブジェクトバージョンが DynamoDB テーブルの対応するアイテムバージョン番号と一致する場合にのみ可能です。この特性を利用すれば、問題を解決できます。 前と同じロジックを実行する場合、作成および更新操作には問題ありませんが、削除に関して問題になるケースがあります。 削除の場合でも、サービス内のレコードに対してハード削除ではなくソフト削除を使用して、イベントの発生順序を強制することで問題を解決できます。たとえば、A が削除され、その削除時刻に関する情報がある場合、その情報を使用してイベントを無視することができます。 障害発生時のリトライ戦略 すべてのロジックが冪等に書かれていることを前提に、問題が発生したときにリトライできるかどうかについて話しましょう。 Kinesis Data Streams と DynamoDB Streams の両方で、 On-failure destination オプションを使用して、過去のデータをストリーム消費者に再配信することができます。しかし、二つのストリームの戦略は異なる場合があります： DynamoDB Streams – DynamoDB Streams は、 イベントソースマッピングの開始位置 に LATEST および TRIM_HORIZON を提供します。特定の時点から再度レコードを取得するには、特定のシャード内の特定のシーケンス番号から目的の時点まで読み取りおよび再処理する別のアプリケーションが存在する必要があります。 Kinesis Data Streams – Kinesis Data Streams は、 イベントソースマッピングの開始位置 に AT_TIMESTAMP を含む 5 つのオプションを提供します。この機能を使用すると、問題が発生する直前のポイントに戻り、イベントソースマッピングのみを更新して再デプロイすることで問題を解決できます。 チャネルコーポレーション の選択 DynamoDB が提供する 2 つのストリームを使用して他のサービスとデータを同期する際に発生する可能性のあるケースについて検討しました。運用上の考慮事項やコストの観点から、特定のストリームを無条件に使用する方が良いとは言い難いです。したがって、 チャネルコーポレーション は特定の基準に基づいて両方のストリームを使用します。 次のユースケースでは、DynamoDB Streams を使用します。 イベントが時系列順に発生することが重要な場合 問題が発生したときにエラー回復コストが高くても良い場合 次のユースケースでは、 Kinesis Data Streams を使用します。 問題が発生したときに特定の時点から迅速に回復することが重要な場合 2 つ以上の Lambda 関数が同時にストリームを処理する必要がある場合 DynamoDB Streams を使用したオンラインスキーマ変更戦略 ストリームの使用のもう 1 つの例として、 チャネルコーポレーション は DynamoDB Streams を使用してオンラインスキーマ変更を実行します。同じアプローチは異なる AWS アカウント間の移行にも使用できます。次の図は、ワークフローを示しています。 このワークフローには次のステップが含まれています。 最初のステップは二つのパートで構成されています DynamoDB に新しいスキーマを持つ新しいテーブルを作成します。 古いテーブルの DynamoDB Streams イベントを消費して新しいテーブルスキーマに変換する Lambda 関数をデプロイします。 Lambda 関数がデプロイされる前の履歴データを読み込み、新しいスキーマに適用します 新しい API サーバーをデプロイします このプロセスにより、スキーマ変更が大幅に行われる場合でも、ライブスキーマ変更を実行できます。ステップ2では、 Amazon EMR 、 AWS Glue 、またはカスタムアプリケーションなど、さまざまな方法で新しいテーブルにデータを入力できます。 特定の時点から新しい DynamoDB テーブルにデータを挿入する必要がある場合、冪等性のために多くのことに注意する必要があります。これを簡素化するために、チャネルコーポレーション は前述の図のようにパイプラインを作成し、既存のすべてのアイテムのバージョンを 1 つ上げます。この場合、変更されたすべてのアイテムが DynamoDB Streams に移動し、Lambda がそれらを新しいスキーマに処理できるため、大きな懸念なしにデータを新しいテーブルに転送できます。 結論 DynamoDB を使用すると、スケーリングがほぼ無限であり、さまざまなダウンストリームサービスとの依存関係が排除されます。 チャネルコーポレーション にとって、 DynamoDB と Kinesis Data Streams の組み合わせは、アプリケーション展開のための堅牢なソリューションを提供します。この組み合わせにより、デプロイメント中に問題が発生した場合でも、特定の時点から迅速に回復できます。その結果、開発者は信頼できるフォールバックメカニズムがあることを知って、いつでも自信を持ってデプロイメントを実行できます。最後に、 DynamoDB のストリーミングオプションのいずれかを活用して、レガシーテーブルを削除し、テーブルを効率的に管理するオンラインスキーマ変更戦略を実装できます。 同様のソリューションを自分のユースケースに実装することを検討し、質問があればコメントセクションに残してください。 著者について TaeHun (Clsan) Yoon は コンピュータエンジニアリングの分野で経験豊富なプロフェッショナルである Channel Corp の最高技術責任者（ CTO ）として革新的なソリューションを牽引しています。チャット体験の向上に注力し、 TaeHun と彼のチームは顧客が直面するさまざまな課題の解決に尽力しています。 Changsoon (CS) Kim は、 Channel Corp の DevOps エンジニアです。開発と運用の間の問題を効率的に解決することに関心を持っています。 Sungbae Park は、 AWS スタートアップチームのアカウントマネージャーであり、 AWS SaaS TFC （Technical Field Communities）のレギュラーメンバーです。現在、 B2B ソフトウェアスタートアップが AWS で成長し成功するのを支援することに注力しています。以前は、 MSP 、 SI 、 ISV パートナーと共に相互成長を促進するパートナーデベロップメントマネージャーとして働いていました。 Hyuk Lee は、韓国に拠点を置くシニア DynamoDB スペシャリストソリューションアーキテクトです。彼は Amazon DynamoDB の機能を使用して顧客のアーキテクチャをモダナイゼーションするのを支援することが大好きです。

こんにちは、プロトタイピング ソリューション アーキテクトの市川です。 2024 年 10 月 30 日に開催された 「IoT@Loft #25 進化する IoT カメラソリューション – 生成 AI で拓く新時代」の内容について紹介させていただきます。 今回の IoT@Loft では i-PRO 株式会社と株式会社 USEN のお客様セッションだけではなく、短い時間ですがデモの展示も行いました。受付後から開始までの時間や、セッション後のネットワーキングの時間をより有意義にできるように初めて取り組みましたが、想像していたよりもデモ展示に興味を持っていただくことができ、大変盛り上がっておりました。 IoT@Loft とは ? 過去の開催ブログ IoT 関連ビジネスで開発を担当するデベロッパーのためのイベントです。IoT の分野は、「総合格闘技」と呼ばれるほど、必要な技術分野が非常に多岐に渡ること、ビジネスモデルが複雑なケースが多いことから、全体を理解することは難しいと言われています。IoT@Loft は、IoT 特有の課題に取り組み、参加者同士の情報共有と意見交換の場を提供することで、参加者の事業や製品開発の成功につながるきっかけを作ることを目指しています。 IoT@Loft #25 では IoT の発展により、カメラやセンサーデバイスが社会のさまざまなシーンで活用され、リアルタイムの映像や各種データを収集できるようになっていることから、データを効果的に活用するため、従来の画像認識や物体検出に加え、生成AIの技術と組み合わせた新たな可能性についてお客様から紹介いただきました。 お客様登壇 生成 AI/IoT ネイティブなカメラを目指して 登壇資料 1 つ目のセッションは i-PRO 株式会社 高橋様と荒井様より、「生成 AI/IoT ネイティブなカメラを目指して」という内容でご登壇いただきました。 i-PRO 株式会社では moduca シリーズ という AI/IoT ネイティブカメラを提供しています。moduca は光学モジュール、 SoC モジュール、インターフェイスモジュールの 3 つを組み合わせることで、用途に適したカメラを作ることができます。現在提供されているモジュールを組み合わせると 1500 通り以上の組み合わせが実現でき、ご自身が必要な機能を持ったカメラを作ることができます。 Linux ベースの OS が動くハードウエアが提供されているため、独自のアプリケーションを開発することで、オリジナルのカメラソリューションとして利用することも可能です。もちろん AWS の SDK を利用することもでき Amazon Kinesis Video Streams にも対応しています。 i-PRO 株式会社ではこのカメラに機械学習のモデルを搭載してエッジ AI アプリケーションを構築することができますが、この機械学習のモデルは何かしら特定の用途のモデルを作成する必要があるため、それなりに開発コストが掛かってしまうことは課題として感じられていたとのことです。 今回のイベントに向けて生成 AI を利用したデモを作成されたとのことですが、カメラで検出した後に、生成AIを利用してカメラに映ったものを判断するデモの作成はわずか 1 週間で完成したそうです。 このデモではビブスを着用しているかの判断を行っていましたが、このように特定なものを判断できる機械学習のモデルを作ろうとすると、それなりの画像が必要となり、精度を上げるための調整にも時間がかかりますが、人物を判定できる AI モデルをカメラで動かし、人を見つけたときだけクラウドに送信し Amazon Bedrock で判断させると、簡単に実現することができたそうです。このように生成 AI を使った新規事業へのアイディアも紹介していただきましたので、ぜひ資料をご覧いただければと思います。 IoT×AI カメラソリューションが拓く店舗 DX の近未来 登壇資料 2 つ目のセッションは、株式会社 USEN の 野村様より、「IoT×AI カメラソリューションが拓く店舗 DX の近未来」という内容でご登壇いただきました。株式会社 USEN と聞いて最初に思い浮かぶのは、お店に流れている音楽のソリューションではないかと思いますが、実際には店舗で必要とされる様々な仕組み( USEN の店舗 DX )をほとんど提供しています。 これらのサービスの中で、カメラを活用した来客の分析などを行なっているのが USEN Camera ですが、映像をクラウドに保存しつつリアルタイムで再生する必要があるが、映像やカメラ操作の遅延が発生することがお客様からのフィードバックとしてありました。 この課題は Amazon Kinesis Video Streams だけではなく他のカメラサービスでも同様の課題を抱えていますが Amazon Kinesis Video Streams WebRTC with Ingestion を使うことで、低遅延化することができそうであることがわかり、実装して見たところ遅延を 1 秒以内に抑えることが確認できたそうです。 この話以外にも現在取り組んでいる仕組みについての話もありましたが、現地の参加者限定での共有でしたので残念ながらご紹介することはできませんが、 株式会社 USEN のサイト に今後登場すると思われます。 AWSセッション 3 つ目のセッションでは、ソリューションアーキテクトの 井上 昌幸 / 宇佐美 雅紀 の 2 名から発表がありました。 登壇資料前半 登壇資料後半 前半は SA の井上より「Amazon Kinesis Video Streams – アップデートとエッジで役立つ構成パターン」と題して Amazon Kinesis Video Streams を紹介しました。 エッジ構成のパターンでは、どのようにデバイスと Amazon Kinesis Video StreamsのStreams を組み合わせると良いのか、それぞれのメリット・デメリットについて話がありました。アップデートでは WebRTC で マルチビューアーのプレビュー が公開されている話があり Ingestion (クラウドへの保存)と組み合わせることで複数のビューアーにリアルタイムで接続しながら、動画を保存することが可能になるとのことでした。 後半は SA の宇佐美より 5 月に開催された AWS Summit Japan で展示されたカメラ＋生成 AI のデモについての紹介がされました。 AWS Summit Japan では多くのデモが展示されており、今回はカメラと生成AIが直接関係するデモのみを紹介しました。この条件を外してデモ全体で見ると、実は裏側で IoT サービスを活用しているものも多く IoT を活用するのは一般化されているなという印象です。紹介いただいたデモは別途ブログでも公開しております。 AWS Summit 2024 で見た IoT の進化！多数のセッションと展示が語る IoT の真価と深化！ ( Industrial IoT 編 ) AWS Summit 2024 で見た IoT の進化！多数のセッションと展示が語る IoT の真価と深化！（ IoT プロダクト編） Raspberry Pi と Web カメラ、生成 AI を使ってショート動画とベストショットを撮影できるカメラスポットを作ってみた！ デモの展示 i-Pro 株式会社 i-PRO 株式会社のデモはセッション内で紹介されていた Amazon Bedrock を利用した検出と通知について紹介されていました。開発したデモだけではなく、複数種類のカメラモジュールも展示されており、非常に小さいことに驚きました。カメラモジュールは Amazon Kinesis Video Streams の認定を獲得しており、 AWS の認定デバイスカタログ にも掲載されております。最後まで多くの人が訪れ、大変賑わっていました。 AWS のデモ Video semantic search using GenAI のデモでは PC のカメラから Amazon Kinesis Video Streams に映像を送信し AWS Lambda がその映像を取り出して Amazon Bedrock でタグ付けを行いその情報を保存します。Web の UI からは文章を入力するとその文章に合致する画像を表示することができ、大量の映像データから欲しいデータを探すユースケースで活用できるデモとなっていました。 生成 AI によるカメラ映像から危険判別 のデモは、監視カメラ映像をと生成 AI を組み合わせて作業員の安全確保を予防・対応両面から支援する 2 つのシナリオをご紹介ています。1 つはカメラ映像と生成 AI を使用して従業員の危険な状況を生成 AI が記述し、状況に応じて警告を出します。もう 1 つは作業員の安全装具の装着状況をカメラ映像から分析してレポートします。このデモは AWS Summit Japan でも展示されており、 詳細な情報はこちらから見ることもできます 。 さいごに IoT のユースケースで少しずつ生成 AI の話も出てきていますが、まだまだ手探りな状況かなと思います。今回のようにすでに試したり、考えられているお客様の話を聞いていると、今後が非常に楽しみな組み合わせと思いました。 IoT@Loft に関しては、今回はセッションと合わせてデモを展示する取り組みを行いました。イベント開始前の時間が有効に使えたり、ネットワーキングの時間では、より具体的なディスカッションが行えているように見えており、アンケートの結果も評価が高かったです。オフラインの開催は現地に行く必要があるのが大変ではありますが、オンラインと違ってより深いコミュニケーションが取れるのが登壇者、参加者どちらにとっても大きなメリットとなっていると思います。次回は来年になると思いますが、より有意義な場となるように改善を続けたいと思います。 関連ウェブサイトのご紹介 AWS IoT 開発者ポータル IoT エンジニア向けに、IoT 関連の国内の事例やセミナーの情報、ハンズオンや学習のためのデジタルコンテンツなどを随時更新しています。ぜひ定期的にチェックしてみてください。 https://aws.amazon.com/jp/local/iot/ 著者について 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。

(本記事は 2024/11/06 に投稿された How チャネルコーポレーション modernized their architecture with Amazon DynamoDB, Part 1: Motivation and approaches を翻訳した記事です。) チャネルコーポレーション は、オールインワン AI メッセンジャー「チャネルトーク」を運営する B2B ソフトウェア・アズ・ア・サービス（ SaaS ）スタートアップです。「顧客と企業の間にあるすべての問題を解決する」というビジョンを掲げ、その第一弾として、顧客と企業間のコミュニケーション問題を解決するためにチャネルトークを開発しました。チャネルトークは、Live チャット相談、チャットボット、音声通話、顧客関係管理 (CRM) 、社内メッセンジャーを統合したソリューションであり、企業と顧客のコミュニケーションを支援しています。韓国、日本、米国を含む 22 カ国で 15 万社以上の企業に利用されており、毎月 7,000 万件以上のコールを処理しています。 この二部構成のブログシリーズは、 RDBMS から NoSQL への移行の動機と考慮事項を提示することから始まります。 第2部 では、 チャネルコーポレーション がストリームを使用して event-driven アーキテクチャを実装する方法について説明します。 この記事では、 チャネルコーポレーション が Amazon DynamoDB を使用してアーキテクチャをモダナイゼーションする動機、 DynamoDB を選択した理由、および Amazon Relational Database Service (Amazon RDS) for PostgreSQL からの移行前に考慮すべき4つの主要なポイントについて説明します。 背景：ビジネス成長と新たな問題の出現 チャネルトーク は当初、チームチャットとユーザーチャットの 2 つのコンポーネントに分かれていました。次のスクリーンショットに示されているチームチャット機能は、チーム内のコミュニケーションをサポートします。 次のスクリーンショットに示されているユーザーチャット機能は、顧客と企業の間のコミュニケーションを助けます。 2018 年以降、ビジネスが毎年 2〜5 倍に成長するにつれて、チャットサービスの1秒あたりのリクエスト数 (RPS) も急速に増加し始めました。以前は Amazon RDS for PostgreSQL を使用してチャットサービスを運用していたため、より高いパフォーマンスが必要な場合はインスタンスタイプをスケールアップしていました。 しかし、キャンペーンメッセージや一度きりのメッセージを送信するマーケティングサービスを開始してから、スケールアップ戦略を変更する必要がありました。キャンペーンメッセージは、顧客が特定のアクションを実行したときにルールに基づいて自動的にメッセージを送信する機能です。例えば、顧客がサインアップしたときにウェルカムメッセージを送信したり、価格ページを閲覧したときに割引クーポンを送信したりします。一度きりのメッセージは、特定の時間にターゲット顧客に一度だけメッセージを送信する機能です。たとえば、現在オンラインの顧客に限定割引クーポンを発行するために使用できます。 今までの チャネルトーク の主なワークロードはチャットベースの 1 対 1 のカスタマーコンサルテーションであったため、ピークトラフィックを予測することは難しくありませんでした。しかし、マーケティングサービスは、顧客がセールイベントを実行したり、多数の顧客に一度きりのメッセージを送信したりすると、複数のテーブルで瞬時に大量のトラフィックスパイクを引き起こすと予想されました。その結果、 チャネルコーポレーション は新しいスケーラブルなデータベースを必要とし、次の 4 つの主要な考慮事項がありました。 コスト効率の悪さ – インスタンスベースのサービスはピークに基づいてインスタンスサイズを選択する必要があり、マーケティングサービスは高い変動性を追加すると予想されました テーブル間の負荷の波及 – 特定のテーブルやサービスの高負荷が RDS インスタンス全体のパフォーマンスに影響を与える可能性があります PostgreSQL で行っていた既存の操作を効率的に実行するためのサポート 要件と許容ダウンタイムに合わせた移行戦略の準備 DynamoDB を選択した理由 上記で記述した 4 つの問題を解決することに加えて、 チャネルコーポレーション は次の 3 つの主要な理由から DynamoDB を選択しました。 他の AWS サービスに event sourcing を実装できる能力、一般的なイベント駆動型アーキテクチャパターン 他の AWS サービスとの豊富なインテグレーション ACID トランザクション 4 つの問題を解決するためのアプローチ マーケティングサービスに関連する最初と第二の問題は、 DynamoDB を選択することで簡単に解決できました。 DynamoDB がオンデマンドキャパシティモードを提供していたため、コスト効率の問題にを柔軟に対応できました。このモードは、以前のピークトラフィックの最大 2 倍まで即座に対応でき、30 分以内に以前のピークの 2 倍を超えない限り対応可能です。また、必要に応じてテーブルを事前にウォームアップすることもできます。さらに、プロビジョンド容量モードでは DynamoDB auto scaling を提供し、安定したワークロードを運用し、過度な利用を防ぐための上限を設定することができました。以下の 2 つの図は、 DynamoDB の user_chat および message テーブルで一度に大量のメッセージが生成される際の書き込みトラフィックパターンを示しています。 第二の問題であるテーブル間の負荷の波及は、 DynamoDB では 1 つのテーブルの負荷が他のテーブルに影響を与えないため、迅速に解決できました。そのため、柔軟なトラフィックを処理しながら、全体のサービスを安定的に運営するためのアーキテクチャを改善することができました。 第三の問題に対処するために、既存の PostgreSQL 操作を DynamoDB で置き換えることが可能かを確認するために、 チャネルトーク チャットの主要機能を検討しました。次のスクリーンショットはこのプロセスを示しています。 チャネルトーク チャットの主な機能は次のように抽象化されます Chat room (Chat) – チャットルームにはメッセージがあります。 Participation information (ChatSession) – 特定のチャットルームでの未読メッセージ数や最後の閲覧時間などの情報が記録されます。 Participation information における未読メッセージ数は ChatBadge と呼ばれます。特定のユーザーが同時に複数のチャットルームに所属することができるため、複数のチャットルームの未読メッセージの合計数は ManagerBadge と呼ばれます。 これらのコンポーネントには別々に動作する 2 つの要件があります： 原子性 – 各チャットルームでメッセージが発生する際、送信者以外の受信者に対して ChatBadge がアトミックに増加します。 カウント – 各チャットルームで発生したすべての ChatBadge の合計が ManagerBadge になります。 以前は PostgreSQL を使用していたため、 ChatBadge はアトミック操作を使用し、 ManagerBadge は単に ChatBadge の合計でした。しかし、ユーザーのチャットルーム数が増加するにつれて、各ユーザーメッセージを送信した後にレコードのアドホックカウントを実行することはスケールが難しいため、パフォーマンスが時間とともに低下する可能性があります。この問題を解決するために、 DynamoDB トランザクション を使用することに決定しました。次のスクリーンショットはテーブル設計変更前の属性を示しています。 次のスクリーンショットは、テーブル設計変更後の属性を示しています。 特定のチャットルームでメッセージが作成されると、送信者を除く各参加者に対して次の操作が実行されます： 参加者の ChatBadge を増加させる UpdateItem を作成します。 参加者の ManagerBadge を増加させる UpdateItem を作成します。 TransactWriteItems API を使用して 2 つの UpdateItem 操作を処理します。 この方法により、 ChatBadge の合計が ManagerBadge となることを保証でき、それぞれを O(1) の時間複雑度でクエリすることができます。もちろん、このアプローチはメッセージが同時に継続的に生成される状況で トランザクションの競合 を引き起こす可能性がありますが、 チャネルトーク の大部分のワークロードがカスタマーコンサルテーションのための 1 対 1 の会話であるため、同時メッセージが発生するケースはあまりありません。さらに、大量のメッセージが同時に発生する場合には、それらを処理する手順があります。 次の図に示すように、競合が発生した場合、 exponential backoff 再試行戦略 を使用します。また、 DynamoDB トランザクションは ClientRequestToken パラメータを使用するときに冪等性をサポートしているため、接続タイムアウトなどの問題で同じ要求が複数回送信された場合でも、 10 分以内に ChatBadge と ManagerBadge を正確に管理することができ、これにより第三の問題が解決されました。 最後に、移行は早朝に API サーバーを停止して行われました。 DynamoDB の 並列スキャン のセグメント化アイデアを参考し、 PostgreSQL ID をハッシュ、各セグメントごとに複数のスレッドを使用して BatchWriteItem API を並列で使用して移行しました。 結論 DynamoDB は、ほぼ無制限のスループットとストレージ、スキーマの柔軟性、event-driven アーキテクチャを可能にする DynamoDB Streams 、および複数のテーブルに対する ACID トランザクションを提供します。 DynamoDB を採用して以来、 チャネルトーク はチャットビジネスエリアで大規模なインフラ変更を行わずに継続的に新しい機能を追加しながらビジネスを運営してきました。DynamoDB を使用することで次のような主要な利点を得ました。 インフラストラクチャやコード構造を改善することなく、新しい機能を継続的に追加することができました。たとえば、ルールに基づいてメッセージを生成するボットの機能など、メッセージの数を急速に増加させる機能がリリースされた場合でも、インフラストラクチャの問題なくサービスを運営することができました。 インスタンスコストなしで使用量に応じてのみ支払う DynamoDB のコストモデルにより、以前は固定費だったデータベースコストを変動費に変えることが容易になりました。トラフィックが減少すると DynamoDB コストも減少するため、ビジネス状況が良くない場合でもコスト削減のためにアーキテクチャを変更する必要がなく、トラフィックが増加しても同様です。 ビジネスエリアが継続的に拡大するにつれて、チャットに加えて チャネルトーク のすべての顧客の使用状況を測定するなど、水平スケーラビリティが必要な領域で DynamoDB を利用してさまざまな問題を解決しています。 シリーズの第 2 部では、 DynamoDB だけでは解決できなかった部分を他のサービスと統合して解決する方法について説明します。 著者について TaeHun (Clsan) Yoon は コンピュータエンジニアリングの分野で経験豊富なプロフェッショナルである Channel Corp の最高技術責任者（ CTO ）として革新的なソリューションを牽引しています。チャット体験の向上に注力し、 TaeHun と彼のチームは顧客が直面するさまざまな課題の解決に尽力しています。 Changsoon (CS) Kim は、 Channel Corp の DevOps エンジニアです。開発と運用の間の問題を効率的に解決することに関心を持っています。 Sungbae Park は、 AWS スタートアップチームのアカウントマネージャーであり、 AWS SaaS TFC （Technical Field Communities）のレギュラーメンバーです。現在、 B2B ソフトウェアスタートアップが AWS で成長し成功するのを支援することに注力しています。以前は、 MSP 、 SI 、 ISV パートナーと共に相互成長を促進するパートナーデベロップメントマネージャーとして働いていました。 Hyuk Lee は、韓国に拠点を置くシニア DynamoDB スペシャリストソリューションアーキテクトです。彼は Amazon DynamoDB の機能を使用して顧客のアーキテクチャをモダナイゼーションするのを支援することが大好きです。

この記事は、「 Implement model-independent safety measures with Amazon Bedrock Guardrails 」を翻訳したものとなります。 生成 AI モデルは幅広いトピックに関する情報を生成できますが、その応用には新たな課題があります。これには関連性の維持、有害なコンテンツの回避、個人を特定できる情報（PII）などの機密情報の保護、ハルシネーション（幻覚）の軽減が含まれます。 Amazon Bedrock の基盤モデル（FM）には組み込みの保護機能がありますが、これらはモデル固有であることが多く、組織のユースケースや責任ある AI の原則に完全に合致しない可能性があります。その結果、開発者は多くの場合、追加のカスタマイズされた安全性とプライバシーの制御を実装する必要があります。このニーズは、組織が複数の FM を異なるユースケースで使用する場合により顕著になります。なぜなら、一貫したセーフガードを維持することが、開発サイクルの加速と責任ある AI への統一されたアプローチの実装に不可欠だからです。 2024 年 4 月、私たちは Amazon Bedrock Guardrails の一般提供を発表しました。これはセーフガードの導入、有害なコンテンツの防止、主要な安全性基準に対するモデルの評価を支援するものです。Amazon Bedrock Guardrails を使用すると、ユースケースと責任ある AI ポリシーに合わせてカスタマイズされた生成 AI アプリケーションのセーフガードを実装できます。複数のユースケースに合わせて複数のガードレールを作成し、それらを複数の FM に適用することで、ユーザーエクスペリエンスを向上させ、生成 AI アプリケーション全体で安全性のコントロールを標準化できます。 さらに、異なる FM を使用するアプリケーションの保護を可能にするために、Amazon Bedrock Guardrails は現在、Amazon Bedrock 外で利用可能なカスタムおよびサードパーティの FM のユーザー入力とモデル応答を評価するための ApplyGuardrail API をサポートしています。この記事では、サードパーティまたはセルフホスト型の大規模言語モデル（LLM）、あるいはセルフホスト型の検索拡張生成（RAG）アーキテクチャなど、一般的な生成 AI アーキテクチャで ApplyGuardrail API を使用する方法について説明します。 ソリューションの概要 この記事では、FM が受託者向けのアドバイスを提供しないようにするガードレールを作成します。ガードレールの完全な設定リストは GitHub リポジトリ をご覧ください。必要に応じてコードを変更できます。 前提条件 Amazon Bedrock Guardrails を使用するための正しい AWS Identity and Access Management（IAM） 権限があることを確認してください。手順については、「 コンテンツフィルタリングにガードレールを使用するアクセス許可を設定する 」を参照してください。 さらに、このウォークスルーで使用するサードパーティまたはセルフホスト型の LLM へのアクセス権が必要です。この記事では、 Amazon SageMaker JumpStart の Meta Llama 3 モデルを使用します。詳細については、「 SageMaker プロジェクトと JumpStart の AWS 管理ポリシー 」を参照してください。 Amazon Bedrock コンソール、Infrastructure as Code（IaC）、または API を使用してガードレールを作成できます。ガードレールを作成するためのサンプルコードについては、 GitHub リポジトリ を参照してください。以下の例で使用するガードレール内に 2 つのフィルタリングポリシーを定義します：ユーザーに受託者アドバイスを提供しないように 拒否トピック と、ソース情報に基づいていないか、ユーザーのクエリに関連しないモデル応答をフィルタリングする コンテキストグラウンディングチェック です。ガードレールのさまざまなコンポーネントの詳細については、「 ガードレールのコンポーネント 」を参照してください。先に進む前にガードレールを作成したことを確認してください。 ApplyGuardrail API の使用 ApplyGuardrail API を使用すると、使用されるモデルに関係なくガードレールを呼び出すことができます。ガードレールは text パラメータに適用されます。以下のコードを参照してください： content = [ { "text": { "text": "Is the AB503 Product a better investment than the S&P 500?" } } ] この例では、ユーザーからの入力全体にガードレールを適用します。入力の特定の部分にのみガードレールを適用し、他の部分を未処理のままにしたい場合は、「 ユーザー入力にタグを適用してコンテンツをフィルタリングする 」を参照してください。 Amazon Bedrock Guardrails 内で コンテキストグラウンディングチェック を使用している場合は、追加のパラメータである qualifiers の導入が必要です。これにより、API にコンテンツのどの部分が grounding_source （根拠となる情報源として利用する情報）、 query （モデルに送信されるプロンプト）、および guard_content （グラウンドソースに対して検証するモデル応答の部分）であるかを伝えます。コンテキストグラウンディングチェックは出力にのみ適用され、入力には適用されません。以下のコードを参照してください： content = [ { "text": { "text": "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%", "qualifiers": ["grounding_source"], } }, { "text": { "text": "What’s the Guaranteed return rate of your AB503 Product", "qualifiers": ["query"], } }, { "text": { "text": "Our Guaranteed Rate is 7%", "qualifiers": ["guard_content"], } }, ] 最後に必要なコンポーネントは、使用するガードレールの guardrailIdentifier と guardrailVersion 、およびテキストがモデルへのプロンプトかモデルからの応答かを示す source です。これは以下のコードで Boto3 を使用して示されています。完全なコード例は GitHub リポジトリ で利用可能です： import boto3 import json bedrock_runtime = boto3.client('bedrock-runtime') # Specific guardrail ID and version guardrail_id = "" # Adjust with your Guardrail Info guardrail_version = "" # Adjust with your Guardrail Info content = [ { "text": { "text": "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%", "qualifiers": ["grounding_source"], } }, { "text": { "text": "What’s the Guaranteed return rate of your AB503 Product", "qualifiers": ["query"], } }, { "text": { "text": "Our Guaranteed Rate is 7%", "qualifiers": ["guard_content"], } }, ] # Call the ApplyGuardrail API try: response = bedrock_runtime.apply_guardrail( guardrailIdentifier=guardrail_id, guardrailVersion=guardrail_version, source='OUTPUT', # or 'INPUT' depending on your use case content=content ) # Process the response print("API Response:") print(json.dumps(response, indent=2)) # Check the action taken by the guardrail if response['action'] == 'GUARDRAIL_INTERVENED': print("\nGuardrail intervened. Output:") for output in response['outputs']: print(output['text']) else: print("\nGuardrail did not intervene.") except Exception as e: print(f"An error occurred: {str(e)}") print("\nAPI Response (if available):") try: print(json.dumps(response, indent=2)) except NameError: print("No response available due to early exception.") API の応答は以下の詳細を提供します： ガードレールが介入したかどうか ガードレールが介入した理由 リクエストに使用されたテキストユニット（Amazon Bedrock Guardrails の完全な価格詳細については、 Amazon Bedrock の料金を参照してください） 以下の応答は、拒否トピックによってガードレールが介入したことを示しています： "usage": { "topicPolicyUnits": 1, "contentPolicyUnits": 1, "wordPolicyUnits": 1, "sensitiveInformationPolicyUnits": 1, "sensitiveInformationPolicyFreeUnits": 0, "contextualGroundingPolicyUnits": 0 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "topicPolicy": { "topics": [ { "name": "Fiduciary Advice", "type": "DENY", "action": "BLOCKED" } ] } } ] } 以下の応答は、コンテキストグラウンディングチェックによってガードレールが介入したことを示しています： "usage": { "topicPolicyUnits": 1, "contentPolicyUnits": 1, "wordPolicyUnits": 1, "sensitiveInformationPolicyUnits": 1, "sensitiveInformationPolicyFreeUnits": 1, "contextualGroundingPolicyUnits": 1 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "contextualGroundingPolicy": { "filters": [ { "type": "GROUNDING", "threshold": 0.75, "score": 0.38, "action": "BLOCKED" }, { "type": "RELEVANCE", "threshold": 0.75, "score": 0.9, "action": "NONE" } ] } } ] } 最初のリクエストへの応答から、金融商品の推奨を求めたユーザーに受託者向けのアドバイスを提供しないようにガードレールが介入したことがわかります。2 番目のリクエストへの応答から、ガードレールが介入し、グラウンドソースの情報から逸脱したモデル応答における、保証利回りの幻想をフィルタリングできたことがわかります。両方のケースで、ガードレールは予想通りに介入し、特定のトピックを避け、ソースに基づいて事実に基づいたモデル応答をユーザーに提供することで、規制要件や社内ポリシーを潜在的に満たすようにしました。 セルフホスト型 LLM での ApplyGuardrail APIの使用 ApplyGuardrail API の一般的なユースケースは、サードパーティプロバイダーの LLM またはセルフホスト型モデルとの組み合わせです。この組み合わせにより、リクエストの入力または出力にガードレールを適用できます。 一般的なフローには以下のステップが含まれます： モデルの入力を受け取ります。 ApplyGuardrail API を使用して、この入力にガードレールを適用します。 入力がガードレールを通過した場合、推論のためにモデルに送信します。 モデルからの出力を受け取ります。 出力にガードレールを適用します。 出力がガードレールを通過した場合、最終出力を返します。 入力または出力のいずれかがガードレールによって介入された場合、入力または出力からの介入を示す、事前定義されたメッセージを返します。 このワークフローは以下の図で示されています。 ワークフローの実装を見るには、提供された コードのサンプル を参照してください。 私たちは Amazon SageMaker エンドポイントでホストされている Meta-Llama-3-8B モデルを使用します。SageMaker で独自のバージョンのこのモデルをデプロイするには、「 Meta Llama 3 models are now available in Amazon SageMaker JumpStart 」を参照してください。 私たちは、 ApplyGuardrail API を SageMaker エンドポイントと統合して保護されたテキスト生成を提供する TextGenerationWithGuardrails クラスを作成しました。このクラスには以下の主要なメソッドが含まれます： generate_text – 入力に基づいてテキストを生成するために、SageMaker エンドポイントを通じて LLM を呼び出します。 analyze_text – ApplyGuardrail API を使用してガードレールを適用するコアメソッドです。API 応答を解釈して、ガードレールを通過したか介入されたかを判断します。 analyze_prompt と analyze_output – これらのメソッドは analyze_text を使用して、入力プロンプトと生成された出力にそれぞれガードレールを適用します。ガードレールを通過したかどうかと関連するメッセージを含むタプルを返します。 クラスは前述の図のワークフローを実装します。以下のように機能します： analyze_prompt を使用して、入力プロンプトをチェックします。 入力がガードレールを通過した場合、 generate_text を使用してテキストを生成します。 生成されたテキストは analyze_output を使用してチェックされます。 両方のガードレールを通過した場合、生成されたテキストが返されます。そうでない場合は、介入メッセージが提供されます。 この構造により、テキスト生成の前後で包括的な安全性チェックが可能になり、ガードレールが介入した場合の明確な処理が可能です。より大規模なアプリケーションと統合するように設計されており、ガードレールの結果に基づいてエラー処理とカスタマイズの柔軟性を提供します。 以下の入力を提供してテストできます： query = "What is the Guaranteed Rate of Return for AB503 Product" grounding_source = "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%" デモンストレーションの目的で、今回は Meta Llama のプロンプトのベストプラクティスに従っていません。実際のシナリオでは、LLM をプロンプトする際にモデルプロバイダーのベストプラクティスに確実に従ってください。 モデルは以下のように応答します： Here is what the Model Responded with: ? The guaranteed rate of return for AB503 product is 4.25% per annum. This rate is guaranteed for the entire term of the investment, which is 5 years. The guaranteed rate of return is based on the performance of the underlying assets and is subject to the creditworthiness of the issuer. What are the Key Features of AB503 Product? The key features of AB503 product are: Guaranteed Rate of Return: 4.25% per annum for 5 years Minimum Investment: $1,000 Maximum Investment: $100,000 Maturity Date: 5 years from the date of investment Interest Payment Frequency: Annually Principal Protection: 100% of the principal amount is guaranteed Credit Risk: The product is issued by a reputable financial institution and is subject to credit risk Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions What are the Risks Associated with AB503 Product? The risks associated with AB503 product are: Credit Risk: The product is issued by a financial institution and is subject to credit risk. If the issuer defaults, you may lose some or all of your investment. Interest Rate Risk: The guaranteed rate of return is fixed and may not keep pace with inflation or changes in interest rates. Liquidity Risk: The product can be redeemed at the end of the term or earlier, subject to certain conditions. If you need to access your funds before the maturity date, you may not be able to do so or may have to sell your investment at a loss. Market Risk: The value of the underlying assets may fluctuate, which could affect the value of your investment. What are the Benefits of AB503 Product? The benefits of AB503 product are: Guaranteed Rate of Return: The product offers a guaranteed rate of return of 4.25% per annum for 5 years, which can provide a predictable income stream. Principal Protection: 100% of the principal amount is guaranteed, which means that you will not lose any of your initial investment. Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions, which can provide flexibility and access to your funds when needed. Diversification: The product can be used as a diversification tool to reduce the risk of your overall investment portfolio. What are the Eligibility Criteria for AB503 Product? The eligibility criteria for AB503 product are: Age: The product is available to individuals これは私たちの質問に対してハルシネーションを含む応答です。ワークフローの出力でこれが示されています。 === Input Analysis === Input Prompt Passed The Guardrail Check - Moving to Generate the Response === Text Generation === Here is what the Model Responded with: ? The guaranteed rate of return for AB503 product is 4.25% per annum. This rate is guaranteed for the entire term of the investment, which is 5 years. The guaranteed rate of return is based on the performance of the underlying assets and is subject to the creditworthiness of the issuer. What are the Key Features of AB503 Product? The key features of AB503 product are: Guaranteed Rate of Return: 4.25% per annum for 5 years Minimum Investment: $1,000 Maximum Investment: $100,000 Maturity Date: 5 years from the date of investment Interest Payment Frequency: Annually Principal Protection: 100% of the principal amount is guaranteed Credit Risk: The product is issued by a reputable financial institution and is subject to credit risk Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions What are the Risks Associated with AB503 Product? The risks associated with AB503 product are: Credit Risk: The product is issued by a financial institution and is subject to credit risk. If the issuer defaults, you may lose some or all of your investment. Interest Rate Risk: The guaranteed rate of return is fixed and may not keep pace with inflation or changes in interest rates. Liquidity Risk: The product can be redeemed at the end of the term or earlier, subject to certain conditions. If you need to access your funds before the maturity date, you may not be able to do so or may have to sell your investment at a loss. Market Risk: The value of the underlying assets may fluctuate, which could affect the value of your investment. What are the Benefits of AB503 Product? The benefits of AB503 product are: Guaranteed Rate of Return: The product offers a guaranteed rate of return of 4.25% per annum for 5 years, which can provide a predictable income stream. Principal Protection: 100% of the principal amount is guaranteed, which means that you will not lose any of your initial investment. Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions, which can provide flexibility and access to your funds when needed. Diversification: The product can be used as a diversification tool to reduce the risk of your overall investment portfolio. What are the Eligibility Criteria for AB503 Product? The eligibility criteria for AB503 product are: Age: The product is available to individuals === Output Analysis === Analyzing Model Response with the Response Guardrail Output Guardrail Intervened. The response to the User is: I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. Full API Response: { "ResponseMetadata": { "RequestId": "6bfb900f-e60c-4861-87b4-bb555bbe3d9e", "HTTPStatusCode": 200, "HTTPHeaders": { "date": "Mon, 29 Jul 2024 17:37:01 GMT", "content-type": "application/json", "content-length": "1637", "connection": "keep-alive", "x-amzn-requestid": "6bfb900f-e60c-4861-87b4-bb555bbe3d9e" }, "RetryAttempts": 0 }, "usage": { "topicPolicyUnits": 3, "contentPolicyUnits": 3, "wordPolicyUnits": 3, "sensitiveInformationPolicyUnits": 3, "sensitiveInformationPolicyFreeUnits": 3, "contextualGroundingPolicyUnits": 3 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "contextualGroundingPolicy": { "filters": [ { "type": "GROUNDING", "threshold": 0.75, "score": 0.01, "action": "BLOCKED" }, { "type": "RELEVANCE", "threshold": 0.75, "score": 1.0, "action": "NONE" } ] } } ] } ワークフローの出力では、入力プロンプトがガードレールのチェックを通過し、ワークフローが応答を生成したことがわかります。次に、ワークフローはユーザーに提示する前にモデル出力をチェックするためにガードレールを呼び出します。そして、コンテキストグラウンディングチェックが介入したことがわかります。これは、モデル応答がグラウンドソースの情報に基づき、事実に基づいていないことを検出したためです。そのため、ワークフローは根拠がなく事実に反すると見なされる応答の代わりに、ガードレールの介入に対して定義されたメッセージを返しました。 セルフマネージド型 RAG パターン内での ApplyGuardrail APIの使用 ApplyGuardrail API の一般的なユースケースは、サードパーティプロバイダーの LLM、またはセルフホスト型モデルを RAG パターン内で適用することです。 一般的なフローには以下のステップが含まれます： モデルの入力を受け取ります。 ApplyGuardrail API を使用してこの入力にガードレールを適用します。 入力がガードレールを問題なく通過した場合、クエリ埋め込みのために埋め込みモデルに送信し、ベクトル埋め込みをクエリします。 埋め込みモデルからの出力を受け取り、それをコンテキストとして使用します。 コンテキストを入力とともに言語モデルに提供して推論を行います。 出力にガードレールを適用し、コンテキストをグラウンディングソースとして使用します。 出力がガードレールを通過した場合、最終出力を返します。 入力または出力のいずれかがガードレールによって介入された場合、入力または出力からの介入を示す定義されたメッセージを返します。 このワークフローは、以下の図で示されています。 図の実装を見るには、 コードのサンプル を参照してください。 例では、LLM に SageMaker でセルフホストされたモデルを使用しますが、これは他のサードパーティモデルでも可能です。 私たちは SageMaker エンドポイントでホストされている Meta-Llama-3-8B モデルを使用します。埋め込みには、voyage-large-2-instruct モデルを使用します。Voyage AI 埋め込みモデルの詳細については、「 Voyage AI 」を参照してください。 私たちは、埋め込み、文書検索の実行、ApplyGuardrail API と SageMaker エンドポイントの統合を行うために TextGenerationWithGuardrails クラスを拡張しました。これにより、文脈に関連する情報を用いてテキスト生成を保護します。クラスには現在、以下の主要なメソッドが含まれています： generate_text – 入力に基づいてテキストを生成するために、SageMaker エンドポイントを使用して LLM を呼び出します。 analyze_text – ApplyGuardrail APIを使用してガードレールを適用するコアメソッドです。API の応答を解釈して、ガードレールを通過したか、介入されたかを判断します。 analyze_prompt と analyze_output – これらのメソッドは analyze_text を使用して、入力プロンプトと生成された出力にそれぞれガードレールを適用します。ガードレールが通過したかどうかと関連するメッセージを含むタプルを返します。 embed_text – 指定された埋め込みモデルを使用して与えられたテキストを埋め込みます。 retrieve_relevant_documents – クエリ埋め込みと文書埋め込み間のコサイン類似度に基づいて最も関連性の高い文書を取得します。 generate_and_analyze – 埋め込み、文書検索、テキスト生成、ガードレールチェックを含むプロセスのすべてのステップを組み合わせた包括的なメソッドです。 拡張されたクラスは以下のワークフローを実装します： まず analyze_prompt を使用して、入力プロンプトをチェックします。 入力がガードレールを通過した場合、クエリを埋め込み、関連文書を取得します。 取得された文書が元のクエリに追加され、拡張クエリが作成されます。 拡張クエリを使用して、 generate_text でテキストが生成されます。 生成されたテキストは、取得された文書をグラウンディングソースとして使用して analyze_output でチェックされます 両方のガードレールが通過した場合、生成されたテキストが返されます。そうでない場合は、介入メッセージが提供されます。 この構造は、テキスト生成の前後に包括的な安全性チェックを可能にすると同時に、文書のコレクションから関連するコンテキストを組み込むことができます。これは以下の目的で設計されています： 複数のガードレールチェックを通じて安全性を強化する。 取得された文書を生成プロセスに組み込むことで関連性を向上させる。 ガードレールの結果に基づいてエラー処理とカスタマイズの柔軟性を提供する。 より大規模なアプリケーションと統合する。 取得する文書の数を調整したり、埋め込みプロセスを変更したり、取得された文書をクエリに組み込む方法を変更したりするなど、クラスをさらにカスタマイズできます。これにより、さまざまなアプリケーションで安全でコンテキストを考慮したテキスト生成を行うための多用途なツールとなります。 以下の入力プロンプトで実装をテストしてみましょう： query = "What is the Guaranteed Rate of Return for AB503 Product?" ワークフローへの入力として以下の文書を使用します： documents = [ "The AG701 Global Growth Fund is currently projecting an annual return of 8.5%, focusing on emerging markets and technology sectors.", "The AB205 Balanced Income Trust offers a steady 4% dividend yield, combining blue-chip stocks and investment-grade bonds.", "The AE309 Green Energy ETF has outperformed the market with a 12% return over the past year, investing in renewable energy companies.", "The AH504 High-Yield Corporate Bond Fund is offering a current yield of 6.75%, targeting BB and B rated corporate debt.", "The AR108 Real Estate Investment Trust focuses on commercial properties and is projecting a 7% annual return including quarterly distributions.", "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%, providing a balance of growth potential and flexible investment options."] 以下はワークフローの出力例です： === Query Embedding === Query: What is the Guaranteed Rate of Return for AB503 Product? Query embedding (first 5 elements): [-0.024676240980625153, 0.0432446151971817, 0.008557720109820366, 0.059132225811481476, -0.045152030885219574]... === Document Embedding === Document 1: The AG701 Global Growth Fund is currently projecti... Embedding (first 5 elements): [-0.012595066800713539, 0.052137792110443115, 0.011615722440183163, 0.017397189512848854, -0.06500907987356186]... Document 2: The AB205 Balanced Income Trust offers a steady 4%... Embedding (first 5 elements): [-0.024578886106610298, 0.03796630725264549, 0.004817029926925898, 0.03752804920077324, -0.060099825263023376]... Document 3: The AE309 Green Energy ETF has outperformed the ma... Embedding (first 5 elements): [-0.016489708796143532, 0.04436756297945976, 0.006371065974235535, 0.0194888636469841, -0.07305170595645905]... Document 4: The AH504 High-Yield Corporate Bond Fund is offeri... Embedding (first 5 elements): [-0.005198546685278416, 0.05041510611772537, -0.007950469851493835, 0.047702062875032425, -0.06752850860357285]... Document 5: The AR108 Real Estate Investment Trust focuses on ... Embedding (first 5 elements): [-0.03276287764310837, 0.04030522331595421, 0.0025598432403057814, 0.022755954414606094, -0.048687443137168884]... Document 6: The AB503 Financial Product is currently offering ... Embedding (first 5 elements): [-0.00174321501981467, 0.05635036155581474, -0.030949480831623077, 0.028832541778683662, -0.05486077815294266]... === Document Retrieval === Retrieved Document: [ "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%, providing a balance of growth potential and flexible investment options." ] 取得された文書は、 ApplyGuardrail API の呼び出しのグラウンディングソースとして提供されます： === Input Analysis === Input Prompt Passed The Guardrail Check - Moving to Generate the Response === Text Generation === Here is what the Model Responded with: However, investors should be aware that the actual return may vary based on market conditions and other factors. What is the guaranteed rate of return for the AB503 product? A) 0% B) 7% C) Not applicable D) Not provided Correct answer: A) 0% Explanation: The text states that the rate of return is "non-guaranteed," which means that there is no guaranteed rate of return. Therefore, the correct answer is A) 0%. The other options are incorrect because the text does not provide a guaranteed rate of return, and the non-guaranteed rate of 7% is not a guaranteed rate of return. Option C is incorrect because the text does provide information about the rate of return, and option D is incorrect because the text does provide information about the rate of return, but it is not guaranteed. === Output Analysis === Analyzing Model Response with the Response Guardrail Output Guardrail Intervened. The response to the User is: I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. Full API Response: { "ResponseMetadata": { "RequestId": "5f2d5cbd-e6f0-4950-bb40-8c0be27df8eb", "HTTPStatusCode": 200, "HTTPHeaders": { "date": "Mon, 29 Jul 2024 17:52:36 GMT", "content-type": "application/json", "content-length": "1638", "connection": "keep-alive", "x-amzn-requestid": "5f2d5cbd-e6f0-4950-bb40-8c0be27df8eb" }, "RetryAttempts": 0 }, "usage": { "topicPolicyUnits": 1, "contentPolicyUnits": 1, "wordPolicyUnits": 1, "sensitiveInformationPolicyUnits": 1, "sensitiveInformationPolicyFreeUnits": 1, "contextualGroundingPolicyUnits": 1 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "contextualGroundingPolicy": { "filters": [ { "type": "GROUNDING", "threshold": 0.75, "score": 0.38, "action": "BLOCKED" }, { "type": "RELEVANCE", "threshold": 0.75, "score": 0.97, "action": "NONE" } ] } } ] } 以下のソース文書の記述により、ガードレールが介入したことがわかります： [ "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%, providing a balance of growth potential and flexible investment options." ] 一方、モデルは以下のように応答しました： Here is what the Model Responded with: However, investors should be aware that the actual return may vary based on market conditions and other factors. What is the guaranteed rate of return for the AB503 product? A) 0% B) 7% C) Not applicable D) Not provided Correct answer: A) 0% Explanation: The text states that the rate of return is "non-guaranteed," which means that there is no guaranteed rate of return. Therefore, the correct answer is A) 0%. The other options are incorrect because the text does not provide a guaranteed rate of return, and the non-guaranteed rate of 7% is not a guaranteed rate of return. Option C is incorrect because the text does provide information about the rate of return, and option D is incorrect because the text does provide information about the rate of return, but it is not guaranteed. これはハルシネーションを示しています。ガードレールが介入し、ハルシネーションされた回答の代わりに定義されたメッセージをユーザーに提示しました。 価格 ソリューションの価格は主に以下の要因に依存します： ガードレールに送信されるテキスト文字数 – 価格の詳細な内訳については、 Amazon Bedrock の価格 を参照してください。 セルフホスト型モデルのインフラのコスト – プロバイダーに依存します。 サードパーティ管理モデルのトークンコスト – プロバイダーに依存します。 クリーンアップ この例でプロビジョニングされたインフラストラクチャを削除するには、 GitHub リポジトリ の手順に従ってください。 結論 ApplyGuardrail API を使用して、生成 AI アプリケーションのセーフガードを FM から切り離すことができます。これで、FM を呼び出さずにガードレールを使用できるようになり、使用されるモデルに関係なく、標準化され徹底的にテストされたエンタープライズレベルのセーフガードをアプリケーションフローにさらに統合できるようになりました。 GitHubリポジトリ のサンプルコードを試して、フィードバックがあれば提供してください。Amazon Bedrock Guardrails と ApplyGuardrail API の詳細については、 Amazon Bedrock Guardrails を参照してください。 翻訳はソリューションアーキテクト菊地が担当しました。 著者について Michael Cho は、AWS のソリューションアーキテクトで、顧客がクラウドでのミッションを加速するための支援しています。彼は顧客に力を与える革新的なソリューションの設計し、構築することに情熱を注いでいます。最近では、複雑なビジネスの問題を解決するために生成 AI を使って実験することに時間を費やしています。 Aarushi Karandikar は、AWS のソリューションアーキテクトで、エンタープライズ ISV の顧客にクラウドジャーニーに関する技術的ガイダンスを提供しています。彼女は UC Berkeley でデータサイエンスを学び、生成 AI の技術を専門としています。 Riya Dani は、AWS のソリューションアーキテクトで、エンタープライズの顧客のクラウドジャーニーを支援しています。彼女は学ぶことに情熱を持ち、Virginia Tech でコンピューターサイエンスの学士号と修士号を取得しています。空き時間には、アクティブに過ごすことと読書を楽しんでいます。 Raj Pathak は、プリンシパルソリューションアーキテクトで、カナダと米国のフォーチュン 50 および中堅 FSI（銀行、保険、資本市場）の顧客の技術顧問です。Raj は、生成 AI、自然言語処理、インテリジェントドキュメント処理、MLOps への応用を含む機械学習を専門としています。

AWS re:Invent 2024 に向けた準備が着々と進む中、11 月 6 日は最新の AWS ヒーロー たちを発表したいと思います! 新しいヒーローたちは、AWS テクノロジーに関する専門知識、そしてこれらのテクノロジーの活用と知識の共有への献身におけるすばらしいお手本です。ヒーローたちの AWS コミュニティへの貢献に心から感謝し、彼らを皆さんにご紹介できるのをとても嬉しく思っています。 Ayyanar Jeyakrishnan 氏 – インド、ベンガルール 機械学習ヒーローである Ayyanar Jeyakrishnan 氏は、Wells Fargo の Principal Engineer/Executive Director です。機械学習とクラウドの経験豊富な愛好家であり、AWS テクノロジーを強く重視する Jeyakrishnan 氏の専門知識には、AWS での機械学習モデルのデプロイと管理を合理化するためのデータプラットフォームの作成と、DevOps および MLOps ソリューションの設計が含まれます。Jeyakrishnan 氏は知識の共有に情熱を注いでおり、業界イベントやコミュニティミートアップで MLOps、生成 AI、機械学習アプリケーションに関する講演を頻繁に行っています。 Dzenana Dzevlan 氏 – ボスニア・ヘルツェゴビナ、サラエボ コミュニティヒーローである Dzenana Dzevlan 氏 は、AllOps Solutions (APN パートナー企業) の共同創設者兼 Technical Manager です。Dzevlan 氏は International Burch University で専門家演習講師を務めており、DevOps、生成 AI、およびその他先進テクノロジーに関する知識を積極的に共有しています。テクノロジーに対する Dzevlan 氏の情熱は教室内だけにとどまらず、クラウドや AI ソリューションに関する学生の指導も活発に行っています。テクノロジーにおける多様性の熱心な提唱者でもあり、業界における女性のインクルージョンとエンパワーメントを支持しています。Dzevlan 氏は、講演やメンターシッププログラムを通じて次世代の IT およびクラウドプロフェッショナルを育成し、彼らのインスピレーションとなっています。 Kenneth Attard 氏 – マルタ、バレッタ コミュニティヒーローである Kenneth Attard 氏 は、マルタを本拠とする Betsson Group の Enterprise Architect です。Attard 氏には 20 年におよぶ技術経験があり、過去 8 年間は AWS クラウドのネットワーク、セキュリティ、およびガバナンスを専門としてきました。AWS Malta User Group のリーダーであり、Malta AWS Community Day の主催者でもある Attard 氏は、クラウド愛好家や専門家の間での知識の育成と学習に情熱を注いでいます。また、現地イベントと国際イベントの両方で頻繁に講演を行っており、これには複数の国で行われた AWS Cloud Day、AWS Summit、および AWS Community Day が含まれます。 Marcin Sodkiewicz 氏 – ポーランド、ヴロツワフ サーバーレスヒーローである Marcin Sodkiewicz 氏 は、Ryanair の Principal Software Engineer です。2016 年に入社した Sodkiewicz 氏は、データセンターからクラウド、そしてサーバーレスファーストの考え方に基づいて構築するチームへの目覚ましい技術的飛躍の一端を担いました。その間、Sodkiewicz 氏は多くのことを見て学びましたが、特に学んだのは、クラウドが高品質かつスケーラブルで信頼性と収益性を備えたソフトウェアの迅速な提供にもたらす違いです。「誰もが手頃な価格で旅行できるようにする」ことを使命とする格安航空会社で働いていることから、Sodkiewicz 氏にとって収益性は非常に重要です。これは、競争上の優位性を実現するコスト最適化されたソリューションの構築への関心と一致しています。Sodkiewicz 氏は、イベント駆動型およびサーバーレスアーキテクチャ、レジリエンシー、コスト最適化、オブザーバビリティといったお気に入りのトピックの視点から、AWS についてブログ記事を書いたり語ったりしています。また、Sodkiewicz 氏が住む街であるヴロツワフでの AWS User Group 主催者の一人でもあります。 Stephen Sennett 氏 – オーストラリア、メルボルン コミュニティヒーローである Stephen Sennett 氏 は、オーストラリアを本拠とする Kinetic IT の Senior Consultant です。経験豊富なクラウドテクノロジストである Sennett 氏は、アーキテクト、コンサルタント、エンジニア、および教育者として 10 年以上もの間 AWS と連携してきました。2021 年から 2024 年にかけて AWS コミュニティビルダープログラムのメンバーであった Sennett 氏は、AWS コミュニティのその他メンバーのメンターを務めるとともに、AWS New Voices プログラムを通じて将来のソートリーダーのパブリックスピーキングコーチも務めました。Sennett 氏は熟練の基調講演者でもあり、AWS Community Day、AWS Summit、および世界中のその他技術カンファレンスでセッションを行っています。プロフェッショナルとしての役割以外にも、現役のボランティア緊急管理官、および非営利団体の役員を務めています。 Vadym Kazulkin 氏 – ドイツ、ボン サーバーレスヒーローである Vadym Kazulkin 氏 は、ip.labs GmbH (富士フイルムの子会社) の Head of Development であり、20 年以上におよぶ Java エコシステムの専門知識を携えています。現在は、拡張性に優れた AWS クラウドアプリケーションの設計と実装に焦点を当てており、サーバーレスアーキテクチャに情熱を傾けています。Java User Group Bonn ミートアップの共同主催者として、Kazulkin 氏は AWS ミートアップや Java ミートアップ、カンファレンス、AWS Community Day、ServerlessDay などの現地イベントや国際イベントで知識を積極的に共有しています。Kazulkin 氏は、クラウドテクノロジーとサーバーレステクノロジーに関するインサイトの共有と継続的な学習の両方において、コミュニティエンゲージメントを大切にしています。 詳細をご覧ください AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブサイト にアクセスしてください。 – Taylor 原文は こちら です。