Amazon Web Services ブログ

Localization Team

Author: Localization Team

新機能 – AWS Greengrass を使用したエッジでの機械学習推論

IoT、機械学習とエッジコンピューティングを組み合わせると何が起こるでしょうか。答をお教えする前に、それぞれを見直して、AWS が何を提供するかについてお話ししましょう。 モノのインターネット (IoT) – 物理的な世界とデジタルの世界を結びつけるデバイスです。ひとつ、または複数のタイプのセンサーが装備されていることがほとんどのこれらのデバイスは、工場、車両、鉱山、農地、家庭などその他いろいろな場所に設置されています。重要な AWS のサービスには、AWS IoT Core、AWS IoT Analytics、AWS IoT Device Management、および Amazon FreeRTOS に加え、AWS IoT ページに記載されているその他サービスが含まれます。 機械学習 (ML) – 大規模のデータセットと統計アルゴリズムを使用して訓練できるシステムで、新しいデータから推論を得るために使用されます。アマゾンでは、お買い物のときに表示される推薦を駆動させたり、フルフィルメントセンターのパスの最適化、ドローンの飛行などを行ったりするために機械学習を使用します。AWS は TensorFlow および MXNet といった優れたオープンソース機械学習フレームワークをサポートし、Amazon SageMaker を通じて ML をアクセスが簡単で、使いやすいものにしています。また、イメージとビデオ用に Amazon Rekognition、チャットボット用に Amazon Lex を提供し、テキスト分析、翻訳、音声認識、そして Text to Speech 用に幅広い言語サービスを提供しています。 エッジコンピューティング – 異なる場所にコンピューティングリソースと意思決定機能を備える力で、多くの場合、クラウドに対しては断続的な接続性しかないか、接続されていません。AWS Greengrass は AWS IoT を基礎としており、Lambda 関数を実行し、インターネットに接続されていないときでさえもデバイスを同期状態に保つ機能を提供します。 エッジにおける ML 推論 私は今日、これらの重要な新テクノロジーをすべてブレンダーに投げ込みたいと思います!AWS […]

Read More

AWS Certificate Managerでプライベート証明局を

本日から、AWS Certificate Manager (ACM) には新機能のプライベート認証局 (CA) が追加されました。この新サービスを使用した場合、ACM はプライベート下位 CA として機能することになります。従来、顧客がプライベート証明書を必要とする場合、顧客には、保守と運用に高額の費用が必要になる、特殊なインフラストラクチャとセキュリティに関する専門知識が必要でした。ACM の既存の証明書機能のアドオンとなる ACM プライベート CA を使用すると、従量制課金が適用されるプライベート証明書のライフサイクルを容易にかつ安全に管理することができるようになります。これにより開発者は、いくつかの API 呼び出しを行うだけで、証明書をプロビジョニングすることができます。一方、管理者は、粒度の細かい IAM ポリシーに基づいて、集中化管理コンソールからきめ細かいアクセス制御を行うことができます。ACM プライベート CA の鍵は、FIPS 140-2 レベル 3 セキュリティ基準に準拠した AWS マネージドハードウェアセキュリティモジュール (HSM) に安全に格納されます。ACM プライベート CA は、Amazon Simple Storage Service (S3) 内で証明書失効リスト (CRL) の自動的な維持管理を実施します。また、管理者に対しては、API またはコンソールを使用した証明書作成に関する監査レポートの発行を促します。このサービスには機能が満載されています。今すぐ、使用を開始し、CA をプロビジョニングしてください。 プライベート認証局 (CA) のプロビジョニング 最初にマイリージョンの ACM コンソールに移動して、サイドバーで新しい [Private CAs (プライベート CA)] セレクションを選択します。そこで、[Get Started (開始)] をクリックして、CA […]

Read More

シークレット情報の安全な格納、配布、および交換

当社は AWS Secrets Managerの提供を開始しました。これにより、API または AWS コマンドラインインターフェイス (CLI) を使用して、シークレットを格納および検索すること、ならびに内蔵またはカスタムの AWS Lambda 関数を使用して、資格証明を交代させることが容易になりました。1 つのマシン、1 つのアプリケーションで作業している場合、データベースの資格証明、パスワード、あるいは API 鍵など、アプリケーションのシークレットの管理は簡単です。多くの分散化したマイクロサービスにまで成長してスケーリングされると、シークレットを安全に、格納、配布、交換、使用する作業は、厄介な作業になります。以前は、顧客はシークレット管理専用の追加インフラストラクチャをプロビジョニングして維持管理する必要がありました。これにはコストがかかり、システムには不必要な複雑性が導入されました。 AWS シークレットマネージャー Twitter からの入力ツイートを受け取って、それらを Amazon Aurora データベースに格納するアプリケーションがあると仮定してください。以前は、データベース管理者からユーザー名とパスワードが求められるため、環境変数、本番へのレース、あるいはアプリケーション自体に、これらの資格証明を組み入れておく必要がありました。また、ソーシャルメディアマネージャーに、Twitter API 資格証明の作成と、それらの格納方法の説明を求める必要もありました。これは複数の人を関与させる、手間のかかるプロセスですが、資格証明を交換するたびに必要なプロセスでした。シークレットマネージャーが利用できるようになったので、データベース管理者は資格証明をシークレットマネージャーに一度入力しておけば、後はシークレットマネージャーのラムダ関数に、自動的に資格証明を更新したり交換したりするのを任せておくことができます。ソーシャルメディアマネージャーが Twitter の API 鍵をシークレットマネージャーに入力してくれれば、単純な API 呼び出しにアクセスしたり、プログラムで Twitter の API を呼び出すカスタムラムダ関数を使って、これらを交換したりすることができるようになりました。シークレットは自分のアカウントで選択する KMS 鍵に基づいて暗号化され、管理者は個々のロールまたはユーザーのための粒度の細かい IAM ポリシーに基づいてこれらのシークレットへの明示的にアクセス権を承認します。 AWS シークレットマネージャーのコンソールを使ってシークレットを格納する方法を説明します。最初に、[Store a new secret (新規シークレットの格納)] をクリックして、新規シークレットウィザードを表示します。RDS Aurora インスタンスの場合、インスタンスを選択して、初期のユーザー名およびパスワードを入力することにより、データベースに接続します。 次に、簡単な説明と名前を入力することによって、シークレットにアクセスします。ここでは任意の命名スキームを使用することができます。 次に、10 日ごとにパスワードを入れ替えるために、シークレットマネージャーに付属しているラムダ関数の交換機能を構成します。 最後に、すべての詳細情報をチェックして、シークレットの格納および検索のためのサンプルコードを完成します。 その結果、シークレットはコンソールで表示できるようになりました。 シークレットには、必要に応じて、API を呼び出すことでアクセスすることができます。 […]

Read More

AWS 構成ルールの更新: アカウントおよびリージョンにまたがる集約コンプライアンスデータ

既に述べたことがありますが、高度な AWS 顧客は複数の AWS アカウントを制御していることが常です。これらのうちのいくつかは、買収、またはボトムアップからの持ち越し、クラウドコンピューティングの部門採用の結果です。また人によっては、開発者、プロジェクト、部門で区別するために、複数のアカウントを作成することがあります。私たちは、これをアカウントのポリシーベース管理のためにベストプラクティスとして採用し、多くの AWS サービス、ならびに AWS Organizations のクロスアカウント機能で補強することを強く支持します。また、これらの顧客は AWS Config を十分に活用しており、Config Rules (自分で作成したもの、および Config から提供されたもの) を使用して AWS リソースのコンプライアンスをチェックします。 アカウントおよびリージョンにまたがる集約 現在私たちは、複数の AWS アカウントおよびリージョンにまたがるルールによって生成されたコンプライアンスデータを集約する機能を追加することによって、さらに役立つ Config Rules を作成することを可能にしました。集約データは、単一のダッシュボードに表示することができるので、ガバナンスとコンプライアンスを改善するための優れた手段になります。さらに良いことに、集約機能とダッシュボードは、AWS Config ユーザーであれば無料で利用することができます。 これのセットアップ方法を簡単に説明します。最初に、いくつかの用語を定義しておきます。 aggregator – これは新規の Config リソースです。これは集約対象となるコンプライアンスデータのソース (アカウントおよびリージョン) を特定します。複数の aggregator を同時に使用できるので、ガバナンスおよびコンプライアンスモデルをさらに細かくチューニングすることができます。 aggregator アカウント – これは 1つ以上の aggregator を所有する AWS アカウントです。 ソースアカウント – これは集約対象のコンプライアンスデータを持つ AWS アカウントです。 集約ビュー – […]

Read More

AWS ファイアウォールマネージャー – ウェブアプリケーションポートフォリオの集中管理

特に大規模な組織では、しばしば、分散制御と集中化制御との間で論争が起きます。分散制御モデルの場合、特殊化したローカルなニーズに対して、迅速に対応することができますが、集中化制御モデルの場合、すべてのチームが関与するグローバルなイニシアチブや課題に対して、適切なレベルの監視を行うことができます。 私たちは、AWS 顧客のアプリケーションの適用範囲が、多数の AWS リージョン、AWS アカウント、開発チーム、およびアプリケーションを含むようになったとき、この問題が発生することを見てきました。顧客は、AWS がリソースを最適の場所にデプロイしつつ、敏捷性および反応性を向上させているという事実に惚れています。しかし、この多様性とスケーリングは、セキュリティやコンプライアンスの観点からは、新しい課題を露呈します。自由なイノベーションは、重要なデータを保護し、脅威が出現したときに迅速に対応するというニーズとバランスが取れている必要があります。 ここ数年当社は、AWS WAF や AWS シールドなど、保護機能の広範囲にわたるセットを提供してきました。当社の顧客はこれらのオプションを最大限に活用してきましたが、一方で、単一の集中化した場所から管理する機能を求める声も多く聞かれました。 AWS ファイアウォールマネージャーの登場 AWS ファイアウォールマネージャーはまさにこのような顧客のために作られました。これは、組織のセキュリティの設定およびプロファイルの集中化制御を管理しつつ、顧客には、複数の AWS アカウントの使用して、必要ないかなるリージョンにおけるアプリケーションをもホストするという自由を与えることを実現します。開発者は開発が可能になり、革新者は革新が可能になる一方で、セキュリティイチームは、潜在的脅威および実際の攻撃に、迅速、統一的、かつグローバルに対応する能力を獲得します。 セキュリティチームは、ファイアウォールマネージャーを使用した場合、アカウントおよびアプリケーションすべてを対象とする自動ポリシー強制機能を通じて、新規および既存のアプリケーションが組織全体のセキュリティポリシーを遵守することを確信することができます。セキュリティチームは、対策が不十分なアプリケーションや AWS リソースを見つけた場合、数分以内にコンプライアンスを確立することができます。 ファイアウォールマネージャーは、WAF ルールセットおよびオプションの AWS シールドアドバンストプロテクションを含む名前付きポリシーを中心に構築されます。各ポリシーは、アカウント、リソースタイプ、リソース ID、またはタグによって指定される、特定の AWS リソースセットに適用されます。ポリシーは、マッチングしたすべてのリソースに自動的に適用されます。またはあなたが選択するそのサブセットに適用されます。ポリシーには、組織のポリシーから抽出した WAF ルール、ならびに、Imperva、F5、Trend Micro、その他 AWS マーケットプレースのベンダーなど、AWS パートナーによって作成された WAF ルールを含めることができます。これにより、セキュリティチームは、既存のオンプレミスセキュリティ環境をクラウド内で再現することができます。 ツアーを見る ファイアウォールマネージャーには次の 3 つの前提条件があります。 AWS Organizations – 組織はアカウントを管理するために AWS Organizationsを使用して、すべての機能を有効にしておく必要があります。詳細については、「組織の作成」を参照してください。 ファイアウォール管理者 – 組織内の AWS アカウントの 1 つをファイアウォールマネージャーの管理者として指名する必要があります。これによって、そのアカウントには、組織全体に AWS WAF […]

Read More

Apache MXNet Model Server が規模に応じたモデルサービングのために最適化されたコンテナイメージを追加

AWS は、本番ユースケースのためのモデルサービングのデプロイメントを効率化する Apache MXNet Model Server (MMS) v0.3 をリリースしました。このリリースには、GPU および CPU 上の深層学習ワークロード用に最適化された事前構築済みのコンテナイメージが含まれています。これによって、エンジニアはスケーラブルなサービングインフラストラクチャをセットアップできるようになります。Apache MXNet Model Server (MMS) と、規模に応じて深層学習モデルを提供する方法の詳細については、この先をお読みください! Apache MXNet Model Server (MMS) とは? MMS は、オープンソースのモデルサービングフレームワークで、規模に応じて深層学習モデルをデプロイするタスクをシンプル化するように設計されています。以下は MMS の主な利点の一部です。 MXNet と ONNX のニューラルネットワークモデルを単一のモデルアーカイブにパッケージ化するためのツール。これは、モデルを提供するために必要なアーティファクトのすべてをカプセル化します。 モデルアーカイブにパッケージ化されたカスタムコードを使用して推論実行パイプラインの各ステップをカスタマイズする機能。これは、初期化、前処理、および後処理の上書きを可能にします。 事前設定されたサービングスタック (REST API エンドポイントを含む) と推論エンジン。 スケーラブルなモデルサービングのために事前構築および最適化されたコンテナイメージ。 サービスとエンドポイントを監視するためのリアルタイムの運用メトリクス。 このブログ記事では、コンテナを使用して MMS を本番環境にデプロイする方法、クラスターを監視する方法、およびターゲットの需要に応じてスケールする方法を見て行きます。 コンテナでの MMS の実行 スケーラブルな本番用スタックのセットアップに進む前に、コンテナで MMS を実行する方法を確認しましょう。これを理解しておくことは、スケーラブルな本番クラスターのより複雑なセットアップについて考察するときに役立ちます。 この新リリースでは、事前構築され、最適化された MMS コンテナイメージが Docker Hub に発行されます。これらのイメージは、CPU ホスト […]

Read More

Amazon SageMaker が追加のインスタンスタイプ、ローカルモード、オープンソース化されたコンテナ、MXNet および Tensorflow アップデートをサポートするようになりました

Amazon SageMaker では、見直し改善が迅速に行われ、お客様のために新機能をリリースし続けています。本日を皮切りに、SageMaker は多くの新しいインスタンスタイプ、SDK を使ったローカルテスト、そして Apache MXNet 1.1.0 および Tensorflow 1.6.0 のサポートを追加します。これらのアップデートのそれぞれを簡単に見てみましょう。 新しいインスタンスタイプ Amazon SageMaker のお客様に、ノートブック、トレーニング、およびホスティングのワークロードの規模最適化のための追加オプションをご利用いただけるようになりました。ノートブックインスタンスは、t2.micro、t2.small、および m4.large インスタンスを除いたほとんどすべての T2、M4、P2、および P3 インスタンスタイプをサポートします。モデルトレーニングでは、m4.large、c4.large、および c5.large インスタンスを除いたほとんどすべての M4、M5、C4、C5、P2、および P3 インスタンスがサポートされるようになりました。最後に、モデルホスティングでは、m4.large インスタンスを除いたほとんどすべての T2、M4、M5、C4、C5、P2、および P3 インスタンスがサポートされます。お客様の多くは、最新の P3、C5、および M5 インスタンスを活用して、ワークロードのために最高の価格/パフォーマンスを得ることができます。また、使用頻度の低いエンドポイントまたはノートブック用に、T2 インスタンスのバースト可能なコンピューティングモデルを利用することも可能です。 オープンソース化されたコンテナ、ローカルモード、および TensorFlow 1.6.0 と MXNet 1.1.0 本日、Amazon SageMaker は SageMaker SDK で MXNet と Tensorflow のエスティメータを動作させる MXNet および Tensorflow ディープラーニングコンテナをオープンソース化しました。シンプルなインターフェイスに従う Python […]

Read More

Amazon Translate が一般提供されました

本日から Amazon Translateの一般提供が開始されました。昨年の AWS re:Invent で、私の同僚 Tara Walker が新しい AI サービスである Amazon Translate の プレビュー についての記事を書きました。今日から、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、および欧州 (アイルランド) で Amazon Translate にアクセスできるようになります。最初の 12 ヵ月間は毎月 200 万文字が無料利用枠対象となり、その後は 100 万文字ごとに 15 USD となります。一般提供では、ソース言語の自動推論、Amazon CloudWatch サポート、および単一の TranslateText 呼び出しで最大 5,000 文字など、数多くの新機能を利用できます。一般提供でのサービスを簡単に見てみましょう。 Amazon Translate の新機能 サービスの基本についてはすでに Tara の記事でまとめられているので、私は今日リリースされたサービスの新機能をいくつか取り上げたいと思います。では、コードサンプルから始めましょう。 import boto3 translate = boto3.client(“translate”) resp = translate.translate_text( Text=”????Je suis […]

Read More

Amazon Transcribe が一般提供されました

AWS re:Invent 2017 において、AWS はプライベートプレビューの Amazon Transcribe を発表しました。そして本日、AWS はすべての開発者に対する Amazon Transcribe の一般提供を発表します。Amazon Transcribe は、開発者が Speech to Text 機能をアプリケーションに追加することを容易にする自動音声認識サービス (ASR) です。AWS は、プレビューでのお客様のフィードバックを元に見直しを続け、Amazon Transcribe に多くの改善を行いました。 一般提供における Amazon Transcribe の新機能 まず、AWS では SampleRate パラメーターをオプションにしました。これは、メディアのタイプと入力言語のみを知っておけばよいことを意味します。そして、より明瞭なトランスクリプトを提供するために音声内の複数の話者を区別する機能 (「いつ誰が話したか」)、そして製品名、業界固有の用語、または個人名の音声認識の正確性を向上させるカスタムボキャブラリの 2 つの新機能も追加しました。Amazon Transcribe の仕組みを思い出せるように、簡単な例を見てみましょう。私の S3 バケットにあるこの音声を変換します。 import boto3 transcribe = boto3.client(“transcribe”) transcribe.start_transcription_job( TranscriptionJobName=”TranscribeDemo”, LanguageCode=”en-US”, MediaFormat=”mp3″, Media={“MediaFileUri”: “https://s3.amazonaws.com/randhunt-transcribe-demo-us-east-1/out.mp3”} ) これにより、個々の話者が識別されている、これに似た JSON が出力されます (ここではレスポンスのほとんどを取り除いています)。 { […]

Read More

Amazon ECS サービスディスカバリ

Amazon ECS でサービスディスカバリがサポートされました。これにより、ECS サービスが Amazon Route 53 の予測可能でフレンドリーな DNS 名で自動的に登録することができるようになります。負荷やコンテナの健全状態に対応してサービスがスケールアップまたはダウンすると、Route 53 のホストゾーンは最新の状態が保たれ、他のサービスが各サービスの状態に基づいてコネクションを行う必要がある場所を発見できるようになります。次のアドレスで、架空のソーシャルネットワークアプリでサービスディスカバリのデモを見ることができます。https://servicediscovery.ranman.com/. サービスディスカバリ マイクロサービスや最新のアーキテクチャへの移行の一部には、障害や変化する負荷に迅速に対応できるダイナミックで、オートスケーリングでき、そして堅牢であるサービスを持つことが必要とされます。皆さんのサービスはおそらく、依存したり利用されるサービスが複雑に関連した依存関係のグラフ構造を持っているでしょう。最新のアーキテクチャのベストプラクティスは、これらのサービスが独自に依存関係を指定できるようにして疎結合にすることですが、ダイナミックな環境では各サービスが自力で自身が接続する先を見つける必要があるため、複雑になってしまう場合があります。 consul、etcd、またはzookeeperなどのサービスディスカバリの従来のアプローチは、すべてこの問題をうまく解決しますが、追加のインフラストラクチャをプロビジョンして管理する必要や、コンテナやインスタンス上にエージェントをインストールする必要があります。これまでは、サービスが互いに発見して接続できるように、独自のサービスディスカバリーシステムを構成して実行するか、すべてのサービスをロードバランサに接続する必要がありました。これからは、ECS コンソール、AWS CLI、または ECS API を使用して、コンテナ化したサービスのサービスディスカバリが可能になります。 Amazon Route 53 サービスレジストリとAuto Naming API の紹介 Amazon ECS サービスディスカバリは、Amazon Route 53 サービスレジストリと Auto Naming API とコミュニケーションすることにより動作します。このブログではこれまでそれらについて触れていないため、ここでは簡単にこれらの Route 53 API の動作について概説したいと思います。最初に、一部の用語について説明します。 名前空間 – 名前空間は、トラフィックを流すドメイン名を指定します (例: internal、local、corp)。これは、サービスが互いに発見できる論理的境界と考えることができます。名前空間は、 aws servicediscovery create-private-dns-namespace コマンドの呼び出しまたはECS コンソールで作成することができます。名前空間は、Route 53 のホストゾーンとほぼ同じです。名前空間にはサービスが含まれます。これは次に取り上げる用語です。 サービス – サービスは「auth」、「timeline」、「worker」などの名前空間にある特定のアプリケーションまたはアプリケーションのセットです。サービスはサービスインスタンスを含みます。 […]

Read More