Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

【新発表】AWS アプリケーションロードバランサー

私たちはElastic Load Balancing (ELB)を2009年にAWSで発表しました(New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatchを見るとこの時からAWSがどれだけ変化してきたかがわかると思います)。Elastic Load BalancingはAWS上で動くアプリケーションのキーコンポーネントとなりました。Auto Scalingとの連携によって、Elastic Load Balancingは高い可用性を保ちながらアプリケーションをスケールアップ・ダウンする仕事を非常に簡単にしてくれました。 レベル よく知られているOSIモデルでは、ロードバランサーは一般的にレイヤー4 (ネットワーク)かレイヤー7 (アプリケーション)で実行されます。 レイヤー4のロードバランサーはネットワークプロトコルのレベルで動作しネットワークパケットの中身を見ないので、HTTPやHTTPSの機能は無視します。別の言い方をすれば、これは全てを知る必要なく負荷を分散する仕組みになります。 レイヤー7のロードバランサーはより洗練されていて強力です。パケットの中を見て、HTTPとHTTPSのヘッダにアクセスし、(他の情報も合わせて)より賢い方法で負荷をターゲットに分散させることができます。 AWS上のアプリケーションロードバランサー 本日、私たちは新しいアプリケーションロードバランサーをELBの1つとして発表します。これはレイヤー7で実行され、幾つかの先進的な機能をサポートしています。元々のロードバランサー(これからはクラシックロードバランサーと呼ばれます)は引き続き利用可能で、レイヤー4とレイヤー7の両方の機能を提供します。 アプリケーションロードバランサーはコンテントベースのルーティングと、コンテナで実行されるアプリケーションをサポートします。業界標準の2つのプロトコル (WebSocketとHTTP/2)をサポートし、またターゲットのインスタンスやコンテナのヘルス状態の可視化も追加されています。コンテナやEC2インスタンスで動いているウェブサイトやモバイルアプリケーションは、アプリケーションロードバランサーを使うことで利益を得ることができるでしょう。 それでは、これらの機能を一つ一つ見ていって、最後に新しいアプリケーションロードバランサーを自身で作成してみましょう! コンテントベースのルーティング アプリケーションロードバランサーはHTTPヘッダーにアクセスし、リクエストを異なるバックエンドにルーティングすることができます。例えば、/apiがURLパスに含まれているリクエストを1つのサーバグループ(これをターゲットグループと呼びます)に送り、/mobileが含まれるリクエストをもう1つのグループに送りたいとします。こういった手法でリクエストをルーティングすることで、複数のマイクロサービスをそれぞれ独立して実行しスケールさせることができます。 この後見ることになりますが、1つのアプリケーションロードバランサーでは、リクエストをターゲットグループへ向けてルーティングするURLベースのルールを10個まで定義することができます。さらにこの先、他のルーティング方式も実装することを計画しています。 コンテナベースアプリケーションのサポート 多くのAWSのお客様がマイクロサービスをコンテナ化し、Amazon EC2 Container Serviceの上で動かしています。これによって1つのEC2インスタンス上で1つ以上のサービスを実行することができますが、古いロードバランサーではポートマッピングやヘルスチェックを注意する必要があるという幾つかの課題が存在しました。 アプリケーションロードバランサーはコンテナベースのアプリケーションを認識しサポートしてくれます。これによって1つのインスタンス上で、複数のポートをlistenしている幾つかのコンテナを同一のターゲットグループの下に紐付けることができ、またより詳細なポートレベルのヘルスチェックを実施できます。 メトリクスの改善 アプリケーションロードバランサーはヘルスチェックをポートベースで実施しレポートします。ヘルスチェックは許容するHTTPのレスポンスのレンジを指定でき、詳細なエラーコードも含まれます。 コンテントベースのルーティングにより、メトリクスをマイクロサービス毎に収集することも可能になりました。これはとても良い副作用であり、各マイクロサービスは自身のターゲットグループを特定のEC2インスタンス群で実行できます。こうした可視化の改善により、各サービスの負荷に応じてスケールアップ・ダウンが可能になりました。 アプリケーションロードバランサーはいくつかの新しいCloudWatchのメトリクスを追加していて、その中には全体のトラフィック(GB単位)、アクティブなコネクション数、また1時間単位のコネクションレートが含まれます。 プロトコルとワークロードの追加サポート アプリケーションロードバランサーは2つのプロトコルサポートを追加しました: WebSoecketとHTTP/2です。 WebSocketはクライアントとサーバの間で、長期間のTCPコネクションを利用可能にしてくれます。これは、HTTP接続を開いたままにして長い間隔の”ハートビート”を利用する様な古い方式の代替として、より効率の良いものとなっています。WebSocketはモバイルデバイスには特に良くて、電源の消費を最小にしながら、株価やスポーツの得点などの動的なデータを配信するのに利用できます。ALBはws://とwss://プロトコルを使ってWebSocketをネイティブサポートしています。 HTTP/2はHTTP 1.1プロトコルから多数の改善がされたものになります。この新しいプロトコルは1つのコネクションで上で複数のリクエストをサポートしています。これによって、ネットワークトラフィックを削減し、またプロトコルはバイナリをベースにしています。 アプリケーションロードバランサーはストリーミングやリアルタイム、そしてWebSocketのワークロードを最適化された方式で扱うために設計されています。リクエストとレスポンスをバッファリングせずに、ストリーミングとして扱います。これによって、レイテンシを削減しアプリケーションのパフォーマンスが向上します。 ALBを作成する では、アプリケーションロードバランサーを作成し、トラフィックを捌ける様にしてみましょう! Elastic […]

Read More

Amazon Elastic Block Store(EBS)アップデート-スナップショットストレージの値下げとPIOPSボリュームのIOPS/GB比率の改善

Amazon Elastic Block Store(EBS)はEC2インスタンスにアタッチして利用できる、永続化されたブロックレベルストレージです。EBSを利用することで、必要なパフォーマンスを備えたSSDベースのボリュームをプロビジョンし、マネジメントコンソールによる手作業やプログラムによってバックアップとして利用できるスナップショットを作成することが可能になります。 本日、これらの機能に対する改善についてお知らせをいたします。プロビジョンドIOPSボリュームにおけるプロビジョン可能なIOPS値の制限を緩和するとともに、スナップショットストレージの費用を47%削減いたします。この改善により、EBSはこれまでよりもパワフルで経済的なものになるでしょう。 IOPS/GB比率の改善 プロビジョンドIOPSのコンセプトをご紹介したのは2012年のことでした(詳細は過去のポストをご覧ください)。プロビジョンドIOPSボリュームを利用すると、それぞれのEBSボリュームに必要なレベルのパフォーマンスを確保することができます。設定可能なIOPSの値はボリュームのサイズに依存しており、最大20,000IOPSまでの範囲でボリュームが大きくなるほどより高いIOPSを指定することが可能です。 これまでは、1GBあたり最大30IOPSの範囲で指定が可能でした。これからは1GBあたり最大50IOPSまでを指定できるようになります。プロビジョンドIOPSボリューム(io1)は年間を通じて、99.9%に時間に対して指定したIOPS値のプラスマイナス10%の範囲のパフォーマンスを発揮するように設計されています(詳細についてはEBSについてのよくある質問をご覧ください)。 極めて負荷の高い処理を実行するために、小容量で高いIOPSを持つプロビジョンドIOPSボリュームを利用しているケースがあります。本日発表した改善により、こういった小容量で高いIOPSを求めるユースケースにおいて、さらに容量を小さくすることが可能になります。つまり、従来は20,000IOPSを指定するには最低667GBの容量が必要だったものが、本日からは400GBを確保すれば良いということになるのです。 この改善は全ての一般利用可能なAWSリージョンにおいて、新たにボリュームを作成する際に適用されます。 スナップショットストレージの値下げ また、全てのAWSリージョンにおいてEBSスナップショットの費用を47%値下げいたします。 スナップショットはこれまでよりも経済的になりました。この改善の結果として、より高頻度にバックアップを取ることが可能になり、これによって障害や人為的ミスからのリカバリタイムが短くなることが期待できます。もしEBSボリュームのバックアップを取っていないようでしたら、今が始めるチャンスです! この値下げは2016年8月1日にさかのぼって自動的に適用されます。また、AWS Storage Gatewayのゲートウェイキャッシュ型ボリュームのスナップショットについても同様に適用されます。 — Jeff; 原文:Amazon Elastic Block Store (EBS) Update – Snapshot Price Reduction & More PIOPS/GiB(翻訳:SA小林)

Read More

サービス開始 – Amazon S3 が IPv6 をサポート

ご存知かもしれませんが、インターネットに接続されたすべてのサーバーとデバイスには独自の IP アドレスが必要です。遡ること 1981 年、RFC 791 (“インターネットプロトコル”) により IP アドレスとは 32 ビットのエンティティで、かつ組織の異なる IP アドレスの必要数に対応するよう設計された 3 つの異なるネットワークとサブネットサイズ (クラス A、B、C – 基本的に大中小のサイズ) を有するものと定義されました。やがてこの形式は無駄が多いとみなされるようになり、より柔軟な CIDR (Classless Inter-Domain Routing) 形式が標準化され使用されました。32 ビットエンティティ (一般に IPv4 アドレスとして知られる) はよく用いられてきましたが、インターネットの継続的な成長により、最終的には利用可能なすべての IPv4 アドレスが割り当てられ使用されてしまうでしょう。 この成長に対応し今後の展開に道を開くよう、ネットワーク、デバイス、サービスプロバイダーは IPv6 へと移行中です。128 ビット/IP アドレスの IPv6 にはたっぷりのアドレス空間 (単純計算すると 128 ビットには 35 億個の IP アドレスを 10 穣個 (1 穣は 10 の 27 乗)、つまり宇宙の星の数ほどの人数に割り当てられるのに十分な数) […]

Read More

AWS ソリューション – Transit VPC

今日は新しい 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 から […]

Read More

Amazon Kinesis Analytics - SQL を使用してリアルタイムにストリーミングデータを処理

ご存知の通り、Amazon Kinesis では、AWS Cloud でリアルタイムにストリーミングデータを操作するプロセスが大幅に簡素化されています。独自のプロセスおよび短期のストレージインフラストラクチャを設定および実行する代わりに、ただ Kinesis ストリームまたは Kinesis Firehose を作成し、そこにデータを流し込むように設定してから、それを処理または分析するアプリケーションを構築するのみです。Kinesis ストリームと Kinesis Firehose を使用してストリーミングデータソリューションを構築するのは比較的簡単なのですが、さらに簡素化したいと考えました。作業開発者、データサイエンティスト、または SQL 開発者であるかどうかにかかわらず、お客様がウェブアプリケーション、テレメトリ、およびセンサーレポートの大量のクリックストリームを、接続されたデバイス、サーバーログなどからすべてリアルタイムに標準クエリ言語を使用して処理できるようにしたいと考えました。 Amazon Kinesis Analytics 本日より、Amazon Kinesis Analytics がご利用いただけるようになりました。ストリーミングデータに対して SQL クエリを継続的に実行し、データが届くと同時にフィルタリング、変換、および集約できるようになりました。インフラストラクチャで時間を無駄にするのではなく、データの処理とそこからのビジネス価値の抽出に注力できます。強力なエンドツーエンドのストリームプロセスパイプラインを 5 分で構築できます。SQL クエリより複雑なものを作成する必要はありません。 データベーステーブルに対する一連の SQL クエリの実行を考慮する場合、クエリは通常、非常に素早く追加および削除されるのに対して、データはほぼ静的なままです。常に行が追加、変更および削除されますが、これは特定の時点で実行する単一のクエリを考慮する際、一般的には関係ありません。Kinesis Analytics のクエリをストリーミングデータに対して実行すると、このモデルと正反対のことが生じます。クエリは長時間実行され、新しいレコード、監視、またはログエントリが届くと同時に、データは毎秒何度も変化します。一度この仕組みを把握すると、クエリプロセスモデルが非常に理解しやすいことが分かります。レコードが届くと同時に処理する、持続的なクエリを構築するのです。所定のクエリで処理されるレコードのセットを制御するには、プロセス「ウィンドウ」を使用します。Kinesis Analytics では、3 つの異なるタイプのウィンドウがサポートされています。 タンブリングウィンドウは定期的なレポートに使用されます。タンブリングウィンドウを使用して、時間の経過と共にデータをまとめることができます。おそらく毎秒数千~数百万ものリクエストを受信するので、1 分ごとの受信数を知りたいと思うでしょう。現在のタンブリングウィンドウが閉じると、その後に次のウィンドウが開始します。ウィンドウがいっぱいになるたびに、新しい結果が生成されます。 スライディングウィンドウは、モニタリングとその他のタイプのトレンド検出に使用されます。例えば、スライディングウィンドウを使用してリアルタイムで動くエラー率の平均をコンピューティングできます。レコードがウィンドウに入り、レコードがその中にあるかぎり結果に反映され、ウィンドウは進行します。新しいレコードがウィンドウに入るたびに、新しい結果が生成されます。ウィンドウのサイズを調整して、結果の精度を制御できます。 カスタムウィンドウは、適切なグループが厳密に時間に基づいていない場合に使用されます。クリックストリームデータまたはサーバーログを処理している場合、カスタムウィンドウを使用してセッション化として知られるアクションを実行できます。つまり、各ユーザーが実行する最初と最後のアクション (受信データ内のセッション ID により識別される) によって、各クエリをバインドできます。各ユーザーが閲覧したページ数またはサイトで費やした時間をコンピューティングするクエリを作成できます。 これらすべてはいくらか複雑に聞こえるかもしれませんが、実装するのは非常に簡単です。Kinesis Analytics では、受信レコードのサンプルを分析し、最適なスキーマを提案します。それをそのまま使用することも、微調整して実際のデータモデルをさらに反映することもできます。スキーマが定義されると、組み込み SQL エディターを使用できます (ライブデータに対する構文チェックと簡単なテストを含む)。クエリの結果を Amazon S3、Amazon Redshift、Amazon Elasticsearch Service、または […]

Read More

サーバーレスでChatbot コンテスト開催

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 を実際に使用した様子を示すビデオ資料 参加作品の機能やユニークな点に関する概要 […]

Read More

Amazon CloudFront をカナダで展開

主にお客様からのご要望に基づき実現した多数の機能を備える Amazon CloudFront は、世界中のお客様に静的、動的、そしてインタラクティブなコンテンツを高速かつ低レイテンシーで提供する場合に最適です。AWS 無料利用枠の一環として、HTTP や HTTPS のリクエスト 200 万件までを処理するほか、追加料金なしに毎月 50 GB までのデータを転送することができます。 そしてこの度、カナダのトロントおよびモントリオールにも CloudFront エッジロケーションを追加いたしました。同地域のお客様に今まで以上に優れたサポートをご提供、そして全世界に渡るロケーション数は 59 か所になりました (詳細は全リストをご覧ください)。これには先日オンラインになったブラジルで 2 番目のエッジロケーション、サンパウロも含まれています。トロントおよびモントリオールのロケーション価格は、米国のエッジロケーションと同様です (詳しくは CloudFront の料金表をご覧ください)。カナダのエッジロケーションは価格クラス 100 になります。 アプリケーションがすでに CloudFront を使用している場合は、新しいロケーションを活用するために特別な操作を行う必要はありません。ロケーションにかかわらず、ユーザーは静的、動的、ストリーミングしたコンテンツへのアクセスを高速かつ低レイテンシーでお楽しみいただけます。 また、開発者の方は CloudFront の使いやすさとコスト効率の良さを実感いただけるでしょう。柔軟性を備えているため、予測が困難なトラフィック負荷を処理する場合でも過剰にプロビジョニングする必要がありません。次の新しい 3 つのロケーションでも今後 Amazon Route 53 をサポートしていく予定です。新しいロケーションを活用するために特別な操作を行う必要はありません。 — Jeff  

Read More

AWS IoT のジャストインタイム登録をリリース

去年 12 月、re:Invent (概要は AWS IoT – Cloud Services for Connected Devices をご覧ください) にて、 AWS IoT を一般公開しました。 そして今年の始めには、私の同僚 Olawale Oladehin が Use Your Own Certificate with AWS IoT という記事で、自分の証明書を AWS IoT で使用する方法をご紹介しました。また、それ以前にも John Renshaw が Predictive Maintenance with AWS IoT and Amazon Machine Learning という記事で、AWS IoT の予測メンテナンスと Amazon Machine Learning について解説しています。 ジャストインタイム方式で登録 AWS IoT の柔軟性をさらに高めるため、本日よりデバイス証明書でジャストインタイム方式による登録が可能になりました。これにより […]

Read More

Amazon EMR 5.0.0 – メジャーアプリアップデート、UI改善、デバッグ改善、その他

Amazon EMRチームは新しいリリースをものすごい勢いでリリースし続けています。今年のローンチを振り返ってみましょう: EMR 4.7.0 – Apache Tez, Apache Phoenix, Presto, HBase, Mahout (6月) EMR 4.6.0 – 巨大データへのリアルタイムアクセス用に、HBase (4月) EMR 4.5.0 – Hadoop, Presto, SparkとEMRFS追加 (4月) EMR 4.4.0 – Sqoop, HCatalog, Java 8, 他 (3月) EMR 4.3.0 – Spark, Presto, Ganglia (1月) 今日、チームからEMR 5.0.0が発表されました。こちらはメジャーリリースとなり、16のオープンソースのHadoopエコシステムプロジェクトをサポートしています。SparkとHiveのメジャーバージョンアップ、TezがHiveとPigのデフォルトに、HueとZeppelinのUI改善、そしてデバッグ機能の改良が含まれています。 こちらは過去の幾つかのリリースでEMRがどの様に進化してきたかの図になります。 それではEMR 5.0.0の新しい機能をチェックしてみましょう! 16のオープンソースHadoopエコシステムプロジェクトのサポート EMR 4.0.0の開発からEMRのビルドとパッケージング処理を管理するために、Apache Bigtopを使い始めました。最新のGA (一般利用可能)なオープンソースのバージョンを出来る限り早くアクセス可能にするというゴールのために、Hadoopエコシステムから新しいパッケージを追加し続けながらもリリースサイクルを加速することができたのはBigtopのおかげです。 そのゴールのもとに、EMR 5.0は16のHadoopエコシステムプロジェクトをサポートしていて、その中にはApache Hadoop, Apache […]

Read More

AWS Application Discovery Service アップデート – VMware のエージェントレス検出

既存の環境を詳しく調べたり、状況の識別、そしてシステムやアプリケーションをクラウドに問題なく移行するために必要な情報と可視性を提供できるように設計された AWS Application Discovery Service については、今年すでにブログで紹介しました (詳しくは過去のブログ New – AWS Application Discovery Service – Plan Your Cloud Migration をご覧ください)。ブログで解説した検出プロセスでは、既存の各ホストで実行できる小規模で軽量なエージェントを使用しています。このエージェントはバックグランドで関連性のあるシステム情報を収集し、確認用にローカルで保管してからポート 443 の安全な接続状態で Application Discovery Service にアップロードします。この情報は AWS Key Management Service (KMS) が保護する暗号化したリポジトリで処理、相関、保管されます。仮想化環境で各ゲストオペレーティングシステムにエージェントをインストールすることは、計画上またはその他の理由により実践的とは言い難い場合があります。このエージェントは、広範に渡る Windows バージョンや Linux ディストリビューションで実行することができますが、過去にリリースされた Windows を使用していたり、Linux の稀なディストリビューションが混ざっている可能性は無視できません。 新しいエージェントレス検出 AWS Application Discovery Service のメリットを多くの AWS のお客様に提供するため、新しいエージェントレス検出オプションを本日リリース致しました。VMware vCenter 環境で仮想マシン (VM) を実行している場合は、この新しいオプションを使用して各ゲストにエージェントをインストールする必要なく、関連性のあるシステム情報を収集できます。代わりにオンプレミスアプライアンスを VCenter で読み込み、その中でゲスト VM を検出できるようにします。どのオペレーティングシステムを使用していても、vCenter アプライアンスはシステムパフォーマンス情報や、各 […]

Read More