Category: Compute

米国ペット用品協会の報告によると、米国では過去1年間に1,300万人を超える人々が新しいペットを自宅に迎え入れています。 そして愛すべきペットが近くにいることは非常に良い効果をもたらし、4人のペットオーナーのうち3人は、家にペットを飼うことで、COVID-19 パンデミックでの生活のストレスを軽減するのに役立ったと言っています。 特に過去1年間、ペットは私たちの生活において重要な役割を果たしており、ペットのためのおやつを常備しておくことは、ソーシャルディスタンスや COVID-19 安全対策と同じくらい大切です。

AWS Black Belt オンラインセミナー「CON371 Amazon ECS Anywhere」を公開します。 視聴は YouTube から、資料閲覧は SlideShare から可能です。 本セッションでは、Amazon Elastic Container Service (Amazon ECS) の機能の一つである Amazon ECS Anywhere について、Amazon ECS Anywhere が登場した背景や Amazon ECS Anywhere のアーキテクチャ、利用開始の手順などを紹介しています。

この記事は、Running GPU-based container applications with Amazon ECS Anywhere (2021/10/08 投稿) を翻訳したものです。 過去 10 年間で、数万ものお客様がオンプレミスのワークロードをクラウドに移行しています。一方で、単純にクラウドへ移行できないワークロードも数多く見てきました。それどころか、それらのワークロードは、データの保持要件やネットワークレイテンシー、規則やコンプライアンスなどの考慮事項により、オンプレミスで実行される必要があります。

この記事は、”Stream a remote environment with NICE DCV over QUIC UDP for a 4K monitor at 60 FPS” を翻訳したものです。 近年、ゲーム開発の分散化が進んでいます。 2020年、COVID-19はリモートにおけるソリューションの需要と革新を加速させました。 形態や規模には関係なくゲームチームには2つの選択肢が残されていました。急いで自宅にワークステーションを持ち帰って、仮想プライベートネットワーク (VPN) 経由でオフィスにアクセスするか、オフィスに開発用のワークステーションを残し、リモートデスクトッププロトコル (RDP) 経由で自宅のハードウェアからアクセスするかのどちらかでした。しかし、現在、ゲーム開発者たちは、完全なクラウド移行により、自分たちの思い通りの、より永続的に作業できる環境を作り出そうとしています。 多くのゲームスタジオで、ワークステーションや継続的インテグレーション/継続的デプロイ(CI/CD) パイプラインのクラウドインフラストラクチャへの移行が進んでいます。AWSのゲーム開発クラウドソリューションを活用することで、ゲーム開発チームはリモートで迅速にコーディング、デプロイ、リリースを行うための必要なリソースを得られます。以前は、分散型の開発パイプラインを作成するために、ゲームスタジオはエンジニアにハードウェアを渡し、新しく作成した環境のオンボーディングに膨大な時間を費やす必要がありました。コストの削減をしながら、没入感がありユーザーを楽しませるゲームの構築により多くの時間を費やしつつ、さらに世界中にいる従業員たちのハイブリッドな作業環境のサポートをするために、開発者はAWSを利用して、クラウドでのゲーム制作(GPIC)のソリューションに移行し、リモートでのQAテスト、プレスへのゲーム配信、没入感のある環境での3D開発ストリーミングの統合などの様々なユースケースで活用しています。 すべてのクラウド上でのゲーム制作のユースケースにおいては重要な命題があります。それは、いかにしてストリーミング中に高いフレームレート(FPS) を保つか？というものです。本記事では、AWS クラウド上で、ストリーミング60 FPSでストリーミングできるようにリモートワークステーションを構築し、NICE DCVでQUIC UDP通信を利用する手順を説明します。NICE DCVは、リモートデスクトップやアプリケーションストリーミングを安全にかつ高パフォーマンスで配信できるリモートディスプレイプロトコルです。

このブログはSeth Eliot (Principal Reliability Solutions Architect with AWS Well-Architected)によって執筆された内容を⽇本語化したものです。原⽂はこちらを参照して下さい。 前回のブログ記事で、AWS での災害復旧 (DR) に関する4つの戦略を紹介しました。これらの戦略により、災害イベントに備え復旧が可能になります。AWS Well-Architected Reliability Pillar ホワイトペーパーで提供されているベストプラクティスを使用して DR 戦略を設計することで、自然災害、技術的障害、または人的な行為による災害が発生しても、ワークロードを利用し続けることができます。 DR戦略: バックアップと復元の選択 図1に示すように、バックアップと復元はRTO（目標復旧時間）とRPO（目標復旧時点）が一番大きくなる選択と位置付けられています。その結果、災害発生から復旧までの間にダウンタイムが長くなり、データ損失が大きくなります。ただし、バックアップと復元は、実装するのが最も簡単で低コストの戦略であるため、ワークロードによっては適した戦略です。すべてのワークロードでRTOとRPOを数分以内に抑えることを必要とするわけではありません。

*本投稿は原文 (2021年12月23日更新版) の日本語訳です 概要 この投稿では、最近公開された Log4j の脆弱性に対応しているお客様を支援するためのガイダンスを提供します。ここでは、脆弱性のリスクを制限するためにできること、問題の影響を受けやすいかどうかを特定する方法、適切なパッチでインフラストラクチャを更新するためにできることについて説明します。 Log4j の脆弱性（CVE-2021-44228、CVE-2021-45046）は、ユビキタスロギングプラットフォームの Apache Log4j における重大な脆弱性（CVSS 3.1 基本値 10.0）です。この脆弱性により、攻撃者は脆弱なプラットフォームでリモートでコードを実行する可能性があります。バージョン 2.0-beta-9 と 2.15.0 の間の Log4j のバージョン 2 が影響を受けます。 この脆弱性は、Java プログラムによって使用される Java Naming and Directory Interface (JNDI) を使用します。JNDI は、通常、ディレクトリ (この脆弱性の場合は LDAP ディレクトリ) を介してデータを検索します。 下の図 1 は、Log4j JNDI 攻撃フローを示しています。

このブログは Seth Eliot (Principal Reliability Solutions Architect with AWS Well-Architected) によって執筆された内容を⽇本語化したものです。原⽂はこちらを参照して下さい。 AWS Well-Architected 信頼性の柱のリードソリューションアーキテクトとして、お客様が AWS で復元力のあるワークロードを構築できるように支援をします。これは、お客様が直面する可能性のある最大の課題の1つである災害イベントに備えるのに役立ちます。このようなイベントには、地震や洪水などの自然災害、電力やネットワークの損失などの技術的な障害、不注意や不正な変更などの人的行為が含まれます。最終的に、ワークロードまたはシステムが主要な場所でビジネス目標を達成するのを妨げるイベントは、災害として分類されます。このブログ投稿では、災害に備えて復旧するプロセスである災害復旧 (DR) の設計方法を示しています。DR は、事業継続計画の重要な部分です。

食料品市場は、COVIDパンデミックによって深刻に混乱しました。 消費者はオンラインショッピングと自宅配送にシフトしました。 例えば、2020年には、英国の食料品全体に占めるオンラインシェアは2024年のCOVID以前の予測を上回り、2020年には8.8％に達しました。国際市場でも同様の成長が見られました。 制限は徐々に解除されていますが、いくつかの消費者のトレンドはここに留まっています。 FoodNavigator によれば、イギリスでは91％の人が「同じくらい、またはそれ以上」料理することを今年予定しており、マッキンゼーのレポートによると、消費者はパンデミック前よりもパンデミック後の食料品に多くのお金を費やすと予測しています。 消費者の巣ごもりと家庭料理の継続、および食料品店のわずかなマージンを考慮すると、カスタマージャーニーを差別化し、再発明することは、小売業者の成長と効率を高めるために非常に重要です。食料品店は、購買履歴、顧客プロファイルや嗜好、ロイヤリティに基づく情報など、顧客のデータを長期間にわたって収集しているため、競争上の優位性があります。 このデータを使用して高度にパーソナライズされたサービスを設計および提供すると、顧客満足度とロイヤルティが向上するだけでなく、総売上高が1〜2％増加します。 小売業者がパーソナライズを使用し豊富な洞察を得ることで売り上げを伸ばす方法に関するAWSの視点については、「パーソナライゼーション：より深い洞察を得て売り上げを伸ばすために」の投稿で説明しています。

(この記事は、Choosing a Well-Architected CI/CD approach: Open Source on AWSを翻訳したものです。) イントロダクション CI/CDプラットフォームを構築する際には、ベースとなる全てのツールについて詳細な情報に基づいた意思決定を行うことが重要です。この投稿では機能要件と非機能要件、価値の最大化のバランスに焦点を当てて各ツールを選択するための基準を評価する方法を模索します。

この記事は、Implementing SaaS Tenant Isolation Using Amazon SageMaker Endpoints and IAM を翻訳したものです。 本投稿は、AWS の Sr. Solutions Architect である Michael Pelts と、DoiT International 社の Sr. Cloud Architect である Joshua Fox により寄稿されました。 マルチテナントの SaaS (Software-as-a-Service) プロバイダーが機械学習サービスの活用を検討する際には、異なるテナントからこれらのサービスに出入りするデータをどのように保護するかを検討する必要があります。 SaaS プロバイダーは、機械学習 (ML) サービスへのリクエストごとに、各テナントのデータがクロステナントアクセス (テナントの境界を超えた相互アクセス) から確実に保護されるような分離構造を導入する必要があります。 (原文寄稿者である) Michael は AWS にて、Joshua は DoiT International 社にて、それぞれデジタルネイティブな企業に対して支援を行うクラウドアーキテクトです。DoiT International 社は AWS アドバンスドコンサルティングパートナーであり、マネージドサービスプロバイダー (MSP) としてインテリジェントなテクノロジーと無制限のアドバイザリー、テクニカル、クラウドエンジニアリングのサポートを提供しています。 私たちの経験では、ML サービスプロバイダーの中には、テナントリソースを分離しているところもあれば、全てのテナントでリソースを共有しているところもあります。 […]