Category: Compute

この記事はAWS Senior Technical EvangelistのAbby Fullerの投稿です。 2017年12月12日に、AWSはAWS CodePipelineのターゲットとしてAmazon Elastic Container Service (ECS)をAWS Fargateも含めてサポートしたことをアナウンスしました。このサポートにより、コンテナベースのアプリケーションやマイクロサービスを継続的デリバリするパイプラインを作成するのがより簡単になりました。 コンテナ化したサービスを手動で構築しデプロイするのは、時間がかかりますしエラーを起こしがちです。自動化されたビルドとテスト機構と組み合わせた継続的デリバリは、早期にエラーを発見し時間を短縮することを助け、失敗を減らしてくれるので、アプリケーションのデプロイモデルとして一般的なものとなってきています。以前は、ECSでコンテナワークフローを自動化するには、AWS CloudFormationを使った自前のソリューションを構築する必要がありました。これからは、わずか数ステップでCodePipelineとCodeBuildをECSと連携させてワークフローを自動かすることができます。 CodePipeline、CodeBuild、そしてECSを使った典型的な継続的デリバリのワークフローは、以下のようなものです: ソースを選択する プロジェクトをビルドする コードをデプロイする GitHub上にこのワークフローのための継続的デプロイのリファレンスアーキテクチャも公開しています。 はじめてみよう 最初に、CodePipelineで新規プロジェクトを作成し、例として”demo”というプロジェクト名を設定します。 次に、コードが保管されているソースの場所を選択します。ここには、AWS CodeCommit、GitHub、またはAmazon S3が選択できます。この例では、GitHubを入力し、CodePipelineにレポジトリへのアクセス権を与えます。 次に、ビルドステップを追加します。JenkinsサーバURLやCodeBuildプロジェクトの様に既存のビルドを持ってくることもできますし、CodeBuildで新しいステップを作成することもできます。もし既存のCodeBuildのプロジェクトがなければ、以下の様に選択してCodePipelineから新しいものを作成しましょう: Build provider: AWS CodeBuild Configure your project: Create a new build project Environment image: Use an image managed by AWS CodeBuild Operating system: Ubuntu Runtime: Docker Version: aws/codebuild/docker:1.12.1 Build specification: […]

Amazon Web Services (AWS) が提供しているAmazon Linuxに新世代のAmazon Linux 2がリリースされました。他のサービスがそうであるようにAmazon Linux 2ではお客様からいただいた多くのフィードバックを元に作成されています。この新しいAmazon Linuxの特長をみていきましょう。 LTS（Long Term Support)の提供 これまでのAmazon Linuxはローリングアップグレードで定期的に新しいバージョンのパッケージが提供され続けることにより、常に最新の状態を維持できる環境として提供されていました。Amazon Linux 2でもこれは変わりませんが、加えてLTS (Long Term Support: 長期サポート）を提供する予定です。LTSでは５年間に渡りコアオペレーティングシステムにセキュリティパッチとバグフィックスを提供し続け、その間のユーザ空間のABI(Application Binary Interface)とAPI(Application Programming Interface)の互換性を維持します。互換性を維持しつつ安全なLinux環境を提供するのが目的であり、新しい環境に更新されることより互換性のある環境を長期に渡って使い続けることの方を望むお客様からのリクエストに応えるものです。 またコアオペレーティングシステムには無い、もしくは新しいバージョンのパッケージについてはAmazon Linux Extrasリポジトリから入手可能です。詳しくはamazon-linux-extrasコマンドのマニュアルを御確認ください。 LTSビルドは現在リリース候補（Release candidate）の状態として提供されており、評価を開始いただける状態です。 オンプレミス環境でのテストや開発が容易に Amazon Linux はAmazon EC2やAmazon ECS (コンテナ環境)上で容易に利用いただけるディストリビューションですが、Amazon Linux 2ではこれらに加えて、VMware、Microsoft Hyper-V、Oracle VM VirtualBoxの仮想イメージを提供します。これによりオンプレミス環境でのテストや開発が容易になります。Amazon Linux 2を稼働させるには最小で512MBのメモリが必要です。 新しい環境とセキュリティの強化 Kernel 4.9やSystemdのサポート等、OS環境全体が刷新されています。またセキュリティ面でも必須パッケージを厳選することによりリスクを減らし、重要度が高いセキュリティパッチについてはOS起動時に自動的に適用する等、高いセキュリティレベルを保つための仕組みが組み込まれています。 今からご利用いただけます！ 全ての商用リージョンでAMIが選択可能になっていますので、ぜひ御利用ください。HVMをサポートする全てのインスタンスタイプで御利用いただけます。Amazon LinuxをEC2上で利用する上で追加の費用は不要です（通常のAmazon EC2費用で利用可能）。DockerリポジトリにもAmazon Linux 2のベースイメージが準備済です。またフォーラムでは新しい告知に加えてみなさまからの利用のフィードバックをお待ちしております。   […]

EC2スポットインスタンスは、AWSクラウドの余剰コンピューティングキャパシティへのアクセスを提供します。 我々のお客様は、オンデマンドインスタンスと比較して大幅な節約をもたらす価格で、CI/CD環境とトラフィックジェネレータ、Webサーバとマイクロサービスのホスト、動画のレンダリング、さまざまなタイプの解析ジョブを実行するためにスポットインスタンスを使用しています 。 新しい合理化されたアクセス 11/28、我々はスポットインスタンスのための新しい、合理化されたアクセスモデルを導入します。 スポットインスタンスを起動したい時、RunInstances関数やrun-instancesコマンド、またはAWSマネージメントコンソールを使用して希望内容をシンプルにサブミットするだけで、条件が満たされている限りそのリクエストを実行することができます。 余分な労力を費やすことなく、インスタンスタイプのオンデマンド価格を最大90％削減できるため、同じ予算でアプリケーションスループットを最大10倍向上できます。 この方法で起動するインスタンスは、終了するまで、またはEC2がオンデマンドリクエストのためにEC2スポットインスタンスをターミネートする必要がある場合まで実行されます。 その時点で、スポットインスタンスには通常2分前の警告が与えられる為、その後再生できるフォールトトレラントなアプリケーションに最適です。 スポットマーケット、入札、およびスタンドアロンの非同期APIへの呼び出しを理解する必要があった旧モデルとは異なり、新しいモデルは同期的でオンデマンドとして使いやすいものです。 あなたのコードまたはスクリプトは即座にインスタンスIDを受け取り、リクエストが処理され受け入れられたかどうかを確認する必要はありません。 私たちは可能な限りクリーンでシンプルにしました。現在の多くのスクリプトやアプリケーションを修正して、スポットリクエストで使用することが容易になると予想しています。 スポットインスタンスの予算をさらに管理したい場合は、スポットリクエスト時に最大価格を指定するオプションがあります。 スポットを使用してAmazon EMR、Amazon ECS、AWS Batchクラスタにパワーを注いでいる場合、またはAWS CloudFormationテンプレートまたはAuto Scaling Groupを使用してスポットインスタンスを起動した場合、変更を加えることなくこの新しいモデルのメリットが得られます 。 RequestSpotInstancesまたは RequestSpotFleetの周辺に構築されたアプリケーションは、変更なしでうまく動作できます。 しかしながらSpotPriceパラメータを含まない要求を行うことができます。 スムーズな価格変更 11/28発表の一環として、スポット価格の変化の仕様を変えて、需給の長期的なトレンドに基づいて価格がより緩やかに調整されるモデルに移行しています。 先ほどお話したように、On-Demand価格の平均70-90％を引き続き保持し、インスタンスの稼働中の期間に有効なスポット価格を引き続き支払えます。 スポットフリート機能をベースに構築されたアプリケーションは、フリートの作成時に指定した設定に基づいて、最も費用対効果の高いプールにスポットインスタンスの配置を自動的に多様化します。 スポット イン アクション コマンドラインからスポットインスタンスを起動する際、 単にスポット市場を指定してください： $ aws ec2 run-instances –instance-market-options ‘{“MarketType”:”Spot”}’ \ –image-id ami-1a2b3c4d –count 1 –instance-type c3.large インスタンスハイバネーション メモリに多くの状態を保持するワークロードを実行する場合、この新しい機能が好ましいです！ インスタンスが再利用されたときにメモリ内の状態を保存するように手配し、ラップトップを閉じてから開くときと同じように、キャパシティが再び利用可能になったときに中断した場所とインスタンス上のアプリケーションを選択できます。 この機能は、Amazon Linux、Ubuntu、またはWindows Serverを実行しているC3、C4、および特定のサイズのR3、R4、およびM4インスタンスで動作し、EC2ハイバネーションエージェントでサポートされています。 メモリ内の状態は、インスタンスの起動時に設定された領域を使用してインスタンスのルートEBSボリュームに書き込まれます。 プライベートIPアドレスとElastic IPアドレスは、停止/開始サイクル全体にわたって保存されます。 […]

私はいつも新規のEC2ユーザの方には、他のインスタンスタイプを見る前に、まずは汎用インスタンスから使い始め、負荷テストをしてみて、自分のアプリケーションのコンピュート・メモリ・ネットワーキングの利用具合をよく把握することをアドバイスしています。コンピュート、メモリ、ストレージ等に最適化した幅広いインスタンスの選択肢によって、我々のお客様は要件にフィットする最適なインスタンスタイプを選ぶ柔軟さを得ることができます。 私のEC2インスタンスの歴史の記事にあるように、汎用 (M) インスタンスは我々がm1.smallをローンチした2006年まで遡ります。我々はこの家系図の枝にそって進化を続け、M2 (2009年)、M3 (2012年)、そしてM4 (2015年) インスタンスをローンチしてきました。我々のお客様は、汎用インスタンスを使って、WEB & APPサーバを動かしたり、エンタープライズアプリケーションをホストしたり、オンラインゲームを支援したり、キャッシュのクラスタを構築しています。 新しいM5インスタンス 2017年11月29日、我々は新しいM5インスタンスをローンチすることで、次のステップに進みます。我々の継続的なイノベーションへのコミットによる成果を持ち、旧世代よりも良い費用対パフォーマンスまでも得られるインスタンスです。カスタムの2.5 GHz Intel® Xeon® Platinum 8175Mシリーズのプロセッサをベースに、M5インスタンスは過酷なワークロードのために設計されておりM4インスタンスよりもコア単価で14%の費用対パフォーマンスの向上が得られます。AVX-512命令を使っているアプリケーションでは、コア毎にさらに2倍のFLOPSを生み出します。我々はさらに新しいハイエンドなサイズを追加することで、更に多くの選択肢を提供しています。 こちらがM5インスタンス達です(全てVPCのみ、HVMのみで、EBS最適化です): インスタンス名 vCPUs RAM ネットワーク帯域 EBS最適化帯域 m5.large 2 8 GiB 最大 10 Gbps 最大 2120 Mbps m5.xlarge 4 16 GiB 最大 10 Gbps 最大 2120 Mbps m5.2xlarge 8 32 GiB 最大 10 Gbps 最大 2120 Mbps m5.4xlarge 16 64 GiB […]

AWSの規模と顧客基盤の多様性により、様々なタイプのワークロードに特化したEC2インスタンスタイプを作成する機会を得られました。例えば、多くの一般的な新ビッグデータの利用ケースは、数テラバイトのデータへの高速でシーケンシャルなアクセスに依存しています。お客様は巨大なMapReduceクラスタを構築して動かし、分散ファイルシステムをホストし、Apache Kafkaを利用して大量のログを処理したいと考えています。 新しいH1インスタンス 新しいH1インスタンスは、この利用ケースに特化して設計されています。既存のD2（高密度ストレージ）インスタンスに比べ、H1インスタンスはローカル磁気ストレージ1テラバイトあたり、より多くのvCPUとメモリを搭載し、ネットワーク帯域幅を拡張しています。リソースのバランスのとれた組み合わせによって、より複雑な課題に対処する能力を提供します。 H1インスタンスは Intel Xeon E5-2686 v4プロセッサ(2.3GHz)で動作し、以下の4つのインスタンスサイズを用意しました（全てVPCのみ、HVMのみ) インスタンス名 vCPUs RAM ローカルストレージ ネットワーク帯域幅 h1.2xlarge 8 32 GiB 2TB 最大 10 Gbps h1.4xlarge 16 64 GiB 4TB 最大 10 Gbps h1.8xlarge 32 128 GiB 8TB 10Gbps h1.16xlarge 64 256 GiB 16TB 25Gps 大きい2つのサイズでは、全コアのTurboで2.7GHz、シングルコアのTurboで3.0GHzのIntel TurboとCPUパワーマネージメントをサポートします。 ローカルストレージはシーケンシャルI/Oで高いスループットを出せるよう最適化されており、2MBのブロックサイズで最大1.15GB/s の転送が期待できます。ストレージは256ビットのXTS-AESとワンタイムキーにより暗号化されます。2つの最大サイズのインスタンスはIntel TurboおよびCPUパワーマネージメントをサポートし、all-core Turboは2.7GHz、single-core Turboは3.0GHzで動作します。 インスタンス間での大容量データの送受信は、拡張ネットワークを使うことで容易に行うことができ、プレースメントグループ内で最大25Gbpsのネットワーク帯域幅が得られます。 今すぐ起動してみましょう H1インスタンスは米国東部（バージニア北部）、米国西部（オレゴン）、米国東部（オハイオ）、欧州（アイルランド）の各リージョンで本日（日本時間2017年11月30日）からオンデマンド型及びスポットでの利用が可能です。その他のリージョンでも準備中です。専用ホスト型、専用インスタンス、リザーブドインスタンス（1年および3年）も同じく利用可能です。 — Jeff; 原文: H1 […]

2017年11月30日、個別のAWS Lambdaファンクションに対して同時実行数の上限を設定することができるようになりました。実行数上限数の設定は、アカウントレベルの同時実行上限の一部を特定のファンクションに対して予約する事になります。この機能によって、特定のファンクションを事前に設定した最大同時実行数に到達した場合にスロットルさせることが出来ます。この機能は、Lambdaによって呼び出されるダウンストリームリソース（例えばデータベースのような）に対するトラフィックレートを制限したい場合や、プライベートVPCにアクセスするファンクションでのElastic Network Interface(ENI)とIPアドレスの消費を制御したい場合に役に立ちます。 あるファンクションの同時実行上限を数値で指定できます。こちらは、そのアカウント全体の同時実行上限($ACCOUNTで定義）から割り当てられます。1アカウントに対して、リージョンあたりの全てのファンクションのデフォルトの同時実行数は1000となっています。デフォルトでは、全てのファンクションの同時実行数が、このアカウントレベルの上限(つまり$ACCOUNT)に対してカウントされます。特定のファンクションに対して上限を設定すれば、同時実行上限の割当は、共有プールから取りされ、その特定のファンクションに割り当てられます。そのファンクションのその後全ての呼び出しは、ファンクションレベルの上限に対してのみカウントされます。個々のファンクションの同時実行数と、アカウントレベルの同時実行数は、この機能と同時に利用可能となった新しいAmazon CloudWatchメトリクスで追跡することが出来ます。 この機能についてより詳しく知りたい方はドキュメントをご参照ください。また、プロダクトページを訪れてさらなる情報を取得ください。 この機能は、 US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), AWS GovCloud (US), Canada (Central), South America (São Paulo), EU (Frankfurt), EU (Ireland), EU (London), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), China (Beijing)のリージョンでご利用可能です。   翻訳はSA布目が担当しました。原文はこちら

私が想像していた以上に早くサーバレスアプリケーションはメインストリームになりました。毎日毎秒、数え切れないほどの AWS Lambda ファンクションが起動され、ビジネスクリティカルな処理を実行しています。ユーザの皆さんは その柔軟性、安定性、コスト効率の良さを好きだと言ってくれます。 私たちはすべてのAWSのお客様がサーバレスな未来へ向かえるようにしたいと考えています。AWS Lambdaのサービス提供開始後、サーバレスアプリケーションのデプロイおよび管理プロセスを簡素化するため Serverless Application Model (SAM) を提供しました。さらにサーバレスのリファレンスアーキテクチャを公開しました。現在、Web アプリケーション、モバイルバックエンド、画像認識&処理、リアルタイムファイル処理、IoTバックエンド、MapReduce、リアルタイムストリーミング処理、そしてチャットボット向けの画像加工 を公開しています。 2017年11月30日、私たちは次のステップをお伝えします。AWS コンソールからサーバレスアプリケーションを可能な限り容易に探し、見つけ、デプロイできるようにします。加えて Lambda、SAM、サーバレスアプリケーションに関するオープンソースコミュニティをサポートするため、誰もが共有し、参加し、メリットを得られる場を提供します。

スプレッドプレイスメントグループは、クラスタやインスタンスのグループが障害になる可能性を低減する手助けを行います。Amazon EC2は、多くのHPCアプリケーションに典型的な、密なノード間コミュニケーションのために低レイテンシーなネットワークパフォーマンスが必要なアプリケーション向けに、クラスタプレイスメントグループを持っていました。今回リリースされた、スプレッドプレイスメントグループを利用することにより、メンバーのインスタンスが別個のハードウェアに配置され、アプリケーションに対してハードウェア障害による影響を低減することが可能になりました。スプレッドプレイスメントグループは全てのAWSリージョンでご利用可能です。スプレッドプレイスメントグループは、AWS Management Console, AWS Command Line Interface (CLI), AWS SDKからご利用可能です。   翻訳はSA布目が担当しました。原文はこちら

T2インスタンスについての最初の投稿は2014年の夏でした。そこでは、多くのワークロードは継続的なCPUパワーに対する需要は控えめであり、かなり多くのCPUパワーを必要とするのは時々であるとお話しました。このモデルはお客様と共鳴しました。T2インスタンスは非常に普及しており、マイクロサービス、低レイテンシーの対話型アプリケーション、仮想デスクトップ、ビルド＆ステージング環境、プロトタイプなどをホストするために利用されています。   新しいT2 Unlmitedインスタンス 本日（日本時間2017年11月30日）、AmazonはT２インスタンスで開拓したバーストモデルを拡張し、コストを可能な限り低く抑えながら、任意の時間枠で高いCPUパフォーマンスを維持する能力を提供します。インスタンスを起動する際に、この機能を有効にするだけです。すでに実行中のインスタンスに対しても、有効にすることができます。時間あたりのT2インスタンスの価格は、平均CPU使用率が24時間のウィンドウにおけるベースラインよりも低い場合には、すべての瞬間的なスパイクをカバーします。長期間に渡って高いCPU使用率でインスタンスが稼働する場合には、少額の時間課金が発生します。例えば、t2.microインスタンスを平均CPU使用率15%（ベースラインに比べ5%高い）で24時間動かすと、追加で6セントが課金されます（vCPU時間あたり5セント * 1 vCPU * 5% * 24時間）。

本日 Amazon Time Sync Service をリリースします。NTPで配信される時刻同期サービスで、各リージョンで冗長化している衛星接続の原子時計を使って高精度な時刻参照を提供します。このサービスは追加料金なくすぐに全リージョンのVPCの稼働中の全インスタンスで利用できます。 このサービスには 169.254.169.123 のリンクローカル IP アドレスを介してアクセスできます。つまり外部のインターネットアクセスする必要なく、プライベートサブネット内から安全にアクセスできます。