Category: Amazon EC2

EC2 スポットフリートモデル（詳しくは「Amazon EC2 スポットフリート API – 1 回のリクエストで数千台のスポットインスタンスを制御」をご覧ください）では、1 回のリクエストで EC2 インスタンスのフリートを作成できます。お客様はフリートのターゲットキャパシティーを指定し、1 時間あたりの入札価格を入力して、フリートに含めるインスタンスタイプを選択するだけです。 バックグランドで、AWS は最安値のスポットインスタンスを起動することにより、必要なターゲットキャパシティー（インスタンスまたは仮想 vCPU の数で表記）を維持します。やがて、フリート内のインスタンスが価格上昇により終了されると、その時点で最安値の交換用のインスタンスが起動されます。 新しい Auto Scaling 今回、Auto Scaling の追加により、スポットフリートモデルが強化されました。 メトリックスに基づいて、フリートをスケールアップ/ダウンできるようになりました。メトリックスには、EC2、、 などの AWS サービスのものを使用できます。代わりに、アプリケーションからパブリッシュしたカスタムメトリックスを使用して、Auto Scaling が開始されるようにもできます。いずれにせよ、これらのメトリックスを使用してフリートのサイズを制御することで、条件や負荷が変わったとしてもアプリケーションの可用性、パフォーマンス、コストをきめ細かく制御できます。以下に示しているのは、この機能の使用開始に必要ないくつかの概念です。 コンテナ – CPU やメモリの使用率メトリックスを使用して、 で動作しているコンテナベースのアプリケーションをスケーリングします。 バッチジョブ – SQS キュー内のメッセージ数に基づいて、キューベースのバッチジョブをスケーリングします。 スポットフリート – スポットフリートメトリックス（ MaxPercentCapacityAllocation など）に基づいて、フリートをスケーリングします。 ウェブサービス – 測定された応答時間と 1 秒あたりの平均リクエスト数に基づいて、ウェブサービスをスケーリングします。 スポットフリートコンソール、、または を使用するか、 のいずれかにより API 呼び出しを行うことで、Auto Scaling を設定できます。 私はフリートの起動から始めました。フリートをスケールアップ/ダウンできるようにするために、リクエストタイプとして […]

SAP HANAの大規模ワークロードにおける新しい利用方法をお伝えするために、私の同僚のSteven Jonesが寄稿してくれました。 — Jeff; AWSクラウド上でSAP HANAのような大規模なインメモリデータベースやインメモリアプリケーションを稼働させるため、Amazon EC2 メモリ最適化インスタンスファミリーに新しいX1インスタンスタイプとして、2TBのRAMを搭載したx1.32xlargeの利用開始を5月に発表しました。 X1インスタンスのシングルノード構成でのSAP HANAにおけるSAP認定取得を同時に発表し、それ以来、SAP S/4HANAとSuite on HANAといったOLTP、またBusiness Warehouse on HANAにBIといったOLAPにおける幅広い用途で、世界中の多くのお客様にご利用いただいています。とはいえ、クラスタ化されたX1インスタンスによるスケールアウト構成でのSAP HANAの提供のご要望も多くいただいていました。 SAP認定プロセスに応じたSAP HANAスケールアウト構成の広範囲なテストとベンチマークを終え、本日、高度に最適化された次世代データウェアハウスSAP BW/4HANAの新発表と同時に、X1インスタンスの最大7ノード、つまり14TBのRAMに対応したSAP BW/4HANAを含むOLAPシナリオの大規模スケールアウト構成におけるSAP認定取得を発表できることを嬉しく思います。 拡張性、柔軟性、コスト効果の高いSAP社の新しいフラッグシップのデータウェアハウスであるSAP BW/4HANAのローンチを私たちがサポートできることに非常に興奮しています。 以下は7台のX1インスタンスで稼働する大規模(14TBメモリ)なスケールアウト構成を表示したSAP HANA Studioのスクリーンショットです： そして、これはほんの始まりに過ぎません。私たちは他のサイズでのX1インスタンスを利用可能にする計画があり、より大きな50TBメモリまでのクラスタ構成を研究室でテストしています。もし、14TBメモリを超える大規模なスケールアウト構成が必要な場合は、ご支援しますので、ぜひご相談ください。 コストと複雑性の削減 多くのお客様が複数のR3インスタンスによるスケールアウト構成でSAP HANAを稼働してきました。今回の新しい認定により、コストと複雑性の両方が削減できる、より少ないインスタンス数での大規模スケールアウト構成に統合できる可能性があります。統合戦略における詳細はSAP HANA Migration Guideをご参照ください。 柔軟性のある高可用性オプション AWSプラットフォームでは、可用性が求められるSAP S/4HANAやSAP BW/4HANAのような環境で使われる重要なSAP HANAを保護するために、お客様のご要望に応じた様々なオプションを提供しています。実際に、従来型のホスティングプロバイダーやオンプレミスのスケールアウト構成でSAP HANAを稼働しているお客様からは、ハードウェア障害に迅速に対応できるように予備のハードウェアやスタンバイノードを購入し非常に高額なメンテナンス契約料を支払わなければならない、とよくお伺いします。他には、残念ながら、何も起こりませんようにと祈って、この余分なハードウェアをなしで済ませようとされています。 AWSプラットフォーム上で活用されている便利なオプションの一つは、Amazon EC2 Auto Recoveryと呼ばれるソリューションです。AWSに起因するハードウェア障害や問題が発生したときに自動的に正常なホスト上で復旧するよう、EC2インスタンスを監視するAmazon CloudWatch アラームを簡単に作成できます。復旧されたインスタンスは、アタッチされたEBSボリュームやホスト名、IPアドレス、AWSインスタンスIDなどの構成情報も元のインスタンスと同じものです。Amazon CloudWatchの標準料金(例えば、米国東部では月当たりアラームごとに0.10ドル)が適用されます。実質、ハードウェア異常への迅速な復旧のために、私たちの持つ空いているキャパシティをすべてお客様の予備機として活用することが可能です。 開始方法 最新のAWS Quick Start Reference Deployment for SAP HANAを使うことで、十分にテストされたX1インスタンスでのシングルノード構成、およびスケールアウト構成のSAP […]

AWS が昨年末に EC2 Run Command を立ち上げてから、クラウドやオンプレミス環境で同機能をご利用されているお客様の様子を目にすることができ大変喜ばしく思っています。本機能のリリース直後には Linux インスタンスのサポート、コマンドの管理と共有をよりパワフルに、そしてハイブリッドとクロスクラウド管理を追加しました。そして本日より、中国（北京） と アジアパシフィック (ソウル) リージョンで EC2 Run Command をご利用いただけるようになりました。AWS のお客様は、定期的に行うシステム管理タスクを自動化したりカプセル化するために EC2 Run Command を使用しています。ローカルユーザーやグループの作成、該当の Windows アップデートの検索とインストール、サービス管理やログファイルのチェックなどを行っています。こうしたお客様は EC2 Run Command を基本的な構成要素として使用しているため、実際に実行するコマンドの進行状況をより把握しやすいように可視性の改善を求めています。また、各コマンドや各コードブロック実行の開始時、コマンド実行の完了時、そしてどのように完了したのかといった詳細情報を素早く取得できることを希望されています。このように非常に重要なユースケースに対応するため、コマンド内のコマンドやコードブロックで変更があった場合にステータス状況を通知できるようにしました。さらに、複数の異なる統合オプションを提供するにあたり、CloudWatch Events または SNS を通じて通知を受信できるようにしました。こうした通知により、EC2 Run Command を基本的な構成要素として使用できるようになります。コマンドをプログラムで呼び出し、結果が戻り次第プロセスを進めることができます。例えば、各インスタンスで重要なシステムファイルやメトリックスのコンテンツをキャプチャするコマンドを作成し実行することができます。コマンドが実行すると EC2 Run Command は S3 で出力を保存します。通知ハンドラーは S3 からオブジェクトを取得し、該当アイテムまたは確認が必要なアイテムをスキャンしてから不適切だと思われる点があれば通知を作成します。 Amazon SNS を使用して実行するコマンドをモニタリング EC2 インスタンスでコマンドを実行し SNS を使用して進行状況を監視してみましょう。手順 (モニタリングコマンド) に従い、S3 バケット (jbarr-run-output)、SNS トピック (command-status)、オンインスタンスエージェントが代理で通知を送信できるようにする […]

AWS をご利用されているお客様の多くは、複数の EC2 インスタンスに渡り密結合のシステムを作成し、利用可能なすべてのネットワーク帯域幅を有効に活用されています。本日、AWS はこの非常に一般的なユースケースを対象に、今まで以上に優れたサポートを提供する Elastic Network Adapter (ENA) をリリース致しました。新しい X1 インスタンスタイプを対象とする ENA には追加費用もなく、プレイスメントグループ内で使用した場合、低レイテンシーで安定したパフォーマンスを最大 20 Gbps でご提供します。ENA のメリット ENA は X1 インスタンスで見られる最新のプロセッサと合わせて運用できるように設計されています。こうしたプロセッサは多数の仮想 CPU (X1 の場合は 128) を含むため、ネットワークアダプターなどの共有リソースを効率的に使用することが重要です。高いスループットやパケット毎秒 (PPS) のパフォーマンスを提供しながら、ENA は数々の方法でホストプロセッサのロードを最小限に抑えます。以下の例をご覧ください。 チェックサム生成 – ENA はハードウェアの IPv4 ヘッダーチェックサム生成と TCP / UDP の一部のチェックサム生成を処理します。 マルチキューデバイスインターフェイス – ENA は複数の配信を使用し、キューを受信して内部のオーバーヘッドを削減します。 受信側による実行 – ENA は適切な vCPU が処理するように着信パケットを誘導します。これにより障害を回避しキャッシュの有効性を高めることができます。 こうした機能は可能な限りプロセッサのワークロードを軽くし、ネットワークパケットと生成または処理を行う vCPU 間で短く効率的なパスを作成するために構築されています。ENA の使用 X1 […]

ユーザーがAmazon EC2を使用するために既存のマシンイメージをクラウドに移行するとき、ドライバや起動パラメータ、システム構成、そして進行中のソフトウェアアップデートなどによる問題に出くわすことがあります。これらの問題によってインスタンスにRDP（Windowsの場合）やSSH（Linuxの場合）経由で接続できなくなり問題判別を難しくします。従来のシステムでは、物理コンソールでログメッセージや何が起きているのかを特定して理解するための手がかりが見つかることがあります。 インスタンスの状態をより可視化しやすくするために、インスタンスコンソールのスクリーンショットを生成してキャプチャできる機能を提供します。インスタンスが稼働中またはクラッシュした後にスクリーンショットを生成することができます。 こちらがコンソールからスクリーンショットを生成する方法です（インスタンスはHVM仮想化を使用している必要があります）： そしてこちらがその結果です： Windowsインスタンスでも使用することができます： CLI (aws ec2 get-console-screenshot)またはEC2 API(GetConsoleScreenshot)を使用してスクリーンショットを作成することもできます。 いますぐ利用可能 この機能は本日から米国東部（北バージニア）、米国西部（オレゴン）、米国西部（北カルフォルニア）、ヨーロッパ（アイルランド）、ヨーロッパ（フランクフルト）、アジアパシフィック（東京）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、そして南アメリカ（ブラジル）リージョンで利用可能です。これに関連する追加コストはありません。 — Jeff; 翻訳はSA渡邉（@gentaw0）が担当しました。原文はこちら。  

多くのAWSのお客様はメモリー性能を必要とするビッグデータ、キャッシング、および分析系のワークロードを実行しており、増え続けるメモリー量に対応したEC2インスタンスについてのご要望をいただいていました。 昨年の秋、初めて新しいインスタンスタイプX1についての計画をお伝えしました。今日、このインスタンスタイプのインスタンスサイズx1.32xlargeが利用可能になったことを発表します。このインスタンスの仕様は以下です： プロセッサー： 2.3GHzの4 x Intel™ Xeon E7 8880 v3 (Haswell) – 64コア / 128 vCPUs メモリー： Single Device Data Correction (SDDC+1)を実現した1,952 GiB インスタンスストレージ： 2 x 1,920 GB SSD ネットワーク帯域幅： 10 Gbps 専用のEBS帯域幅： 10 Gbps (デフォルトでEBS最適化、追加料金不要) Xeon E7 プロセッサーはターボ・ブースト2.0(最大3.1GHzまで)、AVX 2.0、AES-NI、そして非常に興味深いTSX-NI命令をサポートしています。AVX 2.0(Advanced Vector Extensions)は、HPCやデータベース、ビデオ処理といったワークロードの性能を向上できます； AES-NIは、AES暗号化を使用するアプリケーション速度を向上します。新しいTSX-NI命令は、トランザクションメモリーと呼ばれる素晴らしい機能をサポートします。この命令は、並列性が高いマルチスレッドアプリケーションにおいて、メモリーアクセスを必要としたときに行われる低レベルのロックとアンロックの数を削減することで、非常に効率的な共有メモリーの使用を可能とします。 X1インスタンスは、米国東部(バージニア北部)、米国西部(オレゴン)、欧州(アイルランド)、欧州(フランクフルト)、アジアパシフィック(東京)、アジアパシフィック(シンガポール)、そしてアジアパシフィック(シドニー)リージョンで準備ができており、利用申請をしていただければできるだけ早く稼働させようと思っています。また、あまり遠くない将来に、X1インスタンスを他のリージョンで、および他のインスタンスサイズを提供する計画があります。 米国東部(バージニア北部)リージョンの場合、3年契約の一部前払いで1時間あたり3.970ドルでご利用いただけます； 詳細な情報はEC2の料金ページをご覧ください。今日時点で、リザーブドインスタンスとDedicated Host Reservationsを購入することができます； スポット価格は短期的なロードマップにあります。 x1.32xlargeが動いているスクリーンショットをいくつか記載します。lscpuで4ソケットにわたり128vCPUsが搭載されていることが表示されています： システム起動時のカーネルがアクセス可能な総メモリーです： topコマンドでは膨大な数のメモリーとプロセスが表示されています： エンタープライズ規模のSAPワークロードに対応可能 X1インスタンスは、本稼働ワークロードにおけるSAP認定を取得しています。SAP […]

EC2 Run CommandはEC2インスタンスを便利にスケーラブルなやり方で管理することを可能にします（より詳細な情報は、わたしのブログ記事、New EC2 Run Command – Remote Instance Management at Scaleを参照してください）。 本日、この機能にいくつかの機能強化があります： ドキュメント管理と共有 – カスタムのコマンドドキュメントを作成してほかのAWSアカウントまたはすべてのAWSユーザーに共有することができます。 事前定義コマンドの追加 – いくつかのあたらしい事前定義コマンドを使用してWindowsインスタンスの管理をシンプルにできます。 オープンソースのエージェント – インスタンス用エージェントのLinux版がGitHubのオープンソース形式で利用可能です。 ドキュメント管理と共有 Run Commandから実行するコマンドドキュメントの管理と共有ができるようになりました。これによって変動性を削減してエラーの元を取り除くことができるため管理プロシージャーに追加の厳格性をもたらします。さらにほかのAWSユーザーによって作成され共有されたコマンドドキュメントを利用することも可能です。 この機能はお客様からいただいたいくつかのシナリオをサポートするよう設計されました。あるお客様はひとつのアカウントでドキュメントを作成して同じ組織のなかにあるほかのアカウントに共有したいと思っていました。ほかのお客様は共通のタスクをパッケージして広いコミュニティに共有したいと思っていました。AWSパートナーは共通のセットアップとオファリングに固有の管理タスクをカプセル化したいと思っていました。 こちらが自分のドキュメント、公開されたドキュメント、そして自分に共有されたドキュメントを参照する方法です：   ドキュメントをクリックして内容を確認することができます： そしてどのようなパラメータがあるのかがわかります： さらに実行する前にドキュメントを調べることができます（とくにドキュメントが共有されたものである場合、これは強く推奨されたベストプラクティスです）： あたらしいコマンドを作成することができます（ビルトインのAWS-RunShellScriptコマンドをシンプルにしたバージョンを使用しています）： 最後に、アップロードしてテストしたドキュメントを共有できます。パブリックまたは特定のAWSアカウントに共有可能です： この機能に関する詳細はCreating Your Own Commandを参照してください。 事前定義コマンドの追加 多くのAWSのお客様はMicrosoft Windowsが稼動しているEC2インスタンスの保守と管理にRun Commandを使用しています。いくつかの共通オペレーションをシンプルに合理化するために設計された4つのあたらしいコマンドを追加しました： AWS-ListWindowsInventory – インスタンス上のインベントリ情報を収集します（オペレーティングシステム、インストールされたアプリケーション、そしてインストールされたアップデート）。結果はS3バケットに保存できます。 AWS-FindWindowsUpdates – 適用されていないWindows Updateをリストします。 AWS-InstallMissingWindowsUpdates – 適用されていないWindows Updateをインストールします。 AWS-InstallSpecificWindowsUpdates – Knowledge […]

AWSチームは料金とパフォーマンスの両面でイノベーションを起こし、その成果をサービスという形でお客様にご提供する方法がないか日夜検討しています。多くの場合、こういった取り組みは経済的な要素と技術的な要素の間のジレンマに直面することになります。 AWSに限らずとも、こういったジレンマは頻繁に目にすることができます。たとえばストレージにおけるHDDとSSDのトレードオフはその良い例でしょう。今日のSSDをHDDと比較すると、SSDには価格あたりのIOPS値や1GBあたりのデータ転送スループット、レイテンシの短さという点で優位性があります。だからといってHDDに優位性が無いかというとそうではなく、記録密度向上のおかげで容量あたりのコストの面では大きな優位性があります。ただし、これは裏を返せばインタフェースのスループットが同じであれば、1GBあたりのスループットが低下するということにつながります。この種のジレンマはよくあることですが、我々はこれをひとつのチャレンジするべき課題であると考え、「コスト効率の高いHDDを利用してビッグデータやログデータ処理といった用途で使える、高いスループットを安定的に発揮するEBSを作ることができないか？」と自問自答してみました。 その結論は『できる』です。 本日、低コストと高スループットという2つの要素を両立させた、2種類の新たなボリュームタイプを発表いたします。これらのEBSボリュームタイプは磁気ディスクを利用しており、EC2インスタンスやAmazon EMRクラスタと組み合わせて利用することが可能です。（料金は発表時点の東京リージョンのものです。他リージョンについてはEBSの料金ページをご参照ください） スループット最適化HDD(st1) – 高スループットを必要とするワークロード(MapReduce、Kafka、ETL処理、ログ処理、データウェアハウスなど）向けのタイプ; 1GBあたり月額0.054ドル コールドHDD (sc1) – 同様のワークロードでアクセス頻度が低いユースケース向け; 1GBあたり月額0.03ドル 既に多くのお客様にご利用頂いている汎用SSD(gp2)と同様に、これらの新規ボリュームタイプにはベースパフォーマンスとバーストパフォーマンス、バーストクレジットの概念があります。SSDベースのボリュームタイプはIOPSでその性能が表現されていましたが、こちらはスループットで表現されます。ベースパフォーマンスのみならず、バーストパフォーマンスもプロビジョンした容量に応じて下記のルールに従って変わっていきます。 スループット最適化HDD (st1) – 1TBあたり250MB/秒で最大500MB/秒まで コールドHDD (sc1) – 1TBあたり80MB/秒で最大250MB/秒まで EBS進化の歴史 AWSのサービス開発は、お客様のフィードバックが重要な要素となっています。新たなサービスや機能は、多くのユースケースに幅広く適用可能で汎用的なソリューションとして登場します。サービスの立ち上げ後、お客様のユースケースや頂戴したフィードバックを元にサービス改善のプランを立案し、開発に着手します。これによって、初期リリースでは汎用的であったサービスが個々のお客様のユースケースに対して最適化が進んだ形でいくつもの新機能が登場することになります。 この良い例が、EC2インスタンスで利用できるストレージの選択肢です。EC2インスタンスが利用できるストレージについてはこれまで数多くの機能拡張が行われていますが、特徴的なものを時系列で挙げてみましょう。 2006 – EC2のサービス開始。（この時点ではインスタンスストレージのみが利用可能でした） 2008 – 磁気ディスクベースのEBS(Elastic Block Store)をリリース 2012 – プロビジョンドIOPSボリュームとEBS最適化インスタンスをリリース 2014 – SSDベースのボリュームである汎用SSDをリリース 2014 – EBSデータボリュームの暗号化機能をリリース 2015 – 大容量で高速なEBSボリュームをリリース 2015 – EBS起動ボリュームの暗号化機能をリリース 2016 – 新たなボリュームタイプ、スループット最適化HDD(st1)とコールドHDD(sc1)をリリース ワークロードの特性 私たちはビッグデータのワークロードで利用する時に最高のコストパフォーマンスを実現するように設計を行いました。ボリュームに備わった性能を最大限発揮するためには、大きなデータブロックに対してシーケンシャルにアクセスを行う必要があります（これはビッグデータ処理においては一般的なものです）。これはベースとなるHDDの性能特性に由来するものです。一般にHDDはシーケンシャルなデータは高速に転送することが可能ですが、（データベースエンジンが要求するような）小さいデータブロックに対するランダムなアクセスには向いておらずスループットが低くなります。こういった用途にはSSDが向いていますので、引き続き汎用SSDやプロビジョンドIOPSをご利用頂くことをお勧めします。 いずれのボリュームタイプにおいても、バーストクレジットの蓄積上限はボリュームサイズと等しい値になります。これは、もしバーストクレジットが上限まで蓄積されていれば、ボリュームの全領域を常時バースト状態でスキャンできるということを意味しています。1MB以下のブロックサイズに対するI/Oリクエストは1MB分のクレジット消費とカウントされることを覚えておいて下さい。シーケンシャルなI/Oリクエストについては可能な限りマージされますので、スループットの向上とバーストクレジットの有効活用が行われます。（バーストクレジットの概念についてはこちらのブログポストを参照してください） […]