7月10日、機械学習 (ML) 開発ライフサイクルを簡素化および加速する Amazon SageMaker Studio の新機能を発表しました。SageMaker Studio の Amazon Q Developer は、SageMaker JupyterLab エクスペリエンスにネイティブに組み込まれた生成 AI 搭載アシスタントです。このアシスタントは、お客様の自然言語入力をもとに、各タスクに最適なツールの提案、ステップバイステップのガイダンスの提供、開始するためのコード生成、エラー発生時のトラブルシューティング支援を行うことで、お客様の ML 開発ライフサイクルに合わせた実行計画を作成します。また、複雑な ML の問題を小さなタスクに変換したり、ドキュメント内の関連情報を検索したりするなどの課題に直面したときにも役立ちます。 生成人工知能 (生成 AI) や従来の ML のユースケースで Amazon SagaMaker を評価したい初めてのユーザーや、SageMaker の使用方法を知っているけれど生産性をさらに向上させ、インサイトを得るまでの時間を短縮したいと考えているリピートユーザーにも役立ちます。SageMaker Studio の Amazon Q Developer を使用すると、SageMaker Studio を離れなくても、ドキュメントページやオンラインフォーラムでサンプルノートブック、コードスニペット、説明を検索しなくても、ML モデルの構築、トレーニング、デプロイを行うことができます。 それでは、SageMaker Studio の Amazon Q Developer のさまざまな機能をご紹介しましょう。 SageMaker Studio で Amazon Q Developer の使用を開始する Amazon SageMaker コンソール で、 [Admin configurations] (管理者設定) の [Domains] (ドメイン) に移動し、ドメイン設定で Amazon Q Developer を有効にします。Amazon SageMaker を初めて使用する場合は、 Amazon SageMaker ドメインの概要 ドキュメントを確認してください。[ mytestuser ] の [Launch] (起動) ドロップダウンから [Studio] (スタジオ) を選択して Amazon SageMaker Studio を起動します。 環境が整ったら、 [Applications] (アプリケーション) で [JupyterLab] を選択し、 [Open JupyterLab] (JupyterLab を開く) をクリックして Jupyter Notebook を開きます。 生成 AI を搭載したアシスタント Amazon Q Developer は、私の Jupyter Notebook の隣にあります。手始めに使える組み込みコマンドがあります。 ML 問題を自然言語で説明すれば、すぐに Amazon Q Developer との会話を始めることができます。アシスタントのおかげで SageMaker を使えるので、ツールや機能の使い方を調べるのに時間を費やす必要はありません。次のプロンプトを使用します。 S3 バケットにデータがあります。そのデータを使用して、予測用の XGBoost アルゴリズムをトレーニングしたいと考えています。サンプルコードで手順をリストアップしてもらえますか。 Amazon Q Developer がステップバイステップのガイダンスを提供し、予測用に XGBoost アルゴリズムをトレーニングするためのコードを生成してくれます。推奨手順に従って、必要なセルをノートブックに簡単に追加できます。 S3 からデータセットをダウンロードし、Pandas を使って読み込むためのコードを生成する別のプロンプトを試してみましょう。これを使ってモデルの構築やトレーニングができます。これにより、反復的なタスクを処理し、手作業を減らすことで、コーディングプロセスを合理化できます。次のプロンプトを使用します。 S3 からデータセットをダウンロードして Pandas で読み込むためのコードを書いてもらえますか? また、Amazon Q Developer にエラーのデバッグと修正に関するガイダンスを尋ねることもできます。アシスタントは、頻繁に発生するエラーと解決策に基づいてトラブルシューティングを行うのを手伝ってくれます。これにより、時間のかかるオンライン調査や試行錯誤のアプローチから解放されます。次のプロンプトを使用します。 SageMaker のバッチ推論によりモデル品質監視用のマージジョブを実行する場合に、「JSON のスキーマを推論できません。手動で指定する必要があります」というエラーを解決する方法を教えてください。 最後の例として、Amazon Q Developer に、ノートブックジョブのスケジュール方法に関するレコメンデーションを教えてもらいます。次のプロンプトを使用して回答を取得します。 ノートブックジョブをスケジュールするオプションにはどのようなものがありますか? 今すぐご利用いただけます Amazon SageMaker が一般的に利用できるすべてのリージョンで Amazon Q Developer にアクセスできます。 アシスタントは Amazon Q Developer Professional Tier のすべてのユーザーが利用できます。料金の情報は、 Amazon Q Developer の料金ページ をご覧ください。 今すぐ SageMaker Studio の Amazon Q Developer を開始して、ML 開発ライフサイクルの段階を問わず、生成 AI を活用したアシスタントを使い始めましょう。 – Esra 原文は こちら です。

こんにちは。ソリューションアーキテクトの齋藤です。丸紅株式会社(以下、丸紅) デジタル・イノベーション部 では、デジタルを活用して丸紅グループの変革を推進し、デジタル人財を育成して各部門の事業を大きくしていくことをミッションに掲げています。当部では、デジタル技術に精通するメンバーが、丸紅の各組織へ、課題整理→実証実験→実用化まで一気通貫で支援を実施しており、AI・データ分析 を中心に、内製で開発しています。本ブログでは、どのように丸紅がAWS上で社内生成AIプラットフォームアプリ(以降 Marubeni Chatbot)を開発して、社内公開までに直面した課題を解決したか、どのようにユーザへ活用促進を繋げたか、赤裸々に紹介させて頂きます。本ブログは、丸紅 デジタル・イノベーション部 芹川 武尊 氏 から寄稿していただいたものです。 背景 AWS 齋藤  : Marubeni Chatbot の開発が始まった経緯について教えてください。 丸紅 芹川氏 : 元々、私を含めた若手2名での生成AIを使って、なにかやりたいね! という漠然とした雑談が発端です。2023年3月に、GPT-4 を目の当たりにして、衝撃を受けたことが記憶に残っています。これは来るな! と感じました。難易度を4つのレベルに分けて、より技術的・業務的に容易でインパクトも出やすい領域から導入を進めました。開発は自社で熱意のある人が開発するほうが早いということになり、自社若手メンバーで Marubeni Chatbot の内製開発になりました。 AWS 齋藤 : 　ちなみに丸紅様にとってAIを取り扱う中でビジネス上どのような課題があったのですか? 丸紅 芹川氏 : デジタル・イノベーション部は、AIやデータ分析を活用したDX推進に取り組んでおり、その中で複数の部門・事業会社から特定の業務の効率化・高度化を求める声が上がっています。一方、丸紅の事業範囲が非常に広いため、各事業の特殊性に応じた個別対応が必要となるケースが多くあります。このため、AI導入におけるROI（投資対効果）を最適化するためには、各事業部門が主導的にAIを活用し、その業務特性や課題に即したソリューションを開発する、言うなれば「AIの民主化」の実現が必要であると考えていました。そして、最近の生成AIの登場により、それが遠くない未来に現実的に実現可能になったと考えております。 Marubeni Chatbot について AWS 齋藤 : Marubeni Chatbot の ユーザーは、どのような方ですか? 丸紅 芹川氏 : 丸紅本体の役員、管理職、一般社員、グループ会社社員まで、多種多様な社員が使用しています。登録ユーザー数は7,500人以上になっています。 AWS 齋藤 : Marubeni Chatbot では、どのくらいのデータ量を扱っていますか? 丸紅 芹川氏 : 現時点(2024年6月時点)では、ユーザーによって登録されたファイル数は、60,000ファイル、PDF形式に変換したデータ量でいうと 500GB 程になります。 AWS 齋藤 : Marubeni Chatbot の概要及びどのような機能を提供しているか教えてください。 丸紅 芹川氏 : Marubeni Chatbot では、複数のLLM(Claude 3.5 Sonnet, Claude 3 Opus, Gemini 1.5 Pro, GPT-4o, GPT-4 Turbo)をエンドユーザ自身が選択することが出来るチャットアプリを提供しています。多数の機能がありますが、3つに絞り紹介させて頂きます。1つめは ファイルチャットアプリ です。これは、エンドユーザが業務で使用する契約書や資料 (Word, Excel, Powerpoint, PDF) を、Marubeni Chatbot に、エンドユーザ自身がアップロードし、資料内容に基づいて、エンドユーザからの質問への回答や文書の要約を提供します。丸紅はグローバルに展開する商社ということもあり、スペイン語、中国語、ベトナム語など、英語以外の資料を取り扱う機会も多いのですが、そういった資料の日本語での要約、質問回答は、業務効率の大きな改善に繋がっています。2つめは 音声認識チャットアプリ です。これは、音声や動画ファイルをアップロードすると、会議音声の文字起こし・議事録作成を行うことができます。また、会議の最中に本システムを起動して、リアルタイムで文字起こしを行うことも可能です。最後は、 カスタムボットアプリ です。これは、エンドユーザ自身で、担当業務に関連する資料を集約することで、独自の Knowledge base を構築出来ます。特定の部署内のルールに対して回答してくれるボットがその部署内のメンバーによって作成され活用されるなどユーザー自身の手による業務効率化につながっています。尚、こちらの機能でも、LLMは業務特性に合わせて選択することが可能です。 AWS 齋藤 : 各機能のアーキテクチャについても紹介していただけますか? 丸紅 芹川氏 : アーキテクチャは下記の通りになります。 ファイルチャットアプリ ユーザは、Webアプリケーションから、ファイルをアップロードします。アップロードがトリガーになり、外部LLMを用いて Embedding し、Amazon S3 にベクトルデータを格納します。ファイルに関してユーザから指示があると、AWS Lambda は、Amazon S3 に格納されたベクトル情報をメモリに読み込み、類似度の高い文書及びセクションを検索し、Amazon Bedrock で回答を生成します。 ファイルチャット UI ファイルチャット アーキテクチャ 音声認識チャットアプリ ユーザは、Webアプリケーションから、音声又は動画ファイルをアップロードします。アップロードされたファイルは、Amazon Transcribe にて、Speech to Text がされますが、変換時の間違い、区切りの誤りなど、Amazon Bedrock を用いて整形します。音声ファイルの中身そのものを変えないように、プロンプトの試行錯誤を繰り返すことで、想定した変換を実現することが出来ました。また、書き起こし後のテキストに対してチャットUIで質問を投げかけることも可能で、こちらの機能を活用することで容易に議事録作成が可能です。 音声認識チャット アーキテクチャ カスタムボットアプリ ユーザは、Webアプリケーション上のUIから、データソースとなるドキュメントやFAQを登録することで、独自のカスタムボットを作成出来ます。このときユーザーは、LLMの指定とパラメータ設定、そのカスタムボットにアクセスできるユーザーの登録(ユーザ名, 部署, 会社)を行えますが、本情報は、Amazon DynamoDB に保管されます。カスタムボットアプリで使用されるデータソースとなるドキュメントは、Amazon S3 に保管され、外部LLMを用いて Embeddingを計算し、Pineconeにベクトルデータを保存します。データソースとなるドキュメントの中身は、Webアプリケーションからいつでも追加・変更することが可能です。回答精度の改善をしたいときや、事前に回答を規定したいときには、FAQの登録によってチューニングすることも可能です。 カスタムボットアプリ アーキテクチャ カスタムボットアプリ モデル設定 カスタムボットアプリ アーキテクチャ ドキュメント追加・編集UI カスタムボットアプリ FAQ 登録UI AWS 齋藤 : ユーザーが能動的に生成AIを使用することが出来る環境を提供していることが印象に残りました。 直面した課題と解決へのアプローチ AWS 齋藤 : Marubeni Chatbot を構築する中で課題に直面したと思います。どんな課題があり、それをどのように解決したのでしょうか? 丸紅 芹川氏 : Marubeni Chatbot 内のRAGを用いたアプリの開発の中で、回答の精度が課題になりました。例えば、社内規程をもとに回答するボットでは、回答に対して間違いが許容されにくく、一貫性や精度を確保する必要がありました。これに対するアプローチとして、元々WordやPDFの形式で保管された社内規程文書に、意味のあるテキストセグメンテーションを持たせるために、Markdownで記載しなおすように前処理をしました。その後、Markdownでセクションごとにセグメンテーションされた文書をEmbeddingして、 Pinecone にベクトルデータを保存しました。又、開発で工夫した点としては以下です。開発にLangchainを使用していたが、OpenAIのLLMが基軸になっており、Anthropic社など他社LLMへの対応が遅れていることを感じ、LangChainを取り除いて自社で抽象レイヤーを開発しました。それに加え、生成AIの回答精度の改善のために、WordやPowerpointからMarkdownへ変換を実施しましたが、手作業になっていたので、ここでも生成AIを活用して社内規程文書を自動でMarkdown形式に変換する機能を実装しました。 導入効果 AWS 齋藤 : Marubeni Chatbot 導入によりどのような効果がありましたか? 丸紅 芹川氏 : はい。2024年2月時点でのデータになりますが、ユーザからのFeedbackとして各業務で25-65%程度の時間削減効果及び業務高度化の効果を実感したとありました。詳細は下記のグラフの通りになります。 業務時間削減率について Why AWS? AWS 齋藤 : Marubeni Chatbot に、AWSが採用された決め手を教えて下さい。 丸紅 芹川氏 : たくさんあるのですが、AWS は フルマネージド型でありつつも、拡張性が高いサービスが充実しているところです。Marubeni Chatbot　開発当初はコストを割り当てることが難しく少ないメンバーで始める必要がありましたが、長期的には機能やユーザー数が増える可能性も予想されていました。そのような不確実性の高い状況下では、AWSのフルーマネージド型 サービスを採用するところから始めることで、OSやミドルウェアの運用保守をAWSにオフロードし、機能数やトラフィック数が増加したときも構成を大きく変えることなくスケールすることが可能でした。セキュリティでは、HIPPAやGDPRへ準拠しており、エンタープライズ用途でも利用しやすかったです。 今後の展望について AWS 齋藤 : Marubeni Chatbot の、今後の展望について教えてください。 丸紅 芹川氏 : 現在、Level4: 経営判断の高度化への取り組みの開発と利用を進めており、この精度の更なる改善に取り組んでいます。それと同時に丸紅グループ社員の意識改革も引き続き必要だと考えています。まずは実業務での利用を通して、生成AIの特性を現場レベルで理解してもらう。その上で社員一人ひとりが、AI 1st の意識を持って、 AI に最適な形に知見を集積していく。これらを通じて長期的にはAI を使い倒す企業文化を醸成し、それがより高度な生成AIの活用につながってきます。 著者について 丸紅 芹川氏 2022年 東京大学大学院情報理工学系研究科修士課程修了。情報理工学修士（数理最適化に関する研究)。大学院修了後、丸紅株式会社に入社。入社後は、物流関連最適化システムの開発や、生成AIを活用したグループ会社向けChatbotアプリの開発など丸紅グループを横断したプロジェクトの参画。

2024 年 1 月、マイグレーションとモダナイゼーションを加速させるためのガイドツールとして、Migration Hub Journeys を導入しました。ジャーニーは、エキスパートによるガイダンス、専用ツール、チーム間のコラボレーションを備えたタスクベースのテンプレートを通じて、計画、実行、追跡を最適化し、シームレスなマイグレーションとモダナイゼーションを可能にします。この度、AWS for VMware の新しいマイグレーションジャーニーテンプレートを公開しました。このテンプレートによって、オンプレミス、他のクラウド、VMware Cloud on AWS の VMware ワークロードから、AWS ネイティブサービスへの迅速なマイグレーションとモダナイゼーションを可能にします。 AWS Migration Hub Journeys とは AWS Migration Hub Journeys は、マイグレーションプロジェクトをテンプレート化して、社内外のプロジェクト関係者間でタスクを調整するために設計されています。ジャーニーはユーザーに包括的なマイグレーションジャーニーを提供することで、マイグレーションを最初から最後まで実行および追跡できるようにします。エキスパート、プロセス、ツールを結集して、マイグレーション作業を効率化することができます。 図 1 : Migration Hub Journeys の概要 ジャーニーの主な機能には以下のようなものがあります： マイグレーション計画： クラウドマイグレーションを計画するための構造的な方法を提供します。 規範的ガイダンス： マイグレーションテンプレートの形式でガイダンスを行います。 実行と追跡： マイグレーションタスクを管理し、進捗のモニタリングを行って、途中で発生した問題に対処することができます。マイグレーション状況をリアルタイムに確認することができます。 コラボレーションとガバナンス： マイグレーションに関して、さまざまなステークホルダーが協力しやすくなります。 Migration Hub Journeys の新機能 VMware ベースのワークロードを AWS へ速やかにマイグレーションするための新しいテンプレートを追加しています。これらのテンプレートは AWS Migration Methodology に沿って設計されており、効率的に AWS にマイグレーションできるようにタスクのパイプラインを提供します。これらのテンプレートから作成されるマイグレーション関連タスクのパイプラインであるジャーニーは、必要な情報を収集することでインフラストラクチャの現状を評価して、現在のライセンス資産を把握するプロセスをガイドします。また、必要なネットワーキング、セキュリティ、ガバナンスコントロールを備えたランディングゾーンを作成して、リソースを AWS へマイグレーションのためのタスクもガイドします。さらに、AWS クラウドネイティブサービスへマイグレーションするためのタスクもガイドします。 図 2 : Migration Hub のマイグレーションテンプレート AWS for VMware マイグレーションテンプレート VMware から AWS EC2 へのマイグレーションテンプレートは、アセスメント、モビライズ、マイグレーション、モダナイゼーション、オペレートの各フェーズに分類された一連のタスクです。各フェーズはいくつかのモジュールに分かれており、さらにタスクとサブタスクに分かれています。効率的にマイグレーションを実行および追跡できるように、テンプレートで特定のタスクに関連する VMware のガイダンスが表示されます。 例えばアセスメントフェーズのタスクでは、RVTools を使用してサーバー使用率情報を収集し、ビジネスケースに反映させるためのガイダンスが表示されます。さらに、AWS にはマイグレーションアセスメントプログラムとパートナーソリューションがあり、アセスメントフェーズ中に正確なマイグレーションビジネスケースを提供できます。また、現在のアプリケーション / ベンダーライセンスを理解し、コストパフォーマンスを向上させるために AWS をどのように活用できるかをタスクでガイダンスします。マイグレーションフェーズのタスクでは、AWS Application Migration Service (MGN) レプリケーションの使用など、マイグレーションシナリオに特化したツールの選択に関するガイダンスが表示されます。この情報は必要なコンテキストでタスクを実行できるように、それぞれのタスクで提示されます。 図 3 : マイグレーションフェーズのタスクボード 同様に他のフェーズについても、いくつかのモジュール、タスク、サブタスクに分解されています。推奨されるフローに従うことで AWS へのマイグレーションを成功させるために必要なすべてのステップが示され、マイグレーションの実行と追跡が容易になります。 VMware から AWS へのマイグレーションの実行 このシナリオでは VMware から AWS EC2 へのマイグレーションテンプレートを使用して、マイグレーションジャーニーを作成します。ジャーニーを作成したら、タスクの追加、変更、削除を行って、ニーズに合わせてジャーニーをカスタマイズし、他のユーザー (パートナーや AWS 担当者を含む) を招待してコラボレーションを行うことができます。また、ニーズだけに基づいてカスタムジャーニーを簡単に作成することもできます。権限に基づいてユーザーが個々のタスクをエキスパートに割当て、遅延やブロックされたタスクの自動通知を受取ったり、コンテキストが失われないように一箇所に成果物をアップロードできます。ジャーニーを作成する画面を参照してマイグレーションジャーニーの構造を理解してください。 図 4：テンプレートからのジャーニーの作成 ジャーニーが作成されるとジャーニーのダッシュボードにリダイレクトされます (図 5 )。ここではジャーニーの概要と詳細のセクションが表示されます。管理者は、マイグレーションスペースの他のメンバーや、マイグレーションスペースのチーム、さらには AWS 担当者やパートナーなど、マイグレーションスペース外のメンバーを招待することで、コラボレーションを促進することもできます。 図 5：ジャーニーダッシュボード ダウンタイムをほぼゼロにして VMware サーバーを AWS にマイグレーションする方法は複数ありますが (ブロックレベルのレプリケーション、VM Import/Export、パートナーソリューション)、AWS Application Migration Service (MGN) が VMware ベースのワークロードを AWS クラウドにリホストするための主要なマイグレーションサービスとして推奨されています。 例えば AWS MGN は、オンプレミスから AWS へのサーバーレプリケーションにエージェントベース (図 6 ) とエージェントレス (図 7 ) の両方のアプローチをサポートしています。エージェントは Windows と Linux の両方のサーバーにインストールできます。AWS Application Migration Service でレプリケートしたい各ソースサーバーに AWS Replication Agent をインストールする必要があります。 図 6 : AWS MGN エージェントベースのマイグレーションアーキテクチャ エージェントレスアプローチではエージェントレスレプリケーション機能によって、エージェントをインストールせずに vCenter からソースサーバーを追加することもできます。AWS MGN vCenter Client がインストールされると、vCenter 環境内のすべての仮想マシンを検出して AWS MGN に追加します。 図 7 : AWS MGN エージェントレスマイグレーションのアーキテクチャ Migration Hub Journeys テンプレートのタスクとサブタスクは、エージェントベースまたはエージェントレスの方法でマイグレーションプロセスをガイドします。マイグレーション中に必要なすべてのステップ、タスクの所有者、タイムライン、問題、アクションを追跡し、マイグレーションを成功に導きます。 まとめ VMware ベースのワークロードを AWS に迅速にマイグレーションし、最適化できるようにするために、AWS for VMware の新しい Migration Hub Journeys テンプレートを発表しました。これらのテンプレートを利用することで、ステークホルダー、AWS 担当者、パートナー間のコラボレーションを促進し、クラウドへのスムーズなマイグレーションを確保するために効率的な計画と実行ができるようになります。さらに、AWS の広範なグローバルインフラストラクチャによって、スケーラビリティの確保、高いセキュリティ、信頼性の向上、パフォーマンス改善を行うことができます。 AWS Migration Hub Journeys でマイグレーションジャーニーを始めましょう。今すぐ AWS Builder ID を使用してサインインしてください。 また、ワークショップに参加して、ジャーニーの包括的な理解を深し、マイグレーションプロセスをどのように変えることができるかを学ぶこともできます。 翻訳をソリューションアーキテクトの Furuya が担当しました。原文は こちら です。 Migration Hub Journeys と VMware ワークロードの AWS へのマイグレーションに関する追加情報については、以下を参照してください： 計画から実行まで ー AWS Migration Hub を活用してマイグレーションとモダナイゼーションを加速する VMware 仮想マシンを AWS Application Migration Service レプリケーションエージェントを利用して Amazon EC2 に移行する Agentless snapshot based replication for vCenter source environments Accelerate vCenter Migration using AWS Migration Service Agentless Migration AWS VMware Migration Accelerator 著者について Hemanth Vemulapalli 12 年以上の業界経験を持つマイグレーション専門の AWS ソリューションアーキテクト。企業がワークロードを AWS クラウドにシームレスにマイグレーションすることを支援しています。信頼できるアドバイザーとして深い技術的専門知識を活用し、ビジネス変革を推進する革新的なソリューションを設計および実装しています。余暇には、テレビ鑑賞、ハイキング、ランニング、家族との時間を楽しんでいます。 Mangesh Budkule AWS のシニア Microsoft 専門ソリューションアーキテクト。AWS サービスのアーキテクチャガイダンスと技術支援を提供し、AWS を利用するうえでソリューションの価値を向上させるために、顧客と協働しています。2003 年から IT エキスパートとして業界の様々なベンダーの多様な技術をカバーしています。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 AWS Summit New York があり沢山の生成 AI 関係のアップデートがありました。 週刊生成AI with AWS で網羅的に取り上げており、こちらもご覧ください。 異なる視点での最近の生成 AI の出来事を記載すると、 GenU (Generative AI Use Cases JP) という名前の GitHub で公開されているアプリケーションがあるのですが、新たに Knowledge bases for Amazon Bedrock を利用した RAG チャットの機能が追加されました。Knowledge Bases の進化に合わせた機能の利用がやりやすくなったり、コスト面では従来の Kendra を利用した構成と比較して、最大 1/6 ほどの料金で RAG チャットが利用できるようになっています。ぜひ、こちらもお試しください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年7月8日週の主要なアップデート 7/8(月) Amazon CloudFront がウェブアプリケーション向けの管理キャッシュポリシーを提供 Amazon CloudFront は、2 つの新しい管理キャッシュポリシー「UseOriginCacheControlHeaders」と「UseOriginCacheControlHeaders-QueryStrings」を提供開始しました。新しい管理キャッシュポリシーは、オリジンから返されるレスポンスに Cache-Control ヘッダーが有ればコンテンツをキャッシュし、Cache-Control ヘッダーが無ければキャッシュをしません。キャッシュをさせたい静的なページと、キャッシュさせたくない動的なページが混在しているときに、新しいキャッシュポリシーでシンプルな利用がやりやすくなった形です。 FreeRTOS が新しいロングタームサポートバージョンをリリース FreeRTOS のロングタームサポート (LTS) として、202406 LTS をリリースしました。FreeRTOS LTS リリースは、2 年間にわたってセキュリティアップデートと重要なバグ修正を提供しながら、機能の安定性を提供します。FreeRTOS は、組み込みデバイス用に設計されている OS で、IoT といった文脈でよく利用されるものとなっており、軽量に動作する特徴があります。 Amazon Connect の自動エージェントシフト交代機能 Amazon Connect で、電話対応するエージェントのシフト交代スケジュールを自動化できるようになりました。元々、Amazon Connect には管理者がスケジュール管理を行う機能があります。今回の、自動シフト交代機能により、エージェントが繰り返し交代する一連のシフト (例: 朝のシフト、午後のシフト、夜のシフト) を作成することで、自動的にシフト交代を作成してくれるようになりました。詳細は こちらのブログ をご確認ください。 7/9(火) Amazon Q Business でユーザーに合わせてパーソナライズした応答 Amazon Q Business でパーソナライズされた応答を行うための機能が追加されました。Amazon Q Business の認証に利用する Identity Provider から、従業員の所在地、部門、役割といった情報を利用して応答の関連性を高める仕組みをもちます。このパーソナライズ機能は自動的に有効化されており、追加の設定なしにご利用いただけます。 AWS Glue Studio で ノーコードのデータ準備機能を提供 AWS Glue Studio Visual ETL で、データアナリストや機械学習エンジニア向けに、データのクリーニングや加工などの前準備を、表形式の GUI で実行できる機能が追加されました。Visual ETL で処理したい内容を GUI で繋げてデータ加工フローをくみ上げるのですが、そのフローの中に Glue DataBrew のレシピを連携できるようになった形です。詳細は こちらのブログ をご参照ください。 Amazon FSx for NetApp ONTAP で NVMe-over-TCP をサポート Amazon FSx for NetApp ONTAP で NVMe-over TCP をサポートしました。これは、従来の iSCSI ブロックストレージと比較して低レイテンシで、データベースや仮想デスクトップインフラストラクチャ (VDI) などのブロックストレージワークロードを高速化できます。また冗長化のためのマルチパス構成をシンプルにできる特徴もあります。 7/10(水) Claude 3 Haiku でファインチューニングがプレビュー可能に Amazon Bedrock で Anthropic の Claude 3 Haiku モデルのファインチューニングがプレビューで利用可能になりました。組織独自のトレーニングデータセットを用意してファインチューニングを行うことで、企業の独自の情報、ブランド、製品などを反映したユーザー体験を作り出すことができます。ファインチューニングを実施する際に、利用者専用の隔離された環境にコピーしたうえでトレーニングを行うため、セキュアな環境で利用する仕組みが備わっています。現在はオレゴンリージョンで利用が可能です。利用するには、AWS Support にお問い合わせください。 Amazon Q Developer で組織内の独自コードを利用した生成機能のプレビュー Amazon Q Developer で、独自ソースコードを利用した、ソースコード生成のプレビュー提供を開始しました。GitHub、GitLab、BitBucket、S3 に格納している、組織内のソースコードを使ってカスタマイズすることで、独自コードに基づいた内容を生成できるようになりました。例えば、組織内に共通的に利用するライブラリがあったときに、そのライブラリに実装されている関数を使って、新たなコードを生成できます。カスタマイズに利用したソースコードは、モデルの学習に利用されることはありません。Amazon Q Developer Pro サブスクリプションでご利用いただけます。詳細は こちらのブログ をご参照ください。 Agents for Amazon Bedrock で Code Interpretation 機能のプレビュー Agents for Amazon Bedrock で 新たにコード解釈機能 (Code Interpretaion) のプレビュー提供を開始しました。利用者のリクエスト内容に応じて、Agents は安全なサンドボックス環境でコードスニペットを動的に生成、実行できるようになり、データ分析、データ可視化、最適化問題などの複雑なユースケースを実行しやすくなりました。また、CSV、XLS、YAML、JSON、DOC、HTML、MD、PDF などのファイルを渡せるようになりました。例えば、CSV ファイルを渡して、「このデータをもとに売り上げ上位 3 種類を可視化して」とリクエストすると、可視化した画像が生成されます。現在、バージニア北部、オレゴン、フランクフルトリージョンでプレビュー利用ができます。詳細は こちらのブログ をご参照ください。 Knowledge Bases for Amazon Bedrock で Advanced RAG 機能の追加 Knowledge Bases for Amazon Bedrock で Advanced RAG 機能として、高度なチャンキング機能を提供開始しました。階層的なチャンキング (Hierarchical chunking) は、データを親チャンクと子チャンクの階層構造にして管理します。子チャンクを関連データとして取得する際に、より幅広く関連性の高いデータにするため、親チャンクのデータを利用するような仕組みとなります。セマンティックチャンキング (Semantic chunking) は、自然言語処理の手法を利用し、データを意味のあるチャンクに分割することで、理解と情報検索性能を向上させます。また、チャンクを行うコードを Lambda 関数で用意する機能が追加され、ユースケースに合わせた独自のチャンク分割を処理できます。ほかにも追加された機能があり、詳細は こちらの Document をご覧ください。 Amazon Bedrock でプロンプト管理や、プロンプトフロー機能のプレビュー Amazon Bedrock でプロンプト管理や、プロンプトフローのプレビュー提供を開始しました。Prompt Builder を利用することで、プロンプトを定義し、複数のモデル間の違いを確認しながら、最適なプロンプトの組み立てに役立てられます。外部のアプリケーションから、作成したプロンプトを使用するには、API コールでプロンプトを取得できます。また、Bedrock Prompt Flows は、視覚的なビジュアルビルダーを使って、ワークフローの作成、テスト、デプロイができます。詳細は こちらの Blog をご覧ください。 7/11(木) Amazon ECSでは、トラブルシューティングをより簡単に行えるよう、停止したタスクのエラーメッセージがより詳細な出力 Amazon ECS で停止したタスクのエラーメッセージが、より具体的な失敗理由と対処方法の推奨事項が含まれるようになりました。 AWS ドキュメント に具体的となったエラーの一覧とその対処豊富も記載されており、AWS マネジメントコンソールからリンクされすぐに辿れるようになっています。例えば、タスクの起動が失敗したときのメッセージをいくつか抜粋すると、 「Subnet の IP アドレスの空きがない」、「ECR から Pull ができなかったので、接続性に問題がある」、「Fargate Spot でキャパシティがない」といったわかりやすい内容にアップデートされています。 7/12(金) Amazon Q Business は、スキャンされた PDF とPDF 文書に埋め込まれた画像のサポートを導入 Amazon Q Business は、お客様の社内データに基づいて、質問の回答、要約、コンテンツの生成などを行う生成 AI 支援アシスタントです。このアップデートで、PDF のテキスト内容に加えて、紙の書類をスキャンして画像として貼り付けられている PDF に基づき生成ができるようになりました。スキャンした PDF にある表形式のデータや、構造化されたフォームを扱えるようになっています。詳細は こちらのブログ をご参照ください。 7/24 (水) 19:00~ に、Startup Loft (目黒オフィス) で「 IoT サブスクリプション ビジネスの課題と取り組み 」イベントを開催します。株式会社ビットキー様や株式会社VACAN様の事例のお話や、AWS Japan からの登壇の内容もあります。大規模利用事例や、スタートアップとしてのビジネス上で苦労された点のお話がありますので、ぜひ興味がありましたらご参加ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

本記事は 2019年9月9日に公開された ”How to Create a Data-Driven Culture” を翻訳したものです。 「もしデータがあるなら、データを見ましょう。もし皆さんに意見しかないのなら、私の意見に従ってください。」 ― ジム・バークスデール データドリブンな企業について語られるとき、多くの場合、ツールやビッグデータ、データの蓄積/加工/分析をより迅速かつ安価にした技術の進歩に重点が置かれています。これらは全て重要ではありますが、データドリブンカルチャーを企業全体で構築することは、ごくわずかなデータイニシアチブの成功や、特定の事業領域のみでの成功例を上回るために不可欠です。 データドリブンカルチャー では、意思決定時におけるデータの使用を受け入れます。データを広く利用可能にし、アクセスできるようにすることで、データを企業の戦略的資産として扱います。事業全体から意味のあるデータを収集し、クレンジング (訳註: 異常値排除や欠損値補完、表記ゆれの補正などを行なってデータの正確性を高めること) し、キュレーション (訳註: 組織内外のデータを組み合わせるなどして有益なインサイトが得られるように強化すること) することに重点を置いています。また、学習と改善のための頻繁な実験を促進し、人工知能 (AI) と機械学習 (ML) によるビジネスの差別化には、データの強固な基盤が不可欠であることを認識しています。さらに、データリテラシーのレベルが高く、データはすべての人の業績向上に役立つという信念が根付いているカルチャーです。 組織のリーダー達は、どのようにしてデータドリブンカルチャーを築くことができるでしょうか? 有言実行 データドリブンカルチャーを築くには、経営幹部のスポンサーシップが必要ですが、それだけでは十分ではありません。経営幹部には、単なるサポート以上のことが求められます。意思決定時には常に、データとビジネス判断を明確に結びつける必要があります。これには、不必要なレポートやスプレッドシート、ダッシュボードを容赦なく炙り出し、データドリブンカルチャーの錯覚を作り出すためだけに生成されたものを取り除くことが含まれます。データは目的に基づいて作られるべきであり、データ作成自体が目的ではありません。 経営幹部は、自分の信念に反するデータも積極的に求めるべきです。新しいデータに基づいて方針を変更することは、データドリブンカルチャーを作ろうとするリーダー達の強い決意を組織に示すシグナルになります。 データは力を与えてくれますが、強い感情を引き起こすこともあります。データドリブンカルチャーは、企業全体に透明性と説明責任をもたらします。これは時に不快なものになることがあります。一般的な企業では、他の組織にデータとインサイトを提供する専門のチームがあります。彼らは自分たちが関与せず、データの解釈を制御できなくなることを恐れています。経営幹部は、抵抗と組織の硬直化を克服するために介入する必要があります。 成功を生む組織を作る それぞれのデータイニシアチブは、他のものに付随するものとしてではなく、一つの製品のように管理されるべきです。そのためには、それを支える適切な組織体制を整える必要があります。私の同僚の Joe Chung が、「 データドリブンな組織になるには 」(eBook) で、アナリティクス CoE (Center of Excellence) の設立について語っています。これについて、アマゾン社で「シングルスレッドリーダー」と呼んでいるものの観点から考えてみたいと思います。シングルスレッドリーダーは、完全に権限を与えられたリーダーで、与えられた目標の実現を何かとの兼任ではなく、フルタイムの仕事として担当します。( Dave LimpとJeff Wilke から学ぶシングルスレッドリーダーの詳細については、 Forbes の こちらの記事 をご覧ください。) データドリブンカルチャーを築くには、そのことに専念している、権限が与えられたリーダーの存在が重要です。 データエンジニアリングとアナリティクスを IT 部門から切り離す傾向が高まっており、それが摩擦を生むこともあります。組織構造にかかわらず、IT 部門はデータイニシアチブを技術的にサポートするだけではなく、もっと重要な役割を果たすべきです。IT部門は、エンドツーエンドのビジネスサイクル、部門をまたがるワークフロー、および多くの有益なインサイトを内包するトランザクションシステムを完全に把握できるという点で、独自の立場にあります。私が CTO になる前は、グローバルな製品、アプリケーション、およびデータチームを率いていました。エンドツーエンドのオーナーシップを持つことで、私のチームは、サイロを解消する優れたデータ分析プラットフォームを構築できただけでなく、トランザクションシステムのギャップに対処してデータをより適切に収集して活用できるようになりました。十分な説明責任を果たしながらも周囲にフェンスが増えないよう、インクルーシブな構造を作りましょう。 データを部門の所有物ではなく、組織全体の資産として扱う 多くの企業では、データサイロは組織のサイロによって厳重に守られています。多くの場合、それには意味があって、組織内のメンバーが特定のデータ要素の意味や変数、算出方法、パターンを理解して正しく使用できるようにしています。これをデータにアクセスできない理由にしないでください。むしろ、こうした「守護者」を「教育者」に変えましょう。各部門のデータ専門家に教育と支援の主導権を握ってもらい、全ての社員がデータを正しく使用して企業のデータリテラシーを高められるようにしましょう。 これらのサイロは、データの相関分析も妨げます。多くのケースで組織は、収益、コスト、在庫、および顧客フィードバックを別々に見ています。これは、営業、財務、オペレーション、およびカスタマーサポートがそれぞれ独自のデータセットを抱え込んで守っているためです。今日のデジタル世界では、組織はデータを利用して顧客体験を向上させ、より良い製品を生み出すために、相関関係を利用してさまざまな手段をより動的に見つけて適用する必要があります。データを「制限」するのではなく、データへの「アクセスを増やす」というゴールから始める、軽量なデータガバナンス構造を構築しましょう。 データを民主化する データドリブンカルチャーとは、データを使って大きな意思決定を行うことだけではありません。データドリブンカルチャーは、現場で働く従業員の、日々の多くの小さな意思決定を、データを使って行えるようにします。デジタルエコノミーではスピードが重要であり、データを使用して製品のアイデア、設計上の決定、仮説を迅速にテストすることで、ビジネスの俊敏性を高めることができます。 高頻度な意思決定でビジネス価値を生み出し続ける企業 は、HiPPO (最も給料の高い人の意見) に基づく意思決定をやめ、非中央集権型のデータドリブンな意思決定プロセスへ移行しています。 Epic Games 社と、世界中で 1 億 2500 万人以上のプレイヤーが集まる大成功を収めたゲーム「フォートナイト」を例にとってみましょう。Epic 社は AWS を使用してゲーマーの満足度やインタラクションに関する最新の情報を収集し、そのデータをゲームデザイナーに提供しています。ゲームデザイナーはこのデータを使用して、ゲームをするたびに手作りされているように感じられるマップの自動生成や、導入または廃止する武器の決定など、追加すべき新しい体験について決定を下します。これにより、ゲーマーの体験が向上し、ユーザーコミュニティのエンゲージメントが高まっています。 同じ言語を話す 言語は古くから文化の確立と維持において重要な役割を果たしてきました。共通の言語は、文化を形成する価値観、信念、アイデアを伝えるのに役立ちます。データドリブンカルチャーも例外ではありません。データドリブンカルチャーを築くためには、企業はデータに関する共通の語彙を作る必要があります。そのためには、まず全社が理解する主要なビジネス指標の定義から始めますが、その指標に反映される変数群も特定することになります。企業内の機能はさまざまな成功指標に基づいて測定されることが多いため、これは思ったよりはるかに困難です。 一貫性を保つには、企業全体が説明責任を持ち可視性もある主要な成果指標をいくつか作成します。次に、全体の成果に直接影響する機能ごとに、それらをより小さな指標に分解します。単に「できること」を測定するのではなく、「すべきこと」を測定してください。重要なのは、この指標のリストを短くすることです。それらを特定したら、共通の定義について合意し、全員がそれを理解していることを確認します。一貫性、正確性、およびそれらに関する教育を確保するための継続的なメカニズムを構築することが重要です。 まとめると、データドリブンカルチャーがうまくいくのは、上級管理職が関与し、中間管理職に権限が与えられ、現場従業員が活性化され、サイロが排除されたときです。データドリブンカルチャーは、客観性、透明性、そして革新性をもたらすため、楽しく働ける環境です。成功している組織は、データドリブンカルチャーを大規模に推進することで、データを市場における差別化要因とし、社内を統合しています。 — Ishit Twitter | LinkedIn | Blogs | Email このトピックについてさらに知りたい How to Build Data Capabilities , Ishit Vachhrajani In Search of Silver Bullets: Moving Beyond Dreaming of Data , Phil Le-Brun The CFO as Catalyst for the Data-Driven Enterprise , AWS Executive Insights The Power of the Data-Driven Enterprise , AWS Executive Insights Ishit Vachhrajani Ishit は、大企業の元 CXO と上級管理職で構成されるエンタープライズストラテジストのグローバルチームを率いています。エンタープライズストラテジストは、世界の大手企業の経営陣と提携して、クラウドによってスピードと俊敏性を高め、イノベーションを推進し、新しい運用モデルを形成する能力により、顧客のニーズにより多くの時間を費やすことができることを理解できるよう支援しています。AWS に入社する前、Ishit は A+E Networks の最高技術責任者として、クラウド、アーキテクチャ、アプリケーションと製品、データ分析、技術運用、サイバーセキュリティにわたるグローバルテクノロジーを担当していました。Ishitは、オペレーションコストを大幅に削減しながら、クラウドへの移行、アジリティ向上のための再編成、統一されたグローバルファイナンスシステムの実装、業界をリードするデータ分析プラットフォームの構築、グローバルなコンテンツ販売および広告販売製品の刷新など、A+E における大きな変革を主導しました。彼は以前、NBCUniversalおよびグローバルコンサルティング組織でリーダーシップポジションを歴任してきました。Ishit は、A+E Networks の「Create Great」と呼ばれる CEO 賞を含むいくつかの賞を受賞しています。彼は次世代のリーダーの指導に情熱を注いでおり、多くのピア・アドバイザリー・グループに参加しています。Ishit は、インドのニルマ工科大学で計装制御工学の学士号を取得し、学業成績により金メダルを獲得しました。 この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました (オリジナルは こちら 。)

みなさんこんにちは！ソリューションアーキテクトの多田です。 暑い夏がやってきましたね。皆様それぞれの夏を過ごされているかと思いますが、夏の暑さも吹き飛ばす、ホットなイベント AWS Builders Online Series が2024年7月18日(木) に開催されます。 >> AWS Builders Online Series のお申込みはコチラ AWS Builders Online Series はどんなイベント？ AWS Builders Online Series は、初心者を対象とした AWS の基礎を幅広く学ぶことができるオンラインイベントです。「初学者を対象とした」と書きましたが、既に AWS をご利用のお客様も、最新情報を取り入れ基礎から解説いたしますので、これまで触れたことのないサービスのキャッチアップにもってこいだと考えています。 今回の AWS Builders Online Series では、AWS 基礎、生成 AI、モダンアプリケーション開発の 3 つのテーマにフォーカスし、ゼロから学べるよう構成いたしました。デモを交えた分かりやすい説明により、すぐに実践に役立つ知識を習得していただきます。本イベントは、全てのセッションがライブ配信され、リアルタイムで皆様の質問に回答します。 モダンアプリケーション開発の基礎 7月1日からテーマごとに「 AWS 基礎 」「 生成 AI 実践入門 」とリレー形式で紹介しており、本記事では、 「モダンアプリケーション開発の基礎」 の5つのセッションについて紹介いたします！ 「モダンアプリケーション開発の基礎」のテーマは、コンテナ、サーバーレス、オブザーバビリティ、Webアプリ開発、SaaS の全 5 セッションで構成されております。モダンアプリケーション開発が必要とされる背景、そして各技術が解決する課題を理解することができます。説明パートに加えて、デモパートもご用意しているため、実際の画面を見ながら理解を深めやすい構成になっております。それでは各セッションの見どころをご紹介していきます。 14:40 – 15:10 BOS-08: はじめてのコンテナワークロード – AWS でのコンテナ活用の第一歩 概要: コンテナを使ったアプリケーション開発が注目されています。しかし、コンテナのメリットがいまいちわからない、使い方がわからないという方も多いのではないでしょうか。このセッションでは、コンテナの基本的な概念とメリットを解説した後、AWS 上のコンテナサービスの概要を説明します。デモを交えて紹介するため、コンテナ初心者の方でも AWS 上でのコンテナ利用イメージが掴めるはずです。（学べるサービス: Amazon ECS, Amazon EKS, AWS App Runner, Amazon ECR, AWS Fargate） 本セッションは以下のような方々に特におすすめとなっております。 コンテナに興味がある方 これからコンテナワークロードの構築を始める方 15:20 – 15:50 BOS-09: はじめてのサーバーレス – AWS Lambda でサーバーレスアプリケーション開発 概要: サーバーレスでは、サーバーを管理しなくてもアプリケーションを構築して実行できます。このセッションでは、AWS におけるサーバーレスアプリケーションを開発する方法をご紹介します。サーバーレスが小規模から始めて機能をすばやく追加できる方法をご覧ください。AWS Lambda、Amazon API Gateway、Amazon DynamoDB といったサーバーレスアプリケーションを開発するのに役立つ AWS サービスを紹介します。 本セッションは以下のような方々に特におすすめとなっております。 サーバーレスに興味のある方 サーバーレスという言葉を聞いたことがあるけれど何から始めれば良いのかわからない方 これからモダンなAWSの使い方へシフトしていきたいと考えている方 16:00 – 16:30 BOS-10: AWS ではじめるオブザーバビリティ – システムのどこで・何が・なぜ起こってるのかを理解する 概要: アプリケーションの障害や運用上の問題に直面した場合、ユーザに影響が及ぶ前に、迅速に問題を解決することが重要です。マイクロサービスなどの分散型アプリケーションの場合は構成が複雑化し、迅速な問題解決がさらに困難になります。本セッションではこのような複雑化するアプリケーションに対しても、システムの動作状況、パフォーマンス、健全性に関する洞察を得るために重要なオブザーバビリティの概要を解説した上で、AWS でオブザーバビリティをはじめる第一歩として Amazon CloudWatch や AWS X-Ray の活用方法をご紹介します。(学べるサービス: Amazon CloudWatch, AWS X-Ray) 本セッションは以下のような方々に特におすすめとなっております。 オブザーバビリティに興味のある方 アプリケーションの開発・運用に関わる方 これからAWSサービスを利用したオブザーバビリティの実践に取り組む方 16:40 – 17:10 BOS-11: AWS Amplify ではじめる Web アプリケーション開発 概要: Web アプリケーション開発では、実際にユーザーが触れる部分の開発以外にも、認証やストレージ、ホスティング、CI/CD など考慮しなければいけない要素が多岐にわたります。AWS Amplify はそういったバックエンド要素を統合できるサービスとなっており、AWS Amplify を活用することで効率的に環境を構築し開発に集中することができるようになります。本セッションでは、Web アプリケーション開発のプロセスを整理した上で AWS Amplify の概要や最新情報、活用方法についてご紹介します。(学べるサービス: AWS Amplify) 本セッションは以下のような方々に特におすすめとなっております。 開発を始めたばかりの開発者の方 開発に携わるプロダクトマネージャーやデザイナーの方 Web アプリケーションの開発方法や課題を再認識したい方 AWS Amplify に興味のある方 17:20 – 17:50 BOS-12: SaaS ビジネスモデルの理解と、AWS を用いたサービス価値向上のアプローチ 〜生成 AI に触れて〜 概要: Software as a Service (SaaS) とは、ソフトウェアの配信モデルであり、ビジネスモデルです。配信モデルに関しては、ブラウザからインターネット越しで利用できことを考えると想像しやすいかもしれないですが、ビジネスモデルと呼ばれるのはどのような点にあるのでしょうか？本セッションでは、SaaS というビジネスモデルの理解と、生成 AI がどのように SaaS にどのような価値をもたらすのかについて、ユースケースを交えながら説明したいと思います。(学べるサービス: SaaS 一般, Amazon Bedrock) 本セッションは以下のような方々に特におすすめとなっております。 SaaS に興味がある方 SaaS プロダクトの成長を考えている方 まとめ AWS Builders Online Series の「モダンアプリケーション開発の基礎」セッションについて見どころをご紹介してきました。コンテナ、サーバーレス、オブザーバビリティ、Webアプリ開発、SaaS とこれから AWS を始める方、最近始めたという方を中心に、お役に立つ内容がまとまっておりますのでぜひご覧いただけると幸いです。 >> AWS Builders Online Series のお申込みはコチラ このブログの筆者 多田　慎也 (Shinya Tada) ソリューションアーキテクト

組織は、広大なグローバルサプライチェーンを横断してサステナビリティコンプライアンスを維持するという複雑な課題に直面しています。従来の電子メールやバラバラなメッセージングツールを使用して、世界中のサプライヤーからデータを収集し、そのデータの正確性を監査することは非効率で間違いが発生しやすいです。組織が現代のサプライチェーン環境の中で舵取りする際、デジタルと物理的な変革を受け入れることは、レジリエンスを高め、コストを最適化し、持続可能な成長を促進するために不可欠です。また、サステナビリティの規制準拠と報告の要件に対応しつつ、既存のデータ収集プロセスを改善する必要があります。AWS データセンターハードウェアの規制コンプライアンスを検証する責任を負う Amazon の Global Trade and Product Compliance (GTPC) チームは、 AWS Supply Chain Sustainability を活用することで大きな成功を収めています。取引先とのやり取りが改善され、データ収集プロセスが合理化され、詳細なデータ要求コンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 現在の電子メールとマニュアルのアプローチには、以下のような課題があります。 データセキュリティの脆弱性：要件を守らないと、機密データが漏洩するリスクがあります。 分断された調整業務：別々のチームメンバーがサプライヤーからデータを要求すると、重複した要求、見落とされた要求、遅延した応答、非効率的な作業分担が発生します。 分断されたコミュニケーション：メールのスレッドでは、文書要求に関する一貫した会話を維持することが困難で、誤解とデータ取得の遅延が生じます。 メトリクスの欠如：文書収集の進捗状況やサプライヤーの応答時間などのメトリクスを追跡できないため、パフォーマンスの監視とプロセス改善が阻害されます。 AWS Supply Chain Sustainability は、すべてのサプライヤーおよび取引先から ESG データを要求、収集、監査するプロセスを簡素化します。製品ライフサイクルアセスメント、製品安全基準の証明書、使用される有害物質に関する報告書などの詳細情報を要求するデータ収集フォームを簡単に配布できます。サプライヤーがフォームに記入すると、その回答がセキュアで監査可能なリポジトリに収集されます。この合理化されたアプローチにより、メールスレッドやファイルフォルダに散在する規制対応データの課題が解消されます。排出量、材料、その他の規制データを集中化された場所でアクセスでき、レポート作成、監査、分析が効率化されます。 この集中型モデルは、データ保護を強化し、冗長なデータを排除し、柔軟なワークロード割り当てを可能にします。構造化されたコミュニケーションを促進して遅延を減らし、データ主導の最適化のための広範囲にわたる追跡を可能にします。AWS Supply Chain は、分断されたデータとプロセスを統一することで、信頼できる唯一の情報源を提供し、可視性、コラボレーション、および業務効率を向上させます。メール主導のプロセスを集中型のデータ収集と報告の仕組みに置き換えることで、運用効率、コンプライアンス順守、協力会社との関係を改善し、相互の成長と成功のためのエコシステムを育成します。 このブログ投稿では、GTPC が AWS Supply Chain Sustainability を導入して、サステナビリティコンプライアンス成果物の収集プロセスを改善した方法を説明し、この解決策の使用方法について順を追ったガイドを提供しています。 Amazon GTPC は大幅な手作業を排除 GTPC チームは、規制コンプライアンスのために AWS データセンターのハードウェアを検証し、サプライヤーおよびテストラボと協力して必須ドキュメントを収集しています。通常、数千件のコンプライアンス成果物を収集し、その数は年々大幅に増加すると予想されています。GTPC チームは AWS Supply Chain Sustainability を活用し大きな成功を収めています。 「GTPC は AWS Supply Chain Sustainability モジュールを使用して、AWS サプライヤーからのコンプライアンス成果物の収集を管理し、監査履歴を保持しています。Sustainability モジュールは効率的でユーザーフレンドリーなツールで、パートナーとの重複した連絡やデータリクエストを回避し、要求の最新状況を全チームに提供できます。さらに、サプライヤーは必要なすべてのコンプライアンス成果物を１つの画面で確認できるため、サプライヤーエクスペリエンスも向上します。」GTPC のシニアマネージャー、 Nishant Jain の言葉です。 取引先とのやり取りの改善、データ収集プロセスの合理化、詳細なデータ要求のコンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 GTPC が AWS Supply Chain Sustainability を成功裏に導入したことは、コンプライアンスデータ収集の合理化、サプライヤーとの協力関係の強化、業務効率の向上において、この製品の有効性を示しています。これらの魅力的な利点により、自社のサステナビリティ報告とコンプライアンス要件に対して AWS Supply Chain Sustainability を採用することで、GTPC と同様の成功を収めることができます。 次のセクションでは、AWS Supply Chain Sustainability のセットアップと使用開始の手順を説明し、サステナビリティデータ管理プロセスを変革する方法を順を追って紹介します。 前提条件 このブログ投稿では、あなたが前述のサービスの使用を理解しており、次の前提条件を満たしていることを前提としています: Amazon Web Services, Inc. (AWS) のアカウントをお持ちです。アカウントをお持ちでない場合は、 アカウント有効化ガイド に記載されている手順に従ってください。 AWS Supply Chain のアカウントも必要になります。まだお客様でない場合は、 AWS Supply Chain のウェブサイトをご覧いただき、詳細をご確認の上、サインアップしてください。 AWS Supply Chain Sustainability を活用してコンプライアンスを合理化 分かりやすくするため、このブログでは AWS Supply Chain Sustainability を利用する２種類のユーザータイプに言及しています。 要求者 とは、このケースでは GTPC のように、コンプライアンス文書プロセスを管理する担当者のことです。 パートナー とは、要求者から文書要求を完了する必要のある部品、材料、または商品を提供するサプライヤーやベンダーのことです。以下のセクションでは、要求者とパートナーの両方の役割について、定義されたユーザーエクスペリエンスと設定を概説しています。 サステナビリティダッシュボードは、要求者が取引先のオンボーディングおよびあらゆる成果物データリクエストの状況を確認できるメイン画面です。次のスクリーンショットにサンプルのダッシュボードが表示されています。 最初のページには、 Getting Started の概要と、主要な導入指標を含む Partner Overview セクションが含まれています。 Onboarding metrics は、段階別の取引先の参加状況を要約しています。 Data requests は、成果物収集リクエストの状況を要約しています。サンプルのスクリーンショットでは、リクエスト組織の取引先参加成功率は 38%、成果物データリクエストの回答率は 30%です。これにより、要求者は取引先の参加とリクエストのフォローアップ活動を優先付けすることができます。 要求者は、コンプライアンスレポート文書を要求するために、３つのステップに従います: 1) 取引先を招待する、2) 成果物データを要求する、3) 取引先の回答を確認する。 要求者のインタラクションおよびプロセス ステップ１: 取引先を招待する 要求者側では、取引先を 2 つの方法で追加できます。パートナー概要画面に直接情報を入力することで、取引先情報を手動で追加できます。また、取引先の情報が外部のサプライチェーン管理システムで管理されている場合は、サプライチェーンデータレイク (SCDL) に取引先の情報を取り込むこともできます。これらのオプションにより、新規および既存の取引先を柔軟に追加できます。追加後、取引先に対して成果物データリクエストを行うために、取引先を招待する必要があります。招待プロセスでは、取引先が AWS Supply Chain を通じた双方向通信を承認することを確認します。これにより、取引先のビジネスワークフローを簡素化した管理が可能になり、取引先が成果物収集リクエストを表示して応答するために必要となります。取引先の招待画面を以下に示します。 ステップ２: データリクエストを作成する 要求者側では、次のスクリーンショットに示すように、取引相手に送信するデータリクエストのタイプを選択できます。シンプルなレポートテンプレートを選択するか、前回のデータリクエストで保存したテンプレートを使用できます。データリクエストのタイプを選択すると、リクエスト名、説明、データリクエストの詳細などの主要なレポートパラメータを入力する必要があります。また、レスポンス形式を設定したり、取引相手に従ってもらう詳細なガイダンスの提供もできます。 ステップ３:取引先の回答を確認する 要求者としては、「サステナビリティ」ページの Data Request の下に、開始されたすべてのデータリクエストとその主要なマイルストーンを確認できます。次のスクリーンショットに示されています。リンクをクリックすると、特定のデータリクエストを選択し、取引先の提出内容を確認できます。成果物の有効性、リクエストの完全性を評価したり、追加のリクエストを行ったり、アプリケーションから直接追加情報を要求できます。 取引先のインタラクションおよびプロセス 次のセクションでは、取引先の役割とアプリケーションとの対話について説明します。取引先は、成果物収集リクエストに対して２つのステップで対応できます。 1) 要求者の招待を確認して承認する、2) データリクエストを確認して応答する。 ステップ１: 要求者の招待を確認して承認する 取引先として、AWS Supply Chain に参加し、データ収集の共同作業のための要求者の招待を受け入れるためのメールを受け取ります。その後、オンボーディングプロセスを完了することで、プロフィールを設定できます。オンボーディングが完了し、共同作業の招待を受け入れると、要求者に通知されます。要求者はデータ収集要求を送信できるようになります。 ステップ２: データリクエストを確認して応答する 取引先として、完了する必要があるすべてのデータリクエストの概要を示すダイジェストメールを受け取ります。次に、メールのリンクをクリックすると、成果物データリクエスト画面に接続され、保留中のリクエストをすべて表示できます。下図のように、成果物データリクエストページに直接移動して、オープンデータリクエストを表示し、必要な情報を提供できます。リクエストを拒否し、該当する理由コードの文書化もできます。要求者は、データリクエスト送信を確認し、すべての応答が完了した場合はワークフローを終了します。 サステナビリティのセットアップと構成に関する追加情報と詳細は、AWS Supply Chain ユーザーガイド に記載されています。 AWS Supply Chain Sustainability は、GTPC の課題に対処するために以下の利点を提供しました。 シームレスなコミュニケーション： AWS Supply Chain により、GTPC とそのサプライヤーおよび取引先間のシームレスなコミュニケーションが可能になり、深い対話とタイムリーな対応が可能になりました。 可視性の向上： GTPC は作業の重複を最小限に抑え、リソースの活用を最大化することで、ワークフロー内で時間を節約することができました。この可視性により、透明性と説明責任が向上し、持続可能な実践の改善案が特定され、規制の非準拠リスクが軽減されました。 監査可能なコミュニケーション：AWS Supply Chain により、GTPC とその取引先間の監査可能なコミュニケーションが容易になり、やり取りと交換の明確な記録が確保されました。 セキュリティコンプライアンスの改善： AWS Supply Chain は、アプリケーションを通じて重要な成果物の交換を効果的に簡素化し、データを安全かつ確実に転送する方法を提供しました。GTPC はデータの監査可能な記録を持ち、データ収集と検証プロセスの前例のない可視性を獲得しました。 パフォーマンス追跡：GTPC は成果物収集の進捗状況とサプライヤーの応答時間を追跡し、必要に応じてデータ要求を調整することができました。このようなプロセスの可視性と制御により、GTPC は規制コンプライアンスの進捗に影響を与える可能性のある取引先ネットワークの変更、課題、問題を認識することができました。 まとめ 消費者や規制当局が透明性と説明責任を求める中、組織は自社の事業活動とサプライチェーンにわたり、正確かつ包括的なサステナビリティデータを収集する圧力が高まっています。取引先ネットワークから信頼できるデータを入手することは、意味のある分析し、戦略的な意思決定に役立て、進化するサステナビリティ基準とコンプライアンスに準拠するために不可欠です。しかし、多くの企業は非効率的な手作業のプロセスとバラバラなデータソースに苦しんでいます。 AWS Supply Sustainability を活用することで、Amazon の Global Trade and Product Compliance (GTPC) チームは、コンプライアンスデータ収集プロセスを合理化することに成功しました。毎年数千の成果物を収集する責任がある GTPC は、集中型の自動化ソリューションを採用することで、業務効率の大幅な改善を実現しました。取引先とのやり取りの改善、データ収集の合理化、詳細なコンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 GTPC の成功は、AWS Supply Chain Sustainability がサステナビリティデータ管理プロセスに変革的な影響を与えることを示しています。この解決策の中央集権的アプローチは、散在するデータ、分断された通信、可視性の欠如に関連する課題を排除し、同時にサプライヤーとの協力と運用効率を向上させます。これらの魅力的な利点により、サステナビリティ報告およびコンプライアンス要件に対して AWS Supply Chain Sustainability を採用することで、同様の改善を推進できます。 AWS Supply Chain を訪問して、持続可能なビジネス慣行を通じた相互の成長と成功を促進するエコシステムの詳細を学びましょう。 <!-- '"` --> 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Shree Vivek Selvaraj は、AWS Supply Chain のシニアスペシャリストソリューションアーキテクトです。彼の役割は、サプライチェーン幹部と技術アーキテクトと協力し、顧客の問題を理解し、意図したビジネス成果を達成するための適切なソリューションを提案することです。彼は、重工業、バイオ製薬、ハイテク、小売りEコマースなど、フォーチュン500企業の幅広い業界で、オペレーション、サプライチェーン、リーン &amp; シックスシグマ、コア製品管理を通じて14年以上の業界経験を持っています。Shree はグレーターオースティンエリアに拠点を置いています。

組織は、広大なグローバルサプライチェーンを横断してサステナビリティコンプライアンスを維持するという複雑な課題に直面しています。従来の電子メールやバラバラなメッセージングツールを使用して、世界中のサプライヤーからデータを収集し、そのデータの正確性を監査することは非効率で間違いが発生しやすいです。組織が現代のサプライチェーン環境の中で舵取りする際、デジタルと物理的な変革を受け入れることは、レジリエンスを高め、コストを最適化し、持続可能な成長を促進するために不可欠です。また、サステナビリティの規制準拠と報告の要件に対応しつつ、既存のデータ収集プロセスを改善する必要があります。AWS データセンターハードウェアの規制コンプライアンスを検証する責任を負う Amazon の Global Trade and Product Compliance (GTPC) チームは、 AWS Supply Chain Sustainability を活用することで大きな成功を収めています。取引先とのやり取りが改善され、データ収集プロセスが合理化され、詳細なデータ要求コンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 現在の電子メールとマニュアルのアプローチには、以下のような課題があります。 データセキュリティの脆弱性：要件を守らないと、機密データが漏洩するリスクがあります。 分断された調整業務：別々のチームメンバーがサプライヤーからデータを要求すると、重複した要求、見落とされた要求、遅延した応答、非効率的な作業分担が発生します。 分断されたコミュニケーション：メールのスレッドでは、文書要求に関する一貫した会話を維持することが困難で、誤解とデータ取得の遅延が生じます。 メトリクスの欠如：文書収集の進捗状況やサプライヤーの応答時間などのメトリクスを追跡できないため、パフォーマンスの監視とプロセス改善が阻害されます。 AWS Supply Chain Sustainability は、すべてのサプライヤーおよび取引先から ESG データを要求、収集、監査するプロセスを簡素化します。製品ライフサイクルアセスメント、製品安全基準の証明書、使用される有害物質に関する報告書などの詳細情報を要求するデータ収集フォームを簡単に配布できます。サプライヤーがフォームに記入すると、その回答がセキュアで監査可能なリポジトリに収集されます。この合理化されたアプローチにより、メールスレッドやファイルフォルダに散在する規制対応データの課題が解消されます。排出量、材料、その他の規制データを集中化された場所でアクセスでき、レポート作成、監査、分析が効率化されます。 この集中型モデルは、データ保護を強化し、冗長なデータを排除し、柔軟なワークロード割り当てを可能にします。構造化されたコミュニケーションを促進して遅延を減らし、データ主導の最適化のための広範囲にわたる追跡を可能にします。AWS Supply Chain は、分断されたデータとプロセスを統一することで、信頼できる唯一の情報源を提供し、可視性、コラボレーション、および業務効率を向上させます。メール主導のプロセスを集中型のデータ収集と報告の仕組みに置き換えることで、運用効率、コンプライアンス順守、協力会社との関係を改善し、相互の成長と成功のためのエコシステムを育成します。 このブログ投稿では、GTPC が AWS Supply Chain Sustainability を導入して、サステナビリティコンプライアンス成果物の収集プロセスを改善した方法を説明し、この解決策の使用方法について順を追ったガイドを提供しています。 Amazon GTPC は大幅な手作業を排除 GTPC チームは、規制コンプライアンスのために AWS データセンターのハードウェアを検証し、サプライヤーおよびテストラボと協力して必須ドキュメントを収集しています。通常、数千件のコンプライアンス成果物を収集し、その数は年々大幅に増加すると予想されています。GTPC チームは AWS Supply Chain Sustainability を活用し大きな成功を収めています。 「GTPC は AWS Supply Chain Sustainability モジュールを使用して、AWS サプライヤーからのコンプライアンス成果物の収集を管理し、監査履歴を保持しています。Sustainability モジュールは効率的でユーザーフレンドリーなツールで、パートナーとの重複した連絡やデータリクエストを回避し、要求の最新状況を全チームに提供できます。さらに、サプライヤーは必要なすべてのコンプライアンス成果物を１つの画面で確認できるため、サプライヤーエクスペリエンスも向上します。」GTPC のシニアマネージャー、 Nishant Jain の言葉です。 取引先とのやり取りの改善、データ収集プロセスの合理化、詳細なデータ要求のコンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 GTPC が AWS Supply Chain Sustainability を成功裏に導入したことは、コンプライアンスデータ収集の合理化、サプライヤーとの協力関係の強化、業務効率の向上において、この製品の有効性を示しています。これらの魅力的な利点により、自社のサステナビリティ報告とコンプライアンス要件に対して AWS Supply Chain Sustainability を採用することで、GTPC と同様の成功を収めることができます。 次のセクションでは、AWS Supply Chain Sustainability のセットアップと使用開始の手順を説明し、サステナビリティデータ管理プロセスを変革する方法を順を追って紹介します。 前提条件 このブログ投稿では、あなたが前述のサービスの使用を理解しており、次の前提条件を満たしていることを前提としています: Amazon Web Services, Inc. (AWS) のアカウントをお持ちです。アカウントをお持ちでない場合は、 アカウント有効化ガイド に記載されている手順に従ってください。 AWS Supply Chain のアカウントも必要になります。まだお客様でない場合は、 AWS Supply Chain のウェブサイトをご覧いただき、詳細をご確認の上、サインアップしてください。 AWS Supply Chain Sustainability を活用してコンプライアンスを合理化 分かりやすくするため、このブログでは AWS Supply Chain Sustainability を利用する２種類のユーザータイプに言及しています。 要求者 とは、このケースでは GTPC のように、コンプライアンス文書プロセスを管理する担当者のことです。 パートナー とは、要求者から文書要求を完了する必要のある部品、材料、または商品を提供するサプライヤーやベンダーのことです。以下のセクションでは、要求者とパートナーの両方の役割について、定義されたユーザーエクスペリエンスと設定を概説しています。 サステナビリティダッシュボードは、要求者が取引先のオンボーディングおよびあらゆる成果物データリクエストの状況を確認できるメイン画面です。次のスクリーンショットにサンプルのダッシュボードが表示されています。 最初のページには、 Getting Started の概要と、主要な導入指標を含む Partner Overview セクションが含まれています。 Onboarding metrics は、段階別の取引先の参加状況を要約しています。 Data requests は、成果物収集リクエストの状況を要約しています。サンプルのスクリーンショットでは、リクエスト組織の取引先参加成功率は 38%、成果物データリクエストの回答率は 30%です。これにより、要求者は取引先の参加とリクエストのフォローアップ活動を優先付けすることができます。 要求者は、コンプライアンスレポート文書を要求するために、３つのステップに従います: 1) 取引先を招待する、2) 成果物データを要求する、3) 取引先の回答を確認する。 要求者のインタラクションおよびプロセス ステップ１: 取引先を招待する 要求者側では、取引先を 2 つの方法で追加できます。パートナー概要画面に直接情報を入力することで、取引先情報を手動で追加できます。また、取引先の情報が外部のサプライチェーン管理システムで管理されている場合は、サプライチェーンデータレイク (SCDL) に取引先の情報を取り込むこともできます。これらのオプションにより、新規および既存の取引先を柔軟に追加できます。追加後、取引先に対して成果物データリクエストを行うために、取引先を招待する必要があります。招待プロセスでは、取引先が AWS Supply Chain を通じた双方向通信を承認することを確認します。これにより、取引先のビジネスワークフローを簡素化した管理が可能になり、取引先が成果物収集リクエストを表示して応答するために必要となります。取引先の招待画面を以下に示します。 ステップ２: データリクエストを作成する 要求者側では、次のスクリーンショットに示すように、取引相手に送信するデータリクエストのタイプを選択できます。シンプルなレポートテンプレートを選択するか、前回のデータリクエストで保存したテンプレートを使用できます。データリクエストのタイプを選択すると、リクエスト名、説明、データリクエストの詳細などの主要なレポートパラメータを入力する必要があります。また、レスポンス形式を設定したり、取引相手に従ってもらう詳細なガイダンスの提供もできます。 ステップ３:取引先の回答を確認する 要求者としては、「サステナビリティ」ページの Data Request の下に、開始されたすべてのデータリクエストとその主要なマイルストーンを確認できます。次のスクリーンショットに示されています。リンクをクリックすると、特定のデータリクエストを選択し、取引先の提出内容を確認できます。成果物の有効性、リクエストの完全性を評価したり、追加のリクエストを行ったり、アプリケーションから直接追加情報を要求できます。 取引先のインタラクションおよびプロセス 次のセクションでは、取引先の役割とアプリケーションとの対話について説明します。取引先は、成果物収集リクエストに対して２つのステップで対応できます。 1) 要求者の招待を確認して承認する、2) データリクエストを確認して応答する。 ステップ１: 要求者の招待を確認して承認する 取引先として、AWS Supply Chain に参加し、データ収集の共同作業のための要求者の招待を受け入れるためのメールを受け取ります。その後、オンボーディングプロセスを完了することで、プロフィールを設定できます。オンボーディングが完了し、共同作業の招待を受け入れると、要求者に通知されます。要求者はデータ収集要求を送信できるようになります。 ステップ２: データリクエストを確認して応答する 取引先として、完了する必要があるすべてのデータリクエストの概要を示すダイジェストメールを受け取ります。次に、メールのリンクをクリックすると、成果物データリクエスト画面に接続され、保留中のリクエストをすべて表示できます。下図のように、成果物データリクエストページに直接移動して、オープンデータリクエストを表示し、必要な情報を提供できます。リクエストを拒否し、該当する理由コードの文書化もできます。要求者は、データリクエスト送信を確認し、すべての応答が完了した場合はワークフローを終了します。 サステナビリティのセットアップと構成に関する追加情報と詳細は、AWS Supply Chain ユーザーガイド に記載されています。 AWS Supply Chain Sustainability は、GTPC の課題に対処するために以下の利点を提供しました。 シームレスなコミュニケーション： AWS Supply Chain により、GTPC とそのサプライヤーおよび取引先間のシームレスなコミュニケーションが可能になり、深い対話とタイムリーな対応が可能になりました。 可視性の向上： GTPC は作業の重複を最小限に抑え、リソースの活用を最大化することで、ワークフロー内で時間を節約することができました。この可視性により、透明性と説明責任が向上し、持続可能な実践の改善案が特定され、規制の非準拠リスクが軽減されました。 監査可能なコミュニケーション：AWS Supply Chain により、GTPC とその取引先間の監査可能なコミュニケーションが容易になり、やり取りと交換の明確な記録が確保されました。 セキュリティコンプライアンスの改善： AWS Supply Chain は、アプリケーションを通じて重要な成果物の交換を効果的に簡素化し、データを安全かつ確実に転送する方法を提供しました。GTPC はデータの監査可能な記録を持ち、データ収集と検証プロセスの前例のない可視性を獲得しました。 パフォーマンス追跡：GTPC は成果物収集の進捗状況とサプライヤーの応答時間を追跡し、必要に応じてデータ要求を調整することができました。このようなプロセスの可視性と制御により、GTPC は規制コンプライアンスの進捗に影響を与える可能性のある取引先ネットワークの変更、課題、問題を認識することができました。 まとめ 消費者や規制当局が透明性と説明責任を求める中、組織は自社の事業活動とサプライチェーンにわたり、正確かつ包括的なサステナビリティデータを収集する圧力が高まっています。取引先ネットワークから信頼できるデータを入手することは、意味のある分析をし、戦略的な意思決定に役立て、進化するサステナビリティ基準とコンプライアンスに準拠するために不可欠です。しかし、多くの企業は非効率的な手作業のプロセスとバラバラなデータソースに苦しんでいます。 AWS Supply Sustainability を活用することで、Amazon の Global Trade and Product Compliance (GTPC) チームは、コンプライアンスデータ収集プロセスを合理化することに成功しました。毎年数千の成果物を収集する責任がある GTPC は、集中型の自動化ソリューションを採用することで、業務効率の大幅な改善を実現しました。取引先とのやり取りの改善、データ収集の合理化、詳細なコンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 GTPC の成功は、AWS Supply Chain Sustainability がサステナビリティデータ管理プロセスに変革的な影響を与えることを示しています。この解決策の中央集権的アプローチは、散在するデータ、分断された通信、可視性の欠如に関連する課題を排除し、同時にサプライヤーとの協力と運用効率を向上させます。これらの魅力的な利点により、サステナビリティ報告およびコンプライアンス要件に対して AWS Supply Chain Sustainability を採用することで、同様の改善を推進できます。 AWS Supply Chain を訪問して、持続可能なビジネス慣行を通じた相互の成長と成功を促進するエコシステムの詳細を学びましょう。 <!-- '"` --> 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Shree Vivek Selvaraj は、AWS Supply Chain のシニアスペシャリストソリューションアーキテクトです。彼の役割は、サプライチェーン幹部と技術アーキテクトと協力し、顧客の問題を理解し、意図したビジネス成果を達成するための適切なソリューションを提案することです。彼は、重工業、バイオ製薬、ハイテク、小売りEコマースなど、フォーチュン 500 企業の幅広い業界で、オペレーション、サプライチェーン、リーン &amp; シックスシグマ、コア製品管理を通じて14年以上の業界経験を持っています。Shree はグレーターオースティンエリアに拠点を置いています。

本稿では株式会社NTTドコモ（以下、DOCOMO）において、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は 導入事例ページ もご覧ください。 全４回の内容は以下からアクセスできますので、ご興味のある回をご覧いただければ幸いです。 第一回　適切なデータストアの選定とアーキテクチャの見直し 第二回　アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜 第三回　クラウドを活用したテスト効率化 〜リリース前・リリース後に何をするべきか〜 第四回　AWSでのライブ配信アーキテクチャ 第四回　AWSでのライブ配信アーキテクチャ 1.はじめに 第四回では、Lemino のライブ配信について、配信基盤を AWS Media Services やマネージドサービスで再構築について説明します。新たな映像配信基盤は、ボクシングの世界戦など注目度の高いライブ配信を支え、ユーザーの獲得に貢献し、アクティブユーザー数（MAU）は、サービス開始から 3 か月で約 7 倍の 500 万に達しました。 2.基本的な配信基盤のアーキテクチャ Lemino では、VOD の配信だけでなく多種多様なライブ配信を複数同時に実施することが可能です。ライブ配信の最大チャンネル起動実績も 30 に達し、2024 年には最大 50 チャンネルまで拡張する予定で、ライブ配信の規模はさらに拡大する見込みです。 これを可能にしているのは、 AWS Media Services です。 Lemino の担当者が初めて AWS Media Service に触れたのは、約4年前のハンズオンがきっかけです。２日間のハンズオンで一通りの配信に必要なクラウドのマネージドサービスを学び、そこからオンプレミスで培った映像の技術を用いて、大規模な配信に耐える構成を作り上げてきました。(参考ハンズオン： AWSで動画配信を始めよう ) AWS Media Services では、Multi-AZ による冗長化された信頼性の高いサービスをソフトウェア、ハードウェアの管理をすることなく、マネージドサービスで活用することができます。従量課金体系であるため、ライブ配信毎にチャンネルを新規作成しライブ終了後に削除することで、ライブ配信時以外の料金発生を抑え費用を最小限に抑えることが可能です。加えて、東京リージョン・大阪リージョン・ソウルリージョンで同じAWSのマネージメントコンソールや CLI などを使って、配信の環境を整えることができるため、マルチリージョン構成を容易に実現することができます。 こうした可用性の設計は Reference architecture についての AWS Blog が用意されているため、参考に設計しています。 Lemino では、iPhone や Android スマートフォンや、タブレット、パソコン、スマートテレビ・レコーダーなど様々な機種に対応しておりますが、これに対応するには、Apple HLS 、DASH-ISO などの形式で出力し、適切な DRM 設定を行う必要があります。DRM についても Secure Packager and Encoder Key Exchange (SPEKE) を活用して利用できます。 参考： SPEKEとは？ 配信の内容によっては、タイムシフト表示を有効化したり Live コンテンツをアーカイブ配信のために、VOD に変換する必要があります。 AWS Elemental MediaPackage はこうした必要な機能をサポートし、ボクシングの世界戦のような大規模配信でもオリジンとして機能するスケーラビリティを持っています。 リアルタイムエンコーダは AWS Elemental MediaLive を活用して配信仕様に従ったビデオ・オーディオのエンコード出力を行っています。MediaLive は Amazon S3 に事前に保存された MP4 などの形式の映像ファイルからの配信を行うことが可能であるため、この機能を活用し擬似ライブのような配信にも対応しています。 また、エンコーダへの映像入力に関しては AWS Elemental MediaConnect を組み合わせて利用することで、さまざまなロケーションから安定した映像ソースの伝送を行っています。例えば、大規模なスポーツ会場から Live を配信する場合は、現地のオンプレミス機材から映像伝送を行う必要がありますが、パケットロスを防ぐため RTP+FEC や RTMP 、 Zixi など様々なプロトコルで動画を伝送する必要があります。 MediaConnect と MediaLive を利用することでこれらの映像伝送を簡単に行うことができます。 他にも、小規模な練習場のような大規模なオンプレミス機器の設置が困難な場所からクラウドに動画を配信する場合、 AWS Elemental Link という僅か 450 g の小型の専用デバイスを現地に持って行って配信に活用しています。AWS Elemental Link は電源をつなぐ、ネットワークと接続する、カメラからの映像音声を SDI あるいは HDMI で接続する、この3つだけで、AWS Elemental MediaLive に高品質な映像を伝送することが可能です。この映像伝送にはパケットロスの耐性の高い Zixi プロトコルが利用されます。動画配信の仕組みに精通したエンジニアでなくとも現地から映像を送ることができるため、エンジニアが配信都度現地に行く必要がないため、配信にかかる作業負担が大きく軽減されています。 最近の配信では、無料の広告付き配信を行っています。この配信では広告をあらかじめ映像にうめ込んだり、映像の最初に広告を入れるのではなく、Live の途中で、できるだけ試聴体験を邪魔しないように広告を入れる SSAI（Server Side Ad Insertion） によるミッドロール広告も活用を始めています。これらの広告配信は AWS Elemental MediaTailor で短期間で付け加えることができ、配信の特性ごとに一番良い方法で配信できるよう現在も調整を続けています。 Lemino では、こうした多様なライブの運用工数も最適化しています。ライブ配信の構成を AWS で統一したことで、 AWS Media Services を簡単にデプロイできる仕組みを AWS の API を使用して構築し、エンジニアが関与せずともライブ担当者のみで定型的な配信環境構築作業を実行できるようになりました。 3.配信時の CDN の構成について Lemino ではNTT DOCOMOのモバイルネットワーク・ CDN を活用しつつ、 Amazon CloudFront や他社の CDN も活用できるようにすることで、大規模配信の際に必要となる帯域を事前に調整しています。これを実現しているのが、 Amazon Route53 と Amazon CloudFront の Origin Shield です。 CDN-A / CDN-B / CDN-C を活用する場合、３つの CDN のオリジンに Origin Shield を有効化した CloudFront を活用します。そうすることで、CloudFront はすべてのオリジンフェッチを Origin Shield を介してルーティングし、コンテンツが Origin Shield のキャッシュにまだ保存されていない場合にのみオリジンにリクエストを送信します。これは、オリジンの負荷を下げることにつながり、大規模配信時もオリジンへの過負荷によって、配信に影響が出るリスクを低減します。また、 Lambda@Edge を Origin Shield とともに使用して、動的なマニュフェストの変換なども可能にしています。 エンドユーザーからのアクセスを CDN-A / CDN-B / CDN-C にどのように割り振るかを決定するのは Amazon Route53 です。 加重ルーティングを活用して普段はCDN-A 7割、CDN-B 2割、CDN-C 1割のような割合で配信しておいて、CDN-C に異常があった場合、加重の比率を変更することで、CDN の障害から回復することが可能です。また、IPベースのルーティングも併用することで、所定のIPアドレスからは所定のネットワークを経由して映像を配信し、効率的にライブ配信を行なっています。 4.まとめ 昨今の映像サービスでは、様々な場所から様々な形式で入手した映像を、多種多様なデバイスに安定して配信することが配信規模に関わらず求められます。AWSを利用することで最小限の費用と労力でこれらの実現が可能です。今後も、AWS のMedia Servicesの新機能もうまく活用しつつ、Lemino の配信をよりよくする挑戦を続けていきます。 著者について 株式会社NTTドコモ 第一プロダクトデザイン部 映像サービス担当　岸 里奈 株式会社NTTドコモで提供している映像配信サービス『Lemino』のライブ・VOD・広告含めた映像配信システムの開発を担当しているエンジニア。 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部　津和崎美希 通信業界のお客様を担当するソリューション アーキテクト。普段は通信業界のお客様のAWS 活用を支援していますが、Observability についてはAWS 社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Service のご支援にも手を広げるなど、幅広い AWS 活用をご支援しています。

re:Invent 2023 のニュースブログ記事 で、 Amazon S3 Express One Zone をご紹介しました。これは、最も頻繁にアクセスされるデータや、レイテンシーの影響を受けやすいアプリケーションのために、一貫した 1 桁ミリ秒のデータアクセスを提供するために特別に設計された、高性能な単一アベイラビリティーゾーン (AZ) ストレージクラスです。これは要求の厳しいアプリケーションに適しており、S3 Standard と比較して最大 10 倍優れたパフォーマンスを実現するように設計されています。S3 Express One Zone は、S3 ディレクトリバケット を使用して、単一の AZ にオブジェクトを保存します。 7月9日より、S3 Express One Zone は AWS CloudTrail データイベントログ記録をサポートするようになり、既にサポートされていた CreateBucket や DeleteBucket などの バケットレベル のアクションに加えて、 PutObject 、 GetObject 、 DeleteObject などのすべてのオブジェクトレベルのオペレーションをモニタリングできるようになりました。これにより、ガバナンスとコンプライアンスの監査が可能になり、S3 Standard ストレージクラスと比較して 50% 低い S3 Express One Zone のリクエストコストを活用できるようになります。 この新しい機能を使用すると、どの S3 Express One Zone オブジェクトが作成、読み取り、更新、または削除されたかを迅速に判断し、API コールのソースを特定できます。不正な S3 Express One Zone オブジェクトへのアクセスを検出した場合は、アクセスを制限するためにすぐにアクションを実行できます。さらに、 CloudTrail 統合 を Amazon EventBridge と併用して、データイベントによってトリガーされるルールベースのワークフローを作成することもできます。 Amazon S3 Express One Zone の CloudTrail データイベントログ記録の使用 Amazon S3 コンソール で開始します。 ディレクトリバケットの作成 のステップに従って、S3 バケットを作成し、バケットタイプとして [ディレクトリ] 、 [アベイラビリティーゾーン] として [apne1-az4] を選択します。 [ベース名] に s3express-one-zone-cloudtrail と入力すると、該当のアベイラビリティーゾーンのアベイラビリティーゾーン ID を含むサフィックスが自動的に追加され、最終的な名前が作成されます。最後に、 [データは単一のアベイラビリティーゾーンに保存されます] のチェックボックスをオンにして同意し、 [バケットを作成] を選択します。 S3 Express One Zone のデータイベントログ記録を有効にするために、 CloudTrail コンソール に移動します。名前を入力して、S3 ディレクトリバケットのイベントを追跡する CloudTrail 証跡を作成 します。 [ステップ 2: ログイベントを選択する] で、 [高度なイベントセレクターが有効になっています] が選択された状態で [データイベント] を選択します。 [データイベントタイプ] で、 [S3 Express] を選択します。すべての S3 ディレクトリバケットのデータイベントを管理するには、 [ログセレクターテンプレート] として [すべてのイベントをログに記録] を選択できます。 ただし、イベントデータストアでは、S3 ディレクトリバケット s3express-one-zone-cloudtrail--apne1-az4--x-s3 のイベントのみをログに記録したいと考えています。この場合、 [ログセレクターテンプレート] として [カスタム] を選択し、ディレクトリバケットの ARN を指定します。詳細については、「 Filtering data events by using advanced event selectors 」に関するドキュメントをご覧ください。 最後に、 [ステップ 3: 確認および作成する] に進みます。これで、CloudTrail によるログ記録が有効になりました。 S3 Express One Zone の CloudTrail データイベントログ記録の操作: S3 コンソール を使用して、S3 ディレクトリバケットにファイルをアップロードおよびダウンロードします。 AWS CLI を使用して、 Put_Object と Get_Object を送信します。 $ aws s3api put-object --bucket s3express-one-zone-cloudtrail--apne1-az4--x-s3 \ --key cloudtrail_test \ --body cloudtrail_test.txt $ aws s3api get-object --bucket s3express-one-zone-cloudtrail--apne1-az4--x-s3 \ --key cloudtrail_test response.txt CloudTrail は、ログファイルを gzip アーカイブで S3 バケットに公開し、バケット名、アカウント ID、リージョン、日付に基づいて 階層的に 整理します。AWS CLI を使用して、証跡に関連付けられたバケットを一覧表示し、テストを実行した日付のログファイルを取得します。 $ aws s3 ls s3://aws-cloudtrail-logs-MY-ACCOUNT-ID-3b49f368/AWSLogs/MY-ACCOUNT-ID/CloudTrail/ap-northeast-1/2024/07/01/ 次の 4 つのファイル名が取得されます。2 つはコンソールテストから、もう 2 つは CLI テストから取得されます: 2024-07-05 20:44:16 317 MY-ACCOUNT-ID_CloudTrail_ap-northeast-1_20240705T2044Z_lzCPfDRSf9OdkdC1.json.gz 2024-07-05 20:47:36 387 MY-ACCOUNT-ID_CloudTrail_ap-northeast-1_20240705T2047Z_95RwiqAHCIrM9rcl.json.gz 2024-07-05 21:37:48 373 MY-ACCOUNT-ID_CloudTrail_ap-northeast-1_20240705T2137Z_Xk17zhf0cTY0N5bH.json.gz 2024-07-05 21:42:44 314 MY-ACCOUNT-ID_CloudTrail_ap-northeast-1_20240705T21415Z_dhyTsSb3ZeAhU6hR.json.gz これらのファイルで PutObject イベントを検索してみましょう。最初のファイルを開くと、 PutObject イベントタイプが表示されます。ご承知のとおり、ブラウザの S3 コンソール経由で 1 回、CLI を使用して 1 回、合計 2 回のアップロードを実行したばかりです。API コールを実行したソースのタイプである userAgent 属性はブラウザを参照するため、このイベントは S3 コンソールを使用したアップロードを参照します。CloudTrail イベントの詳細については、「 Understanding CloudTrail events 」のドキュメントをご覧ください。 {...}, "eventTime": "2024-07-05T20:44:16Z", "eventSource": "s3express.amazonaws.com", "eventName": "PutObject", "awsRegion": "ap-northeast-1", "sourceIPAddress": "MY-IP", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36", "requestParameters": { ... }, "responseElements": {...}, "additionalEventData": {...}, ... "resources": [ { "type": "AWS::S3Express::Object", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3/cloudtrail_example.png" }, { "accountId": "MY-ACCOUNT-ID", "type": "AWS::S3Express::DirectoryBucket", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3" } ], {...} ここで、AWS CLI を使用して送信された PutObject コマンドに対応するイベントの 3 つ目のファイルを確認すると、 userAgent 属性にわずかな違いがあることがわかります。この場合、これは AWS CLI を参照しています。 {...}, "eventTime": "2024-07-05T21:37:19Z", "eventSource": "s3express.amazonaws.com", "eventName": "PutObject", "awsRegion": "ap-northeast-1", "sourceIPAddress": "MY-IP", "userAgent": "aws-cli/2.17.9 md/awscrt#0.20.11 ua/2.0 os/linux#5.10.218-208.862.amzn2.x86_64 md/arch#x86_64 lang/python#3.11.8 md/pyimpl#CPython cfg/retry-mode#standard md/installer#exe md/distrib#amzn.2 md/prompt#off md/command#s3api.put-object", "requestParameters": { ... }, "responseElements": {...}, "additionalEventData": {...}, ... "resources": [ { "type": "AWS::S3Express::Object", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3/cloudtrail_example.png" }, { "accountId": "MY-ACCOUNT-ID", "type": "AWS::S3Express::DirectoryBucket", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3" } ], {...} では、2 つ目のファイルの GetObject イベントを見てみましょう。イベントタイプが GetObject であり、 userAgent がブラウザを参照していることがわかります。つまり、このイベントは S3 コンソールを使用したダウンロードを参照しています。 {...}, "eventTime": "2024-07-05T20:47:41Z", "eventSource": "s3express.amazonaws.com", "eventName": "GetObject", "awsRegion": "ap-northeast-1", "sourceIPAddress": "MY-IP", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36", "requestParameters": { ... }, "responseElements": {...}, "additionalEventData": {...}, ... "resources": [ { "type": "AWS::S3Express::Object", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3/cloudtrail_example.png" }, { "accountId": "MY-ACCOUNT-ID", "type": "AWS::S3Express::DirectoryBucket", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3" } ], {...} 最後に、AWS CLI から送信した GetObject コマンドの詳細とともに、4 つ目のファイルのイベントを表示します。 eventName と userAgent が想定どおりであることがわかります。 {...}, "eventTime": "2024-07-05T21:42:04Z", "eventSource": "s3express.amazonaws.com", "eventName": "GetObject", "awsRegion": "ap-northeast-1", "sourceIPAddress": "MY-IP", "userAgent": "aws-cli/2.17.9 md/awscrt#0.20.11 ua/2.0 os/linux#5.10.218-208.862.amzn2.x86_64 md/arch#x86_64 lang/python#3.11.8 md/pyimpl#CPython cfg/retry-mode#standard md/installer#exe md/distrib#amzn.2 md/prompt#off md/command#s3api.put-object", "requestParameters": { ... }, "responseElements": {...}, "additionalEventData": {...}, ... "resources": [ { "type": "AWS::S3Express::Object", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3/cloudtrail_example.png" }, { "accountId": "MY-ACCOUNT-ID", "type": "AWS::S3Express::DirectoryBucket", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3" } ], {...} 知っておくべきこと 開始方法 – CloudTrail コンソール、CLI、または SDK を使用して、S3 Express One Zone のために CloudTrail データイベントログ記録を有効にできます。 リージョン – CloudTrail データイベントログ記録は、 S3 Express One Zone が現在利用可能なすべての AWS リージョン でご利用いただけます。 アクティビティログ記録 – S3 Express One Zone の CloudTrail データイベントログ記録を使用すると、 PutObject 、 GetObject 、 DeleteObject などのオブジェクトレベルのアクティビティや、CreateBucket や DeleteBucket などのバケットレベルのアクティビティをログ記録できます。 料金 – S3 ストレージクラスと同様に、ログ記録されたイベントの数とログを保持する期間に基づいて、CloudTrail での S3 Express One Zone データイベントのログ記録についての料金をお支払いいただきます。詳細については、 AWS CloudTrail の料金 ページをご覧ください。 S3 Express One Zone のために CloudTrail データイベントログ記録を有効にすると、高性能ストレージのガバナンスとコンプライアンスを簡素化できます。この新機能の詳細については、「 S3 ユーザーガイド 」をご覧ください。 – Eli. 原文は こちら です。

アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの 新谷です。2024 年 6 月 20 、21 日に AWS Summit Japan が開催され、 2 日間で 150 以上のセッションと 250 以上のブース展示が行われました。その中には、高い信頼性要件に対し工夫を凝らしながら耐障害性の高いワークロードを構築したお客様事例セッションもありました。また、AWS セッションや AWS Village のブース展示においても、レジリエンスに関するトピックを多数お届けしていました。本ブログでは、AWS Summit Japan 2024 よりレジリエンスに関するセッション、ブースの内容をサマリーでご紹介します。 事例セッションより 日本最大口座数を保有する SBI証券のオンライン取引システムの AWS マイグレーション 株式会社SBI証券/ SBIシンプレクス・ソリューションズ株式会社 様 日本最大の口座数を保有する SBI証券様は、新 NISA やゼロ革命 (取引手数料無料化) により拡大するトランザクションに備えて、 OMS（Order Management System） およびその関連するシステムを AWS へマイグレーションし、ビジネスの急激な拡大に対応可能なプラットフォームと顧客への継続的な安定した環境を提供することを実現されました。 AWS の SA とともに金融のベストプラクティスをリファレンスとした、低遅延かつ高い可用性と高負荷トランザクションによる高いパフォーマンス性能が求められるミッションクリティカルなシステムの移行についてお話頂きました。 Oracle Exadata の RDS for Oracle 移行によるフルクラウド化 auコマース＆ライフ株式会社 様 auコマース&amp;ライフ様は au Payマーケットのアプリケーションを AWS 移行するとともにアーキテクチャ刷新を進めていましたが、オンプレミスに残る Oracle Exadata と接続する AWS Direct Connect が単一障害点となっていました。実際にスイッチ故障により長時間停止が発生し、サービス継続性に対するリスクが顕在化したことから、オンプレミスの Oracle Exadata から Amazon RDS for Oracle (Enterprise Edition) への移行を決定しました。移行後は Performance Insights の可視化で性能改善に繋げやすくなった点や、データセンターとの通信レイテンシが低減されお客様体験向上にも繋がった点を効果として挙げています。今後は信頼性とコストのバランスを考慮しながらデータベース含めたマイクロサービス化を推進していくそうです。 AWS セッションより 金融機関様のマルチリージョン事例からクラウドのレジリエンスを紐解く AWS ソリューションアーキテクト 山北 嶺より、金融機関様のレジリエンス事例と技術的な検討ポイントを解説するセッションをお届けしました。Capital One 様ではビジネスチームが利用者目線で目標とする可用性を検討した上で、カード限度額引き上げ処理には Amazon Aurora グローバルデータベース、カード決済処理には Amazon DynamoDB グローバルテーブルを採用するという要件に合わせたデータストア戦略を選択しています。また、住信SBIネット銀行様は、インターネットバンキングにマルチリージョンアーキテクチャを採用し、Amazon Aurora グローバルデータベースの昇格を含めてリージョン切換えのオペレーションを自動化していることを解説しました。 AWS でレジリエントな分散システムを構築するためのデザインパターン AWS ソリューションアーキテクト 新谷 歩生より、 AWS 上でレジリエンスを高めるためのアプローチやデザインパターンを解説するセッションをお届けしました。アプリケーションを機能単位で分割することで、障害時の影響範囲を小さくできます。一方で分散システムの複雑性が高くなるため、グレイスフルデグラデーション、リトライとエクスポネンシャルバックオフ、サーキットブレイカー等レジリンスを高める設計がより重要となります。また、ケーススタディとして仮想の EC サイトを例に、分散トランザクションの障害管理パターンである Saga パターン、書き込みと読み込みで個別の信頼性要件に対応するための手法としてイベントソーシングと CQRS パターンを解説しました。 インシデントの影響を封じ込めるクラウドアーキテクチャの実践 AWS ソリューションアーキテクト 奥野 友哉より障害の影響範囲を狭める手法として、セルベースアーキテクチャとシャッフルシャーディングを解説するセッションをお届けしました。セルベースアーキテクチャは、アプリケーションをセル単位で複製し、論理的な境界を作成することによって、障害時の影響を全体の一部に抑える設計手法であり、Amazon EBS 内部や、 Amazon Music でも採用されています。セルルーター、セル、コントロールプレーンという要素で構成され、それぞれの設計ポイントを解説しました。また、レジリエンスを更に高める手法として、クライアントに対して複数のワーカー (シャード) を割り当てるシャッフルシャーディングもご紹介しました。 アーキテクチャ道場 2024！ AWS ソリューションアーキテクトが 2 つのお題に対して、レジリエンスをテーマに設計したアーキテクチャを紹介します。 1 つ目は、 AZ 内で発生するグレー障害 （インフラは正常だが、アプリケーションは正常応答しないようなケース） への対処です。 AZ 隔離を対処の前提とし、 AZ の独立性を高める手法と障害検出方法について解説しました。 2 つ目は、依存性障害 （外部のサードパーティサービスが正常でなくなった場合に障害となるケース）への対処です。アプリケーションとサードパーティサービスの間にプロキシサービスを配置し、負荷の緩和と障害影響の遮断を行う手法を解説しました。どちらの例も障害が発生した場合に、その影響をコントロールするために参考となる手法です。レジリエンス向上に興味のある方はぜひご確認ください。 AWS FIS で始めるChaos Engineering 入門 AWS ソリューションアーキテクト 安藤 麻衣より、ミニステージ にて AWS FIS で始める Chaos Engineering 入門 のプレゼンテーションを行いました。分散システムの信頼性を向上させるカオスエンジニアリングについて、基本的な考え方や手法を解説し、カオスエンジニアリングを始める際に活用できるサービスとして AWS Fault Injection Service を紹介しました。 AWS ブース展示より AWS Resilience ブース資料は こちら からダウンロード頂けます。 AWS Resilience ブースでは、障害注入と Resilience （回復力） の確認をテーマにデモを実施しました。マルチリージョンで構成された、ミッションクリティカルな株価サービスをに対して、AWS Fault Injection Service (FIS) で障害を注入し、ワークロードの変化と回復力の確認を行うデモを実施しました。具体的には、 FIS を通じて、リージョン障害を想定した障害を注入し、障害が発生した際の影響や、 DNS フェイルオーバーによる切り替わり、自動復旧した様子をワークロードのモニターを通じて確認いただきました。デモを通して、 Resilience （回復力）とモニタリングの重要性についてご紹介しました。 金融業務を支えるプラットフォーム ～最新事例～ ブース資料は こちら からダウンロード頂けます。 こちらのブースでは、⾦融インダストリーの⾼信頼性を担保するフレームワーク「⾦融リファレンスアーキテクチャ⽇本版」の最新アップデートをご紹介しました。来場者様向けの体験型のデモとして、ブースに設置された大きなボタンを押すと銀行アプリケーションが東京リージョンから大阪リージョンに数分で自動で切り替わるものをご提供し、多くのお客様に興味をもってマルチリージョンを体験して頂けました。このデモには Fault Injection Service による故障注入や、 AWS Resilience Hub によるアプリケーション回復力の自動評価も含まれます。 AWS が提供するお客様参加型のイベント 「FSI Resiliency Quest」 GameDay についてもご紹介し、ゲーム形式でレジリエンスを学ぶ機会として多くの来場者様から開催のご要望を頂きました。 Chaos Kitty で楽しくインシデント対応ゲームをしよう！ ブース資料は こちら からダウンロード頂けます。 Chaos Kitty は、 AWS のアーキテクチャを物理的に表現し、楽しみながら障害対応の体験学習ができるソリューションです。 Web 3 層 アーキテクチャを IoT 電球の色で示し、正常時は緑、異常時は赤に変わる仕組みとなっています。AWS SUMMIT Japan 2024 では、Amazon CloudWatch ダッシュボードでリソースの稼働状況やリクエスト状況を把握しながら実際にアプリケーションの障害と復旧を体感頂くゲームをご提供しました。 まとめ レジリエンスに関する様々な事例が多くのセッションとブースを通じてお届けできた AWS Summit Japan 2024 でした。ビジネスや社会へのインパクトの大きいワークロードでクラウド活用が進む中で、年々レジリエンスへの注目度が高まっていることが感じられます。ミッションクリティカルなシステムや高い可用性要件が求められるシステムのクラウド移行を検討頂いている皆様に少しでも参考になれば幸いです。 著者 石倉 徹 パートナー技術統括本部 第三技術部 パートナーソリューションアーキテクト 深森 広英 グローバルフィナンシャルサービス シニアソリューションアーキテクト 新谷 歩生 技術統括本部 ストラテジックインダストリー技術本部 通信グループ シニアソリューションアーキテクト

2024 年 7 月 10 日水曜日に開催される、1 年に 1 度の弊社最大のイベントの 1 つである ニューヨーク市での AWS Summit の興奮に備えましょう。実地での参加は満席ですが、基調講演を視聴するための登録はまだ受け付けています。基調講演では、AWS VP for AI Products である Matt Wood 博士が、AWS の最新のリリースと技術的なイノベーションを発表します。その後、このページでは、お客様が見逃すことのないように、極めてエキサイティングな製品ニュースの役立つまとめをお届けします。 基調講演のライブストリームを視聴するには、こちらからご登録ください。 (この記事の最終更新日時:2024 年 7 月 9 日午後 2 時 45 分 (PST))。 2024 年 7 月 9 日の AWS からのお知らせ Integrate your data and collaborate using data preparation in AWS Glue Studio AWS Glue の新しいビジュアルインターフェイスを使用すると、データチームは共同で ETL パイプラインを構築し、直感的で共有可能なキャンバスを通じてアナリストとエンジニアの間のギャップを埋めることができます。 原文は こちら です。

7月9日、 AWS Glue Studio Visual ETL でのデータ準備オーサリングの一般提供を開始することをお知らせします。これは、ビジネスユーザーとデータアナリスト向けの新しいノーコードデータ準備ユーザーエクスペリエンスで、スプレッドシートスタイルの UI を備えており、AWS Glue for Spark でデータ統合ジョブを大規模に実行します。新しいビジュアルデータ準備エクスペリエンスにより、データアナリストとデータサイエンティストは、データをクリーンアップして変換し、分析と機械学習 (ML) 用に準備することが容易になります。この新しいエクスペリエンスでは、数百の事前構築済みの変換から選択して、データ準備タスクを自動化できます。コードを記述する必要はありません。 ビジネスアナリストは、データエンジニアと協力してデータ統合ジョブを構築できるようになりました。データエンジニアは、Glue Studio のビジュアルフローベースのビューを使用して、データへの接続を定義したり、データフロープロセスの順序を設定したりできます。ビジネスアナリストは、データ準備エクスペリエンスを使用して、データ変換と出力を定義できます。さらに、既存の AWS Glue DataBrew データクレンジングおよび準備「レシピ」を新しい AWS Glue データ準備エクスペリエンスにインポートできます。この方法では、引き続き AWS Glue Studio で直接オーサリングし、レシピをスケールアップして、 AWS Glue ジョブのためにより低い料金ポイント でペタバイト単位のデータを処理できます。 ビジュアル ETL の前提条件 (環境設定) ビジュアル ETL には、 AWS Glue にアクセスするユーザーとロールにアタッチされた AWSGlueConsoleFullAccess IAM マネージドポリシー が必要です。 このポリシーは、AWS Glue へのフルアクセスと、 Amazon Simple Storage Service (Amazon S3) リソースへの読み取りアクセスを、これらのユーザーとロールに付与します。 高度なビジュアル ETL フロー 適切な AWS Identity and Access Management (IAM) ロール許可が定義されたら、AWS Glue Studio を使用してビジュアル ETL をオーサリングします。 抽出 [ソース] のリストから Amazon S3 ノードを選択して、Amazon S3 ノードを作成します。 新しく作成したノードを選択し、S3 データセットを参照します。ファイルが正常にアップロードされたら、 [スキーマを推測] を選択してソースノードを設定すると、ビジュアルインターフェイスに .csv ファイルに含まれるデータのプレビューが表示されます。 私は以前、AWS Glue ビジュアル ETL と同じリージョンに S3 バケットを作成し、視覚化するデータを含む .csv ファイルである visual ETL conference data.csv をアップロードしました。 前のステップで詳しく説明したように、S3 バケットを読み取るためのアクセスを AWS Glue に付与するロール許可を設定することが重要です。このステップを実行しないと、エラーが発生し、最終的にデータプレビューが表示されなくなります。 変換 ノードが設定されたら、データ準備レシピを追加して、データプレビューセッションを開始します。このセッションの開始には通常約 2～3 分かかります。 データプレビューセッションの準備ができたら、 [レシピをオーサリング] を選択してオーサリングセッションを開始し、データフレームが完成したら変換を追加します。オーサリングセッション中は、データの表示、変換ステップの適用、変換されたデータのインタラクティブな表示が可能です。ステップを元に戻したり、やり直したりできるほか、ステップの順序を変更することもできます。列のデータ型と各列の統計プロパティを視覚化できます。 [ステップを追加] を選択して、小文字から大文字への形式変更、並べ替え順序の変更など、データへの変換ステップの適用を開始できます。すべてのデータ準備ステップはレシピで追跡されます。 南アフリカで開催される会議のビューが必要だったため、 [場所] 列の値が「South Africa」と等しく、 [コメント] 列に値が含まれているという条件でフィルタリングする 2 つのレシピを作成しました。 ロード インタラクティブにデータを準備したら、データエンジニアと作業内容を共有できます。データエンジニアは、より高度なビジュアル ETL フローとカスタムコードを使用してその作業内容を拡張し、本番データパイプラインにシームレスに統合できます。 今すぐご利用いただけます AWS Glue データ準備オーサリングエクスペリエンスは、AWS Data Brew が利用可能なすべての商用 AWS リージョン で一般提供されています。詳細については、 AWS Glue にアクセスしてください。 詳細については、「 AWS Glue デベロッパーガイド 」にアクセスしてください。また、 AWS re:Post for AWS Glue または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Veliswa 原文は こちら です。

7月9日、 re: Invent 2023 からプレビュー版として 提供されていた新しい AWS Graviton4 ベースの Amazon Elastic Compute Cloud (Amazon EC2) R8g インスタンスが一般公開されたことをお知らせします。AWS は、150 種類以上の AWS Graviton 搭載の Amazon EC2 インスタンスタイプを世界中で大規模に提供し、200 万個以上の Graviton プロセッサを構築してきました。また、5 万社を超えるお客様が AWS Graviton ベースのインスタンスを使用して、アプリケーションで最高のコストパフォーマンスを実現しています。 AWS Graviton4 は、AWS がこれまで設計した中でも最も強力かつエネルギー効率の高いプロセッサであり、Amazon EC2 で実行される幅広いワークロードにご使用いただけます。他のすべての AWS Graviton プロセッサと同様、AWS Graviton4 は 64 ビットの Arm 命令セットアーキテクチャを採用しています。AWS Graviton4 ベースの Amazon EC2 R8g インスタンスは、AWS Graviton3 ベースの Amazon EC2 R7g インスタンスと比較して、最大 30% 優れたパフォーマンスを提供します。これにより、高性能データベース、インメモリキャッシュ、リアルタイムのビッグデータ分析など、要求の厳しいワークロードのパフォーマンスを向上させることができます。 re: Invent 2023 でのプレビュー版の発表以来、Epic Games、SmugMug、Honeycomb、SAP、ClickHouse を含む 100 社以上のお客様が、AWS Graviton4 ベースの R8g インスタンス でワークロードをテストし、同等のインスタンスと比較してパフォーマンスが大幅に向上していることを確認しました。SmugMug では、画像とデータの圧縮操作において、AWS Graviton4 ベースのインスタンスを使用した場合、AWS Graviton3 ベースのインスタンスと比較してパフォーマンスが 20～40% 向上しました。Epic Games は、AWS Graviton4 インスタンスがこれまでにテストした中で最速の EC2 インスタンスであることを確認しました。Honeycomb.io は、4 年前に使用していた非 Graviton ベースのインスタンスと比較して、vCPU あたりのスループットが2倍以上になったと報告しています。 新しいインスタンスにおける改善点をいくつか見てみましょう。R8g インスタンスは、R7g インスタンスと比較して最大 3 倍の vCPU (最大 48xl)、3 倍のメモリ (最大 1.5 TB)、75% 増のメモリ帯域幅、2 倍の L2 キャッシュを備え、より大きいインスタンスサイズを提供します。これにより、大量のデータの処理、ワークロードのスケールアップ、結果が出るまでの時間の短縮、TCO の削減を実現します。また、Graviton3 ベースのインスタンスが最大 30 Gbps のネットワーク帯域幅と最大 20 Gbps の EBS 帯域幅を提供するのに対して、R8g インスタンスは、最大 50 Gbps のネットワーク帯域幅と最大 40 Gbps の EBS 帯域幅を提供します。 R8g インスタンスは、2 つのベアメタルサイズ (metal-24xl と metal-48xl) を提供する初の Graviton インスタンスです。インスタンスを適切なサイズに設定し、物理リソースへの直接アクセスからメリットを得るワークロードをデプロイできます。R8g インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ ネットワーク帯域幅 EBS 帯域幅 r8g.medium 1 8 GiB 最大 12.5 Gbps 最大 10 Gbps r8g.large 2 16 GiB 最大 12.5 Gbps 最大 10&nbsp;Gbps r8g.xlarge 4 32 GiB 最大 12.5 Gbps 最大 10&nbsp;Gbps r8g.2xlarge 8 64 GiB 最大 15 Gbps 最大 10&nbsp;Gbps r8g.4xlarge 16 128 GiB 最大 15 Gbps 最大 10 Gbps r8g.8xlarge 32 256 GiB 15 Gbps 10 Gbps r8g.12xlarge 48 384 GiB 22.5 Gbps 15 Gbps r8g.16xlarge 64 512 GiB 30 Gbps 20 Gbps r8g.24xlarge 96 768 GiB 40 Gbps 30 Gbps r8g.48xlarge 192 1,536 GiB 50 Gbps 40 Gbps r8g.metal-24xl 96 768 GiB 40 Gbps 30 Gbps r8g.metal-48xl 192 1,536 GiB 50 Gbps 40 Gbps 二酸化炭素排出量の削減と持続可能性の目標達成に役立つ、よりエネルギー効率の高いコンピューティングオプションを探している場合、R8g インスタンスは EC2 のメモリ集約型ワークロードに最適なエネルギー効率を提供します。さらに、これらのインスタンスは AWS Nitro System に構築されており、CPU の仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにオフロードして、ワークロードのパフォーマンスとセキュリティを強化します。Graviton4 プロセッサは、すべての高速物理ハードウェアインターフェイスを完全に暗号化することにより、セキュリティを強化します。 R8g インスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Container Registry (Amazon ECR) 、Kubernetes、Docker、および C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの一般的なプログラミング言語で記述されたアプリケーションを使用して構築された、マイクロサービスベースのコンテナ化されたアプリケーションを含む、すべての Linux ベースのワークロードに最適です。AWS Graviton4 プロセッサは、AWS Graviton3 プロセッサと比較した場合、ウェブアプリケーションでは最大 30%、データベースでは 40%、大規模な Java アプリケーションでは 45% 高速です。詳細については、 AWS Graviton テクニカルガイド をご覧ください。 アプリケーションを Graviton インスタンスタイプに移行する際に役立つ一連の Graviton リソース をご覧ください。また、 AWS Graviton Fast Start プログラムにアクセスして Graviton の導入を開始することもできます。 今すぐご利用いただけます R8g インスタンスは現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト) の AWS リージョンでご利用いただけます。 R8g インスタンスは、リザーブドインスタンス、オンデマンド、スポットインスタンス、または Savings Plans でご購入いただけます。詳細については、 Amazon EC2 の料金 をご覧ください。 Graviton ベースのインスタンスの詳細については、 AWS Graviton プロセッサ または Amazon EC2 R8g インスタンス をご覧ください。 – Esra 原文は こちら です。

7月1日週の月曜日以来の AWS ニュースは 21 件しかなく、そのほとんどは既存のサービスと機能のリージョンレベルの拡張に関するものでした。比較的静かな 1 週間をお過ごしいただけたのではないでしょうか。7月8日週はたくさんお知らせすることがあります。 7月8日週は、7 月 10 日 (水) に Jacob Javits Convention Center で開催される AWS Summit New York にお客様とパートナーをお迎えします。公開する準備が整った AWS ニュースのブログ記事の数から判断すると、お知らせが続々と発表されるでしょう。 私は、7月15日週の土曜日に カメルーンのドゥアラで開催される AWS Community Day に参加する予定であり、その荷造りをする直前にこの記事を書いています。お客様、パートナー、学生の皆さん、そして AWS コミュニティ全体にお会いできるのが待ちきれません。 しかしとにかく今は、7月1日週の新しいお知らせを見てみましょう。 7月1日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon Simple Storage Service (Amazon S3) Access Grants が、 Amazon SageMaker およびオープンソース Python フレームワーク と統合するようになりました – Amazon S3 Access Grants は、Active Directory や AWS Identity and Access Management (IAM) プリンシパルなどのディレクトリ内の ID を、S3 のデータセットにマッピングします。機械学習 (ML) のための Amazon SageMaker Studio との統合 は、S3 の機械学習 (ML) データセットに ID をマッピングするのに役立ちます。 AWS SDK for Python (Boto3) プラグイン との統合により、データ許可の管理に必要なカスタムコードが置き換えられるため、 Django 、 TensorFlow 、 NumPy 、 Pandas などのオープンソース Python フレームワークで S3 Access Grants を使用できます。 AWS Lambda が、Lambda 関数のログの検索、フィルタリング、集約を容易にする新しいコントロールを導入 – 独自のログ記録ライブラリを使用せずに、 Lambda ログを JSON 構造化形式でキャプチャできるようになりました 。また、コードを変更せずに、Lambda ログのログレベル (ERROR、DEBUG、INFO など) を制御することもできます。最後に、Lambda がログを送信する Amazon CloudWatch ロググループを選択できます。 Amazon DataZone がきめ細かなアクセスコントロールを導入 – Amazon DataZone はきめ細かなアクセスコントロールを導入しました 。これにより、データ所有者は行レベルと列レベルでデータをきめ細かく制御できます。 Amazon DataZone を利用すると、ガバナンスとアクセスコントロールを使用して、組織の境界を越えて大規模にデータをカタログ化、検出、分析、共有、管理できます。データ所有者は、データセット全体へのアクセスを付与する代わりに、特定のデータレコードへのアクセスを制限できるようになりました。 AWS Direct Connect が特定の場所でネイティブの 400 Gbps 専用接続を提案 – AWS Direct Connect は、AWS とお客様のデータセンター、オフィス、またはコロケーション施設間のプライベートな高帯域幅接続を提供します。 ネイティブの 400 Gbps 接続は、リンクアグリゲーショングループで複数の 100 Gbps 接続を管理する運用オーバーヘッドなしで、より高い帯域幅を提供します 。400 Gbps 接続によって提供されるキャパシティの増加は、ML および大規模言語モデル (LLM) トレーニングや自動運転車の高度な運転支援システムなど、大規模なデータセットを転送するアプリケーションに特に役立ちます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS の他のニュース 興味深い他のニュース項目をいくつかご紹介します。 今後立ち上げ予定の AWS European Sovereign Cloud リージョンで立ち上げ時に利用可能なサービスのリストを公開 – 新しい AWS European Sovereign Cloud リージョンで立ち上げ時から利用可能な AWS サービスのリスト を共有しました。リストには標準的なサービスが含まれています。セキュリティ、ネットワーキング、ストレージ、コンピューティング、コンテナ、人工知能 (AI)、サーバーレスのサービスが立ち上げ時から利用可能になります。当社は、規制の厳しい業界の公共部門の組織やお客様に、独自のデジタル主権要件、厳格なデータレジデンシー、運用の自律性、回復力の要件を満たすためのさらなる選択肢を提供するために、 AWS European Sovereign Cloud を構築 しています。これは 78 億 EUR (約 84.6 億 USD) の投資です。新しいリージョンは 2025 年末までに利用可能になる予定です。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。今後の AWS Summit イベントの詳細については、 AWS Summit ページをご覧ください。最寄りの都市のイベントにご登録ください: ニューヨーク (7 月 10 日)、 ボゴタ (7 月 18 日)、 台北 (7 月 23〜24 日)。 AWS Community Days &nbsp;– 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供される コミュニティ主導のカンファレンス に参加しましょう。近日開催予定の AWS Community Day は、 カメルーン (7 月 13 日)、 アオテアロア (8 月 15 日)、 ナイジェリア (8 月 24 日) です。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 今週はここまでです。7月15日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

AWS Summit New York まであと 10 日です。新しい発表と 170 以上のセッションをとても楽しみにしています。サミット終了後、 A Night Out with AWS イベントが開催されます。このイベントは、 Amazon Web Services (AWS) の既存のお客様、またはビジネスで AWS クラウドサービスを利用することに強い関心を持っているメディア、エンターテインメント、ゲーム、スポーツ業界の専門家を対象としています。リラックスしたり、コラボレーションしたり、AWS のリーダーや業界の仲間と新しいつながりを築いたりする機会です。 では、6月24日週の新しい発表を見てみましょう。 6月24日週のリリース 私が注目したリリースを以下に記載しました。 AI21 Labs の Jamba-Instruct が Amazon Bedrock で利用可能に – AI21 Labs の Jamba-Instruct は、安心して商用に使用できる、指示準拠型の大規模言語モデル (LLM) です。コンテキストとサブテキストを理解し、自然言語の指示を受けてタスクを完了し、長い文書や財務書類から情報を取り込む機能を備えています。強力な推論機能を持つ Jamba-Instruct では、複雑な問題の分類、関連情報の収集、構造化された出力を行うことができます。これにより、電話での質疑応答、文書の要約、チャットボットの構築などが可能になります。詳細については、 Amazon Bedrock の AI21 Labs と Amazon Bedrock ユーザーガイド をご覧ください。 Amazon WorkSpaces の新機能、Amazon WorkSpaces Pools – Amazon WorkSpaces を使用して非永続的な仮想デスクトップのプールを作成し、ログインのたびに新しいデスクトップを受け取るユーザー間で共有することで、コストを節約できるようになりました。WorkSpaces Pools は、トレーニングラボやコンタクトセンターなどの共有環境を柔軟にサポートします。また、 Amazon Simple Storage Service (Amazon S3) や Amazon FSx といった中央ストレージリポジトリに保存されているブックマークやファイルなどの一部のユーザー設定を保存して、パーソナライゼーションを向上させることができます。 AWS Auto Scaling を使用すると、使用状況メトリクスまたはスケジュールに基づいて、仮想デスクトップのプールを自動的にスケールできます。料金情報の詳細については、 Amazon WorkSpaces の料金 ページを参照してください。 Amazon DataZone の API 主導の OpenLineage 対応データリネージビジュアライゼーション (プレビュー) – Amazon DataZone で、データがソースから消費されるまでの流れを組織全体で視覚化できる、新しいデータ系統機能をご利用いただけるようになりました。このサービスでは、OpenLineage 対応システムから、または API を介してリネージイベントをキャプチャし、データ変換を追跡します。データ利用者はアセットの発生元に対する信頼を得ることができ、作成者は包括的な系統ビューを通じてデータの使用状況を把握して、変更の影響を評価できます。さらに、Amazon DataZone ではイベントごとに系統をバージョン管理して、任意の時点の系統を視覚化したり、アセットやジョブの履歴全体にわたる変換を比較したりできます。詳細については、 Amazon DataZone にアクセスし、 私のニュースブログ投稿 を確認して、 データリネージのドキュメント をご覧ください。 Amazon Bedrock のナレッジベースでオブザーバビリティログの提供を開始 – Amazon CloudWatch 、S3 バケット、または Amazon Data Firehose ストリームを通じてナレッジ取り込みのログをモニタリングできるようになりました。これにより、ドキュメントが正常に処理されたか、取り込み中にエラーが発生したかをより明確に把握できます。このような包括的な洞察が可能になると、文書がいつ使用できる状態になるかを効率的に判断できます。これらの新機能の詳細については、 Amazon Bedrock のナレッジベース ドキュメントを参照してください。 AWS Well-Architected フレームワークとレンズカタログの更新および拡張 – 安全で耐障害性のあるクラウドワークロードを構築するためのアーキテクチャのベストプラクティスに関するガイダンスと推奨事項を拡張するため、AWS Well-Architected フレームワークとレンズカタログの更新を発表しました。この更新によって重複が削減され、リソースとフレームワーク構造の一貫性が強化されます。レンズカタログに新しく 金融サービス業界レンズ を追加し、 合併と買収レンズ を更新しました。また、「 クラウドの変革イネーブルメント 」ホワイトペーパーでも重要な更新を行いました。更新された Well-Architected フレームワークとレンズカタログを使用して、現在のベストプラクティスに従うと、お客様固有の要件に合わせて最適化されたクラウドアーキテクチャを設計できます。 Amazon SageMaker Model Registry でのクロスアカウント機械学習 (ML) モデル共有のサポート – Amazon SageMaker Model Registry が AWS Resource Access Manager (AWS RAM) と統合され、AWS アカウント間で ML モデルを簡単に共有できるようになりました。これにより、データサイエンティスト、ML エンジニア、ガバナンス担当者は、開発、ステージング、本番などのさまざまなアカウントのモデルにアクセスできます。AWS RAM コンソールでモデルを指定し、他のアカウントへのアクセスを許可すると、Amazon SageMaker Model Registry でモデルを共有できます。この新機能は、GovCloud リージョンを除く SageMaker Model Registry が利用可能なすべての AWS リージョン でご利用いただけます。詳細については、 Amazon SageMaker デベロッパーガイド をご覧ください。 AWS CodeBuild、AWS Graviton3 を使用する Arm ベースのワークロードをサポート – AWS CodeBuild では、追加の設定なしで、AWS Graviton3 プロセッサでの Arm ワークロードのネイティブビルドとテストのサポートを開始しました。これにより、以前の Graviton プロセッサと比較してパフォーマンスが最大 25% 向上し、エネルギー使用量は 60% 削減されます。CodeBuild による Arm のサポートの詳細については、 AWS CodeBuild ユーザーガイド をご覧ください。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 Amazon RDS は、AWS GovCloud (米国) リージョンで AWS Secrets Manager との統合のサポートを開始しました 。RDS を AWS Secrets Manager と統合すると、データベース作成のワークフロー中に RDS マスターユーザーのパスワードが管理者やエンジニアにプレーンテキストで表示されないようにすることで、データベースのセキュリティを向上させることができます。 Amazon OpenSearch Serverless をカナダ (中部) リージョンで利用できるようになりました 。OpenSearch Serverless は Amazon OpenSearch Service のサーバーレスデプロイオプションです。複雑なインフラストラクチャ管理を必要とすることなく、検索と分析のワークロードを簡単に実行できます。 Amazon Redshift 同時実行スケーリングを AWS ヨーロッパ (スペイン、チューリッヒ) および中東 (UAE) リージョンで利用できるようになりました 。Amazon Redshift 同時実行スケーリングは、クエリ処理能力を自動的かつ柔軟にスケーリングし、数百の同時クエリに対して一貫して高速なパフォーマンスを提供します。 Amazon ElastiCache は、Graviton3 ベースの M7g および R7g ノードファミリーのサポートを、次の AWS リージョンで開始しました: 米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン、北カリフォルニア)、カナダ (中部)、南米 (サンパウロ)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、パリ (M7g のみ)、スペイン、ストックホルム)、アジアパシフィック (ハイデラバード、ムンバイ、ソウル) 。これらの新しいノードでは、Graviton2 ノードと比較してスループットが最大 28％、P99 レイテンシが 21％、ネットワーク帯域幅が 25％ 向上し、価格パフォーマンスが改善されています。 Amazon EC2 C6a インスタンスをアジアパシフィック (香港) リージョンで利用できるようになりました 。C6a インスタンスは、最大周波数が 3.6 GHz の第 3 世代 AMD EPYC プロセッサを搭載しています。また、同等の C5a インスタンスと比較した場合、最大 15% 優れた価格パフォーマンスを提供します。 ベースキャパシティが小さい Amazon Redshift Serverless を、 アジアパシフィック (ムンバイ) 、 欧州 (ストックホルム)、米国西部 (北カリフォルニア) リージョンで利用できるようになりました。Amazon Redshift Serverless の最小基本容量を、32 RPU から 8 RPU に削減しました。1 秒あたりに支払われる RPU で容量を測定することにより、コストパフォーマンス要件に基づいて、小規模から大規模までさまざまなワークロードをより柔軟にサポートできるようになりました。 Amazon Athena のプロビジョンドキャパシティを南米 (サンパウロ) と欧州 (スペイン) のリージョンで利用できるようになりました 。Provisioned Capacity は Athena の機能の 1 つです。完全マネージド型の専有サーバーレスリソースで、SQL クエリを固定料金で実行できます。長期契約は必要ありません。 Amazon CloudWatch Logs アカウントレベルのサブスクリプションフィルターを、AWS GovCloud (米国東部、米国西部) リージョン、イスラエル (テルアビブ)、カナダ西部 (カルガリー) リージョンで利用できるようになりました 。この新機能により、Amazon CloudWatch Logs に取り込まれたリアルタイムのログイベントを Kinesis Data Streams データストリーム、Amazon Data Firehose 配信ストリーム、または AWS Lambda 関数に配信し、単一のアカウントレベルのサブスクリプションフィルターを使用して、カスタム処理、分析、または他の宛先への配信を行うことができます。 Amazon Route 53 Application Recovery Controller (Route 53 ARC) のゾーン自動シフトを AWS GovCloud (米国東部、米国西部) リージョンで一般的に利用できるようになりました 。この機能を使用すると、AWS がアベイラビリティーゾーンに影響する可能性のある障害を特定したときに、そのアベイラビリティーゾーンからアプリケーションのトラフィックを安全かつ自動的に移行できます。 Amazon S3 の AWS Backup サポートを AWS カナダ西部 (カルガリー) リージョンで利用できるようになりました 。AWS Backup は、ポリシーベースで費用対効果の高い、完全マネージド型のソリューションです。AWS Backup を使用すると、Amazon S3 のデータ保護と、他の (コンピューティング、ストレージ、データベースにまたがる) AWS サービスおよびサードパーティアプリケーションのデータ保護を一元化および自動化できます。 3 TiB のメモリを搭載した Amazon EC2 High Memory インスタンスをアジアパシフィック (香港) リージョンで利用できるようになりました 。新しい High Memory インスタンスは、オンデマンドおよび Savings Plan の購入オプションで使用を開始できます。 AWS のその他のニュース 興味深いと思われるその他のニュース項目をいくつかご紹介いたします。 Amazon Bedrock で生成 AI アプリケーションを構築およびスケールする主な理由 – Jeff Barr の動画 をご覧ください。迅速な価値とビジネスの成長を実現する生成人工知能 (生成 AI) アプリケーションの構築とスケーリングに、お客様が Amazon Bedrock を選ぶ理由について説明されています。Amazon Bedrock はその機能、革新性、可用性、セキュリティにより、生成 AI の構築とスケーリングに適したプラットフォームになりつつあります。さまざまな業界をリードする組織が Amazon Bedrock を使用して、インテリジェントな仮想アシスタント、クリエイティブデザインソリューション、文書処理システムなどの作成など、生成 AI の取り組みを加速させています。 AWS がインフラストラクチャをエンジニアリングして生成 AI を強化する 4 つの方法 – AWS では、モデルトレーニングを高速化するための低レイテンシーかつ大規模なネットワークの提供、データセンターのエネルギー効率の継続的な改善、インフラストラクチャ設計全体にわたるセキュリティの優先、コンピューティングパフォーマンスを向上させつつコストとエネルギー使用量を削減するための AWS Trainium などのカスタム AI チップの開発などのイノベーションを通じて、生成 AI を大規模にサポートできるように、インフラストラクチャを引き続き最適化しています。 AWS が生成 AI のインフラストラクチャをエンジニアリングしている 方法についての新しいブログ投稿をご覧ください。 AWS re:Inforce 2024 re:Cap – 毎年恒例のクラウドセキュリティ学習イベント、AWS re:Inforce 2024 から 2 週間が経ちました。 Wojtek が作成した イベントの概要 をご覧ください。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。今後の AWS Summit イベントの詳細については、 AWS Summit ページをご覧ください。最寄りの都市のイベントにご登録ください: ニューヨーク (7 月 10 日)、 ボゴタ (7 月 18 日)、 台北 (7 月 23〜24 日)。 AWS Community Days &nbsp;– 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供される コミュニティ主導のカンファレンス に参加しましょう。近日開催予定の AWS Community Day は、 カメルーン (7 月 13 日)、 アオテアロア (8 月 15 日)、 ナイジェリア (8 月 24 日) です。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 今週はここまでです。7月8日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Amazon WorkSpaces を使用して非永続的な仮想デスクトップのプールを作成し、グループのユーザー間で共有できるようになりました。デスクトップ管理者は、1 つの GUI、コマンドライン、または API を利用したツールセットを使用して、永続的仮想デスクトップと非永続的仮想デスクトップのポートフォリオ全体を管理できます。ユーザーは、 ブラウザ 、 クライアントアプリケーション (Windows、Mac、Linux)、または シンクライアントデバイス を使用してこれらのデスクトップにログインできます。 Amazon WorkSpaces プール (非永続デスクトップ) WorkSpaces プールを使うことで、各ユーザーは同じアプリケーションを使用し、同じエクスペリエンスを得られるようになります。ユーザーがログインすると、管理者が一元管理するプールの最新の設定に基づいた新しい WorkSpaces にいつでもアクセスできます。管理者がプールのアプリケーション設定の永続化を有効にすると、ユーザーはブラウザのお気に入り、プラグイン、UI のカスタマイズなど、特定のアプリケーション設定を行えます。ユーザーは、デスクトップの外部にある永続ファイルまたはオブジェクトストレージにもアクセスできます。 このようなデスクトップは、リモートワーカー、タスクワーカー (共有サービスセンター、財務、調達、人事など)、コンタクトセンターの従業員、学生など、さまざまなタイプのユーザーやユースケースに最適です。 プールの管理者は、ユーザーが利用できるアプリケーションセットを含め、コンピューティングリソース (バンドルタイプ) とプール内のデスクトップの初期設定を完全に制御できます。既存のカスタム WorkSpaces イメージを使用することも、新しいイメージを作成することも、標準のイメージを使用することもできます。また、エンタープライズ向け Microsoft 365 アプリケーションをイメージに含めることもできます。ユーザーベースの規模と作業時間に合わせてプールを設定できます。また、オプションで組織のドメインとアクティブディレクトリにプールを追加することもできます。 開始方法 プールを設定してユーザーを招待するプロセスを見ていきましょう。WorkSpaces コンソールを開き、 [Pools] (プール) を選択して開始します。 プールがないので、 [Pools] (プール) タブの [Create WorkSpaces] (Workspaces の作成) を選択して、プールの作成プロセスを開始します。 コンソールがワークスペースのオプションを勧めてくれたり、必要なものを選択したりできます。非永続デスクトップのプールを作成するには、 [Recommend workspace options…] (推奨ワークスペースオプション…) を選択したままにし、 [No – non-persistent] (いいえ – ノンパーシステント) を選択します。次に、メニューからユースケースを選択し、オペレーティングシステムをクリックし、 [Next] (次へ) を選択して続行します。 ユースケースメニューには、次のようにたくさんのオプションがあります。 次のページでは、まず WorkSpace オプションを確認して、プールに名前を割り当てます。 次に、下にスクロールして、バンドルを選択します。パブリックバンドルまたは独自のカスタムバンドルを選択できます。バンドルは WSP 2.0 プロトコルを使用する必要があります。カスタムバンドルを作成して、ユーザーにアプリケーションへのアクセスを提供したり、必要なシステム設定を変更したりできます。 次に進むと、各ユーザーセッションの設定をカスタマイズできます。また、アプリケーション設定の永続化を有効にして、セッション間でユーザーごとにアプリケーションのカスタマイズと Windows 設定を保存することもできます。 次に、プールの容量を設定し、オプションで日付や時刻を考慮して 1 つ以上のスケジュールを設定します。スケジュールにより、ユーザーのリズムやニーズに合わせてプールのサイズ (またそれに従ったコスト) を調整することができます。 同時使用量がより動的で、スケジュールに沿っていない場合は、手動のスケールアウトとスケールインのポリシーを使用してプールのサイズを制御できます。 プールにタグを付けて、 [Next] (次へ) を選択して続行します。 最後のステップは、WorkSpaces プールディレクトリを選択するか、 次の手順 に従って新しいディレクトリを作成することです。次に、 [Create WorkSpace pool] (WorkSpace プールの作成) を選択します。 プールを作成して起動したら、登録コードをユーザーに送信して WorkSpace にログインできます。 コンソールからプールのステータスを監視できます。 知っておくべきこと WorkSpaces プールについて知っておきたい事柄には、次のようなものがあります。 プログラムによるアクセス – 上で示したセットアッププロセスは、 CreateWorkSpacePool 、 DescribeWorkSpacePool 、 UpdateWorkSpacePool などの関数、または同等の AWS コマンドラインインターフェイス (CLI) コマンドを使用して自動化できます。 リージョン – WorkSpaces プールは、イスラエル (テルアビブ)、アフリカ (ケープタウン)、中国 (寧夏) を除き、WorkSpaces Personal が利用可能なすべての商用 AWS リージョンでご利用いただけます。今後の更新については、 リージョンの完全なリスト を参照してください。 料金 – 料金情報の詳細については、 Amazon WorkSpaces の料金 ページを参照してください。 詳細については、 Amazon WorkSpaces プール をご覧ください。 – Jeff ; 原文は こちら です。

Hello Builders の皆様もしくは Builders の卵の皆様、こんにちは！機械学習ソリューションアーキテクトの呉( @kazuneet )です。 2024 年 2 回目の 7/18(木)の Builders Online Series が近くなってきました。 前回のブログ では最初のセッション群の「AWS 基礎 – 90 分で学ぶ！AWS 超入門 2024」を紹介しましたが、この記事では 2 番目のセッション群の「生成 AI 実践入門」について紹介します。 &gt;&gt; AWS Builders Online Series のお申し込みはこちらから 「生成 AI 実践入門」では、Amazon Bedrock という生成 AI サービスを通じて、Builder の皆様がアプリケーションの構築のイメージをつかめることを目指します。 全部で４セッションあり、Amazon Bedrock に触れたことがない方が「完全に理解した（※）」を目標として順番でご視聴いただくことを想定しております。 ※ダニング=クルーガー効果でいうところの最初の山の到達地点。イメージとしてはチュートリアルを一通り行いなんでもできるようになった気持ちの状態。その後自分で手を動かして行くと「何もわからない」という状態を通じて「チョットデキル」の状態になっていく。 どんなセッションかイメージしやすいよう、少しだけ登壇資料をチラ見せしつつ紹介いたします。 11:50 – 12:20 BOS-04: 生成 AI コワクナイヨ！AWS マネジメントコンソールで始める Amazon Bedrock Amazon Bedrock の全体像の解説と、基本機能である生成 AI の呼び出しを AWS マネジメントコンソールから行うデモをお見せします。 生成 AI の課題とは・・・ Bedrock から扱えるモデルはいっぱいあります。 セキュリティって大事ですよね・・・ 12:30 – 13:00 BOS-05: Builder なら API で Amazon Bedrock を使ってみよう！超簡単 API コールの手ほどき 生成 AI をシステムに組み込むには API で Amazon Bedrock を呼び出す必要がありますが、Amazon Bedrock の API は簡単に呼び出せます。その呼び出し方をレクチャーします。 Amazon Bedrock をアプリに組み込む場合はどうすれば・・・ AWS のサービスを呼び出すには API を呼び出せばいい・・・？SDK もある・・・？ AWS CloudShell というすぐに利用できるコードの実行環境からデモを行います。 13:10 – 13:40 BOS-06: 明日からすぐに使える自分で作る生成 AI アプリケーション〜Chat with your document〜 生成 AI は単品で使うだけでなく、自分が持っているドキュメントと組み合わせることでできることの幅が広がります。その例えばを紹介いたします。 生成 AI のハルシネーションって困りますよね・・・ RAG というのを使えばハルシネーションを抑制できる・・・？ さらにデータベースを用意しなくてもRAGができる・・・？ 13:50 – 14:20 BOS-07: 業務で利用できる生成 AI ソリューションのデプロイと実装を一緒に覗いてみよう 生成 AI をアプリに組み込んだ例をとその実装を紹介するセッションです。 チャットってなんでもできるけど必ずしも便利ではないですよね・・・ GenU という無償で使えるチャット以外も使えるソリューションがあるんですね。 コードの中身も紹介します。 このように生成 AI の第一歩からアプリケーション構築まで一気に学べるコンテンツをご用意しておりますので、ぜひご参加ください！ &gt;&gt; AWS Builders Online Series のお申し込みはこちらから

Amazon DataZone は、組織内のデータプロデューサーとコンシューマーの間でデータをカタログ化、検出、分析、共有、管理するためのデータ管理サービスです。エンジニア、データサイエンティスト、製品マネージャー、アナリスト、ビジネスユーザーは、統合データポータルを使用して組織全体のデータに簡単にアクセスして、データ駆動型のインサイトを検出および使用したり、そのようなインサイトを得るためにコラボレーションしたりできます。 Amazon DataZone の API 駆動型で OpenLineage 互換の新しいデータリネージ機能のプレビューを発表します。この機能は、時間の経過に合わせたデータ移動のエンドツーエンドのビューを提供します。データリネージは Amazon DataZone 内の新しい機能であり、ユーザーによるデータの出自の視覚化および理解、変更管理の追跡、データエラーが報告された際の根本原因分析の実行、ソースからターゲットへのデータ移動に関する質問への準備に役立ちます。この機能は、Amazon DataZone のカタログから自動的にキャプチャされたリネージイベントと、Amazon DataZone の外部でプログラムによってキャプチャされた他のイベントをつなぎ合わせてアセットとしてまとめた包括的なビューを提供します。 組織内で関心のあるデータがどのように生成されたかを検証する必要がある場合、手動のドキュメントや関係者への確認に依拠することがあります。この手動プロセスは時間がかかり、不整合が生じる可能性があるため、データの信頼性が直接的に低下します。Amazon DataZone のデータリネージは、データの生成元、変更方法、および時間の経過に伴う利用を把握できるようにすることで、信頼性を高めることができます。例えば、データリネージは、 Amazon Simple Storage Service (Amazon S3) で生のファイルとしてキャプチャされた時点から、 AWS Glue を利用した ETL 変換を経て、 Amazon QuickSight などのツールで利用された時点までのデータを表示するようにプログラムで設定できます。 Amazon DataZone のデータリネージを使用すると、データアセットとその関係のマッピング、パイプラインのトラブルシューティングと開発、およびデータガバナンスプラクティスのアサーションにかかる時間を短縮できます。データリネージは、API を使用してすべてのリネージ情報を 1 か所に集約して、データユーザーの生産性を高め、データ駆動型のより適切な意思決定を行い、データの問題の根本原因を特定するためのグラフィカルビューを提供するのに役立ちます。 Amazon DataZone でデータリネージの使用を開始する方法を説明します。その後、データアセットがどのように作成されたかというつながりを視覚的に表示し、そのデータアセットを検索または使用する際に十分な情報に基づいた意思決定を行えるようにすることで、データリネージが Amazon DataZone データカタログエクスペリエンスをどのように強化するのかを説明します。 Amazon DataZone でのデータリネージの開始方法 プレビューでは、 Amazon DataZone API を使用してリネージノードを直接作成するか、既存のパイプラインコンポーネントから OpenLineage 互換イベントを送信して Amazon DataZone の外部で発生するデータの移動または変換をキャプチャすることにより、プログラムで Amazon DataZone にリネージ情報をハイドレートすることから開始できます。カタログ内のアセットに関する情報については、Amazon DataZone は、アセットの状態 (すなわち、インベントリや公開状態など) とサブスクリプションのリネージを自動的にキャプチャします。これは、データエンジニアなどのプロデューサーにとっては、自分が作成したデータを誰が利用しているかを追跡するのに役立ち、データアナリストやデータエンジニアなどのデータコンシューマーにとっては、分析に利用しているのが適切なデータであるかどうかを把握するのに役立ちます。 情報が送信されると、Amazon DataZone はリネージモデルへの入力を開始し、API を通じて送信された識別子を、既にカタログ化されているアセットにマッピングできるようになります。新しいリネージ情報が送信されると、モデルはバージョンの作成を開始し、特定の時点でアセットのビジュアライゼーションを開始しますが、以前のバージョンに移動することもできます。 このユースケースでは、事前設定された Amazon DataZone ドメインを使用します。Amazon DataZone ドメインを使用して、データアセット、ユーザー、プロジェクトを整理します。 Amazon DataZone コンソール に移動し、 [ドメインを表示] を選択します。ドメイン [Sales_Domain] を選択し、 [データポータルを開く] を選択します。 ドメインには 5 つのプロジェクトがあります。1 つはデータプロデューサー用 ( [SalesProject] )、4 つはデータコンシューマー用 ( [MarketingTestProject] 、 [AdCampaignProject] 、 [SocialCampaignProject] 、 [WebCampaignProject] ) です。「 Amazon DataZone Now Generally Available – Collaborate on Data Projects across Organizational Boundaries 」を参照して、独自のドメインとすべてのコアコンポーネントを作成できます。 [アセットを検索] バーに「Market Sales Table」と入力し、 [Market Sales Table] アセットの詳細ページに移動します。 [リネージ] タブを選択して、上流ノードと下流ノードのリネージを視覚化します。 これで、アセットの詳細、プロセス、それらのアセットにつながるジョブ、それらのアセットからつながるジョブを詳しく知ることができ、列レベルのリネージを詳しく確認できます。 データリネージを使用したインタラクティブなビジュアライゼーション Amazon DataZone を定期的に操作し、データリネージ機能の恩恵を享受するさまざまなペルソナを使用して、グラフィカルインターフェイスをご紹介します。 まず、私がマーケティングアナリストであり、自信をもって分析で利用できるよう、データアセットのオリジンを確認する必要があるとします。 [MarketingTestProject] ページに移動し、 [リネージ] タブを選択します。リネージには、Amazon DataZone の内外で発生するアセットに関する情報が含まれていることがわかります。 [カタログ化済み] 、 [公開済み] 、および [アクセスをリクエスト済み] のラベルは、カタログ内のアクションを表します。データの出自を確認するには、 [market_sales] データセット項目を展開します。 これで、データアセットのオリジンがわかり、分析を開始する前にそれが自分のビジネス目的と一致していることを確信できます。 次に、私がデータエンジニアだとします。意図しない変更を避けるために、自分の作業内容が依存オブジェクトに及ぼす影響を理解する必要があります。データエンジニアとして、システムに加えられた変更によって下流のプロセスが中断されることがあってはなりません。リネージを参照することで、誰がサブスクライブしており、アセットにアクセスできるのかを明確に確認できます。この情報を使用して、パイプラインに影響を及ぼす可能性のある喫緊の変更についてプロジェクトチームに通知できます。データの問題が報告された場合、各ノードを調査し、そのバージョン間を移動して、時間が経過する中で何が変わったのかを詳しく確認し、問題の根本原因を特定して適時に修正できます。 最後に、データの保護、ビジネス分類の標準化、データ管理プロセスの実施、および一般的なカタログ管理を担当する管理者またはスチュワードである場合について考えてみましょう。データのソースに関する詳細を収集し、その過程で発生した変換を理解する必要があります。 例えば、監査人からの質問に回答しようとしている管理者として、グラフを上流にたどってデータの出自を確認し、データがオンライン販売と店舗内販売という 2 つの異なるソースから来ていることに気づきました。これらのソースには、パイプラインが合流するポイントに到達するまで、独自のパイプラインがあります。 リネージグラフを適切に操作しながら、列を展開して、変換プロセス中に機密性の高い列が削除されるようにしたり、詳細について監査人に適時に回答したりできます。 プレビューにご参加ください データリネージ機能は、 Amazon DataZone が一般提供されているすべてのリージョンでプレビューとして利用できます。Amazon DataZone ドメインをプロビジョニングできるリージョンの一覧については、「 AWS サービス (リージョン別) 」にアクセスしてください。 データリネージのコストは、ストレージ使用量と API リクエストによります。これらは Amazon DataZone の料金モデルに既に含まれています。詳細については、「 Amazon DataZone の料金 」にアクセスしてください。 Amazon DataZone のデータリネージの詳細については、「 Amazon DataZone ユーザーガイド 」にアクセスしてください。 – Esra 原文は こちら です。

Amazon CodeCatalyst が、 GitHub との既存の統合 に加えて、 GitLab と BitBucket という人気が高い 2 つのコードリポジトリとも統合することをお知らせします。現在 CodeCatalyst と GitHub との統合で使用しているのと 同じ機能セット を GitLab.com と Bitbucket Cloud でもご利用いただけます。 Amazon CodeCatalyst は、統合型のソフトウェア開発および配信サービスです。Amazon CodeCatalyst を使用すると、ソフトウェア開発チームは Amazon Web Services (AWS) 上でアプリケーションを迅速かつ簡単に計画、開発、コラボレーション、構築、配信できるよううになり、開発ライフサイクル全体でフリクションが軽減されます。 CodeCatalyst 用の GitHub、GitLab.com、Bitbucket Cloud のリポジトリ拡張機能を活用すると、開発ワークフローの管理が簡単になります。この拡張機能では、CodeCatalyst 内で外部リポジトリを直接表示および管理できます。また、ワークフロー定義ファイルをコードと一緒に外部リポジトリに保存して管理すると同時に、CodeCatalyst 開発環境からリンクされたリポジトリ内のファイルを作成、読み取り、更新、削除することもできます。さらに、この拡張機能はコードがプッシュされたとき、およびプルリクエストを開いたり、マージしたり、閉じたりしたときに、CodeCatalyst ワークフローの自動実行をトリガーします。しかも、リンクされたリポジトリのソースファイルを直接利用し、CodeCatalyst ワークフロー内でアクションを実行できるため、プラットフォームを切り替える必要がなく、効率を最大化できます。 それだけではありません。6月27日より、 ブループリントからの GitHub、GitLab.com、または Bitbucket Cloud リポジトリでの CodeCatalyst プロジェクトの作成 、これら 3 つのシステムのいずれかのリポジトリにある既存のコードベースへのブループリントの追加、GitHub、Gitlab.com、または Bitbucket Cloud でホストされている外部リポジトリに保存されるカスタムブループリントの作成ができるようになりました。 CodeCatalyst ブループリント は開発のスピードアップに役立ちます。これらの事前作成済みテンプレートには、ソースリポジトリ、サンプルコード、継続的インテグレーションと継続的デリバリー (CI/CD) ワークフロー、統合問題追跡機能が備わっているため、すぐに作業を開始できます。ブループリントはベストプラクティスに従って自動的に更新され、コードを最新の状態に保ちます。IT リーダーは、テクノロジー、アクセス制御、デプロイ、テスト方法を指定して、チームの開発を標準化するカスタムブループリントを作成できます。さらに、コードが GitHub、GitLab.com、または Bitbucket Cloud にある場合でも、ブループリントを使用できるようになりました。 CodeCatalyst スペースを Git リポジトリのホスティングサービスとリンクする これら 3 つのソースコードリポジトリプロバイダーのどれでも、簡単に使用を開始できます。 CodeCatalyst スペース の管理者として、拡張機能を設定するスペースを選択します。次に、 [Settings] (設定) を選択し、 [Installed extensions] (インストールされている拡張機能) セクションで [Configure] (構成) を選択して、CodeCatalyst スペースを GitHub、GitLab.com、または Bitbucket Cloud アカウントにリンクします。 これは CodeCatalyst スペースごとに 1 回限りの操作ですが、スペースを複数のソースプロバイダーのアカウントに接続したいとします。 GitHub を使用するときは、個人の CodeCatalyst ユーザーを自分の GitHub ユーザーにリンクする必要もあります。画面右上の個人メニューで [My settings] (設定) を選択します。次に、 [Personal connections] (パーソナル接続) セクションに移動します。 [Create] (作成) を選択して、指示に沿って GitHub で認証し、2 つの ID をリンクします。 これは CodeCatalyst スペースの各ユーザーにおいて 1 回限りの操作です。GitHub をブループリントで使用している場合にのみ必要となります。 ブループリントからプロジェクトを作成し、GitHub、GitLab.com、Bitbucket Cloud でホストする ブループリントから外部リポジトリにプロジェクトを作成し、後ほどこのプロジェクトに他のブループリントを追加する方法について説明します。CodeCatalyst がサポートする 3 つの Git ホスティングプロバイダーのいずれかを使用できます。このデモでは、GitHub を使用します。 API を実装するための新しいプロジェクトを作成したいとします。まず、 Python と AWS サーバーレスアプリケーションモデル (AWS SAM) を使用して API を実装するブループリントから始めます。このブループリントでは、CI ワークフロー と 問題 管理システムも作成されます。 プロジェクトコードを GitHub でホストしたいとします 。これにより、GitHub のリポジトリにあるソースファイルを直接使用し、CodeCatalyst ワークフロー内でアクションを実行できるようになるため、プラットフォームを切り替える必要がなくなります。 まず、CodeCatalyst スペースのページで [Create project] (プロジェクトを作成) を選択します。 [Start with a blueprint] (ブループリントを使用して開始) を選択し、使用する CodeCatalyst ブループリント または Space ブループリント を選択します。その後、 [Next] (次へ) を選択します。 プロジェクトの名前を入力します。 [Advanced] (詳細設定) セクションを開き、 [Repository provider] (リポジトリプロバイダー) として GitHub を選択し、 GitHub アカウント を選択します。GitHub [Connect a GitHub account] (GitHub アカウントを接続) を選択すると、GitHub への追加接続を設定できます。 残りの設定は、選択したブループリントによって異なります。今回は、言語バージョン、プロジェクトをデプロイする AWS アカウント、 AWS Lambda 関数、 AWS CloudFormation スタックの名前を選択しました。 プロジェクトが作成された後、GitHub アカウントに移動すると、新しいリポジトリが作成されたことがわかります。ブループリントのコードとリソースが含まれています。 既存の GitHub、GitLab.com、または Bitbucket Cloud プロジェクトにブループリントを追加する 1 つのプロジェクトに複数のブループリントを適用して、既存の CodeCatalyst プロジェクトに機能コンポーネント、リソース、ガバナンスを組み込むことができます。プロジェクトは、個別のブループリントでそれぞれ管理される、さまざまな要素をサポートできます。 サービスドキュメントは、既存のプロジェクトのブループリントを使用して、ライフサイクル管理について詳しく学ぶのに役立ちます 。 これで、外部のソースコードリポジトリにある既存のプロジェクトにブループリントを追加できるようになりました。バックエンド API プロジェクトが作成されたので、プロジェクトにウェブアプリケーションを追加します。 左側のメニューの [Blueprints] (ブループリント) セクションに移動し、画面の右上にあるオレンジ色の [Add blueprint] (ブループリントを追加) ボタンを選択します。 [Single-page application] (1 ページのアプリケーション) のブループリントを選択し [Next] (次へ) を選択します。 次の画面では、プロジェクトを作成したときと同じように、必ず GitHub 接続を選択します。この特定のテンプレートに必要な情報も入力します。画面の右側で、提案された変更を確認します。 同様に、 CodeCatalyst Enterprise Tier を使用する場合、 独自のカスタムブループリントを作成 して、チームメイトや組織内の他のグループと共有できます。簡潔にするため、この記事では手順を追って説明しません。詳細については、ドキュメントの「 Standardizing projects with custom blueprints 」を参照してください。 CodeCatalyst が新しいブループリントのインストールを完了すると、GitHub に 2 つ目のリポジトリが表示されます。 単一または複数のリポジトリ戦略 コードを整理するときは、すべてが詰まったツールボックスのような単一の大きなリポジトリを使用するか、整理しやすい小さな専用リポジトリに分割するかを選択できます。単一リポジトリは、緊密にリンクされたプロジェクトの依存関係管理を簡素化しますが、大規模になればなるほど煩雑になる可能性があります。リポジトリが複数あると、整理がしやすくなり、セキュリティが向上しますが、個別のプロジェクト間の依存関係を管理する計画を立てる必要があります。 CodeCatalyst を使用すると、プロジェクトに最適な戦略を使用できます。詳細については、ドキュメントの「 Store and collaborate on code with source repositories in CodeCatalyst 」を参照してください。 前に示した例では、私が選択したブループリントから、2 番目のブループリントを GitHub の別のリポジトリとして適用することが提案されました。選択したブループリントによっては、別のリポジトリを作成するか、既存のリポジトリに新しいコードをマージすることを、ブループリントが提案する場合があります。後者の場合、ブループリントはリポジトリにマージするためのプルリクエストを送信します。 リージョンと利用状況 この新しい GitHub 統合は、公開時点で Amazon CodeCatalyst が利用可能な 2 つの AWS リージョン、米国西部 (オレゴン) と欧州 (アイルランド) で、追加料金なしで利用できます。 今すぐお試しください — seb 原文は こちら です。