Amazon Web Services ブログ

Amazon RDS for MySQLにおいて、MySQLのマイナーバージョン 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23 のサポートを2017年7月19日に終了致します。これらのバージョンはAmazon RDSで2014年10月から2015年6月にかけてサポートされました。そして、新機能やセキュリティ・安定性向上を含んだバージョンに更新されてきました。 現在これらのバージョンをご利用の場合、現在サポートされているMySQLの最新のマイナーバージョン(2017/3/8現在: 5.6.34)にアップグレードを行うことを推奨致します。メジャーバージョンアップグレードと異なり、マイナーバージョンアップグレードはそれ以前データベースエンジンのマイナーバージョンと後方互換性を持っています。 2017年4月5日にAuto Minor Version UpgradeがYesに設定されているDBインスタンスに対して、自動アップグレードを設定致します。アップグレードはこの日以降の通常のメンテナンスウインドウ内で順次実施されます。 2017年7月5日以降に起動しているMySQL 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23バージョンのRDS DBインスタンスは、Auto Minor Version Upgradeの設定に関わらず自動的に最新のマイナーバージョンに、各インスタンスに設定されているにメンテナンスウインドウ内でアップグレードが行われます。 2017年7月19日以降に起動している該当バージョンのRDS MySQLインスタンスは、メンテナンスウインドウに関わらず即座にアップグレードが実施されます。 RDSでのMySQLのマイナーバージョンアップグレードについては、こちらをご覧ください。 不明点などがありましたら、AWS サポートチームへコミュニティフォーラムかサポートセンター経由でご連絡下さい。 今回のアップグレードは、2017年4月5日到来前にアップグレード対象バージョン以上のマイナーバージョンもしくは、メジャーバージョンにアップグレードして頂くことで回避可能です。そのため、テスト環境などでテストを行っていただき、自動適用が開始される前に手動でアップグレードすることをお勧め致します。   原文はこちらをご覧ください。  

本日Amazon Auroraの新機能を2つリリース致しました。 暗号化済みデータベースのクロスリージョンサポート 暗号化済みのデータベースでAWSリージョンをまたいだレプリケーションがサポートされました。クロスリージョンレプリケーションを利用することで、ユーザに近い場所でリードオペレーションを実行することが可能になったり、ディザスターリカバリー環境を簡単に構築出来ます。また、リージョンをまたいだデータベースの移行も容易に行なえます。 また、暗号化されたスナップショットをAWSリージョン間でコピー可能になりました。開発チームとテストチームが様々な地域に分散していたとしても、本番データベースの最新のコピーを安全に共有することによって、グローバルな開発プロセスを構築できます。また、遠隔地にスナップショットを安全に保管することで、ディザスターリカバリー戦略を強化することも可能です。 詳細は、クロスリージョンレプリケーションとクロスリージョンスナップショットコピーのドキュメントをご覧ください。   AWSアカウント間で暗号化済みスナップショット共有をサポート AWSアカウント間で暗号化済みスナップショットの共有が可能になりました。暗号化キーを共有しているアカウントを分離するためにAuroraのセキュリティモデルを拡張出来ます。他のアカウントの所有者は、スナップショットをコピーしたり、スナップショットからデータベースインスタンスを復元することができます。 詳細なドキュメントはこちらをご覧ください。 Amazon Auroraは、フルマネージド、高可用性、コストパフォーマンスのよいリレーショナルデータベースです。MySQLと互換性があるためアプリケーションコードの変更なしに移行が行なえます。また、こちらのツールを利用することでダウンタイムを最小限に移行を行うことも可能です。 翻訳は星野が担当しました。原文は、Amazon Aurora Announces Encryption Support for Globally Distributed Database Deployments, Amazon Aurora Supports Cross-Account Encrypted Snapshot Sharing            

Dr. Jon Handler (@_searchgeek) は検索技術にスペシャライズした Amazon Web Services のプリンシパルソリューションアーキテクトです。 Elasticsearch および Amazon Elasticsearch Service(Amazon ES) のブログポストシリーズへようこそ。ここでは今後もAWS上でElasticsearchをはじめるにあたって必要な情報を提供していく予定です。 いくつのシャードが必要？ Elasticsearchは、大量のデータを、シャードと呼ばれる細かいユニットに分割し、それらのシャードを複数のインスタンスに分散して保持します。Elasticsearchではインデックス作成の際にシャード数を設定します。既存のインデックスのシャード数を変更することは出来ないため、最初のドキュメントをインデックスに投入する前にシャード数を決定しなければなりません。最初はインデックスのサイズからシャード数を算出するにあたって、それぞれのシャードのサイズの目安を30GBにします。 シャード数 = インデックスのサイズ / 30GB インデックスのサイズ算出に関しては、AWS Solutions Architect ブログ: 【AWS Database Blog】Amazon Elasticsearch Service をはじめよう: インスタンス数の見積もり方法をご覧ください。 データの送信やクエリをクラスタに対して行っていく中で、クラスタのパフォーマンスを元に、継続的にリソースのユーセージを評価しながら、シャード数を調整していきます。 シャードとは? サーチエンジンには2つの役割があります: ドキュメントを元にしたインデックスの作成と、インデックスの中からマッチしたドキュメントを引き当てる検索です。インデックスが小さければ一つのデータ構造で一台のマシンで事足りるでしょう。しかし、大量のドキュメントにおいては、インデックスを保存するのに一台のマシンでは足りませんし、ピースに分割されたインデックスから検索結果を求めるためのコンピュート能力も足りません。Elasticsearchではこれらのピースのことをシャードと呼びます。それぞれのドキュメントは計算結果に基いてシャードにルーティングされます。デフォルトではドキュメントのIDのハッシュ値に基づいたルーティングになります。 シャードは ストレージ(storage) の単位であり、また 処理(computation) の単位でもあります。Elasticsearchはシャードを独立した形でクラスタ内のインスタンスにデプロイし、インデックスの処理をそれぞれで並列に行います。Elasticsearchという名前の通り”elastic”なものであると言えるでしょう。クラスタにインスタンスを追加する場合、Amazon Elasticsearch Serviceは自動的にシャードのリバランスを行い、クラスタ内のインスタンスにシャードを再配置します。 ストレージ(storage)においては、シャードはそれぞれ別のもの(distinct)です。シャード内のドキュメントは、他のシャードに重複して保持されることはありません。このアプローチによってシャード毎の独立性を保っています。 処理(computation)においても、シャードはそれぞれ別のもの(distinct)です。それぞれのシャードはドキュメントが処理されて生成されたApache Lucene indexのインスタンスです。インデックスには全てのシャードが含まれるため、クエリや更新リクエストのプロセスにおいて、それぞれのシャードはお互いに協調して機能する必要があります。クエリのプロセスにおいては、Elasticsearchはインデックス内の全てのシャードにクエリをルーティングします。それぞれのシャードはローカルで個別に処理を行い、それぞれの結果をアグリゲートして最終的にレスポンスします。書き込みリクエストにおいては(ドキュメントの追加、もしくは、既存のドキュメントの更新)、Elasticsearchはリクエストを適切なシャードにルーティングします。 Elasticsearchには２つの種類のシャードがある Elasticsearchには2つの種類のシャードがあります – プライマリシャードとレプリカシャードです。プライマリシャードは全ての書き込みリクエストを受け付けます。プライマリシャードは新しく追加されたドキュメントをレプリカにパスします。デフォルトでは、書き込みがレプリカに確認(acknowledge)されるのを待ってから呼び出し元に書き込み成功のレスポンスを行います。プライマリとレプリカシャードはデータの保存に冗長性をもたらし、データのロスを起こりにくくします。 この図の例では、Elasticsearchクラスタは3つのデータインスタンスを保持しています。緑と青の2つのインデックスがあり、それぞれ3つのシャードがあります。それぞれのシャードのプライマリは赤枠で囲われています。それぞれのシャードにはレプリカがあり、それらに枠はありません。Elasticsearchはいくつかのルールを元にシャードをインスタンスに配置します。最も基本的なルールとして、プライマリとレプリカのシャードを同じインスタンスに配置しない、というものが挙げられます。 最初にストレージにフォーカスする お客様のワークロードには2つの種類があります: シングルインデックスとローリングインデックス。シングルインデックスのワークロードは、全てのコンテンツを保持する”source of […]

AWS Database Migration Service について初めてブログ (AWS Database Migration Service) を投稿したのは 1 年ほど前のことです。その時点で AWS ユーザー 1,000 人がすでに AWS への移行の一部として同サービスを使用していました。簡単に説明すると、 とスキーマ変換ツール (SCT) は、AWS のお客様が高価な独自のデータベースやデータウェアハウスから、リレーショナルデータをよりコスト効率の良い 、、MySQL、MariaDB、PostgreSQL といったクラウドベースのデータベースやデータウェアハウスに、ダウンタイムを最低限に抑えた状態で移行できるようにサポートします。ユーザーの皆様からは、その柔軟性とコスト効率に優れた点において良い評価を頂いています。たとえば に移行すると、商用データベースに掛かる 10 分の 1 のコストで MySQL と PostgreSQL との互換性を持つデータベースにアクセスすることができます。Expedia、Thomas Publishing、Pega、Veoci といった企業による使用事例は AWS Database Migration Services Customer Testimonials でご覧いただけます。 独自の移行数 20,000 件 AWS のお客様は、これまでに を使用して 20,000 件もの独自のデータベースを AWS に移行しており、現在もその数は上昇する一方です (2016 年 9 […]

銀行、クレジットカード会社、モバイルプロバイダ、その他にも頻繁に使用するサービスの企業などから、パスワードリマインダーやサービスの更新、重要なカスタマーサービス情報について SMS (ショートメッセージサービス) メッセージが送られてきます。AWS のお客様は、ここ何年にもわたり で SMS メッセージを送信してきました (詳細は Amazon Simple Notification Service Now Supports SMS をご覧ください)。こうしたメッセージには、複数の AWS ユーザーが共有する小さな一連の 10 桁の数字が使用されています。Telephone Consumer Protection Act (TCPA) と Common Short Code Administration (CSCA) の規約に基づき、10 桁の数字を使用したメッセージはカスタマーサービスとチャット機能に対応することができますが、更新のリクエストや予定のリマインダー、PIN コードの送信といった application-to-person (A2P) メッセージを使用することはできません。また、顧客はレート制限の対象となり、1 秒につき送信できるのは 1 件のみとなります。こうしたルールと制限は顧客の安全性を保護し、SMS の適用性を制限することもできます。 専用のショートコード ご利用されているアプリケーションで SMS をさらに有効に活用できるようにするため、SMS 専用ショートコードのサポートを追加しました。こうしたコードは専用コードであるため、ブランドの認知度を高めるチャンスにもなります。 で専用の番号 (5 桁または 6 桁) をリクエストできるようになりました。携帯電話会社がユースケースを承認している間 (このプロセスは通常 6 週間から […]

このエディションには当社からのすべてのお知らせ、当社のすべてのブログのコンテンツ、およびコミュニティで作成された AWS コンテンツをできるだけ多く含めました。今後、ツールや自動化の準備が整い次第、他のセクションもご紹介していきたいと思っています。 月曜日 2 月 27 日 AWS 組織 – 複数の AWS アカウント向けのポリシー管理を一般公開しました。 有効期限 (TTL) を使用した DynamoDB アイテムの管理が可能になりました。 Amazon Aurora リリース 1.11 が利用できるようになったことを発表しました。 EC2 スポットアドバイザーと EC2 スポット群のヘルスチェックをリリースしました。 がシャーディングしたシステムを Aurora で統合しリソース消費を低減させる方法を公開しました。 が Amazon S3 でマルチパートアップロードのライフサイクルルールを自動化する方法を公開しました。 CloudCheckr がニューヨーク州ロチェスターの AWS ユーザーグループの改善について語りました。 火曜日 2 月 28 日 2017 年 2 月の AWS ホットスタートアップを公開しました。 が Amazon Elasticseach Service を開始する上で必要なシャード数についてブログを公開しました。 […]

今回は Tipu Qureshi と Ram Atur を迎え、AWS Health / Personal Health Dashboard の Git リポジトリに関する最新情報についてご紹介します。 -Ana 改善操作の自動化やヘルスアラートのカスタマイズを可能にするコミュニティベースのツールソース、AWS Health Tools のリポジトリを本日リリースしました。AWS Health サービスは、AWS インフラストラクチャに影響するイベントにおいてユーザー独自の情報を提供します。これにより、予定済みの変更を実施しやすくしたり、ユーザーの AWS リソースやアカウントに関する問題のトラブルシューティングを促進することができます。また、AWS Health API は AWS リソースの基盤となる AWS サービスのパフォーマンスや可用性について、各ユーザーに適した情報を表示する Personal Health Dashboard を提供します。さらに Amazon CloudWatch イベントを使用すると、AWS Personal Health Dashboard (AWS Health) イベントのステータスで変更を検出し対応することができます。AWS Health Tools は AWS Health、Amazon CloudWatch イベント、AWS Lambda の統合を活用し、AWS インフラストラクチャに関するイベントへの対応の自動化をカスタマイズすることもできます。たとえば、AWS […]

昨年は 294 件のブログを公開しましたが、取り上げることができなかった紹介に値するリリースはいくつもありました。そこで今回は に焦点を当て、このファミリーが 2016 年に進歩を遂げたすべてのポイントに関する総集編をお届けします。去年、同チームは 4 つの主なエリアに注目しました。 高可用性 拡張モニタリング セキュリティの簡略化 データベースエンジンの更新 では、これらのエリアを見ていきましょう。 高可用性 リレーショナルデータベースは様々なタイプのアプリケーションにおいて、その中心にあります。高可用性の高いアプリケーションをお客様が構築できるようにするため、RDS は 2010 年初期からマルチ AZ サポートを提供しています (詳細は Amazon RDS – Multi-AZ Deployments For Enhanced Availability & Reliability をご覧ください)。データベースインスタンスの作成時にマルチ AZ 配置を選択すれば、複数のインスタンス設定、レプリケーションのアレンジ、ネットワーク、インスタンス、ネットワーク問題などの検出に使うスクリプトを書いたり、フェイルオーバーの決断や新しいセカンダリインスタンスをオンラインにするために、何週間にもわたりセットアップにかける時間を省くことができます。また、RDS はクロスリージョンリードレプリカを作成しやすくします。高可用性を実現しやすくするため、AWS が 2016 年に行ったその他の機能強化については次のブログをご覧ください。 RDS SLA が Amazon RDS for MariaDB を対象に Amazon RDS がアジアパシフィック (ソウル) AWS リージョンで SQL Server 用のマルチ […]

Proletariatについて ボストンに拠点を置くProletariatは、革新的なマルチプレイヤー体験の構築に焦点を当てたインディーゲーム企業です。5人のゲーム業界のベテランによって2012年に設立されました。彼らは、賞を獲得したWorld Zombinationの立案者です。World Zombinationは、プレイヤー同士が共に戦略を立て合ってゾンビや人間の大群を用いて街を破壊したり守ったりする巨大なオンラインゲームです。彼らの最新のマルチプレイヤーゲームであるStreamlineは、オーディエンスのインタラクティブなゲーム参加が特徴であり、ストリーミング配信者や視聴者が試合中にゲームプレイルールをリアルタイムに変更することができます。 課題 Proletariatは、3月のGDC 2016でStreamlineを公表し、ゲームストリーマーのプレミアムイベントである9月のTwitchCon 2016でベータ版を公開する予定であると告知していました。しかし、TwitchCon 2016のTwitch Prime一般公開に含めないかという話をAmazonが持ちかけたところ、ProletariatはStreamlineを誰でもプレイできるようにするために開発を加速することを決めました。彼らは興奮する一方で、自分たちの独自のゲームサーバソリューションが、管理に手間がかかり過ぎることと増加していくプレイヤー需要をサポートするために必要な機能が足りていないことを気にしていました。 Proletariatの独自のクラウドソリューションはAWS Elastic Container Service (ECS)を中心に構築されていました。AWS ECSは、AWS EC2インスタンス上のアプリケーションの管理を容易にしてくれるコンテナ管理のサービスです。サーバのヘルスチェックを実行したりプレイヤーを利用可能なゲームサーバに接続するなど、彼らは基本的なゲームサーバの機能を手動で操作していました。これらのプロセスによってプレイヤーの負荷が処理されますが、Streamlineが一般利用可能になってしまえば管理は手間がかかり過ぎるでしょう。また、彼らの独自のクラウドソリューションは、どのゲームサーバがアクティブなゲームセッションを保持しているかというこを特定することができませんでした。これは、サーバのキャパシティを手動で調整している間に誤ってアクティブなゲームセッションを縮小し、プレイヤーをStreamlineから切断してしましまう可能性があることを意味していました。単一のEC2インスタンス上で複数のゲームサーバプロセスを実行することができないので、テストをシンプルにすることも困難でした。各ゲームサーバはユニークな公開ポートを必要としますが、コンテナ内部からはその公開ポートを取得することができませんでした。 Proletariatは、ゲームサーバのホスティングにAWSの実績のあるインフラストラクチャを使い続けることを希望していましたが、必要な機能を構築するには数千時間はかかりそうでした。あっという間ににTwitchCon 2016の開催は近づき、ProletariatはAmazon GameLiftを紹介されました。Amazon GameLiftはAWSのマネージドサービスです。ゲームサーバのホスティングをシンプルにしサーバキャパシティを数分でスケールします。 「Proletariatのチームにとって選択肢は非常にシンプルでした。つまり、我々のクラウドインフラストラクチャを構築するのに数ヶ月を費やすためにエンジニアチームを雇うか、あるいはAmazon GameLiftで数分でデプロイするか、です。」とProletariat社CEOの Seth Sivakは言いました。 実装 Proletariatは、Amazon GameLift Server SDK for C++をダウンロードしUnreal Engineゲームサーバのビルドに統合し、ゲームサーバをAmazon GameLiftにアップロードしました。Unreal Engineゲームサーバを格納するために、5つのGameLiftインスタンスタイプのどれが自分たちのニーズに最も適しているかを判断する必要がありました。「リアルタイムゲームでは、ネットワークが最適化されたAmazon GameLiftインスタンスが必要でした。そのため、私達は一連のインスタンスにc4.xlarge.gameliftを選択しました。」とStreamlineのリードエンジニアである Cauê Waneck は言いました。「Amazon GameLiftは、各インスタンス上で4つのゲームサーバをサポートするように実行設定を構成することができます。これは、私達のゲームサーバがシングルスレッド構成であることを考えると完璧です。これにより、vCPUあたり1つのゲームサーバプロセスをうまく活用できるようになり、テストとイテレーションのプロセスが大幅にシンプルになります。」 独自に作成したNode.jsのマッチメイキングシステムとAmazon GameLift上のC++のゲームサーバ間のゲームセッションの新規作成を管理するために、ProletariatはAWS JapaScript SDK with Amazon GameLiftを使用しました。また、彼らはクイックマッチに利用可能なキャパシティを持つゲームサーバを見つけるために特殊なゲームセッションデータを使用しました。このデータは、サーバが新規プレイヤーを受け入れるべきかどうかを分類し、どのゲームセッションが利用可能なプレイヤースロットを持っているかを特定するのに役立ちました。「Amazon GameLiftは、大量のプレイヤーのマッチメイクを容易にし、待ち時間を減少させました。」とWaneckは言いました。「さらに、ゲームセッションをパーティーリーダーに関連付けるということが可能だったので、プレイヤーにカスタムゲームマッチの開催を可能にするというかたちでも役に立ちました。」 Proletariatは、アクティブなゲームを保持するインスタンスがスケールダウンされてプレイヤーをオフラインにしてしまうことを防ぐために、Amazon GameLift組み込みのゲームセッション保護の有効化も行いました。「Amazon GameLiftは保険のようなものです。サーバのスケーリング、とりわけ起動時のスケーリングにおいて安心を与えてくれます。」とWaneckは言いました。 AWS Command Line Interface […]

多くのシステムでは、イベント情報を記録するのに Java Script Object Notation (JSON) を使っています。JSON は効率的かつ柔軟ではありますが、JSON から情報を取り出すのは面倒です。 この投稿では、ログデリバリー手段としての Amazon Kinesis Firehose、ログ保存先としての Amazon S3、データの加工整形やデータベースへの挿入なしに ログに対して JSONSerDe を使って SQL クエリを投げる手段としての Amazon Athena を、緊密に連携させます。これらの処理は、完全にサーバーレスで行われます。コンピューティングリソースを準備する必要はありません。 Amazon SES を使えば、サービス間の全メッセージに対する詳細なログが入手でき、SES イベント発行によって、それを Firehose でも利用することができます。しかし、トレンドやコンプライアンスのデータに関する詳細ログのパースには、多額のインフラ投資や開発期間が必要となります。Athena は保存されているデータに対して、そのままのフォーマットで、コードを書いたりアーキテクチャ設計をしたりすることなく直接クエリできることにより、こうしたデータ探索に非常に適しています。その上、Athena では多くの標準 SQL クエリとシンタックスが利用可能です。 ウォークスルー: データセットの作成 まず、以下のような SES 送信イベントのデータセットをみてみましょう。 { “eventType”: “Send”, “mail”: { “timestamp”: “2017-01-18T18:08:44.830Z”, “source”: “youraddress@example.com”, “sourceArn”: “arn:aws:ses:us-west-2:111222333:identity/youraddress@example.com”, “sendingAccountId”: “111222333”, “messageId”: “01010159b2c4471e-fc6e26e2-af14-4f28-b814-69e488740023-000000”, “destination”: [“success@simulator.amazonses.com”], […]