Author: AWS Japan Staff

Redshiftに最近追加された新機能や、SASのRedshift対応強化についてアナウンスが出ていましたので、ご紹介します。 BACKUP NO オプションをCREATE TABLEで指定できるようになりました。名前の通り、この指定を付けた表はRedshiftの自動・手動SNAPSHOTでバックアップが取得されなくなります。Redshiftを活用する上で、一次的に中間データを置く表を作成することが良くあるのですが、これまではそのような一時表も自動SNAPSHOTの対象になっていました。このオプションでSNAPSHOT不要な表を指定することで、パフォーマンスの向上と、SNAPSHOTサイズの縮小が期待できます。 参照）BACKUP MD5ハッシュの文字列を使ったCREATE USER/ALTER USERが利用可能になりました。クラスターバージョン1.0.1046以降で利用可能です。 通常CREATE USERを実行する際には、引数でパスワードを指定する必要があります。これをシェルスクリプトに書いて実行する場合を想定すると、そのファイルからパスワードが漏洩してしまうリスクがありました。今回の機能改善では、予めMD5ハッシュ化した文字列をCREATE　USERのパスワードに指定する事が可能になりました。Redshiftは与えられたパスワードをMD5ハッシュ化して格納していますが、これをユーザが直接指定することが出来るようになったわけです。MD5ハッシュ化した文字は簡単にはパスワードに逆変換できないため、漏洩時のリスクを小さくすることが可能です（漏洩しても絶対大丈夫という意味ではありません）。 パスワードとユーザ名を連結した文字列をRedshiftのMD5関数に通すことで、必要なハッシュ化文字列が得られます。詳しくは以下のCREATE USERのマニュアルをご参照ください。PASSWORD引数の書き方の部分に例とともに解説があります。（※執筆時点では英語版にして確認する必要がありました） 参考）CREATE USER 新しいSVV_TRANSACTIONSビューが提供されました。このビューをクエリすることで今実行中のトランザクション一覧が得られます。granted列が’t’になっているトランザクションが、今ロックを保持している、つまり今実行されているSQLです。これが’f’の場合はロックを待っているSQLという事になります。このビューでロック競合で待たされているトランザクションを発見することが容易になります。 参考）SVV_TRANSACTIONS SAS/ACCESSのRedshift対応が拡張され、自動的なプッシュダウン等がRedshiftに対して有効になりました。これまでもSASからRedshiftへ接続してデータ分析を行う事が可能でしたが、機能拡張され、 Implicit pass-through機能が有効になりました。これはSASへのクエリの一部をSQLに変換してRedshift側に移譲（プッシュダウン）し、パフォーマンスを向上させる事が可能になっています。 SAS 9.4M3から対応されています。この他にも機能拡張されておりますので、詳細はSAS/ACCESSのWebサイトをご覧ください。同様に、分析ソフトとしては、SPSS (IBM)もRedshiftへのプッシュダウンに対応しています。 参考）SAS/ACCESS （原文）：https://aws.amazon.com/jp/about-aws/whats-new/2016/04/amazon-redshift-announces-enhancements-to-data-loading-security-and-sas-integration/ 翻訳：下佐粉　昭（@simosako）

GE Oil & Gas 社は、親会社の General Electric 社によって行われた一連の買収の結果、1980 年代後半に誕生した、同社の比較的新しい部門です。現在、GE Oil &Gas 社は、親会社のデジタル革命を主導しています。下記のゲスト投稿は、GE Transportation の CTO で、以前は GE Oil & Gas 社のクラウド設計者であった Ben Cabanas 氏が、2016 年にオーストラリアのシドニーで行われた AWS Summit における同氏の最新のプレゼンテーションのテーマであった、大規模エンタープライズのクラウド移行に必要な主要ステップについて書かれたものです。 詳細については、AWS によるエンタープライズクラウドコンピューティングを参照してください。 — Jeff; 課題と変革 GE Oil & Gas は、GE を前進させる重要戦略である、GE のデジタル革命の最前線に立っています。この部門を取り巻く環境として、この業界は激しい競争とコスト課題に直面しており、技術革新を受け入れることが不可欠になっています。GE の CIO である Jim Fowler 氏が言及しているように、今日製造業で成功するには、デジタルイノベーターになる必要があります。 クラウドへの移行は、GE のこの革新の中核部分です。もちろん、これは、これほどの規模、グローバルリーチ、業界における役割を持った、エンタープライズ内の大きな部門にとって、「言うは易く行うは難し」です。GE Oil & Gas では、11 の異なるリージョンと 7 つのリサーチセンターにおいて、45,000 […]

本日よりAmazon RDS for MySQLデータベースにて、MySQL 5.6から5.7へマネージメントコンソールやAPIを使用して数クリックでアップグレード出来るようになりました。 MySQL 5.7では以下の様な新機能が利用可能になり、MySQL 5.6よりパフォーマンスが向上しています Native support for the JSON data type and built-in JSON functions Optimizer improvements for better EXPLAINing, parsing, and query performance GIS Spatial Extensions Improved parallel replication using logical clock mode Improved InnoDB scalability and temporary table performance Improved tablespace discovery during crash recovery Dynamic buffer pool resizing […]

MariaDB audit plug-inがRDS MySQL (5.6.29と5.7.11) とRDS MariaDB 10.0.24 にてご利用頂けるようになりました。MariaDB audit plug-inはアプリケーションの問題を切り分けるためや、コンプライアンスに準拠するためにデータベースのイベントのログを取得することが可能です。プラグインの主な機能は以下の通りです。 Enabling and disabling the audit plug-in – オプショングループよりプラグインを有効・無効化出来ます。オプショングループにMARIADB_AUDIT_PLUGINオプションが追加されています。このオプションを設定したオプショングループをRDSインスタンスへ付与することでロギングが有効になります。無効にする場合は、このオプショングループをRDSインスタンスから削除します。 SERVER_AUDIT_EVENTS変数 – この変数では取得するイベントの種類を設定可能です。(CONNECTION: ユーザが接続・切断したイベント, QUERY: クエリとその結果, TABLE: クエリによってアクセスされたテーブル) SERVER_AUDIT_EXCL_USERS と SERVER_AUDIT_INCL_USERS変数 – この変数で、どのユーザを監査対象にするか・しないかを設定可能です。SERVER_AUDIT_INCL_USERSの設定が優先され、標準では全てのユーザが記録対象となっています。 MariaDB audit plug-in for RDS MySQL, MariaDBはRDSが利用可能なリージョン全てでご利用可能です。 翻訳は星野が担当しました。 (原文はこちら)

我々は、Amazon Inspectorがプレビューを経て全てのお客様に一般利用可能となったお知らせが出来ることを嬉しく思います。 Amazon Inspectorは、セキュリティ脆弱性診断サービスです。これは、Amazon EC2上で稼働するお客様のアプリケーションのセキュリティやコンプライアンス適合の改善を支援します。Amazon Inspector は、自動的にアプリケーションを評価し、脆弱性やベストプラクティスからの逸脱がないかどうかを確認し、重大性の順に結果を表示した詳細なリストを作成します。Amazon Inspector には、共通のセキュリティベストプラクティスや脆弱性の定義に対応した何百ものルールが収められたナレッジベースが備えられており、それらはAWS のセキュリティ研究者によって定期的に更新されます。 Amazon Inspectorは前払いの投資も必要ありませんし、追加的なソフトウェアライセンスや保守費用、専用のハードウェアも必要ありません。 お客様はご利用分のみの支払であり、それは柔軟なユースケース、たとえば継続的デプロイメントやオートスケールなどへの対応（それらはホスト毎やIP毎の支払モデルでは難しいものでしょう）を提供します。 Amazon Inspectorは、90日の無償利用を含みます。 ぜひともより詳細な情報を得るためにAmazon Inspectorの製品詳細ページをご覧になってください。   原文はこちら。日本語訳は市崎が担当しました。

ついこの間に新年のご挨拶をしたと思っていたら、あっという間に4月も下旬になってしまいました。今週末からゴールデンウィークですが、今年は5/2と5/6をお休みにすると10連休になります。 この機会に旅行に出かける方も多いかもしれませんが、もしも時間が空いたらAWSのことを思い出してみてください！米国時間で4/18,19にAWS Summit Chicagoが開催され数多くの発表が行われました。かなりのボリュームがありますので、この機会に最新情報をキャッチしてみてはいかがでしょうか？（概要はこちらのWebページとこちらの資料をご覧ください） それでは、いつものように先週AWSの世界で起こった出来事を振り返ってみましょう。 月曜日 4月18日 AWS CodePipelineがAWS CodeCommitとの連携をサポートいたしました。 AWS CloudFormationが新たにAmazon API GatewayをサポートしたとともにCloudWatch EventsとAWS WAFのサポートを改善いたしました。 AWS Developer Blogにてサーバーレスなサービスディスカバリ(パート1 – はじめに、パート2 – 参照する)がポストされました。 AWS Mobile Development BlogにてAWS IoTとAmazon Machine Learningでメンテナンスを予測するがポストされました。 AWS Big Data BlogにてStrata+Hadoop 2016におけるAWS:ストリーミングデータ処理のためのスケーラブルなアーキテクチャをAWSで構築するがポストされました。 火曜日 4月19日 Amazon EBSの新ボリュームタイプ、スループット最適化HDDとコールドHDDを発表いたしました。(日本語版記事) AWS Device Farmのアップデート – インタラクティブなテストを可能にするリモートアクセスを発表いたしました。(日本語版記事) Amazon Cognito向けUser Poolsを発表いたしました。(日本語版記事) Amazon Kinesisのアップデート – Amazon Elasticsearch Serviceとの統合、シャード単位のメトリクス、時刻ベースのイテレータを発表いたしました。(日本語版記事) AWS Elastic […]

先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 4 月 11 日 AWS データベース移行サービスで詳細なテーブルとスキーマのマッピングがサポートされたことを発表しました。 既存のデータソース設定をコピーすることにより、Amazon ML に新しい Amazon Redshift データソースを簡単に作成できることを発表しました。 Amazon Kinesis Agent を新しいデータ処理機能とともに更新しました。 ECS CLI、AWS CLI、AWS SDK for Java、AWS SDK for Ruby、および AWS SDK for JavaScript を更新しました。 AWS サポートに運用に関する評価、推奨、およびレポート作成が追加されたことを発表しました。 Botmetric で、AWS クラウド内での単一障害点の排除について扱われました。 DZone Cloud Zone で、Amazon CloudWatch Logs を AWS Lambda を使用して Loggly に送信することが扱われました。 Gorillastack が、AWS コスト管理の新機能について発表しました。 Datadog […]

アプリケーションが動作するAWS Elastic Beanstalkの環境を、指定したメンテナンス時間帯に、自動的に最新のバージョンに更新するよう選択出来るようになりました。Elastic Beanstalkは、サポートされるプラットフォーム（Java, PHP, Ruby, Node.js, Python, .NET, Go, およびDocker)の新しいバージョンを定期的にリリースしています。こちらには、オペレーティングシステム、ウェブおよびアプリケーションサーバ、言語やフレームワーク等の更新も含まれます。以前は、Elastic Beanstalkコンソール、コマンドラインインタフェース（CLI）、またはAPIを使って手動でElastic Beanstalkの環境の更新を開始しなければいけませんでした。本日より、シンプルに1週間ごとにメンテナンス時間帯を選択して、その時間帯で自動的に環境のプラットフォームバージョンを更新させることが出来るようになりました。 管理されたプラットフォームの更新により、アプリケーションを動作させるプラットフォームへパッチ適用したり、更新し続けるようを気を付ける必要はなくなりました。Elastic Beanstalkは、エンドユーザーへの影響は最小限になるように安全な形で更新を行います。この更新はimmutableデプロイメントメカニズムを使用します。こちらにより、Elastic Beanstalkは同様のAmazon EC2インスタンス群を起動して、環境を交換して既存のインスタンスを終了する前に更新をインストールします。もしElastic Beanstalkのヘルスシステムが更新の間に問題を検知した場合には、アプリケーションのエンドユーザーへのインパクトを最小限に保ちつつ、既存のインスタンス群にトラフィックを向け直します。 Elastic Beanstalkは新しいパッチとマイナープラットフォームのバージョンの更新を自動的に実行できます。環境ごとに異なるメンテナンス時間帯をスケジュール可能です。また定期的にスケジュールが組まれたメンテナンス時間帯以外でアップデートを開始させることも可能です。Elastic Beanstalkは、(例：Java 7 Tomcat 7 からJava 8 Tomcat 8への）メジャーバージョンアップデートを自動的に実行しません。その理由は、メジャーバージョンののアップデートには非互換の変更や追加のテストが必要な場合があるためです。こちらの場合は、手動でアップデートを開始する必要があります。 利用開始するには、Elastic Beanstalkコンソールの設定タブ、EB CLIまたはAPIで、管理されたプラットフォームの更新を有効にしなければなりません。管理されたプラットフォームの更新についての詳細は、ドキュメントまたはFAQをご覧ください。 Elastic Beanstalkの詳細： 製品ページ ドキュメント リリースノート プラットフォームサポートリスト 翻訳は舟崎が担当しました。原文はこちらです。

いくつかのAWSチームは、オンプレミスのデータをクラウドへ移動する処理を簡素化し、高速化することにフォーカスしています。当初はとてもベーシックなPUTのオペレーションとマルチパートアップロード機能のご提供から始めて、ディスクを送付する方法をご提供し、昨年のAWS re:Inventで、AWS Import/Export Snowballをローンチすることでそのプロセスはより簡素化されました。(AWS Import/Export Snowball – Amazon所有のストレージアプライアンスを利用して1週間あたり1ペタバイトのデータ転送を実現を参照下さい。) 本日、S3とSnowballに関する重要な改善についてお伝えします。この改善はどちらもデータ移行プロセスをよりシンプルに、より加速させるようデザインされています。以下が新しい機能になります。: Amazon S3 Transfer Acceleration – この新機能はAWSのエッジロケーションとネットワークプロトコルの最適化を利用し、S3へのデータ転送を高速化します。大きなオブジェクトを国を跨いで転送する場合、50%から500%の改善、もしくは特定の環境下ではそれ以上の高速化を見込むことができます。 より大きなSnowballをより多くのリージョンで – より大きなキャパシティ(80TB)のSnobwballが利用可能となりました。加えて、新たに2つのUSリージョン、および2つのインターナショナルリージョンでご利用頂くことができるようになりました。 Amazon S3 Transfer Acceleration 現在AWSは50箇所以上ののエッジネットワークを提供しています。今までは、Amazon CloudFrontによるコンテンツの配信やAmzon Route53による高速なDNSクエリの応答に利用されてきました。本日のアナウンスにより、S3へ、もしくはS3からのデータ転送の高速化にエッジネットワークが活用されます。もしあなたが、高速なインターネット回線を持ち、大容量のオブジェクトもしくは、大量のコンテンツを地域間で転送する際に、その恩恵を受けることが可能となります。 エッジネットワークを、あなたのアップロード場所(デスクトップもしくはオンプレミスのデータセンター)とターゲットのS3 Bucket間のブリッジとして利用いただけます。Bucketにてこの機能を有効にする(AWSマネージメントコンソールのチェックボックスをチェックする)ことで、簡単にBucketのエンドポイントをBUCKET_NAME.s3-accelerate.amazonaws.comのように変更することができます。それ以外の設定は不要です。設定後は、TCPのコネクションが自動的に最寄りのAWSのエッジロケーションにルーティングされます。S3 Transfer AccelerationによりAWSが管理するバックボーンネットワークと効率化されたネットワークプロトコル、エッジとオリジン間のパーシステント接続、最大化された転送ウィンドウなどを活用し、S3へのアップロード転送を行います。 下記が、自分のBucketに対してTransfer Accelerationを有効化する方法になります。(jbarr-public): 私のBucketのエンドポイントはhttps://jbarr-public.s3.amazonaws.com/でしたが、ツールやコードのエンドポイントをhttps://jbarr-public.s3-accelerate.amazonaws.com/に変更するだけです。これだけで、アップロードを行うとS3 Transfer Accelerationの恩恵をうけることができます。また同じルールで構成されたURLを利用することで、ダウンロードも高速化することが可能です。 ネットワーク設定や環境は日々もしくは場所により常に変動することから、Transfer Acceleration によりアップロードパフォーマンスが改善する可能性がある転送の場合のみ費用をお支払いいただきます。高速化転送は、GBアップロードあたり$0.04から課金されます。またS3の他の機能同様、初期費用および長期的なコミットメントは不要です。 新たに提供するAmazon S3 Transfer Acceleration Speed Comparisonを利用することで、Transfer Accelerationの効果を確認いただくことができます。私のUS West(Oregon)リージョンにあるAmazon WorkSpacesで実行した結果が下記となります： 距離に応じた、自分のリージョンからターゲットへの高速化の割合が確認いただけるかと思います。 本機能に関してより詳細を確認したい場合は、S3 開発者ガイドのGetting Started with Amazon S3 Transfer Accelerationを参照してください。本日より北京(中国)リージョンおよびAWS […]

Amazon Kinesis はストリーミングデータをクラウド上で簡単に扱えるようにします。 Amazon Kinesis プラットフォームは3つのサービスから構成されています：Kinesis Streams によって、開発者は独自のストリーム処理アプリケーションを実装することができます；Kinesis Firehose によって、ストリーミングデータを保存・分析するための AWS へのロード処理がシンプルになります；Kinesis Analytics によって、ストリーミングデータを標準的な SQL で分析できます。 多くの AWS のお客様が、ストリーミングデータをリアルタイムに収集・処理するためのシステムの一部として Kinesis Streams と Kinesis Firehose を利用しています。お客様はこれらが完全なマネージドサービスであるがゆえの使い勝手の良さを高く評価しており、ストリーミングデータのためのインフラストラクチャーを独自に管理するかわりにアプリケーションを開発するための時間へと投資をしています。 本日、私たちは Amazon Kinesis Streams と Amazon Kinesis Firehose に関する3つの新機能を発表します。 Elasticsearch との統合 – Amazon Kinesis Firehose は Amazon Elasticsearch Service へストリーミングデータを配信できるようになりました。 強化されたメトリクス – Amazon Kinesis はシャード単位のメトリクスを CloudWatch へ毎分送信できるようになりました。 柔軟性 – Amazon […]