Amazon Web Services ブログ

Jeff Barr

Author: Jeff Barr

Jeff Barr is Chief Evangelist for AWS. He started this blog in 2004 and has been writing posts just about non-stop ever since.

新規 – Amazon DocumentDB (MongoDB 互換): 高速、スケーラブル、高可用性

AWS データベースのページを見ると、私たちが信じられないほど幅広い種類のデータベースを提供していること、それぞれが特定のニーズに対応するために作られていることが分かるでしょう! 最も素晴らしく、最も強力なアプリケーションを構築するために、リレーショナルデータベース、キーバリューデータベース、インメモリデータベース、グラフデータベース、時系列データベース、台帳データベースを組み合わせることができます。 Amazon DocumentDB (MongoDB 互換) の概要 本日、既存の MongoDB アプリケーションおよびツールと互換であるように設計された、高速、スケーラブル、高可用性のドキュメントデータベース Amazon DocumentDB (MongoDB 互換) を開始します。Amazon DocumentDB は、専用の SSD ベースのストレージレイヤーを使用し、3 つの個別のアベイラビリティーゾーンにわたって 6 のレプリケーションを作成します。このストレージレイヤーは分散型で、耐障害性があり、自己修復型であるため、本稼働規模の MongoDB ワークロードを実行するために必要なパフォーマンス、スケーラビリティ、可用性が得られます。 それぞれの MongoDB データベースには、一連のコレクションが含まれています。それぞれのコレクション (リレーショナルデータベースのテーブルに類似) には、それぞれが JSON に似ている BSON フォーマットである、一連のドキュメントが含まれています。以下に例を挙げます。 { name: “jeff”, full_name: {first: “jeff”, last: “barr”}, title: “VP, AWS Evangelism”, email: “jbarr@amazon.com”, city: “Seattle”, foods: [“chocolate”, “peanut butter”] } […]

Read More

クラウド規模での Western Digital HDD シミュレーション – HPC タスク 250 万件、EC2 スポットインスタンス 4 万個

今月の初めに、同僚の Bala Thekkedath がエクストリームスケール HPC についての記事を公開し、AWS のお客様である Western Digital が AWS でクラウド規模の HPC クラスターを構築し、それを使用して次世代ハードディスクドライブ (HDD) のための将来のヘッドにおける極めて重要な要素をシミュレートした方法について語りました。 この記事で説明されているシミュレーションには 250 万強のタスクが含まれており、その実施は vCPU 100 万個の Amazon EC2 クラスター上でわずか 8 時間で完了しました。Bala がその記事で述べたように、Western Digital でのシミュレーション作業のほとんどが、HDD を包含するテクノロジーとソリューションの異なる組み合わせを評価する必要性を中心に展開されています。エンジニアはその過程において、ますます多くのデータを同じ領域に詰め込むこと、ストレージ容量を改善すること、そして転送速度を向上させることに焦点を当てます。材料、エネルギーレベル、および回転速度の何百万もの組み合わせのシミュレートすることは、Western Digital が最も高い密度と最も速い読み取り/書き込み時間を追求することを可能にし、結果をより迅速に得ることは、より良い判断を行うことを可能にすると共に、新しい製品を以前より速く市場に出すことができるようにします。 以下は、Western Digital のエネルギーによる記録処理が行われる様子を可視化したものです。上の横棒は磁気、中央の横棒は付加されたエネルギー (熱)、そして下の横棒は磁気と熱の組み合わせによって媒体に書き込まれた実際のデータを表しています。 先日、私は記録を塗り替えるこのシミュレーションを実現するために共に取り組んだ私の同僚、Western Digital のチーム、そして Univa に話を聞きました。私の目的は、このシミュレーションのための準備方法についての詳細を解明し、彼らが学んだ事柄を理解して、独自の大規模ジョブを実行する準備が整っている皆さんとそれらを分かち合うことでした。 規模の拡大 約 2 年前、Western Digital チームは、可能な限りコスト効率を良くするために、EC2 スポットインスタンスによって作動する、vCPU 8 万個もの大きさのクラスターを実行していました。クラスターは、8,000 個、1 万 6,000 個、および […]

Read More

新開設 – AWS 欧州 (ストックホルム) リージョン

去年、皆さんとお約束したとおり、スウェーデンの AWS リージョンが始動し、本日よりご利用いただけるようになりました。 公式名は欧州 (ストックホルム) で、API 名は eu-north-1 です。このリージョンは既存の 欧州 (アイルランド)、欧州 (ロンドン)、欧州 (フランクフルト)、欧州 (パリ) に加えて 5 番目のリージョンとなります。これらのリージョン全体で 15 のアベイラビリティーゾーンが提供され、回復力と耐障害性に優れたアプリケーションを構築できるようになります。これで、北欧のお客様のデータをより所在地から近い場所で管理するのに役立つ選択肢をご利用いただけるようになりました。 インスタンスとサービス この 3-AZ リージョンで実行するアプリケーションは、C5、C5d、D2、I3、M5、M5d、R5、R5d、および T3 のインスタンスを使用でき、次に示す豊富な AWS サービスを使用できます。Amazon API Gateway、Application Auto Scaling、AWS Artifact、AWS Certificate Manager (ACM)、Amazon CloudFront、AWS CloudFormation、AWS CloudTrail、Amazon CloudWatch、CloudWatch Events、Amazon CloudWatch Logs、AWS CodeDeploy、AWS Config、AWS Config Rules、AWS Database Migration Service、AWS Direct Connect、Amazon DynamoDB、EC2 Auto Scaling、EC2 Dedicated […]

Read More

新機能 – 100 Gbps ネットワークとローカル NVMe ストレージを装備した EC2 P3dn GPU インスタンスにより、より高速な機械学習が可能に、さらに P3 料金の値下げ

昨年後半に、Amazon EC2 P3 インスタンスについてお伝えしましたが、その際 Tensor Core のコンセプトにも触れました。これは、大規模なディープニューラルネットワークのための機械学習のトレーニングと推論にかかる時間を短縮する、計算に特化したユニットです。弊社のお客様はこの P3 インスタンスにご満足のようで、さまざまな機械学習や HPC ワークロードの実行に、これらのインスタンスを使用されているようです。例を挙げると、fast.ai は、100 万個の画像を使った ResNet-50 深層学習モデルをわずか 40 USD でトレーニングしますが、深層学習の最速スピード記録を達成しました。 限界への挑戦 今日、p3dn.24xlarge インスタンスを追加して、P3 を最上位の製品へと拡張し、その結果、GPU メモリは 2 倍に、vCPU は p3.16xlarge インスタンスと同じ 1.5 倍に増強しました。このインスタンスは、100 Gbps のネットワーク帯域幅 (以前の P3 インスタンスの最大 4 倍の帯域幅)、ローカル NVMe ストレージ、32 GB の GPU メモリを装備した最新の NVIDIA V100 Tensor Core GPU、高速化した GPU 間の通信を行う NVIDIA NVLink、そして全コア Turbo をサポートし 3.1 […]

Read More

新しい AWS Resource Access Manager – クロスアカウントでのリソース共有

以前に説明したように、顧客はさまざまな理由で複数の AWS アカウントを使用しています。一部の顧客は、複数のアカウントを使用して管理および課金を切り分けています。爆発半径を設定して、間違いの影響をコントロールしている顧客もいます。 こうした分離はすべての顧客にとって実際にポジティブなものですが、特定のタイプの共有が有用で有益であることも判明しています。たとえば、多くの顧客は、管理のオーバーヘッドや運用コストを削減するために、リソースを一元的に作成してアカウント間で共有したいと考えています。 AWS Resource Access Manager 新しいAWS Resource Access Manager (RAM) は、AWS アカウント間でのリソース共有を容易にします。AWS 組織内でリソースを簡単に共有でき、コンソール、CLI、一連の API から使用できます。Route 53 Resolver ルールのサポートを開始 (昨日、Shaunの素晴らしい記事で発表) し、近いうちにさらに多くの種類のリソースを追加します。 リソースを共有するには、単にリソース共有を作成し、名前を付け、リソースを 1 つ以上追加し、他の AWS アカウントへのアクセス権を付与するだけです。それぞれのリソース共有はショッピングカートに似ており、異なる種類のリソースを保持できます。自分が所有しているリソースはすべて共有できますが、共有されているリソースを再共有することはできません。リソースは、組織、組織単位 (OU)、AWS アカウントで共有することができます。また、組織外のアカウントを特定のリソース共有に追加できるかどうかをコントロールすることもできます。 組織のマスターアカウントの共有を、RAM コンソールの [Settings] ページで有効にする必要があります。 その後、組織内の別のアカウントとリソースを共有すると、リソースはどちらの側でもさらなるアクションなしで利用可能になります (RAM は、アカウントが組織に追加されたときに行われたハンドシェイクを利用します)。組織外のアカウントでリソースを共有すると、そのアカウントでリソースを利用できるようにするために承認する必要がある招待が送信されます。 リソースがアカウント (消費アカウントと呼ぶ) と共有されると、共有リソースは消費アカウントが所有するリソースと共に適切なコンソールページに表示されます。同様に、Describe/List をコールすると、共有リソースと消費アカウントが所有するリソースの両方を返します。 リソース共有にタグを付け、IAM ポリシーでタグを参照してタグベースの権限システムを作成することができます。リソース共有から、いつでもアカウントやリソースを追加したり削除したりすることができます。 AWS Resource Access Manager の使用 RAM コンソールを開き、[Create a resource share] をクリックして開始します。 共有の名前 […]

Read More

近日登場 – コンピューティング能力と GPU を増強した Snowball Edge

お客様のニーズに基づいたイノベーションが実現するのを目の当たりにする経験は、飽きることがありません。 AWS のお客様からペタバイト単位のデータを AWS に出し入れする簡単な方法が必要だという要望をいただいたとき、私たちは AWS Snowball でお応えしました。その後、AWS にデバイスを送信してデータを戻す前に (多くの場合、オフラインで) ローカルデータ処理やフィルタリングを行いたいという要望をお客様からいただいたときは、AWS Lambda 関数を使用してローカル処理を行える AWS Snowball Edge を提供しました。今年の始めには、EC2 コンピューティングインスタンスのサポートを追加し、デバイスごとに最大 10 個の AMI を事前ロードできるサイズと機能を備えた 6 つのインスタンスが利用可能になりました。 素晴らしい進歩ですが、これで終わりではありません! コンピューティング能力と GPU の増強 嬉しいことに、私たちは 2 つの新しい Snowball Edge オプションを提供する準備ができています。それは、Snowball Edge Compute Optimized と Snowball Edge Compute Optimized with GPU です (元の Snowball Edge は、Snowball Edge Storage Optimized という名称になりました)。どちらのオプションにも、42 TB の […]

Read More

新機能 – Machine Learning を中核とする EC2 の予測スケーリング

AWS の歴史を振り返り、クラウド本来の特徴である動的なオンデマンド性を真の意味で象徴するようなサービスとは何であったかを思い起こしてみます。2 つありました。それは、2006 年のAmazon EC2 のスタートと 2009 年の CloudWatch Metrics、Auto Scaling、Elastic Load Balancing の同時スタートです。前者は計算能力へのアクセスをもたらし、後者はその計算能力へのアクセスを需要の変化に対応できるよう高速かしました。それ以来、これらのサービスに多数の機能を追加してきました。私の知る限りでは、今でもその重要性、基本性は変わっていません。 新しい予測スケーリング 本日、Auto Scaling は予測スケーリングの追加によりさらに強化されます。ユーザーが使用する EC2 から収集されたデータおよび弊社独自の観測結果から得られた情報をもとに、十分にトレーニングを重ねた Machine Learning モデルを使用して、予想されるトラフィック量 (および EC2 使用量) を日次パターンと週次パターンで予測します。当該モデルで予測を開始するには、履歴データを最低でも 1 日分必要とします。その予測結果は 24 時間ごとに再評価され、次の 48 時間分を予測します。 このモデルを使いやすくするために、最善を尽くしてきました。クリック 1 回で有効化し、次に、3 ステップのウィザードに従って観測およびスケーリング対象のリソースを選択します。EC2 インスタンスのウォームアップ時間を設定できます。また、実際および予測の使用状況を見やすく視覚化します。 予測プロセスではスケーリングプランが作成され、Auto Scaled EC2 インスタンスのグループを 1 つまたは複数動作させることが可能です。 新しいスケーリングプランが動作を開始すると、日次ベースや週次ベースでピークに達する前に先を見越したスケーリングができるようになります。この結果、ユーザーのウェブサイトやビジネスに関してユーザーエクスペリエンス全体が向上し、オーバープロビジョニングを防止して EC2 コスト削減に役立ちます。 それでは、具体的にご覧いただきます。 動作中の予測スケーリング まず Auto Scaling コンソールを開いて、[今すぐ始める] をクリックします。 観測および予測スケーリング対象のリソースを選択するには、3 […]

Read More

AWS GovCloud (米国東部) が開設されました

昨年、2011 年に開設された既存の AWS GovCloud (米国西部) リージョンの米国東部パートナーとなる AWS GovCloud (米国東部) の開設に取り組んでいることについてお話しました。この度、この新しいリージョンが開設され、連邦政府、州政府、および地方政府の各機関、それらの機関にサービスを提供する IT 請負業者、ならびに規制対象のワークロードをお持ちのお客様のニーズに対応する準備が整いました。このリージョンは、冗長性、データ耐久性、および回復性をさらに高めると共に、災害復旧のための追加オプションも提供します。これは、FedRAMP の High および Moderate ベースラインの対象となる隔離された AWS リージョンで、米国内で米国市民によって運営されています。このリージョンには、審査を受けた米国事業体と root アカウント所有者のみがアクセスでき、root アカウント所有者がアクセス権を得るには、米国人 (市民または永住者) であることを確認する必要があります。詳細については、Achieve FedRAMP High Compliance in the AWS GovCloud (US) Region を参照してください。 AWS GovCloud (米国) は、審査済みの政府のお客様、および規制対象産業のお客様とそのパートナーに対して、FedRAMP High ベースライン、米国司法省の犯罪司法情報サービス部 (CJIS) セキュリティーポリシー、米国武器国際取引規則 (ITAR)、輸出管理規則 (EAR)、米国国防総省 (DoD) のラウドコンピューティングセキュリティ要件ガイド (SRG) インパクトレベル2、4、および 5、FIPS 140-2、IRS-1075、ならびにその他コンプライアンス体制に準拠したセキュアなクラウドソリューションを設計する柔軟性を提供します。 豊富なサービス このリージョンで実行されるアプリケーションは、Auto Scaling (EC2 および Application)、AWS […]

Read More

只今準備中 – イタリア、ミラノの AWS リージョン

先月下旬、私は 南アフリカの AWS リージョンに取り組んでいることをお知らせしました。本日は、イタリアの AWS リージョンを構築中で、2020 年初頭には開設予定であることをお知らせします。 ミラノ、2020 年 予定されている欧州 (ミラノ) リージョンには 3 つのアベイラビリティーゾーンがあり、これで既存のフランス、ドイツ、アイルランド、英国、今年後半に開始される新しいスウェーデンリージョンを合わせて、ヨーロッパで 6 番目のリージョンになります。当社は現在、全世界 19 の地理的リージョンに 57 のアベイラビリティーゾーンがあり、これに加えて現在から 2020 年の前期の間に、5 つのリージョンの 15 のアベイラビリティーゾーンが準備中です (詳細については、AWS グローバルインフラストラクチャ ページを参照ください)。既存のすべてのリージョンと同じく、これは最も厳格なコンプライアンス基準を満たし、AWS のお客様に最高レベルのセキュリティを提供するように設計されています。 イタリアの AWS イタリアの AWS のお客様は、既存のリージョンを 10 年以上使っています。イタリアのホットなスタートアップ、企業、公共部門組織はすべて、AWS クラウドでミッションクリティカルなアプリケーションを実行しています。すでに起こっていることをお知らせするための例を紹介します。 Ferrero は世界最大のチョコレート製造メーカーの 1 つです (私のブログ執筆を力づけるポケットコーヒーも作っています)。同社は 2010 年から AWS を使用しており、80 か国の 250 Web サイト全体で機能を共有できるテンプレート駆動モデルを使用して、トラフィックサージを処理しながらコストを 30% 削減しています。 Mediaset は複数の放送ネットワークとデジタルチャンネル、有料テレビサービス、広告代理店、イタリア映画スタジオ Medusa […]

Read More

新 – CloudFormation ドリフト検出

AWS CloudFormation は、Infrastructure as Code (IaC) を実装する取り組みをサポートします。テンプレートを使うことで、希望する AWS リソース設定を定義し、それを使って CloudFormation スタックを起動することができます。スタックには、指定通りに設定されたテンプレートに定義されている、一連のリソースが含まれています。設定を変更する必要があるときは、このテンプレートを更新し、CloudFormation の変更セットを使って変更を適用します。テンプレートはインフラストラクチャを完全かつ詳細に指定するので、ユーザーは自信をもって、いつでもこれを使って新しいリソースセットを作成できます。 実に理想的といえるでしょう。 現実には、多くの企業でいまだに IaC の完全な実装が行われています。こうした企業は、並行して従業員の研修やプロセスの調整を行っています。いずれも、ある程度の時間が必要です。移行期間中に、テンプレートを更新することなく、AWS リソース (とそのプロパティ) を直接変更して終わることもよくあります。また、帯域外でその場しのぎの修正を行って EC2 インスタンスタイプを変更したり、Auto Scaling パラメータを修正したり、IAM パーミッションを更新したりしている場合もあります。こうしたアンマネージド型の変更は、再起動時に問題を発生させる要因となります。実行中のスタックの設定がテンプレートから乖離してしまい、適切に記述されなくなるためです。深刻なケースでは、変更によってスタックの更新や削除が妨害される場合もあります。 新しいドリフト検出 本日、当社は、上記のような状況に対応するために設計された、強力な、新しいドリフト検出機能を発表します。テンプレートからスタックを作成した後に、コンソール、CLI、またはユーザー自身のコードからのドリフトを検出できます。スタック全体、または特定のリソースでドリフトを検出し、結果を数分以内に確認することが可能です。その後、テンプレートの更新に必要な情報や、リソースをコンプライアンスに準拠した適切な状態に戻すための情報が提供されます。 ドリフト検出のチェックを開始すると、CloudFormation が、現在のスタック設定と、スタックを作成または更新するために使用された、テンプレートが指定する設定とを比較し、誤差があれば報告し、それぞれの詳細な情報を提供します。 当社は、核となる一連のサービス、リソース、プロパティへのサポートを開始します。サポートは今後さらに追加される予定です。初回のリソースリストには、API ゲートウェイ、Auto Scaling、CloudTrail、CloudWatch Events、CloudWatch Logs、DynamoDB、Amazon EC2、Elastic Load Balancing、IAM、AWS IoT、Lambda、Amazon RDS、Route 53、Amazon S3、Amazon SNS、Amazon SQS その他が含まれています。 ドリフト検出は、CREATE_COMPLETE、UPDATE_COMPLETE、UPDATE_ROLLBACK_COMPLETE、UPDATE_ROLLBACK_FAILED の状態にあるスタックに実行できます。ドリフト検出は、チェックしたスタックにネストされている他のスタックには適用されません。これらのチェックはユーザーが自ら行います。 実行中のドリフト検出 Provisioned Throughput for Amazon EFS の記事を書いたときに使用した単純なタスクで、この機能を実際に使ってみました。スタックを選んで [Action] メニューから [Detect […]

Read More