(出展: 株式会社MIXI) MIXI は、認証から決済までをワンストップで提供する、基盤システム & WALLET サービスである MIXI M を消費者向けに展開しています。このたび、お客様は MIXI M に 3D セキュアを実装しました。3D セキュアは、追加の認証によってユーザーの購買意思を確認する仕組みで、より安心・安全なオンライン決済体験を実現します。 以下はユーザーから見た 3D セキュアを含む決済体験のイメージです。 3D セキュアの提供にあたってはセキュリティ基準 PCI 3DS への準拠が不可欠です。お客様は、PCI 3DS が求める厳密な鍵管理を、AWS Key Management Service (AWS KMS) を用いて実装し、同基準に準拠しました。 PCI 3DS では、一部の鍵管理に FIPS140-2 Level3 以上もしくは PCI PTS 認定の HSM の利用を規定しています。このため、以前は AWS KMS は利用できませんでしたが、 2023 年 5 月に AWS KMS 内部の HSM が FIPS140-2 Level3 にアップグレード したことにより、要件を満たすようになりました。お客様の検討段階では AWS KMS を用いた PCI 3DS 準拠の先行事例はありませんでしたが、AWS からの支援を通じて、AWS KMS を利用するメリット、PCI 3DS QSA (認定審査人) との会話のポイントがクリアになったことから、 AWS KMS を第一選択肢として設計が進みました。 コンプライアンス対応の削減 AWS におけるコンプライアンス対応は、責任共有モデルに基づいて利用者と AWS が分担します。マネージド型サービスなど抽象度の高いサービスを使えば使うほど、利用者の責任範囲が減少し、コンプライアンス対応のより多くを AWS にオフロードできます。当初予定していた AWS CloudHSM を利用する場合に比べて、AWS KMS の利用によりコンプライアンス対応が削減されることは明らかでした。PCI 3DS では準拠後にコンプライアンス維持のための運用が必要となるため、これを削減できることはメリットでした。 運用の削減 AWS CloudHSM では、HSM のバックアップやクラスターの管理の一部を利用者自身で行う必要があります。一方、AWS KMS はマネージド型サービスのため、全て AWS に任せることができます。お客様は少人数でも運用が可能なマネージド型サービスを積極的に採用しているため、AWS CloudHSM よりマネージドな AWS KMS が利用できることに大きなメリットがありました。 AWS SDK の活用 AWS CloudHSM では、鍵へのアクセスに PKCS #11 や OpenSSL Dynamic Engine といった HSM 標準の SDK の利用が必要でした。一方、AWS KMS が管理する鍵へのアクセスはお客様が慣れ親しんだ AWS SDK を利用することができるため、開発やテストが容易である点がメリットでした。 アクセス保護 PCI 3DS では鍵への物理的、論理的アクセスからの保護要件が存在します。物理的アクセスは両サービスともに AWS の責任範囲である一方、論理的アクセスからの保護は利用者の対応も必要です。AWS CloudHSM では HSM の仕様に沿った保護が必要な一方で、 AWS KMS ではキーポリシーの利用によりこれまで活用してきた AWS Identity and Access Management (AWS IAM) の仕組みで実現できることにメリットがありました。 ランニングコスト AWS CloudHSM は時間課金制で HSM の料金が発生するため、最小構成(2台)でも月額 $3,400 程度となり、スケールアウトする際には1台ずつ追加が必要です。一方、AWS KMS はリクエスト単位で費用が発生するため、リクエスト数に応じて無駄なくコストを支払うことができます。そのため、想定していた費用を大きく削減することができました。 アーキテクチャ MIXI M における 3D セキュアの実装に関わるアーキテクチャの一部を紹介します。 お客様は以前より MIXI M で Amazon API Gateway などマネージド型サービスを積極的に活用しており、また PCI DSS に準拠しています。 AWS KMS で管理する鍵を使用する操作は REST API を介して実行します。 AWS KMS で定義されたリクエストクォータの範囲内であればアクセスの増減に対して追加の作業は発生しません。VPC Endpoint を活用することでプライベートな経路で API を呼び出します。AWS KMS で管理する鍵に対する変更や鍵の使用は AWS CloudTrail に記録され確認が可能です。AWS KMS への論理アクセスはキーポリシーで管理しており、鍵へのアクセスが可能な IAM ユーザーや IAM ロールを鍵側から限定することができます。 お客様からの声 田岡 文利様 (株式会社 MIXI 開発本部 MIXI M 事業部) PCI 3DS 準拠は弊社にとって前例がなく、非常にチャレンジングな課題でした。弊社担当の AWS アカウントチームに問い合わせたところ、ニーズを瞬時に理解いただき、迅速にセキュリティスペシャリストとのミーティングを設定していただけました。ミーティングでは数々の有益な情報をご提供いただき、結果として安全性と信頼性を担保しながら迅速に PCI 3DS 準拠への対応を行うことができました。 浅見 公輔様 (株式会社 MIXI 開発本部 MIXI M 事業部) MIXI M では小規模チームでフルスタックに開発と運用を行っており、運用と開発のコスト削減は常に最優先事項です。AWS KMS を利用することで PCI 3DS で必要となる運用コストを大幅に削減でき、3D セキュアのシステム開発に集中できました。私達は AWS のフルマネージド型サービスをフルに活用していますが、フルマネージド型サービスの活用による開発・運用コストの削減は大きなベネフィットがあると改めて確認しました。 まとめ お客様は AWS KMS を利用することで運用コストを低く抑えつつ 3D セキュアの実装と PCI 3DS 準拠を達成しました。今後も マネージド型サービスのメリットを活かしてアーキテクチャを最適化し、サービス向上につながる様々な機能の実装を進めていきたいとのことです。 著者 秋山 周平（ゲームソリューションアーキテクト） 中島 智広（シニアセキュリティソリューションアーキテクト）

こんにちは！ソリューションアーキテクトの伊原です。 この度 AWS Hands-on for Beginners シリーズの新作コンテンツとして、 Amazon FSx for Windows File Server 入門ハンズオン を公開しました。 「社内のファイルサーバー管理が複雑で、データのバックアップや共有に手間がかかっている」などのお悩みはありませんか？ AWS にはこのような場合にご利用いただける、 Amazon FSx というサービスがあり、その中でも今回はお客様からの要望の多い Amazon FSx for Windows File Server を取り上げたいと思います。これを利用すると、Windows ベースの共有ファイルシステムを簡単に構築・管理することができます。このハンズオンでは、AWS の公式ドキュメントと動画を用いて実際に共有ファイルシステムを構築し、操作を体験する手順を含めてご紹介します。 こちらのブログでは、今回公開したハンズオンと、ハンズオン実施後の Next Step として、 AWS Site-to-Site VPN の例をご紹介いたします。 Amazon FSx for Windows File Server を使ったファイルサーバの構築 ハンズオン申込ページ AWS Hands-on for Beginners シリーズ一覧 AWS Hands-on for Beginners とは？ AWS Hands-on for Beginners は、動画にそって実際に手を動かしながら AWS サービスについて学んでいただく無償のコンテンツです。 名前の通り、初めて AWS サービスをご利用される方向けの内容ですので、学習の最初のステップとしてご活用いただけます。 オンデマンド形式での配信となるので、移動時間などのスキマ時間での学習もできますし、分かりにくい部分を巻き戻して何度でもご覧いただくことができます。 Amazon FSx for Windows File Server 入門ハンズオンを公開しました！ Amazon FSx for Windows File Server 入門ハンズオンとして、Amazon FSx for Windows File Server を使ったファイルサーバの構築を公開しました。こちらのハンズオンは、以下のような方に特におすすめとなっております。 オンプレミスにあるファイルサーバーのクラウド移行に関心のある方 部門間や拠点間のファイル共有が出来ずにお困りの方 IT管理部門でのファイル共有やバックアップの効率化に関心のある方 Amazon FSx for Windows File Server を利用すると、共有ファイルシステムの構築と管理が容易になります。 このハンズオンでは、FSx for Windows File Server のセットアップから共有フォルダの作成、ファイルサーバーのマウント設定など、マネジメントコンソール上やリモートデスクトップクライアントでの操作を解説しています。 今回のシリーズでは、 ファイルを Amazon FSx for Windows File Server に保存し、社内での共有とバックアップを実現する 適切な認証を行うために、 AWS Directory Service の AWS Managed Microsoft AD と連携する クライアント PC に見立てた Amazon EC2 サーバーに Amazon FSx for Windows File Server をマウントする といったユースケースを想定しています。 Amazon FSx for Windows File Server のデプロイや、構築した共有ファイルシステムの利用方法もあわせてご紹介します。 概要 ハンズオンの概要について、少しだけ紹介したいと思います。 今回限られた時間の中で構築を進めるにあたり、皆さんが普段お使いになるクライアント PC を EC2 で構築した Windows Server で再現しています。また Amazon FSx for Windows File Server の認証に必要な Active Directoryも AWS Managed Microsoft AD で AWS 上に構築します。オンプレミスとの複雑なネットワーク設計を排除し、AWS に閉じた環境で構築を行うことで、 FSx 入門編としてお客様に構築ステップを理解していただこうという狙いです。 もちろん、このハンズオンが終わった後には、様々な課題が見えてくるはずです。 既存のファイルデータ移行方法はどのように行うのか？ 社内ネットワークへの経路はどのように設計、構築していくのか？ 既存 AD との連携方法は出来るのか？ 実際のパフォーマンスが業務に耐えうるものなのか？ Next Step その中でも今回は社内ネットワークへの経路はどのように設計、構築していくのか？というステップについてについてフォローしていきたいと思います。 今回のハンズオンでは AWS 閉じた環境で構築を行いましたが、実際に利用する際にはオンプレミスと AWS を繋ぐネットワークの構築が不可欠になります。 Amazon FSx for Windows File Server では AWS Site-to-Site VPN もしくは AWS Direct Connect を利用することでオンプレミスと Amazon VPC 間の接続を行います。 AWS Direct Connect では、専用のネットワーク接続を経由して、オンプレミス環境からファイルシステムにアクセスできます。また、 AWS Site-to-Site VPN ではセキュアでプライベートなトンネルを経由して、オンプレミスのデバイスからファイルシステムにアクセスできます。 AWS Site-to-Site VPN は本ハンズオンと同様にハンズオンコンテンツとして公開されているので、合わせて VPC ピアリング / AWS Site-to-Site VPN ハンズオン も対応していただくことでより実構築に近い体験を得ていただくことが出来ます。是非次のステップとして実施してみて頂きたいです。 AWS Hands-on for Beginners VPC ピアリング / AWS Site-to-Site VPN ハンズオン申込ページ まとめ このブログでは AWS Hands-on for Beginners シリーズの新コンテンツである、Amazon FSx for Windows File Server を使ったファイルサーバ構築についてご紹介しました。現行のファイルサーバー管理、運用が大変といったお悩みをお持ちの方には特におすすめのコンテンツとなっております。このコンテンツが、皆様の課題の解消やビジネスへの活用に貢献できれば幸いと考えています。ご実施いただいた際は、ぜひアンケートからフィードバックをいただければと思います。それではハンズオンをお楽しみください！ Amazon FSx for Windows File Server を使ったファイルサーバの構築 ハンズオン申込ページ AWS Hands-on for Beginners シリーズ一覧 伊原 健太 (Kenta Ihara) 業界業種問わず、お客様の技術課題の解決に向けた支援を行うソリューションアーキテクトです。 趣味は最近飼い始めた犬のお世話です。

国際航空運送協会（IATA）が定義する ONE Order は、航空会社の予約、配送、会計システムの簡素化を目的とした業界主導のイニシアチブです。現行の予約、旅客名記録（PNR）、発券記録、エチケット、電子雑書類（EMD）を段階的に廃止していきます。この仕組みの一環として、IATA は ONE Order システムのメッセージング標準、プロセス、および実装ガイドラインを文書化しました。 この仕組みは、次世代航空小売業に向けた大きな一歩であり、小売業を非常に忠実に模倣しています。これにより、航空会社は複雑なプロセスから解放され、収益決済を含む小売エコシステムにおけるデータの保存、共有、パートナーとのやり取りが簡素化されます。 私は現在の職務において、航空会社、空港、ホテルの顧客と幅広く話をする機会がありました。これらの会話の中で、航空会社は ONE Order に準拠したオーダー管理システムを構築または購入し、既存のエコシステムと統合することを検討していると話してくれました。このブログでは、Amazon Web Services（AWS）上で ONE Order システムをクラウドネイティブに構築し、そのシステムを航空会社の IT やパートナーのエコシステムと統合するためのアイデアを共有したいと思います。 ONE Order による標準化とモデル化 ONE Order の仕組みは、フルフィルメントパートナーやマーケティング パートナーの違いに関係なく、注文の作成、管理、追跡のプロセスをシンプルにします。 これにより、当事者間の支払い決済処理が大幅に高速化され、エコシステム全体で注文の変更をニアリアルタイムで確認できるようになり、業務効率と顧客エクスペリエンスが向上します。 この仕組みの一環として、IATA は以下のものを定義しました： XML 標準による注文データ構造のモデル。このデータ構造には顧客注文のすべての詳細が含まれ、小売業界の典型的な注文に酷似しています。 これは、現在ほとんどの航空会社システムに存在する PNR、EMD、ETK データ構造に代わるものです。 ビジネスイベント。注文のライフサイクル、および注文のライフサイクルイベントを他の対象システムにプッシュするイベントになります。 これには、社内の IT システム（収益管理システムやフルフィルメントシステム）であったり、またはコードシェア・パートナーや、ホテル、陸上製品、小売店などの航空以外の製品・サービス提供者などの外部パートナーも含まれます。 実装ガイダンス。 これは、新しい一連のプロセスについて、注文エコシステム内での連携についてのガイダンスになります。 AWSネイティブでのONE Orderシステム構築 次の図は、AWS 上でネイティブに ONE Order システムを構築するための潜在的なアーキテクチャを示しています。 上記の設計は、チャネル、注文ストア、その他の IT システム、エコシステム内のパートナー間のシームレスな情報交換を容易にするイベント駆動型アーキテクチャの構築に重点を置いています。注文の主要業績評価指標（KPI）をニアリアルタイムで監視し、さらなる洞察を得るために企業データレイクに情報を公開しています。ONE Order システムと従来の PNR ベースの旅客サービス・システム（PSS）との共存にも取り組んでいます。 コアとなる注文データストアは、 Amazon DynamoDB を使用して構築されています。Amazon DynamoDB は、高速で柔軟性の高い NoSQL データベースサービスで、事実上あらゆる規模のワークロードに対してミリ秒単位のパフォーマンスを実現します。Amazon DynamoDB は、保存時の暗号化、自動バックアップとリストア、および最大 99.999 パーセントの可用性のサービスレベル（SLA） によって保証された信頼性をサポートしています。 DynamoDB Streams は、注文テーブルのアイテムレベルの変更の時間順のシーケンスをキャプチャし、この情報をストリーム配信を配信することで、他のアプリケーションやパートナーが注文の作成、変更、履行、キャンセルについて知らせます。注文サービスは、完全なマネージドコンテナオーケストレーションサービスである Amazon Elastic Container Service （Amazon ECS）上のコンテナワークロードとしてデプロイされ、API エンドポイントは、開発者が事実上あらゆる規模で API の作成、公開、保守、監視、および保護を容易にする完全なマネージドサービスである Amazon API Gateway を通じて安全に公開されます。 様々なコンポーネント間のコアメッセージの連携には、 Amazon Managed Streaming for Apache Kafka （Amazon MSK）を使用しています。Amazon MSK を使用することで、お客様は可用性の高い Apache Kafka および Kafka Connect クラスタのプロビジョニング、設定、メンテナンスなどの運用オーバーヘッドを大幅に削減できます。 注文と集計は、インタラクティブなログ分析、ニアリアルタイムのアプリケーションモニタリング、ウェブサイト検索などを簡単に実行できる Amazon OpenSearch Service に保存され、スケーラブルでセキュアなデータ可視化を提供する Amazon Managed Grafana を通じて、ニアリアルタイムの読み取り専用アクセスとダッシュボード表示を行います。 フォーマット間の変換や、注文ライフサイクル イベントに基づいたビジネス イベントの開始のための個別の変換ロジックは、サーバーのプロビジョニングや管理を行わずにコードを実行するためのサーバーレス コンピューティング サービスである AWS Lambda を使用して構築されます。 料金は、消費したコンピューティング時間に対してのみお支払いいただきます。 このアーキテクチャは、双方向のイベント交換メカニズムを提供することで、既存の PNR ベースの PSS システムとの共存を可能にし、従来の PSS システムで発生した変更と注文データの同期を保証します。 航空会社のITおよびパートナーエコシステムとの統合 ONE Order システムと航空会社の IT およびパートナー エコシステムの統合は、主にイベントまたは API を通じて行われます。 API は、他のシステムが ONE Order システムと直接対話し、オーダーの作成、変更、キャンセルを行うことを実現します。 一般的な航空会社の顧客チャネル (直接および間接) は、このメカニズムを使用して注文を作成、変更、またはキャンセルします。 IATA によって定義された注文ライフサイクル イベントにより、新しい注文が作成、変更、またはキャンセルされた場合に他のシステムに通知できるようになります。 これらのイベントは、収益管理、PNR ベースの PSS システム、在庫管理システムなどの他の航空会社の IT システムが、注文に何が起こったかを理解し、影響を評価し、下流の処理を開始するのに役立ちます。 またこれらのイベントは、エコシステム内の他のパートナー、例えば、航空会社が共同販売するホテル、空港サービス、その他の非航空小売プロバイダーのような他のサービスプロバイダーやフルフィルメントエージェントとの統合にも役立ちます。 そして、イベントを使用することによって、分離された非同期処理が保証され、このアーキテクチャをスケーラブルで耐障害性の高いものにしています。 次世代小売業 私のように航空会社で、あるいは航空会社と共に数年間働いてきた者にとって、航空業界の小売とパーソナライゼーションの取り組みの進化の一端を担えることはエキサイティングなことです。IATA ONE Order 標準に準拠した次世代小売・プラットフォームを AWS 上でクラウドネイティブに構築したいと考えている航空会社と一緒に仕事ができることを楽しみにしています。 このブログの続きとして、ONE Order システムと航空会社の収益管理システムの統合について詳しく説明しました。これについては、電子書籍「 AWS for RMS：クラウドにおける最新の収益管理 」で読むことができます。 著者について Robin Kanthareuben Robin Kanthareuben は、旅行、輸送、ホスピタリティ分野で 20 年以上の経験を持つ、経験豊富なテクノロジー リーダーです。 彼は、テクノロジー戦略とアーキテクチャのコンサルティングを通じて、大手航空会社、空港、航空連合、ホテル チェーン、旅行テクノロジー プロバイダーと協力してきました。 彼は現在、ドバイに拠点を置くアマゾン ウェブ サービスに勤務しています。 現在の役割では、旅行業界のビジネスおよびテクノロジーエグゼクティブと提携して、クラウドおよびデジタル テクノロジーを活用してビジネス目標を達成し、組織をその分野のリーダーに変革し、最高の顧客エクスペリエンスを提供できるように支援しています。 翻訳はソリューションアーキテクトの程が担当しました。原文は こちら です。

本稿では、 J．フロント リテイリング株式会社 （以後、JFR）が取り組んでいるデジタル人財育成の中で、 AWS 上に構築した統合データ基盤を活用したデータアナリスト育成の取り組みについて紹介します。 JFR の人財育成のアプローチ 大丸松坂屋百貨店、パルコを傘下に持つ JFR は、デジタル戦略の骨子を取りまとめ、現在はそれに基づいた推進を行っています。戦略骨子は以下の３つの柱から構成されています。 カスタマー・データドリブン経営の実践 デジタルテクノロジーを活用した新たなビジネスモデルの構築 これらのアクションを支えるデジタル人財の育成 このうち３つ目の「デジタル人財の育成」について、説明します。 JFR では、デジタル人財として「データアナリスト」「デジタルデザイナー」の2つの人財像を設定し、マインド、スキル、ナレッジを身に着け、データやデジタルテクノロジーを活用して、業務課題の解決や新しいビジネスをデザインできる人財の育成を目標としています。 データアナリストの重要性 デジタル人財のうち、「デジタルデザイナー」は、ビジネスとテクノロジー双方のナレッジを持ち、課題や戦略に沿ったビジネスデザインを行う人財です。これらの人財育成を内製したプログラムで取り組むことで、単なるスキル習得だけでなく、 JFR で求められるマインド、ナレッジを身に着けることを狙っています。もう一方の「データアナリスト」とは、統計解析のナレッジを基に BI ツールなどを用いてデータを分析し、ビジネスレポートや施策の立案、評価などを行う人財です。 データアナリストとして活躍していくためには、仮説の立案を行うと共に、データに基づいた検証を自ら実施できる必要があります。データアナリストは、自ら検証した結果を基にデジタルデザイナーや現場の担当者と協力して戦略施策を立案し、実行していくことが求められるのです。そのために、データアナリストのデータ活用力を高めることが重要となってきます。 人財育成プログラムで目指すこと データプラットフォームを作っただけでは DX を実現できないことを多くの方が認識しています。データアナリストの育成も同様であり、単にスキル教育をするだけではデータ活用力を高めることはできません。そのため、 JFR では、「マインド設定」「データに関する基礎知識」「専門的な実践技術」「現場での実行力」を組み合わせることで、より実践的な人材を育成するプログラムを目指しています。 「データに関する基礎知識」では統計学で用いられる理論やクラウド活用で得られるビジネスメリットの基本知識を押さえ、「専門的な実践技術」ではクラウド上のデータの操作技術、最近では一般化してきた ML などの AI 利用技術などを取得する必要があります。 一方で、研修を受講する JFR グループ社員の強みはこれまでの現場で培った経験であり、顧客感覚です。そのため、この強みに対してデータ活用力を付加していくことが重要です。 これらを考慮した育成プログラムは、 JFR 社員が主体となって作り上げる必要があり、そこへ外部の専門家の力を組み合わせることになります。また、内製化を中心にすることで以下を期待しています。 各プログラムで取り扱う事例やデータを身近なテーマとすることで、受講生の理解を促進する 変化し続ける市場、会社の状況に合わせて、都度育成プログラムを調整することで、正確な情報を受講生へ伝える 社員が中心となって育成プログラムの改善サイクルを回すことで、少ないコストで最適なプログラムを提供する 育成プログラムを社内へオープンにすることで、受講生だけでなく、多くの社員へ自学自習環境を提供する AWS との取り組み データアナリストには、自ら検証を行えるようになることを求めています。すなわち、 JFR が採用しているクラウド環境（ AWS 環境）の基本を理解し、自ら操作し、結果を得るスキルを身に着ける必要があります。これを実現するために、 AWS 協力の下で、以下の内容を盛り込んだ独自のコンテンツを用意しました。 AWS をベースとしたクラウド環境の一般知識、利用におけるメリット／デメリットの解説 AWS の各種機能とJFRが活用している機能の紹介（ Amazon Simple Storage Service 、 AWS Glue 、 Amazon Athena など） AWS へ実際にアクセスし、操作方法を学ぶハンズオン 実業務を想定した、クエリー（SQL）の基本を学ぶハンズオン 自社環境による本格的な教育実施の前にクラウド利用の基礎を、専門家である AWS のソリューションアーキテクトが語り、演習をすることで、 JFR は実践的な教育に専念することができます。また、受講生は一般的な知識やスキルと、当社の環境での活用方法を関連付けて考えることができるようになります。 JFR の AWS を活用した演習環境は、実務データをベースにした非常に実践的な環境です。研修の集大成の位置づけで業務に密着したレポートテーマを設定し、演習環境を利用したデータ分析、仮説立案と検証を行うことで実行力を定着させることを狙っています。 JFR のグループデジタル統括部デジタル推進部でデジタル人財育成チームを率いる村川氏は、「私たちがデジタル人財の育成で大切にしているのは、実践力です。」と述べています。「私たちはこの研修カリキュラムを通じて身に着けた、 AWS を実際に操作して自らデータ分析を行う実践力を、現場で発揮することを期待しています。そのために研修終了後も、企画支援やデータ分析支援を行う体制を整え、データアナリストをバックアップする体制を整えています。」 デジタル人財育成プログラム向けコンテンツについて JFR のデジタル人財育成プログラム向けに作成したコンテンツは、 AWS と SQL の基礎を学ぶハンズオンです。AWS 入門では、 JFR で利用している AWS サービスの基本操作を学び、SQL 実行環境を構築します。SQL 入門では、基本的な構文（GROUP BY 句、 JOIN 句など）を学び、実務に沿ったデータを用いた演習問題に取り組みます。これにより、受講者全体のスキルを向上させ、データアナリストとして活躍するための土台を築きます。 実際に取り組んだコンテンツの抜粋 まとめ・今後について JFR では、データアナリストの育成を 2022 年末から行っています。すでに 20 名以上のデータアナリストを輩出しており、データアナリストとデジタルデザイナーを合わせて、2024 年度末に 100 名、2030 年度末に 1,000 名まで増やす計画を進行中です。データアナリストは現場に戻り、現場課題を抽出し、データ分析による解決に取り組んでいます。データ分析にあたっては、現場に任せきりにするのではなく、統合データ基盤を活用できる環境と共に、分析アドバイスやサポート、継続的な取り組みと、スキルアップが可能な仕組みを提供し、活躍してもらっています。今後は、この動きを活発化させると共にデジタルデザイナーとも連携して、「カスタマー・データドリブン経営」を一層加速させようとしています。 JFR ではこの取り組みを強力に推進していくために、共に取り組んでいく仲間を募集しています。興味を持っていただける方のご連絡をお待ちしています。   本稿は、ソリューションアーキテクト 齋藤、髙橋が担当し、J．フロントリテイリング株式会社 グループデジタル統括部デジタル推進部 デジタル人材育成チームリーダー 村川氏との共同執筆です。デジタル人材育成に取り組む方の参考となれば幸いです。 JFR における統合データ基盤を活用したカスタマー・データドリブン経営の取り組みについても、以下のブログで紹介しています。合わせてご覧ください。 「 J．フロントリテイリングにおける統合データ基盤を活用したカスタマー・データドリブン経営の取り組み 」  

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 を取得し、イェール大学でコンピューターサイエンスの理学士号を取得し、イェール大学で哲学の修士号を取得しています。 この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。原文は こちら です。