本ブログは、IQVIA サービシーズ ジャパン合同会社 と Amazon Web Services Japan が共同で執筆しました。 IQVIA は、データ・テクノロジー・高度な分析・ 専門性を駆使することにより、 ヘルスケアや人々の健康の進展に取り組むお客様をご支援するグローバルリーディングカンパニーです。 お客様とともに、 近代的なそして効果的かつ効率的なヘルスケアシステムの実現を重ねていくことによって、 ビジネスと患者さんの治療アウトカムを変革する画期的なソリューションを生み出しています。 抱えていた課題 IQVIA サービシーズ ジャパンでは、臨床試験や市販後調査（PMS）、医薬品関連文書の作成等の業務において、日本における医薬品の臨床試験の実施の基準に関する省令や治験業務を行う上での規制のように一般に公開されているドキュメントの内容を確認する必要がたびたび発生します。それらの症例や規制の内容について疑問がある場合にはガイドブックやウェブで公開されている情報を元に手作業で調査を行っていましたが、この調査に時間がかかることが課題になっていました。 また、実際の薬品の開発のプロセスで行われる臨床試験のプロジェクトの中でも情報の検索・調査が課題になっていました。 プロジェクトには、臨床試験が適切に実施されているかを監視する役割である臨床開発モニターが大規模なプロジェクトで数十人といった規模で参加します。そのプロジェクトの中で行われた質疑応答については、Q&A の形で社内に蓄積しておき、臨床開発モニターがその Q&A を調べることでプロジェクトに関する情報を確認することがあります。ただし、この Q&A は膨大な数になるため人手での調査には多くの時間を消費しており、平均して 月合計 204 時間を費やしていました。 上述のように多数の業務中の情報確認のための検索・調査に費やす時間が多大にかかっていることに加えて、人によって必要な情報にたどり着くまでのスキルに差異があり、慣れていないメンバーではかなりの時間をこの調査にかけてしまっている場合もありました。 ソリューション 調査効率の向上のために、IQVIA サービシーズ ジャパンでは Amazon Bedrock のナレッジベースを用いた RAG(Retrieval-Augmented Generation) ベースの AI チャットソリューションを構築しました。Amazon Bedrock のナレッジベースは、データソースへのカスタム統合を構築してデータフローを管理することなく、取り込みから取得、迅速な拡張まで、RAG ワークフロー全体を実装するのに役立つフルマネージド機能です。 IQVIA サービシーズ ジャパンでは、少人数でこの RAG チャットの開発・運用を行う必要がありそれらのコストを小さくしたいと考えていました。そのため、はじめは自前で RAG チャットの実装を試していましたが、ドキュメントのチャンキングとインデクシングといったデータの準備からベクトルデータベースと LLM との連携をマネージドに実現することができる Bedrock ナレッジベースを採用しました。ひとまとまりの Q&A 形式のファイルを Q&A 単位で分割し質問と回答が対応するかたちで入力すると言った簡易な加工はありつつも、フィルターなどの Bedrock ナレッジベースのネイティブ機能でほとんどの要件を達成しています。また、このソリューションは AWS Amplify や AWS Lambda、Amazon DynamoDB といった フルサーバレスな構成を採用しており、運用負荷をおさえたものになっています。 IQVIA サービシーズ ジャパンではこの RAG ソリューションの検証と構築を担当者 １ 名のみで実施し、約 2 ヶ月という期間で実現しました。 導入効果 この RAG チャットソリューションを IQVIA サービシーズ ジャパン 全体に広く導入し、約 2 ヶ月で社内ユーザー 321 人を達成しました。また月あたりの検索・調査に費やしていた時間を 93 % 削減することを実現されました。 その他にも調査の苦手なメンバーでも効率的に調査を実施することが可能になり、検索結果の品質向上や均質化した答えが得られることも導入効果として挙げられています。 社内からは今回導入された部署以外でも利用したいという要望が多数あげられており、ソリューションの拡大を検討されています。現在は各部署でデータの投入部分をはじめ運用の一部を担ってもらえるようなサービスの拡張に取り組んでいます。 開発担当者の上長からも、「作成物のイメージがあれば、柔軟性高く、迅速に開発が可能で、マネージドサービスのおかげで限られたリソースでも対応できたので満足しています。また、今回の RAG チャットの開発費用に関しても想像以上に安く抑えられました。」というフィードバックをいただいています。 まとめ Amazon Bedrock のナレッジベースを用いて開発・運用コストを最適化したRAG チャットソリューションを短期間で構築された IQVIA サービシーズ ジャパン 合同会社の取り組みについてご紹介しました。 同社では、この取り組み以外にも AWS の先進的なテクノロジーと 生成 AI を活用し、より広いユーザーへ向けた新たなサービスを展開されることを検討しています。ぜひ続報をお待ちください。

こんにちは！アマゾンウェブサービスジャパン合同会社で製造業のお客様を支援しているソリューションアーキテクトの村松、吉川、シニア事業開発マネージャーの和田です。 2024年10月3日に製造業向けオンラインセミナー「製品・サービスのスマート化 〜モノ / コトの壁とその解決手法 〜」を開催しました。セミナーの開催報告として、ご紹介した内容や、当日の資料・収録動画などを公開します。 製造業のお客様にとって、自社製品のスマート化や自社ソフトウェアの SaaS 化により、モノ売りからコト売りへ変革していくことが求められています。しかし、コト売りへの変革においては、システムだけでなく、組織、人材、開発プロセス、販売方法、KPIなど様々な変革の壁が存在します。 当セミナーでは、自社製品やソリューションのサービタイゼーションを検討 / 実施されているお客様に、実現するために課題となる部分のご説明や解決のための方法、お客様事例のご紹介を行いました。 どうぞ皆様の事業のご参考に、各講演者の録画/資料をご活用下さい。 サービタイゼーションの壁とその克服のヒント 登壇者：アマゾン ウェブ サービス ジャパン合同会社 シニア事業開発マネージャー 和田 健太郎 動画： 資料リンク コト売りにおいてはソリューションを素早く立ち上げ、かつ立ち上げたソリューションを継続的に改善することが重要です。しかし、コト売りへの変革において製造業のお客様は様々な課題に直面していらっしゃいます。Amazon ではイノベーションを起こすためには、組織、アーキテクチャ（システム）、メカニズム、企業文化の4つの要素が重要と捉えていますが、モノ売りとコト売りではこれらの4つの要素に大きな違いがあり、それらが「壁」としてコト売りへの変革を妨げています。 本セッションでは、これらの壁としてどのようなものがあるかをご紹介しつつ、製造業に求められる変革のヒントをご説明致しました。システム面でのクラウドの活用は前提として、組織/機能、KPI等の変革を合わせて進めて頂くことが重要です。 また、これらの変革に取り組まれているお客様の事例と、AWSのご支援内容をご紹介させて頂きました 製造業がデータビジネスはじめるってよ 登壇者：古野電気株式会社 IＴ部長 峯川 和久 様 動画： 資料リンク 古野電気様は魚群探知機や商船レーダーなど船舶電子機器で世界的に高いシェアをお持ちのグローバルメーカーです。本セッションでは IT部 峯川様から「製造業がデータビジネスをはじめる課題」について、自らが率いて古野電気様にデータビジネス基盤を立ち上げた理由、チャレンジ、ソリューションを語っていただきました。古野電気様は売上の７割を海の上のビジネスが占めます。マリンビジネスでの高いシェアを背景に、”Ocean 5.0”として「海との共存共栄」をテーマに新規ビジネスとして、漁業支援、養殖、自律航行、医療などの領域でのサブスク型のデータビジネスに取り組んでいます。 製造業がデータビジネスを推進する上で、３つの壁に直面します。（１）データビジネスの創出プロセスの違い：モノ売り（提供価値最大化）とデータビジネス（価値創造継続）では顧客との関わり方が全く異なリます。（２）マネジメント／人財戦略：メーカーの考えはトップダウン・リスク回避・スキル特化人財ですが、データビジネスではボトムアップ・チャレンジ重視・コミュ力多様性人財が重視されます。（３）採算管理／投資計画：メーカーは個別原価計算志向ですが、データビジネスでは一つのデータがさまざまなビジネスに利用されるためバスケット志向の損益管理が求められます。 これらの壁に対して峯川様は（１）創出プロセスのための「場」を作る。そのための「データ基盤」を整備する。（２）マネジメント／人財戦略としてサッカーフォーメーション型の組織運営。（３）採算管理／投資計画上「データ基盤」を１つに集約しそこでしっかり固定費管理をする。これらが重要と唱えられました。これを実現するために必要な「データプラットフォームの要件」を定義し、それを実現するデータ基盤「JuBuRaw（ジャブロー）」を AWS 上に構築されました。JuBuRaw はデータカタログ管理に Amazon DataZone を先進的に採用し、スピーディな開発のために AWS の Professional Service を活用されました。 高いデータビジネスのための壁を乗り越えるための古野電気様の取り組みはぜひ動画をご覧ください。 峯川様は日本のメーカーの維持とプライドと伝統を死守しつつデータプラットフォームを使いこなすことで企業成長を実現できると今後の抱負を語られました。 「お客様の声から学ぶ」製品・サービスの継続的改善と 生成 AI 活用の可能性 登壇者：横河電機株式会社 デジタル戦略本部 山下 純子 様 横河電機様は計測、制御、情報技術を基盤に多様な製品やソリューションを提供しています。安全で高品質な製品やサービスを提供することで、お客様の課題解決に貢献し、長期的なパートナーシップを築く取り組みを進めています。デジタル戦略本部山下様はコーポレート部門として社内の事業部メンバーと協業してデータ活用による社員生産性向上やお客様への価値向上に取り組んでいます。このセッションでは、製品に関わるデータの分析を行い製品・サービス改善を実現した事例や、組織横断的にデータを活用するまでに乗り越えた課題についてご紹介頂きました。また、生成AIを組み込むことで今後の更なる進化の可能性についても語って頂きました。 山下様の部門では、データ活用を推進していく上で、お客様に近いビジネス部門との協力を重要視しています。一方で、非 IT 人材におけるデータ・ドリブンマネジメントに対するスキルを持った人材育成・データ活用文化の強化を行なっていく必要があります。デジタル戦略本部では、BI ツールセミナーやデータリテラシートレーニングなどを全社に提供し、数百名から数千名規模の人材教育を行っています。更に、ただ受講するだけでなく、実践的なデータ活用まで踏み込んで改善の支援を進めています。結果として数億円規模のコスト効果を示すことができています。 また、生成 AI の活用にも言及されています。IT 部門として、Knowledge を蓄積するストレージ を用意できていても、それを活用するということができていないのが課題です。Knowledge データについて、特にコールセンターやアンケートのようなお客様の声を理解して活動するために、これまで NLP (自然言語処理) 技術を取り入れてデータ分析を進めてきました。しかし、大量のデータから意味のあるデータを抽出するためには、不要なデータを掻き分けていく前処理が必要になります。これに対して生成 AI によってお客様の声から重要なキーワードの抽出を行うことで、従来よりも容易に期待した精度が出せることが明らかになりました。また、PoC の際にご利用頂いた Amazon Bedrock について、安価で且つ手軽に使用でき、既存のデータ活用基盤からの拡張も容易に実現できた、といったご評価を頂いております。 「LOGINECT」で挑む、物流クライシスに向けたTOPPAN物流DXの取り組みのご紹介 登壇者：TOPPANデジタル株式会社 事業開発センター LOGINECT事業開発部 物流システム開発T 係長 武 孝 様 動画： 資料リンク TOPPAN デジタル様は DX 事業推進のコンセプトとして、Erhoeht-X を掲げられ、「製造・流通 DX」をはじめとした 5 つのカテゴリーを重点的に事業拡大を行っていらっしゃいます。各事業はサイクル型ビジネスモデルを軸に展開していて、導入だけにとどまらず、BPO、データ分析、コンサルティング領域を通して付加価値の実現を推進されています。 物流 DX においては、「LOGINECT」というソリューションを提供され、人的リソース不足の課題に対し、「倉庫 DX」と「配送 DX」の2つのサービス基軸で次世代の物流エコシステム構築を目指されています。 本講演では LOGINECT の中でも「LOGINECT 可視化・分析サービス」に関して、個社対応システムから SaaS 化への展開に際して、ぶつかった複数の壁とそれらをどのように乗り越えたかについてお話いただきました。 まず、個社対応システムにおいては、「リソースに限界があり、ビジネスの拡大が困難」という壁に対して、「共通ソリューションを SaaS 化する」という方法でビジネス拡大を目指されました。しかし、SaaS 化した後は、「手動デプロイによる横展開時のスピード感の遅れ」「お客様ごとに異なるデータ形式に合わせた加工作業が発生」という新たな壁に直面されます。これらに対しては、「インフラを AWS リソースで完結することで Terraform を活用」「AWS Glue の活用でデータ構造の違いを吸収」「社内クラウド専門部隊構築」などの施策で解決を試みられています。 また、LOGINECT は「可視化・分析サービス」以外にも様々なソリューションを提供されていますが、昨今では様々なソリューションのインテグレーションやグローバル展開にも挑まれていらっしゃいます。講演の後半ではこれらの取り組みを進めるチームの役割や、新規ソリューションの内容、チャンレンジについてもお話頂きました。 スマートプロダクトビジネスを最大化する生成 AI 活用アーキテクチャ 登壇者：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 村松　謙 動画： 資料リンク イベント最後のセッションでは、AWS よりスマートプロダクトにおける生成AI活用で克服すべき課題や解決するためのアーキテクチャ・AWS サービスをご紹介しました。 スマートプロダクトにおいては、ユーザーの声に迅速に応えてタイムリーに継続的に製品をリリースする必要があります。さらに、生成 AI の普及によってユーザーの声の分析や活用がさらに民主化されていき、あらゆる側面で顧客の声が活用されるようになっていくことで、改善のスピードが高速化されていきます。スマートプロダクトは、あらゆるフェーズで生成 AI を活用するユースケースがありますが、その中でも今回は Voice of Customer の活用・改善による顧客価値の向上にフォーカスしてお伝えさせて頂きました。 顧客価値を向上させるため、スマートプロダクトビジネスにおける Voice of Customer データの種類や、活用者となるステークホルダーの実現したい内容・KPI をご紹介しました。下の図のように、生成AIの登場により、大規模言語モデルを通じてより人間に近い推論能力を実現し、かつ自然言語による指示・質問をすることで、言語処理を簡単に実現することができるようになりました。本セッションでは、営業・マーケティング部門と保守・カスタマーサポート部門における課題と生成 AI の具体的なケイパビリティ・お客様事例をご紹介しました。 後半では、Voice of Customer データの分析を行なっていくにあたっての 3 つの課題 (品質・データコラボレーション・検索性) と AWS サービスによる改善方法についてご紹介しました。 最後に、生成 AI の活用をこれから始めていくお客様や使い始めていくにあたって不安があるお客様に向けて、コストや後戻りを最小限にして徐々にデータ・生成 AI 活用を始めていくアプローチや、AWS からご提供させて頂く支援プログラムのご紹介をしました。 おわりに 本セミナーでは、製造業のお客様が自社製品のスマート化や自社ソフトウェアの SaaS 化により、モノ売りからコト売りへ変革していくために乗り越えるべき壁や、その克服のヒントをご紹介し、実際にサービタイゼーションを実現されたお客様の事例と体験談を共有いただきました。また、スマートプロダクトにおける生成 AI の活用方法についてもご紹介させて頂きました。 本ブログは、事業開発マネージャーの和田健太郎、ソリューションアーキテクトの村松謙、吉川晃平が執筆しました。

この記事は、 OpenSearch optimized instance (OR1) is game changing for indexing performance and cost を翻訳したものです。 Amazon OpenSearch Service は、アプリケーション監視、ログ分析、オブザーバビリティ、Web サイト検索などのユースケースで、ビジネスデータや運用データのリアルタイム検索、監視、分析を安全に実現にします。 この記事では、 2023 年 11 月 29 日に導入された 、OpenSearch 最適化インスタンスである OR1 について検討します。 OR1 は Amazon OpenSearch Service のインスタンスタイプで、大量のデータを保存するためのコスト効率の高い方法を提供します。OR1 インスタンスを使用するドメインでは、 Amazon Elastic Block Store (Amazon EBS) ボリュームをプライマリストレージとして使用し、データが書き込まれるとすぐに Amazon Simple Storage Service (Amazon S3) に同期的にコピーされます。OR1 インスタンスは、高い耐久性と共に、インデクシングのスループットも向上します。 OR1 の詳細については、 紹介ブログ記事 をご覧ください。 インデックスに対して書き込みを行っている間は、レプリカを 1 つ維持することをお勧めします。ただし、ロールオーバー後にインデックスに対する書き込みが行われなくなった後は、レプリカを 0 に切り替えることができます。 これは、データが Amazon S3 に永続化されているため、安全に行えます。 ノードの障害と交換が発生した場合、データは Amazon S3 から自動的に復元されますが、修復操作中は一部のデータアクセスができなくなるため、アクティブに書き込まれていないインデックスの検索に高可用性が必要な場合は、レプリカを 0 にしないでください。 ゴール このブログ記事では、OR1 が OpenSearch ワークロードのパフォーマンスにどのような影響を与えるかを探ります。 OR1 インスタンスは、セグメントレプリケーションを提供することで、プライマリシャードでのみインデックス作成を行うため、CPU サイクルを節約できます。これにより、ノードは同じ計算リソースで、より多くのデータをインデックス化できるか、インデックス作成に使用するリソースを減らし、検索やその他の操作に使えるリソースを増やすことができます。 この記事では、インデックス作成の負荷が高いワークロードを想定し、パフォーマンステストを行います。 従来、 Amazon Elastic Compute Cloud (Amazon EC2) の R6g インスタンスは、Amazon EBS ストレージに依存するインデックス作成の負荷が高いワークロードに適した高性能な選択肢でした。Im4gn インスタンスは、高スループットと低レイテンシーのディスク書き込みに向いた、ローカル NVMe SSD を提供します。 この記事の範囲では、インデクシングのパフォーマンスのみに焦点を当て、OR1 のインデクシング性能を、これら 2 つのインスタンスタイプと比較します。 設定 パフォーマンステストでは、次の図に示すように複数のコンポーネントを設定しました。 テストプロセスについては以下の通りです: AWS Step Functions は、環境のクリーンアップとインデックスマッピングのセットアップ、およびバッチテストの実行のための初期化ステップを調整します。 AWS Batch は、OpenTelemetry JSON 形式のログデータをインデックス化するための並列ジョブを実行します。 ジョブは、 OpenSearch Rust Client と AWS Identity and Access Management (IAM) 認証を使用して、ランダム化されたログを生成するカスタム Rust プログラムを実行します。 OpenSearch Service ドメインは、OpenSearch 2.11、2 つのアベイラビリティーゾーン、きめ細かいアクセス制御、 AWS Key Management Service (AWS KMS) による保存時の暗号化、TLS による転送時の暗号化で設定されています。 インデックスマッピングは、初期化ステップの一部で、次のようになります。 { "index_patterns": [ "logs-*" ], "data_stream": { "timestamp_field": { "name": "time" } }, "template": { "settings": { "number_of_shards": , "number_of_replicas": 1, "refresh_interval": "20s" }, "mappings": { "dynamic": false, "properties": { "traceId": { "type": "keyword" }, "spanId": { "type": "keyword" }, "severityText": { "type": "keyword" }, "flags": { "type": "long" }, "time": { "type": "date", "format": "date_time" }, "severityNumber": { "type": "long" }, "droppedAttributesCount": { "type": "long" }, "serviceName": { "type": "keyword" }, "body": { "type": "text" }, "observedTime": { "type": "date", "format": "date_time" }, "schemaUrl": { "type": "keyword" }, "resource": { "type": "flat_object" }, "instrumentationScope": { "type": "flat_object" } } } } } データストリーム を使用して、ロールオーバー構成を簡素化し、 ベストプラクティス に従って、プライマリシャードのサイズを 50 GiB 以下に抑えています。 不要なインデクシングアクティビティを回避し、 flat_object フィールドタイプを使用して フィールドマッピングの爆発 を回避するようにマッピングを最適化しました。 参考までに、使用した Index State Management (ISM) ポリシーは以下の通りです。 { "policy": { "default_state": "hot", "states": [ { "name": "hot", "actions": [ { "rollover": { "min_primary_shard_size": "50gb" } } ], "transitions": [] } ], "ism_template": [ { "index_patterns": [ "logs-*" ] } ] } } 平均ドキュメントサイズは 1.6 KiB で、バルクサイズは 1 バルクあたり 4,000 ドキュメントのため、1 バルクあたり約 6.26 MiB (非圧縮時) になります。 プロトコルのテスト プロトコルのパラメータは次のとおりです。 データノードの数: 6 または 12 ジョブの並列処理数: 75、40 プライマリシャード数: 12、48、96 (12 ノードの場合) レプリカの数: 1 (合計 2 コピー) インスタンスタイプ (それぞれ 16 vCPU): or1.4xlarge.search r6g.4xlarge.search im4gn.4xlarge.search Cluster Instance type vCPU RAM JVM size or1-target or1.4xlarge.search 16 128 32 im4gn-target im4gn.4xlarge.search 16 64 32 r6g-target r6g.4xlarge.search 16 128 32 im4gn クラスターのメモリ容量は他の 2 つの半分ですが、それでも各環境の JVM ヒープサイズはおよそ 32GiB で同じです。 パフォーマンステストの結果 パフォーマンステストでは、最初にクライアントごとに 75 の並列ジョブと 4,000 ドキュメントの 750 バッチ (合計 2 億 2,500 万ドキュメント) から始めました。その後、シャード数、データノード数、レプリカ数、ジョブ数を調整しました。 構成 1 : 6 データノード、12 プライマリシャード、1 レプリカ この構成では、データノードを 6 つ、プライマリシャードを 12 個、レプリカを 1 つ使用しました。そして、次のようなパフォーマンスを観測しました。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 65-80% 24 分 156 kdoc/s 243 MiB/s im4gn-target 89-97% 34 分 110 kdoc/s 172 MiB/s r6g-target 88-95% 34 分 110 kdoc/s 172 MiB/s この表で強調表示されているように、im4gn クラスターと r6g クラスターの CPU 使用率が非常に高く、 アドミッションコントロール がトリガーされ、ドキュメントが拒否されています。 OR1 は、CPU 使用率が 80% 未満で持続していることを示しており、これは非常に良いターゲットです。 注意すべき点 : 本番環境では、エクスポネンシャルバックオフを使ってインデクシングを再試行し、一時的な拒否によるドキュメント欠落が起きないようにしてください。 バルクインデクシング操作は 200 OK を返しますが、一部失敗する可能性があります。すべての文書が正常にインデックスされたことを確認するには、レスポンスの本文をチェックする必要があります。 並列ジョブの数を 75 から 40 に減らしながら、クライアントごとに 4,000 ドキュメントの 750 バッチ (合計 120M ドキュメント) を維持すると、次のようになります。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 25-60% 20 分 100 kdoc/秒 156 MiB/秒 im4gn-target 75-93% 19 分 105 kdoc/秒 164 MiB/秒 r6g-target 77-90% 20 分 100 kdoc/秒 156 MiB/秒 スループットと CPU 使用率は減少しましたが、Im4gn と R6g の CPU 使用率は高い状態が続いており、一方で OR1 には余剰の CPU 容量があることがわかります。 構成 2 : 6 データノード、48 プライマリシャード、1 レプリカ この構成では、プライマリシャードの数を 12 から 48 に増やしました。これにより、インデックス作成のための並列処理能力が向上します。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 60-80% 21 分 178 kdoc/s 278 MiB/s im4gn-target 67-95% 34 分 110 kdoc/s 172 MiB/s r6g-target 70-88% 37 分 101 kdoc/s 158 MiB/s OR1 のインデックス処理スループットは向上しましたが、Im4gn と R6g は CPU 使用率がまだ非常に高いため、改善は見られませんでした。 並列ジョブを 40 に減らし、プライマリシャードを 48 に保ったところ、OR1 の最小 CPU が 12 のプライマリシャードから増加し、やや負荷がかかることがわかります。一方で、R6g の CPU 使用率は大幅に改善されました。しかし Im4gn の CPU 使用率はまだ高い状態です。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 40-60% 16 分 125 kdoc/s 195 MiB/s im4gn-target 80-94% 18 分 111 kdoc/s 173 MiB/s r6g-target 70-80% 21 分 95 kdoc/s 148 MiB/s 構成 3 : 12 データノード、96 プライマリシャード、1 レプリカ この構成では、元の構成から始め、コンピューティング能力を増強しました。ノード数を 6 から 12 に増やし、プライマリシャード数を 96 に増やしました。 クラスター CPU 使用率 所要時間 インデックス作成速度 or1-target 40-60% 18 分 208 kdoc/s 325 MiB/s im4gn-target 74-90% 20 分 187 kdoc/s 293 MiB/s r6g-target 60-78% 24 分 156 kdoc/s 244 MiB/s OR1 と R6g は CPU 使用率が 80% 未満で良好なパフォーマンスを発揮しています。OR1 は R6g と比較して CPU 使用率が 30% 少なく、パフォーマンスが 33% 優れています。 Im4gn は CPU 使用率が 90% のままですが、パフォーマンスも非常に良好です。 並列ジョブの数を 75 から 40 に減らすと、次のようになります。 クラスター CPU 使用率 所要時間 インデックス作成速度 or1-target 40-60% 11 分 182 kdoc/s 284 MiB/s im4gn-target 70-90% 11 分 182 kdoc/s 284 MiB/s r6g-target 60-77% 12 分 167 kdoc/s 260 MiB/s 並列ジョブの数を 75 から 40 に減らすと、OR1 と Im4gn インスタンスが同等になり、R6g も非常に近くなりました。 解釈 OR1 インスタンスは、レプリカがセグメントのコピーによって生成されるため、プライマリシャードのみを書き込めばよいため、インデックス作成を高速化します。Img4n インスタンスや R6g インスタンスと比較して高性能にも関わらず、CPU 使用率も低いため、追加の負荷 (検索) やクラスターサイズの削減の余地があります。 6 ノードの OR1 クラスターで 48 個のプライマリシャードを持ち、秒あたり 178,000 ドキュメントをインデックス化するのと、12 ノードの Im4gn クラスターで 96 個のプライマリシャードを持ち、秒あたり 187,000 ドキュメントをインデックス化するのと、12 ノードの R6g クラスターで 96 個のプライマリシャードを持ち、秒あたり 156,000 ドキュメントをインデックス化するのを比較できます。 OR1 は、より大きな Im4gn クラスターとほぼ同等のパフォーマンスを発揮し、より大きな R6g クラスターよりも優れたパフォーマンスを示します。 OR1 インスタンスを使用する場合のサイズ設定方法 結果から分かるように、OR1 インスタンスはより高いスループット率でデータを処理できます。しかし、プライマリシャードの数を増やすと、リモートバックドストレージのためにパフォーマンスが低下します。 OR1 インスタンスタイプから最高のスループットを得るには、通常より大きなバッチサイズを使用し、Index State Management (ISM) ポリシーを使ってサイズに基づきインデックスをロールオーバーすることで、インデックスごとのプライマリシャードの数を効果的に制限できます。また、OR1 インスタンスタイプはより多くの並列処理を処理できるため、接続数を増やすこともできます。 検索に関しては、OR1 はパフォーマンスに直接影響しません。しかし、図から分かるように、OR1 インスタンスの CPU 使用率は Im4gn インスタンスや R6g インスタンスよりも低くなっています。これにより、より多くのアクティビティ (検索やインジェスト) を実行できるか、インスタンスのサイズやカウントを削減して、コストを削減できる可能性があります。 OR1 の結論と推奨事項 新しい OR1 インスタンスタイプは、他のインスタンスタイプよりも強力なインデックス作成機能を提供します。これは、日々バッチ処理でインデックス作成を行う場合や、高い持続的なスループットを必要とする場合など、インデックス作成の負荷が高いワークロードにとって重要です。 OR1 インスタンスタイプでは、既存のインスタンスタイプよりもパフォーマンスに対する価格が 30% 優れているため、コスト削減も可能です。複数のレプリカを追加する場合、OR1 インスタンスでは CPU 使用率への影響がほとんどないため、パフォーマンスあたりの価格が下がります。一方、他のインスタンスタイプでは、インデックス処理スループットが低下します。 この repost 記事 を参照して、インデックス作成のためのワークロードの最適化の完全な手順を確認してください。 著者について C é dric Pelvet は AWS プリンシパルソリューションアーキテクトです。リアルタイムデータと検索ワークロードに対するスケーラブルなソリューションの設計をお客様にご支援しています。プライベートでは、新しい言語を学んだり、バイオリンの練習をしています。

この記事は、 Reducing long-term logging expenses by 4,800% with Amazon OpenSearch Service を翻訳したものです。 サーバーログ、サービスログ、アプリケーションログ、クリックストリーム、イベントストリームなどの時間制限のあるデータに Amazon OpenSearch Service を使用する場合、ストレージコストはソリューション全体における主要なコストの 1 つです。昨年、OpenSearch Service では、ログデータを様々な階層に保存できる新機能がリリースされ、データの待機時間、耐久性、可用性のトレードオフが可能になりました。2023 年 10 月、 OpenSearch Service は最大 30TB の NVMe SSD ストレージを備えた im4gn データノードのサポートを発表しました 。2023 年 11 月、 OpenSearch Service は OpenSearch 最適化インスタンスファミリー or1 を導入し 、社内ベンチマークで既存インスタンスに比べ最大 30% のパフォーマンス価格比の改善を実現し、 Amazon Simple Storage Service (Amazon S3) を使用してイレブンナインの耐久性を提供しました。最後に、2024 年 5 月、OpenSearch Service は Amazon OpenSearch Service と Amazon S3 の zero-ETL 統合 の一般提供を発表しました。これらの新機能は、 既存の UltraWarm インスタンス (GB あたりのストレージコストを最大 90% 削減) と、 UltraWarm のコールドストレージ オプション (UltraWarm インデックスを分離し、アクセス頻度の低いデータを Amazon S3 に永続的に保存できる) に加わります。 このポストでは、コスト、レイテンシー、スループット、データの永続性と可用性、保持期間、データアクセスにおける選択肢のトレードオフを理解できるように、例を用いて説明します。これにより、データの価値を最大化し、コストを最小化するための適切なデプロイメントを選択できるようになります。 要件の検討 ロギングソリューションを設計する際は、適切なトレードオフを行う前提条件として、要件を明確に定義する必要があります。レイテンシー、耐久性、可用性、コストに関する要件を慎重に検討してください。さらに、OpenSearch Service に送信するデータ、データの保持期間、そのデータへのアクセス計画を検討する必要があります。 この議論の目的のために、OpenSearch インスタンスのストレージをエフェメラルストレージと Amazon S3 バックドストレージの 2 つのクラスに分けます。エフェメラルドストレージクラスには、Nonvolatile Memory Express SSDs (NVMe SSDs) と Amazon Elastic Block Store (Amazon EBS) ボリュームを使用する OpenSearch ノードが含まれます。Amazon S3 バックドストレージクラスには、UltraWarm ノード、UltraWarm コールドストレージ、or1 インスタンス、および Amazon S3 との Zero-ETL で利用できる Amazon S3 ストレージが含まれます。ロギングソリューションを設計する際は、次の点を考慮してください。 レイテンシ – ミリ秒単位で結果を必要とする場合は、エフェメラルストレージをバックエンドに使用する必要があります。秒または分単位の結果で許容できる場合は、Amazon S3 をバックエンドに使用することでコストを削減できます。 スループット – 一般的に、エフェメラルストレージをバックエンドに使用したインスタンスの方がスループットが高くなります。im4gn のように NVMe SSDs を搭載したインスタンスは通常最高のスループットを提供し、EBS ボリュームも良好なスループットを提供します。or1 インスタンスは、プライマリシャードに Amazon EBS ストレージを利用しながら、 Amazon S3 とセグメントレプリケーション を活用することで、レプリケーションのコンピューティングコストを削減し、NVMe ベースのインスタンスと同等またはそれ以上のインデックス作成スループットを提供します。 データ耐久性 – ホット層 (データノード) に格納されたデータは最も低いレイテンシーですが、耐久性も最も低くなります。OpenSearch Service は、レプリカを通じてホット層のデータの自動復旧を提供し、コストを伴いながら耐久性を確保します。OpenSearch が Amazon S3 (UltraWarm、UltraWarm コールドストレージ、Amazon S3 との zero-ETL、or1 インスタンス) に格納するデータは、Amazon S3 のイレブンナインの耐久性の恩恵を受けます。 データ可用性 – ベストプラクティス では、エフェメラルストレージのデータにレプリカを使用することを推奨しています。少なくとも 1 つのレプリカがあれば、ノードの障害が発生しても、すべてのデータにアクセスできます。ただし、各レプリカはコストの増加を伴います。一時的な利用不可を許容できる場合は、or1 インスタンスと Amazon S3 ストレージを使用することで、レプリカを削減できます。 保持期間 – すべてのストレージ層のデータにはコストがかかります。分析のためにデータを長期間保持するほど、そのデータの 1GB あたりの累積コストが高くなります。すべての価値が失われるまでにデータを保持しなければならない最長期間を特定してください。場合によっては、コンプライアンス要件によって保持期間が制限される可能性があります。 データアクセス – 一般に、Amazon S3 をバックエンドに使用したインスタンスは、コンピューティングに対するストレージの比率がはるかに高く、コスト削減につながりますが、大量のワークロードには十分なコンピューティング能力がありません。クエリ量が多い、またはクエリが大量のデータにまたがる場合は、エフェメラルストレージをバックエンドに使用するのが適切です。ダイレクトクエリ (Amazon S3 ストレージをバックエンドに使用) は、頻繁にクエリされないデータに対する大量のクエリに最適です。 これらの観点から要件を検討すると、その回答が実装の選択肢を導き出すことになります。トレードオフを判断するために、次のセクションで詳細な例を説明します。 OpenSearch Service のコストモデル OpenSearch Service のデプロイのコストを理解するには、コストの特徴を理解する必要があります。OpenSearch Service には、マネージドクラスターとサーバーレスの 2 つの異なるデプロイオプションがあります。この投稿ではマネージドクラスターのみを考慮します。 Amazon OpenSearch Serverless はすでにデータを階層化し、ストレージを管理してくれるためです。マネージドクラスターを使用する場合は、データノード、UltraWarm ノード、専用マスターノードを構成し、それぞれの機能に Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプを選択します。OpenSearch Service はこれらのノードをデプロイ、管理し、REST エンドポイントを介して OpenSearch と OpenSearch Dashboards を提供します。Amazon EBS バックドインスタンスまたは NVMe SSD ドライブ付きインスタンスを選択できます。OpenSearch Service は、マネージドクラスターのインスタンスに対して時間単位の料金を請求します。Amazon EBS バックドインスタンスを選択した場合、サービスはプロビジョニングされたストレージと、構成した プロビジョニング IOPS に対して料金を請求します。or1 ノード、UltraWarm ノード、または UltraWarm コールドストレージを選択した場合、OpenSearch Service は Amazon S3 で消費されたストレージに対して料金を請求します。最後に、 転送されたデータに対するサービス料金 がかかります。 使用例 コストとパフォーマンスのトレードオフを検討するために、使用例を使用します。この例のコストとサイズは、ベストプラクティスに基づいており、方向性を示すものです。同様の節約効果が期待できますが、すべてのワークロードはユニークであり、実際のコストは本記事で示すものとは大きく異なる可能性があります。 架空の大手清涼飲料メーカー Fizzywig のユースケースを見ていきましょう。飲料の製造工場が多数あり、製造ラインからは膨大なログが出力されています。当初はすべてホットデプロイで 1 日 10 GB のログを生成していましたが、今日では 1 日 3 TB のログデータが発生し、経営陣はコスト削減を求めています。Fizzywig はログデータをイベントのデバッグと分析、および 1 年分のログデータの履歴分析に使用しています。OpenSearch Service でそのデータを保存し利用するコストを計算しましょう。 エフェメラルストレージの導入 Fizzywig の現在のデプロイメントは、エフェメラルストレージを備えた 189 個の r6g.12xlarge.search データノード (UltraWarm 層なし) です。OpenSearch Service でデータをインデックス化すると、OpenSearch はインデックスデータ構造を構築し、ソースデータよりも通常 10% 大きくなります。また、運用オーバーヘッドのために 25% の空き領域を残す必要があります。毎日 3TB のソースデータがある場合、オーバーヘッドを含めてプライマリ (最初のコピー) に 4.125TB のストレージが必要になります。Fizzywig は、最大のデータ耐久性と可用性を確保するため、 OpenSearch Service Multi-AZ with Standby オプションを使用して 2 つのレプリカコピーを作成するベストプラクティスに従っています。これにより、1 日あたりのストレージ需要は 12.375TB に増加します。1 年分のデータを保存するには、365 日を掛けて 4.5PB のストレージが必要になります。 このストレージ容量をプロビジョニングするには、im4gn.16xlarge.search インスタンスまたは or1.16.xlarge.search インスタンスを選択することもできます。次の表は、これらのインスタンスタイプごとに、データのコピー数に応じて必要なインスタンス数を示しています。 . ノードあたりの最大ストレージ (GB) Primary (1 Copy) Primary + Replica (2 Copies) Primary + 2 Replicas (3 Copies) im4gn.16xlarge.search 30,000 52 104 156 or1.16xlarge.search 36,000 42 84 126 r6g.12xlarge.search 24,000 63 126 189 前の表と次の説明は、ストレージニーズに厳密に基づいています。or1 インスタンスと im4gn インスタンスの両方とも、r6g インスタンスよりも高いスループットを提供するため、さらにコストを削減できます。計算の節約額は、ワークロードとインスタンスタイプによって 10 〜 40% 異なります。これらの節約は直接利益に反映されるわけではなく、インデックスとシャード戦略のスケーリングと変更を行って初めて実現できます。前の表と後続の計算では、これらのデプロイメントはコンピューティングリソースが過剰にプロビジョニングされており、ストレージに制限があると一般的に想定されています。コンピューティングリソースをさらに拡張する必要がある場合、r6g に比べて or1 と im4gn でより多くの節約が見込めます。 次の表は、指定された 3 つの異なるデータストレージサイズにわたる 3 つの異なるインスタンスタイプの合計クラスターコストを表しています。これらは オンデマンド米国東部 (バージニア北部) AWS リージョンのコスト に基づいており、インスタンス時間、or1 インスタンスの Amazon S3 コスト、および or1 インスタンスと r6g インスタンスの Amazon EBS ストレージコストが含まれています。 . Primary (1 Copy) Primary + Replica (2 Copies) Primary + 2 Replicas (3 Copies) im4gn.16xlarge.search $3,977,145 $7,954,290 $11,931,435 or1.16xlarge.search $4,691,952 $9,354,996 $14,018,041 r6g.12xlarge.search $4,420,585 $8,841,170 $13,261,755 この表は、4.5 PB のワークロードに対する 1 コピー、2 コピー、3 コピーのコスト (該当する場合は Amazon S3 と Amazon EBS のコストを含む) を示しています。この投稿では、「1 コピー」とは、レプリケーション数をゼロに設定した最初のデータコピーを指します。「2 コピー」にはデータのレプリカコピーが含まれ、「3 コピー」にはプライマリと 2 つのレプリカが含まれます。ご覧のとおり、各レプリカはソリューションのコストを倍増させます。もちろん、各レプリカはデータの可用性と耐久性を高めます。1 コピー (プライマリのみ) の場合、単一ノードの障害で (or1 インスタンスを除いて) データを失うことになります。1 つのレプリカがある場合、2 ノードの障害で一部またはすべてのデータを失う可能性があります。2 つのレプリカがある場合、3 ノードの障害でのみデータを失うことになります。 or1 インスタンスはこの規則の例外です。or1 インスタンスは、1 コピーのデプロイをサポートできます。これらのインスタンスは、Amazon S3 をバッキングストアとして使用し、すべてのインデックスデータを Amazon S3 に書き込み、レプリケーションと耐久性を実現します。確認された書き込みはすべて Amazon S3 に永続化されるため、ノードの停止時にデータの可用性を失うリスクはありますが、1 コピーで実行できます。データノードが利用できなくなった場合、通常10~20分程度の復旧時間が必要になり、その間はインデックスが利用できなくなります (ステータスが赤色表示になります)。システム (例: 取り込みパイプラインバッファ) だけでなく、顧客に対してもこの可用性の低下を許容できるかどうかを慎重に評価する必要があります。許容できる場合は、前の表に示されている 1 コピー (プライマリ) の列に基づいて、コストを 1,400 万ドルから 470 万ドルに削減できます。 リザーブドインスタンス OpenSearch Service では、1 年契約と 3 年契約の Reserved Instance (RI) がサポートされています。これには、前払い費用なし (NURI)、一部前払い (PURI)、全額前払い (AURI) があります。すべての RI 契約でコストが下がりますが、3 年契約の全額前払い RI が最も割引率が高くなります。Fizzywig のワークロードに 3 年契約の全額前払い RI の割引を適用した場合の年間コストは、次の表のようになります。 . Primary Primary + Replica Primary + 2 Replicas im4gn.16xlarge.search $1,909,076 $3,818,152 $5,727,228 or1.16xlarge.search $3,413,371 $6,826,742 $10,240,113 r6g.12xlarge.search $3,268,074 $6,536,148 $9,804,222 RI は、コードやアーキテクチャの変更を行うことなく、コストを削減する簡単な方法を提供します。この作業負荷に RI を採用すると、3 コピーの im4gn コストが 570 万ドルに、or1 インスタンスの 1 コピーコストが 320 万ドルになります。 Amazon S3 バックドストレージの導入 前述のデプロイメントはベースラインとの比較のために役立ちます。実際には、コストを管理可能な範囲に抑えるために、Amazon S3 バックドストレージオプションのいずれかを選択するでしょう。 OpenSearch Service の UltraWarm インスタンスは、すべてのデータを Amazon S3 に保存し、UltraWarm ノードをこの完全なデータセットの上の ホットキャッシュ として利用します。UltraWarm は、6 か月前の 1 日分のデータに対して複数のクエリを実行するなど、小さな時間範囲のデータに対する対話型クエリに最適です。アクセスパターンを慎重に評価し、UltraWarm のキャッシュのような動作があなたのニーズに合うかどうかを検討してください。UltraWarm の最初のクエリのレイテンシは、クエリする必要があるデータ量に応じて拡大します。 OpenSearch Service ドメインを UltraWarm 用に設計する際、ホット保持期間とウォーム保持期間を決める必要があります。ほとんどの OpenSearch Service のお客様は、ホット保持期間を 7 ～ 14 日間程度に設定し、ウォーム保持期間で全保持期間の残りを構成しています。Fizzywig のシナリオでは、ホット保持期間を 14 日間、UltraWarm 保持期間を 351 日間に設定しています。また、ホット層では、 2 コピー (プライマリと 1 つのレプリカ) のデプロイを使用しています。 14 日間に必要なホットストレージ (1 日の取り込み量 4.125 TB に基づく) は 115.5 TB です。3 種類のインスタンスタイプのいずれかを 6 つデプロイすれば、このインデクシングとストレージをサポートできます。UltraWarm は Amazon S3 に単一のレプリカを格納し、追加のストレージオーバーヘッドは必要ありません。そのため、351 日間のストレージニーズは 1.158 PiB となります。これは 58 台の UltraWarm1.large.search インスタンスでサポートできます。次の表は、ホット層に 3 年間の AURI を適用したこのデプロイメントの総コストを示しています。or1 インスタンスの Amazon S3 コストは S3 列に含まれています。 . Hot UltraWarm S3 Total im4gn.16xlarge.search $220,278 $1,361,654 $333,590 $1,915,523 or1.16xlarge.search $337,696 $1,361,654 $418,136 $2,117,487 r6g.12xlarge.search $270,410 $1,361,654 $333,590 $1,965,655 さらにコストを削減するには、データを UltraWarm コールドストレージに移行できます。コールドストレージは、データの可用性を下げることでコストを削減します。データを照会するには、対象のインデックスを UltraWarm 層に再アタッチするための API 呼び出しを発行する必要があります。1 年分のデータの典型的なパターンは、14 日間ホット、76 日間 UltraWarm、275 日間コールドストレージです。このパターンに従うと、6 つのホットノードと 13 の UltraWarm1.large.search ノードを使用します。次の表は、Fizzywig の 3TB の日次ワークロードを実行するコストを示しています。Amazon S3 の使用料金は、 UltraWarm ノード + S3 列に含まれています。 . Hot UltraWarm nodes + S3 Cold Total im4gn.16xlarge.search $220,278 $377,429 $261,360 $859,067 or1.16xlarge.search $337,696 $461,975 $261,360 $1,061,031 r6g.12xlarge.search $270,410 $377,429 $261,360 $909,199 Amazon S3 バックドのストレージオプションを利用することで、単一コピーまたは 1 デプロイで 33 万 7,000 ドル、1 インスタンスで最大年間 100 万ドルと、さらにコストを削減できます。 OpenSearch Service の Amazon S3 との zero-ETL 統合 OpenSearch Service zero-ETL for Amazon S3 を使用すると、すべての二次データと古いデータを Amazon S3 に保持できます。二次データとは、VPC フローログや WAF ログなど、直接検査する価値は低い大量のデータです。このようなデプロイメントでは、頻繁にクエリされないデータの大部分を Amazon S3 に保持し、最新のデータのみホット層に保持します。場合によっては、二次データの一部をサンプリングし、ホット層にも一定割合を保持します。Fizzywig は、すべてのデータの 7 日分をホット層に保持することにしました。残りのデータはダイレクトクエリ (DQ) でアクセスします。 ダイレクトクエリを使用する場合、データを JSON、Parquet、CSV 形式で保存できます。Parquet 形式はダイレクトクエリに最適で、データに対して約 75% の圧縮が行われます。Fizzywig は Amazon OpenSearch Ingestion を使用しており、これにより Parquet 形式のデータを直接 Amazon S3 に書き込むことができます。毎日 3 TB のソースデータが 750 GB の Parquet データに圧縮されます。OpenSearch Service はダイレクトクエリ用のコンピューティングユニットのプールを維持しています。これらの OpenSearch コンピューティングユニット (OCU) は時間単位で課金され、アクセスするデータ量に基づいてスケーリングされます。この会話では、Fizzywig がデバッグセッションを行い、1 日分のデータ (750 GB) に対して 50 件のクエリを実行すると想定しています。次の表は、毎日 3 TB のワークロードを 7 日間ホットで、358 日間 Amazon S3 に保存する場合の年間コストの概要を示しています。 . Hot DQ Cost OR1 S3 Raw Data S3 Total im4gn.16xlarge.search $220,278 $2,195 $0 $65,772 $288,245 or1.16xlarge.search $337,696 $2,195 $84,546 $65,772 $490,209 r6g.12xlarge.search $270,410 $2,195 $0 $65,772 $338,377 大変な旅路でした! Fizzywig 社のロギングコストは、年間最高 1,400 万ドルから、Amazon S3 からの zero-ETL によるダイレクトクエリを使用することで年間 28 万 8,000 ドルまで下がりました。これは 4,800% の節約です! サンプリングと圧縮 この投稿では、データサイズに焦点を当て、そのデータへのアクセス方法に応じてトレードオフを行うことができる 1 つのデータフットプリントを見てきました。OpenSearch には、保存するデータ量を削減することで、さらに経済性を変えることができる追加機能があります。 ログワークロードの場合、 OpenSearch Ingestion サンプリングを利用して、OpenSearch Service に送信するデータのサイズを削減 できます。サンプリングは、全体のデータが統計的特性を持ち、一部が全体を代表できる場合に適しています。たとえば、オブザーバビリティワークロードを実行している場合、システムでのリクエスト処理のトレースを代表するサンプリングを取得するために、データの 10% 程度を送信するだけで十分な場合があります。 ワークロードに応じて、 圧縮アルゴリズム を使用することもできます。OpenSearch Service では最近、デフォルトの最高圧縮に比べて、より高い圧縮率と低い伸張待ち時間を実現できる Zstandard (zstd) 圧縮のサポートがリリースされました。 結論 OpenSearch Service を使うことで、Fizzywig は、コスト、レイテンシー、スループット、耐久性と可用性、データ保持、そして好ましいアクセスパターンのバランスを取ることができました。彼らはロギングソリューションのコストを 4,800% 削減することができ、経営陣は大喜びでした。 全体的に見ると、im4gn インスタンスの絶対金額が最も低くなります。ただし、いくつか注意点があります。まず、or1 インスタンスは、特に書き込み集中型のワークロードで、より高いスループットを提供できます。これにより、コンピューティングの必要性が低減され、追加の節約につながる可能性があります。さらに、or1 の高い耐久性により、レプリケーションを減らして可用性と耐久性を維持できるため、コストが削減されます。もう 1 つの検討事項は RAM です。r6g インスタンスは追加の RAM を備えているため、クエリの待ち時間が短縮されます。UltraWarm と組み合わせ、ホット/ウォーム/コールドの比率を変えることで、r6g インスタンスも優れた選択肢となります。 大量のロギングワークロードがありますか? これらの方法の一部またはすべてから恩恵を受けましたか? ご意見をお聞かせください! 著者について Jon Handler は、カリフォルニア州パロアルトに拠点を置く Amazon Web Services のシニアプリンシパルソリューションアーキテクトです。Jon は OpenSearch と Amazon OpenSearch Service を担当し、ベクトル、検索、ログ分析のワークロードを AWS Cloud に移行したいさまざまな顧客に対して支援とガイダンスを提供しています。AWS に入社する前は、ソフトウェア開発者として 4 年間大規模な EC サイトの検索エンジンをコーディングしていました。Jon はペンシルベニア大学で文学士号を、ノースウェスタン大学でコンピューターサイエンスと人工知能の理学修士号と博士号を取得しています。

はじめに 本ブログは、全日本空輸株式会社と Amazon Web Services Japan が共同で執筆しました。 みなさん、こんにちは。 AWS ソリューションアーキテクトの三宅です。 全日本空輸株式会社様では、2021 年よりグループ全社を横断したデータマネジメント基盤として「BlueLake」を整備し、社内のデータ活用の推進に取り組まれています。2024 年 6 月 20日 ～ 21 日に開催された AWS Summit Japan では、全日本空輸株式会社 デジタル変革室 イノベーション推進部 データマネジメントチーム の丸山 様にご登壇いただき、データ活用の取り組みで得たナレッジを 14 の秘伝として紹介いただきました。 本記事は、ANA 様のご登壇内容をブログ記事として再構成したものとなります。 私が所属する ANA デジタル変革室 イノベーション推進部 データマネジメントチームでは主に、ANA を中心としたグループのデータ戦略の策定と、それに沿ったデータ基盤の環境整備と開発管理を行っています。データ活用の推進を担う同部のデータデザインチームや、BlueLake のシステム開発や運用を担うグループ会社の ANA システムズ株式会社とも協力して、ANA のデータ活用を進めています。 ANA グループのかかげる「データの民主化」とは ANA グループのデータの民主化は、グループ ４ 万人の従業員一人一人がデータを自由に扱い、価値を生み出すことができる状態を目指しています。これまでの ANA におけるデータ活用は、各システム部門が中心となって、データの収集から加工・集計・分析し、結果を共有するまでを行ってきました。データの民主化を実現するために、データの収集はシステム部門が行い、それ以降はレベルや目的に応じてシステム部門とビジネス部門が共に手を取り合い、協創しながら実行していくことにしました。データ活用の中心はビジネス部門で推進し、システム部門はそうした取り組みを環境とスキルの両面でサポートします。 ANA のデータの民主化の取り組みは大きく「仕組み」「人財」「ガバナンス」に大別することができます。 まずは「仕組み」として、BlueLake 基盤のアーキテクチャ、データ活用ツールである BlueLake Apps に関する秘伝について 8 つ紹介します。 秘伝 1　データを物理的に 1 箇所に集める戦略 ANA グループは主力ブランドの ANA に加えて、Peach や Air Japan を含めた航空事業を展開しています。また、マイルで買い物ができる EC サイトの ANA Mall やモバイル決済サービスの ANA Pay といった 「ノンエア」 と呼ばれる非航空事業にも注力しており、マイルで生活できる世界の実現に向けて、様々なサービスを提供しています。 BlueLake が立ち上がる前から存在しているデータ基盤は、航空事業に特化した業務別のデータ基盤であったため、データの民主化を推進していくためにも、統合的なデータ基盤を再構築する必要がありました。様々なデータの管理方法があるなか、ANA では物理的にデータを 1 箇所に集約させて、一元管理をしています。個別の業務ごとに特化したシステムから生み出されるデータは、データの型や持ち方、キーなどがそれぞれで異なっています。最近は SaaS を利用することも増えてきており、データは複雑性を増しています。 そのなかで、様々な特性のあるデータを時間の断面でコントロールすることがデータを分析する上で重要であると考え、複数の要素を、固定した時間で横断的に収集し、データとして扱いやすい形で保持できるよう一貫性もったコントロールを行っています。 秘伝 2 プライバシーに配慮した 2 層構造 多くの人が自由にデータを扱えるように、BlueLake では、確実なコンプライアンスのもとでデータを管理する必要がありました。BlueLake ではプライバシーを考慮し、生データを扱う層と仮名加工済みデータを扱う層の 2 層構造でデータを管理しています。具体的なアーキテクチャとしては、Amazon S3 を活用した データレイクと、Amazon Redshift と Snowflake を活用したデータウェアハウスから構成されており、この 2 つの構造をそれぞれ別の AWS アカウントで完全に分離することでデータの管理を行っています。4 万人が自由に使えるデータは主に下図の下の段のデータになっており、仮名加工処理が施されていて、個人情報保護法や GDPR などにも対応しています。完全に分離した 2 層構造によってデータをしっかりと守りつつ、柔軟に活用できる環境を実現しています。 秘伝 3 Amazon S3 を中心としたアーキテクチャ データレイクとして Amazon S3 を採用しています。データ活用に関するトレンドの移り変わりは非常に早いですが、併せて毎回抜本的にアーキテクチャを刷新するのは非常にコストがかかります。そこで私たちは Amazon S3 を中心とすることで、時代や戦略に合わせてサービスの使い分けをしています。Amazon S3 はコネクターも非常に豊富で、DeltaLake や Iceberg といったフォーマットにも対応しています。私たちは AmazonS3 を中心として、様々なサービスを組み合わせながら、目的やスキルレベルに応じたツールを用意しています。 秘伝 4 目的やレベル別に多種なツールを整備 ANA グループの 4 万人の従業員は日々の業務も、データ活用スキルも様々です。こうした人たちが何か 1 つのツールを使ってデータを活用するのは非常に難しいだろうと考え、ANA では現在 6 つの データ活用ツールである BlueLake Apps を整備しています。機微な情報を取り扱う「BlueLake Custo」、データ抽出を行う「BlueLake Exto」、社内基準のレポートを全社に展開する「BlueLake Repo」、セルフ BI ツールの「BlueLake Pivo」、データ実験環境の「BlueLake Labo」、そしてなんでもできる「BlueLake Pro」 の 6 つです。リッチなラインナップにも見えますが、ライセンス課金のツールは利用者を見定めて、従量課金のツールは使いすぎないようにガバナンスを効かせることで、コストを抑えながら運用しています。目的やスキルレベルに応じて使い分けのできるツールを用意することで、データ活用の可能性が広がると考えています。 秘伝 5 4 万人が同じ基準で見られるダッシュボード データを活用する上で、同じ目線でデータを捉えていくことは非常に重要だと考えています。しかし、部門や部署が多いと、独自の集計や分析が行われるため、基準を合わせて物事を進めるのが難しい場面もあります。 そこで、BlueLake Repo は 4 万人が同じ基準で見られるダッシュボードを目指して、Amazon QuickSight を用いて展開しています。展開にあたって工夫したポイントが 2 つあります。1 つは、アカウント作成の部分で、社内が使っているグループウェアの IdP と Amazon Cognito と AWS Lambda を組み合わせて、自動でアカウントが作成される仕組みを構築しました。 2 つ目は、Amazon QuickSight の埋め込み機能を使い、“BlueLake Repo” の名称で社内向けのサービスとして展開したことです。BlueLake Repo では、ユーザーが高度の分析を行うことはありません。そのため、データ活用の第一歩として、利用するハードルをできる限り下げて、誰でも気軽に BlueLake に飛び込んでこれるように工夫しています。 秘伝 6 抽出ツールは必要（現在の答え） データ活用ツールを整理していく中で、データ抽出が分析の目的になることはないため、業務整理を行ってデータ抽出をなくすべきだ、というアドバイスを何度か伺ったことがありました。私自身、もしアドバイスをする立場なら同じことを言うかもしれませんが、実際、データ抽出を無くすのはそう簡単ではありません。これまでの社内のデータ活用の状況を踏まえて、データ抽出をなくすのはまだ早いと判断しました。しかしながら、意外にも抽出に特化したツールというのは世の中にあまりありませんでした。 そこで、AWS のサービスを駆使して、ドラッグ＆ドロップで使える SQL ツールである BlueLake Exto 開発しました。まだこのツールはリリースして間もないため機能も潤沢には備わっていないのですが、 GUI で作成した SQL をレシピとして保存できる機能や、社員同士でレシピを共有できる機能などを開発する予定です。会社ごとに文化や置かれた環境が異なるため、必ずしもデータマネジメント一般論に従う必要はないと考えています。 秘伝 7 ユーザーフレンドリーな”ナレッジの宝庫” 基盤である BlueLake と データ活用ツールの BlueLake Apps 、これらを整備しただけでは、データの民主化はなかなか進みません。BlueLake と BlueLake Apps の橋渡しをするのがデータカタログです。 ANA のデータを活用する 4 万人の従業員が利用することを考えると、データカタログには、とにかくデータも UI も分かりやすいこと、データに関する質問やナレッジを共有できること、そして 4 万人が使えるコストであることが求められました。当時、世の中にはいわゆるデータをよく知る人たちが利用するデータカタログはありましたが、どれも高機能で、私たちの利用目的に合っていませんでした。 そのため、データカタログも AWS のサービスを活用して内製で開発することにしました。それがANA のデータカタログ「Moana」です。無駄な情報は省き、分かりやすい UI にし、南国リゾートを彷彿させる可愛らしい名前にしています。カタログ機能に加えて、社内用語をまとめたディクショナリー機能や社員同士の SNS 機能を搭載し、ANA のデータの民主化を推進する上で欠かせないツールに成長しています。世の中にないものを自分たちで作ることができるのが、AWS の良いところだと思います。 秘伝 8 AWS は自社の世界観を表現できる データの民主化を社内に広めていくことは、マーケティング活動そのものであると考えています。とにかく多くの人に BlueLake を知ってもらう、そして、BlueLake と聞けば、データを便利に使えるプラットフォームであるとイメージしてもらえるようになることが、非常に重要であると考えています。 社内では常に Apps 名でコミュニケーションを行っているため、Apps を製品名で呼ぶ人たちはほとんどいません。レベルに合わせた自分たちの世界観を表現する上でも、AWS のカスタマイズ性の高さは非常に有効であると考えています。 ここからは、データを活用する人「人財」に関する秘伝を 2 つ紹介します。 秘伝 9 多様なチャネルを駆使したコミュニティ ANA ではデータコミュニティを BlueLake DataCircle と名付けて、様々な取り組みを行っています。 コミュニティの特徴として、多様なチャネルを使ってコミュニティ活動を形成していることが挙げられます。具体的には、BlueLake の紹介イベントや、初級者向けにデータの重要性や危険性を伝えるイベントを開催したり、もう少し具体的に興味を持ってもらうために、社内外のデータ活用を行っている人との対談イベントも開催しています。 少し変わった取り組みとして、データドリブン通信というものがあります。データに特化した社内報を我々で作成し、データ活用で知っておいてほしい情報や、社内のデータ活用事例を読みやすくまとめて、グループ全体のポータルサイトで発信しています。 秘伝 10 100 時間を超える内製のデータ教育プログラム 全社に向けた啓発と文化の醸成を目的にしたコミュニティ活動以外にも、実際にデータを扱える人を養成するための活動を内製で行っています。参加希望者はこちらから選ぶのではなく募集し、それぞれが業務での課題やデータ活用の可能性を感じながら教育に取り組みます。そして、その講師は私と同様グランドスタッフ経験者や元整備士で現在データサイエンティストとして社内で活躍しているメンバーが行います。100 時間を超える研修を通じて、データ活用ってこういうことかという勘所と基礎的なスキルを身につけ、業務を理解したデータの専門家となり、各部門で活躍しています。 最後に、「ガバナンス」に関する秘伝を 4 つ紹介します。 秘伝 11 ANA が着目した八つの項目 まず最初にガバナンスに着手した際、DMBOK の輪読から始めました。内容をメンバーで分担しながら理解するところまでは良かったのですが、いざ ANA のガバナンスをまとめるときに困ったのが項目の選定でした。最初からあれもこれもで、絵に描いた餅になってしまっては、ガバナンスをまとめる意味がありません。悩んだ挙句、私たちは 8 つの項目を採用しました。今回は、工夫したガバナンスの一部を紹介します。 秘伝 12 ANA のデータスチュワードは ２ 種類 例えば、上記の項目 2 の「体制と役割」の中では、データスチュワードを定義しています。データスチュワードにも様々なものがありますが、ANA ではまず、BlueLake データスチュワードと、業務データスチュワードの 2 つを定義するところから始めています。BlueLake データスチュワードはデータガバナンス・データマネジメントの視点で、開発・運用を統制しています。業務データスチュワードは社内のデータ利用者からの開発・活用案件を集約し、優先度決め等を行います。双方がデータスチュワードシップ会議にて定期的にコミュニケーションをとることで、ANAのデータのありたい姿を実現させています。 秘伝 13 安全に価値を創出するためのルール グループ 4 万人がデータを活用していく上で欠かせないのが、グループ会社横断でのルールです。「利用料及び契約」の項目では、グループ会社とのデータやツールの利用に関する規定や、個人情報に関する国内外の法令への対応方針を定めています。また、セキュリティやプライバシーに関する教育や啓発にも取り組んでいます。契約や利用料の調整は非常に大変です。しかし、グループ全体でデータによって安全に価値を生み出す上では必要不可欠だと考えています。 秘伝 14 BlueLake DataManagement 最後の秘伝として、ここまでお話しした全ての秘伝は、データ戦略、データマネジメントポリシー、データ利活用ガイドラインの３ 部構成で、BlueLake Data Management として、体系的に文書化してまとめています。ANA ではこの BlueLake データマネジメントに沿って、データの基盤をデザインし、データから価値を生み出す土壌を整備しています。 最後に これら 14 の秘伝は、データの民主化のための手段に過ぎません。そしてデータの民主化自体もまた、目的ではありません。 デジタルとデータを活用したビジネスの変革を通して、ANA をご利用になるお客様の体験価値を向上させ、４ 万人の従業員の働き方に変化をもたらし、そして、企業の持続性と ESG を両立した価値創造を推進していきたいと考えています。お客様、従業員、環境、この 3 つにプラスの価値をもたらすために、今後もデータの活用に取り組んでいきます。

シニア GTM アナリティクススペシャリストソリューションアーキテクトの大薗です。 2024 年 11 月 7 日に「 データガバナンス事例祭り〜AWSで実現するモダンな取り組み〜 」を開催しました。今回の事例祭りでは AWS の Analytics サービスを活用してデータガバナンスの取り組みを実現している富士通株式会社様、株式会社日本経済新聞社様、 LINEヤフー株式会社様、全日本空輸株式会社様にご登壇いただき、AWS からもデータガバナンスを実現する AWS サービスを紹介しました。本ブログでは当日の各発表内容について紹介します。 データガバナンスを実現する AWS サービスのご紹介 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 神部 洋介 資料ダウンロード データガバナンスの重要性と AWS データガバナンスフレームワークのご紹介 AWS の神部からは、オープニングセッションとして、データガバナンスを実現するための様々な AWS サービスについてご紹介しました。 昨今の様々な調査結果も示すように、データガバナンスは企業にとって重要な取り組みとなっています。データガバナンスの目的にはデータを保護する守りの側面と、データを活用してイノベーションを推進する攻めの側面の 2 つがありますが、データの増加、データソースの増加、データ活用者の増加といった課題から推進を難しくさせている点に触れ、AWS で提唱しているデータガバナンスフレームワークについてご紹介しました。データを取得してから活用するまでのフローにおいて、重要な 3 つの領域として Curate、Understand、Protect の 3つがあり、AWS ではこのフレームワークに基づいて様々なサービスを提供しデータガバナンスを支援している点を説明し、各領域における代表的なサービスを紹介していきました。 フレームワークの 3 領域における AWS の代表的なサービス まず Curate の領域では、 AWS Glue (Glue) の機密データ検知やデータ品質管理の機能が紹介されました。Glue を使うことで信頼性の高いデータを作り出し、品質を維持できるためのデータガバナンスの第一歩となります。次に Understand の領域では、 Amazon DataZone (DataZone) のデータポータル、メタデータ、データリネージの機能が紹介されました。DataZone を利用することで、どのようなデータがあるかを簡単に検索でき、メタデータから詳細を理解できるほか、生成 AI によりメタデータを自動生成することも可能です。またデータリネージ機能によりデータのルートや変更履歴を追跡できます。最後の Protect の領域では、 Amazon Redshift (Redshift) のダイナミックデータマスキングと Apache Iceberg が取り上げられました。Redshift のダイナミックデータマスキングを活用することにより、ユーザーごとにデータの表示内容を動的に制御でき、データのセキュア化とデータ活用の両立を図れます。Apache Iceberg はタイムトラベル機能やスキーマ進化機能を持ち、データ変更の追跡や監査要件への対応が容易になります。 このように AWS のサービスや最新のテクノロジーを活用することで、データガバナンスの実現が加速できることを強調し、セッションを締めくくりました。 富士通のデータ利活用プラットフォーム OneData におけるデータガバナンスの取り組み 富士通株式会社 デジタルシステムプラットフォーム本部 Enabling Technologies 統括部 マネージャー 久下 泰明 氏 資料ダウンロード データセキュリティの確保とデータ利活用の促進の両立 富士通株式会社 (以下、富士通) では全社を挙げたデジタルトランスフォーメーションの中核に、データドリブン経営の実現を掲げています。それに向けた経営プロジェクト「OneFujitsu」の一環として、全社データ利活用プラットフォーム「OneData」の整備が始まりました。「OneData」ではデータの提供者、利用者、データ利活用推進者の 3 つの役割を定義し、適切なデータガバナンスの下でデータ利活用を促進するサービスが提供されています。しかし、データ利活用を進める上では、データセキュリティの確保とデータ利活用の促進という 2 つの側面を両立させることが、データガバナンスの大きな課題となります。守りと攻めの両立は容易ではありません。そこで富士通では具体的に 2 つの取り組みを実施し、このデータガバナンスの課題解決を目指しました。 ビジネスデータカタログの導入 1 つ目は AWS のデータガバナンスサービス DataZone を活用したビジネスデータカタログです。DataZone の導入により、データ検索、理解、利用許可の一連の流れをデータガバナンスの下で一元的に実現できるよう構築を進めています。業務コンテキストに基づきデータを発見し価値を理解した上で、メタデータを参照しながらデータの利用許可を 1つの Web ポータルから申請できるようにします。これまで外部ワークフローを経る必要があった利用許可プロセスも DataZone 上で完結し、データガバナンスに基づくデータ利活用のアジリティの大幅な向上を目指しています。 データ品質管理の導入 2 つ目はデータ品質管理の取り組みです。DataZone と Glue Data Quality を組み合わせ、提供側と利用側の双方でデータガバナンスに基づくデータ品質の可視化を進めています。提供側ではデータの業務ルール適合性をチェックし、問題があれば上流システムの改善に役立てます。利用側では分析要件に基づきデータ品質を確認の上、データアセットをサブスクライブすべきかを判断することで、データガバナンスに基づく精度の高いデータ活用の実現を目指しています。 このようにデータガバナンスの観点から、富士通では AWS サービスを活用しながらデータ利活用の促進とセキュリティ確保の両立を実践しています。今後も AWS の機能拡充に期待を寄せつつ、「OneData」におけるデータガバナンスの取り組みを進化させていく考えだと述べられていました。 Apache Icebergで実現する次世代データガバナンス：日経リスク＆コンプライアンスの挑戦 株式会社日本経済新聞社 情報サービスユニット ソフトウェアエンジニア 大塚 恭平 氏 資料ダウンロード データドリブンサービス開発に取り組む日本経済新聞社が直面した課題 株式会社日本経済新聞社 (以下、日本経済新聞社) が提供する法人向けサービス「日経リスク&コンプライアンス」において、Apache Iceberg を活用した次世代のデータガバナンス基盤について紹介されました。日本経済新聞社は、取引先のリスク評価を行うための法人向けサービス開発において、金融庁のガイドラインに準拠するための新機能を追加する必要に迫られていました。具体的には、サービスを利用して取引先のリスク評価を行った際の操作記録を保管し、必要に応じて提示できるようにする必要がありました。年間数億レコードの操作記録を扱う見込みだったため、堅牢でスケーラブルかつ低コストなストレージ基盤が求められました。様々なアーキテクチャを検討した結果、データレイクを支えるオープンソース技術である Apache Iceberg を活用する方針を決めました。 Apache Iceberg の特長を生かしたアーキテクチャ 日本経済新聞社が Apache Iceberg を選んだ理由は、 Amazon Athena (Athena) を含む多くのコンピュートエンジンが Apache Iceberg をサポートしていること、 Amazon S3 (S3) に操作レコードを低コストで保存できること、トランザクション性や スキーマ進化、データの論理削除などの高度な機能に対応できることにありました。実際に構築したアーキテクチャでは、アプリケーションから Amazon Kinesis Data Streams に操作レコードをストリーミングで書き込み、Glue で Apache Iceberg 形式に変換して S3 へ保存しています。ユーザーがアプリで操作履歴を参照する際は、Athena を使って S3 上のデータをクエリします。 Apache Iceberg を用いることで、低コストでありながら高い可用性とデータ整合性を実現。また日付やテナント ID で パーティショニングを行うことで、クエリの高速化とコスト最適化も図れたとのことです。さらに定期的に AWS Step Functions (Step Functions) を使ったメンテナンスジョブを実行し、スモールファイル化の解消やレコード削除などのテーブル最適化を行なっています。 日本経済新聞社では、本プロジェクトを通じて大量データを安全に低コストで保持し、高速なクエリとセキュアな消去を実現 するシステムの構築ノウハウを得ることができました。今後は Apache Iceberg エコシステムの進化に追付することで、よりシンプルかつ低コストなアーキテクチャを実現し、他サービスへのアーキテクチャ横展開を検討しているとのことでした。 LINEヤフー社での DWH としての AWS 導入背景と安全管理のための取り組み LINEヤフー株式会社 データエンジニアリング部 データマネジメントチーム リーダー 尾尻 恒 氏 資料ダウンロード 金融データを取り扱う堅牢なオンプレミスデータレイクを Amazon Redshift Serverless に移行 LINEヤフー株式会社 (以下、LINEヤフー) では、金融データを取り扱う既存の Hadoop ベースのオンプレミスデータレイクシステムが EOL を迎えたことから、新たなデータウェアハウス (DWH) の導入を進めました。既存システムではメンテナンスコスト増加やエンジニア採用の難しさ、データ利活用の課題があったため、 FISC 要件を満たしセキュリティを強化しつつ、効率的な運用とデータ活用の促進を実現できるクラウドベースの DWH が求められていました。 LINEヤフーではセキュリティ、管理・運用、スケーラビリティ、データ活用の 4 つの観点を重要な要件として捉え、これらの要件を満たすプラットフォームとして Amazon Redshift Serverless (Redshift Serverless) を中心とした AWS のサービス群を選定しました。セキュリティ面では AWS IAM Identity Center と既存 Identity Provider (IdP) の連携によりユーザー認証と権限の一元管理を実現し、運用面ではオンプレミスと連携した既存 Notebook の流用と AWS マネージドサービスの活用により容易な運用が実現できる見込みが立ちました。スケーラビリティでは Redshift Serverless や Glue などのサーバーレスサービスを活用することにより、データ量に応じた柔軟なスケーリングが可能となり、データ活用面では非開発職でも利用可能な BI /分析ツールと連携してデータ活用を促進できると判断されました。 データ収集と活用のアーキテクチャ 実際に構築したアーキテクチャでは、オンプレミスのデータを AWS Direct Connect で転送し、Glue や Step Functions などのサービスで機密データのハッシュ化など、適切な ETL 処理を行った上で Redshift Serverless に取り込んでいます。ユーザー認証には IdP を活用した Single Sign On (SSO) で AWS マネージメントコンソールでログインし、Redshift Serverless が提供する機能であるロールベースのアクセスコントロールを行なっています。そのうえで利用者は、汎用的な分析のために Redshift Query Editor v2.0 、可視化に Amazon QuickSight (QuickSight)、高度な分析の用途として Amazon SageMaker (SageMaker) などのサービスを使ってデータ活用を行なっているとのことです。 オンプレミスデータレイクを運用していた尾尻氏は、この DWH 導入プロジェクトを通じて、少人数チームでもクラウドであれば迅速なシステム構築が可能であることを実感されました。一方で、予期せぬ制限にも直面し、運用での工夫が必要になるケースもあったといいます。しかし、AWS の豊富なサービスを組み合わせることで、こうした課題を乗り越えることができたと述べています。今後は、この導入した基盤を生かしてデータカタログソリューションの導入やデータマスキングの実施など、更にデータガバナンスの取り組みを強化していき、組織全体のデータ活用の成熟度を高めていくとのことでした。 ANAグループで実践するデータマネジメントと私たちが大切にしていること 全日本空輸株式会社 デジタル変革室 イノベーション推進部 データマネジメントチーム 丸山 雄大 氏 グループ内外のデータを一元集約する BlueLake 全日本空輸株式会社 (以下、ANA) は、グループ横断でデータの活用を推進するため、データ基盤「BlueLake」の整備を進めてきました。事業の拡大に伴いデータ量やそのバリエーションが増加するなど課題が増えてきたため、2021 年にデータマネジメント構想を掲げ、人材育成支援、プロセスの整備、システムの進化の 3 本柱で取り組みを開始しました。その中核となるのが BlueLake です。BlueLake では ANA グループ内外のデータを一元集約し、スキルレベルに応じたツールで活用できる環境を整備しています。ガバナンスを重視し、データの蓄積から価値創出までの一貫したプロセスを設計しています。 BlueLake において大切にしている 3 つのこと BlueLakeには 3 つの特徴があります。1 つ目は「安心で安全なデータ基盤」であることです。S3 をデータレイクとして活用し、生データを分析可能な Redshift、匿名加工データのみを扱う Snowflake などを組み合わせた 2 層構造となっています。個人情報や機密データは Redshift 側で適切に加工し、Snowflake 側には公開データのみを置くことで、セキュリティを確保しつつ社員の自由な活用を可能にしているとのことです。2 つ目の特徴は、「ワクワクするデータ分析ツール」の提供です。ANA グループには 4 万人の従業員がおり、データリテラシーは様々です。そこで QuickSight、 Amazon WorkSpaces 、Tableau など、目的やスキルに合わせて使い分けられる多様なツールを用意しています。ツール名も製品名ではなく”BlueLake XXX”というキャッチーな呼称を用いるなど、データ活用への親しみやすさを意識しているとのことです。3 つ目は、「二つの Single Source of Truth (SSoT)」の実現です。SSoT には 2 つの側面があり、1 つ目は「データの民主化のための SSoT」で、BlueLake 内でデータの標準化を行い、異なるソースのデータを結合できるよう環境を整えています。レイヤー化やデータモデリングにも取り組んでいます。2 つ目は「データ基盤としての SSoT」で、S3 にデータをファイルとして集約し、基盤アーキテクチャを単純化することで、時代の変化 (技術の進化のスピード) に柔軟に対応できるよう心がけています。現在、新たに Open Table Format 導入を見据え、Apache Iceberg の検証も進めているとのことでした。 データ戦略、データマネジメントポリシー、データ利活用ガイドラインの文書化 また ANA では、データマネジメントに関して、データ戦略、データマネジメントポリシー、データ利活用ガイドラインの 3 部構成で体系的な文書化を行っています。その中核となるのがデータマネジメントポリシーで、その中で上述したような BlueLake のデータ基盤に関する方針やルール、体制などを定義しています。しかし丸山氏は、データマネジメントの考え方を文書化するだけでは実行に移すことは容易ではなく、組織全体でデータマネジメントを理解し取り組んでいく必要があると強調しました。そのため ANA では、データ活用推進体制を戦略、実行、監督の 3 つに分けた三権分立の体制を検討中です。戦略は BlueLake の全社横断推進、実行はデータエンジニアなどによる開発、監督ではリスクマネジメントやガバナンスの観点での役割を想定しているとのことです。 データガバナンスでは最終的に人が最も重要です。優れたポリシーがあってもそれを実行する人がいなければ絵に描いた餅となってしまいます。ANA では従業員の力を結集し、データ活用を通じた事業や社会への貢献を目指していくと宣言され、セッションを締めくくりました。 まとめ 「データガバナンス事例祭り」と題した本セミナーでは、近年注目されているデータガバナンスというテーマに関連する、多様な観点を含む事例が盛り沢山となりました。各社よりご発表いただいたセッションにて紹介された AWS サービスにご興味ある場合は無料で個別相談会を開催しております。皆様からのお申込みをお待ちしております。 お申込みリンク 本ブログは、ソリューションアーキテクトの大薗が作成しました。

はじめに 2024 年 10 月 10 日、新聞・出版・メディア業界のお客様向けに、「AWS Media Seminar 2024 – 今から始める！Publisher 向け生成 AI」というテーマでセミナーをオンラインにて開催いたしました。このセミナーの開催報告として当日お話しした内容や資料をご紹介いたします。文章生成やコンテンツ分析、PDF 解析など、生成 AI は Publisher にとっても様々な活用方法が見いだされるようになり、業務効率化や新しい価値の創造に大きく貢献し始めています。本セミナーでは、このように生成 AI の活用が広がってきた中で見えてきた課題にどう向き合っていくのか、Amazon や 国内のお客様の事例を交えながら AWS セッションにてお話させて頂きました。続いて、生成 AI を先駆的に活用しイノベーションを実現しているお客様にご登壇頂き、具体的な検証結果や自社プロダクトへ組み込む際の工夫点、 Amazon Bedrock の活用場面と選定理由などをお話頂きました。 Publisher のための生成 AI の事例とはじめかた アマゾン ウェブ サービス ジャパン 合同会社 メディアソリューション部 ソリューションアーキテクト 向井 稔 【 資料 】 【 動画 】 オープニングセッションとしてアマゾン ウェブ サービス ジャパン 向井より、生成 AI をはじめる上でのビジネス面と技術面の課題に対するアプローチをお話させて頂きました。ビジネス面の課題については複数の Publisher 向けの事例と共に生成 AI をどう始めたらよいのかアイデアを挙げさせて頂き、技術面の課題を解決するために提供された Amazon Bedrock についてご紹介しました。 この中で生成 AI をはじめる 1 つのアイデアとして、生成 AI を活用したビジネスユースケースのサンプル集となる Generative AI Use Cases JP をご紹介しております。 ママ向け Q&A サービス mamari の検索機能向上における生成 AI 活用～ LLM 時代の新しい検索体験に向けた試み 〜 コネヒト株式会社 機械学習エンジニア 池之上 陽平 様 【 資料 】 【 動画 】 コネヒト株式会社池之上様より、ママ向け Q&A サービスにおける生成 AI を活用した検索機能の改善の取り組みをご紹介いただきました。この中で従来の全文検索と近年注目を集めているベクトル検索について、実際の Q&A データを扱った複数のクエリパターンにおける検索結果の違いについてお話し頂いております。 生成 AI と Amazon Titan で始めるコンテンツのタグ付けとコンテンツ推薦 note株式会社 機械学習エンジニア 漆山 和樹 様 【 資料 】 【 動画 】 note株式会社漆山様より、インターネット上でコンテンツを発表できる note における生成 AI を活用したコンテンツのレコメンド機能の改善の取り組みをご紹介いただきました。この中で Amazon Titan Text Embeddings を活用したタグ付けの事例や、生成 AI を活用したタグ付けを改良する工夫についてお話し頂いております。 コンテンツ制作支援サービス ALOFA における生成 AI 活用 株式会社朝日新聞社 メディア事業本部メディア研究開発センター 嘉田 紗世 様 【 資料 】 【 動画 】 株式会社朝日新聞社嘉田様より、メディア研究開発センターで取り組まれている編集業務の作業効率化に向けた取り組みをご紹介いただきました。取材後の文字起こし作業は記事制作の中でも負担が大きいプロセスです。この作業を効率化するプロダクト 「ALOFA」の 特徴や構成と工夫点、Amazon Bedrock の活用場面と選定理由についてお話し頂きました。 おわりに 本ブログでは、2024 年 10 月 10 日に開催された「AWS Media Seminar 2024 – 今から始める！Publisher 向け生成 AI」の内容をご紹介させていただきました。本セミナーに参加いただいた皆さま、誠にありがとうございました。引き続き皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログはソリューションアーキテクト向井が担当しました。

現代の変化のペースが速く競争の激しい製造業界では、企業はサプライチェーンの管理において、出荷の遅延、部品不足、輸送のボトルネックといった重大な課題に直面しています。 製造業の企業は、需要を予測し、市場の変動に合わせて生産を調整しながら、材料や部品のサプライヤ、生産設備、製品の流通チャネルからなるネットワークの複雑さに苦労することがよくあります。 製品の供給を保証しながら在庫コストを最小限に抑えるには、原材料の入手可能性、生産能力、物流、消費者の嗜好を慎重に検討する必要があります。 従来のサプライチェーン手法は、こうした動的な要因に対して不十分であることが多く、効率の低下、在庫切れ、過剰在庫につながります。 製造業の企業に影響を及ぼすサプライチェーンの課題 製造業の企業は、生産計画や材料管理から可視性やデータ統合に至るまで、サプライチェーン業務全体でさまざまな課題に直面しています。 主な複雑さは次のとおりです。 資材需要と生産能力のバランスを取り、スループットを最適化する効果的な資材資源計画（MRP）の策定。 水の使用量、プラスチック、リサイクルに関するサステナビリティの目標に合わせながら、製品設計の更新や規制遵守による材料組成の変化を監視。 作業指示やメンテナンス作業に必要なスペアパーツや資材を可視化することで、ダウンタイムと潜在的な収益損失の最小化。 エンドツーエンドのサプライチェーンの透明性を実現することで、データドリブンな意思決定、需要シグナルの検出、在庫予測の生成、シミュレーションによるリスク評価、混乱への積極的な対処。 このブログでは、 AWS Supply Chain と Amazon Q を連携させ、サプライチェーンの課題に対する解決策をどのように提供するのかを説明します。 これらのソリューションは、サプライチェーンデータ、生成 AI、機械学習（ML）を活用することで、実用的な洞察を提供します。 こうしたテクノロジーは、製造業の企業に革新的な戦略とデータドリブンな推奨事項を提供し、業務の合理化、リソースの最適化、大きな変化を見越した対応に役立ちます。 AWS Supply Chain AWS Supply Chain は、サプライチェーンネットワーク全体の可視性、トレーサビリティ、計画を強化するクラウドベースのアプリケーションです。 その中心となるのが、分析のために 複数のソース からのデータを統合するリポジトリである サプライチェーンデータレイク （SCDL）です。 AWS Supply Chain は、データから洞察を得る機能、ML を活用した需要予測、在庫最適化、高度な分析により、データドリブンな意思決定を促進します。 サプライチェーン業務を最新化するための次のような 包括的な機能 を提供します。 洞察 : 過剰在庫や在庫切れなどのリスクを特定し、カスタムウォッチリストやアラートのオプションを使用して在庫マップ上で可視化します。 推奨アクションとコラボレーション : ランク付けされたリスク情報とともに、在庫移動の選択肢を提示し、過去の決定から学習して推奨事項を改善します。また、問題を迅速に解決するために組み込まれたコラボレーションツールも含まれています。 需要計画 : ML を使用して正確な需要予測を生成し、市場の状況に基づいて調整し、リアルタイムで更新して余剰在庫と廃棄物を削減します。 供給計画 : ML モデルを使用して必要な資材購入を予測および計画し、在庫管理を改善し、コストを削減します。 N階層の可視性 : 外部パートナーにインサイトを広げ、取引先との注文や供給計画を確認することで計画の正確性を高めます。 サステナビリティ : サプライヤーから環境、社会、ガバナンス（ESG）データを収集して管理し、サステナビリティ基準の遵守を確保します。 複数の拠点の在庫を最適化することで、製造業の企業は統合されたサプライチェーンデータから得られる透明性、説明性を実現し、実用的なアクションにつながる分析能力を向上させることができ、運用の優秀性（オペレーショナルエクセレンス）、収益性、顧客満足度を高めることができます。 Amazon Q Amazon Bedrock を搭載した生成 AI アシスタントである Amazon Q が、 AWS Supply Chain に統合されました。 Amazon Q の自然言語インターフェースにより、SCDL 内のデータへの問い合わせと分析が可能になり、複雑な「何？」や「なぜ？」 「もしも？」 という質問に対するインテリジェントな回答が得られます。例えば、Amazon Q は「航空貨物で注文を急ぐ場合はどうなりますか？」と質問すると「航空貨物は通常 2 日で到着するため、収益への影響は 95,000 USD 減りますが、急送費用には 2,400 USD が追加されます」と回答する可能性があります。 ML モデルを活用することで、Amazon Q はサプライチェーンのデータを解釈し、貴重な洞察を導き出し、実行可能な推奨事項を生成します。 会話型のインターフェイスにより、複雑な SQL クエリやデータ操作を必要とせずに自然に対話できます。 AWS Supply Chain の Amazon Q は、戦略的洞察を求める経営幹部でも、詳細な運用を検討しているサプライチェーンの分析担当者でも、それぞれのニーズに合わせて適応します。 AI による洞察により、ボトルネック箇所の特定、プロセスの最適化、運用効率の向上に役立ちます。 生成 AI による製造エクセレンスの推進 AWS Supply Chain with Amazon Q は、生成 AI と機械学習を活用して、複雑なサプライチェーンの課題に取り組んでいます。 AWS の安全で高性能なインフラストラクチャにより、メーカーは AI の採用を加速させ、市場投入までの時間を短縮し、生産性を高め、業務を合理化し、サプライチェーンを最適化できます。 製造業の企業はすでに AWS AI/ML サービスを使用して業務を強化し、データドリブンな意思決定を可能にしています。 以下にいくつか例を挙げます。 迅速な診断と問題解決による製造現場の生産性の向上 : エレベーターおよびエスカレーター業界のグローバルリーダーである KONE は、原因分析と解決までの時間を短縮することで、現場での顧客サービスの迅速化を実現しています。 同社は Amazon Bedrock を使用して、社内文書を活用する生成 AI アプリケーションを大規模展開しています。 生成 AI テクノロジーを使用してマニュアル、工場データの分析結果、履歴データをトレーニングすることで、技術者は問題のトラブルシューティングを効率的に行い、機器メンテナンスの詳細なガイドを作成できます。 このアプローチは、製造環境における診断、問題解決、意思決定、および資産保守プロセスをスピードアップすることにより、製造現場の生産性を向上させます。 合成画像データによる製品品質と欠陥検出の強化 : 製薬会社の Merck は、AWS のサービスと生成 AI を使用して欠陥画像を合成し、正確で堅牢な欠陥検出モデルをトレーニングする際のデータの制約を克服しています。 生成 AI により、Merck のようなメーカーは合成画像を生成し、「良い」例と「悪い」例でデータセットを補強できます。 このアプローチにより、Merck は製品ライン全体で全体の不良品を 50% 以上削減し、効率の向上と廃棄物の削減を実現しました。 顧客がサステナビリティの目標を達成できるようにする : インテリジェントな気候およびエネルギーソリューションの世界的リーダーである Carrier は、AWS のサービスを利用して Abound Net Zero Management プラットフォームを拡張・強化しています。 Carrier は、Amazon Bedrock と Amazon Textract を活用することで、お客様がエネルギー消費を管理し、二酸化炭素排出量を削減できるよう支援しています。 このソリューションにより、顧客は公共料金の請求書を現地の言語でアップロードでき、Carrier は生成 AI を使用してこのデータをサステナビリティに関する実用的な洞察に変換します。 このイニシアチブは、より安全で持続可能な世界を創造するという Carrier の使命と一致しています。 これらの顧客事例は、生成 AI ソリューションが、いかに製造業の企業がイノベーションを推進し、業務効率を高め、競争が激化する環境において時代を先取りする力を与えているかを示しています。 まとめ 現代における競争の激しい製造環境では、効果的なサプライチェーン管理が運用の優秀性と持続的な成長の鍵となります。 従来の方法では、現代のサプライチェーンの複雑さに対処するには不十分であることが多く、非効率につながります。 製造業の企業は、これらの課題を克服するために AWS Supply Chain や Amazon Q などのソリューションに目を向けています。 AWS Supply Chain の一元化された SCDL と高度な分析機能を活用することで、企業はデータ主導の意思決定、可視性の向上、計画の最適化を実現できます。 Amazon Q では、製造業の企業は自然言語による問い合わせを通じてインテリジェントな洞察と実用的な推奨事項を得ることができます。 生成 AI が現実世界にもたらす影響は、製造現場の生産性の向上、品質の向上、欠陥検出能力の向上、トレーニング時間の短縮といった点で明らかです。 AWS Supply Chain と Amazon Q を採用することで、メーカーは俊敏性、回復力、持続可能な競争力を高めることができます。 業界が進化するにつれて、これらのツールはサプライチェーン運用の可能性を最大限に引き出し、イノベーションを促進し、コストを削減し、優れた顧客体験を提供するのに役立ち、長期的な成功への道を開きます。 AWS Supply Chain を利用開始するには： AWS Supply Chain と Amazon Q については、それぞれのページにアクセスして特徴や機能をご確認ください。 自分のペースで進められる技術的なウォークスルーについては、 AWS Workshop Studio をご覧ください。 インスタンスの作成、データの取り込み、ユーザーインターフェースの操作、インサイトの作成、需要計画の生成の方法を学びます。 準備ができたら、 AWS Console にアクセスし、AWS Supply Chain の効率的でデータ主導型のツールを使用してサプライチェーンの運用を合理化しましょう。 詳細なセットアップ手順や追加のガイダンスについては、 ユーザーガイド も参照いただけます。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> Ben-Amin York Jr Ben-Amin は、フロントエンドウェブおよびモバイルテクノロジーを専門とする AWS ソリューションアーキテクトで、自動車および製造企業のデジタル変革の推進をサポートしています。 彼は AI / ML テクノロジーを扱い、それがさまざまな業界のビジネスに与える変革の影響を評価することを楽しんでいます。 自動車および製造セクターの AWS 企業顧客をサポートすることを専門としており、ビジネス目標の達成に役立つ技術指導を行っています。 Ben-Amin は、Amazon Monitron、Amazon Lookout for Vision、AWS IoT などの AWS サービスを利用して、成功の可能性を解き放っています。 Brayan Montiel Brayan Montiel は AWS のソリューションアーキテクトです。 自動車および製造業界の企業顧客をサポートし、クラウド導入技術の加速と IT インフラストラクチャの近代化を支援しています。 彼は AI / ML テクノロジーを専門としており、お客様がジ生成 AI と革新的なテクノロジーを使用して業務の成長と効率化を推進できるよう支援しています。 仕事以外では、家族と充実した時間を過ごしたり、屋外に出たり、旅行を楽しんだりしています。 Medha Aiyah Medha Aiyah は AWS のソリューションアーキテクトです。 彼女は 2022 年 12 月にテキサス大学ダラス校を卒業し、コンピューターサイエンスの理学修士号を取得しました。専門分野は、AI / ML に焦点を当てたインテリジェントシステムです。 彼女は、顧客が AWS を最適に使用してビジネス目標を達成できるようにすることで、さまざまな業界の企業顧客をサポートしています。 彼女は特に、AI / ML ソリューションを実装し、生成 AI を活用する方法についてお客様を指導することに興味を持っています。 Miles Jordan Miles Jordan は AWS のソリューションアーキテクトで、分析や検索の技術を専門としています。 彼はデータを効果的に利用することに重点を置き、あらゆる分野の企業顧客にビジネス目標を達成するための技術ガイダンスを提供しています。

この記事は、 Build an internal SaaS service with cost and usage tracking for foundation models on Amazon Bedrock を翻訳したものです。 企業は、各事業部門 (LOB) に基盤モデルへのアクセスを提供することで、生成 AI の可能性を迅速に引き出そうとしています。IT チームは、集中管理とオブザーバビリティを提供しながら、事業部門が迅速かつ俊敏にイノベーションを起こせるよう支援する責任があります。例えば、チーム間の基盤モデルの使用状況を追跡し、使用料を請求し、事業部門の関連するコストセンターに可視性を提供する必要があるかもしれません。さらに、チームごとに異なるモデルへのアクセスを規制する必要があるかもしれません。例えば、特定の基盤モデルのみが使用を承認されている場合などです。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの大手 AI 企業が提供する高性能な基盤モデルを単一の API で利用できるフルマネージドサービスです。また、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するための幅広い機能も提供します。Amazon Bedrock はサーバーレスであるため、インフラストラクチャを管理する必要がなく、すでにご利用中の AWS サービスを使用して生成 AI 機能を安全にアプリケーションに統合およびデプロイできます。 基盤モデルのための software as a service (SaaS) レイヤーは、アクセスと利用状況の一元管理を維持しながら、エンドユーザーにシンプルで一貫したインターフェイスを提供できます。API ゲートウェイは、モデルの利用者とモデルエンドポイントサービスの間の疎結合を可能にし、変化するモデル、アーキテクチャ、呼び出し方法に適応できる柔軟性を提供します。 この記事では、組織内のチームをテナントとして捉えた場合の、マルチテナントアーキテクチャで Amazon Bedrock を使用して基盤モデルにアクセスするための内部 SaaS レイヤーの構築方法をご紹介します。特に、テナントごとの使用量とコストの追跡、およびテナントごとの使用量制限などのコントロールに焦点を当てています。このソリューションと Amazon Bedrock の利用プランが、一般的な SaaS ジャーニーフレームワークにどのように対応するかについて説明します。ソリューションのコードと AWS Cloud Development Kit (AWS CDK) テンプレートは、 GitHub リポジトリ で入手できます。 課題 AI プラットフォーム管理者は、複数の開発チームに対して基盤モデルへの標準化された簡単なアクセスを提供する必要があります。 基盤モデルへの管理されたアクセスを提供する上で、以下のような課題があります。 コストと使用状況の追跡 – 個々のテナントの基盤モデルのコストと使用状況を追跡・監査し、特定のコストセンターに費用を振り分けます 予算と使用量の制御 – テナントごとに定義された頻度での基盤モデルの許可された使用に対して、API クォータ、予算、使用制限を管理します アクセス制御とモデルガバナンス – テナントごとに承認された特定のモデルに対するアクセス制御を定義します マルチテナント標準化 API – OpenAPI 標準に準拠した基盤モデルへの一貫したアクセスを提供します API の一元管理 – モデルへのアクセスのための API キーを管理する単一のレイヤーを提供します モデルのバージョンと更新 – 新規および更新されたモデルバージョンの展開を行います ソリューションの概要 このソリューションでは、マルチテナントアプローチについて説明します。ここでのテナントは、個人のユーザー、特定のプロジェクト、チーム、あるいは部門全体まで、さまざまな単位を指します。このアプローチについて説明する際、最も一般的なケースであるため、チームという用語を使用します。チームの API アクセスを制限し監視するために、API キーを使用します。各チームには 基盤モデル へのアクセス用の API キーが割り当てられます。組織内には、さまざまなユーザー認証および承認メカニズムが導入されている場合があります。簡略化のため、このソリューションではこれらは扱っていません。既存の ID プロバイダーをこのソリューションと統合することも可能です。 次の図は、ソリューションのアーキテクチャと主要コンポーネントを示しています。異なるコストセンターに割り当てられたチーム (テナント) は、API サービスを介して Amazon Bedrock 基盤モデル を利用します。チームごとの使用量とコストを追跡するために、このソリューションは、呼び出されたモデル、テキスト生成モデルのトークン数、マルチモーダルモデルの画像サイズなど、個々の呼び出しに関するデータを記録します。さらに、モデルごとの呼び出し回数とチームごとのコストを集計します。 AWS CDK を使用して、お客様のアカウントにこのソリューションをデプロイできます。AWS CDK は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースをモデル化およびプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。AWS CDK のコードは GitHub リポジトリ で入手できます。 以下のセクションでは、このソリューションの主要なコンポーネントについて詳しく説明します。 チーム別の基盤モデル利用状況の把握 各チームの基盤モデル使用状況を収集するワークフローは、以下のステップで構成されています (前述の図の番号に対応)： チームのアプリケーションは、 Amazon API Gateway に POST リクエストを送信し、 model_id クエリパラメータで呼び出すモデルを指定し、リクエストボディにユーザープロンプトを含めます。 API Gateway は、リクエストを AWS Lambda 関数 ( bedrock_invoke_model ) にルーティングします。この関数は、 Amazon CloudWatch でチームの使用情報をログに記録し、Amazon Bedrock モデルを呼び出す役割を担います。 Amazon Bedrock は、 AWS PrivateLink を利用した VPC エンドポイントを提供します。このソリューションでは、Lambda 関数は PrivateLink を使用して Amazon Bedrock にリクエストを送信し、アカウントの VPC と Amazon Bedrock サービスアカウント間のプライベート接続を確立します。PrivateLink の詳細については、 Use AWS PrivateLink to set up private access to Amazon Bedrock をご覧ください。 Amazon Bedrock の呼び出し後、 Amazon CloudTrail は CloudTrail イベント を生成します。 Amazon Bedrock の呼び出しが成功すると、Lambda 関数は呼び出されたモデルのタイプに応じて以下の情報をログに記録し、生成されたレスポンスをアプリケーションに返します： team_id – リクエストを発行するチームの一意の識別子 requestId – リクエストの一意の識別子 model_id – 呼び出すモデルの ID inputTokens – プロンプトとしてモデルに送信されたトークン数（テキスト生成および埋め込みモデル用） outputTokens – モデルによって生成される最大トークン数（テキスト生成モデル用） height – リクエストされた画像の高さ（マルチモーダルモデルおよびマルチモーダル埋め込みモデル用） width – リクエストされた画像の幅（マルチモーダルモデルのみ） steps – リクエストされたステップ数（ Stability AI モデル用） チームごとのコスト追跡 別のフローでは、使用状況情報を集約し、チームごとのオンデマンドコストを日次で計算して保存します。フローを分離することで、コストの追跡がモデル呼び出しフローのレイテンシーとスループットに影響を与えないようにしています。 ワークフローのステップは以下の通りです： Amazon EventBridge ルールが毎日 Lambda 関数 ( bedrock_cost_tracking ) をトリガーします。 Lambda 関数は前日の使用情報を CloudWatch から取得して関連するコストを計算し、 team_id と model_id で集計されたデータを CSV 形式で Amazon Simple Storage Service (Amazon S3) に保存します。 Amazon S3 に保存されたデータのクエリと可視化には、 S3 Select や Amazon Athena と Amazon QuickSight など、さまざまなオプションがあります。 チームごとの使用量の制御 使用プランは、1 つまたは複数のデプロイされた API にアクセスできるユーザーを指定し、オプションでリクエストのスロットリングを開始するためのターゲットリクエストレートを設定します。このプランは API キーを使用して、各キーに関連付けられた API にアクセスできる API クライアントを識別します。API Gateway の 使用プラン を使用して、事前に定義されたしきい値を超えるリクエストをスロットリングできます。また、 API キー とクォータ制限を使用して、指定された時間間隔内に各チームが発行できる API キーごとのリクエストの最大数を設定できます。これは、アカウントレベルでのみ割り当てられる Amazon Bedrock サービスクォータ に加えて設定できます。 前提条件 このソリューションをデプロイする前に、以下のものを準備してください： AWS アカウント 。AWS が初めての場合は、 AWS アカウントの作成 をご覧ください。 開発環境に以下をインストールしていること： AWS Command Line Interface (AWS CLI) Python 3 AWS CDK このソリューションで使用するリソースをデプロイするための AWS Identity and Access Management (IAM) 権限を持つ AWS CLI プロファイル が設定されていること。 AWS CDK スタックのデプロイ GitHub リポジトリの README ファイルの手順に従って、AWS CDK スタックを設定およびデプロイしてください。 このスタックは以下のリソースをデプロイします： プライベートネットワーク環境 (VPC、プライベートサブネット、セキュリティグループ) モデルアクセスを制御する IAM ロール 必要な Python モジュール用の Lambda レイヤー Lambda 関数 invoke_model Lambda 関数 list_foundation_models Lambda 関数 cost_tracking REST API (API Gateway) API Gateway 使用量プラン 使用量プランに関連付けられた API キー チームのオンボーディング 新しいチームにアクセス権を付与するには、以下の 2 つの方法があります。 API キーを異なるチーム間で共有し、API 呼び出し時に異なる team_id を指定してモデルの使用状況を追跡する、もしくは、 README の手順に従って、Amazon Bedrock リソースにアクセスするための専用の API キーを作成する、という方法です。 このスタックは以下のリソースをデプロイします： 先に作成した REST API に関連付けられた API Gateway 使用量プラン 新しいチーム用の使用量プランに関連付けられた API キー (API のスロットリングとバースト設定が予約済み) API Gateway のスロットリングとバースト設定の詳細については、 スループット向上のための API リクエストのスロットリング を参照してください。 スタックをデプロイすると、 team-2 の新しい API キーも作成されていることが確認できます。 モデルアクセス制御の設定 プラットフォーム管理者は、Lambda 関数 invoke_model に関連付けられた IAM ポリシーを編集することで、特定の基盤モデルへのアクセスを許可できます。 IAM アクセス許可は setup/stack_constructs/iam.py ファイルで定義されています。以下のコードをご覧ください： self.bedrock_policy = iam.Policy( scope=self, id=f"{self.id}_policy_bedrock", policy_name="BedrockPolicy", statements=[ iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "sts:AssumeRole", ], resources=["*"], ), iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "bedrock:InvokeModel", "bedrock:ListFoundationModels", ], resources=[ "arn:aws:bedrock:*::foundation-model/anthropic.claude-v2.1", "arn:aws:bedrock:*::foundation-model/amazon.titan-text-express-v1", "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v1" ], ) ], ) … self.bedrock_policy.attach_to_role(self.lambda_role) サービスの呼び出し ソリューションをデプロイした後、コードから直接サービスを呼び出すことができます。以下は、POST リクエストを通じてテキスト生成のための invoke_model API を Python から使用した例です： api_key="abcd1234" model_id = "amazon.titan-text-express-v1" #the model id for the Amazon Titan Express model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2 } prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier } ) text = response.json()[0]["generated_text"] print(text) 出力: Amazon Bedrock is an internal technology platform developed by Amazon to run and operate many of their services and products. Some key things about Bedrock … (参考訳) Amazon Bedrock は、Amazon が多くのサービスや製品を稼働・運用するために開発した内部技術プラットフォームです。Bedrock に関する主なポイントは… 以下は、POST リクエストを通じてエンベディングを生成するために invoke_model API を使用した Python の別の例です。 model_id = "amazon.titan-embed-text-v1" #the model id for the Amazon Titan Embeddings Text model prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier, "embeddings": "true" #boolean value for the embeddings model } ) text = response.json()[0]["embedding"] 出力: 0.91796875, 0.45117188, 0.52734375, -0.18652344, 0.06982422, 0.65234375, -0.13085938, 0.056884766, 0.092285156, 0.06982422, 1.03125, 0.8515625, 0.16308594, 0.079589844, -0.033935547, 0.796875, -0.15429688, -0.29882812, -0.25585938, 0.45703125, 0.044921875, 0.34570312 … 基盤モデルへのアクセス拒否 以下は、POST リクエストを使用して invoke_model API でテキスト生成を行う Python の例で、アクセス拒否応答の場合の例です。 model_id = " anthropic.claude-v1" #the model id for Anthropic Claude V1 model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2 } prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier } ) print(response) print(response.text) &lt;Response [500]&gt; “Traceback (most recent call last):\n File \”/var/task/index.py\”, line 213, in lambda_handler\n response = _invoke_text(bedrock_client, model_id, body, model_kwargs)\n File \”/var/task/index.py\”, line 146, in _invoke_text\n raise e\n File \”/var/task/index.py\”, line 131, in _invoke_text\n response = bedrock_client.invoke_model(\n File \”/opt/python/botocore/client.py\”, line 535, in _api_call\n return self._make_api_call(operation_name, kwargs)\n File \”/opt/python/botocore/client.py\”, line 980, in _make_api_call\n raise error_class(parsed_response, operation_name)\nbotocore.errorfactory.AccessDeniedException: An error occurred (AccessDeniedException) when calling the InvokeModel operation: Your account is not authorized to invoke this API operation.\n ” コスト見積もりの例 オンデマンド料金で Amazon Bedrock モデルを呼び出す場合、総コストは入力コストと出力コストの合計として計算されます。 入力コストはモデルに送信される入力トークン数に基づき、出力コストは生成されるトークン数に基づいて計算されます。 料金は、入力トークン 1,000 個あたりと出力トークン 1,000 個あたりで設定されています。 詳細および具体的なモデル料金については、 Amazon Bedrock の料金 をご参照ください。 2 つのチーム (team1 と team2) が、このポストで紹介するソリューションを通じて Amazon Bedrock にアクセスする例を見てみましょう。 Amazon S3 に保存された 1 日分の使用量とコストデータを、次の表に示します。 input_tokens 列と output_tokens 列には、特定の日におけるモデルごと、チームごとのモデル呼び出しにおける入力トークンと出力トークンの合計が保存されます。 input_cost 列と output_cost 列には、モデルごとおよびチームごとの各コストが格納されます。これらは以下の計算式を使用して算出されます。 input_cost = input_token_count * model_pricing["input_cost"] / 1000 output_cost = output_token_count * model_pricing["output_cost"] / 1000 チーム ID モデル ID 入力トークン数 出力トークン数 呼び出し回数 入力コスト 出力コスト Team1 amazon.titan-tg1-large 24000 2473 1000 0.0072 0.00099 Team1 anthropic.claude-v2 2448 4800 24 0.02698 0.15686 Team2 amazon.titan-tg1-large 35000 52500 350 0.0105 0.021 Team2 ai21.j2-grande-instruct 4590 9000 45 0.05738 0.1125 Team2 anthropic.claude-v2 1080 4400 20 0.0119 0.14379 実践的なマルチテナントサーバーレス SaaS 環境の全体像 エンドツーエンドで機能するマルチテナントのサーバーレス SaaS 環境がどのようなものか見ていきましょう。以下は参考アーキテクチャの図です。 このアーキテクチャ図は、投稿の前半で示した前回のアーキテクチャ図を俯瞰したバージョンです。前回のアーキテクチャ図では、言及されたマイクロサービス (基盤モデルサービス) の 1 つの詳細を説明しました。この図は、基盤モデルサービス以外にも、機能的でスケーラブルなプラットフォームを実装するためには、マルチテナント SaaS プラットフォームに他のコンポーネントも必要であることを説明しています。 アーキテクチャの詳細について説明していきましょう。 テナントアプリケーション テナントアプリケーションは、環境と連携するフロントエンドアプリケーションです。 ここでは、複数のテナントが異なるローカル環境や AWS 環境からアクセスしている様子を示しています。フロントエンドアプリケーションは、新規テナントが自身で登録できる登録ページや、SaaS サービスレイヤーの管理者向けの管理コンソールを含むように拡張できます。テナントアプリケーションが SaaS 環境とのやり取りを必要とするカスタムロジックを実装する必要がある場合、アプリケーションアダプターマイクロサービスの仕様を実装することができます。例えば、SaaS 環境の認可仕様に従いながら、カスタムの認可ロジックを追加するようなシナリオが考えられます。 共有サービス 以下は共有サービスです: テナントとユーザー管理サービス – これらのサービスは、テナントの登録と管理を担当します。アプリケーションサービスとは分離され、すべてのテナントで共有される共通機能を提供します。 基盤モデルサービス – このマイクロサービスは、この投稿の冒頭で説明したソリューションアーキテクチャ図で示されており、API Gateway から Lambda 関数へのやり取りがこのマイクロサービスの範囲内で行われます。すべてのテナントは、このマイクロサービスを使用して、Anthropic、AI21、Cohere、Stability、Meta、Amazon からの基盤モデル、およびファインチューニングされたモデルを呼び出します。また、CloudWatch ログで使用状況を追跡するために必要な情報も収集します。 コスト追跡サービス – このサービスは、各テナントのコストと使用状況を追跡します。このマイクロサービスはスケジュールに従って実行され、CloudWatch ログをクエリして集計された使用状況の追跡と見積もりコストをデータストレージに出力します。コスト追跡サービスは、さらなるレポートや可視化を構築するように拡張できます。 アプリケーションアダプターサービス このサービスは、テナントが SaaS 環境にカスタムロジックを統合するために実装できる仕様と API のセットを提供します。必要なカスタム統合の程度に応じて、このコンポーネントはテナントにとってオプションとなります。 マルチテナントデータストア 共有サービスは、個々のテナントと DynamoDB アイテムを関連付けるテナントパーティショニングキーを持つ、単一の共有 Amazon DynamoDB テーブルなどのデータストアにデータを保存します。コスト追跡の共有サービスは、集計された使用量とコスト追跡データを Amazon S3 に出力します。ユースケースに応じて、アプリケーション固有のデータストアを設けることもできます。 マルチテナント SaaS 環境には、さらに多くのコンポーネントが含まれる可能性があります。詳細については、 AWS のサーバーレスサービスを利用したマルチテナント SaaS ソリューションの構築 を参照してください。 複数のデプロイメントモデルのサポート SaaS フレームワークは通常、プールとサイロの 2 つのデプロイメントモデルを定義しています。プールモデルでは、すべてのテナントが共有ストレージと共有コンピューティングインフラストラクチャを持つ共有環境から基盤モデルにアクセスします。サイロモデルでは、各テナントが専用のリソースセットを持ちます。分離モデルについては、 SaaS テナント分離戦略ホワイトペーパー をご参照ください。 提案されたソリューションは、両方の SaaS デプロイメントモデルに採用できます。プールアプローチでは、集中管理された AWS 環境が API、ストレージ、およびコンピューティングリソースをホストします。サイロモデルでは、各チームが専用の AWS 環境内の API、ストレージ、およびコンピューティングリソースにアクセスします。 このソリューションは、Amazon Bedrock が提供する利用プランにも対応しています。 AWS では、推論用に 2 つの利用プランを選択できます： On-Demand – このモードでは、利用期間にコミットメントせずに、従量課金ベースで基盤モデルを利用できます Provisioned Throughput – このモードでは、利用期間にコミットメントすることで、アプリケーションのパフォーマンス要件を満たすのに十分なスループットをプロビジョニングできます これらのオプションの詳細については、 Amazon Bedrock の料金 をご参照ください。 この記事で説明するサーバーレス SaaS リファレンスソリューションでは、Amazon Bedrock の利用プランを適用して、エンドユーザーにベーシックとプレミアムの階層オプションを提供できます。 ベーシックプランには、Amazon Bedrock のオンデマンドまたはプロビジョンドスループット消費が含まれ、特定の使用量と予算の制限を設定できます。テナントの制限は、リクエスト数、トークンサイズ、または予算配分に基づいてリクエストを制御することで実現できます。プレミアムティアのテナントは、Amazon Bedrock のプロビジョンドスループット消費による専用リソースを持つことができます。これらのテナントは通常、高スループットと低レイテンシーでの Amazon Bedrock 基盤モデルへのアクセスを必要とする本番環境のワークロードに関連付けられます。 まとめ この投稿では、マルチテナント環境で Amazon Bedrock を使用して基盤モデルにアクセスする社内 SaaS プラットフォームの構築方法について説明しました。その際、各テナントのコストと使用状況の追跡、およびスロットリング制限に焦点を当てました。さらに探求すべきトピックとしては、組織内の既存の認証・認可ソリューションの統合、双方向のクライアントサーバー通信のための WebSocket を含む API 層の強化、コンテンツフィルタリングやその他のガバナンスガードレールの追加、複数のデプロイ層の設計、SaaS アーキテクチャにおける他のマイクロサービスの統合などがあります。 このソリューションのコード全体は、 GitHub リポジトリ で入手できます。 SaaS ジャーニーフレームワークの詳細については、 SaaS Journey Framework: Building a New SaaS Solution on AWS を参照してください。 翻訳はソリューションアーキテクトの福本が担当しました。 著者について Hasan Poonawala は、AWS のシニア AI/ML スペシャリストソリューションアーキテクトとして、ヘルスケアおよびライフサイエンスのお客様を担当しています。 Hasan は、AWS 上での生成 AI および機械学習アプリケーションの設計、デプロイ、スケーリングを支援しています。 クラウドにおける機械学習、ソフトウェア開発、データサイエンスの分野で 15 年以上の実務経験を持っています。 余暇には、自然を探索したり、友人や家族と時間を過ごすことを楽しんでいます。 Anastasia Tzeveleka は、AWS のシニア AI/ML スペシャリストソリューションアーキテクトです。 EMEA 地域のお客様が AWS サービスを使用してファンデーションモデルを構築し、スケーラブルな生成 AI および機械学習ソリューションを作成するお手伝いをしています。 Bru no Pistone は、ミラノを拠点とする AWS の生成 AI および ML スペシャリストソリューションアーキテクトです。 大規模な顧客と協力して、技術的なニーズを深く理解し、AWS クラウドと Amazon Machine Learning スタックを最大限に活用する AI および機械学習ソリューションの設計を支援しています。 専門分野は、機械学習の一連のプロセス、機械学習の実用化、生成 AI です。 友人と時間を過ごしたり、新しい場所を探索したり、旅行を楽しんでいます。 Vikesh Pandey は、金融サービスを専門とする生成系 AI/ML ソリューションアーキテクトで、金融系のお客様が数百から数千人規模のユーザーに対応できる生成系 AI/ML プラットフォームとソリューションの構築とスケーリングを支援しています。 余暇には、さまざまなブログフォーラムで記事を書いたり、子供と一緒に LEGO を組み立てたりして過ごしています。

本稿は、2023 年 6 月 23 日に AWS Cloud Enterprise Strategy Blog で公開された “ Should You Prioritize? ” を翻訳したものです。 ときどき、ある考えが常識として染み付いてしまっており、私たちの行動すべてに組み込まれている前提となっていることがあります。会議で誰かが「優先順位をつける必要がある」と言ったり、「これは優先事項ですか？」と言ったりなどです。何かがうまくいかないとき、それは優先順位をつけなかったせいにされるかもしれません。IT チームが、ビジネスが要求するすべての仕事に対応できないとき、ビジネスリーダーには優先順位をつけるよう求められます。優先順位という言葉は、ハイレベルなもの （会社の戦略的優先順位を決めなければならない） から、粗い粒度の戦術的なもの （投資に優先順位をつけなければならない） 、細かい粒度のもの （優先順位に基づいてバックログを整備しなければならない） まで、さまざまな議論の中で定着しています。 優先順位をつけることが誰にとっても難しいように思えるのは、何か不自然なところがあるからなのでしょう。 問題のひとつは、優先順位という言葉の意味が変わってしまったことです。14 世紀にラテン語の prior を元にした古フランス語の priorite から作られた最初の造語では、「（他の何かより） 早い状態」を意味していました。つまり、重要性ではなく時間を指していたのです。1900 年代に入ってから、直ちに注意を要するという意味を持つようになりました。[1] priorities という複数形は、最近になって英語に加わったものです。これは 1900 年代に作られた造語で、1940 年代まではほとんど使われていませんでした。それまでは、最も重要なことは 1 つしかないのだから、優先順位は 1 つしかないことは明らかだったのです。prioritize という動詞が生まれたのは最近のことであり、1972 年の大統領選挙の頃に、政治的な演説の一部として初めて使われました。 私たちの多くは本能的に、優先順位とは企業にとって最も重要な事柄の集合であると定義していますが、実のところ、今日この言葉をそのように使うことはほとんどありません。その意味は、私たちが認めたがらない形で再び変化しています。 今日における優先順位付けの本当の意味 奇妙なことに、今日私たちは優先順位付けを、やる仕事とやらない仕事を分けるために使っています。新しい仕事が提案されると、誰かが 「それは本当に優先順位が高いのか？」と尋ねるでしょう。それは、優先順位が高くないなら、やるべきではないというのが前提があります。優先順位とは、もはや他のことに先立ってやらなければならないことでも、最も重要なことでもありません。だから複数形が必要になっているのです。複数の優先順位がなければ、やるべきことはひとつしかないのです！ 今日の用法では、優先順位とは、組織のランク付けされたすべてのニーズのサブセットとなっています。優先順位を付ける、とは、潜在的な仕事や投資のリストを作り、それらを重要度の高い順に並べ、その中から上位 3 つ、 6 つ、あるいは 12 個を取り出し、優先順位のラベルを付けることです。それらが、その企業が投資する対象となるものです。 なぜ、このように意味が変わってきたのでしょうか？ それは、経営者やリーダーが絶え間なく経費削減を求められそれを証明する必要のある環境の中に住んでいることが関係しているでしょう。優先事項、つまり 「やらなければならないこと」だけに投資すること以上に、支出を少なくする方法はないのです。その起源はどうであれ、この変化は、優先事項が「すべてやるつもり」リストになるというダイナミズムを生み出したのです。奇妙な感じがしますよね？ 私は最近、2 社の戦略計画を見直しました。そのうちの 1 社は、11 の優先事項を挙げていました。なぜそんなに多いのでしょうか？ それは、事業を運営するために必要なことをすべて盛り込もうとしているからです。2 社目の戦略計画には 4 つの優先事項しかありませんでしたが、どれも漠然としたもので、「卓越した運用を追求する」とか 「顧客のために成果を出す」といった内容でした。優先順位はすべてを含むように意図されており、彼らが選択したものはすべて、形式化された優先順位にマッピングできるようになっていました。 これらの「優先順位付け」は、優先順位について何も伝えていないというのが実際のところです。 優先順位付けの重要な（奇妙な）前提1：固定されたキャパシティ 優先順位付けの中心的な前提は、私たちは固定されたキャパシティで仕事をしているということです。私たちができることには限界があるため、優先順位をつけなければなりません。おそらく、優先順位付けの候補リストには、良いリターンが期待できる投資だけが含まれているはずです （そうでなければ候補にはなりません）。優先順位付けの考え方には、機会費用が発生する可能性を残しておこうという意図が組み込まれています （訳者注：機会費用とは、ある生産要素を特定の用途に利用する場合に、それを別の用途に利用したならば得られたであろう利益の最大金額をさし、実際の生産額の費用とする概念[2]）。リターン獲得のために利用可能な機会に基づいてキャパシティが設定されるのではなく、キャパシティが　（どうにかして）　設定され、そこから利用可能な機会が導き出されるのです。 IT 部門は長い間、この仮説に悩まされてきました。 IT 部門は、企業全体のサービスに対する需要を募ったり、受け入れたりすることで、優先順位をつけるために要求された仕事のリストを作成します。この需要は常に IT 部門のキャパシティを超えるため、 IT 部門は全部の中から一部を選択しなければなりません。断る仕事の中には、会社の利益になる仕事も含まれているため、組織 （訳者注： ITにリクエストを出すビジネス部門のこと） の一部を不愉快にさせ、 IT 部門が反応が遅くて鈍いという印象を与えることは間違いありません。 ビジネス部門の人々は、良いアイデアをたくさん持っている傾向があります。もし、キャパシティには限りがあり、優先順位をつけなければならないと言われれば、優先順位が高いものしか扱われないとわかっているため、すべて良いアイデアなのですべての優先順位が高いと宣言するのは自然なことです。もし優先事項だけで実行可否が決定されるのであれば、付加価値を生むアイデアはすべて 「優先事項」になってしまうでしょう。 実際、組織には、優先事項でなくてもやらなければならないことがたくさんあります。特に IT の世界では、会社を運営し続けるにはかなりの帯域幅 （訳者注：キャパシティと同義）　が必要です。仕事を「優先事項」に限定すると、デス・スパイラルが始まり、会社の運営にリスクが加わり始めます。優先順位をつける行為自体が無駄を増やしていくのです。技術者ならこの比喩の意味がわかるかもしれません。コンピュータのメモリが少なすぎると、結局 CPU はアプリケーションをメモリに出し入れするのに時間を費やしてしまい、無駄に消費されてしまいます。 IT 部門は、創造に費やせるはずの労力を需要管理とガバナンスに費やすことになります。 キャパシティに基づいて仕事を絞り込まなければならないという考えは、私たちが平衡状態にないことを意味しています。私達が価値を生み出すことができないのであれば、受け入れるキャパシティを増やす必要があります。あるいは、優先順位付けの候補を特定する方法に何か問題があるのかもしれません。企業は制限されたキャパシティで働くべきだという考え方は、キャッシュ・マネジメントとの類似から来るものかもしれません。企業は一定額のキャッシュしか持っていないので、利用可能なキャッシュでしか投資を行うことができません。しかし、それは短期的な話であり、企業の成長計画はキャッシュ・ニーズへの対応が不可欠です。経営がうまくいっている企業では、資金の制約がビジネス価値を損なうことはありません。 IT リソースに恒久的な制約を課すことは、どういうわけかそれとは違うように思われるのです。 いずれにせよ、 IT 部門は優先事項だけでなく、企業が必要とするすべてのことに責任を持たなければなりません。 優先順位付けの重要な（奇妙な）前提2：既知の機会 優先順位付けの２つ目の前提は、与えられた投資機会のリストについて意思決定を行うことです。私たちは、「優先順位付けの候補となる以下のリストの中で、どのように順位付けをすべきか、また、どのリストに取り組むべきかの境界線をどこに引くべきか？」と問います。しかし、目まぐるしく変化する今日の不確実な環境では、私たちは常に新たな機会や課題に遭遇し、潜在的な投資案件の重要度が上がったり下がったりしています。 スクラムのようなアジャイルフレームワークは、作業のバックログを作成し、それを頻繁に優先順位を変更し、または洗練することによって、こうした変化を管理しようとしています。しかし、おそらくこれは優先順位付けとプロジェクト管理を混同しています。（議論の余地はあるものの）スクラムは組織的な優先順位から逆算するのではなく、要求抽出のプロセスを通じて与えられた、粒度の細かい個々の作業項目を調整しています。スクラムは本質的に、優先順位付けとはランク付けとサブセット化を意味するという考えを形式化したものです。もちろん、バックログを整理し、優先順位を付け直すことはできますが、バーンダウンチャート （訳者注：プロジェクトの進捗状況を可視化したもので残りの作業量を把握することができる）　を有用なものにするためには、多かれ少なかれ、前もって事前に作業を把握しておく必要があります。追加することはできますが、それに必ず他の作業への影響があります。 ここで想定されるメンタルモデルは、それぞれ独自のニーズを持つしたサイロ化された事業単位であり、中央にある IT 組織によってランク付けされなければならない、というものです。各サイロは独自の優先順位があり、中央の IT 組織は 「中央」であるがゆえに異なる優先順位を持っています。この状況は、競合する優先順位の枠組みが生み出され、勝者と敗者を選別しなければなくなります。予想通り、 IT は「ビジネス」と「より整合性のある」ものになるべきだという声が絶えません。 優先順位付けの重要な（奇妙な）前提3：厳格な方法論 3つ目の前提は、多種多様な投資を合理的に順位付けする方法があるはず、それはおそらく投資収益率 (ROI) である、ということです。しかし、拙著『 The Art of Business Value 』で論じたように、 ROI はこの目的を効果的に果たすものではありません。 ROI に基づく IT 作業の優先順位付けは、ビジネススクールの教授だった方々には申し訳ないのですが、価値を破壊することになります。私は、ESGの重要性が増すにつれて、このことをさらに確信するようになりました。ステークホルダーは、必ずしも ROI を最大化しないものにも価値を見出すことが多いのです。 優先順位を分けて考える この混乱を解きほぐす第一歩は、戦略、優先順位、仕事量管理の概念を分けることです。戦略とは、優先順位のリストではなく、リーダーが自社の市場に対する独自のアプローチを推進するために決定する、一連の原則です。どんな瞬間にも、優先順位は 1 つであるべきです。それは、戦略を実行するにあたり、リーダーが従業員に集中して取り組んでほしいと思える事がその時々の優先事項なのです。しかし、優先事項 （単数）は、会社が実行する必要のある仕事すべてではありません。実行は高帯域幅で多くのことを並行して行う必要があります。今日、私たちは従業員を自律的なチームに編成し、それぞれの領域に対して完全なオーナーシップを持つようにしています （「自分たちが構築したものを自分たちで実行する」）。これは、活動を並行して行うための優れた組織構造になります。 この3つのコンセプトはそれぞれ異なりますが、連続した全体の一部になります。仕事量管理に対する異なるアプローチは、経営陣が戦略を打ち出すことから始まり、その戦略を達成するための仕事に直接移行します。優先順位付けが必要な、組織全体から募ったイニシアティブのリストは存在しないのです。イニシアティブは、ハイレベルの戦略から有機的に導かれます。また、優先されるのは最初に実行されるイニシアティブです。戦略上の必須事項が成長である場合、望ましい成長をもたらす可能性が最も高いイニシアティブが追求されます。これは、他のイニシアティブが推進されないという意味ではなく、リソースの競合がある場合に戦略的なイニシアティブが優先されるというだけなのです。 これは、優先順位の設定について私が常に耳にしている雑談に基づいた考えにすぎません。参考になれば幸いです。 -Mark [1] Online Etymology Dictionary https://www.etymonline.com/search?q=priority [2]　機会費用 コトバンク Mark Schwartz マーク・シュワルツは、アマゾンウェブサービスのエンタープライズストラテジストであり、『 The Art of Business Value and A Seat at the Table：IT Leadership in the Age of Agility 』の著者です。 AWS に入社する前は、米国市民権・移民業務局 (国土安全保障省の一部) の CIO、Intrax の CIO、および Auctiva の CEO を務めていました。 彼はウォートン大学で MBA を取得し、イェール大学でコンピューターサイエンスの理学士号を取得し、イェール大学で哲学の修士号を取得しています。 この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。

本記事は Senior Manager-Product の Arvind Mahesh、Senior Technical Program Manager の Kuldeep Yadav、Senior Principal Solutions Architect の Jon Handler により執筆された投稿の日本語版です。原文は こちら よりご確認いただけます。 Amazon OpenSearch Service は、19 のオープンソース Elasticsearch バージョンと、11 の OpenSearch バージョンをサポートしています。AWS は長年にわたり、新しいエンジンバージョンにおいて安定性、回復力、セキュリティを強化することで、お客様が OpenSearch Service からより大きな価値を得られるよう努めてきました。ソフトウェアのバージョンが古くなるにつれ、これらのバージョンが高いセキュリティと法令遵守の基準を満たし続けることを確実にする必要があります。Elasticsearch バージョン 1.5 や 2.3 などの OpenSearch Service でサポートされている多くのレガシーバージョンは、もはや積極的にサポートされていないサードパーティライブラリに依存しています。最新のエンジンバージョンに移行することで、お客様は新機能、改善されたコストパフォーマンス、そして OpenSearch に対する当社のセキュリティ改善から最大限の恩恵を得ることができます。 本日、Amazon OpenSearch Service で利用可能な以下のバージョンについて、標準サポートと延長サポートの終了時期を発表します。 Elasticsearch 6.7 およびそれ以前のバージョン Elasticsearch 7.1 から 7.8 OpenSearch 1.0 から 1.2 OpenSearch 2.3 から 2.9 標準サポート期間内のバージョンについては定期的なバグ修正とセキュリティ修正を、延長サポート期間内のバージョンについては追加の定額料金&nbsp; (正規化されたインスタンス時間) を支払うことで重要なセキュリティ修正とオペレーティングシステムのパッチが提供されます。延長サポートにより、利用者がより新しいエンジンバージョンへのアップグレードを計画している間に、重要なセキュリティ修正を、十分な期間利用できることを目指します。延長サポートの詳細については、 よくある質問 &nbsp;をご覧ください。 Elasticsearch における各バージョンの標準サポートと延長サポートの終了時期 OpenSearch Service で利用可能な Elasticsearch の各バージョンにおける標準サポートと延長サポートの終了日については、以下の表をご覧ください。該当する Elasticsearch のバージョンを使用しているお客様には、最新の OpenSearch バージョンへのアップグレードをお勧めします。すべての Elasticsearch バージョンは少なくとも 12 ヶ月の延長サポートが提供されます。またバージョン 5.6 においては、最長で 36 ヶ月まで延長サポートが提供されます。延長サポートが終了すると、対象のバージョンを実行しているドメインに対しては、バグ修正やセキュリティアップデートの提供が行われなくなります。 ソフトウェアバージョン 標準サポート終了日 延長サポート終了日 Elasticsearch 1.5, 2.3 2025 年 11 月 7 日 2026 年 11 月 7 日 Elasticsearch 5.1 から 5.5 2025 年 11 月 7 日 2026 年 11 月 7 日 Elasticsearch 5.6 2025 年 11 月 7 日 2028 年 11 月 7 日 Elasticsearch 6.0 から 6.7 2025 年 11 月 7 日 2026 年 11 月 7 日 Elasticsearch 6.8 未定 未定 Elasticsearch 7.1 から 7.8 2025 年 11 月 7 日 2026 年 11 月 7 日 Elasticsearch 7.9 未定 未定 Elasticsearch 7.10 未定 未定 OpenSearch における標準サポートと延長サポートの終了時期 Amazon OpenSearch Service で実行される OpenSearch については、対応するアップストリームのオープンソースの OpenSearch バージョンのサポート終了日から、少なくとも 12 ヶ月の標準サポート、または OpenSearch Service における次期マイナーバージョンのリリースから 12 ヶ月の標準サポートの、いずれか長い方が提供されます。すべての OpenSearch バージョンに対して、標準サポート終了日から少なくとも 12 ヶ月の延長サポートが提供されます。詳細については、オープンソース OpenSearch の メンテナンスポリシー をご確認ください。 OpenSearch Service で利用可能な OpenSearch の各バージョンごとの標準サポートおよび延長サポートの終了日については、以下の表をご覧ください。バージョンごとの標準サポートおよび延長サポートに関する今後のアップデートについては、 サポートバージョン のページよりご確認ください。 ソフトウェアバージョン 標準サポート終了日 延長サポート終了日 OpenSearch 1.0 から 1.2 2025 年 11 月 7 日 2026 年 11 月 7 日 OpenSearch 1.3 未定 未定 OpenSearch versions 2.3 から 2.9 2025 年 11 月 7 日 2026 年 11 月 7 日 OpenSearch 2.11 およびそれ以降のバージョン 未定 未定 OpenSearch Service ドメインのアップグレード : OpenSearch Service から最大限の価値を得るために、OpenSearch ドメインを最新の バージョンにアップグレードすることをお勧めします。OpenSearch のマイナーバージョンアップグレードは、互換性を破壊する変更を含まないため、通常はシームレスに実行可能です。最新のマイナーバージョン、またはサポート終了がまだ発表されていないバージョンへの移行をお勧めします。例えば、OpenSearch バージョン 1.2 を使用している場合、1.x 系の最後のマイナーバージョンであり、現在もオープンソースコミュニティと AWS によってサポートされている OpenSearch バージョン 1.3 に移行できます。Elasticsearch バージョンを選択する場合で、以前の 6.x または 7.x バージョンを実行している場合は、バージョン 6.8 または 7.10 に移行できます。 クラスターを新しいバージョンにアップグレードする方法は複数あり、手順はドメインが実行しているバージョンとアップグレード先のバージョンによって異なります。ドメインを新しいバージョンにアップグレードする詳細な手順については、 OpenSearch Service ドメインのアップグレード をご覧ください。また、新しいバージョンへのアップグレードには Amazon OpenSearch Service 用の移行アシスタント も利用可能です。 延長サポート料金の計算 : 延長サポート中のバージョンを実行しているドメインには、正規化されたインスタンス時間 (Normalized Instance Hour = NIH) あたりの定額追加料金が課金されます。例えば、米国東部 (バージニア北部) AWS リージョンでは、0.0065 ドル/NIH の料金が発生します。リージョンごとの正確な料金については、 料金ページ をご覧ください。 NIH は、インスタンスサイズ (例：medium、large) とインスタンス時間数の要素として計算されます。例えば、米国東部 (バージニア北部) リージョンで、m7g.medium.searchインスタンスを 24 時間実行している場合、通常はインスタンス時間あたり 0.068 ドル (オンデマンド) で、1.632 ドル (0.068×24) を支払います。延長サポート中のバージョンを実行している場合、NIH あたり 0.0065 ドルの追加料金が発生し、これは 0.0065 × 24 (インスタンス時間数) × 2 (medium サイズインスタンスのサイズ正規化係数は2) として計算され、24 時間の延長サポートで 0.312 ドルとなります。24 時間の総額は、標準インスタンス使用料と延長サポート料の合計で、1.944 ドル (1.632 + 0.312 、ストレージコストを除く) となります。以下の表は、OpenSearch Service の各インスタンスサイズの正規化係数を示しています。 インスタンスサイズ 正規化係数 nano 0.25 micro 0.5 small 1 medium 2 large 4 xlarge 8 2xlarge 16 4xlarge 32 8xlarge 64 9xlarge 72 10xlarge 80 12xlarge 96 16xlarge 128 18xlarge 144 24xlarge 192 32xlarge 256 まとめ 最新の OpenSearch バージョンには、新機能、パフォーマンスと回復力の改善、セキュリティの改善など、様々な新しい機能を追加しています。OpenSearch Service から最大限の恩恵を得るため、最新の OpenSearch バージョンへの更新をお勧めします。標準サポートと延長サポートのオプションに関する質問については、 よくある質問 &nbsp;をご覧ください。その他の質問については、 AWS サポート にお問い合わせください。 著者について Arvind Mahesh は&nbsp;Amazon OpenSearch Service のシニアプロダクトマネージャーです。分析、検索、クラウド、ネットワークセキュリティ、通信など、様々な分野で約20年間の技術経験を持っています。 Kuldeep Yadav は、イノベーションの推進と複雑な問題解決に情熱を注いでいる Amazon Web Services のシニアテクニカルプログラムマネージャーです。チームや顧客と密接に協力して、運用の優位性を確保し、より少ないリソースでより多くの成果を上げることに取り組んでいます。仕事以外では、トレッキングといったあらゆるスポーツを楽しんでいます。 Jon Handler &nbsp;は、カリフォルニア州パロアルトを拠点とする Amazon Web Services のシニアプリンシパルソリューションアーキテクトです。OpenSearch と Amazon OpenSearch Service に深く携わり、検索やログ分析のワークロードを AWS クラウドに移行したいと考える顧客に対して、幅広くサポートとガイダンスを提供しています。AWS 入社以前は、ソフトウェア開発者としてのキャリアの中で、大規模な e コマース検索エンジンの実装に 4 年間従事していました。ペンシルベニア大学で文学士号を、ノースウェスタン大学でコンピュータサイエンスと人工知能の理学修士号と博士号を取得しています。

※ 本ブログは、株式会社ペライチとAmazon Web Services Japan が共同で執筆いたしました。 ペライチとは、株式会社ペライチが運営するホームページ作成サービスです。EC サイトやセミナー、ランディングページといった利用目的にあわせて数百種類のテンプレートからお好みのデザインを選び、テキストや画像を入力するだけでイメージに近いホームページを作成できます。 個人事業主から大企業まで、誰でも簡単にホームページを作って運用できるように、ペライチは豊富なテンプレートを用意しています。ホームページ制作経験がない方でも直感的に操作できるよう、プロダクトを拡大し続けてきました。しかし、初めてホームページを作成される方にとっては、頭の中でイメージしたレイアウトやデザインをホームページの形に落とし込むことが難しく、公開まで至らないユーザーが存在する課題が浮き彫りになっていました。 こうしたお客様の課題を解決するため、AIの力を活用してより簡単にホームページを作成できる「ペライチクリエイトアシスタント」を開発しました。この機能では、ユーザーが任意のサイトのURLを入力するだけで、そのサイトの特徴や用途に応じた情報を生成AIが抽出し、それに基づいた最適なテンプレートでサンプルのホームページを提案します。 この記事ではそもそもプロダクトの課題をどのように抽出したか、プロダクトの課題に対して生成 AI に限らずどのようなアプローチを検討したか、生成 AI を活用した機能をどのように実装したかをお伝えします。 アプローチの検討 ペライチは AWS ジャパン生成 AI 実用化推進プログラム に参加しました。このプログラムでは、ビジネス価値に繋がるユースケースの発見とその実装のサポートを提供します。生成AIに関する技術的なガイダンスやビジネス支援により３ヶ月程度でお客様のプロダクトに生成AI機能を実装できるように支援します。期間内でのプロダクト実装を条件に a) 生成 AI 活用事例のインプットと事例化されたユースケースをベースにしたビジネスモデルの作成支援、b) 構築済みサンプルアプリケーション を使ったハンズオン、c) PoC 用AWS クレジットといった支援を AWS から受けることができます。ユースケースの検討では ‍AWS で提供実績がありかつ評価が高いワークショップ‍を実施し、プログラムに参加する他社と交流する機会があるなど短い期間で密度の濃い経験をすることができました。 ワークショップでは現状の顧客 (エンドユーザー) の課題、ビジネス (ペライチ) の課題、それらを解決するユースケース、解決の度合いを測る KPI 、 KPI 改善までのマイルストンを整理して一つのドキュメント (=企画書) にまとめます。この企画書にまとめる作業にはペライチの PdM とエンジニアの他に AWS アカウントチームのアカウントマネージャーとソリューションアーキテクト、生成 AI 実用化推進プログラムの運営メンバーが参加し最終的にユーザー観点、ビジネス観点、それぞれ踏まえた上での課題を整理することができました。 ペライチでは「誰でも簡単に初期費用無料で、600 種類以上のテンプレートから選んで編集するだけでページを作成・公開できる」サービスを提供してきました。その上でワークショップの議論の結果、「そもそもどのテンプレートを選べばよいか分からない」「いまあるページをイチから作り直すのはハードルが高い」ユーザー観点の課題があり、従来はペライチのカスタマーサポートのメンバーなどがテンプレートの選択やデザインパーツの選択、素材の移行などでサポートしてきたが人的リソースに限界があるビジネス観点の課題があると整理することができました。 今回はこれらの課題に対して、入力情報としてサイトの URL 情報を与えそこからユーザーのビジネスや商材、ユースケースなどの情報を AI で抽出・要約し、それらの情報を元にしてペライチの既存テンプレートを組み合わせてページを生成することを試みました。「ユーザーが持つ古いページを作り直すケース」や「ユーザーが持つ既存の EC 販売サイトとは別に独自の EC サイトを立ち上げたい」などといったユースケースを想定しています。インプット情報を少なくし、そこから AI を用いてペライチのサービス側でユーザーに必要な情報を抽出・推論することで、今まで人間がサポートしていた部分を一部生成 AI によって置き換えて、ユーザーの制作コストやリードタイムを削減しようとしています。 実装 ペライチは AWS の プロトタイピングプログラム を有効活用しました。これは、AWS の知識や経験が豊富なプロトタイピングエンジニアが、お客さまに代わってシステムのプロトタイプを開発するというプログラムです。 今回実装する全体的な処理は「前処理 : URL から Web ページの情報を取得し、内容を説明・要約・抽出する」と「後処理：前処理で抽出された情報を元にペライチが持つテンプレートを選択・文章を生成・画像やページの配色などを選びページを生成する」の 2 つのステップに分かれています。生成 AI を活用した前処理に焦点を当てると、入力された URL 情報から WEB ページの情報の抽出・説明・要約する処理をプロトタイピングプログラムの支援を受けてAWS Step Functions と AWS Lambda そしてAmazon Bedrock を活用して実装していただきました。 利用者とペライチの皆様からの声 ペライチは 2024 年 8 月5 日より、 無料モニターを受け付けています 。 無料モニターに参加した利用者からは「 URL を入力するだけでイメージに近いページが簡単に生成できてよかった」「自社が保有している既存のページのリプレイスが簡単にできそう」というフィードバックをいただきました。 また、ペライチの藤代様からは「サービスの設計、LLMのモデル選定、実装など幅広くご支援いただき助かりました」「現在はモニターからの声を集めながらサービス改善に努めており、他サービスにも似た仕組みを適用できないか試しています」といった声をいただきました。 まとめ Amazon Bedrock によりWEBサイトの構築において今まで人間がサポートしていた部分を一部生成 AI によって置き換えて、ユーザーの制作コストやリードタイムを削減するシステムを構築することができました。 ペライチでは今後もAWSのサービスを活用しながら、更なる価値提供を実現しようと考えています。 著者について 苅野 秀和(Hidekazu Karino) 飛行機の勉強をしていたのが気づいたらなんやかんやあって AWS に入社してました。現在はウェブ系のお客様の技術支援を行いながら Rust を書いています。 週末は美味しいクロワッサンを求めてパン屋を探訪しています。

はじめに 2024 年 9 月に広島で地域経済の活性化に向けたデータコラボレーションワークショップを開催しました。本記事では、本ワークショップの開催背景と当日の内容をご紹介いたします。 近年、データは新たな価値創造の源泉として注目されています。しかし、単一企業のデータだけでは、その潜在的な可能性を最大限に引き出すことは困難です。そこで重要となるのが、企業間のデータコラボレーションです。多様な産業が集積する広島では、各企業が保有するデータの連携により、新たなビジネスチャンスや地域課題の解決が期待されています。この潮流の中、中国新聞社は「たるポ」という地域IDプラットフォームを構築し、地域に根ざした新たな価値提供を目指しています。しかし、データコラボレーションの実現には、セキュリティ懸念や異業種間でのデータ活用ノウハウの不足という課題がありました。 これらの課題に対応するため、中国新聞社と AWS は共同でワークショップを企画しました。ワークショップでは、「小売」「放送」「金融」といった業界から 4 社の代表者様にお集まりいただき、 AWS Clean Rooms を活用し、セキュリティとプライバシーを確保したデータコラボレーションのユースケースを議論しました。さらに、異業種間でのデータ活用案と、参加企業が具体的なアクションプランを策定できる場を提供することを目指しました。 開催概要 参加企業: 5 社 / 26 名 アジェンダは以下の通りです。 開会のご挨拶 / 参加企業ご紹介 たるポのご紹介 AWS コラボレーションテクノロジーのご紹介 テーブル別ディスカッション Next Step のご案内 / 閉会のご挨拶 前半をセミナー、後半をディスカッションと分けて開催いたしました。後半のディスカッションでは、3つのグループに参加者が分かれ、実際にデータコラボレーションする際のユースケースについて議論を行いました。 データコラボレーションの基本 データコラボレーションとは 続いて、本ワークショップのメインテーマであるデータコラボレーションと、それを支える AWS のサービスについてご説明します。まず、データコラボレーションとは、複数の組織が保有するデータを安全かつ効果的に共有・統合・分析し、単独では得られない洞察や価値を生み出す取り組みです。例えば、小売業とメディア企業が匿名化された顧客データをコラボレーションすることで、より精緻なマーケティング戦略の立案や新サービスの開発が可能になります。重要なのは、各組織のデータプライバシーとセキュリティを維持しながら、必要な情報のみを共有することです。これにより、安全性を確保しつつデータの価値を最大化することができます。 なぜ今データコラボレーションが注目されているのか データコラボレーションの注目が高まっている背景には、デジタル化の加速、消費者行動の複雑化、データ保護に関する規制環境の整備があります。さらに 1st party data (自社で直接収集したデータ) の重要性が増していることも大きな要因です。サードパーティ Cookie の廃止や個人情報保護の厳格化に伴い、企業は自社の顧客データをより効果的に活用し、同時に他社のデータと安全に連携する必要性が高まっています。このデータ活用と連携が、企業の競争優位性を生み出す鍵となっています。実際、多くのグローバル企業がデータコラボレーション強化を推進しており、日本においても今後のビジネス戦略において重要な役割を果たすことが予想されます。 AWS Clean Rooms とは データコラボレーションを支える AWS サービスが AWS Clean Rooms です。これは、組織間で生データを直接共有せずに安全にデータを分析するマネージドサービスです。主な特徴として、暗号化技術によるセキュアなデータ共有、SQL を用いた柔軟な分析環境、実行する SQL の制御機能、緻密なアクセス制御、大規模データセットに対するスケーラビリティがあります。このサービスにより、企業は自社データを保護しつつ、連携先企業とのデータコラボレーションを実現し、新たなビジネス機会を創出できます。 各セッションのハイライト たるポのご紹介 株式会社中国新聞社 メディア開発局 メディア開発部長 石井将文氏 中国新聞社 石井氏より、地域 ID プラットフォーム「たるポ」についてご紹介いただきました。たるポは、中国新聞社が長年培われてきたブランド力と信頼性を基盤とした、新たな地域 ID プラットフォームです。たるポは、地域で広く使われることを意識して構築され、顧客情報の質と地域の企業との柔軟な連携を重視しています。一般ユーザー向けには、1 つの ID で複数サービスへのログイン機能やポイントの一元化、e ギフトへの交換などを提供します。法人向けには、PR ソリューションや会員基盤の新規導入、ID 連携などを実現します。たるポは拡張性のある仕組みで、現在複数のサービスと ID 連携しています。今後は「会員増」と「連携サービス増」を同時に達成し、地域のエコシステムとして、広島エリアでの事業拡大を考えている企業との連携や、B2B での利活用を視野に入れていると語られました。 AWS のコラボレーションテクノロジー アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 本多和幸 アマゾン ウェブ サービス ジャパン 本多より、データコラボレーションを AWS 上で実現する方法についてご説明を行いました。上記でご紹介した AWS Clean Rooms の詳しいご説明と、AWS Clean Rooms の新機能で企業間で類似セグメントの作成を支援する AWS Clean Rooms ML 、名寄せのサービスである AWS Entity Resolution を中心にご説明しました。 テーブル別ディスカッション ワークショップのメインとなったテーブル別ディスカッションでは、具体的なデータコラボレーションのユースケースについて活発な議論が交わされました。参加企業の皆様に事前に各社のデータ資産をヒアリングし、実践的なユースケースを準備したことで、より深い議論が可能となりました。小売業界のテーブルでは、ポイントカードの活用や新規顧客獲得の戦略が話し合われ、非会員の購買行動分析や他業種とのデータ連携の可能性が探られました。放送業界のテーブルでは、会員データの活用やイベント集客データの取得に関する課題が共有され、特にスポーツチームのファンクラブアプリを通じたデータ活用に注目が集まりました。金融業界のテーブルでは、データのセキュリティを保ちつつ顧客理解を深める方法が議論されました。 お客様の声 本ワークショップは、広島地域におけるデータコラボレーションの可能性を探る貴重な機会となりました。参加企業の皆様からは、「他社とのデータ連携でできることや目指すことの具体的な議論ができたことは良かった」「セキュリティを担保しながらのデータ共有方法が理解できた」といった前向きな声を多数いただきました。ワークショップ後のアンケートでは、参加者の90%以上が本ワークショップに対してポジティブなフィードバックを頂き、データコラボレーションに対する高い期待が伺えます。 おわりに 本ワークショップを通じて、データコラボレーションの大きな可能性と、参加企業の皆様の熱意を肌で感じることができました。ここに改めて、ご参加いただいた企業の皆様、そして共催である中国新聞社の皆様に心より感謝申し上げます。AWS は、今後もこの様なデータコラボレーションを推進する取り組みのご支援や、皆様に役立つ情報をセミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログは、ソリューションアーキテクト本多が担当しました。

はじめに 製造業における技能継承は、日本のモノづくりの競争力を維持する上で非常に重要な課題となっています。2024年度版モノづくり白書によると、製造業において能力開発や人材育成に問題があるとした事業所の割合は2022年度では82.8%に達しており、多くの企業が課題を抱えていることがわかります。 （出典：経済産業省　2024年版ものづくり白書） 　問題点の内訳を見ると、「指導する人材が不足している」という回答が最も多く、次いで「人材育成を行う時間が無い」「人材を育成してもやめてしまう」「鍛えがいのある人材が集まらない」といった課題が挙げられています。 （出典：経済産業省　2024年版ものづくり白書） 　これらの問題は、熟練技能者の退職や若手人材の確保難、業務の多忙化などが背景にあると考えられます。 こうした状況に対し、企業ではさまざまな取り組みが行われています。最も多いものは「退職者の中から必要なものを選抜して雇用延長、嘱託による再雇用を行い、指導者として活用している」というもので、熟練技能者の知識や経験を若手に伝承する努力がなされています。次いで、「中途採用を増やしている」「新規学卒者の採用を増やしている」といった人材確保の取り組みや、「退職予定者の伝承すべき技能・ノウハウなどを文書化、データベース化、マニュアル化している」といった知識の形式知化も行われています。 技能継承は一朝一夕には解決できない課題ですが、これらの結果から、技能伝承自体は多くの企業にて課題として認識はしており各社様々な取り組みを行っているものの、世代交代がうまくできていない現状が垣間見えます。 生成AIと映像・音声を活用したプラントメンテナンスデモの開発と AWS Summit Japan 2024 での展示 ベテランエンジニアの退職や若手人材の確保難により、貴重な経験やノウハウが失われつつあります。 この問題に対し、AWSとして何か提供できるソリューションはないかと考え、生成AIや音声・映像技術を活用した技能伝承支援ソリューションを開発しました。従来、技能伝承はテキストやマニュアル、ベテランエンジニアの経験と勘に頼ることが多かったのですが、これらだけでは経験の浅いエンジニアが高品質な製品を作ったり、複雑な設備を適切に保守したりすることは困難です。特に、設備の異常時に物理現象の意味を理解し、正常な状態に復旧させるには、分厚い保守マニュアルや大量の過去の作業報告書から似た事象を探したり内容を読み解く必要があり、都度発生する事象に柔軟に対応しようとするのは非常に困難です。 データ化は客観的な判断や記録保存の観点から重要です。しかし、ベテランエンジニアの五感による経験や、明文化しづらいノウハウも併せて伝承されてこそ、安定した製品品質を保つためには重要です。これらをいかにして次世代に引き継ぐかが、製造業の未来を左右する一つの鍵となるでしょう。 本ソリューションでは、生成AIのサービスである Amazon Bedrock が過去のデータや膨大な資料から効率的に解決策を推測します。同時に、Amazon Chime の Chime SDK を利用してベテランエンジニアがリモートから映像や音声を通じて若手を支援することで、実地での経験を効率的に積むことができます。この複合的なアプローチにより、若手エンジニアは机上の知識だけでなく、ベテランの勘やコツも学ぶことができます。また、ベテランの知識をデジタル化して保存することで、長期的な技能伝承にも貢献します。 製造業の未来は、人間の経験と最新技術の融合にあります。 本デモは、本年6/20 – 6/21 に千葉県の幕張メッセで開催されたAWS Summit Japan 2024にて、製造業ブースで「生成AI・音声・映像によるプラント保守」をテーマにデモを出展しました。2日間で600名以上のお客様にご来場いただき、盛況のうちに幕を閉じることができました。デモのタイトルにもなっているプラント関連のプロセス製造業だけでなく、組み立て製造業やSIer様など、幅広い業種の方々から技能伝承についてご関心をいただいていることを実感することができました。ご来場いただいた方々に改めて御礼申し上げます。 公開版ソリューションのご紹介 この度、本ソリューションを皆様にご活用いただけるように、AWS Summit Japan で展示したデモから IoT の部分だけを外して汎用化して公開させていただきました。下記のURLからダウンロード可能です。 https://github.com/aws-samples/knowledge-transfer-by-genai 本ソリューションの範囲 公開版ソリューションのアーキテクチャ概要 　本ソリューションは、AWS CDK (Cloud Deployment Kit) というサービス向けのテンプレートとして提供させていただき、AWS 上に展開しやすくしております。お手持ちのAWSアカウントに10分程度の作業で手間をかける展開できますので、ぜひお試しください。 本ソリューションでは ユーザーは Amazon Bedrock を介してAIとチャット形式でコミュニケーションを取ります。 AIは RAG（Retrieval-Augmented Generation）手法を用いて、Amazon OpenSearch Serverlessから既存の知見を検索し、適切な回答を提供します。 これらの知見は、事前にS3バケットに保存されています。 AIが対応できない既知の明文化された知見で対応できない新しい問題が発生した場合、Amazon Chimeを通じて熟練者とリアルタイムでビデオ通話が可能です。 通話後、Amazon Transcribeが通話を文字起こしし、Amazon Bedrockがその内容を要約します。この新たな知見が追加されることで、将来的なトラブル対応の回答率向上につながります。 このソリューションは、知識の蓄積と効率的な活用による技能伝承を実現し、組織全体の問題解決能力を高めることができます。ぜひ、皆様の環境で試してみてください。ご質問やフィードバックをお待ちしております。 応用例のご紹介 本ソリューションを活用して、 AWS Summit にて展示させていただいたような実物のプラントとIoTサービスを使って連携した応用例をご紹介します。応用例については、こちらの動画も併せてご参照ください。 また、こちらの応用構成は11/21 – 11/22 に東京ビッグサイトで開催されるケミカルマテリアルJapan2024のAWSのブースにて展示いたしますので、お誘いあわせの上ご来場ください。 このソリューションでは、まず設備のデータをPLCで収集し、たけびし社製のデバイスゲートウェイを介してAWS IoT Coreのトピックに取り込みます。PLCから発せられたエラー情報は、Amazon Bedrockを利用して高度な解析を行うことができます。 具体的なアーキテクチャは以下の通りです： デバイスゲートウェイからMQTTプロトコルを使用して、AWS IoTのトピックにPLCのデータを送信します。 IoT Ruleを活用し、PLCのデータはAmazon Timestreamに、アラート情報はAmazon DynamoDBにそれぞれ格納します。 APIを通じて、必要なデータを容易に取り出せるようにします。 ソリューションに AWS IoT Core などを追加接続して、模擬プラントが発するエラーを分析するためのアーキテクチャ 　このアーキテクチャの主なポイントは、リアルタイムデータ収集、効率的なデータ保存、そして柔軟なデータアクセスにあります。MQTTプロトコルを使用することで、低遅延かつ信頼性の高いデータ転送が可能となり、IoT Ruleによって適切なデータベースへのルーティングが自動化されます。 さらに、Amazon Bedrockを活用することで、PLCから発せられたエラー情報に対して過去の作業レポートと突合することで原因だけでなく、具体的な対処方法案の提示が可能になります。これにより、潜在的な問題の早期発見や、予防保全の実現につながる可能性があります。 PLCが発するエラーコードをもとにソリューションが対処案を提示する様子 終わりに このソリューションは、製造業におけるデータ駆動型の意思決定を支援し、生産性の向上やコスト削減に貢献することが期待されます。IoTとAIの融合により、従来は見過ごされていた微細な変化や傾向を捉えることができ、より効率的で高品質な製造プロセスの実現に近づくことができるでしょう。ぜひご活用ください。 著者について 大井 友三 アマゾン ウェブ サービス ジャパン合同会社 ソリューション アーキテクト 日系SIer、外資サーバーメーカーを経てAWS Japan に入社。現在は主に化学・素材などのプロセス製造業のお客様をメインに技術的なご支援をしています。 &nbsp;

本記事は 2024年6月11日に AWS Database Blog で公開された ” Near zero-downtime migrations from self-managed Db2 on AIX or Windows to Amazon RDS for Db2 using IBM Q Replication ” を翻訳したものです。 Db2 は、大規模なトランザクションおよび分析ワークロードをサポートする IBM のリレーショナル・データベースです。 Amazon Relational Database Service (Amazon RDS) for Db2&nbsp; は、クラウドで Db2 データベースのセットアップ、運用、スケーリングを簡単に行えるようにする新しい RDS エンジンです。これにより、お客様はアプリケーションやビジネスに集中できるようになります。 お客様がミッション・クリティカルな Db2 データベースをオンプレミスまたは Amazon Elastic Compute Cloud (Amazon EC2) から Amazon RDS for Db2 に移行する場合の重要な要件の １つはダウンタイムをほぼゼロにすることです。これには次のような理由が考えられます。 テーブルをアンロードしても通常の業務が中断されることはありませんが、アンロードのために勤務時間中にアクセスを停止させると業務に影響がでる 一部の重要なテーブルには、サイズが 1TB を超える数10億のレコードが含まれています。これらの膨大なデータセットは、営業時間外での限られたメンテナンス時間内にはアンロードできない これらの課題には、論理データ・レプリケーションを使用して対処できます。テーブルのロード中の変更をキャプチャすることで、停止する必要はなく、ソース・データベースに接続するアプリケーションへの影響もありません。 データベースを移行するには、最初に全てのデータベース・オブジェクトを再作成し、次にテーブルごとのフルロードを行います。その後、データベース・トランザクション・ログから変更を反映させることができます。 Db2 移行ツール (Db2mt) は、IBM と AWS が共同で開発したツールで、RDS for Db2 へのデータ移行を支援します。Db2MT は GitHub で配布およびサポートされています。問題や機能要望リクエストは、リポジトリ内で直接上げることができます。このツールは、並列処理を使用して全てのデータベース定義とデータをアンロードし、データとデータベース定義をクラウドへアップロードし、Amazon RDS for DB2 へ直接データをロードすることで、移行プロセスを簡素化し、大幅にスピードアップします。 ソリューション概要 このブログでは、IBM InfoSphere Data Replication (IIDR) の Q レプリケーションを使用し、最小限のダウンタイムでデータを移行する方法を説明します。ソース・データベース (オンプレミス) からターゲット・データベース (Amazon RDS for Db2) へデータをレプリケートするように Q レプリケーションを設定する手順を順を追って説明します。移行は、ソース・システムがオンラインのままバックグラウンドで行われます。ターゲット・データベースがフルロードされ、レプリケーション・プロセスによってソースとの同期が保たれたら、全てのデータが同期され、一貫性があることを確認するために短時間停止させるだけで新しいターゲット・データベースへ切り替えられます。 ソリューションアーキテクチャは下図となります。 Amazon EC2 を使用して Q レプリケーション・インスタンスをホストしています。Q レプリケーション・インスタンスは、リモートからソース・データベースの変更をキャプチャし、それらをターゲット RDS for Db2 データベースに適用します。Q レプリケーション・プロセスは、ソース・データベースのリカバリー・ログから抽出された変更をステージングするために IBM MQ を使用し、そのメタ・データを保持するために Db2 インスタンスを使用します。IBM MQ、Db2、Q レプリケーション実行ファイルが EC2 インスタンスにインストールされています。 前提条件 AWS Direct Connect を使用したオンプレミス-AWS間の接続 RDS for Db2 インスタンス データ・マイグレーション用の Db2MT 全てのデータが移行されるまでのソース Db2 のリカバリー・ログの保持 Q レプリケーション環境のセットアップ 有効なアカウントがあれば、 IBM Passport Advantage から IBM MQ および Db2 ソフトウェア・イメージをダウンロードできます。このブログでは、90日間有効な IBM MQ と Db2 エンタープライズのトライアル・ライセンスを使用します。 Q レプリケーション環境をセットアップするために、以下の手順を実行します。 1. 前提条件 に従い EC2 インスタンス (Linux) を構成、IBM MQ インストール 2. MQ ライセンス承諾、キュー・マネージャー作成 (このブログでは、 QMRDS としています） sudo /opt/mqm/bin/mqlicense -accept sudo /opt/mqm/bin/setmqenv -s dspmqver sudo /opt/mqm/bin/crtmqm QMRDS 3. キュー・マネージャー起動 sudo su - mqm /opt/mqm/bin/strmqm QMRDS 4. Db2 インストール tar zxvf v11.5.8_linuxx64_server.tar.gz sudo ./db2setup -f sysreq -r ../db2server.rsp 5. Db2 クライアント・インスタンス作成 sudo su - groupadd db2adm useradd -G db2adm db2rep add db2rep to mqm group cd /rdsdbdata/db2-v11.5.8/instance ./db2icrt -s client db2rep データベース接続のセットアップ データベース名はソースとターゲットで同じでもかまいませんが、ここで作成する Q レプリケーション・インスタンスのエイリアスは異なっていなければなりません。例では、どちらのインスタンスもデータベース名は bench10k ですが、レプリケーションの目的で区別するために、ソースを BENCHS 、ターゲットを BENCHT としてカタログ化しています。 sudo su – db2rep db2 catalog tcpip node source remote source_ip server 25010 db2 catalog tcpip node target remote rds_ip server 50000 db2 catalog db bench10k as benchs at node source db2 catalog db benck10k as benckt at node target mkdir REPL cd REPL asnpwd init asnpwd add alias benchs id db2inst1 password xxxxx asnpwd add alias benckt id admin password xxxxx MQ リソースの作成 MQ リソースを作成するために、以下の手順を実行します。 1. MQ コマンドを呼び出せるように、シェル環境に MQ のパスを追加 sudo su – db2rep 2. .bash_profile に次の行を追加 export PATH=$PATH:$HOME/.local/bin:$HOME/bin:/opt/mqm/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/mqm/lib64\ source bash_profile Q レプリケーションは、IBM MQ のキューを使用して、キャプチャー・プログラムと アプライ・プログラムの間でメッセージを交換し、キャプチャー・プログラムでリカバリー・ログからキャプチャされたデータをトラックし続けます。キャプチャーとアプライは同じインスタンス上で実行されるため、すべてのキューをローカル・キューにすることができます。以下のキューを作成します。 RESTARTQ — 再始動キューは、キャプチャー・プログラムが変更のレプリケート状況を追跡し、停止した場合にどこから再開するかを決定するために使用されます。 これには、処理中で最も古いトランザクションの Db2 log シーケンス番号（LSN）と、既にレプリケートされたトランザクションの最大 Commit LSN が含まれます ADMINQ — 管理キューは、Q キャプチャー・プロセスと Q アプライ・プロセス間の通信に使用されます DATAQ1 — キャプチャー・プロセスによって取得されたトランザクションは、アプライ・プロセスがレプリケートできるようにこのキューにステージングされます。 QDEPTH を999999999（デフォルトは5000）に設定し、アプライ・プログラムが停止した場合やターゲット・データベースが一時的に利用できなくなった場合に無制限の量のデータをステージングできるようにしています 3. 次のコードを使用しキューを作成 runmqsc QMRDS # Execute the below commands in the runmqsc prompt DEFINE QLOCAL ('QASN.ADMINQ') DEFINE QLOCAL ('QASN.RESTARTQ') DEFINE QLOCAL ('QASN.DATAQ1') alter qlocal(QASN.RESTARTQ) MAXDEPTH(1) alter qlocal('QASN.DATAQ1') MAXDEPTH(99999999) end Q レプリケーション・コントロール表の作成 Q レプリケーションのメタ・データ、モニタリング・データ、および生成されるすべてのメッセージは、Db2 テーブルに保存されます。Q レプリケーション asnclp スクリプトを使用して、Q レプリケーション・コントロール表と、移行したいテーブルのレプリケーション・サブスクリプションを作成します。サブスクリプションを作成すると、コントロール表にデータが挿入されます。 asnclp スクリプトは asnclp -f filename として実行されます。 Amazon RDS for Db2 の場合、Q アプライ・コントロール表には独自のテーブル・スペースが必要です。これらのテーブル・スペースは、Amazon RDS for Db2 で直接作成できないため、ストアード・プロシージャーを使用して手動で作成する必要があります。 1. インスタンスの作成に使用した管理者ユーザー名とパスワードを使用して RDS for Db2 インスタンスに接続し、次のコマンドを実行 call rdsadmin.create_bufferpool('BENCH10K', 'BPQASN', 10000, 'Y', 'Y', 8192); call rdsadmin.create_tablespace('BENCH10K', 'QAQASN', 'BPQASN', 8192); call rdsadmin.create_tablespace('BENCH10K', 'TSDONEMG', 'BPQASN', 8192); call rdsadmin.create_tablespace('BENCH10K', 'TSAPCMDOUT', 'BPQASN', 8192); 2. CREATE CONTROL TABLES コマンドで asnclp スクリプトを実行し、レプリケーションに必要なテーブルを作成します。 # # file control.clp - Creating Control Tables for Q Replication # Run with: asnclp -f control.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHS ; SET SERVER TARGET TO DBALIAS BENCHT ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET QMANAGER "QMRDS" FOR CAPTURE SCHEMA; SET QMANAGER "QMRDS" FOR APPLY SCHEMA; SET OUTPUT CAPTURE SCRIPT "crtlcap.sql"; SET OUTPUT TARGET SCRIPT "crtlapp.sql"; #SET RUN SCRIPT LATER ; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; CREATE CONTROL TABLES FOR CAPTURE SERVER USING RESTARTQ "QASN.RESTARTQ" ADMINQ "QASN.ADMINQ"; CREATE CONTROL TABLES FOR APPLY SERVER ; Q レプリケーションでは、ソース・データベースからレプリケートするトランザクションのステージングと送信に使用されるキューを識別する QMAP オブジェクトを作成する必要があります。 3. この構成では、キャプチャーとアプライは同じシステム上で実行され、1つのローカル・キューを使用できます。そのため、 CREATE REPLMAP コマンドでは、ソース・キューとターゲット・キューの名前はどちらも QASN.DATAQ1 となります。 # # File qmap.clp - Creating Q Replication QMAP - run with asnclp -f qmap.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHT ; SET SERVER TARGET TO DBALIAS BENCH ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET QMANAGER "QMRDS" FOR CAPTURE SCHEMA; SET QMANAGER "QMRDS" FOR APPLY SCHEMA; SET OUTPUT CAPTURE SCRIPT "qmapcap.sql"; SET OUTPUT TARGET SCRIPT "qmapapp.sql"; #SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET RUN SCRIPT LATER ; CREATE REPLQMAP BENCHT_TO_BENCH USING ADMINQ "QASN.ADMINQ" RECVQ "QASN.DATAQ1" SENDQ "QASN.DATAQ1" NUM APPLY AGENTS 4; 4. MQ キューを識別する QMAP を定義したら、レプリケーション・サブスクリプションを作成する準備は完了となります。 次のスクリプトは、1 つのスキーマの全てのテーブルのサブスクリプションを作成します。 CREATE QSUB コマンドでは HAS LOAD PHASE N オプション (ロードなし) を指定します。これは、Db2MT を使用してターゲットにテーブルをロードするためです。代わりに HAS LOAD PHASE I (内部ロード用) を指定した場合、デフォルトでは Q レプリケーションはカーソルからのロードを使用し、サブスクリプションがアクティブになると自動的にテーブルをロードします。 ターゲット・データベースに既に必要なオブジェクトが全て含まれている場合は、Db2MT ユーティリティを使用する代わりに内部ロードを検討できます。このブログでは、Db2MT を使用し、ロードなしでサブスクリプションを定義します。これは、非常に大きなテーブルをロードする場合や、ロード後にターゲットを同期する場合にも最速の方法だからです。全てのテーブルを一度に移行するには、この方法が推奨されます。ロードがない場合は、キャプチャーを再起動して、全てのテーブルのロードフェーズ中に行われた全ての変更を読み取ります。テーブルのロード中に キャプチャーを実行し、それらの変更を MQ に反映させる必要はありません。もし既に稼働しているレプリケーション構成があり、アクティブなレプリケーション・サブスクリプションを中断せずにテーブルを段階的に追加する必要がある場合は、自動ロードが適切です。 # # File sub.clp - Creating subscriptions for all tables under a SCHEMA # # Run with asnclp -f sub.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHT ; SET SERVER TARGET TO DBALIAS BENCH ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET OUTPUT CAPTURE SCRIPT "capsub.sql"; SET OUTPUT TARGET SCRIPT "appsub.sql"; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; #SET RUN SCRIPT LATER ; CREATE QSUB USING REPLQMAP BENCHT_TO_BENCH (SRC OWNER LIKE "RDSDB" SRC NAME LIKE "%" OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN YES EXIST TARGET TABLE OWNER SAME AS SOURCE TABLE NAME SAME AS SOURCE TRGCOLS ALL CONFLICT ACTION F ERROR ACTION S ); このブログで説明している手順は、ソース Db2 インスタンスのバージョン 11.5FP8 以降であることを前提としています。このバージョンでは、タイムス・タンプを使用し、後からキャプチャプログラムを再起動できるため、手順が大幅に簡略化されます。ソース Db2 が下位バージョンの場合、サブスクリプションを次のように定義します。サブスクリプションに OKSQLSTATE を指定することで、データ移行後に追いつきながらレプリケーションの例外をマスクします。 CREATE QSUB USING REPLQMAP BENCHT_TO_BENCH (SRC OWNER LIKE "RDSDB" SRC NAME LIKE "%" OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN YES EXIST TARGET TABLE OWNER SAME AS SOURCE TABLE NAME SAME AS SOURCE TRGCOLS ALL CONFLICT ACTION F ERROR ACTION S OKSQLSTATE "02000" ); レプリケーションを開始しサブスクリプションを有効化 キャプチャーおよびアプライ・プログラムを開始して、全てのサブスクリプションが正常にアクティブ化できることを確認します。v11.5FP8 より前のバージョンでは、これによりソースDb2 ログを読み取るためのリスタート・ポイントも設定されます。 asnqcap capture_server=BENCHS capture_schema=QASN startmode=warmsi &amp; asnqccmd capture_server=BENCHS capture_schema=QASN stop asnqapp apply_server=BENCHT apply_schema=QASN apply_path="/home/db2rep/REPL" &amp; asnqacmd apply_server=BENCHT apply_schema=QASN stop 次の SQL クエリを実行すると、サブスクリプションの状態を確認できます。 connect to BENCHT; select substr(subname,1,8)as subname, substr(recvq,1,10) as recvq, substr(target_owner,1,8) as owner, substr(target_name,1,20) as tablename, has_loadphase, STATE from qasn.ibmqrep_targets; RDR for Db2 環境のセットアップ RDS for Db2 クラスターを作成及び、設定する手順については、 こちら を参照してください。Q レプリケーション・インスタンスが RDS for Db2 クラスターと同じサブネットにあることを確認してください。 Db2MT を使用したデータ移行 全てのデータの移行を開始する前に、処理中の全てのトランザクションがコミットされる時間を把握する必要があります。これは、データ移行中に発生した変更を Db2 リカバリー・ログからキャプチャし、全ての変更がデータ移行に含まれるか、ログから読み取れることを保証する必要があるためです。 まだコミットされていない最も早いトランザクションの開始時間を取得するには、次のクエリを実行して実行中のトランザクションを全て確認します。クエリが空の場合、現在コミットされていないトランザクションはなく、クエリを実行した現在の時間で十分です。 SELECT con.application_handle, con.application_id, con.application_name, con.client_pid, uow.uow_start_time, uow.uow_log_space_used FROM table(mon_get_connection(cast(null as bigint), -1)) as con, table(mon_get_unit_of_work(null, -1)) as uow WHERE con.application_handle = uow.application_handle and uow.uow_log_space_used != 0 ORDER BY uow.uow_start_time オープンソースの Db2MT は、Db2 データベースを使用したデータ移行を簡素化します。Go で書かれた Db2MT は、生成するスクリプトをカスタマイズするための拡張可能なアーキテクチャを備えています。これらのスクリプトを使用すると、実行前に移行プロセスを検証できます。 Db2 のバックアップは通常、同じプラットフォーム・ファミリー内でのみ復元できます。ただし、Linux と UNIX では、バックアップ先と復元先のエンディアンが一致していれば、以前のバージョンからバックアップを復元できます。そうしないと、DDL、データをエクスポートしたり、ターゲット・データベースでオブジェクトを再作成したりする複雑なプロセスが必要になります。 Db2MT を使用すると、この移行プロセス全体が簡素化されます。Db2MT は、ソース・データベースからエクスポートしてターゲットにインポートするために必要なスクリプトを生成し、オブジェクトの再作成とデータロードを処理します。これにより、Db2 データベースの移行が簡単かつ効率的になります。 Db2MT を使用しAIX ソース・データベースから RDS for Db2 へデータを移行 AWS に直接接続している場合、Db2MT は AIX/Windows サーバーまたは Db2 クライアントに直接インストールできます。Db2MT は、ネイティブの db2look を使用して忠実度の高いメタ・データを取得し、複数のパスとチャンク・アップロードを使用して Db2 サーバーから Amazon Simple Storage Service （Amazon S3）にデータを直接アンロードするための並列パスを構築します。Db2MT は GO SDK を使用してデータを直接 Amazon S3 にアップロードします。これは、AIX には AWS Command Line Interface (AWS CLI) がないためです。Db2MT は IXF 形式を使用して最大限のデータ正確性を維持し、クライアント・マシンのコード・ページの影響を受けずにデータを転送します。 Db2MT を使用し Linux ソース・データベースから RDS for Db2 へデータを移行 Db2MT は、データベースのサイズに応じて複数のパスを使用して、オフラインおよびオンラインのデータベース・バックアップを Db2 クライアントから Amazon S3 に直接作成します。Amazon RDS for Db2 に接続している同じまたは別の Db2 クライアントは、RDS for Db2 ストアード・プロシージャー&nbsp; RDSADMIN_RESTORE を実行して、Amazon S3 からオフラインまたはオンラインのデータベース・バックアップを復元できます。オプションで、オンライン・バックアップのアーカイブ・ログを適用して変更を同期できます。 レプリケーションを再開し移行中の全ての変更をキャプチャ Db2MT を使用したデータ・ロードが完了したら、Q レプリケーションを再起動して、変更のバック・ログをターゲット・データベース (Amazon RDS for Db2) に適用できます。 必ず、データ移行が開始される前に キャプチャー・プログラムを再起動し、Db2MT の起動時にまだコミットされていない (処理中の) トランザクションを全てキャプチャできるように、リカバリー・ログに戻ってください。Db2 V11.5FP8 以降では、以前に取得したタイムス・タンプを Q キャプチャーに提供できます。Q キャプチャーは、このタイム・スタンプを LSN にマッピングし、そこからログ・レコードの読み取りを開始します。以前のバージョンでは、LSN パラメータには LSN が必要でしたが、取得が難しい場合があります。V11FP8 より前のバージョンでは、再起動 LSN を提供する代わりに、サブスクリプションに OKSQLSTATES を設定して例外を無視するようにしました。ただし、移行が完了した後もレプリケーションを引き続き使用する場合は、サブスクリプションを変更してこのオプションを削除する必要があります。そうしないと、レプリケーションの例外を検出できません。 キャプチャーを LSN パラメーター（タイム・スタンプまたは実際の LSN のいずれか）で再起動すると、最後に停止した場所からの再起動（ウォーム・スタートとも呼ばれます）ではなく、ターゲット・データベースの一貫性を回復するために変更が適用され、競合が解消されます。このキャッチアップ期間中は、ソース・アプリケーションがまだ実行されている間にデータの読み取りとコピーが行われていたため、データの不一致が起こることが予想されます。このキャッチアップ期間中は、例外は報告されません。キャプチャ開始時刻までに全ての変更が複製されると、通常の処理が再開され、データ不一致の例外が報告されます。 例えば、Db2MT を 10:22 に起動し、まだコミットされていない最長のトランザクションが 10 分前に開始された場合は、キャプチャーを再起動して 10:12 からログを読み取ることができます。 asnqcap capture_server=BENCHS capture_schema=QASN LSN=2023-11-03-10.12.01.000001MAXCMTSEQ=0 &amp; asnqapp apply_server=BENCHT apply_schema=QASN apply_path="/home/db2rep/REPL" &amp; 監視テーブルからクエリを実行することで、レプリケーション・プロセスの進行状況を追跡できます。 db2 connect to BENCHT; db2 "select MONITOR_TIME, END2END_LATENCY, ROWS_APPLIED, OLDEST_TRANS from QASN.IBMQREP_APPLYMON order by MONITOR_TIME DESC fetch first 20 rows only with ur" END2END_LATENCY はミリ秒単位で報告されます。これは、監視間隔（デフォルトは 30 秒）中に適用された全てのトランザクションについて、ソースでのコミットからターゲットでのコミットまでの平均経過時間です。 OLDEST_TRANS は、ターゲット ・データベースの現在のポイント・イン・タイム整合性であり、その時点までにソースからの全てのトランザクションが適用されています。OLDEST_TRANS が現在時刻に近づくと、すべてのデータがソースと一致していることがわかり、カットオーバーを開始できます。 まとめ このブログでは、オンプレミスの Db2 on POWER を Amazon RDS for Db2 に移行する手順を説明しました。ソリューションの概要、リモートのキャプチャーとアプライを使用した Q レプリケーションの設定、RDS for Db2 インスタンス の作成、データ移行に Db2MT を使用する詳細な手順などが含まれています。 ご質問、ご意見、ご提案がございましたら、コメントを残してください。 本記事はカスタマーソリューションマネージャの髙木 昇が 2024年6月11日に AWS Database Blog で公開された ” Near zero-downtime migrations from self-managed Db2 on AIX or Windows to Amazon RDS for Db2 using IBM Q Replication ” を翻訳したものです。

本記事は 2024年6月11日に AWS Database Blog で公開された ” Near zero-downtime migrations from self-managed Db2 on AIX or Windows to Amazon RDS for Db2 using IBM Q Replication ” を翻訳したものです。 Db2 は、大規模なトランザクションおよび分析ワークロードをサポートする IBM のリレーショナル・データベースです。 Amazon Relational Database Service (Amazon RDS) for Db2&nbsp; は、クラウドで Db2 データベースのセットアップ、運用、スケーリングを簡単に行えるようにする新しい RDS エンジンです。これにより、お客様はアプリケーションやビジネスに集中できるようになります。 お客様がミッション・クリティカルな Db2 データベースをオンプレミスまたは Amazon Elastic Compute Cloud (Amazon EC2) から Amazon RDS for Db2 に移行する場合の重要な要件の １つはダウンタイムをほぼゼロにすることです。これには次のような理由が考えられます。 テーブルをアンロードしても通常の業務が中断されることはありませんが、アンロードのために勤務時間中にアクセスを停止させると業務に影響がでる 一部の重要なテーブルには、サイズが 1TB を超える数10億のレコードが含まれています。これらの膨大なデータセットは、営業時間外での限られたメンテナンス時間内にはアンロードできない これらの課題には、論理データ・レプリケーションを使用して対処できます。テーブルのロード中の変更をキャプチャすることで、停止する必要はなく、ソース・データベースに接続するアプリケーションへの影響もありません。 データベースを移行するには、最初に全てのデータベース・オブジェクトを再作成し、次にテーブルごとのフルロードを行います。その後、データベース・トランザクション・ログから変更を反映させることができます。 Db2 移行ツール (Db2mt) は、IBM と AWS が共同で開発したツールで、RDS for Db2 へのデータ移行を支援します。Db2MT は GitHub で配布およびサポートされています。問題や機能要望リクエストは、リポジトリ内で直接上げることができます。このツールは、並列処理を使用して全てのデータベース定義とデータをアンロードし、データとデータベース定義をクラウドへアップロードし、Amazon RDS for DB2 へ直接データをロードすることで、移行プロセスを簡素化し、大幅にスピードアップします。 ソリューション概要 このブログでは、IBM InfoSphere Data Replication (IIDR) の Q レプリケーションを使用し、最小限のダウンタイムでデータを移行する方法を説明します。ソース・データベース (オンプレミス) からターゲット・データベース (Amazon RDS for Db2) へデータをレプリケートするように Q レプリケーションを設定する手順を順を追って説明します。移行は、ソース・システムがオンラインのままバックグラウンドで行われます。ターゲット・データベースがフルロードされ、レプリケーション・プロセスによってソースとの同期が保たれたら、全てのデータが同期され、一貫性があることを確認するために短時間停止させるだけで新しいターゲット・データベースへ切り替えられます。 ソリューションアーキテクチャは下図となります。 Amazon EC2 を使用して Q レプリケーション・インスタンスをホストしています。Q レプリケーション・インスタンスは、リモートからソース・データベースの変更をキャプチャし、それらをターゲット RDS for Db2 データベースに適用します。Q レプリケーション・プロセスは、ソース・データベースのリカバリー・ログから抽出された変更をステージングするために IBM MQ を使用し、そのメタ・データを保持するために Db2 インスタンスを使用します。IBM MQ、Db2、Q レプリケーション実行ファイルが EC2 インスタンスにインストールされています。 前提条件 AWS Direct Connect を使用したオンプレミス-AWS間の接続 RDS for Db2 インスタンス データ・マイグレーション用の Db2MT 全てのデータが移行されるまでのソース Db2 のリカバリー・ログの保持 Q レプリケーション環境のセットアップ 有効なアカウントがあれば、 IBM Passport Advantage から IBM MQ および Db2 ソフトウェア・イメージをダウンロードできます。このブログでは、90日間有効な IBM MQ と Db2 エンタープライズのトライアル・ライセンスを使用します。 Q レプリケーション環境をセットアップするために、以下の手順を実行します。 1. 前提条件 に従い EC2 インスタンス (Linux) を構成、IBM MQ インストール 2. MQ ライセンス承諾、キュー・マネージャー作成 (このブログでは、 QMRDS としています） sudo /opt/mqm/bin/mqlicense -accept sudo /opt/mqm/bin/setmqenv -s dspmqver sudo /opt/mqm/bin/crtmqm QMRDS 3. キュー・マネージャー起動 sudo su - mqm /opt/mqm/bin/strmqm QMRDS 4. Db2 インストール tar zxvf v11.5.8_linuxx64_server.tar.gz sudo ./db2setup -f sysreq -r ../db2server.rsp 5. Db2 クライアント・インスタンス作成 sudo su - groupadd db2adm useradd -G db2adm db2rep add db2rep to mqm group cd /rdsdbdata/db2-v11.5.8/instance ./db2icrt -s client db2rep データベース接続のセットアップ データベース名はソースとターゲットで同じでもかまいませんが、ここで作成する Q レプリケーション・インスタンスのエイリアスは異なっていなければなりません。例では、どちらのインスタンスもデータベース名は bench10k ですが、レプリケーションの目的で区別するために、ソースを BENCHS 、ターゲットを BENCHT としてカタログ化しています。 sudo su – db2rep db2 catalog tcpip node source remote source_ip server 25010 db2 catalog tcpip node target remote rds_ip server 50000 db2 catalog db bench10k as benchs at node source db2 catalog db benck10k as benckt at node target mkdir REPL cd REPL asnpwd init asnpwd add alias benchs id db2inst1 password xxxxx asnpwd add alias benckt id admin password xxxxx MQ リソースの作成 MQ リソースを作成するために、以下の手順を実行します。 1. MQ コマンドを呼び出せるように、シェル環境に MQ のパスを追加 sudo su – db2rep 2. .bash_profile に次の行を追加 export PATH=$PATH:$HOME/.local/bin:$HOME/bin:/opt/mqm/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/mqm/lib64\ source bash_profile Q レプリケーションは、IBM MQ のキューを使用して、キャプチャー・プログラムと アプライ・プログラムの間でメッセージを交換し、キャプチャー・プログラムでリカバリー・ログからキャプチャされたデータをトラックし続けます。キャプチャーとアプライは同じインスタンス上で実行されるため、すべてのキューをローカル・キューにすることができます。以下のキューを作成します。 RESTARTQ — 再始動キューは、キャプチャー・プログラムが変更のレプリケート状況を追跡し、停止した場合にどこから再開するかを決定するために使用されます。 これには、処理中で最も古いトランザクションの Db2 log シーケンス番号（LSN）と、既にレプリケートされたトランザクションの最大 Commit LSN が含まれます ADMINQ — 管理キューは、Q キャプチャー・プロセスと Q アプライ・プロセス間の通信に使用されます DATAQ1 — キャプチャー・プロセスによって取得されたトランザクションは、アプライ・プロセスがレプリケートできるようにこのキューにステージングされます。 QDEPTH を999999999（デフォルトは5000）に設定し、アプライ・プログラムが停止した場合やターゲット・データベースが一時的に利用できなくなった場合に無制限の量のデータをステージングできるようにしています 3. 次のコードを使用しキューを作成 runmqsc QMRDS # Execute the below commands in the runmqsc prompt DEFINE QLOCAL ('QASN.ADMINQ') DEFINE QLOCAL ('QASN.RESTARTQ') DEFINE QLOCAL ('QASN.DATAQ1') alter qlocal(QASN.RESTARTQ) MAXDEPTH(1) alter qlocal('QASN.DATAQ1') MAXDEPTH(99999999) end Q レプリケーション・コントロール表の作成 Q レプリケーションのメタ・データ、モニタリング・データ、および生成されるすべてのメッセージは、Db2 テーブルに保存されます。Q レプリケーション asnclp スクリプトを使用して、Q レプリケーション・コントロール表と、移行したいテーブルのレプリケーション・サブスクリプションを作成します。サブスクリプションを作成すると、コントロール表にデータが挿入されます。 asnclp スクリプトは asnclp -f filename として実行されます。 Amazon RDS for Db2 の場合、Q アプライ・コントロール表には独自のテーブル・スペースが必要です。これらのテーブル・スペースは、Amazon RDS for Db2 で直接作成できないため、ストアード・プロシージャーを使用して手動で作成する必要があります。 1. インスタンスの作成に使用した管理者ユーザー名とパスワードを使用して RDS for Db2 インスタンスに接続し、次のコマンドを実行 call rdsadmin.create_bufferpool('BENCH10K', 'BPQASN', 10000, 'Y', 'Y', 8192); call rdsadmin.create_tablespace('BENCH10K', 'QAQASN', 'BPQASN', 8192); call rdsadmin.create_tablespace('BENCH10K', 'TSDONEMG', 'BPQASN', 8192); call rdsadmin.create_tablespace('BENCH10K', 'TSAPCMDOUT', 'BPQASN', 8192); 2. CREATE CONTROL TABLES コマンドで asnclp スクリプトを実行し、レプリケーションに必要なテーブルを作成します。 # # file control.clp - Creating Control Tables for Q Replication # Run with: asnclp -f control.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHS ; SET SERVER TARGET TO DBALIAS BENCHT ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET QMANAGER "QMRDS" FOR CAPTURE SCHEMA; SET QMANAGER "QMRDS" FOR APPLY SCHEMA; SET OUTPUT CAPTURE SCRIPT "crtlcap.sql"; SET OUTPUT TARGET SCRIPT "crtlapp.sql"; #SET RUN SCRIPT LATER ; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; CREATE CONTROL TABLES FOR CAPTURE SERVER USING RESTARTQ "QASN.RESTARTQ" ADMINQ "QASN.ADMINQ"; CREATE CONTROL TABLES FOR APPLY SERVER ; Q レプリケーションでは、ソース・データベースからレプリケートするトランザクションのステージングと送信に使用されるキューを識別する QMAP オブジェクトを作成する必要があります。 3. この構成では、キャプチャーとアプライは同じシステム上で実行され、1つのローカル・キューを使用できます。そのため、 CREATE REPLMAP コマンドでは、ソース・キューとターゲット・キューの名前はどちらも QASN.DATAQ1 となります。 # # File qmap.clp - Creating Q Replication QMAP - run with asnclp -f qmap.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHT ; SET SERVER TARGET TO DBALIAS BENCH ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET QMANAGER "QMRDS" FOR CAPTURE SCHEMA; SET QMANAGER "QMRDS" FOR APPLY SCHEMA; SET OUTPUT CAPTURE SCRIPT "qmapcap.sql"; SET OUTPUT TARGET SCRIPT "qmapapp.sql"; #SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET RUN SCRIPT LATER ; CREATE REPLQMAP BENCHT_TO_BENCH USING ADMINQ "QASN.ADMINQ" RECVQ "QASN.DATAQ1" SENDQ "QASN.DATAQ1" NUM APPLY AGENTS 4; 4. MQ キューを識別する QMAP を定義したら、レプリケーション・サブスクリプションを作成する準備は完了となります。 次のスクリプトは、1 つのスキーマの全てのテーブルのサブスクリプションを作成します。 CREATE QSUB コマンドでは HAS LOAD PHASE N オプション (ロードなし) を指定します。これは、Db2MT を使用してターゲットにテーブルをロードするためです。代わりに HAS LOAD PHASE I (内部ロード用) を指定した場合、デフォルトでは Q レプリケーションはカーソルからのロードを使用し、サブスクリプションがアクティブになると自動的にテーブルをロードします。 ターゲット・データベースに既に必要なオブジェクトが全て含まれている場合は、Db2MT ユーティリティを使用する代わりに内部ロードを検討できます。このブログでは、Db2MT を使用し、ロードなしでサブスクリプションを定義します。これは、非常に大きなテーブルをロードする場合や、ロード後にターゲットを同期する場合にも最速の方法だからです。全てのテーブルを一度に移行するには、この方法が推奨されます。ロードがない場合は、キャプチャーを再起動して、全てのテーブルのロードフェーズ中に行われた全ての変更を読み取ります。テーブルのロード中に キャプチャーを実行し、それらの変更を MQ に反映させる必要はありません。もし既に稼働しているレプリケーション構成があり、アクティブなレプリケーション・サブスクリプションを中断せずにテーブルを段階的に追加する必要がある場合は、自動ロードが適切です。 # # File sub.clp - Creating subscriptions for all tables under a SCHEMA # # Run with asnclp -f sub.clp # ASNCLP SESSION SET TO Q REPLICATION; SET PWDFILE "/home/db2rep/REPL/asnpwd.aut"; SET SERVER CAPTURE TO DBALIAS BENCHT ; SET SERVER TARGET TO DBALIAS BENCH ; SET APPLY SCHEMA QASN; SET CAPTURE SCHEMA SOURCE QASN; SET OUTPUT CAPTURE SCRIPT "capsub.sql"; SET OUTPUT TARGET SCRIPT "appsub.sql"; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; #SET RUN SCRIPT LATER ; CREATE QSUB USING REPLQMAP BENCHT_TO_BENCH (SRC OWNER LIKE "RDSDB" SRC NAME LIKE "%" OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN YES EXIST TARGET TABLE OWNER SAME AS SOURCE TABLE NAME SAME AS SOURCE TRGCOLS ALL CONFLICT ACTION F ERROR ACTION S ); このブログで説明している手順は、ソース Db2 インスタンスのバージョン 11.5FP8 以降であることを前提としています。このバージョンでは、タイムス・タンプを使用し、後からキャプチャプログラムを再起動できるため、手順が大幅に簡略化されます。ソース Db2 が下位バージョンの場合、サブスクリプションを次のように定義します。サブスクリプションに OKSQLSTATE を指定することで、データ移行後に追いつきながらレプリケーションの例外をマスクします。 CREATE QSUB USING REPLQMAP BENCHT_TO_BENCH (SRC OWNER LIKE "RDSDB" SRC NAME LIKE "%" OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN YES EXIST TARGET TABLE OWNER SAME AS SOURCE TABLE NAME SAME AS SOURCE TRGCOLS ALL CONFLICT ACTION F ERROR ACTION S OKSQLSTATE "02000" ); レプリケーションを開始しサブスクリプションを有効化 キャプチャーおよびアプライ・プログラムを開始して、全てのサブスクリプションが正常にアクティブ化できることを確認します。v11.5FP8 より前のバージョンでは、これによりソースDb2 ログを読み取るためのリスタート・ポイントも設定されます。 asnqcap capture_server=BENCHS capture_schema=QASN startmode=warmsi &amp; asnqccmd capture_server=BENCHS capture_schema=QASN stop asnqapp apply_server=BENCHT apply_schema=QASN apply_path="/home/db2rep/REPL" &amp; asnqacmd apply_server=BENCHT apply_schema=QASN stop 次の SQL クエリを実行すると、サブスクリプションの状態を確認できます。 connect to BENCHT; select substr(subname,1,8)as subname, substr(recvq,1,10) as recvq, substr(target_owner,1,8) as owner, substr(target_name,1,20) as tablename, has_loadphase, STATE from qasn.ibmqrep_targets; RDR for Db2 環境のセットアップ RDS for Db2 クラスターを作成及び、設定する手順については、 こちら を参照してください。Q レプリケーション・インスタンスが RDS for Db2 クラスターと同じサブネットにあることを確認してください。 Db2MT を使用したデータ移行 全てのデータの移行を開始する前に、処理中の全てのトランザクションがコミットされる時間を把握する必要があります。これは、データ移行中に発生した変更を Db2 リカバリー・ログからキャプチャし、全ての変更がデータ移行に含まれるか、ログから読み取れることを保証する必要があるためです。 まだコミットされていない最も早いトランザクションの開始時間を取得するには、次のクエリを実行して実行中のトランザクションを全て確認します。クエリが空の場合、現在コミットされていないトランザクションはなく、クエリを実行した現在の時間で十分です。 SELECT con.application_handle, con.application_id, con.application_name, con.client_pid, uow.uow_start_time, uow.uow_log_space_used FROM table(mon_get_connection(cast(null as bigint), -1)) as con, table(mon_get_unit_of_work(null, -1)) as uow WHERE con.application_handle = uow.application_handle and uow.uow_log_space_used != 0 ORDER BY uow.uow_start_time オープンソースの Db2MT は、Db2 データベースを使用したデータ移行を簡素化します。Go で書かれた Db2MT は、生成するスクリプトをカスタマイズするための拡張可能なアーキテクチャを備えています。これらのスクリプトを使用すると、実行前に移行プロセスを検証できます。 Db2 のバックアップは通常、同じプラットフォーム・ファミリー内でのみ復元できます。ただし、Linux と UNIX では、バックアップ先と復元先のエンディアンが一致していれば、以前のバージョンからバックアップを復元できます。そうしないと、DDL、データをエクスポートしたり、ターゲット・データベースでオブジェクトを再作成したりする複雑なプロセスが必要になります。 Db2MT を使用すると、この移行プロセス全体が簡素化されます。Db2MT は、ソース・データベースからエクスポートしてターゲットにインポートするために必要なスクリプトを生成し、オブジェクトの再作成とデータロードを処理します。これにより、Db2 データベースの移行が簡単かつ効率的になります。 Db2MT を使用しAIX ソース・データベースから RDS for Db2 へデータを移行 AWS に直接接続している場合、Db2MT は AIX/Windows サーバーまたは Db2 クライアントに直接インストールできます。Db2MT は、ネイティブの db2look を使用して忠実度の高いメタ・データを取得し、複数のパスとチャンク・アップロードを使用して Db2 サーバーから Amazon Simple Storage Service （Amazon S3）にデータを直接アンロードするための並列パスを構築します。Db2MT は GO SDK を使用してデータを直接 Amazon S3 にアップロードします。これは、AIX には AWS Command Line Interface (AWS CLI) がないためです。Db2MT は IXF 形式を使用して最大限のデータ正確性を維持し、クライアント・マシンのコード・ページの影響を受けずにデータを転送します。 Db2MT を使用し Linux ソース・データベースから RDS for Db2 へデータを移行 Db2MT は、データベースのサイズに応じて複数のパスを使用して、オフラインおよびオンラインのデータベース・バックアップを Db2 クライアントから Amazon S3 に直接作成します。Amazon RDS for Db2 に接続している同じまたは別の Db2 クライアントは、RDS for Db2 ストアード・プロシージャー&nbsp; RDSADMIN_RESTORE を実行して、Amazon S3 からオフラインまたはオンラインのデータベース・バックアップを復元できます。オプションで、オンライン・バックアップのアーカイブ・ログを適用して変更を同期できます。 レプリケーションを再開し移行中の全ての変更をキャプチャ Db2MT を使用したデータ・ロードが完了したら、Q レプリケーションを再起動して、変更のバック・ログをターゲット・データベース (Amazon RDS for Db2) に適用できます。 必ず、データ移行が開始される前に キャプチャー・プログラムを再起動し、Db2MT の起動時にまだコミットされていない (処理中の) トランザクションを全てキャプチャできるように、リカバリー・ログに戻ってください。Db2 V11.5FP8 以降では、以前に取得したタイムス・タンプを Q キャプチャーに提供できます。Q キャプチャーは、このタイム・スタンプを LSN にマッピングし、そこからログ・レコードの読み取りを開始します。以前のバージョンでは、LSN パラメータには LSN が必要でしたが、取得が難しい場合があります。V11FP8 より前のバージョンでは、再起動 LSN を提供する代わりに、サブスクリプションに OKSQLSTATES を設定して例外を無視するようにしました。ただし、移行が完了した後もレプリケーションを引き続き使用する場合は、サブスクリプションを変更してこのオプションを削除する必要があります。そうしないと、レプリケーションの例外を検出できません。 キャプチャーを LSN パラメーター（タイム・スタンプまたは実際の LSN のいずれか）で再起動すると、最後に停止した場所からの再起動（ウォーム・スタートとも呼ばれます）ではなく、ターゲット・データベースの一貫性を回復するために変更が適用され、競合が解消されます。このキャッチアップ期間中は、ソース・アプリケーションがまだ実行されている間にデータの読み取りとコピーが行われていたため、データの不一致が起こることが予想されます。このキャッチアップ期間中は、例外は報告されません。キャプチャ開始時刻までに全ての変更が複製されると、通常の処理が再開され、データ不一致の例外が報告されます。 例えば、Db2MT を 10:22 に起動し、まだコミットされていない最長のトランザクションが 10 分前に開始された場合は、キャプチャーを再起動して 10:12 からログを読み取ることができます。 asnqcap capture_server=BENCHS capture_schema=QASN LSN=2023-11-03-10.12.01.000001MAXCMTSEQ=0 &amp; asnqapp apply_server=BENCHT apply_schema=QASN apply_path="/home/db2rep/REPL" &amp; 監視テーブルからクエリを実行することで、レプリケーション・プロセスの進行状況を追跡できます。 db2 connect to BENCHT; db2 "select MONITOR_TIME, END2END_LATENCY, ROWS_APPLIED, OLDEST_TRANS from QASN.IBMQREP_APPLYMON order by MONITOR_TIME DESC fetch first 20 rows only with ur" END2END_LATENCY はミリ秒単位で報告されます。これは、監視間隔（デフォルトは 30 秒）中に適用された全てのトランザクションについて、ソースでのコミットからターゲットでのコミットまでの平均経過時間です。 OLDEST_TRANS は、ターゲット ・データベースの現在のポイント・イン・タイム整合性であり、その時点までにソースからの全てのトランザクションが適用されています。OLDEST_TRANS が現在時刻に近づくと、すべてのデータがソースと一致していることがわかり、カットオーバーを開始できます。 まとめ このブログでは、オンプレミスの Db2 on POWER を Amazon RDS for Db2 に移行する手順を説明しました。ソリューションの概要、リモートのキャプチャーとアプライを使用した Q レプリケーションの設定、RDS for Db2 インスタンス の作成、データ移行に Db2MT を使用する詳細な手順などが含まれています。 ご質問、ご意見、ご提案がございましたら、コメントを残してください。 本記事はカスタマーソリューションマネージャの髙木 昇が 2024年6月11日に AWS Database Blog で公開された ” Near zero-downtime migrations from self-managed Db2 on AIX or Windows to Amazon RDS for Db2 using IBM Q Replication ” を翻訳したものです。

このブログでは、Amazon Kinesis Firehose、Amazon Athena、Amazon QuickSight などの AWS サービスを使用して、お客様のメール閲覧状況などの詳細を把握するために必要な粒度の Amazon SES のメール送信イベントを監視する方法を説明します。 現在、E メールマーケターはニュースレターやプロモーションコンテンツなど、キャンペーンやコミュニケーション方法を作るために内部アプリケーションに依存しています。 これらの活動から、顧客とのより良いインタラクションを得るためにワークフローを分析して改善し、より多くの情報を収集する必要があります。 バウンス、拒否、受信成功、配信遅延、苦情、開封率などのデータは顧客を理解するための強力なツールとなります。 通常のアプリケーションは、キャンペーンの効果をより高めるための詳細なログやデータを提供していないため、高レベルの情報しか扱えません。 Amazon Simple Email Service (SES ) は自身の製品に簡単に統合でき、コスト効率の良い柔軟でスケーラブルなメールサービスソリューションを求める企業向けのツールです。 Amazon SES は、Amazon CloudWatch Metrics との組み込み統合により送信活動を管理できる機能を提供し、メール送信イベントデータを収集するメカニズムも提供します。 このブログでは、送信、配信、開封、クリック、バウンス、苦情、拒否、レンダリング失敗、配信遅延などさまざまな種類のメール送信イベントに対して詳細にメール送信アクティビティを追跡するためのアーキテクチャと段階的なガイドを提案します。 Amazon SES の 設定セット 機能を使用して、詳細なログを分析サービスに送信し、そこでデータを保存、クエリ、詳細なビューのダッシュボードを作成します。 ソリューションの概要 このアーキテクチャでは、Amazon SES の組み込み機能と AWS の分析サービスを利用して、メール追跡の要件に対する迅速かつ低コストのソリューションを提供します。 以下のサービスから構成されます。 Amazon Simple Email Service (SES) Amazon Simple Storage Service (S3) Amazon Kinesis Data Firehose Amazon Athena AWS Glue データカタログ Amazon QuickSight 次の図はこのソリューションのアーキテクチャを示しています。 図 1. Amazon SES イベントを分析するためのサーバーレスアーキテクチャ お客様が Amazon SES を使用してメールを送信すると、イベントのフローが開始されます。それらの送信イベントはすべて、設定セット機能によってキャプチャされ、Kinesis Firehose 配信ストリームに転送されます。そこでイベントがバッファされ、Amazon S3 バケットに保存されます。 イベントを保存した後、Amazon Athena が S3 上のそれらのイベントを適切にクエリできるように、データベースとテーブルスキーマを作成し、AWS Glue Data Catalog に格納する必要があります。 最後に、Amazon QuickSight を使用して、インタラクティブなダッシュボードを作成し、メールごとの詳細情報を示して、送信アクティビティ全体を検索および可視化します。 前提条件 このウォークスルーを行うには、以下の前提条件を満たしている必要があります: AWS アカウント 本番稼働アクセスの SES ドメイン Amazon S3、Amazon Athena、AWS Glue Data Catalog、Amazon Kinesis Firehose、Amazon QuickSight を構成するための適切な IAM の権限 Author ユーザーが作成した QuickSight インスタンス ウォークスルー ステップ 1: AWS CloudFormation を使用して、追加の前提条件をデプロイする AWS CloudFormation のサンプルテンプレート を使えば、前提条件をいくつか含めて始められます。 このテンプレートは、Amazon S3 バケットと、Amazon SES から Amazon Kinesis Data Firehose にアクセスするために必要な IAM ロールを作成します。 CloudFormation テンプレートをダウンロードするには、お使いの OS に応じて以下のコマンドのいずれかを実行してください: Windows の場合: curl https://raw.githubusercontent.com/aws-samples/amazon-ses-analytics-blog/main/SES-Blog-PreRequisites.yml -o SES-Blog-PreRequisites.yml MacOS の場合: wget https://raw.githubusercontent.com/aws-samples/amazon-ses-analytics-blog/main/SES-Blog-PreRequisites.yml テンプレートをデプロイするには、次の AWS CLI コマンドを使用します: aws cloudformation deploy --template-file ./SES-Blog-PreRequisites.yml --stack-name ses-dashboard-prerequisites --capabilities CAPABILITY_NAMED_IAM テンプレートがリソースの作成を完了すると、スタックの出力タブに IAM サービスロールと配信ストリームが表示されます。 これらのリソースは次の手順で使用します。 図 2. CloudFormation テンプレートの出力 ステップ 2: SES で設定セットを作成し、検証済みの ID のデフォルト設定セットを設定する SES は、送信したメールごとに送信、配信、開封、クリック、バウンス、苦情のイベント数を追跡できます。イベントパブリッシングを使用すると、これらのイベントに関する情報を他の AWS サービスに送信できます。今回は、イベントを Kinesis Firehose に送信します。そのためには、設定セットが必要です。 設定セットを作成するには、以下の手順を実行してください: AWS コンソールで、 Amazon Simple Email Service を選択します。 Configuration sets を選択します。 Create set をクリックします。 図 3. Amazon SES Create Configuration Set Configuration set name を設定します。 他の設定はデフォルトのままにしておきます。 図 4. Configuration Set Name 設定セットが作成されたら、 Event destinations を選択します。 図 5. Configuration set created successfully Add destination をクリックします。 分析したいイベントタイプを選択し、 next をクリックします。 図 6. Sending Events to analyze 宛先として Amazon Kinesis Data Firehose を選択し、前に作成した配信ストリームと IAM ロールを選択し、 next をクリックします。レビューページで Add destination をクリックします。 図 7. Destination for Amazon SES sending events 設定セットとイベント宛先を作成したら、検証済みの ID (ドメインまたはメールアドレス) のデフォルトの設定セットを定義できます。SES コンソールで Verified identities を選択します。 図 8 Amazon SES Verified Identity イベントを収集する検証済みの ID を選択し、 Configuration set を選択します。 Edit をクリックします。 図 9. Edit Configuration Set for Verified Identity デフォルトの設定セットを割り当てるチェックボックスをオンにし、前に作成した設定セットを選択します。 図 10. Assign default configuration set 前の手順を完了すると、イベントが Amazon S3 に送信されます。Kinesis 配信ストリームのバッファ設定により、データは 5 分ごとまたは 5 MiB ごとに Amazon S3 にロードされます。バケットに作成された構造を確認し、SES イベントデータの JSON ログを確認できます。 図 11. Amazon S3 bucket structure ステップ 3: Amazon Athena を使用して SES イベントログをクエリする Amazon SES は、メール送信イベントレコードを JSON 形式で Amazon Kinesis Data Firehose に公開します。 トップレベルの JSON オブジェクトには、eventType 文字列、mail オブジェクト、およびイベントの種類に応じて Bounce、Complaint、Delivery、Send、Reject、Open、Click、Rendering Failure、DeliveryDelay オブジェクトが含まれています。 メール送信イベントの分析を簡素化するために、次のスクリプトを Amazon Athena で実行して sesmaster テーブルを作成します。 次のスクリプトの LOCATION をメール送信イベントのデータを含む自分のバケットに変更することを忘れないでください 。 CREATE EXTERNAL TABLE sesmaster ( eventType string, complaint struct &lt; arrivaldate: string, complainedrecipients: array &lt; struct &lt; emailaddress: string &gt;&gt;, complaintfeedbacktype: string, feedbackid: string, `timestamp`: string, useragent: string &gt;, bounce struct &lt; bouncedrecipients: array &lt; struct &lt; action: string, diagnosticcode: string, emailaddress: string, status: string &gt;&gt;, bouncesubtype: string, bouncetype: string, feedbackid: string, reportingmta: string, `timestamp`: string &gt;, mail struct &lt; timestamp: string, source: string, sourcearn: string, sendingaccountid: string, messageid: string, destination: string, headerstruncated: boolean, headers: array &lt; struct &lt; name: string, value: string &gt;&gt;, commonheaders: struct &lt; `from`: array &lt; string &gt;, to: array &lt; string &gt;, messageid: string, subject: string &gt;, tags: struct &lt; ses_source_tls_version: string, ses_operation: string, ses_configurationset: string, ses_source_ip: string, ses_outgoing_ip: string, ses_from_domain: string, ses_caller_identity: string &gt;&gt;, send string, delivery struct &lt; processingtimemillis: int, recipients: array &lt; string &gt;, reportingmta: string, smtpresponse: string, `timestamp`: string &gt;, open struct &lt; ipaddress: string, `timestamp`: string, userAgent: string &gt;, reject struct &lt; reason: string &gt;, click struct &lt; ipAddress: string, `timestamp`: string, userAgent: string, link: string &gt; ) ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe' WITH SERDEPROPERTIES ( "mapping.ses_caller_identity" = "ses:caller-identity", "mapping.ses_configurationset" = "ses:configuration-set", "mapping.ses_from_domain" = "ses:from-domain", "mapping.ses_operation" = "ses:opeation", "mapping.ses_outgoing_ip" = "ses:outgoing-ip", "mapping.ses_source_ip" = "ses:source-ip", "mapping.ses_source_tls_version" = "ses:source-tls-version" ) LOCATION 's3://aws-s3-ses-analytics-&lt;aws-account-number&gt;/' sesmaster テーブルは、 org.openx.data.jsonserde.JsonSerDe SerDe ライブラリを使用して JSON データを逆シリアル化します。 JSON 配列とマップのサポート、およびネストされたデータ構造のサポートを活用しています。これらの機能により、データの準備と可視化のプロセスが容易になります。 sesmaster テーブルでは、次のマッピングが適用されており、コロンを含む JSON フィールド名によるエラーを回避しています。 “mapping.ses_configurationset”=”ses:configuration-set” “mapping.ses_source_ip”=”ses:source-ip” “mapping.ses_from_domain”=”ses:from-domain” “mapping.ses_caller_identity”=”ses:caller-identity” “mapping.ses_outgoing_ip”=”ses:outgoing-ip” sesmaster テーブルが準備できたら、そのデータの整理されたビューを作成するのが良い戦略です。最初のビュー vwSESMaster には、メール送信イベントのすべてのレコードと、各イベントで一意のすべてのフィールドが含まれています。次のスクリプトを Amazon Athena で実行して、vwSESMaster ビューを作成します。 CREATE OR REPLACE VIEW vwSESMaster AS SELECT eventtype as eventtype , mail.messageId as mailmessageid , mail.timestamp as mailtimestamp , mail.source as mailsource , mail.sendingAccountId as mailsendingAccountId , mail.commonHeaders.subject as mailsubject , mail.tags.ses_configurationset as mailses_configurationset , mail.tags.ses_source_ip as mailses_source_ip , mail.tags.ses_from_domain as mailses_from_domain , mail.tags.ses_outgoing_ip as mailses_outgoing_ip , delivery.processingtimemillis as deliveryprocessingtimemillis , delivery.reportingmta as deliveryreportingmta , delivery.smtpresponse as deliverysmtpresponse , delivery.timestamp as deliverytimestamp , delivery.recipients[1] as deliveryrecipient , open.ipaddress as openipaddress , open.timestamp as opentimestamp , open.userAgent as openuseragent , bounce.bounceType as bouncebounceType , bounce.bouncesubtype as bouncebouncesubtype , bounce.feedbackid as bouncefeedbackid , bounce.timestamp as bouncetimestamp , bounce.reportingMTA as bouncereportingmta , click.ipAddress as clickipaddress , click.timestamp as clicktimestamp , click.userAgent as clickuseragent , click.link as clicklink , complaint.timestamp as complainttimestamp , complaint.userAgent as complaintuseragent , complaint.complaintFeedbackType as complaintcomplaintfeedbacktype , complaint.arrivalDate as complaintarrivaldate , reject.reason as rejectreason FROM sesmaster sesmaster テーブルには、ネストされた配列で表されているフィールドがいくつかあるため、それらを複数の行にフラット化する必要があります。次に、イベントタイプとフラット化が必要なフィールドを示します。 イベントタイプ SEND: フィールド mail.commonHeaders イベントタイプ BOUNCE: フィールド bounce.bouncedrecipients イベントタイプ COMPLAINT: フィールド complaint.complainedrecipients これらの配列を複数の行にフラット化するために、CROSS JOIN と UNNEST 演算子を次の戦略で使用しました。 mail.messageID とフラット化するフィールドを含む一時ビューを作成します。 配列を複数の行にフラット化した別の一時ビューを作成します。 sesmaster テーブルと 2 番目の一時ビューをイベントタイプと mail.messageID で結合して、最終ビューを作成します。 これらのビューを作成するには、次の手順に従ってください。 次のスクリプトを Amazon Athena で実行して、SEND イベントタイプの mail.commonHeaders 配列をフラット化します。 CREATE OR REPLACE VIEW vwSendMailTmpSendTo AS SELECT mail.messageId as messageid , mail.commonHeaders.to as recipients FROM sesmaster WHERE eventtype='Send' CREATE OR REPLACE VIEW vwsendmailrecipients AS SELECT messageid , recipient FROM ("vwSendMailTmpSendTo" CROSS JOIN UNNEST(recipients) t (recipient)) CREATE OR REPLACE VIEW vwSentMails AS SELECT eventtype as eventtype , mail.messageId as mailmessageid , mail.timestamp as mailtimestamp , mail.source as mailsource , mail.sendingAccountId as mailsendingAccountId , mail.commonHeaders.subject as mailsubject , mail.tags.ses_configurationset as mailses_configurationset , mail.tags.ses_source_ip as mailses_source_ip , mail.tags.ses_from_domain as mailses_from_domain , mail.tags.ses_outgoing_ip as mailses_outgoing_ip , dest.recipient as mailto FROM sesmaster as sm ,vwsendmailrecipients as dest WHERE sm.eventtype = 'Send' and sm.mail.messageid = dest.messageid 次のスクリプトを Amazon Athena で実行して、BOUNCE イベントタイプの bounce.bouncedrecipients 配列をフラット化します。 CREATE OR REPLACE VIEW vwbouncemailtmprecipients AS SELECT mail.messageId as messageid , bounce.bouncedrecipients FROM sesmaster WHERE (eventtype = 'Bounce') CREATE OR REPLACE VIEW vwbouncemailrecipients AS SELECT messageid , recipient.action , recipient.diagnosticcode , recipient.emailaddress FROM (vwbouncemailtmprecipients CROSS JOIN UNNEST(bouncedrecipients) t (recipient)) CREATE OR REPLACE VIEW vwBouncedMails AS SELECT eventtype as eventtype , mail.messageId as mailmessageid , mail.timestamp as mailtimestamp , mail.source as mailsource , mail.sendingAccountId as mailsendingAccountId , mail.commonHeaders.subject as mailsubject , mail.tags.ses_configurationset as mailses_configurationset , mail.tags.ses_source_ip as mailses_source_ip , mail.tags.ses_from_domain as mailses_from_domain , mail.tags.ses_outgoing_ip as mailses_outgoing_ip , bounce.bounceType as bouncebounceType , bounce.bouncesubtype as bouncebouncesubtype , bounce.feedbackid as bouncefeedbackid , bounce.timestamp as bouncetimestamp , bounce.reportingMTA as bouncereportingmta , bd.action as bounceaction , bd.diagnosticcode as bouncediagnosticcode , bd.emailaddress as bounceemailaddress FROM sesmaster as sm ,vwbouncemailrecipients as bd WHERE sm.eventtype = 'Bounce' and sm.mail.messageid = bd.messageid 次のスクリプトを Amazon Athena で実行して、COMPLAINT イベントタイプの complaint.complainedrecipients 配列をフラット化します。 CREATE OR REPLACE VIEW vwcomplainttmprecipients AS SELECT mail.messageId as messageid , complaint.complainedrecipients FROM sesmaster WHERE (eventtype = 'Complaint') CREATE OR REPLACE VIEW vwcomplainedrecipients AS SELECT messageid , recipient.emailaddress FROM (vwcomplainttmprecipients CROSS JOIN UNNEST(complainedrecipients) t (recipient)) メール送信イベントを分析するために Amazon QuickSight で使用できる以下の 4 つのテーブルと 1 つのビューがあります。 テーブル: sesmaster ビュー: vwSESMaster ビュー: vwSentMails ビュー: vwBouncedMails ビュー: vwComplainedemails ステップ 4: Amazon QuickSight を使用してデータを分析し、可視化する Amazon QuickSight を使用して、上述した sesmaster テーブル と 4 つのビューからメール送信イベントを分析し、可視化します。 Amazon QuickSight は Athena を通じてデータに直接アクセスできます。 セッションごとの課金体系であり、組織内の全員に分析のインサイトを提供できます。 まずはセットアップしましょう。最初に Athena で新しいデータソースを作成するためのテーブルとビューを選択しましょう。そして、これらのデータソースを使って可視化していきましょう。ここでは可視化の例を作成します。情報ニーズに基づいて、独自の可視化を作成してください。 Amazon QuickSight でデータを使用する前に、まず基盤となる S3 バケットへのアクセスを許可する必要があります。他の分析でまだ行っていない場合は、その方法についてのドキュメントを参照してください。 Amazon QuickSight のホームページで、左側のメニューから Datasets を選択し、右上の New dataset &nbsp;を選択します。データソースとして Athena を設定し選択します。次のダイアログボックスで、データソースに分かりやすい名前を付けて、データソースの作成を選択します。 図 12. 新しい Athena データソースの作成 次のダイアログボックスで、sesmaster と加工済みビューを含む Catalog と Database を選択します。基本的な KPI (Key Performance Indicators) を作成するために、sesmaster テーブルを選択し、 Select &nbsp;をクリックします。 図 13. Sesmaster テーブルの選択 sesmaster テーブルが Amazon QuickSight のデータソースになりました。次はデータの可視化に移ります。 図 14. QuickSight でのデータ可視化 左側にフィールドのリストが表示されています。右側のキャンバスはまだ空白です。データを追加する前に、 利用可能なビジュアルタイプ から KPI を選択します。 図 15. QuickSight のビジュアルタイプ グラフにデータを追加するには、左側のフィールドリストからフィールドをドラッグ&amp;ドロップして、それぞれの領域に配置します。今回は、フィールド send を値の領域に配置し、集計に count を使用します。 図 16. Send フィールドの可視化への追加 左上から新しいビジュアルを追加し、ビジュアルタイプに KPI を選択します。 図 17. 新しいビジュアルの追加 図 18. KPI のビジュアルタイプ フィールド Delivery を値の領域に配置し、集計に count を使用します。 図 19. Delivery フィールドの可視化への追加 同様の手順 (ステップ 1 から 4) を繰り返し、Open、Click、Bounce、Complaint、Reject イベントの数をカウントします。最後に、次のような可視化が表示されるはずです。ビジュアルのサイズを変更して並べ替えると、下の画像のような分析結果が得られます。 図 20. KPI のプレビュー 現在のデータセットの右側にある鉛筆アイコンをクリックして、新しいデータセットを追加します。 図 21. 新しいデータセットの追加 次のダイアログボックスで Add Dataset &nbsp;を選択します。 図 22. 新しいデータセットの追加 vwsesmaster と呼ばれるビューを選択し、 Select をクリックします。 図 23. vwsesmaster データセットの追加 vwsesmaster ビューの利用可能なフィールドがすべて表示されます。 図 24. vwsesmaster データセットの新しいフィールド 新しいビジュアルを作成し、ビジュアルタイプに表を選択します。 図 25. QuickSight のビジュアルタイプ 左側のフィールドリストからフィールドをドラッグ&amp;ドロップして、それぞれの領域に配置します。今回は、フィールド eventtype、mailmessageid、mailsubject を グループ化の領域に配置しますが、必要に応じてさらにフィールドを追加できます。 図 26. eventtype、mailmessageid、mailsubject フィールドの追加 次に、このビジュアルにイベントタイプでフィルタリングするフィルターを作成します。まず、テーブルを選択し、左側のメニューからフィルターを選択します。 Create One をクリックし、ポップアップウィンドウでフィールド eventtype を選択します。次に、eventtype フィルターを選択すると、次のオプションが表示されます。 図 28. eventtype フィルターの作成 eventtype フィルターの右側の点をクリックし、 Add to Sheet を選択します。 図 29. フィルターのシートへの追加 すべてのデフォルト値をそのままにして、下にスクロールして Apply を選択します。 図 30. デフォルト値でフィルターを適用 これで、vwsesmaster ビューを eventtype でフィルターできます。 図 31. eventtype で vwsesmasterview をフィルター sesmaster テーブル、vwsesmaster ビューで利用可能なすべてのデータを使用して可視化をカスタマイズし続けることができます。さらに、vwSentMails、vwBouncedMails、vwComplainedemails ビューのデータを含めるためにデータセットを追加することもできます。以下に、これらのビューから作成された他の可視化をいくつか示します。 図 32. 最終的な視覚化 1 図 33. 最終的な視覚化 2 図 34. 最終的な視覚化 3 クリーンアップ このブログで作成したリソースを削除して、継続的な課金を避けてください。 Amazon QuickSight で作成した可視化を削除する。 他のプロジェクトで Amazon QuickSight を使用していない場合は、サブスクリプションを解除する。 Amazon Athena で作成したビューとテーブルを削除する。 Amazon SES の設定セットを削除する。 S3 バケットにログとして保存されている Amazon SES のイベントを削除する。 Amazon Kinesis Delivery Stream を削除するために、CloudFormation スタックを削除する。 結論 このブログでは、Amazon SES イベントに基づいてメール追跡ソリューションを迅速に作成する方法を、AWS のサービスおよび機能を使って示しました。 このソリューションは、サーバーレスアーキテクチャを完全に採用しているため、インフラを管理する必要がなく、Amazon SES の使用量が少なくても多くても、サーバーを気にすることなく柔軟にソリューションを利用できます。 我々は、ほとんどのお客様の要件に対応したダッシュボードと分析のサンプルをいくつか紹介しました。しかし、このソリューションを発展させ、ダッシュボードにチャートやフィルター、イベントを追加したり削除したりするなど、ニーズに合わせてカスタマイズすることができます。Amazon SES の利用可能なイベント、その構造、および Amazon QuickSight でのダッシュボードと分析の作成方法については、次のドキュメントを参照してください。 Amazon SES が Amazon SNS に公開するイベントデータの内容 クイックスタート: サンプルデータを使用して 1 つのビジュアルで Amazon QuickSight 分析を作成する パフォーマンスとコスト効率の観点から、この解決策を改善するための設定がいくつかあります。 たとえば、parquet などの列形式のファイルフォーマットを使用したり、Snappy で圧縮したり、メール送信の使用状況に応じて S3 のパーティション戦略を設定したりすることができます。 別の改善点として、Amazon QuickSight でデータを読み取るために SPICE にデータをインポートすることが考えられます。 SPICE を使用すると、Athena からデータが 1 回だけロードされ、手動で更新するかスケジュールを使用して自動的に更新されるまでキャッシュされます。 このウォークスルーを使用して、最初の SES ダッシュボードを構成し、イベントの詳細を可視化することができます。このブログで説明されているサービスは要件に応じて調整できます。 著者について Oscar Mendoza is a Solutions Architect at AWS based in Bogotá, Colombia . Oscar works with our customers to provide guidance in architectural best practices and to build Well Architected solutions on the AWS platform. He enjoys spending time with his family and his dog and playing music. Luis Eduardo Torres is a Solutions Architect at AWS based in Bogotá, Colombia. He helps companies to build their business using the AWS cloud platform. He has a great interest in Analytics and has been leading the Analytics track of AWS Podcast in Spanish. Santiago Benavídez is a Solutions Architect at AWS based in Buenos Aires, Argentina, with more than 13 years of experience in IT, currently helping DNB/ISV customers to achieve their business goals using the breadth and depth of AWS services, designing highly available, resilient and cost-effective architectures. 本記事は、 Analyzing Amazon SES event data with AWS Analytics Services を翻訳したものです。翻訳は Solutions Architect の 松岡勝也 が担当しました。

みなさん、こんにちは。ソリューションアーキテクトの西村です。今期から&nbsp; 週刊AWS を担当させていただくことになりました。これからよろしくお願いいたします。 11 月 15 日 (金) 14:00 – 16:00 に AWS セミナー「 生成 AI が切り拓く、今後のエンジニアリング環境 」が開催されます。生成 AI を活用して、実際にエンジニアリング環境の改善を進めているお客様より、具体的な取り組みについてお話しいただく予定です。生成 AI によるエンジニアリングの品質と効率化を高めるためのヒントが得られるチャンスですので、ぜひ、ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年11月4日週の主要なアップデート 11/4(月) Amazon Simple Email Service (Amazon SES) のメール送信用 API でインラインテンプレート機能をサポート Amazon Simple Email Service (Amazon SES) で SendBulkEmail API もしくは SendEmail API のリクエストにおいて、インラインテンプレート機能をサポートしました。今までは、事前に作成したメールテンプレートを Amazon SES に登録しておく必要がありましたが、今回のアップデートのインラインテンプレート機能を使用することで、事前のテンプレート登録と管理が不要で、直接メールコンテンツを組み立て、配信することが可能です。 Amazon Bedrock で Anthropic 社の Claude 3.5 Haiku モデルを提供開始 Amazon Bedrock で Anthropic 社の Claude 3.5 Haiku モデルが、米国西部(オレゴン)リージョンと米国東部(バージニア北部)リージョン(クロスリージョン推論経由)で利用可能になりました。Claude 3.5 Haiku は、高速な応答時間と向上した推論能力を組み合わせにより、Anthropic 社の旧世代の最大モデルである Claude 3 Opus に匹敵するパフォーマンスを実現しており、スピードと知能の両方が求められるタスクに最適です。現在、テキストのみのモデルとして提供されていますが、画像入力のサポートも追加される予定です。 11/5(火) （この日は週刊AWS でとりあげるアップデートがありませんでした。） 11/6(水) Amazon CloudFront で AWS WAF によってブロックされたリクエストに対する料金が無料化へ 2024 年 10 月25日より、AWS WAF によってブロックされた Amazon CloudFront へのリクエストに対して、リクエスト料金やデータ転送料金がかからなくなりました。この改訂は、アプリケーションなどの設定変更の必要はなく、AWS WAF と連携するすべての CloudFront ディストリビューションに対して自動で適用されます。AWS WAF 自体の料金には変更なく、引き続きリクエスト対する料金がかかりますので、お間違いのないようご注意ください。 Amazon EC2 で Microsoft Windows Server 2025 イメージを提供開始 Amazon EC2 で Microsoft Windows Server 2025 のライセンス付き Amazon Machine Images(AMIs) をサポートしました。Amazon EC2 で Windows Server 2025 を起動することで、AWS の強化されたセキュリティと信頼性を備え、性能とコストパフォーマンスに優れた環境で、最新の Windows Server の機能を活用できます。新しい AMI の詳細については、 AWS Windows AMI リファレンス をご覧ください。Amazon EC2 上での Windows Server 2025 の実行に関する詳細は、 Windows Workloads on AWS ページ をご確認ください。 11/7(木) Amazon Elastic Container Service(Amazon ECS) でサービスのバージョンとデプロイの履歴を表示開始 Amazon Elastic Container Service(Amazon ECS) でアプリケーションをデプロイした際のサービスのバージョンとデプロイの履歴を確認できるようになりました。この機能により、Amazon ECS 上で稼働するアプリケーションのサービスバージョンを追跡したり、進行中のデプロイ状況を監視することが可能になり、デプロイ失敗時のデバッグを容易に行えるようになります。2024 年 10 月 25 日以降にデプロイされたサービスについて、サービスバージョンとデプロイ履歴を確認できます。詳細はこちらの ブログ記事 と ユーザーガイド をご確認ください。 Amazon OpenSearch Service がデータ探索とコラボレーションにより効果的な次世代 UI ダッシュボードを提供開始 Amazon OpenSearch Service 次世代ダッシュボードを提供開始しました。データ探索の操作性が向上し、複数のデータソースから情報を 1 箇所に集中させることで、相互作用分析等の包括的なインサイトを得ることができます。また、OpenSeach Workspaces 機能もリリースされ、ユースケースに応じた専用のスペースを作成することで、共同作業者に限定したデータコラボレーションが可能です。詳細についてはこちらの ブログ記事 をご確認ください。 AWS Lambda で .NET のマネージドランタイムの JSON ロギングをサポート AWS Lambda で.NET のマネージドランタイムを使用する Lambda 関数のアプロケーションログを、 JSON 形式でキャプチャできるようになりました。今までは、.NET のマネージドランタイムのシステムログのみが JSON 形式 でキャプチャ可能で、アプリケーションログを JSON 形式でキャプチャするには、ロギングライブラリを手動で構成する必要がありました。今回のアップデートにより、独自の JSON ライブラリを使用する作業が不要で、アプリケーションログ を JSON 形式でキーと値のペアのシリーズとして構造化できるるようになるため、大量のログ検索、分析し、Lambda 関数の障害をすばやく特定できるようになります。 Amazon OpenSearch Service で延長サポートの提供開始 Amazon OpenSearch Service で Elasticsearch バージョンと OpenSeach バージョンで 延長サポートの提供を開始しました。Elasticsearch 6.7 以前のバージョン、Elasticsearch 7.1 から 7.8 のバージョン、OpenSearch 1.0 から 1.2 のバージョン、OpenSearch 2.3 から 2.9 のバージョンの標準サポートは 2025 年 11 月 7 日に終了します。延長サポートでは、通常のインスタンス料金に加えてサポート料金を支払うことで、標準サポート終了後も少なくとも 12 カ月の期間、重要なセキュリティアップデートを受け取ることができます。各バージョンにおける延長サポートの期限等の詳細は、 ブログ記事 をご確認ください。 11/8(金) Amazon Location Service の場所、ルート、マップ機能の強化による高度なルート計画が可能に Amazon Location Service の場所、ルート、マップ機能が強化され、開発者がアプリケーションに高度な位置情報機能を簡単に追加できるようになりました。このリリースにより、複数の配送地点の最適化、さまざまな移動制限のサポートなど、高度なルート計画機能が利用可能です。また、近隣の企業を見つける Search Nearby 機能、入力された住所を予測する Autocomplete 機能などの機能もリリースされており、位置情報ベースのユースケースを幅広くサポートできます。 Amazon DataZone の料金体系がユーザー単位の月額料金から従量課金モデルへ変更 Amazon DataZone は従量課金モデルへ料金体系を改定しました。今までのユーザー毎の月額料金が廃止され、2024 年 11 月 1 日から Amazon DataZone で使用したリソースに対してのみ課金されるようになります。これによりユーザー数に関係なく、利用した分だけの支払いでご利用いただけます。さらに同時に、Amazon DataZone のメタデータストレージの料金を 1GB あたり 0.417 USD から 0.40 USD へ引き下げと、 プロジェクト作成といった Amazon DataZone のコアとなる一部の DataZone API が無償化となりました。無償化の API リストページ で対象の API をご確認ください。 EC2 Auto Scaling でアベイラビリティーゾーンの厳密な均等化制御が可能に Amazon EC2 Auto Scaling グループ(ASG) はアベイラビリティーゾーン間でワークロードを厳密に均等化できるようになりました。今までは、ASG 内の EC2 インスタンスをアベイラビリティーゾーン間で均等化するには、ライフサイクルフックを使ってカスタムアクションを実施させるか、複数の ASG を維持する必要がありました。今回のリリースにより、容易にアベイラビリティーゾーン間での均等化を実現させ、アプリケーションのレジリエンシーをさらに高めることができます。 11 月も中旬に入り、 AWS re:Invent 2024 の開催まで、あと数週間となりました。ただ、お忙しい中、時差もあり、自身で１つ１つキャッチアップするのも大変という方もおられると思います。そこで、今年も AWS re:Invent 2024 で発表される新サービス、新機能を一挙紹介する AWS Black Belt Online Seminar 2024 年 AWS re:Invent 速報 を、2024 年 12 月 6 日 (金) 12:00 – 13:00 に開催いたします。登録不要でご視聴いただけますので、お気軽にご参加ください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 Amazon Bedrockでサービス利用上限(制限)に当たってしまいサービスが利用できないというご相談をいただきます。そういった場合に参考にして頂ける ブログ記事 を公開していますので、該当する方はぜひご確認ください。モデルアクセスの設定方法と、サービス利用上限引き上げのリクエスト方法を解説しています。 年末が近づいてくると、いよいよAWS re:Inventの季節という感じがします。毎年たくさんのサービスアップデートが発表されますが、毎年恒例の「 新サービス・新機能の全てを1時間でサクッとお伝えするWebinar 」を今年も開催します。12月6日(金)の12:00-13:00ですので、ぜひご参加ください。生成AIも、それ以外も、たくさんのアップデートをギュッと凝縮してお伝えします。 「 AWSジャパン生成AI実用化推進プログラム 」のお申し込みも引き続き募集しています。11月22日が締め切りになりますので、検討されている方はお早めに意思表明をお願いします。 それでは、11 月 4 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社コーテッグ様、生成AIによるAI-OCR機能で診察券読み取り業務を効率化し月間7,500時間の削減に成功 株式会社コーテッグ様は医療機関向けに予約・受付をスムーズにするサービス「 ソトマチ 」を開発・展開しています。ソトマチには診察券を読み取ってカルテを特定する機能がありますが、読み取り精度や精度向上のために労力がかかるといった課題がありました。この課題を解決するために、Amazon Bedrockで稼働するAnthropic社のClaude 3.5をはじめとするマルチモーダルモデルの活用を考えました。それによって医療機関ごとに異なるデザインの診察券に向けた調整が不要になり、読み取り精度が向上したことで30%の精度向上を実現、250の医療機関の合計で月間7,500時間の効率化を実現しています。 ブログ記事「階層化された認可による Amazon Bedrock エージェントのデータプライバシー強化」を公開 生成AIを活用してアプリケーションの能力を拡張するメリットは広く認知されつつありますが、同時に生成AIを組み込むことによって従来は存在しなかった考慮ポイントが発生するケースもあります。このブログ記事では、新たな考慮事項の一例としてデータ保護を取り上げ、Amazon Bedrock Agentsによる複数ステップの処理を実行する場合の対処例をご紹介しています。 ブログ記事「Amazon Bedrock と AWS Amplify を使った生成 AI トラベルアシスタントアプリの作成」を公開 この記事は、生成AIを活用したアシスタントアプリの開発方法について解説しています。お題は「旅行をアシストするアプリ」で、人気の観光地や隠れた名所をレコメンドすることでより良い旅行体験を提供することです。アプリケーションの構築にはAWS Amplifyを活用したインフラの自動設定と、Amazon Bedrockによる基盤モデル利用を組み合わせています。サンプルコードも付いていますので、生成AIアプリの作り方を知りたい方にもおすすめです。 ブログ記事「責任ある AI のベストプラクティス: 責任ある信頼できる AI システムの促進」を公開 ISO 42001は組織内でAIシステムを管理するためのガイドラインを提供するマネジメントシステム規格です。このブログ記事ではその公開をお知らせするとともに、AWSがその策定に積極的に協力してきたことと、今後も国際規格の策定に貢献することをお知らせするものです。 ブログ記事「AWS Skill Builder で、生成 AI に関しての知識を身につけてみませんか?」を公開 ビジネス課題の解決手法として生成AIを活用することを考えるためには、生成AIに対してある程度の知識を持っていることが必要になります。AWSでは AWS Skill Builder というクラウドについて学習するコンテンツをご用意していますが、今回AWS Skill Builderの一環として提供されるAWS Cloud Questで生成AIに関するトピックが日本語化され、学習がやりやすくなりました。AWS Cloud Questはロールプレイングゲームのようなスタイルで、ストーリーに沿って出題される課題を解決することを通じてスキル学習を進めるコンテンツで、実際のAWSアカウントを操作しながら実践的な知識を身につけることができるようになっていますので、ぜひ一度おためしください。 ブログ記事「Amazon Bedrock における Anthropic の Claude 3 Haiku モデルのファインチューニングの一般提供を開始」を公開 先日発表したAmazon BedrockのAnthropic Claude 3 Haikuがファインチューニングに対応しました、というお知らせに関するブログ記事の日本語版を公開しました。 ブログ記事「Amazon Bedrock のモデルアクセスの有効化や制限値の引き上げができない時の対応方法」を公開 冒頭でも触れましたが、Amazon Bedrockでモデルアクセスの有効化・推論回数の上限を変更できない際の対応方法をまとめたブログ記事を公開しています。 サービスアップデート Amazon Q Businessで利用開始を簡素化するWebエクスペリエンスを提供開始 Amazon Q Businessにおいて、企業内データのインデックス化が完了する前の段階でもユーザに対してWebアプリケーションを提供できるようになりました。ローカルのファイルに対する処理や、一般的な知識に関するユーザへのアシストをすぐに開始できるようになるのがポイントで、これまでよりも素早くAmazon Q Businessを使い始めることができます。 AWS Clean Rooms MLがセキュアな独自モデルの学習と推論をサポート AWS Clean Rooms MLでプライバシーが確保されたカスタムモデルの学習と、それによる推論に対応しました。この機能を利用すると、独自モデルのためのトレーニングデータや独自のモデル自体を共有することなく、独自モデルによる推測結果を共有することができます。つまり、機密情報はプライベートでセキュアな状態を保ったまま、モデルによる予測結果だけを利用したコラボレーションが可能になります。 Amazon Bedrock Prompt Managementが一般利用開始に Amazon Bedrockのプロンプトマネジメント機能が一般利用開始になりました。この機能ではAWSアカウントごとに保存されたプロンプトを簡単に実行したり、BedrockのConverse/InvokeModel APIでプロンプト識別子を利用して保存されたプロンプトを利用できます。また保存されたプロンプトについてバージョン毎の差分を検出することも可能です。詳細については ブログ と ドキュメント をご覧ください。 Amazon BedrockでAnthropic Claude 3.5 Haikuがご利用可能に Anthropic社が公開したClaude 3.5 HaikuがAmazon Bedrockでご利用頂けるようになりました。このモデルは素早い応答時間が期待できること、推論機能が改良されていることがポイントとされています。また、ベンチマークではClaude 3で最も大きいOpusを超える性能を発揮しているとのことです。Claude 3.5 Haikuは現時点ではバージニアとオレゴンのリージョンでご利用頂けます。 ブログ記事 もどうぞ。 Amazon Bedrockが欧州(チューリッヒ)リージョンでもご利用可能に Amazon Bedrockがチューリッヒのリージョンでもご利用頂けるようになりました。 リージョン毎にサポートされる機能 と リージョン毎に利用できるモデル はドキュメントにまとまっていますので、適宜参照してください。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

本ブログは 2024 年 10 月 16 日に公開された Amazon News “ Amazon helps the US Department of Justice thwart international cybercriminal group Anonymous Sudan ” を翻訳したものです。 米国司法省は、サイバー犯罪グループ アノニマス・スーダンの背後にいる 2 人を起訴し、AWS の貢献を評価しました。 本日 2024 年 10 月 16 日に、米国司法省は、病院、政府機関、通信サービス、クラウドプロバイダー、および様々な他の組織を標的とした、非常に破壊的なサイバー犯罪活動の 2 人の首謀者に対する刑事起訴を公表しました。 司法省は、アノニマス・スーダンと呼ばれるこのグループの首謀者を裁きにかけるための取り組みに、Amazon Web Services (AWS) とそのセキュリティ専門家が貢献したことを評価しました。AWS は過去 2 年間で何十ものサイバー犯罪集団の解体に取り組んでおり、アノニマス・スーダンはそのうちの 1 つです。このグループは特に金銭目的で分散型サービス拒否 (DDoS) 攻撃を行っていました。 DDoS 攻撃では、悪意のある攻撃者が 1 秒間に何百万件ものリクエストでサーバーを集中的に攻撃します。カスタマーサービスセンターが大量の電話を受けると対応不能になるように、システムは新しいリクエストに対応できなくなり、実質的に停止状態になります。これらの攻撃は、数分間から、攻撃者が十分な資金とインフラを持っている場合は数時間から数日間続く可能性があります。このような攻撃とダウンタイムの影響として、ビジネスと生産性の損失が何百万ドルにも及ぶ可能性、そして最も必要とされる時に重要な医療やその他のインフラが利用できなり、人々への影響が発生してしまいます。 DDoS 攻撃は残念ながら珍しいものではありませんが、アノニマス・スーダンによる攻撃の規模と大胆さは、AWS のセキュリティチームにとっても想定外でした。 「彼らの大胆さと、知名度の高いターゲットへ簡単に影響を与えていたことに少し驚きました」と AWS の Vice President 兼 Distinguished Engineer の Tom Scholl 氏 は述べています。「彼らは DDoS 攻撃を DDoS-as-a-Service の提供して、この攻撃事例をマーケティングに活用して、DDoS サービスを購入するために料金プランや連絡方法など、すべてを揃えていました。」 アノニマス・スーダンは、1 日 100 ドル、1 週間 600 ドル、1 ヶ月 1,700 ドルで DDoS 攻撃を提供し、多数の顧客がいました。しかし、高度なセキュリティチームを持ち、クラウドベースのツールを利用できる企業にとって、DDoS 攻撃は一般的に簡単に防御できます。例えば AWS は、脅威を事前に特定するために、グローバルインフラストラクチャ全体で幅広いセキュリティ監視ツールを運用しています。そのため、大手クラウドプロバイダーを含む多くのターゲットに対して、これらの従来型の攻撃がこれほど効果的だったことは、やや驚きでした。 凶悪な犯罪集団 Scholl 氏によると、アノニマス・スーダンのような犯罪グループは攻撃を実行するために、ホスティング企業からサーバーをレンタルし「プロキシドライバー」と呼ばれる小規模なサーバー群を構成し、そこから攻撃を開始するとのことです。これは一般的な手法です。彼らが本当に大きな影響を与える可能性があるのは、その後、他の何千台ものマシン（通常は設定ミスのある Web サーバー）へのアクセスを獲得し、誰もがそこを経由して攻撃トラフィックを流せるようにした時です。この追加のマシン層は、通常、攻撃の真の発信源を標的から隠します。しかし、攻撃者は、Scholl 氏と彼のチームから隠れることはできませんでした。 Scholl 氏のグループは、2023 年 6 月から AWS の社内脅威インテリジェンスツールである MadPot を使用して アノニマス・スーダンの監視を始めました。それ以前は、アノニマス・スーダンは攻撃を公にしておらず、短期間活動してはすぐ停止する、ということを繰り返していました。MadPot のような脅威インテリジェンスツールの活用して、Scholl 氏と彼のチームは、アノニマス・スーダンが攻撃を仕掛けるためのプロキシサーバーのインフラをホストしていたホスティングプロバイダーを特定することができました。Scholl 氏と彼のチームは、これらのプロキシサーバーがネットワーク上で攻撃を仕掛けているのを観察し、様々なホスティングプロバイダーにプロキシドライバーとして悪用されていることの通知を行いました。司法省も並行して動いていました。 デジタル傭兵 アノニマス・スーダンはしばしば自らをハクティビストと称していましたが、彼らの Telegram チャンネルに投稿された自慢げなメッセージを見ると、単なるデジタル傭兵であることがわかります。犯罪集団やその他の悪意のあるグループは、アノニマス・スーダンのようなグループからサービスを購入して、ウェブサイトやインフラを停止させています。実際、このマーケットは非常に成熟しており、アノニマス・スーダンのようなグループは時として「顧客」に料金プランを提示し、攻撃が思うような効果がなかった場合には返金さえ行うこともあります。 残念ながら、これらの攻撃は特殊なものでも珍しいものでもないため、スケーラブルに対処する必要があります。AWS は MadPot のような脅威インテリジェンス機能により、AWS は アノニマス・スーダンのような DDoS 攻撃を仕掛けるグループを阻止するために、ホスティングプロバイダーやドメインレジストラに対して自動的に停止要請を生成することができます。過去 12 ヶ月間で、AWS チームは 2,500 以上のホスティングプロバイダーとドメインレジストラに対して、8 万以上の個別のホストとドメインの停止要請を行ってきました。 アノニマス・スーダンに対する刑事起訴の詳細についてはカリフォルニア州中部地区連邦地方検事局が公開した プレスリリース をご確認ください。 AWS のセキュリティ脅威の追跡と阻止する方法の詳細については、 「AWS によるクラウドの大規模なセキュリティ脅威の追跡と阻止の支援」 を確認ください。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。