Amazon FSx for NetApp ONTAP ファイルシステムを、これまでよりも最大 9 倍高速に作成できるようになりました。このサービスで既にそうであるように、ファイルシステムはフルマネージド型で、プライマリストレージへのレイテンシーはミリ秒未満、キャパシティプールへのレイテンシーは数十ミリ秒です。この新たなレベルのパフォーマンスにより、要求の厳しい Electronic Design Automation (EDA)、視覚効果 (VFX)、統計計算のワークロード (ほんの数例を挙げると) をさらにクラウドに移行できるようになります。 既存の FSx for ONTAP スケールアップ ファイルシステムは、アクティブ/パッシブ高可用性 (HA) 設定のサーバーペアで動作し、最大 4 GBps のスループットと 192 TiB の SSD ストレージをサポートできます。このサーバーペアは、1 つのアベイラビリティーゾーンの異なるフォールトドメインにデプロイすることも、2 つのアベイラビリティーゾーンにデプロイして、アベイラビリティーゾーンが使用できない場合でも継続的に利用できるようにします。 本日のリリースにより、2～6 組の HA ペアで駆動する ONTAP ファイルシステム向けのスケールアウト FSx を作成できるようになりました。スケールアップとスケールアウトのファイルシステムの仕様は次のとおりです (ファイルシステムを作成するときに、それぞれに希望の値を指定できるため、これらはすべて「最大」と記載されています)。 デプロイタイプ 読み取り スループット 書き込み スループット SSD IOPS SSD ストレージ アベイラビリティーゾーン スケールアップ 最大 4 Gbps 最大 1.8 Gbps 最大 16 万 最大 192 TiB シングルまたはマルチ スケールアウト 最大 36 Gbps 最大 6.6 Gbps 最大120 万 最大 1 PiB シングル 次のように、ファイルシステムに指定するスループット量によって、実際のサーバー設定が決まります。 指定スループット デプロイ タイプ HA ペア スループット (サーバーあたり) SSD ストレージ (サーバーあたり) SSD IOPS (サーバーあたり)  4 GBps 以下 スケールアップ シングル 最大 4 GBps の読み取り 最大 1.1 GBps の書き込み (シングル AZ) 最大 1.8 GBps の書き込み (マルチ AZ) 1～192 TiB 最大 16 万 4 GBps 超 スケールアウト 最大 6 最大 6 GBps の読み取り 最大 1.1 GBps の書き込み 1～512 TiB 最大 20 万 選択肢の詳細については、 Amazon FSx for NetApp ONTAP のパフォーマンス をご覧ください。 スケールアウトファイルシステムを作成する AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) を使用するか、Amazon FSX CreateFileSystem 関数を呼び出すコードを記述することで、スケールアウトファイルシステムを作成できます。コンソールを使用して、まず Amazon FSx for NetApp ONTAP を選択します。 [Standard create] (スタンダード作成) を選択し、名前を入力し、 シングル AZ 配置を選択し、希望する SSD ストレージキャパシティを入力します。推奨スループットキャパシティを受け入れるか、ドロップダウンから値を選択するか、値を入力してオプションを確認することができます (これについては後ほど詳しく説明します)。 ドロップダウンには便利な魔法の機能があります。希望するスループットキャパシティを入力すると、1 つまたは複数のオプションが表示されます。 コンソールには、希望するスループットキャパシティと同じ数のオプションがいくつか表示されることがあります。ワークロードに適した選択を行う際に役立つガイドラインを以下に示します。 低スループット – 4 GBps 以下のオプションを選択した場合、1 つの HA ペアで実行することになります。これは、高いスループットが必要ない場合に選択する最も簡単なオプションです。 高スループットおよび/または高ストレージ – 最大スループットは、プロビジョニングする HA ペアの数に応じてスケールします。また、ペアの数が多いオプションを選択することで、余裕を最大限に活用し、プロビジョニングされたストレージを将来増やすことができます。 通常どおり、残りのオプションを選択して値を入力し、 [Next] (次へ) をクリックして設定を確認します。作成後に編集できない属性について適切な選択をしたことを確認し、 [Create file system] (ファイルシステムの作成) をクリックします。 休憩を取り上の階で何が起きているのかを確認し、犬に餌をやります。戻ってくると新しい 2 TB のファイルシステムが準備完了です。 ストレージキャパシティを増やしたり、6 時間ごとにプロビジョンド IOPS を変更したりできます。 現時点では、ファイルシステムが複数の HA ペアを使用している場合、プロビジョニングされたスループットキャパシティを作成後に変更することはできません。 今すぐご利用いただけます スケールアウトファイルシステムは、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、欧州 (アイルランド) の各リージョンで利用でき、今すぐ作成して使用を開始できます。 詳細はこちら Amazon FSx for NetApp ONTAP Amazon FSx for NetApp ONTAP パフォーマンス – Jeff ; 原文は こちら です。

11月26日、 Amazon FSX for OpenZFS に、ファイルシステムからアカウントの別のファイルシステムにスナップショットを送信する機能が追加されました。 1 回の API 呼び出しまたは CLI コマンドでコピーをトリガーでき、あとは弊社が処理します。 rsync のようなコマンドを使って転送の状態を監視する必要はありません。サービスがお客様に代わってコピーを処理します。潜在的なネットワークの中断を管理し、転送が完了するまで自動的に再試行します。OpenZFS のネイティブな 送信 および 受信 機能を使用して、ブロックレベルでデータを段階的に転送します。 この新機能により、例えば、テスト環境や開発環境をより迅速かつ簡単に作成できるようになるため、 俊敏性 を維持できます。また、リードレプリカの管理を簡素化して パフォーマンス のスケールアウトを実現することでパフォーマンスが向上します。 Amazon FSX for OpenZFS は、オープンソースの OpenZFS ファイルシステム上に構築されたフルマネージド型ファイルシステムを起動、実行、スケールできるフルマネージド型ファイルストレージサービスです。FSX for OpenZFS を使用すると、アプリケーションやデータの管理方法を変更することなく、オンプレミスの ZFS ファイルサーバーを簡単に移行でき、高性能でデータ集約型の新しいアプリケーションをクラウド上に構築できます。 スナップショット は ZFS ファイルシステムの最も強力な機能の 1 つです。スナップショットは、ファイルシステムまたはボリュームの読み取り専用コピーです。スナップショットはほぼ瞬時に作成でき、最初はストレージプール内の追加のディスク容量を消費しません。スナップショットが作成されると、そのスペースは最初にスナップショットとファイルシステムの間で共有され、場合によっては以前のスナップショットと共有されます。ファイルシステムが変更されると、以前に共有されていたスペースはスナップショット固有のものになります。スナップショットは、古いデータを引き続き参照することで消費するディスク容量が増加するため、スペースが解放されなくなります。スナップショットは、非常に大規模なファイルシステムでも、オンデマンドでほぼ瞬時にロールバックできます。スナップショットを複製して新しいボリュームを作成することもできます。 スナップショットはブロックレベルのコピーです。変更されたファイルを検出するためにシステムが何百万ものファイルをトラバースしなければならない従来のファイルレベルのコピーよりも転送が効率的です。また、スナップショットはブロックレベルで増分なので、インクリメンタルスナップショットを転送する方が、ファイルベースのインクリメンタルコピーを転送するよりも効率的です。それには、前回のスナップショット以降に変更されたブロックのみが含まれます。 ZFS スナップショットのオンデマンドレプリケーションにより、基盤となるインフラストラクチャを気にすることなく、OpenZFS のネイティブ 送受信 機能を使用してテラバイトのデータを転送できます。ネットワークの中断やその他の種類のエラーの検出および管理は当社が行い、ファイルシステム間でデータを簡単に複製できるようにします。 この新機能を使用する主なユースケースは 2 つあります。 デベロッパーや品質保証 (QA) エンジニアは、オンデマンドのスナップショットを開発環境やテスト環境に送信することがあります。これにより、本番データを扱うことができるため、正確なテスト結果と開発結果が得られます。最新のスナップショットをテストの開始点として一貫して使用することで、開発プロセスおよびテストプロセスの効率が向上します。 データエンジニアは、オンデマンドレプリケーションを使用して、データセットで並行実験を実行することがあります。アプリケーションが大規模なデータセットを処理するとします。同じベースデータセットで複数のバージョンのデータ処理アルゴリズムを実行して、ユースケースに最適なチューニングを見つけたいと考えています。オンデマンドデータレプリケーションを使うと、ファイルシステムの同一のコピーを複数作成し、各実験を並行して実行できます。 仕組みを見てみましょう このデモを準備するために、 AWS マネジメントコンソール の FSx for OpenZFS セクション を使用します。まず、Amazon FSx for OpenZFS ボリュームを 2 つ作成します。次に、2 つのファイルシステム ( /zfs-filesystem1 と /zfs-filesystem2 ) を 1 つの Amazon Linux インスタンスに マウント します。1 つ目のボリュームでファイルを準備しましたが、オンデマンドレプリケーション後に 2 つ目のボリュームでも同じファイルが見つかるはずです。 2 つのボリューム間でデータを同期するには、 コンソールのスナップショットセクション に移動します。次に、[ スナップショットをコピーしてボリュームを更新 ] を選択します。また、スナップショットを新しい ZFS ボリュームにコピーすることもできます。 [Copy snapshot and update volume] (スナップショットのコピーとボリュームの更新) ページで、コピー先の ファイルシステム と ボリューム を選択します。ソーススナップショットも確認します。 [Source snapshot copy strategy] (ソーススナップショットのコピー方法) を選択し、フルコピーまたは増分コピーをリクエストします。準備ができたら、 [Update] (更新) を選択します。 しばらくすると、転送するデータの量によって異なりますが、コピー先ボリュームに新しいスナップショットが一覧表示されていることが分かります。このデモシナリオでは、ほんの数秒で完了しました。 Linux インスタンスに戻り、2 つ目のマウントポイント /zfs-snapshot にあるコンテンツを一覧表示します。牛形の ASCII アートが 2 つ目のファイルシステムにありますね 。 また、新しい FSx API ( CopySnapshotAndUpdateVolume と CopySnapshotAndCreateVolume ) を使用して、オンデマンド転送を自動化することもできます。 継続的な定期レプリケーションを設定するために、提供されている CloudFormation テンプレート を使用して自動レプリケーションスケジュールを作成します。デプロイすると、システムはソースファイルシステム上のボリュームのスナップショットを定期的に取得し、レプリケート先ファイルシステム上のボリュームへの増分レプリケーションを実行します。例えば、テスト目的で、開発ファイルシステムへのレプリケーションを 15 分に 1 回実行するようにスケジュールできます。 利用可能なリージョンと料金 この新機能は、FSx for OpenZFS が利用できるすべての AWS リージョンでご利用いただけます。 追加費用はかかりません。AWS は、アベイラビリティーゾーン間のネットワークデータ転送に通常の料金を請求します。 リモートファイルシステムが使用するストレージ量に対して、標準の FSx for OpenZFS 料金が発生します。 Amazon FSX for OpenZFS の新しいオンデマンドレプリケーションにより、ファイルシステムの増分スナップショットをアカウントの新しいボリュームに効率的に転送できます。これにより、デベロッパーや QA エンジニアは本番データのコピーを操作し、データエンジニアはデータセットで並行して実験を行うことができます。 今すぐ、 最初のオンデマンドレプリケーションを構築して設定しましょう 。 — seb 原文は こちら です。

 医療画像の分析は、病気の診断と治療において重要な役割を果たします。機械学習 (ML) 技術を使用してこのプロセスを自動化することで、医療従事者は特定のがん、冠状動脈疾患、眼科疾患をより迅速に診断できます。しかし、この分野の臨床医や研究者が直面する主な課題の 1 つは、画像分類のための ML モデルを構築することの時間と複雑さです。従来の方法では、コーディングの専門知識と ML アルゴリズムに関する幅広い知識が必要であり、これは多くの医療従事者にとって障壁となる可能性があります。 このギャップを解消するために、私たちは Amazon SageMaker Canvas を使用しました。これは臨床医のようなMLの非専門家がコーディングや専門知識を必要とせずに ML モデルを構築してデプロイができるようになるビジュアルツールです。このユーザーフレンドリーなアプローチにより、ML に関連する急な学習曲線がなくなり、臨床医は患者に集中できるようになります。 Amazon SageMaker Canvas には、ML モデルを作成するためのドラッグアンドドロップのインターフェイスが用意されています。臨床医は、使用したいデータを選択し、必要な出力を指定して、モデルが自動的に構築されてトレーニングされるのを見守ることができます。モデルがトレーニングされると、正確な予測が生成されます。 このアプローチは、ML を使用して診断と治療に関する意思決定を改善したいと考えている臨床医にとって理想的です。Amazon SageMaker Canvas を使えば、ML の専門家でなくても、ML の力を利用して患者を助けることができます。 医療画像の分類は、患者の転帰と医療効率に直接影響します。医療画像をタイムリーかつ正確に分類することで、疾患の早期発見が可能になり、効果的な治療計画とモニタリングに役立ちます。さらに、Amazon SageMaker Canvas のようなアクセスしやすいインターフェイスを通じて ML を民主化することで、幅広い技術的背景を持たない医療従事者を含め、幅広い医療従事者が医療画像分析の分野に貢献できるようになります。この包括的なアプローチは、コラボレーションと知識共有を促進し、最終的には医療研究の進歩と患者ケアの向上につながります。 この投稿では、Amazon SageMaker Canvas が医療画像を分類する機能について説明し、その利点について説明し、医療診断への影響を実証する実際のユースケースに焦点を当てます。 ユースケース 皮膚がんは重篤で潜在的に致命的な疾患であり、早期に発見されればされるほど、治療が成功する可能性が高くなります。統計的には、皮膚がん（基底細胞がんや扁平上皮がんなど）は最も一般的ながんの種類の1つであり、毎年 世界中 で数十万人が死亡しています。皮膚細胞の異常な成長によって現れます。 ただし、早期診断により回復の可能性が大幅に高まります。さらに、外科療法、X線療法、または化学療法が不要になったり、全体的な使用量が減少したりして、医療費の削減に役立つ可能性があります。 皮膚がんの診断プロセスは、皮膚病変の一般的な形状、大きさ、色の特徴を検査するダーモスコピー [1] と呼ばれる検査から始まります。その後、疑わしい病変は、がん細胞型を確認するために、さらにサンプリングと組織学的検査を受けます。医師は、視覚的な検出から始めて、複数の方法で皮膚がんを検出します。米国皮膚科学研究センターは、 ABCD （非対称性、境界、色、直径）と呼ばれる黒色腫の考えられる形状に関するガイドを開発し、医師が疾患の初期スクリーニングに使用しています。疑わしい皮膚病変が見つかった場合、医師は皮膚の目に見える病変の生検を行い、それを顕微鏡で調べて、良性または悪性の診断と皮膚がんの種類を調べます。コンピュータービジョンモデルは、疑わしいほくろや病変を特定するうえで重要な役割を果たします。これにより、より早く、より正確な診断が可能になります。 がん検出モデルの作成は、以下に概説するように、複数の段階からなるプロセスです。 健康な皮膚やさまざまな種類のがん性または前がん性病変のある皮膚から大量の画像データセットを収集します。このデータセットは、正確性と一貫性を確保するために慎重にキュレーションする必要があります。 コンピュータービジョン技術を使用して画像を前処理し、健康な皮膚とがん性のある皮膚を区別するための適切な画像を抽出します。 教師あり学習アプローチを使用して、前処理された画像で ML モデルをトレーニングし、モデルにさまざまな肌タイプを区別するように教えます。 精度や再現率などのさまざまな指標を使用してモデルのパフォーマンスを評価し、がん性皮膚を正確に識別し、誤検知を最小限に抑えるようにします。 このモデルを、皮膚科医やその他の医療従事者が皮膚がんの検出と診断に役立つ使いやすいツールに統合します。 全体として、皮膚がん検出モデルをゼロから開発するプロセスには、通常、多大なリソースと専門知識が必要です。このような場合に、Amazon SageMaker Canvas はステップ 2 から 5 までの時間と労力を簡素化するのに役立ちます。 ソリューションの概要 コードを書かずに皮膚がんのコンピュータービジョンモデルを作成する方法を実証するために、Harvard Dataverse が公開しているダーモスコピー検査用の皮膚がん画像データセットを使用します。 HAM10000 にある10,015枚のダーモスコピー画像からなるデータセットを使用して、皮膚がんのクラスを予測する皮膚がん分類モデルを構築します。データセットに関するいくつかの重要なポイント: データセットは、学術的な ML を目的としたトレーニングセットとして機能します。 色素性病変の分野におけるすべての重要な診断カテゴリの代表的なコレクションが含まれています。 データセットには、日光角化症と上皮内がん/ボーエン病（akiec）、基底細胞がん（bcc）、良性角化症様病変（日光性黒子/脂漏性角化症および扁平苔癬様角化症、bkl）、皮膚線維腫（df）、悪性黒色腫 (mel)、色素性母斑 (nv) および血管病変 (血管腫、被角血管腫、化膿性肉芽腫および出血、vasc) データセット内の病変の50％以上が組織病理学（ヒストー）によって確認されています。 残りの症例の根拠は、フォローアップ検査（ follow_up ）、専門家の合意（コンセンサス）、または生体内共焦点顕微鏡による確認（共焦点）によって決定されます。 データセットには複数の画像を含む病変が含まれており、 HAM10000_metadata ファイル内の lesion_id 列を使用して追跡できます。 Amazon SageMaker Canvas を使用してコードを記述することなく、複数の皮膚がんカテゴリの画像分類を簡素化する方法を紹介します。SageMaker Canvas の画像分類では、皮膚病変の画像が与えられると、その画像は良性またはがんの可能性のある画像に自動的に分類されます。 前提条件 ステップセクションで説明されているリソースを作成する権限を持つ AWS アカウントへのアクセス。 Amazon SageMaker を使用するための完全な権限を持つ AWS アイデンティティおよびアクセス管理 ( AWS IAM ) ユーザー。 ウォークスルー SageMaker ドメインのセットアップ ここ で説明する手順を使用して、Amazon SageMaker ドメインを作成します。 HAM10000 データセットをダウンロードします。 データセットのセットアップ Amazon Simple Storage Service ( Amazon S3 ) バケットをユニークな名前 ( image-classification-<ACCOUNT_ID> ) で作成します。ACCOUNT_ID はお客様固有の AWS アカウント番号です。 Figure 1 バケットの作成 このバケットに training-data と test-data という 2 つのフォルダーを作成します。 Figure 2 フォルダーの作成 トレーニングデータで、データセットで特定された皮膚がんのカテゴリーごとに、 akiec 、 bcc 、 bkl 、 df 、 mel 、 nv 、 vasc の 7 つのフォルダーを作成します。 Figure 3 フォルダーの一覧 データセットには多数の病変の画像が含まれており、 HAM10000_metadata ファイル内の lesion_id-column で追跡できます。 lesion_id-column を使用して、対応する画像を右側のフォルダーにコピーします (つまり、分類ごとに100枚の画像から始めることができます)。 Figure 4 インポートするオブジェクトのリスト (サンプル画像) Amazon SageMaker Canvas を使用する コンソールの Amazon SageMaker サービスに移動し、リストから Canvas を選択します。Canvas ページに移動したら、 Open Canvas ボタンを選択してください。 Figure 5 Canvas に移動 Canvas ページが表示されたら、 My models を選択し、画面の右側にある New model を選択します。 Figure 6 モデルの作成 新しいポップアップウィンドウが開き、モデルの名前として image_classify という名前を付け、 Problem type で画像解析を選択します。 データセットをインポートする 次のページで、 Import an Image dataset を選択し、ポップアップボックスでデータセットに image_classify という名前を付け、 Create ボタンを選択してください。 Figure 7 データセットの作成 次のページで、 Data Source を Amazon S3 に変更します。画像を直接アップロードすることもできます (つまり、 Local upload )。 Figure 8 S3 バケットからのインポート Amazon S3 を選択すると、アカウントにあるバケットのリストが表示されます。データセットをサブフォルダーに保持する親バケット (例: image-classification-<ACCOUNT_ID> ) を選択した後に training-data フォルダを選択し、 Create dataset ボタンを選択します。これにより、Amazon SageMaker Canvas はフォルダ名に基づいて画像にすばやくラベルを付けることができます。 データセットが正常にインポートされると、ステータス列の値が Processing から Ready に変わります。 次に、ページの下部にある Select dataset を選択してデータセットを選択します。 モデルを作成する Build ページに、Amazon S3 のフォルダ名に従ってデータがインポートされ、ラベルが付けられているのがわかります。 Figure 9 Amazon S3 のデータのラベリング Quick build ボタン (つまり、以下の画像で紫で強調表示されているコンテンツ) を選択すると、モデルをビルドするための 2 つのオプションが表示されます。1 つ目は Quick build で、2 つ目は Standard build です。名前が示すように、クイックビルドオプションは精度よりもスピードが優先され、モデルのビルドには約 15 〜 30 分かかります。標準ビルドはスピードよりも正確さを優先し、モデル構築が完了するまでに 45 分から 4 時間かかります。Standard build は、ハイパーパラメータのさまざまな組み合わせを使用して実験を実行し、バックエンドで (SageMaker Autopilot 機能を使用して) 多数のモデルを生成してから、最適なモデルを選択します。 Standard build を選択してモデルの構築を開始します。完了するまでに約 2 ～ 5 時間かかります。 Figure 10 Standard build の実行 モデルの構築が完了すると、Figure 11 に示すような推定精度を確認できます。 Figure 11 モデルの推論 Scoring タブを選択すると、モデルの正解率 (accuracy) に関する洞察が得られるはずです。また、 Scoring タブの Advanced metrics ボタンを選択すると、適合率 (precision)、再現率 (recall)、F1 値（適合率と再現率の調和平均）が表示されます。 Amazon SageMaker Canvas に表示される高度なメトリクス（Advanced metrics）は、モデルがデータに対して数値、カテゴリ、画像、テキスト、または時系列予測のどれを実行するかによって異なります。この場合、精度よりも再現率が重要であると考えています。なぜなら、がんの検出を見逃すことは、正しい検出よりもはるかに危険だからです。2 カテゴリ予測や 3 カテゴリ予測などのカテゴリ予測は、分類の数学的概念を指します。 高度なメトリクス の再現率は、すべての実際の陽性（TP + 偽陰性）のうち、真陽性（TP）の割合です。モデルによって陽性と正しく予測された陽性インスタンスの割合を測定します。高度なメトリクスの詳細については、こちらの「 あなたのモデルは最適ですか？ Amazon SageMaker Canvas の高度なメトリクス deep dive 」を参照してください。 Figure 12 高度なメトリクス これで、Amazon SageMaker Canvas でのモデル作成ステップは完了です。 モデルをテストする Predict ボタンを選択すると、 Predict ページに移動します。Predict ページでは、 Single prediction または Batch prediction を使用して独自の画像をアップロードできます。お好みのオプションを設定し、 Import を選択して画像をアップロードし、モデルをテストしてください。 Figure 13 自分の画像を使ったテスト まず、単一画像での予測から始めましょう。 Single predict を使用していることを確認し、 Import image を選択します。これにより、 Amazon S3 から画像をアップロードするか、 Local upload を実行するかを選択できるダイアログボックスが表示されます。この例では、 Amazon S3 を選択し、テストイメージがあるディレクトリを参照して、任意のイメージを選択します。次に、 Import data を選択します。 Figure 14 Single image prediction 選択すると、 Generating prediction results という画面が表示されます。以下に示すように、数分で結果が出るはずです。 それでは、バッチ予測を試してみましょう。 Run predictions で Batch prediction を選択し、 Manual から Create dataset を選択し、 BatchPrediction という名前を付けて Create ボタンを押します。 Figure 15 Single image prediction の結果 次のウィンドウで、Amazon S3 アップロードを選択したことを確認し、テストセットがあるディレクトリを参照して、 Import data ボタンを選択します。 Figure 16 Batch image prediction 画像が Ready になったら、作成したデータセットのラジオボタンを選択し、Generating predictions を選択します。これで、バッチ予測のステータスが Generating predictions になっているはずです。結果が出るまで数分待ちましょう。 ステータスが Ready になったら、データセット名を選択すると、すべての画像の詳細な予測を表示するページに移動します。 Figure 17 Batch image prediction の結果 バッチ予測のもう 1 つの重要な機能は、結果を検証できることと、予測を zip または csv ファイルでダウンロードして、さらに使用または共有できることです。 Figure 18 Download prediction これで、Amazon SageMaker Canvas を使用してモデルを作成し、トレーニングし、その予測をテストすることができたはずです。 クリーンアップ 左側のナビゲーションペインで Log out を選択して Amazon SageMaker Canvas アプリケーションからログアウトし、 SageMaker Canvas ワークスペースのインスタンス時間 の消費を停止し、すべてのリソースを解放します。 引用 [1]Fraiwan M, Faouri E. On the Automatic Detection and Classification of Skin Cancer Using Deep Transfer Learning . Sensors (Basel). 2022 Jun 30;22(13):4963. doi: 10.3390/s22134963. PMID: 35808463; PMCID: PMC9269808. まとめ 本記事では、ML 技術を用いた医療画像解析が皮膚がんの診断を迅速化する方法と、他の疾患の診断への応用について紹介しました。ただし、画像分類用の ML モデルの構築は、多くの場合、複雑で時間がかかり、コーディングの専門知識と ML の知識が必要です。Amazon SageMaker Canvas は、コーディングや専門的な ML スキルを必要としないビジュアルインターフェイスを提供することで、この課題に対処しました。これにより、医療従事者は急な学習なしで ML を使用できるようになり、患者のケアに集中できるようになります。 がん検出モデルを開発する従来のプロセスは、面倒で時間がかかります。これには、精選されたデータセットの収集、画像の前処理、ML モデルのトレーニング、パフォーマンスの評価、医療従事者向けの使いやすいツールへの統合が含まれます。Amazon SageMaker Canvas は前処理から統合までのステップを簡素化し、皮膚がん検出モデルの構築に必要な時間と労力を削減しました。 この投稿では、医療画像分類において、Amazon SageMaker Canvas が非常に有効であることを説明しました。私たちが調査した説得力のあるユースケースの 1 つは、皮膚がんの検出と、早期診断によって治療成績が大幅に向上し、医療費が削減されることが多いというものでした。 モデルの精度は、トレーニングデータセットのサイズや採用するモデルの種類などの要因によって異なる可能性があることを認識することが重要です。これらの変数は、分類結果のパフォーマンスと信頼性を決定する役割を果たします。 Amazon SageMaker Canvas は、医療従事者がより正確かつ効率的に病気を診断するのを支援する非常に貴重なツールとして役立ちます。ただし、医療従事者の専門知識や判断に取って代わるものではないことに注意することが重要です。むしろ、能力を強化し、より正確で迅速な診断を可能にすることで、彼らに力を与えます。意思決定プロセスにおいて人的要素は依然として不可欠であり、医療専門家と Amazon SageMaker Canvas などの人工知能 (AI) ツールとのコラボレーションは、最適な患者ケアを提供する上で極めて重要です。 翻訳はソリューションアーキテクト菊地が担当しました。原文は こちら です。 著者について Ramakant Joshi は AWS ソリューションアーキテクトで、分析とサーバーレスドメインを専門としています。ソフトウェア開発とハイブリッドアーキテクチャのバックグラウンドを持ち、お客様のクラウドアーキテクチャの近代化を支援することに情熱を注いでいます。 Jake Wen は AWS のソリューションアーキテクトで、ML、自然言語処理、ディープラーニングへの情熱に基づいています。彼は、企業のお客様がクラウドでのモダナイゼーションとスケーラブルな導入を実現できるよう支援しています。テクノロジーの世界以外でも、ジェイクはスケートボード、ハイキング、エアドローンの操縦に喜びを見出しています。 Sonu Kumar Singh は、分析ドメインを専門とする AWS ソリューションアーキテクトです。彼は、データ主導の意思決定を可能にし、それによってイノベーションと成長を促進することにより、組織の変革をもたらす変化を促進することに尽力してきました。彼は自分がデザインしたり作ったものがポジティブなインパクトをもたらすことを楽しんでいます。AWS では、お客様が AWS の 200 を超えるクラウドサービスから価値を引き出し、クラウドへの移行を支援することを目指しています。 Dariush Azimi は AWS のソリューションアーキテクトで、  機械学習、自然言語処理 (NLP)、Kubernetes によるマイクロサービスアーキテクチャを専門としています。彼の使命は、データストレージ、アクセシビリティ、分析、予測機能を含む包括的なエンドツーエンドソリューションを通じて、組織がデータの可能性を最大限に活用できるようにすることです。

11月26日、クラウド導入の促進、生産性の向上、イノベーションの推進を実現する完全マネージド型のナレッジサービスである AWS re:Post Private を開始します。re: Post Private を使用すると、組織はコラボレーションを強化し、クラウドコミュニティ向けに構築されたナレッジリソースにアクセスできるようになります。これには、AWS の厳選された技術コンテンツとトレーニング資料が含まれています。コンテンツは、組織のメンバーと AWS アカウントチームのためのプライベートディスカッションやコラボレーションフォーラムとともに、組織のユースケースに合わせて特別にカスタマイズされています。 その名前が示すように、 AWS re:Post のプライベートバージョンと考えることができます。プライベートコンテンツとアクセスは、組織と AWS アカウントチームに属するユーザーに限定されます。 あらゆる規模や業種の組織が、業務をクラウドに移行するケースが増えています。クラウドの導入を成功させるには、組織は適切なスキルと構造を備えている必要があります。これを実現する最適な方法は、一元化された Cloud Center of Excellence (CCOE) を設立することです。CCOEは組織の一元的なガバナンス機能であり、ビジネスにおける中央IT、ビジネスユニットIT、およびクラウドサービスの利用者を対象としたコンサルティングの役割を果たします。 ガートナーによると 、CCOEにはガバナンス、仲介、コミュニティという 3 つの柱があります。コミュニティの柱は、利害関係者を集めてクラウドコラボレーションを促進するクラウドコミュニティオブプラクティス（COP）を確立します。COPメンバーとの交流を促進し、クラウド関連のトレーニングやスキル開発を促進することで、組織がクラウドの採用に適応できるよう支援します。 AWS re:Post Private は、社内クラウド実践コミュニティの作成、構築、管理を促進します。これにより、検索や再利用が可能な、スケーラブルなカスタムナレッジベースを構築できます。コミュニティメンバーは、プライベートな質問や回答を投稿したり、記事を公開したりできます。従来のフォーラムの利点であるコミュニティでの議論やコラボレーションと、統合された情報体験の利点を兼ね備えています。 AWS re:Post Private は完全マネージド型のサービスです。複雑なナレッジマネジメントやコラボレーションテクノロジーを運用したり、カスタムソリューションを開発したりする必要はありません。 AWS re:Post Private を使用すると、 AWS サポート とのやり取りも容易になります。プライベートの re: Post から直接サポートケースを作成でき、ケースの解決を組織内のすべての人が参照できる再利用可能な知識に変換できます。 RE: Post Private でデータを保存する AWS リージョンと、アクセスできるユーザーを選択します。保管中および転送中のすべてのデータは、業界標準のアルゴリズムを使用して暗号化されます。管理者は、AWS が管理する暗号化キーを使用するか、お客様が管理および操作するキーを使用するかを選択します。 組織のテクニカルアカウントマネージャーは、プライベート re: Post に自動的に追加されます。組織や AWS チームの中から、自分の AWS ソリューションアーキテクトなど、他の人を招待するように選択できます。AWS アカウントを必要とするのは、プライベートの re: Post 管理者のみです。他のすべてのユーザーは、Microsoft Active Directory などの組織の ID プロバイダーからフェデレーションできます。 re: Post Private を作成する方法を見てみましょう AWS re:Post Private の使用を開始するにあたり、管理者として、ブラウザで AWS マネジメントコンソールの re: POST セクション にアクセスします。 [プライベート re: Post を作成] を選択し、組織、チーム、またはプロジェクト用にプライベートの re: Post を作成するために必要な情報を入力します。 データ暗号化 パラメータと、 サポートケース統合のためのサービスアクセス を有効にするかどうかを選択できます。準備ができたら、 [この re: Post を作成] を選択します。 プライベート re: Post が作成されたら、ユーザーやグループにアクセス権を付与できます。ユーザーとグループの情報は、 AWS IAM アイデンティティセンター とアイデンティティプロバイダーから取得されます。招待されたユーザーには、プライベート re: Post に接続してプロフィールを作成するよう招待するメールが届きます。 管理者側の作業はこれでほぼ終わりです。プライベート re: POST が作成されると、組織の他のメンバーと共有できるエンドポイント名を受け取ります。 Re: Post Private の使い方を見てみましょう 組織の一員として、管理者から受け取ったリンクを使って re: Post Private に移動します。組織の通常のIDサービスで認証すると、re: Post Private のランディングページにリダイレクトされます。 トップメニューでは、タブを選択して、 [質問] 、 [コミュニティ記事] 、 [セレクション] 、 [タグ] 、 [トピック] 、 [コミュニティグループ] 、または [マイダッシュボード] のコンテンツを表示できます。これは、同様の構造を採用した公開ナレッジサービス AWS re:Post を既に使用している場合は、馴染みがあるはずです。 ページのさらに下には、人気のあるトピックと組織内のトップ投稿者が表示されます。また、 質問 や コミュニティグループ にもアクセスできます。検索できるコンテンツを、キーワード、タグ、著者などで検索できます。 料金と利用可能性 組織の AWS re:Post Private は、米国西部 (オレゴン) と欧州 (フランクフルト) の AWS リージョンで作成できます。 AWS re:Post Private は、AWS エンタープライズまたはエンタープライズオンランプサポートプラン をお持ちのお客様にご利用いただけます。re:Post Private では、標準機能を 6 か月間試用できる 無料利用枠 を提供しています。無料利用枠のユーザー数に制限はなく、コンテンツストレージは 10 GB に制限されています。無料ストレージの上限に達すると、プランは有料のスタンダード階層に変換されます。 AWS re:Post Private Standard 階層では、使用した分だけお支払いいただきます。1 か月あたりのユーザー数に基づいて課金されます。詳細については、「 re: Post プライベート価格ページ 」をご覧ください。 今すぐ始めて、組織で AWS re:Post Private を有効にしてください。 — seb 原文は こちら です。

機械学習を使用して統計的な異常や、異常なパターンを検出することにより、データ品質を向上させるのに役立つ新しい AWS Glue Data Quality 機能のプレビューを開始します。コードを書かなくても、データ品質の問題に関する深いインサイト、データ品質スコア、および異常を継続的に監視するために使用できるルールに関する推奨事項が得られます。 データ品質の重要性 AWS のお客様は、データを抽出して変換するためのデータ統合パイプラインをすでに構築しています。データ品質ルールを設定して、生成されるデータが高品質で、ビジネス上の意思決定を正確に行えるようにします。多くの場合、これらのルールは、ビジネスの現状を反映して、特定の時点で選択され固定された基準に基づいてデータを評価します。しかし、ビジネス環境が変化し、データの特性が変化すると、ルールが常に見直され、更新されるとは限りません。 たとえば、初期段階のビジネスで 1 日の売上高が 1 万ドル以上であることを確認するルールを設定できます。ビジネスが成功し成長するにつれて、ルールは時々チェックして更新する必要がありますが、実際にはそうなることはほとんどありません。その結果、売上が予想外に減少した場合、時代遅れのルールは有効にならず、誰も満足しません。 実行中の異常検出 異常なパターンを検出し、データに関するより深いインサイトを得るために、組織は独自の適応型システムを作成しようとしたり、あるいは特定の技術スキルと専門的なビジネス知識を必要とする高価な商用ソリューションに頼ろうとします。 この広範囲に及ぶ課題に対処するため、Glue Data Quality では現在、機械学習 (ML) を利用しています。 Glue Data Quality に新しく追加されたこの便利な機能は、一度起動すると、新しいデータが届くたびに統計を収集し、機械学習と動的しきい値を使用して過去のパターンから学習し、外れ値や異常なデータパターンを調べます。このプロセスでは観測結果が得られ、傾向も視覚化されるため、異常をすばやく理解できます。 また、オブザベーションの一部として推奨ルールも表示され、それらをデータパイプラインに簡単かつ段階的に追加できます。ルールは、データパイプラインの停止などのアクションを強制できます。以前は、静的ルールしか記述できませんでした。これで、しきい値を自動調整する動的ルールと、繰り返し発生するパターンを把握して偏差を特定する 異常検出 ルールを作成できます。ルールをデータパイプラインの一部として使用すると、データフローが停止して、データエンジニアが確認、修正、再開できるようになります。 異常検出を使用するには、ジョブに データ品質評価 ノードを追加します。 ノードを選択し、 [アナライザーの追加] をクリックして統計と列を選択します。 Glue Data Quality は、データから学習してパターンを認識し、観測値を生成して [データ品質] タブに表示します。 そしてビジュアライゼーション: 観察結果を確認した後、新しいルールを追加します。1 つ目は、行数が過去 10 回の実行の最小値と、過去 20 回の実行の最大値の間にあることを確認する適応しきい値を設定します。もう 1 つは、週末に rowCount が異常に多いなど、異常なパターンを探すものです。 プレビューに参加しましょう この新しい機能は現在、以下の AWS リージョンでプレビューでご利用いただけます。米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) 。詳細については、データ品質異常検出]] をご覧ください。 この機能がリリースされたら、詳細なブログ投稿をお楽しみに！ 詳細はこちら データ品質異常検出 – Jeff ; 原文は こちら です。

11月26日、 Application Load Balancer に X509 証明書を提示する相互認証クライアントのサポートについてお知らせします。この新機能により、クライアント認証をロードバランサーにオフロードして、信頼できるクライアントだけがバックエンドアプリケーションと通信できるようになります。この新機能は、強力な暗号化とゼロデイ脆弱性からの保護を提供するAWSのオープンソース Transport Layer Security (TLS) 実装である S2N に基づいて構築されており、開発者はこれを信頼できます。 相互認証 (mTLS) は、オンラインバンキング、自動車、ゲームデバイスなどの企業間 (B2B) アプリケーションで、デジタル証明書を使用してデバイスを認証するためによく使用されます。企業は通常、データやサービスへのアクセスを許可する前に、プライベート認証局 (CA) とともにクライアントを認証します。 お客様は、自分で作成したソリューションまたはサードパーティのソリューションを使用して相互認証を実装しており、追加の時間と管理オーバーヘッドが必要です。これらの顧客は、エンジニアリングリソースを費やしてバックエンドに機能を組み込んだり、最新のセキュリティパッチに対応するようにコードを更新したり、証明書を作成および更新するためのインフラストラクチャに多額の投資を行ったりしています。 Application Load Balancer での相互認証により、完全に管理されたスケーラブルで費用対効果の高いソリューションが実現し、開発者リソースを他の重要なプロジェクトに集中できるようになります。ALB は失効チェックでクライアントを認証し、クライアント証明書情報をターゲットに渡します。この情報はアプリケーションによる承認に使用できます。 ALB での相互認証の開始方法 ALB で相互認証を有効にするには、 Amazon EC2 コンソールの ALB ウィザード で [ Application Load Balancer の作成] を選択します。 リスナーとルーティングのセクション で [HTTPS] を選択すると、セキュリティポリシー、デフォルトサーバー証明書、相互認証をサポートする新しいクライアント証明書処理オプションなど、その他の設定が表示されます。 相互認証 (mTLS) を有効にすると、クライアント証明書を提示するリクエストをリスナーがどのように処理するかを設定できます。これには、Application Load Balancer が証明書を認証する方法と、バックエンドターゲットに送信される証明書メタデータの量が含まれます。 相互認証には 2 つのオプションがあります。 Passthrough オプションは、クライアントから受信したすべてのクライアント証明書チェーンを、HTTP ヘッダーを使用してバックエンドアプリケーションに送信します。MTLS 対応の Application Load Balancer は、ハンドシェイクでクライアント証明書を取得し、TLS 接続を確立して、HTTPS ヘッダーで取得したものをターゲットアプリケーションに送信します。アプリケーションは、クライアントを認証するためにクライアント証明書チェーンを検証する必要があります。 トラストストアで検証 オプションを使用すると、Application Load Balancer とクライアントは互いの ID を検証し、TLS 接続を確立して両者間の通信を暗号化します。新しいトラストストア機能が導入されました。 AWS Private Certificate Authority またはその他のサードパーティ CA によって生成されたルート証明書や中間証明書を含む CA バンドルを信頼するソースとしてアップロードして、クライアント証明書を検証できます。 既存のトラストストアを選択するか、新しいトラストストアを作成する必要があります。トラストストアには、CA、信頼できる証明書、およびオプションで証明書失効リスト (CRL) が含まれます。ロードバランサーはトラストストアを使用してクライアントとの相互認証を行います。 このオプションを使用して新しいトラストストアを作成するには、Amazon EC2 コンソールの左側のメニューで [トラストストア] を選択し、 [トラストストアの作成] を選択します。 PEM 形式の CA 証明書バンドルを選択し、オプションで Amazon Simple Storage Service (Amazon S3) バケットから CRL を選択できます。CA 証明書バンドルは、トラストストアで使用される CA 証明書 (ルートまたは中間) のグループです。CRL は、侵害されたクライアント証明書を CA が取り消し、その失効した証明書を拒否する必要がある場合に使用できます。CA バンドルを置き換えたり、作成後に CRL をトラストストアに追加したり、トラストストアから削除したりできます。 Create-trust-store などの新しい API で AWS コマンドラインインターフェイス (AWS CLI) を使用して、CA 情報をアップロードしたり、Application Load Balancer リスナーで mutual-authentication-mode を設定したり、ユーザー証明書情報をターゲットに送信したりできます。 $ aws elbv2 create-trust-store --name my-tls-name \ --ca-certificates-bundle-s3-bucket channy-certs \ --ca-certificates-bundle-s3-key Certificates.pem \ --ca-certificates-bundle-s3-object-version <version> >> arn:aws:elasticloadbalancing:root:file1 $ aws elbv2 create-listener --load balancer-arn <value> \ --protocol HTTPS \ --port 443 \ --mutual-authentication Mode=verify, TrustStoreArn=<arn:aws:elasticloadbalancing:root:file1> AWS プライベート CA、サードパーティ CA、自己署名 CA など、独自のプライベート CA を既にお持ちの場合は、その CA バンドルまたは CRL を Application Load Balancer のトラストストアにアップロードして、相互認証を有効にすることができます。 Application Load Balancer で相互認証をテストするには、 以下の手順に従って OpenSSL を使用して自己署名 CA バンドルとクライアント証明書を作成し、それらを Amazon S3 バケットにアップロードして、ELB トラストストアで使用します。 curl に --key および --cert パラメーターを使用すると、リクエストの一部としてクライアント証明書を送信できます。 $ curl--key my_client.key--cert my_client.pem https://api.yourdomain.com クライアントが無効または期限切れの証明書を提示した場合、証明書を提示できなかった場合、トラストチェーンが見つからない場合、トラストチェーン内のリンクのいずれかが期限切れになっている場合、または証明書が失効リストに含まれている場合は、相互認証は失敗する可能性があります。 Application Load Balancer は、クライアントの認証に失敗するたびに接続を閉じ、ロードバランサーに送信されたリクエストに関する詳細情報をキャプチャする 新しい接続ログ を記録します。各ログには、クライアントの IP アドレス、ハンドシェイクの待ち時間、使用された TLS 暗号、クライアント証明書の詳細などの情報が含まれます。これらの接続ログを使用して、リクエストパターンを分析し、問題をトラブルシューティングできます。 詳細については、AWS ドキュメントの「 Application Load Balancer での相互認証 」を参照してください。 今すぐご利用いただけます Application Load Balancer での相互認証は、Application Load Balancer が利用可能なすべての商用 AWS リージョン (中国を除く) で利用できるようになりました。初期費用や契約は必要ありません。お支払いいただくのは使用した分のみです。料金については、「 Elastic Load Balancing の料金 」ページを参照してください。 ぜひお試しいただき、 AWS re:Post for Amazon EC2 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 詳細はこちら。 Application Load Balancer 製品ページ – Channy 原文は こちら です。

11月26日より、新しい AWS 無料利用枠 API を使用して、 AWS 無料利用枠 の使用状況を確認できます。API は AWS コマンドラインインターフェイス (AWS CLI) で直接使用することも、 AWS SDK を使用してアプリケーションに統合することもできます。 AWS 無料利用枠プログラムでは、各サービスに指定された上限まで、AWS サービスを無料で試用できます。AWS 無料利用枠には、 次の 3 種類のサービスが含まれます。 常時無料 オファーにより、お客様が AWS ユーザーである限り、指定された制限まで無料でサービスを使用できます。 12 か月間の無料オファー により、お客様はアカウントが有効になった日から 1 年間、指定された上限まで無料でサービスを使用できます。 短期トライアル は、サービスに応じて、特定の期間、または1回限りの制限まで無料で利用できます。 AWS リソースを有効にして、無料利用枠を提供する AWS サービスとやり取りし始めたら、無料利用枠の上限までの進捗状況を追跡して、いつ従量制料金に切り替えるべきかがわかるようにする必要があります。 AWS 無料利用枠の使用状況を追跡する方法はいくつかあります。 AWS Billing and Cost Management コンソールの 請求設定 にある使用状況アラートはデフォルトで有効になっており (アカウントが AWS Organizations 経由で作成された場合を除く)、各サービスの無料利用枠の上限の 85% を超えるとメールが送信されます。 請求とコスト管理コンソールの 予算 セクション で、費用ゼロの予算または月額費用の予算を作成できます。テンプレートを使用すると、数回クリックして通知するメールアドレスを入力するだけで済みます。 Billing and Cost Management コンソールの 無料利用 枠ページ には、サービス、オファーのタイプ、現在の使用量、現在の請求期間における各オファーの予測使用量が表示されます。 新しい GetFreeTierUsage API は、プログラムで使用できる構造化された形式で、無料利用枠ページと同じ情報を提供します。 この新しい API が実際にどのように機能するのかを見てみましょう。 AWS CLI で AWS 無料利用枠の API を使用する 過去数か月間に作成された新しいアカウントにアクセスできました。ここでは、 AWS コマンドラインインターフェイス (AWS CLI) を使用して GetFreeTierUsage API を呼び出しています。 aws freetier get-free-tier-usage レスポンスは、この請求期間中にこのアカウントに適用される各オファーの現在の使用量の説明を含む JSON ドキュメントです。わかりやすくするために、ここではいくつかのオファーのみを示します。 { "freeTierUsages": [ { "service": "Amazon Simple Queue Service", "operation": "", "usageType": "Requests", "region": "global", "actualUsageAmount": 294387.0, "forecastedUsageAmount": 679354.6153846154, "limit": 1000000.0, "unit": "Requests", "description": "1000000.0 Requests are always free per month as part of AWS Free Usage Tier (Global-Requests)", "freeTierType": "Always Free" }, { "service": "Amazon Elastic Compute Cloud", "operation": "", "usageType": "EBS:VolumeUsage", "region": "global", "actualUsageAmount": 9.0, "forecastedUsageAmount": 33.0, "limit": 30.0, "unit": "GB-Mo", "description": "30.0 GB-Mo for free for 12 months as part of AWS Free Usage Tier (Global-EBS:VolumeUsage)", "freeTierType": "12 Months Free" }, { "service": "Amazon Elastic Compute Cloud", "operation": "RunInstances:0002", "usageType": "BoxUsage:freetier.micro", "region": "global", "actualUsageAmount": 476.0, "forecastedUsageAmount": 851.0, "limit": 750.0, "unit": "Hrs", "description": "750.0 Hrs for free for 12 months as part of AWS Free Usage Tier (Global-BoxUsage:freetier.micro)", "freeTierType": "12 Months Free" }, { "service": "Amazon Elastic Compute Cloud", "operation": "RunInstances", "usageType": "BoxUsage:freetier.micro", "region": "global", "actualUsageAmount": 225.0, "forecastedUsageAmount": 485.0, "limit": 750.0, "unit": "Hrs", "description": "750.0 Hrs for free for 12 months as part of AWS Free Usage Tier (Global-BoxUsage:freetier.micro)", "freeTierType": "12 Months Free" }, { "service": "Amazon Redshift", "operation": "RunComputeNode:0001", "usageType": "Node:dc2.large", "region": "global", "actualUsageAmount": 367.0, "forecastedUsageAmount": 735.0, "limit": 750.0, "unit": "Hrs", "description": "750.0 Hrs for free per month during a short-term trial as part of AWS Free Usage Tier (Global-Node:dc2.large)", "freeTierType": "Free Trial" }, ... ] } FreeTierUsages リストには、最も一般的なオファーがいくつか含まれています。 Amazon Elastic Compute Cloud (Amazon EC2) 向けの 2 つのコンピューティングオファー。 オペレーション RunInstances:0002 のオファーは Windows 向けです。 オペレーション RunInstances のオファーは Linux 向けです。 オペレーション プロパティの値は、 Amazon EC2 コンソール の [インスタンス] または [AMI] ページに表示されるプラットフォームの詳細および使用オペレーションと同じです。詳細については、「 Amazon EC2 ユーザーガイドの AMI 請求情報フィールド 」を参照してください。 Amazon Elastic Block Store (Amazon EBS) 容量向けの 1 つのストレージオファー。これと 2 つの Amazon EC2 コンピューティングオファーの FreeTierType は 12 か月間無料 です。 Amazon Simple Queue Service (Amazon SQS) 向けの 常時無料 オファー。 Amazon Redshift の 無料トライアル (短期) オファー。 これらのオファーのいくつかのプロパティを見てみましょう。 説明 には、オファーの内容がわかりやすく説明されています。 FreeTierType は、 常時無料 、 12 か月無料 、 無料トライアル (短期) のいずれかのオファーの種類を示します。 ユニット は、オファーの使用状況を測定するために使用される単位を表します。たとえば、EC2 インスタンスの場合は Hrs (時間)、EBS ボリュームの場合は GB-MO (1 か月あたりの GB)、Amazon SQS の場合は リクエスト などです。 興味深いのプロパティは、オファーの上限 ( limit )、オファーの実際の使用量 ( actualUsageAmount )、請求期間の終わり (当月) の予測使用量 ( forecastedUsageAmount ) の 3 つです。これらはすべて、オファーで使用される単位に基づいています。たとえば、Windows と Linux のコンピューティングオファーには、それぞれ 1 か月あたり 750 時間という制限があります。ストレージサービスの上限は 1 か月あたり 30 GB です。Amazon SQS の場合、オファーの上限は 1 か月あたり 100 万リクエストです。 制限と無料で提供されるサービスの詳細については、各カードの AWS 無料利用枠 ページと各サービスの料金ページに記載されています。AWS 無料利用枠の API で提供される実際の使用量と予測使用量は、 AWS コストと使用状況レポート と同様に、1 日につき 3 回までと推定されます。 予測される使用量がオファーの上限を超える場合、もし同じ方法でサービスを引き続き使用するのであれば、請求期間の終了前に従量制料金に切り替える予定です。上限に達すると、実際の使用量は GetFreeTierUsage API によって追跡されなくなります。つまり、実際の使用量が上限を超えることはできません。その場合、対応するオファーは API から返されません。 たとえば、AWS CLI の --query オプションを使用して、予測が制限を超えるオファーを探します。 aws freetier get-free-tier-usage --query 'freeTierUsages[?forecastedUsageAmount > limit]' { "freeTierUsages": [ { "service": "Amazon Elastic Compute Cloud", "operation": "", "usageType": "EBS:VolumeUsage", "region": "global", "actualUsageAmount": 9.0, "forecastedUsageAmount": 33.0, "limit": 30.0, "unit": "GB-Mo", "description": "30.0 GB-Mo for free for 12 months as part of AWS Free Usage Tier (Global-EBS:VolumeUsage)", "freeTierType": "12 Months Free" }, { "service": "Amazon Elastic Compute Cloud", "operation": "RunInstances:0002", "usageType": "BoxUsage:freetier.micro", "region": "global", "actualUsageAmount": 476.0, "forecastedUsageAmount": 851.0, "limit": 750.0, "unit": "Hrs", "description": "750.0 Hrs for free for 12 months as part of AWS Free Usage Tier (Global-BoxUsage:freetier.micro)", "freeTierType": "12 Months Free" } ] } この結果によると、無料利用枠の制限内にとどまりたい場合は、EBS ボリュームと Windows での Amazon EC2 コンピューティングの使用方法を確認できます。 たとえば、現在、Windows EC2 インスタンスでは、1 か月で利用可能な 750 時間のうち 476 時間を使用しています。このペースでは、限界を超えて約 851 時間に達すると予測されています。コストが気になる場合は、使用していないときや夜間に Windows インスタンスをオフにすることもできます。 知っておくべきこと 以前は、 無料利用枠の API は公開されておらず、同じデータを確認できる AWS 請求コンソールの無料利用枠ページ で内部的に使用されていました。 GetFreeTierUsage API を公開することで、お客様が AWS を楽しみ、AWS 無料利用枠のオファーをより有効に活用し、何が無料で、制限に近づいたり超えたりしたときに何をすべきかを理解できるようになることを願っています。 この情報を使用して、ビジネスニーズを満たすカスタムレポートを作成できます。たとえば、コンピューティングコストを回避したい場合は、プログラムで EC2 インスタンスを停止または休止状態にしたり、EC2 Auto Scaling グループのサイズを 0 に設定したりできます。任意の AWS SDK を使用してウェブアプリを作成したり、このデータをモニタリングソリューションに統合したりできます。 より一般的には、オファーの使用量が制限に近づいたときに、追加の E メールまたは通知 ( Amazon SES や Amazon SNS を使用するなど) を送信できます。これにより、追加費用をかけずにオファーのメリットを最大限に引き出すことができます。使用予算額を無料利用枠の上限に設定すれば、AWS Budgets でもこれを行うことができます。 オファーがこのアカウントに適用されなくなった場合 (たとえば、前月末に期限が切れたため)、対応するアイテムはリストに含まれません。前回の API 呼び出しの結果を保存すると、オファーのリストを前回の請求サイクルで報告されたオファーと比較して、最近期限切れになったオファーを確認できます。 AWS 無料利用枠の使用状況を追跡する方法について詳しく知るために、 AWS Skill Builder で次の 3 つの 10 分コースを作成しました。AWS の専門家から学び、オンラインでクラウドスキルを身に付けることができるオンライン学習センターです。 AWS 無料利用枠: サービスの概要 AWS 無料利用枠: モニタリングサービスの概要 AWS 無料利用枠: サービス管理の概要 – Danilo 原文は こちら です。

Amazon CloudWatch を使用して、 ハイブリッド、マルチクラウド 、およびオンプレミスのデータソースからのメトリクスを統合し、一貫性のある統一された方法で処理できるようになりました。ソースに関係なく、あらゆるメトリクスでクエリ、視覚化、アラームを行うことができます。この新機能は、統一されたビューを提供するだけでなく、インフラストラクチャの複数の部分や側面にまたがる傾向や問題を特定するのに役立ちます。 この新機能について初めて聞いたとき、「待って、 PutMetricData でもそれはできるけど、何が凄いの?」と思いました。 結果的に、かなり凄いことが分かりました。 PutMetricData はメトリックスを CloudWatch に保存しますが、この便利な新機能ではソースから直接オンデマンドでメトリクスを取得します。 データを保存する代わりに、 Prometheus 用のアマゾンマネージドサービス 、汎用 Prometheus 、 Amazon OpenSearch Service 、 Amazon RDS for MySQL 、 Amazon RDS for PostgreSQL 、 Amazon Simple Storage Service (Amazon S3) に保存されている CSV ファイル、および Microsoft Azure モニター からデータを引き出すコネクタを選択して設定します。各コネクタは、 AWS CloudFormation テンプレートからデプロイされる AWS Lambda 関数です。CloudWatch は必要に応じて適切な Lambda 関数を呼び出し、返されたメトリクスをすぐに使用します。メトリクスはバッファリングされたり保持されたりしません。 コネクタの作成と使用 はじめに、CloudWatch コンソールを開いて [すべてのメトリックス] をクリックし、 [マルチソースクエリ] タブをアクティブにしてから、 [データソースの作成と管理] をクリックします。 そしてこれをもう一度行います。 次に、データソースタイプを選択します。 その後、CloudWatch は、データソースのコネクタを作成して設定するために必要な詳細情報を入力するように求めます。たとえば、 Amazon RDS — MySQL を選択した場合、データソースに名前を付け、RDS データベースインスタンスを選択して、接続情報を指定します。 [データソースの作成] をクリックすると、Lambda 関数、Lambda 権限、IAM ロール、シークレットマネージャーシークレット、ロググループ、および AWS CloudFormation スタックが自分のアカウントに作成されます。 次に、データソースを参照して提供するメトリクスを利用する準備ができたら、メトリックのタイムスタンプと値を返す SQL クエリを入力します。 Lambda 関数の内部 カスタム — 開始 テンプレートのコードは短く、シンプルで、理解しやすいものです。次の 2 つのイベントのハンドラーを実装しています。 DescribeGetMetricData — このハンドラーは、コネクタの名前、他のハンドラーへの引数のデフォルト値、および CloudWatch コンソールのカスタムデータソースクエリビルダーに表示される Markdown 形式のテキスト説明を含む文字列を返します。 GetMetricData — このハンドラーは、ハンドラーの引数として指定された時間範囲について、メトリクス名、タイムスタンプとメトリックス値の 1 次元配列を返します。 このコードを数分間調べれば、独自のデータソースに接続する関数の記述方法がわかるはずです。 知っておくべきこと この強力な新機能に関して留意すべき点がいくつかあります。 リージョン — すべての商用 AWS リージョンでデータコネクタを作成して使用できます。あるリージョンで実行されているコネクタは、他のリージョンや他の AWS アカウントのサービスやエンドポイントに接続してデータを取得できます。 料金 — コネクタには追加料金はかかりません。Lambda 関数の呼び出しと、作成したその他の AWS インフラストラクチャの料金を支払います。 – Jeff ; 原文は こちら です。

クロスリージョンデータレプリケーションを使用して、 Amazon WorkSpaces ユーザーにビジネス継続性を提供できるようになりました。スナップショットは 12 時間ごとに作成され、目的のターゲットリージョンにレプリケートされます。このスナップショットを使用して 12～24 時間の目標復旧時点 (RPO) が得られます。 マルチリージョンレジリエンスのレビュー 同僚のアリエルは、2022年の記事「 Amazon WorkSpaces マルチリージョンレジリエンスによる事業継続性の向上 」で、この機能の初期バージョンを紹介し、この機能を使用してユーザーが利用できるスタンバイ仮想デスクトップをセットアップする方法を示しました。セットアップが完了すると、ユーザーは完全修飾ドメイン名 (FQDN) を含む Amazon WorkSpaces 登録コードを使用してログインします。プライマリリージョンの WorkSpaces が利用できない場合、ユーザーはセカンダリリージョンのスタンバイ WorkSpaces にリダイレクトされます。 スタンバイ WorkSpaces は、インフラストラクチャとストレージの少額の固定月額料金で利用でき、その月の利用時間ごとに低額の定額料金がかかります。この機能とこのビジネスモデルを組み合わせることで、スタンバイデプロイメントを簡単かつ経済的に維持できます。 クロスリージョンデータレプリケーション 本日、一方向のクロスリージョンデータレプリケーションを追加することで、この機能をさらに強化します。プライマリ WorkSpace に保存されているアプリケーション、ドキュメント、その他のリソースは 12 時間ごとにスナップショットされ、セカンダリ WorkSpace をホストするリージョンにコピーされます。冗長性がさらに強化され、データ保護が強化され、システム停止によって失われる生産性を最小限に抑えることができます。これは、ユーザーがベースイメージ上にアプリケーションをインストールして構成している場合に特に役立ちます。これは、セカンダリ WorkSpace で上記の手順を繰り返す必要がないためです。 仕組みは以下のとおりです。 通常の運用 — 通常の運用では、 WorkSpaces フリートのユーザーはプライマリリージョンを使用しています。システム (C:) ドライブとデータ (D:) ドライブの EBS スナップショットは 12 時間ごとに作成されます。マルチリージョンレジリエンスはセカンダリリージョンで実行され、新しいスナップショットを定期的にチェックします。それらが見つかると、セカンダリリージョンへのコピーを開始します。コピーがセカンダリリージョンに到着すると、それらを使用してセカンダリ WorkSpace を更新します。 フェイルオーバー検出 — セットアッププロセスの一環として、「 DNS サービスの設定と DNS ルーティングポリシーの設定 」に従って、DNS ルーティングポリシーとオプションの Amazon Route 53 ヘルスチェックを設定し、クロスリージョンリダイレクトを管理します。 フェイルオーバー — 大規模イベント (LSE) がプライマリリージョンとプライマリ WorkSpace に影響する場合、先ほど説明したフェイルオーバー検出が有効になります。ユーザーが再接続を試みると、セカンダリージョンにリダイレクトされ、最新のスナップショットを使用して WorkSpace が起動し、12～24 時間前のデータやアプリにアクセスして稼働状態に戻ります。 フェイルバック — LSE が終了すると、ユーザーはセカンダリ WorkSpace で作成したデータを手動でバックアップし、そこからログアウトします。その後、再びログインすると、今度はプライマリリージョンと WorkSpace にリダイレクトされ、そこでバックアップを復元して作業を続けることができます。 セットアップを始める WorkSpaces 管理者として、まず必要なプライマリワークスペースを見つけることから始めます。 これを選択し、 [アクション] メニューから [スタンバイワークスペースの作成] を選択します。 セカンダリ WorkSpace に必要なリージョンを選択し、 [次へ] をクリックします。 次に、リージョン内の適切なディレクトリを選択し、もう一度 [次へ] をクリックします。 プライマリ WorkSpace が暗号化されている場合は、セカンダリリージョンに KMS キーの ARN を入力する必要があります (または、 マルチリージョンキー を使用するとさらに便利です)。 [データ複製を有効にする] をオンにして、追加の月額料金を許可していることを確認します。 次のページで選択内容を確認し、 [作成] をクリックして、選択したリージョンでセカンダリ WorkSpace の作成を開始します。 前述のように、 マルチリージョンレジリエンスを設定する必要もあります 。これには、WorkSpaces 登録コードとして使用するドメイン名の設定、Route 53 ヘルスチェックの設定、およびそれらを使用してルーティングポリシーを強化することが含まれます。 知っておくべきこと クロスリージョンデータレプリケーションについて知っておくべき重要な点をいくつか紹介します。 ディレクトリ — この記事 で説明されているように、構成されたセルフマネージド型 Active Directory、 AWS マネージド AD 、または AD コネクタ を使用できます。シンプル AD はサポートされていません。 スナップショット — 特定のデータボリュームの最初の EBS スナップショットがいっぱいで、後続のスナップショットは増分になります。その結果、特定の WorkSpace の最初のレプリケーションは、後続のレプリケーションよりも時間がかかる可能性があります。スナップショットは WorkSpaces 内部のスケジュールで開始され、タイミングを制御することはできません。 暗号化 — プライマリリージョンとセカンダリリージョンで同じ AWS Key Management Service (AWS KMS) キーを使用している限り、この機能は 暗号化された WorkSpace で使用できます。 マルチリージョンキー を使用することもできます。 バンドル — Windows 10 および Windows 11 のバンドルを使用できますが、BYOL を実行することもできます。 アカウント — 各 AWS アカウントには、保留中の EBS スナップショットの数に一定の制限があります。これにより、大量の WorkSpaces でこの機能を使用できなくなる可能性があります。 料金 — 各プライマリ WorkSpace に設定されたストレージ量に基づいて、固定月額料金をお支払いいただきます。詳細については、「 Amazon WorkSpaces の料金表 」ページを参照してください。 – Jeff ; 原文は こちら です。

生成系人工知能 (AI) を活用した 通話要約を Amazon Transcribe Call Analytics のプレビューを発表します。 Amazon Bedrock を搭載したこの機能は、カスタマーサービスへの電話を自動的に要約することで、企業がカスタマーエクスペリエンスを向上させ、エージェントとスーパーバイザーの生産性を向上させるのに役立ちます。Amazon Transcribe Call Analytics は、機械学習 (ML) を活用した分析を提供します。これにより、コンタクトセンターは顧客との会話の感情、傾向、ポリシーコンプライアンスを理解して、顧客体験を向上させ、重要なフィードバックを特定できます。たった 1 回の API コールで、顧客との会話のトランスクリプトや豊かなインサイト、および要約を抽出することができます。 ビジネスとして、各会話に関連するアクションアイテムを含め、重要な会話ポイントの正確な履歴記録を維持したいと考えていることは理解しています。そのためには、エージェントは会話の終了後にメモをまとめ、CRM システムに入力します。このプロセスには時間がかかり、人為的ミスの原因となります。ここで、エージェントが会話中に話し合った重要なアクションアイテムを正しく把握して行動でず、顧客の信頼が低下することを想像してみてください。 仕組みの説明 11月26日より、エージェントとスーパーバイザーが顧客との会話を要約しやすくなるように、Amazon Transcribe Call Analytics はコンタクトセンターとのやり取りの簡潔な要約を生成します。この要約には、顧客が電話をかけた理由、問題への対処方法、特定されたフォローアップアクションなどの主要な要素が含まれます。顧客とのやり取りが完了すると、エージェントは会話を要約する必要がないため、次の顧客のサポートに直接進むことができます。その結果、顧客の待ち時間が短縮され、エージェントの生産性が向上します。さらに、スーパーバイザーは、顧客の問題を調査するときに概要を確認して会話の要点を把握できます。通話の録音全体を聞いたり、トランスクリプトを読んだりする必要はありません。 コンソールで Amazon Transcribe Call Analytics を調べる これがどのように機能するかを視覚的に確認するために、まず該当する AWS リージョン に Amazon Simple Storage Service (Amazon S3) バケット を作成します。次に、オーディオファイルを S3 バケットにアップロードします。 音声を書き起こし、顧客とエージェントが行った会話に関する追加の分析を提供する分析ジョブを作成するには、Amazon Transcribe Call Analytics コンソールにアクセスします。左側のナビゲーションバーで [ポストコール分析] を選択し、 [ジョブの作成] を選択します。 次に、オーディオファイルの言語に基づいて言語設定が維持されるように、ジョブ名を入力します。 Amazon S3 URI パスには、この記事で示した最初のスクリーンショットでアップロードされたオーディオファイルへのリンクを指定します。 [ロール名] で、Amazon S3 バケットにアクセスする [IAM ロールの作成] を選択し、 [次へ] を選択します。 生成系コールサマリーを有効にして、 [ジョブの作成] を選択します。 数分後、ジョブのステータスが [進行中] から [完了] に変わり、正常に完了したことが示されます。 ジョブを選択すると、次の画面にトランスクリプトと新しいタブ [生成系コールサマラリー — プレビュー ] が表示されます。 トランスクリプトをダウンロードして、分析と概要を確認することもできます。 今すぐご利用いただけます Amazon Transcribe Call Analytics の生成系コールサマリーは、11月26日、米国東部 (バージニア北部) と米国西部 (オレゴン) で英語でご利用いただけます。 Amazon Transcribe Call Analytics の生成系コールサマリーでは、従量制料金でお支払いいただき、階層型の料金設定に基づいて毎月請求されます。詳細については、「 Amazon Transcribe の料金設定 」をご参照ください。 詳細はこちら 。 Amazon Transcribe Call Analytics の製品ページ Amazon Transcribe Call Analytics 開発者ガイド – Veliswa 原文は こちら です。

11月26日、 AWS Step Functions と Amazon Bedrock の新しい 2 つの最適化された統合について発表しました。Step Functions は、開発者が分散アプリケーションの構築、プロセスの自動化、マイクロサービスのオーケストレーション、データおよび機械学習 (ML) パイプラインの作成を支援するビジュアルワークフローサービスです。 基盤モデル (FM) を使用して生成型人工知能 (AI) アプリケーションを構築およびスケールする最も簡単な方法である Amazon Bedrock を 9 月に公開しました 。Bedrock は、AI21 Labs、Anthropic、Cohere、Stabilability AI、Amazon などの大手プロバイダーが提供するさまざまな基盤モデルと、顧客がプライバシーとセキュリティを維持しながら生成系 AI アプリケーションを構築するために必要な幅広い機能を提供しています。 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) または AWS SDKs から Amazon Bedrock を使用できます。 Amazon Bedrock と最適化された新しい Step Functions との統合により、タスクを調整して、Amazon Bedrock を使用して 生成系 AI アプリケーションを構築したり、 220 を超えるAWSサービス と統合したりすることができます。Step Functions を使用すると、ワークフローを視覚的に開発、検査、監査できます。以前は、ワークフローから Amazon Bedrock を使用するには AWS Lambda 関数を呼び出す必要があり、それを維持するためのコードが追加され、アプリケーションのコストが増加していました。 Step Functions には、Amazon Bedrock 用に最適化された 2 つの新しい API アクションが用意されています。 InvokeModel — この統合により、パラメーターで提供される入力を使用してモデルを呼び出し、推論を実行できます。この API アクションを使用して、テキスト、画像、埋め込みモデルの推論を実行します。 CreateModelCustomizationJob — この統合により、ベースモデルをカスタマイズするための微調整ジョブが作成されます。パラメーターでは、基礎モデルとトレーニングデータの場所を指定します。ジョブが完了すると、カスタムモデルを使用する準備が整います。これは非同期 API であり、この統合により、Step Functions は ジョブを実行 し、ジョブが完了するのを待ってから次の状態に進むことができます。つまり、モデルカスタマイズ作成ジョブの実行中はステートマシンの実行が一時停止し、タスクが完了すると自動的に再開されます。 InvokeModel API アクションは、最大 25 MB のリクエストとレスポンスを受け入れます。ただし、Step Functions にはステートペイロードの入力と出力に 256 kB の制限があります。この統合でより大きなペイロードをサポートするために、 InvokeModel API がデータを読み込んだり、結果を書き込んだりする Amazon Simple Storage Service (Amazon S3) バケットを定義できます。これらの構成は、API アクション構成パラメーターセクションのパラメーターセクションで提供できます。 Amazon Bedrock と AWS Step Functions の開始方法 開始する前に、Amazon Bedrock が利用できるリージョンにステートマシンを作成してください。この例では、米国東部 (バージニア北部)、 us-east-1 を使用してください。 AWS マネジメントコンソールから、新しいステートマシンを作成します。「bedrock」を検索すると、使用可能な 2 つの API アクションが表示されます。 InvokeModel をステートマシンにドラッグします。 これで、右側のメニューでその状態を設定できます。まず、どの基盤モデルを使用するかを定義できます。リストからモデルを選択するか、入力から動的にモデルを取得します。 次に、モデルパラメータを設定する必要があります。テキストボックスに推論パラメータを入力するか、Amazon S3 からパラメータを読み込むことができます。 API アクション設定をスクロールし続けると、S3 宛先バケットなど、API の追加設定オプションを指定できます。このフィールドを指定すると、API アクションは API レスポンスを状態出力に返す代わりに、指定されたバケットに保存します。ここでは、リクエストとレスポンスのコンテンツタイプを指定することもできます。 ステートマシンの設定が完了したら、ステートマシンを作成して実行できます。ステートマシンが実行されると、実行の詳細を視覚化し、Amazon Bedrock ステートを選択し、その入力と出力を確認できます。 Step Functions を使用すると、さまざまなサービスを組み合わせてさまざまな問題を解決しながら、必要なだけ広範囲にステートマシンを構築できます。たとえば、Amazon Bedrock で Step Functions を使用すると、プロンプトチェーンを使用するアプリケーションを作成できます。これは、非常に長くて詳細なプロンプトの代わりに、小さくて単純な複数のプロンプトを FM に渡すことで、複雑な生成系 AI アプリケーションを構築するための手法です。プロンプトチェーンを構築するには、Amazon Bedrock を複数回呼び出すステートマシンを作成して、小さいプロンプトのそれぞれについて推論を行います。 並列状態 を使用してこれらすべてのタスクを並行して実行し、次に並列タスクの応答を 1 つの応答に統合して結果を生成する AWS Lambda 関数を使用できます。 今すぐご利用いただけます Amazon Bedrock 向けの AWS Step Functions 最適化統合は、Amazon Bedrock が利用可能な AWS リージョンに限定されます。 Step Functions コンソール からサンプルプロジェクトを試してみることで、Step Functions と Amazon Bedrock を使い始めることができます。 –  Marcia 原文は こちら です。

自律移動ロボットの最前線に立つ先駆的な企業である ANYbotics は、AWS を使用してグローバルにロボットの労働力を配備しています。安全性、効率性、持続可能性を向上させるインテリジェントな検査ソリューションを提供することで、大規模な産業施設の運営に革命をもたらします。ANYbotics は、物理資産とデジタル資産をつなぐことで、最先端のロボット技術を持つ企業が、ロボットと人間がシームレスに連携してより良い結果を達成できる環境を構築できるよう支援します。 このブログ記事では、ANYbotics がアマゾンウェブサービス (AWS) を活用してアプリケーションを実行し、ロボット群からデータを収集して保存する方法と、顧客がテレメトリデータを表示して新しいミッションをロボットに送信するためのインターフェイスを提供する方法について学びます。 ANYmal を大規模に運用 ANYmal は、反復的で危険な検査作業を行う ANYbotics のロボットソリューションです。堅牢で、自律的で、移動性が高く、すぐに使える検査ロボットです。ANYmal のマルチセンサー機能には、視覚的および音響的な資産監視、熱異常の検出、ガス漏れが含まれます。プラントの 3D マップを絶えず更新して状況を認識し、施設のダイナミックなデジタルツインを作成します。ANYmal は年中無休で利用できるため、ロボットの動作に関する洞察を絶えず提供できるため、顧客は迅速かつ安全に行動できます。 ANYbotics は、ANYmal の最初の商用シリーズで、パイロットプロジェクト用に単一ユニットを納入しました。顧客がテクノロジーの拡張とロボットの導入を開始するにつれ、安全な運用の確保、ロボットからの大量の受信データの処理、テレメトリーデータをクエリするための信頼性の高い方法の提供など、新たなオペレーション課題が生じました。ANYbotics は、AWS ソリューションをソリューションの主要コンポーネントとして使用することで、これらの課題を解決しています。 ソリューション概要 ANYbotics は、クラウド容量をカスタマイズ可能な Amazon Elastic Compute Cloud (Amazon EC2) 、顧客向けワークロードと API のプロビジョニング、メンテナンス、スケーリング用の Amazon Elastic Kubernetes Service (Amazon EKS) 、自動スケジューリング用の AWS Lambda など、AWS 製品の利用を拡大しています。 ANYbotics は、ANYmal からデータを収集して AWS に保存し、API 経由で顧客がアクセスできるようにするソリューションを開発しました。同時に、このソリューションにより、ANYmal はロボットの地理的位置に関係なく、オペレーターからソフトウェアの更新とミッションコマンドを受け取ることができます。 ANYbotics には、ソリューションを顧客サイトのサーバに導入できるという顧客からの独自の要件があります。コンテナベースのアプローチを選択することで、アプリケーションを標準化し、すべての設備で同様のツールを使用できます。すべての設備が同じ構造を使用しているため、ほとんど変化なくすべてのサイトに導入でき、管理オーバーヘッドを低く抑えることができます。 ANYbotics は AWS を活用して、 EC2 インスタンス上で稼働する EKS クラスターを使用してアプリケーションを運用およびスケーリングしています。物理インフラストラクチャに関連するオペレーションタスクを AWS が処理するため、インフラストラクチャ管理のオーバーヘッドが軽減されるというメリットがあります。オーバーヘッドをさらに最小限に抑えるために、Kubernetes クラスタのオペレーションタスクを処理するマネージド Kubernetes サービスである EKS を使用しています。そのため、ハードウェアやコントロールプレーンを管理する代わりに、顧客に価値をもたらすアプリケーションの構築に集中できます。同じクラスター内のさまざまな顧客のアプリケーションを実行するために、ANYbotics は各テナントに固有の名前空間を割り当てます。このセグメンテーションにより、ANYbotics は異なるテナントのアプリケーションを安全に並行して運用し、計算リソースを共有できます。 ANYbotics には、ANYmal と AWS 間のデータ同期、ロボットへの新しいミッションの送信、およびその他のワークロード用のコンテナがあります。ANYmal は、 Amazon Elastic Load Balancer (ELB) を使用してデータ同期アプリケーションに接続し、お客様の産業用サイトから最新の検査テレメトリデータをアップロードします。同時に、更新通知と実行すべき新しいミッションを受け取ります。顧客のオペレーターは、アプリを使用してロボットの状態を確認したり、新しいミッションを定義したりできます。さらに、ANYbotics のお客様は、産業現場から収集した情報を提供する ANYmal API を介して、既存のデジタルツインソリューションまたはサードパーティアプリケーションを統合できます。 Robot-as-a-Service (RaaS) の実現 Robot-as-a-Service（RaaS）は、ロボットを1回限りの製品として販売するのではなく、ロボットやロボットサービスのサブスクリプションまたは従量課金制で顧客に提供するビジネスモデルです。RaaS は ANYbotics が推奨するモデルであり、ANYmal のハードウェアとソフトウェアのフルサービスで ANYmal の製品を拡張できます。これは、顧客への先行投資を必要としない柔軟なビジネスモデルです。 AWS サービスを使用することで、ANYbotics は現在のワークロードに応じてアプリケーションをスケールアップまたはスケールダウンできます。コンピューティングリソースをオンデマンドで数分以内に追加でき、従量課金制の料金モデルを使用してコスト効率の高い運用を実現できます。これは ANYbotics にとって非常に重要です。需要が低い時期には十分に活用されていないオンプレミスのハードウェアに投資することなく、ロボットの数の変動やタスクの複雑さに容易に適応できるからです。増え続ける ANYmal ロボットを将来的に運用する準備を整え、より複雑なタスク解決アプリケーションの需要を満たすためには、スケールアップが不可欠です。 ANYmal ロボットは世界中の産業現場に配備されています。 AWS のグローバルなフットプリント を活用することで、ANYbotics は自社のソリューションをロボットに近づけてレイテンシーを減らし、顧客のパフォーマンスを向上させることができます。 その結果、ANYbotics は AWS を使用して多用途でスケーラブルな Robot-as-a-Service (RaaS) を提供し、ロボットがさまざまな分野のさまざまなアプリケーションで中心的な役割を果たす未来の準備を整えました。 “AWS クラウドコンピューティングソリューションにより、世界中でデータを収集し、ANYmal がよりインテリジェントになるようにトレーニングし、それらのソリューションをほぼ分単位の頻度で顧客にデプロイできる未来に向かって進んでいます。“ – ANYbotics ソリューションズ CTO, Robert MacKenzie. まとめ ANYbotics は、大規模資産運用者に、複雑で危険な産業環境向けの自律的で自動化されたエンドツーエンドのロボット検査ソリューションを提供します。彼らは単一のロボットから始め、世界中で操業するロボットフリートにまで拡大しました。AWS を活用してソリューションを拡張し、コンピューティングリソースをオンデマンドで追加することで、増え続けるロボットを運用および管理できるようになっています。これにより、ANYbotics は必要なリソースに対してのみ支払いを行うため、統合ソリューションを費用対効果の高い方法で提供できます。さらに、インフラストラクチャ管理のオーバーヘッドが軽減されるため、世界中の顧客に Robot-as-a-Service (RaaS) モデルを提供することに集中でき、サービスの信頼性、耐久性、保守が容易になります。 ロボット工学や IoT ソリューションに AWS を使用する方法の詳細については、 AWS IoT または AWS Robotics をご覧ください。 著者について David Boldt David Boldt は、アマゾンウェブサービスのソリューションアーキテクトです。彼は、お客様が安全でスケーラブルなソリューションを構築できるよう支援しています。彼はモノのインターネット（IoT）に情熱を注いでおり、さまざまな業界の課題を解決しています。 João Cravo João Cravo は現在、先駆的なロボット企業である ANYbotics でクラウド・ロボティクス・エンジニアの役職に就いています。2014 年以来、João は、賭け、フィンテック、電気通信などの幅広い企業に AWS ソリューションをデプロイする上で、豊富な専門知識を蓄積してきました。ANYbotics でのキャリアは2021年に始まり、クラウド技術の可能性を最大限に活用してロボティクスの分野を強化することに尽力してきました。 この記事は ANYbotics uses AWS to deploy a global robot workforce for industrial inspections の日本語訳です。IoT Consultant の正村 雄介が翻訳しました。

11月26日、AWS Billing and Cost Management の新しい機能である Cost Optimization Hub を発表しました。これにより、AWS のコスト最適化に関する推奨事項を実現するコスト削減を簡単に特定、フィルタリング、集計、定量化できます。 新しい Cost Optimization Hub を使用すると、組織内の複数の AWS リージョンと AWS アカウントにわたって、アイドル状態のリソースの検出、リソースの適正化、購入オプションなどのコスト最適化に関する推奨事項をインタラクティブにクエリできます。データの集約や処理は不要です。これらの推奨事項を実装すれば、どれだけ節約できるかがわかり、節約によって推奨事項を簡単に比較して優先順位を付けることができます。 Amazon の CEO である Andy Jassy は、 2022年の株主への手紙 の中で、「私たちは、私たち全員よりも長く続く顧客関係 (およびビジネス) を構築しようとしています。その結果、AWS の営業およびサポートチームは、お客様がこの不確実な経済をよりうまく乗り切ることができるように、AWS 支出を最適化するために多くの時間を費やしています」と述べています。 コスト最適化ハブは、 AWS Cost Explorer や AWS Compute Optimizer を含む AWS クラウド財務管理 (CFM) サービス 全体にわたるすべてのコスト最適化推奨アクションを 1 か所にまとめます。これらの推奨事項には顧客固有の価格設定と割引が組み込まれています。また、検出結果やコスト削減の複製が可能になるため、コスト最適化の機会を総合的に把握できます。 FinOps チームまたはインフラストラクチャ管理チームのメンバーで、コスト最適化の機会が最も多い AWS アカウントや AWS リージョンなど、コスト最適化の機会を総合的に把握したい場合は、Cost Optimization Hub から始める必要があります。 組み込みのフィルターとグループ化オプションを使用して、コスト最適化の機会を簡単に分析できます。たとえば、どの AWS アカウントでコスト最適化の機会が最も多いかを把握したら、アイドル状態のリソースの停止、適正化、Graviton への移行など、最もコスト最適化の多い戦略を特定できます。適正サイズ化の機会が最も多い AWS リージョンを特定すると、そのリージョンの適正化に関する推奨事項のリストが表示されます。ディープリンクを通じて Compute Optimizer コンソールにリダイレクトされ、変更を実装した場合に予測される CPU 使用率などの詳細が検証されます。 コストの最適化ハブの開始方法 開始するには、 AWS Billing and Cost Management Console の左側のナビゲーションメニューで [コストの最適化ハブ] を選択します。 [有効] を選択するとオプトインできます。コストの最適化ハブが最初にデータを入力するまでには 24 時間の待機し時間があり、その後データは毎日更新されます。 オプトインすると、AWS アカウント、AWS リージョン、タグキーごとのコスト最適化の推奨事項のダッシュボードが表示されます。最適化に使用できるリソースのリストを表示するには、 [機会を表示] を選択します。 コスト最適化ハブは、次の 6 種類のコスト最適化推奨アクションをサポートしています。 停止 — アイドル状態または未使用のリソースを停止して、リソースのコストを最大 100% 節約します。 適切なサイズ — より小さな Amazon EC2 インスタンスタイプ、Amazon EBS ボリューム、AWS Lambda メモリサイズ、または AWS Fargate タスクサイズに移行します アップグレード — EBS io1 ボリュームタイプから io2 への移行など、より新しい世代の製品に移行します。 Graviton 移行 — x86 ベースのプロセッサを搭載した EC2 インスタンスタイプから AWS Graviton ベースのプロセッサを搭載した EC2 インスタンスタイプに移行することで、コストを節約できます。 節約プランの購入 — Compute Savings Plans、EC2 Instance Savings Plans、および Amazon SageMaker Savings Plans が購入できます リザーブドインスタンスの購入 — Amazon EC2、Amazon RDS、Amazon DynamoDB、Amazon ElastiCache、Amazon Redshift リザーブドインスタンスが購入できます。 リソースタイプ、最も推奨されるアクション、および推定月間節約額を確認できます。また、リストを AWS アカウント、AWS リージョン、実装作業量で、またタグキーをグループ別ディメンションとしてフィルタリングすることもできます。 また、各推奨事項を「リソースの再起動が必要」または「ロールバックが可能」に分類することもできます。 リソースの再起動が必要=いいえ をフィルターに指定した場合、EBS ボリュームの推奨など、リソースの再起動を必要としない推奨のみが表示されます。同様に、 ロールバックが可能=はい をフィルターとして指定した場合、ロールバックできるレコメンデーションのみが表示されます。 適切なサイズの EC2 インスタンスなど、特定のソースを選択すると、詳細を表示して Amazon EC2 と AWS Compute Optimizer コンソールに接続できます。毎月の推定節約額は、将来の節約額を簡単に見積もったものであることに注意してください。実際に節約できるかどうかは、将来の AWS の使用パターンによって異なります。 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK を使用してインタラクティブにクエリを実行することもできます。 リソースの削除とサイズ変更に関する推奨事項を確認するためのサンプルクエリは次のとおりです。 $ aws cost-optimization-hub list-recommendations 前述のクエリでは、次の結果が得られます。 { "items":[ { "recommendationId":"MDA2MDI1ODQ1MTA1XzQ5MzNhYzZlLWZmYTUtNGI2ZC04YzBkLTAxYWE3Y2JlNjNlYg==", "accountId":"006025845105", "region":"Global", "resourceId":"006025845105_ComputeSavingsPlans", "currentResourceType":"ComputeSavingsPlans", "recommendedResourceType":"ComputeSavingsPlans", "estimatedMonthlySavings":1506.591472696, "estimatedSavingsPercentage":55.46400024, "estimatedMonthlyCost":2716.341169146, "currencyCode":"USD", "implementationEffort":"VeryLow", "restartNeeded":false, "actionType":"PurchaseSavingsPlans", "rollbackPossible":false, "recommendedResourceSummary":"$1.628/hour with three years term", "lastRefreshTimestamp":"2023-10-23T16:54:13-07:00", "recommendationLookbackPeriodInDays":30, "source":"CostExplorer" }, { "recommendationId":"MDA2MDI1ODQ1MTA1XzhiZTRlNTczLTE0MDctNGIzOS05MmY3LTdmN2EzOTU2Y2ZkYw==", "accountId":"006025845105", "region":"us-east-1", "resourceId":"arn:aws:lambda:us-east-1:006025845105:function:Lambda-recommendation-testing:$LATEST", "resourceArn":"arn:aws:lambda:us-east-1:006025845105:function:Lambda-recommendation-testing:$LATEST", "currentResourceType":"LambdaFunction", "recommendedResourceType":"LambdaFunction", "estimatedMonthlySavings":3.1682091425308054e-06, "estimatedSavingsPercentage":1.936368871741565, "estimatedMonthlyCost":0.00016044778307703665, "currencyCode":"USD", "implementationEffort":"Low", "restartNeeded":false, "actionType":"Rightsize", "rollbackPossible":true, "currentResourceSummary":"128 MB memory", "recommendedResourceSummary":"160 MB memory", "lastRefreshTimestamp":"2023-10-24T04:07:35.364000-07:00", "recommendationLookbackPeriodInDays":14, "source":"ComputeOptimizer" } ] } 新しいコスト最適化ハブ API の詳細については、「 コスト最適化ハブ API ドキュメント 」を参照してください。 今すぐご利用いただけます コスト最適化ハブは、すべてのお客様が一般的に利用できるようになりました。この新機能には追加料金はかかりません。開始して、すべての AWS リージョンのコスト最適化に関する推奨事項を確認できるようになりました。 詳細については、コスト最適化ハブページを参照し、 コスト最適化のための AWS re:Post にフィードバックを送信するか、通常の AWS サポートの連絡先を通じて送信してください。 – Channy 原文は こちら です。

ログデータを検索して運用上またはビジネス上のインサイトを見つけることは、多くの場合、干し草の山から針を探すようなものです。通常、個々のログレコードを手動でフィルタリングして確認する必要があります。これを支援するために、 Amazon CloudWatch は、数十年にわたる Amazon と AWS の運用データを使用してトレーニングされた高度な機械学習 (ML) アルゴリズムを使用して、ログレコードのパターンを自動的に認識してクラスター化し、注目すべきコンテンツと傾向を抽出し、異常を通知する新しい機能を追加しました。 具体的には、CloudWatch では以下の機能が提供されるようになりました。 [Logs Insights] ページの [パターン] タブでは、クエリ結果で繰り返し発生するパターンを見つけて詳細に分析できます。これにより、探している内容を見つけやすくなり、ログ内の新しいコンテンツや予期しないコンテンツにドリルダウンしやすくなります。 [Logs Insights] ページの時間間隔セレクターにある [比較] ボタンを使用すると、選択した時間範囲のクエリ結果を、前日、週、月などの前の期間と簡単に比較できます。これにより、以前の安定したシナリオと比較して、何が変更されたかを確認するのにかかる時間が短くなります。 ナビゲーションペインの [ログ] セクションの [ログ異常 ] ページでは、取り込み中にログが処理されると、ログで見つかった異常が自動的に表示されます。 一般的なトラブルシューティングの手順で、これらが実際にどのように機能するかを見てみましょう。いくつかのアプリケーションログを調べて主要なパターンを見つけ、2つの期間を比較して何が変化したのかを理解し、最後に異常の検出が問題の発見にどのように役立つかを見ていきます。 ログで繰り返し発生するパターンを検出する CloudWatch コンソール で、ナビゲーションペインの [ログ] セクションから [Logs Insights ] を選択します。まず、クエリするロググループを選択しました。今回は、検査したい Lambda 関数のロググループを選択し、 [クエリを実行] を選択します。 [パターン] タブには、これらのロググループで見つかったパターンが表示されます。パターンの 1 つがエラーのようです。これを選択すると、クエリにフィルターとしてすばやく追加でき、このパターンを含むログに集中できます。とりあえず、虫眼鏡アイコンを選択してパターンを分析します。 [パターン検査] ウィンドウには、選択した期間にパターンが発生したことを示すヒストグラムが表示されます。ヒストグラムの後、ログからのサンプルが提供されます。 パターンの可変部分 (数字など) は「トークン」として抽出されています。 トークンの値 を表示するには、[トークン値] タブを選択します。トークン値を選択してフィルターとしてクエリにすばやく追加し、この特定の値を持つこのパターンを含むログに集中できます。 また、 [関連パターン] タブを見ると、分析しているパターンと同時に通常発生する他のログを確認することもできます。たとえば、詳細を示す DEBUG ログと一緒に常に書き込まれている ERROR ログを見ていると、その関係がわかります。 ログを前期間と比較する 何が起こっているのかをよりよく理解するために、時間間隔セレクターの [比較] ボタンを選択します。これにより、クエリが更新され、前の期間と結果が比較されます。たとえば、 [前日] を選択すると、昨日と比較して何が変化したかがわかります。 [パターン] タブでは、エラーの数が実際に 10% 減少していることに気づきました。したがって、現在の状況はそれほど悪くないかもしれません。 重要度が ERROR のパターンにある虫眼鏡アイコンを選択すると、2 つの期間の完全な比較が表示されます。グラフは、選択した時間範囲（1時間）内の 2 つの期間（この場合は現在と昨日）にわたるパターンの出現と重なっています。 エラーは減少していますが、まだ残っています。これらのエラーを減らすために、アプリケーションにいくつかの変更を加えます。しばらくしてログを比較したところ、前の期間には存在しなかった新しい ERROR パターンが見つかりました。 アップデートで何かが壊れたので、以前のバージョンのアプリケーションにロールバックします。今のところ、エラーの数は私のユースケースでは許容範囲内なので、そのままにしておきます。 ログ内の異常検出 ログを比較してみると、エラーが減ったので安心しています。しかし、予期しないことが起こっているかどうかはどうすれば分かるでしょう？ CloudWatch Logs の異常検出は、取り込み中にログが処理されるときに予期しないパターンを検出し、ロググループレベルで有効にできます。 ナビゲーションペインで [ロググループ] を選択し、フィルターを入力すると、以前表示していたのと同じロググループが表示されます。 [異常検出] 列で [設定] を選択し、 [評価間隔] を 5 分に設定します。オプションとして、より長い間隔 (最大 60 分) を設定して、特定のログイベントのみを処理して異常を検出するパターンを追加することもできます。 このロググループの異常検出を有効にすると、受信ログは常に過去のベースラインと照合して評価されます。数分待ってから、何が見つかったかを確認するために、ナビゲーションペインの [ログ] セクションから [ログの異常] を選択します。 この見方を簡略化するために、追跡したくない異常は非表示にできます。とりあえず、前回と同様の方法で対応するパターンを調べるために、異常の 1 つを選択します。 この追加チェックの結果、私の申請には緊急の問題はないと確信しました。これらの新機能で収集したすべてのインサイトにより、ログ内のエラーに集中して解決方法を理解できるようになりました。 知っておくべきこと Amazon CloudWatch の自動ログパターン分析は、現在 Amazon CloudWatch Logs が提供されているすべての商用 AWS リージョン でご利用いただけます。ただし、中国 (北京)、中国 (寧夏)、イスラエル (テルアビブ) リージョンは除きます。 パターンおよび比較クエリ機能は、既存の Logs Insights クエリコストに応じて課金されます。1 時間の期間を別の 1 時間の期間と比較することは、2 時間の期間にわたって 1 つのクエリを実行することと同じです。異常検出はログ取り込み料金に含まれており、この機能に追加料金はかかりません。詳細については、「 Amazon CloudWatch 料金表 」を参照してください。 CloudWatch の自動ログパターン分析により、ログの分析方法を簡素化します。 – Danilo 原文は こちら です。

11月26日、 Amazon Elastic Kubernetes Service (Amazon EKS) から Prometheus のメトリクスを自動的かつエージェントレスに検出して収集する新しい機能、 Amazon Managed Service for Prometheus コレクター を発表できることを嬉しく思います。Amazon Managed Service for Prometheus コレクターは、クラスター内でコレクターを実行することなく、Amazon EKS アプリケーションとインフラストラクチャからメトリックスを検出して収集するスクレイパーで構成されています。 この新機能により、Amazon Managed Service for Prometheus によるフルマネージド型の Prometheus 互換のモニタリングとアラートが可能になります。大きな利点の 1 つは、コレクターが完全に管理され、自動的に適切なサイズ設定とスケーリングが行われ、ユースケースに合わせて調整されることです。つまり、コレクターが利用可能なメトリクスを収集するためにコンピューティングを実行する必要がないということです。これにより、EKS上で稼働するアプリケーションやインフラストラクチャを監視するためのメトリック収集コストを最適化できます。 このリリースにより、Amazon Managed Service for Prometheus は Prometheus メトリックス収集の 2 つの主要なモードをサポートするようになりました。AWS マネージドコレクション、フルマネージドでエージェントレスのコレクター、およびカスタマーマネージドコレクションです。 Amazon Managed Service for Prometheus コレクターの開始方法 この新しい機能を使って Amazon Managed Service for Prometheus のワークスペースにメトリクスを取り込めるよう、AWS マネージドコレクターの使用方法を見てみましょう。次に、収集したメトリックスを Grafana の Amazon マネージドサービスで評価します 。 Amazon EKS コンソールを使用して新しい EKS クラスターを作成するときに、[ Prometheus メトリクスを Amazon Managed Service for Prometheus に送信] を選択して、AWS マネージドコレクターを有効にするオプションが追加されました 。「 デスティネーション 」セクションでは、新しいワークスペースを作成するか、既存の Amazon Managed Service for Prometheus ワークスペースを選択することもできます。ワークスペースの作成方法の詳細については、「 入門ガイド 」をご覧ください。 その後、エディターを使用してスクレイパー構成を柔軟に定義したり、既存の構成をアップロードしたりできます。スクレイパーの設定は、スクレイパーがメトリクスをどのように検出して収集するかを制御します。設定できる値を確認するには、「 Prometheus 設定 」ページをご覧ください。 EKS クラスターの作成が完了したら、クラスターページの [オブザーバビリティ] タブに移動して、EKS クラスターで実行されているスクレイパーのリストを確認できます。 次のステップは、スクレイパーがメトリクスにアクセスできるようにEKS クラスターを構成することです。Amazon EKS クラスターの設定手順と情報については、「 Amazon EKS クラスターの設定 」を参照してください。 EKS クラスターが適切に設定されると、コレクターは EKS クラスターとノードからメトリクスを自動的に検出します。メトリクスを視覚化するには、プロメテウスのワークスペースと統合された Amazon Managed Grafana を使用できます。詳細については、「 Amazon Managed Service for Prometheus で使用するための Amazon Managed Grafana のセットアップ 」ページをご覧ください。 以下は、コレクターによって取り込まれ、Amazon Managed Grafana ワークスペースで視覚化されたメトリックスのスクリーンショットです。ここから、簡単なクエリを実行して必要なメトリクスを取得できます。 AWS CLI と API を使用する Amazon EKS コンソールを使用するほかに、API または AWS コマンドラインインターフェイス (AWS CLI) を使用して AWS マネージドコレクターを追加することもできます。この方法は、AWS マネージドコレクターを既存の EKS クラスターに追加する場合や、既存のコレクター設定に何らかの変更を加える場合に便利です。 スクレイパーを作成するには、次のコマンドを実行します。 aws amp create-scraper \ --source eksConfiguration="{clusterArn=<EKS-CLUSTER-ARN>,securityGroupIds=[<SG-SECURITY-GROUP-ID>],subnetIds=[<SUBNET-ID>]}" \ --scrape-configuration configurationBlob=<BASE64-CONFIGURATION-BLOB> \ --destination=ampConfiguration={workspaceArn="<WORKSPACE_ARN>"} パラメータ値のほとんどは、EKS クラスター ARN や Amazon Managed Service for Prometheus ワークスペース ARN など、それぞれの AWS コンソールから取得できます。それ以外に、 ConfigurationBlob として定義されているスクレイパー構成を定義する必要もあります。 スクレイパー構成を定義したら、API 呼び出しを渡す前に構成ファイルを base64 エンコーディングにエンコードする必要があります。以下は、Linux 開発マシンで sample-configuration.yml を base64 にエンコードしてクリップボードにコピーするために使用するコマンドです。 $ base64 sample-configuration.yml | pbcopy 今すぐご利用いただけます Amazon Managed Service for Prometheus コレクター機能は、Amazon Managed Service for Prometheus がサポートされているすべての AWS リージョンで、すべての AWS ユーザー様にご利用いただけるようになりました。 詳細はこちら。 Amazon Managed Service for Prometheus の製品ページ AWS マネージドコレクター のドキュメントページ 構築がうまくいきますように。 –  Donnie 原文は こちら です。

11月26日、 Amazon Elastic File System (Amazon EFS) の新しいストレージクラスである EFS Archive を紹介します。これは、ほとんどアクセスされない長期保存データ用に最適化されています。 今回の発表により、Amazon EFS は次の 3 つのリージョナルストレージクラスをサポートします。 EFS Standard — SSD ストレージを搭載し、アクティブなデータでミリ秒未満のレイテンシーを実現するように設計されています。 EFS 低頻度アクセス (EFS IA) — 四半期に数回しかアクセスされないデータに対してコスト最適化されており、EFS Standard のようにミリ秒未満のレイテンシーを必要としません。 EFS アーカイブ — 年に数回しかアクセスされない長期間のデータに最適化されたコストで、EFS IA と同等のパフォーマンスを提供します。 すべてのリージョナルストレージクラスは、1 秒あたりギガバイトのスループットと数十万 IOPS パフォーマンスを実現し、ほぼ 100% の耐久性を実現するように設計されています。 EFS ライフサイクル管理 では、アクセスパターンに基づいてストレージクラス間でファイルを自動的に移行できるため、ファイルシステムのストレージクラスを手動で選択する必要はありません。これにより、レイテンシーの影響を受けやすいアクティブなデータからほとんどアクセスされないデータまで、まったく異なる方法で処理されたファイルを含む単一の共有ファイルシステムを構築できます。 多くのデータセットには、インサイトの生成には役立ちますが、あまり使用されないデータのサブセットが含まれています。EFS Archive を使用すると、ほとんどアクセスしないデータを他のデータと同じ共有ファイルシステムに保持しながら、コスト効率よく保存できます。このシンプルなストレージアプローチにより、エンドユーザーとアプリケーションが 1 か所で大規模な共有データセットで共同作業できるようになり、分析ワークロードの設定とスケーリングが簡単かつ迅速になります。 EFS Archive を使用すると、ユーザー共有、機械学習 (ML) トレーニングデータセット、SaaS アプリケーション、金融取引や医療記録などの規制遵守のために保持されているデータなど、アクティブなデータと非アクティブなデータが混在する大規模なファイルベースのデータセットを使用して、ワークロードのコストを最適化できます。 では、これが実際にどのように機能するのかを見てみましょう。 EFS アーカイブストレージを使用する 新しい EFS Archive ストレージクラスを使用するには、ファイルシステムのライフサイクル管理を設定する必要があります。 Amazon EFS コンソール で、いずれかのファイルシステムを選択し、 [編集] を選択します。EFS アーカイブストレージを使用するには、ファイルシステムの スループットモード が Elastic である必要があります。  Elastic Shroughput は、アプリケーションが必要とする限りのスループットを、従量課金制で提供するように設計されているため、ほとんどのワークロードにおすすめです。 今度は、ワークロードのアクセスパターンに基づいてファイルを EFS IA または EFS Archive に移行するように ライフサイクル管理 を設定します。 私のワークロードでは、1 か月以上経過したファイルはほとんど使用されません。3 か月以上古いファイルは通常のアクティビティでは使用されませんが、長期間保存する必要があります。これらの考慮事項に基づいて、ファイルを 30 日後に EFS IA に、最後のアクセスから 90 日後に自動的に EFS Archive に移行することを選択しました。これらは新しいファイルシステムのデフォルト設定です。 古いファイルの 1 つにアクセスすると、通常は新しい分析に使用されていることを示す指標となるため、しばらくは再びアクティブになります。このため、IA またはアーカイブストレージに初めてアクセスしたときに、ファイルを標準ストレージに戻すオプションを使用しています。 変更を保存したら、終わりです! これで、このファイルシステムは、アプリケーションによるファイルの処理方法に基づいて、さまざまなストレージクラスを自動的に使用するようになります。 知っておくべきこと EFS アーカイブ は現在、Amazon EFS が提供されているすべての AWS リージョン (中国に拠点を置くリージョンを除く) でご利用いただけます。 コールドでアクセス頻度の低いファイルに対してよりコスト最適化されたエクスペリエンスを提供するため、EFS Archive はデータにアクセスしたときのリクエスト料金が 3 倍である EFS IA に比べて、50% 低いストレージコストを提供します。詳細については、「 Amazon EFS の料金 」を参照してください。 ファイルシステムの ライフサイクルポリシー を設定することで、既存のファイルシステムで EFS Archive を使用できます。新しいファイルシステムは、ファイルを 30 日後に EFS IA に、最後のアクセスから 90 日後に EFS Archive に自動的に移行するライフサイクルポリシーを使用してデフォルトで作成されます。 Amazon EFS ファイルシステムのライフサイクル管理を設定して、ストレージコストを最適化します。 – Danilo 原文は こちら です。

Amazon CloudWatch Logs は11月26日、低頻度アクセスと呼ばれる新しいログクラスを発表しました。この新しいログクラスは、アクセス頻度の低いログに対して低コストでカスタマイズされた機能セットを提供するため、お客様は費用対効果の高い方法ですべてのログを 1 か所にまとめることができます。 お客様のアプリケーションがスケールし拡大し続けるにつれて、生成されるログの量も増えます。伐採コストの増加を抑えるために、多くのお客様は厳しいトレードオフを余儀なくされています。たとえば、アプリケーションによって生成されるログを制限してアプリケーションの可視性を妨げたり、ログタイプごとに異なるソリューションを選択したりして、さまざまなロギングソリューションを管理するのが複雑になり、非効率になるお客様もいます。たとえば、顧客はリアルタイムの分析とアラートに必要なログを CloudWatch Logs に送信し、デバッグとトラブルシューティングに必要なより詳細なログを、CloudWatch ほど多くの機能を備えていない低コストのソリューションに送信する場合があります。最終的に、これらの回避策はアプリケーションのオブザーバビリティに影響を与える可能性があります。なぜなら、顧客はログを確認するために複数のソリューション間を移動する必要があるからです。 低頻度アクセスログクラスでは、すべてのログを 1 か所にまとめ、コスト効率の高い方法でログの取り込み、クエリ、保存を行うことで、CloudWatch を使用して包括的なオブザーバビリティソリューションを構築できます。低頻度アクセスは、標準ログクラスよりも 1 GB あたりの取り込み価格が 50% 低くなります 。標準ログクラスが提供する ライブテール 、メトリック抽出、アラーム、または データ保護 などの高度な機能を必要としないお客様向けに、カスタマイズされた機能セットを提供します。低頻度アクセスでも、取り込み、ストレージ、および CloudWatch Logs Insights を使用して詳細に分析できるフルマネージド型のメリットを享受できます。 次の表は、新しい低頻度アクセスと標準ログクラスの機能を並べて比較したものです。 機能 低頻度アクセスログクラス 標準ログクラス 完全に管理された取り込みと保管 利用可能 利用可能 クロスアカウント 利用可能 利用可能 KMS による暗号化 利用可能 利用可能 Logs Insights 利用可能 利用可能 サブスクリプションフィルター / S3 へのエクスポート ご利用いただけません 利用可能 ログイベントの取得 / ログイベントのフィルタリング ご利用いただけません 利用可能 コントリビューター 、 コンテナ 、および Lambda インサイト ご利用いただけません 利用可能 メトリックスフィルターとアラート ご利用いただけません 利用可能 データ保護 ご利用いただけません 利用可能 埋め込みメトリック形式 (EMF) ご利用いただけません 利用可能 ライブテール ご利用いただけません 利用可能 新しい低頻度アクセスログクラスを使用するタイミング Standard ログクラスが提供する高度な機能を必要としない新しいワークロードがある場合は、低頻度アクセスログクラスを使用してください。重要な考慮事項の 1 つは、特定のログクラスでロググループを作成した場合、そのロググループログクラスを後で変更することはできないということです。 低頻度アクセスログクラスは、非常に冗長で、標準ログクラスが提供する高度な機能をほとんど必要としないため、デバッグログや Web サーバーログに適しています。 低頻度アクセスログクラスのもう 1 つの優れたワークロードは、モノのインターネット (IoT) フリートが詳細なログを送信することです。このログには、イベント後の事後フォレンジック分析のためにのみアクセスされます。また、低頻度アクセスログクラスは、ログの照会頻度が低いため、コンプライアンスのためにログを保存する必要があるワークロードに適しています。 開始方法 新しい低頻度アクセスログクラスの使用を開始するには、CloudWatch Logs コンソールで新しいロググループを作成し、新しい低頻度アクセスログクラスを選択します。 AWS マネジメントコンソール からだけでなく、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) 、 AWS SDK からも、新しい低頻度アクセスログクラスを使用してロググループを作成できます。 新しいロググループを作成したら、それをワークロードで使用できるようになります。この例では、このロググループにデバッグログを送信するように Web アプリケーションを設定します。Web アプリケーションがしばらく実行された後、ロググループに戻ると新しいログストリームが表示されます。 ログストリームを選択すると、CloudWatch Logs Insights に移動します。 スタンダードクラスと同じ使い慣れた CloudWatch Logs Insights を使用すれば、クエリを作成し、それらのログを検索して関連情報を検索し、すべてのログを 1 か所ですばやく分析できます。 今すぐご利用いただけます 新しい低頻度アクセスログクラスは、中国と GovCloud リージョンを除くすべての AWS リージョンで利用できるようになりました。使い始めると、完全に管理されたエクスペリエンスでログを収集、保存、分析するためのより費用対効果の高い方法を利用できます。 新しいログクラスの詳細については、CloudWatch Logs ユーザーガイドの「 低頻度アクセスログクラス 」専用ページをご覧ください。 –  Marcia 原文は こちら です。

この記事は Reduce container startup time on Amazon EKS with Bottlerocket data volume (記事公開日: 2023 年 10 月 19 日) を翻訳したものです。 はじめに コンテナは、モダンでスケーラブルなアプリケーションをデプロイするための頼りになるソリューションになっています。これらのコンテナの起動時間は、特に大きなコンテナイメージを必要とするワークロードを処理する場合に大きな課題となる可能性があります。たとえばデータ分析や機械学習のワークロードには、1 GiB を超えるサイズのイメージが含まれることがよくあります。generative AI などのこの種のワークロードを Amazon Elastic Kubernetes (Amazon EKS) で実行する場合、 Amazon Elastic Container Registry (Amazon ECR) などのイメージレジストリからこれらの大きなイメージを取り出して抽出するのに数分かかることがあります。これはパフォーマンスに悪影響を及ぼし、ユーザーエクスペリエンスの低下につながります。 イメージをプリフェッチして Pod をより速く起動する方法を紹介した 既存の投稿 があります。 Amazon EventBridge と AWS System Manager を使用してコンテナイメージをノードにキャッシュし、新しいイメージがイメージレジストリにプッシュされたときにキャッシュを更新します。既存のワーカーノードや継続的なイメージキャッシュに適しています。しかし、クラスターがスケールアップするにつれて新しいワーカーノードが追加されると、すべてのイメージを新しいワーカーノードに取り込むのに時間がかかります。 この投稿では、 Bottlerocket で実行されるインスタンスを使用して、この課題に取り組むためのソリューションを紹介します。Bottlerocket は、AWS がコンテナの実行専用に設計した、オープンソースの Linux ベースのオペレーティングシステム (OS) であり、大きなイメージのコンテナ起動時間を短縮するのに役立ちます。 ソリューションの概要 コンテナランタイムが新しいコンテナを開始すると、まずローカルディスクに必要なイメージコンテンツがあるかどうかを確認します。 image pull policy が明示的に Always に設定されていない限り、これはデフォルトの動作です。これにより、システムは常にイメージリポジトリからイメージを取得します。 イメージがローカルに存在しない場合は、イメージリポジトリからイメージを取得します。この取得プロセスには、特にサイズが数 GB の大きなイメージの場合、数分以上かかることがあります。 コンテナイメージの取得プロセスを高速化するには、次のようないくつかのオプションがあります。 スリムなベースイメージを選択して、コンテナイメージのサイズを最小化する マルチステージビルド を使用して、不要な中間コンテンツを取り除く より大きなインスタンスサイズでより高い帯域幅を採用することで、コンテナイメージのダウンロードを高速化する コンテナイメージの内容をローカルでプリフェッチすることで、イメージをダウンロードする必要をなくす シナリオによっては、前述のオプション 1 と 2 を適用した後でも、コンテナイメージのサイズがまだ大きい場合があります。明らかにこのようなシナリオでは、オプション 4 の方が高速でコスト効率の高い選択肢です。 この記事では、Bottlerocket オペレーティングシステムのデータボリューム機能をどのように利用してコンテナイメージをプリフェッチできるかを詳しく説明します。これにより、特にデータ分析や AI/ML などのシナリオでは、コンテナを起動するまでの時間を短縮できる可能性があります。 Bottlerocket とは Bottlerocket は Linux ベースのオープンソースオペレーティングシステムで、アマゾン ウェブ サービスがコンテナの実行専用に開発したものです。安全で一貫性があり、効率的に運用できるように設計されています。 Bottlerocket には、OS ボリュームとデータボリュームの2つのボリュームがあります。OS ボリュームは OS データとブートイメージの保存に使用されます。Bottlerocket は、一貫性を保証するために、毎回まったく同じ OS イメージから起動します。一方、データボリュームは、コンテナのメタデータや、イメージやエフェメラルボリュームなどのストレージの保存に使用されます。Bottlerocket について詳しく知りたい場合は、 こちら のドキュメントをご覧ください。 なぜ Bottlerocket を選択するのか Amazon EKS は、Amazon Linux と Bottlerocket を利用した Amazon EKS 最適化 Amazon Machine Images (AMI) を提供します。Amazon Linux AMI は、Amazon EKS マネージド型ノードグループのデフォルトの選択肢であり、最も一般的な AMI です。ただし、デフォルトでは OS とコンテナデータが共有されるボリュームは 1 つだけです。Amazon Linux AMI とは異なり、Bottlerocket AMI はコンテナデータ用のボリュームをネイティブで提供します。 Bottlerocket のこの設計により、OS バイナリの更新とセキュリティパッチのサイクルとは別に、プリフェッチされたイメージを含むデータボリュームを簡単にアタッチできます。 図 1. Bottlerocket のボリューム 出典: Bottlerocket – a container-optimized Linux. コンテナイメージをプリフェッチするにはどうすればよいか このソリューションでは、Bottlerocket データボリュームの Amazon Elastic Block Store ( Amazon EBS ) スナップショットを作成し、そのスナップショットを Amazon EKS ノードグループで再利用して、ワーカーノードが起動した時点で必要なすべてのイメージがローカルディスクにプリフェッチされるようにします。 このプロセスはスクリプトによって自動化されており、詳細は以下のとおりです。 Amazon EKS 最適化 Bottlerocket AMI を使用して Amazon Elastic Compute Cloud ( Amazon EC2 ) インスタンスを起動します イメージリポジトリからアプリケーションイメージを取得します Bottlerocket データボリュームの Amazon EBS スナップショットを取得します Amazon EKS ノードグループを作成し、スナップショットをそのデータボリュームにマッピングします 図 2.アーキテクチャ 出典: Caching Container Images for AWS Bottlerocket Instances 次のセクションでは、ソリューション全体を段階的に説明します。コンテナの起動時間を短縮し、ビジネス目標をより効率的に達成する方法を学びます。 前提条件 本ブログのウォークスルーを実行する前に、以下の準備が必要です。 AWS アカウント 以下のコマンドラインツールのインストール eksctl: 0.147.0 kubectl: Major: version 1, Minor: version 27, GitVersion: v1.27.2 Amazon EKS cluster version: 1.24 jq: jq-1.6 Optional – Karpenter : v0.31 AWS Cloud9 環境をセットアップ AWS Cloud9 統合開発環境 (IDE) は、いくつかのプログラミング言語とランタイムデバッガ、そしてビルトインターミナルをサポートし、リッチなコード編集体験を提供します。この記事では、AWS Asia Pacific（東京）リージョン内の AWS Cloud9 ですべてのコマンドを実行します。セットアップのガイドラインは こちら です。 リポジトリをクローンする 以下のコマンドを実行します。 cd ~/environment git clone https://github.com/aws-samples/containers-blog-maelstrom.git cd containers-blog-maelstrom/bottlerocket-images-cache find . -name "*.sh" | xargs chmod +755 AWS CLI などの必要なツールをインストール ウォークスルーを実行するために、jq、eksctl、kubectl、AWS Command Line Interface（AWS CLI）などのコマンドラインツールをインストールする必要があります。以下のコマンドを実行して、これらのツールをインストールします。 cd ~/environment/containers-blog-maelstrom/bottlerocket-images-cache ./cloud9_init.sh 初期設定が成功したかどうかを以下のコマンドで確認します。 eksctl version aws sts get-caller-identity --query Arn | grep eksworkshop-admin -q && echo "IAM role valid" || echo "IAM role NOT valid" 環境変数を設定 AWS Cloud9 のターミナルで、以下のコマンドを実行します。 export ACCOUNT_ID=$(aws sts get-caller-identity --output text --query Account) export AWS_REGION=$(curl -s 169.254.169.254/latest/dynamic/instance-identity/document | jq -r '.region') export AZS=($(aws ec2 describe-availability-zones --query 'AvailabilityZones[].ZoneName' --output text --region $AWS_REGION)) export EKS_CLUSTER_NAME=bottlerocket-eks-simulation test -n "$AWS_REGION" && echo AWS_REGION is "$AWS_REGION" || echo AWS_REGION is not set echo "export ACCOUNT_ID=${ACCOUNT_ID}" | tee -a ~/.bash_profile echo "export AWS_REGION=${AWS_REGION}" | tee -a ~/.bash_profile echo "export AZS=(${AZS[@]})" | tee -a ~/.bash_profile echo "export AZS=(${AZS[@]})" | tee -a ~/.bash_profile echo "export EKS_CLUSTER_NAME=${EKS_CLUSTER_NAME}" | tee -a ~/.bash_profile aws configure set default.region ${AWS_REGION} aws configure get default.region ウォークスルー ステップ 1: Bottlerocket 用の Amazon EBS スナップショットをビルドする この投稿では、次の 2 つのイメージを Amazon EBS ボリュームにプリフェッチします。 ecr.aws/kubeflow-on-aws/notebook-servers/jupyter-pytorch: 1.12.1-cpu-py38-ubuntu20.04-ec2-v1.2 ecr.aws/eks-distro/kubernetes/pause: 3.2 Amazon EBS スナップショットワークフローを自動化するスクリプトを作成しました。このスクリプトは ~/environment/containers-blog-maelstrom/bottlerocket-images-cache にあります。次のコマンドを実行してスナップショットの作成を開始します。 cd ~/environment/containers-blog-maelstrom/bottlerocket-images-cache ./snapshot.sh -r $AWS_REGION public.ecr.aws/eks-distro/kubernetes/pause:3.2,public.ecr.aws/kubeflow-on-aws/notebook-servers/jupyter-pytorch:1.12.1-cpu-py38-ubuntu20.04-ec2-v1.2 複数のイメージのURL をカンマで区切ったコマンドに入れることができることに注意してください。 snapshot.sh スクリプトは、自動的に次のタスクを完了します。 Amazon EKS 最適化 Bottlerocket AMI を使用して Amazon EC2 インスタンスを起動します イメージリポジトリからアプリケーションイメージを取得します Amazon EC2 インスタンスを停止します。 Bottlerocket データボリュームの Amazon EBS スナップショットを取得します Amazon EC2 インスタンスを削除します Amazon EBS スナップショットの作成には約 5 分かかります。ただし、イメージサイズが大きい場合は、時間がかかる場合があります。最終的に、必要なコンテナイメージがプリフェッチされた Amazon EBS スナップショットができあがります。 以下は成功した出力の例です。 [1/8] Deploying EC2 CFN stack ... Waiting for changeset to be created.. Waiting for stack create/update to complete Successfully created/updated stack - Bottlerocket-ebs-snapshot [2/8] Launching SSM . done! [3/8] Stopping kubelet.service .. done! [4/8] Cleanup existing images .. done! [5/8] Pulling ECR images: public.ecr.aws/eks-distro/kubernetes/pause:3.2 - amd64 ... done public.ecr.aws/eks-distro/kubernetes/pause:3.2 - arm64 ... done public.ecr.aws/kubeflow-on-aws/notebook-servers/jupyter-pytorch:1.12.1-cpu-py38-ubuntu20.04-ec2-v1.2 - arm64 ... done done! [6/8] Stopping instance ... done! [7/8] Creating snapshot ... done! [8/8] Cleanup. -------------------------------------------------- All done! Created snapshot in ap-northeast-1: snap-xxxxxxxxx Amazon EBS snapshot id を環境変数に出力 Amazon EBS スナップショットコマンドを正常に実行した後、この Amazon EBS snapshot id を確認することができます。これから利用するためにこの値を環境変数として出力します。 EBS_SNAPSHOT_ID=snap-xxxxxxx echo "export EBS_SNAPSHOT_ID=${EBS_SNAPSHOT_ID}" | tee -a ~/.bash_profile ステップ 2: Amazon EKS のクラスターをセットアップ eksctl を利用して、クラスター設定を作成 AWS Cloud9 のターミナルを開き、新しい Amazon EKS クラスターを作成するための以下のコマンドを実行します。新しいクラスターを作成する時間は、15 分〜 20 分程度かかります。 cd ~/environment/containers-blog-maelstrom/bottlerocket-images-cache cat <<EOF> eks-clusterconfig.yaml --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: $EKS_CLUSTER_NAME region: $AWS_REGION version: '1.24' iam: withOIDC: true managedNodeGroups: - name: no-prefetch-mng instanceType: m5.2xlarge desiredCapacity: 1 minSize: 1 maxSize: 2 privateNetworking: true amiFamily: Bottlerocket - name: prefetch-mng instanceType: m5.2xlarge desiredCapacity: 1 minSize: 1 maxSize: 2 privateNetworking: true amiFamily: Bottlerocket additionalVolumes: - volumeName: '/dev/xvda' # OS Volume - volumeName: '/dev/xvdb' # Data Volume snapshotID: $EBS_SNAPSHOT_ID EOF eksctl create cluster -f eks-clusterconfig.yaml Bottlerocket のためのマネージド型ノードグループをセットアップ この YAML ファイルでは、次の 2 つの Amazon EKS ノードグループを含む新しい Amazon EKS クラスターを作成しました。 no-prefetch-mng ノードグループは、ステップ 2 で Amazon EBS Snapshot_ID を使用せずに Amazon EKS ノードを起動します。つまり、Amazon EKS ノードにはプリフェッチされたイメージがありません prefetch-mng ノードグループは、Amazon EBS Snapshot_ID が /dev/xvdb にマップされた Amazon EKS ノードを起動します。つまり、イメージはすでに Amazon EKS ノードでプリフェッチされています。詳細については、YAML ファイルの additionalVolumes セクションを参照してください Amazon EKS クラスターに接続 aws eks update-kubeconfig --name $EKS_CLUSTER_NAME --region $AWS_REGION ノードの準備が完了することを待つ 次のコマンドを使用して、ノードの準備が整っているかどうかを確認できます。 watch kubectl get nodes 2 つのノードが準備完了状態になるまで待ってください。次のような出力が得られます。 Every 2.0s: kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME ip-192-168-xxx-xxx.ap-northeast-1.compute.internal Ready <none> 2m36s v1.24.15-eks-fae4244 192.168.xxx.xxx <none> Bottlerocket OS 1.14.2 (aws-k8s-1.24) 5.15.117 containerd://1.6.20+bot tlerocket ip-192-168-xxx-xxx.ap-northeast-1.compute.internal Ready <none> 2m30s v1.24.15-eks-fae4244 192.168.xxx.xxx <none> Bottlerocket OS 1.14.2 (aws-k8s-1.24) 5.15.117 containerd://1.6.20+bot tlerocket ステップ 3: 両方のノードグループにデプロイを開始する Kubernetes Deployment では public.ecr.aws/kubeflow-on-aws/notebook-servers/jupyter-pytorch: 1.12.1-cpu-py38-ubuntu20.04-ec2-v1.2 イメージを使用しています。イメージサイズは 4.93 GB です。ワーカーノードがイメージをプリフェッチしていない場合、Pod が起動する前に Amazon ECR からイメージをダウンロードするのにしばらく時間がかかります。 各ノードグループに 2 つの Pod を作成するには、以下のコマンドを使用します。 kubectl apply -f - << EOF apiVersion: apps/v1 kind: Deployment metadata: name: inflate-no-prefetch spec: replicas: 1 selector: matchLabels: app: inflate-no-prefetch template: metadata: labels: app: inflate-no-prefetch spec: terminationGracePeriodSeconds: 0 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "alpha.eksctl.io/nodegroup-name" operator: "In" values: ["no-prefetch-mng"] containers: - name: inflate-amazon-linux image: public.ecr.aws/kubeflow-on-aws/notebook-servers/jupyter-pytorch:1.12.1-cpu-py38-ubuntu20.04-ec2-v1.2 resources: requests: cpu: 1 EOF kubectl apply -f - << EOF apiVersion: apps/v1 kind: Deployment metadata: name: inflate-prefetch spec: replicas: 1 selector: matchLabels: app: inflate-prefetch template: metadata: labels: app: inflate-prefetch spec: terminationGracePeriodSeconds: 0 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "alpha.eksctl.io/nodegroup-name" operator: "In" values: ["prefetch-mng"] containers: - name: inflate-bottlerocket image: public.ecr.aws/kubeflow-on-aws/notebook-servers/jupyter-pytorch:1.12.1-cpu-py38-ubuntu20.04-ec2-v1.2 resources: requests: cpu: 1 EOF コンテナのデフォルトの image pull policy は ifNotPresent です。つまり、イメージがまだローカルに存在していない場合にのみイメージがプルされます。image pull policy が Always に設定されている場合、プリフェッチ機能は動作しません。 inflate-no-prefetch Pod のイベントをチェック kubectl get events コマンドを使用して、Pod 内のイベントをトレースできます。 NO_PREFETCH_POD=$(kubectl get pod -l app=inflate-no-prefetch -o jsonpath="{.items[0].metadata.name}") kubectl get events -o custom-columns=Time:.lastTimestamp,From:.source.component,Type:.type,Reason:.reason,Message:.message --field-selector involvedObject.name=$NO_PREFETCH_POD,involvedObject.kind=Pod inflate-no-prefetch Deployment からの Pod イベントは次のとおりです。 Time From Type Reason Message 2023-08-07T17:13:52Z default-scheduler Normal Scheduled Successfully assigned default/inflate-no-prefetch-6c45cd9b4c-c7dn8 to ip-192-168-180-250.ap-northeast-1.compute.internal 2023-08-07T17:13:53Z kubelet Normal Pulling Pulling image "public.ecr.aws/kubeflow-on-aws/notebook-servers/jupyter-pytorch:1.12.1-cpu-py38-ubuntu20.04-ec2-v1.2" 2023-08-07T17:14:41Z kubelet Normal Pulled Successfully pulled image "public.ecr.aws/kubeflow-on-aws/notebook-servers/jupyter-pytorch:1.12.1-cpu-py38-ubuntu20.04-ec2-v1.2" in 48.003125227s 2023-08-07T17:14:41Z kubelet Normal Created Created container inflate-amazon-linux 2023-08-07T17:14:41Z kubelet Normal Started Started container inflate-amazon-linux Pod は 2023-08-07T 17:13:52 Z に予定されていて、2023-08-07T 17:14:41 Z に開始されました。Amazon ECR から大きなイメージを取得するのに時間がかかるため、コンテナを起動するのに 49 秒かかりました。 inflate-prefetch Pod のイベントを確認 PREFETCH_POD=$(kubectl get pod -l app=inflate-prefetch -o jsonpath="{.items[0].metadata.name}") kubectl get events -o custom-columns=Time:.lastTimestamp,From:.source.component,Type:.type,Reason:.reason,Message:.message --field-selector involvedObject.name=$PREFETCH_POD,involvedObject.kind=Pod inflate-prefetch Deployment からの Pod イベントは次のとおりです。 Time From Type Reason Message 2023-08-07T17:13:53Z default-scheduler Normal Scheduled Successfully assigned default/inflate-prefetch-f5ff79858-g87cb to ip-192-168-97-187.ap-northeast-1.compute.internal 2023-08-07T17:13:54Z kubelet Normal Pulled Container image "public.ecr.aws/kubeflow-on-aws/notebook-servers/jupyter-pytorch:1.12.1-cpu-py38-ubuntu20.04-ec2-v1.2" already present on machine 2023-08-07T17:13:55Z kubelet Normal Created Created container inflate-bottlerocket 2023-08-07T17:13:56Z kubelet Normal Started Started container inflate-bottlerocket Pod は 2023-08-07T 17:13:53 Z に予定されていて、2023-08-07T 17:13:56 Z に開始されました。コンテナイメージはすでに Amazon EKS ノードに存在していたため、コンテナを起動するのに 3 秒しかかかりませんでした。 ステップ 4: 結果 サイズの大きなコンテナイメージをプリフェッチすることで、Pod の起動にかかる時間を 49 秒からわずか 3 秒に短縮できました。 図3. 本ソリューションの適用/未適用における比較 他参考情報 Karpenter Karpenter は、Kubernetes クラスタ内の Pod のスケジューリングを処理するために、コンピューティングリソースを自動的にスケーリングするためのオープンソースプロジェクトです。また、Amazon EBS スナップショットを使用して Bottlerocket ワーカーノードを起動するためにも使用できます。Karpenter Provisioner とノードテンプレートのサンプルは次のとおりです。 尚、Karpenter は alpha から beta に昇格することとなっており、その過程で APIに変更が入っています。以下に記載したサンプルは、変更前のサンプルとなります。変更についての詳細は、 こちらのブログ をご参照ください。 apiVersion: karpenter.sh/v1alpha5 kind: Provisioner metadata: name: bottlerocket-provisioner spec: providerRef: name: bottlerocket labels: billing-team: map-team annotations: example.com/owner: "my-team" requirements: - key: "node.kubernetes.io/instance-type" operator: In values: ["m5.2xlarge"] - key: "karpenter.sh/capacity-type" operator: In values: [ "spot", "on-demand" ] limits: resources: cpu: 1000 ttlSecondsAfterEmpty: 30 weight: 20 --- apiVersion: karpenter.k8s.aws/v1alpha1 kind: AWSNodeTemplate metadata: name: bottlerocket spec: subnetSelector: karpenter.sh/discovery: xxxxxxxx-stack securityGroupSelector: karpenter.sh/discovery: xxxxxxxx-stack amiFamily: Bottlerocket tags: managed-by: "karpenter" intent: "api-server" blockDeviceMappings: - deviceName: /dev/xvda ebs: volumeSize: 10Gi volumeType: gp3 - deviceName: /dev/xvdb ebs: volumeSize: 80Gi volumeType: gp3 snapshotID: snap-xxxxxxxxxx subnetSelector のスタック名と、blockDeviceMappings の snapshotID を忘れずに更新してください。 Automation コンテナイメージのビルドが完了した直後に Amazon EBS スナップショットの作成を開始したい場合は、コンテナビルド後に snapshot.sh を継続的インテグレーション (CI) ツールで実行できます。GitHub Actions を使用した自動化スクリプトのサンプルを作成し、そのスクリプトを GitHub にプッシュしています。 説明のために、GitHub Action YAML のセクションを抽出しました。Job セクションは、build_llm_image と build_ebs の 2 つの部分に分かれています。 build_llm_image は主にコンテナイメージをビルドします。これは標準の Docker ビルドプロセスなので、次の YAML ファイルではこの部分は省略します build_ebs は、Amazon EBS スナップショットを取る際の核となる部分です name: Build LLM Model and EBS Snapshot on: push: branches: [ master ] paths: - 'sd-gen-sdkxl-consumer/**' jobs: build_llm_image: runs-on: ubuntu-latest steps: // ... // skip build steps for docker login, docker build, docker push // for the complete script, please reference GitHub repo build_ebs: runs-on: ubuntu-latest # Only Run after `build_llm_image` job success (image have been pushed to ECR) needs: build_llm_image steps: - name: Checkout source code uses: actions/checkout@v2 - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v1 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: YOUR_AWS_REGION - name: Build EBS Snapshot id: build-ebs-snapshot env: SNAPSHOT_ID: "" run: | cd sd-gen-sdkxl-consumer/automation . ./../run.sh echo "SNAPSHOT_ID:" $SNAPSHOT_ID - name: Commit and Push NodeTemplate id: update-node-template run: | echo "commit and push now" echo "SNAPSHOT_ID" $SNAPSHOT_ID Configure AWS credentials ステップでは、GitHub Action ランナーが Amazon EBS スナップショットスクリプトを実行するための正しい AWS IAM アクセス権限を提供します。必要な AWS IAM 権限は、 こちら で確認できます。この AWS IAM ポリシーを本番環境で使用する場合は、アクセス権限をできるだけ減らすことをお勧めします。尚、2023/12/5 時点においては、GitHub Actions から OIDC を利用し IAM Role を assume する方法が主流となっております。詳細については、GitHub のドキュメント Configuring OpenID Connect in Amazon Web Services をご参照ください。 Build EBS Snapshot ステップでは、Amazon EBS スナップショットスクリプトの実行が開始されます Commit and Push NodeTemplate ステップでは、Amazon EBS SNAPSHOT_ID を取得します。その後、それを Amazon EKS YAML GitHub リポジトリにコミットして、ノードテンプレートを更新できます。 GibHub Action YAML ファイル全体に説明を追加していますので、ご参照ください。 クリーンアップ Amazon EKS クラスタとノード この記事で紹介したウォークスルーに従った場合料金が発生します。それを避ける場合には、以下のコマンドを実行して作成したリソースを削除することができます。 kubectl delete deploy inflate-no-prefetch --force kubectl delete deploy inflate-prefetch --force eksctl delete nodegroup no-prefetch-mng --cluster $EKS_CLUSTER_NAME eksctl delete nodegroup prefetch-mng --cluster $EKS_CLUSTER_NAME eksctl delete cluster --name $EKS_CLUSTER_NAME AWS Cloud9 環境 AWS Cloud9 環境を忘れずに削除してください。以下に削除方法を記載します。 以下の AWS CLI で AWS Cloud9 環境の Id を取得します。 aws cloud9 list-environments // Output: { "environmentIds": [ "5d36cbf9b1e54fa0af7aa80eef9bbb42" ] } AWS Cloud9 環境を削除するには、以下の CLI コマンドを使用することもできます。以下のコマンドの YOUR_CLOUD9_ENV_ID を置き換えて、AWS Cloud9 環境を削除してください。 aws cloud9 delete-environment --region $AWS_REGION --environment-id YOUR_CLOUD9_ENV_ID Amazon EBS スナップショット 作成された Amazon EBS スナップショットを削除するには、次の AWS CLI コマンドを実行します。 snapshot.sh. aws ec2 delete-snapshot --snapshot-id $EBS_SNAPSHOT_ID まとめ この記事では Bottlerocket インスタンスのデータボリュームを使用してコンテナイメージをプリフェッチすることで、Amazon ECR から大きなイメージを引き出すのに必要な時間を大幅に短縮できることを紹介しました。この最適化により、起動時間が短縮され、Amazon EKS 上でのコンテナ起動の効率とパフォーマンスが劇的に改善されました。 このソリューションは、大きなコンテナイメージに依存するコンテナワークロードを持ち、起動時間を短縮することでアプリケーションの起動パフォーマンスを向上させようとしている組織にとって、大きなメリットになると確信しています。Bottlerocket の詳細については、 Bottlerocket の公式ウェブサイト にアクセスしてください。 謝辞 私たちにインスピレーションを与え、この投稿を可能にするコードを提供してくれた同僚の Walkely He と Dongdong Yang に心から感謝します。 翻訳はパートナーソリューションアーキテクトの髙橋達矢が担当しました。原文は こちら です。

Amazon Kendra は、機械学習（ML）を活用した高精度で使いやすいインテリジェント検索サービスです。Amazon Kendra は、さまざまなデータソースコネクタを提供し、どんな場所に置かれているコンテンツでも取り込みと索引付けのプロセスを簡単にします。 組織内の貴重なデータは、構造化されたリポジトリと非構造化リポジトリの両方に保存されています。エンタープライズ検索ソリューションは、さまざまなデータソースからコンテンツを索引付けするプロセスを簡素化し、完全に管理された体験を提供する必要があります。 このような非構造化データリポジトリの一例が、内部および外部ウェブサイトです。ニュースフィードを作成したり、言語の使用を分析したり、ウェブサイトのデータに基づいて質問に答えるボットを作成するために、サイトをクロールする必要がある場合があります。 新しい Amazon Kendra Web Crawler を使用すると、内部および外部ウェブサイトに保存されているコンテンツから回答を検索したり、チャットボットを作成することができます。この投稿では、ウェブサイトに保存されている情報を索引付けし、Amazon Kendra のインテリジェント検索を使用して、内部および外部ウェブサイトに保存されているコンテンツから回答を検索する方法を紹介します。さらに、機械学習で強化されたインテリジェント検索では、キーワード検索が効果的でない自然言語のナラティブを含む非構造化ドキュメントから質問に対する正確な回答を得ることができます。 Web Crawler は、以下の新機能を提供します： 基本的な NTLM / Kerberos 、フォーム、および SAML 認証のサポート 100 個のシード URL を指定し、接続構成を Amazon Simple Storage Service （Amazon S3）に保存する機能 プロキシ資格情報を提供する機能を持つウェブおよびインターネットプロキシのサポート JavaScript を含むウェブサイトなどの動的コンテンツのクロールをサポート フィールドマッピングと正規表現フィルタリング機能 ソリューションの概要 Amazon Kendra を利用すると、複数のデータソースを設定し、ドキュメントリポジトリ全体での検索を一元化することができます。私たちのソリューションでは、 Amazon Kendra Web Crawler を使用してクロールされたウェブサイトをインデックス化する方法を示します。このソリューションは以下のステップで構成されています： ウェブサイトの認証メカニズムを選択し（必要な場合）、 AWS Secrets Manager に詳細を保存する。 Amazon Kendra インデックスを作成する。 Amazon Kendra コンソールを介して Web Crawler データソース V2 を作成する。 ソリューションをテストするためにサンプルクエリを実行する。 前提条件 Amazon Kendra Web Crawler を試すためには、以下が必要です： クロールするウェブサイト。 AWS Identity and Access Management （IAM）のロールおよびポリシーを作成する権限を持つ AWSアカウント 。詳細については、 アクセス管理の概要：アクセス許可とポリシー を参照してください。 AWSサービスの特徴や権限設定など、利用する上で知っておくべき基礎知識 認証の詳細を集める 保護されている安全なウェブサイトの場合、以下の認証タイプと標準がサポートされています： Basic 認証 NTLM / Kerberos フォーム認証 SAML データソースを設定するときに、認証情報が必要です。 基本または NTLM 認証の場合、Secrets Manager のシークレット、ユーザー名、パスワードを提供する必要があります。 フォームと SAML 認証には、以下のスクリーンショットに示されているように、 User name button や Xpath のような一部のフィールドはオプションであり、クロールするサイトが User name の入力後にボタンを使用しているかどうかによります。また、User name と Password フィールドおよび送信ボタンの Xpath をどのように決定するかを知っている必要があります。 Amazon Kendra インデックスを作成する Amazon Kendra インデックスを作成するには、以下の手順を完了します： Amazon Kendraコンソールで、 「Create an Index」 を選択します。 「Index name」 に、インデックスの名前を入力します（例：Web Crawler）。 任意の説明を入力します。 「Role name」 に、IAMロール名を入力します。 任意の暗号化設定とタグを設定します。 「Next」 を選択します。 「Configure user access control」 セクションで、設定をデフォルトのままにして 「Next」 を選択します。 「Provisioning editions」 で、 Developer edition を選択し、 「Next」 を選択します。 レビューページで、 「Create」 を選択します。 これによりIAMロールが作成および伝播され、その後 Amazon Kendra インデックスが作成されます。これには最大30分かかることがあります。 Amazon Kendra Web Crawler データソースを作成する データソースを作成するために、以下の手順を完了します： Amazon Kendra コンソールで、ナビゲーションペインの 「Data sources」 を選択します。 WebCrawler コネクタ V2.0 のタイルを探し、 「Add connector」 を選択します。 「Data source name」 に名前を入力します（例：crawl-fda）。   任意の説明を入力します。 「Next」 を選択します。 「Source」 セクションで、 「Source URL」 を選択し、URLを入力します。この投稿では、例として https://www.fda.gov/ を使用します。 「Authentication」 セクションで、クロールしたいサイトに基づいて適切な認証を選択します。この投稿では、公開サイトで認証が不要なため 「No authentication」 を選択します。 「Web proxy」 セクションでは、Secrets Manager のシークレットを指定できます（必要に応じて ）。 1. 「Create and Add New Secret」 を選択します。 2. 以前に収集した認証の詳細を入力します。 3. 「Save」 を選択します。 「IAM role」 セクションで、 「Create a new role」 を選択し、名前を入力します（例：AmazonKendra-Web Crawler-datasource-role）。 「Next」 を選択します。 「Sync scope」 セクションで、クロールするサイトに基づいて同期設定を構成します。この投稿では、すべてのデフォルト設定をそのまま使用します。 「Sync mode」 で、インデックスをどのように更新するかを選択します。この投稿では、 「Full sync」 を選択します。 「Sync run schedule」 で、 「Run on demand」 を選択します。 「Next」 を選択します。 必要に応じて、フィールドマッピングを設定できます。この記事ではデフォルトのままにします。 フィールドのマッピングは、フィールド名を組織の語彙に合ったユーザーフレンドリーな値に置き換える設定です。 「Next」 を選択します。 「Add data source」 を選択します。 データソースの同期を行うには、データソースの詳細ページで 「Sync now」 を選択します。 同期が完了するのを待ちます。 認証付きウェブサイトの例 認証が必要なサイトをクロールしたい場合は、前述の手順の 「Authentication」 セクションで認証の詳細を指定する必要があります。 フォーム認証 を選択した場合の例は以下の通りです。 「Source」 セクションで、 「Source URL」 を選択し、URLを入力します。この例では、 https://accounts.autodesk.com を使用します。 「Authentication」 セクションで、 「Form authentication」 を選択します。 「Web proxy」 セクションで、Secrets Manager のシークレットを指定します。これは、 「No authentication」 以外のオプションに必要です。 「Create and Add New Secret」 を選択します。 以前に収集した認証の詳細を入力します。 「Save」 を選択します。 ソリューションをテストする サイトからのコンテンツを Amazon Kendra インデックスに取り込んだので、いくつかのクエリをテストできます。 あなたのインデックスに移動し、 「Search indexed content」 を選択します。 サンプル検索クエリを入力し、検索結果をテストします（クエリは、クロールしたサイトのコンテンツと入力したクエリに基づいて異なります）。 おめでとうございます！ Amazon Kendra を使用して、クロールしたサイトのインデックス化されたコンテンツに基づいて回答と洞察を得ることに成功しました。 クリーンアップ 今後のコストを発生させないように、このソリューションの一環として作成したリソースをクリーンアップしてください。このソリューションをテストするために新しい Amazon Kendra インデックスを作成した場合は、それを削除してください。 Amazon Kendra Web Crawler V2 を使用して新しいデータソースのみを追加した場合は、そのデータソースを削除してください。 結論 新しい Amazon Kendra Web Crawler V2 を使用することで、組織は公開サイトまたは認証が必要なサイトをクロールし、Amazon Kendraによるインテリジェントな検索のために使用することができます。 これらの可能性やその他の詳細については、 Amazon Kendra 開発者ガイド を参照してください。データの取り込み時にメタデータとコンテンツを作成、変更、削除する方法の詳細については、「 取り込み中にドキュメントを充実させる 」および「 コンテンツとメタデータを強化して、Amazon Kendra のカスタムドキュメント強化で検索体験を向上させる 」を参照してください。 翻訳はソリューションアーキテクトの西田 光彦が担当しました。原文は こちら です。 著者について Jiten Dedhia は、ソフトウェア業界で20年以上の経験を持つシニアソリューションアーキテクトです。彼はグローバルなファイナンスサービスのクライアントと協力して、AWS が提供するサービスを利用して最新化するためのアドバイスを提供してきました。 Gunwant Walbe は、アマゾンウェブサービスのソフトウェア開発エンジニアです。彼は熱心な学習者であり、新しいテクノロジーの採用に熱心です。彼は複雑なビジネスアプリケーションを開発しており、主な言語は Java です。

製品の戦略は、消費者の需要、技術、競争の組み合わせによって形成されます。業界では、変化のたびに新製品が登場します。多くの場合、最新のテクノロジーを活用した新機能が追加され、ユーザーエクスペリエンスが向上します。 これにより、以前のバージョンの製品の段階的な廃止も開始されます。 その代表的な例が、スマートフォンの新しいモデルの導入と前モデルの段階的な廃止を特徴とする年間リリースサイクルです。 新製品には需要の実績がないため、組織や需要計画担当者にとって運用上の重大な課題となります。新製品の導入にあたって、新製品の需要に対応し、古い製品や従来製品の予測をスムーズに減らすために、精度の高い予測が必要です。需要の実績がないため、需要計画担当者は新製品と従来製品の類似点を導き出すのに勘・コツに頼りがちです。このような手動の予測調整は最適ではなく、非効率的で、予測の精度向上の難しさによって複雑になります。組織は、より迅速かつ効率的な需要計画のための自動化されたソリューションを求めています。 このブログ記事では、過去の売上データがない新製品の導入に伴う課題に対処するために AWS Supply Chain Demand Planning が提供するソリューションについて詳しく説明します。製品系統と製品ライフサイクルの両方の機能を検討し、データと設定を行うための重要な手順をご案内します。 ライフサイクルにおける段階の管理 正確性を確保するために、製品の予測は、製品の実際に提供販売されている期間にのみ適用させる必要があります。このアプローチを見落とすと、過剰在庫など在庫に関する重大な問題が発生する可能性があります。AWS Supply Chain Demand Planning を使用すると、製品ライフサイクルを定義できるため、製品のアクティブなライフサイクルについてのみ予測を作成できます。製品の導入と廃止のための予測パラメータを設定することで、新製品の不足と廃止製品の過剰在庫のリスクを最小限に抑えることができます。 段階的な販売プロファイルを持つ製品のライフサイクルの境界を定義するには、製品マスターデータファイルに 発売日 ( product_available_day 列), 販売終了日 ( discontinue_day 列) の日付を取り込むことができます。以下のスクリーンショットは、製品マスターのサンプルデータの設定例で、フィールドが強調表示されています。 データ設定の詳細については、 製品ライフサイクル ユーザーガイドを参照してください。さまざまなレガシーシステムからデータを変換およびアップロードする手順と前提条件については、以前の ブログ をご覧ください。 柔軟性を高める追加の設定 次に、以前の ブログ で取り上げた設定に基づいて、 発売日 と 販売終了日 の値を変更して、特定のビジネス要件に合わせて調整できます。これは、特に戦略的な在庫管理の目的で、標準的な発売日や販売終了日を超えてさらなる柔軟性を求める場合に重要になります。次のスクリーンショットに設定画面が示されています。ここで、製品ライフサイクルに合わせて、予測開始日と終了日を設定できます。 正確な予測のためのデータ収集 効果的な需要計画には、計画担当者が以前のモデルや代替製品の販売履歴を含めて、正確な予測を作成する必要があります。 製品系統 を使用すると、製品とその前のバージョンや代替製品との間にリンクを確立できるようになりました。このリンクには、予測のために使用する履歴の範囲を定義するルールが組み込まれ、製品の製品履歴の代替データが作成されます。 以下の手順で 履歴がほとんどない、または全くない製品に対して product_alternate エンティティを利用して、データを取り込むことができます。 alternative_product_id 列で、予測パターンをコピーする元となる製品を定義できます。予測パターンのコピー元製品は、 product_id 列で指定されたターゲット製品にコピーされます。 alternate_product_qty は、代替製品の過去の販売実績に割り当てられた重みを示しています。有効期間は、考慮する代替製品の過去の販売実績の期間を示しています。 product_alternate エンティティを設定したサンプルデータを次のスクリーンショットに示します。強調表示されたフィールドは、代替製品とターゲット製品について複製できる履歴の範囲を示しています。 データセットアップの詳細については、 製品系統 のユーザーガイドを参照してください。 需要計画を実行に移す データを取り込み、予測開始と終了の設定を行った後、アプリケーションは需要計画を生成します。画面上では、製品ライフサイクルフェーズ NPI ( New Product Introduction：新製品の導入 ) または EOL ( End of Life：廃止 ) が状況確認のために表示されます。予測に製品系統の履歴が組み込まれている場合は、透明性のために、その旨が注釈として追記表示されます。 まとめ 製品系統と製品ライフサイクルの機能は、重要なプロセスを自動化し、予測の精度を向上させ、手動による調整の必要性を低減させます。この洗練されたアプローチは、業務効率を向上させ、新製品の先進的なサプライチェーン管理を容易にします。 AWS Supply Chain は、前払いのライセンス料や長期契約なしで利用できます。ニーズに合わせて拡張できるソリューションを提供します。そして、AWS Supply Chain Demand Planning はすべてのお客様が利用できます。詳細と開始の仕方については、 AWS Supply Chain &nbsp;をご覧ください。また、インスタンスの作成、データの取り込み、ユーザーインターフェースの操作、インサイトの作成、需要計画の生成に関する技術的な概要を自分のペースで確認できる AWS Workshop Studio &nbsp;もご覧ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Vikram Balasubramanian は、サプライチェーンのシニア・ソリューション・アーキテクトです。Vikram は、サプライチェーンの経営幹部と緊密に連携して、彼らの目標や問題点を理解し、解決策の観点からベストプラクティスと連携させています。Vikram は17年以上にわたり、サプライチェーン分野のさまざまな業種のフォーチュン500企業で働いてきました。Vikram は、パデュー大学でインダストリアルエンジニアリングの修士号を取得しています。ヴィクラムはノースダラス地域を拠点としています。 Harini Kidambi は AWS Supply Chain Demand Planning のプロダクトマネージャーです。 BlueYonderとアマゾンウェブサービス (AWS) の両方でサプライチェーンと分析の分野で5年以上の経験があります。 彼女は AWS Supply Chain のお客様と協力して、お客様のビジネスニーズを理解し、技術ソリューションとユーザーエクスペリエンスを調整し、最大のビジネス価値を実現できるよう支援しています。 <!-- '"` -->