Amazon Web Services ブログ

毎月数件のリクエストから毎秒何千万ものリクエストに簡単にスケールできる、完全マネージド型の key-value データベースとドキュメントデータベースを　AWS のお客様に提供する Amazon DynamoDB には、いつも感銘を受けてきました。 DynamoDB チームは最近、オンデマンドキャパシティからネイティブな ACID トランザクションのサポートまで、数多くの素晴らしい機能をリリースしました。こちらは、グローバルテーブル、ポイントインタイムリカバリ、およびインスタントアダプティブキャパシティなど、最近の DynamoDB 発表の内容がよくわかる概要です。DynamoDB は、保管時のお客様データをすべてデフォルトで暗号化するようになりました。 しかし、リレーショナルデータベースから NoSQL への発想の切り替えはそれほど簡単なことではありません。昨年の re:Invent では、DynamoDB の仕組みと、それをどのように皆さんのユースケースに使用できるかに関する 2 つの素晴らしい講演が行われました。 Amazon DynamoDB Under the Hood: How We Built a Hyper-Scale Database (講演者: Jaso Sorenson) Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (講演者: Rick Houlihan) DynamoDB をさらに役立てていただくため、AWS は本日、プレビュー版の NoSQL Workbench for Amazon […]

 お客様は、AWS 内で使用するサービスの可視性と制御の向上を引き続き求めています。データベースサービスに関しては、お客様からは通常、特定のデータベース内でのクエリの最適化と処理に関する洞察を求めるリクエストを中心に受けています。データベースの開発者と管理者は、ほとんどの場合、データベースクエリ実行プランのアイデアと使用法をすでによく知っています。お客様の議論に動機付けられて、Amazon Neptune に SPARQL クエリの explain 機能が追加されました。 Amazon Neptune は、高度に連結されたデータの保存とクエリのために最適化された、高速で信頼性に優れた完全マネージド型のグラフデータベースで、データ内の接続のナビゲートと活用に依存するオンラインアプリケーションに最適です。 Amazon Neptune は、SPARQL クエリ言語を使用してクエリできる W3C Resource Description Framework (RDF) グラフをサポートしています。また、Gremlin グラフトラバーサルおよびクエリ言語を使用してクエリできる Apache TinkerPop プロパティグラフもサポートしています。 このブログ記事では、新しい SPARQL explain 機能とその使用方法について詳しく説明します。また、この記事の最後に、今日 SPARQL explain を試してみたい人のために、ワークロードと設定の例を示しました。 explain を使用した SPARQL クエリのランタイム動作の理解 SPARQL クエリが Neptune クラスターに送信されると、データベースエンジンはクエリを SPARQL クエリオプティマイザーに転送します。これにより、利用可能な統計とヒューリスティックに基づいてクエリプランが生成されます。オプティマイザーは、個々のトリプルパターンと接続演算子によってクエリを分割し、最適な実行を提供するために自動的に並べ替えます。このタイプの最適化により、クエリ開発者はクエリを評価する最適な順序を考慮する必要がなくなります。 場合によっては、オプティマイザーが選択したトリプルパターン (より一般的には実行プラン) の評価順序についてより多くの洞察を得たい場合があります。ここで、新しい SPARQL explain 機能の出番です。生成された評価プランを検査して、実行順序を理解できるためです。 クエリ explain 出力は、追加パラメータ「explain=<MODE>」を HTTP リクエストに追加するだけで取得できます。 次の curl […]

 ユーザー名とパスワードをアプリケーションに直接保存することはベストプラクティスではありません。セキュリティで保護されたアプリケーションでは、資格情報をプレーンテキストとして保存しないでください。ソリューションとして、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 […]

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 をフェデレーションする方法について手順を追って説明します。

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

最適化とは、設計変数と呼ばれる入力に依存する関数の最小値 (または最大値) を求めるプロセスです。お客様 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 を参照してください。 […]

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 […]

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

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 […]

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