Amazon Web Services ブログ

AWS Health Tools リポジトリを発表

今回は 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 […]

Read More

Amazon RDS – 2016 を振り返る

昨年は 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 用のマルチ […]

Read More

Streamlineのケーススタディ:Amazon GameLiftで加速リリース

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

Read More

JSONSerDe によるマッピングを使って,入れ子の JSON から Amazon Athena のテーブルを作成する

多くのシステムでは、イベント情報を記録するのに 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”], […]

Read More

AWS クイックスタートの更新 – Tableau、Splunk、Compliance、Alfresco、Symantec

AWS クイックスタートは AWS で人気のソリューションのデプロイをサポートします。各クイックスタートは AWS のソリューションアーキテクトやパートナーが設計し、セキュリティや高可用性における AWS のベストプラクティスを活用しています。テストまたは本番稼働環境ですぐにクイックスタートをご利用いただけます。シングルクリックで起動できるクイックスタートには、広範囲にわたる内容を取り上げたデプロイメントガイドと テンプレートが含まれています。クイックスタートは次の 7 つのカテゴリに分類されています。 開発運用 データベースとストレージ ビッグデータと分析 セキュリティ & コンプライアンス Microsoft & SAP ネットワークとアクセス その他 過去 2 か月間で 6 つの新しいクイックスタートをコレクションに追加し、合計数は 42 件になりました。次に、新しいクイックスタートの各カテゴリの概要をご紹介します。 Tableau Server (ビッグデータと分析) AWS クイックスタートの Tableau Server は で完全に機能する Tableau Server のデプロイをサポートします。デフォルト VPC でシングルノードを起動したり、新規または既存の VPC でマルチノードクラスターのデプロイメントができます。クラスターアーキテクチャについてはこちらをご覧ください: CloudFormation テンプレートは Tableau アクティベーションキーについてもプロンプトを表示します。 Splunk Enterprise (ビッグデータと分析) AWS クイックスタートの Splunk […]

Read More

SAP Database Migration Option(DMO)を使ったAWSへの移行

Somckit Khemmanivanhは、Amazon Web Services (AWS)のSAPソリューションアーキテクトです。 このブログ記事では、SAP Software Update Manager(SUM)の機能であるDatabase Migration Option(DMO)を使って、AnyDBデータベースからAWS上のSAP HANAに移行する方法を説明します。SAPでは、SAP社がサポートするSAP HANA以外のソース・データベース(DB2、Oracle、SQL Serverなど)を指すときに、AnyDBという用語を使用しています。ここでは、オンプレミス・アーキテクチャからAWSへの移行オプションについて説明します(ここで留意すべきは、SAP HANAがターゲット・プラットフォームでない場合、他にも多くの移行オプションがあることです。詳細はホワイトペーパーMigrating SAP HANA Systems to X1 Instances on AWSをご覧ください)。 SAP HANAは完全なインメモリーで、列指向に最適化され、また圧縮されたデータベースです。 SAP社により認定されたSAP HANAシステムでは、160+ GB RAMから2TB RAMまでのシステムでSAP HANAデータベースをスケールアップ構成として稼働できます。また、最大14TBまでの認定されたスケールアウト構成も利用可能です。AWSであれば、このシステム構成の柔軟性により、ビジネスとITのニーズに合わせて拡張することができます。もしこれ以上のメモリーを要求するワークロードがある場合は、ぜひご連絡ください。私たちは、お客様要件にお応えできるよう取り組みたいと考えています。 DMOの概要については、SAP Community Networkをご覧ください。大まかには、AnyDBで稼働するSAPシステムをSAP HANAデータベースに移行する際にDMOを使うことができます。また、DMOにより、SAPシステムのソフトウェア・アップグレードとユニコード変換を移行時に合わせて行うこともできます(Enhancement Package(EHP) 8以降、ユニコードは必須)。 標準的なDMOのプロセスでは、ソースのAnyDBをターゲットのSAP HANAデータベースにオンラインかつ直接移行します。 図1: SAP HANA DMOのプロセス 移行先がAWS上のSAP HANAシステムである場合、この直接の移行プロセスを容易にするためにネットワーク接続を確立する必要があります。加えて、標準的なDMOのプロセスにおいて、SAP Note 2277055 – Database Migration Option (DMO) of SUM 1.0 […]

Read More

AWSでの疎結合データセットの適合、検索、分析

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する(あるいは反論する)ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています(例えば、日時が間違っている、地理座標が間違っているなど)。 最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。 データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。 関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。 このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。 異なる3つのデータセットを適合させて索引付けし、検索可能にします。 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。 Amazon AthenaやAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

Read More

新機能 – TTL(Time to Live)機能を利用したDynamoDBアイテムの管理について

AWSを利用頂いている多くのお客様にDynamoDBは使用されています。速度と柔軟性がその理由で、Ad Tech( リファレンスアーキテクチャ )、Gaming( リファレンスアーキテクチャ )、IoT( リファレンスアーキテクチャ )、そして一貫した一桁のミリ秒のレイテンシを実現しアプリケーションを構築されています。また、DynamoDBはフルマネージドのデータベースで、テラバイトサイズのテーブルに対して毎秒何百万というリクエストを処理することができます。 多くのDynamoDBユーザーは、利用する時間が限られている、または時間の経過とともにアクセス頻度が低くなるデータを格納しています。 直近のログイン、試用版のサブスクリプション、アプリケーションのメトリックなどへの利用がそうです。 他にも保管できる期間に関する規制または契約上の制限の対象となるデータを保管します。 これまで、これらを実現するには独自の時間ベースのデータ管理を実装していました。 大規模なシステムでは、DynamoDBアイテムのスキャン、期間を管理するための日付属性の確認、および不要になったアイテムの削除要求を行う為のAmazon Elastic Compute Cloud(EC2)インスタンスを構築するなどの必要があり、これによりアプリケーションのコストと複雑さが増加していました。 新しいTime to Live(TTL)管理 について この普及した重要なユースケースを合理化するため、新しくTTL(Time to Live)機能の提供を開始しました。 アイテムの有効期限を属性で指定する事により、テーブル単位でこの機能を有効にすることができます。 属性が指定され、TTL管理が有効になると(1回のAPI呼び出しで両方の操作が処理されます)、DynamoDBは期限切れのアイテムを見つけて削除します。 この処理は、自動的かつバックグラウンドで行われ、テーブルへの読み取りまたは書き込みトラフィックには影響しません。 DynamoDBストリームを使用することで(詳細は、「 DynamoDBアップデート – トリガ(Streams + Lambda)+クロスリージョンレプリケーションアプリケーション」を参照)。実際の削除を処理またはアーカイブすることができます。 ストリーム内の他の更新レコードと同様に、削除は24時間単位で行われます。 AWS LambdaおよびDynamoDB Triggersを使用して、期限切れのアイテムをコールドストレージに移動したり、ログに記録したり、他のテーブルを更新したりすることができます。 テーブルのTTLを有効にして、必要な属性を指定する方法は次のとおりです。 指定する属性はDynamoDBのNumber型かつ、 UNIX時間でTTLの指定を行います。 上のスクリーンショットからわかるように、DynamoDB Streamsを有効にすることもできます。また、TTLを有効にすると削除されるアイテムのプレビューを見ることもできます。 また、コードからUpdateTimeToLive関数を呼び出しテーブルにTTLの有効化設定することも、 AWSコマンドラインインターフェイス(CLI)からupdate-time-to-liveコマンドを使用しテーブルでTTLを有効化設定することもできます。 TTL の利用事例(TUNE様)  AWSのお客様であるTUNEは既に、この機能をHasOffers製品の一部として活用しています。 HasOffersは、マーケティングキャンペーンの効果を分析し、大量の広告エンゲージメントデータをプロセスに保存するのに役立ちます。 キャンペーンの顧客定義の時間枠が過ぎると、データは不要になり、削除することができます。 TTL機能をTUNEで使用できるようにする前は手動で期限切れアイテムを識別し、古いデータを削除しました。 これは労力と激しく計算を必要とし、テーブルのプロビジョニングされたスループットの一部も消費する必要がありました。 今は各アイテムの有効期限を設定し、あとはDynamoDBに任せます。 失効したデータは自動的に消え、使用可能なスループットには影響しません。 その結果、TUNEは85テラバイトの古いデータを削除することができ、年間200,000ドル以上のコストを削減し、アプリケーションロジックも簡素化しました。 知っておくべきこと あなたのアプリケーションにTTLを使用することを検討する際、留意すべきことがいくつかあります。 […]

Read More

(速報) 2016年AWS Partner Network(APN) Award発表!

みなさん、こんにちは。Partner SA 酒徳です。 本日、東京ミッドタウン カンファレンスホールにてAWS Partner Summit 2017 – Japan が開催され、昨年2016年の功績を讃え、APN Awardの授与式も同時に行われました。 APN Awardは一年を通し、各分野において最もパフォーマンスを発揮されたAPNパートナー様が受賞されるアワードで、今年は下記5つの分野において受賞パートナー様が選出されました。 APN Awardを授与されましたパートナー様とその授与内容についてご紹介させて頂きます。 – APN Partner of the Year 2016 年間を通じて営業・技術・マーケテイング分野等のパートナーとしての総合力で判断し、 AWSのビジネスに最も貢献いただいたAPNパートナー様が受賞 – APN Rising Star of the Year 2016 APNに加入して頂き1年目にして、AWSビジネスに最も高く貢献頂いたAPNパートナー様が受賞 – APN Cloud Business of the Year 2016 AWSが企業のビジネスに大きく貢献いただき、市場に大きな影響を与えたAPNパートナー様が受賞 – APN Architecture of the Year 2016 AWSの利用アーキテクチャがクラウド利用上優れているものの中から、最も先進的、実用的、チャレンジングなものをAWS のソリューションアーキテクトが選定。同システムを構築したAPNパートナー様が受賞 – APN Reference […]

Read More

シャーディングされたシステムをAuroraに集約してリソースの消費を削減

リレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと2つの手法が上げられます。一般的にスケールアップの方が簡単に行えます(単純にスペックのいいマシンを購入するなど)。一方スケールアウトは、それぞれ独立したホストで稼働している複数のサーバへ、データベースをシャーディングする必要があり作業が煩雑になります。 難しさにも関わらずスケールアウトとが最近のトレンドとなってきています。コモディティハードウェアとシステムリソースへの要求の増加に伴いワークロードを効率的にシャーディングする必要が出てきました。シャーディングされたシステムの1つの欠点として管理コストがあげられます。もし4つのシャードを持っているとすると、4つのデータベースを管理する必要があります。しかし、たとえそうだとしてもスケールアウトはスケールアップよりコスト効率がいい場面が多かったのです。特にAmazon RDSの様なマネージドデータベースの登場によりリレーショナルデータベースの管理を軽減することが出来るようになったのがその1つの要因です。 しかし、なぜ過去形なのでしょうか? Amazon Auroraの登場によりスケールアップという選択肢が戻ってきたのです。Amazon Auroraは非常にスケールし、MySQL互換のマネージドデータベースサービスです。Auroraは2 vCPU/4 GiBメモリというスペックのインスタンスから、32 vCPU/244 GiBメモリ搭載のインスタンスまでを提供しています。Amazon Auroraは需要に応じてストレージが10 GBから64 TBまで自動的に増加します。また、将来のリードキャパシティの増加に備えて15インスタンスまで低遅延のリードレプリカを3つのアベイラビリティーゾーンに配置することが可能です。この構成の優れている点は、ストレージがリードレプリカ間でシャーディングされている点です。 シャーディングされたシステムを1つのAuroraインスタンスに集約、もしくは少数のシャードに集約しAuroraで稼働させることで多くのコストを節約する事が可能です。これがこのブログポストでお話したいことの全てです。 シャーディングされたシステムをAuroraに集約するために – まずはじめに – 多くのシャーディングされたシステムは標準的な方法で行うことが可能です。データはカスタマーIDなどの特定のキーを元に分割されており、何かしらマッピングを行う機能を用いてシャードに分割されています。この方法には様々な種類があり、1例として参照用のデータを別のシステムか1つのシャードに格納したり、全てのシャードに参照用のデータを配置するなどがあります。どのようにデータを分割しても、シャーディングの複雑さは通常、アプリケーションレイヤーにあり、シャードの統合は比較的容易に行えます。 多分皆さんは今、”利点はわかった。ではどうやってAuroraにデータを移行するのか”という疑問をお持ちかと思います。今回の例では、MySQLを利用して4つのシャードを持つシステムを利用していると仮定したいと思います。また、各シャードは他のシャードが持っているデータを持っていないものとします。また1つのシャードが参照用のデータを持っている前提とします。現在の構成は以下の図の様な構成になっていると思います。mapは各シャードへのアプリケーショントラフィックを表しています。 MySQLを運用しているため、Aurora documentationに記載されている方法を利用を利用可能です。簡単に移行を行うために、まずはじめに参照データのみが格納されているインスタンス1を移行します。しかし、どのシャードを最初に移行するかはそれほど重要ではありません。 移行が完了すると、マッピング機能はインスタンス1ではなくAuroraインスタンスを指します。システムは次の図のようになります。 残りのデータを移行する この時点で、Auroraが特定のワークロードをどれくらいうまく処理しているか評価し、必要な調整を行う必要があります。設定に問題がなくなれば、他のデータを移行する準備は完了です。では、シャード2をAuroraインスタンスに移行しましょう。しかし、どうやって?   AWS Database Migration Service (AWS DMS)を是非ご活用下さい!AWS DMSはこのようなマイグレーションにも対応するように作られました。シャード2からAuroraインスタンスへデータをコピーするためにDMSをご利用になれます。更に、シャード2にとランアクションを実行しながらこれらの作業が可能です。DMSは初期データのロードが完了すると、それらのトランザクションデータをシャード2から収集しAuroraインスタンスに適用します。DMSは継続的にシャード2からAuroraインスタンスへデータを移行し、シャード2の代わりにAuroraインスタンスの利用を開始させるまで同期させます。シャード2からAuroraインスタンスへ切り替える準備が出来たら、シャード2へのトランザクションを停止し、DMSが最後のトランザクションをAuroraインスタンスへ適用するまで待ち、mapの設定を、シャード2に向いていたトラフィックを直接Auroraインスタンスへ向くように変更します。設定が完了すると、システムは以下のような状態になります。 この時点から、Database Migration Serviceを残り2つのシャードをAuroraインスタンスへ移行するために利用出来ます。最終的にシステムは以下の様になります。   複雑なシャードの扱い方 これでシャーディングされたシステムが1つのAuroraインスタンスへマイグレーションが完了し、コストを削減することが出来ました!しかし、MySQLを利用し、クリーンなシャードを利用しているとう仮定で話をすすめてきました。もしこれらの仮定にそぐわない場合はどうでしょうか? それでは、シャードがクリーンな状態でない場合を見ていきましょう。例えば、システムが最初に2つのシャードで構成されていたとします。ある時点で、その2つのシャードを4つのシャードに分割したとします。 リシャードィングプロセスの一環として、シャード1と2のコピーを作成してシャード3と4を作成し、マッピング機能を更新しました。 結果は次のようになります。 この図は状況が複雑であるように見えます。 理想的には、このようなリシャードィングの際に、シャードに関係のないデータ、つまりグレーアウトされたデータをパージします。 しかし、必ずしも必要というわけではないし、時には難しいこともあるので、データをそのままにしておく事があります。 この方法では使用されていない冗長なデータを保持する”汚れた”シャードが発生します。 これらのシャードを統合しようとすると、アクティブなデータの行が、削除すべき重複した行と衝突する問題が発生します。 何をすべきか? シャードの統合を行う前に、利用していない行を削除することができます。 しかし、特にマッピング関数がID値のハッシュ(一般的な方法の1つ)で構成されている場合、利用していない行を特定するのは難しいかもしれません。 諦めないで下さい! 別のオプションがあるかもしれません。 各シャード内のデータが1つのデータベースに含まれている場合は、DMSを使用して、システムの各シャードをAuroraインスタンス内の単一のMySQLデータベースに統合できます。 次に、既存のマッピング・スキームを使用して、Auroraインスタンス内の適切なデータベースにトランザクションを転送できます。 […]

Read More