Amazon Web Services ブログ

サーバーレスアプリケーションから Amazon Aurora への IAM ロールベース認証

 ユーザー名とパスワードをアプリケーションに直接保存することはベストプラクティスではありません。セキュリティで保護されたアプリケーションでは、資格情報をプレーンテキストとして保存しないでください。ソリューションとして、AWS Identity and Access Management (IAM) ポリシーは、Amazon Aurora リソースを管理できるユーザーを決定するアクセス許可を割り当てることができます。たとえば、IAM を使用して、DB クラスター、タグリソース、またはセキュリティグループを作成、記述、変更、削除できるユーザーを決定できます。Amazon Aurora では、データベースユーザーを IAM ユーザーとロールに関連付けることができます。 この記事では、AWS Lambda 関数を使用して IAM を使用して Amazon Aurora データベースにアクセスする方法を説明します。 概要 IAM データベース認証を使用して、DB クラスターに接続できます。この方法を使用すると、パスワードを設定ファイルに保存する代わりに、生成された認証トークンでデータベースにアクセスできます。Amazon Aurora は、アプリケーションから接続を作成するために 15 分間有効な AWS Signature Version 4 認証トークンを生成します。認証は IAM によって外部で完全に管理されるため、データベースに認証情報を作成する必要はありません。 チュートリアル 次の図は、ワークフローを示しています。 Lambda は、サーバーのプロビジョニングまたは管理を行うことなく、コードを実行するコンピューティングサービスです。Lambda は、必要な場合にのみコードを実行し、1 日あたり数回のリクエストから毎秒数千ものリクエストにまで自動的にスケールします。Lambda を使用するときは、コードに対してのみ責任があります。Lambda は、メモリ、CPU、ネットワークや他のリソースのバランスを提供するコンピュートフリートを管理します。Lambda は Lambda 関数を実行し、結果を返します。 コンソールで Lambda 関数を作成する方法は次のとおりです。 [AWS Lambda […]

Read More

Amazon QuickSight のアクセスに Okta をフェデレーションする

Amazon QuickSight は、クラウドベースで高速なビジネスインテリジェンスサービスです。これにより、組織の誰もが容易に洞察を入手できるようになります。完全マネージド型サービスである Amazon QuickSight では、任意のデバイスからアクセスできる双方向性ダッシュボードを簡単に作成と公開が行え、アプリケーション、ポータル、ウェブサイトなどに埋め込むことができます。 Amazon QuickSight では、Standard と Enterprise の両方のエディションで、セキュリティアサーションマークアップランゲージ 2.0 (SAML 2.0) を使うアイデンティティフェデレーションをサポートしています。フェデレーションを使うと、エンタープライズアイデンティティプロバイダー (IdP) によりユーザーを管理でき、ログインしたユーザーを Amazon QuickSight へ移動させることが可能です。この IdP には、Microsoft Active Directory Federation Services、Ping One Federation Server、Okta などの種類があります。 今回の記事では、Amazon QuickSight のアクセスに Okta をフェデレーションする方法について手順を追って説明します。

Read More

Thinkbox DeadlineのAWS ポータルを使ったレンダリング

はじめに Dealdine 10の新しいAWS ポータル機能は、Autodesk MayaやAutodesk Arnoldを含む数多くのコンテンツ作成アプリケーションをサポートします。この機能により、Amazon EC2 Spot Instancesの分散コンピューティングパワーを使用して、Maya/Arnoldワークフローを最適化することができます。本記事では、AWS上でMaya/Arnoldを使ったレンダリングに必要な手順を説明します。 この手順は、AWS ポータルがサポートする他の製品の場合と非常によく似ているため、他のコンテンツ作成アプリケーションを使用する場合にも、本記事の内容のほとんどが有効です。

Read More

Amazon SageMaker で PyTorch を使用するグローバル最適化のためのディープニューラルネットベースの代理関数の構築

最適化とは、設計変数と呼ばれる入力に依存する関数の最小値 (または最大値) を求めるプロセスです。お客様 X には次のような問題があります。このお客様は、最大の燃料効率のために設計される新しい自動車モデルをリリースしようとしています。実際の場合、エンジン、トランスミッション、サスペンションなどに関連するチューニングパラメータを示す何千ものパラメータがあり、それらの組み合わせは様々な燃料効率値を生じます。 しかし、この記事では、特定の速度で走行する場合に燃焼される 1 時間あたりの燃料量 (ガロン単位) としてこの効率性を測定し、その他すべてのパラメータは変化しないと仮定します。従って、最小化される「関数」は「1 時間ごとに燃焼される燃料量 (ガロン単位)」になり、設計変数は「速度」になります。 この一次元最適化問題は、「1 時間ごとに燃焼される燃料量を最小限化するには、どの速度で車を走行させるべきか」という問題を提起します。これは、考慮される何千もの実際のパラメータを大幅に簡素化したものです。 目的関数 (f) が以下の合成関数のようになると仮定します。 f(x) = x⋅sin(x)+x⋅cos(2x) x および y 軸の単位を無視して、青矢印で示されているこの関数の最小値を探すのが今回のタスクになります。単一次元を扱っている場合でさえも、すべての速度値 (速度は実数) で車を走行させるのは非現実的です。 この記事では、実験を 30 回行う予算があるとします。各「実験」では、テスト装置上で車をその速度で走行させ、1 時間ごとに燃焼された燃料の平均値を測定し、収集します。こうすることで、速度の 30 の値に対応する燃焼された燃料の 30 の値だけが得られ、それ以外は得られません。また、最小値 (図の青矢印) で示されている速度の値で実施された実験が存在するという保証もありません。 各実験のセットアップには、実際に数時間かかる場合があります。このような実験を特定回数以上実施することは現実的ではないため、このタイプの関数は高コストなブラックボックス関数と呼ばれます。この関数が高コストなのは値を返すまでに時間がかかるためで、ブラックボックスと呼ばれるのは実施された実験を数式で記述できないからです。 最適化研究分野の全体が、これらのような問題を解決するアルゴリズムの作成を目的としています。この記事では、上記の関数 (f) を近似化するために、ニューラルネットワークを使用します。「代理モデル」としても知られる関数の訓練された近似化は、実際の実験の代わりに使用することができます! 訓練されたモデルが実際の関数の良好な近似化であるならば、任意の値の速度 (入力) に対して燃焼された燃料 (出力) を予測するためにこのモデルを使用できます。 技術的なアプローチ これらすべてのステップを詳しく説明するサンプルの Jupyter ノートブックについては、Build a Deep Neural Global Optimizer を参照してください。 […]

Read More

AWS Batch および Amazon SageMaker を使用したマルチリージョンサーバーレス分散型トレーニング

AWS でグローバル展開を築き、スケールにアクセスすることは、数多くのベストプラクティスの 1 つです。そのような規模とデータの効率的な利用 (パフォーマンスとコストの両方) を実現するアーキテクチャを作成することで、重要なアクセスが規模であることを確認できます。たとえば、自動運転車両 (AV) の開発では、データは運転キャンペーンにローカルで地理的に獲得されます。機械学習 (ML) から生成データと同じ AWS リージョンでの計算パイプライン実行することに至るまで、関連性があり、より効率的です。 さらに工夫するために、たとえば、組織が米国のサンフランシスコで運転キャンペーンの 4K ビデオデータを獲得したとします。並行して、あなたの同僚がドイツのスタっとガードの運転キャンペーンを取得したとします。両方のビデオキャンペーンにより、1 日当たり数テラバイトのデータを得ることができます。理想的には、そのデータをあなたの生成場所に近いリージョンに転送します。(この場合は、us-west-1とeu-central-1)です。ワークフローがこのデータにラベルを付けると、それぞれのリージョンにローカルの分散型トレーニングを実行することで、コストとパフォーマンスの観点から理に適う一方で、両方のデータセットをトレーニングするために使用されるハイパーパラメーターの一貫性が維持されます。 AWS の分散型トレーニングを開始するには、Amazon SageMaker を使用します。これは、分散型トレーニング (たとえば、Horovod で最適化された TensorFlow) で必要な差別化されないヘビーリフティングの大部分をプロビジョニングします。さらに、1 秒当たりの課金により、効率的なコスト管理をもたらします。これらの利点により、完全管理型のアーキテクチャにおけるモデル開発とデプロイに労力をかけなくても済むようになります。 Amazon SageMaker は管理型 ML サービスのエコシステムであり、地上検証によるラベリング、モデルトレーニング、ハイパーパラメーターの最適化、デプロイを支援します。これらのサービスは、Jupyter notebooks、AWS CLI、または Amazon SageMaker Python SDK を使用してアクセスできます。SDK では特に、ML ワークロードを初期化し、分散させるために少しのコード変更が必要です。 上記のアーキテクチャでは、S3 バケットはトレーニング入力ファイルのソースとしての役割を果たします。SageMaker Python SDK は、必要な計算リソースと Docker イメージをインスタンス化して、S3 からデータをソーシングするモデルトレーニングを実行します。出力モデルアーティファクトは、出力 S3 バケットに保存されます。 Amazon SageMaker Python SDK は、インフラストラクチャデプロイを抽象化し、完全に API […]

Read More

AIを使用してビデオアーカイブから価値を引き出す: Videofashionのケーススタディ

大規模なコンテンツアーカイブを保持するM&E企業にとって、プロデューサーやライセンサーの使用に合わせて適切にコンテンツを抽出することは、重要な課題です。さらに、数十年分のコンテンツを持つスポーツリーグなどの顧客は、コンテンツアーカイブをAPI経由でファンが使えるようにして、アーカイブ全体をエンドユーザーが検索し、API経由でライセンス可能にしたいと考えています。残念ながら、最近まで、コンテンツのメタデータの多くは複数の異なるシステム間で手入力されていたため、大規模なメディアライブラリの所有者がアーカイブの内容全体を完全に把握するには多くのリソースが必要となり、実用的ではありませんでした。

Read More

Amazon EBS を使って Microsoft SQL Server のパフォーマンスを最大化する

AWS のお客様は 10 年以上にわたり、SQL Server などのミッションクリティカルな Windows を実行しています。この投稿では、Amazon EBS ストレージを使用して SQL Server のパフォーマンスを最大化する方法について説明します。 永続ブロックストレージはリレーショナルデータベース管理システム (RDBMS) の重要なコンポーネントであり、重要なデータの速度、セキュリティ、耐久性の最終的な責任を担います。AWS は SQL Server のニーズに合わせて、EBS を通じて、高性能で使いやすいブロックストレージを提供しています。 この投稿は、SQL Server データベースアーキテクト、管理者、および開発者に関連した内容です。AWS プラットフォームでの最適なストレージ構成の概要を説明しています。現在 AWS を使用している、またはオンプレミスのワークロードをクラウドに移行しようとしているのであれば、EBS についてのより詳しい情報と基本的な理解を得ることができます。 Amazon EBS の概要 EBS はすべての AWS リージョンで利用可能な、高性能のブロックストレージサービスです。EBS を使用すると、わずか数回のクリックで SQL Server インスタンスにボリュームを作成し接続が可能です。ホストバスアダプター (HBA)、スイッチ、ネットワーク帯域幅、ディスクキャッシュ、コントローラー、ストレージエリアネットワークなどを構成する必要がなくなります。 EBS ボリュームは専用ストレージネットワークを使用してインスタンスに接続し、高速で信頼性の高いボリュームを柔軟にプロビジョニングするため、SQL Server の重要なワークロードにも対応できます。 EBS ボリュームは伸縮自在です。ワークロードを中断することなく、次のような変更を実行できます。 ボリュームサイズを最大 16 TiB まで増やす。 最大 64,000 IOPS までボリュームパフォーマンスを改善する。 SSD […]

Read More

Aurora PostgreSQL ストレージの I/O コストを削減

多くの企業における IT 部門では、オンプレミスのワークロードをクラウドに移行することの最大の理由の 1 つがコスト削減となっています。今回の記事では、コスト管理についての実例を、Amazon Aurora PostgreSQL のチューニングに着目しながらご紹介していきます。 ヒストリー 私は最近、当社の自動車向けテレマティクスアプリケーションの、AWS への実装作業を指揮するという機会に恵まれました。少し説明しますと、テレマティクスアプリケーションとは、データ提供者から運転データをストリーミングで受信するものです。このデータは、検証、修正、および正規化されます。そして、処理に合わせた変換が行われた後、専用のスコアリングアルゴリズムを用いて、ドライバーの点数付け計算に使われます。このプロジェクトには、次に示す主要な目的がありました。 高い可用性 (HA) の実現 (99.999%) 。 レスポンスタイプは、数ミリ秒台という高いパフォーマンスの実現。 現状の TCO をその何割かまでに削減する。これには、人的および設備的なリソースの削減も含まれます。 実際の使用量を反映した、従量課金制の支払に移行する。 国や地域を問わず、デプロイと新規顧客の受け入れを容易にする。 規模の拡大と需要変動に適応できる、スケーラビリティと伸縮性の獲得。 コストと HA での目標を達成するため、アプリケーションはサーバーレス/マネージド型のアーキテクチャを用いて、ゼロから再設計と再コーディングが行われました。これにより、保守に必要なリソースの最小化と従量課金制の利用がはかられましたこの再設計は、ほとんどの目的を達成し大きな成功となりましたが、コストだけに問題が残りました。オンプレミスに比べればコスト削減ができたものの、依然として想定した金額の 3 倍の金額になってしまったのです。 概要 他のどの変更作業と同様に、オンプレミスから AWS への移行要素には、次の 3 つが含まれます。 人材 処理 テクノロジー 個人的には、人材の要素がキーになると思います。オンプレミス環境とは違い、AWS でのインフラストラクチャーのコストは、いわゆる埋没費用ではありません。AWS での運用コストは、サービス利用量をベースに変化するからです。この利用量には、サービスの実行/経過時間だけでなく、メモリー、ストレージ、I/O といった、サービス毎に違いがうまれるものの利用も含まれます。AWS での課金手法になじむには、少し時間がかかることもあります。作業の工程の見直しやサービスの自動化は、AWS の環境が提供するメリットを活用するための重要なポイントです。 AWS を利用する上でのコスト削減の取り組みは、次のようなステップにグループ分けされます。 AWS のコストを理解する: まず始めに、請求管理ダッシュボードの使用になれることです。それぞれのサービスが、AWS のコストにどの程度影響しているかを理解します。タスクを優先付けするために、まず上位 3 つの高コスト要件に取り組みます。また最終的には、これらの検証がコスト面での重要性だけでなく、セキュリティーの抜け道を洗い出す目的にも重要となります。 ハウスキーピング: サーバーレスでマネージド型のサービスに移行するからといって、データのクリーニングやアプリケーションの保守のためにオンプレミスで行ったベストプラクティスが完全に不要になるわけではありません。むしろ、そういった作業はより厳格に行う必要が生まれます。 アプリケーションとサービスの低い機能を特定し調整します。 詳細情報 […]

Read More
Amazon Game Tech

【開催報告】Game Tech Night #15 ゲーム業界向け AWSで実現する機械学習

こんにちは、ゲームソリューションアーキテクトの 畑史彦 です。 8月21日に第15回となる Game Tech Night を開催致しました。 Game Tech Night は、オンラインゲーム開発と運用に携わる開発者やインフラエンジニアを対象に、ゲームに特化しか技術情報や関連する AWS サービスの情報をお届けすることを目的としたイベントです。最近では概ね 1,2 ヶ月に1度くらいの頻度で定期開催しています。この第15回では 機械学習 をテーマに AWS のソリューションアーキテクトから2つのセッションを実施しました。  

Read More

Amazon RDS for PostgreSQL バージョン 9.4.x のリタイアメントのお知らせ

本投稿は、こちらのフォーラムに投稿された Amazon RDS for PostgreSQL をご利用中のお客様向けのアナウンスメントの参考和訳です。 本投稿は、PostgreSQL コミュニティが2020年2月にバージョン9.4を廃止予定であることに従い、2020年1月15日をもって、Amazon RDS が RDS for PostgreSQL 9.4 のサポートを終了することをお知らせするものです。 Amazon RDSは2015年からPostgreSQLメジャーバージョン9.4をサポートしています。本リリース後、機能性、セキュリティ、信頼性、パフォーマンスの観点で大幅な改善がなされたメジャーバージョンが続々とリリースされています。PostgreSQLコミュニティは、PostgreSQL 9.4のリリース終了時期を2020年2月と発表しています。コミュニティサポートモデルに沿って、AWSは9.4.1, 9.4.4, 9.4.5, 9.4.7, 9.4.9, 9.4.10, 9.4.11, 9.4.12, 9.4.14, 9.4.15, 9.4.17, 9.4.18, 9.4.19, 9.4.20, 9.4.21, 9.4.23 のマイナーバージョンを含む、メジャーバージョン9.4のサポートを終了いたします。Amazon RDS では引き続き、バージョン9.5 以降の PostgreSQLデータベースをサポートいたします。 できるだけ早いタイミングで、Amazon RDS PostgreSQL 9.4 データベースインスタンスをバージョン9.6, 10 もしくは、バージョン11 にアップグレードすることを推奨します。9.5 へアップグレードすることも可能ですが、このバージョンは2021年2月にサポート終了が予定されています。 利用中の PostgreSQL 9.4 のマイナーバージョンと PostGIS 拡張の利用有無に応じて、バージョン10 もしくは、11 に直接アップグレードできる可能性があります(※訳者注: […]

Read More