Amazon Web Services ブログ

Kubernetes 上にある機械学習ワークロードでのハイパフォーマンスストレージの使用

コンテナやマイクロサービスベースのアーキテクチャを導入してのアプリケーションの最新化が、現在、各組織で行われています。多くのお客様は、マイクロサービスアーキテクチャを機能させるために、パフォーマンスの高いワークロードをコンテナ内でデプロして、これらのコンテナーから低レイテンシで高スループットの共有ストレージにアクセスする必要があります。これは、コンテナは一時的なもので、長期にわたりアプリケーションを実行するには、データを耐久性のあるストレージに保存する必要があるからです。Amazon FSx for Lustre (FSx for Lustre) は、世界中で最も使用されているハイパフォーマンスファイルシステムを提供し、現在は完全マネージド型で Amazon S3 と統合されています。このサービスでは、Kubernetes ワークロード用にパフォーマンスのピークを確保ながら高い耐久性のあるストレージを実現する、POSIX 互換の高速並列ファイルシステムをご利用いただけます。FSx for Lustre では、Lustre ファイルシステムの設定や管理に関する従来の複雑さを取り除くことで、パフォーマンスの高いファイルシステムを数分で使用開始できるようになりました。FSx for Lustre のレイテンシーはミリ秒単位以下であり、スループットは最大数百 GB/秒、IOPS は数百万を実現しています。機械学習やハイパフォーマンスコンピューティング (HPC)、画像処理、そして金融モデリングなど、速度が重要視されるワークロードを実行するお客様が、この FSx for Lustre を使用されています。 Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するための、オープンソースなコンテナ用オーケストレーションシステムです。AWS のマネージド型サービスである Amazon Elastic Kubernetes Service (Amazon EKS) を使用することで、Kubernetes のコントロールプレーンやワーカーノードを独自にインストールしたり、操作する必要がなくなり、容易に Kubernetes を実行できるようになります。Amazon EKS では、複数のアベイラビリティゾーン間で Kubernetes のコントロールプレーンインスタンスを実行することで、高可用性を実現しています。障害のあるコントロールプレーンインスタンスは、Amazon EKS により自動的に検出および置き換えが行われ、またそれらに対する、バージョンのアップグレードやパッチ修正も自動で実施されます。 今回の記事では、GitHub のチュートリアルとして、Amazon EKS クラスターでの FSx for Lustre 永続的ファイルシステムのプロビジョニング方法と、FSx for […]

Read More

Porting Assistant for .NET を発表

.NET Core は .NET の未来です! .NET Framework のバージョン 4.8 はリリースされる最後のメジャーバージョンであり、今後リリースされるのは、バグ、信頼性、およびセキュリティ関連の修正のみであると Microsoft は述べています。.NET プラットフォームへの将来の投資と革新による恩恵を引き続き受けたいアプリケーションについては、アプリケーションを .NET Core に移植することを検討する必要があります。また、Linux とオープンソースの革新から得られるメリット、アプリケーションのスケーリングとパフォーマンスの向上、ライセンス費用の削減など、アプリケーションを .NET Core に移植することを検討する理由は他にもあります。しかしながら、移植にはかなりの人による作業を必要とすることがあり、その中には、プロジェクトの依存関係への参照を更新するなどの付加価値を生まない作業も含まれています。 .NET Framework アプリケーションを移植する場合、デベロッパーは、互換性のある NuGet パッケージを検索し、アプリケーションのプロジェクトファイルでそれらのパッケージ参照を更新する必要があります。これらのパッケージ参照は、.NET Core プロジェクトファイル形式にも更新する必要があります。さらに、.NET Core には .NET Framework で使用可能な API のサブセットが含まれているため、代替の API を見つける必要があります。移植が進むにつれて、デベロッパーは、コンパイルエラーと警告の長いリストを調べて、タスクを一つひとつ処理する上で、対応するのが最適であると思われる領域や、最優先で対応すべき領域を特定する必要があります。言うまでもなく、この作業は大変なもので、手間が増えることにより、アプリケーションのポートフォリオが大きいお客様の活動を妨げることがあります。 本日、当社は、Porting Assistant for .NET を発表しました。これは、お客様が .NET Framework アプリケーションを分析して Linux で実行されている .NET Core に移植するのに役立つ新しいツールです。Porting Assistant for .NET は、アプリケーションのソースコードとパブリック API と […]

Read More

Cisco は、ハイブリッド機械学習ワークフローを作成するために Amazon SageMaker と Kubeflow を使用

この記事は、Cisco の AI/ML ベストプラクティスチームのメンバーによるゲスト投稿です。そのメンバーには、テクニカルプロダクトマネージャーの Elvira Dzhuraeva 氏、上級エンジニアの Debo Dutta 氏、プリンシパルエンジニアの Amit Saha 氏が含まれます。 Cisco は、多くのビジネスユニットに機械学習 (ML) と人工知能 (AI) を適用する大企業です。CTO オフィスにある Cisco AI チームは、AI と ML を使用するビジネスユニット全体の会社のオープンソース (OSS) AI/ML ベストプラクティスを担当しています。また、Kubeflow オープンソースプロジェクトと MLPerf/MLCommons の主要な貢献者でもあります。チームの使命は、Cisco のビジネスユニットとお客様の両方が使用できるアーティファクトとベストプラクティスを ML で作成することです。このソリューションはリファレンスアーキテクチャとして共有しています。 ローカライズされたデータ要件などのビジネスニーズに応えて、Cisco はハイブリッドクラウド環境を運用しています。モデルトレーニングは独自の Cisco UCS ハードウェアで行われますが、多くのチームはクラウドを活用して推論を行い、スケーラビリティ、地理的冗長性、復元力を活かしています。けれども、ハイブリッド統合では一貫した AI/ML ワークフローを構築してサポートするために深い専門知識と理解が必要になることが多いため、このような実装はお客様にとって困難な場合があります。 これに対処するために、Amazon SageMaker を使ってクラウド内のモデルにサービスを提供するハイブリッドクラウドを実装するために、Cisco Kubeflow スターターパックを使用する ML パイプラインを構築しました。このリファレンスアーキテクチャを提供することで、お客様が複雑なインフラストラクチャ全体でシームレスで一貫性のある ML ワークロードを構築して、直面する可能性のあるあらゆる制限を満たすことを支援することを目指しています。 Kubeflow は、Kubernetes 上の ML […]

Read More

Amazon DocumentDB (MongoDB 互換) を使用してコストを最適化する

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする、高速かつスケーラブルで可用性に優れた完全マネージドのドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在の MongoDB 3.6 用のプリケーションコード、ドライバー、ツールをそのまま使用して、Amazon DocumentDB 上でのワークロードの実行、管理、そしてスケーリングが行えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 AWS は、可用性、信頼性、耐久性、スケーラビリティ、バックアップなどに関するお客様の課題を独自の方法を用いて解決するために Amazon DocumentDB を構築しました。その過程において、当社は、付加価値を生まない手間のかかる作業を取り除き、コストを削減するために、いくつかの斬新でユニークな機能を構築しました。この記事では、コストの見積もり、最適化、モニタリングを可能にする Amazon DocumentDB 機能を紹介します。 T3 ミディアムインスタンス T3 ミディアムインスタンス (4 GiB RAM、2 vCPU) のリリースにより、r5.large インスタンス (16 GiB RAM、2 vCPU) 以前のエントリポイントより 72% 安い低コストのインスタンスタイプ (1 時間あたり 0.078 USD) が得られます (料金はリージョンごとに異なります。Amazon DocumentDB の料金をご覧ください)。 T3 インスタンスは、開始、開発とテスト、および小規模の本番ワークロードに最適です。T3 ミディアムインスタンスで新しいクラスターをプロビジョニングするか、既存のクラスターのインスタンスを T3 ミディアムインスタンスにスケーリングできます。詳細については、Amazon DocumentDB インスタンスの変更を参照してください。 […]

Read More

Amazon RDS Proxy を使用したアプリケーションの可用性の向上

Amazon RDS Proxy の利点の 1 つは、データベースのフェイルオーバー後のアプリケーションにかかる復旧時間を改善できることです。RDS Proxy は MySQL と PostgreSQL エンジンの両方をサポートしていますが、この記事では、MySQL テストワークロードを使用して、RDS Proxy がフェイルオーバー後のクライアントリカバリ時間を Amazon Aurora MySQL で最大 79%、Amazon RDS for MySQL で最大 32% 削減する方法を示します。この記事では、RDS Proxy がクライアントをリーダー/ライターの移行問題から隔離し、次善のクライアント設定を克服する方法についても説明しています。アクティブ接続監視による計画的フェイルオーバーと計画外フェイルオーバー、およびフェイルオーバーを通じてアイドル接続を維持することによるクライアント接続プールの RDS Proxy の利点について説明します。最後に、この記事では、おすすめのクライアント構成をいくつか紹介します。 背景 RDS Proxy は、Amazon RDS for MySQL/PostgreSQL および Aurora MySQL/PostgreSQL データベースに向かって進むことができます。これにより、データベースへのアプリケーションへのアクセスを管理でき、接続プーリング、多重化、適切なフェイルオーバーを提供します。データベース接続の制限を超えてスケーリングし、接続のバーストとアプリケーションからのリクエストを管理できます。この記事では、RDS Proxy フェイルオーバーのメリットに焦点を当てています。 フェイルオーバーは、プライマリデータベースインスタンスにアクセスできなくなり、別のインスタンスが新しいプライマリとして引き継がれるときに発生します。これにより、クライアント接続が中断されます。ローリングアップグレードなどの管理アクションによって引き起こされた場合は計画的フェイルオーバー、障害が原因で発生した場合は計画外フェイルオーバーになります。どちらの場合も、クライアントの中断を最小限に抑えるためにダウンタイムを取り除くする必要があります。 Amazon RDS には複数の高可用性オプションがあり、RDS Proxy は各オプションにフェイルオーバー復旧の利点を提供します。Amazon RDS マルチ AZ オプションは、同期レプリケーションを備えたプライマリ構成およびスタンバイ構成です。Aurora は、最大 […]

Read More

AWS Machine Learning Research Awards 2019 年第 4 四半期のウィナー

AWS Machine Learning Research Awards (MLRA) は、機械学習 (ML) の進化を目指し、革新的な研究やオープンソースプロジェクトへの資金提供、学生へのトレーニング、研究者への最新技術の提供を行っています。2017 年以来 MLRA では、13 か国に広がる 73 の学校および研究機関における、180 を超える研究プロジェクトをサポートしてきました。そのトピックは、ML アルゴリズム、コンピュータビジョン、自然言語処理、医学研究、ニューロサイエンス、社会科学、物理学、ロボット工学に及びます。 2020 年 2 月 18 日に、MLRA 2019 年第 2、3 四半期提案募集サイクルのウィナーを発表しました。本日は、MLRA 2019 年第 4 四半期提案募集サイクルのウィナー 28 名を発表します。今回の MLRA ウィナーは、6 か国、26 機関の代表者たちです。ML コミュニティに広く寄与するオープンツールソースや研究の開発、または AWS ML ソリューション (Amazon SageMaker、AWS AI サービス、Apache MXNet on AWS など) を使ったインパクトのある研究の開発を目指したプロジェクトが資金を獲得しました。それでは、2019 年第 4 四半期のウィナーをご紹介します。 ウィナー 機関 […]

Read More

AWS App2Container – Java および ASP.NET アプリケーション用の新しいコンテナ化ツール

お客様は、コンテナとサーバーレステクノロジーを使用して新しいアプリケーションを開発することが多くなり、ソフトウェアデリバリーライフサイクルを自動化するために最新の継続的インテグレーションおよび継続的デリバリー (CI/CD) ツールを使用しています。また、手動で、または従来のシステムを使用して、構築および管理される多数の既存のアプリケーションを維持しています。異なるツールを使用してこれら 2 つのアプリケーションのセットを維持することで、運用上のオーバーヘッドが増加し、新しいビジネス機能の提供ペースが低下します。お客様は、既存のアプリケーションと新しいアプリケーションの両方について、管理ツールと CI/CD プロセスを可能な限り標準化できるようにしたいと考えています。その目的を達成するための最初のステップとして、既存のアプリケーションをコンテナにパッケージ化するオプションに目を向けています。 しかし、既存のアプリケーションをコンテナ化するには、アプリケーションの依存関係の識別、dockerfiles の書き込み、各アプリケーションのビルドプロセスとデプロイメントプロセスの設定など、手動による多くの作業を必要とします。これらの手動による作業は時間がかかり、エラーが発生しやすく、最新化に向けた取り組みの速度を低下させる可能性があります。 本日、当社は AWS App2Container をリリースします。これは、コードを変更することなく、オンプレミス、Amazon Elastic Compute Cloud (EC2)、または他のクラウドで実行されている既存のアプリケーションをコンテナ化するのに役立つ新しいコマンドラインツールです。App2Container は、サーバーで実行されているアプリケーションを検出し、それらの依存関係を識別して、Amazon ECS および Amazon EKS へのシームレスなデプロイのために、関連するアーティファクトを生成します。また、AWS CodeBuild および AWS CodeDeploy との統合を提供して、コンテナ化されたアプリケーションを繰り返し構築およびデプロイすることを可能にします。 AWS App2Container は、アプリケーションコンポーネントごとに、アプリケーションファイル/フォルダー、Dockerfiles、Amazon Elastic Container Registry (ECR) のコンテナイメージ、ECS タスク定義、Kubernetes デプロイ YAML、Amazon ECS または EKS にアプリケーションをデプロイする CloudFormation テンプレート、および AWS CodeBuild と CodeDeploy を活用する AWS Codepipeline でビルド/リリースパイプラインを設定するためのテンプレートといったアーティファクトを生成します。 本日より、App2Container を使用して、Windows […]

Read More

委任された管理者からAWS Configルールと適合パックをデプロイする

AWS Configルールの使用により、リソースの構成をベストプラクティスに照らし合せて評価し、決められた構成ポリシーに従っていない場合は修正することができます。 AWS Config適合パックを使用すると、AWS Organizations全体に適用されるAWS Configルールと修復アクションのセットを単一のパックで作成できます。これにより、Configルールの集中管理と展開が可能になります。 今までは、組織全体にまたがる適合パックとConfigルールの展開は、組織のマスターアカウントのみが実施できました。しかし、マスターアカウントを一括請求にのみ使用するお客様も多数おられます。お客様がセキュリティ、監査、コンプライアンスのための専用アカウントを持っている場合、代わりにその専用アカウントを使って組織全体にわたるConfigの展開を管理したいと考えるでしょう。このようなご要望にお応えして、AWS Organizationsの非マスターアカウントからConfigルールと適合パックのデプロイができるようになりました。このAWS Config新機能を使用すると、これらのConfigリソースをAWS Organizations全体に展開し管理できる権限を委任する管理者アカウントを登録できます。 このブログ投稿では、委任された管理者アカウントにて、組織全体に適合パックを展開し、AWS Configルールと適合パックを管理する方法について示します。

Read More

CloudFormation で cfn-init に代えて State Manager を利用する方法とその利点

はじめに AWS CloudFormationを介してAmazon Elastic Cloud Compute (EC2) インスタンスをデプロイした後には、ソフトウェアのインストール、またはオペレーティングシステムの設定が必要になることがほとんどです。多くのAWSのお客様はCloudFormationのヘルパースクリプトの一つである cfn-init (2012年2月から利用可能)を使用していると思います。しかし、それ以後もAWSは、お客様のフィードバックに応じて多くの新機能とサービスをリリースしてきました。そのうちの一つはAWS Systems Managerです。このブログ記事では、AWS CloudFormationを介してデプロイされたAmazon EC2インスタンスに対して、AWS Systems Manager State Managerを使用してインスタンスを設定する、よりシンプルで堅牢な方法を紹介します。

Read More

AWS IoT Device Management セキュアトンネリングを利用して、SSHやリモートデスクトップでトラブルシューティングを行う方法

IoT のユースケースでは、デバイスで不具合や問題が起きた際にログを収集することができないため問題の切り分けが難しい、デバイスが遠隔地にありトラブルシューティングに時間やコストがかかる、といった声をよく耳にします。AWS IoT Device Management ではセキュアトンネリングという機能を提供しており、デバイスの属するネットワークの既存のインバウンドファイアウォールルールを更新することなく、遠隔地のデバイスに対してSSHやリモートデスクトップなどでログインし、状態の確認やログの収集などのトラブルシューティングを行ったり、製品のオーナーに対してリモートからの設定サポートを実施したりすることができます。 この記事では、AWS IoT Core で管理されているデバイスに対して、AWS IoT Device Management のセキュアトンネリングを利用して遠隔からトラブルシューティングを行う方法を紹介します。

Read More