Category: Compute

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 ソリューションをご紹介します。とても興味深い機能です。AWS クイックスタートと同様に、これは AWS ソリューションアーキテクトがセキュリティと可用性のベストプラクティスを取り入れて構築した機能です。この新しい Transit VPC Solution は transit VPC と呼ばれる実に便利なネットワーク構築の実装方法を示します。この機能を使用して地理的に離れていたり、別々の AWS アカウントで実行している仮想プライベートクラウド (VPC) をグローバルネットワーク転送センターとして機能する一般的な VPC と接続することができます。このネットワークトポロジーはネットワーク管理を簡略化し、設定と管理を必要とする接続の数を減少することができます。さらに実装は仮想的に行うようになっているので、物理的なネットワーク機器は不要、コロケーション転送ハブの目の前にいる必要もありません。次の例をご覧ください。 この図では、transit VPC が中央にあり、その周囲に「スポーク型」の VPC と、企業データセンター、その他のネットワークが配置されています。transit VPC は複数の重要なユースケースをサポートします。 プライベートネットワーキング – 2 つ以上の AWS リージョンに渡るプライベートネットワークを構築できます。 共有接続 – 複数の VPC はデータセンター、パートナーネットワーク、その他のクラウドと接続を共有できます。 クロスアカウント AWS の使用量 – VPC と AWS のリソースを複数の AWS アカウントに収めることができます。 ソリューションは AWS CloudFormation スタックを使用し、すべての AWS リソースを起動し構成します。500 Mbps から […]

AWS Serverless Chatbot コンテストの審査員にならないかとのオファーが来たので、喜んで引き受けることにしました。 Chatbot の構築 AWS Lambda と Amazon API Gateway を使用して Slack 用の chatbot を構築してください。他の API (Slack Events API が便利) や追加サービス (AWS その他)、その他のデータソースも使用することができます。コンテストの参加作品はクリエイティブかつオリジナルであり、Stack ユーザーに本当の価値を提供できるものでなければなりません。AWS Free Tier は Lambda、API Gateway、そしてその他の AWS サービスへのアクセスを無料でご提供します。AWS の新規および既存のユーザーは Lambda リクエスト 100 万件、そして 400,000 GB/秒のコンピューティング時間を無料で利用することができます。AWS の新しいユーザーはサインアップしてから 12 か月間、API Gateway への API コールを毎月 100 万件ご利用いただけます。 コンテスト参加作品 Chatbot が完成したら、パッケージやマーケティングにも力を注ぐことをおすすめします。参加作品の一環として次のアイテムを提供することも忘れないでください。 Chatbot を実際に使用した様子を示すビデオ資料 参加作品の機能やユニークな点に関する概要 […]

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）が担当しました。原文はこちら。  

Amazon EC2 Container Service (Amazon ECS)のClusterを自動的にスケールさせる方法はありましたが、本日Auto ScalingとAmazon CloudWatchのAlarmに追加された新機能により、ECSのServiceにScaling Policyを利用することができます。ServiceのAuto Scalingにより、需要が高まった時にスケールアウトさせて高い可用性を実現したり、需要が下がったらServiceとClusterをスケールインさせることでコストを最適化するのを、全て自動でリアルタイムに行うことができます。 この記事では、Clusterを需要に合わせて自動的にリサイズさせつつ、この新しい機能がどうやって利用できるかをお見せします。 Service Auto Scalingの概要 すぐに利用できるECS Serviceのスケーリング機能はずっと一番要望を受けていて、ついに今日この機能をアナウンスでき嬉しいです。自動でスケールするServiceの作成手順はとても簡単で、ECSコンソールやCLI、SDKでもサポートされています。希望するTaskの数とその最小・最大数を選択し、1つ以上のScaling Policyを作成すると、後はService Auto Scalingが面倒を見てくれます。Service SchedulerはAvailability Zoneを意識してくれるので、ECSのTaskを複数のZoneに渡って分散するように心配する必要もありません。 それに加えて、ECS Taskを複数AZ Cluster上で実行することも非常に簡単です。ECS ClusterのAuto Scaling Groupが、複数Zoneに渡る可用性を管理してくれるので、必要とされる回復力や信頼性を持つことができ、ECSがTaskのZone間の分散を管理してくれるので、皆さんはビジネスロジックに集中することができます。 利点: 来ているアプリケーションの負荷にキャパシティを対応させる: ECS ServiceとECS ClusterのAuto Scaling Groupを両方にScaling Policyを使います。必要に応じて、Cluster InstanceとService Taskをスケールアウトさせ、需要が落ち着いたら安全にスケールインさせることで、キャパシティの推測ゲームから抜け出せます。これによって、ロングランな環境で低コストな高可用性を実現できます。 複数AZのClusterでECSの基盤に高い可用性を持たせる: Zone障害という可能性から守ることができます。Availability Zoneを考慮しているECS SchedulerはCluster上のTaskを管理し、スケールし、分散してくれるので、アーキテクチャは高い可用性を持ちます。 Service Auto Scalingのデモ この記事では、これらの機能を使い真にスケーラブルで高い可用性を持ったMicroservicesアーキテクチャを作成する手順を辿りたいと思います。このゴールに到達するために、以下の様な手順をお見せします: Auto Scaling Groupで2つ以上のZoneにECS Clusterを作成する。 そのCluster上にECS Serviceを設定し、希望するTaskの数を定義する。 ECS Serviceの前段にElastic Load Balancingのロードバランサを設定する。これが負荷の入り口になります。 […]