Amazon Web Services ブログ

DynamoDB Accelerator (DAX) が正式にサービス開始しました

今年の初め頃 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 […]

Read More

AWS WAF 用のレートベースのルールでウェブサイトとサービスを保護

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 […]

Read More

新機能 – Amazon WorkSpaces 用のマネージド型デバイスの認証

では、ウェブおよびさまざまなデスクトップおよびモバイルデバイスから、クラウド上の仮想デスクトップにアクセスできます。この柔軟性により、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 が利用できるすべてのリージョンで利用できます。

Read More

AWS Mobile Hub で JavaScript 開発を改善する

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

Read More

7 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの岡本です。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 一同みなさまのご参加をお待ちしております。

Read More

Amazon EC2 スポットインスタンスを利用した Amazon ECSクラスターの起動

この記事は気前よく次の方から寄贈されました。 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戦略を選択した場合、リクエストで指定された最低価格のプールから取得されます。 […]

Read More

【開催報告】CTO Night 2017 Spring @ AWS Summit Tokyo

こんにちは。ソリューションアーキテクトの篠原英治(@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にて行いました。   […]

Read More

AWS が 7 年連続でガートナーのサービスとしてのインフラストラクチャ (IaaS) に関するマジッククアドラントでリーダーとして認定される

AWS での各製品計画セッションはお客様を中心に進められています。当社は最善を尽くしてお客様の声に耳を傾け、それに基づいて将来の開発のロードマップを構築しています。ロードマップの項目の約 90% はお客様のリクエストに基づくものであり、お客様から寄せられた特定のニーズや要件を満たすよう設計されています。 このお客様主導のイノベーションにより、7 年連続でガートナーのサービスとしてのインフラストラクチャ (IaaS) に関するマジッククアドラントで当社が「リーダー」クアドラントで最上位の地位を確保し、最も高い実行力と先見性のあるビジョンを持っていると評価されたものと確信しています。 詳細については、レポートの全文をお読みください。このレポートには多くの詳細が含まれており、お客様がクラウドプロバイダーを選ぶときに確認する機能や要素がよくまとめられています。

Read More

新機能 – Auto Scaling for Amazon DynamoDBについて

Amazon DynamoDBには幅広い業界やユースケースを含む10万人以上の多くのお客様がいます。 お客様は世界中の16の地域で、DynamoDBの一貫性のあるパフォーマンスを利用する事が出来ます。 最近の傾向は、DynamoDBを使用してサーバレスアプリケーションと組み合わせるお客様です。 この使い方は非常にマッチします:DynamoDBでは、サーバーのプロビジョニング、OSとデータベースのソフトウェアパッチ適用、または高可用性を確保するためのAZゾーン間のレプリケーションの設定などを考える必要はありません。テーブルを作成してデータを追加するだけでDynamoDBが処理するようにします。 DynamoDBにはプロビジョニングキャパシティーユニットモデルが用意されており、アプリケーションで必要とされる読み書き容量を設定できます。 これによりサーバの考え方から解放され、簡単なAPIコールまたはAWS Management Consoleのボタンをクリックしてテーブルのプロビジョニングを変更できるようになりましたが、多くのお客様はDynamoDBの容量をさらに簡単に管理できるように望んでいました。 本日、DynamoDBのAuto Scalingを導入して、テーブルとグローバルセカンダリインデックス(GSI)の容量管理を自動化できるようになりました。 維持をしたい使用率を指定し、読み書き容量の上限と下限を指定するだけです。 DynamoDBは、Amazon CloudWatchアラームを使用して消費量を監視し、必要に応じてプロビジョニングされた容量を調整します。 Auto Scalingは、すべての新しいテーブルとインデックスに対してデフォルトでオンに出来ます(但しIAM権限の事前準備が必要です)。また、既存のテーブルやインデックスに対しても設定できます。 あなたが常にマネジメントコンソールに張り付いていなくても、DynamoDB Auto Scalingはテーブルとインデックスを監視して、アプリケーショントラフィックの変化に応じて自動的にスループットを調整します。 これによりDynamoDBデータの管理が容易になり、アプリケーションの可用性を最大化しDynamoDBのコストを削減するのに役立ちます。 どのような機能か早速御覧ください。 Using Auto Scaling 新しいテーブルを作成するときに、DynamoDB Consoleにデフォルトパラメータセットが提示されるようになりました。 あなたはそのまま利用する事も、「Use default settings」のチェックを外して独自のパラメータを入力することもできます 独自にパラメータを設定する方法は以下の通りです。 Target utilizationは、消費容量とプロビジョニングされた容量の比率で表されます。 上記のパラメータは、読み取りまたは書き込み要求が増えた時でも消費される容量の2倍になるように十分な空き容量を確保します(DynamoDBの読み書き操作とプロビジョニングされた容量の関係の詳細については容量単位の計算を参照してください)。 プロビジョニングされた容量の変更は、バックグラウンドで行われます。 Auto Scaling in Action この重要な新機能が実際に動作するのを見るために、「Getting Started Guide」の指示に従いました。 私は、新しくEC2インスタンス起動し、AWS SDK for Pythonを設定(sudo pip install boto3)を実行し利用するための設定(aws configure)を行いました。 次に、PythonとDynamoDBのコードを使用していくつかのデータを含むテーブルを作成し、読み込みと書き込みの各容量を5ずつ手動で設定しました。 CloudWatchメトリクスで綺麗な直線を得るために私は急いで休憩を取ったので、AutoScalingの効果を示すことができました。 負荷を適用する前のメトリクスは次のとおりです。 私はステップ3のコードを変更して、1920年から2007年の範囲でランダムにクエリを発行し、1〜2分後に読み取りメトリクスを確認しました。 消費された容量はプロビジョニングされた容量よりも多く、その結果多くの読み込みリクエストに対してスロットルが発生します。 AutoScalingが実行される! […]

Read More

EC2 Run Command を使用した、SSH アクセスなしでの大規模なインスタンスの管理

Ananth Vaidyanathan (EC2 Systems Manager のシニア製品マネージャー) および Rich Urmston (Pegasystems のクラウドアーキテクチャのシニアディレクター) によって書かれた次のゲスト投稿は、EC2 Run Command を使用して、SSH を用いることなく EC2 インスタンスの大量のコレクションを管理する方法を示しています。 多くの場合、エンタープライズは管理対象環境および数千の Amazon EC2 インスタンスを持っています。Secure Shell (SSH) について悩むことなく、システムをセキュアに管理することが重要です。Amazon EC2 Systems Manager の一部である Run Command では、制御され管理可能な方法で、インスタンス (またはタグを使用してインスタンスのグループ) でリモートコマンドを実行できます。これは、Run Command サービスに毎日依存する Pega Cloud オペレーションにとって、生産性を向上するための優れた追加機能です。標準の IAM ロールとポリシーを通じた Run Command の制御、ドキュメントの定義による入力パラメーターの使用、コマンド出力を返すために使用される S3 バケットの制御が可能です。また、他の AWS アカウントや一般ユーザーとドキュメントを共有することもできます。全体として、Run コマンドは優れた一連のリモート管理機能を提供します。 SSH よりも優れる Run Command が SSH […]

Read More