Author: Danilo Poccia

Amazon Redshift では SQL を使用して、データウェアハウス、運用データベース、データレイク全体で、エクサバイトの構造化データと半構造化データをクエリし、組み合わせることができます。AQUA (Advanced Query Accelerator) の一般提供が開始されたので、追加コストやコードの変更なしで、クエリのパフォーマンスを最大で 10 倍向上させることができます。実際、Amazon Redshift は、他のクラウドデータウェアハウスよりも最大で 3 倍優れたコストパフォーマンスを提供します。 しかし、さらに一歩進んで、このデータを処理して機械学習 (ML) モデルをトレーニングし、ウェアハウス内のデータからのインサイト生成にこれらのモデルを使用したい場合は、どうしたらよいでしょうか。 たとえば、収益の予測、顧客のチャーン予測、異常の検出などのユースケースを実装するには？ 以前なら、トレーニングデータを Amazon Redshift から Amazon Simple Storage Service (Amazon S3) バケットにエクスポートし、機械学習トレーニングプロセス (たとえば Amazon SageMaker を使用します) を設定してから、始めなければなりませんでした。このプロセスには、さまざまなスキルがいくつも必要で、完了するには何人も必要になります。もっと簡単にできないでしょうか。 現在、Amazon Redshift MLが一般公開されており、Amazon Redshift クラスターから直接、機械学習モデルを作成、トレーニング、デプロイすることができます。機械学習モデルを作成するには、シンプルな SQL クエリを使用して、モデルのトレーニングに使用するデータと、予測する出力値を指定します。たとえば、マーケティング活動の成功率を予測するモデルを作成するには、1 つ以上のテーブルで、顧客のプロフィールと、前回のマーケティングキャンペーンの結果を含む列を選択して入力を定義し、さらに予測を出力する列を定義します。この例では、顧客がキャンペーンに関心を示したかどうかを示す列が、出力列になります。 SQL コマンドを実行してモデルを作成すると、Redshift ML は指定されたデータを Amazon Redshift から S3 バケットに安全にエクスポートし、Amazon SageMaker Autopilot を呼び出してデータを準備します […]

Amazon CloudFront を使用すると、データ、動画、アプリケーション、API を低レイテンシーと高速転送速度で世界中の顧客に安全に配信できます。カスタマイズされたエクスペリエンスを可能な限り最小のレイテンシーで提供するために、今日の多くのアプリケーションはエッジで何らかの形式のロジックを実行します。エッジでロジックを適用するユースケースは、主に 2 つのカテゴリに分類できます。 最初のカテゴリは、オブジェクトがキャッシュにないときに実行される複雑な計算負荷の高いオペレーションです。私たちは、広範で複雑なカスタマイズを実装するための完全にプログラミング可能なサーバーレスエッジコンピューティング環境を提供するために 2017 年に Lambda@Edge を立ち上げました。Lambda@Edge 関数は、リージョンのエッジキャッシュで実行されます (通常は、クライアントがアクセスする CloudFront エッジロケーションに最も近い AWS リージョン内にあります)。たとえば、動画やオーディオをストリーミングする場合、Lambda@Edge を使用して適切なセグメントをすばやく作成して提供することで、オリジンのスケーラビリティの必要性を減らすことができます。もう 1 つの一般的なユースケースは、Lambda@Edge と Amazon DynamoDB を使用して、短縮されたユーザーフレンドリーな URL を完全な URL ランディングページに変換することです。 ユースケースの 2 番目のカテゴリは、非常に短命の関数で実行できるシンプルな HTTP(S) リクエスト/レスポンス操作です。このユースケースでは、パフォーマンス、スケール、費用対効果を備え、各リクエストで操作を実行できる柔軟なプログラミングエクスペリエンスが必要です。 この 2 番目のユースケースを支援するために、218 以上の CloudFront エッジロケーションで軽量の JavaScript コードを Lambda@Edge の 1/6 のコストで実行できる新しいサーバーレススクリプトプラットフォームである CloudFront Functions の提供が開始されました。 CloudFront Functions は、次のようなウェブリクエストの軽量な処理に最適です。 キャッシュキーの操作と正規化: HTTP リクエスト属性 (URL、ヘッダー、クッキー、クエリ文字列など) […]

イベント駆動型アーキテクチャは、イベントを使用して、1 つ以上のアプリケーションのコンポーネント間で情報を共有します。イベントでは、API リクエストを受け取ったこと、ファイルがストレージプラットフォームにアップロードされたことや、データベースレコードが更新されたことなど、「何かが起こった」ことを教えてくれます。ビジネスイベントは、新しい顧客アカウントが作成された、支払いが成功したなど、お客様の活動に関連する何かを説明します。

Amazon CodeGuru は、コードの品質を向上させるデベロッパーツールであり、次の 2 つの主要コンポーネントで構成されています。 CodeGuru Reviewer は、プログラム分析と機械学習を使用して、コード内で見つけにくい潜在的な欠陥を検出し、改善のための提案を提供します。 CodeGuru Profiler は、ライブアプリケーションからランタイムパフォーマンスデータを収集し、アプリケーションのパフォーマンスを微調整するのに役立つ視覚化と推奨事項を提供します。 本日は、3 つの新機能を発表いたします。 CodeGuru Reviewer および CodeGuru Profiler 用の Python のサポート (プレビュー) – CodeGuru を使用して Python で記述されたアプリケーションを改善できるようになりました。このリリース以前には、CodeGuru Reviewer は Java コードを分析でき、CodeGuru Profiler は Java 仮想マシン (JVM) で実行されるアプリケーションをサポートしていました。 CodeGuru Reviewer 用の Security Detector – CodeGuru Reviewer 用の新しい検出機能セットで、セキュリティの脆弱性を特定し、Java コード内のセキュリティのベストプラクティスをチェックします。 CodeGuru Profiler 用の Memory Profiling – 時間の経過に伴うオブジェクトタイプごとのメモリ保持の新しいビジュアライゼーションです。これにより、メモリリークを検出し、アプリケーションによるメモリの使用を最適化することが容易になります。 これらの機能をもっと詳しく見てみましょう。 […]

安全性、耐障害性、および効率性に優れた高パフォーマンスソリューションの AWS での構築を支援するため、AWS は 2015 年に AWS Well-Architected Framework を一般公開しました。これは、1 部のホワイトペーパーとしてスタートしましたが、ドメイン固有のレンズ、ハンズオンラボ、およびワークロードを定期的に評価し、高リスク問題を識別して、改善点を記録するメカニズムを提供する AWS Well-Architected Tool (AWS マネジメントコンソールから無料でご利用いただけます) に拡大されました。 ワークロード固有のアドバイスをより多く提供するため、2017 年には「レンズ」の概念でフレームワークを拡張し、一般的な見解の枠を超えて、特定のテクノロジー分野に参入しました。現在、Software-as-a-Service (SaaS) ソリューションの構築を促進するために、AWS SaaS Factory チームが新しい AWS Well-Architected SaaS レンズ を構築する取り組みを先導しています。 SaaS は、ソフトウェアがプロバイダーによって一元的に管理およびホストされ、サブスクリプションベースで顧客に提供されるライセンス供与/デリバリーモデルです。このモデルの使用により、ソフトウェアプロバイダーは迅速に革新し、コストを最適化して、運用効率性を向上させることができます。それと同時に、顧客側もシンプル化された IT 管理、スピード、および使用分の料金だけを支払うというビジネスモデルのメリットを活かすことができます。 Well-Architected SaaS レンズは、SaaS ワークロード向けにカスタマイズされ、SaaS ワークロードの開発と運用に対するクリティカルシンキングを促進することを目的とした質問をツールに追加します。各質問にはベストプラクティスのリストがあり、各ベストプラクティスにはそれらを実施するために役立つ改善計画のリストがあります。何千人ものソフトウェアデベロッパーや AWS パートナーと連携してきた AWS SaaS Factory Program の AWS ソリューションアーキテクチャは、これらの Well-Architected パターンを AWS で SaaS アーキテクチャを構築して運用するための重要な要素として認識しています。 Well-Architected Tool […]

AWS Lambda では、サーバーについて気にすることなくコードをアップロードして実行できます。多くのお客様に Lambda のこの仕組みをご活用いただいていますが、開発ワークフローのためにコンテナツールに投資した場合は、Lambda でのアプリケーションの構築に同じアプローチを使用することが難しくなります。 この問題に対応するため、Lambda 関数を最大 10 GB のコンテナイメージとしてパッケージ化し、デプロイできるようになりました。これにより、機械学習やデータ集約型のワークロードなど、大きな依存関係に頼る大規模なワークロードを簡単に構築してデプロイできます。ZIP アーカイブとしてパッケージ化された関数と同様に、コンテナイメージとしてデプロイされた関数は、同様の操作のシンプルさ、自動スケーリング、高可用性、多数のサービスとのネイティブ統合による恩恵を受けます。 当社では。サポートされているすべての Lambda ランタイム (Python、Node.js、Java、.NET、Go、Ruby) のベースイメージを提供しているため、コードと依存関係を簡単に追加することができます。Amazon Linux ベースのカスタムランタイム用のベースイメージも用意しており、これを拡張して Lambda ランタイム API を実装する独自のランタイムを含めることができます。 Alpine や Debian Linux をベースにしたイメージなど、独自のベースイメージを任意で Lambda にデプロイできます。Lambda を操作するには、これらのイメージに Lambda ランタイム API を実装する必要があります。独自のベースイメージの構築を容易にするため、当社ではサポートされているすべてのランタイムにランタイム API を実装する Lambda Runtime Interface Clients をリリースしています。これらの実装は、ネイティブのパッケージマネージャーを介して利用できるため、イメージ内で簡単に取得でき、オープンソースライセンスを使用してコミュニティと共有されます。 また、Lambda Runtime Interface Emulator をオープンソースとしてリリースします。これにより、コンテナイメージのローカルテストを実行して、Lambda にデプロイした際に実行されることを確認することができます。Lambda Runtime Interface Emulator は、AWS が提供するすべてのベースイメージに含まれており、任意のイメージでも使用できます。 コンテナイメージは、Lambda Extensions […]

AWS Graviton2 による Amazon Elastic Compute Cloud (EC2)インスタンスでワークロードを実行している Snap、NextRoll、Intuit、SmugMug、Honeycomb などのお客様からの素晴らしいフィードバックに基づき、本日、Arm ベースの幅広い Graviton2 ポートフォリオに加わる C6gn インスタンスを発表します。これにより、最大 100 Gbps のネットワーク帯域幅と、最大 38 Gbps の Amazon Elastic Block Store (EBS) 帯域幅を提供し、最大 40% 高いパケット処理パフォーマンス、それに現在の世代の x86 ベースのネットワーク最適化インスタンスと比較して最大 40% 高いコストパフォーマンスを実現します。 この新しいインスタンスタイプは、C6G インスタンスと比較して、4 倍のネットワーク帯域幅と 2 倍の EBS 帯域幅を提供し、4 倍のパケット処理パフォーマンスを実現します。つまり、ハイパフォーマンスコンピューティング (HPC)、ネットワークアプライアンス、リアルタイムビデオ通信、データ分析などの高いネットワーク帯域幅を必要とするワークロードを持つお客様は、最大かつ最も困難なアプリケーションを Arm に導入し、高いパフォーマンスとコスト最適化の利点を活かすことができます。 C6gn インスタンスは次の 8 つのサイズでご利用いただけます。 名前 vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS […]

データ処理パイプラインはそのボリュームを増し、ますます複雑になっていますが、プロセス全体を一連の小さなタスクに分解して簡素化し、これらのタスクの実行をワークフローの一部として調整することができます。その手段として、多くのデベロッパーやデータエンジニアが Apache Airflow を使用しています。Apache Airflow は、コミュニティによって作成され、プログラムによってワークフローを作成、スケジュール、モニタリングするプラットフォームです。Airflow を使用すると、ワークフローをスクリプトとして管理したり、ユーザーインターフェイス (UI) を介してワークフローをモニタリングしたり、強力なプラグインのセットを使用して機能を拡張したりできます。ただし、Airflow を手動でインストール、保守、スケールし、それと同時にユーザーのセキュリティ、認証、認可の処理を行うには多くの時間がかかり、実際のビジネス上の問題解決に集中できなくなってしまいます。 こうした問題点を解消するため、AWS で Apache Airflow のオープンソースバージョンを簡単に実行し、抽出、変換、読み込み (ETL) ジョブとデータパイプラインを実行するワークフローを構築可能な、フルマネージドサービスである Amazon Managed Workflows for Apache Airflow (MWAA) の提供を開始しましたことをお知らせします。 Airflow ワークフローでは、Amazon Athena クエリを使用して Amazon Simple Storage Service (S3) などのソースから入力を取得し、Amazon EMR クラスターで変換を実行し、結果として生成されたデータを使用して Amazon SageMaker で機械学習モデルをトレーニングできます。Airflow ワークフローは、Python プログラミング言語を使用して、有向非巡回グラフ (DAG) として作成されます。 Airflow の主な利点は、プラグインによりオープンな拡張が可能であることです。これにより、AWS とやり取りするタスクや、AWS Batch、Amazon CloudWatch、Amazon DynamoDB、AWS DataSync、Amazon ECS、AWS Fargate、Amazon Elastic Kubernetes […]

分析の実行、レポートの作成、あるいは機械学習の導入を始めるには、使用するデータがクリーンで適切な形式であることを確保する必要があります。このデータの準備ステップでは、データアナリストとデータサイエンティストに対し、カスタムコードの記述や、多くの手動操作が要求されます。そこではまず、データを見て、利用できそうな値を把握し、列同士の間に相関があるかどうかを確認するための簡単な可視化機能を構築する必要があります。その後、想定を外れた通常以外の値をチェックします。たとえば、200℉（93℃）を超えるような気温や、200mph（322 km/h）を超えるトラックの速度、そして欠落しているデータなどを洗い出します。多くのアルゴリズムでは、特定の範囲（たとえば 0 と 1 の間）への値の再スケールや、平均値を中心にした値の正規化が求められます。テキストフィールドは標準的な形式に設定するとともに、ステミングなどの高度な変換が必要な場合もあります。 これは大仕事です。今回、この仕事に対処するための AWS Glue DataBrew が利用可能になったことをお知らせできるのを、喜ばしく思っています。このサービスは、データのクリーンアップと正規化を 80% 高速化できる視覚的なデータ準備ツールであり、ビジネスから得られる価値に、お客様がより集中できるようにするものです。 DataBrew で提供されるビジュアルインターフェースでは、Amazon Simple Storage Service (S3)、Amazon Redshift、Amazon Relational Database Service (RDS) などに保存されたデータや、JDBC でアクセス可能なあらゆるデータストア、または AWS Glue データカタログによってインデックス化されたデータなどに、素早く接続できるようになります。その後、データを探索しパターンを見つけ出した上で、変換を適用できます。たとえば、結合やピボットの適用、異なるデータセットの統合、関数を使用したデータの操作を行います。 準備が終了したデータは、その場で、さらなるインサイトを得るために、AWS とサードパーティが提供するサービスを通じての利用が可能となります。それらのサービスには、機械学習用の Amazon SageMaker、分析用の Amazon Redshift と Amazon Athena、ビジネスインテリジェンス用の Amazon QuickSight と Tableau などがあります。 AWS Glue DataBrew の仕組み DataBrew を使用したデータの準備作業は、次の手順に従います。 S3 または Glue データカタログ（S3、Redshift、RDS）で、1 つ以上のデータセットに接続します。あるいは、DataBrew コンソールを使用すれば、S3 […]

その効率性と多数のプログラミング言語をサポートしていることから、gRPC はマイクロサービス統合およびクライアント/サーバー通信に人気のある選択肢となっています。gRPC は、HTTP/2 をトランスポートに使用し、インターフェイスを記述するためにプロトコルバッファを使用する、高性能なリモートプロシージャコール (RPC) のフレームワークです。 アプリケーションで gRPC を使用しやすくするために、Application Load Balancer (ALB) は HTTP/2 エンドツーエンドのサポートを開始しました。これにより、単一のロードバランサーを介して gRPC サービスを非 gRPC サービスとともに公開できるようになりました。Amazon Elastic Compute Cloud (EC2) インスタンスまたは IP アドレス (AWS Fargate など) を gRPC ターゲットとして使用し、ターゲットグループの gRPC ヘルスチェックをサポートできます。この方法により、ALB を使用して、マイクロサービス間、または gRPC 対応クライアントとサービス間の gRPC トラフィックの終了、ルーティング、およびロードバランシングを行うことができます。 ALB は、gRPC 呼び出しを検査し、適切なサービスにそれらをルーティングするためのリッチコンテンツベースのルーティング機能を提供します。具体的には、ALB は、gRPC ステータスコード、gRPC リクエスト数のメトリクス、gRPC リクエストを区別するアクセスログ、および gRPC 固有の応答ヘッダーを調べることができるヘルスチェックを提供します。さらに、持続性、さまざまなロードバランシングアルゴリズム、TLS 終了などのネイティブ機能を利用できます。 Application Load Balancer で gRPC を使用する方法 […]