Amazon Web Services ブログ

どのような組織でも直面する最大の課題の 1 つは、デジタル変革の概念に対する取組みです。組織やその従業員にとってそれが何を意味するのかを定義することさえ、困難な作業となり得ます。多くの組織にとって、その変革には、クラウドジャーニーと、他の新しい (またはやや新しい) テクノロジーの調査の開始が伴います。Discover で学んだことの 1 つは、ジャーニーの「デジタル」の部分にとらわれ過ぎて、「変革」の側面を見失ってしまわないようにしなければならないということです。最終的な目標は、テクノロジーそれ自体のために、新しいテクノロジーをもたらすことではありません。目標とするのは、顧客との約束をより効果的に実現する組織の能力を変革するテクノロジーです (顧客が社内か社外かにかかわらず)。 Discover のリーダーシップチームが分析とデータサイエンスの取り組みに注力し始めたことは、その顧客の約束を念頭に置いてのことでした。財務分野でビジネスを行うということは、長期にわたって、分析とデータサイエンスに極めて優れていなければならなかったということを意味します。私たちは何年にもわたって分析を活用して、詐欺の検出、意思決定、マーケティングなどに関する競争上の優位性を獲得してきました。その結果、これらすべての関連するビジネスユニットを中心に、個別の分析に関するプラクティスが生まれました。それらのほとんどすべてにおいて、要件、スキルレベル、好まれるツールはさまざまでした。Discover には最先端の研究を行う非常に才能のある人々がたくさんいます。リーダーシップチームの観点から見ると、これらの人々とチームをまとめることで、分析作業全体の改善が促進されることは当然のことのように思われました。技術的な観点からは、これらの人々とチームをまとめ上げる方法を見出すことには困難がありました。 このブログ投稿では、私たちが開発した Air9 と呼ばれるプラットフォームであるソリューションについて詳しく説明します。この困難を解決する際に、最初に合意した設計原則の 1 つは、多様性に強みがあるということでした。これには、チームとその経験の多様性だけでなく、さまざまなアプローチやツールも含まれます。この確立された分析コミュニティに、データサイエンスに対するフリーサイズのアプローチを持ち込むつもりはありませんでした。これにより、すべてのユーザー、ツール、およびデータを単一のプラットフォームに一元化するという単純な計画が導き出されました。これは、最終的に Air9 となるプラットフォームです。 このブログ投稿をさらに読み進める前に、同じコンテンツの多くをカバーする AWS re:Invent 2019 での Discover のプレゼンテーションのこの動画をチェックしてください。 適切なストレージソリューションを選択する Air9 プラットフォームの構築に向けたジャーニーでは、多くのデータサイエンスツールがコンテナ化に当然に用いられていたので、Kubernetes は自然に調和しました。専用のコンテナとポッドを備えることで、分離されたワークロードが可能になりました。この分離により、ユーザーはカスタムパッケージをインストールし、共有コンピューティングクラスターのようなマルチテナント環境で管理するのが難しい環境を調整できました。Amazon EC2 Auto Scaling を活用することで、需要に応じて、当社のコンピューティング機能を拡大および縮小することが可能になりました。 一元化されたデータサイエンスプラットフォームへのクリーンなアプローチのように見えたものは、ストレージレイヤーの設計を開始したときにすぐに問題に直面しました。当社の分析チームは、非常に大きなデータセットを持っています。データサイエンティストをご存知であれば、データウェアハウスに対して調査を行うのではなく、ローカルのデータセットの使用を非常に好むことをご存知でしょう。クラウドデータウェアハウスには大規模なデータセットがいくつかありましたが、データサイエンティストには個々の作業を行うためのローカルストレージが必要でした。また、チーム間 (およびチーム全体) でデータを共有するためのメカニズムも必要でした。このストレージレイヤーは、回復力があり、時間の経過に伴う大きな成長をサポートできる必要がありました。 Discover のテクノロジー組織は常に、新しいソリューションに対する「自分で構築できる」アプローチを好む傾向にあり、ビルダーとしてこれらの課題を楽しんでいます。チームは、データサイエンスプラットフォームのストレージレイヤーとして、オープンソースの分散ストレージソリューションの活用に乗り出しました。ビルドを好む傾向にある組織の重要な特徴の 1 つは、迅速に失敗し、アイデアを反復し、機能していないアイデアから次に進むタイミングを知る能力を有していることです。シャードキー、I/O パターン、成長予測、リカバリポイントの目標についての話し合いを余儀なくさせるいくつかの大きな頭痛の種を抱えつつ、社内の分散ストレージシステムに数週間を費やした後でも、大きく進捗しているようには見えませんでした。その間に、当社は、プラットフォームの初歩的な実装を提供し、ベータユーザーからかなりの量のデータがストレージソリューションに入力され始めました。この時点までのすべての課題を踏まえると、チームは、ソリューションが実現可能で持続可能であるかどうかについて不確かでした。最終的には、他の保管オプションを探すことを決定し、以下のコストチャートがとどめとなりました。 図 1: 請求に問題があります 通常、データサイエンスプラットフォームは、計算集約型の環境です。独自のストレージプラットフォームの運用に関連するコストがコンピューティングコストを超えるのを目にしたとき、何かがおかしいことがわかりました (図 1)。結局、過剰なコストは分散ストレージのレプリケーションファクターに起因するものでしたが、コストを削減する (レプリケーションファクターを削減する) トレードオフは、当社が満足できるものではありませんでした。 当社は、Amazon EC2 のスケーラビリティを活用してこのプラットフォームのコンピューティング側で成功を収めてきたので、ストレージ向けの AWS マネージドサービスを見直しました。Amazon […]

Software as a service (SaaS) アプリケーションはお客様にとってますます重要になり、それを採用するお客様も急速に増えてきています。このソフトウェアの利用方法には多くの利点がありますが、1 つの課題は、データがさまざまな場所に点在していることです。データから有意義な洞察を得るには、それを分析する方法が必要ですが、データが複数のデータアイランドに分散している場合は困難な場合があります。 開発者は膨大な時間をかけてカスタム統合を行い、SaaS アプリケーションと AWS のサービスの間でデータを渡して分析できるようにしています。これには高額の費用がかかり、完了までに数か月を要する場合もあります。データ要件が変更されると、統合に複雑な変更を加える必要があり、費用もかかります。潤沢なエンジニアリングリソースがない企業は、アプリケーションからデータを手動でインポートおよびエクスポートすることになるかもしれません。これは時間がかかり、データ漏洩のリスクがあり、人為的ミスを招く可能性もあります。 本日、この問題を解決する Amazon AppFlow と呼ばれる新しいサービスを発表できることを嬉しく思います。Amazon AppFlow を使用すると、AWS のサービスと、Salesforce、Zendesk、ServiceNow などの SaaS アプリケーション間のデータフローを自動化できます。SaaS アプリケーション管理者、ビジネスアナリスト、および BI スペシャリストは、IT が統合プロジェクトを完了するのに数か月待つことなく、必要な統合のほとんどをすばやく実装できます。 SaaS アプリケーションから AWS のサービスへのデータフローを可能にするだけでなく、AWS のサービスから SaaS アプリケーションへのデータの送信も行えます。AWS ではセキュリティが最優先事項であるため、すべてのデータは転送時に暗号化されます。一部の SaaS アプリケーションは AWS PrivateLink と統合されています。これにより、セキュリティとプライバシーがさらに強化されます。AWS PrivateLink を使用して SaaS アプリケーションと AWS の間でデータの送受信が行われる場合、トラフィックはパブリックインターネットを使用せずに Amazon ネットワークに留まります。SaaS アプリケーションがサポートしている場合、Amazon AppFlow が自動的にこの接続を処理し、プライベートデータの転送を誰にとっても簡単にし、インターネットベースの攻撃による脅威と機密データ漏洩のリスクを最小限に抑えます。 データ転送をスケジュールに従って、ビジネスイベントに応じて、またはオンデマンドで実行するようにスケジュールできます。これにより、データの共有を迅速かつ柔軟に行うことができます。 この新しいサービスの力を示すために、簡単なフローの構築方法を示します。 筆者はイギリスとアイルランドでウェブコミュニティのオーガナイザー向けに Slack ワークスペースを運営しています。Slack は […]

今日ご紹介するサービスの多くは機械学習 (ML) を必要とするものです。オンライン検索や製品のレコメンデーションから音声認識や翻訳まで、これらのサービスには予測を提供するための ML モデルが必要です。ML がさらに多くのサービスで採用されるにつれて、苦労して結果を得て、モデルを迅速かつ確実に本番環境にデプロイすることが困難になります。そして、これらのサービスを利用する人の数が増えるにつれて、モデルが数百万のユーザーに同時に、そして、安全かつ確実に、低レイテンシーで予測を提供できるようにすることには、より大きな困難が伴います。 開発者は、モデル開発にさまざまなオープンソースフレームワークを使用します。ここ数年、PyTorch は、ML を利用したアプリケーションを開発する多くの研究者、開発者、およびデータサイエンティストが選択する深層学習のフレームワークとなっています。PyTorch は、そのシンプルさに加えて、Python 的な方法でモデルを実装およびトレーニングでき、Eager モードと Graph モードをシームレスに切り替える機能があることから好まれています。しかしながら、これまで、PyTorch モデルを本番環境で大規模に提供することについて、簡単かつネイティブにサポートされた方法はありませんでした。 AWS は、PyTorch のオープンソースモデルサービスライブラリである TorchServe の実験的リリースを共有できることを嬉しく思います。 AWS は、Facebook と連携して TorchServe を開発しました。AWS と Facebook は、より広範な PyTorch コミュニティと共に、TorchServe に注力し続けます。クラウドベースの PyTorch プロジェクトが 83% を超えて AWS で行われていることから、PyTorch モデルのデプロイの困難に対処するために TorchServe を立ち上げることができることを幸いに思います。TorchServe を使用すると、PyTorch モデルを TorchScript を使用して Eager モードまたは Graph モードでデプロイし、複数のモデルを同時に提供し、A/B テスト用に本番モデルをバージョン管理し、モデルを動的にロードおよびアンロードし、詳細なログとカスタマイズ可能なメトリクスを監視できます。 TorchServe は使いやすいです。ローカルにデプロイするのに便利な CLI が付属しており、コンテナにパッケージ化して Amazon SageMaker […]

AWS Transfer for SFTP は、セキュアファイル転送プロトコル (SFTP) を使用して Amazon S3 との間でファイルを直接転送できるフルマネージドサービスとして、2018 年 11 月にリリースされました。 本日、サービスを拡張して、FTPS および FTP のサポートを追加することを発表します。これにより、既存の AWS Transfer for SFTP サービスに加えて、SSL を介したファイル転送プロトコル (FTPS) および AWS での FTP ワークロードを簡単に移行して安全に実行できます。Amazon S3 の SFTP、FTPS、および FTP ベースの転送をサポートする「AWS Transfer Family」も発表します。これは AWS Transfer for SFTP、FTPS、および FTP を総称したものです。 一部のソフトウェアアーカイブおよび科学研究用アプリケーションは FTP を使用してソフトウェアアーティファクトやパブリックデータセットを配信し、CRM、ERP、およびサプライチェーンアプリケーションは FTPS を使用して機密データを転送します。既存のアプリケーションの多くは、FTP または FTPS から SFTP に切り替えることができません。これは、既存のアプリケーションとプロセス (特にサードパーティが携わっているもの) を変更する必要があり、非現実的または実行不可能であることが多いためです。お客様は、既存の統合やエンドユーザーを混乱させることなくファイル転送プラットフォームを移行する、簡単で安全な方法を模索しています。このような理由により、AWS Transfer […]

今日のアプリケーションには、コンテナ、マイクロサービス、レガシー内部サービス、サードパーティサービスなど、数百または数千の可動パーツが含まれます。各パーツの正常性とパフォーマンスをモニタリングすることに加えて、許容できるカスタマーエクスペリエンスを提供するために、パーツが確実に噛み合うようにする必要があります。 (AWS re:Invent 2019 で発表した) CloudWatch Synthetics を使うと、サイト、API エンドポイント、ウェブワークフローなどをモニタリングできます。パフォーマンスと可用性の可視性が向上したアウトサイドインビューが表示されるため、これまでになく迅速に問題を認識し、対処できます。顧客満足度を高め、アプリケーションがパフォーマンス目標を満たしていることを確信できるでしょう。 CloudWatch Synthetics の使用を開始するのに、数分しかかかりません。個々のウェブページ、それにウィザードやチェックアウトなどのマルチページウェブワークフロー、API エンドポイントをモニタリングする Canary を作成するだけです。その際、メトリクスは Amazon CloudWatch に、そしてその他のデータ (スクリーンショットや HTML ページ) は S3 バケットに保存されます。Canary を作成するときに、パフォーマンス、動作、またはサイトの整合性に基づくしきい値を超えたときに通知を受け取れるように CloudWatch アラームを設定できます。障害にできるだけすばやく対処するため、スクリーンショット、HAR (HTTP アーカイブ) ファイル、およびログを確認して、障害の詳細を理解することができます。 CloudWatch Synthetics in Action Canary はかつて、炭鉱に致命的なガスが発生したことを早期に警告するために使われていました。CloudWatch Synthetics が提供する Canary は、同様の早期警告を発し、かなり人道的な面があります。開始するには、CloudWatch コンソールを開き、[Canaries] をクリックします。 Canary の全体的なステータスを一目で確認できます。 先月、このブログ記事の準備として、Canary をいくつか作成しました。私は、CNN のホームページ、個人ブログ、Amazon Movers and Shakers ページ、Amazon Best Sellers ページなど、いくつかのサイトを選択しました。どのサイトが最も興味深い結果を返すかはわかりませんでした。もちろん、それらのサイトのいずれかに何か特別な思い入れがあるというわけでもありません。重用なのは、この (そしてすべての) […]

Jeff が 2018 年にお約束したアフリカの AWS リージョンが開設されました。正式な名称はアフリカ (ケープタウン) で、API 名は af-south-1 です。今日からこの新リージョンを使用して、南アフリカでワークロードをデプロイし、データを保存できるようになります。 この新リージョンが加わったことで、すべての組織がアフリカ中のエンドユーザーに低レイテンシーのサービスを提供し、アフリカに拠点を置くより多くの組織が、AWS クラウドのパフォーマンス、セキュリティ、柔軟性、信頼性、使いやすさなどのメリットを利用できるようになります。この開始に伴い、すべての規模の組織で実験と革新をより迅速に実行できるようになります。 AWS リージョンは最高レベルのセキュリティ、コンプライアンス、データ保護をご提供します。この新リージョンを使用することで、データ所在地の要件がある現地のお客様、個人情報保護法 (POPIA: Protection of Personal Information Act) への準拠を予定されているお客様は、自社データの完全な所有権を維持し、お客様ご自身がデータの移動を選択しない限り、データが移動されることはないという保証に基づいて、南アフリカでコンテンツを格納できるようになります。 アフリカ (ケープタウン) は 23 箇所目の AWS リージョンで、アフリカでは初のリージョンとなります。3 つのアベイラビリティーゾーンで構成され、Global AWS Infrastructure ではアベイラビリティーゾーン (AZ) が合計 73 箇所になります。 インスタンスとサービス この 3 つのアベイラビリティーゾーンを持つリージョンで実行されるアプリケーションは、C5d、D2、I3、M5、M5d、R5、R5d、および T3 のインスタンスを使用でき、次の各種 AWS サービスを利用できます。Amazon API Gateway、Amazon Aurora (MySQL と PostgreSQL の両方)、Amazon CloudWatch、Amazon CloudWatch Logs、CloudWatch […]

完全マネージドサービスの Amazon SageMaker は、あらゆる開発者やデータサイエンティストが機械学習 (ML) モデルを迅速に構築、トレーニング、デプロイできるように支援します。Intuit、Voodoo、ADP、Cerner、Dow Jones、Thompson Reuters をご利用の数万人におよぶお客様が、Amazon SageMaker を使って ML の各プロセスで発生する負担の大部分を取り除いています。 リアルタイム予測に ML モデルをデプロイする場合、Amazon SageMaker には、小さな CPU インスタンスからマルチ GPU インスタンスに至る幅広い AWS のインスタンスタイプがあります。そのため、予測インフラストラクチャに適したコストとパフォーマンスの割合を見つけることができます。本日より、Amazon SageMaker で Inf1 インスタンスがご利用いただけるようになりました。これで、高いパフォーマンス、低いレイテンシー、コスト効率の高い推論を実現できます。 Amazon EC2 Inf1 インスタンス入門 Amazon EC2 Inf1 インスタンスは AWS re:Invent 2019 でリリースしました。Inf1 インスタンスは AWSが一から構築したカスタムチップの AWS Inferentia を使用しており、機械学習の推論ワークロードが加速します。G4 インスタンスと比較した場合、Inf1 インスタンスでは、推論のスループットが最大 3 倍となり、推論あたりのコストが最大 45％ 削減します。 Inf1 インスタンスは、1 個、4 個、または […]

Battlesnake は AI を搭載したヘビを構築する AI コンテストです。Battlesnake のルールは、従来のスネークゲームと類似しています。目標は、他のヘビと競争して、最後まで生き残るヘビになることです。あらゆるレベルの開発者が、独自のヒューリスティックベースの戦略から、最先端の深層強化学習 (RL) アルゴリズムまで、さまざまな技術を駆使してヘビを構築します。 SageMaker Battlesnake Starter Pack を使用して独自のヘビを構築し、Battlesnake アリーナで競うことができます。詳細については、Amazon SageMaker の強化学習を使用して AI で駆動する Battlesnake を構築するを参照してください。Starter Pack には、Amazon SageMaker で複数の戦略を開発するための開発環境が含まれています。戦略には、RL ベースのポリシートレーニングと決定木ベースのヒューリスティックが含まれます。以前の SageMaker Battlesnake Starter Pack では、Deep Q-Network (DQN) [1] ベースのスネークポリシーを開発するための Apache MXNet ベースのトレーニングスクリプトを提供しました。このアルゴリズムの実装は実践および変更が簡単で、初心者の開発者に教育体験を提供します。 この投稿では、フルマネージド型の RL に Amazon SageMaker を使用し、同じトレーニング時間で 10 倍の成果を提供する Starter Pack の更新について説明します。Starter Pack は、分散 RL トレーニングに Amazon SageMaker […]

ビジネスリーダーやテクノロジーリーダーと話すと、彼らは新しい製品やサービスを迅速に市場に投入することが必要だと話します。その一方で、彼らはセキュリティを継続的に確保する必要もあります。また同時に、時間とともに変化するビジネスニーズにワークロードを適応させながら、回復力のある環境を維持する必要があります。このブログシリーズでは、AWSのベストプラクティスを共有して、お客様がこれらのセキュリティ、スケーラビリティ、および適応性の要件を満たすようにAWS環境を計画するのを支援します。 私の目標は、クラウド環境の配備を管理するための設計上の考慮事項についてお客様をガイドすることです。このブログシリーズでは、今後、このガイダンスに沿った一般的なユースケースとパターンの実装を解説するブログを投稿していきます。

多数のIoTデバイスを持つ組織では、運用上の問題を特定して対処するために、複数のデバイス間で発生したイベントを追跡する効率的なソリューションが必要となります。この記事では、AcmeTrackerという架空の組織が、IoTデバイスを使用して車両のジオロケーションを追跡するサービスを提供しており、車両が予想されるジオロケーションの境界から外れるとサポートチームに通知する仕組みについて紹介します。AcmeTrackerはAWSのIoTサービスを使用してデバイスとそのデータを管理しています。各デバイスはAWS IoT CoreのFleet Provisioning機能を利用して固有のデバイスのクレデンシャル（証明書と秘密鍵）を取得し、各デバイスのジオロケーションはAWS IoT Eventsで監視しています。 今回の記事では、前述の車両監視ソリューションの運用概要を説明した後、以下のAWS IoTサービスのセットアップ方法について説明します。 AWS IoT Eventsを設定し、GPS座標を監視する AWS IoT CoreのFleet Provisioningでユニークなクレデンシャルをデバイスに設定する ソリューションの概要 とある複数の車両が特定のルートに従わなければならないシナリオを考えてみましょう。ジオロケーションの入力は、各車両を監視し、車両が予想される旅程に沿っていない場合に車両オペレータに通知するために使用されます。AcmeTrackerという組織は、プロビジョニング クレーム クレデンシャル(証明書と秘密鍵)を組み込んで製造されたIoTデバイスを提供しています。 デバイスはAWS IoT Device SDK for Pythonを使用してAWS IoTで認証するために、プロビジョニング クレーム クレデンシャルを使用します。Python以外のプログラミング言語もAWS IoT Device SDKでサポートされており、サポートされているプログラミング言語の一覧はこちらのページをご覧ください。 この車両監視ソリューションでは、以下のような一連のデータとメッセージのやり取りが行われます。 デバイスは、MQTTトピックを介してAWS IoT Coreサービスに、固有のデバイスクレデンシャルの作成（証明書と秘密鍵の作成）を要求します デバイスは、AWS IoT Coreサービスで定義されたプロビジョニングテンプレートに基づいて、MQTTトピックを介してAWS IoT Coreサービスへの登録（固有のデバイスクレデンシャルの有効化）を要求します デバイスは衛星からGPS座標を取得します デバイスは、そのGPS座標をMQTTトピックを介してAWS IoT Coreサービスにpublishします AWS IoT Coreルールエンジンは、MQTTトピックからGPS座標を取得します AWS IoT Coreルールエンジンは、そのGPS座標をAWS IoT Eventsに送信します AWS IoT Eventsサービスには検知器モデルがあり、受信したIoTイベント（GPS座標）を監視して、デバイスが想定される境界線内にあるかどうかを検出します […]