Author: AWS Japan

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; (翻訳は星野が担当しました。原文はこちら)

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

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

本日のゲストポストでは、同僚の 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% […]

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

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

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) に対するオブジェクトレベルのアクティビティを記録することにします。そのためには、この追跡にイベントセレクターを追加する必要があります。このセレクターは […]

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

Human Longevity, Inc. (HLI) は予防衛生を支持する上で、ヒトゲノムおよび関連性を持つ表現型データや臨床データを蓄える世界最大のデータベースを構築したいと考えています。今回のゲスト投稿では、Yaron Turpaz 氏と Bryan Coon 氏、Ashley Van Zeeland 氏が医学に大きな変化をもたらす努力の一端として生成している大量のデータを保存するため、どのように AWS を使用しているのか語ります。 — Jeff; 2013 年に Human Longevity, Inc. を設立した当時から、前途に待ち受ける挑戦を認識していました。ゲノムには生命体を形成し維持する上で必要なすべての情報が詰まっています。ヒトにおいては、30 億もの DNA ベースのペアを含むゲノム全体のコピーが核を持つ全細胞に含まれています。我々の目的は 100 万のゲノムを配列し、その情報と関連付けた健康記録や疾病リスクを研究者や医師に提供することです。研究者や医師はデータを解釈して的を絞った個人の健康管理プランや、癌やその他の深刻な健康リスクにおいて最適な治療を従来より遥かにすばやく提供することができます。従来のように症状が出始めてから医師にかかり、病気を診断されてから治療を始めるモデルではなく、予防衛生やリスク予防を発展させることで医療を変えることが我々の目的です。大規模なコンピューティングを開発し適用、ゲノム研究に機械学習を使用するには Illumina のような企業が提供する DNA 配列技術による大量なデータの収集、分析、保存が必要になります。1 つのゲノムからの生データは約 100 ギガバイトを消耗します。注釈や表現型のソースや分析を含むゲノム情報を調整し、健康上の情報を分析するに伴ってこの数字は上昇します。我々が選ぶコンピューティングとストレージ技術が当社の成功に直接影響することは初めから理解していました。ですから、クラウドを使用することは明らかに最適な選択でした。当社はゲノミクスを専門としているので、IT インフラストラクチャの構築や維持にリソースを使用することは希望していません。そこで、プラットフォームの広さや当社が必要とする優れたスケーラビリティ、そしてビッグデータで展開した専門知識を備えている AWS を選ぶことにしました。また、AWS によるイノベーションのペースも考慮しました。利用者のために可能な限りコストを抑える AWS の手の込んだ策略も、当社のビジョンを実現する上で非常に大切なポイントだと考えました。 広範囲にわたる AWS サービスの活用 スペクトルの核型分析 / 画像提供: Human Longevity, Inc. 現在、当社では広範な AWS サービスを使用して様々な種類のコンピューティングタスクやストレージタスクを行っています。たとえば HLI のナレッジベースは […]

AWS Lambda とサーバーレスアプリケーション開発をめぐる興奮のとりこになっています。過去 1〜2 年間に週刊 AWS で、多くのサーバーレスの成功事例、ツール、オープンソースプロジェクトを紹介しました。今回は Lambda に追加された重要な機能として、環境変数と新しいサーバーレスアプリケーションモデルについて説明します。 環境変数 開発者なら、だれでも複数の環境で利用できるコードを構築したいと思います。コードを簡単に再利用するには、実行時に設定値を受け入れられるように構築する必要があります。設定値とは、コードの環境をカスタマイズするためのテーブル名、デバイス名、ファイルパスなどです。たとえば、多くのプロジェクトは開発環境、テスト環境、本稼働環境ごとに設定が異なります。Lambda 関数に環境変数を指定できるようになりました。これでコードを変更または再デプロイすることなく設定の変更が可能になり、これまで以上にサーバーレスアプリケーション開発が効率化されます。各環境変数はキーと値のペアです。キーと値は AWS Key Management Service (KMS) で暗号化され、必要に応じて復号されます。関数あたりの環境変数の数には制限がありませんが、合計サイズは 4 KB を超えることができません。 Lambda 関数を新規作成する場合は、同時に環境変数も設定します。最新バージョンの関数の値は変更できますが、以前のバージョンの値は変更できません。次の例では、シンプルな Python 関数を作成して、いくつかの環境変数を設定し、その環境変数をコードから参照しています (このために os ライブラリをインポートする必要がありました)。 Lambda に用意されているデフォルトのサービスキーを使えば、この機能を使用しても料金はかかりません (独自のキーを使用する場合は、リクエストあたりの KMS の通常料金が適用されます)。この新しい機能の詳細とさまざまな活用方法については、AWS Compute Blog で「サーバーレスアプリケーションを簡素化する Lambda 環境変数」を参照してください。 AWS サーバーレスアプリケーションモデル サーバーレスアプリケーションを構築するために、Lambda 関数、Amazon API Gateway リソース、Amazon DynamoDB テーブルを併用する場合があります。新しい AWS サーバーレスアプリケーションモデル (AWS SAM) を使うと、これらのすべてのコンポーネントを、AWS CloudFormation でネイティブにサポートされている簡略化された構文で記述できます。この構文を使用するには、CloudFormation テンプレートに次のような […]