Amazon Web Services ブログ

New – AWS マネジメントツールのブログ

過去数年で AWS ブログのコレクションが拡大しました。右側のリストをご覧になれば分かるように、現在では実に幅広い様々なトピックや開発ツールに関するブログをご提供しています。また英語以外の言語でも、AWS ブログをご覧いただくことができます。コレクションに最近追加されたブログは AWS Management Tools Blog です。このブログでは AWS ツールを取り上げ、ユーザーがプロビジョン、設定、モニタリング、トラックのサポートや AWS のコスト管理、大規模なオンプレミスリソースの管理について説明しています。今後ブログで紹介予定のトピックには、機能の更新に関する技術的な詳細情報、ヒントやトリック、サンプルアプリ、CloudFormation テンプレート、ユースケースのディスカッションなども含まれています。ブログ開始当初の投稿をいくつか以下にご紹介します。

こうした便利な内容をお届けするコンテンツを毎回見逃さないようにするには、ブログの RSS フィードへの登録をご検討ください。

Jeff;

Pollexy – Amazon Polly と Raspberry Pi で構築した特別なニーズをサポートする音声アシスタント

4 月は Autism Awareness month (自閉症啓発月間) です。米国では 68 人中に 1 人の子供が自閉症スペクトラム障害 (ASD) と診断されています (2014 年 CDC 調査)。 今回のブログでは AWS のシニア DevOps クラウドアーキテクトの Troy Larson が、息子の Calvin をサポートするために取り組んでいるプロジェクトについて紹介します。これまでにも、AWS がどのようにしてこれほどたくさんの様々なアイデアを出し合えるのか聞かれたことがあります。場合によっては、とても個人的な理由で大切な誰かの役に立ちたいという願いからアイデアが浮かぶこともあるのですが、この Pollexy はまさにその例です。まずは Pollexy に関する記事を読んでから、こちらの動画をご覧ください。 -Ana


背景

私はここ何年もの間、自閉症で会話の少ない 16 歳のティーンエイジャーの親であるコンピュータプログラマーとして、どうにかテクノロジーを使ってより安全で幸せかつ快適な暮らしをつくることができないかと常に模索していました。このプロジェクトのチャレンジとなる根源は、人との交流におけるすべての基本、つまりコミュニケーションです。息子の Calvin は口頭による指示には反応しますが、責任を持って発言することができません。彼のこれまでの人生において、私達が会話をしたことは一度もないのです。自分の部屋で一人で遊んでいることはできても、すべてのタスクや一連のタスクをこなすには、他の誰かが口頭で彼に促す必要があります。我が家には他にも子供がおり、家庭内で担当するその他の役割もありますから、Calvin にかかりっきりになることで家庭内の雰囲気に負の影響が出てしまうことも否めません。

事の発端

去年開催された re:Invent で Amazon PollyAmazon Lex のことを初めて耳にしてから、すぐにこうした技術を活用してどのように息子をサポートできるか考え始めました。息子は人による口頭指示に対しては問題なく対応することができますが、デジタル音声を理解することはできるのだろうか? という疑問がありました。そこで、ある土曜日に Raspberry Pi を息子の部屋に設定し、ドアを閉め、息子に気付かれないように家族と一緒に様子をうかがってみることにしました。Raspberry Pi に接続し、聞き慣れた西海岸の発音による Joanna を選び Polly を介して息子に問いかけてみました。「Calvin、トイレ休憩の時間だよ。部屋から出てトイレに行きなさい。」すると、数秒後に息子の部屋のドアノブが回る音がしました。我々家族は思わず隠れていた場所から頭を出して覗いてみると、息子はよく分からないといった顔つきで私をちらりと見て、そのまま Joanna が指示したようにバスルームに向かっていったのでした。Calvin が聞いたことも見たこともない人物の声による指示を聞き、それに応えたことを目の当たりにした私達は驚きで顔を見合わせたほどです。この一件に関するアイデアを同僚達と話し合ったところ、そのうちの一人が、毎年恒例の AWS Sales Kick-Off ミーティングで開催される IoT と AI のサイエンスフェアに参加してみたらどうだろう、と提案してきました。Polly と Lex のリリースから 2 か月そして 3500 ものコードを作成後、Pollexy は (Calvin 同伴) サイエンスフェアでデビューを飾りました。

概要

Pollexy (“Polly” + “Lex”) は Raspberry Pi とモバイルベースの特別なニーズに応える音声アシスタントです。ヘルパーは Pollexy を使用して、音声によるタスクの指示や、定期的に行うスケジュールもしくはオンデマンドのスケジュールに関するメッセージを再生するように設定できます。たとえば、ヘルパーは定期的に服用する薬のリマインダーメッセージをスケジュールしたり、毎時間のトイレ休憩を促すメッセージを設定することができます。また、同時に Amazon Echo とモバイルデバイスを使用して特定のメッセージをすぐに再生するようにリクエストすることも可能です。ヘルパーは相手がメッセージを聞いたか確認するように設定することもできます。たとえば、Pollexy が最初に「青いボタンを押してください (Push the blue button)」と言わない限り、息子は Pollexy に反応しません。息子が青いボタンを押すまで、Pollexy はメインのメッセージを再生しないようになっています。また他の状況では Lex を使用して口頭で応答したり、確認が不要なユーザーもいるでしょう。どちらにしても、自分のニーズに適うように Pollexy をカスタマイズすることができるのです。そしてもっとも重要かつチャレンジとなるポイントは、大きな家に住んでいる場合、メッセージを再生する部屋に相手がいるか確認するにはどうしたらいいのか? という点です。特別なニーズのある大人が離れに住んでいる場合はどうでしょう?リビングにいるのかキッチンにいるのか分からない場合は?相手が複数人いる場合は?屋内にいる複数の人物がそれぞれ別の部屋にいた場合、各自にそれぞれ別のメッセージを送りたい場合はどうでしょう?では、次に基本的な要素と全容についてご説明します。

Pollexy の基本的要素

Amazon のリーダーシッププリンシプルは「Invent and Simplify (発明と簡素化)」です。Amazon では Pollexy アーキテクチャの複雑性を最小限に抑えたいと考えています。Pollexy で連係しているオブジェクトとコンポーネントは、簡単に説明できる方法でそれぞれ 3 つのタイプに分けることができます。

オブジェクト #1: ユーザー

Pollexy でサポートできるユーザー数には制限がありません。ユーザーは独自の特定できる名前です。「確認する」など基本的な事項を設定できます。さらに大きなポイントは場所をスケジュールで特定できることです。つまり、誰かがいる家の特定の場所に対して Outlook のようなスケジュールを作成することができるのです。

オブジェクト #2: 場所

場所はデバイスが物理的に設置されている独自の場所を識別します。ユーザーのロケーションスケジュールをベースに、Pollexy はどのデバイスを順次に使用して連絡するか把握することができます。必要に応じてデバイスを「消音」モードにすることもできます (お昼寝中など)。

オブジェクト #3: メッセージ

もちろん、これが本来の目的です。各メッセージには、ユーザーそして定期的に実行するスケジュールが連携されます (1 回限りのメッセージを除く)。Pollexy はメッセージの再生準備が整うと、ユーザーの場所を確認することができるのでメッセージには場所情報は保存されません。

コンポーネント #1: スケジューラー

メッセージはどれもスケジュールする必要があります。これはコマンドラインツールです。たとえば「Calvin に「午後 8 時までに歯を磨くこと」と伝えてください」と言った場合、このメッセージは DynamoDB に保管され、Lambda 関数のキューイングを待つことになります。

コンポーネント #2: キューイングエンジン

Lambda はスケジューラーを毎秒ごとに実行しチェックして、メッセージがあるか、また再生できるメッセージがあるか確認します。再生するメッセージがある場合、ユーザーの場所のスケジュールを確認してメッセージを再生またはその場所に SQS キューを送ります。

コンポーネント #3: スピーカーエンジン

Raspberry Pi デバイスでは毎分ごとにスピーカーエンジンが起動し、その場所の SQS を確認します。メッセージがある場合、スピーカーエンジンはユーザーの設定を確認しメッセージを再生するためにコミュニケーションを開始します。相手が応答しない場合、スピーカーエンジンはスケジュールでそのユーザーに別の場所が指定されているか確認し、その 2 番目の場所の SQS キューにメッセージを送ります。結果としてメッセージは再生されるか、タイムアウトになります (そのユーザーが 1 日中留守にしている場合など)。

ユーザーへの配慮と自由がキーポイント

私達は大方、個人のプライバシーや個人情報への配慮というものはごく普通のことだと捉えていると思います。特別なサポートを必要としている人達にとって、常に誰かに見られているということは、プライバシーや自由というものがどれだけ欠如している状況であるのか想像してみてください。自閉症と向き合っている人達にとっては、他者が個人のスペースに入り込むことを強く疎ましく思い、場合によってはそれが怒りや不満に繋がることもあります。Pollexy は不満をもたらすことがなく、穏やかな友達といった存在として日常におけるサポートを提供し、ユーザーに自信を持たせながら、誰もが望む個人のプライバシーや自由が尊重されていると思わせることができるツールです。

-Troy Larson

EMRFSを利用して、別AWSアカウントからデータを安全に分析する

分析されるデータは、異なるアカウントが所有するバケットに分散されることがあります。データのセキュリティを確保するためには、適切な認証情報管理が必要です。これは、さまざまな部門の異なるAmazon S3バケットにデータを格納している大企業にとって特に当てはまります。例えば、顧客サービス部門は、研究部門が所有するデータにアクセスする必要があるかもしれませんが、研究部門はそのアクセスを安全な方法で提供する必要があります。

データを保護するこの側面は非常に複雑になる可能性があります。 Amazon EMRは、統合メカニズムを使用して、S3に格納されたデータにアクセスするためのユーザー認証情報を提供します。 EMR上でアプリケーション(Hive、Sparkなど)を使用してS3バケットとの間でファイルを読み書きする場合、S3 API呼び出しには認証するための適切な認証情報で署名する必要があります。

通常、これらの認証情報は、クラスターの起動時に指定するEC2インスタンスプロファイルによって提供されます。そのオブジェクトが異なる認証情報セットを必要とするため、EC2インスタンスプロファイルの認証情報がS3オブジェクトにアクセスするのに十分でない場合はどうなるでしょうか?

このポストは、カスタム認証プロバイダを使用して、EMRFSのデフォルトの認証プロバイダがアクセスできないS3オブジェクトにアクセスする方法を示しています。

(more…)

【開催報告】Amazon Athena Meetup – Startup and AdTech

こんにちは、ソリューションアーキテクトの篠原英治です。

Amazon AthenaおよびAmazon EMRのGeneral ManagerであるRahul Pathakの来日に伴い、AWSをご利用いただいているスタートアップおよびアドテクのエンジニアの皆さまをAWSジャパンのオフィスにお招きしてAmazon Athenaに関する勉強会を開催しました。

Amazon Athena Meetup in Tokyo

 

– Amazon Athenaのご紹介

お客様からいただいたフィードバックからAthenaを開発するに至ったという背景や、フィロソフィー、そして特徴などについて、AWSのBigData関連サービスを担当している事業開発マネージャーの一柳による逐次通訳とともに、ご紹介させていただきました。

Introducing Athena - Rahul and Kenta Introducing Athena - Rahul Serverless

Amazon QuickSightとの連携や、JDBCコネクタを使った実装、Apache ParquetやApache ORCといったカラムナフォーマット利用の推奨、Apache Spark on EMRで既存ファイルをカラムナフォーマットに変換する方法から、実際にご利用いただいているお客様のユースケースのご紹介にいたるまで、多岐にわたる内容となりました。

Athena - QuickSight Athena - ANSI SQL

 

– Q&Aセッション

Q&A形式で活発なディスカッションが行われました。
Athena - Discuss2 Athena - QA1

非常に実践的で詳細なご質問や大変貴重なフィードバックを数多くいただきました。またRafulからもスキャンデータの圧縮によるコスト効率の改善などのTIPSも共有させていただきました。こちらに関しましては、先日データサイエンス領域をメインに担当させていただいているSAの志村が翻訳した『 Amazon Athena のパフォーマンスチューニング Tips トップ 10 | Amazon Web Services ブログ 』も併せてご覧ください。

Athena - QA Athena - QA

Rahulおよび一柳は『 お客様からAthenaに対する期待やフィードバックを直接いただくことができ、今後の改善のアイデア得ることができました。このMeetupを開催できて本当に良かったです。お忙しい中ご参加くださった皆様ありがとうございました! 』と申しておりました。

Athena - Discuss kenta - rokuro

 

Amazon Athenaに関しまして、フィードバック等ございましたら、お近くのAWSジャパンの人間にお声がけいただければと思いますので、今後ともよろしくお願い致します。

また、日本語でAmazon Athenaの概要を知るには [PDF] AWS Black Belt Online Seminar Amazon Athena もおすすめですので、是非ご覧くださいませ。

AWS KMSを使用してAmazon Kinesisレコードを暗号化および復号する

コンプライアンスやデータセキュリティの要件が厳しいお客様は、AWSクラウド内での保存中や転送中など、常にデータを暗号化する必要があります。この記事では、保存中や転送中もレコードを暗号化しながら、Kinesisを使用してリアルタイムのストリーミングアプリケーションを構築する方法を示します。

Amazon Kinesisの概要

Amazon Kinesisプラットフォームを使用すると、要求に特化したストリーミングデータを分析または処理するカスタムアプリケーションを構築できます。 Amazon Kinesisは、ウェブサイトクリックストリーム、金融取引、ソーシャルメディアフィード、ITログ、トランザクショントラッキングイベントなど、何十万ものソースから1時間につき数テラバイトのデータを連続的にキャプチャして保存できます。
Amazon Kinesis Streamsは、HTTPSを使用してクライアント間でデータを暗号化し、転送されているレコードの盗聴を防止します。ただし、HTTPSで暗号化されたレコードは、データがサービスに入ると解読されます。このデータは24時間保管され(最大168時間まで延長可能)、アプリケーションの処理、再処理、処理遅延の際の巻き取りに対して十分なゆとりが確保されています。

ウォークスルー

Amazon Kinesis Producer Library(KPL)、Kinesis Consumer Library(KCL)、AWS KMSaws-encryption-sdkを使用してサンプルKinesisプロデューサおよびコンシューマアプリケーションへの暗号化と復号を行います。この記事で使用されているKinesisレコードの暗号化と復号に使用される方法とテクニックは、あなたのアーキテクチャに簡単に再現できます。いくつか制約があります:

  • AWSは、暗号化と復号のためのKMS APIリクエストの使用料金を請求します。詳しくは、「AWS KMSの料金」を参照してください。
  • Amazon Kinesis Analyticsを使用して、このサンプルアプリケーションのクライアントによって暗号化されたレコードのAmazon Kinesis Streamにクエリすることはできません。
  • アプリケーションでレイテンシの低い処理が必要な場合は、レイテンシに多少の上乗せがあることに注意してください。

次の図は、ソリューションのアーキテクチャを示しています。

(more…)

Amazon ElastiCache for Redis の リードレプリカの自動フェイルオーバのテスト

“信頼するが、確認する”

– ロナルド・レーガン米国大統領、1987

このコメントで、レーガン大統領は、核軍縮条約の哲学について、ロシアの諺を引用しました。DevOpsにも同じ考え方が当てはまります!

 

Amazon ElastiCache for Redisは、自動化されたフェイルオーバとリカバリを備え、高可用性を提供しています。ElastiCacheクラスタを作成したければ、 Redis Cluster モードを使用し、クラスタ内のシャード数を設定します。各シャードには、1つのプライマリノード(読み取りと書き込み用)と0〜5つのレプリカノード(読み取りとフェールオーバー保護用)があります。1つのクラスタは、レプリカがゼロ(1ノード)のシャードと同じくらい小さくても、5つのシャード(5つのレプリカ(合計90ノード))を持つことができます。

 

AWSでは障害が頻繁に発生することはありませんが、いずれのマシンでも障害は発生します。レプリカノードに障害が発生すると、障害が検出され、数分でノードが置き換えられます。

 

Redis Cluster では、プライマリノードに問題が起きた時に、Redis Cluster は障害を検知しレプリカノードを新しいシャードのプライマリとして昇格させます。このプロセスは大体30秒程で実施されます。問題の起きたノードは入れ替えられ、クラスタのレプリカノードとして復帰します。Redis ClusterとElstiCacheを、エンジンとして Redis 3.2.4 と Cluster モードを有効にすることによって使うことができます。

 

これを信じてください…しかし検証するべきです。

 

ElastiCacheのテストフェイルオーバのおかげで検証は簡単です。マネジメントコンソールかAWS CLIを使用し、ElasiCache クラスタのいずれかのノード障害をシミュレートする事ができます、そして、どのようなプロセスで貴方のアプリケーションが動くのかも見ることができます。マルチシャード、もしくはシングルシャードの環境でもテストは可能です。さらに古いRedis 2.8の環境でもテストは可能です。
コンソールまたはAWS CLIを使用して、ElastiCacheクラスタ内の任意のノードの障害をシミュレートし、自分のアプリケーションでフェールオーバープロセスがどのように機能するかを確認できます。マルチシャード環境とシングルシャード環境、さらに古いRedis 2.8ブランチ環境でもフェールオーバーをテストできます。コンソールでこれを行うには、クラスタとシャードを選択してノードビューを表示し、次にフェールオーバープライマリを選択します。マネジメントコンソールでテストを行う際には、クラスタとシャードを選択してNode Viewを確認し、次にFailover primaryを選択します。

 

使用には注意してください。どのようなクラスタでも同じように動きます。なぜならどのクラスタも開発環境、テスト、本番かをAWSが知るすべが無いためです。その本番のクラスタで実行しても良い事が確信していない限りは本番ノードでは障害を発生させないでください。

 

自動フェイルオーバのテストを試してみてください!

 

翻訳は桑野が担当しました。原文はこちら

Amazon Aurora: Fast DDLの詳細

Anurag GuptaはAmazon Auroraを含む彼がデザインに参加した、いくつかのAWSデータベースサービスに携わっています。 Under the Hoodシリーズでは、Auroraを支える技術や設計について説明します。

Amazon Auroraはオープンソースデータベースのシンプルさとコスト効率とハイエンドなコマーシャルデータベースの可用性と性能を兼ね備えたMySQL互換のデータベースです。この投稿では、Amazon Auroraが一般的な、完了までMySQLでは数時間かかるようなDDL文をほぼ即座に実行出来る仕組みを見ていこうと思います。

 

Fast DDLとは?なぜ考慮するのか

アプリケーションを変更すると、それに付随するデータベースのスキーマを変更する必要があるケースがあります。クエリのワークロードが変わると、インデックスの追加や削除を行う必要があります。データのフォーマットが変更になると、既存のカラムのデータタイプを変更する必要があります。そして、このような変更は頻繁に起こりえます。Ruby on Railsアプリケーションをサポートする一部のDBAは、週に数十回スキーマを変更すると話しています。

多くのMySQLのDBAはご存知のように、このようなスキーマの変更はプロダクションシステムの中断が発生する可能性があります。変更に時間がかかるからです。場合によっては、完了まで数時間から数日かかることもあります。システムのリソースも奪われるため、アプリケーションのスループットも低下します。また、長時間のオペレーションは長時間のクラッシュリカバリが発生する可能性があります。DDL操作の一部は書き込みロックが必要なため、アプリケーションの一部が使用できなくなります。加えて一時的なスペースを多く必要とする可能性があり、小規模のインスタンスではディスクが不足する可能性もあります。

私たちはこのような点を取り除けるように改善を行っており、良く見る一般的なDDL操作(nullableカラムをテーブルの最後に追加)から改善を始めました。

 

なぜ既存の方法では問題が起こるのか?

MySQLがどの様にnullableカラムをテーブルの最後に追加する実装になっているか見ていきましょう。

MySQLは以下のような処理を行っています:

  1. データベースはトランザクションのprepareフェーズでオリジナルテーブルに対して排他ロックを取得します
  2. 変更後のスキーマで新しい空のテーブルを作成します
  3. 1行ずつコピーを行ない、インデックスをその後作成する。同時に実行されたデータ操作(DML)文は、一時ファイルに記録されます
  4. 再度、排他ロックを取得し一時ファイルから新しく作成したテーブルへDML文を適用します。適用すべき操作が多くある場合、この処理に時間を要します
  5. オリジナルテーブルをdropし、テーブルをリネームします

これらの処理には多くのロックが必要になり、データのコピーやインデックスの作成にオーバヘッドが必要になります。そして、I/Oが多く発生し、一時領域も消費します。

 

もっと良い方法はないのでしょうか?

これについてはないと思うかもしれません。各行のデータ形式は変更する必要があります。しかし、この変更をテーブル上で実行されている他のDML(および関連するI/O)操作の上にのせることで、多くのことが実行できます。

完全なアプローチは、ブログポストではやや複雑すぎるので、ここでは簡単に説明します。

Auroraでは、DDLをユーザが実行すると

  1. データベースがINFORMATION_SCHEMAのシステムテーブルを新しいスキーマで更新します。加えて、各操作に対してタイムスタンプを付与し変更をリードレプリカに伝搬します。古いスキーマ情報は新しいシステムテーブル(Schema Version Table)内に格納されます

同期的に行う操作はこれだけで完了です。

そして、その後のDML文は、影響のうけるデータページがスキーマの変更を待っている状態か監視します。この操作は、各ページのlog sequence number (LSN)タイムスタンプとスキーマ変更のLSNタイムスタンプを比べるだけで簡単に行なえます。必要に応じて、DML文を適用する前に新しいスキーマにページを更新します。この操作は、redo-undoレコードページの更新と同じ更新プロセスで実行されます。そして、I/Oはユーザの実行するクエリと同様に扱います。

DML操作では、ページ分割が発生する可能性があるため、ページの変更に注意する必要があります。変更はAuroraのレプリカノードでも同様に扱う必要があります。そして、リードレプリカではどのデータへの変更も許可されていません。SELECT文のために、MySQLに戻されるメモリ上のバッファ内のイメージ変更します。この方法では、ストレージ内で新旧のスキーマが混在していたとしても常に最新のスキーマを参照出来ます。

もし、皆さんがAuroraがどのようにストレージからの読み込みとログの適用を行っているかご存知の場合、このアプローチが似ていると感じると思います。しかし、このアプローチではredo logのセグメントではなく、変更を記録するためにテーブルを使用します。

パフォーマンス比較は以下のようになっています。Auroraは Schema Version Tableを変更するために一定の時間で処理が完了しているのがおわかりになると思います。しかし、MySQLではテーブルサイズにほぼ比例して線形に処理時間が増加しています。

TableComparison

明らかに私達が改善すべき多くのDDL文があります。しかし、殆どの物は同様のアプローチで対処可能と考えています。

このことは重要です。たとえデータベースが通常の可用性で稼働していても、これらの長い操作ではアプリケーションへ影響が発生します。それらを並列、バックグラウンド、非同期処理に移すことで違いが出てきます。

質問やフィードバックはありますか?aurora-pm@amazon.comへ是非お寄せ下さい。皆さんの考えや提案を私たちは非常に大切にしています。

注: こちらの機能は2017年4月6日現在Lab modeにてご提供しております。

翻訳は星野が担当しました。原文はこちら

AWS Server Migration Service – クラウドへのサーバー移行が簡単に!

これはAhmed Omranのゲストポストです。 AhmedはAWSのMigration Solutions Architectです。

大規模構成におけるオンプレミスサーバーの移行は、自動化、スケジューリング、少ない帯域幅の消費や移行時間の短縮を調整することなしに行うことはできません。

この記事では、AWS Server Migration Service(AWS SMS)を使用して、オンプレミスのワークロードをAWSに効率的に移行する方法を段階的に説明します。

AWS Server Migration Serviceとは何ですか?

2016年10月、エンドツーエンドのサーバー移行プロセスを簡素化する目的でAWS SMS を紹介しました。 AWS SMS は現在、仮想アプライアンスを使用したエージェントレスサービスとしてのオンプレミス仮想マシン(VMs)の移行をサポートしています。 AWS SMSには、次の主要な利点があります:

  • ライブサーバーボリュームのAWSへのレプリケーションを順次自動化することにより、カットオーバー時のサーバーダウンタイムを削減します。
  • 費用対効果の高い方法で大規模サーバーの移行を行います。
  • 広く使用されている多くのオペレーティングシステムをサポートします。
  • 使いやすいUIを使用して、サーバー移行の進捗状況を管理および追跡します。

AWS SMSは、VMware 環境からAWSへの大規模マイグレーションを計画している場合に重要な考慮事項となる、ダウンタイム、エージェントレスツール、順次レプリケーション、およびカットオーバー前のアプリケーションテストなどに対する理想的なソリューションです。

AWS SMSは、サーバーの移行に使用する無料のサービスです。 Amazon EBS スナップショットAmazon S3など、移行プロセス中に使用されたストレージリソースにのみ支払います。

現在、米国東部(米国バージニア州)、米国西部(オレゴン州)、米国東部(オハイオ州)、EU(アイルランド)、アジア太平洋(シドニー)、アジア太平洋(東京)、アジア太平洋(ソウル) 、アジア太平洋地域(ムンバイ)でサービスが利用可能です。

どのように機能するのですか?

AWS SMS を使用してワークロードを移行する手順を説明する前に、移行プロセス自体とAWS SMS がどのように処理するかについて詳しく説明します。

移行プロセスは、次の図に示すように、4つの段階に分かれています。

AWS SMS 移行プロセスの概要

AWS SMS の最終出力はAmazon Machine Image(AMI)です。移行プロセスは、ジョブが終了されるまで(あなたが消去するか、または90日後に自動的に終了するまで)、各レプリケーションの実行ごとにAMIを生成します。

移行段階は、調整された複製頻度で反復されます。各レプリケーションの実行間隔の最短時間は12時間で、最大時間は24時間です。この反復サイクルの有効期間は90日です。その後、レプリケーションジョブは終了します。

移行するVMのグループを選択できます。 SMS は、アカウントごとに最大50の同時VM移行をサポートします。

AWS SMS はどのように使用しますか?

AWS SMSには、移行プロセスのワークフローを調整するコネクターが必要です。このコネクターは、vCenter にデプロイされます。

SMS コネクタを展開する前に、環境がAWSのSMS要件を満たし、正しいファイアウォール設定をしていることを確認してください。 DHCP、DNS、HTTPS、ICMP、およびNTPサービスのステートフルな送信接続を許可するようにファイアウォールを再設定できないと、展開に失敗する可能性があります。

また、AWS SMS のドキュメントに記載されているように、AWS SMS 用の適切なポリシーと権限を持つvCenterサービスアカウントとIAMユーザーを作成する必要があります。

Server Migration Connector仮想アプライアンスを展開する

Server Migration Connectorは、VMware 環境へデプロイするためにOVA形式で提供されている、事前設定されたFreeBSD仮想マシンです。 AWS からConnector の最新バージョンをダウンロードできます。

Server Migration Connector をダウンロードしたら、デプロイのための十分な権限を持つvCenterにログインします。

インベントリからvCenterのコンテキスト(右クリック)メニューを開き、OVF テンプレートの展開を選択します。

 

ソースの選択ページで、ソースOVFテンプレートが存在する場所を指定し、次へを選択します。

確認の詳細 ページで、OVF テンプレートに関する情報を確認し、 次へを選択します。

アプライアンスは、シンプロビジョニングの場合は5.9 GB、シックプロビジョニングの場合は299.0 GBのサイズ容量でデプロイされます。実稼働環境では、シックプロビジョニングを推奨します。

名前とフォルダの選択ページで、アプライアンス名と配置場所を指定します。

リソースの選択ページで、OVF テンプレートを展開したいクラスタ、ホスト、vAPP、またはリソースプールを選択します。

ストレージの選択ページで、仮想ディスク形式からThick Provisioned Lazy Zeroedを選択し、OVF テンプレートをデプロイする必要があるデータストアを選択します。

セットアップネットワークページでネットワークマッピングを設定するために、 宛先 ドロップダウンメニューからネットワークを選択し、 次へ をクリックします。

準備完了ページで、すべての構成設定を確認し、展開後に電源をオンにして、完了を選択します。

コネクターを構成する前に、Server Migration ConnectorがvCenterとESXiホストのFQDNを解決できることを確認してください。

ネットワーク設定の再設定が必要な場合、コネクタアプライアンスコンソールにログインし、Advanced Network Configurationガイドに従います。

コネクターの構成

WebブラウザーでIPアドレスを指定し、Connector VM にアクセスし、セットアップ・ウィザードを開きます。

今すぐ開始を選択します。

 

使用許諾契約書を確認し、条件に同意する場合はチェックボックスを選択し、次へを選択します。

コネクターのパスワードを作成します。

ネットワーク情報 ページで、ネットワーク情報を確認し、 次へ を選択します。

ログを自動的にアップロードし、AWS Server Migration Serviceの自動アップグレードに参加するかどうかを確認して決定します。

AWS Regionについては、リストから希望のリージョンを選択します。

AWS 資格情報には、前提条件のステップで作成したIAMユーザーのIAMアクセスキー秘密鍵キー入力します。

vCenter Service Accountには、vCenter のホスト名、ユーザー名、およびパスワードを入力します。

vCenter 証明書を受け入れたら、登録を完了し、コネクター構成ダッシュボードを表示します。

コネクター ページで、登録したコネクターが表示されていることを確認します。

コネクターページは4つのセクションに分かれています:

  • AWS Server Migration Service セクションには、AWSアクセスキー、シークレットアクセスキー、およびvCenterログインなど、編集可能な設定が用意されています。
  • General Healthセクションには、ヘルスチェックと接続ステータスが表示されます。
  • アクション セクションでは、SMS 管理者パスワードを変更し、コネクターの登録を解除できます。常に最新のアップデートを適用する場合は、自動アップグレードアクションを有効にします。
  • サポートセクションでは、ログをダウンロードしたり、問題を報告したり、ドキュメントを確認したりすることができます。

これで、サーバーインベントリをインポートして、移行イベントを編成して自動化する準備が整いました。

サーバーカタログをインポートする

コネクターがインストールされ、正しく登録されたら、AWS SMS コンソールにアクセスし、コネクター、サーバーカタログのインポートを選択して、サーバーの完全なリストを収集します。サーバーカタログが完全に取り込まれ、表に表示されるまでには時間がかかることがあります。

注:サーバーカタログはいつでも再インポートまたはクリアできます。

移行ジョブを作成する

移行ジョブを開始する前に、データストアに一時スナップショットのための十分な領域があることを確認し、選択したVMにISOが接続されていないことを確認します。

AWS SMS コンソールで、 レプリケーションジョブレプリケーションジョブの作成を選択し、ウィザードに従います。

テーブルから複製するサーバーを選択し、次へを選択します。

レプリケーションジョブから作成されるAMIのライセンスタイプを選択します。 LinuxサーバーはBring Your Own License(BYOL)のみを使用でき、WindowsサーバーはAWS提供のライセンスまたはBYOLを使用できます。完了したら、次へを選択します。

レプリケーションジョブ設定を構成し、次へをクリックします。レプリケーションの実行をすぐに開始させることも、後の日時から、現在の時刻から最大30日後に開始するようにスケジュールすることもできます。

Replicate server every ドロップダウンリストから目的のオプションを選択して複製頻度を選択できます。複製の最小頻度は12時間で、最大は24時間です。つまり、選択したサーバーのポイントインタイムレプリカを最小でも12時間ごとに作成できます。

設定を確認します。設定が正しい場合は、作成を選択します。表示されていない場合は、前へを選択して適切なページに戻り、設定を変更します。

AWS SMSコンソールの レプリケーションジョブ ページで、すべてのレプリケーションジョブを表示できます。 1つのレプリケーションジョブを選択すると、 ジョブの詳細パネルにレプリケーションジョブの詳細が表示されます。

前のスクリーンショットからわかるように、移行が開始され、VMDK がAmazon S3にアップロードされる第2段階にあります。

vCenter 画面から移行タスクのステータスを確認すると、開始されたスナップショットとOVFテンプレートが転送用にエクスポートされたことがわかります。

転送後、移行プロセスは第3段階になり、VMDK をAmazon Elastic Block Store(Amazon EBS)のスナップショットに変換します。

変換が完了すると、移行プロセスは最終ステージになり、この複製実行のポイントインタイムコピーのAMIを作成します。

AWS SMS コンソールのレプリケーションジョブ、実行履歴タブから、各レプリケーション実行で使用可能なすべてのAMIを表示できます。

実際のカットオーバーの前にテストする

オンプレミスアプリケーションを廃止する前に、アプリケーションをテストする機会があります。レプリケーション頻度に応じて、多数のポイントインタイムレプリカをテストしてから、差分の最後のレプリケーションジョブをスケジュールできます。

インスタンスを起動するには、前の手順で示したように実行履歴を開き、レプリケーションジョブを選択して、テストしたいインスタンスの起動を選択します。ウィザードに従って、インスタンスの種類の選択、インスタンスの構成、ストレージの追加、インスタンスのタグ付け、およびセキュリティグループの構成を行います。

実際のカットオーバー

テストを完了して実際のカットオーバーを実行することを決定したら、すべてのIOPを休止し、増分レプリケーションジョブを開始してから、AMIを起動します。 AWS SMS は増分レプリケーションを使用するため、以前のレプリケーション実行からの変更に応じて、カットオーバー時間は最小限になります。

レプリケーションジョブの削除

移行が正常に完了し、移行されたVMが正しく構成されて実行されたら、レプリケーションジョブを削除してオンプレミスデータセンターからAWSへのレプリケーションを停止できます。 AWS SMS コンソールの レプリケーションジョブページで、ジョブを選択し、アクションレプリケーションジョブの削除を選択します。

まとめ

この記事では、AWS Server Migration Serviceのメリットと機能について説明しました。また、SMS Connectorのインストールと構成の方法を説明し、稼働中のワークロードをオンプレミスデータセンターからAWSに移行するための移行プロセスの4つの段階について、ダウンタイムを最小限に抑える方法を説明しました。また、実際のカットオーバーの前に複数のポイントインタイムレプリカをテストする機能についても説明しました。

このブログ記事に関するコメントがある場合は、この記事のコメントセクションに投稿してください。あなたからの便りを楽しみにしています。

AWS Service Migration Serviceを開始する方法の詳細については、当社のWebサイトをご覧ください。

(翻訳は諸岡が担当しました。原文はこちら)

 

Amazon Redshift のデータ圧縮の強化で圧縮率が最大 4 倍に

今回は、Amazon Redshift シニアプロダクトマネージャーの Maor Kleider からのゲスト投稿です。

-Ana


Amazon Redshift は、ペタバイト規模の高速なフルマネージド型データウェアハウスサービスであり、すべてのデータをシンプルにコスト効率よく分析できます。多くのお客様 (ScholasticKing.comElectronic ArtsTripAdvisorYelp など) は、Amazon Redshift に移行して機敏性を実現し、洞察が得られるまでにかかる時間を短縮して、同時にコストも大幅に削減しています。

列指向の圧縮は、Amazon Redshift の重要なテクノロジーです。このテクノロジーにより、ノードの効果的なストレージ容量を増やしてコストを削減し、SQL リクエストの処理に必要な I/O を削減してパフォーマンスを向上させることができます。I/O の効率を高めることは、データウェアハウスに非常に重要です。昨年、I/O の向上に伴ってクエリスループットは倍増しました。この度、Amazon Redshift に新しい圧縮の強化機能が追加されました。以下に、いくつかをご紹介します。

まず、Zstandard 圧縮アルゴリズムのサポートが追加されました。このアルゴリズムは、ビルド 1.0.1172 での高い圧縮率とスピードを適切なバランスに維持します。標準の TPC-DS、3 TB ベンチマークで raw データに適用した場合、Zstandard はディスク容量の 65% を節減します。Zstandard は幅広く適用できます。SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、および TIMESTAMPTZ のいずれのデータ型にも使用できます。

2 番目として、CREATE TABLE AS、CREATE TABLE、ALTER TABLE ADD COLUMN の各コマンドで作成されたテーブルに対する圧縮の自動化が強化されました。Amazon Redshift のビルド 1.0.1161 以降では、これらのコマンドで作成された列のデフォルト圧縮が自動的に選択されます。パフォーマンスを低下させずにディスク容量を節減できるような場合は、自動圧縮が行われます。ディスク容量は、最大 40% 削減されます。

3 番目に、引き続き内部オンディスクデータ構造が最適化されています。プレビュー版をご利用のお客様は、この機能改善により、ディスク容量の使用量を平均して 7% 削減しました。この機能はビルド 1.0.1271 から提供されています。

最後に、ディスク容量の削減量を推定するための ANALYZE COMPRESSION コマンドが強化されました。これまで以上にデータを圧縮してパフォーマンスを向上させる機会が増えました。データは、バックグラウンドでサンプリングされて、最も効果的な圧縮が推奨されます。お客様の判断で、推奨された暗号化を使用するか、別の適切な暗号化を指定できます。

「最近追加されたすべての圧縮機能を利用するまでは、当社の最大のテーブルは 7 TB を超えていました。それが今は 4.85 TB までになり、ディスク容量は 30.7% も節減されました。これにより、ディスク容量は合計で 4 分の 1 に削減でき、非圧縮データに基づく有効原価は 250 USD/TB/年未満になります。Amazon Redshift で分析できるデータ量が増え、これまで以上にクエリのパフォーマンスが向上しました」Chuong Do (Coursera 社の Director of Analytics)

無論、実際にクラスターに適用した場合の効果は、ワークロードとデータに応じて異なります。以上の強化機能を組み合わせた場合、データの圧縮は、従来の通常の 3 分の 1 に対して、最大 4 分の 1 になると思われます。

Amazon Redshift データウェアハウスのコストはわずか 1,000 USD/テラバイト/年であるとお聞きになったことがあるかもしれません。これは圧縮後のデータに基づくコストである点にご注意ください。AWS では、データは圧縮されて保存されます。AWS 以外のベンダーではそうでない場合があります。多くのベンダーはデータを圧縮しますが、コストは非圧縮データのテラバイトに基づいています。嘆かわしいことです。データを圧縮しても非圧縮データとして課金するのは法外と言わざるを得ません。

-Maor Kleider

新規 – AWS Application Load Balancer に対するホストベースのルーティングのサポート

昨年、新しい AWS Application Load Balancer (Elastic Load Balancing の重要な一部) をご紹介し、リクエストの URL のパス要素に基づいて受信 HTTP および HTTPS トラフィックをルーティングするための設定方法について説明しました。このパスベースのルーティングにより、たとえば /api へのリクエストをサーバーのセット (ターゲットグループとも呼ばれます) にルーティングし、/mobile へのリクエストを別のセットにルーティングすることができます。このようにトラフィックをセグメント化することで、リクエストのカテゴリ別に処理環境を制御できます。たとえば、最適な処理環境として、/api リクエストにはコンピューティング最適化インスタンスを指定し、/mobile リクエストにはメモリ最適化インスタンスを指定できます。

ホストベースのルーティングと追加のルール
この度、別のルーティングオプションが利用可能になりました。Host ヘッダーに指定したドメイン名に基づいて受信トラフィックをルーティングする Application Load Balancer ルールを作成できるようになりました。api.example.com へのリクエストは 1 つのターゲットグループに送信し、mobile.example.com へのリクエストは別のターゲットグループに送信して、他のすべてのリクエストは (デフォルトルールで) 3 番目のターゲットグループに送信することができます。ホストベースのルーティングとパスベースのルーティングを組み合わせたルールを作成することもできます。これにより、api.example.com/production へのリクエストと api.example.com/sandbox へのリクエストを別々のターゲットグループにルーティングできます。これまでは、一部のお客様はプロキシサーバー群を設定して実行し、ホストベースのルーティングに使用していました。今回のリリースにより、ルーティングは Application Load Balancer によって行われるため、プロキシサーバー群は必要なくなりました。この処理レイヤーの省略により、アーキテクチャが簡素化され、運用のオーバーヘッドが削減されます。Application Load Balancer は、ポートマッピング、ヘルスチェック、サービス検出などのコンテナベースのアプリケーションをサポートする複数の機能を既に提供しています。ホストとパスの両方でルーティングできるようになると、複数のマイクロサービスをそれぞれ異なる Amazon EC2 Container Service コンテナで実行するアプリケーションを構築し、効率的にスケールすることができます。ホストベースのルーティングを使用すると、サービス名とコンテナ名を合致させることで、これまで以上にサービス検出機構を簡素化できます。今回のリリースでは、Application Load Balancer あたりの最大ルール数が 10 から 75 に増え、新しいルールエディタも導入されます。例として、以下のターゲットグループを使用してみましょう。

ロードバランシングコンソールに、Application Load Balancer に関連付けられているリスナーが表示されます。ここで、[View/edit rules] をクリックして新しいルールエディタにアクセスします。

すべてのリクエストを web-target-production ターゲットに転送するデフォルトルールが既に設定されています。

挿入アイコン ([+] 記号) をクリックして、場所を選択します。ルールは、表示されている順に処理されます。

[Insert Rule] をクリックして新しいルールを定義します。ルールは、ホスト、パス、または両方を参照できます。ホストのみを使うことにします。

ホストベースのルーティング用に 2 つのルールを追加します。エディタは次のようになります。

プロダクションおよびサンドボックスのトラフィックを別々のターゲットにルーティングする場合は、パスを参照する新しいルールを作成できます。最初のルールは次のとおりです。

数回クリックして少し入力するだけで、強力なルール群を作成できます。

Host ヘッダーと一致するルールには、最大 3 つの “*” (0 個以上の文字と一致) または “?” (1 文字と一致) ワイルドカードを含めることができます。大規模なお客様のそれぞれに、追跡目的で、独自のホスト名を付けることにします。ホスト名の最後の部分にかかわらず、すべてのリクエストを同じターゲットグループにルーティングするルールを記述できます。シンプルな例は次のとおりです。

ルールエディタの鉛筆アイコンを使用すると、ルールの順番を変更できます。ルールを選択して、別の場所に移動し、新しい順番を保存します。

既存のルールの編集や、不要なルールの削除を行うこともできます。

今すぐ利用可能
この機能は、本日からすべてのパブリック AWS リージョン (15 か所) で利用できます。各ロードバランサーで評価される最初の 10 個のルール (ホストベース、パスベース、または両方) は無料です。その後は、ルールの評価数に基づいて課金されます (これは前回の投稿で説明したロードバランサーのキャパシティーユニット (LCU) に新しく追加されたディメンションです)。各 LCU は最大 1000 ルールの評価をサポートします。LCU の 4 つすべてのディメンションが測定されますが、課金されるのは特定の時間内で最も使用量が多いディメンションのみです。設定されていても処理されないルールは課金対象外です。

Jeff;