Amazon Web Services ブログ

大規模な Amazon DynamoDB テーブルに適切なシャード数の選択

一般的な設計のベストプラクティスとして、アプリケーションをテーブル内のすべての論理パーティションキーとインデックス全体での均一な読み込みと書き込みアクティビティのために設計することによって、Amazon DynamoDB のスループットキャパシティーを最大限に活用することができます。このような設計により、テーブルのキャパシティーを過剰に消費する可能性があるホットパーティションの発生を防ぐことができます。 書き込みアクセスをパーティション全体に均等に分散させる 1 つの方法は、パーティションキースペースを拡大させることです。この戦略は、パーティションキーに追加のサフィックスを付加して、基盤となるパーティション全体での配分を向上させるもので、書き込みシャーディングと呼ばれます。 しかし、このアプローチは、いくつかの興味深い設計面での疑問を生じます。いつシャーディングを検討すればよいのか? パーティションキーごとに何個のシャードを作成するべきなのか? シャードをいつ作成するのか? シャード数をスケールするにはどうすればよいのか? シャーディングは読み込みおよび書き込みパターンにどのように影響するのか? この記事では、複合プライマリキー (パーティションキーとソートキー) が存在する DynamoDB テーブルのための動的な書き込みシャーディングのメカニズムを説明します。このメカニズムは、書き込みスループットの需要の増加に基づいてパーティションキーに新しいシャードを臨機応変に追加することによって、DynamoDB テーブルの書き込みキャパシティーを最適化できるようにしてくれます。 パーティション、キー、および書き込みシャーディング DynamoDB は水平分散されたワークロードで能力を発揮します。DynamoDB はテーブルを作成するときに、プロビジョンドスループット要件に対応するために十分なパーティションをテーブルに割り当てます。作成時、DynamoDB はテーブルのキャパシティーを基盤となるパーティション全体に均等に分散します。DynamoDB は、テーブルが作成された後で追加のパーティションをテーブルに割り当てることもあります。詳細については、「パーティションキーを効率的に設計し、使用するためのベストプラクティス」と「パーティションとデータ分散」を参照してください。 DynamoDB は、パーティションに項目を分散するために一貫した内部ハッシュ関数を使用し、DynamoDB が項目を保存するパーティションは項目のパーティションキーによって決定されます。同一のパーティションキーを共有する項目のグループ (コレクションと呼ばれます) は、コレクションがパーティションのストレージ容量を超える場合を除き、同じパーティションにマップされます。 さらに、単一のパーティションが複数のコレクションに関連付けられた項目を保持する場合があります。同じパーティションにマップされた 1 つ、または複数のコレクションに対する過剰な書き込みアクティビティは、ホットパーティションの原因になります。ホットパーティションとは、集中的な読み込みおよび書き込みアクティビティが、パーティションのプロビジョンドキャパシティー、またはパーティションの最大キャパシティーを超え、キャパシティーエラーを生じる場合のことです。 これらのキャパシティーエラーは、プロビジョンドキャパシティーモデルにおける ProvisionedThroughputExceededException、およびオンデマンドキャパシティーモデルにおける InternalServerError によって識別されます。同じコレクションの項目が同じ基盤となるパーティションにマップされるため、これらのキャパシティーエラーは大規模なコレクションで発生する可能性が高くなります。詳細については、「エラー処理」および「読み込み/書き込みキャパシティーモード」を参照してください。 書き込みシャーディングとは、コレクションを効率的に DynamoDB テーブルのパーティション全体に分散させるメカニズムです。これは、パーティションキーに対する書き込み操作を複数のパーティションに分散させることによって、パーティションキーあたりの書き込みスループットを向上させます。このため、個々のパーティションキーの書き込みスループットが基盤となるパーティションのキャパシティーを超過してもよくなり、DynamoDB のパーティションレベルでのキャパシティーエラーが最小限に抑えられます。 さらに、書き込み操作を DynamoDB のパーティション全体に分散させることによって、パーティションのキャパシティーがより均等に使用されます。これはテーブルのキャパシティーのより効率的な使用につながり、コストが削減されます。 書き込みシャーディングは、パーティションキーにシンプルな値のサフィックスを付加することによって、クライアント側から実装することができます。サフィックスの付加による書き込みシャーディングは、パーティションキーに対する 1 バイトの変更でさえも内部ハッシュ関数での異なる出力の生成につながり、項目を異なるパーティションに置くために効率的です。詳細については、「書き込みシャーディングを使用してワークロードを均等に分散させる」を参照してください。 DynamoDB は、一時的な需要のバーストを緩和するバーストキャパシティー、および不均等なアクセスパターンに合わせてパーティション間のキャパシティーを再利用するアダプティブキャパシティーの機能をネイティブに提供します。書き込みシャーディングは、DynamoDB のパーティション全体にトラフィックを均等に分散させるための補完的なメカニズムです。 事前に設定された数のシャードを使った書き込みシャーディングの例 シャーディングすると良いテーブルの例は、ファイルシステムの監査ログです。ここでのパーティションキーはファイルパス、ソートキーはアクセスタイムスタンプになります。このファイルの人気が極度に上がり、頻繁に共有されるようになった場合、単一の DynamoDB パーティションが過剰な数の書き込みリクエストを受けます。 以下の表は、3 つの異なるシャーディングスキームに出現する同一の項目を示しています。 最初のメソッドでは、データが […]

Read More

AWS Step Functions と AWS Systems Manager を使用して、Amazon EBS ボリュームのサイズ変更を自動化する

アクティブなアプリケーションで、Amazon EC2 インスタンスの Amazon EBS ボリューム使用率がプロビジョニング済み容量に達してしまうことがあります。どのアプリケーションを使用しているかによって異なりますが、プロビジョニング済み容量が使い果たされると、アプリケーション停止のリスクが生じ、お客様に影響を与えることがあります。これに対するソリューションの 1 つに、アプリケーションへのフェールオーバーメカニズムの設計がありますが、オーケストレーションの負担になる可能性があります。より簡単なソリューションは、EBS ボリュームのサイズを自動的に変更することです。 Infor では、本番環境での数千に及ぶ EC2 インスタンス (Windows と Linux) を管理しています。当社はこうした停止を防ぐ予防的アプローチが必要であったため、特定のしきい値に達したときボリュームが自動的に増加するように、本投稿で説明するソリューションを開発しました。このアプローチには 2 つの利点があります。 異常が発生し、ボリュームのスペースが非常に少なくなると、プロビジョニング済み容量が枯渇する前に自動的にボリュームを拡張します。このアクションにより、根本原因を調査し解決するまで、問題に対処できます。 そのため、ボリュームを過剰にプロビジョニングする必要がなくなりました。このソリューションは、より多くのスペースが必要になると、徐々に自動的にボリューム容量を増やし、EBS コストを削減します。 この投稿では、Infor で開発した自動 EBS ボリュームサイズ変更プロセスを順を追って説明します。さらに、そのアーキテクチャを確認し、ベストプラクティスをいくつか学びます。 概要 AWS は Amazon EBS Elastic Volumes を 2017 年に発表しました。この機能では、ダウンタイムなしでシンプルな API 呼び出しで、ボリュームのサイズを増やしたり、パフォーマンスを調整したり、ボリュームタイプをその場で変更したりできます。 ボリュームの変更は比較的簡単ですが、ファイルシステムを拡張して、追加のストレージを活用しようとすると一筋縄ではいきません。これは通常、OS 上で手動で行いますが、AWS Systems Manager がインスタンスを管理している場合には、AWS Lambda を使用して OS レベルのスクリプトを実行する Systems Manager コマンドを送信できます。 次のリストは、このワークフローの手順を示しています。 ボリュームが 80% に達することをモニタリングし、自動化をトリガーします。 特定のシステムが除外されたため、続行する前に一連のチェックを実行します。フリートの […]

Read More

Amazon Aurora PostgreSQL から通知を送信する

企業のお客様は、Amazon Aurora PostgreSQL データベースで多くの日々のバッチジョブを実行し、そのようなジョブを完了した後にアクティビティを追跡するためにメールやテキストなどの通知方法が必要です。Aurora PostgreSQL はマネージドサービスであるため、セキュリティ上の理由から pgsmtp や pgplpythonu などのデータベース拡張機能へのアクセスを制限しています。これにより、他の自動メッセージングの手段で通知を送信するデータベースの必要性が高まります。 この記事では、組織が定期的にビジネス検証のために従業員の情報をプルし、ジョブの完了後に通知を必要とするシナリオを使用します。この記事では、Python を使用してサンプルジョブを作成し、AWS Lambda と Amazon SNS を使用して、E メールまたはテキストメッセージで通知する方法を示します。 前提条件 このソリューションには以下が必要です。 適切な AWS のサービスにアクセスできる有効な AWS アカウント。 Aurora PostgreSQL データベース。詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。 VPC の外部に通知を送信するための、SNS の VPC エンドポイント。詳細については、「Amazon SNS の Amazon VPC エンドポイントの作成」を参照してください。 データベースに接続するための pgadmin または PSQL Client ツールなどのクライアントツール。 AWS Secret Manager にすでに設定および保存されているデータベースパスワード。詳細については、「AWS Secrets Manager とは」を参照してください ソリューションアーキテクチャ […]

Read More

AWS Firewall Manager の最新情報 – VPC Security Groups のサポート

私は皆さまに、昨年、AWS Firewall Manager をご紹介し、それをAWS WAF ルールと AWS Shield の高度な保護を一元的に設定し、管理するために使用する方法を示しました。AWS Firewall Manager は AWS Organizations を利用して、一貫した方法で、複数の AWS アカウントにわたってポリシーを構築し、適用できるようにします。 セキュリティグループのサポート 現在は、AWS Firewall Manager をさらにより便利にして、VPC Security Groups の利用のための組織全体のポリシーを定義、管理、監査するための機能を与えます。 このポリシーを使用して、指定されたアカウントとリソースにセキュリティグループを適用し、セキュリティグループで使用されるルールを確認して管理し、その後、未使用で冗長なセキュリティグループを見つけてクリーンアップできます。誤って設定されたルールが検出されるときにリアルタイムの通知を受けて、Firewall Manager コンソールの中で是正措置を講じることができます。 この機能を利用するために、AWS Organization をもつ必要があり、AWS Config がそのすべてのアカウントに対して有効化されていなければりません。AWS アカウントをファイアウォール管理者としても指定しなければなりません。このアカウントには、AWS WAF ルール、シールドアドバンスト保護、セキュリティグループルールを所属する組織全体にデプロイする許可があります。 ポリシーの作成と使用 組織のルートアカウントにログインした後で、Firewall Manager コンソールを開いて、[Go to AWS Firewall Manager] をクリックします。 次に、[AWS FMS] セクションの [Security Policies] をクリックして開始します。コンソールは既存のポリシー (該当する場合) を表示し、[Create policy] をクリックして先に進みます。 […]

Read More

Amazon SageMaker Ground Truth を使用してデータラベルを検証および調整し、より高品質のトレーニングデータセットを作成する

機械学習 (ML) アルゴリズムのための非常に正確なトレーニングデータセットを構築することは、反復プロセスです。ラベルがグラウンドトゥルース、または実世界で直接観察できるものを正確に表していることに満足するまで、ラベルを確認し、継続的に調整することが一般的です。ML モデルの品質には正確にラベル付けされたデータが重要であるため、ML の実務者は、データラベルを確認および更新するためのカスタムシステムを構築することがよくありました。ラベルに問題がある場合、ML モデルはグラウンドトゥルースを効果的に学習できず、不正確な予測につながります。 ML の実務者がラベル付きデータの精度を改善した 1 つの方法は、監査ワークフローを使用することです。監査ワークフローにより、レビューアーのグループはラベルの正確性を検証 (ラベル検証と呼ばれるプロセス) したり、必要に応じて調整 (ラベル調整と呼ばれるプロセス) したりすることができます。 Amazon SageMaker Ground Truth は、ラベル検証用の組み込みワークフローと、バウンディングボックスとセマンティックセグメンテーション用のラベル調整機能を備えるようになりました。この新しいワークフローを使用して、既存の Amazon SageMaker Ground Truth ラベル付けジョブを検証または調整ジョブにチェーンするか、既存のラベルを検証または調整ジョブにインポートできます。 この記事では、バウンディングボックスラベルの両方のオプションについて説明します。このチュートリアルでは、ラベル付けジョブの実行に慣れているか、既存のラベルがあることを前提としています。詳細については、「Amazon SageMarker Ground Truth – 高い精度のデータセットを構築し、ラベル付けのコストを最大 70% 削減」を参照してください。 完了した Amazon SageMaker Ground Truth ラベル付けジョブのチェーン 完了したラベル付けジョブをチェーンするには、次の手順を実行します。 Amazon SageMaker Ground Truth コンソール から、[ラベル付けジョブ] を選択します。 目的のジョブを選択します。 [アクション] ドロップダウンメニューから、[チェーン] を選択します。 次のスクリーンショットは、[ラベル付けジョブ] ページを示しています。 詳細については、「ラベル付けジョブのチェーン」を参照してください。 [ジョブの概要] ページには、チェーンされたジョブに使用した設定が表示されます。変更がない場合は、次のセクション […]

Read More

Amazon Textract が HIPAA 適格に

今日、アマゾン ウェブ サービス (AWS) は、スキャンされたドキュメントからテキストとデータを迅速かつ簡単に抽出する機械学習サービスである Amazon Textract が、HIPAA 認定を必要とするヘルスケアワークロードに対応するようになったことを発表しました。このリリースは、よりよい医療成果の提供を支援する Amazon Translate、Amazon Comprehend、Amazon Transcribe、Amazon Polly、Amazon SageMaker と Amazon Rekognition を含む、HIPAA 適格の既存の AWS 人工知能サービスのポートフォリオに基づいています。 医療提供者は、手動のデータ入力または単純な光学文字認識 (OCR) ソフトウェアを介して、医療記録やフォームなどの文書から日常的にテキストとデータを抽出しています。これは時間のかかる不正確なプロセスで、他のアプリケーションで使用する前に広範な後処理を必要とする出力を産み出します。組織が望んでいるのはむしろ、あらゆる形式のドキュメントのフォームとテーブル、およびさまざまなファイルタイプとテンプレートからテキストとデータを正確に識別して抽出する機能です。 Amazon Textract は事実上あらゆるタイプのドキュメントを分析し、非常に正確なテキスト、フォーム、およびテーブルデータを自動的に生成します。Amazon Textract は、保険請求の患者情報やスキャンしたカルテのテーブルの値など、文書のテーブルやフォームからテキストとデータを識別し、カスタマイズまたは人間の介入の必要なしに医療や保険に固有のものを含むさまざまな文書形式を認識します。Amazon Textract を使用すると、数百万のドキュメントページを数時間で正確に処理することが容易になり、ドキュメント処理コストが大幅に削減され、後処理に時間と労力を費やすことなく、テキストとデータからビジネス価値を引き出すことに集中できるようになります。結果は、機械学習の経験を必要とせずに簡単にアクセスして使用できる API を介して配信されます。 今日から、Amazon Textract は HIPAA 適格のサービスになりました。つまり、医療関係のお客様はそれを最大限に活用できます。Cerner、Fred Hutchinson Cancer Research Center、The American Heart Association などの多くの医療関係のお客様は、ML の力を利用して現在のワークロードを自動化し、HIPAA で求められるセキュリティとプライバシーの要件を満たしながら、患者へのケア方法を変革する新しい方法を既に模索しています。 Change Healthcare は、米国の医療システムにおける臨床、財務、および患者エンゲージメントの結果を改善するためのデータおよび分析主導型ソリューションを提供する大手独立系医療テクノロジー企業です。「Change Healthcare では、財務および管理上の意思決定の適時性と品質を改善することで、すべての人が手頃な価格で利用できる医療を提供できると考えています。  これは、データからより多くを理解する機械学習技術の力によって実現できます。しかし、この情報の可能性を解き放つことは、従来の光学式文字認識では分析できなかったテーブルやフォームにデータがサイロ化されているため、困難なことがよくあります」、と […]

Read More

Amazon RDS で詳細なバックアップストレージ請求をサポート開始

 最近、AWS は、Amazon RDS の詳細なバックアップストレージ請求機能を一般提供することを発表しました。この機能は、PostgreSQL、MySQL、MariaDB、Oracle、および SQL Server データベースのエンジンに適用されます。この機能がリリースされる前の Amazon RDS バックアップ料金は、毎月の請求書のリージョンごとに単一行の項目として提示されていました。ただし、毎日の自動データベースバックアップと手動 DB スナップショットの両方による Amazon RDS バックアップ請求料金の内訳は理解が困難でした。今後は、AWS Cost Explorer および Cost and Usage Report (CUR) で、コストアロケーションタグに基づいて Amazon RDS バックアップストレージの請求を表示できます。 このブログ投稿では、Amazon RDS データベースインスタンスにタグ値を設定し、コストアロケーションダッシュボードでこれらのタグをアクティブにし、AWS Cost Explorer と CUR で詳細なバックアップストレージ請求コストを表示する方法を示します。 設定 AWS マネジメントコンソールにログインしたら、Amazon RDS バックアップストレージ請求を表示するように設定するために、簡単なステップがいくつか必要です。DB インスタンスに既にタグが付いている場合は、RDS コンソールから、または AWS Cost Explorer から直接開始できます。 ステップ 1: Amazon RDS コンソール、AWS CLI、または API を介して […]

Read More

物理テープベースのバックアップをテープゲートウェイで簡単に置き換える方法

 AWS には毎月数百万人のアクティブなお客様がおり[1]、クラウド導入のジャーニーのどこにいてもお客様のニーズを満たす幅広いクラウドコンピューティングサービスを提供しています。お客様向けのハイブリッドクラウドストレージソリューションを構築する AWS Storage Gateway サービスチームのメンバーとして、私は、複数年にわたるクラウドへの移行のジャーニーにあり、ストレージのニーズに対するクラウドの使用を評価している多くのお客様と話す機会があります。私が見る一般的なパターンは、企業顧客のクラウドへのジャーニーは、多くの場合、バックアップやアーカイブなどの二次的なワークロードの移動から始まります。これにより、お客様のクラウドチャンピオンは、組織内でクラウドストレージを使用することで即時に得られるビジネス価値を実証できます。バックアップにクラウドストレージを使用する運用上の知識を得ると、お客様は追加のワークロードをクラウドに持ち込み、すべてのビジネスニーズに対して AWS を活用するという最終目標に向けて前進することに安心感を持ちます。 クラウドジャーニーを開始するお客様にとって、内部で迅速な勝利を示すことはしばしば重要です。AWS のお客様の言葉を借りれば、通常、クラウドへの「小さな一歩」を踏み出すことになります。小さな一歩を踏み出すことは、組織の構造、文化、内部プロセスに関することであり、同時に技術の変化に関することでもあります。緩やかなジャーニーとは、クラウドストレージサービスを使用することで経済的価値を引き出しながら、ビジネスプロセスの基礎を維持するか、少しづつ変更することを意味します。 AWS Storage Gateway とは ここで、AWS Storage Gateway などの AWS のサービスが登場します。Storage Gateway は、オンプレミスで実質的に無制限のクラウドストレージにアクセスできるようにするハイブリッドなクラウドストレージサービスです。Storage Gateway は、ファイルゲートウェイ、テープゲートウェイ、ボリュームゲートウェイモードを介して NFS、SMB、iSCSI などのストレージプロトコルを提供し、従来のオンプレミスアプリケーションでクラウドストレージをシームレスに使用できるようにします。お客様は、オンプレミスのアプリケーションを AWS にバックアップするためにすべてのゲートウェイタイプを使用できますが、多くの場合、テープゲートウェイの使用が最も重要です。なぜでしょうか? テープゲートウェイは、バックアップとアーカイブに使用されるお客様の物理的なテープインフラストラクチャの簡単で気軽に使える代替となります。お客様は、物理テープにデータを保存する代わりに、オンプレミスのデータを仮想テープとして AWS にバックアップできます。そして、現在のバックアップワークフローやバックアップアプリケーションを変更することなくバックアップできます。テープゲートウェイは、ほとんどの主要なバックアップアプリケーションをサポートし、クラウドで最も低コストのストレージである Amazon S3 Glacier Deep Archive と統合されているため、物理テープから AWS へのワークロードのバックアップとアーカイブの移行は簡単かつ費用対効果に優れています。 お客様は、テープゲートウェイを使用してクラウドジャーニーをどのように開始できるでしょうか? このブログ記事では、テープゲートウェイを使用する利点と、テープゲートウェイをデプロイして使用するためにお客様が実行できる手順を確認します。 テープゲートウェイを使用する利点と物理テープインフラストラクチャを使用する利点 では、物理テープインフラストラクチャを使用する場合と比較して、テープゲートウェイを使用する利点は何でしょうか? 最初に、物理テープ装置の管理のコストと複雑さを取り除きます。テープゲートウェイを使用すると、テープライブラリ、テープメディア、クリーニングテープカートリッジを購入したり、それらを管理するためのリソースをデプロイしたりする必要がありません。 第二に、物理テープは長期保管のために特定の環境条件を必要とし、注意深い取り扱いが必要です。劣化または破損した物理テープからデータを復元することは、不可能ではないにしても困難です。テープが破損していない場合でも、データの劣化やその他の問題のためにテープを読み取れない可能性があります。テープを読み取るには、パンオーブンを購入してテープを焼く必要があります! これを経験したAWSのお客様から直接聞いてください。 第三に、古い物理テープから新しい世代のメディアへの高価な移行を管理する必要はありません。物理メディアの寿命は長いですが、特により良い代替手段の出現により、あるテープから別の手段にデータを移行するのと同じように、タスクの背後にある時間、労力、費用を無駄にしたくはありません。 テープゲートウェイを使用する利点とテープをオフサイトで保存する利点 テープゲートウェイを使用して AWS に仮想テープを保存することには、テープをオフサイトで保存することに比べていくつかの利点があります。 まず、Amazon S3、Amazon S3 […]

Read More

Amazon Lex セッション API チェックポイントを使った複数トピックの会話フローの管理

 日常会話では、複数のトピックの間で行き来することがよくあります。たとえば、家の新しい窓とカーテンの改装について話し合うとき、「カーテンのスタイルはこれで決めて、色について考え直してみない?」というような質問が出てくることがあります。 AWS が Amazon Lex セッション API を開始するときに、 会話が脱線する場合の対応方法を学びました。セッション API アクションを使用して、インテントを切り替え、会話を継続することができます。しかし、毎日の対話で、「では窓の選択を終えてからカーテンについて考えましょう」というような複数の脱線に対応することが必要になる場合があります。 一連の脱線を含む会話フローをどのように設計したらよいでしょうか。 あなたが私のようである場合は、家の改装プロジェクトにおける特定の製品を考える前にでも、複数の質問がある場合があります。 セッションのチェックポイントで、あなたは多くのトピックのうちの 1 つに切り替えるサポートをするために容易に会話を設定できます。家の改装の会話を 2 つのインテント、すなわち OrderWindows と OrderCurtains、としてモデル化することができます。 今ではこのトピックの切り替えが容易にできるようになりました。OrderWindows のフローには、チェックポイントがあることがあります。ユーザーがカーテンを注文したが、窓の選択を最初に完了したい場合、「windowSelection」チェックポイントを使用して会話を OrderWindows に戻すことができました。 セッションチェックポイントの管理 Amazon Lex ランタイム API は、会話のセッションチェックポイントを管理できるようにするオペレーションを提供しています。PutSession および GetSession 呼び出しは、チェックポイントを定義して、取得できるようにします。 ここでは、API を使用して以前、説明した会話フローを管理できる方法を示します。ボットの詳細については、ボットスキーマを見直してください。 会話フローを管理するためには、次のステップに従ってください。 会話の現在の状態を保存します 以前に保存した状態を取得し、会話を継続します 会話の現在の状態を保存します フィルターなしで GetSession API を呼び出し、ボットとユーザーの間の会話の現在の状態を取得します。GetSession API 呼び出しの後に PutSession API 呼び出しが続き、チェックポイント「windowSelection」 を OrderWindows インテントに適用します。PutSession 呼び出しは、以下のコード例で示されています。 PutSession Request: 「OrderWindows」インテントで「windowSelection」チェックポイントを適用します […]

Read More

今すぐ利用可能: ベアメタル Arm ベースの EC2 インスタンス

 AWS re:Invent 2018 では、Arm ベースの AWS Graviton プロセッサを搭載した、Amazon Elastic Compute Cloud (EC2) インスタンスの新しいライン、A1 ファミリーを発表しました。このファミリーは、ウェブフロントエンド、コンテナ化されたマイクロサービス、キャッシングフリートなどのスケールアウトワークロードに最適です。コンピューティングオプションの選択肢を拡大することにより、A1 インスタンスは、お客様が適切なアプリケーションに適切なインスタンスを使用するのを支援し、最大 45% のコスト削減を実現します。さらに、A1 インスタンスにより、Arm 開発者はクラウド内の Arm ベースのインフラストラクチャ上でネイティブにビルドおよびテストできます。クロスコンパイルやエミュレーションはもはや不要です。 今日、ベアメタルオプションで A1 ファミリーを拡大します。 A1 のベアメタル インスタンス名 論理プロセッサ メモリ EBS最適化帯域幅 ネットワーク帯域幅 a1.metal 16 32 GiB 3.5 Gbps 10Gbpsまで 既存のベアメタルのインスタンス (M5、M5d、R5、R5d、z1d など) と同様に、お使いのオペレーティングシステムは、プロセッサに直接アクセスする既存のハードウェアで直接実行されます。 以前のブログ投稿で説明されているとおり、次のようなアプリケーションにベアメタルのインスタンスを利用することができます。 物理的なリソースと低レベルなハードウェア機能にアクセスが必要。仮想化された環境で使用可能または完全なサポートを常に必要としないパフォーマンスカウンターなど、 ハードウェアで直接実行されることを目的とするか、仮想化されていない環境で使用するためにライセンスまたはサポートされている ベアメタルインスタンスでは、Elastic Load Balancing、Auto Scaling、Amazon CloudWatch、および AWS のその他サービスを利用することもできます。 A1 インスタンスの使用 […]

Read More