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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

チームを編成して優れたソフトウェア製品を提供するには、さまざまな方法があります。 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 までお気軽にご連絡ください。新機能の優先順位付けと開発に役立つフィードバックをお待ちしています。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。