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 のお客様と協力して、お客様のビジネスニーズを理解し、技術ソリューションとユーザーエクスペリエンスを調整し、最大のビジネス価値を実現できるよう支援しています。 <!-- '"` -->

チームを編成して優れたソフトウェア製品を提供するには、さまざまな方法があります。 Amazon の Two-Pizza チーム のように、製品に関するエンドツーエンドの責任を単一のチームに割り当てている企業もあれば、複数のチームがインフラストラクチャ (またはプラットフォーム) チームとアプリケーション開発チームの間で責任を分担している企業もあります。この記事では、 AWS Cloud Development Kit (CDK) を活用して Split-Team アプローチの場合に、コラボレーションの効率をどのように改善できるかについてのガイダンスを提供します。 AWS CDK は、クラウドアプリケーションリソースを定義するためのオープンソースのソフトウェア開発フレームワークです。そのためには、TypeScript、Python、Java、C#、Go などの使い慣れたプログラミング言語を使用します。これにより、従来のインフラストラクチャでは AWS CloudFormation や HashiCorp Terraform などの IaC ツールで表現されてきたインフラストラクチャを定義するコードと、アプリケーションをバンドル、コンパイル、パッケージングするコードを組み合わせることができます。 これは、製品に関連するすべてのコードを 1 か所と 1 つのプログラミング言語にまとめることができるため、エンドツーエンドの責任を持つ自律的なチームに最適です。1 つのチームでインフラストラクチャコードとアプリケーションコードを別のリポジトリに分ける必要はありませんが、チームが分割されるモデルについてはどうでしょうか。 大企業は通常、インフラストラクチャ (またはプラットフォーム) チームとアプリケーション開発チームの間で責任を分担します。この記事では複数のチームが関与している場合でも、AWS CDK を使用してチームの独立性と俊敏性を確保する方法を見ていきます。チームごとに異なる責任と各チームが作成した成果物を見ていきます。また、チームがスムーズに連携する方法についても説明します。 このブログ記事は、AWS CDK とその概念に関する基本的な知識があることを前提としています。さらに、イベント駆動型アーキテクチャに関する非常に高いレベルの理解も必要です。 チームトポロジ まず、さまざまなチームトポロジと各チームの責任について簡単に見てみましょう。 One-Team アプローチ このブログ記事では、以降で説明する Split-Team アプローチに焦点を当てます。ただし、「1 つのチームがアプリケーションをエンドツーエンドで所有する」という “One-Team” アプローチが何を意味するのかを理解しておくと役に立ちます。この部門の枠を超えたチームは、次に実装する機能、使用するテクノロジー、そしてその結果得られるインフラストラクチャとアプリケーションコードの構築方法とデプロイ方法を独自に決定します。チームの責任は、インフラストラクチャ、アプリケーションコード、デプロイメント、開発したサービスの運用です。 このような環境で AWS CDK アプリケーションを構築する方法に興味がある場合は、Alex Pulver のブログ記事 “ Recommended AWS CDK project structure for Python applications ” を参照してください。 Split-Teamアプローチ 実際には、アプリケーション開発とインフラストラクチャの開発と展開を別々のチームに分けるお客様が多く居ます。 インフラストラクチャチーム ここで言及するインフラストラクチャチームは、プラットフォームチームまたは運用チームとも呼ばれます。インフラストラクチャチームは、他のチームがアプリケーションを実行するために使用する共有のインフラストラクチャを設定、デプロイ、運用します。これには、 Amazon SQS キュー、 Amazon Elastic Container Service (Amazon ECS) クラスター、新しいバージョンのアプリケーションを本番環境に導入するために使用される CI/CD パイプラインなどがあります。 アプリケーションチームが開発したアプリケーションパッケージを AWS にデプロイして実行させること、およびアプリケーションの運用サポートを提供する事がインフラストラクチャチームの責任です。 アプリケーションチーム 従来、アプリケーションチームはアプリケーションのパッケージ (JAR ファイルや npm パッケージなど) を提供するだけで、AWS でのデプロイ、設定、実行の方法を考えるのはインフラストラクチャチームの責任でした。しかしながら、インフラストラクチャチームは複数のチームが開発したさまざまなアプリケーションをサポートしなければならないため、このような従来の手法ではボトルネックになることがよくあります。さらに、インフラストラクチャチームは多くの場合、それらのアプリケーションの内部構造についてほとんど知識がありません。これはしばしば、サービスのために最適化された選択肢を提供できないことにつながります。インフラストラクチャチームが提供するサービス実行のための選択肢が十分でない場合、アプリケーションチームはワークロードに最適化されたオプションを使用できません。 そのため、このブログ記事では、アプリケーションチームの従来の責任を拡張しています。チームはアプリケーションを提供し、さらにアプリケーションの実行に必要なインフラストラクチャの説明も提供します。「必要なインフラストラクチャ」とは、アプリケーションの実行に使用される AWS サービスのことです。このインフラストラクチャの説明は、インフラストラクチャチームが理解できる形式で記述する必要があります。 このような責任範囲の変化によってアプリケーションチームに追加のタスクが追加されることは理解していますが、長期的には努力する価値があると考えています。これが DevOps の概念を組織に導入する出発点になり得ます。ただし、このブログ記事で説明されている概念は、アプリケーションチームにこの責任を課したくない場合にも、まだ有効です。誰が何を提供するのかという境界線が、インフラストラクチャチームの方へ更に移るだけです。 このアプローチを成功させるには、アプリケーションの引き渡し方、インフラストラクチャの定義、本番環境への導入方法について、2 つのチームが共通の形式について合意する必要があります。Construct というコンセプトを備えた AWS CDK は、そのための役立つ手段を提供します。 入門: AWS CDK Construct このセクションでは、コードを構築するために AWS CDK が提供する概念と、これらの概念を使用して CDK プロジェクトをチームトポロジにフィットさせる方法を見ていきます。 Constructs Construct は AWS CDK アプリケーションの基本的な構成要素です。AWS CDK アプリケーションは複数の Construct で構成されており、最終的には AWS CloudFormation によってデプロイされる方法と内容が定義されます。 AWS CDK には、AWS サービスをデプロイするための Construct が付属しています。ただし、使用できるのは AWS CDK によって提供される Construct だけに限定されないことを理解しておくことが重要です。AWS CDK の真の利点は、デフォルトの Construct の上に独自の抽象化を作成して、特定の要件を満たすソリューションを作成できることです。これを実現するには、独自のカスタム Construct を作成、公開、使用する必要があります。特定の要件をコード化し、抽象化レベルを高め、他のチームがその Construct を利用したり使用したりできるようにします。 以降ではカスタム Construct を使用して、アプリケーションとインフラストラクチャチームの責任を分担します。アプリケーションチームは、アプリケーションコードの実行に必要なインフラストラクチャとその 設定を記述した Construct をリリースします。インフラストラクチャチームはこの Construct を使用して AWS にワークロードをデプロイして運用します。 Split-Team で AWS CDK を使用する方法 次は、AWS CDK を使用してアプリケーションチームとインフラストラクチャチームの間で責任を分担する方法を見てみましょう。サンプルシナリオを紹介し、このシナリオにおける各チームの責任を説明します。 シナリオ 架空のアプリケーション開発チームが AWS Lambda 関数を作成し、AWS にデプロイします。 Amazon SQS キュー内のメッセージがこの関数を呼び出します。関数が注文を処理し (この例では詳細な意味は関係ありません)、各注文はキュー内のメッセージによって表されるとします。 アプリケーション開発チームは AWS Lambda 関数を柔軟に作成できます。どのランタイムを使用するか、どのくらいのメモリを設定するかを決定できます。関数が処理する SQS キューは、インフラストラクチャチームによって作成されます。アプリケーションチームは、メッセージがどのようにキューに入るのかを知る必要はありません。 これで、チームごとに実装例を見ていきましょう。 アプリケーションチーム アプリケーションチームは、アプリケーションコード (JAR ファイルや npm モジュールなど) と、アプリケーションの実行に必要なインフラストラクチャ (AWS Lambda 関数とその設定) を AWS にデプロイするための AWS CDK Construct という 2 つの異なる成果物を担当します。 これらの成果物のライフサイクルは異なります。アプリケーションコードは、実行されるインフラストラクチャよりも頻繁に変更されます。だからこそ、成果物は別々にしておきたいのです。これにより、それぞれの成果物は、変更された場合のみ独自のペースでリリースできます。 このような個別のライフサイクルを実現するためには、アプリケーションのリリースは CDK Construct のリリースから完全に独立している必要があることに注意することが重要です。これは、CDK Construct 内でアプリケーションコードをビルドしてパッケージ化する標準的な CDK の方法と比較して、チームを分けるという私たちのアプローチに合っています。 しかし、このサンプルソリューションではどのように実現するのでしょうか？チームは CDK に関係のないアプリケーションを構築して公開します。 この Construct を含む CDK スタックを合成すると、指定されたバージョン番号のビルド済みアーティファクトを AWS CodeArtifact からダウンロードし、それを使用して Lambda 関数のための zip ファイルを作成します。CDK の合成の間は、アプリケーションパッケージのビルドは行われません。 Constructとアプリケーションコードを分離したので、CodeArtifact から取得するアプリケーションコードの特定のバージョンを CDK Construct に伝える方法を見つける必要があります。この情報をコンストラクターのプロパティを介してConstructに渡します。 アプリケーションチームの責任範囲外のインフラストラクチャへの依存関係については、依存性注入のパターンに従います。共有 VPC や Amazon SQS キューなどの依存関係は、インフラストラクチャチームから Construct に渡されます。 例を見てみましょう。SQS キューへの外部依存関係を、目的の appPackageVersion とその CodeArtifact の詳細とともに渡します。 export interface OrderProcessingAppConstructProps { queue: aws_sqs.Queue, appPackageVersion: string, codeArtifactDetails: { account: string, repository: string, domain: string } } export class OrderProcessingAppConstruct extends Construct { constructor(scope: Construct, id: string, props: OrderProcessingAppConstructProps) { super(scope, id); const lambdaFunction = new lambda.Function(this, 'OrderProcessingLambda', { code: lambda.Code.fromDockerBuild(path.join(__dirname, '..', 'bundling'), { buildArgs: { 'PACKAGE_VERSION' : props.appPackageVersion, 'CODE_ARTIFACT_ACCOUNT' : props.codeArtifactDetails.account, 'CODE_ARTIFACT_REPOSITORY' : props.codeArtifactDetails.repository, 'CODE_ARTIFACT_DOMAIN' : props.codeArtifactDetails.domain } }), runtime: lambda.Runtime.NODEJS_16_X, handler: 'node_modules/order-processing-app/dist/index.lambdaHandler' }); const eventSource = new SqsEventSource(props.queue); lambdaFunction.addEventSource(eventSource); } } lambda.Code.fromDockerBuild(...) というコードに注意してください。ここでは AWS CDK の機能を使用して、Docker ビルドを介して Lambda 関数のコードをバンドルしています。提供された Dockerfile 内で発生する処理は以下のものだけです。 事前ビルド済みのアプリケーションコードのパッケージが格納されている AWS CodeArtifact リポジトリへのログイン アプリケーションコードのアーティファクトを AWS CodeArtifact (この場合は npm 経由) からダウンロードしてインストールすること AWS CDK アセットをビルド、バンドル、デプロイする方法について詳しく知りたい場合は、 Cory Hall による記事 “ Building, bundling, and deploying applications with the AWS CDK ” を強くお勧めします。ここで説明している内容よりもずっと詳細に説明されています。 Dockerfile の例を見ると、上記の 2 つのステップが分かります。 FROM public.ecr.aws/sam/build-nodejs16.x:latest ARG PACKAGE_VERSION ARG CODE_ARTIFACT_AWS_REGION ARG CODE_ARTIFACT_ACCOUNT ARG CODE_ARTIFACT_REPOSITORY RUN aws codeartifact login --tool npm --repository $CODE_ARTIFACT_REPOSITORY --domain $CODE_ARTIFACT_DOMAIN --domain-owner $CODE_ARTIFACT_ACCOUNT --region $CODE_ARTIFACT_AWS_REGION RUN npm install order-processing-app@$PACKAGE_VERSION --prefix /asset 以下の点にご注意ください。 npm のインストールコマンドで --prefix /asset を使用します。これにより、CDK がコンテナーにマウントするフォルダーに依存関係をインストールするよう npm に指示します。Docker build の出力に含まれるはずのすべてのファイルをここに配置する必要があります。 aws codeartifact login を続行するには、適切な権限を持つ認証情報が必要です。これを AWS CodeBuild や CDK Pipelines 内で実行する場合は、使用するロールに適切なポリシーがアタッチされていることを確認する必要があります。 インフラストラクチャチーム インフラストラクチャチームは、アプリケーションチームが公開した AWS CDK Constructを使用します。彼らはアプリケーション全体を構成する AWS CDK スタックを所有しています。おそらく、これはインフラストラクチャチームが所有する複数のスタックのうちの 1 つに過ぎないでしょう。他のスタックは、共有インフラストラクチャ (VPC、ネットワークなど) や他のアプリケーションを作成する可能性があります。 アプリケーションのスタック内では、インフラストラクチャチームがアプリケーションチームの Construct を利用してインスタンス化し、依存関係を解決してから、適切と思われる手段 (AWS CodePipelines、GitHub Actions、またはその他の CI/CD ツール) でスタックをデプロイします。 アプリケーションチームの Construct への依存関係は、インフラストラクチャチームの CDK アプリの package.json に表れています。 { "name": "order-processing-infra-app", ... "dependencies": { ... "order-app-construct" : "1.1.0", ... } ... } 作成された CDK スタックには、アプリケーションパッケージの依存バージョンと、インフラストラクチャチームが追加情報（使用するキューなど）を渡す方法が表示されます。 export class OrderProcessingInfraStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const orderProcessingQueue = new Queue(this, 'order-processing-queue'); new OrderProcessingAppConstruct(this, 'order-processing-app', { appPackageVersion: "2.0.36", queue: orderProcessingQueue, codeArtifactDetails: { ... } }); } } 新しいリリースの普及 これで、各チームが所有するアーティファクトとともに、各チームの責任を整理できるようになりました。しかし、アプリケーションチームが行った変更を本番環境に反映するにはどうすればよいでしょうか。あるいは、アプリケーションチームの最新バージョンのアーティファクトを使用して、インフラストラクチャチームの CI/CD パイプラインを呼び出すにはどうすればよいでしょうか。 アプリケーションまたは AWS CDK Construct のいずれかの新しいバージョンが公開されるたびに、インフラストラクチャチームのアプリケーションチームのアーティファクトへの依存関係を更新する必要があります。依存関係が更新されたら、リリースパイプラインを開始できます。 1 つのアプローチは、 Amazon EventBridge 経由で AWS CodeArtifact によって発行されたイベントを受け取ることです。リリースごとに、AWS CodeArtifact は Amazon EventBridge にイベントを発行します。そのイベントのペイロードから新しいリリースのバージョン番号を抽出し、CDK Construct への依存関係 (例えば CDK アプリケーションの package.json) を更新するワークフローを開始するか、インフラストラクチャチームが利用する Construct に渡す appPackageVersion を更新するワークフローを開始できます。 新しいアプリケーションのリリースがシステム内を流れる仕組みは次のとおりです。 図 1 — アプリケーションパッケージがリリースされると、インフラストラクチャチームの CDK スタックが変更され、デプロイされる アプリケーションチームは新しいアプリケーションバージョンを AWS CodeArtifact に公開します。 CodeArtifact は Amazon EventBridge でイベントをトリガーします。 インフラストラクチャチームが発行されたイベントを受け取ります。 インフラストラクチャチームは、最新の appPackageVersion が含まれるように CDK スタックを更新します。 インフラストラクチャチームの CDK スタックがデプロイされます。 図 2 – アプリケーションチームのCDK Constructの変更をトリガーにインフラストラクチャチームのCDK スタックが変更され、デプロイされる。 そして、CDK Constructの新しいバージョンのリリースも非常によく似ています。 アプリケーションチームは新しい CDK Construct を AWS CodeArtifact に公開します。 CodeArtifact は Amazon EventBridge でイベントをトリガーします。 インフラストラクチャチームが発行されたイベントを受け取ります。 インフラストラクチャチームは依存関係を最新の CDK Construct に更新します。 インフラストラクチャチームの CDK スタックがデプロイされます。 このようなワークフローがどのようになるかについては詳しく説明しません。なぜなら、各チーム向けに高度にカスタマイズされている可能性が高いからです (コードリポジトリや CI/CD に使用されるさまざまなツールを考えてみてください)。ただし、これをどのように実現できるかについてのアイデアをいくつか紹介します。 CDK Construct 依存関係の更新 CDK Construct の依存関係バージョンを更新するには、インフラストラクチャチームの package.json (または pom.xml のような依存関係の追跡に使用される他のファイル) を更新する必要があります。ソースコードをチェックアウトして npm install sample-app-construct@NEW_VERSION (NEW_VERSION は EventBridge イベントペイロードから読み取られた値) のようなコマンドを発行するオートメーションを構築できます。次に、この変更をメインブランチに組み込むためのプルリクエストを自動的に作成します。これがどのようなものかについてのサンプルは、ブログ記事 “ Keeping up with your dependencies: building a feedback loop for shared librares ” を参照してください。 appPackageVersion の更新 インフラストラクチャチームの CDK スタック内で使用されている appPackageVersion を更新するには、上記と同じ方法に従うか、CDK の機能を使用して AWS Systems Manager (SSM) Parameter Store から読み取ることができます。そうすれば、 appPackageVersion の値をソース管理に入力するのではなく、SSM パラメータストアから値を読み取ることになります。その方法については、AWS CDK のドキュメントに Systems Manager Parameter Store から値を取得する というものがあります。次に、 パラメータが変更されたイベント に基づいてインフラストラクチャチームのパイプラインを開始します。 常に何がデプロイされているかを明確に把握し、CloudFormation で使用されているパラメーター値を確認するために、 合成時の Systems Manager の値を読み取り で説明されているオプションを使用することをおすすめします。 結論 複数のチーム (この場合はアプリケーション開発チームとインフラストラクチャチーム) が協力してアプリケーションの新しいバージョンを本番環境に導入する場合でも、AWS Cloud Development Kit とその Construct のコンセプトがチームの独立性と俊敏性を確保するのにどのように役立つかを見てきました。そのために、アプリケーションチームにアプリケーションコードだけでなく、アプリケーションを実行するために使用するインフラストラクチャの部分の管理も任せました。すべての共有インフラストラクチャと最終的なデプロイメントはインフラストラクチャチームが管理し、アプリケーションチームの Construct はこの中で利用されるため、ここまで見てきた Split-Team アプローチと合致しています。 著者 ソリューションアーキテクトとして、Jörg はドイツの製造業のお客様と協力しています。2019 年に AWS に加入する前は、開発者、DevOps エンジニア、SRE など、さまざまな役割を担当していました。そのため、Jörg はビルドと自動化のことが大好きです。AWS Cloud Development Kit に恋をしたのです。 Mo は2020年にテクニカルアカウントマネージャーとして AWS に加入し、7年間の AWS DevOps の実践経験と6年間のシステム運用管理者としての経験を持っています。 AWS 内の2つのコミュニティ(クラウド運用とビルダーエクスペリエンス)のメンバーであり、CI/CD パイプラインと AI for DevOps を使って、ビジネスニーズに合った適切なソリューションを持っていることを確認するために、お客様をサポートすることに焦点を当てています。 本記事は、 Joerg Woehrle と Mohamed Othman による “Improve collaboration between teams by using AWS CDK constructs” を翻訳したものです。翻訳はソリューションアーキテクトの平川 大樹が担当しました。

11月26日、 Amazon Detective は、時間の節約とセキュリティ運用の強化に役立つ 4 つの新機能を追加しました。 1 つ目は、 IAM の Detective 調査 です。これは、セキュリティアナリストが、ユーザーやロールなどの AWS Identity and Access Management (IAM) オブジェクトを調査して 侵害の痕跡 (IOC) がないかを確認し、 MITRE ATT&amp;CK フレームワーク に含まれる既知の戦術に関係している可能性があるかどうかを判断するのに役立ちます。これらの自動調査は、 AWS マネジメントコンソール の [Detective] セクションで利用でき、新しい API を通じて分析やインシデント対応を自動化したり、 AWS Security Hub や SIEM などの他のシステムに検出結果を送信できます。 2 つ目は、 Detective 検出結果グループの要約 です。これは、生成系人工知能 (AI) を使用して調査をエンリッチ化します。検出結果グループを自動的に分析し、自然言語でインサイトを提供することで、セキュリティ調査を加速します。イベントを開始したアクティビティとその影響 (存在する場合) の説明など、関連する要約されたインサイトを含む検出結果グループの分析に基づいて、平易な言葉でタイトルを提供します。検出結果グループの要約は、複数の AWS データソースにわたって構築された検出結果グループの分析という面倒な作業を処理するため、異常なアクティビティや疑わしいアクティビティをより簡単かつ迅速に調査できます。 この記事で説明するこれらの 2 つの新機能に加えて、Detective は、ここでは取り上げていない別の 2 つの機能を追加しています。 Detective は、 Amazon GuardDuty ECS Runtime Monitoring によって検出される脅威についてのセキュリティ調査をサポートするようになりました。 Detective は Amazon Security Lake と統合し、セキュリティアナリストは Security Lake に保存されているログをクエリおよび取得できるようになりました。 Amazon Detective を利用すると、セキュリティに関する検出結果や疑わしいアクティビティの根本原因の分析、調査、および迅速な特定がより容易になります。Detective は、機械学習 (ML)、統計分析、グラフ理論を活用して、セキュリティ調査を視覚化し、より迅速かつ効率的に実施できるようサポートします。Detective は、 AWS CloudTrail ログ、 Amazon Virtual Private Cloud (Amazon VPC) フローログ 、 Amazon GuardDuty 検出結果、 Amazon Elastic Kubernetes Service (Amazon EKS) 監査ログ、AWS セキュリティ検出結果などのソースからログデータとイベントを自動的に収集します。Detective は、分析と調査のために最大 1 年分の集計データを保持します。 クラウドセキュリティの専門家は、脅威ハンティングとインシデント調査に、大量のリソースと長い時間を要すると感じることがよくあります。さまざまなソースからデータを手動で収集して分析し、潜在的な IAM 関連の脅威を特定する必要があります。IAM の調査は、クラウド許可と認証情報が動的であることにより、特に困難です。アナリストは、分散している可能性のある監査ログ、エンタイトルメントレポート、CloudTrail イベントなど、さまざまなシステムから得られたデータをまとめる必要があります。クラウドの許可は、多くの場合、オンデマンドで、またはオートメーションスクリプトを通じて付与されるため、認可の変更を追跡するのが困難です。アクティビティのタイムラインを再構築し、不規則なエンタイトルメントを特定するには、その複雑さに応じて、数時間から数日かかる場合があります。レガシーシステムについての可視性が限られ、ログが不完全である場合には、IAM の調査がさらに複雑になり、不正アクセスを明確に把握することが困難になります。 IAM の Detective 調査は検出結果に優先順位を付けて、極めて重大で疑わしい問題のみを明らかにするため、セキュリティアナリストは高度な調査に集中できます。機械学習と脅威インテリジェンスを使用して、AWS 環境内のリソースを自動的に分析し、潜在的な侵害の痕跡や疑わしいアクティビティを特定します。これにより、アナリストはパターンを特定し、どのリソースがセキュリティイベントの影響を受けるかを把握できるため、脅威の特定と緩和に対するプロアクティブなアプローチを採ることができます。 調査はコンソールで利用できるだけではありません。新しい StartInvestigation API を使用して、修復ワークフローを自動化したり、関係するすべての IP や侵害された AWS リソースに関する情報を収集したりできます。また、API を使用してデータを他のシステムにフィードし、セキュリティ体制の統合ビューを構築することもできます。 検出結果グループの要約は、環境全体のセキュリティイベント間の関係を評価し、関連する脅威、侵害されたリソース、悪意のある攻撃者の行動を結びつけるインサイトを自然言語で提供します。この説明は、個々のサービスレポートにとどまらないセキュリティインシデントの包括的な概要をセキュリティアナリストに提供します。複数のソースから得られたデータをグループ化およびコンテキスト化することにより、検出結果グループの要約は、インサイトが分離されている場合には気付かれない可能性のある脅威を特定します。このアプローチにより、調査と対応の速度と効率が向上します。セキュリティアナリストは、検出結果グループの要約を利用して、セキュリティイベントとその相互関係を総合的に理解できます。これは、封じ込めと修復に関して、十分な情報に基づいた意思決定を下すのに役立ちます。 これらの 2 つの機能がどのように動作するのかを見てみましょう このデモでは、 コンソールの [Detective] セクション にある IAM の Detective 調査から始めます。Detective ダッシュボードには、実行された調査の数と、疑わしいアクティビティに関与した IAM ロールおよびユーザーの数が表示されます。 そこから、調査のリストを詳しく確認します。 そして、特定の調査を 1 つ選択して詳細を把握します。最初に要約があります。 ページを下方向にスクロールして、どの IP アドレスが関与しているか、およびどのような種類のアクティビティに関与しているかを確認します。この例は、物理的な不可能性を示しています。短時間で、オーストラリアと日本という 2 つの異なる場所から同じ IP が使用されました。 私の意見では、このページで最も興味深いのは、 戦術、技術、手順 (TTP) に対するマッピングです。すべての TTP は重大度に従って分類されます。コンソールには、使用された技術とアクションが表示されます。特定の TTP を選択すると、右側のペインに詳細が表示されます。この例では、IAM ロールの信頼できるポリシーを変更しようとして失敗した 2,000 回を超える試行に、疑わしい IP アドレスが関与しています。 最後に、 [指標] タブに移動して指標のリストを確認します。 また、検出結果グループの要約は、 [検出結果グループ] で確認できます。検出結果グループを選択して、検出結果と関連するリスクについての自然言語での説明を確認します。 料金と利用可能なリージョン これらの 2 つの新機能は現在、すべての AWS のお客様にご利用いただけます。 IAM の Detective 調査は、 Detective が利用可能な すべての AWS リージョンでご利用いただけます。検出結果グループの要約は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール、東京)、欧州 (フランクフルト) の 5 つの AWS リージョンでご利用いただけます。 Amazon Detective に関するすべての詳細を確認し、今すぐ使用を開始しましょう 。 — seb 原文は こちら です。

イントロダクション Karpenter は AWS によって開発された Kubernetes のノードライフサイクルマネージャーで、クラスターのノードの設定を最小化することを目的として、2021 年にリリースされました。この 1 年で、GitHub の Star 数は 4900 を超え、200 人以上のコントリビューターによるコードがマージされるなど、素晴らしい成長を遂げています。現在、Kubernetes Autoscaling Special Interest Group の一部として、Cloud Native Computing Foundation (CNCF) に寄贈されるプロセスにあります。 このような成長の一貫として、alpha 版で行われた数々の破壊的な変更に対処したくないというユーザーに対して、より厳格な安定性を保証する Kubernetes API の成熟の需要が高まっています。これは、プロジェクトの進化において重要なマイルストーンになります。この移行によって顧客は、beta 版が提供する API の安定性と成熟度の向上による恩恵を受けます。またこれは、後方互換性を優先するという我々からのコミットメントを示しています。顧客は将来的な破壊的な変更に悩まされる必要なく、新しい機能や機能の拡張を自信を持って採用できます。このリリースは、以前のリリースと同様に、オープンソースコミュニティからのフィードバックを取り入れています。 API の変更は、Karpenter のバージョン 0.32.0 リリースの一部として展開されます。既存の Deployment をこのバージョンにアップグレードする必要があります。この記事で移行パスの概略について説明しており、Karpenter アップグレードガイド でさらに詳しく説明されています。 既存の alpha API は非推奨となり、この単一のバージョンでのみ利用可能です。 v0.33.0 のリリースから、Karpenter は v1beta1 API のみをサポートします。 Karpenter の API は alpha → beta → stable という成熟の過程をたどります。 alpha 版から beta 版への昇格には、この記事で強調している API の重大な変更を必要としました。beta 版から stable 版への昇格には、同じレベルの変更は必要ないと予測しています。 Kubernetes API の昇格プロセスについて興味がある方は、 こちらの記事 をご覧ください。 変更点について stable v1 に到達するまでの過程において、alpha 版から beta 版への移行に際して API に重要な変更を加えました。ユーザーにとってよく問題となる API の領域を削除することによって、使いやすさを向上させるためです。これらの領域のひとつがネーミングでした。provisioner という言葉の使用に際して混乱が生じていて (ストレージの領域では、多重定義された用語)、ユーザーが考える必要がある概念の数を減らしたいと考えていました。 今回のリリースで、Karpenter は Provisioner・AWSNodeTemplate・Machine API を廃止し、NodePool・EC2NodeClass・NodeClaim を導入しました。全体的な視点を捉え、Node という単一の概念を中心に API を合理化しました。 ウォークスルー API グループ と kind のネーミング v1beta1 バージョンでは、以下の新しい API が導入されている一方で、既存の API は廃止されています。 karpenter.sh/Provisioner は karpenter.sh/NodePool になる karpenter.sh/Machine は karpenter.sh/NodeClaim になる karpenter.k8s.aws/AWSNodeTemplate は karpenter.k8s.aws/EC2NodeClass になる これらのネーミングの変更にはそれぞれ、Karpenter の最新バージョンに更新する際に考慮する必要があるスキーマの変更が含まれます。各々の変更点と、新しい API 定義がどのようなものかを見てみましょう。 v1alpha5/Provisioner → v1beta1/NodePool NodePool は Provisioner の後継として機能し、スケジューリング中に Node と Pod 間の互換性に影響を与える、設定ベースのパラメータ (要件、Taint、Label など)を公開します。また Karpenter のスケジューリングやデプロビジョニングの意思決定を微調整するための、振る舞いベースの設定も含まれています。 NodePool はインスタンスタイプとサイズの組み合わせを解決する一方で、ワークロードがリソースをリクエストする方法には制限を課します。これは、プロビジョニングとデプロビジョニングの動作のグルーピングを促進します。重要なのは、ポータブルな設定を維持するためには、プールにクラウド固有の設定を持つべきではないということです。 Karpenter の v1beta1 では、全ての振る舞いに関わらないフィールドは NodePool テンプレートのフィールド内部でカプセル化されます。Karpenter の場合、NodePool が NodeClaims をテンプレート化し、それらは Karpenter コントローラーによってオーケストレートされます。これは Deployment コントローラーによって Pod がテンプレート化されオーケストレーションされる、Deployment のコンセプトを反映しています。 NodePool の詳細については、ドキュメントをご覧ください。 NodePool の例は以下のとおりです。 apiVersion: karpenter.sh/v1beta1 kind: NodePool ... spec: template: metadata: annotations: custom-annotation: custom-value labels: team: team-a custom-label: custom-value spec: nodeClassRef: name: default requirements: - key: karpenter.k8s.aws/instance-category operator: In values: [ "c", "m", "r" ] ... kubelet: systemReserved: cpu: 100m memory: 100Mi ephemeral-storage: 1Gi maxPods: 20 disruption: expireAfter: 360h consolidationPolicy: WhenUnderutilized Apache Configuration spec の例を見ると、disruption という新しいセクションがあることに気がつくでしょう。これにより、Consolidation、Expiration、空のノードに関する以前の設定 ( ttlSecondsAfterEmpty 、 ttlSecondsUntilExipred 、 consolidation.enabled ) がグループ化されます。 NodePool マニフェストが適用される時に明示的に指定されていない場合、Karpenter は disruption をデフォルトで設定します。デフォルト値は以下で強調されています。こららのフィールドの振る舞いの詳細については、 ドキュメント をご覧ください。 Field Default spec.disruption.consolidationPolicy WhenUnderutilized spec.disruption.expireAfter 720h v1alpha1/AWSNodeTemplate → v1beta1/EC2NodeClass EC2NodeClass は AWSNodeTemplate の後継として機能し、Node の起動やブートストラッププロセスに影響するクラウドプロバイダー固有のフィールドを公開します。これには、使用したい Amazon Machine Image (AMI)、セキュリティグループ、サブネットの設定、更にはブロックストレージ、ユーザーデータ、インタンスメタデータの設定に関する詳細が含まれます。 Karpenter の spec.instanceProfile フィールドは EC2NodeClass から削除され、 spec.role フィールドが選択されました。(訳注： spec.instanceProfile フィールドは v0.32.2 で追加されています。現在指定可能なフィールドについては、公式ドキュメントを参照してください。) Karpenter は、ユーザーが指定したロールが定義された EC2NodeClass に基づいて、インスタンスプロファイルを自動生成するようになりました。 既に非推奨となっていた管理対象外の起動テンプレートを参照するための spec.launchTemplateName フィールドが削除されました。そのため、このフィールドを使用している場合は、EC2NodeClass に移行する際に、管理対象外の起動テンプレートから、Karpenter が管理する起動テンプレートに移行する必要があります。 NodeClass の詳細については、 ドキュメント をご覧ください。EC2NodeClass の例は以下のとおりです。 apiVersion: karpenter.k8s.aws/v1beta1 kind: EC2NodeClass metadata: name: default spec: amiFamily: Bottlerocket role: KarpenterNodeRole-karpenter-demo subnetSelectorTerms: - tags: karpenter.sh/discovery: karpenter-demo securityGroupSelectorTerms: - tags: karpenter.sh/discovery: karpenter-demo tags: test-tag: test-value Apache Configuration v1alpha5/Machine→ v1beta1/NodeClaim Karpenter v0.28.0 では、Machine と呼ばれる新しいリソースタイプが追加されました。これにより、複数のノードのプロビジョニングが改善され、ネイティブの Kubernetes コントローラーがノードをクラスターに参加させながら、Karpenter がノードを管理および追跡できるようになりました。v0.28.0 以前の Karpenter のバージョンを使用している場合、このリソースタイプを使用することはできません。 v0.32.0 のリリースで、NodeClaim に変更されました。NodeClaim はクラスター管理者によって作成されることを意図したものではなく、かわりに Karpenter によって作成および削除されます。NodeClaim が機能するために何も変更する必要はないはずです。クラスター内のノードをトラブルシューティングする際に、Karpenter が管理しているノードのライフサイクルと状態を確認できます。 ラベルの変更 Karpenter の v1beta1 では、 karpenter.sh/do-not-evict と karpenter.sh/do-not-consolidate の共通ラベルに変更が加えられました。これらは廃止され、 karpenter.sh/do-not-disrupt という単一のラベルに統一されました。これらは Pod と Node の両方に適用でき、Karpenter がノードの中断や Pod の退避を実行することを防ぎます。 NodeClass の AMI、サブネット、セキュリティグループのためのより柔軟なセレクター 現在のセレクターの設定では、プロビジョニングされるノードに対して異なる設定を識別し使用する能力が、いくらか制限されていました。既存の動作では AND ロジックが適用されるため、様々なクラスターやリージョンで設定を一致させることが困難でした。これに対処するためにセレクターを拡張し、複数の条件を指定できるようにしました。これらの条件は OR ロジックを使って組み合わさるようになり、一致するものが特定されるまで、まとめて評価されることを意味します。 名前が my-name1 あるいは my-name-2 で、所有者が 123456789 または amazon の AMI を照合する場合の例は、以下のとおりです。 amiSelectorTerms: - name: my-name1 owner: 123456789 - name: my-name2 owner: 123456789 - name: my-name1 owner: amazon - name: my-name2 owner: amazon Apache Configuration subnetSelectorTerms と securityGroupSelectorTerms についても同様の設定を行うことができます。詳細については Karpenter の ドキュメント をご覧ください。 securityGroupSelectorTerms: - id: abc-123 name: default-security-group # Not the same as the name tag tags: key: value # Selector Terms are ORed - id: abc-123 name: custom-security-group # Not the same as the name tag tags: key: value Apache Configuration Drift がデフォルトで有効に 次のリリース (v0.33.0) から、Drift 機能はデフォルトで有効になります。Drift のフィーチャーゲートを指定しなかったら、この機能は有効であるとみなされます。Karpenter のコマンドライン引数で --feature-gates DriftEnabled=false を指定することで、Drift 機能を無効化できます。このフィーチャーゲートは core API (NodePool、NodeClaim) が v1 にバージョンアップされた時に、完全に削除される予定です。 移行パス Karpenter コントローラーの AWS IAM ロールを更新する Karpenter コントローラーは、AWS Identity and Access Management ( AWS IAM ) を使用して、AWS アカウント内で Amazon Elastic Compute Cloud ( Amazon EC2 ) インスタンスを起動および操作する権限を付与します。アップグレードの一貫として、以下のとおり新しいアクセス権限ポリシーを作成します。 ec2:RunInstances 、 ec2:CreateFleet 、 ec2:CreateLaunchTemplate に、以前のタグキー karpenter.sh/provisioner-name の代わりに、タグベースの制約 karpenter.sh/nodepool を追加しました。 iam:CreateInstanceProfile 、 iam:AddRoleToInstanceProfile 、 iam:RemoveRoleFromInstanceProfile 、 iam:DeleteInstanceProfile 、 iam:GetInstanceProfile といったアクションの許可を与えました。これらのアクセス権限は全てタグベースのポリシーによって制約され、コントローラーが作成に責務を持つインスタンスプロファイルのみを操作する権限を持っていることを保証します。これらは Karpenter が管理するインスタンスプロファイルをサポートするために必要です。 移行が完了し、以下の詳細の説明に従って新しいノードをロールアウトしたら、以前のアクセス権限ポリシーを安全に削除できます。 アクセス権限ポリシーの例は Karpenter の GitHub リポジトリ にあります。またプロジェクトを開始する AWS CloudFormation テンプレートの一部として配布されています。 API の移行 alpha 版から新しい v1beta1 版の API に移行するには、まず新しい v1beta1 の Custom Resource Definitions (CRD) をインストールする必要があります。その後、Provisioner と AWSNodeTemplates の両方について、alpha 版 API に相当する beta 版 のリソースを作成する必要があります。Machine から NodeClaim への移行は、カスタムリソースを Provisioner から NodePool に移行する際に Karpenter によって管理され、ユーザーにとってはシームレスである点に注目してください。 NodePool と EC2NodeClass オブジェクトの作成を効率化するために設計されたコマンドラインユーティリティツールである karpenter-convert を紹介できることを嬉しく思います。以下に、このツールを効果的に利用するための手順を示します。 コマンドラインユーティリティをインストールします。： go install github.com/aws/karpenter/tools/karpenter-convert/cmd/karpenter-convert@latest 各 Provisioner を NodePool に移行します。： karpenter-convert -f provisioner.yaml &gt; nodepool.yaml 各 AWSNodeTemplate を EC2NodeClass に移行します。： karpenter-convert -f nodetemplate.yaml &gt; nodeclass.yaml ツールによって生成された各 EC2NodeClass に対して、AWS IAM ロールを手動で指定する必要があります。ツールはプレースホルダー $KARPENTER_NODE_ROLE を残すので、実際のロール名に置き換える必要があります。 各 Provisioner のリソースについて、ノードを 1 つずつ入れ替えるか、全ての Provisioner ノードを一気に入れ替えるかを決定する必要があります。詳細な手順のガイドについては、以下のセクションに記載されています。 Drift による段階的なノードの入れ替え Drift を有効にした状態で、クラスター内の各 Provisioner に対して次のアクションを実行します。 alpha 版の CRD を v1beta1 に移行します。 karpenter.sh/legacy=true:NoSchedule のような Taint を古い Provisioner に追加します。 Karpenter の Drift は、その Provisioner によって所有される全てのマシン・ノードをドリフト済としてマークします。 Karpenter の Drift は、新しい NodePool リソースのノードを代替ノードとして起動します。 現在、Karpenter は一度に 1 つのノードの入れ替えのみサポートしています。すなわち、Karpenter が 1 つの Provisioner 配下の全てのノードを入れ替えるには、時間がかかる場合があります。 強制的な削除 クラスター内の各 Provisioner について、以下のアクションを実行します。 クラスター内に、v1alpha5 Provisioner・AWSNodeTemplate に対応する NodePool・EC2NodeClass を作成します kubectl delete provisioner &lt;provisioner-name&gt; --cascade=foreground で古い Provisioner を削除します Karpenter は、Provisioner によって所有される各々の Node を削除し、全ての Node に対して同時に排出を行い、Node が排出中の状態になったら新しく Pending 状態になった Pod 用の Node を起動します 手動での入れ替え クラスター内の各 Provisioner について、次の操作を実行します。 v1alpha5 のProvisioner・AWSNodeTemplate に対応する v1/beta1 NodePool・EC2NodeClass をクラスター内に作成します。 古い Provisioner に karpenter.sh/legacy=true:NoSchedule のような Taint を追加します。 kubectl delete node &lt;node-name&gt; を実行して、Provisioner によって所有される各ノードを 1 つずつ削除します。 まとめ この記事では、新しい API によって導入された変更を紹介し、コミュニティからのフィードバックによって形作られたこれらの変更の背景にある理由についての洞察を提供しました。Karpenter プロジェクトの成熟度の高まりを目の当たりにできてとれも嬉しいです。これらの変更の大部分は、最終的には stable v1 API に移行すると予想しています。これにより、幅広いユーザーベースが、ワークロードネイティブなノードのプロビジョニングにおける Karpenter の能力を最大限に活用できるようになります。 この記事では取り上げなかった廃止や変更が他にもいくつかあります。包括的な移行ガイドラインについては、Karpenter アップグレードガイド をご覧ください。 Karpenter を v0.32.0 にアップグレードする前に、 リリースノート を全て読むことを推奨します。質問があれば、Kubernetes slack #karpenter チャンネル または GitHub までお気軽にご連絡ください。新機能の優先順位付けと開発に役立つフィードバックをお待ちしています。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

生成系 AIの急速な成長は、有望な新しいイノベーションをもたらすともに、新たな課題も提起しています。お客様がお客様の環境のセキュリティに関する保証を規制当局や監査人に提供できるよう、AWS では責任を持って AI を開発することに全力を注いでいます。 AWS Audit Manager は、 Amazon Bedrock におけるエビデンス収集を自動化する生成系 AI の AWS ベストプラクティスフレームワークの最初のバージョンを発表しました。このフレームワークにより、お客様は生成系 AI の可能性を最大限に活用すると同時に倫理的で責任ある使用に関する懸念に対処できるようになります。 2020 年 12 月に提供が開始された AWS Audit Manager は、事前定義されたコントロールに対して、リソース構成と使用アクティビティなどの証拠収集を自動化し、お客様の AWS 利用状況が意図したポリシーや規制要件に合致するかどうかを監視するサービスです。2023年9月に一般提供が開始された Amazon Bedrock は、Amazon やその他の大手 AI 企業の基盤モデル (FM) を API を通じて利用できるフルマネージド型サービスで、既存の大規模言語モデル (LLM) を組織のデータでプライベートにチューニングすることも可能です。Amazon Bedrock のお客様は、生成系 AI モデルとアプリケーションを実行しているアカウントに、この新しいベストプラクティスフレームワークを AWS Audit Manager 経由でデプロイし、意図したポリシーへのコンプライアンスを監視するのに役立つ証拠を収集できます。 AWS の AI、コンプライアンス、セキュリティ保証に関する専門家が、AWS パートナーでグローバルな監査・保証会社であるデロイトによる追加レビューを受けながらこのフレームワークを開発しました。典型的なセキュリティまたはコンプライアンスのフレームワークは、特定のミッションや業界の目標に基づいて既知のリスクやエンティティを中心に境界線を構築します。このことを念頭に置き、規制やコンプライアンスが成熟するまでの間にお客様が革新的なテクノロジーを適切に活用するための心構えを形作ることを目指しています。 “生成 AI の標準的な使用例が広がるにつれて、毒性 (toxicity) や幻覚 (hallucination) などの生成 AI 固有のリスクに対処するための標準的な統制、生成系 AI のためのガードレール実装は今後ますます重要になります。AWS Audit Manager の提供する生成系 AI 向けフレームワークにより、組織は進化する AI リスクの監視を開始し、より多くの生成系 AI 活用の機会を模索できるようになります。” &nbsp; &nbsp;— Christina DeJong 公認会計士 — デロイト パートナー この新しいフレームワークは、正確性、公平性、プライバシー、レジリエンス、責任、安全性、セキュリティ、持続可能性の8つの重要なドメインにわたる32の目標のもと、110の統制項目をグループ化しています。これにより、生成系 AI システム、基盤となるモデル、お客様が入力するデータ、最終的に生成されるデータなど、各テクノロジー層におけるリスクに対処できます。例えば、モデルにデータを入力する前に既知のバイアスを軽減したいお客様は、このフレームワークの「Pre-processing Techniques（前処理に関する技術）」コントロールを用いて、データ拡張、再重み付け、リサンプリングなどに関する文書が、検証のための基準を満たしているかのエビデンスを要求することができます。 AWS Audit Manager での評価の設定方法 Audit Manager の生成系 AI フレームワーク v1のベストプラクティスを使うのは簡単です。Audit Manager 評価の作成を進める前に、以下の前提条件が整っていることを確認してください。 前提条件 Audit Manager が評価を作成するアカウントで Amazon Bedrock を実際に利用していること。Amazon Bedrockをまだセットアップしていない場合は、 以下の手順 に従って利用を開始してください。 Audit Manager が評価を作成するアカウントで有効化されていること。以前にアカウントで Audit Manager を有効にしたことがない場合は、 以下の手順 に従って利用を開始してください。 まず、AWS コンソールに移動し、Audit Manager を選択または検索します。 Audit Manager コンソールから、右上の [ 評価の作成 ] を選択します: 図 1. AWS Audit Manager で評価を作成 次に、2 つの必須情報を入力する必要があります。1 つは 300 文字以下の評価名、もう 1 つは評価レポートの出力先である S3 バケットです。オプションで、評価の説明を 1000 語まで入力できます: 図 2. 評価の詳細を指定 次に、標準フレームワークのリストから [AWS Generative AI Best Practices Framework v1] フレームワークを選択します: 図 3. 生成 AI ベストプラクティスフレームワークを選択 [新しいタグを追加] を選択して、タグを評価に関連付けます。各タグにキーと値を指定できます。タグキーは必須で、このアセスメントを検索する際の検索条件として使用できます。Audit Manager のタグの詳細については、「 AWS Audit Manager リソースのタグ付け 」を参照してください。オプションとして、評価に最大 50 個のタグを追加することが可能です: 図 4. 自動化を容易にするために、フレームワークにタグを追加 次に、評価の対象となる AWS アカウントを指定します。このデモ環境では、開発、ロギング、および単一の本番アプリケーションアカウントを選択しています。ユースケースによっては異なるかもしれませんが、ロギングアカウントを使用している場合は、そのアカウントを含めてそこにルーティングされる可能性のある関連イベントをキャプチャする必要があります。アカウントを指定したら、[次へ] を選択して続行します: 図 5. 評価対象のアカウントを選択 これは標準フレームワークでカスタムフレームワークではないため、Audit Manager はエビデンスの収集に必要なサービスを選択します (つまり、ここで選択されているサービスはこの評価でテスト可能なサービスの一覧ではなく、評価に必要なデータを収集するサービスの一覧となっているということです)。この画面では、あとは [次へ] を選択するだけです: 図 6. 対象となる AWS サービス ユーザー名またはロールで 1 人以上の [監査所有者 (audit owners)] を選択する必要があります。ここで選択されたエンティティは、この評価に変更を加えることが可能です。一般的には、組織内でそのような職務を担う人だけを選択します。監査所有者が決まったら、 [次へ] を選択して次に進みます: 図 7. この評価の監査所有者を選択 最後に、設定した内容がすべて表示されます。必要に応じて内容を変更し、設定内容に問題がなければ [ 評価を作成 ] を選択します: 図 8. 評価を作成 上のバナーにあるように、評価対象のアカウントで Amazon Bedrock が実際に使用されている場合は24 時間以内にエビデンスを確認できるようになるはずです。 さらに深く掘り下げたい場合は、より具体的なニーズに合わせてフレームワークをカスタマイズできます。AWS Audit Manager の標準フレームワークのカスタマイズに関する詳細については、 こちら をご覧ください。 このブログはソリューションアーキテクトの三厨が翻訳を担当しました。原文は こちら 。 著者について John Fischer John は AWS セキュリティ保証サービスチームのシニアアシュアランスコンサルタントであり、AWS Audit Manager のスペシャリストでもあります。余暇には演奏したり、妻や子供たちと過ごす時間を楽しんでいます。 Alexis Robinson Alexis は AWS のシニアマネージャーで業界スペシャリストです。15 年以上にわたり、セキュリティのベストプラクティスに関するアドバイスや、サイバー評価や財務評価を実施するお客様にサービスを提供してきました。現在は、re:inforce のオピニオンリーダー、講演者、トラックリーダーを務めており、AWS のクラウドセキュリティをサポートするインパクトのあるソリューションを推進するチームを率いています。 Neha Singh Rajpurohit Neha は AWS のシニアプロダクトマネージャー (テクニカル) です。製品管理と戦略に関する 10 年以上の経験を活かしています。Neha は、顧客のニーズを理解し、共感できるインサイトとデータを組み合わせて最も複雑なプロセスでも簡素化することに情熱を注いでいます。 参考文献: What’s New Post – Best Practices framework for GenAI AWS Audit Manager ドキュメント Transform responsible AI from theory into practice Amazon Bedrock ユーザーガイド Transform responsible AI from theory into practice AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI <!-- '"` -->

新しい U7i インスタンスは、SAP HANA、Oracle、SQL Server などの大規模なインメモリデータベースをサポートするように設計されています。カスタムの第 4 世代インテル Xeon スケーラブルプロセッサ (Sapphire Rapids) を搭載したインスタンスは、次に示すように、米国西部 (オレゴン)、アジアパシフィック (ソウル)、欧州 (フランクフルト) の複数の AWS リージョンにおいて、プレビューでご利用いただけるようになりました。 インスタンス名 vCPU メモリ (DDR5) EBS 帯域幅 ネットワーク帯域幅 u7in-16tb.224xlarge 896 16,384 GiB 100 Gbps 100 Gbps u7in-24tb.224xlarge 896 24,576 GiB 100 Gbps 100 Gbps u7in-32tb.224xlarge 896 32,768 GiB 100 Gbps 100 Gbps また、より小さなインスタンスにも取り組んでいます。 インスタンス名 vCPU メモリ (DDR5) EBS 帯域幅 ネットワーク帯域幅 u7i-12tb.224xlarge 896 12,288 GiB 60 Gbps 100 Gbps 32 TiB のメモリは次のようになります。 そして、896 vCPU (および他の多くの情報) は次のとおりです。 第 1 世代 のハイメモリインスタンスと比較すると、U7i インスタンスは、最大 125% 高いコンピューティングパフォーマンスと、最大 120% 高いメモリパフォーマンスを提供します。また、2.5 倍の EBS 帯域幅を提供するため、1 時間あたり最大 44 テラバイトのレートでインメモリデータベースをハイドレートできます。 各 U7i インスタンスは、最大 128 の汎用 (gp2 および gp3) またはプロビジョンド IOPS (io1 および io2 Block Express ) EBS ボリュームのアタッチをサポートします。各 io2 Block Express ボリュームは、最大 64 TiB まで拡張でき、最大 32 Gbps で最大 256K IOPS を提供できるため、U7i インスタンスに最適です。 ネットワーク側では、インスタンスは ENA Express をサポートし、ネットワークフローあたり最大 25 Gbps の帯域幅を提供します。 サポートされているオペレーティングシステムには、Red Hat Enterprise Linux および SUSE Enterprise Linux Server が含まれます。 プレビューをお試しください ご使用の環境で U7i インスタンスをテストする準備ができたら、 プレビューにぜひご参加ください 。 – Jeff ; 原文は こちら です。

最近では、特にテキストや画像形式のデータについて、機械学習 (ML) を使用して予測を行う際、ディープラーニングモデルの作成とチューニングに関する広範な機械学習の知識が必要でした。今日では、ML モデルを使用してビジネス価値を生み出したいと考えているすべてのユーザーが、ML にアクセスしやすくなっています。 Amazon SageMaker Canvas を使用すると、コードを 1 行も記述せずに、表形式データや時系列データだけでなく、さまざまなデータタイプの予測を作成できます。これらの機能には、画像、テキスト、およびドキュメントデータタイプの事前トレーニング済みモデルが含まれます。 この記事では、事前トレーニング済みのモデルを使用して、表形式データ以外にもサポートされているデータタイプの予測を取得する方法について説明します。 テキストデータ SageMaker Canvas は、ML モデルの構築、トレーニング、デプロイを行うためのノーコードのビジュアルインターフェースを提供します。自然言語処理 (NLP) タスクの場合、SageMaker Canvas は Amazon Comprehend とシームレスに統合されているため、言語検出、エンティティ認識、感情分析、トピックモデリングなどの主要な NLP 機能を実行できます。この統合により、Amazon Comprehend の堅牢な NLP モデルを使用するためのコーディングやデータエンジニアリングが不要になります。テキストデータを提供し、一般的に使用される4つの機能（感情分析、言語検出、エンティティ抽出、個人情報検出）から選択するだけです。シナリオごとに、UI を使用してテストし、バッチ予測を使用して Amazon Simple Storage Service (Amazon S3) に保存されているデータを選択できます。 感情分析 感情分析を使用すると、SageMaker Canvas では入力テキストの感情を分析できます。次のスクリーンショットに示すように、全体的な感情がポジティブ (Positive)、ネガティブ (Negative)、混合 (Mixed)、ニュートラル (Neutral) のいずれであるかを判断できます。これは、商品レビューの分析などの場合に便利です。たとえば、「この製品が大好きです、すごいです！」というテキストがあるとします。SageMaker Canvas ではポジティブな感情を持つものとして分類され、「この製品はひどい、買ったことを後悔している」はネガティブな感情として分類されます。 エンティティ抽出 SageMaker Canvas はテキストを分析し、その中に記載されているエンティティを自動的に検出できます。文書が分析のためにSageMaker Canvas に送信されると、テキスト内の人、組織、場所、日付、数量、およびその他のエンティティが識別されます。このエンティティ抽出機能により、文書で議論されている主要な人物、場所、詳細についての洞察をすばやく得ることができます。サポートされているエンティティのリストについては、「 エンティティ 」を参照してください。 言語検出 SageMaker Canvas では、Amazon Comprehend を使用してテキストの主要言語を判断することもできます。テキストを分析して主要言語を特定し、検出された主要言語の信頼度スコアを提供しますが、多言語文書の割合の内訳は示しません。複数言語の長い文書で最良の結果を得るには、テキストを小さな部分に分割し、結果を集計して言語の割合を推定します。20 文字以上のテキストで最適に動作します。 個人情報検出 SageMaker Canvas による個人情報検出を使用して機密データを保護することもできます。テキスト文書を分析して個人を特定できる情報 (PII) エンティティを自動的に検出できるため、名前、住所、生年月日、電話番号、電子メールアドレスなどの機密データを特定できます。最大 100 KBのドキュメントを分析し、検出された各エンティティの信頼度スコアを提供するため、最も機微な情報を確認して選択的に削除できます。検出されたエンティティのリストについては、「 PII エンティティの検出 」を参照してください。（訳者注: 対応言語は開発者ガイドを参照してください） 画像データ SageMaker Canvas は、 Amazon Rekognition と統合することで、コンピュータビジョン機能を簡単に使用できるノーコードの視覚的なインターフェイスを画像分析のために提供します。たとえば、画像のデータセットをアップロードしたり、Amazon Rekognition を使用してオブジェクトやシーンを検出したり、テキスト検出を実行してさまざまなユースケースに対応できます。視覚的なインターフェイスと Amazon Rekognition の統合により、開発者以外のユーザーでも高度なコンピュータービジョン技術を活用できます。 画像内のオブジェクト検出 SageMaker Canvas は Amazon Rekognition を使用して画像内のラベル (オブジェクト) を検出します。SageMaker Canvas UI から画像をアップロードするか、 Batch prediction タブを使用して S3 バケットに保存されている画像を選択できます。次の例に示すように、時計塔、バス、建物などの画像内のオブジェクトを抽出できます。インターフェイスを使用して予測結果を検索し、並べ替えることができます。 画像内のテキスト検出 画像からテキストを抽出することは非常に一般的なユースケースです。このタスクを SageMaker Canvas 上ノーコードで簡単に実行できるようになりました。次のスクリーンショットに示すように、テキストは行項目として抽出されます。画像内の短いフレーズはまとめて分類され、1 つのフレーズとして識別されます。（訳者注: 対応言語は開発者ガイドを参照してください） 一連の画像をアップロードしてバッチ予測を実行し、1 つのバッチジョブですべての画像を抽出し、結果を CSV ファイルとしてダウンロードできます。このソリューションは、画像内のテキストを抽出して検出する場合に便利です。 文書データ SageMaker Canvas には、日々の文書理解のニーズを解決する、すぐに使えるさまざまなソリューションが用意されています。これらのソリューションは Amazon Textract によって提供されています。ドキュメントで使用できるすべてのオプションを表示するには、次のスクリーンショットに示すように、ナビゲーションペインで Ready-to-use models を選択し、 Document でフィルタリングします。（訳者注: 対応言語は開発者ガイドを参照してください） 文書分析 文書分析では、検出されたテキスト間の関係について文書とフォームを分析します。このオペレーションでは、未加工テキスト (Raw text)、フォーム&nbsp;(Forms)、テーブル (Tables)、署名 (Signatures) の 4 つのカテゴリの文書抽出が返されます。このソリューションは文書構造を理解できるため、文書から抽出するデータの種類をさらに柔軟に設定できます。次のスクリーンショットは、テーブル検出がどのように見えるかの例です。 このソリューションは複雑な文書のレイアウトを理解できるため、文書内の特定の情報を抽出する必要がある場合に役立ちます。 身分証明書分析 このソリューションは、個人識別カード、運転免許証、またはその他の類似の身分証明書などの文書を分析するように設計されています。ミドルネーム、郡、出生地などの情報は、次のスクリーンショットに示すように、正確性に関する個人の信頼スコアとともに、IDドキュメントごとに返されます。 バッチ予測を行うオプションもあります。これにより、識別書類のセットを一括アップロードし、バッチジョブとして処理できます。これにより、身分証明書の詳細を、データ分析などの下流プロセスに使用できるキーと値のペアに迅速かつシームレスに変換できます。 経費分析 経費分析は、請求書や領収書などの経費文書を分析するように設計されています。次のスクリーンショットは、抽出された情報がどのように見えるかの例です。 結果は集計フィールドと行項目フィールドとして返されます。Summary fields はドキュメントから抽出されたキーと値のペアで、 Grand Total 、 Due Date 、 Tax などのキーが含まれます。Line item fields とは、ドキュメント内のテーブルとして構造化されたデータを指します。これは、レイアウトを維持したままドキュメントから情報を抽出する場合に便利です。 ドキュメントクエリ ドキュメントクエリは、ドキュメントについて質問できるように設計されています。これは、複数ページのドキュメントがあり、ドキュメントから非常に具体的な回答を抽出したい場合に使用するのに最適なソリューションです。以下は、質問できる質問の種類と、抽出された回答の例です。 このソリューションは、ドキュメントを操作するためのわかりやすいインターフェイスを提供します。これは、大きな文書の中で特定の詳細情報を取得したい場合に役立ちます。 まとめ SageMaker Canvas は、テキスト、画像、文書などのさまざまなデータタイプで ML を簡単に使用できるノーコードの環境を提供します。視覚的なインターフェイスと、Amazon Comprehend、Amazon Rekognition、Amazon Textract などの AWS サービスとの統合により、コーディングやデータエンジニアリングの必要がなくなります。テキストの場合、感情、エンティティ、言語、PIIに関して分析できます。画像の場合、オブジェクトとテキストの検出により、コンピュータービジョンのユースケースが可能になります。最後に、ドキュメント分析では、下流プロセスのためにドキュメントのレイアウトを維持しながらテキストを抽出できます。SageMaker Canvas のすぐに使用できるソリューションにより、高度な ML 技術を活用して、構造化データと非構造化データの両方から洞察を得ることができます。すぐに使える ML モデルでコード不要のツールを使用することに興味があるなら、今すぐ SageMaker Canvas を試してみてください。詳細については、「 Amazon SageMaker Canvas の使用を開始する 」を参照してください。 翻訳はソリューションアーキテクト菊地が担当しました。原文は こちら です。 著者について Julia Ang は、シンガポールを拠点とするソリューションアーキテクトです。彼女は、医療や公共部門からデジタルネイティブビジネスまで、さまざまな分野の顧客と協力して、ビジネスニーズに応じたソリューションを採用してきました。また、東南アジアをはじめとする地域のお客様のビジネスにおける AI と ML の活用を支援してきました。仕事以外では、旅行やクリエイティブな活動を通じて世界について学ぶことを楽しんでいます。 Loke Jun Kai は、シンガポールを拠点とする AI/ML のスペシャリストソリューションアーキテクトです。彼は ASEAN 全域の顧客と協力して、AWS で大規模な機械学習ソリューションを構築しています。Jun Kai は、ローコード・ノーコード・機械学習ツールの提唱者です。余暇には、自然とのふれあいを楽しんでいます。

モノのインターネット (IoT) は、様々な業界でますます普及しています。また、接続されるデバイスの増加や送信される機密情報の量に伴い、IoT セキュリティは最重要課題となっています。世界人口の増加が続く中、エネルギー需要はかつてない水準に急増しています。この差し迫った課題に対応するため、再生可能エネルギー源は、IoT 技術の力を活用し、この変革的な移行を推進することで、非常に大きな意味を持つようになりました。風力、水力発電設備、太陽光発電 (PV) システムは、クリーンで持続可能なエネルギーの効率的な生成と利用を可能にする重要な触媒として登場しました。AWS IoT は、デバイスとシステムを接続する安全で暗号化された手段を提供し、送信データの完全性と安全性を保証します。AWS IoT は、再生可能エネルギーシステムの効果的な運用と管理をサポートし、効率的なエネルギー生成と分配を促進する上で重要な役割を果たします。 ソリューション概要 提案するアーキテクチャでは、再生可能エネルギーシステムは、Modbus インターフェースを利用する AWS IoT 認定デバイス と統合されます。このデバイスは AWS IoT Greengrass を実行し、シームレスな接続を実現します。デバイスは、 MQTT と HTTPS プロトコルを介して AWS IoT Core と通信します。データは、効率的な配信のために Amazon Kinesis Data Firehose を通じてストリーミングされ、 Amazon Simple Storage Service に保存されます。データを可視化し、洞察を得るために、 Amazon QuickSight が活用され、インタラクティブで視覚的に魅力的なダッシュボードが作成されます。そして、 AWS IoT Device Management 、 Amazon CloudWatch 、 Amazon Simple Notification Service を使用して、リアルタイムのモニタリングとアラートを実装することができます。さらに、データを AI/ML アプリケーションに活用することで、高度な分析と予測機能を実現することができます。 図1：再生可能エネルギー-電力 AWS IoT 認定ソリューション AWS IoT によるクラウドのセキュリティ 再生可能エネルギー部門は、IoT セキュリティに関していくつかの課題に直面しています。主な課題とそれに対応するAWS IoT ソリューションは以下の通りです： デバイスのセキュリティ: 再生可能エネルギーシステムで使用される IoT デバイスには、悪意のある行為者に悪用される可能性のある脆弱性があります。これらの脆弱性は、安全でないファームウェア、セキュリティパッチの欠如、または脆弱な認証メカニズムに起因する可能性があります。これらのデバイスのセキュリティを向上させることは、不正アクセスや改ざんを防ぐために非常に重要です。AWS IoT は、セキュアな デバイスのオンボーディング 、 証明書管理 、 ポリシーベースのアクセス制御 を可能にするデバイス・セキュリティ・サービスを提供します。デバイスの脆弱性に対処するために、堅牢な 認証メカニズム 、セキュアな Over-the-Air(OTA) アップデート、 AWS IoT Device Defender などの脆弱性管理サービスを提供します。 相互運用性: 再生可能エネルギーシステムは、多くの場合、異なるメーカーのレガシーデバイスと最新デバイスが混在しています。セキュリティを維持しながら、これらの機器間のシームレスな統合と相互運用性を実現することは、難しいことです。レガシーデバイスには強固なセキュリティ機能がない場合があり、システムの潜在的な弱点となります。AWS IoT は、標準化されたプロトコルと API を通じて、異なるメーカーのデバイス間のシームレスな統合と相互運用性を促進します。AWS IoT Core と AWS IoT Greengrass は、安全な通信のための MQTT 、 HTTPs 、 Modbus プロトコルを提供し、セキュリティを維持しながらレガシーデバイスと最新デバイスの互換性を確保します。 データ・セキュリティ: IoT システムは、エネルギー生産、消費、ユーザー行動に関する機密情報を含む膨大な量のデータを生成します。このデータのプライバシーと機密性を保護することは非常に重要です。組織は、不正アクセスやデータ漏洩から保護するために、セキュアなデータ送信、保存、アクセス制御メカニズムを実装する必要があります。AWS IoT は、暗号化、セキュアなデータ伝送プロトコル（TLS など）、アクセス制御メカニズムを通じて、 エンドツーエンド のデータセキュリティを提供します。 リモートアクセスのセキュリティ: 再生可能エネルギーシステムの多くは遠隔地から監視・管理されるため、さらなるセキュリティリスクが生じます。制御システムや監視プラットフォームへのリモートアクセスは、不正アクセスや改ざんを防ぐために適切に保護されなければなりません。セキュアなリモートアクセスプロトコルと多要素認証を実装することで、これらのリスクを軽減することができます。AWS IoT は、 AWS Identity and Access Management (IAM) 、 AWS IoT Core 、 AWS IoT セキュアトンネリング を使用することで、IoT システムへのセキュアなリモートアクセスを提供します。 標準化されたセキュリティのベストプラクティス: IoT 技術は急速に進化しているため、標準化されたセキュリティプラクティスや規制がありません。これは、再生可能エネルギーシステム全体で一貫性のある強固なセキュリティ対策を実施するための課題となっています。業界全体のセキュリティ標準を策定し、関連規制に準拠することは、IoT セキュリティを向上させるために不可欠です。AWS IoT は、業界の セキュリティにおけるベストプラクティス と コンプライアンス に従っています。AWS IoT はガイドライン、フレームワーク、ドキュメントを提供し、組織が IoT の導入全体で堅牢なセキュリティ対策を実施できるよう支援します。 デバイス管理: 再生可能エネルギーシステムの IoT デバイスは、そのライフサイクルを通じて頻繁なメンテナンス更新が必要です。デバイスをセキュリティパッチやアップデートで常に最新の状態に保つことは、大規模な導入では難しい場合があります。組織は、脆弱性を減らすために、デバイスの更新とセキュリティパッチを管理する効率的なプロセスを確立する必要があります。AWS IoT は、大規模なデバイスの更新と管理のプロセスを簡素化するデバイス管理サービスを提供します。AWS IoT Device Management は AWS IoT Jobs を提供し、企業が IoT デバイスにセキュリティパッチやファームウェアアップデートを効率的に導入できるようにします。 AWS IoT が提供する包括的なセキュリティ機能とサービスを活用することで、企業はセキュリティ体制を強化し、ファームウェアや OS の脆弱性、相互運用性、データプライバシー、リモートアクセス、デバイス管理に関連するリスクを軽減することができます。 AWS IoT Greengrassによるエッジでのセキュリティ AWS IoT Greengrass は、Amazon Web Services(AWS) が提供するオープンソースのエッジランタイムソフトウェアサービスで、産業用デバイスなどのエッジデバイスにクラウド機能を拡張し、産業用デバイスのセキュリティを支援します。 AWS IoT Greengrass は、デバイスがエッジでローカルにデータを処理・分析することを可能にし、システムのレイテンシを削減し、オフラインモードでオペレーションを継続する機能を提供することで、低レイテンシとオフライン機能が要求される産業環境でのエッジコンピューティングとデータ処理を可能にします。これにより、機密データをローカライズし、伝送中のデータ漏洩の可能性を低減することで、機密データの安全性を保つことができます。 さらに、 AWS IoT ポリシー 、 クライアントデバイス認証コンポーネント 、AWS IAM ポリシーを使用して、ローカルとクラウドで AWS IoT Greengrass への認証と認可を制御できます。その結果、許可されたユーザーとデバイスのみが産業用デバイスにアクセスし、必要に応じてアクションを実行できます。 AWS Systems Manager &nbsp;は、エッジデバイスのリモートソフトウェアアップデートや構成管理を含むデバイス管理機能を提供します。また、 Systems Manger エージェント を通じて AWS IoT Greengrass と統合することで、産業用デバイスのセキュリティ体制を維持し、最新の OS パッチやアップデートを適用することができます。 AWS IoT Greengrass は、Edge Framework ESF (Everyware Software Framework) のサポートも認定されています。このフレームワークは、 IEC 62443-4-2 &nbsp;と&nbsp; IEC 62443-4-1 &nbsp;の両方のサイバーセキュリティ認証を世界で初めて取得したフレームワークです。この実績は、AWS IoT Greengrass が採用している強固なセキュリティ対策と業界をリードするサイバーセキュリティ標準への準拠を強調しています。その結果、ユーザーはエッジコンピューティングシステムの完全性と回復力に自信を持つことができ、サイバーセキュリティ保護を強化した IoT ソリューションの導入が可能になります。 これらの製品関連認証は、より高いレベルのソリューション認証に継承することができ、エンドツーエンドソリューションのセキュリティ標準やベストプラクティスへの準拠を求めるシステムインテグレーターやソリューションオーナーにとって有益です。つまり、AWS IoT Greengrass と Edge Framework ESF を大規模なソリューションの一部として使用する場合、この製品によって取得された認定は、ソリューション全体のコンプライアンスとセキュリティ態勢に貢献することができ、導入においてサイバーセキュリティを優先する人々に付加価値を提供することができます。 まとめ AWS IoT は、IoT セキュリティの課題を支援するために設計された包括的なサービススイートを提供します。統合作業を合理化し、コストを削減し、リスクを軽減することで、AWS IoT は組織に安全で効率的なソリューションを実装する力を与えます。AWS IoT が提供する edge-to-cloud のセキュリティアプローチは、厳格なサイバーセキュリティ標準に準拠した設計を保証し、堅牢で信頼性の高いセキュリティ対策を求める組織にとって信頼できる選択肢となります。AWS IoT の堅牢なセキュリティ機能を活用することで、再生可能エネルギー業界の組織は貴重なデータとデバイスを保護し、ソリューションの潜在能力を最大限に引き出すことに集中することができます。 著者について Muhammad Qazafi は、アメリカ合衆国を拠点とするソリューションアーキテクトです。ソリューションアーキテクトとして、AWS 上でのセキュアでスケーラブルかつ革新的なソリューションの設計、開発、実装において顧客を支援します。彼の主な目的は、AWS サービスの効果的な活用を通じて、顧客が測定可能なビジネス成果を達成するのを支援することです。Muhammad は15年以上の経験を持ち、多様な業界にわたる豊富な知識と専門知識を持っています。この豊富な経験により、彼はさまざまなビジネスが直面する独自の課題を理解し、顧客が AWS 上でソリューションを作成するのを支援することができます。 この記事は Muhammad Qazafi によって書かれた Protecting renewable energy systems using AWS IoT の日本語訳です。この記事は ソリューションアーキテクトの安田が翻訳しました。

このブログは Kunal Vasavada（Akridata）と Eric Yuen（Senior Partner Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 深層学習プロセスではデータ処理を行う前に、数百 GB に及ぶデータセット全体を読み込むことがよくあります。このようなパフォーマンスが重要なワークロードを実行している企業にとっては、ストレージからの高速なデータ取得と低レイテンシーが非常に重要です。 AWS 独立系ソフトウェアベンダー（ISV）パートナーである Akridata は、ラベルのない動画や画像のデータセットに対して人工知能（AI）を利用した大規模なデータ整理、調査、分析機能を提供することにより、非構造化データの探索を支援しています。 このブログでは、 Akridata Data Explorer がどのように機能するかを、自動運転の開発者がビジュアルデータセットの可能性を引き出した例を交えながら説明します。次に、Akridata Data Explorer を使用する際に、Amazon S3 標準と比較してデータアクセス速度が 10 倍向上しリクエストコストを 50 % 削減できる Amazon S3 Express One Zone ストレージクラスにデータを保存することで、3.5 倍処理を高速化できることについて説明します。 Akridata Data Explorer : ラベル付けされていないビジュアルデータの自動処理 Akridata Data Explorer は software as a service（SaaS）ソリューションで、確かな運用実績、膨大なサービスが利用可能、世界中の潜在的なお客さまにリーチ可能という理由から、すべて AWS 上で構築されています。Akridata Data Explorer は、Amazon Elastic Kubernetes Service（Amazon EKS）上で動作する柔軟なソリューションです。これにより、 Amazon S3 の様々なストレージクラスに格納された大量の動画や画像のデータを手動でラベル付けすることなく、エンドユーザーが分析可能なノーコード環境を提供します。 以下の画像は、Akridata Data Explorer のワークフローを示します。 ビジュアルデータセットを Amazon S3 にアップロードします。（今回の場合、Amazon S3 Express One Zone ストレージクラスを使用） Akridata Data Explorer SaaS サービスにサインインします。 Amazon Elastic Container Registry（Amazon ECR）から目的のモデルを選択し、データ処理パイプラインを作成します。 Akridata Data Explorer は Amazon S3 Express One Zone からデータを読み取り、深層学習処理を開始します。 作成されたデータカタログは、Amazon Aurora に保存されます。 最終的に、ビジュアルデータセットに対して検索やデータ分析等の視覚化操作を実行できます。 Akridata Data Explorer を自動運転のデータで使用する Akridata Data Explorer を説明するため、自動運転データの収集を例に挙げます。自動運転のデータ収集では、日々さまざまな国を走行する各テスト車両は何時間分もの動画や画像を撮影し、大量の非構造化データが収集されます。これらのデータセットはすべて、サニタイズ、クリーニング、タグ付けする必要があります。 Akridata Data Explorer は、すぐに利用できるさまざまなパイプラインを通じて、データセットに対して任意の基盤モデルや一般的な機械学習モデルを使用したタグ付けやラベル付けを自動的に実施できます。以下の画像は、Akridata Data Explorer おいて Recognize Anything Model（RAM）を使用した自動タグ付けの結果です。建物や駐車場といったインフラ関連のタグ、自動車、ジープ、SUV、バンといった自動車関連タグや道路タグがすべて自動的に付与されています。 次の画像は、Akridata Data Explorer がデータセット全体をクラスターに変換し、類似度に基づいてデータをグループ化しているものです。この視覚的なアプローチにより、大規模なデータセットの全体像を迅速かつ直感的に把握でき、外れ値を見つけることができます。 次の画像は、ユーザーが視覚的に類似した画像を検索できることを示しています。画像の場合、Akridata Data Explorer は 1 回のクエリで最大 2,500 万枚の画像を検索できます。一方でこのプロセスでは重い読み取り操作が求められ、最短時間でワークフローを完了するにはストレージサブシステムの高いパフォーマンスが必要です。Amazon S3 のスケーラビリティとパフォーマンスは、ユーザーエクスペリエンスにおいて重要な役割を果たします。 画像の左には、緑の境界枠で囲まれた 3 つの画像例があります。これらの例は、横断歩道と傘を持った人が写っています。対照的に赤い境界枠で囲まれた画像では、これらの特徴はありません。 似たような画像の例を見つけるには、横断歩道や傘を持った人が写っている画像の「いいね」アイコンを選択し、 Quick Search を選択します。画像の右に示す結果には、さまざまなシナリオにおいて類似した画像が示されます。この機能により、興味深いパターンやシナリオの発見が容易になります。 Akridata Data Explorer は自然言語クエリを使用して、ラベルのない動画や画像データセットを検索することもできます。次の画像は、Akridata Data Explorer において「傘を持っている人と横断歩道」と検索した結果を示しています。テキストベースの検索により、データからの洞察がより簡単に得られます。 Amazon S3 Express One Zone による非構造化データ探索の加速 Akridata Data Explorer を使用する場合、ストレージサブシステムは、深層学習、検出、タグ付け、検索にかかる時間に直接影響します。Amazon S3 Express One Zone は、スケーラブルであるだけでなく、データ分析のユースケースで一桁ミリ秒という優れたレイテンシーを実現する最速のクラウドオブジェクトストレージであり、お客様はこれまでで最高のパフォーマンスを体験することができます。 Amazon S3 Express One Zone にデータを保存すると、Akridata Data Explorer パイプラインの実行時間と処理時間は、Amazon S3 標準を使用する場合と比較して平均 3.5 倍も改善されます。結果として、データの取り込みや視覚的データ探索の準備、検索が格段に早くなります。お客さまがオリジナルの高画質な動画や画像を閲覧しようとした場合、Amazon S3 Express One Zone の低レイテンシーと高スループットはデータの準備時間を大幅に短縮し、ユーザーエクスペリエンスを大幅に向上させます。そしてお客さまは運用コストを削減しながら、より多くのデータを短時間で分析できるようになり、生産性が向上します。 まとめ このブログでは、Akridata Data Explorer にて自動運転のデータセットにタグ付けを自動的に行い、画像から特定のコンテンツを検索、データ分類における課題を解決している様子を紹介しました。加えて、Amazon S3 Express One Zone にデータを保存することで、Akridata Data Explorer のお客さまは、データの準備にかかる時間を平均で 3.5 倍高速化することができます。 詳細については、 Akridata や Amazon S3 Express One Zone にアクセスするか、担当の AWS 営業にご連絡ください。Akridata Data Explorer は AWS Marketplace より入手可能です。 Kunal Vasavada Kunal は、Akridata のソリューション開発とプラットフォームエンジニアリングの責任者です。彼の経験は、ハイブリッドデータインフラストラクチャ、ストレージ、システムエンジニアリング、フルスタックML、大規模かつ高速なデータプラットフォームにまで及びます。彼は現在、Akridata でプラットフォームエンジニアリングとカスタマーソリューションを率いており、大規模で分散型なデータ中心の AI アプリケーション向けに、インテリジェントでオープンアーキテクチャの Edge-to-Cloud DataOps プラットフォームを提供しています。 Eric Yuen Eric Yuen は AWS の Senior Partner Solutions Architect です。彼は AWS のストレージパートナーと密に連携してソリューションを構築し、お客さまが AWS 上でストレージ環境を設計するのを支援しています。Eric は、さまざまなストレージおよびデータ保護テクノロジーに取り組んだ 20 年の業界経験を持っています。

はじめに IoT (モノのインターネット)では、接続されたデバイスのパフォーマンスを監視して、異常動作を検出し、デバイスが侵害された時には迅速に対応することが重要です。 AWS IoT Device Defender は、接続されたデバイスとクラウドインフラストラクチャからメトリクスを収集し、デバイスの異常動作の検出機能を提供します。以前は、分析するためにデバイスメトリクスをデータレイクへ追加する場合は、ファームウェアの変更して追加の MQTT トピックへメトリクスをパブリッシュする必要がありました。これは、開発時間とコストに影響を与える可能性があり、特に大量のデバイスを管理する場合は問題になります。AWS IoT Device Defender の新しいメトリクスエクスポート機能は、デバイスメトリクスを AWS IoT Device Defender からデータレイクへ出力するための利便性とコスト効率に優れた方法を提供します。メトリクスエクスポート機能を使えば、ファームウェの変更は不要かつ、簡単な設定のみでメトリクスをエクスポートできます。この新機能は、既存のワークロードも含めて提供されます。 インド最大級の決済業者の 1 社である Paytm は、何百万もの消費者や小売り業者向けの金融取引決済を運用管理しています。最も人気のある IoT ソリューションの 1 つが soundbox デバイスで、Paytm の QR コード決済を行った際に音声で決済内容を伝える、小売業者向けサービスです。Paytm の QR コードサービスにより、企業は Paytm アプリを通じて店頭でのコンタクトレス決済を可能にしました。soundbox には、4G 通信の SIM カードと 50-60 時間のバッテリーが内臓されているため、露店といった小規模店のユーザーはインターネット回線の用意を心配する必要がありません。Paytm のデバイスからメトリクスを AWS IoT Device Defender へ送信することで、Paytm は soundbox の稼働状態を監視することができます。 AWS IoT Device Defender からのメトリクスエクスポート AWS IoT Device Defender は、コネクテッドデバイスに利用される主要なサービスです。AWS IoT Device Defender は、クラウド側やデバイス側から収集したメトリクスと、設定された期待値とを比較することにより、デバイスの異常動作をほぼリアルタイムで検出します。メトリクスは 2 つのソースから収集されます。一つは クラウド側メトリクス として、認証失敗の回数や、AWS IoT Core を介してデバイスが送受信するメッセージ数やサイズなどがあります。もう一つは デバイス側メトリクス として、デバイスが待受しているポート、送信したバイト数またはパケット数、TCP のコネクション数などがあります。フリート固有の カスタムメトリクス を利用することも出来ます。たとえば Wi-Fi ゲートウェイに接続しているデバイスの数や、バッテリーの充電レベル、スマートプラグの電源サイクルの数などを定義することが出来ます。メトリクスエクスポート機能を使用して、クラウド側やデバイス側のメトリクスや、カスタムメトリクスをエクスポートできます。 セキュリティプロファイル の設定で、エクスポートするメトリクスと送信先の MQTT トピックを指定できます。AWS IoT Device Defender はデータをバッチで処理し、セキュリティプロファイルで設定された MQTT トピックへパブリッシュすることで、エクスポートのコストを最適化します。メトリクスをエクスポートする方法としては 2 つのオプションがあります。 IoT Core ルールエンジンを使ったエクスポート AWS IoT Core のルールエンジン の機能を利用して、エクスポートされたメトリクスを任意の宛先にルーティングできます。このオプションを使用すると、AWS IoT Core の Basic Ingest を活用して、データのエクスポートコストを削減できます。次の図は、このオプションのリファレンスアーキテクチャを示しています。このオプションでは、AWS IoT Device Defender からメトリクスを Basic Ingest のトピックに送信し、AWS IoT Core の ルールエンジン でデータを任意の宛先にルーティングする様にルールを作成します。（例えば、 Amazon Kinesis Data Firehose を介して Amazon Simple Storage Service (Amazon S3) バケットにルーティングします） 図1: AWS IoT Core Rules Engine を使用した AWS IoT Device Defender メトリックエクスポートのアーキテクチャ MQTT サブスクリプションを使ったエクスポート このオプションでは AWS IoT Core を使って、AWS IoT Device Defender からデータを MQTT トピックへを送信し、MQTT トピックをサブスクライブすることでデータを利用します。次の図は、AWS IoT Device Defender からメトリクスを MQTT トピックに送信するリファレンスアーキテクチャを表しています。同じ MQTT トピックをサブスクライブする MQTT クライアント（例えば、 Amazon Elastic Container Service のコンテナ内）を実行します。AWS IoT Device Defender がデータをパブリッシュする毎に、MQTT クライアントはデータを受信して処理します。 図 2: AWS IoT Core MQTT Broker を使用した AWS IoT Device Defender メトリックエクスポートのアーキテクチャ ここからは、図 1 で確認した AWS IoT Device Defender からメトリクスをエクスポートするソリューションを構築していきます。 前提条件 AWS IoT Core、AWS IoT Device Defender、Amazon Kinesis Data Firehose、および Amazon S3 上での実行権限がある AWS アカウント AWS Identity and Access management (IAM) で AWS IoT Core に割り当てるロールの作成権限 AWS CloudShell へのアクセスと、Linux と AWS Command Line Interface (AWS CLI) の基本的な知識 手順 以下のステップでは、メトリクスエクスポート機能を使って、いくつかのクラウド側メトリクスと AWS IoT Device Defender のカスタムメトリクスを Amazon S3 にエクスポートするパイプラインを構築します。Basic Ingest のメカニズムを使用して、AWS IoT Device Defender のメトリクスを Kinesis Data Firehose 経由で Amazon S3 にエクスポートします。 初期設定 このステップでは IoT Core でモノを作成し、シミュレーターを使って、このモノのカスタムメトリクスを 5 分毎にパブリッシュします。初期設定と MQTT クライアントの実行には AWS CloudShell を使用します。 AWS コンソールにログインし、 CloudShell を開く 設定で利用するスクリプトとコードをダウンロードするために git リポジトリをクローンする $ git clone https://github.com/aws-samples/aws-iot-device-defender-metric-export.git ‘createThing.sh’ を実行して、AWS IoT Core に名前が ‘dd-export-test’ のモノを作成し、Amazon S3 に保存先バケットを作成します。 $ cd aws-iot-device-defender-metric-export $ bash ./createResources.sh dd-export-test AWS IoT Device Defender カスタムメトリクスの作成 次に、デバイスが観測したモバイルネットワークの電波強度 (RSSI) を収集および評価するためのカスタムメトリクスを作成します。 AWS IoT Core に移動し、左側のメニューから セキュリティ → 検出 → メトリクス を選択し、 作成 をクリックします。 カスタムメトリクスの作成 画面で、以下の値を入力し、 カスタムメトリクスの作成 (Create custom metric) をクリックします。 名前 (Name) – mobilerssi 表示名 (Display name) – Cellular Network Strength タイプ (Type) – number AWS IoT Device Defender セキュリティプロファイルの作成 次に、異常動作を定義する セキュリティプロファイル を作成します。AWS IoT Device Defender メトリクス、 カスタムメトリクス 、 ディメンション を組み合わせることで、ユースケースに応じた適切な検出モデルを作成出来ます。以下の例では、クラウド側メトリクス(受信したメッセージとサイズ)とモバイルネットワークの電波強度カスタムメトリクスを利用します。メトリクスを効果的に組み合わせる方法の詳細については、ドキュメントの セキュリティのユースケース をご確認ください。 AWS IoT Core で、左側のメニューをクリックし、 セキュリティ → 検出 → セキュリティプロファイル に移動します。 セキュリティプロファイルを作成 をクリックし、 ルールに基づいた異常検出プロファイルを作成 を選択します。 セキュリティプロファイルのプロパティを指定する のステップで、以下の値を入力し、 次へ をクリックします。 セキュリティプロファイル名 (Profile name) – Monitor_RSSI ターゲット (Target) – ターゲットグループ、1 つまたは複数のグループを選択できます。この例では、 dd-metric-export-group をターゲットにします。 メトリクス動作の設定 のステップで、次の操作を行います。 クラウド側のメトリクス下にある メッセージサイズ を探して選択し、 アラートを送信しない(リテンションメトリクス) オプションを選択します。 メトリクスの追加 をクリックし、先ほどと同じ様に 受信したメッセージ と Cellular Network Strength メトリクスを繰り返し選択します。 次へ をクリックします。 メトリクスをエクスポートする のステップで、 メトリクスのエクスポート設定 を以下のように設定し、 次へ をクリックします。 メトリクスをエクスポートする (Export Metrics): メトリクスのエクスポートを有効にする を選択します。 トピック (Topic): $aws/rules/dd_export_firehose/ddmetric/cellular IAM ロール (IAM Role): 新しいロールの作成 をクリックし、表示された手順に従います。 メトリクスの選択: 提供されたリストから メッセージサイズ 、 受信したメッセージ 、 Cellular Network Strength を選択します。 通知の設定 のステップでは SNS の構成は空白のまま 次へ をクリックします。 確認と作成 のステップで構成を確認して 作成 をクリックします。 メトリクス動作の設定した内容は以下の様な画面になります。 AWS IoT Core ルールの作成 このセクションでは、AWS IoT Core ルールエンジンでルールを定義して、Basic Ingest のトピック $aws/rules/dd_export_firehose/ddmetric/cellular で受信したデータを、Kinesis Data Firehose のデータストリームに転送します。 AWS IoT Core に移動し、左側のメニューで メッセージのルーティング → ルール を選択して、 ルールの作成 をクリックします。 ルールのプロパティ で、ルール名を dd_export_firehose と入力し、 次へ をクリックします。 SQL ステートメントを設定 のステップで、次の SQL ステートメントを指定し、 次へ をクリックします。 SELECT * FROM 'ddmetric/#' ルールアクションをアタッチ のステップの、 ルールアクション パネルで、 アクション 1 に Kinesis Firehose stream を選択します。 Firehose ストリームを作成 をクリックします。すると、新しいウィンドウで 配信ストリームを作成 ページが開きます。 ソースと送信先を選択 パネルで ソース として Direct Put を選択します。 送信先 として、 Amazon S3 を選択します。 配信ストリーム名 パネルで 配信ストリーム名 フィールドに dd-metric-export-stream と入力します。 送信先の設定 パネルで S3 バケットとして、 &lt;Account_id&gt;.dd.metric.export S3 バケットを参照ボタンから探し選択します。 その他はすべてデフォルトのままにします。 配信ストリームを作成 をクリックし、配信ストリームの作成完了を待ちます。ステータスフィールドが 作成中 から アクティブ に変わったことを確認します。 前のウィンドウ ( ルールアクションをアタッチ ) に戻ります。 Kinesis Firehose ストリーム のドロップダウンから、 dd-metric-export-stream を選択します。ドロップダウンに新しく作成したストリームが表示されない場合は、ドロップダウンの横にある更新ボタンをクリックしてエントリを更新してください。 区切り文字 と バッチモード はそのままにします。 IAM ロール : 新しいロールを作成 をクリックし、表示された手順に従います。 次へ をクリックします。 構成を確認し、 作成 をクリックします。 カスタムメトリクスをパブリッシュし、データ出力を確認する 次に、作成したパイプラインをテストするためにデバイスシミュレータを実行します。 AWS CloudShell プロンプトに移動し、次のスクリプトを実行します。スクリプト内で MQTT クライアントが実行され、5 分ごとに AWS IoT Device Defender の カスタムメトリクスレポート として、モバイルネットワーク RSSI がパブリッシュされます。 $ bash ./publishMetric.sh スクリプトを 15 分以上実行させてください。(Kinesis Firehose はデータを 15 分間バッファリングします) Amazon S3 の &lt;Account_id&gt;.dd.metric.export バケットに移動し、エクスポートされたデータを確認してください。 クリーンアップ 実験後のコスト発生を避けるために、下記手順を実行: スクリプトを実行しているターミナルで Ctrl + C を押して、MQTT クライアントを停止します。 次のスクリプトを実行して、作成した AWS IoT Core のモノを削除します。 $ bash ./cleanupResources.sh 作成した AWS IoT Device Defender セキュリティプロファイルを削除します。 作成した AWS IoT Device Defender カスタマーメトリクスを削除します。 作成した AWS IoT Core ルールを削除します。 作成した Kinesis Data Firehose 配信ストリームを削除します。 作成した Amazon S3 バケットを削除します。 まとめ この投稿では、新しい AWS IoT Device Defender メトリクスエクスポート機能の使用方法を学びました。AWS IoT Device Defender からサービスまたは希望のストレージへメトリクスをエクスポートする方法を学び、エクスポートのコスト最適化に関する方法を学びました。メトリクスを複数の宛先にエクスポートする場合は、AWS IoT Core ルールエンジンのファンアウト機能も検討出来ます。 詳細については、 AWS IoT Core サイトをご覧いただくか、 コンソールにログイン して利用を開始してみてください。ご意見やご質問をお待ちしています。 著者について Reetesh Varshney Reetesh は Amazon Web Services の IoT スペシャリストです。彼は業種を問わずお客様と協力し、IoT が可能にするビジネスチャンスと技術について支援しています。また、スマートコネクテッドプロダクト、コネクテッドビークル、スマートファクトリーの IoT プラットフォーム開発でもお客様を支援してきました。 Andre Sacaguti Andre Sacaguti は、AWS IoT のシニアプロダクトマネージャーです。デバイスメーカー、自動車メーカー、そしてさまざまな業界のお客様が、IoT デバイスを監視および保護できるような製品やサービスの構築をエッジからクラウドに渡って注力しています。AWS 入社以前は、T-Mobile や Qualcomm で IoT 製品の構築やローンチを行っていました。 この記事は “How to use the new metric export capability of AWS IoT Device Defender” の日本語訳です。この記事はソリューションアーキテクトの 山岡 卓紀夫 が翻訳しました。

本日（US時間 11 月 30 日）、私たちは AWS Supply Chain について、サプライチェーンの上流のプロセスをサポートするために4つの新機能を発表しました。 コンポーネントと製品在庫を計画、配置、補充するのに役立ち、在庫コストを削減し、需要の変動とサプライチェーンの混乱により迅速に対応できる AWS Supply Chain Supply Planning 。 貴社とサプライヤー間のコミュニケーションを効率化し、供給計画への対応と実行段階における需要またはサプライの変更の管理を改善する AWS Supply Chain N-tier Visibility （複数段のサプライチェーンに対する可視化） 。この機能により、わずか数クリックで複数階層の取引先と安全に連携できます。 サステナビリティデータの要求、収集、監査を可能にする格納場所を提供する AWS Supply Chain Sustainability 。 生成系 AI を利用して、分析と意思決定を支援する会話型エクスペリエンスをサプライチェーンのプロフェッショナルに提供する AWS Supply Chain の Amazon Q 。 これらの新しい機能は、2024年に利用可能になり、既存のデータレイク、需要予測、機械学習 (ML) によるインサイトを拡張します。 今日、お客様は在庫の可視性を高め、品切れを防ぎ、過剰在庫による在庫保有コストの増加を減らすために AWS Supply Chain を利用しています。 AWS Supply Chain は、個別のERPに格納された、互いに関係した顧客データを 統一された正規データモデルに基づいて集約し、サプライチェーンデータレイク (SCDL) を作成することが出来るためです。 この統一された SCDL により、在庫の可視性を高める Insights という AWS Supply Chain 機能が可能になり、機械学習を活用し、在庫とリードタイムのリスクを軽減するための在庫配置や補充に対する推奨が提供されます。Demand Planning 機能は Amazon の深いサプライチェーンの専門知識と機械学習を組み合わせ、正確性を向上させるためにモデルを継続的に調整しながら、販売履歴データとリアルタイムデータを分析して予測を作成しています。 サプライチェーン上流の課題 サプライチェーンの上流部分には、サプライヤーや取引先パートナーからの原材料とコンポーネントの調達と移動が含まれます。 サプライチェーンのリーダーは、サプライヤー、メーカー、ディストリビューター、小売業者など、多くの異なるレイヤーの取引先との調整が絶えず課題であると伝えてきました。 各取引先には、独自のデータ管理システムがあり、高価なカスタマイズや長い開発サイクル、または手作業による回避策を必要とすることが多いです。 その結果、供給計画担当者は、予測、注文確認、出荷数量など整合するのに多くの時間を費やしています。 データがサイロ化していることが、需要の変動、サプライの中断、ベンダーのリードタイムの不確実性と相まって、企業が正確に在庫を把握し、顧客需要を満たすのを困難にしています。 製造業のお客様は、原材料とコンポーネントの価格・入手が変動することにより一層の複雑さに直面しています。さらに、取引先の顧客からのデータ要求への対応は、品質、頻度、適時性、構造の点で顧客毎に異なっており、必ずしも体系的に追跡または監査されているわけではありません。 大量の規制対応情報(炭素排出量や有害物質開示など)を管理することは、同様に困難であり、これまでは正式な追跡や監査メカニズムではなく、電子メール、ファックス、メッセージアプリを介して行われてきました。その結果、多くの組織では、需要を効率的に満たしたり、厳しくなる規制要件を満たしたりするために、適切な数量の商品を適切な時間に適切な場所に確実に配置することに苦慮しています。 本日発表された新しい AWS Supply Chain 機能を使用することで、上流のサプライチェーン・プロセスを改善し、材料の在庫率や入荷率を向上させ、サプライヤーとコミュニケーションを取りながら供給計画を確認し合意を得ることができます。また、重要な環境要因に関する正確なデータを取得することもできます。これらの機能についてもっと詳しく見ていきましょう AWS Supply Chain Supply Planning Supply Planning の機能は、Amazon が自社の運用のために高度なサプライプランニングモデルを開発してきた専門知識に基づいています。Supply Planning は、施設全体で必要な在庫水準を正確に判断できる高度なサプライプランニングモデルを作成します。サプライプランは、AWS Supply Chain デマンドプランニングによって作成された需要予測と、SCDL からの製品、施設、部品表 (BOM)、在庫、その他の顧客情報を組み合わせて生成されます。このデータの自動統合により、情報の品質が向上し、予測、注文確認、仕入先リードタイムなどを含むさまざまなレポートを手動で統合する作業によるリスクが軽減されます。 Supply Planning は需要の変動、仕入先のリードタイム、発注頻度を考慮して在庫目標を動的に計算し、在庫発注や在庫移動を推奨します。これにより、発注または移動する単位数、発注または移動のタイミング、在庫の配置場所を最適に決定することができます。 次のスクリーンショットは、在庫状況、発注状況、運用指標などをまとめた Supply Planning ダッシュボードを示しています。各カテゴリの詳細を確認し、適切な対応を取ることができます。 AWS Supply Chain N-Tier Visibility N-Tier Visibility（複数段のサプライチェーンに対する可視化） は、組織外の複数の外部取引先の可視性と、そこから洞察を得る能力を向上させます。 わずか数クリックで取引先を招待し、利用を開始してもらうことができ、ネットワーク全体のすべてのパートナーを次のスクリーンショットのように表示できます。 この接続性により、取引先はコミュニケーションを自動化し、自社の予測を改善することもできます。 例えば、AWS Supply Chain の N-Tier Visibility から、取引先と購入注文や供給予測を共有し、それらの購入注文や在庫レベルの変化を追跡することができます。 更新された供給計画と購入注文は Amazon Simple Storage Service (S3) にエクスポートされるので、エンタープライズリソースプランニング (ERP) システムと統合できます。 内蔵されたチャットとメッセージング機能により、サプライチェーン全体でのコラボレーションがさらに容易になります。 例えば、コンポーネントの出荷が遅れた場合、在庫管理者は AWS Supply Chain アプリケーション内で回避策を特定するためにサプライヤーに連絡できます。 サプライヤーや製造業者との内部コラボレーションと情報共有の改善により、調達リスクとコンポーネント不足を検出する能力が向上し、迅速に混乱を軽減できるようになります。 AWS Supply Chain Sustainability Sustainability の機能では、サプライヤーネットワークから必須のドキュメントやデータセットをより安全で効率的な方法で入手することができます。製品のライフサイクルアセスメント、製品安全性に関する証明書、サプライチェーンの有害物質に関する報告書など、どの時点でも使用される成果物を要求、収集、エクスポートすることができます。 また、サプライヤーにサステナビリティの課題を文書化してもらうための独自のデータ収集フォームをアップロードし、複数の改装にまたがって取引相手にデータ要求を送信し、回答を追跡し、不在者にリマインダーを送信し、回答を保存・閲覧するための格納場所を提供することもできます。これは、次のスクリーンショットに示されています。 また、サプライヤーにサステナビリティの課題を文書化してもらうための独自のデータ収集フォームをアップロードし、複数の改装にまたがって取引相手にデータ要求を送信し、回答を追跡し、不在者にリマインダーを送信し、回答を保存・閲覧するための格納場所を提供することもできます。これは、次のスクリーンショットに示されています。 Amazon Q in AWS Supply Chain 最後に、Amazon Bedrock を用いた自然言語インターフェースを備えた生成 AI アシスタントにより、AWS Supply Chain は SCDL 内のデータを問い合わせでき、「何を?」「なぜ?」「もし~だったら?」といった質問に対してインテリジェントな回答を提供します。質問はアプリケーション内の文章による対話を通じて行うことができます。Amazon Q は、複雑なシナリオの結果と、さまざまなサプライチェーンの意思決定のトレードオフを可視化することもできます。 質問と回答の例は次のようになります。 Q 1 : ブレーキパッドは何個注文していますか? A 1 : ブレーキパッドカテゴリーでは、5 つの製品にわたって 1500 個を注文しています。 Q 2 : ブレーキパッドの注文数量は先月と比べてなぜ増加したのですか? A 2 : サプライヤー AA のリードタイムが先月の 28 日から今月は 56 日に延びたため、注文数量は 50% 増加しました。 Q 3 : サプライヤーがリードタイムを 2 週間短縮した場合、注文はどう変わりますか? A 3 : サプライヤー AA からのブレーキパッドのリードタイムが2週間短縮して 42 日になった場合、注文数量は 20% 減少します。 応答は次のスクリーンショットに示します。 これは、Amazon Q in AWS Supply Chain が幅の能力の広さと深さを示す例です。Amazon Q in AWS Supply Chain は応答が速く正確で、すばやく洞察を得たり、因果関係を理解したり、サプライチェーンのパフォーマンスを改善する可能性がある選択肢を特定するのに役立ちます。 まとめ AWS re:Invent は、お客様、パートナー、AWS にとってエキサイティングなイベントです。互いに出会い、学び合い、最新のイノベーションを共有できるからです。今年、サプライチェーンの計画を改善し、複数のティアのサプライチェーン全体での可視性を高め、重要な課題に対応する 4つの新機能を発表しました。Supply Planning、N-Tier Visivility、Sustainability、Amazon Q in AWS Supply Chain は、2024 年第 1 四半期初頭に利用可能になります。 AWS Supply Chain &nbsp;をご覧いただき、詳細をご確認ください。セルフペースの技術概要については、 AWS Workshops をご覧ください。re:Invent セッションの録画やその他の役立つリソースにアクセスするには、 re:Invent ページもご覧ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Diego Pantoja-Navajas は AWS Supply Chain の VP で、ビジネスアプリケーションのビジョンと実行を担当しています。彼と彼のチームは、サプライチェーンがどのように機能できるかを根本的に考え直し、世界で初めての連続的に改善するサプライチェーンシステムオブレコードを市場に投入することに注力しています。彼は顧客の成功に情熱を注ぎ、SaaS、クラウド、AI/ML テクノロジーを活用して、サプライチェーン、e コマース、フルフィルメントに関連するビジネスの問題を解決するための高度に使いやすく知的な B2B エンタープライズソフトウェアソリューションを構築しています。Diego はジョージア工科大学の優等生で、MIT の人工知能・機械学習のエグゼクティブエデュケーションコースなど、トレーニングを続けています。また、IESE ビジネススクール、ミシガン大学ロス・ビジネススクールとのパートナーシップのもと、リーダーシップコースにも参加しています。彼は南フロリダに家族と暮らしており、顧客のビジネスの成功をさらに推進する革新的な製品やソリューションを学ぶことを常に喜んでいます。 <!-- '"` -->