2013 年、アマゾン ウェブ サービスは、初のフルマネージド型でペタバイト規模のエンタープライズグレードクラウドデータウェアハウスである Amazon Redshift を発表し、データウェアハウス業界に革命をもたらしました。Amazon Redshift によって、既存のビジネスインテリジェンスツールを使用して大量のデータを容易かつ費用対効果の高い方法で効率的に分析できるようになりました。このクラウドサービスは、従来の高価で伸縮性がなく、かつ調整と運用に多大な専門知識が必要だったデータウェアハウスソリューションから大きく飛躍したものでした。それ以降、お客様はさまざまな変化に対応する上で、より優れたスケーラビリティ、より高いスループット、俊敏性を求めています。ビジネスクリティカルな分析と機械学習のユースケースは爆発的に増加しており、私たちはその変化のスピードに追従しています。現在、何万ものお客様が AWS のグローバルインフラストラクチャで Amazon Redshift を使用して、毎日エクサバイト単位のデータを処理しています。また、Amazon Redshift をデータアーキテクチャの主要なコンポーネントとして採用し、一般的なダッシュボードからセルフサービス分析、リアルタイム分析、機械学習、データ共有と収益化など様々なユースケースで活用を進めています。 AWS re:Invent 2023 で発表された Amazon Redshift の進化は、クラウド分析環境のモダナイズ化をさらに加速し、規模を問わず最高のコストパフォーマンスを実現するという当社の基本理念を継続していきます。これらの発表は、すべてのデータを統合する AWS のゼロ ETL のビジョンを推進するものです。これにより、包括的な分析と機械学習機能によってデータの価値を最大化し、組織内および組織間の安全なデータコラボレーションによりイノベーションをさらに迅速化できます。コストパフォーマンスの向上からゼロ ETL、生成系 AI 機能まで、すべての方に有益となるサービスや機能を取り揃えています。それではハイライトを見ていきましょう。 スケール、パフォーマンス、信頼性を高めるためのアナリティクスのモダナイズ “ 従来のオンプレミスプラットフォームから Amazon Redshift に移行することで、データの取り込みが 88% 速くなり、データのクエリが 3 倍速くなり、日次でデータをクラウドに読み込む処理が 6 倍速くなりました。Amazon Redshift により、パフォーマンス、可用性、信頼性を最適化できました。これにより、オペレーションの複雑さが大幅に緩和され、製造現場でのエンドユーザーの意思決定エクスペリエンスのスピードも向上しました。 ” – Sunil Narayan, Sr Dir, Analytics at GlobalFoundries 新たな改善により、規模を問わず最高のコストパフォーマンスを実現する取り組みを推進 Amazon Redshift は、当初からコストを抑えながら最適なパフォーマンスを実現するための革新的な機能を構築してきました。Amazon Redshift は、他のクラウドデータウェアハウスよりも最大 6 倍優れたコストパフォーマンスと、ダッシュボーディングアプリケーション用途では高い同時実行性と低レイテンシー性能を備えており、引き続きコストパフォーマンス面でリードしています。弊社ではクエリパターンを綿密に分析し、顧客中心のイノベーションを推進する機会を模索しています。例えば、2023年の初めに、文字列ベースのデータ処理を、LZO (Lempel-Ziv-Oberhumer) や ZStandard などの圧縮エンコーディングと比較して 最大 63 倍高速化 すると発表しました。AWS re:Invent 2023 では、ブルームフィルターの強化、クエリの書き換え、Auto Scaling での書き込み操作のサポートなど、クエリのプランニングと実行におけるパフォーマンスのさらなる強化を導入しました。パフォーマンス改善機能の詳細については、以下の発表リストを参照してください。 Amazon Redshift Serverless は 新しい AI 駆動スケーリングと最適化によりこれまで以上にインテリジェントに コストパフォーマンスについて言えば、 Amazon Redshift Serverless の新しい次世代 AI 駆動スケーリングおよび最適化機能により、手動介入なしに、変動するワークロード に対して最大 10 倍優れたコストパフォーマンスを実現（社内テストに基づく) できます。2021 年から一般提供されている Amazon Redshift Serverless を使用すると、データウェアハウスをプロビジョニングして管理しなくても、分析の実行やスケールができます。一般提供開始以来、Redshift Serverless は 10 億件を超えるクエリを実行して、何千もの顧客がデータインサイトを獲得してきました。新しい AI 最適化機能により、Amazon Redshift Serverless は、データ量、同時接続ユーザー、クエリの複雑さなど、すべての主要な側面にわたるワークロードの変化に応じて、プロアクティブかつ自動的にスケーリングされます。コストを最適化するか、パフォーマンスを最適化するか、またはそのバランスを取るか、望ましい価格性能目標を指定するだけで、Redshift サーバーレスがその要件に合うよう最適化します。Redshift サーバーレスのその他の改善点について詳しくは、末尾の発表リストをご覧ください。 データ共有によるマルチデータウェアハウスの書き込み データ共有は Amazon Redshift で広く採用されている機能で、お客様は共有データに対して毎日何千万ものクエリを実行しています。この機能を利用することで、事前にデータをコピーしたり移動したりすることなく、読み取り目的で組織・リージョン内、および組織・リージョン間でトランザクションの一貫を保ちながらライブデータを共有することができます。お客様は、データ共有機能を利用して分析環境を従来のモノリシックな構成から、マルチクラスタのデータメッシュ構成へとモダナイズしています。これによって、組織全体でシームレスかつ安全なデータアクセスが可能になり、データコラボレーションと強力なインサイト獲得が促進されます。AWS re:Invent 2023 ではさらにデータ共有機能を拡張して、マルチデータウェアハウスへの書き込みを開始（プレビュー）し、わずか数クリックで他の Redshift から 異なる Redshift データベースへの書き込みを開始できるようになりました。これにより、コストパフォーマンスのニーズに基づいてさまざまなタイプとサイズのウェアハウスを追加することで、データコラボレーション、ETL/データ処理ワークロードのコンピューティングの柔軟なスケーリングが可能になります。各ウェアハウスは個別のコンピュート使用量に対して課金されるため、コンピューティング使用量の透明性が高まり、その結果、コストを抑えることができます。 多次元データレイアウト Amazon Redshift は、業界をリードする予測最適化機能を備えています。これにより、ワークロードを継続的に監視し、データウェアハウスをより多く利用するにつれて自動的にデータレイアウトとコンピューティング管理を最適化し、性能をシームレスに高めると共にクエリ同時実行性を最大化します。自動テーブルソート、自動的なソートキー・分散キーの選択など、Redshift がすでに提供している強力な最適化機能に加えて、入力されるクエリのフィルタ条件 (特定の地域の売上など) に基づいてデータを自動的にソートすることで繰り返し実行されるクエリのパフォーマンスを向上させる新しい強力なテーブルソートメカニズムである多次元データレイアウトを導入しました。この方法では、従来の方法に比べてテーブルスキャンのパフォーマンスが大幅に向上します。 ゼロ ETL のアプローチですべてのデータを統合 “ Aurora MySQL Zero-ETL 統合を使用することで、Aurora MySQL データベースと Amazon Redshift の間でニアリアルタイムのデータ同期が可能になり、分析環境を構築するために開発者が費やしていた時間は、以前は 1 か月要していたところ、わずか3時間で実現できるようになりました。 ” – MoneyForward JOYME は、Amazon Redshift のストリーミング取り込み機能やその他の Amazon サービスを使用して、リチャージ、返金、報酬などのユーザーのファイナンス活動のリスク管理を行っています。 “ Redshift を利用することで、リスク対象とデータを時間単位ではなくニアリアルタイムで確認することができます。当社のビジネス ROI 効率を大幅に改善しました。 ” – PengBo Yang, CTO, JOYME データパイプラインは、構築と管理が困難でコストがかかる場合があり、分析用のトランザクションデータを取得するのに何時間もかかる場合があります。このような遅延はビジネスチャンスを逃すことにつながります。特に、トランザクションデータの分析から導き出された洞察が限られた時間しか意味を持たない場合はなおさらです。Amazon Redshift は AWS のゼロ ETL アプローチを採用しています。これにより、データウェアハウスとオペレーションデータベース、さらにはストリーミングデータサービス間の相互運用性と統合が可能になるため、データをウェアハウスに容易かつ自動的に取り込んだり、データが存在する場所に直接アクセスしたりできます。 オペレーションデータベースとの ゼロ ETL 統合 2023年、Amazon Aurora MySQL と Amazon Redshift 間でゼロ ETL 統合を実現しました（ 一般提供開始 ）。これにより、Amazon Aurora からのペタバイト単位のトランザクションデータに対して、Amazon Redshift を使用してニアリアルタイムの分析と機械学習（ML）が可能になりました。トランザクションデータが Aurora に書き込まれてから数秒以内に、データが Amazon Redshift で利用できるようになるため、抽出、変換、ロード (ETL) 操作を実行するために複雑なデータパイプラインを構築して維持する必要はありません。AWS re:Inventでは、ゼロ ETL 統合を他のデータソース、特に Aurora PostgreSQL、Dynamo DB、Amazon RDS MySQL にも拡張しました。また、ゼロ ETL 統合によって、新規または既存の Amazon Redshift インスタンスで複数のオペレーションデータベースクラスターからデータをロードして分析し、多くのアプリケーションにわたる総合的な洞察を引き出すこともできます。 データレイククエリが Apache Iceberg テーブルをサポート Amazon Redshift では、さまざまなオープンファイルおよびテーブル形式をサポートしているため、お客様はデータウェアハウスとデータレイクで幅広いワークロードを実行できます。AWS re:Invent では、Apache Iceberg テーブルのサポートが一般提供されることを発表しました。これにより、Amazon Redshift からデータレイク上の Apache Iceberg テーブルに容易にアクセスでき、必要に応じてデータウェアハウス内のデータと結合できます。Amazon Redshift に自動マウントされた AWS Glue データカタログを使用して、ワンクリックでデータレイクテーブルにアクセスできるため、操作が容易になります。その他、AWS Glue 統計情報と統合することでデータレイクのクエリのパフォーマンスを向上させ、さらにデータレイク上のデータのマテリアライズドビューにインクリメンタルリフレッシュ機能追加（プレビュー）を発表し、繰り返されるクエリ実行を高速化できるようになりました。 ゼロ ETL 統合、データレイクのパフォーマンス強化、その他の発表について詳しくは、末尾をご覧ください。 包括的な分析機能と ML 機能で価値を最大化 “ Amazon Redshift は、Jobcase を企業として成長させる上で私たちが持っていた最も重要なツールの 1 つです。 ” – Ajay Joshi, Distinguished Engineer, Jobcase すべてのデータが統合され、利用可能になったら、AI/ML/生成系 AI アプリケーションへのニアリアルタイムの分析を容易に構築して実行できます。ハイライトをいくつかご紹介します。全リストは末尾をご覧ください。 Amazon Q の Generative SQL（生成系 SQL） 機能 Amazon Redshift クエリエディタは、すぐに使えるウェブベースの SQL エクスペリエンスを提供し、データ探索、視覚分析、データコラボレーションに利用される人気のツールです。AWS re:Invent では、Amazon Redshift クエリエディタに Amazon Q Generative SQL（生成系 SQL）機能を発表 (プレビュー) しました。これにより、自然言語でクエリを表現してSQLコードのレコメンドを受けることができるため、クエリの作成が容易になり、生産性が向上します。Generative SQLは、AI を使用してユーザーの意図、クエリパターン、スキーマメタデータを分析し、一般的な SQL クエリパターンを直接識別します。これにより、組織の複雑なデータベースメタデータに関する幅広い知識がなくても、会話形式でより迅速に洞察を得ることができます。 Amazon Redshift ML 大規模言語モデル （LLM） 統合 Amazon Redshift ML により、お客様は使い慣れた SQL コマンドを使用して機械学習モデルを作成、トレーニング、デプロイできます。お客様は Redshift ML を使用して、データウェアハウス内で 1 日に平均 100 億件を超える予測を実行しています。AWS re:Invent では、プレビューとして LLM のサポートを発表しました。 Amazon SageMaker JumpStart では、事前にトレーニングされたオープンソースの LLM を Redshift ML の一部として使用できるようになりました。これにより、LLM の力を分析にもたらすことができます。たとえば、Amazon Redshift で製品フィードバックデータを推測したり、LLM を使用してフィードバックを要約したり、エンティティ抽出、感情分析、製品フィードバック分類を実行したりすることができます。 組織内および組織間の安全なデータコラボレーションにより、イノベーションを加速 “ 何百万もの企業が Stripe のソフトウェアと API を使用して、支払いの受け付け、支払いの送信、ビジネスのオンライン管理を行っています。Amazon Redshift のような主要なデータウェアハウスを介して Stripe データにアクセスすることは、お客様から最も要望の多かったものでした。当社のお客様は、複雑なデータパイプラインを構築したり、データを移動したりコピーしたりすることなく、安全で高速な統合分析を大規模に必要としていました。Amazon Redshift 用 Stripe データパイプラインにより、お客様が数回のクリックで直接的で信頼性の高いデータパイプラインをセットアップできるよう支援しています。Stripe Data Pipeline により、お客様は最新かつ完全な Stripe データを Amazon Redshift データウェアハウスと自動的に共有し、ビジネス分析とレポートを次のレベルに引き上げることができます。 ” – Tony Petrossian, Head of Engineering, Revenue & Financial Management at Stripe Amazon Redshift を使用すると、チームやデータがどこに存在しても、容易かつ安全にデータを共有し、共同作業を行うことができます。また、どこで事業を展開していても、また厳しい規制のある業界においても、データの 安全性 を確保できます。きめ細かな権限や、組織アイデンティティのシングルサインオンによる容易な認証が可能になりました。これらはすべて追加費用なしで提供されます。 AWS IAM Identity Center 統合 Amazon Redshift と AWS IAM Identity Center 統合を発表しました。これにより、組織は Amazon QuickSight、Amazon Redshift クエリエディタ、および Amazon Redshift 間の信頼されたアイデンティティプロパゲーションをサポートできるようになります。Microsoft Entra ID、Okta、Ping、OneLogin などのサードパーティの ID プロバイダ (IdP) と連携することもでき、組織の ID によるシングルサインオンで Amazon QuickSight や Amazon Redshift クエリエディタから Amazon Redshift にアクセスできます。管理者は、サードパーティの ID プロバイダーのユーザーとグループを使用して、サービス全体のデータへのアクセスをきめ細かく管理し、AWS CloudTrail でユーザーレベルのアクセスを監査できます。この信頼できる ID 連携により、ユーザーの ID は Amazon QuickSight と Amazon Redshift の間でシームレスに連携され、インサイトを得るまでの時間を短縮し、スムーズな分析が可能になります。 発表の全文については、以下を参照してください: スケール、パフォーマンス、信頼性を高めるためのアナリティクスのモダナイズ What’s new – New AI-driven scaling and optimizations in Amazon Redshift Serverless (Preview) What’s new – Multi-data warehouse writes through data sharing (Preview) What’s new – Multi-Dimensional Data Layouts (Preview) What’s new – Support for Multi-AZ deployments in GA What’s new – Concurrency scaling now supports Create Table As Select What’s new – Enhanced manageability and usability features for Amazon Redshift Serverless Redshift price-performance improvements ゼロ ETL のアプローチですべてのデータを統合 What’s new – Amazon Aurora PostgreSQL zero-ETL integration with Amazon Redshift (Preview) What’s new – Amazon RDS for MySQL zero-ETL integration with Amazon Redshift (Preview) What’s new – Amazon DynamoDB zero-ETL integration with Amazon Redshift (Preview) What’s new – Support for Apache Iceberg tables in GA What’s new – Incremental refreshes on materialized views (Preview) What’s new – Integration with AWS Glue column-level statistics 包括的な分析機能と ML 機能で価値を最大化 What’s new – Amazon Q Generative SQL in Amazon Redshift (Preview) What’s new – Large Language Model support in Amazon Redshift (Preview) What’s new – AWS Glue support for multi engine views with AWS Analytics Engines What’s new – Integration with visual studio code What’s new – Autocomplete suggestions in Amazon Redshift Query Editor V2 組織内および組織間の安全なデータコラボレーションにより、イノベーションを加速 What’s new – Trusted Identity propagation with IAM Identity Center What’s new – New Fine grained access control capabilities (Preview) What’s new – Integration with secrets manager What’s new – Row level security enhancements What’s new – Metadata security for multi-tenant applications さらに詳しく: https://aws.amazon.com/redshift 著者について Neeraja Rentachintala は、Amazon Redshift のプリンシパル・プロダクト・マネージャーです。Neeraja は、プロダクトマネジメントと GTM の分野で経験を積んできたリーダーであり、データ製品やプラットフォームにおけるプロダクトビジョン、戦略、リーダーとしての役割において 20 年以上の経験を積んできました。Neeraja は、分析、データベース、データ統合、アプリケーション統合、AI/機械学習、オンプレミスとクラウドにわたる大規模な分散システムなどの製品を提供し、MapR（HPEが買収）、Microsoft SQL Server、Oracle、Informatica、Expedia.comなどのベンチャー企業の一部としてフォーチュン500企業にサービスを提供しました。 Sunaina AbdulSalah は、Amazon Redshift のプロダクトマーケティングをリードしています。彼女は、データウェアハウスと分析の影響について顧客を教育し、AWS の顧客事例を共有することに重点を置いています。彼女は、B2B テクノロジーとクラウドコンピューティングの分野におけるマーケティングと GTM 機能の深い経歴を持っています。仕事以外では、家族や友人と過ごしたり、旅行を楽しんだりしています。 原文は こちら です。 翻訳はソリューションアーキテクトの鈴木 浩之が担当しました。

先日(2023/11/27) 「Amazon Aurora/RDS のコスト最適化 」無料セミナーを開催しました。本セッションでは、Amazon Aurora/RDS を長期間運用するにあたってのコスト最適化のポイントや、安定運用のコツについてご紹介しました。 アジェンダは以下の通りで実施しております。 Amazon Aurora/RDS でのコストの最適化 Amazon RDS/Auroraのアーキテクチャー概要 Amazon RDSコスト最適化アプローチ Amazon Aurora コスト最適化アプローチ Aurora Serverless v2 Aurora I/O-Optimized 移行のベスト プラクティスとコストの最適化 データベース移行の課題 データベース移行に活用できるAWSのサービス Database Freedom Workshop データベース移行パートナー AWS Schema Conversion Tool AWS Database Migration Service OLA for Database (Optimization and Licensing Assessments for Database) まとめ ※セミナー資料・録画を希望する場合、弊社営業担当までご連絡下さい。 当日、参加者の皆様には数多くの 「Q＆A 」を頂きありがとうございました。頂いた「 Q＆A」 の一部についても共有しております。 【Q&A】 Q1: ライターインスタンスをProvisioned、リーダーインスタンスをServerless Auroraにした場合、ハードウェア障害などによるフェイルオーバーが発生すると、リーダーインスタンスであったServerless Auroraがライターインスタンスに昇格する、という理解であっていますか？ A1: お問い合わせ頂きましてありがとうございます。 はい。ご認識の通りです。リーダーのServerlessインスタンスがライターに昇格します。 詳細につきましては、以下ドキュメントも併せてご確認ください。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html#aurora-serverless.ha Q2: Aurora mysqlを使っている本番DBでawsアカウント間の移行作業を予定しています。ダウンタイムをできるだけ少なくするにはDMSが有効ですか？移行後のDBMSの変更は有りません。 A2: はい。有効になります。ダウンタイムを極力少なくしたい場合は、DMSをご検討ください。なお、設定方法や対応バージョンは、こちらのURLをご参照ください。https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.MySQL.html#CHAP_Source.MySQL.Homogeneous Q3: RDS PROXYですが、Auroraの場合高コストになるケースがあります。その辺を教えていただければ。 A3: お問い合わせありがとうございます。 RDS Proxyの料金は、お客様が構成されているデータベースインスタンスに依存します。 以下ドキュメントをご参照の上、お客様環境のご利用料金を試算くださいませ。 https://aws.amazon.com/jp/rds/proxy/pricing/ Q4: DBインスタンスのサイズダウンを検討する際にPerformanceInsightで見るべき観点となるメトリクスに付いてご教授ください。 A4: お問い合わせ頂きましてありがとうございます。 Aurora Serverless V2で確認する代表的なメトリクスは以下になります。 ・現在の容量(ACU)はCloudWatchメトリクスのServerlessDatabaseCapacityで確認することが可能 ・最大ACUに対する現在のACUの割合はCloudWatchメトリクスのACUUtilizationで確認することが可能 上記以外の重要メトリクスにつきましては、CloudwatchおよびPerformance Insightsについて記載されている以下ドキュメントをご確認頂き、お客様の要件に併せた監視をご検討くださいませ。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.viewing.monitoring https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless[…]rformance-insights

みなさま、AWS re:Invent 2023はお楽しみいただけましたでしょうか。 2023年12月1日に実施した [AWS Black Belt Online Seminar] AWS re:Invent 2023速報 の資料及び動画についてご案内させて頂きます。動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画へのリンクは「  AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「  AWS Black Belt Online Seminar の Playlist  」をご覧ください。 AWS re:Invent 2023速報 AWS re:Invent 2023 で発表されたばかりの新サービス、新機能を 1 時間に凝縮して一挙紹介！ 資料（  PDF  ） | 動画（  YouTube  ） 対象者 AWSに興味をお持ちのすべての方 AWS re:Invent 2023を見逃してしまった方、振り返りたい方 日本語でわかりやすく新サービス、新機能の概要を知りたい方 本 BlackBelt で学習できること AWS re:Invent 2023 で発表されたばかりの新サービス、新機能 スピーカー 小林 正人 ( Kobayashi Masato ) Solutions Architect また、併せて以下のイベントへ是非ご参加ください。 AWS re:Invent 2023 re:Cap – AWS Key Message と主要アップデート 〜50 分で全体像を把握する！AWS re:Inventキーノート振り返り〜 登録はこちら AWS re:Invent では複数のキーノートで様々な発表が行われました。2024 年 1 月 18 日（木）開催の『AWS Builders Online Series』内、クロージングセッションでは、これら AWS re:Invent のキーノートをまとめた振り返りをお届けします。AWS の方向性を示すキーメッセージをはじめ、特に注目を集めた新サービス・新機能をピックアップして振り返ります。その他、本イベントでは、AWS の各サービスが基礎から学べ、AWS 認定準備講座も公開されます。是非併せてご参加ください。 AWS re:Invent Recap – ソリューション編 〜AWS の最新アップデートをソリューション別にご紹介〜 登録はこちら AWS re:Invent Recap – インダストリー編 〜AWS の最新アップデートをインダストリー別にご紹介〜 登録はこちら 本BlackBeltを通じて、みなさまが深堀りしたいと思えるサービスが見つかり、より詳細にその機能やメリットを調べていただくきっかけとなれば幸いです。 また、毎週のアップデートをまとめている 週刊AWS も公開される予定ですので楽しみにお待ち下さい！

この記事は “ Three Takeaways from Pfizer at AWS re:Invent Keynote ” を翻訳したものです。 ファイザーは、その科学的専門知識とグローバルなリソースを活用して、人々の命を大幅に延ばし、質を向上させるワクチンと治療薬を提供しています。昨年、ファイザーは13億人の患者を治療しました – つまり6人に1人がファイザーの薬を使用したことになります。 AWSの最大の年次イベントであるre:Inventで、AWSのCEOアダム・セリプスキーは、ファイザーの最高デジタル・テクノロジー責任者リディア・フォンセカと基調講演のステージを共有しました。フォンセカは、進行中の最新の生成系AIの取り組みと、昨年とそれ以降の両社の最も革新的な共同成果について語りました。下記のトップ3つが重要なポイントです。 1. ライフサイエンスの生成系AIの未来を探る:患者をより速く助けるために時間とリソースを再配分 この1年で最も話題になったテクノロジーは、生成系AIです。ファイザーはAWSと協力して、その力を17のユースケースに活用し、イノベーションと生産性を推進しています。科学的・医学的なコンテンツの生成から製造など、Amazon BedrockとAWSのAI/機械学習（ML）エコシステムを使用したプロトタイプは数週間で立ち上がっています。ファイザーは、優先的なユースケースの一部で、年間75億ドルから100億ドルのコスト削減が見込めると推定しています。 例えば、生成系AIは新しいがん治療標的の特定に役立ちます。今日、これはデータソース間で情報を集約せざるを得ないマニュアルプロセスです。しかし、AIはわずかな時間で、はるかに多くのソースから関連するデータと科学コンテンツを特定および照合できます。AIアルゴリズムは、潜在的な標的を生成し、それらをより迅速に検証し、最終的には成功確率を向上させる傾向を評価できます。 さらに、ファイザーはAWSサービスを使用して、VOXと呼ばれるファイザー認定の生成系AIプラットフォームを迅速に導入しました。これにより、従業員はAmazon BedrockやAmazon SageMakerなどの最高の大規模言語モデルに安全にアクセスしながらイノベーションを起こすことができます。他の生成系AIアプリケーションとして、特許出願の初稿を作成し、医学・科学コンテンツを生成することで、人間によるレビューと最終化のための時間を節約し、ファイザーが画期的な成果をより速く患者に届けることができるようにすることが検討されています。 AWSのアジャイルな文化は、ファイザーの働き方と一致しており、両社がプロトタイプを迅速に反復できるようにしています。また、Amazon Bedrockで利用できる大規模言語モデルのバリエーションにより、ファイザーは特定のユースケースに最適なツールを選択できます。AWSのモジュール方式により、ファイザーはベンダー全体でプラグアンドプレイが可能となり、全体的なAI戦略を大幅に加速できます。 2. クラウドによって可能になった前例のないスピードとスケール:COVID-19ワクチンの開発とその先へ 生成系AIは、ファイザーがCOVID-19パンデミックが発生した時を振り返ると、AWSとファイザーは成果につながる方法でテクノロジーを適用するために取り組みました。ファイザーがBioNTechとのCOVID-19ワクチンの共同開発を発表してから、FDAが緊急使用許可を付与した日までわずか269日しかかかりませんでした。このプロセスに通常かかるのは8〜10年です。そしてパンデミック前、ファイザーはポートフォリオ全体で2億2,000万回分のワクチンしか生産していませんでした。この数は、2022年にはコミナティの40億回分に拡大しました。この実現のためには、多くの技術協力が必要でした。 まず、AWSは高性能コンピューティング容量を迅速に提供し、ファイザーがクラウドの追加の数万コアにスケールできるようにしました。追加のCPUを利用することで、ファイザーはワクチン候補の製造方法を理解するための非常に計算負荷の高い分析を実行できました。次に、FDAへの申請のために1日以内にデータを提出する必要があるとき、AWSはオンデマンドでコンピュート容量を増強し、ファイザーが科学進歩のスピードで進められるようにしました。 次に、世界中がワクチンを待っている中、ファイザーはできるだけ速くワクチンを製造および配布する必要がありました。業界初のデジタルオペレーションセンターにより、ファイザーのチームは工場間で連携し、生産状況を確認し、リアルタイムで問題を解決できるようになり、スループットが20%向上しました – これがファイザーの工場の運営の核心です。例えば、mRNA予測アルゴリズムにより、1バッチあたり2万回分多くのワクチンが得られました。 今日、ファイザーとAWSは、サプライチェーンを混乱させる可能性のあるイベントに関するプロアクティブなアラートをAIで生成しています。例えば、ハリケーン・イアンの前に介入することで、重要な医薬品とワクチンの供給の継続性を確保しました。 3. グローバルで成功するのためのエンタープライズレベルのデータ戦略 ファイザーは現在、18ヶ月以内に19の医薬品とワクチンを発売することを目指しています。これは、どの企業によっても達成されたことのない快挙です。非常に野心的な目標ですが、すでに13の発売を達成するなど、着実な進捗があります。 この目標の成功には、デジタル、データ、AIが不可欠であり、ファイザーを際立たせているのは、これらを企業全体に適用している点です。ファイザーは数年前からこの土台づくりを始め、テクノロジーとAIが企業で花開くために必要な要素を整えてきました。データの集中化、グローバルでスケールできる標準とプラットフォームの作成、強力なデジタルとAI人材の育成、そして堅牢でセキュアな基盤の構築です。これらすべてが、最大のインパクトをもたらすイノベーションのために行われました。 2021年、ファイザーは大規模なイニシアチブに着手しました。コアITのクラウド化を10%から80%に引き上げることです。これには、12,000のアプリケーションとデータベース、8,000のサーバーを42週間で移行することが必要でした。これは、ファイザーの規模の企業において、AWSがお客様をご支援した中でも最速の移行の1つです。 AWSへの移行により、ファイザーは年間4,700万ドル以上のコスト削減と、3つのデータセンターの閉鎖ｘを実現し、4,700トンのCO2排出量削減、つまり1,000世帯分の年間エネルギー使用量に相当する削減を達成しました。これによりスピードとスケールでのイノベーションが可能になりました。例えば、ファイザーはコンピューティング資源の設定に必要な時間を、月単位から時間単位(1時間で6万CPU)に短縮でき、大規模な薬事申請のためのデータ生成スピードを75%向上させました。 この成功は、これまで以前の取り組みによるものです。2019年、ファイザーとAWSは、数百の実験機器からのマルチモーダルデータを集約する、業界をリードするサイエンティフィックデータクラウド(SDC)を開発しました。このエンドツーエンドのプラットフォームは、実験室や製造機器によって生成された科学データの処理、保存、検索、再利用、分析に関わる作業を簡素化します。SDCのAWS上に構築されたオープンデータレイクアーキテクチャにより、データ量の増加や分析要件の複雑化に合わせてプラットフォームを動的にスケールできます。納入後、SDCはファイザーの科学者が、以前の断片化された環境では数週間または数ヶ月かかっていた、すべての過去の分子と化合物データの簡単かつカスタマイズされた検索をリアルタイムで行うことが出来るようになりました。この時間短縮により、ファイザーチームは分析と計算研究を加速し、最も有望な新規化合物を特定および設計するAIアルゴリズムを活用できるようになりました。 YouTubeで基調講演をご覧ください ライフサイエンス関連の組織とAWSがどのように連携しているかの詳細は、 aws.amazon.com/health/life-sciences をご覧ください。※日本のお客様向けのウェブサイトはこちら： https://aws.amazon.com/jp/local/health/ 翻訳は事業開発の片岡と亀田が担当しました。

はじめに 2023年10月20日、新聞・出版業界のお客様向けに、「コンテンツ制作・配信におけるクラウド活用」というテーマでセミナーをオンラインにて開催いたしました。このセミナーの開催報告として当日お話しした内容や資料をご紹介いたします。 新聞・出版業界では、従来型の物理媒体での発信に加え、WEB メディアはもちろん、動画や音声配信メディアといった様々な媒体での情報発信が進んでおります。 発信するコンテンツが多様化していくことにより、従来よりもコンテンツの管理、活用のためにより多くの負担が強いられる状況の中、それらを適切に効率よく行うための仕組みづくりが求められます。 本セミナーでは、AWS がコンテンツ制作の現場の業務でどのように活用されているかを、お客様のプロダクト開発事例を交えてご紹介しました。さらに、最近注目を浴びている Generative AI (生成系 AI) についての AWS の取り組みをデモを交えてご紹介いたしました。 コンテンツの多様化とクラウド活用 アマゾン ウェブ サービス ジャパン 合同会社 メディアソリューション部 ソリューションアーキテクト 紙谷 知弘 【 資料 】 【 動画 】 オープニングセッションとして、アマゾン ウェブ サービス ジャパン 紙谷より、昨今進んでいるコンテンツの多様化による業務負荷の高まりと、それに対応するためのクラウド活用による業務効率化について海外の事例を交えてご紹介いたしました。 また、生成系 AI を活用した業務改善のアイディアを手軽に試していただく手段として、 Generative AI Use Cases JP の活用例をデモを交えてご紹介しております。 編集業務の DX に朝日新聞社の R&D チームが本気で挑んでいる話 株式会社朝日新聞社 メディア事業本部メディア研究開発センター 嘉田 紗世 様 【 資料 】 【 動画 】 株式会社朝日新聞社嘉田様より、メディア研究開発センターで取り組まれている編集業務の作業効率化に向けた取り組みをご紹介いただきました。取材後の文字起こし作業は記事制作の中でも負担が大きいプロセスです。この作業を効率化するプロダクト 「YOLO」の 開発目的や構成要素、今後の展望についてお話しいただきました。 ウェブメディア制作を支える tech 組織作りと AWS 活用事例 KODANSHAtech 合同会社 ゼネラルマネージャー 長尾 洋一郎 様 【 資料 】 【 動画 】 KODANSHAtech 合同会社長尾様より、ウェブメディアシステムの開発における組織としての課題と内製化に至った経緯をご紹介いただきました。さらに、なぜ内製化組織が必要だったか、システム内製化を進めるにあたり技術選定のポイントをどのように考えているかについて実例を交えてお話しいただいております。 おわりに 本ブログでは、2023年10月20日に開催された「コンテンツ制作・配信におけるクラウド活用〜最新事例から知る業務効率化手法～」の内容をご紹介させていただきました。本セミナーに参加いただいた皆さま、誠にありがとうございました。引き続き皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログはソリューションアーキテクト浦野が担当しました。

はじめに エージェントは、企業の顧客体験戦略において重要な役割を果たします。多くの場合、顧客が質問、懸念、または苦情がある場合の主要な連絡窓口となります。エージェントが提供するカスタマーサービスの質は、顧客満足度と顧客ロイヤリティに大きな影響を与える可能性があります。さらにエージェントは同じではなく、時間毎、日毎、週毎など、さまざまなレベルで業務を行います。さらに応対品質とエージェントのパフォーマンス管理により、他の方法では気づかなかったかもしれないプロダクトやオペレーションの問題を明らかにすることができます。 Amazon Connect はエージェントとマネージャーに音声、チャット、タスクを含むオムニチャネル体験を提供します。通話録音をしたり画面録画をしたり、インタラクションを監視するための機能が組み込まれています。Amazon Connect Contact Lens は、会話分析、エージェントの画面録画、自動評価を提供して、エージェントのパフォーマンスを向上させます。このブログ記事では、これらすべての機能をまとめるためのベストプラクティスとして、次のような推奨事項を紹介します。 通話録音と画面録画のインタラクション 会話分析による顧客インサイトの抽出 応対とエージェントのパフォーマンス管理の自動化を実現 重要なインタラクションを見つけて実用的なインサイトを得る 1. 通話録音と画面録画のインタラクション インタラクションを記録することは、コンタクトセンターにおいて極めて重要な役割を果たします。この貴重なデータは、顧客の好み、問題点、期待に関する深いインサイトを得る機会を提供します。最終的には、サービスを強化し、優れた顧客体験を提供できるよう支援します。Amazon Connect の録音機能を活用して、音声、チャット、タスクのインタラクションを記録して分析できます。インタラクションを記録することで以下が可能になります。 品質保証とトレーニング パフォーマンス評価 顧客インサイトと分析 トレーニングとコーチング Amazon Connect で通話録音と画面録画を有効にする方法については、 Amazon Connect 管理者ガイド に記載されています。 2. 会話分析による顧客インサイトの抽出 会話分析は、顧客の感情、保留時間、文字起こしなどの指標を導入することで、通話記録を強化します。これらの指標を使用してインタラクションをグループ化し、スーパーバイザーが共通の傾向を導き出すことができます。 Amazon Connect Contact Lens は、ルールを使用してインタラクションをまとめて分類します。ルールを使用して、介入のアラートをリアルタイムでトリガーすることもできます。一方、機密情報を編集して、会話の価値を損なうことなく、セキュリティとプライバシーを確保できます。機密情報の編集がサポートしている言語の一覧については Amazon Connect 管理者ガイド を参照してください。 Contact Lens ルール Contact Lens ルール を設定するのは簡単です。これはリスクのある顧客を特定する例です。 スーパーバイザーが有効にする一般的なルールには以下が含まれます。 エージェントが挨拶または結論を漏らした シナリオと異なるスクリプトを検知して、トレーニングが必要なエージェントを特定します。 保留時間または無音時間の多い通話 エージェントが顧客を保留にして支援を依頼したり、ナレッジを検索していることを示す指標値です。こうした会話を特定することで、対処すべき知識のギャップを目立たせることができます。 契約条件を明確にしないエージェントによるコンプライアンス違反 組織がコンプライアンスのギャップを埋め、法令順守を確実に果たせるようにします。 リスクがある顧客 顧客が否定的な感情を示し、「アカウントを解約したい」や「他の会社と契約する」などの言葉を使うと、リテンションチームにリアルタイムで対応するように通知します。 二重の確認 インタラクションを転送して確認を繰り返すエージェントは、不要なアクティビティをやめるように教育できます。これによりサービスコストが削減され、顧客体験が向上します。 インタラクションにおける顧客のエスカレーションまたは暴言 エージェントが難しい会話を処理できるように訓練されていることを確認してください。 Amazon Connect ルールの完全なリストについては以下の ガイド を参照してください。 Eメールとタスクによる通知 問題が発生したときに行動を起こすことで、好ましい解決の可能性が高まります。例えば、ルールによって E メールをトリガーできます。「アカウントを解約したい」と顧客が言った時に、組織のリテンションチームに対応するよう通知できます。同様により積極的にリテンションチームにタスクを割り当てることもできます。 ルールにアクションを設定するには、 Amazon Connect 管理者ガイド を参照してください。 ルールに関するアラート スーパーバイザーはインタラクションを1つずつ手動で聞く代わりに、複数のインタラクションを顧客の感情とともに視覚化して、根本原因をより理解し、それに応じて行動することができます。例えば以下のスクリーンショットは、Contact Lens ルール「Escalation, Angry customer」(エスカレーション、顧客が怒っている)に対するスーパーバイザーアラートがトリガーされ、アラートが選択されるとコンタクトの概要がトリガーされる様子を示しています。 3. コンタクトセンターの品質評価を自動化 手作業による評価は問題の特定に有効ですが、スーパーバイザーはすべてのインタラクションの一部をレビューする時間しかありません。手動評価に時間をかける前に、自動化された品質評価を組み合わせてすべてのインタラクションを可視化できます。これにより、手動による介入がより効果的になります。 Contact Lens ルールで回答された質問で評価を作成できます。例えば「エージェントは顧客に正しく挨拶しましたか？」というルールを見てみます。ルールを正しい言葉で作成し、基準を満たさないインタラクションがあった場合は、スーパーバイザーがコーチングに時間をかける必要があります。次のスクリーンショットを参照してください。Contact Lens の「Greeting」(挨拶)ルールが該当した場合、質問は自動的に「Yes」と採点されます。 このとき「Greeting」(挨拶)ルールは次のロジックで構成されます。 その他の例としては、次のものがあります。 顧客は特定のキーワードについて言及しましたか？ エージェントはコンプライアンス規約を読みましたか？ 会話が終わると顧客の感情は肯定的に変化しましたか？ 詳細については管理者ガイドの「 エージェントパフォーマンスを評価する 」セクションを参照してください。 4. 重要なインタラクションを見つけて実用的なインサイトを引き出す コンタクトセンターではインタラクションの量が非常に多いため、インタラクションから価値を引き出そうとするスーパーバイザーは、どこから始めれば良いのかという課題に直面しています。その結果、インタラクションをランダムに選び価値を引き出そうとしますが、ランダムに選んだ場合に良い結果が得られることはめったにありません。 コンタクトの検索 を使用すると、スーパーバイザーは適切なインタラクションを見つけるための指示ができます。 例えば「保存した検索」を作成して、次のようなインタラクションを検索します。 >1分 (顧客が意見を言いたいけれど解決策を望んでいないという短時間通話を除外) 感情は否定的から始まり、中立的または肯定的に移行 特定のキューに基づく エージェントの行動を最適化 エージェントの活動時間は、コンタクトセンターの運営における主なコスト要因です。行動を最適化し、AHT (平均処理時間)を短縮する機会を見出すことは非常に有益です。会話分析により、エージェントの通話以外の時間をすばやく分析できます。例えば、通話以外の時間をインタラクションのパーセンテージとして検索したり、通話以外の最長時間を検索したりできます。 検索結果のコンタクトを開くと、Contact Lens は通話以外の時間と正確な時間測定値を棒グラフで強調表示します。 さらに、通話録音のオーディオファイルを視覚的に表現して無音部分を表示できるため、そのセクションにすばやく移動して画面録画を確認し、そのセクションでのエージェントの行動を理解できます。 テーマ検出 構造化されていない顧客応対を理解するために、テーマ検出は機械学習を適用して同じような課題を抱えているコンタクトをグループ化し、その結果得られたテーマを表示します。これにより何を探すべきかをシステムに指示することなく「顧客は私に何を話しているのか」という質問に答えることができます。顧客への働きかけの一般的な理由(例えば「予約のキャンセル」、「注文の遅延」など)を見つけることができます。テーマ検出がサポートしている言語の一覧については Amazon Connect 管理者ガイド を参照してください。 これらの推奨事項をすべてまとめると、1つの画面で次のことを確認できます。 通話録音と画面録画 顧客感情の理解 保留時間やエージェントと顧客が同時に話す時間の特定 発言ごとおよび発言者ごとの感情分析と合わせた文字起こし 自動品質評価 結論 このブログでは会話型分析や自動品質管理を検証し、インタラクションの詳細な分析を行って、その根底にあるテーマや根本原因を把握する効果的なテクニックを詳しく紹介しました。 さらに詳しく知りたい場合は、 Amazon Connect 管理者ガイド を参照してください。 ここで取り上げているトピックについて質問がある場合やガイダンスが必要な場合は、私たちがお手伝いします。 AWS サポート からお問合せいただけます。エンタープライズサポートを受けている AWS のお客様は、緊急の問題のエスカレーションを支援するために、 TAM にサポート関連の項目を依頼してください。 Kun Qian はアマゾン ウェブ サービスの経験豊富なプロダクトリーダーで、Amazon Connect 内の複数の製品分野を統率しています。CCaaS の状況を深く理解している Kun は市場開拓戦略の推進と、これらの重要な通信サービスの製品イニシアチブの形成を担当しています。Kun は世界中の顧客やパートナーと積極的に関わっています。積極的にフィードバックを求め、問題を解決することで、顧客体験を形作り、新しい機能の開発を促進するためのインサイトを収集する上で重要な役割を果たします。   Elias Sayigh はオーストラリアのシドニーを拠点とするAmazon Connect を専門とするソリューションアーキテクトです。Elias はクラウドテクノロジーを使用して顧客体験を迅速かつ簡単に改善する方法をお客様に理解してもらうことに喜びを感じています。AWS を全面的に採用する前、Elias は顧客としてもパートナーとしても、サポート、実装、アーキテクトの役割において15年以上にわたって貴重な経験を積み重ねてきました。   翻訳はソリューションアーキテクト黒木が担当しました。原文は こちら です。

国立研究開発法人 新エネルギー・産業技術総合開発機構 （以下、NEDO）とアマゾン ウェブ サービス ジャパン（以下、AWS）は 2023 年 10 月 26 日に、「Deeptech | AWS : NEDO 助成金と AWS の活用セッション」を AWS Startup Loft Tokyo にて共同開催しました。 NEDO は「エネルギー・地球環境問題の解決」と「産業技術力の強化」をミッションに、イノベーション・アクセラレーターとして産学官の強みを結集した体制構築や運営、評価、資金配分などによって技術開発を推進してきました。そして、その成果の社会実装を促進することで、社会課題の解決を目指しています。 本イベントでは NEDO のスタートアップ支援事業に採択された事業者の経験談や、ディープテック分野における NEDO のスタートアップ支援事業全般についてのご紹介をしました。ここではそのレポートをお届けします。 オープニング AWS パブリックセクター 事業開発マネージャー（Startup） 田村 圭 イベント冒頭では、AWS パブリックセクター 事業開発マネージャー（Startup）の田村 圭が、オープニングのあいさつをしました。 岸田内閣は 2022 年 11 月に「スタートアップ育成 5 か年計画」を発表しました。これは、スタートアップへの投資額を 2027 年度に 10 兆円規模とし、スタートアップを 10 万社、ユニコーンを 100 社創出するという目標です。融資制度や税制優遇、補助金など幅広い政策で援助する内容となっており、すでに 1 兆円規模の予算が計上されています。 「この施策により、本イベントのテーマであるディープテックを扱うスタートアップにも、多額の支援が行われます。そうしたスタートアップが活躍することで、この先の日本経済の成長にもつながると考えております」と田村は述べました。 “ディープテック”とは、特定の自然科学分野での研究を通じて得られた科学的な発見に基づく技術であり、その事業化・社会実装を実現できれば、国や世界全体で解決すべき経済社会課題の解決など社会にインパクトを与えられるような潜在力のある技術のことを指します。 そうした技術は、設備や研究への投資に多額の資金が必要であったり、製品化を実現するまでに長い歳月がかかったりするという課題があります。だからこそ、NEDO の助成事業を活用することには大きな意義があるのです。 「まだ NEDO の助成事業についてそれほど詳しくない方もいらっしゃると思いますので、今回のイベントで NEDO についてぜひ知っていただきたいです。また、ディープテック・スタートアップが AWS をどのように活用すればいいのかも、把握していただきたいと考えております」と田村は結びました。 ディープテックスタートアップ・パネルディスカッション ＜スピーカー＞ FRAIM株式会社 取締役 CTO 宮坂 豪 氏（写真左） WOTA株式会社 インキュベーション責任者 山田 諒 氏（写真右） ＜モデレーター＞ アマゾン ウェブ サービス ジャパン スタートアップ事業本部 福井 健悟 ここからは、NEDO の助成事業を活用したスタートアップとして、FRAIM 社の宮坂 氏と WOTA 社の山田 氏がスピーカーとして登壇。AWS の福井をモデレーターとして、NEDO 活用の経験談を語りました。 FRAIM 社 は「文書作成を、再発明する。」をミッションとして、AI などの最新技術を用いて文書作成を「しくみ」ごと変えることを目指し、クラウド ドキュメント ワークスペース「LAWGUE」や関連技術ソリューションの研究・開発・提供を行っています。 FRAIM 社は NEDO が実施する「研究開発型スタートアップ支援事業／Product Commercialization Alliance（以下、PCA事業）」に、2022年度に採択されました。PCA 事業とは、提案時から 3 年ほどで継続的な売り上げを立てる具体的計画がある研究開発型スタートアップを対象とし、審査を行った上で最大 2.5 億円（助成率2/3）の助成を行うものです。 採択されたのは「LAWGUE」の基幹を支えるクラウド型エディタ技術をベースとした「規制改訂等に伴う影響文書の自動特定および修正支援技術の実用化」というテーマです。 また、 WOTA 社 は「水問題を構造からとらえ、解決に挑む。」を存在意義とし、独自の技術・ソリューションにより「水問題」という社会課題に正面から向き合っています。生活排水を再生し最大限有効活用する「小規模分散型水循環システム」およびそれを実現する「水処理自律制御技術」を開発しているのです。 WOTA 社も FRAIM 社と同様に、2022 年度に PCA事業で採択されました。採択されたのは、住宅規模の全排水再生循環利用に対応した小規模分散型水循環システムを、そのプロダクト化に向けて異なる場面や環境条件で実証し、性能・信頼性を検証する「小規模分散型水循環システム実証事業」です。加えて、WOTA 社は 2023 年度に、「ディープテック・スタートアップ支援基金／ディープテック・スタートアップ支援事業」のDMPフェーズにも採択されています。 セッションでは、両社が NEDO の支援を受けようと思った理由やディープテック・スタートアップが AWS を活用する利点、AWS に期待すること、NEDO の各種公募に応募する際の心構えや Tips などが語られました。 FRAIM 社は PCA 事業の公募で一度は不採択となり、2 回目の挑戦で採択されたといいます。その経緯について、宮坂 氏は「エンジニアを増員して開発速度を向上させたかったですし、インフラの費用も今後大きくなることが見えていました。だからこそ諦められませんでしたね。NEDO の助成金は金額が大きく、スタートアップにとって魅力的です」と話しました。 また、山田 氏は AWS の利用について「多種多様なサービスが用意されているため、ディープテック・スタートアップにとっても便利に活用できます。さらに、AWSの利用クレジットをご提供いただき、運用サポートも受けられるので、多くの利点がございました」と推奨しました。 これから NEDO の助成金を申請する企業に向けて、宮坂 氏は「採択前・採択後にどのような書類を作成する必要があるのかあらかじめ調べておくとよい」と説明。山田 氏は「申請時は、自社の事業の社会的な意義や研究開発した内容を事業化する方法などを申請書類に適切に記載してほしい」と述べました。 NEDO 事業説明会 ここからは、NEDO のイノベーション推進部に所属する方々が登壇。NEDO の概要やディープテック分野におけるスタートアップ支援の内容、申請方法などを解説しました。まずは NEDO イノベーション推進部 総括グループの村井 繁樹 氏が NEDO の支援内容について「ディープテック分野での人材発掘・起業家育成事業（以下、NEP事業）」を中心に説明しました。 NEDO イノベーション推進部 総括グループ 村井 繁樹 氏 NEP 事業は、NEDO が行う起業前後の方々を対象としたスタートアップ支援事業です。本事業は「開拓コース」と「躍進コース」の 2 つに分かれています。躍進コースにおいては、応募要件や支援内容に応じて「躍進 A」「躍進 B」「躍進 C」の 3 タイプを設けています。 開拓コースの対象となるのは、起業前の個人（チームでも可）。活動内容としては、自ら起業することも視野に入れながら、技術シーズを活用したアイデアの実現可能性に関する調査を行うこと。活動費としては月額 30 万円（税込）上限 300 万円までとなります。この費用は調査活動において自らが必要と判断した経費に使用でき、事業期間は NEDO が指定する日から 10 カ月程度です。 一方の躍進コースでは、「躍進 A」の助成対象は個人・チーム。「躍進 B」「躍進 C」は法人が助成対象（応募時が個人の場合、交付決定後に法人化する必要あり）です。活動内容としては、事業可能性の調査や、事業化促進に向けた研究開発や実証を行うこと。助成金額は「躍進 A」「躍進 B」が 500 万円未満であり「躍進 C」が 3,000 万円以内です。事業期間は 12 カ月以内となります。 ●詳細は、本年度のNEP事業公募ページを参考としてご確認下さい。 ※尚、来年度は変更になる可能性があることを予めご了承下さい。 NEP事業公募ページ（2023年度）： https://www.nedo.go.jp/koubo/CA2_100393.html　 セッション内では NEP 事業の各コースの概要説明や実施体制の全体フロー、審査の方法、公募情報の見つけ方、応募の手順や各種参考情報などが網羅的に語られました。 NEDO イノベーション推進部 総括グループ 奥田 洋子 氏 村井 氏の次に登壇したのは、NEDO イノベーション推進部 総括グループの奥田 洋子 氏。 NEDO の支援内容について「ディープテック・スタートアップ支援基金／ディープテック・スタートアップ支援事業（以下、DTSU事業）」を中心に説明しました。 前述の通り、日本政府は「スタートアップ育成 5 か年計画」を掲げています。その施策の柱として「スタートアップへの資金供給の強化と出口戦略の多様化」が存在しているのです。その流れを受けて、NEDO によるディープテック・スタートアップへの支援策の強化のために、DTSU 事業が 2023 年度に開始されました。 ディープテックは、事業化や社会実装を実現すれば世界規模の課題を解決できるというような、社会にインパクトを与える価値を持ちます。一方で、そうした技術は研究開発の成果獲得や事業化・社会実装までに長期間を要する上に多額の資金も不可欠です。さらに既存のビジネスモデルを適用しにくいという特徴があります。そのため、国による支援の必要性が高いのです。 DTSU 事業では、ディープテック・スタートアップが行う研究開発や試作品の開発、量産化のための実証等に加え、市場獲得に向けた事業化可能性調査等に対する支援を行います。STSフェーズ（実用化研究開発（前期））、PCAフェーズ（実用化研究開発（後期））、DMPフェーズ（量産化実証）の3つのフェーズを設けており、事業の進捗度に適合した支援を行います。また、ステージゲート審査を経ることで、複数フェーズでの中長期的な支援を行います。 これらの支援の実施にあたっては、スタートアップの資金調達スパンに応じた支援とするべく、VC等やCVC、事業会社、金融機関から、所定の期間内に、助成対象費用の一定割合以上の出資又は融資を受けることを必須の要件としています。 助成金額上限は、 STSフェーズ が 3億円又は5億円、PCA フェーズが 5 億円又は10 億円、DMP フェーズが 25 億円となり、複数フェーズを跨ぐ場合も 30 億円としています。また、事業期間は次の資金調達の時期を目安に設定することとし、同一フェーズ内で4年まで、複数フェーズを跨ぐ場合も6年までとしています。 ●詳細は、DTSU事業公募ページをご確認下さい。5年間の通年公募を行っていますが、年4回程度の提案受付機会を設けており、当該機会ごとに公募ページが異なり、公募内容も変わりうる点にご留意ください。 ※DTSU事業公募ページ（2023年度第3回の例）： https://www.nedo.go.jp/koubo/CA2_100429.html セッション内では各事業の支援対象者や対象分野、事業の流れ、経費計上に関する留意事項、提出資料の内容などが語られました。 （※NEDOの助成事業に関する情報は諸事情等により変更が生じる可能性がございます。） AWS パブリックセクターは今後も、ディープテック・スタートアップがイノベーションを加速させるための、さまざまなテクニカル・ビジネスセッションやコミュニティ活動を実施予定です。ご関心を持たれた方は、ぜひお気軽にこちらまでお問い合わせください。社会課題解決イノベーションに取り組まれる、スタートアップや研究者のみなさまのご参加をお待ちしております！ このブログは、アマゾンウェブサービスジャパン合同会社 パブリックセクター 事業開発マネージャー（ Startup ）である 田村 圭 が執筆しました。

このブログは 2023 年 11 月 17 日に Daniel Rabinovich（Software Development Engineer）、Vyassa Baratham（Software Development Engineer）、Mahesh Goud Paruchuri（Software Development Manager）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 企業では、複数のチームやプロジェクトで使用されるワークロードや関連リソースをグループ化するために、個別のアカウントを使用することがよくあります。これにより、組織は所有権、意思決定、コストを調整し、社内のチーム間で容易に管理できるようになります。しかし、アカウント内の各チームは、重要なリソースとそうでないリソースに関して、異なる要件やプロセスを持つ場合があります。このような要件やプロセスが混在していると、バックアップの失敗によってデータが失われ、大幅なダウンタイムが発生し、 目標復旧時点 が達成できない可能性があります。一方、アカウントの所有者や管理者は、各チームやプロジェクトのプロセスの詳細を知らないため、アカウントレベルでバックアップの要件を決定することは困難です。 現在お客様は、 Amazon Elastic Block Store（EBS） ボリュームを EBS スナップショット に、 Amazon Elastic Compute Cloud（Amazon EC2） を EBS-backed Amazon Machine Images（EBS-backed AMI）に自動的にバックアップするために使用できる幅広い製品、機能、カスタムスクリプトの選択肢を持っています。これらのツールは互いに独立して動作するため、異なるチームが同じリソースをバックアップするために異なるツールを使用すると、重複したバックアップが作成され、追加コストが発生する可能性があります。 アカウントの所有者とストレージの管理者は、 Amazon Data Lifecycle Manager のデフォルトポリシーを使用して、作成されるリソースの数を最小限に抑えながら、すべての重要なワークロードを保護できるようになりました。デフォルトポリシーは、インスタンスまたはボリュームに、デフォルトポリシーで設定された作成頻度を満たす最近のバックアップがない場合にのみ、新しいバックアップを作成します。それ以外のメカニズムでバックアップが正常に作成されている場合、デフォルトポリシーは対象のリソースに対して新しい AMI またはスナップショットを作成しません。 この記事では、お客様が Amazon Data Lifecycle Manager のデフォルトポリシーをどのように設定すれば、リソースの重複作成とコストを最小限に抑えながら、重要なワークロードを確実にバックアップできるかを説明します。Amazon EC2 インスタンスと Amazon EBS ボリュームに対するデフォルトポリシーのセットアップの概要を説明し、Amazon EC2 のコンソールでデフォルトポリシーが作成するリソースを検証します。デフォルトポリシーは、アカウント内のすべてのインスタンスとボリュームを自動バックアップする簡単な方法が必要なお客様にも最適なオプションです。デフォルトポリシーを使用することで、アカウントの所有者や管理者は、アカウントで動作するチームやプロジェクトが使用するさまざまなプロセスに関係なく、アカウント内のすべての重要なワークロードがバックアップされているという安心感を得ることができます。 シナリオ 以下は、バックアップが必要とされる 2 つの一般的なシナリオです: シナリオ 1: 一人のユーザーがすべてのリソースをバックアップする簡単な方法を求めている アリスはアカウントの所有者で、アカウント内のすべてのインスタンスとボリュームの自動バックアップを有効にする簡単な方法を求めています。Amazon EC2 のコンソールからこの機能を有効にし、「確実に動く」ことを確認したいです。 シナリオ 2: ストレージ管理者は、重要なワークロードがすべてバックアップされていることを確認したい ボブは組織のストレージ管理者で、主要アカウントの重要なワークロードが定期的にバックアップされていることを確認する責任を負っています。このアカウントは複数のチームとユーザーによって使用されており、それぞれが独自の要件を持っています。アカウントのユーザーがデータをリストアするためのバックアップを見つけることができない場合、ボブは彼らの最初の連絡先となります。次の図は、1 つのアカウントで動作するすべてのチームとワークロードの例です。 チーム A は、ボリューム 1–4（ Amazon EBS io2 Block Express ボリューム ）で重要なアプリケーションを実行し、1 時間ごとのバックアップが必要です。 チーム B は、ボリューム 5–7（Amazon EBS io2 Block Express ボリューム）で重要なアプリケーションを実行し、データボリュームのみ 1 時間ごとのバックアップが必要です。 チーム B は、ボリューム 8（ Amazon EBS gp3 ボリューム ）に一時データを保存し、バックアップは不要です。 チーム C は、ボリューム 9–10（Amazon EBS io1 ボリューム、io2 Block Express ボリューム）で重要なアプリケーションを実行し、データボリュームのみ 1 時間ごとのバックアップが必要です。 個別ユーザーはボリューム 11–14（Amazon EBS io2 Block Express ボリューム）を作成し、テスト目的で使用する場合を除き、組織の 1 時間ごとのバックアップ要件を遵守する必要があります。 また、各チームは独自のメカニズムでデータをバックアップしています: チーム A は、ボリュームのタグに基づいてバックアップするリソースを決定するサードパーティツールを使用しています。 チーム B は、Amazon Data Lifecycle Manager のカスタムポリシーを使用して、ボリュームのタグに基づいてバックアップするリソースを決定しています。 チーム C は、ボリュームのタグに基づいてバックアップするリソースを決定するカスタムスクリプトを使用しています。 個別ユーザーは自由にバックアップのメカニズムを選択しています。 アプリケーションをリストアするための最近のバックアップが見つからないという理由で、ボブは何度かユーザーから連絡を受けました。手動で調査した結果、ボブは以下の原因を特定しました: チーム A が誤ってボリューム 1 のタグを削除し、バックアップツールがボリューム 1 のバックアップを停止しました。 チーム B がボリューム 7 のタグを変更したため、Amazon Data Lifecycle Manager のカスタムポリシーがボリューム 7 のバックアップを停止しました。 チーム C のカスタムスクリプトにソフトウェアの欠陥があり、スナップショットが作成されなくなりました。 個別ユーザーは、タグ（production:environment）を持つすべてのボリュームを保護するようにチーム B のポリシーが設定されていると思い込み、ボリュームにタグ（production:environment）を付けていました。しかし、実際にはチーム B のポリシーは別のタグ（prod:environment）を持つボリュームを対象としていました。このため、個別ユーザーのボリュームはまったくバックアップされていませんでした。 ソリューションの概要 アリスもボブも、Amazon Data Lifecycle Manager のデフォルトポリシーを使うことで、それぞれのニーズを満たすことができます: シナリオ 1: 一人のユーザーがすべてのリソースをバックアップする簡単な方法を求めている アリスは、Amazon EC2 のダッシュボードから数回クリックするだけで、Amazon Data Lifecycle Manager のデフォルトポリシーを有効にすることができます（ウォークスルーの Step 1）。アリスはまた、アカウント内のすべての Amazon EBS ボリュームを監視して、過去 1 日以内に作成されたバックアップがあることを確認できます（Step 6）。 シナリオ 2: ストレージ管理者は、重要なワークロードがすべてバックアップされていることを確認したい ボブは Amazon Data Lifecycle Manager のデフォルトポリシーを簡単に有効にして、様々なチームが使用するすべての重要なアプリケーションが日次バックアップされるように設定することができます。アカウント内の一部のユーザーは、1 時間ごとにバックアップを作成するように独自のバックアップメカニズムを設定しますが、ボブは重要なボリュームが少なくとも日次バックアップされるように、デフォルトポリシーを使用することができます。デフォルトポリシーを設定する際（Step 4）、ボブは除外パラメータを設定し、重要なアプリケーションを実行するボリュームのみがデフォルトポリシーの対象となるようにします。 お客様は除外パラメータを使用して、デフォルトポリシーによる定期的なバックアップから除外したい Amazon EBS ボリュームと Amazon EC2 インスタンスの属性を定義できます。リソースが除外パラメータの少なくとも 1 つに一致する場合、デフォルトポリシーはそのリソースのバックアップを作成しません。 さまざまなチームやユーザーの要件に基づくと、ボブのデフォルトポリシーは、すべてのブートボリュームと Amazon EBS io2 以外のボリュームタイプ（gp3、gp2、io1、sc1、st1、standard/magnetic）を除外すべきです。また、タグ（temp:storage）が設定されたテスト目的のボリュームも除外する必要があります。デフォルトポリシーを作成すると、すべてのチームとユーザーにとって重要なワークロードを実行するすべてのボリュームが、デフォルトポリシーの対象となります（以下の図で示す範囲）。各チームのバックアップメカニズムが計画通りに動作してボリュームのバックアップを 1 時間ごとに作成している場合、デフォルトポリシーは追加のスナップショットを作成しません。ただし、何らかの問題が発生し、ボリュームに過去 1 日分のスナップショットが存在しない場合は、デフォルトポリシーがそのボリュームのスナップショットを作成します。 前提条件 このウォークスルーでは、定期的にバックアップする必要がある Amazon EC2 インスタンスと Amazon EBS ボリュームがアカウントに存在することを想定します。デフォルトポリシーを適用したリソースを作成する際に、これらのリソースにタグを設定する必要はありません。 ウォークスルー Amazon Data Lifecycle Manager のデフォルトポリシーを作成および管理するには、いくつかの方法があります。また、Amazon Data Lifecycle Manager のデフォルトポリシーとカスタムポリシーを Amazon EC2 コンソールに統合し、Amazon EC2 インスタンスの新規起動や Amazon EBS ボリュームの新規作成時にポリシーが有効になっているかどうかを確認できるようになりました。この記事では、デフォルトポリシーのすべてのタッチポイントについて説明します: Amazon EC2 ダッシュボードを使用したデフォルトポリシーの確認 デフォルトポリシーの作成と設定 デフォルトポリシーとカスタムポリシーの区別 Amazon EBS ボリュームの作成時におけるデフォルトポリシーの設定の確認 Amazon EC2 インスタンス起動時におけるデフォルトポリシーの設定の確認 Amazon EBS ボリュームと最近のスナップショットバックアップの監視 Step 1: Amazon EC2 ダッシュボードを使用したデフォルトポリシーの確認 1. Amazon EC2 のダッシュボードに移動し、アカウントの属性の Data protection and security に進みます。 2. Data protection and security タブでは、EBS スナップショットおよび/または EBS-backed AMI に対して Amazon Data Lifecycle Manager のデフォルトポリシー が有効になっているかどうかを確認できます。作成するリソースに対応する Create policy を選択します。 この AWS リージョン のアカウントにどちらか一方でも作成されている場合、ダッシュボードにはポリシーの作成頻度と保持期間も表示されます。 Step 2: デフォルトポリシーの作成と設定 Amazon EC2 ダッシュボードから Create policy を選択すると、Amazon Data Lifecycle Manager ポリシーの作成ページに移動します。 1. ポリシーの説明 を入力し、 AWS Identity and Access Management（IAM） ロールを選択することで、デフォルトポリシーの設定を開始できます。どのロールを使用すべきかわからない場合は、 デフォルトロール を選択することをお勧めします。正しい IAM 権限を持たない他のロールを選択した場合、ポリシーは エラー状態 になります。 2. 次に、 作成頻度 、 保持期間 、および 除外パラメータ を設定する必要があります。 作成頻度 は、ポリシーの対象となるすべての Amazon EBS ボリュームのスナップショットバックアップを作成する間隔を定義します。同じ頻度（またはそれ以上の頻度）でスナップショットを作成する他のバックアップメカニズムがある場合、デフォルトポリシーはそれらのボリュームに対してスナップショットを作成しません。ただし、他のメカニズムがスナップショットを作成する頻度が低い場合、または他のメカニズムが対象ボリュームのスナップショットの作成を停止するような問題が発生した場合は、デフォルトポリシーが介入し、作成頻度の基準を満たすようにスナップショットが作成されます。 保持期間 は、デフォルトポリシーで作成されたスナップショットが保持される期間を定義します。 除外パラメータ を定義して、デフォルトポリシーの対象から除くボリュームの属性を設定する必要があります。 ソリューションのセクションにあるボブのユースケースに基づくと、デフォルトポリシーは次のスナップショットを作成しません: ブートボリューム gp3、gp2、io1、sc1、st1、standard/magnetic のボリュームタイプ タグ（temp:storage）を設定したボリューム チームまたはユーザーが前述の除外する基準を満たさないボリュームを作成した場合、デフォルトポリシーはそのボリュームに日次バックアップがあることを確認します。 3. 次に、デフォルトポリシーの 詳細設定 を行います。ここでは、 削除を最新の AMI まで延長 を有効にしています。このパラメータを有効にしない場合、Amazon Data Lifecycle Manager のデフォルトポリシーは、ソースボリュームが削除されたときに最後のスナップショットを削除しません。また、デフォルトポリシーが無効化/削除されたとき、またはエラー状態に遷移したときでも、デフォルトポリシーによって作成されたスナップショットは削除されません。ソースボリュームが削除されたときや、デフォルトポリシーが削除/無効化やエラー状態に遷移したときに、（保持期間に基づいて）デフォルトポリシーが最終スナップショットを削除する場合は、 削除を最新の AMI まで延長 を有効にする必要があります。 4. 満足のいく設定ができたら、 デフォルトポリシーを作成 を選択し、設定を確認することで、デフォルトポリシーの作成は完了です! 同じ手順で、EBS-backed AMI 用のデフォルトポリシーも作成できます。このポリシーは、ポリシーの 除外パラメータ で定義したものを除いて、アカウント/リージョン内のすべての Amazon EC2 インスタンスを対象とします。 5. お客様は、 AWS Command Line Interface（AWS CLI） を一回使用するだけで、同じデフォルトポリシーを簡単に作成することもできます。 $ aws dlm create-lifecycle-policy \ --state ENABLED \ --description "EBS snapshot policy" \ --execution-role-arn “role_arn” \ --default-policy VOLUME \ --create-interval 1 \ --retain-interval 7 \ --extend-deletion \ --exclusions ExcludeBootVolumes=true, ExcludeTags=[{Key=temp,Value=storage}], ExcludeVolumeTypes="standard|gp2|gp3|io1| st1|sc1" Step 3: デフォルトポリシーとカスタムポリシーの区別 Amazon EC2 コンソールの Amazon Data Lifecycle Manager ページから、Amazon Data Lifecycle Manager のデフォルトポリシーを作成することもできます。 1. Amazon EC2 のコンソールで Lifecycle Manager を選択してください。 2. デフォルトポリシー のラジオボタンを選択します。または、タグに基づいて対象とするリソースを選択できる カスタムポリシー を作成することもできます。 3. EBS スナップショットポリシー または EBS-backed AMI ポリシー のいずれかを選択します。次に、Step 2 の指示に従ってポリシーを設定します。 4. 同じアカウントの同じ AWS リージョン同じタイプのデフォルトポリシーを既に作成している場合、別のデフォルトポリシーを作成することはできず、タイルはグレーアウトされます。必要に応じて、 デフォルトポリシーを表示 して既存のデフォルトポリシーの変更ができます。 5. Amazon Data Lifecycle Manager のメイン画面では、デフォルトポリシーの表示、監視、フィルタリング、ソートも可能です。 Step 4: Amazon EBS ボリュームの作成時におけるデフォルトポリシーの設定の確認 Amazon EC2 コンソールを使用してボリュームを作成する際に、Amazon Data Lifecycle Manager のデフォルトおよびカスタムポリシーが Amazon EBS ボリュームをバックアップするか確認できます。 1. Amazon EC2 のコンソールで Elastic Block Store の ボリューム を選択し、 ボリュームの作成 を選択します。 2. ページの一番下までスクロールし、 バックアップの概要 の更新アイコンを選択します。 3. 同じアカウントの同じ AWS リージョンに対して EBS スナップショットのデフォルトポリシーが設定されている場合、そのポリシーがそのボリュームをバックアップするかどうかを確認できます。また、Amazon Data Lifecycle Manager のカスタムポリシーがこのボリュームを（付与されたタグに基づいて）バックアップの対象にしているかどうかも確認できます。 4. ボリュームをデフォルトポリシーの対象にしない場合は、ボリュームの属性が 除外パラメータ の少なくとも 1 つに一致することを確認する必要があります。詳細を表示を拡張し、 除外パラメータを表示 を選択できます。この例では、タグ（temp:storage）を追加し、更新アイコンを再度選択すると、デフォルトポリシーがこのボリュームを対象としていないことがわかります。 Step 5: Amazon EC2 インスタンス起動時におけるデフォルトポリシーの設定の確認 Amazon EC2 コンソールでインスタンスを起動したときに、Amazon Data Lifecycle Manager のデフォルトポリシーとカスタムポリシーが Amazon EC2 インスタンスをバックアップするかどうかを確認できます。 1. Amazon EC2 コンソールで インスタンス を選択し、 インスタンスを起動 へと進みます。 2. EBS-backed AMI のデフォルトポリシーがタグに基づいてインスタンスを除外するように設定されていて、現在のボリュームを除外したい場合は、ここでタグを追加し、それが インスタンス に適用されることを確認する必要があります。 3. ページの ストレージを設定 までスクロールダウンし、更新アイコンを選択します。 4. 同じアカウントの同じ AWS リージョンに EBS-backed AMI のデフォルトポリシーが設定されている場合、インスタンスが作成されると、ポリシーがインスタンスをバックアップするかどうかを確認できます。また、Amazon Data Lifecycle Manager のカスタムポリシーが（付与されたタグに基づいて）このインスタンスをバックアップするかも確認できます。 Step 6: Amazon EBS ボリュームと最近のスナップショットバックアップの監視 Amazon Data Lifecycle Manager を使用しているかどうかに関係なく、Amazon EC2 コンソールの Amazon EBS ボリュームのページを使用して、過去 24 時間に作成されたスナップショットがあるボリュームの数を確認できます。 1. Amazon EC2 コンソールで ボリューム を選択します。 2. 検索バー を使用して、ボリュームの属性に基づいてフィルタリングすることもできます。複数のボリュームを選択すると、 セレクション概要 タブに移動して、選択したボリュームの数と最近スナップショットが取得されたボリュームの数を表示できます。 重要なワークロードを実行している 1 つまたは複数のボリュームに最近のスナップショットが表示されない場合、デフォルトポリシーを作成することで、このギャップを迅速に解決できます。 クリーンアップ 前の手順で作成したスナップショットを削除して、ストレージ料金が発生しないようにします。 スナップショット のページに移動し、ポリシーによって作成されたすべてのスナップショットを検索し、すべてのスナップショットを選択し、 アクション の後に スナップショットの削除 を選択します。 同様に、Amazon Data Lifecycle Manager のデフォルトポリシーを削除して、今後そのポリシーによってスナップショットが作成されないようにする必要があります。まず、デフォルトポリシーの削除を 最新の AMI まで延長 を有効にして、ポリシーが削除されても、ポリシーによって既に作成されたスナップショットが削除されるようにします。次に、Amazon Data Lifecycle Manager の画面に移動してポリシーを選択し、 アクション を選択して ライフサイクルポリシーを削除 を選択すると、ポリシーを削除できます。 まとめ この記事では、AWS リソースのアカウント所有者がアカウント内のすべてのボリュームが定期的にバックアップされていることを簡単に確認できるように、Amazon Data Lifecycle Manager のデフォルトポリシーを作成することについて説明しました。デフォルトポリシーを使用することで、ストレージ管理者は自分が管理するアカウントを使用するチームやユーザーの要件を満たすことができます。ストレージ管理者は、チームやユーザー独自のバックアップメカニズムが失敗した場合でも、アカウント内のすべての重要なワークロードが定期的にバックアップされているという保証を得ることができます。何よりも、デフォルトポリシーでは、最近のバックアップがすでに存在する場合、追加のバックアップを作成しないため、バックアップの重複による追加コストと管理オーバーヘッドを排除することができます。 最後の提案として、ご自身の環境でこの機能を試してみることをお勧めします。また、この機能の詳細については、AWS の ドキュメント をご覧ください。 この記事をご覧いただきありがとうございます。 <!-- '"` --> TAGS: Amazon Data Lifecycle Manager (Amazon DLM) , Amazon EBS Snapshots , Amazon Elastic Block Store (Amazon EBS) , Amazon Elastic Compute Cloud (Amazon EC2) , AWS Cloud Storage Daniel Rabinovich Daniel Rabinovich は Amazon Elastic Block Store（Amazon EBS）の Software Development Engineer です。Amazon Data Lifecycle Manager を含む EBS スナップショット製品の開発に 9 年以上の経験があります。 Vyassa Baratham Vyassa Baratham は Amazon Elastic Block Store（Amazon EBS）の Software Development Engineer です。複雑な問題に対する堅牢で持続可能なソリューションを構築することが好きです。趣味は料理、ランニング、スキー、愛猫ポピーと遊ぶことです。 Mahesh Goud Paruchuri Mahesh Goud Paruchuri は Amazon Elastic Block Store（Amazon EBS）の Software Development Manager です。大規模システムや機能の設計、実装、提供において 10 年以上の経験があります。趣味はワークアウトと読書です。

このブログは、 Amazon DynamoDB zero-ETL integration with Amazon OpenSearch Service is now available を翻訳したものです。 本日、 Amazon OpenSearch Service と Amazon DynamoDB zero-ETL の統合 が一般公開されたことをお知らせします。これにより、カスタムコードやインフラストラクチャを必要とせずに、DynamoDB データを自動的に複製および変換して検索を実行できます。この zero-ETL 統合 により、データパイプラインアーキテクチャのコードの記述、データの同期、頻繁なアプリケーション変更によるコードの更新に伴うオペレーション上の負担とコストが軽減され、アプリケーションに集中できるようになります。 この zero-ETL 統合により、 Amazon DynamoDB を利用するお客様は、全文検索、あいまい検索、オートコンプリート、機械学習 (ML) 用のベクトル検索など、 Amazon OpenSearch Service の強力な検索機能を使用して、ユーザーエンゲージメントを高め、アプリケーションに対する満足度を向上させる新しいエクスペリエンスを提供できるようになりました。 この zero-ETL&nbsp;統合では、 Amazon OpenSearch Ingestion を使用して、Amazon DynamoDB&nbsp;と Amazon OpenSearch Serviceの間でデータを同期します。データを同期する必要がある DynamoDB テーブルを選択すると、Amazon OpenSearch Ingestation は、データが使用可能になってから数秒以内に Amazon OpenSearch マネージドクラスターまたはサーバーレスコレクションにデータを同期します。 また、インデックスマッピングテンプレートを指定して、Amazon DynamoDB フィールドが Amazon OpenSearch Service インデックスの正しいフィールドにマップされるようにすることもできます。また、複数の DynamoDB テーブルのデータを 1 つの Amazon OpenSearch Service マネージドクラスターまたはサーバーレスコレクションに同期して、複数のアプリケーションにわたる総合的なインサイトを得ることができます。 zero-ETL 統合を開始する 数回のクリックで、DynamoDB から OpenSearch Service にデータを同期できます。DynamoDB と OpenSearch Service 間の統合を作成するには、 DynamoDB コンソール の左ペインにある Integrations メニューと、データを同期したい DynamoDB テーブルを選択します。 ポイントインタイムリカバリ (PITR) と DynamoDB Streams 機能を有効にする必要があります。この機能により、テーブル内の項目レベルの変更をキャプチャし、その変更をストリームにプッシュできます。 Exports and streams タブで Turn on を選択してPITR と DynamoDB Streams を有効にします。 PITRとDynamoDB Streamsをオンにしたら、 Create&nbsp; を選択して、OpenSearch Service の管理ドメインにデータをレプリケートするOpenSearch Ingestion パイプラインをアカウントに設定します。 最初のステップでは、一意のパイプライン名を入力し、現在の取り込みワークロードに基づいてパイプラインを自動的にスケーリングするように、パイプラインの容量とコンピューティングリソースを設定します。 これで、定義済みのパイプラインの設定を YAML ファイル形式で設定できるようになります。リソースを参照して情報を検索し、パイプラインの設定を構築するための情報を貼り付けることができます。このパイプラインは、DynamoDB の設定をする source 部分と OpenSearch Service の設定をする sink 部分を組み合わせたものです。 DynamoDB テーブルからデータを読み取り、OpenSearch ドメインに書き込むために必要な権限を持つ複数の IAM ロール ( sts_role_arn ) を設定する必要があります。その後、OpenSearch Ingestion パイプラインがこのロールを引き受け、データをソースからターゲットに移動する際に常に適切なセキュリティが維持されるようにします。詳細については、AWS ドキュメントの Amazon OpenSearch Ingestion のロールとユーザーの設定 を参照してください。 必要な値をすべて入力したら、パイプライン構成を検証して構成が有効であることを確認できます。詳細については、AWS ドキュメントの Amazon OpenSearch Ingestion パイプラインの作成 を参照してください。 数分で OpenSearch Ingestion パイプラインがセットアップされると、DynamoDB テーブルへの統合が完了したことが確認できます。 これで、OpenSearch Dashboards で同期された項目を検索できるようになりました。 知っておくべき事項 この機能について知っておくべきことが数点あります。 カスタムスキーマ –&nbsp;Amazon DynamoDB から OpenSearch Service にデータを書き込む際に、OpenSearch Ingestion が使用するインデックスマッピングとともに、カスタムデータスキーマを指定できます。このエクスペリエンスは Amazon DynamoDB 内のコンソールに追加され、OpenSearch Service で作成されるインデックスのフォーマットを完全に制御できます。 料金 –&nbsp;既存の基盤となるコンポーネントのコストを除いて、この機能を使用する際の追加コストは発生しません。Amazon OpenSearch Ingestion では、Amazon DynamoDB と Amazon OpenSearch Service 間でデータを複製するために使用される OpenSearch Compute Unit (OCU) が課金されることに注意してください。さらに、この機能は変更データキャプチャ (CDC) に Amazon DynamoDB ストリームを使用するため、Amazon DynamoDB ストリームの標準コストが発生します。 モニタリング –&nbsp;パイプラインの状態は、DynamoDB コンソールで統合のステータスを確認するか、OpenSearch Ingestion ダッシュボードを使用してモニタリングできます。さらに、 Amazon CloudWatch を使用してリアルタイムのメトリクスとログを確認し、ユーザー定義のしきい値に違反した場合にアラートを発するように設定できます。 一般利用可能に Amazon DynamoDB と Amazon OpenSearch Service の zero-ETL&nbsp;統合は、現在 OpenSearch Ingestion が利用可能なすべての AWS リージョンで一般利用可能になりました。 詳細については、AWS ドキュメントの &nbsp;DynamoDB zero-ETL integration with Amazon OpenSearch Service&nbsp; と　 Using an OpenSearch Ingestion pipeline with Amazon DynamoDB &nbsp;を参照してください。 お試しいただき、 AWS re:Post for Amazon OpenSearch Service 、または通常の AWS サポート窓口までフィードバックをお送りください。 — Channy Channy Yun Channy Yun は AWS の Principal Developer Advocate であり、開発者が最新の AWS サービスで最新のアプリケーションを構築できるよう支援することに情熱を注いでいます。根っからの開発者でありブロガーでもある彼は、コミュニティ主導のテクノロジー学習と共有が大好きで、開発者はグローバルな AWS ユーザーグループに参加するようになりました。彼の主なトピックは、オープンソース、コンテナ、ストレージ、ネットワークとセキュリティ、IoTです。ツイッターで @channyun で彼をフォローしてください。 翻訳は Solutions Architect 深見が担当しました。

はじめに 私たちは、いつでも国や世界を飛び回れることが簡単で当たり前のことと思っています。しかし、航空会社は、想像以上に頻繁に、予期せぬ気象現象、山火事、地政学的事象、物流問題、その他、通常業務に影響を与える外部要因などの課題に直面しています。このような事態は運航の乱れにつながり、フライトの遅延や欠航を引き起こし、乗務員のスケジューリングに支障をきたし、結果として収益や旅行者の信頼を失うことになります。 厳格なビジネスプロセス、老朽化したインフラ技術、航空運航をサポートするソフトウエア機能不足によって、イレギュラーなオペレーションが悪化する可能性があります。これらの事象をすべて解決することは不可能ですが、航空会社は効果的に管理することができます。 このブログでは、航空会社が直面する運行中断の可能性を増大させる特有の課題のいくつかに焦点を当てます。復旧時間を改善するための Amazon Web Services (AWS) のソリューションガイダンスを提案し、航空会社が技術スタックの全体的な回復力を高める方法を取り上げます。 課題 技術基盤の老朽化： 今日の航空業界の業務の大部分を支える老朽化したインフラ技術には単一障害点が存在します。ルーターの故障、ネットワークケーブルの切断、ストレージサブシステムの故障のような物理層における単純な問題は、技術チームが故障したコンポーネントの修理に奔走する間、数時間に及ぶグランドストップを引き起こしています。 複数の アベイラビリティゾーン や複数のリージョンを活用した AWSのWell-Architected 設計と組み合わせることで、 AWS グローバルインフラストラクチャ はハードウェア障害に対する耐障害性を提供し、業界の最新のハードウェアイノベーションをすぐに利用できます。また、需要に合わせて使用量を増減できるため、ピーク負荷を予測してサイズを調整する必要がなくなります。オンプレミスのデータセンターからAWSにワークロードを移行するだけで、 IDC によると、お客様は計画外の停止を69%削減できると言われています 。 ソフトウエアシステムの不備： ソフトウェア機能不足は、ハードウェアの障害以上に航空会社のオペレーションに影響を与える可能性があります。航空会社が使用する、新しいフライトスケジュールの生成、航空機の割り当ての決定、乗客の再収容、客室乗務員の割り当てをおこなうニッチでレガシーなソフトウエアシステムの多くは、数十年前のものであり、航空会社が今日直面している大規模な障害に対応できるようには構築されていません。 航空会社はこのような課題を認識していますが、利益率の低い厳しい市場で競争力を維持するために新たな機会を追求しながら、すべての課題に対処するための十分な予算も人材も持ち合わせていません。この技術的負債に対処するための予算を確保する1つの方法は、ワークロードをクラウドに移行してモダナイズすることです。すでに述べた可用性の向上に加え、AWSに移行した顧客は、 5年間の運用コストを平均50％削減 し、 ITインフラチームの効率を平均47％向上 させています。これにより、新たな収益を生み出すプロジェクトと技術的負債の解消のため投資できます。 AWSでは、移行方法に柔軟性があります。既存のワークロードを単純に リホスト（リフト・アンド・シフト） して、すぐに回復力とパフォーマンスを向上させることもできます。また、クラウドネイティブサービスを活用して、一からリファクタリングと アプリケーションモダナイゼーション をして、さらなる拡張性とコスト削減を実現することもできます。 AWSには、AWS上に構築された業界固有のソフトウェアを提供するテクノロジー企業を含む、 AWS トラベル・サービスコンピテンシーパートナー の豊富なネットワークがあります。ポートフォリオ分析を実施し、固有のワークロードに最適な移行アプローチの決定するのを支援するコンサルタント会社もあります。 手作業によるプロセスは障害からの回復を遅らせる： 障害からの復旧に関わる多くのプロセスは、ほとんど手作業であったり、顧客と航空会社の担当者の間で双方向のコミュニケーションが必要になったりします。そのため、急な人員増強が必要となり、問題解決プロセスが遅れ、顧客体験の低下につながります。 AWSのサービスとパートナー製品は、高度な自動化を実現するのに役立ちます。航空会社は、 AWS Step Functions や Amazon Textract といったサーバーレスやローコードのサービスを活用し、手動のワークフローやプロセスを自動化できます。新型コロナウィルスの期間中、ユナイテッド航空のデジタルチームは、旅行書類を検証する ソリューションを AWS 上 に構築しました。このソリューションは、400万の乗客のためにアップロードされた新型コロナウィルス検査フォームの3分の2以上を自動的に検証し、この要件を満たすために必要な手作業の労力とコストを削減しました。 スタッフや顧客とのコミュニケーション： フライトの遅延や欠航が発生した場合、顧客が最初に取る行動は、航空会社に電話し代替便を予約します。多くの顧客が影響を受ける大規模なイベントの際、従来のコールセンター・テクノロジーでは、短期間で増加する問い合わせに十分に対応できるようにスケールできません。これでは完全なコミュニケーション不全となり、顧客体験を著しく低下させてしまいます。社内では、客室乗務員が空席状況を報告し、割り当てを取得するために電話をかけようとすると、顧客に対応する代わりに何時間も待たされることになり、さらなる障害につながってしまいます。 業務が中断しても、顧客とのやり取りを適切に処理することで、顧客満足度（CSAT）やネットプロモータースコア（NPS）を向上させることができます。 Amazon Connect を使えば、数分でコンタクトセンターを立ち上げることができ、数万人のエージェントで数百万人の顧客をサポートできる規模にスケールできます。航空会社は、需要に合わせてスケールできない融通のきかないレガシーコンタクトセンター技術の代替として Amazon Connect を使用しています。Amazon Connect を使用すると、対話型 IVRでコールをルーティングし、 Amazon Lex を搭載したチャットボットで複雑度の低いケースを処理し、顧客からの電話に対応するエージェントにステップバイステップのガイドを提供し、ほぼリアルタイムの会話分析を実行して、顧客のアイデンティティと感情を判断することができます。 デルタ航空 がどのように Amazon Connect を採用し、卓越したカスタマーエクスペリエンスを提供し、エージェントとのやり取りを変革し、競争力を維持したかをご覧ください。 データへのアクセスの欠如： 航空会社は、障害に効果的に対処するために、統合された一連のデータ・ドメインに素早くアクセスする必要があります。しかし、復旧に役立つ重要な情報は、組織の境界や技術的な制約により、サイロ化されることがよくあります。その結果、障害を予測したり、障害の影響やコストを定量化したり、障害発生時に迅速に行動できなくなります。障害発生時には、以下のシステムからのデータを統合し、シームレスな影響の把握と復旧を行う必要があります。 予約システム 出発管制システム（DCS）と空港業務 IROPS（Irregular Operations）ツール 空港オペレーション DB（AODB） スケジュール バゲージ・ハンドリング・システム（BHS）とトラッキング・システム 払い戻しおよび補償管理システム CRM およびロイヤルティシステム 航空会社は、すべてのデータを一元的に把握する必要性を認識し、その多くが AWS を利用したデータレイクとクラウドデータウェアハウス機能を構築しています。AWSは、業界で最も広範かつ深い 分析 と 人工知能/機械学習（AI/ML） 機能を提供し、お客様がデータをコントロールし、 最新のデータ戦略 を用いて記述的および予測的分析の両方で深いインサイトを得られるようにします。当社の業界専門家は、Amazon S3 を使用して、最新の無限にスケーラブルなデータレイクや高速で柔軟なレポートを作成するための Amazon Redshift や Amazon QuickSight などのサービスを使用して、航空会社に特化した分析ソリューションを構築しました。これらのサービスを組み合わせることで、実用的な洞察が得られ、航空会社を見直しできるデータ主導の意思決定が可能になります。 まとめ／結論 冬の嵐や山火事など、航空会社の運航に影響を与える出来事の多くは防ぐことができませんが、AWSは復旧までの時間を短縮し、悪条件に対する全体的な回復力を高めることができる 業界固有のソリューション を数多く提供しています。運用の回復力と分析のニーズについて AWS のトラベル＆ホスピタリティの専門家に お問い合わ せください。 さらに読む How machine learning is transforming airline operations Korean Airlines on AWS Transforming Travel and Hospitality Customer Service Using Amazon Connect Mike Gomez Mike Gomezは、AWSエンタープライズサポートのエンタープライズサポートマネージャーです。信頼性エンジニアリングとITオペレーションに情熱を注いでいます。トラベル＆ホスピタリティ、メディア＆エンターテイメント、銀行での経験を生かし、業界横断的なイノベーションを通じてお客様のビジネス目標達成を支援することに注力しています。 Paul Ramsey Paul Ramsey は、テキサス州ダラスを拠点とするエンタープライズアカウントのシニアAWSソリューションアーキテクトです。彼の興味と経歴は、AI/ML、アナリティクス、サーバーレステクノロジー、コンテナなど。仕事以外では、ギターやピアノを弾いたり、Amazon Primeで新しい番組を夢中で見たり、チェスをしたりしています。 Robin Kanthareuben Robin Kanthareuben は、旅行、交通、ホスピタリティ分野で20年以上の経験を持つベテランのテクノロジー・リーダーです。大手航空会社、空港、航空連合、ホテルチェーン、旅行テクノロジープロバイダーとテクノロジー戦略やアーキテクチャのコンサルティングに携わっています。現在はドバイを拠点とする Amazon Web Services に在籍。現在の職務では、旅行業界のビジネス＆テクノロジーエグゼクティブのパートナーとして、クラウドやデジタル技術を活用してビジネス目標を達成し、組織を変革してその分野のリーダーとなり、最高の顧客体験を提供できるよう支援しています。

私が空港の技術分野に携わっていることを話すと、多くの人から、最近の空港での遅延や障害は、テクノロジーで解決できるという反応が返ってきます。昨年は空港で問題が発生したにもかかわらず（主に手荷物取り扱いと保安検査のスタッフ不足が原因）、ほとんどの人は、高度なロボット工学や自律機械を必要とする例に飛びつきません。最も多い不満はデータに関する以下のようなものがあります。なぜ航空会社は私の荷物がどこにあるか知らないのか？飛行機が何時間も飛行しているときに、どうして空港は私のフライトの早期到着に備えられなかったのか？今日、追加の旅客がいるということをどうして知らなかったのか？航空会社は空港に伝えなかったのか？ 空港と航空会社はデータの有効活用を望んでいる それは旅行者だけではありません。空港や航空会社のビジネやテクノロジーリーダーも同じことを言っています。彼らは、運営上の問題を解決するためのデータ不足を嘆いており、空港を利用する旅客の好みをもっと知りたいと考えており、ビジネスパートナーと共に空港内のさまざまなシステムの部門と連携したいと考えています。また、外部プロバイダーから入手できる気象情報や交通情報などのデータを活用したいと考えています。 一般にはあまり知られていませんが、空港は、他の空港、航空会社、グランドハンドリングエージェント（チェックイン、手荷物の積み込み、航空機運航管理など、空港内で多くの航空会社にサービスを提供する会社）とデータを共有し、業務プロセスを改善することに大成功しています。例えば、 Airport collaborative decision-making (A-CDM) は、 空港の遅延を10％削減し、CO2排出量を7.7％削減 しました。 空港はこれをさらに進めたいと考えています。Amazon Web Services (AWS) を利用して予防保全や機内食の需要予測を行っている大韓航空やライアンエアーのような航空会社で、データがどのように業界を変革するか、良い例は、ライアンエアーの Panini Predictor です。正確な予測、パーソナライゼーション、すべての関係者間での簡単なデータ共有によって、空港業務と旅客体験が向上することを想像できます。国際空港評議会（ACI）が、最近、「 空港データの共有とコラボレーションは、旅客の満足度を向上させる鍵である 」と述べたことは驚くべきことではありません。 空港はデータプラットフォームを構築している フランスのニース・コート・ダジュールをはじめ、多くの空港が最近 AWS 上にデータプラットフォームを構築しています。一般的に複雑なビジネスルールを持つ高度に構造化されたデータベースである空港運用データベース（またはAODB）とは異なり、データプラットフォームは、空港のシステム、航空会社、サードパーティ全体からさまざまな種類の情報、理解、視覚化、予測、共有するためのより柔軟な方法です。 シンシナティ空港 は、Enterprise Awareness &amp; Situational Exceptions（EASE）と呼ばれる 予測分析と事前通知 のためにデータを使用しています。EASE は、 Amazon Relational Database Service (Amazon RDS) 、マネージドサービス群、 AWS Lambda 、イベント駆動型のコンピューティングサービスのような AWS のサービスを使用して、企業内各所から構造化データと非構造化データを収集しています。これにより、かなりバラバラなデータセットであっても、動的な意思決定を改善できます。また、空港は気象や現地の交通状況も監視しているため、運航計画を調整したり、旅客に注意を促すこともできます。 シンガポールの チャンギ空港 は、データを活用してコラボレーションとイノベーションを向上させた素晴らしい例です。 AWSのトラベル＆ホスピタリティ・パートナー である アクセンチュア と協力し、チャンギ空港は DIVA イノベーション・ラボの基盤としてデータ・プラットフォームを構築しました。その中には、旅客により良い情報を提供する新しいコンシェルジュ・アプリや、Where-To-Clean アプリは、空港内で利用者の多かった場所を優先的に清掃するようにスタッフに伝えます。 空港の手荷物処理システムの世界的リーダーである シーメンス・ロジスティクス も、あらゆる種類の空港運営データを取り込み、分析し、視覚化するために、AWS 上に航空データハブを構築しました。例えば、同社の Baggage360 システムは、複数の情報ソースを使用して手荷物データを分析し、手荷物の流れを予測します。シーメンス・ロジスティクスの航空データソリューション担当ディレクター Stephan Poser 氏は「手荷物の流れを監視し、手荷物処理時間を予測し、リスクのある乗り継ぎを特定し、手荷物が重要な工程に入るタイミングを予測できます。」「到着ベルトで旅客がいつバックを見つけられるか予測できます。」と語っています。 データプラットフォームをオンプレミスで運用している空港の中には、ニーズが高まるにつれ、拡張性や新サービスの追加に限界があることに気づいているところもあります。例えば、AWSパートナーの Wipro は、最近、トロント・ピアソン国際空港のデータプラットフォームをオンプレミスのシステムからAWSに移行し、拡張性と俊敏性を活用し、人工知能（AI）、機械学習（ML）、ほぼリアルタイムのデータ取り込みなどの新機能を追加しました。Wipro・カナダのゼネラルマネージャー Anudeep Kambhampati 氏は「AWS 上の新しい Databricks レイクハウスプラットフォームは、さまざまなソースからほぼリアルタイムのビジネスインサイトを導き出し、継続的なイノベーションを推進するのに役立ちます。」と語っています。 空港がなぜ最近になってデータプラットフォームの構築に乗り出したのか、私は興味がありました。このテクノロジーは以前から存在していたにもかかわらず、なぜ今なのだろうか？この疑問に答えるため、ヨーロッパで 30 以上の空港でデータによる業務改善を支援してきた Azinq 社のマネージング・ディレクター Chris Taylor 氏に話を聞きました。「我々の顧客は、AWSが提供するインフラとデータサービスを活用するために、急速にクラウドベースのデータプラットフォームに移行しています。空港は以前から、旅客やステークホルダーのエンゲージメントを理解し、改善するためのデータの価値を認識していましたが、これまではコストや技術的な障壁のために、空港がデータプラットフォームを構築することは困難でした。AWS 上の私たちの Airport Hive プラットフォームは、空港が運営に関するインサイトを得ることをはるかに容易にし、小さな変化が財政的にも旅客体験にも大きな影響を与えることを可視化します。AWS のスケーラビリティと弾力性により、お客様はオンプレミスの実装にかかるコストや手間を回避し、長期的な成長余力を得ることができます。」 データプラットフォームは、非常に特殊な問題の解決に役立ちます。例えば、米国のある主要空港では、タクシーが一時駐車場で待機しているという問題を抱えており、それは旅客の駐車スペースが減り、空港の収益が減ることを意味します。これを解決するために、空港は AWS パートナーである Slalom と契約し、過去のフライト、天候、タクシー乗客のデータを利用してデータ予測モデルを構築し、前もってタクシーの需要を予測し、必要なときだけタクシーを要請するようにしました。これにより駐車場のスペースが解放され、旅客体験が向上し、空港は運営改善により約 500 万ドルの収益を回収することができました。 データ共有の課題を解決する 空港にとっての課題のひとつは、必要なデータにアクセスすることです。空港は、空港を運営するすべての航空会社や企業から必要なデータを入手するのが難しいと言います。AWSと私たちのパートナーは、空港がこの問題を解決する支援をしています。 AWS re:Invent 2022 では、 AWS Clean Rooms を発表しました。AWS Clean Roomsは、基盤となるデータを共有したり公開したりすることなく、お客様とそのパートナーがより簡単かつセキュアにデータセットをマッチング、分析、コラボレーションできるようにします。各コラボレーターは、AWS Clean Rooms で独自のデータクリーンルームを作成し、どのデータセットで誰とコラボレートするかを選択し制限を設定します。コラボレーターは、AWS環境の外にデータのコピーを維持したり、別のプラットフォームにロードする必要はありません。顧客がクエリーを実行する際、AWS Clean Rooms はデータが存在する場所でデータを読み込み、分析ルールを適用するため、共同作業者が共有したいデータのみが共有されます。航空会社が独自のデータクリーンルームを作成し、空港は航空会社が共有したいデータ（搭乗者数など）のみにクエリを実行できます。 AWS は、空港と航空会社のコラボレーションとデータ共有を支援してきました。私たちは、旅客体験を共有することに集中することで、空港と航空会社のコラボレーションを構築する可能性があると考えています。例えば、空港に対して実践的なアプローチをとって、特定の旅客のペインポイントを理解し、その解決に必要なデータの特定を支援し、航空会社のパートナーと協力して、その旅客のペインポイントを解決するためにデータ共有をしています。 サードパーティ企業は、空港業務の改善に特化したデータフィードを提供しています。例えば、 Passur はAWS上に構築された　API を通じて、フライトポジション、フライト予測、フライトイベントデータを含むほぼリアルタイムのデータフィードを空港に提供しています。Passur の CEO である Brian Cook 氏は、「空港は、資産管理、キャパシティプランニング、航空会社とのコラボレーションを改善するために当社のデータを使用しています。」「当社のデータフィードは、空港に遅延の事前通知を提供し、空港の混乱を防ぐため、事前に運用を調整できます。」「さらに、 AWS Data Exchange は、サードパーティのデータが 1 つのデータカタログで簡単に見つけることができ、気象やフライトデータを含む何千ものデータセットがあります。」と語っています。 AWS は、イノベーションに対する独自の文化とアプローチで知られています。この方法論を取り入れ、お客様がデータによってイノベーションを起こし、ビジネス上の問題を解決できるように特別にアレンジしました。これを AWS Data-Driven Everything Program (D2E)と呼んでいます。D2E を使って何百ものお客様を支援してきました。 私たちは、 最近、豊富な人口統計学的属性と行動属性を持つ統一されたビューを構築することが困難であると感じていた旅行業界の顧客のために D2E セッションを実施しました。当社の旅行業界のお客様は、顧客をマイクロセグメント化して、サポートをパーソナライズし、ネットプロモータースコア（NPS）を 20 ％以上向上させたいと考えていました。D2E の成果は、顧客を中心とした 360 度のビューに対する野心的なビジョン、Minimum Viable Product（MVP）バージョンの構築計画、統合顧客プロファイル製品の改善を繰り返し提供するファストフォロワー機能でした。 次は何をするのか？ 空港はデータプラットフォームの構築と改善に着手できます。AWS コンサルティングパートナーとテクノロジーパートナーは、素早い構築を支援でき、実証済みのソリューションを実装できます。AWS は、安全なデータレイクプラットフォームを構築するための AWS Lake Formation 、ML を使用してビジネス成果を簡単かつ正確に予測する Amazon Forecast 、ML モデルの構築、トレーニング、デプロイを行う Amazon SageMaker など、さまざまなサービスを提供しています。AWS のすべてのお客様は、アカウントマネージャーに連絡できます。アカウントマネージャーは、導入を支援したり、ソリューションアーキテクトや対象分野の専門家を招いてガイダンスやサポートを提供できます。 また、お客様やパートナーが AWS を利用して望ましいビジネス成果を達成できるよう支援する AWS プロフェッショナルサービス チームもあります。 では、空港とデータの今後はどうなるのでしょうか？新型コロナウイルス感染症のパンデミック、最近の空港の収容能力の制約、最近のテクノロジーの進歩のため、空港がデータを共有し、ャパシティの問題を予測し、それに対処するための計画を立てたり、旅客にパーソナライズされたサービスを提供したり、ビジネスステークホルダーとのより良いコラボレーションを実現したり、データをより有意義な方法で使用することがはるかに容易になると期待しています。 私はこれから出会う人々との会話が、「なぜ空港は知らないのか」ではなく「どうして空港は知っているのか」と問われることを楽しみにしています。空港が知るだけでなく、旅客も知ることになるのは良いことでしょう。 Bob Kwik Bob Kwik は AWS のワールドワイド・エアポート・ヘッドです。 彼の役割は、お客様のクラウド導入の過程をサポートすることです。 彼は空港業界で20年以上の経験を持っています。 AWS に入社する前、Bob は大手航空テクノロジー企業で働き、販売、事業開発、技術設計、製品開発において地域および世界の指導的役割を果たしていました。 彼はヨーロッパとアメリカに住み、働いてきました。また、仕事や娯楽のために広範囲に渡って旅行してきました。 ダブリンのトリニティ・カレッジで工学の修士号を取得しています。

IBM と AWS が協力して、AWS インフラストラクチャ上で稼働するフルマネージド型の Db2 データベースエンジンである Amazon Relational Database Service (Amazon RDS) for Db2 を提供したことをお知らせします。 IBM Db2 は、IBM が開発したエンタープライズグレードのリレーショナルデータベース管理システム (RDBMS) です。強力なデータ処理機能、強固なセキュリティー・メカニズム、スケーラビリティ、多様なデータ型のサポートなど、包括的な機能セットを備えています。Db2 は、その信頼性とパフォーマンスにより、さまざまなアプリケーションのデータを効果的に管理し、データ集約型のワークロードを処理する上で、多くの企業で定評のある選択肢です。Db2 は、IBM が1970年代から行ってきたデータストレージと 構造化クエリ言語 （SQL）に関する先駆的な取り組みに端を発しています。1983 年から商用化されており、当初はメインフレーム専用でしたが、後に Linux、UNIX、および Windows プラットフォーム (LUW) に移植されました。現在、Db2 はあらゆる業種の何千ものビジネスクリティカルなアプリケーションを支えています。 Amazon RDS for Db2 では、 AWS マネジメントコンソール で数回クリックするか、 AWS コマンドラインインターフェイス (AWS CLI) で 1 つのコマンドを入力するか、 AWS SDK を使用して数行のコードを入力するだけで Db2 データベースを作成できるようになりました。インフラストラクチャの面倒な作業は AWS が行い、アプリケーションのスキーマやクエリの最適化など、より高レベルのタスクに時間を割くことができます。 Amazon RDS を初めて使用する方や、オンプレミスの Db2 のバックグラウンドをお持ちの方のために、Amazon RDS の利点を簡単にまとめてみましょう。 Amazon RDS は、現在オンプレミスで使用しているものと同じ Db2 データベースを提供しています。既存のアプリケーションはコードを変更せずに RDS for Db2 を利用することができます。 データベースはフルマネージド型のインフラストラクチャ上で稼働します。サーバーのプロビジョニング、パッケージのインストール、パッチのインストール、またはインフラストラクチャを運用可能な状態に維持する必要はありません。 データベースはフルマネージドです。インストール、マイナーバージョンアップグレード、毎日のバックアップ、スケーリング、高可用性は AWS が担当します。 インフラストラクチャは必要に応じてスケールアップおよびスケールダウンできます。データベースを停止して再起動するだけで、基盤となるハードウェアを変更して変化するパフォーマンス要件を満たすことも、最新のハードウェアを利用することもできます。 Amazon RDS では、高速で予測可能で一貫した I/O パフォーマンスを実現するように設計されたストレージタイプを選択できます。新しいワークロードや予測不可能なワークロードの場合は、 ストレージを自動的にスケーリング するようにシステムを設定できます。 Amazon RDS はバックアップを自動的に実行し、数回クリックするだけで新しいデータベースに復元できます。 Amazon RDS は、可用性の高いアーキテクチャのデプロイに役立ちます。Amazon RDS は、異なるアベイラビリティーゾーン (アベイラビリティーゾーンは個別のデータセンターの集まり) にあるスタンバイデータベースにデータを同期的に複製します。マルチ AZ 配置で障害が検出されると、Amazon RDS は自動的にスタンバイインスタンスにフェイルオーバーし、データベースエンドポイントの DNS 名を変更せずにリクエストをルーティングします。この切り替えは、ダウンタイムが最小限に抑えられ、データ損失も発生しません。 Amazon RDS は AWS の安全なインフラストラクチャ 上に構築されています。転送中のデータを TLS を使用して暗号化し、保存中のデータを AWS Key Management Service (AWS KMS) で管理されているキーを使用して暗号化します。これにより、 FedRAMP 、 GDPR 、 HIPAA 、 PCI 、 SOC など、会社または業界の規制に準拠したワークロードをデプロイできます。 第三者監査人は、複数の AWS コンプライアンスプログラムの一環として Amazon RDS のセキュリティとコンプライアンスを評価します。 Amazon RDS コンプライアンス検証の全リストを確認することができます。 restore や import などのネイティブの Db2 ツールや AWS Database Migration Service (AWS DMS) を使用して、既存のオンプレミスの Db2 データベースを Amazon RDS に移行できます。AWS DMS では、データベースを 1 回の操作で移行することも、継続的に移行することもできますが、その間は、お客様が移行を決めるまで、アプリケーションがソースデータベースのデータを更新し続けます。 Amazon RDS は、 Amazon RDS 拡張モニタリング や Amazon CloudWatch など、データベースインスタンスをモニタリングするための複数のツールをサポートしています。また、 IBM Data Management Console や IBM DSMtop を引き続き使用することもできます。 それでは、その仕組みを見ていきましょう 私はいつも、新しいサービスを実際に動かしてみて、その仕組みを学びたいと思っています。Db2 データベースを作成し、 IBM が提供する標準ツール を使用して接続してみましょう。この記事を読んでいる皆さんのほとんどは、IBM Db2 のバックグラウンドを持ち、Amazon RDS についてあまり知らないと思います。 まず、Db2 データベースを作成します。そのためには、 AWS マネジメントコンソール の Amazon RDS ページに移動し、 Create database を選択します。このデモでは、ほとんどのデフォルト値をそのまま使用します。ただし、ここではすべてのセクションを紹介し、検討しなければならない重要な構成ポイントについてもコメントします。 Amazon RDS が提供する複数のデータベースエンジンの中から Db2 を選択しています。 ページを下にスクロールして、 IBM Db2 Standard とエンジンバージョン 11.5.9 を選択します。Amazon RDS は、必要に応じてデータベースインスタンスに自動的にパッチを適用します。Amazon RDS データベースメンテナンスの詳細については、 こちら をご覧ください。 Production を選択します。Amazon RDS は、高可用性と高速で一貫したパフォーマンスを実現するように調整されたデフォルト設定をデプロイします。 Settings で、RDS インスタンスに名前を付け（これは Db2 カタログ名ではありません！）、 マスターユーザー名 と パスワード を選択します。 Instance configuration で、データベースを実行するノードのタイプを選択します。これにより、仮想サーバーのハードウェア特性 ( vCPU 数、メモリ量など) が定義されます。アプリケーションの要件に応じて、IBM Db2 Standard インスタンスに最大 32 個の vCPU と 128 GiB の RAM を備えたインスタンスを割り当てることができます。IBM Db2 Advanced インスタンスを選択すると、最大 128 個の vCPU と 1 TiB の RAM を備えたインスタンスを割り当てることができます。このパラメーターは費用に直接影響します。 Storage では、 Amazon Elastic Block Store (Amazon EBS) ボリュームの タイプ 、サイズ、IOPS とスループットを選択します。このデモでは、デフォルトで提示されている値を受け入れます。これも費用に直接影響する一連のパラメーターです。 Connectivity で、データベースをデプロイする VPC ( AWS の用語では VPC はプライベートネットワーク) を選択します。 Public access で No を選択して、データベースインスタンスに自分のプライベートネットワークからのみアクセスできるようにします。このオプションで Yes を選択すると、インターネットからRDSに直接アクセスできるようになるため注意が必要です。 VPC セキュリティグループ を選択する場所でもあります。セキュリティグループは、どの IP アドレスまたはネットワークがデータベースインスタンスにアクセスでき、どの TCP ポートにアクセスできるかを定義するネットワークフィルターです。アプリケーションが Db2 データベースに接続できるように、必ず TCP 50000 が開いているセキュリティグループを選択または作成してください。 他のオプションはすべてデフォルト値のままにします。ページの一番下にある Additional configuration セクションを開くことが重要です。ここで Initial database name を指定できます。ここで Db2 データベースの名前を指定しない場合、そのインスタンスにデータベースが作成されないため、既存の Db2 データベースバックアップを復元する必要があります。 このセクションには、Amazon RDS 自動バックアップのパラメータも含まれています。時間枠とバックアップの保持期間を選択できます。 デフォルトをすべてそのまま使用して、 Create database を選択します。 数分後、データベースが使用可能となります。 データベースインスタンスの Endpoint の DNS 名を選択し、同じネットワーク上で稼働している Linux マシンに接続します。 IBM Web サイトからダウンロードした Db2 クライアントパッケージ をインストールしたら、次のコマンドを入力してデータベースに接続します。ここでは、Amazon RDS 固有のものは何もありません。 db2 catalog TCPIP node blognode remote awsnewsblog-demo.abcdef.us-east-2.rds-preview.amazonaws.com server 50000 db2 catalog database NEWSBLOG as blogdb2 at node blognode authentication server_encrypt db2 connect to blogdb2 user admin using MySuperPassword Bash 接続したら、人気の Db2Tutorial Web サイト からサンプルデータセットとスクリプトをダウンロードします。作成したばかりのデータベースに対してスクリプトを実行します。 wget https://www.db2tutorial.com/wp-content/uploads/2019/06/books.zip unzip books.zip db2 -stvf ./create.sql db2 -stvf ./data.sql db2 "select count(*) author_count from authors" Bash ご覧のとおり、データベースの接続と使用に関しては、Amazon RDS に固有のものはありません。私は標準の Db2 ツールとスクリプトを使用しています。 注意点 Amazon RDS for Db2 では、お客様自身の Db2 ライセンスを持ち込む必要があります。Db2 インスタンスを起動する前に、IBM customer ID とサイト番号を入力する必要があります。 そのためには、 カスタム DB パラメータグループ を作成し、起動時にデータベースインスタンスにアタッチします。DB パラメータグループは、1 つ以上の DB インスタンスに適用されるエンジン設定値のコンテナとして機能します。Db2 パラメータグループには、IBM Db2 ライセンス固有のパラメータが 2 つあります。それは IBM Customer Number ( rds.ibm_customer_id ) と IBM サイト番号 ( rds.ibm_site_id ) です。 IBM サイト番号がわからない場合は、IBM営業に連絡して、最新の資格証明（PoE）、請求書、または販売注文のコピーを入手してください。これらの書類にはすべて、サイト番号が記載されているはずです。 価格と使用可能状況 Amazon RDS for Db2 は、中国と GovCloud を除くすべての AWS リージョンでご利用いただけます。 Amazon RDS の価格はオンデマンドで、初期費用やサブスクリプションはありません。お支払いいただくのは、データベースが稼働している時間単位で、さらに、1 か月あたりにプロビジョニングされたデータベースストレージ、使用したバックアップストレージ、およびプロビジョニングした IOPS の数を加えた金額です。 Amazon RDS for Db2 の料金ページ には、リージョンごとの料金の詳細が記載されています。先に述べたように、Amazon RDS for Db2 ではお客様自身の Db2 ライセンスを持参する必要があります。 Amazon RDS を既にご存知であれば、アプリケーション開発者が新しいデータベースエンジンを利用できるようになったことを喜ぶでしょう。オンプレミスの世界から来ているなら、Amazon RDS が提供するシンプルさと自動化を気に入るはずです。 Amazon RDS for Db2 のドキュメントページ には、さらに多くの詳細が記載されています。さあ、今すぐ Amazon RDS for Db2 で初めてのデータベースをデプロイ してください。 — seb Sébastien Stormacq セブは、80年代半ばに初めてコモドール64に触れて以来、コードを書いてきました。彼は、情熱、熱意、顧客支援、好奇心、創造性を密かに融合させて、AWS クラウドの価値を引き出すようビルダーを鼓舞しています。彼の関心はソフトウェアアーキテクチャ、開発者ツール、モバイルコンピューティングです。彼に何かを売りたいなら、その商品にAPIがあることを確認してください。Twitter @sebsto で彼をフォローしてください。 翻訳はソリューションアーキテクトの山根 英彦が担当しました。原文は こちら です。

AWS Application Migration Service (AWS MGN) は、AWS への移行において AWS が推奨するサービスです。AWS MGN を利用することで、物理、仮想、またはクラウドのソースサーバーから AWS でネイティブに稼働するよう移行することが、簡単かつ迅速に行えます。 この 1 年間に、AWS MGN サービスの 主要なアップデート をいくつかご紹介しました。例えば、ソースサーバー環境のインベントリリストを AWS MGNに対して一括で入力するために利用できる「インポートとエクスポート」などの機能です。これらのアップデートは、より多くの移動方法を提供し、クラウドジャーニーのハードルを下げることを目的としています。そして当ブログでは、インポートとエクスポートの機能を補完する位置付けとして MGN コネクタをご紹介します。 MGN コネクタは、ソースサーバーへの AWS MGN レプリケーションエージェントの展開に伴う手動プロセスを自動化するための機能です。エージェントをソースサーバーに迅速にデプロイし、一括移行の準備が行えるため、多くの作業時間を節約することができます。 図 1 は、MGN コネクタを使用した AWS MGN レプリケーションエージェントのデプロイのアーキテクチャの概要を示しています。 図 1. AWS MGN レプリケーションエージェントのデプロイのアーキテクチャの概要 通常、ソースサーバーに AWS MGN レプリケーションエージェントを展開すると、エージェントが MGN エンドポイントに登録され、結果としてソースサーバーが AWS MGN のインベントリに追加されます。MGN コネクタを使用して AWS MGN レプリケーションエージェントを展開する場合、まず図 2 に示すインポートとエクスポート機能を使用して、AWS MGNにソースサーバーのリストを入力します。そのためには、AWS MGN サービスのコンソールからインベントリインポート用のテンプレートをダウンロードし、ソースサーバーデータを入力、そしてコンソールを使用してインポートし直します。インポートとエクスポートとその使用方法の詳細については こちら をご覧ください。 図 2. インポートとエクスポートのAWSコンソール画面 MGN コネクタを使用するために、AWS アカウントに対して、 こちら に記載された権限を付与した IAM ロールと IAM ポリシーを用意します。 次に、適切な IAM 認証情報と、 AWS Systems Manager (SSM) ハイブリッドアクティベーション のコードと ID を取得します。 2023 年 5 月のアップデート である、 AWS Organizations と統合して、複数の AWS アカウントにまたがる移行を管理 するための機能である、 AWS MGN の グローバルビュー を使用している場合、 こちら の手順に従い、MGN コネクタを用いて複数のアカウントにレプリケーションエージェントをデプロイすることができます。 MGN コネクタは、 サポートされている Linux バージョン を実行しているソース環境のサーバーにインストールする必要があります。このサーバーは MGN コネクタの実行にのみ使用してください。 MGN コネクタは、次のプロトコルを使用してソースサーバーと通信し、レプリケーションエージェントを展開します。 Windows サーバー向け: WinRM (Remote PowerShell、TCP ポート 5985-5986) Linux サーバー向け: SSH (TCP ポート 22) ソースサーバーのインベントリが入力され、権限が設定され、ファイアウォールルールが設定されたら、図 3 に示すように MGN コネクタを追加します。AWS MGN サービスコンソールに移動し、 MGN コネクタを追加 を選択します。 図 3. MGN コネクタの追加 次に、図 4 に示すように、コネクタの名前、SSM ハイブリッドアクティベーション、取得した IAM 認証情報など、MGN コネクタの登録に必要な事項を入力します。これらの入力情報を使用したシェルコマンドが生成されるため、それをコピーして Linux サーバーのシェルに貼り付け、MGN コネクタのダウンロードとインストールを行います。 図 4. MGN コネクタを登録するための情報入力 新しく作成された MGN コネクタは、自動的に MGN サービスとの通信を開始し、図 5 に示すように、AWS MGN サービスコンソールに表示されます。 図 5. MGN コネクタが登録されるとコンソールに表示される MGN コネクタをインストールしたら、次はソースサーバーを MGN コネクタに登録します。 コンソールから新しくデプロイした MGN コネクタを選択し、図 6 に示すように サーバーの登録 を選択します。 図 6. MGN コネクタにソースサーバーを登録する 図 7 に示すように、MGN のインベントリからソースサーバーを選択し、 MGN コネクタによるサーバーの登録 を選択します。 図 7. MGN コネクタに登録するソースサーバーを選択する MGN コネクタは、ソースサーバーにレプリケーションエージェントをデプロイするための認証情報を必要とします。認証情報は、 AWS Secrets Manager にシークレットとして作成、保存されます。 認証情報を構成するには、図 8 に示すように、リストから対象のサーバーを選択し、 アクション ドロップダウンメニューから サーバー認証情報の登録 を選択します。 図 8. サーバーの認証情報の登録 図 9 に示すように、ソースサーバーの管理者認証情報に関する新しいシークレットを作成します。複数のソースサーバーが同じ認証情報を共有している場合、シークレットの ARN を提供することで既存のシークレットを使用することもできます。 図 9. AWS secret manager にソースサーバーの認証情報を追加する MGN コネクタへのソースサーバーの登録プロセスが完了し、移行の実施に一歩近づきました。 次に、図 10 に示すように、ソースサーバーを選択し、 アクション ドロップダウンメニューから レプリケーションエージェントのインストール を選択して、MGN レプリケーションエージェントをソースサーバーに展開します。MGN コネクタは、デプロイメントを正常に完了するのに十分な CPU、RAM、およびディスク容量リソースがあることを確認します。 図 10. ソースサーバーへのレプリケーションエージェントのインストール これで、MGN コネクタがソースサーバーにレプリケーションエージェントをデプロイする構成になったため、移行プロセスにおけるその他の観点に集中することができるようになります。 レプリケーションエージェントのデプロイプロセスが完了したら、MGN コンソールからソースサーバーの ライフサイクルの状態 をトラックし、移行プロセスの次のステップを計画できます。 まとめ このブログでは、MGN コネクタを使い、ソースサーバーへの AWS MGN レプリケーションエージェントの展開に伴う手動プロセスを自動化する方法について記載しました。これにより、エージェントをソースサーバーに迅速にデプロイし、一括移行の準備が行えるため、多くの作業時間を節約することができます。ぜひ、AWS Application Migration Serviceの ユーザーガイド を確認し、MGN コネクタやその他の新しいサービス機能をお試しください。 翻訳はソリューションアーキテクト 小宮山 裕樹 が担当しました。原文は こちら です。

Apache Iceberg は、 Amazon Simple Storage Service （ Amazon S3 ）における大規模データセット用のオープンなテーブルフォーマットであり、大規模テーブルに対する高速なクエリパフォーマンス、アトミックコミット、同時書き込み、SQL 互換のテーブル進化を提供します。Iceberg はデータレイクにおける ACID トランザクションをサポートし、スキーマやパーティションのエボリューション、タイムトラベル、ロールバックなどの機能で非常に人気があります。Iceberg はデータセットの状態に関するメタデータ情報を取得し、データセットの進化や時間経過に伴う変化を記録します。 AWS Glue クローラー が Iceberg テーブルをサポートするようになり、AWS Glue Data Catalog の利用や他の Iceberg カタログからの移行が容易になりました。AWS Glue クローラーはスキーマ情報を抽出し、Iceberg メタデータの場所やスキーマの変更を Glue Data Catalog に更新します。その後、すべてのアナリティクスエンジンでデータカタログの Iceberg テーブルにクエリし、 AWS Lake Formation のきめ細かい権限を適用することができます。 Iceberg カタログは、Iceberg テーブルのコレクションを管理し、テーブルの現在のメタデータを追跡するのに役立ちます。Iceberg カタログには、AWS Glue Data Catalog、Hive メタストア、JDBC カタログなど、いくつかの実装オプションがあります。AWS Glue Data Catalog は、 Amazon Athena 、AWS Glue、 Amazon EMR 、Lake Formation などの AWS 分析サービスと統合されているため、ユーザーにおいて AWS Glue Data Catalog の使用や移行が好まれています。 本日（2023年8月16日）の発表で、データカタログにある既存の Iceberg テーブルに対して AWS Glue クローラーを作成し、スケジュールすることができるようになりました。そして、Iceberg テーブルが配置されている 1 つまたは複数の S3 パスを指定することができます。クローラーがクロールできる S3 パスの最大深度を指定するオプションがあります。各クローラーの実行ごとに、クローラーは各 S3 パスを検査し、データカタログ内のスキーマに対する新しいテーブル、削除、更新などのスキーマ情報をカタログ化します。クローラーはすべてのスナップショットでスキーマのマージをサポートし、AWS の分析エンジンが直接使用できるデータカタログの最新のメタデータファイルの場所を更新します。 さらに、AWS Glue は、AWS Glue コンソールまたは AWS Glue CreateTable API を使用して、データカタログに新しい（空の）Iceberg テーブルを作成するためのサポートを開始します。今回のリリース以前は、Iceberg テーブルフォーマットを採用したいユーザーは、 CreateTable に加えて、別途 PutObject を使用して Amazon S3 上に Iceberg の metadata.json ファイルを生成する必要がありました。多くの場合、ユーザーは Athena や AWS Glue などの分析エンジンで create table ステートメントを使用していました。新しい CreateTable API は、metadata.json ファイルを別途作成する必要性をなくし、与えられた API 入力に基づいて metadata.json を自動生成します。また、 AWS CloudFormation テンプレートを使用してデプロイメントを管理するユーザーは、 CreateTable API を使用して Iceberg テーブルを作成できるようになりました。詳細については、 Apache Iceberg テーブルの作成 を参照してください。 Athena を使用してデータにアクセスする場合、Amazon S3 のデータロケーションを Lake Formation に登録する際に、Lake Formation によるきめ細かいアクセス制御権限を設定して Iceberg テーブルを保護することもできます。Amazon S3 のソースデータと Lake Formation に登録されていないメタデータについては、Amazon S3 と AWS Glue アクションの AWS Identity and Access Management (IAM) 権限ポリシーによってアクセスが決定されます。 ソリューション概要 このユースケースの例では、あるユーザーがデータ処理に Amazon EMR を使用し、トランザクションデータには Iceberg フォーマットを使用しています。商品データを Amazon S3 に Iceberg フォーマットで保存し、データセットのメタデータを EMR のプライマリノード上の Hive メタストア にホストしています。ユーザーは、Athena を使用したインタラクティブな分析のために、アナリストロールの人が商品データにアクセスできるようにしたいと考えています。多くのAWS分析サービスは Hive メタストア とネイティブに統合されていないため、AWS Glue Data Catalog にメタデータを入力するために AWS Glue クローラーを使用します。Athena は Iceberg テーブルの Lake Formation アクセス権の許可をサポートしていますので、データアクセスにはきめ細かいアクセス権を適用可能です。 Iceberg スキーマをデータカタログにオンボードし、Lake Formation アクセスコントロールを使用してクローリングを行うようにクローラーを構成します。データベースとクロールされたテーブルに対して Lake Formation によるアクセス権の許可を付与し、アナリストユーザーが Athena を使ってデータをクエリし、検証できるようにします。 既存の Iceberg データセットのスキーマを Data Catalog に入力した後、新しい Iceberg テーブルを Data Catalog に登録し、Athena を使用して新しく作成したデータにデータをロードします。データベースと新しく作成したテーブルに Lake Formation によるアクセス権の許可を付与し、アナリスト・ユーザーが Athena を使用してデータをクエリし、検証できるようにします。 次の図は、ソリューションのアーキテクチャーを示しています。 AWS CloudFormationでリソースをセットアップする AWS CloudFormationを使用してソリューションリソースを設定するには、以下の手順を実行します。 IAM 管理者として AWS Management Console にログインします。 スタックの作成 を選択してCloudFormation テンプレートをデプロイします。 次へ を選択します。 次のページで、 次へ を選択します。 最後のページで詳細を確認し、「 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。 」を選択します。 送信 （注意：画面上は左記の表記ですが 作成 の意味です。）を選択します。 CloudFormationテンプレートは以下のリソースを生成します。 EMR クラスタ用の VPC、サブネット、セキュリティグループ Iceberg テーブルデータとメタデータを格納するデータレイクバケット クローラーと Lake Formation 登録用の IAM ロール EMR クラスタと、Hive メタストアを使用して Iceberg テーブルを作成する手順 データアクセス用のアナリストロール 結果用の Athena バケットパス スタックが完成したら、AWS CloudFormation コンソールで、スタックの リソース タブに移動します。 EmrClusterId 、 DataLakeBucketName 、 LFRegisterLocationServiceRole 、 AWSGlueServiceRole 、 AthenaBucketName 、および LFBusinessAnalystRole の値をメモします。 Amazon EMR コンソールに移動し、作成された EMR クラスタを選択します。 ステップ タブに移動し、ステップが実行されたことを確認します。 このスクリプトは、Hive と Iceberg テーブルの product を使用してデータベース icebergcrawlerblodb を作成します。メタストアとして Amazon EMR 上の Hive メタストアサーバーを使用し、Amazon S3 にデータを保存します。 作成した S3 バケットに移動し、Iceberg テーブルのデータとメタデータが作成されていることを確認します。 このスタックがデプロイするリソースの中には、使用時にコストが発生するものもあります。 データが Amazon S3 上にあるので、バケットを Lake Formation に登録してアクセスコントロールを実装し、データガバナンスを一元化することができます。 Lake Formation の権限を設定する Lake Formation で AWS Glue Data Catalog を使用するには、以下の手順で Data Catalog の設定を更新し、IAM ベースのアクセス制御の代わりに Lake Formation によるアクセス権の許可を設定して Data Catalog リソースを制御します。 Lake Formation コンソールに admin としてサインインします。 Lake Formation コンソールに初めてアクセスする場合は、自分をデータレイク管理者として追加します。 ナビゲーションペインの Administration で Data Catalog Settings を選択します。 Use only IAM access control for new databases の選択を解除します。 Use only IAM access control for new tables in new databases の選択を解除します。 Cross account version settings で Version 3 を選択します。 Save を選択します。 これで Lake Formation によるアクセス権の許可を設定できるようになりました。 データレイクのS3バケットをLake Formationに登録する データレイクの S3 バケットを登録するには、以下の手順を実行します。 Lake Formation コンソールのナビゲーションペインで、 Data lake locations を選択します。 Register location を選択します。 Amazon S3 path には、データレイクバケットのパスを入力します。 IAM ロール は、CloudFormation テンプレートから LFRegisterLocationServiceRole に指定されたロールを選択します。 Permission mode は Lake Formation を選択します。 Register location を選択します。 クローラーにデータロケーションへのアクセス権を与える クローラーへのアクセスを許可するには、以下の手順を実行します。 Lake Formation コンソールのナビゲーションペインで、 Data locations を選択します。 Grant を選択します。 IAM users and roles で、クローラーのロールを選択します。 Storage locations には、データレイクのバケットパスを入力します。 Grant を選択します。 データベースを作成し、クローラーロールにアクセス権を付与する 以下の手順でデータベースを作成し、クローラーロールにアクセス権を付与します。 Lake Formation コンソールのナビゲーションペインで、 Databases を選択します。 Create database を選択します。 データベースの名前を icebergcrawlerblogdb とします。 Use only IAM access control for new tables in this database オプションが選択されていないことを確認します。 Create database を選択します。 Action メニューで Grant を選択します。 IAM users and roles で、クローラーのロールを選択します。 データベースは icebergcrawlerblogdb のままにしておきます。 Database permissions で Create table 、 Describe 、および Alter を選択します。 Grant を選択します。 Iceberg 用クローラーの設定 Iceberg 用のクローラーを設定するには、以下の手順を実行します。 AWS Glue コンソールのナビゲーションペインで、 Crawlers を選択します。 Create crawler を選択します。 クローラーの名前を入力します。この記事では、 icebergcrawler を使用します。 Next を選択します。 Data source configuration で、 Add data source を選択します。 Data source で Iceberg を選択します。 S3 path には、 s3://&lt;datalakebucket&gt;/icebergcrawlerblogdb.db/ を入力します。 Add a Iceberg data source を選択します。 Iceberg テーブルのサポートは、 CreateCrawler と UpdateCrawler の API と、以下のプロパティを持つ IcebergTarget をターゲットとして追加することで利用できます。 connectionId – Iceberg テーブルが VPC 認証が必要なバケットに格納されている場合、ここに接続プロパティを設定します。 icebergTables – これは icebergPaths 文字列の配列で、それぞれ Iceberg テーブルのメタデータファイルが存在するフォルダを示します。 以下のコードを参照してください。 { "IcebergTarget": { "connectionId": "iceberg-connection-123", "icebergMetaDataPaths": [ "s3://bucketA/", "s3://bucketB/", "s3://bucket3/financedb/financetable/" ] "exclusions": [ "departments/**", "employees/folder/**" ] "maximumDepth": 5 } } Next を選択します。 Existing IAM role には、スタックで作成したクローラーロールを選択します。 Lake Formation configuration で、 Use Lake Formation credentials for crawling S3 data source を選択します。 Next を選択します。 Set output and scheduling で、ターゲットデータベースを icebergcrawlerblogdb に指定します。 Next を選択します。 Create crawler を選択します。 クローラーを実行します。 各クロール中、提供された icebergTable パスごとに、クローラーは Amazon S3 List API を呼び出して、その Iceberg テーブルメタデータフォルダ下の最新のメタデータファイルを見つけ、 metadata_location パラメータを最新のマニフェストファイルに更新します。 次のスクリーンショットは、正常に実行された後の詳細を示しています。 クローラーは S3 データソースをクロールし、データカタログに Iceberg データのスキーマを入力することに成功しました。 これでデータカタログをプライマリメタストアとして使い始め、データカタログで直接、または createtable API を使って新しい Iceberg テーブルを作成することができます。 新しいIcebergテーブルを作成する コンソールを使用してデータカタログに Iceberg テーブルを作成するには、このセクションの手順を実施します。または、CloudFormation テンプレートを使用して、以下のコードを使用して Iceberg テーブルを作成することもできます。 Type: AWS::Glue::Table Properties: CatalogId:"&lt;account_id&gt;" DatabaseName:"icebergcrawlerblogdb" TableInput: Name: "product_details" StorageDescriptor: Columns: - Name: "product_id" Type: "string" - Name: "manufacture_name" Type: "string" - Name: "product_rating" Type: "int" Location: "s3://&lt;datalakebucket&gt;/icebergcrawlerblogdb.db/" TableType: "EXTERNAL_TABLE" OpenTableFormatInput: IcebergInput: MetadataOperation: "CREATE" Version: "2" IAMロールにデータロケーションへのアクセス権を付与する まず、IAM ロールにデータロケーションへのアクセス権を付与します。 Lake Formation コンソールのナビゲーションペインで Data locations を選択します。 Grant を選択します。 IAM users and roles の Admin IAM role を選択します。 Storage location に、データレイクのバケットパスを入力します。 Grant を選択します。 Iceberg テーブルの作成 以下の手順を実行して、Iceberg テーブルを作成します。 Lake Formation コンソールのナビゲーション ペインで、 Tables を選択します。 Create table を選択します。 Name に product_details と入力します。 Database に icebergcrawlerblogdb を選択します。 Table format は Apache Iceberg table を選択します。 Table location に &lt;datalakebucket&gt;/icebergcrawlerblogdb.db/ のパスを指定します。 Upload schema を選択後、以下のスキーマを指定し、 Upload を選択します。 [ { "Name": "product_id", "Type": "string" }, { "Name": "manufacture_name", "Type": "string" }, { "Name": "product_rating", "Type": "int" } ] Submit を選択してテーブルを作成します。 新しいIcebergテーブルにレコードを追加する Iceberg テーブルにレコードを追加するには、次の手順を実行します。 Athena コンソールで、クエリエディタに移動します。 設定 のタブを選択後、 管理 を選択し、CloudFormation の出力から AthenaBucketName に指定された値を使用して Athena クエリ結果の場所を構成します。 保存 を選択します。 以下のクエリを実行して、テーブルにレコードを追加します。 insert into icebergcrawlerblogdb.product_details values('00001','ABC Company',10) データカタログの Iceberg テーブルに Lake Formation によるアクセス権の許可を設定する Athena は Iceberg テーブルの Lake Formation によるアクセス権の許可をサポートしているので、この記事ではテーブルへのきめ細かいアクセス権を設定し、Athena を使用してクエリを実行する方法を紹介します。 これにより、データレイク管理者は Lake Formation コンソールを介して LFBusinessAnalystRole-IcebergBlogIAM ロールにデータベースとテーブルへのアクセス権の許可を委譲することができます。 ロールにデータベースと Describe へのアクセス権を許可する LFBusinessAnalystRole-IcebergBlogIAM ロールにDescribe 権限とともにデータベースへのアクセス権を許可するには、次の手順を実行します。 Lake Formationコンソールで、ナビゲーションペインの Permissions の下にある Data lake permissions を選択します。 Grant を選択します。 Principals で、 IAM users and roles を選択します。 IAM ロール LFBusinessAnalystRole-IcebergBlog を選択します。 LF-Tags or catalog resources で、 Named Data Catalog resources を選択し、 Databases に icebergcrawlerblogdb を選択します。 Database permissions で Describe を選択します。 許可を適用するには、 Grant を選択します。 ロールにカラムアクセスを許可する 次に、 LFBusinessAnalystRole-IcebergBlogIAM ロールに列アクセス権を付与します。 Lake Formation コンソールのナビゲーションペインの Permissions で、 Data lake permissions を選択します。 Grant を選択します。 Principals で、 IAM users and roles を選択します。 IAM ロール LFBusinessAnalystRole-IcebergBlog を選択します。 LF-Tags or catalog resources で、 Named Data Catalog resources を選択し、 Databases に icebergcrawlerblogdb を、 Tables に product を選択します。 Table permissions で Select を選択します。 Data permissions で Column-based access を選択します。 Include columns を選択し、 product_name と price を選択します。 権限を適用するには、 Grant を選択します。 ロールにテーブルへのアクセス権を付与する 最後に、 LFBusinessAnalystRole-IcebergBlogIAM ロールにテーブルアクセスを付与します。 Lake Formation コンソールのナビゲーションペインの Permissions で Data lake permissions を選択します。 Grant を選択します。 Principals で、 IAM users and roles を選択します。 IAM ロール LFBusinessAnalystRole-IcebergBlog を選択します。 LF-Tags or catalog resources で、 Named Data Catalog resources を選択し、 Databases に icebergcrawlerblogdb を、 Tables に product_details を選択します。 Table permissions で Select と Describe を選択します。 許可を適用するには、 Grant を選択します。 Athena を使用したテーブルの検証 Athena を使用してテーブルを検証するには、 LFBusinessAnalystRole-IcebergBlogrole に切り替え、以下の手順を実行します。 Athena コンソールで、クエリエディターに移動します。 設定 のタブを選択後、 管理 を選択し、CloudFormation 出力から AthenaBucketName の値を使用して Athena クエリ結果の場所を構成します。 保存 を選択します。 product と product_details のクエリを実行して、アクセスを検証する。 次のスクリーンショットは、 product のカラムパーミッションを示しています。 次のスクリーンショットは、 product_details のテーブル・パーミッションを示しています。 Hive メタストアから作成した Iceberg データセットを Amazon S3 上のデータでクロールし、スキーマが設定された AWS Glue Data Catalog テーブルを作成することに成功しました。データレイクのバケットを Lake Formation に登録し、Lake Formation によるアクセス権の許可設定を使用してデータレイクへのクローラーのアクセスを有効にしました。データベースとテーブルに対する Lake Formation によるアクセス権の許可をアナリストユーザーに付与し、Athena を使用してデータへのアクセスを検証しました。 クリーンアップ AWSアカウントへの不要な課金を避けるために、AWSリソースを削除します。 CloudFormation スタックの作成に使用した IAM 管理者として CloudFormation コンソールにサインインします。 作成したCloudFormationスタックを削除します。 まとめ Iceberg のクローラーがサポートされたことで、Iceberg テーブルのプライマリカタログとしてAWS Glue データカタログへすぐに移行することができます。AWS の Glue クローラーを実行することで、自動的にIceberg テーブルをデータカタログに登録することができ、DDL や手動でのスキーマ定義が不要になります。AWS Glue クローラーを使用して AWS 上のサーバーレスでトランザクション可能なデータレイクの構築の開始、データカタログを使用して新しいテーブルの作成、Athena による Iceberg テーブルフォーマットのクエリのために Lake Formation のきめ細かいアクセス制御を利用することができます。 様々な AWS 分析サービスにおける Iceberg テーブルの Lake Formation サポートについては、 他のAWSサービスでの使用 を参照してください。 原文は こちら です。

マルチアカウント戦略 に関する AWS のベストプラクティスに従い、お客様は製品、グループ、部門などに応じて、複数のアカウントとリージョンで Amazon Connect インスタンスを起動して維持しています。これにより、個々のビジネスオーナー、開発者、エンジニアなどは、各自の独立した Amazon Connect 環境に変更を加えることができます。このようなシナリオでは、 Amazon Connect 環境全体にわたるユーザーやリソースのアクティビティに関する調査を簡素化し、管理するための一元的な仕組みが必要です。 お客様がマルチアカウント環境で Amazon Connect パブリック API を追跡、記録、分析できるように、Amazon Connect は、すべてのパブリック Amazon Connect API 呼び出しを記録するサービスである AWS CloudTrail と統合されています。AWS CloudTrail を使用すると、お客様は AWS Organization 全体でログを収集し、一元化された Amazon Simple Storage Service (S3) バケットに送信できます。また、サーバーレスのインタラクティブ分析サービスである Amazon Athena には、一元化された Amazon Connect ログのクエリと分析を行う機能が備わっています。 このブログ記事では、複数の AWS アカウントとリージョンにわたる Amazon Connect インスタンスのアクティビティを記録、表示、クエリ、分析するために必要な手順について説明します。この情報により、Amazon Connect のセキュリティ状況を把握し、想定から逸脱したアクティビティを調査できます。 前提条件 このチュートリアルでは、次の前提条件を満たしている必要があります。 Amazon Conenct パブリック API の基本的な理解 AWS Organization の 管理アカウント へのアクセス 組織の証跡 を作成できること チュートリアル このチュートリアルでは、アカウントとリージョンを横断し、削除された Amazon Connect インスタンスを調査します。まず、組織全体で削除された Amazon Connect インスタンスの数を確認することから始めます。次に、削除を行ったユーザーを特定し、他のアクティビティを調べます。 まず、 組織の証跡 を作成します。組織の証跡を作成すると、組織全体の Amazon Connect パブリック API の履歴を記録し、CloudTrail ログを一元化された S3 バケットに送信します。次に、Amazon Athena を使用してこの一元化された S3 バケットにクエリを実行し、アカウントとリージョンを横断して Amazon Connect のアクティビティを分析します。図 1 は、このワークフローを図示したものです。 図 1: 一元化された CloudTrail ログへのクエリ ステップ 1: 組織の証跡の設定 既存の組織の証跡がある場合、この演習でも既存の証跡を使用できます。既存の組織の証跡にアクセスできない場合は、以下の手順に従ってください。管理イベントを Amazon S3 に配信する場合、 1 つの配信は 無料 です。 CloudTrail コンソール に移動します。左側のペインから証跡を選択し、右側のペインから証跡の作成を選択します。 証跡属性の選択ページ で、 cloudtrail-connect-example などの証跡名を指定します。 組織内のすべてのアカウントで有効化 のボックスにチェックを入れます。 わかりやすくするために、 ログファイルの SSE-KMS 暗号化 は有効にしません。他のオプションはデフォルトのままにします。 次へ を選択します。 ログイベントの選択 ページですべてデフォルトのままにして、 次へ をクリックします。 確認と作成 ページで、 証跡の作成 を選択します。 これで証跡が作成されました。 S3 バケットの列 のバケット名をメモしておきます。 ステップ 2: Athena テーブルの設定 Athena コンソール に移動し、 クエリエディタ を選択します。Athena を使用して初めてログを記録する場合、以下のメッセージが表示されます。 設定を編集 を開き、クエリ結果の場所の S3 バケットを設定します。 組織 ID を確認するため、AWS Organizations のコンソールにアクセスします。左側のパネルの 組織 ID をコピーします。 Athena コンソール に戻り、クエリエディタを開きます。右側のペインのクエリエディタにクエリを入力し、実行することができます。 以下のクエリを使用して、結果をクエリするためのテーブルを作成します。 S3 バケット名 (ステップ 1 でメモしたもの) と 組織 ID (o-xxxxxxxxxx) は置き換えてください。 CREATE EXTERNAL TABLE cloudtrail_logs ( eventversion STRING, useridentity STRUCT&lt; type:STRING, principalid:STRING, arn:STRING, accountid:STRING, invokedby:STRING, accesskeyid:STRING, userName:STRING, sessioncontext:STRUCT&lt; attributes:STRUCT&lt; mfaauthenticated:STRING, creationdate:STRING&gt;, sessionissuer:STRUCT&lt; type:STRING, principalId:STRING, arn:STRING, accountId:STRING, userName:STRING&gt;, ec2RoleDelivery:string, webIdFederationData:map&lt;string,string&gt; &gt; &gt;, eventtime STRING, eventsource STRING, eventname STRING, awsregion STRING, sourceipaddress STRING, useragent STRING, errorcode STRING, errormessage STRING, requestparameters STRING, responseelements STRING, additionaleventdata STRING, requestid STRING, eventid STRING, resources ARRAY&lt;STRUCT&lt; arn:STRING, accountid:STRING, type:STRING&gt;&gt;, eventtype STRING, apiversion STRING, readonly STRING, recipientaccountid STRING, serviceeventdetails STRING, sharedeventid STRING, vpcendpointid STRING, tlsDetails struct&lt; tlsVersion:string, cipherSuite:string, clientProvidedHostHeader:string&gt; ) ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe' STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3:// ENTERNAMEOFS3BUCKET /AWSLogs/ ENTERORGID /'; 左側のテーブルとビューのパネルに cloudtrail_logs というテーブルが作成されました。 次に、テーブルに追加する必要があります。そのため、クエリエディターでプラス (+) 記号を選択して、次のクエリ用に新しいタブを作成します。 ALTER TABLE cloudtrail_logs SET LOCATION 's3:// ENTERNAMEOFS3BUCKET /AWSLogs/ ENTERORGID /' ステップ 3: 複数のアカウントとリージョンにわたる Amazon Connect アクティビティの調査 Amazon Connect のアクティビティをシミュレートするため、複数のアカウントとリージョンで Amazon Connect インスタンスを作成 し、後で それらのインスタンスを削除 します。CloudTrail レコードが表示されるまで数分待ってから、次のクエリを新しいタブに入力してください。 アカウントとリージョン全体で 削除された インスタンスの数を確認するには、 Athena コンソール に移動して以下のクエリを実行します。 SELECT eventName, count(eventName) AS NumberOfDeletedInstances, recipientaccountid, awsRegion FROM cloudtrail_logs Where eventname = 'DeleteInstance' AND eventsource = 'connect.amazonaws.com' GROUP BY eventName, recipientaccountid, awsRegion これらのインスタンスを削除したユーザーを特定するには、以下のクエリを実行します。 useridentity.arn をコピーしておきます。 SELECT useridentity.arn, recipientaccountid, sourceipaddress, eventtime, awsRegion, eventName, requestParameters FROM cloudtrail_logs Where eventname = 'DeleteInstance' AND eventsource = 'connect.amazonaws.com' これらの削除を行ったユーザーのアクティビティを確認するには、以下のクエリを実行します。 SELECT eventName, recipientaccountid, sourceipaddress, eventtime, awsRegion FROM cloudtrail_logs Where useridentity.arn = 'ENTERTHEUSERARN' AND eventsource = 'connect.amazonaws.com' 上記の例の手順で、アカウント・リージョン全体の Amazon Connect に関する CloudTrail ログをクエリできました。Amazon Connect のログファイルのエントリの詳細については、AWS CloudTrail ドキュメントの「 AWS CloudTrail を使用して Amazon Connect API 呼び出しをログ記録する 」をご覧ください。 クリーンアップ 検証の為だけにブログの手順に従っていた場合は、請求が継続しないようにアカウントをクリーンアップしてください。そうでない場合は、クリーンアップを実行しないでください。クリーンアップするには、以下の手順に従ってください。 この演習の一環として CloudTrail の組織の証跡を作成した場合は、 CloudTrail コンソール に移動し、作成した証跡を選択して 削除 を選択します。 S3 コンソール に移動します。すべてのアカウントの CloudTrail ログを保存するために作成した S3 バケットを 削除 します。 結論 このブログ記事では、組織の証跡を使用して複数のアカウントとリージョンにわたる Amazon Connect に関するアクティビティをクエリする方法を紹介しました。Amazon Connect の詳細については、 Amazon Connect のドキュメント をご覧ください。 著者について Pranjal Gururani Pranjal Gururani は、シアトルを拠点とする AWS のソリューションアーキテクトです。Pranjal はさまざまなお客様とビジネス上の課題に対処するクラウドソリューションを構築しています。ハイキング、カヤック、スカイダイビングを楽しみ、余暇には家族と過ごす時間を楽しんでいます。 Guy Bachar Guy Bachar は、ニューヨークを拠点とする AWS のソリューションアーキテクトです。彼はグリーンフィールドのお客様の AWS を使用したクラウドへの移行を支援しています。ID、セキュリティ、ユニファイドコミュニケーションに情熱を注いでいます。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

組織が未来に対応できるようにすることは、企業のシニア・リーダーの仕事です。しかし、残念ながら未来は不透明で、急速な変化、不確実性、複雑性の時代においてはなおさらです。天気と同じように、私たちは近い将来をある程度確実に予測することができますが、先を見通すにつれて、その保証は薄れてきます。そして今日、濃い霧が立ち込め、1、2メートル先も見えないような状況になっています。では、どうすれば企業はその未来に備えることができるのでしょうか？ 喩えを徹底的に打ちのめすことを終わりにして、うまくいかないことを認めざるをえません。それは、霧の中を大胆に闊歩して、突然穴ぼこにつまずいたり崖から落ちたりするまで、あたかも見えているかのようにすることです。それは、馬鹿げているかと思えるかもしれませんが、多くの伝統的な企業がやっていることです。あたかも遠くまで見通せるかのような硬直した計画を立て、今年のニーズでさえ変化する可能性が高いのに、来年必要になると思われるリソースを獲得し、変化や革新を困難にするガードレールを設けることをしています。 本ブログは、未来に対応できるようになるための記事ですが、正直なところ、筆者は未来がどうなるのかほとんどわかっていません。労働力としてロボットを管理し、AI に事務用品を人質に取られたときに交渉する方法をお伝えしたいところだが、私が目にするのは、時折可能性のある道筋が垣間見える霧のようなものがほとんどなのです。 とはいえ、リーダーは組織が未来に備えるようにしなければなりません。そのための方法がこちらです。 回復力と俊敏性を高める 回復力と俊敏(訳者注：Resilience and agility、レジリエンスとアジリティ) とは、予期しない、あるいは予期できない状況に対応する能力を指す言葉です。それ故に、ビジネスにとって価値があります。貴社は、回復力と俊敏性への投資のリターンをどのように評価しているのでしょうか？　通常、企業は、収益の増加やコストの減少といった目に見えるリターンの予測に基づいて、潜在的な投資の価値を評価します。しかし、回復性への投資は、リスクの削減や選択肢の創出といった、より具体的な準備への投資です。具体的なリターンが予測される投資と比較して、優先順位をつけるのは困難です。特に、組織が、未来に霧がかかっていないかのように装ってリターンを予測している場合はなおさらです。 しかし、回復性と俊敏性は、将来への備えとして極めて重要です。そのためには、将来への継続性という広い視野が必要です。将来には、突然、新たな分かれ道が現れ、道路工事や料金所、あるいは空から降ってくる象によって、道が不意にふさがれてしまうかもしれません。組織には、新たなテクノロジーに対応し、容易に変更し、拡大・縮小できる技術インフラが必要です。また、状況の変化に適応できる労働力と企業文化も必要である。組織がロボット労働者の権利を認める必要があると判断したとき、あるいは生成 AI が顧客一人ひとりに関する小唄を作成し始めたとき、企業のガバナンス・プロセスはそれを受け入れることができるでしょうか？　さらに深刻なのは、状況の変化に応じて資金やその他のリソースを振り向けることができるかどうかです。パンデミックや戦争でマネジャーがいなくなった場合、他の誰かが代わりに行動できるでしょうか?　マネージャーのかわりの人は適切な権限を持ち、適切なデータにアクセスし、必要に応じて支出を委ねることができるだろうか？ 技術面では、未来に対応する組織は柔軟なテクノロジーと技術プロセスを採用する必要があります。今日、DevOps とクラウドは、回復性と俊敏性を獲得するための最良の方法です。クラウドは、インフラストラクチャの迅速な変更と、イノベーションをサポートするサービスの迅速なプロビジョニングを可能にします。DevOpsは、変更を本番環境に迅速に導入します。技術アーキテクチャは柔軟に設計でき、機械学習は、極めて複雑な機能を迅速に構築するための強力な手法になります。機械学習は、未来に対応できる企業の持つ道具セットに入っているべきなのです。 組織に回復性と俊敏性を構築することについては、まだまだ語りたいことがたくさんありますが、他のブログ記事でも頻繁に取り上げているので、この辺で話を進めることにしましょう。 未来志向のパートナーやプロバイダーとの連携 ベンダーやパートナーも同様の課題に直面しています。彼らもまた、不確実な将来に備えなければなりません。この意味で、クラウド・プロバイダーの選択は非常に重要です。 AWS が理想的なパートナーである理由を説明したいと思います。 AWS はクラウドのパイオニアであり、クラウドサービスにおけるイノベーションの最前線にいます。新しいテクノロジーが登場すれば、それらは間違いなくクラウドに登場します。どのような技術かは聞かないでほしいのですが （前述の通り、私はあなたと同じ霧の天気予報しか持っていません）、おそらく、あなたのデータセンターで利用できるようになるずっと前に、クラウドで利用できるようになるでしょう。 AWS は、新しいテクノロジーを試すコストとリスクを軽減することに取り組んでおり、私たちの基本理念の1つは、新しいテクノロジーを民主化し、簡単にアクセスできるようにすることです。言い換えれば、たとえ私たちが未来がどうなるのかよくわからなくても、 AWS が未来を利用できるように努力することは保証されます。 AWS は Amazon.com を動かしているテクノロジーであることを覚えておいてください。 AWS の顧客は、 Amazon.com が未来に進むために頼りにしているのと同じクラウド機能を利用できるのです。 AWS はアマゾンのニーズを満たすために進化し続けます。この表現の通り、まずは自分たちで試しているわけです。アマゾンのレコメンデーション・エンジン、フルフィルメント・センターでのロボットによるピッキング・ルート、配送ドローンや Amazon Go 店舗のビジョン機能、サプライチェーンやロジスティクスの予測システムなどの基盤となっています。 未来に対応できるようになるには、ベンダーの現在の能力だけでなく、ベンダーの未来への可能性を検証することが必要です。 目的と使命を明確にする たとえあなたの組織が変化に対応することに長けていたとしても、潜在的な問題はあるはずです。強い使命感、ビジョン、目的、指針が必要です。それは、ミッション・ステートメントを言葉で作ったり、壁に貼るポスターを作ったりする問題ではなく、何をもって自社の努力を団結させ、従業員のモチベーションを高め、競合他社や他のステークホルダーとの相対的な世界における自社のポジションを定義するかという問題なのです。 目的は、切迫感、思いやり、新しいアイデアに挑戦する意欲、結果のオーナーシップを駆り立てます。それは従業員に力を与え、誰もが組織の方向性を理解することで意思決定の分散化を可能にするのです。また、会社が何を目指しているのかを顧客に伝えることができ、競争力のあるポジショニングの一部となっていきます。 未来対応型であることとは、混乱期においても企業の努力を統合し、リーダーや従業員が変化の時代に迅速な意思決定を行えるような、強い方向感覚を持つことです。 労働力と柔軟なキャパシティ これは我慢しがたいことかもしれませんが、未来に対応する組織には余剰キャパシティが必要です。経済的には非効率に聞こえるかもしれませんが、リーン思考は、稼働率が高すぎ、そのキャパシティに対する需要が予測不可能な場合、 キングマンの方程式 で予測されるように、リードタイムが大きく損なわれる可能性があることを示しています。需要が予測可能な場合、生産能力計画は効果的なのです。需要が予測不可能な場合、ベルトの締め付けが強すぎると、単に他のコストが発生するだけです。 それには、従業員がジェネラリストであり、必要に応じて1つの機能と別の機能を行き来できることが助けになります。未来は霧に包まれているため、私たちは何をしなければならないのか、あまりよくわかっていません。それよりも、組織の目的を達成するために必要なことは何でもやるという文化を育て、さまざまなスキルを持った社員を抱える方がいいのです。 結論 未来に対応できるというのは、未来に何が起こるかを正確に知っていて、そのために今どう準備すべきかを知っているという意味ではありません。未来が進む方向を察知し、それに適応する能力に長けているということです。そしてそれは、組織が習得できるスキルであり、リーダーが率いるべき方法なのです。 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 を取得し、イェール大学でコンピューターサイエンスの理学士号を取得し、イェール大学で哲学の修士号を取得しています。 この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。原文は こちら です。

この記事は、 Automate Ethereum node validator deployment on Amazon EC2 using AWS CDK を翻訳したものです。 イーサリアム は、スマートコントラクト機能を持つ分散型のオープンソースブロックチェーンです。 Beacon chain （ETH2）は、イーサリアムのアップグレード版で、イーサリアムのエコシステムにプルーフ・オブ・ステークの概念を導入したものです。ETH2でのステークは、Ethereumネットワークのセキュリティとスケーラビリティを向上させるために、認証や新しいブロック作成の提案などのアクションを実行するバリデーターによって行われます。バリデーターは、ステーキングを行うことで報酬を得ることができます。 AWSは現在、 Amazon Managed Blockchain （AMB）を提供しています。これは、一般的なオープンソースフレームワークを使用して、スケーラブルなブロックチェーンネットワークを簡単に作成・管理できるフルマネージドサービスです。現在、私たちは Hyperledger Fabric としてプライベート許可型ネットワークを、またパブリックのmainnetと2つの人気テストネットであるRinkebyとRopsten(*)に接続する イーサリアム フルノードをサポートしています。Amazon Managed Blockchainは、現時点ではEthereum Beaconチェーンをサポートしていません。 Rocket Pool は、Beaconチェーンをサポートする分散型ステーキングプールの1つです。ステーキングで報酬を得たいバリデーターは、Rocket Poolを使用して自分の検証ノードを作成することができます。これらの検証ノードは、 Graviton2 プロセッサを搭載した Amazon Elastic Compute Cloud (Amazon EC2) 上で実行することができます。この記事では、 Amazon Elastic Compute Cloud 上での Rocket Pool のデプロイを簡素化する AWS Cloud Development Kit (AWS CDK) アプリについて紹介します。 (*) 2022/11/1時点でGoerilのテストネットもサポートされています。 ソリューションの概要 CDKは、オープンソースのソフトウェア開発フレームワークで、使い慣れたプログラミング言語を使ってクラウドアプリケーションリソースを定義することができます。 私たちのCDKアプリは、8つのvCPUと16GBのメモリを含むc6g.2xlargeインスタンスを使用して、Rocket Pool検証ノードを作成します。c6gインスタンスはGraviton2プロセッサを搭載しており、Ethereum検証のようなブロックチェーンワークロードに理想的です。また、高性能なブロックストレージとして2TBの Amazon Elastic Block Store （EBS）デバイスを、安全なアクセスとして AWS Systems Manager Session Manager を構成しています。 次の図は、AWS CDKを使用してアプリを初期化、合成、デプロイするプロセスを示しています。 このデプロイメントでは、ETH1とETH2の両方のブロックチェーンネットワークの検証を実行します。デフォルトでは、このノードはETH1検証用にGethクライアント、ETH2検証用にLighthouseクライアントを使用するように設定されています。デプロイ後にRocket Pool CLIを使用してこれらのクライアント設定を変更することができます。 ローカルのデスクトップでAWS CDKを使用することができます。 手順のドキュメント を参照してAWS CDKを使い始めることができます。 依存関係とRocket Pool AWS CDKアプリケーションをダウンロードしインストール 以下のコードを使用して、AWS CDKと前提アプリをダウンロードおよびインストールします。 # Install TypeScript globally for CDK npm i -g typescript # If you are running these commands in Cloud9 or already have CDK installed, then # skip this command npm i -g aws-cdk # Clone the demo CDK application code git clone https://github.com/aws-samples/cdk-rocketpool-validator-node # Change directory cd cdk-rocketpool-validator-node # Install the CDK application npm install Rocket Poolは16GBまたは32GBのメモリを搭載したノードをデプロイすることを推奨しています。この記事では、16GBのインスタンスでデプロイしています。ただし、メモリを増やしたい場合は 　lib/cdk-rocketpool-validator-stack.ts ファイルを修正します。例えば、以下のデプロイコードで、ec2.InstanceSize.XLARGE2 を ec2.InstanceSize.XLARGE3 または XLARGE4 に変更します。 // Create the instance const ec2Instance = new ec2.Instance(this, 'Instance', { vpc, instanceType: ec2.InstanceType.of(ec2.InstanceClass.C6G, ec2.InstanceSize.XLARGE2), machineImage: ami, securityGroup: securityGroup, role: role, blockDevices: [rootVolume] }); # Bootstrap the CDK application for first time cdk bootstrap # Deploy the CDK application cdk deploy ➜ rocketpool-blog git:(main) cdk deploy This deployment will make potentially sensitive changes according to your current security approval level (—require-approval broadening). Please confirm you intend to make the following modifications: IAM Statement Changes ┌───┬──────────────────────────────────┬────────┬──────────────────────────────────┬──────────────────────────────────┬───────────┐ │ │ Resource │ Effect │ Action │ Principal │ Condition │ ├───┼──────────────────────────────────┼────────┼──────────────────────────────────┼──────────────────────────────────┼───────────┤ │ + │ ${ec2Role.Arn} │ Allow │ sts:AssumeRole │ Service:ec2.${AWS::URLSuffix} │ │ ├───┼──────────────────────────────────┼────────┼──────────────────────────────────┼──────────────────────────────────┼───────────┤ │ + │ arn:${AWS::Partition}:s3:::{"Fn: │ Allow │ s3:GetBucket* │ AWS:${ec2Role} │ │ │ │ :Sub":"cdk-hnb659fds-assets-${AW │ │ s3:GetObject* │ │ │ │ │ S::AccountId}-${AWS::Region}"} │ │ s3:List* │ │ │ │ │ arn:${AWS::Partition}:s3:::{"Fn: │ │ │ │ │ │ │ :Sub":"cdk-hnb659fds-assets-${AW │ │ │ │ │ │ │ S::AccountId}-${AWS::Region}"}/* │ │ │ │ │ └───┴──────────────────────────────────┴────────┴──────────────────────────────────┴──────────────────────────────────┴───────────┘ IAM Policy Changes ┌───┬────────────┬────────────────────────────────────────────────────────────────────┐ │ │ Resource │ Managed Policy ARN │ ├───┼────────────┼────────────────────────────────────────────────────────────────────┤ │ + │ ${ec2Role} │ arn:${AWS::Partition}:iam::aws:policy/AmazonSSMManagedInstanceCore │ └───┴────────────┴────────────────────────────────────────────────────────────────────┘ Security Group Changes ┌───┬──────────────────────────┬─────┬────────────┬─────────────────┐ │ │ Group │ Dir │ Protocol │ Peer │ ├───┼──────────────────────────┼─────┼────────────┼─────────────────┤ │ + │ ${SecurityGroup.GroupId} │ In │ TCP 22 │ Everyone (IPv4) │ │ + │ ${SecurityGroup.GroupId} │ Out │ Everything │ Everyone (IPv4) │ └───┴──────────────────────────┴─────┴────────────┴─────────────────┘ (NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299) Do you wish to deploy these changes (y/n)? y CdkRocketpoolValidatorStack: deploying... [0%] start: Publishing 1e05055f04e0f731f0605c1138bcef8f9b37398dac16b3c617b743b9e9ff1b36:current_account-current_region [50%] success: Published 1e05055f04e0f731f0605c1138bcef8f9b37398dac16b3c617b743b9e9ff1b36:current_account-current_region [50%] start: Publishing 83d98b3d48439ff5155c3381d7bb65e8e94aff567b80132f374e41e033c588c9:current_account-current_region [100%] success: Published 83d98b3d48439ff5155c3381d7bb65e8e94aff567b80132f374e41e033c588c9:current_account-current_region CdkRocketpoolValidatorStack: creating CloudFormation changeset... [··························································] (0/18) 10:17:23 PM | CREATE_IN_PROGRESS | AWS::CloudFormation::Stack | CdkRocketpoolValidatorStack デプロイメントが完了すると、次のような出力が得られます。 ✅ CdkRocketpoolValidatorStack Outputs: CdkRocketpoolValidatorStack.IPAddress = 3.92.48.208 CdkRocketpoolValidatorStack.sshcommand = aws ssm start-session --target i-03deeff4f403fa189 —document-name SSM-RocketPoolConfiguration Stack ARN:arn:aws:cloudformation:us-east-1:1218594674:stack/CdkRocketpoolValidatorStack/4d31dd40-7979-11ec-a7cb-12 この時点で、AWS CDK Outputsからsshコマンドを実行し、インスタンスにログインしてください。 aws ssm start-session --target i-03deeff403fa189 —document-name SSM-RocketPoolConfiguration 以下は出力例です。 Starting session with SessionId: &lt;&gt; cd ~ &amp;&amp; bash sh-4.2$ cd ~ &amp;&amp; bash [ec2-user@ip-10-0-0-16 ~]$ インストールの完了 接続が完了したら、以下のコマンドを実行して残りのインストールを完了させることができます。 rocketpool service start (オプション) ETH1/ ETH2 のクライアントを変更したい場合は、以下のコマンドを実行します。ETH1のデフォルトクライアントはGeth、ETH2のデフォルトクライアントはLighthouseです。 rocketpool service config 詳細については、 Configuring the Smartnode Stack を参照してください。前述のスタックはPraterテストネットワークで実装されています。メインネットに切り替えたい場合は、 Pool Staking on Mainnet を参照してください。 Rocket pool には Grafana のサポートが付属しており、ETH2 クライアントごとにあらかじめダッシュボードが構築されています。ブラウザで http://&lt;your node IP&gt;:&lt;grafana port&gt; に移動して、 Grafana にログインすることができます。Grafana ポートは、デフォルトで 3100 に設定されています。デフォルトのログイン認証情報やダッシュボードのインポート方法などの追加情報は、Rocket Pool のドキュメントの Setting up Grafana セクションに記載されている場合があります。以下は、Prysm ETH2 クライアントのメトリクスを表示するダッシュボードのサンプル画像です。 クリーンアップ この記事で作成したリソースを次のコードでクリーンアップします。 cdk destroy CdkRocketpoolValidatorStack まとめ Rocket Poolは、Ethereumノードバリデーターがプルーフ・オブ・ステーキングによって報酬を得ることを可能にします。この投稿では、AWS CDKを使用して最小限のセットアップ時間でAWSクラウドのRocket PoolにETH2バリデーターをデプロイする方法を示しました。また、Session Managerを使用してノードに安全にアクセスする方法も紹介しました。ETHバリデータをメインネットにデプロイする前に、テストネットで試してみることをお勧めします。 フィードバックや追加の質問がある場合は、コメントを残すことをお勧めします。 本稿はソリューションアーキテクト畑が翻訳を担当しました。

この記事は、Origin社のColeman MaherとAWSのKevin Goodspeedによる投稿記事 How to Create and Sell Non-Fungible Tokens (NFTs) を翻訳したものです。 Non-Fungible Token (NFTs)は、新しいタイプのデジタル資産で、いろいろなところで話題になっています。NFTは、懐疑的な人からはナンセンスだと言われ、多くの人からはデジタルビーニーベイビーや野球カードだと言われ、真の信者からはデジタルコンテンツからアーティストとファンの交流方法まで全てを変えてしまう革命的な新しいアイデアだと言われています。私はOrigin ProtocolでNFTを担当し、すでに多くの業界でNFTがいかにゲームチェンジャーであるかを目の当たりにしています。このブログでは、NFTの世界を簡単に紹介し、また、自分でNFTを発行し、様々なプラットフォームやマーケットプレイスで取引する方法をお教えしたいと思います。 NFTの紹介 Non-Fungible Token（NFT）は、ユニークまたはレアなデジタル資産です。一般的に受け入れられている同等品と簡単に交換できるアイテムは、「代替可能」と言えます。例えば、1ドル札は別の1ドル札、4セント硬貨、100セント硬貨と交換することができます。NFTは、1つしか存在しないユニークなアイテムである場合があります。また、限られた数しか存在しない、希少なものである場合もあります。NFTが表現できるものに制限はありません。NBAはNBA Top Shotsでバスケットボールの試合のハイライトのビデオクリップを表現するためにNFTを使用しています。 NFTはまた、限定品のハンドバッグのような物理的な物の所有権証明にも利用できます。また、芸術の世界では「provenance」として所有権の証跡を提供することもできます。NFTが物理的なモノと結びつけられるなら、NFTは実体験とも結びつけられ、例えばコンサートやプライベートな公演へのアクセスチケットとして機能することも可能です。NFTの非常に強力な側面の1つは、二次販売取引による将来の収益を、NFTのオリジナル作成者または「発行者」にプログラム的に流用できることです。つまり、最初の販売後にNFTが何度も買い替えられたとしても、元の作成者は収益やロイヤリティを得ることができます。 NFTを発行する方法 独立系クリエイターによるNFTの活動の大部分は、イーサリアムのブロックチェーン上で行われています。イーサリアムとやり取りするには、モバイルアプリケーションとブラウザ拡張機能を持つMetaMaskのようなWeb3対応のウォレットが必要です。イーサリアムで取引を行うには、ブロックチェーンネットワークや「ガス」の手数料を支払うためのイーサリアムのネイティブ暗号通貨であるETHがウォレットに必要です。ETHはCoinbaseのような取引所で取得することができます。 イーサリアムのNFTはオープンソースの標準に基づいており、自分のウォレットに保有、つまり「保管」することになります。つまり、NFTを発行する際、特定のプラットフォームに縛られることなく、自分の好きなツールやプラットフォームを使ってNFTを作成することができます。例えば、MintbaseでNFTを発行し、OpenSeaでそれを公開・販売しても、NFTは自分のウォレットから出ることはありません。 OpenSeaは最近、クリエイターがガス代（手数料）を支払うことなくNFTを発行できる機能を発表しました。その方法について、 ステップバイステップのガイド が公開されています。まず、NFTを追加するコレクションを作成する必要があります。コレクションを作成し、名前を付けたら、画像ファイル、ビデオファイル、3Dモデル、音楽ファイルなど、基本的にあらゆる種類のデジタルコンテンツ・ファイルを使ってNFTを作成し、追加することができます。NFTの名前、説明、レア度も設定することができます。 Mintbaseは、クリエイターがNFTを簡単に発行できるもう一つのプラットフォームです。MintbaseはOpenSeaと同様、NFTを発行するためにまずストアを作成する必要があります。必要な手順については、 非暗号化ユーザー向けのガイド を参照してください。Mintbaseは現時点では画像のみをサポートしているため、ビジュアルアーティストに最適です。ストアを作成したら、名前、説明、数量を指定して NFT を発行し、ストアに追加します。すべてのNFTはデフォルトで販売用になっていますが、ボックスをチェックして販売用に表示されないようにすることができます。 Foundationは、NFTクリエイターのための招待制を採用しているプラットフォームです。Foundationは、誰でもプロフィールを作成できますが、選ばれたクリエイターだけがNFTを発行することができます。Foundationは、プラットフォーム上で NFTを発行する方法に関する完全なガイド を公開しています。Foundationは、画像、ビデオファイル、オーディオファイル、3DモデルによるNFTの発行をサポートしています。NFTの名前、説明、数量を選択することができます。 NFTSを売却する方法 ほとんどのNFTプラットフォームでは、NFTをリストして販売することもできます。OpenSeaでNFTを売却するには、そのNFTのアセットページに移動し、「売却」をクリックします。設定価格、オークション、バンドル販売から販売の種類を選択し、その他の条件を設定することができるようになります。 OpenSea のガイド では、すべての手順を説明しています。Mintbaseでは、デフォルトですべてのNFTが販売用にリストされています。NFTを販売用にリストしないことを選択した場合は、そのNFTに移動して「販売中」をチェックし、価格を設定することができます。Foundationは、NFTオークションに重点を置いています。NFTをオークションに出品するには、オークションに移動してリザーブプライスを設定し、「List Your NFT」をクリックしてオークションを開始します。オークションは24時間行われ、最後の15分間で入札があると、オークションはさらに15分間延長されます。 Foundationのガイド に詳細が記載されています。 もし、NFTのために自分だけにキュレーションされたストアを立ち上げたいと考えているなら、Originの共同設立者でAmazonブロックチェーンリードのKevin Goodspeedが書いた AWS上で自分だけのDshopを立ち上げる方法についてのガイド で確認することができます。多くのクリエイターは、自分のNFTが他のアーティストによる無関係なNFTと同じマーケットプレイスや仮想ギャラリーに表示されることを望まないため、キュレーションを非常に重要視しています。また、無関係なNFTを一緒に表示することは、NFTの価格に悪影響を及ぼす可能性があります。DshopはすでにNFTの出品に対応しているので、Dshopを立ち上げ、自分のプライベートストアとドメインでNFTを出品するだけでよいのです。 まとめ NFTとは何か、そしてこのエキサイティングな新世界に足を踏み入れるための知識について、ご理解いただけたと思います。分散型技術には確かに学習曲線があります。ですから、落胆することなく、非常に新しく実験的な技術を扱っていることを認識してください。皆さんがどのようなNFTを作り上げ、世界と共有するのか、楽しみでなりません。 本稿はソリューションアーキテクト畑が翻訳を担当しました。

Amazon Redshift は、クラウドにおけるフルマネージドでペタバイト規模のデータウェアハウスサービスです。Amazon Redshift を使えば、すべてのデータを分析して、ビジネスと顧客に関する総合的な洞察を導き出すことができます。ストアドプロシージャをサポートしており、準備された SQL コードが保存され、コードを何度も再利用することができます。 ストアドプロシージャは、データ変換、データ検証、ビジネス固有のロジックをカプセル化するために一般的に使用されます。複数の SQL ステップをストアドプロシージャにまとめることで、再利用可能なコードブロックを作成し、単一のトランザクションまたは複数の個別のトランザクションとしてまとめて実行することができます。Amazon Redshift 上のデータ処理を自動化するために、ストアドプロシージャをスケジュールすることもできます。詳細については、 Amazon Redshift にストアドプロシージャを導入する を参照してください。 Redshift ストアドプロシージャのデフォルトのアトミックトランザクションモードでは、Redshift ストアドプロシージャの呼び出しは、呼び出されたときに独自のトランザクションを作成するか、ストアドプロシージャが呼び出される前に明示的なトランザクションが開始されている場合は、既存のトランザクションの一部となります。プロシージャ内のすべてのステートメントは、ストアドプロシージャの呼び出しが終了したときに終了する単一のトランザクションブロック内にあるかのように動作します。他のプロシージャへの入れ子になった呼び出しは、他の SQL 文と同様に扱われ、呼び出し元と同じトランザクションのコンテキスト内で動作します。TRUNCATE、COMMIT、ROLLBACK ステートメントと、任意の SQL 文による例外処理ブロックは、現在のトランザクションを終了し、暗黙的に新しいトランザクションを開始します。この動作は、Teradata のような他のシステムから Amazon Redshift への移行において問題を引き起こす可能性があります。 この投稿では、非アトミックトランザクションモードのための Amazon Redshift ストアドプロシージャの拡張について説明します。このモードは、ストアドプロシージャ内のステートメントを自動的にコミットすることを可能にする、強化されたトランザクション制御を提供します。 非アトミックトランザクションモード 新しい非アトミックトランザクションモード機能は、Amazon Redshift のストアドプロシージャに 3 つの強化された機能を提供します。 DML または DDL ステートメントが明示的にオープンされたトランザクションの一部でない限り、ストアドプロシージャ内の各ステートメントは、それらステートメント自身が暗黙的に開始するトランザクションで実行され、次のステートメントではまた新しいトランザクションが開始されます。明示的にトランザクションが開始された場合、後続のステートメントはすべて実行され、明示的なトランザクション制御コマンド（ COMMIT または ROLLBACK ）がトランザクションを終了するために実行されるまで、コミットされないままになります。 Amazon Redshift は例外処理ステートメントが完了した後、例外を再送出しません。そのため、例外処理ブロックによってキャッチされた例外を再送出するために、INFO や EXCEPTION を持たない新しい RAISE ステートメントが提供されています。INFO や EXCEPTION を持たない、この RAISE ステートメントは、例外処理ブロックでのみ許可されています。 また、新しい START TRANSACTION ステートメントは、非アトミックトランザクションモードのストアドプロシージャ内で明示的なトランザクションを開始します。明示的に開始されたトランザクションを終了するには、既存のトランザクション制御コマンド ( COMMIT または ROLLBACK ) を使用します。 Amazon Redshift はサブトランザクションをサポートしないため、既に開始されたトランザクションが存在する場合、このステートメントを再度呼び出しても何も行われず、エラーは発生しません。 非アトミックトランザクションモードのストアドプロシージャ呼び出しが終了したときに、明示的トランザクションがまだ実行中の場合、セッション内でトランザクション制御コマンドが実行されるまで、明示的トランザクションは実行中のままになります。 トランザクション制御コマンドを実行する前にセッションが切断されると、トランザクション全体が自動的にロールバックされます。 その他の制限 Redshift ストアドプロシージャにはいくつかの制限があります。 ストアドプロシージャの入れ子呼び出しについては、アトミックトランザクションモード（デフォルトのモード）であろうと、新しい非アトミックトランザクションモードであろうと、すべてのプロシージャは同じトランザクションモードで作成されなければなりません。 2 つのトランザクションモード（アトミックと非アトミック）にまたがってストアドプロシージャを入れ子にすることはできません。 非アトミックトランザクションモードのストアドプロシージャに SECURITY DEFINER オプションや SET configuration_parameter オプションを設定することはできません。 カーソルへの影響 非アトミックトランザクションモードのストアドプロシージャのカーソルは、デフォルトのアトミックトランザクションモードと比較して異なる動作をします。 カーソルステートメントは、カーソルループの各イテレーションが自動コミットされないように、カーソルを開始する前に明示的なトランザクションブロックが必要になります。 非アトミックトランザクションモードのストアドプロシージャからカーソルを返すには、カーソルを開始する前に明示的なトランザクションブロックが必要です。そうでなければ、ループ内の SQL ステートメントが自動的にコミットされる時に、カーソルはクローズされます。 利点 ユーザーの視点から見たこの機能の主な利点は、以下の通りです。 Teradata のセッションモードで実行できる Teradata のストアドプロシージャをリフト＆シフトする機能を提供します。これは、Teradata や SQL Server のようなデータウェアハウスからのシームレスな移行に役立ちます。 Amazon Redshift がエラーや例外に遭遇した際に、ストアドプロシージャ内部でより柔軟な操作を提供できるようになります。Amazon Redshift は、例外に到達する前に以前のアクションの状態を保持できるようになりました。 構文 次のコードに示すように、新しいオプションのキーワード NONATOMIC がストアド プロシージャ定義の構文に追加されました。 &lt;code class="lang-sql"&gt;CREATE [ OR REPLACE ] PROCEDURE sp_procedure_name ( [ [ argname ] [ argmode ] argtype [, ...] ] ) [ NONATOMIC ] AS $$ procedure_body $$ LANGUAGE plpgsql&lt;/code&gt; このオプションのキーワードは、ストアドプロシージャを非アトミックトランザクションモー ドで作成します。このキーワードを指定しない場合は、ストアドプロシージャの作成時にデフォルトのアトミックモードがトランザクションモードとなります。 NONATOMIC は、プロシージャ内の各 DML と DDL ステートメントが暗黙的にコミットされることを意味します。 非アトミックモードでない場合、プロシージャは呼び出し開始時に独自のトランザクションを作成するか、呼び出し前に明示的なトランザクションが開始されていれば既存のトランザクションの一部となります。ストアドプロシージャ内の全てのステートメントは、この 1 つのトランザクションに属することになります。 NONATOMIC モードの例 顧客の主連絡先と副連絡先の電話番号を格納する顧客連絡先テーブル custcontacts を考えてみましょう。 CREATE table custcontacts( custid int4 not null, primaryphone char(10), secondaryphone char(10)); 連絡先番号のない 3 つのサンプル顧客レコードを挿入します。 INSERT INTO custcontacts VALUES (101, 'xxxxxxxxxx', 'xxxxxxxxxx'); INSERT INTO custcontacts VALUES (102, 'xxxxxxxxxx', 'xxxxxxxxxx'); INSERT INTO custcontacts VALUES (103, 'xxxxxxxxxx', 'xxxxxxxxxx'); 主と副の電話番号を更新するストアドプロシージャを作成する必要があります。要件は、副連絡先番号への更新が何らかの理由で失敗した場合に、主連絡先番号への更新をロールバックしないことです。 これは、NONATOMIC キーワードを使用してストアドプロシージャを作成することで実現できます。NONATOMIC キーワードは、ストアドプロシージャ内の各ステートメントが独自の暗黙的なトランザクションブロックで実行されるようにします。したがって、副電話番号に対する UPDATE ステートメントが失敗しても、主電話番号に対するデータ更新がロールバックされることはありません。以下のコードを参照してください。 CREATE PROCEDURE sp_update_custcontacts(cid int4,pphone char(15),sphone char(15)) NONATOMIC AS $$ BEGIN UPDATE custcontacts SET primaryphone=pphone WHERE custid=cid; UPDATE custcontacts SET secondaryphone=sphone WHERE custid=cid; END; $$ LANGUAGE plpgsql; それでは、10 桁以上の secondaryphone を渡すストアドプロシージャを呼び出してみましょう。副電話番号の長さが正しくないため UPDATE ステートメントは失敗します。 call sp_update_custcontacts(101,'1234567890','345443345324'); 前述のプロシージャ呼び出しは、主電話番号の更新には成功しますが、副電話番号の更新には失敗します。ただし、 primaryphone の更新は、ストアドプロシージャ定義の NONATOMIC 節により、独自の暗黙のトランザクション ブロックで実行されたため、ロールバックされません。 select * from custcontacts; custcontacts | primaryphone | secondaryphone -------------+---------------+--------------- 101 | 1234567890 | XXXXXXXXXX 102 | XXXXXXXXXX | XXXXXXXXXX 103 | XXXXXXXXXX | XXXXXXXXXX NONATOMICモードでの例外処理 ストアドプロシージャにおける例外の取り扱いは、アトミックモードか非アトミックモードかで異なります。 アトミック (デフォルト) – 例外は常に再送出されます。 非アトミック – 例外は処理され、再送出するかどうかを選択できます。 先ほどの例に続き、非アトミックモードでの例外処理を確認していきましょう。 ストアドプロシージャによって発生した例外を記録するために、以下のテーブルを作成します。 CREATE TABLE procedure_log (log_timestamp timestamp, procedure_name varchar(100), error_message varchar(255)); 次に、例外を処理するために sp_update_custcontacts() プロシージャを更新します。プロシージャ定義に EXCEPTION ブロックを追加していることに注意してください。これは、例外が発生した場合に procedure_log テーブルにレコードを挿入します。 CREATE OR REPLACE PROCEDURE sp_update_custcontacts(cid int4,pphone char(15),sphone char(15)) NONATOMIC AS $$ BEGIN UPDATE custcontacts SET primaryphone=pphone WHERE custid=cid; UPDATE custcontacts SET secondaryphone=sphone WHERE custid=cid; EXCEPTION WHEN OTHERS THEN INSERT INTO procedure_log VALUES (getdate(), 'sp_update_custcontacts', sqlerrm); END; $$ LANGUAGE plpgsql; もう 1 つストアドプロシージャを作成します。このプロシージャは前述のプロシージャを呼び出します。このプロシージャも EXCEPTION ブロックを持ち、例外が発生した場合に procedure_log テーブルにレコードを挿入します。 CREATE PROCEDURE sp_update_customer() NONATOMIC AS $$ BEGIN -- Let us assume you have additional staments here to update other fields. For this example, ommitted them for simplifiction. -- Nested call to update contacts call sp_update_custcontacts(101,'1234567890','345443345324'); EXCEPTION WHEN OTHERS THEN INSERT INTO procedure_log VALUES (getdate(), 'sp_update_customer', sqlerrm); END; $$ LANGUAGE plpgsql; 作成した親プロシージャを呼び出してみましょう。 call sp_update_customer(); これにより、 sp_update_custcontacts() プロシージャが呼び出されます。副電話番号を無効な値で更新しているため、内部で呼び出されているプロシージャ sp_update_custcontacts() は失敗します。コントロールは sp_update_custcontacts() プロシージャの EXCEPTION ブロックに入り、 procedure_log テーブルに挿入します。 しかし、非アトミックモードでは例外を再送出しません。したがって、親プロシージャ sp_update_customer() は、 sp_update_custcontacts() プロシージャから渡された例外を取得しません。コントロールは sp_update_customer() プロシージャの EXCEPTION ブロックに入りません。 procedure_log テーブルをクエリすると、 sp_update_custcontacts() プロシージャで処理されたエラーのエントリのみが表示されます。 select * from procedure_log; 次に、RAISE ステートメントを使用して sp_update_custcontacts() プロシージャを再定義します。 CREATE PROCEDURE sp_update_custcontacts(cid int4,pphone char(15),sphone char(15)) NONATOMIC AS $$ BEGIN UPDATE custcontacts SET primaryphone=pphone WHERE custid=cid; UPDATE custcontacts SET secondaryphone=sphone WHERE custid=cid; EXCEPTION WHEN OTHERS THEN INSERT INTO procedure_log VALUES (getdate(), 'sp_update_custcontacts', sqlerrm); RAISE; END; $$ LANGUAGE plpgsql; 親ストアドプロシージャ sp_update_customer() をもう一度呼び出してみましょう。 call sp_update_customer(); ここで、内部で呼び出されているプロシージャ sp_update_custcontacts() は、自身の EXCEPTION ブロックで例外を処理した後、親プロシージャ sp_update_customer() に例外を再送出します。その後、コントロールは親プロシージャの EXCEPTION ブロックに到達し、 procedure_log テーブルに別のレコードを挿入します。 procedre_log テーブルにクエリを実行すると、2 つのエントリーが表示されます。1 つは内部で呼び出されているプロシージャ sp_update_custcontacts() によるもので、もう 1 つは親プロシージャ sp_update_customer() によるものです。これは、内部で呼び出されているプロシージャの RAISE ステートメントが例外を再送出したことを示しています。 select * from procedure_log; 非アトミック・モードでの明示的なSTART TRANSACTION文 START TRANSACTION ステートメントを発行して、ストアドプロシージャ内でトランザクションブロックを開始することができます。これは、ストアドプロシージャ内で新しいトランザクションを開始します。参考例については、 非アトミックモードのストアドプロシージャのトランザクション管理 を参照してください。 まとめ この投稿では、Redshift ストアドプロシージャの非アトミックトランザクションモードの機能強化について説明しました。これは、ストアドプロシージャ内のステートメントを自動的にコミットできるようにトランザクション制御を拡張したものです。このモードは、Teradata のような他のシステムから Amazon Redshift への移行も容易にします。 原文は こちら です。

オブザーバビリティ（可観測性）とは、システムで何が起こっているかをどれだけ把握できるかを表します。多くの場合、メトリクス、ログ、トレースを収集するために計装することで実現します。運用体験の向上や、業務目標の達成を実現するには、システムがどのように動作しているかを理解する必要があります。これを実現するために、多くのお客様がリアルタイムのモニタリング、アラートとアラーム、カスタマイズ可能なダッシュボードの利用や、ビジネスの意思決定を支援を目的としたメトリクスの可視化を行うために、 Amazon CloudWatch を利用しています。組織では、カスタムパラメータを使用して任意の AWS Lambda 関数を呼び出すことができる CloudWatch ダッシュボードウィジェットを利用することが可能です。これにより、ダッシュボード上でデータを分析、および表示できる可能性が大きく広がります。しかし、組織内にこれらの関数を作成する専門知識がない場合はどうすれば良いでしょうか。ここで、 Amazon CodeWhisperer がこれらの関数の作成を支援するコード提案を行うことで、オブザーバビリティの向上に役立ちます。 Amazon CloudWatch ダッシュボード を使用すると、 AWS 環境全体のさまざまなメトリクスとリソースを一元的にモニタリングすることができるようになります。これにより、システムや組織全体でのアプリケーションの健全性とパフォーマンスを把握することができます。カスタムウィジェットにより、これらのダッシュボードの柔軟性が大幅に向上し、高度なレベルの監視と可視化が可能になります。 Amazon CodeWhisperer は、統合開発環境 (IDE) でリアルタイムに 1 行または関数コード全体の提案を生成することができる AI サービスです。これにより、ソフトウェアの構築を迅速に行うことができます。 この投稿では、 CodeWhisperer を利用して、 カスタムウィジェット 、 CloudWatch ダッシュボードの開発およびデプロイに使用されるコードの作成を支援する方法を示します。 またこの投稿では AWS Cloud Development Kit (CDK) を使用します。CDK は、近代的なプログラミング言語を使用してインフラストラクチャをコードとして定義し、 AWS CloudFormation を通じてデプロイするためのオープンソースのソフトウェア開発フレームワークです。 ソリューション全体像 このソリューションでは、 Amazon CodeWhisperer を使用して、 CDK コードの記述に関するコード提案を行います。 AWS CDK を使用して、さまざまなタイプの 3 つのウィジェットを持つダッシュボードをコーディングおよびデプロイします。 例では、テキストウィジェットと 2 つのカスタムウィジェットの作成方法を示します。 以下の図は、 CDK を介して作成されるリソースの概要を示しています。 図1. CDK によって作成される Amazon CloudWatch ダッシュボードアーキテクチャ この投稿のすべての手順に沿って操作を行うと、CloudWatch ダッシュボードは次のようになります。2 つのカスタムウィジェットと 1 つのテキストウィジェットが含まれます。 図2. CloudWatch テキストウィジェット この投稿全体を通して行うことは以下のとおりです。 Amazon CodeWhisperer の設定 ビルダー ID を使用するように IDE を設定 AWS CLI 、 AWS CDK 、 AWS IAM の設定 Amazon CodeWhisperer を使用して CDK コードと Lambda 関数の作成 デプロイのためのアセットを保持する Amazon Simple Storage Service(S3) バケットの作成 ダッシュボードとカスタムウィジェットのデプロイ 前提条件 この投稿に沿って作業を進める場合、ローカルマシン上の統合開発環境 (IDE) で作業を行なっていきます。 CodeWhisperer は、 Visual Studio Code (VS Code) 、 PyCharm などの JetBrains 製品など、複数の IDE で動作します。この記事では VS Code を使用します。他の IDE の使用手順は、 Amazon CodeWhisperer のドキュメント で確認できます。 また、以下についても必要になります。 AWS アカウント Visual Studio Code Python と pip AWS CLI AWS CDK ビルダー ID を使用するように IDE を設定 AWS Builder ID を使用して、 VS Code で CodeWhisperer を設定しましょう。AWS Builder ID は、 AWS 上で開発するすべてのユーザーのための新しい個人プロファイルです。 まず最初に、AWS Toolkit がインストールされていることを確認する必要があります。 VS Code IDE の左側のパネルで [Extensions] に移動します。検索バーに「AWS Toolkit」と入力し、以下のように拡張機能をインストールしてください。 図3. VS CodeでのAWS拡張機能の設定 これで、左側のパネルに AWS Toolkit アイコンが表示されるはずです。 Visual Studio Code の AWS Toolkit で、[Developer tools] の [CodeWhisperer] を選択し、 [Start] をクリックします。すると、 VS Code の上部にドロップダウンメニューが表示されます。 図4. CodeWhispererの開始 ドロップダウンメニューから、 [Use a personal email to sign up and sign in with AWS Builder ID] を選択します。 図5. 個人メールアドレスの設定 [Copy Code for AWS Builder ID] のプロンプトが表示されたら、 [Copy Code] と [Proceed] を選択します。 [Do you want Code to open the external website?] のプロンプトが表示されたら、 [Open] を選択します。 ブラウザタブが開き、 [Authorize request] ウィンドウが表示されます。コードはすでにクリップボードにコピーされているはずです。それを貼り付けて、 [Next] を選択します。 [Create AWS Builder ID] ページがブラウザタブで開きます。メールアドレスを入力し、 [Next] を選択します。 [Your name] のフィールドが表示されるので、名前を入力し、 [Next] を選択します。 入力したメールアドレスに確認コードが届きます。確認画面で届いたコードを入力し、 [Verify] を選択します。 [Choose your password] 画面で、パスワードを入力し、確認入力してから、 [Create AWS Builder ID] を選択します。 ブラウザタブが開き、 Visual Studio Code の AWS Toolkit にデータにアクセスすることを許可するよう求めるメッセージが表示されます。 [Allow] を選択します。 VS Code に戻ります。すでに IAM を使用して他の AWS ツールに認証している場合は、すべての AWS サービスで Builder ID を使用するかどうかを尋ねられます。状況に適したオプションを選択します。 AWS CLI 、 AWS CDK 、 AWS IAM の設定 このセクションでは、AWS CLI、CDK、CDKのフォルダ構造を設定します。 AWS CLIを設定するには、「 AWS CLI を設定する 」の手順に従ってください。 新しいフォルダを作成し、 sample1 と名前を付けます。このフォルダで CDK プロジェクトを作成します。 sample1 フォルダにディレクトリを変更します。 cd sample1 cdk をブートストラップします。 cdk bootstrap aws://&lt; アカウント番号 &gt;/&lt; リージョン名 &gt; cdk python 環境を作成します。 cdk init --language python これにより、sample1 フォルダに必要な python cdk ファイルが作成されます。 venv をアクティベートします。 source .venv/bin/activate 必要なパッケージをインストールします。 pip install -r requirements.txt Amazon CodeWhisperer を使用したコードの作成 このセクションでは、 CodeWhisperer を使用して CDK コードを記述する方法を説明します。 CDK を使用して、次の 6 つのリソースを作成する方法を説明していきます。 2 つの Lambda 関数 1 つの Lambda 関数は、ユーザー入力を受け取り、対応する出力を生成します。 もう 1 つのLambda関数は、 S3 バケットから HTML を取得します。 3 つの CloudWatch ウィジェット 1 つ目の Lambda 関数と統合するカスタムウィジェット。ユーザー入力を受け付け、 Lambda 関数からデータを読み取って出力を提供します。 2 つ目の Lambda 関数と統合するカスタムウィジェット。 S3 バケットから HTML ファイルを読み取ります。 「Hello World」と表示するテキストウィジェット 1 つの CloudWatch ダッシュボード Visual Studio Codeの利用 左上の [File] メニューから、 [Open Folder] を選択します。（ステップ 2 で作成した sample1 フォルダを選択します。） assets という名前の新しいフォルダを作成し、 HelloWorld.html という名前の html ファイルを作成します。 &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;body&gt; &lt;h1&gt;Hello!! This is an HTML file from S3 bucket&lt;/h1&gt; &lt;/body&gt; &lt;/html&gt; このファイルは S3 バケットにアップロードされ、 Lambda 関数によって読み込まれます。 再び sample1 フォルダに移動し、 sample1 という名前のサブフォルダを探します。 そのサブフォルダにあるスタックファイルを編集します。 ・import 文を追加します（入力時に CodeWhisperer が自動補完を支援します） from aws_cdk import ( aws_lambda, Stack, App, Duration, aws_iam, aws_cloudwatch, aws_s3, RemovalPolicy, aws_s3_deployment ) 必要なモジュールをインポートしたら、次の行を探します。 # The code that defines your stack goes here この行を削除し、スタックコードを記述します。 CodeWhisperer にコメントを入力して、 AWS CDK を使用した最初の Lambda 関数の作成を提案させます。 # define lambda function that has inline code 入力を開始すると、 CodeWhisperer が提案を開始します。 Lambda 関数の作成に関するヘルプが表示されたら、 Lambda 関数の CDK コードを次のように記述します。 # define lambda function that has inline code lambda_function = aws_lambda.Function(self, 'HelloWorldFunction', code=aws_lambda.Code.from_inline(""" def lambda_handler(event, context): showme = event['widgetContext']['forms']['all'].get('petType') # create a 2D array for pets and count data = [['puppy','10'],['bunny','5'],['kitten','6']] rowdata = "" for row in data: if (showme and showme==row[0]): # assume only 2 elements in the data rowdata += f''' &lt;tr&gt; &lt;td&gt;{row[0]}&lt;/td&gt; &lt;td&gt;{row[1]}&lt;/td&gt; &lt;/tr&gt;''' response = f''' &lt;p&gt;Which pet do you want to see? valid inputs: puppy/bunny/kitten &lt;form&gt;&lt;input name="petType" value="{showme}" size="10"&gt;&lt;/form&gt; &lt;/p&gt; &lt;table&gt; &lt;tr&gt; &lt;th&gt;Pets&lt;/th&gt; &lt;th&gt;Count&lt;/th&gt; &lt;/tr&gt; {rowdata} &lt;/table&gt; &lt;a class="btn btn-primary"&gt;Run query&lt;/a&gt; &lt;cwdb-action action="call" endpoint="{context.invoked_function_arn}"&gt;&lt;/cwdb-action&gt; ''' return response """ ), description="CloudWatch Custom Widget sample: simple hello world", function_name=self.stack_name, handler='index.lambda_handler', memory_size=128, runtime=aws_lambda.Runtime.PYTHON_3_9, timeout=Duration.seconds(60)' ) コードをカスタマイズするために入力を追加すると、 CodeWhisperer が提案を行うことに気づくでしょう。この例では、ペットの数の 2 次元配列を作成し、ユーザーに取得するデータを入力するよう求めています。ユースケースに基づいてデータを変更できます。 最初の CloudWatch カスタムウィジェットを作成するためのコメントの入力を開始します。このウィジェットでは、入力を要求し、出力として子犬の数を提供するコードを使用します。 # define custom widget to display lambda function CodeWhisperer の提案を使用して、カスタムウィジェットを作成する CDK コードを記述します。 # define custom widget to display lambda function my_custom_widget = aws_cloudwatch.CustomWidget( function_arn=lambda_function.function_arn, title="Hello, World!") CloudWatch のテキストウィジェットを作成するためのコメントの入力を開始します。 # define a text widget that displays "Hello World" CodeWhisperer の提案を利用しながら、テキストウィジェットのコードを完成させます。 # define a text widget that displays "Hello World" my_text_widget = aws_cloudwatch.TextWidget(markdown='# Hello World', width=6, height=2 ) assets フォルダのファイルをロードする S3 バケットを作成しましょう。 # define parameter for s3 bucket name s3_bucket_name = f'helloworld-{self.account}' s3_file_name = 'HelloWorld.html' # define s3 bucket with account id as suffix for hello world with no public access s3_bucket = aws_s3.Bucket(self, "S3Bucket", versioned=False, block_public_access=aws_s3.BlockPublicAccess.BLOCK_ALL, encryption=aws_s3.BucketEncryption.KMS_MANAGED, auto_delete_objects=True, removal_policy=RemovalPolicy.DESTROY, bucket_name=s3_bucket_name ) # define s3 bucket deployment to deploy files under assets folder aws_s3_deployment.BucketDeployment(self, "S3BucketDeployment", sources=[aws_s3_deployment.Source.asset("assets")], destination_bucket=s3_bucket ) S3 バケットからファイルを読み取る第 2 の Lambda 関数を作成しましょう。関連する IAM ロールも作成します。 # define IAM role for lambda that allows to read s3_file_name from s3 bucket with name s3_bucket_name s3GetObjectLambda_IAM_role = aws_iam.Role(self, "S3GetObjectLambda_IAM_role", assumed_by=aws_iam.ServicePrincipal("lambda.amazonaws.com"), inline_policies={ "S3GetObjectLambda_IAM_role_policy": aws_iam.PolicyDocument( statements=[ aws_iam.PolicyStatement( actions=["s3:GetObject"], effect=aws_iam.Effect.ALLOW, resources=[ f'arn:aws:s3:::{s3_bucket_name}/{s3_file_name}' ] ) ] ) } ) 2 つ目のカスタムウィジェットを作成しましょう。 # define s3GetObject custom widget to display s3GetObjectlambda_function s3GetObject_custom_widget = aws_cloudwatch.CustomWidget( function_arn=s3GetObjectlambda_function.function_arn, width=6, height=4) 次に、作成した 3 つのウィジェットをホストする CloudWatch ダッシュボードを作成します。コメントで CodeWhisperer に提案させることで、ダッシュボードのコードを作成します。 # define cloudwatch dashboard CodeWhisperer のコード提案が表示されたら、以前に作成したウィジェットを使用するダッシュボードのコードを完成させます。 # define CloudWatch dashboard dashboard = aws_cloudwatch.Dashboard( self, 'HelloWorldDashboard', dashboard_name='HelloWorldDashboard' ) 最後に、作成した 2 つのカスタムウィジェットと 1 つのテキストウィジェットをダッシュボードに追加します。 # add the 3 widgets to the dashboard dashboard.add_widgets(my_custom_widget) dashboard.add_widgets(my_text_widget) dashboard.add_widgets(s3GetObject_custom_widget) コードは次の例のようになるはずです。 from aws_cdk import ( Stack, Duration, aws_lambda, aws_cloudwatch, aws_s3, RemovalPolicy, aws_iam, aws_s3_deployment ) from constructs import Construct import os class Sample1Stack(Stack): def __init__(self, scope: Construct, construct_id: str, **kwargs) -&gt; None: super().__init__(scope, construct_id, **kwargs) cwd = os.getcwd() # define lambda function that has inline code lambda_function = aws_lambda.Function(self, 'HelloWorldFunction', code=aws_lambda.Code.from_inline( """ def lambda_handler(event, context): showme = event['widgetContext']['forms']['all'].get('petType') # create a 2D array for pets and count data = [['puppy','10'],['bunny','5'],['kitten','6']] rowdata = "" for row in data: if (showme and showme==row[0]): # assume only 2 elements in the data rowdata += f''' &lt;tr&gt; &lt;td&gt;{row[0]}&lt;/td&gt; &lt;td&gt;{row[1]}&lt;/td&gt; &lt;/tr&gt;''' response = f''' &lt;p&gt;Which pet do you want to see? valid inputs: puppy/bunny/kitten &lt;form&gt;&lt;input name="petType" value="{showme}" size="10"&gt;&lt;/form&gt; &lt;/p&gt; &lt;table&gt; &lt;tr&gt; &lt;th&gt;Pets&lt;/th&gt; &lt;th&gt;Count&lt;/th&gt; &lt;/tr&gt; {rowdata} &lt;/table&gt; &lt;a class="btn btn-primary"&gt;Run query&lt;/a&gt; &lt;cwdb-action action="call" endpoint="{context.invoked_function_arn}"&gt;&lt;/cwdb-action&gt; ''' return response """ ), # code=aws_lambda.Code.from_asset(os.path.join(cwd, "lambdafolder/package.zip")) description="CloudWatch Custom Widget sample: simple hello world", function_name=self.stack_name, handler='index.lambda_handler', memory_size=128, runtime=aws_lambda.Runtime.PYTHON_3_9, timeout=Duration.seconds(60) ) # define a CustomWidget that uses the Lambda function my_custom_widget = aws_cloudwatch.CustomWidget( function_arn=lambda_function.function_arn, title="Hello, World!") # define a text widget that displays "Hello World" my_text_widget = aws_cloudwatch.TextWidget(markdown='Hello World', width=6, height=2 ) # define parameter for s3 bucket name s3_bucket_name = f'helloworld-{self.account}' s3_file_name = 'HelloWorld.html' # define s3 bucket with account id as suffix for hello world with no public access s3_bucket = aws_s3.Bucket(self, "S3Bucket", versioned=False, block_public_access=aws_s3.BlockPublicAccess.BLOCK_ALL, encryption=aws_s3.BucketEncryption.KMS_MANAGED, auto_delete_objects=True, removal_policy=RemovalPolicy.DESTROY, bucket_name=s3_bucket_name ) # define s3 bucket deployment to deploy files under assets folder aws_s3_deployment.BucketDeployment(self, "S3BucketDeployment", sources=[aws_s3_deployment.Source.asset("assets")], destination_bucket=s3_bucket ) # define IAM role for lambda that allows to read s3_file_name from s3 bucket with name s3_bucket_name s3GetObjectLambda_IAM_role = aws_iam.Role(self, "S3GetObjectLambda_IAM_role", assumed_by=aws_iam.ServicePrincipal("lambda.amazonaws.com"), inline_policies={ "S3GetObjectLambda_IAM_role_policy": aws_iam.PolicyDocument( statements=[ aws_iam.PolicyStatement( actions=["s3:GetObject"], effect=aws_iam.Effect.ALLOW, resources=[ f'arn:aws:s3:::{s3_bucket_name}/{s3_file_name}' ] ) ] ) } ) # define lambda function S3GetObject s3GetObjectlambda_function = aws_lambda.Function(self, "S3GetObjectLambdaFunction", #inline code to read file from s3 bucket code=aws_lambda.Code.from_inline(""" import boto3 import json import os s3 = boto3.client('s3') def lambda_handler(event, context): #read environment variable S3_BUCKET_NAME bucket = os.environ['S3_BUCKET_NAME'] key = os.environ['S3_FILE_NAME'] response = s3.get_object(Bucket=bucket, Key=key) file_content = response['Body'].read().decode('utf-8') return file_content """ ), runtime=aws_lambda.Runtime.PYTHON_3_9, handler="index.lambda_handler", timeout=Duration.seconds(60), memory_size=128, description="Lambda function that reads file from S3 bucket and returns file content", # define IAM role for S3GetObject role=s3GetObjectLambda_IAM_role, #environment variables environment={ 'S3_BUCKET_NAME': s3_bucket_name, 'S3_FILE_NAME': s3_file_name }, # define function name as s3GetObject function_name=f's3GetObject-{self.stack_name}' ) # define s3GetObject custom widget to display s3GetObjectlambda_function s3GetObject_custom_widget = aws_cloudwatch.CustomWidget( function_arn=s3GetObjectlambda_function.function_arn, width=6, height=4, title="S3 Get Object" ) # define a CloudWatch dashboard dashboard = aws_cloudwatch.Dashboard( self, 'HelloWorldDashboard', dashboard_name='HelloWorldDashboard' ) # add the 3 widgets to the dashboard dashboard.add_widgets(my_custom_widget) dashboard.add_widgets(my_text_widget) dashboard.add_widgets(s3GetObject_custom_widget) コードを検証します。 Visual Studio Code のターミナルウィンドウで次のコマンドを実行します。 cdk ls コードをデプロイします。 Visual Studio Code のターミナルウィンドウで次のコマンドを実行します。 cdk deploy これで次のリソースがデプロイされているはずです。 2 つの Lambda 関数 3 つのウィジェットを持つ CloudWatch ダッシュボード 1 つのテキストウィジェット Lambda に接続された 2 つの CustomWidget S3 の HTML ファイルから読み取れる 1 つのカスタムウィジェット ユーザー入力を要求し、 Lambda から関連値を取得する 1 つのカスタムウィジェット 他のウィジェットの作成方法は こちら を参考にしてください。 環境の削除 今後課金されないようにするには、Visual Studio Code のターミナルウィンドウで次のコマンドを実行してリソースを削除します。 cdk destroy まとめ この投稿では、 Amazon CodeWhisperer を使用して CloudWatch ダッシュボードを作成する CDK コードを記述する方法を学びました。ご覧のとおり、 CodeWhisperer は開発者の生産性を向上させるだけでなく、より速く成果を出し、ソフトウェア開発を加速し、開発労力を削減する提案を行い、アイデア創出や複雑な問題解決のための時間を確保できるなど、多くのメリットがあります。詳細は CodeWhisperer のドキュメント をご覧ください。 本記事は、「 Leverage generative AI to create custom dashboard widgets in Amazon CloudWatch using Amazon CodeWhisperer 」を翻訳したものです。翻訳は ソリューションアーキテクト津郷が担当しました。