ディザスタリカバリ (災害復旧) と高可用性計画は、事業運営の回復力と継続性を確保する上で重要な役割を果たします。AWS でのディザスタリカバリ戦略を検討する場合、主要な選択肢は 2 つあります。リージョン内のディザスタリカバリとリージョン間のディザスタリカバリです。リージョン内ディザスタリカバリとリージョン間のディザスタリカバリのどちらを選択するかは、アプリケーションとデータの重要性、規制要件、ユーザーの地理的分布、コスト、複雑さなど、さまざまな要因によって異なります。 AWS にマルチリージョンのディザスタリカバリソリューションを実装するには、まずインフラストラクチャの重要なコンポーネントを特定し、各コンポーネントに必要な目標復旧時点 (RPO) と目標復旧時間 (RTO) を決定する必要があります。RPO は許容できる最大データ損失量であり、RTO はシステムを復元するために定められた時間までにかかる最大時間です。 2023 年 7 月現在、 AWS クラウド は世界 31 の地理的リージョンにある 99 のアベイラビリティーゾーンにまたがっています。AWS はまた、カナダ、イスラエル、マレーシア、ニュージーランド、タイに 15 のアベイラビリティーゾーンと 5 つの AWS リージョンを追加する計画も発表しました。 Amazon Relational Database Service (Amazon RDS) は、クラウドでのデータベースのセットアップ、運用、スケーリングを簡単にするマネージドサービスです。 MySQL 、 MariaDB 、 PostgreSQL 、 Oracle 、 SQL Server などの一般的なエンジンから選択できます。 このシリーズでは、さまざまな AWS リージョンで可能な限りの高可用性とディザスタリカバリを必要とする重要なアプリケーションのニーズに焦点を当てます。この最初の投稿では、2 つの AWS リージョンにまたがって Amazon RDS for SQL Server 、 Amazon Route53 、 Amazon Simple Storage Service(Amazon S3) を使用するアプリケーションのフェイルオーバー戦略を確立するプロセスをご案内します。次の投稿では、このプランを使用して実際にフェイルオーバーを実行する方法を示します。 ソーリューション概要 このソリューションは、アクティブ/パッシブ戦略を採用した 2 つの AWS リージョンにデプロイされて、プライマリ (アクティブ) リージョンがワークロードをホストしてトラフィックを処理します。セカンダリ (パッシブ) リージョンはディザスタリカバリに使用されます。フェイルオーバーポリシーが設定された Amazon Route53 パブリックホストゾーンは、プライマリリージョンとセカンダリリージョンの間でインターネットトラフィックをルーティングするために作成されます。Amazon Route 53 プライベートホストゾーン CNAME レコードは RDS for SQL Server エンドポイントを格納します。アプリケーションはこれらのレコードを使用してデータベースに接続します。 次の図は、このアーキテクチャの主要なコンポーネントを示しています。 この例では、プライマリ AWS リージョンは us-east-1、セカンダリ AWS リージョンは us-east-2 です。さらに、次の点にも注意してください。 Amazon RDS for SQL Server マルチ AZ DB インスタンスはプライマリ AWS リージョンにデプロイされ、クロスリージョンリードレプリカはセカンダリリージョンにあります。 Amazon RDS for SQL Server は、 分散可用性グループ を使用してクロスリージョンリードレプリカ (非同期レプリケーション) を設定します。 アプリケーションスタックは両方のリージョンにデプロイされ、リリースバージョンは同じです。 インターネットトラフィックを処理する Amazon Route53 パブリックホストゾーン には “フェイルオーバー” ルーティングポリシー が設定されています。 Amazon Route53 プライベートホストゾーン は、SQL Server インスタンス接続のための RDS へのアプリケーション用の “シンプル” ルーティングポリシーで設定されています。 スタンバイがプライマリを引き継ぐ Amazon Route 53 パブリックホストゾーン のフェイルオーバーポリシーは、Standby takes over primary (スタンバイがプライマリを引き継ぐ) アプローチを使用して実装されます。この方法では、プライマリリージョンの Route53 ヘルスチェックが HTTP エンドポイントのアクセシビリティを検証します。そのエンドポイントはセカンダリリージョンに保存されている Amazon S3 ファイルになります。たとえば、AWS リージョン us-east-2 に examplebucket123 という名前の Amazon S3 バケットがあり、ファイル名が initiate_failover.dr の場合、この S3 ファイルにアクセスするための対応するエンドポイントは次のようになります。 https://examplebucket123.s3.us-east-2.amazonaws.com/initiate_failover.dr このヘルスチェックは、指定されたエンドポイントから受信した HTTP 応答が 4xx または 5xx のステータスコード (つまり、Route 53 ヘルスチェックエージェントがその Amazon S3 ファイルエンドポイントを解決できない) を返したときに正常と見なされます。逆に、レスポンスで 2xx または 3xx のステータスコードが返された場合、ヘルスチェックは失敗します (つまり、Route 53 ヘルスチェックエージェントは Amazon S3 ファイルエンドポイントを解決できたということです)。この方法は Route53 Invert ヘルスチェック と呼ばれます。この方法では、プライマリ AWS リージョンとセカンダリ AWS リージョン間のフェイルオーバーを手動で制御できるだけでなく、スタンバイリージョンのリソースに障害が発生した場合の偶発的なフェイルオーバーを防ぐこともできます。ディザスタリカバリ時には、このファイルをセカンダリリージョンの S3 バケットにアップロードしてください。これにより、プライマリリージョンの Route53 ヘルスチェックが意図的に失敗します。 HTTP ステータスコードのリスト については、このドキュメントを参照してください。信頼性の高いフェイルオーバーメカニズムを設計するさまざまなアプローチを包括的に理解するには、「 Amazon Route 53 を用いたディザスタリカバリ (DR) のメカニズム 」を参照してください。 インターネットトラフィックをセカンダリリージョンに自動的にフェイルオーバーすることは推奨されないことに注意してください。プライマリリージョンのネットワーク障害が短時間発生したような状況では、自動フェイルオーバーによってダウンタイムが長くなる可能性があります。 前提条件 このソリューションを実装するには、次のものが必要です。 プライマリリージョンのアプリケーションスタックと Amazon RDS for SQL Server マルチ AZ インスタンス。 セカンダリリージョンのアプリケーションスタックと Amazon RDS for SQL Server リードレプリカインスタンス (クロスレプリケーション)。手順については、「 Amazon Relational Database Service for SQL Server でクロスリージョンのリードレプリカを使用する 」を参照してください。 リードレプリカの作成後にプライマリ DB インスタンスで作成されたサーバーレベルのオブジェクト (ログイン、SQL エージェントジョブなど) は自動的にレプリケートされないため、リードレプリカで手動で作成する必要がありす。そのため、これらのオブジェクトがプライマリリージョンとセカンダリリージョンの間で同期していることを確認してください。詳細については、 Amazon RDS のドキュメント を参照してください。 ウォークスルー このソリューションを導入するには、次の手順を実行します。 プライマリリージョンの Amazon Relational Database service (RDS) コンソール に移動します。 SQL Server インスタンスのプライマリ RDS のエンドポイントを書き留めておきます。 同様に、 セカンダリリージョンの Amazon RDS コンソール に移動します。 RDS for SQL Server クロスリージョンリードレプリカのエンドポイントを書き留めておきます。 Amazon Route53 コンソール に移動します。 新しい プライベートホストゾーン を 作成します 。 両方のリージョンの VPC をプライベートホストゾーンに関連付けます。これはプライベートホストゾーンは Amazon VPC 内でトラフィックをルーティングするために必要です。 プライベートホストゾーンを作成したら、 シンプルルーティングポリシー で 2 つの CNAME レコードを追加します。この例では、以下の CNAME レコードを作成しました。 rdsprimarydb.rds_sqlserver_private_hosted_zone – プライマリリージョンの RDS for SQL Server に接続します。 rdssecondarydb.rds_sqlserver_private_hosted_zone – クロスリージョンリードレプリカの RDS for SQL Server に接続します。 両方の CNAME レコードを追加すると、プライベートホストゾーンは次のスクリーンショットのようになります。 データベース接続文字列のデータベースホスト名として CNAME レコード rdsprimarydb.rds_sqlserver_private_hosted_zone を使用してプライマリリージョンのアプリケーション設定を更新してください。 同様に、CNAME レコード rdssecondarydb.rds_sqlserver_private_hosted_zone を使用して、セカンダリリージョンのアプリケーションを更新します。このステップにより、アプリケーションが RDS エンドポイントを直接使用していないことが保証されます。そのため、フェイルオーバー中にアプリケーションを変更する必要はありません。 次の Python コードは、プライベートホストゾーン CNAME レコードを使用して RDS for SQL Server インスタンスに接続するコードの例です。 プライマリリージョンとセカンダリリージョンの両方に新しい Amazon S3 バケットを作成します。これらの S3 バケットはホストディザスタリカバリファイル専用です。ヘルスチェックプロセスのセキュリティと整合性を確保するには、このバケットへのアクセスを権限のある担当者のみに制限することが重要です。プライマリリージョンとセカンダリリージョンの両方が正常であれば、この時点でこれらのバケットは空のままにしておくことができます。 Amazon Route53 コンソール に移動し、 Route53 パブリックホストゾーン を作成して、パブリックドメインのインターネットトラフィックを管理します。 パブリックホストゾーンを作成したら、 Amazon Route53 ヘルスチェックコンソール に移動します。 新しい Route53 ヘルスチェックを 2 つ作成します。1 つはプライマリリージョンのフェイルオーバー用、もう 1 つはセカンダリリージョンのフェイルオーバー用です。これらのヘルスチェックは、プライマリリージョンのフェイルオーバーレコードとセカンダリリージョンのフェイルオーバーレコードに紐付けられます。 「ヘルスチェックの作成」ページで、以下を行います。 プライマリリージョンのヘルスチェック名を入力します。 次に、モニタリング対象の [ エンドポイント ] オプションを選択します。 エンドポイントの監視 のセクションで、[ ドメイン名 ] に入力してプロトコルに [ HTTPS ] を選択します。 [ドメイン名] で、セカンダリリージョンの Amazon S3 バケットエンドポイントを指定します。例 : examplebucket123.s3.us-east-2.amazonaws.com [パス] で、ディザスタリカバリファイル名を指定します。例 : initiate_failover.dr 「高度な設定」セクションで 失敗しきい値 と リクエスト間隔 を指定します。 [ ヘルスチェックステータスを反転 ] のオプションにチェックを入れ、[次へ] をクリックします。 [ ヘルスチェックの作成 ] をクリックします。 同じ手順を繰り返して、セカンダリリージョンのヘルスチェックレコードを作成します。 プライマリリージョンのヘルスチェックでは、セカンダリリージョンの S3 ファイルエンドポイントを指定します。その逆も同様です。プライマリリージョンにアクセスできなくなった場合は、セカンダリリージョンの S3 ファイルを変更してフェイルオーバーを開始できます。 プライマリリージョンとセカンダリリージョンのヘルスチェックが作成されると、Amazon Route53 はヘルスチェックを開始してステータスを報告します。 ステップ 13 で作成した Route53 パブリックホストゾーン に移動して、以下の手順を実行します。 フェイルオーバールーティングポリシー を使用してレ コードを作成 します。 [ フェイルオーバーレコードを定義 ] をクリックします。 このレコードをアプリケーションターゲットに関連付けます。たとえば、Route53 はアプリケーションロードバランサー、API ゲートウェイ、VPC エンドポイント、S3 エンドポイントなどをサポートしています。この例では、アプリケーション負荷分散ターゲットが選択されています。 プライマリリージョンを選択。 対象のロードバランサーを選択します。 フェイルオーバーレコードタイプを プライマリ に指定します。 プライマリリージョン用に作成されたヘルスチェックレコードを選択してください。 ターゲットヘルス評価オプションを無効にします。 サブミット 同様の手順を繰り返して、2 番目のレコードタイプ用に別のレコードを作成します。 パブリックホストゾーンの設定が完了すると、以下のスクリーンショットのようになります。 これで、Amazon Route53、Amazon S3、および Amazon RDS for SQL Server によるディザスタリカバリブループリントのデプロイが完了しました。この時点で、インターネットトラフィックを介してアプリケーションにアクセスできるはずです。 後片付け このシリーズの次回の記事では、このブルーポイントを使用して、クロスリージョンフェイルオーバーを実行する方法を示します。したがって、継続する予定がある場合は、このデプロイで作成されたすべてのリソースを保存しておいてください。 このソリューションを実装するために作成されたリソースを削除するには、次の手順を実行します。 作成したパブリックホストゾーンとプライベートホストゾーンを削除します。 アプリケーション構成を元の状態に変更します。 作成した Amazon S3 バケットを削除します。 まとめ この記事では、クロスリージョンのディザスタリカバリブループリントを実施する方法についてのガイダンスを提供しました。Amazon Route53 のパブリックホストゾーンポリシーの「スタンバイがプライマリを引き継ぐ」アプローチにより、組織はフェイルオーバープロセスの制御を維持し、プライマリリージョンにアクセスできなくなったときに手動でフェイルオーバーを開始できます。 このシリーズの 次回の記事 では、AWS セカンダリリージョンで RDS for SQL Server を昇格するプロセスと、デプロイしたブループリントを使用してクロスリージョンフェイルオーバーを実行するプロセスについて詳しく説明します。 著者について Ravi Mathur は、AWS のシニアソリューションアーキテクトです。彼はお客様と連携して、さまざまな AWS サービスに関する技術支援やアーキテクチャに関するガイダンスを提供しています。彼は、さまざまな大規模企業でソフトウェアエンジニアリングとアーキテクチャの役割に数年間携わった経験を持っています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

SageMaker Canvas は、生成系 AI を使用してコンテンツを生成および要約するための基盤モデル ( FM ) を、簡単に使えるモデルとしてサポートする ようになりました。自然言語を会話型チャットインターフェイスと併用すると、説明文、レポート、ブログ投稿の作成、質問への回答、メ自然言語を会話型チャットインターフェイスと併用すると、説明文、レポート、ブログ投稿の作成、質問への回答、メモや記事の要約、概念の説明などのタスクを、コードを 1 行も記述せずに実行できます。お客様のデータは、基盤モデルの改善には使用されず、サードパーティのモデルプロバイダーと共有されることもなく、完全に安全な AWS 環境内に留まります。 SageMaker Canvas では、 Amazon Bedrock モデル ( Anthropic の Claude 2 や AI21 Labs の Jurassic-2 など ) や、公開されている Amazon SageMaker JumpStart モデル ( Falcon-7B-Instruct 、Falcon-40B-Instruct など) を含むさまざまな FM にアクセスできます。1 つのモデルまたは最大 3 つのモデルを使用して、モデルの応答を並べて比較できます。SageMaker Canvas では、Amazon Bedrock モデルは常にアクティブになっているため、すぐに使用できます。SageMaker JumpStart モデルはオンデマンドで AWS アカウントで起動およびデプロイでき、2 時間操作がないと自動的にシャットダウンされます。 SageMaker Canvas の生成系 AI 機能を使用する方法を見てみましょう。この投稿では、架空のエンタープライズカスタマーサポートのユースケースを例として取り上げます。 前提条件 前提条件となる以下のステップを完了してください。 AWS アカウント を作成します。 SageMaker Canvas をセットアップし、オプションでインターネットにアクセスできない VPC を使用するように 設定 します。 Amazon Bedrock でモデルアクセスを設定します。 必要に応じて、お住まいの地域の g5.12xlarge と g5.2xlarge の サービスクォータ の増加をリクエストしてください。これらのインスタンスは SageMaker JumpStart モデルのエンドポイントをホストするために必要です。他のインスタンスは、可用性に基づいて選択できます。 顧客からの苦情の処理 あなたが自転車会社の苦情を処理するカスタマーサポートアナリストだとしましょう。顧客からの苦情を受けた場合、SageMaker Canvas を使用して苦情を分析し、顧客への個別の対応を生成できます。そのためには、以下のステップを完了してください。 SageMaker コンソールのナビゲーションペインで Canvas を選択します。 ドメインとユーザープロファイルを選択し、 Open Canvas を選択して SageMaker Canvas アプリケーションを開きます。 また、SageMaker Canvas には、最初に SageMaker コンソールにアクセスしなくても、 シングルサインオン やその他の既存の ID プロバイダー ( IDP ) を使用してアクセスできます。 Generate, extract and summarize content を選択してチャットコンソールを開きます。 Claude 2 モデルを選択した状態で、指示を入力して、自転車に関する苦情に対する顧客の感情を取得し、 Enter キーを押します。 特に苦情が長い場合は、自転車の具体的な問題を知りたいと思うかもしれません。だから、自転車の問題点を聞いてください。SageMaker Canvas はチャットのコンテキストを保存するので、苦情を再投稿する必要はないことに注意してください。 お客様の問題を理解したので、会社のフィードバックフォームへのリンクを含む回答を送信できます。 入力ウィンドウで、顧客からの苦情への回答をリクエストします。 FM から別のレスポンスを生成したい場合は、レスポンスセクションの更新アイコンを選択します。 元の回答とすべての新しい回答は、回答セクション内でページ分けされます。新しいレスポンスは元のレスポンスとは異なることに注意してください。必要に応じて、応答セクションのコピーアイコンを選択して、応答を電子メールまたは文書にコピーできます。 特定の変更をリクエストすることで、モデルの応答を変更することもできます。たとえば、モデルに50ドルのギフトカードオファーをメールの返信に追加するように依頼してみましょう。 モデル応答の比較 複数のモデル (最大 3 つ) のモデルからの応答を比較できます。Amazon Bedrock の 2 つのモデル ( Claude 2 と Jurassic-2 Ultra ) を SageMaker JumpStart モデル ( Falcon-7B-Instruct ) と比較して、評価してユースケースに最適なモデルを見つけてみましょう。 New chat を選択してチャットインターフェースを開きます。 モデルのドロップダウンメニューで、 Start up another model を選択します。 Foundation models ページの Amazon SageMaker JumpStart models で Falcon-7B-Instruct を選択し、右側のペインで Start up model を選択します。 モデルの起動には約 10 分かかります。 Foundation models ページで、次のステップに進む前に、Falcon-7B-Instruct モデルがアクティブであることを確認します。 New chat を選択してチャットインターフェースを開きます。 Compare を選択して 2 番目のモデルのドロップダウンメニューを表示し、もう一度 Compare を選択すると 3 番目のモデルのドロップダウンメニューが表示されます。 最初のドロップダウンメニューで Falcon-7B-Instruct モデルを選択し、2 番目のドロップダウンメニューで Claude 2 モデルを選択し、3 番目のドロップダウンメニューで Jurassic-2 Ultra モデルを選択します。 チャット入力ボックスに指示を入力し、 Enter キーを押します。 3 つのモデルすべてからの応答が表示されます。 2023/11/02時点で、Falcon-7B-Instruct、Jurassic-2が日本語未対応のため、英語で「顧客からの苦情の処理」と同内容のメールを生成しています。 クリーンアップ SageMaker Canvas から起動した SageMaker JumpStart モデルはどれも、2 時間操作がないと自動的にシャットダウンされます。コストを節約するためにこれらのモデルをより早くシャットダウンしたい場合は、このセクションの指示に従ってください。Amazon Bedrock モデルはアカウントにデプロイされていないため、これらをシャットダウンする必要はないことに注意してください。 SageMaker JumpStart の Falcon-40B-Instruct モデルをシャットダウンするには、次の 2 つの方法から選択できます。 結果比較ページで、Falcon-7B-Instruct モデルのオプションメニュー (3 つのドット) を選択し、次に Shut down mode を選択します。 または、New chat を選択し、model ドロップダウンメニューで Start up another model を選択します。次に、 Foundation models ページの Amazon SageMaker JumpStart models で Falcon-7B-Instruct を選択し、右側のペインで Shut down model を選択します。 左側のペインで Log out を選択して SageMaker Canvas アプリケーションからログアウトし、 SageMaker Canvas ワークスペースインスタンスのセッション時間の消費 を停止し、ワークスペースインスタンスが使用していたすべてのリソースを解放します。 結論 この投稿では、SageMaker Canvas を使用して、Amazon Bedrock と SageMaker JumpStart のすぐに使用できるモデルを使用してテキストを生成する方法を学びました。Claude 2 モデルを使用して、コードを 1 行も記述せずに、顧客の苦情に対する感情を分析し、質問をして、回答を生成しました。また、公開モデルを開始し、3 つのモデルからの回答を比較しました。 Amazon Bedrock モデルの場合、 Amazon Bedrock の料金ページ にあるように、入力トークンと出力トークンの量に基づいて課金されます。SageMaker JumpStart モデルは SageMaker インスタンスにデプロイされるため、 Amazon SageMaker の料金ページ  に従って、インスタンスタイプに基づいて使用期間分の料金が請求されます。 SageMaker Canvas は、ビジネスアナリストがさまざまなユースケースに対応する ML モデルを構築できる、コード不要の視覚的でインタラクティブなワークスペースで AI を民主化し続けています。SageMaker Canvas の新しい生成系AI 機能を今すぐ試してみてください。これらの機能は、 Amazon Bedrock または SageMaker JumpStart が利用可能なすべてのリージョンで利用できます。 原文は こちら です。ソリューションアーキテクトの濱野谷(@yoshiehm)が、英語版を元に翻訳しました。 著者について Anand Iyer は 2016 年から AWS の主任ソリューションアーキテクトを務めています。Anand は、世界中のヘルスケア、ファイナンスサービス、電気通信のクライアントが AWS とハイブリッドクラウドテクノロジーを使用してエンタープライズソフトウェアソリューションを設計および実装するのを支援してきました。ルイジアナ州立大学バトンルージュ校でコンピューターサイエンスの修士号を、ロサンゼルスの USC マーシャル・スクール・オブ・ビジネスで経営学修士号を取得しています。セキュリティ、ソリューションアーキテクチャ、DevOps エンジニアリングの分野で AWS の認定を受けています。 Gavin Satur は、アマゾンウェブサービスの主任ソリューションアーキテクトです。彼は企業のお客様と協力して、戦略的で優れた設計のソリューションを構築し、自動化に情熱を注いでいます。仕事以外では、家族との時間、テニス、料理、旅行を楽しんでいます。 Gunjan Jain は SoCal の AWS ソリューションアーキテクトで、主に大手ファイナンスサービス会社で働いています。クラウドの運用、クラウドの最適化、クラウド上で優れた設計を実現するためのベストプラクティスの採用を支援しています。 Harpreet Dhanoa は AWS で経験を積んだシニアソリューションアーキテクトで 、スケーラブルな分散システムの設計と構築において豊富な経歴を持っています。機械学習、オブザーバビリティ、分析に情熱を注いでいます。彼は、大規模な顧客がクラウドエンタープライズ戦略を構築し、AWS でビジネスを変革するのを支援することを楽しんでいます。自由時間には、ハープリートは2人の息子とバスケットボールをしたり、家族と過ごしたりしています。

本ブログでは、日本語 LLM の OSS である OpenCALM を LoRA (Low-Rank Adaptation) を用いた Fine-Tuning によりクイズ回答の精度を向上させるコードを SageMaker Studio Lab 上で実行することに挑戦します。最初に背景や課題についてご説明しますが、早速動かしてみたい方は、 SageMaker Studio Lab で日本語 LLM OpenCALM を動かす準備 からお読みいただくとスムーズです。 制限事項 執筆時点で SageMaker Studio Lab には CPU と GPU いずれも 1 日あたり連続の利用時間上限が決められています。また、閉域接続するオプションがなくインターネットフェーシングするサービスになります。好評いただいているサービスのため、特に GPU の利用時に一度では Start runtime できず複数回トライいただく場合があります。これらの特徴と上手にお付き合いいただきご利用いただければ嬉しいです。 日本語 LLM を学習してみたいけど、、、 最近、日本語 LLM (Large Language Model) の OSS が複数出現し、プライベートでも企業用途でも気になってらっしゃる方が多いのではないでしょうか？生成系 AI の一種である 日本語 LLM を使えば、 RAG (Retrieval Augmented Generation) を用いたエンタープライズサーチやチャットボットの高度化を日本語対応する形で実現できます。エンタープライズサーチもチャットボットもユーザが必要とする情報を取得するための手段であり、その高速化、高精度化は多くのユースケースに効果をもたらします。ソリューションアーキテクトとして日々お客様と相対させていただく中で、生成系 AI のお問合せの中でも RAG に関する議論が多いのはこのような背景からだと考えています。お客様からよくいただくご質問をいくつかピックアップしてみます。 ・ RAG に用いる LLM は学習する必要があるか？ RAG における LLM の学習の考え方には 3 つの選択肢があります。 学習済みの LLM をそのまま利用する（再学習しない） 学習済みの LLM を 再学習 (Fine-Tuning) して利用する LLM を一から学習して利用する 注意いただきたいのは、上記いずれも RAG 方式を採用することでお客様独自のデータに基づいた回答をすることが可能であるという点です。1, 2, 3 の順に学習に関する専門知識の必要性、開発、ランニングコストが大きくなる傾向があります。そのため、取り組みやすさも 1, 2, 3 の順と言って良いでしょう。1 から取り組んで、課題が発生した場合の対策として、2, 3 に進むステップでの検証方法をお伝えすることがあります。 ・ RAG に用いる LLM に日本語 LLM の OSS を使いたいが、その場合でも上記の考え方は同じか？ 基本的には同じであると考えています。日本語 LLM の OSS をご利用いただく場合は SageMaker を用いて推論用の Web API をホストいただく方法があります。コスト、データ保護、社内ポリシーなどの理由により自社で LLM モデルを管理したい場合には優れた選択肢の一つです。 ・ プロプライエタリのモデルよりも、OSS の LLM を再学習した方が精度が上がる可能性はあるか？ 可能性があります。こちらの ブログ をご覧ください。 株式会社サイバーエージェント様から 2023 年 5 月 11 日に公開された日本語大規模言語モデル である OpenCALM を Fine-Tuning した場合と、ChatGPT とを比較しています。 これらの議論をすると、「自社でも LLM を Fine-Tuning してみたい」というお話に発展するのですが、できるだけ小さなステップから始めることに越したことはありません。生成系 AI を費用対効果よくご利用いただくための GPU, Trainium , Inferentia を搭載した EC2 や、機械学習ワークロードに全面的に活用いただける SageMaker を LLM の Fine-Tuning にも有用なサービスとして AWS からご提供しています。しかしながら、これから AWS アカウントを取る必要があるお客様もいれば、自社内にアカウントがあっても必要な権限が付与されていない場合もあるでしょう。かと言って、GPU を搭載したマシンを購入いただいて検証を始めるというのも調達に時間と手間がかかってしまいます。 SageMaker Studio Lab という選択肢 そこで、AWS では SageMaker Studio Lab を提供しています。AWS アカウント不要の無料の Notebook サービスです。AWS アカウントとは別であり、メールアドレスがあれば登録することができます。始め方は こちら です。 SageMaker Studio Lab は 機械学習帳とも連携 しており、SageMaker Studio Lab を使ってすぐに機械学習のスキル獲得を始めていただく事ができます。 無料のノートブックと聞いて、以下のような懸念を感じる方もいらっしゃるのではないでしょうか？ GPU を使うと有料になるのではないか？ いいえ、SageMaker Studio Lab では GPU を無料でご利用いただけます ストレージを利用すると有料になるのではないか？ いいえ、SageMaker Studio Lab では 15 GB のディスク領域をご利用いただけます また、一度 Stop Runtime してしまうと消えてしまう領域とはなりますが、上記以外のディスク領域を活用いただく事が可能です (後述 RoLAで重要な要素となります) 使用できるライブラリや Python のバージョンが固定されているのではないか？ いいえ、上記の通り、Stop Runtime しても消えないストレージ領域に Conda 環境を保存いただくことで、継続的にご利用可能なお客様環境を構築いただく事ができます SageMaker Studio Lab 上で開発したものを別の開発環境に持っていくことが難しいのではないか？ Git Repository と連携が可能です SageMaker Studio への移行 が可能です これらの懸念の大元にあるのは、「一回きりの利用には良いが、継続して開発する環境としては不十分ではないか？」という観点です。勉強から始めて、せっかくなら、作った環境や成果物を今後も活用したいという要求に対して、SageMaker Studio Lab では上記のように機能を提供しています。さらに、SageMaker Studio Lab では作成した Notebook を AWS の大きな計算機リソースを活用してバッチジョブ化するための機能である Notebook Jobs という機能を提供しています（リンクは SageMaker のものですが同じボタンが SageMaker Studio Lab にもあるとお考えください）。こちらはAWSアカウントを取得する必要があり、SageMakerの利用に伴う料金が発生する点に注意が必要です。重要なことは、SageMaker Studio Lab が提供する計算機リソースを越えて、学習や推論を実行したい場合にも選択肢が提供されていることです。 SageMaker Studio Lab を使えば、初級レベルの機械学習の勉強を超えてご活用いただけそうだとイメージを持っていただければ嬉しいです。それでは、本題の SageMaker Studio Lab で 日本語 LLM を Fine-Tuning するお話に入っていきます。本ブログでは、 こちらのクイズのブログ に倣って、OpenCALM をクイズに回答する精度が向上するように Fine-Tuning していきます。 SageMaker Studio Lab で日本語 LLM OpenCALM を動かす準備 以降の内容では、SageMaker Studio Lab が持つ機能、つまり無料の範囲内でのお話となります。先述の Notebook Jobs は利用しません。NoteBoo Jobs の利用に関しては別途 Blog を公開予定です。また、以降を読み進めていただく上で、SageMaker Studio Lab のアカウントを取得いただいておくとスムーズです。取得方法は こちら です。このブログの実装は こちら のブログを参考にしています。特に、実装部分は以下を参考にしています。併せてご参考くださいませ。 https://huggingface.co/cyberagent/open-calm-7b https://github.com/aws-samples/aws-ml-jp/tree/main/tasks/generative-ai/text-to-text/fine-tuning/instruction-tuning/Transformers SageMaker Studio Lab にログインしたら、GPU を選択、 Start runtime をクリックてください。初回実行の場合、Mobile Number の登録と SMS 確認が必要な場合があります。日本の電話番号にて Mobile Number のチェックがうまくいかない場合は、Mobile Number の入力時に日本 +81 を選択いただき、電話番号の先頭 0 を除いて入力してみてください。 その後、ロボットでないことをチェックする画面を通過してください。SageMaker Studio Lab はご好評いただいており、GPU が確保できない場合がございます。その場合は複数回お試しください。 作業用のディレクトリを作成しましょう。ディレクトリ名は llm-lora-challenge とします。左のメニューにて右クリック、New Folder を選択し、llm-lora-challenge ディレクトリを作成します。 以降、全ての作業はこの llm-lora-challenge ディレクトリ以下で実施します。 必要なライブラリをインストールしていきましょう。2 つの手段があります。ここでは Conda 環境を作成し、可搬性を高める手順 (以下の 1 つ目の方法) を取ります。default 環境を複数の目的で共有して使うとライブラリのバージョン衝突などにより作業しにくくなることがありますが、それを防ぐ効果もあります。 個別の Conda 環境を作成しllm_finetuning.yml を作成し、GUI から Build Conda Environment を実行する llm_finetuning という名前の conda 環境を構成する (参考) default の Conda 環境にライブラリをインストールする requirements.txt を作成し、notebook のセルから pip install を実行する requirements.txt を作成し、terminal を立ち上げ、default に Conda 環境をスイッチした後、pip install を terminal から実行する 以下のように llm_finetuning.yml を作成します。 name: llm_finetuning dependencies: - python=3.10 - deepspeed - pip - pip: - git+https://github.com/huggingface/peft.git@207d2908650f3f4f3ba0e21d243c1b2aee66e72d - bitsandbytes==0.39.0 - accelerate==0.20.3 - transformers==4.30.1 - tokenizers==0.13.3 - pynvml==11.4.1 - protobuf==3.20.2 - scipy - optimum - appdirs - loralib - black - black[jupyter] - datasets - fire - sentencepiece - evaluate - einops - ipykernel 作成した llm_finetuning.yml を右クリックしBuild Conda Environment をクリック、確認画面で OK をクリックします。 terminal が起動され、install が開始されます。 以下が表示されれば完了です。 左上のプラスボタンから Launcher を起動して、conda 環境が作成されたか確認してみましょう。 Notebook の部分に作成した llm_finetuning:Python が表示されていれば成功です。 以降の実行は全て llm_finetuning 環境を利用します。Launcher 画面から llm_finetuning:Python をクリックし、ノートブックを開いたら右上の kernel の表示が llm_finetuning:Python になっていることを確認してください。もしなっていない場合は、そちらをクリックし、下記画面のように Select Kernel から llm_finetuning:Python を選択してください。 最終的な構成を先に示します。以降の手順にて作成いただいたり、ダウンロードしたり、実行によって生成されたりするものを含んでいます。 model/ Fine-Tuning を実行すると作成され、モデルファイルが保存される llm_finetuning.yml 本ブログで使用する llm_finetuning の Conda 環境を作成するためのファイル data/aio_02_train.jsonl ダウンロードされる Fine-Tuning 用ファイル data/aio_02_train_formatted.jsonl Fine-Tuning に利用しやすいようにフォーマットしたファイル templates/simple_qa_ja.json プロンプトテンプレート OpenCALM_inf.ipynb 本ブログで作成する推論用の Notebook ファイル OpenCALM_format.ipynb 本ブログで作成するクイズデータを Fine-Tuning 用にフォーマットする Notebook ファイル OpenCALM_finetune.ipynb 本ブログで作成する Fine-Tuning 用の Notebook ファイル OpenCALM_finetuned_inf.ipynb 本ブログで作成する Fine-Tuning 後のモデルを用いて推論する Notebook ファイル SageMaker Studio Lab で OpenCALM の推論を呼び出す ここでは、Fine-Tuning 前の OpenCALM モデルがどの程度クイズに回答できるか確認してみましょう。新規に ipynb ファイル OpenCALM_inf.ipynb を作成し、以下のソースコードを実行してみてください。OpenCALM は HuggingFace Transformers ライブラリから利用する事ができます。初回はモデルのダウンロードが走る分時間がかかります。2 回目以降はダウンロード済みのモデルを利用するため動作が速くなります。 model_name に以下を指定 (パラメータ数が小さい順に記載) することで、OpenCALM のパラメータ数が異なるモデルを使用する事ができます。いろいろ変えてみて回答がどうなるか確認してみると面白いかもしれません。 cyberagent/open-calm-small cyberagent/open-calm-medium cyberagent/open-calm-large cyberagent/open-calm-1b cyberagent/open-calm-3b cyberagent/open-calm-7b import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name = 'cyberagent/open-calm-1b' model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto", torch_dtype=torch.float16, cache_dir="/tmp/model_cache/") tokenizer = AutoTokenizer.from_pretrained(model_name) inputs = tokenizer("映画『ウエスト・サイド物語』に登場する2つの少年グループといえば、シャーク団と何団?答えは「", return_tensors="pt").to(model.device) with torch.no_grad(): tokens = model.generate( **inputs, max_new_tokens=64, do_sample=True, temperature=0.7, top_p=0.9, repetition_penalty=1.05, pad_token_id=tokenizer.pad_token_id, ) output = tokenizer.decode(tokens[0], skip_special_tokens=True) print(f'{model_name}:{output}') もし、以下のエラーが出た場合、SageMaker Studio Lab が CPU モードで実行されている可能性があります。このブログのコードは GPU モードでのみ動作します。一度 ログアウトいただき、GPU モードに切り替えて再度お試しください。 RuntimeError: "LayerNormKernelImpl" not implemented for 'Half' LLM の出力は確率的要素があるため必ずしも同じになるとは限りません。以下の結果は何か回答しようとはしているものの、正しくない答えが返ってきています。 cyberagent/open-calm-1b:映画『ウエスト・サイド物語』に登場する2つの少年グループといえば、シャーク団と何団?答えは「ダンシングロッド」です。 少年たちの友情や恋心が描かれたミュージカルは老若男女問わず人気で、『美女か野獣』(1992)から現在まで数多くの映画が製作されてきました。『ウェストミンスター寺院の鐘の音が聞こえるまで』『ヘアスプレー』、『ラブアクチュアリー』、そして今世紀最大のヒット作となったのが ここで、注意が必要なのは、ダウンロードされるモデルのファイルサイズです。モデル名を見てみましょう。 1b, 3b, 7b とあるモデル名はそれぞれのパラメータ数の規模を表しています。b は Billion = 10 億であり、7b は 70 億パラメータ規模のモデルであることがわかります。このモデルファイルは 10 GB を越えており、SageMaker Studio Lab で永続化 (Stop Runtime しても残る) 領域に保存してしまうと容量を圧迫してしまいます。今後継続的に開発に利用することを考えると Conda 環境の保存などに利用するためにこの領域は極力空けておきたいですよね。そこで、cache_dir に /tmp/model_cache/ を指定することで対策しています。 AutoModelForCausalLM.from_pretrained メソッドを cyberagent/open-calm-7b を指定して実行した場合、初回にかかる時間は数分程度でした。Start Runtime する度に 1 度だけかかる時間としては許容範囲ではないでしょうか。 SageMaker Studio Lab で OpenCALM を LoRA によって Fine-Tuning する ここでは OpenCALM のクイズ回答精度を向上するために必要な Fine-Tuning 用のデータを準備します。 こちらのブログ に沿う形で、クイズデータを Fine-Tuning 用のフォーマットに変換して保存します。新規に OpenCALM_format.ipynb を作成し、以下のソースコードをセルに転載し実行してみてください。data/aio_02_train_formatted.jsonl にフォーマット済みクイズデータが保存されます。 !wget -P data https://jaqket.s3.ap-northeast-1.amazonaws.com/data/aio_02/aio_02_train.jsonl # Convet .jsonl to .json import pandas as pd df = pd.read_json("data/aio_02_train.jsonl", orient="records", lines=True) df = df.rename(columns={"question": "instruction", "answers": "output"}) df = df[["instruction", "output"]] df["output"] = df["output"].apply(lambda x: f"{x[0]}」") df["input"] = "" print(df.shape) df.to_json( "data/aio_02_train_formatted.jsonl", orient="records", force_ascii=False, lines=True ) df.head(2) 作成されたデータを確認してみましょう。クイズデータのため、質問 (instruciton 列) と回答 (output 列) というペアでデータが作成されている事がわかります。 次に OpenCALM にクイズ回答用の学習をする準備をします。プロンプトテンプレートファイルを用意します。このテンプレートは OpenCALM に学習データを入力するときのテンプレートになります。以下の作業を実施してください。 templates ディレクトリを作成 こちらの template をダウンロード SageMaker Studio Lab の templates ディレクトリに配置 (ファイルはドラッグ&ドロップできます) 以下が template の中身です。 instruction に続き、 答えは「 をプロンプトとして含めることで回答を促しています。実は、先述の推論を試してみたときに、OpenCALM に 答えは「 と入力することで回答させようとしていた部分をテンプレートとして採用しています。 {input} を使用する場合とそうでない場合がある事がわかります。 {instruction} の部分はクイズのデータサンプルごとに異なります。一方で {input} はプロンプトを別途追加したい場合に利用できます。 {input} はこのブログでは使用しません。 OpenCALM_finetune.ipynb ファイルを作成してください。独自のユーティリティクラス Prompter がこのテンプレートファイルを読み、テンプレートに沿った形で OpenCALM にわたす役割です。 Prompter をダウンロードしコードをコピー&ペーストでセルに貼り付けてください。.py ファイルとして別途モジュールを import する形でも構いません。 最後に OpenCALM を Fine-Tuning するコードを準備します。 こちらの Fine-Tuning のコード をダウンロードしコードをコピー＆ペーストでセルに貼り付けてください。セルに貼り付ける際に以下は不要のためコメントアウトしましょう。 ... # from utils.prompter import Prompter ... # if __name__ == "**main**": # fire.Fire(train) .py ファイルとして別途モジュール import する形でも構いません。 Fine-Tuning では学習済みモデルを追加のデータを用いて再学習することで精度向上を図ります。パラメータをランダム値などにより初期化した状態から学習することに比べ、学習済みモデルのパラメータを初期値に利用した状態で学習を進める Fine-Tuning には学習のコスト効率を高めながらモデルの精度を高める狙いがあります。しかし、工夫無しに Fine-Tuning してしまうと全てのパラメータを更新対象にしてしまいコスト効率が悪くなったり、学習済みモデルが獲得した一般的な概念を失ってしまう壊滅的忘却と呼ばれる現象が発生するリスクがあります。そこで、少ない更新パラメータ数でコスト効率よく精度を向上させる研究分野や手法群を指す PEFT (Parameter-Efficient Fine Tuning) が生まれました。実務的には PEFT が実装されたライブラリを利用することでその恩恵を受ける事ができます。PEFT は hugging face library に実装があります。本ブログではこの内 LoRA ( LOW-RANK ADAPTATION OF LARGE LANGUAGE MODELS ) に挑戦します。LoRA は学習済みモデルのパラメータはそのままに、新たに追加したパラメータ (Neural Network の重み) に対し更新する手法です。この手法は以下の利点により注目されています。 更新対象パラメータ数の削減によりメモリ量と学習時間を短くできる場合がある LoRA 部分だけを切り替えることにより、タスクに特化して再学習した Fine-Tuned モデルを効率よく活用できる場合がある Fine-Tuning のソースコードのうち LoRA らしさが表れている部分に着目して読んでみましょう。実際のソースコードは toknizer や学習途中結果の保存などの実装が含まれていますが、LoRA のポイントは以下の通りです。 AutoModelForCausalLM.from_pretrained により LoRA の元になる学習済みモデルを読み込む LoraConfig にて、 LoRA のハイパーパラメータ を設定する で取得した model と 2. で設定した config を get_peft_model に渡すことにより LoRA 用の model を取得する で取得した model オブジェクトを transformers.Trainer に渡し trainer を取得する の trainer を使用し、 trainer.train を呼び出す また、 AutoModelForCausalLM.from_pretrained に cache_dir="/tmp/model_cache/" が指定されているため、LoRA に渡した学習済みモデルファイルは SageMaker Studio Lab では永続化されない領域に保存されます。また、 output_dir にディレクトリ名を指定すると永続化される領域に LoRA のファイルが保存されます。これによって SageMaker Studio Lab の永続化領域を圧迫することなく LoRA を実行できます。 以上で準備は終了です。さあ、Fine-Tuning を実行してみましょう！ 以下のコードをセルに貼り付けて実行してみてください。メモリ不足になる場合は他の Notebook を停止して閉じておきましょう。1b のモデルを学習する場合は 10 – 20 分、7b のモデルを学習する場合は 2 時間程度を要します。まずは動作させてみたいという場合は model_name を cyberagent/open-calm-1b などのパラメータ数の小さいモデルで試してみてください。本ブログでは 1b のモデルを試してみます。 model_name = "cyberagent/open-calm-1b" model_name_base = model_name.split("/")[-1] hyperparameters = { "base_model": model_name, "pad_token_id": 1, "data_path": "data/aio_02_train_formatted.jsonl", "num_epochs": 1, # default 3 "cutoff_len": 256, "group_by_length": False, "output_dir": "model", "lora_target_modules": ['query_key_value'], "lora_r": 16, "batch_size": 32, "micro_batch_size": 4, "prompt_template_name": "simple_qa_ja", } train(**hyperparameters) model_name に OpenCALM を指定しています。また、以下が大きいほど学習に時間を要しますが精度が改善する可能性があります。大きくし続ければ必ず精度が改善するわけではないため注意が必要です。 num_epochs : 学習サンプルを 1 巡する回数を表すハイパーパラメータ lora_r : 行列ランクと呼ばれるLoRA にて更新対象にするパラメータ数に依存するハイパーパラメータ 初めはこれらを小さくして、パラメータ数の小さいモデルで LoRA を実行し、正常に動作するかを確認してみると良いでしょう。 以下のような Epoch に対する進捗のログが出力されれば学習が実行されています。指定した num_epochs にログの Epoch が到達したら学習は完了です。 Training Alpaca-LoRA model with params: base_model: cyberagent/open-calm-1b data_path: data/aio_02_train_formatted.jsonl output_dir: model batch_size: 32 ・・・ [XXXXX/XXXXXX X:XX:XX < 00:00, X.XX it/s, Epoch 1.00/1] もし、学習時間が長く、SageMaker Studio Lab で実行できる GPU 利用時間制限を越えた場合でも、学習途中の LoRA ファイルが model ディレクトリに保存されているため、後で学習した LoRA ファイルを用いて学習を再実行したり、推論に利用したりする事が可能です。 SageMaker Studio Lab で Fine-Tuning した OpenCALM を使って推論する ここまでの作業により、LoRA により Fine-Tuning した OpenCALM モデルがクイズに上手に回答できる事が期待されます。早速、効果を確認していきましょう。新規に OpenCALM_finetuned_inf.ipynb を作成しましょう。 推論のサンプルコード を参考に実装します。このサンプルコードは SageMaker Inference Endpoint にホストする用のコードになっています。このブログでは SageMaker Inference Endpoint は使用しませんので、以下の手順に従って必要なコードだけをセルに貼り付けていきます。 OpenCALM_finetuned_inf.ipynb ファイルを作成してください。LoRA による Fine-Tuning 時に利用した Prompter クラスが必要です。同様に、 Prompter をダウンロードしセルに貼り付けてください。.py ファイルとして別途モジュール import する形でも構いません。 推論のサンプルコード から import に関する部分を抜き出しセルに貼り付けます。 from utils.prompter import Prompter は Prompter をセルに貼り付けている場合は不要です。 import os import sys import json from typing import Dict import torch import transformers from peft import PeftModel from transformers import GenerationConfig, AutoModelForCausalLM, AutoTokenizer, StoppingCriteria, StoppingCriteriaList, BitsAndBytesConfig import deepspeed StopOnTokens クラスをセルに貼り付けます。後ほどテキストを生成する際に生成の停止条件を与えるクラスです。 class StopOnTokens(StoppingCriteria): def __init__(self, stop_ids): self.stop_ids = stop_ids def __call__(self, input_ids: torch.LongTensor, scores: torch.FloatTensor, **kwargs) -> bool: for stop_id in self.stop_ids: if input_ids[0][-1] == stop_id: return True return False prompter, tokenizer, model を生成します。以下のソースコードをセルに貼り付けてください。 base_model = "cyberagent/open-calm-1b" device = "cuda" prompt_template = "simple_qa_ja" lora_weights = "model" prompter = Prompter(prompt_template) tokenizer = AutoTokenizer.from_pretrained(base_model) model = AutoModelForCausalLM.from_pretrained( base_model, load_in_8bit=False, torch_dtype=torch.float16, device_map="auto", cache_dir="/tmp/model_cache/" ) print("Loading Lora Weight") model = PeftModel.from_pretrained( model, lora_weights, torch_dtype=torch.float16, ) model.model_parallel = False if torch.cuda.device_count() > 1: model.is_parallelizable = True model.model_parallel = True 最後に、prompt を生成し、テキストを生成するパラメータを設定したら、テキスト生成するコードをセルに貼り付けてください。 instruction = "映画『ウエスト・サイド物語』に登場する2つの少年グループといえば、シャーク団と何団?" input = "" max_new_tokens = 32 stop_ids = [1, 0] prompt = prompter.generate_prompt(instruction, input) inputs = tokenizer( prompt, add_special_tokens=False, return_token_type_ids=False, return_tensors="pt" ).to(device) generation_config = GenerationConfig( max_new_tokens=max_new_tokens, return_dict_in_generate=True, output_scores=True, temperature=0.1, do_sample=False, num_beams=5, pad_token_id=1, bos_token_id=0, eos_token_id=0 ) with torch.no_grad(): generation_output = model.generate( **inputs, generation_config=generation_config, stopping_criteria=StoppingCriteriaList([StopOnTokens(stop_ids)]), ) s = generation_output.sequences[0, inputs['input_ids'].size(1):] output = tokenizer.decode(s, skip_special_tokens=True) output 推論のソースコードのうち LoRA らしさが表れている部分に着目して読んでみましょう。実際のソースコードは toknizer などの実装が含まれていますが、LoRA のポイントは以下の通りです。 AutoModelForCausalLM.from_pretrained により LoRA の元になる学習済みモデルを読み込む の model と lora_weights = “model“ を PeftModel.from_pretrained に渡し model を取得する の model により model.generate を呼び出す LoRA の保存先が model ディレクトリであったことを思い出してみましょう。Fine-Tuning 時と同様に、 AutoModelForCausalLM.from_pretrained に cache_dir="/tmp/model_cache/" が指定されているため、SageMaker Studio Lab の永続化領域を圧迫することなく LoRA を用いたモデルの推論を実行できます。 さあ、OpenCALM_finetuned_inf.ipynb を実行してみましょう。検証時の結果では、以下のように正しい回答が返ってきました。LLM の出力は確率要素があるため本ブログと同じ回答が得られない場合があることに注意が必要です。 ここで、興味深い事は Fine-Tuning 用ファイルには類似のクイズは含まれていなかった事です。Fine-Tuning に用いたクイズデータを確認したところ、ウェストサイドストーリーに関するクイズは以下のみでした。 {"instruction":"ミュージカル「ウエストサイド・ストーリー」の作曲で知られる音楽家は誰でしょう?","output":"レナード・バーンスタイン」","input":""} 元となる OpenCALM の学習データにはウェストサイドストーリーに関するテキストが含まれており、クイズ回答に特化した Fine-Tuning によって正しい回答を得られるようになった可能性があります。 発展 本ブログを参考に以下にチャレンジしてみましょう。 cyberagent/open-calm-7b を試す 本ブログのコードは 1b のモデルを試しましたが、作者の動作確認では 7b のモデルまで実行できることを確認しています。モデルの大きさによって回答精度がどう変わってくるのか、処理時間はどうか、是非お試しください。 SageMaker Studio への移行 SageMaker Studio Lab で作成したコードを SageMaker Studio Notebook で実行してみましょう。より多くの計算機リソースや機械学習ワークロードを実現する多くの機能と連携できるようになります。 OpenCALM 以外の日本語 LLM を試す Hugging Face に実装されているモデルであれば本ブログの実装を参考にすることができます。例えば、 rinna/japanese-gpt-neox-3.6b · Hugging Face を利用できるように改修してみましょう。rinna モデルの場合はどのようなプロンプトを与えると良いか試してみましょう。もしかしたら、OpenCALM とは違う特性があるかもしれません。 最後に 本ブログで解説した内容は SageMaker Studio Notebook, SageMaker Notebook Instance でも同様に実行可能です。もし、皆様が既に GPU を搭載した計算機環境をお持ちであれば、Jupyter notebook や Jupyter Lab を導入することで同様に実行可能です。生成系 AI はここ数年で実務レベルで活用できるユースケースが多岐に渡るほどの進化を遂げました。トップダウンで検証することになったご担当者様やボトムアップで面白い技術要素としてスキルを獲得しようとしている方まで様々かと思います。新しい技術を検証するとき、社会課題、社内課題ともにどんな課題がこの技術で解決できるかを机上で考える事は重要です。また、皆様の抱える課題のうち優先順位の高い費用対効果の高いテーマを選択することも重要です。同時に、予算や体制が小さな状況でも動くものを作り、その技術を通して何がどう動くのか体験することも重要だと考えています。このブログを通じて、日本語 LLM の OSS がどのように動作するのか、何に使えそうなのかを体験いただき、日本語 LLM の OSS が持つ可能性を感じていただければ大変嬉しく思います。 著者 中島 佑樹 西日本のお客様をメインで担当するソリューションアーキテクト。社会人博士を修了したことをきっかけに AIML を得意分野としている。 システム一般のテーマや Amazon Bedrock を用いた生成系 AI のシステム開発、Amazon SageMaker Studio Lab を用いた AIML への入門まで幅広く活動。

AWS は、2023 年 11 月 15 日 ( 水 ) 〜 2023 年 11 月 17 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2023 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4615 )。AWS ブースでは「Create. Deliver. Monetize.」をテーマに、「コンテンツ制作」、「放送」、「メディアサプライチェーン & アーカイブ」、「Direct-to-Consumer & ストリーミング」、「データサイエンス & AI/ML」におけるクラウドを利用した重要なワークロードの運用をサポートする技術とソリューションを、パートナー 9 社とともにご紹介します。本ブログでは、AWS ブースで行われるブースセミナーの中から 5 つのステージ特別プログラムをご紹介させていただきます。 Inter BEE とは Inter BEE とは、日本随一の音と映像と通信のプロフェッショナル展として、コンテンツビジネスに関わる最新のイノベーションが国内外から集まる国際展示会です。アフターコロナ時代におけるメディア産業の新たなユーザエクスペリエンスを提示する展示会として、「コンテンツ」を中核に位置づけ、コンテンツを「つくる (制作) 」「おくる (伝送) 」「うける (体験) 」の技術要素を網羅した「メディア総合イベント」に変容することを目指し、開催します。 開催期間は、幕張メッセで 2023 年 11 月 15 日 ( 水 ) 〜 2023 年 11 月 17 日 ( 金 ) 、オンライン会場で 2023 年 11 月 6 日 ( 月 ) 〜 2023 年 12 月 15 日 ( 金 ) となっています。 下のリンクから登録を行うことで、無料で参加することができます。 登録はこちらから ステージ特別プログラムのご紹介 [Create.] バーチャルプロダクションにおける AWS 活用 – 制作から撮影まで 株式会社スタジオブロス 上津原一利 様 11 月 15 日 ( 水 ) 12:20-13:00 バーチャルプロダクションの制作、確認、撮影など、様々なシーンでクラウド活用することによって各作業を効率的に進めることができます。スタジオブロスで実際に行ったクラウド活用の事例や、活用によって広がる可能性などお伝えいたします。 Create. Deliver. Monetize. Trends & Customer stories in the M&E Industry Amazon Web Services Shad Hashmi 11 月 15 日 ( 水 ) 16:30-17:10 メディア・エンターテインメント業界は革新の波に直面しており、AWS はコンテンツ制作、メディアサプライチェーン & アーカイブ、放送、Direct-to-Consumer とストリーミング、データサイエンス & 分析、5 つの分野でお客様のイノベーションを支えています。Create. Deliver. Monetize. の視点から、海外のメディア&エンターテインメント業界のトレンドと AWS を用いたお客様事例を紹介します。 [Create.] 目指せ! 収録→編集→アーカイブまで素材一元管理 TBS テレビコンテンツ制作局のこれまでの取り組み 株式会社 TBS テレビ 吉橋 隆雄 様 11 月 16 日 ( 木 ) 15:40-16:20 大量の過去の収録テープ素材を前にした放送局の制作部門スタッフが「円滑に過去素材を再利用できる環境の構築」と「働き方改革にともなう諸業務の効率化」を目的に、社内各部署を巻き込んで説得し、映像のデータ化 ⇒ クラウド化 ⇒ クラウドオフライン編集に挑戦するまでの道のりと今後の課題と展望について、関係者一同と共にフランクにお話します。 [Monetize.] ABEMA ライブイベント配信におけるパーソナライズ広告挿入について 株式会社 AbemaTV 古川 俊太 様 11 月 16 日 ( 木 ) 16:30-17:10 ABEMA ではリニア配信とビデオ配信に加えて、スポーツなどの試合に対応できるように新しく「ライブイベント」という放送形態を導入しました。 ライブイベントという放送形態を新規で導入したことにより、広告の配信システムも新規で開発する必要がありました。 今回、AWS MediaTailor をパーソナライズ基盤として選定しましたが、その経緯と現状、展望についてお話しいたします。 [Deliver.] NeSTREAM LIVE AWS を活用した DOLBY ATMOS での高臨場感ライブ配信事例の紹介 メモリーテック株式会社 棟元 裕介 様、株式会社クープ 近藤 貴春 様、Dolby Japan 株式会社 萩谷 太郎 様 11 月 17 日 ( 金 ) 12:20-13:00 近年、音楽ライブにおいて、Dolby Atmos での劇場上映や、パッケージ販売・配信する事例が増えています。 Dolby Atmos はバーチャライザー技術と併用することで、ホームシアターやヘッドホンなどの様々な民生機器で使用することができます。 これまでの制作事例を踏まえ、今後増えていくことが予想される Dolby Atmos でライブ配信の仕組みなどについてご紹介します。 ブースセミナーのプログラム こちらは、AWS のブースで行うセミナーのプログラムです。今回ご紹介したステージ特別プログラムの他にも、パートナーセッションや AWS ブース紹介が行われます。 終わりに 今回は、Inter BEE 2023 の AWS ブースセミナーをご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2023 の 公式サイト からご確認ください。 皆様にお会いできるのを楽しみにしています！ 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは Solutions Architect 濵野が担当しました。

はじめに 今日の組織は、地域・業界、またビジネスニーズによって異なる、プライバシーや規制の課題に直面しています。これらのプライバシー規制を遵守するために、コンタクトセンターの管理者は、コンタクトセンター内で使用される機密リソースに対する最小アクセス権限の実装を頻繁に求められます。 Amazon Connect の タグベースのアクセスコントロール により、Amazon Connect 管理コンソール内で Amazon Connect リソースに対するより細かいアクセスコントロールを有効にできるようになりました。タグは Key:Value のペアで、役割、チーム、事業部門、その他の基準によって、Amazon Connect リソースへのアクセスを管理、検索、フィルタリング、制御することができます。一例をあげると、タグベースのアクセスコントロールによって、ある管理者にすべてのエージェントを完全に管理するアクセス権を付与しつつ、別の管理者ロールでは管理者が所属するビジネスユニット内のエージェントの表示と管理のみに制限することができます。 この記事では、まず Amazon Connect 管理コンソールによるリソースタグ付けをサポートするようになった追加の Amazon Connect リソースについて説明します。その後、架空の会社 Octank 社の管理者が特定の Amazon Connect リソースにタグを設定し、タグベースのアクセスコントロールでそれらのリソースへの最小権限でのアクセスを設定する方法を示します。 このソリューションは、コンタクトセンターの管理者、マネージャー、コンプライアンス関係者、ビジネスプロセスアウトソーサー (BPO) などの第三者に以下のような利点をもたらします。 ビジネスニーズに基づいて、リソースを論理的にグループ分けした並べ替えやフィルタリング 機密情報 (PII など) の意図しない利害関係者への共有を防止 ソリューション概要 このソリューションを展開するため、以下の手順を実施します。 アクセスコントロールタグおよびリソースタグを特定のリソースに設定する リソースタグとアクセスコントロールタグを自動的に設定する リソースタグとタグベースのアクセスコントロールを設定する前に、Octank 社の社内情報ガバナンスと業務要件を以下に示します。 ユーザー、ルーティングプロファイル、キューへのアクセスを制限する、3つのコンタクトセンター管理者ロールを作成する Country:Argentina のタグだけが付いたリソースにアクセスできるコンタクトセンターロール BPO:Octank のタグだけが付いたリソースにアクセスできるコンタクトセンターロール Country:Argentina および BPO:Octank 両方のタグが付いたリソースにアクセスできるコンタクトセンターロール 前提条件 このチュートリアルは、以下のリソースを理解し、アクセスできることを前提としています。 Amazon Connect の管理者アクセス権を持つ AWS アカウント 作成 済みのAmazon Connect インスタンス 管理者権限 (Admin) の セキュリティプロファイル を持つ Amazon Connect ユーザー AWS リソースのタグ付け に関する基本的な知識 タグ付けをサポートする Amazon Connect のリソース Amazon Connect のリソースにタグを付ける 既存の機能に加えて、Amazon Connect 管理コンソール内で設定するリソースにもタグを付けることができるようになりました。次の表は、管理コンソール内でタグをサポートするようになったリソースと、 API/CLI レベル でタグをサポートしているリソースを示しています。 Amazon Connect リソース Amazon Connect 管理コンソール内でのタグ付け可否 API/CLI 経由のタグ付け可否 User Management 可 可 Security Profiles 可 可 Routing Profiles 可 可 Queues 可 可 Flows 不可 可 Hierarchy Groups 不可 可 Hours of Operation 不可 可 Quick Connects 不可 可 Prompts 不可 可 Instances 不可 可 Task Templates 不可 可 Phone Numbers 不可 可 Traffic Distribution Groups 不可 可 Agent Status 不可 可 アクセスコントロールタグとリソースタグを設定するチュートリアル 最初のセクションでは、最初に アクセスコントロールタグ と リソースタグ を使用してセキュリティプロファイルを設定することで、Amazon Connect 管理コンソール内でリソースタグを設定する方法について説明します。次のセクションでは、ユーザー、キュー、ルーティングプロファイルのリソースタグを設定する手順について説明します。最後のセクションでは、サンプルユーザーを使用してアクセス制御されるさまざまなセキュリティプロファイルを変更およびテストして、より細かいアクセスコントロールを検証する方法について説明します。 アクセスコントロールタグとセキュリティープロファイルの設定 このセクションでは、より細かいアクセスコントロールを持つ 3 つのセキュリティプロファイルを作成して、Amazon Connect 管理コンソール内でセキュリティプロファイルに対してアクセスコントロールタグとリソースタグの両方を設定する方法について説明します。 Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ユーザー から セキュリティプロファイル を選択します 新しいセキュリティプロファイルの追加 を選択します 名前 と 説明 を入力します。ここではセキュリティプロファイルの名前を tagsecurityprofile1 とします。 セキュリティプロファイルのアクセス権限を選択します。下記画像のようにルーティングプロファイル、キュー、ユーザー、セキュリティプロファイルの各行で「すべて」を選択します 詳細オプションの表示 をクリックし、展開します アクセスコントロール の項目で、 リソース にユーザー、ルーティングプロファイル、キューを選択、 タグ のキーに Country 、値に Argentina を入力し、追加をクリックします タグの項目で、任意のリソースタグを入力し、追加をクリックします（画像の例では Createdby:ABC と入力) 保存をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります 同様の手順で、セキュリティプロファイル tagsecurityprofile2 と tagsecurityprofile3 を以下の表に記載のプロファイルの 名前 、アクセス権限、アクセスコントロール リソース 、アクセスコントロール タグ 、リソース タグ の通り作成します セキュリティプロファイルの名前 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ リソースタグ tagsecurityprofile1 ルーティングプロファイル、キュー、ユーザー – すべて ユーザー、ルーティングプロファイル、キュー Country:Argentina Createdby: ABC tagsecurityprofile2 ルーティングプロファイル、キュー、ユーザー – すべて ユーザー、ルーティングプロファイル、キュー BPO:Octank Createdby: ABC tagsecurityprofile3 ルーティングプロファイル、キュー、ユーザー – すべて ユーザー、ルーティングプロファイル、キュー Country:Argentina, BPO:Octank Createdby: ABC 以上が完了すると、次のアクセスコントロールタグが設定済みの 3 つのセキュリティプロファイルが作成されます。 アクセスコントロールタグ Country:Argentina が設定された tagsecurityprofile1 アクセスコントロールタグ BPO:Octank が設定された tagsecurityprofile2 アクセスコントロールタグ Country:Argentina と BPO:Octank が設定された tagsecurityprofile3 これらのセキュリティプロファイルを使用して、Octank のデータガバナンスとビジネス要件を適用できます。これについては、ユーザー、キュー、ルーティングプロファイルのリソースタグを設定した後で説明します。 リソースタグとユーザーの設定 このセクションでは、Amazon Connect 管理コンソール内でユーザーを設定し、リソースタグを適用する方法について説明します。サブ管理者権限と詳細なアクセス制御を適用したユーザーを 1 人作成し、表示/管理する 3 つのエージェントを作成します。ログインに tagadmin 、 taguser1 、 taguser2 、 taguser3 という名前を付けます。最後に、ルーティングプロファイル、セキュリティプロファイル、リソースタグを以下のように設定します。 ログイン 名 姓 ルーティングプロファイル セキュリティプロファイル リソースタグ 1 リソースタグ 2 tagadmin Admin Tag Basic Routing Profile tagsecurityprofile1 taguser1 Test1 Tag Basic Routing Profile Agent Country:Argentina taguser2 Test2 Tag Basic Routing Profile Agent BPO:Octank taguser3 Test3 Tag Basic Routing Profile Agent Country:Argentina BPO:Octank Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ユーザー から ユーザー管理 を選択します 新しいユーザーの追加 を選択します ユーザーを手動で追加 を選択します 名 、 姓 、 ログイン 、 セキュリティプロファイル 、 ルーティングプロファイル を上記表のサンプルの通りに各ユーザーに設定します。別途、メールアドレスとパスワードを各ユーザーに設定する必要があります 管理者を作成する際はスキップできますが、エージェントを作成する際には次の手順が必要です。 詳細設定を表示 をクリックし、キーと値を上の表の例の通り入力、 追加 します 保存 をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります。 この手順を繰り返し、副管理者 ( tagadmin )および 3 つのエージェント( taguser1 , taguser2 , taguser3 )のアカウントを作成します 完了すると、tagadmin という名前の副管理者が 1 人と、次のリソースタグが設定された 3 人のエージェントが作成されます。 リソースタグ Country:Argentina が設定された taguser1 リソースタグ BPO:Octank が設定された taguser2 リソースタグ Country:Argentina と BPO:Octank が設定された taguser3 リソースタグとキューの設定 このセクションでは、Amazon Connect 管理コンソールでキューのリソースタグを設定する方法について説明します。 以下のように、稼働時間とリソースタグを含む tagqueue1 、 tagqueue2 、 tagqueue3 の 3 つのキューを作成します。 キューの名前 オペレーション時間 リソースタグ 1 リソースタグ 2 tagqueue1 Basic Hours Country:Argentina tagqueue2 Basic Hours BPO:Octank tagqueue3 Basic Hours Country:Argentina BPO:Octank Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ルーティング から キュー を選択します キューを追加 を選択します キューの 名前 (例: tagqueue1 ) 、 説明 を入力します。 オペレーション時間 は、Basic Hours を選択します 設定 から タグ の項目で、以下の画像のようにタグを入力し、 追加 します 保存をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります この手順を繰り返し、 tagqueue2 および tagqueue3 も作成します 上の手順が完了すると、以下の通りリソースタグが設定された 3 つのキューが作成されます。 リソースタグ Country:Argentina が設定された tagqueue1 リソースタグ BPO:Octank が設定された tagqueue2 リソースタグ Country:Argentina と BPO:Octank が設定された tagqueue3 ルーティングプロファイルとリソースタグの設定 このセクションでは、Amazon Connect 管理コンソールでルーティングプロファイルのリソースタグを設定する方法について説明します。 次に、以下に説明するように、 音声チャネル 、 デフォルトのアウトバウンドキュー 、およびリソース タグ を使用して、 tagroutingprofile1 、 tagroutingprofile2 、 tagroutingprofile3 という名前の 3 つのルーティングプロファイルを作成します。 ルーティングプロファイルの名前 選択するチャネル デフォルトのアウトバウンドキュー リソースタグ 1 リソースタグ 2 tagroutingprofile1 音声 BasicQueue Country:Argentina tagroutingprofile2 音声 BasicQueue BPO:Octank tagroutingprofile3 音声 BasicQueue Country:Argentina BPO:Octank Amazon Connect 管理コンソールに管理者権限のセキュリティプロファイルを持つユーザーでサインインします ユーザー から ルーティングプロファイル を選択します ルーティングプロファイルを追加 を選択します ルーティングプロファイルの 名前 (例: tagroutingprofile1 )と 説明 を入力します 設定 セクション内の チャネルの設定 で音声を選択、 キュー のセクションは変更せず、 デフォルトのアウトバウンドキュー で BasicQueue を選択します タグについては、以下のようにキー、値の組み合わせを設定し、 追加 をクリックします 保存 をクリックします。保存ボタンが無効な場合、必要なセキュリティプロファイルの権限が割り当てられていない Amazon Connect アカウントでログインしている可能性があります この手順を繰り返し、 tagroutingprofile2 および tagroutingprofile3 も作成します 完了すると、次のリソースタグの付いた 3 つのルーティングプロファイルが作成されます。 リソースタグ Country:Argentina が設定された tagroutingprofile1 リソースタグ BPO:Octank が設定された tagroutingprofile2 リソースタグ Country:Argentina と BPO:Octank が設定された tagroutingprofile3 ここまででユーザー、キュー、ルーティングプロファイルのリソースタグを設定し、アクセス制御とリソースタグを使用してセキュリティプロファイルを設定しました。次のセクションで、サブ管理者の tagadmin が持つ詳細なアクセスを検証できます。 アクセスコントロールの確認 より細かいアクセスコントロールを確認する手順は以下の通りです。 ブラウザのシークレットモードを利用して、Amazon Connect 管理コンソールに作成した副管理者アカウント tagadmin でサインインします ユーザー から ユーザー管理 を選択します。キーがCountry、値がArgentinaのリソースタグを含んだユーザーだけが表示されます。具体的には、 taguser1 と taguser3 が表示されます ルーティング から キュー を選択します。キーがCountry、値がArgentinaのリソースタグを含んだキューだけが表示されます。今回は、 tagqueue1 と tagqueue3 が表示されます ユーザー から ルーティングプロファイル を選択します。キーがCountry、値がArgentinaのリソースタグを含んだキューだけが表示されます。今回は、 tagroutingprofile1 と tagroutingprofile3 が表示されます 補足 セキュリティプロファイルを作成、変更し、アクセス制御タグを追加すると、より制限が厳しくなります セキュリティプロファイルがユーザーに割り当てられるまで、アクセス制御タグは適用されません アクセスコントロールの変更と確認 次に、サブ管理者ユーザ ( tagadmin ) のセキュリティプロファイルを変更し、付与されたアクセス権を確認しましょう。手順は以下の通りです。 Amazon Connect 管理コンソールにサインインします ユーザー から ユーザー管理 を選択します ユーザー tagadmin を選択し、 編集 をクリックします ユーザー tagadmin のセキュリティプロファイル を、 tagsecurityprofile1 から tagsecurityprofile2 に変更します。ドロップダウンメニュー内に「アクセスコントロール: タグ」の表示を確認できます 保存 をクリックします 副管理者のアカウント(ユーザー tagadmin )でログインしているシークレットモードのウィンドウを再読み込みします。タグ BPO:Octank が含まれているユーザー、キュー、ルーティングプロファイルのみにアクセスできるはずです。つまり、ユーザー tagadmin から、ユーザー taguser2 と taguser3 、キュー tagqueue2 と tagqueue3 、ルーティングプロファイル tagrouringprofile2 と tagroutingprofile3 が確認できます 最後にユーザー tagadmin のセキュリティープロファイルを tagsecurityprofile2 から tagsecurityprofile3 に変更して、権限を確認します。タグ Country:Argentina と BPO:Octank の両方が付与されたユーザー、キュー、ルーティングプロファイルだけにアクセスできるはずです。ユーザー tagadmin からは、ユーザー taguser3 、キュー tagqueue3 とルーティングプロファイル tagroutingprofile3 のみが確認できます Amazon Connect API や SDK を利用したより詳細なアクセス制御の設定 Amazon Connect API を使用して、Amazon Connect リソースに対するより詳細なアクセス制御をプログラムで設定できます。 Create Security profile API によりリソースタグとアクセスコントロールタグを使用してセキュリティプロファイルを作成できます Create User API によりタグ付きのユーザーを作成できます Create Routing Profile API によりタグ付きのルーティングプロファイルを作成できます Create Queues API によりタグ付きのキューを作成できます クリーンアップ Amazon Connect 管理コンソールにログインし、このブログの手順で作成した ユーザーを削除 します このブログのハンズオンの為に Amazon Connect インスタンスをセットアップした場合は、Amazon Connect AWS コンソールにアクセスして Amazon Connect インスタンスを削除 できます 結論 このブログでは、Amazon Connect のリソースタグとアクセスコントロールタグを使用して Amazon Connect リソースへのきめ細かなアクセスコントロールを可能にする方法を説明しました。これにより Amazon Connect インスタンスの運用中に要件が変化したときに、チーム、ロール、またはその他の基準で複数のグループを作成し、さまざまな Amazon Connect リソースに対してより複雑なアクセスコントロール条件を表現することができます。 無料のオンラインイベント、AWS Contact Center Day もご覧ください。カスタマーサービスの未来、機械学習がどのように顧客とエージェントのエクスペリエンスを最適化できるかなどについて学ぶことができます。 今すぐ登録 ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 著者について Dilin Joy Dilin Joy は、 AWS のパートナーソリューションアーキテクトです。業界をリードするグローバルシステムインテグレーター (GSI) と協力してアーキテクチャに関するガイダンスを提供し、AWS で戦略的な業界ソリューションを構築できるよう支援しています。 Behrang KHAKISEDDIGH Behrang KHAKISEDDIGH は、 AWS のシニアパートナーソリューションアーキテクトです。業界をリードするグローバルシステムインテグレーター (GSI) と協力してアーキテクチャに関するガイダンスを提供し、AWS で戦略的な業界ソリューションを構築できるよう支援しています。 Mike Cairns Mike Cairns は、 AWS のパートナーソリューションアーキテクトです。業界をリードするグローバルシステムインテグレーター (GSI) と協力してアーキテクチャに関するガイダンスを提供し、AWS で戦略的な業界ソリューションを構築できるよう支援しています。 Tommy Grahams Tommy Graham は、 AWS の技術担当のシニアプロダクトマネージャーです。彼は顧客と協力し課題の解決策を見極め、データ主導の意思決定で業務を楽しんで推進しています。 追加のリソース Amazon Connect 概要 Amazon Connect でセキュリティプロファイルのより詳細なアクセス制御 (リソースタグを使用) が可能に Amazon Connectのリリースノート Amazon Connect 管理者ガイド Amazon Connectのパートナー タグベースのアクセス制御 Amazon Connect API Reference (英文) 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

Amazon Redshift は、クラウドにおけるフルマネージド型のペタバイト規模のデータウェアハウスサービスであり、他のどのクラウドデータウェアハウスよりも 最大 5 倍優れたコストパフォーマンス を実現し、追加費用なしですぐにパフォーマンスの革新的な向上を実現できます。 何万ものお客様が Amazon Redshift を使用して毎日エクサバイト単位のデータを処理し、分析ワークロードを強化しています。 この記事では、Amazon Redshift SYS モニタリングビューについて説明し、Amazon Redshift のワークロードとリソース使用量のモニタリングを簡素化する方法について説明します。 SYS モニタリングビューの概要 SYS モニタリングビューは Amazon Redshift のシステムビューで、プロビジョニングされたクラスターやサーバーレスワークグループのクエリとワークロードのリソース使用状況をモニタリングするために使用できます。 これらには次の利点があります: クエリの状態、パフォーマンス指標、クエリの種類を考慮して、機能の整合性に基づいて分類されています パフォーマンスのトラブルシューティングに役立つように、 planning_time 、 lock_wait_time 、 remote_read_io 、 local_read_io などの新しいパフォーマンスメトリクスを導入しました Redshift の オプティマイザで書き直されたクエリの代わりに、ユーザーが送信したクエリをログに記録することで、モニタリングビューの使いやすさが向上しています 少ないビューでより多くのトラブルシューティングメトリクスを提供できます プロビジョニングされたクラスターでもサーバーレスワークグループでも同じクエリを使用できるため、Amazon Redshift の統合的なモニタリングが可能になります では、いくつかのSYS モニタリングビューの機能と、それらをモニタリングにどのように使用できるかを見ていきましょう。 さまざまなクエリレベルのモニタリングメトリクスを統合 次の表は、複数のシステムテーブルとビューをクエリすることで得られるさまざまなメトリクスと情報を、一つのSYSモニタリングビューにどのように統合できているかを示しています STL/SVL/STV 得られる情報 SYS モニタリングビュー ビューのカラム STL_QUERY クエリの消費合計時間, クエリ名の短縮系, ユーザーID, トランザクションID, セッションID,クエリのステータス, データベース名 SYS_QUERY_HISTORY user_id query_id query_label transaction_id session_id database_name query_type status result_cache_hit start_time end_time elapsed_time queue_time execution_time error_message returned_rows returned_bytes query_text redshift_version usage_limit compute_type compile_time planning_time lock_wait_time STL_WLM_QUERY キュー滞在時間, 実行合計時間 SVL_QLOG キャッシュの使用 STL_ERROR エラーコード、エラーメッセージ STL_UTILITYTEXT SELECT以外のSQL STL_DDLTEXT DDLステートメント SVL_STATEMENTEXT 全てのタイプのSQLステートメント STL_RETURN 結果の行数とバイト STL_USAGE_CONTROL クエリによって到達した使用制限 ID のリスト STV_WLM_QUERY_STATE WLMの現在の状態 STV_RECENTS 現在実行中であるか完了しているクエリ STV_INFLIGHT 実行中のクエリ SVL_COMPILE コンパイル SYS から STL/SVL/STV へのマッピングに関する追加情報については、 SYS モニタリングビューへの移行 を参照してください。 ユーザークエリレベルのロギング クエリのパフォーマンスを向上させるために、Redshift クエリエンジンはユーザーが送信したクエリを書き換えることができます。 ユーザーが送信したクエリの ID は、書き換えられたクエリの ID とは異なります。 この記事では、ユーザーが送信したクエリを 親クエリ 、書き直したクエリを 子クエリ と呼びます。 次の図は、親クエリレベルと子クエリレベルでのロギングを示しています。 親クエリのIDは 1000 で、子クエリのIDは 1001、1002、1003 です。 クエリのライフサイクルのタイミング SYS_QUERY_HISTORY では、さまざまなクエリライフサイクルフェーズに関連する詳細な時間メトリクスを提供するために、カラムが拡張されています。 すべての時間はマイクロ秒単位で記録されることに注意してください。 次の表は、これらのメトリクスをまとめたものです。 タイムメトリクス 詳細 planning_time クエリを実行する前にクエリが費やした時間。通常、パース、分析、計画、書き換えなどのクエリライフサイクルフェーズが含まれます。 lock_wait_time 参照されている必要なデータベースオブジェクトのロックの取得にクエリが費やした時間。 queue_time リソースが実行可能になるまで、クエリがキュー内で待機していた時間。 compile_time クエリのコンパイルにかかった時間。 execution_time クエリの実行にかかった時間。 SELECT クエリの場合、これには結果が返ってくるまでの時間も含まれます。 elapsed_time クエリ実行の開始から終了までの時間。 ソリューションの概要 SYS モニタリングビューに慣れるために、以下のシナリオについて説明します: ワークロードとクエリのライフサイクルのモニタリング データ取り込みモニタリング 外部クエリのモニタリング クエリのパフォーマンスが遅い場合のトラブルシューティング 前提条件 この投稿の例に従うには、以下を事前に準備する必要があります: AWS アカウント プロビジョニングされた Redshift クラスター (現在のトラック) または Amazon Redshift Serverless エンドポイント 加えて、この記事で参照されているすべての SQL クエリを Redshift クエリエディタ v2 SQL ノートブックとして ダウンロード してください。 ワークロードとクエリのライフサイクルのモニタリング このセクションでは、ワークロードとクエリのライフサイクルをモニタリングする方法について説明します。 実行中のクエリを識別 SYS_QUERY_HISTORY では、実行中のすべてのクエリと実行履歴を一元的に確認できます。 次のクエリの例を参照してください: SELECT * FROM sys_query_history WHERE status IN ( 'planning' , 'queued' , 'running' , 'returning' ) ORDER BY start_time ; SQL 次の結果になります。 実行時間の長い上位クエリを特定 次のクエリは、実行に最も時間がかかる上位 100 件のクエリを取得するのに役立ちます。 これらのクエリを分析 (可能であれば最適化) することで、全体的なパフォーマンスを向上させることができます。 これらのメトリクスは、すべての実行されたクエリを累積した統計値です。 時間の値はすべてマイクロ秒単位であることに注意してください。 --top long running query by elapsed_time SELECT user_id , transaction_id , query_id , database_name , query_type , query_text:: VARCHAR ( 100 ) , lock_wait_time , planning_time , compile_time , execution_time , elapsed_time FROM sys_query_history ORDER BY elapsed_time DESC LIMIT 100 ; SQL 次の結果になります。 クエリの種類、期間、ステータス別に毎日のクエリ数を収集 次のクエリは、さまざまなタイプのクエリが各日にどのように分布しているかを把握し、ワークロードの変化を評価して追跡するのに役立ちます: --daily breakdown of workload by query types and status SELECT DATE_TRUNC ( 'day' , start_time ) period_daily , query_type , status , COUNT ( * ) FROM sys_query_history GROUP BY period_daily , query_type , status ORDER BY period_daily , query_type , status ; SQL   次の結果になります。 実行中のクエリの実行詳細を収集する 実行中のクエリの実行レベルの詳細を確認するには、 SYS_QUERY_DETAIL テーブルをクエリするときに is_active = 't' フィルタを使用できます。 次の例を参照してください: SELECT query_id , child_query_sequence , stream_id , segment_id , step_id , step_name , table_id , coalesce ( table_name , '' ) || coalesce ( source , '' ) as table_name , start_time , end_time , duration , blocks_read , local_read_io , remote_read_io FROM sys_query_detail WHERE is_active = 't' ORDER BY query_id , child_query_sequence , stream_id , segment_id , step_id ; SQL 実行された最新の 100 個の COPY クエリを表示するには、次のコードを使用します: SELECT session_id , transaction_id , query_id , database_name , table_name , data_source , loaded_rows , loaded_bytes , duration / 1000.00 duration_ms FROM sys_load_history ORDER BY start_time DESC LIMIT 100 ; SQL 次の結果になります。 コミットとその取り消しに対するトランザクションレベルの詳細の収集 SYS_TRANSACTION_HISTORY は、コミットされたブロック、ステータス、分離レベル ( SERIALIZABLE または SNAPSHOT ISOLATION ) などの詳細とともに、コミットされたトランザクションに関するインサイトを提供することにより、トランザクションレベルのロギングを提供します。 また、ロールバックまたは取り消しトランザクションの詳細も記録されます。 次のスクリーンショットは、正常にコミットされたトランザクションについての詳細情報を取得する方法を示しています。 次のスクリーンショットは、ロールバックされたトランザクションについての詳細情報を取得する方法を示しています。 統計情報とバキューム SYS_ANALYZE_HISTORY モニタリングビューには、分析クエリの最終タイムスタンプ、特定の分析クエリの実行時間、テーブル内の行数、変更された行数などの詳細が表示されます。 次のクエリ例は、すべての永続テーブルに対して実行された最新の分析クエリのリストを提供します: SELECT TRIM ( schema_name ) schema_name , TRIM ( table_name ) table_name , table_id , status , COUNT ( * ) times_analyze_was_triggered , MAX ( last_analyze_time ) last_analyze_time , MAX ( end_time ) end_time , AVG ( ROWS ) "rows" , AVG ( modified_rows ) modified_rows FROM sys_analyze_history WHERE status != 'Skipped' GROUP BY schema_name , table_name , table_id , status ORDER BY schema_name , table_name , table_id , status , end_time ; SQL 次の結果になります。 SYS_VACUUM_HISTORY モニタリングビューでは、バキュームに関するすべての詳細が 1 つのビューに表示されます。 たとえば、次のコードを参照してください: SELECT user_id , transaction_id , query_id , TRIM ( database_name ) as database_name , TRIM ( schema_name ) as schema_name , TRIM ( table_name ) table_name , table_id , vacuum_type , is_automatic as is_auto , duration , rows_before_vacuum , size_before_vacuum , reclaimable_rows , reclaimed_rows , reclaimed_blocks , sortedrows_before_vacuum , sortedrows_after_vacuum FROM sys_vacuum_history WHERE status LIKE '%Finished%' ORDER BY start_time ; SQL 次の結果になります。 データ取り込みのモニタリング このセクションでは、データ取り込みをモニタリングする方法について説明します。 取り込みの概要 SYS_LOAD_HISTORY は、COPY コマンドの統計に関する詳細を提供します。 このビューを使用すると、取り込みワークロードに関するインサイトをまとめることができます。 次のクエリ例は、データ取り込みが行われたテーブルごとに分類された、取り込みの概要を 1 時間ごとに示しています。 SELECT date_trunc ( 'hour' , start_time ) period_hourly , database_name , table_name , status , file_format , SUM ( loaded_rows ) total_rows_ingested , SUM ( loaded_bytes ) total_bytes_ingested , SUM ( source_file_count ) num_of_files_to_process , SUM ( file_count_scanned ) num_of_files_processed , SUM ( error_count ) total_errors FROM sys_load_history GROUP BY period_hourly , database_name , table_name , status , file_format ORDER BY table_name , period_hourly , status ; SQL 次の結果になります。 ファイルレベルの取り込みログ SYS_LOAD_DETAIL は、ファイルレベルでの取り込み処理に関するより詳細なインサイトを提供します。 例としては、 sys_load_history を使用した次のクエリを参照してください: SELECT * FROM sys_load_history WHERE table_name = 'catalog_sales' ORDER BY start_time ; SQL 次の結果になります。 次の例は、詳細なファイルレベルのモニタリングがどのようなものかを示しています。 SELECT user_id , query_id , TRIM ( file_name ) file_name , bytes_scanned , lines_scanned , splits_scanned , record_time , start_time , end_time FROM sys_load_detail WHERE query_id = 1824870 ORDER BY start_time ; SQL     取り込みプロセス中のエラーをチェック SYS_LOAD_ERROR_DETAIL を使用すると、取り込みプロセス中に発生した可能性のあるエラーを追跡してトラブルシューティングできます。 このビューには、取り込み処理中にエラーが発生したファイルの詳細と、エラーが発生した行番号、およびその行内のカラムの詳細が記録されます。 次のコードを参照してください。 select * from sys_load_error_detail order by start_time limit 100 ; SQL 次の結果になります。 外部クエリのモニタリング SYS_EXTERNAL_QUERY_DETAIL は、 Amazon Redshift Spectrum やフェデレーテッドクエリを含む外部クエリの実行詳細を提供します。 このビューは、詳細をセグメントレベルで記録し、単一のモニタリングビューで外部クエリのトラブルシューティングとパフォーマンスのモニタリングに役立つインサイトを提供します。 このモニタリングビューが提供する有用なメトリクスとデータポイントは次のとおりです。 スキャンされた外部ファイル ( scanned_files ) の数と、Parquetやテキストファイルなどの外部ファイルのフォーマット ( file_format ) スキャンされたデータの行数 ( returned_rows ) とバイト数 ( returned_bytes ) 外部クエリとテーブルによるパーティショニング ( total_partitions と qualified_partitions ) の使用 特定の外部オブジェクトの一覧表示 ( s3list_time ) とパーティションスキャン ( get_partition_time ) にかかった時間の詳細なインサイト 外部ファイルの場所 ( file_location ) と外部テーブル名 ( table_name ) Redshift Spectrum 用の Amazon Simple Storage Service (Amazon S3) やフェデレーテッドクエリといった外部ソースのタイプ( source_type ) サブディレクトリの再帰スキャン ( is_recursive ) またはネストされた列データ型へのアクセス ( is_nested ) たとえば、次のクエリは、実行された外部クエリ数とスキャンされたデータ数の日次での概要を示しています。 SELECT DATE_TRUNC ( 'hour' , start_time ) period_hourly , user_id , TRIM ( source_type ) source_type , COUNT ( DISTINCT query_id ) query_counts , SUM ( returned_rows ) returned_rows , ROUND ( SUM ( returned_bytes ) / 1024 ^ 3 , 2 ) returned_gb FROM sys_external_query_detail GROUP BY period_hourly , user_id , source_type ORDER BY period_hourly , user_id , source_type ; SQL 次の結果になります。 パーティションの使用 大量のデータやファイルをスキャンする外部クエリがパーティション化されているかどうかを確認できます。 パーティションを使用する場合、パーティションキーに基づいて絞り込むことによって、外部クエリがスキャンする必要があるデータの量を制限できます。 次のコードを参照してください。 SELECT file_location , CASE WHEN NVL ( total_partitions , 0 ) = 0 THEN 'No' ELSE 'Yes' END is_partitioned , SUM ( scanned_files ) total_scanned_files , COUNT ( DISTINCT query_id ) query_count FROM sys_external_query_detail GROUP BY file_location , is_partitioned ORDER BY total_scanned_files DESC ; SQL 次の結果になります。 外部クエリでエラーが発生した場合は、 SYS_EXTERNAL_QUERY_ERROR を調べてください。 SYS_EXTERNAL_QUERY_ERROR には、そのファイル内の file_location 、 column 、および rowid のレベルで詳細が記録されます。 クエリのパフォーマンスが遅い場合のトラブルシューティング SYS モニタリングビューを使用したクエリレベルのトラブルシューティングを行うための、ステップバイステップのガイドとして、前提条件のセクションでダウンロードした sysview_slow_query_performance_troubleshooting SQL ノートブックがあります。これを参照して、次の質問に対する回答を探してください。 比較対象のクエリと、実行したクエリのクエリテキストは似ていますか ? クエリは結果キャッシュを使用していますか ? クエリのライフサイクル (キューイング、コンパイル、プランニング、ロック待機) のどの部分がクエリの実行時間に最も影響を与えていますか ? クエリプランは変更されましたか ? クエリは多くのデータブロックを読み込んでいますか ? クエリがディスク領域を使っていませんか？もしそうであればそれはローカルストレージですか、リモートストレージですか? データ (分散) と時間 (実行時間) の点で、大きく偏っているクエリですか ? ジョインまたはネストループで処理される行が増えていますか ? 統計情報が古くなっていることを示すアラートはありますか ? クエリに関係するテーブルに対して最後に VACUUM と ANALYZE が実行されたのはいつですか ? クリーンアップ Redshift のプロビジョニングされたクラスターまたは Redshift サーバーレスワークグループをこの記事のために作成し、ワークロードに対して必要なくなった場合は、それらを削除して追加コストの発生を防ぐことができます。 まとめ この記事では、Redshift SYS モニタリングビューを使用して、プロビジョニングされたクラスターとサーバーレスワークグループのワークロードをモニタリングする方法について説明しました。 SYSモニタリングビューでは、ワークロードのモニタリングが簡素化され、統一されたビューからさまざまなクエリレベルのモニタリング用のメトリクスにアクセスできます。また、プロビジョニングされたクラスターとサーバーレスワークグループの両方で、同じ SYS モニタリングビュークエリを使用できます。 また、SYS モニタリングビューを使用した主要なモニタリングおよびトラブルシューティングシナリオについても説明しました。 Redshift のワークロードには、新しい SYS モニタリングビューを使い始めることをお勧めします。 著者について Urvish Shah は Amazon Redshift のシニアデータベースエンジニアです。 彼はデータベース、データウェアハウス、アナリティクス分野で10年以上働いてきました。 仕事以外では、料理、旅行、娘との時間を楽しんでいます。 Ranjan Burman は AWS のアナリティクススペシャリストソリューションアーキテクトです。 Amazon Redshift を専門とし、お客様がスケーラブルなアナリティクスソリューションを構築できるよう支援しています。 彼はさまざまなデータベースおよびデータウェアハウステクノロジーで 16 年以上の経験があります。 クラウドソリューションによる顧客の問題の自動化と解決に情熱を注いでいます。 翻訳はソリューションアーキテクトの小役丸が担当しました。原文は こちら です。

11月27日(月)に無料ウェビナー AWS Purpose Built Database Webinar 「Amazon Aurora/RDS のコスト最適化」 を開催します。 本セッションでは、Amazon Aurora/RDS を長期間運用するにあたってのコスト最適化のポイントや、安定運用のコツについてご紹介します。本セッションは、以下の2部から構成されます。 「Amazon Aurora/RDS でのコストの最適化」のセッションでは、これまでのウェビナーで移行→コスト削減の話が多かったため、RDS長期・安定利用中のお客様向けのコスト削減をこのセッションで紹介し、それ以外にAurora Serverless v2やIO-Cost Optimization（New price model導入)の話も案内します。 「移行のベスト プラクティスとコストの最適化」のセッションでは、移行案件など、必要スペックが想定できているお客様へのコスト削減案を案内し、Tooling&Programもここで紹介します(DBFW/DMS・SCT/OLA)。 AWSマネージドデータベースサービスの運用とコスト削減に興味がある方は是非ご参加ください。 アジェンダ ※当日の進行により、時間割が若干変更となる場合がございます。 時間 プログラム 講師 14:00-14:30 Amazon Aurora/RDS でのコストの最適化 木村 達也 14:30-15:00 移行のベスト プラクティスとコストの最適化 小沢 亮太 開催場所 当日は下記のZoomにアクセスし、Meeting IDを入力してウェビナーにご参加ください。 https://zoom.us/join Meeting ID: 81462473492 Passcode: 357768 講師プロフィール 木村 達也 データ事業本部 ポートフォリオスペシャリストソリューション本部 シニアデータベーススペシャリストソリューションアーキテクト 製造、通信、メディア業界のお客様に対するデータベースの課題解決支援に従事しています。 小沢 亮太 パブリックセクター技術統括本部 パートナーソリューションアーキテクト 前職では外資系データベースベンダーにて、データベースのサポート・プリセールスを行なってきました。AWSでは、パートナーソリューションアーキテクトとして、パートナー様が悩まれているデータベースの移行について、勉強会やソリューションをご案内しています。 今回のウェビナー完了後、開催レポート及びQ＆Aは Amazon Web Servicesブログ に掲載予定となります。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 10月もまもなく終わりですね。11月にさしかかると、常に意識に上がってくるのはAWSの世界最大の学習型カンファレンス、 AWS re:invent 2023 ですね。たくさんのサービスアップデートや先進的な事例が発表されますイベントですので、是非チェックしてください。キーノートと一部のコンテンツはオンラインで無料で視聴いただくこともできます。 そして毎年恒例のAWS BlackBelt Online Seminarのre:Inventまとめ回ですが、今年も配信いたします。日本時間で12/1のお昼休み、12:00-13:00に可能な限り全てのサービスアップデートをざっくりとご紹介します。無料でご参加いただけますが、こちらもお申し込みが必要になります。（10/30 17時頃追記： 申込みページ できました！） それでは、10 月 23 日週のアップデートを振り返ってみましょう。 2023 年 10 月 23 日週の主要なアップデート 10/23(月) Amazon ECSで予期できない負荷が発生した際の挙動を改善 Amazon ECSのタスクスケジューリング機能が強化され、予測できない負荷が発生した場合にもより回復力を高めるように動作するようになりました。ECSで稼働するタスク(コンテナ)はヘルスチェックが行われ、応答がない場合はそれが終了され代わりのタスクが起動されます。今回のアップデートで、新たにタスクを起動しサービスに組み込んだ後に、応答がないタスクを終了するような動作をするようになります。突発的な負荷が発生すると過負荷によってタスクがヘルスチェックに応答できず終了され、一時的に全体のキャパシティが低下してしまう、といったケースの回避につながることが期待できます。 Amazon RDS for SQL ServerがSQL Server 2019の新しいマイナーバージョンをサポート Amazon RDS for SQL ServerでSQL Server 2019 CU22 – 15.0.4322.2をサポートしました。Express, Web, Standard, Enterpriseの各エディションでご利用いただけます。 10/24(火) Amazon OpenSearch Serverlessで時刻ベースのデータ削除に対応 Amazon OpenSearch Serverlessで時刻に基づいた自動データ削除が可能になりました。この機能はインデックスライフサイクルポリシーを設定することで有効化できます。不必要になったデータを削除するといった、ハウスキーピング処理を容易に実現できます。 Amazon Aurora PostgreSQLでpgvector v0.5.0を利用可能に PostgreSQL互換のAmazon Auroraでpgvector v0.5.0を利用できるようになりました。機械学習モデルで利用されるエンベディング(埋め込み)データを格納し、効率的に類似するデータを検索することが可能です。HNSWによる近傍探索のためのインデクシングもサポートされており、特に生成系AIの分野で利用されるデータストアとしての利用が容易になります。pgvector v0.5.0はPostgreSQL 15.4, 14.9, 13.12, 12.16互換のAurora PostgreSQLでご利用いただけます。 Amazon Aurora PostgreSQLで新しマイナーバージョンをサポート PostgreSQL互換のAmazon AuroraでPostgreSQL 15.4, 14.9, 13.12, 12.16, 11.21がサポートされました。このアップデートにはBabelfish for Aurora PostgreSQL 3.3のようなアップデートも含まれています。 Amazon EKSでクラスタのサブネットとセキュリティグループの設定変更が可能に Amazon Elastic Kubernetes Service(EKS)で、クラスタに紐付けられたサブネットとセキュリティグループを変更できるようになりました。VPCの設定を変更する必要が発生した場合も、クラスタを作り直すことなしに変更内容に柔軟に追従させることができます。 Amazon EKSがカスタマーマネージドIAMポリシーをサポート Amazon EKSでユーザが作成した独自のIAMポリシー(カスタマーマネージドIAMポリシー)を利用できるようになりました。Kubernetesクラスタが引き受けることができるIAMの権限をきめ細かく制御することが可能になり、コンプライアンスやガバナンス要件を満たすことが容易になります。 Amazon SQSのFIFOキューの高スループットモードにおける上限を引き上げ Amazon SQLにおいて、順序と同じデータが重複して取り出されない事を保証するFIFOキューのスループット上限が引き上げられました。リージョンによって異なりますが、東京リージョンでは高スループットモードで最大9,000トランザクション毎秒まで対応可能です。リージョン毎の上限値については ドキュメント を確認してください。 10/25(水) Amazon RDS for PostgreSQL, MySQL, MariaDBでM7g/R7gインスタンスを利用できるリージョンを拡大 東京リージョンを始め5つのリージョンにおいて、RDS for PostgreSQL, MySQL, MariaDBをGraviton 3プロセッサベースのM7g/R7gインスタンスでご利用いただけるようになりました。 Amazon Aurora MySQL 3.04がLong term support(LTS)対象に MySQL 8.0.28と互換のAurora MySQL 3.04がLTS(Long term support)対象になりました。LTSリリースが動作するクラスタでは、最低3年間は同じマイナーバージョンにとどまり続けることが可能です。この期間はセキュリティ問題の修正などが提供されますが、新機能は含まれません。 Amazon Aurora MySQLのバージョン3.05が利用可能に Amazon Aurora MySQLのバージョン3.05が一般利用開始になりました。このバージョンはMySQL 8.0.32と互換性を持っています。 Amazon Aurora MySQLでデータベースの再起動時間を最大65%短縮 Amazon Aurora MySQLでバッファプールの初期化と検証の一部をデータベースがオンラインになった後に実行するよう最適化することで、予期しない再起動や計画的な再起動の双方について起動時間が最大65%短縮されました。この最適化はAurora MySQL 3.05以降でデフォルト有効になっています。 Amazon EC2 M2 Macインスタンスが一般利用開始に Amazon EC2で、M2プロセッサを搭載したMacインスタンスが利用可能になりました。iOS, macOS, iPadOSをはじめとするApple社のプラットフォーム向けの開発やテストにご利用いただけます。 10/26(木) Amazon OpenSearch ServiceがIPv6をサポート Amazon OpenSearch ServiceでIPv4に加えてIPv6による通信を利用できるようになりました。 Amazon EC2のI4iインスタンスで新たに2つのサイズが利用可能に 高いパフォーマンスを発揮するローカルストレージが利用できるI4iインスタンスで、新たにI4i.12xlargeとI4i.24xlargeというサイズをご利用いただけるようになりました。東京・大阪のリージョンでもご利用いただけます。 Amazon AppStream 2.0のMicrosoft Windows環境がマルチセッション接続に対応 Amazon AppStream 2.0でWindows環境のマルチセッション接続をサポートしました。複数のユーザセッションを単一のインスタンスで処理できるようになり、コスト効率が向上します。 Amazon EC2インスタンスに対して異なるVPCのENIをアタッチ可能に Amazon EC2で、EC2インスタンスにアタッチされたプライマリのENIが所属するVPCと異なるVPCに所属するENIを、同じインスタンスにアタッチできるようになりました。コントロールプレーンとデータプレーンの分離や、異なるVPCに集約されたアプライアンスへのアクセスが必要な場合に便利な機能です。 10/27(金) AWS NeuronがLlama-2 70bモデルとPyTorch 2.0をサポート AWS Neuronは機械学習用のアクセラレータであるInferentiaとTraniumを搭載したEC2インスタンス向けのSDKです。今回バージョン2.15がリリースされ、Llama-2 70bモデルのトレーニングへの対応と、PyTorch 2.0のサポートが行われました。 Amazon OpenSearch Serviceがk-NN FAISSエンジンによる効率的なクエリフィルタリングに対応 Amazon OpenSearch ServiceのOpenSearch 2.9を利用することで、k-NN FAISSエンジンを利用した効率的なクエリフィルタリングを活用可能になります。これを利用すると従来よりも低遅延で正確な結果を期待できるため、ベクトル検索を必要とするアプリケーションで便利にご利用いただけます。 Amazon Security Lakeが大阪リージョンで利用可能に セキュリティデータの分析を容易にするAmazon Security Lakeが大阪リージョンをはじめ、4つのリージョンでご利用いただけるようになりました。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

アマゾン ウェブ サービス ジャパン合同会社とつくば市は、2022 年9 月に 研究開発型スタートアップの成長加速に向けた 連携協定を締結 いたしました。つくばの研究開発スタートアップの創出・育成に向けつくばのスタートアップへの AWS Activate を通したご支援や、イベントの共催等を行っています。 今回は 2023年 10月 18日に、 つくばスタートアップパーク でつくば市と AWS が開催したイベント 「イノベーションの最前線vol.6 ー防災テックを活かしたレジリエンス社会の実現に向けてー」 の開催報告を、当日の内容から一部抜粋してお送りします。 本イベントのご登壇者は以下の通りです。 I－レジリエンス株式会社 （以下、I－レジリエンス） 代表取締役社長　小林 誠 氏 防災科学技術研究所 （以下、防災科研） 防災情報研究部門/総合防災情報センター  吉森 和城 氏 モデレーター： アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 教育事業本部アカウントエグゼクティブ　田代 皓嗣 まずは小林 氏より、I－レジリエンスのお取り組み紹介をお話しいただきました。 防災科研の研究成果の社会実装のために生まれた、I－レジリエンスの挑戦 I－レジリエンス は、災害が多い日本で、防災の研究成果をきちんと社会で使える状態にしないといけない背景がありまして、防災科研の研究成果の社会実装を促進するために 2021 年 11 月設立されました。もうすぐ設立 2 年の、まだまだスタートアップです。産学官連携で行うために、民間企業 4 社にも出資いただいています。 I－レジリエンス株式会社 代表取締役社長　小林 誠 氏 I－レジリエンスの目的は大きく2つあります。 1 つ目は研究成果を活用したレジリエンス向上 です。防災科研のような研究者の方々が、研究成果を商品化して、運用して社会実装していくまでやるのは大変なので、社会実装を会社でやるのが私たちです。 2 つ目は、 民間企業主体のレジリエンス向上 です。行政だけではなく、企業や生活者にも情報を使った新しいサービスが必要なので、ここをI－レジリエンスとしてやっています。企業が使える防災情報サービスプラットフォームなどを運営し、その中で AWS も活用しています。大きく 3 つ DX・教育・ライフと 3 つの事業領域を持っています。 レジリエンスを高めることでより生活を豊かにする「レジリエントライフ」 レジリエンスとは、災害が起こった時、回復・復旧を早くしようというコンセプトですが、I－レジリエンスでは少し違う定義をしています。私たちは、 社会や個人に降りかかる自然災害だけではない困難に、適応、回復し、その後教訓をもとに成長し、次の被害を予防する、このサイクルを繰り返して困難を乗り越えるチカラ 、と定義しています。 レジリエントライフプロジェクト は、今年関東大震災100年に合わせて、防災科研と民間企業各社と一緒にスタートしました。各社が持っている強みを生かして、個人を起点にあらゆる困難に適応・回復・成長・予防できる生活の豊かさの実現を目指して活動しています。 防災という言葉はネガティブなイメージですが、レジリエンスを高めることでより豊かな生活を目指す、 「レジリエンスっていいよね」、というポジティブなイメージを広げていきたい という想いで取り組んでいます。 私たちは、困難な領域である防災分野のビジネスに挑戦し、これまた困難と言われている、研究成果の社会実装をするという、非常に難しいミッションを二つ負ったスタートアップです。やっていくべきことは主に 3 つあって、1 つ目はニーズとシーズのブリッジです。まだまだマッチングしていない防災に関するニーズと、シーズはたくさんあり、目利きをして橋渡しできる人が増えていく必要があります。 2 つ目は、1 つのソリューションでは解決できない生活者の課題を、色々な企業の色々なサービスを組み合わせて解決していく「コレクティブ・インパクト」を実現してくことです。3 つ目に、レジリエンス市場を新しく創出していくことです。 まだまだ防災分野の課題解決のためには、より多くの企業と共創していく必要があると思っています。私たちは、企業同士が防災分野で連携していくための基盤となるサービスとして、レジリエンスに関するすべてのニーズにこたえる総合プラットフォーム IRIN (I-Resilience Information Network）の開発を進めています。このようなサービスによってレジリエンス社会の実現を目指していきます。 分散した防災情報を集約・一元化し、防災効果の最大化を目指す 続いて、 防災科研 の吉森 氏より、防災科研の取り組みのご紹介と AWS の活用についてお話いただきました。 防災科研では、あらゆる自然災害を対象に、予測・予防、応急対応、復旧・復興という災害のすべての段階についての、基礎研究及び基盤的研究開発に取り組んでいます。例えば、全国各地にある地震計の観測震度をリアルタイムで公開( 強震モニタ )していたり、災害の現象実物大で再現し実験する施設( 大型降雨実験施設 、 E-ディフェンスなど )があったりします。 防災科学技術研究所 防災情報研究部門/総合防災情報センター  吉森 和城 氏 私が所属する防災情報研究部門では、色んな機関に分散している防災情報をきちんと活用し、社会実装していくために活動しています。その中で、 SIP4D （基盤的防災情報流通ネットワーク）というシステムを研究開発しています。こちらは分散したデータを繋ぎ相互に共有していく「パイプライン」を実現し、国全体としての災害対応の効果最大化を目指しています。その SIP4D で集約した情報を公開する 防災クロスビュー というウェブサイトも運用しています。 AWSとの出会いは北海道胆振東部地震。いつどこで地震や災害起きても、気づける仕組みが必要だった AWS と出会ったきっかけは、平成 30 年に発生した北海道胆振東部地震です。私のチームは、防災クロスビューを速やかに開設し、様々な情報発信を行いました。 しかし、深夜3時7分という、メンバー全員が寝ている時に深夜に発生したので、すぐに地震に気づくことができず、初動の対応に課題が残りました。 いつどこで地震が発生しても、対応者が気づける仕組みが必要 だという課題が浮き彫りになりました。 そのころ丁度スマートスピーカーが普及してきた頃だったので、Amazon Echo の Alexa スキルで地震情報を教えてくれるシステムを開発している開発者に問い合わせ、地震が起きたら強制的にアラートを出してくれる Alexa スキルを開発できないかと聞きました。 Alexa スキルは制約が多いので難しいと言われましたが、 Amazon Connect というサービスを使えば強制的に電話通知できると教えてもらいました。また、AWS の色々なサービスを組み合わせることで、電話通知だけではなく他の通知にも拡張できるとのことでした。 当初はコスト面が懸念でしたが、 AWS は従量課金で、災害発生時に電話をかけた時のみコストが発生するため、低コストで運用できるのでは と考え、AWS 導入の検討に踏み切りました。 開発者の方に相談して 10 日後にはサンプルを構築してくださり、このスピード感でサンプルシステムが実現できたので AWS は本当にすごいなと思いました。 突発的な災害にも、俊敏かつ柔軟に対応可能な災害通知システムを、2.5 か月で構築 サンプルシステムを踏まえ、実際に災害が起きた時に電話がかける仕組みを実現しようと、考案から2.5 か月で、初回の災害情報通知システムが構築されています。気象庁や J-アラートをトリガーに、AWS 上の処理を経て職員にチャットや電話等のツールで通知する仕組みです。 あくまで個人の見解とはなりますが、AWSを活用する上でプラスに感じていることは、まず 従量課金のため頻度が高くない利用に関しては、コストメリットが大きい ことです。そして システム構築のスピード感、スモールスタートで開発できその後の拡張が容易であること もメリットです。 最初は私も災害情報通知システムだけを作り始めましたが、2018 年の導入から業務の自動化・簡便化にも活用するようになり、5 年間でこれまで9 種類のシステムで AWS を活用しています。 一方で、少し困っていることとしては、従量課金のため費用感が確実に予想できないことです。ここ数年特に為替変動が大きく予測が難しいこともあり、この点は何かしらの改善を期待しているところです。 必要な時に、必要なだけ使うことができるクラウドは、防災テックと相性がよい 続いて、AWS の田代より、 AWS の概要についてお話しました。AWS クラウドの価値は、まさしく吉森 氏は話されたような、スモールスタートで必要な時に必要なだけ使えること、アイデアから実装までの時間を短縮できることで、防災分野はクラウドと大変相性がよいことを強調しました。 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 教育事業本部アカウントエグゼクティブ　田代 皓嗣 防災分野でテクノロジーを活用する余地はまだまだある。必要な時に必要なだけ防災データを活用できる仕組みの構築に向けて 最後に、登壇者でクロストークを行いました。ここではその一部を抜粋してお伝えします。 ―まずお伺いしたいのは、防災の領域でのテクノロジー活用はどのくらい進んでいるか、お二人のお考えを率直にお聞かせください。 小林 氏：まだまだこの領域で新しいテクノロジーの活用は進んでいないと考えています。例えば、災害の被害状況はリアルタイムで把握することができません。IoT や衛星データによって身の回りの情報、よりきめこまかやかに取得できると、防災対策も大きく変わってくると思います。 現状では、行政は市全体に対して防災サービス提供という形になっていますが、 一人ひとりに合わせて必要なサービスを提供していくには、テクノロジーをより活用していくことが重要 だと思いますし、さらに技術が進化していく必要があります。 「必要な時に、必要なだけ使えるようにする」というのは防災において重要です。平時から防災情報が活用できるようにするのは、コスト面では結構しんどい。 必要な時だけ使えるようにしておき、使った分だけ課金される仕組みができると、もっと防災情報は普及する と思います。そういったところで今後 AWS ともご一緒したいと思います。 田代：防災レジリエンスではテクノロジーによって情報がパーソナライズされていく、 個々人が最適な行動をとるうえで、クラウドがビジネスモデルに組み込まれていくことが必要 なのだということ理解しました。 吉森 氏：私もこの領域でテクノロジー活用の余地はまだまだあると考えています。 現在、やっと解析に使えるデータがそろい始めている段階 。集まったデータをより価値のある情報に変えていくために、新しいテクノロジーの活用がもっと必要です。 災害は毎回規模も大きさも違い、今まで準備していたデータの扱い方がガラッと変わったりします。それぞれにうまく対応していくのはテクノロジーで解決していかなければいけないと考えています。 スタートアップ企業の革新的ソリューションがもとめられている防災分野 田代：テクノロジーが解決していくために、スタートアップのような企業の革新的なソリューションが必要とされている市場だと思います。ぜひこの分野に取り組むスタートアップを増やしていきたいですね。 小林 氏： スタートアップのような方が情報を使いやすく、より防災サービスを作りやすくしていく環境作りを、私たちI－レジリエンスとしてやっていきたい と思っています。防災情報を一から集めるのは、各自がやらなくても、誰かがやってくれればよいんです。 田代：I-レジリエンスはご自身もスタートアップでありながら、スタートアップのためのプラットフォームにもなられようとされていますね。こういった状況も踏まえて、この領域で起業する方が増えることを期待しています。 ―I－レジリエンスは防災科研が出資をされて設立された、今までになかったベンチャーです。防災科研が出資までしてスタートアップを設立した目的についても、改めて教えていただけますでしょうか。 小林 氏：防災科研の素晴らしい研究成果をしっかり社会に広めていきたいというときに、研究者が社会実装まで担うのは難しいことがあります。研究者にはしっかり研究に専念していただきたいですし、私たちが会社として、社会に技術を実装していくために設立されました。I－レジリエンスは、研究所発ベンチャーではありながら、私のような技術者でも研究者でもない者が代表ですし、その技術が社会の何の役に立つのか、をうまく翻訳し、社会実装に繋げていきたいです。 田代： 防災科研とI－レジリエンスの関係は、研究の社会実装の形としては、先進的なモデルとなるような形 だと思っています。他の研究機関も真似するところがでてくると考えています。 ―最後に、今後テクノロジーを使ってどういったことをしていきたいか、将来の展望を教えてください。 吉森 氏：研究者の立場としては、研究のロジックや要件は定義しますが、それを支えるシステムやテクノロジーを作っていくために、 技術者が関わってくださることがもっと必要 です。 田代：そうですね。AWS を使えるようなエンジニアの方はぜひ防災科研にコンタクトしていただいて、防災の研究者と技術者の協業が増えるといいなと思います。 小林 氏：吉森さんのおっしゃる通り、研究を「実装」するためにも、研究開発において、研究にきちんとテクノロジーを入れていくことが重要だと思います。 防災は一つの分野ではなく、理学、工学、社会科学、医療、通信など様々な分野の色々なテクノロジーがないとできない特殊な領域です。現在では今バラバラに個別の機関がデータを抱えている状況です。なぜそのような対応をしたのか、等情報が集まっていくと、世の中は変わっていくと思っています。そういう バラバラのデータが、分野を超えてクラウドの同じ場所に集めて解析され、新しい価値を生み出して社会を変えていくことが求められています 。 私たちは、日々の生活の色々な部分にテクノロジーが組み込まれ、日常的にレジリエンスを意識するような社会を目指していきたいです。I－レジリエンス自身もスタートアップですが、他のスタートアップと協業して、そのような新しい社会を作ることを目指しています。 田代： システムのサイロを打破して、きちっとナレッジをシェアできるコミュニティを作っていく、そしてみんなで災害に備えていくことで、レジリエントな社会に繋がっていく と思います。 今日お話しされたアイデアがどんどん社会実装されていくのは一生活者としても非常に楽しみですし、AWS のテクノロジーがその社会の実現に貢献できればとても嬉しいです。 イベントレポートはいかがでしたでしょうか？AWS パブリックセクターは今後も、自治体、大学、研究機関、スタートアップの皆様と共創し、地域発イノベーションを加速させるためのさまざまなセッションや Meetup を実施予定です。ご関心を持たれた方は、ぜひお気軽に こちら までお問い合わせください。 このブログは、 アマゾンウェブサービスジャパン合同会社 パブリックセクター  シニア事業開発マネージャー（ Startup ）である 岩瀬 霞 が執筆しました。

この記事は Patterns for rapid IoT solution prototyping using AWS IoT Greengrass and Docker の日本語訳です。 はじめに 調査によると、モノのインターネット（IoT）ソリューションの実装には、通常、市場に出て運用準備が整うまでに 平均18〜24か月 かかります。IoT ソリューション開発に関連する一般的なシナリオには、デバイスプロビジョニング、テレメトリ収集、リモートコマンドアンドコントロールなどがあります。ユースケースにもよりますが、 well-architected IoT solution のプロトタイプを作成するには、それぞれのシナリオに適した設計原則とベストプラクティスを検討する必要があります。この投稿では、 AWS Cloud Development Kit (AWS CDK)、 AWS IoT Greengrass 、 Docker を組み合わせたプロトタイピングデザインパターンを採用して、AWS での IoT ソリューションのプロトタイピングを加速する方法を説明します。 AWS CDK は、一般的なプログラミング言語の表現力を利用して、AWS 上のクラウドリソースをモデル化することで、クラウド開発を加速します。AWS IoT Greengrass は、デバイスソフトウェアを構築、デプロイ、管理するためのオープンソースのエッジランタイムおよびマネージドクラウドサービスです。AWS IoT Greengrass を使用することで、ワークロードのエッジでの実行、IoT デバイスフリート全体に新規アプリケーションやレガシーアプリケーションをデプロイ、デバイスフリートをリモートで管理および操作を行うことができます。AWS IoT Greengrass には、カスタムコードを記述することなくエッジデバイスの機能を拡張できる 30 種類以上の AWS提供コンポーネント もあります。 AWS IoT Greengrass は、 Docker コンテナ内での実行や、Docker コンテナとしての実行 など、 さまざまなデプロイ方法 をサポートしています。AWS CDK を使用して作成された体系化されたインフラストラクチャパターンを、コンテナ化および自動化と組み合わせて、IoT デバイスの機能をテストまたは調査するための一貫したアプローチを作成できます。このアプローチは、プロトタイピングの繰り返し中に重要ではない暫定的なアーティファクトを残すことなく、IoT ソリューションの迅速なプロトタイピングをサポートします。 ソリューションの概要 本投稿では、このアプローチが一般的な IoT ソリューションシナリオをサポートする方法を説明します。一般的な IoT ソリューションシナリオは、デバイスプロビジョニング、デバイスコマンドアンドコントロール、テレメトリ収集です。 デバイスプロビジョニング 安全な IoT デバイスのプロビジョニング では、 固有の アイデンティティ を使用してデバイスを設定し、これらの ID を AWS IoT サービスに登録し、必要な権限を関連付ける必要があります。これにより、デバイスが AWS IoT やその他の必要な AWS サービスに安全に接続して通信できるようになります。この要件は AWS IoT Greengrass コアデバイスのセットアップ に適用されます。以下の手順は、AWS IoT Greengrass コアデバイスをプロビジョニングする方法を示しています。 AWS IoT Coreポリシーを作成します。 AWS IoT のモノ、グループ、証明書、プライベートキーを作成します。 AWS IoT ロールエイリアスと AWS Identity and Access Management (IAM) ロールを作成します。 AWS IoT Greengrass コアデバイスをセットアップします。 プロトタイピングとテスト用に AWS IoT Greengrass コンポーネントをデプロイします。 上記の手順を効率化するために、図 1 に示すパターンの採用を検討してください。このパターンでは、AWS CDK と Docker を使用して関連するリソースの作成を簡素化および効率化できます。そのため、ユーザーは 自身の IoT  ソリューションにおける機能の差別化実現に集中できます。本パターンには以下の要素が含まれます。 必要な AWS リソースを再利用可能な構成として表す AWS CDK スタック 。AWS リソースは、 AWS CloudFormation を使用して AWS CDK CLI を通じてデプロイされます。 新しく作成された AWS IoT クライアント証明書をダウンロードし、 Docker Compose ファイルと AWS IoT Greengrass セットアップスクリプトを設定することができる ヘルパースクリプト  があります。 AWS IoT Greengrass Core デバイスをセットアップし、AWS が提供するコンポーネントとオプションのカスタムコンポーネントを デプロイ する Docker コンテナです。 図 1.AWS CDK と Docker を使用して自動化された AWS IoT Greengrass Core デバイスプロビジョニングの基本プロトタイピングパターン 図 1.の詳細については、このセクションを開いて確認してください。 この図は、AWS IoT Greengrass コアデバイスのリソースの作成とデプロイを自動化する手順を示しています。AWS CDK (1) と CloudFormation (2) を使用して、必要な AWS IoT リソースと IAM リソースを作成します。付属のヘルパースクリプト (3) を使用してローカル設定を完了し、ローカルの Docker コンテナ (4) で AWS IoT Greengrass を起動します。 AWS IoT サービス、インフラストラクチャデプロイ、Docker を組み合わせて機能的な AWS IoT Greengrass コアデプロイを作成できます。その後、ソリューションに必要な 特化した コンポーネント開発 を進めます。 リモート管理/コマンドとコントロール IoT ソリューションを構築する際に遭遇する可能性のあるもう 1 つの一般的なシナリオは、IoT デバイスとリモートでやり取りできることです。たとえば、産業機器から特定のテレメトリデータを要求したり、ホームオートメーションイベントのスケジュールを設定したりします。AWS のベストプラクティスに従い、 MQTT プロトコル の双方向機能を使用してください。AWS では MQTT のコマンドとコントロールを実装するための  Device Shadow  と AWS IoT Jobs を提供しています。 図 1 で説明したパターンをベースにすると、このアプローチを拡張して MQTT 経由でデバイスのコマンドとコントロール機能をすばやく有効にすることができます。このパターンの例を図2に示します。このパターンには以下が含まれます。 AWS CDK スタックの内容: 追加の AWS IoT Core ポリシーと IAM ポリシーを作成します。 新しい AWS IoT モノグループを作成します。 既存の AWS IoT モノを新しいグループに追加します。 デバイスのコマンドとコントロールのカスタム AWS IoT Greengrass コンポーネントをデプロイします。 AWS CDK CLIを利用してCloudFormathionを実行し、リソースをデプロイします。 このパターンでは、AWS CDK ランタイムコンテキスト を使用して、以前に作成されたベースとなる CloudFormation スタックからサポートしている AWS CDK リソースを参照します。本パターンは、リソースの再実装や再デプロイすることなく、新しい機能を作成してテストすることに重点を置いています。 スタックが正常にデプロイされると、カスタムコンポーネントは指定された MQTT トピックをサブスクライブし、コマンドリクエスト到達を待機します。このトピックを通じてデバイスにコマンドを発行し、MQTT トピックのレスポンス内で完了ステータスメッセージを受信します。 このアプローチを採用すると、利用用途に合致した AWS IoT ソリューションの一部として、カスタムデバイスのコマンドとコントロール機能のプロトタイプを迅速に作成できます。 図 2.MQTT を使用した IoT デバイスのコマンドとコントロールのプロトタイピングパターンの例 図 2 の詳細については、このセクションを開いて確認してください。 AWS CDK (1) を使用して、すでにデプロイされた CloudFormation スタック (2) を参照し、追加の AWS IoT、IAM、および AWS IoT Greengrass デプロイリソースを作成します。MQTT ベースのコマンドとコントロールのコンポーネントは、ローカルで実行されている AWS IoT Greengrass コアデバイスにデプロイされます。 テレメトリの収集 最後に、一般的な IoT ソリューションには、物理デバイス、センサー、または産業機器からテレメトリデータを収集する機能が必要です。収集されたデータは、ストリーミング分析、デジタルツイン、予知保全、プロセスのシミュレーションと最適化など、多くの IoT アプリケーションをサポートできます。詳細については、「  IoT データの取り込みと可視化のための7つのパターン – ユースケースに最適なものを決定する方法 」を参照してください。 基本的なデバイスプロビジョニングパターン (図 1) を基盤として、ユースケースの要件を満たすために IoT データを AWS に取り込むオプションを検討できます。たとえば、AWS IoT Greengrass コア デバイス上で実行されている AWS IoT SiteWise を使用すると、産業機器からのデータを大規模に収集、整理、分析できます。具体的には、 OPC-UA プロトコルを使用して産業用テレメトリデータを取り込むソリューションを作成してください。取り込んだデータを 視覚化 して 分析し 、異常に対応したり、産業施設間の違いを特定したりできます。 このソリューションを実装するには、図 3 に示すパターンを採用してください。以前のパターンと同様に、このパターンには以下が含まれます。 AWS CDK スタックの内容: 専用の AWS IoT Core ポリシーと IAM ポリシーを作成します。 新しい AWS IoT モノグループを作成します。 既存の AWS IoT モノを新しいグループに追加します。 D必要な AWS IoT Greengrass コンポーネント ( AWS IoT SiteWise OPC-UA コレクター 、 AWS IoT SiteWise パブリッシャー 、および AWS IoT Greengrass ストリームマネージャー ) をデプロイします。 クラウドフォーメーションを使用して AWS CDK CLI を使用してリソースをデプロイします。 また、このパターンでは、AWS CDK ランタイムコンテキスト を使用して、作成済みのベースとなる AWS CloudFormation スタックがサポートする AWS CDK リソースを参照します。 デプロイすると、IoT Greengrass コア デバイスは既存の OPC-UA エンドポイントからテレメトリを収集し、このテレメトリを AWS IoT SiteWise に発行できるようになります。詳細については、「 AWS IoT SiteWise へのデータの取り込み 」を参照してください。 図 3.OPC-UA と AWS IoT SiteWise を使用してテレメトリを取り込むプロトタイピングパターンの例 図 3 の詳細については、このセクションを開いて確認してください。 AWS CDK (1) を使用して、以前にデプロイされたベースの CloudFormation スタック (2) を参照し、追加の AWS IoT、IAM、および AWS IoT Greengrass デプロイリソースを作成します。テレメトリの収集と公開に必要な AWS IoT SiteWise コンポーネントは、ローカルで実行されている AWS IoT Greengrass コアデバイスにデプロイされます。 このアプローチを使用すると、必要なテレメトリの取り込み機能を迅速に構築してテストできます。自動化とコンテナ化という利点も加わり、プロトタイピングにかかるコストを全体的に削減できます。 この記事で紹介するパターンとソリューションはすべて、以下の概要に従ってお客様の AWS アカウントで使用できます。 前提条件 AWS アカウント へのアクセス。 ローカルにインストールされた Docker ランタイム 、または AWS Cloud9 クラウドベースの統合開発環境。 AWS IoT Greengrass accelerators の GitHub リポジトリへのアクセス。 ソリューションウォークスルー 今回紹介しているパターンは、 AWS IoT Greengrass accelerators  の GitHub リポジトリから入手できます。これらのパターンやその他の利用可能なパターンを調べるには、このリポジトリを開発環境にクローンし確認してください。クローンを作成したら、表示される手順に従って環境に AWS IoT Greengrass Core デバイスをセットアップし、説明されているシナリオを調べることができます。 例 説明 Base Implementation IoT Greengrass コアデバイスのプロビジョニングの基本パターンです。 Operating System Command Component 基本パターンを拡張したもので、デバイスのコマンドと制御機能の実装例を紹介しています。 AWS IoT SiteWise Deployment 基本パターンを拡張したもので、AWS IoT SiteWise を使用した OPC-UA による産業用テレメトリの取り込みを紹介しています。 各列のリンク先に記載されているデプロイ手順に従うと、すぐに使い始めることができます。これらのソリューション例をカスタマイズして、さまざまなユースケースに適応させることができます。また、既存のパターンを基盤として新しい AWS CDK スタックを作成し、独自のユースケースに合わせてカスタムコンポーネントを作成してテストすることもできます。すべてのサンプルを AWS Cloud9 にデプロイして、アーティファクトをローカルにインストールまたはデプロイしなくても、迅速に検証することができます。 クリーンアップ 追加料金が発生しないように、この記事で作成したリソースを削除してください。 作成した CloudFormation スタックを削除するには: https://console.aws.amazon.com/cloudformation/ で AWS CloudFormation コンソールを開きます。 削除するスタックを選択すると、その詳細が表示されます。 Delete  を選択し、最新のスタックから例を実行して作成された各スタックの削除を確認します。スタックが順番に削除されるのを待ちます。 まとめ この投稿では、AWS CDK、AWS IoT Greengrass、Docker を組み合わせて AWS で迅速な IoT ソリューションのプロトタイピングを実現する方法を説明しました。宣言型インフラストラクチャをコードとして使用し、コンテナ化と自動化を行うことで、パターンベースのプロトタイピングアプローチを採用して、一般的な IoT ソリューションシナリオを迅速に構築できます。コア機能の構築に費やす時間を短縮することで、IoT ソリューションの差別化と革新的な機能の実現に集中できます。これにより、市場投入までの全体的な時間も短縮されます。 詳細については、他のプロトタイプパターンの作成に役立つ AWS クラウド開発キット (AWS CDK) 、 AWS IoT Greengrass 、および AWS IoT Greengrass accelerators  を参照してください。 著者について Maxim Chernyshev Maxim Chernyshev は、AWS で鉱業、エネルギー、産業分野の顧客を担当するシニアソリューションアーキテクトです。西オーストラリア州パースに拠点を置く Maxim は、適用可能な幅広いAWSのサービスと機能を使用して、お客様が複雑で斬新な問題に対するソリューションを考案できるよう支援しています。Maxim は、産業用IoT、スケーラブルな IT/OT コンバージェンス、サイバーセキュリティに情熱を注いでいます。 この記事は Maxim Chernyshev によって書かれた  Patterns for rapid IoT solution prototyping using AWS IoT Greengrass and Docker の日本語訳です。ソリューションアーキテクトの川﨑 裕希が翻訳しました。

本記事は、製薬企業における大規模言語モデル ( LLM ) の効果が大きく期待できる様々なユースケースについて業務部門毎に整理し、AWS が提供する生成系 AI サービスと共に解説する 3 部構成のシリーズの 2 つ目のブログ記事です。 パート1 では、臨床開発でのデータクリーニング作業、メディカルライティングを始めとした文書業務の効率化について、ファーマコビジランス部門での AI アプリケーションを利用した SNS 上の有害事象を検知について説明しました。パート 2 では、メディカルアフェアーズ部門での社内レビュー業務の効率改善、マーケティング部門における医療関係者向け、患者さん向けの生成系 AI チャットボットの有用性ついて説明します。 ユースケース＃3：メディカルアフェアーズ 社内のメディカルエキスパートをアナログなレビュープロセス、文書管理から解放する 製薬企業が医療関係者向けに行うプロモーション活動には、適正使用などの観点から薬機法、医療用医薬品プロモーションコードなど様々なルールが設けられており、確実な順守が求められています。このルールは年々厳格化しており、製薬企業が医療関係者向けに開催する講演会等で使用される発表スライドは、事前に社内レビューが実施されています。これらのレビュー業務は、メディカルアフェアーズ部門のメディカルエキスパート（医師、または医学系学位保持者）を中心に医科学的な妥当性、正確性、コンプライアンスなど複数の観点から行われています。特にコロナ禍に伴う企業主催のオンラインセミナーの増加を背景に、レビュー業務の負担が急激に増加しています。 この課題に対し、AI と機械学習を用いることで効率的なレビューを実施できる可能性があります。具体的には、スライドに記載された情報を AI が解析し、適正使用の観点から予め設定した注視すべきポイントが含まれるスライドにアラームを発し、レビューワーの確実な検証と適切な資料作成を支援するサービスが国内で展開されています。レビュー業務の生産性を大幅に改善し、社内のメディカルエキスパートがより医科学的、戦略的な活動にフォーカスできるようになります。 製薬企業が医療関係者に提供する情報の特徴の一つは、透明性が高く、説明可能な情報、参照元が明確であることです。医師や薬剤師に提供される情報は、常に医科学的に検証された“出処が明らかな内容”で回答する必要があります。一方で、外部からの問い合わせは、製品情報から疾患情報、最新論文まで非常に多岐に渡ります。そのため、担当部門では、社内外の何千もの医療情報ソースを分析し、大量の Q＆A を準備する必要があります。この準備プロセスには、膨大な裏付け調査、評価、データ統合が必要になり、正確な回答を効率的に導き出す環境の構築には非常に多くの労力を要しています。この課題に対する一つの解決策として、生成系 AI を活用したチャットボットの可能性を紹介したいと思います。 医療関係者向けのチャットボットは、24 時間 365 日の問い合わせ対応を可能にし、医療従事者や患者さんなど利用者の利便性向上を図る目的として、様々な製薬企業から提供されています。厚生労働省の調べによると、平均1社当たりの問い合わせ件数は、1カ月に約 2026 件で、その 97 ％以上が医療関係者からの問い合わせです。問い合わせの多い製薬企業では 1 カ月に 6000 件以上と報告されており、チャットボットは、お客様からの大量の問い合わせに対応するためには欠かせないツールと言っても過言ではないでしょう（ 厚生労働省, 2022 ）（ 第一三共, 2022 ）問い合わせに対しては、社内で承認、確認された内容から正確な情報をお伝えすることが重要となります。 その観点において、AWS の生成系 AI を活用したチャットボットでは、企業規模で正確な回答を合成することができます。予め準備した信頼できるデータレポジトリ（社内の参照元）に接続し、自然言語クエリを実行して、これらの信頼できるデータソースの内容に応じた回答を数秒で生成することができます。加えて、回答生成に使用されたデータ参照元をリファレンスとして表示することで、情報の正確性を検証することも可能になります。なお詳細は、後述の「責任ある AI のためのアプローチ」で記載しています。 ユースケース＃4：マーケティング 生成系 AI チャットボットは、患者さんと製薬企業をつなぐエンゲージメントチャネルになるのか？ 昨今、製薬企業では患者サポートプログラム( PSP : Patient Support Program )への取り組みが盛んになっています。その理由の一つとして、癌や難病といったスペシャリティ医薬品の増大に伴い、抗癌剤など外来治療（通院注射）が一般化されたことで、患者支援、副作用マネジメントの重要性が高まっているからと考えられます。加えて、新型コロナウイルス感染症による受診控えや治療中断を防ぐ手段として、PSP を通じて直接、患者にコミュニケーションを取ることで、患者の QOL やアドヒアランス改善、治療アウトカムの向上につなげたいという企業の意識変化、患者中心の企業活動が強化されている影響と考えられます。 PSP では、自社の医薬品を使用する患者さんに対し、疾患や治療に関する情報提供、注射手技の解説などの資材提供だけにとどまらず、疾患に特化した治療管理アプリ、服薬管理用のデバイスやオンライン診療など様々なデジタルサービスを組み合わせた患者支援プラットフォームとして提供されることも少なくありません。患者向けチャットボットは、これらの患者支援プラットフォーム上で、患者さんが日常生活に抱える疑問や不安を気軽に相談できるツールとして提供されるケースが増えています。 一方で、従来の AI チャットボットのコミュニケーションはまだ機械的な感じがする、あるいは質問の意図とは違った回答が表示されて回答が的を射ていないと思われる人もいるかもしれません。このような疑問に対して、カリフォルニア大学サンディエゴ校（ UCSD ）が、2023 年に患者向け生成系 AI チャットボットを利用した医師と患者のエンゲージメントについて、非常に興味深い研究結果を報告しています（ John W. Ayers, 2023 ） 図表： Boston Consulting Group Article, July 2023 この研究では、医療系 SNS に患者から寄せられた質問 195 件をランダムに抽出し、医師の回答と生成系 AIの回答を「回答された情報の質」「文章から受ける思いやり」の二つの観点から評価し、比較検討しています。評価は 5 段階で（ 1 が最も悪く、5 が最も良い）医療専門家が行っています。 その結果、「情報の質」については、良い／非常に良い以上（≧ 4 ）の割合が、チャットボット：78.5 ％、医師：22.1 ％で、チャットボットの割合が 3.6 倍有意に高いことが分かりました。 また、「思いやり」についても、ある／とてもある以上（≧ 4 ）の割合が、チャットボット：45.1 ％、医師：4.6 ％で、チャットボットの割合が 9.8 倍高かったと報告されました。 この非常に興味深い結果は、生成系 AI がチャットボットを、知りたい情報を得るという単なる検索ツールから、製薬企業と患者のより良いエンゲージメントチャネルへ進化させる日も近いという可能性と示唆を与えてくれています。 次号、Part.3 では「責任ある AI 開発のためのアプローチ」について考察し、AWS が提供する生成系AIサービスについてご紹介します。 亀田　俊樹 (Toshiki Kameda) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。 製薬業界で 20 年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略（ DTx 含む）を得意としている。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブと BBQ。

こんにちは、アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクトの川島です。2023 年 10 月 19 日に AWS for Games Live を開催いたしました。 AWS for Games Live とは？ AWS for Games Live は、AWS 公式ウェブマガジン builders.flash の記事と連動したイベントで、AWS for Games の 3 つの柱「Build」「Run」「Grow」の柱のうち 1 つにフォーカスを当てて、その内容を掘り下げるものです。参加者の方々には、ゲーム業界のトレンドを知ったりネットワーキングを楽しんだりする時間として活用していただいています。今回は、「これからのゲームデータ分析環境を考える」と題して、AWS でのゲーム分析について 4 つのセッションを設けました。 AWS でこれから始めるゲーム分析 はじめに、ソリューションアーキテクト渡邉 真太郎から、ゲームを改善するための分析を予算や工数が限られたなかで進めていくために、サーバーレスな分析サービスを組み合わせた AWS でのゲーム分析の導入例をご紹介しました。資料は こちらのリンク からご覧いただけます。 本セッションでは最初に、Amazon Aurora にある基本 KPI データをエンジニアが SQL でアドホックに集計して制作チームに共有している状況を仮定しました。このとき、集計の処理時間の長期化や集計対応の工数が課題として想定されます。そこで第一に、Amazon Redshift Serverless というクラスター管理不要のクラウドデータウェアハウスを導入し、Amazon Aurora との Zero-ETL 統合をセットアップします。Amazon Aurora と Amazon Redshift の Zero-ETL 統合は現在 機能の制限 がある Public Preview のものであり、後段のセッションで詳しく紹介します。第二に、幅広いメンバーが定常的にデータを確認・分析するための可視化に、サーバーレスな BI サービスである Amazon QuickSight を導入します。 しかしこれでもなお、基本 KPI データだけではゲーム内のユーザーの動向を定量的に確認することができず、この課題を解消するためにはユーザー行動ログも出力し分析する必要があります。そこで第三に、Amazon Kinesis Data Firehose によりゲームサーバーやクライアントからユーザー行動ログを吸い出して Amazon Redshift Serverless に格納します。これにより、分析に必要な基本 KPI データとユーザー行動ログの双方を分析・可視化できるようになります。 このようにAWSのサーバーレスな分析サービスを組み合わせていくことで分析要件の変化に応じてゲーム分析環境を発展させられることをお話ししました。 Amazon Aurora と Amazon Redshift の Zero-ETL 統合のご紹介 次に、同じくソリューションアーキテクトの佐藤 祥多から、Amazon Aurora と Amazon Redshift の Zero-ETL 統合 (以下単に「Zero-ETL 統合」) についてご紹介しました。資料は こちらのリンク からご確認ください。 Zero-ETL 統合は、ETL パイプライン不要で複数の Amazon Aurora データベースから Amazon Redshift に対して数秒以内にデータを複製できる、現在 Public Preview 中の機能です。現在は Amazon Aurora MySQL の一部バージョンのみをサポートしています。内部では Amazon Aurora の拡張 Binlog を利用してデータ複製をしているため、MySQL クラスタへの負荷を最小限に抑えられることや Crash recovery の時間が大幅に改善していることも特徴です。本機能は、ETL の運用軽減・データベースへの負荷軽減・リアルタイムでの可視化といった用途でお使いいただけます。 本セッションでは、ゲーム内の仮想通貨の動きをリアルタイムで可視化するデモもお見せしました。クライアントから送られた情報が、Amazon Aurora から Amazon Redshift に同期され、Amazon Managed Grafana で可視化されるという一連の流れをお見せし、設定の簡単さやリアルタイム性を実感していただける内容でした。 Amazon Aurora MySQL と Amazon Redshift の Zero-ETL 統合について使い所を考えてみた！ 続いて、面白法人カヤックの池田 将士氏から、Zero-ETL 統合の具体的な使い道やメリットについてご紹介をいただきました。資料は こちらのリンク からご覧いただけます。 池田氏が Zero-ETL 統合のメリットを論じるにあたって挙げたキーワードは「VPC 超え」でした。 Amazon Aurora と Amazon Redshift が異なる VPC にある場合、VPC を跨いだデータ搬送が必要になります。この「VPC 超え」の状況は、複数ゲームタイトルの統合的な分析のための分析用アカウントを用いるクロスアカウント分析の場合などに発生します。そして、そのときに Zero-ETL 統合のメリットが大きいというのが池田氏の着目する点です。「VPC 超え」のデータ搬送においては、これまで、Amazon S3 のスナップショットを経由する方法や VPC Peering で Federated Query もしくは変更データキャプチャ (CDC) を用いる方法、パブリックアクセスで AWS IAM を用いて権限を付与する方法といったものがありました。しかし、それぞれの方法で、リアルタイム性や管理の手間といった課題はありました。一方で Zero-ETL 統合なら、AWS マネージドかつニアリアルタイムで、VPC やアカウントが異なっていても CDC ができるという旨味があります。 一方で、Amazon Aurora と Amazon Redshift が同一 VPC 内に存在するときは、Federated Query で十分な場合もあります。しかしながら、それでも Zero-ETL 統合により享受できるメリットもあります。第一に、大量のデータを扱うときには Federated Query では Amazon Aurora 側の読み込み負荷が気になるため、Zero-ETL 統合によりその負荷を軽減できます。第二に、Amazon Aurora MySQL は行指向のデータベース、Amazon Redshift は列指向のデータベースなので、Zefo-ETL 統合を導入して両者を使い分けながらクエリを操作することで、効率的に分析できるようになります。これにより、HTAP (Hybrid Transactionla/Analytical Processing) と呼ばれる、トランザクション処理と分析処理の両方が行えるデータベースと同じような使い方が実現できるのです。 モンストシリーズでのデータ分析戦略 最後に、株式会社 MIXI の白川 裕介氏から、モンストシリーズにおけるデータ分析戦略についてご紹介をいただきました。資料は こちらのリンク からご覧いただけます。 モンストシリーズは 1 年弱で 6 個と多くのタイトルが出ており、内製開発と他社による開発のいずれもが共存しておりました。当初は各デベロッパーが個別最適化しながらゲーム開発していたのですが、その点に課題を感じた MIXI では統一されたルールを定義しました。そのなかで、今回は KPI などのデータ分析の方針のルールを取り上げてご紹介いただきました。 第一に、ログイン・課金・ゲームプレイといった全タイトルで共通の KPI ログを定義し、ログフォーマットも共通化して同じクエリで分析できるようにしています。加えて、それ以外の各タイトル固有の KPI ログは個別に取得しています。ログの取得は MIXI で検証して開発社にサンプルの実装を提供しました。 第二に、KPI ログの転送では、Amazon Kinesis Agent・Amazon Kinesis Data Streams・Amazon Kinesis Data Firehose を用いたデータ転送フローの標準仕様を策定しました。なお、Amazon Kinesis Data Streams がなくても構成は可能ですが、Amazon Kinesis Data Firehose の仕様上 PutRecord 時のデータごとの改行が必要だったり、恒常的な大量の流量を捌けないことがあったりする点に注意が必要です。なお、開発社によっては Fluent Bit や CloudWatch を用いたカスタマイズもしています。 第三に、Aurora MySQL スナップショットの方法にも 2 通りの方法を決めています。 1 つ目が SELECT INTO OUTFILE の SQL ステートメントを実行する方法です。ここでは、インスタンスへの負荷を考慮してリードレプリカを用いることや AWS Lambda でのタイムアウトを避けるため AWS Glue ジョブの Python Shell で実行することを推奨しています。2 つ目が Amazon S3 のエクスポート機能を用いる方法です。こちらは制約が多い代わりに簡単に実行できるものです。 以上に挙げた内容は、後から決めるのではなく最初に決めておくことが大事だと白川氏は強調しました。MIXI では、一定のルールを設けつつも後から柔軟に変更しています。そしてデータ形式やインフラの共通化により、リソースの最適化や横断的な同様のクエリでの分析の実現といったメリットがありました。 最後に 今回ご紹介したものをはじめとして、AWS 上には効率的に分析するための様々なサービスや機能があります。ゲームを発展させるのに分析は一つの重要な要素ですので、ご自身のゲームにおいてもぜひ活用をご検討ください。また、AWS for Games Live は AWS 公式ウェブマガジン builders.flash と連動して、定期的に開催しております。今回複数のセッションで紹介された現在 Public Preview 中の Zero-ETL 統合機能も、 builders.flash 内の記事 で取り上げていますので、ご興味があればぜひご覧ください。 ※この記事はTakumi Kawashimaが作成し、Hiroshi Sumiが代理で投稿しています。

AWS European Sovereign Cloud により、政府機関、規制が厳しい業界、およびそれらをサポートする独立系ソフトウェアベンダー (ISV) は、欧州連合 (EU) に所在し、かつ、EU の居住者である AWS の従業員によって運用およびサポートされる AWS インフラストラクチャ上で、機密データを保存したり、重要なワークロードを実行したりできるようになります。最初のリージョンはドイツ国内に設けられることになります。 背景 2022年末、当社は AWS Digital Sovereignty Pledge を発表し、クラウドで利用できる最先端の主権コントロールと機能のセットをお客様 (およびすべての AWS をご利用のお客様) に提供することをお約束しました。そのお知らせ以降、当社は、その誓約を守るためにいくつかの重要な一歩を踏み出しました。 2023 年 5 月 – AWS Nitro System が独立したサードパーティーによって検証され、AWS の誰かが AWS ホスト上のお客様のデータにアクセスすることを許可するいかなるメカニズムも含まれていないことが確認されたことを お知らせ しました。同時に、 AWS Key Management Service (KMS) 外部キーストア を利用することで、AWS の外部にキーを保存し、そのキーを使用して AWS に保存されているデータを暗号化できることをお知らせしました。 2023 年 8 月 – AWS 専有ローカルゾーン を 発表しました 。これは、AWS が完全に管理し、特定のお客様またはコミュニティ専用に構築され、お客様が指定する場所またはデータセンターに設けられるインフラストラクチャです。 AWS European Sovereign Cloud 今後の AWS European Sovereign Cloud は、フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム、スペイン、チューリッヒで既にオープンしている 8 つの既存の AWS リージョンとは別個であり、これらから独立したものとなります。これにより、既に使い慣れた AWS サービス、API、ツールが提供されると同時に、デプロイのための追加のオプションが提供されます。この設計は、データレジデンシー、運用上の自律性、回復力のニーズを満たすのに役立ちます。 このクラウドと既存の AWS グローバルクラウドの間の分離を維持するには、新しい AWS アカウントを作成する必要があります。作成するメタデータ (データラベル、カテゴリ、許可、設定など) は EU 内に保存されます。これは、支出データや請求データなどの AWS アカウント情報には適用されません。これらの情報は、一定量の使用と引き換えに適用される該当階層内で、有利な料金が確実に適用されるようにするために集計および使用されます。 前述のとおり、このクラウドは、EU に所在し、かつ、EU の居住者である AWS の従業員によって運用およびサポートされ、サポートは 24 時間年中無休で利用可能となる予定です。 AWS European Sovereign Cloud は、運用上、他のリージョンから独立し、別個のリージョン内の請求システムおよび使用量測定システムが使用されることになります。 初期のリージョン 初期のリージョンはドイツ国内に設けられることになります。これは、複数のアベイラビリティーゾーンを利用して立ち上げられます。これらの各アベイラビリティーゾーンは個別の異なる地理的位置に所在し、これらの間には十分な距離が確保されるため、単一のイベントがビジネスの継続性に影響を及ぼすリスクを大幅に軽減できます。 立ち上げが近づくにつれて、利用可能なサービスやインスタンスタイプなどに関するさらなる詳細が判明する予定です。 将来的には、このクラウド内のこのリージョンと他のリージョンは、 AWS Outposts および専有ローカルゾーン用の親リージョンとしても機能するようになる予定です。これらのオプションにより、分離と国内のデータレジデンシーに関してさらに柔軟な対応が可能になります。ご自身の所在国の 専有ローカルゾーン にご関心がおありの場合は、担当の AWS アカウントマネージャーにお問い合わせください。 準備を整えましょう 既存のリージョンのいずれかで今すぐアプリケーションの構築を開始し、リージョンの立ち上げ時にそれらを AWS European Sovereign Cloud に移行できます。特定のリージョンに固有の問題をより深く理解するために、現地の規制当局との対話を開始することもできます。 – Jeff ; 原文は こちら です。

AWS ニュースブログチームの全員が、ラスベガスで行われる毎年恒例のカスタマーカンファレンス、 AWS re:Invent の開催中に新しいサービスと機能を発表するための記事の執筆に全力で取り組んでいます! そして、私たちが皆さんに読んでいただくためのコンテンツを準備している間も、AWS のサービスチームは革新し続けています。以下は、10月16日週のリリースの概要です。 10月16日週のリリース 私が関心を持ったリリースをいくつかご紹介しましょう。 Amazon CodeCatalyst – CI/CD ワークフローをトリガーするための cron 式を追加できるようになりました。 これは、ワークフローを指定された時間に開始する手段を提供します。CodeCatalyst は、プロジェクトのコラボレーションツール、CI/CD パイプライン、および開発環境とデプロイ環境を統合する統合開発サービスです。 Amazon Route53 – お客様のトラフィックをお客様に最も近い AWS Local Zones にルーティング して、レイテンシーの影響を受けやすいワークロードのアプリケーションパフォーマンスを向上させることが可能になりました。詳細については、Route53 のドキュメントの「 Geoproximity routing 」を参照してください。 Amazon RDS – AWS がお客様のデータベースの TLS 証明書に署名するために使用するルート証明書は、2024 年に有効期限が切れます。データベース用の新しい証明書は、有効期限日の前に生成しておく必要があります。 このブログ記事には、そのステップバイステップ手順が詳しく説明されています 。AWS が生成した新しいルート証明書の有効期間は、 RSA2048 では今後 40 年、 RSA4098 および ECC384 では 100 年になります。AWS のデータベース証明書を更新する義務を負うのは、皆さんのプロとしてのキャリアの中でこれが最後になるでしょう。 Amazon MSK – Kafka クラスターを大規模に複製することは困難で、大抵の場合は、インフラストラクチャとレプリケーションソリューションを独自に管理しなければなりません。AWS は、同じ AWS リージョン内、または複数の AWS リージョンにまたがる Kafka クラスターのためのフルマネージドレプリケーションソリューション、 Amazon MSK Replicator の提供を開始しました。 Amazon CodeWhisperer – Amazon CodeWhisperer Professional の次なる機能のプレビューが開始されました。 これからは、プライベートコードベースで CodeWhisperer をトレーニングできるようになります 。この機能は、より適切な提案を組織の開発者に提供することによって、組織のプライベートライブラリやフレームワークに対する毎日のコーディングで開発者をよりよくサポートできるようにします。 Amazon EC2 – 第 7 世代のメモリ最適化 EC2 インスタンス (R7i) が利用可能になりました 。これらのインスタンスは、第 4 世代インテル Xeon スケーラブルプロセッサー ( Sapphire Rapids ) を使用しています。このインスタンスファミリーは、最大 192 個の vCPU と 1,536 GB のメモリを提供します。これらは、インメモリデータベースやキャッシュなどのメモリ集約型アプリケーションに最適です。 X in Y – 追加のリージョンで既存のサービスとインスタンスタイプの提供が開始されました。 Amazon Bedrock が欧州 (フランクフルト) で利用可能になりました 。ヨーロッパのお客様は、そのデータが欧州連合内に維持されることを確実にしなければならない場合が多いため、この機能はこれらのお客様にとって重要です。これからは、プロンプトやカスタム設定がヨーロッパ内に維持されるという確信を持ったうえで、アプリケーションに生成系 AI 機能を組み込み、大規模言語モデルにアクセスすることができるようになります。 Amazon EC2 が、複数のインスタンスファミリーのフットプリントを拡大し、カナダ (中部) と南米 (サンパウロ) で m6gd インスタンス 、 カナダ (中部) で c6a インスタンス、カナダ (中部) と欧州 (ミラノ) で m6a インスタンス、そして米国西部 (北カリフォルニア) とアジアパシフィック (シンガポール) で r6a インスタンス の提供を開始しました。最後に、欧州 (チューリッヒ) では m6id インスタンスが利用できるようになりました 。 Amazon EMR Managed Scaling がアジアパシフィック (ジャカルタ) で利用可能になりました。 その他の AWS ニュース 以下は、皆さんが興味を持つと思われるその他のブログ記事とニュースです。 Community.AWS ブログが、 Java アプリケーションと Go アプリケーション内に Amazon Bedrock を統合する方法を説明する新しい記事を発表しました。また、私の同僚である Brooke も、 re:Invent に初めて参加する人のためのサバイバルガイド を書きました。 AWS の公式ポッドキャスト  – 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS ニュースのすばらしい情報源には、他にも次のようなものがあります。 AWS Open Source Newsletter AWS Graviton Weekly AWS Cloud Security Weekly Last Week in AWS 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしてください。 AWS Community Days – お住まいの地域の AWS ユーザーグループリーダーが運営する、コミュニティ主導のカンファレンスに参加しましょう。このカンファレンスは、 ジャイプル (11 月 4 日)、 ヴァドーダラー (11 月 4 日)、および ブラジル (11 月 4 日) で開催されます。 AWS Innovate: Every Application Edition – 無料のオンラインカンファレンスに参加して、 セキュリティと信頼性の強化、限られた予算でのパフォーマンスの最適化、アプリケーション開発の迅速化を行い、生成系 AI を用いてアプリケーションに大革新をもたらすための最先端の方法を探りましょう。10 月 26 日に開催される AWS Innovate Online アジアパシフィック & 日本 にぜひ登録してください。 AWS re:Invent (11 月 27 日～12 月 1 日) – このカンファレンスに参加 して、AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 セッションカタログ と 参加者ガイド を参照して、 生成系 AI の re:Invent ハイライト を確認してください。 近日開催される対面イベントと仮想イベントのすべてを閲覧することができます。 10月23日週のニュースは以上です。re: Invent ブログ記事の執筆に戻ろうと思います。 10月30日週の Weekly Roundup もお楽しみに! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) コンソールで [証明書の更新] を目にしても驚かないでください。 Amazon RDS for MySQL、MariaDB、SQL Server、Oracle、PostgreSQL、Amazon Aurora のデータベースインスタンスに接続するために、Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を証明書の検証とともに使用しているか、または使用する予定がある場合、ルート証明書の有効期限が切れる前に、DB インスタンスとアプリケーションの両方で新しい認証機関 (CA) 証明書をローテーションする必要があります。 DB インスタンスのほとんどの SSL/TLS 証明書 ( rds-ca-2019 ) は、 2020 年の証明書の更新 後、2024 年に期限切れになります。2022 年 12 月に、40 年間有効な CA 証明書 ( rds-ca-rsa2048-g1 ) と 100 年間有効な CA 証明書 ( rds-ca-rsa4096-g1 および rds-ca-ecc384-g1 ) を新しくリリースしました。これにより、CA 証明書をローテーションした後、長期にわたって、再度ローテーションする必要はありません。 影響を受けるリージョンと、それらの rds-ca-2019 の有効期限の一覧を次に示します。 有効期限 リージョン 2024 年 5 月 8 日 中東 (バーレーン) 2024 年 8 月 22 日 米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (ストックホルム)、および南米 (サンパウロ) 2024 年 9 月 9 日 中国 (北京)、中国 (寧夏) 2024 年 10 月 26 日 アフリカ (ケープタウン) 2024 年 10 月 28 日 欧州 (ミラノ) 2061 年まで影響なし アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、欧州 (スペイン)、欧州 (チューリッヒ)、イスラエル (テルアビブ)、中東 (UAE)、AWS GovCloud (米国東部)、および AWS GovCloud (米国西部) 次のステップでは、アプリケーションからデータベースインスタンスへの接続を維持するために証明書をローテーションする方法を示します。 ステップ 1 – 影響を受ける Amazon RDS リソースを特定する 前述したように、 Amazon RDS コンソール の [証明書の更新] ページで影響を受ける DB インスタンスの総数を確認し、影響を受けるすべての DB インスタンスを表示できます。注: このページには、現在のリージョンの DB インスタンスのみが表示されます。複数のリージョンに DB インスタンスがある場合は、各リージョンの証明書の更新のページを確認して、古い SSL/TLS 証明書を使用しているすべての DB インスタンスを表示します。 また、 AWS コマンドラインインターフェイス (AWS CLI) を使用して describe-db-instances を呼び出し、期限切れの CA を使用するインスタンスを見つけることもできます。クエリにより、アカウントと us-east-1 リージョン内の RDS インスタンスのリストを表示できます。 $ aws rds describe-db-instances --region us-east-1 | jq -r '.DBInstances[] | select ((.CACertificateIdentifier != "rds-ca-rsa2048-g1") and (.CACertificateIdentifier != "rds-ca-rsa4096-g1") and (.CACertificateIdentifier != "rds-ca-ecc384-g1")) | "DBInstanceIdentifier: (.DBInstanceIdentifier), CACertificateIdentifier: (.CACertificateIdentifier)"' ステップ 2 – データベースクライアントとアプリケーションを更新する DB インスタンスに新しい証明書を適用する前に、接続するために SSL/TLS およびサーバー証明書を使用するクライアントとアプリケーションの信頼ストアを更新する必要があります。 現在、アプリケーションが接続するための前提条件として証明書の検証が必要かどうかを、DB インスタンス自体から簡単に判断する方法はありません。ここでの唯一のオプションは、アプリケーションのソースコードまたは設定ファイルを検査することです。 DB エンジン固有のドキュメント には、極めて一般的なデータベース接続インターフェイスで注意すべき点が概説されていますが、証明書の検証が使用されているかどうか、および特定のクライアントアプリケーションのためにアプリケーションの SSL/TLS 証明書を更新する正しい方法をアプリケーションデベロッパーに確認することを強くお勧めします。 アプリケーションの証明書を更新するために、古い CA と新しい CA の両方の証明書を含む 新しい証明書バンドル を使用できます。これにより、アプリケーションを安全にアップグレードし、移行期間中も接続を維持できます。 各 DB エンジンについての SSL/TLS 接続の確認とアプリケーションの更新については、次のトピックを参照してください。 新しい SSL/TLS 証明書を使用して MariaDB DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Microsoft SQL Server DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して MySQL DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Oracle DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して PostgreSQL DB インスタンスに接続するようにアプリケーションを更新する 新しい SSL/TLS 証明書を使用して Aurora MySQL DB クラスターに接続するようにアプリケーションを更新する 。 新しい SSL/TLS 証明書を使用して Aurora PostgreSQL DB クラスターに接続するようにアプリケーションを更新する 。 ステップ 3 – 非本番 RDS インスタンスで CA ローテーションをテストする すべての信頼ストアで新しい証明書を更新した場合は、非本番環境で RDS インスタンスを使用してテストする必要があります。この設定は、本番環境と同じデータベースエンジンとバージョンを備えた開発環境で実行します。また、このテスト環境は、本番と同じコードと設定を使用してデプロイする必要があります。 テストデータベースインスタンスで新しい証明書をローテーションするには、 Amazon RDS コンソール で、変更する DB インスタンスについて [変更] を選択します。 [接続] セクションで、 rds-ca-rsa2048-g1 を選択します。 [続行] を選択して、変更の概要を確認します。変更をすぐに適用する場合は、 [すぐに適用] を選択します。 AWS CLI を使用して DB インスタンスのために CA を rds-ca-2019 から rds-ca-rsa2048-g1 に変更するには、 modify-db-instance コマンドを呼び出し、 --ca-certificate-identifier オプションを使用して DB インスタンス識別子を指定します。 $ aws rds modify-db-instance \ --db-instance-identifier <mydbinstance> \ --ca-certificate-identifier rds-ca-rsa2048-g1 \ --apply-immediately これは、本番データベースインスタンスで新しい証明書を手動でローテーションする方法と同じです。参照した信頼ストアまたは CA 証明書バンドルを使用したローテーションの後、アプリケーションが SSL/TLS を使用して問題なく再接続することを確認します。 新しい DB インスタンスを作成する場合、デフォルトの CA は 2024 年 1 月 25 日までは rds-ca-2019 のままですが、その後は rds-ca-rsa2048-g1 に変更されます。新しい CA を設定して新しい DB インスタンスを作成する場合、CA オーバーライドを設定して、すべての新しいインスタンスの起動で任意の CA が使用されるようにできます。 $ aws rds modify-certificates \ --certificate-identifier rds-ca-rsa2048-g1 \ --region <region name> これは、RDS DB インスタンスが存在するすべてのリージョンで行う必要があります。 ステップ 4 – 本番 RDS インスタンスを安全に更新する 非本番環境でのテストが完了したら、本番環境で RDS データベース CA 証明書のローテーションを開始できます。ステップ 3 に示すように、DB インスタンスを手動でローテーションできます。今日のエンジンの多くは再起動を必要としませんが、メンテナンス期間に再起動をスケジュールすることが推奨されることにご留意ください。 ステップ 1 の [証明書の更新] ページで、ローテーションする DB インスタンスを選択します。 [スケジュール] を選択すると、次のメンテナンス期間に証明書のローテーションをスケジュールできます。 [今すぐ適用] を選択すると、ローテーションをすぐに適用できます。 [スケジュール] を選択すると、証明書のローテーションを確認するよう求めるプロンプトが表示されます。このプロンプトは、更新のスケジュールウィンドウも示します。 (すぐに、またはメンテナンス期間中に) 証明書が更新された後、データベースとアプリケーションが想定どおりに動作していることを確認する必要があります。 今日の DB エンジンのほとんどでは、証明書を更新するためにデータベースを再起動する必要はありません。CA 更新のためだけにデータベースを再起動したくない場合は、 modify-db-instance コマンドで --no-certificate-rotation-restart フラグを使用できます。 $ aws rds modify-db-instance \ --db-instance-identifier <mydbinstance> \ --ca-certificate-identifier rds-ca-rsa2048-g1 \ --no-certificate-rotation-restart エンジンの再起動が必要かどうかを確認するには、 describe-db-engine-versions コマンドの出力で SupportsCertificateRotationWithoutRestart フィールドを確認します。このコマンドを使用すると、再起動なしでのローテーションをサポートしているエンジンを確認できます。 $ aws rds describe-db-engine-versions \ --engine <engine> --include-all --region <region> | jq -r '.DBEngineVersions[] | "EngineName: (.Engine), EngineVersion: (.EngineVersion), SupportsCertificateRotationWithoutRestart: (.SupportsCertificateRotationWithoutRestart), SupportedCAs: ([.SupportedCACertificateIdentifiers | join(", ")])"' データベースインスタンスのために SSL/TLS を使用しない場合でも、CA をローテーションすることをお勧めします。将来的に SSL/TLS を使用する必要がある場合があります。その場合、JDBC コネクタや ODBC コネクタなどの一部のデータベースコネクタは、接続する前に有効な証明書をチェックします。その際、CA の期限が切れていると、SSL/TLS を使用できない可能性があります。 DB インスタンスを手動で変更することによる証明書の更新、サーバー証明書の自動ローテーション、信頼ストアに証明書をインポートするためのサンプルスクリプトの検索の詳細については、「 Amazon RDS ユーザーガイド 」または「 Amazon Aurora ユーザーガイド 」を参照してください。 留意点 知っておくべき重要な事項をいくつか次に示します。 Amazon RDS Proxy と Amazon Aurora Serverless は、 AWS Certificate Manager (ACM) からの証明書を使用します。SSL/TLS 証明書をローテーションする際に Amazon RDS Proxy を利用している場合は、Amazon RDS Proxy 接続を使用するアプリケーションを更新する必要はありません。Aurora Serverless を利用している場合、SSL/TLS 証明書をローテーションする必要はありません。 現在から 2024 年 1 月 25 日 まで – 新しい RDS DB インスタンスには、 create-db-instance API の ca-certificate-identifier オプションで別の CA を指定しない限り、デフォルトで rds-ca-2919 証明書が含まれます。または、上記のセクションで言及したように、アカウントのためにデフォルトの CA オーバーライドを指定します。 2024 年 1 月 26 日 以降 – 新しいデータベースインスタンスは、 rds-ca-rsa2048-g1 証明書を使用するようデフォルト設定されます。新しいインスタンスのために別の証明書を使用することを希望する場合は、AWS コンソールまたは AWS CLI を使用して、どの証明書を使用するかを指定できます。詳細については、 create-db-instance API ドキュメント を参照してください。 Amazon RDS for SQL Server を除き、今日の RDS および Aurora エンジンのほとんどは、その最新バージョンにおいて、データベースの再起動なしでの証明書のローテーションをサポートしています。 describe-db-engine-versions を呼び出し、応答フィールド SupportsCertificateRotationWithoutRestart を確認します。このフィールドが true に設定されている場合、インスタンスでは CA 更新のためにデータベースを再起動する必要がありません。 false に設定すると、再起動が必要になります。詳細については、AWS ドキュメントの「 データベースのために CA を設定する 」を参照してください。 ローテーションされた CA は、各 DB インスタンスにインストールされる DB サーバー証明書に署名します。DB サーバー証明書は、信頼されたサーバーとして DB インスタンスを識別します。DB サーバー証明書の有効期間は、DB エンジンとバージョンによって異なり、1 年間または 3 年間です。CA がサーバー証明書の自動ローテーションをサポートしている場合、RDS は DB サーバー証明書のローテーションも自動的に処理します。DB サーバー証明書のローテーションの詳細については、AWS ドキュメントの「 サーバー証明書の自動ローテーション 」を参照してください。 40 年間有効な証明書 ( rds-ca-rsa2048-g1 ) または 100 年間有効な証明書を使用することを選択できます。RDS インスタンスによって使用される期限切れの CA は、RSA2048 鍵アルゴリズムと SHA256 署名アルゴリズムを使用します。 rds-ca-rsa2048-g1 はまったく同じ設定を使用するため、互換性の点で最適です。100 年間有効な証明書 ( rds-ca-rsa4096-g1 および rds-ca-ecc384-g1 ) は、 rds-ca-rsa2048-g1 よりも安全な暗号化スキームを使用します。これらを使用する場合は、本番前環境で十分にテストし、データベースクライアントとサーバーがリージョンで必要な暗号化スキームをサポートしていることをダブルチェックする必要があります。 すぐに始めましょう! 証明書の有効期限が切れるまであと 1 年間ある場合でも、チームと連携して計画を開始すべきです。SSL/TLS 証明書を更新するには、有効期限が切れる前に DB インスタンスを再起動する必要がある場合があります。有効期限前にアプリケーションを更新するようにスケジュールし、本番環境でこれらのステップを完了する前に、ステージングまたは本番前のデータベース環境でテストを実行することを強くお勧めします。SSL/TLS 証明書の更新の詳細については、「 Amazon RDS ユーザーガイド 」および「 Amazon Aurora ユーザーガイド 」を参照してください。 SSL/TLS 接続を使用しない場合、データベースセキュリティのベストプラクティスは、SSL/TLS 接続を使用し、接続認証プロセスの一部として証明書の検証をリクエストすることです。SSL/TLS を使用して DB インスタンスへの接続を暗号化する方法の詳細については、「 Amazon RDS ユーザーガイド 」および「 Amazon Aurora ユーザーガイド 」を参照してください。 ご質問や問題がある場合は、ご利用のサポートプランに応じて、通常の AWS サポート までお問い合わせください。 – Channy 原文は こちら です。

モダンアプリケーションは、モジュール式かつ分散型のコンポーネントで構築されています。お客様は、特にハイブリッドクラウド環境において、サービスコンポーネント間のアプリケーションネットワーキングをシンプル化する柔軟な方法を求めています。 VMware Cloud on AWS を利用することで、お客様はオンプレミスの vSphere 環境からのワークロードとアプリケーションをシームレスなハイブリッドクラウド体験で Software Defined Data Center (SDDC) に簡単に移行できます。 ワークロードを VMware Cloud on AWS に移行するにつれ、SDDC 上で実行されている既存のアプリケーションと、ネイティブ AWS サービスを使用してデプロイされた新しいサービスとの接続要件に対処することが不可欠となってきます。 異なる AWS アカウントや Amazon Virtual Private Cloud (VPC) 間のサービス接続をサポートするには通常、 VPC ピアリング 、 AWS Transit Gateway 、 AWS PrivateLink 、 サービスメッシュ プロキシなど、追加のネットワーキングサービスとコンポーネントをプロビジョニングする必要があります。 さらに、複数の AWS アカウントと VPC を持つお客様は、重複する CIDR ブロックや環境分離の要件などの課題に直面することが多く、サービス間のアンダーレイとなる IP 接続性の構築をさらに複雑にします。 この記事では、 Amazon VPC Lattice が SDDC やクラウドネイティブ環境全体のサービス間通信を、アンダーレイネットワークの複雑さを抽象化しながらシンプル化する方法を見ていきます。また、VPC Lattice を活用して、VMware Cloud on AWS からクラウドネイティブサービスへアプリケーションをシームレスに変換、移行できることも説明します。 Amazon VPC Lattice 概要 2023 年 3 月、AWS はアプリケーションネットワーキングサービス「Amazon VPC Lattice」の 一般提供を発表 しました。VPC Lattice は、サービス間通信のディスカバリと接続を容易にするものです。 VPC Lattice は、論理的なアプリケーションレイヤーネットワークである サービスネットワーク を作成します。これにより、異なる AWS アカウントや Amazon VPC 間でのサービスネットワーク全体のクライアント (コンシューマー) とサービス (プロバイダー) 間のアプリケーション通信を、アンダーレイネットワークの複雑さを抽象化してシンプル化します。 以下の図を元に Amazon VPC Lattice の主なコンポーネントを確認しましょう。 図1 – Amazon VPC Lattice の主なコンポーネント サービス : VPC Lattice サービスは、特定のタスクや機能を提供するカスタマーアプリケーションを表します。サービスは、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、サーバーレス関数など、さまざまなコンピュートオプションで実行できます。VPC Lattice サービスは、 AWS Resource Access Manager (RAM) を使用して他の AWS アカウントと共有できます。VPC Lattice サービスには、次の要素が含まれます。 ターゲットグループ – アプリケーションやサービスを提供するリソースの集まりです。ターゲットには、EC2 インスタンス、IP アドレス、 AWS Lambda 関数、 Application Load Balancer 、 Kubernetes Pod を指定できます。 リスナー – 定義されたプロトコル (HTTP/HTTPS) とポート番号に基づいて、ターゲットグループ内のターゲットに接続リクエストをルーティングするプロセスです。 ルール – 優先順位、条件、アクションが定義されたアプリケーションフローを制御するルーティングルールです。 サービスネットワーク : サービスの集合を論理的に区切る境界。VPC Lattice サービスと VPC をサービスネットワークに関連付けて、サービス接続を容易にすることができます。RAM を使用して、サービスネットワークを他のアカウントと共有することもできます。 サービスディレクトリ : 所有または RAM 経由で共有されているすべての VPC Lattice サービスの中央レジストリ。 認証ポリシー : サービスへのアクセスを制御するために、サービスネットワークまたはサービスに関連付けることができる AWS Identity and Access Management (IAM) ポリシー。 VPC がサービスネットワークと関連付けられると、VPC 内のクライアントは Domain Name System (DNS) を使用して、サービスネットワークに登録されたサービスを自動的に検出できるようになります。さらに、登録済みサービスのすべてのアプリケーション間トラフィックは VPC Lattice を通過するようになります。 VPC Lattice は、IAM ベースの認証ポリシーを使用したコンテキスト固有の認証によって、アプリケーション接続のセキュリティも強化します。これにより、顧客は細かいトラフィック制御とエンドツーエンドの可観測性が得られます。 VPC Lattice の詳細については、この ブログ記事 と Amazon VPC Lattice リファレンスアーキテクチャ を参照してください。 VMware Cloud on AWS と VPC Lattice の統合 SDDC ENI を介した Application Load Balancer の活用 VMware Cloud on AWS 上で実行されているアプリケーションを Amazon VPC Lattice と統合するには、Application Load Balancer が必要です。これは、VPC Lattice が一意のリンクローカルアドレスレンジの 169.254.171.0/24 を使用しているためです。このアドレスレンジは VPC 内でのみローカルにアクセス可能で、SDDC 外部にルーティングできません。 そこで、 Connected VPC 内に Application Load Balancer をデプロイすることで、 VPC Lattice からの着信リクエストを終端できます。これにより、広帯域かつ低レイテンシの SDDC Elastic Network Interface (ENI) を使用して、SDDC 上にホストされているワークロードにアプリケーションフローを IP ターゲット としてルーティングできます。サンプルアーキテクチャは以下の通りです。 図2 – Application Load Balancer を介した SDDC ENI 統合   SDDC と Connected VPC 間のデータ転送は、SDDC とネイティブサービスが同じ AWS アベイラビリティーゾーン (AZ) 内にデプロイされている限り、いかなる egress 通信コストも発生しません。 以下のスクリーンショットに示すように、Connected VPC 内に 内部 Application Load Balancer をプロビジョニングすると、 ユーザーガイド に従って、SDDC 上で実行されているアプリケーション向けの Lattice ターゲットグループ (およびサービス) を作成できます。 図3 – VPC Lattice ターゲットグループとして Application Load Balancer を登録  VMware Transit Connect を介した Application Load Balancer の活用 Application Load Balancer を Lattice サービスとは分けた VPC に展開し、 VMware Transit Connect を介してアプリケーショントラフィックを SDDC に渡すという選択肢もあります。以下の図のような構成です。 図4 – VMware Transit Connectを介した Application Load Balancer の統合 これは、Application Load Balancer がセキュリティ検査の要件のために Central Ingress VPC に展開されている場合に有効です。サービスネットワークは、別の AWS アカウントに存在し、AWS RAM を使用して ingress VPC と共有されることもあります。 VMware Transit Connect は、VMware が管理する AWS Transit Gateway ソリューションで、お客様のSDDC、クラウドネイティブサービス、オンプレミスリソース間の高速かつ回復性のある接続を提供します。SDDC と Amazon VPC を接続するために VMware Transit Connect をプロビジョニングする方法については、 VMware のブログ記事 を ( 日本語ブログはこちら ) 参照してください。 お客様の環境で AWS Transit Gateway をすでに利用している場合は、ingress Application Load Balancer で着信サービスリクエストを終端し、アプリケーションフローを リージョン内ピアリング を使用した AWS Transit Gateway とVMware Transit Connect 経由で SDDC に配信することが可能です。以下の図は、このサンプルアーキテクチャを示しています。 図 5 – リージョン内ピアリングによる Application Load Balancer 統合 SDDCとネイティブサービス間のアプリケーション接続のシンプル化 VMware Cloud on AWS のお客様が、アプリケーションネットワーキングをシンプル化し、変革を加速する VPC Latticeの活用例を見ていきましょう。 最初の例では、お客様はオンプレミスのアプリケーション群を VMware Cloud on AWS に移行しました。新しくSoftware-as-a-Service (SaaS) 製品のローンチを計画しており、これには SDDC-01 上のバックエンド APIサービス (Service 1) を、ネイティブ AWS 環境で最近構築された 2 つのマイクロサービス (Service2, Service3) と統合する必要があります。これらのマイクロサービスは、下の図に示すように、異なる AWS アカウントと VPC にまたがる AWS Lambda と Amazon Elastic Kubernetes Service (Amazon EKS) 上にデプロイされています。 図 6 – SDDC アプリケーションと複雑性のある AWS 環境の統合 お客様は以下のサービス統合の要件と課題があります: VPC-02 の CIDR と SDDC-01 の CIDR は一部重複しています。 VPC-03 は、外部のサービスプロバイダーが所有する別の AWS Organization の下にデプロイされているため、直接 IP 接続を確立することは許可されていません。 Service 2 と Service 3 は、Service 1 にアクセスする必要があります。 Service 2 と Service 3 は、双方向で通信する必要があります。 この場合、マルチアカウント環境における SDDC、コンテナ、サーバーレス関数全体で、セキュアかつプライベートなアプリケーション間接続を構築するために、VPC Lattice を活用できます。 VPC Lattice のユニークなリンクローカルアドレスレンジは、VPC や SDDC 間の潜在的なIPアドレスの競合問題も解消します。 まず、SDDC-01 にアタッチされた Connected VPC 内に、Service 1 の Application Load Balancer を作成する必要があります。これは、Lattice サービスはネイティブ VPC 内でのみアクセスできるため、Service 1 のすべての着信サービスリクエストを Connected VPC で終端するためです。 次に、VPC Lattice サービスネットワークを作成し、AWS RAM を介して 3 つのサービスアカウント (Account 1 ~3) と共有します。これにより、各アカウントで個別の VPC Lattice サービス (Service 1~3 向け) を作成し、サービスネットワークに関連付けることができます。 最後に、Service 2 と Service 3 が双方向通信を必要とするため、VPC-02 と VPC-03 をサービスネットワークに関連付ける必要があります。 ただし、Service 3 はバックエンドサービスであるため、Connected VPC をサービスネットワークに関連付ける必要はありません。 以下にアーキテクチャ、ソリューションの概要を示しています。 図 7 – VPC Lattice によるアプリケーション間ネットワーキングのシンプル化 VPC Lattice を使用すると、マルチアカウントおよびマルチ VPC 環境における VMware Cloud on AWS アプリケーションとクラウドネイティブサービス間の相互接続を素早く構築できます。また、AWS Transit Gateway、AWS PrivateLink、 Private NAT Gateway など、追加のネットワークインフラストラクチャサービスの構築による複雑さと管理オーバーヘッドを排除できます。 さらに、VPC Lattice には Lattice サービスごとに一意の DNS 名を自動的に割り当てる、組み込みの DNS ベースのサービスディスカバリーがあります。 Amazon Route 53 プライベートホストゾーンを利用することで、サービスの CNAME、またはエイリアスレコードをカスタマイズすることもできます。 VPC Lattice によるアプリケーション変革の加速 次の例では、VPC Lattice が VMware Cloud on AWS のお客様がアプリケーションをシームレスにクラウドネイティブサービスに変換・移行するのにどのように役立つかを探っていきます。 お客様は SDDC 上で実行されているレガシーアプリケーションのリファクタリングを進めており、それを AWS Lambda のサーバーレス関数に再構築しました。SDDC 内のレガシーアプリケーションから Lambda 関数へのサービストラフィックの切り替え前に、アップストリームの他のサービスへの潜在的な影響を調査するための一連のカナリアテストを実施したいと考えています。 Amazon VPC Lattice は、このシナリオのような ブルー/グリーン や カナリアスタイル のロールアウトなど、一般的なデプロイメントパターンをサポートしています。VPC-02 の Lambda 関数を使用する 1 つのターゲットグループと、Connected VPC 内の Application Load Balancer を公開して SDDC-01 上のレガシーアプリケーションに向けたもう 1 つのターゲットグループで VPC Lattice サービスを設定できます。 その後、以下の図に示すように、リクエスト条件 (パス、メソッド、ヘッダー) に基づいて、 2 つのターゲットグループ間でトラフィックを分散する重み付けルーティングを利用できます。 図 8 – VPC Lattice による SDDC と AWS Lambda を横断したカナリアロールアウト VPC Lattice は、サービス間の詳細なアクセスログを提供します。サポートされているログ配信ターゲットには、 Amazon Simple Storage Service (Amazon S3) バケット、 Amazon Kinesis Data Firehose 、 Amazon CloudWatch のロググループが含まれます。これにより、お客様は必要なログの詳細を迅速に取得し、特定のサービスまたはサービスネットワーク全体で発生し得る問題を特定および分析できます。 VPC Lattice は、アプリケーションの変革とモダナイゼーションを促進し、新しいアイデアを簡単に試すことができ、必要に応じて迅速にロールバックできるようにします。 これにより、サービス移行時のリスクを軽減し、最終的にエンドユーザーの体験を向上させます。 追加の考慮事項 サービスネットワーク全体でのネットワークレベルの保護を実施するため、VPC Lattice の AWS マネージドプレフィックスリスト をセキュリティグループで活用することをおすすめします。 さらに、個々のサービスまたはサービスネットワーク全体のいずれかに、強力な認証とコンテキスト固有の認可を適用するために、サービスレベルの認証ポリシーを使用できます。詳細は、こちらの AWS ブログ記事 を参照してください。 デフォルトでは、VPC Lattice のサービスはリンクローカルアドレスレンジがルーティング不可能なため、VPC 内からのみアクセスできます。 Lattice サービスへの外部接続性を提供するには、 Elastic Load Balancing とプロキシのフリートを使用した ingress VPC が必要です。サンプルアーキテクチャと実装ガイドは、この AWS ブログ記事 を参照してください。 AWS 責任共有モデル に従って、AWS インフラストラクチャ上にホストされるコンテンツの管理はお客様の責任となります。この ユーザーガイド に従って Amazon VPC Lattice を設定し、セキュリティとコンプライアンス目標を満たしてください。また、VMware Cloud on AWS の ネットワークとセキュリティの包括的なガイド も参照してください。 VMware Cloud on AWS 環境の強化に役立つ リソース があります。 価格については、Amazon VPC Lattice の 料金ページ をご確認ください。 AWS Transit Gateway や VMware Transit Connect の 料金 もご参照ください。 まとめ この投稿では、Amazon VPC Lattice が VMware Cloud on AWS のお客様にどのようにアプリケーションネットワーキングをシンプル化し、変革を加速できるかについて説明しました。一般的な統合アーキテクチャと使用例の概要についてもご紹介しました。 より詳細については、以下のリンクをご参考ください。 VMware Cloud on AWS ハイブリッドネットワークデザインパターン VPC Lattice のご紹介 – サービス間通信のためにネットワーキングを簡素化する Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice 本稿は、ソリューションアーキテクトの齋藤が翻訳を担当しました。原文は こちら です。

このブログは 2023 年 10 月 2 日に 執筆された内容を日本語化したものです。原文は こちら をご参照ください。 (原文はイベント開催前に掲載された為、イベント期間中のみの活動については省略しています) Unreal Engine (UE) の開発会社である Epic Games が主催する毎年恒例の開発者カンファレンスである Unreal Fest は、 10 月 3 日から 5 日までニューオリンズで開催され、 3 日間の講演セッション、ハンズオンワークショップ、業界に特化したトラックを開催します。このカンファレンスにはゲーム開発者、デザイナー、アーティスト、様々な業界の専門家が一堂に会し、最新テクノロジーについてより深い洞察を得たり、専門家から学んだり、 UE のクリエイターやゲーム開発者と交流したりします。このブログ記事では Unreal Fest 2023 での AWS for Games のプレゼンスについて取り上げます。 UE のゲーム開発者が AWS を使用してリアルタイム 3D 体験をどのようにスケーリングしているかについては、 AWS と Unreal Engine をご覧ください。 現地での活動 AWS は今年 Unreal Fest のプラチナスポンサーになったことを誇りに思います。これには、パートナーセッション、ブースプレゼント、 AWS 業界の専門家によるライブ製品デモが含まれます。 AWS で Unreal Engine のゲームを構築しているお客様 高度な 3D ゲーム開発テクノロジーと専用のグローバルインフラストラクチャ機能を組み合わせることで、ゲームスタジオがどのようにゲームを構築、運営、成長させているかをご紹介します。 Epic Games は 2018 年にアマゾンウェブサービス （AWS） を全面的に採用し、ビジネスに不可欠なストレージ、分析、スケーリング機能を提供しました。これは毎日約 1,500 万人のアクティブユーザーがいるオンラインゲーム「フォートナイト」のリリースで爆発的に増加しました。フォートナイトは、世界中のゲームサーバー、バックエンドサービス、ウェブサイトを含め、ほぼすべて AWS 上で運営されています。詳細は こちら をご覧ください。 Odyssey Interactive は 2020 年に設立されたウォータールーを拠点とするゲームスタジオで、最初のゲームであるオメガストライカーズの発売と拡大のための費用対効果の高いソリューションを求めていました。オメガストライカーズは UE をベースに構築された 3 対 3 のエキサイティングなフットボールバトルゲームです。実績のある AWS と UE によるソリューションにより、 Odyssey Interactive はバックエンドのインフラストラクチャではなく優れたゲームの制作に集中できるようになりました。こちらの お客様のビデオ をご覧ください。 QXR Studios の共同創設者である Graeme Devine 氏は次のように語っています。「これまでは 100人 以上のチームがこのレベルで成果を出すのに 5 年の期間と 2500 万ドルがかかっていました。業界としては AWS や UE のようなツールにより、テクノロジーの基盤となるサービスに加えて、世界中のアーティストやモデラーにアクセスできるようになりました。これにより小規模なゲーム会社でも AAA のゲームコンテンツを制作できるようになり、ワクワクしています」。こちらの お客様のブログ をご覧ください。 Red Barrels はモントリオールに拠点を置く独立系ゲームスタジオで、スタジオの設立当初から UE をベースに開発を続けています。同社は最初のマルチプレイヤータイトルである「 Outlast Trials 」のゲームサーバーを管理するソリューションを必要としていました。 Red Barrels は UE と AWS の両方を選択しました。これはこれらのテクノロジーがゲーム開発プロセスにパワーと柔軟性をもたらすためです。こちらの お客様のビデオ をご覧ください。 Behaviour Interactive はカナダ最大のゲームスタジオの 1 つで、受賞歴のある非対称型マルチプレイヤーホラーゲーム「 Dead by Daylight 」は 2016 年の発売以来 5,000 万人を超えるプレイヤー数を獲得しています。 UE と AWS により、スタジオは忠実度の高いゲーム体験を制作し、何 100 万人ものプレイヤーに自信を持ってスケールできるようになりました。こちらの お客様のビデオ をご覧ください。 AWS での Unreal Engine 利用例 AWS for Games には、UE ゲーム開発者がコストを削減し、反復作業を迅速に行い、より良いプレイヤー体験を世界規模で提供できるよう支援する、用途別のポートフォリオが用意されています。 仮想ワークステーション – AWS 上の Epic Unreal Engine 5 ワークステーションは、 3D データをホストしてレンダリングするための高価なハードウェアや物理ワークステーションを必要とせずに、忠実度が高く没入感のある 3D 体験を世界中にシームレスに提供します。この Amazon Machine Image (AMI) には UE 5.2 とその動作に必要なものが予め用意されているため、ダウンロードやインストールなしでクラウドで直接制作作業を行う事ができます。詳細は こちら をご覧ください。 ビルドパイプライン – AWS 上の Incredibuild は、 UE の開発者と DevOps の管理者に、ゲームを継続的にビルド、改善、予定通りリリースするためのスケーラブルなプラットフォームを提供する強力なソリューションです。詳細は こちら をご覧ください。 バージョン管理 – AWS 上の Perforce Helix Core は、グローバルな規模と優れたパフォーマンスを実現するエンタープライズ向けのバージョン管理システムです。これは信頼できる単一のソースを UE のデジタルアセットに提供することで、グローバルなチームや大規模なバイナリアセットを管理できるようにします。詳細は こちら をご覧ください。 ゲーム QA とテスト – Amazon GameLift Anywhere は、環境内のハードウェアを統合する事で、ローカルワークステーションでリアルタイムにゲームプレイのモニタリングとデバッグが行える様高速化します。詳細は こちら をご覧ください。 ゲームサーバーホスティング – AWS Graviton3 プロセッサを搭載した Amazon GameLift の専用ゲームサーバー管理サービスは、計算集約型の UE ゲームに最適なコストパフォーマンスを実現します。 Unreal Engine 用 Amazon GameLift Plugin は、 Windows および Mac OS 用の UE 5、 UE 5.1、 UE 5.2、 UE 5.3 をサポートしており、最新の Amazon GameLift SDK 5 以上の API が含まれているため、お客様はUnreal Engine Editor でゲームをビルド、テスト、デプロイできます。詳細は こちら をご覧ください。 ゲーム分析 – AWS のゲーム分析パイプラインは、ゲーム開発者がスケーラブルなサーバーレスデータパイプラインを立ち上げ、 UE で作られたゲームクライアントのアクティブユーザーとビルドから生成されたプレイヤーデータを取り込み、保存、分析するのに役立ちます。詳細は こちら をご覧ください。 カスタムゲームバックエンドホスティング – AWS でのカスタムゲームバックエンドホスティングのガイダンスでは、 UE 5 のサンプルコードとともに、カスタマイズされた軽量でスケーラブルなクロスプラットフォーム向けのID認証機能をデプロイする方法を示しています。詳細は こちら をご覧ください。 ゲーム開発者が AWS 上で UE のゲームを構築、実行、成長させるのに役立つ、 7 つの専用機能 終わりに Unreal Fest はさまざまな業界のデベロッパーやクリエイターが一堂に会し、新しいプロジェクトについて学び、最新テクノロジーのハンズオントレーニングを受け、他のクリエイターと出会い、ネットワークを築くための今年のプレミアイベントです。 UE のゲームの開発者が、 AWS でゲームのワークロードと体験をどのように変革しているかについての詳細は AWS と Unreal Engine のホームページをご覧ください。 翻訳はソリューションアーキテクトの長田が担当しました。

2023 年 9 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Batch 入門編 HPC や機械学習などのバッチ処理を AWS 上で実現できる AWS Batch ついて入門編の内容をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 HPC や機械学習などのバッチ処理をクラウド上で実行することについ て興味のある方。 Amazon VPC / Amazon EC2 / Amazon S3 などの概要知識がある方。 本 BlackBelt で学習できること AWS Batch の概要と、キーコンポーネント、ワークロードごとのデザインパターンについて学習することができます。 スピーカー 小林広志 ソリューションアーキテクト Amazon EMR 基礎編 Apache Spark、Apache Hive、Presto, Trino などのオープンソースフレームワークを使用して、ペタバイトスケールのデータ処理、相互分析、機械学習を行なう業界をリードするクラウドビッグデータソリューションである Amazon EMR について、サービスの基礎的な内容を解説します。 資料（ PDF ） 対象者 ビッグデータを扱うシステムのインフラエンジニア、データエンジニア、および、機械学習エンジニア 本 BlackBelt で学習できること Apache Spark、Apache Hive、Presto, Trino などのオープンソースフレームワークを使用して、ペタバイトスケールのデータ処理、相互分析、機械学習を行なう業界をリードするクラウドビッグデータソリューションである Amazon EMR を利用するために必要となるサービスの基礎的な内容を理解することができます。 スピーカー 川村誠 ソリューションアーキテクト AWS Secrets Manager AWS Secrets Manager はシークレットのライフサイクルを一元的に管理し、保存・取得・更新・アクセス制限・監査・モニタリングを行うことができます。 本セミナーでは、AWS Secrets Manager の機能について詳細に解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 環境におけるデータベース認証情報や API キーなどのシークレット管理に関心をお持ちの方 これから AWS Secrets Manager をご利用予定の方や、理解を深めたい方 本 BlackBelt で学習できること 本セミナーをご覧になることで、AWS Secrets Manager の機能と、どのようにセキュリティ要件を満たすように構築されているかを理解していただき、安心して AWS 上のシークレットを管理していただくことができるようになります。 スピーカー 押川令 ソリューションアーキテクト Amazon Kinesis Video Streams 基礎編 Amazon Kinesis Video Streams は、メディアデータのストリーミングや分析、保存、再生のためのサービスです。 本セミナーでは、Amazon Kinesis Video Streams 基礎編として、サービスの特徴や基本的な機能、開発のための SDK などを紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 見守りカメラや監視カメラなど、コネクテッドカメラからのメディアデータのクラウド活用を検討されている方 コネクテッドカメラからの動画のストリーミングや保存、分析、再生のアプリケーションを検討されている方 Amazon Kinesis Video Streams の初めてのご利用を検討されている方 本 BlackBelt で学習できること Amazon Kinesis Video Streams の特徴や機能 アプリケーションやデバイスを開発するために利用できる SDK やライブラリ、デモアプリケーション デバイスの認証方法 Amazon Kinesis Video Streams の利用を素早く開始するための、パートナーデバイスと入門用コンテンツ 2022 〜 2023 年に公開された Amazon Kinesis Video Streams の新機能 素早く利用を開始するためのパートナーデバイスと入門用コンテンツ スピーカー 宇佐美雅紀 ソリューションアーキテクト Amazon Kinesis Video Streams 応用編 Amazon Kinesis Video Streams を活用する上で知っておくべき Tips について紹介します。パフォーマンスやコストの最適化、よくある問題とトラブルシューティング方法など、サービスをよりよく利用するためのアドバンストな内容を扱います。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Kinesis Video Streams を利用中もしくは利用を検討しており、サービスへの理解を深めたい方 サービスの基本的な知識をお持ちでない方は、同月に公開される Amazon Kinesis Video Streams 基礎編を先にご視聴ください 本 BlackBelt で学習できること 遅延の削減方法 注意すべきサービスの仕様や上限 コストの考え方 WebRTC のトラブルシューティング GStreamer のよくある問題 スピーカー 三平悠磨 IoT スペシャリストソリューションアーキテクト Amazon EventBridge Scheduler サーバーレスのスケジューラーである Amazon EventBridge Scheduler の基本的な機能や使い方について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 クラウドに適したジョブスケジューラーをお探しの方 ノーコードで定期的なタスクの実行を管理したい方 本 BlackBelt で学習できること EventBridge Scheduler を使って定期的に AWS サービスの API を実行する方法 スピーカー 櫻谷 広人 パートナーソリューションアーキテクト FreeRTOS Kernel 編 FreeRTOS はリアルタイム OS の一つで、マイクロコントローラ上で動作する組込み機器向け OS です。 多機能な IoT デバイスを開発する上で、FreeRTOS は欠かせません。 この動画では、FreeRTOS のコアである Kernel が提供する機能について詳しく説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから IoT デバイスを開発されようとするエンジニアの方 これから FreeRTOS の利用を検討しているエンジニアの方 FreeRTOS 上でソフトウェアを開発するエンジニアの方 本 BlackBelt で学習できること AWS が提供する FreeRTOS のサポート内容 FreeRTOS のコアである Kernel が提供する機能の詳細 FreeRTOS のはじめかた スピーカー 山岡卓紀夫 ソリューションアーキテクト AWS Clean Rooms お客様とそのパートナーが、Raw データを共有したり互いにコピーしたりすることなく、集合データセットをより簡単かつ安全に分析、およびコラボレーションする為の独自のクリーンルームを作成できるサービス AWS Clean Rooms について機能の詳細や利用パターンをご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データクリーンルームの技術要素をキャッチアップしたい方 機密性の高いデータのグループ間、企業間共有に課題を抱えている方 AWS を利用したデータコラボレーションを運用設計を検討されている方 AWS を利用したデータ活用に興味がある方 本 BlackBelt で学習できること AWS Clean Rooms のサービス概要や機能詳細 安全にデータをコラボレーションする為の利用方法 具体的な利用パターンや他 AWS サービスとの連携方法 スピーカー 鈴木康士郎 ソリューションアーキテクト AWS Systems Manager Maintenance Windows AWS Systems Manager は統合的な AWS 環境の運用をするためのツールとして進化しており、多くの機能を持っています。本セッションでは、AWS Systems Manager の数ある機能のうち、 Maintenance Windows についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS の運用をされている方、これから運用される予定の方、AWS Systems Manager に興味のある方を対象者として想定しています。 本 BlackBelt で学習できること AWS Systems Manager Maintenance Windows のユースケースと機能概要、AWS Systems Manager State Manager との使い分けについて学習いただけます。 スピーカー 小野卓人 シニアソリューションアーキテクト AWS Systems Manager Distributor 編 AWS Systems Manager (SSM) は統合的な AWS 環境を運用するためのツールとして進化しており、多くの機能を持っています。本セッションでは、AWS Systems Manager の数ある機能のうち、 Distributor についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS の運用をされている方、これから運用される予定の方 本 BlackBelt で学習できること AWS Systems Manager Distributor の機能とユースケースをご理解いただくことができます。 スピーカー 村田京介 ソリューションアーキテクト Amazon Monitron Part 1（基本編） Amazon Monitron は回転機器の振動や温度データを、設備に貼り付けた電源不要のセンサーデバイスでクラウド上へ収集しクラウドで分析することで、潜在的な障害の予兆を検知して、計画外のダウンタイム発生を防止するソリューションです。 資料（ PDF ） | 動画（ YouTube ） 対象者 工場、プラント、物流拠点等で設備の計画外ダウンタイムを減らしたい方 モーター・ギア・ベアリング・ポンプ・コンプレッサーなどの回転体部品を多く稼働させておりそれらの点検保守を効率化したい方 機器の計画保守（定期的な点検保守）を減らし、データに基づく予測型保守を導入したい方 本 BlackBelt で学習できること Amazon Monitron セミナーはシリーズ開催予定です。このセミナーでは Amazon Monitron シリーズ Part 1 として、産業設備のメンテナンスにおける課題と Amazon Monitron によるソリューション、そして Amazon Monitron のしくみを解説します。 スピーカー 吉川晃平 シニア ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-10 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 入門編 クラウドサポートエンジニア 高橋尚久 2023-10 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Container Service(Amazon ECS) 編 クラウドサポートエンジニア 古野俊広 2023-10 Amazon EC2 Auto Scaling スケーリングポリシー編 シニアソリューションアーキテクト EC2 フレキシブルコンピュートスペシャリスト 滝口開資 2023-10 アクセラレータ搭載インスタンスの選択肢 シニアソリューションアーキテクト 赤澤智信 2023-10 AWS ML アクセラレータ入門 Annapurna Labs 常世大史 2023-10 AWS Application Discovery Service の概要（AWS 移行準備シリーズ） マイグレーションパートナーソリューションアーキテクト 鈴木槙将 2023-10 Amazon CodeCatalyst Overview 編 ソリューションアーキテクト 三尾泰士 2023-10 AWS Budgets シニアテクニカルアカウントマネージャー 岡本迅人 2023-10 AWS Cost and Usage Reports シニアテクニカルアカウントマネージャー 石王　愛 2023-10 AWS CloudFormation ユースケースとよくある質問編 ソリューションアーキテクト 木村友則 2023-10 AWS CloudFormation DeepDive 編 クラウドサポートエンジニア 山本一生 2023-10 AWS CloudFormation CloudFormation レジストリ編 クラウドサポートエンジニア 山本一生 2023-10 Amazon Monitron #2 設定編 ソリューションアーキテクト 伊藤ジャッジ向子 2023-11 Amazon Linux 最新情報 ソリューションアーキテクト 寺部祐菜 2023-11 Karpenter Basic ソリューションアーキテクト 多田慎也 2023-11 AWS SAW – セルフサービス自動化ランブックを使用したトラフィック監視の視覚化 Amazon Virtual Private Cloud (Amazon VPC) 編 クラウドサポートエンジニア 中村佑希 2023-11 AWS CloudFormation#2 基礎編 クラウドサポートエンジニア 上原優樹 2023-11 AWS CloudFormation 開発・テスト・デプロイ編 ソリューションアーキテクト 山川達也 2023-11 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Kubernetes Service (Amazon EKS) 編 クラウドサポートエンジニア 坂元龍太 2023-11 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Compute Cloud – Windows 編 クラウドサポートエンジニア 和田智優 2023-11 Amazon CloudWatch Evidently テクニカルアカウントマネージャー 日平大樹 2023-11 AWS SAW – Nitro システムへの移行を支援する SAW ランブックのご紹介（EC2 Linux 編） クラウドサポートエンジニア 渡邉亮藏 2023-11 AWS SAW – セルフサービスなトラブルシューティング Amazon S3 + AWS Lambda 編 クラウドサポートエンジニア 石川直哉 2023-11 Amazon Pinpoint 再入門 マルチチャネル・コミュニケーションサービス ソリューションアーキテクト 清水幸典 2023-11 Amazon Connect カスタム CCP による従業員体験の向上 ソリューションアーキテクト 清水幸典

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 AWS の生成系 AI サービス・ Amazon Bedrock  が GA (General Availability) になりました。 本ブログでは、Amazon Bedrock の Claude v2 ( by Anthropic 社) モデルを指定して、 Playgrounds のチャット機能を手軽に使用する方法について解説します。 今回は製造業で設計開発業務に取り組まれている R&D (Research and Development：研究開発) エンジニアの方を想定ユーザーとして設定させていただきました。本サービスを活用して、どのように設計開発業務改善を実現できるかについてのイメージを持っていただけるような構成になっています。 なお、本ブログの内容は2023年10月12日時点の内容に基づいて実行しています。執筆段階では東京リージョンにおいては Claude v1.3 モデルしか利用できません。 現時点で最も新しいバージョンは v2 になりますので、ここでは v2 モデルが利用できる北米のバージニア北部リージョンで試行を行います。また、 Amazon Bedrock は日々進化しており、ブログ作成段階ではできなかったことも、ブログを読んでいただいた時点ではできるようになっている場合もありますのでご注意ください。 取り組む内容 設計開発プロセスの大きなマイルストーンの一つに、 DR （デザインレビュー：設計審査）があります。 DR では設計仕様書や設計計算書など、たくさんの設計ドキュメントを用意する必要があります。本ブログではその中から、 FMEA （ Failure Mode and Effects Analysis ：故障モード影響解析）に着目し、 Amazon Bedrock を活用して FMEA のドキュメントを効率的に作成するイメージをお見せしたいと思います。 FMEA の狙いは、製品や製造プロセスに潜在する故障モードを事前に洗い出し、影響を分析評価したうえで対策を講じることです。なるべく広く故障モードを想定できたほうが設計品質が高くなりますが、それには熟練の知識や経験が必要になります。また、洗い出す項目が多いほど、ドキュメント作成に時間を要します。このような FMEA のドラフトを、 Amazon Bedrock を活用して作成することで、 基盤モデル の特性を活かした広い観点での項目抽出を素早く行うことができるようになります。 実行方法 まずマネジメントコンソール上部の検索バーで、「bedrock」などと打ち込んでいただくと、 Amazon Bedrock が候補に表示されます。クリックしてサービス画面に移行してください。 サービス画面に移行すると、画面左に Playgrounds という項目が表示されます。今回は Chat 機能にアクセスして、生成系 AI と対話形式でやり取りを行います。 Amazon Bedrock では、主要な AI スタートアップ企業や Amazon から提供される幅広い基盤モデルの中からユースケースに適したものを選択して使用することができます。詳細については Amazon Bedrock の製品ページをご参照ください。初期状態ではモデルアクセスへの権限が与えられていない状態のため、以下画像のように Base Models の中から選べるものが存在しません。そこで、まずモデルアクセスへの権限付与設定を行います。 画面左の Base Models をクリックし、 Claude v2 にカーソルを当てると、画面の黄色部分のような枠が表示されますので、 Model access ボタンをクリックします。 すると、以下画面に遷移しますので、 Claude にチェックマークをつけます。現状 Available が灰色になっていますが、このチェックを入れた状態で画面最下部でオレンジ色の Save changes ボタンをクリックすると、利用可能な状態に変わります。 以下画面のように、 Claude が Access granted の状態になれば利用可能です。 画面左の Chat ボタンを押すと、以下画面のように、 Base Models として Anthropic が選択可能な状態になっています。その右では Claude v2 を選択します。 この状態で、Add InstructionsのHuman : と記載されている箇所からチャット文章を書き込むことが可能になっていますが、書き込む文章が長い場合などに備えて、 Update inference configurations をクリックして、 Maximum Length （出力トークン数の最大値）を上げましょう。（トークン数はおおまかに文字数に相当するものと捉えてください） Maximum Length をデフォルトの300から上限の2048に上げます。 事前の設定が済めば、いよいよチャット文章を打ち込みます。以下画面の赤枠で、Human : と記載されている箇所に続いてこのような文章を打ち込みました。 「冷却ファンのFMEA（故障モードと影響解析）を作成してください。表形式で、列には、機能、故障モード、故障影響、故障原因、重要度（影響の重大度）、重要度（発生頻度）、重要度（検知難易度）、致命度（影響の重大度＊発生頻度＊検知難易度）、対策内容を入れてください。重要度はそれぞれ、1,2,3点のいずれかで表してください。多様な機能の観点で合計10個の故障原因について、対策内容は50文字程度を目安に具体的に記述してください。」 Run ボタンを押すと、紫色の箇所に Anthropic Claude v2 から回答文章が返ってきました。この状態では表形式で表示されていませんが、右上のほうにあるコピーボタンを押して、Excel などの表計算ソフトに貼り付けていただくと、表形式で表示されます。 必要に応じて罫線や色を追加するなどして見やすく編集しましょう。こちらが Anthropic Claude v2 によって数秒で作成された冷却ファンの FMEA になります。（※注意点として、生成系 AI ではランダムな要素が含まれるため、同じ質問をしても異なる回答が返ってくることがあります） このFMEAの良い点、改善が求められる点としては主に以下が挙げられます。 良い点 機能ごとに故障モード、影響、原因を網羅的に洗い出されている 致命度が指示された定義通りに算出されており、リスクの大きさが定量化されている 対策内容が適度な文字数である程度具体的に記載されている 改善が求められる点 重要度（影響、頻度、検知）の評価根拠が不明確（例えば、異音発生の重要度（影響）は本当に1点が相応しいのか、まだ動く状態だが騒音不快感を考慮すると影響はもっと大きいのではないか、など） 対策内容が要件に合うかが不明（例えば、定期的に確認する対策項目が多いが、要件に即時性が求められていた場合常時監視などの対策が必要となる、など） このように、生成系 AI を活用してドキュメントを作成する際には大事なポイントがあります。 ポイント1：質問段階で希望する出力形式を具体的に指定すると、それに沿ったドキュメント作成が行える ポイント2：項目の洗い出しや、ドキュメントのドラフト作成をまず生成系 AI に任せて、取捨選択判断や仕上げは人間が行うことで、品質向上や工数短縮が実現できる 生成系 AI は便利である一方、タスクを任せきりにしてしまうと思わぬ誤りがコンテンツに含まれてしまったりすることがあります。適材適所で生成系 AI に任せる部分、人間が責任を持って判断する部分を切り分けるようにして、設計開発業務を進化させましょう。 著者プロフィール 山田 航司  (Koji Yamada @yamadakj) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Transcribe です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。

AWS SimSpace Weaver は、大規模な空間シミュレーションのスケーリングに必要なインフラストラクチャの機能および SDK (Software Development Kit) を提供するマネージドサービスです。前回の記事「 AWS SimSpace Weaver で実現する大規模空間シミュレーション: Part 1 」では、空間シミュレーションの分類や AWS での実現方法、そして AWS SimSpace Weaver が提供する機能と解決する課題について概要を紹介しました。本記事は Part 2 となり、AWS SimSpace Weaver が提供する機能と解決する課題についてのより詳細な解説を行い、AWS SimSpace Weaver を実際に導入するにあたってのステップを紹介します。 なお、本記事の内容は 2023 年 10 月時点の情報であるため、最新の情報は AWS SimSpace Weaver の Documentation を参照ください。 AWS SimSpace Weaver のコンセプト 本記事ではオンライン空間シミュレーションの具体例として、状況の可視化やインタラクティブなシナリオ操作を伴う人流・物流シミュレーションを例にして AWS SimSpace Weaver の使いどころを考えていきます。 大規模な人流シミュレーションとはどんなものでしょうか。ある施設で火事が発生し 100 人ほどが避難するシミュレーションはそれほど大規模ではないことはイメージできるかと思います。では大きなイベントホールから 50000 人が避難する場合はどうでしょうか。あるいは何らかの警報をきっかけに一都市全体で住民が一斉に避難を始めた場合のシミュレーションはどうでしょうか。他にも、数万台の車両が走行している一都市全体の交通状況を考慮した物流や緊急車両の走行シミュレーションではどうでしょうか。これらのシミュレーションの計算には大きなコンピュート処理能力が必要となります。従来のアプローチでは、CPU やメモリの能力を最大限に引き出すためにコーディング技術を駆使したり、チューニングを限界まで行ったりする必要がありました。そしてシミュレーションアプリケーションが単一プロセスや単一インスタンスの性能では処理しきれなくなったとき、スケールアップの限界を迎えます。よりスケールさせるには、スケールアウトのアプローチが必要となります。 空間シミュレーションをスケールアウト、つまり複数のインスタンスやプロセスにまたがって一つの空間シミュレーションを実行する典型的な方法は、空間分割です。シミュレーションで扱う空間を二次元 (または三次元) 座標のグリッドに分割し、各領域 (パーティション) の処理を異なるプロセスで実行するというアプローチです。 空間分割のイメージ このアプローチはシンプルですが、課題も存在します。1: 各パーティションを担当するプロセス間でシミュレーション対象の物体 (以降エンティティと呼びます) の情報を共有・同期する仕組みが必要なこと、2: 各パーティションの時刻を同期する仕組みが必要なこと、です。例えば避難経路の計算において近くの人との位置関係を考慮して次の移動方向を決めるとしたら、隣接したパーティションにいる人の位置も知る必要があります。また、各パーティションで時刻ずれが発生してしまうと、シミュレーション全体の結果が破綻してしまうので、パーティション間で足並みをそろえて処理を進める必要があります。単一インスタンス内の複数プロセスにおいてこれらの課題に対処するのも重労働ですが、異なるインスタンス上のプロセスまでスケールアウトする場合、これらの課題は更に複雑になります。AWS SimSpace Weaver はこれらの課題を解決するためのインフラストラクチャと SDK を提供します。 AWS SimSpace Weaver が提供する機能 1 点目はエンティティの情報の共有の仕組みです。AWS SimSpace Weaver は内部的に EC2 インスタンスを使用しますが、EC2 インスタンス上の複数のプロセス間や EC2 インスタンス間でエンティティ情報を共有するために、独自の共有メモリの仕組みを持っています。これは State Fabric と呼ばれ、各エンティティの座標位置に加え、ユーザーが自由に定義可能な属性情報を保持できます。また、分割された各パーティションにて他のパーティション内のエンティティ情報にアクセスするために、 Subscription の仕組みを提供しています。この仕組みにより、隣接したパーティションのエンティティ情報をもとにシミュレーションを実行したり、複数のパーティションにまたがった可視化を行ったり、シミュレーション全体にわたるメトリクスを計算したりできます。 Subscription の仕組みにより他のパーティション内のエンティティの情報を取得できる 2 点目は時刻同期の仕組みです。AWS SimSpace Weaver には、シミュレーションロジックを実行する各プロセスにおける時刻を制御する Simulation clock の仕組みがあります。Simulation clock で刻まれる時刻単位は tick と呼ばれ、その進むレート (clock rate) は 10 Hz, 15 Hz, 30 Hz, および unlimited (SimSpace Weaver app SDK 1.14.0 以降) から指定できます。Simulation clock により、複数インスタンス間でも単一の時間軸においてシミュレーションを実行できるようになります。 加えてシミュレーションの可視化が必要な場合、クライアントアプリケーションを独自で構築し、AWS SimSpace Weaver で動作しているシミュレーションアプリケーションにネットワーク経由で接続して可視化に必要な情報を得たり、ユーザー操作をシミュレーションに反映させることができます。 2023 年 10 月時点で AWS SimSpace Weaver が提供しない機能 本記事執筆時点では、AWS SimSpace Weaver が主に提供するのはシミュレーションを実行するインフラストラクチャのスケーリングを助ける機能です。AWS SimSpace Weaver はクライアントアプリケーションの作りやネットワークプロトコルには基本的に関与しないことに注意してください。SimSpace Weaver はクライアントアプリケーションが接続するためのエンドポイントを提供するため、お客様はエンドポイントに接続するアプリケーションやプロトコルを自由にデザイン・実装できます。 ただしスクラッチで実装するのが困難な場合には、SimSpace Weaver app SDK に同梱されている クライアントアプリケーションのサンプルコード、および Demo Framework が利用できます。Demo Framework にはシンプルなネットワークプロトコルのコードが含まれており、お客様の実装のスタートポイントとして活用できます。 SimSpace Weaver app SDK は本記事執筆時点で C++ および Python をサポートしています。また 3D エンジンのサポートとして Unity Plugin/Unreal Engine Plugin も提供しています。ただしこれらは可視化のためのクライアントアプリケーションで利用するものではなく、サーバーサイドアプリケーションにおけるシミュレーションロジックを各エンジンで実装する場合に利用するものであることに注意してください。 AWS SimSpace Weaver を導入するまでのステップ 最も AWS SimSpace Weaver の恩恵を受けられるお客様は、既に空間シミュレーションのワークロードを運用しており、その性能限界に課題を持っているお客様です。上述の AWS SimSpace Weaver の提供する機能を活用して既存のシミュレーションワークロードをスケールアウトし、大規模に拡張できます。もし現在利用しているサードパーティ製のシミュレーション用アプリケーションがあれば、それを AWS SimSpace Weaver 上でスケールさせることが可能かについて 是非 AWS へご相談ください 。 現在のシミュレーションがスタンドアロンアプリケーションで構築されている場合は、性能限界はそのアプリケーションを動かす端末、多くの場合はユーザーのクライアント PC のスペックの制約を受けます。よりパフォーマンスを高めたい場合、かつパフォーマンスのボトルネックがレンダリングではなくシミュレーションロジックにある場合、最終的には AWS SimSpace Weaver により大規模なシミュレーションへと進化できる可能性があります。ステップとしては、まずスタンドアロンアプリケーション内の処理をシミュレーションロジック部分と可視化部分に分離し、それらの間の情報をネットワーク経由でやり取りするように変更することで、それぞれを独立したアプリケーションとして実行できるようにします。次に、シミュレーションロジック部分のアプリケーションをサーバーサイドで、可視化部分のアプリケーションをクライアントサイドで実行する構成に変更します。結果としてクライアントサーバー構成のシミュレーション環境となります。シミュレーションロジックは独自実装でも構いませんし、3D エンジンを利用して実装する場合は Unreal Engine Dedicated Server 等の機能を利用するのが典型的な方法となります。ネットワークプロトコルについても、TCP や UDP をベースとした独自実装、または websocket や gRPC、MQTT 等の双方向通信が可能なプロトコルなど自由に利用できます。クライアントサーバー構成のシミュレーションはサーバーをスケールアップさせることで一定レベルまでパフォーマンスを高められます。スケールアップでの性能限界を超える必要が生じたら、是非 AWS SimSpace Weaver の導入をご検討ください。 既存のシミュレーションアプリケーションがなくこれから取り組む場合には、まずシミュレーションアプリケーションをクライアントサーバー構成で構築されることをおすすめします。スタンドアロンアプリケーションで可視化部分とシミュレーションロジック部分が密結合なアプリケーションを構築してからそれを分離するよりも、あらかじめ分離された構成で実装する方が容易な傾向があるためです。クライアントサーバー構成のシミュレーションアプリケーションを実装出来たら、先述の流れで最終的に AWS SimSpace Weaver の恩恵を受けることができます。 AWS SimSpace Weaver の始め方 本記事にて AWS SimSpace Weaver の特徴をつかんだら、AWS SimSpace Weaver の Product Manager によるサービス紹介動画 や、AWS re:Invent 2022 における AWS SimSpace Weaver ローンチ時のセッション を確認ください。AWS SimSpace Weaver の概念の詳細については 公式ドキュメントのユーザーガイド を参照ください。また、AWS SimSpace Weaver で動くアプリケーションを手軽に触ってみたい場合、 AWS SimSpace Weaver workshop を活用ください。 まとめ 本記事では AWS SimSpace Weaver が提供する機能とマッチするユースケース、および始め方について概念的な内容を中心に紹介しました。これまで技術的制約により一定規模で頭打ちとなっていた空間シミュレーションを大規模に拡張できるのが AWS SimSpace Weaver の最大の特徴です。開発者の皆様がインフラ構築の手間に煩わされることなく、すばらしいシミュレーションを構築されることを楽しみにしています。AWS SimSpace Weaver がマッチするユースケースを持つお客様や、今後そのようなワークロードに取り組む予定のあるお客様は、 是非 AWS へご相談ください 。 DNBソリューション本部 Game Techグループ ソリューションアーキテクト 西坂 信哉