Category: Amazon EC2*


EC2のX1インスタンス – メモリー重視のワークロードに対応可能

多くの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.0AES-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 HANAに必要とされるSAP OLAPとOLTPの両ワークロードの性能要件を満たしています。

お客様は、オンプレミスからAWSに移行できますし、もちろん新規構築することもできます。次世代ビジネススイートSAP S/4HANA、または以前のバージョンのどちらも稼働させることができます。

現在、多くのAWSのお客様が、複数のR3インスタンスを並べたスケールアウト構成でSAP HANAを稼働させています。これらのワークロードの多くは1台のX1インスタンスで実行できるようになります。この構成であれば、構築も容易で、運用コストも抑えられます。後述していますが、構成オプションの詳細情報は最新のSAP HANA Quick Start にて提供いたします。

X1インスタンスで実行された環境をSAP HANA Studioでみると次のようになります:

X1インスタンスでSAP HANAを稼働させる場合、災害対策(DR)や高可用性(HA)においても複数の興味深いオプションがあります。例えば:

  • 自動リカバリー – RPO (Recovery Point Objective)とRTO(Recovery Time Objective)にもよりますが、EC2 Auto Recoveryを使うことでシングルインスタンスで稼働することができるかもしれません
  • ホットスタンバイ – 2つのアベイラビリティゾーンでX1インスタンスを稼働し、SAP HANAシステムレプリケーションによって予備インスタンスと同期することができます
  • ウォームスタンバイ / 手動フェイルオーバー – プライマリーのX1インスタンスとセカンダリーには永続ストレージが付与された小さなインスタンスで構成することもできます。フェイルオーバーが必要となった場合、セカンダリーインスタンスを停止し、インスタンスタイプをX1に変更し、再起動します。このユニークなAWSならではのオプションであれば、低コストを維持しながら、迅速な復旧が実現できます

今日のローンチにあわせてSAP HANA Quick Startを更新しています。新規のVPCもしくは既存のVPC内に、十分に検証済みのSAP HANAが1時間以内で利用可能です:

このクイックスタートは 、インスタンスと関連するストレージを構成し、SAP HANAと前提となるOSパッケージをインストールするのにお役立ちいただけます。

また、私たちはSAP HANA Migration Guideも公開しました。現行のオンプレミスもしくはAWS上で稼働するSAP HANAワークロードのAWSへの移行をお手伝いします。

Jeff;

翻訳はPartner SA 河原が担当しました。原文はこちらです。

EC2 Run Commandアップデート – コマンドの管理と共有など

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 Base (KB) IDで指定された特定のWindows Updateのセットをインストールします。

オープンソースのエージェント
インスタンス用Simple Systems Manager (SSM)エージェントのLinux版がGitHubのhttps://github.com/aws/amazon-ssm-agentで利用可能になりました。

このコードへのプルリクエストのサブミットを歓迎します(詳細はCONTRIBUTING.mdを参照してください)。

いますぐ利用可能
ここで説明した機能はいますぐ利用可能で米国東部(北バージニア)、米国西部(オレゴン)、ヨーロッパ(アイルランド)、米国西部(北カルフォルニア)、ヨーロッパ(フランクフルト)、アジアパシフィック(東京)、アジアパシフィック(シンガポール)、アジアパシフィック(シドニー)、そして南アメリカ(ブラジル)リージョンで今日からつかいはじめることができます。

より詳細は、Managing Amazon EC2 Instances Remotely (Windows) とManaging Amazon EC2 Instances Remotely (Linux)をお読みください。

Jeff;

翻訳は渡邉(@gentaw0)が担当しました。原文はこちらです。

Amazon EBSのアップデート – 新たなスループット最適化ボリュームとコールドボリューム

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リクエストについては可能な限りマージされますので、スループットの向上とバーストクレジットの有効活用が行われます。(バーストクレジットの概念についてはこちらのブログポストを参照してください)

もしアプリケーションがファイルシステムとOSのページキャッシュを利用するのであれば(普通は利用するようになっていますが)、先読みバッファのサイズを1MBに設定することをお勧めします。Amazon LinuxやUbuntuにおける設定例を以下に示します。(デバイスファイル名は読み替えてくださいね!)

$ sudo blockdev --setra 2048 /dev/xvdf

なお、2048という値は512バイトのセクタの数を意味しています。従ってこの例のように2048と指定すればちょうど1MBということになります。この設定を行うことにより、大きなデータブロックに対するシーケンシャルな読み書きパフォーマンスが向上します。しかしながら、小さなデータブロックに対するランダムなI/Oではレイテンシが高くなりますので注意して下さい。

Linux Kernelのバージョン4.2以前を使用しているお客様が設定すべき項目は既にご紹介した先読みバッファのサイズだけです。もっと新しいKernelを使用している場合は、最高のパフォーマンスを発揮するためにxen_blkfront.maxを256に設定することをお勧めします。 Amazon Linux AMIの場合は/boot/grub/menu.listをエディタで開き、下記のように編集を行えばOKです。

kernel /boot/vmlinuz-4.4.5-15.26.amzn1.x86_64 root=LABEL=/ console=ttyS0 xen_blkfront.max=256

もしお手元のシステムのファイルに複数のエントリが存在する場合は、現在利用しているカーネルに関するものを修正してください。これは起動時に適用されるパラメータですので、変更内容を反映するには再起動が必要です。ブートローダとしてGrubを採用していないLinuxディストリビューションを利用している場合は、そのブートローダにあったやり方で同様のパラメータ変更を行う必要があります。

パフォーマンスチューニングに関する情報が必要な場合は、Amazon EBSボリュームのパフォーマンス on LinuxインスタンスまたはAmazon EBSボリュームのパフォーマンスon Windowsインスタンスを参照してください。

EBSボリュームタイプの比較
それぞれのボリュームタイプの仕様やユースケースを表にまとめました。(元祖EBSであるマグネティックは記載していませんが、これからも引き続きご利用いただけます)

Solid State Drive (SSD) Hard Disk Drive (HDD)
ボリュームタイプ プロビジョンド
IOPS SSD (io1)
汎用SSD
(gp2)
スループット
最適化HDD (st1)
コールドHDD (sc1)
ユースケース I/O性能に依存するNoSQLデータベースやリレーショナルデータベース 起動ボリューム、低レイテンシを要求するアプリケーション、開発・テスト環境 ビッグデータ、DWH、ログデータ処理 スキャンする頻度が低いデータ
ボリュームサイズ 4 GB – 16 TB 1 GB – 16 TB 500 GB – 16 TB 500 GB – 16 TB
ボリューム毎の最大IOPS 20,000
(16 KB I/O size)
10,000
(16 KB I/O size)
500
(1 MB I/O size)
250
(1 MB I/O size)
インスタンス毎の最大IOPS
(複数ボリューム)
48,000 48,000 48,000 48,000
ボリューム毎の最大スループット
320 MB/s 160 MB/s 500 MB/s 250 MB/s
インスタンス毎の最大スループット
(複数ボリューム)
800 MB/s 800 MB/s 800 MB/s 800 MB/s
月額料金
(東京リージョン)
$0.142/GB
+
$0.074/設定IOPS値
$0.12/GB $0.054/GB $0.03/GB
性能指標
IOPS IOPS MB/s MB/s

なお、汎用SSDやプロビジョンドIOPSで提供されるIOPSよりも高いIOPSが必要な場合は、ストライピング構成を取ることが可能です。詳しい情報はLinuxでのRAID構成またはWindowsでのRAID構成にまとまっています。

テスト用のCloudFormationテンプレート
テスト環境を簡単に構築するために、シンプルなCloudFormationテンプレートをご用意いたしました。st1 templateは2TBのスループット最適化HDDボリュームがアタッチされたEC2インスタンスが起動します。詳細な情報はst1 template instructionsにまとまっていますので、こちらもご覧ください。

今すぐご利用頂けます
新しいボリュームタイプは今すぐにご利用頂けます!AWS Management ConsoleAWS Command Line Interface (CLI)AWS Tools for Windows PowerShellAWS CloudFormationテンプレートAWS SDKなどお好みの方法で新しいタイプのボリュームをプロビジョンできます。

これまでご説明してきたように、新ボリュームタイプは高スループットと低コストを両立しています。我々は引き続きお客様のご要望を満たすようなEBSの進化を継続していきたいと考えておりますので、みなさまのフィードバックをお待ちしております!


Jeff;

 

日本語版の補足情報
毎週水曜日にお送りしているAWS BlackBelt Online Seminarですが、4/27(水)にAmazon EBSをご紹介いたします。今回発表された新しいボリュームタイプについても詳しくご説明いたしますので、ぜひご参加下さい。無料でご参加いただけますが、登録が必要ですのでこちらのサイトからご登録をお願いいたします。

(日本語版は小林が担当しました。原文はこちら)