はじめに Amazon Connect の利用が拡大するにつれ、顧客は効率的にスケーリングを管理し、クォータ（制限）を超過することによるデプロイの失敗やサービスの中断を防ぐために、クォータの可視性が必要になります。 Amazon Connect は Service Quotas との統合により、Amazon Connect インスタンスのサービスクォータ管理が改善されています。 Service Quotas は、AWS マネジメントコンソールや AWS Command Line Interface(AWS CLI) を通じてアクセスできる、 AWS アカウント全体のクォータを効率的に管理し追跡するためのハブです。この統合によりアカウントとリソースのクォータ割り当てをナビゲートし最適化する上で、より広範な制御と柔軟性が実現されます。Service Quotas を使用することで、複数のソースにアクセスする必要なく、一つの場所で Connect のクォータを中央管理できます。またサポートされているクォータでは、 Amazon CloudWatch との統合により、設定可能なアラームを通じて積極的な管理も可能になり、指定されたクォータに近づくと適時アラートを提供します。 Service Quotas によるメリット Amazon Connect サービスクォータの一元管理 : Service Quotas を使用することで、Amazon Connect のクォータを一箇所で管理でき、複数のソースを参照したり独自のリストを維持する必要がなくなります。Service Quotas は AWS マネジメントコンソール 、またはプログラム的に API や AWS CLI を使用してアクセスできます。 クォータの可視性向上 : デフォルトのクォータ値を表示するだけでなく、リソース（Connect インスタンス）単位で適用されているクォータが確認できるようになりました。クォータが変更された場合、変更後のクォータを確認できます。 クォータ引き上げリクエストの簡素化 : コンソールまたは API を通じて、アカウントレベルのクォータとリソースレベルのクォータの両方を表示および管理できます。リソースレベルのリクエストでは、調整を適用する特定のインスタンス（リソース）を選択できます。また、リクエストのステータスを表示および追跡することもできます。 クォータ引き上げリクエストへの迅速な対応 : Amazon Connect はクォータの自動レビューと承認を実装しました。自動承認されるクォータリクエストの場合、完了までの時間が数分に短縮されます。リクエストが自動承認の基準を満たさない場合は、AWS サポートケースが自動的に生成されます。 プロアクティブなクォータ管理への道筋 : Service Quotas は CloudWatch と統合されており、しきい値に達したときにアラートを発し、クォータをプロアクティブに管理できるようにします。 AWS Organizations 内の新規アカウントのクォータリクエストの簡素化 : 組織内に作成した新規アカウントのクォータ引き上げは頻繁にリクエストされています。Service Quotas はこのプロセスを自動化することで、組織内の新規アカウントのクォータ引き上げリクエストにかかる時間を削減しつつ、すべてのアカウントがワークロードのニーズに応じて一貫して構成されるようにします。 概要 このブログ記事では、Service Quotas の管理コンソール、AWS CLI を通して、リソース管理できるようになった Amazon Connect のクォータについて詳しく説明します。さらに、管理者が特定の Amazon Connect リソースのクォータを設定および管理する方法についても示します。 実施する内容 Service Quotas コンソールを使用して Amazon Connect のクォータを確認し、クォータの引き上げをリクエストする Service Quotas コンソールを使用してクォータリクエスト履歴を確認する AWS CLI を使用してクォータの引き上げをリクエストする AWS CLI を使用してクォータリクエストのステータスを確認する Service Quotas コンソールを使用してクォータ使用量メトリクスを確認する Service Quotas コンソールを使用してクォータ使用量のアラートを設定する 前提条件 Amazon Connect インスタンス IAM 権限 : クォータの引き上げをリクエストするには、service-quotas:RequestServiceQuotaIncrease 権限が必要です。 AWS CLI バージョン : AWS CLI を使用して Amazon Connect のリソースレベルのクォータを表示および管理するには、バージョン 2.13.20 以上が必要です。 Service Quotas の利用 Julie は金融業の AnyCompany 社のコンタクトセンター管理者で、新しいローンチに向けて本番環境の Connect インスタンスをテストしています。Julie は自社のコンタクトセンターが高い可用性を保ち、問い合わせとエージェントの作業量の変化に柔軟に対応できるよう細心の注意を払っています。彼女の会社は複数の事業部門をサポートするために複数の Amazon Connect インスタンスを使用しています。最大規模である消費者向けのインスタンスに電話番号を追加する必要があるため、このインスタンスの Phone numbers per instance（インスタンスあたりの電話番号数） クォータを確認し、増やしたいと考えています。 Amazon Connect のクォータについて、Julie は AWS Management Console から Service Quotas にアクセスし、Amazon Connect のページに移動することでサービスの全体のクォータに関する情報を確認できます。 Julie はページを下にスクロールして利用可能なすべてのクォータの中から Phone numbers per instance を探します。追加の詳細を確認するために表示されたクォータ名をクリックします。 詳細ページで、Julie は自身のすべての Amazon Connect インスタンスのリストを見ることができ、各インスタンスに適用されているクォータ値も含まれています。ここから、Julie はクォータの引き上げが必要な適切な Amazon Connect インスタンスを選択し、 「リソースレベルでの引き上げをリクエスト」 を選択できます。 これにより、新しいクォータ値を入力してリクエストを送信できるダイアログウィンドウが表示されます。 Phone numbers per instance の詳細ページ に戻り、 「リクエスト履歴」 タブを選択すると、Julie は現在および過去のクォータリクエストのステータスを確認できます。新しいリクエストは 「保留中」 のステータスになります。ステータスをクリックするとリクエストの詳細が表示されます。クォータの引き上げを処理するために AWS サポートケースが必要な場合は、自動的に作成され、ステータス詳細ページに AWS サポートケースへのリンクが表示されます。 Service Quotas API を使用した Amazon Connect のクォータ引き上げリクエスト Service Quotas は、クォータ引き上げをリクエストするための API も提供しています。Julie は RequestServiceQuotaIncrease API を使用してクォータ引き上げのリクエストを送信できます。例えばこの例で Julie は、別の Amazon Connect インスタンスの Phone numbers per instance（インスタンスあたりの電話番号数） クォータを 10 から 11 に増やす必要があるとします。 Julie は AWS CLI を使用してリクエストを送信します リクエストが送信されると、Julie は GetRequestedServiceQuotaChange を利用してリクエストを追跡できます 新しいクォータが適用されたかどうかを GetServiceQuota を使用して確認できます。この AWS CLI リクエストの構文は次のとおりです : aws service-quotas get-service-quota –service-code connect –quota-code <quota_code> –context-id <connect_instance_arn> –region <region> クォータに対する使用状況のモニタリング Julie は、コンタクトセンターが StopContact API を頻繁に使用して、キューからコールバックを削除していることを理解しています。さらに、彼女はこの API のクォータに対する使用状況を可視化したいと考えています。 Service Quotas 内から、彼女は Amazon Connect 内の StopContact API リクエストのレート(Rate of StopContact API requests)を参照します。 ここから、彼女は 「モニタリング」 タブを選択して CloudWatch による使用率グラフを確認します。 Julie は、このメトリクスが 100 パーセントの使用率に近づいた場合に通知を受けたいと考えています。彼女は 「アラーム」 タブを選択し、 「アラームを作成」 をクリックします。 Julie はメトリクスが 80 パーセントの使用率に達した時に通知を受けたいので、しきい値を設定し、アラームの名前を入力して作成をクリックします。 追加の考慮事項 使用率 : 選択したサービスクォータの詳細を表示する際、表示される 使用率 の値は、CloudWatch によって可視化された適用されているクォータの使用率を表します。 Connect Public API の利用率が利用可能です。 Amazon Connect グローバルレジリエンス : Amazon Connect グローバルレジリエンス（ACGR）を活用しているお客様の場合、Amazon Connect インスタンスを 2 つ目のリージョンに初期レプリケーションする際にクォータの同期プロセスがあります。サービスクォータのリクエストはリージョン固有です。初期レプリケーション後、お客様は ACGR インスタンスを今後同期させ続けるために、各リージョンに対して個別にサービスクォータの引き上げを申請する必要があります。 クリーンアップ Amazon Connect インスタンスを作成して Amazon Connect のクォータ管理をテストした場合は、 ガイドに従って Amazon Connect インスタンスを削除 できます。 結論 Service Quotas を使用すると、1 つの中央の場所から AWS サービスのクォータを表示および管理できます。Service Quotas を使用すると、クォータ引き上げリクエストを簡単に申請、追跡することができるほか、AWS Organizations と統合することで、新しいアカウントのクォータを一貫した方法で設定し、時間と労力を節約できます。このブログ記事では、Service Quotas を使用して Amazon Connect リソースのクォータを設定および管理する方法を紹介しました。 詳細については、以下をご覧ください : Amazon Connect サービスクォータ CloudWatch を使用したインスタンスのモニタリング Service Quotas とは何ですか Amazon Connect でカスタマーサービス体験を変革する準備はできましたか ? お問い合わせください 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本ブログは 2023 年 10 月 10 日に公開された Amazon News “ 3 ways AWS is helping to make the internet more secure ” を翻訳したものです。 新種のサイバー攻撃からお客様を守るための Amazon Web Services の取り組みと、ビジネスをオンラインでより安全性を高めるための対策を説明します。 2023年 8 月末、AWS のセキュリティチームは、ユーザーを標的とする新種の HTTP リクエストフラッド攻撃を発見しました。HTTP リクエストフラッド攻撃は、分散型サービス妨害 (DDoS) 攻撃の一種で、ウェブサイトやアプリケーションをユーザーが利用できないようにすることを意図的に狙ったものです。このような攻撃は、残念ながらサイバーセキュリティチームが対処すべき一般的な問題となっています。しかし、今回の攻撃はこれまでとは異なっており、かつてない規模でした。 「DDoS 攻撃は進化しています。かつてに比べてずっと攻撃的かつ高レートでWebサーバーにリクエスト通信をする方法が見つかってます。」と AWS のVice President 兼 Distinguished Engineer である Tom Scholl 氏は述べています。「リクエストフラッド攻撃は、本質的にデータを要求することです。サーバーは要求されたデータを用意しますが、攻撃者はそれを受け取る気はありません。電話を無駄に掛け続けて、相手が出たらすぐ切るようなものです。一度に 1 億回以上のリクエストがあると、大量のリソースを消費し、通常のトラフィックの処理を妨げる可能性があります。この特別な攻撃は「HTTP/2 ラピッドリセット攻撃」として知られており、1 秒あたり 1 億 5500 万回以上のリクエストが発生していました。」 DDoS 攻撃が成功すると、企業に混乱を引き起こされ、コストが増大し、日常生活を送ろうとしている人々にも影響が及ぶ可能性があります。例えば、銀行振込ができなくなったり、医療機関の情報を見られなくなったり、お気に入りの番組を視聴できなくなるかもしれません。ゲームをする人は、ログインできなくなったり、プレイ中に突然切断されてしまったりする可能性があります。 AWS エンジニアの努力により、AWS のお客様はこの新しい DDoS 攻撃から迅速に保護されました。AWS は他のテクノロジー企業と協力して、さらなる対策の開発に取り組み、業界全体でこのような攻撃への対処方法の改善に取り組みました。 「私たちはこのような問題に対して、複数の角度からアプローチします」と Scholl 氏は言います。「社内のあらゆる専門知識を総動員して迅速に対策を講じると同時に、他の脆弱な可能性のある領域も特定します。新種の DDoS 攻撃が発生した場合、検証環境で攻撃者が行っていることを再現し、攻撃の仕組みをより深く理解し、私たちのシステムの耐性をテストします。」 Scholl 氏は、業界の専門家と最も効果的な技術的アプローチに関する知識を共有し、協力することも、攻撃を防ぐために不可欠だと述べています。 「最終的に私たちは、AWS のお客様だけでなく、世界中のすべての一般の Web ユーザーにとって、インターネットをより安全でより安心な場所にしようとしています。」と彼は述べました。 AWS が DDoS 攻撃を防止し、攻撃に使われているインフラストラクチャを無効化させるために行っている 3 つの方法を紹介します。 1. ボットネットの検出と特定 攻撃者は DDoS 攻撃を実行するために、しばしば「ボットネット」を使用します。ボットネットは、通常のシステム動作を妨害するように設計されたマルウェアやその他の破壊的なソフトウェアに感染したコンピューターのネットワークです。影響を受けた数万台に及ぶ可能性のあるマシンは、1 台のサーバーによって制御されています。サーバーは、システムに過負荷をかけようとする試みとして、同時に攻撃を実行するよう指示することができます。私たちの 脅威インテリジェンスツール MadPot を通じて、ボットネットを検出し特定することができ、ボットネットがどこから制御されているかを識別できます。その後、ドメインレジストラやホスティングプロバイダーと連携して、その制御ポイントを遮断します。これにより、ボットネット自体が攻撃に加わることができなくなります。 2. スプーフィングされた IP の送信元の特定 DDoS 攻撃者がよく使用する一般的な手法の 1 つに「IP スプーフィング」があります。これは、攻撃の一環としてメッセージを送信する際に、送信元の IP アドレスを偽装して、活動停止をさせにくくする手法です。歴史的に、IP スプーフィングは真の送信者の特定が非常に困難なため、セキュリティチームにとって対処が困難な課題となっていました。(1,000 個の異なる番号から同時に 1,000 件の電話がかかってきたと想像してみてください。各メッセージの送信元ネットワークを見つけるには、一つ一つ遡って追跡する必要があります。) AWS は大規模なグローバルネットワーク基盤を運用し、何千もの独自のネットワークと相互接続しているため、ピアネットワークと直接連携して攻撃を送信元まで追跡し、遮断することができます。私たちは、さまざまなネットワーク事業者と協力して、送信者の追跡を行い、このような種類の攻撃に使用されるインフラストラクチャを遮断しています。 3. オープンプロキシを介した HTTP リクエストフラッドのトレース 「プロキシサーバー」は、ユーザーとインターネットの間のゲートウェイのような役割を果たすコンピューターです。代表的な例として、Squid のようなソフトウェアパッケージがあります。DDoS 攻撃者は、誰でも利用できるオープンプロキシサーバーを悪用して、自身の攻撃送信元を隠蔽します。彼らは積極的にオープンプロキシをスキャンし、HTTP リクエストフラッド攻撃を生成する際にそれらを使用することで、ターゲットを攻撃する際に真の送信元を隠すことができます。ターゲットが攻撃を検出しても、実際の攻撃元ではなく、インターネット上の数千のプロキシサーバーから攻撃が来ているように見えます。私たちの 脅威インテリジェンスツール MadPot を使用することで、これらのプロキシに接続している実際の攻撃元を追跡し、上位のホスティングプロバイダーに働きかけて攻撃元の遮断をすることができます。 ビジネスをオンラインでより安全に保つための 3 つのヒントを紹介します。 1. 一人で抱え込まない セキュリティは協力して取り組む必要があるというのが Scholl 氏の考えです。Amazon CloudFront のようなサービスを使えば、スタートアップであれ、大企業であれ、どのような企業にも役立ちます。CloudFront のグローバルなフットプリント、DDoS 緩和システム、トラフィック管理システムは、大量のトラフィック (良いものも悪いものも) に対処できるよう設計されています。Scholl 氏は、CloudFront の働きを考えるうえでの有用なたとえとして、非常に強固で補強された玄関ドアのイメージを挙げています。誰かが重い石を投げつけても、わずかな傷をつけるられるかもしれませんが、玄関ドア自体は無事です。DDoS に特化して対処する AWS Shield サービスと組み合わせることで、お客様は DDoS 関連の脅威に対処するための適切なツールセットを手にできます。 2. 最新状態の維持 最新のセキュリティアップデートを確実に入手し、ビジネスが依存するソフトウェアに定期的にパッチを適用し、アップデートすることは、非常に重要です。これらのアップデートには、最新の既知の脆弱性への対応が盛り込まれています。HTTP/2 対応の Web サーバーを自社で運用しているお客様には、最近報告された攻撃の影響を受けるかどうかを Web サーバーベンダーに確認し、影響を受けている場合は、この問題に対処するためにベンダーから最新のパッチをインストールすることをお勧めします。 3. 多要素認証の使用 オンラインで自身とビジネスを保護する最良の方法の 1 つは、多要素認証 (MFA) です。これはセキュリティのベストプラクティスであり、ユーザー名とパスワードのサインイン認証情報に加えて、2 つ目の認証要素を必要とします。MFA は、権限のない個人がシステムやデータにアクセスすることを防ぐための追加の保護層となります。AWS のお客様は、MFA についてさらに詳しく知りたい場合、 こちらのブログ記事 をご覧ください。 AWS がお客様の安全をどのように守っているかについての詳細は、 AWS クラウドセキュリティウェブサイト をご覧ください。2023年 8 月の DDoS 攻撃をどのように阻止したかについてのより詳細な情報については、 AWS による DDoS イベントからのお客様の保護 をご覧ください。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

この記事は、 QuickSight Demo Central に公開したサンプルダッシュボードを用いて、ゲームビジネスにおけるデータ分析基盤導入の課題と解決策を説明します。 はじめに – ゲームビジネスにおけるデータ分析の重要性 こんにちは、ゲーム業界のお客様を中心に支援を行っているテクニカルアカウントマネージャの坂本です。ゲーム業界のお客様からデータ分析基盤に関するご相談、お問合せを多くいただいています。近年のゲームビジネスでは、 Free-To-Play を基本としたオンラインゲームのように、リリース後もゲーム要素の追加やゲームバランス調整などのアップデートを継続的に行うゲームサービスとして提供することが一般的です。ゲームサービスをビジネスとして成功させる、運営を通して売れるゲームサービスにしていくためには、ゲームサービスを継続して改善し、ユーザーのニーズに応え続けることが必要です。この継続的な改善を迅速かつ的確に行うためには、ゲームデザイナーの勘や経験から導出された定性的な情報だけでなく、ゲーム内のユーザー行動を通して生成されたデータの分析結果という定量的な情報も必要です。データ分析基盤を構築し効率的にデータを収集、 BI（Business Intelligence） ツールを用いてデータを可視化することで、ユーザー行動のトレンドの変化を一目で確認できるようになり、実施した施策が売上や DAU（Daily Active User） などの KPI にどのように影響を与えたのか、仮説が正しかったのかを効率よく検証できます。加えて、可視化したデータを利用することで、ゲーム運営に携わる関係者が、ビジネス目標の達成状況や改善結果を効率よく共有、理解できるようになります。このように、定性的な情報に加えて、定量的なデータを可視化して活用することで、迅速かつ的確にゲームサービスの改善に向けた意思決定を行うことができます。本記事ではゲームビジネスにおけるデータ分析基盤導入の課題と解決策を、データ分析基盤のアーキテクチャ、および Amazon QuickSight によるサンプルダッシュボードを QuickSight Demo Central に公開しましたので、そのダッシュボードを用いてご説明します。 ゲームビジネスにおけるデータ分析の課題と解決策 お客様からご相談をいただく中で、先述のようなゲームビジネスにおけるデータ分析の重要性は感じられていますが、実際にはデータ分析基盤の導入まで至っていないことが多くあります。売上、DAUなどゲームビジネスの基本的なKPIはデータベースからデータを抽出し表計算ソフトで集計されているものの、あくまでビジネス状況を中心に表層的な把握に留まっており、ゲームサービスの運営における意思決定は勘や経験といった定性的な情報に基づいているという実情をよく伺います。このようにデータ分析の重要性は感じられていながらも、現実としてデータ分析の導入が進んでいない原因としては大きく２つの課題があると考えています。１つ目はゲームビジネスにおいてデータ分析基盤とBIツールを用いたデータ分析方法が一般的なナレッジとして普及していないという課題。２つ目はデータ分析基盤のスケーラビリティと導入の優先度を上げられないという課題です。 １つ目の課題について、お客様から Amazon QuickSight でゲームにおけるデータ分析のダッシュボードのテンプレートがあるかお問合せをいただくことが非常に多いことからも、ゲームビジネスでどのようにデータを可視化して分析を行えば良いのか悩まれるお客様が多いことが伺えます。背景にはゲームサービスに関わるドメイン知識と、データ分析の技術スキルの両方を兼ね備えた人材の獲得や育成が難しいことが挙げられます。本記事では、データ分析を専門分野とされていないお客様にも、効率よくデータ分析基盤を導入いただけるように、ゲームビジネスにおけるデータの可視化と分析の例を、 Amaozn QuickSight のデモを用いて説明します。詳細は後述しますが、 Amaozn QuickSight というクラウドネイティブなサーバーレスの BI ツールを用いることでデータ分析の専門知識を備えていないエンジニアやゲームの企画運営に関わる方でも簡単にデータの可視化を始めることができます。 2つ目の課題の背景としては、ゲームサービスは不確実性が高く、売上やユーザー数が変動するという性質があります。この性質により、データ分析基盤に必要なインフラの見積もりが困難になり、データ分析の導入が難しくなっています。この課題を解決し、データ分析基盤の費用対効果を最大限に高めるためには、ユーザー数やデータ量の変動に合わせて柔軟にスケールできる仕組みが必要です。他にデータ分析の導入に対する優先度を上げられない要因として、ゲームをリリースするまではゲーム開発にフォーカスしなければならずリリース前からデータ分析基盤を構築することに労力を割けないということが挙げられます。また、ゲームがリリースされた後でゲームサービスの本番環境に影響を与えないように分析用ログの追加・アプリケーションの変更を加えようとすると、リリース前にデータ分析基盤を構築するよりも多くの工数が必要になります。加えて、リリース後は運用業務のタスク量が多く、ゲームのユーザーに直接的に価値を提供できるタスクの優先度が高くなることから、ゲームのリリース後にデータ分析基盤を導入することは非常に難しいです。これらの理由から、お客様がデータ分析の必要性を理解されていてもゲームのリリース前、リリース後ともにデータ分析基盤の構築がなかなかできない状況であると考えています。この課題を解決するために、本記事では AWS が提供するサーバーレスサービスを組み合わせたデータ分析基盤の参考アーキテクチャをご紹介します。お客様はサーバーレスサービスを組み合わせるのみという少ない工数でデータ分析基盤を構築できます。加えて、サーバーレスサービスは使用量に応じた従量課金制のため、ゲームサービスの規模やご利用状況に合わせたリーズナブルな料金でご利用いただくことができ、トラフィックの増減に応じた柔軟なスケーラビリティも確保することができます。 ゲームのサーバーサイドとデータ分析基盤のアーキテクチャ ゲームにおけるデータ分析基盤のアーキテクチャをご紹介するにあたり、まずはゲームのサーバーサイドのアーキテクチャをおさらいします。ゲームのサーバーサイドは大きく分けて、インゲームとアウトゲームで構成されます。インゲームはRPGゲームにおけるクエストやアクションゲームにおけるバトルなどゲームの主体となる遊びの部分です。アウトゲームは認証、アイテム購入、キャラクター管理といったインゲームを支える周辺機能を指します。以下のアーキテクチャ図においては、インゲームはリアルタイムサーバーに代表されるようなゲームサーバーが担い、アウトゲームはゲームバックエンドがその処理を行います。ゲームバックエンドでは、アイテムの購入履歴など、データの一貫性と耐久性が必要なデータは Amazon Aurora などのリレーショナルデータベースに保存し、セッション情報や一時的に高頻度で使われるデータは Amazon ElastiCache などのインメモリデータベースにキャッシュすることが一般的です。一方で、これらのデータベースに保存しないゲームバックエンドのアクセスログや、ゲームサーバーで出力されるユーザーの行動ログ、およびアプリケーションが出力するエラーログといった様々なログはログ収集サービスを使用してログ保管用のストレージに蓄積します。リレーショナルデータベースに保存されているユーザーのプレイ状況やゲームの売り上げといったデータとログに記録されているユーザーの行動を組み合わせて分析するためには以下のアーキテクチャ図のようなデータ収集の仕組みが必要となります。 図1：ゲームのサーバサイドとデータ分析基盤のアーキテクチャ データ分析基盤は「データ収集」、「保管」、「分析」、「可視化」の4つのレイヤーで構成されます。 データ収集レイヤーでは、データベースなどのデータソースからデータを抽出して、分析レイヤーで分析がしやすいフォーマットに加工、圧縮を行います。このアーキテクチャでは、データベースのデータを、サーバーレスなデータ統合サービスである AWS Glue を使用して抽出、加工します。ゲームバックエンド、およびゲームサーバで生成されたログは Amazon CloudWatch 、またはログストリーミングしたデータをストレージや分析サービスに容易に連携できる Amazon Data Firehose を使用して収集します。 保管レイヤーでは、データ収集レイヤで抽出、加工したデータを  Amazon S3 で保管します。 分析レイヤーでは、データの可視化や分析に使用するデータを作成するために、 Amazon Redshift Serverless を使用します。 Amazon Redshift Serverless はデータウェアハウスサービスである Amazon Redshift のServerlessオプションで、お客様にクラスタの管理をいただく必要はなく、処理を行った分だけお支払いをいただく料金モデルとなっています。 可視化レイヤーでは、分析レイヤーで集計されたデータをBIツールである Amazon QuickSight を使用します。 Amazon QuickSight はお客様にインフラを管理いただく必要はありません。 これらのサーバーレスなAWSのデータ分析サービスを組み合わせて、ご利用いただくことで、サービスの規模に応じた料金と柔軟なスケールメリットを享受することができ、データ分析基盤の効率的な実装と運用を実現することができます。 Amazon QuickSight について Amazon QuickSight は、クラウドネイティブなサーバーレスの BI ツールです。お客様による分析用サーバーのセットアップは必要なく、すぐに使いはじめて、お手元のデータを分析することが可能です。また、少人数での小規模利用から数万人規模の大規模活用まで、利用人数に応じた柔軟なスケーリングが可能です。他のAWS サービスとネイティブに統合されており、お客様に必要とされる堅牢なセキュリティを備えたデータ分析環境を迅速に構築することができます。詳細は、 Amazon QuickSight の特徴 やこちらの ブログ記事 にて解説されています。また、 Amazon QuickSight は月額課金となっており、ご利用いただくユーザー数に応じた従量課金で料金が発生します。そのため年単位でのライセンス契約などは必要なく、ご利用者数の増減に対して細やかに対応できます。 デモダッシュボード QuickSight Demo Centralのデモは以下のユースケースを元に作られています。 ユースケース ペルソナ – ダッシュボードの利用者 ゲームプロデューサー、ゲームディレクターなどゲームの企画運営に関わる方 ゲームバックエンドの開発・運用に関わる技術者の方で、チームにデータ分析を導入したいと考えている方 ストーリー ゲームパブリッシャーのA社では日本国内ユーザー向けの Free-To-Play のモバイルゲームを企画、開発、運用している。今まではゲームタイトルごとの月毎の売上、 DAU（Daily Active User）などの基本的な KPIデータの収集のみを行なっていた。ゲームのアップデート内容は、ゲームプロデューサーとゲームデザイナーが自身のアイデアや過去の経験などの定性的な情報のみに基づいて意思決定をしている。アップデートに対するユーザーの反響が良い場合も多々あったが、追加するゲーム要素、ゲームバランス調整などの改善の効果を計測することができず、意思決定が正しかったのかデータに基づいて定量的に検証することができない。また、想定していなかったキャラクターが流行した際には効果の測定と検証をする仕組みがないため流行した理由が分からず、反響の大きかった要因を分析して論理的に説明できないことも課題であった。昨今ではゲームからユーザーが早期離脱してしまい、ゲームタイトルがリリースから1年未満の短期間でサービス終了となることも珍しくない。ゲーム開発には数億円規模の投資がされており、投資資金の回収、計画した利益の創出といったビジネス目標の達成には、定常的なゲームサービスの状況把握、定量的なデータに基づいた仮説検証、および継続的な改善によるゲームサービスの長期運営が必要となる。 A社では新規タイトルとして得意領域であるマルチプレイヤーに対応したロールプレイングゲームの開発を決定した。このゲームの課金要素はゲーム内通貨のジェムである。ユーザーはこのジェムを使用してガチャを購入することで、ランダムに抽選された、武器または防具を入手できる。プレイヤーは戦闘で得た経験値でキャラクターのレベルを上げ、より強い武器と防具を使用することで、ゲームを有利に進めていくことができる。人気のあるアニメ作品や漫画とのコラボレーションによるイベントの開催も集客要素の一つとして計画した。このコラボレーションイベントに合わせた期間限定ガチャを提供することで、プレイヤーの購買意欲を高める戦略とした。 A社はビジネス目標を確実に達成するために、アイデアや過去の経験などの定性的な情報に加えて、データ分析基盤で収集した定量的なデータを用いて、ゲームサービスの状況把握と継続的な改善に取り組むこととした。 データの分析例 データ分析のポイントは２つあります。１つ目は可視化することでデータの変化を一目で確認できること、２つ目は売上や Active Users などの基本的なビジネスKPIとユーザー行動の両面で分析することです。可視化によって、ゲームのアップデートや施策をユーザーに提供したタイミングと、ユーザー行動やビジネスKPIの変化を時系列順に確認できます。これにより、あるアップデートや施策によって、ユーザー行動がどのように変化し、どれくらいKPIに影響があったかを効率よく確認することができます。 ではQuickSight Demo Centralの画面を見てみましょう。ゲームのKPI分析の例は[図2]のとおりです。このダッシュボードの一番上[図2(1)]にゲームの主要なKPIを表示しています。これらのKPIはすべて、ゲームビジネスの売上にかかわる指標です。主要KPIを表示することで、ビジネス目標の達成状況が一目でわかります。「売上合計」はある期間にゲームで売り上げた金額の合計です。これは、ゲームビジネスにおいて最も重要なKPIです。「Active User」 は指定した期間に遊んでくれたプレイヤーの数、「Average Revenue Per Paid User（ARPPU）」は課金しているプレイヤー１人あたりの平均売上金額、「新規ユーザ数（新規インストール数）」は指定した期間に新たにゲームに参加したプレイヤー数です。 図2：KPI分析シート/主要KPI・KPI時系列分析 このダッシュボードでは、[図2(2)]のそれぞれのグラフで、 KPI の日ごとの変化を時系列に一目で確認できます。これらのデータの推移と施策を実施したタイミングを照らし合わせて分析することで、実施した施策が各KPIにどのように影響したのか容易に確認できます。Free-To-Playにおいて課金/無課金プレイヤーは大きく異なり、ゲームビジネスを継続するためには、課金プレイヤーにいかに満足してもらいながら対価を支払ってもらえるかが重要です。 ARRPU の変動を分析することで、ゲームサービスがその対価を支払うに値し続けているかを確認することができます。ARRPUを上げることが必ずしも正解ではなく、一時的に上がった後に下がってしまった場合は、短期的に課金のプレッシャーが高まってしまい、ユーザエンゲージメントが下がってしまった可能性があります。ARRPUの変動と合わせて確認したいのが Conversion Rate（CVR） です。 Conversion Rate は、その日の Active User の中で課金したユーザの割合を示しています。新しい商品を追加した時に、ARPPUは変動させずに課金ユーザー数を増やしたいのか、既に課金しているユーザーの中でよりコアなユーザーに購入してもらいたいかなど、 ARPPU と CVR がどのように変動することが好ましいかは目的や状況によって異なります。 KPI の項目ではありませんが、[図2(3)]の7日間継続率も重要な指標の一つです。これは、ゲームに新規登録したプレイヤーのうち、7日後以降も継続しているユーザーの割合です。ゲームビジネスを長期的に運用していくためには、プレイヤーにゲームをインストールしてもらうだけでなく、日々継続して遊んでもらうことも必要です。一般的に新規登録から7日経過して継続して遊んでもらえていれば、そのプレイヤーは定着していると考えることが出来ます。7日間継続率が低いことを検知した場合、チュートリアルに離脱ポイントがないか、レベルデザインに問題があってある程度プレイヤーがゲームを進めたところで一気に難易度が上がり離脱に繋がっていないかなど、離脱要因の分析に繋げることができます。 以下の[図3]では課金要素であるガチャの売上推移を確認できます。ガチャはユーザーの課金要素であるため売上と密接な関係があります。ガチャの売上の推移とKPIの変化の両方を照らし合わせて確認することで、ゲームの改善内容やガチャで入手できるアイテムのアップデートが売上をはじめとする各KPIにどのように影響したのかを効率よく確認することができます。 図3：KPI分析シート/ガチャ回転数推移 以下の[図4]では、インゲームの要素であるイベントのエントリー人数の時系列の変化と合わせて確認することで、この例では実施したイベントが売上や DAU にどのような影響を与えたのか分析することがでます。またイベントごとの参加ユニークユーザ数を一目で確認することが出来ます。 図4：KPI分析シート/イベント分析 このようにゲーム内の施策がゲームビジネスにどのように影響しているかデータに基づいて計測し、当初の想定と比較することで改善点を導出して次の施策に繋げられていると、ゲームの企画運営にデータ分析を活用していると言えるのではないかと思います。 Amazon Quicksightの技術的なポイント このダッシュボードでは、 Amazon Quicksight の技術的なポイントが２点あります。１点目はKPIを計算フィールドを用いて算出していること、２点目は複数のデータセットに対してクロスデータセットフィルターを使用してダッシュボードを作成している点です。計算フィールドを用いることで、データの計算や集計処理したデータを準備することなく、ダッシュボードを作成するタイミングで実装することができ、変更も容易になります。このことにより、ゲームの機能開発が優先される中で後からデータ分析を導入する場合でも、データの前処理から可視化まで Amazon QuickSight で完結できます。また、クロスデータセットフィルターを使用することで、今回のダッシュボードのように複数のデータセットを組み合わせて使用するダッシュボードのフィルタ制御を単一のコントロールで行うことができます。ある施策がある期間にどのような影響を与えたか、ビジネスKPIからユーザー行動まで複数のデータセットに跨って分析をする必要があるため、それら複数のデータセットを単一のコントロールで制御できる機能はゲーム分析に適しています。 まとめ 本記事では、ゲームサービスにおけるデータ分析の重要性、データ分析基盤導入の課題と、その課題を解決しすぐにデータ分析を始めるための参考として Amazon QuickSight のデモをご紹介しました。ゲームサービスをビジネスとして成功させるためには、ゲームサービスを継続して改善しユーザーのニーズに応え続けることが求められます。この継続的な改善を迅速かつ的確に行うために、ゲームデザイナーの勘や経験から導出された定性的な情報だけでなく、定量的なデータを分析、可視化して組み合わせて活用することが重要です。 本記事がデータ分析基盤の導入、およびお客様のゲームビジネスの成功のお役に立てば幸いです。 著者/開発者紹介 坂本 達哉 アマゾン ウェブ サービス ジャパン合同会社 テクニカルアカウントマネージャ 2021年にAWSに入社し、テクニカルアカウントマネージャ（TAM）として、ゲーム業界のお客様を中心に、 AWS 活用支援を担当しています。   渡邉 真太郎 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト モバイルゲームの開発会社2社でサーバーサイドエンジニアとして従事し現職。 普段はゲーム業界向けのソリューションアーキテクトとしてゲーム開発に携わるお客様をご支援しております。

本ブログは 2023 年 10 月 10 日に公開されたBlog “ How AWS protects customers from DDoS events ” を翻訳したものです。 Amazon Web Services (AWS) では、セキュリティが最優先事項です。セキュリティは私たちの文化、プロセス、システムに深く根付いており、私たちのあらゆる活動に浸透しています。これはお客様にとってどういった意味があるのでしょうか。AWSは、お客様に影響を与えるセキュリティインシデントの防止と緩和に向けた取り組みについて、お客様により深く理解していただくことが有益だと考えています。 2023 年 8 月下旬以降、AWS は新種の分散型サービス妨害 (DDoS) 攻撃を検出し、お客様アプリケーションを保護してきました。DDoS 攻撃とは、ウェブサイトやアプリケーションなどの対象システムの可用性を妨害し、正規ユーザーに対するサービスのパフォーマンスを低下させようとすることです。 DDoS 攻撃方法の例 には、HTTP リクエストフラッド、リフレクション攻撃(アンプ攻撃)、パケットフラッドなどがあります。今回 AWS が検出した DDoS 攻撃は、HTTP/2 リクエストフラッドの一種で、ウェブサーバーの能力を超える大量の不正なウェブリクエストを送って、正規のクライアントからのリクエストに応答できないようにする攻撃です。 2023 年 8 月 28 日から 29 日にかけて、AWS のプロアクティブな監視により Amazon CloudFront への HTTP/2 リクエストの異常な急増を検出しました。ピーク時には 1 秒あたり 1 億 5500 万リクエスト (RPS) を超えるリクエストを観測しました。AWS は数分以内にこの異常な活動の性質を特定し、CloudFront が新種の HTTP リクエストフラッド DDoS イベント（現在は HTTP/2 ラピッドリセット 攻撃と呼ばれています）を自動的に緩和していました。この 2 日間で、AWS は HTTP/2 ラピッドリセット攻撃について 10 件以上の 一連のイベントを観測し軽減しました。そして続く 9 月も、この新種の HTTP/2 リクエストフラッドが引き続き発生していたことを確認しています。Amazon CloudFront や AWS Shield などのサービスを使用して DDoS 耐性を施したアーキテクチャを構築していた AWS のお客様は、アプリケーションの可用性を維持することができました。 図1. 世界の 1 秒あたりの HTTP リクエスト数、9 月 13 日～16 日 HTTP/2 ラピッドリセット攻撃の概要 HTTP/2 では、1 つの HTTP セッション上で複数の異なる論理接続を多重化できます。これは、各 HTTP セッションが論理的に分かれていた HTTP 1.x からの変更点です。HTTP/2 ラピッドリセット攻撃は、リクエストとリセットを短時間に連続して行う複数の HTTP/2 接続で構成されます。例えば、複数のストリームに対する一連のリクエストが送信され、その後それぞれのリクエストに対するリセットが続きます。攻撃対象システムは各リクエストを解析して処理し、クライアントによってリセット（またはキャンセル）され、さらにリクエストのログも生成します。クライアントにデータを送り返す必要がなくても、システムはそれらのログを生成します。悪意のある攻撃者は大量の HTTP/2 リクエストを発行することで、このプロセスを悪用しウェブサイトやアプリケーションなどの攻撃対象システムのリソースを枯渇させることができます 重要なのは、HTTP/2 のラピッドリセット攻撃も、HTTP リクエストフラッドの新しい形態に過ぎないことです。このような種類の DDoS 攻撃から防御するには、不要なリクエストを特定して検出し、悪意のある HTTP リクエストを吸収してブロックするような、スケーリング可能なアーキテクチャを実装する必要があります。 DDoS 耐性のあるアーキテクチャの構築 AWS のお客様は、AWS のグローバルクラウドインフラストラクチャに組み込まれたセキュリティと、AWS サービスのセキュリティ、効率性、および回復力を継続的に改善するという当社のコミットメントの両方から恩恵を受けることができます。DDoS 耐性を向上させるための具体的なガイダンスとして、AWS は AWS Best Practices for DDoS Resiliency などのホワイトペーパーを公開しています。このドキュメントでは、アプリケーションの可用性を保護するためのガイドとして、DDoS 耐性を持つリファレンスアーキテクチャを説明しています。AWS サービスには複数の DDoS 緩和のための組み込み機能が自動的に含まれていますが、特定のサービスを使用した AWS アーキテクチャを採用し、ユーザーとアプリケーション間のネットワークフローの各部分に追加のベストプラクティスを実装することで、DDoS 耐性をさらに向上させることができます。 例えば、 Amazon CloudFront 、 AWS Shield 、 Amazon Route 53 、 Route 53 Application Recovery Controller などのエッジロケーションから運用される AWS サービスを使用して、既知のインフラストラクチャレイヤーへの攻撃に対する包括的な可用性保護を構築できます。これらのサービスは、世界中に分散したエッジロケーションからあらゆるタイプのアプリケーショントラフィックを提供する際に、アプリケーションの DDoS 耐性を向上させることができます。オリジンのアプリケーションは AWS 上でもオンプレミスであっても、これらの AWS サービスを使用して不要なリクエストがオリジンサーバーに到達するのを防ぐことができます。ベストプラクティスとして、アプリケーションを AWS 上で実行することで、アプリケーションエンドポイントが DDoS 攻撃にさらされるリスクを軽減し、アプリケーションの可用性を保護して、正規ユーザーに対するアプリケーションのパフォーマンスを最適化できます。Amazon CloudFront (HTTP キャッシュ機能を含む)、 AWS WAF 、Shield Advanced による自動アプリケーションレイヤー保護を使用すると、アプリケーションレイヤーの DDoS 攻撃中に不要なリクエストがオリジンに到達するのを防ぐことができます。 AWS のお客様のための知識を活かす AWS は、セキュリティ課題がお客様のビジネスに混乱をもたらすことを防ぐため、絶えず注意を払っています。AWS はサービスの設計方法だけでなく、エンジニアがサービスのあらゆる側面に対して深い責任感を持って積極的に取り組んでおり、そのことをお客様に共有することが重要だと考えています。インフラストラクチャとお客様のデータを守る取り組みの中で、お客様を自動的に保護する方法を常に模索しています。可能な限り、AWS セキュリティとそのシステムは、最も効果的な場所で脅威を阻止します。多くの場合、この作業は主に舞台裏で行われています。グローバル規模の脅威インテリジェンスとエンジニアリングの専門知識を組み合わせることで、悪意のある活動に対してサービスの耐性を高め、脅威を軽減するよう努めています。AWS は、Amazon CloudFront などのサービスで使用するプロトコルや、AWS WAF、AWS Shield、 Amazon Route 53 Resolver DNS Firewall などの AWS セキュリティツールなど、サービスの効率性とセキュリティの向上に常に取り組んでいます。 さらに、AWS の取り組みは、AWS 自体の範囲をはるかに超えて、セキュリティ保護と改善を拡大しています。AWS はコンピュータ緊急対応チーム (CERT)、インターネットサービスプロバイダー (ISP)、ドメインレジストラ、または政府機関などの幅広いコミュニティと定期的に連携し、特定された脅威を阻止するのを支援しています。また、セキュリティコミュニティ、他のクラウドプロバイダー、コンテンツデリバリーネットワーク (CDN)、および世界中の協力企業と密接に連携して、脅威アクターを隔離して排除しています。例えば、2023 年第 1 四半期には、130 万件以上のボットネットによる DDoS 攻撃を阻止し、23 万件の L7/HTTP DDoS 攻撃の発信源を追跡して外部機関と協力して解体しました。私たちの緩和戦略の有効性は、脅威インテリジェンスを迅速に捕捉、分析、行動に移す能力に大きく依存しています。こうした取り組みを通じて、AWS は一般的な DDoS 攻撃から防御するだけでなく、保護の範囲は AWS の範囲を越えて拡大しています。この取り組みの詳細については、 AWS 脅威インテリジェンスによる脅威アクターの阻止 をお読みください。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 AWS セキュリティに関するニュースにご興味がある場合は、 X をフォローしてください。 Mark Ryland Mark は、バージニア州を拠点とする Amazon のセキュリティディレクターです。技術業界で 30 年以上の経験を持ち、サイバーセキュリティ、ソフトウェアエンジニアリング、分散システム、技術標準化、公共政策の分野でリーダーシップを発揮してきました。AWS で 12 年以上のキャリアを持ち、最初は AWS Worldwide Public Sector チームのソリューションアーキテクチャおよびプロフェッショナルサービスのディレクターとして勤務し、最近では AWS Office of the CISO を設立し、リードしました。 Tom Scholl Tom は AWS の Vice President 兼 Distinguished Engineer です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

生成 AI のポテンシャルが幅広く認知される中、様々な業界で活用に向けた試行錯誤が続いています。そこで多くの組織が気づきはじめているのは、この最先端テクノロジーを 単に社内で使えるようにするだけでは不十分だ ということです。生成 AI は顧客体験の向上から内部プロセスの合理化まで、業務の様々な側面を革新する可能性を秘めています。しかし、顧客やビジネス知識がなければビジネスインパクト、技術の専門知識がなければ実現コストを評価できず、それぞれを評価できるメンバーが連携しなければ結果として ROI を正確に見積もることは困難です。つまり、組織横断の連携とそれを可能にする経営からの支援がなければ、生成 AI の導入効果は不透明で必要十分な投資を行うことはできないということです。 Gartner の “ 2025 年までに生成 AI プロジェクトの 3 分の 1 が停止する ” との予言は、まさに不透明な ROI に起因しています。 AWS の 100 を超える生成 AI の事例から得られる知見 でも、下図のように Technology 、生成 AI の活用には顧客起点文化を持つ People、小規模なチームや頻繁な実験といった迅速な仮説検証を可能にする Process が重要であるとしており組織とプロセス、それらを支える文化が生成 AI の活用に不可欠であることを示唆しています。 生成 AI の力を本当に活用するなら、経営戦略としてビジネス、技術、双方にかかわる組織から クロスファンクショナルなチームを組成することを最優先に行うべきです 。AWS が無償で公開する ML Enablement Workshop はまさにそのための方法論です。 ML Enablement Workshop は 1) 経営層の支持のもとプロダクトマネージャーなどのビジネスサイド、エンジニア・データサイエンティストなどの技術サイドのリーダー・メンバーを招集したチームを組成する、 2)  Amazon のプロダクトづくりのプロセスに基づきプロダクト・サービスの持続的な成長につながる AI/ML のユースケースを特定する、3) 1~3 ヵ月で最初の効果を確認するためのロードマップを作成する 3 つのプロセスを短期で行うワークショップです。本ワークショップを通じお客様が成果を上げられる様子を見て、生成 AI の活用においてチームの組成が鍵であることに確信を持っています。本記事では、その気づきを共有すべく事例を中心にご紹介します。 事例 1 : 組織横断チームでの顧客体験分析 (株式会社ココペリ) ココペリ様の事例は、プロダクトマネージャー、開発者、カスタマーサクセスチーム、データサイエンティストを集め、顧客体験を全員で、全体にわたり分析することの重要性を示しています。 ML Enablement Workshop を通じ、中小企業向の DX 化を支援するプロダクト Big Advance における顧客体験を端から端まで分析し、生成 AI の有効なユースケースを特定。成功を測る KPI と実現に向けたタスクを整理し、ワークショップ終了直後からプロジェクトを始めることができました。 生成 AI は中小企業のビジネスマッチングに活用されており、その詳細は AWS Blog として公開されています 。中小企業ではまだ生成 AI の利用率が低い現状がありますが、Big Advance を通じ生成 AI が中小企業の事業機会の創出に貢献しています。 事例 2 : ビジネス効果駆動で営業 DX を実現  (株式会社三菱 UFJ 銀行) 三菱 UFJ 銀行様の事例は、ビジネス部門が顧客への効果を確認し、技術部門が効果が確認された価値創出プロセスを生成 AI で効率化する ビジネス効果駆動での生成 AI の活用 を進められています。営業部門、データサイエンティスト部門を巻き込み ML Enablement Workshop を実施することで、DX 化された営業プロセスのあるべき姿と実現に向けたロードマップを策定しました。ワークショップ終了後 3 ヵ月で最初の顧客提案を行い提案そのものの有効性を確認し、並行してデータサイエンティストのチームが提案の作成の自動化プロセスを実現しています。この緊密な連携が、営業 DX 推進の鍵となっています。さらに、データサイエンティストのチームは、 AWS のプロトタイピング支援により部門職員が利用できるアプリケーション開発のスキルも獲得し、アジャイルな改善プロセスを内製化しています。 三菱 UFJ 銀行様のこの取り組みは、 日本の金融機関初の re:Invent 登壇 として re:Invent 2024 の金融トラックセッションで発表されます。ぜひご視聴ください！ FSI202 | Beyond productivity: Using generative AI to grow in financial services The present has caught up with the future in financial services. New generative AI capabilities have helped financial institutions automate labor-intensive tasks like extracting information from unstructured data sources, summarizing complex documents, and curating market intelligence. These investments in improving productivity have paved the way for the industry to focus on harnessing generative AI to create business value. Companies are engaging more meaningfully with their customers, identifying sales opportunities more efficiently, increasing lead conversion, and driving adoption of new products. Hear from industry leaders how they built and are running new growth-focused generative AI applications in production on AWS. John Kain, Head Financial Service Market Development, Amazon Web Services Tetsuo Horigane, Director, MUFG Bank, Ltd. Aaron Linsky, CTO – AIA Labs, AIA Labs @ Bridgewater Associates Sunny Fok, SVP, Head of AI Innovation Technology, Crypto.com 事例 3: 経営主導の迅速な意思決定と実装 (株式会社セゾンテクノロジー) セゾンテクノロジー様は、CTO 自ら主導してクロスファンクショナルなチームを組成し、生成 AI 活用を推進しています。ML Enablement Workshop では企画、営業、エンジニア、生成 AI 有識者からなるチームを結成し、競合を含めた生成 AI 活用事例をもとに最適なソリューションを検討、2 週間という短期間で経営陣の合意を得て修了後 3 ヵ月で HULFT Square への AI アシスタント機能の実装を完了しています。 セゾンテクノロジー様の取り組みは、 AI Day 2024 のまさに “生成AIを PoC の次のステップに進めるために” と題したトラックで発表頂きます。ぜひご視聴いだたければ幸いです！ 事例 4: 5 ヵ月で本番リリース、さらに特許出願へ (株式会社ペライチ) ペライチ様では、AWS の生成 AI 活用開始プログラムを通じ迅速なユースケースの決定とプロトタイピングを進め、 5 ヵ月という短期間で 本番リリース、プレスリリース、そしてコア機能の特許出願まで進まれています 。本プログラムでは、EC 業界に特化することで ML Enablement Workshop のユースケース決定のプロセスを短縮するとともに、プロトタイピングプログラムと組み合わせて実装面の支援、さらに AWS クレジットの支援という予算的な支援を複合することで生成 AI 活用における代表的な 3 つのブロッカー、「決まらない」「開発リソースがない」「予算がない」の 3 点をオールクリアしました。このプログラムを通じ、ペライチ様はウェブサイト制作時間を 10 営業日以上から 10 分と劇的に短縮する「 ペライチクリエイトアシスタント 」を開発・リリースされています。本プログラムでは オズビジョン様 、 ナビプラス様 も本番稼働、事例化しており AWS Blog で詳細を公開いただいています。本プログラムではビジネス、技術双方の意思決定者がプログラムに参加いただくよう依頼しており、組成されたクロスファンクショナルなチームが技術・予算の支援を受けるとインパクトのあるユースケースが短期間で実現することを示す実例となりました。 ペライチ様の取り組みもまた、 AI Day 2024 の “事例で学ぶ生成 AI 活用と気になる責任ある AI の実践ポイント” と題したトラックで発表を頂きます。ぜひご覧ください！ 結論 経営層の支持に基づくクロスファンクショナルなチームの構築は生成 AI 活用の第一歩にして最重要のプロセスです 。この基盤に、ユースケースを確定するためのワークショップ、プロトタイピング実装支援、予算面の支援といった AWS のプログラムリソースが加わることで劇的な速さで差別化につながる価値を創出できることを 4 つの事例を通じ示しました。 ぜひ、生成 AI の力を活用する第一歩として、自社の組織文化や構造を評価し、効果的なクロスファンクショナルチームの構築を検討いただければ幸いです。 ML Enablement Workshop はまさにそのための方法論であり、 資料はすべて GitHub で公開されています 。本資料を自身で活用いただくことはもちろん、実施に関心がある方は AWS 担当までぜひお問い合わせください。本記事が、皆さんの組織の中で生成 AI の活用を促進、あるいは停滞を解消する鍵となれば幸いです。

本記事は 2024 年 10 月 8 日に公開された “ Amazon ElastiCache and Amazon MemoryDB announce support for Valkey ” を翻訳したものです。 AWS は設立以来、お客様がクラウドでオープンソースソフトウェアを構築・実行するための最適な場所となっています。AWS は、オープンソースプロジェクト、財団、パートナーを支援することを誇りにしています。私たちは、オープンソースが誰にとっても有益であると考えており、お客様にオープンソースの価値を、そしてオープンソースコミュニティに AWS の運用上の優秀性を提供することに尽力しています。 2024 年 3 月、Redis Inc. が Redis の将来のバージョンをオープンソースではなくする と発表してから 1 週間も経たないうちに、Linux Foundation、Redis OSS の開発者、およびコントリビューターが団結して Valkey プロジェクト を立ち上げました。Valkey は、オープンソースの高性能キーバリューデータストアです。Redis OSS の代替として設計されており、Linux Foundation が管理し、活発な開発者コミュニティからの貢献により急速に改善が進んでいます。Linux Foundation の下でプロジェクトをホストすることで、ベンダーの中立性が確保され、オープンソースライセンスが単一の組織の意向で取り消されたり変更されたりすることがないという安心感をコミュニティに提供しています。プロジェクト開始から 6 ヶ月で、50 万回以上のコンテナのダウンロード、数千件の貢献、40 社以上の企業からのサポートを得て、Valkey は急速に採用が進んでいます。 2024 年 10 月 8 日より、フルマネージド型インメモリサービスである Amazon ElastiCache と Amazon MemoryDB で Valkey 7.2 のサポートを開始しました。このブログでは、AWS の Valkey への貢献、ElastiCache と MemoryDB のお客様に Valkey をより利用しやすくするための AWS の取り組み、そしてお客様のアプリケーションでの Valkey の使用開始方法について説明します。 AWS の Valkey への貢献 AWS は Redis OSS への貢献の長い歴史を持っています。例えば、AWS は以前、Redis OSS 7 に キーとコマンドに対する細かなアクセス制御 、TLS セキュリティを可能にする クラスター構成のネイティブホスト名サポート 、そしてスケーラブルな pub/sub のための パーティション化されたチャネル など、いくつかの主要な機能を提供してきました。 今年初め、オープンソースの Valkey (および Redis OSS) 互換クライアントである Valkey General Language Independent Driver for the Enterprise (Valkey GLIDE) をリリースしました。Valkey GLIDE は、簡単に設定でき、Valkey および Redis OSS データストアに接続するための信頼性の高い方法です。GLIDE の立ち上げを決定したのは、お客様から、クライアントの設定ミス、不適切な接続管理、観測性の欠如により、オープンソースクライアントを使用する際にアプリケーションへの予期せぬ影響を軽減したいという声があったためです。GLIDE は、私たちの運用経験を活かしてお客様のワークロードの信頼性を向上させた一例です。アクティブな接続管理などの技術を使用することで、お客様は GLIDE をクライアントとして使用する際、予期せぬ障害時のアプリケーションの問題を減らすことができます。GLIDE は Java、Python、Node.js で利用可能で、また Go 実装についてもオープンソースコミュニティと協力して開発を進めています。 AWS は、パフォーマンスと信頼性の分野を含め、 オープンソースの Valkey 8.0 にも貢献しました。Valkey 8.0 の重要な機能の 1 つは、 新しい I/O スレッディングアーキテクチャ の導入で、これによりシステムの並列性が向上し、コマンドをより効率的に実行できるようになりました。この新しいアーキテクチャは、Redis OSS 7.2 のフォークである Valkey 7.2 と比較して、最大 230% 高いスループットと最大 70% 優れたレイテンシーを実現します。AWS はまた、 メモリオーバーヘッドを最大 20.6% 削減するメモリ最適化 にも貢献し、以前のバージョンと同じメモリ容量でより多くのデータを保存できるようになりました。 ElastiCache for Valkey 数十万のお客様が、アプリケーションのパフォーマンス向上、スケーラビリティの向上、コストの最適化を実現するために Amazon ElastiCache を使用しています。Prime Day 2024 では、 ElastiCache は 1 分あたり 1 兆リクエスト以上のピークを記録し、1 日で 1000 兆を超えるリクエストを処理しました 。ElastiCache for Valkey により、お客様はオープンソース技術に基づいたフルマネージド型のエクスペリエンスを活用しながら、ElastiCache が提供してきた 13 年以上の運用上の優秀性、セキュリティ、信頼性を活用できます。 本日( 訳註： 2024 年 10 月 8 日 )の発表により、AWS は Valkey をより多くのお客様にご利用いただけるようになりました。ElastiCache Serverless for Valkey の価格は、ElastiCache Serverless for Redis OSS と比べて 33% 低く、ノードベースの ElastiCache for Valkey は、他のノードベースの ElastiCache エンジンと比べて 20% 低く設定されています。ElastiCache Serverless for Valkey の最小キャッシュサイズは 100MB で、ElastiCache Serverless for Redis OSS の 1GB と比べて小さくなっています。これらの価格変更により、お客様はより低価格で Valkey の利用を迅速に開始できるようになりました。たとえば、お客様は ElastiCache Serverless for Valkey を使用して、1 分以内にキャッシュを作成でき、月額 6 ドルからご利用頂けます。さらに、ElastiCache のリザーブドノードをご利用のお客様は、ElastiCache for Redis OSS から ElastiCache for Valkey に簡単に切り替えることができ、同じファミリー内のすべてのノードサイズで既存の割引されたリザーブドノードレートを維持できます。 MemoryDB for Valkey Amazon MemoryDB は、Valkey および Redis OSS 互換の耐久性を持ったインメモリデータベースサービスで、超高速のパフォーマンスを提供します。MemoryDB では、データがメモリに格納されるため、マイクロ秒単位の読み取りと 1 桁ミリ秒の書き込みレイテンシー、高いスループットを実現できます。本日( 訳註： 2024 年 10 月 8 日 )より、MemoryDB でも Valkey 7.2 を利用できるようになりました。MemoryDB for Valkey は、MemoryDB for Redis OSS と比較して 30% 低価格です。ElastiCache と同様に、MemoryDB のリザーブドノードを使用しているお客様は、MemoryDB for Redis OSS から MemoryDB for Valkey に簡単に切り替えることができ、同じファミリー内のすべてのノードサイズで既存の割引されたリザーブドノードレートを維持できます。 今後の展望 Valkey プロジェクトのサポーターとして、私たちは Valkey 開発者の幅広いコミュニティと協力し、最も機能豊富なインメモリ型キーバリューデータストアを構築し、これらのイノベーションを ElastiCache と MemoryDB にもたらします。 ElastiCache for Valkey と MemoryDB for Valkey は、これらのサービスをサポートするすべての AWS リージョンで利用できるようになりました。ElastiCache for Valkey と MemoryDB for Valkey の使用開始方法については、 Amazon ElastiCache for Valkeyの開始方法 、 Amazon MemoryDB for Valkeyの開始方法 のステップバイステップガイドをご参照ください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Rashim Gupta は AWS のシニアマネージャー、プロダクトマネジメントで、Amazon ElastiCache と Amazon MemoryDB のプロダクト責任者を務めています。AWS で 6 年以上の経験を持ち、コンピュート、ストレージ、データベースの分野でプロダクトマネージャーとして活躍しています。

本記事は 2024 年 10 月 8 日に公開された “ Get started with Amazon MemoryDB for Valkey ” を翻訳したものです。 2024年10月8日、 Amazon MemoryDB は Valkey バージョン 7.2 のサポートを発表しました。これは、Amazon MemoryDB for Redis OSS と比較してインスタンス時間あたりの料金が 30% 低くなっています。MemoryDB for Valkey では、月間 10 TB までのデータ書き込みに対して料金は発生せず、10 TB を超えるデータ書き込みに対しては 1 GB あたり 0.04 ドルで課金されます。Valkey は、Linux Foundation が管理し、40 社以上の企業が支援するオープンソースの高性能キーバリューデータストアです。Valkey は Redis OSS の代替として、長年 Redis OSS のコントリビューターおよびメンテナーを務めてきた開発者によって開発されました。2024 年 3 月のプロジェクト開始以来、急速に採用が進んでいます。AWS は Valkey プロジェクトに 積極的に貢献 しています。この発表により、お客様はオープンソース技術に基づいて構築されたフルマネージド型のエクスペリエンスを享受しつつ、ElastiCache が提供してきた 13 年以上の運用の卓越性、セキュリティ、信頼性を活用できるようになります。 この記事では、MemoryDB for Valkey の概要、その利点、そして MemoryDB for Redis OSS データベースを MemoryDB for Valkey データベースにアップグレードする方法について説明します。 MemoryDB for Valkey の概要 Amazon MemoryDB は、Valkey および Redis OSS 互換の、耐久性のある、インメモリデータベースサービスで、超高速のパフォーマンスを提供します。MemoryDB は、分散トランザクションログを使用して複数のアベイラビリティーゾーン (AZ) にわたってデータを耐久性をもって保存し、高速なフェイルオーバー、データベースの復旧、ノードの再起動を可能にします。MemoryDB for Valkey は、ユーザーセッションデータ、メッセージストリーミング、ゲームのリーダーボードなど、耐久性のあるストレージと超高速のパフォーマンスを必要とするアプリケーションに使用できます。MemoryDB for Valkey は、AWS 上の一般的なベクトルデータベースの中で、最高の再現率で最速のベクトル検索パフォーマンスを提供します。MemoryDB は高可用性を提供し、データ階層化によってより低コストでスケーリングできます。AWS は MemoryDB を通じて Valkey をマネージドサービスとして提供することで、お客様自身で Valkey を管理する運用負荷なしに、その広範な機能を活用できるようにします。MemoryDB for Valkey は現在、MemoryDB がサポートされているすべての AWS リージョンで利用可能です。 MemoryDB for Valkey の利点 低価格: MemoryDB for Valkey では、MemoryDB for Redis OSS と比較してインスタンス時間あたりの価格が 30% 低く、月間 10 TB までのデータ書き込み料金が無料になり、コストを最適化できます。10 TB を超えるデータ書き込みについては、MemoryDB for Redis OSS と比較して 80% 低い 1 GB あたり 0.04 ドルの価格設定となっています。 パフォーマンス: MemoryDB は、読み取りにマイクロ秒単位の応答時間、書き込みに一桁ミリ秒の応答時間を必要とする高性能アプリケーション向けに構築されています。 運用の卓越性: MemoryDB for Valkey は、オープンソース技術を基盤とし、AWS のセキュリティ、運用の卓越性、99.99% の可用性、信頼性を活用したフルマネージド型のエクスペリエンスを提供します。 API 互換性: MemoryDB for Valkey は Redis OSS の API とデータ形式と互換性があり、顧客はコードの書き直しやアーキテクチャの変更なしにアプリケーションを移行できます。 ダウンタイムゼロの移行: 既存の MemoryDB for Redis OSS ユーザーは、ダウンタイムなしで MemoryDB for Valkey に迅速にアップグレードできます。 継続的なイノベーション: AWS の Valkey サポートへのコミットメントにより、顧客は安定したソリューションを採用するだけでなく、将来の成長とイノベーションに向けた準備も整えることができます。Valkey コミュニティがプロジェクトの開発と強化を続けるにつれ、AWS の顧客は継続的な改善と新機能の恩恵を受け、アプリケーションの競争力を維持できます。AWS も Valkey に積極的に貢献しており、詳細は Amazon ElastiCache と Amazon MemoryDB の Valkey サポートを発表 の記事でご覧いただけます。 ソリューションの概要 わずか数ステップで MemoryDB for Valkey を始めることができます： MemoryDB for Valkey データベースを作成します。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを作成します。 valkey-cli ユーティリティをダウンロードしてセットアップします。 アプリケーションからデータベースに接続します。 以下のセクションでこれらのステップを順を追って説明します。その後、データベースでの基本的な操作の実行方法を示します。また、MemoryDB for Redis OSS から MemoryDB for Valkey へのアップグレード方法についても説明します。 MemoryDB for Valkey データベースの作成 Amazon MemoryDB for Valkey データベースは、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または MemoryDB API を使用して作成できます。以下のコードは、AWS CLI を使用して MemoryDB for Valkey データベースを作成する例です。MemoryDB で Valkey リソースを使用するには、CLI のバージョンが最新であることを確認してください。 aws memorydb create-cluster \ --cluster-name memorydb-valkey-cluster \ --node-type db.r6g.large \ --acl-name open-access \ --subnet-group-name basic-subnet-group \ --engine valkey \ --tls-enabled \ --region us-east-1 describe-clusters コマンドを使用して、MemoryDB データベースの作成プロセスのステータスを確認できます。 aws memorydb describe-clusters \ --cluster-name memorydb-valkey-cluster \ --region us-east-1 { "Clusters": [ { "Name": "memorydb-valkey-cluster", "Status": "available", "NumberOfShards": 1, "AvailabilityMode": "MultiAZ", "ClusterEndpoint": { "Address": "clustercfg.memorydb-valkey-cluster.xxx.amazonaws.com", "Port": 6379 }, "NodeType": "db.r6g.large", "Engine": "valkey", "EngineVersion": "7.2", "EnginePatchVersion": "7.2.6", "ParameterGroupName": "default.memorydb-valkey7", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "basic-subnet-group", "TLSEnabled": true, "ARN": "arn:aws:memorydb:xxx:xxx:cluster/memorydb-valkey-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "fri:05:00-fri:06:00", "SnapshotWindow": "03:00-04:00", "ACLName": "open-access", "AutoMinorVersionUpgrade": true, "DataTiering": "false" } ] } MemoryDB for Valkey データベースへの接続のための EC2 セットアップ MemoryDB には、同じ VPC 内の EC2 インスタンスから、または VPC ピアリングを使用して異なる VPC 内の EC2 インスタンスからアクセスできます。EC2 インスタンスの作成手順については、 Amazon EC2 の開始方法 をご覧ください。 MemoryDB for Valkey データベースは、ポート 6379 を使用します。EC2 インスタンスから正常に接続し、Valkey コマンドを実行するためには、セキュリティグループがこのポートへのアクセスを必要に応じて許可している必要があります。 valkey-cli ユーティリティのダウンロードとセットアップ EC2 インスタンスに接続し、以下のコマンドを実行して valkey-cli ユーティリティをダウンロードします。 sudo yum install gcc jemalloc-devel openssl-devel tcl tcl-devel -y wget https://github.com/valkey-io/valkey/archive/refs/tags/7.2.7.tar.gz tar xvzf 7.2.7.tar.gz cd valkey-7.2.7/ make BUILD_TLS=yes install Valkey エンジンに接続してコマンドを実行するための valkey-cli の使用方法の詳細な手順については、 Valkey CLI を参照してください。 MemoryDB for Valkey データベースへの接続 MemoryDB for Valkey データベースに接続するには、AWS CLI コマンド describe-clusters を使用して新しいデータベースのエンドポイントを取得します。以下のように memorydb クラスターの設定エンドポイントを見つけることができます： aws memorydb describe-clusters \ --cluster-name memorydb-valkey-cluster \ --region us-east-1 "ClusterEndpoint": { "Address": "clustercfg.memorydb-valkey-cluster.xxx.amazonaws.com", "Port": 6379 } valkey-cli ユーティリティ を使用して MemoryDB for Valkey データベースに接続する valkey-cli -h clustercfg.memorydb-valkey-cluster.xxx.amazonaws.com -p 6379 -c --tls -h = ホスト名 -p = ポート -c = クラスターモード –tls = TLS 有効クラスター これで、MemoryDB for Valkey データベースに対して基本的な GET および SET 操作を実行する準備が整いました。以下は、Valkey において HASH オブジェクトを作成するための HSET 操作の例です。Valkey のハッシュは、フィールドと値のペアのコレクションを格納するために使用されるデータ構造です。ハッシュは、複数の属性 (名前、年齢、メールアドレスなど) を持つユーザープロファイルのように、オブジェクトを表現したり、関連データを単一のエンティティに格納したりする必要がある場合に便利です。 clustercfg.memorydb-valkey-cluster.xxx.amazonaws.com:6379> hset car:1 make ferrari model sf90spider year 2024 engine "4.0 L V8" horsepower 769hp transmission "8-speed auto" price 580000 (integer) 7 clustercfg.memorydb-valkey-cluster.xxx.amazonaws.com:6379> 前述の操作により、make、model、year、engine、horsepower、transmission、price などの属性を持つ HASH オブジェクト car:1 が作成されます。 これで、HMGET または HGETALL 操作を使用して、個別または全てのフィールドと値のペアを取得できます。 clustercfg.memorydb-valkey-cluster.xxx.amazonaws.com:6379> HMGET car:1 make model price 1) "ferrari" 2) "sf90spider" 3) "580000" clustercfg.memorydb-valkey-cluster.xxx.amazonaws.com:6379> MemoryDB for Redis OSS から MemoryDB for Valkey へのアップグレード わずか数回のクリックで、MemoryDB for Redis OSS の既存ユーザーはダウンタイムなしで MemoryDB for Valkey にアップグレードできます。以下の手順を実行してください： MemoryDB コンソールで、ナビゲーションペインの「クラスター」を選択します。 アップグレードの準備ができている MemoryDB for Redis OSS クラスターを選択します。 「修正」を選択します。 「エンジン」で、Valkey を選択します。「変更をプレビュー」を選択します。 変更の概要を確認できます。 「変更を保存」を選択して、エンジンを Redis OSS から Valkey に変更することを確認します。「クラスターは正常に変更されました。」という通知が表示されます。 既存の MemoryDB for Redis OSS データベースは Updating のステータスになります。 アップグレードが成功すると、 memorydb-redisoss-cluster は新しいエンジンタイプとして Valkey を表示し、ステータスは Available になります。 アプリケーションへの影響を最小限に抑えながら、エンジンを Redis OSS から Valkey にアップグレードしました。 クリーンアップ 最小権限の原則を維持し、将来の料金発生を避けるため、このポストの一部として作成したリソースを削除してください。MemoryDB クラスター (詳細については クラスターの削除 を参照) と EC2 インスタンス ( delete-instance ) を削除してください。 まとめ MemoryDB への Valkey サポートの追加は、アプリケーション向けの堅牢なオープンソースソリューションを提供するという AWS のコミットメントにおいて、大きな前進を表しています。まだサインアップしていない場合は、MemoryDB ページで「開始する」を選択し、サインアッププロセスを完了できます。サインアップ後、Valkey については MemoryDB の使用開始 ページを参照してください。その後、MemoryDB コンソール、AWS CLI、または MemoryDB API を使用して、数分でデータベースクラスターを作成できます。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Madelyn Olson は Valkey プロジェクトのメンテナーであり、Amazon ElastiCache と Amazon MemoryDB のプリンシパルソフトウェア開発エンジニアとして、Valkey エンジンの安全で高信頼性の機能の構築に注力しています。プライベートでは、長時間のハイキングや穏やかなサイクリングを通じて、太平洋岸北西部の自然の美しさを楽しんでいます。 Goumi Viswanathan は、Amazon インメモリデータベースチームのシニアプロダクトマネージャーです。12 年以上の製品開発経験を持ち、データベースソリューションを提供するクロスファンクショナルチームのリーダーとして活躍しています。仕事以外では、旅行やアウトドア活動を楽しんでいます。 Siva Karuturi は、テキサス州ダラスを拠点とするインメモリデータベースのワールドワイド・スペシャリスト・ソリューションアーキテクトです。Siva はさまざまなデータベース技術 (リレーショナルと NoSQL の両方) を専門とし、複雑なアーキテクチャの実装を支援し、クラウドコンピューティング、ガバナンス、セキュリティ、アーキテクチャ、高可用性、災害復旧、パフォーマンス向上を含むインメモリデータベースおよび分析ソリューションのリーダーシップを提供しています。仕事以外では、アンソニー・ボーデイン風に旅行や様々な料理を味わうことが好きです！

この記事は、 Small Business, Big Tech: Why SaaS is Your Organization’s Secret Weapon を翻訳したものです。 ペースの速いデジタル主導のビジネスの世界では、ソフトウェアは 中小企業 (SMB) の成功の礎となっています。業務の合理化や顧客関係の管理から、イノベーションの推進や生産性の向上に至るまで、ソフトウェアはビジネスを前進させる基本的な原動力です。 幸いなことに、 Software as a Service (SaaS) は画期的な武器として登場し、中小企業の期待を上回る成果を上げて、かつては大企業に限られていた最先端の機能にアクセスできるようになりました。SaaS では、多額の先行投資、社内の IT インフラストラクチャ、時間のかかるソフトウェア更新が不要になり、顧客が強力なソリューションを手頃な価格で利用できるようになります。 このブログ記事では、SaaS 企業がどのようにして公平性を生み出し、すべての中小企業がデジタル時代に成功できるようになったのかを探ります。スケーラビリティや価値を創出するまでの時間の短縮、セキュリティの強化、シームレスなコラボレーションなど、クラウドベースのアプリケーションがもたらす利点について詳しく説明します。最後には、SaaS がどのようにしてビジネスに圧倒的な競争力をもたらし、競合他社を打ち負かして長期的な成功を収めることができるかがわかります。 中小企業のジレンマ 中小企業は、予算が少なく、リソースに制約があり、ブランド認知度が限られているため、大企業との競争において重大な課題に直面することがよくあります。多くの中小企業経営者にとって、複雑なソフトウェアソリューションを実装して維持することは大きな負担となります。迅速に適応し、効率的に運用する必要性は不可欠ですが、財務上および運用上の制約により、業界をリードするソリューションにアクセスすることは困難です。このテクノロジーギャップは大きな障害となり、小規模な組織が大規模な競合他社に追いつくのを妨げています。 SaaS が救いの手を差し伸べる 従来のオンプレミスソフトウェアアプリケーションをクラウドベースのモデルに移行できる SaaS の登場は、中小企業にとって画期的な武器となりました。 顧客関係管理 (CRM) 、プロジェクト管理、会計、 カスタマーエクスペリエンスサポート などのさまざまな機能のための独自のソフトウェアアプリケーションの開発と保守ではなく、差別化された価値とブランドの構築に集中できるようになりました。 AWS Marketplace では、中小企業のあらゆるビジネス機能に役立つ 100,000 を超える SaaS ソリューションを検索できます。これらのクラウドベースの SaaS ソリューションは、データ セキュリティ 、スケーラビリティ、レジリエンシーに対応し、社内に大規模な IT スタッフやインフラストラクチャを必要とせずに効率と生産性を高めます。SaaS プロバイダーは従量課金制のライセンスを提供しているため、手頃な価格で柔軟性があります。中小企業は、多額の初期費用や長期的なコミットメントなしで、必要なものだけをサブスクライブし、必要に応じて拡張し、最小限のリスクで新しいソリューションを試すことができます。 競争力 : SaaS が中小企業の成功にどのように役立つのか オンデマンドのスケーラビリティ : SaaS ソリューションはオンデマンドの容量と価格設定を提供するため、中小企業は費用のかかるインフラストラクチャへの投資や人員変更なしに、変化するビジネス需要に適応できます。この俊敏性により、中小企業は市場の変化に迅速に対応し、新たな成長機会が生じたときにそれを活用することができます。 価値創出までの時間の短縮 : SaaS ソリューションは、従来のソフトウェア実装に通常かかる期間である数か月ではなく、数日または数週間で導入および統合できます。このように価値創出までの時間が短縮されることで、競合他社を圧倒する重要な優位性が得られ、革新的な製品やサービスを迅速に市場に投入できるようになります。 シームレスなコラボレーション : SaaS ソリューションは、地理的な障壁を打ち破り、リモートチーム間のシームレスなコラボレーションを促進します。これは、従業員が分散している中小企業にとって特に有益であり、プロジェクトを調整し、情報を共有し、より効果的に顧客にサービスを提供できるようになります。 セキュリティの強化 : SaaS 企業はアプリケーションのセキュリティ、バックアップ、規制コンプライアンスを管理し、中小企業の負担を大幅に軽減します。このリスク軽減により、中小企業はデータ保護やコンプライアンスの複雑さを心配することなく、中核となる事業活動に集中できます。 継続的なイノベーション : SaaS ソリューションは最新の機能で継続的に更新されています。これらの定期的な更新により、コストのかかるソフトウェアアップグレードを必要とせずに最先端の機能を活用できるため、ペースの速い市場での競争力を維持できます。 直感的なユーザーエクスペリエンス : SaaS ソリューションは顧客中心の設計を採用し、直感的なユーザーインターフェイスと合理化されたオンボーディングプロセスを提供します。これにより、これらのソリューションの導入と拡張が容易になり、従業員の生産性が向上し、優れた顧客体験を提供できるようになります。 戦略的実装 中小企業が SaaS ソリューションを効果的に評価、選択、利用開始するためのステップは次のとおりです。 ビジネスニーズの特定 : このステップでは、ビジネス要件と直面している具体的な課題を十分に理解する必要があります。SaaS ソリューションに求める特定の特徴、機能、能力を判断してください。必須要件を特定し、事業運営における重要性に基づいて優先順位を付けます。要件をランク付けすることで、ビジネスに適したツールを評価して選択する際に、最も重要な機能に焦点を当てることができます。 オプションの調査と評価 : 徹底的な市場調査を実施して、業界とビジネスのニーズに応える SaaS ソリューションを特定します。AWS Marketplace は、ビジネスインテリジェンス、CRM、セキュリティ、ネットワーキング、プロジェクト管理など、さまざまなカテゴリにわたる製品の選択肢を提供しています。これにより、要件を満たすさまざまなソリューションを簡単に見つけて評価できます。各 SaaS プロバイダーの機能、価格設定、スケーラビリティ、データセキュリティ、およびカスタマーサポートを評価してください。他の中小企業からのレビュー、ケーススタディ、お客様の声を読みましょう。要件に最も適したプロバイダーの候補リストを用意してください。 技術的およびオペレーション影響の評価 : SaaS ソリューションと既存のシステムおよびプロセスとの統合機能を評価します。現在の IT インフラストラクチャやビジネスワークフローとシームレスに統合できることを検証してください。統合と継続的な管理に必要な IT サポートとリソースのレベルを決定します。事業運営への影響、ワークフローの変更、ユーザートレーニング、必要なデータ移行を評価します。 データセキュリティとコンプライアンス : 機密性の高いビジネスデータを保護するために、SaaS プロバイダーのセキュリティプロトコル、データ暗号化、アクセス制御、および障害復旧計画を評価してください。このソリューションが、 医療保険の相互運用性と説明責任に関する法律 (HIPAA) 、 ペイメントカード業界データセキュリティ基準 (PCI DSS) 、または 一般データ保護規則 (GDPR) の要件など、お客様のコンプライアンスニーズに対応しているかを確認してください。組織とプロバイダー間のデータセキュリティとコンプライアンスに関する 責任共有モデル を理解してください。データセキュリティとコンプライアンスを維持する上での両当事者の役割と責任を明確に定義して、協調的かつ効果的なアプローチを促進してください。AWS Marketplace には、掲載されている SaaS プロバイダー向けの厳しいセキュリティ基準とコンプライアンス基準があります。これは、規制の厳しい業界で事業を行っている企業や機密データを扱う企業にとって特に重要です。 財務 上および契約上の考慮事項の評価 : 目に見えないコストや手数料を含め、価格設定モデルを理解してください。ビジネスニーズに合致し、要件の変化に応じて拡張できる最適な価格プランを決定してください。成長率に応じてボリュームディスカウントを依頼してください。サービスレベルアグリーメント (SLA) を確認し、アップタイム、データセキュリティ、およびサポートに対するプロバイダーの取り組みを理解してください。お客様固有の要件に合った、有利な契約条件を交渉してください。AWS Marketplace は、SaaS ソリューションを発見、評価、購入するための一元化されたプラットフォームを提供することで、調達プロセスを簡素化します。一部の SaaS プロバイダーは、ボリュームディスカウントを提供するプライベートプライシング契約を提供しています。AWS Marketplace では、請求とレポートを一元管理できるので、企業は複数のベンダーやアプリケーションにまたがる SaaS 支出をより適切に管理および最適化できます。 SaaS ソリューションのパイロット : 少数のユーザーグループを対象にトライアルまたはパイロット実装を実施し、SaaS ソリューションの機能、使いやすさ、ビジネスへの適合性を評価します。パイロットユーザーからフィードバックを収集し、ソリューションのパフォーマンスと運用への影響を評価します。パイロットフェーズは、SaaS ソリューションを組織全体に展開する前に、潜在的な課題や障害を発見して対処するのに役立ちます。 利用開始 の計画と実行 : 導入を成功させるために必要なステップ、タイムライン、リソース、役割分担を概説した詳細な実装計画を作成します。シームレスな移行のために SaaS ソリューションを使用するすべての従業員に変更を伝え、包括的なトレーニングを提供します。実装プロセスを管理し、進捗状況を監視し、発生する可能性のある課題に対処するプロジェクトマネージャーまたは専任チームを指名してください。ソリューションのパフォーマンスを定期的に監視し、システムを維持し、ユーザーに継続的なサポートを提供するための構造化されたプロセスを実装します。AWS Marketplace には、SaaS ソリューションのデプロイと統合のさまざまな側面を支援できるコンサルティングパートナーと実装パートナーのパートナーエコシステムがあります。 AWS Marketplace パートナーディレクトリ でこれらのパートナーを検索し、交流することができます。 継続的な評価と最適化 : SaaS ソリューションのパフォーマンス、ユーザーによる運用、進化するビジネス要件との整合性を継続的に評価します。ユーザーからのフィードバックを収集して、SaaS ソリューションの機能、使いやすさ、またはビジネスプロセスとの統合を改善する機会を特定します。SaaS プロバイダーの製品ロードマップを定期的に見直し、事業運営をさらに最適化できるような新機能の導入を検討してください。SaaS プロバイダーとの継続的な対話を続けて、製品の更新、新機能、およびビジネスに影響を与える可能性のある変更について常に情報を入手してください。 次のステップ 結論として、中小企業が大規模な競合他社がもたらす課題を克服する上で、SaaS は大きな役割を果たすことができます。SaaS ソリューションはお客様のビジネスニーズに合わせて拡張でき、柔軟なオンデマンド価格設定が可能で、一般的なビジネス機能のために独自のソフトウェアを管理する手間が省けます。中小企業は、成長を促進し、生産性を高め、最終的には長期的な成功を達成するために、これらの革新的なテクノロジーを採用する必要があります。 SaaS への取り組みを始めるには、AWS Marketplace を検索してビジネスニーズに合った SaaS ソリューションを探し、 今すぐお問い合わせ いただくか、 AWS SaaS パートナー と直接相談してください。 翻訳はソリューションアーキテクト 江成 篤 が担当しました。原文は こちら です。

このブログは、大和総研様の商用データベースからの移行についてのシリーズ記事の第三回目になります。これ以前の記事については「大和総研が CRM システムを商用データベースから Amazon Aurora PostgreSQL に移行 Part 1 と Part 2 」をご参照ください。今回は、Aurora PostgreSQLへの移行後の効果や課題についてご紹介します。 本番リリース 2020 年 4 月に要件定義が開始し 2 年半後の 2022 年 10 月に当該システムがリリースされました。現時点で安定して稼働していますが、本番リリース直後に対処が必要な課題が発生しました。 AWS 移行後の課題 ・リリース直後の負荷高騰 本番リリース時の Aurora クラスターは、Writer インスタンス 1 台と Reader インスタンス 1 台の 2 台で構成していました。これは、システムの初期リリース時の想定負荷に合わせた設計でしたが、実際にはリリース後に予想以上の負荷によりデータベースサーバーの負荷が高騰し、パフォーマンス問題が発生しました。お客様はワークアラウンドとして Aurora インスタンスのスケールアップと Reader インスタンスを2台追加することでこのパフォーマンス問題を解消しました。 ・パフォーマンス遅延 特定の機能を実行した時に処理が遅延する事象が発生しました。事象について調査したところ、該当機能を実行した時の SQL で遅延が発生していました。さらに調査した結果、テスト環境と本番環境でデータの値に差異があり、テスト環境では本番とは異なる実行計画で実行されていることがわかりました。これにより、大量の読み込みが発生し SQL が遅延している状況でした。対処として、該当 SQL に対して読み込みを抑えるようなチューニングを実施することで、問題を改善しました。 AWS 移行による効果 AWS への移行がリリースされてから約 1 年半が経過し、移行による効果として以下 3 つを確認しています。 ・リソースの最適化 Aurora PostgreSQL への移行により、リソース管理の柔軟性が大幅に向上しました。従来のシステムでは数年先を見越してリソースを確保する必要がありましたが、Aurora PostgreSQL ではニーズに応じて迅速にリソースを調整できるようになりました。これにより、ビジネスの成長や変化に合わせて最適なリソース配分が可能となり、効率的なシステム運用が実現しました。 さらに、マネージドサービスの活用により、運用管理の効率が飛躍的に向上しました。多くの機能がマネージドサービスを通じて提供されるため、リリース後の運用管理が大幅に簡素化されました。これにより、開発部門は戦略的なプロジェクトにより多くの時間とリソースを割り当てることが可能になりました。また、移行前と比較してライセンスコストなど運用費用は、大幅な削減を実現しました。 ・柔軟なスケーリング リリース直後の負荷高騰に対して、柔軟なスケーリングで対処できたことはオンプレミスのデータベースではできなかった対応の一つであり移行による効果と言えます。また、先に紹介した問題の解消後、ワークロードの分析とチューニングを実施して負荷を軽減することで、Reader インスタンスの台数も減らすことができました。最終的には、Writer インスタンスと Reader インスタンスを本番リリース当初の 1 台ずつに戻すことができています。さらに、上記パフォーマンス問題の経験から、その後のリリースの時には事前のチューニングとモニタリングを強化し、必要に応じて Reader インスタンスの台数を増やすことで、問題発生を事前に防ぐような運用を実現することができました。 ・パフォーマンス管理 オンプレミスのデータベースでは、データベースのリソース状況を確認するためには問題発生時点のレポートを作成してそれを元に調査する運用でした。このため、リアルタイムの監視が難しく、パフォーマンス問題が発生した後に原因を調査するといったリアクティブな対応が多くなっていました。AWS への移行により Amazon RDS Performance Insights を使ってリソース状況をリアルタイムで確認できるようになりました。現在では、毎朝 Performance Insights のダッシュボードで主要なメトリクスを確認して、問題がありそうな事象があれば対応するといったプロアクティブな活動を行っています。このように、監視業務の効率化、リアルタイムでの問題発見、プロアクティブな対処が可能になった点も、AWS 移行による効果と言えます。 まとめ 大和総研様では、今回の AWS への移行で、単なるコスト削減を超えて、システムの柔軟性とプロアクティブな運用による安定したシステム運用を実現することができました。この結果、システムを利用している大和証券の担当者様からは満足度が高いシステムであるという評価が得られました。 データベースエンジンの変更は一般的に二の足を踏むことも多い中、大和総研様で今回のデータベースエンジン変更を実現できた要因については、お客様の理解と協力がありました。移行担当の責任者である久保様は、 「今回のデータベースエンジン変更について、お客様とは移行するメリットだけではなく移行した時のリスクやそのリスクに対する回避案についてディスカッションしました。結果としてリスクテイクが必要なケースもありましたが、お客様自体がクラウド移行に向けて前向きに検討したことで、AWS 移行を進めることができたと考えています。」 と述べられています。 今後、さらに柔軟で付加価値の高いサービスを迅速に提供するために、AWS のサービスを活用していく予定です。 終わりに 三回にわたって、大和総研様の商用データベース移行についてご紹介しました。今回、事例化に当たりまして、大和総研の小野寺様、岩波様、久保様、プラ様、守屋様には、多大なご協力をいただき心より感謝申し上げます。 今回のデータベース移行の実績を契機に、大和総研様では他社へのデータベース移行支援も積極的に展開される予定です。データベース移行を検討中の方は、以下の問い合わせフォームからご相談ください。 https://it-solution.dir.co.jp/inquiry_seminar （写真左から） 株式会社大和総研 クラウドソリューション部　部長 守屋 史明様 株式会社大和総研 リテールフロントシステム部 データサイエンティスト プラスティ バンダラ バラッマネ様 株式会社大和総研 リテールフロントシステム部　部長 久保 諭史様 株式会社大和総研 システムインフラ設計部　小野寺 正樹様 株式会社大和総研 システムインフラ設計部　岩波 祥平様 また、ブログ掲載にあたり、 株式会社大和総研 クラウドソリューション部　石川 真由美様 ご多用の中、ご調整ならびにご対応・協力いただきありがとうございました。改めて感謝申し上げます。

この連載の最初の記事「 大和総研が CRM システムを商用データベースから Amazon Aurora PostgreSQL に移行 Part 1 」では、大和証券様の CRM システムを商用データベースから Aurora PostgreSQL に移行した際の移行検討段階について、アセスメントや検証の内容などをご紹介しました。 このアセスメント結果を踏まえ、商用データベースから Aurora PostgreSQL への移行プロジェクトが開始されました。 移行プロジェクト開始 移行プロジェクトは、2020 年 4 月に開始され、2022 年 10 月にリリースされました。 移行作業では AWS Schema Conversion Tool（以下SCT）を使用してDDL 文を Aurora PostgreSQL に変換しました。アプリケーションについては、MyBatis 形式のソースコードが SCT に対応していなかったため（現在は対応済）、手作業での SQL の書き換え作業を実施しました。移行を担当した大和総研様では、商用データベースについての経験は豊富でしたが、PostgreSQL についての経験が少なく、データベースエンジンの移行に対するノウハウも不足していましたが、PostgreSQL が商用データベースに近いアーキテクチャーであった為、商用データベースの知識やノウハウをベースに移行開発を進めることができました。また、AWS のプロフェッショナルサービスによるバックエンドの移行支援もありました。プロジェクトとしては順調に進んでいましたが、データベースの移行に伴ういくつかの課題も発生しました。 課題１：パフォーマンス PostgreSQL に書き換えた SQL の一部で、パフォーマンスが低下する事象が発生しました。遅延した原因を調査した結果、2 つの事象が発生していました。 1. 実行計画の差異 事象：当該システムで作成された SQL はサブクエリを多用しており、ネストが深いサブクエリもあるなど複雑な構造の SQL がありました。このような SQL に対して、商用データベースでは実行計画をコントロールするためにサブクエリ内でのヒント句を使用するなど、パフォーマンスチューニングが施されていました。 一方、PostgreSQL に変換した SQL の中には、PostgreSQL 用に最適化が必要な SQL もありました。特にサブクエリに指定されていたヒント句は PostgreSQL ではクエリ全体に適用されてしまう仕様であったため、対処が必要な状況でした。 対処：基本的には、pg_hint_planという拡張オプションを採用して実行計画をコントロールすることで対処しました。サブクエリに指定されていたヒント句については、テーブル構成の変更やSQL自体を一部書き換えるなど、PostgreSQL に最適なパフォーマンスが得られるよう試行錯誤を繰り返しながら、SQL のチューニングを実施しました。 2. 不要な読み込みの改善 事象：SQL の変換やチューニングを実施する中で、商用データベースで実行されていたSQLに改善の余地があることがわかりました。具体的には、商用データベースではデータ取得用の SELECT 文とデータ件数を取得する SQL を2 回実行していて、1 回あたりの処理時間やデータベースの負荷が高い状況でした。 対処：PostgreSQL の SELECT に変換する際に、OVER 句を使用したウィンドウ関数を使用することでデータ取得と件数を1 回で実行できるよう変更しました。 このようなチューニングを実施した結果、パフォーマンスについては商用データベースの時と同程度の状態に改善されました。 課題２：エラー時の結果差異 アプリケーションの異常系テスト中に、エラー発生時の結果に差異が生じました。商用データベースの場合、トランザクションを rollback する際、トランザクションの一部のみが rollback されますが、PostgreSQL の場合、すべてが rollback されるという仕様の違いがあります。例えば、以下のようにトランザクション内で INSERT 処理が一意制約違反でエラーになった場合、商用データベースではエラーのみが例外処理されますが、PostgreSQL の場合はトランザクション内で実行されたすべての INSERT 文が rollback されます。 この仕様差異により、異常時の結果が商用データベースと PostgreSQL で異なる状態になっていました。この問題に対しては、エラー後のリトライ処理でトランザクション内の全ての更新処理が rollback されることを前提にアプリケーションを修正することで対処しました。 このように、発生した課題を一つずつ解決していくことで、移行プロジェクトは無事カットオーバーを迎えることができました。 Part 3 に続く。

大和総研は、長年培ってきたIT分野における多くの実績とノウハウを基盤として、証券会社、銀行等の金融機関に加え、事業会社、官庁および地方自治体、健康保険組合といった公共団体等の幅広いお客様に向けて、戦略的かつ効率的な業務改革に資するコンサルティング、ならびに安全性の高い情報システムサービスを展開している AWS のパートナーです。大和総研では、大和証券の顧客情報管理システム（以下「CRM システム」）を 2022 年に全面更改しました。この更改のタイミングで、データベースエンジンを商用データベースから Aurora PostgreSQL に移行しています。本ブログでは、商用データベースから Amazon Aurora PostgreSQL に移行した時の検討から移行作業の詳細、移行したことで得られた効果や、そのときに直面した課題とその解決方法について、お客様の現場の声を交えてご紹介します。 CRM システム概要 今回移行を実現した CRM システムは、2 ノードで構築された商用データベースが 2 セットあり、1 ノードあたり 7CPU で 2 ノード合計 14CPU のサーバー上に構築されていました。500 を超えるデータベースのオブジェクトがあり、そのうち約半分がテーブルで、プロシージャなどの PL/SQL の使用はなく、アプリケーション側に数千以上の SQL がありました。 移行前システムにおける課題 この CRM システムは初期構築から 10 年以上が経過して、サーバー側ソフトウェアのサポートの問題が発生しており、これに伴うシステムの全面更改が必要な状況でした。また、10 年という期間の中でシステムに求められる要件もかわり、BCP 環境の構築など新しい要件への対応も必要でした。そして、最も重要な課題が商用データベースに関するもので、ライセンス費や保守費はシステム運用における大きな課題となっていました。 移行先の検討 このような現行システムの課題を踏まえ、システムの移行検討がスタートしました。システムの移行先は、AWS が第一候補として検討されました。大和総研では、増大するクラウド案件の増加に対応するため、2021 年に CCoE（Cloud Center of Excellence）を設置し、2023 年 7 月には AWS の認定資格取得数が 1,000 を超えて「AWS 1000 APN Certification Distinction」にも認定されるなど人材の育成も進めていました。また、会社の方針としてシステム更改時の移行先はパブリッククラウドファーストが原則とされており、このような背景から今回の CRM システム更改でも AWS が第一候補となりました。ここで課題になったのは、商用データベースの移行です。AWS へそのまま移行した場合、移行に伴うライセンス費や保守費が増加しコストがかさむことも判明しました。また、スケーリングの柔軟性も重要な要素でした。AWS の RDS や Aurora は、ユーザー数や機能の増減に合わせた柔軟なスケーリングが可能で、クラウド移行によるメリットの一つであり、システムの要求を満たすのに十分なレベルでした。一方、商用データベースのまま AWS に移行した場合、スケールアップやスケールアウトするためには追加ライセンスが必要で、タイムリーな対応が難しく、コスト面でも問題が生じます。このような背景から今回の CRM 更改プロジェクトにおいては、商用データベースからの移行を本格的に検討することになりました。 移行先決定に向けたアセスメント データベースエンジンの変更については、AWS が提供している Database Freedom Workshop を利用しました。Database Freedom Workshop はデータベースエンジンの移行を検討しているお客様に AWS の Database Specialist が無償で提供するワークショップで、データベースエンジンの移行に対するアセスメントや商用データベースのパフォーマンス分析によるサイジングなどを実施するワークショップです。大和総研では、データベースエンジンの移行に対するアセスメントとパフォーマンス分析を行いました。 データベースエンジンの移行に対するアセスメントは、AWS が提供する無償ツールであります AWS Schema Conversion Tool（SCT）を使いました。その結果、対象のシステムでは Aurora PostgreSQL への移行難易度が低く、オブジェクトの 98% が最小限の変更で移行が容易であることがわかりました。 このアセスメント結果を踏まえ、机上検証と実機検証を実施しました。 机上検証 机上検証では、可用性、拡張性、性能、運用保守性、セキュリティの技術的な項目とコストについて調査を実施しました。移行対象としては、オンプレミスの商用データベースに対して商用の PostgreSQL と Aurora PostgreSQL を比較検証しました。 机上検証の結果、コストや可用性の観点から Aurora PostgreSQL が最適であるという結論に至りました。 実機検証 実機検証では、SCT で変換された PostgreSQL のオブジェクトを使用して動作検証を実施しました。動作検証では SCT で移行したオブジェクトを使用してアプリケーションで実行されるような SQL を Aurora PostgreSQL で実行し、その挙動や性能などを確認しました。検証の結果、移行前と移行後で基本的な動作や性能で大きな差異がないことを確認することができました。ただし、一点、パーティションについて課題があることがわかりました。移行前のデータベースではパーティションを跨ったインデックスを使用していましたが、Aurora PostgreSQL には同等の機能がなく、複数のパーティションを検索する場合パフォーマンスが数十秒程度劣化することがわかりました。 もう一つの観点として、アプリケーションの移行性についても検証しました。本システムでは、フレームワークとして MyBatis を採用しており、SQL が XML ファイルに定義されています。このSQLは条件によって動的に組み替えて実行する仕組みであった為、SCTを使っての変換が難しく、変換方法の検討が必要な状況でした（現在は対応済み）。 実機検証での課題に対する解決案 課題となっていたパーティションの遅延について、改善案を検討しました。その結果、今回のシステムではパーティションと通常テーブルの 2 つを用意して、参照処理を実行する際に効率の良いテーブルを参照するように変更することにしました。該当テーブルへの更新は、すべての更新処理で両方のテーブルに更新するよう変更することで、移行前と同等のパフォーマンスで動作することを確認することができました。 アプリケーションの移行性については、XML ファイルにある SQL を実行できる形で整形して、SCT で変換することで、SQL 自体の変換工数を効率化することが可能であることが確認されました。 これらの机上検証と実機検証により商用データベースを移行することによるリスクは低く、コストメリットがあると判断され、Aurora PostgreSQL へのデータベース移行が決定されました。 Part 2 に続く。

当社はお客様、規制当局、利害関係者の声に継続的に傾聴し、 Amazon Web Services (AWS)  における監査、保証、認定、認証プログラムに関するそれぞれのニーズを理解に努めています。この度、AWS System and Organization Controls (SOC) 1 レポートが、日本語、韓国語、スペイン語で利用可能になりました。この翻訳版のレポートは、日本、韓国、ラテンアメリカ、スペインのお客様および規制要件との連携と協力体制を強化するためのものです。 本レポートの日本語、韓国語、スペイン語版には監査人による独立した第三者の意見は含まれていませんが、英語版には含まれています。利害関係者は、日本語、韓国語、スペイン語版の補足として英語版を参照する必要があります。 今後、四半期ごとの以下のレポートで翻訳版が提供されます。SOC 1 統制は、Spring および Fall SOC 2 レポートに含まれるため、英語版と合わせ、1 年間のレポートの翻訳版すべてがこのスケジュールで網羅されることになります。 レポート 対象期間 春季SOC 2 4 月 1 日〜3 月 31 日 夏季SOC 1 7 月 1 日〜6 月 30 日 秋季SOC 2 10 月 1 日〜9 月 30 日 冬季SOC 1 1 月 1 日〜12 月 31 日 Summer 2024 SOC 1 レポートの日本語、韓国語、スペイン語版は AWS Artifact (AWS のコンプライアンスレポートをオンデマンドで入手するためのセルフサービスポータル) を使用してダウンロードできます。 AWS マネジメントコンソール内の AWS Artifact  にサインインするか、 AWS Artifact の開始方法ページ で詳細をご覧ください。 Summer 2024 SOC 1 レポートの対象範囲には合計 177 のサービスが含まれます。その他のサービスが追加される時期など、最新の情報については、 コンプライアンスプログラムによる対象範囲内の AWS のサービス で [SOC] を選択してご覧いただけます。 AWS では、アーキテクチャおよび規制に関するお客様のニーズを支援するため、コンプライアンスプログラムの対象範囲に継続的にサービスを追加するよう努めています。SOC コンプライアンスに関するご質問やご意見については、担当の AWS アカウントチームまでお問い合わせください。 コンプライアンスおよびセキュリティプログラムに関する詳細については、 AWS コンプライアンスプログラム をご覧ください。当社ではお客様のご意見・ご質問を重視しています。お問い合わせページより AWS コンプライアンスチーム にお問い合わせください。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 10 月 31 日 (木) 14:00 – 18:00 に AWS AI Day が開催されます。ザ・プリンス パークタワー東京の物理開催に加えて、ライブ配信も行います。現地の展示ブースでは、私を含む AWS Japan のスタッフが展示員として立つ予定です。ぜひ皆様ご参加いただき、イベントを楽しみながら、新しい学びを持ち帰っていただけますと幸いです。事前登録制になっておりますので、ぜひご登録の上ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024 年 10 月 21 日週の主要なアップデート 10/21(月) AWS Console Mobile Application でシームレスリンク体験の提供 AWS Console Mobile Applicaton は、iOS や Android などのモバイルデバイスにインストールできるアプリケーションで、プッシュ通知によるお知らせを確認、専用ダッシュボードでリソースのモニタリング、サポートされている AWS サービスの詳細確認などができます。今回のアップデートで、AWS リソースに関する URL をモバイルデバイスで開く際に、AWS Console Mobile Applicaton の画面が直接開くシームレスリンク体験を提供するようになりました。ラップトップを開けない時などで利用体験が向上するアップデートです。 RDS Custom for SQL Server で Windows 認証をサポート RDS Custom for SQL Server で WIndows 認証をサポートするようになり、既存の Active Directory を利用してアクセスを管理できるようになりました。AWS Managed Microsoft AD や、お客様がセルフで管理している Active Directory のいずれかで連携可能です。RDS Custom for SQL Server を提供しているすべてのリージョンで利用可能です。 10/22(火) Amazon Bedrock で Claude 3.5 Sonnet v2 モデルの提供開始と、Computer Use 機能のパブリックベータ提供 Amazon Bedrock で、アップグレードされた Claude 3.5 Sonnet v2 モデルを提供開始しました。前のバージョンから全面的に改善されており、特にコーディング分野で大きく進化しています。Anthropic によると、公開されているすべてのモデルの中で最高のスコアを記録されています。料金については、従来の Claude 3.5 Sonnet と同じ価格で利用ができます。また、Computer Use 機能のパブリックベータを提供開始しました。Claude がコンピューターの画面を認識し操作できるようになり、人間の指示を基にして、画面を識別、マウスの操作、ボタンのクリック、テキストの入力などを行ってくれる機能となります。この機能はまだ初期段階であるため、リスクの低いタスクから検証を行うことをお勧めします。Claude 3.5 Sonnet v2 は、オレゴンリージョンで利用可能です。詳細は こちらのブログ を参照ください。 AWS Lambda で Code-OSS (VS Code – Open Source) ベースのコードエディター機能の提供開始 AWS Lambda のマネジメントコンソール画面に、コードを直接編集する機能があります。今回のアップデートで、Code-OSS (VS Code – Open Source) ベースのインターフェースにアップデートされました。VS Code に慣れている方は、デスクトップ版の VS Code と同様なインターフェースで利用いただけます。また、Amazon Q Developer の拡張機能を有効化することができ、コード生成やインサイト提供など開発者の生産性向上のメリットがあります。詳細は こちらのブログ を参照ください。 Amazon Redshift でクエリー監視と診断を行う Query Profiler の提供開始 Aamzon Redshift でクエリーの可視性向上や問題発生時の分析作業を強化する Query Profiler 機能を提供開始しました。AWS マネジメントコンソールで、Redshift に投げられた SQL クエリーに対して、実行計画や、統計情報を視覚的に確認ができるようになり、クエリーパフォーマンスを改善するための分析作業やトラブルシュートなどに利用できる機能です。Redshift Serverless 、Redshift provisioned Cluster の両方で利用可能です。 Amazon Aurora の Global Database writer endpoint の提供開始 Amazon Aurora で、Global Database writer ednpoint の提供を開始しました。Amazon Aurora の Global Database は、Aurora クラスターを複数の AWS リージョンにまたがって構成でき、リージョン単位の障害に対する耐障害性向上や、各リージョンでの高速な読み取りを利用できる仕組みです。このアップデートで、異なるリージョン間のフェールオーバーやスイッチオーバーを行ったときに、writer endpoint の名前をそのまま保持するようになりました。writer endpoint の裏側で切換を行うため、アプリケーション側の接続先を変更する負担を軽減できます。なお、DNS キャッシュなどの考慮点があり、詳細は こちらのドキュメント をご覧ください。 10/23(水) Bottlerocket で NVIDIA GPU Time-slicing をサポートし AI/ML の利用効率を向上 コンテナのホスティング用途で設計されている Linux ベースの OS である Bottlerocket で、NVIDIA GPU Time-slicing をサポートしました。Bottlerocket はセキュリティ、最小限のフットプリント、安全なアップデートを重視されて設計されています。NVIDIA GPU Time-slicing は、コンテナ上で実行する複数の AI/ML 処理のために、GPU リソースを共有する仕組みを提供するものです。例えば、マルチテナントの環境があり、複数の機械学習のタスクで GPU が必要になった際に、GPU の処理時間をより小さな間隔 (スライス) に分割することで、1 つの GPU に同時にアクセスできるようになります。詳細は Bottlerocket の Document をご覧ください。 AWS Billing Conductor でリザーブドインスタンスと Savings Plans のカバレッジや使用率レポートをサポート AWS Billing Conductor (ABC) は、組織内の複数の部門にまたがって、事前に指定したルールに基づき費用の按分を行う用途などに利用できる、カスタム請求サービスです。たとえば、AWS を管理している組織 (CCoE, Cloud Center of Excellence など) が、複数の利用部門に AWS 環境を提供する場合、一定の管理費を追加して請求する、といったカスタム請求管理ができます。今回のアップデートで、リザーブドインスタンスと Savings Plans の利用率レポートにより、プロフォーマデータ (請求額) を調整しやすくなりました。各部門の Saving Plans などの利用割合に基いて、請求額をコントロールすることがやりやすくなるアップデートです。 Amazon Timestream for LiveAnalytics で Query Insights を提供開始 大量の時系列データを取り込み、分析する用途に利用できる Amazon Timestream for LiveAnalytics で Query Insights の提供を開始しました。クエリを実行した際にレスポンス内に、詳細を確認するためのデータが含まれており、パフォーマンス最適化のための改善点を深ぼる際に便利に活用できます。データ取得効率、非効率なテーブル、その他メトリクスなどの詳細情報を提供します。 10/24(木) AWS Lambda で Java ランタイムを利用した際のカスタムシリアライザーの利用をサポート AWS Lambda で Java の関数を起動する際に、invoke リクエストに含まれる入力データを Java の Object として扱うために、デシリアライズがされます。また、関数の実行結果を返却する際に、Lambda サービスにデータを送信するためのシリアライズ処理がされます。今回のアップデートで、シリアライザーを独自にカスタムすることが出来るようになりました。たとえば、「vehicleType」というデータがリクエストに含まれる想定だったが、実際には「vehicle-type」というデータが来た場合、デフォルトのシリアライザーではエラーになります。これに対して、カスタムシリアライザーを独自に実装することで、エラーにせずに正常に扱うための制御が可能になります。詳細は こちらの Document をご覧ください。 Elastic Fabric Adapter (EFA) を Elastic Network Adapter (ENA) から切り離す新しいインターフェースタイプの提供開始 ENA は高性能ネットワーキングを提供するハードウェアインターフェースで、EC2 インスタンスの基盤となるハードウェアレベルで動作するコンポーネントです。EFA は HPC や 機械学習のワークロードに最適化されているネットワークインターフェースです。これまで、EFA インターフェースは、ENA デバイスと合わせて提供され IP アドレスを消費する動作となり、VPC 内で利用できる IP アドレスの不足などで、スケーリングの制限が生じる可能性がありました。今回のアップデートで、ENA から切り離された「EFA のみ」のインターフェースが提供されました。「EFA のみ」では、IP アドレスは利用せず、Mac アドレスを基にした SRD プロトコルを利用するため、IP アドレスに起因する制限を緩和できるメリットがあります。 10/25(金) AWS でクレジットカードやデビットカードで支払う際に、一部支払いに対応 クレジットカードやデビットカードで AWS 利用料金をお支払いしている場合は、毎月の請求に対して、「一部支払い」が可能になりました。「一部支払い」は、AWS の請求額を複数に分割して、異なるカードで決済を可能にするものです。これまで AWS カスタマーサービスの問い合わせ窓口経由で利用ができましたが、AWS マネジメントコンソール上で、「一部支払い」が設定できるようになりました。例えば、部門やプロジェクトごとに異なるカードを利用したいときに、柔軟な支払いがしやすくなります。 CloudWatch Logs で異常検知やパターン分析における機能改善とService Quota の緩和 CloudWatch Logs Insights は、機械学習を利用してログをいくつかの共通的なパターンに集約し、数千行のログを数行に要約することで分析をやりやすくできます。今回のアップデートで、Logs Insights で pattern や diff コマンドを含めたクエリーを実行する際に、フィールドを解析し名前を付けることで、ログデータの分析をより簡単にできるようになりました。例えば、ARN 値を含むフィールドは「ARN-1」、IP アドレスを含むフィールドは「IPV4-1」といった名前に名付けられます。この名前付きパターンを使用することで、リクエスト ID、HTTP レスポンスコードなど、ログに出現する共通フィールドを容易に特定し検査することができます。 11 月 7 日 (木) に、AWS オンラインセミナーの データガバナンス事例祭り を開催します。組織横断でデータ利活用を促進するデータガバナンスに関して、AWS サービスと最新のアプローチを活用しているお客様より、その具体的な取り組みの背景とソリューションについてお話いただきます。ぜひ事前登録の上ご参加ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

2024/9/25 より、 AWS Transit Gateway にてセキュリティグループ参照のサポートを開始しました。この新機能により、同一 Amazon Web Services (AWS) リージョン 内の Transit Gateway に接続した他の Amazon Virtual Private Cloud (Amazon VPC) で定義された、セキュリティグループを参照するインバウンドセキュリティルールを作成できるようになりました。Transit Gateway を介したアウトバウンドセキュリティルールの参照は、現時点ではサポートされていません。 Transit Gateway は、サードパーティの仮想アプライアンスをプロビジョニングすることなく、複数の Amazon VPC とオンプレミスネットワークを接続するハブアンドスポークネットワークの構築を支援するネットワークトランジットハブです。これにより、アーキテクチャの合理化や制御、セキュリティの向上が可能です。Transit Gateway は、高可用性で拡張性が高く、シームレスに設定でき、リージョン内の Transit Gateway ごとに数千の VPC アタッチメントをサポートできるフルマネージド型サービスです。詳細については、 クォータに関するドキュメント を参照してください。 Transit Gateway の新しいセキュリティグループ参照機能により、セキュリティグループの管理が効率化されます。これを実現するために、IPv6 や IPv4 アドレス、CIDR の代わりにセキュリティグループ参照を使用してルールを作成します。これにより、特にセキュリティグループ参照に大きく依存している場合、VPC ピアリングから Transit Gateway への移行が容易になります。また、この機能は何千もの VPC にわたる大規模なネットワーキングをサポートし、効率化されたセキュリティグループ管理を通じてセキュリティ体制の向上を提供します。 本稿では、Transit Gateway 間でのセキュリティグループ参照の有効化 / 無効化する方法や一般的なシナリオでの使用方法を示します。 開始方法: Transit Gateway を通じてセキュリティグループ参照を使用する方法 AWS マネジメントコンソール や AWS SDK 、 AWS API を使用して、新しい Transit Gateway または Transit Gateway VPC アタッチメントを作成する際、あるいは既存のものを編集する際に、 セキュリティグループ参照サポートオプション を有効または無効にすることができます。 Transit Gateway レベルでのセキュリティグループ参照サポート設定と、Transit Gateway VPC アタッチメントレベルでの設定の違いを理解することが重要です。これにより、ネットワークアーキテクチャのセキュリティ要件に合わせたアクセス制御セットを選択することができます。 この機能を使用するには、Transit Gateway と Transit Gateway VPC アタッチメントの両方でセキュリティグループ参照サポートを有効にする必要があります。 この図では、Transit Gateway を介して接続された 3 つの VPC を示しています。 図1. Transit Gateway を介して接続された 3 つの VPC 図1 に示されたアーキテクチャを考えてみましょう。 Transit Gateway とその 3 つのアタッチメント (VPC 1、VPC 2、VPC 3) でセキュリティグループ参照が有効になっている場合、Transit Gateway を介して 3 つの VPC でセキュリティグループ参照が可能になります。 Transit Gateway と VPC 1 および VPC 2 のアタッチメントでセキュリティグループ参照が有効になっている場合 (VPC 3では無効)、Transit Gateway を介して VPC 1 と VPC 2 間でセキュリティグループ参照が可能ですが、VPC 3 とは不可能です。 Transit Gateway でセキュリティグループ参照が無効になっている場合、個々の Transit Gateway VPC アタッチメントでオプションが有効になっているかどうかに関係なく、Transit Gateway を介したセキュリティグループ参照はできません。 1. Transit Gateway レベルのセキュリティグループ参照サポート Transit Gateway レベルの セキュリティグループ参照サポート は、デフォルトで全ての Transit Gateway で無効になっています。 この機能の導入以前に作成された Transit Gateway も含まれます。 この機能を Transit Gateway レベルで有効化するには、コンソール上の セキュリティグループ参照サポート オプションをチェックします (図 2)。本稿執筆時点では、Transit Gateway を介して VPC を AWS Local Zones または AWS Outposts に拡張する場合、この機能はサポートされていません。 セキュリティグループ参照に関する詳細は、 セキュリティグループ参照ドキュメント を参照してください。 この図では、コンソール上での Transit Gateway レベルのセキュリティグループ参照サポートオプションを示しています。 図2. コンソール内の Transit Gateway レベルでのセキュリティグループ参照サポートオプション この機能を無効化するには、 セキュリティグループ参照サポート オプションのチェックを外してください。 無効化すると、Transit Gateway 全体でセキュリティグループ参照機能が動作しなくなります。 その結果、参照されたセキュリティグループのみに依存するインスタンス間のトラフィックは、Transit Gateway のセキュリティグループ参照に依存しないIPv4 または IPv6 アドレス / CIDR を使用する別のルールに一致しない限り、ドロップされます。 この機能は、API または CLI で SecurityGroupReferencingSupport オプションを使用して有効または無効にすることもできます。次に例をいくつか示します。 新しい Transit Gateway ( MyTransitGateway ) で有効化： aws ec2 create-transit-gateway --description MyTransitGateway --options SecurityGroupReferencingSupport=enable 既存の Transit Gateway (Transit Gateway ID tgw-1234abcd ) で有効化： aws ec2 modify-transit-gateway --transit-gateway-id tgw-1234abcd --options SecurityGroupReferencingSupport=enable 既存の Transit Gateway (Transit Gateway ID tgw-1234abcd ) で無効化： aws ec2 modify-transit-gateway --transit-gateway-id tgw-1234abcd --options SecurityGroupReferencingSupport=disable Transit Gateway レベルの設定を変更しても、個々の Transit Gateway アタッチメントの設定には影響しません。各アタッチメントは、この機能に対して個別の設定を保持しています。 2. Transit Gateway VPC アタッチメントレベルのセキュリティグループ参照サポート Transit Gateway VPC アタッチメントレベルの セキュリティグループ参照サポート は、この機能の導入以前に作成されたものも含み、デフォルトで全ての Transit Gateway VPC アタッチメントで有効になっています。 コンソールでこのオプションをコントロールするには、 セキュリティグループ参照サポート オプションを見つけてください (図3)。この機能を有効化するにはチェックを入れ、無効化する場合はチェックを外します。 この図では、コンソール上での Transit Gateway VPC アタッチメントレベルのセキュリティグループ参照サポートオプションを示しています。 図3. コンソール内の Transit Gateway VPC アタッチメントレベルでのセキュリティグループ参照サポートオプション VPC アタッチメントレベルでのセキュリティグループ参照サポート設定の変更は、Transit Gateway レベルの設定とは独立して動作します。ただし、この機能が正しく動作するためには、Transit Gateway と個々の VPC アタッチメントの両方で有効にする必要があります。 この二重構成アプローチにより、管理者は Transit Gateway レベルでセキュリティグループ参照機能を有効にしながら、特定の VPC アタッチメントに対してこの機能を無効化またはオプトアウトすることができるようなきめ細かな制御が可能になります。 このオプションは、API や CLI を用いても有効化あるいは無効化できます。以下の例では、セキュリティグループの参照が有効化された新しい Transit Gateway VPC アタッチメントを作成します： aws ec2  create-transit-gateway-vpc-attachment  --transit-gateway-id tgw-0262a0e521EXAMPLE  --vpc-id vpc-07e8ffd50f49335df  --subnet-id subnet-0752213d59EXAMPLE  --options SecurityGroupReferencingSupport=enable API/CLI コールで SecurityGroupReferencingSupport を定義しなかった場合、デフォルト設定は有効になっています。 以下の例では、Transit Gateway レベルの設定が異なる場合でも、Transit Gateway VPC アタッチメント ID tgw-attach-09fbd47ddf に対してこの機能を無効にしています： aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id tgw-attach-09fbd47ddf --options SecurityGroupReferencingSupport=disable VPC アタッチメントレベルでセキュリティグループ参照を無効化すると、新しいインバウンドセキュリティグループの参照を設定できなくなります。以前まで参照されたルールで許可されていたインスタンス間のトラフィックは、この機能のみに依存していた場合、ドロップされます。 セキュリティグループ参照が有効化された VPC アタッチメントを削除する際、セキュリティグループの参照が無効になります。この操作を行う前に、 describe-security-group-references と describe-stale-security-groups の API または CLI コールをお勧めします。 最後に、別のセキュリティグループで参照されているセキュリティグループを削除すると、セキュリティグループ参照を使用しているルールが無効になります。 セキュリティグループ参照のユースケース 以下の一般的な例は、あるリージョン内の Transit Gateway に接続された複数の VPC にまたがるリソースへの厳密なアクセス制御を行う際に、セキュリティグループ参照がどのように役立つかを示しています。 1. Transit Gateway で接続された異なる VPC 間に展開された異なるアプリケーション層間のリソース共有 以下のアーキテクチャ (図4) は、3 つのVPC (VPC 1、VPC 2、VPC 3) にまたがるウェブ、アプリケーション、データベースの各層で構成されており、Transit Gateway によって VPC 同士の相互接続が可能となっています。目的は、VPC 1 のウェブ層インスタンスが VPC 2 のアプリケーション層インスタンスにアクセスできるようにすることです。また、VPC 2 のアプリケーション層インスタンスは、VPC 3 のデータベース層インスタンスへのアクセスが必要です。 セキュリティグループは VPC の IP アドレスファミリー (IPv4 または IPv6) とは独立しているため、デュアルスタック (IPv4 または IPv6) VPC や IPv6 専用サブネットにまたがるインスタンス間のトラフィックを許可できます。したがって、ウェブ、アプリケーション、データベースインスタンスは、IPv4 アドレス、IPv6 アドレス、またはその両方の組み合わせを使用することができます。 この図では、ウェブ層、アプリケーション層、データベース層の Transit Gateway を介した通信を示しています。 図4. Transit Gateway を介してウェブ層、アプリケーション層、データベース層が通信している ウェブ層インスタンスがアプリケーション層インスタンスにポート 443 (HTTPS) でアクセスすることを許可するために、VPC 2 のアプリケーション層のセキュリティグループのインバウンドルールで、VPC 1 で定義されたウェブ層のセキュリティグループを参照できます： aws ec2 authorize-security-group-ingress —group-name SG-App-Tier —protocol tcp —port 443 —source-group SG-Web-Tier —groupowner vpc1-web-tier-owner 同様に、アプリケーション層インスタンスがデータベース層インスタンスにポート 3306 でアクセスすることを許可するために、VPC 3 のデータベース層のセキュリティグループのインバウンドルールで、VPC 2 で定義されたアプリケーション層のセキュリティグループを参照できます： aws ec2 authorize-security-group-ingress —group-name SG-DB-Tier —protocol tcp —port 3306 —source-group SG-App-Tier —groupowner vpc2-app-tier-owner 2. 集中型共有サービス VPC への安全なアクセスを強化および効率化する ファイアウォールを使用せず、セキュリティグループ管理の複雑さを心配することなく、共有サービス VPC に対するセキュリティアクセスを特定のアプリケーションのみに強化したい場合があります。 以下のアーキテクチャ (図5) では、VPC 1 内の複数のアプリケーション層インスタンスが、共有サービス VPC の AWS Directory Service にアクセスする必要があります。2 つの VPC は、Transit Gateway を介して接続しています。 VPC 1 のアプリケーション層インスタンスがディレクトリにアクセスできるようにするため、共有サービス VPC のディレクトリサービス層のセキュリティグループのインバウンドルールに、VPC 1 のアプリケーション層のセキュリティグループを追加できます。これにより、VPC 1 のインスタンスはセキュリティグループ参照を通して Directory Service と通信できるようになります。 この図では、アプリケーション層インスタンスが Transit Gateway を介して Directory Service に接続している様子を示しています。 図5. Transit Gateway を介して Directory Service に接続されたアプリケーション層インスタンス 検査用VPC がある場合、AWS Gateway Load Balancer やAWS Network Firewall を介した Transit Gateway によるセキュリティグループ参照は機能しません。 3. 共有 VPC モデルにおけるリソース共有 共有 VPC モデル (前述のユースケースで説明した共有サービス VPC とは異なる) では、アプリケーションは Transit Gatewayを通じて、複数の共有 VPC にまたがることができます。セキュリティを強化しつつ、セキュリティアクセス制御を効率化するために、Transit Gateway を介したセキュリティグループの参照を使用することができます。 以下の例 (図 6) では、共有 VPC 1 内の AWS アカウント 1 のプライベートサブネットにあるアプリケーションインスタンスが、共有 VPC 2 内の AWS アカウント 5 のプライベートサブネットにある別のアプリケーションにアクセスする必要があります。Transit Gateway を通じて異なる AWS アカウントの VPC 間でセキュリティグループを相互参照することが可能になりました。そのため、AWS アカウント 1 の共有 VPC 1 で定義されたアプリケーション層インスタンスのセキュリティグループを、AWS アカウント 5 の共有 VPC 2 にあるアプリケーション層のセキュリティグループのインバウンドルールで参照できます。 この図では、共有 VPC モデルを通じて、1 つの共有 VPC 内のアプリケーション層インスタンスが、トランジットゲートウェイを介して別の共有 VPC 内の別のアプリケーション層に接続されている様子を示しています。 図6. Transit Gateway を介して接続されたアプリケーション層インスタンス 考慮事項 本稿執筆時点では、セキュリティグループ参照は Outposts および一部のタイプの Local Zones ではサポートされていません。サービスの中断を避けるため、一部のタイプの Local Zones と Outposts で拡張された VPC では、セキュリティグループ参照のフラグを無効にしておく必要があります。詳細については、 ドキュメント を参照してください。 本稿執筆時点では、異なる AWS リージョンのセキュリティグループを参照することはできません。2 つの VPC を接続するには、両方の VPC が同じ Transit Gateway に接続され、同じリージョンに存在する必要があります。 セキュリティグループ参照は、サードパーティのミドルボックスや Bump-in-the-Wire (BITM) アプライアンスを介しては機能しません。サードパーティのミドルボックスや BITM アプライアンスを介したインスタンス間のトラフィックは、セキュリティグループの参照を使用して許可することはできません。 本稿執筆時点では、Transit Gateway 上のマルチキャストではセキュリティグループの参照はサポートされていません。 本稿執筆時点では、アウトバウンドセキュリティグループに対するセキュリティグループの参照はサポートされていません。 詳細な考慮事項については、ドキュメント内の Reference security groups across a transit gateway の項目で言及されています。 Transit Gateway の動作は次の表にまとめられています。 Transit gateway レベルの制御 VPC attachment レベルの制御 セキュリティグループの参照結果 新規または既存の Transit Gateway の動作 有効 有効 有効 無効 (デフォルト) 有効 (デフォルト) 無効 (デフォルト) 有効 無効 無効 無効 無効 無効 まとめ Transit Gateway を介したセキュリティグループの参照の導入により、Transit Gateway 間のリソースへのセキュリティアクセス制御を直接的かつ便利に強化できるようになりました。この新機能は、VPC ピアリングから Transit Gateway への直接的な移行経路を提供します。特に、多くのセキュリティグループの参照を本番環境に展開している場合に有効です。 本稿では、Transit Gateway を介したセキュリティグループの参照の有効化と無効化、およびこの機能の利点について説明しました。 この機能は、AWS 商用リージョン、 AWS GovCloud (US) リージョン、およびAWS China リージョンで利用可能です。 Transit Gateway について詳しく知りたい際は、 Transit Gateway のドキュメント を参照してください。本稿に関する質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 本稿は、2024年9月25日に Networking & Content Delivery で公開された “ Introducing security group referencing for AWS Transit Gateway ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。

GoPro は、イマーシブかつエキサイティングな方法で画像のキャプチャや共有をサポートしています。2002年の設立以来、GoPro は、お客様がコンテンツから最大限の価値と楽しみを得られるように、多用途のカメラとソフトウェアツールをリリースしてきました。Amazon Web Services (AWS) がサポートする GoPro サブスクリプション は、カメラ、マウント、アクセサリー、ライフスタイルグッズなどの GoPro のラインナップに加えて、無制限のクラウドストレージ、自動ハイライトビデオ、デバイス間で同期される便利な編集機能、ライブストリーミングプラットフォーム、ソーシャルメディアプラットフォームと直接コンテンツを共有する機能など、GoPro 体験を結びつけます。現在、GoPro は毎月大量の動画データを処理し、 約250万人の加入者にサービスを提供 しています。 図 1: GoPro でのメディア処理 GoPro は独自のトランスコーディングとメディア処理パイプラインを使用しており、さまざまなデバイス、ビットレート、コーデック、帯域幅をサポートしています。コンテンツが Amazon Simple Storage Service (Amazon S3) に取り込まれると、前処理を行うジョブが実行されてメタデータ、解像度、コーデック情報が収集され、動画のサムネイルが作成されます。さまざまなクラスのトランスコーディングジョブが、Amazon EC2 上の FFmpeg を使用して、 Amazon Elastic Container Service (Amazon ECS) クラスター、Docker コンテナ、カスタム設定ビルドで実行されます。また、動画と音声、 GPMF (GoPro Metadata Format/General Purpose Metadata Format) 、デマルチプレクサ、マルチプレクサのトランスコーディングを組み合わせるために、Amazon EC2 上で他の独自のツールを使用しています。 GoPro は当初、エンドユーザーがコンテンツを取り込み、処理、保存、共有できるようにするために、AWS を使用してサブスクリプションサービスを展開していました。しかし、加入者数とユーザーが生成するコンテンツの量が増加するにつれて、GoPro は柔軟でスケーラブルなインフラストラクチャを備えた、より適応性の高いコンテンツ処理パイプラインを必要とするようになりました。 一時的にピークが高くなる季節的なトラフィックに対して、インスタンスのオートスケーリングは弾力性とスケーラビリティを提供し、トランスコーディング中のEC2 キャパシティの増減を管理します。トランスコーディングワークフローは非同期で、メッセージとイベント駆動型であるため、複数のジョブを並行して実行することで効率を高め、ワークロードは中断に耐えることができます。GoPro は Amazon ECS クラスターを Amazon EC2 スポットインスタンス にデプロイして、より費用対効果の高いコンピューティングを実現し、オンデマンドコストを約 50% ～ 70% 削減しました。Amazon EC2 スポットインスタンスは、オンデマンド価格と比較して最大 90% 割引で利用できることを特徴としています。 GoPro は EC2 スポットインスタンスのベストプラクティス を活用しています。可能な限り幅広く多くのキャパシティプールを分散して利用することで、終了したスポットインスタンスを他のスポットインスタンスで置き換え、ピーク時のトラフィックを処理しています。スポットインスタンスの中断の頻度を最小限に抑えるため、GoPro はキャパシティ最適化配分戦略を採用しています。また、Terraform スクリプトによる自動化で、中断されたスポットインスタンスの自動ドレインを実行する機能も実装しています。 Auto Scaling グループにおいては 属性ベースのインスタンスタイプ選択 を使用することで、Amazon ECS クラスターではCPU インスタンスと GPU インスタンスの両方を使用しています。 instance_requirements = { memory_mib_min = 32768 memory_mib_max = 131072 vcpu_count_min = 32 vcpu_count_max = 64 cpu_manufacturers = ["amd", "intel"] excluded_instance_types = (["a*", "t*", "m6g*", "c6g*", "c7g*", "d*", "h*", "i*", "g*", "p*", "inf1*", "dl*", "vt*", "x*", "r6g*", "z1*", "f1*"]) } 他のすべての Auto Scaling グループでは、次の例のようなインスタンスタイプを使用しています。 （訳者注）以下の例では以前の世代のインスタンスタイプが多く見られますが、なるべくより新しい世代のものも含めることも選択肢として重要です。 spot-instance-type = [ { instance_type = "r5b.4xlarge" }, { instance_type = "r4.4xlarge" }, . . . ] spot-instance-type = [{ instance_type = "g4dn.xlarge" }] spot-instance-type = [{ instance_type = "c3.4xlarge" }, { instance_type = "c3.8xlarge" }, { instance_type = "c4.4xlarge" }, { instance_type = "c4.8xlarge" }, . . . ] Auto Scaling グループ (ASG) は配分戦略としてキャパシティ最適化を行うように設定されています。これにより、起動するインスタンスの数に最適なキャパシティを持つプールからスポットインスタンスをリクエストします。 spot-allocation-strategy = "capacity-optimized" （訳者注）配分戦略は価格とキャパシティの両方を考慮する price-capacity-optimized (料金キャパシティ最適化) をより推奨していますが、GoPro ではキャパシティのみを考慮し中断の可能性を最も下げることができる capacity-optimized を利用しています。 ワークフローのレジリエンスは、一連の AWS Lambda 関数の実行で高められています。 Auto Scaling グループスケールイン CloudWatch イベントは、終了中のインスタンスのドレインを実行する Lambda 関数 (General Drain と呼んでいる) をトリガーします。 もう 1 つの Lambda 関数 (Spot Drain と呼んでいる) はスポット ASG に特化したもので、EC2 スポットインスタンス中断通知が発生するとトリガーされます。 スポットインスタンスにかんするメトリクスの収集にはさらに別の Lambda 関数が使用され、これはインスタンス終了時、起動時、およびスポットインスタンスの中断時にトリガーされます。 図 2: EC2 Auto Scaling を使ったトランスコードワークフロー ワークフロー全体は、AWS Lambda を利用した GoPro 用のカスタムビルドのダッシュボードで監視されています。このダッシュボードは、Amazon ECS を使用してスポットインスタンスをモニタリングおよび可視化し、中断率、インスタンスタイプ、およびスポットインスタンスに関連するその他の統計情報を表示します (図3)。 図3: スポットインスタンス関連の統計情報を表示するダッシュボード Amazon EC2 スポットインスタンスを追加し、潜在的な中断に備えて設計した結果、GoPro はコンテナ化された全ワークロードの 70% 以上をスポットインスタンスで実行し、大幅なコスト削減を実現しています。 この記事では、Amazon EC2 スポットインスタンスによって GoPro がコンピューティングリソースをよりコスト効率よく活用し、メディアサプライチェーンにおけるトランスコーディングプロセスを大規模に改善する方法について説明しました。スポットインスタンスの詳細については、 EC2 スポットインスタンスのベストプラクティスのドキュメント をご覧ください。 このブログは、GoPro DevOpsエンジニアのVlad-Alexandru Voineaと、GoProのDevOpsマネージャーであるZaven Boniが執筆し、テクニカルアカウントマネージャーのJenny Oshimaが公開したものを、ソリューションアーキテクトの石神靖弘が翻訳しました。原文は こちら です。

本記事は 2024 年 10 月 8 日に公開された “ Get started with Amazon ElastiCache for Valkey ” を翻訳したものです。 2024 年 10 月 8 日、 Amazon ElastiCache は、Serverless の価格が他のサポートされているエンジンより 33% 低く、セルフデザインの (ノードベースの) クラスターが 20% 低い Valkey バージョン 7.2 のサポートを発表しました。ElastiCache Serverless for Valkey を使えば、お客様は 1 分以内にキャッシュを作成でき、月額 $6 から利用を開始できます。Valkey は、40 社以上に支持されている Linux Foundation が運営するオープンソース、高性能のキーバリューデータストアです。Valkey は Redis OSS の代替製品で、長年 Redis OSS に貢献してきた開発者とメンテナが開発し、2024 年 3 月のプロジェクト開始以来、急速に採用が広がっています。AWS は Valkey プロジェクトに積極的に貢献 しています。今回のリリースにより、お客様はオープンソーステクノロジーに基づくフルマネージド環境の恩恵を受けながら、ElastiCache が提供する 13 年以上の運用の卓越性、セキュリティ、信頼性の利点を活用できます。 この記事では、ElastiCache for Valkey の概要、その利点、および ElastiCache for Redis OSS キャッシュから ElastiCache for Valkey キャッシュへのアップグレード方法をご紹介します。 ElastiCache for Valkey の概要 Amazon ElastiCache は、フルマネージド型の Valkey、Memcached、Redis OSS 互換のキャッシュサービスで、モダンアプリケーションに対してリアルタイムでコスト最適化されたパフォーマンスを提供します。ElastiCache は、マイクロ秒のレスポンスタイムで毎秒数百万のオペレーションにスケールでき、エンタープライズグレードのセキュリティと信頼性を備えています。ElastiCache for Valkey では、セルフデザインの (ノードベースの) クラスターとサーバーレスキャッシュのデプロイオプションを選択できます。自動スケーリング、マルチ AZ デプロイによる高可用性、リージョン間レプリケーションなどの機能を活用でき、ビジネス継続性とディザスタリカバリが確保されます。ElastiCache を通して Valkey をマネージドサービスとして提供することで、AWS はお客様が Valkey の豊富な機能を運用オーバーヘッドなしに活用できるようにしています。 ElastiCache for Valkey の利点: 価格の引き下げ: ElastiCache Serverless for Valkey では、33%の価格引き下げと、最低 100MB の最小データストレージ容量で月額 6 ドルからの低価格を実現しています。ElastiCache for Valkey のセルフデザイン(ノードベース)クラスターでは、他のエンジンと比べて最大 20%のコスト削減が可能です。さらに、 ElastiCache では、インスタンスファミリーと AWS リージョン内でリザーブドノードのサイズの柔軟性がサポートされています 。ElastiCache のリザーブドノードを使用している場合、ElastiCache for Redis OSS から ElastiCache for Valkey に切り替えても、同じファミリー内のすべてのノードサイズで既存のリザーブドノード割引料金が維持され、リザーブドノード割引のさらなる価値を得られます。 運用の卓越性: ElastiCache for Valkey は、オープンソーステクノロジーに基づいて構築されたフルマネージド型の体験を提供し、AWS のセキュリティ、運用の卓越性、99.99%の可用性、信頼性を活用しています。 パフォーマンス: お客様は、最も高いパフォーマンスが求められるリアルタイムアプリケーションの基盤として ElastiCache を選択しています。マイクロ秒単位の読み書き待ち時間を実現でき、単一のセルフデザイン(ノードベース)クラスターで 5億リクエスト/秒(RPS)までスケールできます。 API 互換性: ElastiCache for Valkey は、Redis OSS の API とデータフォーマットに互換性があり、お客様はコードを書き換えたり、アーキテクチャを変更する必要なくアプリケーションを移行できます。 ダウンタイムゼロの移行: ElastiCache for Redis OSS の既存ユーザーは、ダウンタイムゼロで ElastiCache for Valkey にすばやく移行できます。 継続的なイノベーション: AWS が Valkey をサポートすることで、お客様は安定したソリューションを採用するだけでなく、将来の成長とイノベーションに備えることができます。Valkey コミュニティがプロジェクトの開発と強化を続けるにつれ、AWS のお客様は継続的な改善と新機能の恩恵を受け、アプリケーションの競争力を維持できます。AWS も Valkey に積極的に貢献しており、 Amazon ElastiCache and Amazon MemoryDB announce support for Valkey でさらに詳しく読むことができます。 ソリューションの概要 Amazon ElastiCache for Valkey を使い始めるには、わずか数ステップで行えます: ElastiCache Serverless for Valkey キャッシュを作成します。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを作成します。 valkey-cli ユーティリティをダウンロードし、セットアップします。 アプリケーションからキャッシュに接続します。 これらの手順については、次のセクションで説明します。その後、データベースに対する基本的な操作を実演します。また、ElastiCache for Redis OSS から ElastiCache for Valkey へのアップグレード方法についても説明します。 ElastiCache Serverless for Valkey キャッシュの作成 AWS Management Console 、 AWS Command Line Interface (AWS CLI)、または ElastiCache API を使用して、ElastiCache Serverless for Valkey キャッシュを作成できます。以下は、AWS CLI を使用して ElastiCache Serverless for Valkey キャッシュを作成する例です。ElastiCache で Valkey リソースを使用するには、CLI のバージョンが最新であることを確認してください。 aws elasticache create-serverless-cache \ --serverless-cache-name ec-valkey-serverless \ --engine valkey \ --region us-east-1 これにより、デフォルトの VPC 内に ElastiCache Serverless for Valkey キャッシュが作成され、デフォルトのセキュリティグループが使用されます。 ElastiCache Serverless キャッシュの作成ステータスは、 describe-serverless-caches コマンドで確認できます。 aws elasticache describe-serverless-caches \ --serverless-cache-name ec-valkey-serverless \ --region us-east-1 { "ServerlessCaches": [ { "ServerlessCacheName": "ec-valkey-serverless", "Description": " ", "CreateTime": "2024-08-14T21:28:11.116000 + 00:00", "Status": "available", "Engine": "valkey", "MajorEngineVersion": "7", "FullEngineVersion": "7.2", "SecurityGroupIds": [ "sg-bba254aa" ], "Endpoint": { "Address": "ec-valkey-serverless-xxx.cache.amazonaws.com", "Port": 6379 }, "ReaderEndpoint": { "Address": "ec-valkey-serverless-xxx.cache.amazonaws.com", "Port": 6380 }, "ARN": "arn:aws:elasticache:xxx:ec-valkey-serverless", "SubnetIds": [ "subnet-x", "subnet-y", "subnet-z" ], "SnapshotRetentionLimit": 0, "DailySnapshotTime": "03:00" } ] } EC2 から ElastiCache Serverless for Valkey キャッシュへの接続設定 ElastiCache は、同じ Amazon Virtual Private Cloud (Amazon VPC) 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスから、または VPC ピアリングを使用して別の Amazon VPC 内の EC2 インスタンスからアクセスできます。 EC2 の開始方法 を使用して EC2 インスタンスを作成します。ElastiCache Serverless for Valkey キャッシュは、ポート 6379 とポート 6380 の両方を使用します。EC2 インスタンスから Valkey コマンドを正常に実行してキャッシュに接続するには、必要に応じてこれらのポートへのアクセスをセキュリティグループで許可する必要があります。 valkey-cli のダウンロードとセットアップ EC2 インスタンスに接続し、次のコマンドを実行して valkey-cli ユーティリティをダウンロードしてください。 sudo yum install gcc jemalloc-devel openssl-devel tcl tcl-devel -y wget https://github.com/valkey-io/valkey/archive/refs/tags/7.2.7.tar.gz tar xvzf 7.2.7.tar.gz cd valkey-7.2.7/ make BUILD_TLS=yes install valkey-cli を使用して Valkey エンジンに接続しコマンドを実行する詳細な手順については、 valkey-cli のドキュメント を参照してください。valkey-cli をインストールする際は、TLS のサポートを構築することが重要です。ElastiCache Serverless for Valkey キャッシュは、TLS が有効になっている場合にのみアクセスできます。 Valkey キャッシュへの読み書き接続 ElastiCache Serverless for Valkey キャッシュに接続するには、describe-serverless-caches AWS CLI コマンドを使用して、新しいサーバーレスキャッシュのエンドポイントを取得します。2 つのエンドポイントが表示されます。 aws elasticache describe-serverless-caches \ --serverless-cache-name ec-valkey-serverless \ --region us-east-1 "Endpoint": { "Address": "ec-valkey-serverless-xxx.cache.amazonaws.com", "Port": 6379 }, "ReaderEndpoint": { "Address": "ec-valkey-serverless-xxx.cache.amazonaws.com", "Port": 6380 } Valkey キャッシュに接続するには、valkey-cli ユーティリティを使用して ElastiCache Serverless に接続してください。 valkey-cli -h ec-valkey-serverless-xxx.cache.amazonaws.com -p 6379 -c --tls -h = ホスト名 -p = ポート -c = クラスターモード –tls = TLS 有効化クラスター これで、Valkey キャッシュに対して基本的な GET と SET 操作を実行する準備ができました。以下は、Valkey で HASH オブジェクトを作成するための HSET 操作の例です。Valkey のハッシュは、フィールド値のペアのコレクションを格納するためのデータ構造です。ハッシュは、複数の属性 (例えば、名前、年齢、メールアドレス) を持つユーザープロファイルなど、オブジェクトを表現したり、関連するデータを単一のエンティティに格納する必要がある場合に便利です。 ec-valkey-serverless-xxx.cache.amazonaws.com:6379> hset car:1 make ferrari model sf90spider year 2024 engine "4.0 L V8" horsepower 769hp transmission "8-speed auto" price 580000 (integer) 7 ec-valkey-serverless-xxx.cache.amazonaws.com:6379> これにより、make、model、year、engine、horsepower、transmission、price などの属性を持つ Hash オブジェクト car:1 が作成されます。 今度は、HMGET または HGETALL 操作を使用して、個々のフィールド値のペアまたはすべてのフィールド値のペアを取得できます。 ec-valkey-serverless-xxx.cache.amazonaws.com:6379> HMGET car:1 make model price 1) "ferrari" 2) "sf90spider" 3) "580000" ec-valkey-serverless-xxx.cache.amazonaws.com:6379> ElastiCache for Redis OSS から ElastiCache for Valkey へのアップグレード ElastiCache for Redis OSS の既存ユーザーの場合、ダウンタイムなしで ElastiCache for Valkey にすばやくアップグレードできます。次の例は、ElastiCache for Redis OSS キャッシュが ElastiCache for Valkey キャッシュにアップグレード準備ができている状態を示しています。 ElastiCache コンソールで、ナビゲーションペインから Redis OSS キャッシュ を選択し、 変更 を選択して、アップグレードプロセスを開始します。 ElastiCache の変更ウィンドウのクラスター設定で、Redis OSS と Valkey を含む複数の エンジンオプションが表示されます。エンジンオプションとして Valkey を選択し、 変更をプレビュー を選択します。 次の画面では変更の概要が表示されます。 すぐに適用 で はい を選択して、Redis OSS から Valkey へのエンジン変更を確認し、 変更 を選択します。 変更 を選択すると、 クラスターを変更するアクションが正常に開始されました。 という通知が表示されます。 既存の ElastiCache for Redis OSS キャッシュのステータスは “Modifying” になります。 アップグレードが正常に完了すると、 elasticache-redisoss-cache-cluster は Redis OSS キャッシュの下に表示されなくなり、代わりに Valkey キャッシュ の下に表示されます。 アプリケーションへの影響を最小限に抑えながら、Redis OSS から Valkey へのエンジンアップグレードが完了しました。 クリーンアップ 最小特権の原則を維持し、将来の課金を避けるために、この記事の一環として作成したリソースを削除してください。ElastiCache クラスター (詳細は クラスターの削除 を参照) と EC2 インスタンス ( delete-instance ) を削除してください。 結論 この投稿では、ElastiCache for Valkey キャッシュを作成する方法、ElastiCache Serverless for Valkey キャッシュに接続するための Elastic Compute Cloud (EC2) インスタンスのセットアップ方法、ElastiCache Serverless for Valkey キャッシュへの読み書き接続方法を説明しました。また、ElastiCache for Redis OSS キャッシュから ElastiCache for Valkey キャッシュへのアップグレードの例も示しました。 Valkey サポートの追加により、Amazon ElastiCache は、AWS がデータベースアプリケーション向けに堅牢なオープンソースソリューションを提供するという取り組みにおいて、大きな前進を遂げました。まだサインアップしていない場合は、 ElastiCache ページで 使用を開始する を選択し、サインアッププロセスを完了してください。サインアップ後は、Amazon ElastiCache for Valkey の入門ガイドを含む ElastiCache ドキュメントを参照してください。ElastiCache for Valkey に慣れた後は、ElastiCache コンソール、AWS CLI、または ElastiCache API を使用して、数分でサーバーレスクラスターを作成できます。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Madelyn Olson は Valkey プロジェクトのメンテナーであり、Amazon ElastiCache と Amazon MemoryDB のプリンシパルソフトウェア開発エンジニアです。Valkey エンジンのセキュアで高信頼性の機能を構築することに注力しています。余暇には、太平洋北西部の自然の美しさを長い散歩やのんびりした自転車に乗って楽しんでいます。 Goumi Viswanathan は、Amazon In-Memory Databases チームのシニアプロダクトマネージャーです。12 年以上のプロダクト経験があり、データベースソリューションを提供するクロスファンクショナルチームをリードしています。仕事以外では、旅行と屋外での時間を楽しんでいます。 Siva Karuturi はテキサス州ダラスを拠点とする、インメモリデータベースのワールドワイドスペシャリストソリューションアーキテクトです。Siva は、さまざまなデータベーステクノロジー (リレーショナルおよび NoSQL の両方) に精通しており、クラウドコンピューティング、ガバナンス、セキュリティ、アーキテクチャ、高可用性、ディザスターリカバリ、パフォーマンス強化を含むインメモリデータベースおよび分析ソリューションの複雑なアーキテクチャの実装と、リーダーシップの提供をお客様に支援しています。仕事以外では、Anthony Bourdain スタイルで旅行や様々な料理を味わうのが好きです。

本稿は 「 Aramark launches first Just Walk Out store in a US corporate headquarters 」（記事公開日： 2024 年 7 月 22 日）の翻訳記事です。 従業員がオフィスに戻るにつれ、ビジネスリーダーは進化するニーズを持った変化する労働力に直面しています。多くの人が、オフィスで食べ物や飲み物を購入する際の利便性を重視し、目的を持った買い物をしていることを認識しています。彼らは、出社、昼食や休憩、帰宅の際、移動中に買い物をし、素早く商品を選びます。 フォーチュン 200 企業で世界的な食品・施設管理のリーダー企業である Aramark は、便利で 24 時間 365 日利用可能な職場での栄養補給の需要の高まりに対応することを目指しています。6月、Aramark はフィラデルフィアのセンターシティにあるグローバル本社に「The Market」を開設しました。The Market は、米国の企業本社に開設された最初の Just Walk Out テクノロジー 店舗です。 Aramark の The Market、出典：Aramark 最適化された The Market Aramark は、世界 15 か国で食品サービスと施設管理を提供しています。その顧客には、教育機関、フォーチュン 500 企業、スポーツチーム、医療提供者、観光地や文化施設、多数の自治体などがあります。フィラデルフィアのリバーフロントにある Aramark の本社には、1,200 人以上の管理およびサポート担当者が勤務し、魅力的なアメニティを備えた活気のある職場環境が提供されています。The Market には、テイクアウトの食品、スイーツやスナック、ソフトドリンク、水、ジュースが入った冷蔵庫など、幅広い商品が揃っています。 Aramark の The Market、出典：Aramark 「フィラデルフィアの Aramark 本社にある LifeWorks café は、私たちにとってゲストの体験が常に最優先されている素晴らしい例です」と LifeWorks レストラングループの地域副社長である Greta Patel は述べています。「ジャーニーの全てが計画され、シームレスで効率的な体験を生み出しています。Just Walk Out テクノロジーを備えた The Market は、従業員の体験をさらに向上させ、店内をスムーズに移動し、日々の業務に戻ることを可能にします。」 手間のないショッピング Just Walk Out テクノロジーは、チェックアウト不要のショッピング体験です。お客様はクレジットカードをスキャンして The Market に入店し、必要な商品を手に取り、列に並ぶことなく、そのまま退店できます。Just Walk Out テクノロジーは、ディープラーニング、センサーフュージョン、AI、コンピュータービジョン( RFID テクノロジー)を使用して、お客様が商品を手に取ったり戻したりしたことを自動的に検知します。取得した商品は仮想カートで追跡されます。お客様が退店すると、手に取った商品の代金が請求されます。このテクノロジーは、一緒にショッピングをするグループも追跡できます。グループが 1 枚のクレジットカードで入店すると、システムは個人を追跡しつつ、そのグループを同じ支払い方法に関連付けます。これは、 Aramark 社員が会議用の商品を購入する際の、グループのショッピングツアーで特に便利です。グループが退店すると、システムは一緒にショッピングをした人々を認識し、その取引全体で1つの領収書を発行します。 商品を手に取って出るだけ オフィス環境における Just Walk Out ストアは、企業の売上増加、盗難減少、そしてイノベーションの紹介に役立ちます。 Aramark の The Market では営業時間の延長とスタッフの最適化が可能になり、店舗スタッフがピーク時間でもより価値の高い業務に専念できるようになり、売上を犠牲にすることなく運営コストを削減できます。 「人々が忙しかったり、急いでいるところでは、Just Walk Out テクノロジーの価値が見えてきます」とアマゾンの Just Walk Out テクノロジーのVP である Jon Jenkins は述べています。「オフィスにいる場合、会議と会議の間の数分間で軽食と飲み物を手に入れ、机に戻らなければならないかもしれません。The Market by Aramark は、従業員に高速で手間のかからない買い物体験を提供します。」 Aramark の The Market、出典：Aramark Aramark とのパートナーシップによる他の Just Walk Out の場所 には、シカゴのノースパーク大学の the Viking Market 、レズリー大学の Lesley on the Go ( Aramark Collegiate Hospitalityと共同)、Minute Maid Park とCoors Field ( Aramark Sports + Entertainment と共同) があります。 詳細は justwalkout.com をご覧いただき、 LinkedIn でも当社をフォローしてください。 著者について Sarah Yacoub Sarah Yacoub は、AWS のマーケティングシニアマネージャーで、アマゾンの Just Walk Out テクノロジーのマーケティングを担当しています。彼女はワシントン DC に拠点を置いています。   本稿はソリューションアーキテクトの齋藤が翻訳を担当しました。原文は こちら 。

EC2 Image Builder での macOS サポートを発表できることを嬉しく思います。この新機能により、Windows と Linux の既存のサポートに加えて、macOS ワークロード用のマシンイメージを作成および管理できます。 ゴールデンイメージは、 Amazon マシンイメージ (AMI) とも呼ばれる起動可能なディスクイメージで、オペレーティングシステムとワークロードに必要なすべてのツールがあらかじめインストールされています。継続的インテグレーションと継続的デプロイ（CI/CD）パイプラインのコンテキストでは、ゴールデンイメージにはほとんどの場合、特定のバージョンのオペレーティングシステム（macOS）と、アプリケーションのビルドとテストに必要なすべての開発ツールとライブラリ（ Xcode 、 Fastlane など）が含まれています。 macOS のゴールデンイメージを構築するためのパイプラインを開発して手動で管理するのは時間がかかり、有能なリソースを他のタスクからそらしてしまいます。また、Linux または Windows イメージを構築するための既存のパイプラインがある場合は、macOS イメージの作成にさまざまなツールを使用する必要があるため、ワークフローがばらばらになります。 このような理由から、EC2 Image Builder を使用して macOS イメージを管理できる機能を求める声が多く寄せられています。複数のオペレーティングシステム間でイメージパイプラインを統合し、EC2 Image Builder が提供する自動化とクラウド中心の統合を活用したい。 EC2 Image Builder に macOS サポートを追加することで、イメージ管理プロセスを合理化し、macOS イメージを維持するための運用オーバーヘッドを削減できるようになりました。EC2 Image Builder は、ベースイメージを大規模にテスト、バージョニング、検証するので、お好みの macOS バージョンを維持するためのコストを節約できます。 実際の動作を見てみましょう Xcode 16 で macOS AMI を作成するためのパイプラインを作成しましょう。同様の手順で AMI に Fastlane をインストールできます。 高いレベルでは、4 つの主要なステップがあります。 私はインストールしたいツールごとにコンポーネントを定義します。コンポーネントは、インストールするアプリケーションとその方法を EC2 Image Builder に指示する YAML ドキュメント です。この例では、Xcode をインストールするためのカスタムコンポーネントを作成します。Fastlane をインストールする場合は、2 つ目のコンポーネントを作成します。 ExecuteBash アクションを使用して、Xcode のインストールに必要なシェルコマンドを入力します。 レシピ を定義します。レシピはベースイメージから始まり、そこにインストールするコンポーネントが一覧表示されます。 イメージを構築するために使用する インフラストラクチャ構成 を定義します。これにより、イメージを構築するための Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのプールが定義されます。私の場合は、アカウントに EC2 Mac 専有ホストを割り当て、それをインフラストラクチャ設定で参照します。 与えられたレシピと イメージワークフロー を使って、インフラストラクチャ上で実行するパイプラインとスケジュールを作成します。出力 AMI をテストし、選択した宛先（自分のアカウントまたは別のアカウント）に配信します 思ったよりずっと簡単です。 AWS マネジメントコンソール の手順を紹介します。また、 AWS コマンドラインインターフェイス (AWS CLI) を使用して EC2 Image Builder を設定したり、 AWS SDK のいずれかを使用してコードを記述したりすることもできます。 ステップ 1: コンポーネントの作成 コンソールを開き、「 EC2 Image Builder 」、「 コンポーネント 」、「 コンポーネントの作成 」の順に選択します。 ベース イメージオペレーティングシステム と 互換性のある OS バージョン を選択します。次に、 コンポーネント名 と コンポーネントバージョン を入力します。「 ドキュメントコンテンツを定義 」を選択し、この YAML を コンテンツ として入力します。 name: Xcode ドキュメントをインストール description: Xcode をダウンロードしてインストールします。まず、必ずラップトップから「xcodeinstall authenticate -s us-east-1」を実行してください。 schemaVersion: 1.0 phases: - name: ビルド steps: - name: Xcode をインストール action: Bash を実行 inputs: commands: - sudo -u ec2-user /opt/homebrew/bin/brew tap sebsto/macos - sudo -u ec2-user /opt/homebrew/bin/brew install xcodeinstall - sudo -u ec2-user /opt/homebrew/bin/xcodeinstall download -s us-east-1 --name "Xcode 16.xip" - sudo -u ec2-user /opt/homebrew/bin/xcodeinstall install --name "Xcode 16.xip" - name: 検証 steps: - name: Xcode をテスト action: Bash を実行 inputs: commands: - xcodebuild -version && xcode-select -p 私が書いたツールを使って、コマンドラインから Xcode をダウンロードしてインストールします。 xcodeinstall は AWS Secrets Manager と統合され、認証ウェブトークンを安全に保存します。パイプラインを実行する前に、 ラップトップから xcodeinstall authenticate -s us-east-1 コマンドを使用して認証します。このコマンドは Apple サーバーとのセッションを開始し、セッショントークンを Secrets Manager に保存します。xcodeinstall は、イメージ作成パイプライン中にこのトークンを使用して Xcode をダウンロードします。 Secrets Manager で xcodeinstall を使用する場合、シークレットにアクセスするための権限をパイプラインに付与する必要があります。これは、EC2 Image Builder が使用する EC2 インスタンスにアタッチされたロールに追加したポリシードキュメントです (以下のインフラストラクチャ構成)。 { "Sid": "xcodeinstall", "Effect": "Allow", "Action": [  "secretsmanager:GetSecretValue" "secretsmanager:PutSecretValue" ], "Resource": "arn:aws:secretsmanager:us-east-1:<アカウントID>:secret:xcodeinstall*" } EC2 Mac インスタンスの起動とリサイクルを長時間待たずに、これらのコンポーネントをローカルでテストおよびデバッグするには、 AWS Task Orchestrator and Executor (AWSTOE) コマンドを使用できます。 ステップ 2: レシピの作成 次のステップはレシピを作成することです。コンソールで「 イメージレシピ 」と「 イメージレシピの作成 」を選択します。 ベース イメージオペレーティングシステム として macOS を選択します。 イメージ名 として macOS Sonoma ARM64 を選択します。 「 ビルドコンポーネント 」セクションで、ステップ 1 で作成した Xcode 16 コンポーネントを選択します。 最後に、ボリュームがオペレーティングシステム、Xcode、およびビルドを保存するのに十分な大きさであることを確認します。私は通常 500 Gb gp3 ボリュームを選択します。 ステップ 3 と 4: パイプライン (およびインフラストラクチャ構成) の作成 EC2 Image Builder ページで、「 イメージパイプライン 」と「 イメージパイプラインの作成 」を選択します。パイプラインに名前を付け、 ビルドスケジュール を選択します。このデモでは、手動トリガーを選択します。 次に、先ほど作成したレシピ (Sonoma-Xcode) を選択します。 イメージ作成プロセスの定義 に デフォルトワークフロー を選択しました（簡潔にするために示していません）。 既存の インフラストラクチャ構成 を作成または選択します。macOS イメージを構築する場合、最初に Amazon EC2 専有ホスト を割り当てる必要があります。ここで、EC2 Image Builder が AMI の作成に使用するインスタンスタイプを選択します。仮想プライベートクラウド (VPC)、セキュリティグループ、 AWS Identity and Access Management (IAM) ロール、イメージの準備中に必要な権限、キーペア、EC2 インスタンスの起動時に通常選択するすべてのパラメータをオプションで選択することもできます。 最後に、出力 AMI を配信する場所を選択します。デフォルトでは、私のアカウントに残ります。ただし、他のアカウントと共有またはコピーすることもできます。 パイプラインを実行 これで、パイプラインを実行する準備ができました。 イメージパイプライン を選択し、次に作成したパイプライン（ Sonoma-Xcode ）を選択します。 アクション メニューから「 パイプラインを実行 」を選択します。 Amazon CloudWatch から進捗状況と詳細なログを確認できます。 しばらくすると、AMI が作成され、使用できる状態になります。 AMI をテスト デモを終了するために、先ほど作成した AMI で EC2 Mac インスタンスを起動します (最初に専有ホストを割り当てるか、EC2 Image Builder で使用したホストを再利用することを忘れないでください)。 インスタンスが起動したら、Secure Shell (SSH) を使用してインスタンスに接続し、Xcode が正しくインストールされていることを確認します。 料金と利用可能なリージョン EC2 Mac インスタンスが利用可能なすべての AWS リージョンで、EC2 Image Builder for macOS が利用可能になりました：米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、ソウル、シンガポール、シドニー、東京)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、ストックホルム) (すべてのリージョンですべての Mac インスタンスタイプを利用できるわけではありません )。 追加コストは発生せず、パイプラインの実行中に使用されたリソース、つまり EC2 Mac 専有ホストが割り当てられた時間に対してのみ課金されます (最低 24 時間)。 EC2 Image Builder の macOS サポートのプレビューでは、イメージパイプラインを統合し、ゴールデンイメージ作成プロセスを自動化し、AWS でのクラウド重視の統合のメリットを活用できます。EC2 Mac プラットフォームがインスタンスタイプを増やして拡大し続けるにつれて、この新機能により EC2 Image Builder は Windows、Linux、macOS にわたるイメージ管理のための包括的なソリューションとしての地位を確立しています。 最初のパイプラインを今すぐ作成しましょう！ — seb 原文は こちら です。

4 か月前、AWS は Amazon Bedrock に Anthropic の Claude 3.5 を導入 して、 Claude 3 Sonnet のスピードとコストを維持しながら、AI モデルインテリジェンスの業界水準を引き上げました。 10 月 22 日は、 Amazon Bedrock で利用できる Claude 3.5 モデルファミリー の 3 つの新しい機能をご紹介したいと思います。 アップグレードされた Claude 3.5 Sonnet – 前バージョンの長所をさらに強化し、より優れたインテリジェンスを同じコストで提供する、アップグレードされた Claude 3.5 Sonnet モデルにアクセスできるようになりました。Claude 3.5 Sonnet は、現実世界のソフトウェアエンジニアリングタスクを解決し、複雑なエージェント型ワークフローに従う能力を絶えず向上させています。アップグレードされた Claude 3.5 Sonnet は、初期設計からバグ修正、メンテナンス、そして最適化まで、ソフトウェア開発ライフサイクルの全体を支援します。これらの機能でアップグレードされた Claude 3.5 Sonnet モデルは、温かみのある人間のような口調で話す、より高度なチャットボットの構築に役立ちます。アップグレードされたモデルが能力を発揮するその他のユースケースには、ナレッジ Q&A プラットフォーム、グラフや図などの視覚的素材からのデータ抽出、反復的なタスクや操作の自動化などがあります。 Computer Use 機能 – アップグレードされた Claude 3.5 Sonnet は、Amazon Bedrock でパブリックベータ版の Computer Use を提供するようになりました。これは、Claude がコンピュータインターフェイスを認識し、やり取りすることを可能にします。開発者は、人間と同じ方法 (画面を見る、カーソルを動かす、ボタンをクリックする、テキストを入力する) でコンピュータを使用するよう Claude に指示できます。これは、キーストロークやマウスクリック、テキストファイルの編集、シェルコマンドの実行といったコンピュータアクションを返すことができる、統合されたツールへのアクセスをモデルに提供することによって機能します。ソフトウェア開発者は、アクション実行レイヤーを構築することで Computer Use をソリューションに統合し、画面にアクセスする許可を Claude 3.5 Sonnet に付与することができます。そうすることで、ソフトウェア開発者は、コンピュータアクションを実行し、複数のステップに従って、結果を確認する能力を備えたアプリケーションを構築できます。Computer Use は、AI 駆動のアプリケーションに新たな可能性を生み出します。例えば、この機能はソフトウェアのテストやバックオフィスタスクの自動化と、アプリケーションとやり取りできるより高度なソフトウェアアシスタントの実装に役立ちます。このテクノロジーは初期段階にあるため、開発者には、リスクの低いタスクの検討と、サンドボックス環境での使用が推奨されます。 Claude 3.5 Haiku – 新しい Claude 3.5 Haiku の提供が間もなく開始されます。これは、すばやい応答時間と改善された推論機能を兼ね備えているため、スピードとインテリジェンスの両方が必要になるタスクに最適です。Claude 3.5 Haiku は前バージョンの改良版であり、Claude 3 Haiku のスピードとコストで Claude 3 Opus (Claude の旧最大モデル) に匹敵するパフォーマンスを実現します。Claude 3.5 Haiku は、迅速で正確なコード提案、すばやい応答時間を必要とするカスタマーサービス向けの高度にインタラクティブなチャットボット、e コマースソリューション、教育プラットフォームなどのユースケースに役立ちます。金融、ヘルスケア、研究などの分野で大量の非構造化データを扱うお客様の場合は、Claude 3.5 Haiku が情報の効率的な処理と分類に役立ちます。 Anthropic によると、アップグレードされた Claude 3.5 Sonnet は前バージョンを全面的に改善したものであり、既に抜きん出ていた領域であるコーディングが大幅に向上されています。アップグレードされた Claude 3.5 Sonnet は、複数の業界ベンチマークで幅広い改善を示しています。コーディングでは、SWE-Bench Verified のパフォーマンスが 33% から 49% に向上しており、一般公開されているすべてのモデルを上回るスコアを獲得しています。エージェント型ツールを使用するタスクに関する TAU-bench のパフォーマンスも、小売業界では 62.6% から 69.2%、航空業界では 36.0% から 46.0% に向上しています。以下は、Anthropic 提供のモデル評価表です。 AI インタラクションにおける新境地、Computer Use Claude では、API を使用するようにモデルを制限するのではなく、一般的なコンピュータスキルでトレーニングを行っていることから、幅広い標準ツールとソフトウェアプログラムを使用することが可能です。そのため、アプリケーションは Claude を使用してコンピュータインターフェイスを認識し、それらとやり取りすることができます。ソフトウェア開発者はこの API を統合して、Claude がプロンプト (「ローマのホテルを探して」など) を特定のコンピュータコマンド (ブラウザを開く、ウェブサイトを操作するなど) に変換できるようにすることが可能です。 具体的には、ソフトウェア開発者がこのモデルを呼び出すときに、コンピュータを操作するための仮想的な手を提供する 3 つの新しい統合ツールにアクセスできるようになります。 コンピュータツール – このツールは、スクリーンショットやゴールを入力として受け取り、そのゴールを達成するために実行する必要があるマウスとキーボードのアクションの説明を返します。例えば、このツールは、カーソルを特定の位置に移動させる、クリックする、入力する、およびスクリーンショットを撮るように要求できます。 テキストエディタツール – このツールを使用すると、モデルがファイルコンテンツの表示、新しいファイルの作成、テキストの置き換え、編集の取り消しといった操作の実行を要求できます。 Bash ツール – このツールは、ユーザーによるターミナルへの入力に応じて下位レベルでやり取りするために、コンピュータシステムで実行できるコマンドを返します。 これらのツールは、データ分析やソフトウェアのテストから、コンテンツ作成やシステム管理まで、複雑なタスクの自動化に大きな可能性をもたらします。Claude 3.5 Sonnet 駆動のアプリケーションが人間と同じようにコンピュータとやり取りし、ターミナル、テキストエディタ、インターネットブラウザなどの複数のデスクトップツールを操作して、フォームへの入力やコードのデバッグにも対応できることを想像してみてください。 AWS は、ソフトウェア開発者が Amazon Bedrock でこれらの新機能を追求できるようにすることをとても楽しみにしています。この機能は今後数か月で急速に改善されることが予想されますが、コンピュータの使用における Claude の現在の能力には限界があります。アクションには、スクロール、ドラッグ、ズームなど、Claude には処理が困難なものもあるため、リスクの低いタスクの検討をお勧めします。 実際のコンピュータ環境内にあるマルチモーダルエージェントのベンチマーク、 OSWorld を見てみると、アップグレードされた Claude 3.5 Sonnet のスコアは現在 14.9% です。人間レベルのスキルは、これをはるかに上回る約 70〜75％ になっていますが、14.9% という結果は、同じカテゴリーで Claude 3.5 Sonnet に次ぐモデルが得た 7.7％ よりも大幅に優れています。 Amazon Bedrock コンソールでのアップグレードされた Claude 3.5 Sonnet の使用 アップグレードされた Claude 3.5 Sonnet の使用を開始するには、 Amazon Bedrock コンソール に移動して、ナビゲーションペインで [モデルアクセス] を選択します。そこから、新しい [Claude 3.5 Sonnet V2] へのアクセスをリクエストします。 新しいビジョン機能をテストするため、別のブラウザタブを開いて、 Our World in Data ウェブサイト から Wind power generation グラフを PNG 形式でダウンロードしました。 Amazon Bedrock コンソールに戻り、ナビゲーションペインの [プレイグラウンド] で [チャット/テキスト] を選択します。モデルには、モデルプロバイダーとして [Anthropic] を選択してから、 [Claude 3.5 Sonnet V2] を選択します。 チャットの入力セクションにある縦に並んだ 3 つの点を使用して、コンピュータから画像ファイルをアップロードします。その後、以下のプロンプトを入力します。 Which are the top countries for wind power generation? Answer only in JSON. 結果は、私の指示に従って、画像から抽出した情報のリストを返します。 AWS CLI と SDK でのアップグレードされた Claude 3.5 Sonnet の使用 以下は、 Amazon Bedrock Converse API を使用する AWS コマンドラインインターフェイス (AWS CLI) コマンドの例です。CLI の --query パラメータを使用して結果をフィルタリングし、出力メッセージのテキストコンテンツのみを表示します。 aws bedrock-runtime converse \ --model-id anthropic.claude-3-5-sonnet-20241022-v2:0 \ --messages '[{ "role": "user", "content": [ { "text": "What do you throw out when you want to use it, but take in when you do not want to use it?" } ] }]' \ --query 'output.message.content[*].text' \ --output text 出力では、このテキストが応答に表示されます。 An anchor! You throw an anchor out when you want to use it to stop a boat, but you take it in (pull it up) when you don't want to use it and want to move the boat. AWS SDK も同じようなインターフェイスを実装します。例えば、 AWS SDK for Python (Boto3) を使用して、コンソールの例と同じ画像を分析することができます。 import boto3 MODEL_ID = "anthropic.claude-3-5-sonnet-20241022-v2:0" IMAGE_NAME = "wind-generation.png" bedrock_runtime = boto3.client("bedrock-runtime") with open(IMAGE_NAME, "rb") as f: image = f.read() user_message = "Which are the top countries for wind power generation? Answer only in JSON." messages = [ { "role": "user", "content": [ {"image": {"format": "png", "source": {"bytes": image}}}, {"text": user_message}, ], } ] response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages, ) response_text = response["output"]["message"]["content"][0]["text"] print(response_text) アプリケーションとの Computer Use の統合 Computer Use が実際にどのように機能するのかを見てみましょう。まず、Ubuntu システムのデスクトップのスナップショットを撮ります。 このスクリーンショットは、Computer Use が実装するステップの出発点になります。その仕組みを確認するため、モデルに対する入力でスクリーンショットの画像と以下のプロンプトを渡す Python スクリプトを実行します。 Find me a hotel in Rome. このスクリプトは、Computer Use に必要な新しい構文を使用して、Amazon Bedrock 内のアップグレードされた Claude 3.5 Sonnet を呼び出します。 import base64 import json import boto3 MODEL_ID = "anthropic.claude-3-5-sonnet-20241022-v2:0" IMAGE_NAME = "ubuntu-screenshot.png" bedrock_runtime = boto3.client( "bedrock-runtime", region_name="us-east-1", ) with open(IMAGE_NAME, "rb") as f: image = f.read() image_base64 = base64.b64encode(image).decode("utf-8") prompt = "Find me a hotel in Rome." body = { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 512, "temperature": 0.5, "messages": [ { "role": "user", "content": [ {"type": "text", "text": prompt}, { "type": "image", "source": { "type": "base64", "media_type": "image/jpeg", "data": image_base64, }, }, ], } ], "tools": [ { # new "type": "computer_20241022", # literal / constant "name": "computer", # literal / constant "display_height_px": 1280, # min=1, no max "display_width_px": 800, # min=1, no max "display_number": 0 # min=0, max=N, default=None }, { # new "type": "bash_20241022", # literal / constant "name": "bash", # literal / constant }, { # new "type": "text_editor_20241022", # literal / constant "name": "str_replace_editor", # literal / constant } ], "anthropic_beta": ["computer-use-2024-10-22"], } # Convert the native request to JSON. request = json.dumps(body) try: # Invoke the model with the request. response = bedrock_runtime.invoke_model(modelId=MODEL_ID, body=request) except Exception as e: print(f"ERROR: {e}") exit(1) # Decode the response body. model_response = json.loads(response["body"].read()) print(model_response) リクエストの本文には、以下の新しいオプションが含まれています。 Computer Use を有効化するために、値が ["computer-use-2024-10-22"] に設定された anthropic_beta 。 新しい type オプションをサポートする tools セクション (設定するツールのために custom になっています)。 コンピュータツールは、画面の解像度を認識する必要があることに注意してください ( display_height_px および display_width_px )。 モデルは、Computer Use での私の指示に従うために、デスクトップ (入力スクリーンショットによって説明されているもの) で実行するアクションを提供します。 モデルからの応答には、最初のステップを提供する computer ツールからの tool_use セクションが含まれています。モデルは、スクリーンショットにある Firefox ブラウザのアイコンとマウスカーソル (矢印) の位置を把握しているため、今度はマウスを特定の座標に移動して、ブラウザを起動するように要求します。 { "id": "msg_bdrk_01WjPCKnd2LCvVeiV6wJ4mm3", "type": "message", "role": "assistant", "model": "claude-3-5-sonnet-20241022", "content": [ { "type": "text", "text": "I'll help you search for a hotel in Rome.I see Firefox browser on the desktop, so I'll use that to access a travel website.", }, { "type": "tool_use", "id": "toolu_bdrk_01CgfQ2bmQsPFMaqxXtYuyiJ", "name": "computer", "input": {"action": "mouse_move", "coordinate": [35, 65]}, }, ], "stop_reason": "tool_use", "stop_sequence": None, "usage": {"input_tokens": 3443, "output_tokens": 106}, } これは最初の一歩に過ぎません。通常のツール使用リクエストと同様に、このスクリプトはツールの使用結果 (今回はマウスを動かす) で応答する必要があります。ホテルを予約するという最初のリクエストに基づいて、ホテルの予約が完了するまでは、アイコンのクリックや、ブラウザへの URL の入力などを要求するツール使用インタラクションが繰り返されます。 より詳細な例は、 Anthropic が共有したこちらのリポジトリ で確認できます。 知っておくべきこと アップグレードされた Claude 3.5 Sonnet は、米国西部 (オレゴン) AWS リージョン にある Amazon Bedrock で本日から利用可能になり、アップグレード前の Claude 3.5 Sonnet と同じコストで提供されます。リージョンごとの利用可能性に関する最新情報については、 Amazon Bedrock ドキュメント を参照してください。各 Claude モデルのコストに関する詳細は、 Amazon Bedrock の料金ページ をご覧ください。 アップグレードされたモデルのより優れたインテリジェンスに加えて、ソフトウェア開発者は Computer Use (パブリックベータ版で利用可能) をアプリケーションに統合することで、複雑なデスクトップワークフローを自動化し、ソフトウェアのテストプロセスを強化して、より高度な AI 駆動のアプリケーションを作成できるようになります。 Claude 3.5 Haiku は数週間以内にリリースされる予定で、最初はテキストのみのモデルとしてリリースされ、後ほど画像入力が追加されます。 Computer Use がコーディングにどのように役立つかについては、Anthropic の Head of Developer Relations である Alex Albert 氏 の動画でご覧いただけます。 こちらの もうひとつの動画は、操作を自動化するための Computer Use について説明しています 。 これらの新しい機能の詳細については、 Amazon Bedrock ドキュメントの Claude モデルセクション をお読みください。 Amazon Bedrock コンソール でアップグレードされた Claude 3.5 Sonnet を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock までフィードバックをお寄せください。 community.aws では、詳しい技術コンテンツを検索し、ビルダーコミュニティが Amazon Bedrock を使用する方法を見出すことができます。これらの新機能で何を構築するのか教えてくださいね! – Danilo 原文は こちら です。

エージェント型ワークフローは急速に AI イノベーションの基盤となりつつあり、インテリジェントなシステムが人間による問題解決と同じ方法で複雑なタスクを自律的に処理し、改良することを可能にしています。10 月 14 日週、AWS は Serverless Agentic Workflows with Amazon Bedrock の提供を開始しました。これは、 Andrew Ng 博士 および DeepLearning.AI と共同で開発された新しい短時間のコースです。 私の同僚である Mike Chambers が教えるこの実践的なコースでは、インフラストラクチャを管理する手間をかけずに、複雑なタスクを処理できるサーバレスエージェントを構築する方法を学ぶことができます。 Amazon Bedrock を使用して、 Amazon Web Services (AWS) でツールの統合、ワークフローの自動化、および組み込みガードレールを用いた責任あるエージェントのデプロイを実行するために必要なすべての事柄を学びます。 コースで提供されるハンズオンラボでは、AWS パートナーである Vocareum がホストする AWS 環境で知識を直接応用することができます。 DeepLearning.AI コースページ で詳細を確認して、無料で登録しましょう。 それでは、AWS に関する 10 月 14 日週のエキサイティングなニュースを見ていきましょう。 10 月 14 日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon Transcribe が 30 の追加言語でのストリーミングトランスクリプションをサポート – Amazon Transcribe が 30 言語を追加してサポートを拡大し、サポートされる言語が合計で 54 言語になりました。この機能強化は、より広範なグローバルオーディエンスへのアクセスに役立ち、コンタクトセンター、放送、e ラーニングを含めたさまざまな業界全体でアクセシビリティを向上させます。拡張された言語サポートは、より効率的なコンテンツモデレーション、エージェント生産性の向上、およびライブイベントや会議の自動字幕作成を可能にします。 AWS Lambda コンソール が主要関数のインサイトの表面化と リアルタイムのログ分析をサポート – AWS Lambda コンソールに組み込みの Amazon CloudWatch Metrics Insights ダッシュボードが搭載され、CloudWatch Logs Live Tail をサポートするようになりました。これらは、重要な関数メトリクスとリアルタイムのログストリーミングを瞬時に可視化します。これからは、コンソールを離れることなく Lambda 関数のエラーやパフォーマンス問題を特定してトラブルシューティングするとともに、ログが利用可能になると同時にリアルタイムで表示して分析することが可能になります。コンテキストの切り替え頻度を減らして、サーバーレスアプリケーションの開発プロセスとトラブルシューティングプロセスを迅速化することができます。詳細については、 ローンチ記事 をお読みください。 Amazon Bedrock のモデル評価 がカスタムモデルのインポートモデル評価をサポート – モデル評価 機能を使用して、 Amazon Bedrock にインポートされたカスタムモデルを評価できるようになりました。この機能は、モデルをデプロイする前に、それらの選択、カスタマイズ、評価の全サイクルを完了するために役立ちます。インポートされたモデルを評価するには、評価ジョブを作成するときに、モデルセレクターツールで評価対象モデルのリストからカスタムモデルを選択します。 Amazon Q in AWS Supply Chain – インタラクティブな AI アシスタントである Amazon Q を使用して、 AWS Supply Chain でサプライチェーンデータの分析を行い、サプライチェーンをより効率的に運用するためのインサイトを取得できるようになりました。Amazon Q は、データを詳しく調査することによってサプライチェーン関連の質問に答えることができます。この機能は、情報の検索に費やす時間を減らし、回答の取得を合理化して、サプライチェーン運用を改善します。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 以下は、皆さんが関心を持つと思われるその他のニュース項目と記事です。 新しい Amazon OpenSearch Service YouTube チャンネル – このチャンネルは、簡単なチュートリアルや厳選されたコンテンツに加えて、ログ分析、セマンティック検索、ベクトルデータベース、運用上のベストプラクティスなどのトピック別に分類されたプレイリストを提供します。また、今後のチャンネルコンテンツや OpenSearch Service ロードマップの方向性を左右するフィードバックを提供することもできます。 ローンチ記事 で詳細を確認して、 Amazon OpenSearch Service YouTube チャンネルにサブスクライブ しましょう。 Deploying Generative AI Applications with NVIDIA NIM Microservices on Amazon Elastic Kubernetes Service (Amazon EKS)  – この記事では、 Amazon EKS  を使用して  NVIDIA NIM マイクロサービス が含まれるポッドのデプロイをオーケストレーションし、すばやくセットアップできる最適化された大規模言語モデル (LLM) 推論を Amazon EC2 G5 インスタンス で実現する方法を説明します。また、Prometheus 経由でカスタムメトリクスを監視することによってポッドとクラスターの両方をスケールする方法と、 Application Load Balancer を使用して負荷を分散する方法のデモも行います。 Instant Well-Architected CDK Resources with Solutions Constructs Factories – 新しい AWS Solutions Constructs ファクトリ を使用して関数コールを一度実行するだけで、 Amazon Simple Storage Service (Amazon S3)  バケットや AWS Step Functions などの適切に設計された AWS リソースを作成できるようになりました。これらのファクトリは、カスタマイズすることを可能にしながら、ユーザーに代わってすべてのベストプラクティス設定に対応します。サポートされているリソースのいずれかをデプロイする必要が生じたときは、Constructs ファクトリを使用してみてください。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS GenAI Loft – AWS GenAI Loft は、テクノロジーを紹介するだけに留まらず、スタートアップ、開発者、投資者、および業界エキスパートが一堂に集まって交流する場も提供します。深いインサイトを得たい、または 生成 AI の専門家から質問の回答を得たいと考えているかにかかわらず、GenAI Loft は皆さんのニーズに対応し、次のイノベーションの構築を開始するために必要な事柄のすべてを提供します。 ロンドン (10 月 25 日まで)、 ソウル (10 月 30 日～11 月 6 日)、 サンパウロ (11 月 20 日まで)、および パリ (11 月 25 日まで) で開催されるイベントにご参加ください。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスに参加しましょう。日程は、 マルタ (11 月 8 日)、 チリ (11 月 9 日)、および インド、コーチ (12 月 14 日) です。 AWS re:Invent – 12 月 2 日から 6 日にかけてラスベガスで開催される、毎年恒例のテクノロジーイベントの 登録 が開始されました。re: Invent 2024 では、生成 AI などの喫緊のトピックへの対応に関するお客様や AWS リーダーからの体験談を間近で聞くことができます。話題になること間違いなしの 5 つの基調講演で、新製品のローンチについて学び、デモを見て、舞台裏のインサイトを入手してください。 近日開催されるすべての対面イベントと仮想イベントを閲覧できます。 10 月 21 日週はここまでです。10 月 28 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。