Amazon Web Services ブログ

Category: AWS Lambda

Apache Spark を実行しているAmazon Kinesis Data Firehose と Amazon EMR によるダウンストリームデータ処理の最適化

増え続けるデータを処理し、新しいデータソースを取り込むことは、多くの組織にとって大きな課題となっています。  多くの場合、AWS のお客様は接続中のさまざまなデバイスやセンサーからメッセージを受け取っていますが、それらを詳しく分析する前に、効率的に取り込み、処理する必要があります。  結果として、あらゆる種類のデータが行き着くソリューションが Amazon S3 となるのは当然と言えるでしょう。  ただし、データが Amazon S3 に格納される方法によって、ダウンストリームデータ処理の効率とコストに大きな違いが生じる可能性があります。  具体的に言うと、Apache Spark では少数の大きなファイルを処理する場合に比べて、小さいファイルを数多く処理すると、ファイル操作に負担がかかります。  これらのファイルにはそれぞれ、メタデータ情報のオープン、読み込み、クローズの処理に数ミリ秒のオーバーヘッドがあります。これらのファイルを数多くファイル操作すると、このオーバーヘッドのために処理が遅くなります。このブログ投稿では、Amazon Kinesis Data Firehose を使用して、Amazon S3 に配信する多数の小さいメッセージを大きいメッセージにマージする方法を説明しています。  この結果、Spark を実行している Amazon EMR の処理が高速化します。 Amazon Kinesis Data Streams と同様、Kinesis Data Firehose は最大で 1 MB のメッセージサイズを受信できます。  単一のメッセージが 1 MB を超える場合は、ストリームに配置する前に圧縮できます。  ただし量が多い場合、メッセージのファイルサイズが 1 MB 以下だと通常小さすぎます。  正しいファイルサイズというものはありませんが、多くのデータセットでは 1 MB を指定するとファイルの数とファイル操作が多すぎることになるでしょう。 この投稿では、Amazon S3 にある Apache Spark を使用して、圧縮ファイルを読み込む方法についても説明します。この圧縮ファイルには適切なファイル名拡張子がなく、parquet […]

Read More

Amazon Connectのスケジュールされた レポートを自動的に送信する

コンタクトセンターではデータが重要です。 スーパーバイザとマネージャは、レポートを使用して、チームのパフォーマンスを確認し、要員配置の計画を立てます。 必要なときに必要なデータを人々に提供することは不可欠です。 このブログ記事では、レポートの生成を有効にしてEメールで自動的にユーザーに送信する方法について説明します。 以下のサービスを使用します。 Amazon S3 AWS Lambda Amazon SES Amazon CloudWatch with Amazon Connect このブログでは、 AWS CloudFormationを使用してデプロイを簡素化する方法についても説明します。 このブログのソリューションでは、 Amazon Connectのネイティブレポート機能を使用してレポートを設定およびスケジュールします。 そのスケジュール設定されたレポートは、Amazon Connectの設定で指定したS3バケットに作成されます。 レポートがS3に作成されると、Lambda関数を起動するイベントが発生します。 Lambda関数はイベントを読み取り、S3からレポートを取得して、指定されたEメールアドレスに送信します。 すべてのアクティビティは追跡目的でCloudWatchに記録されます。 では始めましょう。 このセットアップを完了するには、次のものが必要です。 アクティブなAWSアカウント us-east-1(バージニア北部)またはus-west-2(オレゴン)のいずれかにあるAmazon Connectインスタンス。 Amazon SESはこれらのAmazon Connectリージョンでのみ使用可能であるため、この設定ではこれら2つのリージョンのみがサポートされています。 インスタンスを作成したら、電話番号を取得します。 詳細については、Amazon Connect の使用開始を参照してください。 あなたのアカウントに設定されたAmazon SES。 このソリューションでは、Amazon SESを使用してレポートを指定の受信者にEメールで送信します。 SESを使用してEメールを送信するには、送信元アドレスを確認して、自分が所有者であることを示します。 サンドボックスにいる場合は、 送信先アドレスも確認する必要があります。 あなたは、Eメールアドレスまたはドメイン全体を確認することができます。 検証プロセスについては、Amazon SES のIDの検証を参照してください。 アカウントをサンドボックスから削除する方法については、Amazon SES サンドボックスの外への移動を参照してください。 このCloudFormationテンプレートを実行するための適切なIAM権限。 これには、IAMロールとLambda関数を作成する権限が含まれます。 […]

Read More

高度な Amazon CloudWatch メトリクスと AWS Lambda を使用したアイドルチェックとリソースの自動終了による Amazon EMR コストの最適化

多くのお客様が、その開発環境で Apache Spark および Apache Hive のクエリなどのビッグデータワークロードを実行するために Amazon EMR を利用しておられます。データアナリストとデータサイエンティストは、分析 EMR クラスターとして知られるこれらのタイプのクラスターを頻繁に使用しますが、ユーザーは、作業終了後にクラスターを終了し忘れることがしばしばあります。これはクラスターのアイドル実行につながり、不必要なコストが生じることになります。 このオーバーヘッドを避けるため、EMR クラスターのアイドル状態を追跡し、アイドル状態で長時間にわたって実行される場合にクラスターを終了する必要があります。YARN ジョブが実行されているかどうかをチェックすることによってクラスターのアイドル状態を判断する Amazon EMR ネイティブの IsIdle Amazon CloudWatch メトリックがありますが、クラスターがアイドル状態かどうかを判断するためにも、接続されている SSH ユーザー、または実行中の Presto ジョブなどの追加のメトリクスを検討するべきです。また、Apache Zeppelin で Spark ジョブを実行する場合、ジョブの実行が終了した後でも、IsIdle メトリックが長時間アクティブ (1) 状態のままとなります。このような場合、IsIdle メトリックはクラスターの非アクティブ状態を判断するには適切ではありません。 このブログ記事では、このオーバーヘッドコストを削減するソリューションを提案します。このため、EMR クラスターのマスターノードにインストールされるバッシュスクリプトを実装しました。このスクリプトは 5 分ごとに実行されるようにスケジュールします。スクリプトはクラスターを監視し、5 分ごとにカスタムメトリック「EMR-INUSE」 (0 = 非アクティブ、1 = アクティブ) を CloudWatch に送信します。CloudWatch が事前定義されたデータポイントセットの一部に対して 0 (非アクティブ) を受け取ると、CloudWatch がアラームをトリガーし、アラームがクラスターを終了する AWS Lambda 関数を実行します。 […]

Read More

データカタログと ETL ジョブの AWS Glue トリガーを使用してサーバーレスデータレイクを構築および自動化する

今日、データは、IoT センサー、アプリケーションログ、クリックストリームなどのリソースの非構造化データ、トランザクションアプリケーション、リレーショナルデータベース、スプレッドシートの構造化データなど、あらゆる場所から流れています。データはすべてのビジネスにとって非常に重要な部分になりました。そのため、データから迅速にデータを抽出するために、信頼できる唯一の情報源を維持し、データの取り込みから変換、分析まで、パイプライン全体を自動化する必要があります。 データ量、速度、種類が増えるにつれて、データ分析の複雑さに対する懸念が高まっています。この懸念は、データをビジネスユーザーが使用できる状態にするために必要な手順の数と複雑さから生じています。多くの場合、データエンジニアリングチームは、パイプラインの構築と、その抽出、変換、ロード (ETL) の最適化に時間を費やしています。プロセス全体を自動化することで、価値実現までの時間と運用コストを削減できます。この記事では、完全に自動化されたデータカタログと ETL パイプラインを作成してデータを変換する方法について説明します。 アーキテクチャ この記事では、以下のアーキテクチャを構築して自動化する方法を学びます。 プライマリデータストアとして Amazon Simple Storage Service (Amazon S3) を使用して、サーバーレスデータレイクを構築します。Amazon S3 のスケーラビリティと高可用性を考えると、データの信頼できる唯一の情報源として最適です。 Amazon S3 にデータを取り込み、保存するためにさまざまな手法を使用できます。たとえば、ストリーミングデータを取り込むために Amazon Kinesis Data Firehose を使用できます。既存のデータベースからリレーショナルデータを取得するために AWS Database Migration Service (AWS DMS) を使用できます。また、AWS DataSync を使用して、オンプレミスのネットワークファイルシステム (NFS) からファイルを取り込むこともできます。 取り込まれたデータは Amazon S3 バケットに入り、これを raw ゾーンと呼びます。そのデータを利用できるようにするには、そのスキーマを AWS Glue のデータカタログに登録する必要があります。これを行うには、Amazon S3 トリガーによって呼び出される AWS Lambda 関数を使用して、データをカタログ化する AWS Glue クローラを起動します。クローラによるテーブル定義の作成が完了したら、Amazon […]

Read More

Serverless Tech/事例セミナー(2019年3月27日 実施) レポート Vol.3

2019年3月27日 実施のセミナーのレポート 3部編の Vol.3 です。他の回は以下のリンクよりアクセスください。 Vol.1 : 手段先行でも悪くはない!Ruby on LambdaではじめるServerless Vol.2 : Ruby on Lambdaで変わる大規模サービスの裏側 Vol.3 : Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方 [本記事]     Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方 [資料はこちら] クラスメソッド株式会社 和田祐介氏

Read More

Serverless Tech/事例セミナー(2019年3月27日 実施) レポート Vol.2

2019年3月27日 実施のセミナーのレポート 3部編の Vol.2 です。他の回は以下のリンクよりアクセスください。 Vol.1 : 手段先行でも悪くはない!Ruby on LambdaではじめるServerless Vol.2 : Ruby on Lambdaで変わる大規模サービスの裏側 [本記事] Vol.3 : Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方     Ruby on Lambdaで変わる大規模サービスの裏側 [資料はこちら] Sansan株式会社 Eight事業部 Engineering Group/エンジニアリングマネージャー 藤井洋太郎氏

Read More

Serverless Tech/事例セミナー(2019年3月27日 実施) レポート Vol.1

「AWS re:Invent 2018」では多くのサーバーレス関連のアナウンスがありました。その中でも、Ruby や COBOL を始めとする開発言語対応の拡張やカスタムランタイム、共有ライブラリ管理機能(Layers)は、サーバーレスの成熟と広がりを感じさせるものでした。特に、日本で利用者の多い Ruby は長い間望まれていたことから、プロジェクトでの適用が急速に進みはじめています。 そこで、すでに利用し始めていただいているお客様として、ヴァル研究所様およびSansan様に2019年3月27日に実施のServerless Tech/事例セミナーで登壇いただき、その経験を共有いただきました。開発言語としてのRubyに対する熱い想いやモチベーションが伝わる講演内容でした。また、これからサーバーレスを検討される参加者のために、従来型開発との考え方の違いを、開発の観点からクラスメソッド様より説明がありました。 Vol.1 : 手段先行でも悪くはない!Ruby on LambdaではじめるServerless [本記事] Vol.2 : Ruby on Lambdaで変わる大規模サービスの裏側 Vol.3 : Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方     手段先行でも悪くはない!Ruby on LambdaではじめるServerless [資料はこちら] 株式会社ヴァル研究所 マーケティングテクノロジー部 CB開発チーム 福本江梨奈氏

Read More

Amazon Connectで作るセキュアなIVRソリューション

Amazon Connectで作るセキュアなIVRソリューション Amazon Connectの問い合わせフローを使用して、ダイナミックな自動音声応答(IVR)ソリューションを作成できます。 Amazon Connectを使用すると、適切に個人情報を収集し、IVRによる顧客体験をカスタマイズすることができます。 個人情報として、社会保障番号、クレジットカード情報、および住所などが考えられます。 コンプライアンス上の理由から、個人情報など機密性の高い情報は通信時および保管時に暗号化する必要があります。 常に個人情報は暗号化しましょう。 このブログでは、Amazon Connectの[顧客の入力を保存する]ブロックを使用して機密な個人情報を収集し、ご自身でお持ちの暗号化キーを使用してデータを自動的に暗号化する方法について説明します。 この機能により、暗号化の要求に応えることができます。 この目的のために、Amazon ConnectはAWS Encryption SDKを使用して顧客提供データを暗号化します。 SDKはエンベロープ暗号化アプローチを使用します。 これにより、生データとそれらの暗号化に使用されるデータキーの両方が保護されます。 AWS Encryption SDKの機能の詳細については、Envelope Encryptionを参照してください。 この記事では、以下の手順を説明しています。 クレジットカード番号を収集するようにAmazon Connectを設定します。 クレジットカードの番号を暗号化します。 ご自身でお持ちの復号化キーを使って復号化するために、バックエンドのAWS Lambdaに暗号化されたクレジットカード番号を送信します。 次の図に示すAmazon Connect問い合わせフローを使用します。 セキュアなIVRの作成 このセキュアなIVRを作るために、以下を実施する必要があります。 新しい暗号化キーと復号化キーを作成するか、既存のものをインポートします。 復号化キーをAWSパラメータストアに安全に保存する 収集した番号を復号化するためのAWS Lambda関数を作成します。 収集したクレジットカード番号を暗号化するために、Amazon Connectに公開鍵をアップロードします。 前のセクションで説明した問い合わせフローを作成します。 注意 セキュアなIVRを作るために、AWS Command Line Interface(AWS CLI)がインストールされ、セットアップされ、Amazon Connectインスタンスと同じリージョンに設定されていることを確認しましょう。 ターミナルウィンドウから“ aws configure”を実行できることを確認し、デフォルトのリージョンパラメータに正しい値が設定されていることを確認します。 Amazon Connectの顧客入力を暗号化する機能は、ご自身でお持ちの公開鍵を使用してデータを暗号化するように設計されています。 これにより、自分の秘密鍵を使用してデータを復号化し、データを後続処理に利用できます。 顧客だけが知っている秘密鍵を使用すると、要求されるプライバシーを保護するのに役立ちます。 既存の鍵ペアを使用することも、新しい鍵ペアを作成することもできます。 鍵情報が利用可能であるかぎり、このプロセスは変わりません。 […]

Read More

Amazon Connectインスタンスへの迷惑電話を特定し対処する

我々はAmazon Connectによって強化されたコンタクトセンターを展開してきました。 あなたは今、顧客から電話で問い合わせを受けています。 素晴らしいことです。 ただし、迷惑電話が増えてきていることにも気付いています。 それはあまり素晴らしいことではありません。 このブログでは、発信者の番号に基づいてこの不要な着信通話の発信者を識別するソリューションを構築する方法をご紹介します。 着信を識別して対処するステップ まず、Amazon DynamoDBに電話番号のリストを作成し、Amazon Connectにすべての着信呼び出しについてこのリストをチェックさせます。 Amazon Connectがこのリストにアクセスするために、AWS LambdaをAmazon Connect問い合わせフローと統合します。 その後、すべての着信呼び出しに対してそのLambda関数を実行します。 AWS Lambdaは、着信呼び出しの番号についてデータベースを検索します。 一致したレコードが見つかった場合に問い合わせフロー内で別のパスへルーティングできるようにするために、AWS Lambdaはレコードの一致を示す値を返します。 このプロセスの4つのステップは以下のとおりです: Amazon DynamoDBにテーブルを作成する AWS Lambdaを使用して番号データベースを検索する 問い合わせフローでAWS Lambdaを使用するようにAmazon Connectを設定する Amazon Connectに返される値を確認する ステップ1:Amazon DynamoDBにテーブルを作成する Amazon DynamoDBコンソールを開きます。 テーブル作成を選択します。 [テーブル名]に、filteredNumbersと入力します。 プライマリキーにphoneNumberと入力します。 デフォルト設定を使用をチェックしたままにして、作成を選択します。 テーブルを作成したら、ブロックする電話番号を追加します。filteredNumbersを選択し、項目タブを選択し、「項目の作成」を選択します。 国際的に認められたE.164形式で電話番号を入力してください。 たとえば、北米の場合は+ 15551234567などです。 ブロックする番号を入力してから、保存を選択します。 ブロックするすべての番号について手順6を繰り返します。 注意 電話番号を入力するこれらの手順では、番号を個別に入力する必要があります。 電話番号をまとめて追加する方法については、DynamoDB CLIリファレンスを参照してください。 ステップ2:AWS Lambdaを使用して番号リストを検索する AWS Lambdaは、Amazon ConnectとAmazon DynamoDBテーブルをつなぐパイプの役割を果たします。 Amazon […]

Read More

弊社のデータレイク物語:Woot.comはどのようにしてAWS上でサーバーレスデータレイクを構築したか

この投稿では、当社が受け継いできた関係データベース上に構築されたデータウェアハウスの代替としての、cloud-nativeデータウェアハウスの設計についてお話します。 設計過程のはじめで、最も簡単に見える単純なソリューションは、関係データベースから他のものへのリフト&シフトマイグレーションです。しかし、当社は一歩戻り、まずはデータウェアハウスで何が本当に必要とされているかに焦点を当てることに決めました。当社はどのようにして、正しいツールを適した業務に使用することにより、従来のオラクルデータベースをより小さなマイクロサービスに分離できるかに着目し始めました。当社の方法はAWSツールを使用するだけではありませんでした。さらに、それはcloud-native技術を使用して当社を最終状態に持っていくためにマインドシフトすることでした。 このマイグレーションには既存データもマイグレートさせながら新規のデータを流入させるために、新規の抽出、変換、ロード(ETL)パイプラインが必要でした。このマイグレーションのため、AWS Glueに統合されることにより、当社は多くのサーバーを除去し、完全にサーバーレスのデータウェアハウスに移行することができました。 このブログ投稿で、当社は以下をご覧に入れます: 当社がデータウェアハウスのためにサーバーレスデータレイクを選択した理由。 Woot’sシステムのアーキテクチャー図。 マイグレーションプロジェクトの概要。 当社のマイグレーションの結果。 アーキテクチャーおよび設計の関係 こちらは当社が考慮した設計重点の一部です: 顧客体験。当社は常にお客様が必要とすることから始め、そこから戻るように業務を行いました。当社のデータウェアハウスは様々なレベルの技術専門性を持った人々による事業を渡って使用されます。 当社は異なるタイプのユーザーが運用の中に識見を持つ能力に焦点を当て、全体的な顧客体験を向上させるために、より良いフィードバックメカニズムを提供します。 最小限のインフラストラクチャーメンテナンス。「Wootデータウェアハウスチーム」は本当にたった一人の人です-Chaya! このため、当社がcloud-native技術を使用することができるAWSサービスに集中することは当社にとって重要です。これらは需要が変化し、技術が進化するにつれ、未分化性のインフラストラクチャーの管理といった困難な仕事を取り除きます。 データソースの変化に対する応答性。当社のデータウェアハウスは内部サービスの範囲からデータを取得します。弊社の既存のウェアハウスでは、これらのサービスへのいずれの更新でETL業務および諸表で手動による更新が必要でした。これらのデータソースのための応答時間は当社の主要関係者にとって重大なことです。このために当社は高性能アーキテクチャーの選択に向けたデータ主動のアプローチが必要でした。 生産システムからの分離。当社の生産システムへのアクセスは固く結びついています。複数のユーザーを許容するため、当社はそれを生産システムから分離し、複数のVPCsでのリソースをナビゲートすることの複雑さを最小化する必要がありました。 これらの要件に基づき、当社は運営面およびアーキテクチャーの面の両方で、データウェアハウスを変更することを決定しました。運営の観点から、当社はデータ摂取の目的で新規の共有応答モデルを設計しました。アーキテクチャーの面で、当社は従来の関係データベースに代わってサーバーレスモデルを選択しました。これら2つの決定は、当社がマイグレーションで行った、すべての設計および実装の決定を動かすこととなりました。 当社が共有応答性モデルに移行するにあたって、複数の重要な点が浮上しました。第一に、当社のデータ摂取の新しい方法はWootの技術組織にとっては主要な文化シフトでした。過去に、データ摂取は専らデータウェアハウスチームの担当で、サービスからデータを引っ張るためにカスタム化されたパイプラインが必要でした。当社は「押し、引かない」にシフトしました:サーバーがデータウェアハウスにデータを送信するべきである。 これが共有責任が行き着いたところでした。初めて、当社の開発チームがデータウェアハウスのサービスデータ全体の所有権を持ちました。しかし、当社は開発者にミニデータエンジニアになってほしくありませんでした。代わりに、当社はデータをプッシュするために、彼らに開発者の既存のスキルセットに適合する簡単な方法を示しました。データは当社のウェブサイトで使用される技術の範囲でアクセス可能である必要がありました。 これらの検討されたことは当社をサーバーレスデータウェアハウス向けの、以下のAWSサービスを選択することに導きました。 データ摂取用Amazon Kinesis Data Firehose データ保存用Amazon S3 データ処理用AWS Lambda および AWS Glue AWS データマイグレーションサービス (AWS DMS) および データマイグレーション用AWS Glue 統合およびメタデータ管理用AWS Glue クエリおよびデータ視覚化用 Amazon Athena および Amazon QuickSight 以下のデータグラムは当社がどのようにこれらのサービスを使用するかをハイレベルで示します。 トレードオフ これらの構成要素は共に当社のすべての要件を満たし、共有責任モデルを実行可能にしました。しかし、当社はリフト&シフトマイグレーションをもう一つの関係データベースと比較し、数回のトレードオフを行いました。 最大のトレードオフは先行投資の努力対進行中のメンテナンスでした。当社はすべてのデータパイプラインをもって効果的に白紙の状態から開始し、新しい技術を当社のすべてのウェブサイトサービスに導入しました。これには複数のチームを渡り協力的な努力が必要となりました。最小限の現行メンテナンスは核心要件でした。当社が使用するサーバーレスコンポーネントの管理されたインフラストラクチャーの優位点を利用するために、当社は快くこのトレードオフを行いました。 もう一つのトレードオフは非技術ユーザー対ビッグデータテクノロジーを利用することの有用性のバランスを取ることでした。顧客体験を核心要件にすることは、当社がこれらのトレードオフを検討するときに、意思決定を導くのを助けました。最終的には、他の関係データベースへの切り替えは、当社のお客様が同じ体験をするだけで、より良い体験をするわけではなかったのです。 Kinesis Data Firehose および […]

Read More