Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

Amazon ECSイベントストリームで、クラスタの状態を監視

今までは、実行中のAmazon ECSクラスタの状態の更新を取得するためには、AWS CLIやSDKを使ってコンテナインスタンスとタスクの状態を定期的にポーリングする必要がありました。新しいAmazon ECSイベントストリーム機能によって、これからはAmazon ECSのタスクとコンテナインスタンスの状態更新を準リアルタイムにイベント駆動で受け取ることが可能になりました。イベントはAmazon CloudWatch Eventsを通して配送され、AWS Lambda関数やAmazon SNSトピックといった、あらゆるCloudWatch Eventsのターゲットに向けることができます。 この記事では、簡単なサーバレスアーキテクチャを作って、イベントストリームの更新を受け取り、処理し、そして保存する方法をお見せします。まず最初にLambda関数を作成し、入ってきた全てのイベントをスキャンして実行中のタスクに関連したエラーが無いかを探し、もしあれば即座にSNSの通知を送ります。その後、関数は全てのメッセージをAmazon Elasticsearch Serviceを使ったElasticsearchのクラスタにドキュメントとして保存することで、皆さんや開発チームの方がKibanaのインタフェースを通じてクラスタの状態を監視したり、ユーザから報告された問題に返答するための診断情報を検索することができます。

Read More

Auto Scalingを利用して、Amazon EMRのアプリケーションを動的にスケールする

Apache SparkやPresto、Apache Hadoopエコシステムを利用しているお客様は、ワークフローの完了次第クラスターを終了させることや、安価なAmazon EC2スポットインスタンスを利用してクラスターをリサイズをすることよってコスト節約するために、Amazon EMRの弾力性を活用しています。例えば、お客様は日次のETLや機械学習処理のためにクラスターを作成し、それらの処理が完了したらクラスターを終了させるということや、BI分析者がアドホックでレイテンシーの低いSQLをAmazon S3に置かれたデータに対して行えるよう、業務時間帯のみPrestoクラスターをスケールアウトする、ということが可能です。 Amazon EMRリリース4.xと5.xで新しくサポートされたAuto Scalingによって、お客様は、クラスターのノードを、より簡単に追加(スケールアウト)や削除(スケールイン)できます。スケーリングの動作は、EMRから提供される5分間隔のAmazon CloudWatchメトリクスによって、自動的にトリガーされます。トリガーになるメトリクスには、メモリ利用、未実行アプリケーションの状態、HDFS利用、に関連するいくつかのYARNメトリクスも含まれます。 EMRリリース5.1.0には、2つの新しいメトリクスが導入されました。YARNMemoryAvailablePercentageとContainerPendingRatioです。これらは、Apache SparkやApache Tez、そして、Apache Hadoop MapReduceのような、スケーラブルなYARNベースのフレームワーク向けの、クラスターの利用状況を知るのに便利なメトリクスです。さらに、お客様は、カスタムCloudWatchメトリクスをAuto Scalingポリシーに利用することもできます。 以下は、最大40・最小10インスタンスで、一度に1インスタンスずつ増減する、インスタンスグループに対するAuto Scalingポリシーの例示です。インスタンスグループは、YARN内の利用可能なメモリが15%を下回ると、スケールアウトし、75%を上回るとスケールインします。また、インスタンスグループは、割り当てられているYARNコンテナに対するYARNコンテナの未実行率が0.75になった場合も、スケールアウトします。 さらに、お客様は、EMR 5.1.0のクラスターによってノードが終了される際に、スケールダウンの振る舞いを設定することができます。デフォルトで、EMRは、いかなるタイミングで終了リクエストが投げられたとしても、インスタンス時間単位の境目に実施されるスケールインイベントの最中のみ、ノードの停止を行います。これは、EC2は、いつインスタンスを終了したかに関わらず、時間単位で請求をするためです。この振る舞いによって、クラスター上で実行されているアプリケーションは、コスト効率をより高く、動的にスケールする環境で、インスタンスを利用することができます。 反対に、5.1.0より前のEMRリリースでは、お客様は、以前のデフォルト設定を利用できます。インスタンス時間単位の境目に近接しているかどうかを考慮せず、ノードを終了する前に、ノードをブラックリストしたり、タスクを排出したり、ということが可能です。いずれの振る舞いにおいても、EMRは、まず最も動きの少ないノードを削除しますし、HDFSの不整合を招き得る場合は、終了処理をブロックします。 EMRコンソール、AWS CLI、または、AWS SDKのEMR APIを利用して、Auto Scalingポリシーの作成や変更ができます。Auto Scalingを有効にするためには、Auto Scalingで容量の追加・削除を行うための権限を付与すべく、追加のIAMロールをEMRに与える必要があります。さらに詳細な情報は、Amazon EMRでのAuto Scalingを確認して下さい。また、もし、EMRでのAuto Scalingに関して、ご質問や公開したい面白い事例などございましたら、コメントを下に書いていただければと存じます。 原文: Dynamically Scale Applications on Amazon EMR with Auto Scaling (翻訳: 半場 光晴)

Read More

Amazon Auroraを開発・テストワークロードでご利用しやすいT2.Medium DBインスタンスクラスをリリース

Amazon Auroraは既にdb.r3.large (2 vCPUs, 15 GiB RAM) から db.r3.8xlarge (32 vCPUs 244 GiB RAM)まで5つのインスタンスクラスをご提供していました。これらのインスタンスは非常に多くのプロダクション環境やアプリケーション向けのユースケースをサポートしています。 今日、 db.t2.medium DB インスタンスクラス (2 vCPUs, 4 GiB RAM)の6つ目の選択肢を追加致しました。通常時、このインスタンスクラスではシングルコアの40%のパフォーマンスを利用することが可能で、CPUを利用するクエリやデータベースタスクを実行する場合コアのフルパフォーマンスまでバーストをします。同名のEC2インスタンスの様に、この新しいインスタンスクラスはCPUクレジットを持っており、CPUが多く使われている場合は消費し、そうでない場合はCPUクレジットを蓄積します。(バースト可能な性能を持つ新しい低コストEC2インスタンスで詳細を説明しています) db.t2.mediumは多くの開発・テスト環境に最適です。また、負荷の少ないプロダクションワークロードにも利用出来ます。CPUCreditUsageとCPUCreditBalance メトリクスを監視することでCPUクレジットの利用や蓄積を確認することが出来ます。 本日からご利用いただけます 新しいインスタンスクラスを使ったAmazon Auroraデータベースは本日から起動頂けます。Amazon Auroraが利用出来る全リージョンで利用可能です。1時間あたり$0.082(N.Virginiaリージョンの場合)からご利用頂けます。 —Jeff; (翻訳は星野が担当しました。原文はこちら)

Read More

最良のアーキテクチャ、バックワードアプローチを通して前進する

同僚の Philip “Fitz” Fitzsimons は次のゲストポストであの名高い最良アーキテクチャフレームワークに読者を招待します。 — Jeff; バックワードアプローチは私たちのイノベーションプロセスにとても重要な作業です。カスタマーからスタートして何を求めているかを探り、定義付けすることで、取り組みの方向を決めます。2015 年に優れた設計のフレームワークを発表し、そのなかで投稿されたブログ「優れた設計を導入していますか?」で、フレームワークを改善するためのカスタマーからのフィードバックに耳を傾けました。実施したいくつもの改善策のなかでもまず、AWS ソリューションアーキテクトによって集められた数千のレビューの指摘を基にフレームワークを更新しました。また、クラウド上での作業方法についてのさらなるガイダンスを希望するカスタマーに回答する形で、フレームワークに第5番目の柱である運用性へのベストプラクティスの取得を加えました。すべての柱は次のようになります: セキュリティ – リスクの評価と軽減戦略を通して、ビジネス価値を提供しながら、情報、システム、資産を保護する能力です。 信頼性 – インフラストラクチャまたはサービスの障害から復旧したり、必要に応じて動的にコンピューティングリソースを獲得したり、設定ミスや一時的なネットワークの問題などによる障害を軽減したりといったシステムの能力です。 パフォーマンス効率 – システムの要求に合わせてコンピューティングリソースを効率的に使用し、需要の変化や技術の進歩に合わせてこの効率を維持する能力です。 コストの最適化 – 不要なコストや最適でないリソースを回避または排除する能力です。 運用性 – ビジネスの価値をもたらし、サポートプロセスと手順の継続的な向上を実現するために、システムを実行およびモニタリングする能力です。 AWS の最良アーキテクチャのフレームワークホワイトペーパーは、クラウド上の設計についてどのように捉えるかに観点を置いています。このホワイトペーパーでは、柱を達成するベストプラクティスを説明し、ベストプラクティスに見合う行動を取れていることの判断に役立つ自由回答形式の質問集を提供しています。これに加えて、クラウド上で設計する方法についてのアドバイスがもっと具体的であることを希望するカスタマーの声に対応して、それぞれの柱を背景とするクラウドネイティブアーキテクチャの設計方法に対する具体的なアドバイスを含むホワイトペーパーシリーズを作成しました。以上のホワイトペーパーは、最良アーキテクチャへの新しいホームから閲覧でき、私たちの最新の視点についてご覧いただけます。また、最良アーキテクチャの導入に役立つように、無料オンライントレーニングを始めました。AWS 最良アーキテクチャトレーニングコースは、AWS の優れた設計フレームワークとその 5 本の柱を深い理解を提供できるようにデザインされています。バックワードアプローチを通してカスタマーにとって最良のサービスを構築していくことができると信じています。最良アーキテクチャの真髄を表明するベストプラクティスを提供することで、カスタマーのビジネス前進に役立てていきます。– Philip Fitzsimonsリーダー、AWS 最良アーキテクチャチーム

Read More

AWS Mobile Hub を使用したエンタープライズモバイルアプリの構築 – 新規ユーザーの管理と SaaS 統合

AWS Mobile Hub を使用すると、AWS のサービスを使用したモバイルアプリケーションの構築、テスト、モニタリングが可能になります。単独の組み込みコンソールを使用して、ユーザー認証、データストレージ、バックエンドロジック、プッシュ通知、コンテンツ配信、分析機能をアプリに追加できますし、カスタマイズの機会も十分にあります。私たちは、エンタープライズモビリティで課題を抱える開発者の数が増え続けているのを見てきました。彼らは、既存のデスクトップアプリと同じくらいパワフルで、柔軟性が高く、安全な B2C (business to consumer) および B2E (business to employee) アプリケーションを構築したいと考えています。また、既存の企業ユーザーディレクトリを使用し、既存の CRM、セールス管理、経理、カスタマーサービス用ツールを利用したいとも考えています。本日、Mobile Hub が新しく SaaS 統合機能をサポートするように拡張されました。上記のようなタイプのアプリを構築している開発者の方々には特に興味を持っていただけると思います。これらの新機能は、最近リリースされた、AWS Lambda 関数と Amazon API Gateway エンドポイントを使用してアプリケーションに拡張クラウドロジックを追加しカスタムコネクターを構築するサポートのフォローアップです。どちらの機能も、最近リリースされたエンタープライズユーザー管理機能と一緒に機能し、アプリユーザーを認証します。 エンタープライズユーザー管理 B2C および B2E アプリへのユーザー認証の追加が簡単になる新機能を最近追加しました。B2C 側では Amazon Cognito に独自のフルマネージドディレクトリを作成し、多要素認証 (MFA) を含むサインアップおよびサインイン機能を追加できます。B2E 側では、ユーザーが既存の社内認証情報を使用してサインインするようにできます。この機能は SAML (セキュリティアサーションマークアップランゲージ) を利用し、Active Directory を含む複数のディレクトリと連携します。詳細は、Introducing Mobile Hub User Authentication Using SAML Federation or Email and Password Sign-in […]

Read More

アプリケーションパフォーマンスのパーセンタイルと AWS アプリケーションロードバランサーへのリクエストのトレース

本日のゲストポストでは、同僚の Colm MacCárthaigh が新しいCloudWatch パーセンタイル統計およびロードバランサーの意味と利点について語ります。 また、個別のリクエストがロードバランサーに到着した時点からその進行を追跡でき、そのリクエストがアプリケーションに繋がるための新しいリクエストのトレース機能も紹介します。 — Jeff; アプリケーションパフォーマンスのパーセンタイルメトリクス AWS Elastic Load Balancer はすでに以前から Amazon CloudWatch メトリクスに含まれ、ロードバランサーのバックグラウンドで実行しながらインスタンスとソフトウェアのヘルス状態とパフォーマンスの可視化を提供します。たとえば、ELB はアプリケーションに送られたすべてのリクエストが負荷分散される応答時間を測定します。多くのカスタマーはアプリケーションのパフォーマンスを監視するために、ビルトインの平均と最大レイテンシーメトリクスを使用しています。また、インスタンスやコンテナを負荷の変動として追加や削除するためのきっかけとしてこういったメトリクスを使用することも一般的です。新しい CloudWatch パーセンタイルサポートに基づき、ELB Classic and Application Load Balancer(ALB) はアプリケーションの応答時間によりきめ細かなデータを提供します。こういった測定により範囲内のパフォーマンスをより正確に掴むことができます。たとえば、10 番目のパーセンタイルが 2 ミリ秒とすると、10% のリクエストは 2 ミリ秒以下かかることになり、99.9 番目のパーセンタイル値が 50 ミリ秒とすると、99.9% のリクエストは 50 ミリ秒以下かかっているという具合です。 パーセンタイルがどれだけ役に立つかという現実的な例としては、ほとんどのリクエストを 1 から 2 ミリ秒で高速キャッシュから処理するアプリケーションの場合、キャッシュが空になるとリクエストの処理はさらにずっと遅くなり、100 ミリ秒 から 200 ミリ秒の範囲までも落ちてしまいます。従来の最大メトリクスでは 200 ミリ秒台の最低速の案件のみが反映され、平均には高速と低速の回答が混合して示されることになり、どれだけのリクエストが高速または低速で処理され、そしてそれぞれがどれだけの速度であったかについての詳細はほとんど提供されませんでした。パーセンタイルメトリクスは、アプリケーションのパフォーマンスをリクエストの範囲を通して映し出し、より分かりやすい情報を提供します。パーセンタイルのメトリクスはアプリケーションに対してより有意義で積極的なパフォーマンスとして使用できます。たとえば、99番目のパーセンタイルを Auto Scaling のトリガーあるいは CloudWatch アラームとして使用すると、スケーリングのターゲットを設定できるために十分なリソースが提供されて 1% […]

Read More

AWS の値下げ – CloudWatch メトリクスの料金

2011 年と同じに 私は CloudWatch 用のカスタムメトリクスと、お客様のアプリケーションやスクリプトからそれらのメトリクスを発行する方法について説明しました。そのときに、最初の 10 個のカスタムメトリクスは無料で、追加のメトリクスは、発行したメトリクスの数にかかわらず、1 か月あたり、1 メトリクスあたり 0.50 USD でした。本日は、CloudWatch メトリクスの料金変更と数量割引について発表いたします。毎月お客様が発行するメトリクスの数に基づいて、最大 96% の節約を実現できます。US East (Northern Virginia) リージョンの新料金を次に示します (最初の 10 個のメトリクスは引き続き無料です)。 階層 下限 上限 1 か月あたり、1 メトリクスあたりの料金 現在の料金に対する割引率 最初の 10,000 メトリクス 0 10,000 0.30 USD 40% 次の 240,000 メトリクス 10,001 250,000 0.10 USD 80% 次の 750,000 メトリクス 250,001 1,000,000 0.05 USD 90% 残りの全メトリックス 1,000,001 […]

Read More

AWS ストレージの更新 – S3 と Glacier の値下げ + Glacier に追加された取得オプション

2006 年に、S3 のサービスを画期的な従量課金制 (月額 15 セント/GB の初期料金) で開始しました。以降、これまでの間に GB あたりの料金を 80% 値下げし、すべての AWS リージョンで S3 を開始しました。元の汎用モデルにはユーザー主導型の機能として、ウェブサイトのホスティング、VPC の統合、IPv6 のサポートなどが追加され、さらに S3 の低頻度アクセスなどの新しいストレージオプションも追加されました。AWS の多くのお客様は、法的、コンプライアンス、その他の目的で重要なデータをアーカイブしますが、このようなデータは滅多に参照することがないため、2012 年に Glacier を発表しました。そして、ライフサイクルのルールを使用して S3、S3 の低頻度アクセス、Glacier の間でデータを転送する機能を提供しました。ここでは、2 つのビッグニュースを紹介します。まず、S3 の標準ストレージと Glacier ストレージの料金が値下げになります。さらに、Glacier に新しい取得オプションが追加されます。 S3 と Glacier の値下げ AWS を長くご利用いただいているお客様はご存じだと思いますが、AWS では絶えずコスト削減に取り組んでおり、その結果を AWS の値下げという形でお客様に還元しています。S3 の標準ストレージの GB あたりの料金は、ほとんどの AWS リージョンで 2016 年 12 月 1 日より値下げになります。12 月の使用量に対する請求には、自動的に値下げ後の新料金が反映されます。標準ストレージの新料金は以下のとおりです。 リージョン 0〜50 […]

Read More

CloudTrail の更新 – Amazon S3 オブジェクトレベルの API アクティビティのキャプチャと処理

AWS の複数のサービスを組み合わせることで、多くのお客様が直面している問題に対処できることを示したいと思います。ここでは、本日発表される新しい AWS CloudTrail 機能を紹介し、この機能を CloudWatch イベントと合わせて使う方法について説明します。 課題 お客様はさまざまな種類のミッションクリティカルなデータを Amazon Simple Storage Service (S3) に保存しており、これらのデータに対するオブジェクトレベルのアクティビティを追跡できることを望んでいます。S3 アクセスログには、アクティビティの一部がキャプチャされて保存されますが、その詳細レベルは限定的でログ配信に何時間もかかる場合があります。お客様は、より充実した詳細とタイムリーな配信を求めています。金融サービスなどの規制業界では特にそうです。たとえば、特定の IAM ユーザーが S3 バケットの特定箇所に保存されている機密情報にアクセスした時間を確認したいというような要望があります。このようなお客様のニーズを満たすために、S3 オブジェクトに対するオブジェクトレベルのアクティビティをキャプチャする機能を CloudTrail に追加します。この機能はデータイベントと呼ばれます (CloudTrail の元のイベントは今後、管理イベントと呼びます)。データイベントは、”読み取り” オペレーション (GET、HEAD、Get Object ACL など) と “書き込み” オペレーション (PUT、POST など) で構成されます。これらのオペレーションでキャプチャされる詳細のレベルは、セキュリティ、監査、ガバナンス、コンプライアンスのさまざまなユースケースに対応するよう意図されています。たとえば、この詳細のレベルに基づいて、個人識別情報 (PII) 用に新しいアップロードされたデータのスキャン、保護されたバケット内のデータに対するアクセス試行の監査、適切なアクセスポリシーが適用されていることの確認ができます。 オブジェクトレベルの API アクティビティの処理 以上のすべてを考慮して、選択されたバケット内のオブジェクトやバケット内の選択されたフォルダーに対して S3 オペレーションが実行されるたびに、それをカスタムアクションで処理する Lambda 関数を簡単に設定できます。この投稿に着手する前に、jbarr-s3-trail という新しい CloudTrail 追跡を作成しておきました。 この追跡を使用して、S3 バケットの 1 つ (jbarr-s3-trail-demo) に対するオブジェクトレベルのアクティビティを記録することにします。そのためには、この追跡にイベントセレクターを追加する必要があります。このセレクターは […]

Read More

Redshiftアップデート:列や表の名前に日本語が使用できるように

Amazon Redshift で列や表、もしくはビューといったオブジェクトの名前として日本語が利用可能になりました!これは以前から日本のお客様からご要望いただいていた機能ですので、以下で説明します。 Amazon Redshift introduces multibyte (UTF-8) character support for database object names and updated ODBC/JDBC Release: Amazon Redshift on 2016-11-10 Redshiftはこれまではデータとしては日本語を含むマルチバイト文字を格納可能でしたが、表や列の名前には使用できませんでした。これが改善され、Redshift v1.0.1122からは日本語のテーブル名や列名が利用可能になります。利用する前にご自身のRedshiftクラスターが1.0.1122以降に更新されているかをご確認ください。 列や表の名前は最大で127バイトまで利用でき、文字はUTF-8で保存されます(日本語の漢字やひらがなは1文字を表現するのに3バイト必要です)。以下のドキュメントも更新されています。現時点では日本語翻訳はまだ更新されていないので、英語に切り替えてご覧ください。 Names and Identifiers なおマルチバイト文字のテーブル名や列名を使用する場合は、RedshiftのJDBCドライバー 1.2.1以降、ODBCドライバー 1.3.1以降にアップデートする必要がある事に注意してください。どちらもRedshiftのマネジメントコンソールから、もしくは以下のリンクよりダウンロードが可能です(こちらも英語にしてご覧ください)。名前のマルチバイト対応だけでなく、バグフィックスや機能向上を含みますのでぜひこの機会にドライバを最新に更新して御利用ください。 Download the Amazon Redshift JDBC Driver Install and Configure the Amazon Redshift ODBC Driver on Microsoft Windows Operating Systems Amazon Redshift JDBC Driver 1.2.1リリースノート(リンク先PDF) […]

Read More