Category: Announcements

皆様の元には、お客様からのフィードバックが日常的に届いていることでしょう。それを基に、アプリケーションやインフラストラクチャをくり返し修正し、イノベーションのための改善をされていると思います。クラウドに置いた IT システムの変更は継続的なものです。ただ、現実を見てみると、稼働中のシステムで何かを変えることは、何かを壊すことでもあります。この結果、時には予測できない副作用を引き起こす危険があるのです。テストを何回行ったのかは重要ではありません。一方、変化を加えないということは停滞を意味します。その後に続くのは的外れのサービス提供、そして、その終了という結末です。 そのため、あらゆる規模とタイプの組織が、変更を上手に継続するための文化を、内部に醸成しています。一部の組織では、ITIL v4 で定義されている変更管理プロセスなどのシステムを採用しています。DevOps や、継続的デプロイを導入していたり、他の方法を採用している組織も存在します。いずれの場合にしても、変更管理プロセスを上手く運用するのに大切なのは、ツールを用意することです。 今回、AWS Systems Managerの新しい変更管理機能である、AWS Systems Manager Change Manager がリリースされました。このサービスにより、アプリケーションの構成やインフラストラクチャに対し運用エンジニアが行う、運用的な変更の追跡、承認、実装が簡素化されます。

本投稿は、Akshay Ram, Prithvi Ramesh, Michael Hausenblas による寄稿を翻訳したものです。   Container roadmap 上の issue 701 では、 EKS on Fargate 利用時の CNCF Fluent Bit を利用したログルーターのサポートについて議論していました。このブログ記事では、EKS on Fargete利用時におけるいくつかの設定ステップによってCloudWatch へ直接ログを送信する事が出来る新しい機能とそれを利用する流れをみていきましょう。 以前は、AWS Fargate 上で動くAmazon EKS の Pod から コンテナログを送信するためには サイドカーコンテナを動かす必要がありましたが、組み込みのログルーターを利用出来るようになりました。これはサイドカーをインストールしたり維持する必要が無いという事を意味しています。ユーザーはデータの送信先を選択するだけで、ログは選択した送信先にルーティングされます。 私たちは、2つの設計原則を維持しながらこの機能を構成しました。 一貫性：必要に応じて、ネイティブの Kubernetes オブジェクトを利用して、コンピューティングタイプ(EC2、マネージドノードグループ、Fargate)に渡った一貫したインターフェイスをお客様に提供する シンプル：お客様のインフラストラクチャーや add-ons をさらに管理する この設計原則に従う事で、Fluent Bit 設定言語と Kubernetes Config Map を、プライマリインターフェイスとして選択し、 Kubernetes クラスターにおける標準的な方法としてロギングを設定する様にしました。Fluent Bit をプラットフォームの中に含める事で、Fluent Bit のライフサイクル管理をシンプルにしました。ログを何処に送るかを指定するだけで、後はAWSによって管理されます。   […]

この記事は、 AWS Proton: A first look を翻訳したものです。 ※日本語字幕の表示には、設定 → 字幕 → 自動翻訳 → 日本語をご選択ください 我々がお客様のエンジニアチームと会話するときに、特にエンタープライズ規模のお客様の場合、開発チームとプラットフォームチームに分かれて組織化されていることがよくあります。通常、開発チームはサービスの作成とメンテナンスを担当し、プラットフォームチームは開発チームが簡単にサービスを展開できるようなツールを構築しています。このツールには多くの場合、ビルドパイプラインや可観測性、スケーリング、およびセキュリティについての既知のベストプラクティスが組み込まれています。

※日本語字幕の表示には、設定 → 字幕 → 自動翻訳 → 日本語をご選択ください EC2 および Fargate コンピュートタイプ用の Amazon ECS deployment circuit breaker をパブリックプレビューで発表しました。この機能により、Amazon ECS をご利用のお客様は、手動での作業を行うことなく、不健全なサービスデプロイを自動的にロールバックできるようになります。これにより、お客様は失敗したデプロイを迅速に発見できるようになり、失敗したタスクのためにリソースが消費されたり、デプロイが無期限に遅延したりすることを心配する必要がなくなります。 以前は、Amazon ECS でデプロイメントタイプにローリングアップデートを使用しているときに、サービスが健全な状態にならない場合、スケジューラは サービススロットリングロジック により永続的にデプロイを再試行していました。このデプロイの失敗を迅速に検知するには、追加でモニタリングの仕組みが必要であり、これは AWS CloudFormation を使用して Amazon ECS サービスをデプロイしているお客様にとっても厄介事の1つでした。 デプロイが失敗する理由はいくつかあり、例えば、コードやサービス構成に破壊的変更を加えた場合、希望のタスク数を立ち上げるために必要なリソースが不足している場合、コンテナやロードバランサのヘルスチェックに失敗した場合などです。ここで紹介したデプロイ失敗のシナリオは一部にしか過ぎず、deployment circuit breaker がどのような場面で役立つかを理解していただくための具体例として取り上げています。このブログの後半では、コンテナのヘルスチェックが失敗した場合のシナリオを例に deployment circuit breaker のデモを行います。   何をデプロイするか？ デプロイするデモアプリケーションは Python Flask Web サーバを実行しており、ECS サービスを介してデプロイされたタスク定義の現在のバージョンを表示します。このサービスの作成、デプロイ、更新には AWS CLI を使用します。まずはコード、Dockerfile、タスク定義を見て、これからデプロイされる内容の理解を深めることから始めてみましょう。 この Flask アプリケーションは、タスクメタデータエンドポイントからタスクのバージョンを取得しており、ウェブサイトにアクセスすることで、ECS サービスが実行しているタスク定義のバージョンが表示されます。このアプリケーションは circuit breaker […]

今日は、Grafana Labs とのパートナーシップにより、複数ソースからのデータを視覚化して分析するためのスケーラブルでセキュアなオンデマンド Grafana ワークスペースを簡単に作成できる完全マネージド型サービス、Amazon Managed Service for Grafana (AMG) のプレビューが開始されたことをお知らせします。 Grafana は、アプリケーションのためのオブザーバビリティダッシュボードの作成に使用される、最も人気のあるオープンソーステクノロジーの 1 つです。プラグイン可能なデータソースモデルを備えており、さまざまな種類の時系列データベースとクラウドモニタリングベンダーをサポートしています。Grafana は、複数のオープンソース、クラウド、およびサードパーティーデータソースからのアプリケーションデータを一元化します。 多くのお客様が Grafana を愛用しておられますが、それを独自にホストして管理する負担は抱えたくありません。AMG は Grafana のプロビジョニング、セットアップ、スケーリング、バージョンアップグレード、およびセキュリティパッチの適用を管理するので、お客様がそれらを自分で行う必要がなくなります。AMG は、優れた可用性で何千人ものユーザーをサポートするように自動的にスケールします。 AMG では、AWS、Google、および Microsoft などのクラウドサービスを含めた複数のデータソース全体で運用メトリクス、ログ、およびトレースをクエリ、関連付け、および視覚化できる、完全に管理されたセキュアなデータ可視化サービスを利用できます。AMG は、Amazon CloudWatch、Amazon Elasticsearch Service、AWS X-Ray、AWS IoT SiteWise、Amazon Timestream、およびその他の AWS データソースと統合し、シンプルな方法で運用データを収集します。これに加えて、AMG は、AWS コンソールから直接 Grafana Enterprise にアップグレードすることによって、Datadog、Splunk、ServiceNow、および New Relic などの一般的なサードパーティーデータソースに接続するプラグインも提供します。 AMG は AWS Organizations と直接統合されます。AMG ワークスペースは、AWS 組織のすべてのアカウントとリージョンにあるデータソースを検出し、アクセスすることを可能にする 1 つの AWS […]

今日は、皆さんに Amazon SageMaker Debugger が機械学習モデルのプロファイリングを実行できるようになったことをお知らせしたいと思います。これにより、ハードウェアリソースの使用率が原因で生じるトレーニング問題の特定と修正が極めて容易になります。 幅広いビジネス問題に対応する目覚ましいパフォーマンスにもかかわらず、機械学習 (ML) は今も謎めいたところがあるトピックです。物事の的確な実行は、サイエンス、職人技 (魔法と言う人もいます)、そして時には運を組み合わせた錬金術です。特に、モデルトレーニングは、結果がデータセット、アルゴリズムとそのパラメータ、そしてトレーニングを実行するインフラストラクチャの品質に応じて変化する複雑なプロセスです。 ML モデルがかつてない規模に増大し、ますます複雑になるにつれて (深層学習さん、あなたのことです) 拡大している問題のひとつに、モデルをトレーニングするために必要なインフラストラクチャの量があります。たとえば、一般公開されている COCO データセットでの BERT のトレーニングは、単一の p3dn.24xlarge インスタンスで実行すると、それに 8 個の NVIDIA V100 GPU が搭載されているにもかかわらず、6 時間を優に超える時間がかかります。自律走行車企業などのお客様には、はるかに大きなデータセットを扱い、オブジェクト検出モデルのトレーニングに数日間かけるお客様もおられます。 複雑なトレーニングジョブにこれだけの時間がかかると、何らかの不具合が生じてトレーニングが失敗に終わる可能性が非常に高くなり、時間を無駄にするだけでなく、大きないら立ちを感じる原因にもなります。調査を行い、根本的な原因をつきとめて修正を試み、それからトレーニングジョブを再度実行する間、重要な作業は後回しにしなくてはなりません。たいていの場合は、問題を突き止めるために、この手順をかなりの回数繰り返すことになります。 使用している ML フレームワーク、そして時にはそのバージョンによっては、既存のフレームワーク固有のツールを使用できるかどうかもわからず、多くの場合は、独自の特注ツールを構築して維持しなくてはならなくなります。これは、経験豊かなプラクティショナーでさえも大いに苦労する作業で、私のような普通のデベロッパーにとっては、気が遠くなるようなタスクでしかありません。 Amazon SageMaker Debugger のモデルプロファイリングのご紹介 去年の AWS re:Invent でローンチされた Amazon SageMaker Debugger は、ML トレーニングジョブで生じている複雑な問題を自動的に識別する Amazon SageMaker の機能です。これらの問題には、減少しない損失、および勾配爆発などが含まれます。 SageMaker Debugger がハードウェアリソースの使用率も監視できるようになった今、これからはトレーニングジョブをプロファイリングして、リソースの使用率とトレーニングスクリプトの ML オペレーションとの関連付けに役立てることができます。そうすることで、はるかに迅速にパフォーマンス問題を解決し、はるかに高速にトレーニングジョブを反復することができるようになります。 自動運転および運転者支援システムを構築する Intel 企業、Mobileye の […]

今日は、数百から数千ギガバイトにおよぶデータセットでのモデルのトレーニングを容易にする、新しいデータ並列化ライブラリの Amazon SageMaker によるサポートが開始されたことをお知らせしたいと思います。 データセットとモデルがますます大きくなり、高度化するにつれて、大規模な分散型トレーニングジョブを扱う機械学習 (ML) プラクティショナーは、Amazon Elastic Compute Cloud (EC2) p3 および p4 インスタンスなどの強力なインスタンスを使用している場合でさえも、長くなる一方のトレーニング時間に対応しなければなりません。たとえば、8 個の NVIDIA V100 GPU を搭載した ml.p3dn.24xlarge インスタンスを使用しても、一般公開されている COCO データセットでの Mask RCNN および Faster RCNN などの高度なオブジェクト検出モデルのトレーニングには 6 時間以上かかります。これと同じく、最先端の自然言語処理モデルである BERT のトレーニングにも、同一のインスタンスで 100 時間以上かかります。自律走行車企業などのお客様には、大規模な GPU クラスターで何日もかけて実行される、さらに大きなトレーニングジョブを定期的に処理するお客様もおられます。 ご想像どおり、これらの長いトレーニング時間は ML プロジェクトの深刻なボトルネックであり、生産性を損なうと共に、イノベーションを遅らせています。お客様から助けを求められた AWS は、この問題の解決に乗り出しました。 Amazon SageMaker のデータ並列化のご紹介 SageMaker Data Parallelism (SDP) ライブラリのおかげで、Amazon SageMaker を使って ML チームによる分散型トレーニングの時間とコストの削減を実現することが可能になりました。TensorFlow […]

今日は、お客様が機械学習 (ML) モデルのバイアスを検出し、ステークホルダーと顧客にモデルの動作を説明できるようにすることで透明性を高めるために役立つ Amazon SageMaker の新機能、Amazon SageMaker Clarify をご紹介します。 ML モデルは、データセットに存在する統計的パターンを学習するトレーニングアルゴリズムによって構築されるため、いつくかの疑問がすぐさま思い浮かびます。第一に、ML モデルが特定の予測にたどり着いた理由を説明できるようになるのか? 第二に、モデル化しようとしている現実問題をデータセットが忠実に表現しない場合はどうなるのか? そもそも、このような問題を検出することはできるのか? これらの問題は、認識できない形で何らかのバイアスを生じないのか? これから説明するとおり、これらは決して推論的な疑問ではなく、極めて現実的なもので、その影響は広範囲に及ぶ可能性があります。 バイアス問題から始めましょう。不正なクレジットカード決済を検出するモデルに取り組んでいることを想像してください。幸いにも、決済の大部分は正当なものであり、データセットの 99.9% を占めています。これは、不正決済が 0.1% のみであることを意味し、100,000 件のうち 100 件といったところです。二値分類モデル (正当な決済 vs. 不正な決済) のトレーニングでは、モデルが多数派グループに強い影響を受ける、つまりバイアスがかかる可能性が非常に高くなります。実際に、トリビアルモデルでは決済が常に正当であると判断されてしまうかもしれません。このモデルはまったく役に立たないものの、99.9% は正しいことになります! このシンプルな例から、データの統計的特性、そしてモデルの精度を測定するために使用するメトリクスをどれほど慎重に扱わなければならないかがわかります。 この過少出現問題には多数の派生タイプがあります。クラス、特徴、およびユニークな特徴量が増加しても、データセットには特定のグループについて少量のトレーニングインスタンスしか含まれていない可能性があります。実際、これらのグループの一部は、性別、年齢範囲、または国籍など、さまざまな社会的にセンシティブな特徴に該当することがあります。このようなグループの過少出現は、予測結果に不均衡な影響をもたらす恐れがあります。 残念ながら、悪意がまったくなかったとしても、データベースにバイアス問題が存在し、ビジネス、倫理、および規制面での影響を伴うモデルに取り込まれてしまう可能性があります。このため、モデル管理者が本番環境システムにおけるバイアスの潜在的な原因に注意することが重要になるのです。 では、説明可能性の問題についてお話しましょう。線形回帰や決定木ベースのアルゴリズムといったシンプルで十分に解明されているアルゴリズムでは、モデルを検証し、モデルがトレーニング中に学習したパラメータを調べ、モデルが主に使用する特徴を特定することは比較的簡単です。その後、このプロセスがビジネス慣行に沿っているかどうかを判断できます (つまり、「人間のエキスパートでもこうしただろう」と言うようなものです)。 しかし、モデルがますます複雑になるにつれて (深層学習さん、あなたのことです)、このような分析は不可能になります。スタンリー・キューブリックの「2001 年宇宙の旅」に出てくる先史時代の部族と同じように、私たちはしばしば、不可解なモノリスをまじまじと見詰めながら、それが何を意味するのか頭をかしげるしかありません。多くの企業と組織は、MＬ モデルを本番環境で使用する前に、それらを説明可能なものにする必要があるかもしれません。さらに、一部の規制では、ML モデルが重大な意思決定の一環として使用される場合に説明可能性が義務付けられている場合があり、この説明可能性は、最初にお話したバイアスの検出にも役立ちます。 こうして、データセットとモデルに存在するバイアスを検出し、モデルが予測を行う方法を理解するための援助をお客様から求められた AWS は、作業を開始し、SageMaker Clarify を考案しました。 Amazon SageMaker Clarify のご紹介 SageMaker Clarify は、AWS の完全マネージド型 ML サービスである Amazon […]

本日、 Amazon SageMaker Pipelines を発表することができまして、大変うれしく思います。これは Amazon SageMaker の新機能で、データサイエンティストやエンジニアが、エンドツーエンドの機械学習パイプラインを簡単に構築、自動化、スケールできるようになります。 機械学習 (ML) はもともと試験段階にあり、本質的に予測することはできません。数日から数週間かけてさまざまな方法でデータを分析および処理します。これは、ジオード (晶洞石) を壊して、貴重な宝石を見つけようとする作業のようです。次に、さまざまなアルゴリズムとパラメータを試しながら、最高の精度を求めて多くのモデルをトレーニングおよび最適化します。この作業は通常、アルゴリズムとパラメータの間に依存関係がある多くの異なる手順を伴い、手作業で管理するため、とても複雑になる可能性があります。特に、モデル系列の追跡は簡単ではなく、監査性やガバナンスを妨げます。最後に、上位モデルをデプロイし、参照テストセットに対するモデルの評価を行います。最後に、 と言いましたが、実際には何度も反復して、新しいアイデアを試し、新しいデータでモデルを定期的に再トレーニングします。 ML がどんなにエキサイティングであっても、残念ながら多くの繰り返し作業を伴います。小規模なプロジェクトでも、本番環境に移る前には何百もの手順が必要になります。こうした作業のせいで、時間の経過とともにプロジェクトの楽しさや興奮が失われていくだけでなく、監視する必要性やヒューマンエラーの可能性が大きくなります。 手作業を軽減し、トレーサビリティを向上させるために、多くの ML チームでは DevOps の理念を採用し、継続的インテグレーションと継続的配信 (CI/CD) 用のツールとプロセスを実装しています。確かにこれは正しい手順といえますが、独自のツールを作成することで、当初の予想よりも多くのソフトウェアエンジニアリングとインフラストラクチャ作業が必要な複雑なプロジェクトとなる場合が多いです。貴重な時間とリソースが実際の ML プロジェクトから奪われ、革新のペースがスローダウンします。残念ながら一部のチームでは、手作業でのモデルの管理、承認、デプロイに戻ることにしました。 Amazon SageMaker Pipelines のご紹介 簡単に言うと、Amazon SageMaker Pipelines で、ML プロジェクトの DevOps がトップレベルになります。この新機能により、データサイエンティストや ML デベロッパーは、自動化された、信頼性の高いエンドツーエンドの ML パイプラインを簡単に作成できるようになります。SageMaker は通常どおり、すべてのインフラストラクチャを完全に管理するため、お客様が作業を行う必要はありません。 Care.com は、高品質の介護サービスを見つけて管理するための世界をリードするプラットフォームです。Care.com のデータサイエンスマネージャーの Clemens Tummeltshammer 氏は次のように言います「 需要と供給が均衡な、力のある介護業界は、個々の家庭から国の GDP にいたる経済成長にとって不可欠です。私たちは Amazon SageMaker Feature Store と […]

Amazon Lookout for Metrics を発表いたします。これは、機械学習 (ML) を使用してメトリックスの異常を検出する新しいサービスです。ML の経験がなくても、ビジネスの健全性を積極的に監視、問題を診断して、迅速に機会を発見できます。 Lookout for Metrics では Amazon と同じ技術を使用しています。ともすれば見つけるのが難しい、データの例外的な変化を検出しつつ、誤検出の回数を減らします。また、類似するものをまとめてグループ化し、厳密にランク付けします。さらに異常の根本原因特定に役立つ情報を提供します。 収益額やウェブページビュー、毎日のアクティブユーザー数、解約率、トランザクション量、モバイルアプリのインストール数など、さまざまなメトリックスで使用できます。本日、Lookout for Metrics のプレビューをご覧いただけます。 Amazon Lookout を異常検知のために使用する理由 どの業界の組織も、テクノロジーと自動化を通じてビジネスの効率を向上させようとしています。さまざまな試みがされていますが、よくあるのは欠陥や機会を早期に特定でき、材料コストの節約、利益率の向上、カスタマーエクスペリエンスの向上につながるものです。これまでは、組織による大量のデータ監査は、手作業に依存していました。これでは規模を拡大することが難しく、また人為的ミスの原因になりがちです。任意に範囲を決めて、ルールベースの方法を使用している組織もあります。多くの場合これらの方法は静的であり、季節性の変化に容易には対応できず、誤検出が多すぎます。 ひとたび異常が検出されると、デベロッパーやアナリスト、ビジネスオーナーは、変化の根本原因をつきとめようと数週間も費やすことになります。これが ML が効果的かつ変革的なツールになり得る状況です。しかし ML のアルゴリズムは、データの種類ごとに慎重に選択し、トレーニングを行い、テストとデプロイをする必要があります。そのため ML に熟練したエキスパートチームが必要です。 Amazonには、データ主導型の企業としての長い歴史があります。ビジネスの健全性や運営、カスタマーエクスペリエンスにおいてトップでありつづけなければならないビジネスを抱えており、その数は増え続けています。この長年に渡る取り組みの重要な部分は、さまざまなトラフィックチャネルからのウェブサイト訪問、ショッピングカートに追加された商品の数、注文数、商品ごとの収益をはじめとした、主要業績評価指標 (KPI) の異常を検出するために ML テクノロジーを構築し、改善させることでした。 Amazon Lookout for Metrics によって、すべてのデベロッパーが Amazon で使われていたものと同じ ML テクノロジーを手にすることができます。データの異常を検出してインテリジェントにグループ化することで、集計結果を視覚化し、自動的に警告を行えます。 フルマネージド型のサービスなために ML プロセス全体を扱うことができ、すぐに開始してコアビジネスに集中できます。そして最も重要なのは、異常と根本原因の分析における正確さと関連性についてのフィードバックを、このサービスがリアルタイムに組み込むことで、モデルのパフォーマンスを継続的に向上させられることです。 Amazon Lookout for Metrics の仕組み AWS マネジメントコンソールから数回クリックするだけで、Lookout for Metrics […]