Amazon Web Services ブログ

2018 年 6 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。マーケティングの鬼形です。6 月の AWS Black Belt オンラインセミナーの配信についてご案内させて頂きます。 !!オンラインセミナーお申し込み方法: オンラインセミナー登録ページよりお申し込みください AWS 認定取得に向けて 2018 年 6 月 6 日 | 18:00 – 19:00 | IT 知識レベル:★☆☆☆☆ | AWS 知識レベル:★☆☆☆☆ AWS が提供しているAWS認定プログラムおよびその価値を説明します。また AWS 認定の取得に必要な最新の試験体系と、その受験方法および受験に必要な各種準備リソースの紹介をいたします。※本セミナーはテクニカルな内容は含みません。 対象者 AWS初心者/初学者の方 認定試験をはじめて受験する方 本セミナーで学習できること AWS認定プログラムの内容について AWS認定のための資格試験の体系について 資格試験の受験方法および事前学習に必要なリソースについて スピーカー 石上 浩 AWS Training and Certification   AWS で実現するライブ動画配信とリアルタイムチャットのアーキテクチャパターン 2018 年 6 月 12 日 | 12:00 – 13:00 | IT […]

Read More

Amazon Aurora Backtrack – 時間を巻き戻す

こんなご経験、皆さんにもありますよね。重要なプロダクションデータベースに素早く、見かけ上はシンプルな修正を加えなければならないという状況。まずクエリを作成して、ざっと目を通し、そして実行キーを押す。数秒後、WHERE 句を書き忘れたとか、ドロップしたのが誤ったテーブルだったとか、または、他にも深刻な間違いがあったことに気づき、クエリを中断するものの、すでに一部の変更は反映されてしまっている。あなたは深いため息をつき、歯の間から弱々しい音をもらし、Undo (元に戻す) 機能があればよかったのにとうつむくのです。さて、次はどうしますか? 最新の Amazon Aurora Backtrack 今日は Amazon Aurora の新しい「巻き戻し」機能についてご紹介します。 これは現在の技術レベルで可能な、現実世界を「元に戻す」のに最も近い方法です。 この機能は新しく開始される Aurora データベースクラスターで有効にすることができます。 これを有効にするには、巻き戻す必要がある可能性のある時間を指定するだけで、そのあとは通常通りにデータベースを使用します (以下は事前設定の設定ページ): Aurora は分散型ログ構造ストレージシステム (詳細については Design Considerations for High Throughput Cloud-Native Relational Databases を参照) を採用しています。データベースへ変更を加えるたびに新しいログレコードが作成され、ログシーケンス番号 (LSN) が生成されます。巻き戻し機能を有効にすることで、LSN のストレージ用クラスターに FIFO バッファーがプロビジョニングされます。これにより、素早いアクセスと秒単位で測定されたリカバリ時間が利用できるようになります。 すべてが失われたように思えたその絶望的な瞬間のあと、あなたはただアプリケーションを一時停止し、Aurora コンソールを開いてクラスターを選択して [Backtrack DB cluster] (DB クラスターを巻き戻す) をクリックするだけです。 それから Backtrack を指定し、取り返しのつかない過ちを犯してしまった寸前を選び、[Backtrack DB cluster] (DB クラスターを巻き戻す) をクリックします。 それから巻き戻しが終わるまで待ち、アプリケーションを再開して、何ごともなかったかのように作業に戻ります。巻き戻し機能を開始すると、Aurora はデータベースを一時停止し、すべての接続を遮断して、コミットされていない書き込みをドロップし、巻き戻し機能が完了するのを待ちます。その後、通常のオペレーションを再開して、リクエストを受け入れます。 巻き戻し機能の実行中、インスタンスの状態は […]

Read More

Amazon Kinesis Data Firehose、Amazon Athena、Amazon Redshift を使用して Apache Parquet 最適化データを分析する

Amazon Kinesis Data Firehoseは、 Amazon S3で構築されたデータを取得し、データレイクへデータを流し入れる最も簡単な方法です。このデータは、AWS CloudTrail ログファイル、Amazon VPC フローログ、Application Load BalancerなどのAWSのサービスによるものです。IoTイベント、ゲームイベントなどにもなります。このデータを効率的に参照するには、時間のかかるETL (抽出、転送、ロード)処理が必要です。最適なファイルフォーマットへデータを抽出、変換することで、インサイトへの時間が増えます。この状況は、特に時間とともに価値が失われるリアルタイムデータ向けには最適とはいえません。 この通常の問題を解決するために、Kinesis Data Firehoseでは、Apache Parquet または Apache ORC フォーマット内でAmazon S3へデータを保存できます。S3でデータを参照する場合、最適なパフォーマンスとコスト効率に優れた、推奨される最適なカラムナフォーマットがあります。これにより、Amazon Athena、Amazon Redshift、AWS Glue、Amazon EMR、またはAWS パートナーネットワークから、またオープンソースコミュニティから利用できるその他のビッグデータツールを使用する場合に、直接的なメリットがあります。 Amazon Connectは、使いやすい、クラウドベースの連絡センターサービスです。通常のサービスよりも低コストで優れた顧客体験を簡単に提供することができます。オープンプラットフォーム設計により、他のシステムと簡単に統合できます。その中のシステムの1つとして、Kinesis Data Streams および Kinesis Data Firehose内のAmazon Kinesisがあります。 Apache Parquetフォーマット内の Amazon ConnectからS3までイベントを保存できることは素晴らしいことです。リアルタイムに Amazon Athena および Amazon Redshift Spectrumを使用して、この主なパフォーマンスとコスト最適化を利用した分析を実行できます。もちろん、Amazon Connectはその1例です。これにより、特に、組織がデータレイクを継続的に構築する場合、最適な機会が開けるでしょう。 Amazon Connectには、管理者ダッシュボード内に一連の分析表示が含まれています。しかし、その他の種類の分析を実行したい場合もあるでしょう。この投稿では、Kinesis Data Streams、Kinesis Data Firehose、S3を経由してAmazon Connectからのデータストリームを設定し、Athena および […]

Read More

EC2 スポットインスタンスと TIBCO GridServer を使用して AWS 上で 130万個の vCPU グリッドを作成する

私の同僚の多くがお客様に会い、お客様の声に耳を傾けるといった機会を持てることは幸運です。これによりお客様のビジネスやテクノロジーのニーズをより満足させる方法を見つけるのに最善を尽せます。この情報は細心の注意を払って扱い、新しいサービスと新機能のロードマップに取り組むときに利用します。 金融サービス業界 (FSI) の AWS を利用するお客様は、2019年から2021年に実施される FRTB (Fundamental Review of Trading Book) の規制に備えています。とりわけ、それぞれの金融機関がニューヨークで取引が終了してから東京で開始するまでの4時間の時間枠内に「バリュー・アット・リスク」の計算を実行しなければならなという新しい方法取り組みが規定されます。現在、このミッションクリティカルな計算は、20万個の vCPU (仮想CPU) のリソースを消費していますが、本規制により 40万 〜 80万個の vCPU (仮想CPU) に増加する見込みです。この高いスループットの計算を実行するのに必要な規模や回数などについては、まだ議論が必要ですが、全体的な方向性は明確になっています。 FSIのお客様がこれらの新しい規制に対処できるようサポート体制が整ったことを確かなものにするため、TIBCOと協力して、 AWSクラウドでPoC (概念実証) を実施します。4時間以内に処理を完了するために必要な処理能力とストレージ量が伴う計算には、費用対効果の高く、オンデマンドで膨大な量の計算能力を利用できる環境が最も適しています。 当社のお客様は、すでにオンプレミスの TIBCO GridServer をクラウドで利用することを検討しています。本製品は、エンタープライズ規模でグリッドを実行するように設計されています。仮想化された方法でアプリケーションを実行し、リソースの要求を受諾し、必要に応じて動的にプロビジョニングします。クラウド版では、Amazon Linux だけでなく、PostgreSQL と互換性のある Amazon Aurora サポートしています。 TIBCOと協力して、現在のハイエンド予測である 80万個の vCPU よりも大幅に大きいグリッドを作成し、50% の安全係数を追加した 130万個の vCPU (オンプレミスの5倍の規模) まで拡張しました。この目標を念頭に置いて、アカウント制限を次のように引き上げました。 スポットインスタンス制限 – 120,000 EBS ボリューム制限 – 120,000 EBS 容量制限 – […]

Read More

AWS オンラインテックトーク – 2018 年 5 月および 6 月前半

AWS オンラインテックトーク – 2018 年 5 月および 6 月前半 AWS では今月も注目の新サービスやソリューションのベストプラクティスについてご紹介します。また、初の re:Invent 2018 ウェビナーシリーズ、「How to re:Invent」も企画しています。 お見逃しないよう早目にご登録ください。 注意 – すべてのセッションは無料で、太平洋時間です。 今月の主なテックトーク 分析 & ビッグデータ 2018 年 5 月 21 日 | 午前 11:00 ~ 11:45 (太平洋時間) – Integrating Amazon Elasticsearch with your DevOps Tooling – Amazon Elasticsearch Service をいかに簡単に DevOps へ統合し、ログデータから価値ある詳細情報を得ることができるかについて学びます。 2018 年 5 月 […]

Read More

Amazon SageMaker で量子系をシミュレートする

Amazon SageMaker は、開発者やデータサイエンティストがあらゆる規模の機械学習モデルを迅速かつ簡単に構築、訓練、およびデプロイすることを可能にする完全マネージド型サービスです。しかし、機械学習 (ML) のワークフローを能率化するだけでなく、Amazon SageMaker は科学技術向けコンピューティングタスクの大規模なスペクトルを実行したり、並列化したりするためのサーバーレスでパワフルな使いやすいコンピューティング環境も提供します。このノートブックでは、TensorFlow と Amazon SageMaker の「bring your own algorithm (BYOA)」 (独自のアルゴリズムを活用する) 機能を併用して、シンプルな量子系をシミュレートする方法についてご紹介します。 この演習を実行するにあたり、Amazon SageMaker にアクセスできる AWS アカウントと Python および TensorFlow に関する基礎知識が必要になります。 量子系の超放射: 簡単な説明 これから私たちがシミュレートする量子効果は超放射として知られています。 これは、ある一定の環境下で、独立した発光体 (個別の原子など) が自然に量子コヒーレンスを増加させ、1 つの実体として協調的に動作するという現象を示します。コヒーレンスが増大したことで、このグループが高輝度のバーストを単発で発します。このバーストは独立した粒子のグループから生じると予想される輝度の N 倍 (!) も強いものである、この場合の N とはグループの粒子の数を示します。興味深いことに、この影響は粒子との相互作用に基づくものではなく、むしろ、粒子の明視野との相互作用と対称的な性質によってのみ生じます。 以下の図では、発光プロファイルが独立型 (上のパネル) と超放射型 (下のパネル) の粒子集団で明確に異なっていることがわかります。超放射は空間的に方向を持った、短時間の高輝度パルスを生じさせます。これは従来の急激に崩壊する放出プロファイルとは異なります。 超放射は多くの様々な量子系で見られ、 提示されてきました。ここでは TensorFlow と Amazon SageMaker を使って、ダイヤモンド窒素-空孔中心の核スピン集団からの超放射をシミュレートする方法を見ていきましょう。 Amazon SageMaker における科学的コンピューティングの構造 Amazon […]

Read More

[AWS Black Belt Online Seminar] AWS Greengrass で実現するエッジコンピューティング 資料及び QA 公開

こんにちは、マーケティングの鬼形です。 先日 (2018/5/8) 開催しました AWS Black Belt Online Seminar「AWS Greengrassで実現するエッジコンピューティング」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

Read More

Redis 用 Amazon ElastiCache を使用してリアルタイムの販売分析ダッシュボードを構築する方法

Amazon ElastiCache について説明すると、ほとんどの場合、読み取り負荷の高いデータベースワークロードのパフォーマンスを向上させるという文脈になります。リードスルーまたはライトスルーのパターンを採用するようにアプリケーションを更新し、キャッシュ内のデータを最新に保ち、データベースの負担を軽減します。この文脈で使用すると、ElastiCache はデータをメモリにキャッシュして大量のワークロードを高速化し、ミリ秒未満のデータ取得パフォーマンスを実現します。さらに、Redis 用 Amazon ElastiCache は、マルチ AZ 設定の自動フェイルオーバーにより、ワークロードの可用性とフォールトトレランスを向上させます。 ただし、ElastiCache は、ワークロードをより効率的にするだけでなく、新しい機能を提供するなど他にも多くの利点をもたらすことができます。この記事では、Redis 用 ElastiCache で構築されたリアルタイムの販売分析ダッシュボードの文脈で、こうした機能のいくつかを検討します。 この例で使用されているダッシュボードのコードとサンプルアーキテクチャは、GitHubの aws-elasticache-retail-dashboard リポジトリから入手できます。 ダッシュボードの指標 このダッシュボードは、広範な製品カタログを持つ大量の電子商取引サイトについて、ほぼリアルタイムの指標を提供します。リレーショナルデータベースを使用してこうしたダッシュボードを構築するには、リソースを集中的に使用するクエリの複雑なセットが必要です。代わりに、少数の Redis コマンドを使用してこのデータを追跡します。 このダッシュボードは、5 つの主要な一般的販売指標に焦点を当てています。 毎日の注文数 まず、簡単な指標である、毎日の注文数から始めます。注文を受け取るたびに、注文数を 1 つ増やします。操作は高速でアトミックなので、リレーショナルデータベースのテーブルの行数を数える必要はありません。毎日、新しいキーを作成し、Redis は初期値 0 のキーを作成します。ダッシュボードは当日の注文数にのみ関係しています (履歴データは後で取り上げます)。 2018 年 3 月 11 日の注文数を増やすには、指定したキーに保存されている整数値をインクリメントする、Redis INCR 操作を使用します。キーが存在しない場合は、操作が実行される前に値が 0 に設定されます。 INCR orders:20180311 これで、次のように整数形式の値を取得できます。 GET orders:20180311 当日販売された一意の商品の数 毎日の注文数をカウントしたので、次はそれらの注文で販売されている商品に関するデータを収集しましょう。まず、毎日販売されている一意の商品の数 (SKU または一意の ID による) を追跡しましょう。注文数の指標と同様に、同じ結果を作成する SQL クエリ […]

Read More

AWS DMS は、R4 タイプのインスタンスをサポートするようになりました。適切なインスタンス AWS DMS 移行を選択できます

AWS Database Migration Service (AWS DMS) でAmazon EC2 の R4 メモリに最適化されたインスタンスのサポートをお知らせ致します。これらのインスタンスには、より多くのメモリとより高いネットワーク帯域幅があり、高いスループットとメモリ集約的な操作を必要とする移行をサポートするのに役立ちます。 ここには、DMS でサポートされているインスタンスの一覧が表示されます。 DMS が新しいインスタンスクラスをサポートするようになったので、どのインスタンスクラスを選択するのか迷うかもしれません。 状況に適したインスタンスクラスはどれですか? この質問に答える前に、各インスタンスクラスを DMS でどのように使用できるかを見てみましょう: T2インスタンス:軽負荷のために設計されており、時折パフォーマンスが急上昇します。このインスタンスクラスを使用して、DMS について学習し、小さな断続的なワークロードの移行をテストすることをお勧めします。 C4インスタンス:クラス最高のCPU性能を備えた計算集約型ワークロード向けに設計されています。DMSは、特に異機種間の移行やレプリケーション(たとえば、Oracle からPostgreSQL へ)を実行する場合、CPUを集中的に使用することがあります。C4インスタンスは、これらの状況に適しています。 R4インスタンス:メモリ集約型ワークロード用に設計されています。これらのインスタンスには、vCPUあたりのメモリが含まれます。DMS を使用するハイスループットトランザクションシステムの継続的な移行やレプリケーションは、時には大量のCPUとメモリを消費することがあります。R4インスタンスは、これらの状況に適しています。 これらの点を念頭に置いて、AWS DMS を使用して移行を実施する際に、C4 および R4 タイプのインスタンスが要件に適合できるかどうかを理解するための例をいくつか紹介します。 フルロードフェーズでの R4 の利点 以前のブログ記事で議論したように、PostgreSQL は、コンマ区切り値(CSV)ファイルを使用して値が引き渡されるターゲットエンジンです。この場合、DMS は移行を開始するときに次のことを行います: DMS は、ソーステーブルからレプリケーションインスタンスメモリにデータをアンロードして、データを含む CSV ファイルを準備します。この CSV ファイルのサイズは、パラメータ maxFileSize に依存します。 DMS は CSV ファイルをディスクに保存し、COPYコマンドを使用してデータを PostgreSQL にプッシュします。 このタイプの移行を実行する場合、maxFileSize 値を大きくするとスループットが大幅に向上します。私たちは、maxFileSize の最大が1,048,576KB(1.1 GB)まで向上し、移行速度が大幅に改善されていることを実際に確認しました。バージョン […]

Read More