Category: Compute

以下のゲスト投稿で、私の同僚である Tim Bray は IsItOnAWS.com を構築した方法について説明しています。このサイトは、AWS の IP アドレスレンジのリストと Tim が記述した 関数を使用して、お気に入りのウェブサイトが AWS で実行されているかどうかを調べることを目的としています。 AWS のサイトですか? クリスマスの時期に遊び半分でプログラミングをしていたら、おもしろい Lambda 関数ができました。きっと気に入ってもらえると思います。指定したドメイン名 (または IP アドレス) (IPv6 でも可能) が、公表されている AWS IP アドレスレンジ に含まれているかどうかを調べてくれます。IsItOnAWS.com で実際に試してみることができます。構築の過程では、1 つの Lambda 関数で別の Lambda 関数を作成しています。JSON 形式の IPv4 および IPv6 CIDR で提供されているレンジのリストはここです。説明書はここで、Jeff Barr のブログ もあります。以下は、JSON 形式の IP レンジの例です。 { “syncToken”: “1486776130”, “createDate”: “2017-02-11-01-22-10”, “prefixes”: [ { […]

2010 年に、EC2 インスタンスでのリソースへのタグ付け およびその他の EC2 リソースが発表されました。その発表以来、リソースあたりのタグ付けできる数が 10 から 50 へ引き上げられ、また、リソースグループとタグエディタの導入により、タグはより役に立つものとなりました。お客様はタグを使用して、所有権の追跡、コスト計算の処理の向上、コンプライアンスプロトコルの導入、および IAM ポリシーからのアクセスとリソースの管理などを行っています。AWS のタグ付けモデルでは、リソース作成とリソースのタグ付けという別個の機能を提供しています。これは柔軟性が高く、多くのユーザーに役立ってきましたが、リソースがタグ付けされていない状態で存在すると、時間枠が小さくなります。2 つの異なる機能を使用すると、リソースの作成だけは成功してもタグ付けが失敗し、リソースがタグ付けされていない状態になってしまいます。以下の 4 つの新たな機能により、タグ付けをより柔軟で役に立つ仕方で行えます。作成時のタグ付け – EC2 インスタンスと EBS ボリュームのタグはリソースを作成する API 呼び出しの一部として指定できます。タグの使用の強制 – EC2 インスタンスまたは EBS ボリュームの特定のタグは強制的に使用するように IAM ポリシーを記述できます。リソースレベルのアクセス許可 – 皆様からのリクエストにより、 CreateTags と DeleteTags 機能では、IAM のリソースレベルのアクセス許可がサポートされるようになりました。ボリューム暗号化の強制 – 新しく作成された EBS ボリュームに対して、暗号化を強制的に使用するように IAM ポリシーを記述できます。作成時のタグ付け EC2 インスタンスと EBS ボリュームのタグはリソースを作成する API 呼び出しの一部として指定できるようになりました (呼び出しがインスタンスとボリュームの両方を作成する場合は、インスタンスと各ボリュームに異なるタグを指定できます)。リソースの作成とタグ付けは自動的に行われ、オペレーション (RunInstances、CreateVolume、および、リソースを作成するその他の機能) が成功するには、両方が成功する必要があります。インスタンスやボリュームを作成した後に実行するタグ付けのスクリプトを構築する必要はもうありません。EC2 インスタンスを起動するときにタグを指定する方法は以下のとおりです (インスタンスが起動するときに、CostCenter および […]

去年、AWS が NICE 買収の契約に署名したこと、そして両社が協力し合い高パフォーマンスと科学計算において今まで以上に優れたツールとサービスを開発していく予定であることをブログでお知らせしました。そして本日、NICE EnginFrame 2017 をリリースするに至りました。この製品は のパワー、スケール、柔軟性を活用する技術的および科学的なアプリケーションのセットアップと実行のプロセスをシンプルにするように設計されています。1 時間以内に、完全に機能する HPC クラスターをセットアップし、シンプルなウェブベースのユーザーインターフェイスを介してアクセスすることができます。すでに EnginFrame を使用している場合は、引き続きオンプレミスで実行したりクラウドに移動することができます。 AWS Inside クラスター (1 つ以上のクラスターを起動することも可能) は Virtual Private Cloud (VPC) 内にあり、複数の AWS サービスや機能を使用して構築されています。そうした機能とは Amazon Linux AMI、共有 、NFS スタイルのファイルストレージ、ユーザー認証の AWS Directory Service、トラフィック管理の Application Load Balancers などを実行している インスタンスなどです。このようなマネージド型サービスはワークロードや作業に集中しやすくすることができます。システムソフトウェアのアップグレード、パッチ、処理やストレージのスケーリング、そして自分でクラスターを構築した場合に伴うその他の責任などを心配する必要がありません。EnginFrame は テンプレートから起動します。パラメーター化し自己完結型のテンプレートは、起動する各クラスターが同じ様に設定されることを確実にします。テンプレートを実行すると 2 つの異なる CloudFormation スタック (AWS リソースの集合) が作成されます。 Main Stack – このスタックは自分のクラスターが共有している EFS ベースのストレージと、デフォルトのクラスタースタックへの受信リクエストをルートするアプリケーションロードバランサーをホストします。このスタックは IAM […]

EC2 シニアプロダクトマネージャーの Taylor Anderson が自動化を利用して AMI メンテナンスとパッチ適用を合理化する方法についてご説明します。-Ana 去年 12 月の re:Invent でリリースした Amazon EC2 Systems Manager では、ソフトウェアインベントリの収集や OS パッチの適用、システムイメージの作成そして Windows や Linux のオペレーティングシステム設定などのプロセスを自動化することができます。こうした機能は自動設定や継続的に行う大規模なシステム管理を自動化し、Amazon EC2 やオンプレミスで実行しているインスタンスのソフトウェアコンプライアンスを維持することができます。Systems Manager には自動化の機能が含まれています。パッチの適用やエージェントの更新、Amazon Machine Image (AMI) にアプリケーションを組み込む場合に、この機能を使用することができます。自動化を使用することで、イメージの更新を手動で行うための時間や労力を省くことができます。代わりに、合理化し繰り返し可能で監査可能なプロセスを通じて AMI を構築することができます。先日、AWS は自動化に関する公開ドキュメントを初めてリリースしました。詳しくは AWS-UpdateLinuxAmi をご覧ください。 このドキュメントは Ubuntu、CentOS、RHEL、Amazon Linux AMI のパッチ適用を自動化できるようしたり、その他のサイト固有のパッケージと設定のインストールも自動化します。さらに、自動化ドキュメントを最初に書く必要を排除することで自動化を取り入れやすくしています。 AWS-UpdateLinuxAmi は、ご自分の自動化ワークフローを構築する場合にテンプレートとして使用することもできます。Windows ユーザーを対象にした、今後公開予定の AWS-UpdateWindowsAmi ドキュメントはこれと同等の内容を提供します。AWS-UpdateLinuxAmi は次のワークフローを自動化します。 ソース Linux AMI から一時 EC2 インスタンスを起動 インスタンスのアップデート インスタンスでユーザー提供の更新前のフックを起動 […]

リザーブドインスタンスは AWS のお客様がご利用されている EC2 の使用量に対し、大幅な割引を提供します (オンデマンドの料金に比べ最大 75% の割引)。また、特定のアベイラビリティーゾーン (AZ) で使用する RI を購入される際のキャパシティー予約においても同様です。去年後半には、リージョン内の AZ すべてを対象に割引を適用するリージョン RI をリリースし、今まで以上にリザーブドインスタンスの柔軟性を高めました。また、リザーブドインスタンスに関連付けられたインスタンスファミリーやその他のパラメーターを変更できるようにするコンバーティブル RI も提供しました。どちらのタイプの RI も管理に掛かるコストを削減し、追加オプションを提供します。リージョン RI を使用すると、RI 割引の対象になる AZ で起動することを心配せずにインスタンスをスタートできます。コンバーティブル RI を使用する場合、時間が経過するに連れて選択するインスタンスタイプやサイズが変わっても、RI が使用量に適しているか確認することができます。 インスタンスサイズの柔軟性 3 月 1 日より、すでにご利用されているリージョン RI の柔軟性が今まで以上に高まります。一括請求により、複数のアカウントで使用している場合でも、共有テナンシーを持つすべての Linux/UNIX RI をインスタンスファミリーと AWS リージョン内のあらゆるサイズのインスタンスに適用できるようになりました。これにより、RI の管理時間を節約したり、コンピューティングリソースをよりクリエイティブで革新的に使用できるようになります。新しい RI や既存の RI のサイズはインスタンスサイズに基づいた正規化係数により決定されています。 インスタンスサイズ 正規化係数 nano 0.25 micro 0.5 small 1 medium 2 […]

うれしいお知らせです。AWS Elastic Beanstalk でカスタムプラットフォームを作成できるようになりました。この最新リリースの AWS Elastic Beanstalk により、開発者やシステム管理者は、AWS Elastic Beanstalk のカスタムプラットフォームイメージを独自に作成して管理し、インスタンス設定を完全にコントロールできます。ご存じのように、AWS Elastic Beanstalk は、一般的なウェブプラットフォームでウェブアプリケーションやサービスをデプロイ、スケーリングするためのサービスです。このサービスでは、ユーザーがコードをアップロードするだけで、デプロイメント、容量のプロビジョニング、負荷分散、Auto Scaling が自動的に処理されます。 これまでの AWS Elastic Beanstalk で提供していたのは、事前設定済みのプラットフォームのセットです。さまざまなプログラミング言語、Docker コンテナ、上述した用途別のウェブコンテナの設定が複数用意されていました。Elastic Beanstalk では、選択された設定に従って、1 つ以上の Amazon EC2 インスタンスで対象のアプリケーションを実行するためのソフトウェアスタックやリソースをプロビジョニングしていました。この最新リリースでは、独自のカスタマイズした Amazon Machine Image (AMI) からプラットフォームを作成できます。カスタムイメージは、サポートされているオペレーティングシステム (Ubuntu、RHEL、Amazon Linux) のいずれかで構築できます。これらの特化された Elastic Beanstalk プラットフォームの作成作業は、マシンイメージ作成ツールの Packer で簡素化できます。Packer は、すべての主要オペレーティングシステムで実行するオープンソースツールであり、1 つの設定から複数のプラットフォームのマシンイメージやコンテナイメージを作成できます。カスタムプラットフォームでは、Elastic Beanstalk 環境全体にわたり、標準化とベストプラクティスを適用して管理できます。たとえば、Ubuntu や Red Hat Enterprise で独自のプラットフォームを作成し、Elastic Beanstalk で現在サポートされていない言語やフレームワーク (Rust、Sinatra など) を使用してインスタンスをカスタマイズできます。 […]

の初日に、私は EC2 インスタンスの更新に関する投稿で、入手次第、皆様に追加情報をお知らせすることを約束しました。本日は、15 か所の AWS リージョンで 6 つのサイズの新しい I3 インスタンスの提供を開始したことをお知らせします。このインスタンスは入出力量が多いワークロード用に設計されており、きわめて効率が高い NVMe SSD ストレージを備えています。4 KB ブロックで最大 330 万の IOPS を配信し、最大 16 GB/秒のシーケンシャルディスクスループットを実現します。このため、リレーショナルデータベース、NoSQL データベース、検索エンジン、データウェアハウス、リアルタイム分析、ディスクベースのキャッシュなど、高スループットと低レイテンシーを必要とするあらゆるワークロードに最適です。I3 インスタンスは、I2 インスタンスと比較すると、低コストで高密度のストレージを提供し、CPU コアあたりの IOPS とネットワーク帯域幅も大幅に増えます。 仕様 インスタンスサイズと関連仕様は次のとおりです。 インスタンス名 vCPU カウント メモリ インスタンスストレージ (NVMe SSD) 料金/時間 i3.large 2 15.25 GiB 0.475 TB 0.15 USD i3.xlarge 4 30.5 GiB 0.950 TB 0.31 USD i3.2xlarge 8 […]

お客様からビジネスのダイナミックさと、それを実現するためのアプリケーションがブロックストレージに求めるものについてご意見をうかがうことは、いつも興味深いものです。ビジネス状況の変化に伴ってブロックストレージへの要求も変化し、容量を追加したり、性能特性の異なるボリュームが必要になったりすることもあるはずです。今日では、24時間運用され続けるシステムも珍しくはありません。結果として、ダウンタイムやシステム運用への影響なく変更作業を行えることがお客様にとって重要な要素となってきます。 我々は長年にわたり、お客様の様々なユースケースをカバーするために、EBSに新機能を追加し続けてきました。例えば、2016年にはスループット最適化HDD(st1)とコールドHDD(sc1)という2種類のボリュームタイプをリリースしました。これらのボリュームをシステム運用への影響なく、パフォーマンス特性の変更やコスト削減を行うことで、階層化ストレージのように利用したいと考えるお客様がいらっしゃいます。言い換えると、お客様はEBSがより柔軟になることを望んでいるのです！ エラスティックボリューム 本日、EBSの新機能としてエラスティックボリュームをリリースいたしました。これは現行世代のEC2インスタンスにアタッチされた、全ての現行世代のEBSボリュームで利用可能です。お客様はボリュームサイズの拡張、パフォーマンスの調整、ボリュームタイプの変更を利用中に行うことができます。変更処理はオンラインで行われますので、お客様のアプリケーションは引き続き利用可能でダウンタイムはありません。 この新機能はリソース計画やチューニング、空き容量の管理といった作業を劇的にシンプル化してくれます。あるいは作業自体が不必要になるかもしれません。従来のやり方はダウンタイムを伴うため、変更の完了までプランニングやシステム停止の調整を含めると数週間から数ヶ月にわたる時間が必要でした。しかしこれからは、利用しているストレージインフラストラクチャをシンプルなAPIコールで簡単に変更することが可能になります。 ワークロードの変化 – インフラ構築を急ぐ必要があり、汎用SSDボリュームを採用することにしました。システムをリリースし、運用を行っていくにつれて、スループット最適化HDDボリュームが最適であることに気づいたとしましょう。エラスティックボリュームの機能により、単純にボリュームタイプを変更するだけで対応が完了します。 突発的な需要への対応 – プロビジョンドIOPSボリューム上に構築したリレーショナルデータベースで、1ヶ月のほとんどの期間にわたり問題なく処理を行えるシステムがあります。ただし月末処理の関係で各月終わりの3日間は10倍のトラフィックを処理する必要があったとします。この場合は、エラスティックボリュームを利用して月末の3日間だけIOPSを高く設定し、処理が終わったら元に戻すという運用が可能です。 ストレージの増加 – 100GBのボリュームで運用してきたシステムで、ディスク使用率が90%を超過したというアラームが発報しました。あらかじめ設定を行っておけば、ボリュームとファイルシステムの拡大を自動的にダウンタイム無しで行うこともできます。 エラスティックボリュームの利用 お客様はこれら全ての操作をAWSマネジメントコンソールやAPIコール、AWSコマンドラインインタフェース(CLI)で実行できます。これに加えて、AWS CloudFormationのスタック更新機能を利用することも可能で、対象のボリュームに必要な変更を行ってくれます。コンソールを利用する場合は、対象のボリュームを選択してアクションメニューから「Modify Volume」を選択するだけです: ポップアップするウィンドウの中で、ボリュームタイプやサイズ、IOPS値(プロビジョンドIOPSボリュームの場合)を変更してください。これは75GBの汎用SSDボリュームを、20,000IOPSで400GBのプロビジョンドIOPSボリュームに変更する例です: 変更ボタンをクリックしたら、確認ウィンドウが表示されるので問題が無ければ「YES」をクリックします: ボリュームの「状態」に変更処理の進捗状況(modifying、optimizing、completed)が表示されます: 次のステップは追加されたストレージ領域を利用できるようにするために、ファイルシステムを拡張することです。作業の詳細についてはLinuxでEBSボリュームのストレージ領域を拡張するかWindowsでEBSボリュームのストレージ領域を拡張するを参照してください。ボリュームの状態が最適化中に変わったら(通常数秒で変わります)、ファイルシステムの拡張作業を行うことができます。新しいボリュームの容量やタイプはすぐに利用可能になりますが、最適化の処理は最大で24時間を要する場合があります。コストについて補足すると、ボリュームの状態がoptimizingになったタイミングで新構成を基準に計算されることになります(変更自体のコストはかかりません)。 エラスティックボリュームの自動オペレーション 手動オペレーションでの変更も充分に魅力的ですが、自動化を行うたくさんのチャンスがあります。いくつかのアイデアをお見せしてみましょう: 正しいサイジング – IOPS上限か、それに近いレベルに到達しているかをCloudWatchで監視しアラームを上げるよう設定します。アラームが上がったらIOPS値の増加や、ボリュームタイプの変更を行うための承認プロセスを開始し、変更作業の準備を進めます。同様にCloudWatchのカスタムメトリクスを利用して空き容量をモニタリングして、拡張のための承認プロセスを開始することもできます。 コストの削減 – CloudWatchメトリクスや予め設定したスケジュールに従ってIOPSの削減やボリュームタイプの変更を行います。（背景：先週、大学のセキュリティ管理者と会話する機会がありました。彼は学内の全てのサーバから1日に10GBのログを収集し、60日間に渡って保持するという仕事をしています。ほとんどのファイルは参照されることはなく、参照が必要になったときでもアクセス速度はそれほど求められません。この場合、1日分のログを書き込むための汎用SSDボリュームを作成し高速な書き込みを実施し、完了したらスループット最適化HDDに変更することでコストを最適化することができます。） 先にお伝えしたように、新たに追加された領域を利用できるようにするためにはファイルシステムをリサイズする必要があります。この手順をお見せするために、私の同僚がCloudWatch Events、AWS Lambda、EC2 Systems Managerを利用したPythonとPowerShellのサンプルスクリプトを提供してくれました。このルールはEBSから送信される情報に基づきmodifyVolumeというイベントにマッチし、logEventsというLambdaファンクションを起動します: このファンクションは対象となるボリュームを特定し、これがEC2 Systems Managerで管理されるインスタンスにアタッチされていることを確認したうえでメンテナンス用のタグ情報を付与します: def lambda_handler(event, context): volume =(event[‘resources’][0].split(‘/’)[1]) attach=ec2.describe_volumes(VolumeIds=[volume])[‘Volumes’][0][‘Attachments’] if len(attach)>0: instance = attach[0][‘InstanceId’] filter={‘key’: ‘InstanceIds’, ‘valueSet’: [instance]} info = […]

AWS Identity and Access Management(IAM) のロール を利用することで、Amazon EC2上で実行するアプリケーションは、AWSが自動的に作成、配布、およびローテーションする一時的なセキュリティ資格情報を利用することができます。一時的な資格情報を使用することは、IAMのベストプラクティスとなっており、インスタンスで長期間の鍵の管理する必要がなくなります。IAM Roles for EC2 (EC2のIAMロール)を使用することで、長期的なAWSアクセスキーを手動またはプログラムで管理する必要もなくなります。そして本日、既存のEC2インスタンスにIAMロールをアタッチすることが可能になり、アプリケーションはAWSによって提供される一時的なセキュリティ資格情報を使用できるようにするよう設定できるようになりました。 また、既存のEC2インスタンスに添付されているIAMロールを変更することも可能になります。 このブログ記事では、AWS CLIを使用して既存のEC2インスタンスにIAMロールをアタッチする方法をご紹介します。 ソリューションの概要 このブログ記事のソリューションでは、 1. IAMロールの作成 2. IAMロールなしで起動された既存のEC2インスタンスにIAMロールをアタッチ 3. アタッチされているIAMロールの付け替え この記事では、新しく作成されたIAMロールを”YourNewRole“とします。このロールに関連付けられたインスタンス・プロファイルを”YourNewRole-Instance-Profile“、 既存のインスタンスを”YourInstanceId“とすることにます。 これら(赤字)はアカウントのリソース名に置き換えてください。 ここでは、AWSコマンドラインインターフェイス（CLI）の設定が完了しており、IAMロールを作成する権限、EC2 APIを呼び出す権限を持っていることを前提としています。 IAMロールの作成 注：既存のIAMロールをアタッチする場合は、このポストの「IAMロールなしで最初に起動された既存のEC2インスタンスにIAMロールをアタッチ」に進んでください。 またAWSマネージメントコンソールを使用してIAMロールを作成してから、同じセクションに進むこともできます。 AWS CLIからIAMロールを作成する前に、信頼ポリシーを作成する必要があります。 信頼ポリシーは、EC2などのAWSサービスがアプリケーションに代わってIAMロールを引き受けることを許可します。 信頼ポリシーを作成するには、下記のポリシーをコピーし、YourNewRole-Trust-Policy.jsonという名前で保存したテキストファイルに貼り付けます。 { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Principal”: { “Service”: “ec2.amazonaws.com” }, “Action”: “sts:AssumeRole” } ] } 信頼ポリシーを作成すると、既存のEC2インスタンスにアタッチできるIAMロールを作成する準備が整いました。 AWS CLIからIAMロールを作成 1. AWS […]

Matt Wood の投稿 当社は Alexa から Amazon Go まで Amazon のすべての領域でディープラーニングを広範に使用し、これまで多くのディープラーニングエンジンを試してきました。そして 1 つのエンジンがディープラーニングを実行するための最もスケーラブルで効率的な方法として出現しました。その理由により、Amazon のエンジンとして MXNet が選択されました。MXNet はオープンソースの最新鋭のディープラーニングエンジンであり、これにより開発者は高度なカスタム人工知能システムを構築することができます。 このようなシステムのトレーニングは、そのスケールとパフォーマンスにより、MXNet では著しく高速です。たとえば、よく使用される画像認識ネットワークの Resnet では、MXNet は他のエンジンと比較して 2 倍のスループットを実現し、同等のモデルを半分の時間でトレーニングできます。また、MXNet は数百の GPU にわたって線形に近いスケーリングを示しますが、他のエンジンのパフォーマンスでは、規模に見合った増加は見られません。 Amazon には重要なチームがあり、MXNet コミュニティと連携して、この進化に継続的に取り組んでいます。チームは MXNet に対して Apache Incubator に参加し、Apache Software Foundation のプロセス、財産管理、支援活動、およびコミュニティイベントを活用することを提案しました。幸い、この提案は受け入れられました。Apache MXNet への投資は開始点にあり、当社はコミュニティと連携して既に重要になっているユーティリティを拡大していくことを楽しみにしています。MXNet の使用開始を希望される場合は、AWS Re:Invent で私が行った基調講演をご覧になり、AWS ディープラーニング AMI のインスタンス (またはクラスター全体) を起動してください。これには MXNet と、プリコンパイルされ、すぐに使用できるサンプルコードが含まれています。また、推奨モデリングに関する Leo のプレゼンテーションとチュートリアルもご覧ください。 Twitter で @apachemxnet […]