Category: General

Anurag Guptaは幾つものデザインのヘルプを行ったAmazon Auroraを含むAWSが提供するデータベースサービスの責任者です。このシリーズではAnuragがAuroraを支える技術やデザインについて説明します。 この記事は、Amazon Auroraがどのようにクオーラムを使用するのかをお話する4回シリーズの最後です。最初の記事では、障害が発生した場合に必要なクォーラムのメリットとメンバの最小数について説明しました。2回目の記事では、読み書きを行う際に利用するネットワーク帯域の増加を避けるために、ロギング、キャッシュの状態、および非破壊的な書き込みを使用する方法について説明しました。3回目の記事では、より高度なクォーラムモデルを使用して複製コストを削減する方法について説明しました。クォーラムに関するこの最後の記事では、クォーラムメンバーシップの変更を管理する際にAmazon Auroraが問題を回避する方法について説明します。 クオーラムメンバーシップの変更を管理するテクニック マシンは故障します。クオーラムメンバの1つが破損すると、ノードを交換することによってクオーラムを修復する必要があります。これは複雑な決定になります。 クォーラムの他のメンバーは、障害のあるメンバに一時的なレイテンシーの増加が発生したか、再起動のための短期間の可用性低下が発生したか、または永久にダウンしたかどうかを判断できません。 ネットワークパーティションにより、複数のメンバーグループが同時にお互いに隔離を実行出来ます。 ノードごとに大量の永続状態を管理している場合、クォーラムを修復するための状態の再複製には長い時間がかかります。 そのような場合、障害のあるメンバーが復帰できる場合に備えて修復を開始することについて慎重に行う必要があります。 多くのノードで状態をセグメント化することで、修復時間を最適化することができます。 しかし、これは失敗の可能性を高めます。 Auroraでは、データベースボリュームを10GBのチャンクに分割し、3つのアベイラビリティゾーン(AZ)に分散した6つのコピーを使用します。 現在の最大データベースサイズが64TBなので、プロテクショングループは6,400個、セグメント数は38,400個です。 このスケールでは破損は一般的に発生する可能性があります。 メンバーシップの変更を管理する一般的な方法は、一定期間リースを使用し、各リースでメンバーシップを確保するためにPaxosなどのコンセンサスプロトコルを使用することです。 しかし、Paxosは処理負荷のかかるプロトコルであり、最適化されたバージョンでは多数の障害が発生します。 障害を管理するためにクオーラムセットを利用する Auroraはメンバーシップの変更を管理するために、ロギング、ロールバック、コミットなどのクォーラムセットとデータベース技術を使用します。 A、B、C、D、E、Fの6つのセグメントを持つプロテクショングループを考えてみましょう。この場合、書き込みクォーラムはこの6組のうち4つのメンバーであり、読み取りクォーラムは3つのメンバーです。 前回の記事でご紹介したように、Auroraのクオーラムはこれよりも複雑ですが、今は単純に考えてみることにします。 Auroraの読み書きはそれぞれ、メンバーシップエポックを使用します。これは、メンバーシップの変更ごとに単調に増加する値です。 現在のメンバーシップエポックよりも古いエポックにある読み取りと書き込みは拒否されます。そのような場合、クオーラムメンバーシップの状態をリフレッシュする必要があります。 これは、概念的には、REDOログ内のlog sequence numbers(LSN)の概念に似ています。 エポックナンバーおよび関連する変更記録は、メンバーシップに順序付けられたシーケンスを提供します。 メンバーシップエポックを変更するには、データ書き込みと同様に書き込みクォーラムを満たす必要があります。 現在のメンバーシップの読み込みには、データの読み込みと同様のリードクオーラムが必要です。 ABCDEFのプロテクショングループの話を続けましょう。セグメントFが破損した可能性があるとし、新しいセグメントGを導入する必要があると考えてください。一時的な障害に遭遇する可能性があり、迅速に復帰する可能性があります。またはリクエストを処理しているかもしれませんが、なんらかの理由で検出出来ない可能性があります。また、Fが復活したかどうかを確認するのを待ちたくはありません。クオーラムが損なわれて2回目の障害が発生する可能性が増加だけです。 これを解決するためにクォーラムセットを使用します。 私たちはABCDEFからABCDEGに直接メンバーシップの変更をすることはありません。代わりに、メンバーシップのエポックを増やし、クォーラムセットをABCDEFとABCDEGに移動します。書き込みはABCDEFの6つのコピーのうち4つから正常に行われなければならず、またABCDEGの6つのコピーのうち4つからackが返る必要があります。 ABCDEのどの4つのメンバーは両方とも書き込みクォーラムを満たしています。 読み取り/修復クォーラムは同じように動作し、ABCDEFからの3つのackとABCDEGから3つのackが必要です。ABCDEからの3つのいずれかが両方を満たします。 データがノードG上に完全に移動され、Fを取り除くと決定した場合、メンバーシップエポックの変更を行い、クォーラムセットをABCDEGに変更します。エポックの使用は、コミットLSNがREDO処理のために行うのと同様に、これをアトミックに行います。このエポックの変更は、現在の書き込みクォーラムが満たされている必要があり、他のアップデートと同様に、ABCDEFの6つのうち4つと、ABCDEGの6つのうちの4つからのackが必要です。Gが利用可能になり前に再びノードFが利用可能になると、変更を元に戻しメンバーシップエポックの変更をABCDEFに戻します。完全に健全なクオーラムに戻るまで、いかなる状態やセグメントも破棄しません。 このクォーラムへの読み書きは、メンバーシップの変更中に、変更前または変更後と同じように行われることに注意してください。 クォーラムメンバーシップへの変更は、読み取りまたは書き込みをブロックしません。失効したメンバーシップ情報を持つ呼び出し元は、状態をリフレッシュして正しいクォーラムセットに要求を再発行します。また、クオーラムメンバーシップの変更は、読み取り操作と書き込み操作の両方に対して非ブロッキングです。 もちろん、Fの代わりにGへデータを移動しクオーラムを修復している間にABCDEGのいずれかが破損する可能性もあります。多くのメンバーシップ変更プロトコルはメンバーシップの変更中に障害を柔軟に処理しません。クォーラムセットとエポックでは、簡単です。Eも破損してHに置き換えられる場合を考えてみましょう。ABCDEFとABCDEGとABCDFHとABCDGHのクオーラムに移動するだけです。単一障害と同様に、ABCDへの書き込みはこれらのすべてを満たします。メンバーシップの変更は、読み取りと書き込みの失敗と同じ範囲になります。 まとめ クォーラムセットをメンバーシップの変更に使用することにより、Auroraは小さなセグメントを使用することができます。これにより、Mean Time To Repair(MTTR)および複数の障害に対する可能性を削減することで、耐久性が向上します。また、お客様のコストを削減します。Auroraのボリュームは必要に応じて自動的に増加し、小さなセグメントでは少しずつ増加します。クォーラムセットを使用することで、メンバーシップの変更が行われている間も読み取りと書き込みが継続できるようになります。 メンバーシップの決定を元に戻すことができれば、積極的にクオーラムを変更することができます。障害のあったメンバーが返ってくると、いつでも変更を元に戻すことができます。いくつかの他のシステムでは、リースが期限切れとなり、クオーラムメンバシップを再確立する必要があるため、定期的な停止が発生します。Auroraは、リースが期限切れになるまでメンバーシップの変更操作を延期するという耐久性の犠牲を払わず、クオーラムメンバシップが確立されている間に読み込み、書き込み、またはコミットを遅らせるというパフォーマンス上のペナルティも発生しません。 Auroraは、さまざまな分野で進歩を遂げています。データベースと分散システムを統合するアプローチは、これらの多くの中核を成しています。クォーラムをどのように使用するかについてのこの連載をご覧いただき、ご自身のアプリケーションやシステムを設計する方法について考えるときに役立てて頂けると思います。今回使用した手法は広く適用可能ですが、スタックの多くの要素にに対して適用する必要があります。 もしご質問などありまししたら、コメントもしくは aurora-pm@amazon.comにご連絡下さい。 翻訳は星野が担当しました (原文はこちら)

更新 2017年12月2日: 本記事を初回に公開した2017/11/7の際、AWS CLIやPython SDK は 2015年2月5日 より古いバージョンを使っている場合に更新が必要としていましたが、2013年10月29日より古いバージョンが更新必要と修正させていただきます。 更新 2018年3月28日: Amazon Trust Services の表にある古い値を新しい値に置き換えました。 TLS (Transport Layer Security, 以前は SSL と呼ばれていました) はインターネットでやりとりされる情報を暗号化するために不可欠です。例えば、Amazon.com ではウェブサイト上の全トラフィックに TLS を使用していますし、AWS は AWS サービスへの安全な呼び出しに使用しています。 証明書と呼ぶ電子ドキュメントは、暗号化した接続を行う際にサーバのアイデンティティを証明します。アドレスバーに入力した Web サイトとブラウザが安全に通信しているかを検査するのに証明書は役立ちます。CA としても知られている 認証局 は、特定のドメイン名に対して証明書を発行します。ドメインが信頼された認証局から発行された証明書を提示すると、ブラウザやアプリケーションは通信を行っても安全だとわかります。 2016年 1月、AWS は AWS Certificate Manager (ACM) の提供を開始しました。このサービスは、AWS サービスで使用できる SSL/TLS 証明書を簡単に作成、管理できるようにします。証明書にはアマゾンの自社認証局 Amazon Trust Services から発行されたものを追加料金無しで利用できます。ブラウザやその他のアプリケーションが証明書を信頼するには、証明書の発行者がブラウザなどが信頼している認証局一覧である 信頼ストア に含まれている必要があります。もし信頼ストアに発行した認証局が含まれていない場合は、ブラウザはエラーメッセージ（参考例）を表示したり、アプリケーションは独自のエラーを表示します。AWS は Amazon Trust Services […]

今回のブログは Astro Technology, Inc. の CTO である Roland Schemers 氏より寄稿いただきました。Astro は同社について次のように説明しています。「当社はユーザーやチーム向けに開発した人工知能を使用する Mac や iOS および Android 用のメールアプリを製作しています。アプリ内のメールボイスアシスタント、Astrobot Voice を使えば、Astro アプリを終了せずにメールを読んだり返信することができます。」 そして最近では Astrobot Voice という初のアプリに組み込まれているメールボイスアシスタントをリリースしたばかりです。これにより、iOS 向け Astro や Android 向けアプリを終了する必要なく、メールの読み取り、管理、返信が可能になりました。 Astro が 6 月に Amazon Alexa スキルをリリースしてから、我々はより多くのユーザーが音声でメール管理をできるようにしたいと考えました。そこで、今回のブログではなぜ我々がこうした選択を取ったのか技術面から説明し、どのようにこれを実現しどういったテクノロジーを使用したのかご説明します。 アプリ内ボイスを構築する理由は? 当社では Amazon Echo を愛用しています。実際、Astro の新入社員には「ようこそ」という意味はもちろん、我々の Alexa スキルを社内で試験運用することを兼ねて、各自に Echo Dot を提供しています。結果として私達のスキルが上々であることが分かり、より多くのユーザー、そしてさらに様々な場所で取り入れられる方法を新たに見つけることもできました。そこでアプリ内ボイスを構築できるか、その可能性を探ってみることにしたのです。 ソフトウェアの選択 アプリ内ボイスの構築方法を決定する上で、我々はいくつものオプションを検討しましたが、その上でいくつかのポイントを念頭に置きました。 まず、当社のテキストベースアシスタント (api.ai で実行) または Alexa スキルからできるだけ多くのコードやロジックを再使用することです。 […]

AWS リソースにタグを付け、タグごとにコストの内訳を確認する機能は、以前から提供されていました。コスト配分の機能は 2012 年に開始され (「お客様の請求のための AWS コスト配分」を参照)、当社はその他のサービスのサポートを安定して追加してきました。最も最近では DynamoDB (「Amazon DynamoDB 用のコスト配分タグの概要」)、Lambda (「AWS Lambda がタグ付けとコスト配分をサポート」)、EBS (「新規 – AWS Snapshots 用のコスト配分」) が追加されました。 本日は、Amazon Simple Queue Service (SQS) 用のタグベースのコスト配分を発表いたします。これにより、キューにタグを割り当て、それを使用して、アプリケーション、アプリケーションステージ (キューを介して通信する疎結合アプリケーション用)、プロジェクト、部署、開発者など、目的とするあらゆるレベルでコストを管理できます。キューにタグを付けたら、AWS Tag Editor を使用して、対象のタグが付けられたキューを検索できます。 私のキューの 1 つに 3 つのタグ (app、stage、department) を追加する方法をご覧ください。 この機能はすべての AWS リージョンで今すぐご利用いただけます。タグ付けの詳細については、「Amazon SQS キューにタグを付ける」を参照してください。タグを使用したコスト配分の詳細については、「コスト配分タグの使用」を参照してください。メッセージキューを使用して最新のアプリケーション用の疎結合マイクロサービスを構築する方法については、当社のブログ投稿 (「Amazon SQS および Amazon SNS による疎結合のスケーラブルな C # アプリケーションの構築」) を参照するとともに、当社の最近のウェビナー (「Amazon SQS and […]

AWS re:Invent の開催まで後わずか 40 日となったので、私の同僚と私は、お客様がラスベガスでの時間を有効に活用するためのヒントをいくつかご紹介します。いつもどおり、トレーニングと教育に重点を置き、それ以外の時間にはお楽しみイベントやレクリエーションも用意されています。 場所、場所、場所 re:Invent Campus はラスベガス商業地全体にわたって行われ、MGM Grand、Aria、Mirage、Venetian、Palazzo、Sands Expo ホール、Linq Lot、Encore でイベントが開催されます。各施設では、特定のトピック専用のトラックをホストします。 MGM Grand – ビジネスアプリ、エンタープライズ、セキュリティ、コンプライアンス、アイデンティティ、Windows。 Aria – Big Data & Analytics、Alexa、コンテナ、IoT、人工知能 & 機械学習、サーバーレス。 Mirage – ブートキャンプ、認証 & 認定試験。 Venetian / Palazzo / Sands Expo ホール – アーキテクチャ、AWS Marketplace & Service Catalog、コンピューティング、コンテンツ配信、データベース、DevOps、モバイル、ネットワーキング、ストレージ。 Linq Lot – Alexa ハッカソン、Gameday、ジャムセッション、re:Play パーティー、講演者との交流 & 挨拶。 Encore – 予約可能な会議会場。 […]

（補足：本記事は2017年7月にAWS Bigdata Blogにポストされた記事の翻訳です。一部の記載を現時点の状況に合わせて更新してあります） 何年も前、最初にクラウドベースのデータウェアハウスを構築する可能性について検討を始めた際、我々は、我々の顧客が増え続ける一方の大量のデータを持つ一方で、そのごく一部のデータのみが既存のデータウェアハウスやHadoopシステムに投入され分析に利用されているという事実に直面しました。同時に、これがクラウド特有の特殊事情ではないこともわかりました。エンタープライズストレージ市場の成長率がデータウェアハウス市場のそれを大きく上回る様々な業界においても、状況は同じだったのです。 我々はこれを“ダークデータ”問題と名付けました。我々の顧客は、彼らが収集したデータに利用されていない価値があることに気づいていました。そうでなければなぜそれを保管するコストをかけるでしょうか？しかしながら、彼らが利用できるシステムは、これらのデータ全てを処理するには遅すぎ、複雑すぎ、高すぎたため、データのサブセットのみを利用することになりました。彼らはいつか誰かが解決策を見出すことへの楽観的な期待とともに、これらのデータを保持し続けました。 Amazon Redshift はダークデータ問題の解決に寄与することから、AWSサービスの中でも最も成長の速いサービスの一つとなりました。このソリューションは大半の代替案に比べ、少なくとも一桁は安価で、かつ高速でした。また、Amazon Redshiftは当初からフルマネージドのサービスで、ユーザーはキャパシティやプロビジョニング、パッチ対応、監視、バックアップ等を始めとする様々なDBA課題について頭を悩ませる必要がありませんでした。 Vevo, Yelp, Redfin,Edmunds, NTTドコモなどの多くの顧客が、Amazon Redshiftに移行して、クエリー性能の改善、DBAオーバーヘッドの削減、そして分析コストの低減を実現しました。 我々の顧客のデータは、極めて速いペースで増え続けています。おしなべて、ギガバイトのデータはペタバイトとなり、平均的なAmazon Redshift顧客が分析するデータ量は毎年二倍になっています。我々が、増加するデータを扱う上でお客様の手助けとなる機能群を実装してきた理由はここにあります。例えばクエリースループットを二倍にする、圧縮率を三倍から四倍に改善する、といったことです。これらは、お客様がデータを破棄したり分析システムから削除したりすることを考慮せざるを得なくなる時期を遅らせることができます。しかしながら、ペタバイトのデータを日々生成するAWSユーザーが増えており、こうしたデータはわずか3年でエクサバイトの水準に達します。このようなお客様のためのソリューションは存在しませんでした。もしデータが毎年倍々になるのであれば、コスト・性能・管理のシンプルさに革新をもたらす、新たな、破壊的なアプローチを見付けることを強いられるまで、そう長い時間はかからないでしょう。 今日利用可能な選択肢に目を向けてみましょう。お客様は、Amazon EMRを用いて、Apache HiveなどのHadoopベースの技術を利用することができます。これは実際のところ、非常に素晴らしいソリューションです。抽出と変換のステップを経ることなく、Amazon S3上のデータを簡単かつ低コストで直接操作できるようになるからです。クラスターは必要な時に起動することができ、実行対象となる特定のジョブに合うよう適切にサイジングすることができます。こうしたシステムは、スキャンやフィルター、集計といったスケールアウト型の処理には最適です。一方で、これらのシステムは複雑なクエリー処理には向いていません。例えば、結合処理ではノード間でデータをシャッフルする必要が生じます。巨大なデータと多数のノードが存在する場合、この処理は極めて低速になります。そし結合処理は、重要な分析課題の大半において本質的に重要なものです。 Amazon Redshiftのような、列指向かつ超並列型のデータウェアハウスを利用することもできます。こうしたシステムは、巨大なデータセットに対する結合や集計といった複雑な分析クエリーを、単純かつ高速に実行することを可能にします。特に、Amazon Redshiftは、高速なローカルディスクと洗練されたクエリー実行、そして結合処理に最適化されたデータフォーマットを活用します。標準SQLを用いるので、既存のETLツールやBIツールを活用することもできます。一方で、ストレージとCPU双方の要件を満たすようにクラスターをプロビジョニングする必要があり、データロードも不可欠となります。 いずれのソリューションも強力な特長を備えていますが、お客様はどちらの特長を優先するかの判断を強いられます。我々はこれを「ORの抑圧（※）」と見做しています。ローカルディスクのスループットとAmazon S3のスケーラビリティは両立できない。洗練されたクエリー最適化と高度にスケールするデータ処理は両立できない。最適化されたフォーマットによる高速な結合処理性能と、汎用的なデータフォーマットを用いる様々なデータ処理エンジンは両立できない、などです。しかし、この選択は本来迫られるべきではありません。この規模においては、選択する余裕など到底ないからです。お客様が必要とするのは「上記の全て」なのです。 ※ジム・コリンズが著書「ビジョナリー・カンパニー」で提示した概念。一見矛盾する力や考え方は同時に追求できない。 Redshift Spectrum Redshift Spectrumは、こうした「ORの抑圧」に終止符を打つべく開発されました。Redshift Spectrumによって、Amazon Redshiftを利用されているお客様はAmazon S3上のデータに対し 簡単にクエリーを実行できるようになります。Amazon EMRと同様に、お客様はオープンなデータフォーマットと安価なストレージの恩恵を享受できます。データを抽出し、フィルターし、射影し、集計し、グループ化し、ソートするために、何千ものノードにスケールアウトすることも可能です。Amazon Athenaと同様に、Redshift Spectrumはサーバーレスであり、プロビジョニングや管理は必要ありません。単に、Redshift Spectrumを利用したクエリーが実行されている間に消費中のリソースに対してお支払いいただくだけです。Amazon Redshift自身と同様に、洗練されたクエリーオプティマイザー、ローカルディスク上のデータへの高速アクセス、そして標準SQLの恩恵を得ることができます。そして、他のどのようなソリューションとも異なり、Redshift Spectrumはエクサバイト級ないしはそれ以上のデータに対して、高度に洗練されたクエリーを、わずか数分で実行することが可能です。 Redshift SpectrumはAmazon Redshiftの組み込み機能の一つであり、お客様の既存のクエリーやBIツールはシームレスにご利用いただくことができます。背後では、我々は複数のアベイラビリティゾーンに跨がった何千ものRedshift Spectrumノードのフリートを運用しています。これらのノードは、処理する必要があるデータに基づいて透過的にスケールし、クエリーに割り当てられます。プロビジョニングや利用の確約は不要です。Redshift Spectrumは同時実行性にも優れています。お客様は任意のAmazon S3上のデータに対して、複数のAmazon Redshiftクラスターからアクセスすることができます。 Redshift Spectrumクエリーのライフサイクル Redshift Spectrumクエリーのライフサイクルは、クエリーがAmazon Redshiftクラスターのリーダーノードに送信された時に始まります。リーダーノードはクエリーを最適化し、コンパイルし、その実行命令をAmazon Redshiftクラスターのコンピュートノード群に送ります。次に、コンピュートノード群は外部テーブルに関する情報をデータカタログから取得し、当該クエリーのフィルターと結合に基づいて、無関係なパーティションを動的に取り除きます。コンピュートノードはまた、ノード上でローカルに利用可能なデータを精査して、Amazon S3内の関連するオブジェクトだけを効率的にスキャンするようプレディケイトプッシュダウンを行います。 Amazon Redshiftコンピュートノードは、続いて、処理する必要のあるオブジェクトの数に基づいて複数のリクエストを生成し、それらをRedshift Spectrumに一斉に送ります。Redshift Spectrumは、AWSリージョンごとに何千ものAmazon EC2インスタンスをプールしています。Redshift […]

先日のCloud Roadshow 2017 広島、名古屋、大阪では、KeyNoteの中でAWSの円払い対応および日本準拠法対応についてみなさんにご案内いたしました。本ブログの中で2回連載という形でそれぞれ、支払方法の円対応、日本準拠法切り替えについてご案内をいたします。 実は、AWSの支払い通貨変更機能は、2015年2月にお客様からのご要望受けて実現してる機能ですが、新しくAWSのご利用をご検討いただいている皆様に改めてお伝えしたいこと、また管理者画面のデザイン変更などで過去ブログで記載された手順と少し変更が入っているため、改めてみなさんにその特徴・注意点と手順を共有させていただきます。 [特徴] 管理者画面での変更だけで切り替え作業が完了します 対応しているクレジットカードはVISAとMasterカードです MarketplaceでAMI形式で有償EC2インスタンスを設定している場合、その部分だけ引き続きドルで請求されます AWS内部ではドルで計算され、月末の利用料集計時に、その時点でのAWSが定めるレートをもとに円に自動計算されます 月額のAWSご利用額がドル換算で過去3か月平均が2000ドル以上、もしくは2000ドルを超えるご予定がある場合は、請求書切り替えも可能となります。 請求書払いもクレジットカードと同様にMarketplaceでAMI形式で有償EC2インスタンスを設定している場合、その部分だけ引き続きドルで請求されます [手順] それでは手順についてみていきましょう。まず管理者画面にログインしてください。トップページがでてきます。 右上のアカント名が、みなさんが設定を行おうとしているアカウント名が正しく表示されていることを確認してください。なお、AWSマネージメントコンソールはアカウント開設時期や設定状態などで異なるデザインが表示される方もいらっしゃいますが、エラーではありませんので安心してください。 右上のアカウント名を選択してください。 アカウントを選ぶと以下の画面が出てきます。 オレンジ色の箇所にはみなさんのアカントに登録された情報が出てきます。左側の「お支払方法」を選択してください。 お支払いに使用されているクレジットカード情報が表示されます。その右上にUSDとなっている箇所がありますのでそちらをクリックしてください。 「お支払通貨の設定」の右側にある「編集」を選んで通貨を選んでください。 全部で13種類の通貨が選べるようになっています。日本円の場合はJPYを選んでください。以上で切り替えは終わりです。作業を行った月のAWS利用分から支払通貨変更が反映されます。 [請求書払いへの切り替えについて] 請求書払いへの切り替えの場合、AWSの月額ご利用額がドル換算で過去三か月の平均が2000ドル以上であれば、サポートセンターで「新規ケースの作成」をクリックし、「アカウントおよび請求サポート」まで変更をご依頼ください。 2000ドルに満たないが、今後ご利用予定がある場合は、担当アカウントマネージャへのご連絡、もしくはこちらからご連絡ください。 -プロダクトマーケティング エバンジェリスト 亀田  

Amazon Redshiftは高速で完全マネージド型のデータウェアハウス（DWH）です。ペタバイト級までスケールアウトが可能であり、Amazon Redshift Spectrumを利用することでAmazon S3上に保存されたエクサバイト級のデータにロード無しでクエリを実行することも可能です。 Amazon Redshiftがリリースされた当初からご利用いただいている方であれば、当初はHDD搭載のDW1と呼ばれるノード1種類しか無かったことをご記憶かと思います。続いてSSDを搭載した新しいノード追加され、DW1(HDDベース）とDW2(SSDベース）の2タイプから選択可能になりました。 その後、DW1の後継がリリースされる際にHDDベースはDense Storage (DS) に、SSDベースはDense Compute (DC)とそれぞれの特性を表した名前に整理され、DS1（旧DW1)の後継としてDS2がリリースされました。DS2リリース時のブログエントリはこちらにありますが、その登場はDS1ユーザから驚きをもって迎えられました。DWHとしての性能が大きく向上しつつ、ノードの価格は据え置きだったからです。 次はDense Compute (DC)の番です。DC2が本日より利用可能になりました！ 第二世代のDense Computeノード DC2はDC1の後継となるノードであり、高いスループットと低いレイテンシを必要とするDWHワークロードのために設計されています。CPUはIntel E5-2686 v4(Broadwell)になり、高速なDDR4メモリを搭載。ストレージはNVMe接続のSSDです。 私達はAmazon Redshiftがこのより高速なCPU、ネットワーク、ストレージの性能をDC2で十分に発揮できるようチューニングを行い、結果としてDC1との同一価格構成での比較で最大2倍のパフォーマンスを発揮しています。DC2.8xlargeノードではスライスあたりで2倍のメモリを搭載しており、ストレージレイアウトの改善によって30%多いデータが保管できるようになりました。これらの改善がされた新世代のノードを旧世代と同じ価格で提供します。 DC2.8xlargeではパフォーマンスを最大化するためにスライス数が変更されています。旧世代のDC1.8xlargeでは1ノードあたり32スライスでしたが、DC2.8xlargeでは16スライスに変更されています。DC2.largeはDC1.largeと変わらず1ノード2スライスのままです。 このため、DC1.8xlarge (もしくはDS)からDC2.8xlargeへ移行するためにはクラスターのリサイズが必要になります。DC1.largeからDC2.largeへの移行については、リサイズもしくはDC1で取得したスナップショットからの作成が可能です。 本日より利用可能です DC2ノードはUS East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), EU (Frankfurt), EU (Ireland), EU (London), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific […]

つい先日までのLumberyardとは違います。もし、しばらく離れられていたなら新しいLumberyardを見ていただく良い機会です。 新たなビジュアルスクリプティングとアニメーションツールが実装された Lumberyard 1.11を こちら からダウンロードできます。 これまでの19ヶ月で オリジナルのコードベースの60%を入れ替えており、3,300以上の改善と、500個の無料アセットを追加し、皆さんゲームプロジェクトでご利用いただけるようになりましが、今回のリリースはエンジンと皆さんの制作体験上とても重要なターニングポイントになります。なぜなら… 新アニメーションシステムとしてEMotion FXが導入され、CryAnimation (GeppettoとMannequin)と置き換えられました。エンジニア不在でも、ブレンドツリー、ステートマシン、ブレンドスペース、モーションツリー等の機能を使って10分程触っていただくだけで高品質なアニメーションを制作できます。EMotion FX はこれまでにEAやUbisoftのようなスタジオで10年以上に渡って利用されてきていましたが、今回Lumberyardの永続的なパートとなり、強力かつ扱い易いソリューションをアーティストの皆さんに提供できることになました。(1.11の新たなサンプル中に我々のキャラクターRinがありますのでお試しください。サンプルへのアクセス方法は こちら) Script Canvasが、これまでのFlow Graphと置き換えられ、新たなビジュアルスクリプティングソリューションになりました。Script CanvasでLuaやC++と同様にゲーム内の挙動をオーサリングできるソリューションとなります。これにより、必要とされるエンジニアがいない場合でもEMotion FXで作成されたクールなアニメーションをScript Canvasで即座にキャラクターの挙動を制作できるということになります。プログラミング経験に乏しくても、Script Canvasのノードインターフェースで、品質の高いゲームプレイ体験を創り出していただけるようになります。Script Canvasで皆さんの創り出されるものを楽しみにしています。(Script Canvasの開始方法やチュートリアルは こちら の最新ドキュメントをご参照ください) さらに新たに、将来を見据え CryEntity コンバートツールを用意し、CryEntityを新たなComponent Entityフォーマットにコンバートできるようにしました。これにより、将来Lumberyardの新たな上システムの利点を享受し安定した土台の上にゲームを構築できるようになります。まだまだ沢山の作業がありますが、素晴らしい開発コミュニティの皆さんと共に進化と成長を続け育てていくことはとてもエキサイティングなことです。 (コンバートツールのご利用は こちらのチュートリアルをご参照ください)   EMotion FX   Script Canvas 400以上の追加アップデート 今回のリリースには沢山の更新がありますので詳しくは こちら をご参照ください。 新たに3つのCloud Gemが加わり、ゲーム中のプレイヤーの状態を簡単に観測したり、 Amazon Polly を活用したSpeech Gemでテキストを読ませたり、Amazon Lex による音声認識をゲームプレイで活用したりできるようになりました。 新規プロジェクトのスタート地点として、新たに2つのプロジェクトテンプレートが加わり、デフォルトのテンプレートはGem群を有効にしてシンプルなレベルからのスタートとして、空のテンプレートは最低限の素の状態のテンプレートとなります。 新たなGetting Started Guide（初心者ガイド）により、以前よりもさらに素早くLumberyardを始めていただけるようになりました – 迷路脱出ゲームをお友達と簡単にシェアできてしまいます。ドキュメントは […]

この記事では、広範に利用可能なコンポーネントを利用して、Amazon Lex をどのようにカスタムハードウェアに組み込むかを紹介します。シンプルな音声ベースの AI キットを構築して、Amazon Lex に接続する方法を示します。Raspberry Pi および合計 60 ドル以下の市販のコンポーネントをいくつか使用します。このブログの終わりまでに、Amazon Lex PostContent API に統合された、インターネット接続されたハードウェアデバイスが使用できるようになります。音声制御ロボットおよび音声制御メトロノームなどの、幾つかのボットのデモも行います。 コンポーネント概要 Amazon Lex ハードウェアキットを構築するには、以下のコンポーネントが必要です。 Raspberry PI 3 Model B、Amazon で 35 ドルから。 Kinobo – USB 2.0 ミニマイク、Amazon で 5 ドルから。 Adafruit I2S 3W ステレオスピーカーボンネットおよびスピーカー、adafruit で 12 ドルから。 (オプション) Qunqi クリアーケースボックスエンクロージャー、Amazon で 20 ドルから。 物理的な作成 Raspberry Pi 図 1. Raspberry PI […]