TECH PLAY

AWS

AWS の技術ブログ

3167

9月20日より、Apple プラットフォーム ( iOS 、 iPadOS 、 macOS 、 tvOS 、 watchOS 、 visionOS )、または サーバー側で実行されている Swift アプリケーション 用のコードを記述する Swift デベロッパーは、 AWS CodeArtifact を利用して、パッケージの依存関係を安全に保存および取得できます。CodeArtifact は、 Xcode 、 xcodebuild 、 Swift Package Manager ( swift package コマンド) などの標準的なデベロッパーツールと統合します。 シンプルなアプリケーションには通常、数十のパッケージが含まれています。大規模なエンタープライズアプリケーションには、何百もの依存関係が存在する場合があります。これらのパッケージは、ネットワークアクセス、暗号化機能、データ形式の操作などの一般的なプログラミングの課題を解決するコードを提供することで、デベロッパーが開発とテストのプロセスをスピードアップするのに役立ちます。また、デベロッパーは、リモートサービスにアクセスするために、 AWS SDK などの SDK を埋め込みます。これらのパッケージは、組織内の他のチームによって作成されたり、オープンソースプロジェクトなどのサードパーティーによって保守されたりする場合があります。パッケージとその依存関係の管理は、ソフトウェア開発プロセスの不可欠な部分です。最新のプログラミング言語には、依存関係をダウンロードして解決するためのツールが含まれています。Java の Maven 、C# の NuGet 、JavaScript の npm または yarn 、Python の pip はその一例です。Apple プラットフォームのデベロッパーは、 CocoaPods または Swift Package Manager (SwiftPM) を使用します。 パッケージのダウンロードと統合は、アプリケーションデベロッパーにとって日常的な業務です。ただし、組織にとっては少なくとも 2 つの重大な課題が生じます。 1 つ目の課題は法務関連です。組織は、サードパーティーパッケージのライセンスが、特定のプロジェクトで想定されるライセンスの使用と互換性があるようにするとともに、およびパッケージが他者の知的財産 (IP) を侵害していないようにする必要があります。2 つ目の課題はセキュリティです。組織は、含まれているコードが安全に使用できるものであるようにするとともに、アプリケーションにセキュリティ上の欠陥を導入するために設計されたバックドアや意図的な脆弱性が含まれていないようにする必要があります。人気のオープンソースプロジェクトに脆弱性を挿入することは、 サプライチェーン攻撃 として知られており、近年ますます発生件数が増加しています。 これらの課題に対処するために、組織は通常、プライベートパッケージサーバーをオンプレミスまたはクラウドでインストールします。デベロッパーは、組織のセキュリティチームと法務チームによって精査され、かつ、プライベートリポジトリを通じて使用できるパッケージのみを使用できます。 AWS CodeArtifact は、社内のデベロッパーチームにパッケージを安全に配布できるようにするマネージドサービスです。基盤となるインフラストラクチャをインストール、管理、スケールする必要はありません。当社がそれを処理するため、お客様は、ソフトウェア開発インフラストラクチャではなく、アプリケーション関連の業務により多くの時間を費やすことができます。 CodeArtifact が npm 、 PyPI 、 Maven 、 NuGet 、 汎用 パッケージ形式に加えて、ネイティブ Swift パッケージをサポートするようになったことをお知らせします。Swift パッケージは、再利用可能な Swift コード要素をパッケージ化して配布するための方法として広く利用されています。独自の Swift パッケージを作成する方法を学ぶには、 このチュートリアル に従ってください。または、コミュニティは、Swift アプリケーションで使用できる 6,000 を超える Swift パッケージ を作成しました。 AWS クラウドの CodeArtifact リポジトリで Swift パッケージの依存関係を公開およびダウンロードできるようになりました。CodeArtifact SwiftPM は、 Xcode 、 VSCode 、 Swift Package Manager コマンドラインツール などの既存のデベロッパーツールと連携して動作します。パッケージが CodeArtifact に保存されたら、Git エンドポイントを使用してパブリック Swift パッケージにアクセスするのと同様の方法で、プロジェクトの Package.swift ファイルまたは Xcode プロジェクトでそれらのパッケージを参照できます。 設定が完了すると、ネットワークジェイル化された構築システムが CodeArtifact リポジトリからパッケージをダウンロードし、アプリケーションの構築プロセス中に承認および制御されたパッケージのみが使用されるようにします。 開始方法 このブログではいつものように、その仕組みを説明します。 Amazon DynamoDB をデータベースとして利用する iOS アプリケーションについて作業していると仮定してください。私のアプリケーションには、依存関係として AWS SDK for Swift が埋め込まれています。私の組織のポリシーに準拠するために、アプリケーションは社内でコンパイルされ、組織の法務チームとセキュリティチームによって承認された特定のバージョンの AWS SDK for Swift を使用する必要があります。このデモでは、環境を準備し、パッケージをリポジトリにアップロードして、この特定のパッケージビルドをプロジェクトの依存関係として使用する方法を示します。 このデモでは、Swift パッケージに固有のステップについて中心的に説明します。 CodeArtifact の利用を開始するに際して、同僚の Steven が作成したチュートリアル が参考になります。 パッケージ リポジトリ ( MySwiftRepo ) と ドメイン ( stormacq-test ) が既に設定されている AWS アカウントを使用します。 SwiftPM が CodeArtifact リポジトリにアクセスできるようにするために、まず CodeArtifact から認証トークンを収集します。 export CODEARTIFACT_AUTH_TOKEN=`aws codeartifact get-authorization-token \ --domain stormacq-test \ --domain-owner 012345678912 \ --query authorizationToken \ --output text` 認証トークンは 12 時間後に期限切れになることに注意してください。12 時間が経過すると、新しいトークンを取得するためにこのコマンドを繰り返す必要があります。 その後、リポジトリエンドポイントをリクエストします。 ドメイン 名と ドメイン所有者 (AWS アカウント ID) を渡します。 --format swift オプションに注目してください。 export CODEARTIFACT_REPO=`aws codeartifact get-repository-endpoint \ --domain stormacq-test \ --domain-owner 012345678912 \ --format swift \ --repository MySwiftRepo \ --query repositoryEndpoint \ --output text` リポジトリエンドポイントと認証トークンを取得したので、 AWS コマンドラインインターフェイス (AWS CLI) を使用してマシン上で SwiftPM を設定します。 SwiftPM は、 ユーザーレベル (ファイル ~/.swiftpm/configurations 内) または プロジェクトレベル (ファイル <お客様のプロジェクト>/.swiftpm/configurations 内) でリポジトリ設定を保存できます。デフォルトでは、CodeArtifact ログインコマンドはプロジェクトレベルの設定を作成し、異なるプロジェクトに異なる CodeArtifact リポジトリを使用できるようにします。 AWS CLI を使用して、ビルドマシンで SwiftPM を設定します。 aws codeartifact login \ --tool swift \ --domain stormacq-test \ --repository MySwiftRepo \ --namespace aws \ --domain-owner 012345678912 このコマンドは、正しいオプションを使用して swift package-registry login を呼び出します。これにより、指定されたリポジトリ名 ( MySwiftRepo ) とスコープ名 ( aws ) を使用して必要な SwiftPM 設定ファイルが作成されます。 ビルドマシンの準備ができたので、私の組織が承認したバージョンの AWS SDK for Swift パッケージを準備し、それをリポジトリにアップロードします。 git clone https://github.com/awslabs/aws-sdk-swift.git pushd aws-sdk-swift swift package archive-source mv aws-sdk-swift.zip ../aws-sdk-swift-0.24.0.zip popd 最後に、このパッケージバージョンをリポジトリにアップロードします。 Swift 5.9 以降を使用している場合は、SwiftPM コマンドを使用してパッケージをプライベートリポジトリにアップロードできます。 swift package-registry publish \ aws.aws-sdk-swift \ 0.24.0 \ --verbose 5.9 よりも前のバージョンの Swift は、 swift package-registry publish コマンドを提供しません。そのため、代わりに curl コマンドを使用します。 curl -X PUT --user "aws:$CODEARTIFACT_AUTH_TOKEN" \ -H "Accept: application/vnd.swift.registry.v1+json" \ -F source-archive="@aws-sdk-swift-0.24.0.zip" \ "${CODEARTIFACT_REPO}aws/aws-sdk-swift/0.24.0" リポジトリの URI の後のパッケージ名の形式に注目してください: <スコープ>/<パッケージ名>/<パッケージバージョン> 。パッケージバージョンは、 セマンティックバージョニング スキームに従う必要があります。 CLI またはコンソールを使用して、パッケージがリポジトリで利用可能であることを確認できます。 aws codeartifact list-package-versions \ --domain stormacq-test \ --repository MySwiftRepo \ --format swift \ --namespace aws \ --package aws-sdk-swift { "versions": [ { "version": "0.24.0", "revision": "6XB5O65J8J3jkTDZd8RMLyqz7XbxIg9IXpTudP7THbU=", "status": "Published", "origin": { "domainEntryPoint": { "repositoryName": "MySwiftRepo" }, "originType": "INTERNAL" } } ], "defaultDisplayVersion": "0.24.0", "format": "swift", "package": "aws-sdk-swift", "namespace": "aws" } パッケージが使用可能になったので、いつものようにプロジェクトで使用できます。 Xcode は、SwiftPM ツールと、作成したばかりの設定ファイルを使用します。Xcode プロジェクトにパッケージを追加するには、左側のペインでプロジェクト名を選択し、 [パッケージの依存関係] タブを選択します。既にプロジェクトの一部となっているパッケージが表示されます。プライベートパッケージを追加するには、 [パッケージ] の下にある [+] 記号を選択します。 右上の検索フィールドに aws.aws-sdk-swift と入力します (これは、 <スコープ名>.<パッケージ名> です)。1~2 秒後に、パッケージ名がリストに表示されます。右上で、ソースリポジトリ ( [レジストリ] ラベルの横) を確認できます。 [パッケージを追加] ボタンを選択する前に、公開されているパッケージについて選択する場合と同様に、パッケージバージョンを選択します。 あるいは、サーバー側アプリケーションまたはコマンドラインアプリケーションの場合は、依存関係を Package.swift ファイルに追加します。また、 .package(id:from:) 関数の最初のパラメータとして形式 ( <スコープ>.<パッケージ名> ) を使用します。 dependencies: [ .package(id: "aws.aws-sdk-swift", from: "0.24.0") ], swift package update と入力すると、SwiftPM が CodeArtifact リポジトリからパッケージをダウンロードします。 留意点 最初の Swift パッケージをアップロードする前に、留意すべき点がいくつかあります。 前述の手順に示されているコマンドを試す前に、必ず CLI の最新バージョンに更新してください 。 swift package コマンドで CodeArtifact を使用するには、Swift バージョン 5.8 以降を使用する必要があります。macOS では、Swift ツールチェーンには Xcode が付属しています。Swift 5.8 は macOS 13 (Ventura) および Xcode 14 で使用できます。Linux および Windows では、 swift.org から Swift ツールチェーンをダウンロード できます。 iOS、iPadOS、tvOS、または watchOS アプリケーションには Xcode 15 を使用する必要があります。私は、これを Xcode 15 beta8 でテストしました。 swift package-registry publish コマンドは、Swift 5.9 以降で使用できます。Swift 5.8 を使用する場合は、デモで示したように、 curl を使用してパッケージをアップロードできます (または、任意の HTTP クライアントを使用します)。 Swift パッケージには、 スコープ という概念があります。スコープは、パッケージリポジトリ内の関連パッケージ用に名前空間を提供します。スコープは、CodeArtifact の 名前空間 にマッピングされます。 認証トークンは 12 時間後に期限切れになります。更新を自動化するスクリプトを記述するか、または スケジュールされた AWS Lambda 関数 を使用してトークンを (例えば) AWS Secrets Manager に安全に保存することをお勧めします。 トラブルシューティング Xcode がプライベートパッケージを見つけられない場合は、 ~/.swiftpm/configurations/registries.json のレジストリ設定を再確認してください。特に、スコープ名が存在するかどうかを確認してください。また、認証トークンがキーチェーンに存在することも確認してください。エントリの名前はリポジトリの URL です。キーチェーン内のエントリは、 /Application/Utilities/Keychain Access.app アプリケーションまたは security コマンドラインツールを使用して確認できます。 security find-internet-password \ -s "stormacq-test-012345678912.d.codeartifact.us-west-2.amazonaws.com" \ -g 私のマシンの SwiftPM の設定は次のとおりです。 cat ~/.swiftpm/configuration/registries.json { "authentication" : { "stormacq-test-012345678912.d.codeartifact.us-west-2.amazonaws.com" : { "loginAPIPath" : "/swift/MySwiftRepo/login", "type" : "token" } }, "registries" : { "aws" : { // <-- これはスコープ名です! "url" : "https://stormacq-test-012345678912.d.codeartifact.us-west-2.amazonaws.com/swift/MySwiftRepo/" } }, "version" : 1 } 料金と利用可能なリージョン Swift パッケージの CodeArtifact のコストは、既にサポートされている他のパッケージ形式のコストと同じです。CodeArtifact の請求額は、ストレージ (GB/月で測定)、リクエスト数、インターネットまたは他の AWS リージョンへのデータ転送 (OUT) という 3 つのメトリクスによって決まります。同じリージョン内の AWS サービスへのデータ転送には料金がかかりません。つまり、例えば、CodeArtifact のデータ転送についての料金が発生しない状態で、 Amazon EC2 Mac インスタンスで CI/CD ジョブを実行できます。いつものように、詳細については 料金ページ をご確認ください。 CodeArtifact for Swift パッケージは、 CodeArtifact が使用可能な 13 のリージョンすべて でご利用いただけます。 さぁ、Swift アプリケーションを構築して、プライベートパッケージを CodeArtifact にアップロードしましょう! — seb PS: Swift プログラミング言語で Lambda 関数を記述できることをご存知ですか? クイックスタートガイド をご確認いただくか、または この 35 分間のチュートリアル に従ってください。 原文は こちら です。
9月19日、 Amazon EC2 M2 Pro Mac インスタンス の一般提供が開始されたことを発表します。これらのインスタンスは、Apple プラットフォーム用のアプリケーションを構築およびテストする際に、既存の M1 Mac インスタンスよりも最大 35% 高速なパフォーマンスを実現します。 新しい EC2 M2 Pro Mac インスタンスは、12 コア CPU、19 コア GPU、32 GiB のメモリ、16 コア Apple Neural Engine を搭載し、高速 Thunderbolt 接続を通じて AWS Nitro System によって独自に強化されている Apple M2 Pro Mac Mini コンピュータ を使用します。これらの Mac mini コンピュータは、最大 10 Gbps の Amazon VPC ネットワーク帯域幅と最大 8 Gbps の Amazon EBS ストレージ帯域幅を備えた、完全に統合されたマネージドコンピューティングインスタンスとして提供されます。EC2 M2 Pro Mac インスタンスは、macOS Ventura (バージョン 13.2 以降) を AMI としてサポートします。 EC2 Mac インスタンスの物語 Jeff Barr が 2020 年に初めて Amazon EC2 Mac インスタンス をリリースしたとき、お客様は、Amazon EC2 上で macOS を実行して、macOS、iOS、iPadOS、tvOS、watchOS などの Apple プラットフォーム用に、 Xcode アプリケーションを使用して開発されたアプリケーションを構築、テスト、パッケージ化、署名できることに驚きました。 AWS re:Invent 2020 の 基調講演 で、Peter DeSantis は、AWS Nitro System を利用した EC2 Mac インスタンスの構築に関する秘密を明かしました。これにより、Apple Mac mini コンピュータを、他の EC2 インスタンスと同様に、Amazon VPC ネットワーキングと Amazon EBS ストレージを備えた、完全に統合されたマネージドコンピューティングインスタンスとして提供できるようになります。 「Mac ハードウェアに変更を加える必要はありませんでした。必要だったのは、Mac の Thunderbolt 接続を介して Nitro コントローラーを接続することだけです。Mac インスタンスを起動すると、 Mac 互換の Amazon マシンイメージ (AMI) がハイパーバイザーなしで Mac Mini 上で直接実行されます。Nitro コントローラーはインスタンスを設定し、ネットワークおよびアタッチされているストレージへの安全なアクセスを提供します。そして、Mac Mini はあらゆる AWS サービスをネイティブに利用できるようになりました」 2022 年 7 月、Apple が設計した M1 システムオンチップ (SoC) を中心に構築された Amazon EC2 M1 Mac インスタンスをリリース しました。iPhone、iPad、Apple Watch、Apple TV アプリケーションを構築するデベロッパーは、x86 ベースの EC2 Mac インスタンスまたは Arm ベースの EC2 M1 インスタンスのいずれかを選択できます。EC2 M1 インスタンスを使用して Apple シリコンを搭載した Mac をネイティブにサポートするようにアプリを再設計したい場合は、AWS のすべてのメリットを活用しながら、iPhone および Mac のアプリの構築ワークロードのために、EC2 Mac インスタンスよりも最大 60% 優れた料金パフォーマンスを実現するアプリを構築してテストできます。 多くのお客様 は EC2 Mac インスタンスを利用して、AWS において、 macOS 上の完全なエンドツーエンドの構築パイプライン を提供しています。EC2 Mac インスタンスを使用すると、iOS ビルドフリートをスケールし、AMI を使用してカスタム macOS 環境を簡単に使用できるほか、完全に再現可能な macOS 環境でビルドまたはテストの失敗をデバッグできます。 お客様からは、構築時間の最大 4 倍の短縮、並列ビルドの最大 3 倍の増加、マシン関連のビルド障害の最大 80 % の削減、およびフリートサイズの最大 50 % の削減が報告されています。オンプレミスの macOS インフラストラクチャの管理に必要となる退屈な作業を軽減しながら、製品や機能の革新のために優先的に時間を割き続けることができます。 このイノベーションを加速するために、EC2 Mac インスタンスは最近、実行中の EC2 Mac インスタンス上の ルートボリュームの置き換え のサポートを開始しました。これにより、EC2 Mac インスタンスのルートボリュームを、インスタンスを停止または終了することなく、初期の起動状態または特定のスナップショットに復元できるようになります。 また、インスタンスを Apple Developer Program に登録することで、EC2 M1 Mac インスタンスのゲスト環境内から、特定のまたは最新の macOS バージョン ( ベータ版 を含む) への オペレーティングシステムのインプレースアップデート を使用することもできます。デベロッパーは、macOS のパブリックリリース前に、最新の macOS 機能をアプリケーションに統合し、既存のアプリケーションの互換性をテストできるようになりました。 EC2 M2 Pro インスタンスの開始方法 他の EC2 Mac インスタンスと同様に、EC2 M2 Pro Mac インスタンスも、macOS ライセンスに合わせて、最小ホスト割り当て期間が 24 時間の専有ホストテナンシーをサポートしています。 使用を開始するには、Mac 専有ホスト、つまり AWS アカウントにおける完全に自分専用の物理サーバーを割り当てる必要があります。ホストが割り当てられた後は、1 つの専有ホストとなるように、そのホスト上の 1 つのインスタンスとして独自の macOS 環境を起動、停止、開始できます。 ホストが割り当てられたら、そのホスト上で EC2 Mac インスタンスを起動できます。この手順は、あらゆる EC2 インスタンスタイプを開始する場合と変わりません。macOS AMI バージョンを選択し、 [アプリケーションと OS イメージ] セクションで mac2-m2pro.metal インスタンスタイプを選択します。 [高度な詳細] セクションの [テナンシー] で [専有ホスト] を選択し、 [テナンシーホスト ID] で作成したばかりの専有ホストを選択します。 EC2 Mac インスタンスを初めて使用するときは、SSH を使用して通常どおり新しく起動したインスタンスに接続するか、EC2 インスタンスに対して Apple Remote Desktop を有効にして VNC セッションを開始 できます。詳細については、 Sebastien の一連の記事 を読み、Mac インスタンスを起動して接続してください。 Mac 専有ホストが必要なくなった場合は、実行中の Mac インスタンスを終了し、基盤となるホストを解放できます。Mac 専有ホストは、割り当て後、Apple の macOS ライセンスに合わせて、24 時間が経過しなければリリースできないことにご留意ください。 今すぐご利用いただけます Amazon EC2 M2 Pro Mac インスタンスは、米国西部 (オレゴン) と米国東部 (オハイオ) の AWS リージョンでご利用いただけます。また、追加のリージョンも近日中に追加される予定です。 詳細を確認したり、使用を開始したりするには、「 Amazon EC2 Mac インスタンス 」をご覧いただくか、または EC2 Mac ドキュメント にアクセスしてください。 フィードバックは、 AWS re:Post for EC2 に送信するか、または AWS サポートの通常の担当者を通じてお寄せください。 – Channy 原文は こちら です。
2023 年 8 月 30 日: Amazon Kinesis Data Analytics は Amazon Managed Service for Apache Flink に名称が変更されました。 AWS News Blog や こちら をご覧ください。 リアルタイム異常検出とは、ストリーミングデータで予期しない挙動が発生したときにそれを検出する手法です。そして、オンライン機械学習アルゴリズムは、明示的なルールを必要とせずに変化するベースラインに適応できるため、リアルタイム異常検出のユースケースで人気があります。このアルゴリズムは、受信するデータが時間の経過とともに継続的に変化する連続的なデータストリームに対して特に役立ちます。 ランダムカットフォレスト (RCF) は、異常検出のユースケースで広く使用されているアルゴリズムの 1 つです。一般的には、入力データに対して RCF アルゴリズムを高いスループットで実行したい場合が多く、ストリーミングデータ処理フレームワークはそのようなケースで役立ちます。 Amazon Managed Service for Apache Flink 上で RCF が使用可能になり、ストリーミングデータ処理において異常検出ができるようになりました。 Apache Flink は、データストリーム上でリアルタイムでステートフルな計算を行うための人気のオープンソースフレームワークで、高いスループットで RCF を入力ストリームに実行するために使用できます。 この記事では、Amazon Managed Service for Apache Flink を使用して、異常検出用のオンライン RCF アルゴリズムを実行する方法を説明します。 ソリューションの概要 今回作成するアーキテクチャを下の図に示します。アーキテクチャは、 Amazon Kinesis Data Streams による入力データストリーム、Amazon Managed Service for Apache Flink によるFlink ジョブ、Amazon Kinesis Data Streams による出力データストリームの 3 つのコンポーネントで構成されています。データフローに関しては、Python スクリプトを使用して異常な正弦波データを入力データストリームに配信し、そのデータを Flink ジョブで RCF によって処理し、結果の異常スコアを出力データストリームに配信します。 以下のグラフは、予想される結果の例です。正弦波データソースが定数 -17 に異常に低下した際に、異常スコアがピークに達した様子を示しています。 このソリューションは以下の 3 つの簡単なステップで実装できます。 AWS CloudFormation 経由で AWS リソースをセットアップします。 入力データストリームに正弦波データを配信するようにデータジェネレータを設定します。 Amazon Managed Service for Apache Flink で RCF Flink Java コードを実行します。 AWS Cloud Formation で AWS リソースをセットアップする 次の CloudFormation スタックは、2 つの Kinesis Data Streams、1 つの Amazon Managed Service for Apache Flink アプリケーション、および Amazon Simple Storage Service (Amazon S3) バケットを含む、このチュートリアルに必要なすべての AWS リソースを作成します。 AWS アカウントにサインインし、[ Launch Stack ] を選択します。 AWS CloudFormation コンソールのステップに従ってスタックを作成します。 データジェネレータをセットアップする 次の Python スクリプトを実行して、入力データストリームに異常な正弦波データを入力します。 import json import boto3 import math STREAM_NAME = "ExampleInputStream-RCF" def get_data(time): rad = (time/100)%360 val = math.sin(rad)*10 + 10 if rad > 2.4 and rad < 2.6: val = -17 return {'time': time, 'value': val} def generate(stream_name, kinesis_client): time = 0 while True: data = get_data(time) kinesis_client.put_record( StreamName=stream_name, Data=json.dumps(data), PartitionKey="partitionkey") time += 1 if __name__ == '__main__': generate(STREAM_NAME, boto3.client('kinesis', region_name='us-west-2')) Amazon Managed Service for Apache Flink で RCF Flink Java コードを実行する CloudFormation スタックは、RCF Flink ジョブ JAR ファイルを自動的にダウンロードしてパッケージ化します。そのため、Amazon Managed Service for Apache Flink コンソールにアクセスし、作成された分析アプリケーションを実行するだけでリアルタイム異常検出を体験できます。 分析アプリケーションを実行することにより、 Kinesis Data Streams からのデータを継続的に読み込み、過去のデータポイントを基に新しいデータポイントの異常スコアを計算する Flink ジョブが作成されました。 以下のセクションでは、RCF の実装と Flink のジョブコードについて詳しく説明します。 RCF の実装 RCF 実装方法は多数公開されています。このチュートリアルでは、 AWS での実装 を Flink ジョブで使用するカスタムラッパー ( RandomCutForestOperator ) でラップして使用します。 RandomCutForestOperator は Apache Flink ProcessFunction として実装されています。この関数を使用すると、ストリーム内のすべての要素を処理するカスタムロジックを記述できます。カスタムロジックは、 inputDataMapper.apply によるデータ変換から始まり、続いて rcf.getAnomalyScore 経由で AWS RCF ライブラリ を呼び出して異常スコアを取得します。 RandomCutForestOperator の実装コードは GitHub で確認できます。 RandomCutForestOperatorBuilder には主に 2 つのタイプのパラメータが必要です。 RandomCutForestOperator のハイパーパラメータ Dimensions – 入力データが float 型で構成される 1 次元の正弦波であるため、1 に設定します。 ShingleSize – 1 に設定します。この設定により、RCF アルゴリズムは異常スコア推定において過去と現在のデータポイントを使用します。季節性を持つデータを対象にする場合、この値を増やすことを考慮する必要があります。 SampleSize – 628 に設定します。この設定により、各ツリーのデータサンプルには最大 628 個のデータポイントが保持されます。 入出力処理用の DataMapper パラメータ InputDataMapper – RandomCutForestOperator.SIMPLE_FLOAT_INPUT_DATA_MAPPER を使用して、入力データを float から float[] にマップします。 ResultMapper – RandomCutForestOperator.SIMPLE_TUPLE_RESULT_DATA_MAPPER を使用します。これは、異常スコアと対応する正弦波データポイントを結合してタプルにする BiFunction です。 Flink ジョブコード 次のコードスニペットは、Apache Flink ストリーミング Java コードのコアストリーミング構造を示しています。まず、ソース Kinesis Data Streams からデータを読み込み、次に RCF アルゴリズムを使用して処理します。次に、計算された異常スコアが出力 Kinesis Data Streams に書き込まれます。 DataStream<Float> sineWaveSource = createSourceFromStaticConfig(env); sineWaveSource .process( RandomCutForestOperator.<Float, Tuple2<Float, Double>>builder() .setDimensions(1) .setShingleSize(1) .setSampleSize(628) .setInputDataMapper(RandomCutForestOperator.SIMPLE_FLOAT_INPUT_DATA_MAPPER) .setResultMapper(RandomCutForestOperator.SIMPLE_TUPLE_RESULT_DATA_MAPPER) .build(), TupleTypeInfo.getBasicTupleTypeInfo(Float.class, Double.class)) .addSink(createSinkFromStaticConfig()); この例では、ベースライン入力データは正弦波です。次のスクリーンショットに示すように、データが規則的であれば低い異常スコアが返されます。ただし、データに異常がある場合 (正弦波入力データが定数まで低下した場合)、高い異常スコアが返されます。異常スコアは出力 Kinesis Data Streams に配信されます。この結果は、Amazon Managed Service for Apache Flink Studio アプリケーションを作成することで視覚化できます。手順については、「 ストリーミングデータのインタラクティブ分析 」を参照してください。 RCF は教師なしアルゴリズムなので、この手順には明示的なルールやラベル付きデータセットを指定する必要はありません。つまり、入力データストリーム、データ変換、および一部のハイパーパラメーターのみで実行できます。RCF 自身が入力データに基づいて予想されるベースラインを決定し、予期しない動作を特定します。 さらに、RCF はベースラインが時間の経過とともに変化しても、継続的に適応することができます。そのため、再トレーニングの頻度は最小限で済みます。季節的な傾向、インフレーション、機器のキャリブレーションのドリフトなどにより、データが時間の経過とともにゆっくりとドリフトすることはよくあるため、RCF はストリーミングデータの異常検出に有効なアルゴリズムです。 クリーンアップ 今後料金が発生しないようにするには、次の手順を実行してください。 Amazon S3 コンソールで、CloudFormation スタックによって作成された S3 バケットを空にします。 AWS CloudFormation コンソールで、CloudFormation スタックを削除します。 まとめ この記事では、Amazon Managed Service for Apache Flink を使用するオンラインの教師なし機械学習アルゴリズムである RCF を使用して、入力ストリーミングデータの異常検出を実行する方法を説明しました。また、このアルゴリズムが自動的にデータのベースラインを学習し、時間の経過に伴うベースラインの変化に適応する方法についても説明しました。リアルタイム異常検出のユースケースにこのソリューションを検討していただければ幸いです。 著者について Daren Wong は AWS のソフトウェアエンジニアです。彼は、AWS で Apache Flink アプリケーションを実行するためのマネージドサービスである Amazon Managed Service for Apache Flink に携わっています。 Aleksandr Pilipenko は AWS のソフトウェアエンジニアです。彼は、AWS で Apache Flink アプリケーションを実行するためのマネージドサービスである Amazon Managed Service for Apache Flink に携わっています。 Hong Liang Teoh は AWS のソフトウェアエンジニアです。彼は、AWS で Apache Flink アプリケーションを実行するためのマネージドサービスである Amazon Managed Service for Apache Flink に携わっています。 このブログは 2023 年 5 月 1 日に Daren Wong、Aleksandr Pilipenko、Hong Liang Teoh によって執筆された「 Real-time anomaly detection via Random Cut Forest in Amazon Managed Service for Apache Flink 」を日本語化したものです。 翻訳はソリューションアーキテクトの山下一樹が担当しました。
この記事は “ Improving AstraZeneca Japan’s Enterprise Search Capabilities and Regulatory Compliance using Amazon Kendra ” を翻訳したものです。 日本で事業を展開する製薬会社にとって、販売情報提供活動において間違った情報や古い情報を誤って伝達することを防ぐためには、倫理的なコンプライアンスが極めて重要です。規制が厳しく、消費者保護に重点が置かれていることで知られる日本では、製薬会社は信頼を維持し、患者の健康を確保するために、一連の倫理ガイドラインを遵守しなければなりません。 アストラゼネカ株式会社 (AZKK)の医療情報担当者 (MR) は、規制に準拠した方法で医療従事者に情報提供するため、常に最新の承認済みマーケティングコンテンツを探さなければならないという課題があります。この課題を解決するために、AZKK はアマゾンウェブサービス (AWS) と協力して Amazon Kendra を使用した POC を実施し、関連性が高く、最新の承認済みコンテンツを効率的に見つけ出すためのエンタープライズ検索のエクスペリエンスの向上に取り組みました。 Amazon Kendra は、機械学習 (ML) を活用したインテリジェントな検索サービスです。ウェブサイトやアプリケーションのエンタープライズ検索を一新し、従業員や顧客が探しているコンテンツが組織内の複数のリポジトリに分散していても、簡単に見つけられるようにします。このサービスは、日本語を含む複数の言語での半構造化コンテンツと非構造化コンテンツの両方のセマンティック検索をサポートしており、AWS の東京リージョンでの Amazon Kendra の一般提供が最近発表されました。AZKK が POC に Amazon Kendra を選択した際の要件は日本語対応のセマンティック検索でしたが、Microsoft Excel ドキュメントのインデックス作成や検索など、AZKK が必要とする製品機能は他にもありました。Amazon Kendra には、イベント駆動型のカスタムコネクタを作成する機能もあります。これにより、AZKKはKendraのインデックスをほぼリアルタイムで更新できるため、ユーザーは最新のコンテンツをすぐに見つけることができます。 AZKK は、Amazon Kendra、 Amazon API Gateway 、 Amazon Simple Notification Service (Amazon SNS)、 Amazon Simple Queue Service (Amazon SQS)、 AWS Lambda 、 Amazon EventBridge イベントバス 、 Amazon EventBridge Pipes 、 AWS Key Management Service (AWS KMS) のカスタマーマネージドキー、 Amazon Simple Storage Service (Amazon S3) を使用してエンタープライズ検索ソリューションを構築しました。ソリューションのアーキテクチャは、次の図の通りです。 保存中のすべてのデータは、AWS KMS のカスタマーマネージドキーを使用して暗号化されます。 Box コンテンツ管理ソリューションでドキュメントが作成、更新、または削除されるたびに、Box の Webhook サービスは JSON メッセージをAPI Gateway に送信します。 API Gateway は、サービス統合を使用してメッセージを Amazon SQS FIFO (First-In-First-Out) キューに転送し、重複するメッセージを削除し、ドキュメントのイベントの順序を維持します。 Lambda 関数は SQS キューのメッセージによってトリガーされ、メッセージを処理します。ドキュメントのファイル形式が Amazon Kendra でサポートされている場合、ファイルは Box から S3 バケットにダウンロードされ、Amazon Kendra によってインデックス化されます。Amazon Kendra に送信されるインデックス作成のリクエストには Box 内の ACL に基づくアクセスコントロールリスト (ACL) も含まれています。 ドキュメント ID、Amazon Kendra インデックス ID、および Amazon Kendra データソース ID を含む JSON オブジェクトは SQS FIFO キューに転送され、Amazon Kendra のインデックス作成リクエストのステータスを監視します。 Box イベントタイプが FILE.TRASHED、FILE.DELETED、または FILE.LOCKED (Box でプライベート化) の場合、Lambda 関数はコンテンツが検索できないように最初にドキュメントコンテンツとドキュメントタイトルを置き換え、次に Amazon Kendra にドキュメントをインデックスから削除するようリクエストします。 別の Lambda 関数は、「ドキュメントインデックスステータスの確認」のSQS キューによってトリガーされ、Amazon Kendra をポーリングしてインデックス作成リクエストの結果を検索します。成功または失敗を示す結果を受け取ると、メッセージがカスタムEventBridgeバスに送信され、以降のプロセスに警告したり、必要に応じてログに記録したり、さらなる分析をトリガーしたりできます。 EventBridge ルールは、インデックスの取り込みステータスをチェックして SUCCEED または FAIL の結果に対して Lambda 関数をトリガーし、S3 バケットからドキュメントの一時的なコピーを削除して、ドキュメントのコピーが 1つになるようにします。 Amazon Kendra のインデックス作成で問題が発生し、その結果 FAIL ステータスになった場合は、EventBridge ルールがトリガーされ、チームに調査用のメッセージが送信されます。例外処理のために、SQS キューにデッドレターキュー (DLQ) をアタッチしています。これにより、必要な場合に最初の Webhook メッセージに対してメッセージをリドライブできるほか、チームに調査を通知することもできます。 Amazon Kendra に問題が発生し、インデックスステータスを取得できない場合、メッセージは DLQ にドロップされ、EventBridge パイプがメッセージを変更してエラーとして、EventBridge バスに渡します。 受信した Webhook 通知の処理に問題がある場合、メッセージは DLQ に渡され、Amazon CloudWatch アラームを使用してアラームがトリガーされます。 POC の結果では、既存のエンタープライズ検索ソリューションと比較して、 検索結果の精度が2倍に向上 しただけでなく、 検索速度 (平均評価は 4.4/5 対 2.4/5 ) とアクセシビリティ (平均評価は 4.2/5 対 2.2/5 ) も大幅に向上 しました。ユーザーの 93% が、ソリューションを本番環境に展開することを推奨しています。多くのユーザーが、高速で正確な検索が気に入っているとコメントしています。 POCの成功により、このソリューションは2023年6月末に本番環境に移行し、好評を博しています。 “AIによる従業員の生産性の向上は、デジタルワークフォースの重要な基盤です。このプロジェクトは年間12,000時間の生産性の改善を実現しており、社内のAIエンジニアの才能と、AWSチームとの緊密なパートナーシップによってもたらされるインパクトを示しています。” Harsh Gandhi, Head of Information and Digital, IT, AstraZeneca Japan. AZKK は、より多くのデータソースを追加し、ソリューションを Amazon Comprehend と統合してコンテンツの分類を改善することで、ソリューションを強化しようとしています。チャットボットの統合に Amazon Lex と Amazon Polly を組み合わせて使用して音声対話をサポートする計画もあります。これにより、AZKK のフィールド担当者は外勤の移動中であっても、 Amazon Kendra とハンズフリーでやり取りできるようになります。 Amazon Kendra は、アストラゼネカのような組織が検索エクスペリエンスを向上させ、従業員の生産性を高めるのに役立ちます。生成AIの普及により、より複雑なクエリへの応答を生成できるようになってきています。正確な応答をタイムリーに作成できるようになったことで、AZKKは、検索拡張生成(RAG)ベースのアプリケーションで 大規模言語モデル(LLM)を搭載した対話型AI を使用するようにユースケースを進化させています。RAGアーキテクチャは、ハルシネーション(誤った応答)に陥りやすいLLMに頼るのではなく、企業データに関する応答に制限することで、生成AIのハルシネーションを軽減します。Amazon Kendra の Retrieve API (RAG のためのAPI)、データソースコネクタの包括的なエコシステム、一般的なファイル形式のサポート、セキュリティにより、Amazon Kendra を取得メカニズムとするエンタープライズユースケース向けの生成 AI ソリューションをすぐに使い始めることができます。AZKK は、既存の Amazon Kendra ベースのソリューションを Amazon Bedrock や Amazon Sagemaker JumpStart などのネイティブ AWS サービスで強化し、それぞれのユースケースに最適なさまざまな LLM にアクセスできるようにしています。 <!-- '"` --> Thiam Hwa Lim Thiam Hwa Lim は、ヘルスケアおよびライフサイエンス業界のお客様をサポートする AWS のシニアソリューションアーキテクトです。彼は業界の顧客と20年間働いてきており、テクノロジーを使って人々の生活を改善することに情熱を注いでいます。 Firaz Akmal Firaz Akmal は AWS の Amazon Kendra のシニアプロダクトマネージャーです。彼は顧客を重視しており、AWS で Kendra を使って顧客が検索と生成 AI のユースケースを理解できるよう支援しています。仕事以外では、PNWの山で時間を過ごしたり、娘の視点から世界を体験したりすることを楽しんでいます。 Jarich Vansteenberge Jarich Vansteenbergeは、アストラゼネカ株式会社の Data, AI and Innovation CoE 担当のディレクターです。9年以上にわたり、日本のヘルスケアおよび製薬業界においてAIやイノベーティブ・プロジェクトの実践的な実装に携わってきた経験があります。 Jim O’Neil Jim O’Neilは、アストラゼネカ株式会社の Data, AI and Innovation CoE チームのシニアクラウドアーキテクトです。複数の業界向けにスケーラブルで費用対効果が高く、持続可能なアーキテクチャの設計と構築に30年以上の経験があります。サーバーレスのすべてが好みです。 翻訳はソリューションアーキテクトの松永が担当しました。
Amazon Elastic Block Store (Amazon EBS) の io2 および io2 Block Express ボリュームが NVMe 予約を使用したストレージフェンシングをサポートするようになりました。この記事を書いているときに学んだことですが、ストレージフェンシングは、クラスター内の 1 つのホストだけがいつでもボリュームに書き込むことのできるアクセス許可を持つよう、コンピューティングクラスターまたはデータベースクラスターのストレージへのアクセスを規制するために使用されます。例えば、SQL Server フェイルオーバークラスターインスタンス (FCI) を設定すると、データベースのレプリケーションを作成する必要なく、単一のアベイラビリティーゾーン内でアプリケーションの可用性を高めることができます。 簡単に復習しておくと、io2 Block Express ボリュームは、Nitro ベースの Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で実行し、I/O 負荷が非常に高いアプリケーションのニーズを満たすように設計されています。ボリュームのサイズは最大 64 TiB で、ボリュームあたり最大 256,000 IOPS と 4,000 MB/秒のスループットという SAN 並みのパフォーマンスを実現し、そのすべてが 99.999% の耐久性とミリ秒未満のレイテンシーを実現しています。ボリュームは、 暗号化 や マルチアタッチ などの他の高度な EBS 機能をサポートし、ダウンタイムなしでオンラインで再プロビジョニングできます。詳細については、「 Amazon EC2 R5b インスタンスを使用した Amazon EBS io2 Block Express ボリュームが一般的に利用可能に 」を参照してください。 予約を使用する 予約を活用するには、マルチアタッチが有効な io2 ボリュームを作成し、それを 1 つ以上の Nitro ベースの EC2 インスタンスにアタッチします (サポートされているインスタンスタイプの完全な一覧については、「 プロビジョンド IOPS ボリューム 」を参照してください)。 既存の io2 Block Express ボリュームがある場合は、すべての EC2 インスタンスからボリュームをデタッチしてから再アタッチすることで予約を有効にできます。最初のアタッチを行うとすぐに予約が有効になります。データスタンプが 2023 年 8 月 以前の AMI を使用する Windows Server を実行している場合、「 AWS Windows インスタンス用 NVMe ドライバー 」で説明されているように aws_multi_attach ドライバーをインストールする必要があります。 知っておくべきこと NVMe 予約に関して、念頭に置いておくべきことを記載しておきます。 オペレーティングシステムのサポート – NVMe 予約は、Windows Server (2012 R2 以上、2016、2019、2022)、SUSE SLES 12 SP3 以上、RHEL 8.3 以上、Amazon Linux 2 以降で使用できます (詳細については、「 NVMe reservations 」を参照してください)。 クラスターマネージャーとボリュームマネージャー – Windows Server フェイルオーバークラスタリングがサポートされています。現在、その他のクラスターマネージャーとボリュームマネージャーを追加するための作業が進められています。 料金 – この機能の追加料金は発生しません。各予約は I/O オペレーションとしてカウントされます。 – Jeff ; 原文は こちら です。
(この記事は、 How Small and Medium Businesses Can Develop a Modern Data Strategy を翻訳したものです。) 企業はビッグデータの時代において、増え続けるさまざまなソースから生まれる大量のデータに悩まされることがよくあります。 Gartner によると、60% の企業は質の悪いデータに起因するコストを測定していません。測定を行わないとデータ品質の問題に事後対応したり、ビジネスの成長機会を逃したり、リスクを増大させたりすることになります。データを効果的に活用する能力は企業の成功を左右する重要な要因になりつつあります。しかし生データを価値ある洞察に変えるには、健全なデータ戦略、効率的な管理、最新のデータアーキテクチャが必要です。このブログでは Amazon Web Services がどのように強力なソリューションを提供できるかに焦点を当てて、これらの側面を探ります。 中堅中小企業における最新のデータ課題を探る データ量が増え、ソースが多様化するにつれて、企業はデータ関連のさまざまな課題に直面します。これらの課題には次のようなものがあります。 どこから始めるか ビジョンを持ち、将来のアーキテクチャがどのようなものかを明確に理解することがデータアーキテクチャの旅の始まりであり、データ戦略のエグゼクティブスポンサーの責任です。すべてを一度に行う必要はありません。代わりに、重点分野に優先順位を付けることが成功には不可欠です。たとえば AWS のお客様である Qure4u は医療機関に向けたリアルタイムのデータ可視化ダッシュボードを作成するため、 Amazon QuickSight から着手しました。 このビジネスデータ戦略への注力は、時が経つにつれ 5 倍の成長につながりました 。「中堅中小企業は AWS を使用することですぐに事業を開始できます。自分のチームに特定の能力がない場合でも、AWS には専門家とつなぐためのリソースがあり、低コストで専門的なセットアップを受けることができます」と Qure4u の CEO 兼創設者である Monica Bolbjerg 博士は述べています。 効果的な戦略の欠如 多くの企業はデータ戦略をビジネスビジョンに合わせることに苦労しています。この課題はビジネス目標を測定可能なデータポイントに変換し、データを効果的に管理することの難しさに起因しています。データ戦略を実行するには、最新のデータアーキテクチャへの道筋を描く際、人材、プロセス、そしてソリューションを備えたターゲットテクノロジーの選択が必要です。 人員不足と IT スキルギャップ 資金や人的リソースが限られている中堅中小企業は、高度なデータ管理ツールに対する投資が制限されることがあります。これらの制限により、データの保存と管理が最適とは言えない状況が生まれます。 AWS は多くの 中堅中小企業で社内の IT 人材が不足し 、データ管理が困難になる可能性があることを認識しています。それに伴うボトルネックにより、重要なビジネス情報へのアクセスと分析が困難になる可能性があります。 データ品質 データ品質の低下も企業にとって一般的な課題です。手作業によるデータ入力、不完全なデータセット、データサイロはデータの品質を低下させ、洞察と意思決定を歪める可能性があります。連携されていないさまざまなスプレッドシートや旧来のソフトウェアで苦労しているのであれば、これはよく知られた話に聞こえるはずです。同様に強固なデータセキュリティ対策には多大なリソースが必要なため、企業はデータセキュリティとコンプライアンスの維持に苦慮します。 データ統合 最後に、ソーシャルメディア、 顧客管理 (CRM) システム、 EC プラットフォーム など、さまざまなソースからのデータ統合が大きなハードルになることが判明しています。こうした統合の課題は企業が データを全体的に理解する ことを妨げ、データに基づいた意思決定をさらに妨げます。 成果を定義し、データに関する課題に優先順位を付けることの重要性 ソリューションを掘り下げる前に、ビジネスで達成しようとしていることに基づいて明確な目標を設定することが重要です。このプロセスには、重要業績評価指標 (KPI) を特定し、 KPI を追跡するために必要なデータを決定することが含まれます。 KPI のもっとも一般的な例は、収益、利益率、顧客維持率、コンバージョン率などです。また現在のデータ状況、つまり企業が収集するデータ、保存場所、分類方法を理解することで、企業が目標を達成する態勢がどの程度整っているかについての重要な洞察が得られます。 ただし、データ戦略は目標の設定とデータ状況の理解にとどまりません。データに関する課題に優先順位を付けることも同じく重要です。このプロセスには、以下の評価を含める必要があります。 現在のデータ管理状況 データ品質に関する問題の特定 データ収集のギャップ ストレージの問題 さらに、意思決定に不可欠なデータソースを特定しデータのパターンと傾向を特定することは、このプロセスにおける重要なステップです。 最新のデータアーキテクチャによるデータ課題への取り組み これらのデータ課題に取り組むため、AWS が提供する 最新のデータアーキテクチャパターン を活用できます。このアプローチは、分析に対する画一的な取り組みが妥協につながるという考えに基づいています。これらのパターンの中核となる要素には、多様なデータに対応できるスケーラブルなデータレイク、さまざまなデータニーズに対応するための専用データベース、シームレスなデータ移動のためのサーバーレスデータ統合サービス、統合されたデータガバナンス、さまざまなパフォーマンスとコストの最適化ツールが含まれます。これらのソリューションはデータをより効果的に管理し、そこから有意義な洞察を引き出すのに役立ちます。 人材、プロセス、テクノロジーの連携 図1: 最新のデータ戦略の要素 強固なデータ戦略を策定するには、テクノロジーだけでなく人とプロセスを連携させることも重要です。組織内でデータ中心の文化を育み、チームに必要なスキルを備え、必要に応じて新しい人材を採用することは、データの使用を最適化するのに役立ちます。最高データ責任者(エグゼクティブスポンサー)、データスチュワード、データサイエンティスト/エンジニアなど、実行において重要な役割がいくつかあります。企業規模によっては個人が複数の役割を担う場合があることに注意してください。 プロセスの観点から見ると、自動化はデータ取り込みの最適化、データ品質の向上、変換、分析、 コストの最適化 、 ガバナンス において重要な役割を果たします。 また、テクノロジーの選択はビジネスニーズと一致している必要があります。 AWS はデータ管理のさまざまな側面に対応する幅広いテクノロジーを提供しています。 Amazon Simple Storage Service (S3) のようなスケーラブルなデータレイクから、 Amazon Athena 、 Amazon EMR 、 Amazon OpenSearch Service 、 Amazon Kinesis 、 Amazon Redshift などの専用分析サービスまで、さまざまなニーズを満たすように設計されたツールが存在します。データ品質の測定とモニタリングを伴うシームレスなデータ移動は AWS Glue で実現でき、 AWS Lake Formation は統合ガバナンスを提供します。 図 1 を参照して、これらすべてのサービスがどのように連携してテクノロジーの目標を達成するかを確認してください。 最後に、コスト削減については S3 intelligent tiering でデータレイクのストレージコストを最大 70% 節約可能なことに加え、 Amazon Elastic Computing Cloud では業界をリードする 500 を超えるインスタンスタイプをさまざまな savings plans でご提供します。 進捗状況の測定とコースの調整 データ戦略を立て、人材、プロセス、テクノロジーを調整した後、設定された目標に向けた進捗状況を測定することが不可欠です。KPI を継続的に監視することは、データ戦略の有効性を評価し、改善すべき領域を特定するのに役立ちます。現在の戦略が期待した結果をもたらしていないとわかったとしても、進路の調整をためらうべきではありません。多くの場合、アジャイルで柔軟なデータ戦略がもっとも成功します。チームの成果や改善の余地が関係者に伝わるように、定期的なミーティングを設定することをお勧めします。 まとめ 資源が限られた企業にとって、データに関する課題に取り組むことは非常に困難な作業です。ただし、ビジネスビジョンを綿密に練られたデータ戦略と整合させ、データを理解し、明確な成果を定義し、データの課題に優先順位を付けることで、より良いデータの管理と利用への道を開くことができます。 最新のデータアーキテクチャパターンを採用することで、これらの課題の多くを克服できます。さらに、人材、プロセス、テクノロジーを連携させることで、データ戦略の効果を最大限に高めることができます。AWS が提供するサービスを活用することで、データ管理を変革し、データを効果的に実用的な洞察に変えることができます。 結論として、データの課題を克服し、データの真の可能性を引き出すまでの道のりは複雑かもしれませんが、適切な戦略とツールがあれば、この道のりを成功させるための準備が整います。データに関する課題への対処方法の詳細については、AWS の 専門家にお問い合わせください 。 翻訳はソリューションアーキテクトの酒井 賢が担当しました。原文は こちら です。
(この記事は、 A Basic Guide to Customer Interaction Analytics for Small and Medium Businesses を翻訳したものです。) 顧客に対する理解が深まれば、ビジネスは何を達成できるでしょうか? Gartner が 2022 年に実施した調査では、カスタマーサービスおよびサービスサポートリーダーの 84% が 2023 年に組織目標を達成する上で、 顧客データと分析が「非常に重要」または「非常に重要」と回答しています。 中堅中小企業の経営者にとって、こうした顧客データの洞察は極めて重要ですが、他の重要なビジネス課題に加えて、これらすべてを大規模に管理する時間を見つけることは困難です。 ビジネスの成長を加速し、顧客基盤を拡大しながら顧客維持率を向上させるには、 データを深く掘り下げる 必要があります。カスタマーインタラクション分析によって製品開発や特別なオファーに影響を与える実用的な洞察を生み出すことができます。このブログ記事では、カスタマーインタラクション分析を行うメリット、役立つツール、顧客データの活用事例に焦点を当てます。 カスタマーインタラクション分析とは カスタマーインタラクション分析は複数のチャネルで収集された未加工の顧客データを統合し、実用的な洞察を生み出します。たとえば Web ページのユーザーコンバージョン率を確認したい場合は以下に挙げるデータが用いられます。 アプリケーションのクリックデータ 商品購入の取引データ オンラインレビューまたはカスタマーサポートフィードバックからの定性データ これらの情報を統合することで、ユーザーの行動パターンを発見し、製品機能の調整や新しい市場へのターゲットを絞った働きかけなどの新しい取り組みの可能性を引き出すことができます。簡単に言えば、競争上の優位性をもたらすための知見となります。大企業ではこれらの情報を定期的に確認し、結果を経営陣と共有する専任のデータ分析チームがあります。従来、財務部門の責任者はビジネス分析の領域を所有していましたが、通常は収益性に関する指標のみに焦点を当てていました。 皆様のビジネス現場では技術スキルを持った人材が不足している状況にあるかもしれませんが、顧客データ分析を行うにはエンジニア、データサイエンティスト、または開発者である必要はありません。顧客行動のインタラクションデータは、多くの場合、場所、時間、その他の指標に基づいてフィルタリングできるダッシュボード(または未加工データを視覚的に解釈したもの)に表示されます。顧客データ分析によって業務改善ができる方であれば、未加工データを手作業で確認しなくても、よりスマートな意思決定を行うために必要な洞察を引き出すことができます。 カスタマーインタラクション分析を活用するメリット 企業が経験などの不確かな証拠に頼っている場合や、 何を測定すべきかわからない 場合は、顧客データ分析がビジネス上のよりスマートな意思決定に役立ちます。 Amazon Web Services ではこれから分析に取り組む企業を支援するために、次の 3 つのメリットを提供しています。 顧客をよりよく理解する カスタマーインタラクション分析を活用して、ユーザー全体、主要なユーザー属性、さまざまな製品や機能との関わり方を深く理解しましょう。それらのパターンを特定し、将来の利用状況を予測することで、新しい市場、業界、地域に拡大できます。たとえば、新しいサービスをマーケティングする場合、特定の地域で使用量が具体的に増加しているかどうかを確認し、販売(および e コマース)の取り組みをさらに集中させてビジネスを成長させることができます。 新たなビジネスパターンを認識する ユーザーの行動パターンを見つけることは、主要なビジネスイニシアチブについてデータ主導の意思決定を行うことに役立ちます。顧客とのインタラクションにおける幅広いテーマを発見することで、企業は戦略的に新製品の開発、マーケティングメッセージの更新、よりスマートな販売投資などを行うことができます。さらに、複数のチャネルにわたるエンドユーザーの使用パターンを観察すると、何が注目を集めているのか、どこにイノベーションを起こすべきかという新たなテーマが明らかになります。たとえば、同じ期間におけるネガティブなコールセンターのデータと Web サイトのインタラクションを比較すると、Web サイトのユーザビリティの問題が明らかになる可能性があります。 手動分析なしで迅速に移行 企業は第三者調査会社と契約する代わりに、統合されたデータをオンデマンドで利用できるようにすることで、機敏な意思決定を行い、ひいては市場投入までの時間を短縮できます。カスタマーエクスペリエンスデータを活用したビジネスインテリジェンスツール(ダッシュボードなど)を利用すると、意思決定を簡単かつ迅速に行うことができます。これにより、製品の構想、開発、市場投入までの時間が短縮されます。技術的なソリューションを構築しなくても、ビジネスインテリジェンスが戦略的な投資判断に役立ちます。 &nbsp; 顧客を深く理解するために使用できるデータの種類 顧客データ分析が非常に重要である理由がわかったところで、次は顧客分析の導入を妨げる可能性のある課題を克服する方法について詳しく見ていきましょう。よくある課題は、①さまざまなタイプのデータを適切に格納する方法を見つけること、②セルフサービスダッシュボードを効果的に使用すること、③クエリを使用してデータを大規模に分析することです。企業が洞察を得るために役立つデータのカテゴリは次のとおりです。 エンタープライズシステムからの構造化データ: 例としては、 顧客関係管理 (CRM) ソフトウェア、 エンタープライズリソースプランニング (ERP) ツール、およびその他のデータベースが含まれます。これらのデータが個別に利用可能であっても、互いに同期できない場合があります。 テキストファイル、ドキュメント、画像、ビデオ、オーディオなどの非構造化データ: 企業にはサイズにかかわらずこれらのファイルが大量にあります。ビジネスの多くはこれらの連携していないファイルで行われていますが、その価値を軽視すべきではありません。 電子メールや XML などの半構造化データ: 未加工の XML ファイルから検索および予約データを取得すると、オンライン旅行ビジネスの予約率が低いことを特定するのに役立ちます。メールの内容を分析すると、顧客維持率の向上に役立つセンチメントの傾向とパターンが明らかになります。 カスタマーインタラクション分析で直面する 3 つの課題と推奨する解決策 課題 1: 企業が保存しているさまざまなデータで何ができるか? データからビジネス価値を生み出すことに成功した組織は同業他社よりも優れたパフォーマンスを発揮します。データストレージのニーズが高まるにつれ、企業はデータをホストするためのスケーラブルで費用対効果の高いソリューションを検討しています。データレイクは、すべての構造化データと非構造化データをあらゆる規模で保存できる一元化されたストレージです。データレイクには、基幹業務アプリケーションからのリレーショナルデータと、モバイルアプリ、IoT デバイス、ソーシャルメディアからの非リレーショナルデータが格納されます。 ABERDEEN の調査によると、データレイクを導入した組織は、有機的な収益成長において類似企業を 9% 上回っています。これらのリーダーたちは、ログファイル、ウェブサイトのクリックからのデータ、ソーシャルメディア、データレイクに保存されているインターネット接続デバイスなどの新しいソースに対して、機械学習などの新しいタイプの分析を実行することができました。これにより、顧客を引き付けて維持し、生産性を高め、積極的にデバイスを保守し、情報に基づいた意思決定を行うことで、ビジネスの成長の機会をより早く特定して行動できるようになりました。 AWS LakeFormation は安全なデータレイクを簡単に作成し、データを幅広い分析に利用できるようにします。 Lake Formation を利用すると、業務効率の向上、データの一元化と民主化、アドホックレポートの作成と公開が可能になります。 課題 2: データを視覚化する使いやすいセルフサービスツールがあるか? クラウドビジネスインテリジェンスツールは、ビジネスの意思決定者がインタラクティブなダッシュボードを作成したり、データを視覚化したり、パターンを検出したり、データ内の外れ値の特定に役立ちます。これらのダッシュボードを作成すると、さまざまな部門の運用指標をまとめることができるため、多くのレポートを 1 か所に集約できます。 Amazon QuickSight は統合されたビジネスインテリジェンスによってデータ駆動型の組織を強化します。QuickSight ダッシュボードを活用して隠れた傾向を明らかにし、コスト要因を認識し、小売販売実績、製造効率、医師の品質評価などの分野の予測を改善します。自動化に関心のある場合は、レポートの頻度をスケジュールすることから始めるのが最適です。最終的には QuickSight などの分析ツールが新しい機会を開拓し、社内の業務効率を向上させます。 課題 3: データのクエリと分析を簡単に行うにはどのようなツールを使用できますか? 全文検索、リアルタイム分析、機械学習などのセルフサービス データ分析メカニズムは、ビジネス オーナーが有意義な洞察を発見し、独自に予測を生成するのに役立ちます。 AWS での分析 は、高い費用対効果、スケーラビリティ、最低コストを実現する専用のサービスを提供します。大規模な分析を行うことで、企業はマーケティングキャンペーンのデータを解釈し、コンテンツエンゲージメントを追跡し、過去の履歴に基づいて製品価格モデルを生成し、顧客獲得戦略を改善できます。 製造業事例:分析を活用して顧客の購入意向をよりよく理解する方法 Mikatasa はインドネシアを拠点とする家族経営の会社で、40 年以上にわたって塗料と接着剤を製造してきました。彼らの製品は高品質で定評があり、15,000 を超える国内小売店で販売されています。 Mikatasa には 30 人のメンバーからなるチームがいて、バックエンドのタスクに集中していました。 AWS のフルマネージド分析サービスを利用することで、メンテナンスに必要なリソースを 50% 削減し、顧客向けのフロントエンドソリューションの構築に集中できるようになりました。 AWS クラウドへの移行は 小売データの収集と分析の基礎を築くのに役立ちました 。 Mikatasa のマネージングディレクター Martin Hendriadi Fu 氏は次のように述べています。「私たちは未加工データの上に何層にも重なる情報を構築していますが、AWS はそのデータにアクセスして分析し、情報共有を容易にするという便利な機能を備えています。 ヘルスケア業界事例:データソースを接続して社内外の効率を向上 Healthvana は米国を拠点とする企業で郡や市の機関を含む医療提供者に代わって患者に健康記録を提供しています。Healthvana は複数の AWS サービスを活用しています。 データ分析は Healthvana の製品とその将来の成長にとって極めて重要です。 Healthvana は AWS 上でサービスを拡張し、3,500 万件を超える新型コロナウイルス感染症 (COVID-19) 検査結果と新型コロナウイルス感染症 (COVID-19) ワクチン接種記録を提供しました。Healthvana は Amazon Redshift データウェアハウスサービスを使用して、重要な顧客の健康記録レポートを迅速に生成します。また、データウェアハウスをほぼリアルタイムで更新することもできます。顧客にレポートを送信できるようになったと同時に、初期対応者や医療従事者からの医療記録リクエストの管理に費やす時間を削減することもできました。社内的には価値の低い活動に費やす時間が削減されるため、 コスト削減を実現し、イノベーションを加速するのに役立ちます 。 次のステップ 顧客データ分析を使用することで、企業は顧客の好み、行動パターン、問題点に関する貴重な洞察を得ることができます。これにより、製品やサービスを改善し、マーケティング活動をパーソナライズし、最終的には顧客満足度とロイヤルティを高め、収益と成長機会を増やすことができます。AWS はお客様のあらゆるデータ分析ニーズを満たす幅広い分析サービスを提供し、あらゆる規模や業界の組織がデータを活用してビジネスを改革できるようにします。データ分析を活用して ビジネスをスマートにする 方法について詳しく学びましょう。 翻訳はソリューションアーキテクトの酒井 賢が担当しました。原文は こちら です。
(この記事は、 How to Create a Data Governance Strategy for Your Small or Medium Business を翻訳したものです。) 「データガバナンス」という言葉を聞くと、医療や金融サービスなどの規制の厳しい業界を連想するかもしれません。しかし、あらゆる業界の賢明な企業は、データを効果的に活用することで競争上の優位性がもたらされることを認識しています。データに基づく意思決定に関する 2021 年のレポートによると、「データおよび分析の専門家の 66% がデータガバナンスプログラムを実施する際、最大のメリットとして データ品質の向上 を経験しています。この傾向はすでに成熟したデータガバナンスの枠組みを導入している組織では 83% に上昇します。」 企業はリモートコラボレーションや在宅勤務時のセキュリティを強化するために、データワークフローの一部をクラウドに移行しているかもしれません。気づいていないかもしれませんが、データ中心のビジネスアプローチを確立するための第一歩を踏み出したということです。クラウドにおいて、組織のデータは確立されたパターンとプロセスを通じて信頼性が高くなければなりません。これにより、あなたのチームはビジネスイニシアチブについて正確な洞察を得ることができます。 データガバナンスが見落とされると、障害になる可能性があります。一方でお客様からは次に挙げる理由で専門家による支援が求められています。 ビジネスデータの価値を伝える推進者がいない 予算の制約 従来のチームメンバーのスキルギャップ ツール自体がガバナンスの役目を果たすと考えている ガバナンスはイノベーションに対する制約と見なされることがあります。この見解は主に、ガバナンスがこれまでどのように導入されてきたか、つまり指揮統制型のアプローチを活用した万能の解決策として導入されてきたことに由来しています。もう 1 つの要因は規制順守、つまり短期的な目標を達成するために長期的なイノベーションを犠牲にすることです。 データガバナンスとは データガバナンスとは、組織のデータ整合性、可用性、使いやすさ、セキュリティを確保するためのプロセスです。ビジネスにとっての重要性を考えると、それをどのように管理するかが非常に重要です。一般的なガバナンスのカテゴリには次のものがあります。 トランザクションデータ リファレンスデータ 顧客データ 製品データ データガバナンスにはポリシー、手順の策定、テクノロジーの活用、プロセスの運用、データ所有文化の確立が含まれます。つまり、データの取り込み、処理、アクセス、そして最終的な廃棄の方法に適用される内部標準を設定することです。また、政府機関、業界団体、およびその他の関連する第三者が設定した基準への準拠も保証します。 中堅中小企業には大量の顧客データを管理、および維持するためのリソースや時間がない可能性があります。しかし、不十分なデータ管理がもたらす真のコストは金銭だけではありません。データの紛失や破損は、顧客からの信頼低下につながります。データガバナンスとは、組織が独自のデータを管理および保護するためのベストプラクティスを確実に順守するためのポリシーを確立することです。 ここで問題となるのは、中堅中小企業がデータガバナンスについて考慮すべきかどうかということです。 データガバナンス戦略がないことのリスク 企業は組織の人員が 10 人でも 100 人でも、データガバナンスを強く考慮する必要があります。効果的な戦略を実施することで、次の 5 つの一般的な課題を軽減できます。 信頼性の低下: 信頼性が低い、または不正確なデータは企業の評判を傷つけ、場合によっては取り返しのつかないこともあります(とくに競争の激しい業界では)。 データ管理コストの増加: 重複データや冗長データの保管コスト、コンプライアンス違反の罰金もデータ管理コストの一因となります。 データの悪用: ガバナンスがなければ、同じデータセットから異なる結論や誤った結論が導き出される可能性があります。 規制およびコンプライアンス違反: 規制機関によって課される罰金は大企業ほど簡単には吸収できない可能性があります。 セキュリティイベント: 管理されていないデータに対し、外部の第三者や権限のないユーザーが情報にアクセスする可能性があります。 ビジネス要件に基づくデータガバナンス戦略の実施方法 ガバナンスアプローチは組織の事業運営状況を考慮する必要があります。たとえば、競争の激しい業界で状況の変化への対応が遅れると、ビジネスに多大なコストがかかる可能性があるため、機敏な意思決定を採用する必要があります。 多くのデータガバナンスのフレームワークが存在しますが、同じビジネスは 2 つとないため、意思決定者と共に有意義な基盤を構築するのために役立つ活動に焦点を当てます。 図1: データガバナンスのモデル 1. 目標と優先順位の設定 最初のステップは組織の具体的な優先事項、目標、およびビジネスの成果を特定することです。例としては次のようなものがあります。 データセキュリティの強化によるリスクの最小化 規制要件への準拠 コスト削減の実現 分析データの価値の向上 ビジネスの成果に責任を負う関係者(CIO 、 CTO 、 CDO)と成功の測定に用いる指標を特定します。たとえばデータ品質、セキュリティ、リネージ(データソースから使用までのデータの流れ)などの指標があります。経営陣に技術担当の役員がいない場合は、会社のデータを密に扱う部門とその責任者を見つけてください。 2. 評価と分析­ 具体的な成果を特定したのち、データガバナンスの推進者を選びましょう。技術やビジネスの領域に精通している人材が求められます。彼らは以下を支援します。 データ管理および統制プロセスを評価し、特定されたビジネス成果をサポートするか否かを判断する データ収集、保守、伝達プロセスの分析 3. 定義 ビジネスの成果とリスク指標に基づいて主要業績評価指標 (KPI) を設定します。多くのお客様はデータガバナンスに直接関連するプロセスの管理者を含むチームを構築したいと考えています。このチームのメンバーは以下のとおりです。 データ所有者: データがすべてのシステムで一貫して安全に管理されるようにする責任があります データ管理者: 特定のデータセットのセキュリティを維持する責任があります データスチュワード: データの品質を確保する責任があります 企業規模によっては、個人が複数の役割を担う場合があります。効果的なデータガバナンスの鍵はプロセスを定義した上で、標準化するための意思決定と実行権限を持つ個人に対し、データ領域の責任を割り当てることです。決定と行動には次のものが含まれます。 データ資産に対するデータドメインの定義 各ドメインのアクセスと権限の定義 各データドメインにおいて、データを記録するために用いるシステムの定義 決定された内容に基づいてポリシーを策定する 4. 実行 データガバナンスチームによって定義されたポリシーとプロセスを実装するツールを選択します。業界にはいくつかのツールが存在しますが、要件に合った適切なツールを選択する必要があります。たとえば、 AWS Lake Formation は大規模なセキュリティ管理とガバナンスを簡素化する機能を提供し、データストアへのアクセス制御も可能にします。 見落とされがちな領域の 1 つとして、ガバナンスチーム以外への教育があります。データガバナンスの基準とポリシーを組織に知らせるためのコミュニケーション計画を作成します。一般的に共有すべき情報には次のものが含まれます。 データガバナンスに関するルールとポリシー。企業は新入社員を教育し、既存の従業員の知識を更新するために、これを毎年のトレーニングとして取り入れています データガバナンスの利点および、データガバナンスが日々の業務でより良い意思決定を行うためにどのように役立つのか データの問題やセキュリティイベントが発生した場合の連絡先とエスカレーションルール 必要に応じたデータガバナンスプロセスの継続的な変更 5. 評価と統制 データガバナンスは継続的かつ進化し続けるプロセスです。だからこそ、目的地ではなく旅として考えるべきです。データガバナンスのポリシーと手順を運用したのち、次のステップをおすすめします。 特定のビジネス成果の KPI に基づいてレポートを作成することにより、データガバナンスプロセスの有効性を測定および評価します 評価に基づいて、データガバナンスプロセスに変更を加えます エンドユーザーからのフィードバックを求め、データライフサイクルを改善します AWS クラウドはこのプロセスにどのように役立ちますか? AWS はテクノロジーをさまざまな方法で適用して組織を変革できるよう支援します。これにより、もっとも重要な資産を管理し、イノベーションを実現し、達成できることの可能性を再考できるようになります。 15 年間にわたり 150 万人以上のお客様がデータサービスを利用してきた AWS は、もっとも経験豊富で信頼できるクラウドサービスプロバイダーの 1 つです。AWS ではデータガバナンスを進めるうえで役立つサービスを提供しています。 モニタリングと監査証跡 Amazon CloudWatch はログ、メトリクス、イベントからモニタリングデータと運用データを収集します Amazon CloudTrail はユーザーのアクティビティと API の使用状況を追跡します セキュリティとデータアクセス管理 AWS Identity and Access Management はさまざまなレベルのデータへのアクセスを制御するのに役立ちます データセキュリティと一元管理 Amazon Macie は機械学習を用いて機密データを検出する、フルマネージド型のデータセキュリティおよびプライバシーサービスです AWS Lake Formation はセキュリティ管理とアクセス制御の簡素化に役立ちます データ統合、変換、検出、保存 Amazon Simple Storage Service (Data Lake and Glacier) AWS Glue デジタル化が初めて、またはさらにクラウドの利点を追加したいとお考えですか? AWS スマートビジネスで、業界、メリット、ユースケースごとにソリューションをご覧ください 次のステップ 企業は安全かつ費用対効果の高い方法でデータを最大限活用することを求めており、データガバナンスをビジネス目標に合わせるための経営陣によるスポンサーシップの必要性を取り上げました。責任を明確に定義した所有権の割り当てにより、成功に必要な説明責任を果たすことができます。データガバナンスを繰り返し実装することで、明確に定義された KPI と指標に対して効果的かつタイムリーな評価が可能になります。 反復的かつ適応的なアプローチを採用することで、データガバナンスのメリットが加速します。ビジネス目標の達成を可能にするデータガバナンス戦略の策定をお手伝いします。 中堅中小企業のモダナイズについて詳しく学び、 AWS の 専門家にお問い合わせください 。 翻訳はソリューションアーキテクトの酒井 賢が担当しました。原文は こちら です。
7 月に、 Amazon Bedrock のエージェント のプレビューを発表しました。これは、デベロッパーが生成系 AI アプリケーションを作成してタスクを完了するための新機能です。9月13日は、 エージェントを使用して基盤モデル (FM) を会社のデータソースに安全に接続する 新しい機能をご紹介します。 ナレッジベース があれば、エージェントを使用して Bedrock の FM に追加データへのアクセスを提供できます。これにより、FM を継続的に再トレーニングしなくても、モデルはより関連性が高く、コンテキスト固有の正確な応答を生成できます。ユーザーの入力に基づいて、エージェントは適切なナレッジベースを特定し、関連情報を取得し、その情報を入力プロンプトに追加します。これにより、モデルに追加のコンテキスト情報が与えられ、補完することができます。 Amazon Bedrock のエージェントは、これを実現するために検索拡張生成 (RAG) と呼ばれる概念を使用しています。ナレッジベースを作成するには、データの Amazon Simple Storage Service (Amazon S3) の場所を指定し、埋め込みモデルを選択し、ベクトルデータベースの詳細を指定します。Bedrock はデータを埋め込みに変換し、埋め込みをベクトルデータベースに保存します。次に、ナレッジベースをエージェントに追加して、RAG ワークフローを有効にできます。 ベクトルデータベースでは、 Amazon OpenSearch Serverless 用ベクトルエンジン 、 Pinecone 、 Redis Enterprise Cloud から選択できます。ベクトルデータベースの設定方法については、この記事の後半で詳しく説明します。 検索拡張生成、埋め込み、ベクトルデータベースの入門 RAG は特定の技術セットではなく、FM がトレーニング中に見なかったデータにアクセスできるようにするための概念です。RAG を使用すると、モデルを継続的に再トレーニングしなくても、企業固有のデータなどの追加情報で FM を強化できます。 モデルを継続的に再トレーニングすると、計算負荷が高くコストがかかるだけではありません。モデルを再トレーニングするや否や、会社は既に新しいデータを生成していて、モデルが持つ情報が古くなっている可能性があります。RAG は、実行時にモデルが追加の外部データにアクセスできるようにすることで、この問題に対処しています。次に、関連データがプロンプトに追加され、補完の関連性と精度の両方が向上します。 このデータは、ドキュメントストアやデータベースなど、さまざまなデータソースから取得できます。ドキュメント検索は、一般的に、次の図に示すように、埋め込みモデルを使用してドキュメントまたはドキュメントのチャンクをベクトル埋め込みに変換し、そのベクトル埋め込みをベクトルデータベースに保存することで実装します。 ベクトル埋め込みには、ドキュメント内のテキストデータの数値表現が含まれます。それぞれの埋め込みは、データのセマンティックまたはコンテキスト上の意味を捉えることを目的としています。各ベクトル埋め込みは、多くの場合、埋め込みが作成された元のコンテンツへの参照などの追加のメタデータとともに、ベクトルデータベースに入れられます。次に、ベクトルデータベースはベクトルにインデックスを付けます。これはさまざまな方法で実行できます。このインデックスにより、関連データをすばやく取得できます。 従来のキーワード検索と比較して、ベクトル検索では、キーワードが完全に一致しなくても関連する結果を見つけることができます。例えば、「製品 X のコストはいくらですか」と検索する場合、ドキュメントに「製品 X の価格は […] です」と記載されていると、「価格」と「コスト」は異なる単語であるため、キーワード検索が機能しない可能性があります。ベクトル検索では、「価格」と「コスト」は意味的に似ていて同義なので、正確な結果が返されます。ベクトル類似度は、ユークリッド距離、コサイン類似度、ドット積類似度などの距離メトリクスを使用して計算されます。 次に、ベクトルデータベースをプロンプトワークフロー内で使用して、下の図に示すように、入力クエリに基づいて外部情報を効率的に取得します。 ワークフローは、ユーザー入力プロンプトから始まります。同じ埋め込みモデルを使用して、入力プロンプトのベクトル埋め込み表現を作成します。次に、この埋め込みを使用してデータベースに類似のベクトル埋め込みをクエリすると、最も関連性の高いテキストがクエリ結果として返されます。 次に、そのクエリ結果がプロンプトに追加され、拡張されたプロンプトが FM に渡されます。このモデルは、次の図に示すように、プロンプト内の追加コンテキストを使用して補完を生成します。 Amazon Bedrock のエージェント に関するブログ記事で説明したフルマネージド型エージェントのエクスペリエンスと同様に、Amazon Bedrock のナレッジベースはデータインジェストワークフローを管理し、エージェントは RAG ワークフローを管理します。 Amazon Bedrock のナレッジベースの開始方法 Amazon S3 などのデータソースを指定してナレッジベースを追加したり、Amazon Titan Embeddings などの埋め込みモデルを選択してデータをベクトル埋め込みに変換したり、送信先ベクトルデータベースを選択してベクトルデータを保存したりできます。Bedrock は、ベクトルデータベースへの埋め込みの作成、保存、管理、更新を行います。 エージェントにナレッジベースを追加すると、エージェントはユーザー入力に基づいて適切なナレッジベースを識別し、関連情報を取得して情報を入力プロンプトに追加します。これにより、次の図に示すように、応答を生成するためのより多くのコンテキスト情報がモデルに提供されます。ナレッジベースから取得するすべての情報には、透明性を高め、ハルシネーションを最小限に抑えるためのソース属性が付いています。 これらのステップを詳しく説明しましょう。 Amazon Bedrock のナレッジベースを作成する あなたが税務コンサルティング会社のデベロッパーで、米国の税務申告に関する質問に回答できる生成系 AI アプリケーション (TaxBot) をユーザーに提供したいとしましょう。&nbsp;まず、関連する税務書類を保持するナレッジベースを作成します。次に、このナレッジベースにアクセスできるように Bedrock のエージェントを設定し、そのエージェントを TaxBot アプリケーションに統合します。 開始するには、 Bedrock コンソール を開き、左側のナビゲーションペインで [Knowledge base] (ナレッジベース) を選択し、次に [Create knowledge base] (ナレッジベースの作成) を選択します。 ステップ 1 – ナレッジベースの詳細を入力します。 ナレッジベースの名前と説明 (オプション) を入力します。また、Amazon Bedrock の信頼ポリシー、ナレッジベースで使用する S3 バケットへのアクセス許可、およびベクトルデータベースへの読み取り/書き込み許可を備えた AWS Identity and Access Management (IAM) ランタイムロールを選択する必要があります。必要に応じてタグを割り当てることもできます。 ステップ 2 – データソースをセットアップします。 データソース名を入力し、データの Amazon S3 ロケーションを指定します。サポートされているデータ形式には、.txt、.md、.html、.doc と .docx、.csv、.xls、.xlsx、.pdf ファイルが含まれます。Bedrock でデータの復号化と暗号化を行えるようにする AWS Key Management Service (AWS KMS) キーと、Bedrock がデータを埋め込みに変換している間の一時的なデータストレージ用の別の AWS KMS キーを指定することもできます。 Amazon Titan Embeddings などの埋め込みモデル、テキスト、使用しているベクトルデータベースを選択します。ベクトルデータベースでは、前述のように、Amazon OpenSearch Serverless 用ベクトルエンジン、Pinecone、または Redis Enterprise Cloud から選択できます。 ベクトルデータベースに関する重要な注意事項: Amazon Bedrock がお客様に代わってベクトルデータベースを作成することはありません。サポートされているオプションのリストから新しい空のベクトルデータベースを作成し、ベクトルデータベースのインデックス名とインデックスフィールドとメタデータフィールドのマッピングを指定する必要があります。このベクトルデータベースは Amazon Bedrock 専用である必要があります。 Amazon OpenSearch Serverless 用ベクトルエンジンのセットアップがどのようなものかをお見せしましょう。 デベロッパーガイドと この AWS ビッグデータブログ記事 で説明されているように OpenSearch Serverless コレクションをセットアップしたと仮定して、OpenSearch Serverless コレクションの ARN を指定し、ベクトルインデックス名、ベクトルフィールドとメタデータフィールドのマッピングを指定します。 Pinecone と Redis Enterprise Cloud の設定は似ています。Bedrock のベクトルデータベースをセットアップして準備する方法の詳細については、この Pinecone のブログ記事 と Redis Inc. のブログ記事 をチェックしてください。 ステップ 3 – 確認して作成します。 ナレッジベースの設定を確認し、 [Create knowledge base] (ナレッジベースの作成) を選択します。 ナレッジベースの詳細ページに戻り、新しく作成したデータソースの [Sync] (同期) を選択します。データソースに新しいデータを追加するたびに、Amazon S3 データをベクトル埋め込みに変換し、その埋め込みをベクトルデータベースにアップサートする取り込みワークフローを開始します。データ量によっては、このワークフロー全体に時間がかかる場合があります。 次に、ナレッジベースをエージェント設定に追加する方法を説明します。 ナレッジベースを Amazon Bedrock のエージェントに追加する Amazon Bedrock のエージェントを作成または更新するときに、ナレッジベースを追加できます。 Amazon Bedrock のエージェントに関するこの AWS ニュースブログの記事 で説明されているように、エージェントを作成します。 私の税務ボットの例として、「TaxBot」というエージェントを作成し、基盤モデルを選択し、ステップ 2 でエージェントに次の指示を行いました。「あなたはアメリカの税務申告に関するユーザーの質問に答えてくれる、親切でフレンドリーなエージェントです」。 ステップ 4 では、以前に作成したナレッジベースを選択し、そのナレッジベースをいつ使用するかを説明する指示をエージェントに提供できます。 これらの指示は、特定のナレッジベースを検索に使用すべきかどうかをエージェントが判断するのに役立つため、非常に重要です。エージェントは、ユーザー入力と利用できるナレッジベースの指示に基づいて適切なナレッジベースを特定します。 私の税務ボットの例として、ナレッジベース「Taxbot-Knowledge-Base」と「税務申告に関する質問に答えるには、このナレッジベースを使ってください」という指示を追加しました。 エージェントの設定が完了したら、エージェントをテストし、追加されたナレッジベースをどのように使用しているかをテストできます。エージェントがナレッジベースから取得した情報のソース属性をどのように提供しているかに注目してください。 生成系 AI の基礎を学ぶ 大規模言語モデル (LLM) を使用した生成系 AI は、RAG を含む LLM を使用して生成系 AI アプリケーションを構築する方法を学びたいデータサイエンティストとエンジニアを対象とした 3 週間のオンデマンドコースです。Amazon Bedrock で構築を始めるのに最適な基礎コースです。 今すぐ LLM で生成系 AI を申請しましょう。 サインアップして、Amazon Bedrock (プレビュー) についての詳細を学ぶ Amazon Bedrock は現在プレビューでご利用いただけます。プレビューの一部として Amazon Bedrock のナレッジベースを利用したい場合は、普段の AWS サポート担当者にお問い合わせください。私たちは定期的に新規顧客へアクセスを提供しています。詳細については、 Amazon Bedrock の機能ページにアクセスし 、 サインアップして Amazon Bedrock について詳しく学んでください 。 —&nbsp; Antje 原文は こちら です。
vector engine for Amazon OpenSearch Serverless &nbsp;のプレビューリリースを発表できることを嬉しく思います。ベクトルエンジンは、 Amazon OpenSearch Serverless &nbsp;でシンプルでスケーラブルでパフォーマンスの高い類似検索機能を提供します。これにより、最新の機械学習 (ML) 拡張検索エクスペリエンスと生成人工知能 (AI) アプリケーションを、基盤となるベクトルデータベースインフラストラクチャを管理することなく簡単に構築できるようになります。この投稿では、ベクトルエンジンの特徴と機能をご紹介します。 拡張 ML 検索とベクトル埋め込みによる生成 AI の使用 膨大なデータセットを処理し、自動化されたコンテンツを生成し、インタラクティブで人間のような応答を提供する機能を備えた生成 AI は、あらゆる業種の組織で急速に導入されています。現在多くの顧客は、チャットボット、質疑応答システム、パーソナライズされたレコメンデーションなどの高度な会話生成 AI アプリケーションを統合することにより、エンドユーザー体験とデジタルプラットフォームとのインタラクションを変革する方法を模索しています。これらの会話型アプリケーションを使用すると、自然言語で検索およびクエリを実行し、セマンティックな情報、ユーザーの意図、クエリのコンテキストを考慮して、人間に非常に似た応答を生成できます。 ML 拡張検索アプリケーションと生成 AI アプリケーションは、テキスト、画像、オーディオ、映像のデータの数値表現であるベクトル埋め込みを使用して、動的で関連性の高いコンテンツを生成します。ベクトル埋め込みは顧客が持つ独自のデータを利用してトレーニングされ、情報の意味属性とコンテキスト属性を表します。理想的には、これらの埋め込みは既存の検索エンジンやデータベース内など、ドメイン固有のデータセットの近くに保存および管理することです。これにより、結果を統合するための外部のデータソースや追加のアプリケーションコードに依存せずに、ユーザーのクエリを処理して最も近いベクトルを見つけ、それらを追加のメタデータと組み合わせることができます。多くの顧客は構築が簡単で、プロトタイプから本番環境に迅速に移行可能なベクトルデータベースの選択肢を求めています。それにより、本来の目的である差別化されたアプリケーションの作成に集中できます。OpenSearch Serverless のベクトルエンジンは、基盤となるインフラストラクチャを考慮することなく、数十億のベクトル埋め込みをリアルタイムで保存、検索、取得し、正確な類似性マッチングやセマンティック検索を実行できるようにすることで、OpenSearch の検索機能を拡張します。 ベクトルエンジンの機能と可能性 OpenSearch Serverless 上でベクトルエンジンを構築することで、OpenSearchの堅牢なアーキテクチャを継承し、恩恵を受けることができます。例えば、バックエンドインフラストラクチャのサイジング、チューニング、スケーリングについて心配する必要がなくなります。ベクトルエンジンは、変化するワークロードパターンと要求に適応してリソースを自動的に調整し、一貫して高速なパフォーマンスとスケールを提供します。ベクトルの数がプロトタイピング時の数千から本番環境では数億以上に増加するにつれて、ベクトルエンジンはシームレスに拡張され、インフラストラクチャを拡張するためにインデックスの再作成やデータを再度ロードする必要はありません。さらに、ベクトルエンジンはインデックス作成と検索ワークロード用に別個のコンピューティングを備えているため、ユーザーが体験するクエリのパフォーマンスに影響を与えずに、ベクトルをリアルタイムでシームレスに取り込み、更新、削除できます。全てのデータは&nbsp; Amazon Simple Storage Service (Amazon S3) に保存されているため、Amazon S3 (イレブンナイン) と同じデータ耐久性保証が得られます。まだプレビュー段階ではありますが、ベクトルエンジンはアベイラビリティ ゾーンの停止やインフラストラクチャ障害に備えた冗長性を備えた実稼働ワークロード向けに設計されています。 OpenSearch Serverless のベクトルエンジンは、信頼性が高く正確な結果を提供することが実証されている、オープンソース OpenSearch プロジェクトの k近傍法アルゴリズム&nbsp; (kNN) を利用しています。現在、多くのお客様はアプリケーションでセマンティック検索とパーソナライゼーションを提供するために、マネージドクラスターで OpenSearch kNN 検索を使用しています。ベクトル エンジンを使用すると、サーバーレス環境のシンプルさで同じ機能を得ることができます。ベクトルエンジンは、ユークリッド距離、コサイン類似度、ドット積などの一般的な距離メトリックをサポートし、16,000 次元に対応できるため、幅広い基盤モデルやその他の AI/ML モデルのサポートに適しています。また、数値、ブール値、日付、キーワード、ジオポイントといったメタデータや、保存されたベクトルにさらにコンテキストを追加するための説明情報のテキストなど、さまざまなデータ型を持つフィールドを保存することができます。複数のデータ型を同じ場所に配置すると、複雑さと保守性が軽減され、データの重複やバージョン互換性の問題、ライセンスの問題が回避されアプリケーションスタックが効果的に簡素化されます。ベクトルエンジンは、オープンソース OpenSearch と同様の API をサポートしているため、全文検索、高度なフィルタリング、集計、地理空間クエリ、データを高速に取得するためのネストされたクエリ、高度な検索結果などの豊富なクエリ機能を利用できます。たとえば、ユースケースとしてリクエストを投げたユーザーから 15 マイル以内の結果を見つける必要がある場合、ベクトルエンジンはこれを 1 つのクエリで実行できるため、2 つの異なるシステムを維持し、アプリケーションロジックを通じて結果を結合する必要がなくなります。LangChain や Amazon Bedrock 、 Amazon SageMaker を使用すると、好みの ML および AI システムをベクトルエンジンと簡単に統合できます。 ベクトルエンジンは、画像検索、ドキュメント検索、音楽検索、製品のレコメンド、ビデオ検索、位置ベースの検索、不正検出、異常検出など、さまざまなドメインにわたる幅広いユースケースをサポートします。また、我々は語彙検索手法と高度な ML および生成 AI 機能を組み合わせたハイブリッド検索の傾向が高まると予想しています。たとえば、ユーザーが電子商取引 Web サイトで「赤いシャツ」を検索する場合、セマンティック検索は語彙 (BM25) 検索に実装されている調整および強化ロジックを維持しながら、赤のすべての色合いを取得することで検索範囲を拡大するのに役立ちます。OpenSearch フィルタリングを使用すると、サイズ、ブランド、価格帯、近くの店舗の在庫状況に基づいて検索を絞り込むオプションをユーザーに提供することで検索結果の関連性をさらに高めることができるため、さらにパーソナライズされた正確なエクスペリエンスが可能になります。ベクトル エンジンのハイブリッド検索サポートにより、単一のクエリ呼び出し内でベクトルの埋め込み、メタデータ、説明情報をクエリできるため、複雑なアプリケーションコードを構築することなく、より正確でコンテキストに関連した検索結果を簡単に提供できるようになります。 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI)、または AWS ソフトウェア開発キット (AWS SDK) を使用して、OpenSearch Serverless でベクトル検索のコレクションを作成することで、ベクトルエンジンを数分で開始できます。コレクションは、ワークロードをサポートするためのインデクシングされたデータの論理グループであり、物理リソースはバックエンドで自動的に管理されます。必要なコンピューティングまたはストレージの量をあらかじめ決定したり、システムが正常に実行されていることを確認するためにシステムを監視する必要はありません。OpenSearch Serverless は、Time-series、Search、ベクトル検索という 3 つの使用可能なコレクションタイプに対して、さまざまなシャーディングおよびインデックス作成戦略を適用します。データの取り込み、検索およびクエリに使用されるベクトルエンジンのコンピューティング能力は、OpenSearch コンピューティングユニット (OCU) で測定されます。1 つの OCU は、128 次元の場合は 400 万のベクトル、768 次元の場合は 50 万のベクトルを 99 % の再現率で処理できます。ベクトルエンジンは可用性の高いサービスである OpenSearch サーバーレス上に構築されており、少なくとも 4 つの OCU (プライマリとスタンバイを含む取り込み用の 2 つの OCU、およびアベイラビリティーゾーン全体にわたる 2 つのアクティブなレプリカによる検索用の 2 つの OCU) が アカウント内の最初のコレクションに対して 必要です。同じ&nbsp; AWS Key Management Service (AWS KMS) キーを使用する後続のすべてのコレクションはそれらの OCU を共有できます。 ベクトル埋め込みを始める コンソールを使用してベクトル埋め込みの使用を開始するには、次の手順を実行します。 OpenSearch Serverless コンソールで新しいコレクションを作成します。 名前とオプションの説明を入力します。 現在、ベクトル埋め込みはベクトル検索コレクションによってのみサポートされています。したがって、 Collection type で&nbsp; Vector search を選択します。 次に暗号化、ネットワーク、データアクセス ポリシーなどのセキュリティポリシーを構成する必要があります。 今回は新しい&nbsp; Easy create&nbsp; オプションを利用していきます。 これによりセキュリティ構成が最適化され、迅速にオンボーディングできます 。ベクトルエンジン内のすべてのデータはデフォルトで転送中も保存中も暗号化されます。独自の暗号化キーを使用するか、コレクションまたはアカウント専用のサービスによって提供される暗号化キーを使用するかを選択できます。コレクションをパブリックエンドポイントまたは VPC 内でホストすることを選択できます。ベクトルエンジンはきめ細かい&nbsp; AWS Identity and Access Management (IAM) アクセス許可をサポートしているため、暗号化、ネットワーク、コレクション、インデックスを作成、更新、削除できるユーザーを定義でき、組織の権限統制を行えます。 セキュリティ設定を適切に行ったら、コレクションの作成をします。 コレクションが正常に作成されたら、ベクトルインデックスを作成できます。この時点で、API またはコンソールを使用してインデックスを作成できます。インデックスは、共通のデータスキーマを持つドキュメントのコレクションであり、ベクトル埋め込みやその他のフィールドを保存、検索、取得する方法を提供します。ベクトルインデックスは最大 1,000 フィールドをサポートします。 ベクトル インデックスを作成するには、ベクトルフィールド名、次元、距離メトリックを定義する必要があります。 ベクトルインデックスは、最大 16,000 次元と 3 種類の距離メトリック (ユークリッド、コサイン、ドット積) をサポートします。 インデックスが正常に作成されたら、OpenSearch の強力なクエリ機能を使用して包括的な検索結果を取得できます。 次の例は OpenSearch API を使用して、タイトル、説明、価格、場所の詳細をフィールドとして持つ単純な不動産の情報を持ったインデックスを簡単に作成できることを示しています。このインデックスはクエリ API を使用することで、「シアトルにある 3000 ドル未満の 2 ベッドルームのアパートを探してください」などの検索リクエストに一致する正確な結果を効率的に提供できます。 プレビューから GA、それ以降について 本日、ベクトルエンジンのプレビューを発表し、すぐにテストを開始できるようになりました。前述のように、OpenSearch Serverless はインデックスと検索用の独立したコンピューティングリソースと組み込みの冗長性を備えた、エンタープライズ アプリケーションを強化する高可用性サービスを提供するように設計されています。 私たちは、皆様の多くが実験段階にあり、開発とテストのためのより経済的なオプションを望んでいることを認識しています。GA の前に、最初のコレクションのコストを削減できる 2 つの機能を提供する予定です。1 つ目は、アクティブなスタンバイまたはレプリカを使用せずにコレクションを起動できる新しい開発/テストオプションで、エントリーコストを 50% 削減します。ベクトルエンジンはすべてのデータを Amazon S3 に保持するため、耐久性が保証されます。2 つ目は、初期ワークロードが数万から数十万ベクトル前半の場合、最初に 0.5 OCU フットプリント( ワークロードをサポートするために必要に応じてスケールアップされます )を次元数に応じてプロビジョニングしてコストをさらに削減するオプションです。 これら 2 つのオプションで、最初のコレクションを導入するために必要な最小 OCU を 1 時間あたり 4 OCU から 1 OCU に削減します。 また、今後数か月以内に提供できるようにワークロードの一時停止と再開を実現できる機能の開発にも取り組んでいます。これらのユースケースの多くはデータの継続的なインデックス作成を必要としないため、これはベクトルエンジンにとって特に役立ちます。 最後に、私たちはキャッシュやマージなどの改善を含め、ベクトルグラフのパフォーマンスとメモリ使用量の最適化に熱心に取り組んでいます。 これらのコスト削減に取り組んでいる間、開発テストオプションが利用可能になるまで、ベクトルコレクションで月あたり最初の 1400 OCU 時間を無料で提供する予定です。これにより、ワークロードに応じて毎月最大 2 週間ベクトルエンジンのプレビューを無料でテストできるようになります。 まとめ OpenSearch Serverless のベクトルエンジンには、シンプルでスケーラブルかつ高性能なベクトルストレージおよび検索機能が導入されており、さまざまな ML モデルから生成された数十億のベクトルエ埋め込みをミリ秒単位の応答で簡単かつ迅速に保存およびクエリできるようになります。 OpenSearch Serverless 用のベクトルエンジンのプレビューリリースは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジア太平洋 (東京)、ヨーロッパ (フランクフルト)、ヨーロッパ (アイルランド)の 8 つのリージョンで利用可能になりました。 私たちは今後の展望に興奮しており、皆様のフィードバックはこの製品の進歩を導く上で重要な役割を果たします。OpenSearch Serverless のベクトルエンジンを試して、使用例、質問、フィードバックをコメントセクションで共有することをお願いしています。 今後数週間で、ベクトルエンジンを LangChain、Amazon Bedrock、SageMaker と統合する方法に関する詳細なガイダンスを提供する一連の投稿を公開する予定です。ベクトルエンジンの機能の詳細については、 our Getting Started with Amazon OpenSearch Serverless documentation &nbsp;をご参照ください。 About the authors Pavani Baddepudi は、 AWS の検索サービスのプリンシパルプロダクトマネージャーであり、OpenSearch サーバーレスのリード PM です。彼女の興味には、分散システム、ネットワーキング、セキュリティが含まれます。仕事以外のときは、ハイキングや新しい料理の探索を楽しんでいます。 Carl Meadows は AWS の製品管理ディレクターであり、Amazon Elasticsearch Service、OpenSearch、Open Distro for Elasticsearch、および Amazon CloudSearch を担当しています。Carl は、Amazon Elasticsearch Service が 2015 年に開始される前から働いています。彼は、エンタープライズ ソフトウェアおよびクラウド サービスの分野で長年働いてきました。仕事以外の時間は、音楽を作ったり録音したりすることを楽しんでいます。 このブログは Introducing the vector engine for Amazon OpenSearch Serverless, now in preview を翻訳したものになります。
この投稿では、 Amazon Relational Database Service (Amazon RDS) for SQL Server をセルフマネージド型の Active Directory と統合する方法を説明します。以前は、RDS for SQL Server インスタンスは AWS Managed Microsoft AD ディレクトリにしか接続できませんでした。次の図に示すように、AWS Managed Microsoft AD とオンプレミス AD 間の 信頼関係 を結んでオンプレミス AD を接続することができます。 セルフマネージド型 Active Directory サポートの開始により、RDS for SQL Server インスタンスをホストされている場所に関係なくセルフマネージド型 AD ドメインに直接参加させることができます。AD は、企業のデータセンター、 Amazon Elastic Compute Cloud (Amazon EC2)、またはその他のクラウドプロバイダーでホストできます。次の図は、セルフマネージド型の AD に参加する場合のシナリオを示しています。お客様環境と VPC 間のトラフィック用にAWS Direct Connect または VPN を設定できます。 ソリューション概要 セルフマネージド型 Active Directory で RDS for SQL Server を実装するには、まず Active Directory に次の 3 つのオブジェクトを作成する必要があります。 Amazon RDS for SQL Server をデプロイするための組織単位 (OU) Amazon RDS for SQL Server をデプロイと管理するための AD サービスアカウント 権限が制限された AD サービスアカウントの OU への委任 RDS for SQL Server インスタンスをデプロイするたびに、新しい OU と AD サービスアカウントを作成することをお勧めします。そうすることで、セキュリティの境界が広がります。 次の図は、ソリューションアーキテクチャを示しています。 AD オブジェクトの設定を簡単にするために、オブジェクトを作成して適切な権限を設定するための PowerShell スクリプトを作成しました。このスクリプトは ここ からダウンロードできます。 以下のセクションでは、AD OU と AD サービスアカウントを作成し、 AWS Secrets Manager で AWS Key Management Service (AWS KMS) キーとシークレットを作成して Amazon RDS AD サービスアカウントの認証情報を保存する手順について説明します。 まず、Amazon RDS for SQL Server をセルフマネージド型の Microsoft AD と統合するために必要な AD オブジェクトを作成します。Amazon RDS for SQL Server をデプロイする前に、PowerShell スクリプトを使用して前提条件をすべて作成します。具体的には、このスクリプトは以下を作成します。 RDS-MSSQL (または任意の名前) という名前の Amazon RDS for SQL Server 用の OU RDSServiceAccount (または任意の名前) という名前の Amazon RDS for SQL Server 用の AD サービスアカウントで、適切な最小権限権限が付与されている AD サービスアカウント 次に、サービスアカウント情報を保存する新しい Secrets Manager シークレットとシークレットを暗号化するための新しい KMS キーを作成します。サービスアカウント情報を保存したら、シークレットのリソース権限を更新して Amazon RDS サービスプリンシパルに GetSecretValue 権限を付与します。 最後に、RDS サブネットグループを作成してセルフマネージド型 AD と統合された RDS for SQL Server インスタンスをデプロイしてデプロイを検証します。 この記事で紹介したリソースの見積もり 独自のディレクトリを使用する場合は、必ず環境に合った情報を使用してください。 us-west-2 リージョンでは、リソースを 24 時間実行するための推定総コストは 29.54 USD です。次の表は、料金の詳細をまとめたものです。 Service Count Price per Hour (USD) Region Estimated 24 Hour Cost (USD) Calculations Secrets Manager secret 2 $0.00056 us-west-2 $0.03 = 0.00056 * 2 * 24 t3.large EC2 Windows instance 1 $0.1108 us-west-2 $2.66 = 0.1108 *24 t3.medium EC2 Windows instance 1 $0.06 us-west-2 $1.44 = 0.06 * 24 Amazon EBS General Purpose SSD (gp3) – storage 90 $0.08 GB-Month us-west-2 $0.24 = .08 * 90 * 86400 / 2,592,000 KMS service key 1 $0.0014 us-west-2 $0.03 = 0.0014 * 24 Amazon RDS for SQL Server Standard (single AZ – db.t3.xlarge) 1 $1.044 us-west-2 $25.06 = 1.044 *24 Amazon RDS database storage (General Purpose (SSD) storage) 20 $0.115 GB-Month us-west-2 $0.08 = .115 * 20 * 86400 / 2,592,000 前提条件 この記事では、以下のリソースをデプロイする必要があります。 Active Directory (セルフマネージド型または AWS Managed Microsoft AD を使用)。どちらも実装ステップと連携します。この記事では、 corp.example.com というドメイン名の単一ドメインコントローラーのセルフマネージド型 AD を使用します。この投稿では EC2 インスタンス上でブートストラップされたセルフマネージド型 AD を使用しているため、実稼働目的では使用しないでください。別のドメイン名を使用している場合は、必要に応じて更新してください。 EC2 Windows Server インスタンス (この投稿では MGMT EC2 インスタンスと呼びます) は、Active Directory 管理ツールと SQL Server Management Studio (SSMS) がインストールされた状態で AD に参加します。 新しい VPC に前提条件をデプロイするのに役立つ AWS CloudFormation テンプレートを提供しています。テンプレートは ここ からダウンロードできます。 CloudFormation テンプレートをデプロイ CloudFormation テンプレートをデプロイするには、以下の手順を実行します。 AWS CloudFormation コンソールで、[ スタックの作成 ] を選択します。 [ テンプレートファイルのアップロード ] を選択し、[ ファイルを選択 ] を選択します。 ダウンロードした CloudFormation テンプレートを参照し、[ 次へ ] を選択します。 [ スタック名 ] に RDS-Self-AD と入力します。 「 パラメータ 」セクションはデフォルトのままにします。 「 スタックオプションの設定 」ページで、デフォルトのままにして [ 次へ ] を選択します。 「 スタックの確認 」ページで、「 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。 」をチェックして、[ 送信 ] を選択します。 Active Directory OU とサービスアカウントの作成 Active Directory OU とサービスアカウントを設定するには、次の手順を実行します。 Secrets Manager コンソールで、 OnPremAdministratorSecret シークレットに移動します。 シークレット詳細ページ で [ シークレットの値を取得する ] を選択します。 後で使用できるように、パスワードのキー値を書き留めておきます。 AWS Systems Manager Fleet Manager のリモートデスクトップコンソール を開きます。 [ 新しいセッションを追加 ] を選択し、次に MGMT EC2 インスタンスノードを選択して [ 追加 ] を選択します。 ユーザー認証情報 を選択し、以下を入力します。 「ユーザー名」には Administrator と入力します。 「パスワード」には、 OnPremAdministratorSecret シークレットから取得した値を入力します。 [ 接続 ] を選択します。 OU とサービスアカウントを作成する PowerShell スクリプトを ここ からダウンロードします。 [スタート] を選択 (右クリック) し、[ Windows PowerShell (管理者) ] を選択します。 Windows PowerShell ウィンドウで、スクリプトをダウンロードしたディレクトリにいることを確認し、次のコードを実行します (これを独自の環境にデプロイする場合は、 $RDSDeployment ハッシュテーブル変数を適切な値に更新してください)。 $RDSDeployment = @{ RdsOUBaseDn = 'DC=corp,DC=example,DC=com' RdsOUName = 'RDS-MSSQL' RdsSvcAccountName = 'RdsServiceAccount' RdsSvcAccountPw = Get-Credential -Message 'Please provide a password for the RDS Service Account RdsServiceAccount' -User 'RdsServiceAccount' -ErrorAction Stop | Select-Object -ExpandProperty 'Password' } .\Set-RDSAdObjects.ps1 @RDSDeployment スクリプトの出力は以下のようになるはずです。 PS C:\temp&gt; .\Set-RDSAdObjects.ps1 @RDSDeployment Getting AD domain information. Getting RootDSE information. Getting computer SchemaNamingContext. Getting ExtendedRightsMap. Creating OU RDS-MSSQL. Creating RDS Service Account RdsServiceAccount. Getting RdsServiceAccount SID. Creating ACL object S-1-5-21-1232016207-3383558643-744262169-1104 CreateChild, DeleteChild Allow bf967a86-0de6-11d0-a285-00aa003049e2 All 00000000-0000-0000-0000-000000000000. Getting ACL for OU=RDS-MSSQL,DC=corp,DC=example,DC=com and adding new rule. Setting ACL for OU=RDS-MSSQL,DC=corp,DC=example,DC=com. Creating ACL object S-1-5-21-1232016207-3383558643-744262169-1104 Self Allow f3a64788-5306-11d1-a9c5-0000f80367c1 Descendents bf967a86 -0de6-11d0-a285-00aa003049e2. Getting ACL for OU=RDS-MSSQL,DC=corp,DC=example,DC=com and adding new rule. Setting ACL for OU=RDS-MSSQL,DC=corp,DC=example,DC=com. Creating ACL object S-1-5-21-1232016207-3383558643-744262169-1104 Self Allow 72e39547-7b18-11d1-adef-00c04fd8d5cd Descendents bf967a86 -0de6-11d0-a285-00aa003049e2. Getting ACL for OU=RDS-MSSQL,DC=corp,DC=example,DC=com and adding new rule. Setting ACL for OU=RDS-MSSQL,DC=corp,DC=example,DC=com. Amazon RDS サービスアカウント認証情報を保存するための KMS キーとシークレットの作成 適切な委任でターゲット OU とサービスアカウントを作成したので、次は Secrets Manager シークレットにサービスアカウント情報を保存する必要があります。 KMS キーのセットアップ KMS キーを設定するには、次の手順を実行します。 AWS KMS コンソールのナビゲーションペインで [ カスタマー管理型のキー ] を選択します。 [ キーの作成 ] を選択します。 キーのタイプ で [ 対称 ] を選択します。 キーの使用 で [ 暗号化および復号化 ] を選択します。 「 詳細オプション 」セクションの キーマテリアルオリジン で [ KMS ] を選択します。 リージョンごと には、[ 単一リージョンキー ] を選択します。 [ 次へ ] を選択します。 「 ラベルを追加 」ページで、エイリアスを入力し (この投稿では RDS-Self-Ad と入力します)、[ 次へ ] を選択します。 「 キーの管理アクセス許可を定義 」ページで、IAM ユーザーまたはロールを選択し、[ 次へ ] を選択します。 「 キーの使用アクセス許可を定義 」ページで IAM ユーザーまたはロールを選択し、[ 次へ ] を選択します。 「 レビュー 」ページで、選択内容を確認し、[ 完了 ] を選択します。 AWS KMS コンソールで、作成したキーのエイリアスを選択します。 [ キーポリシー ] タブで [ ポリシービューへの切り替え ] を選択し、[ 編集 ] を選択します。 キーポリシーに以下を追加し、[ 変更の保存 ] を選択します。 { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "Service": [ "rds.amazonaws.com" ] }, "Action": "kms:Decrypt", "Resource": "*" } 注意 : 暗号化キーには、AWS のデフォルト KMS キーを使用しないでください。AWS KMS キーは、セルフマネージド型 AD に参加させたい RDS for SQL Server DB インスタンスと同じ AWS アカウントで作成してください。 サービスアカウントの認証情報を Secrets Manager シークレットへ保存 認証情報を Secrets Manager シークレットに保存するには、以下の手順を実行します。 Secrets Manager コンソールで、[ 新しいシークレットを保存する ] を選択します。 シークレットのタイプ で [ その他のシークレットのタイプ ] を選択します。 キー / 値のペア の場合は、以下のキーペアを追加します。 キーには CUSTOMER_MANAGED_ACTIVE_DIRECTORY_USERNAME と入力します。 値には PowerShell スクリプトの RdsSvcAccountName パラメータに設定した名前を入力します。 [ + 行を追加 ] を選択し、別のキーペアを追加します。 キーには CUSTOMER_MANAGED_ACTIVE_DIRECTORY_PASSWORD と入力します。 値には PowerShell スクリプトの RdsSvcAccountPw パラメーターに設定したパスワードを入力します。 暗号化キー には、先ほど作成したキーを選択します。 [ 次 ] を選択します。 シークレット名前 には名前を入力します (この投稿では RDS-Self を使用します)。 リソースのアクセス許可 セクションで、[ 許可を編集 ] を選択します。 次のリソースポリシーを入力し、[ 保存 ] を選択します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "rds.amazonaws.com" ] }, "Action": "secretsmanager:GetSecretValue", "Resource": "*", "Condition": { "StringEquals": { "aws:sourceAccount": "123456789012" }, "ArnLike": { "aws:sourceArn": "arn:aws:rds:us-west-2:123456789012:db:*" } } } ] } 注意 :このブログで使用されている AWS アカウント ID は、デモンストレーションのみを目的としています。読者は AWS アカウント ID を適宜変更する必要があります。 「 ローテーションの設定 – オプション 」ページで、デフォルトのままにし、[ 次 ] を選択します。 「 レビュー 」ページで選択内容を確認し、[ 保存 ] を選択します。 Secrets Manager コンソールでリフレッシュアイコンをクリックし、先ほど作成したシークレット名を選択します。 「 シークレットの詳細 」ページで、RDS for SQL Server インスタンスをデプロイするときに使用するシークレットの ARN を書き留めておきます。 RDS サブネットグループの作成 このステップでは、DB サブネットグループを作成します。DB サブネットグループは、DB インスタンス用に指定する VPC 内のサブネットの集まりです。各 DB サブネットグループには、特定のリージョンの少なくとも 2 つのアベイラビリティーゾーンにサブネットが必要です。VPC に DB インスタンスを作成するときは、DB サブネットグループを選択します。Amazon RDS は DB サブネットグループから、DB インスタンスに関連付けるサブネットとそのサブネット内の IP アドレスを選択します。DB はサブネットを含むアベイラビリティーゾーンを使用します。 Amazon RDS コンソールのナビゲーションペインで [ サブネットグループ ] を選択します。 [ DB サブネットグループの作成 ] を選択します。 名前 に名前を入力します (この投稿では RDS-Self-Ad と入力します)。 説明 には説明を入力します (この投稿では RDS-Self-Ad と入力します)。 VPC では、RDS インスタンスをデプロイしたいサブネットを含む VPC を選択します。 アベイラビリティーゾーン では、RDS インスタンスをデプロイしたいサブネットを含むアベイラビリティーゾーンを選択します。 サブネット では、RDS インスタンスをデプロイしたいサブネットを選択します。 [ 作成 ] を選択します。 セルフマネージド型 AD と統合された RDS for SQL Server インスタンスのデプロイ このステップでは、RDS for SQL Server インスタンスをデプロイし、セルフマネージド型 AD に参加させます。RDS for SQL Server インスタンスをデプロイするプロセス全体を説明するわけではなく、RDS for SQL Server インスタンスを AD に参加させるために必要な構成設定についてのみ説明します。デプロイ手順の詳細については、「 DB インスタンスの作成 」を参照してください。 Amazon RDS コンソールのナビゲーションペインで [ データベース ] を選択します。 [ データベースを作成 ] を選択します。 [ Microsoft SQL Server Windows 認証を有効化 ] をチェックします。 Windows authentication type には、[ セルフマネージド型の Microsoft Active Directory ] を選択します。 Fully qualified domain name には、RDS インスタンスが使用するドメインの名前を入力します (この記事では corp.example.com を使用します)。 Domain organizational unit には、Amazon RDS AD オブジェクトの場所を入力します (この投稿では OU=RDS-MSSQL、DC=corp、DC=Example、DC=com と入力します)。 Authorization secret ARN には、作成したサービスアカウント認証情報を含むシークレットの ARN を入力します。 Primary DNS には、セルフマネージド型 AD を解決できる DNS サービスの DNS リゾルバー IP を入力します。 Secondary DNS には、セルフマネージド型 AD を解決できる DNS サービスの DNS リゾルバー IP を入力します。 その他の設定をすべて検証してください。 デプロイの検証 RDS for SQL Server インスタンスがアクティブな場合は、インスタンスをデプロイしたときに設定したローカルサービスアカウント認証情報を使用して SSMS で MGMT EC2 インスタンスノードから RDS for SQL Server インスタンスに接続できます。ログインしたら、corp\Administrator アカウントに RDS for SQL Server インスタンスへの認証を行う権限を付与します。以下のステップを完了してください。 Secrets Manager コンソールで、 OnPremAdministratorSecret シークレットに移動します。 シークレット詳細 ページの「 シークレット値 」セクションで、[ シークレットの値を取得する ] を選択します。 corp\Administrator アカウントのパスワードをメモしておき、後の手順で使用します。 AWS Systems Manager Fleer Manager のリモートデスクトップコンソール を開きます。 [ 新しいセッションを追加 ] を選択し、MGMT EC2 インスタンスノードを選択して [ 追加 ] を選択します。 [ ユーザー認証情報 ] を選択し、以下を入力します。 「ユーザー名」には corp\Administrator と入力します。 「パスワード」には、 OnPremAdministratorSecret シークレット用にコピーしたパスワードを入力します。 [ 接続 ] を選択します。 「 開始 」を選択して SSMS を起動します。 ダイアログボックスで、次の情報を入力します。 「 サーバー名 」には、RDS for SQL Server インスタンスエンドポイントの名前を入力します。 「 認証 」には、[ SQL Server 認証 ] を選択します。 「 ログイン 」には、ディレクトリを起動したときに設定したユーザー名を入力します。 「 Password 」には、ディレクトリを起動したときに設定したパスワードを入力します。 [ 接続 ] を選択します。 SSMS に入ったら、ナビゲーションペインで [ セキュリティとログイン ] を展開します。 [ ログイン ] を選択 (右クリック) し、[ 新規ログイン ] を選択します。 ログイン名として corp\Administrator と入力し、[ OK ] を選択します。 [ スタート ] を選択し、新しい SSMS ウィンドウを開きます。 ダイアログボックスで、次の情報を入力します。 「 サーバー名 」には、RDS for SQL Server インスタンスエンドポイントの名前を入力します。 「 認証 」には [ Windows 認証 ] を選択します。 [ 接続 ] を選択します。 セルフマネージド型 Active Directory のユーザーを使用して RDS for SQL Server インスタンスに正常にサインインすることができました。 後片付け この投稿によってアカウントにデプロイされたリソースを削除するには、次の手順を実行します。 デプロイした RDS for SQL Server インスタンスを削除します。手順については、「 DB インスタンスの削除 」を参照してください。 注意 : この手順だけでは DB サブネットグループは削除されませんので、「サブネットグループ」のメニューから作成した DB サブネットグループを削除してください。 作成した RDS-Self-AD シークレットを削除します。手順については、「 AWS Secrets Manager シークレットを削除する 」を参照してください。 作成した RDS-Self-AD キーを削除します。手順については、「 AWS KMS キーの削除 」を参照してください。 この記事の前提条件を満たすリソースをデプロイした CloudFormation スタックを削除します。手順については、「 AWS CloudFormation コンソールでのスタックの削除 」を参照してください。 まとめ この投稿では、セルフマネージド型 AD と統合された RDS for SQL Server インスタンスをデプロイする方法を示しました。ここではこの新機能に必要なすべての Active Directory 前提条件を簡単にセットアップできるサンプル PowerShell スクリプトを使用しました。次に、Amazon RDS AD サービスアカウントの認証情報を含む Secrets Manager シークレットを暗号化する KMS キーを作成してセルフマネージド型の Microsoft AD と統合された新しい RDS for SQL Server インスタンスをデプロイしました。最後にセルフマネージド型の Microsoft AD ユーザーが RDS for SQL Server インスタンスへの認証を受けることを検証する方法を示しました。 この新しくてエキサイティングな機能に関する今後の投稿に注目してください。質問やコメントがある場合は、以下に追加してください。 著者について Jeremy Girven は、AWS 上の Microsoft ワークロードを専門とするソリューションアーキテクトです。Microsoft Active Directory で 17 年以上、業界で 25 年以上の経験があります。彼の楽しいプロジェクトの 1 つは、SSMS を使用して AWS の Active Directory ビルドプロセスを自動化することです。詳細については、 Active Directory AWS パートナーソリューション をご覧ください。 Siva Thang は、AWS のパートナーであるシニアソリューションアーキテクトです。専門はデータベースと分析で、エンジニアリングの修士号も取得しています。彼はお客様がクラウドで最新のデータプラットフォームを構築できるよう支援することに情熱を注いでいます。これには最新のリレーショナルデータベースへの移行や、分析と機械学習のための大規模なデータレイクとデータパイプラインの構築が含まれます。また、最新のデータベースと分析をテーマにしたさまざまな会議やサミットでプレゼンテーションを行うことも好きです。 Pradipta Kishore Das は、データベース管理システムに関する豊富な経験を持ち、Microsoft SQL Server で 18 年以上の経験があります。彼は現在、アマゾンウェブサービスでデータベースエンジニアとして働いています。Amazon RDS チームと協力して、商用データベースエンジンと SQL Server を中心に、顧客向けの新しいエキサイティングな機能を構築しています。過去には、Microsoft で複雑な SQL Server の問題のトラブルシューティングとデバッグを担当するテクニカルリードを務めていました。彼はさまざまな規模の環境に取り組んできました。 &nbsp; 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。
Amazon RDS Proxy は、フルマネージド型の可用性の高いデータベースプロキシサービスです。RDS Proxy の使用を開始するにあたり、追加のインフラストラクチャをプロビジョニングしたり管理したりする必要はありません。これに加えて、 Amazon Relational Database Service (Amazon RDS) は RDS Proxy のメンテナンス作業を完全に管理します。アップグレードやパッチ適用などは、アプリケーションのダウンタイムを避けるために段階的に実施されます。 この投稿では、プレーンテキストパスワードの使用を避けてデータベースインスタンスの安全性を高め、RDS Proxy による IAM 認証を使用して PowerShell および .Net ベースのアプリケーションから RDS for SQL Server インスタンスに接続する方法について説明します。 RDS Proxy を使用するメリット モダンなアプリケーションはかつてないほど要求が厳しくなり、急速にスケーリングできるサーバーレスアーキテクチャやマイクロサービスに指数関数的に移行しています。 RDS Proxy 経由での SQL Server への接続は、このようなアプリケーションのニーズに応え、次のような利点があります。 スケーラビリティとパフォーマンスの向上 サーバーレス 、PHP、Ruby on Rails などのテクノロジーに基づいて構築されたアプリケーションは、アプリケーションのリクエストを処理するためにデータベース接続を頻繁にオープンしたりクローズしたりすることがあります。何千もの新しい接続を確立するとクエリの処理に使用できたはずのデータベースリソースが頻繁に消費されます。 RDS Proxy は、アイドル状態の接続を維持したり、セッション内のさまざまなトランザクション間で十分な待機時間を確保したりするアプリケーションを支援します。RDS Proxy は同じデータベース接続を複数のアプリケーション接続と共有することで、バックエンドデータベースへの接続数を減らし、データベースの CPU とメモリ消費量を削減するのに役立ちます。 信頼性 RDS Proxy 経由で接続すると、データベースフェイルオーバーに対するアプリケーションの回復力が高まります。RDS Proxy は DNS の伝播に依存しないため、フェイルオーバー時間を最大 66% 短縮できます。また、元の DB インスタンスが使用できなくなっても、RDS Proxy はアイドル状態のアプリケーション接続を切断せずにスタンバイデータベースに接続します。そうすることでフェイルオーバーのスピードアップとフェイルオーバープロセスの簡素化に役立ちます。 セキュリティ プレーンテキストパスワードを使用してデータベースインスタンスに接続することは、今でもデータベース認証のメカニズムとして広く使用されていますが、セキュリティリスクに対する脆弱性、コンプライアンス上の問題、管理オーバーヘッドの増加などのいくつかの課題が伴います。RDS Proxy 経由での SQL Server への接続では、 AWS Secrets Manager と AWS Identity and Access Management (IAM) を通じてデータベースの認証情報とアクセスを管理できるようになり、アプリケーションにデータベース認証情報を埋め込む必要がなくなりました。この記事では、PowerShell および .NET Framework ベースのアプリケーション用に IAM 認証を使用する RDS Proxy for SQL Server をセットアップする方法を説明します。 前提条件 RDS Proxy は、データベースインスタンスと同じ Amazon Virtual Private Cloud (Amazon VPC) 内にある必要があり、パブリックにアクセスすることはできません (ただし、データベースインスタンスはアクセス可能です)。RDS Proxy for SQL Server 経由で IAM 接続を確立するには、同じ VPC 内にあるクライアントを使用するか専用ネットワークをセットアップします。 この記事の目的と IAM 接続をテストするために、お使いの RDS for SQL Server インスタンス、RDS Proxy と同じ VPC 内に Windows ベースの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをセットアップします。PowerShell と .NET サンプルコードを使用して接続をテストするには、 AWS コマンドラインインターフェイス (AWS CLI) をセットアップする必要もあります。このセクションでは、ソリューションの使用を開始する前に前提条件となる設定手順を順を追って説明します。 SQL サーバー DB インスタンスを設定 Amazon RDS の基本的な構成要素は DB インスタンスです。RDS DB インスタンスはオンプレミスの SQL Server と似ています。SQL Server DB インスタンスをプロビジョニングする手順については、「 Microsoft SQL Server DB インスタンスを作成して接続する 」を参照してください。作成後、エンドポイントをメモしておきます。 RDS Proxy 経由で接続する SQL Server の設定 RDS Proxy 経由で接続する SQL Server を設定する手順については、「 Amazon RDS Proxy 経由で SQL Server に接続するモダンなサーバーレスアプリケーションをスケールさせる 」を参照してください。 AWS CLI の設定 RDS Proxy 経由で接続する SQL Server インスタンスおよび RDS Proxy 経由で接続する SQL Server と同じ VPC にある Windows ベースの Amazon EC2 インスタンス用に AWS CLI を インストール して 設定 します。 RDS Proxy 用の TLS/SSL の有効化 RDS Proxy 経由で接続する Amazon RDS for SQL Server で IAM 認証を使用するには、RDS Proxy を作成する際に [Transport Layer Security が必要] の設定を有効にします。 RDS Proxy は AWS Certificate Manager (ACM) の証明書を使用します。RDS Proxy を使用している場合は、Amazon RDS 証明書をダウンロードしたり、RDS Proxy 接続を使用するアプリケーションを更新したりする必要はありません。 PowerShell に対する IAM 認証の構成 IAM 認証による RDS Proxy へのアプリケーション接続では、パスワードフィールドの代わりに認証トークンが使用されます。ただし、RDS Proxy から基盤となるデータベースへの接続は Secrets Manager からユーザー名とパスワードの詳細を取得することによって確立されます。 次の AWS CLI スクリプトを実行して認証トークンを生成します。 aws rds generate-db-auth-token --hostname &lt;proxy-endpoint&gt; --port 1433 --region &lt;Region&gt; --username &lt;UserName&gt; ユーザー名は大文字と小文字が区別されることに注意してください。また、認証トークンの有効期間は 15 分です。これによって IAM 認証による接続をテストできます。 IAM 認証を使用して RDS for SQL Server インスタンスに接続するには、データベースドライバーの適切なトークンプロパティを使用する必要があります。この例では、.Net SqlClient ドライバーの AccessToken プロパティを使用します。 環境に応じてパラメータ値を置き換え、同じ VPC 内に作成された EC2 インスタンスから次の PowerShell スクリプトを実行します。 $RDSSQLProxy = " &lt;proxy-endpoint&gt; " $Database = " &lt;dbadmin&gt; " $ConnectionString = "Server=tcp:$($RDSSQLProxy),1433;Initial Catalog=$($Database);Persist Security Info=False;Connect Timeout=30;Encrypt=True;TrustServerCertificate=False" $AuthToken = "Auth Token Generated in the previous Step" $SQLConnection = New-Object System.Data.SqlClient.SqlConnection($ConnectionString) $SQLConnection.AccessToken = $AuthToken $SQLConnection.Open() $query = "SELECT * FROM sys.databases" $command = New-Object System.Data.SqlClient.SqlCommand($query, $SQLConnection) $reader = $command.ExecuteReader() while($reader.Read()) { Write-Output $reader[0] } 接続に成功すると、 SELECT * FROM sys.databases の出力が表示されるはずです。 .NET フレームワークに対する IAM 認証の設定 .NET Framework は、C#、F#、Visual Basic、およびその他の一般的なプログラミング言語で開発されたアプリケーションと連携するため、Web ベースのアプリケーションで人気があります。このデモでは、まず .NET Framework 用の基本的なコンソールアプリケーションを作成して、Amazon RDS for SQL Server で IAM 認証をテストします。コンソールアプリケーションは簡単にデプロイでき、Windows の cmd プロンプトから実行できます。 このセクションでは、 AWS SDK for Amazon RDS の RDSAuthTokenGenerator クラスを使用して DB 認証トークンを生成し、.Net Framework の SQLConnection クラスの AccessToken プロパティを生成してDB 認証トークンを介して接続を認証する方法について説明します。同様の例を使用して、フォーム、ウェブアプリケーション、MVC などの他のアプリケーションを作成できます。 EC2 インスタンスに Visual Studio をインストールして設定します。 新しいプロジェクトを作成し、 コンソールアプリケーション (.NET Framework) を選択します。 [ 次へ ] を選択します。 [ プロジェクト名 ] に名前を入力します (例えば、 RDSProxy_IAMAuth_RDSSql ) 。 フレームワーク には、 .NET Framework バージョン 4.6 以降 を選択します。 [ 作成 ] を選択します。 これでプロジェクトを表示できます。 次に、AWS SDK for Amazon RDS を追加して RDSAuthTokenGenerator クラスを公開し、DB 認証トークンを生成する必要があります。 ソリューションエクスプローラーでプロジェクト名を選択 (右クリック) し、[ NuGet パッケージの管理 ] を選択します。 AWSSDK.RDS を参照し、[ インストール ] を選択します。 ポップアップメッセージで [ OK ] を選択し、インストールを完了します。 NuGet ウィンドウを閉じて、メインプログラムファイル ( Program.cs ) に戻ります。 Main クラス内に次のコードを入力します (サンプルコード内のコメントに従い、環境の詳細に従ってパラメータ値を変更してください)。 // Replace these values with your own Amazon RDS Instance and RDS Proxy details string rdsProxyEndpoint = " &lt;proxy-endpoint&gt; "; int port = 1433; string username = " &lt;username&gt; "; string dbname = " &lt;dbname&gt; "; // Create Connection String to connect to your RDS for SQL Server instance via RDS Proxy var connectionString = $"Server=tcp:{rdsProxyEndpoint},{port};Initial Catalog={dbname};Persist Security Info=False;Connect Timeout=30;Encrypt=True;TrustServerCertificate=False"; // Create DB Authentication Token var authToken = Amazon.RDS.Util.RDSAuthTokenGenerator.GenerateAuthToken(rdsProxyEndpoint, port, username); // Create a new SQLConnection Object by using ConnectionString created in previous steps using(SqlConnection RDSSQLConnection = new SqlConnection(connectionString)) { // Use AccessToken Property and provide DB Authentication Token to authenticate connection with RDS for SQL Server instance RDSSQLConnection.AccessToken = authToken; //Open Connection RDSSQLConnection.Open(); //Write your query to access data from RDS for SQL Server instance, for example, List all Databases on RDS for SQL Server instance string query = @"SELECT @@ServerName"; SqlCommand command = new SqlCommand(query, RDSSQLConnection); //execute the SQLCommand SqlDataReader reader = command.ExecuteReader(); //display retrieved record (first column only/string value) while(reader.Read()) { Console.WriteLine(reader.GetString(0)); } //Close Connection RDSSQLConnection.Close(); } ソリューションをビルドし、プロジェクト実行ファイルのビルドパスを書き留めておきます。 cmd プロンプトを開き、ビルドパスに移動してソリューションの .exe ファイルを実行します。 成功すると指定したクエリの出力が表示されます。例えば、上記のサンプルコードを使用した場合はサーバー名が表示されます。 後片付け Visual Studio プロジェクトをクリーンアップするには、次の手順を実行します。 Visual Studio で、[表示]、[ アプリケーションエクスプローラー ] を選択してアプリケーションエクスプローラーを開きます。 Visual Studio プロジェクト フォルダーの下にあるプロジェクトに移動します。 プロジェクトを選択 (右クリック) し、[ 削除 ] を選択します。 確認ポップアップで [ OK ] を選択します。 DB インスタンスは、 AWS マネジメントコンソール 、AWS CLI、または Amazon RDS API を使用して削除できます。DB インスタンスの削除に必要な時間は、バックアップ保持期間 (削除するバックアップの数)、削除されるデータ量、最終スナップショットを作成するかどうかによって異なります。 RDS for SQL Server DB インスタンスを削除する には、次のことを行う必要があります。 Amazon RDS コンソールのナビゲーションペインで、[ データベース ] を選択し、削除する DB インスタンスを選択します。 [ アクション ] メニューで [ 削除 ] を選択します。 DB インスタンスの最終的な DB スナップショットを作成するには、[ 最終スナップショットの作成 ] を選択します。 最終スナップショットを作成する場合は、[ 最終スナップショット名 ] に名前を入力します。 自動バックアップを保持するには、 [ 自動バックアップを保持 ] を選択します。 テキストフィールドに「delete me」と入力します。 [ 削除 ] を選択します。 まとめ この投稿では、RDS Proxy 経由での SQL Server 接続で IAM 認証を使用する利点を示し、PowerShell および .NET ベースのアプリケーションからの接続を設定する方法を示しました。質問やフィードバックがある場合はコメント欄に残してください。 著者について Sudarshan Roy は、AWS Worldwide Database Services Organization (DBSO) のシニア RDS スペシャリストクラウドソリューションアーキテクトです。彼の専門分野は、AWS RDS サービスを利用するエンタープライズのお客様向けのモダンなデータベースプラットフォームの設計、構築、実装です。余暇には、クリケットをしたり、家族と過ごすのが大好きです。 Sikandra Chaudhary は、AWS の RDS PostgreSQL ソリューションアーキテクトです。Sikandra は AWS のお客様のアーキテクチャ設計を支援し、データベースワークロードを AWS に移行して実行するための効率的なソリューションを提供しています。彼は PostgreSQL と Microsoft SQL Server のデータベーステクノロジーに関する専門知識を持っています。 &nbsp; &nbsp; 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。
エンタープライズストラテジストである私は、マルチクラウドのトピックが、混乱、誤った確信、暫定性をはらんだ多くの議論の中で取り上げられていることに気づいています。企業は、マルチクラウドアプローチを決して採用しないようにというメッセージや、「どの企業もマルチクラウドに切り替えている」のだからマルチクラウドアプローチが必要だ、という相反するメッセージにさらされています。 マルチクラウド戦略を追求するにしても避けるにしてもそれなりの理由があります。このブログでは、マルチクラウドで成功するための 8 つの実証済みのプラクティスに焦点を当てます。これには、どういった場合にマルチクラウドが理にかなっているか、 AWS がどのように企業のマルチクラウド戦略の成功を支援する立場にあるのかを紹介します。 マルチクラウドとは、組織全体で、複数のクラウドサービスプロバイダー ( CSP ) を同時に利用することを指します。その前に、いくつかの用語を明確にしておきましょう。メールやプロジェクト管理ソフトウェアなどの SaaS 製品を CSP と併用するのは、純粋なマルチクラウド環境とは言いません。これは良い戦略であり、複数のクラウドを活用できる可能性があります。ただし、このブログの中では、パブリッククラウドのマルチクラウドとは言いません。 1.&nbsp;&nbsp; 正当なビジネスニーズを満たすためのみにマルチクラウドを追求すること AWS のお客様には、ワークロードの大部分を単一の CSP 上に配置するプライマリのクラウドプロバイダーを選択することでクラウドの利点を十分に実現することをお勧めします。しかしながら、マルチクラウドアプローチが組織に適していることには正当な理由がある場合があります。マルチクラウドインフラストラクチャの複雑さが必要となる状況には、次のようなものがあります。 合併と買収 買収企業があるプライマリの CSP を採用しており、被買収企業が別のプライマリの CSP を採用している場合、M&amp;A取引の結果、マルチクラウド環境の状態になります。私のエンジニア経験から、マルチクラウド環境に突入するのはあまり嬉しいことではないと考えています。統合したり、コンパクトにまとめられた方が良いと考えています。しかし、統合を急いで行うことに意味がない場合もあります。全体的なテクノロジー統合戦略と評価アプローチをこのプロセスに反映し、M&amp;A プレイブックの一部にする必要があります。あるプロバイダーから別のプロバイダーに何を移すか、いつ移転するか、何をそのままにしておくかは、それぞれ異なる可能性があります。しかし、統合戦略の確立は、ERPの複数のインスタンスが永遠に稼働し続けることを防ぐのと同じくらい重要です。 他社の CSP が持つ長期的に差別化された機能を活用したい 取りこぼしを恐れて、一部の企業は、あらゆるクラウドの一部の機能を活用したいと考える場合もあります。私たちは、より分散した戦略を採用するよりも、組織の課題の大部分を解決できる CSP を選択した方が、企業にとってより良いサービスを提供できると考えています。これを考えるには、80:20の法則が適しています。(20%の方ではなく)80%の優先順位を検討することは、効率性や、人材の有効活用、価値の向上につながります。特定のテクノロジーを必要とする特殊なワークロードもあるかもしれませんが、メリットとのトレードオフを検討して、ケースバイケースで対処すべきです。 企業は「適切なクラウドに適したワークロード」について考えるかもしれません。「適切なクラウド」とは何かを分析することが、特定のワークロードに関する考慮事項にとどまらないようにしましょう。このワークロードを別の CSP に分散させると、全体的な複雑さにどのような影響が出るかを確認してみてください。各クラウドの各ワークロードの価格とパフォーマンスを注意深く分析して、その価値がこれを正当化するのに十分であることを確認することをお勧めします。 持株会社のマルチクラウド、事業会社/LOBのプライマリのクラウド プライベート・エクイティ組織や、複数のポートフォリオ企業を持つ大規模な持株会社の場合、各ポートフォリオ企業が独自の CSP 戦略 (多くの場合 M&amp;A によって推進される) を持つことは理にかなっています。1 つのクラウドプロバイダーにより多くの支出を集中させることで、そのボリュームディスカウントやインスタンス予約のインセンティブを活用できる可能性があります。しかし、人材不足、細分化されたワークロード、リスクの増大といったその他の欠点は、各組織が独立して運営されているため、ほとんど回避できます。 2.&nbsp;&nbsp; マルチクラウドに関する誤解に注意しましょう 誤解 1: 誰もがマルチクラウド戦略を採用している アドバイザリー会社とメディア企業は、企業がどの程度ワークロードを複数のクラウドに配置しているかについて、さまざまな調査結果を発表しています。私たちのアドバイスは、この慣行がどれほど蔓延しているかにかかわらず、企業にとって正しいことを行い、コストとリスクに基づいて意思決定を行うことです。 誤解 2: マルチクラウドはベンダーロックインのリスクを軽減する マルチクラウド戦略を追求する主な理由として、(契約上の観点と技術的観点の両方から)ロックインの恐れを挙げている企業もあります。オンプレミス環境では、企業は長期にわたる大規模な設備投資に駆り立てられ、多くの場合、長期的で複雑なサービス契約に縛られます。これらは企業にとって一方通行の大きな決定であり(つまり、取り消すのは困難でコストがかかる)、リスクの軽減に重点を置く必要があります。 クラウドは違います。複数のクラウドプロバイダーで同じワークロードを実行している企業は、「最も低い共通点」、つまり複数 CSP で利用できる技術のみを採用して開発しなければならないというプレッシャーを感じることがよくありますが、これはクラウドの利点を最大限利用できないという制限となっていることを考慮する必要があります。場合によっては、プロバイダーごとに異なるワークロードを実行することでこの問題を回避できる場合もあります。 企業には、既存の CSP のサービス利用を終了する場合に発生する切り替えコストと、その可能性を十分に理解するよう努めることをおすすめします。そこから、CSP を変更する必要があるコストと可能性と、主要プロバイダーを持つことの戦略的メリットを比較して、ロックインを減らすための最善のアプローチを定義することができます。 また、クラウドは本質的に従来の IT モデルよりもオープンであり、ロックインを回避するためにマルチクラウドは必要ないという点にも留意してください。AWS が SQL、Linux、コンテナなどのオープンソーステクノロジーと標準に基づいてサービスを構築する点に着目してください。お客様は、MySQL 向けの Amazon Relational Database Service ( Amazon RDS ) や PostgreSQL 向けの Amazon RDS などのマネージド型オープンソースサービス、あるいは基本的なビルディングブロックに基づいて構築するかを選択できます。従量課金制であり、長期にわたる先行契約はありません。AWS では、お客様が使用したいサービスを構築するよう努めていますが、お客様が移転を選択した場合でも、AWS ではこれをできる限り簡単にします。AWS は、お客様がリソースをオンプレミスから AWS に簡単に移動できるようにするだけでなく、お客様が希望すればオンプレミスや他のクラウドに戻すことができるように、複数の移行ツールを提供しています。 誤解 3: マルチクラウドは可用性を向上させる 企業で利用しているプライマリの CSP が停止した場合、そのサービスが中断されるリスクを軽減するために、マルチクラウド戦略を採用するのは、稀なケースになってきています。このような場合、企業はワークロードを簡単かつシームレスにセカンダリ CSP に切り替えることができると考えている場合があります。マルチクラウド・フェイルオーバーは、アプリケーションを別のクラウドにフェイルオーバーできることを前提としています。多くの企業が気づいているように、これは極めて困難です。これを実現するには、2 つの CSP 間の完全なポータビリティを維持する必要があるため、複雑さが増し、リスクが高まり、フェイルオーバーが可能であると信じているとするならさらに作業が増えます。 Gartnerのアナリストでディスティングイッシュト バイスプレジデントのリディア・レオン(Lydia Leong)氏は、マルチクラウド・フェイルオーバーの問題点を ツイート にまとめています。「マルチクラウドのフェイルオーバーは複雑でコストがかかり、ほとんどの場合非現実的であり、クラウドやレジリエンスのリスクに対処する上でも特に効果的な方法ではありません。」フェイルオーバーを機能させる際の問題は、CSP の差別化要因(たとえば、ネットワークアーキテクチャと機能の違い、ストレージ機能の違い、独自の高レベルサービス、データベース層、MLサービス、セキュリティ機能の違いなど)にあります。ワークロードが複数の CSP に分散している場合、いずれかの CSP に障害が発生すると機能停止が発生する可能性があります。この場合、ワークロードを複数の CSP に分散させると、実際にはリスクが高まります。 代わりに、「実装と簡素化」によってリスクを軽減することを企業にお勧めします。特定のワークロードやアプリケーションを単一のクラウドを対象とし、それを移行し、マスターし、コストとリスクを軽減し、それを繰り返します。トレーニングを通じて CSP 固有の特徴や能力をより深く学ぶよう促し、すでに統合されている CSP 固有のより高度なサービスやツールを活用しましょう。最後に、そしておそらく最も重要なのは、AWS のリージョンとアベイラビリティーゾーンを活用することです。この分野の AWS の機能は、すでに AWS のお客様に、可用性と信頼性の高いソリューションを実現するための優れた機能を提供しています。 誤解 4: マルチクラウドの方が価格競争力を高める 価格競争力は、マルチクラウドにとって最も弱い論点かもしれません。複雑で高価なソフトウェアやデータセンター契約を複数年契約に縛られるような経験を持つ組織は、ITサービスの調達に慎重になっています。従来の調達アプローチは、従量課金制購入、大量割引、またはクラウドにおける価格競争の現実に適応していませんでした。(AWS はサービス提供以来 129 回も価格を引き下げてきました)。 コスト削減の最大の要因は、企業のクラウド環境がいかに適切に管理され、最適化されているかということです。コストパフォーマンスに優れ ( AWS Graviton のようなカスタム設計のチップをベースにしたコンピュートインスタンスなど)、優れたクラウド財務管理ソリューションを提供するサービスを提供するプロバイダーを主に利用することで、コスト最適化が向上する可能性があります。Hackett Group が 1,000 社を超える組織を対象に実施した 2021 年の調査によると、IT 支出総額に占めるインフラストラクチャ支出の割合は、マルチクラウド組織よりも AWS のお客様が 20% 低いことがわかりました。 私たちの経験から、企業は複数のクラウドでの運用による追加コストや複雑さを予測しておらず、直接的なソーシング契約で得られる利益と適切に比較検討していないことがわかっています。 3.&nbsp;&nbsp; 明確な戦略とそれを支えるガバナンスを確立する マルチクラウド戦略を追求すると決めただけでは十分ではありません。どのワークロードをどこに、なぜ使用するかの明確なガバナンスを含め、マルチクラウドの目標を達成するための戦略を確立する必要があります。評価基準を使用してワークロードとその依存関係を最適化する必要があります。個人に任せれば、CSP 間の無秩序な拡大は、マルチクラウド戦略が達成しようとしていた価値を損なう可能性があります。CSP のワークロードパフォーマンスを定期的に評価し、その評価を CSP の選択、基準、将来の利用に関する重要な情報として活用してください。 全体的なガバナンス戦略の一環として、企業全体で使用されるサービス、アプリケーション、コンポーネントの総数を包括的に把握することが重要です。そのためには、CSPにまたがり、デプロイされたリソースの 100% の所有権、使用状況、環境 (開発、QA、ステージ、プロダクションなど) を明確に確立する強固なタグ付け戦略が不可欠です。すべて所有者にタグ付けする必要があります。タグ付けされていない場合や所有者が特定できない場合は、削除する必要があります。これにより、進捗を妨げるゲートではなく、ガードレールを設けて、ガバナンスルールを体系化し、運用を自動化できます。コスト、運用、セキュリティを同じ方法で追跡、監視、対応し、CSP全体で同じ量のデータと透明性を保たなければなりません。特定のニーズに対応し、複数のCSPで運用できる単一のツールが望ましいです。 4.&nbsp;&nbsp; 連続するワークロードを複数の CSP に分散しない 私の考えでは、複数の CSP にまたがるワークフローは、不必要な複雑さ、リスク、コストをもたらす一方で、サポート、導入、アーキテクチャを複雑にし、付加価値もほとんどありません。連続したワークロードには大量のデータが含まれることが多く、それらをまとめて処理して分析する必要があります。データが複数のクラウドプロバイダーに分散していると、データの移動、同期、一貫性の維持に課題が生じる可能性があります。さらに、複数の CSP にまたがる連続したワークロードの管理は複雑で時間がかかる場合があります。CSP ごとに異なる API、管理インターフェース、セキュリティモデル、運用プロセスを扱う必要があります。このような複雑さは、エラーの可能性を高め、運用上のオーバーヘッドを増大させ、アジリティとスケーラビリティを妨げる可能性があります。 この種の設計やビジネスニーズを評価する際には、具体的な基準と指針を定める必要があります。 5.&nbsp;&nbsp; アプリケーションはトランザクションデータと共にあるべき 開発者が異なるクラウドのアプリケーション間で大量のデータを移動する必要がある場合、特にコンピューティング/アプリケーションをある CSP にデプロイし、別の CSP にデータストレージをデプロイする場合には注意が必要です。このような状況では複雑さが増し、待ち時間が増え、得られるメリットが相殺されてしまう可能性があります。 ワークロードの CSP を決定する決定基準には、そのワークロードを他のワークロードと統合するという長期的な視点を含める必要があります。そのデータは、現在の範囲を超えて高度な分析や機械学習に必要になるのでしょうか?提供されるサービスは他の CSP に広く利用されるのか、それともその CSP のワークロードに限定されるのか。導入に関する考慮事項に関する詳細なガイダンスと意思決定モデルについては、同僚の Gregor Hohpe の「 Multi-Cloud: From Buzzword to Decision Model 」というブログをご覧ください。 6.&nbsp;&nbsp; コンテナは役に立つがすべてのユースケースを解決できるわけではないことを理解する コンテナの使用は、現代のあらゆるアプリケーションにとって一般的に良いアイデアであり、移植性の多くの要素に役立ちます。コンテナはプラットフォームに依存しないため、コンテナ化をサポートするあらゆるクラウドプラットフォームやインフラストラクチャで実行できます。これにより、アプリケーションを一度開発してパッケージ化すれば、大きな変更を加えることなく、複数のクラウドプロバイダーやオンプレミス環境に一貫してデプロイできます。ただし、コンテナはすべてのケース (大規模なモノリシックアプリケーションなど) で機能するわけではなく、CSP 間の移植性に関する問題 (特にデータ、ポリシー、セキュリティ) をすべて解決するわけでもないため、注意が必要です。 7.&nbsp;&nbsp; 単一のクラウド・センター・オブ・エクセレンス ( CCoE ) を持ち、その上で専門性を持つ AWS の多くのお客様にお勧めしているように、クラウド導入のリーダーシップ、標準化、加速を実現するには、組織内の CCoE を活用する必要があります。マルチクラウドに関して言えば、最も成功している企業は CCoE を 1 つだけ持っていながら、特定の CSP に固有のスキル、ツール、メカニズムをその CCoE に特化していることがわかりました。AWS のお客様が CSP ごとに複数の CCoE を持っていると、単一の CCoE によるより協調的なアプローチではなく、分散、再エンジニアリング、無駄につながることが多いことがわかりました。 8.&nbsp;&nbsp; セキュリティが常に最優先事項であることを確認する マルチクラウドは、不正アクセスやデータ侵害のリスクを高め、セキュリティをより困難にします。マルチクラウドでは、企業は ID 管理、ネットワークセキュリティ、資産管理、監査ログなどの分野で、CSP 全体で複数のセキュリティモデルに対処する必要があります。 このような複雑さは、透明性を難しくし、セキュリティチームの負担を増大させ、リスクを高めます。マルチクラウドに限ったことではありませんが、(1) デリバリーパイプライン、クラウド環境やチームの優先事項にセキュリティにおけるシフトレフトを組み込み、自動化していくこと、(2) CSP 内またはCSP間で保存中および転送中のデータを暗号化することなど、いくつかのコアセキュリティプラクティスがより重要になっています。 マルチクラウド導入に役立つアプローチの 1 つは、セキュリティデータの保存先を 1 つ (つまり、一元管理) にすることです。各 CSP が開発したクラウドネイティブなツールでこれを補強して、その環境内で意味のあるデータが表示されるようにします。 結論 ほとんどの組織にとって、プライマリのクラウド戦略は、シンプルさ、集中力、リスク軽減を通じて最大の価値をもたらすと同時に、企業がパートナーシップを深め、主要な CSP やサービスに関する実務上の知識を深めることを可能にします。これにより、組織はより高度なサービスを活用し、優秀な人材を引き付けて定着させると同時に、企業により早く価値を提供できるようになります。 マルチクラウドのアプローチは理にかなっていますが、企業はこのようなアプローチを採用する決定をビジネスニーズに基づいて行い、関連するトレードオフを明確に理解した上で行う必要があります。このような場合は、単一の CSP から提供でき、CSP 間でデータを共有する可能性が低く、どのワークロードがどこに行くのかを明確に管理できる、アプリケーションとビジネスワークフローに焦点を当てたクラウドモデルをお勧めします。 ハイブリッド環境とマルチクラウド環境の管理と監視を一元化および簡素化し、保存されている場所を問わずすべてのデータへのアクセスを提供し、AWS、オンプレミス、および AWS コンテナサービスを備えたその他のクラウドでアプリケーションを実行するのに役立つ AWS サービスの詳細については、 ハイブリッドおよびマルチクラウド向けの AWS ソリューション をご覧ください。 著者について Tom Godden Tom Godden は、アマゾンウェブサービス (AWS) のエンタープライズストラテジスト兼エバンジェリストです。AWS に入社する前は、Foundation Medicine の最高情報責任者を務め、FDA が規制する世界有数のがんゲノミクス診断、研究、患者アウトカムプラットフォームの構築を支援しました。これにより、アウトカムを改善し、次世代の精密医療に役立つ情報を得ることができます。以前、トムはオランダのアルフェン・アーン・デン・レインにある Wolters Kluwer で複数の上級技術指導職を歴任し、ヘルスケアおよびライフサイエンス業界で 17 年以上携わってきました。トムはアリゾナ州立大学で学士号を取得しています。 本記事は、Tom Goddenによる Proven Practices for Developing a Multicloud Strategy を翻訳したものです。翻訳は ソリューションアーキテクト豊原が担当しました。
モダンなサーバーレスアーキテクチャで構築されたものも含め、多くのアプリケーションはデータベースサーバーを多数接続し、データベース接続を高速にオープンしたりクローズしたりして、データベースメモリとコンピューティングリソースを使い果たす可能性があります。また、データベースには一時的な障害が発生してアプリケーションの可用性に影響が出ることもあります。最後にアプリケーションはデータベースに接続するためにデータベースの認証情報を維持する必要があるため、データ漏えいのリスクが高まりセキュリティが低下します。 本日、RDS Proxy が RDS for SQL Server をサポートするようになったことをお知らせできることを嬉しく思います。この記事では、 Amazon RDS Proxy 経由での RDS for SQL Server への接続がこれらの問題を軽減してアプリケーションのスケーラビリティ、データベース障害に対する耐性、安全性を高める方法について説明します。 SQL Server は、マイクロソフトが開発したリレーショナルデータベース管理システムです。Amazon RDS for SQL Server を使用すると SQL Server のデプロイをクラウドに簡単にセットアップ、運用、スケーリングすることができます。また、Express、Web、Standard、Enterprise など SQL Server の複数のエディション (2014、2016、2017、2019) を数分でデプロイでき、費用対効果が高く、コンピューティング能力の拡張も可能です。AWS にはクラウド内のお客様のデータベースワークロードの運用とスケーリングに 10 年の経験があります。Amazon RDS でリレーショナルデータベースを運用する利点の 1 つは、データベースの管理とスケーリングにかかる多大な労力を省き、お客様を成功に導くことに集中できることです。私たちは、データベースを管理しやすくスケーラブルで可用性と耐久性を高め、さらに重要なこととして安全性とコンプライアンスを高めることでこれを実現します。 RDS Proxy 経由での RDS for SQL Server 接続の利点 RDS Proxy は、フルマネージド型の可用性の高いデータベースプロキシサービスです。そのため、RDS Proxy の使用を開始するために追加のインフラストラクチャをプロビジョニングしたり管理したりする必要はありません。さらに、RDS がお客様に代わって RDS Proxy のパッチ適用やアップグレードなどのメンテナンス作業を行います。このセクションでは、Amazon RDS Proxy 経由での SQL Server への接続がアプリケーションのスケーラビリティを高め、データベース障害に対する耐性を高め、安全性を高めるのにどのように役立つかについて説明します。 モダンなアプリケーションがマイクロサービスに移行するにつれて、サーバーレスアーキテクチャにより迅速なスケーリングが可能になりました。例えば、サーバーレス、PHP、Ruby on Rails などの技術に基づいて構築されたアプリケーションは、アプリケーションのリクエストを処理するためにデータベース接続を頻繁にオープンしたりクローズしたりすることがあります。何千もの新しい接続を頻繁に確立するとデータベースリソースが消費され、クエリの処理に使用できたはずのデータベースリソースを消費します。このような場合、RDS Proxy はアプリケーションとデータベース間のデータベース接続のプールを維持し、新しい接続を確立するときのデータベースのコンピューティングとメモリに不必要な負荷がかからないようにします。RDS Proxy は、安全な場合は複数のアプリケーション接続とデータベース接続を共有します。これは特に、アイドル状態の接続を維持しているアプリケーションやセッション内の異なるトランザクション間で十分な待機時間があるアプリケーションに役立ちます。RDS Proxy は、同じデータベース接続を複数のアプリケーション接続と共有することでバックエンドのデータベースへの接続数を減らし、データベースの CPU とメモリ消費量を削減するのに役立ちます。 ビジネス継続性を確保するために、お客様は一時的なデータベース障害から保護し、アプリケーションの可用性を向上させたいと考えています。Amazon RDS は一時的なデータベースエラーを自動的に検出し、介入なしでフェイルオーバーを実行します。 RDS Proxy は、フェイルオーバーを透過的に行い、データベースのフェイルオーバー時間を短縮することで、アプリケーションの可用性をさらに向上させます。RDS Proxy は、アプリケーション接続を維持したままトラフィックを新しいデータベースインスタンスに自動的にルーティングすることでフェイルオーバーを透過的に行い、複雑な障害をハンドリングするコードを書く必要がなくなります。データベースのフェールオーバー中はアプリケーションのレイテンシーが増加し、進行中のトランザクションを再試行しなければならない場合があります。RDS Proxy は、マルチ AZ 配置の DNS (Domain Name System) キャッシュをバイパスすることでフェイルオーバー時間を短縮するのに役立ちます。RDS for SQL Server は、SQL Server データベースミラーリングまたは Always On 可用性グループを通じて高可用性を実現するマルチ AZ 配置をサポートします。 フェールオーバーが発生するとクライアントは接続障害を検出し、新しいプライマリを検出してできるだけ早く再接続する必要があります。ただし、クライアントが DNS 名を使用してデータベースに接続する場合は、まず DNS サーバーに問い合わせて IP アドレスを解決する必要があります。その後、クライアントは応答をキャッシュします。DNS レスポンスは、プロトコルごとに Time To Live (TTL) を指定します。TTL はクライアントがレコードをキャッシュする期間を決定します。TTL 設定を最適化し、ソケットタイムアウトを 10 秒にすることで、RDS Proxy は、Always On リスナーエンドポイントへの接続よりもフェイルオーバー時間を最大 36%、RDS エンドポイントに直接接続するよりも 59%、SQL Server データベースミラーリングエンドポイントへの接続よりも 83% 短縮します。 次のテストは m5.xlarge の RDS for SQL Server インスタンスで行われ、Amazon RDS Proxy 経由で SQL Server に接続した際のタイムアウトの改善が実証されています。X 軸はフェイルオーバーの試行回数を表し、Y 軸はミリ秒単位の時間を表します。 RDS Proxy を使用すると、 AWS Identity and Access Management (IAM) 認証を使用してデータベースに接続することで、アプリケーションの安全性を高めることができます。これにより、アプリケーションコードまたは静的設定ファイルにデータベースの認証情報を保存する必要がなくなります。 ソリューション概要 アプリケーションは PHP、Ruby、.NET で実行することも、 AWS Lambda やコンテナなどのサーバーレスアプリケーションで実行することもできます。アプリケーションは RDS Proxy に接続し、そのプロキシはバックエンドの RDS SQL Server データベースに接続します。RDS Proxy は単一のインスタンスではありません。サーバーレスサービスに期待される高い可用性と拡張性を実現するために、複数のアベイラビリティーゾーンに分散された可用性の高いマルチインスタンスプロキシです。次の図は RDS Proxy の仕組みを示しています。 ネットワーク前提条件の設定 RDS Proxy を使用するには、RDS DB インスタンスと RDS Proxy の間に共通の Amazon Virtual Private Cloud が必要です。この VPC には、異なるアベイラビリティーゾーンにある少なくとも 2 つのサブネットが必要です。アカウントはこれらのサブネットを所有することも他のアカウントと共有することもできます。VPC 共有の詳細については、「 VPC を他のアカウントと共有する 」を参照してください。 Amazon Elastic Compute Cloud (Amazon EC2)、Lambda、 Amazon Elastic Container Service (Amazon ECS) などのクライアントアプリケーションリソースは、同じ VPC に配置することもプロキシとは別の VPC に配置することもできます。同じ VPC 内または別の VPC 内の RDS DB インスタンスに正常に接続できた場合は、必要なネットワークリソースがすでにあることに注意してください。 Amazon RDS for SQL Server を使い始めたばかりの場合は、「 Amazon RDS を使用した Microsoft SQL Server データベースの作成と接続 」の手順に従って環境を設定することで、データベースへの接続の基本を学ぶことができます。 また、それぞれが独自の VPC 設定を持つ複数の RDS Proxy エンドポイントを作成し、複数の共有 VPC 間の接続を有効にすることもできます。たとえば、共有 VPC にプロキシエンドポイントを作成して、プロキシの VPC 内のすべてのリソースへのアクセスを許可するのではなく、プロキシのみへのアクセスを選択的に許可することができます。プロキシエンドポイントの詳細については、「 Amazon RDS Proxy エンドポイントの操作 」を参照してください。 セキュリティ データベースシークレットは、暗号化されたシークレットストアである AWS Secrets Manager に保存する必要があります。Secrets Manager では、データベース認証情報を管理および取得できます。アプリケーションから API 呼び出しを行うだけで、シークレットを取得して接続を開始できます。もう 1 つ追加された制御レイヤーは、RDS Proxy で IAM 認証を使用できることです。ユーザー名とパスワードによる接続よりもはるかに安全です。Secrets Manager を使用すると、アプリケーションがプロキシ上で使用できる認証情報を管理できます。コード内のハードコードされた認証情報は get secrets 呼び出しに置き換えるか、IAM 認証トークンを使用して削除することもできます。 次のコマンドを使用して、 AWS コマンドラインインターフェイス (AWS CLI) を使用してプロキシを作成できます。 // create a secret for user credential that you use on RDS instance // One per each credential you intend to use with proxy aws secretsmanager create-secret \ --name sqlserver-creds --description "db admin user" \ --secret-string '{"username":"master","password":"**********"}' --region us-west-2 // create proxy role aws iam create-role --role-name rds-proxy-role \ --assume-role-policy-document '{"Version":"2012-10-17","Statement": [{"Effect":"Allow","Principal":{"Service":["rds.amazonaws.com"]}, "Action":"sts:AssumeRole"}]}' // add secrets reader policy to the role aws iam put-role-policy --role-name rds-proxy-role \ --policy-name rds-proxy-secret-reader-policy --policy-document '{"Version":"2012-10-17","Statement":[{"Sid":"getsecretvalue","Effect" :"Allow","Action":["secretsmanager:GetSecretValue","kms:Decrypt"], "Resource":"*"}]}' // create proxy instance aws rds create-db-proxy --db-proxy-name test-proxy --engine-family SQLSERVER \ --auth Description=master,AuthScheme=SECRETS,SecretArn=arn:&lt;arn details&gt;:&lt;acc&gt;:secret:sqlserver-creds-ConshD,IAMAuth=DISABLED \ --role-arn arn:aws:iam::&lt;acc&gt;:role/rds-proxy-role --vpc-subnet-ids subnet-XXXXX subnet-XXXXX subnet-XXXXX subnet-XXXXX --region us-west-2 // register rds instance aws rds register-db-proxy-targets --db-proxy-name test-proxy --db-instance-identifiers test-instance RDS for SQL Server を使用したプロキシの作成 指定した DB インスタンスセットの接続を管理するために、プロキシを作成できます。Amazon RDS Proxy は Amazon RDS for SQL Server、Amazon Aurora with MySQL 互換、Amazon Aurora with PostgreSQL 互換、Amazon RDS for MySQL、Amazon RDS for MariaDB、 Amazon RDS for PostgreSQL で利用できます。ここでは RDS for SQL Server の RDS Proxy に焦点を当てます。 Amazon RDS コンソールのナビゲーションペインで [ プロキシ ] を選択します。 [ プロキシの作成 ] を選択します。 「 プロキシ設定 」のセクションでは、以下の設定に関する情報を入力します。 プロキシ識別子 – AWS アカウント ID と現在の AWS リージョン内で一意になる任意の名前を指定します。 エンジンファミリー – SQL Server を選択してください。 Transport Layer Security が必要 – プロキシがすべてのクライアント接続に TLS/SSL を適用するように設定する場合は、この設定を選択してください。プロキシに対して暗号化された接続または暗号化されていない接続を使用する場合、プロキシは基盤となるデータベースへの接続時に同じ暗号化設定を使用します。 注意:この項目は、今の画面レイアウトでは「接続」のセクションにあります。 アイドルクライアントの接続タイムアウト – プロキシがクライアント接続を閉じるまで、クライアント接続をアイドル状態にしておく時間を選択します。デフォルトは 1,800 秒 (30 分) です。前の要求が完了してから指定された時間内にアプリケーションが新しい要求を送信しない場合、クライアント接続はアイドル状態と見なされます。基になるデータベース接続は開いたままになり、接続プールに戻されます。そのため、新しいクライアント接続に再利用できます。プロキシに古い接続を積極的に削除させたい場合は、アイドル状態のクライアント接続のタイムアウトを短くすることを検討してください。ワークロードが急増している場合は、接続を確立するコストを節約するためにアイドル状態のクライアント接続タイムアウトを長くすることを検討してください。 「 認証 」セクションでは、次の情報を入力します。 Secrets Manager シークレット – このプロキシでアクセスする RDS DB インスタンスの DB ユーザー認証情報を含む Secrets Manager シークレットを少なくとも 1 つ選択します。 Access Management (IAM) ロール – 選択した Secrets Manager シークレットにアクセスする権限を持つ IAM ロールを選択します。 AWS マネジメントコンソール を使用して新しい IAM ロールを作成することもできます。 IAM 認証 – プロキシへの接続に IAM 認証を許可するか禁止するかを選択します。IAM 認証またはネイティブデータベース認証の選択は、このプロキシにアクセスするすべての DB ユーザーに適用されます。 サブネット – このフィールドには、VPC に関連付けられているすべてのサブネットがあらかじめ入力されています。このプロキシに必要のないサブネットはすべて削除できます。少なくとも 2 つのサブネットを残す必要があります。 注意:この項目は、今の画面レイアウトでは「接続」のセクションにあります。 追加の接続設定を指定します。 VPC セキュリティグループ – 既存の VPC セキュリティグループを選択します。コンソールを使用して新しいセキュリティグループを作成することもできます。このセキュリティグループは、プロキシが接続するデータベースへのアクセスを許可する必要があります。アプリケーションからプロキシへの通信、プロキシからデータベースへの通信には、同じセキュリティグループが使用されます。例えば、データベースとプロキシに同じセキュリティグループを使用しているとします。この場合、そのセキュリティグループ内のリソースが同じセキュリティグループ内の他のリソースと通信できるように指定してください。共有 VPC を使用する場合、その VPC のデフォルトのセキュリティグループや別のアカウントに属するセキュリティグループは使用できません。自分のアカウントに属するセキュリティグループを選択してください。存在しない場合は作成してください。この制限について詳しくは、「 制限事項 」を参照してください。 オプションで、高度な設定を行います。 拡張ログ記録をアクティブ化 – この設定を有効にすると、プロキシの互換性やパフォーマンスの問題をトラブルシューティングできます。この設定を有効にすると RDS Proxy は SQL ステートメントに関する詳細情報をログに記録します。この情報は、SQL の動作やプロキシ接続のパフォーマンスとスケーラビリティに関する問題のデバッグに役立ちます。デバッグ情報には、プロキシ経由で送信する SQL ステートメントのテキストが含まれます。従って、この設定はデバッグに必要な場合とログに表示される機密情報を保護するためのセキュリティ対策が講じられている場合にのみ有効にしてください。プロキシに関連するオーバーヘッドを最小限に抑えるため、RDS Proxy はこの設定を有効化してから 24 時間後に自動的にオフにします。特定の問題をトラブルシューティングするには、この設定を一時的に有効にしてください。 [ プロキシの作成 ] を選択します。 RDS Proxy に接続する プロキシを作成すると、その DNS エンドポイントにアクセスしてアプリケーションを接続できます。RDS Proxy は SQL Server のデフォルトポート 1433 を使用します。プロキシエンドポイントの詳細は、Amazon RDS コンソールの対応するプロキシの詳細ページで取得することも、AWS CLI の describe-db-proxies コマンドを使用して取得することもできます。以下のコード例を参照してください。 # Add —output text to get output as a simple tab-separated list. $ aws rds describe-db-proxies —query '*[*].{DBProxyName:DBProxyName,Endpoint:Endpoint}' [ [ { "Endpoint": "the-proxy.proxy-demo.us-east-1.rds.amazonaws.com", "DBProxyName": "the-proxy" }, { "Endpoint": "the-proxy-other-secret.proxy-demo.us-east-1.rds.amazonaws.com", "DBProxyName": "the-proxy-other-secret" }, { "Endpoint": "the-proxy-rds-secret.proxy-demo.us-east-1.rds.amazonaws.com", "DBProxyName": "the-proxy-rds-secret" }, { "Endpoint": "the-proxy-t3.proxy-demo.us-east-1.rds.amazonaws.com", "DBProxyName": "the-proxy-t3" } ] ] ユーザー名とパスワードを含む Secrets Manager シークレットを設定し、RDS Proxy がシークレットマネージャーから認証情報を取得することを許可できます。IAM 認証は、クライアントプログラムとプロキシ間の接続に適用されます。その後、プロキシは Secrets Manager から取得したユーザー名とパスワードの認証情報を使用してデータベースを認証します。RDS Proxy では複数のシークレットを設定できます。詳細については、 create-db-proxy を参照してください。 SQL Server の場合は、ドライバごとに適切なトークンプロパティを使用する必要があります。JDBC の場合は AccessToken 、ODBC の場合は sql_copt_ss_access_token 、.NET SqlClient の場合は AccessToken です。このようなプロパティをサポートしていない他のツールは IAM 認証方法を使用できません。この記事の執筆時点では、AD 認証はサポートされていません。 RDS Proxy for RDS SQL Server のモニタリング Amazon CloudWatch を使用して RDS Proxy をモニタリングできます。CloudWatch はプロキシから未加工データを収集し、読み取り可能でほぼリアルタイムのメトリクスに加工します。CloudWatch コンソールでこれらのメトリクスを見つけるには、ナビゲーションペインで [すべてのメトリクス] を選択し、[RDS]、[プロキシごとのメトリクス] を選択します。詳細については、「 Amazon CloudWatch メトリクスを使用する 」を参照してください。 環境の後片付け 次の手順では、このチュートリアルで作成したリソースをクリーンアップします。 Amazon RDS コンソールのナビゲーションペインで [ プロキシ ] を選択します。 プロキシを選択し、[ アクション ] メニューで [ 削除 ] を選択します。 ダイアログボックスに「delete me」と入力し、[ 削除 ] を選択します。 プロキシのステータスが [削除中] に変わります。完了すると、プロキシはリストから削除されます。AWS CLI で DB プロキシを削除するには、 delete-db-proxy コマンドを使用します。関連するアソシエーションを削除するには、 deregister-db-proxy-targets コマンドを使用します。次のコードを参照してください。 aws rds delete-db-proxy --name proxy_name aws rds deregister-db-proxy-targets --db-proxy-name proxy_name [--target-group-name target_group_name] [--target-ids comma_separated_list] # or [--db-instance-identifiers instance_id] # or [--db-cluster-identifiers cluster_id] Secrets Manager コンソールで、シークレットを選択します。 「アクション」メニューで [シークレットを削除] を選択します。 このチュートリアル用に新しい EC2 インスタンス、RDS インスタンス、および対応するセキュリティグループを作成した場合は、それらのリソースも削除してください。 まとめ RDS Proxy を使用すると、アプリケーションはデータベースと確立された接続をプールして共有できるため、データベースの効率とアプリケーションのスケーラビリティが向上します。RDS Proxy 経由での RDS for SQL Server への接続では、Always On リスナーエンドポイントに接続するよりもフェイルオーバー時間を最大 36% 短縮し、RDS エンドポイントに直接接続する場合と比べてフェイルオーバー時間を最大 59% 短縮します。RDS Proxy を使用すると、SQL Server データベースミラーリングエンドポイントに接続するときのフェイルオーバー時間が最大 83% 短縮されます。また、RDS Proxy では IAM 認証を使用できるため、アプリケーションに認証情報を保存する必要がないため、アプリケーションのセキュリティが向上します。この投稿では、RDS proxy で SQL Server に接続するための設定方法を示し、これらの潜在的な利点について詳しく説明しました。 RDS for SQL Server インスタンスでこのソリューションを試してみてください。コメントや質問がある場合は、コメント欄に残してください。 著者について Sudarshan Roy は、AWS Worldwide Database Services Organization (DBSO) のシニア RDS スペシャリストクラウドソリューションアーキテクトです。彼の専門分野は、AWS RDS サービスを利用するエンタープライズのお客様向けのモダンなデータベースプラットフォームの設計、構築、実装です。余暇には、クリケットをしたり、家族と過ごすのが大好きです。 Lakshman Thatisetty は、アマゾンウェブサービスのデータベーススペシャリストクラウドソリューションアーキテクトです。彼は AWS のお客様と協力してデータベースプロジェクトに関する顧客ソリューションを設計し、既存のデータベースを AWS クラウドに移行して近代化する支援や、AWS での大規模な移行のオーケストレーションを支援しています。 &nbsp; 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。
みなさんこんにちは! アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの前田です。 2023 年 8 月 31 日に「第三十三回 アップデート紹介とちょっぴり DiveDeep する AWS の時間」をオンラインで開催しました。本イベントは、AWS の数あるアップデートの中から「すぐ使える、運用に役立つ、あったらいいなと思ってた、おもしろい、重要」なものをピックアップし、ちょっぴり DiveDeep してカジュアルな雰囲気でお伝えするイベントです。 今回は「Security 編」ということで、AWS ソリューションアーキテクト や 実際にセキュリティサービスをご利用いただいているお客様から事例やサービスの機能についてご紹介頂きました。 今回も非常に多くの方にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました。 当日の様子と実施内容 AWS ソリューションアーキテクトから AWS Gateway Load Balancer と Amazon GuardDuty の機能についてデモを交えてお伝えし、ゲストスピーカーとして弥生株式会社の峯岸様、HENNGE 株式会社の土居様、穂坂様からマルチアカウント環境におけるセキュリティ強化の事例や AWS Control Tower Account Factory for Terraform の事例について発表して頂きました。合計 1 時間半の中で盛りだくさんの内容でお送りしました。 記事の中に資料や動画のリンクがありますので、見逃してしまった方はそちらから御覧ください。 当日参加したメンバー(一部) アジェンダ 今月のお勧め 5 分間アップデート (5 分) スピーカー:AWS ソリューション アーキテクト 前田 駿介 今月の AWS のサービスアップデートを 5 分でご紹介。たくさんのアップデートの中から 5 つをピックアップしました。 Network Load Balancer でセキュリティグループのサポートを開始 汎用 Amazon EC2 M7a インスタンスの発表 Amazon Aurora Global Database がグローバルデータベースフェイルオーバーを導入 AWS の新着情報については 公式ページ のほか、 週刊 AWS を合わせてご覧いただくのがオススメです! AWS 初心者が取り組んだセキュリティ強化の 2 年間とこれから(15分) スピーカー:弥生株式会社 峯岸 純也 様 マルチアカウント環境を構築し、増え続ける AWS アカウント数(2021 年 8 月: 23 → 2023 年 5 月:110 → 20xx 年 x 月: 300 ?)に対して取り組んでいるセキュリティ強化にて、主に活用している「AWS Security Hub」、「SIEM on Amazon OpenSearch」の活用事例の紹介と今後の取り組みについて発表致します。 AWS Gateway Load Balancer を用いた仮想アプライアンスの活用(15分) スピーカー:アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 長屋 和真 AWS Gateway Load Balancer は、クラウド上のファイアウォール、侵入検出と防止システム、ディープパケットインスペクションシステムなどのサードパーティの仮想アプライアンスの可用性を簡単かつ費用効果の高い方法で、デプロイ、スケーリング、管理できるようにするサービスです。このセッションでは、AWS Gateway Load Balancer の基本的な概念をお伝えしつつ、どのように仮想アプライアンスとの通信を実現できるのかをご紹介します。 Amazon GuardDuty 2023 夏(15分) スピーカー:アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 吉田 裕貴 Amazon GuardDutyのProtection 機能を中心にデモを交えてご紹介します。 AFT で AWS アカウントをばら撒いてみた(15分) スピーカー:HENNGE株式会社 Cloud Product Development Division 土居 俊也 様、Internal IT Section 穂坂 栄一 様 HENNGE では「挑戦し続けること」をモットーに、常に新しいことへのキャッチアップやアイデアの具現化を推奨しています。 本セッションでは、 AWS Control Tower Account Factory for Terraform (AFT) を用いた AWS アカウント管理の自動化を通じて、企業としてのセキュリティのベースラインは担保しつつ、エンジニア一人一人に専用のアカウントを提供した仕組みを紹介します。 当日の様子 当日の内容を抜粋してご紹介します。 AWS 初心者が取り組んだセキュリティ強化の 2 年間とこれから [ 資料 、 動画 ] 最初のセッションは弥生株式会社の 峯岸 純也 様より実際に取り組んでいるセキュリティ施策として AWS Security Hub の検知・ 自動復旧対応 と SIEM on Amazon OpenSearch Service 環境の構築についてお話いただきました。弥生様では Security Hub で検出した内容を Slack に通知する仕組みで運用されていましたが、当初 AWS Health 、 Amazon GuardDuty 、Security Hub の通知をそれぞれ 1 つのチャンネルに集約しており、AWS アカウントが増えるに連れて情報が流れてしまう、通知時にアカウント ID しか表示されないといった課題を抱えていました。そこで通知部分のアーキテクチャを見直し、各通知情報を各チームの Slack へ Post される形に改善されています。この改善によって開発チームのセキュリティ意識の向上や Security Hub スコアの改善など良い効果が出てきているとのことです。また、 SIEM 環境については具体的にどういったイベントをトリガーに調査を実施するのか具体的な活用方法についてお話いただき、運用していく中で改善したアーキテクチャについても共有していただきました。過去のご経験を元にアーキテクチャ改善された事例というのはどのお客様にとっても有益な情報だと思います。 AWS の様々なセキュリティサービスを利用した検知、通知の具体的な運用方法を知りたい方、SIEM の活用方法について具体的なイメージを確認したい方にはぜひご覧いただきたい内容です。 AWS Gateway Load Balancer を用いた仮想アプライアンスの活用 [ 資料 、 動画 ] 2 つ目のセッションでは、ソリューションアーキテクトの長屋より、 Gateway Load Balancer の概要とユースケースごとの設定内容について説明し、紹介したユースケースを使ったデモも実施いたしました。セキュリティ仮想アプライアンスとは 3rd パーティの製品をサーバーに導入し、検査対象の通信を経由させて利用するものです。AWS で従来型のセキュリティアプライアンスを利用する場合、仮想アプライアンスをセットアップしたインスタンスを検査対象の間に挟む構成をよく取ります。しかし、この構成の場合、検査対象となるアプリケーションがトラッフィク増などに対応するためにスケーリングを行った場合、仮想アプライアンスも追従してスケーリングが必要となります。構成が複雑化し、管理不可の増加が課題となるケースが多いです。そこで Gateway Load Balancer を利用することでこれらの課題に対応するスケーラビリティを実現し、トラフィックに対応する適切なコンピュートを割り当てることが出来るようになります。デモでは外部通信のトラフィック検査としてルーティング設定や実際の通信、Gateway Load Balancer を用いた仮想アプライアンスインスタンスのスケーリングの確認を行いました。AWS 環境にセキュリティ仮想アプライアンスの導入を検討されている方にぜひご確認頂きたい内容です。 Amazon GuardDuty 2023 夏 [ 資料 、 動画 ] 3つ目のセッションでは、ソリューションアーキテクトの吉田より Amazon GuardDuty の標準で利用できる機能と追加で利用可能な各種 Protection について概要を説明したうえで検知に関するデモを実施しました。GuardDuty は、基本的なログデータソースに加えて、他の AWS サービスからの追加デー タを使用して、潜在的なセキュリティ脅威を監視および分析が出来るサービスです。具体的にどういった脅威の検出が出来て、裏側の仕組みとしてどのように動いているのかを説明しました。デモでは Malware Protection での脅威検出の流れを確認しました。Malware Protection は Amazon EC2 インスタンスおよびコンテナワークロードにアタッチされた Amazon EBS ボリュームをスキャンすることで、マルウェアの検出が可能な機能です。マルウェア対策を検討されている方、GuardDuty というサービスが何を検出し、どのように振る舞うサービスなのか理解するために有用なセッションとなっているためぜひ動画や資料でご確認ください。 AFT で AWS アカウントをばら撒いてみた [ 資料 、 動画 ] 最後のセッションは、HENNGE 株式会社 土居 俊也 様、穂坂 栄一 様より、 AWS Control Tower Account Factory for Terraform (AFT) を用いた AWS アカウント管理の自動化を通じて、企業としてのセキュリティのベースラインは担保しつつ、エンジニア一人一人に専用のアカウントを提供した仕組みについてご紹介頂きました。HENNGE 様では元々スプレッドシートで AWS アカウントを管理されており、AWS アカウントの増加に伴ってより効率の良い管理方法の検討を開始されました。本セッションではスプレッドシートで管理されていた頃のお悩みや AWS Organizations を運用するなかでの課題感を共有して頂き、最終的に導入することとなった AFT の概要についてご紹介いただいています。AFT を用いて最少人数で 100 以上のアカウントをセキュリティを担保しつつ管理出来るようになるということで、同じようなお悩みを抱えている方やあまりセキュリティに人数を当てることが出来ず困っているお客様にぜひご覧頂きたい内容です。また、本セッションの内容は builders.flash に寄稿いただきた記事である「 HENNGE が Account Factory for Terraform を導入して実現できたこと 」がベースになっているということで、こちらの記事も是非皆様にもご覧頂ければと思います。 いただいたご質問とその回答 「Amazon GuardDuty 2023 夏」について Q. GuardDuty のProtection のサービスですが、手動で有効化という風に言っていたかと思いますが、AWS Control Tower を使って一括で各アカウントを有効化することはできますでしょうか。 A. 現時点では AWS Control Tower のみを利用した Amazon GuardDuty の Protection の一括有効化はできません。 AWS Control Tower を利用した有効化を実施する際には、 AFC 、 CfCT 、 AFT 、 AWS CloudFormation StackSets といった方法を利用してAWS Control Tower Account Factory でアカウントを作成する際に有効化いただけると幸いです。 もしくは Amazon GuardDuty の委任管理者 を利用して新しく作成されるアカウントに対してProtectionを有効化することも可能です。こちらをご利用いただくと上記の AFC、CfCT、AFT、AWS CloudFormation StackSets といった設定は不要です。 「Amazon GuardDuty 2023 夏」について Q. Malware Protectionでは、AWS側が所有するところにコピーしてスキャンされるということですが、保存期間はどれくらいになるのでしょうか。自身で制御できますか?また、定期のスキャンも同じ手法でされているのでしょうか。 A. ドキュメント に記載の通り、スナップショットの保持設定の有効性とは関係なく、マルウェアが検出されなかった場合は、スキャン完了後に自動的に削除されます。また、スナップショットの保持設定を有効化しマルウェアが検出された場合、お客様の EBS のスナップショットにマルウェア検出したスナップショットが追加されるため、お客様側で Delete 操作を行わない限り削除されることはありません。 「AWS Gateway Load Balancer を用いた仮想アプライアンスの活用」について Q. Gateway Load Balancer を導入した場合、レイテンシの増加などによるアプリケーションへのパフォーマンス影響はありますか? A. セキュリティ仮想アプライアンスにてどのような検査を実施するかによって、どの程度パフォーマンスに影響するかが変わってくるものかと思います。 この影響を最小限にするために、AutoScaling による適切なインスタンスの配置や、クロスゾーンでの負荷分散をご活用頂けます。詳細については下記ドキュメントをご参照ください。 AutoScalingの活用 https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/attach-load-balancer-asg.html クロスゾーン負荷分散の活用 https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/gateway/gateway-load-balancers.html#cross-zone-load-balancing 次回予告 次回は「 Container 」編です。 ゲストスピーカーとして、株式会社ラクスの下西 氏、freee 株式会社の藤原 氏をお招きしましてコンテナ運用ノウハウKubernetes ネイティブのワークフローエンジンである Argo Workflows を Amazon EKS Cluster に導入する方法などに DiveDeep してお伝えします。 次回も多くの方々のご参加を心よりお待ちしております! 2023 年 4 月以降に開催予定の『アップデート紹介とちょっぴり DiveDeep する AWS の時間』の視聴申し込みを一括でできるようになりました!毎月申し込みする必要はなくなります。また、イベント開催直前にリマインドメールをお送りいたします。下記リンクから参加ご希望月の申し込みをお願いいたします。 第三十四回「アップデート紹介とちょっぴり DiveDeep する AWS の時間」- Container 編- 開催日時:2023 年 9 月 28 日(木)16:00 – 17:30 オンライン開催 アジェンダ 16:00 – 16:10 オープニングセッション 16:10 – 16:25 AWS 上でコンテナを爆速起動する方法をまとめてみた スピーカー: アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 祖父江 宏祐 16:25 – 16:40 AWS でメール配信システムを構築! Amazon ECS on AWS Fargate で楽楽運用 スピーカー: 株式会社ラクス インフラ開発部 東京インフラ開発2課 アシスタントマネージャー 下西 章王 氏 16:40 – 16:45 Q&amp;A 16:45 – 17:00 Amazon EKS と Argo Workflows で実現するタスク実行と AWS リソースとの連携方法 スピーカー: freee 株式会社 SRE / Developer Experience エンジニア 藤原 彰人 氏 17:00 – 17:15 Amazon EKS と KubeVela でプラットフォームエンジニアリングに入門しよう! スピーカー: アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 17:15 – 17:20 Q&amp;A 17:20 – 17:30 クロージングセッション このブログの著者 前田 駿介 ( Maeda Shunsuke ) ソリューションアーキテクトとして ISV/SaaS 系のお客様の技術支援を行っております。好きなサービスは Amazon Cognito です。自転車で琵琶湖一周してきました。
はじめに ビデオオンデマンドのワークフローを大規模に設計・運用する場合、お客様はトランスコーディングパイプラインのパフォーマンスに関するインサイトを得るために豊富なメトリックデータを必要とします。 AWS Elemental MediaConvert は、 Amazon CloudWatch および Amazon EventBridge とネイティブに統合されており、Amazon Web Services (AWS) 上で実用的かつ観測可能なシステムを構築するために必要なツールをお客様に提供します。 MediaConvert では、オブザーバビリティのポートフォリオを拡張するメディアメトリクスの提供を開始しました。これにより、CloudWatch や EventBridge における メディア固有のメトリクスを 監視するエクスペリエンスが向上しました。メディアメトリクスを活用することで、お客様は潜在的な問題を早期に特定し、必要な調整を行って動画品質および配信を最適化することができます。本ブログ記事では、MediaConvert で CloudWatch アラームと EventBridge ルールを使用してトランスコードの警告、ビデオコンテンツの黒味、字幕の欠落、エンコーディング品質スコアなどの要素に対して例外ベースの監視を構築する方法について説明します。 AWS Elemental MediaConvert イベント MediaConvert のユーザーは、 EventBridge イベント を使用して、ジョブのステータスや API コール、エラーに関する包括的な情報にアクセスすることができます。メディアメトリクスの公開に伴い、MediaConvert のジョブは、EventBridge を通じて警告コードやその他の動画品質に関する情報を発行できるようになります。これらの警告は、トランスコードの失敗につながるとは限らないものの、ジョブの出力に予期せぬ影響を及ぼしかねない事態がトランスコードで見つかったことを示します。発生する可能性のある警告の例としては、音声と映像の同期に関する問題、字幕の欠落、出力先 Amazon S3 バケットでのスロットリングなどがあります。お客様は、これらの警告を既存のジョブステータス変更イベントと組み合わせて使用することで、広範なイベント駆動型ワークフローを構築し、品質に影響を与えうるアラートについて詳細な通知を設定することができます。警告情報は AWS コンソールとジョブ (GetJob、ListJobs) の API レスポンスからも確認できます。警告コードの包括的なリストについては、 こちらのリンク を参照してください。 EventBridge では、MediaConvert のイベントを他の AWS サービスやサードパーティアプリケーションと簡単に統合できます。以下に、ユニークな警告状態が初めて発生した際にNEW_WARNINGイベントとして受信され得るイベントパターンとイベントペイロードの例、およびジョブ COMPLETE イベントのイベントペイロードを示します。ジョブの COMPLETE および ERROR の CloudWatch イベントには、以下のようなさまざまな新しいイベントデータに加え、発生したすべてのユニークな警告の一覧も含まれます。 出力の平均ビットレート 出力の継続時間 (ミリ秒単位) 出力グループの解像度の詳細 連続ブラックフレームの開始/終了タイムスタンプ 動画に挿入されたパディングの量 品質指定可変ビットレート(QVBR)の品質レベルに関する統計データ これらのサンプルを使用して、受信した警告イベントを照合してフィルタリングするための EventBridge ルールを作成し、それらを Amazon Simple Notification Service (Amazon SNS) などのターゲットに送信して処理することができます。イベント駆動型のアプローチをとることで、以下のようなさまざまな方法でアクションを自動化できます。 MediaConvert ジョブの状態変更や警告の通知を受け取る AWS Lambda など他の AWS サービスを使って修復アクションを自動化する サードパーティーのソリューションと連携して、実行可能なパイプラインを作成・拡張する AWS Media Services 用に Amazon SNS で EventBridge 通知を設定する詳しい手順については、 こちらのリンク を参照してください。 EventBridge イベントパターン { "source": ["aws.mediaconvert"], "detail-type": ["MediaConvert Job State Change"], "detail": { "status": ["NEW_WARNING"] } } AWS Elemental MediaConvert NEW_WARNING のペイロード例 { "version": "0", "id": "1234abcd-12ab-34cd-56ef-1234567890ab", "detail-type": "MediaConvert Job State Change", "source": "aws.mediaconvert", "account": "111122223333", "time": "2018-01-07T23:35:20Z", "region": "us-west-2", "resources": ["arn:aws:mediaconvert:us-west-2:111122223333:jobs/1515368087458-qnoxtd"], "detail": { "timestamp": 1515368120764, "accountId": "111122223333", "queue": "arn:aws:mediaconvert:us-west-2:111122223333:queues/Default", "jobId": "1515368087458-qnoxtd", "status": "NEW_WARNING", "warningCode": "000000", "warningMessage": "Example warning message", "userMetadata": {} } } AWS Elemental MediaConvert COMPLETE のペイロード例 { "version": "0", "id": "1234abcd-12ab-34cd-56ef-1234567890ab", "detail-type": "MediaConvert Job State Change", "source": "aws.mediaconvert", "account": "111122223333", "time": "2022-12-19T19:07:12Z", "region": "us-west-2", "resources": [ "arn:aws:mediaconvert:us-west-2::jobs/1671476818694-phptj0" ], "detail": { "timestamp": 1671476832124, "accountId": "111122223333", "queue": "arn:aws:mediaconvert:us-west-2:111122223333:queues/Default", "jobId": "1671476818694-phptj0", "status": "COMPLETE", "userMetadata": {}, "warnings": [ { "code": 000000, "count": 1 } ], "outputGroupDetails": [ { "outputDetails": [ { "outputFilePaths": [ "s3://DOC-EXAMPLE-BUCKET/file/file.mp4" ], "durationInMs": 30041, "videoDetails": { "widthInPx": 1920, "heightInPx": 1080, "qvbrAvgQuality": 7.38, "qvbrMinQuality": 7, "qvbrMaxQuality": 8, "qvbrMinQualityLocation": 2168, "qvbrMaxQualityLocation": 25025 } } ], "type": "FILE_GROUP" } ], "paddingInserted": 0, "blackVideoDetected": 10, "blackSegments": [ { "start": 0, "end": 10 } ] } } AWS Elemental MediaConvert のメトリクス AWS Elemental MediaConvert は、トランスコーディングワークフローと動画コンテンツのパフォーマンスの監視に使用できる CloudWatch メトリクスを発行します。CloudWatch メトリクスを使用して MediaConvert のキュー、ジョブ、出力を監視する方法をいくつか紹介します。 プログラムエラーの監視:お客様は、CreateJob、GetJob、ListJob などの MediaConvert API を呼び出す際に発生したエラーを追跡できます。 キュー効率の監視:キューメトリクスを使用して、特定のキューのジョブ数やトランスコーディングジョブの完了に要する時間などの詳細を取得します。 エンコードパフォーマンスの監視:メディア固有のメトリクスにより、お客様は、ソースコンテンツの動画品質や MediaConvert 出力の動画品質を把握しやすくなります。 MediaConvert でメディアメトリクスを使用することで、お客様は、ソースコンテンツと出力に関する活用可能な情報量を増やすことができます。たとえば、入力アセットのブラックフレーム数や、トランスコードされたコンテンツのビットレートや映像品質スコアを監視することができます。以下は、MediaConvert 用に新たに導入されたメディア固有の CloudWatch メトリクスのリストです。MediaConvert メトリクスの包括的なリストについては、 こちらのリンク を参照してください。 メトリクス名 説明 単位 ディメンション VideoPaddingInserted ジョブの出力全体において、MediaConvert により挿入された空白フレームの合計時間(ミリ秒単位)。 動画のパディング処理では音声と映像の時間を揃えるために空白のフレームが挿入されます。VideoPaddingInserted の値が大きいと、より多くの空白フレームが挿入されたことを示しています。また、入力のオーディオトラックが、遅れて開始、早く終了、あるいはどちらも該当する場合、その程度を示します。 ミリ秒 Queue VideoPaddingInsertedRatio MediaConvert によって挿入された空白フレームと出力合計時間の比率。 この比率が高いと、入力の音声と映像の同期に問題がある可能性があります。 比率 Queue QVBRAvgQualityHighBitrate 出力グループの最高ビットレート出力の平均 QVBR 品質スコア。 スコア Queue, Output Group Type QVBRAvgQualityLowBitrate 出力グループの最低ビットレート出力の平均 QVBR 品質スコア。 スコア Queue, Output Group Type QVBRMinQualityHighBitrate 出力グループの最高ビットレート出力の最小 QVBR 品質スコア。 スコア Queue, Output Group Type QVBRMinQualityLowBitrate 出力グループの最低ビットレート出力の最小 QVBR 品質スコア。 スコア Queue, Output Group Type BlackVideoDetected 入力側と共通して存在する出力側のブラックビデオフレームの合計時間(ミリ秒単位)。 BlackVideoDetected には、MediaConvert により挿入されたブラックフレームは含まれていないことに留意してください。 ミリ秒 Queue BlackVideoDetectedRatio ブラックビデオフレームと出力合計時間の比率。 比率が高いほど、出力にブラックフレームが多いことを示します。 比率 Queue LongestBlackSegmentDetected 最長の連続ブラックビデオフレームセグメントの出力位置(ミリ秒単位)。 ミリ秒 Queue AvgBitrateTop 出力グループの最高ビットレート出力の平均ビットレート。 ビット毎秒 Queue, Output Group Type AvgBitrateBottom 出力グループの最低ビットレート出力の平均ビットレート。 ビット毎秒 Queue, Output Group Type お客様は、 CloudWatch Dashboards を使って CloudWatch メトリクスを一元的に表示し、トランスコーディングジョブのパフォーマンスと動画の品質を包括的に把握することで、MediaConvertジョブを常時監視することができます。より積極的なアプローチとしては、 CloudWatch アラーム の使用をおすすめします。このアラームを使用することで、特定のメトリクスが指定されたしきい値を超えた場合について、通知を受け取り、アクションを自動化することができます。MediaConvert のメディアメトリクスを使用すると、お客様はトランスコードアセットのブラックビデオフレームや、パディングされたビデオフレーム、ビットレート統計データ、映像品質スコアに関するしきい値のアラームを作成することができます。EventBridge と同様に、ユーザーはしきい値違反に対し、SNS を使用した通知の送信や、他の AWS サービスやサードパーティソリューションの呼び出しなど、さまざまなアクションを実行できます。CloudWatch Alarms を使うと、モニタリングのオーバーヘッドを削減し、トランスコーディングパイプラインの可視性を向上させることができるため、潜在的な問題に迅速かつ適切に対応することが可能になります。 こちらのブログ記事 では、Amazon CloudWatch を使用して AWS Elemental MediaConvert のダッシュボードとアラームを作成する詳細な手順を説明しています。 おわりに メトリクスやイベントを使って AWS Elemental MediaConvert をモニタリングすることは、トランスコードされたコンテンツの映像と音声の詳細な品質メトリクスを取得し、お客様の体感品質 (QoE: Quality of Experience) に影響が出る前に問題を特定するうえで、非常に重要です。Amazon CloudWatch と Amazon EventBridge には、MediaConvert ワークフローに対するモニタリング・分析・アクションを行うための強力なツールセットが用意されているため、ユーザーは MediaConvert のパフォーマンスに関する貴重なインサイトを取得し、何か問題が発生した場合には迅速に解決することができます。MediaConvert のメディアメトリクスは、動画コンテンツとトランスコーディングジョブに関する豊富なデータを提供し、動画ワークフローと動画品質を最適化するために使用できます。トランスコードの警告、映像品質スコア、ブラックフレーム、ビットレート統計データなどの主要なメトリクスを追跡することで、十分な情報に基づいた意思決定を行い、動画アセットの全体的な品質を向上させることができます。今後も、MediaConvert のオブザーバビリティ機能をさらに強化する新たなイベントやメトリクスにご期待ください。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口、SA 井村が担当しました。原文は こちら をご覧ください。
みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 8月よりは気温が下がってきたとはいえ、まだまだ暑い日が続きますね。そろそろ早朝ウォーキングが快適にできる気温に落ち着いてくれると嬉しいのですが。 さて、今週開催のイベントについてのお知らせです。海外から DynamoDB Book の著者であり AWS Serverless Hero である Alex DeBrie 氏が来日されるので、それに合わせて Developer x NoSQL night at AWS Loft Tokyo というイベントが9月21日に目黒で開催されます。ご興味がある方はぜひお申込みください。 – Developer x NoSQL night at AWS Loft Tokyo 9/21 開催のお知らせ それでは、先週の主なアップデートについて振り返っていきましょう。 2023年9月11日週の主要なアップデート 9/11(月) Amazon RDS for PostgreSQL Multi-AZ Deployment with two readable standbys now supports major version upgrades Amazon Relational Database Service (Amazon RDS) PostgreSQL の2 つの読み取り可能なスタンバイを備えた Amazon RDS マルチ AZ構成において、メジャーバージョンアップが簡単に行えるようになりました。管理コンソールからの操作で、v13.4からv14.5、もしくはv14.3から15.4にアップグレードできます。 Amazon RDS now supports M6id and R6id database instances Amazon Relational Database Service (Amazon RDS) で M6id および R6id DBインスタンスが利用可能になりました。 PostgresSQL、MySQL、 MariaDBでサポートされます。M6id/R6idは旧世代のR5dと比較して最大で24%の性能向上を実現しており、オンデマンド料金で比較すると最大13%のコスト/性能比を実現します。 9/12(火) Announcing memory optimized Amazon EC2 R7a instances Amazon EC2 R7a インスタンスが利用可能になりました。現在US East (Ohio)、 US East (N. Virginia)、 US West (Oregon)、 Europe (Ireland)リージョンで利用可能です。R7aは第四世代 AMD EPYC プロセッサ(Genoa)を搭載し、旧世代(R6a)と比較して最大50%高いパフォーマンスを実現します。R7aインスタンスの詳細は こちらをご覧ください 。 AWS IAM Identity Center session duration limit increases from 7 to 90 days AWS IAM Identity Center で、ユーザーが(再認証なしで) アクセスポータルへのセッションを維持できる期間を最大90日間に設定することが可能になりました(これまでは最大7日間でした)。 9/13(水) Announcing post-launch actions framework for AWS Elastic Disaster Recovery 災害時のAWS へのアプリケーションの復旧を支援する AWS Elastic Disaster Recovery&nbsp;(AWS DRS) で、インスタンスリカバリー後のアクション(post action)が定義可能になりました。 AWS Systems Manager (AWS SSM) コマンドを呼び出すカスタムアクションが定義できるため、例えばリカバリ成功後にCloudWatchエージェントを導入するといった操作を自動化することが可能になります。 Knowledge base for Amazon Bedrock connects foundation models to your data sources 生成系 AI アプリケーションの基盤モデル(Foundation Model, FM)構築を支援する Amazon Bedrock で knowledge base (ナレッジベース)を定義する機能が追加されました。Bedrockのagentを経由して、FMと企業内のデータをセキュアに接続することを可能にします。詳細は こちらのブログ をご覧ください。 Amazon EMR on EKS now supports Amazon Linux 2023 Amazon EMR on EKS 6.13 で Amazon Linux 2023 (AL2023) がサポートされました。AL2023には Java 17 が含まれており、これを使って Amazon EMR on EKS 上でApache Sparkアプリケーションを稼働させることが可能になります。詳細は こちらのドキュメントをご覧ください 。 Amazon EC2 now supports Block Public Access for Amazon Machine Images Amazon EC2 AMI Block Public Access (BPA) 機能がリリースされました。自身のAWSアカウント以外からのAMI(Amazon Machine Image)へのアクセスを禁止することができる機能です。これまでもAMI単位でパブリックアクセスの可否を設定できましたが、BPAを有効にするとそのAWSアカウント内ではパブリックアクセス可能なAMIを作成できなくなり、操作ミス等で外部に公開することを防ぐことができます。 Announcing API Gateway console refresh Amazon API Gateway の管理コンソールのUIが刷新されました。REST、WebSocket API 作成のワークフロー改善や、アクセシビリティの改善、ダークモードのサポート等の改善がおこなれています。 9/14(木) Introducing Amazon EC2 C7i instances Amazon EC2 C7i インスタンスが利用可能になりました。現在 US East (Ohio)、 US East (N. Virginia)、 US West (Oregon)、 Europe (Ireland)、 Europe (Spain)、 Europe (Stockholm) リージョンで利用可能です。C7iは第四世代 Intel Xeon Scalable processors (Sapphire Rapids) を搭載し、旧世代(C6i)と比較して最大15%高い価格性能比を提供します。C7iの 詳細はこちらのページをご覧ください 。 Amazon SNS FIFO topics now support message delivery to Amazon SQS Standard queues Amazon Simple Queue Service (SQS) の 標準キューから、SQSのFIFOキューのトピックをサブスクライブできるようになりました。これにより、FIFOキューのメッセージを標準キューに渡すことが容易に実現可能になりました。 9/15(金) PostgreSQL 16.0 is now available in Amazon RDS Database Preview Environment Amazon Relational Database Service (Amazon RDS) for PostgreSQL のプレビュー環境において、9月14日にリリースされた PostgreSQL v16.0 が利用可能になりました。RDSのプレビュー環境は、本番環境へのデプロイ前に新しいデータベースエンジンをテスト・評価するためのものです。 それでは、また来週! ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )
この投稿では、 Amazon Kendra と Amazon Rekognition を使用した複雑な画像を検索するための機械学習 (ML) ソリューションについて説明します。具体的には、多数の異なるビジュアルアイコンとテキストが組み込まれているアーキテクチャ図の例を使用します。 インターネットを使えば、画像を検索して取得することはかつてないほど簡単になりました。ほとんどの場合、次の休暇を過ごす場所の画像を検索するなど、目的の画像を正確に見つけることができます。単純な検索は成功しやすいですが、多くの特徴に関連していないためです。目的の画像特性を超えて、通常、検索基準は必要な結果を見つけるための詳細情報を必要としません。たとえば、特定の種類の青いボトルを検索しようとする場合、さまざまな種類の青いボトルの結果が表示されます。ただし、一般的な検索用語のため、目的の青いボトルが簡単に見つからない場合があります。 検索コンテキストの解釈も結果の簡素化に寄与します。ユーザーが特定の画像を考えている場合、それをテキストベースの検索クエリに組み立てようとします。類似したトピックの検索クエリの違いを理解することは重要で、関連する結果を提供し、ユーザーが手動で結果を整理する必要がある手間を最小限に抑えるのに役立ちます。たとえば、“Dog owner plays fetch” (訳注: ここでの plays fetch は、ボールなどのおもちゃを投げて、犬が取ってくる遊び。)という検索クエリは、犬の飼い主が犬と一緒にフェッチをする遊びを示す画像結果を期待しています。しかし、実際の結果は飼い主の関与を表示せず、犬が物をフェッチすることに焦点を当てる場合もあります。複雑な検索を扱う際、ユーザーは不適切な画像結果を手動でフィルタリングする必要があるかもしれません。 複雑な検索に関連する問題に対処するため、この投稿では詳細に説明します。Amazon Kendra と Amazon Rekognition を統合することで、複雑な画像を検索できる検索エンジンをどのように実現できるかを。Amazon Kendra は ML によって強化されたインテリジェントな検索サービスであり、Amazon Rekognition は画像や動画からオブジェクト、人物、テキスト、シーン、アクティビティを識別できる ML サービスです。 どのような画像が検索対象にするには複雑すぎるでしょうか? 一つの例として挙げられるのがアーキテクチャ図です。これらはユースケースの複雑さや必要な技術サービスの数に応じて多くの検索基準と関連付けることができ、ユーザーにとって大きな手動検索の労力を必要とします。例えば、ユーザーが顧客認証のユースケースに適したアーキテクチャの解決策を探したい場合、通常、「顧客認証のためのアーキテクチャ図」といった検索クエリを使用します。しかし、一般的な検索クエリは幅広いサービスと異なるコンテンツ作成日を網羅します。ユーザーは特定のサービスに基づいて適切なアーキテクチャ候補を手動で選択し、コンテンツ作成日と検索日に応じてアーキテクチャ設計の選択の関連性を考慮する必要があります。 次の図は、オーケストレーションされた抽出、変換、ロード (ETL) を実行するソリューションのアーキテクチャを示す図の例を示しています。 クラウドプラットフォームの提供サービスに慣れていないユーザーは、このような図を検索する際に、異なる一般的な方法や説明を提供することがあります。以下は、それがどのように検索されるかのいくつかの例です。 「ETLワークフローをオーケストレーションする」 「バルクデータ処理を自動化する方法」 「データを変換するためのパイプラインを作成する方法」 ソリューションの概要 ソリューションを実装するための以下の手順を順を追って説明します。 Amazon Rekognition カスタムラベル でモデルをトレーニングして、アーキテクチャ図内のシンボルを認識できるようにします。 Amazon Rekognition のテキスト検出機能を組み込んで、アーキテクチャ図のシンボルを検証します。 Amazon Rekognition をウェブクローラー内で使用して、検索用のリポジトリを構築します。 Amazon Kendra を使用してリポジトリを検索します。 関連する結果の大規模なリポジトリをユーザーに簡単に提供するには、信頼できるソースを検索する自動化された方法が必要です。アーキテクチャ図を例にとると、ソリューションはアーキテクチャ図の参照リンクや技術文書を検索し、存在するサービスを特定する必要があります。これらのソースからユースケースや業種などのキーワードを特定することで、情報を収集し、より関連性の高い検索結果をユーザーに表示することもできます。 関連する図をどのように検索するかという目的を考慮すると、画像検索ソリューションは次の 3 つの基準を満たす必要があります。 簡易キーワード検索を有効にする ユーザーが提供するユースケースに基づいて検索クエリを解釈する 検索結果の並べ替えと並べ替え キーワード検索では、単に「Amazon Rekognition」を検索し、さまざまなユースケースでサービスがどのように使用されているかを示すアーキテクチャ図が表示されます。あるいは、アーキテクチャに関連するユースケースや業種を通じて、検索語を図に間接的にリンクさせることもできます。たとえば、「ETL パイプラインのオーケストレーション方法」という用語を検索すると、 AWS Glue と AWS Step Functions で構築されたアーキテクチャ図の結果が返されます。作成日などの属性に基づいて検索結果を並べ替えたり並べ替えたりすることで、サービスの更新やリリースがあってもアーキテクチャ図の関連性が保たれます。次の図は、画像検索ソリューションのアーキテクチャ図を示しています。 前の図とソリューションの概要に示されているように、このソリューションには主に 2 つの側面があります。1 つ目の側面は Amazon Rekognition で行われます。Amazon Rekognition は画像や動画を大規模に分析するために適用できる事前トレーニング済みのモデルで構成されています。Amazon Rekognition のカスタムラベル機能により、ソースから照合した画像を、信頼できる参照リンクや技術文書内のアーキテクチャ図にラベル付けすることで、ML サービスを特定のビジネスニーズに合わせて調整できます。Amazon Rekognition は、少量のトレーニングイメージをアップロードすることで、トレーニングデータを自動的に読み込んで検査し、適切な ML アルゴリズムを選択、モデルをトレーニングし、モデルパフォーマンスメトリクスを提供します。したがって、ML の専門知識がないユーザーでも、オーバーヘッドが大幅に削減されるため、API 呼び出しを通じてカスタムラベルモデルのメリットを享受できます。このソリューションでは、Amazon Rekognition カスタムラベルを適用してアーキテクチャ図上の AWS サービスロゴを検出し、アーキテクチャ図をサービス名で検索できるようにします。モデリングが完了すると、各アーキテクチャ図イメージとそのメタデータ (URL オリジンやイメージタイトルなど) で検出されたサービスが、今後の検索に備えてインデックス化され、高性能アプリケーションを実行するように設計された、フルマネージド型のサーバーレスのキー値 NoSQL データベースである Amazon DynamoDB に保存されます。 2 つ目の側面は、ML を利用したインテリジェントなエンタープライズ検索サービスである Amazon Kendra によって実現されています。これにより、さまざまなコンテンツリポジトリを検索できます。Amazon Kendra では、画像やドキュメントなど、インデックス化された結果を検索できます。検索サービスには組み込みのコネクタが採用されているため、これらの結果をさまざまなリポジトリに保存することもできます。検索にはキーワード、フレーズ、説明を使用できます。これにより、特定のユースケースに関連する図を正確に検索できます。そのため、最小限の開発コストでインテリジェントな検索サービスを簡単に構築できます。 問題と解決策を理解した上で、以降のセクションでは、信頼できるソースからアーキテクチャ図をクロールしてデータソーシングを自動化する方法について詳しく説明します。続いて、フルマネージドサービスでカスタムラベル ML モデルを生成するプロセスを順を追って説明します。最後に、ML を利用したインテリジェントな検索サービスによるデータ取り込みについて説明します。 カスタムラベルを使用して Amazon Rekognition モデルを作成する アーキテクチャ図を入手する前に、画像をアーキテクチャ図として識別できるかどうかを評価するツールが必要です。Amazon Rekognition カスタムラベルを使用すると、ビジネスニーズに特化した画像内のオブジェクトやシーンを識別する画像認識モデルを作成するためのプロセスが簡略化されます。このケースでは、Amazon Rekognition カスタムラベルを使用して AWS サービスアイコンを識別し、Amazon Kendra を使用してより関連性の高い検索を行えるように、そのサービスにイメージがインデックス付けされます。このモデルでは、画像全体がアーキテクチャ図であるかどうかは区別されません。サービスアイコンがあればそれを識別するだけです。そのため、アーキテクチャ図ではない画像が検索結果に表示される場合があります。ただし、このような結果はごくわずかです。 次の図は、このソリューションが Amazon Rekognition カスタムラベルモデルを作成するために実行する手順を示しています。 このプロセスには、データセットをアップロードし、アップロードされたデータセットを参照するマニフェストファイルを生成してから、このマニフェストファイルを Amazon Rekognition にアップロードすることが含まれます。Python スクリプトは、データセットをアップロードしてマニフェストファイルを生成するプロセスを支援するために使用されます。マニフェストファイルが正常に生成されると、Amazon Rekognition にアップロードされ、モデルトレーニングプロセスが開始されます。Python スクリプトとその実行方法の詳細については、 GitHub リポジトリ を参照してください。 モデルをトレーニングするには、Amazon Rekognition プロジェクトで [新しいモデルをトレーニングする] を選択し、トレーニングするプロジェクトを選択します。次に、関連するタグを追加して [モデルをトレーニング] を選択します。Amazon Rekognition カスタムラベルプロジェクトの開始方法については、利用可能な ビデオチュートリアル を参照してください。このデータセットを使用してモデルをトレーニングするには、最大 8 時間かかる場合があります。 トレーニングが完了したら、トレーニング済みのモデルを選択して評価結果を表示できます。精度、再現率、F1 などのさまざまな指標の詳細については、 モデルを評価するための指標 を参照してください。モデルを使用するには、[モデルを使用] タブに移動し、推論単位の数を 1 のままにして、モデルを起動します。次に、 AWS Lambda 関数を使用して base64 の形式でモデルに画像を送信すると、モデルはラベルと信頼度スコアのリストを返します。 Amazon Rekognition カスタムラベルを使用して Amazon Rekognition モデルを正常にトレーニングできたら、このモデルを使用して、クロールされたアーキテクチャ図内のサービスアイコンを識別できます。アーキテクチャ図でサービスを識別する精度を高めるために、 テキスト検出 と呼ばれる別の Amazon Rekognition 機能を使用しています。この機能を使用するには、base64 の形式で同じ画像を渡すと、Amazon Rekognition はその画像で識別されたテキストのリストを返します。以下の 2 つの図では、元の画像と、画像内のサービスを特定した後の画像を比較しています。最初の図は元の画像を示しています。 次の図は、検出されたサービスを含む元の画像を示しています。 スケーラビリティを確保するために、 Amazon API Gateway を使用して作成された API エンドポイントを通じて公開される Lambda 関数を使用しています。Lambda はサーバーレスのイベント駆動型コンピューティングサービスで、サーバーのプロビジョニングや管理をしなくても、事実上あらゆるタイプのアプリケーションやバックエンドサービスのコードを実行できます。Lambda 関数を使用すると、API エンドポイントに大量のリクエストが行われた場合のスケールアップに関する一般的な懸念がなくなります。Lambda は特定の API 呼び出しに対して自動的に関数を実行し、呼び出しが完了すると停止するため、ユーザーにかかるコストが削減されます。リクエストは Amazon Rekognition エンドポイントに送信されるため、スケーラブルな Lambda 関数だけでは十分ではありません。Amazon Rekognition エンドポイントをスケーラブルにするには、エンドポイントの推論ユニットを増やすことができます。 推論ユニット の設定の詳細については、推論ユニットを参照してください。 以下は、画像認識処理の Lambda 関数のコードスニペットです。 const AWS = require("aws-sdk"); const axios = require("axios"); // 個々のサービスに関する情報を取得するAPI const SERVICE_API = process.env.SERVICE_API; // Amazon Rekognition モデルの ARN const MODEL_ARN = process.env.MODEL_ARN; const rekognition = new AWS.Rekognition(); exports.handler = async (event) =&gt; { const body = JSON.parse(event["body"]); let base64Binary = ""; // ペイロードに画像のURLまたはbase64形式の画像が含まれているか確認 const base64Res = await new Promise((resolve) =&gt; { axios .get(body.url, { responseType: "arraybuffer", }) .then((response) =&gt; { resolve(Buffer.from(response.data, "binary").toString("base64")); }); }); base64Binary = new Buffer.from(base64Res, "base64"); } else if (body.byte) { const base64Cleaned = body.byte.split("base64,")[1]; base64Binary = new Buffer.from(base64Cleaned, "base64"); } // トレーニングされたカスタムラベルモデルとテキスト検出にコンテンツを渡す const [labels, text] = await Promise.all([ detectLabels(rekognition, base64Binary, MODEL_ARN), detectText(rekognition, base64Binary), ]); const texts = text.TextDetections.map((text) =&gt; ({ DetectedText: text.DetectedText, ParentId: text.ParentId, })); // 重複するラベルを比較し、最も信頼度の高いラベルをそのまま使用 let filteredLabels = removeOverlappingLabels(labels); // すべてのラベルを信頼度の高いものから最も信頼度の低いものへと並べ替え filteredLabels = sortByConfidence(filteredLabels); // リスト内の重複したサービスを削除 const services = retrieveUniqueServices(filteredLabels, texts); // 各サービスを参照ドキュメント API に渡して、ドキュメントの URL を取得 const refLinks = await getReferenceLinks(services); var responseBody = { labels: filteredLabels, text: texts, ref_links: refLinks, }; console.log("Response: ", response_body); const response = { statusCode: 200, headers: { "Access-Control-Allow-Origin": "*", // Required for CORS to work }, body: JSON.stringify(responseBody), }; return response; }; // セクション短縮するためにコードを省略 Lambda 関数を作成したら、API Gateway を使用して API として公開することができます。Lambda プロキシ統合を使用して API を作成する手順については、「チュートリアル: Build a Hello World REST API with Lambda proxy integration. を参照してください。 アーキテクチャ図をクロールする 検索機能を簡単に機能させるには、アーキテクチャ図のリポジトリが必要です。ただし、これらの図は、 AWS ブログ や AWS 規範的ガイダンス などの信頼できる情報源からのものでなければなりません。データソースの信頼性を確立することで、ユースケースの根底にある実装と目的が正確になり、十分に吟味されていることが保証されます。次のステップは、多くのアーキテクチャ図を集めてリポジトリに加えるのに役立つクローラを設定することです。関連するソースからアーキテクチャ図や実装の説明などの情報を抽出するウェブクローラーを作成しました。このようなメカニズムを構築する方法は複数あります。この例では、 Amazon Elastic Compute Cloud (Amazon EC2) で実行されるプログラムを使用しています。プログラムは最初に AWS ブログ API からブログ投稿へのリンクを取得します。API から返されるレスポンスには、タイトル、URL、日付、投稿内の画像へのリンクなど、投稿の情報が含まれます。 以下は、Web クロールプロセスの JavaScript 関数のコードスニペットです。 import axios from "axios"; import puppeteer from "puppeteer"; import { putItemDDB, identifyImageHighConfidence, getReferenceList, } from "./utils.js"; /** グローバル変数 */ const blogPostsApi = process.env.BLOG_POSTS_API; const IMAGE_URL_PATTERN = "&lt;pattern in the url that identified as link to image&gt;"; const DDB_Table = process.env.DDB_Table; // パブリック API からレコードの URL を取得する関数 function getURLs(blogPostsApi) { // URL のリストをリターン return axios .get(blogPostsApi) .then((response) =&gt; { var data = response.data.items; console.log("RESPONSE:"); const blogLists = data.map((blog) =&gt; [ blog.item.additionalFields.link, blog.item.dateUpdated, ]); return blogLists; }) .catch((error) =&gt; console.error(error)); } // 個々の URL のコンテンツをクロールする関数 async function crawlFromUrl(urls) { const browser = await puppeteer.launch({ executablePath: "/usr/bin/chromium-browser", }); // const browser = await puppeteer.launch(); const page = await browser.newPage(); let numOfValidArchUrls = 0; for (let index = 0; index &lt; urls.length; index++) { console.log("index: ", index); let blogURL = urls[index][0]; let dateUpdated = urls[index][1]; await page.goto(blogURL); console.log("blogUrl:", blogURL); console.log("date:", dateUpdated); // URL パターンに基づいて投稿から画像を識別して取得 const images = await page.evaluate(() =&gt; Array.from(document.images, (e) =&gt; e.src) ); const filter1 = images.filter((img) =&gt; img.includes(IMAGE_URL_PATTERN)); console.log("all images:", filter1); // 画像がアーキテクチャ図かどうかを検証 for (let index_1 = 0; index_1 &lt; filter1.length; index_1++) { const imageUrl = filter1[index_1]; const rekog = await identifyImageHighConfidence(imageUrl); if (rekog) { if (rekog.labels.size &gt;= 2) { console.log("Rekog.labels.size = ", rekog.labels.size); console.log("Selected image url = ", imageUrl); let articleSection = []; let metadata = await page.$$('span[property="articleSection"]'); for (let i = 0; i &lt; metadata.length; i++) { const element = metadata[i]; const value = await element.evaluate( (el) =&gt; el.textContent, element ); console.log("value: ", value); articleSection.push(value); } const title = await page.title(); const allRefLinks = await getReferenceList( rekog.labels, rekog.textServices ); numOfValidArchUrls = numOfValidArchUrls + 1; putItemDDB( blogURL, dateUpdated, imageUrl, articleSection.toString(), rekog, { L: allRefLinks }, title, DDB_Table ); console.log("numOfValidArchUrls = ", numOfValidArchUrls); } } if (rekog &amp;&amp; rekog.labels.size &gt;= 2) { break; } } } console.log("valid arch : ", numOfValidArchUrls); await browser.close(); } async function startCrawl() { // URL のリストを取得 // それらの URL からアーキテクチャ図を抽出 const urls = await getURLs(blogPostsApi); if (urls) console.log("Crawling urls completed"); else { console.log("Unable to crawl images"); return; } await crawlFromUrl(urls); } startCrawl(); このメカニズムにより、さまざまなブログから何百、何千もの画像を簡単にクロールできます。ただし、アーキテクチャ図ではない画像を除外するには、アーキテクチャ図(この場合は AWS サービスのアイコン)の内容を含む画像のみを受け入れるフィルタが必要です。 これが Amazon Rekognition のモデルを利用する目的です。ダイアグラムは画像認識プロセスを経てサービスアイコンを識別し、それが有効なアーキテクチャ図と見なせるかどうかを判断します。 以下は、Amazon Rekognition モデルに画像を送信する関数のコードスニペットです。 import axios from "axios"; import AWS from "aws-sdk"; // 設定 AWS.config.update({ region: process.env.REGION }); /** グローバル変数 */ // 画像を特定する API const LABEL_API = process.env.LABEL_API; // 個々のサービスの関連ドキュメントを取得するための API const DOCUMENTATION_API = process.env.DOCUMENTATION_API; // DynamoDB サービスのオブジェクトを作成する const dynamoDB = new AWS.DynamoDB({ apiVersion: "2012-08-10" }); // Amazon Rekognition モデルを呼び出す API を使用して画像を識別する関数 function identifyImageHighConfidence(image_url) { return axios .post(LABEL_API, { url: image_url, }) .then((res) =&gt; { let data = res.data; let rekogLabels = new Set(); let rekogTextServices = new Set(); let rekogTextMetadata = new Set(); data.labels.forEach((element) =&gt; { if (element.Confidence &gt;= 40) rekogLabels.add(element.Name); }); data.text.forEach((element) =&gt; { if ( element.DetectedText.includes("AWS") || element.DetectedText.includes("Amazon") ) { rekogTextServices.add(element.DetectedText); } else { rekogTextMetadata.add(element.DetectedText); } }); rekogTextServices.delete("AWS"); rekogTextServices.delete("Amazon"); return { labels: rekogLabels, textServices: rekogTextServices, textMetadata: Array.from(rekogTextMetadata).join(", "), }; }) .catch((error) =&gt; console.error(error)); } Amazon Kendra にメタデータを取り込む アーキテクチャ図が画像認識プロセスを経てメタデータが DynamoDB に保存されたら、メタデータの内容を参照しながら図を検索できるようにする方法が必要です。そのためのアプローチは、アプリケーションと統合でき、大量の検索クエリを処理できる検索エンジンを用意することです。このことから、インテリジェントなエンタープライズ検索サービスである Amazon Kendra を使用しています。 Amazon Kendra をソリューションのインタラクティブコンポーネントとして使用しているのは、その強力な検索機能、特に自然言語を使用できるためです。これにより、ユーザーが探しているものに最も近い図を検索するときの作業がさらに簡単になります。Amazon Kendra には、コンテンツを取り込んで接続するためのデータソースコネクタが多数用意されています。このソリューションでは、カスタムコネクタを使用して DynamoDB からアーキテクチャ図の情報を取り込みます。Amazon Kendra インデックスにデータソースを設定するには、既存のインデックスを使用するか、 新しいインデックスを作成 できます。 次に、クロールされた図を、作成された Amazon Kendra インデックスに取り込む必要があります。次の図は、図のインデックス作成の流れを示しています。 まず、DynamoDB に挿入された図によって Amazon DynamoDB Streams 経由で PUT イベントが作成されます。このイベントは、Amazon Kendra のカスタムデータソースとして機能する Lambda 関数をトリガーし、図をインデックスに取り込みます。Lambda 関数の DynamoDB ストリームトリガーを作成する手順については、チュートリアル: Using AWS Lambda with Amazon DynamoDB Streams を参照してください。 Lambda 関数を DynamoDB と統合したら、関数に送信されたダイアグラムのレコードを Amazon Kendra インデックスに取り込む必要があります。インデックスはさまざまなタイプのソースからデータを受け付けるため、Lambda 関数からインデックスに項目を取り込むには、カスタムデータソース設定を使用する必要があります。インデックスのカスタムデータソースを作成する手順については、 カスタムデータソースコネクタ を参照してください。 以下は、カスタムを利用した方法で図をインデックスに紐付ける方法を示す Lambda 関数のコードスニペットです。 import json import os import boto3 KENDRA = boto3.client("kendra") INDEX_ID = os.environ["INDEX_ID"] DS_ID = os.environ["DS_ID"] def lambda_handler(event, context): dbRecords = event["Records"] # Amazon DynamoDB からのアイテムを繰り返し処理 for row in dbRecords: rowData = row["dynamodb"]["NewImage"] originUrl = rowData["OriginURL"]["S"] publishedDate = rowData["PublishDate"]["S"] architectureUrl = rowData["ArchitectureURL"]["S"] title = rowData["Title"]["S"] metadata = rowData["Metadata"]["M"] crawlerMetadata = metadata["crawler"]["S"] rekognitionMetadata = metadata["Rekognition"]["M"] rekognitionLabels = rekognitionMetadata["labels"]["S"] rekognitionServices = rekognitionMetadata["textServices"]["S"] concatenatedText = ( f"{crawlerMetadata} {rekognitionLabels} {rekognitionServices}" ) add_document( dsId=DS_ID, indexId=INDEX_ID, originUrl=originUrl, architectureUrl=architectureUrl, title=title, publishedDate=publishedDate, text=concatenatedText, ) return # Kendra インデックスにダイアグラムを追加する関数 def add_document(dsId, indexId, originUrl, architectureUrl, title, publishedDate, text): document = get_document( dsId, indexId, originUrl, architectureUrl, title, publishedDate, text ) documents = [document] result = KENDRA.batch_put_document(IndexId=indexId, Documents=documents) print("result:" + json.dumps(result)) return True # 図を Kendra が受け付けられる形式の文書に整形します。 def get_document(dsId, originUrl, architectureUrl, title, publishedDate, text): document = { "Id": originUrl, "Title": title, "Attributes": [ {"Key": "_data_source_id", "Value": {"StringValue": dsId}}, {"Key": "_source_uri", "Value": {"StringValue": architectureUrl}}, {"Key": "_created_at", "Value": {"DateValue": publishedDate}}, {"Key": "publish_date", "Value": {"DateValue": publishedDate}}, ], "Blob": text, } return document 図を検索できるようにする重要な要素は、文書内の Blob キーです。これは、ユーザーが検索入力を行うときに Amazon Kendra が調べる内容です。このコード例の Blob キーには、画像認識プロセスで検出された情報を連結した図のユースケースの要約バージョンが含まれています。これにより、ユーザーは「不正検出」などのユースケースや「Amazon Kendra」などのサービス名に基づいてアーキテクチャ図を検索できます。 Blob キーの例として以下に示すスニペットは、この記事の前半で紹介した最初の ETL ダイアグラムを参照しています。これには、クロール時に取得された図の説明と、Amazon Rekognition モデルによって識別されたサービスが含まれています。 { ..., "Blob": "Build and orchestrate ETL pipelines using Amazon Athena and AWS Step Functions Amazon Athena, AWS Step Functions, Amazon S3, AWS Glue Data Catalog " } Amazon Kendra で検索 このユースケースを検索すると、さまざまなアーキテクチャ図が生成されます。ユーザーには、実装しようとしている特定のワークロードのさまざまな方法が提供されます。 クリーンアップ このセクションの手順を実行して、この記事の一部として作成したリソースをクリーンアップしてください。 API を削除します。 API Gateway コンソールで、削除する API を選択します。 「アクション」メニューで、「Delete」を選択します。 [削除] を選択して確定します。 DynamoDB テーブルを削除します。 DynamoDB コンソールのナビゲーションペインで [テーブル] を選択します。 作成したテーブルを選択し、[削除] を選択します。 確認を求められたら、確認 と入力します。 [削除] を選択して確定します Amazon Kendra インデックスを削除します。 Amazon Kendra コンソールのナビゲーションペインで [Indexes] を選択します。 作成したインデックスを選択し、[Delete] を選択します。 確認を求められたら、理由を入力します。 [削除] を選択して確定します。 Amazon Rekognition プロジェクトを削除します。 Amazon Rekognition コンソールのナビゲーションペインで [カスタムラベルを使用] を選択し、[プロジェクト] を選択します。 作成したプロジェクトを選択し、[削除] を選択します。 確認を求められたら、Delete と入力します。 [関連するデータセットとモデルを削除] を選択して確定します。 Lambda 関数を削除します。 Lambda コンソールで、削除する関数を選択します。 「アクション」メニューで、「削除」を選択します。 確認を求められたら、Delete と入力します。 [削除] を選択して確定します。 まとめ この記事では、画像から情報をインテリジェントに検索する方法の例を示しました。これには、画像のフィルターとして機能する Amazon Rekognition ML モデルをトレーニングするプロセス、信頼性と効率性を確保する画像クロールを自動化するプロセス、より柔軟にアイテムにインデックスを付けることができるカスタムデータソースをアタッチしてダイアグラムをクエリするプロセスが含まれます。コードの実装について詳しくは、 GitHub リポジトリ を参照してください。 複雑な検索のために一元化された検索リポジトリの基盤を提供する方法を理解したところで、独自の画像検索エンジンを作ってみましょう。コア機能の詳細については、「 Amazon Rekognition カスタムラベル入門 」、「 コンテンツのモデレーション 」、および「 Amazon Kendra デベロッパーガイド 」を参照してください。Amazon Rekognition カスタムラベルを初めてご利用になる場合は、無料利用枠を使って試してみてください。3 か月間有効で、1 か月あたり 10 時間の無料トレーニングと、1 か月あたり 4 時間の無料推論時間が含まれます。 著者について Ryan See は AWS のソリューションアーキテクトです。 シンガポールに拠点を置く彼は、顧客と協力してビジネス上の 問題を解決するソリューションを構築するとともに、 クラウドでよりスケーラブルで効率的なワークロードを実行できるように 技術的なビジョンを調整します。 James Ong Jia Xiang は AWS のカスタマーソリューションマネージャーです。 彼は移行加速プログラム (MAP) を専門としており、顧客やパートナーが AWS への大規模な移行プログラムを成功裏に実装できるよう支援しています。 シンガポールに拠点を置き、スケーラブルなメカニズムを通じてAPJ全体で 近代化と企業変革の取り組みを推進することにも注力しています。 余暇には、トレッキングやサーフィンなどの自然アクティビティを 楽しんでいます。 Hang Duong は AWS のソリューションアーキテクトです。 ベトナムのハノイに拠点を置き、可用性が高く安全でスケーラブルな クラウドソリューションを顧客に提供することで、国全体でクラウドの 採用を促進することに注力しています。 さらに、彼女はビルディングが好きで、さまざまなプロトタイピングプロジェクトに 携わっています。彼女は機械学習の分野にも情熱を注いでいます。 Trinh Vo は、ベトナムのホーチミン市を拠点とする AWS のソリューションアーキテクトです。 彼女は、ベトナムのさまざまな業界の顧客やパートナーと協力して、顧客の ビジネスニーズから逆算して機能する AWS プラットフォームのアーキテクチャと デモンストレーションを作成し、適切な AWS テクノロジーの採用を促進することに 重点を置いています。 彼女はレジャーとして洞窟探検やトレッキングを楽しんでいます。 Wai Kin Tham は AWS のクラウドアーキテクトです。 シンガポールに拠点を置く彼の日常業務は、顧客のクラウドへの移行とクラウド内の テクノロジースタックの最新化を支援することです。 自由時間には、ムエタイとブラジリアン柔術のクラスに参加しています。 翻訳はソリューションアーキテクトの福本が担当しました。原文は こちら です。
このブログ記事は Get started with the open-source Amazon SageMaker Distribution を翻訳したものです。 データサイエンティストは、機械学習(ML)およびデータサイエンスのワークロードに対して、セキュア且つ一貫性のある、依存関係の管理と再現可能の環境が必要です。 AWS Deep Learning Containers は、既にTensorFlow、PyTorch、MXNetなどのモデルトレーニングのフレームワークを事前構築されたDockerイメージで提供しています。利用者の体験を向上させるために、2023年のJupyterConでオープンソースのAmazon SageMaker Distributionのパブリックベータ版を発表しました。これにより、さまざまなレベルの専門知識を持つML開発者に統合されたエンドツーエンドのML体験が提供されます。開発者は、実験のために異なるフレームワークコンテナを切り替えたり、ローカルのJupyterLab環境とSageMakerノートブックからSageMaker上の本番ジョブに移行したりする必要がもはやありません。オープンソースのAmazon SageMaker Distributionは、TensorFlow、PyTorch、Scikit-learn、Pandas、Matplotlibなどのデータサイエンス、ML、可視化のための最も一般的なパッケージとライブラリをサポートしています。本日から Amazon ECR Public Gallery で公開されたコンテナを使用できます。 この記事では、オープンソースのAmazon SageMaker Distributionを使用して、ローカル環境で迅速に実験し、それらを簡単にSageMaker上のジョブに移行する方法を紹介します。 ソリューションの概要 この例では、PyTorchを使用して画像分類モデルのトレーニングを示します。公開されているPyTorchで利用可能な KMNIST データセットを使用します。ニューラルネットワークモデルをトレーニングし、モデルの性能をテストしてトレーニングとテストの損失を表示します。この例のノートブックは、 SageMaker Studio Labのサンプルリポジトリ で利用できます。オープンソースディストリビューションを使用してローカルのノートパソコンで実験を開始し、より大きなインスタンスを使用するために Amazon SageMaker Studio に移動し、最後にノートブックをノートブックジョブとしてスケジュールします。 前提条件 次の前提条件が必要です: Docker がインストールされていること。 管理者権限を持つアクティブなAWSアカウント。 AWS Command Line Interface(AWS CLI) とDockerがインストールされた環境。 既存のSageMakerドメイン。ドメインを作成するには、「 Amazon SageMakerドメインへのオンボード 」を参照してください。 ローカル環境のセットアップ SageMakerオープンソースディストリビューションを直接ローカルのノートパソコンで使用できます。JupyterLabを起動するには、ターミナルで次のコマンドを実行してください: export ECR_IMAGE_ID='public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu' docker run -it \ -p 8888:8888 \ --user `id -u`:`id -g` \ -v `pwd`/sample-notebooks:/home/sagemaker-user/sample-notebooks \ $ECR_IMAGE_ID jupyter-lab --no-browser --ip=0.0.0.0 ECR_IMAGE_ID を、 Amazon ECR Public Gallery で利用可能ないずれかのイメージタグで置き換えることができます。または、GPUをサポートするマシンを使用している場合は、 latest-gpu タグを選択できます。 このコマンドはJupyterLabを起動し、ターミナルに http://127.0.0.1:8888/lab?token=&lt;token&gt; のようなURLを提供します。リンクをコピーして、お好きなブラウザに入力してJupyterLabを起動してください。 Studioのセットアップ Studioは、開発者やデータサイエンティストがMLモデルをビルド、トレーニング、デプロイ、監視できる、スケールできるエンドツーエンドの統合開発環境(IDE)です。Studioには、Data Science、TensorFlow、PyTorch、Sparkなどの共通のフレームワークとパッケージを含む、幅広いファーストパーティのイメージが提供されています。これらのイメージを使用することで、データサイエンティストはフレームワークとインスタンスタイプを選ぶだけでMLを簡単に始められます。 SageMakerオープンソースディストリビューションをStudioで使用するために、Studioの「 bring your own image 」機能を使用できます。SageMakerドメインにオープンソースディストリビューションを追加するには、以下の手順を完了してください: ターミナルで次のコマンドを実行して、オープンソースディストリビューションをアカウントの Amazon Elastic Container Registry(Amazon ECR) リポジトリに追加します: # Use the latest-cpu or latest-gpu tag based on your requirements export ECR_GALLERY_IMAGE_ID='sagemaker-distribution:latest-cpu' export SAGEMAKER_IMAGE_NAME='sagemaker-distribution' export SAGEMAKER_STUDIO_DOMAIN_ID='d-xxxx' export SAGEMAKER_STUDIO_IAM_ROLE_ARN='&lt;studio-default-execution-role-arn&gt;' docker pull public.ecr.aws/sagemaker/$ECR_GALLERY_IMAGE_ID export ECR_PRIVATE_REPOSITORY_NAME='sm-distribution' export ECR_IMAGE_TAG='sagemaker-distribution-cpu' export AWS_ACCOUNT_ID='0123456789' export AWS_ECR_REPOSITORY_REGION='us-east-1' # create repository aws --region ${AWS_ECR_REPOSITORY_REGION} ecr create-repository --repository-name $ECR_PRIVATE_REPOSITORY_NAME aws --region ${AWS_ECR_REPOSITORY_REGION} ecr get-login-password | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_ECR_REPOSITORY_REGION}.amazonaws.com export ECR_IMAGE_URI=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_ECR_REPOSITORY_REGION.amazonaws.com/$ECR_PRIVATE_REPOSITORY_NAME:$ECR_IMAGE_TAG # Tag docker tag public.ecr.aws/sagemaker/$ECR_GALLERY_IMAGE_ID $ECR_IMAGE_URI # Push the image to your private repository docker push $ECR_IMAGE_URI SageMakerイメージを作成し、そのイメージをStudioドメインにアタッチします。 # Create a SageMaker image aws sagemaker create-image \ --image-name $SAGEMAKER_IMAGE_NAME \ --role-arn $SAGEMAKER_STUDIO_IAM_ROLE_ARN # Create a SageMaker Image Version. aws sagemaker create-image-version \ --image-name $SAGEMAKER_IMAGE_NAME \ --base-image $ECR_IMAGE_URI # Optionally, describe the image version to ensure it's succesfully created aws sagemaker describe-image-version \ --image-name $SAGEMAKER_IMAGE_NAME \ --version-number 1 # Create the app image configuration file cat &gt; /tmp/app-config.json &lt;&lt; EOF { "AppImageConfigName": "app-image-config-$SAGEMAKER_IMAGE_NAME", "KernelGatewayImageConfig": { "FileSystemConfig": { "DefaultGid": 100, "DefaultUid": 1000, "MountPath": "/home/sagemaker-user" }, "KernelSpecs": [ { "DisplayName": "Python 3 (ipykernel)", "Name": "python3" } ] } } EOF # Create an Amazon SageMaker App Image Config. aws sagemaker create-app-image-config \ --cli-input-json file:///tmp/app-config.json # Create a default user settings file # Update the file with your existing settings if you have additional custom images cat &gt; /tmp/default-user-settings.json &lt;&lt; EOF { "DefaultUserSettings": { "KernelGatewayAppSettings": { "CustomImages": [ { "ImageName": "$SAGEMAKER_IMAGE_NAME", "AppImageConfigName": "app-image-config-$SAGEMAKER_IMAGE_NAME", "ImageVersionNumber": 1 } ] } } } EOF # Update Amazon SageMaker Domain with the new default User Settings. aws sagemaker update-domain \ --domain-id $SAGEMAKER_STUDIO_DOMAIN_ID \ --cli-input-json file:///tmp/default-user-settings.json SageMakerコンソールで、ドメインを選択し、既存のユーザープロファイルを選んでStudioを起動します。 必要に応じて、SageMaker Studioを再起動するには、「 SageMaker Studioのシャットダウンとアップデート 」の手順に従ってください。 ノートブックのダウンロード GitHubリポジトリ からサンプルノートブックをローカルにダウンロードします。 好きなIDEでノートブックを開き、ノートブックの最初に torchsummary をインストールするセルを追加します。 torchsummary パッケージはディストリビューションの一部ではないため、このパッケージをノートブックにインストールすることで、ノートブックが終端まで実行されることが保証されます。環境と依存関係を管理するために conda または micromamba を使用することをおすすめします。以下のセルをノートブックに追加して、ノートブックを保存してください。 %pip install torchsummary ローカルのノートブックで実験する 次のスクリーンショットで示すように、アップロードアイコンを選択して、起動したJupyterLab UIにノートブックをアップロードします。 アップロードが完了したら、 cv-kmnist.ipynb ノートブックを起動します。torch、matplotlib、ipywidgetsなどの依存関係をインストールする必要なく、すぐにセルの実行を開始できます。 前の手順に従っている場合、ローカルのノートパソコンからディストリビューションを使用できることがわかるでしょう。次のステップでは、Studioの機能を活用するために、同じディストリビューションをStudioで使用します。 Studioへの移行(オプション) これからは実験をStudioに移行しましょう。Studioの利点の1つは、基盤となるコンピュートリソースが完全に弾力的であるため、利用可能なリソースを容易に増減でき、作業が中断されることなく変更は自動的にバックグラウンドで行われます。以前のノートブックを大規模なデータセットとコンピュートインスタンスで実行したい場合、Studioに移行できます。 既に起動したStudio UIに移動し、アップロードアイコンを選択してノートブックをアップロードします。 ノートブックを起動した後、イメージとインスタンスタイプを選択するようにプロンプトが表示されます。カーネルランチャーで、イメージとして sagemaker-distribution 、インスタンスとして ml.t3.medium を選択し、 Select をクリックしてください。 今、ローカルの開発環境からStudioのノートブックまで、ノートブックに変更を加えることなく、ノートブックを最初から最後まで実行できます! ノートブックをジョブとしてスケジュールする 実験が完了したら、SageMakerはトレーニングジョブやSageMakerパイプラインなど、ノートブックを本番環境で利用するための複数のオプションを提供しています。その1つは、 SageMakerノートブックジョブ を使用して、ノートブック自体を非対話型のスケジュールされたノートブックジョブとして直接実行することです。例えば、定期的にモデルを再トレーニングしたり、定期的に入力データに対して推論を行い、ステークホルダー向けにレポートを生成します。 Studioから、ノートブックジョブアイコンを選択してノートブックジョブを起動します。ローカルのノートブックジョブ拡張機能をノートパソコンにインストールしている場合は、ノートパソコンから直接ノートブックをスケジュールすることもできます。ノートブックジョブ拡張機能をローカルにセットアップするには、 インストールガイド を参照してください。 ノートブックジョブは自動的にオープンソースディストリビューションのECRイメージURIを使用するため、ノートブックジョブを直接スケジュールすることができます。 Run on schedule を選択し、スケジュール(例: 毎週土曜日)を選択して、 Create を選択します。また、結果をすぐに表示したい場合は、 Run now を選択することもできます。 最初のノートブックジョブが完了したら、Studio UIから Output files の下にある Notebook を選択して、ノートブックの出力を直接表示できます。 追加の考慮事項 公開されているECRイメージをMLワークロードに直接使用することに加えて、オープンソースディストリビューションには以下の利点があります: イメージをビルドするために使用されるDockerfileは、開発者が探索して独自のイメージをビルドすることができるように公開されています。このイメージをベースイメージとして継承し、カスタムライブラリをインストールして再現可能な環境を作成することもできます。 Dockerに慣れていない場合や、JupyterLab環境でConda環境を使用することを好む場合、各バージョンごとに env.out ファイルを提供しています。このファイルの指示に従って、同じ環境を模倣するための独自のConda環境を作成できます。たとえば、CPU環境ファイル cpu.env.out を参照してください。 GPUバージョンのイメージを使用して、ディープラーニングや画像処理などのGPU互換のワークロードを実行できます。 クリーンアップ リソースをクリーンアップするには、以下の手順を実行してください: ノートブックをスケジュールで実行するように設定している場合、ジョブの追加料金を防ぐために、Notebook Job Definitionsタブでスケジュールを一時停止または削除してください。 すべてのStudioアプリをシャットダウンして、コンピュートの追加料金を防ぎましょう。手順については、「 Studioアプリのシャットダウンとアップデート 」を参照してください。 (オプション) 作成したドメインを削除します。 結論 MLライフサイクルのさまざまなステージで再現可能な環境を維持することは、データサイエンティストや開発者にとって最も大きな課題の1つです。SageMakerオープンソースディストリビューションは、最も一般的なMLフレームワークとパッケージの相互互換性のあるバージョンを含むイメージを提供しています。また、このディストリビューションはオープンソースであり、パッケージやビルドプロセスに対する透明性が提供され、カスタマイズが容易になっています。 この記事では、ディストリビューションの使用方法を、ローカル環境やStudio、トレーニングジョブのコンテナとして紹介しました。この機能は現在パブリックベータ版です。ぜひ試してみて、フィードバックや問題点を公開の GitHubリポジトリ で共有してください! 著者について Durga Sury &nbsp;は、Amazon SageMakerサービスチームのMLソリューションアーキテクトです。彼女は機械学習を誰にでも利用可能にすることに情熱を持って取り組んでいます。AWSでの4年間の経験を通じて、エンタープライズ顧客向けにAI/MLプラットフォームの設定を支援してきました。仕事以外では、バイクのライド、ミステリー小説、そして5歳のハスキーとの長い散歩が大好きです。 Ketan Vijayvargiya&nbsp; は、AWSのシニアソフトウェア開発エンジニアです。彼の専門分野は機械学習、分散システム、およびオープンソースです。仕事以外では、ウェブサービスの運用や自然を楽しむことに時間を費やしています。
AWS Application Migration Service ( AWS MGN ) は、 AWS への リホスト 移行のための推奨サービスとして位置付けられて以来、お客様のニーズに応えるべく、驚異的な速さで新機能のリリース、複数の機能強化、継続的なイノベーションが行われてきました。 AWS Application Migration Service (AWS MGN) は、高度に自動化されたリフト&amp;シフト(リホスト)のためのソリューションであり、アプリケーションを AWS に移行する作業を簡略化、迅速化、そして削減します。これにより企業は、互換性の問題、パフォーマンスの低下、長いカットオーバーの期間なしに、多数の物理、仮想、またはクラウドのサーバーを移行できます。AWS MGN はソースサーバーを AWS アカウントにレプリケートします。移行の準備が整うと、サーバーを自動的に変換して AWS 上で起動するので、クラウドのコスト削減、生産性、耐障害性、俊敏性をすぐに活用できます。アプリケーションを AWS で起動できれば、その後は AWS のサービスと機能を活用してそれらのアプリケーションをリプラットフォームやリファクタリングすることができます。つまり、リホストはモダナイゼーションへの近道となります。AWS MGN は AWS のすべてのお客様とパートナーが利用できます。 ワークロードを AWS クラウドに正常に移行する際には、これらのワークロードがセキュリティとコンプライアンスのベストプラクティス/フレームワークを満たしていることを確認することも重要です。 そのため、組織にとって、脆弱性が顕在化する前に、アプリケーションの保守とパッチを予定どおりに実施することが重要です。 過去 2 年間に何らかのデータ侵害を経験した組織は 48% と推定されています。 侵害の被害者の 60% は、パッチが適用されていない既知の脆弱性が原因で侵害されたと答えています。 企業はパッチ管理に関して大きな課題に直面しています。ITとセキュリティの専門家はパッチが複雑で時間がかかると感じています。ビジネスユニットのリーダーは、リリース後すぐにパッチを適用するとアプリケーションの機能が損なわれてしまうことを恐れることがよくあります。さらに、これらの脆弱性の修正は、移行または変革の過程にあるワークロードで行う必要があります。 この記事では、AWS MGN のウェーブと、起動後のアクションを使用して AWS への移行中にインスタンスへのパッチ適用を自動化することで、これらの課題にどのように対処できるかを見ていきます。 準備 このチュートリアルでは、次の前提条件を満たす必要があります。 ・ AWS アカウント をお持ちであること ・利用するサービスに対する十分な権限を持つ IAMユーザー が利用できること ・「チュートリアル – 使用サービス」のセクションに記載されているサービスの操作経験(*)。 * AWSアカウントをご用意いただき、 Migration Immersion Day ワークショップ を実施いただくことがお勧めです。日本語の説明で、手順を順々に理解いただけるようになっています。 チュートリアル AWS MGN と AWS Systems Manager を使用してクラウドジャーニーを始めましょう。 読むのに掛かる時間 15 分 コスト 移行するソースサーバーごとに、AWS MGN を 2,160 時間 (継続して使用すると 90 日間) 無料で使用できます。この記事に記載されているその他のサービスでは Amazon EC2、Amazon EBS、AWS Systems Manager を使用しているため、請求が発生する可能性があります。料金の詳細については、サービス製品ページをご覧ください。 学習レベル 300 – 上級 使用サービス AWS MGN, AWS Systems Manager, Amazon EC2, Amazon EBS ソリューション概要 AWS MGNの機能である ウェーブ を使い、ソースサーバーとアプリケーションをグループ化することでユーザーが移行を管理できるようにします。このウェーブを利用することで、移行ステータス、進捗状況、ウェーブに含めたアプリケーションを監視できますし、一括操作を実行することもできます。 また、AWS MGN の機能である 起動後アクション を使い、任意の AWS Systems Manager ドキュメント を実行して、カスタムの最新化アクションを適用してアプリケーションを最適化することができます。起動後アクションを使うと、クロスリージョンDR構成や、CentOSの変換、SUSE Linuxのサブスクリプションの変換といった組み込みアクションを選択することもできます。 AWS Systems Manager パッチマネージャー は AWS Systems Manager の機能で、セキュリティ関連やその他種類のアップデートについて、管理対象ノードにパッチを適用するプロセスを自動化します。パッチマネージャーを使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用できます。 図 1 – ソリューションのアーキテクチャ図 1. AWS MGN の起動後アクションで AWS Systems Manager オートメーションを呼び出してインスタンスにパッチを適用 2. アプリケーションとインスタンスのパッチコンプライアンスを検証 3. カットオーバーを完了し、移行作業を完了する 1) AWS MGN の起動後アクションを作成する 起動後アクションの設定 により、サーバーが AWS で起動された後に実行されるアクションを制御と自動化を行えます。これらのアクションは、起動後テンプレートに基づいて自動的に実行されます。このセクションでは、カスタムアクションを定義し、それを実行するように AWS MGN を設定します。独自の移行プロジェクトでは、必要に応じてさまざまなアクションを実行することができます。 起動後のアクションの設定には 2 つのオプションがあり、起動後テンプレートで新しいアクションを定義することも、サーバーレベルで起動後設定を構成することもできます。起動後テンプレートを設定すると、変更 (新しいアクションを含む) は変更後に追加されたサーバーにのみ適用され、既存のサーバーには適用されません。また、サーバーレベルで設定を行う場合は、ソースサーバーごとにアクションを手動で設定する必要があります。 サーバーにエージェントをインストールする前に、アカウントレベルの起動後テンプレートで新しいアクションを定義することをお勧めします。テンプレートを設定したら、ソースサーバーにエージェントをインストールしてレプリケーションを開始します。これにより、すべてのソースサーバーがアカウントレベルのテンプレートのデフォルト設定を継承します。 1. 左側のナビゲーションメニューから[起動後テンプレート]を選択します。 2. [編集]をクリックします。 3. [Systems Manager エージェントをインストールし、起動したサーバーでのアクションの実行を許可する]のトグルボタンをオンにします。 これにより、AWS MGN は移行ウェーブに属するサーバーに AWS Systems Manager&nbsp;エージェント を自動的にインストールできます。 図 2 – 起動後テンプレートの設定 4. 起動させるインスタンスで実行したいアクションを追加します。 これを実現するために、Systems Manager オートメーション ランブックを使用して新しいアクションを作成します。このアクションにより、該当するパッチベースラインが適用されます。処理途中で障害が発生した場合は、ルートボリュームは自動的にソースサーバーの状態にロールバックされます。 アクションに名前を付け、オートメーション ランブック AWS-PatchInstanceWithRollback を選択します。このアクションを有効化するには、チェックボックスをチェックをしてください。[順序]フィールドに数値を入力して、その他の一緒に実行するカスタムアクションや定義済みアクションとの順序を設定します。 図 3 – 起動させるインスタンスで実行するアクションの追加 2) サーバーのグループを定義し、それらをアプリケーションに関連付ける 起動したインスタンスで実行されるアクションを定義したので、次は、同時に起動させるインスタンスのグループを定義します。 AWS MGN では、ソースサーバーをアプリケーションにグループ化し、アプリケーションをウェーブにグループ化する機能があります。 アプリケーションとは、ビジネスニーズを満たすために連携して機能するサーバーのグループです。サーバーは連携して動作し、ネットワークを共有し、機能を正しく動作させるために必要であるため、サーバー間には依存関係があります。たとえば、データベース、いくつかの Web サーバー、そして計算を実行するバックエンドサーバーがある大規模なアプリケーションです。アプリケーションを本番環境で完全に機能させるには、これらのサーバーをすべてまとめて移行する必要があります。 ウェーブは、指定された期間内にまとめて移行できるように設計されたアプリケーションのグループです。これは移行プロジェクト計画の一環として決定されます。移行中のさまざまなアプリケーション間に必ずしも依存関係があるわけではありません。グループ分けはお客様の移行ニーズに基づいて行われます。移行プロセスから学び、改善するために、優先度の低いアプリケーションをすべてグループ化し、優先度の高いアプリケーションを別のウェーブにまとめても構いません。あるいは、特定のビジネスユニット (マーケティングなど) のすべてのアプリケーションを 1 つのウェーブにグループ化してから、営業アプリケーションなどの次のウェーブに移るといったこともできます。ビジネスニーズに基づいて、移行ウェーブを計画し、アプリケーションをウェーブに割り当てる方法を選択できます。 AWS MGN では、アプリケーションとウェーブのどちらについても、移行プロセスを集約してモニタリングできるほか、アプリケーションやウェーブに含まれるすべてのリソースに対して一括アクションを実行できます。 1. 左側のナビゲーションメニューから [アプリケーション] を選択します。 2. アプリケーションにサーバーを追加します。 図 4 – アプリケーションへのサーバーの追加 3) アプリケーションをウェーブに追加する 図 5 – ウェーブへのアプリケーションの追加 ウェーブを作成してすべてのアプリケーションを追加したら、 テストインスタンスを起動する 準備が整いました。 カットオーバー を開始する前に、ソースサーバーの AWS への移行をテストすることが重要です。 4) 移行インスタンスを起動し、移行ジョブを監視する テストインスタンスを起動 をクリックし、テストインスタンスを起動したら、移行ダッシュボードをモニタリングします。最も重要な点は、 ステップ 1 で設定した起動後のアクションが正常にトリガーされたことを確認することです。 図 6 – 起動後アクションの実行の確認 上記の例では、起動後アクションが開始され、Wave1 を構成するすべてのインスタンスにパッチを適用する AWS Systems Manager オートメーションが正常に終了しました。これで、アプリケーションの機能を検証し、すべてが期待どおりに動作していることを確認する準備ができました。 5) インスタンスのコンプライアンス状態の検証 1. AWS Systems Manager &gt; パッチマネージャー に移動します。 2. コンプライアンスレポート のタブで、ウェーブに追加したサーバーが準拠状態になっていることを確認できるはずです。 図 7 – サーバーのコンプライアンス状態の確認 コンプライアンスは AWS Systems Managerの機能であり、パッチマネージャーでパッチ適用状況に関するデータを収集して報告します。パッチコンプライアンスの詳細については、 設定コンプライアンスの使用 を参照してください。 パッチベースラインにより、パッチマネージャーを使用する際に、ご使用の環境でどのパッチが承認または却下されるかをより細かく制御できます。これらの定義済みベースラインは、現在設定されているとおりに使用することも、独自のパッチベースラインを設定することもできます。詳細については、 事前定義されたパッチベースラインおよびカスタムパッチベースラインについて を参照してください。 6) カットオーバーインスタンスを起動して移行を完了する すべてのソースサーバーとアプリケーションのテストが完了したら、①カットオーバーインスタンスの起動と、②カットオーバーの完了を行う準備が整います。カットオーバーは、設定した日時に実行する必要があります。カットオーバーにより、ソースサーバーは、パッチがすでにインストールされていてインスタンスが準拠状態にある AWS 上のカットオーバーインスタンスに移行されます。 図 8 – カットオーバーインスタンスの起動と完了 まとめ 多くの企業にて、アプリケーションのセキュリティとコンプライアンスを強化する方法を模索されている中、パッチ管理は複雑で時間がかかり、複数の利害関係者の事前検証と事後の検証が必要とします。移行を完了すると同時にコンプライアンスを確保するためのメンテナンス期間が限られているため、これらの課題はさらに大きくなります。 この記事では、AWS MGN の起動後アクションと AWS Systems Manager パッチマネージャー/オートメーションを利用することで、移行の期間を活用したパッチの適用を自動化し、ワークロードを順守し続ける方法について記載しました。 翻訳はソリューションアーキテクト 小宮山 裕樹 が担当しました。原文は こちらです。