Amazon Web Services ブログ

Category: Amazon Redshift

Zendesk がレガシーシステムを Amazon Aurora と Amazon Redshift に移動してパフォーマンスを 3 倍にした方法

 この記事は、Zendesk のエンジニアリングリーダーである James Byrne 氏によるゲスト投稿です。Zendesk は、Zendesk Explore アナリティクス製品のデータパイプラインにおける開発と運用、および AWS ソリューションアーキテクトの Giedrius Praspaliauskas に焦点を当てています。 Zendesk は、より良い顧客関係を促進するために設計されたサポート、販売、顧客エンゲージメントソフトウェアを構築する CRM 企業です。規模、業界、または野心に関係なく、大企業からスタートアップ企業にいたるまで、強力で革新的な顧客体験がすべての企業に届くと、私たちは信じています。Zendesk は、さまざまな業界の 150,000 社以上の顧客に 30 以上の言語でサービスを提供しています。Zendesk はサンフランシスコに本社を置き、世界中に 17 ヵ所のオフィスを展開しています。 Zendesk Explore は、企業が顧客体験全体を測定して改善できるように分析を提供します。Zendesk Explore を使用すれば、企業は重要な顧客分析にすぐにアクセスでき、顧客とその関連ビジネスについてより深く理解できます。 この記事では、レガシーシステムを Amazon Aurora と Amazon Redshift に移行する方法について説明します。新しいデータストアと 3 倍のパフォーマンスを構築できるプロセスとアーキテクチャについて詳しく説明します。 移行を決定する 2015 年、Zendesk はビジネスインテリジェンスのスタートアップ企業である BIME Analytics を買収しました。BIME 製品は、現在のレポート製品である Zendesk Explore の構成要素として機能していました。Zendesk Explore は、Zendesk サポート、トーク、チャット、ガイドなど、さまざまな Zendesk […]

Read More

[AWS Black Belt Online Seminar] Amazon Redshift 資料及び QA 公開

先日 (2020/03/18) 開催しました AWS Black Belt Online Seminar「Amazon Redshift」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200318 AWS Black Belt Online Seminar Amazon Redshift AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. どういった場合に行指向ストレージが向いているのでしょうか?(逆に言えば、Redshiftでの処理に向いていないクエリはあるのでしょうか) A. 多数のショートトランザクションが中心となるような場合に行指向ストレージが向いていると言えます。例えば、特定の行のみの情報を取得するような場合や、1行に対する更新処理や挿入処理が繰り返し行われることが多いシステムの場合、行指向ストレージが向いていることが考えられます。一般論になりますが、いわゆるOLTPの処理は行指向の方が向いていると言えます。一方で、比較的少量のトランザクションが中心で、クエリが多くの場合複雑で大規模な履歴データセットに対する集計を伴うような場合、Amazon Redshiftが向いていると言えます。AWSでは、目的別に応じて多様なデータベースをご用意しておりますので、利用シーンに合わせて選択いただければと思います。 Q. SQAにもスロットという概念あるのでしょうか? A. はい、SQAにもスロットという概念があります。SQA用のキューがデフォルトで存在し、該当のキューに対して、スロットが設定されています。Amazon Redshiftがクエリを実行する際には、必ず、デフォルトキュー、ユーザー定義のキュー、SQA用のキューいずれかが持つスロットが使用されることになります。ただし、SQA用のキューが確保しているメモリ容量やスロットの数については公開されておりません。 — 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。 皆様のご参加をお待ちしております。 — AWS Innovate Online Conference / AWS Startup Day Online 【全42セッション公開中】 AWS Innovate は、AWS クラウドを活用してビジネス革新を目指しているすべての IT […]

Read More

[AWS Black Belt Online Seminar] Next Generation Redshift 資料及び QA 公開

先日 (2020/02/18) 開催しました AWS Black Belt Online Seminar「Next Generation Redshift」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200218 AWS Black Belt Online Seminar Next Generation Redshift AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. Concurrency Scalingの1日あたり1時間分の無料クレジットは繰越されるのでしょうか? A. はい、繰り越されます。クレジットはクラスターごとに最大30時間まで累積します。詳細はAmazon Redshift の料金 の「同時実行スケーリングの料金」をご参照ください。 Q. 無料アカウント(期間)にRA3をお試しする事可能ですか? A. いいえ、無料トライアルの2ヶ月間でお試しいただけるのはDC2.largeインスタンスタイプのみとなります。詳細は Amazon Redshift 無料トライアル をご参照ください。 — 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。 — AWSome Day Online Conference 「AWSome Day Online」は、実際に足を運んでいただく 1 […]

Read More

Amazon Redshift の新機能 – データレイクエクスポートとフェデレーテッドクエリー

データウェアハウスは、トランザクション系システムや業務アプリケーションから届いたリレーショナルデータの分析に最適化されたデータベースです。Amazon Redshiftは高速でフルマネージドのデータウェアハウスであり、標準SQLや既存のビジネスインテリジェンス(BI)ツールを用いたデータ分析をシンプルかつ効率的に行うことを可能にします。 データウェアハウス内に格納されていないであろう非構造化データから情報を習得するためには、データレイクを構築するという手段があります。データレイクは、全ての構造化データと非構造化データをあらゆるスケールで格納可能な、一元化されたレポジトリです。Amazon Simple Storage Service (S3)上に構築されたデータレイクによって、ビッグデータ分析を行い、機械学習を用いて準構造化データセット(JSON、XMLなど)や非構造化データから知見を得ることが簡単に行えるようになります。

Read More

Amazon Redshift の新機能 – 次世代コンピュートインスタンスと、マネージドで分析に最適化したストレージ

私たちはAmazon Redshiftを2012年にローンチしました(Amazon Redshift – The New AWS Data Warehouse)。数万ものお客様を抱え、今では世界で最も人気のあるデータウェアハウスとなっています。私たちのお客様は、業界を牽引するコストパフォーマンスで享受できる高速なパフォーマンス、複雑なクエリのサポート、トランザクション機能などに満足しています。 オリジナルのRedshiftのモデルは、計算能力とストレージのキャパシティが強固に結びついた形で規定されています。特定数のインスタンスからなるクラスターを作成すると、同時にインスタンスが搭載するローカルストレージの総量が約束されます(ときには総量によって容量が限定されます)。Concurrency Scaling(同時実行スケーリング)によって追加の処理能力を得ることもできますし、数分でクラスターのスケールアウトやスケールダウンが可能なElastic Resize(伸縮自在なサイズ変更)を使うことができるため、変化する処理能力やストレージの要求に適応することが可能です。 私たちはもっとうまくやれると思っています!今日、私たちはRedshiftに、処理能力とストレージをそれぞれ別々に最適化することができる新しいストレージ管理モデルで支えられている、Nitroベースの次世代コンピュートインスタンスをローンチします。このローンチは、ネットワークの広帯域化、Amazon Simple Storage Service (S3)を背後に持つSSDベースのローカルストレージを利用するマネージドストレージ、そしてS3との間で行き来するデータの動きを最適化するための複合的で高度なデータ管理技術といった、アーキテクチャの改良を利用しています。

Read More

【開催報告】Amazon Analytics 事例祭り – データウェアハウスマイグレーション

こんにちは。アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクトの平間です。 9月24日に、「Amazon Analytics 事例祭り – データウェアハウスマイグレーション」を開催いたしました。今回は既存のデータウェアハウス(DWH)環境から、AWSの高速かつ完全マネージド型のDWHであるAmazon Redshiftへ移行されたお客様に、移行の決め手や移行後の効果について「本音」でお話ししていただきました。セミナーは前半がAWSソリューションアーキテクトからAWSのデータレイク及びアナリティクスサービスの概要と、DWHの移行をどのように検討すればよいかの方法をお話させていただき、後半はお客様より移行時の体験談をお話しいただいております。

Read More

【開催報告】第9回 AWS Data Lake ハンズオンセミナー

こんにちは。AWS ソリューションアーキテクトの上原誠(@pioh07)です。 9月27日に、「AWS Data Lake ハンズオンセミナー」を開催いたしました。去年から行ってきた恒例のワークショップで第9回目となります。去年から引き続き盛況で、今回も80名以上のお客様にご参加頂きました。 はじめに、AWSにおけるデータ活用のベストプラクティスである Amazon S3 を中心とした Data Lake について解説し、ビッグデータ分析基盤の考え方として有名なラムダアーキテクチャの解説を行いました。 当イベントでは、Amazon Athena や Amazon Redshift の各 AWS サービスを駆使して実際にラムダアーキテクチャを構築することがゴールです。とはいえ全てを構築するのはボリュームが大きいため、スピードレイヤー or バッチレイヤー or 全部入りでコース分けて取り組めるようハンズオンコンテンツを用意しました。最初にコースの説明を行い、出席いただいたお客様ご自身の課題に合わせてコースを選択頂き、ハンズオンを行っていただきました。今回、参加者も多くいらっしゃいましたので、サポートするソリューションアーキテクトも7名で対応させていただきました。 今回参加できなかった方も、ソリューションアーキテクトのサポートを受けながらハンズオンを行いログ分析を初めてみてはいかがでしょうか? 次回はハロウィンも待ち遠しい11月に開催予定です。ご参加お待ちしております。

Read More

[AWS Black Belt Online Seminar] Amazon Redshift Update 資料及び QA 公開

先日 (2018/1/22) 開催しました AWS Black Belt Online Seminar「Amazon Redshift Update」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190122 AWS Black Belt Online Seminar Amazon Redshift Update AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. Redshiftアドバイザ実行中、Redhiftのパフォーマンスに影響を及ぼさないでしょうか? A. Redshiftアドバイザのための各種ログ収集は内部的にスケジューリングされて自動実行され、パフォーマンスに影響を及ぼさないように動作します Q. クエリエディタについて質問です。ds2.xlargeでも、将来的に使えるようになるのでしょうか? A. 将来的なことはご回答できませんが、お客様のRequestに答えられるよう活動してまいります​ 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております! AWS Black Belt Online Seminar 1月分申込先 ≫ AWS Black Belt Online Seminar 2月分申込先 ≫ 2019 年 1 月 22 日 | 12:00 […]

Read More

750 TB のデータを使用して Amazon Redshift で Amazon Payments 分析を実行する

 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 処理に使えること。 […]

Read More

クライアントのデジタルマーケティング成果の向上を助けるために Amazon Redshift を使用する Bannerconnect

Bannerconnect は、望ましいタイミングと場所で適切な人に広告を見てもらうことによって、アドバタイザーが注意と顧客を惹きつけることができるようにするプログラム的なマーケティングソリューションを使用しています。データ主導の洞察は、大規模アドバタイザー、トレードデスク、およびエージェンシーがブランド認知を促進し、デジタルマーケティングの成果を最大化するために役立ちます。ログデータの適宜を得た分析は、顧客行動における動的変化に応答し、マーケティングキャンペーンを迅速に最適化して、競争優位性を得るために必要不可欠です。 AWS と Amazon Redshift への移行により、当社クライアントはほぼリアルタイムの分析を簡単に得ることができるようになりました。このブログ記事では、オンプレミスのレガシーデータウェアハウスで直面した課題について説明し、Amazon Redshift への移行によって得たメリットについてお話します。現在 Bannerconnect では、データをよりすばやく取り込み、より高度な分析を行って、クライアントがそのデジタルマーケティングを改善するためにより迅速なデータ主導の判断を行えるよう援助することができます。 レガシーオンプレミス状況と課題 当社のオンプレミスのレガシーインフラストラクチャは、IBM PureData System をログレベルのデータウェアハウスとした構成で、MySQL データベースを使用してメタデータと分析データのすべてを保存しました。この仮想化されていない物理的な環境では、データの増加に対応するために、容量をかなり前から注意深く計画する必要がありました。アップグレード、メンテナンス、およびバックアップの管理と、ワークロードとクエリパフォーマンスの日常的な管理を行うためには、かなりの人数のチームが必要でした。 数多くの課題にも直面しました。ログレベルのデータのデータウェアハウスへのロードに利用できる帯域幅は 1 ギガバイトしかありませんでした。ピークロード時には、ETL (extract/transform/load) サーバーがフル稼働状態になり、帯域幅がボトルネックになって、データが分析用に利用できるようになる時間を遅らせました。データウェアハウスに対するソフトウェアとファームウェアのアップグレードはスケジュールしておかなければならず、メンテナンスのダウンタイムは完了までに 8 時間かかることもありました。このインフラストラクチャは脆弱でもありました。すべての事をひとつの PureData System で実行しており、別個の開発/テスト環境はありませんでした。当社の本番環境に直接アクセスできるクライアントは、不正確な SQL クエリを発行してデータウェアハウス全体をダウンさせる可能性がありました。 私たちはログレベルのデータから集約を作成し、それらを MySQL に保存しました。インデックスはロードプロセスを大幅に減速させました。実行したかった集約のいくつかは、どう見ても実行不可能でした。200 ギガバイトの圧縮されていない行ベースのデータに対するアドホック (一回限りの) クエリは、完了にとても長い時間がかかりました。ダッシュボードクエリの多くは 10~15 分、またはそれ以上かかり、最終的にはキャンセルされました。ユーザーが不満を抱いていたため、私たちが全面的に、応答性が高いソリューションに進化しなければならないことは明白でした。Bannerconnect は、データウェアハウスのために AWS と Amazon Redshift を選びました。 Amazon Redshift への移行 当社のレガシーソフトウェアはクラウドでの実行向けに設計されていなかったため、私たちは利用できるすべての AWS コンポーネントを使用してアプリケーションを再構築することに決定しました。そうすることによって、移行プロセスの煩わしさが省かれ、AWS の可能性を最大限に生かすようにアプリケーションを設計することができました。 当社の新しいインフラストラクチャは、ログレベルのデータのウェアハウスとして Amazon Redshift を使用します。本番プロセスには 40 […]

Read More