Penta Security は、 AWS のデータ暗号化パートナー であり、 27年間の顧客のサイバーセキュリティを担当した企業で、データセキュリティ、ウェブセキュリティ、認証セキュリティの領域で安全なクラウド環境を提供しています。 韓国のデータセキュリティ市場で 15 年間シェア 1 位を守り続けている D’Amo は、グローバル CC 認証および韓国国家情報院の認証を受けた暗号化モジュールを通じて、顧客の重要データを安全に保護し、国内外のプライバシー関連コンプライアンスをすべて遵守しています。 D’Amo は、強力なデータ暗号化技術に基づき、次の機能を提供します。 顧客のビジネス環境に最適化された全システムレイヤーでの暗号化サービスを提供 韓国国家情報院認証の暗号化モジュールを使用した安全な暗号化アルゴリズムの提供 カラム単位の暗号化と DB アクセス制御機能の提供 クラウド環境専用の鍵管理システム D’Amo KMS を用いた暗号鍵、外部鍵、Oracle TDE 鍵など、企業全体の暗号鍵管理 統合された集中管理システム D’Amo Control Center によるインフラ内の暗号化製品とサーバー管理のサポート Amazon RDS Custom での D’Amo による暗号化・復号環境の構築 Amazon RDS Custom は Oracle と Microsoft SQL Server エンジンをサポートしています。 Amazon RDS Custom は、Amazon RDS が提供しているスナップショットやバックアップ、リカバリ機能、パッチ適用サポート、データベースのモニタリング、ログ管理など多くの管理機能を提供します。さらに、SYSDBA および OS レベルのアクセスが可能なため、これまでの Amazon RDS では対応できなかった暗号化ソリューションの導入や、パッケージアプリケーション（例えば、ERP、MES、SCM、HRなど）のデータベースとしても利用できます。 また、Amazon RDS for Oracle がサポートしていない Oracle 12c などのバージョンも利用でき、Oracle RMAN や Data Guard、DB Vault、Flashback といった機能やサードパーティ製ソリューションもインストールして使用することが可能です。 通常の Amazon RDS インスタンスでは OS および SYSDBA へのアクセスができないため、商用データベースセキュリティソリューションの構築が難しい状況でした。しかし、Amazon RDS Custom インスタンスであれば、OS と SYSDBA へのアクセスが可能なため、D’Amo を利用して安全な暗号化・復号環境を構築することができます。 図1 – DB 暗号化ソリューションの観点からの Amazon RDS とAmazon RDS カスタムアーキテクチャの比較 Penta Security は、Amazon RDS Custom インスタンス上で D’Amo が正常に動作することを確認するため、以下の項目について検証を行いました。 D’Amo テスト環境 OS: Oracle Linux DBMS: Oracle Database 19c、12c (64 bit) D’Amo 機能検証リスト 主な検証機能 暗号化ポリシーの管理機能：管理ツールで設定した暗号化ポリシーの正常動作確認 VTI (View/Trigger Interface) モードでカラムの暗号化・復号：管理ツールによるVTI暗号化作業の正常動作確認 API モードでカラムの暗号化・復号：管理ツールによる API 暗号化作業の正常動作確認 図 2 – 暗号化ポリシー管理、VTI 及び API 暗号化・複合の正常動作結果画面 カラムアクセス制御：管理ツールで設定した対象カラムへのアクセス許可・遮断が正常に動作することの確認 ポリシーアクセス制御：管理ツールで設定した対象ポリシーへのアクセス許可・遮断が正常に動作することの確認 暗号化・復号権限制御：管理ツールで設定した権限による暗号化・復号の許可・遮断が正常に動作することの確認 図3 – 暗号化・復号の権限、カラムおよびポリシーへのアクセス制御の正常動作結果画面 追加の動作確認 DB キー管理、カラムインデックスの設定、ストレージ設定などの DBMS 管理機能の正常動作確認 Penta Security は、Amazon RDS Custom 環境で 79 の検証項目が正常に動作することを確認し、D’Amo の Amazon RDS Custom 環境での正式サポートを発表しました。 Amazon RDS Custom での D’Amo の暗号化タイプ D’Amo は、Amazon RDS Custom インスタンスを使用しているお客様向けに、D’Amo DA と DP の両製品を提供しており、企業環境に最適な暗号化方式を選択できます。 D’Amo DA（DBMS Application 暗号化）：D’Amo DA は、DBMS の内部に暗号化・復号 API をインストールして暗号化を行う製品で、DB サーバーの負荷を最小限に抑えて運用できる点が特徴です。また、暗号化対象のテーブル名やカラム名を変更せずに暗号化環境を構築できます。 D’Amo DP（DBMS Pakage 暗号化）：D’Amo DP は、DBMS に暗号化パッケージをインストールして暗号化を行う製品でカラム単位の暗号化、アクセス制御、権限制御など多様な管理機能を提供します。アプリケーションと独立した暗号化方式として動作するため、クエリやコードの変更を最小限に抑えて構築することが可能です。 D’Amo を構築するお客様のための多様なサポート特典 D’Amo は、オンプレミス環境で暗号化を適用していたお客様が Amazon RDS Custom に切り替える際に、既存の RDB 構造を維持します。また、検証済みの暗号モジュールを通じて、アプリケーションを変更せずにお客様のビジネス環境に合わせた暗号化を提供します。なお、Amazon RDS Custom でサポートされている Oracle や Microsoft SQL Server のすべてのバージョンに 100％ 対応しています。 さらに、Penta Security は AWS の公式 ISV パートナーとして、D’Amo を活用するお客様に向けて、さまざまな特典を提供しています。 AWS PoC サポート：既存のインフラストラクチャから AWS への移行や、クラウド環境に不慣れなお客様に対し、カウンセリングおよび技術サポートを提供します。 AWS クレジットの提供：D’Amo のインストールや内部テストのための AWS クレジットを提供することでコスト負担を軽減し、企業のデータベース環境に最適な暗号化ソリューションを構築できます。 トレーニングサポート：クラウドおよびデータ暗号化担当者のデジタルスキル向上のための個別トレーニングをサポートします。 今後、Penta Security は AWS と継続的に協力し、Amazon RDS Custom サービスに合わせたさまざまな機能や特典を拡充していきます。PoC サポート、クレジット提供、トレーニングサポートの詳細については、AWS の担当営業チームまたは Penta Security 営業チーム（cloudbiz@pentasecurity.com）までお問い合わせください。 サマリー 既存のオンプレミス（レガシー）環境やカスタム環境の制約により Amazon RDS の利用が難しかったお客様は、Amazon RDS Custom を活用することで、Amazon RDS の便利な管理機能を利用できます。 Amazon RDS Custom 環境で信頼性が証明されている Penta Security の D’Amo は、企業の重要な情報を安全に保護し、国内外のプライバシーに関するコンプライアンス要件をすべて満たすことができます。 Penta Security の D’Amo を導入する際には、AWS の公式 PoC サポートやテスト用クレジットの提供、トレーニングサポートなど、さまざまな支援を受けることが可能です。 D’Amo の詳細については、 Penta Security の Web サイト を参照してください。 翻訳はソリューションアーキテクト鄭宇鎭（ジョン ウジン）が担当しました。原文は こちら です。

2024年11月1日に、「コンテナ/サーバーレスによるモダン・プロジェクト実践」と題して 3社にご講演いただきました。 コンテナやサーバーレスを利用することで、従来とは異なるランニングコストの構造に移行し、迅速な対応・変更で利用者/お客様のニーズに迅速に対応できるようになります。それを実際にプロジェクトで実践されているお客様のそのままの声をお伝えし、選択のポイントや勘所を理解する機会として、特に従来型の慣れた手法からまだ抜け出せない方・組織の後押しとなるヒントとなるべく、本セミナーは企画されました。 今回は 3社 それぞれ異なる領域のシステムでの経験談をご紹介いただきました。 貴重な実体験をご紹介いただいたのは以下のお客様です。 保険Web申込サービスの顧客体験価値向上のため、4週間ごとの改善リリースを実現 はなさく生命保険株式会社様 Step Functionsで決裁を回そう -内製ワークフロー・チケットシステムの紹介- クックパッド株式会社様 SQSを用いたクレジットカード決済の非同期化 株式会社ZOZO様 各セッションの内容について 保険Web申込サービスの顧客体験価値向上のため、4週間ごとの改善リリースを実現 はなさく生命保険株式会社 / CS戦略部 課長　渡邉 佑亮 様 はなさく生命保険様からは、Web申込サービスのローンチ（2021/09）に際して、どのような思考、優先度でプロジェクトが発足したのか、どのような体制で進められたのかが紹介されました。不確実な新規ビジネスに対し、SIパートナー（開発ベンダー）との共創型のアジャイル開発体制をとることで変化対応力を確保したこと、「当たり前に動く」ことが前提の金融サービスを安定的に支える仕組みとして選択されたアーキテクチャや技術方式についてのご説明がありました。IT システムの開発・運用を開発パートナー企業とともに実施されている企業は日本には多く存在します。モダンな開発スタイルへのチャレンジには、技術的な観点だけではなく、開発パートナー企業とどのように座組みすると良いのかという観点において、参考になる内容が含まれていたように感じました。また、視聴者から、サーバーレス型による運用のため、費用の変動による予算とのブレをどうお考えかという質問がありましたが、そもそも新規のプロジェクトであり、どのくらいアクセスがあるかは不透明だったので、厳密な予算管理を行うことが困難だった。サービスローンチ後は月次でシステム稼働状況と費用の確認を行っているが、オンプレ運用費用との比較においても適性水準であると判断しているとのコメントがありました。これは、サーバーレス型ではよく聞かれる質問の一つですが、実際のお客様の判断が伺えたのは良い機会でした。 資料は こちら です。 Step Functionsで決裁を回そう -内製ワークフロー・チケットシステムの紹介- クックパッド株式会社 / Software Engineer　Shota Nagasaki 様 Head of Corporate Engineering and Security　Sorah Fukumori 様 クックパッド様からは、AWSサーバーレスおよびコンテナサービスをフレームワークとして利用したカスタムの決裁ワークフローのシステム（Fryegg）を構築・展開し、元々お持ちのワークフローシステムから移行された事例をご紹介いただきました。ここでキーとなるAWSサービスが Step Functions です。条件分岐などはもちろん、上長の承認を待つ待機処理や何かシステム上の問題で処理が途中でエラーになってしまった際の再開処理など、ワークフローに求められる機能の大部分が Step Functions の近年の機能アップデートでカバーされ、それが後押しになったとのこと。日本企業の決裁や承認処理は特殊で、多くの場合、企業ごとにカスタマイズが必要、とよく言われますが、複数のシステムや組織をまたがるワークフローをサーバーレス型で実装できれば、ランニングコストの改善への影響は大きいです。しかし、主要メンバー2名で、4ヶ月でやり切るのはすごい。 資料は こちら です。将来的には、この Fryegg をOSSとして公開するビジョンもあるとのことで、個人的にも期待したいです! SQSを用いたクレジットカード決済の非同期化 株式会社ZOZO / EC基盤開発本部 SRE部 カート決済SREブロック　金田 卓巳 様 EC基盤開発本部 カート決済部 カート決済基盤ブロック　林 友貴 様 ZOZOTOWN の、特にセールスキャンペーン時の終了時間直前の決済処理のスパイクに対し、将来のサービス成長を考慮してどう対処すべきなのか、それに対する現時点での対応策がご紹介されました。最終的に SQS を挟んだ非同期型の連携構成までの具体的な検討のポイント・思考フローでは、決済処理という重要機能に対する判断と利用者の利便性を両立させようとする考慮が見えました。負荷の高い部分の処理における非同期アーキテクチャの効果を技術的には理解できても、特に決済に関する処理となると心理的になかなか踏み込みにくいものです。しかし、ZOZOTOWNという日本でも有数のサービスのカード決済部分で実現し、効果があるという話は大きな説得力があります。また、その負荷テストのために使用した EKS上のシステムの紹介も、負荷テストにおけるコンテナ活用の良い一例となりました。 資料は こちら です。なお、負荷テストとしてEKS上で稼働させたツールは こちら であるのことでした。 まとめ 顧客フロントのサイトやカード決済のような業務でも、コンテナやサーバーレス型のサービスを使うことはもう珍しいことではありません。運用の工数を省力化し、その分、機能拡張や改善リリースのサイクルを回す方に力を注ぐことができます。一方、モダンなアーキテクチャの活用の前に、まだ既存の従来型システムが足枷になって、という方が多いのも事実です。全部を一気には変えられませんし、全てを変える必要があるかどうかも疑問です。せめて、新しいプロジェクトでモダンな方式で進めてみて、その体験を実感してから今後の方針を決めるのでも十分良いスタートです。実際、先人の企業の多くは、こうしたアプローチをとった結果、その領域を拡大して今に至っているのです。一歩を進み始めないとその先はありません。 なお、コンテナやサーバーレスをあらためて理解したい方には、自習型の以下のワークショップがあります。ご自分のペースで進めながら来たる次のプロジェクトに備えてはいかがでしょうか。 ECS、EKS を学びたい ECS Workshop Introduction to EKS ひとまずコンテナ化してみる! App2Container サーバーレスをこれから始めるなら… サーバーレス自己学習ガイド サーバーレスの勉強方法を聞いてみた サーバーレス/クラウドネイティブ系 実践力を鍛えるBootcamp – クラウドネイティブ編 サーバーレス事業開発 杉

本ブログは 2024 年 11 月 11 日に公開されたBlog “ Maximize your cloud security experience at AWS re:Invent 2024: A comprehensive guide to security sessions ” を翻訳したものです。 AWS re:Invent 2024 は、12 月 2 日から 6 日までラスベガスで開催され、最新のセキュリティイノベーションを学びたいセキュリティの専門家、クラウドアーキテクト、コンプライアンスリーダーにとって有益なセッションが満載です。今年のイベントでは、ゼロトラスト、生成 AI を活用したセキュリティ、アイデンティティとアクセス管理 (IAM)、DevSecOps、ネットワークとインフラストラクチャセキュリティ、データ保護、脅威検出とインシデント対応のベストプラクティスに焦点を当てています。このイベントは、クラウドセキュリティの専門家にとって、貴重な学習とネットワーキングの機会をご提供します。 re:Invent 2024 の豊富なセッションを効果的に活用し、学習効果を最大限に高めるため、 必見のセキュリティセッション のリストを厳選しました。ぜひ 今すぐご登録 いただき、ラスベガスでお会いしましょう！ 基調講演とイノベーショントーク AWS re:Invent 2024 の 基調講演 と イノベーショントーク は、AWS のシニアリーダーから直接、革新的な洞察を得る機会となります。これらのセッションでは、生成 AI、クラウドセキュリティ、そしてアプリケーション開発と AWS クラウドの未来に新たな方向性を示す革新的なアーキテクチャにおける最新のブレークスルーを深く掘り下げます。 KEY002 – CEO Keynote with Matt Garman (Matt Garman による CEO 基調講演) 。基幹サービスの刷新から新しい体験の創造まで、AWS がクラウド全体でどのようにイノベーションを起こし、お客様とパートナーが安全で豊かな未来を構築できるようにしているかをご覧ください。 SEC203-INT – Security insights and innovation from AWS with Chris Betz (Chris Betz による AWS のセキュリティに関する洞察とイノベーション) 。 AWS の CISO である Chris Betz が、セキュリティを統合・自動化し、チームが重要な取り組みに集中できるようにする変革的な戦略を明らかにする中で、革新的なセキュリティ技術と生成 AI が、組織のセキュアなイノベーションの加速をどのように支援するかをご覧ください。 イノベーショントーク の全リストをご確認ください。今年、現地に参加されない方も、基調講演とイノベーショントークはライブ配信でご視聴いただけます。 セッション セッションタイトルのリンクを選択するとセッション情報と時間場所を確認できます。セッションを予約し、AWS re:Invent のお客様のアジェンダにセッションの追加もできます。 高度なアクセス分析による最小権限の実現の加速 攻撃対象範囲を最小限に抑え、ゼロトラストアーキテクチャを実現するために、アイデンティティ管理とアクセス制御のベストプラクティスを学びます。 (訳者注: チョークトーク（Chalk talk）は、少人数の参加者を対象とした 1 時間の双方向性の高いセッションです。特定のトピックを深く掘り下げ、AWS のエキスパートと直接対話し、その場で質問できることもあります。) SEC325 | チョークトーク | A least privilege journey made easier by IAM Access Analyzer (IAM Access Analyzer による最小権限への容易な移行) : 集中管理をしているセキュリティチームと IAM ポリシー作成者が、 IAM Access Analyzer を使用して、未使用や過剰な権限を可視化し、実用的な推奨事項を活用してスケーラブルな最小権限を実現する方法を学びます。 SEC337 | チョークトーク | Scaling IAM: advanced administration and delegation patterns (IAM のスケーリング: 高度な管理と委任パターン) : 組織の拡大に伴うセキュリティと俊敏性のバランスを取りながら、効果的なアクセス管理のための革新的な戦略をご覧ください。実際のシナリオ、ベストプラクティス、最先端のテクニックから、スケーラビリティ、パフォーマンス、将来の成長のための IAM インフラストラクチャの最適化方法を学びます。 SEC202 | ビルダーズセッション | API Authorization with Amazon Cognito and Verified Permissions (Amazon Cognito と Verified Permissions による API 認可) : このセッションでは、AWS 上のマイクロサービスベースのアーキテクチャにおけるモダンな認可について実践的な経験を得られます。 Amazon Cognito による認証の外部化とカスタマイズ、 Amazon Verified Permissions を使用したポリシーベースのアクセス制御による詳細な認可の適用、 Amazon API Gateway で保護された API との統合方法を学びます。参加にはラップトップの持参が必要です。 SEC334 | チョークトーク | Building zero trust architectures with AWS practical guidance (AWS による実践的なゼロトラストアーキテクチャの構築ガイダンス) : このチョークトークでは、AWS サービスを使用したゼロトラストネットワークアーキテクチャの構築について詳しく説明します。ゼロトラストの観点から、ユーザーからアプリケーション、アプリケーション間、その他のアクセスシナリオをセキュアにする方法を学びます。 SEC232 | ブレイクアウトセッション | Secure by design: Enhancing the posture of root with central control (セキュアバイデザイン: 中央管理によるルートのセキュリティポスチャの強化) : このセッションでは、集中管理とガバナンスを維持しながら、AWS 環境全体でルートアクセスを安全に管理する方法を説明します。さらに、多要素認証 (MFA) を実施し、業界の取り組みと連携し、環境を安全に保つための AWS が提供する最新のツールと取り組みについて説明します。 脅威検出とインシデント対応によるセキュリティポスチャの強化 AWS のセキュリティサービスを使用して、セキュリティリスクを継続的に特定し優先順位付けすることで、セキュリティポスチャを強化し、セキュリティ運用を効率化できます。 (訳者注: コードトーク（code talk）は、ソリューションの構築に使用される実際のコードを詳しく見ていき、参加者がアプローチの「理由」を理解し、エラーも含めた開発プロセスを観察できます。参加者は質問をしたり、実際に手を動かしながら学んだりすることが推奨され、より深い実践的な学習体験を得ることができます。) SEC321 | ブレイクアウトセッション | Innovations in AWS detection and response (AWS の検出と対応におけるイノベーション) : このセッションでは、脅威の検出、ワークロードとデータの保護、自動化された継続的な脆弱性管理、一元化されたモニタリング、継続的なクラウドセキュリティポスチャ管理、統合されたセキュリティデータ管理、調査と対応、生成 AI などの実践的なユースケースに焦点を当てます。AWS の検出および対応サービスをシームレスに統合して、ワークロードを大規模に保護し、セキュリティポスチャを強化し、AWS 環境全体でセキュリティ運用を効率化する方法について、より深く理解することができます。 SEC332 | チョークトーク | Anatomy of a ransomware event targeting data within AWS (AWS 上のデータを標的としたランサムウェアイベントの分析) : このチョークトークでは、AWS 上のお客様環境のデータを標的としたランサムウェアイベントの検出、対応、復旧について解説します。環境内のランサムウェアイベントから保護するために使用できる AWS のサービスと機能、およびランサムウェアイベントが発生した場合の調査方法について、より深い理解を得ることができます。 SEC301 | ワークショップ | Threat detection and response using AWS security services (AWS セキュリティサービスを使用した脅威検出と対応) : このワークショップでは、さまざまなリソースと動作にわたる複数のセキュリティイベントをシミュレートします。提供されたサンドボックス環境で、シミュレートされたイベントから得られた検出結果を確認し、対応する実践的な体験ができます。参加にはラップトップの持参が必要です。 SEC219 | ブレイクアウトセッション | Uncovering sophisticated cloud threats with Amazon GuardDuty (Amazon GuardDuty による高度なクラウドの脅威の発見) : Amazon GuardDuty が AWS 環境全体にわたるエンドツーエンドの可視性を提供する、フルマネージド型の脅威検出を実現する方法について学びます。GuardDuty の独自の検出機能は、クラウドの脅威状況に対する AWS の可視性に基づいており、対応者がより迅速に問題に対処し、修復までの平均時間 (MTTR) を最小限に抑え、セキュリティリソースを最適化するのに役立ちます。これにより、チームはセキュリティリスクへの対応に追われる時間を減らし、より多くの時間をイノベーションに費やすことができます。 SEC343 | チョークトーク | Identify a prioritization strategy for security response & remediation (セキュリティ対応と修復のための優先順位付け戦略の見極め) : このチョークトークでは、アカウントのセキュリティ検出結果への対応と修復を自動化するためのフレームワークについて学びます。 AWS Security Hub を基盤として、どの検出結果を自動修復できるか、自動修復アプローチの影響、そして迅速かつ徹底的な対応を実現する方法について検討します。 SEC401 | コードトーク | Inspect and secure your application with generative AI (生成 AI を使用したアプリケーションの検査とセキュリティ確保) : 生成 AI を使用してアプリケーションのセキュリティを向上させる方法を詳しく見ていきます。AI を活用したツールがセキュリティ問題を迅速に特定し、修復を推奨する方法について学びます。 Amazon Inspector がアプリケーションのソフトウェアとコードの脆弱性を検出する方法について学び、統合開発環境 (IDE) で生成 AI を使用してセキュリティ上の問題をスキャンし修復する方法をご確認ください。 新たな脅威に対するエッジの保護 AWS エッジセキュリティサービスを使用して、アプリケーションに対する分散型サービス妨害 (DDoS) 攻撃や脆弱性攻撃から保護し、より一貫性のあるセキュリティポスチャを実現します。 SEC322 | ブレイクアウトセッション | Reduce your risk exposure with least privilege egress controls (最小権限のアウトバウンド通信制御によるリスクの低減) : このセッションでは、アウトバウンド通信制御戦略を最小権限の原則に合わせる方法を学びます。 AWS Network Firewall 、 Amazon Route 53 Resolver DNS Firewall 、その他のセキュリティサービスの最新リリースが、様々なリスクを低減するのにどのように役立つかを学びます。実装を簡素化し、ユースケースに特化したルールの推奨事項を紹介します。セキュリティポリシーが意図したニーズを満たしているという確信を得ることができます。 SEC344 | チョークトーク | Lessons learned from DDoS mitigation (DDoS 対処から学んだ教訓) : AWS Shield Response Team (AWS SRT) の重大インシデントからの洞察：このチョークトークでは、過去の DDoS イベントを掘り下げ、AWS SRT がセキュリティインシデントをどのように対処したかを解説します。この種の侵入に関する洞察を得て、アプリケーションをより DDoS 耐性の高いものにするための緩和戦略を学びます。 SEC327 | チョークトーク | Building secure network designs for generative AI applications (生成 AI アプリケーションのためのセキュアなネットワーク設計戦略の構築) : このチョークトークでは、AWS 上で生成 AI アプリケーションをセキュアに加速し、問題をより迅速に保護、検出、対応するための階層化されたネットワークセキュリティ制御の構築方法を学びます。多層的な防御のネットワーク設計目標を達成するための主要な考慮事項、ベストプラクティス、リファレンスアーキテクチャをご確認ください。 SEC304 | ワークショップ | Mitigate zero-day events and ransomware risks with VPC egress controls (VPC アウトバウンド制御によるゼロデイイベントとランサムウェアリスクの軽減) : このネットワークセキュリティワークショップでは、ソフトウェアサプライチェーンの依存関係、ゼロデイイベント、暗号通貨マイニング、ランサムウェアからのリスクを軽減するための AWS アウトバウンド制御のベストプラクティスの実装方法を学びます。参加にはラップトップの持参が必要です。 SEC317 | ブレイクアウトセッション | How Amazon threat intelligence helps protect your infrastructure (Amazon が脅威インテリジェンスをお客様のインフラストラクチャ保護に役立ててる方法) : AWS の脅威インテリジェンス機能を理解し、 AWS WAF 、AWS Network Firewall、Amazon Route 53 Resolver DNS Firewall などのセキュリティサービスにおいて、マネージドファイアウォールルールとセキュリティ検出結果をどのように強化しているかを学びます。AWS が AWS インフラストラクチャの保護し、新しいセキュリティ機能を開発し、お客様の AWS 上のアプリケーション保護の強化に使用している脅威インテリジェンスについて学びます。 生成 AI 時代における機密データの保護 最新の AI テクノロジーを実装する際に、データの機密性とプライバシーを保護するのに役立つ高度なテクニックと AWS サービスをご紹介します。 SEC323 | ブレイクアウトセッション | The AWS approach to secure generative AI (生成 AI に対する AWS のセキュリティアプローチ) : このセッションでは、AWS が生成 AI スタックの 3 つのレイヤー (インフラストラクチャのボトム層、モデルやツールへのアクセスを提供するミドル層、大規模言語モデル (LLM) やその他の基盤モデル (FM) を活用して作業を効率化するアプリケーションを含むトップ層) にわたるセキュリティをどのように考えているかについて学びます。 SEC310 | ワークショップ | Persona-based access to data for generative AI applications (生成 AI アプリケーションにおけるユーザーの役割に基づいたデータアクセス) : このワークショップでは、組織内の様々なユーザーロールに合わせて調整されたチャットボットアプリケーションによるドキュメントアクセスを管理します。アクセス権限を職務に合わせることで、セキュアな情報配信に関する課題に対処し、効率性とコンプライアンスを向上させる方法を学びます。参加にはラップトップの持参が必要です。 SEC336 | チョークトーク | Security and compliance considerations using Amazon Q Business (Amazon Q Business を使用する際のセキュリティとコンプライアンスの考慮事項) : このチョークトークでは、 Amazon Q Business アプリケーションのセキュリティ確保のためのベストプラクティスについて、アクセスコントロール、データ保護、コンプライアンスの考慮事項を含めて説明します。 生成 AI に焦点を当てたセッションについては、 こちらのブログ もご覧ください。 セキュリティを重視するカルチャーで開発者を支援する DevSecOps の実践にセキュリティをシームレスに統合し、市場への投入時間を短縮してリスクを軽減します。 SEC216 | ブレイクアウトセッション | Build trust in your CI/CD pipeline (CI/CD パイプラインにおける信頼の構築) : スケーラブルなコンテナセキュリティのコード化: このセッションでは、スケーラブルなコンテナのセキュリティとコンプライアンスを自動化する方法を学びます。 Amazon Q Developer 、Amazon Inspector、 Amazon Elastic Compute Cloud (Amazon EC2) Image Builder がどのように連携して、セキュアなコンテナイメージの作成とその Amazon Elastic Container Registry (Amazon ECR) への保存を自動化するのかを探ります。セキュリティを損なうことなく、開発者をサポートし、迅速な開発を可能にする方法を習得することができます。 SEC217 | ブレイクアウトセッション | Building a resilient and effective culture of security (レジリエントで効果的なセキュリティのカルチャーの醸成) : このセッションでは、リーダーシップからのサポート獲得、セキュリティオーナーシップの共有、心理的安全性の定着による信頼、透明性、そしてプロアクティブなセキュリティファーストのマインドセットの構築など、レジリエントで力強いセキュリティのカルチャーの醸成についてのガイダンスを提供します。 SEC218 | ブレイクアウトセッション | Emotionally intelligent security leadership to drive business impact (ビジネスインパクトを生み出す感情知性を備えたセキュリティリーダーシップ) : リーダーシップを向上させ、セキュリティニーズと戦略的なビジネス成果を一致させ、インパクトのある変革を先導し、持続可能なセキュリティのカルチャーを醸成する方法を学びます。AWS とお客様がどのように共感を持ってセキュリティをリードし、セキュリティの目的を結果に変換し、イノベーションを促進し、ポジティブなエスカレーションカルチャーを改善するための関係を育むかについての内部からの視点をご紹介します。的確なリーダーシップを発揮し、セキュリティ目標を意味のあるビジネスインパクトに結びつける技術を習得し、セキュリティが成功とレジリエンスの触媒となる未来へ組織を導く力を身につけることができます。 SEC314 | コードトーク | Accelerate your DevOps pipeline and remain secure with policy as code (policy as code で DevOps パイプラインを加速させながらセキュリティを維持) : このコードトークでは、オープンソースの汎用 policy as code 評価ツールである AWS CloudFormation Guard を使用して、AWS インフラストラクチャのコンプライアンスルールを定義し評価する方法を学びます。既存のデプロイメントパイプラインに自動化されたポリシー検証をシームレスに統合し、DevOps エンジニアが CI/CD パイプラインにポリシー評価ステップを組み込めるようにする方法を学びます。セキュリティ評価者は、堅牢なセキュリティポスチャを維持しながら、合理化されたレビュープロセスを体験できます。 SEC302 | ブレイクアウトセッション | Better together: Protecting data through culture and technology (より良い協力関係: カルチャーとテクノロジーを通じたデータ保護) : このセッションでは、AWS で利用可能なデータ保護機能の全範囲と、ベストプラクティスとカルチャーがこれらの機能を補完してセキュリティ成果を向上させる方法について考察します。組織がすべてのレイヤーにセキュリティを一貫して組み込むことで、データを保護しセキュリティのカルチャーを強化する方法について、多層防御の観点から詳しく学ぶことができます。 Expo の概要 クラウドセキュリティについて AWS のエキスパートと直接話したいですか？ Expo 会場 のセキュリティアクティベーションエリアで、AWS のセキュリティエキスパートと 1 対 1 で会話できるこの機会をお見逃しなく。組織のセキュリティポスチャを強化するお手伝いをします。 以下のような主要なセキュリティ領域について詳しく説明します 検出と対応: 大規模なワークロードを保護するために、セキュリティリスクの検出と対応のテクニックを探ります。 ネットワークとインフラストラクチャのセキュリティ: AWS サービスを使用して、安全なグローバルネットワークを構築および管理する方法を学びます。 アプリケーションセキュリティ: セキュアなソフトウェアを提供し、アプリケーションセキュリティの課題に対処するための戦略を探ります。 アイデンティティとアクセス管理: 最新のクラウドネイティブなアイデンティティソリューションを採用し、最小権限のアクセス制御を適用します。 デジタル主権とデータ保護: データの制御を維持し、AWS クラウドでデータをセキュアに保護し管理する方法を選択できます。 楽しみはまだまだこれから！ 革新的な洞察と深い学習に満ちた刺激的な 1 週間の後、世界的に有名な re:Play パーティー にご参加ください。これは re:Invent のフィナーレを飾るパーティーです！ヘッドライナーアーティストによるライブエンターテイメント、絶品の料理、たっぷりの飲み物に囲まれながら、リラックスし、交流を深め、無限の可能性に満ちた未来に乾杯しましょう。 今すぐ登録 re:Invent 2024 は素晴らしいイベントになることは間違いありません。みなさまにお会いできることを楽しみにしています！ 今すぐ登録 して、参加枠を確保してください。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Apurva More Apurva は AWS セキュリティ、ID、およびコンプライアンスチームのメンバーで、スタートアップから大企業まで、グローバルなプロダクトマーケティングで 13 年の経験を持っています。市場ポジショニング、競合分析、顧客インサイトのエキスパートとして知られ、ターゲット層に響き収益成長を促進する製品を立ち上げてきました。また、製品ビジョンと市場ニーズ、ビジネス目標を連携させるため、部門を超えた協力を行っています。 Justin Criswell Justin は AWS のセキュリティソリューションアーキテクチャのシニアマネージャーです。クラウドセキュリティとカスタマーサクセスを専門とする 12 年を含む、20 年にわたる技術 expertise を持っています。企業の AWS ユーザーがセキュリティサービスを導入・運用し、可視性を高め、リスクを低減し、AWS クラウドでのセキュリティポスチャを強化するために、スペシャリストチームを率いています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

この記事は、“ Orchestrating Clinical Generative AI Workflows Using AWS Step Functions ” を翻訳したものです。 医療分野の急速な進化に伴い、生成 AI を活用することで、患者ケアを革新し、臨床プロセスを合理化する可能性があります。しかし、HIPAA などの規制に準拠しながら、データのセキュリティを確保しつつ、これらの複雑なワークフローを調整することは難しい課題です。一般的なパターンは、ソースデータから始め、生成 AI モデルを選択し、プロンプトを使用して各データレコードに対して特定のタスクを実行することです。このブログ記事では、 AWS Step Functions と他の AWS サービスを組み合わせて、セキュアで拡張性と柔軟性に優れた、臨床生成 AI ワークフローのオーケストレーションソリューションを構築する方法を探ります。 ユースケース例 図 1: アーキテクチャ図 この設計を実証するため、私たちは AWS HealthLake 、 Amazon Bedrock などの生成 AI サービス、および他の AWS コンポーネントを組み合わせて、臨床ノートを要約するヘルスケア特化ソリューションを構築しました。簡単なデプロイと管理のために AWS Cloud Development Kit (CDK) を使用して構築されたこのソリューションは、 GenAIWorkflow と呼ばれる AWS Step Functions ステートマシンによってオーケストレーションされています。以下で、このワークフローの各ステップを確認しましょう。 図 2. GenAIWorkflow ステートマシン まず、 AWS Systems Manager Parameter Store からクエリパラメータを取得します。パラメータには、処理するレコード ID のリストを取得する Amazon Athena クエリと、AWS HealthLake データストアの詳細が含まれます。 Amazon Athena の StartQueryExecution を呼び出して、Athena クエリを実行します。 Amazon Athena の GetQueryResults は、クエリの結果であるレコード ID のリストを取得します。クエリと結果セットによっては、最大数の結果が返されます。追加の結果がある場合は、 NextToken が返され、すべてのレコードを取得するには後続のクエリを実行する必要があることを示します。 分散モードのマップステート は、返されたレコード ID のリストを反復処理し、同時に処理します。デフォルトでは、Step Functions は同時実行数 10 を使用します。 各レコード ID について、Amazon Athena の StartQueryExecution API を呼び出してクエリの実行を開始します。 このステップでは、クエリの結果 (レコード ID に関連付けられたレポートのコンテンツ) を取得します。 Choice State を使用して、このステップでは、処理ロジックを続行する前に結果が返されたかどうかを判断します。 これは、 AWS Lambda 関数を使用して、Athena クエリの結果に必要な書式設定を行うオプションのステップです (例: 複数の列の値を 1 つの値に結合する、またはクエリ結果から JSON レコードを作成する)。 Parameter Store から、特定のタスクのプロンプトテンプレートを取得します。このプロンプトは、ユースケースに合わせてカスタマイズし、呼び出すモデルに最適化する必要があります。 このステップでは、プロンプトテンプレートとレポートコンテンツを組み合わせてプロンプトを作成し、Amazon Bedrock API を呼び出します。ここでは、さまざまな種類の Amazon Bedrock API 呼び出しの例外をキャッチして再試行するメカニズムを設定できます。 別の Lambda 関数を呼び出して、Amazon Bedrock API レスポンスを解析し、出力データを Amazon DynamoDB テーブルに保存できる形式に変換します。 PutItem API を使用して、構造化された出力データを DynamoDB テーブルに保存します。 結果が返されない場合は、反復処理をスキップします。 Choice state を使用して、 NextToken 値の有無を判断します。 NextToken が存在する場合は、Amazon Athena の GetQueryResults API を NextToken とともに再度呼び出して、次のバッチの結果を取得します。 処理するレコードがなくなると、ワークフローが成功します。 メリット AWS Step Functions を使用して生成 AI ワークフローを調整することには、いくつかの利点があります。Step Functions の中核は、さまざまな AWS サービスとシームレスに統合されるビジュアルワークフロー調整ツールであり、複雑な臨床生成 AI ワークフローを管理するのに最適です。このソリューションではセキュリティが最重要で、特に Step Functions が最近 カスタマーマネージドキーのサポート を発表したことで、独自の暗号化キーを使用してワークフロー定義と実行データを暗号化できるようになりました。この強化されたセキュリティは、 AWS KMS Customer Managed Keys (CMKs) を通じて保護された医療情報 (PHI) の堅牢な取り扱いと、遷移中と処理中の両方でコンポーネント全体にわたる包括的な暗号化にも及びます。このアーキテクチャは、Amazon Athena、AWS Lambda、Amazon DynamoDB などのサービスを通じて、セキュアなデータ処理とストレージを活用しています。また、このソリューションは非常に拡張性が高く、SQL クエリと生成 AI プロンプトを AWS Systems Manager Parameter Store のパラメータとして格納しているため、コード変更なしに変更が可能です。さらに、Lambda 関数を更新して、生成 AI ステップの前後にユースケース固有のロジックを組み込むこともできます。 このソリューションは、運用の信頼性とパフォーマンスにも優れています。Step Functions には、組み込みのエラー処理と再試行メカニズムがあり、自動再試行や適切な障害処理を通じてワークフローの回復力を確保します。また、 redrive 機能を使用して、失敗したステップから実行を再開することができます。以下のスクリーンショットは、Step Functions のビジュアルエディタと、堅牢なエラー処理機能を示しています。このアーキテクチャでは、Lambda や Athena などのサーバーレステクノロジーを活用しているため、ワークロードに基づいて自動的にスケーリングされ、必要なリソースのみを消費することで、パフォーマンスとコスト効率の両方を最適化できます。最後に、Step Functions には包括的な監視とログ機能が組み込まれているため、ワークフローの進行状況を追跡し、プロセスの各ステップでの入出力データを検査することができます。 図 3. Step Functions のエラー処理 次のステップ AWS Step Functions やその他の AWS サービスを活用することで、臨床現場での生成 AI ワークフローを実現するための、セキュリティ、拡張性、スケーラビリティに優れたソリューションを構築できます。これにより、医療機関は生成 AI の可能性を最大限に活用しながら、データ保護とコンプライアンスの最高水準を確保できます。 このソリューション を検討し、ご自身の要件に合わせてカスタマイズし、患者ケアと臨床プロセスに新たな可能性を切り開いてください。私たちはコミュニティとの協力を重視しており、 プルリクエスト を送ってソリューションの機能強化に貢献したり、 GitHub の Issue で問題を報告したり、コメント欄で経験や提案を共有したりすることを歓迎します。皆様のフィードバックと参加により、このソリューションを改善し、医療コミュニティのニーズにより良く応えられるよう努めていきます。 Qing Liu Qing Liu はAWSのシニアソリューションアーキテクトです。彼はヘルスケアIT業界で10年以上の経験を持っています。彼はヘルスケアデータを活用してより良い洞察を得て患者の治療成績を改善することに情熱を注いでいます。余暇には、妻や友人とテニスをするのが好きです。 Nick Ragusa Nick Ragusa はAWS教育チームのプリンシパルソリューションアーキテクトで、教育機関や大学病院がクラウド技術を活用して学習体験と患者の治療成績の両方を変革するのを支援しています。クラウドソリューションの設計をしていない時は、3人の子供たちのスポーツイベントで観客席から声援を送ったり、さわやかな秋の朝のランニングで思索しながら長距離を走ったり、あるいは慎重に選んだデザートで甘い物好きの自身を満足させたりしています。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

このブログは、2024 年 11 月 14 日に AWS Cloud Operations Blog で公開された “ Operations re:Imagined – Know Before You Go – AWS re:Invent 2024 ” を翻訳したものです。 12 月 2 日から 12 月 6 日にかけて毎年恒例のクラウドコンピューティングカンファレンス、 AWS re:Invent 2024 がラスベガスで開催されます。このカンファレンスでは、刺激的な基調講演に参加し、サービスを深く掘り下げて学び、クラウド利用に熱意のあるユーザー同士で交流する機会が得られます。初心者からエキスパートまで、全ての参加者に合わせたセッションやイベントをご用意しています。 学習するサービスが多数あるため、オペレーションに関するセッションを事前に検討しておくことをおすすめします。AWS でのノードやアプリケーションの管理は複雑になりがちですが、ハイブリッド環境やマルチクラウド環境でも同様です。特に新しい技術が絶えず登場する中で、一元的な運用によりノードやアプリケーションの運用面での洞察を得ることができます。AWS Systems Manager、Amazon CloudWatch、AWS Resource Explorer などのサービスは、AWS とそのお客様の両方に利益をもたらすベストプラクティスを適用するよう設計されています。大量なリソースの管理とタグ付けから、運用データに基づいて改善を促す洞察の提供まで、AWSにおける運用のベストプラクティスを強化する最新機能をご覧いただけます。 AWS re:Invent では、参加者のスキルレベルに合わせて様々な形式のセッションをご用意しています。セッション ID によってレベルが示されています。re:Invent のセッションタイプの詳細は こちら をご覧ください。 このブログでは、AWS クラウド運用をさらに活用するための、AWS re:Invent 2024 の一元的な運用に関するセッションをいくつか紹介します。 筆者のおすすめ マルチアカウント環境の構築に取り組む際、タグポリシーの実装や、アカウントにまたがって展開されたリソースの管理に関する課題に直面することがあります。タグ付けとリソース管理は、クラウド基盤構築の重要な要素ですが、組織にとって適した戦略を考案するのは時間がかかる作業です。そこで、AWS エキスパートが異なるお客様向けに実践してきた様々な戦略について議論するセッションをご紹介します。ここでの洞察が、タグ付けとリソース管理の戦略立案や、既存の取り組みの改善の一助となれば幸いです。 COP351 | Effective multi-account tagging and resource discovery strategies – Chalk Talk 数千ものリソースを複数のアプリケーションや AWS アカウントにまたがって管理する際は、適切なタグ付けとリソース管理の戦略を立案し、実行に移すのは時間がかかり、非常に複雑な作業となります。このセッションでは、未タグ付けのリソースを検出し、アプリケーションごとにリソースを整理する方法、および AWS Organizations を使ったアプリケーションの管理方法について学びます。さらに、リソースとアプリケーションを大規模に管理する方法について、AWS エキスパートに質問する機会も設けられています。 その他の運用管理セッション COP321 | Centralize Multicloud Management using AWS – Breakout Session マルチクラウド環境で運用する場合、オペレーションの複雑さが増す可能性があります。このセッションでは、AWS Systems Manager を使ってインスタンスの管理を簡素化する方法を学びます。Amazon CloudWatch と Amazon Managed Grafana を活用すれば、あらゆるデータソースからのメトリクスとログを単一のダッシュボードで把握できます。これらのサービスを使えば、AWS やオンプレミス、他のクラウドにまたがるワークロードの日々のタスクを簡素化し、コントロールを維持しつつリソースを最適化できます。マルチクラウドの複雑さを解消し、ビジネスに集中できるようサポートします。 COP325 | Operating your fleet of resources at scale is easier than you think! – Breakout Session これまでは、大規模な組織全体にまたがった AWS リソース、マルチクラウド、オンプレミスのリソースを運用するには多数のツールと手動プロセスが必要でした。AWS では自動化によって効率を高め、コストを削減できます。このセッションでは、AWS Systems Manager、Amazon CloudWatch などのサービスを使って、コンピューティングリソースの一括パッチ適用、アプリの展開、インシデントの解決など、さまざまな運用タスクを自動化する方法を学びます。数多くのお客様が、数百万ものリソースを AWS、マルチクラウド、オンプレミス、IoT にわたって管理するのに、これらのサービスを活用しています。今回、それらのサービスがさらに簡単に使えるようになりました。 COP328 | Streamlining application management on AWS – Breakout Session 開発チームとオペレーションチームには、リソースを効率的に管理・監視できる一元的な方法が必要です。このセッションでは、AWS myApplications を使ったアプリケーションの管理と監視のベストプラクティスを考察します。リソースを論理的なアプリケーション単位で整理する方法や、単一のダッシュボードからアプリケーションポートフォリオの可視化、コスト、セキュリティ、パフォーマンスの重要指標の把握、標準化された方法でのアプリケーションの展開と拡張を加速する方法について説明します。 COP337 | All things patching: Manage and monitor at scale – Chalk Talk このセッションでは、AWS Organization に属する EC2、オンプレミス、マルチクラウドのインスタンスの最新のオペレーティングシステムセキュリティパッチを確実に適用する、一元的なパッチ管理アプローチについて学びます。管理アカウントでポリシーを定め、アカウントやアプリケーションのコンプライアンス状況を把握する方法を習得します。さらに、組織全体のインスタンスからどのパッチが不足しているかを素早く特定する方法も学びます。これにより、セキュリティ脆弱性への対応時間を短縮し、組織全体のセキュリティポスチャーを高めることができます。 COP339 | Adopt AWS’s Ops management culture on your team – Chalk Talk AWS は、サービスの信頼性がお客様の重要な要件であることを認識しています。このセッションでは、非中央集権組織において、重要なプロセスであるインシデント管理を Amazon がどのように文化的・技術的な仕組みを用いて効果的に運用しているかについて学びます。重大度判断、優先順位付け、インシデント対応と緩和に使われる当社のメカニズムとツールを掘り下げて説明し、それらを支える Amazon の企業文化についても探ります。日々のオペレーション負荷を軽減し、インシデントの平均解決時間 (MTTR) を短縮するために、Amazon が使っている実践的な手法とツールについて解説します。 COP346 | Centralize audit data for hybrid and multicloud environments – Chalk Talk お客様がクラウドへの移行を加速し、事業変革を遂げる中で、ハイブリッド環境の IT 運用を管理しなければならない状況に直面することがあります。これにお困りではありませんか？このセッションでは、AWS CloudTrail Lake を有効にし、過去の CloudTrail ログをインポートし、パートナー製品との統合、カスタムソリューション、多数の AWS リソースからの監査ログを集約する方法を説明します。また、調査分析とセキュリティ目的でこのデータをクエリする方法についても扱います。 まとめ このブログでは、AWS クラウド運用に関連するいくつかのセッションをご紹介しました。re:Invent の当日は、AWS ビレッジのクラウド運用ブースにお立ち寄りいただき、さらに詳しいお話をお聞きいただければと思います。セッションの詳細は、re:Invent の イベントセッションサイト をご確認ください 筆者について Tiffany Chen Tiffany は、ヘルスケアとライフサイエンス業界を担当する AWS のソリューションアーキテクトです。デプロイメント業務のサポートを行い、現在はエンタープライズ顧客と協力して、Well-Architected にコスト最適化されたソリューションの構築に取り組んでいます。趣味は旅行、園芸、お菓子作り、バスケットボールの観戦です。 Winnie Chen Winnie は AWS のソリューションアーキテクトで、金融サービス業界の新規顧客を支援しています。AWS上でのインフラストラクチャの移行と構築を支援しています。趣味は旅行、ハイキング、自転車、岩登りなどのアウトドア活動です。

この記事は Amazon EKS and Kubernetes sessions at AWS re:Invent 2024 (記事公開日: 2024 年 11 月 16 日) を翻訳したものです。 イントロダクション Amazon Web Services の年次イベントである AWS re:Invent 2024 が近づいています。今年のイベントでは、Kubernetes やその他のクラウドネイティブ技術に焦点を当てたセッションのフルトラックを含みます。広大なセッションカタログを簡単に参照できるよう、Kubernetes とクラウドネイティブ関連トピックのセッションリストを作成しました。 コアトピックごとにまとまっており、re:Invent セッションカタログのセッション詳細へのリンクもあります。 さぁ、参加者ポータルのカタログで、今すぐセッションを予約し始めましょう。 興味のあるセッションの予約席を確保できない場合は、ほとんどのセッションタイプで Walk-up 席が利用できます。 注目すべきセッションの 1 つに、 KUB201: Kubernetes on AWS の未来 があります。ここでは、 AWS の Kubernetes Head of Product である Nathan Taber 氏 と、 Snowflake の Princilal Software Engineer である Hyungtae Kim 氏 が登壇します。このセッションでは、EKS の最新のイノベーションと、Snowflake の次世代 AI/ML プラットフォームの洞察について学ぶことができます。 必ず聞くべきセッションの 1 つに、 CMP215: あらゆるアプリケーションのためのコンピューティング・イノベーション があります。こちらは、 AWS の VP & Distinguished Engineer, Compute & Networking, Amazon EC2 である Anthony Liguori と、 AWS の VP Serverless Compute である Holly Mesrobia によるセッションです。 このセッションでは、AWS のインフラとソリューションに対する革新の取り組みが紹介されます。これによりお客様は、クラウドだけでなくオンプレミスやエッジでもアプリケーションのビルド、実行、スケーリングが可能になります。 是非ご参加いただき、これらの AWS のイノベーションがコンピューティングの世界をどのように変革しているか、内部からの視点をご覧ください。 さまざまなセッション形式の詳細な説明は re:Invent ラーニングフォーマット をご確認ください。 Kubernetes によるプラットフォームの構築 Amazon EKS – Kubernetes とコンテナによって構築されたアプリケーションや開発者プラットフォームの最新のイノベーションを探索しましょう。今年の re:Invent のラインナップには、コンテナ化が初めての方でも、既にあるワークフローを改善したい方であっても、Kubernetes のスキルを向上させるのに最適なセッションが用意されています。 AWS のエキスパートや同じ考えを持つプロフェッショナルと協力して、Kubernetes の管理を簡素化し、あらゆる規模のチームにとっての可能性を解き放つ、最新の戦略を探ってください。 KUB308 | IDP ファストトラック: エンタープライズ DevOps のための CNOE を活用したデプロイレース(ワークショップ) KUB301 | Amazon EKS を用いた、スケーラブルなプラットフォームの構築 (ブレイクアウト) PEX402-R | Amazon Q を用いた AWS におけるモダンなエンジニアリング技術の取り入れ (ワークショップ) KUB102-S | Zesty における最適化されたプラットフォームによる Kubernetes 管理の革新 (ライトニングトーク) KUB402-R | Amazon EKS: Infrastructure as code、GitOps、CI/CD (チョークトーク) KUB306-R | Amazon EKS へのアプリケーションデプロイの簡素化 (ビルダーセッション) KUB307-R | 組織における Kubernetes のスケールの基礎 (ワークショップ) SAS311-R | Amazon EKS でのマルチテナント SaaS アーキテクチャの最適化 (チョークトーク) データ、機械学習、生成 AI これらのセッションに参加して、AWS 上のデータ処理、機械学習、Kubernetes が交差する領域を探索してください。これらのセッションは、EKS を分析のためのデータプラットフォームとして活用することから、生成 AI モデルのデプロイとスケーリング、責任ある AI のプラクティスの採用まで、EKS のスケールとパフォーマンスを、データ処理、機械学習、生成 AI と組み合わせるうえでの、貴重な洞察を提供します。 KUB405 | 分析のためのデータプラットフォームとしての Amazon EKS (ブレイクアウト) KUB313 | Amazon EKS 上の MLOps のためのアーキテクチャパターン (チョークトーク) KUB401 | Amazon EKS におけるデータと生成 AI (ワークショップ) KUB314 | Amazon EKS におけるハイパフォーマンスな生成 AI (ブレイクアウト) KUB316 | Amazon EKS への最適化された推論パイプラインのデプロイ (チョークトーク) KUB403 | Amazon EKS における高性能な LLM 推論のスケーリング (チョークトーク) KUB320-R | Amazon EKS でのモダンなデータ処理パイプラインの構築 (チョークトーク) OPN309-R | オープンソースと共に実現する責任ある生成 AI の実践 (チョークトーク) DAT202-S | チャットボットを超えて: AI がリアルタイムにビジネスクリティカルな意思決定をおこなう方法 (ブレイクアウト) STG406-R | Amazon S3 と Amazon EKS での AI/ML ワークロードのオンボーディングと最適化 (ワークショップ) ANT410 | Amazon EMR on EKS でデータパフォーマンスを最大化する (チョークトーク) コスト最適化とパフォーマンス Amazon EKS での Kubernetes 環境における、クラスター効率の最大化、無駄の削減、イノベーションの解放のための最新の戦略を発見するために、ご参加ください。 これらのセッションでは、クラスターを動的にスケーリングする方法、Kubernetes のコストをビジネス価値と整合させる FinOps アプローチを採用する方法、クラウドコスト最適化のベストプラクティスを探索する方法についての知識を身につけることができます。 KUB312 | Amazon EKS と Karpenter による自動化されたクラスターインフラストラクチャー (ブレイクアウト) KUB309-R | Karpenter: Amazon EKS のベストプラクティスとクラウドコストの最適化 (ワークショップ) KUB311-R | Kubernetes を採用する FinOps :ビジネス革新のためのコスト最適化 (チョークトーク) セキュリティ AWS で Kubernetes ワークロードを実行しているお客様にとって、セキュリティは最も重要です。これらのセッションに参加して、Kubernetes のセキュリティの重要な領域を探索し、EKS 環境の保護に役立つ重要なツールとベストプラクティスを理解しましょう。これらのセッションでは、Kubernetes ワークロードの保護を深く掘り下げ、ソフトウェアサプライチェーンを最適化し、セキュリティと可観測性が交差する領域を調査し、Policy as Code で Kubernetes のセキュリティを強化する方法を学ぶことができます。 KUB319 | Amazon ECR を使用したソフトウェアサプライチェーンのセキュリティ強化と最適化 (チョークトーク) KUB315 | Amazon EKS における Kubernetes ワークロードのセキュリティ対策 (ブレイクアウト) KUB305-R | Amazon EKS クラスターのセキュリティ対策と監視 (ビルダーズセッション) KUB302-R | セキュアなコンテナ環境の戦略とベストプラクティス (チョークトーク) OPN306-R | Kyvernoを使った Policy as Code によるKubernetes セキュリティ強化 (チョークトーク) ストレージ Amazon EKS 上のコンテナ化アプリケーションのストレージを効果的に管理および最適化する方法を知ることができます。 ステートフルワークロード向けに AWS ストレージサービスを活用する方法と、コンテナ化アプリケーションのデプロイにおけるベストプラクティスを探求します。 KUB324 | AWS のストレージサービスを活用した、Amazon EKS でのステートフルなワークロードの実現 (ライトニングトーク) STG331 | Amazon EBS でのコンテナ化されたアプリケーションのデプロイ (チョークトーク) 運用、デプロイ、可観測生 re:Invent 2024 で、EKS の効率的な運用、堅牢な可観測性、効果的なデプロイ戦略に深く踏み込む包括的なセッションを披露できることを楽しみにしています。参加者の皆様は、生成 AI を活用して EKS 運用を最適化する方法、可観測性のベストプラクティス、Kubernetes とサーバーレスコンピューティングが交差する領域、Kubernetes API を介したインフラストラクチャの管理の最新動向を探索する機会が得られます。手を動かしたい方向けに「Amazon EKS フリート管理への Dive Deep」ワークショップでは、Kubernetes 環境の効果的な管理とスケーリングの実践的な体験を提供します。 KUB321 | 生成 AI で Amazon EKS の運用を効率化する(コードトーク) KUB323 | Amazon EKS ワークロードにおける可観測性戦略 (ライトニングトーク) KUB101-S | Amazon EKS ワークロードにおける可観測性のデータコストと複雑さの制御 (ライトニングトーク) KUB303-R | Amazon EKS フリート管理への Dive Deep (ワークショップ) KUB203-S | プロダクトカルチャーの再構築: Smarsh による AWS でのスケーリングと移行 (ライトニングトーク) KUB202-S | 生成 AI のスケーリング: Kubernetes での運用課題の対処 (ブレイクアウト) KUB304-R | Cloud-native Java on AWS (ビルダーズセッション) API308 | Kubernetes が出会う Serverless: Kubernetes API で EDA をデプロイする (ブレイクアウト) OPN312 | Infrastructure as Kubernetes API (ブレイクアウト) OPN202 | AWS Controllers for Kubernetes による API 経由のインフラストラクチャ管理 (ライトニングトーク) SAS404 | Kubernetes DevOps ツールを活用した SaaS プロビジョニングとデプロイの自動化 (ワークショップ) スケーラビリティ、レジリエンシー、接続性 AWS に Kubernetes をデプロイするにあたって、アプリケーションのスケーラビリティ、レジリエンス、接続性を確保する必要があります。最新の戦略とイノベーションを探索し、本番グレードのアーキテクチャ構築、クラスターパフォーマンスの最適化、機械学習ワークフローの効率化の方法を学びましょう。 ネットワーク戦略やサービスメッシュから、コスト効果の高い ML トレーニングやエッジデプロイまで、 AWS 上での Kubernetes のポテンシャルを最大限に引き出すためのベストプラクティスとツールについて深掘りします。 KUB404 | Amazon EKS での本番グレードのレジリエンスアーキテクチャの構築 (ブレイクアウト) KUB406 | Kubernetes のネットワーク戦略 (ブレイクアウト) KUB310 | エッジおよびハイブリッドなユースケースのための Amazon EKS (ブレイクアウト) KUB322-R | Amazon EKS で回復力のあるアプリケーションを構築する (チョークトーク) KUB318-R | Karpenter による Kubernetes クラスターのスケール、最適化、アップグレード (チョークトーク) NET315 | Kubernetes のネットワーク戦略 (チョークトーク) OPN307 | Kubernetes の接続性: サービスメッシュから未来へ (チョークトーク) CMP403 | Amazon EKS と AWS Batch を活用したスケーラブルかつコスト効率な MLトレーニング (チョークトーク) AWS Village の Kubernetes kiosk や、Developer Pavilion の Modern Apps と Open Source Zone を訪れるため、 Expo Hall にお立ち寄りください。AWS 上でのモダンアプリケーション構築について専門家に質問したり、デモを見たり、オープンソースチームと会ったりできます。 立ち寄って挨拶をして、楽しんで、スナックをつまんで、クレーンゲームから商品をゲットしましょう！ re:Invent に直接参加できない場合も問題ありません！バーチャルパスを 登録 することで、Keynote と Leadership Session のライブ配信に参加できます。 また、ブレイクアウトセッションをお見逃しなく！イベント後に AWS Events YouTube でオンデマンド視聴できます。 これらのセッションや、AWS の専門知識があなたの組織にどのように役立つかについて、さらに詳しく知りたいですか？詳細は AWS アカウントチームにお問い合わせください。 あなたの組織で Kubernetes を最大限に活用する方法の詳細については、 Amazon EKS のウェブページをご覧ください。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

本ブログは “ Upgrade Amazon DocumentDB 4.0 to 5.0 with near-zero downtime ” を翻訳したものです。 Amazon DocumentDB (MongoDB 互換) は、MongoDB ワークロードをサポートする、高速でスケーラブルで可用性の高いフルマネージド型のドキュメントデータベースサービスです。基盤となるインフラストラクチャの管理について心配することなく、同じ MongoDB 3.6、4.0、5.0 アプリケーションコード、ドライバ、およびツールを使用して、Amazon DocumentDB でワークロードを実行、管理、およびスケーリングできます。Amazon DocumentDB はドキュメントデータベースであるため、JSON データの格納、クエリ、インデックス作成が行えます。 Amazon DocumentDB バージョン 5.0 のリリースにより、Amazon DocumentDB クラスターのバージョン 3.6 および 4.0 から 5.0 へのメジャーバージョンアップグレードを実行して、 複数の拡張機能 を活用できるようになりました。Amazon DocumentDB 5.0 は、ベクター検索、ドキュメント圧縮、I/O 最適化ストレージ、インデックス構築ステータスによる高速インデックス作成、クライアント側 Field Level Encryption (FLE) などをサポートしています。 この投稿では、 メジャーバージョンのインプレースアップグレード 、 Amazon DocumentDB ボリュームクローニング 、 AWS Database Migration Service (AWS DMS) を使用して、Amazon DocumentDB 4.0 から 5.0 へのダウンタイムをほとんど発生させずにアップグレードする方法を記載します。 既存のアップグレードオプション 現在、Amazon DocumentDB 4.0 のユーザーは、以下の方法を使用して Amazon DocumentDB 5.0 へのメジャーバージョンアップグレードを実行できます。 mongodump と mongorestore — mongodump や mongorestore などのコマンドラインユーティリティを使用して Amazon DocumentDB データベースのバイナリバックアップを作成し、それらを新しい Amazon DocumentDB 5.0 クラスターに復元できます。この方法では、アップグレード中に Amazon DocumentDB クラスターがオフラインになるため、ダウンタイムに耐えられるワークロードに最適です。 AWS DMS — AWS DMS を使用して、既存のクラスターから新しい Amazon DocumentDB 5.0 クラスターにデータを移行することができます。AWS DMS はマネージド型サービスで、サポートされているソースやターゲット間で既存のデータを移行するために使用できます。この方法では、追加の DocumentDB I/O 料金と AWS DMS の使用料が発生します。詳細については、「 AWS データベース移行サービスを使用した Amazon DocumentDB クラスターのアップグレード 」を参照してください。 インプレース メジャーバージョン アップグレード — この機能を使用すると、データの移行やエンドポイントを変更したりする必要なく、Amazon DocumentDB クラスターのインプレースアップグレードを実行できますが、ダウンタイムが必要となり、ダウンタイムの長さはコレクション、データベース、コレクション、インデックスの数によって異なります。詳細については、 インプレース メジャーバージョン アップグレードのドキュメント を参照してください。 ソリューション概要 この記事では、メジャーバージョンのインプレースアップグレード、ボリュームクローニング、AWS DMS を使用して、ダウンタイムをほとんど発生させずにメジャーバージョンアップグレードを実行するハイブリッドアプローチについて説明します。このアプローチでは、クラスターデータ全体を新しいエンドポイントに移行する際に通常かかる I/O コストとアップグレードに要する時間を最小限に抑えることもできます。この手法は下記の流れで実施します。 Amazon DocumentDB クラスターで変更ストリームを有効にする Amazon DocumentDB クラスターのクローンを作成します クローンしたクラスターでインプレースメジャーバージョンアップグレードを実行します AWS DMS を使用して Amazon DocumentDB クラスターからクローンクラスターに変更データキャプチャ (CDC) を複製します レプリケーションが終了したら、アプリケーションエンドポイントをクローンクラスターに変更します アップグレード後のクリーンアップを実行します 前提条件 さらに進めるには、AWS DMS、 インプレースメジャーバージョンアップグレード 、および ボリュームクローニング について高いレベルで理解している必要があります。このソリューションを利用すると、Amazon DocumentDB 変更ストリーム、AWS DMS レプリケーションインスタンス、その他のリソースに関連して、アカウントで発生するコストを最小限に抑えることができます。 AWS Pricing Calculator ツールを使用すると、設定に基づいてコストを見積もることができます。 Amazon DocumentDB クラスターをより高いバージョンにアップグレードする場合は、廃止された機能や演算子、または使用方法の変更がないか確認してください。アプリケーションを新しいバージョンに対して実行し、アプリケーションに意図的な変更がない限り、動作とパフォーマンスが以前のバージョンと同じであることを確認します。 エンドポイントの切り替え時に、ある程度のダウンタイムが発生することに注意してください。実稼働環境で試す前に、検証環境でこのアプローチを複数回ドライランすることを強くお勧めします。 Amazon DocumentDB クラスターで変更ストリームを有効にする Amazon DocumentDB クラスターのメジャーバージョンアップグレードを最小限のダウンタイムで実行するには、クラスターで 変更ストリーム を有効にする必要があります。変更ストリームは、Amazon DocumentDB クラスター内で発生する更新イベントを時系列で提供します。 CDC でトランザクション漏れが発生しないように、変更ストリームログの保持期間を設定する必要があります。変更ストリームログのデフォルトの保持期間は 3 時間です。この期間は 1 時間から 7 日の間の任意の値に設定できます。この属性は 24 時間以上に設定することをおすすめします。 次の AWS コマンドラインインターフェイス では、保持期間が 24 時間に延長されます。 aws docdb modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name <parameter group name> \ --parameters "ParameterName=change_stream_log_retention_duration, ParameterValue=86400,ApplyMethod=immediate" Amazon DocumentDB コンソール から変更ストリームを有効にすることもできます。 すべてのデータベースで変更ストリームを有効にするには、Amazon DocumentDB クラスターに接続し、次のコマンドを使用して変更ストリームを有効にします。 db.adminCommand({modifyChangeStreams: 1,database :"",enable: true}); 変更ストリームの作成を確認するには、 $listChangeStreams アグリゲーションパイプラインステージを使用して、クラスターで有効になっているすべての変更ストリームを一覧表示します。詳細については、「 変更ストリームの有効化 」を参照してください。 Amazon DocumentDB クラスターのクローン Amazon DocumentDB のクローニングでは、お使いの Amazon DocumentDB プロダクションクラスターと同じ Amazon DocumentDB クラスターボリュームを使用し、同じデータを持つ新しいクローンクラスターを作成できます。クローンの作成は、スナップショットの復元などの他の手法を使用してデータを物理的にコピーするよりも高速で、スペース効率も高くなります。 Amazon DocumentDB プロダクションクラスターのクローンを作成するには、以下のステップを実行します。 Amazon DocumentDB コンソールのナビゲーションペインで、[クラスター] を選択します。 Amazon DocumentDB プロダクションクラスターを選択し、[アクション] メニューで [クローンの作成] を選択します。 [クラスター識別子] に、クローンされた Amazon DocumentDB クラスターに付ける名前を入力します (たとえば、 cloned-docdb-cluster など)。 [インスタンス]、[構成]、[ネットワーク設定]、[保存時の暗号化]、[ログのエクスポート]、[ポート]、[削除保護] では、Amazon DocumentDB クラスターと同じ設定を選択します。Amazon DocumentDB クラスターとインスタンスの設定の詳細については、Amazon DocumentDB クラスターの管理を参照してください。 [クローンを作成] を選択して、選択した Amazon DocumentDB クラスターのクローンを起動します。クローンが作成されると、他の Amazon DocumentDB クラスターとともに [クラスター] ページに表示され、現在の状態が表示されます。状態が Available になると、クローンは使用できる状態になります。 クラスターページで、クローンクラスターを選択し、構成タブに移動して、クラスターの作成時間をメモします。 クローンされたクラスターでインプレースメジャーバージョンアップグレードを実行する このステップでは、データを移行したりエンドポイントを変更したりせずに、複製された Amazon DocumentDB 4.0 クラスターを 5.0 にアップグレードします。クローンされたクラスターでメジャーバージョンのインプレースアップグレードを実行しても、追加料金は発生しません。 インプレースメジャーバージョンアップグレードを実行する前に、前提条件となるステップをすべて完了していることを確認してください。詳細については、 Amazon DocumentDB インプレースメジャーバージョンアップグレード を参照してください。 Amazon DocumentDB イベントのサブスクライブ の手順に従って、クローンクラスターのメンテナンスイベントをサブスクライブします。次に、以下のステップを実行してクラスターをアップグレードします。 Amazon DocumentDB コンソールのクラスターページでクローンクラスターを選択し、アクションメニューで [変更] を選択します。 [クラスター識別子] に、クラスターの名前を入力します。 [エンジンバージョン] には 5.0.0 を選択します。 VPC セキュリティグループを指定します。 クラスターオプションセクションで、適切なデフォルトまたはカスタムクラスターパラメータグループを選択し、[Continue] を選択します。 「変更のスケジュール設定」セクションで、「すぐに適用」を選択します。 [Modify cluster] を選択して、クラスターのインプレースアップグレードを開始します。これで、クラスターのステータスが Upgrade に変わります。アップグレードが完了すると、クラスターのステータスが Available に戻り、「データベースクラスターのメジャーバージョンがアップグレードされました」というイベントが表示されます。イベントページを監視することで、アップグレードの進行状況を追跡できます。 インプレースメジャーバージョンアップグレードが完了したら、サニティチェックを実行して、アップグレードしたクローンが機能していて、すべてのデータとインデックスが損なわれていないことを確認します。 注:データの不整合が発生する可能性があるため、複製したクラスターのデータを変更しないように注意してください。 AWS DMS を使用して、ソースクラスターからクローンクラスターに CDC をレプリケートする このステップでは、クローンの作成後に行われたすべてのデータベース変更をレプリケートすることで、クローンクラスターを Amazon DocumentDB ソースクラスターと同期させます。AWS DMS レプリケーションインスタンスは、Amazon DocumentDB プロダクションクラスターに接続してデータを読み取り、それをターゲットのクローンクラスターに書き込むことで CDC を実行します。 AWS DMS レプリケーションインスタンスを作成する レプリケーションインスタンスを作成するには、以下のステップを実行します。 AWS DMS コンソールで [レプリケーションインスタンスを作成] を選択します。 名前 ( docdb40todocdb50 など) とオプションの説明を入力します。 インスタンスクラスでは、必要に応じてサイズを選択します。 [エンジンバージョン] で [3.5.1] を選択します。 Amazon VPC の場合は、ソースとターゲットの Amazon DocumentDB クラスターを収容する VPC を選択してください。 [割り当て済みストレージ] には、デフォルトの 50 GiB を使用します。書き込みスループットのワークロードが高い場合は、ワークロードに合わせてこの値を増やしてください。 マルチ AZ では、高可用性とフェイルオーバーサポートが必要な場合は [はい] を選択してください。 パブリックにアクセスできるようにするには、このオプションを有効にします。 [レプリケーションインスタンスを作成] を選択します。 AWS DMS のソースエンドポイントとターゲットエンドポイントの作成 ソースエンドポイントを作成するには、以下のステップを実行します。 AWS DMS コンソールのナビゲーションペインで [Endpoints] を選択します。 [エンドポイントの作成] を選択します。 [エンドポイントタイプ] で [ソース] を選択します。 [エンドポイント識別子] には、覚えやすい名前 ( docdb40-source など) を入力します。 [ソースエンジン] には [Amazon DocumentDB] を選択します。 [サーバー名] には、Amazon DocumentDB プロダクションクラスターの DNS 名を入力します。 ポートには、Amazon DocumentDB プロダクションクラスターのポート番号を入力します。 SSL モードの場合は、[すべてを確認] を選択します。 CA 証明書の場合は、「新しい CA 証明書の追加」を選択し、次の手順を実行します。 新しい CA 証明書をダウンロードして TLS 接続バンドルを作成します。 「証明書の識別子」には、 global-bundle.pem と入力します。 [新しい CA 証明書の追加] で [ファイルを選択] を選択し、ダウンロードした.pem ファイルに移動します。 ファイルを選択して開きます。 [証明書のインポート] を選択し、[証明書の選択] ドロップダウンメニューで global-bundle.pem を選択します。 [ユーザー名] には、ソースクラスターのプライマリユーザー名を入力します。 Password には、ソースクラスターのプライマリパスワードを入力します。 Amazon DocumentDB クラスターのすべてのデータベースから CDC を複製する場合は、[データベース名] を空白のままにします。または、テーブルマッピングを使用して特定のデータベースを指定することもできます。 エンドポイント接続をテストし、接続が機能することを確認します [エンドポイントの作成] を選択します。 2 つ目のエンドポイントを作成し、エンドポイントタイプに Target を選択し、クローンしたクラスターの詳細を指定します。 AWS DMS 移行タスクを作成する AWS DMS タスクはレプリケーションインスタンスをソースインスタンスおよびターゲットインスタンス関連付けます。移行タスクを作成するときは、ソースエンドポイント、ターゲットエンドポイント、レプリケーションインスタンス、および必要な移行設定を指定します。AWS DMS タスクには、「既存のデータを移行する」、「既存のデータを移行して、継続的な変更をレプリケートする」、「データ変更のみをレプリケートする」の 3 つの移行タイプがあります。 クラスター作成の開始までにすべてのデータを含むボリュームクローンを使用してターゲットクラスターを作成した場合は、クラスター作成後にソースで発生した差分変更をコピーするだけでよいので、AWS DMS の「データ変更のみをレプリケートする」移行タイプを使用します。このオプションを使用すると、AWS DMS はソースクラスターの動作を維持したまま、変更内容をクラスターからクローンクラスターにレプリケートします。最終的に、ソースデータベースとターゲットデータベースは同期され、移行のダウンタイムはほぼゼロになります。 次の手順を実行して移行タスクを作成します。 AWS DMS コンソールのナビゲーションペインで [Tasks] を選択します。 [タスクを作成] を選択します。 [タスク識別子] に、名前 ( mvu-cdc-task など) を入力します。 [レプリケーションインスタンス] で、作成したレプリケーションインスタンスを選択します。 [ソースデータベースエンドポイント] で、作成したソースエンドポイントを選択します。 [ターゲットデータベースエンドポイント] で、作成したターゲットエンドポイントを選択します。 [移行タイプ] で [データ変更のみをレプリケート] を選択します。 「タスク設定」セクションで、「ウィザード」を選択し、「カスタム CDC 開始モードを有効にする」を選択します。 開始時間を、先ほど書き留めたクローンクラスターの作成時間の 2 分早く指定してください。 [ターゲットテーブル準備モード] で [何もしない] を選択します。 LOB 列の設定では、デフォルトの最大 LOB サイズ (32) で制限付き LOB モードを選択します。 [CloudWatch ログの有効化] を選択します。 詳細タスク設定はデフォルト設定のままにします。 テーブルマッピングでは、[ウィザード] を選択します。 「選択ルール」で、スキーマには「EnterSchema」、ソース名には「%」、ターゲット名には「%」、「アクション」には「include」を選択します。 [タスクを作成] を選択します。 監視と検証 これで、AWS DMS はソース Amazon DocumentDB クラスターからターゲット Amazon DocumentDB クラスターへの CDC のレプリケーションを開始します。タスクステータスが [開始] から [レプリケーション中] に変わるはずです。AWS DMS コンソールのタスクページで進捗状況をモニタリングできます。変更内容によっては、数分から数時間かかることがあります。DMS タスクに 並列スレッドを追加 することで、CDC のスループットを向上させることができます。 最終的に、ソースとターゲットは同期されます。コレクションで count () 操作を実行してすべての変更イベントが移行されたことを確認することで、両者が同期しているかどうかを確認できます。 Amazon DocumentDB DataDiffer ツール を使用してデータ検証を実行することもできます。 レプリケーションが追いついたら、アプリケーションエンドポイントを 5.0 クラスターに変更 新しい Amazon DocumentDB 5.0 クラスターが同期され、すべてのチェックに合格したことを確認したら。これで、アプリケーションのデータベース接続エンドポイントを Amazon DocumentDB クラスターから Amazon DocumentDB 5.0 クラスターに変更する準備が整いました。 アップグレード後のクリーンアップを実行 以下の手順を実行してリソースをクリーンアップできます。 Amazon DocumentDB クラスターを削除 します。 Amazon DocumentDB 5.0 プロダクションクラスターの変更ストリームを無効にします。 必要に応じて AWS DMS インスタンス、レプリケーションタスク、エンドポイントをすべて削除 します。 Amazon DocumentDB 5.0 クラスターにインスタンスを追加して Amazon DocumentDB プロダクションクラスターに一致させるには、Amazon DocumentDB コンソールのクラスターページでクローンクラスターを選択し、アクションメニューで [インスタンスを追加] を選択します。 Amazon DocumentDB 4.0 クラスターにあったモニタリングとアラートをコピーまたは設定します。 結論 この投稿では、インプレースメジャーバージョンアップグレードと AWS DMS を使用して、Amazon DocumentDB 4.0 から 5.0 にアップグレードする方法と、ダウンタイムをほぼゼロに抑える方法を紹介しました。 Amazon DocumentDB 5.0 は、ベクター検索、ドキュメント圧縮、I/O 最適化ストレージ、インデックス構築ステータスによるインデックス作成の高速化、クライアント側 FLE などをサポートしています。Amazon DocumentDB クラスターのバージョン 3.6 と 4.0 から 5.0 へのメジャーバージョンアップグレードを実行することで、複数の拡張機能を活用できます。詳細については、 ドキュメントを参照 してください。 著者について Kunal Agarwal は、アマゾンウェブサービスのシニアプロダクトマネージャーです。Kunal はデータに情熱を傾け、顧客の問題を解決するスケーラブルな製品を構築することが大好きです。AWS に入社する前、Kunal はテクノロジー業界で製品管理と戦略に 12 年間携わっていました。 Anshu Vajpayee は、アマゾンウェブサービス (AWS) のシニア DocumentDB スペシャリストソリューションアーキテクトです。彼は、お客様が NoSQL データベースを採用し、Amazon DocumentDB を活用したアプリケーションをモダナイズできるよう支援してきました。AWS に入社する前は、リレーショナルデータベースと NoSQL データベースを幅広く扱っていました。 本ブログの翻訳はソリューション アーキテクトの大井が担当しました。

この投稿では、 AWS Network Load Balancer (NLB) の Transmission Control Protocol (TCP) フローのアイドルタイムアウトを設定する手順を説明します。 NLB は Open Systems Interconnection (OSI) モデルのレイヤー 4 で動作する Amazon Web Services (AWS) の Elastic Load Balancing ファミリの一部で、TCP または User Datagram Protocol (UDP) でクライアント接続を管理し、それらをロードバランサーのターゲットに分散します。 NLB は接続の確立から、非アクティブ (アイドルタイムアウト) による閉鎖またはタイムアウトまでを追跡します。 デフォルトでは、TCP 接続のアイドルタイムアウトは 350 秒、UDP 接続のタイムアウトは 120 秒です。 新しく TCP のアイドルタイムアウトが設定可能になったため、既存および新規の NLB TCP リスナーでこの属性を変更できるようになり、NLB が非アクティブな接続を終了するまでの時間を決められるようになりました。 TCP 接続確率の手順の理解 始める前に、TCP プロトコルの動作の概要を説明します。より深く理解するには、 TCP の RFC(RFC 9293) を参照してください。 図 1. TCP 接続確立の段階 TCP 接続には確立、データ転送、正常なクローズなどのいくつかの段階があります。 ハーフオープン : クライアントが SYN を送信し、サーバーが応答しますが、まだクライアントがハンドシェイクを完了していない状態。 接続確立 : 3 ウェイハンドシェイクが完了した状態。 データ転送 : ハンドシェイク後、クライアントとサーバーの間でデータを交換している状態。この図の部分は、読みやすくするために簡略化されています。 クローズ : クライアントが FIN パケットを送信し、正常にクローズされます。 NLB の TCP 接続処理 NLB は、レイヤー 4 プロキシとして動作し、確立された各接続をフローテーブルで追跡します。 ハーフオープン、正常にクローズした接続、またはクライアントまたはサーバーでリセットされた接続は追跡されません。 単一の接続は 5 つの属性の組み合わせ (5 タプル) によって定義され、プロトコル (TCP)、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポートからなります。 図 2. NLB デプロイのサンプルアーキテクチャ デフォルトでは、クライアントとターゲット間でトラフィックがない状態が 350 秒続くと、NLB のフローテーブルからその接続が削除されます。 接続が追跡されなくなった後にクライアントがトラフィックを送信しようとすると、NLB は新しい接続を確立する必要があることを示す TCP RST を返します。 多くのアプリケーションでは、接続がタイムアウトしても問題ありません。 しかし、一部の場合は問題となることがあります。 例えば、定期的にデータを送信する IoT (Internet of Things) デバイスは、それぞれの送信時で少量のデータしか転送しません。 そのたびにデータが送信されるごとに、特に暗号化された接続を再度開くと、リソースを大量に消費し、コストがかかります。 接続がタイムアウトしないように、TCP キープアライブを設定して、確立された接続に対して決められた間隔でプローブ(※1)を送信することができます。このプローブにはデータは含まれていませんが、NLB などの中継システムでのアイドルタイマーをリセットすることができます。TCP キープアライブの設定方法の詳細については、以前の記事” Implementing long-running TCP Connections within VPC networking “を参照してください。 アプリケーションで長期間持続する永続的な TCP 接続が必要で、TCP キープアライブを使用できない場合は、NLB の TCP アイドルタイムアウトを変更できます。 TCP アイドルタイムアウトの更新時の考慮事項 各 NLB TCP リスナーのアイドル タイムアウト値は 60 ～ 6000 秒の範囲内で調整できます。 この変更はすでに進行中の接続には影響せず、新しい TCP 接続にのみ影響します。 その他のリスナの種類 (TLS、UDP など) では、現時点でアイドル タイムアウト値の調整はサポートされていません。 アイドルタイムアウト値を設定する前に、アプリケーションのニーズを理解し、TCP キープアライブが代替手段になり得るかを検討してください。 NLB の TCP アイドルタイムアウトは、アプリケーションの TCP アイドルタイムアウトよりも長く設定するのが適切です。 つまり、NLB ではなく、アプリケーションが接続管理とタイムアウトを処理することになります。 アイドルタイムアウトを高すぎる値に設定すると、フローテーブルがいっぱいになるリスクが高まります。テーブルがいっぱいになると、NLB が新しい接続を暗黙に拒否するようになります。 Amazon CloudWatch の新しいメトリクス (監視セクションで説明) を使って、接続拒否を監視する必要があります。 接続が拒否された場合は、TCP アイドルタイムアウトの値を小さくする必要があります。 TCP アイドルタイムアウトを AWS API/CLI で設定する手順 AWS は TCP アイドルタイムアウト機能を Network Load Balancer に導入するにあたり、新しい API を公開しました。以下の例は API の動作を示しています。 TCP アイドルタイムアウトの現在の値を確認するための、NLB リスナーについて説明します。 入力: aws elbv2 describe-listener-attributes \ --listener-arn arn:aws:elasticloadbalancing:us-east-1:000011112222:listener/network/NLBTest/123/123 出力: { "Attributes": [ { "Value": "350", "Key": "tcp.idle_timeout.seconds" } ] } TCP アイドルタイムアウトの値を変更する 入力: aws elbv2 modify-listener-attributes \ --listener-arn arn:aws:elasticloadbalancing:us-east-1:000011112222:listener/network/NLBTest/123/123 \ --attributes \ Key = tcp.idle_timeout.seconds,Value = 600 出力: { "Attributes": [ { "Value": "600", "Key": "tcp.idle_timeout.seconds" } ] } TCP アイドルタイムアウトを AWS マネジメントコンソールで設定する手順 次の手順では、 AWS マネジメントコンソール でタイムアウト値を変更する方法を示します。 1. NLB の TCP リスナーを見つけます。 図 3. NLB TCP リスナー 2. Attributes セクションで現在の TCP アイドルタイムアウト の値を確認します。 図 4. NLB リスナーの Attributes 3. リスナー属性の編集 セクションで、新しい TCP アイドルタイムアウト 値を入力します。 図 5. アイドルタイムアウトの設定 監視 Network Load Balancer の TCP アイドルタイムアウトの導入により、2 つの新しいメトリクス RejectedFlowCount (フローテーブルがいっぱいで拒否されたフロー数の合計) と RejectedFlowCount_TCP (同じ理由で拒否された TCP フロー数) が追加されました。 これらのメトリクスを使って、アイドルタイムアウト設定の影響を監視できます。 NLB がフローの受け入れを拒否し始めたときにあなたに通知を受け取れるように、 CloudWatch アラーム をセットアップすることをお勧めします。 RejectedFlowCount の増加は、タイムアウトを短縮する必要があることを示していて、より早くフローを削除し、フローテーブルが一杯になるのを防ぐことができます。 既存の NLB メトリクス (NewFlowCount、NewFlowCount_TCP、ActiveFlowCount、ActiveFlowCount_TCP など) は変更されません。 結論 NLB での TCP アイドルタイムアウトを設定すると、長時間接続するアプリケーションなどで特に接続管理をより詳細に制御できます。アイドルタイムアウトを調整し関連するメトリクスを監視することで、NLB のパフォーマンスを最適化し接続の問題を防ぐことができます。 本稿は、2024年9月3日に Networking & Content Delivery で公開された “ Introducing NLB TCP configurable idle timeout ” を翻訳したものです。翻訳は Solutions Architect の長屋が担当しました。

こんにちは。AWS ソリューションアーキテクトの木村です。 みなさん、Rufus（ルーファス）という単語を聞いたことがありますでしょうか？ Rufus（ルーファス）とは、生成 AI を搭載した Amazon の新たな対話型ショッピングアシスタントの名前です。Amazon.co.jp で「登山に必要なものは？」「5歳児と雨の日に遊べるゲーム」「この商品の耐久性はどう？」「電気カミソリの種類を比較して」などの質問に対応することができ、商品を見つけやすくなるようお客様をサポートします。 先日、ベータ版の日本への導入を発表 し、一部のお客様向けにリリースされています。買い物体験が変わると思うとワクワクしますね。ぜひアプリやサイトをチェックしてみてください！ 11 月に入り AWS 公式ウェブマガジン、builders.flash の記事が公開されていますので生成 AI に関係するものをピックアップしてみます。承認・検索・エージェントなど色々なシーンで生成 AI が活用されておりユースケースの参考になりますね。 生成AI(Claude3.5 Sonnet)による次世代型レビュー承認システムの実現 (DMM.com合同会社様) 日本一のポイントモールへとグロースさせるための「生成AIを用いた検索体験向上」チャレンジ (株式会社オズビジョン様) AWS IoTと生成AIを使って自宅の消費電力を測定・予測してみよう AWS Summit Japan 2024 Game Industry Booth の舞台裏 また最近、SNS 等で AWS re:Invent 2024 に関する投稿が増えてきているように感じます。今年も楽しみですね。12 月 6 日(金) の 12:00-13:00 に毎年恒例の「 新サービス・新機能の全てを1時間でサクッとお伝えするWebinar 」を開催しますので、ぜひご参加ください。 「 AWSジャパン生成AI実用化推進プログラム 」のお申し込みも募集しています。11 月 22 日が締め切りになりますので、検討されている方はお早めに意思表明をお願いします。 それでは、11 月 11 日週の生成AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社ペライチ様、Amazon Bedrock を使用したホームページ自動生成サービスを開発 株式会社ペライチ様は、ホームページ作成サービス「ペライチ」を運営しています。ペライチは、誰でも簡単にホームページを作って運用できるように豊富なテンプレートが用意されていますが、イメージをホームページの形に落とし込むのが難しく公開まで至らないユーザーが存在するといった課題がありました。そこで、ユーザーが任意のサイトのURLを入力すると、そのサイトの特徴や用途に応じた情報を生成 AI が抽出し、それに基づいた最適なテンプレートを選択しサンプルのホームページを生成して提案する「ペライチクリエイトアシスタント」を開発しました。入力された URL 情報から WEB ページの情報抽出・説明・要約する処理は、AWS Step Functions と AWS Lambda そしてAmazon Bedrock を活用しています。現在、 無料モニターを受け付けています 。この取り組みは、ペライチ様に AWS ジャパン生成 AI 実用化推進プログラム に参加いただき、企画ワークショップ、 プロトタイピングプログラム による実装支援を AWS から提供しています。 AWS生成AI国内事例ブログ: 株式会社 JPX 総研様、生成 AI を活用したタグ付により適時開示資料・銘柄検索における検索性の向上を実現 JPX 総研様は、JPX グループ等が保有するデータを網羅的にカタログ化するポータルサイト「 JPxData Portal 」の提供を行っています。200 種類を超える幅広いデータを提供する一方で、データの種類が多すぎて探しにくいといった課題を抱えていました。そこで、全ての適時開⽰資料の PDF をAmazon Bedrock に連携し、⽣成 AI ( Claude ) を活⽤してファイル内の文章からタグを生成して、キーワードを付与する取り組みを行いました。その結果、ユーザーは「持続可能性」や「グッドデザイン」といったタグ情報を利用して検索することができるようになり、目的の開示情報を容易に探せるようになりました。また AWS Lake Formation によるアクセス管理を導入したことで、生成されたタグ情報の他システムへの容易な連携や、運用の効率化といったメリットも享受されています。 AWS生成AI国内事例ブログ: IQVIAサービシーズ ジャパン合同会社様、社内 RAG チャットシステムの構築により検索・調査に費やしていた時間を 93 % 削減 IQVIA 様は、ヘルスケアや人々の健康の進展に取り組むお客様を支援するグローバルリーディングカンパニーです。臨床試験などの業務においては、規制等が書かれているドキュメントを都度確認する必要があり、この検索・調査に費やす時間が多大にかかっているという課題がありました。そこで Amazon Bedrock のナレッジベースを用いた RAG ベースの AI チャット問い合わせ対応ソリューションを構築しました。この RAG チャットソリューションを IQVIA 様 全体に導入し、約 2 ヶ月で社内ユーザー 321 人の利用を達成。月あたりの検索・調査に費やしていた時間を 93 % 削減することができたそうです。また、RAG ソリューションの検証と構築は、担当者 １ 名のみで実施し、約 2 ヶ月という短期間で実現されました。フルサーバレスな構成を採用することで、開発・運用コストの最適化も実現されています。 AWS生成AI国内事例ブログ: 株式会社アーベルソフト様、 災害監視用の自社開発モデルの代わりとして Amazon Bedrock を活用することで、 約45 %の精度向上・年間コスト約 260 時間削減を達成 アーベルソフト様は、災害写真情報サービス「 ビューちゃんねる（防災 DX） 」を開発しており、複数の自治体に向けてサービスを提供しています。その中で自社で開発した画像認識モデルを用いて、冠水を自動判定する Web サービスを提供しているのですが、機械学習モデルの作成や精度改善にかかるコストに課題を抱えていました。そこで、Amazon Bedrock 上で利用可能なマルチモーダルモデルである Claude 3.5 Sonnet の導入を行いました。その結果、精度が従来から約 45 %向上、開発・運用コストが年間約 260 時間削減、さらに交通事故や火災などのこれまで行なっていないユースケースに対応することが可能になった、といった効果を得ることができました。削減できたコストはお客様に還元することを検討しており、最終的には約 40 %低減させた価格で提供できる見込みとなっているようです。 ブログ記事「製造業における技能継承への生成 AI・音声・映像の活用とサンプルソースのご紹介」を公開 製造業における技能継承は、日本のモノづくりの競争力を維持する上で非常に重要な課題となっています。本ブログでは、生成 AI や音声・映像技術を活用した技能伝承支援ソリューションを紹介しています。Amazon Bedrock が過去のデータや膨大な資料から効率的に解決策を推測し、Amazon Chime の Chime SDK を利用してベテランエンジニアがリモートから映像や音声を通じて若手を支援するソリューションとなっています。こちらは GitHub にて公開しています。 ブログ記事「Amazon Bedrock 上で基盤モデルのコストと利用状況を追跡できる社内 SaaS サービスを構築する」を公開 この記事では、マルチテナント環境で Amazon Bedrock を使用して基盤モデルにアクセスする社内 SaaS プラットフォームの構築方法について紹介しています。特に、テナントごとの使用量とコストの追跡、およびテナントごとの使用量制限などのコントロールに焦点を当てています。ソリューションは GitHub にて公開しています。社内で生成 AI の管理をされている方は是非ご覧ください。 ブログ記事「AWS Supply Chain と Amazon Q を活用して製造業における運用の優秀性（オペレーショナルエクセレンス）を推進」を公開 製造業の企業は、生産計画や材料管理から可視性やデータ統合に至るまで、サプライチェーン業務全体でさまざまな課題に直面しています。このブログでは、 AWS Supply Chain と Amazon Q を連携させ、サプライチェーンの課題に対する解決策をどのように提供するのかを紹介しています。 ブログ記事「【開催報告 & 資料公開】今から始める！Publisher 向け生成 AI」を公開 2024 年 10 月 10 日に、新聞・出版・メディア業界のお客様向けに、「AWS Media Seminar 2024 – 今から始める！Publisher 向け生成 AI」というテーマでセミナーを開催しました。このブログは、セミナーの開催報告記事です。コネヒト株式会社様からは mamari での生成 AI 活用による検索機能向上、株式会社朝日新聞社様からはコンテンツ制作支援サービス ALOFA における生成 AI 活用について登壇いただいています。資料と動画を公開していますのでぜひご覧ください。 ブログ記事「Amazon Bedrock Guardrails を使用したモデルに依存しない安全対策を実装する」を公開 Amazon Bedrock Guardrails は現在、Amazon Bedrock 外で利用可能な LLM のユーザー入力とモデル応答を評価するための ApplyGuardrail API をサポートしています。この記事では、一般的な生成 AI アーキテクチャで ApplyGuardrail API を使用する方法について紹介しています。 ブログ記事「IoT@Loft #25 進化するIoTカメラソリューション – 生成AIで拓く新時代」を公開 こちらは、2024 年 10 月 30 日に開催された 「IoT@Loft #25 進化する IoT カメラソリューション – 生成 AI で拓く新時代」の開催報告記事です。 AI/IoT ネイティブカメラを扱っているi-PRO 株式会社様の生成AI活用の取り組み、株式会社 USEN 様による店舗 DX をテーマにした IoT×AI カメラソリューションなどが紹介されています。また当日のデモ展示の様子も書かれています。 サービスアップデート Amazon Q Developer で、Datadog および Wiz 向けプラグインが一般提供開始 AWS マネジメントコンソールで Amazon Q とチャットする際、お客様は自然言語を使用して Datadog と Wiz サービスの情報にアクセスできるようになりました。例えば、「@datadog アクティブなアラートはありますか？」や「@wiz 今日のトップ3のセキュリティ問題は何ですか？」といった質問を投げかけることで情報をより速く見つけ、作業の高速化を図ることが可能です。詳細は ブログ を参照ください。 Amazon Q Developer Pro にて、ユーザーアクティビティの閲覧が可能に Amazon Q Developer Pro ティアで、管理者がサブスクリプションユーザーのアクティビティをより詳細に把握できるようになりました。管理者はユーザーの最終アクティビティ情報を閲覧することが可能です。これにより非アクティブなサブスクリプションを簡単に特定できるようになります。また送信メッセージ数や AI が生成したコード行数などが記載されたユーザー別アクティビティレポートも作成できるようになりました。 Amazon Q Developerにて以下の新機能が追加されました ・Java 8/11 から 17 へのコード変換機能がエージェンティックワークフローにより強化されました ・Q Developer が全ての YAML ファイルと JSON ファイルに対してのコード提案をサポートするようになりました ・Ruby、Scala、SQL に対してより長い複数行のインラインコード提案をサポートするようになりました ・Dart、Lua、R、Swift、SystemVerilog、PowerShell、Vue に対してのインラインコード提案をサポートするようになりました AWS B2B Data Interchangeにて生成AIベースのEDIマッピング機能を提供 AWS B2B Data Interchange は、EDI 規格のデータの変換をフルマネージドで行うサービスです。今回、AWS B2B Data Interchange にて生成 AI を使用した EDI マッピングコードを生成する機能が提供されました。この新機能により、双方向の EDI マッピングの作成とテストのプロセスが迅速化され、EDI ワークロードを AWS に移行する際の時間、労力、コストが削減されます。 AWS CloudTrail Lake にて AI 機能で強化されたログ分析が可能に AWS CloudTrail Lake は、アクティビティログや AWS Config の設定項目を保存し分析するためのデータレイクサービスです。今回、AWS CloudTrail Lakeに 2 つの AI 機能が追加されました。1 つは、自然言語によるクエリ生成機能です。この機能により「先週、権限不足で失敗したAPIイベントは何？」といったような質問で AWS アクティビティに関する情報が得られるようになりました。2 つ目は、クエリ結果要約機能です。この機能により、AWSアクティビティログから意味のあるインサイトを得るために必要な時間と労力が大幅に削減できるようになりました。現時点では英語のみのサポートとなっています。 SageMaker Model Registry がモデルのリネージをサポートし、モデルガバナンスを向上 Amazon SageMaker Model Registry が機械学習モデルのリネージ追跡をサポートするようになりました。これにより、データ準備やトレーニングからモデル登録、デプロイメントまで、ML ワークフローの各ステップに関する情報を自動的に取得し保持することが可能になります。これによりモデルライフサイクル全体の可視性が向上し、モデルガバナンスが改善されます。 Amazon SageMaker Model Registryが機械学習モデルのライフサイクルステージをサポート Amazon SageMaker Model Registry が ML モデルのライフサイクルステージをサポートするようになりました。今回のリリースにより、モデルレジストリ内の ML モデルに対して、開発、テスト、本番環境などのカスタムステージを定義できるようになりました。これにより、トレーニングから推論まで、ライフサイクルの異なるステージ間でのモデルの遷移を簡単に追跡および管理できます。 Amazon SageMaker ノートブックインスタンスが Trainium1 および Inferentia 2 ベースのインスタンスをサポート Amazon SageMaker ノートブックインスタンスで、Trainium1 (Trn1) および Inferentia2 (Inf2) ベースの EC2 インスタンスの一般提供を開始しました。Trn1 は生成 AI モデルのトレーニング、Inf2 は 推論において低いコストで高いパフォーマンスを実現します。Amazon SageMaker 上で、コスト効率良く LLM などを扱うことができるようになりました。 Amazon EC2 キャパシティブロックが新しいリージョンに拡大 EC2 キャパシティブロックとは、需要の高い GPU インスタンスを、必要な時間分予約することができる機能です。今回、P5 インスタンスの EC2 キャパシティブロックが 2 つの新しいリージョン（オレゴンおよび東京）で利用可能になりました。EC2 キャパシティブロックを使用すると、1〜64 インスタンス（512 GPU）のサイズで、最大 8 週間前から最大 28 日間の GPU キャパシティを予約することができます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

生成 AI は企業の業務効率化やイノベーション創出の鍵として注目を集めています。生成 AI は単体で利用することも可能ですが、企業が保有する多様なデータと組み合わせることで生成 AI の真価が発揮されます。このため、企業内の重要文書やデータを適切に管理し、AI 環境と連携させることが重要となっています。 日本において、クラウドストレージサービスとして Box が広く利用されています。 株式会社アイ・ティ・アール の調査によると、Box は国内コンテンツ・コラボレーション市場のベンダー別売上金額シェアで2年連続1位を獲得しています。さらに2023年度の業種別市場シェア予測では、製造、金融、通信、サービス、建設、公共・公益という主要6業種でシェア1位を達成しています。 企業データと生成 AI を組み合わせるにはいくつかアプローチがありますが、代表的な手法として RAG (Retrieval Augmented Generation; 検索拡張生成) があります。実際、筆者がお客様とお話しする中でも、Box 内のドキュメントを RAG で活用したいという相談をいただくことがあります。 AWS のインテリジェントエンタープライズサーチサービスの Amazon Kendra や、生成 AI アシスタントアプリケーションの Amazon Q Business はさまざまなデータソースに接続できるコネクターを用意しており、それぞれ Box コネクターを準備しています。一方、Box 内のドキュメントを RAG のために利用可能な形で AWS に取り込むことに特化したソリューションとして、 アクロクエストテクノロジー株式会社 が開発した DocCollector が注目されています。DocCollector は、Box に保存されているドキュメントを、そのアクセス権限を保持したまま AWS 環境に同期することができます。 本記事では、Box 内のデータを DocCollector を利用して AWS に取り込み、生成 AI アプリケーション開発のためのサービスである Amazon Bedrock を活用した RAG システムを構築する具体的な方法について解説します。なお、本記事の執筆に当たってアクロクエストテクノロジーの鈴木貴典様と古賀匠様のご協力もいただいています。 DocCollector とは 「DocCollector」とは、外部クラウドストレージのドキュメントを AWS に連携させ、生成 AI と組み合わせた RAG 構成をすばやく構築させるためのドキュメント同期ソリューションです。 Amazon Kendra と同期させた場合の構成 Amazon Bedrock Knowledge Basesと同期させた場合の構成 現在 Box に対応しており、RAG の検索エンジンとしての Amazon Kendra や、RAG システム構築のマネージドサービスである Amazon Bedrock Knowledge Bases との連携が可能です。Box とのドキュメント同期を、効率よく実施できるようにするため、以下のような機能を備えています。 同期対象のファイル一覧出力 ファイル全体同期 ファイル差分同期 ユーザー指定での同期 同期対象のフィルタリング 外部共有ファイルの同期有無の指定 ユーザー権限同期 グループ権限同期 これらの機能により、Box に大量のドキュメントが登録されている場合でも、必要なファイルのみに絞って効率的に同期することが可能です。また、アクセス権限を同期させることも可能なため、RAG で検索処理が行われた際に、Box 上のアクセス権限を元に、表示させるドキュメントを制限することも可能です。 加えて、お客様の AWS アカウント内に本ソリューションを構築して動作するため、ドキュメントが外部の環境を経由したり、保持されたりすることがないため、セキュアに運用することができます。 DocCollector はアクロクエストテクノロジーが支援した 大阪市高速電気軌道株式会社 (Osaka Metro) 様の事例 でも活用されています。 DocCollector と Amazon Bedrock を利用した RAG システムの構築 DocCollector を利用して Box のドキュメントを Amazon Kendra に同期させ、さらに、Amazon Bedrock を利用した RAG システムの構築例を説明します。 今回は、単にドキュメントを同期するだけではなく、Box のアクセス権限 (Access Control List; ACL) も同期し、RAG で利用されるドキュメントを、ユーザー毎にアクセス制御できるようにします。RAG でのドキュメントのアクセス制御は、企業内ではニーズが多い内容であり、DocCollector を利用することで、そのようなことも実現可能となります。 前提条件 Boxからドキュメント同期を行うには、以下の内容が必要となります。 Box Enterprise 以上のプラン Box の開発者コンソールにおける Box アプリの作成、および、その JWT 認証ファイル RAG システム構築の流れ 以下のような流れで、DocCollector でドキュメントを同期し、Amazon Kendra と Amazon Bedrock を組み合わせた RAG システムの構築を行います。 Box のファイル準備 Amazon Kendra のインデックス作成／カスタムデータソースの登録 DocCollector の構築 DocCollector での Box ドキュメント同期 Amazon Kendra でのドキュメント同期結果の確認 Amazon Bedrock を利用した RAG 処理の実現 1. Box のファイル準備 最初に、サンプルとして、以下のような構成で Box にドキュメントが登録されているとします。アクセス権限の確認をするために、フォルダによってアクセスできるユーザーを設定しています。 Box 内のファイル構成 Box 内のファイル構成 (DX 推進部門) Box 内のファイル構成 (開発部門) 2. Amazon Kendra のインデックス作成／カスタムデータソースの登録 Amazon Kendra のインデックスを作成し、それに対して、カスタムデータソースを登録します。DocCollector の構築の際に、このカスタムデータソースに DocCollector を紐づけることで、Box 内のドキュメントを Amazon Kendra に同期できるようになります。 Amazon Kendra インデックス作成 Amazon Kendra カスタムデータソース登録 3. DocCollector の構築 まず、DocCollector を自社の AWS アカウントにセットアップします。DocCollector は、アクロクエストテクノロジーから提供されます。DocCollector の AWS Batch の構成は、 AWS Cloud Development Kit (CDK) で自動構築されます。 DocCollector の構築 AWS Batch のジョブとして DocCollector を登録した様子は以下の通りです。 DocCollector の AWS Batch ジョブ登録 ※ Box への接続情報は、AWS Batch のパラメータとして指定します。 4. DocCollector での Box ドキュメント同期 DocCollector を用いて Box 上のドキュメントを AWS に同期させます。 同期処理は、先ほど構築した AWS Batch のジョブを実行するだけです。ジョブが正常に終了したら、ドキュメントの同期が完了しています。同期処理の詳細については、 Amazon CloudWatch Logs から確認できます。 DocCollector の AWS Batch ジョブ実行の結果 5. Amazon Kendraでのドキュメント同期結果の確認 Amazon Kendra のインデックスやデータソースの詳細を見ると、正常に同期が完了し、9個のファイルがすべて同期できたことが確認できます。 Amazon Kendra インデックス (同期後) Amazon Kendra データソース (同期後) また、Amazon Kendra の検索コンソールから、検索を行ってみます。ここでは、それぞれのドキュメントが適切に同期されているかを確認するため、管理者権限のもとで検索します。ユーザーのアクセス権限による影響の差分は次のセクションで確認します。 Amazon Kendra 検索コンソール (開発部門のドキュメント) Amazon Kendra 検索コンソール (DX 推進部門のドキュメント) アクセス権限が指定されている、「開発部門」フォルダ内のドキュメントも、「DX推進部門」フォルダ内のドキュメントも、どちらの内容も検索できていることが確認できました。 定期的に、DocCollector のバッチジョブを実行することで、ドキュメントの内容は最新化されます。 Amazon EventBridge Scheduler などを利用して、定期実行されるようにしておくと良いでしょう。 6. Amazon Bedrock を利用した RAG 処理の実現 Amazon Bedrock と Amazon Kendra を組み合わせた RAG システムの場合、以下のような処理の流れになります。 RAG の処理の流れ AWS が OSS として公開している「 Generative AI Use Cases JP (GenU) 」でも、上記の構成で RAG システムを構築できますが、今回、Box のアクセス権限に基づいたドキュメント検索を確認するため、アクロクエストテクノロジー社が提供している、エンタープライズ向け生成 AI アシスタントである「 AcroChatAI 」を利用して、動作確認を行います。ここでは、以下のような制御が正常に行われているかを確認します。 userA に対しては、「DX 推進部門」のドキュメントだけが検索に利用され、「開発部門」のドキュメントは検索に利用されない。 userB に対しては、「開発部門」のドキュメントだけが検索に利用され、「DX 推進部門」のドキュメントは検索に利用されない。 userC に対しては、「DX 推進部門」のドキュメントも「開発部門」のドキュメントも検索に利用される。 まずは (1) の「userA」での操作を確認します。「DX 推進部門」のドキュメントを元にした情報は問合せできていますが、「開発部門」のドキュメントを元にした情報は問合せ結果が出力されません。 DX 推進部門所属の userA の検索結果 (1) DX 推進部門所属の userA の検索結果 (2) 次に (2) の「userB」での操作を確認します。「開発部門」のドキュメントを元にした情報は問合せできていますが、「DX 推進部門」のドキュメントを元にした情報は問合せ結果が出力されません。 開発部門所属の userB の検索結果 (1) 開発部門所属の userB の検索結果 (2) 最後に (3) の「userC」での操作を確認します。今度は、どちらのドキュメントの内容も問合せできています。 両方のフォルダにアクセスできる userC の検索結果 (1) 両方のフォルダにアクセスできる userC の検索結果 (2) このように、DocCollector を利用すると、Boxのドキュメントを同期させるだけではなく、Amazon Kendra のアクセス制御機能とも連携し、RAG で利用されるドキュメントを、ユーザー毎に制御することが可能になることが確認できました。 今回は、シンプルな Box の構成でしたが、一部のドキュメントに限定して同期したり、ファイル差分で同期したりと、DocCollector には、効率よく Box のドキュメントを同期できる機能が備わっています。 まとめ 本記事では、アクロクエストテクノロジーが提供する DocCollector を利用して、Box のドキュメントとアクセス権限を Amazon Kendra に同期させ、そこから Amazon Bedrock を利用した RAG システムを実現しました。 これにより、企業は、クラウドストレージサービスとして Box を利用しつつ、その内容を、AWS 上で RAG システムとして活用することができるようになります。 また、今回は Amazon Kendra との連携でしたが、DocCollector は、Amazon Bedrock Knowledge Bases との連携にも対応しています。また、生成 AI アシスタントの Amazon Q Business にも今後対応する予定です。DocCollector を活用することで、Box と連携可能な RAG システムを簡単に構築できるようになります。 参考情報 RAG 向けドキュメント同期ソリューション 「DocCollector」 エンタープライズ向け生成 AI アシスタント「AcroChatAI」   著者について 本橋 和貴 (Kazuki Motohashi / @kmotohas ) は、AWS Japan の機械学習スペシャリストソリューションアーキテクトです。AWS の AI/ML サービスのお客様に対する技術的な支援を行いながら市場開拓を推進しています。好きなサービスは Amazon Bedrock と Amazon SageMaker です。週末は子供と屋内遊園地で遊ぶのが習慣になっています。博士 (理学)。 鈴木貴典 (Takanori Suzuki / @takanorig ) は、アクロクエストテクノロジー株式会社のシニアテクニカルアーキテクトです。お客様へのクラウドを活用したシステムのご提案や、開発・構築などのコンサルティングを実施しています。サーバーレス・アーキテクチャ推しなので、Amazon Bedrock はもちろん、AWS Lambda 他、サーバーレス系サービスを多用しています。こう見えて (?)、甘党なんですが、最近は健康を意識して控えめにしています。 古賀匠 (Takumi Koga) は、アクロクエストテクノロジー株式会社のクラウド開発エンジニアです。主に、AI/ML サービスを活用したクラウドシステムの開発・構築を得意としています。特に最近は LLMOps に興味があり、生成 AI をどう活用／運用するかを考えています。趣味はサッカープレミアリーグ観戦で、応援しているチームが勝つと、週明けはテンションが高くなります。

2023 年 12 月 22 日、Amazon CloudWatch Network Monitor の提供を発表しました。これは AWS 上のハイブリッドネットワーク接続の可視化を容易にする CloudWatch の機能です。CloudWatch Network Monitor は現在、AWS Direct Connect と AWS Site-to-Site VPN で構築されたネットワーク用のハイブリッドモニターをサポートしています。Amazon CloudWatch Network Monitor は Amazon CloudWatch のコンソール上で利用することが可能です。 この記事では、CloudWatch Network Monitor (CWNM) を使用してハイブリッドネットワークのパフォーマンスを測定し、MTTR ( 平均復旧時間 ) を短縮する方法について説明します。 ハイブリッド接続とグレー障害 Advanced Multi-AZ Resilience Patterns Whitepaper では、グレー障害を異なるエンティティが異なる視点で障害を検知することと定義しております。グレー障害は、原因特定と解決が難しい場合があります。ネットワークドメインでのグレー障害の例としては、特定のネットワークリンクでの断続的なパケットロスやレイテンシーの変動などがあります。 このような状況が発生すると、あるエンティティ ( ルーティングコントロールプレーン ) では低下による影響は見られないのに対して、別のエンティティ ( お客様 ) ではスループットの低下やレイテンシーの増加のような形で影響が見られます。 Border Gateway Protocol (BGP) は、AWS Direct Connect と AWS Site-to-Site VPN で使用されるダイナミックルーティングプロトコルで、TCP のトランスポートプロトコルで動作しています。TCP は、再送信やスライディングウィンドウなどのメカニズムによって、ある程度のネットワーク低下を許容することができます。さらに、TCP セッションは、お客様のルーターと AWS Direct Connect ルーターとの間で確立されます。そのため、VPC とオンプレミスネットワーク間のどこかでネットワーク障害が発生しても、BGP では必ずしも低下の兆候に気づけないかもしれません。 Direct Connect (DX) または Site-to-Site VPN によるハイブリッド接続を必要とする AWS のお客様は、グレー障害が発生したら直ちに検知し、問題が起きている経路からトラフィックを回避するオプションを用意する必要があります。これまでの経験から、ネットワークに問題が発生すると、ネットワークエンジニアは問題の特定に相当な時間を費やすことがわかっています。パフォーマンス低下がお客様管理のネットワーク部分で発生したのか、それとも AWS 責任範囲内のネットワーク部分で発生したのかを迅速に把握することは、MTTR の短縮に役立ちます。 野村総合研究所は Direct Connect のパートナーです。当社にとって、ネットワークのグレー障害を検出・特定し、その影響を軽減するまでの時間を短縮することは長年の課題でした。 CloudWatch Network Monitor のおかげで、エンドツーエンドのパフォーマンスの低下や停止が発生と同時に検知できるようになりました。CloudWatch アラームでしきい値を設定し、CloudWatch Network Monitor を Lambda や SNS などの他の AWS サービスと統合するのは簡単でした。 上記により、ネットワークイベントが検出された際に事前に定義したアクションを実行することで、これまで以上に多くのネットワーク障害の影響を自動的に軽減できると期待しています。 株式会社野村総合研究所 シニア・アソシエイト 藤原 和樹 氏 Amazon CloudWatch Network Monitor の紹介 Network Monitor を使用する以前は、ハイブリッドアーキテクチャを採用しているお客様は、既製のソリューションを使用するか、独自のツールを開発したアクティブ監視手法を実装することで、ネットワークのグレー障害の問題に対処してきました。 CloudWatch Network Monitor は、フルマネージド型のエージェントレスソリューションで簡単に実現します。 モニター は、Direct Connect または Site-to-Site VPN 経由で到達可能な IPv4 または IPv6 宛先への ICMP または TCP トラフィックをテストするために使用できます。送信元サブネット、宛先 IP、 パケットサイズ、およびプロトコル/ポートの各組み合わせは、 プローブ と呼ばれます。 Amazon VPC で モニター を作成すると、AWS はバックグラウンドで RTT (Round-Trip Time) とパケットロスの測定を実行するために必要なすべてのインフラストラクチャを作成します。 プローブ で設定されたポートとプロトコルでモニタリングトラフィックに応答するように監視ターゲット （プローブの宛先） を設定するだけで済みます。 Direct Connect と併用する場合、 モニター はモニターがデプロイされた VPC から DX 接続を終端する Direct Connect ロケーションまでの、AWS が管理するネットワーク経路の状態を可視化します。これは Network Health Indicator (NHI) と呼ばれ、問題が AWS のネットワークにあるのか、お客様が管理するネットワークにあるのか原因特定のスピードアップに役立ちます。 モニター によって生成されたメトリクスは Amazon CloudWatch に公開され、ダッシュボードとアラームを設定して、通知や軽減アクションを実施することができます。 シナリオ Direct Connect High Resiliency モデルを実装する一般的なお客様のシナリオを以下に説明します。この設計に焦点を当てて、Network Monitor の設定と使用方法を示します。Network Monitor は他のシナリオでも使用することができます。 図 1. Direct Connect High Resiliency 構成を利用のお客様 こちらのお客様では各 Direct Connect ロケーションにルーターを設置しています。各ルーターは、DX 専用接続を介して AWS ルーターに接続されます。 2 つの Transit VIF (T-VIF) が、Direct Connect Gateway (DXGW) に関連付けられた AWS Transit Gateway との間でトラフィックを転送するように設定されています。お客様のルーターは、両方の T-VIF 上で eBGP を介して DXGW とルーティング情報を交換します。これは、AWS の ドキュメント 、ブログ記事、および ハイブリッド接続ホワイトペーパー などのリソースで扱われている一般的なアーキテクチャです。 お客様は、複数のプライベートサブネットにワークロードを所持しており、アプリケーションの可用性を最大化するために、異なるアベイラビリティゾーン (AZ) に分散しています。図を見やすくするために、ここでは 2 つだけ表示することにします。これらのワークロードには、オンプレミス LAN 上のクライアントがアクセスします。 お客様は、等コストマルチパス (ECMP) を使用して、両方の DX 接続間でネットワークフローの負荷分散を行っています。LAN（ 172.16.0.0/24 - 2001:DB8::/48 ） には、AWS から両方の T-VIF 経由で到達が可能です。同様に下の図が示すように VPC にも、LAN から両方の T-VIF を経由して到達可能です。 図 2. 両方のトランジット VIF から LAN に到達可能 プライベートサブネット内のワークロードはレイテンシーにセンシティブです。お客様は、どちらかの経路に障害が発生した場合にも対処できるように、両方の経路のネットワークパフォーマンスを可視化したいと考えています。 AWS リージョン内のアベイラビリティーゾーンは独立した障害ドメインとして設計されている ため、異なる AZ の異なるサブネットからの可視性を提供する必要があります。 モニタリング アーキテクチャ ユーザーのペルソナによって、モニタリングの目的は異なる可能性があります。例えば、アプリケーションオーナーは、ネットワークがアプリケーショントラフィックをどのようにルーティングするかに関係なく、エンドツーエンドのレイテンシーとパケットロスがエンドユーザーのエクスペリエンスに影響を与えないことを確認したいと考えるかもしれません。 アプリケーション開発者は、ワークロードと同じサブネットに モニター を設定し、オンプレミスの LAN に対してプローブを送信します。いずれかのワークロードのサブネットからのモニタリングトラフィックは、オンプレミスのモニタリング宛先に到達するために、利用可能なすべての経路を使用します。 図 3. モニタリングアーキテクチャ (アプリケーションオーナー) 一方、ネットワーク・エンジニアは各ネットワーク経路を重視するため、各 プローブ のトラフィックが特定の経路をたどって宛先に到達するようにモニターを構成します。 図 4 に示す 2 つ目のアーキテクチャでは、ネットワークエンジニアが各モニタリングサブネットにプローブを作成しました。各プローブは、緑色または赤色の DX 接続を経由してのみ到達可能な宛先に設定されています。同様に、モニターの宛先は、緑色または赤色の DX 接続を経由してのみ、図の左側にある対応するプローブに到達できます。例としては VRF-Lite をお客様のルーター上で構成することで実現できます。 図 4. モニタリングアーキテクチャ (ネットワークエンジニア) 執筆時点では、同一 モニター 内に IPv4 と IPv6 の両方の宛先に対する プローブ を作成することはできません。IPv6 宛先への プローブ を設定したい場合は、別の IPv6 モニター を作成してください。 次に、2 つ目のアーキテクチャについて説明し、AWS コンソール内での設定方法を示します。CloudWatch Network Monitor は、サービス API、AWS SDK、AWS CloudFormation、CDK を使用して設定することもできます。ここでは IPv4 のみのモニターを作成する方法を示しております。IPv6 のみのモニターを作成したい場合も同じ手順に従ってください。 Amazon CloudWatch Network Monitor のセットアップ 2 つ目のリファレンスアーキテクチャを実装するために、 monitor-us-east-1-ipv4 という名前の モニター を作成します。これを行うには、Network Monitor コンソールを開き、 モニターを作成 を選択します。 図 5. Network Monitor コンソールでのモニター作成 集計期間 は、 Network Monitor のプローブが生成したメトリクスを CloudWatch に送信する間隔を表します。 この値は 30 秒（デフォルト）のままにします。これは Network Monitor によって生成されるメトリクスに依存しており、自動化されたアクションを使用して障害のあるネットワークパスを迅速に回避するためです。 図 6. 新しいモニターの作成 次に、 プローブ をデプロイするソースとして、 monitor-subnet-us-east-1a と monitor-subnet-us-east-1b のサブネットを選択します。最後に、 172.16.100.1 と 172.16.200.1 を宛先として設定します。コンソールを使用して作成された プローブ は、デフォルトで 56 バイトサイズの ICMP エコーパケットを送信します。これを図 7 に示します。 図 7. モニターの送信元サブネットと宛先IPを指定 ステップ順に従うと、すべてのリソースがデプロイされ、 プローブ が先ほど設定した集計間隔ごとに CloudWatch にメトリクスを送信開始するまで、 モニター と プローブ は Pending 状態になります。 Network Monitor ダッシュボード CloudWatch Network Monitor は モニター 毎にダッシュボードを作成します。これは、Network Monitor ダッシュボードで モニター 名をクリックすることでアクセスできます。 左上には、 モニター がデプロイされているリージョンの AWS ネットワークのステータスが表示されます。 この情報は接続が複数のネットワーク ( 例：AWS ネットワーク、Direct Connect Partner バックボーン、オンプレミスデータセンターネットワークなど ) を経由する場合に、モニターされたパケットロスや増加したレイテンシーの原因を調査するのに役立ちます。 右上には、アラーム状態の プローブ 数、平均パケットロス、選択した時間範囲の RTT など プローブ のステータスの概要が表示されます。 図 8 では、AWS Network Health Indicator メトリクスの履歴と、各 プローブ のパケットロスと RTT を示す折れ線グラフが表示されます ( 図 9)。この情報を使用して、AWS Network Health Indicator とモニターされたパケットロス/レイテンシーを相関することで、ネットワークの問題をさらにトラブルシューティングできます。 図 8. モニターのサマリー表示 図 9. Network Monitor メトリクスのサマリー表示 CloudWatch メトリクス AWS Network Monitor は、CloudWatch メトリクスを名前空間内に “AWS/NetworkMonitor” として公開しています。各プローブには 3 つのメトリクスがあります。 HealthIndicator: 測定時に AWS ネットワークが正常であれば 0、低下している場合は 100 です。 PacketLoss: パケットロスをパーセント値で表します。 RTT: ラウンドトリップ時間をマイクロ秒単位で表します。 図 10. NetworkMonitor CloudWatch メトリクス (RTT) Metrics math 複数のメトリクスを数式と組み合わせると便利な場合があります。 例えば、複数の プローブ が物理リンクを共有している場合、集約期間中 （ この場合は 30 秒）にすべての プローブ のパケットロスの平均を取得することができます。取得するには、関連するメトリクスを選択し、「数式を追加」オプションを使用してください。次に、図 11 と図 12 に示すように、適切な関数  ( 平均を表す “AVG” など ) を選択します。 図 11. CloudWatch メトリクスの数式追加 図 12. CloudWatch メトリクスに数式を追加した結果 (RTT) アラームの作成 シナリオに最も適したメトリクスを特定したら、アクションセクションの小さなベルのリンクアイコンをクリックして、必要なアラームと アクション を設定できます。 最もシンプルなタイプのアラームとして、静的なしきい値を使用します。例えば、パケットロスの平均値が 1% を超えた場合に通知するアラームを作成できます。ほとんどのアプリケーションでは、1% のパケットロスは許容範囲内と考えられます。 図 13. パケットロスに関する CloudWatch アラームの設定 事前に妥当なメトリクス値が分からない、または日中に何らかの変動が予想されるため ( ラウンドトリップタイムなど ) 静的なしきい値を設定したくない場合は、 CloudWatch 異常検出 を使用してアラーム設定ができます。 異常検出 は予想される帯域の値を計算し、実際の値がその帯域より大きい場合や低い場合、または帯域外である場合にアラートを発します。プローブが失敗した場合 （ パケットロス = 100%）、RTT は 0 ミリ秒と報告されるため、予想よりも低い値や高い値を検出するように異常検出を設定することは合理的です。 図 14. CloudWatch 異常検出の設定 フェイルオーバーの自動化 Amazon Simple Notification Service (SNS) を使用してアラートを送信する以外に、障害検出時の際に Direct Connect リンクのフェールオーバーを自動化することも可能です。そのためには、 Amazon EventBridge によって呼び出される Lambda 関数を使用します。サンプルの Lambda 関数は AWS Samples GitHub リポジトリ で提供されています。詳細とベストプラクティスについては、ブログ記事「 AWS Direct Connect monitoring and failover with Anomaly Detection 」 を参照してください。 また、実際の障害シナリオが発生した際に期待通りに機能することを確認するため、フェイルオーバーの自動化を定期的にテストすることもベストプラクティスです。 リソースの削除 Network Monitor をテスト後は、想定していない料金の発生を避けるため、すべてのモニターとプローブ、この機能をテストするために作成したその他のリソースを削除して、テスト環境をクリーンアップしてください。 まとめ この投稿では、ハイブリッドネットワークのモニタリングを容易にするフルマネージド型でエージェントレス機能である Amazon CloudWatch Network Monitor を紹介しました。Network Monitor を使用することで、ネットワークの問題をより迅速にトラブルシューティングと修復を行うことができるため、カスタマーエクスペリエンスへの影響を最小限に抑えることができます。 Network Monitor の料金の詳細については、 こちら の CloudWatch 料金表ページをご覧ください。この機能の設定方法と使用方法に関する技術的なガイダンスについては、 AWS Documentation をご覧ください。 本稿は、2023 年 12 月 22 日に Networking & Content Delivery で公開された “ Monitor hybrid connectivity with Amazon CloudWatch Network Monitor ” を翻訳したものです。翻訳はテクニカルアカウントマネージャーの安藤 彰が担当しました。

本記事は、2024 年 7 ⽉ 3 ⽇に公開された ” Does Your People Strategy Match Your Transformation Objectives? “を翻訳したものです。 なぜ多くの企業のイノベーションプログラムは失敗するのでしょうか。 その答えは、組織の複雑さと同じぐらい複雑です。厳格すぎるガバナンスモデル、縦割りのチーム、厳しい規制環境、官僚的な意思決定などが主な原因として指摘されることがありますが、見過ごされがちな領域が 1 つあります。それは人材戦略です。 人材プロセスは、イノベーションを支援するか、それとも阻害するかのどちらかです。中間地点はありません。 私は最近、同僚の Mark Schwartz が書いた「 Adaptive Ethics for Digital Transformation 」という本を読みました。この思考を刺激する挑戦的な本の内容を要約しようとは思いません ( 特に帽子、食べ物、神話上の怪物の例え話に惹かれる方には )。その代わりに、本の中の1つの引用について考えを述べたいと思います。これは本の主要なテーマではないので、 Mark の著作権を侵害しているわけではありません (ぜひその本を読んでみてください。素晴らしい本です)。 エンロンの崩壊の話の途中で、Mark は次のような言葉を述べています: 「文化は、従業員を成功に導くものを中心に形成される」 Mark は、エンロンの掲げた価値観が、組織内での個人の成功や昇進につながるものとは全く異なっていたことを示しています。価値観自体が問題だったのではなく、現実との乖離が問題だったのです。 私はアマゾンでの 11年間 ( AWSとAmazon.comの両方 ) において、人材と企業文化に焦点を当ててきました。私は企業文化の専門家で、常に「文化が最も重要なもの」という視点で世界を見ています。そして、地球上で最も顧客中心主義の企業になるというミッションを果たすために、意図的に企業文化を進化させてきた組織で働いています。しかし、Mark の言葉は他の組織にも当てはまるのでしょうか ? 私はそう考えており、多くの組織変革が頓挫するのは、組織が掲げる文化的価値観を従業員の育成、業績評価、そして報酬にまで反映させることに失敗した時だと強く思います。 過去 5 年間で、私はほぼすべての業界にわたる世界中の 1,000 人以上の組織リーダーたちと対話を重ねてきました。その中で、ある会話が特に印象に残っています。それは、組織変革を追求する際には 人材戦略も見直す必要性 を示すものでした。 数年前、私はある世界的な大手石油・ガス会社のイノベーション責任者 (仮にザビエルと呼びます) と時間を過ごす機会がありました。エネルギー業界の多くの既存組織と同様に、ザビエルの会社も自社を変革し、よりイノベーティブになる緊急の必要性を感じていました。その従来の持続可能で収益性の高いビジネスモデルでは、枯渇する天然資源と高まるエネルギー需要への対応ができなくなっていたのです。 会話の中で、ザビエルは会社全体で イノベーションを推進するための方法 について話してくれました。それには、経営陣からの高水準なイノベーション目標、各組織へのイノベーション予算、特定の課題に取り組む小規模チーム、ハッカソン、表彰や賞与など、あらゆる手段でした。 彼は言いました。「このプログラムを1年半実施しています。そして、社内にはうまくいっている部署もあります。しかし、私達が期待していたほどには浸透していません。私たちは実験をしているわけではありません。私たちは依然として官僚的で、意思決定が遅いのです。人々は革新的なプロジェクトに参加しようとしません。私の何が間違っているのでしょうか ? 」 ザビエルの計画は、組織のイノベーションを推進するための教科書的なアプローチとほぼ一致していました。正直なところ、彼が何を見落としているのか思い当たりませんでした。1 時間後、私たちは昼食を取りながら、 アマゾンのリーダーシップ原則 とその報酬哲学へ話題を移しました。アマゾンは長年にわたり、各従業員の全体的な報酬の重要な一部として会社の株式を含めてきました。この方法は、私たちのリーダーシップ原則のオーナーシップと一致しています。 リーダーはオーナーです。リーダーは長期的視点で考え、短期的な結果のために、長期的な価値を犠牲にしません。リーダーは自分のチームだけでなく、会社全体のために行動します。リーダーは「それは私の仕事ではありません」とは決して口にしません。 ここで言う「リーダー」とは、肩書や役職に関わらず組織内のすべての従業員を指します。誰もが周囲の人々の行動に影響を与える事ができるので、責任あるリーダーの心構えで仕事に取り組む必要があります。そしてAWSでは、「リーダーはオーナーです」というのは文字通りの意味があります。役割と結果に対する責任を持つことに加えて、各従業員がそれぞれ会社の一部を所有し、組織の長期的な成功から利益を得られます。株式を全従業員に付与することで、個人の動機づけと組織の目標を一致させているのです。 このオーナーシップの考え方は、私がザビエルと会話していたイノベーションの課題とどのように関連しているのでしょうか? 私が報酬哲学の詳細を共有すると、ザビエルは私を遮って言いました。「待ってください、全員に株が支給されているのですか ? 」 「そうです。もちろん、ジョブレベルや仕事のパフォーマンスに基づいて付与される量は異なります。パフォーマンスが良くない人は株を受け取れないこともあります。ただ、それ以外の従業員全員に、毎年の報酬の一部として株が支給されるのです」 「へぇ」と彼は言いました。「うちの経営陣は成果主義を信じています。私たちも株を与えていますが、10人いるチームのうち上位2人しか対象にしていません。それは大きな報酬で、年俸の30%にもなることがあります。」 経営陣が株式報酬を厳しく審査し、それを受け取った人々は通常、その年の完璧な結果を出していました。全ての目標と目的を達成していたのです。そのような環境で、わずかでも失敗のリスクのあるプロジェクトに手を挙げる人がいるでしょうか? 私にも共感できる部分があります。私は大学生の子供が 3 人います。アメリカでは、それは子供たちの教育に多額のお金をかけているということです。私なら、ザビエルの会社のモデルに従って 30% の昇給を得られれば、確実に達成可能な目標を設定し、それらの目標を他の何よりも綿密かつ容赦なく追及するでしょう。すべての人がお金に動機づけられるわけではありませんが、完璧な実行を報酬とする文化は、実験とイノベーションに逆行するものです。経営陣は「素早く失敗せよ！」と言うかもしれませんが、報酬と是正のシステムは逆のことを伝えています。 私がザビエルと話した1年後、彼の会社はAWSのデジタルイノベーションチームと提携し、5 つの重要な実験に取り組み、従来の 3 分の 1 の期間で実行しました。それらの実験のうち 2 つは現在も本番環境で稼働しています。私たちの会話がザビエルの会話の変化どの程度関係していたかは分かりませんが、昨年、同じ組織のリーダーシップの方々とも会話する機会がありました。彼らは会社の報酬アプローチを改訂し、すべての従業員に対して株式を提供するようになっていたのです。 ここでの変革の教訓は「ただ従業員への報酬の与え方を変えればいい」というわけではありません。どんな大規模な組織の変革にも、それによって生じる課題を解決する万能薬はありません。しかし、自分の組織のあらゆる側面、特に人材に関する実践、を見直す意思のあるリーダーは、より持続的な変革を導く可能性が高いのです。 私からいくつかのアイデアを提案しましたが、より良いアイデアがあればお聞かせください。 – Stephen 本記事は、カスタマーソリューションマネージャーの宮本雅勝が翻訳を担当しました。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 12月2日からの AWS re:Invent 関連の情報が少しづつ出てきますね。去年同様、色々なセッションがオンライン中継もされる予定ですので、視聴したい方は こちらのレジストレーション をお忘れなく。 時差の関係で、日本から視聴するのは難しいものも多いのですが、録画も公開される予定ですし、最初の キーノート である現地月曜夜のPeter DeSantisキーノートは、日本時間だと火曜のお昼12時半ごろ開始予定なので、ライブで見やすいかと思います。 それでは、先週の主なアップデートについて振り返っていきましょう。今週はいつもに増して新発表が多かったので、各項目の説明はできるだけシンプルにしています。詳細はリンク先のWhat’s new等でご確認ください。 2024年11月11日週の主要なアップデート 11/11(月) Amazon OpenSearch Ingestion adds support for ingesting data from Amazon Kinesis Data Streams – AWS Amazon OpenSearch Ingestion では、Amazon Kinesis Data Streams から直接レコードを取り込むことができるようになりました。これにより、追加の工数が不要で、KinesisからのストリーミングデータをOpenSearch Serviceでインデックスできるようになりました。 Get x-ray vision into AWS CloudFormation deployments with a timeline view – AWS AWS CloudFormation で Deploy timeline view (デプロイタイムラインビュー)が提供されるようになりました。この機能は、CloudFormationのスタックで実行する一連のアクションを視覚化してくれるため、スタックでのリソースプロビジョニングアクションの順序やかかった時間を把握しやすくなります。 11/12(火) Amazon SageMaker Model Registry now supports defining machine learning model lifecycle stages – AWS Amazon SageMaker Model Registry でカスタムの機械学習モデルのライフサイクルステージがサポートされました。この機能により、トレーニングから推論まで、モデルライフサイクルのさまざまな段階でのトラックと管理が容易になります。また、承認待ち、承認済み、却下などの段階承認ステータスをトラックして、モデルが次の段階に進む準備ができているかどうかを確認することもできます。 Amazon Managed Service for Apache Flink now supports Amazon DynamoDB Streams as a source – AWS Amazon DynamoDB 用の新しい Apache Flink コネクタが利用可能になりました。これは AWS が Apache Flink プロジェクトにコントリビューションした 新しいコネクタ であり、Apache Flink のソースとして Amazon DynamoDB ストリームを追加し、変更データを順次 Flink に流すことが容易になります。 Amazon EC2 Capacity Blocks expands to new regions – AWS アジアパシフィック (東京)、米国西部 (オレゴン) の2つのリージョンにおいて、 P5 インスタンスで Amazon EC2 の機械学習用キャパシティブロックが利用可能になりました。キャパシティブロックを使用すると、1 ～ 64 インスタンス (512 GPU) のクラスターサイズで、最大 8 週間前まで GPU 容量を最大 28 日間予約できるため、機械学習ワークロードをより確実に実行できるようインフラを準備することが可能になります。 Amazon EventBridge announces up to 94% improvement in end-to-end latency for Event Buses – AWS Amazon EventBridgeで、2023年1月以降の改善によりイベントバスのエンドツーエンドのレイテンシーが最大 94% 改善されたことを発表しました。2023年1月時点では、2235.23ms (P99)であったレイテンシが、2024年8月には129.33ms (P99)まで短縮しています。これにより、よりミッションクリティカルな領域でも利用が可能になります。 Amazon EBS now supports detailed performance statistics on EBS volume health – AWS Amazon Elastic Block Store (EBS) ボリュームで、詳細なパフォーマンス統計が利用可能になりました。この新機能により、1秒未満の精度で 11 のメトリックスにアクセスし、 EBS ボリュームの入出力 (I/O) 統計をリアルタイムにモニタリングできます。 11/13(水) Amazon OpenSearch Service now supports 4th generation Intel (C7i, M7i, R7i) instances – AWS Amazon OpenSearch Service で、第4世代インテル Xeon スケーラブルプロセッサーベースのコンピューティング最適化インスタンス (C7i)、汎用 (M7i) インスタンス、およびメモリ最適化インスタンス (R7i) を利用可能になりました。これらはC6i、M6i、R6i の各インスタンスよりもそれぞれ最大 15% 価格性能比を実現します。 Introducing resource control policies (RCPs) to centrally restrict access to AWS resources – AWS AWS Organizations で Resource Control Policy (RCP) が利用可能になりました。これは、組織内のAWSリソースへのアクセスを一元的に制御できる機能で、外部IDによる内部リソースへのアクセス防止や、通信のTLS強制といった用途に利用が可能です。現時点では、Amazon S3, AWS STS, AWS KMS, Amazon SQS, AWS Secrets Manager に適用が可能です。 Amazon DynamoDB introduces warm throughput for tables and indexes – AWS Amazon DynamoDB では、新しく warm throughput (ウォームスループット)値と、DynamoDB テーブルとインデックスを簡単にPre warming (事前ウォーミング)できる機能が追加されました。ウォームスループット値を参照すると、テーブルが処理できる読み取り/書き込みオペレーションの数が可視化されます。今後のイベントにおける性能不足に気付いた場合には、事前ウォーミングにより性能値を増やすことができます。詳細は こちらのブログ をご覧ください。 AWS Glue Data Catalog now supports scheduled generation of column level statistics – AWS AWS Glue Data Catalog で、Apache Iceberg 表と Parquet、JSON、CSV、XML、ORC、ION などのファイル形式のデータにおいて、列レベルの統計のスケジュール生成がサポートされました。これにより、統計の生成を簡略化および自動化できます。統計情報は Amazon Redshift Spectrum および Amazon Athena のコストベースオプティマイザー (CBO) と統合されているため、クエリのパフォーマンスが向上し、コスト削減が期待できます。 11/14(木) AWS Backup now supports Amazon Neptune in three new Regions – AWS AWS Backup による、 Amazon Neptuneのバックアップが利用可能なリージョンが拡張され、新たに大阪、ジャカルタ、ケープタウン)リージョンで利用可能になりました。 Amazon DynamoDB reduces prices for on-demand throughput and global tables – AWS Amazon DynamoDB の料金改定がアナウンスされました。オンデマンドスループットの価格は最大50%、グローバルテーブルの価格は最大67%引き下げます。この料金は11月1日からの利用分に適用されます。詳細は こちらのブログをご覧ください 。 Amazon Keyspaces (for Apache Cassandra) reduces prices by up to 75% – AWS Amazon Keyspaces for Apache Cassandra は、スケーラブルでサーバーレスの Apache Cassandra 互換データベースサービスです。今回オンデマンドモードの料金を単一リージョンで最大56%、マルチリージョンで最大65%引き下げました。また、プロビジョニングモードの料金は、単一リージョンで最大13%、マルチリージョンで最大20%引き下げられました。また、Keyspacesは有効期限（TTL）の削除料金を75%引き下げました。この変更により、以前のようにスパイクがあるワークロードだけでなく、大半のワークロードでオンデマンドモードの利用が推奨されます。 AWS Transit Gateway and AWS Cloud WAN enhance visibility metrics and Path MTU support – AWS AWS Transit Gateway と AWS Cloud WAN enhance において、アベイラビリティーゾーン (AZ) 単位のメトリクスをCloudWatchに送信可能になりました。AZ単位のメトリクスにより、AZ単位で詳細可視化できるようになり、AZ単位の障害を迅速にトラブルシューティングできるようになります。あわせて、パス最大伝送ユニット検出（PMTUD）をサポートするようになりました。 Amazon RDS for PostgreSQL now supports major version 17 – AWS Amazon RDS for PostgreSQL において PostgreSQL バージョン 17.1 が利用可能になりました。あわせて、最新のマイナーバージョンである、16.5、15.9、14.14、13.17、12.21の利用も可能になっています。 Amazon S3 now supports up to 1 million buckets per AWS account – AWS Amazon S3 で、AWS アカウントあたりのデフォルトバケット数のクォータ（上限値）を 100 から 10,000 に引き上げました。また、最大100万バケットまでクォータの増加をリクエスト可能になりました。この変更は自動的に適用されるため、ユーザー側のよる操作は必要ありません。最初の 2,000 バケットは無料で作成できますが、2,000 バケットを超えると、少額の月額料金がかかる点に注意してください。詳細は S3の料金ページ をご覧ください。 Amazon RDS for Oracle now M7i and R7i instances types – AWS Amazon RDS for Oracle で、M7iおよびR7iデータベースインスタンスタイプが利用可能になりました。新しい最大インスタンスサイズは 48xlarge になり、M6iやR6iインスタンスと比較して50%多い最大vCPUとメモリを利用可能になりました。M7i および R7i インスタンスは、Oracle Database エンタープライズエディション（EE）とスタンダードエディション 2（SE2）の両方のエディションで、Bring Your Own ライセンスモデルで利用できます。 11/15(金) Introducing Amazon Route 53 Resolver DNS Firewall Advanced – AWS Amazon Route 53 Resolver DNS Firewall Advanced がリリースされました。これは Route 53 Resolver DNS ファイアウォールの新しい機能で、DNS トンネリングやドメイン生成アルゴリズム (DGA) などの高度な DNS 脅威に関連する、疑わしいDNSトラフィックを監視およびブロックできます。詳細は こちらのドキュメンテーション をご覧ください。 Amazon Data Firehose supports continuous replication of database changes to Apache Iceberg Tables in Amazon S3 – AWS Amazon Data Firehose で RDS、Aurora、もしくはEC2上で稼働する MySQL もしくは PostgreSQL のトランザクションログから更新データを読み取り、Amazon S3上のApache Iceberg表に差分反映させる機能がPreview提供開始になりました。サーバーレスのサービスを利用して、より容易に、RDBからS3への差分レプリケーションが実現可能になります。東京・大阪リージョンでもPreviewが利用可能です。詳細は こちらのブログ をご覧ください。 Centrally manage root access in AWS Identity and Access Management (IAM) – AWS AWS Identity and Access Management (IAM) に、AWS Organizations 管理化のAWSメンバーアカウントにルート(root)権限でアクセス可能な機能が追加されました。これまで個々のメンバーアカウントごとにrootユーザーが必要で、これをセキュアに管理していく必要がありましたが、この機能により集中的にroot権限を管理できるようになります。 詳細はこちらのブログ をご覧ください。 先週もご案内しましたが、恒例の「1時間でre:Inventの発表まとめをしゃべりきる日本語Webinar」が 12 月 6 日 (金) 12:00~13:00 に開催されます。新発表内容をいっきに振り返る内容なので、ぜひこちらもご覧ください。今回はYoutube Liveでの放送予定ですので、事前に「通知を受け取る」ボタンをクリックしておいてください。 – AWS Black Belt Online Seminar 2024 年 AWS re:Invent 速報 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

お客様は通常、SQL Server データベースを Babelfish for Aurora PostgreSQL に移行するために AWS Database Migration Service (AWS DMS) を選択します。AWS DMS は、フルロードの移行は、すべてのエディションの SQL Server をサポートしています。ただし、継続的なレプリケーションと進行中の変更の場合、ソースとなる SQL Server は トランザクションレプリケーション または 変更データキャプチャ (CDC) を有効にする必要があります。これにより、AWS DMS はデータベースのトランザクションログファイルまたはトランザクションログバックアップから変更を読み取り、ターゲットデータベースにレプリケートすることができます。 Enterprise、Standard、Developer などの SQL Server エディションには、トランザクションレプリケーションと CDC 機能が付属しています。したがって、これらのエディションでは Babelfish for Aurora PostgreSQL への継続的なレプリケーションを実装できます。ただし、SQL Server Web エディションを使用している場合や Azure SQL 上で SQL Server ワークロードを実行している場合は、トランザクションレプリケーションと CDC のいずれもサポートされていません。そのような場合は、継続的なレプリケーションなしでフルロードのみを実行できます。 この制限を回避するには、 リンクサーバー と併せて 変更トラッキング を使用するワークアラウンドがあります。このアプローチでは、Azure SQL または SQL Server Web Edition での変更をトラッキングし、対象データベースに効果的にレプリケーションできます。 この投稿では、SQL Server Web Edition (ソース) の変更トラッキング機能と、Babelfish for Aurora PostgreSQL (ターゲット) のリンクサーバー機能を使用して、進行中の変更をレプリケーションする手順を提供します。 ソリューション概要 変更トラッキングはデータベース内のデータ変更をトラッキングするメカニズムです。テーブルで変更トラッキングが有効になると、SQL Server は内部的に別の内部テーブルで変更(挿入、更新、または削除)をトラッキングします。この内部テーブルにはテーブルの主キー列が含まれています。 トラッキングが有効になってからの変更はすべて、CHANGETABLE という関数を使用して取得できます。変更トラッキングの詳細については、「 変更トラッキングの操作 (SQL Server) 」を参照してください。 次の図は、ソリューションアーキテクチャを示しています。 このソリューションを実装するには、次の設定手順を完了してください。 ソースサーバーでデータベースとテーブルレベルの変更トラッキングを有効にします。 AWS DMS を使用して、ソースデータベースの初期フルロードをターゲットに対して行います。 ターゲットにソース SQL サーバーへのリンクサーバーを作成します。 ターゲットにアンカーテーブルを作成します。 ソースから変更されたデータを抽出し、ターゲットテーブルにロードします。 前提条件 このソリューションを試すには、次の前提条件が必要です。 ソースとなる SQL Server または Azure SQL インスタンス SQL Server 上の Northwind データベース バージョン 4.0 または以降の Babelfish for Aurora PostgreSQL インスタンス SQL Server と PostgreSQL のファンクションに関する知識 SQL Server に接続するための SQL Server Management Studio (SSMS) または他のクライアントツール このソリューションには、新しい AWS リソースの作成と利用が伴います。したがって、アカウントに料金が発生します。詳細については、 AWS 料金ぺージ をご確認ください。本番環境にこのソリューションを実装する前に、非本番インスタンスでセットアップを行い、エンドツーエンドの検証を実行することを強くお勧めします。 ソースデータベスでの変更トラッキング有効化 ソースサーバーで変更トラッキングを有効にするには、次の手順に従ってください。 SSMS を使用して SQLServer インスタンスに接続します。 Northwind データベースを選択し、[新しいクエリ] を選択します。 次のコマンドを使用してデータベースレベルで変更トラッキングを有効にします。 ALTER DATABASE NORTHWIND SET CHANGE_TRACKING = ON ( CHANGE_RETENTION = 5 DAYS , AUTO_CLEANUP = OFF ) SQL 継続的レプリケーションのターゲットの一部として含めたいテーブルで変更トラッキングを有効にします。ここでは、次のコマンドを使用して顧客テーブルで変更トラッキングを有効にします。 ALTER TABLE DBO . CUSTOMERS ENABLE CHANGE_TRACKING SQL 次のコマンドを実行して、テーブルで変更トラッキングが有効になっていることを確認してください。 SELECT schema_name ( T . schema_id ) as SCH_NAME , T . NAME , CT . min_valid_version , ct . * FROM northwind . sys . tables T LEFT OUTER JOIN sys . change_tracking_tables CT on T . object_id = CT . object_id WHERE min_valid_version is not null SQL 変更トラッキングが更新された行をどのように取得するかをテストするには、次のコマンドを実行します。 関数 CHANGE_TRACKING_CURRENT_VERSION() を使用して、現在の変更トラッキングバージョンを確認します。この値が 26 であると仮定しましょう。 customers テーブルの行を更新します。 customers テーブルのどの行が更新されたかを確認するには、バージョン番号 (この例では 26) をパラメーターとして CHANGETABLE 関数を使用します。 DECLARE @CTCV INT ; SELECT @CTCV = CHANGE_TRACKING_CURRENT_VERSION ( ) ; -- In this example , the current value is 26 SELECT @CTCV -- update a record in customer table UPDATE dbo . CUSTOMERS SET CompanyName = 'camilo2' where CUSTOMERID = 'ALFKI' -- Get all the changes that are made after version 26 in this example. SELECT P . * , '--' , CT . * FROM customers AS P JOIN CHANGETABLE ( CHANGES northwind . dbo . customers , @CTCV ) AS CT ON P . customerid = CT . customerid ; SQL AWS DMS を使ってフルロードを開始する前に、継続的なレプリケーションが必要なテーブルで変更トラッキングを有効にすることが不可欠です。これにより、システムはフルロードの開始時点から指定されたテーブルに対するすべてのデータ変更操作 (DML) を追跡できるようになります。 AWS DMS を使用して初回のフルロードでソースデータベースをターゲットデータベースに移行 ターゲットにフルロードを使用してソースデータベースを AWS DMS で移行するには、次の手順を実行します。「 Compass ツールと AWS DMS を使用した SQL Server の Babelfish for Aurora PostgreSQL への移行 」を参照し、Babelfish for Aurora PostgreSQL クラスターを作成して接続します。投稿では、AWS DMS を使用して SQL Server から Babelfish にデータを移行する手順も概説されています。 ターゲットサーバーで、Northwind データベースのスキーマを作成してください。Northwind サンプルスキーマは、 GitHub リポジトリ からダウンロードできます。 AWS DMSのフルロード設定を使用して、ソースからターゲットにデータを移行します。手順については、「 AWS Database Migration Service のターゲットとしての Babelfish for Aurora PostgreSQL の使用 」を参照してください。 ソース SQL Server に対するリンクサーバーをターゲットに作成 Babelfish for Aurora PostgreSQL でリンクサーバーを構成するには、「 Babelfish は、リンクサーバーをサポートしています 」を参照してください。次の手順を完了してください。 SSMS または SQLCMD を使用してターゲットのデータベースインスタンスに接続し、次のコマンドを実行します。ここでは、SQLCMD を使用して Babelfish for Aurora PostgreSQL インスタンスに接続します。適切な値でパラメーターを置き換えてください。 sqlcmd - S your - DB - instance . aws - region . rds . amazonaws . com - U test - P password SQL tds_fdw 拡張機能をインストールします。 EXEC sp_execute_postgresql N 'CREATE EXTENSION tds_fdw' ; SQL ターゲットインスタンスで次のコマンドを使用してリンクサーバーを作成します。@datasrc、@rmtuser、および @rmtpassword パラメーターを適切な値に置き換えてください。 Use Northwind ; GO EXEC master . dbo . sp_addlinkedserver @server = N 'ls_northwind' , @srvproduct = N '' , @provider = N 'SQLNCLI' , @datasrc = N 'myserver.xxxxx.US-WEST-2.RDS.AMAZONAWS.COM' , @catalog = 'northwind' ; GO EXEC master . dbo . sp_addlinkedsrvlogin @rmtsrvname = N ' ls_northwind' , @useself = N 'False' , @locallogin = NULL , @rmtuser = N 'username' , @rmtpassword = 'password' ; SQL リモートサーバー上のテーブル、ビュー、またはその他のサポートされているオブジェクトを参照するには、次のコードに示されているように OPENQUERY() T-SQL を使用するか、標準の 4 部構成の名前付け規則を使用します。 SELECT * FROM OPENQUERY ( ls_northwind , 'SELECT * FROM customers' ) ; SQL 初期の変更トラッキングバージョン (この例では 0 を使用) に基づいて customers テーブルの変更されたレコードを取得するには、次のコマンドを実行します。 SELECT * FROM OPENQUERY ( ls_northwind , 'SELECT C.* FROM customers AS C JOIN CHANGETABLE(CHANGES northwind.dbo.customers,0 ) AS CT ON C.customerid = CT.customerid' ) ; SQL 次のスクリーンショットは私たちの出力結果です。 変更トラッキングバージョンに基づいて、ソースの変更済みレコードを正常にクエリしました。ソリューションを自動化するには、変更トラッキングバージョンを保存する必要があります。変更トラッキングバージョンをアンカーテーブルと呼ばれる別のテーブルに保存できます。これにより、前回の同期以降の変更のみを取得できます。 ターゲットにアンカーテーブルを作成 リンクサーバーを使用してソースのレコードを照会した後、ターゲットにアンカーテーブルを作成します。ここでは、次のコマンドを使用して Northwind データベース内に CT_ANCHOR_NORTHWIND という名前のテーブルを作成します。このテーブルはアンカーとして機能し、データがレプリケーションされるたびに変更トラッキングバージョン番号を保持します。 CREATE TABLE ct_anchor_northwind ( sch_name varchar ( 256 ) , tbl_name varchar ( 256 ) , ct_fetched_ver int , -- 0 during first execution ct_next_ver int -- current version at the source database , to fetch next version of the records ) SQL アンカーテーブルを作成した後、追跡する各テーブルの行を挿入します。ここでは、Northwind データベースの customers テーブルのスキーマ名、顧客名、取得した変更追跡バージョン、次の変更トラッキングバージョンの値を挿入します。 insert into ct_anchor_northwind ( sch_name , tbl_name , ct_fetched_ver , ct_next_ver ) values ( 'dbo' , 'customers' , 0 , 0 ) SQL 次のスクリーンショットは私たちの出力結果です。 各レプリケーションでは、CT_NEXT_VER カラムを手動またはスクリプトを使用して変更トラッキングテーブルの現在のバージョン ID で更新する必要があります。この値を使用して、次の変更されたレコードのセットを取得できます。 次の図は、各同期中にバージョン番号を維持する方法を説明しています。 ソースからデータの変更部分を抽出してターゲットテーブルにロード ソースの SQL Server とターゲットの Babelfish for Aurora PostgreSQL 間でデータを同期するには、次の手順を実行します。これらの手順はスケジュールに従って実行することもできます。 ターゲットデータベースに接続し、アンカーテーブル (ct_northwind_anchor) から ct_next_ver( 次にレコードを取得するバージョン ) の値を @ct_next_ver という変数に取得します。 declare @ct_next_ver varchar ( 9 ) SELECT @ct_next_ver = ct_next_ver FROM ct_anchor_northwind WHERE sch_name = 'dbo' and tbl_name = 'customers' print @ct_next_ver -- result: 0 SQL 変数 @ct_src_current_ver にソースからの現在の変更トラッキングバージョンを取得します。ターゲットでリンクサーバーのクエリを使用して値を取得できます。 declare @ct_src_current_ver varchar ( 9 ) SELECT @ct_src_current_ver = src_current_ver FROM OPENQUERY ( ls_northwind , 'select change_tracking_current_version () as src_current_ver from northwind.sys.change_tracking_tables' ) print @ct_src_current_ver -- result: 10 SQL ソーステーブルの変更された行の主キー値に一致するターゲットのレコードを、特定の変更トラッキングバージョン (@ct_next_ver) に基づいて削除します。 DELETE FROM [dbo].[customers] from [dbo].[customers] x JOIN ( SELECT * from openquery(ls_northwind,'select x.[customerid] FROM [northwind].[dbo].[customers] x JOIN changetable(changes [northwind].[dbo].[customers],0) as y on x.[customerid]=y.[customerid] ')) y on x.[customerid]=y.[customerid] ; -- result : 2 rows affected SQL 特定の変更トラッキングバージョン (@ct_next_ver) に基づいて、ソースから新しいレコードを抽出し、それらの宛先に配置します。 INSERT INTO [dbo].[customers]([customerid],[companyname],[contactname],[contacttitle],[address],[city],[region],[postalcode],[country],[phone],[fax]) SELECT * FROM OPENQUERY(ls_northwind,'select x.[customerid], x.[companyname], x.[contactname], x.[contacttitle], x.[address], x.[city], x.[region], x.[postalcode], x.[country], x.[phone], x.[fax] from [northwind].[dbo].[customers] x join changetable(changes [northwind].[dbo].[customers],0) as y on x.[customerid]=y.[customerid] ') -- result: 2 rows affected SQL アンカーテーブルの列の値を適切な値で更新してください。これらの値は次の実行時に次のセットを取得するために使用されます。 UPDATE ct_anchor_northwind SET ct_fetched_ver = @ct_next_ver , ct_next_ver = @ct_src_current_ver WHERE sch_name = 'dbo' and tbl_name = 'customers' SQL ターゲットテーブルの値をソースと照合して、同期を確認してください。 SELECT * FROM customers WHERE customerid = 'alfki' SQL クリーンアップ 今後の課金を避け、このユースケースのテスト中に作成されたコンポーネントを削除するには、以下の手順を実行してください。 SSMS を使用して、ソースの SQL Server インスタンスに接続します。 マスターデータベースを選択し、[新しいクエリ] を選択します。 次のコマンドを実行してください。 Drop database Northwind GO SQL まとめ この投稿では、リンクサーバーを使用した変更トラッキングによって、SQL Server データベースを Babelfish for Aurora PostgreSQL に移行する方法を示しました。この構成により、最小のダウンタイムで SQL Server ワークロードを Babelfish for Aurora PostgreSQL に移行できます。このソリューションは、スクリプトをスケジュールされたジョブとして実行することで自動化できます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Chandra Pathivada は、アマゾン ウェブ サービスのシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS for PostgreSQL や Amazon Aurora PostgreSQL などのオープンソースデータベースエンジンを中心に Amazon RDS チームで働いています。AWS 上でリレーショナルデータベースワークロードを設計、デプロイ、最適化するお客様をサポートすることを楽しんでいます。 Minesh Chande は、アマゾン ウェブ サービスのシニアデータベーススペシャリストソリューションアーキテクトです。彼は様々な業界のお客様が SQL Server のワークロードを Amazon RDS、Amazon RDS Custom、Babelfish for Aurora PostgreSQL などのマネージドデータベースプラットフォームに設計、移行、最適化するのを支援しています。

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

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

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

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

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

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