Amazon Web Services ブログ

5月末〜6月頭に開催されたAWS Summit Tokyo 2017において、を実際にご利用頂いているお客様からの導入事例セッションとAWSからのTechセッションを合わせると、なんと11ものAmazon ECS関連セッションが行われました。Summit全体で130以上のセッションがありましたので、その中で10%程度がAmazon ECS関連だったということになります。Amazon ECSは、2015年4月にGA(東京リージョン含む)して以来、着実にお客様に導入を頂き、スタートアップからエンタープライズまで、新規システムだけでなくオンプレからの移行でも利用される標準的なサービスとなってきたことの表れかと思います。 この投稿では、それらのセッションを一気に見返せる様に情報を集約してお届けしたいと思います。これらの情報をご覧になって、Amazon ECSの利用をぜひご検討下さいませ。 導入事例トラック ナビタイムサービスにおける、Amazon ECS を活用したシステム移行　～『乗換NAVITIME』での移行事例 ～ 資料 [リコー] サービス全断はダメ、ゼッタイ。途切れないテレビ会議システムを目指して 〜AWS を最大限活用して可用性を高める秘策〜 資料 動画 クックパッドの機械学習を支える基盤のつくりかた 資料 動画 Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョブワーカーシステム (※株式会社インティメート・マージャー様事例) 資料 動画 [Intelligence] オンプレから移行するので、Amazon ECS でコンテナ化と Terraform でインフラコード化した話 資料 DAU 100 万人突破！ 急成長を支える Shadowverse のインフラ技術 資料 DMM における会員基盤プラットフォームへのAWS導入から活用事例の紹介 資料 動画 [ABEJA] IoT / Bigdata / AI […]

Amazon Redshift Spectrum を使うことで、Amazon S3 に置かれたデータに対して Amazon Redshift の SQL クエリを走らせることができます。つまり Redshift Spectrum によって、データウェアハウスのローカルディスク内に保存されたデータ以外に対しても、Redshift の分析を拡張できるようになるのです。S3 の “データレイク” に貯まった大量のデータに対して、面倒で時間のかかる抽出・変換・ロード（ETL）処理を行うことなく、クエリを投げることができます。Redshift Spectrum は洗練されたクエリ最適化を用いて、数千ものノードにまでスケールして高速に処理を行います。 このブログポストでは、Redshift Spectrum の 10 の重要なベストプラクティスについて、いくつかのカテゴリにわけてご紹介します。 このガイドラインは、Redshift をお使いのお客さまとの多くのやりとりや、直接的なプロジェクトに基づいて作られています。 Amazon Redshift vs. Amazon Athena AWS のお客さまは、私たちによく「Amazon Athena と Amazon Redshift Spectrum について、どう使い分けをすればよいのでしょうか？」と尋ねます。 Amazon Athena の利用シーン Athena は S3 に置かれたデータに対して、SQL によるインタラクティブなアドホッククエリを投げるといったユースケースに向いています。Athena はサーバーレスアーキテクチャなので、クエリを投げるためにクラスタを立ち上げる必要はありません。クエリごとにスキャンした S3 のデータ量に基づいて料金が発生します。データを圧縮、パーティショニング、または列指向フォーマットに変換することにより、費用を節約しつつ優れたパフォーマンスを得ることができます。JDBC に対応しているすべての BI ツールや SQL […]

データウェアハウスのワークロードは多様性で知られています。これは、季節性や、往々にして高コストになりがちな探索的クエリー、SQL開発者のスキルレベルのばらつきなどによるものです。 Amazon Redshiftワークロード管理機能（WLM）を用いて優先度やリソース使用量を柔軟に管理することで、極めて多様なワークロード環境でも高い性能を得ることが可能となります。WLMによって、短時間で完了するクエリーが長時間実行されるクエリーのせいでキューに滞留するような状況を避けることができます。にも拘わらず、あるクエリーが不釣り合いな量のリソースを独占し、システム内のその他のクエリーを圧迫することが依然として起こり得ます。こうしたクエリーは、一般にrogue queryやrunaway queryと呼ばれます（訳者註：rogueはならず者、面倒を起こすといった意味、runawayは暴走の意で、ここでは一方的にリソースを占有し他のクエリーに影響を及ぼすクエリーを指します） WLMは、メモリー使用量を制限し、タイムアウトを用いてクエリーを別のキューに移動させる機能を持ちますが、ずっと粒度の細かいコントロールができることが望ましいことは論を俟ちません。クエリーモニタリングルールを用いて、リソース使用量のルールを作成し、クエリーのリソース使用量を監視し、それらがルールを犯した時のアクションを決めることが可能になりました。 ワークロード管理における同時並列性とクエリーモニタリングルール Amazon Redshift環境では、単一クラスターに対し最大500まで同時接続することができます。性能指標であるスループットは一般に一時間あたりのクエリー数として表現されますが、MySQLのような行指向データベースであれば、同時接続数を増やすことによってスケールします。Amazon Redshift環境では、ワークロード管理（WLM）によって、同時接続数とは異なる方法でスループットを最大化します。WLMは二つの部分があります。キューと同時並列性です。キューはユーザーグループまたはクエリーグループのレベルでのメモリー割り当てを可能にします。同時並列性（またはメモリースロット）は、この割り当てをさらにどのように分割し、個々のクエリーにメモリーを割り当てるかを制御します。 例えば、同時並列性10の1つのキューがある（メモリー割り当て100％）と仮定しましょう。これは、個々のクエリーは最大10%のメモリーの割り当てを受けることを意味します。もしクエリーの大半が20%メモリーを必要とした場合、これらのクエリーはディスクにスワップアウトし、スループットの劣化をもたらします。しかし、もし同時並列性を5に下げた場合、個々のクエリーは20%のメモリー割り当てを受けることができるため、トータルのスループットは高くなり、SQLクライアントへのレスポンスも全体的に高速になります。高い同時並列性がよりよいパフォーマンスに繋がると考えてしまうことは、行指向のデータベースを列指向に切り替える時に陥りがちな典型的な落とし穴の一つです。 同時並列性について理解したところで、クエリーモニタリングルールについて掘り下げていきましょう。リソース使用量に基づくルールと、それに違反した場合に取るアクションを定義します。当該クエリーによるCPU使用量、クエリー実行時間、スキャンされた行数、返された行数、ネステッドループ（Nested loop）結合など、12の異なるリソース使用量メトリクスを利用できます。 それぞれのルールは最大3つの条件（述語）と、一つのアクションを持ちます。 述語は、メトリック、比較演算子（=、<または>）、値で構成されます。あるルール内の全ての述語がマッチすると、そのルールのアクションがトリガーされます。ルールアクションには、ログ（記録）、ホップ（次のキューへの移動）、アボート（終了）があります。 これにより、はた迷惑なクエリーを、より深刻な問題が出来する前に捕捉することが可能になります。ルールはアクションをトリガーしてキューを解放し、スループットと応答性を改善します。 例えば、短時間実行クエリー専用のキューのために、60秒を超えて実行し続けるクエリーをアボートするルールを作ることができます。設計のよくないクエリーを追跡するために、ネステッドループを含むクエリーを記録する別のルールを作ることもできます。Amazon Redshiftコンソールには、簡単に始められるよういくつかのテンプレートが事前定義されています。 シナリオ クエリーモニタリングルールを使って、単純なロギングからクエリーのアボートまで、幅広いクエリーレベルアクションを行うことができます。また、全てのアクションはSTL_WLM_RULE_ACTIONテーブルに記録されます。 ログ（LOG）アクションは、情報を記録した上でクエリーの監視を継続します。 ホップ（HOP）アクションは、クエリーを中断し、次に合致するキューで再起動します。 もし合致するキューがない場合、当該クエリーはキャンセルされます。 アボート（ABORT）アクションは、ルールに違反したクエリーをアボートさせます。 それでは、以下の三つのシナリオを用いて、クエリーモニタリングルールをどのように使うかを見ていきましょう。 シナリオ1：アドホッククエリーに潜む非効率なクエリーを制御するには？ 二つの大きなテーブルを結合するようなクエリーは、何十億、あるいはそれ以上の行を返す可能性があります。十億行を超える行を返すクエリーをアボートさせるルールを設定することで、アドホッククエリーの安全性を担保することができます。このルールは、論理的には以下のようになります。 IF return_row_count > 1B rows then ABORT 以下のスクリーンショットの設定では、十億行を超える行を返すBI_USERグループ内のクエリーはすべてアボートします。 シナリオ 2： 非効率で、CPUインテンシブなクエリーを制御するには？ CPUスパイクをもたらすクエリーが、必ずしも問題というわけではありません。しかし、高いCPU使用量と長いクエリー実行時間を併せ持ったクエリーは、実行中の他のクエリーのレイテンシーを悪化させます。例えば、高いCPU使用率を示し続ける非効率なクエリーが長時間実行されている場合、それは誤ったネステッドループ結合のせいかも知れません。 こうしたケースでは、10分間にわたって80%以上のCPU使用率を示しているクエリーをアボートさせるルールを作成することで、クラスターのスループットと応答性を上げることができます。このルールは、論理的には以下のようになります。 IF cpu_usage > 80% AND query_exec_time > 10m then ABORT 以下のスクリーンショットの設定では、10分間にわたってCPU使用率が80%を超えているクエリーはすべてアボートします。 80%以上のCPU使用率を5分以上続けるクエリーを記録し、10分以上続いた場合はアボートするよう、ルールを拡張することもできます。このルールは、論理的には以下のようになります。 IF cpu_usage > […]

今年の初め頃 Amazon DynamoDB Accelerator（DAX）について紹介をしました。DAXはフルマネージドのキャッシュサービスでDynamoDBテーブルの前段（論理的に）に置かれます。DAXはキャッシュされたデータに対するリクエストをマイクロ秒単位で返すため、読み込みワークロードに最適です。DAXはアプリケーションコード内ではDynamoDB APIと互換性を保つ様にサポートしており、シームレスで使いやすいようにデザインしています。管理することはDAXクラスタを作成して既存の読み取りと書き込みのターゲットとして使用するだけです。パッチ適用、クラスタメンテナンス、キャッシュデータの複製、または障害管理について心配する必要はありません。 本日から利用可能 今日DAXが正式に利用可能になったことをお知らせします。DAXが利用可能なAWSリージョンを追加拡張し、プレビューの期間にパフォーマンスと可用性をチューニングしました。 5つのリージョンで利用可能 – 現在 DAXはUS East (Northern Virginia)、EU (Ireland)、US West (Oregon)、Asia Pacific (Tokyo)、US West (Northern California) の5つの地域で利用可能です。 In Production – プレビュー期間内にDAXを本番で使用しているユーザーもおり、DAXをアプリケーションに追加するのが楽で今ではアプリケーションの速度が10倍速くなってたという声を頂いています。 Getting Started with DAX 以前の記事(翻訳版はこちら)で紹介したように、DAXを使用して既存のDynamoDBアプリケーションを高速化するのは簡単です。必要なリージョンにDAXクラスタを作成し、 DAX SDK for Javaを利用するようにアプリケーションを更新します（コード内の呼び出し方は同じですが、ライブラリの置き換えを行う事です）。SDKを構成してクラスタにエンドポイントを使用するようにします。リードスルー/ライトスルーキャッシュとして、DAXはすべてのDynamoDB読み取り/書き込みAPIをシームレスに処理します。 私たちは他の言語のSDKのサポートも取り組んでおり、利用可能になった時点で追加情報を共有します。 価格について US East (Northern Virginia) と US West (Oregon) の各地域で、時間あたり$ 0.269から始まる料金 でクラスター内の各ノード（詳細については、 DynamoDBの価格を参照）を1時間単位でお支払いいただきます。DAXでは、クラスタ内の各ノードが高可用性のための読み取りターゲットおよびフェールオーバーターゲットとして機能します。DAX SDKはクラスタを認識しており、クラスタ内のすべてのノードに対してラウンドロビンで要求を発行し、クラスタのキャッシュリソースを最大限に活用できるようにします。 DAXは読み取りトラフィックの急激な急上昇を容易に処理できるため、テーブルのプロビジョニングされたスループットの量を減らすことができ、結果としてマイクロ秒で結果を返しながら全体のコストを削減できます。 最後にAmazon.comのCTOであるWerner Vogelsが書いたブログを紹介させて頂きます。 Amazon DynamoDB […]

AWS WAF (ウェブアプリケーションファイアウォール) は、悪質または不正なリクエストに関与する様々なタイプのアプリケーションレイヤー攻撃からアプリケーションを保護するために利用できます。このサービスについて説明したブログ (「新しい AWS WAF について (New – AWS WAF)」でもお見せしましたが、クロスサイトスクリプティング、IP アドレス、SQL インジェクション、サイズ、コンテンツ制約に見合うルールを定義できます。 受信リクエストがルールと一致すると、アクションが呼び出されます。アクションは許可やブロックを実行したり、単にマッチ数をカウントすることができます。既存のルールモデルはパワフルかつ様々な種類の攻撃を検出し対応することができます。ただし、特定の IP アドレスから送られた有効なリクエストが大量に送信されただけのケースでは、攻撃として対応することはできません。こうしたリクエストはウェブレイヤーの DDoS 攻撃や総当たりのログインの試行、もしくはパートナー統合で不具合があった場合の可能性があります。 新しいレートベースのルール 本日、WAF にレートベースのルールを追加しました。これにより、ブラックリストへの IP アドレスの追加または削除を管理できるようになり、例外や特別なケースに対応できる柔軟性も提供します。IP アドレスをブラックリストに追加 – 設定済みのしきい値を超える速度でリクエスト数を送信した IP アドレスをブラックリストに追加することができます。IP Address のトラッキング– どの IP アドレスがブラックリストに追加されているか見ることができます。IP Address の削除 – ブラックリストに追加された IP アドレスは、設定済みのしきい値を超える速度でリクエストを送信しないようになれば自動的にリストから削除されます。IP Address の例外 – 特定の IP アドレスをブラックリストの対象外として設定することができます。その場合はレートベースのルール内にある IP アドレスのホワイトリストを使用してください。たとえば、自分のサイトに信頼できるパートナーが高速でアクセスできるように許可したい場合もあるでしょう。モニタリングおよびアラーム発行 – 各ルールに発行した CloudWatch メトリクスでモニタリングしたりアラーム発行をすることができます。新しいレートベースのルールと WAF の条件を組み合わせて高度なレート制限戦略を取り入れることもできます。たとえば、レートベースのルールやログインページと一致する WAF […]

では、ウェブおよびさまざまなデスクトップおよびモバイルデバイスから、クラウド上の仮想デスクトップにアクセスできます。この柔軟性により、WorkSpaces はユーザーが自己所有しているデバイス (BYOD または Bring Your Own Device とも呼ばれます) を使用できる環境に最適です。このような環境では、組織は WorkSpaces にアクセスできるデバイスを管理する機能を必要とする場合があります。たとえば、コンプライアンスまたはセキュリティポリシー要件を満たすため、クライアントデバイスのオペレーティングシステム、バージョン、またはパッチレベルに基づいてアクセスの制御が必要になる場合があります。 マネージド型デバイスの認証 本日、WorkSpaces 用のデバイス認証の提供を開始します。これにより、デジタル証明書を使用して、Apple OSX および Microsoft Windows からのクライアントアクセスを管理できるようになりました。また、iOS、Android、Chrome OS、ウェブ、およびゼロクライアントデバイスからのアクセスを許可またはブロックする選択もできます。ポリシーを実装して、許可するデバイスタイプとブロックするデバイスタイプを、パッチレベルまで管理できます。アクセスポリシーは、各 WorkSpaces ディレクトリに対して設定されます。ポリシーの設定後、クライアントデバイスから WorkSpaces への接続リクエストが評価され、ブロックまたは許可されます。この機能を利用するには、Microsoft System Center Configuration Manager またはモバイルデバイス管理 (MDM) ツールを使用して証明書をクライアントデバイスに配布する必要があります。WorkSpaces コンソールからアクセスコントロールオプションを設定する方法を次に示します。 クライアントが接続を許可されていない場合は、次のようになります。   今すぐ利用可能 この機能は、WorkSpaces が利用できるすべてのリージョンで利用できます。

はじめに JavaScript エコシステムが成長していくなかで、私達はモバイルおよびハイブリットアプリを構築するお客様を支援する取り組みを続けています。本日、 AWS Mobile Hub に Hosting and Streaming 機能をリリースしました。この機能は、Amazon S3 と Amazon CloudFront を使用するモバイル Web サイトのテスト及びプロダクション環境へのデプロイを自動化します。また、標準設定ファイルと SDK を使用する際の設定ワークフローを簡略化します。 この新しい機能によって、 JavaScript 開発者は事前設定された AWS アーキテクチャを起動したり、 Mobile Hub プロジェクトをビルドできます。また、集中管理された設定と事前ダウンロードされた SDK を使用して、ワンクリックでグローバル Web サイトを作成できます。

こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー 7 月の配信についてご案内させて頂きます。今月はAmazon Connect, AWS Shield, AWS Step Functions と Black Belt 初開催となるサービスの紹介が多く予定されておりますので、是非とも最新情報の習得にお役立ていただければと思います。またその他にも AWS Lambda, AWSの運用監視といった実用的な技術情報をお届けいたします。 サービスカット 7/5(水) 18:00-19:00 Amazon Connect 7/18(火) 12:00-13:00 AWS Shield   ※ 通常の開催日時と異なりますのでご注意ください 7/19(水) 18:00-19:00 AWS Lambda 7/26(水) 18:00-19:00 AWS Step Functions ソリューションカット 7/25(火) 12:00-13:00 Monitoring on AWS -AWS運用監視- お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。

この記事は気前よく次の方から寄贈されました。 Chad Schmutzer Solutions Architect Shawn O’Connor Solutions Architect   本日、Amazon EC2 Container Service(Amazon ECS)が、ECSコンソール上から直接 Amazon EC2 Spot Instances上に ECSクラスターを起動させる機能をサポートする事を発表しました。 スポットインスタンスを利用すると、Amazon EC2の余剰コンピュートキャパシティに入札することが出来ます。スポットインスタンスは通常、オンデマンドインスタンスよりも50-90%安い価格です。スポットインスタンス上でECSクラスターを起動することで、既存のコンテナ化されたワークロードの実行コストを削減したり、同じ予算を維持しながら、コンピュートキャパシティを2倍から10倍に増やすことが可能です。もしくは、その両方を実現することもできます！ スポットインスタンスを利用する場合、インスタンス時間あたりに支払う価格を指定します。現在のスポットプライスを上回る価格で入札している間、スポットインスタンスは起動します。スポットプライスの上昇によりインスタンスが回収された場合、インスタンスが実行された分の時間は請求されません。 ECSコンソールはスポットインスタンスをデプロイするために、 Spot Fleetを利用します。Spot Fleetは、利用者にとって最も良い価格となる様にスポットインスタンスを起動し、コンテナ化したアプリケーションの為にリクエストしたターゲットキャパシティ(インスタンスやvCPUの数で表現される)をデプロイしようします。スポットプライスや、空き容量の変化によってスポットインスタンスが回収された場合、Spot Fleetはターゲットキャパシティを維持しようとします。 コンテナはSpot Fleetが大きくなる多様なリソースプールに適してします。Spot Fleetを利用すると複数のスポットインスタンスプール(インスタンスタイプとアベイラビリティゾーンの組み合わせ)に渡ってキャパシティをプロビジョニング出来き、アプリケーションの可用性を向上させ、時間経過と共に運用コストを削減できます。ECSが提供する拡張性と柔軟性を備えたコンテナ配置システムとSpot Fleetとの組み合わせはコンテナ化されたワークロードを効率的にデプロイし、わずかなコストであらゆる規模のクラスタを容易に管理できます。 従来は、スポットインスタン上へのECSクラスタのデプロイは手動で行われてました。この記事では、ECSコンソール上からのSpot Fleetとの新しいインテグレーションによって、高い可用性とスケーラビリティをどの様に実現し、コンテナ化したワークロードをどの様にコストを削減するのかを紹介します。また、AWS　CloudFormationを利用し、スポットインスタンス上にECSクラスターを構築する方法も紹介します。   スポットインスタンスで実行するECSクラスタの作成 AWS マネージメントコンソールを利用してECSクラスタを作成することが可能です。 Amazon ECSコンソールを開きます。 https://console.aws.amazon.com/ecs/ ナビゲーションパネル上でClustersを選択します。 Clustersページでは、Create Clusterを選択します。 Cluster nameに名前を入力します。 インスタンス設定では、プロビジョニングモデルとしてSpotを選択します。 配置戦略の選択 2つの利用可能なSpet Fleet配置戦略はDiversified戦略かLower price戦略です。 Spot Fleetで選択した配置戦略は、利用可能なスポットインスタンスプールからSpot Fleetをどの様に満たすかを決定します。diversified戦略を使用すると、スポットインスタンスは全てのプールにわたって分散されます。lowest price戦略を選択した場合、リクエストで指定された最低価格のプールから取得されます。 […]

こんにちは。ソリューションアーキテクトの篠原英治(@shinodogg)です。 Amazon.comのCTOであるWerner Vogels(@werner)の3年振りの来日に伴いまして、AWS Summit Tokyoの期間中に、日本の著名なCTOの皆さまにお集まりいただき、 CTO Night 2017 Spring (#CTONight) を開催しました。     ■ CTOs Round Table   少人数の日本のCTOの皆さまをお招きし、AmazonのCTOとしてAmazonのイノベーションをリードするWernerとラウンドテーブル形式で最新の技術動向についてディスカッションを行いました。   Wernerから、AmazonがAWSというクラウドビジネスを始めたことで、1テクノロジー企業から、テクノロジープロバイダーとなり、CTOとしてどのように全社のテクノロジーをドライブしてきたか？といったトピックからはじまり、Wernerのブログ(Working Backwards – All Things Distributed)でも詳細に解説されている、新しくサービス/プロダクト/機能を開発する際にAmazon社内で取られている方法論など、白熱した議論が展開されました。   ビジネスやサービスが多岐に渡るようになるにつれ、技術的なキャッチアップが困難になり、CTOとしてどのようにそれに取り組むべきか？というトピックに関しては、Werner自身は週4-6時間はメールやミーティングなどを一切シャットアウトして集中してハンズオンで新しい技術を習得しており、そこで得たものをコードレビューやプロダクトチームとのディスカッションに活かしている、とのことでした。CTOが社内で取り扱う全ての技術分野の専門家になることは厳しい部分があるものの、エンジニアチームを、進化する同じ船に乗せるといった意味で開発者と会話をする際の姿勢などについて、日本のCTOの皆さまのエピソードもご紹介いただきました。   プログラミング言語を選定する上での考え方や、サーバーのroot権限をCTO自らが持つべきか？など様々なトピックに関するディスカッションはあっという間に時間が経過し、Werner自身も非常に有意義だったと申しておりました。ご参加いただいたCTOの皆さまありがとうございました！     ■ Startup CTO Night with Amazon CTO – Werner Vogelsによる公開技術レビュー   2014 年 7 月にシークレットイベントとして開催され大盛況だったWernerによる 『Startup CTO Night with Amazon CTO』を3 年ぶりにAWS Dev Day Tokyoにて行いました。   […]