Amazon Web Services ブログ

今月の初めに、同僚の Bala Thekkedath がエクストリームスケール HPC についての記事を公開し、AWS のお客様である Western Digital が AWS でクラウド規模の HPC クラスターを構築し、それを使用して次世代ハードディスクドライブ (HDD) のための将来のヘッドにおける極めて重要な要素をシミュレートした方法について語りました。 この記事で説明されているシミュレーションには 250 万強のタスクが含まれており、その実施は vCPU 100 万個の Amazon EC2 クラスター上でわずか 8 時間で完了しました。Bala がその記事で述べたように、Western Digital でのシミュレーション作業のほとんどが、HDD を包含するテクノロジーとソリューションの異なる組み合わせを評価する必要性を中心に展開されています。エンジニアはその過程において、ますます多くのデータを同じ領域に詰め込むこと、ストレージ容量を改善すること、そして転送速度を向上させることに焦点を当てます。材料、エネルギーレベル、および回転速度の何百万もの組み合わせのシミュレートすることは、Western Digital が最も高い密度と最も速い読み取り/書き込み時間を追求することを可能にし、結果をより迅速に得ることは、より良い判断を行うことを可能にすると共に、新しい製品を以前より速く市場に出すことができるようにします。 以下は、Western Digital のエネルギーによる記録処理が行われる様子を可視化したものです。上の横棒は磁気、中央の横棒は付加されたエネルギー (熱)、そして下の横棒は磁気と熱の組み合わせによって媒体に書き込まれた実際のデータを表しています。 先日、私は記録を塗り替えるこのシミュレーションを実現するために共に取り組んだ私の同僚、Western Digital のチーム、そして Univa に話を聞きました。私の目的は、このシミュレーションのための準備方法についての詳細を解明し、彼らが学んだ事柄を理解して、独自の大規模ジョブを実行する準備が整っている皆さんとそれらを分かち合うことでした。 規模の拡大 約 2 年前、Western Digital チームは、可能な限りコスト効率を良くするために、EC2 スポットインスタンスによって作動する、vCPU 8 万個もの大きさのクラスターを実行していました。クラスターは、8,000 個、1 万 6,000 個、および […]

AWS ではこの 2019 年、DynamoDB での作業時にミッションクリティカルなワークロードのパフォーマンスを最大化して、コストを最適化するために役立つ Amazon DynamoDB のベストプラクティスに従うことをお勧めします。この記事は、このような抱負の維持を助ける DynamoDB のコンテンツに焦点を当てて行きます。

このブログ記事では、リソースをひとつ、または複数のタグに基づいてグループ化し、スケーリングプランを使用することによって AWS Auto Scaling ポリシーを集約、設定、および管理する方法をご紹介します。スケーリングプランを使用すると、タグを用いることによって AWS Auto Scaling ポリシーの作成を自動化し、これらのポリシーを簡単に変更できます。

AWS Systems Manager Automation は AWS リソースを集中管理するためにマルチアカウントおよびマルチリージョンを対象としたアクションを実行することができます。この機能を活用することでアカウント全体への設定の適用、運用アクション、コンプライアンス管理、に必要な時間とオーバーヘッドを減らすことができます。 このブログ記事では、AWS Systems Manager Automation を使用して、マルチアカウントおよびマルチリージョン環境のマネージドインスタンスにパッチを適用する方法を紹介します。またパッチ適用のために、インスタンス管理にどのようにリソースグループを活用するか説明します。例えば、開発、テスト、および本番などのさまざまな環境用のリソースグループを作成できます。そして Patch Manager を活用したカスタム自動化ドキュメントの作成方法と、カスタム自動化ドキュメントを実行してマネージドインスタンスにパッチを適用する方法を説明します。

先日 (2018/12/25) 開催しました AWS Black Belt Online Seminar「Amazon DynamoDB Advanced Design Pattern」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 「時系列データが必要なアプリケーション」のスライドで GSIKey Rand(0-N) というのがありましたが、これはどのような目的がありますか？ A. こちらにあるような形で、書き込み後の検索効率向上の為のテクニックになります。 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております！ AWS Black Belt Online Seminar 1月分申込先 ≫ Redshift Recently Features Update 2019 年 1 月 22 日 | […]

AWS コミュニティヒーローである Teri Radichel による寄稿。Teri Radichel は、彼女の会社である 2nd Sight Lab を通じてサイバーセキュリティ評価、ペネトレーションテスト、調査サービスを提供しています。また、彼女は AWS Architects Seattle Meetup の創設者でもあります。 クラウドセキュリティのトレーニングを行うために旅行している間、私はホテルの部屋でも、教室でも VPN を使用して Wi-Fi ネットワークに接続します。ほとんどの企業は、リモート VPN エンドポイントをインターネット全体に公開しています。そこで、必要な場所にだけネットワークアクセスを許可するために AWS IoT ボタンを使用できるという仮説を思いつきました。VPN ユーザーがクリックするとアクセスできるようになり、ネットワークルールが起動され、ダブルクリックすると再びネットワークトラフィックが許可されなくなるとしたらどうでしょうか。 このアイディアを試したところ、以下の結果が分かります。 なぜ、VPN をリモートクラウド管理に使用するのか、疑問に思われるかもしれません。なぜ、ノートパソコンやモバイルアプリケーションではなくて AWS IoT ボタンなのでしょうか? それについての詳細は、私のクラウドセキュリティに関するブログをご覧ください。 最初は、デバイスで使用される証明書を組織が管理できるので、AWS IoT エンタープライズボタンを使用したいと考えていました。また Wi-Fi も使用し、ネットワークアクセスを許可するためにボタンの IP アドレスを取得することを望んでいました。そのためには、ラップトップと同じ IP アドレスをボタンが Wi-Fi ネットワークから受け取ったことを証明できなければなりませんでした。残念ながら、一部のワイヤレスネットワークで使用されるキャプティブポータルのために、一部の場所でボタンを接続するのに問題がありました。 次に、AT&T LTE-M ボタンを試しました。このボタンを今回のユースケースのために機能させることはできましたが、必要とされるほどユーザーフレンドリーではありませんでした。このボタンは、ホテルの部屋で VPN に接続するために使用している Wi-Fi ではなく、セルラーネットワークにあるため、IP アドレスを自動的に判断することができないのです。AWS IoT モバイルアプリケーションを使用して手動で設定しなければなりません。 […]

このプレイブックは、AWS Schema Conversion Tool の自動変換機能に焦点を当て、自動変換プロセスの制限事項に対する代替方法について説明します。SQL Server と Aurora MySQL の違い、非互換性、類似点を中心に説明し、幅広い種類のトピックを網羅しています。そうしたトピックとしては、T-SQL、構成、高可用性と災害対策 (HADR)、インデックス作成、管理、パフォーマンスチューニング、セキュリティ、物理ストレージなどが含まれます。

前回のブログ記事では、コンタクトセンターでの通話におけるセンチメント分析を実施できるように Amazon Transcribe と Amazon Comprehend をつなぎ合わせる方法を説明しました。今回は、そのプロセスを自動化し、大規模なソリューションをデプロイするために AWS CloudFormation を活用する方法をご紹介します。 ソリューションアーキテクチャ 以下の図は、Amazon Transcribe を使ってコンタクトセンターからの通話記録のテキストトランスクリプトを作成するアーキテクチャを示しています。この例では Amazon Connect (クラウドベースのコンタクトセンターサービス) を参照していますが、このアーキテクチャはどのコンタクトセンターに対しても機能します。 以下の図は、エンティティ分析、センチメント分析、およびキーフレーズ分析を実施するために、Amazon Comprehend を使用して文字に起こされたテキストを処理するアーキテクチャを示しています。最後に、Athena と QuickSight の組み合わせを使って分析を可視化することができます。 AWS CloudFormation を使用した自動化とデプロイメント ここでは、上記のソリューションを自動化してデプロイするために AWS CloudFormation を使用します。 まず AWS コンソールにログインし、このリンクをクリックして CloudFormation でテンプレートを起動します。 コンソールで、以下のパラメータを入力します。 RecordingsPrefix: 分割された記録が保存される S3 のプレフィックス TranscriptsPrefix: 文字に起こされたテキストが保存される S3 のプレフィックス TranscriptionJobCheckWaitTime: 文字起こしジョブチェック間の待ち時間 (秒単位) 他はすべてデフォルト値のままにしておきます。AWS の箇所にあるチェックボックスの両方にチェックを入れて、[変更セットの作成] をクリックしてから、[実行] を選択します。 このソリューションは以下のステップに沿って実行されます。 Amazon Connect […]

 Amazon Payments データエンジニアリングチームは、データの取り込み、変換、計算と保管を担当しています。チームはこれらのサービスを世界で 300 社以上のビジネス顧客が利用できるようにしています。これらの顧客には、製品マネージャー、マーケティングマネージャー、プログラムマネージャー、データサイエンティスト、ビジネスアナリスト、およびソフトウェア開発エンジニアが含まれます。彼らは、ビジネス上の決定を適切に下すために、データをスケジュールされたクエリとワンタイムクエリに使用しています。このデータは、リーダーシップチームがレビューする、週次、月次、および四半期ごとのビジネスレビューメトリクスの構築にも使用されています。 私たちは、以下を含むさまざまな消費者支払いビジネスチームをサポートしています。 Amazon 支払い商品 (クレジットカード、ポイント付きショップ、アマゾン通貨コンバーター、国際決済商品) ギフトカード 支払いの受け取り体験 Amazon ビジネスペイメント また、機械学習の推薦エンジンへのフィードも行っています。このエンジンは、Amazon の支払いチェックアウトページでお客様に最適な支払い手段を提案します。 古いデータウェアハウスの課題 このセクションでは、データウェアハウスと分析のニーズでこれまで直面していた課題について説明します。支払い商品の発売とその新市場への拡大により、データ量が急激に増加しました。その後、抽出、変換、ロードプロセス (ETL) のスケーリングは厳しい課題に直面し、その結果、遅延と運用上の負担が生じました。データウェアハウスで直面していた具体的な課題は、次のとおりです。 Upsert はスケーリングしていないので、1 回の実行あたり最大 10MN を超える更新が行えました。消費者製品カタログのデータセットには、米国市場で 6.5BN を超えるレコードがリストされており、1 日の更新が 10MN を超えることもありました。注文属性データセットについても同様の傾向が見られました。 6 か月分もの支払いデータを分析しなければならなかった場合、データの集計に時間がかかるか、または集計が完了しませんでした。多くの場合、ビジネスオーナーは特定の属性に基づいてデータを集約したいと考えていました。たとえば、成功した取引の数や特定の種類のカードごとの金額などです。 共有クラスター、つまり共有ストレージとコンピューティングは、リソースクランチを引き起こし、その全ユーザーに影響を与えました。各チームにはデータウェアハウスでそれぞれ最大 100TB が割り当てられました。各チームは自分のテーブルを持ち寄り、中央データウェアハウスのテーブルに結合することができます。クラスター上の不正なクエリは、同じクラスター上の他のすべてのクエリに影響を与えました。これらの不正なクエリの所有者を特定するのは困難でした。 本番テーブルは 30,000 以上あり、それらすべてを同じクラスターでホストすることはほとんど不可能になりました。 大きなテーブルでインデックスが破損すると、テーブルを再構築して埋め戻すのが大変です。 データベース管理者はパッチを適用し、更新する必要がありました。 Amazon Redshift を新しい支払いデータウェアハウスとして使用する 私たちは、高速で信頼性が高く、将来のデータの増加に見合う規模がある、分析のニーズに適したさまざまなオプションを検討し始めました。これまでに説明したすべての問題を考慮して、中央データウェアハウスはコンピューティング層とストレージ層を分離する方向に進み、彼らはストレージを担当することにしました。そして機密性の高い重要なデータでも格納できるように暗号化されている Amazon S3 にデータレイクを構築しました。各消費者チームは、分析ニーズに合った独自の計算能力を実現するためのガイドラインを得ました。支払いチームは以下の利点に目を付け出しました。 便利な分析。 S3 や他の AWS のサービスとの統合。 手ごろな価格のストレージと計算レート。 ETL 処理に使えること。 […]

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。