Category: Amazon EC2

今年はじめに公開したブログ「長い形式の EC2 リソース ID が利用可能に」で、移行期間は 2016 年 12 月の初旬までと説明しました。この期間中はリージョンやユーザーベースで新しいリソース形式にオプトインすることができます。移行を完了すると、新たに作成したリソースの文字列には 17 文字が使用されるようになります。次の大切な日付を忘れないようにしてください。 11 月 – 11 月 1 日より describe-id-format コマンドを使用して希望のリージョンのカットオーバー期限を確認できるようになります。 12 月 – 12 月 5 日から 12 月 16 日の間、各 AWS リージョンにおいて 17 文字の文字列をデフォルトで使用するように設定します。 ご利用されているコードやツールが新しい形式に対応できるように、できる限り早急にオプトインすることをお勧めします。 オプトイン、オプトアウト、またはステータスチェックに使用できる長い形式の ID コンバーターツールをリリースしました。すでに をインストールしている場合は、スクリプトをダウンロードすればこれを実行することができます。 $ wget https://raw.githubusercontent.com/awslabs/ec2-migrate-longer-id/master/migratelongerids.py $ chmod +x migratelongerids.py 次に実施可能な操作をいくつかご紹介します。 アカウントのステータスを確認: $ ./migratelongerids.py –status アカウント、IAM ロール、IAM ユーザーを長い形式の […]

で Windows Server 2016 を実行できるようになりました。このバージョンの Windows Server にはいくつもの新機能が搭載されています。これには Docker や Windows コンテナのサポートも含まれています。本日より、すべての AWS リージョンで次の 4 つの形式をご利用いただけます。 Windows Server 2016 Datacenter のデスクトップ環境 – Windows Server のメインストリームバージョンはセキュリティとスケーラビリティを考慮して設計されています。従来のアプリケーションはもちろんのこと、クラウドネイティブのアプリケーションにも対応しています。Windows Server 2016 に関する詳細は「The Ultimate Guide to Windows Server 2016」 (登録必須) をご覧ください。 Windows Server 2016 の Nano Server – 最小構成のインストールで導入するクラウドネイティブは適度なディスク容量を使用し、アプリやサービス実行に使用するシステムリソース (メモリ、ストレージ、CPU) をより多く残し、データセンターバージョンよりも迅速に起動することができます。コードやアプリケーションを移行する場合の詳細情報については「Moving to Nano Server」をご覧ください。Nano Server にはデスクトップ UI が含まれていないので、PowerShell または WMI […]

今年初旬に AWS は x1.32xlarge インスタンスをリリースしました。約 2 TiB の容量を備えるこのインスタンスタイプは、メモリに大きな負担をかけるビッグデータ、キャッシュ、分析などのワークロードに最適です。AWS のお客様は SAP HANA インメモリデータベース、大規模な Apache Spark や Hadoop ジョブ、様々なタイプのハイパフォーマンスコンピューティング (HPC) ワークロードを実行しています。 そしてこの度、AWS は X1 インスタンスタイプの更新を 2 つリリースしました。 新しいインスタンスのサイズ – x1.16xlarge インスタンスの新しいサイズはフットプリントが小さいワークロードの実行を可能にします。 新しいリージョン – X1 インスタンスの利用が可能なリージョンを 3 つ追加しました。これでリージョン数は合計 10 になりました。 新しいインスタンスのサイズ 新しい x1.16xlarge の仕様は次のとおりです。 プロセッサ: 2 x Intel™ Xeon E7 8880 v3 (Haswell) 2.3 GHz – 32 cores […]

EC2 リザーブドインスタンスはほぼ 8 年前に発表されました。2009 年に開始されたモデルには 2 つの利点があります。キャパシティーの予約と、アベイラビリティーゾーン内の特定のインスタンスの使用に適用される大幅な割引です。長年にわたり、お客様からの意見や要望に基づいてモデルを改良し、スケジュールされたリザーブドインスタンス、リザーブドインスタンスの予約内容の変更機能、リザーブドインスタンスマーケットプレイスでのリザーブドインスタンス (RI) の売買機能などのオプションを追加してきました。今回、リザーブドインスタンスモデルを再び強化することになりました。その内容は以下のとおりです。 リージョン単位の利点 – 多くのお客様から、割引がキャパシティーの予約よりも重要だという意見や、柔軟性が増すなら割引率は下がっても構わないという意見を頂いていました。そこで今回からは、Standard RI に関連付けるキャパシティーは予約されずに、リージョン内のいずれかの AZ で実行したインスタンスに RI の割引が自動的に適用されるように選択可能になりました。 Convertible リザーブドインスタンス – Convertible RI では、柔軟性を増しながらも高い割引 (On-Demand に比べて通常 45% の割引) を受けられます。リザーブドインスタンスに関連付けたインスタンスファミリーやその他のパラメータはいつでも変更できます。たとえば、新しいインスタンスタイプを利用するために C3 RI を C4 RI に変換したり、アプリケーション用にメモリの増量が必要になった場合に C4 RI を M4 RI に変換したりできます。また、EC2 の値下げを徐々に活用するために Convertible RI を使用することもできます。 それでは、詳しく見ていきましょう。 リージョン単位の利点 リザーブドインスタンス (Standard または Convertible) がリージョン内のすべてのアベイラビリティーゾーン間で自動的に適用されるように設定可能になりました。リージョン単位の利点により、リージョン内のすべてのアベイラビリティーゾーン間で RI がインスタンスに自動的に適用されることで、RI の割引の適用範囲が広がります。この利点を使用すると、キャパシティーの予約は行われません。代わりに、キャパシティーを予約するためのアベイラビリティーゾーンの選択が必要になります。インスタンスを頻繁に起動、使用、終了する動的な環境では、この新しい利点により、柔軟性が増し、RI […]

私は長期に渡る技術やビジネスの動向を見ながら、自ら使用しブログに書くことができる製品やサービスの成り立ちを観察することが好きです。今回のブログを準備している時に、3 つのトレンドが頭に浮かびました。 ムーアの法則 – 1965 年に予測されたムーアの法則は、半導体のトランジスタ数の集積度は毎年 2 倍になるというものです。 大量市場/大量生産 – 人類が生み出し、使用し、楽しんでいる技術は大量の半導体を消費しており、大きなマーケットシェアになっています。 専門化 – 上記の動向から、ニッチ市場ですら専門的な製品に関しては十分に大きい市場である場合があります。 このような動向に合わせて業界が進むに連れ、過去 10 年ほどの間に興味深いチャレンジがいくつか浮上しました。次のリストをご覧ください (箇条書きで考える癖がついていますね)。 光の速度 – トランジスタ密度が増加しても、光の速度には限界があります (コンピューターの先駆者 Grace Hopper が好んで言っていたように、電気は1ナノ秒の間に 1 フィート未満しか移動できません)。 半導体物理学 – トランジスタのタイム変換 (オンまたはオフ) の基本的限界により CPU が達成可能なサイクル時間の最低値を判断することができます。 メモリボトルネック – 有名な von Neumann Bottleneck は CPU の追加能力値を制限します。 GPU (グラフィックスプロセッシングユニット) はこうした動向から生まれたもので、いくつものチャレンジに対応しています。プロセッサがクロック速度の上限に達しても、設計者はムーアの法則でより多くのトランジスタを使用することができます。従来のアーキテクチャに対し、より多くのキャッシュやメモリを追加するためにトランジスタを使用することができますが von Neumann Bottleneck はそれを制限します。逆に、現在では専用ハードウェア (GPU 消費の先駆けとしてはゲームなど) が大きな市場になっています。これらをまとめると、GPU はスケールアップ (プロセッサ速度の上昇やボトルネックメモリ) の代わりにスケールアウト […]

EC2 の M4 インスタンスはバランスの良いコンピューティング、メモリ、ネットワーキングリソースを提供し、様々なタイプのアプリケーションに適しています。 AWS は M4 インスタンスを去年リリースし (過去のブログを参照)、large から 10xlarge まで 5 つのサイズをご提供しました。そして本日、64 vCPU と 256 GiB の RAM を使用する m4.16xlarge をリリースしました。仕様情報については次をご覧ください。 インスタンス名 vCPU カウント RAM インスタンスストレージ ネットワークパフォーマンス EBS 最適化 m4.large 2 8 GiB EBS のみ 中 450 Mbps m4.xlarge 4 16 GiB EBS のみ 高 750 Mbps m4.2xlarge 8 32 GiB EBS のみ […]

同僚の Sean Kelly は Amazon Linux AMI チームに所属しています。今回のゲスト投稿では彼が最新バージョンについてご紹介します。 Amazon Linux AMI は Amazon EC2 で使用するために保守管理している Linux イメージです。 Amazon Linux AMI の新しいメジャーバージョンは、1 つ以上のリリース候補を含む公開テスト段階を完了した後に提供します。リリース候補は EC2 フォーラムで告知します。皆様からのフィードバックをお待ちしています。 2016.09 のリリース AWS は本日、全リージョンと現行世代の EC2 インスタンスタイプすべてに対応する 2016.09 Amazon Linux AMI をリリースしました。Amazon Linux AMI は HVM モードと PV モードの他に、EBS-backed と Instance Store-backed の AMI もサポートします。 この新しいバージョンの AMI はいつもの方法で起動できます。次のコマンドを実行して既存の EC2 インスタンスをアップグレードすることもできます。 $ sudo […]

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)、オンインスタンスエージェントが代理で通知を送信できるようにする […]