Category: Compute

多くの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 Elastic Beanstalkの環境を、指定したメンテナンス時間帯に、自動的に最新のバージョンに更新するよう選択出来るようになりました。Elastic Beanstalkは、サポートされるプラットフォーム（Java, PHP, Ruby, Node.js, Python, .NET, Go, およびDocker)の新しいバージョンを定期的にリリースしています。こちらには、オペレーティングシステム、ウェブおよびアプリケーションサーバ、言語やフレームワーク等の更新も含まれます。以前は、Elastic Beanstalkコンソール、コマンドラインインタフェース（CLI）、またはAPIを使って手動でElastic Beanstalkの環境の更新を開始しなければいけませんでした。本日より、シンプルに1週間ごとにメンテナンス時間帯を選択して、その時間帯で自動的に環境のプラットフォームバージョンを更新させることが出来るようになりました。 管理されたプラットフォームの更新により、アプリケーションを動作させるプラットフォームへパッチ適用したり、更新し続けるようを気を付ける必要はなくなりました。Elastic Beanstalkは、エンドユーザーへの影響は最小限になるように安全な形で更新を行います。この更新はimmutableデプロイメントメカニズムを使用します。こちらにより、Elastic Beanstalkは同様のAmazon EC2インスタンス群を起動して、環境を交換して既存のインスタンスを終了する前に更新をインストールします。もしElastic Beanstalkのヘルスシステムが更新の間に問題を検知した場合には、アプリケーションのエンドユーザーへのインパクトを最小限に保ちつつ、既存のインスタンス群にトラフィックを向け直します。 Elastic Beanstalkは新しいパッチとマイナープラットフォームのバージョンの更新を自動的に実行できます。環境ごとに異なるメンテナンス時間帯をスケジュール可能です。また定期的にスケジュールが組まれたメンテナンス時間帯以外でアップデートを開始させることも可能です。Elastic Beanstalkは、(例：Java 7 Tomcat 7 からJava 8 Tomcat 8への）メジャーバージョンアップデートを自動的に実行しません。その理由は、メジャーバージョンののアップデートには非互換の変更や追加のテストが必要な場合があるためです。こちらの場合は、手動でアップデートを開始する必要があります。 利用開始するには、Elastic Beanstalkコンソールの設定タブ、EB CLIまたはAPIで、管理されたプラットフォームの更新を有効にしなければなりません。管理されたプラットフォームの更新についての詳細は、ドキュメントまたはFAQをご覧ください。 Elastic Beanstalkの詳細： 製品ページ ドキュメント リリースノート プラットフォームサポートリスト 翻訳は舟崎が担当しました。原文はこちらです。

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リクエストについては可能な限りマージされますので、スループットの向上とバーストクレジットの有効活用が行われます。 […]

AWS Elastic Beanstalk を利用してアプリケーションコードをデプロイする際に、immutable, rolling with additional batch という 2つの新たなデプロイメントポリシーを利用可能になりました。これは、現在 Elastic Beanstalk がサポートしている2つの既存のデプロイメントポリシー(rolling, all at once) に追加されるものです。アプリケーションを更新する際に、これらの4つのポリシーから、1つ選択できます。 これらの 4つのデプロイメントポリシーに加えて、 Elastic Beanstalk では、 DNS ベースの Blue/Green アップデートも利用できます。 Elastic Beanstalk 上のアプリケーションや環境設定を更新する際に、 新たなデプロイメントポリシーである immutable を利用できます。このポリシーは、ダウンタイムを細小にしたり、デプロイメントの失敗によるリスクを小さくしたい商用環境でのアップデートに非常に向いています。このポリシーを利用することによって、デプロイメントの失敗による影響を1つのインスタンスに限定したり、更新中にあなたのアプリケーションがフルキャパシティでトラフィックをさばいたりすることが可能になります。このポリシーでは、新たに作成される 一台のAmazon EC2 インスタンスにコードをデプロイし、新しいバージョンを実行する新規インスタンス群の全台が起動される前に、ヘルスチェックに通るか確認します。ひとたび、新しいアプリケーションバージョンを実行する新規インスタンス群が起動されると、古いインスタンス群は終了されます。 また、アプリケーションを更新する際に、新たなデプロイメントポリシーである rolling with additional batch を利用できます。このポリシーを利用することによって、デプロイメントの失敗による影響を単一バッチに限定したり、更新中にあなたのアプリケーションがフルキャパシティでトラフィックをさばいたりすることが可能になります。このポリシーでは、既存のインスタンス群からなる各バッチに更新を展開する前に、新規に作成される EC2 インスタンスからなるバッチにコードをデプロイします。デプロイメントの終わりに、古いアプリケーションバージョンを実行する最後のバッチを終了します。例えば、もしあなたが、 あなたのアプリケーションを実行する 9台の EC2 インスタンスを持っていて、1/3 ずつ更新するように選択した場合、本ポリシーにより、まずはじめに3台の新バージョンを実行する新規インスタンスが作成されます。新規インスタンス群(バッチ)がヘルスチェックに成功すると、 Elastic Beanstalk は、古いインスタンスのうちの6台を、2回にわけて連続で更新していきます。古いバージョンを実行する残りの3台を終了します。 加えて、Elastic Beanstalk でサポートされる全ての Linux プラットフォームが、 2016.03 […]