Amazon Web Services ブログ

先日 (2019/3/5) 開催しました AWS Black Belt Online Seminar「Amazon EC2」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190305 AWS Black Belt Online Seminar Amazon EC2 AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. Nitro Hypervisor と KVMベースのハイパーバイザーとの違いは何でしょうか。今後はNitor Hypervisorベースが主になるのでしょうか。 A. Nitro Hypervisor はKVMのコアテクノロジーをベースとして構築されており、一般的なHypervisorの機能である、CPUやメモリの分離といった仮想化機能に加えて、Nitro CardなどEC2の専用ハードウェアコンポーネントを活用して、Hypervisorとしてより軽量に、仮想化インスタンスに対して一貫したパフォーマンスを提供できるように作られています。今後、新しいインスタンスタイプのほとんどがNitro Hypervisorを使用する予定です。Nitro Hypervisorに関しては、下記のFAQも参照ください。 https://aws.amazon.com/jp/ec2/faqs/#Nitro_Hypervisor Q. Public IPのユースケースがよくわかりませんでした。Public IPが変わっても、ALBの設定に連動するのでしょうか？ A. EC2インスタンスをインターネットと通信する要件がある場合、1) VPCのサブネットにインターネットゲートウェイ(IGW)をアタッチする(このサブネットを「パブリックサブネット」と呼びます)のに加え、2) EC2インスタンスがインターネットから通信可能なIPアドレスを持つ必要があります。この2)を実現するひとつの方法がPublic IPアドレスです。Public IPアドレスを付与するかどうかはEC2インスタンス起動時のオプションで指定することができます。 後半のご質問は対象のEC2インスタンスがALBのバックエンドにアタッチされている場合、Public IPアドレスが変わったときどうなるか、というご質問としてお答えします。この場合、ALBに登録したインスタンスの設定を変更する必要はありません。これはALBはバックエンドEC2インスタンスをPublic IPアドレスの単位で管理しておらず、EC2インスタンスそのものとして管理しているためとお考えください。補足として、EC2インスタンスの稼働中にPublic IPアドレスは変更されることはなく、停止して起動するタイミングでのみ変更されます。このとき、インスタンスの停止中もALBからの登録状態は継続されます。 Q. Webサーバーなどのアプリケーション利用ではAMDのCPUは、有用性はありますでしょうか？ A. 利用するアプリケーションの性能要件をAMDのCPUでも満たすことさえできれば、Intel版の同等のインスタンスタイプに比べてオンデマンド価格で10%程度安価にご利用頂くことが可能であり、コスト面でとても有用と思われます。 Q. 利用中のEC2で、armアーキテクチャのCPUに変更は可能ですか？ A. 従来のx86とARMではCPUアーキテクチャが異なり、稼働するOSやアプリケーションもそれぞれのアーキテクチャに対応したものである必要があります。その為、利用中のEC2がx86アーキテクチャの場合は、インスタンスタイプの変更でARMアーキテクチャのA1インスタンスに変更するような事は行えません。OSからARMアーキテクチャのものを使用して構築して頂くことになります。 Q. Elastic […]

本日、カリフォルニア州サンタクララ市で開催された AWS サミットでは、世界初のグローバル自律型レーシングリーグの2019年シーズンが開始されました。AWS DeepRacer リーグは、すべてのスキルレベルの開発者が、 世界中のAWS グローバル サミット の一連のレーシングイベントを通じて、Machine Learning を使った実践を行うことを許可します。AWS DeepRacer リーグは、年間を通じた仮想イベントとトーナメントを含みます。 開発者として、Machine Learning のスキルをテストするエキサイティングな日でした! 9 時間後に、400 周の自律走行、5 マイルを超えるレースで、サンタクララの優勝者が発表されました。カリフォルニア州サンタクララを拠点にする Cloud Brigade の創立者である Chris Miller は、リーダーボードを突破し、ネバダ州ラスベガスで開催される re:Invent 2019 でAWS DeepRacerチャンピオンシップカップへの経費支給の旅に進める最初の勝者です。10.43 秒の優勝者のタイムで Chris と彼のチームはサンタクララサミットに AI トML について学ぶことを目的に来ました 「私は最新の用途で利用できる Machine Learning と技術に興奮しています」。 Chris はサミットの AWS DeepRacer ワークショップの 1 つで彼の勝利したモデルをトレーニングしました。次は Chris のアジェンダです。彼は現在、Machine Learning と彼のモデルをさらにカスタマイズする方法についてもっと多く学習することにより、re:Invent の準備をしています。 リーダーボードの 3 つのトップの開発者: […]

このブログ記事では、Amazon Elastic Container Service for Kubernetes (Amazon EKS) を使用したコンテナへの Microsoft SQL Server のデプロイについて説明します。ここで説明するものと同じアプローチと原則は、再利用可能で再現可能な DevOps プラクティスと組み合わせた高可用性 (HA) と耐久性を必要とする他のステートフルアプリケーションにも適用されます。ユースケースの例としては、MongoDB、Apache Cassandra、MySQL、ビッグデータ処理などがあります。 SQL Server をコンテナ内で実行するためのサポートは、SQL Server 2017 で初めて導入されました。Kubernetes (K8s と呼ばれることもあります) を使用して、Linux コンテナ内で本番用 SQL Server ワークロードを実行できます。 Microsoft SQL Server は、今日使用されている最も人気のあるデータベースエンジンの 1 つです。SQL Server は魅力的な機能と堅牢なコミュニティを数多く提供しますが、クラウドベースまたはオープンソースのデータベースソリューションよりもさらにメンテナンスを必要とするか、より高価です。組織によっては、オープンソースソリューションに移行してライセンスコストを削減することで、これらのコストを削減しようとしているところもあります。他の企業は、ワークロードを Amazon RDS for Microsoft SQL Server や Amazon Aurora などのマネージド型リレーショナルデータベース管理システム (RDBMS) サービスに移行することを選択しています。 ただし、組織が SQL Server エンジンから離れることができない […]

AWS App Mesh は、HTTP および TCP サービスの実行を広範囲で支援します。これにより、トラフィックのルーティングと監視に一貫性のある方法が提供され、問題の内容を把握し、障害やコード変更の後にトラフィックをリルートすることが可能になります。App Mesh は、オープンソースの Envoy プロキシを使用します。AWS のパートナーやオープンソースコミュニティが提供する多くのツールと連携できます。 このサービスは、AWS Fargate、Amazon EC2、Amazon ECS、Amazon Elastic Container Service for Kubernetes、 Kubernetes などの上で実行が可能です。各サービスに出入りするトラフィックは、全て Envoy プロキシを通過するので、ルーティング、帯域制限、測定、記録などが行えます。この追加された間接レベルにより、共通コミュニケーションライブラリの必要もなしで、お望みのあらゆる言語でサービスを構築することもできます。 App Mesh のコンセプト 早速取りかかる前に、まず、重要な App Mesh のコンセプトやコンポーネントのいくつかについて確認しておきましょう。 サービスメッシュ – 隣り合うサービス間にあるトラフィックの論理的な境界線。1 つのメッシュには、仮想サービス、仮想ノード、仮想ルーター、ルートなどが含まれています。 仮想サービス – 仮想ノード にが直接的に、あるいは、仮想ルーターにが間接的に与える、サービスの抽象型 (論理名)。メッシュ内にあるサービスは、他のサービスを論理名によって参照および利用します。 仮想ノード – タスクグループ (ECS サービスもしくは Kubernetes デプロイメント) 、または、1 つか複数の EC2 インスタンスの上で実行されるサービスへのポインタ。各仮想ノードは、リスナーを経由して入って来るトラフィックを受け付け、バックエンドを通じ他の仮想ノードへ接続します。加えて、各ノードには、サービスディスカバリー設定 (現状では DNS ネーム) […]

昨年、皆さんに新しい低コストの AMD 搭載 M5a および R5a EC2 インスタンスについてお伝えしました。AWS Nitro System 上に構築されたこれらのインスタンスは、2.5 GHz で動作するカスタム AMD EPYC プロセッサを備えています。これらは、同等の EC2 M5 および R5 インスタンスよりも価格が 10% 低く、コストとパフォーマンスに基づいてインスタンスの組み合わせのバランスを取るための新しい機会を提供します。 本日、AWS は M5ad と R5ad の各インスタンスを追加します。これらはどちらもカスタム AMD EPYC 7000 シリーズプロセッサを搭載しており、AWS Nitro System 上に構築されています。 M5ad および R5ad インスタンス これらのインスタンスは、昨年末にローンチされた既存の M5a および R5a インスタンスに、高速で低レイテンシーのローカル (物理的に接続された) ブロックストレージを追加します。 M5ad インスタンスは、ウェブサーバー、アプリケーションサーバー、開発/テスト環境、ゲーム、ログ記録、およびメディア処理などの汎用ワークロード向けに設計されています。これらは 6 つのサイズでご利用いただけます。 インスタンス名 vCPUs RAM ローカルストレージ […]

AWS のお客様の多くは、大量 (大抵の場合ペタバイト以上) の重要データを収集して保存しますが、そのデータにアクセスすることはほとんどありません。raw データを収集してからすぐに処理し、その後万が一さらに処理または分析する必要が生じたときのために数年または数十年にわたって保存しておく場合もあれば、データをコンプライアンスまたは監査目的のために保持する場合もあります。このパターンに当てはまる業界とユースケースには以下のようなものがあります。 金融 – 取引アーカイブ、活動 & 監査ログ、および通信ログ。 ヘルスケア/ライフサイエンス – 電子医療カルテ、医療画像 (レントゲン、MRI、または CT)、遺伝子配列、製剤開発の記録。 メディア & エンターテイメント – メディアアーカイブと未処理の撮影映像。 物理的なセキュリティ – 未処理のカメラ映像。 オンライン広告 – クリックストリームと配信ログ。 交通 – 車両テレメトリ、ビデオ、RADAR、および LIDAR データ。 科学/研究/教育 – 石油および天然ガス探鉱のための振動実験に関連するデータを含む、研究のインプットと結果。 AWS は本日、Amazon S3 で重要な低頻度アクセスのデータを保存するための、新しく、コスト効率性がより高いストレージを導入します。 Amazon S3 Glacier Deep Archive ストレージクラス 新しい Glacier Deep Archive ストレージクラスは、耐久性があり、セキュアな大量のデータ向けの長期ストレージを、オフプレミスのテープアーカイブサービスに負けない価格で提供するよう設計されています。データは 3 つ以上の AWS アベイラビリティゾーンにまたがって保存され、12 時間以内に取りだすことができます。高価で扱いにくいテープドライブに対処し、オフプレミスストレージを手配して、新世代のメディアへのデータの移行について心配する必要はもうありません。 既存の […]

AWS Application Load Balancer は、2016 年の夏以来活躍しています。 これらは、コンテンツベースのルーティングをサポートし、サーバーレスおよびコンテナベースのアプリケーションとも相性がよく、スケーラビリティがきわめて高いロードバランサーです。AWS のお客様の多くが既存のホストおよびパスベースのルーティングを使用して、HTTP や HTTPS アプリケーションを動作させています。同時に、ポート転送 (コンテナベースのアプリケーションには最適)、ヘルスチェック、サービスディスカバリー、リダイレクト、固定レスポンス、組み込み認証といったさまざまな ALB 機能も活用しています。 高度なリクエストルーティング ホストベースのルーティング機能で、ホスト のヘッダーを使用してトラフィックを任意のターゲットグループにルーティングするようにルールを書くことができます。本日より、この機能を拡張、汎用化して、皆さまが標準およびカスタム HTTP ヘッダーとメソッド、クエリ文字列、ソース IP アドレスに基づいてルールを書けるように (その結果、トラフィックをルーティングできるように) なりました。さらに、そのルールと条件もパワフルになりました。ルールは複数の条件 (AND 条件すべて) が設定可能になり、その各条件も複数の値 (OR 条件のいずれか) とのマッチを指定できます。 この新機能で、お使いのアプリケーションアーキテクチャはシンプル化され、ルーティング用のプロキシフリートの必要性がなくなり、望まないトラフィックをロードバランサーでブロックできます。ユースケースをいくつかご覧ください。 ボットやクローラのトラフィックを人的トラフィックから分離する。 顧客または顧客グループをセル (別のターゲットグループ) にアサインし、そのトラフィックをルーティングする。 A/B テストを実施する。 カナリアリリース手法によるデプロイ、またはブルー/グリーンデプロイを実施する。 メソッドベース (たとえば、あるターゲットグループには PUT、別のターゲットグループには GET など) で、マイクロサービスハンドラーにトラフィックをルーティングする。 IP アドレスまたは CDN ベースで、アクセス制限を実行する。 オンプレミスまたはインクラウドのターゲットグループにトラフィックを選択的にルーティングする。 デバイスのさまざまなタイプやカテゴリに、異なるページやユーザーエクスペリエンスを配信する。 高度なリクエストルーティングの使用法 本機能は、現在お使いの Application Load Balancer で既存のルールを編集するだけでご利用になれます。まず、プレーンテキストの固定レスポンスを返すシンプルなルールから始めます […]

Amazon Redshift は、エクサバイト規模まで拡張可能なデータウェアハウスです。現在、何万ものAWS 顧客 (NTTドコモ、Finra、Johnson & Johnson を含む) が Redshift を使用してミッションクリティカルな BI ダッシュボードを実行し、リアルタイムのストリーミングデータの分析や、予測分析ジョブを実行しています。 こうした中、ピーク時に同時実行クエリの数が増えると、問題が発生します。多くのビジネスアナリストが BI ダッシュボードに目を向けるようになったり、長期間実行されるデータサイエンスのワークロードが他のワークロードとリソースを奪い合うようになると、Redshift はクラスター内で十分なコンピューティングリソースが利用可能になるまでクエリをキューに入れます。こうすることで、すべての作業は確実に完了しますが、ピーク時にパフォーマンスが影響を受ける可能性があります。次の 2 つの選択肢があります。 ピーク時のニーズに合わせてクラスタをオーバープロビジョニングする。この選択肢は当面の問題は解決しますが、必要以上にリソースとコストを浪費します。 一般的なワークロードに合わせてクラスターを最適化する。この選択肢を採用すると、ピーク時に結果を待つ時間が長くなり、ビジネス上の重要な決定が遅れる可能性があります。 新しい同時実行スケーリング 今回、第 3 の選択肢を提示したいと考えています。必要に応じてクエリ処理能力を追加するように Redshift を設定することができます。これは透過的かつ数秒の短時間で発生し、ワークロードが何百もの同時クエリに増加しても高速で一貫したパフォーマンスを提供します。追加の処理能力は数秒で準備ができるので、事前のウォームアップまたはプロビジョニングは必要ありません。1 秒あたりの請求額で、使用した分だけお支払いいただき、メインクラスターの実行中は 24 時間ごとに 1 時間の同時実行スケーリングクラスターのクレジットが累積されます。余分な処理能力は、不要になった時点で取り除かれるので、前述したバースト性のあるユースケースに対処するのに最適な方法です。 特定のユーザーまたはキューにバーストパワーを割り当てることができ、既存の BI および ETL アプリケーションを引き続き使用することができます。同時実行スケーリングクラスターは、さまざまな形式の読み取り専用クエリを処理するために使用され、柔軟に動作できます。詳細については、同時実行スケーリングを参照してください。 同時実行スケーリングの使用 この機能は、既存のクラスターに対して数分で有効にできます。 テスト目的で新しい Redshift パラメーターグループから始めることをお勧めします。そこで、まず 1 つ作成することから始めます。 次に、クラスターの Workload Management Configuration を編集し、新しいパラメータグループを選択し、[Concurrency Scaling Mode] を [auto] に設定して、[Save] をクリックします。 […]

深層学習について学び、アプリケーションでそれを使う方法をできるだけ簡単にしたいと考えています。大規模なデータセットを取り込み、既存のモデルをトレーニングし、新しいモデルを構築して推論を実行する方法を知っていれば、将来のための十分な準備が整います。 新しい深層学習コンテナ 今日は、新しい AWS Deep Learning コンテナについて説明します。こうした Docker イメージは、他のフレームワークと共に、TensorFlow または Apache MXNet を使用した深層学習トレーニングや推論に使用する準備ができています。顧客が Amazon EKS や ECS を使用して TensorFlow ワークロードをクラウドにデプロイしていることを説明し、そうしたタスクをできる限り単純かつ簡単にすることを当社に依頼したのを受けて、これらのコンテナを構築しました。その間、トレーニング時間の短縮と推論性能の向上を目的として、AWS で使用するイメージを最適化しました。 イメージは事前設定および検証済みなので、Amazon ECS、Amazon Elastic Container Service for Kubernetes、Amazon Elastic Compute Cloud (EC2) でのカスタム環境とワークフローの設定が数分で可能であり、深層学習に集中できます。 AWS Marketplace や Elastic Container Registry で見つけて、無料で使用することができます。イメージはそのまま使用することもできますし、追加のライブラリーまたはパッケージを使用してカスタマイズすることもできます。 次の要素に基づく名前の複数の深層学習コンテナを使用できます (すべての組み合わせが使用できるわけではありません)。 フレームワーク – TensorFlow または MXNet。 モード – トレーニングまたは推論。単一ノードまたはマルチノードのクラスターでトレーニングをすることができます。 環境 – CPU または GPU。 […]

ディープニューラルネットワークのアーキテクチャ向けに設計されたデータセットの収集と、トレーニングルーティンのコード化はすでに済んでいます。いつでも、最強の GPU インスタンスにある複数のエポックに、大規模なデータセットでのトレーニングを実行することが可能です。NVIDIA Tesla V100 GPU を搭載した Amazon EC2 P3 インスタンスが、計算集約型の深層学習トレーニングジョブに最適であることはわかりました。ただし、予算は限られており、トレーニングの費用を減らしたいと考えます。 スポットインスタンスの料金は、数時間から数日を要するトレーニングジョブを実行している深層学習の研究者や開発者のために、高性能 GPU を手頃で利用しやすいものにしています。スポットインスタンスを利用すると、オンデマンドレートよりも大幅に値引きされた価格で、予備の Amazon EC2 コンピューティング性能を利用できます。インスタンスおよびリージョンごとの最新の価格一覧については、スポットインスタンスアドバイザーをご覧ください。スポットインスタンスとオンデマンドインスタンスの主要な相違点の詳細については、Amazon EC2 ユーザーガイドをお読みいただくことをお勧めします。 スポットインスタンスは深層学習のワークフローに最適ですが、オンデマンドインスタンスと比べ、使用上の課題がいくつか存在します。まず、スポットインスタンスはプリエンプションが可能で、2 分前に通知すれば終了できます。これは、トレーニングジョブを実行し完了する際にインスタンスを当てにできない、ということを意味します。したがって、時間的制約のあるワークロードにはお勧めしません。第二に、トレーニングの進行状況が正常に保存されていなかった場合、インスタンスを終了したときにデータが紛失する可能性があります。第三に、スポットインスタンスを作成した後はアプリケーションを中断させないことを決定した場合、スポットインスタンスを停止し、オンデマンドインスタンスまたはリザーブドインスタンスとして再作成する以外に選択肢がなくなります。 これらの課題に対処するために、深層学習のトレーニングワークフロー向けにスポットインスタンスをセットアップし、同時に、スポットの中断が発生した場合にはトレーニングの進行状況の紛失を最小限に抑えることが可能な、ステップバイステップのガイドを用意しました。次の特徴を維持しながらセットアップを実装することが、ここでの目標です。 コンピューティング、ストレージ、コードのアーティファクトを分離し、コンピューティングインスタンスをステートレスに維持する。これにより、インスタンスが終了したときに、復旧とトレーニング状態の復元を簡単に行えるようになります。 データセット、トレーニングの進行状況 (チェックポイント)、ロゴのために、専用のボリュームを使用する。このボリュームは永続的で、インスタンスの終了の影響を受けるようなことがあってはなりません。 バージョン管理システム (例: Git) を使用する。このリポジトリは、トレーニングを開始/再開するためのクローンを作成する必要があります。これにより、トレーサビリティが有効になり、インスタンスが終了したときに変更されたコードが紛失することを防げます。 トレーニングスクリプトのコードの変更を最小限に抑える。これにより、トレーニングスクリプトを個別に開発することが可能になり、バックアップとスナップショットのオペレーションをトレーニングコードの外部で実行できます。 さまざまな自動化終了後の交換用インスタンスの作成、起動時のデータセットとチェックポイントのEBS ボリュームの添付、 アベイラビリティーゾーンを横断したボリュームの移動、インスタンスの状態の復元実行、トレーニングの再開、トレーニング完了後のインスタンスの終了、これらを自動化します。 TensorFlow と AWS 深層学習 AMI を使用したスポットインスタンスの深層学習 この例では、スポットインスタンスと AWS 深層学習 AMI を使って、CIFAR10 データセットで ResNet50 モデルをトレーニングします。 ここでは、AWS 深層学習 AMI バージョン 21 で入手可能な CUDA 9 を使って構成された、TensorFlow […]