みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊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 原文は こちら です。

本ブログは、ルームクリップ株式会社と Amazon Web Services Japan が共同で執筆しました。また、今回の内容を含む講演動画 ( Lambda で動くプロンプトライクな物体検出システム ) も公開されていますので、興味をお持ちいただけましたら合わせてご覧ください。 ルームクリップ株式会社 は「日常の創造性を応援する」というミッションを掲げ、住生活の領域に特化した日本最大級のソーシャルプラットフォーム「RoomClip」を運営しています。同プラットフォームでは、ユーザーが投稿した「住生活の実例写真」から欲しいアイテムや好きなブランドと繋がることができます。 同社で投稿された部屋写真を自動で解析して類似商品のリンクを記載する機能を実装しました。これによりユーザーは投稿された写真に写る家具を取り扱う EC サイトに遷移したり、一部は Roomclip 内で直接購入できるため、シームレスな購買体験が得られます。この機能のコアとなる家具の検出システムに軽量な基盤モデルを採用し AWS Lambda 上で実行した事例を紹介いたします。 課題 家具の検出システムの実装には要件が 2 つあり、1) ある写真ではカーテンにリンクを付与するが、ある写真では付与しないというような、細やかな運用のドメイン知識を反映できること。2) 今までリンクが付けられていなかったコーヒーメーカーにもリンクを付与したいというような、追加のニーズに柔軟に対応できることが求められます。 まずは、家具検出システム構築に必要な要素であるセグメンテーション、家具の認識、座標の取得を、既存の仕組みを用いて検討しました。しかし、既存の API サービスを利用する場合、新たに検出したい家具を追加するには追加学習が必要で、ニーズに即座に応えるのが難しいこと。さらに過剰に家具を検出してしまうという課題があり、柔軟なリンク付与対象の調整が難しいことが分かりました。また、自社で機械学習モデルを開発する場合は GPU の利用コストと学習時間がかかるという課題がありました。 ソリューション ルームクリップ社では課題解決のために、軽量な基盤モデルを利用して自然言語で指定した家具のみを検出させる以下のようなアプローチを取りました。 FastSAM による物体のセグメンテーションと座標取得 基盤モデルの CLIP による自然言語で指定した家具の認識 FastSAM と CLIP を組み合わせた物体検出のフローを AWS Lambda 上で構築 FastSAM のセグメント範囲の大小を調整できるカスタム性と、CLIP を利用した自然言語で指定した家具のみを抽出するフィルターを組み合わせることで、細やかなビジネスニーズに応える柔軟な家具検出システムを実現しました。投稿された写真が Amazon Simple Storage Service (Amazon S3) に保存されたことをトリガーに AWS Lambda 上の家具検出システムが実行され、処理結果が Amazon Relational Database Service (Amazon RDS) に保存されるというシンプルな構成です。ここで注目すべきは家具検出システムは CPU で動作し、 AWS Lambda のメモリは 4 GB 程度で、写真 1 枚あたりの計算は 60 秒以下で完了する高速かつ低コストなシステムであることです。検出すべき家具が追加された場合でも、追加学習不要でプロンプトを変更するだけで対応可能です。 導入効果 生成 AI を活用したことにより独自のニーズに即座に応えられる家具検出システムの構築を実現しました。プロンプトで認識すべき家具を指定できるため、非エンジニアでも仕様を変更できる柔軟なシステムとなりました。新たに認識したい家具が増えた場合でも、追加学習不要でプロンプトの修正のみで対応可能です。ビジネス的な効果としては、導入前と比較して商品ページの閲覧数がおよそ 2 倍に増加する大きな効果が得られました。また基盤モデルを AWS Lambda 上で実行することで、コストと運用負荷を大幅に削減できました。ルームクリップ社は、今後も AI やクラウドサービスの活用を推進し、住生活の領域でイノベーションを続けていく考えです。 ソリューションアーキテクト　長友 健人

2024 年 6 月 20 日、21 日に AWS Summit Japan が開催され、その 1 日目に “ チームで課題解決型ハンズオンに挑戦！楽しく学ぶ「AWS Jam」 ” を実施しました。本イベントには、クラウドスキルの向上を目指す 112 名が 4 名ずつ 28 チームに分かれて参加し、熱戦が繰り広げられると同時にチーム内でのスキル共有や新たな発見に満ちた有意義な時間となりました。 このブログでは当日の様子を伝えつつ、AWS Jam がどのように AWS の学習やチームでのスキル共有などに役立てられるか、AWS Jam を実施したい場合の選択肢として AWS Skill Builder やクラスルームトレーニングを紹介します。 AWS Jam とは AWS Jam は、AWS のユースケースに沿って用意された様々なテーマの課題を解決しながら「AWS を楽しく学ぶ」実践型のイベントです。参加者は AWS やシステム開発の知識や経験を活用し、必要に応じてその場で情報を調べながら、与えられた複数の課題を AWS マネジメントコンソールなどを利用してクリアしていきます。AWS Jam では、課題ごとに獲得得点やヒントが設定されており、時間内にクリアした課題と使用したヒントを総合してチームの得点を競い合います。 AWS Jam には「 Play 」「 Learn 」「 Validate 」の3つのコンセプトがあります。 Play (遊ぶ) : 得点を競うゲーミング形式のイベントを通じて、楽しみながら課題解決に挑戦します。チーム内でのコミュニケーションの促進にもつながります。 Learn (学ぶ) : シナリオに沿った課題を解決することで、AWS サービスの知識やスキルを身につけていきます。普段扱っていない AWS のサービスや機能を新たに学んだり調べたりする機会にもなります。 Validate (検証する) : 課題解決を通して、参加者自身の AWS サービスに対するスキルや理解度を確認できます。 AWS Jam 実施前のハイライト 今回の AWS Jam では 4 人でチームを組みます。登録時点ではチームは決まっておらず、会場に入場する際にくじ引きでチームを決定しました。ランダムにチームを決定することで、個人で参加する人のハードルを下げ、平等性を保つことを目的としました。 AWS Jam 開場時のくじ引きと誘導 AWS Jam に参加するには、AWS Skill Builder のアカウントが必要です。開場からイベント開始までの時間を利用して、アカウントの準備を行なっていただきました。また、準備が完了したテーブルでは、チームメンバーと自己紹介や雑談をして交流を深めていました。 準備が整ったらオリエンテーション開始です。オリエンテーションでは、AWS Jam のプラットフォーム上でイベントとチームに参加していただき、AWS Jam の紹介とチャレンジへの取り組み方の説明を行いました。 AWS Jam では、チームでの取り組み方にプラットフォーム上の制約は無く、複数人で相談しながら 1 つずつチャレンジを進めるモブ型や、チーム内で 2 人 1 組になってチャレンジを進めるペア型、手分けして個人でチャレンジを進めるソロ型があります。 AWS Jam チーム内での分担 ただし、本イベントでは以下の理由によりペアワークまたはモブワークで進めていただくことにしました。 個人ではなく、チームで AWS Jam イベントを楽しんでいただきたいため AWS Jam は個人の学習だけではなく参加者同士のスキル共有にも役立つことを体験していただきたかったため また、ペアワークまたはモブワークをチャレンジに取り組む時のルールとして設定することは、昨年の AWS Summit でも行なっていました。ペアワークまたはモブワークの効果やうまく進めるための方法は AWS Jam 実施レポート @ AWS Summit Tokyo 2023 も確認ください。 AWS Jam 開始前にいくつかコツを伝えました。直前のことが一番記憶に残りやすいため、特に重要なことを開始直前のタイミングで伝えると効果的です。 AWS Jam うまく進めるためのコツ 特に最後の楽しむためのコツとして、チームで喜びを共有することを意識していただきました。チームで何かを達成したり、ポイントを獲得したりしたときには、チーム全員で拍手をすることで、チームの連帯感を高め、チームでイベントを楽しんでいただけるようにしました。 AWS Jam 実施中の様子 本イベントでチームで Jam に取り組む時間は 150 分でした。AWS Jam が始まると、チーム内でペアを決めたり、担当チャレンジを相談したりしていました。ペアワークやモブワークでは、画面を操作するドライバーと、指示やサポートを行うナビゲーターに分かれて協力しながらチャレンジに取り組んでいました。参加者の中にはペアワークやモブワークを初めて経験する方も多く、最初は上手に指示ができなかったり、指示の意図をうまく汲み取れなかったりする様子も見受けられましたが、積極的にコミュニケーションを取る中でチームでスキルを共有する姿が見られました。 また、ペアワークでチャレンジに取り組む中で行き詰まったときには、ホワイトボードを活用して考えを整理したり、チーム内の他のペアに相談したりすることで、チーム一丸となって課題解決に取り組んでいました。 AWS Jam 実施中の様子 1/4 AWS Jam 実施中の様子 2/4 AWS Jam 実施中の様子 3/4 AWS Jam 実施中の様子 4/4 結果発表 激戦の結果、優勝は「オオサカ」チーム、2 位が「Nara as the No.1」チーム、3 位が「サーティーワン」チームとなりました。各チームとも素晴らしいパフォーマンスを見せ、最後まで緊張感が漂う白熱した戦いを繰り広げました。おめでとうございます。 1 位「オオサカ」のみなさん 2 位「 Nara as the No.1 」のみなさん 3 位「サーティーワン」のみなさん 上位３チームのメンバー AWS Jam のコンソールでは、リーダーボードやスコアリングトレンドがリアルタイムで表示されるため、特に後半ではリーダーボードを見ながらチャレンジの優先順位を変更したり、ヒントを活用してチームで競い合う様子が確認できました。スコアリングトレンドからは、順位が何度も入れ替わる大接戦の様子がわかります。 AWS Jam では単純な技術力だけでなく、チームでの連携や戦略も順位に大きく影響します。特に、ヒントを使用したチームには最大獲得可能スコアの減少というペナルティがある中、ヒントを使ってでも学びとスコアを得るという戦略を選択したチームもありました。 AWS Jam リーダーボード AWS Jam スコアリングトレンド 実施後のアンケートでは、「楽しく学べて大変満足しました！」「ペアワークはお互いで教え合う仕掛けになっており、勉強になり、かつ楽しかったです！」「普段利用していなかったサービスかつ、設定したことのない設定ができたので、そこは今後の社内でのサービス検討時に利用できそうです。」といったコメントを多くいただきました。 また、「今後自分の組織でスキルアップをするために AWS Jam を使いたいと思いますか？」という項目では、96 %以上の参加者が肯定的な結果となりました。組織で AWS のスキルアップを考えられている場合には、ぜひ AWS Jam を活用してみてください。組織で AWS Jam を活用する方法は次にご紹介します。 AWS Skill Builder チームサブスクリプションで AWS Jam イベントを実施可能 AWS Skill Builder は AWS の無料の学習コンテンツとして、600 を超えるデジタルコースや AWS 認定公式練習問題を使用できるオンライン学習センターです。また、 チームサブスクリプション を利用すれば、今回の AWS Summit で実施した AWS Jam イベントをお客様が実施できるようになります。他にも 500 を超えるチャレンジ (2024/07/01 現在) から好みのチャレンジを選定し、組織内で回数制限なく自由にイベントを開催できます。 AWS Skill Builder サブスクリプションのご案内 のブログに詳細が記載されていますので、併せてご確認ください。 AWS Summit Japan 2024 で使われたチャレンジの一覧はこちらです。すでに組織で AWS Skill Builder チームサブスクリプションを契約されている場合は、「 AWS Summit Japan 2024 」 のチャレンジセットを使用して、ぜひご自身の組織で開催してみてください。 レベル タイトル AWSサービス Easy Protect my CloudFront Origin CloudFront, ELB Easy ARM64 your Databases RDS Medium Query operations in DynamoDB DynamoDB, Lambda Medium Use one ALB with multiple domains ELB, Route 53, VPC Medium Pull the Alarm! CloudWatch, EC2 Medium Mining in my cloud? CloudTrail, EC2, ELB Medium Trace with AWS Lambda Powertools Lambda, X-Ray, DynamoDB Medium Connect using RDS Proxy RDS, Lambda, IAM Hard A/B Testing Puzzle CloudFront, S3, Cognito, API Gateway, Lambda, DynamoDB, CloudWatch Hard Hash the Data Lake! Athena, S3, Lake Formation, Lambda AWS クラスルームトレーニングで AWS Jam を提供中 AWS クラスルームトレーニングに AWS Jam を追加したコースも提供しています (2024/07/01 時点では個社向けの開催のみです)。こちらを選択していただく利点として、クラスルームトレーニングを受けた後に AWS Jam を実施するため、 知識をインプットするだけでなく AWS Jam で実践することで、より理解を深めたりスキルとしての検証をしたりできる点があります。さらに、トレーニング企画時に AWS の担当者と相談しながら AWS Jam の実施方法を決めていけるので、以下のような要望も可能です。 Play / Learn / Validate のどのコンセプトを重視するか 知識やスキルの近いメンバーでチームを組むか、均等になるようにチームを組むか モブ型、ペア型、ソロ型など、どんな形式で進めるか また、AWS Summit と同様に AWS の認定インストラクターが実施準備や当日の進行をするため、AWS Jam の用意や進行をするのに不安があるお客様にもおすすめです。 AWS Jam を追加したクラスルームトレーニングはオンラインでもオンサイトでもどちらでも提供可能です。オンラインの利点を活かして、普段は交流の少ないグループ内企業や国際拠点の従業員との交流の場としたり、オンサイトで部署やチーム内のスキル共有の場としていただいています。どちらもトレーニングでの知識のインプットだけでなく、AWS Jam で実践することで、知識を深めスキルとして検証できたとお客様から満足いただけています。 組織での AWS Jam 活用に興味がある場合は、 AWS トレーニングと認定へのお問い合わせ からご連絡ください。(画面右上で「日本語」を選択し、日本語での問い合わせが可能です) 最後に AWS Jam は、楽しみながら実践的に AWS を学ぶことができるイベントです。今回の AWS Summit Japan でも、熱戦が繰り広げられるとともに、チーム内でのスキル共有や新たな発見に満ちた有意義な時間としていただけました。これからクラウドスキルの向上を目指す方、ただ知識をインプットするだけでなく実践力を鍛えたい方、組織や個人のスキルを検証したい方にとって AWS Jam は最適です。 AWS Jam をやってみたいと思った方は、AWS Skill Builder や AWS クラスルームトレーニング、AWS のイベント時に開催される機会を利用して AWS Jam に参加してみてください。 AWS Jam 実施後の集合写真 おまけ：本イベントでは、AWS トレーニングパートナー所属の AWS 認定インストラクターも運営メンバーとして加わっていました。当日運営をサポートいただいた AWS 認定インストラクターの方々、ありがとうございました。 AWS Jam 実施前のサポーター打ち合わせの様子 AWS Jam サポーターの集合写真 AKKODiSコンサルティング株式会社 藤原 靖士 NECビジネスインテリジェンス 吉田 薫 NTTデータ先端技術株式会社 田中 勇希 クラスメソッド株式会社 大前 諒祐 クラスメソッド株式会社 平野 文雄 トレノケート株式会社 久保玉井 純 トレノケート株式会社 山下 光洋 トレノケート株式会社 髙山 裕司 パナソニック コネクト株式会社 船橋 俊雄 株式会社f4samurai 酒井 幹士 株式会社アシスト 佐伯 竜輔 株式会社日立システムズ 藤巻 雄裕 著者について 西村 諄 (Nishimura Shun) AWS トレーニングサービス本部 テクニカルインストラクター

本稿では株式会社NTTドコモにおいて、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は 導入事例ページ もご覧ください。 これまでの記事は以下です。 第一回　適切なデータストアの選定とアーキテクチャの見直し 第二回　アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜 第三回　クラウドを活用したテスト効率化 〜リリース前・リリース後に何をするべきか〜 1.はじめに 第三回では、Lemino のサービスリリース時にどんな検証をし、リリース後のデプロイサイクルでどのような確認をしているか、ご紹介します。 2.サービスリリース前のテスト Lemino のリリース前には、機能面のテスト・負荷テスト・異常時を想定した検証など様々な検証を行なっています。 開発に加えて、複数の観点の検証を並行して効率的に実施するために、開発・負荷試験・ステージング・商用環境を更に分割した8面で構成し、それぞれの環境を各開発チーム・試験チームに割り当てています。複数環境を運用するため、IaCツール(Terraform)で各環境のリソースを管理し、各環境で不用意な差分が発生しないように管理しつつ、プロビジョニングの作業を効率化しています。 機能面のテストは日々の開発の中でも実施するのですが、サービスリリース前のテストとして、ライブイベント時のピーク負荷を実際にかける検証をしています。Leminoでは同時視聴ユーザが数百万規模のライブに耐えうる基盤を作ることを想定しましたので、その負荷テストの中でどの部分を実際の負荷をかけて検証するかが課題になりました。 視聴開始に関連するアクセスなどピーク負荷が課題になる部分は、本番相当の負荷をかけて検証しました。 検証の際には以下に注意する必要があります。 全体として 1 分を越えて継続する、1Gbps (10 億ビット/秒) または 1Gpps (10 億パケット/秒) を超える検証についてはネットワーク負荷テストの申請が必要になります。（参考： Amazon EC2 Testing Policy ）ほとんどの場合、このネットワーク負荷に到達する試験が必要になるケースはありませんが、今回のような大規模トラフィックの場合、この申請が通る前に負荷試験を行うことはできないため、大規模な負荷試験の場合、十分なリードタイムをもって、負荷試験を行う計画をたてることが必要です。 負荷を発生させるためのアカウントで、想定負荷を出すためのリソース準備が必要になります。 ※Amazon EC2 Testing Policy を基準に、十分小規模な負荷テストであれば同一アカウントから、大規模な負荷試験の場合、負荷を発生させるためのアカウントを別途用意し、試験を実施 Lemino では、システムごとに異なる負荷試験のツールを使いましたが、たとえば、Grafana k6 はコンテナ実行可能なJavaScript ベースの負荷試験ツールでコードベースなのでGit での試験コード管理も可能です。EC2 からの軽微な負荷試験や 5000rps 程度の負荷試験であれば Docker がインストールされている環境から負荷試験が実施可能ですが、Kubernetes cluster からの大規模負荷及び 100万 rps 近い負荷試験を実施する場合は k6-operator を Kubernetes にデプロイすることで cluster が実行可能となります。eksctlでEKSを作成すれば30分程度で構築可能です。 負荷試験の前に、ピーク負荷を発生させるために必要なリソースと、ピーク負荷をかけた際にそれを処理するために必要となるリソースが問題なく起動できるか確認し、必要に応じて上限緩和申請を行う必要性があります。非常に大きなトラフィックを発生させようとした場合、通常は問題にならないことが課題になるケースがあります。例えば、ALB や Fargate がスケールするために必要とするIPアドレスが、既存の Subnet のIPレンジからでは払い出せない、などといったことがありえます。思いもよらない制限のために、本番当日にリソースが用意できない自体に陥らないよう、利用するサービスについてはすべての上限に当たる可能性を確認し、あらかじめ検証で本番ピーク相当にスケールアウトさせた上で、実際のピーク負荷をかけています。また、上限緩和申請についても十分なリードタイムを持って実施することが必要ですので、ネットワーク負荷テストの申請が必要になる程の一定以上大規模な試験を計画する場合には、あらかじめ入念な計画が必要です。 本番相当の負荷をかける試験に意味がある部分、ない部分を判断することも重要です。通常のトラフィック処理では、CDN を使っていれば、多数のクライアントに対して、地理的に分散されたエッジロケーションでリクエストを処理するため、処理は適切に分散します。 通常のトラフィック処理 例えば、CDN を経由して Live 配信の動画を視聴する検証を特定の AWS アカウントに擬似的に作った環境で再現しようとした場合、仮に下りの通信が1ユーザーあたり 1Mbps だったとしても、1000万同時視聴を想定すると 10Tbps になります。このトラフィックを受ける検証環境を用意することは技術的にもコスト面でも非常に難しく、また、全国のユーザーがアクセスする場合と1つのAWSアカウントのリージョンからアクセスするのでは接続する CDN の Edge ロケーションのトラフィックパターンも変わってしまいます。 アンチパターン：特定のクライアントからの負荷試験 特定のクライアントからの大量のリクエストは、一部のリソースだけにリクエストが集中するため、実際のトラフィックパターンとは異なった試験になり、キャッシュヒットやパフォーマンスの観点で検証にならない場合が多くあります。概ねどの程度CDN でキャッシュヒットするかなどの確認は、小規模なライブを開催し、過去の配信実績をベースにして試算します。大規模トラフィックについては机上でどの程度キャッシュヒットするか検討した上で、バックエンドにかかる負荷を試算し、その試算をベースに負荷を想定することも選択肢の一つです。 参考： CloudFront の負荷テスト 3.リリース後も継続するデプロイの中でのテスト リリース前の検証も大切ですが、機能面の検証は本番運用開始後も継続的に、楽にできるようにしておかなければ、開発のアジリティを向上することはできません。 Lemino でのデプロイ可能ブランチは一つのみ運用し、タグのPUSHを契機として単体テストから各環境へのデプロイ及び、エンドツーエンドテストまでGitlab-CI で自動化しています。またステージング環境から商用への展開、Blue-Green切替え、切戻しのタイミングだけ手動で指定できるように制御することで、品質とアジリティの両立を実現しています。CIで利用したエンドツーエンドテストのスクリプトは、外形監視でも流用するなどの効率化も行っています。 4.まとめ AWS では本番相当のテスト環境を一時的に作成し、テスト完了後に環境を破棄できるため、容易に本番環境をシミュレートできます。一方、その本番相当の検証が意味がないものにならないよう、十分計画する必要があります。リリース後も継続するCI/CD の中でのテストは自動化することで、開発のアジリティを向上しつつ品質を担保できます。 こうした Lemino での知見が皆様の今後の開発の役に立てば幸いです。 著者について 株式会社NTTドコモ 第一プロダクトデザイン部 映像サービス担当　松原拓也 株式会社NTTドコモで提供している映像配信サービス『Lemino』のアーキテクト及び、バックエンドシステムのリードエンジニア、プロジェクトマネージャーを担当。 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部　津和﨑美希 通信業界のお客様を担当するソリューション アーキテクト。普段は通信業界のお客様のAWS活用を支援していますが、ObservabilityについてはAWS社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Serviceのご支援にも手を広げるなど、幅広いAWS活用をご支援しています。