Amazon Relational Database Service (Amazon RDS) for SQL Server は、 AWS Nitro System 上に構築された第3世代のIntel Xeon Scalable (Ice Lake) プロセッサを搭載する X2iedn をサポートするようになりました。SQL Serverのワークロードはメモリに大きく依存します。そのため、メモリに最適化された Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが最も一般的に利用されています。 x2iedn インスタンスタイプは、最大 4096 GiB の RAMと 128 個の vCPU を提供し、お客様の最も難易度の高いニーズを満たします。x2iedn を使用することで、お客様のワークロードは同等の X1 インスタンスよりも最大 50 %高いコストパフォーマンスを得ることができます。 Amazon RDS for SQL Serverは、x2iedn インスタンスタイプとして、4, 8, 16, 32, 64, 96, 128 vCPUの 7 つのサイズを提供しています。このブログでは、x2iedn を使用する主な利点について説明し、x2iedn インスタンスタイプと x1e インスタンスタイプで測定したパフォーマンスを比較します。詳細については、 Amazon EC2 X2idn および X2iedn インスタンスの紹介 を参照してください。 特徴 新しいインスタンスタイプは、以下の機能を提供します。 最大 3.5 GHz の第 3 世代 Intel Xeon Scalable プロセッサ（Ice Lake 8375C） すべてのサイズで vCPU に対するメモリの比率は 32 : 1 X1 インスタンスより最大 50 %優れた価格性能 最大 100 Gbpsのネットワーク速度 Amazon Elastic Block Store（Amazon EBS）への帯域幅は最大 80 Gbps 専用ハードウェアと軽量ハイパーバイザーを組み合わせた Nitro System を搭載 次の表は、インスタンスタイプのそれぞれの仕様をまとめたものです。 Instance Name vCPUs Memory (GiB) Storage Memory (GB) Network Bandwidth (Gbps) EBS Bandwidth (Gbps) x2iedn.xlarge 4 128 1 x 118 NVMe SSD Up to 25 Up to 20 x2iedn.2xlarge 8 256 1 x 237 NVMe SSD Up to 25 Up to 20 x2iedn.4xlarge 16 512 1 x 475 NVMe SSD Up to 25 Up to 20 x2iedn.8xlarge 32 1,024 1 x 950 NVMe SSD 25 20 x2iedn.16xlarge 64 2,048 1 x 1900 NVMe SSD 50 40 x2iedn.24xlarge 96 3,072 2 x 1425 NVMe SSD 75 60 x2iedn.32xlarge 128 4,096 2 x 1900 NVMe SSD 100 80 利点 x2iedn RDS DB インスタンスタイプには以下のメリットがあります。 Nitro System 上に構築 – Nitro System は EC2 インスタンスに最新のハードウェアとソフトウェアコンポーネントを提供し、全体的なパフォーマンスを向上させます。さらに、Nitro System 上に構築された RDS DB インスタンスは、高速ネットワーキング、高速 EBS 帯域幅、 I/O アクセラレーションを可能にする専用の Nitro Cards を利用できます。これらの改善により、X1 インスタンスと比較して SQL Server データベースのパフォーマンスが最大 50 %向上します。 vCPU あたりの高いメモリ比率 – X2 インスタンスファミリーは、サポートされているすべての RDS DB インスタンスタイプと比較して、 vCPU あたりのメモリ比率が最も高くなっています。これは、 SQL Server Enterprise Edition や Standard Edition など、コア単位のライセンスに依存する SQL Server ワークロードに最適です。お客様のワークロードは、 X2iedn が提供する vCPU あたりのより大きいメモリ（ 32 GB : 1 vCPU ）によって、 vCPU のプロビジョニング数を減らすことができます。サポートされる RDS インスタンスタイプの詳細については、 Amazon RDS インスタンスタイプ を参照してください。 高いネットワークと EBS スループット – X2iedn では、最大 100 Gbps のネットワーク帯域幅と 80 Gbps の EBS 帯域幅を実現できます。 x1e の最大ネットワーク帯域幅が 25 Gbps、EBS 帯域幅が 14 Gbps であることと比較すると、その差は歴然です。スループット要件を満たすために、より大きなインスタンスサイズをプロビジョニングする必要がなくなります。これにより、抽出、変換、ロード（ ETL ）処理や SQL Server のネイティブバックアップなど、スループット負荷の高いタスクをパフォーマンスに影響を与えることなく実行できます。 ローカル NVMe（インスタンスストア） – tempdb がローカルインスタンスストレージを使用するように構成された状態で X2iedn を起動できます。 tempdb のデータファイルとログファイルをローカルに配置することで、標準的な Amazon EBS ベースのサービスと比較して、読み取りと書き込みのレイテンシを低く抑えることができます。 X2iedn RDS DB インスタンスは、最大 3,600 GB の NVMe（ Non-Volatile Memory Express ）SSD ベースのインスタンスストレージを提供し、低レイテンシ、非常に高いランダム I/O パフォーマンス、および高いシーケンシャルリードスループットを実現するように最適化されています。 X2iedn インスタンスタイプでインスタンスをプロビジョニングする際、 Amazon RDS for SQL Server は自動的にローカルに接続された NVMe ディスクに tempdb ファイルを配置し、ストレージレイテンシーを低減し、特定のワークロードのパフォーマンスを最大 30 %向上させます。AWSのドキュメントを参照して、 マルチ AZ 配置に関する考慮事項 と ファイルの場所とサイズの考慮事項 についてもご確認ください。   x1e インスタンスと x2iedn インスタンスの性能比較 パフォーマンスベンチマークツールである HammerDB を実行し、パフォーマンスを比較検証しました。 HammerDB を使用してテストをベンチマークする方法の詳細については、 HammerDB を使用して Amazon RDS SQL Server のパフォーマンスをベンチマークする を参照してください。 SQL Server 2019 Enterprise Edition 環境に、10,000 warehouses (データベースサイズ 約1TB) のTPC-C データベースを作成しました。プロビジョニングされたストレージは io1 ボリュームタイプで約 2 TB、32 k PIOPSでした。オートパイロット機能のサンプリングを 3 回使用し、各実行では仮想ユーザー（ VU ）の数を設定しました（64、128、256、324、512、724に設定）。 次の表は、各インスタンスの特徴をまとめたものです。 Instance Size vCPUs RAM (GiB) Local NVMe SSD Storage (GB) Network Bandwidth (Gbps) EBS-Optimized Bandwidth (Gbps) db.x1e.4xlarge 16 488 1 x 475 Up to 10 1.75 db.x2iedn.4xlarge 16 512 1 x 475 Up to 25 Up to 20 以下の画像はパフォーマンス結果を示しています。 このパフォーマンス結果から、同じような構成の x1e インスタンスタイプと比較して、85 %高いパフォーマンスを達成することができました。 結論 Amazon RDS for SQL Server データベースを X1e インスタンスで運用している場合は、インスタンスタイプを X2iedn に変更してパフォーマンスを向上させることを検討してください。本番インスタンスを変更する前に、別の環境で インスタンスクラスの変更 をテストすることをお勧めします。インスタンスタイプの変更にはダウンタイムが必要です。メンテナンウィンドウを設定して、変更を実施することができます。 本ブログはSolution Architect 塚本によって翻訳されました。原文は こちら   著者について Sudhir Amin Amazon Web Services のデータベーススペシャリスト・ソリューションアーキテクト。ニューヨークを拠点に、さまざまな業種の企業顧客にアーキテクチャのガイダンスと技術支援を提供し、クラウド導入を加速させている。スヌーカー、ボクシングやUFC などの格闘技の大ファンで、野生動物保護区のある国を旅行し、世界で最も雄大な動物を間近で見るのが趣味。 Vikas Babu Gali Amazon Web Services でマイクロソフトのワークロードを担当するシニアスペシャリスト・ソリューションアーキテクト。インド出身で、趣味はクリケットや、家族や友人とアウトドアをすること。 Julio Oliveira Leme Amazon Web Services データベースエンジニア。2018年に AWS に入社し、RDS SQL Server チームのプロジェクトで新機能やエンジンバージョンのリリースに携わる。趣味は読書と友人や家族と過ごすこと。

­ はじめに 世界中の報道機関やメディア企業が AWS Elemental MediaLive を使用して、インフラストラクチャを管理することなく、高速で信頼性が高く、使いやすい高品質のライブ動画ストリームを配信しています。MediaLive は、ライブストリームの処理と配信のための取り込みとエンコーディング用コンポーネントの設定・管理を自動化することで、ライブ動画のオペレーションを効率化します。現時点では、MediaLive チャネルがアイドル状態で、出力をストリーミングしていないときに自動的に停止させる方法はありません。ライブストリーミングが停止しても、MediaLive チャネルは稼働し続けるため、コストがかかってしまいます。入力がない間はチャネルを停止させたい場合、お客様が手動で停止させる必要があります。 本記事では、MediaLive がどこにもストリーミング出力していないときに MediaLive チャネルを停止させるための完全に自動化されたソリューションを構築する方法、およびお客様がコストを節約できる方法について説明します。 一部の MediaLive リソースについては、アイドル時でも少額の料金が発生することにご留意ください。詳細については、MediaLive の 料金 を確認してください。 前提条件 本記事は、次の前提条件に基づいています。 1.    Single pipeline の、RTMP プッシュ入力による MediaLive チャネルが構成済みである。 2.    チャネルに冗長入力がアタッチされていない。 3.    MediaLive チャネルにファイル入力が設定されていない 4.    MediaLive チャネルの入力損失タイマーはユーザー定義で 10 分に設定されている。MediaLive チャネルのアラートを 10 分間監視した後にチャネルを停止する 5.    MediaLive チャネルにアタッチされた入力は再利用できるため削除しない アーキテクチャ このブログでは、ライブストリーミングソフトウェアとして OBS Studio を使用しています。OBS は、Mac、Windows および Linux と互換性のある、オフラインビデオ録画とライブストリーミング用の無料のオープンソースソリューションです。 MediaLive はライブフィードを取り込み、リアルタイムでエンコードし、放送用の高品質のストリームに圧縮します。MediaLive チャネルには、Standard と Single pipeline の 2 種のチャネルクラスオプションがあります。今回のライブ信号の入力設定には、Single pipeline チャネルを使用します。チャネル設定には、入力を特定の出力にトランスコード (デコードおよびエンコード) してパッケージ化する方法を MediaLive に指示する詳細情報が含まれています。MediaLive は、チャネル内のいずれかのパイプラインで問題、または潜在的な問題が発生すると、アラートを生成します。各アラートの詳細は、MediaLive コンソールの [Alerts] タブに表示されます。 Amazon EventBridge は、コードを記述しなくても、AWS サービスのデータの変更や、独自のアプリケーション、およびサービスとしてのソフトウェア (SaaS) アプリケーションにリアルタイムでアクセスできるようにするサービスです。今回、EventBridge を使って、MediaLive チャネルのアラートを監視するルールを 2 つ作成します。1 つ目のルールは、アラート状態が「SET」でアラートタイプが「RTMP Has No Audio/Video」に一致した受信イベントパターンのアラートをターゲットの AWS Step Functions に送信します。そこでさらに処理が行われます。2つ目のルールは、アラートタイプが「RTMP Has No Audio/Video」に一致した受信イベントパターンをターゲットの Amazon CloudWatch に送信します。CloudWatch は、AWS のクラウドリソースやお客様が AWS で実行するアプリケーションを監視するサービスです。CloudWatch を使用して、メトリクスの収集と追跡、ログファイルの収集と監視、アラームの設定を行うことができます。 Step Functions は、視覚的なワークフローを使用して分散アプリケーションやマイクロサービスのコンポーネントを簡単に調整できるフルマネージドサービスです。ここでは、Step Functions内に、 AWS Lambda 関数 2 つおよび待機状態 1 つから成るワークフローを作成します。 AWS Lambda を使うと、サーバーのプロビジョニングや管理をすることなく、コードを実行することができます。Lambda を使うことで、事実上あらゆるタイプのアプリケーションやバックエンドサービスのコードをインフラストラクチャ管理なしで実行できます。1 番目の Lambda 関数は、カスタムの Amazon SNS 通知 E メールをユーザーに送信します。Amazon SNS は、通知を簡単に設定、操作、送信できるウェブサービスです。Step Functionsワークフローはここで、2 番目のLambda関数を呼び出す前に10分間の待機状態に入ります。これは、MediaLive チャネルのユーザー定義の入力損失待機時間を 10 分にした前提条件に基づくものです。2 番目の Lambda 関数は、CloudWatch ログをフィルタリングして MediaLive アラートがクリアされたかどうかを確認し、クリアされていない場合には MediaLive チャネルを停止します。 事前準備 以下のサービスへのアクセス許可を持った AWS アカウントが必要です。 AWS Elemental MediaLive AWS Elemental MediaPackage Amazon CloudFront AWS Lambda Amazon CloudWatch AWS Identity and Access Management (AWS IAM) AWS Step Functions Amazon SNS Amazon EventBridge AWS CloudFormation 本記事では、 AWS Media Services を使用してライブストリーミングチャネルを準備する必要があります。 こちらの記事 に従い、フルマネージドの AWS Media Services を使用したエンドツーエンドのライブストリーミングチャネルを作成してください。 ステップ 1: CloudFormation テンプレートをデプロイする AWS Console にサインインする 下の [Launch Stack] ボタンをクリックして、任意のリージョンに CloudFormation テンプレートをデプロイします。 お客様の E メールアドレス を入力してください。これは SNS 通知の宛先になります。 前提条件の手順で作成した MediaLive チャネルの ARN をコピーして、 MediaLive Arn テキストボックスに貼り付けます。 次に、確認ボックスにチェックを入れ、 [Create] をクリックします。 CloudFormation テンプレートは、お客様の AWS アカウントに以下のサービスをデプロイします。 AWS Lambda Amazon CloudWatch AWS Step Functions Amazon SNS Amazon EventBridge ワークフローの流れ まず始めるにあたり、MediaLive チャネルが稼働していて、OBS のソースからコンテンツがストリーミングされている必要があります。 OBS からのストリーミングを停止します。すると、MediaLive チャネルにアラートが発生します。 EventBridge ルールはアラートを監視し、受信イベントのパターンを照合して、イベントまたはペイロードをターゲット（Step Functions や CloudWatch ロググループ）に送信します。 Step Functions のワークフローは、Lambda 関数 2 つおよび待機状態 1 つで構成されています。 ワークフローが 1 番目の Lambda 関数を呼び出すことで、ユーザーに SNS 通知が送信されます。 その後、ワークフローは 10 分間の待機状態に入ります（ユーザー定義の待機時間）。 待機状態の終了後、2 番目の Lambda 関数が呼び出され、CloudWatch ロググループをフィルタリングすることで、MediaLive チャネルによって生成されたアラートがクリアされたかどうかを確認します。クリアされていない場合には、MediaLive チャネルを停止します。 費用に関する免責事項 このワークフローの構築に必要な AWS リソースは 無料利用枠 の対象ではないため、実行中には追加費用が発生します。このワークフローの実行中に使用した AWS サービスの費用は、お客様のご負担となります。リソースの長時間稼働による料金が発生しないように、作業完了後は必ずリソースをクリーンアップしてください。 クリーンアップ 完了後にさらなる料金が発生しないように、AWS Lambda、Amazon SNS、Amazon EventBridge (CloudWatch Events)、MediaLive チャネル、MediaPackage、CloudFront ディストリビューションなど、本ブログ記事に従って作成されたリソースを削除してください。 まとめ MediaLive チャネルを停止させるワークフローを自動化することで、チャネルを手動で監視する負担が軽減されます。自動化されたワークフローにより、以前よりもはるかに迅速にアラートを特定し、エラーを解決することができます。チャネルの分析と停止にかかる時間を短縮することの利点は、企業が、ストリーミング実行中でないチャネルにかかるコストを節約できることです。 エンジニアリングチームは、チャネルを手動で監視して停止させるという繰り返しの多い作業から解放されます。これは、冗長入力がアタッチされているチャネルや Standard パイプラインチャネル、ファイル入力を持つチャネルの分析へと、さらに拡張できます。 AWS は、メディア関連ワークフローの構築を支援するために設計された多数のサービスを提供しています。動画のストリーミング、処理、配信向けに、さらに他のアプリケーションを検討したい場合は、 AWS Media Services をご覧ください。   参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口、SA 金目が担当しました。原文は こちら をご覧ください。

Amazon Timestream は高速でスケーラブルなサーバレスの時系列データベースサービスで、1 日に数兆件のイベントの保存や分析が簡単に実現出来ます。Timestream は自動的にスケールアップ、スケールダウンを行い容量とパフォーマンスを調整する為、基盤となるインフラストラクチャを管理する必要がありません。時系列データの管理に関しては、従来のリレーショナルデータベースでは、大量のタイムスタンプ付きのデータという固有の要件を満たす事が出来ませんでしたが、Timestream は時系列データ専用に設計されたアーキテクチャと、高度な組み込み時系列分析機能を備えており、時系列データの真の可能性を引き出し、意味のある洞察を得る事が出来る理想的なソリューションとなります。 本投稿では Timestream の重要な概念を説明し、それらを使用して重要なデータモデリングの意思決定を行う方法を示します。まず、データモデリングがクエリのパフォーマンスやコスト効率にどう影響するかを説明します。次に、ビデオストリーミングに関するデータをモデリングする実践例を検討し、これらの概念がどう適用されるか、及び、その結果得られる利点を示します。最後にデータモデリングに直接的または間接的に関連するその他のベストプラクティスを説明します。 Timestream の重要な概念 以下に示した Timestream の重要な概念を理解する事は、最適なデータモデリングと効果的な取り込み、クエリ、分析の為に不可欠です。 ディメンジョン – 時系列のメタデータを記述する属性です。例えば、証券取引所をディメンジョンとする場合、ディメンジョン名は証券取引所となり、対応するディメンジョン値は NYSE (ニューヨーク証券取引所) となります。 メジャー – 実際に記録される値を示します。メジャーの一般的な例としては、温度測定値、株価、クリックまたはビデオストリーミングのメトリクス、そして製造装置や、IoT デバイス、自動車に関連したその他のメトリクス等が挙げられます。 メジャー名 (デフォルトのパーティションキー) – measure_name は時系列データポイントに関連付けられた特定の測定値、又は、メトリクスの識別子を示しており、Timestream のテーブル内で様々なタイプのメジャー値を分類、及び区分する方法を提供します。この属性は 顧客定義のパーティションキー が使用されない場合、デフォルトのパーティションキーとして動作します。 顧客定義のパーティションキー – Timestream はこの項目を元に各データをパーティションを区切って分割して配置し、ストレージとクエリパフォーマンスを改善します。カーディナリティが高く、クエリで頻繁に利用される属性を選択する事で、パフォーマンスの最適化を実現できます。多くの場合、ホスト ID、デバイス ID、顧客 ID 等のディメンジョンがパーティションキーとして適切な選択肢となります。 タイムスタンプ – 特定のレコードのメジャーがいつ収集されたのかを示しています。また、Timestream はナノ秒単位のタイムスタンプをサポートしています。例えば、患者のバイタルサインを追跡する為のセンサーデータを収集する場合、UNIX 時間のフォーマットを利用して、このフィールドにデータ収集のタイムスタンプを格納します。 テーブル – 関連する一連の時系列レコードのコンテナです データベース – テーブルの最上位のコンテナです 次の図は、2 つのディメンジョン ( device_id と location ) と、 measure_name 、 time 、そして 2 つのメジャー ( quality と value ) を含む Timestream のテーブルを示しています。 device_id のカーディナリティが高く、クエリのフィルタリングによく利用されると仮定した場合、それを顧客定義のパーティションキーとして選択すると効果的です。 Timestream は柔軟なスキーマレスの構造であり、厳格なスキーマの制約を受ける事は無く、テーブル作成時に列を定義する必要はありません。また、Timestream は時系列データ専用の NoSQL であり、情報をリレーショナルテーブルには保存しませんが、SQL をサポートしています。SQL に精通したユーザは、高度な時系列関数を利用して時刻ベースのデータセットの分析を簡単に実行できます。 最適なデータモデリングはデータ品質の改善、パフォーマンス向上、ストレージコスト削減に役立ちます。Timestream での効果的なデータモデリングはクエリパターンを理解する事から始まり、パフォーマンスとコスト最適化に役立ちます。クエリパターンを理解し、ディメンジョン、メジャー、パーティション化キーを見極める事で、Timestream 内のデータを効率的に構造化出来ます。データモデリングに加えて、クエリに適切なフィルターを使用する事で、クエリを迅速かつコスト効率よく実行出来るようになります。 ビデオストリーミングデータのモデリング ビデオストリーミングアプリケーションのデータモデリングの例を通じて、これらの要素がコストとパフォーマンスにどの程度寄与するのかを見てみましょう。アプリケーションは次のデータを収集していると考えて下さい。 video_id – 各ビデオの一意の識別子 viewer_id – 動画の視聴者を識別する ID device_type – モバイル、Web、スマート TV 等、視聴者がストリーミングに使用するデバイスの種類 region – 視聴者の位置情報 session_id – 各ストリームセッションの一意となる ID start_time – 視聴者がビデオの視聴を開始した時間 playback_duration – 視聴者がビデオの視聴に費やした時間 video_resolution – ビデオの解像度 playback_quality – 720p, 1080p, 4K 等、ビデオ再生の品質 クエリを詳しく説明する前に、ビデオストリーミングアプリケーションが実行する必要がある重要なタスクを明らかにしましょう。まず、特定の動画がどの位の頻度でどの位視聴されているかを確認する事で、コンテンツの人気と視聴者のエンゲージメントを明らかにする事を目的としています。また、ユーザ体験を最適化する為に、優先するデバイスを特定し、顧客の品質の好みを評価する必要があります。さらには、地域毎の傾向を理解する事で戦略を組みなおしたり、個別のセッションの継続時間と維持率を分析する事で視聴者の行動に対する洞察を得る事が出来ます。また、エンゲージメントの高い視聴者を特定し、動画の趣向に関する傾向を見出す事も目的としています。 以下の例を使って、時系列データとクエリについて考えていきましょう。データは test データベース配下の videostreaming テーブルに格納されているとします。 session_id viewer_id device_type region video_id time start_time video_resolution playback_quality playback_duaration session_87 viewer_38 tablet Australia video_148428 2023-05-17 20:54:39.000000000 2023-05-17 20:49:39.000000000 4K Excellent 2820 session_52 viewer_86 computer Australia video_5982 2023-05-17 20:54:31.000000000 2023-05-17 20:49:31.000000000 4K Fair 1020 session_96 viewer_89 smart_tv Australia video_77868 2023-05-17 20:54:30.000000000 2023-05-17 20:49:30.000000000 720p Excellent 2340 session_45 viewer_41 computer Europe video_21191 2023-05-17 20:54:27.000000000 2023-05-17 20:49:27.000000000 720p Excellent 600 session_54 viewer_51 computer US video_115903 2023-05-17 20:54:18.000000000 2023-05-17 20:49:18.000000000 720p Good 420 クエリの例をいくつか見てみましょう。 Query 1 – 次のクエリは region でデータをフィルタリングし、過去 1 日間で米国地域で視聴されたビデオの合計回数をカウントしています (Timestream の ago() 関数 を利用) 。指定された地域でのビデオ消費量の全体像を示します。 SELECT COUNT(*) AS video_count FROM "test"."videostreaming" WHERE time >= ago(1d) AND region = 'US' Query 2 – 次のクエリは device_type に基づいてデータをグループ化し、過去 1 日分の各デバイスタイプ毎のビデオストリーミングセッションの平均時間を計算します。こうする事でデバイス毎に平均時間がどのように変化するか分析出来ます。この情報は様々なデバイスでのユーザの行動や好みを理解し、それに応じてストリーミングサービスを最適化するのに役立ちます。 SELECT "device_type", AVG("playback_duration") AS "avg_duration" FROM "test"."videostreaming" WHERE time >= ago(1d) GROUP BY "device_type" order by "avg_duration" Query 3 – 次のクエリは動画視聴時間に焦点を当て、4K 再生品質で視聴されたビデオの合計時間を算出します。この情報から帯域幅の消費量を把握したり、高品質ビデオコンテンツの需要を評価したりする事が出来ます。 SELECT SUM("playback_duration") AS "total_duration" FROM "test"."videostreaming" WHERE time >= ago(1h) and "video_resolution" = '4K' Query 4 – 次のクエリでは最も長時間視聴されているビデオを特定出来ます。この情報からビデオの品質を向上させたり、より大々的に宣伝したりできます。 SELECT "video_id", AVG("playback_duration") AS "average_playback_duration" FROM "test"."videostreaming" WHERE time >= ago(7d) GROUP BY "video_id" limit 10 Query 5 – 次のクエリで低品質で視聴されているビデオを識別出来ます。 SELECT video_id FROM "test"."videostreaming" where time >= ago(1d) and video_resolution= "720p" Query 6 – 次のクエリは viewer_id に基づいてデータをグループ化し、過去 1 日間に各ユーザが視聴したビデオの合計数を計算します。結果は降順で並べ替えられて合計数が最も多い上位 1,000 名の視聴者を特定出来ます。この情報からパワーユーザを特定したり、視聴者のエンゲージメントを判断する事が出来ます。 SELECT "viewer_id", COUNT(*) AS "video_count" FROM "test"."videostreaming" WHERE time >= ago(1d) GROUP BY "viewer_id" ORDER BY "video_count" DESC LIMIT 1000 Query 7 – 次のクエリは過去 7 日間の各視聴者の平均再生時間を計算し、上位 1,000 名の視聴者を特定します。エンゲージメントが高く、動画の視聴に多くの時間を費やしている視聴者の特定出来る為、パーソナライズされた推奨事項やターゲットを絞った広告に使用できます。 SELECT "viewer_id", AVG("playback_duration") AS "avg_duration" FROM "test"."videostreaming" WHERE time >= ago(7d) GROUP BY "viewer_id" ORDER BY "avg_duration" DESC LIMIT 1000 適切なディメンジョンとメジャーの選択 従来のデータベースから Timestream に移行する場合、既存のデータベースから Timestream にテーブルと列をそのまま移行すれば機能すると考えている方は多いと思います。ですが、本当の課題はクエリパターンを理解した上で、適切なディメンジョン、メジャー、及びオプションでパーティションキーを選択する事にあります。 レコードのタイムスタンプを含むディメンジョンは、各レコードで誰が、何を、いつ、どこで記録したかを特定するのに役立ちます。またディメンジョンはデータを整理・分類し、クエリの一部としてデータをフィルタリングする為に使用されます。ここでは、 video_id 、 viewer_id 、 device_type 、 region 及び session_id は、ビデオストリーミングを整理、分類する為の理想的な選択肢となります。これらの列を利用すると、様々な要素に基づいてデータをフィルター及びグループ化し、様々な観点で分析出来るようになります。例えば、ディメンションを使用して、デバイスの種類ごとに視聴者の趣向を理解したり、地域の視聴パターンを明らかにしたりできます。このようにディメンションを使用すると、データのクエリと分析が柔軟になり、ビデオストリーミング分析のための貴重な洞察が得られます。 メジャーは、データの数学的計算 (合計、平均、変化率の差など) と定量的分析を実行するための基礎を提供します。この例ではメジャーである start_time 、 playback_duration 、 video_resolution 、 playback_quality は、時間の経過とともに変化する視聴者のストリーミング体験に関連する重要な指標をキャプチャします。これらのメトリクスを使用すると、ビデオセッションの平均継続時間、時間の経過に伴うビデオ品質の傾向の追跡、視聴者が好むビデオ解像度の特定など、さまざまな分析を実行できます。こうして、視聴者のストリーミング行動に関する貴重な洞察が得られ、データに基づいた意思決定を行って全体的なエクスペリエンスを向上させることができます。 ただ、ディメンションまたはメジャーの説明のみに頼るだけでは不十分な場合があり、ディメンションがメジャーになる場合もあります。したがって、クエリパターンから考え始めると、何をどの属性に基づいて計算しているのかを理解しやすくなり、メジャーなのかディメンションなのかを判断するのに役立ちます。例えば、属性がデータのフィルタリングや計算にも使用される場合には、それはメジャーになります。また、ディメンションを決定する際は、特定のレコードのディメンションは更新できないこと、およびすべてのディメンションがレコードを一意に識別することを考慮することが重要です。 Timestream は、データを更新/挿入する機能 (upsert) を提供します。 即ち、レコードが存在しない場合はシステムにレコードを挿入し、レコードが存在する場合はレコードを更新する操作です。ただし、更新は、 API 内のすべてのディメンションを使用して、新しいメジャーを追加するか、既存のレコードのメジャーを更新することに限定されます。 ディメンションの数、メジャー (レコードごとの最大メジャー数、テーブル全体の一意のメジャー数)、およびレコードの最大サイズには 制限 がある為、データモデルを設計する際には、これらの要素を考慮する必要があります。多くの場合、Timestream に取り込まれるデータは、時系列分析に必要な属性以外の追加の属性を含むイベントまたはメトリクスを通じて発生します。制限に達しないようにするには、必要な属性のみをターゲットにします。データに関連性がなく、一緒にクエリを実行しない場合は、1 つの統合テーブルよりも個別のテーブルを使用する方が適しています。 パーティションキーの選択 Timestream でパーティション化する場合、パーティションキーを自身で決定するか、 measure_name 列に基づくデフォルトのパーティションを使用するかを選択できますが、カーディナリティの高い列を持ち、クエリの述語として頻繁に使用されるディメンションに基づいてパーティションキーを自身で選択することを推奨します。そうする事で、パーティション間でデータが均等に分散され、パフォーマンスの問題を回避出来ます。このビデオストリーミングの例では、カーディナリティの高い列 ( session_id 、 viewer_id 、 video_id 等) がパーティションキーとして適している可能性があります。ただし、パーティションキーの選択については、どの列がクエリ実行時のフィルタリングに頻繁に使用され、カーディナリティが高いのかを事前にユースケースから検討する必要があります。 場合によっては、データの分散に役立つ属性が無く、顧客定義のパーティションキーを使用できないことがあります。この場合、 measure_name はデータを分割するデフォルトのキーとなります。必ず measure_name 属性の設計を慎重に計画してください。一例として言うと、デバイスから圧力と温度のメトリクスを収集している場合は、次のデータ例に示すように、それら ( pressure と temperature) を measure_name 列に配置します。これはデータを均等に分散するのに役立ちます。 device_id measure_name Time Quality Value sensor-123 temperature 2023-08-01 19:21:32 85 43 sensor-123 temperature 2023-08-01 19:22:32 86 44 sensor-123 pressure 2023-08-01 19:23:32 83 31 sensor-123 pressure 2023-08-01 19:24:32 34 123 各テーブルは、 measure_name 列に対して最大で 8,192 個の個別の値を格納できます。 measure_name 列の最適な値が見つからない場合、または設計段階で制限 (8,192 個の一意の値) を超えることに気づいた場合は、 こちら でさらなる推奨事項を参照してください。 timestamp、measure_name、および少なくとも 1 つのディメンションとメジャーは、Timestream にデータを取り込む際の必須の列です。顧客定義のパーティションキーが使用されている場合でも、measure_name 列は必須であり、テーブルの作成時に レコードのパーティションキーを強制するオプション が無効になっている場合はパーティションキーとして機能します。 コストとパフォーマンスの最適化 Timestream の価格設定 は使用量に基づいており、そのコストの 1 つはクエリ処理中に サーバーレス分散クエリエンジン によってスキャンされるデータ量によって計算されます。新しくタイムスタンプ付きデータが取り込まれると、データは複数のパーティションに分散され、時間、ディメンション、および顧客定義のパーティションキーまたは measure_name によって構成されます。可能な限り、クエリは時間でフィルタリングを行う事をお勧めします (時間は Timestream のディメンジョンです)。これは、クエリエンジンが定義された時間間隔内のデータが配置されたパーティションのみをスキャンする事で、コスト削減とパフォーマンスの向上に直接影響を与えるためです。 さらにクエリ内で可能な場合は、時間フィルターに加えて、顧客定義のパーティションキーまたは measure_name (デフォルトのパーティション分割が使用されている場合) でのフィルターを使用することをお勧めします。これにより、Timestream は無関係なパーティションを効率的に取り除き、特定の時間ウィンドウとパーティションフィルター値のパーティションのみをスキャンすることで、クエリのパフォーマンスを向上させ、コストを削減します。クエリを実行する際、すべてのディメンション (顧客定義のパーティションキーを含む) と measure_name を時間とともにフィルターに使用すると、クエリを最大 30% 高速化できます。 パーティション化キーと時間をフィルターとして使用せずにデータをクエリすると、多数のパーティションがスキャンされることになり、クエリの応答が遅くなり、コストが高くなる可能性があります。Timestream の他のコストの 1 つはストレージです。ディメンション、メジャー、パーティション キーを決定した後は、全体的なコストを節約するために、不要なデータは Timestream に格納しないようにして下さい。 Timestream にデータを保存する ディメンションとメジャーを定義したら、データ モデリングの作業として次に実施するのは、Timestream にデータを保存する方法を検討する事です。データ型は、書き込みとクエリのために Timestream にどのように保存できるかに基づいて選択する必要があります。 アプリケーションが JSON オブジェクトを出力する場合、それらを JSON 文字列に変換し、VARCHAR 型として保存できます。ダウンストリームのコードまたはアプリケーションはこのエンコードを認識し、デコードを適切に処理する必要があることに注意しましょう。ただし、Timestream は時系列データ用に設計されているため、サービスの機能を最大限に活用するには、各データを別々の列として格納することがベスト プラクティスであることに注意してください。 たとえば、自動車用のアプリケーションが、車体番号、測定値 (燃料消費量、速度、経度、緯度)、および時間の属性を持つデータを扱うとします。その場合、アプリケーションはこの JSON データを Timestream テーブルの個別の列に変換する必要があります。 元の JSON データは以下の通りです。 { "car_vin_number": "1234567", "time": "2023-07-20T12:34:56.789Z" "state": "in_motion" "speed": "65" "longitude”: "0.01", "latitude”: "3.02" "fuel_consumption": "80 percent" } Timestream 用に変換されたデータは以下の通りです。 car_vin_number state time fuel_consumption speed longitude latitude 1234567 in_motion 2023-07-20T12:34:56.789Z 80 65 0.01 3.02 データを個別の列に変換することで、Timestream が時系列データを効率的に保存およびクエリできるようになります。各属性は専用の列になり、Timestream が時間ベースのクエリと集計を実行しやすくなります。 シングルメジャー vs マルチメジャー Timestream ではレコードを保存する方法として、 シングルメジャー方式とマルチメジャー方式 があります。 シングルメジャー方式の場合、レコードは 1 つのメジャーしか持ちませんが、マルチメジャー方式の場合、レコードに複数のメジャーを格納する事が出来ます。シングルメジャー方式は、異なる期間で異なるメトリクスをキャプチャする場合、または異なる期間でメトリクスとイベントを発行するカスタム処理ロジックを使用する場合に適しています。しかし、実際には、デバイスまたはアプリケーションは同じタイムスタンプで複数のメトリクスまたはイベントを発行する場合が多いです。 このような場合、同じタイムスタンプで発行されたすべてのメトリクスを同じマルチメジャーレコードに保存する事で、クエリの柔軟性と効率が向上します。多くの場合では、 シングルメジャー方式よりもマルチメジャー方式が推奨 されます。このアプローチにより複数のメジャーの同時取り込みとクエリが可能になり、全体的なコストが削減され、パフォーマンスが向上します。 次のテーブルはシングルメジャーレコードの例です。 device_id measure_name time measure_value::double measure_value::bigint sensor-123 temperature 2022-01-01 08:00:00 25.3 NULL sensor-123 humidity 2022-01-01 08:00:00 NULL 50 sensor-123 pressure 2022-01-01 08:00:00 1014.2 NULL sensor-456 temperature 2022-01-01 08:00:00 23.8 NULL sensor-456 humidity 2022-01-01 08:00:00 NULL 55 sensor-456 pressure 2022-01-01 08:00:00 1013.7 NULL 以下はマルチメジャーレコードの例です。 device_id measure_name time temperature humidity pressure sensor-123 metric 2022-01-01 08:00:00 25.3 50 1014.2 sensor-456 metric 2022-01-01 08:00:00 23.8 55 1013.7 ベストプラクティス Timestream でデータモデリングを行う時には、データ保持ポリシー、暗号化キー、アクセス制御、制限、クエリワークロード、アクセスパターン等がアプリケーションのパフォーマンスとコストにどのような影響を与えるかを考慮することが重要です。 暗号化キーはデータベースレベルで設定されるため、暗号化要件が異なるデータは異なるデータベースに保存する必要があります データ保持ポリシーはテーブルレベルで構成されるため、異なるデータ保持要件を持つデータは別のテーブルに保存する必要があります。 アクセス制御はデータベースおよびテーブルレベルで設定されるため、アクセス要件が異なるデータは異なるテーブルに保存する必要があります。 頻繁にクエリされるデータを同じテーブルに格納することで、クエリの待ち時間を改善しつつ、クエリ作成がやりやすくなります。テーブルが同じ AWS アカウントおよびリージョン内に作成されている場合、Timestream で複数テーブルを結合してクエリ実行することは可能ですが、単一のテーブルをクエリする場合と複数テーブルを結合してクエリする場合とでは、パフォーマンスに顕著な違いが生じる可能性があります。 バッチ書込 と CommonAttributes の利用は、Timestream でのデータ取り込みの最適化とコスト削減の達成に重要な役割を果たします。バッチ書込を使用すると、1 回の API 呼び出しで複数のレコードを効率的に取り込むことができ、リクエスト数が減り、全体的な取り込みパフォーマンスが向上します。このアプローチにより、大量のデータをより効率的に処理して保存し、コストを節約できます。 また、CommonAttributes を使用すると、バッチ書込で共有する属性をまとめて定義できるため、データ転送と取り込みのコストが削減されます。 尚、バッチ書込で利用する WriteRecords API リクエストの最大レコード数は 100 です。 さらに、ここでは詳細の説明は行いませんが、データモデリングの決定に役立つ Timestream に関連する他のいくつかの重要な側面と機能があります。 ストレージ層 – Timestream は、メモリストアと磁気ストアという 2 つのストレージ層を提供します。メモリストアは、高スループットのデータ書き込みと高速なポイントインタイムクエリ向けに最適化されています。磁気ストアは、低スループットの遅延到着データ書き込み、長期データ保存、および高速分析クエリ向けに最適化されています。テーブルの作成時に両方の層の保持ポリシーを構成可能で、テーブル作成後にそれらを変更することもできます。最新のタイムスタンプ付きデータはメモリストアに送信され、設定されたメモリストアの保持期間に基づいて、古いタイムスタンプ付データは磁気ストアに移動されます。 スケジュールドクエリ – スケジュールドクエリを使用すると、ソーステーブルの Timestream データに対して集計、計算、変換を実行し、それを別テーブルにロードするクエリの実行を自動化できます。別テーブルに格納されたデータは既に集計が完了している為、データ量が削減されており、ダッシュボードや視覚化用のデータとして最適です。より詳細な情報は こちら を参照して下さい。 追加のリソース 詳細については以下のリソースを参照して下さい。 Data modeling API reference Using the AWS SDKs Quotas 結論 本ポストでは、Timestream の主要な概念と、データモデリングが重要な理由を説明しました。 Timestream でのビデオストリーミングの例を取り上げ、データモデリングがコストの最適化とパフォーマンスにどのように役立つかを詳しく掘り下げました。 まずは 1 か月の無料トライアル を使って、 Timestream を試して頂ければと思います。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

9月25日週は、AWS ユーザーグループインドネシアと AWS Cloud Day インドネシアをサポートするためにジャカルタに来ています。昨日は、「Innovating Yourself as Early-Stage Developers」のテーマで AWS ユーザーグループインドネシア と Hacktiv8 が共同で開催した コミュニティイベント に参加しました。イベントは大いに盛り上がり、スピーカーや開発者とつながる素晴らしい時間を過ごすことができました。 次は AWS Cloud Day インドネシア が待っています。私は Developer Lounge にいますから、見かけたら声をかけてください。 9月18日週のリリース 9月18日週のリリースのうち、私が注目したいくつかのリリースを以下に記載しました。 AWS CodeArtifact への Swift パッケージの追加 – この記事では、サーバー側で実行する Apple プラットフォーム ( iOS 、 iPadOS 、 macOS 、 tvOS 、 watchOS 、 visionOS 、または Swift ) アプリケーション向けのコードを記述する Swift デベロッパーが AWS CodeArtifact を使用してパッケージの依存関係を安全に保存および取得する方法について Seb が説明しています。私が特に気に入っているのは、デベロッパーが Xcode 、 xcodebuild 、 Swift Package Manager ( swift package コマンド) などの標準デベロッパーツールを引き続き使用して AWS CodeArtifact とやり取りし、開発ワークフローへの統合を推進できる点です。 Apple Silicon M2 Pro Mac Mini コンピューター上に構築された Amazon EC2 M2 Pro Mac インスタンス – Channy が、Amazon EC2 M2 Pro Mac を使用して、メモリを大量に消費するビルドとテストワークロードの実行、CI/CD のモダナイズ、そして市場への製品投入の加速を行う方法について説明しています。Apple のデベロッパーは、EC2 M1 Mac インスタンスと比較して、2 倍の RAM、1.5 倍の CPU コア、2 倍以上の GPU コアを活用して、複数の Xcode シミュレータでより多くのテストを並行して実行できるようになりました。 Amazon CloudWatch Synthetics 用の Synthetics Python ランタイムバージョン 2.0 – Amazon CloudWatch Synthetics では、Canary を作成して顧客エクスペリエンスを継続的に検証し、顧客が気づく前に問題を発見できます。Canary は、エンドポイントと API を監視するためにスケジュールに従って実行される設定可能なスクリプトです。このリリースでは、Synthetics Python ランタイムバージョン syn-python-selenium-2.0 を使用して Canary を作成できるようになりました。 Amazon QuickSight が新しいレイアウトとスパークラインを KPI ビジュアルに追加 – これらの新しいアップデートでは、Amazon Quicksight 上で視覚的な魅力のある KPI を簡単に設計できます。Quicksight では、テンプレート化された KPI レイアウト、スパークラインのサポート、条件付き書式の向上、改良された書式設定ペインなど、ユーザーフレンドリーなエクスペリエンスを実現するための広範な機能強化が導入されています。 Amazon Location Services が追跡とジオフェンシングの価格の最大 75% 引き下げを発表 – Amazon Location Service が追跡とジオフェンシングの 4 つの価格モデルを発表し、オペレーションとビジネスをスケールしてコスト効果の高い方法で実行できるようになりました。請求額は、ジオフェンシングで 20%～70%、追跡で最大 75% 削減される可能性があります。 Amazon Corretto 21 の一般提供開始 – Java デベロッパーに朗報です。長期サポート (LTS) 付きの Amazon Coretto 21 の Linux、Windows、macOS 向けの一般提供が開始されました。 AWS App Runner が自動スケーリング設定管理の向上を発表 – AWS App Runner サービス用の新しい API とパラメータを使用して App Runner サービスを管理し、自動スケーリング設定 (ASC) を定義できるようになりました。例えば、デフォルトの ASC の設定、既存の ASC の更新、ASC リソースを使用しているすべての App Runner サービスの一覧表示を行うことができます。 編集とマスクによる Amazon SNS メッセージデータの保護 – Amazon SNS で個人を特定できる情報 (PII) と保護対象保健情報 (PHI) の特定のタイプを検出して保護できるようになりました。データ保護ポリシーを定義すると、SNS がメッセージをリアルタイムでスキャンして機密データを検出します。 今後予定されている AWS とコミュニティのイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS On Tour – 9 月 18 日～10 月 6 日、 AWS Cloud Day インドネシア – 9 月 26 日 AWS Summit ヨハネスブルグ – 9 月 26 日 CDK Day – 9 月 29 日 そして、仲間のビルダーから学び、AWS Community Day に参加しましょう。 AWS Community Day ジンバブエ (9 月 30 日) AWS Community Day チリ  (9 月 30 日) AWS Community Day ブルガリア  (10 月 7 日) ランディングページにアクセスして、今後開催されるすべての AWS Community Days をチェックしてください。 構築がうまくいきますように。 –  Donnie この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2023 年 9 月 7 日に「 お客様やユーザーの視点を意識したビジネスイノベーションの進め方 」オンラインセミナーを開催しました。このブログでは、当日参加できなかった方や、内容を振り返りたい方へ向けて参考としていただくために当日のセッション内容のまとめを紹介します。 ビジネス変革を目的に、クラウド導入・活用に挑戦する企業がますます増えています。そこで、AWSでは技術的なサポートだけではなく、ビジネスアイデアづくりや変革推進についてもご支援しています。変革の根幹となるのがAmazon自身が新製品や新サービス開発・社内の業務改善の際に実践している「Working Backwards」と呼ばれるメカニズム（フレームワーク）です。エンドユーザーや社内の従業員、お取引先様など、「お客様」と「お客様の課題」を探求し、アイデア創造と洗練化、そして実装や検証まで、Working Backwards一連の流れをご一緒し、ビジネス変革のにつなげています。 本セッションでは、Working Backwardsを活用し、ビジネス変革を推進された事例を、3社のお客様よりご紹介いただきました。業界も、ビジネス構造も、またクラウドへの取り組みも三者三様のみなさまにご登壇いただきましたが、プログラムを実践されたことによってどんな価値を得て、どんな変革につながっていったのか、バラエティに富んだお話をお聞きできました。 AWSのビジネス変革ご支援について アマゾンウェブサービスジャパン合同会社 セグメント事業開発本部 デジタルイノベーション シニアスペシャリスト　櫻井直子 昨今、デジタライゼーション（ペーパーレス化）・デジタライゼーション（IT化）の先にある、新たな価値創出やビジネス変革にデジタルを活用していくデジタルトランスフォーメーション（DX）の必要性が高まっています。一方で何から始めていったらいいのか、技術の手前にあるアイデアの出し方や変革推進の部分での課題を感じられている企業様もたくさんいらっしゃることを、日々の活動の中で実感しております。 そこで、AWSではテクノロジーとしてのクラウド導入のご支援にとどまらず、ビジネス変革のご支援のひとつとして、「デジタルイノベーションプログラム」をご提供しています。Amazon自身が新しいサービスやプロダクトを生み出しているときに使っているフレームワーク・やりかたであるWorking Backwardsを活用しながら、新しいビジネスアイデアを考え、アイデアをAmazonでも使っている文章というフォーマットでかたちにし、そしてその有用性をプロトタイプで検証するところまでを一貫してご支援するプログラムです。 このセッションではデジタルイノベーションプログラムについて、またその中で活用するWorking Backwardsのプロセス（お客様にこだわる5つの質問への回答・社内企画書としてのプレスリリース・FAQ・ビジュアルの作成）についてお伝えしました。   日本最古の私鉄：南海電鉄が挑戦するDXと新しい体験価値創造への取り組みについて 南海電気鉄道株式会社 総務人事グループ DX推進部 課長補佐　尾上 拓也 氏 南海電気鉄道株式会社は2021年ごろよりDXを本格推進されはじめました。コロナ禍において運輸事業の在り方を見直す中で、デジタルを使った新しい価値創出も積極的に進めていく必要性を感じていらしたときに、AWSのデジタルイノベーションプログラムの活用を始めていただきました。 社内の業務改善のDXではなく、南海電鉄のお客様・エンドユーザー様を見据えた新しい価値創造のDXプロセスについては初めての取り組みとのことでしたが、デジタルイノベーションプログラムを活用いただくことによって、スピード感をもってプロセスを完遂いただけました。また、考えたアイデアを机上の空論で終わらせずプロトタイプの実践に移していただいたことで、考えたアイデアが本当に顧客視点で有用性があるのかという仮説検証もされています。素早いプロトタイプ化により、実際のお客様からのフィードバックをアイデアの洗練化につなげていかれました。そして、チームのみなさまも含めて、新しいチャレンジに対して前向きに取り組んでいただく風土もはぐくまれました。 セッション内ではアプリ内のUXや実証実験中のお写真もご紹介いただいています。ぜひ挑戦の詳細をビデオでご確認ください。   顧客志向のマインドを持つ企画人材の育成 ～AWS社サービス開発ソリューションの体現～ 株式会社エナリス 事業企画本部 副本部長 兼 みらい研究所 所長 小林 輝夫 氏 株式会社エナリス みらい研究所 主任研究員 星野 光保 氏 エナリスはエネルギー総合ソリューションを展開されています。経営層のみなさまと、電力を取り巻く昨今のビジネス課題についてAWSと議論させていただく中から、プログラムを開始した事例をご紹介いただきました。顧客視点を徹底したからこそ生まれた、今までとは一味ちがったソリューションの考案に結び付けていただくことができ、プログラム終了後も新人研修にWorking Backwardsのコンセプト加えることで、組織の風土づくりにも活かされています。また、デジタルイノベーションプログラムの中で、実際に考えていただいたアイデアを形作るために活用できるAWSサービスもご紹介したことで、素早くプロトタイプ作りにもつなげていただきました。 AmazonというとConsumerビジネスのイメージが強く、Working Backwardsは法人向けビジネスを考えるうえでどのように役立ちそうかイメージが湧きにくい、というコメントをいただくこともありますが、エナリスの実践事例はその問いへの一つの解と言えます。セッション内では実際に記載いただいたPress Releaseの一部も公開くださっています。ぜひご覧ください。   Working Backwardsで顧客価値の解像度を上げ、新たな顧客体験を実現 株式会社ジンズホールディングス 執行役員 CIO 松田 真一郎 氏 株式会社ジンズ デジタル本部 ITデジタル部 営業基盤G クリエイター 劉 珈彤 氏 ジンズホールディングス・ジンズは積極的にAWSをご導入いただき、日本の中でもかなり早い段階から様々な面でクラウドのテクノロジーをご活用いただいておりました。デジタル戦略として「最高の顧客体験の実現」を掲げ、先進的なお取組みを進める中で、デジタルイノベーションプログラムをご活用いただきました。プログラムを通じて、改めて店舗でのお客様行動の観察からアイデアを着想し、Working Backwardsの特徴でもあるPress ReleaseとFAQという「文章のフォーマット」を使ってアイデアを洗練化することで、チームワークを活かしながら課題解決に向かわれました。また、素早くお客様のニーズを形にするためのAgile開発の体制づくりにもチャレンジいただきました。 プロジェクトの推進体制やアーキテクチャ図もご紹介いただき、テクニカルな視点でも進め方の具体的な参考になる実践事例をご紹介いただきました。アイデアを実践に素早く生かす組織づくりの実践例をぜひご覧ください。   まとめ 本セッションでは日本国内のお取組み事例についてご紹介しましたが、AWSは海外含めて多くのビジネス変革のお取組みにご一緒しています。 AWSを利用したイノベーションのページ ではAmazon自身のイノベーションの取り組み詳細や、さらに多くのお客様のお取組み事例など、ブログや動画でご紹介しています。デジタルイノベーションプログラムに参加し、Working Backwardsを自社でも試してみたいとお感じになられましたら、担当営業までご相談いただくか、 AWSホームページのお問合せフォーム やチャットよりお問い合わせください。御社のビジネス課題に合わせて、どのような形で変革をご支援できそうか、ぜひご相談させていただければと思います。 AWSは、今後もビジネスパートナーとして事業開発やサービス向上のご支援を強化してまいります。新しいお取組みのきっかけに、ぜひデジタルイノベーションプログラムのご活用をご検討ください。

日が暮れるのが早くなってきた今日この頃ですが、コンピューティングとメモリに最適化された 2 つの新しい EC2 インスタンスタイプと、他のサービス向けの多くの新機能が導入されました。9月11日週、ミュンヘンで EMEA AWS Heroes Summit も開催され、インサイトと情熱に満ちた素晴らしい一日になりました。参加者の素敵な写真をご覧ください。 9月11日週のリリース 9月11日週のリリースのうち、私が注目したいくつかのリリースを以下ご紹介します。 C7i インスタンス – カスタムの第 4 世代 Intel Xeon Scalable プロセッサー (コードネーム Sapphire Rapids) を搭載し、AWS でのみ利用できるこれらのコンピューティング最適化インスタンスは、他のクラウドプロバイダーが使用している同等の x86 ベースの Intel プロセッサーよりもパフォーマンスが最大 15% 向上します。C7i インスタンスは、バッチ処理、分散分析、ハイパフォーマンスコンピューティング (HPC)、広告配信、拡張性の高いマルチプレイヤーゲーム、ビデオエンコーディングなど、あらゆる計算集約型ワークロードに最適な選択肢で、C6i インスタンスと比較して最大 15% 高い料金パフォーマンスを実現します。 vCPU メモリ (GiB) ネットワーク帯域幅 EBS 帯域幅 c7i.large 2 4 最大 12.5 Gbps 最大 10 Gbps c7i.xlarge 4 8 最大 12.5 Gbps 最大 10 Gbps c7i.2xlarge 8 16 最大 12.5 Gbps 最大 10 Gbps c7i.4xlarge 16 32 最大 12.5 Gbps 最大 10 Gbps c7i.8xlarge 32 64 12.5 Gbps 10 Gbps c7i.12xlarge 48 96 18.75 Gbps 15 Gbps c7i.16xlarge 64 128 25 Gbps 20 Gbps c7i.24xlarge 96 192 37.5 Gbps 30 Gbps c7i.48xlarge 192 384 50 Gbps 40 Gbps c7i.metal-24xl* 96 192 37.5 Gbps 30 Gbps c7i.metal-48xl* 192 384 50 Gbps 40 Gbps *ベアメタルインスタンスは近日公開予定です。 データ操作の効率的なオフロードと高速化を促進し、ワークロードのパフォーマンスを最適化するために、C7i インスタンスは、Data Streaming Accelerator (DSA)、In-Memory Analytics Accelerator (IAA)、QuickAssist Technology (QAT) などの組み込み Intel アクセラレーターと、CPU ベースの ML などのアプリケーションの行列乗算演算を高速化する新しい Intel Advanced Matrix Extensions (AMX) をサポートしています。 EC2 R7a インスタンス – 最大周波数が 3.7 GHz の第4世代 AMD EPYC プロセッサー (コードネーム Genoa) を搭載したこれらのメモリ最適化インスタンスは、R6a インスタンスと比較して最大 50% 高いパフォーマンスを実現し、SQL や NoSQL データベース、分散型ウェブスケールのインメモリキャッシュ、インメモリデータベース、リアルタイムのビッグデータ分析、Electronic Design Automation (EDA) アプリケーションなどの高性能でメモリ集約型ワークロードに最適です。 詳細については、Channy のブログ記事をご覧ください 。 Amazon Bedrock のナレッジベース (プレビュー) – より関連性が高く状況に応じた応答を行うために、Bedrock は取り込みワークフローとランタイムオーケストレーションの両方を管理して、組織のプライベートデータソースを基盤モデル (FM) に接続し、生成系 AI アプリケーションの検索拡張生成 (RAG) を有効にできるようになりました。データを保存するには、Amazon OpenSearch Serverless 用ベクトルエンジン、Pinecone、Redis Enterprise Cloud など、さまざまなベクトルデータベースから選択できます。 詳細については、Antje のブログ記事をご覧ください 。 Amazon OpenSearch Serverless による高いクエリレートにより自動スケーリングが拡大 – OpenSearch Serverless を利用することで、検索とクエリのトラフィックの予測不可能な急増を管理し、1 分あたり何万ものクエリトランザクションを効率的に処理できるようになりました。 Amazon EMR on EKS – EMR を使用して他のアプリケーションと同じ Amazon EKS クラスターで Apache Flink (パブリックプレビュー) を実行することで 、リソース使用率を向上させ、インフラストラクチャ管理を簡素化できるようになりました。また、カーネル、ツールチェーン、glibc、openssl などの最新の拡張機能を備えた、安全で安定した高性能環境を実現するために、 Amazon Linux 2023 をオペレーティングシステムとして使用し 、また Java 17 を Java ランタイムとして使って、Amazon EMR on EKS を使用してワークロードを実行できるようになりました。 Amazon Connect – Amazon Connect Cases では、 ケースへの添付ファイルのアップロード がサポートされるようになりました。これにより、エージェントはケースの解決に必要な情報をすぐに利用できるようになりました。また、ケースに書かれた コメントには作成者名が表示されるため 、ケースの解決に貢献したユーザーをより簡単に追跡し、より効果的に共同作業を行うことができます。コンタクトセンターで連絡 (音声通話、チャット、タスク）イベント (例えば、通話がキューに入っているなど) のストリームをほぼリアルタイムで受信するために、 新しい連絡データ更新イベントに登録 できるようになりました。 AWS Chatbot 用のカスタム通知 – これにより、Microsoft Teams や Slack チャネルで AWS アプリケーションの状態やパフォーマンスをモニタリングする際に、注文数や現在のスロットリング制限などの追加情報を含めることができます。 AWS IAM アイデンティティセンターのセッション期間が最大 90 日間に延長 – セキュリティコンテキストと希望するエンドユーザーエクスペリエンスに基づいて、より柔軟に対応できるようになりました。以前は、最大 7 日間でした。デフォルトのセッション時間は引き続き 8 時間で、お客様が設定した既存のセッション制限は変更されません。 Amplify Studio での GraphQL API の完全サポート – Amplify Studio または Amplify CLI で作成された GraphQL API 向けに、API に接続されたフォームを生成したり、API 中のレコードを Data Manager で管理したり、データバインドされた Figma to React コンポーネントを作成したりできるようになりました。以前は、これらのデータ駆動機能は Amplify DataStore を使用した場合にのみ利用できました。 AWS AppSync WebSockets ベースのサブスクリプション向けのネストされたフィルタリング – 公開されたデータ内の特定のサブ項目を対象とするフィルタリングルールを使って、接続されたクライアントにデータを公開する方法を詳細に制御できるようになりました。 このブログ記事 で詳細をお読みください。 API Gateway コンソールの更新 – REST と WebSocket API ワークフローの使いやすさが向上し (HTTP API のコンソールエクスペリエンスと視覚的に連携するようになりました)、ダークモードがサポートされるようになりました。アクセシビリティの強化は、支援技術との統合にも役立ちます。 AWS Supply Chain の上書き保存機能 – 需要プランナーが手動で行った予測調整は、自動的に保存され、ある計画サイクルから次の計画サイクルに再適用されるようになりました。 AWS のその他のニュース AWS でのサーバーレス開発 – AWS ヒーローの Sheen Brisals と彼の同僚である Luke Hedger は、AWS でエンタープライズ規模のサーバーレスソリューションを構築するのに役立つ本で専門知識を共有しています。この本では、人材、考え方、ワークロードの観点から採用要件の概要を説明し、サーバーレスアプリケーションを構築するためのアーキテクチャパターン、セキュリティ、データのベストプラクティスを詳しく説明しています。 AWS ブログからのその他の記事 – 私がフォローしている他の AWS ブログやクラウドブログからの投稿です。 AWS コンテナブログ – Django アプリケーションを AWS App Runner にデプロイしてスケーリングしましょう 。 AWS アーキテクチャブログ – アーキテクトしよう! インメモリデータベースの活用 。 AWS 機械学習ブログ – AWS SageMaker JumpStart Foundation Model を使用して、ツールを用いた LLM エージェントを構築およびデプロイする方法を説明します 。 AWS 機械学習ブログ – 検索拡張世代生成と LangChain エージェントを使用して内部情報へのアクセスを簡素化します 。 AWS for Games ブログ – コンテンツ管理サービスとグラフデータベースおよび分析を組み合わせて、コミュニティの有害性を軽減しましょう 。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS On Tour、9 月 18 日～10 月 6 日 – AWS デベロッパー関係チームは バスに乗り込み、欧州の都市 (ロンドン、パリ、ブリュッセル、アムステルダム、フランクフルト、チューリッヒ、ミラノ、リヨン、バルセロナ) を巡り 、経験を共有し、生産性の向上を支援します。 AWS グローバルサミット、9 月 26 日 – 今年最後の対面式 AWS Summit が 9 月 26 日に ヨハネスブルグ で開催されます。 CDK Day、9 月 29 日 – CDK と関連プロジェクトに関するコミュニティ主導の完全バーチャルのイベント (英語とスペイン語) に関する ウェブサイトで詳細をご覧ください 。 AWS re:Invent、11 月 27 日～12 月 1 日 – 自身の re:Invent の計画を始めるには、 セッションカタログ を閲覧するのが良い方法です。ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 AWS Community Day – オランダ (9 月 20 日)、 スペイン (9 月 23 日)、ジンバブエ (9 月 30 日)、 ペルー (9 月 30 日)、 チリ (9 月 30 日)、 ブルガリア (10 月 7 日) など、お住まいのリージョンの AWS ユーザーグループリーダーが主催するコミュニティ主導の会議に参加しましょう。ランディングページにアクセスして、今後開催されるすべての AWS Community Day をチェックしてください。 今後予定されている AWS 主導の対面イベント、仮想イベント や AWS DevDay などの デベロッパー向けイベント をすべて閲覧できます。 — Danilo この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

DynamoDB Specialist Solutions Architectの成田と申します。 前回、表題のイベントについて イベントの告知ブログ を公開させて頂きました。 本投稿ではイベントの風景や各スピーカーの資料を皆様にシェアさせて頂きます。当日参加したが見逃してしまった、などに是非お役立て下さい。 なお、一部スライドは今回の公開用に変更・修正をしている可能性があることを承知下さい。発表者のスライドは各speaker画像下のリンクから参照下さい。（サイトの仕様上、スライドを直接表示が出来ないため宜しくお願いします） AWSにおけるマイクロサービスとNoSQLの活用- 福井 厚 Understanding & Using Amazon DynamoDB – Alex DeBrie Amazon DynamoDB Deep Dive at AWS Loft Tokyo 2023/9/28 各セッションは途中で質問が出るなどAmazon DynamoDBの特性やどう有効利用するかでとても白熱した議論が出来たと思います！ もし、今後もDatabase/NoSQL/Analytics関連でのイベント開催、特にAmazon DynamoDBを始めとしたNoSQLサービスについてより初学者向け、よりエキスパート向け、ハンズオンを利用したワークショップを希望されている方は是非ハッシュタグ #DynamoDB をつけてX(Twitter)で本ブログの感想などをお寄せください！ 本ブログ著者 : 成田 俊は、Principal DynamoDB Solutions Architectです。Amazon DynamoDB を使用する多くの AWS のお客様にアーキテクチャのレビューや技術支援を行っています。

みなさんこんにちは。ソリューションアーキテクトの眞壽田（ますた）です。7/28にAWSが主催する自動車業界向けイベント「AWS Autotech Forum 2023」を開催しました。AWS Japanでは、自動車業界の皆様にクラウドを活用してビジネスを加速して頂くことを目指し、 2018 年より事例や最新技術の活用方法等をご紹介する本イベント「 AWS Autotech Forum」 を開催して参りました。今回で6回目となる本イベントも昨年同様オンライン開催となりましたが、1000名近くの多くの方にご登録頂きました。CASEによる変革が自動車業界で起動に乗った今、CASEという言葉が生まれた当初の想定通り、世の中で自動車に対する価値が変わってきていることを私自身も実感しています。今年の本イベントでは、自動車の新しい価値を第一線で創造しているお客様を代表して、ソニー・ホンダモビリティ株式会社様、TIER IV, Inc.様、KINTOテクノロジーズ株式会社様にご登壇頂きました。 オープニング – 竹川 寿也　アマゾン ウェブ サービス ジャパン 合同会社 事業開発本部 シニア事業開発マネージャー オープニングでは、これまでAuto Tech Forumのあゆみをお伝えすると共に、AWS for Automotiveという自動車業界のお客様を支援するチームの取り組みやご支援内容をご紹介し、自動車業界の皆様にAWSがどのように貢献できるかということをご説明しました。 ソニー・ホンダモビリティが目指す新たなモビリティの価値 – 川西 泉 様　ソニー・ホンダモビリティ株式会社　代表取締役 社長 兼 COO セッションでは、ソニーホンダモビリティの設立の経緯から、車両がユーザーに提供する新たな価値と、それを実現するための車両開発のアプローチについてお話頂きました。AFEELAが、ユーザーに提供する新たな価値とは、ユーザーに感動を与える空間を提供することであり、移動の価値を継続的に進化させていくことである。その継続的な進化は、量産後も継続的に車載ソフトウエアをアップデートすることで実現し、それを実現するには車両アーキテクチャーがSoftware-Definedでなければならない。そしてSoftware-Definedな車を実現するには車の演算能力も高くあるべき、ということから、業界内で話題となっている車載のSoCを選定した経緯もお話頂きました。 以下、所感になりますが、AFEELAは AIBO と同様に、車両（IoTデバイス）、スマホ、クラウドがそれぞれ接続し、様々なサービスと連携することを想定しており、その中でAWSクラウドが果たす役割は非常に大きいと感じました。自動車業界一般的にも言えることですが、この領域に関してAWSクラウドの役割を具体的に列挙すると次のようになります。認証、データアップロード、データ解析、OTA、パーソナライズ、ADAS機能開発、車両ソフトウエア開発。 IoTデバイスの認証においては、 AWS IoT Core を使用するユーザー事例が一般的になりつつあり、ソニー様においてもAIBOの認証機能でAWS IoT Coreが採用されています。データアップロードにおいては、認証と同様にAWS IoT Coreを使用するケースや、AIBOの事例では、 AWS AppSync を利用し、デバイスとAWSクラウド間、スマホアプリとAWSクラウド間をGraphQLで情報同期をする方法が採用されています。パーソナライズやADAS機能開発で Amazon SageMaker などの機械学習サービスを利用するケースも一般的になりつつありますが、新しい自動車業界の潮流として、車載ソフトウエアの開発を可能な限りAWSクラウド上で行い、V字の開発プロセスにおいてShift-Leftを目指す 事例 が、海外の自動車メーカー様でも増えてきています。 自動運転の事業化を加速するWeb.Auto – 関谷 英爾 様　TIER IV, Inc. Architect セッションでは、自動運転の潮流や、Autowareという自動運転のソフトウエアをオープンソースとして提供するTIER IV様のビジネスの方式や、各プロダクトの実際の開発・アーキテクチャー、運用の効率化についてお話頂きました。 TIER IV様のビジネスは、Autowareを実際のプロダクションフェーズで利用するために必要な関連プロダクトを提供することであり、大きく３つのプロダクトをご紹介頂きました。自動運転ソフトウエアの開発環境を提供するWeb.Auto、主に狭域自動運転などのMaaSで利用される自動運転用のプラットフォームであるPilot.Auto、自動運転で必要となる車載センサーデバイスであるEdge.Autoの３つです。本セッションでご紹介頂いたWeb.AutoとPilot.Autoは、非常に完成度が高い印象を受けました。また、ご紹介頂いたアーキテクチャーも大変参考になる情報が多く、個人的に感銘を受けたのはパスプランニングの経路探索で利用するGraphデータベースに Amazon Neptune を採用している点でした。ベクターマップから抽出した道路リンクをGraphデータベースとして表現する際、プログラム上でメモリ管理することは比較的容易なのですが、その機能をクラスタ化することは過去の私の体験談で苦労した経験があったためです。一方で、MLOpS、DevOpSに関してもアーキテクチャーを詳細にご紹介頂いており、シミュレーション機能を複数のコンピューティングリソースでクラスタ化させて動作させる際、そのノードを自動でProvisioning、Deprovisioningする仕組みを AWS Step Functions と Amazon EKS で実現している点、AD/ADASの機能を開発する開発者様にも参考になる事例ではないかと思いました。 セッションの後半では、Web.Autoが、 AWS Foundational Technical Review (FTR) の承認を受けたことをご紹介頂きました。FTRは、AWS Well-Architected Framework で定義されたガイドラインでシステムが設計されていることをAWSがレビューする評価サービスで、Web.Autoはその承認を受けたことで、第三者に品質をアピールすることができているとその効果をご紹介を頂きました。FTRは、潜在顧客に対してAWSを使ったプロダクトを販売する際、セキュリティ、信頼性、運用に関するリスクを低減していることを客観的にアピールできる仕組みということで、多くのパートナー企業様にもご利用いただいています。 まだまだ語りきれない情報含め、有益な情報を多くご提供頂いた関谷様のセッションは、次のリンクからご視聴頂くことができます。 資料ダウンロード（自動運転の事業化を加速するWeb.Auto） カーナビのクラウド化と固まっていた常識を変えるプロダクト開発 – 中西 葵 様　KINTOテクノロジーズ株式会社　開発・編成本部 プラットフォーム開発部 共通サービス開発グループ プリンシパル エンジニア セッションでは、ソフトウエアの技術を使ってお客様に迅速にサービスを提供するために生まれたKINTOテクノロジーズ様と、トヨタ自動車様との関係性や組織構造のご紹介、KINTOテクノロジーズ様が手掛けるKINTOの様々なサービスについてご紹介頂きました。今までKINTOイコール車のサブスクリプションサービスという認識でおりましたが、それだけではなく、多くの興味深いサービスをお客様に提供していることが中西様のセッションから実感できました。 中でも一番驚いたのが、KINTO FACTORYでした。現在の自動車業界のSoftware-Defined Vehicleは、車両の量産開始までにハードウエアを決定し、ソフトウエアは後から更新することを想定していますが、後から更新されるソフトウエアで提供できるサービスは、量産開始前に決められたハードウエアで制限が掛けられてしまうという潜在的な課題があるように思います。KINTO FACTORYはその課題をポジティブに解決できうるサービスで、ハードウエアは車両購入時に決める必要はなく、後から必要に応じて追加することを可能とするようです。これはKINTO様の所有から使用へを推進するビジネスを大きく拡張することができるサービスではないかと思いました。 また、OTAでアップデートするソフトウエアについて、個人の運転志向に基づいてパーソナライズされた機能を提供することができると紹介頂きました。パーソナライズを実現する要となるのはデータであり、自動車や販売店から収集したデータを効率的に処理するアーキテクチャーとして、FrontendやBackendで、Elastic Load Balancingと Amazon ECS の組み合わせて処理を実行する構成や、バッチジョブで Amazon EventBridge とAmazon ECSを連携させる構成をご紹介頂きました。 セッションの後半では、技術選定とエンジニア採用について興味深いお話をして頂きました。JavaやSpring Bootのような（流布されている）技術を指定して、一定のエンジニアを獲得することは比較的容易である。一方で、先進的なサービスを構築するために特殊なこと実行しようとすると、チームを組織することは難しくなる。そのために、臨機応変な技術選定をすることは会社の成長のためにとても重要であるとお話頂きました。 まだまだご紹介できていないサービスの詳細含め、有益な情報を多くご提供頂いた中西様のセッションは、次のリンクからご視聴頂くことができます。 資料ダウンロード（カーナビのクラウド化と固まっていた常識を変えるプロダクト開発） パネルディスカッション – 関谷 英爾 様　TIER IV, Inc. Architect – 中西 葵 様　KINTOテクノロジーズ株式会社　開発・編成本部 プラットフォーム開発部 共通サービス開発グループ プリンシパル エンジニア – 三浦 直樹 様　KINTOテクノロジーズ株式会社 開発・編成本部 プロジェクト開発部 プロジェクト推進G プリンシパル プロダクトマネージャ – 竹川 寿也、アマゾン ウェブ サービス ジャパン 合同会社　事業開発本部 シニア事業開発マネージャー パネルディスカッションでは、新たにKINTOテクノロジーズ様の三浦様にご参加頂き、「次世代に向けた変革」についての課題と解決方法ついてのトピックでお話し頂きました。新たな価値を創造している２社様ですが、自動運転という世の中になかった新しい技術を開発しているテックベンチャーのTIER IV様と、トヨタグループの中で車のサブスクビジネスを提供されるKINTOテクノロジーズ様、両社の課題はそれぞれ異なり、ディスカションでは大変興味深いやりとりがありました。また、最後のトピックでは「AWSの良い点、もう少し頑張ってもらいたい点」について、パネリスト様から貴重なご意見を賜りました。パネルディスカッションの詳細は下記の動画でご視聴頂くことができます。 パネルディスカッション | AWS Auto Tech Forum 2023 おわりに 6年目となる今回の AWS Autotech Forum は、長い歴史を持つ自動車業界の中では比較的新しい企業様にご登壇頂き、新たなコンセプトやサービス、先進事例をご紹介頂き、視聴者の皆様からも多くの反響を頂けたことを、主催者の一人として大変嬉しく思います。一方で、現在の自動車業界は、CASEの対応で増大化したソフトウエアを、Software-Definedな車載アーキテクチャーへの変化を推進することで、その増大化を抑えようとしています。そのプロセスには様々な課題があります。その課題を解決するために、AWSとしてお客様を支援できること、AWSパートナー企業様と協調することで支援が可能になることなど様々ございますが、次のイベントではそのSoftware-Defined Vehicleを推進する車載ソフトウエア開発の取り組みをご紹介できるよう、自動車業界のお客様を支援するソリューションアーキテクトとして、日々お客様と帆走していきたいと思います。 今後も先進的な取り組みを発信されたいお客様にイベント登壇頂き、自動車業界の皆様への参考としていただけるように本イベント活動も続けて参ります。 過去のイベント – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 眞壽田 英輝 (Masuta, Hideki) アマゾン ウェブ サービス ジャパン 合同会社 Mobility領域のお客様を支援するソリューションアーキテクト。好きなAWSサービスはAmazon Managed Streaming for Apache Kafka (MSK)です。

みなさんこんにちは！ アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトのウジンです。 2023 年 9 月 6 日に「アップデート紹介とちょっぴり DiveDeep する AWS の時間 – AWS re:Inforce デモ祭り」をオンラインで開催しました。本イベントは、AWS の数あるアップデートの中から「すぐ使える、運用に役立つ、あったらいいなと思ってた、おもしろい、重要」なものをピックアップし、ちょっぴり DiveDeep してカジュアルな雰囲気でお伝えするイベントです。 今回は、毎月開催している「ちょっぴりDD」の特別回で、6月に開催された クラウドセキュリティ、コンプライアンスに特化したカンファレンスである「AWS re:Inforce」で発表された新サービス、新機能の内容についてデモ中心でご紹介いただきました。 今回も非常に多くの方にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました。 実施内容 AWS のメンバーから Amazon Verified Permissions サービス、Amazon CodeGuru Security 機能、EC2 Instance Connect Endpoint 機能、Amazon Inspector SBOM Export 機能を紹介するセッションをお届けしました。 記事の中に資料や動画のリンクがありますので、見逃してしまった方はそちらから御覧ください。 アジェンダ ついにGA！ Amazon Verified Permissions でアプリケーションの認可をシンプルに！（15分） スピーカー:アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 柴田 龍平 re:Invent 2022 にて発表された Amazon Verified Permissions が東京を含むほとんどのリージョンで一般利用開始となりました。従来、コードでの管理だと複雑になる一方だった分散アプリケーションの機能が追加される際のアクセス制御なども、Amazon Verified Permissions でポリシーを管理することでシンプルに監査可能な形で実現できます。本セッションでは Amazon Cognito との統合など、GAと共に発表された新たな機能をご紹介し、アプリケーションに統合する方法を Demo を交えつつご紹介します。 Amazon CodeGuru Security の紹介（15分） スピーカー:アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 江口 昌宏 Amazon CodeGuru Security は、機械学習を使用してコードの脆弱性を特定し、修復の手助けとなるような静的アプリケーション・セキュリティテスト（SAST）ツールです。この機能がプレビューリリースとなりました。開発ワークフローのさまざまな段階（コード・リポジトリ、CI/CD パイプライン、コンテナ・レジストリなど）で統合できるように設計されています。本セッションでは、これらの機能をご紹介いたします。 踏み台サーバーなしでプライベートサブネットのインスタンスに SSH？EC2 Instance Connect Endpoint を試してみる！（15分） スピーカー:アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 山崎 宏紀 EC2 Instance Connect Endpoint (EIC Endpoint) が利用可能になりました！EIC Endpoint を使うと、パブリック IP アドレスを使用せずに EC2 インスタンスへ SSH と RDP で接続できます。EIC Endpoint があれば踏み台サーバーが不要となり、パッチ適用、管理、監査など運用上のオーバーヘッドやインスタンスの維持費用を削減できます。本セッションでは新機能の使い方についてデモを交えてご紹介します。 Amazon Inspector SBOM Export ではじめるソフトウェアサプライチェーンセキュリティ（15分） スピーカー:アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 Amazon Inspector の新機能である「SBOM Export」が発表されました。昨今、増大するソフトウェアサプライチェーンセキュリティリスクに対処するため、SBOM の活用が注目されています。本セッションでは、SBOM の概要や「SBOM Export」機能について、デモを交えつつご紹介します。 当日の様子 当日の内容を抜粋してご紹介します。 ついにGA！ Amazon Verified Permissions でアプリケーションの認可をシンプルに！ [ 資料 、 動画 ] 最初のセッションは、ソリューションアーキテクトの柴田より、6月に一般公開となった Amazon Verified Permissions について、デモを交えながらご紹介しました。Verified Permissions は、アクセス制御用のオープンソース言語である Cedar を使用しているため、アクセス許可をわかりやすいポリシーとして定義できます。Cedar では、ロールベースおよび属性ベースのアクセス制御をサポートしており、Verified Permissions を利用することで、アプリケーション上でこれらの制御をシンプルに実現できます。 このセッションのデモでは、アプリケーションの認可処理を Verified Permissions を活用し実装しました。 アプリケーションコード内に認可処理が実装され拡張性に課題を抱えている方、これから認可処理を導入しようと考えている方はぜひご覧いただければ幸いです。 Amazon CodeGuru Security の紹介 [ 資料 、 動画 ] 2 つ目のセッションでは、ソリューションアーキテクトの江口より、6月にプレビューリリースとなった Amazon CodeGuru Security について、デモを交えてご紹介しました。Amazon CodeGuru Securityは、機械学習を活用してコードの脆弱性を特定し、修正の手助けをする静的アプリケーションセキュリティ検査（SAST）ツールです。 このセッションでは、CodeGuru Security をビルドプロセスに統合し、アプリケーションの脆弱性を検出する方法をデモで実演しました。デモの中では、サンプルコードに潜んでいる SQL インジェクションの脆弱性を検知し、その結果と修正ガイダンスを CodeGuru Security のダッシュボードで視覚的に確認することができました。 アプリケーション開発におけるセキュリティをより高めたい方にはぜひ御覧いただきたい内容です。 踏み台サーバーなしでプライベートサブネットのインスタンスに SSH？EC2 Instance Connect Endpoint を試してみる！ [ 資料 、 動画 ] ３つ目のセッションでは、ソリューションアーキテクトの山崎より、EC2 Instance Connect(EIC) という新機能をデモを交えてご紹介しました。以前は、プライベート Subnet にある EC2 インスタンスに接続するためには踏み台ホストを用意する必要がありましたが、EIC Endpoint を活用すれば踏み台サーバが不要となり、踏み台の維持にかかるコストや運用上の手間を削減できると同時にインスタンスにパブリック IPv4 アドレスがなくても、SSH または RDP 経由でインスタンスに接続でき、セキュリティも強化できます。EC2 インスタンスを運用している方にはぜひ参考にしていただきたい内容です。 Amazon Inspector SBOM Export ではじめるソフトウェアサプライチェーンセキュリティ [ 資料 、 動画 ] 最後のセッションは、ソリューションアーキテクトの後藤より、 Amazon Inspector の新機能、SBOM Export 機能をご紹介しました。Amazon Inspector では、組織全体の Amazon Inspector が監視しているすべてのリソースの統合ソフトウェア部品表 (SBOM) を、CyclonedX や SPDX などの業界標準の形式でエクスポートできるようになりました。この新機能により、自動化および一元管理された SBOM を使用して、ソフトウェアサプライチェーンに関する重要な情報を可視化できます。 本セッションでは、Amazon Inspector からサンプルソースの SBOM を S3 に出力し、Athena でその結果を検索する流れをデモを交えてご紹介しました。更なるセキュリティ強化を考えている方はぜひご覧いただければと思います。 次回予告 次回は「 Container 」編です。 ゲストスピーカーとして、株式会社ラクスの下西 氏、freee 株式会社の藤原 氏をお招きしましてコンテナ運用ノウハウKubernetes ネイティブのワークフローエンジンである Argo Workflows を Amazon EKS Cluster に導入する方法などに DiveDeep してお伝えします。 次回も多くの方々のご参加を心よりお待ちしております！ 2023 年 4 月以降に開催予定の『アップデート紹介とちょっぴり DiveDeep する AWS の時間』の視聴申し込みを一括でできるようになりました！毎月申し込みする必要はなくなります。また、イベント開催直前にリマインドメールをお送りいたします。下記リンクから参加ご希望月の申し込みをお願いいたします。 第三十四回「アップデート紹介とちょっぴり DiveDeep する AWS の時間」- Container 編- 開催日時：2023 年 9 月 28 日（木）16:00 – 17:30 オンライン開催 アジェンダ 16:00 – 16:10 オープニングセッション 16:10 – 16:25 AWS 上でコンテナを爆速起動する方法をまとめてみた スピーカー： アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 祖父江 宏祐 16:25 – 16:40 AWS でメール配信システムを構築！ Amazon ECS on AWS Fargate で楽楽運用 スピーカー： 株式会社ラクス インフラ開発部 東京インフラ開発2課 アシスタントマネージャー 下西 章王 氏 16:40 – 16:45 Q&A 16:45 – 17:00 Amazon EKS と Argo Workflows で実現するタスク実行と AWS リソースとの連携方法 スピーカー： freee 株式会社 SRE / Developer Experience エンジニア 藤原 彰人 氏 17:00 – 17:15 Amazon EKS と KubeVela でプラットフォームエンジニアリングに入門しよう！ スピーカー： アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 17:15 – 17:20 Q&A 17:20 – 17:30 クロージングセッション このブログの著者 鄭 宇鎭 ( Jung Woojin ) ソリューションアーキテクトとして ISV/SaaS 系のお客様の技術支援を行っております。好きなサービスは Amazon API Gateway とAmazon ECS です。趣味は子供と落書きをすることです。

本日、Amazon Bedrockが一般提供を開始したことをお知らせします。また、MetaのLlama 2 13B および 70B パラメータのモデルが、近日中に Amazon Bedrock で利用可能になることもお伝えします。 今年の4月、 AWS で生成系 AI を構築 するための新しいツールセットの一部として Amazon Bedrock を発表しました。Amazon Bedrockは、 AI21 Labs 、 Anthropic 、 Cohere 、 Stability AI 、 Amazon などの先進的な AI 企業の高性能な基盤モデル (Foundation Models) を選択できるフルマネージドサービスです。プライバシーとセキュリティを維持しながら、生成系 AI アプリケーションの開発を簡素化する幅広い機能群を提供します。 Amazon Bedrockの包括的な機能により、さまざまなトップレベルの基盤モデルをサーバーレスで試すことができ、ファインチューニングや検索拡張生成 (Retrieval-Augmented Generation; RAG) などの技術を用いて、プライベートな環境で独自のデータを活用して基盤モデルをカスタマイズし、コードを書くことなく複雑な業務タスクを遂行するマネージドなエージェントを作成できます。 以前の投稿をチェックして、これらの技術を利用するための Agents for Amazon Bedrock や  Knowledge Base についてさらに学ぶことができます。Agents for Amazon Bedrock や Knowledge Base を含む一部の機能は、引き続きプレビューでのみ利用可能であることに注意してください。このブログ記事の後半で、どの機能がプレビューで利用できるか詳細を共有します。 Amazon Bedrock はサーバレスなので、インフラを管理する必要がなく、すでに使い慣れている AWS サービスと連携して生成系　AI の機能をセキュアに統合およびデプロイできます。 Amazon Bedrock は Amazon CloudWatch および AWS CloudTrail と統合されており、モニタリングとガバナンスのニーズに対応しています。CloudWatch を使用して使用状況に関するメトリクスを追跡し、監査目的で独自のダッシュボードを構築できます。CloudTrail を使用すると、他のシステムを生成系 AI アプリケーションに統合する際に API 操作を監視し、トラブルシューティングをすることができます。 Amazon Bedrock を使用すると、 GDPR に準拠したアプリケーションを構築でき、 HIPAA (医療保険の相互運用性と説明責任に関する法律) で規制されるセンシティブなワークロードを実行できます。 Amazon Bedrock の利用を開始する Amazon Bedrock で利用可能な基盤モデルは AWS マネジメントコンソール や、 AWS SDK 、 LangChain などのオープンソースフレームワークを通じてアクセスできます。 Amazon Bedrock のコンソール では、基盤モデルを閲覧したり、各モデルの例となるユースケースやプロンプトを調べたり、読み込むことができます。はじめに、モデルへのアクセスを有効化する必要があります。コンソールで、左のナビゲーションペインの Model Access を選択し、アクセスしたいモデルの有効化を行いましょう。モデルアクセスが有効になると、さまざまなモデルを試し、ユースケースに適したモデルを見つけるために、さまざまな異なるモデルと推論に関する設定を試すことができます。モデルを試行する際には、本記事の最後に記載された料金モデルに従って支払いが発生します。 例えば、 Cohere の Command モデルを使用した契約に関する固有表現抽出の例は以下のようになります: この例では、プロンプト、サンプルのレスポンス、推論用パラメータの設定例、このサンプルを実行する API リクエストを示しています。 Open in Playground を選択すると、インタラクティブなコンソールで、モデルとユースケースをさらに試すことできます。 Amazon Bedrockは、チャット、テキスト、画像の Playground を提供します。チャットの Playground では、会話型のチャットインターフェースを使用して、さまざまな基盤モデルを試すことができます。次の例では、 Anthropic の Claude モデルを使用しています: 異なるモデルを評価する際には、様々なプロンプトエンジニアリングの手法や推論設定のパラメータを試すべきです。プロンプトエンジニアリングは、タスクやユースケースをよりよく理解し、基盤モデルを適用するための新しい技術です。効果的なプロンプトエンジニアリングとは、基盤モデルの能力を最大限に引き出し、適切かつ正確な返答を得るための完璧なクエリを作り上げることです。一般に、プロンプトはシンプルで直接的で、あいまいさを避けた方が良いです。プロンプトの中で例を提示したり、モデルに対してさらに複雑なタスクを推論させたりすることもできます。 推論設定のパラメータは、モデルが生成するレスポンスに影響します。 Temperature 、 Top P 、 Top K などのパラメータは、ランダム性や多様性を制御し、 Maximum Length や  Max Tokens はモデルのレスポンスの長さを制御します。それぞれモデルは、互いに異なる推論パラメータをもっていますが、それらの中には重複するパラメータがあることに注意してください。これらのパラメータは、異なるモデルを試していくなかで、モデル間で同じ名前か、似たような名前であることに気づくでしょう。 AWSが DeepLearning.AI と共同開発した Generative AI with Large Language Models のオンデマンドコースの第1週目で、効果的なプロンプトエンジニアリング技術と推論設定のパラメータについて詳しく説明しています。 Amazon Bedrock のドキュメント やモデルプロバイダーの関連ドキュメントを参照することで、追加のヒントを得ることができます。 次に、Amazon BedrockをAPI経由で操作する方法を見ていきましょう。 Amazon Bedrock API の利用 Amazon Bedrockは、ユースケースに合った基盤モデルを選択し、数回の API 呼び出しを行うだけの簡単な作業で利用することができます。以下のコード例では、Amazon Bedrock を操作するために、 PythonのAWS SDK (Boto3) を使用します。 利用できる基盤モデルの一覧を取得 まず boto3 の Clientをセットアップし、 list_foundation_models() を使って利用可能な最新の基盤モデルの一覧を取得しましょう。 import boto3 import json bedrock = boto3.client( service_name='bedrock', region_name='us-east-1' ) bedrock.list_foundation_models() Amazon Bedrock の InvokeModel API を使って推論を実行 次に、Amazon Bedrockの InvokeModel APIと boto3 ランタイムクライアントを使用して推論リクエストを実行しましょう。ランタイムクライアントは、 InvokeModel APIを含むデータプレーン API を管理します。 InvokeModel API 次のパラメータを必要とします。 {     "modelId": <MODEL_ID>,     "contentType": "application/json",     "accept": "application/json",     "body": <BODY> } modelId パラメーターは使用する基盤モデルを指定します。リクエストの body は、タスクのプロンプトと、推論設定のパラメーターを含む JSON の文字列です。プロンプトのフォーマットは、選択したモデルプロバイダと基盤モデルによって異なります。 contentType パラメーターと accept パラメーターは、リクエストの body とレスポンスのデータの MIME タイプを定義し、デフォルトは application/json です。最新のモデル、 InvokeModel API のパラメーター、プロンプトのフォーマットに関する詳細は Amazon Bedrock のドキュメント を参照してください。 例: AI21 LabのJurassic-2 モデルを使用したテキスト生成 ここでは、 AI21 Lab の Jurassic-2 Ultra モデルを使用したテキスト生成の例を示します。ノックノックジョークを話してとモデルにリクエストする、Hello Worldのようなものを試してみます。 bedrock_runtime = boto3.client( service_name='bedrock-runtime', region_name='us-east-1' ) modelId = 'ai21.j2-ultra-v1' accept = 'application/json' contentType = 'application/json' body = json.dumps( {"prompt": "Knock, knock!", "maxTokens": 200, "temperature": 0.7, "topP": 1, } ) response = bedrock_runtime.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) response_body = json.loads(response.get('body').read()) レスポンスは以下の通りです。 outputText = response_body.get('completions')[0].get('data').get('text') print(outputText) Who's there? Boo! Boo who? Don't cry, it's just a joke! InvokeModel API を利用して Embedding (埋め込み) のモデルを利用することもできます。 例: Amazon Titan Embeddings Model を使用したテキスト埋め込みの作成 テキスト埋め込みモデルは、単語、フレーズ、あるいはもっと大きな単位のテキストなどを、埋め込みベクトルと呼ばれる数値表現に変換します。埋め込みベクトルは、テキストの意味的な内容を高次元のベクトル空間に符号化したもので、パーソナライゼーションや検索などのアプリケーションにおいて有用です。この例では、 Amazon Titan Embeddings Model を使用して埋め込みベクトルを作成しています。 prompt = "Knock-knock jokes are hilarious." body = json.dumps({ "inputText": prompt, }) model_id = 'amazon.titan-embed-g1-text-02' accept = 'application/json' content_type = 'application/json' response = bedrock_runtime.invoke_model( body=body, modelId=model_id, accept=accept, contentType=content_type ) response_body = json.loads(response['body'].read()) embedding = response_body.get('embedding') 埋め込みベクトル (一部省略) は、例えば以下のようになります。 [0.82421875, -0.6953125, -0.115722656, 0.87890625, 0.05883789, -0.020385742, 0.32421875, -0.00078201294, -0.40234375, 0.44140625, ...] Amazon Titan Embeddings は一般利用可能です。テキスト生成のための Amazon Titan Text モデルは、限定プレビューで引き続き利用可能です。 Amazon Bedrockの InvokeModelWithResponseStream APIを使用して推論を実行する InvokeModel APIリクエストは同期的で、モデルが出力全体を生成するのを待つ必要があります。ストリーミングレスポンスをサポートするモデルの場合、入力した内容に対して、指定したモデルで推論を実行させながら、モデルが出力を生成するたびにレスポンスをストリーム形式で出力する InvokeModelWithResponseStream API を提供します。 ストリーミング形式のレスポンスは、インタラクティブなアプリケーションにおいて、ユーザを引きつけるような、反応の良いチャットインターフェースを提供する際に役立ちます。以下は、Amazon Bedrock の InvokeModelWithResponseStream APIを使用した Python コードの例です: response = bedrock_runtime.invoke_model_with_response_stream( modelId=modelId, body=body) stream = response.get('body') if stream: for event in stream: chunk=event.get('chunk') if chunk: print(json.loads(chunk.get('bytes').decode)) データプライバシーとネットワークセキュリティ Amazon Bedrock では、お客様がデータを完全にコントロールでき、入力した内容やカスタマイズした内容はお客様のAWSアカウント内でのみプライベートに保持されます。プロンプト、コンプリーション (出力)、ファインチューニングしたモデルなどのデータは、サービス改善のために使用されることはありません。また、データはサードパーティのモデルプロバイダーと共有されることもありません。 お客様のデータは、API コールが処理されたリージョン内にとどまります。すべての通信データ (in transit) は最低 TLS 1.2 で暗号化されています。保管データ (at rest) は、 AWS KMS のマネージドデータ暗号化キーを使用したAES-256で暗号化されています。また、お客様自身のキー (カスタマーマネージドキー) を使用してデータを暗号化することも可能です。 お客様のAWSアカウントとVirtual Private Cloud (VPC) を設定することで、 Amazon VPCエンドポイント ( AWS PrivateLink を利用)を使用して、VPC内で実行されているアプリケーションとAmazon Bedrockの間を、AWSネットワーク上で安全に接続できます。これにより、アプリケーションとAmazon Bedrockの間で、セキュアでプライベートな接続が実現します。 ガバナンスとモニタリング Amazon Bedrock は IAM と統合することで、Amazon Bedrock へのアクセス権限の管理を支援します。これらのアクセス権限には、特定のモデル、Playground、Amazon Bedrock 内の機能へのアクセスが含まれます。すべての AWS マネージドサービスの API 操作(Amazon Bedrock 操作を含む)は、お客様のアカウント内の CloudTrail に記録されます。 Amazon Bedrock は、AWS/Bedrock の名前空間を使用して InputTokenCount 、 OutputTokenCount 、 InvocationLatency 、 Invocations (呼び出し回数) などの一般的なメトリクス情報を CloudWatch に送信します。メトリクスを検索するときにモデル ID のディメンションを指定することで、結果をフィルタリングし、特定のモデルの統計を取得できます。このニアリアルタイムのインサイトにより、Amazon Bedrock で生成系 AI アプリケーションの構築を開始したときの使用量とコスト(入力および出力のトークン数)を追跡し、パフォーマンスの問題 (実行時のレイテンシと実行回数) をトラブルシューティングすることができます。 請求と料金モデル 請求と料金モデルに関して、Amazon Bedrockを利用する際には、以下を念頭に置いてください: 請求 – テキスト生成モデルは、処理された入力トークンと生成された出力トークンの両方について請求されます。テキスト埋め込みモデルは、処理された入力トークンについて請求されます。画像生成モデルは、生成された画像について請求されます。 料金モデル – Amazon Bedrockは、オンデマンドとプロビジョンドスループットの2つの価格設定モデルを提供しています。オンデマンド価格設定では、期間のコミットメントをすることなく、利用した分だけの支払いで基盤モデルを利用できます。プロビジョンドスループットは、主に大規模で一貫した推論ワークロード向けで、期間のコミットメントと引き換えに、保証されたスループットが必要な場合に設計されています。アプリケーションのパフォーマンス要件として、1分あたりの最大入力トークン数と出力トークン数を満たすために、特定の基盤モデルのモデルユニット数を指定します。詳細な価格情報は、 Amazon Bedrockの料金 をご参照ください。 Now Available Amazon Bedrockは、現在AWSリージョンの US East (バージニア北部)とUS West (オレゴン) で利用できます。詳細は、 Amazon Bedrock ウェブサイト 、 Amazon Bedrock のドキュメント 、 community.aws の generative AI のスペース をご覧ください。また、 Amazon Bedrock workshop でハンズオン体験ができます。Amazon Bedrock に関するフィードバックは、 AWS re:Post for Amazon Bedrock か、通常のAWSのお問い合わせ先までお送りください。 (プレビュー) Amazon Titan Textのテキスト生成モデル、Stability AI の Stable Diffusion XL  画像生成モデル、および agents for Amazon Bedrock (Knowledge Baseを含む) は、限定プレビューとして引き続き利用できます。アクセスをご希望の方は、AWSのお問い合わせ先までご連絡ください。 (近日公開) Meta の Llama 2 13Bおよび70Bパラメータモデルが、Amazon BedrockのフルマネージドAPIを通じて、推論とファインチューニングを利用できるようになります。 今日から Amazon Bedrock を利用して生成系 AI アプリケーションを構築しましょう！

AWS Amplify は、AWS Amplify Studio で GraphQL API をフルサポートすることを発表しました。これによって、DataStore の有無に関わらず、 Connected Forms や Data Manager のような、Amplify Studio の既存のデータ駆動の機能が、すべての新規および既存の Amplify アプリで利用できるようになりました。 何が新しくなったのか？ 今まで多くの Amplify Studio の機能は、すべての API に 競合解決モードセット を設定する必要がありました。Amplify DataStore は GraphQL API のラッパーで、デバイスがオフラインの間、ローカルでデバイス上のストレージを使用してデータを処理します。DataStore は、選択した競合解決ストラテジーを使用して、オフライン使用から生じるデータの不整合を処理します。 開発者からは、DataStore を使用しないアプリにも Amplify Studio の一連の機能を拡張してほしいという要望が寄せられていましたが、私たちはこれに応えました。今回の発表により、Amplify Studio はすべての Amplify GraphQL API と直接連携できるようになりました。 DataStore を使用していない開発者向けに、以下の機能が利用可能になりました。 Data Manager GraphQL API へのデータの作成、管理、シードは時間がかかり、面倒な場合があります。データマネージャーは、データ管理を簡単にするビジュアルコンテンツマネージャーです。データマネージャーは API に自動的に接続され、データスキーマと常に同期します。 Figma to Code + データバインディング わずか数行のコードで、Figma デザインからリアルタイムでクラウドに接続されたコンポーネントへ変換することが出来ます。Figma to Code を使用したデータバインディングにより、API のデータを利用して、 ユニークなコンポーネントの動的なコレクション を生成することができます。 Connected Forms クラウドに接続された美しい React フォームを、必要なときにすぐに入手できます。 Connected Forms は、GraphQL API に自動的にリンクされ、デザインも動作も完全にカスタマイズできます。 Amplify Studioの拡張サポートは、 既存のすべての Amplify アプリにも適用されます 。Amplify Studio を起動するか、既存のアプリに Amplify Studio を追加するだけで、すべての機能が Amplify アプリですぐに利用できるようになります。 Amplify Studio で新しい GraphQL API を構築する Amplify Studio で新しい GraphQL API を構築するには、まず新規または既存の Amplify アプリを開き、 Amplify Studio を起動する 必要があります。既存の Amplify アプリは Amplify コンソール で見つけることができます。 新しいアプリを作成する 場合は、アプリと名前を入力し、”Confirm deployment” を選択します。 デプロイが完了したら、”Launch Studio” ボタンを使用してスタジオを開きます。 スタジオを開いたら、左側のナビゲーションバーで Data タブを選択し、ビジュアル・データ・モデラーを開きます。”Add model” をクリックして、スキーマにテーブルを作成し定義します。スキーマが完成したら、右上隅にある “Save and Deploy” を選択します。 送信すると、Amplify はあなたのスキーマで新しい GraphQL API を生成します。API がデプロイされると、Amplify バックエンドをローカルプロジェクトに追加する準備が整います。生成された amplify pull コマンドをコピーし、ローカルプロジェクトのルートディレクトリで実行して、新しく作成した API をインポートします。 まだローカルプロジェクトを持っていない場合は、 こちらのドキュメント を参考に Next.js アプリや他のサポートされているフレームワークのプロジェクトを作成することができます。 amplify pull が完了したら、API を使用する準備ができました。 amplify add codegen を実行すると、Amplify CLI が自動的に GraphQL クエリを生成します。 重要: amplify add codegen の実行は、クエリーの深さを 4 に設定することをお勧めします。これによって、すべての Amplify Studio の機能が期待通りに動作します。 amplify configure codegen を実行することで、いつでもクエリの深さを変更できます。 競合解決の設定を変更する デフォルトでは、Amplify は競合解決を 無効 にして GraphQL API をプロビジョニングします。競合解決が無効になっている間、Amplify は Amplify Libraries を使用して GraphQL API と直接接続します。アプリがオフラインとオンラインの両方で動作する必要がある場合は、競合解決を有効にして DataStore を有効にすることができます。 競合解決を有効/無効にする、または競合解決戦略を変更するには、Data タブに移動し、”GraphQL API Settings” を選択します。 GraphQL API 設定で、競合解決を有効または無効にするスイッチをクリックします。競合解決が有効な場合、ドロップダウンで利用可能な競合解決ストラテジーから選択できます。 設定が完了したら、左上の “Back to Data Modeling”をクリックし、”Save and Deploy “で変更を適用します。最後に、ターミナルを使用して、プロジェクトのルートディレクトリで amplify pull を実行すると、更新された設定の APIが使用できるようになります。 重要：競合解決を無効にすると、データが破壊的に変更されます。データのない GraphQL API でのみ競合解決設定を変更することをお勧めします。詳しくはドキュメントをご覧ください。 今すぐ始める Amplify Studio は、GraphQL API の視覚的な設計とデプロイを簡単にし、Data Manager、Figma to Code、Form Builder などのツールを提供して、アプリの差別化を支援します。新しい Studio ユーザーであっても、長年の Amplify 開発者であっても、Studio はアプリ開発を加速するのに役立ちます。 今すぐ Amplify アプリの構築を始めましょう。 本記事は、 AWS Amplify Studio now offers direct support for GraphQL APIs を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

この記事は Amazon EKS now supports Kubernetes version 1.28 (記事公開日: 2023 年 9 月 26 日) を翻訳したものです。 はじめに Amazon Elastic Kubernetes Service ( Amazon EKS ) チームは、 Amazon EKS および Amazon EKS Distro の Kubernetes バージョン 1.28 のサポートを発表できることを嬉しく思います。 Amazon EKS Anywhere (リリース 0.18.0) も Kubernetes 1.28 をサポートします。このバージョンのリリース名は「Planternetes」です。このテーマは、植物 (Plant) と Kubernetes を組み合わせて庭園をイメージさせる言葉遊びです。 Kubernetes リリースチームは、 公式リリース発表 の中で、このリリースについて「このリリースを支えているのは、さまざまなバックグラウンドを持つ人々です。」と述べています。 Kubernetes 1.28 のハイライト この記事では、Kubernetes バージョン 1.28 リリースの注目すべき機能強化、および削除と非推奨の一部について説明します。まず、このリリースでは、コントロールプレーンとノードコンポーネントの間でサポートされるバージョンスキューの拡張を含む、いくつかの重要な変更が加えられていることに注意してください。v1.28 には、高度なステートフルワークロード管理のサポートなど、私たち全員が興奮している素晴らしい機能強化もあります。 以下は、1.28 リリースに関して技術コミュニティが興奮した機能強化の一部です。Kubernetes バージョン 1.28 の変更とアップデートの完全なリストについては、 Kubernetes リリースブログ を確認してください。 コントロールプレーンとノードのバージョン間でサポートされるスキューの変更 Kubernetes v1.28 では、コアコンポーネントに対してより寛容なバージョン互換性ポリシーが導入され、Kubernetes API サーバーと kubelet の間でサポートされるスキュー (ずれ、不均衡) が n-2 から n-3 に 1 マイナーバージョン分拡大されます。これは、サポートされている最も古いマイナーバージョンのノードコンポーネントが、サポートされている最新のマイナーバージョンの Amazon EKS コントロールプレーンコンポーネントと連携できることを意味します。例えば、Amazon EKS のバージョンが 1.26 の場合、使用できる最も古い kubelet のバージョンは 1.23 です。この変更は、 AWS Fargate 、 マネージド型ノードグループ 、 セルフマネージド型ノード でサポートされます。結局のところ、この変更により、データプレーン上の kubelet を更新するための猶予期間が少し長くなります。この変更により、データプレーン上で kubelet のマイナーバージョンを更新するための猶予期間が追加されますが、セキュリティ上の理由、特に潜在的な共通脆弱性識別子 (CVE) を考慮して、より新しい AMI (Amazon Machine Image) バージョンを維持することの重要性が否定されるわけではないことに注意してください。この n-3 スキューの変更は、現在サポートされているバージョンにのみ適用されます。あるバージョンがサポート終了となった場合、現在サポートされているバージョンのみの使用に制限されます。 詳細については、 Changes to supported skew between control plane and node versions を参照してください。 ステートフルワークロードの機能強化が安定版に移行 Kubernetes 1.28 では、特にステートフルワークロードの処理を強化する、高度なストレージ機能スイートが発表されました。Kubernetes Enhancement Proposal (KEP) ( #2268 , #3333 ) で説明されているこれらの機能強化は、安定版への移行が完了したため、すぐに利用可能です。これらの機能は、ステートフルワークロードをクラスター内でより効率的に管理できるようにする VolumeAttachment や PersistentVolumeClaim (PVC) などの強力なツールセットを提供します。StorageClass が定義されていないストレージを処理する場合でも、PersistentVolume (PV) を作成するオプションがあります。StorageClass を参照せずとも、NFS マウント用の PV を作成し、NFS サーバーの詳細とともに PV を定義するなど、PV を直接手動でプロビジョニングして作成することができます。その後、PV を PVC 経由で要求し、ステートフルワークロード用のストレージをプロビジョニングできます。 #2268 は安定版に移行し、NodeOutOfServiceVolumeDetach フィーチャーゲートはデフォルトで有効になりました。この機能は、グレースフルではないノードシャットダウンからの復旧を可能にし、ステートフルワークロードを別のノードに正常にフェイルオーバーできるようにします。これは、さまざまなプラットフォームでノードのシャットダウンを処理する際の以前の制限に対処します。既存の VolumeAttachment がシャットダウンされた元のノードから切り離されることを確実にすることで、ステートフルなアプリケーションのシームレスな移行を可能にします。 #3333 は安定版に移行し、RetroactiveDefaultStorageClass フィーチャーゲートはデフォルトで有効になりました。この機能により、PVC に対するデフォルトの StorageClass の自動的かつ遡及的な割り当てが安定に移行しました。PVC に StorageClassName が定義されていない場合、Kubernetes は自動的に StorageClassName を設定します。この機能により、ステートフルワークロードのストレージ管理の堅牢性が強化され、Kubernetes クラスター内でのストレージリソースの一貫した処理が保証されます。 詳細については、 Kubernetes 1.28: Non-Graceful Node Shutdown Moves to GA および Kubernetes v1.28: Retroactive Default StorageClass move to GA を参照してください。 高度なトポロジー管理ときめ細やかな Pod 配置がベータ版に到達 Kubernetes v1.28 では、洗練された多様なトポロジー管理機能が導入されました。KEP ( #3545 ) で詳しく説明されているこれらの機能は、デフォルトで有効になっており、ベータ版で利用可能です。これらを組み合わせることで、リソース効率を最大化し、パフォーマンスを向上させ、耐障害性を強化する方法で Pod の配置を調整するという課題に対処する、堅牢な強力なツールを形成します。両方のオプションを使用することで、Pod を互いに近くに配置してパフォーマンスを向上させるだけでなく、アベイラビリティゾーンなどの他の制約にも従い、クラスターリソースを効率的に使用できます。 TopologyManagerPolicyBetaOptions は、ノードのトポロジーやリソースのアベイラビリティなどの要素に基づいて Pod の配置を微調整するための高度な設定を提供します。主要な設定の 1 つは、prefer-closest-numa-nodes ポリシーです。 NUMA (Non-Uniform Memory Access) ノードは、CPU とメモリのグループです。通常、Topology Manager は利用可能な NUMA ノードに Pod を分散させますが、この設定は Topology Manager に近くの NUMA ノードを優先するように指示します。このオプションを有効にすると、Topology Manager は Pod の配置についてより多くの情報に基づいた決定を下せるようになり、NUMA ノード間の距離を考慮するように指示されます。これは、レイテンシーの影響を受けやすいアプリケーションや高スループットを必要とするアプリケーションにとって重要です。 TopologyManagerPolicyOptions は、独自のクラスタートポロジーに従って Pod の配置を調整する際の、追加のきめ細やかなレイヤーを提供します。この機能を使用すると、ノードラベル、アフィニティルール、およびリソース制約に基づいて制約を定義できるため、Pod の配置を細かく制御できます。これにより、ノードラベル、アフィニティルール、およびリソース制約を使用して制約を定義できます。たとえば、リソース使用率を最適化するために、Pod を特定のアベイラビリティゾーンに制限するように指定できます。 これらは強力な機能ですが、既存の Pod の仕様やノードの設定を調整する必要があることに注意してください。その影響を総合的にテストし、問題が発生した場合のロールバック計画を立てておくことをお勧めします。何らかの問題が発生した場合は、機能を無効にして kubelet を再起動することをお勧めします。 詳細については、 Control Topology Management Policies on a node を参照してください。 非推奨とその他のアップデート Kubernetes バージョン 1.28 のリリースに伴い、Amazon EKS は Amazon Elastic Compute Cloud ( Amazon EC2 ) インスタンスの互換性に直接影響する非推奨事項を含む、いくつかの重要な変更を導入しています。Kubernetes 1.28 に移行する前に、これらのアップデートを確認し、それに応じて Amazon EKS クラスターとアプリケーションを適応させることが重要です。この文脈における主な変更点は以下のとおりです。 Amazon EC2 P2 インスタンスの廃止 Kubernetes バージョン 1.28 以降では、Amazon EKS optimized accelerated Amazon Linux AMI で Amazon EC2 P2 インスタンスを使用することができなくなりました。 Kubernetes バージョン 1.28 以降向けのこれらの AMI は、P2 インスタンスと互換性のない NVIDIA 525 シリーズ以降のドライバーをサポートします。ただし、NVIDIA 525 シリーズ以降のドライバーは、P3、P4、および P5 インスタンスと互換性があるため、Kubernetes バージョン 1.28 以降の AMI でこれらのインスタンスを使用できます。Amazon EKS クラスターをバージョン 1.28 にアップグレードする前に、P2 インスタンスを P3、P4、P5 インスタンスに移行してください。また、NVIDIA 525 シリーズ以降で動作するように、アプリケーションを積極的にアップグレードすることをお勧めします。 サポートの終了 Amazon EKS は、常に少なくとも 4 つの Kubernetes バージョンをサポートしています。Kubernetes のリリースサイクルの性質を考えると、すべてのお客様にとって、継続的なアップグレード計画を持つことは非常に重要です。1.23 や 1.24 などの古いバージョンの Kubernetes をまだ実行している場合は、 より新しいサポートされているバージョン のいずれかにアップグレードすることを検討してください。1.23 クラスターのサポート終了は 2023 年 10 月 11 日、1.24 クラスターのサポート終了は 2024 年 1 月を予定しています。Amazon EKS のバージョンサポートに関してさらに質問がある場合は、 FAQ を参照してください。 まとめ この記事では、Kubernetes バージョン 1.28 の注目すべき変更点を紹介し、利用可能となった最もエキサイティングな機能のいくつかをハイライトしました。 Kubernetes v1.28 のリリースノート に記載されているその他の改善点もぜひチェックしてみてください。クラスターを最新の Amazon EKS バージョンにアップグレードする際にサポートが必要な場合は、 こちら のドキュメントを参照してください。 翻訳はプロフェッショナルサービスの杉田が担当しました。原文は こちら です。

業界調査会社の Information Services Group, Inc. (ISG) は、レポート ISG Provider Lens “Mainframes – Services and Solutions” を毎年発行しています。このレポートは、メインフレームアプリケーションモダナイゼーションソフトウェアを企業に提供しているベンダーの現在の市場での位置付けを、そのサービス提供の深さと市場での存在感に基づいて評価しています。 このたび本レポートに AWS Mainframe Modernization サービスが初めて掲載され、米国市場のリーダーとして評価されました。また、AWS はポートフォリオの魅力度でも最高位にランクされています。 レポートの筆頭著者である Pedro L Bicudo Maschio 氏は、「AWS は、強固なパートナーネットワークに支えられて、複雑なモダナイゼーションのための完全なポートフォリオを提供しています」と述べています。 AWS の強みは、モダナイゼーションとイノベーション、独自のクラウドネイティブなモダナイゼーションソリューション、厳選されたパートナーとソリューションにあると ISG が強調しています。 この評価は、メインフレームモダナイゼーションにおける AWS の6年間の投資とイノベーションの集大成であると我々は考えています。AWS Mainframe Modernizationは2017年にAWS パートナーネットワークの中の特定のパートナーとの協業から始まり、メインフレームの専門家を多数採用することで成長しました。革新的な AWS Mainframe Modernization というクラウドネイティブなサービスと AWS Mainframe Migration Acceleration Program (MAP) の併用により、この傾向はさらに加速しました。 AWS Mainframe Modernization サービス は、メインフレームアプリケーションをモダナイズするための、クラウドネイティブな独自の従量課金制サービスです。そのランタイム環境には、自動リファクタリング用の事前構成済みの AWS Blu Age ツールセット、リプラットフォーム用の Micro Focus ツールセット、Precisely によるデータ複製用の追加拡張パターン、Model9 によるファイル転送を含みます。このサービスは現在 15 の AWS リージョンで利用でき、将来的にはさらに多くのリージョンでも利用できるようになる予定です。AWS のソリューションアーキテクト、事業開発、プロフェッショナルサービスが、利用開始のお手伝いをします。このサービスは、厳選された AWS Mainframe Modernization コンピテンシーパートナー による支援も可能です。AWS は、メインフレーム向けの AWS Migration Acceleration Program ( MAP ) を通じて提供される、メインフレームのモダナイゼーションを加速するための具体的な方法論とインセンティブを提供しています。AWS は、お客様がビジネス変革を加速できるよう支援する機会を得て、新しい自動化機能、パートナーテクノロジーの統合、その他のユースケースのサポートにより、メインフレームアプリケーションのモダナイゼーションを革新し続けています。 2023 ISG Provider Lens US Quadrant for Mainframe Services and Solutions – Mainframe Application Modernization Software の無償コピーは、 こちら から入手できます。 本記事は、Ilia Gilderman と Madhavi Reddy による “ AWS Recognized as a Leader in the 2023 ISG Provider Lens for Mainframe Application Modernization Software ” を翻訳したものです。翻訳はソリューションアーキテクトの皆川 元が担当しました。 TAGS: Announcements

メインフレームはビジネス成長を支えるサービスとして長く利用されていますが、複雑性、運用保守コストや人材不足が課題となっています。ベンダーの製造・販売からの撤退も大きな衝撃をもたらしています。本ブログではMainframe Modernizationへのアプローチとして、 前編 では（１）ビジネス状況に応じたビジネスゴールの設定、（２）Mainframe Modernizationに向けた戦略立案についてご紹介し、後編では（３） AWS Mainframe Modernization でのソリューション選定についてご紹介します。 （３）AWS Mainframe Modernizationでのソリューション選定 AWSや AWSパートナー はさまざまな移行ソリューションを提供しており、用途に合わせた最適なソリューションを選定することができます。ここではAWS Mainframe Modernizationが提供する「 自動リファクタリング 」、「 リプラットフォーム 」についてご紹介します。なお、データ移行の新しいソリューションとしては、「 データレプリケーション 」、「 ファイル転送 」があります。 a. 「自動リファクタリング」ソリューション AWS Blu Age は、新しいウェブ・フレームワークとクラウド DevOps のベストプラクティスを駆使し、レガシーな言語アプリケーションをアジャイルなJavaベースのサービスに自動変換する強力なリファクタリング・ソリューションです。AWS Blu Ageは業務ロジックの変更を最小限に抑え、初期投資を削減することを目指しています。これにより、既存のシステムを効率的にアップデートし、ビジネスへの影響を低く抑えることができます。アップデートされたシステムと幅広いソリューションのオプションにより、新しいニーズにも素早く対応できるのは大きな利点です。また、AWS Blu AgeはJavaとの親和性を活かし、既存のシステムと新たなシステムをシームレスに連携させることができます。さらに、AWS Blu Ageは、システム全体に与えるリファクタリングによる影響を事前に評価し、品質を確保することができるため、安定したシステム運用を維持しつつアップデートを進める信頼性があります。このように、AWS Blu AgeとJavaを組み合わせることは、効率的かつ確実な業務モダナイゼーションを実現するための有力な手段です。 b. 「リプラットフォーム」ソリューション Micro Focusツールチェーン を使用して、COBOLアプリケーションの移行を行うアプローチは、特に注目されています。なぜなら、COBOLは長い歴史を持ち、その安定性と信頼性が確立されており、多くの企業で広く利用されているからです。したがって、既存のCOBOLシステムを維持しながら、プラットフォームをアップデートすることで、ビジネス運用の安定性を確保することが可能です。リプラットフォームのアプローチは、新たなシステムへの移行に比べてコストを大幅に削減できる点でも魅力的です。既存のシステムを基盤として、必要な部分を最新の技術で更新することで、コストを節約しながらシステムをモダナイゼーションできます。また、COBOLのスキルを持つエンジニアや開発者が新たなスキルを習得するためには時間とリソースが必要ですが、既存の人材を活用することでシステムの継続的な運用を確立することができます。統合されたMicro Focusツールチェーンを使用したCOBOLアプリケーションの移行は、AWS Mainframe Modernizationの成功事例の一つとしてビジネスに大きな価値を提供します。 おわりに Mainframe Modernizationは、ビジネスゴールを明確に設定し、最適な戦略を立案し、最適なソリューションを選択することで、多くのビジネス・メリットを享受することが出来ます。新しいテクノロジーとアプローチを活用することで、コストの削減、アジリティの向上、技術的負債とリスクの低減などが実現可能です。ビジネスのさらなる発展に向けてMainframe Modernizationへの取り組みは現代のビジネス環境に不可欠なステップになります。

メインフレームはビジネス成長を支えるサービスとして長く利用されていますが、複雑性、運用保守コストや人材不足が課題となっています。ベンダーの製造・販売からの撤退も衝撃をもたらしています。本ブログではMainframe Modernizationへのアプローチの前編として（１）ビジネス状況に応じたビジネスゴールの設定、（２）Mainframe Modernizationに向けた戦略立案についてご紹介します。 （１）ビジネス状況に応じたビジネスゴールの設定 メインフレームを運用しているお客様がビジネスゴールを設定するには、主要な観点を考慮した上でビジネス状況に応じた検討を行うことが重要です。 a. 財務上の成果 メインフレームの運用保守コストは他のコンピュータ資源に比べ高額であり、上昇傾向にあります。財務上の成果を達成するために、コストを削減し、運用効率を向上させる必要があります。 b. ビジネスリスクの軽減 メインフレームの技術的負債や人的リスク等のリスクを軽減し、競争力を確保するためには、最新のテクノロジーに適応させる必要があります。モダナイゼーションやクラウド移行により、目標とするビジネスゴールを設定します。 c.　ワークロードの特性 メインフレームのワークロードには、ビジネスの中心で利用され今後も更改され続けるもの、現状ほとんど変更がなく維持を継続する個々のワークロードの特性があります。その特性に合わせたビジネスゴールを設定します。 d. 俊敏性とインサイトの確保 メインフレームのデータはマスタデータとして広く活用されていますが、特有のデータ構造のため俊敏性や拡張性に劣ります。最新のテクノロジーの採用とデータ利用の革新性を高め、ビジネスプロセスの改善や意思決定のサポートに役立てるビジネスゴールを設定します。 （２）Mainframe Modernizationに向けた戦略立案 メインフレームをモダナイズするには、ビジネスゴール、ワークロードの特性および移行コスト等を考慮した移行戦略を立案します。その上で、ビジネスニーズに合った最適な移行ソリューションを選定します。 a. Migration & Modernization（移行とモダナイゼーション） 対象のワークロードをクラウドに移行することで、コストの削減、アジリティの向上、技術的負債とリスクの低減を実現することができます。ビジネスゴールに従って7Rアプローチによる移行戦略を策定します。以下に戦略策定の例を示します。 リプラットフォーム：短期間にできる限りコストを掛けずに他のプラットフォームに移行します。 リファクタリング：モダナイゼーションと俊敏性を高めつつコストを抑えて移行します。 リパーチェス、リライト：積極的に投資をおこない革新的な環境に作り直します。 b. Augmentation & Integration（拡張と統合） クラウドによる俊敏性と革新性を提供することで、メインフレームのデータから最大限の価値を引き出すことができます。ここでは、データの価値を高めるための戦略を策定します。 クラウド上でのデータ活用：メインフレームからクラウドにリアルタイムでデータを連携し、クラウド上で新しいチャネルや機能を提供し、顧客に新たな価値を提供します。 クラウド上でのデータ分析: データをクラウド上で分析し、洞察を得て戦略的な意思決定に活用します。 クラウドストレージ を使用したバックアップとアーカイブ: データの安全なバックアップと長期保存をクラウドストレージで行うことで、データの保護と可用性を向上させます。 Mainframe Modernizationのアプローチは、ビジネスゴールを設定した上で移行戦略を策定することが重要です。その上でソリューションを選定することでビジネスニーズに沿ったアプローチが可能になります。 後編 では、（３） AWS Mainframe Modernization でのソリューション選定についてご紹介します。

ソリューションアーキテクトの浅野です。2023年8月24日に「 製造業の設計開発領域向けセミナー ～AWSのHPCを活用した製品の設計開発期間の削減～ 」をオンライン開催しました。 本セミナーでは製造業での製品設計の研究・開発をされているお客様に向けて、流体解析や構造解析などで用いら入れるCAEなどでのAWS活用をご紹介いたしました。AWSからは、実際にAWSのHPCを活用頂いているお客様にご登壇頂き、設計者の方々ににいかに簡単にご利用いただけるか、セキュリティへの対応、実際のアプリケーション性能、AI/MLの活用事例をご紹介頂きました。AWSからは高パフォーマンスを実現する AWS のユニークなテクノロジや HPC に関連する AWS サービスの解説の他、hpc6a インスタンスや Graviton3 プロセッサなど最新のアップデートについてもご紹介しております。 本記事では、発表内容の概要と、発表資料を掲載します。 セミナー概要 タイトル :「製造業の設計開発領域向けセミナー ～AWSのHPCを活用した製品の設計開発期間の削減～」 日時 : 2023 年 8 月 24 日 (木) 10:00 – 12:00 10:00 – 10:05 オープニング スピーカー: AWS シニアビジネスデベロップメントマネージャー 舛重 国規 10:05 – 10:35 クラウドで設計・開発プロセスを爆速化！AWSを活用したオムロン独自の研究開発環境「RDinX」 スピーカー: オムロン株式会社 経営基幹職 津田 学 氏 自社セキュリティ基準に準拠したオムロン独自のAWS開発環境「RDinX」を構築。CAE・最適化のための演算リソースの柔軟な確保を実現し、パワーエレクトロニクス技術のプロセスを大幅削減！ 講演資料 10:35 – 11:05 プラントエンジニアリングのCAEにおけるHPC on AWS活用事例（ベンチマークを中心として） スピーカー: 千代田化工建設株式会社 リードエンジニア 髙城 恭司 氏 長年3次元流動解析（CFD）をHigh Performance Computing基盤にて実施しているが、近年はCPUおよびGPUの選択肢が増えている。本講演では、プラントエンジニアリングにおけるCAE活用事例や、各種CPUおよびGPUの実検討モデルにおけるベンチマーク結果（計算速度）について発表する。 講演資料 11:05 – 11:35 マテリアルズ・インフォマティクスと画像検査自動化への挑戦 スピーカー: 三協立山株式会社 三協マテリアル社 林 良和 氏、佐藤 晃太 氏 MI（林 様）: 材料工学の分野で「機械学習を活用した材料探索」（MI）が注目されています。本セッションではAmazon SageMakerを用いたMIによる材料開発について紹介します。 画像解析（佐藤 様）: Pythonを始めて数か月のエンジニアが、社内で蓄積された画像検査データとAmazon SageMakerを使って、画像検査の自動化に挑戦した過程をご紹介します。 講演資料 11:35 – 11:55 HPC on AWS の概要と最新動向 スピーカー: AWS シニアソリューションアーキテクト 吉廣 理 AWS では HPC 環境に求められる高レベルな CPU /ネットワーク/ストレージパフォーマンスは勿論、VDI やオーケストレーションなどクラウド HPC 環境をアシストする機能を兼ね備えています。本セッションでは高パフォーマンスを実現する AWS のユニークなテクノロジや HPC に関連する AWS サービスの解説の他、hpc6a インスタンスや Graviton3 プロセッサなど最新のアップデートについてもご紹介します。 講演資料 11:55 – 12:00 クロージング スピーカー: AWS シニアデベロップメントマネージャー 舛重 国規 おわりに 今回のセミナーでは、設計・開発分野でAWSを活用頂いているお客様より、実際の活用例や、導入にあたっての課題といったリアルな使い方についてご紹介頂きました。実業務での使い心地や導入時の課題に関心がある方々にとって、参考にして頂ける内容になっております。AWSでは、HPC環境を簡単に構築でき、コスト効率よくご利用いただけます。ぜひ設計・開発業務でもAWSをご活用ください！

このブログ記事は、Telco Solutions Architect の Jack Chen と、Developer Advocate の Robert Belson が執筆しています。 AWS Wavelength は、AWS のコンピューティングサービスとストレージサービスを 5G ネットワーク内に組み込み、超低レイテンシーアプリケーションの開発、デプロイ、スケーリングのためのモバイルエッジコンピューティングインフラストラクチャを提供します。AWS は、Wavelength Zones における Application Load Balancer (ALB) のサポートを開始しました。ALB はレイヤー 7 の負荷分散のユースケースに対応していますが、 Wavelength Zones にデプロイされる一部の低レイテンシーアプリケーションでは、QUIC、WebRTC、SRT などの UDP ベースのプロトコルに依存しており、レイヤー 7 ロードバランサーでは負荷分散できません。この投稿では、AWS Wavelength の一般的な負荷分散パターンについて説明します。これには、DNS ベースの負荷分散が、複数の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス間で非 HTTP (s) トラフィックを負荷分散するという顧客の要件にどのように対処できるかを示すアーキテクチャ案が含まれます。 このソリューションは、Wavelength Zones で実行されるワークロードの自動スケールアップおよびスケールダウン機能の基盤も構築します。 AWS Wavelength における負荷分散のユースケース AWS リージョンでは、可用性の高いエッジアプリケーションのデプロイを検討しているお客様が、受信したアプリケーショントラフィックを 1 つ以上のアベイラビリティーゾーン(AZ) の複数のターゲットに自動的に分散するアプローチとして Amazon Elastic Load Balancing (Amazon ELB) を検討することがよくあります。ただし、本投稿の公開時点では、AWS マネージドである Network Load Balancer (NLB) は Wavelength Zonesではサポートされておらず、ALB は世界中のすべての Wavelength Zones に展開されています。そのため、この投稿は、AWS Wavelength の負荷分散ソリューションに関する一般的なアーキテクチャガイダンスを文書化することを目的としています。 最も顕著な AWS Wavelength のユースケースの 1 つとして、WebRTC のようなプロトコルを大規模に使用した UDP 通信の没入感が高い動画ストリーミングがあります。ここでは、ライブイベントや一般的な顧客アクセスパターンによるトラフィック急増に対応するために負荷分散ソリューションが必要になることがよくあります。レイヤー 4 トラフィックに依存するこれらのユースケースでは、レイヤー 7 の ALB で負荷分散することはできません。代わりに、レイヤー 4 の負荷分散が必要です。 現在までに、レイヤー 4 ロードバランサーを含め以下の2つのインフラストラクチャデプロイメントが最もよく見られます。 Amazon EC2 ベースのデプロイメント : 多くの場合、初期段階の企業や ISV が選択する環境ですが、EC2 インスタンス群は、ビデオストリーミング、データ分析、産業 IoT (IIoT) アプリケーションなどの高スループットのユースケースでロードバランサーを活用します。 Amazon EKS デプロイメント : インフラストラクチャのパフォーマンスとコスト効率を最適化したいお客様は、エッジでのコンテナデプロイメントにより Wavelength Zones のアプリケーションを管理できます。次に、外部ロードバランサーを NodePort オブジェクトを介して公開されたサービスを指すように構成できます。さらに、Kubernetes の Ingress を作成するときに、 AWS Load Balancer Controller を活用して ALB をプロビジョニングするという方法も一般的です。 デプロイメントタイプにかかわらず、以下の設計上の制約を考慮する必要があります。 ターゲット登録 : AWS が管理していない負荷分散ソリューションの場合、ロードバランサーのターゲット登録をシームレスに行うためのソリューションはお客様が管理する必要があります。考えられる解決策の 1 つとして、最近の HAProxyConf でのプレゼンテーション をご覧ください。 エッジディスカバリ : キャリア向けエンドポイントごとに DNS レコードを Amazon Route 53 に入力することはできますが、DNS はモバイルクライアントを最適なモバイルエンドポイントに確定的にルーティングするわけではありません。利用可能な場合にモバイルクライアントを最もレイテンシーの低いエンドポイントに最も効果的にルーティングするには、エッジディスカバリサービスが必要です。 クロスゾーン負荷分散 : AWS Wavelength のハブアンドスポーク設計を考えると、お客様管理のロードバランサーはその Wavelength Zones にのみトラフィックをプロキシする必要があります。 ソリューションの概要 — Amazon EC2 このソリューションでは、Amazon EC2 ベースのデプロイメントで、単一の Wavelength Zones で可用性の高い負荷分散を実現します。別の投稿では、 AWS Wavelength における Amazon Elastic Kubernetes Service (Amazon EKS) クラスターの AWS Load Balancer Controller に必要な設定について説明します。 提案ソリューションでは、DNSベースの負荷分散を導入しています。これは、インテリジェントな負荷分散ソフトウェアの複雑さを解消し、Domain Name System (DNS) リゾルバーがトラフィックをエンドポイントセットに（均等に、または加重分散で）分散できるようにする手法です。 本ソリューションでは、Amazon Route 53 の 加重ルーティングポリシー を活用して、Wavelength Zones 内で実行されている複数の EC2 インスタンスに対するインバウンド DNS クエリを解決します。特定ワークロードの EC2 インスタンスは Wavelength Zones にデプロイされるため、起動時に キャリア IP アドレス をネットワークインターフェイスに割り当てることができます。 このソリューションにより、AWS Wavelength インスタンスにアタッチされたキャリア IP アドレスが、お客様提供のパブリックホストゾーンの DNS レコードとして自動的に追加されます。 パブリックホストゾーンのレコードがいくつあったとしても、Route53 がクエリにどのように応答するかを決定できるよう、Route53 には多数のルーティングポリシーが用意されています。 シンプルルーティングポリシー — Wavelength Zones の単一リソースにトラフィックをルーティングする必要がある場合は、シンプルなルーティングを使用できます。1 つのレコードに複数の IP アドレスを含めることができますが、Route 53 は値をランダムな順序でクライアントに返します。 加重ルーティングポリシー — 指定した比率を使用してトラフィックをより確定的にルーティングさせる場合は、このポリシーを選択できます。たとえば、キャリア IP アドレス A にトラフィックの 50% を受信させ、キャリア IP アドレス B にトラフィックの 50% を受信させたい場合は、それぞれ 50 と 50 の重みを持つ 2 つの個別の A レコード (キャリア IP アドレスごとに 1 つ) を作成します。Route 53 のルーティングポリシーの詳細については、 Route 53 デベロッパーガイド をご覧ください。 提案ソリューションは、Route 53 DNS の 加重ルーティングポリシー を利用して、Wavelength Zones で実行されている複数の EC2 インスタンスにトラフィックをルーティングします。 レファレンスアーキテクチャ 次の図は、本ソリューションの負荷分散コンポーネントを示しています。このコンポーネントでは、Wavelength Zones の EC2 インスタンスにキャリア IP アドレスが割り当てられます。ホスト (www.example.com など) の加重 DNS レコードは、キャリア IP アドレスで更新されます。 デバイスが DNS クエリを実行すると、指定されたドメイン名に関連付けられているキャリア IP アドレスのいずれかが返されます。デバイス数が多い場合は、リソースプール内のすべての EC2 インスタンスに負荷が均等に分散されると予想されます。非常にエフェメラルなモバイルエッジ環境であることを考慮すると、キャリア IP はワークロードに対応するために頻繁に割り当てられ、さらにすぐにリリースされる可能性があります。ただし、この予測不可能な動作により、古い DNS レコードが生成され、「ブラックホール」、つまり存在しなくなったエンドポイントへのルートが発生する可能性があります。 Time-To-Live (TTL) は、DNS 再帰リゾルバーがこのレコードに関する情報をキャッシュする時間を秒単位で指定する DNS 属性です。 この例では、30 秒に設定して、DNS リゾルバーが権威ネームサーバーから最新のレコードを取得するように強制し、古い DNS 応答を最小限に抑える必要があります。ただし、TTLを低くするとコストに直接影響します。これは、再帰リゾルバーから常に最新のレコードを取得するために Route 53への呼び出しが増えるためです。 ソリューションの中核となるコンポーネントは次のとおりです。 EC2 起動テンプレート — Amazon マシンイメージ (AMI) 、 Amazon Elastic Block Storage (Amazon EBS) のタイプとサイズ、キャリア IP が関連付けられた Elastic Network Interface (ENI) アタッチメント、 インスタンスタグ 、その他の属性などのインスタンス設定情報を指定します。 AWS Auto Scaling グループ — 自動スケーリングを目的として論理的にグループ化された EC2 インスタンス群 Wavelength Zones の上記のサービスに加えて、AWS リージョンでは以下のサービスも利用されています。 AWS Lambda — Route 53 サービスに API 呼び出しを行って DNS レコードを更新するサーバーレスのイベント駆動型関数 Amazon EventBridge — EC2 インスタンスの ライフサイクルイベント に反応し、Lambda 関数を呼び出して DNS を更新するサーバーレスイベントバス Amazon Route 53 — AWS Wavelength がホストするリソースを指すドメインレコードを含むクラウド DNS サービス 本投稿では、特定の負荷分散ソフトウェアソリューションは意図的にお客様に任せています。お客様は、HAProxy や NGINX など、 AWS Marketplace で入手可能なさまざまな一般的なロードバランサーを活用できます。DNS レコードの自動登録に重点を置いて機能的な負荷分散を実現するために、このソリューションはステートレスワークロードのみをサポートするように設計されています。ステートフルなワークロードをサポートするには、スティッキーセッション（ターゲットグループ内の同じターゲットにリクエストをルーティングするプロセス）を基盤となるロードバランサーソリューションで構成する必要があり、DNSがネイティブに提供できる範囲外です。 自動化の概要 前述のコンポーネントを使用して、以下のワークフローの自動化を実装できます。 Amazon CloudWatch アラーム は、Auto Scaling グループの スケールアウトまたはスケールイン イベントをトリガーし EC2 インスタンスを追加または削除することができます。EventBridge は EC2 インスタンスの状態変更イベントを検出し、Lambda 関数を呼び出します。この関数は、EC2 インスタンスの状態変化に関連する加重 A レコード を追加（スケールアウト）または削除（スケールイン）することにより、 Route53 の DNSレコードを更新します。 自動自動スケーリングポリシーの設定は、この記事の範囲外です。 メモリ使用率 などの 事前定義済み のカスタムメトリクスに基づいて、使用を検討できる Auto Scaling トリガーは多数あります。デモでは、手動による自動スケーリングを利用します。 すでに説明したコアコンポーネントに加えて、このソリューションでは AWS Identity and Access Management (IAM) ポリシーと CloudWatch も利用しています。どちらのサービスも、 AWS Well-Architected なソリューションを AWS で構築するための重要コンポーネントです。また、 AWS Systems Manager Parameter Store を使用してユーザー入力パラメータを追跡しています。ソリューションのデプロイは、 AWS CloudFormation テンプレートによって自動化されます。提供される Lambda 関数は AWS Simple Storage Service (Amazon S3) バケットにアップロードする必要があります。 Amazon Virtual Private Cloud (Amazon VPC) 、 サブネット 、 Carrier Gateway 、および ルートテーブル は、AWS ベースのネットワークインフラストラクチャにおける基本的な構成要素です。今回のデプロイメントでは、新しい VPC を作成し、選択した Wavelength Zones に 1 つのサブネット、Carrier Gateway を作成し、このサブネットのルートテーブルを更新して、デフォルトルートを Carrier Gateway を指すようにします。 導入の前提条件 本ソリューションを AWS アカウントにデプロイするための前提条件は次のとおりです。 Wavelength Zones へのアクセス : アカウントが Wavelength Zones を使用するための許可リストにない場合は、 こちら から Wavelength Zones にオプトインしてください。 Route 53 でホストされているパブリック DNS ホストゾーン : このソリューションをデプロイするには、登録済みのパブリックドメインへのアクセス権が必要です。このドメインのゾーンは、AWS Wavelength ワークロードをデプロイ予定のアカウントと同じアカウントでホストする必要があります。 パブリックドメインをお持ちでない場合は、 新しいドメイン を登録できます。ドメイン登録にはサービス料がかかりますのでご注意ください。 Amazon S3 バケット : Route 53 の DNS レコードを更新する Lambda 関数では、ソースコードを.zip ファイルとして Amazon S3 バケットに保存します。 Amazon EC2 キーペア : デプロイには既存のキーペアを使用できます。このソリューションをデプロイする予定のリージョンにキーペアがない場合は、 これらの手順 に従って作成してください。 4G または 5G 接続デバイス : インフラストラクチャは基盤となる接続デバイスとは独立して導入できますが、接続をテストするには、いずれかの Wavelength パートナーネットワークが利用可能なモバイルデバイスが必要です。詳細については、 通信プロバイダーと Wavelength Zones のロケーション一覧 を確認してください。 まとめ この投稿では、AWS Wavelength Zones で実行されているワークロードに DNS ベースの負荷分散を実装する方法を示しました。EventBridge ルール と Lambda 関数を使用して Route 53 がホストする DNS レコードを更新するソリューションをデプロイしました。AWS Wavelength について詳しく知りたい場合は、 こちら からAWS Compute ブログチャンネルを購読してください。 原文は こちら です。翻訳はソリューションアーキテクトの新谷 歩生が担当しました。

この記事は、Napptive の CTO である Daniel Higuero 氏と共同執筆したものです。 イントロダクション クラウドネイティブなアプリケーションの時代に、Kubernetes はコンテナオーケストレーションの分野における傑出したテクノロジーとして登場しました。しかしながら、Kubernetes を使う際には、クラスターの設定、クラスター全体のアドオン、補助するツールの実行や管理だけでなく、アプリケーションのデプロイに関わる設定 (Deployment、Service、Ingress, Horizontal Pod Autoscaling、LimitRange など) を理解することをユーザーに要求します。これはアプリケーションを実行するプラットフォームの構築に高い柔軟性をもたらす一方で、本番環境においてこういった設定を完全に把握し、プラットフォームを保守・実行することは簡単なタスクではありません。顧客の話によると、Kubernetes 上でアプリケーションのプラットフォームを構築・実行することに関連する懸念は、通常 1 つのチームに降りかかります。チームの名前は、誰に尋ねるかにもよっても異なるかもしれませんが、本記事ではチーム内のメンバーを プラットフォームエンジニア と呼びます。オペレーションモデルと責任 (言い換えると、自身でも運用するものを構築したり、他のユーザーが再利用できるテンプレートを作成する) は異なる場合がありますが、その目的は通常は同じで、社内の顧客や アプリケーション開発者 が簡単に利用できるプラットフォームを構築することです。 アプリケーション開発者はエンドユーザーに価値を提供するビジネスロジックと機能の実装に責任がある一方で、必ずしも Kubernetes の一部始終 (Ingress オブジェクトの詳細を適切に設定する方法など) を理解しているわけではありません。できれば、これらのチームはアプリケーションを実行する最小限の設定のみを指定したいと考えています。具体的には、どのポートをリッスンするのか、どのコンテナイメージを使用するのか、アラームの設定にどのメトリクスとしきい値を使用するのか、といったものです。 これらのペルソナは、両方ともビルダーです。内部向け、あるいは外部向けの顧客に公開されるプロダクトを開発しています。本番環境においては、構築するものは安定していて時間の経過とともに顧客の期待を満たすために進化可能である必要があります。 ソリューション概要 双方向の組織的な依存関係の削減 アプリケーション開発者を支援する 1 つの方法は、抽象化を通じて組織標準を導入することです。難しいのは、これらの抽象化を正しくおこなうことです。Kubernetes はそれ自体がアプリケーション、リソース、ストレージ、コンピュートの抽象化をおこなう一方で、この抽象化は、プラットフォーム開発者とアプリケーション開発者の双方にとって効率的であるには低レベルであることが多いと考えられています。例を挙げることで、こういった論拠を発展させてみましょう。プラットフォームチームが Kubernetes API をそのまま顧客 (すなわち、アプリケーションチーム) に公開し、変更がロールアウトされる必要があるシナリオを想像してください。おそらく、Kubernetes の 廃止予定の API 移行ガイド で説明されている Kubernetes v1.22 の Ingress オブジェクトの API グループの変更のような、新しい Kubernetes のバージョンと関係しているかもしれません。Ingress オブジェクトを例に挙げると、networking.k8s.io/v1beta1 API バージョンは Kubernetes 1.22 で廃止され、ユーザーは Ingress の定義を networking.k8s.io/v1 に変更する必要がありました。この変更により、プラットフォームチームと全ての顧客に依存関係が生じました。新しい API バージョンに沿うように設定を変更する必要があったからです。またこれは、プラットフォームチームが Kubernetes クラスターをアップグレードする前に、全ての顧客一人ひとりが新しいバージョンの API を使用する必要があることを意味しています。 このチーム間の双方向依存関係の例は、通常はプラットフォームチームとアプリケーションチームは一対多の関係であり、Kubernetes をアップグレードできないシナリオに繋がる可能性があります。Kubernetes のアップグレードが顧客のアプリケーションを壊すかもしれず、Kubernetes のバージョンのアップグレードが遅れるシナリオに陥り、サポートされているライフサイクル ( Amazon EKS Kubernetes リリースバージョンカレンダー を参照) から外れ、重要なアップデートの取り込みが停止するリスクがありいます。 Platform as a Product 前述のシナリオのような課題を解決する 1 つの方法は、独自の抽象化のレイヤーを作成することです。これは、サービスの API を構築する場合と同じように考えることができます。その API は安定していて、小さく、使用している基盤となるデータベースエンジンについての詳細が漏れないようにしたがるでしょう。それは API を利用するユーザーの関心事ではないからです。所有するインタフェースを通じて明確に定義された設定の選択肢の小さなセットをアプリケーションチームに公開することで、基盤となる実装 (この場合は Kubernetes) の詳細を顧客に漏らすことなく、改善点や機能をより早く実装できます。先程の例を踏まえると、このようなプラットフォームの改善は、Service と Ingress を使ってサービスを公開する従来のアプローチから、Kubernetes Gateway API でのサービスの公開に移行することかもしれません。 Open Application Model (OAM) 前述の抽象化は様々な方法で実現できますが、この記事では、アプリケーションのコンポーネントをデプロイする構成の抽象化を標準化する方法として、 Open Application Model (OAM) について説明します。これは抽象化のさらなる抽象化に少し似ているように聞こえるかもしれません。そうではありますが、これらの抽象化は、抽象化を利用するペルソナの目的を果たしていることを念頭に置いてください。Kubernetes は、プラットフォームを構築するプラットフォームエンジニアが、基盤となるインフラストラクチャリソースを使用するための抽象化のレイヤーとして機能し、OAM はプラットフォームエンジニアリングチームによって構築されたプラットフォームを使用するアプリケーション開発者向けの抽象化のレイヤーとして機能します。 OAM は、クラウドネイティブなアプリケーションを構築するためのオープンソースの 仕様 です。サービス、構成、依存関係を含む、アプリケーションのコンポーネントを宣言的に定義できます。OAM は、開発者が大幅な変更を加えることなく異なるプラットフォームのバージョンに簡単にデプロイ可能な、ポータブルなアプリケーションを作成することを可能にします。また、デプロイ・スケーリング・更新を含む、アプリケーションのライフサイクルを管理するためのフレームワークも提供します。OAM はその柔軟性と相互運用性により、クラウドでのモダンアプリケーション開発のための強力なツールとなっています。OAM の仕様は、必要に応じて新しいコンポーネントや機能を追加し拡張できるように設計されています。また OAM 仕様をサポートするどのプラットフォームでも使用できるという意味でも、非依存的です。このモデルでは、機能的な目的を達成するためにまとめてデプロイされるサービスの集合として、Application を定義します。 KubeVela KubeVela は前述の Open Application Model を実装するオープンソースのプロジェクトです。Kubernetes 上でアプリケーションを構築・デプロイ・管理するためのデリバリープロセスとして定義されています。開発者がアプリケーションのコンポーネントとそれらの関係を宣言的な方法で定義することを可能にする高レベルのプログラミングモデルを提供します。KubeVela のモデル主導型アプローチは、Kubernetes に関連する複雑さを大きく取り除き、開発者がインフラストラクチャの管理ではなくコードを書くことに集中できるようにします。また KubeVela は、アプリケーションの複数のコンポーネントを統合し、ローリングアップデート・ロールバック・カナリアリリースを実行できる、強力なデプロイエンジンを提供します。KubeVela の柔軟性と使いやすさは、Kubernetes の深い専門知識を必要とせずに Kubernetes 上でクラウドネイティブなアプリケーションを構築したい開発者にとって、良い選択になります。 KubeVela の Application は、以下の要素で構成されています。 Components: アプリケーションの機能要素について記述します。通常はバックエンドのマイクロサービスと関連付けられます。異なる Component の type が、リクエストを受信するバックエンドサービスなどの長時間実行されるプロセスと、定期的なバックアップタスクなどの短時間で終了するプロセスの両方をサポートします。 Traits: Trait を Component に関連付けることで、Component の基礎となる機能を拡張または変更できます。例えば、Trait はコンポーネントのログを別のサブシステムにエクスポートしたり、コンポーネントをインターネットに公開する追加の要素を作成したり、コンポーネントを実行するための設定オプションを追加したりできます。Component には、必要に応じて多くの Trait を関連付けることができます。 Policies: Trait と同様に、すべての Component に影響するアプリケーションレベルの設定オプションを適用する方法を提供します。 Workflows: 開発者がアプリケーションのデプロイ方法を定義できるようにします。これにより、コンポーネントのデプロイから他のサービスとの通信まで、複数の type のアクションを可能にする個々のワークフローステップを利用できます。 以下の図は、 KubeVela のドキュメントサイトから抜粋したものです。 ソース: https://kubevela.io/docs/getting-started/core-concept このアプローチにより、プラットフォームチームは Pod・Ingress・インフラストラクチャコントローラーのリソース ( AWS Controllers for Kubernetes や Crossplane ) など、全てのコンポーネントの低レベルの設定を保持する抽象化のレイヤーを作成でき、アプリケーションチームはそれを利用できます。アプリケーションチームは、作成・アップグレード・削除を含むコンポーネントのライフサイクル全体を担当します。以下の図は、もっとも単純な抽象化を示しています。 プラットフォームチームは、Deployment 設定、 Pod Topology Spread Constraints 、Ingress、Service の設定 (プロトコルまたはその他のパラメータに基づく) 及びその他の Kubernetes オブジェクトの構成など、Kubernetes のドメイン固有の設定を担当します。アプリケーションチームは、アプリケーション全体を表すとても軽量な構成を作成することに責任を持ちます。KubeVela の Component と Trait の抽象化を用いるため、アプリケーションチームは Kubernetes オブジェクトとその構成を設計した経験が豊富である必要はありません。 以下のハンズオンの例からもわかるとおり、最小限の設定で 1 つのアプリケーションを作成すると、Ingress または Service、HPA (オートスケーリング用) および Deployment というオブジェクトが生成されます。Kubernetes におけるデプロイの内容について知らなくても実現可能です。 ウォークスルー 何を構築するのか？ OAM と Kubernetes の価値を実証するために、 フロントエンド のコンポーネントと バックエンド のコンポーネントを組み合わせたサンプルアプリケーションを使用します。これらのサービスが合わさることで 1 つのアプリケーションを表します。アプリケーション開発者は Kubernetes について知る必要はありません。代わりに、KubeVela によって実装された、標準化された OAM モデルを使用できます。その結果、Kubernetes オブジェクトの設定 (Deployment、Ingress、ConfigMap など) はシンプルになります。アプリケーション開発者はこの OAM ベースのコンポーネントを使用して、アプリケーションを Kubernetes クラスターにデプロイします。 前提条件 始める前に、以下の前提条件を満たす必要があります。 Amazon Command Line Interface ( AWS CLI ) kubectl 実行中の Amazon Elastic Kubernetes Service (Amazon EKS) クラスター AWS LoadBalancer Controller がインストールされていること ( ガイド を参照すること) vela CLI ( KubeVela ユーザーインタフェース のため) アプリケーションコードを設定ファイルをホストする GitHub アカウント (GitOps アプローチを使用している場合) このセクションでは、Amazon EKS で KubeVela を使用して OAM を実装するために必要なステップを示します。 KubeVela を用いて環境をブートストラップする 最初のステップとして、OAM を使用して Kubernetes にクラウドネイティブなアプリケーションを構築およびデプロイするためのオープンソースフレームワークである KubeVela をデプロイしてみましょう。以下のコマンドで示すように、Amazon EKS クラスターに KubeVela をインストールします。 helm repo add kubevela https://charts.kubevela.net/core helm repo update helm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait Apache Configuration これらのコマンドは vela-system という名前の新しい Namespace を作成し、Amazon EKS クラスターに最新バージョンの KubeVela をインストールします。インストールした後、KubeVela を用いて OAM アプリケーションを定義およびデプロイできます。KubeVela ダッシュボードを有効化したい場合は、以下のコマンドを使用できます。 # vela addon enable velaux Apache Configuration ダッシュボードにアクセスするには、以下のコマンドを使用します。 # kubectl port-forward svc/velaux-server 8000:8000 -n vela-system Apache Configuration ブラウザを操作し、以下のようにダッシュボードにアクセスします。管理者ロールのユーザーとパスワードを登録しセットアップします。 KubeVela によるアプリケーションのデプロイ 前述のとおり、アプリケーションは 2 つのマイクロサービスで構成されています。マイクロサービスをデプロイするために、アプリケーションチームはもはや Kubernetes の Deployment の設定を覚える必要はありません。ここで OAM が登場します。 複数の Kubernetes オブジェクトをデプロイする代わりに、アプリケーションを設定するための適切な知識を持っていさえすれば、開発者はアプリケーションの高レベルな抽象化を以下のように定義できます。 # cat <<EOF > app.yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: web-app spec: components: - name: frontend type: webservice properties: image: "public.ecr.aws/aws-containers/ecsdemo-frontend:latest" ports: - port: 3000 expose: true traits: - type: cpuscaler properties: cpuUtil: 80 max: 6 min: 1 - type: env properties: env: NODEJS_URL: "http://ecsdemo-nodejs.default.svc.cluster.local/" - name: backend type: webservice properties: image: "public.ecr.aws/aws-containers/ecsdemo-nodejs:latest" ports: - port: 8080 expose: true traits: - type: scaler properties: replicas: 2 EOF kubectl apply -f app.yaml Apache Configuration Application マニフェストの構成について説明します。フロントエンドとバックエンドという 2 つの Component があります。これらの Component は type が webservice です。これは、KubeVela のインストールに付属するビルトインのコンポーネントタイプの 1 つです。組織の標準に沿った独自のコンポーネントの実装を作成することもできます。各 Component 内で、定義された Trait を確認できます。各 Trait には独自の実装があり、デモンストレーションを目的として、2 つの異なる Trait として、オートスケーリングと ENV Trait を使用しました。覚えておいて頂きたいのは、Component と Trait を組み合わせるこの方法は、Trait で定義される API に忠実に従う限り、メトリクスのバックエンドを別のものに切り替えるなど、Trait の基礎となる実装を後で変更または拡張できるようにするためであるということです。これには、Component と Trait を組み合わせる方法を変えることは含まれません。 KubeVela は作成する全てのオブジェクトにデフォルトの Label を付与するので、web-app Application の関連するオブジェクトを全て取得できます。ターミナルで以下のコマンドを実行して、アプリケーション用にどのようなオブジェクトが作成されたのかを調べてみましょう。 # kubectl get all --selector=app.oam.dev/name=web-app -L app.oam.dev/component NAME READY STATUS RESTARTS AGE COMPONENT pod/backend-6959d96ddc-4vnlc 1/1 Running 0 3d14h backend pod/backend-6959d96ddc-bmm4p 1/1 Running 0 3d14h backend pod/frontend-76877d4554-dzldt 1/1 Running 0 3d14h frontend NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE COMPONENT service/backend ClusterIP 10.100.148.2 <none> 8080/TCP 3d14h backend service/frontend ClusterIP 10.100.171.75 <none> 3000/TCP 3d14h frontend NAME READY UP-TO-DATE AVAILABLE AGE COMPONENT deployment.apps/backend 2/2 2 2 3d14h backend deployment.apps/frontend 1/1 1 1 3d14h frontend NAME DESIRED CURRENT READY AGE COMPONENT replicaset.apps/backend-6959d96ddc 2 2 2 3d14h backend replicaset.apps/frontend-76877d4554 1 1 1 3d14h frontend NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE COMPONENT horizontalpodautoscaler.autoscaling/frontend Deployment/frontend <unknown>/80% 1 6 1 3d14h frontend Apache Configuration ご覧のとおり、Service が 2 つ、Deployment が 2 つ、Horizontal Pod Autoscaler が 1 つあります。 簡潔に言うと、各オブジェクトは app.oam.dev/component ラベルの値に基づいて特定の Component に関連付けられます。KubeVela と Open OAM は、プラットフォームチームがより高レベルな概念を作成し、それらを組み合わせてより高度な構造にすることを可能にします。その後、これらの構造をアプリケーションチームが使用できるようになります。 フロントエンドサービスへのポートフォワーディングを設定することで、アプリケーションが実行されていることをテストできます。 # kubectl port-forward svc/frontend 3000:3000 Forwarding from 127.0.0.1:3000 -> 3000 Forwarding from [::1]:3000 -> 3000 Apache Configuration その後、ブラウザで http://localhost:3000 にアクセスして、アプリケーションが実行中であることを確認できます。 クリーンアップ 以下のコマンドを使用して、Application、Component、Trait をクリーンアップできます。 kubectl delete -f app.yaml Apache Configuration オプションで、 このドキュメント に従って作成された Amazon EKS クラスターを削除できます。 結論 本記事では、KubeVela を使って OAM を実装する方法を紹介しました。OAM は、Kubernetes 上でクラウドネイティブなアプリケーションを構築しデプロイするための標準化されたアプローチを提供します。OAM と KubeVela で抽象化をおこなうことで、開発者が Kubernetes でクラウドネイティブなアプリケーションを構築しデプロイするプロセスをシンプルにでき、開発者は顧客に価値を提供することに集中できます。 このブログ記事で紹介したコンセプトに興味がある場合は、ソーシャルメディア (Linkedin または Twitter) を使ってお気軽にご連絡ください。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

広告クリエイティブは、生成系 AI（Generative AI, GenAI）によって革命を起こす可能性を秘めています。 生成系 AI モデルを再トレーニングし、テキストプロンプト (モデルによって生成されるシーンやオブジェクトを説明する文) などのいくつかの入力をモデルに与えることで、製品画像などさまざまな種類の斬新な画像を作成できるようになりました。 この手法は、2022 年から Stable Diffusion 、 Midjourney 、 Dall-E-2 などの潜在拡散モデル (Latent Diffusion Model) と呼ばれる新しいクラスの基盤モデル（Foundation Model, FM）の爆発的増加によって有望な結果を示しています。 ただし、これらのモデルを本番環境で使用するには、生成プロセスを継続的に改良して一貫した出力を生成する必要があります。 多くの場合、製品のサンプル画像を大量に作成し、巧妙で迅速なエンジニアリングを行う必要があるため、大規模な作業は困難になります。 この記事では、特に大量の画像を扱う場合に、この革新的なテクノロジーを活用して、魅力的で革新的な広告を大規模に生成する方法について模索します。生成系 AI の力、特にインペインティング技術を利用することで、画像の背景をシームレスに作成でき、視覚的に美しく魅力的なコンテンツを作成でき、（モデルハルシネーションと呼ばれる）望ましくない画像アーティファクトを減らすことができます。 また、 Amazon SageMaker エンドポイントを活用して、この手法の実用的な実装についても詳しく説明します。これにより、この創造的なプロセスを推進する生成系 AI モデルの効率的なデプロイが可能になります。 生成系 AI ベースの画像生成では、画像内の欠落している要素を置き換えるための強力なソリューションである、インペインティングを重要なテクニックとして採用しています。 ただし、これにはいくつかの課題があります。 たとえば、画像内のオブジェクトの位置を正確にコントロールすることは制限されるため、次の画像例に示すような生成した画像自体の問題や、オブジェクトの浮き上がり、境界がシームレスに融合していないなどの問題が発生する可能性があります。 この問題に対処するために、この記事では最低限の指示で多数のリアルな画像を生成し、創造の自由と制作における効率性のバランスをとることを提案します。 提案されたソリューションを本番環境向けに拡張し、AWS 環境への AI モデルのデプロイを効率化するために、SageMaker エンドポイントを使用してデモを行います。 特に、インペインティング処理をレイヤーのセットとして分割します。この各レイヤーは異なるプロンプトのセットを持つことがあります。 このプロセスは、以下のステップに要約できます。 まず、一般的なシーンのプロンプト (たとえば「後ろに木がある公園」など) を入力して背景画像を生成し、その背景にオブジェクトをランダムに配置します。 次に、オブジェクトを置く場所をプロンプト（たとえば「芝生の上でのピクニック」、「木製のテーブル」など）で指示し、オブジェクトの中央下部より下の部分にレイヤーを追加します。 最後に、背景と同じプロンプトを使用して、オブジェクトの中央上部より上の部分に背景レイヤーに似たレイヤーを追加します。 このプロセスの利点は、背景に対して人間の期待に沿った拡大縮小や配置を解釈するため、オブジェクトのリアリティが向上することです。 次の図は、提案されたソリューションの手順を示しています。 ソリューション概要 これらのタスクを実行するには、次のデータフローが考えられます。 Segment Anything Model (SAM) と Stable Diffusion インペインティング モデルは SageMaker エンドポイント にホストされます。 背景プロンプト (Background Prompt) を使用して、Stable Diffusion モデルを使用して背景画像 (Generated Background Image) を生成します。 基本となる商品画像 (Base Product Image) が SAM を介して渡されマスク画像 (Mask) が生成されます。 マスク画像の逆はアンチマスク画像 (Anti-Mask) と呼ばれます。 生成された背景画像とマスク画像が、前景用のプロンプト (Foreground Prompt) とネガティブプロンプト (Negative Prompt) と一緒に Stable Diffusion インペインティングモデルへの入力として使用され、中間生成物としての背景画像 (Generated Intermediate Background Image) が生成されます。 同様に、生成された背景画像、アンチマスク画像、前景用のプロンプト、ネガティブプロンプトが Stable Diffusion Inpainting モデルへの入力として使用され、中間生成物としての前景画像 (Generated Intermediate Foreground Image) が生成されます。 最終的に生成される商品画像の出力結果 (Generated Product Image) は、生成された中間の前景画像と生成された中間の背景画像を組み合わせることによって得られます。 前提条件 エンドポイントのデプロイと推論の実行に使用する SageMaker ノートブック を作成する AWS CloudFormation テンプレートを開発しています。 以下にアクセスできる AWS Identity and Access Management (IAM) ロールを持つ AWS アカウントが必要です。 AWS CloudFormation SageMaker SageMaker エンドポイントには ML モデルを実行するインスタンスが提供されていますが、生成系 AI モデルのような負荷の高いワークロードを実行するには、GPU 対応の SageMaker エンドポイントを使用します。 価格の詳細については、 Amazon SageMaker の料金 を参照してください。 モデルのホストには NVIDIA A10G 対応の ml.g5.2xlarge インスタンスを使用しています。 Amazon Simple Storage Service (Amazon S3) 詳細については、 GitHub レポジトリ と CloudFormation テンプレート をご確認ください。 製品の対象領域をマスクする 一般的には、配置したいオブジェクトの画像と、オブジェクトの輪郭を描いたマスクを用意する必要があります。 これは Amazon SageMaker Ground Truth などのツールを使用して行うことができます。あるいは、オブジェクトが画像の真ん中にあると仮定すれば、Segment Anything Models（SAM）などの AI ツールを使用してオブジェクトを自動的にセグメント化することもできます。 SAM を使用してマスク画像を生成する 高度な生成系 AI 技術である SAM を使用すると、画像内のさまざまなオブジェクトに高品質のマスク画像を簡単に生成できます。 SAM は、広範なデータセットでトレーニングされた深層学習のモデルを使用して、対象オブジェクトを正確に識別してセグメント化し、正確な境界とピクセルレベルのマスク画像を提供します。 この画期的なテクノロジーは、手作業でマスク画像を作成するという時間と労力のかかる作業を自動化することで、画像処理のワークフローを革新します。 SAM により、企業や個人はオブジェクト認識、画像編集、コンピュータービジョンタスクなどのためのマスク画像を迅速に生成できるようになり、視覚的な分析と操作の可能性が広がります。 SAM モデルを SageMaker エンドポイントでホストする ノートブック 1_HostGenaiModels.ipynb を使用して SageMaker エンドポイントを作成し、SAM モデルをホストします。 inference_sam.py 内の推論コードを使用し、それを code.tar.gz ファイルにパッケージ化し、それを使用して SageMaker エンドポイントを作成します。 このコードは SAM モデルをダウンロードし、エンドポイントにホストし、推論を実行して出力を生成するためのエントリポイントを提供します。 SAM_ENDPOINT_NAME = 'sam-pytorch-' + str(datetime.utcnow().strftime('%Y-%m-%d-%H-%M-%S-%f')) prefix_sam = "SAM/demo-custom-endpoint" model_data_sam = s3.S3Uploader.upload("code.tar.gz", f's3://{bucket}/{prefix_sam}') model_sam = PyTorchModel(entry_point='inference_sam.py', model_data=model_data_sam, framework_version='1.12', py_version='py38', role=role, env={'TS_MAX_RESPONSE_SIZE':'2000000000', 'SAGEMAKER_MODEL_SERVER_TIMEOUT' : '300'}, sagemaker_session=sess, name='model-'+SAM_ENDPOINT_NAME) predictor_sam = model_sam.deploy(initial_instance_count=1, instance_type=INSTANCE_TYPE, deserializers=JSONDeserializer(), endpoint_name=SAM_ENDPOINT_NAME) SAM モデルを呼び出してマスク画像を生成する 次のコードは 2_GenerateInPaintingImages.ipynb ノートブックの一部で、エンドポイントを実行して結果を生成するために使用されます。 raw_image = Image.open("images/speaker.png").convert("RGB") predictor_sam = PyTorchPredictor(endpoint_name=SAM_ENDPOINT_NAME, deserializer=JSONDeserializer()) output_array = predictor_sam.predict(raw_image, initial_args={'Accept': 'application/json'}) mask_image = Image.fromarray(np.array(output_array).astype(np.uint8)) # save the mask image using PIL Image mask_image.save('images/speaker_mask.png') 次の図は、製品画像から取得したマスク画像を示しています。 インペインティングを使用して画像を生成する SAM によって生成されたマスク画像を使ったインペインティングの力と、ユーザーのプロンプトを組み合わせることで、素晴らしい生成画像を作成できます。 インペインティングは高度な生成系 AI 技術を利用して、画像の欠けている部分やマスク画像されている部分をインテリジェントに埋め、周囲のコンテンツとシームレスに融合します。 SAM が生成したマスク画像をガイダンスとし、ユーザーのプロンプトをクリエイティブな入力として使用することで、インペインティングアルゴリズムは視覚的に一貫した文脈に適したコンテンツを生成し、とても美しくパーソナライズされた画像を作成できます。 このテクノロジーの融合により、クリエイティブな可能性が無限に広がり、ユーザーは自分のビジョンを鮮やかで魅力的なビジュアルストーリーに変えることができます。 SageMaker エンドポイントで Stable Diffusion のインペインティングモデルをホストする 2.1 と同様に、ノートブック 1_HostGenaiModels.ipynb を使用して SageMaker エンドポイントを作成し、Stable Diffusion のインペインティングモデルをホストしています。 inference_inpainting.py 内の推論コードを使用し、それを code.tar.gz ファイルにパッケージ化し、それを使用して SageMaker エンドポイントを作成します。 このコードは Stable Diffusion インペインティングモデルをダウンロードし、エンドポイントでホストし、推論を実行して出力を生成するためのエントリポイントを提供します。 INPAINTING_ENDPOINT_NAME = 'inpainting-pytorch-' + str(datetime.utcnow().strftime('%Y-%m-%d-%H-%M-%S-%f')) prefix_inpainting = "InPainting/demo-custom-endpoint" model_data_inpainting = s3.S3Uploader.upload("code.tar.gz", f"s3://{bucket}/{prefix_inpainting}") model_inpainting = PyTorchModel(entry_point='inference_inpainting.py', model_data=model_data_inpainting, framework_version='1.12', py_version='py38', role=role, env={'TS_MAX_RESPONSE_SIZE':'2000000000', 'SAGEMAKER_MODEL_SERVER_TIMEOUT' : '300'}, sagemaker_session=sess, name='model-'+INPAINTING_ENDPOINT_NAME) predictor_inpainting = model_inpainting.deploy(initial_instance_count=1, instance_type=INSTANCE_TYPE, serializer=JSONSerializer(), deserializers=JSONDeserializer(), endpoint_name=INPAINTING_ENDPOINT_NAME, volume_size=128) Stable Diffusion のインペインティングモデルを呼び出し、新しい画像を生成する SAM モデルを呼び出す手順と同様に、ノートブックの 2_generateInPaintingImages.ipynb を使用してエンドポイントで推論を実行し、結果を生成します。 raw_image = Image.open("images/speaker.png").convert("RGB") mask_image = Image.open('images/speaker_mask.png').convert('RGB') prompt_fr = "table and chair with books" prompt_bg = "window and couch, table" negative_prompt = "longbody, lowres, bad anatomy, bad hands, missing fingers, extra digit, fewer digits, cropped, worst quality, low quality, letters" inputs = {} inputs["image"] = np.array(raw_image) inputs["mask"] = np.array(mask_image) inputs["prompt_fr"] = prompt_fr inputs["prompt_bg"] = prompt_bg inputs["negative_prompt"] = negative_prompt predictor_inpainting = PyTorchPredictor(endpoint_name=INPAINTING_ENDPOINT_NAME, serializer=JSONSerializer(), deserializer=JSONDeserializer()) output_array = predictor_inpainting.predict(inputs, initial_args={'Accept': 'application/json'}) gai_image = Image.fromarray(np.array(output_array[0]).astype(np.uint8)) gai_background = Image.fromarray(np.array(output_array[1]).astype(np.uint8)) gai_mask = Image.fromarray(np.array(output_array[2]).astype(np.uint8)) post_image = Image.fromarray(np.array(output_array[3]).astype(np.uint8)) # save the generated image using PIL Image post_image.save('images/speaker_generated.png') 次の図は、調整されたマスク画像、生成された背景画像、生成された製品画像、および後処理後の画像を示しています。 生成された商品画像は、次のプロンプトを使用します。 背景生成 — “chair, couch, window, indoor”（日本語訳：「椅子、ソファ、窓、屋内」） インペインティング — “besides books”（日本語訳：「本以外」） クリーンアップ この記事では、コストの大部分を占める 2 つの GPU 対応の SageMaker エンドポイントを使用します。 これらのエンドポイントは、使用していないときに余分なコストがかからないように、オフにする必要があります。エンドポイントのクリーンアップに役立つノートブック 3_CleanUp.ipynb を用意しています。 また、SageMaker ノートブックを使用してモデルをホストし、推論を実行します。 そのため、ノートブックインスタンスが使用されていない場合は停止することをお勧めします。 まとめ 生成系 AI モデルは通常、効率的に実行するには特定のリソースを必要とする大規模な ML モデルです。 この投稿では、広告のユースケースを使用して、SageMakerエンドポイントが、テキストから画像への基盤モデルである Stable Diffusion などの生成系 AI モデルをホストするためのスケーラブルで管理された環境を提供する方法を説明しました。 2 つのモデルをホストして必要に応じて実行する方法と、 1 つのエンドポイントから複数のモデルをホストする 方法を説明しました。 これにより、インフラストラクチャのプロビジョニング、スケーラビリティ、監視に関連する複雑さが解消され、組織はモデルの導入と予測の提供だけに集中してビジネス上の課題を解決できます。 SageMaker エンドポイントを使用すると、組織は統一されたインフラストラクチャ内で複数のモデルを効率的に展開および管理できるため、最適なリソース利用を実現し、運用のオーバーヘッドを削減できます。 詳細なコードは GitHub で公開されています。 このコードでは、AWS CloudFormation と AWS Cloud Development Kit (AWS CDK) を使用して SageMaker ノートブックやその他の必要なリソースを作成するプロセスを自動化する方法を示しています。 著者について Fabian Benitez-Quiroz は AWS プロフェッショナルサービスの IoT エッジデータサイエンティストです。 オハイオ州立大学でコンピュータービジョンとパターン認識の博士号を取得しています。 Fabian は、さまざまな業界のお客様が IoT デバイスやクラウド上で低レイテンシーで機械学習モデルを実行できるよう支援しています。   Romil Shah は AWS プロフェッショナルサービスのシニアデータサイエンティストです。 Romilは、コンピュータービジョン、機械学習、IoT エッジデバイスにおいて6年以上の業界経験があります。 彼は、顧客がエッジデバイスやクラウド向けに機械学習モデルを最適化して展開できるよう支援しています。 顧客と協力して、基盤モデルを最適化および展開するための戦略を策定しています。   Han Man は、カリフォルニア州サンディエゴを拠点とする AWS プロフェッショナルサービスのシニアデータサイエンスおよび機械学習マネージャーです。 ノースウェスタン大学で工学の博士号を取得し、経営コンサルタントとして製造、ファイナンスサービス、エネルギーの分野でクライアントにアドバイスを提供した経験が数年あります。 現在、彼はさまざまな業種の主要顧客と熱心に協力して、AWS で ML と生成系ソリューションを開発および実装しています。   翻訳はソリューションアーキテクトの柏村が担当しました。原文は こちら です。

ビジネスアナリストであれば、顧客の行動を理解することは、おそらく最も重要なことの1つです。顧客の購入決定の背後にある理由とメカニズムを理解することで、収益の拡大を促進できます。一方で、顧客の喪失 (一般に顧客解約と呼ばれる) は常にリスクを伴います。顧客が離脱する理由についてのインサイトを得ることも、利益と収益を維持するためにも同様に重要です。 機械学習 (ML) は貴重なインサイトを提供できますが、 Amazon SageMaker Canvas が導入されるまでは、顧客離れ予測モデルを構築するには ML の専門家が必要でした。 SageMaker Canvas はローコード/ノーコードのマネージドサービスで、コードを 1 行も記述しなくても多くのビジネス上の問題を解決できる ML モデルを作成できます。また、まるでデータサイエンティストであるかのように、高度な指標を使用してモデルを評価できます。 前提条件 この記事で説明されているタスクのすべてまたは一部を実装する場合は、SageMaker Canvas にアクセスできる AWS アカウントが必要です。SageMaker Canvas、顧客離れ予測モデル、およびデータセットに関する基本事項については、「 Amazon SageMaker Canvas を使用したコーディング不要の機械学習による顧客離れの予測 」を参照してください。 モデル性能評価の概要 一般的なガイドラインとして、モデルのパフォーマンスを評価する必要がある場合、新しいデータを見たときにモデルが結果をどれだけうまく予測できるかを測定することです。この予測は推論と呼ばれます。まず、既存のデータを使用してモデルをトレーニングし、次に、まだ見ていないデータに基づいて結果を予測するようにモデルを呼び出します。モデルがこの結果をどの程度正確に予測するかが、モデルのパフォーマンスを理解するうえで重要です。 モデルが新しいデータを見ていないとしたら、予測が良いか悪いかをどうやって知ることができるでしょうか？つまり、結果が既に分かっている過去のデータを実際に使用して、その値をモデルの予測値と比較するというものです。これは、過去のトレーニングデータの一部を取っておき、モデルが予測した値と比較できるようにすることで可能になります。 顧客離れ（カテゴリ分類の問題）の例では、多くの属性（各レコードに 1 つ）を持つ顧客を説明する履歴データセットから始めます。Churn と呼ばれる属性の 1 つは True でも False でもかまいません。これは、顧客がサービスを辞めたかどうかを表すものです。モデルの精度を評価するために、このデータセットを分割し、一方の部分 (トレーニングデータセット) を使用してモデルをトレーニングし、もう一方の部分 (テストデータセット) の結果を予測するようにモデルを呼び出します (顧客を離脱する顧客かそうでないかに分類)。次に、モデルの予測をテストデータセットに含まれる正解データと比較します。 高度なメトリクスの解釈 このセクションでは、モデルのパフォーマンスを理解するのに役立つ SageMaker Canvas の高度なメトリクスについて説明します。 混同行列 SageMaker Canvas は混同行列を使用して、モデルが予測を正しく生成することを視覚化するのに役立ちます。混同行列では、予測値を実際の過去 (既知の) 値と比較するように結果が整理されます。次の例は、 positive と negative を予測する 2 つのカテゴリの予測モデルで混同行列がどのように機能するかを説明しています。 True positive — 正解ラベルがpositiveの場合、モデルはpositiveを正しく予測しました True negative — 正解ラベルがnegative場合、モデルはnegativeを正しく予測しました。 False positive — 正解ラベルがnegativeの場合、モデルは誤ってpositiveと予測しました。 False negative — 正解ラベルがpositiveの場合、モデルは誤ってnegativeと予測しました。 次の画像は、2 つのカテゴリの混同行列の例です。この顧客離れ予測モデルでは、実際の値はテストデータセットから得られ、予測値はモデルに問い合わせて得られます。 正解率 正解率は、テストデータセットのすべての行またはサンプルのうち、正しい予測のパーセンテージです。True と予測された真のサンプルと、False と正しく予測された偽サンプルを、データセット内のサンプルの総数で割ったものです。 モデルがどのくらいの割合で正しく予測したかわかるため、理解しておくべき最も重要な指標の1つですが、場合によっては誤解を招く可能性があります。例えば: クラスの不均衡 — データセット内のクラスが均等に分布していない（あるクラスのサンプル数が不均衡で、他のクラスのサンプル数が非常に少ない）場合、正解率は誤解を招く可能性があります。このような場合、データごとに過半数のクラスを予測するだけのモデルでも、高い正解率となってしまいます。 コスト考慮型の分類 — アプリケーションによっては、クラスごとに誤分類のコストが異なる場合があります。たとえば、ある薬物が病状を悪化させる可能性があるかどうかを予測する場合、偽陰性（たとえば、その薬物が実際にはその薬物を使用すると悪化するにもかかわらず、悪化しない可能性を予測）は、偽陽性（たとえば、実際には悪化しないのにその薬を使用することで悪化する可能性があると予測すること）よりもコストがかかる可能性があります。 精度（Precision）、再現率（recall）、F1スコア（F1 score） 精度は、予測されるすべての陽性（TP+FP）に対する真陽性（TP）の割合です。陽性の予測のうち、実際に正しかったものの割合を測定します。 再現率は、実際の陽性（TP + FN）すべてに対する真陽性（TP）の割合です。モデルによって陽性と正しく予測された陽性例の割合を測定します。 F1 スコアは、精度と再現率を組み合わせたもので、両者のトレードオフのバランスを取った単一のスコアになります。精度と再現率の調和平均として定義されています。 F1 score = 2 * (精度 * 再現率) / (精度 + 再現率) F1のスコアの範囲は0〜1で、スコアが高いほどパフォーマンスが優れていることを示します。F1 スコアが 1 の場合は、モデルが完全な精度と完全な再現率の両方を達成したことを示し、スコアが 0 の場合は、モデルの予測が完全に誤っていることを示します。 F1スコアは、モデルのパフォーマンスをバランスよく評価します。精度と再現率を考慮して、陽性事例を正しく分類し、偽陽性と偽陰性を回避するモデルの能力を反映した、より有益な評価指標となります。 たとえば、医療診断、不正検知、感情分析では、F1が特に重要です。医療診断では、特定の疾患または状態の存在を正確に特定することが重要であり、偽陰性または偽陽性は重大な結果をもたらす可能性があります。F1スコアでは、精度（陽性症例を正しく特定する能力）と再現率（すべての陽性症例を発見する能力）の両方が考慮され、疾患の検出におけるモデルの性能をバランスよく評価できます。同様に、実際の不正事例の数が非不正事例と比較して比較的少ない不正検出（不均衡なクラス）では、真陰性の事例の数が多いため、精度だけでは誤解を招く可能性があります。F1スコアは、精度と再現率の両方を考慮して、モデルが不正なケースと非不正的なケースの両方を検出する能力を包括的に測定します。また、感情分析では、データセットのバランスが取れていないと、ポジティブな感情クラスのインスタンスを分類する際のモデルのパフォーマンスが精度に正確に反映されない可能性があります。 AUC (area under the curve) AUC メトリクスは、すべての分類閾値においてポジティブクラスとネガティブクラスを区別する二項分類モデルの能力を評価します。閾値とは、モデルが 2 つのクラス間の判断に使用する値で、サンプルがクラスに含まれる確率をバイナリ判定に変換します。AUC を計算するには、さまざまな閾値設定にわたって真陽性率 (TPR) と偽陽性率 (FPR) をプロットします。TPR は実際のすべての陽性に対する真陽性の割合を測定し、FPR は実際の陰性すべてのうちで偽陽性の割合を測定します。結果として得られる曲線は、受信者動作特性 (ROC) 曲線と呼ばれ、さまざまな閾値設定での TPR と FPR を視覚的に表しています。AUC 値は 0 ～ 1 の範囲で、ROC 曲線の下の領域を表します。AUC 値が高いほどパフォーマンスが良く、分類モデルが完璧であれば AUC は 1 になります。 次のグラフは、TPR を Y 軸、FPR を X 軸とした ROC 曲線を示しています。曲線がプロットの左上隅に近づくほど、モデルはデータをカテゴリに分類しやすくなります。 わかりやすくするために、例を見てみましょう。不正検出モデルについて考えてみましょう。通常、これらのモデルは不均衡なデータセットからトレーニングされます。これは、通常、データセット内のほとんどすべてのトランザクションが不正ではなく、不正とラベル付けされたトランザクションはごくわずかであるためです。この場合、精度だけではモデルのパフォーマンスを十分に捉えられない可能性があります。不正ではないケースの多さに大きく影響され、誤解を招くような高い精度スコアにつながるからです。 この場合、AUCは、モデルが不正な取引と不正でない取引を区別する能力を包括的に評価できるため、モデルのパフォーマンスを評価するためのより良い指標となるでしょう。さまざまな分類閾値における真陽性率と偽陽性率のトレードオフを考慮に入れて、より微妙な評価ができます。 F1スコアと同様に、AUCはデータセットのバランスが崩れている場合に特に役立ちます。TPR と FPR のトレードオフを測定し、分布に関係なくモデルが 2 つのクラスをどれだけうまく区別できるかを示します。つまり、一方のクラスが他方のクラスよりも大幅に小さくても、ROC 曲線では両方のクラスを同等に考慮することで、モデルの性能をバランスよく評価できるということです。 その他の主要トピック ML モデルのパフォーマンスを評価および改善するために利用できる重要なツールは、高度なメトリクスだけではありません。データ準備、特徴量エンジニアリング、特徴量重要度分析は、モデル構築に不可欠な手法です。これらのアクティビティは、生データから有意義なインサイトを抽出し、モデルのパフォーマンスを向上させる上で重要な役割を果たし、より堅牢で洞察に富んだ結果につながります。 データ準備と特徴量エンジニアリング 特徴量エンジニアリングは、生データから新しい変数 (機能) を選択、変換、作成するプロセスであり、ML モデルのパフォーマンスを向上させる上で重要な役割を果たします。入手可能なデータから最も関連性の高い変数や特徴量を選択するには、モデルの予測に寄与しない無関係な特徴量や冗長な特徴量を削除する必要があります。データの特徴量を適切な形式に変換するには、スケーリング、正規化、欠損値の処理が含まれます。最後に、既存のデータから新しい機能を作成するには、数学的な変換、さまざまな機能の組み合わせや相互作用、またはドメイン固有の知識に基づく新しい機能の作成を行います。 特徴量重要度分析 SageMaker Canvas は、データセット内の各列がモデルに与える影響を説明する特徴量重要度分析を生成します。予測を生成すると、列の影響を確認して、各予測に最も大きな影響を与える列を特定できます。これにより、どの特徴量を最終モデルに含めるべきか、どの特徴量を破棄すべきかについてのインサイトが得られます。列への影響度は、ある列が他の列と比較して予測を行う際にどの程度重要かを示すパーセンテージスコアです。列への影響が 25% の場合、Canvasは予測結果への影響を、その列が 25%、その他の列が 75% と重み付けします。 モデルの精度を向上させるためのアプローチ モデルの精度を向上させる方法は複数ありますが、データサイエンティストと機械学習担当者は通常、前述のツールとメトリクスを使用して、このセクションで説明した2つのアプローチのうちのどちらか1つを使用します。 モデル中心のアプローチ このアプローチでは、データは常に同じままで、望ましい結果が得られるようにモデルを繰り返し改善するために使用されます。このアプローチで使用されるツールには以下が含まれます。 関連する複数の機械学習アルゴリズムを試してみる。 アルゴリズムとハイパーパラメーターのチューニングと最適化。 さまざまなモデルアンサンブル法。 事前トレーニング済みモデルの使用 (SageMaker には ML 担当者に役立つさまざまな 組み込みモデルや事前トレーニング済みモデル が用意されています)。 AutoML は SageMaker Canvas が舞台裏で ( Amazon SageMaker Autopilot を使用して) 行っていることであり、上記のすべてを網羅しています。 データ中心のアプローチ このアプローチでは、データ準備、データ品質の向上、およびパフォーマンスの向上を目的としたデータの反復修正に重点が置かれています。 モデルのトレーニングに使用したデータセットの統計情報の調査 (探索的データ分析 (EDA) とも呼ばれます)。 データ品質の向上 (データクリーニング、欠損値の補完、外れ値の検出と管理)。 特徴量の選択。 特徴量エンジニアリング。 データ拡張。 Canvasにおけるモデルパフォーマンスの向上 まず、データ中心のアプローチから始めます。モデルプレビュー機能を使用して最初の EDA を実行します。これにより、データ拡張、新しいベースラインの生成、そして最終的に標準ビルド機能を使用したモデル中心のアプローチによる最適なモデルの作成に使用できるベースラインが得られます。 この記事では通信携帯電話会社の 合成データセット を使用します。このサンプルデータセットには 5,000 件のレコードが含まれており、各レコードには 21 の属性を使用して顧客プロファイルを記述しています。詳細については、「 Amazon SageMaker Canvas を使用したコーディング不要の機械学習による顧客離れの予測 」を参照してください。 データ中心のアプローチによるモデルプレビュー 最初のステップとして、データセットを開き、予測する列である Churn? を選択します。そして、 Preview model を選択してプレビューモデルを生成します。 Preview model ペイン には、プレビューモデルの準備が整うまでの進捗状況が表示されます。 モデルの準備が整うと、SageMaker Canvas は特徴量重要度分析を生成します。 最後に、モデルプレビューの作成が完了すると、 Preview model ペイン にはモデルへの影響を含む列のリストが表示されます。これらの情報は、その特徴量が予測にどの程度関連しているかを理解するのに役立ちます。 Column impact は、ある列が他の列と比較して予測を行う際にどの程度重視されているかを示すパーセンテージスコアです。次の例では、「Night Calls」列について、SageMaker Canvas はその列について 4.04%、その他の列では 95.9% と重み付けしています。値が大きいほど、影響も大きくなります。 ご覧のとおり、プレビューモデルの精度は 95.6% です。データ中心のアプローチを使用してモデルのパフォーマンスを改善してみましょう。データ準備を行い、特徴量エンジニアリングの手法を使用してパフォーマンスを向上させます。 次のスクリーンショットに示すように、「Phone」列と「State」列が予測に与える影響は他の列に比べてはるかに小さいことがわかります。そのため、この情報を次のフェーズであるデータ準備のインプットとして使用します。 SageMaker Canvas には ML データ変換が用意されており、これを使用してデータをクレンジング、変換、モデル構築の準備を行うことができます。これらの変換はコードを書くことなくデータセットに使用でき、モデルレシピに追加されます。モデルレシピとは、モデル構築前にデータに対して実行されたデータ準備の記録です。 使用するデータ変換は、モデルを構築するときに入力データを変更するだけで、データセットや元のデータソースは変更しないことに注意してください。 SageMaker Canvas には、構築用のデータを準備するための以下の変換方法が用意されています。 日時抽出 列削除 行フィルター 関数と演算子 行の管理 列名変更 行削除 値の置換 時系列データの再サンプリング まず、予測にほとんど影響がないことがわかった列を削除することから始めましょう。 例えば、このデータセットでは、電話番号はアカウント番号と同等です。他のアカウントが解約される可能性を予測する上では役に立たず、有害ですらあります。同様に、顧客の状態はモデルにあまり影響しません。Phone 列と State 列を削除して、 Column name の下にあるチェックボックスの選択を解除しましょう。 次に、追加のデータ変換と特徴量エンジニアリングを実行してみましょう。 例えば、以前の分析では、顧客への請求金額が解約に直接影響することがわかりました。そこで、日中、夜、深夜、の国際電話の「料金」、「通話時間」、「通話回数」を組み合わせて、お客様への合計請求額を計算する新しい列を作成してみましょう。そのためには、SageMaker Canvas のカスタム数式を使用します。 まず Functions を選択し、次に数式のテキストボックスに次のテキストを追加します。 (Day Calls*Day Charge*Day Mins)+(Eve Calls*Eve Charge*Eve Mins)+(Night Calls*Night Charge*Night Mins)+(Intl Calls*Intl Charge*Intl Mins) 新しい列に「合計料金」など適切な名前 を付け、プレビューが生成されたら Add を選択します。これで、モデルレシピは次のスクリーンショットのようになるはずです。 このデータ準備が完了したら、新しいプレビューモデルをトレーニングして、モデルが改善されたかどうかを確認します。もう一度 Preview model を選択すると、右下のペインに進行状況が表示されます。 トレーニングが終了すると、予測精度の再計算が行われ、新しい  Column impact も作成されます。 最後に、プロセス全体が完了すると、前に見たのと同じペインが、新しいプレビューモデルの精度で表示されます。モデルの精度が 0.4% (95.6% から 96% に) 向上したことがわかります。 MLはモデルのトレーニングプロセスにはある程度の確率性を導入しており、ビルドごとに異なる結果につながる可能性があるため、本記事の画像の数値は実際の数値とは異なる場合があります。 モデル中心のアプローチによるモデル作成 Canvasには、モデルを作成するための2つのオプションがあります。 Standard build – 速度を犠牲にして精度を高める最適化されたプロセスから最適なモデルを構築します。Auto-ML を使用して、モデルの選択、ML のユースケースに関連するさまざまなアルゴリズムの試行、ハイパーパラメータの調整、モデルの説明可能性レポートの作成など、ML のさまざまなタスクを自動化します。 Quick build – Standard build に比べてわずかな時間で単純なモデルを構築できますが、精度はスピードと引き換えられます。Quick Build は、データの変更がモデルの精度に与える影響をより迅速に把握するために反復試行を行う場合に役立ちます。 引き続き Standard build アプローチを使用してみましょう。 Standard build 前述したように、Standard build は、精度を最大化するために最適化されたプロセスから最適なモデルを構築します。 顧客離れ予測モデルのビルドプロセスには約45分かかります。この間、Canvasは何百もの候補パイプラインをテストし、最適なモデルを選択します。次のスクリーンショットでは、予想されるビルド時間と進行状況を確認できます。 標準のビルドプロセスでは、ML モデルによってモデルの精度が 96.903% に向上しました。これは大幅な改善です。 advanced metrics を見る Analyze タブを使用してモデルを調べてみましょう。 Scoring タブで Advanced metrics を選択します。 このページでは、F1スコア、正解率、精度、再現率、AUCなどの高度なメトリクスと混同行列を組み合わせて表示します。 予測の生成 メトリクスが適切に表示されたので、 Predict タブでバッチ予測または単一 (リアルタイム) 予測のいずれかでインタラクティブな予測を実行できます。 次の 2 つの選択肢があります。 このモデルを使用して、バッチ予測または単一予測を実行します。 モデルを Amazon SageMaker Studio に送信して、データサイエンティストと共有します。 後片付け 記事の作業を実施後、 セッション料金 が発生しないようにするには、SageMaker Canvas からログアウトしてください。 まとめ SageMaker Canvas には、コーディングや専門的なデータサイエンスや ML の専門知識を必要とせずにモデルの構築と精度を評価してパフォーマンスを向上させることができる強力なツールが用意されています。顧客離れ予測モデルを作成した例で見てきたように、これらのツールをデータ中心のアプローチと高度なメトリクスを使用するモデル中心のアプローチの両方と組み合わせることで、ビジネスアナリストは予測モデルを作成して評価できます。また、ビジュアルインターフェイスを使用すると、正確な ML 予測を自分で生成できます。参考文献に目を通し、これらのアプローチが他の種類のML問題にも適用可能であることを確認してみてください。 参考文献 Predict customer churn with no-code machine learning using Amazon SageMaker Canvas Build, Share, Deploy: how business analysts and data scientists achieve faster time-to-market using no-code ML and Amazon SageMaker Canvas Customizing and reusing models generated by Amazon SageMaker Autopilot Amazon SageMaker Canvas Immersion Day Workshop Manage AutoML workflows with AWS Step Functions and AutoGluon on Amazon SageMaker 著者について Marcos は、米国フロリダ州を拠点とする AWS シニア機械学習ソリューションアーキテクトです。その職務では、米国のスタートアップ企業のクラウド戦略を導き、支援し、リスクの高い問題に対処し、機械学習ワークロードを最適化する方法に関するガイダンスを提供しています。クラウドソリューション開発、機械学習、ソフトウェア開発、データセンターインフラストラクチャなど、テクノロジーに関する 25 年以上の経験があります。 Indrajit は AWS エンタープライズシニアソリューションアーキテクトです。彼の役職では、クラウドの導入を通じて顧客がビジネス上の成果を達成できるよう支援しています。マイクロサービス、サーバーレス、API、イベント駆動型パターンに基づいた最新のアプリケーションアーキテクチャを設計しています。DataOps と MLOps のプラクティスとソリューションを採用することで、顧客と協力してデータ分析と機械学習の目標を実現できるよう努めています。Indrajit は、サミットや ASEAN ワークショップなどの AWS の公開イベントで定期的に講演を行い、いくつかの AWS ブログ記事を公開しているほか、AWS でのデータや機械学習に焦点を当てた顧客向けの技術ワークショップも企画しています。 翻訳は Solution Architect の Masanari Ikuta が担当しました。原文は こちら です。