2023 年 7 月 : この投稿には、オンプレミスの SMTP サーバーを使用してデータベース メールを構成する手順が追加されました。 Amazon RDS for SQL Server が SQL Server データベース メールを完全にサポートするようになったことを発表できることを嬉しく思います。このリリースより前にデータベース メールを有効にするには、 リンク サーバー の使用などさまざまな回避策を使用する必要がありました。SQL Server 用データベース メールのリリースでは、DB パラメータ グループを使用してデータベース メールをシームレスに有効にすることができます。 データベース メールは、Microsoft SQL Server で頻繁に使用される機能の 1 つです。データベース メールを使用すると、SMTP (Simple Mail Transfer Protocol) サーバーを使用して SQL Server からユーザーにメッセージを送信できます。この投稿では、データベース メールを設定し、 Amazon Simple Email Service (Amazon SES) 経由で RDS for SQL Server DB インスタンスから E メールを送信する方法を学びます。 データベース メールの一般的なユースケースは次のとおりです。 テキストメッセージの送信 クエリ結果またはレポートをテキストまたは添付ファイルとして送信 プロシージャまたはジョブ内でプログラムによる電子メール通知の送信 この投稿では、次の AWS サービスを使用します。 Amazon RDS for SQL Server – データベース メールは、SQL Server の Web、Standard および Enterprise エディションでサポートされています。 Amazon SES – Amazon SES を SMTP サーバーとして使用します。これは 1 つのオプションにすぎません。代わりに、別の SMTP サーバーを使用することもできます。その場合は、Amazon SES のセットアップに関する次のセクションをスキップしてください。 Amazon SES のセットアップ Amazon SES を SMTP サーバーとして使用して、電子メールを迅速に送信します。 Amazon SES は、あらゆるアプリケーション内から E メールを送信できるコスト効率が高い柔軟でスケーラブルな E メール サービスです。まず、次の手順を実行します。 Amazon SES コンソールで、[ SMTP 設定 ] を選択します。 「 サーバー名 」と「 ポート 」の値に注目してください。 [ SMTP 認証情報の作成 ] を選択します。 注意 : Amazon SES SMTP インターフェイス経由で E メールを送信するために使用する認証情報は、各 AWS リージョンで固有です。詳細については、「 Amazon SES SMTP 認証情報の取得 」を参照してください。 AWS Identity and Access Management の名前を入力します。 (IAM) ユーザーにするか、デフォルトのままにします。 「 作成 」を選択します。 SMTP 認証情報を安全な場所に保存します。ダウンロードできるのはこのときだけです。 Amazon SES コンソールで、[ E メールアドレス ] を選択します。 [ 新しいメール アドレスの確認 ] を選択します。 確認メールを受信するには、所有しているメール アドレスを入力してください。 メールを確認すると、「 検証ステータス 」に 認証済み と表示されます。 この時点で、SMTP サーバーに関する必要な情報がすべて揃ったので、データベース メールの構成を開始することができます。 データベース メールのセットアップ データベース メールを構成する前に、まず DB パラメータ グループを通じてデータベース メールを有効にします。 DB パラメータ グループによるデータベース メールの有効化 データベース メールは、RDS インスタンスでは DB パラメータグループを通じて 有効にします。 Amazon RDS では、パラメータグループは、1 つ以上の DB インスタンスに適用されるエンジン設定値のコンテナとして機能します。各 RDS インスタンスには、デフォルトのパラメータ グループが関連付けられています。ただし、変更することはできません。新しいパラメータグループを使用することも、既存の作成済みパラメータ グループを使用することもできます。既存のパラメータグループを選択する場合は、SQL Server インスタンスのエディションとバージョンがサポートされている必要があります。新しいパラメータグループの作成の詳細については、「 DB パラメータ グループの操作 」を参照してください。パラメータ グループを通じてデータベース メールを有効にするには、次の手順を実行します。 Amazon RDS コンソールで、[ パラメータグループ ] を選択します。 使用するパラメータグループを選択します。 検索ボックスに「database mail xps」と入力します。 「 編集 」を選択して値を変更します。 [ 値 ] で 1 を選択します。 変更を保存します。 Amazon RDS コンソールで、[ データベース ] を選択します。 使用するインスタンスを選択します。 「 変更 」を選択します。 「 データベース オプション 」で、database mail xps に1 が設定されているパラメータグループを選択します。 「 続行 」を選択します。 「 変更のスケジュール 」で、「 すぐに適用 」を選択します。 [ DB インスタンスを変更 ] を選択して変更を適用します。 パブリックサブネット内のインスタンスのデータベースメールの構成 次の図は、データベース メール構成の例を示しています。 User1 は、Profile 1 を介してアカウント 1 とアカウント 2 にアクセスできます。User2 は、両方のプロファイルを介してすべてのアカウントにアクセスできます。 User3 は、Profile 2 を介してアカウント 2 とアカウント 3 にアクセスできます。 データベース メールを使用する前に、メール構成をセットアップする必要があります。 SQL Server Management Studioを起動します。 データベース メールが有効になっている RDS インスタンスの SQL Server エンジンに接続します。 新しいクエリを開きます。 次のストアド プロシージャを使用して、単純なデータベース メール構成を作成します。 データベース メール プロファイルを作成します (プロファイルは電子メール アカウントを保存するために使用されるコンテナです)。次のコードを参照してください。 use msdb go EXECUTE msdb.dbo.sysmail_add_profile_sp @profile_name = 'Notifications', @description = 'Profile used for sending outgoing notifications using SES.' ; プロファイルにプリンシパルを追加します。 public を使用すると、すべてのユーザーがプロファイルにアクセスできるようになります。 use msdb go EXECUTE msdb.dbo.sysmail_add_principalprofile_sp @profile_name = 'Notifications', @principal_name = 'public', @is_default = 1 ; 必要に応じてデータベース メール オブジェクトに対するアクセス許可を付与できますが、現時点では public で問題ありません。 データベース メール アカウントを作成します (必ず正しい SMTP 資格情報を入力してください)。 use msdb go EXECUTE msdb.dbo.sysmail_add_account_sp @account_name = 'Acc1', @description = 'Mail account for sending outgoing notifications.', @email_address = ' example@example.com ', @display_name = 'Automated Mailer', @mailserver_name = ' email-smtp.us-west-2.amazonaws.com ', @port = 587 , @enable_ssl = 1, @username = 'SMTP-username' , @password = 'SMTP-password' ; この手順は、パブリック サブネットでホストされている RDS インスタンスに適しています。ただし、RDS インスタンスがプライベート サブネットに配置されている場合は、次のセクションで詳細なガイダンスを参照してください。 データベース メール アカウントをデータベース メール プロファイルに追加します。 use msdb go EXECUTE msdb.dbo.sysmail_add_profileaccount_sp @profile_name = 'Notifications', @account_name = 'Acc1', @sequence_number = 1; プライベート・サブネット内のインスタンスのデータベース・メールの構成 RDS for SQL Server インスタンスがプライベート サブネットでホストされている場合は、Amazon SES の VPC エンドポイントを使用する必要があります。これにより、RDS for SQL Server インスタンスと SMTP サーバー間の通信が可能になります。先に進む前に、まず前のセクションのステップ 1 ～ 5 を完了することが重要です。これらの最初のステップは、その後のステップの基礎となります。 SES の VPC エンドポイントのセキュリティグループの作成 Amazon VPC コンソール を開きます SES VPC エンドポイントの セキュリティ グループ を作成します。 新しいインバウンドルールを作成します。 [タイプ] で、[ カスタム TCP ] を選択します。 [ ポート範囲 ] に、電子メールの送信に使用するポート番号を入力します。 25、465、587 を使用できます。 [ ソース タイプ ] で、[ カスタム ] を選択します。 [ ソース ] に、RDS for SQL Server インスタンスにアタッチされているセキュリティ グループを入力します。 VPC エンドポイントの作成 Amazon VPC コンソール を開き、[エンドポイント] を選択します。 「エンドポイントの作成」を選択します。 名前を入力します。 [サービス カテゴリ] で [AWS サービス] を選択します。 「サービス」で「smtp」を検索し、そのリージョンに固有の SMTP VPC エンドポイントを選択します。 「VPC」セクションで、このエンドポイントが作成される VPC を選択します。 追加設定では、デフォルトで DNS 名の DNS 名を有効化 にチェック、DNS レコードの IP タイプでは Ipv4 がチェックされていることを確認してください。 「サブネット」で、アベイラビリティーゾーン内のサブネットを選択します。  [セキュリティ グループ] で、前に作成したセキュリティ グループを選択します。 「エンドポイントの作成」をクリックします。 VPC エンドポイントが利用可能な状態になったら、エンドポイントを選択し、DNS フィールドで見つかった最初のエントリをコピーします。 SMTP サーバー名の代わりに、前に作成した VPC エンドポイントの DNS 名を使用してデータベース メール アカウントを作成します。 (必ず正しい SMTP 資格情報を入力してください) use msdb go EXECUTE msdb.dbo.sysmail_add_account_sp @account_name = 'Acc1', @description = 'Mail account for sending outgoing notifications.', @email_address = 'example@example.com' , @display_name = 'Automated Mailer', @mailserver_name = 'vpce-XXXXX-XXXX.email-smtp.us-west-2.vpce.amazonaws.com' , -- VPC endpoint created in previous step @port = 587 , @enable_ssl = 1, @username = 'SMTP-username' , @password = 'SMTP-password' ; データベース メール アカウントをデータベース メール プロファイルに追加します。 use msdb go EXECUTE msdb.dbo.sysmail_add_profileaccount_sp @profile_name = 'Notifications', @account_name = 'Acc1', @sequence_number = 1; テストメールの送信 ストアド プロシージャ sp_send_dbmail を実行して電子メールを送信します (次のコードを参照)。受信者は、 Amazon SES シミュレーター を使用して、メールの送信が成功したかどうかを簡単にテストできます。その他のテスト オプションについては、「メールボックス シミュレーターの使用」を参照してください。実際の受信者に送信したい場合は、このプロセスを繰り返して追加の電子メール アドレスを確認する必要があります。 EXEC msdb.dbo.sp_send_dbmail @profile_name = 'Notifications', @recipients = 'success@simulator.amazonses.com', @body = 'The database mail configuration was completed successfully.', @subject = 'Automated Success Message'; GO 次に、次に示すストアド プロシージャを実行してすべての電子メール アイテムを表示します。 SELECT * FROM msdb.dbo.sysmail_allitems sent_status 列で、ステータスが送信されたことを確認します。 オンプレミスの SMTP サーバーを使用したデータベース メールの構成 一部の顧客は、オンプレミスの SMTP サーバーを使用して Amazon RDS for SQL Server でメールを設定したいと考えていました。このセクションでは、オンプレミスの SMTP サーバーをメール サーバーとして使用して、RDS for SQL Server DB インスタンスから電子メールを送信するようにデータベース メールを構成する方法について詳しく説明します。 前提条件 次の前提条件を満たしている必要があります。 前のセクションの DB パラメータ グループを通じて database mail xps が有効になっている DB パラメータを持つ RDS for SQL Server インスタンスであること SMTP サーバーでの認証に有効な資格情報を持つオンプレミス SMTP サーバーであること オンプレミス SMTP サーバーの構成を変更するための十分なアクセス権限を持つこと オンプレミスの SMTP サーバー接続を確認する オンプレミスの SMTP サーバーが正しく構成されており、電子メールを送信できることを確認します。次のことを確認してください。 SMTP サーバー アドレス – SMTP サーバーの IP アドレスまたはホスト名を取得します。 ポート番号 – SMTP サーバーで使用されるポート番号をメモします (通常、暗号化されていない接続の場合はポート 25、TLS/SSL 暗号化された接続の場合はポート 587 )。 認証資格情報 – SMTP サーバーでの認証に必要なユーザー名とパスワードがあることを確認します。 暗号化要件 – SMTP サーバーに安全な接続 (TLS/SSL) が必要かどうかを決定します。 ネットワーク接続を有効にする ネットワーク接続を有効にするには、次の手順を実行します。 SMTP サーバーは AWS ネットワークの外部に存在するため、サーバーが指定された IP 範囲内の Amazon RDS for SQL Server からの接続を許可していることを検証する必要があります。 Amazon RDS for SQL Server の IP 範囲またはパブリック IP が SMTP サーバーの許可リストに含まれていることを確認する必要があります。これを実現するための具体的な手順は、組織のポリシーや設定によって異なる場合があることに注意してください。 RDS for SQL Server インスタンスのセキュリティ グループを変更し、SMTP サーバーからの接続を許可する新しい受信ルールを追加します。 RDS インスタンスが実行されている AWS アカウントでは、ポート 25 がデフォルトでスロットルされます。ポート 25 がブロックされていないことを確認するには、AWS に SMTP (ポート 25) スロットリングを削除するようにリクエストする必要があります。これを行うには、 電子メール送信制限の削除リクエスト フォーム を使用します。 SMTP サーバーの DNS を解決するための Amazon Route 53 ルールを追加します。これにより、RDS インスタンスから電子メールを送信するときに SMTP サーバーのドメインが解決されます。 データベースメールの構成 次の手順でデータベース メールを構成します。 「 パブリック サブネット内のインスタンスのデータベース メールの構成 」セクションと同じ手順に従って、データベース メールを設定します。 データベース メール アカウントを作成するとき、メール サーバー名には、オンプレミスの SMTP サーバー名または IP (例えば mysmtpsvr.com など) を使用します。 データベース メール アカウントを作成します (必ず正しい SMTP 資格情報を入力してください)。 use msdb go EXECUTE msdb.dbo.sysmail_add_account_sp @account_name = 'Acc1', @description = 'Mail account for sending outgoing notifications.', @email_address = 'example@example.com', @display_name = 'Automated Mailer', @mailserver_name = 'mysmtpsvr.com', @port = 587, @enable_ssl = 1, @username = 'On-Prem-SMTP-username', @password = 'On-Prem-SMTP-password'; データベース メール アカウントをデータベース メール プロファイルに追加します。 use msdb go EXECUTE msdb.dbo.sysmail_add_profileaccount_sp @profile_name = 'Notifications', @account_name = 'Acc1', @sequence_number = 1; 結論 この投稿では、Amazon SES を使用してデータベース メールを設定する方法を説明しました。 SQL Server 用データベース メールのリリースにより、データベース メールを有効にして使用するための回避策を見つける必要がなくなりました。このソリューションは、他のサードパーティ SMTP サーバーにも使用できます。今すぐ AWS マネジメントコンソール でデータベースメールを試して、コメントであなたの考えや経験を共有してください。 About the authors Andrew Zhou は、アマゾン ウェブ サービスのソフトウェア開発エンジニアです。彼は AWS RDS チームと協力して、商用データベース エンジンと SQL Server に重点を置いています。彼は技術的な課題に取り組むことを楽しんでおり、新しいテクノロジーを学ぶことに情熱を持っています。 Chandra Shekar Ramavath iは、アマゾン ウェブ サービスのデータベース エンジニアです。彼は AWS RDS チームと協力して、商用データベース エンジン、SQL Server、Oracle に重点を置いています。 Sid Vantair は、戦略アカウントを担当する AWS のソリューション アーキテクトです。リレーショナル データベースを扱う 10 年以上の経験を持つ彼は、顧客のハードルを克服するために複雑な技術的問題を解決することに熱心に取り組んでいます。仕事以外では、家族と過ごす時間を大切にし、子供たちの好奇心を育んでいます。 Bharath Kumar は、AWS プロフェッショナル サービス チームのリード データベース コンサルタントです。彼は、顧客がオンプレミス データセンターから AWS クラウドにデータベースを移行できるようにサポートし、また商用データベース エンジンから Amazon のオープンソース データベースへの移行もサポートしてきました。 Nishad Mankar は、AWS プロフェッショナル サービスのリード データベース コンサルタントです。彼は、顧客が AWS クラウド上でデータベースを移行して最新化できるよう支援しています。       翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

この記事は、“ Improving medical imaging workflows with AWS HealthImaging and SageMaker ” を翻訳したものです。 医用画像は、医療における患者の診断と治療計画において重要な役割を果たします。しかし、医療提供者は、医用画像の管理、保存、分析に関していくつかの課題に直面しています。このプロセスには時間がかかり、エラーが発生しやすく、コストがかかる可能性があります。 また、地域や医療制度全体では放射線科医が不足しており、人口の高齢化、画像技術の進歩、医療における画像診断の重要性の増大により、この専門分野の需要が高まっています。 画像検査の需要が高まり続ける中、対応できる放射線科医の数が限られているため、検査予約や適切な診断が遅れています。テクノロジーによって臨床医と患者への医療提供の改善が可能になる一方で、病院は最も差し迫った課題を解決するために次のような追加のツールを求めています。 画像検査および診断サービスに対する需要の高まりによる専門家の燃え尽き症候群 体積測定や画像の構造的セグメンテーションなど、手間のかかる作業 利便性、使いやすさ、個別化の観点から、小売やテクノロジーに匹敵する質の高い医療体験を期待する患者からの期待の高まり 臨床医と患者の体験を向上させるには、人工知能（AI）対応の画像診断クラウドソリューションでPicture Archiving and Communication System（PACS: 医用画像サーバー）を運用して、重要な知見を安全に取得し、医療へのアクセスを改善してください。 AIは自動化により放射線科医の燃え尽き症候群を低減するのに役立ちます。たとえば、AIは放射線科医の胸部X線画像の診断時間を節約します。また、精密検査が必要な領域を特定するための強力なツールでもあり、当初は特定できなかった二次的な発見も得るのに役立ちます。相互運用性と分析の進歩により、放射線科医は患者の健康記録を360度縦断的に把握できるようになり、より低コストでより良い医療を提供できるようになりました。 AWS は、これらの課題に対処するサービスを提供しています。このブログ記事では、 AWS HealthImaging (AWS AHI) と Amazon SageMaker 、およびこれらを併用して医療提供者の医用画像ワークフローを改善する方法について説明します。これにより、最終的に画像診断が加速し、放射線医学の生産性が向上します。AWS AHI を使用すると、開発者はクラウドネイティブな医用画像アプリケーションにパフォーマンス、セキュリティ、およびスケールを提供できます。これにより、Digital Imaging and Communication in Medicine (DICOM) 画像を取り込むことができます。Amazon SageMaker は AI と機械学習のためのエンドツーエンドのソリューションを提供します。 自動車事故後のX線に関する使用例を見てみましょう。この医用画像診断ワークフローでは、患者は救急室にいます。そこから: 患者は骨折の有無を確認するためにX線撮影を受けます。 スキャンされた撮影装置の画像はPACSシステムに送られます。 放射線科医は、この検査で取得した情報を確認し、レポートを作成します。 依頼医にレポートが提供されるまで、患者のワークフローは継続されます。 次世代の画像処理ソリューションとワークフロー 医療提供者は AWS AHI と Amazon SageMaker を併用することで、次世代の画像診断ソリューションを実現し、医用画像診断ワークフローを改善できます。次のアーキテクチャは、この例を示しています。 図 1: X 線画像が AWS HealthImaging に送信され、Amazon SageMaker エンドポイントが分析情報を抽出します。 アーキテクチャと主要なコンポーネントを見てみましょう。 1. イメージスキャナー:患者の体から画像をキャプチャします。モダリティによっては、X線検出器、CTスキャナーの検出器アレイ、MRIスキャナーの磁場と高周波コイル、または超音波センサーなどがあります。この例では X 線デバイスを使用しています。 AWS IoT Greengrass : DICOM C-Store SCP で設定されたエッジランタイムとクラウドサービスで、画像を受信して Amazon Simple Storage Service (Amazon S3 ) に送信します。画像と関連するメタデータは、それぞれ Amazon S3 と Amazon Simple Queue Service (Amazon SQS) に送信され、ワークフローがトリガーされます。 2. Amazon SQS メッセージキュー:S3 バケットからのイベントを受信し、 AWS Step Functions ワークフローオーケストレーションをトリガーします。 3. AWS Step Functions は変換ジョブとインポートジョブを実行して画像を処理し、AWS AHI データストアインスタンスにインポートします。 4. 最終的な診断画像は、関連する患者情報およびメタデータとともに、AWS AHI データストアに保存されます。これにより、画像データの検索と管理を効率的に行うことができます。また、クラウドネイティブ API と AWS パートナーのアプリケーションにより、医用画像データへのアクセスも可能になり、1 秒未満の大規模な画像取得レイテンシーを実現できます。 5. ML 画像のラベリングを担当する放射線科医は、 Amazon SageMaker Ground Truth を使用して医用画像にアノテーションを付けます。カスタムデータラベリングワークフロー（組み込みまたはカスタムのデータラベリングワークフローをサポートするフルマネージドデータラベリングサービス）を使用して DICOM 画像を視覚化およびラベル付けします。また、 3D Slicer などのツールを活用して、インタラクティブな医用画像にアノテーションを付けています。 6. データサイエンティストは、Amazon SageMaker のアノテーション付き画像を使用して、組み込みのディープラーニングモデルを構築または活用します。SageMaker には、低レイテンシーや高スループットから長時間実行される推論ジョブまで、さまざまな展開オプションが用意されています。これらのオプションには、バッチ、リアルタイム、または ニアリアルタイム の推論に関する考慮事項が含まれます。 7. 医療提供者は AWS AHI と Amazon SageMaker を使用して、AI を活用した検出と解釈のワークフローを実行しています。このワークフローを使用して、見えにくい骨折、脱臼、軟部組織損傷を特定し、外科医や放射線科医が自信を持って治療を選択できるようになります。 8. 最後に、AWS AHI に保存された画像はモニターやその他の視覚出力デバイスに表示され、放射線科医やその他の医療専門家が分析および解釈できます。 Open Health Imaging Foundation （OHIF）ビューアーは、オープンソースのウェブベースの医用画像プラットフォームです。複雑な画像処理アプリケーションを構築するためのコアフレームワークを提供します。 Radical Imaging と Arterys は、OHIF ベースの医用画像ビューアを提供する AWS パートナーです。 これらの各コンポーネントは、医用画像システムの全体的な性能と精度だけでなく、診断結果と患者ケアの向上に焦点を当てた継続的な研究開発においても重要な役割を果たします。AWS AHI は、効率的なメタデータエンコーディング、可逆圧縮、プログレッシブ解像度データアクセスを使用して、業界トップクラスのパフォーマンスを画像読み込みで提供します。効率的なメタデータのエンコーディングにより、画像ビューアと AI アルゴリズムは、画像データを読み込まずに DICOM 検査の内容を理解できます。 セキュリティ AWS の責任共有モデルは、AWS AHI と Amazon SageMaker におけるデータ保護に適用されます。 Amazon SageMaker は HIPAA の対象であり、保護対象保健情報 (PHI) を含むデータを扱うことができます。転送中のデータの暗号化は SSL/TLS によって提供され、Amazon SageMaker のフロントエンドインターフェイス (ノートブック) との通信時と Amazon SageMaker が他の AWS サービスとやり取りする場合の両方に使用されます。 AWS AHI は HIPAA 適格のサービスでもあり、メタデータレベルでのアクセス制御が可能なため、各ユーザーとアプリケーションには、それぞれのロールに基づいて必要な画像とメタデータフィールドのみが表示されます。これにより、患者のPHIの増加が防止されます。AWS AHI API へのすべてのアクセスは、 AWS CloudTrail に詳細に記録されます。 これらのサービスはどちらも AWS Key Management Service (AWS KMS) を活用して、PHI データを保存時に暗号化するという要件を満たします。 まとめ この投稿では、症状の早期発見と治療のための一般的な使用例を概説し、その結果、患者の治療成績が向上しました。また、テクノロジーの力を活用して医用画像の精度、効率、アクセス性を向上させることで、放射線医学分野を変革できるアーキテクチャについても取り上げました。 参考文献 AWS HealthImaging Partners AWS features AWS HealthImaging at RSNA22 Annotate DICOM images and build an ML model using the MONAI framework on Amazon SageMaker MLOps deployment best practices for real-time inference model serving endpoints with Amazon SageMaker Sukhomoy Basak Sukhomoy Basak はアマゾンウェブサービスのソリューションアーキテクトで、データおよび分析ソリューションに情熱を注いでいます。Sukhomoy は、企業のお客様と協力して、ビジネス成果を達成するためのアプリケーションの設計、構築、拡張を支援しています。 Hassan Mousaid Hassan Mousaid 博士は、アマゾンウェブサービスの主任ソリューションアーキテクトであり、ヘルスケアおよびライフサイエンス (HCLS) のお客様が、Amazon のイノベーションメカニズムを使用してアイデアを市場に投入するプロセスを加速できるようサポートしています。エンタープライズおよびクラウドトランスフォーメーション、ヘルスケアIT、医用画像分野で20年の経験があります。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

この記事は、“ Enhancing multidisciplinary collaboration in digital pathology with cloud-based PACS ” を翻訳したものです。 病理医は凍結切片法を用いて生検した組織の分析を行います。従来、凍結切開では組織生検の可視化に顕微鏡検査のみに頼っていました。ただし、顕微鏡スライドは壊れやすく、細胞構造の視覚化に使用される色素は時間の経過とともに色あせてしまうため、情報の共有とデータ保存に重大な問題が生じます。顕微鏡用カメラの発明により、スライドキャプチャが簡単になりました。それでも、画像はローカルストレージに最適化するために圧縮されることが多く、レポートの作成中に画像をキャプチャするという手作業が追加されるため、病理医の通常のワークフローが中断されることになります。 ホールスライドスキャナーは画像キャプチャの負担を軽減すると、当初はデジタル病理学において関心を呼びましたが、完全なエンドツーエンドのソリューションではありません。世界中の多くの病院は、まだデジタル病理学の可能性を最大限に活用していません。 韓国に拠点を置くヘルスケアテクノロジー（ HealthTech ）企業である INFINITT Healthcare は、スライド標本全体画像（WSI）の出力を医療における Digital Imaging and Communications in Medicine（DICOM）ファイルとして抽出して変換することで、状況を変えることに取り組んでいます。DICOM は、病理医が時間と資源を節約し、多分野のコミュニケーションを効率化し、患者ケアのソリューションを実現するまでの時間を短縮するのに役立つWSIのデジタルバージョンです。その後、これはアマゾンウェブサービス（AWS）上に構築されたクラウドベースの Digital Pathology System（DPS）に保存されます。 デジタル病理学のパイロットリサーチ計画 専門の腫瘍センターを備えたソウル有数の病院である Samsung Medical Center（SMC: サムスン医療センター）は、デジタル病理学の導入を先導しています。SMCは年間200万人以上の患者を診察しており、1,200人の医師と2,300人の看護師を含む約7,400人のスタッフが配置されている三次病院です。INFINITT との共同リサーチ計画で、 SMC は2019年に病理部門でクラウドネイティブな Picture Archiving and Communication System（PACS）を試験的に導入しました。 SMC の病理部門は、年間52,000件の症例をサポートしており、これは1日あたり平均約214人の患者です。病理医は、本院から離れた別の建物で働いています。通常、搬送者が生検標本を搬送し、臨床検査技師が顕微鏡検査のために処理と準備を行い、最終的に病理医が検体を診断する必要があります。緊急の所見は、電話で主治医に伝えられます。 病理学におけるデジタル化の直接的なメリット 以前は、病理医は生検スライドを分析し、その結果を診療ノートに個別のレポートとして記述していました。腫瘍検査中に所見について話し合いたい場合は、顕微鏡に接続されたカメラで顕微鏡画像を撮影し、組織病理学的所見を含む PowerPoint ファイルを準備する必要がありました。さらに、生検スライドが壊れている場合、病理医は同じスライド画像を得るためにパラフィンブロックの再切断を依頼する必要があります。 スライド全体をデジタル化することで、病理医は所見を画像に直接アノテーションできるようになりました。その後、腫瘍ボード中に画像を INFINITT DPS で直接開くことができるため、時間と労力を節約できるだけでなく、患者のケアに焦点を当てたより多くの情報に基づいた意思決定が可能になります。 クラウドベースの DPS は、複数の専門分野にわたる腫瘍学チームにおけるコミュニケーションを即座に改善しました。病理医は、 INFINITT が提供するソフトウェアシステムを使用して、プライマリケアチームに電話をかけ、一緒に WSI をレビューできます。双方向の診断ツールとして、ウェブブラウザに搭載された最新の画面共有技術により、複数の遠隔地の病理医がスライド画像全体を同時に見て、まとめて診断することができます。これが可能なのは、各ユーザーが自分のマウスカーソルでスライドを動かして特定の位置を指すことができ、他の全員がリアルタイムですべてを見ることができるからです。 DPS は、国家レベルでの研究協力を可能にするために、アジア太平洋地域の一部の医療センターで実施されています。その後、韓国病理学会は会員の教育と訓練を目的として DPS を採用しました。 病理医のコミュニティ全体では、新しい DPS によってコストのかかるローカル IT インフラストラクチャの必要性が軽減され、データガバナンスを改善したという意見が一致しています。これまで、研究データ保持ポリシーを大規模に実施することは困難でした。ポリシーに準拠するため、サーバーラックをサードパーティベンダーが廃棄する必要がありました。クラウドベースの DPS では、データ保持ポリシーは Amazon Simple Storage Service (Amazon S3) バケットに書き込まれ、自動的にバックアップされます。 INIFITT が AWS を使用して WSI をデジタル化する方法 図 1.SMC の支援に役立った INFINITT のソリューションのアーキテクチャ図 INFINITT は DPS ソフトウェアで複数の AWS サービスを使用しています。図 1 は、このソリューションの大まかなアーキテクチャを示しています。 1) さまざまな学術機関から提供された DICOM 形式の WSI は、 Amazon Virtual Private Cloud (Amazon VPC) の Amazon Elastic Block Store (Amazon EBS) にエクスポートされ、保存されます。 2) INFINITT DPS は VPC の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされます。 3) ユーザーはウェブポータルを介してWSIの検査にアクセスします。 4) アノテーションが付けられた WSI イメージは Amazon S3 に保存されます。 Amazon SageMaker は、人工知能 (AI) と機械学習 (ML) のワークフロー全体を管理し、関心のある特定の疾患に関するモデルをトレーニングするために使用されます。その後、処理された画像は Amazon S3 に保存され、INFINITT DPS 経由でアクセスできるようになります。 5) Amazon Cognito は INFINITT DPS ロードマップに追加され、臨床研究者の役割分担やアクセスガバナンスの強化など、役割分担によるデータへの安全なアクセスをサポートします。 INFINITT の DPS ソリューションは、病理学者のコミュニケーションと学際的なコラボレーションを強化するのに役立ちます。さらに、従来の IT インフラストラクチャからクラウドベースの PACS に切り替えることで、病院システムは50〜70％の節約になります。DPS は WSI データの自動バックアップをサポートし、データ保持ポリシーのガバナンスを容易にします。 デジタル病理学の次は？ 一般に、WSI の出力は、非圧縮画像の場合は2.5ギガバイト (GB) から10GB までさまざまです。病理検査ラボの一般的な作業負荷は、1日あたり約1,000枚の画像で、これは毎日生成される10テラバイト（TB）のデータに相当します。WSIの研究はGB単位の規模になることがあります。これは、デジタル画像検査の平均サイズが通常数十メガバイト（MB）から数百メガバイト（MB）である放射線画像検査などの他の専門分野とは対照的です。 SMC の病理検査部門全体が100％WSI を使用する方向に向かっているため、長期的にはクラウドベースの DPS の方がはるかに費用対効果が高い可能性があります。スライドのデジタル化により、SMC はさらなる革新と Amazon SageMaker を使った実験を計画しています。 SMC は、WSI での病理所見の検出を加速できる AI および ML アルゴリズムを構築する予定です。さらに、乳がんと前立腺がんに必要な面倒な悪性度判定プロセスを自動化して、病理医の臨床作業負荷を軽減したいと考えています。 世界的な労働力の高齢化により、 病理学は専門職の人員不足に直面しています。 しかし、 がんの診断数は増加しています。 したがって、病理学におけるデジタルトランスフォーメーションは、病院が今後数十年にわたって最適な状態で機能し続けるために不可欠です。クラウドネイティブなアプローチは、病院の情報システムに追加の資本的負担や運用上の負担をかけることなく、スタッフと患者の治療成績をサポートするのに役立ちます。 ヘルスケア向け AWS の詳細はこちら 世界中の医療機関や製薬企業は、連携の方法、データ主導の臨床および業務上の意思決定、精密医療の実現、医療費の削減の方法を改革しています。ヘルスケアおよびライフサイエンス組織がビジネス上および技術上の目標を達成できるように、AWS for Health は AWS のサービスと AWS パートナーソリューションを提供しており、世界中の何千ものお客様が使用しています。AWS が世界中の重要な医療ミッションをどのように支援しているかについての詳細は、 AWS for healthcare hubにアクセスする か、 AWS 公共部門チームにお問い合わせください。 AWS 公共部門ブログで関連記事を読む: Large scale AI in digital pathology without the heavy lifting Automating clinical lab workflow at scale for chronic disease monitoring with the cloud Alzheimer’s disease research portal enables data sharing and scientific discovery at scale Designing a biometric IoMT solution to support health equity with AWS ProServe AMILI helps advance precision medicine by building microbiome library on AWS Transforming radiology workflows with clinical decision support powered by AWS AWS Public Sector Blog ニュースレターを購読して 、公共部門の AWS ツール、ソリューション、イノベーションの最新情報をメールで受け取ることができます。または、 お問い合わせください。 このアンケートで AWS Public Sector Blog を使った感想をぜひお聞かせください。 アンケートからのフィードバックをもとに、読者の好みに沿ったコンテンツをさらに作成します。 MinSung Cho MinSung Cho は、韓国のアマゾンウェブサービス (AWS) ヘルスケアのリーダーです。彼は、Picture Archiving and Communication System（PACS）と電子医療記録（EMR）でヘルスケア企業のIT分野で10年以上の経験があり、GEヘルスケアでの前職からは医療用IoT（モノのインターネット）デバイスに関する8年以上の経験があります。 Dr. Sun Park Park 博士は神経内科医であり、医療業界で12年以上の経験を持ち、GEヘルスケア・コリアで6年間のデジタルイノベーションに携わってきた経験もあります。患者中心のケアと、病院のニーズを満たす適切なテクノロジーの導入に情熱を注いでいます。彼女は現在、韓国のアマゾンウェブサービス (AWS) の公的医療部門の事業開発業務を統括しています。 Dr. Petty Chen Chen 博士 は、アジア太平洋および日本 (APJ) の電子医療記録 (EMR) およびアマゾンウェブサービス (AWS) の病院エンゲージメントリーダーです。ハーバード大学で公衆衛生学修士（MPH）を、デューク国立大学医学部で医学博士（MD）を取得しています。ヘルスケアとテクノロジーの交差点で働く彼女は、人工知能（AI）と機械学習（ML）対応のソフトウェア開発における経験豊富なプロダクトリーダーであり、イノベーションの導入においてアジア全域の病院の責任者と緊密に協力してきました。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 AWS Black Belt オンラインセミナーをご存じでしょうか？AWSではいろいろなイベント・セミナーを開催していますが、このBlack BeltシリーズはAWSのサービス単体にフォーカスして解説を提供するものです。このBlack Beltの先月分の内容が以下に公開されています。オンデマンドで過去のセミナーをいつでも閲覧できますし、PDFで資料もダウンロード可能になっていますので活用してください。 – 2023 年 7 月の AWS Black Belt オンラインセミナー資料及び動画公開のご案内 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年8月14日週の主要なアップデート 8/14(月) AWS CodePipeline now supports GitLab フルマネージドの継続的デリバリーサービスである AWS CodePipeline でソースレポジトリとしてGitLab.comがサポートされました。GitLab.comの変更をもとにビルドパイプラインを実行することが可能です。 AWS IAM Identity Center integration is now generally available for Amazon QuickSight Amazon QuickSight が AWS IAM Identity Center (旧AWS SSO)との連携をサポートしました。これにより容易に IAM Identity Center 経由でのフェデレーションサインインでQuickSightへのログインを実現可能です。具体的な連携例としては こちらのブログを参照してください 。 8/15(火) Amazon OpenSearch Serverless expands support for larger workloads and collections Amazon OpenSearch Serverless が拡張され、時系列コレクションの最大インテックスデータが6 TBに増加し(以前は1 TB)、検索・時系列コレクションの最大OpenSearch Compute Units (OCU)数も最大100 OCU(以前は50 OCU)まで拡張されました。OCUはOpenSearch Serverlessの仮想的なコンピューティング性能値です。 Amazon Kinesis Video Streams improves image sampling frequency to 5 frames per second 動画のストリーミング分析サービスである Amazon Kinesis Video Streams で動画から画像の切り出し頻度がこれまでの3秒に1枚から、最大で1秒あたり5枚に改善され、より短い頻度での分析処理が実行可能になりました。 8/16(水) AWS Backup Audit Manager now supports delegated backup administrator AWS Backup Audit Manager で、backup administrator の権限をAWS Organizations内のユーザーに移譲できるようになり、より柔軟な運用に対応可能になりました。 Announcing general purpose Amazon EC2 M7a instances Amazon EC2 の M7a インスタンスが一般提供開始（GA）になりました。現在 Ohio、N. Virginia、Oregon、Irelandリージョンで利用可能です。M7a インスタンスは第四世代AMD EPYC プロセッサ(Genoa)を搭載し、前世代のM6aと比較して最大50%高いパフォーマンスを実現します。詳細は こちらのブログをご覧ください 。 Amazon EC2 D3en instances are now available in additional regions Amazon EC2 D3en インスタンスが利用可能なリージョンが拡大され、新たにTokyo、Frankfurt、Singaporeの3リージョンで利用可能になりました。D3enは最大で 336 TB のローカルHDDを搭載したインスタンスで、最大 75 Gbps のネットワーク帯域と7 Gbps のEBS帯域を提供します。 Amazon RDS now supports M6g and R6g database instances in six additional AWS regions Amazon RDS で AWS Graviton2ベースの M6g、R6gインスタンスが選択可能なリージョンが追加され、新たにOsaka、 Cape Town、Jakarta、Melbourne、Zurich、 Bahrain の6リージョンにおいて利用可能になりました。サポートされるDBエンジンはPostgreSQL、 MySQL、 MariaDB です。 同時にT4gインスタンスのリージョン拡張もアナウンス されており、大阪リージョンを含む前述のリージョンで利用可能になっています。 Amazon RDS Performance Insights provides an on-demand analysis experience Amazon RDS の Performance Insights に新しいメトリクスが追加されました。このリリースにより、選択した期間のパフォーマンスのデータを分析できます。たとえばアプリケーションがスローダウンした期間を分析して、データベースの動作が変化したかどうか、またどのように変化したかを確認したり、それを是正するためのアドバイスを得ることが可能です。この機能は Aurora MySQL、 Aurora PostgreSQL、 RDS for PostgreSQL で利用可能です。 8/17(木) Announcing Amazon EC2 Hpc7a instances Amazon EC2 の Hpc7a インスタンスが一般提供開始（GA）になりました。現在 Ohio、 GovCloud (US-West) リージョンで利用可能です。Hpc7a インスタンスは第四世代 AMD EPYCプロセッサ(Genoa)を搭載し、前世代のHpc6aと比較して最大2.5倍の性能を提供します。詳細は こちらのブログ をご覧ください。 Announcing Amazon GameLift support for instances powered by AWS Graviton3 processors 信頼性が高くスケーラブルなゲームサーバーホスティングを提供する Amazon GameLift で AWS Graviton3 プロセッサを搭載したC7gインスタンスが利用可能になりました。Graviton2 と比較して最大25%高いパフォーマンスを提供可能です。 Amazon FSx for NetApp ONTAP now provides additional performance metrics and an enhanced monitoring dashboard Amazon FSx for NetApp ONTAP に新しいCloudWatchメトリクスが追加され、新たにCPU使用率、SSDのIOPS等が確認可能になりました。詳細は こちらのドキュメント をご覧ください。 8/18(金) AWS Batch on Amazon ECS now supports AL2023 AWS Batch on ECS において、ECSに最適化された Amazon Linux 2023 (AL2023) AMIが選択可能になりました。AL2023は2028年3月までの長期サポートを提供しています。AL2023については こちらのブログを参照してください 。 AWS Audit Manager adds integration with Amazon EventBridge AWS Audit Manager で Amazon EventBridge との連携をサポートしました。Audit Managerのイベントを元にEventBrigde経由で、AWS Lambdaや AWS Step Functionsに連携することが可能です。 AWSのユーザーグループである JAWS-UG をご存じの方も多いと思います。ユーザーグループ主導で各技術領域や地域別にいろいろな勉強会やイベントが毎週実施されています。そのいろいろなイベントの予定について、 こちらのNote で定期的に情報がまとめられているのをご存じでしょうか？今週・来週にどういったイベントがあるのか一覧できるようになっているので、ユーザーグループの活動についてご興味がある方は参考にしてください。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

(本記事は 2023/01/27に投稿された Differences to expect when migrating from Azure Cosmos DB to Amazon DynamoDB を翻訳した記事です。) Azure Cosmos DBのワークロードを Amazon DynamoDB に移行することを検討しているお客様から、どのような違いが想定されるのかと聞かれることがあります。この記事では、Azure Cosmos DBからDynamoDBへの移行時に想定される相違点と、それに備えるための計画について説明します。DynamoDBは、一般的なアクセスパターン (通常は大量のデータの保存と取得) に合わせて最適化された、サーバーレスなキーバリュー型のデータベースです。DynamoDBではマルチリージョン、アクティブーアクティブなフルマネージドのデータベースであり、あらゆる規模で１桁ミリ秒という一貫したレイテンシー、保存時の暗号化、バックアップと復元、インメモリキャッシュを実現します。DynamoDBはイベント駆動型アーキテクチャの一部として一般的に使用されており、他のAWS サービスを使用することでDynamoDBの機能を拡張することができます。 用語とアーキテクチャの比較 Azure Cosmos DBとDynamoDBはどちらもNoSQLデータベースですが、移行を開始する前にアーキテクチャと用語の違いを考慮する必要があります。 DynamoDB Azure Cosmos DB テーブル Table コレクション Collection 項目（最大サイズは400 KB） Item (maximum size is 400 KB) ドキュメント（最大サイズは2 MB） Document (maximum size is 2 MB) 属性 Attribute フィールド Field プライマリーキー：パーティションキー Primary key: Partition key パーティションキー Partition key プライマリーキー：ソートキー（任意） Primary key: Sort key (optional) 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields 複合プライマリーキー：プライマリーキー + ソートキー Composite key: Partition key + Sort key 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields ローカルセカンダリインデックス（LSI） ：パーティションキーはメインテーブルと同様で、ソートキーと非キー属性が異なる Local secondary index (LSI) : Same partition key as the main table but different sort key and non-key attributes 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields グローバルセカンダリインデックス（GSI） ：メインテーブルとは異なるパーティションキーとソートキーおよび非キー属性 Global secondary Index (GSI) : Different partition and sort key than in the main table and non-key attributes 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields Amazon Kinesis Data Stream と Amazon DynamoDB Streams Amazon Kinesis Data Streams and Amazon DynamoDB Streams 変更フィード Change Feed 1 RCU: 1 つの読み込みキャパシティーユニットは、強力な整合性を実現するには 1 秒あたり4KB、結果整合性を維持するために 1 秒あたり8KB One RCU: One read capacity unit is 4 KB per second for strong consistency and 8 KB per second for eventual consistency.1 WCU: 1 つの書き込みキャパシティーユニットは 1 秒あたり1KB One WCU: One write capacity unit is 1 KB per second. 1 RU: 要求ユニット (読み取りの場合、1 KBで) One RU: Request unit (1 KB for read)5 RU: 要求ユニット (書き込みの場合、1 KBで) Five RU: Request unit (1 KB for write) 複数のパーティションとテーブルにわたる トランザクションサポート Transaction support across multiple partitions and tables パーティション内のみのトランザクションサポート Transaction support only within a partition Amazon DynamoDB Accelerator (DAX) による読み取り時の応答時間をマイクロ秒で実現 Amazon DynamoDB Accelerator (DAX) for microsecond response time on reads 利用不可 Not available 使用可能なモード: プロビジョンド、オートスケーリング、オンデマンド Available modes: provisioned, autoscaling, and on-demand 使用可能なモード:プロビジョンド、オートスケーリング、サーバーレス Available modes: Provisioned, autoscaling, and serverless 保存時と転送時の暗号化 Encryption at rest and in transit 保存時と転送時の暗号化 Encryption at rest and in transit 論理パーティション Logical partitions 論理パーティション Logical partitions API サポート:DynamoDB API と PartiQL API support: DynamoDB API and PartiQL APIサポート：Core (SQL)、Cassandra、Gremlin、MongoDB、TableおよびPostgreSQL API support: Core (SQL), Cassandra, Gremlin, MongoDB, Table, and PostgreSQL 表 1: DynamoDB と Azure Cosmos DB の用語とアーキテクチャの比較 （注：より理解しやすいように本文の英語を併記しています） Amazon DynamoDB テーブル、スキーマ、およびインデックス 移行をシンプルにするため、Azure Cosmos DBのコレクションとDynamoDBのテーブル間を１対 １でマッピングするようにしてください。DynamoDBにはデータベースの概念はなく、テーブルと呼ばれるエンティティがあります。Azure Cosmos DBのコレクションに基づいてDynamoDBのテーブルを作成する場合： カーディナリティの高いパーティションキーを選択します。DynamoDBはパーティションキーの値を内部ハッシュ関数への入力として使用します。ハッシュ関数の出力によって、項目が保存されるパーティションが決まります。各項目の場所は、そのパーティションキーのハッシュ値によって決定されます。ほとんどの場合、同じパーティションキーを持つ項目は項目コレクションにまとめて格納されます。項目コレクションは、パーティションキーは同じでソートキーが異なる項目のグループとして定義されます。複合プライマリキーを含むテーブルでは、ソートキーはパーティションの境界として使用できます。DynamoDBは、コレクションサイズが10 GBを超えると、仮想的なパーティションをソートキーごとに分割します。ソートキーを使用してAzure Cosmos DBのプライマリ複合インデックスを置き換えることもできます。パーティションキーを選択する方法の詳細については、「 Choosing the Right DynamoDB Partition Key 」を参照してください。 同じパーティションキーと異なるソートキーを必要とするクエリパターンの場合では、非キー属性とともに、メインテーブル作成時にGSIまたはLSIを作成できます。GSIは、非キー属性とともに、テーブルの作成中または作成後でも作成することができます。 注: GSIが推奨されるオプションです。LSIを使用する場合、１つのパーティションキー値に対するインデックス項目の合計サイズが 10GB を超えることはできません。 プライマリキーとソートキーが異なるクエリパターンには、GSIを使用することが推奨されます。GSIはメインテーブルの作成中または作成後に、非キー属性とともに作成することができます。 Amazon Simple Storage Service (Amazon S3) から DynamoDB データをインポート する場合、インポート中にGSIが追加されます。ローカルおよびグローバルセカンダリインデックスは、一度定義されると、DynamoDBによって自動的に管理されます。セカンダリインデックスを使用すると、ベーステーブルと比較してデータサイズを削減するのに役立ちます。セカンダリインデックスのサイズが小さくなるかどうかは、使用される非キー属性の数によって異なりますが、プロビジョニングされたスループットのパフォーマンスを向上させるのに役立ちます。プロビジョニングモードのテーブルにGSIを作成する場合、そのインデックスに予想される負荷に応じて読み取りと書き込みキャパシティーユニットを指定する必要があります。GSI上でのクエリ操作は、ベーステーブルではなく、インデックスから読み取りキャパシティユニットを消費します。テーブル内の項目を追加、更新、削除すると、そのテーブルのグローバルセカンダリインデックスは非同期で更新され、インデックス更新は、ベーステーブルではなくインデックスの書き込みキャパシティーユニットを消費します。テーブル属性をGSIに投影する場合は、新しい更新がベーステーブルとGSIの両方に書き込みを行うため、プロビジョニングされた書き込みキャパシティーユニットをベーステーブルの書き込み容量と同等かそれ以上の値に設定することを推奨します。なお、GSIの更新には ２つの書き込みが必要となり、１つは、インデックスから前の項目を削除する書き込み、もう１つはGSIのパーティションキーまたはソートキーである属性を更新する際に、新しい項目をインデックスに追加するための書き込みとなります。 Azure Cosmos DBは、２つ以上のプロパティを持つ複合インデックスをサポートしています。ソートキーを連結して DynamoDBプライマリキーとセカンダリインデックスにマッピングできます。例えば、Azure Cosmos DBのEmployee ID、Country、State、Cityの各フィールドが複合キーとして定義されている場合、DynamoDB では、Employee IDをパーティションキー、ソートキーを country#state#city に置き換えます。なお、ソートキーの#はユーザー指定の区切り文字で、コロン（:）、カンマ（,）、チルダ（~）などの他の区切り文字に変更できることに注意してください。 DynamoDBはAzure Cosmos DBのデータ型をサポートしているほか、バイナリとセットのデータ型もサポートしています。Azure Cosmos DBからDynamoDBへの属性マッピングについては、表２を参照してください。 DynamoDB Azure Cosmos DB DynamoDB description Number Number 38桁の精度を持つ数値 String String UTF-8バイナリエンコードによるUnicode Boolean Boolean True or False List Array 順序付きの値のコレクション Map Object 順序なしの名前と値のペアのコレクション。Azure Cosmos DBのフィールドにある深くネストされたJSONデータには、このDynamoDBデータ型を使用してください。 Set Not supported 数値、文字列、バイナリなどの同じデータ型のコレクション Binary Not supported 圧縮されたテキスト、画像、または暗号化されたデータ 表 2: DynamoDB 属性マッピング DynamoDBインデックスはAzure Cosmos DBとは異なります。Azure Cosmos DBは転置インデックスを使用しますが、DynamoDBはテーブルパーティションとインデックスパーティションにハッシュアルゴリズムを使用します。Azure Cosmos DBのネストされたJSONインデックスを移行する場合、Azure Cosmos DBのインデックス付き属性は DynamoDB のプライマリキー、LSI、または GSIの一部である必要があります。ネストされたインデックス化されていないオブジェクトをマップデータ型として追加できます。 DynamoDBにはAzure Cosmos DBストアドプロシージャやユーザー定義関数と同等のものはありませんが、 AWS Lambda またはDynamoDB StreamsとLambdaの組み合わせを使用して同等の機能を実行することは可能です。DynamoDBクライアントはDynamoDBデータの事後後処理に責任を持ちます。 キャパシティユニット DynamoDBには、読み取りキャパシティーユニット (１つの RCU は、強力な整合性のある読み取りでは1秒あたり4KB、結果整合性のある読み取りでは 8KB/秒) と書き込みキャパシティーユニット (1 WCU はDynamoDBテーブルへの書き込みで1秒あたり1KB) があります。DynamoDBの RCUとWCU の要件を把握するには、DynamoDBをオンデマンドモードで実行することをお勧めします。移行を完了する前にオンデマンドモードでテーブルの負荷テストを実行することで、アプリケーションとテーブルがライブトラフィックに最適化されていることを確認できます。トラフィックパターンが急上昇するような場合には、引き続きDynamoDBオンデマンドモードの使用を継続します。予測可能なトラフィックパターンでは、負荷テストのベースラインを使用してプロビジョニングされたキャパシティを設定します。DynamoDBがアプリケーショントラフィックの増加に合わせてスケールすることができ、プロビジョニングされたスループットが不十分であることによるエラーを回避できるようにするために、プロビジョニングされたキャパシティーでオートスケーリングを使用することを推奨します。 グローバルテーブル の場合、書き込みキャパシティーの設定は、使用する各リージョンのレプリカテーブルとセカンダリインデックス全体で一貫して設定する必要があります。また、グローバルテーブルのレプリカの読み込みキャパシティー設定は、リージョンの読み取り要件に基づいている必要があります。 有効期限 (TTL) Azure Cosmos DBの有効期限（TTL）設定をDynamoDBに移植できます。Azure Cosmos DBのTTL（秒単位）をDynamoDB のエポックタイムに変換する必要があります。 DynamoDB TTL では、項目ごとにタイムスタンプを定義して、項目が不要になる時期を判断できます。項目が不要になったことを示すタイムスタンプから 48時間以内 に、DynamoDB は書き込みスループットを消費せずにその項目をテーブルから削除します。TTL は、ワークロードのニーズに合わせて最新の項目のみを保持することで、保存されるデータ量を削減する手段として、追加コストなしで提供されます。 DynamoDBのきめ細かなアクセス Azure Cosmos DBには、ロールベースのアクセス制御（RBAC）が組み込まれています。DynamoDBは、 AWS Identity and Access Management（IAM） を使用して、 項目および属性レベルでのきめ細かなアクセス を提供します。IAMポリシーは、DynamoDBのテーブルに格納された項目や属性へのアクセスを制御します。以下は、きめ細かいアクセス制御の２つの例です。 ユーザーの位置情報に基づいて近くの空港の情報を表示するモバイルアプリ。アプリは、航空会社名、到着時刻、フライト番号などの属性にアクセスして表示することができます。ただし、パイロットの名前や乗客数にアクセスしたり表示したりすることはできません。 ユーザーのハイスコアを１つのテーブルに保存するモバイルゲーム。各ユーザーは自分のスコアを更新できますが、他のプレイヤーのスコアを更新することはできません。 マイクロ秒単位のパフォーマンスを実現するAmazon DynamoDB DAX Azure Cosmos DBの読み取り時でマイクロ秒のレスポンスにサードパーティのキャッシュソリューションを使用している場合、 Amazon DynamoDB Accelerator（DAX） を使用することもできます。DAXを使用すると、コードをリファクタリングすることなくキャッシュソリューションを組み込むことができます。DAXは、DynamoDBのための結果整合性のあるライトスルーキャッシュレイヤーです。DAX は、必要に応じてリードスルーモード、ライトスルーモード、またはライトアラウンドモードで使用することができます。 Azure Cosmos DB変更フィードをDynamoDBに再設計する Azure Cosmos DBは、Azure Cosmos DBの変更フィードを使用して他のAzureサービスに変更を伝搬します。DynamoDBには、 変更データキャプチャ（CDC） 用に Amazon Kinesis Data Streams と Amazon DynamoDB Streams という２つのストリーミングオプションがあります。それぞれのストリーミングオプションは、以下で説明するユースケースに対応しています。 Kinesis Data Streamsは、ログデータのキャプチャ、リアルタイムメトリックスとレポート、リアルタイムデータ分析、複雑なストリーム処理などのユースケースに使用します。データストリームは、レコードの順序付けや重複が重要ではない場合に使用します（最終的な宛先で重複を処理し、冪等性のある処理を実現することができます）。たとえば、 Amazon OpenSearch Service では、複数のコンシューマーが無制限のスループットでストリームを並行処理する必要がある場合や、24時間を超えるデータ保持が必要な場合に、バージョニングと一意のIDを組み合わせて処理の重複を防ぐことができます。 DynamoDB Streamsは、時系列の変更ストリームをキャプチャし、この情報を最大24時間ログに保持します。その後、アプリケーション内から DynamoDB Streams Kinesis Adapter とDynamoDB Streams APIを使用して、専用のエンドポイントからデータレコードを読み取ることができます。また、Lambdaを自動スケーリングで使用してDynamoDB Streamsのデータを処理することもできます。 DynamoDB Streamsを使用する場合、ストリーミングデータを利用するには Kinesis Adapterが推奨されます。DynamoDB Streams Kinesis Adapterは、アプリケーションに代わって シャード管理 （シャードの有効期限と分割）を自動化します。また、「 DynamoDB Streams Kinesis Adapter を使用したストリームレコードの処理 」に記載されている、その他の利点もあります。Lambdaを使用してDynamoDBの追加、更新、削除イベントを開始できます。Azure Cosmos DBトリガーの代わりに DynamoDB StreamsとLambdaトリガーを使用することを検討してください。 DynamoDB Streamsの使用方法の詳細については、「 DynamoDB Streams Use Cases and Design Patterns 」を、Kinesis Data Streamsと DynamoDB Streamsの詳細な比較については DynamoDB ドキュメント を参照してください。 400 KB を超える項目の処理 DynamoDB の最大項目サイズは400KB で、これには属性名のバイナリ長 (UTF-8の長さ) と属性値の長さ (バイナリの長さ) の両方が含まれます。DynamoDBでは、400KBを超える項目に対して、GZIPなどの圧縮アルゴリズムを使ってから項目を挿入したり、大きな項目を複数の小さな項目に分割したりすることができます。また、これらの大きなオブジェクトをS3バケットに保存し、S3オブジェクトのURLを属性としてDynamoDBテーブルに保存することもできます。このアプローチでは、DynamoDBのインデックスを使用して高速な検索を行い、S3を耐久性が高く費用対効果の高いオブジェクトストアとして使用できます。 例として、あるアプリケーションが従業員の記録（名前、住所、その他の情報）を管理し、各従業員の600×400ピクセルの画像も保存する必要があるとします。この場合、1人の従業員の項目サイズが 400 KB の制限を超えています。さらに、ユーザーは従業員の項目がDynamoDBに追加されたら、すぐに人事アプリケーションを更新する必要があります。画像のURLを従業員の項目の属性として保存し、イメージを S3 バケットに保存できます。DynamoDB Streamsを使用してLambda関数を起動し、人事アプリケーションを更新できます。以下の図 1 は、このアプローチを示しています。 図１：大きなアイテムサイズを扱うためのアーキテクチャ この記事に記載されているソリューションオプションの詳細については、「 Large object storage strategies for Amazon DynamoDB 」と「 Use vertical partitioning to scale data efficiently in Amazon DynamoDB 」を参照してください。 グローバルテーブルとリージョナルテーブル DynamoDBグローバルテーブルは、独自のクロスリージョンレプリケーションソリューションを構築、維持することなく、マルチリージョン、アクティブーアクティブデータベースを展開するためのフルマネージドソリューションです。テーブルを利用したいリージョンを指定することができ、DynamoDBはそれらのリージョンを介して継続的なデータ変更をテーブルに伝搬します。これにより、ユーザーがどこにいても、低レイテンシーのデータアクセスが可能になります。Azure Cosmos DBのグローバルデータレプリケーションの代わりに DynamoDBグローバルテーブルを簡単に使用することができます。 DynamoDB はレプリカと同期するための非同期レプリケーションを提供し、通常1秒未満でリージョン間のレプリケーションを行います。レプリカの競合が発生した場合、DynamoDBグローバルテーブルでは、ベストエフォートで最終書き込み者優先が使用されます。DynamoDBグローバルテーブルは、グローバルに分散したユーザを持つ地理的に分散したアプリケーションに最適です。 Amazon DynamoDBのバックアップとリストア機能 DynamoDB には、データをバックアップおよびリストアするためのオプションがいくつかあります。 ポイントインタイムリカバリ（PITR） を使用すると、偶発的なDynamoDBテーブルへの書き込みや削除から保護することができます。PITRは継続的にデータをバックアップするので、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス（AWS CLI） 、または DynamoDB API を使用して、過去35日間の任意の時点にテーブルをリストアできます。PITRを使用することで、オンデマンドバックアップの作成、管理、スケジュールについて心配する必要はありません。また、DynamoDB のオンデマンドバックアップ機能を使用して、テーブルのフルバックアップを作成し、長期保存したり、コンプライアンスの対応に合わせてアーカイブを作成することができます。PITRとオンデマンドバックアップはどちらも、テーブルのパフォーマンスや APIレイテンシーには影響を与えません。 Azure Cosmos DB データを DynamoDB に移行 Azure Cosmos DBからDynamoDBへのデータ移行は以下の手順で行います。 Azure Azure データエクスプローラー を使用して CSV 形式でデータをエクスポートします。 データがCSV形式になったら、 AWS Database Migration Service (AWS DMS) を使用して DynamoDB に移行します。AWS DMS に関するチュートリアルについては、「 Migrate Delimited Files from Amazon S3 to an Amazon DynamoDB NoSQL Table Using AWS Database Migration Service and AWS CloudFormation 」を参照してください。 DMSを利用してデータを同期させます。 AWS Glue を使用してCosmos DBを移行できます。詳細については、「 Migrate from Azure Cosmos DB to Amazon DynamoDB using AWS Glue 」を参照してください。 Amazon S3 からテーブルデータをインポートすることもできます。詳細については、「 Amazon DynamoDB can now import Amazon S3 data into a new table 」を参照してください。 まとめ この記事では、Azure Cosmos DBとDynamoDBの関連する機能の違いと、移行時に考慮すべきアーキテクチャパターンについて説明しました。相違点はあるものの、それに適応するための方法があります。グローバルセカンダリインデックスのシャーディングとインデックスの過負荷への戦略、マテリアライズドクエリを使用したスケーラブルなグラフ処理、複合キーを使用したリレーショナルモデリング、そして、DynamoDBでのトランザクションワークフローの実行に関する詳細情報は「 DynamoDB Deep Dive: Advanced Design Patterns 」を参照してください。 質問や提案がある場合は、コメントを残してください。 著者について Utsav Joshi はAWSのプリンシパルテクニカルアカウントマネージャーです。ニュージャージー州在住で、AWSのお客様と協力してアーキテクチャ、運用、およびコスト最適化の課題を解決することを楽しんでいます。余暇には、旅行、ロードトリップ、子供たちとの遊びを楽しんでいます。 Joydeep Dutta はAWSのシニアソリューションアーキテクトです。Joydeepは、AWSのお客様と協力してワークロードを AWS クラウドに移行し、コストを最適化し、アーキテクチャのベストプラクティスを支援することを楽しんでいます。彼は、企業のコストと複雑さを軽減するのに役立つエンタープライズアーキテクチャに情熱を注いでいます。彼はニュージャージー州に住んでおり、余暇には音楽を聴いたり、屋外で過ごしたりしています

前回の記事 では、ストアコンピュータや、POS といった店舗に配置されているワークロードを AWS で稼働させるにあたってのメリットや構成について可用性と応答性能に焦点をあてて考察しました。本記事では、AWS クラウドに移行後のアーキテクチャと、実現に向けたアプローチについて考察します。 アーキテクチャとして検討すべき対象範囲 店舗システムをクラウド化するメリットとして、前回の記事では以下のメリットを述べました。 コスト削減（ストアコンピュータレス） 運用効率化（システム集約化、ハードウェアライフサイクルからの解放） 機能の高度化（データ活用のし易さ、ハードウェアリソース制約からの解放） 最後の機能の高度化について、店舗システムということで、POS や検品や陳列、発注やスタッフ管理といった店舗業務が検討範囲であることは言うまでもありませんが、”顧客の購買体験を提供する店舗” として考えた場合、購買体験がテクノロジーの進歩と共に変わっていることは、顧客でもある皆様はご理解いただけるのではないでしょうか。 以前：顧客の購買体験は店舗で完結 現在：顧客の購買体験は店舗で完結するわけでなく、ECやモバイルなどをまたがっている（例えばモバイルオーダーで注文して店舗で受け取る、フードデリバリーのように顧客は店舗に来店しないが店舗が介在する） 図1：購買体験の変化 購買体験が変化すると、店舗オペレーションや店舗システムも対応する必要があります。従って、アーキテクチャを考えるにあたり、既存業務の継続はいうまでもありませんが、絶えず変化する顧客ニーズや購買体験の変化に対応できるアーキテクチャが求められます。つまり、下図のような店舗システムにおける主要な機能とデータの配置を、そのままクラウドに移行することはできますが、変化により対応しやすいアーキテクチャに変更する契機と捉えることもできます。 図2：店舗システムと連携先システム 多様で変化する顧客ニーズに統一的な体験を提供するユニファイドコマース 絶えず変化する顧客ニーズや購買体験の変化に対して、リアル店舗やアプリケーションを含めた統一した体験を提供する ユニファイドコマース を通して顧客体験を向上させることに取り組まれています。小売業者がリアル店舗、EC サイトなど複数の販売チャネルを消費者に向けて用意する販売戦略がオムニチャネル戦略ですが、それぞれのチャネルにおいて消費者へ “統一された ( Unified ) ” 購買体験を提供することを目指す考え方がユニファイドコマースです。 ユニファイドコマースを実現するにあって、統一された顧客体験を提供するため、顧客との接点であるモバイルアプリ、店頭のタブレット、店舗の POS 端末など、様々なチャネルから顧客の行動履歴やオペレーションのデータをリアルタイムで受け取る必要があります。そして、チャネルが様々であっても、注文や在庫などの複数の拠点から随時更新される情報は最新の正しい値を特定できるようにデータを一元管理し、各チャネルからのリクエストに応じて共通のコマース機能を通してリアルタイムに情報を返す必要があります。 図3：ユニファイドコマース実現イメージ アーキテクチャは、多くの小売業者が注目している MACH (Microservices-based, API-first, Cloud-native SaaS, Headless) アーキテクチャを取り入れることで実現できます。ビジネスの機能別に開発できるようなマイクロサービスで設計し、機能間の連携は API を通して行い、クラウドの柔軟性やスケーラビリティを活用し、フロントエンドはヘッドレスな設計にすることでバックエンドのロジックと切り離して疎結合とする、という原則に基づいたアーキテクチャです。 図4：MACH アーキテクチャによる実店舗と EC が連携するアーキテクチャイメージ ユニファイドコマースを実現するにあたってのガイダンス AWS は、ユースケース別の AWS ベストプラクティスに基づく設計や実装として、AWS Solutions / Solutions Guidance / AWS Samples を用意してます。これらを利用することによって、全てを 1 から考えて自社向けに開発して、他社との差別化にならない部分に時間とお金を投資することを避けられます。 ユニファイドコマースについては、Solutions Guidance（ソリューションガイダンス）が用意されていて、「 AWS でのユニファイドコマースに関するガイダンス 」を参考にできます。 図5：アーキテクチャ図 詳しくは、ソリューションガイダンスのウェブページに加えて、本ソリューションガイダンスを解説しているこちらのブログ（ ビジネスアジリティを加速する AWS のアーキテクチャ part 2 – Unified Commerce on AWS ）にまとめられていますが、MACH アーキテクチャの原則に則っています。 店舗システムの移行にあたってのコンポーザブルアプローチ 店舗システムは、様々な業務機能やデータから構成されています。ストコン や POS といった機器に分かれているものの、長年運用していると、初めは別々に作られていた機能が、相互に関連し合う、いわゆる密結合となっていることは起こり得ます。また、クラウド移行後のユニファイドコマース、MACH アーキテクチャを紹介しましたが、今後を見据えてアーキテクチャを変更するものもあれば、差別化にはならないためそのまま移行するものもあります。 店舗業務の分類 業務システムに対する期待 システム/機能の例 移行方針の例 接客・販売 多様で変化する顧客ニーズに素早く対応することが期待される POS セルフレジ、スマフォレジを展開をしやすくするためアーキテクチャを変更する 在庫 モバイルオーダー、フードデリバリーとの連携をしやすくするためアーキテクチャを変更する バックヤード・店舗管理 接客・販売に注力できるための効率化が、業務だけでなくシステム面でも期待される 検品 既存機能を踏襲するので単純移行する スタッフ勤怠管理 開発と運用の負担を軽減するため SaaS を利用する 1 回で移行するビッグバンアプローチは、シンプルではあるものの移行失敗時による変革のリスクがありますが、共通のコマースメカニズムをマイクロサービスで提供するユニファイドコマースにおいては、必要となる仕組みを段階的に組み立てていくコンポーザブルアプローチにより、リスクの軽減を図りつつ、すばやく実現していくことができます。 密結合となっている、結果として一枚岩（モノリス）なアプリケーションを段階的に移行する設計パターンとして、ストラングラーフィグパターンを利用することができます。利用できるケースや考慮事項、実装といった詳細については、AWS の規範的ガイダンスのクラウドの設計パターン、アーキテクチャ、実装にまとめられています（ こちら ）。 この他、モノリスのアプリケーションからマイクロサービスとして機能を切り出すにあたっては、AWS の規範的ガイダンスの モノリスをマイクロサービスに分解 に、ビジネス能力別に分解、サブドメインによる分解、トランザクションによる分解、チームごとのサービスパターンなどの各パターンの利点と欠点を含む特徴がまとめられているので参考になります。さらに、マイクロサービス間でデータを永続化するためのパターンについては、 マイクロサービスにおけるデータ永続性の実現 にまとめられています。 まとめ 本記事では、店舗システムの AWS クラウドに移行後のアーキテクチャと、実現に向けたアプローチについて考察しました。顧客の購買体験を提供する店舗として、店舗に限らない各販売チャネルで統一した体験を提供するユニファイドコマースとして検討していく必要性と、ユニファイドコマースを実現する MACH アーキテクチャを紹介し、AWS より提供するソリューションガイダンスや規範的ガイダンスを利用することで、1 から考える必要がなく、実現に向けて迅速に進められることを説明しました。 コンビニエンスストアやスーパーマーケットなど多店舗展開している小売業では、どの機能からどのような移行方針で進めるか、という観点だけではなく、全店舗一斉に切り替えるのか、あるいは地域や店舗形態などの分類単位より段階的に切り替えるのか、という観点も考える必要があります。本記事によって、店舗システムのクラウド化にあたって考えなければならないことが減り、それによりクラウド移行が促進され、結果としてビジネスの成長につながれば幸いです。

しばしば組織の「個性」と表現される組織文化は、人々の働き方、相互作用、変化や課題への対応を決定します。組織の文化が変革の成功を左右する強力な要因であるという認識は、 エビデンス にも裏付けられています。文化の影響は、クラウドの変革においてさらに大きくなります。というのも、クラウドの機能がいかに有用だとしても、その実際の有用性は人々がどのように使うかによって決まるからです。 しかしながら、組織文化が存在し、従業員の行動を形成するということに誰もが同意するとしても、それは主観的で無形のものです。組織文化は、Well-Architected なシステムのように、意図して思慮深く設計および構築することは可能でしょうか？ この記事では、ビジネスの成果を達成するためにクラウド導入を加速する適切な組織文化を構築するためのベストプラクティスを提供します。 なぜクラウド導入に適した組織文化が重要なのか？ クラウドは、コスト削減、業務のアジリティ向上、運用の強靭性、スタッフの生産性向上など、多くの利点を提供しています。クラウドは急速に成長し、広く運用されているにもかかわらず、クラウドサービスのもたらす価値の実現において他の組織よりも成功している組織があります。 私たちのお客さまは、クラウドを利用して企業のデジタル変革を推進する上で、非技術的な要因、特に文化的変革が最大の課題だと述べています。すべての組織には既存の文化があります。文化には、クラウドへの対応を助ける側面もあれば、中立的な側面もあり、はたまた対立する側面もあります。成功している企業は、文化的な手段を活用して潜在的な問題点を特定して対処することで、クラウド導入を加速させています。 たとえば、クラウド導入を成功させるには、セルフサービスと再利用を重要視するオープンで協力的な文化が必要です。クラウドによって、企業は完璧さよりもスピードを優先するようになります。考えられるすべての結果に対して過度に分析する必要はありません。実験が奨励され、従業員は 試行錯誤 を通じて学ぶことができます。一方、指揮統制に基づいて意思決定を行う階層的な文化を持つ組織は、イノベーションを阻害し、クラウド導入における課題に直面する可能性があります。 組織文化の構築（アーキテクティング） 本来、または目的があって、すべての組織には文化があります。成功する企業文化は偶然の産物ではなく、慎重かつ意図的に構築されたものです。文化にはある程度の自発性と予測不可能性があるかもしれませんが、目的意識のある行動によっても影響を受け、形成されることもあります。 お客さま中心の文化 ：クラウドプラットフォームは、ビジネスソリューションを構築するための既製のビルディングブロックを提供します。お客さま中心の文化を促進することで、チームは「 他社との差別化につながらない面倒な重労働 」を省き、IT 内部ではなくビジネス価値とイノベーションに集中できるようになります。お客さま中心の文化は、お客さまのニーズ、嗜好、および行動を深く理解することを含みます。Amazon ではこれを「 Working Backwards 」（お客さまを起点に考え行動する）と呼んでいます。すべてのレベルの従業員がお客さまの満足を優先し、積極的にフィードバックを求め、お客さまからいただいた洞察に基づいて製品とサービスを改善するよう奨励されるべきです。 模範となるリーダーシップの文化 ：CEO はしばしば企業の文化、価値観、および長期的な目標を定義する一連の原則を実施します。これらの原則は、従業員に一体感をもたらすのに役立ちます。ただし、真に効果的なものであるためには、これらの原則が示されるだけでなく、組織のあらゆるレベルで実践される必要があります。リーダーは、「なぜクラウドなのか？」を明確に説明する中で、定義され、測定可能で、期待されるビジネス成果を伝える必要があります。変革をもたらすリーダーは、クラウド戦略の設定と伝達において、「これが私たちの未来です。そのためのロードマップがあり、その道のりを成功させるために必要なリソースを提供します。」と企業自身、自分たちの事業に対して伝えます。信頼を育み、リソースを提供し、自律性とコラボレーションを促進することで、リーダーは従業員が主体性を発揮し、前向きな変化を推進できるよう支援します。また、従業員が叱責を恐れることなく問題をエスカレーションできるオープンで安全な環境も醸成します。 データ駆動の意思決定文化 ：今日の意思決定には、固定的なオペレーション情報だけでなく、次のステップや将来の見通しをリアルタイムで分析する必要があります。クラウドは、事業において戦略的意思決定を行うために膨大な量のデータを処理するための強力な人工知能（AI）および機械学習（ML）ツールを提供します。クラウド導入のメリットを最大化するには、データを使用して情報を提供し、優先順位を付け、意思決定の指針を決めることに重点を置く、データ駆動の意思決定文化が必要です。たとえば、製造業ではクラウドベースの AI と ML ツールを使用してセンサーデータを分析し、ダウンタイムを最小限に抑え、コストを削減するためのメンテナンスを予測しスケジュールすることができます（予知保全）。データ駆動の意思決定文化を実施することで、予知保全分析からの得た知見を活用してメンテナンスタスクを優先順位付けし、リソースを効率的に割り当てることができます。 アジリティ、イノベーション、実験、リスクを取る文化 ：クラウドコンピューティングはアジャイル開発文化に適しています。それは実験、柔軟性、インクリメンタル（段階的）な提供の原則に基づいています。クラウドネイティブ技術は、サービス提供に影響を与えることなく、システムの迅速かつ頻繁な変更をサポートします。アジャイル開発アプローチでは、完璧よりもスピードが重視されます。望ましくない結果が発生した場合に、実行してはいけないアクションを知っておくことには価値があります。たとえば、Amazon では、 リーダーシッププリンシプル を指針として誘導し実行するためのメンタルモデルを使用しています。「Bias for Action」はその指針の 1 つで、「ビジネスにおいてスピードが重要です。多くの決定と行動は元に戻せるため、詳細な調査は必要ありません。計算されたリスクテイクを大切にします。」と述べています。 継続的な学習の文化 ：これは、従業員がクラウドの環境に対応するスキルと知識を持つことを確実にするために、組織が従業員のトレーニングと教育を優先する必要があることを意味します。これにはクラウドサービスに関する技術的なトレーニングだけでなく、コミュニケーションやコラボレーションといったソフトスキルを含みます。学習は自助努力で為すべきであり、イベント駆動のものでは成り立ちません。組織全体で絶え間なく学ぶためには、測定と報酬の仕組みが必要です。トレーニングだけでなく、クラウドの経験が豊富な従業員が新しいチームメンバーを指導するための社内メンターシッププログラムを設立することもできます。 再利用の文化 ：クラウドの価値を高めるためには、ソフトウェア資産の再利用が必要です。再利用により、組織は既存の実証済みで信頼性の高いソフトウェアコンポーネントを活用して、効率性の向上、コスト削減、市場投入までの時間の短縮を実現できます。たとえば、従来のソフトウェア開発者はインフラストラクチャリソースの複雑さを理解するのに時間を費やし、ビジネス価値を提供するソフトウェアの構築に充分な時間を割くことができませんでした。クラウドでは、 Infrastructure as Code (IaC) を使用することで、開発者は事前に構築されテストされた再利用可能なテンプレートを選択し、ソフトウェアアプリケーションを構築するために必要なインフラストラクチャコンポーネントを自動的にプロビジョニングします。再利用の文化には、個人が自分の知識、経験、リソースを他者と積極的に共有できる、オープンで協力的な考え方が必要です。 自動化とセルフサービスの文化 ：クラウド導入には、クラウドの強力な自動化ツールとセルフサービス機能を活用したリソースの提供、管理、利用が含まれます。セルフサービスには、従業員が信頼されて権限を持ち、自らのタスクに責任を持つような文化の変革が必要です。たとえば、オンプレミス環境では、アプリケーションチームは通常、IT インフラストラクチャチームにインフラのプロビジョニングを依頼します。クラウドでは、チームは自分自身で（セルフサービスで）自動化プロセスを通じてインフラをプロビジョニングします。これにより、開発者は自由になり、チケット処理を待つ代わりにビジネス価値を提供するための時間を増やすことができます。クラウド導入には集中的かつ組織的な取り組みが必要ですが、これを推進する Cloud Centre of Excellence (CCoE) が役立つ場合があります。この多種専門的なチームは、クラウドポリシー、ベストプラクティス、トレーニング、アーキテクチャを反復可能で自動化された、セルフサービス型の方法で提供することで、企業の成熟度を高めることができます。 セキュリティとコンプライアンスの文化 ：クラウド導入ではセキュリティとコンプライアンスに関する新たな考慮事項が生じます。組織はクラウド環境におけるデータ保護、プライバシー、および規制遵守を優先する必要があります。セキュリティとコンプライアンスに重点を置いた文化は、 責任共有 の意識を持つことで、セキュリティ対策がクラウド導入のあらゆる側面に統合されることを保証します。 ガバナンスの文化 ：クラウドサービスの利用を開始するのは容易になりましたが、企業のクラウド導入はより複雑になりました。適切なガバナンスがないと、クラウドの利用がすぐに制御を失う可能性があります。クラウドでは、インフラストラクチャの容量が「固定」から「無制限」に変わりますし、コストモデルも固定費から変動費（pay-as-you-go；従量課金）に変わります。これにより価値を提供するのに必要なアジリティは提供されるものの、シャドウ IT や経緯が不明のコストが発生することがあります。ここでクラウドガバナンスの文化が重要となります。ガバナンスの文化は、組織がクラウドの利用を管理し制御するために実施する一連のポリシー、手順、プロセスです。それはリアルタイムで自動化された「ガードレール」を通じてアジリティを維持しながら統制力を犠牲にすることなく実施されます。 おわりに 企業はそれぞれが複雑でユニークであり、文化が異なることもあります。組織文化は変革にとって重要であり、従業員のマインドセット、エンゲージメント、コラボレーション、変化への適応性、レジリエンスを形成します。変革の目標をサポートし、それに沿った文化を育むことで、組織は成功かつ持続可能な変革の実現可能性を高めることができます。Amazon のイノベーションへのアプローチは、文化からプロセス、テクノロジーに至るまでの一連の方法論、概念、ツールに基づいています。 参考情報 AWS CAF – Culture Evolution AWS Well-Architected Mental Models for Your Digital Transformation AWS Prescriptive Guidance – Accelerating cloud adoption through culture, change and leadership Learn from Amazon’s Approach to Innovation Leading and Innovating with Leadership Principles Elements of Amazon’s Day 1 Culture The Imperatives of Customer-Centric Innovation How to create a data-driven culture 本記事は、Nurani Parasuraman および Siraj Gadne による「 Maximize Cloud Adoption Benefits with a Well-Architected Organizational Culture 」を翻訳したものです。翻訳はカスタマーソリューションマネージャの山泉 亘が担当しました。 ＜原著執筆者について＞ Nurani Parasuraman AWS のカスタマーソリューションチームの一員です。彼は、人、プロセス、テクノロジー全体にわたる基本的な移行から大規模なクラウド変革への推進を通じて、企業が成功し、クラウド運用から大きなメリットを実現できるよう支援することに情熱を注いでいます。AWS に入社する前は、複数の上級管理職を歴任し、ファイナンスサービス、小売、通信、メディア、製造におけるテクノロジーの提供と変革を主導していました。彼は金融学の MBA と機械工学の理学士号を取得しています。 Siraj Gadne アマゾンウェブサービスのカスタマーソリューションチームのリーダーです。彼は真のビルダーであり、移行、モダナイゼーション、トランスフォーメーションを通じて顧客がクラウド運用のメリットを最大化できるよう支援することに情熱を注いでいます。Siraj は、25 年間のキャリアの中で、コンサルティングと企業の分野でいくつかの指導的地位を歴任してきました。AWS に入社する前、Siraj はザ・コカ・コーラ社、Merkle Inc.、キャップジェミニに勤務し、クラウド対応とデジタルトランスフォーメーションの分野で顧客にサービスを提供していました。

2023 年 7 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Personalize 基礎編 レコメンドを機械学習の専門知識無しで利用できる Amazon Personalize の使い方を紹介します 資料（ PDF ） | 動画（ YouTube ） 対象者 レコメンドの導入を検討されている方 本 BlackBelt で学習できること Amazon Personalize がなぜ必要なのかと基本的な使い方 スピーカー 近藤健二郎 ソリューションアーキテクト Amazon Neptune ではじめるグラフデータベース入門 近年注目を集めているグラフデータベースについて、 Amazon Neptune の便利機能や簡単なクエリの実行結果を交えながらご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースに関する基本的な知識を持っている方 データベースに関連する開発や運用経験を持っている方 グラフデータベースに興味を持っている方 Amazon Neptune に興味を持っている方 本 BlackBelt で学習できること グラフデータベースの概念やユースケース グラフデータベースのクエリ基礎知識 Amazon Neptune の概要 グラフデータベースの学習方法 スピーカー 木村達也 ソリューションアーキテクト DX の加速に向けた AWS クラウド導入フレームワーク (AWS CAF) の活用 AWS クラウド導入フレームワーク (AWS CAF) は、AWS の経験とベストプラクティスを活用しており、AWS の利用によるデジタルトランスフォーメーション (DX) とビジネスの成果の加速を促すフレームワークです。本セミナーでは、AWS CAF を活用していただくために、そのホワイトペーパーを読み解くための、コツやポイントを紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 DX 推進の施策を検討中の システム / DX 部門の方 クラウド活用を体系的に進めたい IT 担当者、または CCoE の方 オンプレミスとクラウドの考え方の違いを確認したいシステム部門の方 本 BlackBelt で学習できること AWS クラウド導入フレームワーク (AWS CAF) の読み解く方法を学習でき、クラウドを活用したデジタルフォーメーション（DX）の進め方を学ぶことができます。 スピーカー 釈迦郡一郎 カスタマーソリューションマネージャー モダナイゼーションプロジェクト立ち上げに向けたポイント ここ数年でモダナイゼーションという言葉が浸透し、実際に取り組まれている事例が増えています。一方で、抽象的なために全容が把握しずらい、検討したが関係者の共通認識がはかれないまま進めた結果頓挫してしまった、どこから手をつければいいか分からない、といった声も聞くようになってきました。本セッションでは、モダナイゼーションプロジェクトの立ち上げに向けて、事前に検討・考慮すべきポイントについてお話します。 資料（ PDF ） | 動画（ YouTube ） 対象者 モダナイゼーションに取り組むうえで、企画フェーズでの検討内容に関心があるリーダー、責任者の方 システムのモダナイゼーションに取り組もうとしているが、その対象選定や方針策定のポイントを確認したい方 本 BlackBelt で学習できること モダナイゼーションプロジェクト立ち上げ前に検討・考慮すべきポイント モダナイゼーションに取組む上での対象選定や方針策定の進め方 スピーカー 平岩梨果 ソリューションアーキテクト Modernize Enterprise Java Application エンタープライズにおける Java アプリケーションをモダナイゼーションするポイントやアプローチについて、AWS の各種サービスの組み合わせ方を紹介しながら理解を深めます。 資料（ PDF ） | 動画（ YouTube ） 対象者 Java アプリケーションのモダナイゼーションに関心のある、IT アーキテクトやソフトウェアエンジニア Java アプリケーションの維持運用に課題を感じている方 本 BlackBelt で学習できること エンタープライズの Java アプリケーションの構成要素や処理方式に対し、AWS の各種サービスを組み合わせることでどのようなモダナイゼーションが実現できるのか、どのようなメリットがあるのか、について理解を深めることができます。 スピーカー 倉元貴一 ソリューションアーキテクト AWS CDK 概要 (Basic #1) AWS Cloud Development Kit (AWS CDK) の概要から開発の流れまでをご紹介します。AWS CDK で Amazon VPC をデプロイするデモも含んでいます。 資料（ PDF ） | 動画（ YouTube ） 対象者 インフラ構築の手間や作業ミスにお悩みの方 インフラを含めたアプリ全体を素早くデプロイしたいエンジニア プログラミングの知識がある、あるいはこれから学ぶ方 本 BlackBelt で学習できること Infrastructure as Code の基礎から、AWS CDK のコンセプトや誕生ストーリー、開発の流れまでを概観できます。 スピーカー 高野賢司 ソリューションアーキテクト AWS CloudFormation#1 基礎編 AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、AWS およびサードパーティーのリソースをモデル化、プロビジョニング、管理することができます。 本セミナーは、AWS CloudFormation について解説するシリーズの初回である基礎編です。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CloudFormation をこれから学ぶ方、概要をお知りになりたい方 本 BlackBelt で学習できること AWS CloudFormation を扱う上で必要になる用語や、基本機能について解説しています。 AWS CloudFormation の基本的な使い方について学習いただけます。 スピーカー 福井敦 パートナーソリューションアーキテクト Amazon GameLift FlexMatch マルチプレイヤーゲーム用のマネージドなマッチメイキングサービス Amazon GameLift FlexMatch について網羅的に解説します 資料（ PDF ） | 動画（ YouTube ） 対象者 マッチメイキングの導入を検討されている方 現行のマッチメイキングの仕組みに課題を感じている方 本 BlackBelt で学習できること Amazon GameLift FlexMatch の抑えておきたい概念と仕組みについて網羅的に学習できます スピーカー 秋山周平 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-08 AWS Cloud Development Kit (CDK) 開発の基礎 ソリューションアーキテクト 高野 賢司 2023-08 AWS Control Tower 基本編 ソリューションアーキテクト 桂井俊朗 2023-08 AWS Control Tower 手順編 既存 Organizations での有効化 クラウドサポートエンジニア 大西朔 2023-08 Amazon CloudFront ( レポート / モニタリング / ロギング編 ) ソリューションアーキテクト 長谷川純也 2023-08 Amazon Personalize 応用編 ソリューションアーキテクト 近藤健二郎 2023-09 AWS Batch HPC スペシャリストソリューションアーキテクト 小林広志 2023-09 Amazon Managed Grafana ソリューションアーキテクト 大井友三 2023-09 Amazon Kinesis Video Streams 基礎編 ソリューションアーキテクト 宇佐美雅紀 2023-09 Amazon Kinesis Video Streams 応用編 IoT スペシャリストソリューションアーキテクト 三平悠磨 2023-09 AWS SimSpace Weaver コンセプト編 ソリューションアーキテクト 阿南麻里子 2023-09 Virtual Andon on AWS ソリューションアーキテクト 山田航司 2023-09 ミニチュア工場デモ : AWS IoT によるデータ集約と可視化 ソリューションアーキテクト 鈴木健吾 2023-09 AWS Key Management Service セキュリティソリューションアーキテクト 平賀敬博 2023-09 AWS Secrets Manager ソリューションアーキテクト 押川令 2023-09 Amazon GameLift FleetIQ ソリューションアーキテクト 安藤怜央  

デジタルの力で地域活性化を目指すデジタル田園都市国家構想に基づき、それぞれの地域の社会課題の解決や、その地域の強みや特色を活かしたデジタルトランスフォーメーション（DX）が加速しています。また2021年9月のデジタル庁発足後、ガバメントクラウドの導入が各自治体で本格的に進み始めています。一方でそれを推進すべきデジタル人材の不足は大きな課題です。 2006年に他社に先駆けてサービスを開始して以来、世界で最も包括的かつ幅広く採用されたクラウドサービスを提供するアマゾン ウェブ サービス（以下、AWS）は、クラウドサービスの提供にとどまらず、デジタル人材の育成支援にも取り組んでおり、最新のデジタルテクノロジーやグローバルの知見の提供などを通じて、地域経済活性化や地域創生に向けたDXの加速を支援しています。 アマゾン ウェブ サービス ジャパン合同会社（以下、AWSジャパン）では、全国の自治体や地域行政におけるイノベーションを支援し、より良い社会と市民生活の実現に貢献すべく、様々な自治体、関係団体との連携を図っています。2022年9月にはつくば市と研究開発型スタートアップの成長加速に向けた連携協定、また、同年同月に浜松市とデジタル・スマートシティ浜松の実現に向けた連携協定、2023年5月には新潟県と地域産業の活性化に向けた包括的な連携協定を締結しました。そしてこのたび、地域創生に向けた自治体におけるDXの加速を支援するため、AWSジャパンは2023年8月17日に北九州市と連携協定を締結しました。 アマゾン ウェブ サービス ジャパン合同会社 執行役員　パブリックセクター 統括本部長　宇佐見 潮は次のように述べています。「北九州市は『デジタルで快適・便利な幸せなまち』というミッションの実現を目指して、市の行政および地域産業全体でデジタルトランスフォーメーション（DX）に取り組まれています。また、同市は地域のポテンシャルや強みを生かした独自の戦略を打ち出し、“バックアップ首都構想”の実現や宇宙産業の推進に力を入れています。これらを支援する今回のイニシアチブは、デジタル田園都市国家構想が目指す地域創生の布石となることでしょう。北九州市との連携を通じて AWS のクラウドテクノロジーと多様な支援プログラムを提供し、北九州の目指すミッションに向けて伴走できることを心から嬉しく思います」   （写真左）AWSジャパン　執行役員 パブリックセクター統括本部長 宇佐見 潮／（写真右）北九州市 市長 武内 和久 北九州市は、「デジタルで快適・便利な幸せな街へ」のミッションのもと、DXを契機に必要な見直し・改善に取り組み、市民サービスの向上と業務の効率化を同時に実現することを推し進めています。 AWSジャパンは、北九州市の地域の特色や強みを活かしながら地域課題を解決するためのDXの推進に向けて、以下の4つの項目において、最新のクラウドテクノロジー、グローバルの知見・ネットワーク、デジタルスキル支援を通じて、北九州市のミッション実現を支援します。 1）“バックアップ首都構想 ”の実現に向けた支援 2）行政や地域のDX促進に向けた支援 3）スタートアップ育成に向けた支援 4）宇宙産業の推進に向けた支援 1. “バックアップ首都構想”実現に向けた支援 北九州市は、低災害リスクや、エネルギーや水の安定供給など、北九州市のポテンシャルを活かし、首都圏に集中する企業などが災害時にも業務を維持できるよう、バックアップ機能を誘致する“バックアップ首都構想”を掲げています。 この構想に基づく企業誘致には、北九州市におけるデジタル人材、特にクラウド人材が不可欠です。そこでAWSジャパンは在北九州市の企業と連携し、ハンズオンセッションを実施するなど、地域の企業にクラウドスキルトレーニングを提供し、デジタル人材の育成を支援します。 2. 行政や地域のDX促進に向けた支援 地域のイノベーションを推進するために、地域の産業やビジネスのイノベーション、DXを支える北九州市の職員がクラウドについて理解を深めていただくことが重要です。AWSのパートナー企業が実施するクラウド人材育成プログラムを市の職員に提供し、職員のデジタルスキルの向上をサポートしていきます。 また、地域のデジタル人材の層を厚くし、北九州市全体のイノベーションを促進・支援するために、地域の高等教育機関などと連携し、クラウド学習プログラムであるAWS Academy を活用した学生のクラウドスキルトレーニングや将来のデジタル人材育成を行います。 AWS Academyを通じて、教材や実習環境だけではなく、講師の登壇までのトレーニングも含むパッケージ化されたプログラムを高等教育機関向けに提供し、学生たちが将来、業界で認知されている認定資格を取得し、需要の高いクラウド関連の仕事に就けるように支援します。 3. スタートアップ育成に向けた支援 AWSでは、クラウドをはじめとしたデジタルテクノロジーを社会実装するうえで、スタートアップが欠かせないと考えています。それにより、過去10年にわたり数千におよぶ日本のスタートアップを支援してきました。北九州市との連携においてもそのノウハウを共有し、北九州市のスタートアップのすそ野をより一層拡大していきます。 まず、「COMPASS小倉」等の市内コワーキングスペースを利用する企業に対し、AWSのクレジットを利用できる AWS Activate などの支援プログラムを提供します。AWS Activateとは、スタートアップが自身のビジネスの立ち上げや拡大に向けてAWSを速やかに運用開始するために必要なリソースを包括的に提供するスタートアップ支援プログラムです。 4. 宇宙産業の推進に向けた支援 北九州市は市の成長戦略の一つとして宇宙産業に力を入れており、宇宙ビッグデータの利活用などを進めていく方針を打ち出しています。AWSは2020年に航空宇宙・衛星産業におけるイノベーションの加速に特化したチームを立ち上げ、官民のお客様の宇宙関連のビジネスをサポートしています。 今後、AWSの宇宙産業に関する知見や企業間のネットワークを北九州市と共有することで、市の宇宙産業推進のステージに合わせた連携を図っていきます。また、宇宙に関するアイデアコンテストやハッカソン等の共同開催も予定していきます。 AWSは、デジタル技術を活用して地域創生や社会課題解決に取り組む自治体や地域産業、スタートアップを、AWSの最新のテクノロジーやサービスなどの提供を通じて支援します。それにより市民や住民のより良い豊かな市民の暮らしに貢献することを、様々なステークホルダーと共に目指していきます。

2021 年 11 月、最高 3.6 GHz の周波数で動作する第 3 世代 AMD EPYC (Milan) プロセッサを搭載した Amazon EC2 M6a インスタンスがリリース されました。これにより、M5a インスタンスに比べてコストパフォーマンスが最大 35% 向上します。SAP など、x86 命令に依存するワークロードを実行する 多くのお客様 は、クラウドの利用を最適化する方法を模索しています。これらのお客様は、EC2 が提供するコンピューティングオプションを活用しています。 8月15日、最大周波数 3.7 GHz の第 4 世代 AMD EPYC (Genoa) プロセッサを搭載した新しい汎用 Amazon EC2 M7a インスタンスの一般提供をお知らせします。このインスタンスでは、M6a インスタンスと比べてパフォーマンスが最大 50% 向上しています。このパフォーマンスの向上により、データ処理の高速化、ワークロードの統合、保有コストの削減が実現します。 M7a インスタンスは、 AVX-512、Vector Neural Network Instructions (VNNI) 、および bfloat16 (Brain Floating Point 16) をサポートします。これらのインスタンスには、データインメモリへの高速アクセスが可能な Double Data Rate 5 (DDR5) メモリが搭載されていて、M6a インスタンスに比べて 2.25 倍のメモリ帯域幅を提供するので、レイテンシーを低く抑えることができます。 SAP 認定の M7a インスタンスは、金融アプリケーション、アプリケーションサーバー、シミュレーションモデリング、ゲーム、中規模データストア、アプリケーション開発環境、キャッシングフリートなど、高パフォーマンスと高スループットのメリットを活用するアプリケーションに理想的です。 M7a インスタンスでは、768 GiB の RAM で最大 192 の vCPU を使用できます。詳細な仕様は次のとおりです。 名前 vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) m7a.medium 1 4 最大 12.5 最大 10 m7a.large 2 8 最大 12.5 最大 10 m7a.xlarge 4 16 最大 12.5 最大 10 m7a.2xlarge 8 32 最大 12.5 最大 10 m7a.4xlarge 16 64 最大 12.5 最大 10 m7a.8xlarge 32 128 12.5 10 m7a.12xlarge 48 192 18.75 15 m7a.16xlarge 64 256 25 20 m7a.24xlarge 96 384 37.5 30 m7a.32xlarge 128 512 50 40 m7a.48xlarge 192 768 50 40 m7a.metal-48xl 192 768 50 40 M7a インスタンスには最大 50 Gbps の拡張ネットワーキングと 40 Gbps の EBS 帯域幅があり、これは M6a インスタンスと同様です。ただし、1 つの vCPU、4 GiB を提供する新しいミディアムインスタンスサイズでは、ワークロードのサイズをより正確に調整できます。最大サイズは 192 の vCPU、768 GiB です。 新しいインスタンスは、従来の仮想化機能の多くを専用ハードウェアにオフロードするビルディングブロック技術の集合体である AWS Nitro System をベースに構築されており、高性能、高可用性、高セキュリティのクラウドインスタンスが実現しています。 今すぐご利用いただけます 8月15日、Amazon EC2 M7a インスタンスは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) の AWS リージョンで利用できるようになりました。Amazon EC2 でいつも支払うのと同じように、使用した分の料金のみをお支払いいただきます。詳細については、 Amazon EC2 の料金ページ を参照してください。 詳細については、 EC2 M7a インスタンス と AWS/AMD パートナーページ を参照してください。 ec2-amd-customer-feedback@amazon.com 、 AWS re:Post for EC2 、または通常の AWS サポートの担当者を通じて、ぜひフィードバックをお寄せください。 — Channy 原文は こちら です。

夏を満喫するためにカリフォルニアで数日を過ごしている間に AWS では多くのことが起こりました。一緒に見ていきましょう！ 8月7日週のリリース 私が注目したリリースを以下に記載しました。 Amazon MWAA での Apache Airflow バージョン 2.6 のサポート – Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は エンドツーエンドのデータパイプラインをクラウドでセットアップして運用するために使用できる Apache Airflow 用のマネージドオーケストレーションサービスです。Apache Airflow バージョン 2.6 では、ワークフローのセキュリティと信頼性を強化する重要なセキュリティ更新とバグ修正が導入されています。現在 Apache Airflow バージョン 2.x を実行している場合は、バージョン 2.6.3 にシームレスにアップグレードできるようになりました。 この AWS ビッグデータブログの投稿 をご覧ください。 Amazon EMR Studio が AWS Lake Formation のきめ細かいアクセスコントロールのサポートを追加 – Amazon EMR Studio は、 Amazon EMR クラスター上で実行するフルマネージド型の Jupyter Notebook 用のウェブベースの統合開発環境 (IDE) です。EMR Studio ワークスペースから EMR クラスターに接続する際、接続する AWS Identity and Access Management (IAM) ロールを選択できるようになりました。Apache Spark インタラクティブノートブックは、このランタイム IAM ロールにアタッチされたポリシーで許可されているデータとリソースにのみアクセスします。 AWS Lake Formation で管理されているデータレイクからデータにアクセスする場合、このランタイムロールにアタッチされたポリシーを使用して、テーブルレベルと列レベルのアクセスを強制できます。詳細については、 Amazon EMR のドキュメント をご覧ください。 AWS Security Hub が 12 の新しいセキュリティコントロールをローンチ – AWS Security Hub は、セキュリティのベストプラクティスチェックを実行し、アラートの集約と自動修復の有効化を行う Cloud Security Posture Management (CSPM) サービスです。新たにリリースされたコントロールにより、Security Hub は Amazon Athena 、 Amazon DocumentDB (MongoDB 互換)、 Amazon Neptune という 3 つの AWS のサービスをサポートするようになりました。Security Hub では、 Amazon Relational Database Service (Amazon RDS) に対するコントロールも追加されています。AWS Security Hub では、現在、276 のコントロールが提供されています。詳細については、 AWS Security Hub のドキュメント を参照してください。 AWS イスラエル (テルアビブ) リージョンで利用可能になった AWS のサービス – AWS イスラエル (テルアビブ) リージョンが 2023 年 8 月 1 日にオープンしました 。8月7日週、イスラエル (テルアビブ) リージョンで利用可能なサービスのリストに、 AWS Service Catalog 、 Amazon SageMaker 、 Amazon EFS 、 Amazon Kinesis Data Analytics が追加されました。可用性に関する最新情報については、 AWS リージョン別のサービス表 を確認してください。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS のニュース 興味深いと思われるその他のブログ投稿とニュース項目をいくつかご紹介いたします。 2023 Gartner Magic Quadrant において AWS が Amazon Connect で Contact Center as a Service のリーダーに認定 – 柔軟な AI 搭載のクラウドコンタクトセンターである Amazon Connect が 2017 年にローンチされて以来、AWS は初のリーダーに選出されました。 全文を読む。 生成系 AI を使用したクリエイティブな広告生成 – この AWS Machine Learning ブログ投稿 では、生成系 AI を使用して魅力的で革新的な広告を大規模に生成する方法を示しています。Inpainting の手法に加えて、画像の背景、視覚的に魅力的なコンテンツをシームレスに作成する方法、そして不要な画像アーティファクトを削減する方法について説明します。 AWS オープンソースニュースと更新情報 – 私の同僚の Ricardo が 週刊のオープンソースニュースレター を執筆し、AWS コミュニティの新しいオープンソースプロジェクト、ツール、デモを紹介しています。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 生成系 AI 上での構築 – 生成系 AI のすべてを網羅した 週刊 Twitch ショー のシーズン 2 が始まりました。 毎週月曜日 9:00 (米国太平洋標準時) に同僚の Emily と Darko が AWS の新しい技術的および科学的パターンについて考察し、ゲストスピーカーを招いてその作業のデモを行い、生成系 AI の状態を改善するために構築されたものを紹介します。 本日のエピソードでは、Emily と Darko が最新モデルの LLAMA-2 と Falcon について話し、Retrieval-Augmented Generation のデザインパターンで探求します。 ビデオはこちらからご覧いただけます 。 ショーのノートとエピソードの完全なリストについては、community.aws をチェックしてください 。 AWS NLP カンファレンス 2023 – 9 月 13 日から 14 日にロンドンで開催 されるこの対面式イベントで AWS の自然言語処理 (NLP) 機能を活用する最新のトレンド、画期的な研究、革新的なアプリケーションの詳細を確認してください。今年のカンファレンスでは、多くの生成系 AI アプリケーションやユースケースのバックボーンを形成する大規模言語モデル (LLM) に主な焦点を当てます。 こちらからご登録 いただけます。 AWS グローバルサミット – 2023 年の AWS Summit シーズンを締めくくるのは、 メキシコシティ (8 月 30 日) とヨハネスブルグ (9 月 26 日) の 2 回の対面イベントです。 AWS Community Day – AWS ユーザーグループリーダーが主催し、お住まいの地域のコミュニティが主導するカンファレンスにご参加ください。 西アフリカ (8 月 19 日)、 台湾 (8 月 26 日)、 ニュージーランド (9 月 6 日)、 レバノン (9 月 9 日)、 ミュンヘン (9 月 14 日) で開催されます。 AWS re:Invent (11 月 27 日～12 月 1 日) – ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 登録が開始されました 。 近日開催予定の実地イベントやバーチャルイベントをすべてご覧いただけます。 8月14日週はここまでです。8月21日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 —  Antje P.S.私たちは、より良いカスタマーエクスペリエンスを提供するためにコンテンツの改善に注力しており、そのためにはお客様からのフィードバックが必要です。 この短いアンケート にご回答いただき、AWS ブログに関するご感想をお聞かせください。なお、このアンケートは外部企業によって実施されているため、リンク先は当社のウェブサイトではありません。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。 原文は こちら です。

この記事では、 Amazon Neptune Serverless の一般的なユースケースと、推奨されるベストプラクティスに従ってコストとパフォーマンスの両方を最適化する方法を紹介します。 Amazon Neptune は、グラフ・アプリケーションの構築と実行を容易にする、クラウド向けに最適化されたフルマネージド・データベース・サービスです。 RDF と プロパティグラフ 両方のグラフ・データモデルをサポートしています。データベース管理を簡素化し、新規アプリケーションの構築や既存アプリケーションの移行を迅速に行うことができます。高価なライセンス料からの脱却を目指す組織は、Neptuneに移行することで、最新のオープンソース・イノベーションの恩恵を受けることができます。求められる要件に対してカスタマイズできるよう、 高可用性や耐久性 など幅広い機能を提供します。 Neptune Serverless は、オンデマンドの自動スケーリング構成で、必要に応じてNeptuneクラスタをスケールするようにデザインされています。Neptune Serverlessでは、 いくつかの制限 はありますが、プロビジョニングされたインスタンスと同じ機能を使用できます。費用対効果が高く、データベースの容量を管理・最適化することなく、グラフのワークロードを実行し、迅速にスケーリングすることができます。Neptune Serverlessインスタンスでは、次のようなメリットがあります。 迅速かつ無停止のキャパシティ・スケーリング きめ細かく予測可能なキャパシティ調整 高可用性、ディザスタリカバリ、拡張機能 すでにNeptuneを使用している場合、アプリケーションを変更することなく簡単に移行することが可能 Neptune Serverlessクラスタのスケーリング構成は Neptune Capacity Unit （NCU）で定義され、NCUはそれぞれ2 GBのメモリと、関連する仮想プロセッサ（vCPU）およびネットワーク容量で構成されます。サポートされる NCU の最小値は 1.0 で、最大値は 128 です。NCU 構成は 0.5 NCU 単位で調整できます。Neptune Serverlessはコンピュートリソースのみスケールすることにご注意ください。 ストレージの上限 は変わらず、サーバーレスのスケーリングの影響を受けません。 Neptune Serverlessの一般的な使用例 Neptune Serverlessは、非定常的かつ突発的なトラフィックを伴うワークロードに最適です。定常的で予測可能なトラフィックを持つワークロードに使用することはお勧めしません。その理由は、定常的なワークロードの場合、プロビジョニングされたインスタンスの方がコスト効率が良いからです。たとえば、プロビジョニングされた db.r5.xlarge インスタンスを選択する方が、NCU=16 最小値=最大値に設定して 、NCU=16 のままのサーバーレスインスタンスよりも費用対効果が高くなります。 以下は、サーバーレスがデータの分離や費用対効果などの利点を提供できる、その他の使用例です。 Neptuneの新規利用あるいは新規アプリケーションに対するリソースの最適化 Neptuneを初めて利用するお客様にとって、グラフデータのワークロードに必要なインフラストラクチャを決定することが困難な場合があります。お客様のワークロードに 最適なインスタンスサイズを推定する方法 を提供していますが、クエリのレイテンシや予想されるトラフィックなどの追加情報が必要であり、初期段階では明らかにできないケースが多くあります。そのため、新規でNeptuneを利用するお客様や新規アプリケーションにとっては、キャパシティ要件を決定することが難しくなります。代わりに、コンピュートリソースの計算を気にせずにNeptune Serverlessを開始し、それまでのリソース消費量を確認することで要件を満たすプロビジョニング・インスタンス・サイズを特定することができます。また、アプリケーションの書き込み/読み込みが多かったり、トラフィックにばらつきがあることに気づいたら、 サーバーレスインスタンスとプロビジョニングインスタンス を1つのクラスタで組み合わせることもできます。 開発環境とテスト環境 多くのお客様は、本番環境ではない開発環境とテスト環境でコストを削減する新しい方法を模索しています。開発チームやテストチームが大規模なインスタンスをデプロイし、その停止や削除を忘れてしまうことは、多くのお客様にとって懸念事項です。しかし、開発チームやテストチームは、大規模な負荷テストを実行できるインスタンスをデプロイしなければいけません。サーバーレスは両方の長所を提供することができます。つまり、稼働していない期間中のコストを削減するために最小NCU数が少ないサーバーレスインスタンスをデプロイすることができ、開発チームやテストチームが高稼働期間中に迅速にスケーリングできるように最大NCU数が多いサーバーレスインスタンスをデプロイすることができます。 テナントごとのデータベースを備えたマルチテナント・アプリケーション 何千人ものエンドユーザーにサービスを提供する SaaS (Software as a Service) アプリケーションのようなプラットフォームでは、現在または予想される需要に基づいて Neptune クラスタを過剰または過小にプロビジョニングすることがよくあります。また、個々の顧客データを分離する必要がある場合、データの分離要件に直面することもあります。Neptune Serverlessを使用すると、個々のNeptuneクラスタを提供することで各顧客のデータを物理的に分離できるだけでなく、Neptune Serverlessの自動スケーリング機能を使用して、基盤となるインフラストラクチャを積極的に管理する必要がなくなり、各テナントデータベースを独立してスケーリングできます。 データベースに支えられたいくつかのアプリケーション 今日の最新のアプリケーション・アーキテクチャでは、何百、何千ものカスタム・アプリケーションが存在し、それぞれが1つ以上のデータベースによって成り立っています。アプリケーションの要件が進化するにつれて、それらをサポートし続けるためのデータベース容量も追随しなければなりません。費用対効果の高い方法でデータベース・フリートの容量調整を管理することは、困難かつ労力を要します。サーバーレスは、アプリケーションと関連するキャパシティ要件が進化するにつれて、データベース・キャパシティの管理負担を軽減するのに役立ちます。 効率的な水平および垂直スケーリング スケーラビリティを必要とするアプリケーションは、より高いスループットを得るために、データベースを複数のインスタンスに分割することがお勧めです。各インスタンスの容量を予測するのは困難で非効率的です。なぜなら、予想されるリクエスト数と各クエリのレイテンシに関する複雑な情報や経験が必要だからです。インスタンスの数が少なすぎると、データを再配置しなければならず、ダウンタイムが発生します。インスタンスの数が多すぎると、すべてのインスタンスが均等に利用されないため、高いコストを支払うことになります。サーバーレスインスタンスを使用することで、初期コストをあまり追加することなく、アプリケーションを複数のインスタンスにシャードすることができ、シャードされたデータベースはそれぞれ、必要なときに必要な容量を垂直方向に拡張することができます。過少利用や過剰なプロビジョニング、不要なコストの支払いは必要ありません。 Global DatabaseとNeptune Serverlessによるディザスタリカバリ Neptune Global Database は、プライマリーインスタンスと最大 5 つのセカンダリーリージョン間でグラフデータをレプリケートする機能を提供します。これにより、リージョン全体が停止した場合のディザスタリカバリの機能を提供します。しかし現実には、リージョン全体で障害が発生する可能性は低いため、セカンダリーリージョンにプロビジョニングされたNeptuneインスタンスは十分に活用されないケースもあります。セカンダリーリージョンでプロビジョニングされたインスタンスの代わりにサーバーレスインスタンスを使用することで、NCUの最小値を許容可能な最小値に設定することで、積極的に使用されていない間のコストを節約することができます。また、必要に応じて、クラスタ構成を更新することでNCU値を増やし、新しい需要に合わせて自動的にスケールさせることもできます。 Neptune Serverlessのベストプラクティス このセクションでは、Neptune Serverlessを使用する際のベストプラクティスを紹介します。 ワークロードと機能に最適な最小および最大NCUの構成 次のことを検討します。 一括ロードを使用するワークロード – バルクロードのようなリソース集約型のワークロードには、Neptune Serverlessを適切に構成することをお勧めします。最大 NCU は、希望するレートでデータを取り込むことができるレベルに設定する必要があります。たとえば、バルクロード操作時に 128 NCU に設定すると、Neptune は一括ロードに必要なリソースを確保できます。正確な最大 NCU は、取り込むデータ量と希望するデータ取り込みレートに依存します。また、NCU 最小値=最大値 とする構成は、スケーリングが容易にならないため、この種のユースケースではアンチパターンです。この場合、同じようなサイズ（メモリ・サイズとvCPU数）のプロビジョニングされたNeptuneインスタンスの方が良い選択かもしれません。 サーバーレスリーダーインスタンスを大規模なプロビジョニングされたプライマリーインスタンスと組み合わせて使用する場合、書き込みの数に追いつけず、共有ストレージからの読み込みを再起動するような状況が発生します。この場合、プライマリーからのレプリケーショントラフィックを満たすためにサーバーレスリーダーインスタンスの最小NCU構成を1NCU以上の値にスケールアップするか、一括ロード操作中に一時的に削除する必要があります。詳細については、 一括ロード中に再起動を繰り返さないようにする を参照してください。 IAMデータベース認証が有効になっているNeptuneクラスタ – AWS Identity and Access Management (IAM)データベース認証 が有効になっているNeptuneクラスタでは、エラーを回避するために最低でも2以上の最小NCU値が必要です。 トラフィックが急増するワークロードをサーバーレスインスタンスに切り替える 需要が急増し、一貫性のないワークロードに対しては、サーバーレスインスタンスを使用することで、Neptuneクラスタに関連するコンピュートリソースを垂直方向にスケールする自動化されたコスト効率の高いメカニズムが提供されます。しかし、トラフィックが一貫しているワークロードでは、サーバーレスインスタンスを使用すると、同じ容量のプロビジョニングされたインスタンスを使用する場合と比較してコスト効率が悪くなります。また、サーバーレスクラスターでNCU 最小値=最大値を設定することは、推奨されるパターンに反しています。要件によっては、プロビジョニングされたインスタンスの方がコスト効率とパフォーマンスが高く、ニーズを満たせるかもしれません。 最小容量を増やし、より高速なスケーリングを可能にする Neptune Serverlessは、最小NCUの設定値に基づく速度でスケールします。最小NCUが1.0に設定されている場合、サーバーレスクラスターが重いトラフィックに対応する容量を提供するためにスケールアップするのに時間がかかります。これは、Neptune Serverlessが 現在使用されているサーバーレス容量に基づいてスケーリング増分を選択 するためです。これを高い値に設定することで、特にデータベースへの需要が増加することが分かっているイベントの前に、Neptune Serverless はより高いスケーリング率を使用し、需要に対応するためにより速くスケールアップします。 リーダーインスタンスの正しい昇格階層を設定する Neptune Serverlessリーダーインスタンスが最小NCUまでスケールダウンせず、プライマリーインスタンスと同じかそれ以上の容量にとどまっている場合は、リーダーインスタンスの昇格階層を確認してください。Tier 0または1では、サーバーレスリーダーインスタンスはライターインスタンスと同じ容量に維持されます。リーダーの昇格階層を2以上に変更することで、ライターから独立してスケールアップあるいはスケールダウンするようになります。詳細については、 Neptune Serverlessインスタンスの昇格階層 の設定を参照してください。 Neptune Serverlessと自動スケーリングの組み合わせ Neptuneリードレプリカ自動スケーリング を使用して、接続要件とワークロードに基づいてNeptuneクラスタ内のレプリカ数を自動的に調整できます。また、Neptune Serverless を使用して、アプリケーションからの突然のトラフィック急増にも対応することができます。CPU使用率ベースの自動スケーリングを使用する場合、最小値と最大値の両方のNCUを低く設定したり、最小値と最大値のNCUの範囲を狭く実装したりすると、Neptuneリードレプリカの追加と削除が急激に行われることがあります。 クエリのタイムアウトを正しく設定し、クエリがバックグラウンドで実行され、コストがかかるのを防ぐ プロビジョンドインスタンスと比較して、長時間稼働するワークロードに対してNeptune Serverlessを実行するコストは高くなるため、特定の要件に対応できるように クエリタイムアウトパラメータ(neptune_query_timeout) を調整することをお勧めします。短時間のクエリのみが予想される場合は、クエリタイムアウトを短く設定します。これは、バックグラウンドで実行されている予期せぬ長時間実行クエリによって不要なコストが発生するのを避けるためです。 サーバーレスインスタンスを監視してコストと最適化を図る サーバーレスクラスターやインスタンスを監視するために、 サーバーレスインスタンス用のAmazon CloudWatchメトリクス が2つ追加されています。 ServerlessDatabaseCapacity – (インスタンスレベルの) 現在のインスタンス容量、または (クラスタレベルの) 全インスタンスの全値の平均を提供する NCUUtilization – ServerlessDatabaseCapacity を NCU の最大値で割って、使用可能な容量の割合をレポートする もし NCUUtilization メトリックが100%に近づいている場合は、サーバーレスインスタンス全体でNCUの最大値を増やすことを検討してください。 Neptune Serverlessの価格 サーバーレスインスタンスをデプロイする際、価格設定などはプロビジョニングインスタンスと同じ要素が適用されます。 ストレージはGB/月で請求 消費されたI/Oオペレーション バックアップ・ストレージ データ転送料金 Global Database やスナップショットエクスポートなどの特別機能の料金 サーバーレスインスタンスの課金の主な違いは、 1時間あたりのNCUでの使用量 に基づいて価格が設定されることです。実際のコストは、Neptuneクラスタがデプロイされたリージョンによって異なります。 Neptune Serverlessの価格比較 以下は、サーバーレスインスタンスと db.r6g.8xlarge プロビジョニングインスタンスを使用した場合の、30日間にわたるスパイク上のトラフィックと一貫したトラフィックを持つワークロードのコスト比較です。どちらの見積もりにも以下の構成が含まれています。 リージョンは us-east-1 50GBのデータと100GBのバックアップ 月間2億回のI/Oオペレーション 月間50GBのデータ転送 月間10GBのデータ転送 次の表は、トラフィックが急増しているワークロードの例を比較したものです。最大 NCU (128) で 1 日あたり 1 時間、最小 NCU (1) で 1 日あたり 23 時間です。 Serverless Provisioned (db.r6g.8xlarge) Instance charges $728.42 $3,804.62 Storage charges $7.10 $7.10 I/O charges $40.00 $40.00 Data transfer charges $0.00 $0.00 Total charges $775.52 $3,851.72 サーバーレスを使用した場合、プロビジョニングされたインスタンスと比較して、スパイク特性の高いワークロードにかかるコストの差は、月額 3,076.20ドル の節約となりました。 次の表は、最大NCU（128）で1日あたり23時間、最小NCU（1）で1日あたり1時間、一貫したトラフィックのワークロードの例を比較したものです。 Serverless Provisioned (db.r6g.8xlarge) Instance charges $14,206.80 $3,804.62 Storage charges $7.10 $7.10 I/O charges $40.00 $40.00 Data transfer charges $0.00 $0.00 Total charges $14,253.90 $3,851.72 一貫したワークロードに対してプロビジョニングされたインスタンスとサーバーレスを使用した場合のコストの差は、月額 10,402.18ドル の増加となりました。 Neptune Serverlessの制約 Neptune Serverlessは垂直スケーラビリティとコスト効率を迅速に提供できますが、その制約を理解することが重要です。 サーバーレスは すべての地域で利用できるわけではない （訳注:東京リージョンではご利用可能です） エンジンリリース1.2.0.1 以降で使用可能 Neptuneの ルックアップキャッシュ とは互換性がない サーバーレスインスタンスの最大メモリは256GB（最大NCUは128） 詳細は Amazon Neptune Serverless constraints を参照してください。 まとめ この投稿では、Neptune Serverlessの一般的なユースケースとベストプラクティスについて説明しました。様々なトラフィックやデータ分離を必要とするワークロードに対してプロビジョニングされたインスタンスよりもサーバーレスインスタンスを使用したり、本番環境ではない開発環境やテスト環境などで高い費用対効果を得たりすることでメリットを得ることができます。さらに、同じNeptuneクラスタ内でサーバーレスインスタンスと従来のプロビジョニングされたインスタンスを組み合わせることで、最も負荷の高いワークロードに対して柔軟性とスケーラビリティを提供する方法についても説明しました。 Neptune Serverlessを始めるには、 Neptuneコンソール にアクセスするか、 Amazon Neptune Serverless を参照して詳細を確認してください。 著者について Kevin Phillips は、Amazon Web Servicesの英国で働くNeptuneスペシャリスト・ソリューション・アーキテクトです。18年にわたる開発とソリューション・アーキテクチャの経験を生かし、顧客のサポートと指導にあたっています。 Ankit Gupta は、インドの Amazon Neptune Platform チームのソフトウェア開発マネージャーで、製品立ち上げ当初から Neptune チームの一員です。AWSの顧客や社内の開発チームと協力し、Neptuneのユーザビリティ、パフォーマンス、スケーラビリティ、ユーザーエクスペリエンスの向上に取り組んでいます。 本記事は 2023/06/28に投稿された Use cases and best practices to optimize cost and performance with Amazon Neptune Serverless を翻訳した記事です。翻訳はソリューションアーキテクトの木村 達也が行いました。

AWS AppSync は、アプリケーションがデータに接続するためのスケーラブルな API を簡単に構築できるマネージドサービスです。AppSync を使用することで、 Amazon DynamoDB に接続する API で Web アプリケーションを強化する場合や、ユーザーにイベントの ライブアップデートを提供する リアルタイムダッシュボードを構築する場合に、アプリケーションを需要に合わせてシームレスに拡張することができます。昨年、AppSync は AppSync パイプラインリゾルバと AppSync 関数で JavaScript のサポートを開始しました。これにより、お客様はリゾルバを JavaScript で記述し、AppSync の JavaScript ランタイム上で実行してクエリを解決できるようになりました。また、JavaScript リゾルバにより、お客様は一般的な変換や翻訳操作のために追加の計算リソースを使うことなく、リゾルバでより多くのことを行えるようになりました。 AppSync は JavaScript のサポートをユニットリゾルバに拡張しました。開発者は、単一のリゾルバで JavaScript の単一データソースアクセスパターンを扱えるようになりました。開発者は、複雑なアクセスパターンを処理したり、 パイプラインリゾルバで JavaScript 関数と Velocity Template Language (VTL) 関数を混在させたりすることができます。本記事では、独自の API で JavaScript リゾルバを使用する方法について説明します。 はじめに AWS AppSync コンソールで JavaScript リゾルバを始めることができます。コンソールで “Create API” を選択し、”design from scratch” を選択します。API に名前を付け、ステップ 2 で “Create type backed by a DynamoDB table now” を選択します。ここでコンソールは、新しい GraphQL 型とオペレーションの作成をサポートしてくれます。型を持つ DynamoDB テーブルを作成します。 id 、 owner 、 name 、 severity 、 dueOn のフィールドを持つ Todo 型を作成してみましょう。コンソールで、リゾルバに AppSync JavaScript ランタイムを事前に選択します。 DynamoDB テーブルで構築されたデータモデルを構成します。 次に、データを格納するテーブルを設定します。テーブル名を “todos” とし、プライマリキーを id 、ソートキーを owner に設定します。 owner で Todo を取得するためのインデックスを追加します。インデックス名を “owner-dueon-index” とし、主キーを owner 、ソートキーを dueOn とします。 “Next” をクリックし、オプションを確認して API を作成します。API が作成され、リゾルバが自動的に生成されます。スキーマページから、生成されたリゾルバを 1 つ選択するか、任意のフィールドに新しいリゾルバをアタッチすることができます。 id を与えなくても Todo が作成できるようににスキーマを変更してみましょう。 CreateTodoInput を以下のように更新します。 input CreateTodoInput { id: String owner: String! name: String severity: Int dueOn: AWSDate } 次に、”Resolvers” の画面で、 createTodo フィールドを見つけ、そのリゾルバをクリックします。編集するコードは 1 行だけです。以下のように修正を行います。 修正前 const { id, owner, ...values } = ctx.args.input; 修正後 const { id = util.autoId(), owner, ...values } = ctx.args.input; この単純な変更では、AppSync ユーティリティの autoId を使用して、一意な ID が提供されていない場合に新しい一意な ID を生成します。”Queries” の画面から、Query や Mutation の送信や、Subscription の設定ができます。 例えば、以下のように Todo を作成することができます。 mutation create { createTodo(input: {name: "first todo", owner: "brice", severity: 10, dueOn: "2023-08-10"}) { dueOn id name owner severity } } 次に、 owner を使用して作成した Todo を取得することができます。 query byOwner { queryTodosByOwnerDueonIndex(owner: "brice") { items { id name owner } } } どのスキーマフィールドにもリゾルバをアタッチすることができます。リゾルバをアタッチするには、リゾルバの型、ランタイム、データソースを選択します。 リゾルバが作成されると、いくつかのサンプルコードから選択して、独自のリゾルバを書き始めることができます。 AWS CDK の使用 AWS CDK プロジェクトでは JavaScript リゾルバを使用できます。ローカルで作業する場合は、TypeScript、AppSyncユーティリティライブラリや型、AWS Amplify codegen を活用してコーディング体験を向上させることができます。CDK プロジェクトで TypeScript を使い始めるには、AppSync リゾルバサンプルリポジトリの Todo API CDK サンプルを利用できます。この例では、ファイル名に基づいてリゾルバをデータソースに自動的にリンクするローカルのヘルパーコンストラクトを使用しています。まずリポジトリをローカルにクローンし、依存関係をインストールします。 $ git clone https://github.com/aws-samples/aws-appsync-resolver-samples.git $ cd aws-appsync-resolver-samples $ cd examples/cdk/constructs/appsync-helper $ npm run init $ cd ../../dynamodb-todo-app $ npm install アプリのリゾルバは lib/appsync/resolvers にあります。 Mutation.createTodo.[todos].ts を見てください。 ./lib/appsync/codegen にある自動生成コードの型を使用しています。codegen の型は、 ./lib/appsync/schema.graphql にあるスキーマファイルから自動生成されます。codegen を生成するには、以下を実行します。 $ npm run codegen (このコマンドは amplify codegen を呼び出します。) これで、コード内で型を使用できるようになります。スキーマが変更された場合はいつでも codegen を再実行し、型を更新することができます。これは Mutation.createTodo のリゾルバです。 import { util, Context } from '@aws-appsync/utils'; import { CreateTodoMutationVariables } from '../codegen'; import { dynamodbPutRequest } from './utils'; export { checkErrorsAndRespond as response } from './utils'; export function request(ctx: Context<CreateTodoMutationVariables>) { const { input: values } = ctx.arguments; const key = { id: util.autoId() }; const condition = { id: { attributeExists: false } }; console.log('--> create todo with requested values: ', values); return dynamodbPutRequest({ key, values, condition }); } このリゾルバは、DynamoDB の PutItem リクエストを作成するためにヘルパー関数 dynamodbPutRequest を使用します。また、レスポンス処理には、レスポンスとしてエクスポートするヘルパー関数 checkErrorsAndRespond を使用します。これはよくあるパターンなので、すべてのリゾルバに書くのではなく、プロジェクトのユーティリティのリストに追加します。 /** * Checks for errors and returns the `result */ export function checkErrorsAndRespond(ctx: Context) { if (ctx.error) { util.error(ctx.error.message, ctx.error.type); } return ctx.result; } リゾルバをローカルで操作する際には、TypeScript、インポート、エクスポート、外部ユーティリティを使用できます。リゾルバを保存する前にコードをバンドルするだけです。バンドルの詳細については、AppSync の ドキュメント をご参照ください。このプロジェクトでは、リゾルバを自動的にバンドルし、データソースにアタッチしてくれます。詳細については、 ヘルパーコンストラクト をご参照ください。 変更をデプロイする準備ができたら、以下を実行してください。 $ npm run cdk deploy プロジェクトが終了したら、リソースを削除することができます。 $ npm run cdk destroy リゾルバのコードサンプルだけでなく、その他のサンプルも リポジトリ にあります。 まとめ 本記事では、ユニットリゾルバで JavaScript が新たにサポートされたことについて説明しました。コンソールから簡単に始める方法を説明し、CDK プロジェクトのユニットリゾルバで TypeScript などの機能をどのように使用できるかを見ました。これで、すべてのリゾルバと関数で AppSync JavaScript ランタイム を利用できるようになり、データアクセスのすべてのユースケースを使い慣れた方法で簡単に扱えます。まだ JavaScript リゾルバを試したことがないのであれば、ぜひ試してみてください。AWS AppSync コンソールのサンプルやサンプルリポジトリで簡単に始めることができることを忘れないでください。 JavaScript リゾルバの詳細については、 ドキュメント や チュートリアル を参照してください。詳細なガイド付きウォークスルーについては、 AWS AppSync Immersion Day Workshop をご覧ください。 サンプルリポジトリ には、使いやすいサンプルやガイドがあります。 本記事は、 AWS AppSync now supports JavaScript for all resolvers in GraphQL APIs を翻訳したものです。翻訳はソリューションアーキテクトの 稲田大陸 が担当しました。

この記事では、 Amazon SageMaker Processing API を使用して数値最適化問題を解く方法について説明します。最適化とは、様々な制約条件のもと、ある関数の最小値（または最大値）を求めるプロセスです。このパターンは、作業スタッフのシフト作成や輸送ルート選定、在庫配分、形状や軌跡の最適化など、ビジネスにおける重要な問題の解決に役立ちます。このような問題を解くためには、商用もしくはオープンソースで提供される“ソルバー”というソフトウェアが利用されます。この記事では、無償で利用できる3つの一般的な Python のソルバーを SageMaker Processingで実行し、これらの最適化問題を解く方法を示します。 概要 SageMaker Processing により、データサイエンティストと ML エンジニアは、SageMaker 上で前処理や後処理、モデル評価などのAIや機械学習に必要なタスクを簡単に実行できるようになります。このSDKは、 scikit-learn と Spark の組み込みコンテナを使用しますが、独自の Docker イメージを使用することもできます。これにより、SageMaker Processing に限らず、 Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) のようなAWSコンテナサービス、あるいはオンプレミスであっても、どんなコードも実行できるという柔軟性が得られます。まず、一般的な最適化パッケージとソルバーを含んだ Docker イメージをビルドし、以下の3つの最適化例題を解きます。 物流ネットワークを通じて商品を出荷するコストを最小化する 病院における看護師のシフトをスケジューリングする アポロ11号の月着陸船を最小の燃料で着陸させる軌道を求める それぞれの例題を、対応するソルバーを使用して解きます。おおまかには以下のステップに沿って各例題を解決します（こちらの ノートブック を参照）。 最適化ソルバー（GLPK や CBC など）に対応する Python インターフェース（Pyomo や PuLP など）を含む Docker コンテナのイメージをビルドする。 Amazon Elastic Container Registry (Amazon ECR) のリポジトリにビルドしたコンテナイメージをプッシュする。 SageMaker Python SDKを使用して（ノートブックなどから）Amazon ECRの Docker イメージを指定し、実際の最適化問題のコードを含むPythonファイルを送信します。 ノートブックまたは Amazon CloudWatch Logs でログを監視し、指定した Amazon Simple Storage Service （Amazon S3）の出力フォルダで結果を取得します。 以下にこの処理の全体像を図解します。 それでは始めましょう。 DockerコンテナのビルドとECRへのプッシュ まずは以下のような Docker ファイルを作成します。 FROM continuumio/anaconda3 RUN pip install boto3 pandas scikit-learn pulp pyomo inspyred ortools scipy deap RUN conda install -c conda-forge ipopt coincbc glpk ENV PYTHONUNBUFFERED=TRUE ENTRYPOINT ["python"] このコードでは、ソルバーにアクセスする Python インタフェースをインストールしています。ソルバーとは PuLP や Pyomo、Inspyred、OR-Tools、Scipy、DEAP のようなソフトウェアです。これらソルバーについてのより詳細な情報は、この記事の最後にある 参考情報 のセクションを参考にしてください。 以下のコードをノートブックから実行することで、コンテナイメージがビルドされ、Amazon ECR にプッシュされます。 import boto3 account_id = boto3.client('sts').get_caller_identity().get('Account') ecr_repository = 'sagemaker-opt-container' tag = ':latest' processing_repository_uri = '{}.dkr.ecr.{}.amazonaws.com/{}'.format(account_id, region, ecr_repository + tag) # Create ECR repository and push docker image !docker build -t $ecr_repository docker !$(aws ecr get-login --region $region --registry-ids $account_id --no-include-email) !aws ecr create-repository --repository-name $ecr_repository !docker tag {ecr_repository + tag} $processing_repository_uri !docker push $processing_repository_uri 上記のコードを実行した結果、以下のような出力が得られます（出力結果はサンプルであるため実行環境によって異なる点にご注意ください）。 Sending build context to Docker daemon 2.048kB Step 1/5 : FROM continuumio/anaconda3 ---> bbf09a95b565 Step 2/5 : RUN pip install boto3 pandas scikit-learn pulp pyomo inspyred ortools scipy deap ---> Using cache ---> 90655e74a46d Step 3/5 : RUN conda install -c conda-forge ipopt coincbc glpk ---> Using cache ---> d61d5542b339 Step 4/5 : ENV PYTHONUNBUFFERED=TRUE ---> Using cache ---> 56636836f8ae Step 5/5 : ENTRYPOINT ["python"] ---> Using cache ---> f3e5b0f6e957 Successfully built f3e5b0f6e957 Successfully tagged sagemaker-opt-container:latest WARNING! Using --password via the CLI is insecure. Use --password-stdin. WARNING! Your password will be stored unencrypted in /home/ec2-user/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded { "repository": { "repositoryArn": "arn:aws:ecr:us-east-2:xxxxxxxxxxxx:repository/sagemaker-opt-container", "registryId": "xxxxxxxxxxxx", "repositoryName": "sagemaker-opt-container", "repositoryUri": "xxxxxxxxxxxx.dkr.ecr.us-east-2.amazonaws.com/sagemaker-opt-container", "createdAt": 1691281443.0, "imageTagMutability": "MUTABLE", "imageScanningConfiguration": { "scanOnPush": false }, "encryptionConfiguration": { "encryptionType": "AES256" } } } The push refers to repository [xxxxxxxxxx.dkr.ecr.us-east-2.amazonaws.com/sagemaker-opt-container] 689828f5: Preparing 7ca1d711: Preparing 8bbb3a9d: Preparing 8bbb3a9d: Pushing 2.302GB/4.828GBPushing 1.843GB/4.828GB 8bbb3a9d: Pushed 4.954GB/4.828GBPushing 2.811GB/4.828GBPushing 3.629GB/4.828GBPushing 3.851GB/4.828GBPushing 3.973GB/4.828GBPushing 4.42GB/4.828GBPushing 4.437GB/4.828GBPushing 4.531GB/4.828GBlatest: digest: sha256:428c97609616197615e370da1f78b3aefaebd9ae7ac7739bad0ecb7849512cd1 size: 1169 SageMaker Python SDKによるジョブの実行 まず、以下のように SageMaker Processing ScriptProcessor を初期化します。 script_processor = ScriptProcessor(command=['python'], image_uri=processing_repository_uri, role=role, instance_count=1, instance_type='ml.m5.xlarge') そして、スクリプトファイル(この記事では“preprocessing.py”というファイル名で作成します)を記述し、以下のように SageMaker の Processingジョブを実行します。 from sagemaker.processing import ProcessingInput, ProcessingOutput script_processor.run(code='preprocessing.py', outputs=[ProcessingOutput(output_name='data', source='/opt/ml/processing/data')]) script_processor_job_description = script_processor.jobs[-1].describe() print(script_processor_job_description) 例題1: 最小のコストで商品を配送する流通ネットワークを選択する オハイオ州に拠点を置く鋼鉄製造会社であるAmerican Steel社は、ヤングスタウンとピッツバーグにある2つの製鉄所で鋼鉄を生産しています。同社は地域倉庫と現場倉庫で構成される流通ネットワークを通じて、完成品の鋼鉄を小売り顧客に供給しています。 このネットワークでは、American Steel社の2つの製鉄所ヤングスタウン（ノード1）とピッツバーグ（ノード2）で製造された鋼鉄が、現場倉庫であるオールバニ、ヒューストン、テンペ、ゲーリー（ノード6、7、8、9）へ出荷されます。ただしその途中で、シンシナティ、カンザスシティ、シカゴ（ノード3、4、5）の3つの地域倉庫を経由します。なお、一部の現場倉庫へは製鉄所から直接製品が供給されることもあります。 以下の表は、それぞれの都市間で輸送可能な鋼鉄の最小および最大量と、1,000トンあたり1ヶ月の鋼鉄の輸送コストを示しています。例えば、ヤングスタウンからカンザスシティへの出荷は鉄道会社によって行われますが、最小出荷量が1,000トン/月の契約を結んでいます。ただし、鉄道会社の車両数の制限により1ヶ月に5,000トン以上を出荷することができません。 発地 着地 コスト 最小輸送量/月 最大輸送量/月 Youngstown Albany 500 – 1000 Youngstown Cincinnati 350 – 3000 Youngstown Kansas City 450 1000 5000 Youngstown Chicago 375 – 5000 Pittsburgh Cincinnati 350 – 2000 Pittsburgh Kansas City 450 2000 3000 Pittsburgh Chicago 400 – 4000 Pittsburgh Gary 450 – 2000 Cincinnati Albany 350 1000 5000 Cincinnati Houston 550 – 6000 Kansas City Houston 375 – 4000 Kansas City Tempe 650 – 4000 Chicago Tempe 600 – 2000 Chicago Gary 120 – 4000 一般的な転送問題と同様、American Steel社の目的はネットワークを通じて商品を出荷するコストを最小限にすることです。 本例題では、次の流入保存制約に従う必要があります。製品を製造する”製鉄所“には「供給」が定義されており、ここから流出する商品は「供給」量以下である必要があります。また、消費地に近い”現場倉庫“には「需要」が定義されており、「需要」量以上の商品が流入される必要があります。また、各ノードへの流入量は流出量以上である必要があります。 この問題は以下のようにコード化されます。 %%writefile preprocessing.py import argparse import os import warnings """ The American Steel Problem for the PuLP Modeller Authors: Antony Phillips, Dr Stuart Mitchell 2007 """ # Import PuLP modeller functions from pulp import * # List of all the nodes Nodes = ["Youngstown", "Pittsburgh", "Cincinatti", "Kansas City", "Chicago", "Albany", "Houston", "Tempe", "Gary"] nodeData = {# NODE Supply Demand "Youngstown": [10000,0], "Pittsburgh": [15000,0], "Cincinatti": [0,0], "Kansas City": [0,0], "Chicago": [0,0], "Albany": [0,3000], "Houston": [0,7000], "Tempe": [0,4000], "Gary": [0,6000]} # List of all the arcs Arcs = [("Youngstown","Albany"), ("Youngstown","Cincinatti"), ("Youngstown","Kansas City"), ("Youngstown","Chicago"), ("Pittsburgh","Cincinatti"), ("Pittsburgh","Kansas City"), ("Pittsburgh","Chicago"), ("Pittsburgh","Gary"), ("Cincinatti","Albany"), ("Cincinatti","Houston"), ("Kansas City","Houston"), ("Kansas City","Tempe"), ("Chicago","Tempe"), ("Chicago","Gary")] arcData = { # ARC Cost Min Max ("Youngstown","Albany"): [0.5,0,1000], ("Youngstown","Cincinatti"): [0.35,0,3000], ("Youngstown","Kansas City"): [0.45,1000,5000], ("Youngstown","Chicago"): [0.375,0,5000], ("Pittsburgh","Cincinatti"): [0.35,0,2000], ("Pittsburgh","Kansas City"): [0.45,2000,3000], ("Pittsburgh","Chicago"): [0.4,0,4000], ("Pittsburgh","Gary"): [0.45,0,2000], ("Cincinatti","Albany"): [0.35,1000,5000], ("Cincinatti","Houston"): [0.55,0,6000], ("Kansas City","Houston"): [0.375,0,4000], ("Kansas City","Tempe"): [0.65,0,4000], ("Chicago","Tempe"): [0.6,0,2000], ("Chicago","Gary"): [0.12,0,4000]} # Splits the dictionaries to be more understandable (supply, demand) = splitDict(nodeData) (costs, mins, maxs) = splitDict(arcData) # Creates the boundless Variables as Integers vars = LpVariable.dicts("Route",Arcs,None,None,LpInteger) # Creates the upper and lower bounds on the variables for a in Arcs: vars[a].bounds(mins[a], maxs[a]) # Creates the 'prob' variable to contain the problem data prob = LpProblem("American Steel Problem",LpMinimize) # Creates the objective function prob += lpSum([vars[a]* costs[a] for a in Arcs]), "Total Cost of Transport" # Creates all problem constraints - this ensures the amount going into each node is at least equal to the amount leaving for n in Nodes: prob += (supply[n]+ lpSum([vars[(i,j)] for (i,j) in Arcs if j == n]) >= demand[n]+ lpSum([vars[(i,j)] for (i,j) in Arcs if i == n])), "Steel Flow Conservation in Node %s"%n # The problem data is written to an .lp file prob.writeLP('/opt/ml/processing/data/' + 'AmericanSteelProblem.lp') # The problem is solved using PuLP's choice of Solver prob.solve() # The status of the solution is printed to the screen print("Status:", LpStatus[prob.status]) # Each of the variables is printed with it's resolved optimum value for v in prob.variables(): print(v.name, "=", v.varValue) # The optimised objective function value is printed to the screen print("Total Cost of Transportation = ", value(prob.objective)) この例題を PuLP とそのデフォルトのソルバーである CBC を script_processor.run で実行します。この最適化ジョブは以下のログを出力します。 Status: Optimal Route_('Chicago',_'Gary') = 4000.0 Route_('Chicago',_'Tempe') = 2000.0 Route_('Cincinatti',_'Albany') = 2000.0 Route_('Cincinatti',_'Houston') = 3000.0 Route_('Kansas_City',_'Houston') = 4000.0 Route_('Kansas_City',_'Tempe') = 2000.0 Route_('Pittsburgh',_'Chicago') = 3000.0 Route_('Pittsburgh',_'Cincinatti') = 2000.0 Route_('Pittsburgh',_'Gary') = 2000.0 Route_('Pittsburgh',_'Kansas_City') = 3000.0 Route_('Youngstown',_'Albany') = 1000.0 Route_('Youngstown',_'Chicago') = 3000.0 Route_('Youngstown',_'Cincinatti') = 3000.0 Route_('Youngstown',_'Kansas_City') = 3000.0 Total Cost of Transportation = 15005.0 例題2: 病院における看護師のシフトをスケジューリングする（ナーススケジューリング） この例題では、4人の看護師の3日間の勤務スケジュールを作成します。ただし、勤務表の作成にあたっては以下の条件を満たす必要があります。 1日のスケジュールは 8 時間の 3 つのシフトで構成されます。 1日の中で 1 人の看護師が割り当てられるシフトは1つです。複数のシフトを勤務することはできません。 各看護師は 3 日間の期間中に少なくとも 2 つのシフトに割り当てられます。 このスケジューリング問題についてさらに詳しい情報は こちら をご参照ください。 この例題は以下のようにコード化されます。 %%writefile preprocessing.py from __future__ import print_function from ortools.sat.python import cp_model class NursesPartialSolutionPrinter(cp_model.CpSolverSolutionCallback): """Print intermediate solutions.""" def __init__(self, shifts, num_nurses, num_days, num_shifts, sols): cp_model.CpSolverSolutionCallback.__init__(self) self._shifts = shifts self._num_nurses = num_nurses self._num_days = num_days self._num_shifts = num_shifts self._solutions = set(sols) self._solution_count = 0 def on_solution_callback(self): if self._solution_count in self._solutions: print('Solution %i' % self._solution_count) for d in range(self._num_days): print('Day %i' % d) for n in range(self._num_nurses): is_working = False for s in range(self._num_shifts): if self.Value(self._shifts[(n, d, s)]): is_working = True print(' Nurse %i works shift %i' % (n, s)) if not is_working: print(' Nurse {} does not work'.format(n)) print() self._solution_count += 1 def solution_count(self): return self._solution_count def main(): # Data. num_nurses = 4 num_shifts = 3 num_days = 3 all_nurses = range(num_nurses) all_shifts = range(num_shifts) all_days = range(num_days) # Creates the model. model = cp_model.CpModel() # Creates shift variables. # shifts[(n, d, s)]: nurse 'n' works shift 's' on day 'd'. shifts = {} for n in all_nurses: for d in all_days: for s in all_shifts: shifts[(n, d, s)] = model.NewBoolVar('shift_n%id%is%i' % (n, d, s)) # Each shift is assigned to exactly one nurse in the schedule period. for d in all_days: for s in all_shifts: model.Add(sum(shifts[(n, d, s)] for n in all_nurses) == 1) # Each nurse works at most one shift per day. for n in all_nurses: for d in all_days: model.Add(sum(shifts[(n, d, s)] for s in all_shifts) <= 1) # min_shifts_per_nurse is the largest integer such that every nurse # can be assigned at least that many shifts. If the number of nurses doesn't # divide the total number of shifts over the schedule period, # some nurses have to work one more shift, for a total of # min_shifts_per_nurse + 1. min_shifts_per_nurse = (num_shifts * num_days) // num_nurses max_shifts_per_nurse = min_shifts_per_nurse + 1 for n in all_nurses: num_shifts_worked = sum( shifts[(n, d, s)] for d in all_days for s in all_shifts) model.Add(min_shifts_per_nurse <= num_shifts_worked) model.Add(num_shifts_worked <= max_shifts_per_nurse) # Creates the solver and solve. solver = cp_model.CpSolver() solver.parameters.linearization_level = 0 # Display the first five solutions. a_few_solutions = range(5) solution_printer = NursesPartialSolutionPrinter(shifts, num_nurses, num_days, num_shifts, a_few_solutions) solver.SearchForAllSolutions(model, solution_printer) # Statistics. print() print('Statistics') print(' - conflicts : %i' % solver.NumConflicts()) print(' - branches : %i' % solver.NumBranches()) print(' - wall time : %f s' % solver.WallTime()) print(' - solutions found : %i' % solution_printer.solution_count()) if __name__ == '__main__': main() この例題を OR-Tools とソルバーのCP-SATを使うよう、 script_processor.run で実行します。この最適化ジョブは以下のログを出力します。 Solution 0 Day 0 Nurse 0 does not work Nurse 1 works shift 0 Nurse 2 works shift 1 Nurse 3 works shift 2 Day 1 Nurse 0 works shift 2 Nurse 1 does not work Nurse 2 works shift 1 Nurse 3 works shift 0 Day 2 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 works shift 0 Nurse 3 does not work Solution 1 Day 0 Nurse 0 works shift 0 Nurse 1 does not work Nurse 2 works shift 1 Nurse 3 works shift 2 Day 1 Nurse 0 does not work Nurse 1 works shift 2 Nurse 2 works shift 1 Nurse 3 works shift 0 Day 2 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 works shift 0 Nurse 3 does not work Solution 2 Day 0 Nurse 0 works shift 0 Nurse 1 does not work Nurse 2 works shift 1 Nurse 3 works shift 2 Day 1 Nurse 0 works shift 1 Nurse 1 works shift 2 Nurse 2 does not work Nurse 3 works shift 0 Day 2 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 works shift 0 Nurse 3 does not work Solution 3 Day 0 Nurse 0 works shift 0 Nurse 1 does not work Nurse 2 works shift 1 Nurse 3 works shift 2 Day 1 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 does not work Nurse 3 works shift 0 Day 2 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 works shift 0 Nurse 3 does not work Solution 4 Day 0 Nurse 0 does not work Nurse 1 works shift 0 Nurse 2 works shift 1 Nurse 3 works shift 2 Day 1 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 does not work Nurse 3 works shift 0 Day 2 Nurse 0 works shift 2 Nurse 1 works shift 1 Nurse 2 works shift 0 Nurse 3 does not work Statistics - conflicts : 37 - branches : 41231 - wall time : 0.367511 s - solutions found : 5184 例題3: アポロ11号の月着陸船を最小の燃料で着陸させる軌道を求める この例題では、 Pyomo によるシンプルな宇宙ロケットのモデルを使用して、月面着陸のための制御ポリシーを計算します。 ここで使用しているパラメータは、1969年7月20日のアポロ11号月着陸船の月への降下時のものです。高度 h で垂直飛行中の質量 m のロケットの場合、運動量バランスにより次のモデルが得られます。 このモデルでは、 u は推進剤の質量流量、ve はロケットに対する排気の速度を表しています。モデリングと制御のこの最初の試みでは、燃料の燃焼によるロケットの質量の変化を無視します。 燃料消費量は以下の式で算出されます。 さらに以下で燃料消費量が最小となるような軌道を求めます。 この例題は以下のようにコード化されます。 %%writefile preprocessing.py import numpy as np from pyomo.environ import * from pyomo.dae import * #Define constants ... # lunar module m_ascent_dry = 2445.0 # kg mass of ascent stage without fuel m_ascent_fuel = 2376.0 # kg mass of ascent stage fuel m_descent_dry = 2034.0 # kg mass of descent stage without fuel m_descent_fuel = 8248.0 # kg mass of descent stage fuel m_fuel = m_descent_fuel m_dry = m_ascent_dry + m_ascent_fuel + m_descent_dry m_total = m_dry + m_fuel # descent engine characteristics v_exhaust = 3050.0 # m/s u_max = 45050.0/v_exhaust # 45050 newtons / exhaust velocity # landing mission specifications h_initial = 100000.0 # meters v_initial = 1520 # orbital velocity m/s g = 1.62 # m/s**2 m = ConcreteModel() m.t = ContinuousSet(bounds=(0, 1)) m.h = Var(m.t) m.u = Var(m.t, bounds=(0, u_max)) m.T = Var(domain=NonNegativeReals) m.v = DerivativeVar(m.h, wrt=m.t) m.a = DerivativeVar(m.v, wrt=m.t) m.fuel = Integral(m.t, wrt=m.t, rule = lambda m, t: m.u[t]*m.T) m.obj = Objective(expr=m.fuel, sense=minimize) m.ode1 = Constraint(m.t, rule = lambda m, t: m_total*m.a[t]/m.T**2 == -m_total*g + v_exhaust*m.u[t]) m.h[0].fix(h_initial) m.v[0].fix(-v_initial) m.h[1].fix(0) # land on surface m.v[1].fix(0) # soft landing def solve(m): TransformationFactory('dae.finite_difference').apply_to(m, nfe=50, scheme='FORWARD') SolverFactory('ipopt').solve(m, tee=True) solve(m) この連続時間の軌道最適化問題を解決するため、 Pyomo と非線形最適化ソルバー Ipopt を使用します。 実行結果は以下のように ScriptProcessor.run のログに出力されます。 Ipopt 3.12.13: ****************************************************************************** This program contains Ipopt, a library for large-scale nonlinear optimization. Ipopt is released as open source code under the Eclipse Public License (EPL). For more information visit http://projects.coin-or.org/Ipopt ****************************************************************************** This is Ipopt version 3.12.13, running with linear solver mumps. NOTE: Other linear solvers might be more efficient (see Ipopt documentation). Number of nonzeros in equality constraint Jacobian...: 448 Number of nonzeros in inequality constraint Jacobian.: 0 Number of nonzeros in Lagrangian Hessian.............: 154 Error in an AMPL evaluation. Run with "halt_on_ampl_error yes" to see details. Error evaluating Jacobian of equality constraints at user provided starting point. No scaling factors for equality constraints computed! Total number of variables............................: 201 variables with only lower bounds: 1 variables with lower and upper bounds: 51 variables with only upper bounds: 0 Total number of equality constraints.................: 151 Total number of inequality constraints...............: 0 inequality constraints with only lower bounds: 0 inequality constraints with lower and upper bounds: 0 inequality constraints with only upper bounds: 0 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 0 9.9999800e-05 5.00e+06 9.90e-01 -1.0 0.00e+00 - 0.00e+00 0.00e+00 0 1r 9.9999800e-05 5.00e+06 9.99e+02 6.7 0.00e+00 - 0.00e+00 4.29e-14R 4 2r 2.1397987e+02 5.00e+06 4.78e+08 6.7 2.14e+05 - 1.00e+00 6.83e-05f 1 3r 2.1342176e+02 5.00e+06 1.36e+08 3.2 4.37e+04 - 7.16e-01 6.16e-01f 1 4r 1.7048263e+02 4.99e+06 4.67e+07 3.2 1.60e+04 - 9.85e-01 4.16e-01f 1 5r 1.5143799e+02 4.99e+06 2.50e+07 3.2 3.57e+03 - 5.88e-01 7.62e-01f 1 6r 1.3041897e+02 4.99e+06 2.08e+07 3.2 1.89e+03 - 2.75e-01 8.14e-01f 1 7r 1.1452223e+02 4.99e+06 3.17e+04 3.2 1.97e+03 - 9.78e-01 8.18e-01f 1 8r 1.1168709e+02 4.99e+06 2.72e+05 3.2 3.36e-01 4.0 9.78e-01 1.00e+00f 1 9r 1.0774716e+02 4.99e+06 1.66e+05 3.2 4.28e+03 - 9.36e-01 9.70e-02f 1 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 10r 8.7784873e+01 5.00e+06 5.08e+04 3.2 3.69e+03 - 8.74e-01 7.24e-01f 1 11r 7.9008215e+01 5.00e+06 1.88e+04 2.5 1.09e+03 - 1.22e-01 8.35e-01h 1 12r 1.1960245e+02 5.00e+06 4.34e+03 2.5 1.81e+03 - 6.76e-01 1.00e+00f 1 13r 1.2344166e+02 5.00e+06 1.35e+03 1.8 1.66e+02 - 8.23e-01 1.00e+00f 1 14r 2.0065756e+02 4.99e+06 6.85e+02 1.1 4.28e+03 - 4.26e-01 1.00e+00f 1 15r 3.0115879e+02 4.99e+06 4.78e+01 1.1 9.69e+03 - 7.64e-01 1.00e+00f 1 16r 3.0355974e+02 4.99e+06 5.30e+00 1.1 4.92e+00 - 1.00e+00 1.00e+00f 1 17r 3.0555655e+02 4.99e+06 6.83e+02 0.4 7.49e+00 - 1.00e+00 1.00e+00f 1 18r 4.4494526e+02 4.97e+06 2.28e+01 0.4 2.17e+04 - 8.05e-01 1.00e+00f 1 19r 3.9588385e+02 4.97e+06 3.77e+00 0.4 4.73e+00 - 1.00e+00 1.00e+00f 1 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 20r 4.0158949e+02 4.97e+06 7.79e-02 0.4 5.70e-01 - 1.00e+00 1.00e+00h 1 21r 4.0076180e+02 4.97e+06 9.88e+02 -1.0 1.80e+00 - 1.00e+00 1.00e+00f 1 22r 5.4964501e+02 4.95e+06 7.59e+02 -1.0 1.57e+05 - 2.48e-01 2.32e-01f 1 23r 5.5056601e+02 4.95e+06 7.57e+02 -1.0 1.21e+05 - 1.00e+00 3.02e-03f 1 24r 5.5057553e+02 4.95e+06 7.57e+02 -1.0 1.09e+05 - 8.13e-01 3.34e-05f 1 25r 5.5898777e+02 4.95e+06 7.00e+02 -1.0 3.82e+04 - 1.00e+00 7.48e-02f 1 26r 6.0274077e+02 4.96e+06 3.93e+02 -1.0 3.53e+04 - 1.00e+00 4.39e-01f 1 27r 6.0301192e+02 4.96e+06 3.90e+02 -1.0 1.98e+04 - 1.00e+00 7.83e-03f 1 28r 6.0301418e+02 4.96e+06 3.89e+02 -1.0 1.61e+04 - 1.00e+00 9.62e-05f 1 29r 5.9834909e+02 4.96e+06 3.71e+02 -1.0 3.63e+03 - 1.00e+00 1.85e-01f 1 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 30r 5.7601446e+02 4.95e+06 1.67e+00 -1.0 2.96e+03 - 1.00e+00 1.00e+00f 1 31r 5.6977301e+02 4.95e+06 6.41e-02 -1.0 1.22e+00 - 1.00e+00 1.00e+00h 1 32r 5.7024128e+02 4.95e+06 9.05e-05 -1.0 4.89e-02 - 1.00e+00 1.00e+00h 1 33r 5.6989454e+02 4.95e+06 6.84e+02 -2.5 9.30e-02 - 1.00e+00 1.00e+00f 1 34r 5.7613459e+02 4.94e+06 5.38e+02 -2.5 5.65e+04 - 4.67e-01 2.13e-01f 1 35r 5.7617358e+02 4.94e+06 5.37e+02 -2.5 4.45e+04 - 1.00e+00 9.52e-04f 1 36r 6.6264177e+02 4.90e+06 3.78e+01 -2.5 4.45e+04 - 6.62e-01 9.30e-01f 1 37r 7.5101828e+02 4.90e+06 7.59e+01 -2.5 3.12e+03 - 1.25e-02 1.00e+00f 1 38r 7.5705424e+02 4.90e+06 8.60e-02 -2.5 7.04e-01 - 1.00e+00 1.00e+00h 1 39r 7.5713736e+02 4.90e+06 2.85e-05 -2.5 9.02e-03 - 1.00e+00 1.00e+00h 1 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 40r 7.5713093e+02 4.90e+06 4.90e+02 -5.7 6.76e-03 - 1.00e+00 9.99e-01f 1 41r 1.0909809e+03 4.78e+06 4.67e+02 -5.7 2.54e+06 - 6.15e-02 4.62e-02f 1 42r 1.0909867e+03 4.78e+06 4.67e+02 -5.7 2.42e+06 - 1.00e+00 9.55e-07f 1 43r 1.5672936e+03 4.59e+06 8.15e+03 -5.7 2.42e+06 - 3.36e-03 7.69e-02f 1 44r 1.7598365e+03 4.50e+06 8.17e+03 -5.7 2.24e+06 - 4.43e-08 4.23e-02f 1 45r 5.7264420e+03 2.36e+06 4.60e+03 -5.7 2.14e+06 - 7.07e-02 1.00e+00f 1 46 4.3546591e+03 2.35e+06 1.50e+01 -1.0 2.51e+08 - 3.52e-03 2.97e-03f 1 47 3.7700543e+03 2.16e+06 1.94e+01 -1.0 2.87e+06 - 3.27e-01 8.10e-02f 1 48 3.9963720e+03 1.02e+06 7.97e+00 -1.0 3.70e+05 - 3.47e-01 5.26e-01h 1 49 4.0601733e+03 5.28e+05 5.09e+00 -1.0 1.57e+06 - 5.24e-03 4.85e-01h 1 iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls 50 4.0596593e+03 5.27e+05 3.53e+00 -1.0 4.32e+06 - 7.60e-01 1.81e-03h 1 51 4.1577305e+03 9.40e+04 7.32e-01 -1.0 4.01e+05 - 9.09e-01 8.22e-01h 1 52 4.1754490e+03 1.27e+01 4.74e-02 -1.0 5.08e+04 - 8.32e-01 1.00e+00h 1 53 4.1752565e+03 7.78e-02 8.68e-07 -1.0 1.49e+04 - 1.00e+00 1.00e+00h 1 54 4.1704409e+03 1.60e+00 3.18e-05 -2.5 1.16e+04 - 1.00e+00 1.00e+00f 1 55 4.1704236e+03 6.98e-04 2.83e-08 -2.5 1.41e+03 - 1.00e+00 1.00e+00h 1 56 4.1702897e+03 1.15e-03 2.31e-08 -3.8 2.98e+02 - 1.00e+00 1.00e+00f 1 57 4.1702823e+03 3.63e-06 5.75e-11 -5.7 1.67e+01 - 1.00e+00 1.00e+00h 1 58 4.1702822e+03 1.28e-09 1.62e-14 -8.6 2.04e-01 - 1.00e+00 1.00e+00h 1 Number of Iterations....: 58 (scaled) (unscaled) Objective...............: 4.1702822027548118e+03 4.1702822027548118e+03 Dual infeasibility......: 1.6235231869939369e-14 1.6235231869939369e-14 Constraint violation....: 1.2805685400962830e-09 1.2805685400962830e-09 Complementarity.........: 2.5079038009909822e-09 2.5079038009909822e-09 Overall NLP error.......: 2.5079038009909822e-09 2.5079038009909822e-09 Number of objective function evaluations = 63 Number of objective gradient evaluations = 16 Number of equality constraint evaluations = 63 Number of inequality constraint evaluations = 0 Number of equality constraint Jacobian evaluations = 60 Number of inequality constraint Jacobian evaluations = 0 Number of Lagrangian Hessian evaluations = 58 Total CPU secs in IPOPT (w/o function evaluations) = 0.682 Total CPU secs in NLP function evaluations = 0.002 EXIT: Optimal Solution Found. まとめ この記事では、SageMaker Processing を使用して数値最適化問題を解決するために、様々なフロントエンドツールやソルバーを試しました。さらに、Scipy.optimize やDEAP、Inspyred を使用して他の例題を試してみてください。自社におけるビジネス問題を SageMaker Processing を使用して解決する際には、次のセクションの参考文献や他の例題を参照してください。もし現在、機械学習プロジェクトで SageMaker API を使用している場合、最適化を実行するために SageMaker Processing を使用することは、シンプルな方式です。ただし、最適化問題の解決のためにこれらのオープンソースライブラリを実行するには、Lambda や Fargate などの他のAWSサービスも検討することをおすすめします。また、この記事で使用したオープンソースライブラリは最小限のサポートで提供される一方、CPLX や Gurobi などの商用ライブラリは常に高いパフォーマンスを追求しており、通常はプレミアムサポートも提供されています。 参考情報 Training APIs: Processing https://pypi.org/project/PuLP/ OR-Tools: Get Started Guides Pyomo Documentation 5.7.2 inspyred: Recipes Optimization and root finding (scipy.optimize) DEAP documentation https://www.gurobi.com/ CPLEX optimzer OR Tools code license PuLP code license Pyomo code license 著者について Shreyas Subramanian は AI/ML specialist Solutions Architect です。機械学習を使ってAWSのお客様の課題解決に取り組んでいます。 この記事の翻訳はソリューションアーキテクトの横山誠が担当しました。原文は こちら です。

人気の React フレームワークである Next.js は、開発者がモダンな Web アプリケーションを構築する方法を変えました。Next.js は、Static Site Generation (SSG) や Server Side Rendering (SSR) といった強力な機能を提供し、アプリケーションのパフォーマンスとユーザー体験を最適化します。本記事では、SSG と SSR の主な違い、利点、いつどちらかを選択するか、それぞれのアプローチで AWS Amplify を使ってデプロイする方法を説明します。Amplify は、フロントエンドの Web やモバイル開発者が AWS 上でフルスタックのアプリケーションを簡単に構築、ホストできるようにする包括的なソリューションです。 Static Site Generation (SSG) とは？ Static Site Generation は、ビルド時に静的な HTML ファイルを生成します。アプリをビルドするたびに、全てのページが作成されます。ユーザーが Web サイトにアクセスするとこれらのファイルがユーザーに提供され、サーバーは余計な作業をする必要がなくなります。このアプローチは、ブログやドキュメントサイトのような、頻繁に変更されないコンテンツを持つ Web サイトに適しています。 SSG の利点 速度 ： レンダリングされた HTML ファイルが直接提供されるため、ロード時間が短縮されます。 スケーラビリティ ： 静的ファイルは CDN によって簡単に提供され、アプリケーションの能力を向上させ、グローバルなトラフィックを処理することができます。 Server Side Rendering (SSR) とは？ Server Side Rendering は、ユーザーがリクエストしたときに、サーバー上で各ページを生成します。SSR では、ページを事前にレンダリングするサーバーがあります。それは、変数を差し込むテンプレートのようなもので、サーバーはすべてのレンダリングを処理します。。これはリクエスト時に発生するので、ユーザがページをリクエストすると、サーバ側でレンダリングされたページを取得します。このレンダリングはすべてサーバーサイドで行われ、ブラウザで実行されることはありません。そのため、ページがすでにサーバでレンダリングされてクライアントに提供されるのを待っている SSG とは異なり、SSR はリクエストを受け取ったときにサーバでページをレンダリングします。SSR は、e コマースサイトやソーシャルメディアプラットフォームのような、頻繁に変更される動的またはパーソナライズされたコンテンツを持つ Web サイトに最適です。 SSR の利点 一貫したユーザー体験 ： ユーザーは、その場で生成された最新のコンテンツを見ることができ、常に最新の情報を得ることができます。 パーソナライゼーション ： SSR は、ユーザーの嗜好やその他の動的なデータに基づいて、ユニークなコンテンツを提供することができます。 SSG と SSR のどちらを選ぶべきか コンテンツは頻繁に更新されていますか？コンテンツが頻繁に変更されない場合は、パフォーマンスとスケーラビリティを向上させるために SSG を選択する方が良いでしょう。動的なコンテンツの場合、SSR はユーザーに最新の情報を提供します。 あなたの Web サイトはインタラクティブなユーザー体験を提供しますか？ SSR Web サイトはインタラクティブなユーザー体験を提供しますが、SSG Web サイトは CSR や SSR と組み合わされていない限り、動的コンテンツをほとんど含まない静的なサイトです。 ビルド時とランタイムのどちらにレンダリングコストをかけたいですか？ ビルド時にレンダリングコストを発生させたい場合は SSG を、ランタイムに発生させたい場合は SSR を選択してください。 SEO 対策は必要ですか？ SEO のための SSR と SSG の主な違いは、サーバーの応答時間だけです。 ビジネス要件を考慮する SSG は優れた SEO 効果を提供しますが、SSRは 検索ランキングに重要な動的コンテンツとパーソナライゼーションをより良くサポートします。 ユーザー体験 ： ユーザーがリアルタイムのデータやパーソナライズされたコンテンツを必要としているかどうかを検討しましょう。もし必要であれば、SSR の方がよいでしょう。そうでない場合は、SSG の方がより低いサーバー要件でより高速な体験を提供します。 最新データ ： SSRページはユーザーからのリクエストごとにサーバー上で生成されるため、常に最新のデータを表示します。すべてのリクエストで、常に最新/最新の情報を得ることができます。 Next.js の SSG と SSR： 正しいレンダリングアプローチの選択 この記事では、Next.jsの2つのレンダリングアプローチ、SSGとSSRについて説明します。また、あなたのアプリケーションに最適なレンダリングアプローチを判断するためのコードベース例も紹介します。 Next.js は、n 個の動的生成ルートを生成する機能をサポートしています。コードベースの例では、過去数日間の Hacker News のトップ投稿を 100 件取得し、それらの ID をホームページにレンダリングします。 クリックすると、それぞれのページに投稿の詳細が表示されます。これらの各ページはまた、 pages/[hackerNewsArticleId] のようなルートを持ちます。あなたは、そのテンプレートページが slug 指定で pages フォルダで利用可能であることを見ることができます。 この静的に生成されるパスのリストを定義するために getStaticProps と getStaticPaths の 2 つの Next.js 関数を使います。 getStaticProps は、ビルド時にページをプリレンダリングし、Hacker News API から投稿情報のリストを取得し、その情報を getStaticPaths と同様にコンポーネントの props に渡します。 2番目の関数である getStaticPaths は動的ルーティングに非常に重要です。 getStaticProps から ID のリストを受け取り、以下のようなパスオブジェクトのリストを作成します。 export async function getStaticPaths() { return { paths: [{ params: { id: '1' } }, { params: { id: '2' } }], fallback: false, // can also be true or 'blocking' } } Next.js はこのパスのリストを取り込み、それぞれのパラメータに対して新しいページを生成します。また、個々のページにルーティングするために、プライマリコンポーネントに Hacker News ID をインジェストしてレンダリングするようにしました。動的にレンダリングされたコンポーネントページに行くと、再び getStaticProps メソッドを呼び出して Hacker News の詳細エンドポイントを呼び出し、投稿のタイトルや投票数などを取得していることがわかります。これはコンパイル時のブログ記事のスナップショットであることに注意してください。 SSG のアプローチ GitHub リポジトリ から、SSG Next.js アプリを Amplify にデプロイする方法を説明します。まずは、以下をクリックして、このプロジェクトを自分の環境にデプロイしてください。Amplify でのデプロイとホスティングの詳細は こちら を確認してください。 Connect to GitHub を選択し、aws-amplify-console を認証します。 Deploy App ページで、 Create new role を選択します。 ロールを作成したら、 Deploy App ページで既存のロールをリフレッシュし、作成したばかりのロールを選択します。 Save and Deploy を選択します。 アプリのデプロイには 2 ～ 3 分かかります。ボックスが表示されたら、 Continue をクリックします。その後、Amplify アプリがプロビジョニング、ビルド、デプロイの各段階に進むのを確認できます。 デプロイが完了すると、そのドメインでホストされている Web サイトにアクセスできるようになります。 ドメインを選択すると、Amplify アプリに移動し、SSG Next.js アプリが表示されます。 SSR のアプローチ Next.js の Web アプリケーション を GitHub から直接 Amplify にデプロイする方法を見ていきましょう。 実は Amplify にデプロイするときに、すでに SSR ページをデプロイしています。Next.js のすごいところは、ビルド時に生成するページもあれば、SSR を利用して動的なデータをレンダリングするページもあることです。 特定のページで Server Side Rendering を使用するには、 getServerSideProps という非同期関数をエクスポートします。この関数は、リクエストごとにサーバーから呼び出されます。 ホストされているリンクで、 /ssr ルートに移動します(ie. https://main..amplifyapp.com/ssr). このようなページが表示されるはずです。 よくある問題 Next.js では、Create React App (CRA) や React Router といったライブラリを活用する、非常に人気のあるフロントエンド・フレームワークとは異なるパラダイム・シフトが必要です。 CRA は、React アプリケーションを作成するためのボイラープレート・プロジェクトを提供するスターターキットです。CRA は Client Side Rendering (CSR) を使用し、アプリケーションはブラウザでレンダリングされ、通常、ユーザーのインタラクションに基づいてネットワークリクエストを分割するのがベストプラクティスです。SSG と比較すると、すべてのデータを一度にロードしなければなりません。 Static Site Generation 大規模な静的 Web サイトでは、ビルドやデータ取得にかかる時間をすべて顧客に渡す代わりに、サイトがビルドされるのを何時間も待つことになるかもしれません。静的ページの数が 2 倍になるたびに、ビルド時間も 2 倍になります。 10,000 のアイテムがある e コマース・ Web サイトの場合、各アイテムのフェッチ／ビルドに約 1 秒かかるとすると、ビルドとデプロイに 3 時間近くかかることになります。 この場合、 Incremental Static Regeneration (ISR) が適しています。これによって Web サイト全体を再構築することなく変更を加えることができます。 データ・フェッチ 最近の Web 開発では、ユーザーの viewport (表示領域) を埋めるのに十分な API 呼び出しだけを行い、潜在的に後続のユーザーアクションのためのデータをプリフェッチすることがが推奨されることがよくあります。しかし、SSG では、 Web ページ全体と潜在的なユーザーのアクションをすべて入力するために必要なすべての API をコールする必要があります。 ページの更新 例えば、複数のセクションがあるブログのページなど、 Web サイトのあるページが頻繁に更新される場合、SSG はひとつのページに含まれる変更のために、サイト全体を頻繁にリビルドす必要があるかもしれません。 その結果、SSG ページはビルド時に HTTP ヘッダやクエリパラメータのようなリクエストに直接アクセスすることができません。もしこれらにアクセスしたければ、SSG に加えてカスタムミドルウェアを書かなければなりません。 Server Side Rendering レイテンシ 生成プロセスにおいて、外部 API からのデータ取得のように、最終的にページの読み込み速度に影響を与える外部要因があります。API のレスポンスが遅ければ、ページ生成の読み込み時間は遅くなります。また、SSR はリクエストごとにページを生成するので、SSG に比べて遅くなります。 SSR のページでキャッシュを有効にし、読み込み時間速度を改善するには、 getServerSideProps を呼び出すときに、追加の HTTP ヘッダ、Cache-Control を追加する必要があります。 こちら を参照してください。キャッシュについてもっと学びたい場合は、 こちら も参照ください。 スケーラビリティ SSR はリクエストごとにサーバーがフロントエンドを処理し生成する必要があり、Web サイトが複雑なページを持ち、処理するエンドクライアントが多い場合、スケーラビリティが低く、速度も遅くなります。 SSR の 動的 HTMLは静的な CDN (例：CloudFront) によってキャッシュされることができず、サーバーとの往復時間が長くなり、ページをリクエストしてからサーバーによって最初のバイトが読み込まれるまでの時間 (TTFB: Time to First Byte) が遅くなります。 SEO Google と Bing は、最新のレンダリングエンジンで同じChromium ベースのクローラーを活用すると発表しましたが、JavaScript は依然として検索エンジンがページを解析する能力を複雑にし、SEO ランクを下げる可能性があります。検索エンジンは JavaScript ファイルをダウンロードする必要があり、サイトの他の部分に移動する前にバンドル全体が読み込まれるのを待てない可能性があります。結局のところ、Google や Bing があなたのページをどのようにランク付けするかは不確実であり、クローラーを楽にすることは理にかなっていると言えるでしょう。 クリーンアップ Amplify アプリの削除 GitHub アプリの削除 まとめ SSG も SSR も、Next.js アプリケーションの種類によってそれぞれの利点があります。プロジェクトのコンテンツ頻度、SEO、ユーザー体験、開発の複雑さなどを理解することで、Next.js プロジェクトで SSG と SSR のどちらを使うべきか、十分な情報を得た上で決定することができます。最終的には、特定のユースケースと、パフォーマンス、スケーラビリティ、動的コンテンツのトレードオフ次第です。 まずは、 Amplify Hosting を利用して、ユーザー認証機能付きの Next.js 13 Web アプリを構築 してみてください。 著者について Alexa Perlov Alexa Perlov は、ニューヨークを拠点とするAmazon Web Services のソリューションアーキテクトです。メディアとエンターテインメントの戦略的アカウントのビジネス目標達成のために AWS を活用するサポートをしてます。技術トレーニングをリードし、幅広いクラウドドメインに焦点を当てたプロトタイプを開発しています。 Michael Tran Michael Tran は Amazon Web Services のプロトタイピングアクセラレーションチームのソリューションアーキテクトです。技術的なガイダンスを提供し、AWS 上で可能なアートを示すことで顧客のイノベーションを支援しています。専門は AI/ML 分野におけるプロトタイプの構築。 本記事は、 SSG vs SSR in Next.js Web Applications: Choosing the Right Rendering Approach を翻訳したものです。翻訳はソリューションアーキテクトの 稲田大陸 が担当しました。

はじめに AWS IoT Core を使ってモノのインターネット (IoT) デバイスのフリートを管理する際に、特定のデバイスやデバイスのセットを ID や能力に基づいて検索し発見する方法として、AWS IoT のモノのタイプの属性を使うことはデバイスの発見を容易にするために推奨される方法の一つです。 「モノ」とは、AWS IoT Core の IoT 対応デバイスのようなエンティティの論理的な名前です。モノのプロビジョニング中に、AWS IoT レジストリ内での識別と検索を容易にするために、検索可能な属性を付与することができます。 AWS IoT レジストリ からモノを検索したいのはどんな場合でしょうか? その質問に答えるために、Lighting-as-a-Service (LaaS) プロバイダまたはその顧客が（セルフサービスポータルを通じて）、既に設置されている照明から、特定の製品タイプ、モデル番号、ワット数、輝度、色、製造バッチがいくつあるかを特定する必要がある、コネクテッド照明のユースケースを考えてみましょう。 AWS IoT Core では、モノに検索可能な属性の数が 3 つまでという制限があり、追加の属性に基づいてデバイスを検索したいときには十分でない場合があります。本記事では、AWS IoT Core の モノのタイプ と AWS IoT Device Management の フリートインデックス の組み合わせを使って、この課題を軽減する方法を紹介します。 フリートインデックスにより、フリート管理者はデバイスフリートを整理、調査、トラブルシューティングすることができます。デバイスのグループに検索を実行し、状態、接続性、デバイス違反を含むデバイス属性のさまざまな組み合わせに基づくデバイスレコードの統計を集計できます。例えば、ある場所に設置されたあるモデルの電球のうち、現在何個が接続切断されていて、古いバージョンのファームウェアを実行しているか、といった情報を検索することができます。 前提条件 AWS IoT Core の デバイスプロビジョニング 機能と AWS IoT Device Management のフリートインデックス機能の基本的な理解が必要です。 チュートリアル それでは、検索不可能な属性をモノに追加する方法と、検索不可能な属性を使っていてもフリートインデックスを使って検索する方法を見てみましょう。 MyFirstThing というモノをプロビジョニングし、検索可能な属性を付けてみましょう。下図からわかるように、検索可能な属性は 3 つしか付与することができません。 このモノにさらに属性を追加するために、モノに「モノのタイプ」を付与することができます。 モノのタイプは、同じタイプに関連付けられたすべてのモノに共通する説明と構成情報を保存することを可能にします。これにより、レジストリ内のモノの管理が簡単になります。例えば、一つ一つの電球に個別に属性を割り当てる代わりに、LightBulb というモノのタイプを作成し、シリアル番号、光度、ワット数などの電球の属性を関連付けることができます。さらに、既存のモノのタイプを LightBulb に変更すれば、モノのタイプの属性を継承し、モノのタイプで定義された各属性の値を指定することができるようになります。 モノのタイプをモノに割り当てることはオプションですが、これを使うことで 47 の検索不可能な属性が追加可能となります。この関連付けにより、下図のように合計 50 の属性が使用可能になります。 本記事では、メーカー、シリアル番号、ワット数などの検索可能な属性を持つ LightBulb タイプを作成し、 MyFirstThing に割り当てました。また下図でわかるように、3 つの検索不可能な属性（色、ファームウェア・タイプ、輝度）を追加しました。 では、AWS CLI の list things コマンドを使って検索してみます。検索可能な属性で検索すると、LightBulb_1 がヒットします。 aws iot list-things --attribute-name "wattage" --attribute-value '40' { "things": [ { "thingName": "LightBulb_1", "thingTypeName": "LightBulb", "thingArn": "arn:aws:iot:ap-south-1:************:thing/LightBulb_1", "attributes": { "Color": "White", "Firmware_Type_Version": "Smart_LED.1.0", "Luminosity": "100", "manufacturer": "xyz_corp", "serialnumber": "123", "wattage": "40" }, "version": 5 } ] } しかし、検索不可能な属性で検索すると、モノのタイプで追加された属性は検索不可能であるため、コマンドは何も返しません。 aws iot list-things --attribute-name "Color" --attribute-value 'White' { "things": [] } そこで、AWS IoT Device Management のフリートインデックス機能が役に立ちます。 AWS IoT Device Management のフリートインデックス機能を使えば、AWS IoT レジストリ、AWS IoT デバイスシャドウ、AWS IoT への接続状態、AWS IoT Device Defender での違反といったソースからデバイスデータのインデックスを作成、検索、集約することができます。 フリートインデックス機能は、前述したような主要な機能を備えていますが、本記事ではモノのタイプの属性に基づくインデックス作成と検索にのみ焦点を当てます。 それでは、AWS IoT コンソールを使ってフリートインデックスを有効にしましょう（既に有効になっている場合はこのステップは飛ばしてください）。左のパネルから 設定 を選択し、 フリートのインデックス作成  までスクロールし、以下のように インデックス作成の管理 を選択します。 フリートインデックスの管理画面で、以下のようにスイッチを切り替えてフリートインデックスを有効化し、画面下部の 更新 を選択して設定を保存します。 前の画面に表示されている他のチェックボックスは、デバイスシャドウ、接続状態、および Device Defender の違反に基づくインデックス作成と検索を可能にしますが、これらはこの記事の範囲外であるためここでは選択しません。 フリートインデックスが有効化されたら、下図に示すように AWS IoT のモノの管理コンソールから  高度な検索 を選択します。 検索ボックスを使って、検索不可能な属性を検索します。例えば、color の値が white である場合、以下のように、一致する属性値を持つものが画面下部に検索結果として表示されます。 また、AWS CLI を使用して、検索不可能な属性 color の値が white であるデバイスに対して同様の検索を実行することもできます。 aws iot search-index –query-string ‘attributes.color=White’ { "things": [ { "thingName": "LightBulb_1", "thingId": "******************************", "thingTypeName": "LightBulb", "attributes": { "Color": "White", "Firmware_Type_Version": "Smart_LED.1.0", "Luminosity": "100", "manufacturer": "xyz_corp", "serialnumber": "123", "wattage": "40" } } ] } なお、AWS IoT Device Management のフリートインデックス作成は、管理者がデバイス群を整理、調査、トラブルシューティングできるようにするものであり、管理用途でのみ使用すべきことにご注意ください。 フリートインデックスと検索機能は、インデックスの更新と検索の実行数によって課金されます。詳しくは 価格ページ をご覧ください。また、制限とクォータについては こちら をご覧ください。 まとめ 本記事では、AWS IoT モノのタイプと AWS IoT Device Management のフリートインデックスを使ってデバイスの検索性を向上する方法を紹介した。モノのタイプを使用すると、モノに追加の属性（検索不可）を付与することができ、これらは検索不可の属性でありながら、フリートインデックス機能を使用することでこれらの属性が検索可能となります。 その他のAWS IoT Core 関連のリソースについては、 ウェブサイト をご覧ください。 この記事は Ankush Sharma によって書かれた How to improve device discoverability by unlocking 50 AWS IoT thing type attributes の日本語訳です。この記事はソリューションアーキテクトの中西貴大が翻訳しました。

このブログ記事は AWS offers new artificial intelligence, machine learning, and generative AI guides to plan your AI strategy を翻訳したものです。 人工知能 (AI) および機械学習 (ML) に関するブレイクスルーはこの数か月の間、毎日のように話題になっていますが、それには正当な理由があります。これらのテクノロジーの新たな進化や機能は、あらゆる分野や業界のお客様に新たなビジネスチャンスをもたらすものだからです。その一方、これらの技術の進化があまりにも高速であるため、各企業では、これらのブレイクスルーが自分たちにとって具体的に何を意味するのかを評価することが難しくなっています。 アマゾン ウェブ サービス (以下、AWS) では、長年にわたり、AI、ML、そして Generative AI (以下、生成系AI) へのアクセスと理解の民主化に投資してきました。 生成系 AI の最新開発に関する発表 や 1 億ドル規模の Generative AI Innovation Centerの設立 を通じて、AWS は、これらのイノベーションが個人と組織の両方の生活に果たす役割を深く理解するため、最前線に立って支援を行っています。AI と ML に関する選択肢を理解しやすくするため、AWS は 2 つの新しいガイドを公開しました： AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI と、 AWS機械学習サービスを選択するための意思決定ガイド です。 AI, ML, 生成系AIのためのAWSクラウド導入フレームワーク AI, ML, 生成系AIのためのAWSクラウド導入フレームワーク ( AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI (以下, CAF-AI)) は、AI への移行を支援する目的で設計されており、AI/ML によってビジネス価値を生み出そうとする組織にとってのメンタルモデルを示しています。AWS自身、および当社のお客様の経験に基づいて作られた本フレームワークのベストプラクティスにより、AI 変革を実現し、AWSでのAIの革新的な利用を通じてビジネス成果を加速させています。 AWSのお客様およびパートナーチームでも利用されているCAF-AIは、AIによる変革のための戦略の導出、優先順位付け、進化、およびコミュニケーションに役立ちます。以下の図は、お客様が求めるビジネス成果 (1) を起点に考える「Working Backwards」のアプローチにより、AI、ML、生成系AIがもたらす機会 (2) 、自社内で変革の対象とする領域 (3) 、および基盤となるケイパビリティ (4) を、AI戦略のアクションアイテムの評価、導出、実装という反復的なプロセス (5) を通じてAIジャーニーを簡素化する方法を示しています。 CAF-AIでは、AIとMLに関する組織内のケイパビリティが成熟するにつれて経験する可能性のあるAI/MLジャーニーについて説明します。その指針を示すため、組織がAIの成熟度をさらに高めるために役立つことが確認されている基本的なケイパビリティの進化に焦点を当てています。 また、これらの基本的なケイパビリティのターゲット状態の概要を通じて規範的なガイダンスを提供し、その過程でビジネス価値を生み出すためにケイパビリティを段階的に進化させる方法を説明します。以下の図は、クラウドと AI/ML の運用のための基本的なケイパビリティを示しています。ここでいうケイパビリティとは、所定のプロセスを使用してリソース (人、技術、その他の有形または無形の資産) を投入して成果を達成する組織の能力を指します。CAF-AIは現在も進化を続けている知識の指標であるため、時間の経過とともに成長し、変化することが見込まれます。 CAF-AI は、お客様の ML と AI への取り組みの出発点および方向付けのポイントとして設計されており、組織が中期的な AI と ML のアジェンダを策定し、それに影響する重要なトピックや視点を理解しようとする際にインスピレーションを得られるドキュメントとなることを意図しています。AI/ML ジャーニーのどの段階にいるかによって、特定のセクションに焦点を当ててそこでスキルを磨くことも、ドキュメント全体を使って成熟度を判断し、短期的な改善領域を導出することも可能です。 AI/MLが適用可能なビジネス課題は単一の機能や領域に限定されないため、AI/MLが差別化要素となる市場で競争の場をリセットする方法を探しているあらゆるビジネスの機能と業界ドメインに当てはまります。 AI、ML、生成系AIのための AWS クラウド導入フレームワーク は、この成果を達成するために AWS が提供する多くのツールの 1 つです。AI/MLは、何十年もの間解決するのが経済的ではない (またはAI/MLなしでは技術的に不可能だった) 問題に対するソリューションと解決への道筋を可能にするため、結果的に得られるビジネス成果の可能性は計り知れません。 AWS機械学習を選択するための意思決定ガイド AWSは、常にお客様のための選択肢を重視してきました。AI の活用機会の拡大にあたり、お客様のビジネスニーズに最適なサービス、モデル、インフラストラクチャを選択できるよう、適切なサポートを受けられることが最も重要と考えています。 AWS機械学習サービスを選択するための意思決定ガイド は、AWS が提供する AI および ML サービスの詳細な概要を示し、お客様とお客様のユースケースに適したサービスの選択方法に関する体系的なガイダンスを提供することを目的としています。 本ガイドは、適切な選択を行うための基準の明確化と検討にも役立てることができます。たとえば、AWS が提供する AI/ML サービスの適用範囲 (下記スクリーンショット参照) について説明しています。この説明を参照することにより、お客様において必要な制御とカスタマイズの度合いなど、さまざまなレベルの管理要件に対応するサービスを選定することが可能になります。 また、本ガイドでは、生成系AIの基盤モデルの力を引き出すための AWS サービスの独自機能や、急速に進化する生成系AIの分野を最大限に活用できる機会についても説明しています。 さらに、本ガイドには、特定のサービスの詳細、詳細なサービスレベルのテクニカルガイドへのリンク、主要サービスの独自の機能を強調した比較表、AI サービスと ML サービスの選択基準が掲載されています。AWS で AI、ML、生成系 AIの サービスを使い始めるのに役立つ主要なリソースへのリンクもまとめられています。 AWS が提供する AI、ML、生成系 AI サービスの幅広さを理解したいお客様におかれましては、本ガイドは良いスタートポイントになると考えています。 結論 このブログ記事で紹介した AWS機械学習サービスを選択するための意思決定ガイド と、 AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI では、お客様からよく聞かれる技術的ならびに非技術的な質問が網羅されています。これらのリソースが皆様のお役に立てば幸いです。各リソースに対するフィードバックをお待ちしています。 著者について Caleb Wilkinson はAIソリューションの構築に10年以上携わっています。AWSのシニアMLストラテジストとして、組織が責任のある形でAIからベネフィットが得られる可能性を広げるための革新的なAIアプリケーションを開拓しています。本記事で紹介したCAF-AIの共著者の一人です。 Alexander Wöhlke は、AI/ ML の分野で 10 年の経験があります。AWS Generative AI Innovation CenterのシニアMLストラテジスト 兼 テクニカルプロダクトマネージャーです。大規模組織のAI戦略策定に取り組んでおり、お客様が技術開発の最前線で計算されたリスクを取れるよう支援しています。本記事で紹介したCAF-AIの共著者の一人です。 Geof Wheelwright は AWS Decision Content チームのマネージャーです。本チームは、AWS 入門リソースセンターに掲載されている意思決定ガイドの執筆と開発を行っており、本記事で紹介した「AWS 機械学習サービスを選択するための意思決定ガイド」も作成しました。1980年代初頭にシンプルなテキストベースの Apple II 搭載版の ELIZA を体験して以来、AIとその先祖に相当する技術との仕事を楽しんでいます。

企業などの組織は、重要なデータを保護し、データを復元できるようにするため、データ保護やアーカイブのソリューションを利用しています。ハイブリッドアーキテクチャに移行するにつれて、データが様々な場所やプラットフォームに分散されるようになり、このような複雑性に対応できるバックアップソリューションが課題となっています。 インフラストラクチャの自動的なプロビジョニングと、クラウドをベースにしたリモートバックアップとリカバリのソリューションが登場したことにより、クラウドネイティブなワークロードに適合する高度なデータ保護とバックアップ戦略を採用できるようになりました。 VMware Cloud on AWS は、VMware によるエンタープライズグレードの SDDC (Software-Defined Data Center) と、Amazon Web Services (AWS) の グローバルインフラストラクチャ 上で稼働する Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンスを統合した、共同開発によるフルマネージドサービスです。この統合によって、仮想マシン (VM) をリプラットフォームすることなく、ワークロードを VMware Cloud on AWS にシームレスに移行することができます。 一方 AWS Backup は、さまざまな AWS サービスのデータバックアップを一元化および自動化するフルマネージドバックアップサービスです。re:Invent 2021 において、VMware をサポートすることが発表され、VMware Cloud on AWS、VMware Cloud on AWS Outposts、オンプレミスの VMware で稼働する仮想マシンについてもデータ保護を一元化および自動化できるようになっています。 さらに 2022 年 6 月、VMware ワークロード向けの AWS PrivateLink のサポートが加わりました。VMware 環境から、Virtual Private Cloud (VPC) のプライベートインターフェースエンドポイントを介して、 AWS Backup に直接アクセスすることができます。 この記事では、VMware Cloud on AWS で実行されるワークロードを保護するために、プライベートインターフェース VPC エンドポイント (AWS PrivateLink) を用いて AWS Backup を利用する際、考慮すべきアーキテクチャ設計について説明します。 ソリューションの概要 AWS Backup は VMware vSphere と統合されており、AWS エコシステム内での仮想マシンのバックアップのスケジューリング、管理、保存を可能にします。バックアップを異なる AWS リージョンやアカウント間でコピーすることもできる、事業継続とランサムウェア攻撃からの保護のための包括的なソリューションです。手動または指定されたスケジュールに従って、バックアップを作成することができます。 最初のバックアップの復旧ポイントは仮想マシンの完全なスナップショットで構成されます。その後のバックアップは増分で、最後のバックアップ以降の変更分のみを取得します。さらに、バックアップをウォームストレージ層から、より経済的なコールドストレージ層に自動的に移行することでコストを削減します。 デフォルトでは、仮想マシンのアプリケーション整合性を保持したバックアップを実現するために、VMware Tools の静止設定を使用します。VMware Tools が利用できない場合には、クラッシュ整合性バックアップを取得します。ネットワークの転送効率を高めるため、バックアップは圧縮されて転送されます。 AWS ではセキュリティが最優先事項であり、AWS Backup は強固な 暗号化対策 を採用しています。仮想マシンのバックアップは、非常に安全な AES-256 暗号化アルゴリズムを使用して、転送中と保管時に暗号化されます。 カスタマーマネージドキー を使用してクラウドに保存されたバックアップを暗号化することで、セキュリティを強化できます。 図 1 – VMware Cloud on AWS と AWS Backup の統合アーキテクチャ 図 1 に示すように、VMware Cloud on AWS 上で動作する AWS Backup ゲートウェイアプライアンスに接続するためのインターフェース VPC エンドポイントが、Connected VPC がある AWS アカウントで実行されます。 AWS Backup を実行するための前提条件を詳しく説明する前に、AWS Backup の基本的な用語を確認しておきましょう。 AWS Backup ゲートウェイアプライアンス ： VMware Cloud on AWS 上で動作し、AWS Backup インターフェース VPC エンドポイントを通じて、AWS Backup コントロールプレーンにプライベート接続します。バックアップゲートウェイは ESXi ホストとの通信を確立し、VMware vCenter Server を介して、すべての仮想マシンを検出し、仮想マシンスナップショットを取得したり、データのバックアップとリストアを管理します。 AWS Backup インターフェース VPC エンドポイント ： AWS Backup ゲートウェイアプライアンスから AWS Backup コントロールプレーンにプライベートでアクセスできます。 AWS Backup バックアップボールト ： バックアップデータを保管および整理するコンテナです。クロスリージョンコピーにより、事業継続やコンプライアンス要件のために、本番データから離れた場所にある複数のバックアップボールトにデータを保管することができます。 前提条件 AWS Backup インターフェース VPC エンドポイントを使用して、VMware Cloud on AWS のために AWS Backup をデプロイするには、いくつかの前提条件があります。 VMware Cloud on AWS SDDC で、vCenter Server の FQDN 解決アドレスを プライベート IP アドレス に設定します。 VMware Cloud on AWS SDDC の管理ゲートウェイ (MGW) とコンピューティングゲートウェイ (CGW) のデフォルトのドメインネームシステム (DNS) ゾーンが、組織内部の DNS サーバーを利用するように構成 されていることを確認します。 vCenter へのアクセスを許可するために、前提条件となる ファイアウォールルールを設定 します。 AWS Backup ゲートウェイアプライアンス用のコンピュートネットワークセグメントを作成します。 AWS Backup サービスを実行する AWS アカウントを指定します。 AWS Backup インターフェース VPC エンドポイントをホストする VPC を指定します。 SDDC 上で動作する AWS Backup ゲートウェイアプライアンスと、以下のいずれかにある AWS Backup インターフェース VPC エンドポイント間のネットワーク接続を確認します。 Connected VPC ： クロスアカウント Elastic Network Interface を使用して、接続が確立されています。 (作業は必要ありません) その他の VPC ： VMware Transit Connect の外部 VPC アタッチメントを使用して VPC 接続を構成します。 AWS Backup の仮想マシンのサポートを有効化します。 作業手順 ステップ 1 ：インターフェース VPC エンドポイントを作成する 以下の手順に従って、AWS Backup サービスに接続するインターフェース VPC エンドポイントを作成します。 Amazon VPC コンソールのナビゲーションペインで、 エンドポイント を選択し、 エンドポイントを作成 をクリックします。 図 2 – Amazon VPC コンソールからエンドポイントを作成 サービスカテゴリ で AWS のサービス を選択し、 サービス は com.amazonaws.ap-northeast-1.backup-gateway (東京リージョンの場合) を検索して選択します。 図 3 – AWS Backup ゲートウェイインターフェースのエンドポイントを選択 VPC では、AWS Backup インターフェース VPC エンドポイントを作成する VPC を選択します。 サブネット では、 AWS Availability Zone (AZ) ごとに 1 つのサブネットを選択します。 セキュリティグループでは、デフォルト以外の適切な セキュリティグループ を選択します。 ポリシー では、 フルアクセス または カスタム を選択して、組織の AWS セキュリティポリシーと一致する VPC エンドポイントポリシーをアタッチし、 エンドポイントを作成 をクリックします。 インターフェース VPC エンドポイントが作成されたら、 DNS 名 を記録します。 図 4 – インターフェース VPC エンドポイントの DNS 名を記録 ステップ 2 ：AWS Backup ゲートウェイを導入する 手順に従って、AWS Backup ゲートウェイを作成します。 AWS Backup コンソールのナビゲーションペインで、 外部リソース セクションの ゲートウェイ を選択し、 ゲートウェイを作成 をクリックします。 図 5 – AWS Backup コンソールから AWS Backup ゲートウェイを作成 ゲートウェイを設定 セクションで、 OVF テンプレートをダウンロード をクリックし、指示に従って AWS Backup ゲートウェイアプライアンスをデプロイします。 OVF で仮想マシンをデプロイしたら、パワーオンを行います。 これらの手順を実行するために使用するマシンや踏み台サーバーが、AWS Backup ゲートウェイアプライアンスに到達可能なネットワークに接続されていることを確認します。そうでない場合は、SDDC の NSX Manager からパブリック IP アドレスを使用して受信ネットワークアクセス変換 (NAT) ルールを構成することで、ネットワークの疎通を確保します。パブリック IP アドレスを忘れずに記録してください。 ゲートウェイの設定手順に進みます。 ゲートウェイ接続 セクションで、前の手順で設定した仮想マシンの IP アドレスを指定し、組織の命名規則に従ってゲートウェイ名を設定します。 エンドポイント のタイプで VPC でホスト を選択し、前の手順で作成した VPC エンドポイントを選択します。インターフェース VPC エンドポイントを作成し、ゲートウェイタグセクションに必要なタグ (オプション) を追加します。最後に、 ゲートウェイを作成 をクリックします。 図 6 – AWS Backup ゲートウェイを構成し、インターフェースのエンドポイントを選択 ステップ 3 ：AWS Backup ゲートウェイに vCenter ハイパーバイザーを追加する 手順に従って、VMware Cloud on AWS SDDC の vCenter Server をハイパーバイザーとして AWS Backup ゲートウェイに追加します。 AWS Backup コンソールのナビゲーションペインで、 外部リソース セクションの ハイパーバイザー を選択し、 ハイパーバイザーを追加 をクリックします。 図 7 – AWS Backup ゲートウェイにハイパーバイザーを追加 ハイパーバイザーの設定では、 ハイパーバイザー名 、 vCenter サーバーの IP アドレスまたは完全修飾ドメイン名 (FQDN)、vCenter のユーザー認証情報、組織のポリシーに一致する暗号化キー (AWS 所有またはお客様所有) を指定します。デフォルトの SDDC 管理者 ( cloudadmin@vmc.local ) を使用するか、 必要な VMware の権限 を持つサービスアカウントを作成して使用することもできます。 図 8 – 認証情報とともにハイパーバイザー (vSphere) を指定 ドロップダウンリストボックスから前の手順で作成した ゲートウェイ を選択します。次に、 ゲートウェイ接続テスト を実行してハイパーバイザーが正常に接続されていることを確認します。 ハイパーバイザーのタグ (オプション) および VMware タグマッピング (オプション) では必要なタグを追加し、 ハイパーバイザーを追加 をクリックします。デフォルト以外の AWS Identity and Access Management (IAM) ロールを使用する場合には、 kms:Decrypt アクションが含まれていることを確認し、AWS Backup が AWS Key Management Service (AWS KMS) のカスタマーマネージドキーを使用してハイパーバイザーの認証情報を暗号化および復号化できるようにします。 ハイパーバイザーが正常に追加され、接続ステータスが オンライン であることを確認します。 ステップ 4 ：VMware Cloud on AWS のファイアウォールルールを追加する 手順に従って、AWS Backup ゲートウェイと SDDC の ESXi ホスト間の通信を確保します。この手順は、AWS Backup のプロビジョニングと操作を適切に機能させるために必要です。 VMware Cloud コンソールから SDDC の NSX Manager にログインし、 セキュリティ タブから ゲートウェイファイアウォール に移動します。 管理ゲートウェイ のファイアウォールに対して以下のようにルールを追加します。 送信元 ： AWS Backup ゲートウェイアプライアンス 宛先：  ESXi サービス： プロビジョニングとリモートコンソール ( 902 ) 、HTTPS ( 443 ) ベストプラクティス VMware Cloud on AWS ワークロードに対する AWS Backup 導入に関して、以下に推奨事項を記載します。 導入においては AWS Backup インターフェースの VPC エンドポイントを常に使用し、パイロットや PoC の場合でもパブリックにアクセス可能なエンドポイントは利用しないようにします。 可能な限り、AWS Backup インターフェースの VPC エンドポイントを connected VPC 内に作成してください。VMware Transit Connect または AWS Transit Gateway を使用して AWS Backupインターフェースの VPC エンドポイントにアクセスすると、想定外のデータ処理コストの増大を招く可能性があります。 アベイラビリティゾーン (AZ) 間のデータ転送コストを回避するために、AWS Backup のインターフェース VPC エンドポイントが、VMware Cloud on AWS SDDC と同じアベイラビリティゾーン (AZ) にある VPC サブネットに作成されていることを確認してください。 以下の要素に関連するコストを評価して管理します。 インターフェース VPC エンドポイントを通じて処理される データの GB あたりのコスト ウォーム/コールド ストレージの 1 GB /月あたりのバックアップコスト ウォーム/コールド ストレージの 1 GB /月あたりのリストアコスト アイテムごとのリストア費用 (仮想マシンまたはディスクごと) クロスアベイラビリティゾーン (AZ) 料金 (該当する場合) クロスリージョン料金  (リージョンをまたがるバックアップボールトの場合) AWS Backup 監査マネージャのコスト (オプション) 必須ではありませんが、関連するタグを利用することを推奨します (ゲートウェイ、ハイパーバイザー、VMware タグマッピングなど) 。タグを使用すると、ユーザーが定義したキーと値をメタデータとして割り当てることができます。タグは、目的、所有者、環境、その他の条件に基づいて、リソースの管理、識別、整理、検索、フィルタリングを支援します。 AWS Backup は AES-256 暗号化アルゴリズムを採用していますが、カスタマーマネージドキーの自動キーローテーションを有効にすることを推奨します。 まとめ AWS Backup は、複雑なバックアップインフラストラクチャを導入および管理することなく、AWS 上の VMware Cloud で稼働する仮想マシンを保護するソリューションです。 仮想マシン向け AWS Backup の詳細につきましては、 製品ページ をご覧ください。 VMware Cloud on AWS、AWS Backup の実装、設計、ベストプラクティスに関するガイダンスについては、お気軽に お問合せ ください。 翻訳をソリューションアーキテクトの Furuya が担当しました。原文は こちら です。 リソース VMware と VMware Cloud on AWS のための AWS Backup AWS Backup 製品ドキュメント AWS Backup の価格 AWS Backup for VMware ローンチブログ

AWS Black Belt オンラインセミナー Amazon Redshift の資料及び動画をご紹介します。 過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Black Belt へのご意見、ご感想は Twitterの #awsblackbelt をご利用いただき、フィードバックをお寄せください。 Amazon Redshift Overview AWS の Analytics サービスの 1 つであるデータウェアハウス Amazon Redshift は 2012 年のサービス開始以来、データからインサイトを得るための重要な機能を数多く提供してきています。Amazon Redshift の 3 つの特徴にそって、これらの機能を幅広くご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースの導入や運用に携わるデータベース管理者 AWS 環境におけるデータウェアハウスに関心がある方 Amazon Redshift の機能を網羅的に学びたい方 本 BlackBelt で学習できること Amazon Redshift の 3 つの特徴と重要な機能を幅広く学ぶことができます。 スピーカー 池田敬之（ソリューションアーキテクト） Amazon Redshift 運用管理 Amazon Redshift は、高速、スケーラブルで費用対効果の高いデータウェアハウスのマネージドサービスで、データウェアハウスにおける運用タスクの多くが自動化・簡易化されています。本セッションでは、Amazon Redshift の運用管理について詳しく解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Redshift をご利用予定の方、あるいはご利用されている方 Amazon Redshift について深く学びたい方 本 BlackBelt で学習できること Amazon Redshift の自動化された運用タスクと、モニタリングと性能改善方法、利用者の増加に対処する方法について学ぶことができます。 スピーカー 平井健治（ソリューションアーキテクト）

この記事は Centrally manage access and permissions for Amazon Redshift data sharing with AWS Lake Formation の翻訳記事です。 現代のグローバルなデータドリブン組織は、データを資産として扱い、さまざまな事業部門 (LOB) で使用して、タイムリーな洞察とより適切なビジネス上の意思決定を推進しています。 Amazon Redshift データ共有 を使用すると、あるクラスターから別のクラスターにデータをコピーしたり移動したりすることなく、ある Amazon Redshift データウェアハウス内のトランザクションの一貫性を保ったライブデータを別の Amazon Redshift データウェアハウスと安全に共有できます。同じ AWS アカウント内、アカウント間、リージョン間でデータ共有が使用可能です。 一部のお客様は、異なるアカウントの 50 ～ 100 のデータウェアハウスとデータを共有し、相互に共有を行っているため、誰がどのデータにアクセスしているかを追跡することが困難になっています。アクセス情報を取得するには、個々のアカウントの Amazon Redshift コンソールで確認しなければいけません。また、多くのお客様は、 Amazon Simple Storage Service (Amazon S3) 上にデータレイクを持っており、さまざまなビジネスユニット内およびビジネスユニット間で共有されています。組織が成長し、データが民主化されるにつれて、管理者はガバナンスと監査のためにデータ共有を一元管理し、きめ細かいアクセス制御を適用できる機能を必要としています。 お客様からの要望から逆算して、次の新機能を発表します。Amazon Redshift データ共有と AWS Lake Formation の統合により、Amazon Redshift のお客様は AWS Lake Formation を使用して Amazon Redshift データ共有へのアクセスを一元管理できるようになります。 AWS Lake Formation は、Amazon S3 を活用したデータレイクを一元管理するための一般的な選択肢です。今回、AWS Lake Formation による Amazon Redshift データ共有のサポートにより、新しい設計パターンが増え、データウェアハウス全体のガバナンスとセキュリティ体制を広げます。この統合により、AWS Lake Formation を使用して、フェデレーテッド AWS Identity and Access Management (IAM) ユーザーおよび IAM ロールに Amazon Redshift データ共有で共有されているテーブルおよびビューに対するきめ細かいアクセス制御を定義できます。 お客様は、ビジネスユニット間でデータを共有するメカニズムを提供する データメッシュ のアプローチを用いています。また、お客様は モダンデータアーキテクチャ を使用して、データレイクストアや Amazon Redshift のマネージドストレージからのデータをビジネスユニット間で共有しています。 AWS Lake Formation は、ビジネスユニット内およびビジネスユニット全体にデータガバナンスを適用する機能を提供します。これにより、安全なデータアクセスと共有、簡単なデータ検出、およびデータアクセスの集中監査が可能になります。 ユナイテッド航空 は人々をつなぎ、世界を一つにする事業を行っています。 「データ駆動型企業として、ユナイテッド航空は、革新的なモダンデータ駆動型アプリケーションを構築する分析コミュニティ向けに統合されたデータと分析エクスペリエンスを生み出そうとしています。 我々は、Athena、Aurora、Amazon Redshift、AWS Lake Formation などのさまざまな AWS サービスを使用して Purpose Built なデータメッシュ アーキテクチャを構築し、きめ細かいデータアクセスとコラボレーションに関する管理とガバナンスを簡素化することで、これを達成できると考えています。」 -Ashok Srinivas, Director of ML Engineering and Sarang Bapat, Director of Data Engineering. この投稿では、AWS Lake Formation を使って Amazon Redshift データ共有のアクセスと権限を一元管理する方法を示します。 ソリューション概要 このソリューションでは、データガバナンスのために Amazon Redshift データ共有と AWS Lake Formation を統合することがデータドメインの構築にどのように役立つか、またデータメッシュアプローチを使用してデータドメインを統合し、ビジネスユニット全体でのデータ共有とフェデレーションを可能にする方法を示します。次の図は、ソリューションのアーキテクチャを示しています。 データメッシュは、分散型のドメイン指向のアーキテクチャです。一元管理されたフェデレーテッドデータカタログを介してデータプロデューサーとデータコンシューマーを分離することを重視しています。通常、プロデューサーとコンシューマーはそれぞれ独自のアカウント内で運用されます。これらのデータメッシュ特性の詳細は次のとおりです。 データプロデューサー – データプロデューサーはデータプロダクトを所有し、データの生成や正確性の維持、データプロダクトを最新の状態に保つ責任があります。データプロデューサーはどのデータセットを公開して利用できるかを決定し、セントラルガバナンスアカウントの一元管理されたデータカタログにデータセットを登録することでデータセットを共有します。セントラルのガバナンススチュワードまたは管理者チームとともにデータプロダクトを管理するためのプロデューサー側のスチュワードまたは管理者が存在する場合があります。 セントラルガバナンスアカウント – AWS Lake Formation により、共有データセットに対するきめ細かいアクセス管理が可能になります。一元化されたデータカタログにより、コンシューマーは共有データセットをすばやく検索できるようになり、管理者は共有データセットに対するアクセス許可を一元管理できるようになり、セキュリティチームはビジネスユニット全体でのデータプロダクトの使用状況を監査および追跡できるようになります。 データコンシューマー – データコンシューマーは、セントラルガバナンス アカウントから共有リソースへのアクセスを取得します。これらのリソースはコンシューマーの AWS Glue データカタログ内で利用できるため、コンシューマー側のデータスチュワードや管理者が管理できるデータベースやテーブルへのきめ細かいアクセスが可能になります。 次の手順では、データメッシュアーキテクチャのセントラルガバナンスパターンで、AWS Lake Formation によって Amazon Redshift データ共有をどのように統制管理できるかの概要を示します。 プロデューサーアカウントでは、 Amazon Redshift プロデューサークラスター内にデータオブジェクトが作成および維持されます。データウェアハウス管理者は、Amazon Redshift データ共有を作成し、データセット (テーブル、ビュー) を共有に追加します。 データウェアハウス管理者は、セントラルガバナンスアカウントのデータカタログへのデータ共有へのアクセスを許可します。 セントラルガバナンスアカウントでは、データレイク管理者が AWS Lake Formation で管理できるようにAmazon Redshift データ共有を受け入れ、 そのデータ共有を指す AWS Glue データベースを作成します。 データレイク管理者は、 AWS Lake Formation のクロスアカウント共有 を使用して、AWS Glue データベースとテーブルをコンシューマーアカウントと共有します。 コンシューマーアカウントでは、データレイク管理者は AWS Resource Access Manager (AWS RAM) 経由でリソース共有の招待を受け入れるとデータベースがリストされているのが確認できます。 データレイク管理者は、きめ細かいアクセス制御を定義し、アカウント内の IAM ユーザー (この投稿では consumer1 と consumer2 ) にデータベースとテーブルに対するアクセス許可を付与します。 Amazon Redshift クラスターでは、データウェアハウス管理者が Glue データベースを指す Amazon Redshift データベースを作成し、作成された Amazon Redshift データベースの使用を IAM ユーザーに許可します。 IAM ユーザーとしてのデータアナリストは、Amazon Redshift クエリエディタなどの好みのツールを使用して、AWS Lake Formation のきめ細かい権限に基づいてデータセットにアクセスできるようになります。 この投稿の例では、次のアカウント設定を使用します。 プロデューサーアカウント – 123456789012 セントラルアカウント – 112233445566 コンシューマーアカウント – 665544332211 前提条件 Amazon Redshift データ共有を作成し、データセットを追加する プロデューサーアカウントで、暗号化を有効にした RA3 ノードタイプを使用して Amazon Redshift クラスターを作成します。次の手順を実行します。 Amazon Redshift コンソールで、 クラスターサブネットグループ を作成します。 詳細については、「 コンソールを使用したクラスター サブネット グループの管理 」を参照してください。 [Create cluster] を選択します。 [Cluster identifier] には、選択したクラスター名を指定します。 [Node type] で、RA3 ノードタイプのいずれかを選択します。 この機能は、RA3 ノードタイプでのみサポートされます。 [Number of nodes] に、クラスターに必要なノードの数を入力します。 [Database configurations] で、管理者ユーザー名と管理者ユーザーのパスワードを選択します。 [Cluster permissions] で、IAM ロールを選択し、それをデフォルトとして設定できます。 デフォルトの IAM ロールの詳細については、「 Amazon Redshift 用にデフォルトの IAM ロールを作成する 」を参照してください。 デフォルト設定を変更するには、 [Additional configurations] の横にある [Use defaults] オプションをオンにします。 [Network and security] で、次のように指定します。 [Virtual private cloud (VPC)] では、クラスターをデプロイする VPC を選択します。 [VPC security groups] では、デフォルトのままにするか、適切なセキュリティ グループを追加します。 [Cluster subnet group] で、作成したクラスターサブネットグループを選択します。 [Database configuration] の [Encryption] セクションで、[Use AWS Key Management Service (AWS KMS)] または [Use a hardware security module (HSM)] を選択します。 暗号化はデフォルトでは無効になっています。 [Choose an AWS KMS key] では、既存の AWS Key Management Service (AWS KMS) キーを選択する、もしくは [Create an AWS KMS key] を選択して、新しいキーを作成することができます。 新しいキーを作成する場合には、「 キーの作成 」を参照してください。 [Create cluster] を選択します。 この投稿では、次の スクリプト を使用してテーブルを作成し、プロデューサーの Amazon Redshift クラスターにデータをロードします。 データ共有の承認 AWS Command Line Interface (AWS CLI) の最新バージョンをインストールまたは更新して、AWS CLI を実行してデータ共有を承認します。手順については、「 AWS CLI の最新バージョンのインストールまたは更新 」を参照してください。 AWS Lake Formation の権限を設定 AWS Lake Formation で AWS Glue データカタログを使用するには、セントラルガバナンスアカウントで次の手順を実行して、IAM ベースのアクセス制御ではなく、Lake Formation のアクセス許可を使用してカタログリソースを制御するようにデータカタログ設定を更新します。 AWS Lake Formation コンソール に管理者としてサインインします。 ナビゲーション ウィンドウの [Data catalog] で、 [Settings] を選択します。 [Use only IAM access control for new databases] の選択を解除します。 [Use only IAM access control for new tables in new databases] の選択を解除します。 [Cross account version settings] で [Version 3] を選択します。 [Save] を選択します。 IAM ユーザーをデータレイク管理者として設定する 既存のデータレイク管理者ユーザーまたはロールを使用している場合は、次の管理ポリシーを追加し、以下のセットアップ手順をスキップします。 AWSGlueServiceRole AmazonRedshiftFullAccess それ以外の場合、IAM ユーザーをデータレイク管理者として設定するには、次の手順を実行します。 IAM コンソールのナビゲーションペインで [Users] を選択します。 データレイク管理者として指定する IAM ユーザーを選択します。 [Permissions] タブで [Add an inline policy] を選択します。 <AccountID> を自分のアカウント ID に置き換え、次のポリシーを追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action":"iam:CreateServiceLinkedRole", "Resource": "*", "Condition": { "StringEquals": { "iam:AWSServiceName":"lakeformation.amazonaws.com" } } }, { "Effect": "Allow", "Action": ["iam:PutRolePolicy"], "Resource": "arn:aws:iam::<AccountID>:role/aws-service role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormationDataAccess" }, { "Effect": "Allow", "Action": [ "ram:AcceptResourceShareInvitation", "ram:RejectResourceShareInvitation", "ec2:DescribeAvailabilityZones", "ram:EnableSharingWithAwsOrganization" ], "Resource": "*" } ] } JSON ポリシー名を指定します。 設定を確認して保存します。 [Add permissions] ボタンを選択し、[Attach existing policies directly] を選択します。 次のポリシーを追加します。 AWSLakeFormationCrossAccountManager AWSGlueConsoleFullAccess AWSGlueServiceRole AWSLakeFormationDataAdmin AWSCloudShellFullAccess AmazonRedshiftFullAccess [Next: Review and add permissions] を選択します。 データコンシューマーアカウントの設定 コンシューマー アカウントでは、セントラルガバナンスアカウントで前述した手順に従って、AWS Lake Formation とデータレイク管理者をセットアップします。 データコンシューマーアカウントで、暗号化付きの RA3 ノードタイプを使用して Amazon Redshift クラスターを作成します (プロデューサーアカウントで Amazon Redshift クラスターを作成する手順を参照してください)。 [Launch Stack] を選択して AWS CloudFormation テンプレートをデプロイし、ポリシーを持つ 2 人の IAM ユーザーを作成します。 スタックは、データアナリストとして次のユーザーを作成します consumer1 consumer2 CloudFormation スタックが作成されたら、スタックの [Outputs] タブに移動します。 ConsoleIAMLoginURL と LFUsersCredentials の値を取得します。 LFUsersCredentials の値を選択して、 AWS Secrets Manager コンソールに移動します。 [Secret value] セクションで、[Retrieve secret value] を選択します。 パスワードのシークレット値を取得します。 consumer1 と consumer2 はどちらも、 AWSマネジメントコンソール にログインするために、これと同じパスワードを使用する必要があります。 AWS Lake Formation を使用して Amazon Redshift データ共有を設定する プロデューサーアカウント コンソールを使用してデータ共有を作成 プロデューサーアカウントで Amazon Redshift データ共有を作成し、セントラルアカウントの AWS Lake Formation と共有するには、次の手順を実行します。 Amazon Redshift コンソールで、データ共有を作成するクラスターを選択します。 クラスターの詳細ページで、 [Datashares] タブに移動します。 [Datashares created in my namespace] で、[Connect to database] を選択します。 [Create datashare] を選択します。 [Datashare type]として、[Datashare] を選択します。 [Datashare name] に名前を入力します (この投稿では、demotahoeds)。 [Database name] で、データ共有オブジェクトを追加するデータベースを選択します (この投稿では dev) 。 [Publicly accessible] で、[Turn off] を選択します (または、パブリックにアクセス可能なクラスターとデータ共有を共有するには [Turn on] を選択します)。 [DataShare objects] で、[Add] を選択してスキーマをデータ共有に追加します (この投稿ではパブリック スキーマ) 。 [Tables and views] で [Add] を選択し、テーブルとビューをデータ共有に追加します (この投稿では、テーブル customer とビュー customer_view を追加します)。 [Data consumers] で、[Publish to AWS Data Catalog] を選択します。 [Publish to the following accounts] で、[Other AWS accounts] を選択します。 コンシューマーアカウントの AWS アカウント ID を指定します。この投稿では、Lake Formation 中央ガバナンス アカウントの AWS アカウント ID を提供します。 同じアカウント内で共有するには、[Local account] を選択します。 [Create datashare] を選択します。 データ共有が作成されたら、[Datashares] タブに戻り、 [Datashares created in my namespace] の下の検索バーにデータ共有名を入力して確認できます。 データ共有名を選択すると、その詳細が表示されます。 [Data consumers] の下に、コンシューマーアカウントのデータカタログのコンシューマーのステータスが [Pending Authorization] として表示されます。 コンシューマーデータカタログのチェックボックスを選択すると、 [Authorize] ボタンが有効になります。 [Authorize] をクリックして、コンシューマーアカウントのデータカタログへのデータ共有アクセスを承認すると、コンシューマーのステータスが [Authorized] に変わります。 SQL コマンドを使用してデータ共有を作成する プロデューサーアカウントでデータ共有を作成し、セントラルアカウントの AWS Lake Formation と共有するには、次の手順を実行します。 Amazon Redshift コンソールのナビゲーションペインで、[Query editor V2] を選択します。 クラスター名を選択 (右クリック) し、[Edit connection] または [Create Connection] を選択します。 [Authentication] で、[Temporary credentials] を選択します。 さまざまな認証方法の詳細については、「 Amazon Redshift データベースに接続する 」を参照してください。 [Database] にデータベース名を入力します (この投稿では dev) 。 [User name] に、データベースへのアクセスを許可されたユーザーを入力します (この投稿では awsuser) 。 [Save] を選択してデータベースに接続します。 次の SQL コマンドを実行してデータ共有を作成し、共有するデータオブジェクトを追加します。 create datashare demotahoeds ; ALTER DATASHARE demotahoeds ADD SCHEMA PUBLIC ; ALTER DATASHARE demotahoeds ADD TABLE customer ; ALTER DATASHARE demotahoeds ADD TABLE customer_view ; Bash 次の SQL コマンドを実行して、プロデューサーのデータ共有をセントラルガバナンスアカウントと共有します。 GRANT USAGE ON DATASHARE demotahoeds TO ACCOUNT ' <central-aws-account-id> ' via DATA CATALOG Bash 次の SQL コマンドを実行すると、作成されたデータ共有と共有されたオブジェクトを確認できます。 DESC DATASHARE demotahoeds Bash AWS CLI を使用して次のコマンドを実行して、セントラルデータカタログに対するデータ共有を承認し、AWS Lake Formation がデータ共有を管理できるようにします。 AWS マネジメントコンソールを使用して承認する手順については、「 データ共有の承認と承認の取り消し 」を参照してください。 aws redshift authorize-data-share \ --data-share-arn 'arn:aws:redshift: <producer-region> : <producer-aws-account-id> :datashare: <producer-cluster-namespace> /demotahoeds' \ --consumer-identifier DataCatalog/ <central-aws-account-id> Code 以下は出力例です。 { "DataShareArn": "arn:aws:redshift:us-east-1:XXXXXXXXXX:datashare:cd8d91b5-0c17-4567-a52a-59f1bdda71cd/demotahoeds", "ProducerArn": "arn:aws:redshift:us-east-1:XXXXXXXXXX:namespace:cd8d91b5-0c17-4567-a52a-59f1bdda71cd", "AllowPubliclyAccessibleConsumers": false, "DataShareAssociations": [{ "ConsumerIdentifier": "DataCatalog/XXXXXXXXXXXX", "Status": "AUTHORIZED", "CreatedDate": "2022-11-09T21:10:30.507000+00:00", "StatusChangeDate": "2022-11-09T21:10:50.932000+00:00" }] } JSON 前のセクションで説明した手順に従って、コンソールでデータ共有のステータスを確認できます。 セントラルカタログアカウント データレイク管理者は、セントラルガバナンスアカウントで AWS Lake Formation とのデータ共有を受け入れて登録し、同様にデータベースを作成します。次の手順を実行します。 データレイク管理者の IAM ユーザーまたはロールとしてコンソールにサインインします。 AWS Lake Formation コンソールに初めてログインする場合は、[Add myself] を選択し、[Get Started] を選択します。 ナビゲーションペインの [Data catalog] で、 [Data sharing] を選択し、 [Configuration] タブで Amazon Redshift データ共有の Invitations を表示します。 データ共有を選択し、[Review invitation] を選択します。 invitation の詳細を示すウィンドウが表示されます。 [Accept] を選択して、Amazon Redshift データ共有を AWS Glue データカタログに登録します。 AWS Glue データベースの名前を入力し、[Skip to Review and create] を選択します。 内容を確認し、[Create database] を選択します。 AWS Glue データベースが Amazon Redshift データ共有上に作成されると、それらのデータベースを [Shared databases] で表示できます。 AWS CLI を使用してデータ共有を登録し、データベースを作成することもできます。次のコマンドを使用します。 セントラルアカウントと共有される Amazon Redshift データ共有について確認します。 aws redshift describe-data-shares Bash Amazon Redshift データ共有を受け入れて Data Catalog に関連付けます。 aws redshift associate-data-share-consumer \ --data-share-arn 'arn:aws:redshift: <producer-region> : <producer-aws-account-id> :datashare: <producer-cluster-namespace> /demotahoeds' \ --consumer-arn arn:aws:glue:us-east-1: < central-aws-account-id > :catalog Bash 以下は出力例です。 { "DataShareArn": "arn:aws:redshift:us-east-1:123456789012:datashare:cd8d91b5-0c17-4567-a52a-59f1bdda71cd/demotahoeds", "ProducerArn": "arn:aws:redshift:us-east-1:123456789012:namespace:cd8d91b5-0c17-4567-a52a-59f1bdda71cd", "AllowPubliclyAccessibleConsumers": false, "DataShareAssociations": [ { "ConsumerIdentifier": "arn:aws:glue:us-east-1:112233445566:catalog", "Status": "ACTIVE", "ConsumerRegion": "us-east-1", "CreatedDate": "2022-11-09T23:25:22.378000+00:00", "StatusChangeDate": "2022-11-09T23:25:22.378000+00:00" } ] } JSON AWS Lake Formation に Amazon Redshift データ共有を登録します。 aws lakeformation register-resource \ --resource-arn arn:aws:redshift: < producer-region > : < producer-aws-account-id > :datashare: < producer-cluster-namespace > /demotahoeds Bash 受け入れられた Amazon Redshift データ共有を指す AWS Glue データベースを作成します。 aws glue create-database --region <central-catalog-region> --cli-input-json '{ "CatalogId": " <central-aws-account-id> ", "DatabaseInput": { "Name": "demotahoedb", "FederatedDatabase": { "Identifier": "arn:aws:redshift: <producer-region> : <producer-aws-account-id> :datashare: <producer-cluster-namespace> /demotahoeds", "ConnectionName": "aws:redshift" } } }' JSON これで、セントラルガバナンスアカウントのデータレイク管理者は、AWS Lake Formation のクロスアカウント共有機能を使用して、データベースとテーブルの両方に対するコンシューマーアカウントへのアクセスを表示および共有できるようになりました。 データコンシューマーにデータ共有アクセスを許可する 共有された AWS Glue データベースに対するコンシューマーアカウントへのアクセス許可を付与するには、次の手順を実行します。 AWS Lake Formation コンソールのナビゲーションペインの [Permissions] で、 [Data lake permissions] を選択します。 [Grant] を選択します。 [Principals] で、 [External accounts] を選択します。 コンシューマーアカウント ID を入力して Enter キーを押します (この投稿では 665544332211)。 [LF-Tags or catalog resources] で、 [Named data catalog resources] を選択します。 [Databases] では、データベース demotahoedb を選択します。 [Database permissions] と [Grantable permissions] の両方に [Describe] を選択します。 [Grant] を選択します。 コンシューマーアカウントにテーブルに対するアクセス許可を付与するには、次の手順を実行します。 AWS Lake Formation コンソールのナビゲーション ペインの [Permissions] で、[Data lake permissions] を選択します。 [Grant] を選択します。 [Principals] で、 [External accounts] を選択します。 コンシューマーアカウントを指定します (この投稿では 665544332211 を使用します)。 [LF-Tags or catalog resources] で、 [Named data catalog resources] を選択します。 [Databases] では、データベース [demotahoedb] を選択します。 [Tables] で、 [All tables] を選択します。 [Table permissions] と [Grantable permissions] の両方で [Describe] と [Select] を選択します。 [Grant] を選択して変更を適用します。 コンシューマーアカウント コンシューマー管理者はセントラルガバナンスアカウントから共有リソースを受け取り、次の表に示すように、コンシューマーアカウント内の他のユーザーにアクセスを委任します。 IAM User Object Access Object Type Access Level consumer1 public.customer Table All consumer2 public.customer_view View specific columns: c_customer_id , c_birth_country , cd_gender , cd_marital_status , cd_education_status データ コンシューマー アカウントで、次の手順に従って、アカウントと共有されているリソースを受け入れます。 データレイク管理者の IAM ユーザーまたはロールとしてコンソールにサインインします。 AWS Lake Formation コンソールに初めてログインする場合は、[Add myself] を選択し、[Get Started] を選択します。 AWS RAM コンソールにサインインします。 ナビゲーション ウィンドウの [Shared with me] で [Resource shares] を選択し、保留中の Invitation を表示します。2 つの Invitation を受け取ります。 保留中の Inviation を選択し、リソース共有を受け入れます。 AWS Lake formation コンソールのナビゲーションペインの [Data catalog] で、[Databases] を選択して、クロスアカウント共有データベースを表示します。 AWS Lake Formation を使用してデータアナリストと IAM ユーザーにアクセスを許可する これで、コンシューマーアカウントのデータレイク管理者は、共有データベースとテーブルに対するアクセス許可をコンシューマーアカウントのユーザーに委任できるようになりました。 consumer1 と consumer2 にデータベース権限を付与する IAM ユーザー consumer1 と consumer2 にデータベース権限を付与するには、次の手順に従います。 AWS Lake Formation コンソールのナビゲーション ペインの [Data catalog] で、 [Databases] を選択します。 データベース demotahoedb を選択し、 [Actions] メニューから [Grant] を選択します。 [Principals] で、 [IAM users and roles] を選択します。 IAM ユーザー consumer1 と consumer2 を選択します。 [LF-Tags or catalog resources] では、demotahoedb がデータベースとしてすでに選択されています。 [Database permissions] で [Describe] を選択します。 [Grant] を選択して権限を適用します。 consumer1 にテーブル権限を付与する IAM ユーザー consumer1 にテーブル public.customer に対するアクセス許可を付与するには、次の手順に従います。 ナビゲーション ペインの [Data catalog] で、 [Databases] を選択します。 データベース demotahoedb を選択し、「Actions」メニューから「Grant」を選択します。 [Principals] で、 [IAM users and roles] を選択します。 IAM ユーザー consumer1 を選択します。 [LF-Tags or catalog resources] では、 demotahoedb がデータベースとしてすでに選択されています。 [Tables] で、 public.customer を選択します。 [Table permissions] で [Describe] と [Select] を選択します。 [Grant] を選択して権限を適用します。 consumer2 に列権限を付与する IAM ユーザー consumer2 に public.customer_view の機密情報ではない列に対するアクセス許可を付与するには、次の手順に従います。 ナビゲーション ペインの [Data catalog] で、 [Databases] を選択します。 データベース demotahoedb を選択し、 [Actions] メニューから [Grant] を選択します。 [Principals] で、 [IAM users and roles] を選択します。 IAM ユーザー consumer2 を選択します。 [LF-Tags or catalog resources] では、 demotahoedb がデータベースとしてすでに選択されています。 [Tables] で、 public.customer_view を選択します。 [Table permissions] で [Select] を選択します。 [Data permissions] で、 [Column-based access] を選択します。 [Include columns] を選択し、機密情報ではない列 ( c_customer_id 、 c_birth_country 、 cd_gender 、 cd_marital_status 、および cd_education_status ) を選択します。 [Grant] を選択して権限を適用します。 コンシューマーアカウントの Amazon Redshift クラスターからデータ共有の利用設定を行う コンシューマー 用の Amazon Redshift データウェアハウスで、Query Editor V2 を使用して管理者ユーザーとしてログインし、次の手順を実行します。 次の SQL コマンドを使用して、共有されたカタログデータベースから Amazon Redshift データベースを作成します。 CREATE DATABASE demotahoedb FROM ARN 'arn:aws:glue: <central-region> : <central-aws-account-id> :database/demotahoedb' WITH DATA CATALOG SCHEMA demotahoedb ; SQL 次の SQL コマンドを実行して、Amazon Redshift データベースを作成し、IAM ユーザー consumer1 と consumer2 に作成したデータベースに対して USAGE の許可を与えます。 CREATE USER IAM:consumer1 password disable ; CREATE USER IAM:consumer2 password disable ; GRANT USAGE ON DATABASE demotahoedb TO IAM:consumer1 ; GRANT USAGE ON DATABASE demotahoedb TO IAM:consumer2 ; Bash AWS Lake Formation アクセス許可を強制するために IAM 認証を利用します。次の手順に従ってクエリエディタ v2 を設定します。 クエリエディタ v2 の左下隅にある設定アイコンを選択し、[Account Settings] を選択します。 [Connection settings] で、[Authenticate with IAM credentials] を選択します。 [Save]を選択します。 コンシューマーユーザーとして共有データセットをクエリする IAM ユーザー consumer1 が Amazon Redshift からデータ共有アクセス権があることを検証するには、次の手順を実行します。 IAM ユーザー consumer1 としてコンソールにサインインします。 Amazon Redshift コンソールのナビゲーションペインで [Query Editor V2] を選択します。 コンシューマークラスタに接続するには、ツリー ビュー ペインでコンシューマークラスタを選択します。 プロンプトが表示されたら、 [Authentication] で [Temporary credentials using your IAM identity] を選択します。 [Database] にデータベース名を入力します (この投稿では dev ) 。 ユーザー名は現在の IAM アイデンティティ にマッピングされます(この投稿では consumer1 )。 [Save] を選択します。 データベースに接続したら、次の SQL コマンドを使用して、現在ログインしているユーザーを確認できます。 select current_user ; Bash コンシューマーアカウントで作成されたフェデレーションデータベースを検索するには、次の SQL コマンドを実行します。 SHOW DATABASES FROM DATA CATALOG [ ACCOUNT ' <id1> ' , ' <id2> ' ] [ LIKE 'expression' ] ; Bash consumer1 の権限を検証するには、次の SQL コマンドを実行します。 select * from demotahoedb.public.customer limit 10 ; Bash 次のスクリーンショットに示すように、 consumer1 はデータ共有の customer オブジェクトに正常にアクセスできます。 では、 consumer2 が同じコンシューマークラスタ上のデータ共有テーブル「public.customer」にアクセスできないことを検証してみましょう。 コンソールからログアウトし、IAM ユーザー consumer2 としてサインインします。 同じ手順に従って、クエリエディタ v2 を使用してデータベースに接続します。 接続できたら、同じクエリを実行します。 select * from demotahoedb.public.customer limit 10 ; Bash ユーザー consumer2 は、次のスクリーンショットに示すように、アクセスの拒否エラーを受け取るはずです。 consumer2 に対する public.customer_view ビューの 列レベルのアクセス権限を検証してみましょう。 consumer2 としてクエリエディタ v2 に接続し、次の SQL コマンドを実行します。 select c_customer_id,c_birth_country,cd_gender,cd_marital_status from demotahoedb.public.customer_view limit 10 ; Bash 次のスクリーンショットでは、consumer2 が AWS Lake Formation によって許可された列にのみアクセスできることがわかります。 まとめ データメッシュアプローチは、組織がビジネスユニット間でデータを共有できる方法を提供します。各ドメインは、データの取り込み、データ処理、データの提供を担当します。ドメインの担当者は、データ所有者でありドメインの専門家であり、データの品質と正確性に対して責任を負います。データガバナンスのために AWS Lake Formation と Amazon Redshift データ共有を使用すると、データメッシュアーキテクチャの構築が容易になり、きめ細かいアクセス制御によるビジネスユニット間のデータ共有とフェデレーションが可能になります。 AWS Lake Formation との Amazon Redshift データ共有の開始に貢献していただいた皆様に心より感謝いたします。 Debu Panda, Michael Chess, Vlad Ponomarenko, Ting Yan, Erol Murtezaoglu, Sharda Khubchandani, Rui Bi 参考情報 Modern Data Architecture on AWS Designing a data lake for growth and scale on the AWS Cloud Design a data mesh architecture using AWS Lake Formation and AWS Glue 翻訳はソリューションアーキテクトの池田 敬之が担当しました。